ハニートークンとデセプションで侵入に早く気づく。触られた時点で通知される偽の認証情報と偽ファイルの置き方

侵入を検知する仕組みの多くは、正常な状態との差を見て異常を拾います。ログの量が多い環境では、正常の幅が広く、その幅の中に攻撃者の操作が紛れ込みます。アラートの大半が業務上の操作だったという経験は、SOCを運用していれば一度はあるはずです。

ハニートークンは、この問題を逆方向から扱います。正規の業務では誰も使わない偽の認証情報や偽のファイルを環境の中に置き、それが触られたこと自体を通知の条件にします。探すべき異常を先に作っておくので、正常との比較が要りません。想定読者は、SOCの運用やログ監視を担う担当者と、クラウドやActive Directoryを管理する情報システム担当です。

この記事では、ハニートークンが誤検知の少ないアラートになる理由、ハニーポットとの違い、置き場所の設計、オープンソースのCanarytokensの仕組み、SIEMとSOCへの繋ぎ方、見破られにくくする工夫、運用と法務の注意を順に整理します。記述はMITRE Engage、MITRE D3FEND、MITRE ATT&CK、NIST SP 800-53 Rev. 5、Canarytokensの公式ドキュメントとリポジトリ、Microsoft Learnで確認できた範囲に限り、確認できなかった事項は書きません。

触られた時点で異常と言える理由#

通常の検知ルールは、正常な操作と攻撃者の操作が同じ種類のイベントとして記録される前提で作られます。管理者もファイルを開き、攻撃者もファイルを開きます。そのため、回数や時間帯や組み合わせで両者を分けようとし、分け方が甘いと誤検知が増え、厳しいと見逃しが増えます。

ハニートークンではこの前提が変わります。正規の業務手順はその偽物を一度も参照しないように作られているため、触られたという事実だけで、候補は社内の誤操作か侵入者の探索のどちらかに絞られます。閾値もベースラインも要りません。

攻撃者の側から見ると、侵入後の探索は避けにくい工程です。MITRE ATT&CKは、ファイル内に残された認証情報を探す技術をT1552.001 Credentials In Files、ディレクトリやファイルを列挙する技術をT1083 File and Directory Discovery、ドメインのアカウントを列挙する技術をT1087.002 Domain Account、ソースコードの保管場所から情報を集める技術をT1213.003 Code Repositoriesとして整理しています。ハニートークンは、こうした探索で攻撃者が拾いに来るものの形をしたおとりです。

MITRE Engageは、攻撃者との関与(adversary engagement)の計画と議論のための枠組みで、目標、アプローチ、アクティビティの3階層で構成されています。公開データでは、アクティビティEAC0005 Luresを「攻撃者から特定の反応を引き出すための、おとり、パンくず、餌として意図された欺瞞的なシステムとアーティファクト」と定義しています。同じくEAC0022 Artifact Diversityは多様なネットワークとシステムのアーティファクトを攻撃者に提示すること、EAC0011 Pocket Litterは関与のストーリーを支えるデータと定義されています。

MITRE Engageは、Luresの前提となる攻撃者の弱みとして、ネットワークやシステムの資源に触れたときに仕掛け線(tripwire)を踏んだり、検知しやすい異常な振る舞いをしたりする点を挙げています。ハニートークンは、この仕掛け線を最も軽い形で実装したものと言えます。

あわせて読みたい

アラート待ちから抜け出す脅威ハンティングの始め方

ハニーポットとハニートークンの違い#

似た言葉にハニーポットがあります。どちらもおとりですが、置くものの大きさと運用の重さが違います。

MITRE D3FENDは、防御技術の分類の中にDeceiveという戦術を置いています。その下で、Decoy Environmentを「攻撃者を欺く目的のホストとネットワークからなる環境」と定義し、同義語にHoneypotを挙げています。一方、Decoy Objectは「攻撃者を欺く目的で作成して配置するオブジェクト」で、その下にDecoy File(D3-DF)、Decoy User Credential(D3-DUC)、Decoy Session Token(D3-DST)、Decoy Network Resource(D3-DNR)などが並びます。この記事でハニートークンと呼んでいるのは、主にDecoy Objectの側です。

NIST SP 800-53 Rev. 5の管理策SC-26 Decoysは、攻撃の検知、そらし、分析のために、悪意ある攻撃の標的となるよう設計した構成要素をシステムに含めることを求めています。補足説明では、おとりを「ハニーポット、ハニーネット、欺瞞ネット」と例示し、そらした悪性コードが組織のシステムに感染しないよう隔離措置が必要であること、用途によっては導入前に法務部門(Office of the General Counsel)への相談が必要になりうることを述べています。SC-26の関連管理策には、SC-30 Concealment and Misdirection(隠蔽と誤誘導)、SC-35 External Malicious Code Identification、SI-4 System Monitoringなどが挙げられています。

