Den brugerdrevne arbejdsstation er det mest sårbare punkt i infrastrukturen, hvad angår informationssikkerhed. Brugere kan modtage en e-mail, der ser ud til at komme fra en sikker kilde, men som indeholder et link til en inficeret hjemmeside. Det er muligt, at nogen downloader et nyttigt værktøj fra en ukendt kilde. Man kan finde på mange scenarier, hvor ondsindet software kan trænge ind i interne virksomhedssystemer gennem brugerne. Derfor kræver arbejdsstationer særlig opmærksomhed, og i denne artikel vil vi beskrive, hvor og hvilke hændelser man skal hente for at overvåge angreb.
For at identificere et angreb i de tidlige faser er der tre nyttige hændelseskilder i Windows: sikkerhedshændelsesloggen, systemovervågningsloggen og PowerShell-loggene.
Sikkerhedshændelsesloggen (Security Log)
Dette er det primære sted for opbevaring af sikkerhedslogfiler. Her opbevares hændelser om brugerlogin/logout, adgang til objekter, ændringer i politikker og andre aktiviteter relateret til sikkerhed. Selvfølgelig, hvis den relevante politik er konfigureret.
Brugere og grupper gennemsøgning (hændelser 4798 og 4799). Ondsindet software starter ofte angrebet med at gennemsøge lokale brugerkonti og grupper på arbejdsstationen for at finde legitimationsoplysninger til sine ulovlige aktiviteter. Disse hændelser kan hjælpe med at opdage ondsindet kode før den bevæger sig videre og spreder sig til andre systemer ved hjælp af indsamlede data.
Oprettelse af en lokal konto og ændringer i lokale grupper (hændelser 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 og 5377). Et angreb kan også starte med for eksempel at tilføje en ny bruger til gruppen af lokale administratorer.
Forsøg på login med lokal konto (hændelse 4624). Ordentlige brugere logger ind med en domænekonto, og identifikation af login med en lokal konto kan betyde, at et angreb er ved at begynde. Hændelse 4624 inkluderer også indlogninger med domænekonti, så hændelserne skal filtreres, så de, hvor domænet adskiller sig fra arbejdsstationens navn, ekskluderes.
Forsøg på login med en bestemt konto (hændelse 4648). Dette kan ske, når processen kører i "Kør som"-tilstand. I normal drift bør sådanne situationer ikke forekomme, så disse hændelser bør være under kontrol.
Låsning/låsning af arbejdsstation (hændelser 4800-4803). Enhver aktivitet, der fandt sted på en låst arbejdsstation, kan betragtes som mistænkelig.
Ændringer i firewallkonfigurationen (hændelser 4944-4958). Det er tydeligt, at når nyt software installeres, kan firewallkonfigurationens indstillinger ændre sig, hvilket kan føre til falske alarmer. Det er i de fleste tilfælde ikke nødvendigt at overvåge sådanne ændringer, men det kan være nyttigt at vide om dem.
Tilslutning af Plug'n'Play-enheder (hændelse 6416 og kun for Windows 10). Dette er vigtigt at holde øje med, hvis brugere normalt ikke tilslutter nye enheder til arbejdsstationen, og pludselig gør det.
Windows indeholder 9 kategorier af revision og 50 underkategorier til finjustering. Det minimale sæt af underkategorier, der bør aktiveres i indstillingerne:
Logon/Logoff
- Logon;
- Logoff;
- Konto låsning;
- Andre logon/logoff hændelser.
Kontoadministration
- Bruger-kontoadministration;
- Sikkerhedsgruppeadministration.
Politikændring
- Revisionspolitisk ændring;
- Autentificeringspolitisk ændring;
- Godkendelsespolitisk ændring.
Systemovervågning (Sysmon)
Sysmon er et indbygget værktøj i Windows, der kan registrere hændelser i systemjournalen. Det er normalt nødvendigt at installere det separat.
Disse hændelser kan grundlæggende findes i sikkerhedsloggen (ved at aktivere den relevante revisionspolitik), men Sysmon giver flere detaljer. Hvilke hændelser kan hentes fra Sysmon?
Oprettelse af proces (hændelses-ID 1). Sikkerhedshændelsesloggen kan også sige, hvornår en hvilken som helst *.exe blev startet, og viser endda navnet og stien til start. Men i modsætning til Sysmon kan den ikke vise applikationshashen. Ondsindet software kan endda kaldes en harmløs notepad.exe, men netop hash'en vil afsløre det.
Netværksforbindelser (hændelses-ID 3). Det er indlysende, at der er mange netværksforbindelser, og det kan være svært at følge med. Men det er vigtigt at tage højde for, at Sysmon i modsætning til Security Log kan binde netværksforbindelsen til felterne ProcessID og ProcessGUID, viser porten og IP-adresser kilden og modtageren.
Ændringer i registreringsdatabasen (hændelses-ID 12-14). Den nemmeste måde at tilføje sig selv til opstartsprogrammet på er at registrere sig i registreringsdatabasen. Security Log kan gøre dette, men Sysmon viser, hvem der har foretaget ændringer, hvornår, hvorfra, process ID og den tidligere værdi af nøglen.
Oprettelse af fil (hændelses ID 11). Sysmon viser, i modsætning til Security Log, ikke kun filens placering, men også dens navn. Det er klart, at man ikke kan holde øje med alt, men man kan jo revidere bestemte mapper.
Og nu det, som ikke findes i politikkerne for Security Log, men er i Sysmon:
Ændring af filens oprettelsestidspunkt (hændelses ID 2). Nogle skadelige programmer kan ændre oprettelsesdatoen for filen for at skjule den fra rapporterne med nyoprettede filer.
Indlæsning af drivere og dynamiske biblioteker (hændelses ID 6-7). Sporing af indlæsning af DLL'er og enhedsdrivere i hukommelsen, kontrol af digitale signaturer og deres gyldighed.
Oprettelse af en tråd i en kørende proces (hændelses ID 8). En af formerne for angreb, som også skal overvåges.
RawAccessRead hændelser (hændelses ID 9). Læseoperationer fra disken ved hjælp af “.”. I næsten alle tilfælde bør sådan aktivitet betragtes som unormal.
Oprettelse af en navngivet filstrøm (hændelses ID 15). Hændelsen registreres, når der oprettes en navngivet filstrøm, der genererer hændelser med hash af filens indhold.
Oprettelse af named pipe og forbindelser (hændelses ID 17-18). Sporing af skadelig kode, der kommunikerer med andre komponenter via named pipe.
Aktivitet ved WMI (hændelses ID 19). Registrering af hændelser, der genereres ved adgang til systemet via WMI-protokollen.
For at beskytte Sysmon selv skal der overholdes hændelser med ID 4 (stoppelse og opstart af Sysmon) og ID 16 (ændring af Sysmon-konfigurationen).
Power Shell-logfiler
Power Shell er et kraftfuldt værktøj til at administrere Windows-infrastrukturen, så det er sandsynligt, at en angriber vil vælge netop det. For at få data om Power Shell-hændelser kan der bruges to kilder: Windows PowerShell log og Microsoft-WindowsPowerShell / Operational log.
Windows PowerShell log
Dataudbyderen er blevet indlæst (hændelses ID 600). PowerShell-leverandører er programmer, der fungerer som datakilder for PowerShell, så du kan se og administrere dem. For eksempel kan indbyggede leverandører være Windows-miljøvariabler eller registreringsdatabasen. Det er vigtigt at holde øje med nye leverandører for hurtigt at opdage ondsindet aktivitet. Hvis du for eksempel ser, at WSMan er dukket op blandt leverandørerne, betyder det, at der er startet en fjern PowerShell-session.
Microsoft-WindowsPowerShell / Operational-log (eller MicrosoftWindows-PowerShellCore / Operational i PowerShell 6)
Modulregistrering (Hændelses-ID 4103). I hændelserne gemmes oplysninger om hver udført kommando og de parametre, den blev kaldt med.
Script-blokregistrering (Hændelses-ID 4104). Script-blokregistreringen viser hver udført PowerShell-kodeblok. Selv hvis en angriber forsøger at skjule kommandoen, vil denne type hændelse vise den faktiske udførte PowerShell-kommando. Derudover kan nogle lave API-opkald også blive registreret i denne type hændelse, som normalt logges som Verbose, men hvis en mistænkelig kommando eller script bruges i kodeblokken, vil den blive registreret med alvorlighed Warning.
Vær opmærksom på, at der efter konfiguration af værktøjet til indsamling og analyse af disse hændelser vil være behov for ekstra tid til fejlfinding for at reducere antallet af falske positiver.
Fortæl i kommentarerne, hvilke logs du indsamler til revision af informationssikkerhed, og hvilke værktøjer du bruger til dette. Et af vores fokusområder er løsninger til revision af hændelser inden for informationssikkerhed. For opgaven med indsamling og analyse af logs kan vi anbefale at se nærmere på , som kan komprimere de gemte data med en faktor på 20:1, og én installeret instans kan håndtere op til 60.000 hændelser pr. sekund fra 10.000 kilder.
Kilde: habr.com
