Gitea重大RCE悪用で産業オートメーションのリポジトリが大量流出、LD_PRELOADルートキットで持続化──Red Heronキャンペーンの本質

今日の深掘りポイント

• 「開発基盤＝王冠の宝石」が再び狙われ、GiteaのRCE（CVE-2026-60004）を足がかりに機微な産業向けソースコードが窃取されています。攻撃はインターネット露出の自己ホスト型Giteaに集中しています。
• ポスト侵入はC++バックドア「JITTERLY」とLD_PRELOADルートキット「SIXZUT」で持続化。開発サーバが“静かにOT側の前段”へ変質する、古典的かつ見逃されやすい最悪パターンです。
• 指標全体からは緊急度・実行可能性・確度が高い案件と読み取れる一方、被害の可視化が難しいため初動で「完全再構築・認証情報ローテーション」まで踏み切れるかが勝負です。
• CI/CD秘匿情報・署名鍵・デプロイ鍵・Webhookの一括棚卸しと即時ローテーション、LD_PRELOAD由来のステルス化に対する“オフホスト”検証（ライブCD/EDR外での検査）が鍵になります。
• MITRE ATT&CK的には、Exploit Public-Facing Application → Valid Accounts → LD_PRELOADによるHijack Execution Flowの三段跳びが核となり、Exfiltration Over C2でリポジトリ単位の広域流出へ至るシナリオが妥当です。

はじめに

開発者インフラを起点に知財・顧客・サプライチェーンすべてが芋づる式に奪われる。ここ数年繰り返し見てきた構図ですが、自己ホストのGiteaという“現場の現実解”が狙われた点が今回の重さです。産業オートメーション（SCADA/HMI）関連のソース流出は、単なる設計図の漏洩にとどまらず、将来のOT侵入や模倣製品・逆コンパイルによる脆弱性探索を加速します。報道では、Red HeronがCVE-2026-60004を武器化し、JITTERLYとSIXZUTで持続化したとされます。一次情報が限られる現時点でも、CISOとSOCがやるべきことは明確です。露出Giteaの即時隔離と完全ローテーション、そして“OSごと欺く”LD_PRELOADの罠を外部から見抜く段取りです。

参考：報道まとめ（一次情報の出典が乏しいため、今後のベンダー公式アドバイザリ公開に留意ください）

• Red Heron Exploits Critical Gitea Flaw to Steal Repositories (GBHackers)
  MITRE ATT&CK（技術マッピング用の一次参照）
• T1190: Exploit Public-Facing Application
• T1574.006: Hijack Execution Flow: LD_PRELOAD
• T1059: Command and Scripting Interpreter
• T1078: Valid Accounts
• T1021.004: Remote Services: SSH
• T1041: Exfiltration Over C2 Channel

深掘り詳細

事実関係（報道で確認できる範囲）

• Red HeronがGiteaのRCE（CVE-2026-60004）を悪用し、インターネット露出のGitea環境へ初期侵入したとの報道です。対象は産業オートメーション組織の開発インフラに集中しているとされます。
• 数百リポジトリ規模の窃取、SCADA/HMI関連のソースを含む情報収集が行われたとの記載があります。
• ポスト侵入でC++製Linuxバックドア「JITTERLY」と、LD_PRELOADを用いたルートキット「SIXZUT」を投入。偵察・横展開・持続化のための多機能性（30超の機能を持つとの記載）を特徴とします。
  出典：前掲のGBHackers記事

注：CVEの技術詳細、Gitea公式の修正アナウンス、IOC（ハッシュ・C2・ファイル名）等の一次情報は本稿執筆時点で限定的です。以降の考察は、報道と一般的な攻撃常識（MITRE）に基づく仮説で構成します。

編集部のインサイト（なぜ効いたのか／何が見落とされがちか）

• 自己ホストGiteaの「運用の現実」
  • 開発者の利便を優先し、VPN外の直接公開、パッチ適用の停滞、CI/CDランナーやWebhookの横串権限、長寿命PAT/デプロイ鍵の乱立──この“よくある構図”がRCE直撃時の被害半径を最大化します。
  • Giteaは小規模〜中規模で“ビルドにもデプロイにも近い”場所に置かれがちです。RCE→レポ窃取→CI/CD秘匿情報の連鎖で、開発から運用まで一息に踏み越えられます。
• LD_PRELOADの選択は合理的
  • LD_PRELOADはユーザ空間でローダの挙動を乗っ取り可視性を落とす定番手口です。EDR/NIDSのカバレッジが薄い環境や、ログの中央集約が弱い中小規模開発環境では、検出が後手に回りやすいです。
• メトリクスから読む“いま動くべき理由”
  • 総合的に見ると、緊急性・実行可能性・確度が高く、業務影響は大きい一方でポジティブ要素は乏しい局面です。つまり「パッチを当てて様子を見る」では手遅れになりやすく、露出Giteaは“侵害前提”で扱い、完全再構築と全秘匿情報の強制更新まで踏み切る意思決定が妥当です。
• 産業オートメーション特有の二次被害
  • HMI/SCADAソースの流出は、プロトコル実装・例外系の癖・装置の識別情報・ハードコード鍵の露呈を通じ、OT侵入の将来リスクを一段引き上げます。知財リスクとセーフティリスクが同居するため、開発チームだけの課題に閉じません。

脅威シナリオと影響

以下はMITRE ATT&CKに基づく仮説シナリオです（一次情報限定のため、代表的な分岐を提示します）。

• 初期侵入（Initial Access）
  • 公開アプリ脆弱性悪用（T1190）
    GiteaのRCEでコード実行→アプリユーザ権限から脱出を図る。
• 実行・権限昇格・持続化（Execution/Privilege Escalation/Persistence）
  • コマンド実行（T1059）とローダ悪用
  • 実行ハイジャック：LD_PRELOAD（T1574.006）
    /etc/ld.so.preloadやプロセス環境変数を悪用し、プロセスにフックを挿入。ファイル・プロセス・ネットワークの可視性を低下させる。
  • 正規アカウントの確保（T1078）
    GiteaのPAT、デプロイ鍵、CI/CDトークン、OS/SSH資格情報を収集し持続化。
• 偵察・横展開（Discovery/Lateral Movement）
  • リポジトリ列挙・クローン、CI/CD実行環境やビルドノードへのSSH（T1021.004）。
• 資格情報取得（Credential Access）
  • ファイル中の秘匿情報抽出（T1552.001）
    レポ内の.env、YAML、CI設定からクラウド・レジストリ鍵を収集。
• 収集・流出（Collection/Exfiltration）
  • 大量のgit-upload-packトラフィックやアーカイブ化後の送信（T1041）
    C2への暗号化チャネル経由でレポ単位の広域送出。
• 影響（Impact）
  • 知財窃取、将来のサプライチェーン妥協、後日のOT侵入準備。必要に応じて恐喝・二重の恐喝も現実的です。

ビジネスへの影響は三層で考えると解像度が上がります。

• 短期：開発停止・契約/輸出管理リスク・顧客への通知対応コストが顕在化します。
• 中期：競合・模倣、ゼロデイ探索の逆利用、納入先からのセキュリティ再評価要求。
• 長期：OT領域への攻撃成功確率の上昇（プロトコル・設計理解に基づく侵入）、ブランド毀損の持続です。

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

「侵害前提」での初動と、その後の構成的な対策を分けて提示します。LD_PRELOADルートキット前提のため、オンホストの観測は“騙される”可能性を常に織り込むべきです。

• 0〜24時間（初動封じ込め）

  • 露出Giteaの即時ネットワーク隔離（WAF/リバプロ層含む）。フォレンジック目的でスナップショット取得後、運用はクリーン環境へフェールオーバーします。
  • 全秘匿情報の強制ローテーション計画を同時始動
    • Gitea内：PAT、デプロイ鍵、OAuthアプリ、Webhookシークレット、組織/リポジトリ秘密。
    • CI/CD：ランナー登録トークン、Pipeline用環境変数、レジストリ鍵。
    • インフラ：SSH鍵、クラウドIAM、アーティファクト署名鍵、パッケージ署名鍵。
  • 迅速トリアージ（“外から見る”観点を優先）
    • リバプロ/Nginx等のアクセスログでgit-upload-packの大量ヒット／異常帯域を抽出。
      例：grep -i "git-upload-pack" access.log | awk '{print $1}' | sort | uniq -c | sort -nr
    • Outbound通信の急増・未知宛先をフローベースで把握（NetFlow/Zeekなど）。
  • OT/製品側のリスク低減
    • SCADA/HMIレポのリリースブランチ・生成物のコードサイニングを一時停止し、再ビルド・再署名計画を策定します。

