N-able、N-centralの攻撃者が管理対象エンドポイントに到達したことを確認

2026年7月31日、N-ableのAdluminマネージド検出・対応サービスは、顧客環境内で異常な活動を検知し、ベンダーがまだ公表していなかったN-centralの脆弱性を悪用している脅威アクターを発見した。N-centralは、マネージドサービスプロバイダー（MSP）が顧客のシステムを管理するために使用するリモート監視・管理（RMM）プラットフォームであるため、侵入者が掌握していたのは1台のマシンではなく、多数の顧客システムの前面に位置するコンソールだった。この脆弱性は後にCVE-2026-18577として登録され、認証なしでのリモート管理アクセスを可能にしていた。攻撃者はその後、N-central自体のTake Control機能を使って管理対象エンドポイントにセッションを開き、それらのデバイスにCloudflareトンネルサービスを登録した。これにより、N-centralアカウントを失ってもアクセスが存続するようにした。N-ableは「影響を受けたと確認されている顧客は限られた数」と述べており、その数や攻撃者がどこまで到達したかは明らかにしていない。この記事は、1件の記録に基づいて構成されている。Orca AI Incident Archiveは、その記録を、同アーカイブが追跡している他の文書化されたRMMおよびMSPサプライチェーンインシデントと並べて分類している。

この記述について、それを伝える情報源の間で争点となっている点はほとんどない。N-able自身のセキュリティアップデート、両方のCVE識別子に対するNVDのレコード、検出から数日以内に公開されたHuntressの調査、そしてThe Registerの8月7日とThe Hacker Newsの8月8日の報道は、同じ経過を説明している。すなわち、N-centralへの未認証での侵入、ピボットとして使用されたTake Control、永続化のためにエンドポイント上に登録されたCloudflareトンネルである。アーカイブはこのインシデントの日付を2026年7月31日と日単位の精度で特定している。つまり、単一の日、すなわちAdluminの検出が発報された日であり、期間ではない。情報源に関する詳細を1つ述べておく価値がある。N-ableの統合投稿の日付は2026年8月10日であり、アーカイブが引用するURLは"august-2-2026"で終わるが、現在はその後の更新に解決される。そのため、当初公開された8月2日の文面はそのリンクから復元できない。

欠陥は最初のバイパスではなく、2番目のバイパスにあった。

N-centralはその夏、すでに一度バイパスされていた。CVE-2026-18556は、代替パスまたはチャネルを用いた認証バイパスとして分類され、バージョン2026.1までのN-centralに影響し、2026.2で修正された。CVE-2026-18577のNVDレコードは、これを一文で「CVE-2026-18556に対する不完全なパッチ」であり、「バージョン2026.3.1までのN-centralにおいて認証バイパスおよびアカウント乗っ取りを可能にするもの」と説明している。つまり、すでに2026.2の修正を適用していた組織も依然として影響を受けていたということであり、だからこそ最初の脆弱性から1週間以内に2つ目の脆弱性と2つ目のホットフィックスが続いたのである。

両方のレコードは同じ脆弱性クラス CWE-288 を持っています。スコアは評価者間で一致しませんが、それは矛盾ではなくスコアリングの性質です。NVD は CVE-2026-18577 について CVSS 4.0 の基本スコア 8.2 を記録していますが、NIST の CVSS 3.1 評価では 8.1 となっています。CVE-2026-18556 では、両者は 8.2 と 7.4 です。2026-18577 の 4.0 ベクターは AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N で、サブスコアは SC:L/SI:L/SA:L です。つまり機密性は高、完全性と可用性はなしです。これはバイパス自体の説明であり、それを越えた後に攻撃者が何をするかの説明ではありません。また、侵害された管理コンソールが引き起こし得る被害を導くには不適切な指標です。

CVE-2026-18577 の修正バージョンは、2026.3.1.7 より前のすべてのビルドと示されており、これは Beazley Security の脆弱性に関するアドバイザリで用いられた表現です。N-able 自身の投稿ではホットフィックスのビルドのみが挙げられており、影響を受けるバージョンの一覧は公開されていません。

侵入者が管理コンソールで何をしたか

Take ControlはN-central独自のリモートサポートツールで、MSPの技術者がエンドユーザーのデスクトップ上で、そのユーザーに何もインストールさせることなくセッションを開けるようにするために提供されている。攻撃者はそれを、技術者と同じやり方で利用した。The Registerが報じたように、Huntressはこのアクセスを「通常は信頼されたネットワーク運用およびエンジニアリングスタッフのために確保されているのと同じレベルのN-centralアクセス」と特徴づけた。これは顧客システムへのリモートセッションの開始やスクリプトの投入に十分であり、CISO Intelligenceの8月3日の要約がこの能力を表現したように、ドメインコントローラーへのセッションを開くことも可能にするものだった。攻撃者が実際にこれらの能力のどれを使用したかは、どの情報源も述べていない。

永続化のステップは、インシデント後も生き残った部分である。エンドポイント上でCloudflareトンネルをWindowsサービスとして登録する攻撃者は、受信ファイアウォールルールを必要としない外向き専用のチャネルを手に入れ、再起動後も再び起動し、それを仕込むのに使ったN-centralアカウントが無効化された後も動作し続ける。N-ableの更新情報は、探すべきサービス名「Cloudflared」を、ユーザーのDocumentsフォルダーに置かれたsvchost.exeのコピーや、製品自体のログにおける異常なTake Controlセッションと並べて挙げている。Beazley Securityのアドバイザリは、捜索すべき兆候として組み込みアカウントmspsupport@n-able.comを追加している。N-ableはまた、攻撃者が居座るために新規アカウントを作成し既存アカウントをリセットしていたと警告し、その帰結を率直に述べた。パッチを適用しても「環境内にすでに存在している可能性のある脅威アクターを排除するものではない」。

