［2026年第2四半期｜インテリジェンスレポート］グローバル脅威インフラの動向

サンズラボの脅威分析チームは、収集情報を基に四半期ごとのインテリジェンスレポートを作成しています。

専門的な解析で明らかになったマルウェアの特徴、脅威動向、関連情報などを共有し、安全なサイバー環境の実現を目指しています。

さらに詳しい情報は、サイバー脅威インテリジェンスサービス<CTX>でご確認いただけます。

1. 要約

前四半期のレポートの主眼は、単純なIoC一覧を超えることにあった。IPアドレスやドメインは急速に変化するが、攻撃インフラの運用で繰り返し残されるメタデータは、より長く維持される。証明書、port、URI、ASN、時間帯、C2通信構造は、単なる遮断リストより寿命の長い手がかりとなる。本レポートはこの問題意識を引き継ぎ、攻撃者がどのインフラを選び、どう運用するかに一層焦点を当てる。

第2四半期のデータも同じ流れを示す。脅威インフラは消滅したのではなく、正規サービスの内部へさらに入り込んでいる。ClearFakeとClickFixはCloudflareや主要なクラウド・共有ホスティング環境で大量に検知され、古くから存在するドメインや侵害済みWeb資産を利用してレピュテーションに基づく遮断を回避していた。重要なのは、特定の提供者を悪性と断定することではない。防御側が直面する課題は、正規の業務通信と悪性キャンペーンの痕跡が同じサービス環境に混在するとき、何を根拠に区別するかである。

ライフサイクルを見ても同じ結論に至る。IoC全体の寿命の中央値は短いが、すべての脅威が短期間で終わるわけではない。検知直後に使い捨てられるIoCもあれば、検知後も長く残る、あるいはactive／dead状態を繰り返すキャンペーンもある。重要なのは観測件数よりも、現在も対応範囲に残っているか、再活性化する可能性があるか、同じインフラのフィンガープリントを繰り返すかである。

そのため、本レポートの中心は個々の攻撃ツールではない。攻撃者がどの提供者をどの役割で繰り返し選ぶかが、より有意義な分析軸となる。Cloudflareは悪性ペイロードやリダイレクトが正規CDNに混在する代表例で、Hostinger、Hetzner、Railnet、Namecheap系はペイロード配信や稼働中のC2・バックエンドへの対応が必要なインフラとして現れた。Alibaba、Tencent、Yancy系ASNにはC2／フレームワーク関連の脅威タグが高い割合で集中していた。検知量の比較より、提供者ごとの悪用される役割と対応優先度を区別する方が、インテリジェンスとしての価値が高い。

提供者の選択は、最終的にC2の運用方式につながる。攻撃者はC2の機能を1台に集約せず、ペイロード配信、設定値の提供、コマンド制御、アップロード・外部送信、代替経路候補に分け、各役割に適したサービスを選ぶ。CDNと古いドメインは到達性と信用を利用した隠蔽に、セルフサービス型ホスティングは迅速な交換とペイロード配信に、特定地域のクラウドASNは中核の制御インフラとして、より多く活用された。

Analyst’s Pickに選んだ、北朝鮮関連の攻撃者による開発者向けJavaScript C2の事例は、この流れを最も明確に示す。重要なのは特定のIPではなく、開発業務の信頼チェーン、SaaSによる設定値配信、Socket.IO／WebSocketの制御チャネル、アップロード・外部送信チャネルが1つの作戦構造につながる点である。特にvalidationヘッダー、ホストのメタデータ項目、Node.js依存関係の組み合わせは、サーバー変更後も残り得るC2の特徴であり、ファイル検知やネットワークパケット検知に転用する根拠となる。

本レポートの目的は、収集した脅威の手がかりを、防御側が実際に運用できる基準へ変換することである。即時遮断できる稼働中のC2・バックエンドとキャンペーンの証拠があるIoCを速やかに分け、業務影響が大きいクラウド・CDN・共有ホスティングのIoCは精査対象として管理する。ASN／提供者のプロファイル、C2運用モデル、URI／ヘッダー、SPKI／ASN_Port、ファイル痕跡は、長期的なハンティング指標として保持するのがよい。インフラが変化しても運用可能な検知ロジックを取り出すことに、分析の意義がある。

2. 概要

実際の防御に役立つには、収集したIoCを並べるだけでは不十分である。すでに無力化された多数のエンドポイントを知ることより、攻撃者がインフラをどう構成し、どのサービスを繰り返し選び、どんな痕跡を残すかが重要となる。

本レポートは、2026年3月1日から6月15日までに収集した59,833件のIoCを基に作成した。分析単位は個々のIoCにとどまらず、提供者、ASN、国、脅威タグ、URIパス、ポート、TLS／SPKIフィンガープリント、ライフサイクル、クラスターの証拠を検討した。

