デジタルペンテスト部でペネトレーションテストを担当している小松奈央です。
たまに新卒採用活動のお手伝いをさせていただくことがあり、セキュリティ業界を目指す学生さんや、配属先が決まる前の内定者の方とお話する機会があります。そういった際に将来どのような仕事をしたいか聞くと、ありがたいことにペネトレーションテスターになりたいという方が少なくありません。また、ペネトレーションテスターになるためにはどのような勉強をしたら良いかという質問もよくいただきます。
そこで今回は、普段私が実際にペネトレーションテストの検証や、新しい攻撃技術を勉強する際に使用している環境1について、その概要とどのような使い方をしているかをご紹介します。
検証環境の全体像
一言にペネトレーションテストといっても、Active Directory（以下、ADとする）やWebアプリケーション、IoTデバイスなどその対象は様々です。ここでは、「ペネトレーションテスト = ADを中心とする企業ネットワークに対するペネトレーションテスト」と定義し、ADに対する攻撃技術を検証・勉強するための環境を紹介します。
検証環境全体の構成は以下のとおりです。
右側のVictim環境はローカルのVMware Workstation Pro上に構築しており、プロキシサーバ（ubuntu22-px01）以外は同一ドメインに参加しています。もちろんVMwareではなく、VirtualBoxやHyper-Vなどの仮想化ソフトウェアでも問題ありません。
ちなみに、Hyper-VであればAutomatedLabというMicrosoft社が提供するWindows環境の自動構築フレームワークを使用することができ、AD環境の構築を自動化することができるため、こちらもおすすめです。AutomatedLabの詳細は、本ブログの過去記事「AutomatedLabでAD構築を自動化しよう」をご覧ください。
なお、AD環境は一度にすべて構築するのではなく、まずは必要最小限のホストのみ構築し、必要に応じて拡張していく方法がおすすめです。これにより、最初の構築の負担が減るだけでなく、すぐに攻撃技術の検証や勉強を始めることができ、モチベーションの維持にもつながります。後述の各ホストの解説では、役割に応じた構築優先度も記載しているので参考にしてみてください。
各ホストの概要
ドメインコントローラ（構築優先度：高）
ADを管理するドメインコントローラ（以下、DCとする）は検証環境においても必須であり、一番最初に構築することになります。ただ、ペネトレーションテスト検証環境としてのDCの設定は難しくなく、ほとんどの設定がデフォルトもままでも多くの攻撃技術やペネトレーションテスト関連のツールを検証することが可能です。
その後、試したい攻撃技術に合わせて追加で設定を変更するのがおすすめです。
- 構成図上のホスト名：win2019-dc01
- 必須の設定例：ドメインユーザの追加
- 任意の設定例：ドメイングループの追加、OU（Organization Unit）の追加、グループポリシーの設定、ACL（Access Control List）の設定、SPN（Service Principal Name）の設定
クライアント端末（構築優先度：高）
ペネトレーションテストのシナリオにおいて、一般社員が使用するクライアント端末を想定したホストです。
この端末もドメインアカウントを割り当て、ドメインに参加させるだけで様々な検証に利用できます。また、PCのスペックに余裕がある場合、異なるバージョンのOSをいくつか用意しておくと便利です。細かな設定はグループポリシーによって管理しますが、簡単な検証であればローカルグループポリシーやレジストリの編集で済ませてしまうことも多いです。
- 構成図上のホスト名：win10-ws02、win11-ws03
情シス用端末（構築優先度：中）
このホストは、一般社員が使用する端末よりも高い権限を持ったクライアント端末です。
ここでは情シス用端末と呼んでいますが、管理用端末などと呼ばれることもあり、（ペネトレーションテストのシナリオにおいて）DCをはじめとする各サーバをリモート操作することを想定2しています。このホストが存在することで、「一般社員のクライアント端末がマルウェアに感染 -> 情シス用端末に侵入範囲拡大 -> ドメイン管理者アカウント奪取」などのシナリオに基づいた検証が可能です。
- 構成図上のホスト名：win10-ws01
- 必須の設定例：ローカル管理者権限の付与
- 任意の設定例：ドメイン管理者アカウント（Domain Admins）によるログオン、Built-in Administratorの有効化
データベースサーバ（構築優先度：低）
実際の企業の社内ネットワークにおいてもMSSQLサーバが存在していることは多く、案件でMSSQLの設定不備を報告することも少なくありません。そこで、MSSQLに対する攻撃手法の検証や対策方法の検証を行うために構築しています。MSSQLに対する攻撃手法は、NetSPI社が開発するツールPowerUpSQLのWikiが非常に参考になります。
データベースサーバ以外のホストは、デフォルトの設定のままでも検証に使えるシチュエーションが多々ありますが、データベースサーバに関しては意図的に脆弱性（設定不備）を作り込んでおく必要があり構築の難易度が少し高いです。
ファイルサーバ（構築優先度：低）
ペネトレーションテストでは、ファイルサーバ上の機密性の高いファイルを入手し、外部に持ち出すことをゴールとして設定することがあります。そのようなシナリオに基づく検証を行うためにファイルサーバを構築しています。
ペネトレーションテストの勉強にはあると便利ですが、ADに対する攻撃手法の勉強という観点では優先度は低いです。
- 構成図上のホスト名：win2019-fs01
- 必須の設定例：機密ファイル（想定）の設置
- 任意の設定例：共有フォルダのアクセス制御設定
プロキシサーバ（構築優先度：低）
実際の企業の社内ネットワークに近い環境において、各種C2フレームワークの検証を行うためにプロキシサーバを構築しています。
実環境におけるインターネット通信はプロキシサーバを経由することが多いため構築しましたが、プロキシサーバがなくてもC2フレームワークの検証は可能であるため優先度は低いです。
プロキシサーバと呼んでいますが、フォワードプロキシ（Squid）とDNSサーバ（Unbound）を兼ねており、クライアント端末がインターネット通信を行う際は、以下のような経路をたどるように設定しています。
■HTTP通信：クライアント端末 -> プロキシサーバ（Squid） -> インターネット
■DNS通信：クライアント端末 -> ドメインコントローラ -> プロキシサーバ（Unbound） -> インターネット
検証環境の使用用途の例
ペネトレーションテスト関連ツールの動作検証
BloodHoundやRubeus、Mimikatzなど、ADを対象としたペネトレーションテストで使用するツールはたくさんあります。しかし、これらのツールやツールに含まれる機能は、AD環境上でないと正しく動作しないものが多いため、本検証環境を利用して動作確認を行います。
また、オープンソースのツールをカスタマイズする際や、自身でツールを作成する際にも本検証環境上でテストを行っています。
もちろんペネトレーションテスト用のツールを使えるだけでなく、ツールの動作原理や各攻撃手法の仕組みを理解することも必要不可欠です。ただ、ペネトレーションテストの学習の入り口としては、とりあえずツールを動かしてみるというのもありだと思います。ツールを動かしてみることによって攻撃のイメージもつかめますし、攻撃が成功すればモチベーションにもつながります。
ADに対する攻撃手法の勉強
私がペネトレーションテストの勉強を始めた際は、本検証環境と似たような環境上で、ADに対する攻撃手法を色々試してみることから始めました。
例えば、管理共有やWMIを悪用してPass-the-Hashによってクライアント端末間の横展開をしてみたり、LSASSやNTDSをダンプしてみたり、Kerberoastによって入手したチケットを解析して平文パスワードの特定を試みたりといった感じです。
今でも新しい攻撃手法が公開された際には本検証環境上で勉強しています。
C2フレームワークの検証
上述の「ペネトレーションテスト関連ツールの動作検証」と似ていますが、C2フレームワークの検証にも本環境を使用しています。
クラウド上にC2フレームワークをインストールし、検証環境内のクライアント端末上でクライアント側の実行ファイルを実行します。検証環境のドメインコンピュータはプロキシサーバを経由しないとインターネットに接続できないようになっているため、より実環境に近いシチュエーションでC2フレームワークを使用することができます。
おわりに
ADに対する攻撃技術を勉強するためには、ADの仕組みや正常動作を把握する必要があります。また、実際に攻撃を試すためには検証環境が必要です。これらを可能とする学習用プラットフォームも存在しますが、私はAD環境を自身で構築するほうが勉強になると考えています。
ペネトレーションテストに興味があるけど勉強方法がわからないという方は、まずは学習用のAD環境を構築してみてはいかがでしょうか。その際に本記事を参考にしていただけると嬉しいです。
- 弊部で用意している検証環境ではなく、プライベートで検証や勉強に使用している私用PC上の環境です。↩
- ペネトレーションテストのシナリオにおいて、情シス担当者が操作することを想定しているだけなので、実際の環境構築や設定変更は各サーバを直接操作しても問題ありません。↩
