1. 導入：なぜ今、Emotet対策が重要なのか
Emotetは、単なるウイルスではなく「感染の踏み台」となるマルウェアです。特に巧妙な点は、過去の正規メールを流用した「スレッドハイジャック」です。実在の取引先を装うため、従来のセキュリティ教育だけでは限界があります。本稿では、Emotetの侵入経路として最も一般的な「Officeマクロによる不正なPowerShell実行」を、システム管理者がどう検知・制御すべきか、実務的な観点から解説します。
2. 基礎知識：Emotetの仕組み
Emotetの感染プロセスは、主に「メール添付のOfficeファイルを開く」→「マクロが実行される」→「PowerShellが呼び出され、外部サーバーから本体をダウンロードする」という流れです。
ここで重要なのは、OS標準機能であるPowerShellが攻撃の道具として悪用されている点です。攻撃者はPowerShellを難読化して実行し、検知を回避しようとします。管理者は「マクロの無効化」だけでなく、「PowerShellの実行ポリシー」や「ログによる異常検知」を組み合わせた多層防御が必要です。
3. 実装/解決策：PowerShell実行ログの監視と制限
現場で最も即効性がある対策は、PowerShellの実行内容を可視化することです。以下の手順で対策を講じます。
・PowerShellのログ有効化: グループポリシー（GPO）で「モジュールログ」と「スクリプトブロックログ」を有効にします。これにより、難読化されたスクリプトが実行時にメモリ上で展開された状態を記録できます。
・実行ポリシーの引き締め: `Set-ExecutionPolicy AllSigned` を適用し、署名のないスクリプトの実行を禁止します。
・AppLockerによる制御: 実行可能なスクリプトを制限します。
4. サンプルプログラム：PowerShellの不審な実行を検知するスクリプト
以下のコードは、イベントログから「Base64で難読化されたPowerShell」の実行痕跡を抽出するためのサンプルです。
イベントログからPowerShellの実行ログ（EventID 4104）を取得
Base64で難読化されている可能性が高い「-e」や「-enc」フラグを抽出します
$searchDate = (Get-Date).AddDays(-1)
$logs = Get-WinEvent -FilterHashTable @{
LogName = 'Microsoft-Windows-PowerShell/Operational'
Id = 4104
StartTime = $searchDate
} -ErrorAction SilentlyContinue
foreach ($log in $logs) {
# スクリプトブロックの内容を取得
$scriptContent = $log.Message
# 難読化によく使われるキーワードが含まれているかチェック
if ($scriptContent -match '-e(ncod(ed|e)?)?\s+') {
Write-Host "警告: 不審なPowerShellコマンドを検知しました" -ForegroundColor Red
Write-Host "発生時刻: $($log.TimeCreated)"
Write-Host "内容の一部: $($scriptContent.Substring(0, [Math]::Min(100, $scriptContent.Length)))"
Write-Host "------------------------------------------------"
}
}
5. 応用・注意点：現場での運用のコツ
・誤検知への対応: 正規の管理スクリプトも「-enc」を使用している場合があります。検知対象を絞り込む際は、実行ユーザーや親プロセス（Winword.exeやExcel.exeから起動された場合のみ抽出するなど）でフィルタリングを行うのが定石です。
・マクロ制御の徹底: 「インターネットから取得したOfficeファイルのマクロをブロックする」というグループポリシー設定は、現在必須の対策です。
・EDRの活用: スクリプトによる検知はあくまで補助です。Emotetのようなファイルレス攻撃に対抗するためには、プロセスの挙動を監視するEDR（Endpoint Detection and Response）ツールの導入を強く推奨します。
Emotetは手口を変え続けていますが、その根幹にある「PowerShellの悪用」という特徴は変わりません。ログを監視し、「異常な挙動」を早期に発見できる体制を構築しましょう。
コメント