ᄒᆞᆫ글 815 特別版 CD

ハンコム ソリューションウェア。国民的ワードプロセッサになったコードは30年持ちこたえた。その隙間を北朝鮮が掘り続けた。

キム・ホグァン サイワールド元代表 / 2026年10月10日

🌐 한국어 · English · 日本語 · 中文

分類: TLP:CLEAR | 文書類型: 分析コラム (Analytical Column) | 作成日: 2026-10-10 深刻度: HIGH | 信頼度: A2 | 関連行為者: APT37 · キムスキ(Kimsuky)

コードは老いない。コードを理解する人が老いるだけだ。 韓国の「文書インフラ」になった国産ワードプロセッサと、30年物のコードが残した宿題。

マスター版（2026年10月9日）

はじめに — 今月、公務員メールでHWPが止まる

政府計画どおりなら、2026年10月、公務員が国民とやり取りする公職者統合メールでHWPファイルの添付が制限される。地方政府のオンナラシステムはすでに5月18日からHWPX義務化が拡大された。政府が掲げる大義は「AIが読める文書」だ。だがこの転換には、公式発表にほとんど出てこないもう一つの理由がある。HWPは10年以上、北朝鮮ハッキングの最も確実な出入り口だった。

2025年12月、ジニアンス・セキュリティセンターは北朝鮮連携のAPT37による「アルテミス作戦（Operation Artemis）」を公開した。攻撃者は大学教授や放送作家を装い、何度も会話して信頼を積んだうえで、事前インタビュー質問票や行事案内に見せたHWPファイルを送った。被害者が文書を開き、コンテンツ実行を許可し、本文の「ハイパーリンク」を押した瞬間に感染が始まった。そのリンクは、リンクに見せかけたOLEオブジェクトだった。

米国の北朝鮮専門媒体38ノースは2025年10月の報告で、HWPが韓国の省庁・軍・基幹産業・学界の事実上の標準であるという事実そのものが、韓国と米韓同盟のサイバー安保上の弱点だと診断した。

なぜハングルなのか。本コラムはその答えを歴史・文化・技術の三重で解き、最後にまだ本格的に語られていない問題、すなわち30年物のCコードと、そのコードを理解する人々の高齢化を扱う。

1. 韓国語のために生まれたワードプロセッサ

ハングルワードプロセッサは1988年、ソウル大コンピュータ研究会出身のイ・チャンジン、キム・ヒョンジプ、ウ・ウォンシク、キム・テクジンらが開発を始め、1989年に1.0として世に出た。製品名の「ᄒᆞᆫ글」はアレア（ㆍ）を残した古い表記だ。1990年にハングルアンドコンピュータ（ハンコム）が設立され、本格的に商用化された。

当時の海外ワードプロセッサはハングルをまともに扱えなかった。ハングル一字は初声・中声・終声の組み合わせで、現代ハングル音節だけでも1万1,172字に達する。ハングルは組合型コードでこの問題に正面から当たり、ハングル・漢字混用、縦書き、韓国式段落・字間制御まで実装して「国民的ワードプロセッサ」になった。

韓国語は助詞と語尾が発達した膠着語で、漢語と固有語が混ざり、公文書と学術文書には漢字併記と特殊記号が頻繁だ。この組版要求に最初に、最も正確に答えたのがハングルだった。1990年代半ばにマイクロソフトワードが韓国市場を叩いたが、韓国語組版の品質とユーザー習慣の壁は越えられなかった。1998年の通貨危機当時、マイクロソフトの出資提案に対抗して「ハングルを守れ」運動が起きたことは、このソフトが韓国社会で製品以上の象徴だったことを示す。

その象徴性こそが、後に攻撃者の機会になる。

2. 表の国、そして「韓国だけが使う」フォーマットになった理由

公文書の表文化

韓国の行政文書の特徴は表と改条式だ。起案、報告、計画、予算、一枚の状況報告まで、ほとんど表で項目を分け、「〜함」「〜임」で終わる改条式の文を埋める。セル結合、罫線の太さ、行間、フォントと長平まで決まった書式があり、少しでもずれると「やり直してこい」と言われるのが公職社会の長い風景だ。

ハングルはこの表編集で圧倒的だった。複雑な表を描き、セルを裂き、合わせ、表の中で計算までする機能は、公務員と研究者の仕事の仕方そのものになった。

