進化したフィッシング: デバイス登録のトリックが、MFA を持たない被害者のためのフィッシャーのツールボックスに追加されます

最近、攻撃者が操作するデバイスを組織のネットワークに参加させてキャンペーンをさらに広めることで、従来のフィッシング戦術に新しい手法を追加する大規模なマルチフェーズ キャンペーンを発見しました。キャンペーンの第 2 段階は、ID セキュリティの重要な柱である多要素認証 (MFA) を実装していない被害者に対して成功したことがわかりました。 MFA などの追加の保護手段がない場合、攻撃は、盗まれたばかりの資格情報を使用してデバイスを登録する機能を介して、Bring Your Own Device (BYOD) の概念を利用します。

キャンペーンの第 1 段階では、主にオーストラリア、シンガポール、インドネシア、タイにある標的組織で認証情報を盗みました。次に、盗まれた資格情報が第 2 段階で利用されました。攻撃者は侵害されたアカウントを使用して、ラテラル フィッシングを介して組織内での足場を拡大したり、アウトバウンド スパムを介してネットワークを超えたりしました。

攻撃者が制御するデバイスをネットワークに接続すると、攻撃者はひそかに攻撃を広め、標的のネットワーク全体を横方向に移動することができました。この場合、デバイス登録はさらなるフィッシング攻撃に使用されましたが、他のユースケースが観察されているため、デバイス登録を利用することが増加しています。さらに、この手法を容易にするように設計された侵入テスト ツールがすぐに利用できるようになったことで、将来的には他のアクター間での使用が拡大するだけです。

攻撃者が盗まれた資格情報を使用してデバイスやネットワークにアクセスするのを防ぐ MFA は、ほとんどのターゲットのキャンペーンを阻止しました。ただし、MFA が有効になっていない組織では、攻撃が進行しました。

フィッシングは、企業を攻撃して最初の侵入を得る最も有力な手段であり続けています。このキャンペーンは、管理対象デバイスの可視性と保護の継続的な改善により、攻撃者が代替手段を探らざるを得なくなったことを示しています。潜在的な攻撃対象領域は、在宅勤務する従業員の増加によってさらに拡大し、社内ネットワークと社外ネットワークの境界が変化しています。攻撃者は、さまざまな戦術を展開して、ハイブリッド ワーク、人的エラー、「シャドー IT」、または管理されていないアプリ、サービス、デバイス、および標準ポリシーの範囲外で動作するその他のインフラストラクチャに固有の組織の問題を標的にします。

これらの管理されていないデバイスは、参加時にセキュリティ チームによって無視されるか見落とされることが多く、侵害、静かなラテラル ムーブメントの実行、ネットワーク境界のジャンプ、およびより広範な攻撃を開始するための持続性の達成のための有利なターゲットになります。さらに懸念されるのは、このケースで当社の研究者が明らかにしたように、攻撃者が完全に操作し、完全に制御しているデバイスの接続に成功した場合です。

この攻撃に代表されるように巧妙化する攻撃をかわすために、組織は電子メール、ID、クラウド、およびエンドポイントからの脅威データを配信して関連付けるソリューションを必要としています。 Microsoft 365 Defenderは、これらのドメイン全体で保護を調整し、シグナル間のリンクを自動的に見つけて包括的な防御を提供します。このクロスドメインの可視性により、このキャンペーンを明らかにすることができました。受信トレイ ルールの異常な作成を検出し、それをフィッシング キャンペーンの最初の波にさかのぼり、データを関連付けて、攻撃者の次のステップ、つまりデバイスの登録とその後のフィッシング キャンペーンを明らかにしました。

この攻撃は、認証情報が盗まれ、ゼロ トラスト ポリシーが導入されていない場合に、ネットワークの一部になる可能性がある、攻撃者によって制御された管理対象外のデバイスの影響を示しています。 Microsoft Defender for Endpointは、攻撃者がサーバーやその他の管理対象デバイスとのネットワーク対話を開始するたびに、組織が攻撃者によって操作されている特定の管理対象外デバイスを見つけるのに役立つデバイス検出機能を提供します。これらのデバイスは、検出されてオンボーディングされると、修復して保護することができます。

