1. 定期観測レポート SOCレポート | Internet Infrastructure Review（IIR）Vol.62 | IIJの技術

目次

1. 定期観測レポート

SOCレポート

1.1 はじめに

IIJではセキュリティブランド「wizSafe（ウィズセーフ）」の立ち上げから一貫して、安全なインターネット利用環境の実現に向けた取り組みを進めています。その1つがwizSafe Security Signal^（注1）を通じたブログ形式での定期的なセキュリティに関する情報の発信です。その他にも、セキュリティ機器のログに加え、バックボーントラフィックを集約した情報分析基盤^（注2）を活用したISPならではのデータ分析により、日々高度化するサイバー攻撃に対抗すべく予防措置及び速やかな事後対処に注力しています。

本稿の1.2節では2023年のセキュリティインシデントを振り返り、特に注目した事案をセキュリティサマリとしてカレンダー形式で紹介します。続く1.3節ではデータ分析や情報分析基盤の運用で見えてきた課題の解決へ向けた直近の取り組みとして、「データ分析基盤の運用と分析における課題とdbtの導入」と「時間間隔のばらつきに着目したC&C通信の可視化」について取り上げます。その中で1.3.1節では、データの鮮度やデータマート作成・保守の課題に対応するためにdbtを導入した経緯を紹介し、1.3.2節では、時間間隔のばらつき評価に関する3つの課題に対処するため「移動変動係数」という統計量の適用を検討した結果を共有します。

1.2 2023年セキュリティサマリ

2023年に話題となった主要なセキュリティに関する出来事の中から、SOCが注目したものを表-1、表-2にまとめます。

表-1 インシデントカレンダー（1月～6月）