なぜ韓国だけHWPを使うのか — 政治経済的ロックイン

機能だけでは説明が足りない。HWPの支配力は国民感情に加え、官公庁標準文書をはじめ何層ものロックインで維持されてきた。

  • システム・ロックイン。 政府の業務管理システム「オンナラ」がHWPを既定の文書形式にしてきた。公務員がHWPを使うので、民間協力企業・研究機関・学校もHWPで提出しなければならなかった。
  • 書式資産のロックイン。 数十年分の公文様式、支援事業申請書、入札書式がすべてHWPだ。フォーマットを変えれば様式を何万も作り直すことになる。
  • 調達と産業政策。 国産ソフト育成という大義の下、公共調達でハンコムオフィスは長く既定値だった。
  • 象徴のロックイン。 「外産に対抗する国産ソフト」という物語が、転換議論を感情的に難しくした。

攻撃者から見ると、この構造は決定的だ。標的が毎日開くファイル形式、開くときに誰も疑わないファイル形式、そして事実上世界で韓国だけが使うファイル形式。 この三条件が重なる点がHWPだ。マイクロソフトワードやPDFは世界のセキュリティ業界が一緒に見るが、HWPを監視するのは事実上韓国のセキュリティ業界だけだ。見る目が少ないところに攻撃は集まる。

「G7首脳会談に伴うBHの政策変化」

この題のhwp文書がメールやカカオトークで来たら、クリックしない官僚はほとんどいないだろう。

3. 欠陥の特徴 — 二つの攻撃軸

HWPを狙う攻撃は性格のまったく違う二つの流れに分かれる。これを分けないと処方も的外れになる。

第一 — メモリ欠陥、文書を「読む」瞬間に破られる

既存のHWP（5.0）フォーマットは、マイクロソフト複合文書構造（OLE Compound File）の上に独自のバイナリレコードを圧縮して積む方式だ。ハンコムはフォーマット仕様を公開しているが、30年を超える下位互換の要求のため、パーサが処理すべき例外と分岐が非常に多い。複雑なバイナリパーサは広い攻撃面になる。

公開脆弱点を見るとパターンははっきりしている。

時期 識別子 類型 備考
2015 CVE-2015-6585 型の混同 FireEyeが北朝鮮連携攻撃のゼロデイと確認、ハンコムが9月7日にパッチ
2016〜2020 CVE-2017-8291 など 内蔵ゴーストスクリプト（EPS処理）脆弱点 HWP内のEPS図を処理していた外部Cライブラリが攻撃経路になった
2022 CVE-2022-33896 バッファアンダーフロー XMLベース文書パース過程のメモリ欠陥
2026.02公開 CVE-2025-29867 型の混同（CWE-843） Hancom Office 2018・2020・2022・2024全ライン、CVSS 4.0基準8.5。公開時点で実害報告なし

型の混同、バッファオーバーフロー・アンダーフロー、解放後使用（Use-After-Free）はすべてC/C++のようなメモリ非安全言語で典型的に起きる欠陥だ。一つをパッチすると同系統のバグが別の場所に出る。個々の開発者のミスではなく言語とアーキテクチャの問題だ。ゴーストスクリプトの事例は、この問題がハンコム自身のコードだけにないことも示す。文書の中に図を一つ描くために引いてきた外部Cライブラリも攻撃地点になりうる。

第二 — 正規機能の悪用、脆弱点がなくても破られる

HWPは文書の中にOLEオブジェクトを入れられる。本来は表や図、他プログラムのデータを入れる機能だ。アルテミス作戦で攻撃者はこのOLEオブジェクトを普通のハイパーリンクのように偽装した。ソフトにバグが一つもなくても、利用者が警告を無視してクリック一度で感染が成立する。圧縮ファイルの中にHWPアイコンを付けたショートカット（LNK）を入れる手法も同じ系統だ。

この軸の核心は技術ではなく信頼だ。攻撃者は教授、記者、放送作家、研究機関職員を装い、何週間も会話してからファイルを送る。

二つの攻撃軸は異なる処方を求める

軸A：メモリ欠陥 軸B：正規機能の悪用
攻撃時点 文書を開く（パースする）瞬間 利用者が許可・クリックする瞬間
代表事例 CVE-2015-6585、EPS/ゴーストスクリプト アルテミス作戦、HWP+LNK
パッチで防げるか 個別バグは防げる、系統は繰り返す 防げない（機能自体が正常）
根本処方 メモリ安全言語への転換、サンドボックス CDR・文書検査、利用者行動

