Direct naar de inhoud
Beveiligingsnieuws

MeshCentral backdoor bij 3BB: aanpak & risico’s

MeshCentral backdoor

Een aanval op 3BB, een van de grootste internetproviders van Thailand, laat zien hoe lastig het kan zijn om kwaadwillende activiteiten te onderscheiden van “normaal” beheer. Onderzoekers van Hunt.io ontdekten dat een aanvaller op afstand controle behield via een legitiem hulpmiddel: MeshCentral. Dat beheerinstrument werd niet alleen gebruikt, maar ook als MeshCentral backdoor ingezet om toegang te verankeren.

In dit artikel lees je wat er volgens het onderzoek precies is gebeurd, welke doelen werden nagestreefd en welke acties organisaties met vergelijkbare edge- en authenticatiesystemen het best direct ondernemen.

Wat Hunt.io ontdekte bij 3BB

Hunt.io kwam de intrusie op het spoor door onderzoek aan een server die de aanvaller open hadgezet op het internet. Die machine bevatte tools van de aanvaller en een overzicht van interne computers die al waren toegevoegd aan zijn opzet.

Belangrijk detail: de onderzoekers zagen de server op 3 juni 2026 terwijl de operatie nog actief was. De tools op de openstaande server werden uitgevoerd vanuit het interne netwerk van 3BB zelf. Eén teruggevonden bestand liet zien dat de aanvaller volledige administratieve controle behaalde op een interne machine, aangeduid als root.

MeshCentral werd gebruikt als verborgen toegang

Om die controle te behouden, installeerde de aanvaller een MeshCentral-agent. Dit is een gratis tool die IT-teams doorgaans gebruiken om apparaten op afstand te beheren. Juist daardoor past het gedrag in de “beheer-routine” en is het lastiger om het als aanval te herkennen.

De configuratie die teruggevonden werd, wijst erop dat MeshCentral was ingesteld als een verborgen backdoor. De agent rapporteerde terug naar een control server die de aanvaller beheerde via www.ayuthayatech[.]com. Binnen MeshCentral was er bovendien sprake van een specifieke device group: TH-3BB.

Ook de device list die op de server stond, gaf aanwijzingen voor actieve controle: meerdere machines waren op het moment van vastlegging verbonden en draaiden met root-privileges. Dat ondersteunt de conclusie dat de aanvaller op dat moment daadwerkelijk administratieve toegang had.

Waarom remote-managementtools extra risico geven

Remote-managementsoftware is ontworpen om verbindingen te leggen en acties uit te voeren op beheerde systemen. Daardoor wordt de aanwezigheid van tooling en communicatie vaak niet direct als verdacht gezien.

Hunt.io wijst er expliciet op dat aanvallers steeds vaker misbruikmaken van dit soort legitieme software. De aanval verbergt zich dan tussen normale beheeractiviteiten: logs kunnen “gewoon beheer” suggereren, en SOC-teams zien mogelijk eerst alleen vertrouwd ogende processen of verbindingen.

Persistence en “cleanup”: toegang blijven houden

Een opvallend onderdeel van de aanval was de manier waarop de aanvaller sporen probeerde te wissen. Volgens het onderzoek was er een aparte cleanup-script dat logs wilde verwijderen en andere tools moest weggooien.

Tegelijk werd MeshCentral niet verwijderd. De kern van deze aanpak is duidelijk: de aanvaller wilde dat de toegang bleef bestaan via de agent, ook nadat overige sporen waren gewist. Dat betekent voor verdedigers dat “alles opschonen” niet automatisch genoeg is—eerst moet je bewijs veiligstellen.

Waren wachtwoorden en gevoelige gegevens het doel?

De aanval was niet gericht op één enkel apparaat, maar op het uitbreiden van controle binnen het netwerk. Hiertoe werden volgens de onderzoekers scripts ingezet die via SSH wachtwoorden probeerden op meer dan 55 interne computers. Daarnaast werd de interne salesportal van 3BB verkend: agent.3bb.co[.]th.

Verder zochten de scripts op gecompromitteerde machines naar opgeslagen inloggegevens, waaronder wachtwoorden, database-aanmeldingen en SSH-keys. In sommige scenario’s kunnen zulke vondsten direct leiden tot extra persistentie en lateral movement.

Het onderzoek vermeldt ook dat er mogelijkheden waren om web shells te plaatsen—verborgen pagina’s waarmee een aanvaller commando’s kan uitvoeren—en om extra SSH-keys toe te voegen als back-uproutes terug.

Als einddoel noemt Hunt.io de subscriber data. De getroffen evidence suggereert dat vooral de RADIUS-databases werden benaderd. RADIUS is een systeem dat logincredentials opslaat die klanten gebruiken om online te komen. Volgens de onderzoekers is er geen bewijs gevonden dat de data daadwerkelijk is overgenomen, maar wel dat de databases werden geviseerd.

Meerdere doelen: FortiGate SSL-VPN en interne portals

Naast de focus op de interne portal werd ook gekeken naar systemen rondom VPN-toegang. Het rapport verwijst naar twee domeinen: mail.3bb.co[.]th (gekoppeld aan een FortiGate SSL-VPN gateway) en agent.3bb.co[.]th (een interne portal).

Hunt.io vond daarnaast aanwijzingen die de aandacht verbreden. Op de aangetroffen server stonden referenties naar een tweede doel binnen infrastructuur die 3BB deelde met een voormalig onderdeel: het netwerk “Jasmine”. Daar waren een geldig VPN-certificaat en actieve sessies zichtbaar. Dat bevestigt volgens de onderzoekers niet dat “Jasmine” zelf daadwerkelijk is doorbroken, maar het geeft wel richting aan de intenties.

Mogelijke initiële toegang: toolkit met Fortinet-kwetsbaarheid

Het rapport beschrijft dat de precieze manier waarop de aanvaller binnenkwam niet is vastgesteld. Wel bevatte de server een complete toolkit gericht op 3BB FortiGate SSL-VPN gateways, waaronder een exploit voor CVE-2024-21762.

Deze Fortinet-kwetsbaarheid wordt beschreven als een serious issue uit 2024 waarmee aanvallers code kunnen uitvoeren zonder in te loggen. De betreffende gateway zou een firmwareversie hebben gedraaid die door de advisory wordt geraakt.

Toch ontbreekt een harde bevestiging dat deze exploit daadwerkelijk de initiële toegang veroorzaakte. Hunt.io benadrukt dat de aanwezigheid van FortiGate-tooling vooral iets zegt over capaciteit en intentie—niet over een bewezen succesvolle break-in via dat specifieke pad.

Wat je als verdediger nu kunt doen

Het herstelplan uit het Hunt.io-onderzoek vertaalt zich naar een praktische checklist voor organisaties met edge-apparaten en systemen die authenticatie en remote access ondersteunen.

1) Patch of verifieer FortiGate SSL-VPN tegen CVE-2024-21762

Controleer of je FortiGate SSL-VPN-apparaten zijn gerepareerd of dat je veiligheidsmaatregelen correct zijn uitgevoerd. Als patchen niet direct kan, adviseert Fortinet volgens het rapport om SSL-VPN uit te schakelen. Alleen web mode uitschakelen is volgens de advisory geen toereikend alternatief.

2) Zoek naar MeshCentral agents die je niet hebt geïnstalleerd

Ga na of er MeshCentral-agents draaien die niet door jouw IT-team zijn geplaatst. Kijk ook naar management- of control-servers die je niet herkent en let op afwijkende communicatiepatronen.

3) Draai gecompromitteerde credentials om

Rotatie is essentieel, omdat patching een reeds geïnstalleerde agent of gekopieerde secrets niet automatisch “terugdraait”. Hunt.io noemt expliciet het rouleren van onder meer SSH-keys, database- en RADIUS-wachtwoorden, VPN-certificaten en applicatiegeheimen.

4) Hunt naar verborgen manieren om terug te komen

Omdat de aanvaller web shells en extra SSH-keys kon inzetten, moet je actief zoeken naar indirect bewijs van persistentie. Denk aan onverwachte SUID-bestanden, aanwezigheid van web shells, wijzigingen in SSH-keys en nieuwe remote-management componenten.

5) Preserveer logs en bewijs vóórdat je opschoont

In deze casus was er een script dat logs wilde wissen en tools wilde verwijderen. Dat betekent: stel eerst forensisch materiaal veilig (logs, configuraties, bestanden en netwerkdata) voordat je “cleanup” uitvoert. Daarmee voorkom je dat je achteraf niet meer kunt bewijzen wat er precies is gebeurd.

Detectiepunten uit het rapport (indicaties)

Het rapport noemt verschillende indicators, deels in “defanged” vorm. Voor je eigen monitoring zijn dit relevante aanknopingspunten om naar te zoeken:

  • IP-adres: 92.63.180[.]133 (open directory op poort 8888; callback via poort 9443)
  • Domein: www.ayuthayatech[.]com (MeshCentral control server)
  • MeshCentral group: TH-3BB
  • Persistency paths: /usr/local/bin/.rc (verborgen backdoor) en /usr/local/mesh_services/meshagent/
  • Targets: mail.3bb.co[.]th en agent.3bb.co[.]th

Vergelijkbare aanpak: credential-hunting en patchdiscipline

Dit incident past in een bredere lijn waarin aanvallers eerst systeemtoegang proberen te krijgen via kwetsbaarheden of edge-componenten, en vervolgens credential-hunting doen om hun positie uit te breiden. Ook elders zagen we dat aanvallers zich verplaatsen richting interne portals en authenticatiecomponenten.

Als je wilt verdiepen in wat er praktisch komt kijken bij het valideren en prioriteren van blootstellingen, sluit dit onderwerp aan bij zo kies je actie bij exposure-issues. Daarnaast kan de aanpak na een aanval op confidential computing je helpen bij het bepalen van vervolgstappen wanneer de impact onzeker is.

Conclusie

De casus rond de MeshCentral backdoor bij 3BB toont hoe remote-managementtools misbruikt kunnen worden om langdurige controle te krijgen. De aanval combineert verankering (MeshCentral-agent), uitbreiding (SSH-wachtwoordpogingen en credential searches) en sporen wissen, met als doel uiteindelijk subscriber-gerelateerde systemen zoals RADIUS.

Voor verdedigers draait de reactie om vijf kernacties: repareer of verifieer kwetsbare edge-systemen, detecteer ongeautoriseerde agents, roteer potentiële secrets, hunt naar verborgen persistentie en preserveer bewijs vóórdat je opschoont. Door deze stappen systematisch te doorlopen, verklein je de kans dat een aanvaller blijft terugkomen via “normaal” ogende beheerkanalen.

Bron: https://thehackernews.com/2026/09/3bb-attacker-used-meshcentral-backdoor.html