データ上、脅威インフラは2方向に分かれる。1つは即時遮断すべき稼働中のC2・バックエンドとペイロード配信インフラ、もう1つは正規サービスと混在し、提供者単位では遮断しにくい共有インフラの悪用である。同じ方法で扱うと防御方針の信頼性が損なわれる。一律に遮断すれば業務影響が大きく、精査だけにとどめれば稼働中のC2を見逃す。

そのため、収集量より防御判断に必要な基準を優先する。現在の稼働状態、再活性化の可能性、正規サービスとの混在度、同じフィンガープリントの反復、好まれる提供者とC2運用モデルに基づいて分類し直す。以降では、インフラ分布、提供者ごとの悪用、好まれるC2運用、稼働時間、回避パターン、SPKIによるキャンペーンの関連付け、Analyst’s Pick、実行可能な防御用成果物を順に扱う。

3. 2026年第2四半期のエコシステム

3.1. 正規サービスに入り込む攻撃インフラ

攻撃インフラは信用度の低いホスティングにとどまらず、防御側が容易に遮断できない正規サービスへ入り込んでいる。Cloudflareや主要クラウド・共有ホスティングは、ペイロード配信、リダイレクト、キャンペーン展開に繰り返し悪用された。防御側の問いも、頻出する提供者を遮断するかではなく、正規サービスに混在する悪性キャンペーンをどう見分けるかへ変える必要がある。

その中心にあるCLOUDFLARENETは、ASN-role／Tag基準で26,213件と提供者中最大の割合を占め、ClearFakeが18,644件（71.1%）、ClickFixが2,081件、Vidarが1,108件確認された。ASN-roleでもPayload deliveryが22,549件（86.0%）と中心的な役割だった。これはCloudflare自体を攻撃基盤と断定する根拠ではなく、正規サービスと悪性配信が同じ共有インフラに共存することを示す警告に近い。

そのためCloudflare関連IoCは、遮断リストより共有インフラの精査リストで扱う方が現実的である。URI、Hostヘッダー、証明書、脅威タグ、最新状態を併せて検知条件を絞る必要がある。大規模提供者の一括遮断は、誤検知による障害を招く。

3.2. 検知後も残るClearFakeとClickFix

ClearFakeとClickFixは最多のキャンペーンだが、件数の多さだけに注目すると重要な点を見落とす。共有インフラと古いドメインを使い、検知後も長く対応範囲に残った。一度遮断して終わりではなく、継続的な状態確認と過去ログの調査が必要な類型である。

四半期全体のタグ別では、ClearFakeが15,535件、ClickFixが10,648件だった。ClearFakeはActive 9,993件、Active ratio 64.33%、ClickFixはActive 8,123件、Active ratio 76.29%である。MTTD（Mean Time To Death）の中央値も、それぞれ1,289時間、1,489.7時間と長い。検知後も容易には対応対象から消えないことを示している。そのため、一度使ったIoCを破棄するのではなく、共有インフラの精査、稼働中ドメイン・URIの再検証、証明書とURI構造を組み合わせた遡及的ハンティングで管理すべきである。

3.3. 消えるIoC、残るフィンガープリント

ライフサイクルは特に慎重に読むべき指標である。全体の中央値は約0.35日と短く、この数字だけでは大半のIoCがすぐに意味を失うように見える。一方、同期間のSPKI再利用率は40.47%で、戦略的ハンティングシグネチャ128件中115件がSPKIベースだった。エンドポイントは早く消えても、証明書や配備の痕跡は繰り返される。

防御では両者を分ける必要がある。IP・ドメインの遮断リストはTTLを短く設定し、SPKI、通信パターン、URI、ヘッダーの組み合わせは長期的なハンティング指標として残す。IoCは早く失効しても、インフラのフィンガープリントは長く残る。

3.4. 攻撃ツール以上に情報をもたらすインフラの選択

データは、どの攻撃ツールが多いかよりも、どの提供者がどの役割で繰り返し悪用されるかを明確に示す。Cloudflareは正規CDNに混在するペイロードとリダイレクトの精査対象で、HostingerとNamecheapはClickFix中心の配信が遮断リストに多く移される提供者である。HetznerとRailnetは配信とbotnet／C2の役割が混在し、現在の対応を要する。Alibaba／Tencent／Yancy系は特定ASNにC2／フレームワークタグが集中する中核の運用インフラとして現れる。

この観点では個々のツールも独立した主題ではなく、提供者ごとの悪用を説明する手がかりとなる。Yancy Limitedはbotnet_cc roleがほぼ100%、C2／フレームワークタグが96.2%を占めた。Hangzhou AlibabaとShenzhen Tencentもbotnet_ccが大半で、同種のタグが高い割合で集中した。一方、Cloudflare、DigitalOcean、Vultr、Amazonは正規サービスと悪性キャンペーンが混在する共有インフラとして扱うべきである。主なハンティング軸はツール単体ではなく、ASN・提供者の役割、タグ集中度、稼働状態、悪用形態の組み合わせとなる。