Rustで書き直したHWPでも、利用者が偽装リンクを押せば破られる。逆に教育をいくらしても、開くだけで実行されるゼロデイは止められない。どちらか一方では足りない。

4. 北朝鮮のHWP標的攻撃、13年の年表

時期 主体 内容 攻撃軸
2013 キムスキ カスペルスキーがキムスキ・キャンペーンを初公開。HWP文書を選んで盗む専用モジュールを含む。HWPは侵入手段である前に収集目標だった 収集
2015 北朝鮮連携推定 FireEyeがHWPゼロデイ（CVE-2015-6585）とバックドア「Hangman」を公開。C2が他の北朝鮮疑義攻撃と接続 A
2016〜2020 北朝鮮連携多数 統一・安保セミナー資料、仮想資産関連文書に見せたHWPに悪性EPSを仕込む攻撃が数年続く A
2017 APT37 外交・安保・統一分野の約20人を狙ったHWPスピアフィッシング A+B
2023 キムスキ 米韓6機関（米FBI・国務省・NSA、韓国情院・警察庁・外交部）が共同勧告。記者・学者を装う社会工学を警告 B
2025.03 APT37 「トイボックス・ストーリー」作戦。北朝鮮関連活動家を狙ってHWPに見せたLNKを配布 B
2025.08〜11 APT37 アルテミス作戦。教授・放送作家偽装、OLEハイパーリンク偽装、ステガノグラフィとDLLサイドローディングの結合 B

年表を見ると流れは明らかだ。2010年代半ばまでは軸A（脆弱点）が主力だった。ハンコムのパッチが速くなり、内蔵ゴーストスクリプトが除去されると、攻撃の重心は軸B（社会工学と正規機能の悪用）へ移った。2023年の米韓共同勧告が強調したのも、キムスキが最初のメールにはマルウェアを付けず、長く信頼を積むという点だった。

5. 今もHWPを狙う北朝鮮

北朝鮮のHWP攻撃は過去形ではない。2026年にもHWPX文書とスクリプトファイル（JSE）を組み合わせた変種、HWPとLNKを編んだキムスキの連鎖攻撃が業界で報告され続けている。

もう一つ注目すべき点がある。攻撃者はすでにHWPXも餌に使う。開放型フォーマットに変えただけではこの戦争は終わらない。攻撃者はフォーマットではなく、標的が信頼する業務の流れを追う。韓国の公共機関がHWPXを使えばHWPXで、公職者統合メールが止まればメッセンジャーとクラウドリンクへ移る。

6. 私たちは何をすべきか

処方は二つの攻撃軸に合わせて設計すべきだ。本コラムは四つを提案する。第一と第二は軸A、第三は軸B、第四は組織と個人の分だ。

第一、30年物のCコードをメモリ安全言語へ移す [軸A]

本コラムで最も強調したい部分だ。

ハングルの根は1980年代末、DOS時代のCコードだ。Windows時代を経てC/C++へ拡張され、その上に30年以上、機能と下位互換コードが重ねられた。ポインタを直接扱い、メモリを手で割り当て・解放する方式は、当時は性能のための最善だった。しかし今日そのコードは、北朝鮮が10年以上掘っている攻撃の地点だ。かつては各Windows版でGDIレンダリングが異なるため、MFCを使わずにレンダリングしたともいう。

そこに人の問題が重なる。ハングルを作った第一世代の開発者はいま還暦前後で、ほとんどが会社を離れて久しい。初期設計の意図と内部構造を深く理解する人材は減るのに、その上に重ねたコードは増え続ける。コードは老いないが、コードを理解する人は老いる。 レガシーシステムの最大のリスクは、この知識の断絶だ。

世界の方向はすでに決まっている。

  • マイクロソフトは、自社製品で毎年パッチするセキュリティ脆弱点の約70%がメモリ安全性の問題だと明らかにしている。
  • グーグルは、Androidの新規コードをRustなどメモリ安全言語で書き始めてから、全脆弱点に占めるメモリ安全性脆弱点の比重が2019年76%から2024年24%へ落ちたと発表した。既存のC/C++を全部書き換えず、新しいコードだけ変えても効果が出た点が核心だ。
  • 米国CISA・NSA・FBIと友好国のサイバー機関は2023年、ソフトメーカーに「メモリ安全ロードマップ」策定を共同勧告し、ホワイトハウス国家サイバー局長室（ONCD）も2024年、メモリ安全言語への転換を公式に促した。
  • 米国国防高等研究計画局（DARPA）は、AIでCコードをRustへ自動変換するTRACTORプログラムを進めている。

