Sysmons veiledning for trusselanalyse, del 1

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 med kommandoen DownloadString eller et VBS-skript som utgir seg for å være en Word-fil - bare bla gjennom den siste aktiviteten i Windows-hendelsesloggen. Men dette er en veldig stor hodepine. Heldigvis opprettet 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 WMI-hendelser som et middel til å spionere og du innser hvordan innsidere i det skjulte kan observere andre ansatte. Hovedproblemet med å jobbe med Windows-hendelsesloggen er mangelen på informasjon om overordnede prosesser, dvs. det er umulig å forstå hierarkiet av prosesser ut fra det. Sysmon-loggoppføringer, derimot, inneholder den overordnede prosess-IDen, dens navn og kommandolinjen som skal startes. 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 – nyttig og lesbar informasjon om prosessene (se bilder under). Du finner en haug med nyttige detaljer som ikke er i Windows Event Log, 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 her. 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 -> Operativt. I mine egne hårreisende undersøkelser av Windows-logger måtte jeg hele tiden bytte mellom for eksempel PowerShell-logger-mappen og Security-mappen, og bla gjennom hendelsesloggene i et tappert forsøk på på en eller annen måte å korrelere verdiene mellom de to. . Dette er aldri en lett oppgave, og som jeg senere innså, var det bedre å fylle opp aspirin umiddelbart.

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 wmiexec, som simulerer bevegelsen til en smart insider i nettverket. Dette er hva du vil se i Windows-hendelsesloggen:

Windows-loggen viser litt informasjon om prosessen, men den er til liten nytte. Pluss prosess-ID-er i heksadesimal???

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 kommando-og-kontroll (C2): 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, hva Windows vet om det ("Windows Command Processor"), identifikatoren 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 prosjekter 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 Get-WinEvent 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 Konverter Fra-Json .
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 hvor (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 IQ 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 gå tilbake og tenke på hva vi nettopp har laget. I hovedsak har vi nå en Windows-hendelsesdatabase tilgjengelig via PowerShell. Som jeg bemerket tidligere, er det forbindelser eller relasjoner mellom poster - via ParentProcessId - slik at et fullstendig hierarki av prosesser kan oppnås.

Hvis du har lest serien "The Adventures of the Elusive Malware" 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