環境寄生型攻撃(LOLBins)の仕組みと振る舞いで見つける検知設計

環境寄生型攻撃(Living off the Land、以下LOTL)は、攻撃用のプログラムを持ち込まず、対象のシステムにもとから入っている正規のツールだけで侵入後の作業を進める手口です。PowerShellやWMIといったOS標準の機能、rundll32.exeやcertutil.exeといったOS標準の実行ファイルは、管理者が日常的に使うものであり、実行ファイルにはMicrosoftの署名も付いています。だからこそ、そこを通った攻撃はファイルの正体を見る検知だけでは見逃しやすくなります。想定読者は、SOCや情報システム部門で検知設計とログ運用にあたる実務担当者です。記述はCISAほか各国機関の共同ガイダンス、MITRE ATT&CK、Microsoftの公式ドキュメント、JPCERT/CCの資料にもとづき、事実は執筆時点(2026年8月6日)に確認できた範囲に限ります。悪用の手順やコマンドをそのまま使える形では書きません。挙動の確認は、自組織が管理する、または管理者から明示の許可を得た検証環境だけで行ってください。許可のない環境で他人のシステムに対して同様の操作を行えば、不正アクセス行為の禁止等に関する法律をはじめとする関連法令に触れる可能性があります。適用の可否は事案ごとに変わるため、判断が必要な場面では法律の専門家へ確認してください。

環境寄生型攻撃が指す範囲#

CISA、NSA、FBIを含む米国6機関と、オーストラリアのASD's ACSC、カナダのCyber Centre、英国NCSC、ニュージーランドNCSCの計10機関は、2024年2月7日に共同ガイダンス「Identifying and Mitigating Living Off the Land Techniques」を公開しました。この文書はLOTLを、システム上のネイティブなツールやプロセスの悪用と定義し、とくにLOLBins(living off the land binaries)と呼ばれる実行ファイル群を挙げています。狙いは、通常のシステム動作に紛れ込み、検知されたりブロックされたりする可能性を下げることです。ツールが既に配備され、環境内で信頼されているという事実が、そのまま隠れ蓑になります。

適用範囲は特定のOSに限りません。同ガイダンスは、オンプレミス、クラウド、ハイブリッド、Windows、Linux、macOSのいずれでもLOTLが使われると述べています。そのうえで、各機関のインシデント対応チームが観測する事例はWindows環境に偏っており、これは企業や組織での利用が広いためだと説明しています。macOSでは「living off the orchard」という呼び方があり、そこで悪用されるバイナリはLOOBinsと呼ばれます。

事例をまとめた公開データベースも複数あります。同ガイダンスが参照先として挙げているのは、Windowsを対象とするLOLBAS Project、Unix系バイナリを集めたGTFOBins、macOS向けのloobins.io、攻撃者がセキュリティ機構の迂回に使うWindowsドライバを脆弱なものと悪性のものの両面から収録するloldrivers.ioです。LOLBASの収録基準は明確で、Microsoftが署名したファイルであること、本来の用途から外れた予期しない機能を持つこと、そしてAPTやレッドチームにとって有用な機能であることの3点を満たす必要があります。想定どおりの使い方を記録することには意味がない、と基準そのものに書かれています。

共同ガイダンスは、LOTLが効果的である理由として次の3点を挙げています。多くの組織が基準線などの管理実務を持たないため、正規の挙動と悪意ある挙動を区別できないこと。活動に伴う従来型のIOCがそもそも乏しく、追跡と分類が難しいこと。そして攻撃側が独自ツールの開発と配布に投資せずに済むことです。

正規バイナリが攻撃者に選ばれる理由#

攻撃側の利点は、検知回避だけではありません。共同ガイダンスが指摘するとおり、独自マルウェアを作らずに済むこと自体がコスト面の利点になります。開発したツールは検体として採取され、ハッシュやシグネチャが共有され、いずれ使えなくなります。標準ツールは、検体のハッシュが共有されたからといって直ちに使えなくなるものではありません。ただし後述するwmic.exeのように、非推奨化や既定でのプリインストール終了によって使える範囲が変わることはあります。

防御側から見て厄介なのは、これらのバイナリが本当に業務で使われている点です。同ガイダンスは、LOLBinsはIT管理者が正当に使うものであり、ファイルハッシュやデジタル署名といった信頼された属性を持つため、防御側が「すべての利用者にとって安全だ」と誤解しやすいと書いています。そして、正規の管理ツールだから全社的に許可してよいという考え方をよくある誤解と呼び、共通のLOLBinsに対する一律の許可ポリシーは攻撃面を広げると述べています。CISAのレッドチームは、標準権限の利用者にまでLOLBinsが開放されている状態を頻繁に見つけているとも記されています。

もう1つの前提として、共同ガイダンスが扱うLOTLは、攻撃者が足場を得たあとの実行、探索、横展開、認証情報の取得、永続化を進める段階が中心です。ただし初期侵入の局面と無縁なわけではなく、MITRE ATT&CKのT1218.005は、mshta.exeが初期侵害の段階とコード実行の両方で悪用された事例が複数あると記載しています。共同ガイダンスは、インターネットに面したサービスの悪用で最初の足がかりを得た攻撃者が、初期実行や偵察、二次ペイロードの展開にLOLBinsを使うことが多いとして、DMZ内の公開サーバのような危険性の高いホストに追加の注意を払うよう求めています。

従来型のシグネチャ検知が届かない構造#

シグネチャ検知は、悪意あるファイルを特定できることを前提に組み立てられています。LOTLはその前提を外します。実行されるのは正規のバイナリであり、ディスクに新しい実行ファイルが落ちないことも珍しくありません。実行ファイルのハッシュ照合や署名検証は、その正規バイナリを通してしまいます。検知の手がかりは、持ち込まれたペイロードやコマンドの内容、メモリ上で復元されるスクリプト、プロセスの振る舞いの側に残ります。

共同ガイダンスは、成熟した組織でも切り分けが難しい理由を、防御側の体制の問題として整理しています。挙げられているのは、セキュリティ担当がIT部門やその運用フローと分断されたサイロで動いていること、チューニングされていないEDRと個別のIOCに依存していること、既定のログ設定のままで詳細な情報を取れていないこと、そして大量のログの中から相対的にわずかな悪意ある活動を見つけ出すのが難しいことです。

回避のしやすさも具体的に書かれています。攻撃者はファイル名、ファイルパス、コマンド&コントロールの宛先といった一般的なIOCを容易に変えられます。文字列の変更でハッシュも変わります。さらに、コマンドライン引数の別表記や環境変数を使った表記も使われます。同ガイダンスはntdsutil.exeの例を挙げ、正式な引数を並べた命令列と、それを短縮した表記のどちらでも同じ動作になると説明しています。文字列の完全一致で検知ルールを組めば、短縮形で素通りします。

EDR側の事情も無関係ではありません。同ガイダンスは、EDRベンダーがLOLBinsを安全とみなす場合があること、管理者が自分のツールをブロックされることを嫌って標準構成での許可を求める場合があることを指摘しています。導入したから見えるようになる、という順序では進みません。

実行を肩代わりさせる正規バイナリの機構#

MITRE ATT&CKは、信頼された署名済みバイナリを悪用して悪意あるコンテンツを実行する手口を、T1218 System Binary Proxy Executionとして整理しています。執筆時点のattack.mitre.orgでは、この戦術区分はStealth(TA0005)です。サブテクニックは14個あり、Compiled HTML File(T1218.001)、Control Panel(T1218.002)、Mshta(T1218.005)、Msiexec(T1218.007)、Regsvr32(T1218.010)、Rundll32(T1218.011)、MMC(T1218.014)などが含まれます。検知の指針としては、rundll32.exe、msiexec.exe、regsvr32.exeといった信頼されたMicrosoft署名バイナリが、外部にホストされたもの、署名されていないもの、疑わしいペイロードを実行するために使われていないかを監視するよう書かれています。

なぜこれらのバイナリが選ばれるのかは、それぞれが持つ機能に由来します。rundll32.exeは、DLL内のエクスポート関数を名前で指定して呼び出すためのツールです。T1218.011は、DLLペイロードの実行に使われることに加え、shell32.dllの文書化されていない関数を経由してコントロールパネル項目のファイルを実行できること、JavaScriptのようなスクリプトの実行にも使えることを挙げています。関数名の解決時にワイド文字版としてWを、ANSI版としてAを付けた名前も探しに行く仕様があり、これが意図を隠すために使われるとも記載されています。

regsvr32.exeは、OLEコントロールやDLLを登録するためのツールです。T1218.010が説明する「Squiblydoo」と呼ばれる手法は、このバイナリのネットワーク対応を利用してURL経由でリモートのCOMスクリプトレットを読み込みます。COMオブジェクトが実際には登録されず実行だけされるため、レジストリを変更せずに済みます。同ページは、Windowsが正規の操作でregsvr32.exeを使うことによる許可リスト登録や誤検知を理由に、セキュリティ製品がこのプロセスの実行や読み込んだモジュールを監視対象にしていない場合があるとも述べています。

mshta.exeは、HTAファイルを実行するためのバイナリです。共同ガイダンスは、HTAをブラウザの外でInternet Explorerのモデルと技術を使って動作する独立したアプリケーションと説明しています。ブラウザの外側でスクリプトが動くという性質が、そのまま実行経路として使われます。

共通するのは、これらがいずれも「外部から与えられたものを読み込んで実行する」機能をもともと持っている点です。攻撃者が新しい脆弱性を見つけたわけではなく、設計どおりの機能を目的外に使っています。修正プログラムで塞ぐ種類の問題ではないため、対処は使い方の制限と観測に寄ります。

スクリプトインタプリタとWMIが持つ実行経路#

MITRE ATT&CKのT1059 Command and Scripting Interpreterは、コマンドやスクリプトの解釈実行系そのものを扱うテクニックで、戦術区分はExecutionです。サブテクニックにはPowerShell(T1059.001)、Windows Command Shell(T1059.003)、Unix Shell(T1059.004)、Python(T1059.006)、JavaScript(T1059.007)などが並びます。検知の方向性としては、管理作業の時間帯から外れた実行、通常と異なる利用者コンテキスト、難読化された引数、二次的な実行チェーンといった、普段と違う実行パターンの監視が挙げられています。

Windows Management Instrumentation(WMI)は、T1047として別建てで整理されています。WMIは管理データと操作のための基盤であり、DCOM(TCP 135番)やWinRM(5985番と5986番)を通じてローカルとリモートの双方から利用できます。ここが横展開に使われる理由です。なお、wmic.exeの扱いは変わりつつあります。Microsoftの公式ドキュメントは、WMICユーティリティをWindows 10 version 21H1およびWindows Serverの21H1リリースで非推奨とし、WMI向けのWindows PowerShellへの置き換えを案内しています。2024年1月の更新では次のWindowsリリースでWMICのFeature on Demandを既定で無効にするとされ、Windows 11 version 24H2以降は既定でプリインストールされません。非推奨の対象はコマンドラインユーティリティであり、WMI自体は影響を受けないとも明記されています。緩和策としては、ASRルールによるWMI由来のプロセス生成のブロック(M1040)、App Control for Business(WDAC)によるwmic.exeの実行制限(M1038)、リモートWMI接続の管理者への限定(M1018)が挙がっています。検知はプロセス生成、コマンド実行、リモートの場合はそれに対応するネットワーク接続という複数イベントの連鎖として組むよう書かれています。

WMIは永続化にも使われます。T1546.003は、イベントフィルタ、プロバイダ、コンシューマ、バインディングを登録し、定義したイベントが起きたときにコードを実行させる手口です。実行はWMIプロバイダホストプロセス(WmiPrvSe.exe)によって代理されるため、SYSTEM権限に昇格した状態になる場合があります。検知の指針は、EventFilter、EventConsumer、FilterToConsumerBindingの各オブジェクトの生成の監視、mofcomp.exeのコマンドライン実行、PowerShellのRegister-WmiEventの使用、WmiPrvSE.exeの想定外の子プロセスです。独立したペイロードファイルやレジストリの自動起動キーを使わずに永続化できるため、実行ファイルと自動起動キーだけを見る点検では見落とします。Microsoftのドキュメントは、永久イベントコンシューマがWMIリポジトリに実装され、作成後は再起動をまたいでイベントを受け取り続けると説明しており、確認はWMIのオブジェクトと関連イベントの側で行うことになります。

