af Bhabesh Raj Rai, Associate Security Analyst Engineer

Nylige sårbarheder i forbindelse med eskalering af AD-rettigheder (Active Directory) gør det muligt for standarddomænebrugere at udgive sig for at være domæneadministratorer. Hvis angrebet lykkes, kan administratorer komme i en uønsket situation, hvor de bliver nødt til at rydde op i og genopbygge hele deres AD. Ved hjælp af LogPoint SIEM og SOAR kan administratorer registrere, undersøge og afhjælpe eskaleringer af AD-rettigheder med high fidelity-identifikationer og køreklar playbooks.

Den 9. november 2021 fastlagde Microsoft en række sårbarheder i forbindelse med eskalering af AD-rettigheder, som, når de er kædet sammen, tillader en standarddomænebruger at udgive sig for at være en bruger med udvidede rettigheder, f.eks. en domæneadministrator. Adskillige PoC’er (proof-of-concepts) er offentligt tilgængelige, hvilket gør det muligt for selv en mindre sofistikeret trusselsaktør at kompromittere hele domænet.

CVE-2021-42278 og CVE-2021-42287 er begge eskaleringssårbarheder i Active Directory Domain Services og har en CVSS-score på 8.8. Begge sårbarheder gør det muligt for den angribende at udgive sig for at være en domænecontroller – CVE-2021-42278 bruger computerkonto sAMAccountName-spoofing, og CVE-2021-42287 bruger Kerberos (Privileged Certificate Certificate) PAC-confusion. Administratorer bør sikre sig, at de har anvendt Microsofts KB5008102 til CVE-2021-42278 og Microsofts KB5008380 til CVE-2021-42287 på alle deres domænecontrollere.

Sikkerhedsforsker Charlie Clark har i vid udstrækning redegjort for, hvordan man kan afhjælpe disse sårbarheder. Kort sagt starter angrebskæden med at oprette en ny computerkonto til AD-domænet efterfulgt af en omdøbning af den pågældende computerkonto for at afspejle navnet på en eksisterende domænecontroller, men uden det efterfølgende ‘$’. Derefter sendes en Kerberos TGT-anmodning ved hjælp af det nye computernavn, hvorefter den oprettede computerkonto omdøbes til en vilkårlig værdi. Til sidst afslutter kæden ved at anmode om en Kerberos S4U2self-billet ved hjælp af den hentede TGT. Hvis hvert trin lykkes, vil angriberen få en tjenestebillet til en domænecontroller. Angriberen får en billet, fordi når vi anmoder om en S4U2self-billet ved hjælp af en TGT for en konto, der ikke findes (eftersom vi har omdøbt den), søger KDC automatisk igen ved at tilføje et efterfølgende ‘$’. PoC’er i python og EXE blev tilgængelige efter Clarks offentliggørelse, og selv uerfarne hackere kan nemt kompromittere hele AD-domænet ved hjælp af PoC’erne.

Administratorer skal være opmærksomme på, at for at angrebskæden kan starte, skal en bruger uden de fornødne rettigheder kunne føje en computer til et eksisterende domæne. AD tillader som standard brugere af standarddomæner at føje op til 10 computere til et AD-domæne via attributten MS-DS-Machine-Account-Quota. Vi anbefaler administratorer at ændre attributværdien til nul for alle deres domæner.

LogPoint-kunder kan bruge vores pakke UseCases v5.1.1, der indeholder analyser til sårbarheder i forbindelse med eskalering af AD-rettigheder.

Identifikation af eskaleringer af AD-rettigheder ved hjælp af LogPoint

LogPoint-kunder skal have logkilder til AD Domain Services for at kunne identificere eskaleringer af AD-rettigheder. Som beskrevet ovenfor består angrebskæden af en del trin, hvilket betyder, at der vil blive genereret flere hændelseslogge, efterhånden som angrebet skrider frem. Sikkerhedsanalytikere kan bruge de genererede hændelseslogs til at oprette identifikationer med en høj grad af troværdighed. Vi kan søge efter en oprettelse af en ny computerkonto (EID 4741) efterfulgt af en omdøbning af denne computerkonto (EID 4781) til en ny værdi, der ikke har en efterfølgende ‘$’.

[label=Computer label=Account label=Create] as s1   
followed by   
[label=Account label=Name label=Change target_user="*$" -new_user="*$"] as s2   
within 5 second   
on s1.computer=s2.target_user  
| rename s1.computer as computer, s1.user as user, s2.new_user as new_computer_name 
| chart count() by user, computer, new_computer_name

Søgning efter kontooprettelse efterfulgt af en omdøbning til en ny værdi, der ikke har et efterfølgende ‘$’

Derefter kan vi søge efter omdøbning af en konto for at fjerne det efterfølgende ‘$’ efterfulgt af en Kerberos TGT-anmodning (EID 4768), der gør brug af den omdøbte konto.

[label=Account label=Name label=Change target_user="*$" -new_user="*$"] as s1  
followed by   
[norm_id=WinServer event_id=4768 -user="*$"] as s2  
within 5 second on s1.new_user=s2.user
| rename s1.target_user as old_computer_name, s1.new_user as 
new_computer_name, s1.user as user, s2.source_address as source_address 
| chart count() by user, old_computer_name, new_computer_name, source_address

