Ĉi tiu artikolo estas la unua parto de serio pri Sysmon minacanalizo. Ĉiuj aliaj partoj de la serio:
Parto 1: Enkonduko al Sysmon Log Analysis (ni estas ĉi tie)
Parto 2: Uzante Sysmon Event Datumojn por Identigi Minacojn
Parto 3. Profunda analizo de Sysmon-minacoj uzante grafikaĵojn
Se vi laboras en informa sekureco, vi verŝajne ofte devas kompreni daŭrajn atakojn. Se vi jam havas trejnitan okulon, vi povas serĉi nenorman agadon en la "krudaj" neprilaboritaj protokoloj - ekzemple, PowerShell-skripto funkcianta. aŭ VBS-skripto ŝajniganta esti Word-dosiero - simple rulumante la plej novan agadon en la Vindoza okazaĵprotokolo. Sed ĉi tio estas vere granda kapdoloro. Feliĉe, Mikrosofto kreis Sysmon, kiu multe plifaciligas atakan analizon.
Ĉu vi volas kompreni la bazajn ideojn malantaŭ la minacoj montritaj en la protokolo de Sysmon? Elŝutu nian gvidilon kaj vi rimarkas, kiel internuloj povas kaŝe observi aliajn dungitojn. La ĉefa problemo pri laborado kun la Vindoza evento-protokolo estas la manko de informoj pri gepatraj procezoj, t.e. estas neeble kompreni la hierarkion de procezoj el ĝi. Sysmon protokolaj enskriboj, aliflanke, enhavas la gepatran procezidentigilon, ĝian nomon, kaj la komandlinion por esti lanĉita. Dankon, Microsoft.
En la unua parto de nia serio, ni rigardos kion vi povas fari kun bazaj informoj de Sysmon. En Parto XNUMX, ni plene profitos de gepatra procezo-informoj por krei pli kompleksajn plenumajn strukturojn konatajn kiel minacaj grafikoj. En la tria parto, ni rigardos simplan algoritmon, kiu skanas minacan grafeon por serĉi nekutiman agadon analizante la "pezon" de la grafeo. Kaj ĉe la fino, vi estos rekompencita per neta (kaj komprenebla) probabla minaca detekto-metodo.
Parto 1: Enkonduko al Sysmon Log Analysis
Kio povas helpi vin kompreni la kompleksecon de la evento-protokolo? Finfine - SIEM. Ĝi normaligas eventojn kaj simpligas ilian postan analizon. Sed ni ne devas iri tiom malproksimen, almenaŭ ne komence. Komence, por kompreni la principojn de SIEM, sufiĉos provi la mirindan senpagan ilon Sysmon. Kaj kun ŝi estas surprize facile labori. Daŭrigu ĝin, Microsoft!
Kiajn funkciojn Sysmon havas?
Resume - utilaj kaj legeblaj informoj pri la procezoj (vidu bildojn sube). Vi trovos multajn utilajn detalojn, kiuj ne estas en la Vindoza Event Log, sed la plej gravaj estas la sekvaj kampoj:
- Proceza ID (en decimala, ne heks!)
- Gepatra procezo ID
- Procezi komandlinion
- Komandlinio de la gepatra procezo
- Dosiera bildo hash
- Dosieraj bildoj nomoj
Sysmon estas instalita kaj kiel aparata pelilo kaj kiel servo - pli da detaloj Ĝia ŝlosila avantaĝo estas la kapablo analizi ŝtipojn de pluraj fontoj, korelacio de informoj kaj eligo de rezultaj valoroj al unu eventa protokolo-dosierujo situanta laŭ la vojo Microsoft -> Vindozo -> Sysmon -> Funkcia. En miaj propraj haraj esploroj pri Vindozaj protokoloj, mi konstante devis ŝanĝi inter, ekzemple, la dosierujo de la protokoloj de PowerShell kaj la dosierujo de Sekureco, trarigardante la evento-protokolojn en kuraĝa provo iel korelacii la valorojn inter ambaŭ. . Ĉi tio neniam estas facila tasko, kaj kiel mi poste konstatis, estis pli bone tuj provizi per aspirino.
Sysmon faras kvantuman salton antaŭen provizante utilajn (aŭ kiel vendistoj ŝatas diri, ageblaj) informojn por helpi kompreni subestajn procezojn. Ekzemple, mi komencis sekretan sesion , simulante la movadon de inteligenta internulo ene de la reto. Jen kion vi vidos en la Vindoza evento-protokolo:
La Vindoza protokolo montras kelkajn informojn pri la procezo, sed ĝi malmulte utilas. Plus procesaj identigiloj en deksesuma???
Por profesia IT-profesiulo kun kompreno de la bazoj de hakado, la komandlinio devus esti suspektinda. Uzi cmd.exe por tiam ruli alian komandon kaj redirekti la eligon al dosiero kun stranga nomo estas klare simila al la agoj de monitorado kaj kontrola programaro. : Tiamaniere, pseŭdoŝelo estas kreita uzante WMI-servojn.
Nun ni rigardu la ekvivalenton de Sysmon, rimarkante kiom da pliaj informoj ĝi donas al ni:
Sysmon-funkcioj en unu ekrankopio: detalaj informoj pri la procezo en legebla formo
Vi ne nur vidas la komandlinion, sed ankaŭ la dosiernomon, la vojon al la plenumebla aplikaĵo, kion Vindozo scias pri ĝi ("Windows Command Processor"), la identigilon. gepatra procezo, komandlinio gepatro, kiu lanĉis la cmd-ŝelon, same kiel la realan dosiernomon de la gepatra procezo. Ĉio en unu loko, finfine!
El la protokolo de Sysmon ni povas konkludi, ke kun alta probablo ĉi tiu suspektinda komandlinio, kiun ni vidis en la "krudaj" protokoloj, ne estas la rezulto de la normala laboro de la dungito. Tute male, ĝi estis generita de C2-simila procezo - wmiexec, kiel mi menciis pli frue - kaj estis rekte generita de la WMI-serva procezo (WmiPrvSe). Nun ni havas indikilon, ke fora atakanto aŭ internulo provas la kompanian infrastrukturon.
Enkonduko de Get-Sysmonlogs
Kompreneble estas bonege kiam Sysmon metas la protokolojn en unu lokon. Sed verŝajne estus eĉ pli bone, se ni povus aliri individuajn protokolkampojn programe - ekzemple per PowerShell-komandoj. En ĉi tiu kazo, vi povus skribi malgrandan PowerShell-skripton, kiu aŭtomatigus la serĉon de eblaj minacoj!
Mi ne estis la unua, kiu havis tian ideon. Kaj estas bone, ke en iuj forumaj afiŝoj kaj GitHub Jam estis klarigite kiel uzi PowerShell por analizi la protokolon de Sysmon. En mia kazo, mi volis eviti devi skribi apartajn liniojn de analiza skripto por ĉiu Sysmon-kampo. Do mi uzis la maldiligentan principon kaj mi pensas, ke mi elpensis ion interesan kiel rezulto.
La unua grava punkto estas la kapablo de la teamo legu Sysmon-protokolojn, filtru la necesajn eventojn kaj eligu la rezulton al la PS-variablo, kiel ĉi tie:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Se vi volas mem testi la komandon, montrante la enhavon en la unua elemento de la tabelo $events, $events[0].Mesaĝo, la eligo povas esti serio de tekstaj ĉenoj kun tre simpla formato: la nomo de la Sysmon-kampo, dupunkto, kaj tiam la valoro mem.
Hura! Eligo de Sysmon-protokolo en JSON-pretan formaton
Ĉu vi pensas same kiel mi? Kun iom pli da peno, vi povas konverti la eligon en JSON-formatan ĉenon kaj poste ŝargi ĝin rekte en PS-objekton per potenca komando. .
Mi montros la PowerShell-kodon por la konvertiĝo - ĝi estas tre simpla - en la sekva parto. Nuntempe, ni vidu, kion mia nova komando nomata get-sysmonlogs, kiun mi instalis kiel PS-modulo, povas fari.
Anstataŭ plonĝi profunde en la analizon de la protokolo de Sysmon per maloportuna interfaco de protokolo de eventoj, ni povas senpene serĉi pliigan agadon rekte de sesio de PowerShell, kaj ankaŭ uzi la komandon PS. (kaŝnomo – “?”) por mallongigi la serĉrezultojn:
Listo de cmd-ŝeloj lanĉitaj per WMI. Analizo de Minaco sur la Malmultekosta kun Nia Propra Get-Sysmonlogs Teamo
Mirinda! Mi kreis ilon por sondi la Sysmon-protokolo kvazaŭ ĝi estus datumbazo. En nia artikolo pri oni rimarkis, ke ĉi tiu funkcio estos plenumita per la malvarmeta utileco priskribita en ĝi, kvankam formale ankoraŭ per reala SQL-simila interfaco. Jes, EQL eleganta, sed ni tuŝos ĝin en la tria parto.
Sysmon kaj grafika analizo
Ni retroiru kaj pensu pri tio, kion ni ĵus kreis. Esence, ni nun havas Vindozan eventan datumbazon alirebla per PowerShell. Kiel mi notis pli frue, ekzistas ligoj aŭ rilatoj inter rekordoj - per la ParentProcessId - do kompleta hierarkio de procezoj povas esti akirita.
Se vi legis la serion vi scias, ke hackers amas krei kompleksajn plurfazajn atakojn, en kiuj ĉiu procezo ludas sian propran malgrandan rolon kaj preparas saltotablon por la sekva paŝo. Estas ege malfacile kapti tiajn aferojn simple el la "kruda" protokolo.
Sed kun mia komando Get-Sysmonlogs kaj plia datumstrukturo, kiun ni rigardos poste en la teksto (grafikaĵo, kompreneble), ni havas praktikan manieron detekti minacojn - kio nur postulas fari la ĝustan vertican serĉon.
Kiel ĉiam kun niaj DYI-blogaj projektoj, ju pli vi laboras pri analizado de la detaloj de minacoj malgrandskale, des pli vi rimarkos kiom kompleksa minaco-detekto estas sur la entreprena nivelo. Kaj ĉi tiu konscio estas ekstreme grava punkto.
Ni renkontos la unuajn interesajn komplikaĵojn en la dua parto de la artikolo, kie ni komencos kunligi Sysmon-eventojn unu kun la alia en multe pli kompleksajn strukturojn.
fonto: www.habr.com