カメラファームウェアの中の管理者の鍵 — ハンファビジョンGitHubトークン漏洩とCIパイプラインの崩壊

多層暗号化で隠したファームウェアもLLMの前では紙箱にすぎない — process.env 一行が招いた国防総省IPと組織全体adminトークンの露出

要約（TL;DR）
Key Judgments
はじめに — 「難読化は退屈させることにしか効かなかった」
事件タイムライン
技術分析 — 二重暗号化レイヤーとLLM支援リバースエンジニアリング
根本原因 — process.env 一行がCI全体を成果物に刻み込む
MITRE ATT&CK / CWEマッピング
露出資産リスク評価 — トークンと国防総省IP
全数調査結果 — 約500件のファームウェア、3件の同一トークン
報告・対応評価 — 12時間の迅速な対応と訂正報道
韓国の視点 — 国内防衛産業系列会社とCTIへの示唆
検知・緩和・対応の推奨事項
結論
参考文献

1. 要約（TL;DR）

2026年7月24日、あるセキュリティ研究者（ブログ名hhh.hn、筆名Austin）が、ハンファビジョン（Hanwha Vision、旧サムスンテックウィン）のネットワークカメラのファームウェアを分析し、Web管理UIのビルド成果物約30ファイルから同一のGitHub個人アクセストークンを発見したと公表した。このトークンは、ハンファのGitHub組織内の数百のリポジトリに対する管理者（admin）権限を保有していた。原因は単純だった — カメラ管理UIをビルドするVite設定において、ある環境変数がprocess.env全体として指定されていたため、CI/CDジョブの全環境変数（ビルドシステムのアドレス、社内インフラのIP、GitHubトークンを含む）がそのままクライアント側の成果物に書き込まれていた。

研究者によれば、ファームウェア自体も二重に暗号化されていたが、fwupgraderバイナリをGhidraとClaude Codeで分析することで、XORで難読化されたAES-256-CBCの鍵・IV復元ロジックを数時間で解除できたという。これは「コード難読化が予算ではなく時間しか稼げなかった時代が終わった」ことを示す事例である。

漏洩したCI環境変数には、米国防総省（DoD）割り当て帯域に見えるIPアドレスが3件含まれていたことも議論を呼んだが、ハンファ側は確認の上で「サムスンテックウィン時代から社内アドレス体系として慣行的に使用してきたものであり、DoD割り当ての事実を認識していなかった」と公式に回答し、研究者はこの部分の推測的な記述を撤回・訂正した（2026-07-27）。実際の攻撃によるものではなく、レガシーな社内アドレス体系の誤用であったことが確認された事案である。

ハンファは報告受領後12時間以内にトークンを失効させ、迅速な対応事例として評価されるが、根本原因である「ビルド時にCI環境変数全体をクライアント成果物に埋め込む構成」が是正されたかどうかは公開されていない。

⚠️ 調査範囲の限界 — 本レポートは研究者個人のブログ（一次情報源）とGeekNewsの要約報道に基づく分析である。ハンファビジョンの公式セキュリティ告知は確認されておらず、実際のカメラ管理UIでトークンがネットワーク経由で送信されていたか（攻撃対象として露出していたか）については、研究者自身も実機を保有していなかったため検証できなかったと明記している。

Key Judgments

