攻撃者より先に弱点を見つける

このブログ投稿は、もともとM-Trends 2019の記事として掲載されたものです。

FireEye Mandiant のレッド チーム コンサルタントは、環境に溶け込み、従業員がワークステーションやアプリケーションとどのようにやり取りするかを観察することで、攻撃のライフサイクル全体にわたって高度な国家攻撃者による実際のサイバー攻撃をエミュレートする目的ベースの評価を実行します。このような評価は、組織が現在の検出および対応手順の弱点を特定するのに役立ち、既存のセキュリティ プログラムを更新して最新の脅威により適切に対処できるようにします。

ある金融サービス会社は、情報セキュリティ チームの検出、防止、および対応能力の有効性を評価するために、Mandiant レッド チームと契約しました。このエンゲージメントの主な目的は、検出されることなく次のアクションを達成することでした。

• Active Directory (AD) の侵害:クライアントの Microsoft Windows AD 環境内でドメイン管理者権限を取得します。
• 金融アプリケーションへのアクセス:金融送金データとアカウント管理機能を含むアプリケーションとサーバーにアクセスできます。
• RSA Multi-Factor Authentication (MFA) をバイパスする: MFA をバイパスして、クライアントの支払い管理システムなどの機密性の高いアプリケーションにアクセスします。
• ATM 環境へのアクセス:内部ネットワークのセグメント化された部分で ATM を識別してアクセスします。

最初の妥協

Mandiant の調査経験に基づくと、ソーシャル エンジニアリングは、高度な攻撃者が使用する最も一般的で効率的な初期攻撃ベクトルになっています。このエンゲージメントでは、レッド チームは電話ベースのソーシャル エンジニアリング シナリオを使用して、メール検出機能を回避し、フィッシング メールによってしばしば残される残留証拠を回避しました。

レッド チームは、クライアントのインターネットに接続されたインフラストラクチャのオープン ソース インテリジェンス (OSINT) 偵察を実行しているときに、https://owa.customer.example でホストされている Outlook Web App ログイン ポータルを発見しました。赤いチームは類似ドメイン (https://owacustomer.example) を登録し、クライアントのログイン ポータルのクローンを作成しました (図 1)。

OWA ポータルが複製された後、レッド チームはさらに OSINT を介して IT ヘルプデスクと従業員の電話番号を特定しました。これらの電話番号が収集されると、レッド チームは公開されているオンライン サービスを使用して従業員に電話をかけ、IT ヘルプデスクの電話番号を偽装しました。

Mandiant のコンサルタントは、ヘルプデスクの技術者を装い、従業員に電子メールの受信トレイが新しい会社のサーバーに移行されたことを知らせました。 「移行」を完了するには、従業員は複製された OWA ポータルにログインする必要があります。疑いを避けるために、従業員は認証されるとすぐに正規の OWA ポータルにリダイレクトされました。このキャンペーンを使用して、レッド チームは 8 人の従業員から、クライアントの内部ネットワークに足場を築くために使用できる資格情報を取得しました。

足場を固める

クライアントの仮想プライベート ネットワーク (VPN) と Citrix Web ポータルは、ユーザーがパスワードと RSA トークン コードを提供する必要がある MFA を実装していましたが、レッド チームは単一要素の Bring Your Own Device (BYOD) ポータルを見つけました (図 2)。

レッド チームは、盗んだドメイン資格情報を使用して BYOD Web ポータルにログインし、CUSTOMERuser0 の Android フォンの登録を試みました。レッド チームはユーザー設定を表示できましたが、新しいデバイスを追加することはできませんでした。この制限を回避するために、コンサルタントは IBM MaaS360 Android アプリをダウンロードし、電話からログインしました。デバイス構成プロセスにより、クライアントの VPN 証明書がインストールされ (図 13)、Cisco AnyConnect アプリに自動的にインポートされ、電話にもインストールされました。

AnyConnect アプリを起動した後、レッド チームは電話がクライアントの VPN で IP アドレスを受信したことを確認しました。次に、レッド チームは、Google Play ストアの一般的なテザリング アプリを使用して、ラップトップを電話にテザリングし、クライアントの内部ネットワークにアクセスしました。

権限の昇格

内部ネットワークに接続すると、赤いチームは Windows の「runas」コマンドを使用して PowerShell を CUSTOMERuser0 として起動し、「 Kerberoast 」攻撃を実行しました。ケルベロスティングは、Active Directory の正当な機能を悪用して、サービス アカウントのチケット許可サービス (TGS) チケットと、脆弱なパスワードを使用したブルート フォース アカウントを取得します。

