企業が刻一刻と侵害され続けるなか、ITチームやセキュリティチームは、ネットワークから攻撃者を一掃しようと防御策の見直しに追われている。（ある意味で）朗報なのは、セキュリティソフトウェアやハードウェアのベンダーが、ユーザーを支援するための製品やサービスをあふれるほど提供していることだ。なかには、悪意ある攻撃者をシステムから24時間365日締め出すと約束するものまである。
では、クレジットカードを取り出して製品を1つインストールし、安心して眠ればいいだけなのだろうか。残念ながら、私たちが国内各地のクライアント向けに実施しているペネトレーションテストでは、こうした高価なセキュリティソリューションに重大な死角があることを何度も確認している。最も基本的な攻撃すら完全には検知できない製品も少なくない。また、セキュリティ製品は環境に合わせて細かく調整する必要がある。デフォルト設定だけでは、環境固有の懸念をすべてカバーできない。
この記事では、組織のセキュリティサービスの有効性をテストするために、攻撃者にとって「簡単に手が届く果実」にあたる攻撃をいくつか実行する方法を紹介する。これらの攻撃を仕掛ける実在の商用ツールが必要だったため、ラボ環境にRapid7のセキュリティソリューション、InsightIDRをインストールして使用した。
InsightIDRはSIEMを基盤とし、さらに拡張することで、XDRソリューションとして、エンドポイント、ネットワークトラフィック分析、UEBA、インシデント対応などをカバーする。今回のテストでは、SIEMシステムに共通する問題をいくつも確認した。朗報なのは、ベンダーがこうした問題にきちんと対応していることだ。ベンダーとしても、悪意ある攻撃者ではなく「ホワイトハット」の専門家や顧客から指摘を受けたいのだろう。私たちは作業を通じてRapid7とも連絡を取り合った。Rapid7は対応が早く、話も進めやすかった。これはユーザーサポートにとって好ましい兆候であり、サイバーセキュリティにおいて極めて重要な点でもある。Rapid7は、今回の調査結果を受けて複数の修正に取り組んでいる。そのなかには、同社がすでに把握していた既知の問題も含まれるため、作業の完了を反映するよう数カ月後にこの記事を更新する予定だ。各所にはRapid7のコメントも掲載している。
私たちの知る限り、これほど大規模なサイバーセキュリティ製品についてテスト結果が公開されるのは、今回が数少ない例の1つだ。そのため、この記事の主な目的は教育にある。この記事をガイドとして、セキュリティソリューションの社内テストを自分たちで実施してほしい。攻撃中（またはペネトレーションテスト中）に発生し得る、検知可能な「警告射撃」に注目した。これらは、舞台裏で悪いことが進行していると知らせてくれる。こうした攻撃の1つでも検知できなければ、ベンダーに対して、その攻撃を検知するシグネチャを作成するよう求めてみよう。その結果、製品はユーザーベース全体にとってより強固なものになる。
また、製品の使いやすさと機能についての印象をまとめた別記事、Rapid7 InsightIDRを始めるためのガイドも作成した。製品は数時間で簡単にインストールと設定ができ、すぐに重要なセキュリティイベントの通知を受け取れるようになった。この記事では、ペネトレーションテストで実施する一般的な攻撃と、それにRapid7のInsightIDRシステムがどう対応したかに焦点を当てる。
InsightIDRの攻撃検知能力をテスト
- Active Directoryの列挙
- パスワードスプレー
- Kerberoasting
- AS-REP Roasting
- ネットワークトラフィックのポイズニング
- ドメインコントローラーからのハッシュダンプ
- Pass the hash（PTH）攻撃
- 結論
テスト環境のすべてのシステムにエージェントをインストールし終えると、攻撃者やランサムウェアのオペレーターが行う操作を再現し、どのようなセキュリティ脅威が検知されるかを確認する準備が整った。（注：以下の攻撃の多くは、Light Pentest LITE：eBook版から引用している。これは、内部ネットワークのペネトレーションテスト向けに、実践的な手順を追ったプレイブックとして設計されている。）
Active Directoryの列挙
ペネトレーションテストで最初に行うことの1つは、クライアントのActive Directory環境について詳しく調べることだ。特に何年も本番環境で使われているActive Directoryの構成には、内部を深く調べなければ見つけにくい攻撃経路が数多く存在することがある。
Active Directoryの列挙に使うツールの1つがSharpHoundだ。これは、ディレクトリ内のすべてのオブジェクトに関する情報と、セキュリティの観点から見た相互関係を収集する。SharpHoundには、データ収集をよりステルス性の高いものにするために調整できる設定が数多くあるが、通常は次のように「全開」で実行する。
sharphound.exe -d pwn.town -c all
「-d pwn.town」はドメインを指定し、「-c all」はSharpHoundにActive Directory環境に関するすべてのデータを収集させる。
InsightIDRは、SharpHoundが実行されたことを検知しなかった。ただし、これは驚くことではない。これまでSharpHoundを検知するセキュリティソリューションを見たことがないからだ。
朗報なのは、InsightIDRが近くこの攻撃を検知できるようになることだ。Rapid7は次のように説明している。「SharpHoundを使ったActive Directory列挙の検知に取り組んでいる。Windowsのログイベントを使えば実現可能だと考えている。年末までには利用可能になる見込みだ」
パスワードスプレー
ペネトレーションテストの初期段階では、ほかのActive Directoryユーザーアカウントにアクセスできるかどうかを確認したい。一般的かつ比較的ステルス性の高い方法がパスワードスプレーだ。これは、各アカウントへのログインを、1回だけ、人々が使いがちなパスワードを使って試みる手法である。経験上、人々は季節と年を組み合わせたパスワードを非常に好む。そこでRubeusをダウンロードし、次の構文で各ユーザーアカウントへのログインを試みた。
rubeus.exe spray /password:Spring2022! /outfile:pwned.txt
「spray」フラグはRubeusにパスワードスプレーを実行することを伝え、「/password:Spring2022! 」はスプレーに使うパスワードを指定する。「/outfile:pwned.txt 」は有効な認証情報を保存するテキストファイルとして、pwned.txtを指定する。
InsightIDRは、今回のパスワードスプレーの試行を検知しなかった。セキュリティソリューションは、アカウントがロックアウトされたときの通知は非常に得意だが、今回は各アカウントへのログインを1回ずつ試みただけなので、アカウントはアクティブなままだった。
Rapid7によれば、設定していなかったハニーポットがあれば役立ったという。同社の回答はこうだ。「パスワードスプレーについては2つの検知機能がある。1つ目は、テスト時に設定していなかったハニーユーザー、2つ目は、単一ホストから大量の認証失敗が発生したことを検知するブルートフォース検知だ。しきい値は少なくとも100人の異なるユーザーとしている（当社の最小規模の顧客でも約500ユーザーいる）。現在、このしきい値を再評価している」
Kerberoasting
Kerberoastingは、私たちが特に好んで使う攻撃の1つだ。技術的な説明は少し難しくなり得るため、詳しく知りたい場合はBlack Hills Information Securityのこの記事を読むことを勧める。ただし、Kerberoastingについて説明するときは、攻撃の内容と、なぜ注意すべきなのかを平易に説明してほしい管理職や経営幹部が集まる部屋にいることが多い。そこで、私たちは次のように説明する。
「基本的には、どのActive Directoryアカウントでも、『ねえActive Directory、IISやSQLなどに関連付けられたサービスアカウントのハッシュをもらえない？』と言える。そしてActive Directory環境は、『問題ないよ、ブライガイ。はい、どうぞ！』と喜んで答える」
この攻撃は、実際に動かしてみると分かりやすい。環境がKerberoasting攻撃に対して脆弱かどうかを確認するには、次の構文で再びRubeusを使う。
rubeus.exe kerberoast
ここで分かるように、ラボ環境のRay ユーザーアカウントはKerberoastingに対して脆弱だ。そこで、アカウントのハッシュを高性能なパスワード解析マシンに持ち込み、平文のパスワードを割り出せる可能性がある。本番環境で見つかるKerberoast可能なアカウントは、しばしばDomain Adminsグループに属しており、パスワードも頻繁には変更されない。つまり、そうしたアカウントの解析に成功すれば、朝のおやつの時間までにドメインを完全に掌握できるかもしれない。
InsightIDRはKerberoastingの試行を検知しなかった。もっとも、これは完全に意外というわけではない。この特定の攻撃に対するアラートを生成するセキュリティソリューションは、これまでに数例しか見ていないからだ。しかし、Blumiraなどのソリューションはこの攻撃の検知機能を構築しており、Kerberoast用のハニークレデンシャルのコードまで一般公開している。
Rapid7の回答：「当社の顧客の複数社がKerberoastingを懸念しており、現在、この種の活動を検知する機能に積極的に取り組んでいる。夏の終わりまでには稼働させる予定だ。現時点での最大の懸念は、誤検知を抑える方法で実装することだ」
AS-REP Roasting
Kerberoastingと同様に、AS-REP Roastingは、どのActive Directoryアカウントでもアカウントパスワードのハッシュを取得するために利用できる手法だ。この攻撃の技術的な仕組みについては、Stealthbitsの記事が詳しく説明している。しかし、技術者と非技術者が混在する場では、次のように説明する。
AS-REP Roasting攻撃では、どのActive Directoryユーザーでも、基本的にはこう言える。「ねえActive Directory、Kerberosの事前認証を必要としない設定になっているユーザーアカウントがあれば、そのユーザーに関する暗号化データを少し分けてくれない？オフラインに持ち出して解析したいんだ！」
Active Directory内で脆弱なユーザーを見つけるには、次のPowerShellコマンドを使う。
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $True} -Properties DoesNotRequirePreAuth
このコマンドで返されたユーザーは、Active Directoryユーザーとコンピューター ツールで開き、アカウントタブをクリックすると、脆弱な設定を確認できる：
脆弱なユーザーとそのハッシュを確認したいので、再びRubeusを使う：
rubeus.exe asreproast
InsightIDRは、AS-REP Roastの試行を検知しなかった。Kerberoastingと同様に、この攻撃に対するアラートを生成するセキュリティソリューションは、これまでにほとんど見ていない。今回も、近い将来Rapid7による検知が可能になると期待できる。
ネットワークトラフィックのポイズニング
パスワードスプレー、Kerberoasting、AS-REP Roastingで進展を得られなかった場合は、NBT-NS（NetBIOS Name Service）、LLMNR（Link-Local Multicast Name Resolution）、mDNS（multicast DNS）など、特定の脆弱なネットワークトラフィックプロトコルをポイズニングするさまざまなツールを使う。
この攻撃を視覚的にイメージするため、ユーザーSallyがWindows Explorerを開き、PT-APP01サーバーを参照しようとしたものの、サーバー名に余分なゼロを入れて間違え、\\pt-app001と入力した場面を想像してほしい。しばらくすると、「Windows cannot access \\pt-app001（Windowsは\\pt-app001にアクセスできません）」というポップアップエラーが表示される。大したことはないと思うだろうか。実は、バックグラウンドでは、もっと邪悪なことが起きている可能性がある。
攻撃者として、たとえばInveighのようなネットワークポイズニングツールを実行していれば、Sallyがこのような入力ミスをするのを待ち受け、実際に傍受できる。この動作をイメージするには、次の図を見てほしい：
基本的に、SallyのマシンはDNSサーバーに、\\pt-app001がどこにあるかを尋ねる。DNSサーバーが見つけられないと、Sallyのマシンは安全でないプロトコル（NBT-NS、LLMNR、mDNS）を使ってネットワークのほかの端末に呼びかける。その瞬間――ドン！――私たちは彼女のマシンをだまして、Sallyのユーザー名とパスワードハッシュを送信させる。
ネットワークトラフィックに対するこの攻撃を始めるには、Inveighを使う：
inveigh.exe -nbns y -llmnr y -mdns y
この構文によって、Inveighが起動し、安全でないNBT-NS、LLMNR、mDNSのトラフィックをポイズニングする。
しばらくすると、Inveighのログに次のようなエントリが表示されるはずだ：
これで、ユーザーBeverlyのハッシュを取得し、解析を試みることができる。
InsightIDRはネットワークトラフィックのポイズニングを検知しなかった。ただし、InsightIDRはエンドポイントベースのツールなので、検知は期待していなかった。とはいえ、エンドポイントの活動に加えてネットワークトラフィック全体を監視しているセキュリティソリューションを使っているなら、Inveighを実行してアラートが生成されるか確認することを勧める。あるいは、ネットワークポイズニング攻撃を検知するために実行できる、CanaryPiという優れた無料ツールもある。
ここでも朗報がある。Rapid7によれば、ソリューションが開発中だという。「この攻撃に対する検知機能はすでにあり、過去にResponderというツールでテストして発火した。今回使用したツール（inveigh）でも試したが、発火させることができなかった。理由を調査中だが、近いうちに動作するようにする」
ドメインコントローラーからのハッシュダンプ
Domain Adminsグループのメンバーから認証情報を取得して解析できたら、次にActive Directoryからすべてのユーザー名とパスワードハッシュを抽出する。mimikatzツールは、この作業に最適だ：
lsadump::dcsync /domain:pwn.town /all /csv
この構文によって、Mimikatzはpwn.townドメインの全ユーザーとそのハッシュの一覧を、整ったCSV形式で出力する：
私たちの見解では、この攻撃はActive Directory環境で起こり得る最悪の事態だ。なぜか。攻撃者がこの情報を手にし、なおネットワーク内にいるなら、任意のユーザーになりすましてActive Directory上で行動するpass-the-hash（PTH）攻撃を実行できるからだ。さらに、攻撃者が環境内に築いた足場を崩したとしても、ハッシュの一部を解析して、メール、VPN、VDIなどを経由してネットワークにすぐ戻ってくる可能性がある。
InsightIDRはInsightIDRエージェントが導入されたエンドポイント上にmimikatz.exeが存在することを検知した。しかし、監視対象外のエンドポイントからActive Directoryのハッシュをimpacketを使ってダンプした際は、InsightIDRはアラートを発生させなかった。従来、セキュリティソリューションはハッシュダンプの動作に対してアラートを出すものだ。これは朗報である一方、少しもどかしくもある。基本的には、ソリューションが攻撃者のActive Directoryにおける「とどめの一撃」を検知したということだからだ。
Pass the hash（PTH）攻撃
Active Directoryからダンプしたハッシュがあれば、CrackMapExecのようなツールを使って、ネットワーク上のほかのシステムにハッシュを「パス」できる：
cme smb 10.0.7.0/24 -u brian -H PASSWORD-HASH-FOR-BRIAN
この構文では、cmeがCrackMapExecを呼び出し、smbは使用するプロトコルを指定し、10.0.7.0/24はハッシュを「スプレー」するシステムのサブネットを指定し、-u brianはBrianユーザーを指定する。そして、-H PASSWORD-HASH-FOR-BRIANはBrianのパスワードハッシュを表す：
ご覧のように、このハッシュを10.0.7.0/24サブネット全体に「スプレー」した結果、ユーザーとハッシュの組み合わせが有効なだけでなく、多くのシステムで高い権限を持つアカウントであることが分かった（Pwn3d!で示されている）。
InsightIDRはpass-the-hash攻撃を検知しなかった。一般に、企業向けのエンドポイント検知・対応（EDR）エンドポイント保護ツールは、pass-the-hashの挙動を検知するとアラートを発生させる。
「警告射撃」検知のために環境をペネトレーションテストする
この種の見落としは、多くのSIEMでよく見られることに注意が必要だ。理想を言えば、魔法の杖を振って、ネットワークをハッキング不可能にするセキュリティソリューションの組み合わせを見つけられればよい。しかし、それまでの間にも、攻撃（またはペネトレーションテスト）の最中に発生し得る、検知可能な「警告射撃」は数多く存在し、舞台裏で悪いことが進行していると知らせてくれる。この記事をガイドとして、自社でセキュリティソリューションのテストを実施することを勧める。これらの攻撃の1つ以上が検知されなければ、ベンダーにシグネチャの作成を求めてほしい。また、新しい監視・ログ記録ソリューションを探しているなら、SIEMple SIEMアンケートを確認してほしい。ここには、ソリューションが何を実行でき、何を実行できないのかをより深く理解するために営業前に尋ねられる質問の一覧に加え、脅威の検知や阻止におけるソリューションの有効性を判断するために実行できる技術テストも掲載されている。
その他の主要SIEMソリューションを見る
次に読む：