Denne artikel er den første del af en serie om Sysmon-trusselsanalyse. Alle andre dele af serien:
Del 1: Introduktion til Sysmon-loganalyse (vi er her)
Del 2: Brug af Sysmon-hændelsesdata til at identificere trusler
Del 3. Dybdegående analyse af Sysmon-trusler ved hjælp af grafer
Hvis du arbejder med informationssikkerhed, skal du nok ofte forstå igangværende angreb. Hvis du allerede har et trænet øje, kan du kigge efter ikke-standard aktivitet i de "rå" ubehandlede logfiler - f.eks. et PowerShell-script, der kører eller et VBS-script, der foregiver at være en Word-fil - blot at rulle gennem den seneste aktivitet i Windows-hændelsesloggen. Men det er en rigtig stor hovedpine. Heldigvis skabte Microsoft Sysmon, som gør angrebsanalyse meget lettere.
Vil du forstå de grundlæggende ideer bag de trusler, der vises i Sysmon-loggen? Download vores guide og du indser, hvordan insidere i det skjulte kan observere andre medarbejdere. Hovedproblemet ved at arbejde med Windows-hændelsesloggen er manglen på information om overordnede processer, dvs. det er umuligt at forstå hierarkiet af processer ud fra det. Sysmon-logposter indeholder på den anden side det overordnede proces-id, dets navn og kommandolinjen, der skal startes. Tak, Microsoft.
I den første del af vores serie vil vi se på, hvad du kan gøre med grundlæggende oplysninger fra Sysmon. I del XNUMX vil vi drage fuld fordel af overordnede procesoplysninger til at skabe mere komplekse overholdelsesstrukturer kendt som trusselsgrafer. I den tredje del vil vi se på en simpel algoritme, der scanner en trusselsgraf for at søge efter usædvanlig aktivitet ved at analysere "vægten" af grafen. Og i sidste ende vil du blive belønnet med en pæn (og forståelig) metode til at opdage trusler.
Del 1: Introduktion til Sysmon-loganalyse
Hvad kan hjælpe dig med at forstå kompleksiteten af hændelsesloggen? I sidste ende - SIEM. Det normaliserer begivenheder og forenkler deres efterfølgende analyse. Men vi skal ikke så langt, i hvert fald ikke i starten. I begyndelsen, for at forstå principperne for SIEM, vil det være nok at prøve det vidunderlige gratis Sysmon-værktøj. Og hun er overraskende nem at arbejde med. Hold det op, Microsoft!
Hvilke funktioner har Sysmon?
Kort sagt - nyttig og læsbar information om processerne (se billeder nedenfor). Du finder en masse nyttige detaljer, der ikke er i Windows Event Log, men de vigtigste er følgende felter:
- Proces-id (i decimal, ikke hex!)
- Overordnet proces-id
- Behandle kommandolinje
- Kommandolinje for den overordnede proces
- Filbillede hash
- Filbilleder
Sysmon er installeret både som enhedsdriver og som en service - flere detaljer Dens vigtigste fordel er evnen til at analysere logfiler fra af et par kilder, korrelation af information og output af resulterende værdier til én hændelseslog-mappe placeret langs stien Microsoft -> Windows -> Sysmon -> Operationel. I mine egne hårrejsende undersøgelser af Windows-logfiler, oplevede jeg, at jeg konstant skulle skifte mellem f.eks. PowerShell-logs-mappen og Security-mappen, idet jeg bladrede gennem hændelsesloggene i et tappert forsøg på på en eller anden måde at korrelere værdierne mellem de to. . Dette er aldrig en nem opgave, og som jeg senere indså, var det bedre straks at fylde op med aspirin.
Sysmon tager et kvantespring fremad ved at give nyttig (eller som leverandører kan lide at sige, handlingsvenlig) information for at hjælpe med at forstå underliggende processer. For eksempel startede jeg en hemmelig session , der simulerer bevægelsen af en smart insider i netværket. Dette er, hvad du vil se i Windows-hændelsesloggen:
Windows-loggen viser nogle oplysninger om processen, men det nytter ikke meget. Plus proces-id'er i hexadecimal???
For en professionel it-professionel med en forståelse af det grundlæggende i hacking, bør kommandolinjen være mistænkelig. Brug af cmd.exe til derefter at køre en anden kommando og omdirigere outputtet til en fil med et mærkeligt navn ligner tydeligvis handlingerne i overvågnings- og kontrolsoftware : På denne måde skabes en pseudo-shell ved hjælp af WMI-tjenester.
Lad os nu tage et kig på Sysmon-indgangsækvivalenten og bemærke, hvor meget yderligere information det giver os:
Sysmon-funktioner i ét skærmbillede: detaljerede oplysninger om processen i en læsbar form
Du ser ikke kun kommandolinjen, men også filnavnet, stien til det eksekverbare program, hvad Windows ved om det ("Windows Command Processor"), identifikatoren forældre proces, kommandolinje forælder, som lancerede cmd-skallen, såvel som det rigtige filnavn på den overordnede proces. Alt på ét sted, endelig!
Fra Sysmon-loggen kan vi konkludere, at med en høj grad af sandsynlighed er denne mistænkelige kommandolinje, som vi så i de "rå" logfiler, ikke resultatet af medarbejderens normale arbejde. Tværtimod blev den genereret af en C2-lignende proces - wmiexec, som jeg nævnte tidligere - og blev direkte affødt af WMI-serviceprocessen (WmiPrvSe). Nu har vi en indikator for, at en ekstern angriber eller insider tester virksomhedens infrastruktur.
Introduktion af Get-Sysmonlogs
Det er selvfølgelig fantastisk, når Sysmon lægger loggene ét sted. Men det ville nok være endnu bedre, hvis vi kunne få adgang til individuelle logfelter programmæssigt - for eksempel gennem PowerShell-kommandoer. I dette tilfælde kan du skrive et lille PowerShell-script, der vil automatisere søgningen efter potentielle trusler!
Jeg var ikke den første, der fik sådan en idé. Og det er godt, at i nogle forumindlæg og GitHub Det er allerede blevet forklaret, hvordan man bruger PowerShell til at analysere Sysmon-loggen. I mit tilfælde ville jeg undgå at skulle skrive separate linjer med parsing-script for hvert Sysmon-felt. Så jeg brugte lazy man-princippet, og jeg synes, jeg fandt på noget interessant som resultat.
Det første vigtige punkt er holdets evner læs Sysmon-logfiler, filtrer de nødvendige hændelser og udsend resultatet til PS-variablen, som her:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Hvis du selv vil teste kommandoen ved at vise indholdet i det første element af $events-arrayet, $events[0]. Besked, output kan være en række tekststrenge med et meget simpelt format: navnet på Sysmon-felt, et kolon og så selve værdien.
Hurra! Udsender Sysmon-log i JSON-klar format
Tænker du det samme som mig? Med lidt mere indsats kan du konvertere outputtet til en JSON-formateret streng og derefter indlæse det direkte i et PS-objekt ved hjælp af en kraftfuld kommando .
Jeg viser PowerShell-koden til konverteringen - det er meget enkelt - i næste del. Lad os indtil videre se, hvad min nye kommando kaldet get-sysmonlogs, som jeg installerede som et PS-modul, kan gøre.
I stedet for at dykke dybt ned i Sysmon-loganalyse gennem en ubekvem hændelsesloggrænseflade, kan vi uden besvær søge efter trinvis aktivitet direkte fra en PowerShell-session samt bruge PS-kommandoen (alias – “?”) for at forkorte søgeresultaterne:
Liste over cmd-skaller lanceret via WMI. Trusselsanalyse til en billig penge med vores eget Get-Sysmonlogs-team
Vidunderlig! Jeg oprettede et værktøj til at polle Sysmon-loggen, som om det var en database. I vores artikel om det blev bemærket, at denne funktion vil blive udført af det seje værktøj, der er beskrevet i det, selvom det formelt stadig er gennem en ægte SQL-lignende grænseflade. Ja, EQL elegant, men vi vil komme ind på det i tredje del.
Sysmon og grafanalyse
Lad os træde tilbage og tænke over, hvad vi lige har skabt. I det væsentlige har vi nu en Windows-hændelsesdatabase tilgængelig via PowerShell. Som jeg bemærkede tidligere, er der forbindelser eller relationer mellem poster - via ParentProcessId - så et komplet hierarki af processer kan opnås.
Hvis du har læst serien du ved, at hackere elsker at skabe komplekse flertrinsangreb, hvor hver proces spiller sin egen lille rolle og forbereder et springbræt til næste trin. Det er ekstremt svært at fange sådanne ting blot fra den "rå" log.
Men med min Get-Sysmonlogs-kommando og en ekstra datastruktur, som vi vil se på senere i teksten (en graf, selvfølgelig), har vi en praktisk måde at opdage trusler på – som blot kræver at lave den rigtige toppunktssøgning.
Som altid med vores DYI-blogprojekter, jo mere du arbejder på at analysere detaljerne i trusler i lille skala, jo mere vil du indse, hvor kompleks trusselsdetektion er på virksomhedsniveau. Og denne bevidsthed er ekstrem vigtigt punkt.
Vi vil støde på de første interessante komplikationer i anden del af artiklen, hvor vi vil begynde at forbinde Sysmon-begivenheder med hinanden i meget mere komplekse strukturer.
Kilde: www.habr.com