#	判断	確信度
KJ-1	露出の原因は攻撃ではなくビルド設定の欠陥（Vite環境変数が`process.env`全体にバインドされていた）であり、CIジョブの全環境が副次的にクライアント成果物へ露出した。	High
KJ-2	漏洩したGitHubトークンは組織admin権限を持つ単一の認証情報であり、たった一つのビルド設定ミスが組織全体のコード資産の機密性・完全性リスクに直結する単一障害点（SPOF）構造を露呈させた。	High
KJ-3	ファームウェアの二重暗号化（1段目：モデル名ベースのパスフレーズ、2段目：バイナリ内XOR難読化されたAES鍵）はかつては有意な防御線だったが、LLM支援リバースエンジニアリング（Claude Code + Ghidra）により人間が数時間で解除できるようになり、防御効果は事実上消滅した。	High
KJ-4	漏洩したCI環境変数における国防総省（DoD）割り当てIP帯域の使用は、ハンファと米国防総省の実質的な関係ではなく、サムスンテックウィン時代から続く社内アドレス体系慣行との偶然の衝突であることが、ハンファ側の回答と研究者の訂正を通じて確認された。	High
KJ-5	約500件中62%のファームウェアで同一手法による解読が成功し、トークンが発見された3件のファームウェアはすべて同一のトークンを含んでいた — 一つのCIパイプラインの成果物が複数のモデルラインで再利用される構造であることを示唆する。	Medium-High
KJ-6	報告後12時間以内のトークン失効は迅速だったが、公開情報のみでは根本原因（ビルドスクリプトによる`process.env`全体の露出）が是正されたかどうかは確認できない— 再発の可能性は残っている。	Medium
KJ-7	ハンファビジョンは監視カメラ以外にも、自走砲・装甲車サブシステム・警戒ロボットなどを生産してきたハンファグループの系列会社であり、今回の事案は単一のIoTベンダーのリスクにとどまらず、防衛産業関連企業のソフトウェアサプライチェーンセキュリティの成熟度という問題に拡張して捉える余地がある。	Medium

2. はじめに — 「難読化は退屈させることにしか効かなかった」

この事件がCTIの観点から興味深いのは、漏洩そのものよりも漏洩に至る経路が崩壊した速度である。ハンファはファームウェア保護のために少なくとも二重の暗号化を施していた — モデル名ベースのパスフレーズで外側のtarballを包み、内部のfwimage.tgzは別途AES-256-CBCで再度包んでいた。鍵とIVはバイナリ内に平文で置かれるのではなく、静的テーブルとのXOR演算によって分散させられていた。2023年時点であれば、個人研究者の時間と忍耐力を消耗させるには十分な壁であった。

しかし研究者は、この難読化解除の作業を人間がGhidraで直接追うのではなく、Claude Codeにバイナリ解析を任せてその場を離れたと述べている。夕食を終えて戻ったときには、すでに復号ロジックの説明と完全なルートファイルシステムが用意されていた。これはGeekNewsのコメントスレッドでも中心的な論点となった — 「難読化は攻撃者を止めるものではなく、退屈させて諦めさせるための仕掛けにすぎなかった。国家背景組織や専門的な犯罪集団は最初からその手間を惜しまなかった。今やLLMがその退屈さえも代わりに耐えてくれる」。

ファームウェア難読化の経済学が変わった。 防御側が難読化に投じるエンジニアリングコストに対し、攻撃者（あるいは研究者）がそれを解除するコストは、LLM支援リバースエンジニアリングによって構造的に低下した。これは今回の一件に限った教訓ではなく、ハードコードされた認証情報や鍵の隠蔽に依存するあらゆる組み込み/IoTベンダーに当てはまる脅威モデルの変化である。

3. 事件タイムライン

