ちょっとした読み物枠：初期感染（Initial access）に関する考察 - [RedTeaming][情報セキュリティ][マルウェア配送]
今回は、なんの因果かわからないけど仕事としてRedTeamingをやってみて、攻撃側の情報としてなかなかネットに転がっていなかったりRedTeamingの本とかでも深く掘り詰めてなさそうなところをいろいろ考えたので、後進のRedTeamerあるいは企業のネットワーク設計・管理・運用担当者さんへ向けての参考材料として、以下の方針でメモを書いておきます。
- 極力技術的に細かい話は書かない、企業ネットワークの設定・構成に関しては細かいとこを気にしてるのでそのあたりは書く
- 攻撃側が実際にどんなことを考えてプログラムを作ったりするのか、だとかを攻撃者目線で
- そもそもRedTeamingとは
- 実際攻撃側はなにをやるのか
- 武器化、エクスプロイト〜遠隔操作について
- Initial accessの成功条件について
- 外部と通信する必要がある ＝ HTTP/外部DNSとの通信が前提、企業内ネットワークタイプの想定および準備が必要
- 継続的にマルウェアを動かす必要がある ＝ Persistence設定が必要
- マルウェア上で多種多様なコマンド実行を行える必要がある ＝ コマンド実行のためのモジュールが必要
- ネットワークの探索は自動では行わない（検知される可能性を下げるため）
- あらゆるAV/EDRに検知されないようにする必要がある（標的組織で利用されているセキュリティソフトの特定前という条件） ＝ 上記の要件を満たす各アクティビティが検知されない仕組みの用意が必要
- あとがき
そもそもRedTeamingとは
WikipediaさんによるとRedTeamingは以下のような感じです。
ある組織の効率性を改善するように挑む独立したグループで、対象組織に敵対した役割あるいは視点を持つことを前提とし、（省略）侵入テストの担当者は、組織のセキュリティを評価する。多くの場合、対象組織の職員には知らされない。 このタイプのレッドチームは、演習、ロールプレイング、または発表された評価よりも、セキュリティ準備状況のより現実的なイメージを提供する。 レッドチームは、特定の運用環境内でアクティブなコントロールと対策を引き起こす可能性がある。（以下省略）
なんか英語の直訳感があるけど、ざっくり内容を書くと
- 「攻撃」を提供する企業（以降、攻撃側）と「防御」の実践を行いたい企業（以降、防御側）、双方の合意に基づいた、情報セキュリティにおける攻撃シミュレーション
- 目的は、防御側が定めたゴール（情報資産の持ち出しやらネットワーク管理者権限の奪取やら）に到達できるかをチェックすること
という感じ。攻撃側は、いわゆる「標的型攻撃」を防御側に対してガンガンしかけていって、その結果・内容を報告する、形になります。会社ごとのサービス内容と契約によって呼び名と内容が「なんかミスマッチじゃね？」ってなることは往々にしてあるので細かいことは気にせず、まあこんなもんなんだって程度で。
実際攻撃側はなにをやるのか
Cyber Kill Chainが定義されて久しいけど、ざっくりこんな感じ。
PDF, IoT時代のサイバーセキュリティ確保に向けて, P.8, IPA
「目的達成」のとこはざっくりすぎて防御側が具体的に何をどう守ればいいのかわからん、みたいな話があって別のモデルも考えられてはいるんだけど(Unified Kill Chain、本家のPDFがなくなってた、どっかにアーカイブあるんかな)、この記事では上の画像でいう「武器化、エクスプロイト〜遠隔操作」の部分を深掘りするので、ここでは割愛。
というのも、「目的の達成」の部分は技術的な話になりがちで、かつ「昔から使われている手法からほぼほぼ変わってないし、なんだかんだ情報転がってる」というのが実感としてあるからです。記事の趣旨からズレるからね、仕方ないね。興味ある人はいろいろ調べて、どうぞ。
武器化、エクスプロイト〜遠隔操作について
"じゃあ「武器化、エクスプロイト〜遠隔操作」はなにか変わっているのか"という話。個人的にはここもそんな大きくは変わっていないんじゃないかと考えてます。それならなんでこのブログを書いたんだ、ってとこに関しては、攻撃側の情報としてなかなかネットに転がっていなかったりRedTeamingの本とかでも深く掘り詰められていないように見えている、かつ結構頑張って考えたと自負しているからです（スクリプトも作ったしAVにもたくさん消されたし）。
そんなわけで、以下、安定的な「遠隔操作」の実現に向けて、本気の攻撃者が考えているであろう、かつ極力汎用的なところまで落とし込んだことをつらつら書いていきます。防御側の人は読んでみて、実際の攻撃者への嫌がらせをたっぷり考えていきましょう。
Initial accessの成功条件について
まずマルウェアを標的組織内に送り込んで実行させることを目標とした場合に、攻撃目的からプログラム要件を考えてみます。一般化した場合はおそらく以下のような感じになるでしょう。
- ランサムウェアタイプ
- APT / 情報窃取を目的とした標的型攻撃タイプ
基本的に、ランサムウェアタイプは初弾が検知されずに実行されれば成功、というシンプルなものに対し、標的型攻撃タイプはいくつか条件があることがわかります。RedTeam的には「C2がうまくいき」かつ「継続的にマルウェアを動作させる」ことができれば大成功、最悪でも外部との通信経路を確認できれば次弾の用意が捗る、という感じです。
今回はRedTeam（APT/標的型攻撃タイプ）を前提にしているので、2について深堀りをします。それでは各項目について考察していきます。
外部と通信する必要がある ＝ HTTP/外部DNSとの通信が前提、企業内ネットワークタイプの想定および準備が必要
そのままで、外部との通信を「どのプロトコルで」かつ「どの経路で行うか」という話です。目的は以下の2つです。
- C2サーバと通信を行う（感染端末⇄C2/Exfilサーバ）
- 取得した情報を持ち出す（感染端末→C2/Exfilサーバ）
1に関しては説明不要だと思います。攻撃を継続的に行うために、感染端末上で何かしらの操作ができるようにするということです。いろいろな解析ブログでもC2に関しては触れられていますね。
2に関しては1と異なり、完全に端末の掌握はできない場合でも、2回目にマルウェアを送付した際にマルウェア感染・端末掌握の成功確率を引き上げるための戦術になります。具体例を挙げると、端末上のセキュリティ製品情報の持ち出しであったり、外部との通信で利用可能なプロキシ情報であったり、C2通信に利用可能なプロトコル情報など、必要最低限な情報だけを外部に送り、最終的なマルウェア感染は（わざと）しない、というものです（できればラッキー）。
それではまず企業内ネットワークを考えてみます。なにかしらで外部と通信可能という前提で企業ネットワーク内にある端末（内部デバイス）を想定した場合、おおよそ次のようなネットワーク構成があると思います。HTTPプロキシに関しては、外部・内部・その他用途といろいろもっと細分化できると思いますが、数だけ多くなるのでいったんはこのぐらいにしておきます。またCASBなどのサービスは考慮外とします。
※図はLucidchartで作成
各図を説明すると以下のような形です。
- 左ー上の図、HTTP(S)ではインターネットと直接通信可能な穴があり、プロキシ通しても通信可能、DNSも外部を参照するようになっている
- 右ー上の図、用途別にプロキシがある、通信の制御がブラックリスト形式とホワイトリスト形式で異なっており、HTTP(S)のデフォルト通信先はホワイトリスト制御のプロキシに向いている、DNSは端末から外部参照可能
- 左ー下の図、HTTP(S) でインターネットと通信するためにはプロキシを通る必要がある、名前解決はプロキシが行なっており、端末からは名前解決できない
- 右ー下の図、DNSのみ外部と通信可能
それぞれについて、どのプロトコル、かつ経路で通信可能かを考えてみます。
- HTTP(S)/DNSで通信可能、HTTPでプロキシを参照しない方がログに残らなくて良い
- HTTP(S)はNot blacklistedなプロキシを指定した場合、もしくはDNSは特に考えずに通信可能、プロキシ情報はpacに記載されていると想定されるのでpac取得した上で指定する必要がある
- HTTP(S)でのみ通信可能、プロキシを参照する必要がある
- DNSのみ通信可能
だいたいまとまりました。Initial accessでは、1-4すべてで情報の外部持ち出しを試み、かついずれかの通信経路に対応したマルウェアを動作させる必要がある、ということがわかります。
ちなみにですが、その辺に公開されているC2 Frameworkで生成されるマルウェアでは、このあたりのプロトコル調査・経路探索はやれないので自分で準備する必要がありました。標的組織に送り込めるファイルタイプとの兼ね合いもあって、実際の初弾はVBAマクロになりがちです。この辺はもう仕方ないなーと思って白目剥きつつオレオレフレームワークを作ってました（現在進行形）。
対策
マルウェアがHTTP(S)で通信を行おうとした場合レジストリや.pacの参照を行うことになりますが、この辺での検知は非常に難しいので昔からある通りプロキシ（あるいはその他のデバイス）のログを基に検知するしかないと思います。問題は複数プロキシがあり、かつデフォルトがホワイトリスト形式のプロキシに向いている場合です。端末上のデフォルト通信先設定で安心しちゃってブラックリスト形式のプロキシログの監視を行なっていない場合、C2通信の検知ができない恐れがあります。
めちゃくちゃ大変でしょうが、企業内にあるプロキシに関してはすべてについて用途、通信可能・あるいは不可能なドメイン、およびログ監視の有無の棚卸しをした方がよいでしょう。
DNSに関しては、個人的には3. 左下の図の形が良さそうな気がしています。外部への情報持ち出しを止めることは難しいですが端末の掌握自体は防げますし、業務利用を考えても外部との通信が可能な状態を維持したままにできるので（なお構築）。
余談
- だいたいのC2 Frameworkが出力するマルウェアは、プロキシ情報（レジストリのProxyServer）を参照するようになっているようなので、単にプロキシ置いてレジストリ設定しただけではほぼほぼ通信阻止に至りません（pacの場合はわかりません、全Frameworkを調査したわけではないので）
- DNSで安定してC2できるFrameworkが少なすぎてつらみ
継続的にマルウェアを動かす必要がある ＝ Persistence設定が必要
それでは次にPersistence設定について考えてみます。インストールされているソフトウェアによって増えたりしますが、パッと思いつくところだとこんなもんではないかと。
- レジストリ、HKLM, HKCU 配下のRunとかRunOnceとか、LogonscriptとかCortanaとかいろいろ（一部要管理者権限）
- スタートアップフォルダ
- スケジュールタスク
- サービス（要管理者権限）
- DLL (search order) hijacking / side loading
- Officeアドインフォルダ
- Keepass
- その他プラグイン/アドイン/拡張機能
まずKeepassやらプラグインアドイン拡張機能に関してはインストール済みが条件となるので、汎用性を考えた場合設定対象からは外れます。
次にレジストリですが、実際のInitial accessでもよく用いられるためか、ちょっと（けっこう？）前からVBAからのレジストリアクセスがWindows Defenderに検知されるようになったようでした。コードベースで検知された可能性もありますが、一度でも検知された以上積極的に採用する気にはなりません。またサービスは要管理者権限ですし、よほど運が良くない限り登録できないでしょう。
DLL系は...一発で見つけて、かつPersistenceするのは相当難しいです。検証はしているものの、そもそもsearch orderの設定不備が、標的になった組織でほぼほぼ見られないのであまり採用する気にはなりません。
そのような感じでどんどん絞っていったところ、わりとスタートアップフォルダへのドロップ、およびOfficeアドインフォルダへのファイルドロップは比較的アンチウイルスソフトに検知されにくいような印象を受けました。ただしEDRにはかなり検知されます。さすがに怪しいからね、仕方ないですね。
というわけで、今後Persistence対象として選ばれる可能性が高くなるのはフォルダ系と見ています。
対策
この辺は設定されないように防ぐ、ということは難しいですが、EDRでの検知がめちゃくちゃ強い部分だと思います。アンチウイルスソフトとEDRの強いところを組み合わせて、総合的に守っていくようにしましょう。
侵害済み端末かどうか、のところに関してはまずAutorunsとかで確認して、DLL漁っていくとかアドイン探すとかになるのでしょうかね。かなり大変なのであんまやりたくはないですね。
マルウェア上で多種多様なコマンド実行を行える必要がある ＝ コマンド実行のためのモジュールが必要
ここは詳細、対策は省略。攻撃側は公開されているC2 Framework使うとか、商用のもの使うとか、その上でEvasionを頑張るしかないところかと。私は自作のプロトコル・経路探索のやつに、特定のセキュリティ製品の場合だけ任意のタイミングでコマンド実行できるモジュールをロードするようにしてみました。
防御側はEDRとかでのエンドポイント検知を頑張るしかないかと。
ネットワークの探索は自動では行わない（検知される可能性を下げるため）
（やらないので書くことは）ないです。
あらゆるAV/EDRに検知されないようにする必要がある（標的組織で利用されているセキュリティソフトの特定前という条件） ＝ 上記の要件を満たす各アクティビティが検知されない仕組みの用意が必要
はい、ここまでで一通りInitial accessで必要と考えられる要素を挙げてきました。最終的には標的組織内に送り込むファイルに、要件通りのものを仕込んだ上でAV/EDR Evasionやって、メールで送るなら経路上での検知を潜り抜けるようにして、気づかれないように実行してもらうだけですね。頑張りましょう。
あとがき
ここまででRedTeamプロジェクトの始めも始め、というか正直まだ始められてもいない（けど苦労はめちゃくちゃしている）という段階の話です。いかがだったでしょうか。
攻撃者としては、2弾目以降の攻撃で足掛かりになる情報はかなり欲しい気持ちになるので、情報の持ち出しについて深く考えているんじゃないかと思います。
防御側に関しては、外部との通信方法について改めてネットワークを確認いただくことで、ハードニングも捗るんじゃないかと思います（なんの通信も外に出てこなかったりすると、攻撃者は何もわからなくて寝れなくなるんじゃないでしょうか）。ネットワーク構築の際も大変な思いだけして作るのも気が滅入るので、攻撃者にたっぷり嫌がらせができる構成を考えて楽しみつつ実装していきましょう。
Dear real attacker,
進撃の巨人、一巻
以上
