Vad kan vara användbart att hämta från loggarna på en arbetsstation baserad på Windows

Användarstationen är den mest sårbara delen av infrastrukturen när det gäller informationssäkerhet. Användare kan få e-post som ser ut att komma från en säker källa, men som innehåller en länk till en infekterad webbplats. Kanske laddar någon ner ett verktyg från ett okänt ställe. Man kan tänka sig tiotals fall där skadlig programvara kan tränga in i företagsresurser via användare. Därför kräver arbetsstationer ökad uppmärksamhet, och i denna artikel kommer vi att berätta varifrån och vilka händelser som ska spåras för att upptäcka attacker.

För att upptäcka en attack i ett tidigt skede finns det tre användbara händelsekällor i Windows OS: säkerhetslogg, systemövervakningslogg och PowerShell-loggar.

Säkerhetslogg (Security Log)

Detta är den huvudsakliga platsen för lagring av säkerhetsrelaterade systemloggar. Här sparas händelser för inloggning/utloggning av användare, åtkomst till objekt, ändringar av policyer och andra aktiviteter relaterade till säkerhet. Naturligtvis förutsätter detta att en lämplig policy har ställts in.

Övervakning av användare och grupper (händelser 4798 och 4799). Skadlig programvara letar ofta tidigt under attacken igenom lokala användarkonton och lokala grupper på arbetsstationen för att hitta användaruppgifter för sina illasinnade syften. Dessa händelser kan hjälpa till att upptäcka den skadliga koden tidigare innan den sprider sig till andra system med insamlade uppgifter.

Skapande av lokalt användarkonto och ändringar i lokala grupper (händelser 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 och 5377). En attack kan också inledas med att en ny användare läggs till i gruppen för lokala administratörer.

Försök att logga in med lokalt användarkonto (händelse 4624). Godhjärtade användare loggar in med domänkonto, och upptäckten av inloggning med lokalt användarkonto kan betyda att en attack inleds. Händelse 4624 inkluderar också inloggningar med domänkonto, så det är viktigt att filtrera händelser där domen skiljer sig från namnet på arbetsstationen vid behandling av händelser.

Försök att logga in med ett specifikt konto (händelse 4648). Det här händer när processen körs i "Kör som" -läge. I normalt driftläge bör sådana händelser inte förekomma, så sådana händelser bör hållas under kontroll.

Låsning/olåsning av arbetsstation (händelser 4800-4803). Till kategorin misstänkta händelser kan man räkna alla åtgärder som utfördes på en låst arbetsstation.

Ändringar av brandväggskonfigurationen (händelser 4944-4958). Det är uppenbart att vid installation av ny programvara kan inställningarna i brandväggen ändras, vilket kan leda till falska larm. I de flesta fall är det inte nödvändigt att kontrollera sådana ändringar, men det skadar inte att veta om dem.

Anslutning av Plug’n’play-enheter (händelse 6416 och endast för Windows 10). Detta är viktigt att följa upp, om användarna vanligtvis inte ansluter nya enheter till arbetsstationen, men plötsligt har gjort det.

Windows inkluderar 9 kategorier av granskning och 50 underkategorier för finjustering. Det minimiantal av underkategorier som bör aktiveras i inställningarna är:

Inloggning/Utloggning

• Inloggning;
• Utloggning;
• Kontolåsningshändelse;
• Andra inloggnings-/utloggningshändelser.

Kontohantering

• Användarkontohantering;
• Hantera säkerhetsgrupper.

Policyändring

• Granskningspolicyändring;
• Autentiseringspolicyändring;
• Auktoriseringspolicyändring.

Systemmonitor (Sysmon)

Sysmon är ett inbyggt verktyg i Windows som kan registrera händelser i systemloggen. Oftast krävs det att det installeras separat.

Dessa händelser kan i princip hittas i säkerhetsloggen (genom att aktivera den nödvändiga granskningspolicyn), men Sysmon ger mer detaljer. Vilka händelser kan samlas in från Sysmon?

Skapande av process (händelse-ID 1). Säkerhetssystemloggen kan också visa när en viss *.exe startade och till och med visa dess namn och sökväg. Men till skillnad från Sysmon kan den inte visa applikationens hash. Skadlig mjukvara kan kallas något harmlöst som notepad.exe, men just hash-värdet kommer att avslöja den.