月	概要
1月	自治体は、公式Webサイトの閲覧障害が発生しており、Anonymousと名乗る集団からの妨害行為（DDoS攻撃）と見られることを明らかにした。なお、Twitter（現：X）ではAnonymousを名乗る者から攻撃を示唆する内容がへ投稿されている。
1月	Microsoft OneNote形式ファイルを添付した攻撃メールが増加していることをSOCで観測した。1月以降、複数のマルウェア感染活動でOneNote形式ファイルが利用されていることを確認している。
2月	VMware ESXi製品に存在するOpenSLPのヒープバッファオーバーフローの脆弱性（CVE-2021-21974）を悪用したランサムウェア攻撃キャンペーン（ESXiArgs）が行われていることが複数の組織から報告された。同時期にOpenSLPが使用する427番ポートに対するスキャン通信が増加していることをSOCでも確認している。
2月	暗号資産取引所は、従業員がソーシャルエンジニアリング攻撃を受けていたことを公表した。攻撃者は複数の従業員に対してスミッシング攻撃を行い、窃取することができた従業員の認証情報を用いて内部ネットワークへログイン試行したが多要素認証（MFA）によりブロックされた。また、攻撃者は該当の従業員に対してITスタッフを装った電話をかけて攻撃の継続を試みたが、組織内のCSIRTが介入したことで阻止することができたとのこと。
2月	ランサムウェア攻撃グループClopは、ファイル転送ツールのGoAnywhere MFTに存在するゼロデイの脆弱性を利用して130以上の組織からデータを盗み出したと主張していることが明らかとなった。当該の脆弱性にはCVE-2023-0669が割り当てられている。その後、日系企業を含む複数組織が被害を受けたことを公表している。
3月	一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）は、2022年11月以降確認されていなかったEmotetへの感染を狙うメール配布が確認されたことを注意喚起した。メールに添付されたZIP形式ファイルには展開後に500MBを超えるWord形式ファイルが含まれたケースがあり、セキュリティ製品の検知回避を目的とした手法であると見られる^（注-1）。
3月	ビジネスコミュニケーションソフトウェアを開発する海外企業は、提供するソフトウェアの正規インストーラから情報窃取型マルウェアに感染する恐れがあることを公表した。その後、侵害調査を行ったセキュリティベンダから、既にサプライチェーン攻撃を受けていたことが報告されており、ソフトウェア開発環境が侵害されていたことで別のサプライチェーン攻撃に繋がったことが明らかになっている。
3月	電気通信事業者は、業務委託先の企業から個人向けインターネットサービス及び映像配信サービスの顧客情報が流出したことを公表した。なお、流出の原因はマルウェア感染ではなく、業務委託先の企業で当該サービスの業務に従事していた元派遣社員が不正に情報を持ち出していたことを続報で明らかにしている。
3月	情報通信及びシステムインテグレーションを提供する企業は、提供する自治体の証明書交付サービスにおいて申請者とは異なる住民の証明書が発行される事象が発生したことを公表した。サービス提供を一時停止し対処を行ったが、後日、原因となったシステムのプログラムの改修において一部の自治体で修正プログラム未適用のままとなる不備があったため、点検及び速やかな修正プログラムの適用作業を行うものとしている。
4月	公共サービスの業務受託などを行うIT企業は、自治体の議会向けに提供するソリューションサービスで使用するサーバが不正アクセスを受けたことを公表した。この不正アクセスにより複数の自治体から議会のインターネット中継サービスを一時停止する報告が相次いだ。
5月	大手自動車メーカの事業戦略会社は、クラウド環境の誤設定により車両関連の情報やドライブレコーダで撮影された映像などを含む顧客情報が外部から閲覧可能となっていたことを公表した。その後、他のクラウド環境の調査を実施した結果、新たに顧客情報の一部が閲覧可能となっていたことを明らかにしている。
5月	Progress Software社は、ファイル転送サービスのMOVEit TransferのWebアプリケーションにSQLインジェクションの脆弱性（CVE-2023-34362）が存在し、既に悪用が確認されていることを公表した。同社は当初、少なくとも過去30日の間に侵害を受けていないか確認するよう案内していたが、その後、他のセキュリティ関連組織から30日よりも更に過去から活動していることが公表されている。
6月	Fortinet社は、製品が使用するFortiOS及びFortiProxyのSSL-VPN機能にヒープベースバッファオーバーフローの脆弱性（CVE-2023-27997）が存在し、限定的なケースにおいて悪用されていた可能性があることを公表した。また、攻撃グループVolt TyhpoonはFortinet社製品のゼロデイの脆弱性を初期アクセスに利用することが複数のセキュリティベンダから報告されているが、本脆弱性の使用は確認されていないことを明らかにしている。
6月	6月以降、旅行予約サイトを通じて予約した利用客に対してフィッシングサイトへ誘導するメッセージが送られる事案が相次いで公表された。原因は宿泊予約情報管理システムが不正アクセスされたことによるもので、一部の宿泊施設ではシステム管理を行う端末がマルウェアに感染していたことを明らかにしている。また、複数のセキュリティベンダからは、利用客を装った問い合わせなどのメールのやりとりで添付ファイルを開かせ情報窃取型マルウェアに感染させる手法を用いていたことが報告されている。

（注-1）マルウェアEmotetの感染再拡大に関する注意喚起（https://www.jpcert.or.jp/at/2022/at220006.html）。

表-2 インシデントカレンダー（7月～12月）

