af Bhabesh Raj Rai, Security Research

I denne måneds programrettelse tirsdag fastlagde Microsoft en sårbarhed over for eskalering af rettigheder af høj sværhedsgrad (CVE-2022-26923) i AD domain services med en CVSS score på 8,8, hvilket er tæt på kritisk. Denne sårbarhed gør det muligt for en autentificeret bruger med lav rettighed at erhverve et certifikat over konti med flere rettigheder såsom domænecontrollere fra AD Certificate Services, hvilket giver mulighed for at øge rettigheden.

Dagen efter fejlrettelsen tirsdag udgav Oliver Lyak– den forsker, der opdagede sårbarheden –tekniske detaljer om sårbarheden på sin blog. Han har også opdateret certipy-værktøjet for at lette udnyttelsen af denne sårbarhed.

For at udnytte denne fejl skal der være en AD CS-server (Active Directory Certificate Services) i domænet. AD CS er Microsofts svar på PKI (public key infrastructure). Domænebrugere kan anmode om et certifikat fra AD CS-serveren baseret på en foruddefineret certifikatskabelon. Dette certifikat kan bruges til forskellige formål, især klientgodkendelse. Det betyder, at brugerne kan anmode om Kerberos TGT ved hjælp af certifikatet som godkendelsesmedium.

AD CS har separate certifikatskabeloner til brugere og computere, og begge kan bruges til klientgodkendelse. Ved brugergodkendelse via certifikat forsøger domænecontrolleren at knytte UPN’en fra certifikatet til en bruger, hvorimod domænecontrolleren ved computergodkendelse via certifikat i stedet forsøger at tilknytte dNSHostName, da computerkonti ikke har et UPN. Opretteren af computerkontoen har rettighederne til at ændre egenskabsværdien for dNSHostName. I modsætning til UPN behøver dNSHostName heller ikke at være unikt i et domæne.  Men når vi ændrer dNSHostName-værdien, opdateres servicePrincipalName-værdien også for at afspejle den nye dNSHostName-værdi.   Så hvis vi opdaterer dNSHostName-egenskaben for en computerkonto for at afspejle en domænecontroller, forsøger domænecontrolleren at opdatere servicePrincipalName, hvilket ville være i konflikt med domænecontrollerens egen servicePrincipalName og dermed give os en indirekte begrænsningsovertrædelse.

Opretteren af computerkontoen har dog også tilladelse til at ændre servicePrincipalName. De nye værdier skal stemme overens med dNSHostName. Vi kan slå denne begrænsningskontrol, hvis vi blot sletter de servicePrincipalName-værdier, der indeholder dNSHostName. Endelig giver domænecontrolleren os mulighed for at opdatere dNSHostName på den nyoprettede computerkonto til en af domænecontrollerne. Domænecontrolleren har ikke behov for at opdatere servicePrincipalName, da vi netop har slettet de værdier, der indeholdt dNSHostName-værdien.

Nu kan vi anmode om et certifikat for den nyligt oprettede computerkonto til AD CS-serveren ved hjælp af maskinskabelonen,  og domænecontrolleren skal indlejre dNSHostName-egenskaben som identifikation. Vi kan derefter godkende ved hjælp af dette certifikat til domænecontrolleren for at få hash fra domænecontrollerens maskinkonto. Ved hjælp af dette hash kan vi enten bruge DCSync-angreb direkte til at dumpe alle hashes fra domænecontrolleren eller få Kerberos TGT fra domænecontrolleren.

Den sidste del af denne angrebskæde ligner meget Petitpotams relæangreb, hvor modstandere videresender en enheds opnåede hash til en AD CS-server og indhenter den pågældende enheds certifikat. Lad os se på, hvordan vi kan identificere udnyttelsen af denne sårbarhed over for eskalering af privilegier i Logpoint.

Påkrævede logkilder

  • Windows AD
  • Windows AD CS
  • Zeek

Administratorer skal sikre, at de har aktiveret følgende indstillinger, fordi de som standard er deaktiveret.

  • Underkategori for audit af certifikattjenester
  • Auditering af “Udsted og administrer certifikatanmodninger” på AD CS-serveren

Identifikation af udnyttelse i LogPoint

Analytikere bør søge efter nye computerkontooprettelser, hvor dns_host-værdien er indstillet til at spoofe en af domænecontrollerne. WINDOWS_DC er en liste, der skal indeholde alle FQDN’er for de domænecontrollere, der arbejder i dit domæne.

1norm_id=WinServer label=Computer label=Account label=Create dns_host IN WINDOWS_DC

Searching for new computer account creations

Søgning efter nye computerkontooprettelser

Analytikere kan også søge efter ulige SPN-værdier i computerkontooprettelser, som modstandere har indstillet til at omgå valideringstjek af dNSHostName som beskrevet tidligere.

1norm_id=WinServer label=Computer label=Account label=Create 2
service="HOST/*RestrictedKrbHost/*"

Searching for SPN manipulations

Søgning efter SPN-manipulationer

Søg derefter efter uoverensstemmelse mellem computer- og dns_host-værdier i computerkontooprettelseshændelser. I nedenstående forespørgsel er domænenavnet knowledgebase.local. Analytikere bør erstatte denne værdi med deres eget domænenavn, før de bruger denne forespørgsel.

