APT-C-60「SpyGlace」攻撃を分解する — mshta.exeとGitHubを使われても検知する方法

公開 2026年7月14日 最終更新 2026年7月28日 98回閲覧 0件のコメント
執筆: クルモン 専門分野: Webインフラ、セキュリティ、データベース
目次
LINUX KERNEL SECURITY

💬 くるるちゃんのワンポイント図解解説

【技術背景・解説】
Linuxカーネルの非同期I/Oイベント通知機構であるepollにおいて、特定条件下で競合状態（Race Condition）が発生し、メモリ保護が回避される脆弱性です。

【アイキャッチ図解のポイント】
中央で循環するシアンのイベント通知ループ（epoll）に対し、外周の琥珀色カーネル安全検証モジュールがリアルタイムで割り込み状態をチェックし、競合発生を未然に遮断・監視する防御システムを表現しています。

【資格・要点ノート】
Linuxカーネル脆弱性対応、Race Condition防止、非同期I/O安全制御

結論

JPCERT/CCが2026年7月に公開した「APT-C-60による2026年の攻撃について」は、 日本国内の組織を標的にした攻撃グループ APT-C-60 が、Windows標準機能と GitHub / GitLab / jsDelivr / Codeberg といった正規クラウドサービスを段階的に悪用して、遠隔操作型マルウェア「SpyGlace」を送り込む手口を詳細に報告したものです。

一言でいえば、メールからRARファイルを開かせ、Windowsの正規機能(mshta.exe)と正規サービス(GitHub等)を悪用して マルウェアを段階的に取得させる攻撃です。個々の通信・プロセス起動はどれも「正規」に見えるため、 URLブラックリストやシグネチャ単体では検知しづらいのが最大の特徴です。当サイトの kururuIPS/EDR には、 この一連の挙動をチェーンとして捉える検知シグネチャ apt_c60_mshta_chain を追加しました。

執筆にあたって確認した範囲では、JPCERT/CCの日本語原文以外に、この2026年7月更新分を対象にした 日本語での技術的な深掘り解説はまだ多くありません(英語圏では JPCERT/CC 英語版のほか複数のセキュリティ企業が 速報を出しています)。本記事では原文の内容に加えて、2024年・2025年の同グループの活動と比較した 手口の変化、検知ロジックの考え方、組織側のチェックリストまでをまとめて日本語で整理することを目的にしています。

攻撃全体の流れ

標的型メール(スピアフィッシング)
  ↓
Proton Driveへのリンク、またはメールへの直接添付
  ↓
RARファイルをダウンロード
  ↓
RAR内のLNKファイルを実行
  ↓
Windows標準のmshta.exeが起動
  ↓
難読化されたJavaScriptを実行
  ↓
jsDelivr(正規CDN)からcontributing[1].txt等の追加ファイルを取得
  ↓
正規のgit.exeを悪用してスクリプトを実行
  ↓
分割された複数の.dbファイルを結合してダウンローダーを生成
  ↓
GitHub・GitLab・Codebergなどから追加マルウェアを取得
  ↓
SpyGlace(確認バージョン: 3.1.15 / 3.1.17 / 3.1.18)に感染
  ↓
攻撃者が端末を遠隔操作

メールにRARファイルが直接添付されるケースも確認されており、「Proton Driveのリンクだけ遮断すれば防げる」 という単純な話ではない点に注意が必要です。

2024年→2025年→2026年でどう変化したか

APT-C-60はJPCERT/CCが2024年12月・2025年11月・2026年7月と継続して報告しているグループです。 過去2回のJPCERT/CC英語版レポートも確認したところ、配布形式・悪用サービス・マルウェアバージョンが 年ごとに更新されていることが分かります。

2024年(2024年8月の活動)2025年(2025年6-8月の活動)2026年(本記事)
入口 採用担当者を装うメール+Google Driveリンク メールへのVHDX直接添付 Proton Driveリンク、またはメール直接添付
アーカイブ/コンテナ形式 VHDX(仮想ディスク) VHDX RAR
起点ファイル LNK(例: Self-Introduction.lnk) LNK LNK
実行プロキシ git.exeが直接IPML.txtを実行 git.exe(gcmd.exe) mshta.exeが難読化JSを実行→git.exeを悪用
悪用された正規サービス Bitbucket、StatCounter GitHub、StatCounter GitHub、GitLab、jsDelivr、Codeberg
永続化・ダウンローダー SecureBootUEFI.dat ボリュームシリアル+コンピュータ名でデバイス識別 分割.dbファイルを結合して生成
SpyGlaceバージョン 3.1.6 3.1.12 / 3.1.13 / 3.1.14 3.1.15 / 3.1.17 / 3.1.18

