av Bhabesh Raj Rai, Associate Security Analyst Engineer

De senaste eskaleringssårbarheterna i Active Directory (AD) gör det möjligt för vanliga domänanvändare att imitera domänadministratörer. Om attacken lyckas kan administratörer hamna i ett läge där de behöver rensa och bygga om hela AD. Med hjälp av LogPoint SIEM och SOAR kan administratörer identifiera, undersöka och åtgärda eskalering av AD-privilegier med hjälp av detaljerade detekteringssökningar och färdigpaketerade playbooks.

Den 9 november 2021 åtgärdade Microsoft en rad privilegierade eskaleringssårbarheter i AD som, när de kopplas samman, låter vanliga domänanvändare imitera en högprivilegierad användare som t.ex. en domänadministratör. Det finns ett flertal proof-of-concepts (PoC:er) offentligt tillgängliga som gör det möjligt även för mindre sofistikerade hotaktörer att enkelt kompromettera en hel domän.

CVE-2021-42278 och CVE-2021-42287 är båda privilegieeskaleringssårbarheter i Active Directory Domain Services och har en CVSS-poäng på 8.8. Båda sårbarheterna gör det möjligt för en angripare att imitera en domänkontrollant – CVE-2021-42278 utnyttjar sAMAccountName användarkonto-spoofing och CVE-2021-42287 använder Kerberos (Privileged Attribute Certificate) ”PAC confusion”. Administratörer bör säkerställa att de har tillämpat Microsoft KB5008102 för CVE-2021-42278 och Microsoft KB5008380 för CVE-2022022287 på alla sina domänkontrollanter.

Säkerhetsforskaren Charlie Clark har noggrant beskrivit hur dessa sårbarheter kan utnyttjas av illasinnade aktörer. Enkelt uttryckt börjar attackkedjan med att skapa ett nytt användarkonto i AD-domänen följt av att döpa om det användarkontot för att spegla namnet på en befintlig domänkontrollant men utan det efterföljande ”$”-tecknet. Därefter skickas en Kerberos TGT-förfrågan med det nya datornamnet varefter det skapade användarkontot döps om till ett godtyckligt värde. Slutligen avslutas kedjan med att begära en Kerberos S4U2self-ticket med den hämtade TGT-förfrågan. Om varje steg lyckas får angriparen ett service ticket till en domänkontrollant. Angriparen får en ticket eftersom när en S4U2self-ticket anropas med hjälp av en TGT för ett konto som inte existerar (eftersom namnet har ändrats) söker KDC automatiskt igen genom att lägga till ett efterföljande ”$”-tecken. PoC:er i python och EXE blev tillgängliga efter Clarks avslöjande och även mindre skickliga angripare kan enkelt kompromettera en hel AD-domän med hjälp av dessa PoC:er.

Administratörer bör notera att för att angreppskedjan ska kunna starta måste en icke-privilegierad användare kunna lägga till en dator i en befintlig domän. Som standard tillåter AD att vanliga domänanvändare lägger till upp till 10 datorer i en AD-domän genom attributet MS-DS-Machine-Account-Quota. Vi rekommenderar att administratörer ändrar attributvärdet till noll i alla sina domäner.

LogPoint-kunder kan använda vårt paket UseCases v5.1.1 som innehåller analyser för privilegieeskaleringssårbarheter i AD.

Identifiera privilegieeskalering i AD med hjälp av LogPoint

För att kunna identifiera privilegieeskalering i AD måste LogPoint-kunder ha loggkällor för AD Domain Services. Som beskrivits ovan består angreppskedjan av ett flertal steg, vilket innebär att flera händelseloggar genereras allt eftersom angreppet fortskrider. Säkerhetsanalytiker kan använda de genererade händelseloggarna för att skapa detaljerade detekteringar. Vi kan söka efter skapandet av ett nytt användarkonto (EID 4741) följt av namnändring av kontot (EID 4781) till ett nytt värde som inte har ett efterföljande ”$”.