月	概要
7月	港湾輸送団体は、ランサムウェア感染によりターミナルシステムに障害が発生し復旧作業中であることを公表した。この障害発生後、当該団体宛に攻撃グループLockbitを名乗る脅迫文が届いていたことをメディアが報じている。なお、障害発生から約2日半と短い期間で順次業務が再開されている。
7月	Microsoft社は、攻撃グループStorm-0558がExchange Online及びOutlook.comへ不正アクセスし、政府機関を含む約25組織の電子メール及び組織に関連する個人アカウントへアクセスされていたことを公表した。不正アクセスは、Microsoftアカウント（MSA）署名鍵を使用して対象サービスへアクセス可能な偽造トークンを発行する手口であったことを明らかにしている。Microsoftアカウント（MSA）署名鍵の入手方法については、後日、具体的な証拠は無いものの可能性の高い手法についてレポートにて解説している。
8月	16shopと呼ばれるフィッシング作成キットを利用して、他人のクレジットカード情報を窃取し不正利用したインドネシア人の男性が逮捕されたことをメディアが報じた。また、本件は警察庁が国際刑事警察機構（ICPO）、インドネシア警察の他国とサイバー共同捜査で容疑者摘発に至った初のケースであるとのこと。
8月	国内で使用されているモバイル回線対応のIoTルータのログイン画面が改ざんされる事案が多発した。改ざんされたログイン画面には原発の処理水排出を抗議する内容が書かれていることをSOCで確認した。また、X上では改ざんに関与したと見られるアカウントから改ざんに使用した脆弱性を説明するポストが行われている。
9月	セキュリティ企業は、AI研究者がGitHubへオープンソースのAI学習モデルを公開する際に公開データを参照するトークンの設定に誤りがあり、研究者の端末のバックアップを含む38TBのデータを公開していたことを公表した。公開されたデータの中にはAI研究者が所属する企業のサービスで使用するパスワードや秘密鍵、従業員のメッセージなどが含まれていたことを明らかにしている。
9月	ドメインレジストラが運営するオークションサイトに送金・決済サービスで使用されていたドメインが出品されていることが明らかとなり、第三者が取得し悪用する可能性を懸念する声が相次いだ。一部メディアは、当該ドメインを所有していた企業への取材で社内管理の不手際によるものであったと報じている。
9月	脆弱性発見コミュニティのZero Day Initiativeは、メール転送エージェント（MTA）のEximにリモートからコード実行が可能となる脆弱性（CVE-2023-42115）があることを公表した。本脆弱性は前年6月にセキュリティ研究者から報告し、9月にゼロデイとして公開することを開発元へ勧告後、公表に至ったことを明らかにしている^（注-2）。
10月	Google社、Cloudﬂare社、Amazon Web Services社の3社は、HTTP/2プロトコルの脆弱性（CVE-2023-44487）を利用した大規模なDDoS攻撃を8月に観測していたことを公表した。この脆弱性は、1つのTCPコネクション内で複数のHTTPリクエスト及びレスポンスを同時並行処理するHTTP/2のストリームの特徴を悪用し、クライアント側からHEADERSフレームとRST_STREAMフレームを大量送信することでサーバのリソースを枯渇させることが可能となる。この脆弱性はHTTP/2 Rapid Resetと命名されている。
10月	Cisco Systems社は、Cisco IOS XEのWebUI機能に存在する脆弱性（CVE-2023-20198）を公表した。この脆弱性を利用することでユーザ認証せずに最高位特権レベルのアクセス権を取得し新たなローカルユーザを作成することが可能となる。この数日後、同様のWebUI機能にローカルユーザからroot権限でコマンド実行可能となる脆弱性（CVE-2023-20273）が追加で公表された。この2つの脆弱性を組み合わせた攻撃による被害が国内でも報告されており、本脆弱性に関連する通信をSOCでも確認している。
10月	コンタクトセンターを運営する企業は、コールセンタシステムの運用保守に従事する者が顧客情報を不正に持ち出し、第三者へ流出させていたことを公表した。流出は約10年継続していたと想定されている。原因として、運用保守を行う端末で顧客情報のダウンロード及び外部記憶媒体へ書き出すことが可能であり、それらの操作をタイムリーな検知や定期的なログなどのチェックから把握できなかったことを挙げている。
10月	ID管理及び認証サービスを提供する企業は、サポートケース管理システムが不正アクセスを受けていたことを公表した。公表当初、影響範囲は一部の顧客がアップロードしたファイルとしていたが、その後の続報で影響範囲が全ユーザに及んでいたことを明らかにしている。なお、原因については、不正アクセスに使用されたアカウントを調査したところ、同社が管理する端末で従業員が個人のGoogleアカウントへサインインし従業員の個人デバイスにアカウント情報が同期されていたことが判明し、従業員の個人デバイスが侵害されたことでアカウントが窃取された可能性を示唆している。
11月	オンラインストレージ構築用オープンソースソフトウェアのownCloudに、コンテナ環境における機密情報及び設定の漏えいの脆弱性（CVE-2023-49103）が存在することが公表された。なお、公表から数日後、本脆弱性を悪用されていることが複数の組織から報告されている。
11月	Akamai社のSIRTは、InfectedSlursと呼ばれるMiraiの亜種がDDoSボットネットを拡大する攻撃にゼロデイの脆弱性を利用していることを公表した。また、当該の脆弱性が存在する製品の1つは国内で販売されている情報コンセント対応型無線LANルータであることを続報で明らかにしており、工場出荷時にデフォルトで設定されている認証情報を悪用可能である点が問題であることを指摘している。なお、当該ボットネットによるDDoS攻撃が11月以降も継続して行われていることをIIJでも観測している。
12月	Microsoft社及びArkose Labs社は、不正なMicrosoftアカウントやCAPTCHA認証を回避するツールなどを販売しているグループStorm-1152が使用するインフラを差し押さえ、首謀者を特定して刑事告訴状を法執行機関へ提出したことを公表した。Storm-1152は約7億5,000万件もの不正なMicrosoftアカウントを販売していたことや、販売するツールの使用方法のチュートリアル動画や利用者をサポートするチャットサービスを提供していたことも明らかにしている。
12月	セキュリティコンサルティング会社のSEC Consultは、SMTP Smugglingと命名したSMTPの実装における脆弱性を公表した。本脆弱性は、SMTPプロトコルのデータ終端に用いられるシーケンスとは異なるシーケンスを使用した場合でも終端と認識するプロダクトが複数存在し、後続データに2通目のメールを加えることで送信ドメイン認証の1つであるSPFによる送信元の詐称チェックが行われずに配送が可能になるなどの問題を明らかにしている。