攻撃を実行するために、赤いチームはサービス プリンシパル名 (SPN) を持つすべてのアカウントについて Active Directory ドメイン コントローラーにクエリを実行しました。次に、典型的な Kerberos 攻撃は、関連付けられたユーザー アカウントの SPN の TGS を要求します。 Kerberos チケット リクエストは一般的ですが、デフォルトのKerberos 攻撃ツールは大量のリクエストを生成します。これは異常であり、疑わしいと識別される可能性があります。コンサルタントは、「管理者」、「SVC」、「SQL」などのキーワード検索を使用して、潜在的に価値の高い 18 のアカウントを特定しました。検出を回避するために、レッド チームは、この対象となるアカウントのサブセットのチケットを取得し、各リクエスト間にランダムな遅延を挿入しました。これらのアカウントの Kerberos チケットは、 Mandiant のパスワード クラッキング サーバーにアップロードされ、2.5 時間以内に 18 個のアカウントのうち 4 個のパスワードをブルート フォース攻撃することに成功しました。

その後、赤いチームはクラックされたアカウントの Active Directory グループ メンバーシップのリストを編集し、{ComputerName}_Administrators の命名スキームに従っているいくつかのグループを明らかにしました。赤いチームは、 {ComputerName}C$ のリモート ディレクトリ リストを実行することにより、アカウントが指定されたコンピューターに対するローカル管理者権限を持っていることを確認しました。また、赤いチームは、PowerShell Remoting を使用してシステム上でコマンドを実行し、ログオンしているユーザーと実行中のソフトウェアに関する情報を取得しました。このデータを確認した後、レッド チームはエンドポイントの検出と応答 (EDR) エージェントを特定しました。このエージェントは、疑わしいコマンド ライン引数と関連する親/子プロセスのヒューリスティックの実行を識別して警告する可能性が高いメモリ内検出を実行する機能を備えていました。資格情報の盗難。

検出を回避するために、レッド チームは、WMI 経由で実行されるカスタム ユーティリティを使用して、LSASS プロセス メモリ ダンプを作成しました。赤いチームは SMB 経由で LSASS ダンプ ファイルを取得し、 Mimikatzを使用して平文のパスワードと NTLM ハッシュを抽出しました。赤いチームは、アクティブな特権ユーザー セッションが存在する可能性があると特定された 10 の固有のシステムでこのプロセスを実行しました。これら 10 個のシステムの 1 つから、レッド チームはドメイン管理者グループのメンバーの資格情報を正常に取得しました。

このドメイン管理者アカウントへのアクセスにより、レッド チームは、顧客のドメイン内のすべてのシステムとユーザーに対する完全な管理者権限を取得しました。次に、この特権アカウントを使用して、いくつかの優先度の高いアプリケーションとネットワーク セグメントへのアクセスに集中し、重要な顧客資産に対するこのような攻撃のリスクを示しました。

高価値目標へのアクセス

このフェーズでは、クライアントは、RSA MFA システム、ATM ネットワーク、および高価値の金融アプリケーションを、Mandiant レッド チームがターゲットとする 3 つの重要な目標として特定しました。

金融アプリケーションをターゲットにする

レッド チームは、目的に関連するホスト名について Active Directory データを照会することからこのフェーズを開始し、主要な金融アプリケーションへの参照を含む複数のサーバーとデータベースを見つけました。レッド チームは、金融アプリケーション Web サーバー上のファイルとドキュメントを確認し、次のユーザーが金融アプリケーションにアクセスしたことを示す認証ログを見つけました。

• CUSTOMERuser1
• CUSTOMERuser2
• CUSTOMERuser3
• CUSTOMERuser4

赤いチームは、金融アプリケーションの Web インターフェイス (図 4) に移動し、認証に「RSA パスコード」が必要であることを発見しました。これは、アクセスには MFA トークンが必要であることを明確に示しています。

多要素認証のバイパス

レッド チームは、ネットワーク ファイル共有で構成ファイルと IT ドキュメントを検索することにより、クライアントの RSA MFA 実装をターゲットにしました。レッド チームは、1 つのファイル共有 (図 5) で、3 つの RSA サーバーのホスト名を明らかにするソフトウェア移行ログ ファイルを発見しました。