この3年分を並べると分かるのは、「LNKファイルをユーザーに実行させ、正規の実行ファイル/正規サービスを 中継する」という骨格は変えず、コンテナ形式(VHDX→RAR)・実行プロキシ(git.exe単体→mshta.exe経由)・ 悪用サービスの種類だけを毎回入れ替えているということです。ドメインや拡張子ベースの対策は その時々では有効でも、次の更新で回避されやすい構造だと考えられます。

APT-C-60とは何者か

2026年7月13日、JPCERT/CCは、日本国内の組織を狙う攻撃グループ「APT-C-60」の新たな攻撃活動を公表しました。

今回の攻撃では、Proton Driveやメール添付からRARファイルを届け、内部のLNKファイルを開かせた後、Windows標準のmshta.exe、正規のgit.exe、GitHub、GitLab、jsDelivr、Codebergなどを段階的に悪用し、最終的にバックドア型マルウェア「SpyGlace」を実行します。

APT-C-60の怖さは、未知の魔法のような攻撃を使うことではありません。

メール、圧縮ファイル、Windows標準機能、開発者向けクラウドサービスという、普段から信頼されているものを組み合わせ、攻撃全体を正常な業務通信に見せる点にあります。

本記事では、APT-C-60は誰なのか、どのような目的を持つ攻撃者なのか、2024年から2026年に手口がどう変わったのか、企業は何を監視すべきかを、公開情報に基づいてわかりやすく整理します。

APT-C-60は誰なのか

APT-C-60は、個人名や企業名ではありません。

セキュリティ研究者が、共通するマルウェア、攻撃手順、標的、インフラの使い方などを基に、同じ攻撃主体または近い活動群として追跡するために付けた識別名です。

公開情報から最も安全に説明すると、APT-C-60は次のような攻撃者です。

  • 日本を含む東アジアの組織を継続的に狙う

  • 金銭要求よりも情報窃取や長期的な遠隔操作を重視する

  • 採用担当者など、外部からファイルを受け取る部門を狙う

  • SpyGlaceというバックドアを継続的に更新して使用する

  • 正規クラウド、CDN、Windows標準機能を悪用して検知を避ける

  • 必要に応じてソフトウェアのゼロデイ脆弱性も悪用する

ESETはAPT-C-60を「South Korea-aligned cyberespionage group」、つまり韓国との方向性・関連性が指摘されるサイバー諜報グループと説明しています。

ただし、これは「韓国政府の組織である」「韓国人が実行している」と確定した意味ではありません。

JPCERT/CCの公開記事も、日本や東アジアで確認された攻撃事実を中心に説明しており、国家や具体的組織への帰属を断定していません。

したがって、記事で「韓国政府系ハッカー」と言い切るのは不正確です。

韓国との関連性を指摘する分析がある、東アジア指向のサイバー諜報グループと表現するのが妥当です。

APT攻撃の帰属は、マルウェアの類似性、使用言語、活動時間帯、インフラ、標的、コードの特徴などから推定されます。しかし、攻撃者が他国のツールや言語を意図的に使い、分析者を誤誘導することもあります。

そのため、「誰なのか」という問いへの正確な答えは、次のようになります。

APT-C-60の実行者個人や正式な所属組織は公開情報では特定されていない。ただし、日本を含む東アジアを狙い、SpyGlaceを継続利用するサイバー諜報型の活動群として追跡されている。

APT-C-60の目的は金銭ではなく情報窃取

ランサムウェア集団は、暗号化したデータと引き換えに金銭を要求するため、目的が比較的わかりやすい攻撃者です。

一方、APT-C-60は、侵入後すぐに金銭要求を行うタイプではありません。

SpyGlaceには、端末情報の取得、ファイル操作、追加モジュールの読み込み、ファイルのアップロードやダウンロード、スクリーンショット取得など、侵害端末を継続的に遠隔操作するための機能が確認されています。

2025年の活動では、ボリュームシリアル番号とコンピュータ名を使って被害端末を識別し、端末ごとに異なるファイルをGitHubから取得させる仕組みも報告されました。

攻撃者は、感染したすべての端末へ一律に最終マルウェアを配るのではありません。

