皆さんこんにちは。国井です。
最近、Microsoft 365 Defenderを利用したトレーニングやセミナーでお話しさせていただく機会が多く、中でも従業員数300名以下の企業で利用可能なMicrosoft Defender for Business (略称MDB) がテーマになることが多いです。
Microsoft Defender for BusinessのEDRとしての側面について話をするとき、
いつも「(インシデントを)勝手に見つけて、勝手に修復する」というフレーズを使わせていただいています。
(ここはセールストークみたいになっちゃうけど)マイクロソフトでは世界最大級のインシデント対応のためのデータベースを持っているので、
自分で頑張ってインシデントを見つけて、
自分で頑張って調査して、
自分で頑張って対応する
ということをしなくても良いという、セキュリティの専任担当を置くことができないような企業ではありがたいメリットがあるのです。
■ ■ ■
では逆に自分で頑張らなければならないケースが出てきたとするならば、MDBってどこまでのことができるのだろうか？今日はこれを追及してみたいと思います。
本日の特選素材
Microsoft Azureで動かしているWindows 10の脆弱な仮想マシンを用意し
なんのセキュリティ設定もしないで放置しておきました。
そしたら2日ほどでWindows 10が乗っ取られてしまい、自分のアカウントでサインインできなくなってしまいました。
今日はこちらを使ってインシデント対応してみたいと思います。
調査開始
あらかじめ仮想マシンはオンボーディングしておいたので、Microsoft 365 Defenderの画面から「やられた」仮想マシンを調査することができます(ちなみに「やられた」という状態を表す言葉として「危殆化」という言葉があります。Compromiseという英語の訳語として使われるのですが、あまり一般的な日本語じゃない気が今でもしているので私は「やられた」という俗語で表現したいと思います)。
Microsoft 365 Defender画面(https://security.microsoft.com/)からインシデント調査を開始するときは[インシデント]メニューからスタートします。
インシデントメニューにはMulti-stage incident… で始まる項目とその配下にアラートとしてSuspicious behavior by… で始まる項目が表示されていることがわかります。
インシデントをクリックして、インシデントの内容を確認していきます。
インシデントの概要ページはダッシュボードページになっていて、文字通り「概要」が把握できます。
次に[証拠と対応]タブをクリックしてみます。こちらではインシデントを発生させた要因(＝攻撃者が行ったこと)が確認できます。勝手に見つけて、勝手に対応してくれるパターンでは[修復状態]という項目にどんな修復を行ったか？が表示されるのですが、今回は(もしくはこの時点では？)まだ対応していないことがわかります。
この項目を見て勘の良い方ならレジストリに何やら書き込みをしたのだな(reg.exeから推測)、タスクスケジューラで定期的に悪意のあるプログラムを実行しようとしているのだな(schtasks.exeから推測)ってことがわかると思います。さらに進めていきましょう。
アラートで詳細調査
インシデントには必ず付随するアラートという項目があります。今回で言えばSuspicious behavior by… で始まる項目です。これをクリックして内容を確認しましょう。
アラートはクリックすると[アラートのストーリー]という項目が登場し、どのような「悪いこと」が行われたのかがわかります。
例えば、いま見ている画面の中ではPowerShellが実行し、REG ADD.. と書いてありますのでレジストリに項目が追加されたことがわかります。PowerShellでは以下のことを行う命令が書いてありました(悪用の危険があるので細かくは書けないです)。
・ユーザーアカウント制御の無効化
・Set-ExecutionPolicyコマンドレットでUnrestrictedに設定
・Microsoft Defenderウイルス対策のリアルタイム保護機能の無効化
・Microsoft Defenderウイルス対策からRuntime.exeプロセスを監視対象から除外
要するにセキュリティ的によろしくないことを全部やってくれてます。
[10424]と書いてあるプロセスを拡大してみると、[10424]の配下にreg.exe.. の説明やpowershell.exe processes…の説明がありますが、これらは[10424]で説明していたことと同じことが書いてありました。
さらに画面を下へスクロールすると、続いてschtasks.exe schtasks /create… の説明が出てきました。
説明の中にはこのように書いてありました (こっちのほうが悪用の危険があるような..)。
schtasks /create /tn AWSD /SC ONSTART /tr “c:\windows\Runtime.exe” /RL HIGHEST /RU SYSTEM
Runtime.exeという実行プログラムをSYSTEMアカウントの権限でデバイス起動時に実行しなさいという命令がタスクスケジューラのコマンド(schtasks.exe)によって設定されています。
Runtime.exeってなに？いかにもな名前だけど、そんなプログラムは普通のWindowsにどうやらないようです。つまり、ここまでの話をまとめるとRuntime.exeが悪の元凶のようだ、ということがわかりました。
初動を決めよう
何が起きているかはなんとなくわかったところで、今度は初動の対応として行うことを決めたいと思います。ここまでのところで、
・インシデントは起きている
・でも、勝手に対処はしてくれていない
・Runtime.exeとやらを放置しておくと危険っぽそう
以上のことから、まずはデバイスのネットワークを遮断することにしました。遮断は[デバイスのインベントリ]から特定のデバイスを選択して、[デバイスを分離]をクリックして行います。
そして、さらに[ウイルス対策スキャンを実行]をクリックして、フルスキャンを行いました。
Live Responseセッションで調査
ウイルス対策スキャンですが、スキャンをかけてもマルウェアが検出されることはありませんでした。そこで今度はLive Responseを使ってRuntime.exeを調査しに行くことにしました。
上のメニューから[Live Responseセッションを開始する]をクリックして、プロンプト画面を出し、dirコマンドでファイルの存在を確認しました。
先ほどウイルス対策スキャンはフルスキャンをかけたけど、一番知りたいのはruntime.exeが危険か？ってこと。だからanalyzeコマンドを使ってファイルを指定して調査してみました。
結果はクリーンと出ました。
続けてruntime.exeが現在実行中であるかも確認しました。
タスクスケジューラで実行するように設定されているから今なお実行中なわけですね。
ではタスクスケジューラのタスク一覧も見てみましょう。
先ほどAWSDという名前でタスクを登録するコマンドがありましたので、AWSDというのが今回の攻撃で登録されたタスクになります。
修復
ある程度のところが確認できたら修復してみましょう。
Remediate scheduledtask AWSD とコマンドを実行すると、AWSDタスクが検疫されたことが確認できます。
続けてファイルも検疫してしまいましょう。
Remediate fileコマンドに続けてフルパスを書いてあげるとファイルの検疫ができます。
まとめ
ここまでのところでMDBの機能を使って手動でのインシデント対応を行ってみました。
ここまでの流れを見ていると「えっ、それで終わり？？」って思った人もいると思います。
そうです、ここまでがMDBを使った手動でのインシデント対応なのです。
MDBはとても安価に使えますし、手軽に使えるし、(MDEも同じだけど)勝手に修復してくれるメリットがあります。ただ、手動で調査をするとなるとできることはどうしても限定的になります (手動で調査しなければならない機会がどのくらいあるのか？ということについては参考となる統計情報などがあるとよいのですが..)。
そのため、Microsoft Defender for Endpoint (MDE) という別のライセンスが用意されているわけで、MDEを使うとタイムラインやAdvanced Huntingを使った調査もできるようになり、調査の効率や原因特定の確率もぐっと上がることになります。
ちなみに今回見ていただいたインシデント対応はMDEの機能も含めてハンズオンで学んでいただけるトレーニングを用意していますので、ご興味があればご参加いただければと思いますし、お客様のご要望に合わせたアレンジもできますので気軽にお問い合わせいただければ幸いです。
