PAMとOpenSSHの改ざんで認証そのものが乗っ取られた—約10年潜伏の痕が示す“静かな諜報”の現在地です

今日の深掘りポイント

• 認証スタック（PAM/OpenSSH）そのものを改ざんすることで、パスワードリセットやセッション終了が無力化される構造的リスクが顕在化しました。
• 研究者は少なくとも9種類のバックドア亜種を確認しており、長期潜伏を前提に検出回避の進化が見て取れます。
• 侵害後対策（EPP/EDR、アカウント無効化等）に依存した従来の運用は限界で、信頼の根（Trust Anchor）をどう再構築するかが当面の勝負どころです。
• 監視の主戦場を「ログの振る舞い」から「バイナリの真正性」へシフトし、OSレベルの測定・検証（FIM/IMA/TPM）を取り込む設計が必要です。
• キーマテリアル（SSHホスト鍵・ユーザ鍵・Vault/CI/CD用シークレット）の全面再発行と、ネットワーク境界での追加検証（mTLS/デバイス証明）を併用するのが現実解です。
• 直近の運用意思決定を要する即時性が高く、同時に再発防止にはアーキテクチャ変更が不可欠という“二段構え”の対応が求められます。

はじめに

ログインという日常の営みが、もっとも信用してきた“土台”から崩されると、私たちの運用の前提がひとつずつ意味を失っていきます。今回のケースは、PAMやOpenSSHというOS認証の心臓部が静かに書き換えられ、通常の監視や保守手順の死角に潜られたという報告です。約10年にわたり複数亜種が使い分けられ、しかも振る舞いが通常の管理活動に見えるよう巧妙に装われていたとされます。表層のアカウント対策では届かない、もっと深い場所での“信頼の再定義”が必要な局面です。

本稿は公開情報と提供資料に基づく予備分析です。元調査はSygniaによるもので、The Hacker Newsが報じています。一次資料のハッシュやIoCが未出そろいの段階であり、以下の技術的推定を含む部分は仮説として提示します。

参考: The Hacker News: China-Linked Hackers Backdoored Linux Login Software (2026-06-13)

深掘り詳細

事実関係（いま分かっていること）

• 中国に関連する脅威グループ（報道ではSygniaが“Velvet Ant”として追跡）が、LinuxのPAMおよびOpenSSHコンポーネントを改ざんし、バックドアを潜ませていたと報じられています。
• 最低9つの異なるバックドア亜種が確認され、約10年にわたり潜伏していたとされています。
• 改ざんは信頼済みのログインプログラム内部で行われ、通常の管理操作（ログイン、パスワード変更、セッション操作）に偽装されるため、表面的な対処（パスワードリセットやユーザ無効化）が効果を持たない状況が生まれていました。
• 一部はインターネット直結ではないネットワークを狙い、インターネット接続のある中継システムを経由して侵入・維持されたとされています。

出典: [The Hacker News 上記記事]

編集部のインサイト（なぜ厄介か）

• 認証経路自体の改ざんは「有効なアカウントを無効化する」「MFAを強制する」といった施策の“直上”を踏み越えます。ホストに到達された段階で、ホスト内部の検証ロジックが攻撃者に従属してしまうからです。
• 10年スパンでの潜伏は、検出回避技術（署名値の整合、タイムスタンプ偽装、パッケージ検証のすり抜け等）が段階的に洗練されてきたことを示唆します。9亜種という多様性は、ディストリ/カーネル差分や運用標準に合わせた“カスタム適応”の存在も仮説として読み取れます。
• いわゆる「クリーンアップの自動化」（失効・削除・再起動）や、ログ相関での異常検出に依拠した運用は、この手の“土台改ざん”には届きません。信頼の起点をどこに置くか（TPMでの計測、IMA/EVMでの実行前検証、パッケージ検証を強制モードで運用など）という設計問題に踏み込む必要があります。
• 報道は政府・防衛・サプライチェーン領域への静かな諜報活動を示唆しています。域外転送が難しい環境では、資格情報の収集と横展開の継続性が主眼になりがちで、発覚がさらに遅延します。監視のKPIを「外向き流量の異常」だけに置かないことが肝要です。

脅威シナリオと影響

以下は公開情報に基づく仮説シナリオです。MITRE ATT&CKは典型マッピングであり、個別事例では差異がありえます。

• シナリオA：認証フロー改ざんによる持続化

  • 初期侵入後、PAMモジュールやsshdバイナリ/関連ライブラリを改変し、“特定条件（マジックパス/特定鍵/送信元）”で常に成功させるフックを仕込む仮説です。
  • 想定ATT&CK
    • T1556.003 Modify Authentication Process: Pluggable Authentication Modules（PAM改ざん）
    • T1574 Hijack Execution Flow（ライブラリ挿げ替え/ロード順序悪用の可能性）
    • T1036 Masquerading（通常の管理操作に見せかける）
    • T1070 Indicator Removal on Host（痕跡の隠蔽）

• シナリオB：資格情報収集と静かな横展開

  • 認証時のユーザ名・パスワードを捕捉し、正規アカウントで横展開する静的な諜報運用です。
  • 想定ATT&CK
    • T1056.001 Input Capture: Keylogging/ログインプロンプトの傍受
    • T1078 Valid Accounts（収集した正規資格情報の再利用）
    • T1021.004 Remote Services: SSH（SSH経由の横展開）

