Denne artikel er den første del af en serie om Sysmon-trussanalyse. Alle de øvrige dele af serien:
Del 1. Introduktion til Sysmon-loganalyse (vi er her)
Del 2. Brug af data fra Sysmon-begivenheder til at identificere trusler
Del 3. Dybdegående analyse af Sysmon-trusler med grafer
Hvis du arbejder med informationssikkerhed, står du formentlig ofte over for analyser af igangværende angreb. Hvis du allerede har øvet dig, kan du lede efter usædvanlige aktiviteter i "rå" ubehandlede logs – for eksempel et PowerShell-script, der kører eller et VBS-script, der udgiver sig for at være et Word-dokument, blot ved at gennemse den seneste aktivitet i Windows-begivenhedsloggen. Men det er virkelig en stor hovedpine. Heldigvis har Microsoft skabt Sysmon, som gør angrebsanalyse meget lettere.
Vil du forstå de grundlæggende ideer bag trusler vist i Sysmon-loggerne? Download vores guide og du vil indse, hvordan insidere kan overvåge andre medarbejdere i al hemmelighed. Hovedproblemet med at arbejde med Windows-begivenhedsloggen er manglen på information om forældresprocesser, dvs. du kan ikke forstå processernes hierarki. I Sysmon-logposter er der derimod information om forældresprocessens identifikator, navn og den kørende kommandolinje. Tak, Microsoft.
I den første del af vores serie ser vi på, hvad vi kan gøre med den grundlæggende information fra Sysmon. I den anden del vil vi på fuld tryk udnytte informationen om forældresprocesser til at oprette mere komplekse overensstemmelsesstrukturer, der kaldes trusselgrafer. I den tredje del vil vi se på en simpel algoritme, der scanner trusselgrafen for at finde usædvanlig aktivitet ved at analysere grafens "vægt". Og som belønning til sidst venter der dig en ordentlig (og forståelig) sandsynlighedsmetode til trusselopdagelse.
Del 1: Introduktion til Sysmon-loganalyse
Hvad kan hjælpe med at forstå kompleksiteterne i hændelsesloggen? I sidste ende er det SIEM. Den normaliserer hændelser og forenkler efterfølgende analyse. Men vi behøver ikke at gå så langt, i det mindste ikke i starten. Til at forstå principperne bag SIEM er det nok at prøve det fantastiske gratis værktøj Sysmon. Og det er overraskende nemt at arbejde med. Godt gået, Microsoft!
Hvilke muligheder har Sysmon?
Kort sagt – nyttig og læsbar information om processer (se billederne nedenfor). Du vil opdage en masse nyttige detaljer, der ikke findes i Windows hændelsesloggen, men det vigtigste er følgende felter:
- Process-ID (i decimalform, ikke hex!)
- Forælderprocessens ID
- Processens kommando-prompt
- Forælderprocessens kommando-prompt
- Filens hash-værdi
- Filnavne
Sysmon installeres både som en enhedsdriver og som en tjeneste – mere herom Dens nøglefordel er muligheden for at analysere logs fra flere kilder, korrelerer information og viser resultatværdier i én hændelseslogmappe, placeret på stien Microsoft -> Windows -> Sysmon -> Operational. I mine egne undersøgelser af Windows-logs, der får håret til at rejse sig, måtte jeg konstant skifte mellem for eksempel PowerShell-logmappen og mappen "Sikkerhed", mens jeg bladrede gennem hændelsesloggene i et heroisk forsøg på at matche værdierne mellem dem. Det er bestemt ikke nogen let opgave, og som jeg senere indså, var det bedre at have lidt aspirin ved hånden.
Sysmon tager et kvalitetsmæssigt skridt fremad ved at levere nyttig (eller som leverandører elsker at sige – proaktiv) information til hjælp i forståelsen af de grundlæggende processer. For eksempel kørte jeg en skjult session , som simulerer en smart insider, der bevæger sig inden i netværket. Her er hvad du vil se i Windows hændelsesloggen:
I Windows-loggen ses der en eller anden information om processen, men den er ringe nyttig. Plus, proces-ID'er i hex-form???
En professionel IT-specialist med forståelse for hackingens grundprincipper bør finde kommando-prompten mistænkelig. At bruge cmd.exe til efterfølgende at køre en anden kommando med omdirigering af output til en fil med et mærkeligt navn – det ligner klart handlinger fra software til kontrol og administration. : på denne måde oprettes der en pseudo-shell ved hjælp af WMI-tjenester.
Lad os nu se på den ækvivalente post fra Sysmon, og bemærke hvor meget ekstra information den giver os:
Sysmon-muligheder på ét skærmbillede: detaljeret information om processen i læsbar form
Du ser ikke kun kommandolinjen, men også filnavnet, stien til den udførbare applikation, hvad Windows ved om dette ("Windows Command Processor"), identifikator til den overordnede proces, kommandolinjeforælderen
, der startede cmd-shellen, samt det rigtige navn på den overordnede proces. Alt på ét sted, endelig!
Fra Sysmon-loggen kan vi konkludere, at det med høj sandsynlighed er denne mistænkelige kommandolinje, som vi så i de "rå" logs, ikke er resultatet af normal medarbejderaktivitet. Snarere er det genereret af en C2-lignende proces — wmiexec, som jeg nævnte tidligere — og blev direkte afledt af WMI-tjenestens proces (WmiPrvSe). Nu har vi en indikator på, at en fjernangriber eller insider tester den virksomhedsinfrastruktur.
Præsenterer Get-Sysmonlogs
Det er selvfølgelig fantastisk, når Sysmon har logs samlet ét sted. Men det ville sikkert være endnu bedre, hvis vi kunne få adgang til individuelle logfelter programmatisk – for eksempel gennem PowerShell-kommandoer. I så fald kunne vi skrive et lille PowerShell-script, der automatiserer søgningen efter potentielle trusler! projekter
allerede er forklaret, hvordan man bruger PowerShell til at parse Sysmon-loggen. I mit tilfælde ønskede jeg at undgå at skulle skrive separate linjer af parse-scriptet for hvert Sysmon-felt. Derfor brugte jeg den dovne mands princip, og som jeg mener, kom jeg op med noget interessant. Get-WinEvent
kan læse Sysmon-logs, filtrere de nødvendige begivenheder, og returnere resultatet i PS-variablen, som her: $events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Hvis du ønsker at kontrollere, hvordan teamet fungerer selv, kan du gennem visningen af indholdet i det første element i arrayet $events, $events[0].Message, få en række tekststrenge med et meget simpelt format: feltets navn Sysmon, kolon og derefter selve værdien.
Hurra! Uddata fra Sysmon-loggen i et klart JSON-format
Tænker du på det samme som mig? Med lidt ekstra indsats kan vi konvertere uddata til en formateret JSON-streng og derefter indlæse den direkte i PS-objektet ved hjælp af det kraftfulde kommando .
Jeg vil vise PowerShell-koden til konvertering – den er meget simpel – i næste del. Men lad os først se, hvad mit nye kommando kaldet get-sysmonlogs, som jeg har installeret som PS-modul, kan gøre.
I stedet for at dykke dybt ind i analysen af Sysmon-loggerne gennem det besværlige grænseflade af begivenhedsloggen, kan vi nemt søge efter inkrementel aktivitet direkte fra PowerShell-sessionen og også bruge PS-kommandoen (alias – «?») til at forkorte resultatudbyttet:
Liste over cmd-shells, der køres via WMI. Bedste trusselanalyse ved hjælp af vores egen kommando Get-Sysmonlogs
Utrolig! Jeg har skabt et værktøj til forespørgsel af Sysmon-loggen, som om det var en database. I vores artikel om blev det nævnt, at denne funktion også udføres af det fantastiske værktøj, der beskrives, om end formelt gennem et ægte SQL-lignende grænseflade. Ja, EQL er elegant, men vi vil berøre det i den tredje del.
Sysmon og grafanalyse
Lad os abstrahere og tænke på, hvad vi lige har skabt. I bund og grund har vi nu en database over Windows-begivenheder, der er tilgængelig via PowerShell. Som jeg nævnte tidligere, er der forbindelser eller relationer mellem posterne – gennem ParentProcessId – så vi kan få den fulde proceshierarki.
Hvis du har læst serien ved du, at hackere elsker at skabe komplekse, flerstadie angreb, hvor hver proces udfører sin lille rolle og forbereder grundlaget for næste skridt. Sådanne ting er ekstremt svære at fange blot fra en «rå» log.
Men med min kommando Get-Sysmonlogs og den ekstra datastruktur, vi vil se nærmere på senere (selvfølgelig er det grafen), vil vi få en praktisk måde at opdage trusler – for dette kræver det blot at udføre den rigtige søgning over noderne.
Som altid i vores DYI blogprojekter, jo mere du arbejder med at analysere truseldetaljer i lille skala, desto bedre bliver du til at forstå, hvor kompleks trusseldetektion er på organisationsniveau. Og denne forståelse er yderst vigtig.
Vi vil møde de første interessante udfordringer i den anden del af artiklen, hvor vi begynder at forbinde Sysmon-hændelser i langt mere komplekse strukturer.
Kilde: habr.com
