開発者のマシン上での認証情報窃取は、対象範囲を大きく広げています。従来のインフォスティーラーは、ブラウザの認証情報ストアやいくつかのクラウド認証情報パスなど、既知の標的の短いリストをもとに動作していました。
現在活動しているマルウェアファミリーは、はるかに広い網を仕掛けています。例えばShai-Huludは、想定される数か所の場所をチェックするのではなく、ファイルシステム全体にシークレットスキャナーをかけ、発見したものすべてを検証していました。
この網羅性の広さこそが、欺瞞(デセプション)技術を実用的なものにしている理由であり、そのスピードこそが緊急性の理由です。収集した情報を検証するハーベスターは、盗んだ認証情報を数時間ではなく数秒でテストします。もはや初期侵害は、調査のための猶予が残された時間帯ではありません。誰かが調査を始めようと思い立つ頃には、認証情報はすでに窃取され、検証され、悪用されています。
ディスク全体を漁って認証情報らしきものを探す攻撃者は、どこに置かれていようとおとり(デコイ)を拾い上げ、他のすべてと同様にテストします。この最初の検証の試みこそが警告シグナルであり、意味を持つには唯一そのタイミングで捉える必要があります。
欺瞞技術がこれまで期待に応えられなかった理由
振る舞い検知は手がかりをもとに動作します。プロセスの動作、ファイル操作、ネットワーク通信を監視し、既知のパターンと照合して、悪意のある活動である可能性を推定します。優れた製品はこの推定の精度が高いものの、それでも「推定」であることに変わりはありません。
ハニートークンはこの推論という要素そのものを排除します。この認証情報は盗まれるためだけに存在するので、通常のエンジニアリング業務でそれに触れる理由は一切ありません。その使用自体が侵害の「証拠」ではなく、使用イコール侵害そのものなのです。判断すべき要素が存在しないため、誤って判断を誤る余地もありません。これが、誤検知率がほぼゼロになる理由です。
ここまでを踏まえると、当然出てくる疑問は「なぜ欺瞞技術がまだ広く普及していないのか」というものです。その答えは概念上の問題ではなく、運用上の問題にあります。おとりを手作業で仕掛けるやり方は、ごく一部の高価値システムを超える規模には対応できません。誰かが何を仕掛けるか、どこに置くかを決め、マシンが再イメージ化されたり開発者が入れ替わったりする中でそれを維持し続ける必要があります。3か月後にひっそりと消えているおとりは、そもそもおとりが存在しない状態よりもたちが悪いものです。なぜなら、チームは「カバーされている」と思い込んでしまうからです。
GitGuardianは、モバイルデバイス管理(MDM)を通じた全社規模での展開を導入し、手作業でのおとり設置という課題を解消しました。すでに全マシンで稼働しているエージェントが、おとりを設置し、誰かが削除しても再設置できるのです。もう一方の課題は、認証情報スティーラーが実際にどう振る舞うかについての研究によって解決されました。スティーラーが何に食いつくかを推測する必要はもはやなく、実際に何を収集するかを研究し、それに合わせて設計すればよいからです。
現在稼働している機能
ハニートークンは数年前からGitGuardianプラットフォームの一部として存在していますが、現在チームがそれを使ってできることは、「おとりの認証情報」という言葉から連想される範囲よりもはるかに広範です。
チームはダッシュボード、API、またはコマンドラインを通じてハニートークンを作成します。その後、攻撃者が探しに来そうな場所ならどこにでも配置します。ソースコードリポジトリ、設定ファイル、社内ドキュメント、デプロイスクリプト、継続的インテグレーション(CI)パイプラインなどです。
設置されたハニートークンが、それが存在するマシンと、書き込まれた認証情報ファイルにひも付けられている様子。イベントテーブルは空であり、これは手つかずのおとりの状態を示しています。
2026年6月以降、この配置対象は開発者のノートパソコンにまで拡大しています。ハニートークンは既存のMDMツールを通じて全社規模で展開されるため、セキュリティチームは各マシンを個別に操作することなく数千台単位のマシンをカバーできます。またダッシュボードでは、どのエンドポイントに実際にデコイが配置されているかが報告されるため、カバーされていると誰かが勝手に思い込む状況を防げます。削除されたデコイは、次回の同期時に再配置されます。
単一エンドポイントにおけるハニートークン保護の状況。最終同期日時、展開されているデコイの数、そのマシンがカバーされている期間が表示されています。このトークンは有効で、これまで一度もトリガーされていません。
運用面で重要なのは、アラートの仕組みです。誰かがハニートークンを使おうとすると、GitGuardianはそのマシン名と、認証情報の出所となったファイルを明記したインシデントを発報し、チームがすでに利用している通知経路——メール、Slack、Teams、ServiceNow、あるいは独自のWebhookなど——にルーティングします。誰も新たなコンソールを監視する必要はありません。これは言葉で言うほど些細なことではなく、多くの検知ツールは、前の週よりも多くのアラートをチームに吸収させようとしてくるものだからです。しかしこの仕組みが求めるのは、「常に対応する価値のあるアラート」を一つ吸収することだけです。
クラウド鍵を超えておとりを拡張する
現時点のGitGuardianのハニートークンはAWSの認証情報であり、そのデコイはGitGuardianが管理するAWSアカウントから発行された実在のキーです。そのキーに対して行われたすべてのAPI呼び出しは、そのキーが属するアカウント内でログに記録されます。そのため攻撃者が認証情報をテストすると、その試みを、発生日時や発信元とともに検知できます。
開発者のマシン上にある大半の認証情報には、これに匹敵する仕組みがありません。Kubernetesクラスタへのアクセス、パッケージレジストリのログイン情報、その他のサービス認証情報はそれぞれ異なる形式を持ち、異なる場所にルーティングされます。そしてこれらの多くは、パッケージレジストリを狙うワームが真っ先に探しに来るものの一部です。これらをカバーするには、単にそれらしく見えるファイルをディスクに書き込むだけでは足りません。攻撃者がそれを試した際に、その試みを認識し、特定の顧客とマシンにまでたどり着ける何かが、受け手側で待ち構えている必要があるからです。
これはまさに現在進行中の取り組みであり、認証情報の種類ごとに作り直すのではなく、意図的に一度だけ構築する形で進められています。アラート発報後の処理は何も変える必要がないため、新しい種類のデコイはどれも、顧客がすでに使っている仕組みの中にそのまま組み込まれます。同じインシデント、同じ通知経路、同じワークフローで対応できるのです。
破綻しないおとりの設計
デコイは、攻撃者が本物の認証情報と見分けがつかない間だけ有効です。この制約こそが、他の何よりもデコイの設計を左右しています。
私たちが追加している認証情報形式は、デコイであることを見破る手がかりとなるような内部構造を一切持ちません。ファイル内の識別子はランダムであり、攻撃者が所有者やアカウントを割り出せるような情報は一切エンコードされていません。そのため、盗まれたデコイは、たとえ入念に調べられても攻撃者に何の情報も与えません。こうしたデコイを支えるインフラは、GitGuardian由来だと特定されうる要素から切り離されています。これは、執念深い攻撃者ならいずれそれを調べにくるだろうという前提に基づいています。
ただし、こうした基本方針を超えたところでは、効果的な欺瞞は、多くの脅威モデルが想定するような精巧なカモフラージュにはそれほど依存しないことがわかっています。というのも、情報を収集するマルウェア自体は、そうしたモデルが想定する敵ほど識別能力が高くないからです。重要なのは、実際の現場で認証情報がどう収集されているかに合わせることであり、これは仮想的な攻撃者を想定して設計するよりもハードルが低く、かつはるかに実用的なアプローチです。
正直に言うべき限界
欺瞞技術が検知できるのは「使用」であって「窃取」そのものではありません。盗まれたものの、その後一度も使われなかったデコイは沈黙したままであり、どんな実装であってもこれを変えることはできません。なぜなら、この仕組みは誰かが盗んだものを実際に行使した瞬間にしか作動しないからです。だからこそ欺瞞技術は、認証情報の探索(ディスカバリー)の代わりではなく、それと並んで機能すべきものなのです。ディスカバリーは、マシン上のどの有効な認証情報が露出しているかを教え、失効させるべきリストを提供します。一方で欺瞞技術は、誰かがその認証情報に手を伸ばした瞬間を教えてくれます。前者だけを運用するチームは、誰も監視していないリスクの棚卸しを持っているにすぎませんし、後者だけを運用するチームは、計測すらしていない露出についてのアラートをただ待っているだけになってしまいます。
今後の展望
この取り組みは2つの方向に進んでいます。設置場所を増やすことと、ハニートークンの種類を増やすことです。
設置場所については、継続的インテグレーション(CI)ランナーとKubernetesクラスタの両方が対象に含まれています。最近のワーム亜種はビルド環境に侵入するよう作られているためです。
カバー範囲については、Kubernetesの設定ファイルとパッケージレジストリのログイン情報を、今後対応を進めていく認証情報の種類として位置付けています。
Google CloudとAzureの認証情報は、優先順位としてはさらに下位に位置しています。というのも、インフォスティーラーの検体を調査した結果、現時点ではこれらがほとんど狙われていないことが分かっているためです。私たちは、実際に窃取活動が行われている領域から優先的に対応範囲を拡大していく方針です。
GitGuardianプラットフォームにおけるハニートークンの位置づけ
ハニートークンは、GitGuardianのシークレット・非人間アイデンティティセキュリティプラットフォームにおける欺瞞レイヤーです。Developer Endpoint Protectionが、開発者の端末群全体にわたってこれらを設置・維持する役割を担っています。認証情報のディスカバリー機能と組み合わさることで、セキュリティチームがあらゆるマシンについて抱く2つの疑問——「そのマシン上で何が露出しているか」「誰かがそれに手を伸ばしたか」——に答えます。
開発者のマシン上における認証情報の攻撃対象領域は拡大を続けており、AIコーディングツールが四半期ごとに新たな経路を追加しています。窃取行為の初期段階で気づけるのは、その経路上に、窃取が起こる前から何かを待ち構えさせているチームだけです。
開発者エンドポイントからアイデンティティの可視化までを一貫して確認できるGitGuardianプラットフォームのライブデモで、実際の動作をご覧ください。
ハニートークンの仕組みを見る
翻訳元: https://www.helpnetsecurity.com/2026/09/10/product-showcase-gitguardian-honeytoken-decoy-service/
