Brugerarbejdsstationen er det mest sårbare punkt i infrastrukturen med hensyn til informationssikkerhed. Brugere kan modtage et brev til deres arbejds-e-mail, der ser ud til at være fra en sikker kilde, men med et link til et inficeret websted. Måske vil nogen downloade et hjælpeprogram, der er nyttigt til arbejde fra et ukendt sted. Ja, du kan komme med snesevis af tilfælde af, hvordan malware kan infiltrere interne virksomhedsressourcer gennem brugere. Derfor kræver arbejdsstationer øget opmærksomhed, og i denne artikel vil vi fortælle dig, hvor og hvilke hændelser du skal tage for at overvåge angreb.
For at opdage et angreb på det tidligst mulige stadie har Windows tre nyttige hændelseskilder: Sikkerhedshændelsesloggen, Systemovervågningsloggen og Power Shell-loggene.
Sikkerhedshændelseslog
Dette er den primære lagerplads for systemsikkerhedslogfiler. Dette inkluderer hændelser med brugerlogin/logud, adgang til objekter, politikændringer og andre sikkerhedsrelaterede aktiviteter. Selvfølgelig, hvis den relevante politik er konfigureret.
Optælling af brugere og grupper (begivenheder 4798 og 4799). Allerede i begyndelsen af et angreb søger malware ofte gennem lokale brugerkonti og lokale grupper på en arbejdsstation for at finde legitimationsoplysninger til dens lyssky forretninger. Disse hændelser vil hjælpe med at opdage ondsindet kode, før den går videre og ved hjælp af de indsamlede data spredes til andre systemer.
Oprettelse af en lokal konto og ændringer i lokale grupper (begivenheder 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 og 5377). Angrebet kan også begynde, for eksempel ved at tilføje en ny bruger til den lokale administratorgruppe.
Loginforsøg med en lokal konto (begivenhed 4624). Respektable brugere logger ind med en domænekonto, og at identificere et login under en lokal konto kan betyde starten på et angreb. Event 4624 inkluderer også logins under en domænekonto, så når du behandler hændelser, skal du filtrere hændelser fra, hvor domænet er forskelligt fra arbejdsstationens navn.
Et forsøg på at logge ind med den angivne konto (hændelse 4648). Dette sker, når processen kører i "kør som"-tilstand. Dette bør ikke ske under normal drift af systemer, så sådanne hændelser skal kontrolleres.
Låsning/oplåsning af arbejdsstationen (begivenheder 4800-4803). Kategorien af mistænkelige hændelser inkluderer alle handlinger, der fandt sted på en låst arbejdsstation.
Firewall-konfigurationsændringer (hændelser 4944-4958). Når du installerer ny software, kan firewall-konfigurationsindstillingerne naturligvis ændre sig, hvilket vil forårsage falske positiver. I de fleste tilfælde er der ingen grund til at kontrollere sådanne ændringer, men det vil bestemt ikke skade at vide om dem.
Tilslutning af Plug'n'play-enheder (event 6416 og kun for Windows 10). Det er vigtigt at holde øje med dette, hvis brugere normalt ikke forbinder nye enheder til arbejdsstationen, men så pludselig gør de det.
Windows inkluderer 9 revisionskategorier og 50 underkategorier til finjustering. Det mindste sæt af underkategorier, der skal aktiveres i indstillingerne:
Logon/Log af
- Log på;
- Log af;
- Kontolåsning;
- Andre logon/logoff begivenheder.
Account Management
- Brugerkontostyring;
- Sikkerhedsgruppeledelse.
Politikændring
- Ændring af revisionspolitik;
- Ændring af godkendelsespolitik;
- Ændring af autorisationspolitik.
System Monitor (Sysmon)
Sysmon er et værktøj indbygget i Windows, der kan registrere hændelser i systemloggen. Normalt skal du installere det separat.
De samme hændelser kan i princippet findes i sikkerhedsloggen (ved at aktivere den ønskede revisionspolitik), men Sysmon giver flere detaljer. Hvilke begivenheder kan tages fra Sysmon?
Procesoprettelse (hændelses-id 1). Systemsikkerhedshændelsesloggen kan også fortælle dig, hvornår en *.exe startede og endda vise dens navn og startsti. Men i modsætning til Sysmon vil den ikke være i stand til at vise applikationens hash. Ondsindet software kan endda kaldes harmless notepad.exe, men det er hashen, der vil bringe det frem i lyset.
Netværksforbindelser (hændelses-id 3). Det er klart, at der er mange netværksforbindelser, og det er umuligt at holde styr på dem alle. Men det er vigtigt at overveje, at Sysmon, i modsætning til Security Log, kan binde en netværksforbindelse til ProcessID og ProcessGUID felterne og viser porten og IP-adresserne for kilden og destinationen.
Ændringer i systemregistret (hændelses-id 12-14). Den nemmeste måde at tilføje dig selv til autorun er at registrere dig i registreringsdatabasen. Security Log kan gøre dette, men Sysmon viser, hvem der har foretaget ændringerne, hvornår, hvorfra, proces-id og den forrige nøgleværdi.
Filoprettelse (hændelses-id 11). Sysmon, i modsætning til Security Log, viser ikke kun placeringen af filen, men også dens navn. Det er klart, at du ikke kan holde styr på alt, men du kan revidere visse mapper.
Og nu, hvad der ikke er i sikkerhedslogpolitikker, men er i Sysmon:
Ændring af filoprettelsestidspunkt (Event ID 2). Nogle malware kan forfalske en fils oprettelsesdato for at skjule den fra rapporter om nyligt oprettede filer.
Indlæser drivere og dynamiske biblioteker (hændelses-id'er 6-7). Overvågning af indlæsning af DLL'er og enhedsdrivere i hukommelsen, kontrol af den digitale signatur og dens gyldighed.
Opret en tråd i en kørende proces (hændelses-id 8). En type angreb, der også skal overvåges.
RawAccessRead-begivenheder (hændelses-id 9). Disklæsningshandlinger ved hjælp af ".". I langt de fleste tilfælde bør en sådan aktivitet betragtes som unormal.
Opret en navngivet filstrøm (hændelses-id 15). En hændelse logges, når der oprettes en navngivet filstrøm, der udsender hændelser med en hash af filens indhold.
Oprettelse af et navngivet rør og forbindelse (hændelses-ID 17-18). Sporing af ondsindet kode, der kommunikerer med andre komponenter gennem det navngivne rør.
WMI-aktivitet (begivenheds-id 19). Registrering af hændelser, der genereres ved adgang til systemet via WMI-protokollen.
For at beskytte Sysmon selv skal du overvåge hændelser med ID 4 (Sysmon stopper og starter) og ID 16 (Sysmon-konfigurationsændringer).
Power Shell logs
Power Shell er et kraftfuldt værktøj til at administrere Windows-infrastruktur, så chancerne er store for, at en angriber vælger det. Der er to kilder, du kan bruge til at hente Power Shell-hændelsesdata: Windows PowerShell-log og Microsoft-WindowsPowerShell/Operational log.
Windows PowerShell-log
Dataudbyder indlæst (hændelses-ID 600). PowerShell-udbydere er programmer, der giver en datakilde, som PowerShell kan se og administrere. For eksempel kan indbyggede udbydere være Windows-miljøvariabler eller systemregistret. Fremkomsten af nye leverandører skal overvåges for at opdage ondsindet aktivitet i tide. For eksempel, hvis du ser WSMan dukke op blandt udbyderne, så er en ekstern PowerShell-session blevet startet.
Microsoft-WindowsPowerShell / Operational log (eller MicrosoftWindows-PowerShellCore / Operational i PowerShell 6)
Modullogning (hændelses-ID 4103). Hændelser gemmer information om hver udført kommando og de parametre, som den blev kaldt.
Scriptblokerende logning (hændelses-id 4104). Scriptblokeringslogning viser hver blok af PowerShell-kode, der udføres. Selvom en angriber forsøger at skjule kommandoen, vil denne hændelsestype vise den PowerShell-kommando, der faktisk blev udført. Denne hændelsestype kan også logge nogle API-kald på lavt niveau, der foretages, disse hændelser registreres normalt som Verbose, men hvis en mistænkelig kommando eller et mistænkeligt script bruges i en kodeblok, vil det blive logget som en advarselsgrad.
Bemærk venligst, at når værktøjet er konfigureret til at indsamle og analysere disse hændelser, vil der kræves yderligere fejlretningstid for at reducere antallet af falske positiver.
Fortæl os i kommentarerne, hvilke logfiler du indsamler til informationssikkerhedsrevisioner, og hvilke værktøjer du bruger til dette. Et af vores fokusområder er løsninger til revision af informationssikkerhedshændelser. For at løse problemet med at indsamle og analysere logfiler, kan vi foreslå at kigge nærmere på , som kan komprimere lagrede data med et forhold på 20:1, og en installeret forekomst af det er i stand til at behandle op til 60000 hændelser i sekundet fra 10000 kilder.
Kilde: www.habr.com