DigiCertサポート経由で証明書初期化コードを奪取──GoldenEyeDogがコード署名の“最後の盾”を突き崩す可能性です

今日の深掘りポイント

• 攻撃は「コード署名＝安全」という前提を崩すものです。署名そのものを“武器化”されると、SmartScreenやEDRのスコアリングは大きく揺らぎます。
• 侵入ベクトルはCA（認証局）のコア鍵ではなく、サポート業務フローという“運用の縫い目”です。ここを突かれると、正規顧客になりすました証明書発行や初期化が現実になります。
• タイムスタンプ付き署名は失効後も有効性が残存するため、封じ込めは一拍遅れます。失効だけに頼らないエンドポイント側の「否認リスト」とWDAC/アプリ制御が鍵になります。
• 企業は「署名の検証」と「発行元（Publisher）単位の許可・否可」を分離し、多層で判断する必要があります。サプライチェーンの信頼は“単一要素最適化”では守れないです。
• SOCは「正規署名かつ初観の発行者」「短期間に大量観測される新規発行者」「通常と異なるタイムスタンプCA」の3条件で高優先のハントを開始すべきです。

はじめに

DigiCertに関連するコード署名証明書の悪用を、中国系クラスターGoldenEyeDogが組織的に進めたとする報道が出ています。報道では、2026年4月にDigiCertのサポートチケット運用を足掛かりに支援担当者の端末を侵害し、正規顧客向けの証明書初期化コードを傍受。これを用いて悪性ペイロードへ正規署名の外形を与え、Windows SmartScreenの警告回避や信頼性の付与に悪用したとされています。さらに同クラスターは2015年から活動し、2024年以降は盗難・不正取得した証明書を一貫して悪用、過去に75以上の証明書濫用が確認されたとの記述もあります。

現時点で公開情報は限定的で、一次情報（公式インシデント開示や技術詳細）は十分ではない可能性があります。本稿は公開された報道ベースの事実関係を整理し、CISO/SOC/Threat Intelの視点で「何が本質的に危ういのか」「どこから手を打つべきか」を掘り下げます。一次情報の追加があれば、評価は適宜アップデートすべき前提でお読みください。

参考：報道記事（セカンダリ情報）

• GoldenEyeDog Threat Group Targets DigiCert Code Signing Certificates (GBHackers)

深掘り詳細

事実（報道で示されたポイント）

• 攻撃主体は中国系クラスター「GoldenEyeDog」。2015年から活動し、2024年以降は盗難・不正取得したコード署名証明書によるSmartScreen回避と“正当性の外形付与”を常套化したと報じられています。
• 2026年4月、DigiCertのサポートチケット経路を用いたマルウェア流し込みでサポート担当者端末を侵害。これにより正規顧客向け「証明書初期化コード」を傍受でき、悪性バイナリに正規署名を施せた、というストーリーです。
• 過去に75超の証明書悪用が確認されているとの記述があり、継続的・反復的な運用の成熟がうかがえると報じられています。

注記：上記は現時点の公開報道に基づく要約です。CAのルート鍵や中間鍵の侵害を示す一次情報は確認できていません（本件の核心は“鍵”ではなく“運用フローの乗っ取り”と理解すべきです）。一次ソースの不足により、細部は今後の公式開示で変動する可能性があります。

インサイト（なぜ痛いのか／どこが急所か）

• 「鍵ではなく運用」を突くサプライチェーン攻撃です
  コード署名の信頼モデルは、鍵素材（HSM・トークン）と身元確認（発行プロセス）の両輪で成立します。今回のポイントは後者——サポート起点で顧客側の初期化トークン／コードに相当する“運用の要”を奪われた点です。鍵そのものに触れずとも、結果として“正規発行に見える証明書”を攻撃者が得る経路が開きます。
• 「タイムスタンプが“盾”にも“刃”にもなる」現実です
  Windowsのコード署名検証では、有効なタイムスタンプが付与されると、失効時点以前の署名は引き続き検証を通りやすい設計です。CAが後追いで失効しても、既に時刻押印済みの不正署名物は長く環境に残存し得ます。封じ込めは「エンドポイント側での明示的なブロック（発行者・シリアルなどの否認）」とセットで設計すべきです。
• 「署名＝安全」という単純モデルの時代は完全に終わった、の再確認です
  多くのEDRやゲートウェイが署名有無・発行者レピュテーションに重み付けします。攻撃者が“正規発行者の外形”を奪取できるなら、静的信頼は逆手に取られます。署名は“必要条件”ではあっても“十分条件”ではありません。プロセスの振る舞い、出自、初観性、配布経路の整合性まで重ねて見るゼロトラスト的な検証が要ります。

脅威シナリオと影響

以下はMITRE ATT&CKに沿って想定する仮説ベースのシナリオです（仮説であり、実際のインシデント詳細は今後の一次情報で再評価が必要です）。

• シナリオA：サポートワークフロー乗っ取りによる「なりすまし発行」
  • 初期侵入: T1566.003（Phishing via Service）/ T1190（Public-Facing Application Exploit）を介してサポートポータルや担当端末に到達
  • 実行: T1204.002（User Execution: Malicious File）
  • 資格情報・トークン窃取: T1552.004（Unsecured Credentials: Private Keys）相当の機密、または初期化コード・セッション情報の奪取
  • 能力獲得: T1588.003（Obtain Capabilities: Code Signing Certificates）
  • 防御回避: T1553.002（Subvert Trust Controls: Code Signing）
  • 影響: 正規顧客名義に見える証明書で悪性バイナリを署名、配布チャネル（サイト・メール・広告）で被害拡大
