Overslaan naar inhoud
Nederlands
Neem contact met ons op
  • Er zijn geen suggesties want het zoekveld is leeg.

Geautomatiseerde device code-aanmelding [RULE-1166]

Deze regel detecteert geslaagde device code-aanmeldingen die zijn voltooid door een geautomatiseerde HTTP-client in plaats van een browser. Device code flow is een authenticatiemethode voor apparaten die niet eenvoudig een aanmeldpagina kunnen tonen, zoals een smart TV, een vergaderzaalsysteem of een command-line tool. Het apparaat toont een korte code, de gebruiker voert die code in op een tweede apparaat, en het eerste apparaat ontvangt een token.

De regel kijkt naar de client die de aanmelding heeft voltooid. Browsers, Office-applicaties en mobiele apps identificeren zich op een herkenbare manier. Scripting libraries en HTTP-toolkits doen dat anders, en Attic markeert device code-aanmeldingen die door dat soort client zijn afgerond. Daarnaast worden de IP-adressen van de aanmelding vergeleken met de recente aanmeldgeschiedenis van het account, zodat de melding kan aangeven of de sessie ook afkomstig is van infrastructuur die dit account niet eerder heeft gebruikt.

Rationale

Device code phishing is een van de meest effectieve aanvallen op Entra ID geworden, omdat er nooit om een wachtwoord wordt gevraagd. De aanvaller start zelf een device code flow en stuurt het slachtoffer vervolgens de resulterende code met een geloofwaardige reden om die in te voeren: een Teams-meeting die niet wil starten, een nieuw apparaat dat geactiveerd moet worden, een IT-supportverzoek. Het slachtoffer meldt zich aan op de echte Microsoft-pagina, keurt de echte prompt goed en voltooit MFA. Alles wat het slachtoffer ziet is authentiek. Het token gaat echter naar de aanvaller.

Omdat de resulterende sessie volledig geauthenticeerd is en aan MFA voldoet, ziet die er verderop vrijwel overal legitiem uit. Daarom is juist de client het waard om in de gaten te houden. Een persoon die een device code-aanmelding voltooit, doet dat in een browser. Wanneer de flow in plaats daarvan door tooling wordt aangestuurd, is dat een sterke aanwijzing dat de aanmelding wordt geautomatiseerd in plaats van uitgevoerd door de eigenaar van het account, of dat nu een aanvaller met een phishing kit is of een script dat niemand heeft gedocumenteerd.

Een aanmelding vanaf een IP-adres dat het account recent niet heeft gebruikt, versterkt dat beeld aanzienlijk. Die combinatie maakt deze detectie de moeite waard om snel op te acteren: doorgaans betrapt hij een aanvaller in de eerste minuten dat deze een geldig token heeft, nog voordat er persistence is opgezet.

Opvolging

Voer deze stappen uit om deze detectie adequaat op te volgen:

  1. Valideer of de aanmelding legitiem is: Neem contact op met de eigenaar van het account. Vraag of zij rond het tijdstip van de melding een device code hebben ingevoerd, of iemand hen dat heeft gevraagd, en of zij de applicatie uit de melding herkennen. Een gebruiker die gephisht is, herinnert zich vaak dat er een code is ingevoerd die per e-mail, Teams of telefoon werd aangeleverd.
    • Zo nee (niet legitiem): Beschouw het account als gecompromitteerd. De aanvaller heeft een geldig token, dus alleen een wachtwoordreset is niet voldoende:
      1. Trek alle active sessions in via Entra admin center → Users → [gebruiker] → Revoke sessions. Hiermee wordt het gestolen refresh token ongeldig; dit is verreweg de belangrijkste stap.
      2. Blokkeer sign-in via Entra admin center → Users → [gebruiker] → Block sign-in
      3. Reset het wachtwoord via een out-of-band methode (niet per e-mail naar het gecompromitteerde account)
      4. Check voor persistence: Controleer of de aanvaller:
        • Een nieuw apparaat heeft geregistreerd (zie ook RULE-1167)
        • MFA-methoden heeft toegevoegd of gewijzigd
        • OAuth consent heeft verleend aan applicaties
        • Inbox rules heeft aangemaakt (forwarding, auto-delete)
        • Application credentials heeft toegevoegd (secrets, certificates)
      5. Onderzoek de timeline: Bekijk de Entra ID sign-in logs en de unified audit log voor alle activiteit van dit account sinds de aanmelding. Let op toegang tot mailboxen, downloads uit SharePoint of OneDrive, en toegang tot admin portals.
      6. Escaleer naar IR: Betreft het een privileged account, of heeft de aanvaller tijd gehad om te handelen, neem dan contact op met Attic voor incident response ondersteuning via onze IR Strippenkaart.
    • Zo ja (legitiem): De aanmelding hoort bij automatisering of bij een apparaat dat deze flow daadwerkelijk gebruikt:
      1. Valideer de use case: Stel vast welke tool of welk script het betreft, waar het voor dient en wie de eigenaar is. Interactieve user accounts horen normaal gesproken niet voor automatisering gebruikt te worden.
      2. Best practice: Gebruik een service principal, een managed identity of een workload identity voor automatisering in plaats van een user account. Dat beperkt het blast radius en maakt auditing veel eenvoudiger.
      3. Onderdruk toekomstige meldingen: Is de combinatie goedgekeurd, voeg deze dan toe aan de instelling "Goedgekeurde device code-applicaties" in Attic. De melding bevat de exacte regel die u kunt toevoegen. Keur de specifieke combinatie van gebruiker en applicatie goed in plaats van de gebruiker als geheel, zodat het account voor overige activiteit gemonitord blijft.
  2. Overweeg device code flow volledig te beperken: De meeste organisaties hebben deze authenticatiemethode maar voor een klein aantal accounts of apparaten nodig. Met een Conditional Access policy op authentication flows kunt u device code flow voor alle overige gebruikers blokkeren, waarmee u deze aanvalsroute wegneemt in plaats van alleen detecteert. Dit is de meest effectieve maatregel tegen device code phishing.Attic controleert op deze policy met Blokkeer Device Code Flow Authenticatie (CHK-1172), en biedt een geautomatiseerde fix die de Conditional Access policy voor u aanmaakt.
Meer informatie