日時（2026年）	出来事	備考
（不明、7月中）	研究者、ハンファビジョンのウェブサイトで公開されているカメラモデル別ファームウェアイメージをダウンロードし分析に着手	AXISのLinuxアプリケーション対応拡大の議論をきっかけに関心を転換
（不明）	`binwalk`でイメージを分析 → 1段目暗号化された`fwimage.tgz`を確認、Matt Brownの既公開分析（モデル名ベースのパスフレーズ）で1段目を解除	`HTWXNP-9300RW`のパスフレーズで成功
（不明）	内部に存在する2段目暗号化された`fwimage.tgz`を発見 — 既存の手法は再利用不可
（不明）	`fwupgrader`バイナリをGhidra + Claude Codeで分析、XOR難読化を解除 → AES-256-CBCの鍵・IVを復元しルートFSを取得	夕方の時間帯に完了（研究者の記述による）
（不明）	`trufflehog`でルートFSをスキャン → 約30ファイルで同一GitHubトークンの重複を発見、組織admin権限を確認
（不明）	原因分析 — Viteのビルド変数が`process.env`全体に設定されており、CI環境全体が成果物に書き込まれていることを確認	`GITHUB_NPM_TOKEN`など多数の変数を含む
（不明）	約500件のカメラモデルのファームウェアを全数収集・解読試行 — 62%で抽出成功、そのうち3件で同一トークンを再確認
（不明）	ハンファの公開セキュリティ報告チャネルへ最小限の情報のみを記載したメールを送付
（不明、報告後12時間以内）	ハンファ、トークン失効完了の返信	迅速な対応事例として評価
2026-07-24	研究者、hhh.hnブログで分析全体を公開（"My security camera shipped a GitHub admin token…"）	国防総省IPに関する推測を含む（原文）
2026-07-25	GeekNews、国内向け要約報道（xguru）	国内開発者コミュニティで拡散
2026-07-27	ハンファ、DoD IPに関する問い合わせに公式回答 — 「サムスンテックウィン時代からの社内アドレス体系であり、DoD割り当ての事実は認識していなかった、アドレス体系変更を計画」	研究者、原文の推測的な記述に取り消し線を引いて訂正

タイムラインに関する注記: 原文には各技術的段階の正確な日付は明示されていない。ただし、報告~~失効（12時間）と公開~~訂正（約3日間）という二つの対応サイクルの双方でハンファ側が実質的に応答しているという点で、他事例で扱われたTVING事例（報告期限の1分前に消火型対応）とは異なる質のインシデント対応文化として評価できる。

4. 技術分析 — 二重暗号化レイヤーとLLM支援リバースエンジニアリング

4.1 1段目暗号化 — モデル名ベースのパスフレーズ

ハンファビジョンのウェブサイトはモデル別ファームウェアイメージを公開ダウンロードとして提供している。binwalkによる分析の結果、内部にAIコンポーネントのtarballと暗号化されたfwimage.tgzが確認された。既公開の第三者分析（Matt Brown）によれば、パスワードはHTW + モデル番号の組み合わせであり、対象モデル（HTWXNP-9300RW）で実際に機能した。これはパスフレーズの構成規則そのものがすでに公開情報として知られていたことを意味し、このレイヤーは事実上防御力を失っていた状態だった。

4.2 2段目暗号化 — バイナリ内のXOR難読化

1段目の解除後も、内部にはさらにもう一つのfwimage.tgzが存在しており、今回は別の方式で暗号化されていた。fwupgraderバイナリの分析結果:

AES鍵はバイナリ内の小さな静的鍵テーブルとのXOR演算を経て実行時に再構成される
IVはバイナリに平文として保存
復号はfwupgraderがopensslのCLIをシェルアウト（shell-out）する方式で行われ、このコマンド文字列の断片も同様にXOR難読化されている

復元されたコマンドの形式:

openssl enc -md sha256 -aes-256-cbc -d \
  -K <KEY> -iv <IV> -in <INPUT> -out <OUTPUT>

実際の鍵/IV（研究者が公開したもの、同一モデルライン内で共通使用）:

KEY = dfa049bb922e63e2decc764af5628068e5b7a2662e479a615b14643e567579b0
IV  = 53f926801b81454a4f889c9a390db6e6

4.3 LLM支援リバースエンジニアリングの含意

研究者は、この難読化解除作業をGhidraの静的解析とClaude Codeを組み合わせて実施したと明記しており、結果として人間が従来手法であれば数日を要していた作業を大幅に短縮した。CTIの観点からは、これは以下を示唆する:

防御コストの非対称性の逆転: ハードコードされた鍵をコード/バイナリ内部に「隠す」というアプローチは、リバースエンジニアリングのコストを引き上げることで遅延させる効果に依存してきた。LLM支援ツールはこのコストを大幅に引き下げ、難読化だけではもはや有意な時間稼ぎの効果を期待することが難しくなった。
国家背景組織や専門集団にとってはもともと低い壁だったという点で、今回の事件の本当のニュースは「専門性の低い個人研究者でさえ一晩で到達できる難易度まで防御線が下がった」ことにある。
対策は難読化の強化ではなく、そもそも長期的な認証情報をクライアント/ファームウェアに組み込まないアーキテクチャへの移行であるべきだ（§12の推奨事項を参照）。

5. 根本原因 — `process.env` 一行がCI全体を成果物に刻み込む

トークン露出の実際の原因は、暗号化レイヤーとは無関係な、はるかに平凡なビルド設定の欠陥だった。カメラ管理UIはViteでビルドされており、あるビルド変数がprocess.envオブジェクト全体に設定されていた。その結果、CIジョブが保持する全環境変数がそのままクライアントバンドルにハードコードされた:

var W = {
  DATAPORT: "9090",
  GIT_LFS_SKIP_SMUDGE: "1",
  npm_command: "run-script",
  KUBERNETES_SERVICE_PORT_HTTPS: "443",
  GITHUB_NPM_TOKEN: "<snip>:ghp_…REDACTED…",
  npm_config_userconfig: "/home/docker/.npmrc",
  // etc
}

このパターンはCWE-798（Use of Hard-coded Credentials）の典型例だが、発生箇所がアプリケーションコードではなくビルドツールの設定（Viteのdefine/env処理）であるという点で、一般的なシークレットスキャンの慣行が見落としやすい領域である。ソースリポジトリ自体にはトークンが存在しなかった可能性が高く（CIジョブ環境に注入された値）、問題は「ビルド成果物」というシークレットスキャンの死角で発生した。

同じ環境変数群には、社内インフラの識別情報（例：SWARM_MASTER_NFS_ADDRESS、OTEL_ELASTIC_URL、CIMIPなど社内ネットワークアドレス）も含まれていた。つまり今回の事案は、GitHubトークン単体の問題ではなく、CI/CDパイプライン全体の内部構成情報が大量にクライアント製品へ漏洩した事件として捉えるべきである。

6. MITRE ATT&CK / CWEマッピング

カテゴリ	マッピング	備考
脆弱性の種類	CWE-798 Use of Hard-coded Credentials	ビルド成果物（クライアントUI）にCIシークレットがハードコード
脆弱性の種類	CWE-312 Cleartext Storage of Sensitive Information	バイナリ内の平文IV、暗号化されずに保存された露出トークン
潜在的な攻撃手法	T1552.001 Unsecured Credentials: Credentials In Files	カメラUIファイル約30件で繰り返し発見されたトークン
潜在的な攻撃手法	T1078.004 Valid Accounts: Cloud/SaaS Accounts (GitHub)	トークンが窃取された場合、組織のリポジトリ全体にadmin権限でアクセス可能
潜在的な後続手法	T1195.002 Supply Chain Compromise: Compromised Software Dependencies	adminトークンの悪用によりコードリポジトリの改ざんを通じたサプライチェーン汚染の可能性（発生はしていない理論上のリスク）
防御失敗のポイント	シークレットスキャンの対象範囲 — ソースリポジトリは対象、CIビルド成果物（クライアントバンドル）は対象外と推定	根本原因§5を参照

本事件は実際に侵害が発生したインシデント（incident）ではなく、事前露出脆弱性の発見・報告（vulnerability disclosure）の事例である。したがって、攻撃者の実際のTTPが観測されたわけではなく、「もし悪用されていたら」可能であった潜在的な経路をマッピングしたものであることに留意が必要である。

7. 露出資産リスク評価 — トークンと国防総省IP