PowerShellについては、ログの取り方が検知の可否をほぼ決めます。Microsoftのドキュメントは、スクリプトブロックログを有効にするとPowerShellが処理するすべてのスクリプトブロックの内容を記録すると説明しています。Windows PowerShell 5.1のabout_Loggingでは、Microsoft-Windows-PowerShell/Operationalログにイベント4104として記録されるとされています。PowerShell 7系のログは別記事のabout_Logging_Windowsが扱っており、そちらではPowerShellCore/Operationalログに同じ4104が記録されるとされています。有効化はグループポリシーの「Turn on PowerShell Script Block Logging」またはレジストリで行います。同時に注意も書かれており、ログの詳細度を上げると認証情報などの機微な内容がイベントログに書かれる可能性があるため、診断以外の目的で使う場合はProtected Event Loggingの併用が推奨されています。この仕組みはCMS標準の公開鍵暗号でログ内容を暗号化するもので、復号用の秘密鍵はログを出す端末側に置かず、集約先の安全な場所で保持します。

標準ツールに備わるダウンロード機能#

外部からファイルを持ち込む段階も、標準ツールで賄えます。MITRE ATT&CKのT1105 Ingress Tool Transferは、Command and Control戦術に分類され、ネイティブなユーティリティを使った転送を具体的に列挙しています。Windowsではcopy、finger、certutilといったユーティリティがツールの取得に使われること、PowerShellのInvoke-WebRequestやWebClient経由の取得が使われること。LinuxとmacOSではcurl、wget、scp、sftp、tftp、rsync、fingerが挙がっています。BITSAdminはBITSジョブを作ってアップロードとダウンロードの両方を行えるとされ、ftpも同様に悪用されうると書かれています。パッケージマネージャやクラウド同期サービスを経由する形も記載されています。

certutilは本来、証明書と証明書ストアを扱うためのツールです。ダウンロード以外に、T1140 Deobfuscate/Decode Files or Informationでも登場します。同ページは、証明書ファイルの中に隠された遠隔操作ツールの実行ファイルをcertutilでデコードする例や、base64でエンコードされたペイロードのデコードにcertutilのデコード機能が使われた事例を挙げています。ダウンロードとデコードという2つの機能が1つの署名済みバイナリに揃っているため、外部からの持ち込みが一連の操作で完結します。

BITSはさらに独特の性質を持ちます。T1197 BITS Jobsによれば、BITSはCOM経由で提供される低帯域の非同期ファイル転送機構で、PowerShellやBITSAdminツールから利用できます。回避に寄与する要素として、BITSタスクがBITSジョブデータベース内で自己完結し、新しいファイルやレジストリの変更を伴わないこと、ホストのファイアウォールで許可されている場合が多いこと、ジョブの既定の最大寿命が90日で延長も可能なことが挙げられています。実行はsvchost.exeの下で行われるため、プロセス名だけを見ても判別できません。検知の方向としては、BITSジョブの作成と変更、BITSが開始したHTTP(S)やSMBの転送、svchost.exeから起動される通知コマンド、そしてBITS-Clientの運用ログとプロセス生成やネットワーク接続との相関が示されています。

運用管理ツールが同じ問題を抱える理由#

OS標準のバイナリだけが対象ではありません。共同ガイダンスは、攻撃者がサードパーティ製のリモートアクセスソフトウェアも同じように使うとして、RMM、エンドポイント構成管理、EDR、パッチ管理、MDM、データベース管理ツールを挙げています。これらはネットワーク内の全クライアントに対してコマンドを実行する機能を持ち、ドメインコントローラのような重要なホストも対象に含みます。管理という目的のために高い権限を必要とする以上、乗っ取られたときの到達範囲も広くなります。

付録Bはさらに細かく整理しています。MDMは数千台のモバイル端末への昇格されたアクセスを提供するため狙われること。RMMやSCCMは監視と操作の能力が大きく、永続化と横展開に使われること。パッチ管理システムは数千台へのアクセス経路になること。EDR自体もリモートシェル機能を悪用される対象であること。仮想化管理ツール、ネットワーク管理システム、IAM、ITSMも同様に挙げられています。

対処の方向は、種類を絞ることです。同ガイダンスは、ネットワーク内で使う管理ツールを最小限の一組に選定し、そこに詳細なログを設定したうえで、それ以外はブロックまたはアラートの対象にするよう求めています。これにより防御側が見るべきノイズが減り、観測された挙動についてより詳しい情報が得られます。リモートアクセスソフトウェアについても、現在使われているものと承認されているものを棚卸しし、必要としないものは無効化してアラートを出すよう書かれています。

