Password spray og brute force: mønstre i loginloggen

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

Password spray og brute force er automatiserede forsøg på at gætte adgangskoder. Brute force prøver mange koder mod én konto, password spray prøver få almindelige koder mod mange konti, og credential stuffing prøver kombinationer af brugernavn og kode fra tidligere lækager. I loginloggen ses de som mønstre af mislykkede forsøg. Det afgørende spørgsmål i en sag er næsten aldrig, om der var forsøg, for det er der hos de fleste. Det er, om et af forsøgene lykkedes, og hvad der skete bagefter.

Haster det? Entra ID gemmer loginlogs i 7 eller 30 dage efter licens, og domænecontrollerens sikkerhedslog kan overskrives på timer, når et angreb fylder den op. Se akut forensisk sikring; hastesager koster ekstra.

Artiklen handler om mønstrene. Hvordan de enkelte felter og fejlkoder i Microsofts loginlog læses, står i Entra ID sign-in logs.

De tre mønstre

Brute force · Mange fejlede forsøg mod én konto på kort tid, ofte fra få adresser; kan udløse kontolåsning
Password spray · Et eller få forsøg pr. konto mod mange konti, gentaget med timers eller dages mellemrum; sjældent låsning
Credential stuffing · Forsøg mod konti med netop de brugernavne, der findes i lækkede datasæt, ofte med høj træfprocent på kendte konti

Password spray er bevidst langsom og fordelt. Den holder sig under grænsen for låsning og bruger ofte mange forskellige IP-adresser, så hver adresse kun står for få forsøg. Mønstret ses derfor først, når loggen grupperes på tværs af konti, ikke når den læses pr. bruger.

Kilder

Microsoft Entra ID-loginlogs med resultat, fejlkode, klientapp, protokol, IP-adresse og brugeragent. Fejlkoder for forkert adgangskode, ukendt bruger og låst konto er de centrale: 50126 for forkert brugernavn eller adgangskode, 50034 for en konto, der ikke findes i tenanten, og 50053 for en konto, der er låst efter for mange forsøg. Kode 50053 bruges også, når et login blokeres, fordi det kommer fra en adresse med kendt skadelig aktivitet, så fejlteksten skal læses med. → Entra ID-loginlogs: felter, fejlkoder og fortolkning
Windows’ sikkerhedslog på domænecontrollere og servere: mislykkede logons med logontype og fejlårsag, Kerberos-fejl ved forhåndsgodkendelse og hændelser for låste konti. → Event 4624 og 4625: logontyper og fortolkning og Kerberos og NTLM: autentificeringsspor
VPN-, firewall- og RDP-gateway-logs, hvor forsøg mod eksponerede tjenester typisk lander. → VPN-logs: sessioner og tildelte adresser
Google Workspace og andre identitetsudbydere har tilsvarende loginlogs med lidt andre felter.
Risikohændelser fra identitetsudbyderen, hvis licensen omfatter dem.

Sådan findes mønstret

Eksportér loginloggen for hele tenanten eller domænet i den relevante periode, ikke kun for den konto, sagen handler om. Gruppér derefter:

Pr. IP-adresse: Hvor mange forskellige konti har hver adresse forsøgt? En adresse med forsøg mod mange konti er et spray-kendetegn.
Pr. konto: Hvor mange fejl har hver konto, og fra hvor mange adresser?
Pr. tidsvindue: Kommer forsøgene i bølger med jævne mellemrum? Spray kører ofte i runder.
Pr. protokol og klient: Forsøg via ældre protokoller, der ikke understøtter totrinsgodkendelse, er særligt interessante, fordi en korrekt kode her kan give adgang uden yderligere godkendelse.
Pr. brugeragent: Automatiserede værktøjer bruger ofte de samme eller usædvanlige brugeragenter.

Normalisér tidszoner og felter først, især hvis loggene kommer fra flere systemer. → Normalisering af logdata

Lokale miljøer og eksponerede tjenester

I et lokalt Active Directory ser mønstret anderledes ud. Forsøg mod en eksponeret VPN eller en RDP-gateway ender som godkendelsesforespørgsler på domænecontrolleren, og her registreres de typisk med gatewayens adresse som kilde, ikke angriberens. Den egentlige kildeadresse står kun i gatewayens eller VPN-enhedens egen log. Derfor skal de to kilder kobles på tidspunkt og brugernavn, før det kan siges, hvor forsøgene kom fra. → Active Directory og domænecontroller-logs

