Wie internetgerichte netwerkapparatuur beheert, moet extra alert zijn op SSH-aanvallen zonder normale inlog. De MikroTrick chain laat zien hoe twee RouterOS-kwetsbaarheden samen kunnen leiden tot volledige administratieve controle, zelfs wanneer een aanvaller geen wachtwoord, geen SSH-key en geen afgeronde authenticatie nodig heeft.
In dit artikel lees je wat er precies misgaat, welke sporen je kunt controleren en welke stappen je meteen na het patchen moet uitvoeren.
Wat is de MikroTrick chain precies?
De MikroTrick chain is de naam die CERT Polska gebruikt voor een aanvalsketen die is gebaseerd op twee beveiligingsproblemen in MikroTik RouterOS SSH. Het gaat om:
- CVE-2026-67279: een fout in de SSH state-machine rond authenticatieverwerking.
- CVE-2026-86060: een argument-injectiebug in het RouterOS loginproces.
Door deze fouten te combineren kunnen aanvallers een router in een fase brengen die normaal alleen na succesvolle login beschikbaar komt. Vervolgens wordt de loginroutine zo aangestuurd dat de aanvaller toegang krijgt tot een volledig geprivilegieerde shell.
Hoe werkt de aanvalsketen stap voor stap?
SSH kent in grote lijnen drie opeenvolgende stappen: eerst komt de versleutelde verbinding tot stand, daarna volgt authenticatie, en pas daarna wordt een sessie geopend om opdrachten uit te voeren. In een correcte flow bevestigt de server expliciet dat authenticatie geslaagd is (door een succesbericht).
De MikroTrick chain doorbreekt deze logica op twee punten.
1) CVE-2026-67279: authenticatie checken wordt omzeild
Met CVE-2026-67279 kan een aanvaller tijdens de authenticatiefase een sleutel-heronderhandeling starten. Na het afronden daarvan gaat kwetsbare RouterOS door naar de commandofase, zonder dat het systeem de identiteit nog echt bevestigt.
Belangrijk: deze stap creëert op zichzelf geen geauthenticeerde sessie en verleent niet direct rechten. Maar de aanvaller bereikt wél een overgang die in normaal gedrag pas na een geslaagde login zou plaatsvinden.
2) CVE-2026-86060: argument-injectie geeft volledige adminrechten
De tweede schakel is CVE-2026-86060. Bij het starten van de loginroutine (/nova/bin/login) ontvangt het systeem de gebruikersnaam en een privilege-niveau via command-line argumenten vanuit de SSH-daemon.
Omdat het RouterOS loginprogramma niet eerst de gebruikersnaam correct valideert, kan een aanvaller een waarde met een hyphen aanleveren die door het programma wordt gezien als een optie in plaats van als naam. In de analyses wordt als voorbeeld -2 gebruikt.
Het loginprogramma behandelt die waarde vervolgens als instructie om zijn identiteit en privilege-informatie te lezen uit een bestandsdescriptor die gekoppeld is aan de SSH-terminal. Doordat de aanvaller via het SSH-kanaal al de gewenste identiteit en privileges kan “schrijven” voor die terminal, accepteert de loginroutine die gegevens en opent een console met volledig administratieve privileges.
Wanneer werd misbruik gezien en welke updates zijn beschikbaar?
In de beschikbare analyse staan log- en tijdlijnen die wijzen op misbruik voor de fixes beschikbaar waren. Er wordt verwezen naar bewijslast die minstens dateert van 2 september, dus ongeveer een dag vóór MikroTik patches uitbracht.
De patches waar in de bron naar wordt verwezen verschijnen in RouterOS versies 6.49.21, 7.23.4 en 7.24.2. In het algemeen betekent dit: als je deze RouterOS-versies nog niet draait, is upgraden je eerste en belangrijkste stap.
Welke sporen laat de MikroTrick chain achter?
Een ketenaanval is vaak lastig te detecteren met generieke regels, maar deze aanval blijkt wél een herkenbaar logpatroon te hebben. CERT Polska noemt een specifieke mislukte loginpoging als “onderscheidend spoor”.
Volgens CERT Polska zie je in logs onder meer:
- Username: -2 in SSH login logs (mislukte poging)
- Account: ops in de groep met volledige privileges
- Observed IP’s in relevante gevallen, waaronder 82.192.72.4 (succesvolle aanvallen) en 103.102.31.18 (pogingen)
Daarnaast zijn er aanwijzingen dat de aanval een reeks gebeurtenissen op een apparaat kan triggeren, zoals een geforceerde heronderhandeling, een sprong naar de kanaalfase en vervolgens een request om een gebruiker te creëren (met de betreffende privileges). In sommige gevallen crashte het SSH-proces voordat het commando volledig afliep, maar latere meldingen bevestigden dat de beoogde “ops”-account daadwerkelijk is aangemaakt op getroffen systemen.
Na patchen: controleer “Flagged status” en kijk verder dan alleen een vinkje
Patchen voorkomt nieuwe exploitatie, maar kan niet automatisch ongedaan maken wat al is gebeurd. Daarom adviseren CERT Polska en MikroTik om na een update gericht te controleren.
Een van de controles na het upgraden is het checken van de Flagged status door in RouterOS de volgende opdracht te gebruiken: /system/device-mode/print.
Let op: de flagged mechaniek detecteert niet alle sporen van mogelijke compromittering. Het ontbreken van een flagged status is dus geen garantie dat het apparaat veilig is.
Praktische checklist voor incident response
Als je het risico wilt verkleinen of een mogelijke aanval wilt afhandelen, houd dan deze aanpak aan.
1) Isoleer het apparaat bij verdachte indicatoren
Staat de router in de logs of inventaris verdacht (zoals username -2 of een account in de volle privilege-groep)? Isoleer het toestel dan om verdere communicatie te stoppen.
2) Behoud logs en configuratie
Voordat je opschoont, wil je bewijsmateriaal behouden. CERT Polska adviseert om logs en configuratie te bewaren zodat je het incident later kunt analyseren.
3) Reset en rebuild vanuit een vertrouwde basis
De aanbeveling is om het systeem te voorzien van een factory reset en vervolgens opnieuw op te bouwen met een vertrouwde configuratie. Een “terugzetten” van een backup afkomstig van een mogelijk aangetast apparaat wordt afgeraden.
4) Credential hygiene: verander alles
Wijzig alle wachtwoorden, keys en gerelateerde referenties. Ook als je denkt dat de inbraak beperkt is gebleven: door de keten kan een aanvaller al vroeg in het proces controle krijgen.
5) Extra aandacht voor configuratie- en persistence-sporen
Naast de kernindicatoren (zoals -2 en de ops-account) is het verstandig om te zoeken naar onbekende gebruikers, scripts of scheduler entries, tunnels, proxies, onverwachte .rif diagnostische bestanden en ongebruikelijke “fetch” activiteit.
Welke netwerkinstellingen verhogen het risico?
De MikroTrick chain kan alleen werken wanneer SSH bereikbaar is voor de aanvaller. In de bron wordt aangegeven dat MikroTik zegt dat de standaard thuisconfiguratie SSH niet naar het internet blootstelt.
Het risico neemt toe als beheerders firewallregels hebben aangepast of wanneer apparaten beheerd worden via SSH vanuit onbetrouwbare netwerken. Met andere woorden: “internet-exposed” SSH is de versneller.
Snelle duiding: waarom dit type ketenaanval extra belangrijk is
Deze case onderstreept een terugkerend patroon in security: afzonderlijke bugs hoeven niet “verwoestend” te zijn, maar gecombineerd kunnen ze wel tot volledige controle leiden. Dit past bij bredere inzichten over hoe aanvallers logische zwakheden in authenticatie- en validatielogica benutten.
Voor organisaties die ook met andere supply chain- of compromisrisico’s te maken hebben, kan het nuttig zijn om tegelijk naar upstream risico’s en downstream impact te kijken. Bijvoorbeeld: bij pakketmanipulatie of gecompromitteerde componenten geldt hetzelfde principe dat je niet alleen naar de directe oorzaak moet kijken, maar ook naar de keten van effecten. Zie ook gecompromitteerde MemTensor npm en PyPI pakketten voor hoe aanvallen via softwarecomponenten kunnen doorwerken.
Conclusie
De MikroTrick chain toont hoe twee SSH-kwetsbaarheden in MikroTik RouterOS samen kunnen zorgen voor overname van internetgerichte routers zonder wachtwoord, SSH-key of volledige authenticatie. De kern is dat authenticatiecontrole wordt omzeild en dat argument-injectie de loginroutine kan sturen naar een geprivilegieerde console.
Upgraden naar de genoemde RouterOS versies is essentieel, maar minstens zo belangrijk is de post-patch controle: check de flagged status, onderzoek logs op de verdachte patronen en voer bij indicaties een incident-respons aanpak uit (isoleren, bewaren, reset/rebuild en credential wijziging). Alleen zo beperk je de kans dat een aanvaller al persistent toegang heeft opgebouwd.
Bron: https://thehackernews.com/2026/09/mikrotrick-chain-let-attackers-take.html