Søgning efter en ændring af et kontonavn efterfulgt af Kerberos TGT-anmodning ved hjælp af en omdøbt konto

Alternativt kan vi søge efter mistænkelige anmodninger om Kerberos-tjenestebilletter (i dette tilfælde S4U2self), der specificerer en domænecontroller i både tjeneste- og brugerfelter, men sidstnævnte inkluderer ikke det efterfølgende ‘$’.

norm_id=WinServer event_id=4769 service IN WINDOWS_DC
| norm on service <dc:'\S+'>$
| process compare(user, dc) as result
| search result=true
| chart count() by log_ts, user, dc, service, source_address

Kerberos service ticket requests

Søgning efter mistænkelige anmodninger om Kerberos-tjenestebilletter

For at finde den bruger, som man udgiver sig for i S4U2self-anmodningen, kan vi søge efter ovennævnte mistænkelige anmodning om en Kerberos-tjenestebillet efterfulgt af et brugerlogin fra den samme IP-adresse, som fremsatte den mistænkelige anmodning om tjenestebillet.

[norm_id=WinServer event_id=4769 service IN WINDOWS_DC
| norm on service <dc:'\S+'>$ 
| process compare(user, dc) as result 
| search result=true] as s1 followed by 
[norm_id=WinServer event_id=4624] as s2 
within 5 second on s1.host=s2.host and s1.source_address=s2.source_address 
| rename s1.log_ts as log_ts, s2.log_ts as login_ts, s1.host as host, s1.user as user, 
         s1.service as service, s1.dc as dc, s2.user as impersonated_user, s2.source_address as source_address
| chart count() by log_ts, login_ts, user, service, dc, impersonated_user, source_address

Søgning efter en konto, der er blevet efterlignet

I Python PoC’en er der mulighed for at åbne en shell direkte efter en vellykket kompromitteirng, hvilket vi kan se i den nye tjenesteinstallationshændelse. Vi kan se, at tjenesten er oprettet af den bruger, der er blevet efterlignet.

label=Service label=Install path="%COMSPEC%*\\127.0.0.1\C$\*" 
| chart count() by user, file, service, path

suspicious paths in new service installations

Søgning efter mistænkelige stier i nye tjenesteinstallationer

Personer med ondsindede hensigter kan efter at have modtaget tjenestebilletten for en domænecontroller (DC) nemt bruge DCSync-teknikken til at dumpe den pågældende DC’s adgangskodehashes. LogPoint-kunder kan bruge alarmer, der sendes med alarmregelpakken, til at registrere angreb, der normalt bruges af angriberne.

Searching for artifacts of a DCSync attack

Søgning efter artefakter fra et DCSync-angreb

Undersøgelse af aktivitet efter kompromitteringer ved hjælp af LogPoint SOAR 

Administratorer kan bruge LogPoint SOAR til at oprette playbooks, der udfører undersøgelser relateret til angribernes aktivitet efter en kompromittering.
Nogle vigtige trin i undersøgelsen omfatter kontrol af:

  • Oprettelsen af nye brugere til persistens.
  • Et spor efter SYSTEM-shells på den berørte domænecontroller.
  • Mistænkelige tjenesteinstallationer.
  • Dumpning af legitimationsoplysninger af mimikatz.
  • Et DCSync-angreb.

LogPoint SOAR playbook for investigating post-compromise activity after AD privilege escalation

LogPoint SOAR-playbook til undersøgelse af aktivitet efter en kompromittering efter eskalering af AD-rettigheder

Efter udførelse af playbook’en i LogPoint SOAR kan vi i de sager, der er oprettet af playbook’ens komponenter i undersøgelsestidslinjen, danne os et overblik på højt niveau over undersøgelsens resultater.

LogPoint SOAR investigation timeline gathers the results of the investigation

LogPoint SOAR-undersøgelsestidslinjen samler resultaterne af undersøgelsen

Afhjælpning af eskalering af AD-rettigheder

Hvis det lykkedes angriberne at kompromittere hele domænet, skal administratorerne rydde op i og genopbygge hele deres Active Directory helt fra bunden. Det er en kompliceret og manuel opgave, som normalt ikke kan automatiseres fuldstændigt. Administratorer kan implementere følgende afhjælpningstrin for at genopbygge AD’et.

  • Oprette nye legitimationsoplysninger for alle konti.
  • Igangsætte procedurer for nulstilling af KRBTGT-kontoadgangskode.
  • Tjekke for ændringer i gruppepolitik (GPO) og logonscripts.
  • Ibrugtage nye servere til DC’er og flytte FSMO-rollerne til dem, så de gamle DC’er kan tages ud af drift.

Administratorer bør holde øje med sårbarheder i forbindelse med eskalering af rettigheder, fordi ransomware-aktører nemt kan bruge dem til at minimere deres ransomware-implementeringstid. Vi råder til, at man tester PoC’en i et laboratoriemiljø, der har samme konfiguration som deres produktionsmiljø. Herefter kan man teste og finjustere det, man identificerer, for at sikre sig, at logkildekravet for identifikationen opfyldes i stedet for bare at bruge identifikationen i blinde.

 

Kontakt Logpoint

Kontakt os og lær hvorfor markedsledende firmaer vælger Logpoint:

Kontakt LogPoint

Lær mere om Logpoint

Book en demo
Kundesager
Kunde anmeldelser