（注-2）Exim AUTH Out-Of-Bounds Write Remote Code Execution Vulnerability（https://www.zerodayinitiative.com/advisories/ZDI-23-1469/）。

1.3 セキュリティトピックス

本節では、IIJのSOCにおける課題解決への取り組みについて紹介します。

1.3.1 データ分析基盤の運用と分析における課題とdbtの導入

IIJでは、サイバーセキュリティにおける脅威への適切な予防措置や事後対処に活かすことを目的として「情報分析基盤」というデータ基盤を運用しています。取り組みの詳細については2018年3月30日発行の本レポートのVol.38（https://www.iij.ad.jp/dev/report/iir/038/01.html）の「SOCレポート」にも記載がありますので併せてご覧ください。情報分析基盤は、ソフトウェアのアップデートやデータソースの拡充などを繰り返しながら活用が続いています。ここでは、情報分析基盤の運用を通して見えてきた課題と、その解決に向けてdbt（data build tool）というOSSを導入した取り組みについて紹介します。

課題について述べる前に、前提となるデータ基盤の運用やアーキテクチャについて説明します。なお、この内容は情報分析基盤に限った話ではありません。まず、一般的にデータ基盤に関する業務には、次の2種類の職能を持ったメンバーが携わります。

データエンジニア
データアナリスト

より細分化して扱う場合もありますが、ここでは主に前者を「データ基盤を作るメンバー」、後者を「データ基盤を使うメンバー」という意味で使用します。情報分析基盤においても、それぞれのメンバーが開発を担うチームと分析を担うチームに分かれて、連携しながら業務を遂行しています。

また、データ基盤に蓄積するデータは次のような層構造で管理する考え方が現在の主流です。情報分析基盤も、これに相当する形でデータを管理しています（図-1）。

データレイク層
データウェアハウス層
データマート層

データレイク層では、データの生成元であるデータソースから収集または転送されてくるデータを、なるべくそのままの形で保存します。データウェアハウス層では、データレイク層のデータを分析しやすいように構造化データなどに変換します。データマート層では、データウェアハウス層のデータを特定の用途に特化した形で変換します。

データマート層については後述する課題とも関わってくるため、セキュリティというドメインで例を挙げておきます。仮にですが、あるデータ基盤においてIPS/IDSから収集したデータがデータウェアハウス層に取り込まれているとしましょう。このとき、特定のデータポイント（レコード）には脅威を検出したシグネチャや時刻に関する情報が含まれることにします。もし、このデータから日々の傾向を確認したくなった場合には、検出したシグネチャの種類と件数を日ごとに集計することが考えられます。その際、データアナリストがアドホックに集計するのではなく、あらかじめ集計しておいたものがデータマートに相当します。参照する頻度が高い重要な内容であれば、ダッシュボードなどを使って可視化することも考えられるでしょう。

