Hierdie artikel is die eerste deel van 'n reeks oor die ontleding van Sysmon-bedreigings. Alle ander dele van die reeks:
Deel 1. Inleiding tot die ontleding van Sysmon-logboeke (ons is hier)
Deel 2. Die gebruik van data van Sysmon Events om bedreigings op te spoor
Deel 3: Diep Sysmon-bedreigingsanalise met grafieke
As jy by inligtingsekuriteit betrokke is, moet jy waarskynlik die voortdurende aanvalle verstaan. As jy reeds 'n geoefende oog het, kan jy soek vir nie-standaard aktiwiteit in die "rou" rou logs - sê, 'n PowerShell script wat loop of 'n VBS-skrip wat voorgee om 'n Word-lêer te wees deur net deur die nuutste aktiwiteit in die Windows-gebeurtenislog te blaai. Maar dit is 'n baie groot kopseer. Gelukkig het Microsoft Sysmon geskep, wat aanvalontleding baie makliker maak.
Wil jy die basiese idees agter die bedreigings wat in die Sysmon-logboek vertoon word, verstaan? Laai ons gids af en jy besef hoe ingewydes ander werknemers in die geheim kan spioeneer. Die grootste probleem met die werk met die Windows-gebeurtenislogboek is die gebrek aan inligting oor ouerprosesse, d.w.s. dit is onmoontlik om die hiërargie van prosesse daaruit te verstaan. Die Sysmon-loginskrywings, aan die ander kant, bevat die ouer se proses-ID, sy naam en die opdragreël wat uitgevoer word. Dankie Microsoft.
In die eerste deel van ons reeks sal ons sien wat ons met basiese inligting van Sysmon kan doen. In deel twee sal ons die ouerprosesinligting ten volle benut om meer komplekse voldoeningstrukture bekend as bedreigingsgrafieke te skep. In die derde deel sal ons kyk na 'n eenvoudige algoritme wat die bedreigingsgrafiek skandeer vir nie-standaardaktiwiteit deur die ontleding van die "gewig" van die grafiek. En op die ou end, as 'n beloning, sal jy 'n netjiese (en verstaanbare) waarskynlikheidsmetode vind om bedreigings op te spoor.
Deel 1: Stel Sysmon Log Analysis bekend
Wat sal help om die kompleksiteit van die gebeurtenislogboek te verstaan? Uiteindelik, SIEM. Dit normaliseer gebeure en vereenvoudig hul daaropvolgende ontleding. Maar ons hoef nie so ver te gaan nie, ten minste eers. In die begin, om die beginsels van SIEM te verstaan, sal dit genoeg wees om die wonderlike gratis Sysmon-hulpprogram te probeer. En sy is verbasend maklik om mee te werk. Hou so aan, Microsoft!
Wat is die kenmerke van Sysmon?
Kortliks, nuttige en leesbare inligting oor prosesse (sien prente hieronder). Jy sal 'n klomp nuttige besonderhede vind wat nie in die Windows-gebeurtenislogboek is nie, maar die belangrikste is die volgende velde:
- Proses ID (in desimale, nie hex!)
- Ouer proses ID
- Verwerk opdragreël
- Ouer proses opdragreël
- Lêer prent hash
- Lêerbeeldname
Sysmon word terselfdertyd as 'n toestelbestuurder en 'n diens geïnstalleer - kom meer te wete Die belangrikste voordeel daarvan is die vermoë om logs van te ontleed van 'n paar bronne, korrelasie van inligting en uitvoer van die resulterende waardes in een gids van die gebeurtenislogboek, geleë langs die pad Microsoft -> Windows -> Sysmon -> Bedryf. In my eie harelose ondersoeke na die Windows-logboeke moes ek voortdurend wissel tussen byvoorbeeld die PowerShell-logboeklêer en die Security-lêergids, deur die gebeurtenislogboeke te blaai in 'n heldhaftige poging om die waardes tussen hulle op een of ander manier te karteer. Dit is nooit 'n maklike taak nie, en soos ek later besef het, was dit beter om dadelik aspirien aan te skaf.
Sysmon, aan die ander kant, neem 'n kwalitatiewe sprong vorentoe deur nuttige (of, soos verkopers wil sê, uitvoerbare) inligting te verskaf om jou te help om die onderliggende prosesse te verstaan. Ek het byvoorbeeld 'n versteekte sessie begin , wat die beweging van 'n slim insider binne die netwerk simuleer. Hier is wat jy in die Windows Event Log sal sien:
Sommige inligting oor die proses is sigbaar in die Windows-logboek, maar dit is van min nut. Plus proses ID's in hex???
Vir 'n professionele IT-professionele met 'n begrip van die basiese beginsels van inbraak, moet die opdragreël verdag wees. Gebruik cmd.exe om dan 'n ander opdrag uit te voer met uitvoer wat herlei word na 'n lêer met 'n vreemde naam - dit is duidelik soortgelyk aan die aksies van sagteware vir beheer en bestuur : Op hierdie manier word 'n pseudo-dop geskep deur WMI-dienste te gebruik.
Kom ons kyk nou na die ekwivalent van 'n Sysmon-inskrywing, en let op hoeveel ekstra inligting dit vir ons gee:
Sysmon-funksies in een skermkiekie: gedetailleerde inligting oor die proses in 'n leesbare vorm
Jy sien nie net die opdragreël nie, maar ook die lêernaam, die pad na die uitvoerbare toepassing, wat Windows daarvan weet ("Windows Command Processor"), die identifiseerder ouerlike proses, opdragreël ouer, wat die cmd-dop geloods het, sowel as die regte lêernaam van die ouerproses. Alles op een plek, uiteindelik!
Uit die Sysmon-logboek kan ons aflei dat met 'n hoë mate van waarskynlikheid hierdie verdagte opdragreël, wat ons in die "rou" logs gesien het, nie die resultaat van die werknemer se normale werk is nie. Dit is eerder gegenereer deur 'n C2-agtige proses - wmiexec, soos ek vroeër genoem het - en is direk voortgebring deur die diens se WMI-proses (WmiPrvSe). Nou het ons 'n aanduiding dat 'n afgeleë aanvaller of insider die korporatiewe infrastruktuur vir 'n tand probeer.
Stel Get-Sysmonlogs bekend
Dit is natuurlik wonderlik as Sysmon logs op een plek het. Maar dit sal waarskynlik selfs beter wees as ons toegang tot individuele logvelde programmaties kan kry - byvoorbeeld deur PowerShell-opdragte. In hierdie geval sou dit moontlik wees om 'n klein PowerShell-skrif te skryf wat die soektog na potensiële bedreigings sal outomatiseer!
Ek was nie die eerste wat hierdie idee gehad het nie. En dit is goed dat dit in sommige forumplasings en GitHub is dit is reeds verduidelik hoe om PowerShell te gebruik om die Sysmon-logboek te ontleed. In my geval wou ek vermy dat ek aparte reëls ontledingskrip vir elke Sysmon-veld hoef te skryf. Ek het dus die lui man-beginsel gebruik en ek dink ek het gevolglik met iets interessants vorendag gekom.
Die eerste belangrike punt is die vermoë van die opdrag lees Sysmon-logboeke, filter die nodige gebeurtenisse en vertoon die resultaat in 'n PS-veranderlike, soos volg:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
As jy self die opdrag wil toets, deur die inhoud in die eerste element van die $events-skikking, $events[0] te vertoon. Boodskap, kan jy 'n reeks teksstringe met 'n baie eenvoudige formaat uitvoer: die naam van die Sysmon veld, 'n dubbelpunt, en dan die waarde self.
Hoera! Sysmon-logboekuitset in JSON-gereed-formaat
Dink jy dieselfde ding as ek? Met 'n bietjie meer moeite kan jy die uitvoer na 'n JSON-geformateerde string omskakel en dit dan direk in 'n PS-voorwerp laai met die kragtige opdrag .
Ek sal die PowerShell-kode vir die omskakeling wys - dit is baie eenvoudig - in die volgende deel. Kom ons kyk vir eers na wat my nuwe opdrag genaamd get-sysmonlogs, wat ek as 'n PS-module geïnstalleer het, kan doen.
In plaas daarvan om dieper te delf in Sysmon log-analise deur die ongemaklike gebeurtenislog-koppelvlak, kan ons moeiteloos soek na inkrementele aktiwiteit direk vanaf 'n PowerShell-sessie, en ook die PS-opdrag gebruik (alias - "?") om die soekresultate te verkort:
Lys van cmd-skulpe wat via WMI bekendgestel is. Bedreigingsanalise goedkoop met ons eie Get-Sysmonlogs-span
Wonderlike! Ek het 'n Sysmon-log-peilingsinstrument geskep asof dit 'n databasis is. In ons artikel oor Daar is opgemerk dat hierdie funksie uitgevoer sal word deur die koel nut wat daarin beskryf word, hoewel formeel deur 'n regte SQL-agtige koppelvlak. Ja, ECL grasieus, maar ons sal dit in die derde deel aanraak.
Sysmon en grafiek analise
Kom ons abstraheer en dink oor wat ons pas geskep het. In wese het ons nou 'n Windows-gebeurtenisdatabasis wat via PowerShell toeganklik is. Soos ek vroeër opgemerk het, is daar verbande of verwantskappe tussen rekords - deur ParentProcessId - sodat jy 'n volledige hiërargie van prosesse kan kry.
As jy die reeks gelees het dan weet jy dat kuberkrakers daarvan hou om komplekse multi-stadium aanvalle te skep waarin elke proses sy klein rol speel en 'n springplank voorberei vir die volgende stap. Sulke goed is uiters moeilik om net uit die "rou" log te vang.
Maar met my Get-Sysmonlogs-opdrag en 'n bykomende datastruktuur waarna ons later in die teks sal kyk (natuurlik 'n grafiek), het ons 'n praktiese manier om bedreigings op te spoor - wat net 'n behoorlike hoekpuntsoektog vereis.
Soos altyd in ons DYI-blogprojekte, hoe meer jy daaraan werk om die besonderhede van bedreigings op 'n klein skaal te ontleed, hoe meer sal jy besef hoe moeilik dit is om bedreigings op organisasievlak op te spoor. En hierdie besef is uiters belangrike punt.
Ons sal die eerste interessante kompleksiteite in die tweede deel van die artikel teëkom, waar ons sal begin om Sysmon-gebeure met mekaar te verbind in baie meer komplekse strukture.
Bron: will.com