• シナリオC：分離ネットワークへの段階侵入

  • インターネット接続のある踏み台や管理サーバに持続化を確立し、オフライン/準オフライン環境へ認証情報を中継して侵入を拡大する手口です。
  • 想定ATT&CK
    • T1105 Ingress Tool Transfer（中継によるツール/設定持ち込みの可能性）
    • T1071 Application Layer Protocol（C2や中継を通常プロトコルに偽装）
    • T1041 Exfiltration Over C2 Channel（資格情報等の段階的流出）

影響評価の要点です。

• パスワードリセットや鍵失効の効果が限定的になり、インシデント封じ込めの“常套手段”が効かなくなるリスクが高いです。
• バックドアが収集した資格情報により、クリーンな再構築後も“戻り侵入”される二次被害が想定されます。鍵・トークン・機密設定の全面再発行なしに終息宣言は出せない前提です。
• 認証基盤の一部が改ざんされていた場合、監査証跡の信頼性も毀損している可能性があり、事後精査の難易度が上がります。時間軸での完全復元は限定的と考えるべきです。

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

短期の被害抑止と、中長期の“信頼の再構築（Trust Reset）”を分けて設計するのが現実的です。

• 直ちにやること（初動とスコーピング）

  • 侵害疑いホストはネットワーク分離します。root化前提でメモリ/ディスクのフォレンジック取得を優先します。
  • パッケージ真正性の検証をオフラインで実施します。
    • RPM系: 「rpm -Va」で改変兆候（S/M/5/T 等）を確認、「rpm -V openssh-server pam」など重点検証します。
    • DEB系: 「debsums -s openssh-server libpam-modules」「dpkg -V」で検証します。
    • 重要パスのハッシュ比較: /usr/sbin/sshd、/lib*/security/pam_.so、/etc/pam.d/ を既知良版と比較します（検証自体は信頼できる別環境で実施します）。
  • 変更監査の追加設定を行います（広域ハンティングの継続用）。
    • auditd例: 「-w /usr/sbin/sshd -p xatr -k ssh_bin」「-w /lib*/security -p wa -k pam_mod」「-w /etc/pam.d -p wa -k pam_cfg」など。

• 封じ込めを効かせるための再発行・失効

  • SSHホスト鍵・ユーザ鍵（含むJIT/JEA用途）・Vault/CI/CDシークレット・APIトークンを“範囲を広め”に再発行します。順序は1) ホスト鍵→2) 管理者鍵→3) サービス/機械アカウント→4) 一般ユーザの順で、旧鍵の即時失効を伴走させます。
  • 収集済みの資格情報逆利用に備え、踏み台・ジャンプホストの認可リストを一時的に最小化し、相互信頼（known_hosts/authorized_keys）の棚卸しを実施します。

• 再構築（Rebuild from Known-Good）

  • 影響範囲のホストは“上書き修復”ではなく再イメージ化します。ベースイメージは署名検証済みの既知良ソースから取得し、構成管理もクリーンなコントロールプレーンに一時退避します。
  • 復旧手順には「復元直後にキーマテリアルを最終交換する」ステップを必ず含めます（復元中に盗聴されていないことを担保するためです）。

• 予防強化（次を起こさないための設計）

  • 実行前検証の強制: Linux IMA/EVMでの測定・検証を有効化し、/usr/sbin/sshd と /lib*/security/pam_*.so を署名必須にします（appraise_tcb相当のポリシー適用を検討します）。
  • ファイル整合性監視（FIM）を“コンプライアンス項目”から“運用必須”へ格上げし、/etc/pam.d、/lib*/security、/usr/sbin/sshd を高感度で常時監視します。
  • 認証の多層化:
    • ホスト内PAMに依存しない境界検証（mTLSベースの端末証明、デバイス姿勢検証、Bastionでの強制プロキシ）を併用します。
    • OpenSSH設定は原則として「PasswordAuthentication no」「KbdInteractiveAuthentication no」「AuthenticationMethods publickey」で固定します。ただし“sshd自体が改ざんされれば無効化され得る”前提を忘れず、ネットワーク側の強制制御と組み合わせます。
  • ハンティングの常設: フリート全体で「ビルドID/ハッシュの同一性」「RPM/DEB検証差分」「PAM設定の逸脱」を継続クエリ化します（osqueryのhash/file/augeasテーブル活用などが有効です）。

• 運用とガバナンス

  • ゴールデンイメージのサプライチェーン（ビルド～署名～配布）の見直しを行い、署名検証の“強制モード”運用に移行します。
  • 重大インシデント前提の卓上演習（IR Tabletops）に「認証基盤の改ざん」をシナリオとして追加し、キーマテリアル全面交換の意思決定と実務オーケストレーションを事前にテストします。

• してはいけないこと

  • 改ざん疑いのあるホストで“そのまま”検証コマンドや鍵再発行を実行しないでください。観測や再発行プロセス自体が盗聴・改変される恐れがあります。
  • “ログに怪しい挙動がない”をもって無影響と判断しないでください。今回の性質上、痕跡の残りにくさは前提条件です。

参考情報

• The Hacker News: China-Linked Hackers Backdoored Linux Login Software (2026-06-13) https://thehackernews.com/2026/06/china-linked-hackers-backdoored-linux.html

本件は、いま取れる即効策と、今後のアーキテクチャ刷新を同時に走らせる必要がある厄介なタイプの脅威です。認証という当たり前を、もう一度“測れる・検証できる・強制できる”設計に組み替えていくことが、最短距離の解だと考えます。皆さんの現場に合った現実解を、今日から一歩ずつ積み上げていきましょうです。