かつては数百万行のCを他言語へ移すのは非現実的だった。いまはLLMベースのコード移行という新しい道具がある。現実的な順序はこうだ。

  1. パーサから移す。 軸Aの攻撃は文書を「読む」瞬間に起きる。HWP/HWPXパーサ、画像・OLE処理モジュールのように外部入力を受ける境界コードからRustで書き直す。
  2. AIで変換し、テストで検証する。 LLMがCをRustへ下訳し、既存エンジンと新エンジンに同じ文書を数百万件入れて結果を比べる差分テストとファジングで動作を確認する。ハンコムは30年分の実文書という、他社が持たないテスト資産を持つ。LLMは翻訳機であって判定者ではない。判定はテストがする。
  3. 残ったCは閉じ込める。 すぐ移せない部分はサンドボックスに隔離し、破られてもシステム全体へ広がらないようにする。
  4. 知識をコードとして残す。 変換過程でレガシーの動作をLLMで文書化し、テストで固定すれば、第一世代の暗黙知が次世代が読める形で保存される。

費用は誰が出すか。正直に言って、この作業はハンコム一人では大きい。売上を増やさないセキュリティ再執筆に企業が自発的に数百億ウォンを使うのは難しい。しかしHWPが国家の文書インフラである以上、これは一企業の品質問題ではなく国家サイバー安保の問題だ。二つの大義とテコが必要だ。

  • 調達条件。 公共機関が買う文書ソフトに「メモリ安全ロードマップ」の提出を求める。米国がSecure by Design原則を調達に結びつけるのと同じやり方だ。
  • 共同R&D。 パーサ再執筆とファジング基盤を国家R&Dで支え、その成果の一部（とくにHWPXパーサ）をオープンソースにして、セキュリティ業界全体で検証できるようにする。

第二、開放型文書体系への転換を最後まで押し切る。単一ワードプロセッサへの露出を最大限減らす。

政府は2022年、中央部署オンナラにHWPXを義務化し、2026年5月18日から地方政府まで拡大した。公務員間のオンメールと対民窓口の公職者統合メールは10月からHWP添付を制限する。HWPXはXMLベースの開放型文書標準（OWPML、KS X 6101）に従い、拡張子をzipに変えれば内部構造をそのまま見られる。

転換の本当の価値は「検査可能性」にある。構造が透明でなければ自動検査、無害化（CDR）、AI分析はできない。ただし前述のとおり、開放型フォーマットがすなわち安全なフォーマットではない。 HWPXでもパース脆弱点が報告され、攻撃者はすでにHWPXを使う。フォーマット転換は出発点であって決勝線ではない。

第三、LLMベースの文書検査体系を構築する

第一項のLLMがコードを直す道具なら、ここでのLLMは入ってくる文書を検査する道具だ。同じ技術、まったく違う用途だ。

軸Bの攻撃はシグネチャでは捉えにくい。マルウェアではなく、正規機能とそれらしい文脈で成り立つからだ。だから文脈を読む検査が要る。HWPXからOLEオブジェクト、外部リンク、スクリプト、メタデータを構造的に抽出したうえで、LLMに次のような問いを投げさせられる。

  • 「インタビュー質問票だと言いながら、なぜ実行可能なオブジェクトが入っているのか」
  • 「本文に見えるリンクテキストと実際の接続先は一致するか」
  • 「送信者として表示された教授の所属と、文書の書式・メタデータは一致するか」

この構造でもLLMは最終判定者ではない。決定論的検査エンジンが危険要素を確定し、LLMはその前段で疑い信号を濾し、人が理解できる言葉で説明する役割を担う。数十年分の旧版HWPをHWPXや構造化データへ移す作業も、この検査体系と公共データ活用のための基盤になる。

第四、組織はCDRを既定値に、個人は五つの習慣を [組織・個人]

