カナリアトークン.

カナリアトークンは、URL・文書・DNS ホスト名・ファイル・実行ファイル・クラウド資格情報といった、組み込み可能な小さなトリップワイヤであり、開封・実行・利用された瞬間に制御サーバーへコールバックします。トークンには正規の用途がないため、あらゆるコールバックは構造上、侵入・内部不正・データ漏えいを示す高信頼のシグナルとなります。セキュリティチームはファイル共有・ソースコード・メールボックス・SaaS アプリにカナリアトークンをばらまき、侵害がノイズの多い検知層に到達するはるか前の段階で早期警告を得ます。

最もよく知られた実装は、Thinkst の無料 Canarytokens サービス（セルフホストも可能）で、10 年以上にわたってトリップワイヤ用の URL や文書を発行してきたほか、2017 年には AWS API キートークン を追加しました。重要な設計上のポイントは トランスポート です。多くのトークンは DNS 経由で発火するため、セグメント化されたネットワークの奥深くで開かれたおとり文書でも、そのユニークなサブドメインが解決された時点で警告が発せられます。ホストに直接の HTTP 送信経路がなくても機能するのです。各アラートには送信元 IP、ユーザーエージェント、タイムスタンプが含まれます。運用面ではアーティファクトの種類が重要で、おとりの AWS キーは攻撃者が sts get-caller-identity を実行した瞬間に警告を発します。ただし防御側は、Thinkst がホストするキーはビーコンドメインを含む呼び出し元 ID を返すことを知っておくべきで、これは巧妙な攻撃者が気づきうる「手がかり」となります。これがセルフホスティングを推す論拠の一つです。

トークンは配置場所ごとにユニークにデプロイし、アラートによってどの共有・リポジトリ・メールボックスが触られたかを正確に特定できるようにし、あらゆるコールバックをインシデント対応のトリガーとして扱いましょう。

flowchart LR
  A[防御側がトークンを発行<br/>URL / 文書 / AWS キー / DNS] --> B[ファイル共有・リポジトリ・<br/>メールボックス・SaaS に設置]
  B --> C[攻撃者が開封・<br/>実行・解決する]
  C --> D{トランスポート}
  D -->|HTTP| E[制御サーバーへコールバック]
  D -->|DNS| F[ユニークなサブドメインを解決<br/>HTTP 送信経路なしでも機能]
  E --> G[アラート: 送信元 IP、UA、タイムスタンプ]
  F --> G
  G --> H[高信頼な IoC →<br/>インシデント対応]