まず、StatCounterなどへの通信を通して端末を認識し、価値があると判断した端末に対応するファイルをGitHubへ配置します。Downloaderは、その端末専用のファイルを取得して次の感染段階へ進みます。

これは、不特定多数へ大量感染させて即座に収益化する犯罪よりも、価値のある組織や端末を選別し、情報を集め続ける諜報活動に近い運用です。

なぜ採用担当者が狙われるのか

2024年と2025年にJPCERT/CCが確認した日本向け攻撃では、求職者や入社希望者を装い、組織の採用担当者へ履歴書や職務経歴書に見せかけたファイルを送る手口が使われました。

採用担当者は、業務上、社外の知らない人物から文書やクラウドストレージのリンクを受け取らなければなりません。

攻撃者から見ると、次の条件がそろった非常に狙いやすい窓口です。

  • 外部メールを日常的に受け取る

  • 添付ファイルを開く業務上の理由がある

  • PDF、Word、圧縮ファイル、クラウドリンクが不自然に見えにくい

  • 応募者ごとにファイル名や本文が違っても疑われにくい

  • 人事情報や社内アカウントへ接続できる端末を使用している

  • 応募者へ早く返信する必要があり、確認を急ぎやすい

「怪しい添付ファイルを開くな」という精神論だけでは防げません。

採用窓口では、外部ファイルをブラウザプレビュー、無害化環境、サンドボックス、VDIなどを経由して確認する運用設計が必要です。

社員の注意力を最後の防壁にするのではなく、危険なファイルを通常端末で直接開かなくても仕事が進む仕組みを作るべきです。

2024年：Google Drive、VHDX、git.exe、SpyGlace v3.1.6

JPCERT/CCが2024年8月ごろに確認した攻撃では、入社希望者を装ったメールからGoogle Drive上のVHDXファイルをダウンロードさせ、仮想ディスク内のLNKファイルを実行させていました。

LNKファイルは、正規のgit.exeを利用して悪意あるスクリプトを実行します。その後、BitbucketやStatCounterなどの正規サービスから追加ファイルを取得し、COMハイジャッキングを使って永続化していました。

最終的に実行されたバックドアはSpyGlace v3.1.6です。

JPCERT/CCは当初、マルウェア名を「SpyGrace」と記載していましたが、2025年9月1日の追記で、正式には「SpyGlace」であると訂正しています。

ここで既に、APT-C-60の基本設計が見えています。

  1. 業務文書に見せかけてユーザーに開かせる

  2. VHDXやLNKで通常の添付検査を回避する

  3. 正規プログラムを実行の中継役にする

  4. 正規サービスから追加ファイルを取得する

  5. SpyGlaceを配置し、遠隔操作を可能にする

2024年：WPS Officeのゼロデイ脆弱性も悪用

APT-C-60は、ソーシャルエンジニアリングだけに依存する集団ではありません。

ESETは2024年、APT-C-60がWPS Office for Windowsのコード実行脆弱性CVE-2024-7262を実際の攻撃で悪用していたと報告しました。

ESETの解析では、攻撃者が正規の表計算文書に見えるファイルを武器化し、WPS Officeのプラグイン読み込みやパス検証の不備を利用してコード実行へつなげていました。

調査の過程では、別経路から同様に悪用できるCVE-2024-7263も発見され、両脆弱性は修正されています。

ESETによると、CVE-2024-7262は、攻撃用ファイルが最初に使用された時点ではゼロデイ脆弱性でした。APT-C-60は、東アジアの標的を攻撃するために、この脆弱性を武器化していました。

この事実は重要です。

APT-C-60は「ユーザーがLNKを開かなければ終わり」という単純な相手ではありません。

攻撃キャンペーンに応じて、標的型メール、正規機能の悪用、ソフトウェア脆弱性を使い分けられる能力を持っています。

2025年：VHDXを直接添付し、被害端末を個別管理

JPCERT/CCが2025年6月から8月に確認した活動では、前年のGoogle Drive経由から、悪性VHDXファイルをメールへ直接添付する方式に変化しました。

VHDX内のLNKファイルを開くと、正規のGit実行ファイルで悪性スクリプトが動作し、COMハイジャッキングによる永続化へ進みます。

さらに、DownloaderはStatCounterへ定期通信し、ボリュームシリアル番号とコンピュータ名を使って端末を識別しました。

