Spurを検討する実務担当者に向けて、Doppelgangerと呼ばれるマルウェア調査を、感染機器の把握、検体収集、侵入経路の確認、動的解析、持続化の流れで整理します。
概要
ネットワークにつながる機器を業務で使う場合、感染の有無をどう把握し、得られた検体をどう調べるかが実務上の入口になります。本記事では、Spurを検討する担当者が脅威調査の観点を確認できるよう、Doppelgangerというマルウェアについて、サンドボックスで詳しく調べた流れを整理します。Doppelgangerは、過去数年の活動から改称したものとされています。付随する作業は、感染を再現できる環境を用意し、検体を集め、挙動を追う順序で進みます。今回は個別の攻撃手順だけでなく、どのように調査対象を絞り、解析へつなげたかを中心に見ていきます。保障されていない外部機器を扱う担当者にとって、観測、収集、確認の流れを分けて読むことが重要です。これは製品評価の前段で、どの情報を見れば判断しやすいかを整理するための読み方です。
背景として、Facelessと呼ばれるマルウェア集団が、3月初めにDoppelgangerへ改称して再び現れたことがLumenの初期報告で示されています。この集団は、侵害されたIPアドレスおよびエッジ機器を、暗号資産だけで顧客へ販売していたとされています。Lumenの報告では当時の数は約14,000とされており、対象が少数の単一機器に閉じない問題として扱われていました。こうした数の情報は、感染範囲を正確に断定するためというより、調査を始める際の規模感を把握する手掛かりになります。業務環境で外部公開機器を管理する立場では、脅威名だけでなく、売買される侵害済み機器という観点も確認対象になります。ここから、実際にどの機器が狙われ、どう観測したのかという話題へ進みます。
目次
主なポイント
主なポイントは、報告済みの数だけを見て終わらせず、現在の広告状況や独自調査の見え方を合わせて確認している点です。示された数はその後いくらか下がったものの、現在広告されているIPアドレスは約11,000前後で推移しているようだと説明されています。一方で、独自調査ではその数がかなり多い可能性も示されました。数が動くという前提で見ると、単発の報告だけではなく、観測を続ける設計が必要になります。実務担当者にとっては、脅威情報を固定値として読むのではなく、時間とともに変わる対象として扱う姿勢が読み取りどころです。ここでの焦点は、製品名や攻撃名そのものより、追跡対象を継続的に確認する考え方にあります。営業や運用の判断では、この変動を前提に調査の粒度を決める必要があります。
対象機器については、主にルーターが狙われ、特にASUS製品群が挙げられています。調査では、QNAP、Seagate、一部のSynologyのNAS、つまりネットワーク接続ストレージ機器、さらにDigital WatchdogのCCTV、つまり監視カメラ系システムも対象に含まれることが確認されています。この広がりを受け、感染機器を識別して追跡する方法が調査上の問いになりました。その出発点として、マルウェア検体を得るために小規模なルーターハニーポット実験環境が組まれています。ハニーポットは、攻撃や感染の動きを観測するために用意するおとり環境です。対象の種類を押さえたうえで観測環境を置くことで、以後のログ収集や検体取得へ進む準備が整えられました。機器種別を広く見ることが、調査範囲を決める基礎になっています。
検体収集で起きた選別と再試行
観測環境を作っただけでは、目的の検体がすぐに得られるとは限りません。稼働するハニーポットを用意し、必要なログ取得とパケット取得を設定した後、実際に機器へ感染が届き始めました。ただし、最初に遭遇したものはMiraiでした。Miraiは別のボットネットに属する古いマルウェアファミリーで、10年にわたり断続的に存在してきたものと説明されています。ここで重要なのは、感染を観測できたことと、目的のDoppelganger系検体とは異なるものが混じることを分けて扱っている点です。ログと通信内容を取れる状態にしておくことで、得られた感染が調査対象に合っているかを確認できます。実務でも、検出された事象をすぐ目的の脅威へ結び付けず、系統を見分ける作業が次の工程になります。観測結果の選別が、解析前の品質を左右します。
その後、何度もクリーンアップと再試行を重ね、DoppelgangerファミリーのKadNap検体を得ることができました。取得した検体は、そこで終わりではなく、バイナリやスクリプトを配布している感染サーバーへたどる材料にもなりました。その追跡により、初期報告で示されたよりも多くのものを見つけたとされています。検体収集は単なる入手作業ではなく、配布元や関連するファイル群を広げて確認する入口です。調査の流れとしては、ハニーポットで感染を受け、不要な検体を取り除き、目的の検体を確保し、そこから配布経路へ戻るという段階が見えます。この順序を押さえると、感染の有無だけでなく、攻撃基盤の理解へ調査をつなげられます。収集と追跡が同じ流れの中で扱われている点が特徴です。業務で外部機器を監視する際にも、検出後の確認先を考える手掛かりになります。
サンドボックス解析へ進む前の侵入経路確認
感染サーバーや配布物を確認した後、調査はそれらをサンドボックスで試す段階へ進みました。サンドボックスは、対象プログラムの挙動を隔離された環境で確認するための分析環境です。前段で得た検体や関連ファイルをそのまま断片的に眺めるのではなく、実行時の動きを確認するための場所へ移すことで、静的に見える内容と実際の振る舞いをつなげやすくなります。この段階に入る前に、どのように侵入しているのかという問いも置かれています。つまり、解析対象を実行するだけでなく、最初の足掛かりを確認する流れが並行して考えられていました。調査の順番は、収集、配布元の確認、隔離環境での挙動確認、侵入経路の確認へとつながります。実務担当者は、どの工程で何を確認するのかを切り分けて読むと理解しやすくなります。
侵入の足掛かりとして、確実に把握している悪用手法は2つとされています。そのうち1つについては、CVEという脆弱性識別子を暫定的に割り当てたと説明されています。CVEは脆弱性を識別するための番号として扱われる名称ですが、ここでは確定情報として断定するのではなく、暫定的な位置付けで示されています。数が2つに絞られていることは、調査で確認済みの範囲を明確にするうえで重要です。見えている悪用手法の一覧を広げ過ぎず、確認できたものに限定して扱うことで、以後の説明はASUS製ルーターへの侵入手順など具体的な流れへ移ります。未知の可能性を勝手に足さず、把握済みの手法に基づいて解析を続ける姿勢が読み取れます。導入判断の場面でも、確認済みの範囲と未確定の表現を分けることが必要です。
ASUS製ルーターとSeagate機器で見えた入口
ASUS製ルーターへのアクセスに使われた手順では、まず独自のウェブ要求方式であるset root certificateが使われ、SHまたはBashスクリプト内容を含むダミー証明書ファイルがアップロードされました。続いて、apply app要求が送られ、RC serviceヘッダーにコマンドインジェクションが含まれていました。コマンドインジェクションは、想定外の命令を実行させる形の不正な入力として理解できます。この説明は、単に脆弱性名を挙げるのではなく、ファイルの投入と要求送信が連続する流れとして示されています。実務で読む際は、どの通信やファイル操作が前段になり、どの要求が実行につながるのかを追うと、後続の持続化処理も理解しやすくなります。ここでは1つの手順を過度に一般化せず、ASUS製ルーターで確認された流れとして扱うことが大切です。
この確認により、ASUS製ルーターへどのように入り込むかは把握できたとされています。さらに、Seagate機器についても調査が進められ、感染しているものがかなり見えていたため掘り下げた結果、AccentaファームウェアのXML外部実体に関する欠陥が悪用されていることが確認されました。XMLはデータを構造化して扱う形式として言及されていますが、ここでは正式な技術解説ではなく、欠陥の種類を示す手掛かりです。複数ベンダーや複数機器が関わる場合、1つの侵入経路だけで全体を説明するのではなく、機器ごとの入口を分けて確認する必要があります。この段階では、ASUS製ルーターの手順とSeagate機器側の欠陥が別々に扱われています。対象が広がるほど、機器ごとの観測結果を混同しないことが重要になります。
対象範囲を読むための確度と量の見方
Seagate機器側では、AccentaファームウェアのXML外部実体に関する欠陥が悪用されていることが確認されました。実際の悪用フローは詳述されていませんが、同じファミリー内の他の機器も影響を受けていると考えられる、という位置付けで示されています。あわせて、初期のKadNap検体は後に確保されています。ここでの読みどころは、詳細を出し切っていない部分と、実際に検体を得た部分が分けて示されている点です。技術調査では、確認済みの検体、推定を含む影響範囲、詳細を控えた手順が同じ文章内に並ぶことがあります。実務担当者は、それぞれの確度を同じものとして扱わず、確認された検体と影響が考えられる機器群を区別して読む必要があります。その切り分けが、次の対象調査や運用上の確認範囲を決める前提になります。
Facelessの過去の動きとして、Shodanに基づき、一定数を超える感染機器を得られる悪用手法に対して対価を払うと広告していたことも示されています。Shodanはインターネット上に見える機器を探すサービスとして知られますが、ここでは悪用可能な機器数を示す照会の文脈で触れられています。この情報は、単一の脆弱性だけではなく、見つけられる機器の量が攻撃側の関心になっていたことを示します。企業の実務では、個別機器の脆弱性だけでなく、外部から見える状態にある機器のまとまりを把握する視点が必要になります。過去の広告内容は現在のすべての動きを説明するものではありませんが、感染対象を探す発想を理解する補助になります。次の節では、この量に関する考え方が、複数ベンダー機器への広がりや回収されたバイナリの確認へつながります。
IoTボットネットの関心と回収バイナリ
悪用手法と検索条件によって、影響を受ける機器を10,000台示せる場合に対価が支払われる、という条件付きの説明もありました。この文脈から、FacelessはIoTボットネットのような領域に強い関心を持っていたとされています。IoTは、ネットワークにつながる機器群として理解できます。ここでのポイントは、攻撃側が単に個々の端末を狙うだけでなく、検索によってまとまった数を見つけられる機器群に注目していたことです。業務環境では、ルーターやストレージ、監視系機器などが部署ごとに分散している場合があります。根拠の範囲では具体的な社内事例は示されていませんが、調査の読み方としては、機器の台数や露出状況を別々に扱わず、攻撃側が数を意識する文脈で捉える必要があります。これは感染追跡だけでなく、監視対象を決める際の前提にもなります。
影響を受けた機器は、異なるベンダーや異なる機器ファミリーにまたがっていると説明されています。調査の結果、6個の別々のマルウェアバイナリが回収されました。また、リビジョン番号を伴う8ビットの命名パターンが使われていたため、総当たりで列挙しやすかったとも述べられています。ここで、バイナリの個数、命名パターン、対象機器の多様さがつながります。複数の実行ファイルが存在し、命名規則に手掛かりがある場合、検体の回収や一覧化は解析の前準備として意味を持ちます。実務担当者が読むべきなのは、バイナリを1つ入手して終わりにしない点です。複数のファミリーや機器にまたがる状況では、命名やリビジョンの規則を見ながら関連物を探す作業が、分析範囲を広げる入口になります。次に、その回収物がどの機器向けで、どのように実行時解析へ移されたかを見ます。
実行時解析で静的な発見と挙動を照合する
回収されたさまざまなバイナリの多くは、ARM向け機器を対象としていました。ARMは、薄型クライアント、エッジルーター、NASストレージ機器などに関係する機器側の実行環境として言及されています。このため、動的解析環境ではクラウド上のインスタンス、とくにARMベースのものを借り、リアルタイムで実行して分析できるようにしました。ここでの目的は、静的解析で得た発見を、実際の実行と挙動に対応付けることでした。静的解析はファイルの中身を読む作業、動的解析は実行時の振る舞いを見る作業として分けて理解できます。対象がARM向けであれば、実行環境もそれに合わせる必要があります。解析環境の選び方は、検体の種類と切り離せません。導入検討の場面でも、対象データや対象機器に合う環境で検証する考え方が重要になります。
動的解析では、Lumenの発見の一部も確認されています。具体的には、ランデブーの仕組み、制御サーバーへ到達するためのハッシュ計算、別々の制御経路、サーバーからのアプリケーションデータを待つ動き、ファイル配布ロジックに関する点です。調査を続ける中で、ファイル配布ロジックについては独自の結論にも至ったとされています。そのうえで、ASUS製機器がどのように侵害され、どのように持続化を確立するかの高レベルな確認へ進みました。ここでは、外部報告の確認と自分たちの解析結果を結び付けている点が重要です。別の報告にある内容をそのまま受け取るだけでなく、実行時の挙動と照合しながら、次に詳しく見るべき持続化の流れへ進んでいます。実務上も、既存情報と自社で得た観測を照らし合わせる工程が解析の精度を支えます。
配布サーバーから持続化処理までの流れ
ASUS製機器の侵害と持続化の流れでは、最初のペイロードから動くスクリプトが、現在3つある配布サーバーのうち1つから取得を行うと説明されています。この取得されるスクリプトの1つがAIC.SHです。ここでは、ペイロード、配布サーバー、スクリプトという順に処理がつながっています。実務担当者が理解するうえでは、最初に機器へ入る処理だけでなく、その後に外部から何を取得するかを追うことが大切です。配布サーバーが複数あるという事実は、取得元を単一の場所に限定して見ない読み方につながります。ただし、根拠にあるのは3つの配布サーバーのうち1つから取得するという説明であり、それ以上の推測は加えません。この段階の確認は、後続のスクリプトや機器別の処理を理解する入口になります。取得の順序を押さえることで、持続化処理の見通しが立ちます。
スクリプトは3つに分かれ、ANPとSTOというスクリプトも存在しますが、それぞれ別の機器ファミリーを対象としていました。ASUS製ルーターに固有の動きとしては、「.asusrouter」ファイルを作成し、このファイルは起動時に実行されます。また、他の設定や機器への変更を通じて、別のスケジュールされたイベントからも起動され得ると説明されています。この仕組みにより、再起動やその他の変更の後でも、攻撃側が機器へ戻るための持続的な経路が作られました。ここでいう持続化は、一度の実行で終わらず、機器状態の変化後にも再び動けるようにする処理です。運用担当者が読む場合、初回侵入だけでなく、起動時や設定変更時に動く処理へ注意を向ける必要があります。機器ファミリーごとの差分も、確認の優先順位を決める材料になります。
時刻同期が解析の最後に持つ意味
AICスクリプトの後続では、CADバイナリが8ビットのバイナリファイルの1つをCADとしてtempまたはJFFSに保存し、NTPクライアントバイナリのラッパーも作成しました。NTPは機器の時刻同期に関わる仕組みとして言及されています。このラッパーは機器の時刻を同期するもので、後の仕組みを理解するうえで重要な点だと説明されています。ここでは、ファイル保存、ラッパー作成、時刻同期が一続きの処理として示されています。持続化の確認では、単に不審なファイルがあるかだけでなく、既存の時刻同期処理に関わるバイナリがどのように扱われたかも見る必要があります。JFFSなどの名称は正式な説明なしに出てくるため、ここでは保存先として扱うにとどめます。調査では、保存場所と起動に関わる処理を結び付けて追うことが次の確認点になります。
時刻同期が重要とされるのは、この仕組み全体が、すべての機器の時刻が同期されていることにかなり依存していると説明されているためです。調査の流れを振り返ると、Doppelgangerの改称という背景から始まり、侵害済み機器の売買、対象機器の広がり、ハニーポットによる検体収集、侵入手法の確認、ARM環境での動的解析、配布サーバーと持続化、最後に時刻同期へと話題が進みました。実務担当者にとって、この流れは個別の技術名称を覚えるためだけのものではありません。感染を見つける工程、目的の検体を選別する工程、実行時挙動を確認する工程、持続化と時刻同期を確認する工程を分けて読むことで、外部接続機器をめぐる調査観点を整理できます。Spurを検討する際も、脅威情報を一つの結果として見るのではなく、観測から解析までのつながりとして捉えることが判断材料になります。