3.5. C2をサーバーではなく運用モデルとして捉える

C2インフラは、1台がすべての機能を担うよりも、役割を分担する運用に近い。ペイロード配信、リダイレクト、設定値の提供、コマンド制御、アップロード・外部送信、代替経路候補を異なる環境に配置する。攻撃者は各機能に合うサービスを選び、防御側はその組み合わせを1つのC2運用モデルとして読む必要がある。

このモデルでは、Cloudflareと古いドメインは正規サービスの信用を利用した隠蔽・配信に、Hostinger、Namecheap、Hetzner、Railnetは配信と稼働サーバーに、Alibaba／Tencent／Yancy系はC2／フレームワークの集中度が高い中核制御インフラに近い。北朝鮮関連のJavaScript C2も、Vercelの設定配信、Git hook／precommit設定、ターミナル・API接続候補、Socket.IO／WebSocket制御、アップロード・外部送信チャネルが分離され、同じ運用論理を質的に示す。

3.6. 分析者が選ぶ事例：開発業務とC2の接続

Analyst’s Pickは大量観測されたキャンペーンではなく、件数は前述の大規模事例より少ない。それでも個別に扱う理由は、開発業務の流れがC2運用に直接つながるためである。正規の開発環境、SaaSによる設定配信、Git hook／precommitの流れ、ターミナル・API接続候補、サンプルで確認されたC2バックエンドが、1本の攻撃経路につながり得ることを示している。