攻撃者が対象端末を確認した後、その端末専用のファイルをGitHubへ配置すると、Downloaderが対応ファイルを取得して次の段階へ進みます。

つまり、攻撃者は感染端末を一律に扱うのではなく、「調査する価値がある端末か」を確認しながら追加ペイロードを渡していたと考えられます。

このキャンペーンでは、SpyGlace v3.1.12、v3.1.13、v3.1.14が確認されました。

2026年：Proton Drive、RAR、mshta.exe、複数の正規サービス

2026年7月13日に公開されたJPCERT/CCの最新報告では、初期侵害方法と攻撃インフラがさらに変更されました。

確認された主な流れは次のとおりです。

標的型メール
  ↓
Proton Driveのリンク、または悪性ファイルの直接添付
  ↓
RARファイル
  ↓
RAR内のLNKファイルを実行
  ↓
mshta.exeがLNK内部の難読化JavaScriptを実行
  ↓
jsDelivrから追加ファイルを取得
  ↓
展開先の正規git.exeでスクリプトを実行
  ↓
複数の.dbファイルを結合してDownloaderを生成
  ↓
GitHub・GitLab・Codebergなどから追加ペイロードを取得
  ↓
SpyGlace v3.1.15 / v3.1.17 / v3.1.18を実行

LNKファイルにはJavaScriptコードが含まれており、実行されるとmshta.exeを使って、そのJavaScriptを動かします。

JavaScriptはjsDelivrから追加ファイルを取得し、展開されたフォルダー内の正規git.exeを使って後続スクリプトを実行します。

さらに、複数の.dbファイルを結合してDownloaderを生成し、GitHubなどから追加のDownloader、Loader、SpyGlaceを取得します。

2026年版では、Proton Driveを経由しないメール直接添付も確認されています。

そのため、「Proton Driveを遮断すれば防げる」という対策では不十分です。

APT-C-60の一貫した骨格

APT-C-60は、攻撃の骨格を維持しながら、入口とインフラを変更しています。

変わっているのは、ファイル形式、配布元、正規サービス、マルウェアのバージョンです。

一方で、次の特徴は一貫しています。

  • ユーザーにLNKファイルを開かせる

  • 正規プログラムを代理実行に使う

  • 正規サービスから追加ファイルを取得する

  • 感染を複数段階に分割する

  • SpyGlaceを最終的に実行する

  • COMハイジャッキングなどで永続化する

したがって、特定ドメインや特定ハッシュだけに依存した対策は、次のキャンペーンで回避される可能性があります。

mshta.exeが危険視される理由

mshta.exeは、Microsoft HTML Applicationを実行するWindowsの正規ユーティリティです。

正規ファイルであるため、存在するだけでは異常ではありません。

しかし、mshta.exeはJavaScriptやVBScriptなどを実行でき、攻撃者が悪意あるコードを信頼済みのWindowsプログラム経由で動かすために悪用できます。

MITRE ATT&CKでは、この手法をT1218.005 System Binary Proxy Execution: Mshtaとして整理しています。

MITREは、mshta.exeによる不審なスクリプト実行を検知する際、次の情報を相関させる必要があると説明しています。

  • 親プロセス

  • コマンドライン

  • ファイル作成

  • 外部通信

  • 子プロセスの起動

つまり、mshta.exeを見つけたら即座にマルウェアと判断するのではなく、次のような前後関係を監視します。

  • メールやダウンロードフォルダーからRARが展開された

  • RAR内のLNKファイルが実行された

  • LNKを起点にmshta.exeが起動した

  • mshta.exeが外部ネットワークへ接続した

  • 直後にgit.exeやスクリプトが起動した

  • 一時フォルダーへ.dat、.db、.tmpなどが連続して作成された

単一イベントではなく、時系列でつながった挙動を検知する必要があります。

正規サービスをブロックするだけでは防げない理由

GitHub、GitLab、jsDelivr、Codebergは正規サービスです。

開発部門では日常的に使われ、ソフトウェアやWebサイトの配信にも利用されます。

ドメイン全体を遮断すると、正規業務へ大きな影響が出ます。また、攻撃者は利用するアカウント、リポジトリ、ファイル名、サービスを変更できます。

見るべきなのは「どこへ接続したか」だけではありません。

  • どのプロセスが接続したか

  • どの親プロセスから起動したか

  • 直前にどのファイルを開いたか

  • 接続後に何が作成・実行されたか

  • 開発者端末か、通常はGitを使わない人事端末か

