Stația de lucru utilizatorului este cel mai vulnerabil loc din infrastructură în ceea ce privește securitatea informațională. Utilizatorii pot primi pe e-mailuri de serviciu mesaje care par a proveni dintr-o sursă sigură, dar conțin linkuri către site-uri infectate. Este posibil ca cineva să descarce un utilitar util dintr-o sursă necunoscută. Se pot imagina nenumărate cazuri în care malware-ul poate pătrunde în resursele interne prin intermediul utilizatorilor. Prin urmare, stațiile de lucru necesită o atenție sporită, iar în acest articol vom discuta despre sursele și evenimentele pe care trebuie să le monitorizăm pentru a urmări atacurile.
Pentru a identifica un atac în cea mai timpurie etapă, în sistemul de operare Windows există trei surse utile de evenimente: jurnalul de evenimente de securitate, jurnalul de monitorizare a sistemului și jurnalele PowerShell.
Jurnalul de evenimente de securitate (Security Log)
Acesta este principalul loc de stocare a jurnalele de securitate ale sistemului. Aici sunt înregistrate evenimentele de logare/dezlogin ale utilizatorilor, accesul la obiecte, modificările politicilor și alte activități legate de securitate. Desigur, cu condiția ca politica corespunzătoare să fie configurată.
Enumerarea utilizatorilor și grupurilor (evenimentele 4798 și 4799). Malware-ul, la începutul atacului, verifică adesea conturile locale de utilizator și grupurile locale pe stația de lucru pentru a găsi acreditive pentru faptele sale necurate. Aceste evenimente pot ajuta la descoperirea codului malițios înainte ca acesta să avanseze și, folosind informațiile colectate, să se răspândească la alte sisteme.
Crearea unui cont local și modificări în grupurile locale (evenimentele 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 și 5377). Atacul poate începe, de exemplu, prin adăugarea unui nou utilizator în grupul administratorilor locali.
Încercări de logare cu un cont local (evenimentul 4624). Utilizatorii corecți se conectează cu un cont de domeniu, iar identificarea unei logări cu un cont local poate însemna începutul unui atac. Evenimentul 4624 include, de asemenea, logările cu conturi de domeniu, așa că, în timpul procesării evenimentelor, trebuie filtrate evenimentele în care domeniul diferă de numele stației de lucru.
Încercare de logare cu un cont specific (evenimentul 4648). Acest lucru se întâmplă când procesul este executat în modul „Executare ca” (run as). În mod normal, în condiții de funcționare a sistemului, acest lucru nu ar trebui să se întâmple, așa că astfel de evenimente trebuie să fie monitorizate.
Blochează/Dezbloază stația de lucru (evenimente 4800-4803). Orice acțiuni care au avut loc pe o stație de lucru blocată pot fi considerate evenimente suspecte.
Modificări ale configurației firewall-ului (evenimente 4944-4958). Este evident că, în timpul instalării unui nou software, setările de configurare ale firewall-ului se pot schimba, ceea ce va provoca false alerte. În cele mai multe cazuri, nu este necesar să monitorizăm aceste schimbări, dar a fi conștient de ele nu strică.
Conectarea dispozitivelor Plug’n’play (eveniment 6416 și doar pentru Windows 10). Este important să monitorizăm acest lucru dacă utilizatorii în mod normal nu conectează noi dispozitive la stația de lucru, iar acum, dintr-o dată, au conectat unul.
Windows include 9 categorii de audit și 50 de subcategorii pentru o configurare fină. Setul minim de subcategorii care ar trebui activat în setări este:
Autentificare/Dezautentificare
- Autentificare;
- Dezautentificare;
- Blocarea contului;
- Alte evenimente de autentificare/dezautentificare.
Gestionarea conturilor
- Gestionarea contului de utilizator;
- Gestionarea grupurilor de securitate.
Schimbarea politicii
- Schimbarea politicii de audit;
- Schimbarea politicii de autentificare;
- Schimbarea politicii de autorizare.
Monitorizarea sistemului (Sysmon)
Sysmon este un utilitar integrat în Windows care poate înregistra evenimente în jurnalul sistemului. De obicei, este necesar să fie instalat separat.
Aceste evenimente pot fi, în principiu, găsite și în jurnalul de securitate (activând politica de audit corespunzătoare), dar Sysmon oferă mai multe detalii. Ce evenimente pot fi extrase din Sysmon?
Crearea unui proces (ID eveniment 1). Jurnalul de evenimente de securitate al sistemului poate spune, de asemenea, când a fost lansat un anumit *.exe și poate chiar să arate numele și calea de lansare. Dar, spre deosebire de Sysmon, nu poate arăta hash-ul aplicației. Malware-ul poate purta un nume inofensiv, cum ar fi notepad.exe, dar hash-ul va dezvălui adevărata sa identitate.
Conexiuni de rețea (ID eveniment 3). Este evident că sunt multe conexiuni de rețea și nu este posibil să le monitorizăm pe toate. Dar este important de menționat că Sysmon, spre deosebire de Security Log, poate corela conexiunea de rețea cu câmpurile ProcessID și ProcessGUID, arătând portul și adrese IP sursele și destinațiile.
Modificări în registrul de sistem (ID eveniment 12-14). Cea mai simplă modalitate de a te adăuga în pornire automată este să te înscrii în registru. Security Log poate face asta, dar Sysmon arată cine a efectuat modificările, când, de unde, ID-ul procesului și valoarea anterioară a cheii.
Crearea fișierului (ID eveniment 11). Sysmon, spre deosebire de Security Log, va arăta nu doar locația fișierului, ci și numele acestuia. Este clar că nu poți urmări totul, dar este posibil să se efectueze un audit al anumitor directoare.
Și acum, ceea ce nu se regăsește în politicile Security Log, dar se găsește în Sysmon:
Modificarea timpului de creare a fișierului (ID eveniment 2). Unele programe malware pot schimba data de creare a fișierului pentru a-l ascunde din rapoartele cu fișiere recent create.
Încărcarea driverelor și bibliotecilor dinamice (ID evenimente 6-7). Urmărirea încărcării în memorie a DLL-urilor și driverelor de dispozitive, verificarea semnăturii digitale și a validității acesteia.
Crearea unui fir în procesul executabil (ID eveniment 8). Un tip de atac care trebuie de asemenea monitorizat.
Evenimente RawAccessRead (ID eveniment 9). Operațiunile de citire de pe disc utilizând ‘.’. În majoritatea cazurilor, această activitate ar trebui considerată anormală.
Crearea unui flux de fișier denumit (ID eveniment 15). Evenimentul este înregistrat atunci când se creează un flux de fișier denumit, care generează evenimente cu hash-ul conținutului fișierului.
Crearea unui pipe denumit și conexiuni (ID evenimente 17-18). Urmărirea codului malware care comunică cu alte componente prin intermediul unui pipe denumit.
Activitate WMI (ID eveniment 19). Înregistrarea evenimentelor care sunt generate atunci când se accesează sistemul prin protocolul WMI.
Pentru a proteja Sysmon, trebuie să monitorizezi evenimentele cu ID 4 (oprirea și pornirea Sysmon) și ID 16 (modificarea configurației Sysmon).
Jurnalele Power Shell
Power Shell este un instrument puternic de gestionare a infrastructurii Windows, astfel că există șanse mari ca atacatorul să îl aleagă. Pentru a obține date despre evenimentele Power Shell pot fi folosite două surse: log-ul Windows PowerShell și log-ul Microsoft-WindowsPowerShell / Operational.
Log-ul Windows PowerShell
Furnizor de date încărcat (ID eveniment 600). Furnizorii PowerShell sunt programe care servesc ca sursă de date pentru PowerShell pentru a le vizualiza și gestiona. De exemplu, furnizorii încorporați pot fi variabilele de mediu Windows sau registrul de sistem. Este important să urmăriți apariția de noi furnizori pentru a detecta la timp activitățile malițioase. De exemplu, dacă observați că între furnizori a apărut WSMan, înseamnă că a fost inițiată o sesiune PowerShell de la distanță.
Jurnalul Microsoft-WindowsPowerShell / Operational (sau MicrosoftWindows-PowerShellCore / Operational în PowerShell 6)
Jurnalizarea modulelor (ID eveniment 4103). Evenimentele stochează informații despre fiecare comandă executată și parametrii cu care a fost apelată.
Jurnalizarea blocării scripturilor (ID eveniment 4104). Jurnalizarea blocării scripturilor arată fiecare bloc de cod PowerShell executat. Chiar dacă un atacator încearcă să ascundă comanda, acest tip de eveniment va arăta efectiv comanda PowerShell executată. De asemenea, în acest tip de eveniment pot fi înregistrate anumite apeluri API de nivel jos; aceste evenimente sunt de obicei înregistrate ca Verbose, dar dacă o comandă sau un script suspect este utilizat într-un bloc de cod, acesta va fi înregistrat cu severitate Warning.
Rețineți că după configurarea instrumentului de colectare și analiză a acestor evenimente va fi necesar un timp suplimentar pentru depanare pentru a reduce numărul de alarme false.
Spuneți-ne în comentarii ce jurnale colectați pentru auditul securității informației și ce instrumente folosiți pentru aceasta. Una dintre direcțiile noastre este soluții pentru auditurile evenimentelor de securitate a informației. În ceea ce privește sarcina de colectare și analiză a jurnalelor, vă putem recomanda să luați în considerare , care poate comprima datele stocate cu un raport de 20:1, iar un singur exemplu instalat poate procesa până la 60.000 de evenimente pe secundă din 10.000 de surse.
Sursa: habr.com
