レッドチームでやっていることを書いていきます（ドキュメント化＆レポート）

## 本記事で学べること
レッドチームの目的は、対象組織に対して実際にサイバー攻撃を仕掛けることで、セキュリティにおける技術面、運用面の評価を実施し、経営層への改善提言を通じて、最終的に対象組織のセキュリティ耐性を向上させることです。
そのため、提言にあたって調査観点を体系立ててドキュメントとして整理することは重要なスキル要素となります。
本記事では顧客への提示ドキュメントの全体像やレッドチームのドキュメント作成を支援する具体的なツールを紹介していきます。

### 報告書作成に向け活動時に書き留める観点
基本的に利用したコマンド、実行結果の画面などをキャプチャしておくことで、再現性も生まれるため常に作業ログを取ることは意識しておく必要があります。以下はオリジナル版の観点を時系列順に変更して記載しています。
- Administrative Information
- Scoping Information
- Vulnerability Scan Research
- OSINT
- Service Enumeration Research
- Web Application Research
- AD Enumeration Research
- Findings
- Attack Path
- Credentials
- Activity Log
- Payload Log


## Notetakig Tools
あまり本腰を入れて検討したことがなかったのですが、せっかくなので自分が知らなかったツールの中から独断と偏見で以下3つをピックアップ。今回を機に少し味見をしてみることにします。

- [Notion](https://www.notion.so/ja-jp)
クラウド版、デスクトップ版、があり、エディタだけでなくスプレッドシート等もあり、非常に有用なエディタ。

- [Cyptpad](https://cryptpad.fr/)
IT業界では珍しい気もするフランスのツール。クラウドサービスがあるため、便利そう。

- [Obsidian](https://obsidian.md/)
ドメインが.mdなことから分かるようにマークダウンアプリ特化。


## レポート種別
レッドチーム活動といっても実際には攻撃までは実施しなかったり、攻撃を事前にブルーチーム側にも予告して進めたり、対象組織のシステム情報全てを開示した上で進めたり、とケースバイケースとなります。そのため、活動の内容（範囲）毎にアウトプットであるレポートも変わってきます。以下は切り口の参考例です。

- Black Box / Grey Box / White Box
- Full evasion / Hybrid evasion / Zero evasion
- Internal / External

## 攻撃シナリオ例
以下は、ActiveDirectory環境下において、内部犯が機密情報にアクセスするまでの攻撃シナリオ例となる。

1. あるドメインユーザ（例：Taro）のNTLMv2パスワードのハッシュ値を[Responder](https://github.com/lgandx/Responder)を使って入手する
2. 入手したハッシュ値は[Hashcat](https://hashcat.net/hashcat/)を用いて、オフライン環境でクラッキングし平文パスワードを取得。しかしながら、Taroアカウントは一般ユーザのため、機密情報にアクセスするには適切な上位アクセス権限が必要。
3. [BloodHound](https://github.com/BloodHoundAD/BloodHound)を使ってAD内のユーザが割り当てられているアクセス権限等を明示化し、意図しない依存関係の確認等を行う。調査の結果、Service Principal Names(SPNs)として複数の権限を保持するドメインユーザの存在を確認。本ドメインユーザが脆弱なパスワードを使用している場合、hashcatにより平文を入手することができると想定。Kerberoastingによりサービスチケットからパスワード情報を入手する
4. 入手した該当ドメインユーザのハッシュ化されたパスワードをhashcatを用いてクラッキングすることで平文パスワードを入手
5. 入手したドメインユーザのアカウント情報を使って、ADサーバにログインし、ドメインコントーラを除く全てのサーバに対してローカル管理者権限を保有するアカウント情報を搾取


## レポート作成時の注意点
レポートの読み手は経営層が中心となるため、専門的な記述を排除するのはもちろんのこと以下の点については**盛り込まない**よう注意が必要となる。

- **特定企業の製品名**
提言書は中立的な報告書にすべきであり、営業マンの提案書にすべきではない。顧客から具体的な依頼があるまでは対処すべき内容も概念のみに留め具体的な製品を記述しない。

- **技術的に困難であった点**
報告会の場などで陥りがちであるが、レッドチーム側にとって技術的に困難でそれを打破したことが顧客にとって今後の対処として価値がなければ時間を割いて説明すべきではない。

- **省略語、専門用語の多用**
本観点は顧客に提出する前に第3者のレビューを実施することで、本観点での失敗を避けることができる。

## レポート作成ツール
人生でWord以外を経験してこなかったが、報告書が必要となる似たようなプロジェクトを実行する際に有用なツールがあるらしい。新規に案件を作成し、ディレクトリ構成を作成した後、該当箇所に収集した情報や画像データ等をアップロードしていけば最終的にPDFでポンっとレポートが出力されたりするらしい。こちらも有料/無料で7つほど紹介されていたが、無料版の中から以下3つを紹介する。どれも初耳だが、もし使ったことがある人がいれば是非使い勝手を教えて欲しい。

- [WriteHat](https://blog.blacklanternsecurity.com/p/writehat)
- [Ghostwriter](https://www.ghostwriter.wiki/)
- [Dradis](https://dradisframework.com/ce/)
- [PlexTrac](https://plextrac.com/) 

最後のPlexTracは唯一の有償ツールだが、米国の有力セキュリティ企業Mandiant（2022年9月にGoogleによる買収が完了）がリリースしているペネトレーションテストのレポーティングおよびマネジメントのツールらしい。
なお、レポート作成に向けコマンド実行画面などスクリーンショットを取得する機会が増えると思うが、[GetGreenShot](https://getgreenshot.org/)というツールが紹介されている。初耳だが、これは確かに便利そう。

## レッドチーム活動における注意点
レッドチームは、対象システムにおける脆弱性の調査に加え組織内のブルーチームの攻撃検知時の対応を評価する。しかしながら、その目的遂行に固執することで顧客に損害を与えるケースもあります。以下のようなシーンでは顧客とコミュニケーションをしっかりと取って進めることが大切です。

- 対象組織の業務に影響を与える (i.e. スキャンの結果、対象システムをダウンさせてしまう）
- 重大な脆弱性を発見したが、報告すると攻撃時に利用できないため報告会まで黙っておく
- アラートが大量に発生することで顧客のブルーチームに著しく負担をかけてしまう