JPCERT/CCも、開発者向けサービスやCDNは業務環境からアクセスが許可される場合が多く、通信先だけを基にした検知や遮断が難しいと指摘しています。

ブラウザやIDEからGitHubへ接続するのと、LNKから起動したmshta.exeがCDNへ接続するのでは、危険度がまったく異なります。

APT-C-60を防ぐための優先対策

1. 外部メール由来のLNKを原則隔離する

RAR、ZIP、7z、VHDXなどの内部にLNKが含まれている場合は、高リスクとして隔離またはサンドボックス解析します。

次の条件は特に危険です。

  • 外部メールから届いた圧縮ファイル

  • 圧縮ファイル内にLNKが存在する

  • 文書に見せかけたアイコンが設定されている

  • resume.pdf.lnkのような二重拡張子

  • クラウドストレージから圧縮ファイルを取得させる

  • 人事、経理、営業など、通常はLNKを受け取らない部門へ届いた

業務上不要であれば、外部から届くLNKは原則隔離するのが有効です。

2. 採用担当者のファイル確認フローを分離する

応募書類は通常端末で直接開かず、次のいずれかを経由します。

  • ブラウザプレビュー

  • CDRによるファイル無害化

  • サンドボックス

  • VDI

  • 閲覧専用端末

  • マクロやスクリプトを実行できないプレビュー環境

「採用担当者が注意する」ではなく、「採用担当者が危険な形式を直接実行できない」仕組みに変えることが重要です。

3. EDRでプロセスツリーを相関分析する

最低限、次の連鎖を検知候補にします。

mshta.exe単体やGitHub通信単体では誤検知が増えるため、親子関係、時間差、ファイル作成、接続先を組み合わせてスコアリングします。

概念的には次のような判定です。

IF 外部メール由来のアーカイブを展開
AND アーカイブ内のLNKを実行
AND 120秒以内にmshta.exeが起動
THEN リスクスコアを加算

IF mshta.exeが外部通信
AND 直後にgit.exeまたはスクリプトが起動
THEN リスクスコアを加算

IF 一時フォルダーに複数の.db/.dat/.tmpが生成
THEN リスクスコアを加算

IF 合計スコアがしきい値以上
THEN 端末隔離または重大アラート

4. 業務上不要ならmshta.exeを制限する

MITRE ATT&CKは、環境で不要な場合、アプリケーション制御によるmshta.exeのブロックを緩和策として挙げています。

Microsoftは、Windowsのアプリケーション制御技術として次の2つを提供しています。

  • App Control for Business

  • AppLocker

アプリケーション制御は、許可されたコードだけを実行させる仕組みです。ただし、ウイルス対策ソフトの代替ではなく、併用する必要があります。

いきなり全社で遮断すると既存業務へ影響する可能性があるため、次の順番で進めます。

  1. 監査モードでmshta.exeの利用状況を記録する

  2. 業務利用している端末と処理を特定する

  3. 人事端末など、利用していない範囲から制限する

  4. 例外ルールを整理する

  5. ブロックモードへ段階的に移行する

5. IoCとTTPを分けて管理する

IPアドレス、ハッシュ、リポジトリ名は短期検知に役立ちますが、攻撃者が変更できます。

一方、次のTTPは比較的長く残ります。

  • 外部人物を装った標的型メール

  • 圧縮ファイルや仮想ディスク内のLNK

  • 正規Windowsバイナリによる代理実行

  • 正規クラウドやCDNを使った多段配布

  • 被害端末を識別して追加処理を変える運用

  • SpyGlace系バックドアの継続利用

SOCでは、IoC一致アラートと行動ベースの検知を別レイヤーで持つ必要があります。

不審なファイルを開いてしまった場合の初動

不審なRARやLNKを開いた場合は、次の順番で対応します。

  1. 対象端末をネットワークから隔離する

  2. すぐに電源を落とさず、セキュリティ担当へ連絡する

  3. 元メール、RAR、LNK、ダウンロードURLを保全する

  4. mshta.exe、git.exe、スクリプトの実行履歴を確認する

  5. GitHub、GitLab、jsDelivr、Codebergへの通信を調査する

  6. .db、.dat、.tmpファイルの作成履歴を確認する

  7. COMハイジャッキングなどの永続化を調査する

  8. 同じメールが他の従業員へ届いていないか確認する

  9. 感染が確認された場合は、クリーンな端末から認証情報を変更する

  10. 必要に応じて端末を再イメージする

