Infostealer hunting（情報窃取マルウェアの脅威ハンティング）で今すぐ見直すべきなのは、マルウェア本体のハッシュや既知C2だけではありません。2026年4月16日時点で注目すべき Microsoft Security Experts guidance では、WhatsApp のような信頼済みコミュニケーション基盤や、PDF変換ツールに見せかけたソフトウェア配布経路が、認証情報窃取マルウェアの侵入・拡散に悪用される流れが示されています。(TECHCOMMUNITY.MICROSOFT.COM)
Threat hunters や SOC analysts が取るべき結論は明確です。Microsoft Defender XDR では「怪しいファイルを見つける」だけでなく、wscript.exe、PowerShell、Python、AutoIt、スケジュールタスク、ブラウザプロファイルアクセスといった一連の前兆をつなげて、認証情報やセッションCookieが盗まれる前に検出ロジックを組む必要があります。
Microsoft Security Experts guidance / Microsoft Defender の最新動向で押さえるべき結論
Microsoft Security Experts の最新解説で重要なのは、攻撃者が「怪しいサイト」ではなく「ユーザーが普段から信頼している入口」を使っている点です。WhatsApp、PDF変換ツール、広告、検索結果、正規クラウドサービスに見える挙動が混ざるため、従来のブラックリスト中心の監視では初動を見逃しやすくなります。
今回の trusted-platform abuse から読み取れる実務上のポイントは、次の3つです。
- Infostealer hunting は、侵害後のIOC照合では遅い。スクリプト実行、ペイロード取得、永続化、ブラウザデータ接触の段階で見る。
- Microsoft Defender XDR の Advanced Hunting では、単一イベントではなく親子プロセス、ファイル作成、ネットワーク接続、スケジュールタスクを時系列でつなぐ。
- カスタム検出化する前に、誤検知が業務ツールに偏っていないかを確認し、検出頻度・ルックバック・対象デバイスをSOC運用に合わせる。
Infostealer hunting の情報が継続的に検索される理由は、単なる脅威ニュースではなく、SOCのアクティブディフェンス業務に直結するからです。アラート調査、横展開確認、KQL作成、カスタム検出、ASRルール評価まで、検索ユーザーの次の行動が明確です。
Trusted Platform Abuse が Infostealer hunting を難しくする理由
Trusted Platform Abuse とは、攻撃者が広く使われるサービス、広告ネットワーク、メッセージングアプリ、正規ソフトウェアに見える仕組みを悪用し、ユーザーやセキュリティ製品の警戒を下げる手口です。
Infostealer の目的は、端末の完全制御だけではありません。ブラウザに保存されたCookie、セッション情報、認証キャッシュ、暗号資産ウォレット、決済サービスの認証情報などを盗めれば、攻撃者は正規ユーザーとしてクラウドサービスに入れる可能性があります。つまり、EDRでマルウェアを削除しても、盗まれたトークンやセッションが残っていれば被害は続きます。
そのため、ハンティングの焦点は「最終ペイロード」から「その前の不自然な業務外挙動」に移すべきです。
| 監視対象 | 見るべき理由 | 典型的なハンティング観点 |
|---|---|---|
| スクリプト実行 | 初期実行やダウンロード処理に使われやすい | wscript.exe、VBS、BAT、PowerShell の親子関係 |
| ユーザー領域の実行ファイル | 正規インストーラーや一時ファイルに見せかける | AppData、Temp、Downloads、Desktop からの実行 |
| Python / AutoIt | 自動化、ローダー、回避処理に使われる場合がある | 署名、配置場所、親プロセス、コマンドライン |
| スケジュールタスク | 再起動後の再実行や永続化に使われる | 新規作成、実行時刻、タスク名、起動対象 |
| ブラウザプロファイル接触 | Cookieやセッション情報の窃取につながる | Chrome、Edge、Firefox のプロファイル配下への非ブラウザプロセス接触 |
| 外部通信 | ペイロード取得や情報送信に使われる | 新規ドメイン、POST通信、不審なプロセスからの通信 |
Microsoft Security Experts が示した2つの攻撃パターン
Microsoft Security Experts の解説では、信頼済みプラットフォーム悪用の例として、WhatsApp を使った Eternidade Stealer 配布と、Crystal PDF を装った悪性インストーラーキャンペーンが取り上げられています。どちらも「ユーザーが自然にクリックしそうな入口」から始まり、最終的に認証情報窃取へ進む点が共通しています。(TECHCOMMUNITY.MICROSOFT.COM)
| 攻撃パターン | 初期の見え方 | 攻撃チェーンの要点 | SOCで見るべき初期シグナル |
|---|---|---|---|
| WhatsApp悪用 | 知人から届いたように見えるメッセージや添付ファイル | VBS、BAT、PowerShell、Python、自動メッセージ送信、MSI、AutoIt、プロセスインジェクション | wscript.exe 起点のスクリプト実行、PowerShellダウンロード、Python実行、AutoItローダー |
| 偽PDF変換ツール | PDF編集・変換ツールの広告や検索結果 | CrystalPDF.exe、スケジュールタスク、C2通信、ブラウザプロファイルアクセス | ユーザー領域からの実行、Crystal_updater のようなタスク、ブラウザCookie・セッション関連ファイルへの接触 |
WhatsApp悪用では「メッセージアプリ」ではなく「端末上の自動化挙動」を見る
WhatsApp悪用の事例では、Microsoft Defender Experts が2025年11月第3週に確認したキャンペーンとして、難読化されたVisual Basic Scriptの実行から始まり、BATファイル、PowerShellによる追加ペイロード取得、PythonスクリプトによるWhatsApp Webベースの拡散、MSIによる Eternidade Stealer 配布へ進む多段階チェーンが説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
特に重要なのは、攻撃が「WhatsApp通信そのもの」だけで完結しないことです。端末側では、VBS、PowerShell、Python依存関係、AutoIt、.log に見せかけたスクリプト、暗号化ペイロード、svchost.exe へのプロセスホローイングなど、エンドポイントで検出できる痕跡が複数残ります。
SOCでは「WhatsAppを使っているか」だけで判断しない方が安全です。企業によっては業務連絡や海外拠点との連絡でWhatsAppが使われる場合もあります。ブロック方針より先に、端末上の異常な自動化・ペイロード取得・認証情報窃取の前兆を見てください。
偽PDF変換ツールでは「正規に見える便利ツール」の裏側を見る
Crystal PDF を装ったキャンペーンでは、PDF編集ツールに見えるサイトや広告を入口に、ユーザーが CrystalPDF.exe をダウンロードして実行する流れが説明されています。Microsoft は、観測されたURL形式などから Google Ads が主な誘導手段として使われた可能性に触れています。(TECHCOMMUNITY.MICROSOFT.COM)
実行後は、AppData\Local\Temp\crys 配下へのコピー、Crystal_updater というスケジュールタスクによる永続化、攻撃者制御ドメインへの通信が発生します。一方で、デスクトップ上に置かれる別の Crystal PDF.exe は、CloudConvert 関連ドメインへ接続する正規風の機能を持つように見えるため、ユーザーや一次対応者が「ただのPDFツール」と誤認しやすい構成です。(TECHCOMMUNITY.MICROSOFT.COM)
ここでのハンティングの中心は、製品名の一致ではありません。未知のPDF変換ツールが、なぜユーザーのブラウザプロファイル、Cookie、セッションデータ、認証キャッシュに触れているのかを確認することです。
SOCが最初に見るべき検出シグナル
Microsoft Defender XDR の検出観点では、Execution、Persistence、Defense Evasion、Discovery の各段階にまたがって、PowerShellダウンロード、スケジュールタスク、ASEPレジストリ、DLLサイドローディング、プロセスインジェクション、Python実行、AutoItリネーム、WMIやプロセス探索などが整理されています。(TECHCOMMUNITY.MICROSOFT.COM)
| 優先度 | シグナル | 具体例 | 調査の切り口 |
|---|---|---|---|
| 高 | スクリプトからPowerShellが起動 | VBS、BAT、LNKからのPowerShell実行 | 親プロセス、ダウンロード先、コマンドライン、実行ユーザー |
| 高 | ユーザー領域からのローダー実行 | Temp、AppData、Downloads 配下のEXE | 署名、作成時刻、同一ハッシュの横展開 |
| 高 | ブラウザプロファイルへの不審アクセス | Chrome、Edge、FirefoxのCookie・Profile配下 | 非ブラウザプロセス、直前のインストーラー実行 |
| 中〜高 | Python / AutoIt の不自然な実行 | 業務端末で突然Python依存関係を導入 | 配置場所、親プロセス、外部通信、スクリプト拡張子 |
| 中 | スケジュールタスク作成 | updater、helper、PDF名を含むタスク | タスク名、実行対象、作成元プロセス |
| 中 | 新規・低評価ドメインへの通信 | インストーラー直後のC2接続 | RemoteUrl、プロセス名、端末群での分布 |
優先順位を付けるなら、最初に見るべきは「ブラウザデータに触る前の段階」です。Infostealer は認証情報を盗んだ後に発見しても、セッション無効化やクラウド側調査が必要になります。端末隔離だけで完了と判断しないことが重要です。
Microsoft Defender XDR Advanced Hunting で使えるハンティング起点
以下のKQLは、そのまま完成版の検出ルールではなく、SOCで初期調査を始めるための起点です。Microsoft Defender XDR の Advanced Hunting では、通常、テーブル名から始めてパイプで条件を重ねます。手動ハントでは時間範囲を絞ることで、結果を管理しやすくし、タイムアウトを避けやすくなります。なお、Kusto の時間フィルターは設定タイムゾーンに関係なくUTCで扱われます。(Microsoft Learn)
VBS・BAT・PowerShell の多段実行を探す
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("wscript.exe", "cscript.exe")
or InitiatingProcessParentFileName in~ ("wscript.exe", "cscript.exe")
| where ProcessCommandLine has_any (
"powershell",
".bat",
"DownloadFile",
"DownloadData",
"DownloadString",
"Invoke-WebRequest",
"WebClient",
"http",
"https"
)
| project Timestamp, DeviceName, AccountName,
InitiatingProcessFileName, InitiatingProcessCommandLine,
FileName, ProcessCommandLine, FolderPath, ReportId
| order by Timestamp descこのクエリは、WhatsApp悪用型のような「VBSからBATやPowerShellに進む」流れの初期確認に使えます。結果が出たら、同じ端末で直後に作成されたファイル、ネットワーク接続、スケジュールタスクを追います。
ユーザー領域からの Python / AutoIt 実行を探す
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("python.exe", "pythonw.exe", "autoit3.exe")
or ProcessVersionInfoOriginalFileName has_any ("Python", "Autoit3.exe", "AutoIt")
| where FolderPath has_any ("\\AppData\\", "\\Temp\\", "\\Downloads\\", "\\Desktop\\")
| project Timestamp, DeviceName, AccountName,
FileName, FolderPath, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine, ReportId
| order by Timestamp descPythonやAutoItは正規業務でも使われます。開発部門やRPA端末では誤検知が出やすいため、対象部署、端末ロール、署名、親プロセス、実行パスで絞り込んでください。逆に、一般事務端末で突然これらが動き、直前にPDFツールやメッセージ添付ファイルが実行されていれば優先度は上がります。
偽インストーラー由来のスケジュールタスクを探す
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType == "ScheduledTaskCreated"
| where AdditionalFields has_any (
"updater",
"update",
"pdf",
"converter",
"AppData",
"Temp",
"Crystal"
)
| project Timestamp, DeviceName, AccountName,
InitiatingProcessFileName, InitiatingProcessCommandLine,
AdditionalFields, ReportId
| order by Timestamp descスケジュールタスク名だけで決め打ちすると亜種に弱くなります。updater、helper、service のような一般的な名前と、実行ファイルの場所・作成元プロセスを組み合わせて判断します。
ブラウザプロファイルへの不審なファイル操作を探す
DeviceFileEvents
| where Timestamp > ago(7d)
| where FolderPath has_any (
"\\Google\\Chrome\\User Data\\",
"\\Microsoft\\Edge\\User Data\\",
"\\Mozilla\\Firefox\\Profiles\\"
)
| where InitiatingProcessFileName !in~ (
"chrome.exe",
"msedge.exe",
"firefox.exe",
"browser_broker.exe"
)
| where InitiatingProcessFolderPath has_any (
"\\AppData\\",
"\\Temp\\",
"\\Downloads\\",
"\\Desktop\\"
)
| project Timestamp, DeviceName, AccountName,
ActionType, FolderPath, FileName,
InitiatingProcessFileName, InitiatingProcessFolderPath,
InitiatingProcessCommandLine, ReportId
| order by Timestamp descこの観点は、Infostealer hunting の中でも優先度が高い領域です。ただし、バックアップソフト、ブラウザ管理ツール、DLP、正規EDRコンポーネントが該当する場合もあるため、既知の業務プロセスを除外リスト化してから検出化します。
カスタム検出に昇格する判断基準
Advanced Hunting で有効なクエリが見つかっても、すぐに高重大度のカスタム検出へ昇格するのは危険です。Microsoft Defender XDR のカスタム検出ルールでは、クエリ結果に Timestamp や対象資産を識別する列が必要で、頻度、ルックバック、アラート詳細、推奨アクションを設計する必要があります。継続的（NRT）頻度は迅速な検出に役立ちますが、1つのテーブルのみを参照する、joinやunionを使わないなどの条件があります。(Microsoft Learn)
| 状態 | 推奨アクション | 理由 |
|---|---|---|
| 結果が少なく、明らかに不審 | カスタム検出候補にする | SOCの初動を早められる |
| 結果が多いが業務ツールが混ざる | 手動ハントでチューニング継続 | 誤検知でSOC疲れを起こす |
| 単一テーブルで高精度 | NRT候補として検討 | 早期検出に向く可能性がある |
| 複数テーブルの相関が必要 | 定期実行または手動ハント | NRT条件に合わない場合がある |
| 特定部門だけで正規利用あり | デバイスグループや除外条件を設計 | 一律適用は誤検知・業務影響が大きい |
カスタム検出の名称は、アラートを見た一次対応者がすぐ動けるものにします。たとえば「Suspicious script-to-PowerShell chain from user download folder」のように、攻撃名ではなく観測された挙動を入れると、担当者が初動判断しやすくなります。
Microsoft Defender で優先して確認したい防御設定
Microsoft のガイダンスでは、cloud-delivered protection、EDR in block mode、network protection、web protection、SmartScreen、自動調査と修復、tamper protection、ASRルールなどが、trusted-platform abuse を使った Infostealer 対策として推奨されています。(TECHCOMMUNITY.MICROSOFT.COM)
| 防御設定 | 目的 | 導入時の注意点 |
|---|---|---|
| Cloud-delivered protection | 新種・亜種への対応力を高める | Defender Antivirus の状態とポリシー適用を確認 |
| EDR in block mode | 他社AV利用時やパッシブ構成でも悪性アーティファクトを抑止しやすくする | ライセンス、対象OS、運用設計を確認 |
| Network protection / Web protection | 危険なドメインやWeb由来脅威への接続を抑える | 業務SaaSやクラウド変換サービスを誤って止めないよう段階導入 |
| Microsoft Defender SmartScreen | フィッシング、マルウェアサイト、不審なダウンロードへの対策 | ブラウザ標準化やユーザー教育とセットで効果が出やすい |
| Automated investigation and remediation | アラート対応の自動化でSOC負荷を下げる | 自動修復の影響範囲を事前に確認 |
| Tamper protection | 攻撃者によるセキュリティ設定の無効化・変更を防ぐ | 管理変更がブロックされる場合があるため運用手順を整備 |
| ASR rules | スクリプト、実行ファイル、Office、LOLBAS系の悪用を抑える | 監査モードで影響確認後、段階的にブロックへ移行 |
ASRルールでは、難読化されたスクリプトのブロック、評価・年齢・信頼リスト基準を満たさない実行ファイルのブロック、JavaScriptやVBScriptがダウンロード済み実行コンテンツを起動する挙動のブロックなどが、今回のような攻撃チェーンと相性のよい確認項目です。Microsoft のASRルールリファレンスでは、標準保護ルールとその他のルール、対応OS、構成方法、監査からブロックへの展開手順が整理されています。(Microsoft Learn)
Tamper protection も見落とせません。Microsoft Defender for Endpoint の tamper protection は、ウイルスと脅威の防止、リアルタイム保護、クラウド保護、セキュリティインテリジェンス更新、除外設定などが攻撃者に変更されにくいよう保護する機能です。(Microsoft Learn)
SOC向け初動対応プレイブック
Infostealer の疑いがあるアラートを受けたら、端末上のファイル削除だけで終わらせないでください。認証情報やセッションが盗まれている前提で、エンドポイント、ID、クラウドサービスを横断して確認します。
| フェーズ | 実施内容 | 具体例 |
|---|---|---|
| 初期トリアージ | 親子プロセスと実行タイムラインを確認 | VBS → BAT → PowerShell → Python / MSI の流れを追う |
| スコープ確認 | 同じファイル名、ハッシュ、タスク名、コマンドラインを横展開検索 | 同一部門・同一拠点・同一広告経路で広がっていないか確認 |
| 端末封じ込め | 侵害可能性が高い端末を隔離・調査 | ブラウザプロファイル接触やC2通信があれば優先 |
| ID対応 | パスワード変更だけでなくセッション無効化を検討 | Cookie・トークン窃取を想定し、クラウド側サインインも確認 |
| 防御強化 | IOC、ASR、カスタム検出、Web/Network protection を更新 | 単発対応で終えず、再発防止ロジックに落とす |
| ユーザー通知 | クリック経路と再発防止を伝える | PDF変換ツール、広告経由ダウンロード、メッセージ添付の注意喚起 |
特に重要なのは、ID対応です。Infostealer は端末上のマルウェアを止めた後も、盗まれたセッションCookieやトークンを使ってクラウドサービスへアクセスされる可能性があります。端末対応チームとID管理チームが別組織の場合、SOCのプレイブックに「セッション無効化の連絡先」と「実施判断基準」を明記しておくと対応が速くなります。
失敗しやすいポイント
IOCだけで検出しようとする
ハッシュ、ドメイン、URLは重要ですが、trusted-platform abuse では配布経路やファイル名が変わりやすくなります。IOC照合は最後の確認として使い、検出の中心は「ユーザー領域からの不審実行」「スクリプト経由のダウンロード」「ブラウザデータへの接触」に置く方が長持ちします。
正規サービス名で安心してしまう
CloudConvert、WhatsApp、Google Ads、PDF変換といった名前が見えると、一次対応で「正規サービス」と判断されがちです。しかし攻撃者は、まさにその信頼を利用します。正規サービスへの接続があるかではなく、その前後で不審な実行ファイル、永続化、認証情報窃取の挙動があるかを見てください。
KQLを狭く作りすぎる
CrystalPDF.exe や特定のタスク名だけで検出すると、ファイル名を変えた亜種を逃します。最初は広めに取り、実行場所、親プロセス、署名、ユーザー部門、端末ロールで絞り込む方が実務では使いやすくなります。
カスタム検出を高重大度で乱発する
Infostealer hunting は重要ですが、誤検知が多いルールを高重大度で出し続けると、SOCの信頼を失います。まずは手動ハントで結果を確認し、業務ツールを除外し、検出名・説明・推奨アクションを整えてからカスタム検出化してください。
グローバルSOCでの見方
今回のパターンは、日本国内だけでなくグローバル環境でも扱いやすいテーマです。理由は、特定国の銀行名や言語に依存せず、攻撃チェーンの構造が共通しているからです。
グローバルSOCでは、次のように正規化して見ると運用しやすくなります。
| 地域差が出る要素 | 正規化して見るべき観点 |
|---|---|
| WhatsApp、LINE、Teamsなど利用アプリの違い | メッセージアプリ経由の添付・リンク後に端末で何が実行されたか |
| PDF変換、請求書、履歴書などルアーの違い | ユーザー領域で実行されたインストーラーが永続化・外部通信したか |
| 銀行・決済・暗号資産サービス名の違い | ブラウザCookie、セッション、ウォレット、認証キャッシュへの接触 |
| 広告ネットワークや検索エンジンの違い | 広告・SEO経由ダウンロード後のプロセスチェーン |
| 部門ごとの正規Python利用 | 開発端末と一般端末でベースラインを分ける |
グローバル環境では、すべての拠点に同じブロックポリシーを入れるより、まずはハンティングクエリでベースラインを取り、利用実態が見えた段階でASRやWeb/Network protectionの適用範囲を広げる方が失敗しにくいです。
次にやるべきこと
Microsoft Defender を使って Infostealer hunting を前倒しするなら、まずは次の順番で着手してください。
1つ目は、過去7〜30日分で wscript.exe、PowerShell、Python、AutoIt、スケジュールタスク、ブラウザプロファイルアクセスをハントすることです。今回の trusted-platform abuse では、最終ペイロードより前に検出できる材料が複数あります。
2つ目は、検出結果を「正規業務」「要確認」「高リスク」に分けることです。開発端末、RPA端末、管理端末、一般端末では正常な挙動が異なります。端末ロール別にベースラインを作るだけで、誤検知は大きく減ります。
3つ目は、高精度なクエリをカスタム検出やASR評価に進めることです。特に、スクリプトからのPowerShellダウンロード、ユーザー領域からの不審ローダー実行、非ブラウザプロセスによるブラウザプロファイル接触は、Infostealer hunting の早期検出に直結します。
Trusted Platform Abuse の厄介さは、入口が自然に見えることです。だからこそ、Microsoft Defender XDR では「どのサイトから来たか」だけでなく、「端末上で何が連鎖したか」を時系列で見る必要があります。SOCの次の一手は、IOCの追加ではなく、認証情報が盗まれる前の挙動を検出できるハンティングロジックを整えることです。
コメント