N-able bestätigt: N-central-Angreifer erreichten verwaltete Endpunkte

Am 31. Juli 2026 meldete der Managed-Detection-and-Response-Dienst Adlumin von N-able ungewöhnliche Aktivitäten in einer Kundenumgebung und stellte fest, dass ein Bedrohungsakteur eine Schwachstelle in N-central ausnutzte, die der Anbieter noch nicht offengelegt hatte. N-central ist die Remote-Monitoring-and-Management-Plattform, die Managed Service Provider nutzen, um die Systeme ihrer Kunden zu verwalten; was die Eindringlinge kontrollierten, war daher nicht ein einzelner Rechner, sondern die Konsole vor vielen Systemen. Die Schwachstelle, die später als CVE-2026-18577 erfasst wurde, ermöglichte administrativen Fernzugriff ohne Authentifizierung; der Angreifer nutzte dann N-centrals eigene Funktion Take Control, um Sitzungen auf verwalteten Endpunkten zu öffnen, und registrierte Cloudflare-Tunnel-Dienste auf diesen Geräten, sodass der Zugriff auch nach Verlust des N-central-Kontos bestehen bliebe. N-able erklärt: „Eine begrenzte Anzahl von Kunden wurde als betroffen identifiziert“, und hat weder gesagt, wie viele das sind, noch, wie weit die Angreifer vorgedrungen sind.Dieser Artikel basiert auf einem einzelnen Datensatz in dem Orca AI Incident Archive, das ihn zusammen mit den anderen dokumentierten RMM- und MSP-Lieferkettenvorfällen aufführt, die es verfolgt.

An dieser Darstellung ist kaum etwas zwischen den Quellen umstritten, die sie beschreiben. N-ables eigenes Sicherheitsupdate, die NVD-Einträge zu beiden CVE-Kennungen, eine wenige Tage nach der Entdeckung veröffentlichte Huntress-Untersuchung sowie die Berichterstattung von The Register am 7. August und von The Hacker News am 8. August beschreiben dieselbe Abfolge: unauthentifizierter Einstieg in N-central, Take Control als Pivot eingesetzt, zur Persistenz auf Endpunkten registrierte Cloudflare-Tunnel. Das Archiv datiert den Vorfall tagesgenau auf den 31. Juli 2026, also auf diesen einzelnen Tag – den Tag, an dem Adlumins Erkennung ausgelöst wurde – und nicht auf ein Zeitfenster. Ein Detail zur Quellenlage ist erwähnenswert: N-ables konsolidierter Beitrag ist auf den 10. August 2026 datiert, und die vom Archiv zitierte URL, die auf "august-2-2026" endet, führt inzwischen zu diesem späteren Update, sodass sich der ursprünglich veröffentlichte Text vom 2. August über diesen Link nicht mehr wiederherstellen lässt.

Der Fehler war der zweite Bypass, nicht der erste.

N-central war in diesem Sommer bereits einmal umgangen worden. CVE-2026-18556, eingestuft als Umgehung der Authentifizierung über einen alternativen Pfad oder Kanal, betraf N-central bis einschließlich Version 2026.1 und wurde in 2026.2 behoben. Der NVD-Eintrag für CVE-2026-18577 beschreibt sie in einem Satz als „einen unvollständigen Patch für CVE-2026-18556“, der „eine Umgehung der Authentifizierung und Kontoübernahme in N-central-Versionen bis 2026.3.1 ermöglicht“. Mit anderen Worten: Die Organisationen, die den 2026.2-Fix bereits eingespielt hatten, waren weiterhin gefährdet, weshalb innerhalb einer Woche nach dem ersten ein zweiter Fehler und ein zweiter Hotfix folgten.

Beide Einträge weisen dieselbe Schwachstellenklasse auf, CWE-288. Die Scores stimmen zwischen den Bewertern nicht überein, und das ist eine Eigenschaft des Scorings, kein Widerspruch: NVD verzeichnet für CVE-2026-18577 einen CVSS-4.0-Basisscore von 8.2, während die CVSS-3.1-Bewertung von NIST ihn bei 8.1 einordnet. Für CVE-2026-18556 liegen die beiden Werte bei 8.2 und 7.4. Der 4.0-Vektor für 2026-18577 lautet AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N mit den Sub-Scores SC:L/SI:L/SA:L – Vertraulichkeit hoch, Integrität und Verfügbarkeit keine. Das beschreibt die Umgehung selbst, nicht das, was ein Angreifer nach ihrer Überwindung tut, und es ist ein schlechter Anhaltspunkt dafür, welchen Schaden eine kompromittierte Verwaltungskonsole anrichten kann.

