Manual för analys av Sysmon-hot, del 1

Denna artikel är den första delen av en serie om analys av Sysmon-hot. Övriga delar i serien:

Del 1. Introduktion till analys av Sysmon-loggar (här är vi)
Del 2. Användning av data från Sysmon-händelser för att identifiera hot
Del 3. Djupgående analys av Sysmon-hot med hjälp av grafteknik

Om du arbetar med informationssäkerhet stöter du säkert ofta på attacker. Om du har ett vältränat öga kan du leta efter oegentligheter i de "råa" outredda loggarna — till exempel ett PowerShell-skript som körs med kommandot DownloadString eller ett VBS-skript som låtsas vara en Word-fil, genom att helt enkelt bläddra genom den senaste aktiviteten i Windows händelseloggen. Men det är verkligen en stor huvudvärk. Tack och lov har Microsoft skapat Sysmon, vilket gör attackeranalys betydligt enklare.

Vill du förstå de grundläggande idéerna bakom hoten som visas i Sysmon-loggen? Ladda ner vår guide WMI-händelser som ett spionageverktyg och du kommer att inse hur insiders kan övervaka andra anställda utan att bli upptäckta. Huvudproblemet med att arbeta med Windows händelseloggen är avsaknaden av information om föräldraprocesser, dvs. man kan inte förstå processhierarkin. I Sysmon-loggarna å sin sida finns både föräldraprocessens ID, dess namn och den körda kommandoraden. Tack Microsoft.

I den första delen av vår serie kommer vi att titta på vad som kan göras med grundläggande information från Sysmon. I den andra delen kommer vi fullt ut att utnyttja informationen om föräldraprocesser för att skapa mer komplexa överenskommelsestrukturer som kallas hotgrafer. I den tredje delen kommer vi att gå igenom en enkel algoritm som skannar hotgrafen för att leta efter oegentligheter genom att analysera "vikten" av grafen. Och avslutningsvis väntar en prydlig (och begriplig) sannolikhetsmetod för hotdetektering som belöning.

Del 1: Introduktion till analys av Sysmon-loggar

Vad hjälper till att förstå komplexiteten i händelseloggen? I slutändan – SIEM. Det normaliserar händelser och förenklar deras efterföljande analys. Men vi behöver inte gå så långt, åtminstone inte i början. För att förstå SIEM:s principer räcker det att prova det fantastiska gratisverktyget Sysmon. Och det är förvånansvärt lätt att arbeta med. Bra jobbat, Microsoft!

Vilka möjligheter har Sysmon?

Kort sagt – användbar och läsbar information om processer (se bilder nedan). Du kommer att upptäcka en massa användbara detaljer som saknas i Windows händelseloggen, men viktigast av allt – följande fält:

• Process-ID (i decimalt format, inte hex!)
• Föräldra-processens ID
• Processens kommandorad
• Föräldra-processens kommandorad
• Filens bildhash
• Filens bildnamn

Sysmon installeras samtidigt som en enhetsdrivrutin och som en tjänst – mer information här. Dess huvudfördel är möjligheten att analysera loggar från flera källor, korrelera information och visa resulterande värden i en händelseloggmapp som finns på vägen Microsoft -> Windows -> Sysmon -> Operational. I mina egna utredningar av Windows-loggar, som får håret att reser sig, var jag ständigt tvungen att växla mellan, säg, mappen med PowerShell-loggar och mappen 'Säkerhet', och bläddra bland händelseloggarna i ett heroisk försök att på något sätt matcha värdena mellan dem. Det är ingen lätt uppgift, och som jag senare insåg, var det bäst att ha några aspiriner till hands.

Sysmon gör ett kvalitativt språng framåt, och ger användbar (eller som leverantörer gillar att säga – handlingsbar) information för att hjälpa till att förstå grundprocesserna. Till exempel, jag körde en dold session wmiexec, som simulerar rörelsen av en smart insider inom nätverket. Så här ser det ut i Windows-loggen:

I Windows-loggen syns viss information om processen, men den är inte särskilt användbar. Dessutom är process-ID:n i hexadecimalt format???

En professionell IT-specialist med förståelse för hackning bör ifrågasätta kommandoraden. Att använda cmd.exe för att köra ett annat kommando med omdirigering av utdata till en fil med ett konstigt namn – det liknar tydligt åtgärder som mjukvara för kontroll och styrning command-and-control (C2): På det här sättet skapas en pseudo-shell med hjälp av WMI-tjänster.
Låt oss nu titta på motsvarande post från Sysmon, med fokus på hur mycket mer information den ger oss:

Sysmons möjligheter i en bild: detaljerad information om processen i läsbar form