• 24〜72時間（根絶・継続監視）

  • クリーンルームで再展開
    • OS再イメージ→Gitea最新版導入→データ移行（リポは“信頼できる最後のスナップショット”から）。
    • サービスアカウント最小権限化、2FA/SSO強制、PAT寿命の短縮。
  • LD_PRELOAD系の痕跡検査（ライブ環境を信用しすぎない）
    • レスキューメディア/EDRオフラインスキャンで以下を確認：
      • /etc/ld.so.preload の存在・更新時刻・内容（sudo stat /etc/ld.so.preload; sudo cat /etc/ld.so.preload）。
      • 主要プロセスのmapsに不審soがマップされていないか（sudo grep -H "lib..so" /proc//maps | grep -v /usr/lib）。
      • 異常なライブラリ探索順序（LD_LIBRARY_PATH, LD_AUDIT等の環境変数をsystemdユニット・プロファイルで確認）。
  • 横展開の有無
    • SSHログイン履歴（sshdログ/lastlog）、新規sudoer、cron/systemdタイマー、未知ユーザ・グループ、setuidビット新規付与の検査。
  • 流出規模の推定
    • リバプロログ×Giteaサーバのgitログで、clone/fetchの時系列・対象レポ・転送量を相関。外形から規模を把握します。

• 1〜2週間（再発防止の構造化）

  • アーキテクチャ見直し
    • 直接公開を廃止し、VPN/ZTNA配下へ。反向プロキシでmTLS、レート制限、IP許可リストを運用。
    • CI/CDランナーはエフェメラル化（使い捨て実行）。シークレットは外部Secret Managerに集約、短寿命化。
  • 検知の強化
    • git-upload-pack/receive-packの高頻度アクセス検知、レポ単位のダウンロードしきい値超過アラートを導入。
    • /etc/ld.so.preload・/etc/ld.so.conf.d配下の変更監視、未知の共有ライブラリ生成（/tmp,/dev/shm, $HOME/.local/libなど）検知。
  • サプライチェーン安全性の再評価
    • 署名鍵のハードニング（HSM/YubiKey）、署名ポリシーの二眼承認。ビルドの再現性確認、SLSA/SBOM運用の棚卸し。
  • コミュニケーション
    • 顧客・パートナーへ「影響を受け得るブランチ・期間・対策」の透明性ある説明。必要に応じて製品の再署名・更新プログラムを提供します。

• 現場の簡易チェックリスト（被疑ホスト）

  • sudo cat /etc/ld.so.preload（存在/中身）
  • sudo find / -xdev -name "*.so" -mmin -1440 2>/dev/null（直近生成soの洗い出し）
  • journalctl -u gitea --since "2026-09-01"（Giteaサービスログの異常）
  • 反向プロキシaccess.logでgit-upload-pack急増と未知ASへの転送
  • authorized_keys/known_hostsの不審エントリ、cron/systemdの新規ジョブ

最後に、今回の件は「パッチ適用」で終わる話ではないと強調したいです。レポの価値は、その中に埋まるシークレット、設計、署名の“つながり”にあります。つながりを断ち、取り戻すためのローテーションと再構築、そして“オフホスト”の検証手順を標準化しておくことが、明日の被害縮小につながる最短路です。

参考情報

• Red Heron Exploits Critical Gitea Flaw to Steal Repositories (GBHackers)
• MITRE ATT&CK: T1190 Exploit Public-Facing Application
• MITRE ATT&CK: T1574.006 Hijack Execution Flow: LD_PRELOAD
• MITRE ATT&CK: T1059 Command and Scripting Interpreter
• MITRE ATT&CK: T1078 Valid Accounts
• MITRE ATT&CK: T1021.004 Remote Services: SSH
• MITRE ATT&CK: T1041 Exfiltration Over C2 Channel

本稿は公開情報が限られる段階での深掘りです。ベンダーの公式アドバイザリやCVE詳細が出次第、検知・封じ込めのプレイブックをアップデートすることを強く勧めます。読者の皆さんの現場判断を少しでも後押しできていれば幸いです。