続いては、情報分析基盤の運用と分析において見えてきた2つの課題について説明します。まず1つ目は、データの品質に関わる課題です。データアナリストが適切な分析をするためには、データ基盤のデータが健全な状態を維持し続ける必要があります。一方で、完全無欠のシステムはこの世に存在しないことから、情報分析基盤でも次のような事象が生じることがありました。

特定のデータの鮮度が低下する
特定のデータが想定外の状況に陥る

データの鮮度というのは、データが滞りなくタイムリーにデータ基盤へ取り込まれているかどうかを表す概念です。データの鮮度が低下しているというのは、データ基盤へのデータの取り込みが想定よりも遅れていたり、あるいは一時的に停止した状況を表します。データの鮮度が低下した状況では、データアナリストが適時性のある分析を実施できない恐れがあります^（注3）。

データが想定外の状況に陥るというのは、やや漠然とした表現ですが、データアナリストから見たときに「データがおかしい」と思える状況です。例えば、本来はユニークであるはずの値に重複が生じたり、あるいは想定していない値が含まれる状況はイメージしやすいでしょう^（注4）。このような状況を見過ごしてしまうと、分析した結果の信頼性に関わります。

続いて2つ目は、データマートの作成や保守に関する課題です。定型で繰り返し何度も実施するような業務においては特にデータマートの存在は欠かせません。何故なら、データマートの有無によって作業の効率が大きく変わるためです。

一方で、情報分析基盤においてはデータマートを作成する際に、個別の開発が生じやすいという課題がありました。個別の開発が生じると、開発から保守に至るまで少なくないリソースが費やされます。また、実際に利用できるようになるまでのリードタイムも長くかかる傾向にありました。

情報分析基盤では、これらの課題を解決するためにdbtというOSSを導入しました。dbtにはOSS版のdbt CoreとSaaS版のdbt Cloudがあります。情報分析基盤で導入したのは、前者のdbt Coreです。dbtはデータ基盤が備える基本的な機能を表したETL（Extract Transform Load）の中で、T（データの変換）に特化したツールです。SQLとYAMLの設定だけで、ほとんどの機能を利用できる点が特長として挙げられます^（注5）。この「SQLとYAMLの設定だけ」という点は、分析においてSQLを多用しやすいデータアナリストにとって特に扱いやすい長所です。

1つ目の「データの品質に関する課題」は、dbtを使ってデータをテストすることで解決します。自動化されたテストは、ソフトウェアエンジニアリングにおける優れたプラクティスの1つです。そして、その考え方はデータエンジニアリングにおいても有効です。

dbtにはデータをテストする機能が含まれており、テストについてもSQLとYAMLを使って記述できます。dbtにおけるテストの実体は、正常系において抽出されるレコードが0件になるSELECT文です。つまり、あるテストに対応するSELECT文で1件以上のレコードが抽出されるとテストが失敗したことになります。自分でゼロからSELECT文を書くことはもちろん、組み込みやサードパーティ製のプラグインが実装しているテスト用のマクロも利用できます。また、データの鮮度が低下する状況についても「source freshness」という機能で検知が可能です。

従来であれば、情報分析基盤のデータが何らかの想定外の状況に陥っていることは、データアナリストが分析する過程で気づくのが典型的でした。しかし、データアナリストは何らかの目的を持ってデータを分析しています。つまり、そのデータを今まさに必要としていることが多いわけです。そのため、判明した際には業務への影響が大きくなる傾向にありました。一方でdbtの導入後は、データの定義やデータアナリストの経験則を自動化されたテストに落とし込むことで、効率的な発見と対処が可能になりました。

2つ目の「データマートの作成や保守に関する課題」は、dbtを使ってSQLでデータを変換することで解決します。dbtでは、モデルと呼ばれるオブジェクトを、やはりSQLのSELECT文を使って定義できます。モデルに対応するSELECT文によって変換された結果は、ビューやテーブルといった形でアクセスできるようになります。また、モデルを定義する際にはJinja形式のテンプレート言語が利用できます。そのため、頻繁に記述する内容をマクロとしてまとめたり、純粋なSQLでは表現が難しい柔軟なループ処理や分岐処理も可能です。

