2024年1月26日

NECサイバーセキュリティ戦略統括部　セキュリティ技術センターの竹内です。

2023年10月、米国のCISAがLogging Made Easy（LME）[1]と呼ばれるツールを公開しました。このツールは小規模な組織において、主要なWindowsイベントログを集約し、攻撃を検知することを目的としたツールです。
CISAが公開しているチュートリアルでは、ログの集約方法、Sysmonのインストール方法、ELK Stack※ [2]の構築方法、集約したログを監視するためのKibana上で使用するダッシュボード構築手順を展開しています。

LMEではELK Stackを使って解析を行う方法が示されていますが、それに加えてHayabusa [3]も使用することで更なる効率化が行えると考えました。そこで、本ブログでは「LMEを用いて集約したWindowsイベントログをHayabusaで解析した結果」と「各Windowsホスト上でHayabusaを実行した結果」を比較し、LMEで集約したログをHayabusaで活用する際の課題そしてその解決方法について紹介します。

ブログで紹介する内容について

今回のブログで紹介する内容は以下の通りです。

Logging Made Easy（LME）について

Logging Made Easy（LME）は、CISAが提供する主要なWindowsイベントログを収集し、攻撃を検知するための機能を提供するツールです。

LMEのインストールはChapter1-4という形でGitHubのリポジトリに公開されています。それぞれのChapterで実施する内容は次の通りです。

本ブログではChapter1のWindows Event Forwardingの設定を実施した後、WEC上でHayabusaを実行して、不審なログの解析を行います。

Hayabusaについて

Hayabusaは日本のYamatoSecurityグループによって作られたWindowsイベントログのファストフォレンジックタイムライン作成および脅威ハンティングツールです [3]。Hayabusaの使用方法や活用例については公式のREADME [4]をはじめ、様々なブログ[5] [6]でも紹介されているため、本ブログでは割愛します。

Hayabusaは実行時のオプションとして「-l」もしくは「--live-analysis」を付けることで、Hayabusaを実行する端末上のイベントログフォルダを解析できます。このオプションを使用して、LMEで集約したWEC上のWindowsイベントログの解析を行います。

LMEでのHayabusa活用検証

LME環境の作成と検知ログ生成のためのアクション

まずはLMEの環境を作成する必要があります。LMEの環境には、「ADの管理端末」、「クライアント端末」、「ログ集約する端末」の最低3台のマシンを用意する必要があります。検証用途であればAutomatedLab [7]を使用することで容易に準備可能です。本ブログはAutomatedLabでマシンを作成した後、LMEのChapter1の手順を実施した環境で検証しています。AutomatedLabのスクリプトについては参考までに本ブログ末に記載しています。

次にHayabusaでWindowsイベントログを解析するため、事前にクライアント端末に対して疑似的な攻撃を行い、クライアント端末のWindowsイベントログに不審なアクティビティが記録される状況にします。そのため、同じネットワーク上にKali LinuxのVMを作成します。最終的に図 2の環境を用意しました。

今回は疑似的な攻撃としてHydraを使用したRDPに対するBrute forceのログイン試行とISO-Bypass試行 [8]を行います。

Hydraを使用したRDPに対するBrute forceのログイン試行

Kali LinuxにデフォルトでインストールされているBrute forceツールである「Hydra」[9]を使用して、Client端末へのログイン試行を行います。以下のコマンドを実行することでsmbに対するブルートフォースが可能になります。passwordlist.txtには20個ほどのパスワードを事前に記載しておきます。

このログイン試行を行うことにより、クライアント端末上にログイン失敗のイベントログが記録されます。

ISO-Bypass試行

ISO BypassはAdversary Emulation Library [10]のMicro Emulation Planとして紹介されている攻撃です。攻撃者がフィッシングメール等で添付した悪意のあるペイロードをユーザに実行させることをエミュレートしたものとなります。

このISO Bypassでは以下の流れで攻撃を行います。

この試行を行うことで、Microsoft-Windows-Powershell/Operationalイベントログに不審な操作が記録されます。

WECでのHayabusa実行結果と各クライアントPC上でのHayabusa実行結果の比較

Hayabusaは以下のコマンドで実行した結果を比較しています。前述したように「-l」オプションを使用することで、Hayabusaを実行している端末のイベントログを解析します。また「-o」オプションで出力先のファイルを指定します。

brute forceログイン試行後のHayabusaの実行結果比較

Brute forceの攻撃試行はKali LinuxからClient2に対して行いました。
図 3はブルートフォースログインを試行されたClient2端末でのHayabusaの実行結果、図 4はログを集約するWEC端末でのHayabusaの実行結果です。ログイン失敗を示す「Logon failure」を両ホストのHayabusaで検知していることが分かります。

ISO Bypass試行のHayabusa実行結果比較