Nätverksanslutningar (händelse-ID 3). Det är uppenbart att det finns många nätverksanslutningar och det är svårt att hålla koll på dem alla. Men det är viktigt att notera att Sysmon, till skillnad från säkerhetsloggen, kan koppla nätverksanslutningen till fälten ProcessID och ProcessGUID, visar port samt IP-adresser källa och mottagare.

Ändringar i systemregistret (händelse-ID 12-14). Det enklaste sättet att lägga till sig själv i autostart är att registrera sig i registret. Security Log kan göra detta, men Sysmon visar vem som gjorde ändringar, när, varifrån, process-ID och det föregående värdet av nyckeln.

Skapa fil (händelse-ID 11). Sysmon visar, till skillnad från Security Log, inte bara filens plats utan också dess namn. Det är klart att man inte kan ha koll på allt, men man kan utföra granskning av vissa kataloger.

Och nu det som inte finns i Security Logs policys men finns i Sysmon:

Ändring av filens skapelsedatum (händelse-ID 2). Viss skadlig programvara kan ändra filens skapelsedatum för att dölja den från rapporter om nyligen skapade filer.

Laddning av drivrutiner och dynamiska bibliotek (händelse-ID 6-7). Övervakning av laddning av DLL och drivrutiner i minnet, kontroll av digital signatur och dess giltighet.

Skapa en tråd i en körande process (händelse-ID 8). En typ av attack som också behöver övervakas.

RawAccessRead-händelser (händelse-ID 9). Läsoperationer från disken med hjälp av ‘.’. I nästan alla fall bör sådan aktivitet betraktas som onormal.

Skapa en namngiven filström (händelse-ID 15). Händelsen registreras när en namngiven filström skapas som genererar händelser med hash-värdet av filens innehåll.

Skapa named pipe och anslutningar (händelse-ID 17-18). Övervakning av skadlig kod som kommunicerar med andra komponenter via en named pipe.

Aktivitet via WMI (händelse-ID 19). Registrering av händelser som genereras när man kontaktar systemet via WMI-protokollet.

För att skydda Sysmon själv behöver man övervaka händelser med ID 4 (stoppa och starta Sysmon) och ID 16 (ändring av Sysmon-konfigurationen).

Power Shell-loggar

Power Shell är ett kraftfullt verktyg för att hantera Windows-infrastruktur, så det är stor risk att en angripare väljer just det. För att få informationsdata om Power Shell-händelser kan man använda två källor: Windows PowerShell-logg och Microsoft-WindowsPowerShell / Operational-logg.

Windows PowerShell-logg

Data-leverantör har laddats (händelse-ID 600). PowerShell-leverantörer är program som fungerar som datakällor för PowerShell för att visa och hantera dem. Exempel på inbyggda leverantörer kan vara Windows miljövariabler eller systemregister. Det är viktigt att övervaka nya leverantörer för att snabbt kunna upptäcka skadlig aktivitet. Om du ser att WSMan har lagts till bland leverantörerna, betyder det att en fjärrsession för PowerShell har startats.

Microsoft-WindowsPowerShell / Operativ logg (eller MicrosoftWindows-PowerShellCore / Operativ i PowerShell 6)

Modulloggning (händelse-ID 4103). I händelserna lagras information om varje körd kommando och de parametrar som användes.

Skriptblockering (händelse-ID 4104). Skriptblockering visar varje körd kodblock i PowerShell. Även om en angripare försöker dölja kommandot, visar den här typen av händelse det som faktiskt kördes. Dessutom kan vissa lågnivå-API-anrop som utförs registreras i denna typ av händelser, som vanligtvis noteras som Verbose, men om en misstänkt kommando eller skript används i kodblocket, kommer det att registreras med en allvarlighetsgrad av Warning.

Observera att efter konfiguration av verktyget för insamling och analys av dessa händelser kommer ytterligare tid att behövas för felsökning för att minska antal falska positiva.

Berätta i kommentarerna vilka loggar du samlar in för att auditera informationssäkerhet och vilka verktyg du använder för detta. En av våra fokusområden är lösningar för audit av händelser inom informationssäkerhet. För att lösa uppgiften att samla in och analysera loggar kan vi föreslå att titta på Quest InTrust, som kan komprimera lagrad data med en faktor av 20:1, och en installerad instans kan hantera upp till 60 000 händelser per sekund från 10 000 källor.

Källa: habr.com