SC-26の補足説明が想定しているのは主にハニーポット型のおとりです。ハニートークンは本番環境の中に置くため、ハニーポットほどの隔離は要りませんが、偽の認証情報が本物の権限を持っていないこと、偽物が触られても実害に繋がらないことは、別の形で担保する必要があります。この点は後の運用の節で扱います。

置き場所の設計#

置き場所は、攻撃者が侵入後に探しに行く場所から逆算します。自社の環境で、侵入者が真っ先に漁りそうな場所を洗い出し、それぞれに1種類ずつ置くところから始めるのが現実的です。

偽の認証情報と偽のAPIキー#

偽の認証情報は、最も効果が出やすいおとりです。攻撃者は侵入した端末で、設定ファイルやシェルの履歴、クラウドCLIの資格情報ファイルを探します。そこに本物らしい形式の偽キーを置いておけば、攻撃者がそれを試したときに通知が届きます。通知までの時間は種類と経路によって異なり、後の表のAWSキーのように時間差が出るものもあります。

置くときは、本物のキーと同じ場所、同じ形式に揃えます。クラウドの資格情報ファイルであれば、そのクラウドのCLIが読む既定のパスとファイル形式に合わせます。偽キーには業務の資源へのアクセス権を与えず、利用された記録だけが残るように作ります。

あわせて読みたい

シークレット管理の実務。APIキー・認証情報をハードコードせず、Vaultやマネージドサービスで守りローテーションする

ソースリポジトリ#

ソースリポジトリには、外部に漏れた場合の検知という別の役割もあります。社内リポジトリの設定ファイルに偽のキーや偽の内部URLを置いておくと、リポジトリが複製されて外部に持ち出されたあとでも、そのキーが使われたりURLにアクセスされたりした時点で通知が届きます。複製されただけでは発火しません。侵入の検知と漏えいの検知を1つのおとりで兼ねられる点が、他の置き場所にない利点です。

一方で、開発者が誤って使うことがないよう、変数名や周辺のコメントで使われない理由を示しすぎると、攻撃者にも見破られます。どこまで社内に周知するかは、後の節で扱う運用の設計と一緒に決めます。

ファイルサーバと偽の文書#

共有フォルダには、給与一覧やパスワード一覧のような目を引く名前の偽文書を置きます。文書を開いたときに外部のURLやホスト名を参照するよう細工しておけば、開かれた時点で通知が届きます。フォルダそのものを閲覧されたときに通知する方法もあります。具体的な仕組みはCanarytokensの節で説明します。

Active Directoryの偽アカウント#

Active Directoryには、業務で一度も使わない偽のユーザーアカウントを作ります。列挙そのものは検知できませんが、そのアカウントを使った認証の試行や、そのアカウントを要求先とするKerberosのチケット要求がドメインコントローラーに記録されれば、誰かがディレクトリで見つけたアカウントを試した可能性が高いと判断できます。

Microsoft Defender for Identityには、この用途のためのHoneytokenタグがあります。Microsoft Learnは、honeytokenアカウントを「攻撃者への罠として設定するもので、通常は休眠している」と説明し、honeytokenアカウントからのサインインはすべてアラートになると記載しています。タグはユーザーとデバイスに付けられます。

ATT&CKのKerberoasting(T1558.003)のページに掲載された検知用のアナリティクは、Kerberosのサービスチケット要求(イベントID 4769)の中から、RC4暗号(etype 0x17)での要求や短時間の大量要求、通常の利用パターンから外れたサービスアカウントへの要求を探す方法を挙げています。これを応用すると、実在しないサービスを名乗るサービスプリンシパル名(SPN)を偽のアカウントに登録しておき、要求先を示すService Nameがそのアカウントである4769が記録されたこと自体を検知条件にできます。4769のAccount Nameは要求した側のアカウントなので、照合するフィールドを取り違えないようにします。正規のクライアントはそのサービスに接続しないため、要求が記録された時点でSPNの列挙結果を使った試行の可能性が高いと判断できます。

あわせて読みたい

Kerberoastingとは何か。サービスアカウントの弱いパスワードが狙われる仕組みと対策

データベースの偽レコード#

データベースには、実在しない顧客の行を混ぜておきます。その行だけが持つ一意のメールアドレスや電話番号を使えば、データが外部に持ち出されたあとに、その連絡先への着信として漏えいに気づけます。クエリそのものを検知する方法もあり、テーブルへのアクセスを検知する仕組みはCanarytokensにもあります。

