jekob heidelberg bloghoved

Sådan angribes brugernes adgangskoder - og sådan opdager du at et angreb står på

Jeg har før været inde på "password spraying", og i dette blogindlæg vil jeg uddybe konceptet ud fra både et angrebs- og et forsvarsmæssigt synspunkt og underbygge med et par nyudviklede PowerShell scripts til Proof of Concept. Tanken er at udbrede forståelsen for og kendskabet til denne angrebsmetode, samt give inspiration til hvordan angreb forhindres og opdages.

Vanen tro fokuseres på on-premise Active Directory (AD) og tilhørende NTLM/Kerberos protokoller, som de fleste virksomheder anvender til autentificering af brugerne i miljøet, men svagheder og mulige løsninger er nogenlunde de samme uanset system og protokol.

Denne type angreb foretages f.eks. også nemt mod eksterne tjenester og portaler, som f.eks. VPN, Citrix, TS/RDP eller Outlook Web Access (OWA), der ikke har multi-faktor validering aktiveret. Til sådanne formål findes andre værktøjer, f.eks. THC Hydra og moduler i Metasploit.

Snedig angrebsmetode

Password spraying er et relativt enkelt online brute force angreb som tager udgangspunkt i det faktum, at en betydelig procentdel af vi mennesker anvender uoriginale, velkendte og vidt udbredte adgangskoder og adgangskodemønstre.

I bund og grund handler angrebsmetoden om at forsøge at logge på et givent system på vegne af en eller flere brugere, ud af en større brugermasse, ved at afprøve en eller flere sandsynlige adgangskoder efter hinanden, f.eks. først ”Sommer2016”, derefter ”Juli2016” og til sidst "[firmanavn]2016", for dermed undgå at være utrolig støjende og belastende, som et klassisk brute force angreb, der på kort tid prøver tusindvis af adgangskoder mod miljøets brugerkonti.

Illustration: Jakob H. Heidelberg

Illustrationen ovenfor viser et password spraying angreb. I stedet for at angribe en eller flere brugerkonti med mange forskellige adgangskoder, så angribes mange brugerkonti med et (eller meget få) nøje udvalgte adgangskoder. Angrebet kan udføres af flere runder og giver typisk hurtigt "gevinst".

Du er ikke usårlig

Det er desværre en alt for udbredt misforståelse, at man er usårlig over for denne type angreb. Mange antager fejlagtigt, at de i deres AD-miljø har forhindret denne angrebsmetode i kraft af, at deres ”lockout threshold” politik er aktiveret og sat til f.eks. 5 fejlede loginforsøg, hvorefter brugerkontoen låses.

Men for det første, så kan man som angriber holde sig under de 5 forsøg (det nøjagtige threshold-tal kan enten gættes eller læses af almindelige brugere, f.eks. med kommandoerne "net accounts", gpresult, rsop m.v.), og vente tålmodigt indtil "Badpwdcount" tælleren er på nul igen, når enten brugeren har været logget på, kontoen er låst manuelt op eller tidsperioden for låsning er udløbet.

For det andet, så kan man som angriber med stor sandsynlighed komme ind, eller overtage flere brugerkonti, som måske har andre og flere rettigheder, hvis blot man sender et enkelt loginforsøg pr. brugerkonto med en af de nævnte adgangskoder eller tilsvarende.

Dertil er det efter min erfaring langt fra alle virksomheder, der har systemer som alarmerer rette personer i tilfælde af anomalier ved fejlede loginforsøg. Mange gange er låsning af brugerkonti og fejlede loginforsøg end ikke noget der alarmeres på eller efterforskes nærmere, og har man overhovedet relevante logs, ses de ikke igennem regelmæssigt.

Defensive tiltag

Active Directorys indbyggede beskyttelse mod brute force angreb er således relateret til de individuelle brugerkonti, hver for sig, og ikke set over det samlede miljø.

Man kunne måske ønske sig et standard scenarie, hvor der automatisk udføres defensive handlinger, eksempelvis alarmering, deaktivering af en computerobjekt eller blokering af den IP-adresse som gentagne gange forsøger at autentificere på vegne af et større antal brugere, men i stedet må man selv udvikle (eller tilkøbe) en sådan funktionalitet.

En del kan faktisk klares relativt lavpraktisk og uden større investeringer, f.eks. vha. PowerShell, idet et igangværende brute force (herunder password spraying) angreb vil være synligt på flere niveauer, primært.:

  • Attributterne ”Badpwdcount” og ”LastBadPwd” på hver enkelt brugerkonto, som alene opdateres på PDC'en (Primary Domain Controller Emulator).
  • Security loggen på PDC’en, såfremt denne er konfigureret korrekt til både "success" og "failure" (ikke standard).
  • Netværkstrafikken mellem Domain Controller(e) og klient, forudsat denne kommunikation overvåges.

