Bij N-able N-central hebben aanvallers een serieuze stap gezet richting volledige overname. Ze maakten gebruik van een authenticatiebypass om remote administratieve toegang te krijgen tot servers die via het platform beheerd worden. Vervolgens breidden ze de controle uit richting de klantomgevingen die aan die N-central servers gekoppeld zijn.
De eerste herstelmaatregel bleek volgens N-able niet afdoende. Daarom is de update-advieslijn opnieuw aangescherpt. In dit artikel zet ik de kernpunten op een rij: wat er is gebeurd, welke versies geraakt worden en welke acties beheerders nu moeten nemen.
Wat is er gebeurd met N-able N-central?
N-central is een remote monitoring en management-oplossing die door managed service providers en IT-teams wordt gebruikt om endpoints en klantomgevingen te beheren. Na succesvolle compromis van een N-central server konden aanvallers hun toegang doortrekken naar de endpoints die via die server worden beheerd.
Het interessante deel zit in de overbrugging naar de eindpunten: de aanvallers gebruikten Take Control om beheersingang te bereiken. Daarna registreerden ze Cloudflare tunnels als services op de aangetaste apparaten.
Waarom Cloudflare tunnels lastig te detecteren zijn
De door de aanvallers gebruikte tunnels leggen verbinding uitgaand met de edge van Cloudflare. Daardoor hebben beheerders doorgaans geen inbound firewallregel of open luisterpoort nodig om die verbinding mogelijk te maken. Bovendien draaien de tunnels als services, waardoor ze doorgaans blijven werken na een reboot.
Volgens N-able konden de aanvallers zo blijven bij de systemen, zelfs nadat de route via de N-central server was weggevallen of werd ingetrokken. Cruciaal: het feit dat een N-central update je oorspronkelijke toegangspad dichtzet, betekent niet automatisch dat alle persistence elders ook verdwijnt.
Welke kwetsbaarheden spelen mee?
De incidentinformatie draait om twee CVE’s die samen een groter beeld schetsen van hoe een aanvaller binnen kan komen en waarom een eerste fix onvoldoende was.
- CVE-2026-18556 betreft releases tot en met 2026.1. N-able gaf aan dat een pad in 2026.2 was gerepareerd.
- CVE-2026-18577 breidt het getroffen bereik uit naar builds vóór 2026.3.1.7. Deze kwetsbaarheid ontstond nadat N-able later een alternatief exploitatiespoor vond dat de eerdere blokkade niet afdekte.
Beide CVE’s zijn volgens N-able gescoord met 8.2 op CVSS 4.0. In de disclosure ontbreekt echter code-level root-cause detail, en ook wordt niet gespecificeerd welke specifieke endpoint of request sequence precies wordt misbruikt.
Welke N-able N-central versies moeten worden geüpgraded?
N-able heeft als eerste “onbekende” versie die niet meer kwetsbaar zou zijn: 2026.3.1.7. N-able meldde dat deze build op 2 augustus beschikbaar is gekomen als de eerste versie die niet geraakt wordt.
Eerdere instructies richting 2026.3 blijken later niet voldoende. De aanbevolen actie is nu helder: alle N-able N-central klanten moeten naar 2026.3.1.7.
Daarnaast is er een verschil tussen hostingmodellen:
- Hosted NCOD: upgrades worden volgens N-able automatisch ingepland, op een schedule die partners rechtstreeks ontvangen.
- Self-hosted: deze moeten door de klant zelf worden geüpgraded.
Persistente toegang na patch: waar moet je op letten?
Een belangrijke boodschap van N-able is dat het upgraden van N-central niet automatisch alle sporen op andere machines opruimt. Als de aanvaller persistence heeft geïnstalleerd op de beheerde endpoints, dan blijft die mogelijk werken.
Daarom is het verstandig om naast het updaten van N-central ook gericht te zoeken naar tekenen van ongeautoriseerde tunnel-services en andere indicators.
Praktische aanwijzingen voor onderzoek en hunting
De onderzoekers geven meerdere concrete richtingen om te controleren.
Zoek naar verdachte services en bestandslocaties
N-able adviseerde klanten om te letten op de aanwezigheid van:
- svchost.exe in Documents-mappen van gebruikers
- een service met de naam Cloudflared
- verkeer dat overeenkomt met de gepubliceerde IP-adressen
Wie dergelijke signalen aantreft, wordt gevraagd contact op te nemen met support en interne securityteams in te schakelen.
Controleer logs rond Take Control
Huntress adviseerde specifiek om te kijken naar mogelijke Take Control-activiteiten die niet door een geautoriseerde operator uitgevoerd lijken te zijn.
- Check ui_access_control.log
- Correlatie met Windows-endpoint logs zoals C:\ProgramData\GetSupportService_N-Central\Logs\BASupSrvc_*.log.gz
Let op: deze logs kunnen ook tijdens legitiem gebruik van Take Control voorkomen. Aanwezigheid alleen bewijst dus geen compromittering, maar het maakt correlatie met tijdstippen en sessies wél relevant.
Let op sessions die lijken te koppelen aan support-identiteiten
Huntress noemt ook het onderzoeken van sessies die gekoppeld zijn aan “support” identiteiten, zoals mspsupport@n-able.com. Dit kan helpen bij het onderscheid tussen geplande/ondersteunde activiteiten en ongeautoriseerde toegang.
Netwerkindicatoren: gepubliceerde IP-adressen en VPN-exitnodes
N-able publiceerde zes IP-adressen die in de aanvallen gezien zouden zijn. Later gaf Huntress aan dat een deel daarvan te koppelen was aan Mullvad of NordVPN exit nodes.
De lijst die N-able deelde:
- 173[.]249[.]252[.]200
- 87[.]249[.]138[.]34
- 37[.]19[.]210[.]32
- 37[.]153[.]90[.]88
- 92[.]118[.]112[.]181
- 68[.]235[.]46[.]214
Huntress adviseerde om eventuele matches te combineren met data uit N-central UI, netwerkobservaties en endpoint logs. Alleen “IP match” is dus niet voldoende om met zekerheid te concluderen dat er misbruik is gemaakt.
Impact en scope: wat weten we wel (en nog niet)?
N-able startte het onderzoek op 31 juli nadat on-premises klanten opvallend veel licentiefouten rapporteerden. Daarbij stelde N-able vast dat een aanvaller remote administratieve toegang had verkregen tot servers die draaiden met versies 2026.1 of ouder.
Over de omvang van getroffen klanten en downstream endpoints wordt in de disclosure geen concreet aantal genoemd. Wel zegt N-able dat men een beperkte groep aangetaste klanten zou hebben geïdentificeerd en benaderd.
Huntress vult aan dat het ging om een self-hosted N-central instance binnen één partneraccount, waarbij de aanvallers negen organisaties bereikten. Per organisatie werd één endpoint benaderd. Daarbij was de post-compromise activiteit volgens Huntress aanvankelijk beperkt tot het enumereren van processen; daarna zijn de aanvallers losgekoppeld. Over mogelijke datadiefstal of extra actorkunst worden op basis van de beschikbare informatie geen definitieve claims gedaan.
Gerelateerde incidenten: waarom “update” niet genoeg is
Dit soort aanvallen past in een breder patroon waarin een kwetsbaarheid niet alleen leidt tot eenmalige toegang, maar ook tot het opzetten van duurzame controle. Als je dit vergelijkt met eerdere cases rond vertrouwen en patch-gaten, zie je een terugkerend thema: een fix kan incompleet blijken, of persistence kan op een ander punt in de keten blijven staan.
Daarom is het zinvol om ook aandacht te besteden aan hoe je patches en bewijsstukken combineert. Lees bijvoorbeeld ook implicaties van hacks en patches: wat je nu doet voor een praktische aanpak bij herstel na compromittering.
Omdat dit incident gaat over remote beheersystemen en het doorzetten van toegang naar endpoints, helpt het bovendien om te begrijpen hoe “beheerstromen” misbruikt kunnen worden. Een vergelijkbare lens vind je in analyses zoals device code phishing: waarom het zo snel groeit, waar ook de focus ligt op toegang verwerven via beheerdersgerichte mechanismen.
Wat je nu moet doen als beheerder
Als je met N-able N-central werkt, is de volgorde van handelen belangrijk:
- Upgrade naar 2026.3.1.7 (2026.3 alleen is niet langer voldoende).
- Voer daarna hunting op endpoints uit op verdachte tunnel-services en indicators zoals de door N-able genoemde bestanden en service-naam.
- Correlatie in logs: koppel Take Control-logs en netwerkverkeer aan de tijdlijn van beheerssessies.
- Neem bij signalen contact op met support en laat je securityteam de bevindingen valideren.
Door eerst het toegangspunt te sluiten en daarna persistence elders aan te pakken, verklein je de kans dat dezelfde toegang “terugkomt” via de omweg die de aanvaller al had voorbereid.
Conclusie
N-able N-central is geraakt door een authenticatiebypass waarmee aanvallers remote administratieve controle konden verkrijgen. Toen N-able een eerste fix toepaste, bleek die later incompleet door een alternatief exploitatiespoor, wat leidde tot het uitgebreid getroffen bereik tot vóór 2026.3.1.7.
De kern van de verdediging ligt daarom niet alleen bij upgraden, maar ook bij het onderzoeken en verwijderen van persistence op beheerde endpoints. Neem de updates serieus, maar controleer ook of de aanvaller nog actief is via geïnstalleerde services en uitgaand tunnelverkeer.
Bron: https://thehackernews.com/2026/08/n-able-says-attackers-take-over-n.html