情報分析基盤では、dbtの導入によって多くのケースにおいてSQLの記述だけでデータマートが作成できるようになりました。セキュリティのIoC（Indicator of Compromise）情報を高速に検索するためのデータマートを短期間で作成して、特定の業務が数十倍に効率化された例もあります。なお、SQLだけでは実現が難しい処理もあることから、個別の開発が全く不要になったわけではありません。一方で、以前よりもデータエンジニアとデータアナリストの分業が進めやすくなった側面があります。具体的には、SQLだけでは実現が難しい処理を、データエンジニアがSQLのユーザ定義関数（User Defined Function）として実装します。その上で、データアナリストが、そのユーザ定義関数を組み込んだSQLを使ってdbtでデータを変換する処理を記述します。この流れでは、それぞれの作業が既存の枠組みを踏襲していることから、以前に比べて必要なリソースの低減やリードタイムの短縮が見込めるようになりました。また、以前よりもデータマートを作成するまでの道筋が具体的になったことで、効率化や新たな分析に関するアイデア自体を出しやすくする効果もあったように感じています。

図-1 データ基盤のデータを層構造で管理するイメージ

1.3.2 時間間隔のばらつきに着目したC&C通信の可視化

マルウェアの中には、システムに感染するとインターネット上のC&C（Command and Control）サーバと通信して、攻撃者からの指示を受け取るものがあります。このときに生じる通信（以下、C&C通信）は、あらかじめマルウェアのプログラムによって基本的な振る舞いが定められています。そのため、例えば人間がブラウザなどのアプリケーションをアドホックに操作することで生じる通信に比べると、特定のパターンが現れやすい状況にあります。

特定のパターンを反映しやすい代表的な特徴の1つが、通信の時間間隔です。典型的な例としては、死活監視で用いられるハートビートのような、一定の時間間隔でポーリングする通信をイメージすると分かりやすいでしょう。そのような通信は、生じる時間間隔のばらつきが小さくなる傾向にあります。そこで、今回はセキュリティアナリストが効率的にC&C通信のパターンを捉えられるように、時間間隔のばらつきに着目した統計量を用いて通信の可視化を試みました。

ただし、マルウェアでない正規のアプリケーションであっても、時間間隔のばらつきが小さい通信を生じうる点には留意が必要です。実環境において時間間隔のばらつきが小さな通信を見つけたとしても、その多くは正規のアプリケーションに由来すると考えた方が良いでしょう。そのため本手法は、侵害事象が生じた際にアナリストが視覚的に状況を把握するのを助けることを応用先に想定しています。

まずは、課題とその解決に使えそうな道具について整理しておきましょう。C&C通信は、時間の経過と共に発生するイベント（事象）と捉えることができます。個々のイベントは、典型的には以下の組み合わせで識別される特定のセッション^（注6）に属します。送信元がマルウェアに感染したシステムで、送信先が攻撃者の用意したC&Cサーバです。なお、送信元ポート番号をセッションの識別に含めないのは、エフェメラルポートで接続ごとに変わる可能性が考えられるためです。

送信元IPアドレス
送信先IPアドレス
トランスポート層のプロトコル
送信先ポート番号

次に、記述統計において数値のばらつきを定量的に扱うための代表的な統計量には、「分散」や、それを元にした「標準偏差」があります。ですが、あるセッションに含まれるすべてのイベントを使って、分散や標準偏差で通信の時間間隔のばらつきを評価することにはいくつかの課題があります。

a. 異なるセッション同士で値を比較することが難しい

例えば、次のような状況を考えてみましょう。あるセッションAにおいて、イベントの生じる平均的な時間間隔が100秒で、ばらつきを表す標準偏差が10秒だったとします。一方で、セッションBにおいては、イベントの生じる平均的な時間間隔が1000秒で、ばらつきを表す標準偏差が50秒だったとします。標準偏差という統計量の絶対値だけで比べると、セッションAの方がセッションBよりも小さくなります。しかし、平均に対するばらつきの大きさで考えた場合には、セッションBの方がセッションAよりも小さいと言えます。このように、分散や標準偏差だけでは、異なるセッションを比較するには不十分であることが分かります。