次に、レッド チームは、RSA 認証モジュールをインストールしたユーザーの特定に焦点を当てました。赤いチームは、RSA サーバーの C:Users および C: データ フォルダーのディレクトリ リストを実行し、CUSTOMER CUSTOMER_ADMIN10 が RSA エージェント インストーラーがダウンロードされた同じ日にログインしていることを発見しました。これらの指標を使用して、レッド チームは CUSTOMER CUSTOMER_ADMIN10 を潜在的な RSA 管理者としてターゲットにしました。

レッド チームは、ユーザーの詳細を確認することで、CUSTOMERCUSTOMER_ADMIN10 アカウントが実際には、対応する標準ユーザー アカウント CUSTOMERuser103 の特権アカウントであることを特定しました。次にレッド チームは、オープン ソースの PowerShell ツールであるPowerViewを使用して、CUSTOMERuser103 がログインした、または最近ログインした環境内のシステムを特定しました (図 7)。

赤いチームは、10.1.33.133 の LSASS メモリから資格情報を収集し、CUSTOMERuser103 のクリアテキスト パスワードを正常に取得しました (図 8)。

赤いチームは、CUSTOMERuser103 の資格情報を使用して、MFA なしで、RSA セキュリティ コンソールの Web フロントエンドに管理者権限でログインしました (図 9)。

多くの組織には、新しい RSA トークンの作成を監視するための監査手順があるため、レッド チームは、最もステルスなアプローチは緊急トークンコードをプロビジョニングすることであると判断しました。ただし、クライアントはソフトウェア トークンを使用していたため、緊急トークンには依然としてユーザーの RSA SecurID PIN が必要でした。赤いチームは、金融アプリケーションの個々のユーザーをターゲットにして、ワークステーションに保存されている RSA PIN を見つけようとすることにしました。

赤いチームは、どのユーザーが金融アプリケーションにアクセスできるかを知っていましたが、各ユーザーに割り当てられたシステムを知りませんでした。これらのシステムを特定するために、赤いチームは受信トレイを通じてユーザーをターゲットにしました。赤いチームは、Ruler11 ユーティリティを使用して MAPI over HTTP を介して、金融アプリケーション ユーザー CUSTOMERuser1 に悪意のある Outlook ホームページを設定しました。これにより、ユーザーが自分のシステムで Outlook を再度開いたときに、バックドアが起動することが保証されました。

CUSTOMERuser1 が Outlook を再起動し、ワークステーションが侵害されると、レッド チームはシステムにインストールされているプログラムの列挙を開始し、標的のユーザーが一般的なパスワード保管ソリューションである KeePass を使用していることを特定しました。

レッド チームは、悪意のあるイベント トリガーを KeePass 構成ファイルに追加することで、KeePass に対して攻撃を実行し、マスター パスワードを取得せずにファイルの内容を取得しました (図 10)。このトリガーにより、次にユーザーが KeePass を開いたときに、KeePass データベース内のすべてのパスワードを含むカンマ区切り値 (CSV) ファイルが作成され、レッド チームはユーザーのローミング プロファイルからエクスポートを取得できました。

結果として得られた CSV ファイルのエントリの 1 つは、金融アプリケーションのログイン資格情報であり、アプリケーション パスワードだけでなく、ユーザーの RSA SecurID PIN も含まれていました。この情報により、赤いチームは金融アプリケーションにアクセスするために必要な資格情報をすべて取得しました。

レッド チームは、CUSTOMERuser103 として RSA セキュリティ コンソールにログインし、CUSTOMERuser1 のユーザー レコードに移動しました。その後、レッド チームはオンラインの緊急アクセス トークンを生成しました (図 11)。トークンは、次に CUSTOMER user1 が正当な RSA SecurID PIN + トークンコードで認証されたときに、緊急アクセス コードが無効になるように構成されていました。これは、秘密を保ち、ユーザーのビジネス遂行能力への影響を軽減するために行われました。

その後、レッド チームは、緊急アクセス トークンを使用して金融アプリケーションへの認証に成功しました (図 12)。

ATMへのアクセス

レッド チームの最終的な目的は、主要な企業ドメインとは別のネットワーク セグメントにある ATM 環境にアクセスすることでした。最初に、レッド チームは、ATM_Administrators などの潜在的に関連するグループのメンバー リストを照会して、価値の高いユーザーのリストを作成しました。次に、レッド チームは、アクセス可能なすべてのシステムを検索して、これらの標的のアカウントによる最近のログインを探し、パスワードをメモリからダンプしました。