露出資産	性質	悪用時の影響範囲	実際の確認状況
GitHubトークン（`GITHUB_NPM_TOKEN`）	長期PAT（個人アクセストークン）と推定	組織内数百のリポジトリへのadmin権限 — コード漏洩、バックドア埋め込み、リリース改ざんなどサプライチェーン攻撃が可能	報告後12時間以内に失効を確認。実際の悪用の痕跡は報告されていない
社内インフラ変数（`SWARM_MASTER_NFS_ADDRESS`など）	社内ネットワーク識別情報	社内インフラのマッピング（偵察）資料として活用される可能性	公開の有無・対応措置は不明
DoD割り当てIP帯域3件	社内アドレス体系の再利用の状況	当初の推測：ハンファと米国防総省の実質的な関係 → ハンファの公式回答により反証、レガシーアドレス慣行として確認	ハンファの回答および研究者の訂正により説明完了
管理UI自体の露出範囲	検証不可	管理UIへのアクセス時にトークンが実際にネットワークへ送信されていたかは未確認	研究者が実機を保有していなかったため検証不可（ブログ原文に明記）

DoD IP項目に対する評価: 当初のブログ原文は、これらのアドレスが米国防総省の割り当て帯域であることを根拠に「ハンファは米国防総省と直接的な関係があるのか」という推測を提起し、GeekNewsのコメント欄でも「韓国製セキュリティ製品の回避」といった過剰な解釈が続いた。しかしハンファ側の公式回答によれば、これはサムスンテックウィン時代から続く社内アドレス体系の慣行であり、自社が使用中の帯域が公式にDoDへ割り当てられている事実自体を認識していなかったことが実際の原因である。研究者はこれを確認した上で、原文の推測部分に取り消し線を引き、訂正文を追加した（2026-07-27）。CTIレポート作成にあたっては、こうした説明後の事実関係の更新を必ず元の記述と分離して明示する必要があり、本レポートはこの原則に基づき訂正された事実をKJ-4に反映している。

ただし、「国防総省に割り当てられたIP帯域を社内アドレスとして無断で再利用する」という慣行自体は、それ自体がIPアドレスの衝突・ルーティング誤動作のリスクをはらんだ誤ったネットワーク設計の慣行であり、ハンファもこれを認めアドレス体系の変更計画を明らかにした点は、別途記録しておく価値がある。

8. 全数調査結果 — 約500件のファームウェア、3件の同一トークン

研究者は、これが偶然の単発事例であるかを確認するため、ハンファビジョンのウェブサイトで公開されている約600のカメラモデルのうち、ファームウェアが提供されている約500件を全量収集し、同一の方法で解読を試みた。

指標	値
収集対象モデル数	約600件（ファームウェア提供モデル基準で約500件）
解読成功率	約62%
GitHubトークンが発見されたファームウェア数	3件
発見されたトークンの同一性	3件すべて同一トークン

この結果は二つのことを示唆する。第一に、解読失敗（38%）の原因は明示されていないが、これはモデル世代ごとに暗号化方式が異なる可能性を示唆しており、調査されていない他のモデル群に別途の露出が存在する可能性を排除できない。第二に、トークンが発見された3件のモデルすべてが同一のトークンであるという点は、一つのCIパイプライン/ビルドスクリプトが複数のモデルラインのUIビルドに再利用されている構造を裏付けており、これは一つの設定欠陥が製品ライン全体に波及する典型的なサプライチェーン型リスクのパターンである。

9. 報告・対応評価 — 12時間の迅速な対応と訂正報道

研究者はトークンの所在を特定できる最小限の情報のみを記載し、ハンファの公開セキュリティ報告チャネルへメールを送付した。ハンファは12時間以内に応答し、トークンの失効を完了した。研究者自身も「このようなミスはあってはならないが、これほど迅速な対応・解決は稀だった」と評価している。

その後のDoD IPに関する問い合わせに対しても、ハンファは具体的な根拠（サムスンテックウィン時代からの社内アドレス体系、認識していなかった事実の認定、今後の変更計画）を添えて回答し、研究者はこれを根拠に原文の推測的な記述を公に撤回した。脆弱性報告への対応、および事後の対外的なコミュニケーションの両方において実質的かつ透明な姿勢が観測された事例であり、これは他事例で扱われたTVING事例（報告期限の1分前に消火型対応、通知のダークパターン）と対照的な参考事例として記録する価値がある。

ただし、以下の二点は未確認のまま残る。

根本原因であるViteビルド設定（process.env全体の露出）が実際に修正されたかどうか
すでに出荷され現場に設置されているカメラのファームウェアに残存する旧バージョンのUI成果物への対応（再配布・強制アップデート）の有無

10. 韓国の視点 — 国内防衛産業系列会社とCTIへの示唆

監視機器・防衛産業系列会社という構造。ハンファビジョンはサムスンテックウィンを起源としハンファグループに編入された映像監視企業であり、過去にK9自走砲、K10弾薬運搬装甲車、K2戦車のサブシステム、SGR-A1警戒ロボットなどを生産してきた実績がある。今回の事案自体は防衛製品ではなく民生用CCTVのウェブUIで発生したものだが、ハンファグループ傘下にHanwha Aerospace・Hanwha Defense USAなど防衛産業系列会社が存在することを踏まえると、グループ共用のCIインフラを利用する系列会社間のソフトウェアサプライチェーンセキュリティの境界設計が今後の点検対象になり得る。
国内IoT/組み込みベンダー共通のリスク。 GeekNewsのコメント欄でも指摘されているように、ハードコードされた認証情報や危険なデフォルト設定は国内外を問わずIoT業界の慢性的な問題である。ただし今回の事例は「報告後12時間で対応」という比較的良好なベンチマークを提供しており、国内ベンダーのセキュリティ報告対応プロセス設計の参考になり得る。
監視カメラのエンタープライズ資産化。 原文でも言及されているように、AXISなど業界がカメラを「Linuxを稼働させるエンタープライズネットワーク資産」として再定義する流れの中で、国内CCTVベンダーも認証情報のライフサイクル管理・SBOM（ソフトウェア部品表）・シークレットスキャンをビルドパイプラインの標準項目として採用する必要性が高まっている。

11. 検知・緩和・対応の推奨事項

製造業者/組み込み-IoTベンダー全般

ビルド成果物へのシークレットスキャンの拡大— ソースリポジトリだけでなく、ビルド成果物（クライアントバンドル、ファームウェアイメージ、コンテナイメージ）に対してもtrufflehog系のシークレットスキャナーをCIパイプラインの最終段階で強制実行する。ソースにシークレットが存在しなくても、ビルドツールの設定欠陥によって成果物に混入し得ることを今回の事件が示している。
ビルド変数のホワイトリスト化— Vite/Webpackなどバンドラーのdefine/env関連設定において、process.env全体をクライアントに露出させるパターンを禁止し、明示的に必要な変数のみを個別のホワイトリストとして注入する。
長期認証情報の排除 — GitHub PATなど長期（long-lived）トークンをCI環境に常設せず、GitHub Actions OIDC/Fine-grained PAT/短TTLトークンへ移行する。組織admin権限を持つ単一のトークンが複数のCIジョブで共有される構造自体を排除する。
ファームウェア暗号化の再設計 — バイナリ内でXOR難読化された鍵再構成方式を、もはや有効な防御線とみなさない。ハードウェアセキュリティモジュール（HSM/TPM/Secure Element）ベースの鍵導出、デバイスごとの固有鍵発行へ移行する。
社内アドレス体系の監査 — 社内インフラにおいて公的IP帯域（特に政府・防衛機関割り当て帯域）を社内アドレスとして無断で再利用するレガシーな慣行を全数点検し、RFC 1918のプライベート帯域へ移行する。
LLM支援リバースエンジニアリングを脅威モデルに反映 — コード/バイナリの難読化を「時間稼ぎ」ではなく防御対策として設計する慣行を再検討する。脅威モデリングにおいて「熟練した個人がLLM支援ツールを用いて一晩で難読化を解除できる」という前提をデフォルトとして採用する。