JPCERT/CCが公開したIPアドレス、ハッシュ、URL、リポジトリ名との照合も有効です。

ただし、IoCに一致しないことは、安全の証明になりません。

既知の値との照合と、プロセス・通信・ファイル作成の時系列調査を両方行う必要があります。

よくある質問

APT-C-60は韓国のハッカーですか？

ESETは「South Korea-aligned」と評価していますが、公開情報だけで実行者の国籍、所属組織、政府との関係を確定することはできません。

「韓国との関連性を指摘する分析がある、東アジア指向のサイバー諜報グループ」と理解するのが適切です。

SpyGraceとSpyGlaceは別のマルウェアですか？

JPCERT/CCは、以前のSpyGrace表記を訂正し、正式にはSpyGlaceとしています。

古い記事や転載ではSpyGraceが残っている場合がありますが、本記事ではSpyGlaceに統一します。

2026年の攻撃はWindowsの脆弱性を悪用しますか？

JPCERT/CCが2026年に報告した流れは、主にユーザーにLNKを開かせ、mshta.exeなどの正規機能を悪用するものです。

そのため、Windows Updateだけでは防ぎきれません。

ただし、APT-C-60には過去にWPS Officeのゼロデイ脆弱性CVE-2024-7262を悪用した実績があります。

GitHubやGitLabを禁止すれば防げますか？

一部の環境では遮断が有効ですが、開発業務への影響が大きく、攻撃者は別の正規サービスへ移動できます。

接続元プロセス、親子関係、直前のファイル操作、接続後の実行を組み合わせて判断する方が重要です。

mshta.exeは削除してもよいですか？

OSファイルを手作業で削除するのではなく、業務利用の有無を確認し、App Control for BusinessやAppLockerなどの実行制御で段階的に制限する方法が安全です。

ウイルス対策ソフトだけでは防げませんか？

APT-C-60は、正規プログラムと正規サービスを利用し、最終マルウェアを複数段階に分けて取得します。

静的なファイルスキャンだけではなく、メール、ファイル、プロセス、通信、レジストリを横断した監視が必要です。

Microsoftも、従来型のウイルス対策だけでは新しい攻撃への防御として不十分であり、アプリケーション制御などとの併用が必要だと説明しています。

ここまでのまとめ

APT-C-60は、正体が公開された犯罪組織ではなく、共通する攻撃活動を追跡するための脅威アクター名です。

公開情報からは、日本を含む東アジアを継続的に狙い、SpyGlaceを使って情報窃取や遠隔操作を行うサイバー諜報型の攻撃者と評価できます。

2024年は、Google Drive、VHDX、Bitbucket、StatCounter、SpyGlace v3.1.6。

2025年は、VHDX直接添付、GitHub、端末別のペイロード管理、SpyGlace v3.1.12〜v3.1.14。

2026年は、Proton Driveまたは直接添付、RAR、mshta.exe、jsDelivr、GitHub、GitLab、Codeberg、SpyGlace v3.1.15、v3.1.17、v3.1.18へ変化しました。

変わっているのは、入口と中継サービスです。

変わっていないのは、人をだましてファイルを開かせ、正規機能と正規サービスへ紛れ込み、多段階でバックドアを完成させる設計です。

防御側も、特定IPやハッシュだけを追うのではなく、

外部メール → アーカイブ → LNK → mshta.exe → 正規サービス通信 → git.exe → 追加ファイル生成

という攻撃チェーン全体を監視しなければなりません。

APT-C-60は、メール対策、EDR、アプリケーション制御、ネットワーク監視、IPS、XDR、SOC分析を連携させる必要性を示す、典型的な現代型サイバー諜報活動です。

なぜ検知しにくいのか

1. 一つひとつの挙動が正規である

mshta.exe はWindows標準のHTAアプリケーション実行機能、git.exe は開発現場で日常的に使われるツール、 GitHub・GitLab・jsDelivr・Codebergは開発者なら誰もが利用する正規サービスです。ドメイン単位・実行ファイル単位で 一律に禁止することは業務影響が大きく現実的ではありません。

2. マルウェアが段階的に(小分けで)配布される

最初のLNKファイルの時点ではSpyGlace本体は含まれておらず、JavaScript→分割.dbファイル→ダウンローダー→ローダー→ SpyGlace本体、という複数段階を経て初めて完成します。メール添付ファイルを静的スキャンするだけの対策では、 最終的なマルウェアまで到達できない可能性があります。

