サイト内の現在位置

LME × Hayabusa - Windowsイベントログの集約と解析の効率化

NECセキュリティブログ

2024年1月26日

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

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

  • ELK StackとはElastic社が提供するElasticsearch、Logstash、Kibanaなどのソフトウェアで構成される検索プラットフォームです。

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

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

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

  • Logging Made Easy(LME)について
  • Hayabusaについて
  • LMEでのHayabusa活用検証
    • LMEの環境作成と検知ログ生成のためのアクション
    • WECでのHayabusa実行結果と各クライアントPC上でのHayabusa実行結果の比較
    • Event Forward設定の修正とHayabusaの再実行

Logging Made Easy(LME)について

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

図 1 CISA:event forwarding_overview new window[1]

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

  1. Windows Event Forwardingの設定
    Active DirectoryのグループポリシーとWindowsのEvent Forwardingの機能を用いて、ログ収集を行う端末(WEC※)にログの転送設定を行う方法が記載されています。
    • Windows Event Collectorの略で、イベントログを集約するホスト名を指します。
  2. Sysmonのインストール
    ログ収集を行う端末に一括でSysmonをインストールする方法が記載されています。
    このChapterまで実施することで、ログ収集を行う端末(WEC)に主要なWindowsイベントログとSysmonのログが集約されます。
  3. ELKスタックのインストールとログの取得
    WECに集約したログをELK基盤で解析を行うために、ELK基盤の作成方法およびイベントログの転送手法について記載されています。
  4. インストール後のアクション
    Chapter3まで実施したことで、集約したログをKibanaで可視化することができるようになります。このChapterではその後の解析や攻撃検知を容易にするためのダッシュボードの作成やアラートの作成方法が記載されています。

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

Hayabusaについて

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

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

LMEでのHayabusa活用検証

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

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

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

図 2 検証環境図

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

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

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

hydra -l fleming -P passwordlist.txt 10.0.0.8 smb

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

ISO-Bypass試行

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

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

  1. iso.exeという名前の実行ファイルをダブルクリックする。
  2. iso.exeにより以下の動作を行う。
    • 同じディレクトリに用意したdownload.isoをマウントする。
    • マウントしたdownload.iso内のrun.batを実行する。
    • download.isoをアンマウントする

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

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

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

hayabusa-<バージョン名>-win-x64.exe csv-timeline -l -o <出力先ファイル名>

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

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

zoom拡大する
図 3 Client2でのHayabusaの実行結果(抜粋)
zoom拡大する
図 4 WECでの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の痕跡は検出できていません。

zoom拡大する
図 5 Client1でのHayabusaの実行結果(抜粋)
zoom拡大する
図 6 WECでのHayabusaの実行結果(抜粋)

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

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

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

図 7 lme_wec_config.xmlの設定(抜粋)

しかし、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」内に転送したいイベントログを追記します。

図 8 SubscriptionTypeのコメントアウト

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

<Query Id="60" Path="Security">
    <!-- please change query Id -->
    <Select Path="Security">*[System[(EventID=4624)]] and (*[EventData[Data[@Name="LogonType"]=="10"]])</Select>
</Query>

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

<Query Id="60" Path="Microsoft-Windows-PowerShell/Operational">
  <Select Path="Microsoft-Windows-PowerShell/Operational">*[System[(EventID=4103 or EventID=4104 or EventID=4105 or EventID=4106)]]</Select>
</Query>

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

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

図 9 イベントログフィルターでXMLを作成する方法

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

wecutil ss /c:lme_wec_config.xml

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

wecutil gs lme

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

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

zoom拡大する
図 10 Event Viewerの画面

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

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

  • (※1)
    ログ転送されるForwarded Eventのログサイズはデフォルトで20MBとなっています。実環境で運用する場合は事前にログサイズを増やすことを勧めます。

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

zoom拡大する
図 11 lme_wec_config.xml修正後のClient1でのHayabusaの実行結果
zoom拡大する
図 12 lme_wec_config.xml修正後のWECでのHayabusaの実行結果

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

おわりに

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

参考文献

付録:使用したAutomatedLab Scripts

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

# 既にLabが存在していれば削除
Remove-Lab
# HyperVの環境で「LME」という名前空間のLabを作成
New-LabDefinition -Name LME -DefaultVirtualizationEngine HyperV
# DomainNameを変数として設定、マシン作成時に変数を指定する。
$Domain = 'lme.local'
## ドメイン管理者ユーザの情報も変数として設定。
$DomainAdminUser = "fleming"
$DomainAdminPassword = "P@ssword123!"

## ラボ構築のためのOSインストール時のユーザアカウントを設定
Set-LabInstallationCredential -Username $DomainAdminUser -Password $DomainAdminPassword
# ドメイン管理者アカウントを設定
Add-LabDomainDefinition -Name $Domain -AdminUser $DomainAdminUser -AdminPassword $DomainAdminPassword

## ネットワーク関係の設定を行う
# 仮想スイッチの作成
Add-LabVirtualNetworkDefinition -Name 'LME' -AddressSpace 10.0.0.0/16

## ドメインコントローラを作成
Add-LabMachineDefinition -Name DC1 -Memory 2GB -OperatingSystem 'Windows Server 2019 Standard Evaluation (Desktop Experience)' -Roles RootDC -DomainName $Domain -Network 'LME' -IpAddress 10.0.0.4 `

## Client1のWindows10マシンを作成
Add-LabMachineDefinition -Name Client1 -Memory 2GB -OperatingSystem 'Windows 10 Enterprise' -DomainName $Domain -Network 'LME' -IpAddress 10.0.0.7
## Client2のWindows10マシンを作成
Add-LabMachineDefinition -Name Client2 -Memory 2GB -OperatingSystem 'Windows 10 Enterprise' -DomainName $Domain -Network 'LME' -IpAddress 10.0.0.8
## WECのマシンを作成
Add-LabMachineDefinition -Name WEC -Memory 2GB -OperatingSystem 'Windows 10 Enterprise' -DomainName $Domain -Network 'LME' -IpAddress 10.0.0.9
# ラボ設定を適用し作成する
Install-Lab
# デプロイ結果を表示する
Show-LabDeploymentSummary -Detailed

執筆者プロフィール

竹内 俊輝(たけうち としき)
セキュリティ技術センター リスクハンティング・アナリシスグループ

リスクハンティング・アナリシスグループにて脆弱性診断やペネトレーションテストを担当。趣味はマルウェア解析

SEC560メダル保持
情報処理安全確保支援士(登録番号014728号)
GIAC GPEN

執筆者の他の記事を読む

アクセスランキング