Brukerarbeidsstasjonen er det mest sårbare punktet i infrastrukturen når det gjelder informasjonssikkerhet. Brukere kan motta et brev til jobbe-e-posten som ser ut til å være fra en sikker kilde, men med en lenke til et infisert nettsted. Kanskje noen vil laste ned et verktøy som er nyttig for arbeid fra et ukjent sted. Ja, du kan komme opp med dusinvis av tilfeller av hvordan skadelig programvare kan infiltrere interne bedriftsressurser gjennom brukere. Derfor krever arbeidsstasjoner økt oppmerksomhet, og i denne artikkelen vil vi fortelle deg hvor og hvilke hendelser du bør ta for å overvåke angrep.
For å oppdage et angrep på et tidligst mulig stadium, har Windows tre nyttige hendelseskilder: sikkerhetshendelsesloggen, systemovervåkingsloggen og Power Shell-loggene.
Sikkerhetshendelseslogg
Dette er hovedlagringsstedet for systemsikkerhetslogger. Dette inkluderer hendelser med brukerinnlogging/utlogging, tilgang til objekter, policyendringer og andre sikkerhetsrelaterte aktiviteter. Selvfølgelig, hvis riktig policy er konfigurert.
Oppregning av brukere og grupper (hendelser 4798 og 4799). Helt i begynnelsen av et angrep søker skadelig programvare ofte gjennom lokale brukerkontoer og lokale grupper på en arbeidsstasjon for å finne legitimasjon for dens lyssky handlinger. Disse hendelsene vil bidra til å oppdage ondsinnet kode før den går videre og, ved å bruke de innsamlede dataene, spres til andre systemer.
Oppretting av en lokal konto og endringer i lokale grupper (hendelser 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 og 5377). Angrepet kan også starte, for eksempel ved å legge til en ny bruker i den lokale administratorgruppen.
Påloggingsforsøk med en lokal konto (hendelse 4624). Respektable brukere logger på med en domenekonto, og å identifisere en pålogging under en lokal konto kan bety starten på et angrep. Event 4624 inkluderer også pålogginger under en domenekonto, så når du behandler hendelser, må du filtrere ut hendelser der domenet er forskjellig fra arbeidsstasjonsnavnet.
Et forsøk på å logge på med den angitte kontoen (hendelse 4648). Dette skjer når prosessen kjører i "kjør som"-modus. Dette skal ikke skje under normal drift av systemer, så slike hendelser må kontrolleres.
Låse/låse opp arbeidsstasjonen (hendelser 4800-4803). Kategorien mistenkelige hendelser inkluderer alle handlinger som har skjedd på en låst arbeidsstasjon.
Brannmurkonfigurasjonsendringer (hendelser 4944-4958). Åpenbart, når du installerer ny programvare, kan brannmurens konfigurasjonsinnstillinger endres, noe som vil forårsake falske positiver. I de fleste tilfeller er det ikke nødvendig å kontrollere slike endringer, men det vil definitivt ikke skade å vite om dem.
Koble til Plug'n'play-enheter (hendelse 6416 og kun for Windows 10). Det er viktig å holde øye med dette hvis brukere vanligvis ikke kobler nye enheter til arbeidsstasjonen, men plutselig gjør de det.
Windows inkluderer 9 revisjonskategorier og 50 underkategorier for finjustering. Minimumssettet med underkategorier som bør aktiveres i innstillingene:
Pålogging / pålogging
- Logg på;
- Logg av;
- kontosperre;
- Andre påloggings-/avloggingshendelser.
Account Management
- Brukerkontoadministrasjon;
- Sikkerhetsgruppeledelse.
Policyendring
- Endring av revisjonspolicy;
- Endring av autentiseringspolicy;
- Endring av autorisasjonspolicy.
System Monitor (Sysmon)
Sysmon er et verktøy innebygd i Windows som kan registrere hendelser i systemloggen. Vanligvis må du installere den separat.
De samme hendelsene kan i prinsippet finnes i sikkerhetsloggen (ved å aktivere ønsket revisjonspolicy), men Sysmon gir flere detaljer. Hvilke hendelser kan hentes fra Sysmon?
Prosessoppretting (hendelses-ID 1). Systemsikkerhetshendelsesloggen kan også fortelle deg når en *.exe startet og til og med vise navnet og startbanen. Men i motsetning til Sysmon, vil den ikke kunne vise applikasjonens hash. Skadelig programvare kan til og med kalles harmless notepad.exe, men det er hashen som vil bringe det frem i lyset.
Nettverkstilkoblinger (Hendelses-ID 3). Det er åpenbart mange nettverkstilkoblinger, og det er umulig å holde styr på dem alle. Men det er viktig å tenke på at Sysmon, i motsetning til Security Log, kan binde en nettverkstilkobling til ProcessID- og ProcessGUID-feltene, og viser porten og IP-adressene til kilden og destinasjonen.
Endringer i systemregisteret (hendelses-ID 12-14). Den enkleste måten å legge deg selv til autorun er å registrere seg i registeret. Sikkerhetslogg kan gjøre dette, men Sysmon viser hvem som har gjort endringene, når, hvorfra, prosess-ID og forrige nøkkelverdi.
Filoppretting (hendelses-ID 11). Sysmon, i motsetning til Security Log, viser ikke bare plasseringen av filen, men også navnet. Det er klart at du ikke kan holde styr på alt, men du kan revidere visse kataloger.
Og nå er det som ikke er i sikkerhetsloggpolicyer, men i Sysmon:
Endring av filopprettingstidspunkt (Event ID 2). Noe skadelig programvare kan forfalske en fils opprettelsesdato for å skjule den fra rapporter om nylig opprettede filer.
Laster drivere og dynamiske biblioteker (hendelses-ID 6-7). Overvåker lasting av DLL-er og enhetsdrivere i minnet, kontrollerer den digitale signaturen og dens gyldighet.
Opprett en tråd i en løpende prosess (hendelses-ID 8). En type angrep som også må overvåkes.
RawAccessRead-hendelser (Event ID 9). Diskleseoperasjoner ved å bruke “.”. I de aller fleste tilfeller bør slik aktivitet anses som unormal.
Opprett en navngitt filstrøm (hendelses-ID 15). En hendelse logges når en navngitt filstrøm opprettes som sender ut hendelser med en hash av filens innhold.
Opprette et navngitt rør og kobling (hendelse ID 17-18). Sporing av ondsinnet kode som kommuniserer med andre komponenter gjennom det navngitte røret.
WMI-aktivitet (hendelses-ID 19). Registrering av hendelser som genereres ved tilgang til systemet via WMI-protokollen.
For å beskytte Sysmon selv, må du overvåke hendelser med ID 4 (Sysmon stopper og starter) og ID 16 (Sysmon-konfigurasjonsendringer).
Power Shell-logger
Power Shell er et kraftig verktøy for å administrere Windows-infrastruktur, så sjansen er stor for at en angriper velger det. Det er to kilder du kan bruke for å hente Power Shell-hendelsesdata: Windows PowerShell-logg og Microsoft-WindowsPowerShell/Operational log.
Windows PowerShell-logg
Dataleverandøren er lastet inn (hendelses-ID 600). PowerShell-leverandører er programmer som gir en datakilde som PowerShell kan vise og administrere. For eksempel kan innebygde leverandører være Windows-miljøvariabler eller systemregisteret. Fremveksten av nye leverandører må overvåkes for å oppdage ondsinnet aktivitet i tide. Hvis du for eksempel ser WSMan vises blant leverandørene, har en ekstern PowerShell-sesjon blitt startet.
Microsoft-WindowsPowerShell / Driftslogg (eller MicrosoftWindows-PowerShellCore / Operational i PowerShell 6)
Modullogging (hendelses-ID 4103). Hendelser lagrer informasjon om hver utførte kommando og parameterne som den ble kalt.
Skriptblokkerende logging (hendelses-ID 4104). Skriptblokkeringslogging viser hver blokk med PowerShell-kode som er utført. Selv om en angriper prøver å skjule kommandoen, vil denne hendelsestypen vise PowerShell-kommandoen som faktisk ble utført. Denne hendelsestypen kan også logge enkelte API-anrop på lavt nivå. Disse hendelsene blir vanligvis registrert som Ordinære, men hvis en mistenkelig kommando eller et skript brukes i en kodeblokk, vil det bli logget som en advarselsgrad.
Vær oppmerksom på at når verktøyet er konfigurert til å samle inn og analysere disse hendelsene, vil det kreves ekstra feilsøkingstid for å redusere antallet falske positive.
Fortell oss i kommentarfeltet hvilke logger du samler inn for informasjonssikkerhetsrevisjoner og hvilke verktøy du bruker til dette. Et av våre fokusområder er løsninger for revisjon av informasjonssikkerhetshendelser. For å løse problemet med å samle og analysere logger, kan vi foreslå å se nærmere på , som kan komprimere lagrede data med et forhold på 20:1, og én installert forekomst av den er i stand til å behandle opptil 60000 10000 hendelser per sekund fra XNUMX XNUMX kilder.
Kilde: www.habr.com