Procentdel fejlede logins i miljøet

Normalt er det en mindre mængde af ens aktive brugere hvis "Badpwdcount" værdi er forskellig fra 0. Den attribut tæller op (+1) hver gang en bruger indtaster en forkert adgangskode, men nulstilles normalt igen efter succesfuldt login.

Den viden kan anvendes til f.eks. at overvåge procentdelen af miljøets brugerkonti, der har registreret et eller flere fejlede loginforsøg.

Jeg har skrevet et simpelt script til dette formål, som blot returnerer de relevante tal og procentdel af brugerkonti der på tidspunktet for eksekveringen har registreret fejlede loginforsøg.

Illustration: Jakob H. Heidelberg

Det kan forholdsvis nemt omskrives til at foretage alarmering såfremt værdien kommer over en given værdi (typisk få procent, afhængigt af miljøets størrelse, kultur m.v.).

Man kunne også vælge at se på attributten “LastBadPwd” og f.eks. vurdere antallet af fejlede logins indenfor den seneste time eller dag, og sammenligne over tid, for således at reagere på statistiske anomalier.

Hændelser i sikkerhedsloggen

Det er en god idé lige at sikre sig, at man logger relevante hændelser i sikkerhedsloggen på DC'erne.

Det gøres oftest i "Default Domain Controller Policy" under:

  • Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy

Her bør "Audit Account logon events" være aktiveret for både "success" og "failure", hvilket desværre ikke er standardindstillingen.

Der skal selvfølgelig være styr på event loggens størrelse, sikkerhedskopiering, forwarding osv., men det vil jeg ikke komme nærmere ind på her.

Når det er sat op korrekt, vil et password spraying angreb se nogenlunde således ud:

Illustration: Jakob H. Heidelberg

Bemærk de mange Event ID 4625, med “Microsoft Windows security auditing” som kilde og "Logon" som kategori, indenfor et kort tidsrum.

4625 betyder ”An account failed to log on” (audit failure) og hvad man ikke kan se af ovenstående billede er, at de enkelte hændelser indeholder oplysninger om f.eks. "Logon Type" (typisk 3 ved brute force angreb = via netværk), "Workstation Name" og "Source Network Address". Sidstnævnte vil typisk angive angriberens IP adresse (med mindre der er noget proxy i spil) og kan således bruges til yderligere filtrering.

Illustration: Jakob H. Heidelberg

Vi har også Event ID 4776, med "Failure" som status, “Microsoft Windows security auditing” som kilde og "Credential Validation" som kategori. Denne hændelsestype indeholder dog ikke så mange oplysninger som 4625.

I forhold til hændelsesloggen skal det i øvrigt bemærkes, at når DC'erne kører Windows Server 2008 eller nyere, forekommer Event ID 4740 i Security loggen på PDC'en, når en brugerkonto låses ude. Den slags bør man også være ekstra opmærksom på.

For at efterforske om en angriber faktisk er lykkedes med sit foretagende, så er man nødt til at se efter godkendte login events på alle DC’ere i domænet, for disse videresendes ikke til PDC’en, ligesom fejlede logins gør det. Det er "by design", men en smule upraktisk i forbindelse med forensics.

Såfremt angriberen har haft succes, vil man se en Event ID 4624, "An account was successfully logged on", samt Event ID 4776, med "Success" som status.

Et SIEM eller "log correlation" system vil jo være ideelt til at holde øje med ovenstående og alarmere ved anomalier, men har man ikke den slags på budgettet, så kan man komme rimelig langt ved at anvende f.eks. PowerShell til løbende gennemsyn af logs.

Netværksanalyse

Jeg vil ikke her komme ind på identifikation af brute force angreb som følge af analyse af netværkstrafik, men der vil jo eksempelvis være et betydeligt antal indgående login-forespørgsler fra en given IP-adresse til DC'erne i miljøet.

Principielt set bør IDS systemer og produkter som Microsoft Advanced Threat Analytics (ATA) kunne opdage det på denne vis, men jeg har ikke fået testet det endnu. I øvrigt er det langt fra alle virksomheder, der har den slags systemer på indersiden.

Spray-Passwords PoC scriptet

For at demonstrere, hvordan angribere udfører password spraying angreb, har jeg i samarbejde med en god ven udviklet et let læseligt og forhåbentlig lærerigt PowerShell script.