正規利用と悪用を切り分けるための文脈#

LOTLの検知が扱うのは、ファイルではなく文脈です。同じrundll32.exeの実行でも、誰が、どのプロセスから、どこにあるファイルを、どんな引数で、いつ動かしたかで意味が変わります。共同ガイダンスも、単一の指標でLOTLを見分けられることはまれで、複数の指標の集まりが全体像を描くと書いています。実務では、次のような軸を組み合わせることになります。

1つ目はプロセスの親子関係です。同ガイダンスは、Officeアプリケーションがcmd.exe、PowerShell、wscript.exe、cscript.exeを起動する連鎖を追跡するよう求め、WordやExcelがこれらを起動するのは通常ではないと述べています。単独で見れば何でもない探索系コマンドも、Officeアプリケーションから起動されれば異常であり、調査に値するという整理です。LinuxではvimやgeditのようなテキストエディタがcurlやSSHを起動するプロセスツリー、macOSではPagesやNumbersがbashやzsh、Pythonを起動する挙動が同様の例として挙げられています。

2つ目は実行元のパスとファイル名です。Windowsのイベント4688のドキュメントは、New Process NameやCreator Process Nameが標準的なフォルダ(System32やProgram Files)の外にある場合や、制限すべきフォルダにある場合を監視できると書いています。名前の偽装への対処も示されています。共同ガイダンスは、多くのMicrosoft製ユーティリティについてPEヘッダに元のファイル名が入っているため、OriginalFileNameを使えばnet.exeをnet2.exeに変えたような改名を見つけられると述べています。

3つ目は引数です。イベント4688にコマンドラインを含めるには、グループポリシーの「Include command line in process creation events」を有効にする必要があり、既定ではProcess Command Lineフィールドは空です。有効化したうえで、難読化の兆候を見ます。同ガイダンスが挙げるのは、エスケープ文字の多用、コマンドの連結、環境変数の過剰な使用、base64エンコードです。前述のとおり、引数の短縮形も想定しておく必要があります。

4つ目は時間帯と利用者ロールです。同ガイダンスは、通常の業務利用者はコマンドプロンプトを開いてipconfigを実行しないと書き、侵害されたアカウントであればそれが起こりうると対比しています。認証ログについては、勤務時間や休暇予定と矛盾するアクセス、短時間に集中した試行のあとの成功、通常と異なる経路、地理的に離れた場所からの同時サインインを異常の例として挙げています。ドメイン管理者権限のアカウントはドメインコントローラ以外にログインすべきではない、という基準の置き方も示されています。

5つ目は自動処理の輪郭です。サービスアカウントやスキャナのような自動化された仕組みは、高権限で一見すると疑わしい動作を繰り返します。同ガイダンスは、これらの利用が時間帯、送信元と宛先のホスト、影響を受けるアカウントによって予測可能な範囲に収まるべきだと述べています。輪郭を定義しておかないと、正規の自動処理がアラートを埋め尽くします。

これらの軸を成立させる前提が、基準線です。同ガイダンスは、LOLBinsについても基準線を作って変化を監視するよう求め、あるLOLBinが使われるとしても常に特定のコマンドラインや特定の利用者と結び付いている場合がある、という例を挙げています。その外側で使われたときにアラートを出せるかを評価し、観測された実行を調査する、という組み立てです。

ログ取得の設計順序#

観測できないものは検知できません。共同ガイダンスの検知に関する推奨は、詳細なログの取得と、攻撃者が改ざんできない集約先への転送から始まっています。ログの改ざんや削除を避けるため、帯域外の中央集約先に置くこと、そして中央集約により保持期間を延ばせることが理由として挙げられています。日本語の資料では、JPCERT/CCが「ログを活用したActive Directoryに対する攻撃の検知と対策」でイベントログの確認ポイントと環境改善の運用方法を整理しており、Windowsイベントログの分析トレーニング用コンテンツも公開しています。

