Simovits

En praktisk genomlysning av Windows eventloggning

Introduktion

Windows eventloggning är en oumbärlig loggkälla för IT-forensik och incidenthantering som ingår i alla Windows-enheter, men som bör anpassas för att logga och kunna upptäcka vanliga incidenter i Windows-miljöer.

Windows eventloggar som lagras i .evtx filer under C:\Windows\System32\winevt\Logs i XML-format och kan granskas lokalt i loggboken (engelska: Event Viewer) eventvwr.msc som nedan. Loggningen delas upp i olika logg-hivar Application, Security, Setup, System och Forwarded Events sedan har olika händelser har olika event-ID. Gemensam data för alla events finns i under <System> i XML-loggen medan specifik logg för en händelse finns i <EventData> eller <UserData>. Nedan visas en event 4624 logg vilket motsvarar att ett konto loggade på.

Problembild

Windows förvalda eventloggning inte tillräcklig för att kunna logga och detektera vanliga incidenter. Förvald loggstorlek är 20 MB, även på domänkontrollanter! (varav 15MB för powershell loggning). Och om inte loggarna samlas in och en larmsättning ställs in kommer eventloggen endast användas när incidenter konstaterats på andra sätt.

Strategi

Ett effektivt sätt att påbörja en larmsättning är att implementera Sigma-regler som bygger på eventloggning för att detektera avvikelser, men förvald loggning i Windows ger en undermålig täckning på vad som loggas och vilka regler som kan användas. Ett sätt att inventera täckningen mot sviter av Sigma-regler är att köra WELA 1 som både kan inventera och applicera loggningsinställningar baserat på en baseline.

I version 2.0.0 av WELA kan nuvarande loggkonfiguration mätas mot följande baselines:

Genom WELA har en nyinstallerad Windows 11 klient 25H2 OS Build 26200.6899 en täckning på 23.56% mot YamatoSecurity och Australian Signals Directorates baselines. Efter en körning noteras att regelkategorin Process Creation med 1363 regler varav 69 inte kan implementeras eftersom kommandorader inte är inkluderade i process creation-event. Vidare saknas loggning kopplat till registret och Powershell.

Nedan visas en jämförelse av de kategorier av eventloggar som har flest detektionsregler och eventloggsinställningarna före och efter att WELA tillämpat YamatoSecurity-baseline.

Efter att automatiskt tillämpat YamatoSecurity-baseline nås 87.88% täckning utan ytterligare åtgärder.

Konkreta brister med förvalda logginställningar

För att kolla specifika inställningar kan verktyget auditpol användas i Powershell. Innan en baseline tillämpats noteras att både lyckade och misslyckade Logon-events loggas (event id 4624, 5625). Men nya processer loggas inte (event id 4688) likadant med NTLM Credential Validation (event id 4776 , 4777). Förvald inställning för NTLM Credential Validation är att logga endast lyckade valideringar och bara på server-OS.

Med loggning på credential validation kan bland annat följande Sigma-regler användas för att detektera password guessing, user guessing och password-spray attacker:

Ett källa till analyssvårigheter är också att Windows-loggen inte kodar meddelande-data i själva .evtx-filerna, utan baserat på Provider och EventID-värde hämtas interpoleras meddelandetexten från korrekt MESSAGE_TABLE från en extern DLL-fil. Så ifall applikationslogg inhämtas från ett annat system till ett system utan samma log-provider kommer loggmeddelandet att sakna meddelandetext vad som loggats.5 Lyckligtvis finns det internet-resurser som förklarar vanliga event-id såsom Windows Security Event log events. 6

Referenser

  1. https://github.com/Yamato-Security/WELA ↩︎
  2. https://github.com/Yamato-Security/EnableWindowsLogSettings ↩︎
  3. https://www.cyber.gov.au/business-government/detecting-responding-to-threats/event-logging/windows-event-logging-and-forwarding ↩︎
  4. https://learn.microsoft.com/en-gb/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations ↩︎
  5. https://docs.velociraptor.app/blog/2019/2019-11-12_windows-event-logs-d8d8e615c9ca/ ↩︎
  6. https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx ↩︎