• シナリオB：署名済みローダを用いた高速展開
  • 配布: T1566.002（Spearphishing Link）/ malvertising / SEOポイズニング
  • 実行後: T1059（Command and Scripting Interpreter）, T1055（Process Injection）, T1218（Signed Binary Proxy Execution）で横展開準備
  • 防御回避: 署名によりSmartScreenや一部アプリ制御の閾値を回避（T1553.002）
• シナリオC：CAエコシステムの周辺侵害深化（仮説の上限）
  • 横展開: T1021（Remote Services）, T1047（WMI）
  • 目的: サポート連絡網・再発行プロセス・タイムスタンプサーバ等の運用資産を足がかりに持続化（T1053.005 Scheduled Task 等）
  • 注：CAのルート／中間鍵侵害は現時点で示されていません。本シナリオは“運用周辺”の深掘りの仮説に留めます。

影響面の要点

• ベンダーブランド毀損の深刻度が高いです。発行者名（Publisher）欄に正規企業名が表示されれば、ユーザも自動化検知も判断を誤りやすいです。
• 失効・ブロックのレイテンシが被害曲線を押し上げます。時刻押印済みの不正署名物は“静かな残骸”として長く環境に潜みます。
• 日本国内のサプライヤ網でも、外注先のサポートBPO・ヘルプデスク経由の侵害が波及しやすいです。調達・サポート契約に“セキュリティ附帯要件（添付ファイル制限、分離端末、EDR、サンドボックス）”を明記すべきです。

セキュリティ担当者のアクション

優先度高から並べます。実装は段階的に、逸脱時のビジネス影響を織り込んで進めるのが現実的です。

• 署名を“ファクタの一つ”に格下げする運用へ
  • EDR/ゲートウェイで「有効署名＝低リスク」の重み付けを緩め、振る舞い・初観性・配布経路の整合性を重視するスコアリングに改めます。
  • 検知ユースケースを新設：
    • 直近7〜14日で初観の発行者による署名ファイルの実行アラート
    • DigiCert系発行者で“通常と異なるタイムスタンプCA”または“短期に大量観測”の相関アラート
    • 署名は有効だが配置パスがユーザ書き込み領域（Downloads, AppData等）の実行アラート
• エンドポイントの明示的ブロック戦術
  • WDAC/Applockerで“許可リスト型”を段階展開（監査→限定適用→本番）。Publisher Allowに加え、否認（Deny）ルールを発行者・シリアル単位で即応適用できる運用を整えます。
  • 重要端末では「ユーザ書き込み領域からの実行禁止」を原則化し、署名有無に関わらずブロックします。
• 失効の“実効性”を確保するネットワーク整備
  • OCSP/CRLの外向き通信を正常化（プロキシ・SSL検査で阻害しない）。疎通監視をダッシュボード化し、失効確認がソフトフェイルにならないようにします。
  • タイムスタンプサーバへの通信を可視化し、新規・異常なTSAへのアクセス急増を検知します。
• 自社コード署名ガバナンスの強化（開発組織向け）
  • 鍵はHSMまたはクラウド署名基盤に隔離。署名はCI/CDの中でのみ実施し、二人承認・短期有効の発行者トークンを強制します。
  • 発行済み証明書・シリアル・タイムスタンプCAの台帳を整備し、SOCと共有。SOCはこの台帳にない発行者名「自社名義」検出を高優先でアラートします（ブランドなりすまし検知）。
  • 侵害時プレイブックを事前整備：失効申請、EDR/WDACのDeny配信、顧客告知、配布チャネル停止、代替署名経路の切替までを訓練します。
• サプライヤ／BPOの“運用の縫い目”対策
  • サポート窓口は、添付ファイル受領を原則サンドボックス経由に限定。支援端末は“対外非信頼ゾーン”として分離し、データ持ち出し・横展開の経路を最小化します。
  • サポート関連SaaS（チケット・チャット）に対するフィッシング対策（リンク展開の無効化、URLリライトルール、MFA強制）と、監査ログのSOC連携を必須化します。
• Threat Intelと広報の連携
  • 悪用証明書のシリアル・発行プロファイルを入手可能な範囲で収集し、インテリジェンス・ブロックに反映します。
  • “署名の見た目は正規でも危険がある”ことを顧客・社内に啓発。サプライチェーン攻撃の異常時に備えた広報テンプレートを用意します。

最後に一言です。今回の示唆は単純です。「署名は必要、でも十分ではない」です。攻撃者が運用の縫い目を縫って“正規の顔”を奪う時代に、私たちは“署名の外側”で真贋を確かめる力を持たねばならないです。ゼロトラストは人とネットワークだけの話ではなく、実行ファイルにも適用する時代です。今日できる最小の一歩から、現場で前に進めていきたいです。

参考情報

• GoldenEyeDog Threat Group Targets DigiCert Code Signing Certificates (GBHackers)