Sysmonについては、Microsoftのドキュメントが記録できる内容を明示しています。プロセス生成(イベントID 1)では現在のプロセスと親プロセスの完全なコマンドラインが記録され、プロセスGUIDによってPIDが再利用されてもイベントを相関できます。ネットワーク接続(3)は既定で無効、イメージ読み込み(7)も既定で無効で、後者はすべてを記録すると大量のログが出るため慎重な設定が必要と書かれています。ファイル作成(11)、レジストリの作成と削除および値の設定(12と13)、WMIのフィルタとコンシューマとバインディング(19、20、21)、DNSクエリ(22)も揃っており、前述の観測軸をほぼ覆えます。出力先はApplications and Services Logs/Microsoft/Windows/Sysmon/Operationalです。

ルールの粒度にも注意が要ります。共同ガイダンスは、コマンドライン全体を対象にするような広すぎる検知ルールを避けるよう明記し、これは包含ルールにも除外ルールにも当てはまるとしています。除外が広いと、そこが素通りの経路になります。

実行そのものを狭める抑止の設計#

検知だけで受け止めるには、標準バイナリの数が多すぎます。共同ガイダンスのハードニング推奨は、アプリケーション許可リストによって実行環境を制約し、業務ロールごとに構成することを挙げています。狙いは、利用者と管理者の活動を監視しやすい狭い経路へ通し、振る舞い分析の効果を高めてアラート量を絞ることです。Windowsについては、AppLockerとWindows Defender Application Control(App Control for Business)により、実行ファイル、スクリプト、MSIファイル、DLL、パッケージアプリ形式を規制でき、ファイル名、バージョン、発行元、パスといった属性でルールを作れると書かれています。

許可リストを敷いても、そこを迂回できるバイナリが残ります。Microsoftはこの問題を認識しており、App Controlを迂回しうる正規アプリケーションの一覧と推奨ブロックルールを公開しています。同ページは、利用シナリオが明示的にそれらを必要としない限りブロックすることを推奨するとしたうえで、設計上ほかのコードを実行できるアプリケーションは、業務上どうしても必要でない限りApp Controlポリシーでブロックすべきだと述べています。掲載されているのはcscript.exe、wscript.exe、mshta.exe、wmic.exe、msbuild.exe、bash.exe、wsl.exe、csi.exe、windbg.exe、dotnet.exe、system.management.automation.dllなど多岐にわたります。同ページは、PowerShellモジュールにApp Controlを迂回できる問題があったことに触れ、最新のセキュリティ更新の適用も求めています。

PowerShellは、アプリケーション制御と組み合わせたときに動作が変わります。Microsoftのドキュメントは、システムのアプリケーション制御ポリシーの下で動作している場合、PowerShellが自動的にConstrainedLanguageモードで実行されると説明しています。検出対象となるポリシーはAppLockerとWDACです。ConstrainedLanguageモードは、ループや条件分岐、文字列展開、オブジェクトのプロパティ参照といった基本的な言語要素を残しつつ、悪用されうる操作を制限します。同ドキュメントの説明では、すべてのコマンドレットとPowerShell言語要素の一部が使える一方で、使用できるオブジェクトの型が限定されます。Add-Typeは署名済みアセンブリを読み込めますが任意のC#コードやWin32 APIは読み込めず、New-Objectは許可された型に限られます。悪用されうるPowerShell、.NET、COMのAPIに手が届かない状態にしつつ、対話的なシェルとしては使えるようにするという設計です。同ドキュメントは、ConstrainedLanguageモードを迂回されないようにするため、App Control for BusinessのSystem Lockdownモードと組み合わせて使う必要があるとも明記しています。ポリシーが信頼したスクリプトはFullLanguageモードで動くため、業務スクリプトを署名して通す運用と両立します。

スクリプトの内容を見る仕組みとしてはAMSIがあります。Microsoftのドキュメントは、AMSIをマシン上に存在する任意のマルウェア対策製品とアプリケーションを連携させるためのインタフェース標準と説明し、ファイル、メモリまたはストリームのスキャン、コンテンツのURLやIPの評判確認といった技術に対応するとしています。Windows 10で統合されているコンポーネントとして挙げられているのは、UAC(EXE、COM、MSI、ActiveXのインストールの昇格)、PowerShell(スクリプト、対話的な利用、動的なコード評価)、Windows Script Host(wscript.exeとcscript.exe)、JavaScriptとVBScript、OfficeのVBAマクロです。難読化されたスクリプトも、実行時には解釈可能な形に戻る必要があるため、その時点の内容を見られる点が要になります。