Man behøver ikke være administrator i hverken AD eller på Windows hosten som eksekverer scriptet, ligesom der ikke behøves PowerShell moduler af nogen art. Der anvendes kun built-in funktionalitet (living off the land).

Scriptet modtager input i form af enten en fil med adgangskoder, en URL til en fil med adgangskoder eller en streng med en eller flere adgangskoder. Slår man ”Verbose” til, får man mere detaljerede informationer om status på eksekvering m.v.

Som standard ekskluderer scriptet privilegerede brugerkonti, der som oftest befinder sig i Protected Groups, hvilket betyder, at de får sat deres ”admincount” værdi til 1. Dette gøres for at være ekstra sikker på, at man ikke ved en fejl låser vigtige brugerkonti ude i et live miljø. Vil man også have disse konti med i et angreb, så kan man slå -Admins parameteren til (switch).

Scriptet henter relevante brugeroplysninger for alle aktive brugerkonti fra PDC’en og forsøger at autentificere som dem (impersonation) med de(n) adgangskode(r) der er givet som input. Løbende holdes øje med, at brugerkonti ikke låses ude.

Grunden til at det er PDC’en som kontaktes er, at den som eneste Domain Controller (DC) holder samlet regnskab med antallet af forkerte loginforsøg for hvert enkelt brugerobjekt (attributten ”BadPwdCount”).

Scriptet stopper når alle brugerkonti er løbet igennem med de givne adgangskoder eller brugeren trykker [q] undervejs.

Med Verbose tilstand slået til, og sti til en fil med adgangskoder der skal afprøves, ser en eksekvering således ud:

Illustration: Jakob H. Heidelberg

Kun til gode formål

Eksekvering er 100% på eget ansvar og bør aldrig foregå uden eksplicit tilladelse fra ejeren og/eller administratoren af det pågældende Active Directory (AD) miljø, ideelt set kun i lukkede test-miljøer eller som nøje planlagte red team øvelser (penetration tests).

Scriptet er ikke udviklet til at gå fuldstændig under radaren og holde angrebet helt skjult, selvom der ikke bør være brugerkonti som bliver låst. Tværtimod er det meget støjende i form af netværkstrafik og event logs på DC’er. En dygtig angriber med tålmodighed vil ofte gribe det lidt anderledes an og f.eks. sætte tempoet ned og sprede sit trafikmønster bedre. Ville du opdage det - og i givet fald hvordan?

Scriptet er skrevet således, at man skal være ”insider” og altså have mulighed for at logge på en computer i domænet, men det kan skrives anderledes og der findes andre værktøjer, som ikke har denne begrænsning. En "insider", kan også være i form af et stykke malware på en brugers computer, som opererer i vedkommendes brugerkontekst.

På samme måde som Get-bADpasswords kan Spray-Passwords scriptet bruges defensivt, omend det er noget mere "aggressivt" af natur (intrusive). Eksempelvis kan man finde ud af hvor mange af ens brugere der har ”Sommer2016” som adgangskode – eller helt blank adgangskode, hvilket jeg faktisk stadig opdager i ny og næ (i øvrigt ofte oprettet med et script i stil med dette skrækkelige VBS-script: createuser_nopwd.vbs). Man kan også bruge scriptet til at teste hvorvidt ens logning og alarmering er sat korrekt op eller ej.

Med Verbose slået til, og parameteren -Pass "" (to på hinanden følgende anførselstegn, dvs. en tom tekststreng), ser en eksekvering således ud:

Illustration: Jakob H. Heidelberg

Jeg har gjort en del ud af at kommentere og opbygge scriptet logisk, så det skulle gerne være nemt at læse og forstå. Forslag til forbedringer er meget velkomne via Github.

I håbet om at styrke bevidstheden om kritiske sårbarheder relateret til svage adgangskoder.

/Jakob

Relevante links:

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Hansen

Det ville være fedt hvis du teamede op med en eller flere medskribenter på bloggen, som kunne supplere dine velvalgte vinkler med handson-anvisninger til, hvordan man gør det samme i OS/X Server og Linux-miljøer. Det virker lidt fattigt/ensporet kun at komme med Windows-anvisninger, men jeg har selvfølgelig forståelse for, at det er skribentens egen baggrund, der sætter begræsningen i denne henseende.

  • 0
  • 0
Henrik Høyer

Forhåbentlig en øjenåbner for mange it administratorer rundt om i landet.

Mange tænker (desværre) kun på at sikre deres webservere mod ddos, sql injection osv - rigtig mange tænker ikke på at deres AD er eksponeret via Exchange Active Sync, VPN løsninger osv osv

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize