端末のファイル実行を制御するセキュリティ AppLocker, WDACのススメ
組織を脅威から守るために実行ファイル制御(アプリケーションコントロール)は如何ですか?ランサムウェア対策や内部統制に有効なAppLocker, WDAC(Windows Defender Application Control)は、Windows標準で利用可能で細かなカスタマイズで制御可能です。
このnoteに辿り着いた方の組織が、少しでも幸せになれるような内容について述べていきます。
AppLockerとは
意外にも認知度が低く驚くことも多いのですが、Windowsに標準で搭載されたアプリケーション制御機能です。無料で利用できます。実行ファイルに関連する属性情報をポリシーとして設定し、特定ユーザやグループ毎に動作を決めることで、細かな制御条件で運用することができます。
Windows OSであればWindows 7以降のWindows 10やWindows11、Windows ServerのOSで動作します(※)。エンドポイント上でアプリケーションを制御することで、昨今話題のゼロトラストモデルの一部を担えます。
「使ってるよ、アプリケーション制御くらい当たり前じゃん」の組織と、「え?どうやって使うの?初めて知ったよ」の組織がはっきり分かれてることも多い機能だったりします。
※ Windows 10 バージョン2004以降、Windows 11 バージョン21H4以降で、Homeを除くProfessional、Education、Enterpriseなどすべてのモデルで、2022年10月頃リリースされた更新プログラムを適用していればAppLockerが利用可能です。2022年8月以前の古いバージョンを利用している環境の場合は対象外の可能性があるのでご注意ください。
WDACとは
WDAC(Windows Defender Application Control)はAppLockerの後継とも言える機能で、Microsoft Security Response Center(MSRC)を利用している環境下で利用できるAppLockerとほぼ同一の機能です。Windows 10以降のOSで動作します。日本ではWindows Defender アプリケーション制御機能と呼ばれたりします、表記は多くの場合WDACと省略されています。
AppLockerに比べ少し複雑な設定が可能となっており、シンプルな考え方の運用ではAppLockerのほうがマッチします。MSRC環境下である、主にM365のセキュリティ群を利用している環境であればAppLockerよりもWDACが好ましいでしょう。
WDACはAppLockerにはない、プロセスベースのポリシー作成が可能であり、またMicrosoftが提供するインテリジェンスソース(インテリジェントセキュリティグラフ, ISG)を利用することで、更に検知能力の向上が狙えます。しかしMSRCやMicrosoft Defender(Windows Defender)を利用していないなどの環境であれば、AppLockerでも問題はないでしょう。
そのため、このnoteではAppLockerを中心に取り上げます。以下のAppLockerに関する言及は、WDACでも同一のものが再現、適応するものとして読んでいただけたら。
AppLockerにより期待できる点
AppLockerを導入し、うまく条件が合致し、期待できる点は以下のシナリオが考えられます。
「侵入した攻撃者によってセキュリティを無害化する際のハッキングツールの実行」を防げる。
「誤ってユーザがインターネットから取得した不審なファイルを実行し、マルウェアに感染してしまう」ことを防ぐ。
「サーバに侵入された時、権限昇格や情報窃取、認証情報の窃取、横展開などに必要なLiving-Off-The-Land(自足自給型)の実行ファイルを動作させない」ことで攻撃進行を困難とする。
「特定の悪用されやすいリモートアクセスツールを事前にブロックする設定を導入」することで、攻撃者のアクセスや情報を持ち出しを防ぐ。
…といったシナリオを、ポリシーに沿って実行ファイルを制御することで、攻撃の糸口を潰す役割を担えます。これは重要なことで、攻撃者はいくらでも時間と手数が掛けられれば基本的にランサムウェアの実行に辿り着くことは容易いです。
しかし、様々なセキュリティを搔い潜るうちに検知され、ブロックされ、封じ込められれば攻撃は失敗してしまいます。掻い潜る手段は持っていても、全ての検知回避は難しいため、攻撃者が得意とする攻撃手法(TTPs)を潰すことが大切です。
(スパイが施設に侵入するような映画を見たことがあるかと思いますが、あのような感じで掻い潜るスパイが嫌がる対策を練ることです。映画だと大抵スパイのほうが勝ってしまうのですが…。)
こんな組織は特に導入をおすすめしたい (効果を得やすい)
閉域網(Closed Network)を持った組織 ≒ システムの利用用途が限定的な組織 → システムの更新が頻繁ではない組織
お金の掛からない製品は導入検討が進みやすい組織
ユーザのリテラシー教育が追いついておらず、不正広告や見知らぬWebサイトからファイルをダウンロードし実行しがちな組織
サーバやクライアント端末は管理者権限さえあればどんなファイルでも自由に実行ができる組織
ある程度自組織内で検証でき、ブロック、動作すべきソフトウェアや実行ファイルの選定ができるエンジニアが居る組織
こんな組織は導入しづらい (効果を得にくい、デメリットが大きい)
頻繁にシステムの導入、アプリの変更を行う、あるいは様々な運用事業者が入り組んでいる
ユーザの裁量権が大きく、使うソフトウェアやサービスは自由に選ばせている
圧倒的にマシンパフォーマンス重視、遅くなることは一ミリも許せない
導入しているソフトウェアをセキュリティ担当者(AppLockerを導入/運用する)が管理できるポジションに居ない
残念ながら、AppLockerは若干設定と運用の難易度が高い(コスト面含む)と言わざるを得ません。手放しでの運用は困難でしょう。そのため、上述したメリットの恩恵が受け易い組織は前向きに検討いただくのが良いでしょう。デメリットが大きい組織は無理して導入する必要はないと思います。特に最後のソフトウェアをセキュリティ担当者が関与/管理しない組織はまず無理です、運用が回らないです。本来関与すべきですが、縦割りな組織で風通しが悪い組織にありがちです。当人たちの仲が良くとも企業体として成せない場合もありそうです。AppLockerを使わずとも、インシデントが発生した時は組織政治的に地獄ですね。
深く踏み入る前の前提と注意点
AppLockerといえど万能薬ではなく銀の弾丸でもありません。利用環境によりふさわしい設定は千差万別で、それゆえに知名度や利用が広まらない原因でもあるのですが、昨今のサイバーセキュリティはPON!!と導入できるような対策はまず存在しません。個々の組織や環境によって正解の設定値は異なります。後述する監査モードをうまく活用しながら導入と運用を進めていきましょう。
恋は盲目と言いますが、セキュリティも盲目になりがちです。特に企業法人組織は「ビジネスで利益を上げ、組織メンバーに給与を支払い働いてもらえる」ことで組織が存続できます。セキュリティは守るためではありますが、ビジネスのために存在します。忘れてはならないのはセキュリティはユーザビリティにも大きく影響がある点です、ユーザを締め付けすぎた先には裏切りがあります、ユーザはより良い快適性を求め抜け道を探します。セキュリティ担当者(システム担当者)の首が最後に締まらないよう気を付けましょう。
AppLockerを設定しても万全ではない
万能薬ではなく銀の弾丸でもないと上述しましたが、このAppLockerは所詮はイチ機能に過ぎません。侵入してきた攻撃者により0-Dayの脆弱性が悪用され、端末の管理者権限が窃取されAppLockerを無効に替えられる。あるいは組織を管理するActiveDirectoryが侵害され、組織ネットワーク全体のAppLockerや、EPPなどのセキュリティが無効化される可能性が十分にあります。むしろ、後者は特にランサムウェア被害の致命的かつ、最もな原因でもあるわけです。どんなに良いEPPやEDR、SIEM、IPSを導入していても無効化や迂回されてしまえばそれまでです。対策として取り入れるには脅威のシナリオを定期的に見直し理解する必要があります。
昨今のEDRなどでは、そのような不審な挙動を検知できるよう各ベンダーにおいて非常に努力頂いていますが、そうとはいっても個々組織において設定を確認し、防げる確率(センサー)を増やすことは重要です。AppLockerは対策のうちの1つであり、有効な対策を複数設けることで、ランサムウェアの攻撃者が攻撃を完遂できないよう防御網を張り巡らせるためのパズルの1ピースに過ぎないのです。そしてその防御網に攻撃者が引っ掛かった時に、正しくアラートが挙がり、即座に対処できる体制も重要であり、セキュリティ対策とはシステムやソフトウェアの設定だけではないことも忘れないようにしましょう。
AppLockerの設定の流れ
このあとの流れは簡単です、設定例として"notepadのみブロック"するに至るまでの手順を記載します。手順例として述べる環境は Windows Server 2019とWindows 10 21H2(19044)となります。
まずはAppLockerがエンドポイント上で動作するのに必要な Application Identity サービスを有効にするGPOを設定しておきましょう、別々に分けていただいても大丈夫ですし、AppLocker用のGPOと一緒にしてしまっても良いです。
次にAppLockerの設定を行っていきます。再度GPOを編集し、アプリケーション制御ポリシーのAppLocker配下にある"実行可能ファイルの規則"を開き、"既定の規則の作成"を選び許可ポリシーを3個作成します。
"(既定の規則)"と書かれた許可ポリシーができたことを確認し、"新しい規則の作成"を選びます。
操作は"拒否"を選択し、ユーザはひとまずEveryoneにしておきます。条件は"パス"を選びます。"発行元"や"ファイルハッシュ"も選べますが、まずはディレクトリパスとファイル名の標準的なところから。
パスの入力画面が表示されたら「*notepad.exe」と打ち込みましょう。本来Windows配下の標準プログラムはsystem32(32bit)とsyswow64(64bit)があるため、正確な運用を行うのであれば2回ポリシーを作成する必要があります。その場合は変数で効率的に記述することも可能です。
制御したいnotepadのポリシー設定が完了したら、次に"パッケージアプリの規則"も設定を済ませます。画面上で右クリックし、"既定の規則の作成"を実行し、許可ポリシーを1個作成します。これはC:\Program Files\WindowsAppsやC:\Windows\SystemAppsなどのWindowsシステムの一部として提供されるユニバーサルWindowsプラットフォームであるUWPの動作を許可させる必要があるためです。これを設定しておかないと、スタートメニューなどの諸々の動作もブロックされてしまいます。
"実行可能ファイルの規則"と"パッケージアプリの規則"を設定し終えたら、最後にどのようにAppLockerを動作させるかを選択します。GPOの"AppLocker"を右クリックし、プロパティから各設定を"規則の実施"に選択しOKボタンから反映させます。
"規則の実施"は許可/拒否にもとづき動作を実行/ブロックするモードです。もう一つ、"監査のみ"の選択もあり、こちらはイベントログに出力するのみのログモードのような動作が選べます。初めて検証を行うのであればまずは"監査のみ"を選択し、監査モードから始めてみるのがよいでしょう。
GPOを作成した後は指定のドメインやグループにリンクさせるのを忘れずに。
"gpupdate /force"コマンドやグループポリシーの更新メニューなどからGPOをエンドポイントへ配布した後にnotepadが動作するかを確認してみます。試しにcalcも動かしてみた結果が以下の通りです。notepadは動作せず、calcは動作しました。"このアプリは、システム管理者によってブロックされています。"と表示されます。コマンドプロンプトなどで叩いた場合は「このプログラムはグループ ポリシーによりブロックされています。詳細については、システム管理者に問い合わせてください。」と表示され実行することができません。
ブロックされるとイベントログは以下のように表示されます。実行が許可されなかった(ブロック)場合はイベントID:8004、実行が許可された場合はイベントID:8002にて記録されます。ブロックせず監査のみとした対象が動作した場合はイベントID:8003にて記録されます。
AppLockerで設定すべき実行ファイル (ブラックリスト運用方式基準)
これは最も簡単な運用方式です、特定の実行ファイルを狙い撃ちで実行させない方法です。効果はホワイトリスト運用方式と比べると劣ります。最低限の運用であると理解し、このブラックリスト運用方式以外の実行ファイルはEDRを始めとしたその他のセキュリティ対策にて補えることを確認するようにしましょう。
Deny list方式とも呼ばれるブラックリスト運用方式基準ですが、設定により効果が見込まれる実行ファイルはLoLBINやLOLBASと呼ばれる、端末内に存在する実行ファイル(ツール群)が分かりやすいでしょう。導入しているソフトウェアやシステムによっては多用されている可能性もありますが、そうでない実行ファイルはリストに追加し、動作をブロックするべきです。
特に攻撃者が悪用する実行ファイルについて下記に記載します。各セキュリティベンダやスライド、公開情報などから収集し、まとめたリストとなります。最終的に組織のAppLockerポリシーへどのように適用するかは、入念な検証と監査モードを利用したうえで判断してください。もちろんですが、これが全てではありませんので、取り組みのスタート地点の一つとしてお役立てください。
これらはすべて、c:\windows\system32とc:\windows\syswow64の配下に存在するファイルとなります。
さらには、マシンに存在せずとも、外部から攻撃者が持ち込み実行することで攻撃範囲を広げる可能性のあるファイルも数多く存在します。いずれもマルウェアとして作られたわけではないものの、有用ゆえに悪用されてしまっているファイルとなります。実際にマシンにダウンロードした場合にセキュリティ製品が検知する場合もあるためご注意ください。細かい悪用事例は検索して頂くと、多くの各社ベンダーレポートがあるかと思います。取り組みのスタート地点としては、端末に攻撃者が侵入した際に悪用されそうなファイルをリストアップしてみました。
そのほかにも、RMM(Remote monitoring and management)と呼ばれる、攻撃者がマシンにアクセスするために悪用されてしまっている悲しきリモートツールソフトウェアも存在します。ランサムウェア対策の観点では有効な対策といえるでしょう。JSAC2023の公開資料にてリサーチャの方がまとめてくださっているため、必要に応じて設定することを検討ください。
どう運用したらいいの?
上述した「ブラックリスト運用方式で設定すべき実行ファイル」の他、組織であまり利用されていない実行ファイルはブラックリストに追加してしまっても良いでしょう。
閉域網(Closed Network)のシステムで、限定的な運用がされている環境である場合はホワイトリストで運用することも出来そうです。
ホワイトリスト運用方式のポリシーを用意してみる
ホワイトリスト運用方式は大変ですがより強固です。なんとAppLockerの運用方法についてNSAも推奨しているほどです。ただし本当に導入と運用が大変です。組織内の端末上で動作している実行ファイルを把握し、正しく設定する必要があります。設定後に設定漏れがあり動作しないファイルがあった場合は早急に検証し、業務環境に反映できる運用が求められます。可能であればある程度の権限を持ったメンバーが迅速な検証が実施でき、反映できるような柔軟性のある運用も加えたいところです。
メンテナンス用のポリシーを用意しておく
普段はある程度ガチガチにかためたポリシーを適用して、Windows Updateやソフトウェアのバージョンアップなど作業時のみ緩和するポリシー(GPO)を作っておくことも運用上好ましいでしょう。この考え方はホワイトリストでもブラックリストでも同じ考え方です。AppLockerによってソフトウェアがバージョンアップできず脆弱な状態になるのは以ての外です。作業を行う領域(システム)のみメンテナンスポリシーを適用し、それ以外の領域は通常通りのポリシーを適用しておくことでリスクを最小限に抑えながらバージョンアップが可能になるでしょう。
ロックダウン状態のポリシーを用意しておく
これは「論理分離」や「論理隔離」などと言われるような、ロックダウン状態(緊急時の最低限の動作状態)をポリシーとして用意した方が良いだろう、とする提言の一つです。ただし、既に圧倒的な侵害を受け、GPOによるポリシー展開すらままならない時には使い物になりません。侵害の初期、疑いの時点でシステムネットワーク内を攻撃者に闊歩させない、被害を広げない、現状のシステムとネットワークを維持しながら被害範囲を制限するためのやり方です。有効時には最低限か全く業務が遂行できない状況にあえてすべきです。この考え方はエンドポイント型のファイアウォールや、ネットワーク(境界型)ファイアウォールでも実装可能です。
普段であればシステムやソフトウェアの動作に影響が出てしまいそうなものをすべてブロックすることです。cmd.exeやPowershell.exeも御構い無しです。
DLLの制御も検討する
難易度は高いのですが、ホワイトリスト運用方式の究極としてはDLLの制御も推奨されています。各国の組織も「ホワイトリストでやるならぜひ」と記述しているのですが、具体的なノウハウが散らばっておらず、私も全く影響度合いが分かりません。ただ、昨今の標的型攻撃やマルウェアの高度なテクニックにはDLLのSide-Loadingなどを悪用してくることも多いため、理想の理想としては活用したいところではあります。もし試したことがある方、実際に運用されている方がいらっしゃいましたらコッソリと使い心地を教えてくださると嬉しいです。
イレギュラーな挙動を検知したら即座に対応する
上述したブラックリスト運用方式の場合で例に挙げた実行ファイルがマシン上で実行された時に、即座にアラートとして発報され、インシデント疑いの調査が開始できることが好ましいです。というのもこのイベント(イベントID:8004や8003)を基準としたアラートは白と黒の判別がしやすいからです。正しくロギングシステムで管理しておくことで、ヒアリングや分析も容易に進められることが期待できます。
マシンからローカル管理者を削除する
組織の運用上実施できない可能性も大いにありえますが、AppLockerに限らずローカル管理者権限は無いほうがセキュリティ的にはリスク低減に繋がります。また、一般的なユーザにもローカル管理者権限が実行出来ないようなITポリシーであることが好ましいです。ローカル管理者権限を持っている、あるいは攻撃者が権限を得た場合にAppLockerは容易に回避、無効化されてしまいます。もちろん、エンドポイントセキュリティ(EPP,EDR)なども同様です。用心しましょう。
結局どれくらいの時間を見積もれば?
組織において、どれだけ攻撃開始から暗号化開始までの、内部の攻撃展開時間を想定すればよいのか?といった話も聞くことがあります。およその時間を知ることで、攻撃者を検知し対処するまでのMTTR(Mean Time to Respond)の策定に繋げられますが、残念なことに環境、規模や業務形態によって様々であり「一般的、平均的にこの程度である」と断言することは困難です。
しかし、2024年7月時点の情報では、Akira Ransomwareが「内部に侵入し、情報を持ち出すまで133分」といった被害事例が報告されています。攻撃の成功は、細かく言えば暗号化まで行うことで脅迫性が増しますが、データが持ち出せれば成功でしょう。ビジネスとしてはデータが漏洩した時点で多大なダメージを負います。そのダメージを負うまで2時間強の時間は非常にインパクトのある事例と言えます。
攻撃者にとって理想的(脆弱)環境かつセキュリティ対策が刺さらなかった場合、この場合は情報探索や横展開などに時間が掛からず、機密情報を取り扱うマシンが即座に見つかってしまう場合などが該当します。この場合は1-2時間程度で情報流出が始まってしまうと認識し、対応について計画するのも一つの手でしょう。
リファレンス
このnoteを書くにあたって、いくつかの公式サイトやインテリジェンス記事などを参照しています。より確実性の高い情報として記載したソースURLについて目を通すことを推奨します。
お前何言ってんだよ!と言える内容や誤字があればご指摘ください。色々と実体験や検証から述べていますが、乖離している箇所がある可能性があります。見つけた際はX(Twitter)か、本noteのコメントでお知らせください。
ここまでお読みいただきありがとうございました。もしお役立てできる内容であった場合はスキ(ハート)を押して応援いただけると嬉しいです。
余談
X(旧Twitter)でリポストして頂くことで無償でお読み頂けます。駄文を読み漁る知的好奇心の溢れた方はリポスト後にお付き合いください。今回はなぜAppLockerを題材にしたのか?なぜ人間はマルウェアを実行してしまうのか?本当に不思議で仕方ないな、と他所の情シス、セキュリティ担当の皆様の前で、壇上の上で講演するが如く、独り言を書いていきます。
ここから先は
この記事が気に入ったらサポートをしてみませんか?