セキュリティ報告プロセス（参考事例として）

今回の事件における12時間以内のトークン失効対応と公開問い合わせに対する具体的根拠を伴う回答は、他社の脆弱性報告対応プロセスのベンチマークとして参考にする価値がある。

カメラ購入・運用企業（エンタープライズ）

ネットワーク分離 — IoT/CCTV機器は専用VLANに隔離し、インターネットへのアウトバウンドアクセスを原則として遮断する。
管理UIへのアクセス制御 — カメラ管理ウェブUIへのアクセスを社内ネットワークに限定し、可能であればONVIFなど標準プロトコルに基づく別途のNVR経由での運用を検討する。
ファームウェア更新の追跡 — ベンダーのセキュリティ告知を購読し、今回の事件に関連するファームウェアパッチが公開されるかを継続的に確認する。

12. 結論

今回の事件の本質は「巧妙な攻撃」ではなく、ありふれたビルド設定ミス（process.env全体の露出）と、時代遅れの防御前提（ファームウェア難読化が時間を稼いでくれるという想定）が同時に崩壊したことにある。二重の暗号化で包まれたファームウェアは、LLM支援リバースエンジニアリングの前ではひと晩の障壁にすぎず、その中から発見されたのは組織全体に対するadmin権限を持つ単一のGitHubトークンだった。国防総省割り当てIPという刺激的なサブプロットは、実際にはレガシーな社内アドレス体系との偶然の衝突であったことが説明されたが、その説明のプロセス自体 — 報告後12時間以内の対応、公開問い合わせに対する根拠ある回答、原著者による迅速な訂正 — が、今回の事件で最も印象的な要素として残る。

CTIの観点から残る問いは二つである。あなたのビルドパイプラインがクライアント成果物に何を刻み込んでいるか、実際に確認したことがあるだろうか。そしてあなたの難読化は、人間を止めるために設計されているのか、それともLLMを止めるために設計されているのか。

13. 参考文献

hhh.hn（Austin）— "My security camera shipped a GitHub admin token in its login page"（2026-07-24、2026-07-27訂正）— https://hhh.hn/hanwha-github-token/
GeekNews — 「ハンファビジョンのセキュリティカメラのウェブUIログインページにGitHub管理者トークンが含まれた状態で出荷」（2026-07-25、xguruによる要約）— https://news.hada.io/topic?id=31784
Matt Brown — "Hanwha firmware file decryption"（1段目暗号化レイヤーの分析、原文参照）— https://brownfinesecurity.com/blog/hanwha-firmware-file-decryption
Wikipedia — "Hanwha Vision"（沿革、旧サムスンテックウィン、防衛産業系列会社の情報）— https://en.wikipedia.org/wiki/Hanwha_Vision
NBC News — "Future Tech: Autonomous killer robots are already here"（SGR-A1関連、原文引用）— https://www.nbcnews.com/tech/security/future-tech-autonomous-killer-robots-are-already-here-n105656
CWE-798: Use of Hard-coded Credentials — MITRE CWE
CWE-312: Cleartext Storage of Sensitive Information — MITRE CWE
MITRE ATT&CK — T1552.001, T1078.004, T1195.002

変更履歴

バージョン	日付	内容
v1.0	2026-07-28	初版発行 — 原文およびGeekNews要約に基づく技術分析、DoD IPの訂正を反映

本レポートは公開OSINT資料（研究者個人のブログ、GeekNewsの要約報道）に基づく独立分析であり、ハンファビジョンまたは関連機関の公式見解を代弁するものではありません。本事件は実際の侵害（breach）ではなく、研究者による責任ある脆弱性公開（responsible disclosure）の事例であり、ハンファ側は報告受領後に迅速に対応したことを明記します。教育・防御・研究目的でのみ使用してください。TLP:GREEN — コミュニティ内での共有・対外公開が可能です。