Acest articol este prima parte a unei serii consacrate analizei amenințărilor Sysmon. Toate celelalte părți ale seriei:
Partea 1. Introducere în analiza jurnalelor Sysmon (noi suntem aici)
Partea 2. Utilizarea datelor din evenimentele Sysmon pentru identificarea amenințărilor
Partea 3. Analiza aprofundată a amenințărilor Sysmon folosind grafuri
Dacă te ocupi de securitate informațională, probabil că trebuie să te confrunți adesea cu atacurile în desfășurare. Dacă ai deja un ochi antrenat, poți căuta activitate neobișnuită în jurnalele 'neprelucrate' — de exemplu, un script PowerShell rulat cu sau un script VBS, care se dă drept fișier Word, — răsfoind doar ultimele activități în jurnalul de evenimente Windows. Dar asta este cu adevărat o mare durere de cap. Din fericire, Microsoft a creat Sysmon, care face analiza atacurilor mult mai simplă.
Vrei să înțelegi conceptele de bază din spatele amenințărilor afișate în jurnalul Sysmon? Descarcă ghidul nostru și vei realiza cum insiderii pot observa discret ceilalți angajați. Principala problemă cu jurnalul de evenimente Windows este lipsa informațiilor despre procesele părinte, adică nu poți înțelege ierarhia proceselor. În schimb, în înregistrările jurnalului Sysmon, se conțin identificatorul procesului părinte, numele său și linia de comandă executată. Îți mulțumim, Microsoft.
În prima parte a seriei noastre, vom explora ce se poate face cu informațiile de bază din Sysmon. În a doua parte, ne vom folosi pe deplin de informațiile despre procesele părinte pentru a crea structuri de conformitate mai complexe, cunoscute sub numele de grafuri de amenințări. În a treia parte, vom analiza un algoritm simplu care scanează grafurile de amenințări pentru a căuta activitate neobișnuită prin analiza 'greutății' grafului. Iar la final, ca recompensă, te așteaptă o metodă probabilistică clară (și ușor de înțeles) pentru detectarea amenințărilor.
Partea 1: Introducere în analiza jurnalelor Sysmon
Ce poate ajuta să înțelegem complexitățile jurnalului de evenimente? În cele din urmă – SIEM. Aceasta normalizează evenimentele și facilitează analiza ulterioară a acestora. Dar nu trebuie să mergem atât de departe, cel puțin la început. La început, pentru a înțelege principiile SIEM, ar fi suficient să încercăm minunatul instrument gratuit Sysmon. Și este surprinzător de ușor de utilizat. Bravo, Microsoft!
Ce funcționalități are Sysmon?
Pe scurt – informații utile și ușor de citit despre procese (vezi imaginile de mai jos). Vei descoperi o mulțime de detalii utile care nu apar în jurnalul de evenimente Windows, dar cel mai important – următoarele câmpuri:
- ID-ul procesului (în formă zecIMALĂ, nu hex!)
- ID-ul procesului părinte
- Linia de comandă a procesului
- Linia de comandă a procesului părinte
- Hash-ul imaginii fișierului
- Numel fișierelor imaginii
Sysmon este instalat simultan ca driver de dispozitiv și ca serviciu – detalii suplimentare Principalul său avantaj este capacitatea de a analiza jurnalele din mai multe surse, corelarea informațiilor și generarea valorilor rezultante într-un singur folder de jurnal de evenimente, situat la calea Microsoft -> Windows -> Sysmon -> Operational. În propriile mele investigații asupra jurnalele Windows, care îmi făceau părul să se ridice, a trebuit constant să comut între, să zicem, folderul cu jurnalele PowerShell și folderul „Securitate”, derulând jurnalele de evenimente într-o încercare eroică de a asocia valorile între ele. Aceasta nu este o sarcină ușoară și, așa cum am realizat ulterior, ar fi fost mai bine să am din timp aspirină.
Sysmon face totuși un salt calitativ înainte, oferind informații utile (sau, cum spun furnizorii – eficiente) pentru a ajuta la înțelegerea proceselor fundamentale. De exemplu, am lansat o sesiune ascunsă , simulând mișcarea unui insider inteligent în rețea. Iată ce vei vedea în jurnalul de evenimente Windows:
În jurnalul Windows apare o anumită informație despre proces, dar aceasta este puțin utilă. În plus, identificatorii proceselor sunt în format hex???
La un specialist IT profesionist, care înțelege principiile hacking-ului, ar trebui să stârnească suspiciuni linia de comandă. Utilizarea cmd.exe pentru a lansa ulterior o altă comandă cu redirecționarea ieșirii într-un fișier cu un nume ciudat – pare evident a fi acțiuni de software de control și management : în acest mod se creează un pseudo-shell folosind serviciile WMI.
Acum să ne uităm la echivalentul înregistrării din Sysmon, observând cât de multe informații suplimentare ne oferă:
Capabilitățile Sysmon într-o captură de ecran: informații detaliate despre proces într-o formă lizibilă
Nu doar că vezi linia de comandă, ci și numele fișierului, calea către aplicația executabilă, ce știe Windows despre aceasta („Windows Command Processor”), identificatorul procesului părinte , linia de comandă a părintelui, care a lansat shell-ul cmd, precum și numele real al fișierului procesului părinte. Totul într-un singur loc, în sfârșit!
Din logul Sysmon putem concluziona că, cu o mare probabilitate, această linie de comandă suspectă pe care am văzut-o în logurile „neprelucrate” nu este rezultatul unei activități normale a unui angajat. Mai degrabă, a fost generată de un proces asemănător C2 — wmiexec, așa cum am menționat anterior — și a fost generat direct de procesul WMI al serviciului (WmiPrvSe). Acum avem un indicator că un atacator remote sau un insider încearcă să testeze infrastructura corporativă.
Prezentăm Get-Sysmonlogs
Desigur, este minunat când Sysmon are logurile într-un singur loc. Dar ar fi, probabil, și mai bine dacă am putea accesa câmpurile individuale ale logului prin metode programatice - de exemplu, prin comenzi PowerShell. În acest caz, am putea scrie un mic script PowerShell care să automatizeze căutarea de amenințări potențiale!
Nu am fost primul care a avut această idee. Și este bine că în unele postări de pe forumuri și GitHub deja este explicat cum să folosești PowerShell pentru a parsa logul Sysmon. În cazul meu, am vrut să evit necesitatea de a scrie linii separate de script parsing pentru fiecare câmp Sysmon. Prin urmare, am folosit principiul omului leneș și, după cum mi se pare, am reușit să inventez ceva interesant.
Primul aspect important este posibilitatea comenzii de a citi logurile Sysmon, filtra evenimentele necesare și a afișa rezultatul într-o variabilă PS, ca aici:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Dacă doriți să verificați personal funcționarea echipei, puteți obține o serie de șiruri de text cu un format foarte simplu din vizualizarea conținutului primului element al array-ului $events, $events[0].Message.
Ura! Iată ieșirea log-ului Sysmon într-un format pregătit pentru JSON.
Te gândești la același lucru la care mă gândesc și eu? Aplicând câteva eforturi suplimentare, putem converti ieșirea într-un șir formatat pentru JSON și apoi să-l încărcăm direct într-un obiect PS cu ajutorul comenzii puternice. .
Voi arăta codul PowerShell pentru conversie — este foarte simplu — în partea următoare. Între timp, să ne uităm la ce poate face noua mea comandă numită get-sysmonlogs, pe care am instalat-o ca modul PS.
În loc să ne aprofundăm în analiza log-urilor Sysmon printr-o interfață incomodă a jurnalului de evenimente, putem căuta fără efort activitatea incrementată direct din sesiunea PowerShell, folosind și comanda PS. (alias – „?”) pentru a scurta rezultatele afișării:
Lista shell-urilor cmd care au fost rulate prin WMI. Analiza amenințărilor la un preț accesibil cu ajutorul propriei noastre comenzi Get-Sysmonlogs.
Minunat! Am creat un instrument de interogare a log-ului Sysmon, ca și cum ar fi fost o bază de date. În articolul nostru despre s-a menționat că această funcție va fi îndeplinită de utilitarul cool descris acolo, chiar dacă formal totuși printr-o interfață similară SQL. Da, EQL este elegant, dar vom discuta despre el în partea a treia.
Sysmon și analiza grafurilor
Să ne abstractizăm și să ne gândim la ceea ce tocmai am creat. Practic, acum avem o bază de date de evenimente Windows, accesibilă prin PowerShell. Așa cum am menționat anterior, există conexiuni sau legături între înregistrări — prin ParentProcessId — astfel încât putem obține o ierarhie completă a proceselor.
Dacă ați citit seria atunci știți că hackerii adoră să creeze atacuri complexe, în care fiecare proces îndeplinește un mic rol și pregătește terenul pentru următorul pas. Astfel de lucruri sunt extrem de greu de prins doar din log-ul „branșat”.
Dar cu comanda mea Get-Sysmonlogs și structura de date suplimentară pe care o vom explora mai departe (desigur, aceasta este un grafic), vom avea o modalitate practică de a descoperi amenințările — pentru care este nevoie doar de a efectua căutarea corectă în vârfuri.
Așa cum se întâmplă întotdeauna în proiectele noastre de blog DYI, cu cât lucrați mai mult la analiza detaliilor amenințărilor la o scară mică, cu atât mai bine înțelegeți cât de complexă este detectarea amenințărilor la nivel organizațional. Și această conștientizare este extrem de importantă.
Vom întâlni primele dificultăți interesante în a doua parte a articolului, unde vom începe să corelăm evenimentele Sysmon într-o structură mult mai complexă.
Sursa: habr.com
