
Denne artikkelen er den første delen av en serie om Sysmon-trusselsanalyse. Alle andre deler av serien:
Del 1: Introduksjon til Sysmon-logganalyse (vi er her)
Del 2: Bruke Sysmon-hendelsesdata for å identifisere trusler
Del 3. Dybdeanalyse av Sysmon-trusler ved hjelp av grafer
Hvis du jobber med informasjonssikkerhet, må du sannsynligvis ofte forstå pågående angrep. Hvis du allerede har et trent øye, kan du se etter ikke-standard aktivitet i de "rå" ubehandlede loggene - for eksempel et PowerShell-skript som kjører eller et VBS-skript forkledd som en Word-fil – ganske enkelt ved å bla gjennom den siste aktiviteten i hendelsesloggen WindowsMen dette er en skikkelig hodepine. Heldigvis skapte Microsoft Sysmon, som gjør angrepsanalyse mye enklere.
Vil du forstå de grunnleggende ideene bak truslene som vises i Sysmon-loggen? Last ned vår guide og du innser hvordan innsidere i hemmelighet kan overvåke andre ansatte. Hovedproblemet med å jobbe med hendelsesloggen Windows Problemet er mangelen på informasjon om overordnede prosesser, noe som betyr at det er umulig å forstå prosesshierarkiet. Sysmon-loggoppføringer, derimot, inneholder den overordnede prosessens ID, navnet og kommandolinjen som kjøres. Takk, Microsoft.
I den første delen av serien vår skal vi se på hva du kan gjøre med grunnleggende informasjon fra Sysmon. I del XNUMX vil vi dra full nytte av overordnet prosessinformasjon for å lage mer komplekse samsvarsstrukturer kjent som trusselgrafer. I den tredje delen skal vi se på en enkel algoritme som skanner en trusselgraf for å søke etter uvanlig aktivitet ved å analysere "vekten" til grafen. Og til slutt vil du bli belønnet med en ryddig (og forståelig) sannsynlighetsdeteksjonsmetode.
Del 1: Introduksjon til Sysmon-logganalyse
Hva kan hjelpe deg med å forstå kompleksiteten til hendelsesloggen? Til syvende og sist - SIEM. Det normaliserer hendelser og forenkler deres påfølgende analyse. Men vi trenger ikke gå så langt, i hvert fall ikke med det første. I begynnelsen, for å forstå prinsippene til SIEM, vil det være nok å prøve det fantastiske gratis Sysmon-verktøyet. Og hun er overraskende lett å jobbe med. Fortsett med det, Microsoft!
Hvilke funksjoner har Sysmon?
Kort sagt, den gir nyttig og lesbar informasjon om prosesser (se bilder nedenfor). Du finner massevis av nyttige detaljer som ikke finnes i hendelsesloggen. Windows, men de viktigste er følgende felt:
- Prosess-ID (i desimal, ikke hex!)
- ID for overordnet prosess
- Behandle kommandolinje
- Kommandolinje for den overordnede prosessen
- Filbildehash
- Filbildenavn
Sysmon er installert både som enhetsdriver og som en tjeneste - flere detaljer Den viktigste fordelen er muligheten til å analysere logger fra av noen få kilder, korrelasjon av informasjon og utdata av resulterende verdier til én hendelsesloggmappe som ligger langs banen Microsoft -> Windows -> Sysmon -> DriftsmessigI mine egne loggundersøkelser WindowsHårreisende feil som disse gjorde at jeg stadig måtte veksle mellom, for eksempel, PowerShell-loggmappen og Sikkerhetsmappen, og bla gjennom hendelseslogger i et heroisk forsøk på å på en eller annen måte korrelere verdiene mellom dem. Dette er aldri en enkel oppgave, og som jeg senere innså, ville det vært bedre å hamstre aspirin med en gang.
Sysmon tar et kvantesprang fremover ved å gi nyttig (eller som leverandører liker å si, handlingsdyktig) informasjon for å hjelpe til med å forstå underliggende prosesser. For eksempel startet jeg en hemmelig økt , som simulerer bevegelsen til en smart insider i nettverket. Dette er hva du vil se i hendelsesloggen. Windows:

I magasinet Windows Noe prosessinformasjon er synlig, men det er ikke særlig nyttig. Også prosess-ID-er i heksadesimal form?
For en profesjonell IT-profesjonell med forståelse for det grunnleggende om hacking, bør kommandolinjen være mistenkelig. Å bruke cmd.exe til å kjøre en annen kommando og omdirigere utdataene til en fil med et merkelig navn er tydelig lik handlingene til overvåking og kontrollprogramvare : På denne måten opprettes et pseudo-skall ved hjelp av WMI-tjenester.
La oss nå ta en titt på Sysmon-oppføringsekvivalenten, og legge merke til hvor mye tilleggsinformasjon det gir oss:

Sysmon-funksjoner i ett skjermbilde: detaljert informasjon om prosessen i en lesbar form
Du ser ikke bare kommandolinjen, men også filnavnet, banen til det kjørbare programmet, som Windows vet om det («Windows Kommandoprosessor», identifikator foreldrenes prosess, kommandolinje forelder, som lanserte cmd-skallet, samt det virkelige filnavnet til overordnet prosessen. Alt på ett sted, endelig!
Fra Sysmon-loggen kan vi konkludere med at denne mistenkelige kommandolinjen som vi så i de "rå" loggene, med en høy grad av sannsynlighet ikke er et resultat av den ansattes normale arbeid. Snarere tvert imot, den ble generert av en C2-lignende prosess - wmiexec, som jeg nevnte tidligere - og ble direkte skapt av WMI-tjenesteprosessen (WmiPrvSe). Nå har vi en indikator på at en ekstern angriper eller innsider tester bedriftens infrastruktur.
Vi introduserer Get-Sysmonlogs
Det er selvfølgelig flott når Sysmon legger loggene på ett sted. Men det ville trolig vært enda bedre om vi kunne få tilgang til individuelle loggfelt programmatisk - for eksempel gjennom PowerShell-kommandoer. I dette tilfellet kan du skrive et lite PowerShell-skript som vil automatisere søket etter potensielle trusler!
Jeg var ikke den første som fikk en slik idé. Og det er bra at i noen foruminnlegg og GitHub Det har allerede blitt forklart hvordan du bruker PowerShell til å analysere Sysmon-loggen. I mitt tilfelle ønsket jeg å unngå å måtte skrive separate linjer med parsing script for hvert Sysmon-felt. Så jeg brukte lazy man-prinsippet og jeg tror jeg kom på noe interessant som et resultat.
Det første viktige punktet er lagets evner les Sysmon-logger, filtrer de nødvendige hendelsene og send ut resultatet til PS-variabelen, som her:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Hvis du vil teste kommandoen selv, ved å vise innholdet i det første elementet i $events-matrisen, $events[0]. Melding, utdata kan være en serie tekststrenger med et veldig enkelt format: navnet på Sysmon-felt, et kolon og deretter selve verdien.

Hurra! Sender ut Sysmon-logg til JSON-klar format
Tenker du det samme som meg? Med litt mer innsats kan du konvertere utdataene til en JSON-formatert streng og deretter laste den direkte inn i et PS-objekt ved hjelp av en kraftig kommando .
Jeg viser PowerShell-koden for konverteringen - det er veldig enkelt - i neste del. For nå, la oss se hva min nye kommando kalt get-sysmonlogs, som jeg installerte som en PS-modul, kan gjøre.
I stedet for å dykke dypt inn i Sysmon-logganalyse gjennom et upraktisk hendelseslogggrensesnitt, kan vi enkelt søke etter inkrementell aktivitet direkte fra en PowerShell-økt, samt bruke PS-kommandoen (alias – “?”) for å forkorte søkeresultatene:

Liste over cmd-skall lansert via WMI. Trusselanalyse til en billig penge med vårt eget Get-Sysmonlogs-team
Strålende! Jeg opprettet et verktøy for å spørre Sysmon-loggen som om den var en database. I vår artikkel om det ble lagt merke til at denne funksjonen vil bli utført av det kule verktøyet som er beskrevet i det, men formelt fortsatt gjennom et ekte SQL-lignende grensesnitt. Ja, EQL elegant, men vi skal berøre det i tredje del.
Sysmon og grafanalyse
La oss ta et skritt tilbake og tenke på hva vi nettopp har laget. I hovedsak har vi nå en hendelsesdatabase. Windows, tilgjengelig via PowerShell. Som jeg nevnte tidligere, finnes det forbindelser eller relasjoner mellom poster – via ParentProcessId – slik at du kan hente hele prosesshierarkiet.
Hvis du har lest serien du vet at hackere elsker å lage komplekse flertrinnsangrep, der hver prosess spiller sin egen lille rolle og forbereder et springbrett for neste trinn. Det er ekstremt vanskelig å fange slike ting bare fra den "rå" loggen.
Men med Get-Sysmonlogs-kommandoen min og en ekstra datastruktur vi skal se på senere i teksten (en graf, selvfølgelig), har vi en praktisk måte å oppdage trusler på – som bare krever å gjøre riktig toppunktsøk.
Som alltid med våre DYI-bloggprosjekter, jo mer du jobber med å analysere detaljene i trusler i liten skala, jo mer vil du innse hvor kompleks trusseldeteksjon er på bedriftsnivå. Og denne bevisstheten er ekstrem viktig poeng.
Vi vil møte de første interessante komplikasjonene i den andre delen av artikkelen, hvor vi vil begynne å koble Sysmon-hendelser med hverandre til mye mer komplekse strukturer.
Kilde: www.habr.com