ISO Bypass施行はClient1端末に、ファイルをコピーし実行しました。
図 5はClient1端末でのHayabusaの実行結果、図 6はWEC端末でのHayabusa実行結果です。図 5では「Suspicious Mount-DiskImage」として、ISO Bypass試行が検出できていることに対し、図 6では直前の「Logon（Network）」「Logoff」は同じですが、PowershellやWMIの痕跡は検出できていません。

この検出できていない事象は、Hayabusaの問題ではなく、WECに転送されたログにPowershell ScriptやWMIが含まれていない（Client1からWECに転送されていない）ことにあります。LMEでは主要なログのみと記載されているように、デフォルト設定では転送されていないログがあります。LMEの設定を調整することで、WECに転送しHayabusaでの解析をさらに効率化することができます。

Event Forward設定の修正とHayabusaの再実行

LMEでのイベントログの収集はWindowsイベントログ転送（WEF）と呼ばれる標準機能 [11]が使用されています。 このイベントログ転送では指定したログのみを転送することが可能となっており、LMEでは「lme_wec_config.xml」[12]に記載されているログを転送するようになっています。「lme_wec_config.xml」を確認すると、図 7のようにログオン・ログオフやシステム時刻の変更、Windows Defenderのログなど、主要なログは転送されるようになっています。

しかし、Hayabusaはこのファイルで転送設定されているイベントログ以外も解析可能です。

本ブログでは、Microsoft-Windows-Powershell/Operationalのログを転送し、WEC上でHayabusaを実行した際にISO-Bypassが不審なアクティビティとして出力できるようにxmlファイルを修正します。

Event Forwardの設定の変更方法はlme_wec_config.xmlを編集し、「wecutil」コマンドで再読み込みさせる手法と、Windowsの「Event Viewer」アプリケーション上で直接編集する手法の2通りあります。

wecutilコマンドで修正する方法

はじめに、lme_wec_config.xmlの修正を行います。lme_wec_config.xmlの先頭付近にある「<SubscriptionType>SourceInitiated</SubscriptionType>」を図 8のようにコメントアウトします。その後、「QueryList」内に転送したいイベントログを追記します。

<Query>はXPath式で記入します [13]。例えばSecurity.evtxのイベントログのうち、イベントIDが4624かつネットワークログオンタイプが10のログを転送したい場合は次のようなQueryとなります。

今回は「Microsoft-Windows-Powershell/Operational」のイベントログのイベントID「4103～4106」のログを転送させます。そのため以下の様なQueryになります。

なお、詳細なイベントの選択方法は以下の文献が参考にできると思います。
Microsoft | Event Selection
https://learn.microsoft.com/en-us/previous-versions//aa385231(v=vs.85)

また、Event Viewerアプリケーションのフィルターを使うことで簡単なXMLは作成可能です。図 9のようにイベントIDとして「4624」、コンピュータとして「Client1.lme.local」を記載した後、上のタブにある「XML」を選択することで、当該条件のXMLを作成することができます。

XMLの修正後は、「wecutil」コマンドで設定を反映させます。以下のコマンドを実行することで設定が反映されます。

このコマンドで何も出力されなければ、設定の反映は完了しています。設定した内容は以下のコマンドで確認できます。

Event Viewerアプリケーション上で修正する方法

Event Viewerアプリケーションのプロパティ画面からも、修正することができます。Event Viewerアプリケーションを起動したら、「Subscriptions」を選択し、中央の画面から「lme」を選択します。右下に表示される「Properties」もしくは、「lme」を右クリックして「Properties」を選択することでプロパティ画面へ移動できます。

プロパティ画面から、「Select Events」を選択すると、Query Filterという画面でXMLを編集することができます。Queryの記入は、wecutilコマンドを使う際と同様にXPath式で記入します。

修正が完了するとイベントログの転送が行われます。今回は検証中にログの保存サイズを超過してしまい転送の処理に不具合が生じた(※1)ため、再度ISO-Bypass試行およびHayabusaを実行しました。その結果は図 9、図 10のようになりました。

修正後はPowershellのイベントID4104が転送されるようになったため、Client1、WECの両ホスト上でPowershellの痕跡をHayabusaで検知していることが分かります。なお、WMIのイベントはまだ転送していないため、検知されていません。

LMEとHayabusaを組み合わせる場合は、Hayabusaでどこまでのログを解析してほしいかということを念頭に置いたうえで、転送するログを増減させることで効率的な解析が可能になると思います。

おわりに

CISAが提供するLMEでログを集約し、Hayabusaで解析を行う手順と改善手法について紹介しました。Hayabusaで効率的に解析を行うためにはWECに転送するログの量を増やせばよいですが、端末台数が増えるとWEC上で保存するログの量も増えていきます。本ブログではログの増加量までは検証できていませんが、十分なディスクサイズを確保する、ログローテーションを行うといったことで対策はできると思います。本ブログがLMEの使用を考えている方への助けとなれば幸いです。

参考文献

付録：使用したAutomatedLab Scripts

本スクリプトは検証時のみにご使用ください。

執筆者の他の記事を読む