Sikkerhedsloggen på domænecontrolleren har ofte begrænset størrelse og overskrives hurtigt, når der kommer mange fejlede forsøg. Et vedvarende angreb kan i sig selv skubbe de ældre hændelser ud. Kontrollér den ældste hændelse i loggen, og notér, hvis perioden før den ikke er dækket.

Hvilke brugernavne blev forsøgt?

Listen over forsøgte brugernavne siger noget om, hvor angriberen har sine oplysninger fra. Forsøg mod brugernavne, der ikke findes, tyder på gætværk ud fra et navnemønster. Forsøg kun mod eksisterende konti, herunder konti, der ikke fremgår af hjemmesiden, kan tyde på, at listen stammer fra et tidligere udtræk eller en lækage. Det er en indikation, ikke en konklusion, men den kan være relevant for, hvor undersøgelsen skal fortsætte.

Det vigtige fund: succes efter fejl

Når mønstret er beskrevet, skal der ledes efter:

et vellykket login fra en af de adresser, der også har mislykkede forsøg,
et vellykket login med korrekt kode, men afvist af totrinskrav eller en politik, som viser, at koden var gættet, selv om adgangen blev stoppet,
en konto, hvor fejlene pludselig stopper, fordi den rigtige kode er fundet og brugt fra en anden adresse.

Det andet punkt overses ofte. Et login, hvor den første faktor lykkedes, men totrinskravet ikke blev opfyldt, er dokumentation for, at adgangskoden var kendt. Det har betydning for, hvilke konti der skal have ny kode, selv om ingen kom ind.

Finder du et vellykket login, skal undersøgelsen skifte spor: Hvad gjorde kontoen bagefter? Det er beskrevet i BEC-undersøgelse i Microsoft 365.

Sikring

Eksportér loginloggen for hele perioden og alle konti, før den udløber, og gem den i det rå format, tjenesten leverer. Tag de lokale logs fra domænecontrollere, VPN og gateways med, og notér for hver kilde den ældste og nyeste hændelse. Beregn hashværdier af eksporterne, og registrér, hvem der hentede dem og hvordan. Ændringer som kodeskift, blokering af adresser og nye politikker noteres med tidspunkt, så det bagefter kan ses, hvilke forsøg der kom før og efter.

Fejlkilder

Brugerens egne fejl. En mobilenhed med en gammel kode kan generere hundredvis af fejlede forsøg efter et kodeskift. Det ligner brute force, men kommer fra brugerens egen enhed og kendte adresse.
Tjenestekonti og scripts med udløbne koder giver vedvarende fejl fra interne adresser.
Fælles udgående adresser. Forsøg fra en cloududbyders adresser kan komme fra mange uafhængige kilder.
Kontolåsning i skyen sker ofte kun mod ukendte adresser, så en låsning udefra påvirker ikke nødvendigvis brugeren indefra. Loggen viser låsningen, men ikke altid, hvilke kilder den gjaldt for.
Prøveudtræk. En eksport med maksimalt antal rækker kan afskære en del af perioden uden at sige det. Kontrollér, at første og sidste tidsstempel dækker hele perioden.
Opbevaring. Mislykkede logins er mange og fylder; de forsvinder med samme opbevaringstid som resten. I Entra ID var den på tidspunktet for gennemgangen (oktober 2026) 7 dage uden premiumlicens og 30 dage med.

Hvad mønstret kan og ikke kan bevise

Loggen kan vise, at der var automatiserede forsøg, mod hvilke konti, fra hvilke adresser og med hvilket resultat. Den kan vise, om og hvornår en kode blev gættet, og om totrinsgodkendelse eller politikker stoppede adgangen. Den kan ikke identificere, hvem der stod bag adresserne, og den kan ikke i sig selv vise, at en svag kode var årsagen, hvis adgangen også kan forklares af phishing eller en lækket kode. Fravær af mislykkede forsøg før et vellykket login peger snarere mod, at koden var kendt i forvejen.

Dokumentation

Beskriv i rapporten, hvilke logkilder og perioder der er analyseret, hvordan der er grupperet, og hvilke tærskler der er brugt til at kalde noget et mønster. Tal i rapporten skal komme direkte fra eksporten og kunne genskabes af en anden. Læg de rå eksporter med hashværdier i bilag, og vis de vigtigste poster, især første succes efter fejl, i en kort tabel med tidspunkt i UTC, konto, adresse, protokol og resultat. Den grundlæggende forklaring af loginlogs for ikke-teknikere findes på digitalbevissikring.dk.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: AiTM-phishing: kendetegn på stjålne sessioner i loginloggen · Lookalike-domæner: registreringsdata og certifikatlogs som dokumentation

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik