Sysmon Threat Analysis Guide, del 1

Den här artikeln är den första delen av en serie om Sysmon-hotanalys. Alla andra delar av serien:

Del 1: Introduktion till Sysmon Log Analysis (vi är här)
Del 2: Använda Sysmon Event Data för att identifiera hot
Del 3. Fördjupad analys av Sysmon-hot med hjälp av grafer

Om du arbetar inom informationssäkerhet måste du förmodligen ofta förstå pågående attacker. Om du redan har ett tränat öga kan du leta efter icke-standardaktivitet i de "råa" obearbetade loggarna - t.ex. ett PowerShell-skript som körs med kommandot DownloadString eller ett VBS-skript som låtsas vara en Word-fil - rulla helt enkelt igenom den senaste aktiviteten i Windows-händelseloggen. Men det här är en riktigt stor huvudvärk. Som tur är skapade Microsoft Sysmon, vilket gör attackanalys mycket enklare.

Vill du förstå de grundläggande idéerna bakom hoten som visas i Sysmon-loggen? Ladda ner vår guide WMI-evenemang som ett sätt att spionera och du inser hur insiders i smyg kan observera andra anställda. Det största problemet med att arbeta med Windows-händelseloggen är bristen på information om överordnade processer, d.v.s. det är omöjligt att förstå processhierarkin utifrån det. Sysmon-loggposter, å andra sidan, innehåller det överordnade process-ID, dess namn och kommandoraden som ska startas. Tack, Microsoft.

I den första delen av vår serie ska vi titta på vad du kan göra med grundläggande information från Sysmon. I del XNUMX kommer vi att dra full nytta av överordnad processinformation för att skapa mer komplexa efterlevnadsstrukturer som kallas hotdiagram. I den tredje delen kommer vi att titta på en enkel algoritm som skannar en hotgraf för att söka efter ovanlig aktivitet genom att analysera grafens "vikt". Och i slutet kommer du att belönas med en snygg (och begriplig) probabilistisk hotdetekteringsmetod.

Del 1: Introduktion till Sysmon Log Analysis

Vad kan hjälpa dig 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 till en början. I början, för att förstå principerna för SIEM, räcker det med att prova det underbara gratisverktyget Sysmon. Och hon är förvånansvärt lätt att arbeta med. Fortsätt så, Microsoft!

Vilka funktioner har Sysmon?

Kort sagt - användbar och läsbar information om processerna (se bilder nedan). Du hittar en massa användbara detaljer som inte finns i Windows Event Log, men de viktigaste är följande fält:

• Process-ID (i decimal, inte hex!)
• Förälders process-ID
• Bearbeta kommandoraden
• Kommandoraden för den överordnade processen
• Filbild hash
• Filbildnamn

Sysmon installeras både som enhetsdrivrutin och som en tjänst - mer information här. Dess främsta fördel är möjligheten att analysera loggar från av ett fåtal källor, korrelation av information och utdata av resulterande värden till en händelseloggmapp som ligger längs vägen Microsoft -> Windows -> Sysmon -> Drift. I mina egna hårresande undersökningar av Windows-loggar befann jag mig ständigt behöva växla mellan, säg, PowerShell-loggmappen och Security-mappen, bläddra igenom händelseloggarna i ett tappert försök att på något sätt korrelera värdena mellan de två . Detta är aldrig en lätt uppgift, och som jag senare insåg var det bättre att genast fylla på med aspirin.

Sysmon tar ett kvantsprång framåt genom att tillhandahålla användbar (eller som leverantörer vill säga, handlingsbar) information för att hjälpa till att förstå underliggande processer. Till exempel startade jag en hemlig session wmiexec, simulerar rörelsen av en smart insider inom nätverket. Det här är vad du kommer att se i Windows-händelseloggen:

Windows-loggen visar lite information om processen, men den är till liten nytta. Plus process-ID:n i hexadecimal???

För en professionell IT-proffs med förståelse för grunderna i hackning bör kommandoraden vara misstänksam. Att använda cmd.exe för att sedan köra ett annat kommando och omdirigera utdata till en fil med ett konstigt namn liknar tydligt åtgärderna för övervakning och kontrollprogramvara kommando-och-kontroll (C2): På detta sätt skapas ett pseudo-skal med hjälp av WMI-tjänster.
Låt oss nu ta en titt på Sysmon-postens motsvarighet och lägga märke till hur mycket ytterligare information den ger oss:

Sysmon-funktioner i en skärmdump: detaljerad information om processen i en läsbar form

Du ser inte bara kommandoraden, utan också filnamnet, sökvägen till det körbara programmet, vad Windows vet om det ("Windows Command Processor"), identifieraren förälder process, kommandorad förälder, som lanserade cmd-skalet, såväl som det riktiga filnamnet för den överordnade processen. Allt på ett ställe, äntligen!
Från Sysmon-loggen kan vi dra slutsatsen att med en hög grad av sannolikhet är denna misstänkta kommandorad som vi såg i de "råa" loggarna inte resultatet av den anställdes normala arbete. Tvärtom, den genererades av en C2-liknande process - wmiexec, som jag nämnde tidigare - och skapades direkt av WMI-tjänstprocessen (WmiPrvSe). Nu har vi en indikator på att en fjärrangripare eller insider testar företagets infrastruktur.

Vi presenterar Get-Sysmonlogs

Visst är det bra när Sysmon lägger stockarna på ett ställe. Men det skulle förmodligen vara ännu bättre om vi kunde komma åt enskilda loggfält programmatiskt - till exempel genom PowerShell-kommandon. I det här fallet kan du skriva ett litet PowerShell-skript som skulle automatisera sökningen efter potentiella hot!
Jag var inte den första som fick en sådan idé. Och det är bra att i vissa foruminlägg och GitHub projekt Det har redan förklarats hur man använder PowerShell för att analysera Sysmon-loggen. I mitt fall ville jag undvika att behöva skriva separata rader med analysskript för varje Sysmon-fält. Så jag använde lazy man-principen och jag tror att jag kom på något intressant som resultat.
Den första viktiga punkten är lagets förmåga Get-WinEvent läs Sysmon-loggar, filtrera de nödvändiga händelserna och mata ut resultatet till PS-variabeln, som här:

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

Om du vill testa kommandot själv, genom att visa innehållet i det första elementet i $events-arrayen, $events[0]. Meddelande, utdata kan vara en serie textsträngar med ett mycket enkelt format: namnet på Sysmon-fält, ett kolon och sedan själva värdet.

Hurra! Utmatar Sysmon-logg i JSON-färdigt format

Tänker du samma sak som jag? Med lite mer ansträngning kan du konvertera utdata till en JSON-formaterad sträng och sedan ladda den direkt till ett PS-objekt med ett kraftfullt kommando ConvertFrom-Json .
Jag visar PowerShell-koden för konverteringen - det är väldigt enkelt - i nästa del. För nu, låt oss se vad mitt nya kommando som heter get-sysmonlogs, som jag installerade som en PS-modul, kan göra.
Istället för att dyka djupt in i Sysmon-logganalys genom ett obekvämt händelselogggränssnitt, kan vi enkelt söka efter inkrementell aktivitet direkt från en PowerShell-session, samt använda PS-kommandot var (alias – “?”) för att förkorta sökresultaten:

Lista över cmd-skal lanserade via WMI. Hotanalys på det billigaste med vårt eget Get-Sysmonlogs-team

Underbar! Jag skapade ett verktyg för att polla Sysmon-loggen som om det vore en databas. I vår artikel om EQL det noterades att den här funktionen kommer att utföras av det coola verktyget som beskrivs i det, men formellt fortfarande genom ett riktigt SQL-liknande gränssnitt. Ja, EQL elegant, men vi kommer att beröra det i den tredje delen.

Sysmon och grafanalys

Låt oss ta ett steg tillbaka och tänka på vad vi just skapat. I huvudsak har vi nu en Windows-händelsedatabas tillgänglig via PowerShell. Som jag noterade tidigare finns det kopplingar eller relationer mellan poster - via ParentProcessId - så en fullständig hierarki av processer kan erhållas.

Om du har läst serien "The Adventures of the Elusive Malware" du vet att hackare älskar att skapa komplexa attacker i flera steg, där varje process spelar sin egen lilla roll och förbereder en språngbräda för nästa steg. Sådana saker är extremt svåra att fånga helt enkelt från den "råa" stocken.
Men med mitt Get-Sysmonlogs-kommando och en ytterligare datastruktur som vi ska titta på längre fram i texten (en graf förstås), har vi ett praktiskt sätt att upptäcka hot – vilket bara kräver att man gör rätt vertexsökning.
Som alltid med våra DYI-bloggprojekt, ju mer du arbetar med att analysera detaljerna i hot i liten skala, desto mer kommer du att inse hur komplex hotdetektion är på företagsnivå. Och denna medvetenhet är extremt viktig poäng.

Vi kommer att möta de första intressanta komplikationerna i den andra delen av artikeln, där vi kommer att börja koppla Sysmon-händelser med varandra till mycket mer komplexa strukturer.

Källa: will.com