3. 通信先が正規サービスのドメインである

github.com / gitlab.com / cdn.jsdelivr.net / codeberg.org を組織的にブロックすることは通常困難です。 重要なのは「GitHubに接続したこと」ではなく、「mshta.exeがGitHubやCDNへ接続した」 「RAR展開直後にLNK→mshta→外部通信という順序で発生した」という一連の流れで判定することです。

MITRE ATT&CKで見る攻撃技術

JPCERT/CCの報告内容をMITRE ATT&CKの技術に当てはめると、おおむね次のように整理できます。

攻撃の段階手法ATT&CK(参考)
メール内のクラウドリンク/添付Spearphishing Link / AttachmentT1566系
RAR・LNKを開かせるUser Execution: Malicious FileT1204.002
mshta.exe悪用System Binary Proxy Execution: MshtaT1218.005
難読化JavaScriptObfuscated Files or InformationT1027系
正規CDN/Gitサービス経由の取得Ingress Tool Transfer / Web ServiceT1105 / T1102系

悪意あるファイルをユーザーに開かせる行為や、追加ツールの外部転送は、いずれもMITRE ATT&CKで代表的な攻撃技術として 整理されているものです。特別な未知の技術ではなく、既知の技術の組み合わせと段階化が この攻撃の本質だと考えています。

当サイトで実施した対応

  1. kururuIPS/EDRに新しい検知シグネチャ apt_c60_mshta_chain を追加しました。 mshta.exeの単体起動やGitHub/CDNへの通常アクセスだけでは誤検知するため、 「LNK/アーカイブ実行を起点として mshta.exe が起動し、そこから git.exe や 正規CDN(jsDelivr等)との通信が連鎖して観測された場合」を優先的に拾う設計にしています。
  2. 脅威情報として APT-C-60 / SpyGlace のキャンペーンを脆弱性・脅威管理台帳に登録し、 継続的に参照できるようにしました。
  3. エンドポイント側でmshta.exeを業務上使用していない環境では、 アプリケーション制御(WDAC/AppLockerなど)による制限を、監査モードから段階的に検討することを 社内向けの推奨事項として整理しました。

判定ロジックの考え方を簡略化すると、次のようなイメージです(実際のコードを単純化した概念図であり、 そのままの設定ファイルではありません)。 

IF archive_extracted(.rar/.zip) AND lnk_executed
   AND process_started("mshta.exe") within 120s of lnk_executed
THEN chain_score += 高

IF "mshta.exe" spawned "git.exe"
   OR "mshta.exe" connected to (jsdelivr.net / github.com / gitlab.com / codeberg.org)
THEN chain_score += 高

IF chain_score >= しきい値
THEN signature = "apt_c60_mshta_chain", severity = critical

ポイントは、mshta.exe単体の起動やgithub.comへの通常アクセスだけでは スコアが閾値に届かない設計にしていることです。あくまで「アーカイブ実行→LNK→mshta.exe→ 正規サービスとの通信」という時系列でつながった一連の挙動を要求します。

組織で優先すべき対策(読者向けチェックリスト)

P0: メールゲートウェイでRAR内LNKを高リスク扱いにする

  • RAR/ZIP/7z内にLNKファイルが存在する
  • LNKのファイル名が文書ファイルらしい、または二重拡張子になっている
  • 外部クラウドストレージのリンクから圧縮ファイルを取得させようとしている

業務上不要であれば、外部メールから届くLNKファイルは原則隔離するのが有効です。

P0: プロセスの連鎖をEDRで監視する

特に次の連鎖は優先度高く監視します。

  • LNK実行 → mshta.exe起動
  • mshta.exeが外部ネットワークへ接続
  • mshta.exeの直後にgit.exeが起動
  • 開発者以外の端末でgit.exeが、ダウンロードフォルダーや一時フォルダー内のスクリプトを実行
  • mshta.exeの直後に.js/.tmp/.dat/.dbファイルが大量作成される

P1: 業務上不要ならmshta.exeを制限する

組織内でHTA(HTML Application)を業務利用していない場合は、アプリケーション制御でmshta.exeの実行を 制限することを検討できます。いきなり全社ブロックするのではなく、監査モードで業務影響を確認したうえで 段階的にブロックモードへ移行するのが安全です。

P1: 通信先をドメイン単体で判断しない

