Un viitor SOC Analyst nu începe întotdeauna cu un SIEM scump, dashboard-uri elegante și reguli gata făcute. Uneori începe cu un laptop Windows, câteva fișiere de log și întrebarea simplă: „ce s-a întâmplat, în ce ordine?”. Aici intră în scenă Windows Event Logs, una dintre cele mai importante surse de adevăr pentru investigațiile de bază.
Pentru un începător, logurile Windows pot părea aglomerate: ID-uri, surse, niveluri, mesaje tehnice și ore diferite. Dar, folosite metodic, ele pot ajuta la reconstruirea unei cronologii suficient de clare pentru triere, documentare și escaladare către o echipă mai avansată.
De ce contează cronologia
În investigațiile defensive, ordinea evenimentelor este esențială. Nu este suficient să observi că a existat o autentificare eșuată sau că un proces a pornit. Trebuie să înțelegi ce a venit înainte, ce a urmat și dacă evenimentele se leagă între ele.
O cronologie bună răspunde la întrebări simple: când a început activitatea suspectă, ce cont a fost implicat, de pe ce sistem, ce proces s-a lansat, ce schimbare s-a produs și când s-a oprit activitatea. Fără SIEM, această muncă se face mai lent, dar principiul rămâne același: colectezi, filtrezi, corelezi și notezi concluziile fără să sari peste verificări.
Ce loguri Windows merită verificate prima dată
Pentru început, cele mai utile zone sunt Security, System, Application și, acolo unde există, logurile operaționale precum Windows PowerShell sau Microsoft-Windows-Sysmon/Operational. Microsoft documentează Windows Event Log ca mecanism prin care sistemul și aplicațiile înregistrează evenimente importante. Pentru analiză defensivă, Security este adesea punctul de plecare, mai ales când cauți autentificări, încercări eșuate sau activitate asociată conturilor.
Câteva ID-uri apar des în investigațiile de bază. Event ID 4624 indică o autentificare reușită, iar 4625 o autentificare eșuată. Event ID 4688 indică faptul că un proces nou a fost creat, dacă auditarea pentru creare de procese este activată. Aceste evenimente nu spun singure întreaga poveste, dar pot fi piese importante în puzzle.
Cum reconstruiești cronologia fără SIEM
Primul pas este să stabilești intervalul de timp. Dacă ai o alertă, un mesaj de utilizator sau o oră aproximativă, lucrează cu o fereastră rezonabilă înainte și după acel moment. Nu porni de la ideea că primul eveniment găsit este începutul incidentului.
Al doilea pas este normalizarea timpului. Notează fusul orar al sistemului și verifică dacă ora din loguri corespunde cu ora raportată de utilizator sau de alt sistem. Diferențele de timp sunt o cauză frecventă pentru cronologii greșite.
Al treilea pas este filtrarea. În Event Viewer poți filtra după log, nivel, sursă și Event ID. În PowerShell, Get-WinEvent este instrumentul documentat de Microsoft pentru interogarea logurilor de evenimente. Pentru un analist la început, ideea importantă nu este să memoreze comenzi, ci să caute consecvent aceleași repere: cont, nume de stație, adresă de rețea, proces, oră și rezultat.
Al patrulea pas este corelarea. O autentificare reușită urmată imediat de procese neobișnuite poate merita atenție. Mai multe autentificări eșuate înainte de una reușită pot sugera o problemă de parolă, configurare sau, în anumite contexte, o încercare de acces neautorizat. Interpretarea trebuie făcută prudent: același Event ID poate avea explicații legitime.
Sysmon: util, dar nu magic
Sysmon, instrument din suita Microsoft Sysinternals, poate înregistra activitate detaliată precum crearea de procese, conexiuni de rețea și modificări relevante, în funcție de configurare. Pentru un viitor SOC Analyst, Sysmon este valoros deoarece adaugă context peste logurile standard. Totuși, el trebuie instalat și configurat din timp; nu poate reconstrui evenimente pe care nu le-a colectat anterior.
Asta este o lecție importantă: investigația bună începe înainte de incident, prin logare corectă, retenție suficientă și documentarea setărilor.
Ce notezi în raport
Un raport simplu trebuie să includă intervalul analizat, sistemul verificat, logurile consultate, evenimentele relevante, ipotezele și limitele. Dacă nu ai SIEM, spune clar asta. Dacă anumite loguri nu existau sau fuseseră suprascrise, notează limitarea. În cybersecurity, un raport onest este mai valoros decât o concluzie spectaculoasă, dar nesusținută.
Pentru începători, exercițiul cel mai bun este să creeze cronologii pe cazuri controlate: autentificare, instalare de aplicație, rulare de proces legitim, eroare de sistem. Așa înveți cum arată normalul, înainte să încerci să identifici anormalul.
Windows Event Logs nu înlocuiesc un SIEM enterprise, dar pot construi disciplina de bază a unui analist: atenție la timp, context, dovezi și concluzii proporționale cu datele disponibile. Iar această disciplină contează indiferent ce platformă vei folosi mai târziu.