ATM 管理者 CUSTOMERADMIN02 のパスワードを取得した後、レッド チームはクライアントの内部 Citrix ポータルにログインして、従業員のデスクトップにアクセスしました。レッド チームは管理者の文書を確認し、クライアントの ATM には、企業ネットワーク セグメントと ATM ネットワーク セグメントを接続する JUMPHOST01 という名前のサーバーを介してアクセスできると判断しました。赤いチームは、Internet Explorer に保存された「ATM 管理」のブックマークも発見しました。このリンクは Citrix デスクトップから直接アクセスできませんでしたが、レッド チームは、JUMPHOST01 からアクセスできる可能性が高いと判断しました。

ジャンプ サーバーは、システムに RDP で接続しようとするユーザーに対して MFA を適用したため、レッド チームは、以前に侵害されたドメイン管理者アカウント CUSTOMER ADMIN01 を使用して、WMI を介して JUMPHOST01 でペイロードを実行しました。 WMI は MFA をサポートしていないため、レッド チームは JUMPHOST01 とレッド チームの CnC サーバー間の接続を確立し、SOCKS プロキシを作成し、RSA ピンなしで ATM 管理アプリケーションにアクセスすることができました。レッド チームは、ATM 管理アプリケーションへの認証に成功し、すべての ATM マシンで、お金の支払い、ローカル管理者の追加、新しいソフトウェアのインストール、SYSTEM 権限でのコマンドの実行を行うことができました (図 13)。

ポイント: 多要素認証、パスワード ポリシー、アカウント セグメンテーション

多要素認証

Mandiant の専門家は、VPN またはリモート アクセス インフラストラクチャを MFA で保護しているクライアントの数が大幅に増加していることを確認しています。ただし、社内ネットワーク内からアクセスされるアプリケーションの MFA が不足していることがよくあります。したがって、FireEye では、外部からアクセス可能なすべてのログイン ポータルと機密性の高い内部アプリケーションに対して MFA を適用することをお客様に推奨しています。

パスワード ポリシー

このエンゲージメント中に、レッド チームは 4 つの特権サービス アカウントを危険にさらしました。これは、すぐに力ずくで攻撃される可能性のある脆弱なパスワードを使用したためです。 FireEye は、お客様がすべてのアカウントに対して強力なパスワードの実践を実施することを推奨しています。お客様は、サービス アカウントに 20 文字以上のパスワードを適用する必要があります。可能であれば、お客様は Microsoft マネージド サービス アカウント (MSA) またはエンタープライズ パスワード保管ソリューションを使用して、特権ユーザーを管理する必要もあります。

アカウントのセグメンテーション

レッド チームが環境への最初のアクセス権を取得すると、アカウントのセグメンテーションがないため、ドメイン内の権限を迅速に昇格させることができました。 FireEye では、アカウントをプロビジョニングする際に「最小権限の原則」に従うことをお客様に推奨しています。通常のユーザー、管理ユーザー、およびドメイン管理者は、1 人の従業員がそれぞれ 1 つ必要とする場合でも、すべて固有のアカウントになるように、アカウントは役割ごとに分ける必要があります。

通常のユーザー アカウントには、文書化されたビジネス要件がない限り、ローカル管理者アクセス権を付与しないでください。ワークステーション管理者はサーバーにログインできず、その逆も同様です。最後に、ドメイン管理者にはドメイン コントローラへのログインのみを許可し、サーバー管理者はそれらのシステムにアクセスできないようにする必要があります。このようにアカウントをセグメント化することで、攻撃者が権限を昇格させたり、侵害された単一のアカウントから横方向に移動したりすることを大幅に困難にすることができます。

結論

このケース スタディで示されているように、Mandiant のレッド チームは、クライアントの環境に足場を築き、会社のドメインの完全な管理制御を取得し、ソフトウェアやオペレーティング システムのエクスプロイトなしですべての重要なビジネス アプリケーションを侵害することができました。代わりに、レッド チームは、システムの構成ミスの特定、ソーシャル エンジニアリング攻撃の実行、およびクライアントの内部ツールとドキュメントの使用に重点を置きました。レッド チームは、クライアントの MFA、サービス アカウント パスワード ポリシー、およびアカウント セグメンテーションの構成により、目的を達成することができました。