Apparaat geregistreerd na device code-aanmelding [RULE-1167]

Device code flow is een authenticatiemethode voor apparaten die niet eenvoudig een aanmeldpagina kunnen tonen. Het registreren van een apparaat voegt een nieuwe identiteit aan uw tenant toe die aan de gebruiker gekoppeld is. Elke gebeurtenis op zichzelf is alledaags. Het is de volgorde die deze detectie betekenis geeft.

Vergaderzaalsystemen en conference hardware combineren deze twee acties legitiem, en daarom filtert Attic bekende conference-apparatuur automatisch weg. Daarnaast kunnen goedgekeurde combinaties van gebruiker en applicatie worden gewhitelist in de instelling "Goedgekeurde device code-applicaties", die deze regel deelt met RULE-1166.

Rationale

Device code phishing geeft een aanvaller een geldig token dat aan MFA voldoet, zonder ooit het wachtwoord van het slachtoffer te leren. Wat dat token op zichzelf niet kan, is voortbestaan: trek de sessie in of reset het wachtwoord en de toegang is weg. Een aanvaller die zijn voet tussen de deur wil houden, moet dat tijdelijke token dus omzetten in iets duurzaams, en het registreren van een eigen apparaat is daarvoor de meest betrouwbare manier.

Een door de aanvaller geregistreerd apparaat wordt een blijvende identiteit in uw tenant. Het kan gebruikt worden om te voldoen aan Conditional Access policies die een bekend of compliant apparaat vereisen, het kan zelfstandig nieuwe tokens aanvragen, en bovenal: het blijft werken nadat het wachtwoord van het slachtoffer is gereset. Incident response teams treffen regelmatig aan dat een account keurig is opgeschoond terwijl een door de aanvaller geregistreerd apparaat stilletjes toegang behield. Daarom registreert MITRE device registration als een eigen persistence-techniek (T1098.005).

De waarde van deze regel zit in de correlatie, niet in een van beide gebeurtenissen. Device registrations vinden voortdurend plaats in een gezonde tenant en zijn veel te ruisgevoelig om afzonderlijk op te alarmeren. Device code-aanmeldingen hebben ook legitieme toepassingen. Maar een device code-aanmelding die kort daarop wordt gevolgd door een nieuwe apparaatregistratie door datzelfde account, past op het standaard draaiboek van device code phishing en verdient direct onderzoek. Omdat deze detectie afgaat in de persistence-fase in plaats van de initial access-fase, is deze urgenter dan een device code-melding op zichzelf.

Opvolging

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

Valideer of de registratie legitiem is: Neem contact op met de eigenaar van het account. Vraag of zij rond het tijdstip van de melding een nieuw apparaat hebben ingericht, en of zij daarvoor een device code hebben ingevoerd. Controleer of de apparaatnaam uit de melding overeenkomt met iets dat de gebruiker of uw IT-afdeling herkent. Let op apparaatnamen die een naamgevingsconventie nabootsen maar niet in uw asset administratie voorkomen.
- Zo nee (niet legitiem): Beschouw het account als gecompromitteerd en het geregistreerde apparaat als in handen van de aanvaller. De volgorde is hier belangrijk:
  1. Verwijder eerst het geregistreerde apparaat via Entra admin center → Devices → All devices → [apparaat] → Delete. Doe dit vóór de wachtwoordreset. Een apparaat dat geregistreerd blijft, kan toegang blijven verkrijgen nadat het account verder is opgeschoond.
  2. Trek alle active sessions in via Entra admin center → Users → [gebruiker] → Revoke sessions
  3. Blokkeer sign-in via Entra admin center → Users → [gebruiker] → Block sign-in
  4. Reset het wachtwoord via een out-of-band methode (niet per e-mail naar het gecompromitteerde account)
  5. Check voor overige persistence: Controleer of de aanvaller ook MFA-methoden heeft toegevoegd of gewijzigd, OAuth consent heeft verleend aan applicaties, inbox rules heeft aangemaakt, of application credentials heeft toegevoegd. Een aanvaller die een apparaat heeft geregistreerd, heeft doorgaans meer dan één persistence-mechanisme geprobeerd.
  6. Onderzoek de timeline: Bekijk de Entra ID sign-in logs en audit logs voor alle activiteit van dit account en van het geregistreerde apparaat sinds de aanmelding. Ga na wat het apparaat heeft benaderd nadat het was aangemeld.
  7. Escaleer naar IR: Omdat deze detectie duidt op gevestigde persistence en niet enkel op een verdachte aanmelding, adviseren wij contact op te nemen met Attic voor incident response ondersteuning via onze IR Strippenkaart, zeker bij privileged accounts.
- Zo ja (legitiem): De gebruiker heeft daadwerkelijk een apparaat aangemeld:
  1. Valideer het apparaat: Bevestig dat het apparaat in uw omgeving thuishoort en is vastgelegd in uw asset administratie. Controleer of het aan uw compliance-eisen voldoet.
  2. Valideer de flow: Stel vast waarom een device code nodig was. Als een normale browsergebaseerde aanmelding ook had gewerkt, is dat het corrigeren waard: het beperkt hoe vaak gebruikers eraan gewend raken codes in te voeren die zij toegestuurd krijgen.
  3. Onderdruk toekomstige meldingen: Betreft het terugkerende goedgekeurde automatisering of hardware, voeg de combinatie dan toe aan de instelling "Goedgekeurde device code-applicaties" in Attic. De melding bevat de exacte regel die u kunt toevoegen. Let op: deze instelling wordt gedeeld met RULE-1166.
Overweeg device code flow en device registration te beperken: Met een Conditional Access policy op authentication flows kunt u device code flow blokkeren voor iedereen die het niet nodig heeft. Beoordeel daarnaast wie apparaten mag registreren en vereis MFA voor device registration via Entra admin center → Devices → Device settings. Samen nemen deze twee maatregelen het grootste deel van deze aanvalsroute weg in plaats van die alleen te detecteren.Attic controleert op de eerste maatregel met Blokkeer Device Code Flow Authenticatie (CHK-1172), en biedt een geautomatiseerde fix die de Conditional Access policy voor u aanmaakt.

Meer informatie