Canarytokensの仕組み#

Canarytokensは、Thinkst Applied Researchが公開しているハニートークンの作成と通知の仕組みです。公式ドキュメントは「ネットワーク、コンピューター、クラウドのための動体検知センサーのようなもの」と説明しています。作成画面で種類を選び、通知先のメールアドレスと、置いた場所を思い出すためのメモを入力すると、偽物が生成されます。

Canarytokensの公式ドキュメントは、典型的なCanarytokenを「一意のURLまたはホスト名」と説明しています。URLのパス部分は柔軟で、トークン固有の部分さえ含んでいれば別のファイル名でアクセスされても発火します。メモについては、運用を続けると数千個を各所に配置することになるため、発火したときに置いた場所が自明になる説明を書くよう求めています。

仕組みの中心は、名前解決とHTTPアクセスです。DNS型のトークンでは一意のホスト名が発行され、そのホスト名を誰かが名前解決しようとした時点で通知されます。偽の文書やフォルダは、開かれたり閲覧されたりしたときにこのホスト名やURLを参照するよう作られているため、ファイルそのものに監視用のプログラムを入れなくても検知が成り立ちます。

主な種類の動き方を、公式ドキュメントの記載に沿って整理します。

種類の一覧には、ほかにもAdobe PDF、Azure Entra ID、Kubeconfig、MS Excel、Network Folder、QR Code、Unique Email Address、WireGuardなどが並んでいます。自社の環境で攻撃者が探しそうなものに近い種類を選ぶのが基本です。

表の注意書きは、そのまま運用上の制約になります。AWSのキーは通知までに時間差があります。Word文書はOfficeで開かれなければ発火しません。desktop.iniやSQL Serverのトークンは名前解決を合図にしているため、外向きのDNSを厳しく絞っている環境では通知が届かない可能性があります。置く前に、その環境から実際に発火するかを試しておきます。

あわせて読みたい

アウトバウンド通信制御(egress filtering)の設計。侵入後のC2通信と持ち出しの経路を出口で絞る

自前で運用する場合#

Canarytokensは、canarytokens.orgの公開サービスとして使えるほか、ソースコードがGitHubで公開されており、自前のサーバで動かせます。リポジトリのLICENSEファイルは、GNU General Public License Version 3を基本に、独自の明確化と例外を付けた条件で配布すると記載しています。公式リポジトリは導入方法としてDocker構成の利用を推奨しており、Docker構成のリポジトリはBSD-3-Clauseで公開されています。

自前で運用すると、トークンに使うドメインを自社で決められます。公式リポジトリのREADMEによると、通知はメールとWebhookで送られ、同じ発信元IPからの通知は既定で1分あたり1件に抑えられます。抑えられた分も記録はデータベースに残り、管理画面で確認できます。Webhookが5回続けてエラーを返すと、そのWebhookは無効になります。この2つの挙動は、SIEMへの連携を組むときに影響します。

ただし、自前の環境ではすべての種類を作れるわけではありません。READMEによると、AWS API Keys型はIAMユーザーの割り当てにAWS側の基盤を使い、その基盤は非公開のリポジトリに移されています。必要な設定がなければ、自前のインスタンスではAWSキー型の作成が無効になります。

公開サービスを使う場合は、置いた場所のメモや発火時の情報が外部のサービスに送られることになります。業務のデータをどこまで外部に出してよいかは、組織の規程に照らして判断します。

SIEMとSOCへの通知の繋ぎ方#

ハニートークンの通知は、確度が高い一方で件数が少ないため、ふだんのアラートの流れに埋もれると見落とされます。担当者個人のメールアドレスに届くだけの運用では、休暇や異動で誰も読まなくなります。

通知は、SIEMまたはSOCのチケット管理に集約します。Canarytokensを使う場合は、WebhookをSIEMのHTTP受け口や自動化基盤に向けます。Active Directoryの偽アカウントであれば、ドメインコントローラーのセキュリティログに記録された認証とチケット要求のイベントを、そのアカウント名で絞る検知ルールをSIEMに書きます。自社のクラウドアカウントで発行した偽キーであれば、そのアカウントの監査ログでそのキーのアクセスキーIDが現れたことを条件にします。Canarytokensが発行したAWSキーは自社のアカウントの監査ログには記録されないため、Canarytokensからの通知を取り込む経路で扱います。

発火時の初動では、まず台帳で置き場所を確かめ、社内の作業による発火かを切り分けます。そのうえで、発信元のIPアドレスや端末、使われたアカウントを起点に、前後のログをたどります。偽物が見つかった場所から逆算すると、攻撃者がどの端末やどの共有に到達しているかの手がかりになります。発火したトークンは証拠として扱い、すぐに削除せずに状態を保全します。