b. 外れ値の影響を大きく受ける

例えばマルウェアに感染したのが企業の業務で利用されているパソコンであれば、平日の日中帯にしか電源が入っていないかもしれません。端末の電源が入っていなければ、もちろんC&C通信は生じません。仮に端末の電源が入っていない時間帯まで計算に含めると、そのタイミングは外れ値のようにイベントの時間間隔が大きくなります。結果として、集計した分散や標準偏差は、本来の想定よりも大きくなることでしょう。

c. イベントの生じる時間間隔が途中で変わる恐れがある

マルウェアによっては、攻撃者が活発に指示を与えるタイミングで、イベントの生じる時間間隔を短くするものがあります。マルウェアの多くは自発的にC&Cサーバへ指示を受け取りに行く^（注7）ことから、ポーリングの間隔が長いと動作の反映までに時間を要するためと考えられます。そのような、長短の時間間隔が混ざり合った状況は、単一の分散や標準偏差といった統計量では表現が難しいと言えます。

そこで、上記のような課題に対処するため「移動変動係数」という統計量の利用を検討しました。移動変動係数は、一般的な統計量である「変動係数」に「移動」の考え方を導入したものです。通信間隔から求めた移動変動係数が小さいほど、ばらつきの小さな規則正しい通信と言えます。

まず、「変動係数」は標準偏差を平均で割った統計量です。課題aで述べたとおり、標準偏差だけでは平均の大きさに対するばらつきの大小が判断できません。そこで、標準偏差を平均で割ることで無次元化します。これによって、異なるセッションのばらつき同士を比較できるようになります。

次に、「移動」は局所的なデータを用いて統計量を計算する概念です。主に時系列など連続するデータにおいて、一定数のデータポイントだけを使って統計量を計算します。このとき、計算に用いる一定数のデータポイントの範囲はウィンドウと呼びます。移動では、ウィンドウをずらしながらデータのすべての範囲について統計量を求めます。

つまり、「移動変動係数」は変動係数を移動で求めた統計量です。移動変動係数は、移動標準偏差を移動平均で割って求めます。これにより、課題bやcの影響を低減できます。課題bについては、外れ値の影響を受けるのが、そのイベントを含むウィンドウの範囲だけに限定されます。また、課題cについては、イベントの生じる時間間隔が途中で変わったとしても、時系列での統計量の変化として捉えられることが期待できます。

ここからは、実際に過去の感染事例においてマルウェアが生じたC&C通信を移動変動係数で可視化した様子を紹介します。まず1つ目の事例では、マルウェアが複数のC&Cサーバと同時に通信する様子です。近年のマルウェアは、この事例のように複数のC&Cサーバと同時に通信を試みるケースが多くあります。

図-3の折れ線グラフは、横軸に基準となる時刻からの経過時間を、縦軸に移動変動係数をプロットしています。それぞれの折れ線はセッションを表しており、すべてC&Cサーバへの通信です。このケースでは、それぞれのセッションは送信元IPアドレスとトランスポート層のプロトコルが同一で、送信先IPアドレスとポート番号が異なっていました。見やすさのために、送信先IPアドレスのAS番号ごとにグラフを複数のパネルに分割しています。また、移動変動係数を求める際のウィンドウサイズには10点を用いました。

図-3のグラフでは、各パネルに移動変動係数が2前後で推移する特徴的なノコギリ状の折れ線が確認できます。それぞれのノコギリができるタイミングは、少しずつずれていますが近い場所にあります。これは、異なるC&Cサーバであっても、それぞれへ通信を試みるタイミングは類似していたことを意味します。

続いて2つ目の事例では、マルウェアが通信中のC&Cサーバが途中で使えなくなった際に、別のC&Cサーバへフォールバックする様子を示します。このマルウェアは同時に1つのC&Cサーバとしか通信しませんが、利用中のC&Cサーバとの疎通が失われて一定時間が経過すると、別のC&Cサーバに通信先を切り替える機能を有していると考えられます。

