はじめに
Red Team 演習やマルウェア解析を学び始めると、必ず登場する言葉が Beacon（ビーコン） です。
「なんとなく定期通信するやつ」という理解で止まっていると、OPSEC も検知回避も一段浅いままになります。
本記事では Beacon の本質・通信モデル・OPSEC 上の意味・Blue Team からの見え方までを体系的に解説します。
Beacon とは
Beacon とは、侵害された端末（Agent / Implant）が一定間隔で C2（Command & Control）サーバに接続し、命令の取得や実行結果の送信を行う通信方式を指します。
最大の特徴は以下の一点です。
「常時接続しない」
これは単なる実装上の都合ではなく、OPSEC（Operations Security）を最優先した設計思想です。
Beacon と Reverse Shell の違い
| 観点 | Reverse Shell | Beacon |
|---|---|---|
| 接続形態 | 常時接続 | 定期ポーリング |
| 検知リスク | 高い | 低い |
| 通信制御 | 即時 | 非同期 |
| OPSEC | 弱い | 強い |
| 実戦適性 | 低 | 高 |
Reverse Shell は「電話をかけっぱなし」、
Beacon は「決まった時間にだけ安否確認する連絡」です。
Beacon の基本通信フロー
この「何も起きない通信が大半」という点が、検知を難しくします。
なぜ Beacon が使われるのか（赤チーム視点）
1. OPSEC 最優先
- 常時接続は NDR / EDR に即捕まる
- 定期通信は 業務トラフィックに紛れやすい
2. 操作の柔軟性
- Operator は好きなタイミングで命令を投入
- Agent は「次の Beacon」で処理
3. ネットワーク制約への強さ
- プロキシ越し
- アウトバウンド制限環境
- HTTPS のみ許可された社内ネットワーク
👉 Beacon は“環境に適応するための妥協点”
よく使われる Beacon 通信プロトコル
| プロトコル | 特徴 |
|---|---|
| HTTP / HTTPS | 最も一般的、業務通信に擬態しやすい |
| DNS | 非常にステルス、帯域は狭い |
| SMB | 内部横展開向き |
| TCP / UDP | 独自プロトコル |
| Domain Fronting | CDN 越しに C2 を隠蔽 |
Beacon の重要パラメータ（OPSEC の核心）
Sleep Time
- 固定値は危険
- 例：
60秒ぴったりは SIEM に愛される
Jitter
- Sleep に揺らぎを加える
- 例：
60s ±30%
URI / User-Agent
-
/api/v1/updateのような自然さ - Chrome / Edge らしい UA
Selective Response
- 正しい条件で来た Beacon にのみ応答
- 間違ったリクエストは 404 / 無視
有名な Beacon 実装
- Cobalt Strike Beacon
- Sliver Implant
- Mythic Agent
- Meterpreter（実質 Beacon 型）
名前は違っても、思想は同じです。
Beacon を MITRE ATT&CK で見る
Beacon は単独の Technique ではなく、以下にまたがります。
- TA0011 Command and Control
- T1071 Application Layer Protocol
- T1090 Proxy
- T1105 Ingress Tool Transfer
👉 Beacon は C2 戦略そのもの。
Blue Team から見た Beacon（検知のヒント）
Beacon は「見えない」のではなく、「見えにくい」だけです。
注目点：
- 外向き通信の 周期性
- リクエストサイズの類似
- 不自然な User-Agent
- 業務と関係ない API パス
- 深夜・休日の定期通信
Beacon は隠れるが、完璧には消えない
まとめ
- Beacon とは C2 フレームワークの中核となる通信モデル
- 本質は OPSEC を最大化するための設計
- 赤にも青にも「理解必須」の概念
- Reverse Shell 感覚で扱うと即死する