攻撃面の減少(ASR)ルールにも、LOTLに直接関わるものがあります。Microsoftのドキュメントは、ASRルールをMicrosoft Defender Antivirusの機能と位置づけ、Microsoft Defender for EndpointがMicrosoft Intune、Microsoft Configuration Manager、Microsoft Defenderポータルを通じた集中管理とレポート、アラートを提供すると説明しています。標準保護ルールには「Block persistence through WMI event subscription」と「Block credential stealing from the Windows local security authority subsystem」が含まれます。そのほかに「Block all Office applications from creating child processes」「Block JavaScript or VBScript from launching downloaded executable content」「Block execution of potentially obfuscated scripts」「Block process creations originating from PSExec and WMI commands」「Block use of copied or impersonated system tools」が用意されています。

不要なものを減らす方向も有効です。共同ガイダンスは、各ホストの構成、ポリシー、インストール済みソフトウェアの棚卸しを作り、そのホストに不要なソフトウェアはアンインストールして攻撃者が使えるツールを減らすよう求めています。MITRE ATT&CKのT1218も緩和策としてDisable or Remove Feature or Program(M1042)を挙げています。あわせて、外向き通信の制限も効きます。同ガイダンスは、バックエンドサーバ、とくにデータベースやドメインコントローラはインターネットアクセスを必要としないとして、既定で制限することが多くの初期ペイロードを防ぐと述べ、対応するDNSクエリのないIPアドレスへの生の接続を探すことも挙げています。

検知しきれない前提で組む運用#

共同ガイダンスは、LOTLの活動を完全に防いだり検知したりする万全の解決策は存在しないと明記しています。推奨事項も、それぞれ単体ではなく組み合わせて実施することで効果が出るという位置づけです。運用側の設計も、その前提に立って組むほうが破綻しません。

アラートのノイズ低減は、検知力そのものと同じ比重で扱われています。同ガイダンスは、監視ツールとアラート機構を調整して通常の管理作業と脅威の挙動を区別すること、リモート認証の活動を相関させて異常値を見つけることを求めています。ITチームと協調してネットワーク内で許可する管理ツールとログオンタイプの種類を減らすこと、ホストの用途と利用者を考慮することも挙げられています。組織が必要としないリモートアクセスツールについては、インストールと使用を無効化してアラートを出す方針です。

防御側の設定情報そのものが狙われる点にも触れられています。同ガイダンスは、攻撃者が防御側の設定を読んで手口を調整する可能性があるとして、Sysmonのルールが既定でグローバルに読み取り可能なレジストリキーに置かれ、Sysmon.exeで解析できることを例に挙げています。設定の読み取り、監視ソフトウェアの無効化、ログ成果物の改ざんの試みを監査するよう求めています。

長期的な方向としては、ゼロトラストアーキテクチャの実装が推奨されています。同ガイダンスは、ゼロトラストの原則を適用することで、バイナリとそれを使うアカウントが自動的に信頼されない状態になり、利用が制限され、信頼できる挙動かどうかを確認するために検査されるようになると説明しています。バイナリが署名されているという事実と、その実行が正当であるという判断を切り離す考え方です。

現状を点検するチェックリスト#

まとめ#

環境寄生型攻撃が難しいのは、技術的に高度だからというより、防御側が長く頼ってきた「悪いファイルを見つける」という判定軸が使えなくなるからです。実行されるバイナリはMicrosoftの署名を持ち、ディスクに新しい実行ファイルが残らない場合もあり、引数の表記を変えるだけで文字列一致のルールは外れます。共同ガイダンスが基準線の欠如を最初に挙げているのは、比較対象がなければ異常も定義できないためです。

打てる手は3方向に分かれます。1つは、プロセス系譜と実行元パス、引数、時間帯、利用者ロールを記録して、平常時との差を見られるようにすること。1つは、管理ツールの種類を絞り、アプリケーション制御と制約言語モード、推奨ブロックルールで実行できる経路そのものを狭めること。もう1つは、権限とネットワークの範囲を切って、正規の資格情報が取られたときの到達先を限ることです。どれも単体では足りず、順に積み上げる作業になります。自組織のOS構成と管理ツールで実際に何が取れて何を止められるかを確かめながら進めてください。検証は許可された環境だけで行い、関連法令の範囲を外れないよう気をつけてください。