Bij moderne aanvallen draait phishing lang niet altijd om het stelen van wachtwoorden via een nep-inlogscherm. De device code phishing-aanpak uit de Skyw4lker-campagne laat zien hoe criminelen zich kunnen mengen in legitieme processen: cloudservices, authenticatiestromen en vertrouwde werkafspraken.
Volgens analyses richt de campagne zich vooral op Amerikaanse organisaties en combineert zakelijke lokdocumenten met een autorisatieflow die uiteindelijk Microsoft 365-tokens oplevert. Voor security teams betekent dit dat het opsporen van de “lure” niet genoeg is: je wilt precies begrijpen wat er gebeurt tijdens de authenticatie en welke infrastructuur daarbij hoort.
Waarom device code phishing zo lastig te detecteren is
Traditionele phishing probeert vaak direct credentials te verzamelen met een nagemaakte pagina. Bij device code phishing start de aanvaller een autorisatieverzoek op een manier die voor het slachtoffer lijkt op een normaal apparaat- of toestemmingsproces. De gebruiker rondt dat verzoek af, waarna de aanvaller kan profiteren van de resulterende tokens.
Het gevolg is dat je in je identiteitstelemetrie soms “gewoon geldige” authenticatie-events ziet, zonder dat de context direct zichtbaar is als verdacht. Daardoor kan een SOC alert zijn op basis van een token-validatie, maar nog steeds missen waar de aanval begon en waarom.
De kernvraag voor onderzoek wordt dan: welke route leidde van het lokdocument naar de authenticatorij en de uiteindelijke toegang?
Zo werkt Skyw4lker in grote lijnen
Skyw4lker begint met een lok die zakelijk en herkenbaar moet voelen. Slachtoffers ontvangen een met een wachtwoord beveiligd document dat is gepresenteerd als contract of voorstel voor een dienst. In omgevingen waar medewerkers vaker vendor agreements, procurementdocumenten of statements of work uitwisselen, kan zo’n scenario geloofwaardig zijn.
Na het openen van het document wordt de gebruiker doorgestuurd naar een pagina die uiteindelijk onderdeel wordt van een Microsoft-authenticatiestroom. Daarbij is het volgens de analyse niet noodzakelijk dat de aanvaller de Microsoft-ervaring perfect nabootst. Het beslissende element is dat de gebruiker een authenticatieverzoek afmaakt dat door de aanvaller is geïnitieerd.
Wanneer de flow is afgerond, kan de aanvaller de uitkomst gebruiken: de Microsoft 365-tokens. Daarmee wordt de aanval praktisch “authentiek” uit het perspectief van het platform, terwijl de initiatie en het doel wel degelijk kwaadaardig zijn.
Welke infrastructuur zit er achter de phishingpagina
Naast de lok speelt ook de technische infrastructuur een rol. In de onderzochte keten zijn aanwijzingen gevonden voor obfuscated JavaScript en een PHP-backend die een victimsessie opbouwt.
Die backend verzamelt onder meer gegevens zoals IP-adres en geolocatie, en communiceert herhaaldelijk met de pagina totdat het authenticatieproces is afgerond. Een eenvoudige statische inspectie van alleen het startdocument kan dan wel een initiële URL tonen, maar verklaart niet volledig wat er gebeurt na interactie met de doorverwijzingen.
In de praktijk betekent dit: de schadelijke logica zit in de combinatie van browsergedrag, redirects, JavaScript-uitvoering en backendcommunicatie. Wie alleen naar “wat staat er in de tekst” kijkt, mist mogelijk het deel dat de echte risico-indicatoren oplevert.
Van initial lure naar bruikbare signalen: wat securityteams moeten doen
Voor je eerste verdedigingslinie is het verleidelijk om te stoppen bij “kwaadaardig vs. veilig” voor een document of link. Bij device code phishing is die stap echter slechts het begin. Je onderzoek moet de aanval door de tijd volgen: document → webinteracties → authenticatieflow → infrastructuur.
De analyse vraagt om betrouwbare indicatoren die je kunt vertrouwen bij detectie. Denk aan URL’s, domeinen, IP-adressen en netwerkpatronen die terug te voeren zijn op de campagne. Daarnaast wil je context: screenshots en gedragsbewijs helpen om te valideren dat een alert echt past bij dezelfde keten.
Met die inzichten kun je vervolgens detecties bouwen die niet alleen reageren op “een geslaagde authenticatie”, maar op de combinatie van stappen die voorafgaan aan het tokenresultaat.
Interactieve sandboxing: bewijs dat je statisch niet ziet
Een belangrijk verschil met statische analyse is dat je bij een interactieve sandbox het document en de links kunt uitvoeren alsof je slachtoffer dat ook doet, in een geïsoleerde omgeving. Daardoor kun je redirects, het gedrag van JavaScript en het netwerkverkeer observeren.
Voor campagnes zoals Skyw4lker is dat cruciaal, omdat het lokdocument slechts de start is. Je moet de keten doorlopen in de browser, het backendverkeer inspecteren en de infrastructuur blootleggen die nodig is om de flow te laten slagen.
Het doel van sandboxing is niet alleen een verdict, maar het opleveren van concrete, herbruikbare observaties voor SOC-analisten en threat hunting: IOCs met context die helpen om sneller te beoordelen of een signaal bij een bestaande campagne hoort.
Threat intelligence inzetten om sneller te reageren
Onderzoek wordt efficiënter wanneer je nieuwe bevindingen kunt vergelijken met bestaande threat intelligence. In de bronanalyse wordt benadrukt dat indicatoren meer waarde krijgen wanneer ze al gevalideerd zijn en direct te koppelen aan eerdere campagnes of infrastructuur.
In onderzoekstrajecten kan dat betekenen dat een deel van de unieke IOCs al eerder is gezien, waardoor je minder tijd kwijt bent aan handmatige uitzoekrondes. Tegelijkertijd heb je juist voor onbekende dreigingen gedragsbewijs nodig om zeker te weten dat je de juiste conclusies trekt.
Ook contextuele verdieping helpt: een lookup op domeinen, IP’s of URL’s kan duidelijk maken of een indicator samenhang heeft met eerder waargenomen kwaadwillige activiteiten. Daardoor kun je alerting en scope sneller aanscherpen.
Waarom dit extra relevant is voor healthcare, manufacturing en technologie
De impact van een gecompromitteerde Microsoft 365-account kan breed zijn. Volgens de analyse kan zo’n toegang leiden tot blootstelling van gevoelige communicatie, intellectueel eigendom, operationele informatie en data waarvoor regulering geldt.
Juist in sectoren als healthcare, manufacturing en technologie is “vroeg herkennen” belangrijk. Niet alleen om direct schade te beperken, maar ook om gerelateerde activiteiten te spotten voordat de aanval doorschakelt naar grotere incidenten.
Daarom is het belangrijk dat teams device code phishing niet alleen zien als een identiteitsprobleem, maar als een ketenprobleem: de aanval gebruikt een legitiem proces als vehikel.
Praktische vervolgstappen voor je detectieproces
Als je wilt verbeteren hoe je device code phishing behandelt, helpt het om je proces langs dezelfde logica op te bouwen als de aanvalsketen.
- Onderzoek de volledige authenticatieflow, niet alleen het eindresultaat van “token ontvangen”.
- Koppel webactiviteit aan het initiële document: waarheen werd de gebruiker gestuurd en welke redirects speelden mee?
- Maak IOCs bruikbaar: verzamel domeinen, URL’s en netwerkindicatoren die herleidbaar zijn naar gedrag.
- Versterk context door threat intelligence lookup en rapportages te gebruiken om relaties tussen incidenten te ontdekken.
- Herbruik bevindingen zodat dezelfde aanval minder vaak opnieuw “van nul” onderzocht hoeft te worden.
Wil je inspiratie voor hoe je dit soort incidenten sneller kunt valideren en verrijken, dan kun je ook kijken naar eerdere berichtgeving over phishing- en authenticatiegerelateerde dreigingen op onze site, zoals patch-updates bij Adobe Campaign Classic (om te begrijpen hoe snel bekende kwetsbaarheden kunnen escaleren) en veiliger secrets voor AI-agents (relevant voor het bredere thema van token- en secretbescherming).
Conclusie
Skyw4lker maakt duidelijk waarom moderne phishingverdediging verder moet kijken dan de eerste pagina of het vermeende inlogmoment. Met device code phishing kan een aanvaller toegang krijgen via een ogenschijnlijk legitieme toestemmings- of autorisatieflow, waarna Microsoft 365-tokens worden benut.
Voor security teams draait de verbetering daarom om keteninzicht: traceer document → webinteracties → authenticatiestroom → infrastructuur. Combineer dat met interactieve sandboxing en context uit threat intelligence, zodat je sneller van verdacht signaal naar betrouwbare detectie gaat.
Bron: https://thehackernews.com/2026/10/american-organizations-under-attack.html
