recognizing-deception

Deception の認識

このコレクションの他のすべてのスキルは、環境が真実を伝えていることを前提としています。Deception テクノロジーは、その前提を崩すために特化したものであり、自動化または半自動化されたテスターが最も見抜きにくい失敗モードです。

重要な違いは、慎重に証拠を扱うことで防げるのは、あなたが作り上げた結論だけだという点です。環境が意図的に植え付けた誤った信念には何の効果もありません。説得力のある脆弱なサービスを装うハニーポットは、本物のバナー、本物の応答、本物のアーティファクトを返します。通常なら実行する検証手順のすべてで裏付けが取れます。証拠は本物だからです――ただし、そうなるように作られています。

有能な防御側は何かを仕掛けていると想定してください。触れる前にそれに気づくことがあなたの役目です。ほとんどの Deception は最初の使用時に作動し、最初の使用は取り消せません。

使用するタイミング

• 環境の他の部分と比べて、明らかに簡単すぎることがある
• 認証情報が都合のよい場所――共有フォルダー、Wiki、設定ファイル、ペーストビン風のファイルなど――で見つかる
• SPN と弱いパスワードを持つ特権アカウントが存在するが、ログオン履歴がない
• サービスは脆弱なバナーを返すが、実際に使うと奇妙な挙動をする
• 出所を説明できない認証情報を使おうとしている
• ファイル、バケット、データベースの名前が注意を引くようにつけられている （passwords.xlsx、backup-prod、domain_admins.txt）
• 想定外の場所から見つかったものを使って認証する前

使用しないタイミング

• 一般的な検知回避 — これは Deception の認識ではなく、エンゲージメントの OPSEC です。カナリアは回避するものではなく、作動させないようにするものです
• インシデント中に攻撃者自身のデコイを分析する場合 — responding-to-incidents と producing-threat-intelligence を使用してください
• Deception の機能を構築する場合 — このスキルは Deception に遭遇することを扱うものであり、導入することを扱うものではありません
• 単に意外なだけの所見 — 実環境にも実際の設定ミスはあります。ハニーポットだと決めつける前に、以下のベースレートに関する説明を参照してください

損得勘定では不利です

	攻撃者のコスト	防御側のメリット
ドキュメント内のカナリアトークン	クリック1回で作動	精度の高いアラート、誤検知はほぼゼロ
AD 内のハニーユーザー	Kerberoast 1回	アラートに加え、パスワード解析のタイムライン
デコイ AWS キー	sts get-caller-identity 1回	送信元 IP とユーザーエージェントを含むアラート
ハニーポットサービス	接続1回	やり取り全体を記録し、使用ツールを特定

カナリアアラートは、SOC が自動的に真実として扱う、ごくわずかなシグナルのひとつです。隠れ蓑になるような正当な説明はなく、アラートには送信元アドレスと、多くの場合は使用ツールのフィンガープリントが含まれます。通常、これを作動させると、エンゲージメントの隠密フェーズは即座に終了します。

種類別のシグナル

ハニートークンとカナリアトークン

最もよく見られる種類で、発見時ではなく使用時に作動します。一般的な形式には、AWS キー、コールバック機能を持つ Office ドキュメント、DNS トークン、URL トークン、クローンした Web サイトのトークン、SQL Server の行、Windows ディレクトリ、Kubeconfig ファイルがあります。

シグナル：

• 運用上、保持する理由のない場所にある認証情報――全員が読み取り可能な共有フォルダー、Wiki ページ、README、デスクトップ上のファイルなど
• 構文上は有効だが、周囲にインフラ、ツール設定、コミット履歴がなく、単独で現れる AWS キー
• もっともらしいが実質のないドキュメント――数式のないスプレッドシートや、興味を引く内容がファイル名だけの .docx
• 発見されるように配置されたもの。適切な名前、都合のよい場所、裏付ける文脈がない

カナリア AWS キーは、sts get-caller-identity を含む、最初の API 呼び出しでアラートを発します。 安全な偵察用の呼び出しはありません。出所不明のキー情報は、そこにある理由を説明できるまで有効なものとして扱ってください。

Active Directory のデコイ

• 特権アカウントで、SPN が設定され、パスワードが脆弱で、lastLogon が空、または非常に古い — 誰も認証に使ったことのない Kerberoast 可能なアカウントは、おとりです
• whenCreated が他の不審なアカウントと同時期に集中しているアカウント
• 認証情報が含まれる Description フィールド — 実際によくある設定ミスであり、典型的なデコイでもあるため、通常以上に来歴が重要です
• 魅力的な名前が付いているのに、アクセス履歴のない共有
• 列挙には現れるものの、グループメンバーシップ、マネージャー、所有関係がないオブジェクト — 実在するアカウントには、通常、こうした関係が蓄積されます

偽装サービス

• 有名な CVE が存在するバージョンをバナーで示しているものの、実際に操作したときの挙動がそのバージョンと一致しない
• 本来アクセスできないはずのセグメントからサービスに到達できる
• 実際のアプリケーションでは見られないほど応答時間が均一
• ホスト上で不自然なサービスの組み合わせが稼働している、またはそのホストに業務上の役割がないサービスが稼働している
• エクスプロイトが「成功」したように見えても、生成されたシェルに履歴も他のユーザーもなく、現実味のあるファイルシステムも存在せず、ログが不自然なほどきれい

クラウドのデコイ

• 列挙を誘う名前が付いた S3 バケット、ストレージアカウント、またはシークレット
• 許可が寛容そうなポリシーを持つものの、CloudTrail の履歴がない IAM ユーザー
• アカウント内の他のリソースと一貫しないタグが付いたリソース