Die Fixversion für CVE-2026-18577 wird mit „alle Builds vor 2026.3.1.7“ angegeben – eine Formulierung, die in der Sicherheitsmeldung von Beazley Security zu der Schwachstelle verwendet wird; der eigene Beitrag von N-able nennt nur die Hotfix-Builds und veröffentlicht keine Matrix der betroffenen Versionen.

Was die Eindringlinge mit einer Managementkonsole angestellt haben

Take Control ist N-centrals eigenes Remote-Support-Tool, das bereitgestellt wird, damit ein MSP-Techniker eine Sitzung auf dem Desktop eines Endbenutzers öffnen kann, ohne dass dieser Benutzer etwas installieren muss. Die Angreifer nutzten es so, wie ein Techniker es tun würde. Wie The Register berichtete, beschrieb Huntress den Zugriff als „dasselbe Maß an N-central-Zugriff, das normalerweise vertrauenswürdigen Netzwerkbetriebs- und Engineering-Mitarbeitern vorbehalten ist" – ausreichend, um Remote-Sitzungen zu öffnen und Skripte in Kundensysteme einzuspeisen, und, wie CISO Intelligence in der Zusammenfassung vom 3. August die Fähigkeit formulierte, Sitzungen zu Domänencontrollern zu öffnen. Keine Quelle gibt an, welche dieser Fähigkeiten die Angreifer tatsächlich nutzten.

Der Persistenzschritt ist der Teil, der den Vorfall überdauert hat. Ein Angreifer, der einen Cloudflare-Tunnel als Windows-Dienst auf einem Endpunkt registriert, erhält einen ausschließlich ausgehenden Kanal, der keine eingehende Firewallregel benötigt, nach einem Neustart erneut startet und auch dann weiter funktioniert, nachdem das N-central-Konto, das zu seiner Platzierung verwendet wurde, widerrufen wurde. Das Update von N-able führt den zu suchenden Dienstnamen Cloudflared auf, zusammen mit einer Kopie von svchost.exe, die im Dokumenteordner eines Benutzers abgelegt ist, und anomalen Take-Control-Sitzungen in den eigenen Protokollen des Produkts. Der Sicherheitshinweis von Beazley Security nennt zusätzlich das integrierte Konto mspsupport@n-able.com als Anzeichen, nach dem gesucht werden sollte. N-able warnte außerdem, dass Angreifer neue Konten anlegten und bestehende zurücksetzten, um sich zu halten, und benannte die Konsequenz unmissverständlich: Das Anwenden des Patches „entfernt keinen Bedrohungsakteur, der möglicherweise bereits in Ihrer Umgebung vorhanden ist“.

Wie weit es reichte: neun Organisationen und ein Anbieter, der nicht mitzählt

Die einzige Zahl, die jemals dazu veröffentlicht wurde, wie weit die Eindringung reichte, stammt von Huntress, nicht von N-able. In einer einzelnen kompromittierten Partnerumgebung stellte Huntress fest, dass Angreifer neun nachgelagerte Organisationen erreichten, in jeder einen Endpunkt berührten und sich weitgehend auf Prozess-Enumeration beschränkten, bevor sie die Verbindung trennten. Das ist ein in einem Fall beobachteter Mindestwert, keine Gesamtzahl: N-able hat es abgelehnt, Angaben dazu zu machen, wie viele Kunden betroffen waren, wie viele nachgelagerte Systeme erreicht wurden oder was die Angreifer unternahmen, nachdem Persistenz eingerichtet war. The Register berichtete ausdrücklich über diese Weigerung. In der Zusammenfassung von CISO Intelligence vom 3. August wurde der Anteil der erreichbaren Cloud-N-central-Server von Huntress-Partnern, die an diesem Datum noch ungepatcht waren, auf mehr als 55 Prozent beziffert.

Was die KI-Anbindung tatsächlich ist

Das Archiv verzeichnet die Beteiligung von KI an diesem Vorfall als bestätigt, und die Stelle, an der man danach suchen muss, ist die Erkennung, nicht der Angriff. N-able vermarktet Adlumin als „KI-gestütztes, menschengeführtes SecOps“ mit „adaptiver KI“, die „kontinuierlich Ihre Umgebung lernt“ und Verhaltensauffälligkeiten meldet; auf der RSAC 2026 im März kündigte das Unternehmen drei KI-gestützte Erkennungen innerhalb von Adlumin MDR an — die Erkennung anomaler PowerShell, eine ML-gestützte DNS-Störungswarnung und ein Prozessausführungsmodell für Einzelereignisse, das einen Prozess anhand seines Namens, seines Pfads und seiner übergeordneten Prozesskette bewertet. Der MDR-Dienst von Adlumin war es, der das Eindringen am 31. Juli entdeckt hat.