このブログ投稿では、大規模で多段階のフィッシング キャンペーンの技術的側面を共有します。攻撃者が最初の攻撃の波をどのように使用して、さまざまな組織の複数のメールボックスを侵害し、検出を回避するために受信トレイ ルールを実装したかを詳しく説明します。これに続いて、ある組織の MFA プロトコルの欠如を悪用して、攻撃者の管理されていないデバイスを登録し、ラテラル、内部、および送信スパムを介して悪意のあるメッセージを広める 2 番目の攻撃の波が続きました。

最初のウェーブとルールの作成

このキャンペーンでは、複数のコンポーネントと手法を活用して、アカウントを密かに侵害し、攻撃を広めました。 Microsoft 365 Defender の脅威データを使用して、攻撃の最初の侵害ベクトルがフィッシング キャンペーンであることがわかりました。分析の結果、受信者は DocuSign ブランドのフィッシング メールを受信したことがわかりました。

攻撃者は、.xyz トップレベル ドメインに登録された一連のフィッシング ドメインを使用しました。 URL ドメインは、次の正規表現構文で記述できます。

UrlDomain は正規表現 @”^[az]{5}.ar[az]{4,5}.xyz” と一致します

フィッシング リンクは、URL のクエリ パラメータでエンコードされた被害者の電子メール アドレスを使用して、電子メールごとに一意に生成されました。リンクをクリックすると、被害者は、Office 365 のログイン ページを模倣した newdoc-lnpye[.]ondigitalocean[.]app のフィッシング Web サイトにリダイレクトされました。パスワードを入力します。この手法により、被害者が Web サイトを正当で信頼できるものと見なす可能性が高まりました。

次に、被害者の盗まれた資格情報がすぐに Exchange Online PowerShell との接続を確立するために使用されたことを発見しました。これは、おそらくフィッシング キットの一部として自動化されたスクリプトを使用したものです。リモート PowerShell 接続を利用して、攻撃者はNew-InboxRuleコマンドレットを介して受信トレイ ルールを実装し、電子メール メッセージの件名または本文のキーワードに基づいて特定のメッセージを削除しました。受信トレイ ルールにより、攻撃者は、侵害されたユーザーに送信された可能性のある配信不能レポートと IT 通知メールを削除することで、侵害されたユーザーの疑いを喚起することを回避できました。

このキャンペーンの第 1 段階の調査中に、複数の組織で 100 を超えるメールボックスが侵害され、受信トレイ ルールが一貫して以下のパターンに適合していることが確認されました。

さまざまな組織内の複数のユーザーが最初の波で侵害されましたが、MFA が有効になっているターゲットの大部分では、攻撃はこの段階を超えて進行しませんでした。攻撃の伝播は、MFA プロトコルの欠如に大きく依存していました。 Office 365 アプリケーションの MFA を有効にしたり、新しいデバイスを登録したりすると、攻撃チェーンの第 2 段階が中断された可能性があります。

デバイスの登録とフィッシングの第 2 波

MFA が有効になっていない組織に属する 1 つのアカウントがさらに悪用され、攻撃者の足場を拡大し、キャンペーンを広めました。より具体的には、攻撃は組織の MFA 適用の欠如を悪用して、デバイスを Azure Active Directory ( Azure AD ) インスタンスに参加させたり、場合によっては Intune などの管理プロバイダーに登録して、準拠デバイスに基づいて組織のポリシーを適用したりしました。

この例では、攻撃者は最初に自分の Windows 10 マシンに Outlook をインストールしました。この攻撃者所有のデバイスは、盗まれた資格情報を使用してデバイスを登録するための Outlook の最初の起動エクスペリエンス プロンプトを受け入れるだけで、被害者の組織の Azure AD に正常に接続された可能性があります。 Azure AD MFA ポリシーは、この段階で攻撃チェーンを停止します。ただし、包括性のために、 AADInternalsなどのいくつかの一般的なレッド チーム ツールに注意する必要があります。 コマンドJoin-AADIntDeviceToAzureADを使用すると、盗まれたトークンが存在し、強力な MFA ポリシーがない場合でも、同様の結果を得ることができます。