組織。 CDR（Content Disarm and Reconstruction、コンテンツ無害化）は文書からOLEオブジェクト、スクリプト、外部リンクのような実行要素を取り除き、安全な文書として再構成する。脆弱点が知られていてもいなくても働くので、軸Aのゼロデイと軸Bの偽装リンクの両方に効果がある。外部から入る文書はCDRを経てからだけ開くよう、メールゲートウェイの既定値にすべきだ。

個人。 政策と技術が変わるには数年かかる。その間、北朝鮮が狙うのは結局ひとりのクリックだ。

今日からできる五つ

  1. 初めて連絡してきた教授・記者・作家が文書を送ってきたら、もともと知っている経路でもう一度確認する。 2023年の米韓共同勧告は短いビデオ通話で身元を確認する方法を勧めた。素顔かもしれない瞬間のビデオ通話だとしても。
  2. 文書を開いたとき「コンテンツを許可」「実行」などの警告が出たら押さない。 正常な報告や質問票はそんな許可を求めない。
  3. 文書の中のリンクとアイコンは文書ではない。 どうしても必要ならリンク先を自分で確認し、ブラウザに別に入力する。
  4. Windowsエクスプローラーで「ファイル拡張子を表示」をオンにする。 HWPアイコンを付けた .lnk は文書ではなく実行ファイルだ。
  5. ハンコムオフィスを最新に保ち、サポートが終わった旧版は替える。 怪しい文書を受け取ったらKISA（118）か国家情報院（111）に通報する。

7. 予想される反論と応答

「それならMSワードに乗り換えればいいのでは？」実際、国家AI戦略委員会の民間委員の間でもワード導入論が出た。しかしワードに変えてもハッキングの単一攻撃軸が消えるのではなく、別会社のC++パーサへ移るだけだ。ワードもマクロとOLEを悪用した攻撃の常連経路だった。さらに数十年分の公共書式と韓国語組版資産を捨てる費用、国家中核の文書インフラを海外企業一つに依存するリスクも勘定すべきだ。問題は「国産か外産か」ではなく「検査可能でメモリ安全か」だ。その基準を満たすならHWPXでもDOCXでもODFでも構わない。HWPXが現実的な出発点である理由は、既存の書式資産を最も損失なく移せるからだ。

「公務員と研究者の転換費用は？」小さくない。古い様式が壊れ、旧版ユーザーはファイルを開けず、部署間のシステム連携も手を入れる必要がある。だから政府も公職者統合メールに5か月の猶予を置き、案内ポップアップから出す段階的方式を選んだ。転換費用は実在するが、13年続いた侵入の費用と比べると話が変わる。

「ハンコムはこれまで何もしてこなかったのか？」そうではない。ハンコムは2010年からHWPXを支援し、2021年の定期パッチでHWPXを既定の保存形式に変えた。2018年ごろには攻撃経路になった内蔵ゴーストスクリプトモジュールをセキュリティ更新で除去し、脆弱点が報告されればKrCERT/CCを通じてパッチを出している。本コラムの要点はハンコムの努力が足りないことではなく、パッチとフォーマット転換という今のやり方だけでは言語レベルの欠陥系統を終わらせられないということだ。次の段階はコードの土台を変えることだ。

「Rustに変えれば北朝鮮ハッキングは終わるのか？」 終わらない。第3章で見たとおり、Rustは軸Aを減らすだけで、偽装リンクを押す軸Bは止められない。だから処方は四つが一組でなければならない。

結び

1989年、外国ソフトがハングルをまともに扱えなかった時代に、大学生数人が韓国語で文書を書く仕方を変えた。彼らが書いたCコードは30年以上、この国の行政と研究と産業を支えてきた。

そのコードは今も当時の姿のまま動く。変わったのは外側の世界だ。北朝鮮はその隙間を13年掘り続け、コードを最初に設計した人々は現場を一人また一人と離れた。公務員メールでHWPが止まるこの10月は、終わりではなく始まりでなければならない。フォーマットを変えた次はコードを変え、コードを変えた次はその知識を次の世代に残さなければならない。

1989年の大学生たちにCがあったなら、2026年の私たちにはAIとメモリ安全言語がある。ハングルを書き直すことはその遺産を捨てることではなく、その遺産があと30年耐えるようにすることだ。

参考リンク

北朝鮮のHWP攻撃事例

脆弱点・共同勧告

開放型文書転換政策

メモリ安全言語への転換