Användararbetsstationen är den mest sårbara punkten i infrastrukturen när det gäller informationssäkerhet. Användare kan få ett brev till sin arbetsmail som verkar vara från en säker källa, men med en länk till en infekterad webbplats. Kanske kommer någon att ladda ner ett verktyg som är användbart för arbete från en okänd plats. Ja, du kan komma på dussintals fall av hur skadlig programvara kan infiltrera företagets interna resurser genom användare. Därför kräver arbetsstationer ökad uppmärksamhet, och i den här artikeln kommer vi att berätta var och vilka händelser du ska vidta för att övervaka attacker.
För att upptäcka en attack i ett så tidigt skede som möjligt har Windows tre användbara händelsekällor: säkerhetshändelseloggen, systemövervakningsloggen och Power Shell-loggarna.
Säkerhetshändelselogg
Detta är den huvudsakliga lagringsplatsen för systemsäkerhetsloggar. Detta inkluderar händelser av användarinloggning/utloggning, åtkomst till objekt, policyändringar och andra säkerhetsrelaterade aktiviteter. Naturligtvis, om lämplig policy är konfigurerad.
Uppräkning av användare och grupper (händelser 4798 och 4799). I början av en attack söker malware ofta genom lokala användarkonton och lokala grupper på en arbetsstation för att hitta autentiseringsuppgifter för dess skumma affärer. Dessa händelser kommer att hjälpa till att upptäcka skadlig kod innan den går vidare och, med hjälp av den insamlade informationen, sprids till andra system.
Skapande av ett lokalt konto och ändringar i lokala grupper (event 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 och 5377). Attacken kan också börja, till exempel genom att lägga till en ny användare i den lokala administratörsgruppen.
Inloggningsförsök med ett lokalt konto (händelse 4624). Respektabla användare loggar in med ett domänkonto, och att identifiera en inloggning under ett lokalt konto kan innebära starten på en attack. Event 4624 inkluderar även inloggningar under ett domänkonto, så när du bearbetar händelser måste du filtrera bort händelser där domänen skiljer sig från arbetsstationens namn.
Ett försök att logga in med det angivna kontot (händelse 4648). Detta händer när processen körs i "kör som"-läge. Detta bör inte hända under normal drift av systemen, så sådana händelser måste kontrolleras.
Låsa/låsa upp arbetsstationen (händelser 4800-4803). Kategorin misstänkta händelser inkluderar alla åtgärder som inträffade på en låst arbetsstation.
Brandväggskonfigurationsändringar (händelser 4944-4958). När du installerar ny programvara kan uppenbarligen brandväggens konfigurationsinställningar ändras, vilket kommer att orsaka falska positiva resultat. I de flesta fall finns det inget behov av att kontrollera sådana förändringar, men det kommer definitivt inte att skada att veta om dem.
Ansluta Plug'n'play-enheter (event 6416 och endast för Windows 10). Det är viktigt att hålla ett öga på detta om användare vanligtvis inte ansluter nya enheter till arbetsstationen, men så plötsligt gör de det.
Windows innehåller 9 revisionskategorier och 50 underkategorier för finjustering. Minsta uppsättning underkategorier som bör aktiveras i inställningarna:
Inloggning/Logga ut
- Logga in;
- Logga ut;
- Kontolåsning;
- Andra inloggnings-/avloggningshändelser.
Account Management
- Användarkontohantering;
- Säkerhetsgruppsledning.
Policyändring
- Ändring av revisionspolicy;
- Ändring av autentiseringspolicy;
- Ändring av auktorisationspolicy.
System Monitor (Sysmon)
Sysmon är ett verktyg inbyggt i Windows som kan registrera händelser i systemloggen. Vanligtvis måste du installera den separat.
Samma händelser kan i princip hittas i säkerhetsloggen (genom att aktivera önskad revisionspolicy), men Sysmon ger mer detaljer. Vilka händelser kan hämtas från Sysmon?
Processskapande (händelse-ID 1). Systemsäkerhetshändelseloggen kan också berätta när en *.exe startade och till och med visa dess namn och startsökväg. Men till skillnad från Sysmon kommer den inte att kunna visa applikationens hash. Skadlig programvara kan till och med kallas harmless notepad.exe, men det är hashen som kommer att visa upp det.
Nätverksanslutningar (Event ID 3). Uppenbarligen finns det många nätverksanslutningar, och det är omöjligt att hålla reda på dem alla. Men det är viktigt att tänka på att Sysmon, till skillnad från Security Log, kan binda en nätverksanslutning till ProcessID och ProcessGUID-fälten och visar porten och IP-adresserna för källan och destinationen.
Ändringar i systemregistret (händelse-ID 12-14). Det enklaste sättet att lägga till dig själv i autorun är att registrera dig i registret. Säkerhetslogg kan göra detta, men Sysmon visar vem som gjorde ändringarna, när, varifrån, process-ID och föregående nyckelvärde.
Skapande av fil (händelse-ID 11). Sysmon kommer, till skillnad från Security Log, att visa inte bara platsen för filen, utan också dess namn. Det är tydligt att du inte kan hålla reda på allt, men du kan granska vissa kataloger.
Och nu är det som inte finns i säkerhetsloggpolicyer, utan i Sysmon:
Ändring av filskapande tid (Event ID 2). En del skadlig programvara kan förfalska en fils skapandedatum för att dölja den från rapporter om nyligen skapade filer.
Laddar drivrutiner och dynamiska bibliotek (händelse-ID 6-7). Övervaka laddningen av DLL:er och enhetsdrivrutiner i minnet, kontrollera den digitala signaturen och dess giltighet.
Skapa en tråd i en pågående process (händelse-ID 8). En typ av attack som också behöver övervakas.
RawAccessRead Events (Event ID 9). Diskläsoperationer med “.”. I de allra flesta fall bör sådan verksamhet anses onormal.
Skapa en namngiven filström (händelse-ID 15). En händelse loggas när en namngiven filström skapas som avger händelser med en hash av filens innehåll.
Skapa ett namngivet rör och anslutning (händelse-ID 17-18). Spåra skadlig kod som kommunicerar med andra komponenter via det namngivna röret.
WMI-aktivitet (händelse-ID 19). Registrering av händelser som genereras vid åtkomst till systemet via WMI-protokollet.
För att skydda Sysmon själv måste du övervaka händelser med ID 4 (Sysmon stoppar och startar) och ID 16 (Sysmons konfigurationsändringar).
Power Shell-loggar
Power Shell är ett kraftfullt verktyg för att hantera Windows-infrastruktur, så chansen är stor att en angripare väljer det. Det finns två källor som du kan använda för att hämta Power Shell-händelsedata: Windows PowerShell-logg och Microsoft-WindowsPowerShell/operativ logg.
Windows PowerShell-logg
Dataleverantör laddad (händelse-ID 600). PowerShell-leverantörer är program som tillhandahåller en datakälla för PowerShell att visa och hantera. Till exempel kan inbyggda leverantörer vara Windows-miljövariabler eller systemregistret. Uppkomsten av nya leverantörer måste övervakas för att upptäcka skadlig aktivitet i tid. Om du till exempel ser WSMan dyka upp bland leverantörerna, har en fjärrstyrd PowerShell-session startats.
Microsoft-WindowsPowerShell / Operational log (eller MicrosoftWindows-PowerShellCore / Operational i PowerShell 6)
Modulloggning (händelse-ID 4103). Händelser lagrar information om varje utfört kommando och parametrarna som det anropades med.
Skriptblockerande loggning (händelse-ID 4104). Skriptblockeringsloggning visar varje block av PowerShell-kod som körs. Även om en angripare försöker dölja kommandot kommer denna händelsetyp att visa PowerShell-kommandot som faktiskt kördes. Den här händelsetypen kan också logga vissa API-anrop på låg nivå som görs, dessa händelser registreras vanligtvis som Verbose, men om ett misstänkt kommando eller skript används i ett kodblock, kommer det att loggas som en varningsgrad.
Observera att när verktyget är konfigurerat för att samla in och analysera dessa händelser kommer ytterligare felsökningstid att krävas för att minska antalet falska positiva.
Berätta i kommentarerna vilka loggar du samlar in för informationssäkerhetsrevisioner och vilka verktyg du använder för detta. Ett av våra fokusområden är lösningar för granskning av informationssäkerhetshändelser. För att lösa problemet med att samla in och analysera stockar kan vi tipsa om att titta närmare på , som kan komprimera lagrad data med ett förhållande på 20:1, och en installerad instans av den kan bearbeta upp till 60000 10000 händelser per sekund från XNUMX XNUMX källor.
Källa: will.com