Die aktuellen Meldungen zu N-central Angriffe werfen ein ernstes Licht auf die Risiken in Remote Monitoring- und Management-Umgebungen. Laut N-able verschafften sich Angreifer zunächst über einen Authentifizierungs-Umgehungsfehler Zugriff mit administrativen Rechten auf Server, auf denen N-central läuft. Danach konnten sie die über diese Plattform verwalteten Endpoints erreichen und dabei Funktionen nutzen, die eigentlich für Support und Administration gedacht sind.
Besonders relevant: Der erste Patch war zwar veröffentlicht, aber offenbar nicht vollständig. N-able spricht deshalb davon, dass alle betroffenen Installationen konsequent auf eine neuere Version aktualisiert werden müssen – und dass ein reines Upgrade unter Umständen nicht genügt, um von Angreifern eingebaute „Wiederzugriffs“-Mechanismen wieder zu entfernen.
Was N-able über die N-central Angriffe berichtet
N-able beschreibt, dass Angreifer einen Authentication Bypass in N-central ausnutzten. Dadurch erlangten sie Remote-Administrative Access und konnten im Anschluss in die Kundensysteme vordringen, die über die kompromittierten N-central Server gemanagt werden.
Der Weg vom kompromittierten Management-Server zu den Endgeräten erfolgte über Take Control. Damit lassen sich verwaltete Systeme aus der Ferne übernehmen, typischerweise für Support- und Wartungszwecke. Im konkreten Angriffsszenario nutzten die Angreifer dieses Capability-Setup, um Zugriff auf Endpoints zu erlangen.
Warum der erste Fix nicht ausreichte
Der erste von N-able bereitgestellte Fix wird als unvollständig eingeordnet. Eine zentrale Rolle spielt dabei CVE-2026-18577. Laut N-able betrifft diese Schwachstelle N-central Builds, die vor 2026.3.1.7 liegen.
N-able lieferte mit 2026.3.1.7 die erste Version, die als „unbetroffen“ gilt. Als Veröffentlichungstermin nennt das Unternehmen den 2. August. Damit macht N-able deutlich, dass ein Upgrade auf frühere Updates allein nicht ausreichend sein kann.
Zuvor war bereits eine Version ins Feld geführt worden, die man als erste Abhilfe verstanden hatte: N-able hatte Kunden zunächst angewiesen, auf 2026.3 zu gehen. Diese Anweisung gilt jedoch nicht mehr als ausreichend, weil im Nachhinein ein alternativer Ausnutzungsweg entdeckt wurde.
Die Rolle von Cloudflare-Tunneln und Persistenz
Nach dem erfolgreichen Zugriff auf einen N-central Server nutzten die Angreifer laut Bericht Cloudflare Tunnels – und registrierten sie als Dienste auf den verwalteten Geräten. Das ist vor allem deshalb bedeutsam, weil der Tunnel ausgehend eine Verbindung zum Cloudflare-Edge aufbaut.
Dadurch ist in vielen Fällen keine Inbound-Freigabe oder offene Listening-Port erforderlich. Zusätzlich berichtete N-able, dass die Dienste so konfiguriert waren, dass sie auch nach einem Neustart des Systems bestehen bleiben. Praktisch bedeutet das: Selbst wenn der Pfad über den N-central Server später blockiert oder deaktiviert wird, können die Angreifer den Zugriff über die Tunnel weiterhin aufrechterhalten.
N-able betont zudem, dass nach dem bisherigen Stand der Offenlegung nichts darauf hindeutet, dass Cloudflare selbst kompromittiert wurde. Vielmehr wird das Tunneling-Angebot als Technik zur Zugangserhaltung missbraucht.
Welche Systeme betroffen sind und welches Upgrade zählt
Wenn es um N-central Angriffe und die Eindämmung geht, ist die wichtigste Maßnahme für Betreiber klar formuliert: Jeder N-central Kunde sollte auf 2026.3.1.7 aktualisieren.
N-able stellt außerdem klar, dass ein Upgrade auf 2026.3 als ursprüngliche Empfehlung nicht mehr genügt. Für hosted NCOD-Instanzen soll der Plattformanbieter Updates automatisiert auf einem Zeitplan bereitstellen, der direkt mit Partnern kommuniziert wird. Für self-hosted-Installationen liegt die Verantwortung dagegen beim Kunden: Dort muss die Aktualisierung durch den Betreiber selbst durchgeführt werden.
Warum ein Upgrade nicht alles entfernt
Besonders wichtig ist der Hinweis, dass das reine Aktualisieren von N-central Persistenz auf anderen Maschinen nicht automatisch beseitigt. Findet man Hinweise auf Kompromittierung, sollten Teams deshalb gezielt nach den von Angreifern eingerichteten Tunnel-Diensten auf den verwalteten Endpoints suchen und diese entfernen.
Mit anderen Worten: Das Upgrade schließt zwar die ursprüngliche Lücke in der Management-Komponente, aber es räumt nicht zwangsläufig die „Spuren“ und Zugangspunkte weg, die bereits auf Kundensystemen installiert wurden.
Wie es begann: Erkennung durch ungewöhnliche Lizenzfehler
Die Ermittlungen begannen laut N-able am 31. Juli. Auslöser waren ungewöhnliche Mengen an Lizenzierungsfehlern bei On-Premises-Kunden. Im Rahmen der Untersuchung stellte das Unternehmen fest, dass ein Angreifer remote administrative Rechte auf Servern erlangt hatte, auf denen Versionen 2026.1 und früher liefen.
N-able erklärt weiter, dass es eine begrenzte Anzahl betroffener Kunden identifiziert und kontaktiert habe, ohne dabei eine konkrete Zahl zu nennen. Welche weiteren Details zu Zeitpunkt, Ausmaß oder Zielsystemen vorliegen, blieb in der Berichterstattung zunächst offen.
Die Schwachstellen im Überblick: CVE-2026-18556 und CVE-2026-18577
Zwei CVEs stehen im Zusammenhang mit dem Geschehen. Der erste Punkt ist CVE-2026-18556. N-able bezeichnet diese Schwachstelle in seinem eigenen CVE-Eintrag als „unauthenticated administrative account takeover“. Eingestuft wird der Fehler als Authentifizierungs-Bypass über einen alternativen Pfad oder Kanal (CWE-288).
Später kam CVE-2026-18577 hinzu. N-able berichtet, dass der ursprüngliche Fix den zuerst bekannten Pfad behoben habe, man aber danach einen alternativen Weg fand, der dieselbe grundlegende Schwachstellenklasse nutzte und die frühere Blockade umging. Dadurch wurde der betroffene Bereich erneut erweitert – bis zu Builds vor 2026.3.1.7.
Beide Schwachstellen erhielten laut Bericht einen Score von 8.2 (CVSS 4.0). Welche konkreten Endpunkte oder Request-Sequenzen betroffen sind, wird in den öffentlichen Informationen nicht bis in Code-Ebene hinein aufgeschlüsselt.
IoCs und Hinweise zur forensischen Suche
Zur Unterstützung bei der Erkennung wurden im Bericht mehrere IP-Adressen genannt, die im Zusammenhang mit den Angriffen gesehen wurden. Dazu gehören unter anderem:
- 173.249.252.200
- 87.249.138.34
- 37.19.210.32
- 37.153.90.88
- 92.118.112.181
- 68.235.46.214
Ein weiterer Punkt: Huntress ordnete einen Teil dieser Adressen später als Mullvad- oder NordVPN-Exit-Nodes ein. Entsprechend riet Huntress dazu, Treffer abzugleichen und in den N-central UI-, Netzwerk- und Endpoint-Logs korrelierende Hinweise zu suchen.
N-able nannte außerdem konkrete Suchhinweise: Dazu gehört das Auftauchen von svchost.exe in Dokumentordnern (Users’ Documents), das Vorhandensein eines Dienstnamens Cloudflared sowie Traffic von den oben genannten IP-Adressen.
Wer solche Indikatoren findet, soll laut N-able den Support kontaktieren und gleichzeitig die eigenen Sicherheitsteams einbinden.
Empfehlungen zu Logs und Take-Control-Aktivitäten
Für Betreiber, die verdächtige Take Control-Aktivitäten untersuchen wollen, nennt Huntress konkrete Logquellen. Besonders relevant seien ui_access_control.log sowie die Windows-Dateipfade rund um:
C:\
Quelle: https://thehackernews.com/2026/08/n-able-says-attackers-take-over-n.html