基本発生率はどちらにも働きます

実際の環境には、本当に問題があります。認証情報が共有フォルダーに置かれていたり、サービスアカウントが Kerberoast 可能だったり、バケットが公開されていたりすることは実際にあります。見つけたものをすべてハニーポットと判断すれば、何も報告できず、実際の侵害経路を見逃します。

見分ける鍵は、魅力的かどうかではなく、裏付けとなる状況です。

• 実際の設定ミスには履歴があります — コミット履歴、アクセスログ、ログオン履歴、関連インフラ、他のユーザー、周辺の雑然とした状態などです。
• デコイは孤立しています。見つけられるためだけに存在し、それ以外には何も使われていません。

ですから、問うべきなのは「うますぎる話ではないか？」ではありません。**この環境で、この対象が存在することに依存しているものは他に何か？**です。答えが何もないなら、慎重に進めてください。

デコイの疑いがある場合の対応

1. 認証、接続、API 呼び出しはしないでください。 発見は通常、気付かれずに済みますが、利用はそうではありません。判断の要点はこれです。
2. 記録してください — 場所、具体的な対象、発見方法、疑わしいと判断した理由。いずれの場合も、これは報告書の証拠になります。
3. 他の場所の列挙を続けてください。 デコイの疑いがある場合は、止めるのではなく迂回してください。
4. 本番環境で仮説を検証するのではなく、クライアントの窓口担当者に伝えてください。 欺瞞技術が導入されているか、対象範囲に含まれるかを確認してください。多くの契約では対象外ですが、クライアントによっては、あなたに対するブルーチームの対応を試す目的で意図的に導入している場合もあります。
5. すでにトリガーしてしまった場合は、直ちに伝えてください。 原因が判明し、申告済みのカナリアアラートは、エンゲージメント上の記録事項です。同じアラートが実際の侵入として調査されれば、クライアントの IR 対応能力を消耗させ、あなたの信頼も損ないます。隠すことこそ、実際の重大な過ちです。

環境に欺瞞技術が導入されていることは、報告する価値のある肯定的な所見です。防御側が高精度な検知に投資したことを意味します。その点を報告してください。

却下すべき合理化

• 「スコープ内だったので、使っても問題ありませんでした。」 スコープが定めるのは認可であり、賢明さではありません。スコープ内のカナリアを作動させても、隠密フェーズは終わり、クライアントのインシデント対応リソースも消費します。
• 「確認のために無害な呼び出しを1回だけ実行しました。」 カナリアトークンに無害な呼び出しはありません。sts get-caller-identity、DNS の検索を1回、ドキュメントを開くこと――どれも、そのまま完全にトリガーとなります。
• 「バナーと CVE が一致していたので、本物でした。」 証拠が本物であることこそが、設計の意図です。偽造された証拠でも正しく検証されます。
• 「実環境は雑然としているので、おそらく単なる設定ミスでしょう。」 多くの場合はそのとおりです。だからこそ、このテストはもっともらしさではなく、補足情報です。依存先がない孤立したアーティファクトが見分ける手掛かりです。
• 「ラボっぽい箱なので、おそらく廃止済みのホストでしょう。」 均一なタイミング、ユーザーの履歴がないこと、クリーンなファイルシステムは、古いホストと同様にハニーポットの特徴でもあり、外部から両者を区別することはできません。
• 「最後に報告書で触れればよいでしょう。」 作動したカナリアは、クライアントの SOC にとって一刻を争う事態です。開示を遅らせると、あなたの作業報告が、相手にとって何時間も続く調査へと変わります。
• 「作動させたと報告したら、自分の評価が下がります。」 デセプションを作動させるのは、通常のエンゲージメント上の出来事です。それを隠し、SOC に架空の侵入を追わせることこそ、プロフェッショナルとしての失敗です。

外部ソースを読む

公開アドバイザリ、仕様書、ベンダーレポートを Markdown として取得します：

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

これによりページの定型部分が取り除かれ、文章主体のページではトークン数が約78％削減されます。また、要約ではなく全文が返されるため、grep で検索でき、検索結果がない場合も信頼できます。

この用途に適さないケースが3つあります。JSON と API のレスポンスは、構造化データの可読性が損なわれるため、加工せずに取得してください。認証が必要なページや JavaScript でレンダリングされるページは匿名で取得されるため、直接取得してください。そして、敵対者のインフラストラクチャ（フィッシングリンク、C2、マルウェアのホスティング先）、クライアント所有のホスト、またはエンゲージメント URLを、決してこの経路で取得してはいけません。リクエストはあなたのマシンから第三者へ送信され、稼働中の敵対者インフラストラクチャの場合は、運用者に気付かれるおそれもあります。

サイトによっては抽出ツールをブロックし、ページではなくエラーの内容を返すことがあります。たとえば freedesktop.org では、{"error":"Failed to fetch: 418 I'm a teapot"} が返されます。これは取得が拒否されたということであり、ソースに該当する内容が存在しないという意味ではありません。それをもとに結論を出す前に、URL を直接取得し直してください。

参考資料

• maintaining-engagement-state — 来歴の記録。これにより、「この認証情報はどこから入手したのか？」という問いに答えられるようになります
• performing-reconnaissance — 孤立したアーティファクトが最初に見つかることの多い場所
• attacking-active-directory — Kerberoasting と共有の列挙。AD のデコイに遭遇する可能性が最も高い2つの操作です
• establishing-persistence — カナリアファイルやフォルダーは、永続化の書き込み先としてよく使われます