Cluster 2046は46件のIoC、76件の活動記録、4件のSPKIからなる。希少タグは北朝鮮関連の「contagiousinter view」「lazarus」「web3-targeting」「novara1o1」に集中する。VercelベースのOS別設定配信、「precommit.ver cel.app」のGit hook／precommit config、「lab99.sbs /api/terminal/*」のターミナル・API接続候補、ROUTERHOSTINGのバックエンドpivot候補、静的解析で確認した「216.126.225.243:8087」のSocket.IO／WebSocket制御と「8085 /8086」のアップロード・外部送信を、役割ごとに分けて解釈できる。重要なのはIoC自体よりC2通信方式と役割分担である。

4. インフラ分布と提供者別の悪用形態

4.1. 特定提供者にIoCが集中する理由

提供者の分布は単なる占有率の順位ではなく、攻撃者がどこで正規サービスの信用と運用上の利便性を得ているかを示す。上位にはCloudflareのようなCDN・共有インフラ、DigitalOcean／Vultr／Amazonなどのパブリッククラウド、Hostinger／Namecheap系セルフサービス型ホスティング、Hetzner／Railnet／Yancy／Alibaba／Tencent系のVPSや地域クラウドASNが並ぶ。同じIoCでも、観測された提供者によって遮断・精査・ハンティングの基準を変える必要がある。

［表1］主要インフラ提供者別のIoC分布

［図1］ASN別に見た主要提供者の脅威構成

Cloudflareの圧倒的な割合は、直接遮断すべき対象の多さを意味しない。同じインフラで正規サービスと悪性キャンペーンの混在が広がっている兆候に近い。別添の共有インフラ精査リストは32,448件で、CLOUDFLARENETだけで26,209件を占める。頻出ASNを遮断するのではなく、その共有環境で悪性キャンペーンの証拠を絞るべきである。Cloudflare、DigitalOcean、Vultr、Amazon系では、提供者単位の遮断よりもHostヘッダー、URI、証明書、タグ、稼働状態を組み合わせた精査を優先する。

4.2. ASNとタグの組み合わせから見える役割

ASNとタグの組み合わせは、提供者を悪性と断定する指標ではない。同じ提供者でどのキャンペーンやC2活動が繰り返されるかを確認し、遮断・精査・ハンティングの基準に変える分析軸である。割合が高いほど、そのインフラの特徴が反復利用されている可能性が高い。強く確認された組み合わせを以下に示す。割合は全IoCに対するものではなく、当該提供者のIoC全体に占める特定タグの比率である。

［表2］主要なASN・タグの組み合わせと比率

［図2］主要なASN・タグの組み合わせの集中度

重要なのは個々のツール名よりも、組み合わせの傾向である。CloudflareではClearFake、ClickFix、Vidarが同じCDN・共有環境で繰り返され、HostingerとNamecheapではClickFix中心の配信が強く見られる。Yancy、Hangzhou Alibaba、Shenzhen Tencentへのcobaltstrikeタグの集中は、単一ツールの問題より、C2／フレームワーク活動が一部ASNに集まる兆候と読むのが妥当である。この組み合わせだけで提供者全体の遮断を判断せず、SPKI、port、TLSの稼働状態、URI／Hostを併せたハンティング条件に変えるべきである。

4.3. 提供者ごとに異なる悪用方法

IoCがCDN・共有環境、セルフサービス型ホスティング、クラウドの各リージョン、VPS事業者のどこにあるかで、防御方法は変わる。本節では主要提供者を悪用された特徴で分類し、遮断・精査・ハンティングの基準を分ける。ASN・提供者は単なる所有者情報ではなく、攻撃者が選んだ運用インフラとして解釈すべきである。

［表3］提供者別の悪用類型と対応基準

特定の提供者を悪性事業者と断定するための分類ではない。インテリジェンス上重要なのは、どの提供者の特徴が繰り返し悪用されたかである。無料試用・クレジット、セルフサービス登録、悪用通報への対応速度、KYCの水準、CDN・プロキシ機能、VPS作成の自動化可否は、OSINTで別途確認すべき補足情報となる。大半の事業者は公開規約で悪用を禁じており、安易には結論付けられない。

［図3］主要提供者別の脅威種別分布

4.4. 機能ごとに分担されるC2運用

重要なのは、どのC2が存在したかより、攻撃者がどう運用したかである。確認されたパターンは単一サーバー中心ではなく、役割分担、信用を利用した隠蔽、迅速な交換、フィンガープリントの再利用を組み合わせるモデルに近い。以下は攻撃手順の再現説明ではなく、防御側がセキュリティログやネットワーク記録で識別すべき運用痕跡である。

［表4］C2運用方式ごとの確認兆候と防御上の価値

攻撃者が好むのは、隠蔽しやすい環境で配信し、交換しやすいインフラで運用し、必要に応じて特定ASN・地域に中核制御を集める構造といえる。防御側はIoC遮断、共有インフラの精査、ASN・提供者の監視、SPKI・URI・ヘッダーによるハンティングを別々の業務とせず、1つのC2運用モデルの中でつなぐ必要がある。

4.5. 国より重要なインフラの役割

国別では米国が9,010件で最多、次いでドイツ2,577件、オランダ2,300件、中国1,995件、香港1,797件だった。ただし国別分布は攻撃者の帰属根拠ではなく、インフラの役割を分ける基準として解釈する。米国にはOther／Uncategorized 6,644件とCore C2 Framework 1,798件が同時に見られ、正規通信と悪性キャンペーンが混在する大規模共有クラウドに近い。中国と香港はCore C2 Frameworkの比率が54.84%、56.59%と高く、単なる通信量より中核制御の役割に注目すべきである。シンガポールも47.8%と高かった。

［図4］国別のインフラ役割の積み上げ分布

［図5］国別のインフラ役割の集中度

5. ライフサイクル：短命のIoCと長く残る痕跡

5.1. 短命のIoCと長く残るIoCを区別する

IoC全体の寿命の中央値は約0.35日、平均は約5.54日である。これだけでは大半が急速に使い捨てられるように見えるが、タグごとのMTTD（Mean Time To Death）に分けると様相は異なる。

［表5］主要タグのライフサイクルとDead比率

［図6］主要タグのMTTDと稼働状態の分布

ClearFake、ClickFix、StrelaStealer、QuasarRATは長期残存型に近く、Mozi、Kimwolf、Aisuru、Metasploitは短期消耗型、または検知直後に無力化される傾向が強い。一部のC2フレームワークでは、中央値が短くても例外的な長寿命個体が平均を大きく押し上げる。中央値だけでIoCを廃棄せず、SPKIやインフラのフィンガープリントが繰り返されるかを確認し、長期ハンティング対象として残すべきである。

5.2. 遮断を難しくする古いドメイン

作成時点に基づく19,032件の記録では、古いドメインに当たるAged（>1y）が13,550件で最多、Intermediateが3,144件、Fresh（0–1d）が2,338件だった。ユニークドメインは9,516件である。

［表6］ドメイン作成時点に基づく分布

［図7］ドメイン作成から悪性活動までの期間分布

まず注目すべきはFresh（0–1d）の多さではなく、Aged（>1y）が71.2%を占める点である。新規登録ドメインは初動の遮断やアラート優先付けに依然有効だが、このデータでは悪性活動は新規ドメインに限られなかった。19,032件中13,550件が作成から1年以上経過したドメインで、ユニーク数でも6,775件がAgedに属する。作成日だけでリスクを下げる方針は、ClearFakeやClickFixなどの大規模キャンペーンを見逃し得る。

上の分布では1日以下のFreshにも明確な棒があるが、重心は右側の古いドメインにある。10,000日を超える記録だけで8,660件、全体の45.5%を占める。攻撃者は必ずしも新規登録せず、長く維持された正規ドメイン、侵害されたWeb資産、古い親ドメイン配下のパスやサブドメインを悪用できる。この場合、レピュテーションや作成日だけでは悪性配信やリダイレクトを安定して識別できない。

タグ別分布も同じ結論を支える。ClearFakeは5,908のユニークドメインで経過期間の中央値が11,494日、記録の81.1%がAgedだった。ClickFixも1,029ドメイン、中央値1,153日、Aged比率69.3%となった。StrelaStealer、QuasarRAT、RemcosRATも右側に長い分布を示し、古いドメインの悪用が確認できる。一方、VidarやCobaltStrikeの一部は中間層に多く、作成時点はキャンペーンごとに解釈する必要がある。

この図が示すのは、古いドメインは安全という前提を捨てる必要性である。新規ドメインは迅速な遮断候補として扱いつつ、古いドメインも自動的に信頼せず、URI、Hostヘッダー、リダイレクト構造、タグ、証明書、提供者情報を併せて精査する。ClearFakeやClickFixのように正規Webリソース風のパスを使う場合、実際のリクエストパスとキャンペーンの痕跡がより重要な判断材料となる。

5.3. 稼働状態の変化が示す再出現の可能性

タグ展開後の活動記録では、[D]Unstable 32,054件、[E]Mixed 16,122件、[C]Heartbeat 12,560件、[A]AlwaysOn 12,145件、[B]OfficeWorker 613件が確認された。常時稼働型より、稼働と停止を繰り返す不安定型・混合型が多い。切り替えが多いタグはTofsee、WordPress、EtherHiding、Polygon、compromised、Vidar、ClickFixである。ClickFixは10,261記録で平均14.29回、中央値15.0回の切り替えを示した。単なるネットワーク障害より、侵害済みWebインフラや共有ホスティングで稼働状態が繰り返し変わる運用特性と解釈する方が自然である。

［図8］タグ別の稼働状態変化とライフサイクル

6. 検知回避と通信パターン

6.1. ポートの変更も運用痕跡となる

全体のポート再利用率は95.91%と高かったが、一部タグでは幅広い非標準ポートを切り替える傾向が明確だった。何番を使ったかだけでなく、どの程度頻繁に変更しながら運用したかが重要である。

［図9］タグ別のユニークポート数と非標準ポート比率

［表7］タグ別の非標準ポート使用状況

図は1:1の基準線を中心に読む。右側のタグは標準より非標準ポートを多く使用する。aisuruは96.00倍、tofseeは84.67倍、kimwolfは80.67倍で、metasploit、antidot、vshell、adaptixc2も非標準への依存が高い。80／443中心のWeb通信精査だけでは不十分で、ファイアウォール、Proxy、NDRで外向きの非標準ポート接続、プロトコル不一致、新規ASN・ポートの組み合わせを併せて見る必要がある。

［図10］タグ別のユニークポート使用比率

この図は非標準ポート比率とユニークポート数を併せて示す。右上のmozi、vshell、metasploit、adaptixc2は比率もポートの幅も大きい。moziは標準ポートの記録がなく前の倍率図では算出しにくいが、散布図では536件すべてが非標準ポートで、ユニーク数は517である。特定ポート1つの遮断より、タグ、ASN、プロトコル、接続方向、反復するポート生成パターンを併せて見るべきである。

cobaltstrike、remcosrat、asyncrat、quasarratは別の読み方が必要である。非標準比率はvshellやmetasploitより低いが、ユニーク非標準ポート数は多い。cobaltstrikeは4,240件中1,737件が非標準で、ユニーク非標準ポートは228。remcosratも771件、377ポートだった。非標準を主経路とする型より、標準と非標準を併用してインフラを広く分散させるC2・フレームワーク系と捉える方が自然である。

大量観測されたclearfake、clickfix、strelastealer、vidarは散布図下部に集中する。80／443などの標準Webポートに強く依存し、非標準比率は低いため、ポート中心では検知の識別力が弱い。前節の古いドメイン、正規リソース風URI、Hostヘッダー、証明書、リダイレクト構造がより重要なハンティング軸となる。

ポート分析の結論は、タグごとに対応基準が異なるということである。非標準優位型はファイアウォール、Proxy、NDRログで優先確認し、許可方針にない外部宛先・ポートを遮断やアラート候補にする。広範なポートを使うC2・フレームワーク系ではASN＋ポート、SPKI、プロトコル特性を長期指標として残す。標準ポートでの配信は、Webリクエスト構造とインフラの文脈で絞り込む。

6.2. URIパターンが示すキャンペーンの特徴

URIのランダム性はGlassworm、CalendarC2、MaskgramStealer、ClearFake、AmadeyBot、FakeAdobe、Stealc、FakeZoomなどで高かった。Glasswormは平均エントロピー4.511、中央値4.634と最高で、ランダム性の高いパスによる静的シグネチャ回避の傾向が強い。一方、Moziは平均1.004、Formbookは2.253、一部C2フレームワークは2点台後半と低い。低エントロピーでも、正規リソース風の短く単純なURIを反復してヒューリスティック検知を回避できる。主要な反復URIを以下に示す。

［表8］主要な反復URIとキャンペーンタグ

［図11］URIエントロピーに基づくキャンペーン別パスパターン

7. 持続性：変化するIoCの間に残るつながり

7.1. 分散したキャンペーンを再び結ぶSPKI

脅威インテリジェンスの主要な目的の1つは、単一指標の一律遮断を超え、一見無関係なインフラをメタデータで関連付けて群集化し、先回りした防御体制を築くことである。本事例では、2026年第1四半期に収集した脅威インフラで最大の群を形成した、CobaltStrike関連の単一証明書公開鍵ハッシュ（SPKI: 6691ce9450b4eb3d35709bbefaa63e3819c8940e8a7db70e796070e3d5cb5c93）クラスターを分析対象に選んだ。最初の84指標を基に、ポートとプロトコルの分岐を反映した最終データセットを構成し、拡張分

［表9］主要SPKIクラスターと分散の特徴

規模の大きいクラスターと分散度の高いクラスターを区別することが重要である。単一提供者に集中した群はサブネット・提供者単位の対応が可能な場合があるが、複数ASN・国に分散したキャンペーンはIP遮断だけでは対応しにくい。SPKI、ASNの移動、ポート、稼働状態を併せたハンティング指標として運用する。

［図12］SPKIベースのキャンペーンクラスター分布

7.2. 長く残る特徴値から始める戦略的ハンティング

別添には戦略的ハンティングシグネチャが128件あり、SPKIが115件、ASN＋ポートが13件である。優先度はmedium 73件、high 46件、critical 9件。criticalで特に注目されるSPKIは「6691ce9450b4eb3d35709bbefaa63 e3819c8940e8a7db70e796070e3d 5cb5c93」で、101のユニークIP、111回の使用、105.1日の継続が確認され、主なASNはRailnet LLC、AROSS-AS、Biil Ru Ltdだった。また「9ef15a1ce89f8df6b8fed558a36547e5205501e6b21fe 5b00790e4716a3bd248」はKimsuky／Xworm／Remcosタグとともに22のIP、31回、97.1日を示し、criticalに分類された。

IPやドメインは速く変わるが、SPKIや配備のフィンガープリントは反復する。そのため、戦略的ハンティング一覧は遮断リストより長く運用し、TLS検査やCTIプラットフォームで再利用されるフィンガープリントとして管理すべきである。

8. Analyst’s Pick：北朝鮮関連の攻撃者による開発者向けJavaScript C2運用

8.1. 事例概要と選定理由

Analyst’s Pickのクラスター2046は、北朝鮮関連の攻撃者による開発者向けJavaScript C2運用事例である。IoC件数が最大のキャンペーンではないが、分析価値は高い。データの参考根拠が実際のJavaScriptサンプルにつながり、静的復元で難読化文字列、Node.js実行構造、C2制御、アップロード・外部送信まで関連付けられるためである。

［表10］クラスター2046の構造指標

重要なのは単一のサーバーアドレスではない。開発者の端末、GitHub／NPM／VSCode／Git hook、Vercelの設定配信、ターミナル・API接続候補、Socket.IO／WebSocket制御、アップロード・外部送信が1つの攻撃フローになる。単一IoCの遮断だけでは不十分で、ファイル痕跡、C2通信規約、ヘッダー・項目の組み合わせ、Proxy／SIEMでの過去ログ調査を併せて設計する必要がある。

本事例は北朝鮮C2サーバーの一覧ではなく、北朝鮮関連の開発者向け作戦が正規の業務フローをどう悪用し、C2バックエンドとアップロード・外部送信経路につなぐかを示すものとして扱うべきである。

8.2. 役割別のインフラ構成

単なるIoCの集合ではなく、役割別のインフラとして見る必要がある。

［表11］クラスター2046の役割別インフラ構成

［図13］北朝鮮関連の開発者向けJavaScript C2の役割モデル

図は開発者の実行フローにおけるVercel設定配信、lab99のターミナル・API候補、ROUTERHOSTINGのバックエンド候補、サンプル確認済みの制御・アップロードチャネルの役割分担を示す。特に下部の証拠の境界が重要である。「216.126.225.243:8087」と「8085/8086」はサンプルから役割を確認できたが、Vercelやlab99の応答がそのバックエンドを直接渡すという関連性は、追加検証が必要である。

8.3. サンプルの実行構造と通信構造

マルウェア解析上の強みは、インフラのグラフだけで終わらない点にある。最優先のpivotサンプルは難読化JavaScriptであり、解析によって実行構造と通信構造を分けて確認できた。

［表12］JavaScriptサンプルの静的解析での観測点

この構造は単純なスクリプト型ダウンローダーより運用面で一段進んでいる。開発ツールチェーン内で被害者の実行を誘導し、サンプルはNode.jsで第2段ペイロードを分離実行した後、制御とアップロード・外部送信を別チャネルで行う。そのため本節は、インフラ分析であると同時に静的マルウェア解析の結果として読むべきである。

8.4. C2通信規約とチャネル分離

最大の発見は、216.126.225.243:8087が単なる関連IoCではなく、実際のC2制御チャネルと確認されたことである。ただしサンプルに直接ハードコードされているのはWebSocket形式ではなくhttp://216.126.225.243:8087で、実行フローでSocket.IO／WebSocket通信に変換または利用する構造となっている。

［表13］C2通信要素とチャネル分離

この構造はコマンド制御とアップロード・外部送信の分離を示す。単一IoCの遮断より、upload、validation、ホストメタデータ、Socket.IO／WebSocketへの移行、Node.js依存関係を組み合わせたハンティング条件が有効である。

8.5. 証拠の範囲と解釈の限界

確認済みの証拠と候補インフラを別の範疇として解釈することが重要である。

# 確認済み

- 難読化JavaScriptの静的復元で、C2関連の平文文字列と実行構造を確認

- Node.jsベースで、第1段ローダーと第2段の収集・制御スクリプトを分離

- ‘http://216.126.225.243:8087’ ハードコードされたC2制御チャネル

- 実行フローで「ws://216.126.225.243:8087」形式のSocket.IO／WebSocket制御チャネルを使用

- ‘http://216.126.225.243:8085/upload’, ‘http://216.126.225.243:8086/upload’

- validationヘッダー、ホスト識別項目、Node.js依存関係の組み合わせ

- ブラウザー認証情報、ウォレット、.env、.ssh、APIトークン、秘密鍵の収集ロジック

# 候補インフラ

- lab99.sbs /api/terminal/*：分析データ上のターミナル・API接続区間候補

- brezo.live、admin.brezo.live：同じ分析集合で確認されたサーバー側・管理拠点の候補

- Vercel設定配信と216.126.225.243のC2バックエンド間の直接的な応答フローの関連性

# 未確認

- lab99.sbsの応答が実際に216.126.225.243のC2バックエンドを渡す直接証拠

- Vercel設定配信エンドポイントと216.126.225.243のC2バックエンドのコード上の直接的な関連性

- 時間帯に基づく攻撃者の帰属

8.6. ファイル・ネットワークハンティングルールの適用例

このAnalyst’s Pickは分析だけで終わらせず、実際のハンティング条件に落とし込む価値が高い。ルールは2系統に分けるとよい。1つは静的ファイルやアーティファクト保存先で類似JavaScriptを探すYARAルール、もう1つはProxy／IDS／NDRでC2通信規約を見つけるネットワークパケットルールである。運用優先度は次のとおり。

［表14］ハンティングルールの運用優先順位

以下のファイルルールは2種類に分かれる。1つ目は確認済みバックエンドとアップロードパスを含むため精度が高く、2つ目はアドレスが変更された変種を探す動作ベースのルールである。ただし、平文文字列が残るファイル、静的解析の成果物、復号・文字列復元結果の保存先に適しており、文字列未復元の元の難読化ファイルでは検知漏れの可能性がある。

ネットワークパケットルールはSuricata 6／7系の構文で作成した。Snort 2.xや一部商用IDS／IPSではHTTP buffer keywordが異なる可能性があるため、運用前に製品ごとのパーサーで検証する。直接バックエンドのルールは高精度だが短命になり得る一方、「/upload」と「validation」の組み合わせはサーバー変更後も残る長期ハンティング条件となる。

M365 DefenderまたはSentinelでは、以下のクエリで直接バックエンド接続の有無を先に確認することもできる。

運用では「216.126.225.243」ベースのルールを即時遮断とハンティングに使い、/upload、validation、ukey／username／timestamp、Socket.IO／WebSocketへの移行条件を長期候補として残すのが適切である。Vercel、lab99、brezoはサンプル確認済みのC2バックエンドではなく、遮断より精査・関連性確認の軸として管理する。

9. 結論

前四半期は単一IoC遮断の限界を指摘し、攻撃インフラに残るメタデータを防御ロジックへ変換することに焦点を当てた。IP・ドメインが急速に変わっても、証明書、ポート、URI、活動時間帯、配備方法は交換・拡張の過程でも反復し得る。今回はその視点を引き継ぎ、同じ問いに少し異なる結果を示した。

2026年3月1日から6月15日までのデータで目立ったのは、特定ツールの優勢ではなく、正規サービスと共有インフラの利用方法だった。Cloudflareや主要クラウド・共有ホスティングではClearFake、ClickFix、Vidarが正規通信に混在し、Hetzner、Railnet、Hostinger、Namecheap系は配信と稼働中C2バックエンドへの対応対象となった。Alibaba、Tencent、Yancy系ASNでは特定ネットワークへのC2／フレームワークタグ集中も見られた。問われるのは一括遮断するインフラより、即時遮断、精査継続、長期ハンティング指標への転換をどう分けるかである。

単一IP・ドメインだけを見ると、Cloudflare上のキャンペーンは過剰遮断につながり、中国系クラウドASNのC2集中は国別統計に埋もれ、SPKIやASN＋ポートも使い捨てIoCの中に隠れてしまう。1つの一覧にまとめず、遮断、精査、戦術的ハンティング、戦略的ハンティングに分けて運用すべきである。

北朝鮮関連の開発者向けJavaScript C2は、この流れをサンプルレベルで裏付ける。価値は単一IPではなく、開発業務の信頼チェーンが設定配信、Git hook設定、Socket.IO／WebSocket制御、「/upload」の外部送信につながる構造にある。静的解析で確認したバックエンド（216.126. 225.243）、validationヘッダー、ukey、host、os、username、timestampは、個々のIoCより長く残り得るC2通信構造である。これにより、ファイル検知とネットワークパケット検知のルールに転用できる分析根拠となる。

本レポートは収集した手がかりを、防御側がすぐ判断・運用できる基準へ変えることを目指す。即時遮断対象を絞り、正規サービスと混在する対象は精査可能な条件で管理し、繰り返される証明書、ポート、URI、ヘッダー、ホスト項目、ASNの組み合わせを次の検知の指標として残す。第2四半期のデータは、共有インフラ悪用、提供者別の役割分化、役割分担型C2モデルを中心に基準を整理できることを示した。

10. 対応ガイド付録

本レポートは、多チャネル脅威テレメトリーの信頼度と防御手法の特性に応じ、5種類の別添データを提供する。各データセットは遮断・監視・ハンティング・戦略・予測という段階別プロセスに適しており、以下を基準に社内のセキュリティ機器やSIEMへ動的に適用することを推奨する。

［別添1］即時遮断リスト（Blocklist）

分析時点でC2通信が稼働（Alive）し、悪性の信頼度が非常に高いIoCだけを厳選した一覧である。Cloudflare、Akamaiなどの主要CDN・共有クラウド帯域を自動除外し、単発のIP遮断による正規サービス障害を防ぐ。担当者はIP・ドメインをF/WやIPSなどの遮断方針へ即時反映すべきである。その後、内部ネットワークとのIn／Outbound接続試行が確認された場合は端末感染を強く疑い、速やかに隔離とフォレンジックを行う。

［別添2］共有インフラ点検リスト（Review_Shared_Infra）

悪性動作を確認しても即時遮断で付随的被害が生じ得る対象や、追加のペイロード検証が必要な対象を含む。今四半期は発信元を隠すため悪用されたCloudflare（AS13335）とAmazon（AS16509）のプロキシノードが多い。IP単位で単純遮断せず、WAFやプロキシによるドメイン・URLパス単位の精密遮断を検討する優先対象として利用する。

［別添3］戦術的ハンティングリスト（Tactical_Hunting_Active_Campaign）

現在活発に拡散する最新キャンペーンのリアルタイム検知パターンとIoCを集め、四半期ごとの攻撃戦術の動向を反映している。SIEMの相関分析ルールへ組み込み、初期侵入をリアルタイムで阻止するとともに、過去3か月のファイアウォール・DNSログを対象に同じ通信の有無を全件調査する遡及的ハンティングにも利用する。

［別添4］戦略的ハンティングリスト（Strategic_Hunting_Signatures）

防御を避けるためIP・Domainを継続的に変更しても変わらない、攻撃者固有のインフラ指紋をまとめた一覧である。証明書公開鍵ハッシュ（SPKI）、特定ホスティングと非標準ポートの組み合わせ（ASN＋Port）などをシグネチャ化した。内外のCTIプラットフォームやSSL Inspection機器へ適用し、まだ表面化していない予備C2も先回りして発見し、一括で無力化する戦略的対応に活用する。

［別添5］インフラ移行追跡指標（Tactical to Strategic Promotions）

次の大規模作戦に向けて新設された、またはホスティング事業者間を移動中の予備攻撃拠点を追う長期Watchlistである。キャンペーンの大規模インフラ移行が代表例となる。単なる遮断対象を超え、次の攻撃の兆候を予測し、防御を先行して高度化するために観察すべき戦略的指標として管理する。

※ すべてのデータは抽出時点（2026.06.16）の稼働状態を反映している。特に［別添1］の有効期間は攻撃者のインフラ廃棄速度で変わり得るため、ファイアウォールの負荷を防ぐ定期的な有効性確認と動的削除を推奨する。

サイバー脅威は、いつでもどこでも発生し得ます。

サンズラボは、最新マルウェアの解析で得た脅威間の関連情報とIoCを継続的にレポートで共有し、サイバー脅威の予防と安全なサイバー社会の実現を目指しています。