Azure AD は、デバイスが認証を試みるときにアクティビティ タイムスタンプを評価してトリガーします。これを確認して、新たに登録されたデバイスを検出できます。この場合、これには、Azure AD に参加しているか、ハイブリッド Azure AD に参加してネットワーク上でアクティブな Windows 10 デバイスが含まれます。アクティビティのタイムスタンプは、 Get-AzureADDeviceコマンドレットを使用するか、Azure portal のデバイス ページの [アクティビティ] 列を使用して確認できます。期間が定義され、潜在的な不正なデバイスが特定されると、そのデバイスを Azure AD から削除して、そのデバイスを使用してサインインするリソースへのアクセスを防ぐことができます。

攻撃者が新たに登録したデバイスと相まって、標的のアカウントで受信トレイ ルールが作成されたことは、攻撃者がキャンペーンの第 2 波を開始する準備が整ったことを意味します。この第 2 波は、ラテラル、内部、およびアウトバウンドのフィッシング メッセージを送信することで、追加のアカウントを侵害することを目的としているようです。

ドメインの一部として認識されるようになったデバイスを、通常のユーザーとまったく同じように構成されたメール クライアントと組み合わせて使用することにより、攻撃者は、典型的な疑わしい識別子の多くが欠落している組織内の電子メールを送信する能力を獲得しました。これらの疑わしいメッセージ要素を十分に削除することで、攻撃者はフィッシング キャンペーンの成功を大幅に拡大しました。

第 2 の波を開始するために、攻撃者は標的のユーザーの侵害されたメールボックスを利用して、被害組織の内外の 8,500 人を超えるユーザーに悪意のあるメッセージを送信しました。電子メールは、共有されている「Payment.pdf」ファイルが正当なものであることを受信者に納得させるために、SharePoint 共有への誘いをメッセージ本文として使用していました。

キャンペーンの第 1 段階と同様に、第 2 波のフィッシング メールで使用された URL が第 1 波の構造と一致し、Office 365 のログイン ページを模倣した newdoc-lnpye[.]ondigitalocean[.]app フィッシング Web サイトにもリダイレクトされていることがわかりました。第 2 段階のフィッシング サイトで資格情報を入力した被害者は、同様に Exchange Online PowerShell に接続され、それぞれの受信トレイの電子メールを削除するルールがすぐに作成されました。このルールは、キャンペーンの最初の攻撃段階で作成されたルールと同じ特徴を持っていました。

一般に、大多数の組織は MFA を有効にしており、攻撃を広めてネットワークの足場を拡大する攻撃者の能力から保護されていました。それにもかかわらず、MFA が有効になっていないものは、潜在的な将来の攻撃の波で犠牲になる可能性があります。

デバイスの永続性の修復: パスワードをリセットするだけでは不十分な場合

この斬新な攻撃チェーンと、このキャンペーンで使用された追加の手法を分析すると、従来のフィッシング修復プレイブックでは不十分であることがわかります。侵害されたアカウントのパスワードをリセットするだけで、ユーザーが侵害されないようにすることはできますが、潜在的な持続メカニズムを排除するには不十分です。

ハイブリッド ネットワークで運用する慎重な防御者は、次の手順も考慮する必要があります。

• 侵害されたアカウントに関連付けられたアクティブなセッションとトークンの取り消し
• アクターによって最終的に作成された メールボックス ルールの削除
• アクターによってAzure AD に参加している不正なデバイスを無効にして削除する

これらの追加の修復手順が実行されない場合、侵害されたアカウントのパスワードを正常にリセットした後でも、攻撃者は依然として貴重なネットワーク アクセスを取得する可能性があります。この新しいタイプの脅威を適切に緩和して防御するには、この攻撃を深く理解する必要があります。

多段階のフィッシング キャンペーンに対する防御

最新のMicrosoft Digital Defense Reportは、フィッシングが企業と個人の両方に大きな脅威をもたらすことを詳述していますが、昨年の最も被害の大きかった攻撃の多くで資格情報のフィッシングが利用されていました。従業員の資格情報、特に高い権限を持つ従業員を標的とする攻撃者は、通常、盗んだデータを使用して他のデバイスにサインインし、ネットワーク内を横方向に移動します。このブログで説明したフィッシング キャンペーンは、これらの攻撃がますます巧妙化していることを示しています。