Du ser inte bara kommandoraden, utan också filnamnet, sökvägen till den körbara applikationen, vad Windows vet om detta ("Windows Command Processor"), identifieraren föräldra processen, kommandoraden föräldern, som startade cmd-shellet, såväl som det verkliga filnamnet för föräldraprocessen. Allt på ett ställe, äntligen!
Från Sysmon-loggen kan vi dra slutsatsen att denna misstänkta kommandorad, som vi såg i de "råa" loggarna, troligtvis inte är resultatet av normal anställning. Snarare tvärtom, den genererades av en C2-liknande process - wmiexec, som jag nämnde tidigare - och skapades direkt av WMI-tjänstens process (WmiPrvSe). Nu har vi en indikation på att en fjärrangripare eller insider testar företagsinfrastrukturen.

Presentera Get-Sysmonlogs

Självklart är det fantastiskt när Sysmon har loggar på ett ställe. Men det skulle nog vara ännu bättre om vi kunde programmässigt få tillgång till individuella loggfält – till exempel genom PowerShell-kommandon. I sådana fall skulle vi kunna skriva ett litet PowerShell-script som automatiserar sökandet efter potentiella hot!
Det var inte jag som först kom på idén. Och det är bra att det redan har förklarats i vissa foruminlägg och GitHub projekten hur man använder PowerShell för att parsa Sysmon-loggen. I mitt fall ville jag undvika att behöva skriva separata rader av parse-script för varje Sysmon-fält. Därför använde jag principen av en lat människa och, som jag tror, kom på något intressant.
Det första viktiga momentet är möjligheten av kommandot Get-WinEvent att läsa Sysmon-loggar, filtrera de nödvändiga händelserna och skriva ut resultatet i en PS-variabel, som här:

$events = Get-WinEvent  -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}

Om du vill kontrollera lagets arbete själv, kan du genom att visa innehållet i det första elementet i arrayen $events, $events[0].Message, få en serie textsträngar med ett mycket enkelt format: Sysmon-fältnamn, kolon och sedan själva värdet.

Wow! Utskrift av Sysmon-logg i ett färdigt JSON-format.

Tänker du på samma sak som jag? Med lite mer ansträngning kan vi konvertera utskriften till en formatterad JSON-sträng och sedan ladda upp den direkt i PS-objektet med hjälp av det kraftfulla kommandot. ConvertFrom-Json .
Jag kommer att visa PowerShell-koden för konvertering — den är mycket enkel — i nästa del. Men först, låt oss titta på vad mitt nya kommando kallat get-sysmonlogs gör, som jag installerade som en PS-modul.
Istället för att gräva ner oss i analysen av Sysmon-loggar genom det otympliga gränssnittet för händelseloggen, kan vi enkelt söka efter inkrementell aktivitet direkt från PowerShell-sessionen och också använda PS-kommandot. där (alias – "?") för att förkorta utfallet:

Lista av cmd-shells som körs via WMI. Hotanalys billigt med hjälp av vårt eget kommando Get-Sysmonlogs.

Fantastiskt! Jag skapade ett verktyg för att fråga Sysmon-loggar, som om det vore en databas. I vår artikel om EQL nämndes det att denna funktion utförs av det fantastiska verktyget som beskrivs, även om det tekniskt sett ändå går via ett verkligt SQL-liknande gränssnitt. Ja, EQL är elegant,, men vi kommer att ta upp det i tredje delen.

Sysmon och grafanalys.

Låt oss abstrahera och tänka på vad vi just har skapat. I grunden har vi nu en databas av Windows-händelser, tillgänglig via PowerShell. Som jag nämnde tidigare finns det kopplingar eller relationer mellan posterna — via ParentProcessId — så vi kan få en fullständig hierarki av processer.

Om du har läst serien "Äventyr med svårfångad skadlig kod", vet du att hackers älskar att skapa komplexa flerstegsattacker där varje process har en liten roll och förbereder scenen för nästa steg. Sådana saker är oerhört svåra att fånga bara från en "rå" logg.
Men med mitt kommando Get-Sysmonlogs och den extra datastrukturen som vi kommer att titta på längre fram i texten (naturligtvis är det en graf), får vi ett praktiskt sätt att upptäcka hot — vilket kräver att vi bara utför rätt sökningar bland noderna.
Som alltid i våra DYI blogprojekt, ju mer du arbetar med att analysera hotdetaljer i liten skala, desto bättre förstår du hur komplext det är att upptäcka hot på organisatorisk nivå. Denna insikt är mycket viktig.

Vi kommer att möta de första intressanta utmaningarna i den andra delen av artikeln, där vi börjar koppla samman Sysmon-händelser i betydligt mer komplexa strukturer.

Källa: habr.com