[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ökning efter kontoskapande följt av namnbyte till ett nytt värde som inte har ett efterföljande ”$”

Därefter kan vi söka efter namnändring av ett konto för att ta bort efterföljande ”$” följt av en Kerberos TGT-förfrågan (EID 4768) som använder det omdöpta kontot.

[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öka efter ändring av ett kontonamn följt av en Kerberos TGT-förfrågan som använder det omdöpta kontot

Alternativt kan vi söka efter misstänkta förfrågningar om service tickets från Kerberos (i detta fall S4U2self) som specificerar en domänkontrollant i både service- och användarfälten, men den senare inkluderar inte ett efterföljande ”$”-tecken.

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öka efter misstänkta Kerberos service ticket-förfrågningar

För att hitta användaren som imiteras i S4U2self-förfrågan kan vi söka efter ovan nämnda misstänkta Kerberos service ticket-förfrågan följt av en användarinloggning från samma IP-adress som utförde misstänkt service ticket-förfrågan.

[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öka efter ett imiterat konto

Python PoC har möjlighet att öppna en shell-instans direkt efter framgångsrik exploatering vilket vi kan se i den nya tjänstinstallationshändelsen. Vi kan se att tjänsten skapades av den imiterade användaren.

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öka efter misstänkta sökvägar i nya installationer av tjänster

Angripare kan efter att ha fått en service ticket från en domänkontrollant (DC) enkelt använda DCSync-tekniken för att dumpa den domänkontrollantens lösenordshashar. LogPoints kunder kan använda de larm som ingår i paketet Alert Rules för att identifiera attackmetoder som angripare ofta använder.

Searching for artifacts of a DCSync attack

Söka efter artefakter från en DCSync-attack

Undersöka aktiviteter efter intrång med hjälp av LogPoint SOAR 

Administratörer kan använda LogPoint SOAR för att skapa playbooks som utför undersökningar för att identifiera aktiviteter som utförs efter ett framgångsrikt intrång.
Några viktiga steg i undersökningen är att kontrollera:

  • Skapandet av nya användare för varaktighet.
  • Spår av eventuella SYSTEM shell-instanser på den berörda domänkontrollanten.
  • Misstänkta installationer av tjänster.
  • k. ”Credential dumping” genom mimikatz.
  • En DCSync-attack.

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

LogPoint SOAR playbook för undersökning av aktiviteter efter framgångsrikt intrång genom eskalering av AD-privilegier

Efter exekvering av motsvarande playbook i LogPoint SOAR kan vi se de fall som skapats av playbookens komponenter i utredningens tidslinje för att få en detaljrik översikt över undersökningens resultat.

LogPoint SOAR investigation timeline gathers the results of the investigation

LogPoint SOAR-undersökningens tidslinje samlar in resultaten av utredningen

Åtgärda eskalering av AD-privilegier

Om angriparna lyckas kompromettera hela domänen måste administratörerna rensa och bygga om hela Active Directory från grunden. Att göra detta är en komplicerad och manuell uppgift och kan i regel inte automatiseras helt. För att återuppbygga AD kan administratörer implementera följande åtgärdssteg.

  • Skapa nya inloggningsuppgifter för alla konton.
  • Initiera rutiner för återställning av KRBTGT kontolösenord.
  • Kontrollera om det finns ändringar i gruppolicy (GPO) och inloggningsskript.
  • Driftsätta ”färska” nya servrar som domänkontrollanter och överföra FSMO-rollerna till dem så att de gamla domänkontrollanterna kan tas ur drift.

Administratörer bör vara uppmärksamma på privilegieeskaleringssårbarheter eftersom ransomware-aktörer enkelt kan använda dem för att minimera installationstiden för utpressningstrojaner. Vi rekommenderar att IT-säkerhetsexperter testar PoC:n i en labbmiljö som har samma konfiguration som produktionsmiljön. IT-säkerhetsexperter kan testa och finjustera sina detekteringar och vara säkra på att kravet på loggkälla för detekteringen uppfylls istället för att blint använda detekteringen.

 

Kontakta Logpoint

Kontakta oss och få information om varför branschledande företag väljer Logpoint:

Kontakta Logpoint

Learn more about Logpoint

Book a demo
Customer cases
Customer reviews