GitHub/GitLab/jsDelivr/Codebergへの通信は、接続元プロセス・URL/リポジトリ名・直前に開いたファイル・ 作成された子プロセスと組み合わせて評価します。ブラウザや開発用IDEがGitHubへ接続することと、 mshta.exeがGitHubへ接続することでは危険度が大きく異なります。

IoC(侵害指標)の例

JPCERT/CC原文に掲載されている例の一部を抜粋します(攻撃者側の運用により今後変わる可能性があります。 自組織のログと照合する際は、値そのものより下記の"パターン"を参考にしてください)。

  • 送信元メールアドレスの例: [email protected] のようなProtonMailアドレス
  • リポジトリの例: github.com/mei1990789/class125、gitlab.com/sapphire689/dnaluakxit のような、意味を持たない文字列名のアカウント/リポジトリ
  • SpyGlace 3.1.15のファイルハッシュ(SHA-256)例: e5f2c7068ade7b87d24c3b94bc749c351d53609f5fcaa48dce06234beaa2444f

すでに不審なファイルを開いてしまった場合

  1. 対象端末をネットワークから隔離する(電源はすぐに切らない)
  2. セキュリティ担当へ連絡し、LNK・RAR・メール・ダウンロード元URLを保全する
  3. EDRでmshta.exeとgit.exeの実行履歴、GitHub/GitLab/jsDelivr/Codebergへの通信履歴を確認する
  4. JPCERT/CC公開のハッシュ値・IPアドレス・リポジトリ名と照合する
  5. 同じメールが他の従業員に届いていないか横展開を確認する
  6. 感染が確認された場合は、クリーンな端末から認証情報を変更し、必要に応じて端末を再イメージする

なお、JPCERT/CCの記事に掲載されたIoC(IPアドレス・ハッシュ値・リポジトリ名など)は攻撃者側の運用により 変更される可能性があります。今回公開された値に一致しないからといって安全とは限らない点にご注意ください。

誤解されやすいポイントの整理

読者から実際に寄せられた質問ではなく、この種の攻撃の解説でよく誤解が生じる論点を、 執筆時点で筆者(編集部)側から先回りして整理したものです。

誤解1: GitHubやjsDelivrを使っているだけで危険ではないか

いいえ。GitHubやjsDelivr自体は安全な正規サービスです。危険なのはこれらのサービスそのものではなく、 mshta.exeのような実行プロキシがLNK実行を起点として、これらのサービスへ通信するという 組み合わせ・順序です。

誤解2: ウイルス対策ソフトだけで防げるはず

個々のファイルが正規サービスから細かく分割・難読化されて配布されるため、静的スキャンだけでは 最終マルウェアまで到達できない可能性があります。メール・ファイル・プロセス・通信を横断して 攻撃の"流れ"を見る仕組みと組み合わせる必要があります。

誤解3: Windows Updateを適用していれば安全なはず

この攻撃はOSやミドルウェアの未修正の脆弱性を突くものではなく、正規機能を悪用してユーザーに ファイルを実行させる手口が起点です。パッチ適用だけでは防げず、メール対策・実行制御・行動監視の 組み合わせが必要です。

まとめ

APT-C-60の攻撃の本質は、特別な一つのマルウェアではなく、「人間をだます」「Windowsの正規機能を使う」 「正規クラウドサービスを使う」「マルウェアを細かく分割して段階的に取得する」という組み合わせです。 ウイルス対策ソフトだけ、URLブラックリストだけ、Windows Updateだけでは防ぎきれません。 メール・ファイル・プロセス・通信・レジストリを横断して攻撃の流れを検知することが重要であり、 今回のAPT-C-60は IPS・EDR・XDR・SOC を連携させる必要性が非常によく表れた事例だと考えています。

関連記事

出典・最終確認

最終確認日: 2026年7月22日。感染経路、正規サービスの悪用、SpyGlaceの確認バージョンは JPCERT/CCの2026年報告を出典としています。 脅威情報は変化するため、IoCは本文の公開時点の参考情報として扱ってください。

#セキュリティ #APT #APT-C-60 #SpyGlace #IPS #EDR #mshta #LOLBin
読んだ内容を10問練習と実技で確認

記事で理解した用語を、StudyQuestの演習とクラウド実技ラボで定着させます。

10問練習 実技ラボ

コメント（0件）

まだコメントはありません。最初のコメントを投稿してください！

コメントを投稿

関連記事