Was belegt ist, endet dort. Keine für diesen Artikel herangezogene Quelle gibt an, ob ein KI-Modell oder ein menschlicher Analyst den konkreten Alarm ausgelöst hat, mit dem die Reaktion begann, und N-able schreibt die Erkennung keiner namentlich genannten Engine zu. Ebenso klar ist, dass auf der anderen Seite kein KI-System auftaucht: Weder N-ables Darstellung noch die berichteten Ergebnisse von Huntress noch die Berichterstattung von The Register oder The Hacker News beschreibt irgendwo in der Eindringkette ein Modell, einen Agenten oder ein KI-Tool. Nüchtern gelesen gehört dieser Eintrag in ein KI-Vorfallarchiv, weil eine KI-gestützte Sicherheitsplattform das Instrument der Erkennung war, nicht weil KI die Kompromittierung verursacht oder durchgeführt hat. Diese Unterscheidung ist das Nützlichste, was das Archiv-Tag einem Leser hier sagen kann.

Was sich geändert hat – und was N-able weiterhin nicht sagen wird

N-able lieferte Hotfix 1, Build 2026.3.1.7, am 2. August aus und entschärfte seine eigenen gehosteten Umgebungen zentral; On-Premises-Kunden mussten ihn selbst installieren. Am 6. August ergab die fortgesetzte Überwachung einen verwandten Angriffspfad, und das Unternehmen lieferte Hotfix 2, Build 2026.3.1.10, aus, der laut eigenen Angaben den ersten „mit zusätzlichen Härtungsmaßnahmen“ ersetzt und auch für Kunden erforderlich ist, die Hotfix 1 bereits eingespielt hatten. CISA nahm CVE-2026-18577 am 3. August in seinen Katalog „Known Exploited Vulnerabilities“ auf, mit einer Behebungsfrist für Bundesbehörden bis zum 6. August, und CVE-2026-18556 am 4. August mit einer Frist bis zum 7. August – in beiden Fällen ein Zeitfenster von drei Tagen, das The Register als ungewöhnlich kurze Frist bezeichnete, die dringendem Risiko vorbehalten sei. Die mit den Korrekturen einhergehenden Hinweise waren operativer statt technischer Natur: MFA erzwingen, das produktinterne Supportkonto deaktivieren, sofern kein Ticket es erfordert, Konten und Berechtigungen hinsichtlich Erstellungen und Zurücksetzungen prüfen und die eigene Servicevorlage des Herstellers zum Scannen nach Indikatoren ausführen – wobei ein sauberer Scan keinesfalls als Beweis zu werten ist. „Ein sauberes Ergebnis sollte nicht als Garantie dafür interpretiert werden, dass Ihre Umgebung nicht beeinträchtigt wurde“, schrieb N-able.

Was N-able nicht veröffentlicht hat, ist die Grundursache. Das Unternehmen gibt an, technische Details bewusst zurückzuhalten, solange Akteure aktiv sind – „Eine vollständige Analyse der Grundursache wird folgen, und wir werden sie teilen, sobald dies sicher möglich ist“ – und dass es „das nicht als abgeschlossen bezeichnet“, bis es sicher ist. Damit bleibt die zweite Umgehung nur durch ihre Wirkung beschrieben: als alternativer Weg um dieselbe Authentifizierungsprüfung herum, die der 2026.2-Fix schließen sollte.

Was ist noch offen?

Die Zuordnung ist unbekannt, und die eigenen Indikatoren des Anbieters werden sie nicht liefern. CISO Intelligence berichtete, dass mehrere der von N-able veröffentlichten IP-Adressen Exit-Nodes von Mullvad und NordVPN waren und dass zwei weitere Adressen später in die Liste aufgenommen wurden – Ermittlungsansätze, keine Zuordnung, wie dieselbe Zusammenfassung anmerkt. Das Vertrauen, das N-able hier an den Tag legt, ist nicht das des Archivs: Der Eintrag trägt die Konfidenzstufe A, weil die Primärquellen miteinander übereinstimmen – eine Aussage über die Dokumentation, nicht darüber, dass jemand den Eindringungsversuch unabhängig von Anfang bis Ende verifiziert hätte.

Was der Befund tatsächlich stützt, ist enger und belastbarer als eine Schlagzeile über einen Sicherheitsvorfall. Eine zweite Authentifizierungs-Umgehung in einer Plattform, die MSPs zur Verwaltung gesamter Kundenumgebungen nutzen, wurde in freier Wildbahn ausgenutzt und blieb mindestens sechs Tage lang offen – zwischen der ersten Entdeckung am 31. Juli und dem zweiten Hotfix am 6. August. Die Angreifer bauten einen Weg zurück in Endpunkte, den das Patchen von N-central nicht schließt – weshalb die eigene Empfehlung des Anbieters an alle, die spät gepatcht haben, darin bestand, die Umgebung als kompromittiert zu behandeln und mit der Prüfung von Konten zu beginnen, statt einem sauberen Scan zu vertrauen.