1norm_id=WinServer label=Computer label=Account label=Create dns_host=* 2
| process eval("computer_name=rtrim(computer, '$')") 3
| process eval("dns_name=rtrim(dns_host, '.knowledgebase.local')") 4
| process compare(computer_name, dns_name) as result 5
| search result=*

Søger efter uoverensstemmelse mellem computer- og dns_host-værdier i computerkontooprettelseshændelser

Vi råder analytikere til at gennemgå vellykkede certifikatanmodninger for maskinskabelonen inden for tidsrammen for oprettelse af den nye computerkonto.

1norm_id=WinServer label=Certificate label=Request label=Approve 2
attributes="CertificateTemplate:Machine"

Searching for successful certificate requests for Machine template

Søger efter succesfulde certifikatanmodninger for maskinskabelon

Vi kan korrelere de to hændelser ved at udløse en alarm, når en nyoprettet computerkonto, dvs. spoofing af en domænecontroller, anmoder om et Maskinskabeloncertifikat.

1[ norm_id=WinServer label=Computer label=Account label=Create dns_host IN WINDOWS_DC ] as s1 2
followed by [ norm_id=WinServer label=Certificate label=Request label=Approve attributes="CertificateTemplate:Machine" 3
| norm on requester \<requester_account:'\S+'> ] as s2 4
within 1 hour on s1.computer=s2.requester_account 5
| rename s1.log_ts as account_creation_ts, s1.computer as computer, s1.user as user, s1.service as service, s1.dns_host as dns_host, s2.subject as certificate_subject 6
| chart count() by account_creation_ts, computer, user, service, dns_host, certificate_subject

Correlating computer account creation with successful Machine template certificate request

Sammenkædning af oprettelse af computerkonto med vellykket anmodning om maskinskabeloncertifikat

Modstandere kan bruge DCSync-angreb direkte til at dumpe alle hasher fra domænecontrolleren efter at have hentet dens hash. Analytikere kan bruge Zeek til at søge efter mappereplikeringstrafik, der stammer fra systemer, der ikke er domænecontrollere. WINDOWS_DC_IPS er en liste, der skal indeholde alle IP-adresserne på de domænecontrollere, der arbejder i dit domæne.

1norm_id=Zeek event_category=dce_rpc endpoint=drsuapi 2
operation IN ["DRSGetNCChanges", "DRSReplicaSync"] -source_address IN WINDOWS_DC_IPS

Searching for DCSync artifacts in Zeek events

Søger efter DCSync-artefakter i Zeek-hændelser

Anvend rettelserne og afhjælpningerne så hurtigt som muligt

Vi råder administratorer til at læse Microsofts vejledning (KB5014754) om fuldstændig afhjælpning af denne sårbarhed. Vi anbefaler på det kraftigste, at administratorer patcher alle servere, der kører Active Directory Certificate Services og Windows domænecontrollere, som servicecertifikatbaseret godkendelse med opdateringen den 10. maj 2022. Efter opdateringen i maj vil systemerne være i kompatibilitetstilstand. Hvis et certifikat kan knyttes stærkt eller svagt til en bruger, vil godkendelse ske som forventet. Der vil dog blive logget en advarsel, medmindre certifikatet er ældre end brugeren. Hvis certifikatet er ældre end brugeren, mislykkes godkendelsen, og der logges en fejl.

Efter programrettelser har Microsoft rådet administratorer til at holde øje med eventuelle advarsler, der kan forekomme efter en måned eller mere. Hvis der ikke er nogen advarsler, anbefaler Microsoft på det kraftigste, at Full Enforcement Mode aktiveres på alle domænecontrollere, der bruger certifikatbaseret godkendelse. Microsoft opdaterer alle enheder til Full Enforcement Mode inden 9. maj 2023.

Hændelsesrespons på ægte positiver

Administratorer kan tage følgende skridt, når de har registreret en ægte positiv alarm.

  1. Identificer den kompromitterede brugerkonto.
  2. Identificer den berørte domænecontroller og CA-server.
  3. Undersøg spor efter DCSync-angreb.
  4. Undersøg nye brugeroprettelser omkring tidsrammen for persistens.

Kunderne kan køre deres SOAR-playbooks for at afhjælpe kompromitterede brugerkonti og rydde op i de berørte systemer.

 Isolate Host playbook in Logpoint SOAR

Isoler Host playbook i LogPoint SOAR

Hvis det lykkedes angriberne at kompromittere hele domænet, skal administratorerne rydde 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.

På det seneste har der været mange sårbarheder i forbindelse med eskalering af rettigheder, der påvirker både Windows og Linux. Ransomware-aktører er som regel hurtige til at bruge dem til at minimere deres ransomware-udrulningstid. Vi råder virksomhederne til at identificere, om deres AD-miljø er sårbart, og anvende de nødvendige patches og afhjælpninger.

Kunderne kan downloade Windows-applikationen fra hjælpecenteret, der kommer med nyttigt identifikationsindhold.

Detecting high severity AD privilege escalation vulnerability blog visual

Contact Logpoint

Contact us and learn why
industry-leading companies
choose Logpoint:

Contact Logpoint