Detecteren en omzeilen van anti-Adversary-in-the-Middle (AitM) tokens
Auteur
Mike Oude Reimer
Publicatiedatum
Binnen het Advanced Red Teaming (ART) raamwerk is het mogelijk om de initiële fase van een red team engagement over te slaan en te beginnen vanuit een "Assumed Compromise" scenario. Phishingaanvallen worden echter vaak gebruikt om de perimeter te doorbreken. In deze blog zullen we een specifieke detectiemethode bespreken voor Adversary-in-the-Middle-aanvallen (AitM). Deze aanvallen worden vaak gebruikt door kwaadwillende zoals ransomwaregroepen, om toegang te krijgen tot de gegevens van de organisatie. Vervolgens onderzoeken we hoe deze methode omzeild kan worden. Allereerst moeten we begrijpen wat AitM-aanvallen zijn en hoe ze vaak worden gebruikt om inloggegevens en MFA-tokens te stelen.
AitM-aanvallen zijn zeer effectief omdat ze een aanvaller in staat stellen zich te positioneren tussen het slachtoffer en het doelwit, wat een legitieme service kan zijn zoals de Microsoft-inlogpagina. Vanuit deze positie kunnen de aanvallers het netwerkverkeer afluisteren, waarbij ze e-mails, wachtwoorden, cookies en sessietokens kunnen opvangen. Door de authenticatietokens in bezit te hebben, is het mogelijk om MFA te omzeilen. Dit benadrukt het belang van het detecteren en mitigeren van dergelijke aanvallen.
Implementatie van Adversary-in-the-Middle-detectie met Canarytokens
Er is al wat onderzoek gedaan naar hoe bepaalde tokens kunnen worden geïmplementeerd om AitM-aanvallen op de Microsoft loginpagina te detecteren, zoals die van Zolder.io en Clarion. De detectiemethode werkt op basis van een token die geimplementeerd is in een verborgen achtergrondafbeelding binnen het custom CSS-bestand, wat gebruikt kan worden voor de company branding op de Microsoft-inlogpagina. Deze company branding wordt vaak door organisaties gebruikt om hun eigen bedrijfslogo en achtergrond te implementeren. Wanneer een gebruiker zijn e-mailadres invoert op de Microsoft-inlogpagina op https://login.microsoftonline.com, laadt de webbrowser deze company branding bestanden, als deze zijn geconfigureerd.
Het voorbeeld dat in het onderzoek wordt gegeven, vermeldt de CSS-code zoals hieronder weergegeven. Om deze implementatie te testen, hebben we de CSS cloned website functie van https://canarytokens.org gebruikt om een token te verkrijgen. Tijdens de configuratie wordt de waarde van de beschermde website ingesteld op https://login.microsoftonline.com/. Deze blog gaat echter niet over de implementatie van deze tokens. Als je de specifieke stappen wilt weten voor de implementatie, bekijk dan het onderzoek in de eerder gelinkte blogs van Zolder of Clarion. Daar vind je een gedetailleerde uitleg van het proces. Een voorbeeldconfiguratie van zo'n achtergrondafbeelding in de company branding is:
1.ext-footer2{3 background-image: url(‘<YOUR_CANARY_TOKEN>’);4 background-size 0 0;5}
Figuur 1 – Canarytoken in een verborgen achtergrondafbeelding in de Custom CSS.
Normaal gesproken bevat de referer-header bij het inloggen op Microsoft de waarde https://login.microsoftonline.com/. Echter, wanneer een reverse proxytool zoals Evilginx wordt gebruikt, zal de waarde van de referer-header het phishing domein bevatten. In ons voorbeeld is het phishing domein https://login.fake.com, dus de referer-header zal zijn: Referer: https://login.fake.com
Wanneer de Referer-header niet overeenkomt met de waarde die geconfigureerd is voor de beschermde website, zal Canarytokens een melding genereren omdat er een verschil is tussen de Referer-waarde (https://login.fake.com) en het domein dat we hebben beschermd (https://login.microsoftonline.com). Hieronder is een voorbeeld te zien van zo'n melding:
Figuur 2 – Canarytokens melding vanwege het verschil in de referrer-header.
Detecteren van anti-Adversary-in-the-Middle tokens
Als we deze tokens willen omzeilen, moeten we te weten komen hoe deze tokens worden geladen in de webbrowser. Eerst moeten we een manier vinden om de company branding te laden voor de betreffende tenant. Door de whr-parameter aan de URL toe te voegen, kan dit eenvoudig worden gedaan zonder over een geldig e-mailadres te bezitten voor de tenant. In het geval van NVIDIA zou de volledige URL dan zijn: https://login.microsoftonline.com/?whr=nvidia.onmicrosoft.com. Als je de pagina bezoekt, wordt de company branding geladen zonder dat er een aanmeldingsgebeurtenis gegenereerd wordt. Als je echter inlogt met een geldig e-mailadres, wordt er een onvolledige aanmelding geregistreerd.
Figuur 3 – Gebruik van de whr parameter om de company branding in te laden.
Hoe komen we er nu achter waar deze detectietokens zijn opgeslagen? Door het netwerktabblad in de ontwikkelaarstools te openen, kunnen we filteren op het woord customcss. In het voorbeeld van NVIDIA wordt geen aangepast CSS-bestand gebruikt voor de company branding, omdat ze alleen een eigen logo en achtergrond hebben geconfigureerd. In onze ontwikkelaarstenant hebben we echter een aangepaste CSS ingesteld met een canarytoken in de verborgen achtergrondafbeelding, zoals te zien is in het antwoord van de webserver op de customcss hieronder.
Figuur 4 – Detectietoken in de verborgen achtergrondafbeelding.
We hebben een tool geschreven om het vinden van deze tokens te vereenvoudigen. De tool analyseert het CSS-bestand en identificeert alle URL's die erin staan. Als het een aangepast CSS-bestand zonder URL's vindt, zal het de gehele CSS afdrukken voor handmatige controle, om er zeker van te zijn dat er niets over het hoofd wordt gezien. De tool is te vinden op onze GitHub. Hieronder zie je een voorbeeld van onze ontwikkelaarstenant en DHL’s tenant die een aangepaste CSS hebben geïmplementeerd, maar geen URL's in achtergrondafbeeldingen bevat:
Figuur 5 – Geautomatiseerde identificatie van detectietokens in het aangepaste CSS-bestand.
Omzeilen van anti-Adversary-in-the-Middle tokens
Het interessantste deel van ons onderzoek is uitzoeken hoe we deze tokens kunnen omzeilen. Omdat we alle inhoud proxyen, hebben we meerdere oplossingen tot onze beschikking. Eén manier is door de waarde van de referer header te veranderen naar de normale waarde: https://login.microsoftonline.com/. Evilginx lijkt dit momenteel echter niet te ondersteunen. Een andere oplossing is door onze eigen Content Security Policy (CSP) toe te voegen, waardoor de token wordt geblokkeerd om ingeladen te worden op onze geproxyde Microsoft 365 pagina.
We kunnen eenvoudig een nieuwe sub_filter maken in onze Microsoft 365 Evilginx phishlet. Deze sub_filters kunnen worden gebruikt om te zoeken naar bepaalde inhoud in HTML, CSS en JS-bestanden en deze dan te vervangen door een nieuwe waarde. Dit is precies wat we nodig hebben om onze aangepaste CSP toe te voegen aan de geproxyde pagina. Er zijn waarschijnlijk meerdere opties om dit te implementeren, maar in onze aanpak zoeken we naar de eerste <head> HTML-tag en vervangen we deze door een nieuwe. Daarna voegen we een nieuwe meta-tag toe die de CSP bevat en stellen we het MIME-type in om te zoeken naar text/html-inhoud.
Figuur 6 – Sub_filter met de CSP-bypass in de Microsoft 365 phishlet voor Evilginx.
Als je je nog herinnert uit de eerste paragraaf, worden de detectietokens geïmplementeerd via de background-image url(<TOKEN URL>), dus de inhoud die we moeten blokkeren zijn afbeeldingen. In de CSP kan dit worden bereikt met de optie img-src. We willen natuurlijk niet alle afbeeldingen blokkeren, want dan zou de pagina er heel anders uit komen te zien.
Als we gebruik maken van company branding voor een aangepaste logo en achtergrond, dan worden deze geladen vanaf een domein van Microsoft. Er is echter niet slechts één domein, er worden verschillende domeinen gebruikt om verschillende soorten company branding bestanden en Microsofts eigen afbeeldingen te laden. In het onderstaande voorbeeld wordt de NVIDIA-afbeelding geladen vanaf aadcdn.msftauthimages.net:
Figuur 7 - Voorbeeld van een company branding bestand dat wordt geladen vanaf een domein van Microsoft.
Op basis van onze tests met verschillende company branding bestanden, lijken de volgende domeinen te worden gebruikt om de afbeeldingen te laden:
- aadcdn.msftauthimages.net
- aadcdn.msauthimages.net
- aadcdn.msftauth.net
- aadcdn.msauth.net
Als je deze aan de CSP toevoegt, zou je het volgende sub_filter moeten krijgen:
1sub_filters:23- {triggers_on: 'login.microsoftonline.com', orig_sub: 'login', domain: 'microsoftonline.com', search: '<head>', replace: '<head><meta http-equiv="Content-Security-Policy" content="img-src aadcdn.msftauthimages.net aadcdn.msauthimages.net aadcdn.msauth.net aadcdn.msftauth.net">', mimes: ['text/html']}
Figuur 8 – Sub filter voor plaatsen van CSP en blokkeren van tracking pixel
Houd er rekening mee dat als je zoiets als frameless BiTB gebruikt, je ook je eigen phishing subdomeinen (bijv. login.fake.com) moet toevoegen aan de CSP, tenzij je natuurlijk geen afbeeldingen gebruikt op je domein.
We kunnen ook de Microsoft documentatie bekijken om te zien welke domeinen worden gebruikt om inhoud te laden tijdens de portaalauthenticatie, zie: https://learn.microsoft.com/en-us/azure/azure-portal/azure-portal-safelist-urls?tabs=public-cloud#azure-portal-authentication
Conclusie
Company branding bestanden bieden een eenvoudige manier om tokens te implementeren die gebruikt kunnen worden om AitM aanvallen te detecteren. Deze bestanden zijn echter openbaar toegankelijk en kunnen daarom gemakkelijk gecontroleerd worden op de aanwezigheid van deze tokens.
Door gebruik te maken van de Evilginx phishlet filters is het gelukt om een Content Security Policy te implementeren, die blokkeert dat de tokens worden geladen in de geproxyde Microsoft 365 pagina, waardoor deze specifieke AitM detectiemethode wordt omzeild.
Dit is slechts de eerste blog in onze Red Team series. In de volgende blog zullen we het hebben over moderne phishingtechnieken voor Microsoft 365.
Een overzicht van verschillende Microsoft 365 phishing technieken die nog steeds worden gebruikt of die de afgelopen jaren zijn waargenomen.
In dit tweede deel van moderne phishing-technieken voor Microsoft 365 kijken we naar device code phishing.