攻撃者がターゲットに到達する前に攻撃を妨害するために、適切な認証情報衛生、ネットワーク セグメンテーション、および同様のベスト プラクティスにより、ネットワークを介して拡散しようとする攻撃者の「コスト」が増加します。これらのベスト プラクティスは、最初の侵入後に横方向に移動して資産を侵害する攻撃者の能力を制限する可能性があり、ドメイン全体の可視性を提供し、保護コンポーネント全体で脅威データを調整する高度なセキュリティ ソリューションで補完する必要があります。

組織は、基本認証、すべてのユーザーに対して多要素認証を有効にし、次の場合に多要素認証を要求するデバイスを Azure AD に参加させる. Microsoft 365 グローバル管理者もExchange Online PowerShell を無効にする特定のユーザーまたはフィルター可能な属性のリストを介して、個々または複数のエンド ユーザーに対して、ターゲット アカウントがすべて役職や部門などのフィルター可能な一意の属性を共有していると仮定します。セキュリティを強化するために、お客様は新しい条件付きアクセス制御デバイスを登録するために MFA を要求します。これは、デバイス プラットフォームや信頼できるネットワークなどの他の CA 条件と組み合わせることができます。

Microsoft 365 Defenderは、疑わしい受信トレイ ルールの作成と疑わしいデバイスの登録によって生成された最初のフィッシングに関連するアラートとシグナルを、1 つのわかりやすいインシデントに関連付けます。

Microsoft Defender for Office 365は、エッジ保護、送信者インテリジェンス、コンテンツ フィルタリング、配信後保護を含む多層型の電子メール フィルタリング スタックを使用して、電子メールの脅威から保護します。また、自動電子メール転送を構成および制御するための送信スパム フィルター ポリシーも含まれます。外部の受信者に。さらに、Microsoft Defender for Office 365 は、 安全なリンク機能を使用して、クリック時に内部メッセージまたは Office ドキュメント内の悪意のある URL からユーザーをプロアクティブに保護します。安全なリンク機能により、クリック時に内部メッセージまたは Office ドキュメント内の悪意のある URL からユーザーをプロアクティブに保護します。

高度なハンティング クエリ

フィッシング URL を含む電子メールのハンティング

let startTime = ago(7d);
let endTime = now();
EmailUrlInfo
| | (startTime..endTime) の間のタイムスタンプ
| |ここで、UrlDomain は正規表現 @"^[az]{5}.ar[az]{4,5}.xyz" と一致します
| |プロジェクト NetworkMessageId,Url
| |参加 (EmailEvents 
| | (startTime..endTime) の間のタイムスタンプ)
NetworkMessageId で

疑わしい受信トレイ ルールレットのハンティングlet startTime = ago(7d);

// 疑わしい受信トレイ ルールのハンティング
let startTime = ago(7d);
let endTime = now();
CloudAppEvents
| |タイムスタンプの範囲 (開始時間 .. 終了時間)
| |ここで、ActionType == "New-InboxRule"
| |ここで、RawEventData には「Spam Filter」が含まれます
| | RawEventData has_any("ジャンク","スパム","フィッシング","ハッキング","パスワード","あなたと") 
| |ここで、RawEventData には「DeleteMessage」が含まれています 
| |プロジェクトのタイムスタンプ、AccountDisplayName、AccountObjectId、IPAddress

不正なデバイス登録のハンティング

// 不正なデバイス登録のハンティング
let startTime = ago(7d);
let endTime = now();
CloudAppEvents
| |タイムスタンプの範囲 (開始時間 .. 終了時間)
| | where ActionType == "登録済みの所有者をデバイスに追加します。" 
| |ここで、RawEventData には「notorius」が含まれています
| | where AccountDisplayName == "デバイス登録サービス"
| |ここで、isnotempty(RawEventData.ObjectId) および isnotempty(RawEventData.ModifiedProperties[0].NewValue) および isnotempty(RawEventData.Target[1].ID) および isnotempty(RawEventData.ModifiedProperties[1].NewValue)
| | Extend AccountUpn = tostring(RawEventData.ObjectId)
| | extend AccountObjectId = tostring(RawEventData.Target[1].ID)
| | extends DeviceObjectId = tostring(RawEventData.ModifiedProperties[0].NewValue)
| | extends DeviceDisplayName = tostring(RawEventData.ModifiedProperties[1].NewValue)
| |プロジェクトのタイムスタンプ、ReportId、AccountUpn、AccountObjectId、DeviceObjectId、DeviceDisplayName