図-5の折れ線グラフは、先ほどと同様に横軸が基準となる時刻からの経過時間、縦軸が移動変動係数になっています。それぞれの折れ線がセッションを表している点も同様です。移動変動係数を求める際のウィンドウサイズも先ほどと同じ10点を用いました。ただし、経過時間の単位が先ほどのグラフでは「秒」でしたが、こちらでは「分」になっています。

グラフには2つのセッションが含まれており、いずれも移動変動係数がゼロ付近で安定している時間帯が確認できます。これは言い換えると、通信間隔のばらつきが極めて小さい、規則正しい通信をしている時間帯があるということです。実際には、同時間帯においてマルウェアはおおむね317から320秒程度の間隔でC&Cサーバとの通信を繰り返していました。

また、オレンジ色のセッションについては200分前後から移動変動係数が増加した^（注8）後に折れ線が途絶えています。そして、そこから少し経過したタイミングで紫色の折れ線が現れます。これが、マルウェアが通信先のC&Cサーバをフォールバックする様子です。オレンジ色のセッションについては、折れ線が途絶える約1時間前からC&Cサーバとの通信に失敗していました。そのため、マルウェアが通信先として使用するC&Cサーバを切り替えたものと見られます。

なお、ここで紹介した内容は代表的な例であり、マルウェアの通信には様々なパターンが存在しています。例えば、通信先のC&Cサーバごとに通信の間隔を変えたり、一定のランダム性を持たせたマルウェアも珍しくありません。これらは、通信の時間間隔のばらつきに由来する検知を避けるためと考えられます。そのような場合でも、移動変動係数ではグラフの形状に類似が見られたり、特定の範囲で値が推移する様子として観察できる事例を確認しています。

ここでは、時間間隔のばらつきに着目した統計量を用いて通信を可視化する試みについて紹介しました。IIJのSOCでは、今後もデータを活用したセキュリティの分析を効率的に進める手法を検討していきます。

図-2 マルウェアが複数のC&Cサーバへ同時に通信を試みるイメージ

図-3 特徴的なノコギリ状の折れ線を含んだマルウェアからC&Cサーバへの通信

図-4 マルウェアが通信先のC&Cサーバをフォールバックするイメージ

図-5 マルウェアが通信先のC&Cサーバをフォールバックした通信

1.4 おわりに

本稿では、2023年に観測した事案の中から、SOCの観測で着目したものをいくつかピックアップして紹介しました。1.2節の年間サマリでは、引き続きソフトウェアにおける脆弱性の発覚やランサムウェア攻撃、設定ミス・外部からの攻撃による情報漏えいが発生していることが分かります。1.3.1節では、dbtを利用した自動化されたテストや個別開発が不要なSQLを用いたデータ変換により、データの鮮度・品質やデータマートの作成・保守に関する課題を解決した経緯を説明しました。また1.3.2節では、「分散」やそれを元にした「標準偏差」を用いて時間間隔のばらつきを評価する際に顕在化した、異なるセッションの比較や外れ値の影響、時間間隔の変化といった問題への対処法として「移動変動係数」を導入した流れと実際のケースを例示しました。

引き続きIIJでは、刻一刻と変化する脅威に対応するための情報発信を続けていきます。今後もIIRやwizSafe Security Signalで発信する情報を注視いただき、セキュリティ対策や業務に役立てていただければ幸いです。

（注1）wizSafe Security Signal（https://wizsafe.iij.ad.jp/）。
（注2）Internet Infrastructure Review（IIR）Vol.38（https://www.iij.ad.jp/dev/report/iir/038/01.html）。
（注3）鮮度の低下がどこまで許容できるかは、データアナリストが実施する業務の性質に依存します。
（注4）実際に生じる状況は、データの定義から自明な異常もあれば、要約統計量などを通して見たときにデータの分布が変化するといった発見の難しいケースまで様々です。
（注5）データベース間の差異（SQLの方言など）については、データベースごとに用意されたアダプタで吸収します。
（注6）あるノード間での一連のやり取りを便宜的に呼んでいるものでTCPのセッションとは異なります。
（注7）インターネット上のC&Cサーバ側を起点にするとNATやファイアウォールに阻まれる可能性が高いためと考えられます。
（注8）移動変動係数の増加は、前述の課題cで示したように途中で通信間隔の規則正しさが崩れたことを意味します。