どこまで広がったか：9つの組織と、数に入ることを拒む1社のベンダー

侵入がどこまで及んだかについて誰かが公表した唯一の数値は、N-ableではなくHuntressによるものだ。単一の侵害されたパートナー環境で、Huntressは攻撃者が9つの下流組織に到達し、それぞれで1つのエンドポイントに触れ、切断前に大半はプロセス列挙に留まっていたことを確認した。これは1つの事例で観察された下限であり、総数ではない。N-ableは、影響を受けた顧客が何社いたか、到達した下流システムが何台あったか、永続化が確立された後に攻撃者が何をしたかを明らかにすることを拒んでいる。The Registerはその拒否を明示的に報じた。CISO Intelligenceの8月3日の要約では、Huntressパートナーが到達可能なクラウドN-centralサーバーのうち、同日時点で依然未パッチだったものの割合が55パーセント超とされた。

AIの接続が実際には何なのか

アーカイブには、このインシデントへのAIの関与が確認済みとして記録されており、それを探すべき場所は攻撃側ではなく検知側である。N-ableはAdluminを「AI駆動、人間主導のSecOps」として売り込み、「適応型AI」が「環境を継続的に学習」して行動上の異常を検知すると説明している。3月のRSAC 2026で同社は、Adlumin MDR内の3つのAI駆動型検知——異常なPowerShellの検知、ML駆動のDNS混乱アラート、プロセスをその名前、パス、親チェーンでスコアリングする単一イベント型プロセス実行モデル——を発表した。7月31日の侵入を検知したのはAdluminのMDRサービスである。

確定しているのはそこまでだ。本記事のために参照したどの情報源も、対応を開始させた具体的なアラートをAIモデルと人間のアナリストのどちらが上げたのかを述べておらず、N-ableも検出を特定の名前のあるエンジンに帰属させていない。同じく明確なのは、反対側にAIシステムが現れないことだ。N-ableの説明、報道されたHuntressの調査結果、The RegisterやThe Hacker Newsの報道のいずれも、侵入の連鎖のどこにもモデル、エージェント、AIツールを記述していない。素直に読めば、この記録がAIインシデントアーカイブに属するのは、AI支援のセキュリティプラットフォームが検出の手段だったからであり、AIが侵害を引き起こしたか実行したからではない。この区別こそ、このアーカイブタグがここで読者に伝えられる最も有用なことだ。

何が変わったのか、そしてN-ableが今も語らないこと

N-ableは8月2日にHotfix 1（ビルド2026.3.1.7）をリリースし、自社のホスト環境は中央で緩和したが、オンプレミス顧客は自分でインストールする必要があった。8月6日、継続的な監視により関連する攻撃経路が判明し、同社はHotfix 2（ビルド2026.3.1.10）をリリースした。これは「追加の強化策を伴って」最初のHotfixを置き換えるもので、Hotfix 1をすでに適用した顧客にも必須だとしている。CISAは8月3日にCVE-2026-18577をKnown Exploited Vulnerabilitiesカタログに追加し、連邦政府の修復期限を8月6日とした。また8月4日にはCVE-2026-18556を追加し、期限を8月7日とした。いずれも3日間の猶予であり、The Registerはこれを緊急リスク向けの異例に短い期限と呼んだ。修正プログラムに伴うガイダンスは技術的ではなく運用面のものだった。MFAを徹底し、チケットで必要になる場合を除いて製品内サポートアカウントを無効化し、アカウントと権限の作成・リセットを監査し、ベンダー自身のインジケータースキャンサービステンプレートを実行せよという内容で、一方でクリーンなスキャン結果は何の証明にもならないとしている。「クリーンな結果は、環境が影響を受けていないことを保証するものと解釈すべきではない」とN-ableは書いている。

N-ableが公表していないのは根本原因だ。同社は、攻撃主体が活動を続けている間は技術的詳細を意図的に伏せていると述べている——「完全な根本原因分析を準備中で、安全に公表できるようになり次第共有します」——そして、確信が持てるまで「これを終了とは見なさない」としている。そのため、2つ目のバイパスはその効果によってのみ説明され、2026.2の修正が塞ぐことを目的としていた同じ認証チェックを回避する別の経路として残っている。

何がまだ未解決ですか

帰属は不明であり、ベンダー自身の指標からはそれを得られない。CISO Intelligenceは、N-ableが公開した複数のIPアドレスがMullvadおよびNordVPNの出口ノードであったと報じ、さらに2つのアドレスが後にリストへ追加されたことも報じた。同じ要約が指摘するように、これらは帰属ではなく調査上の手がかりである。ここでのN-ableの信頼度はアーカイブの信頼度とは異なる。記録が信頼度Aを帯びるのは一次資料同士が一致しているためであり、これは文書化に関する表明であって、誰かが侵入を端から端まで独立に検証したことについての表明ではない。

記録が実際に裏付けているのは、侵害を報じる見出しよりも範囲が狭く、より長く残る事実だ。MSPが顧客の環境全体を管理するために使うプラットフォームで2回目の認証バイパスが実際の攻撃で悪用され、7月31日の最初の検知から8月6日の2回目のホットフィックスまでの少なくとも6日間、塞がれないままだった。攻撃者は、N-centralにパッチを当てても塞げない、エンドポイントへの再侵入経路を構築していた。だからこそベンダー自身も、パッチ適用が遅れた人には、クリーンなスキャン結果を信じるのではなく、環境は侵害済みとして扱い、アカウントの監査を始めるよう助言したのだ。