あわせて読みたい

インシデント発生時の初動対応。最初の1時間で何をするか

攻撃者に見破られにくくする工夫#

ハニートークンは、攻撃者が本物だと信じて触ることで初めて働きます。見破られると、攻撃者はそれを避けるだけでなく、防御側が監視していることを知ります。

• 名前と形式を環境に合わせる。社内の命名規則や、本物のキーと同じ形式、同じ保存場所に揃える
• 不自然に新しく見せない。作成日だけが新しいアカウントや、中身が空の文書は目立つ
• 目を引きすぎない。管理者パスワード一覧のような露骨な名前ばかり並べると、かえって疑われる
• 種類と場所を散らす。MITRE EngageのArtifact Diversityのように、複数の種類を複数の場所に置き、1つを見破られても他が残るようにする
• 周辺のもっともらしさを整える。偽のアカウントに説明欄や所属を入れ、偽の文書に本物らしい中身を入れる。EngageのPocket Litterに相当する作業
• 設置の事実を公開文書に書かない。社内の広い範囲に共有する手順書やWikiに、トークンの一覧や置き場所を載せない

公開サービスのトークンは、発行元のドメインが決まっています。そのドメインを知っていれば、偽物だと推測される可能性があります。見破られにくさを重視する場合は、自前で運用して自社で用意したドメインを使う方法があります。

運用上の注意#

社内の誤操作と自動処理#

誤検知が少ないとはいえ、ゼロにはなりません。発火の原因になりやすいのは、人よりも自動処理です。ファイルサーバの全文検索のインデックス作成、ウイルス対策製品による文書の検査、バックアップ、移行作業での一括コピー、シークレットスキャンなどが、偽物に触れる可能性があります。導入時に、どの自動処理が置き場所を走査するかを確認し、発火した場合に切り分けられるよう台帳に記録します。

偽のキーを置いたリポジトリでは、シークレットスキャンが偽キーを本物と判定して別のアラートを上げる可能性もあります。この場合は、スキャンの除外設定で黙らせるのではなく、スキャンの担当とハニートークンの担当の間で、どのキーが偽物かを共有する運用にします。除外設定そのものが、攻撃者にとっての手がかりになりうるためです。

権限と実害の切り離し#

偽の認証情報には、業務の資源へのアクセス権を与えません。偽のADアカウントは特権グループに入れず、ログオンできる端末を制限します。偽のクラウドキーは、使われたことが記録されるだけで、どの資源にも触れない状態にします。偽物が本物として機能してしまうと、おとりが侵入経路になります。

監査への説明#

監査や棚卸しでは、使われていないアカウントや、出所の分からない認証情報が指摘の対象になります。ハニートークンは、その指摘にそのまま該当する形をしています。台帳を監査担当と共有し、統制上の位置づけを説明できるようにしておきます。NIST SP 800-53 Rev. 5のSC-26 DecoysやSC-30 Concealment and Misdirectionに対応づけておくと、管理策としての説明がしやすくなります。

法務とプライバシーへの配慮#

NIST SP 800-53 Rev. 5のSC-26は、用途によっては導入前に法務部門へ相談する必要があると述べています。日本の組織でも、次の点は導入前に法務や個人情報保護の担当と確認しておきます。

• 従業員の操作を検知する仕組みになるため、就業規則や情報セキュリティ規程で、監視の目的と範囲を定めているか
• 文書を開いたときに外部参照する仕組みは、社外の人が開いた場合にもその人の環境の情報が記録されうる。社外に送る文書や顧客に渡すデータには仕込まない
• 公開サービスを使う場合、置き場所のメモや発火時の情報が外部に送られることを、データの取り扱い規程と照らして問題がないか
• 発火から得た発信元の情報は、自社の防御と調査の範囲で使う。相手の機器に対して調査目的で接続したり、反撃したりしない

ハニートークンは、自社が管理し、設置の権限を持つ環境の中に置くものです。他社のシステムや、許可を得ていない環境に置いてはいけません。

あわせて読みたい

ログ管理の基本。何を・どこまで・どれだけ残すか

小さく始めて台帳で育てる#

ハニートークンは、1件ずつなら数分で置けます。一方で、置いただけで台帳も通知経路もない状態では、発火しても意味を読み取れません。最初は、クラウドの偽キー、共有フォルダの偽文書、ADの偽アカウントのように、性質の違う場所に数件だけ置き、通知がSIEMに届いて初動手順が回ることを確かめるところから始めます。そのうえで、脅威ハンティングや過去のインシデントで分かった攻撃者の探索経路に合わせて、置き場所を増やしていきます。