Fillös skadlig kod och Living-off-the-Land-attacker

Traditionell skadlig kod skriver körbara filer till disken, vilket ger signaturbaserade antivirusprogram möjlighet att skanna och upptäcka dem. Fileless malware körs helt i minnet eller missbrukar legitima verktyg som redan är installerade, och lämnar därför inga traditionella filer med skadlig kod som antivirusprogram kan hitta. Detta minskar upptäcktsgraden dramatiskt för signaturbaserade verktyg. Säkerhetsleverantörer rapporterar att fileless-attacker har 10 gånger större sannolikhet att lyckas än filbaserade attacker. Bankrånet mot Bangladesh Bank 2016, varianterna av Petya/NotPetya från 2017 och otaliga intrång av nationalstatsaktörer har utnyttjat fileless-tekniker för att upprätthålla persistens och undgå upptäckt.

Living-off-the-land-attacker (LotL) använder legitima verktyg och verktygsprogram som redan finns på det angripna systemet för att utföra skadliga åtgärder. Dessa verktyg – PowerShell, WMI, certutil, mshta, regsvr32, rundll32 – betros av operativsystemet och säkerhetsprogram eftersom de har legitima användningsområden. En angripare som uteslutande använder inbyggda verktyg kan smälta in i normal administrativ aktivitet. Utmaningen för försvarare är att skilja skadlig användning av dessa verktyg från legitimt administrativt arbete. Därför är beteendeanalys och kontextmedvetenhet effektivare än signaturidentifiering för LotL-tekniker.

PowerShell är det mest missbrukade LotL-verktyget eftersom det ger åtkomst till hela .NET-ramverket, WMI och Windows-API:er med minimala spår när det körs i minnet. Angripare laddar ned PowerShell-skript direkt till minnet utan att skriva dem till disken, kodar kommandon i Base64 för att dölja dem från loggning och använder funktioner som reflection för att läsa in .NET-sammansättningar i minnet. Ramverken Empire och Cobalt Strike förlitar sig i hög grad på PowerShell efter kompromettering. Försvarsåtgärder omfattar PowerShell Constrained Language Mode, ScriptBlock Logging (loggar avkodat skriptinnehåll), Module Logging och begränsning av vilka som får köra PowerShell via Group Policy.

WMI (Windows Management Instrumentation) är en kraftfull Windows-funktion för systemhantering som angripare missbrukar för persistens och lateral förflyttning. En WMI-händelseprenumeration utlöser ett kommando när en angiven händelse inträffar, till exempel var femte minut, vid inloggning eller när en viss process startar. Dessa prenumerationer överlever omstarter, lagras i WMI-databasen och visas inte som traditionella schemalagda aktiviteter eller registernycklar för autostart, vilket gör att många verktyg för identifiering av persistens inte upptäcker dem. Angripare kan även använda WMI för att köra processer på fjärrsystem via DCOM (port 135), vilket möjliggör lateral förflyttning utan nätverksresurser.

Processinjektion gör det möjligt för skadlig kod att köras i adressutrymmet för en legitim och betrodd process (explorer.exe, svchost.exe, notepad.exe). Den skadliga koden ärver processens behörigheter och identitet, vilket får nätverksanslutningar att se ut att komma från ett betrott program. Vanliga injektionstekniker omfattar DLL-injektion (läser in en skadlig DLL i en annan process), process hollowing (skapar en pausad process, avmapp­ar dess kod och ersätter den med skadlig kod) och reflective DLL injection (läser in en DLL direkt från minnet utan att skriva den till disken). EDR-verktyg upptäcker injektion genom att övervaka sekvenser av API-anrop (OpenProcess, VirtualAllocEx, WriteProcessMemory, CreateRemoteThread).

Många fileless-attackkedjor börjar med ett skadligt Office-dokument som innehåller VBA-makron. När användaren öppnar dokumentet och aktiverar makron (ofta lockad av ett meddelande som 'Enable Content to view this document') kör makrot PowerShell för att ladda ned och köra en nyttolast direkt i minnet. Nyttolasten skrivs aldrig till disken – endast det ursprungliga Office-dokumentet gör det. Därför betonar Security+-provet vikten av att inaktivera makron och distribuera ASR-regler (Attack Surface Reduction). Moderna phishingramverk för attacker i mitten (som Evilginx2) levererar också skadliga dokument efter att autentiseringsuppgifter har fångats upp, för att installera RAT:ar.

AMSI (Antimalware Scan Interface) är ett Windows-API som gör det möjligt för program (PowerShell, VBScript, JScript, Office) att skicka innehåll till den installerade antivirusmotorn för skanning vid körning – även innan innehållet har skrivits till disken. AMSI gör det möjligt för antivirusleverantörer att skanna skriptinnehåll som annars skulle vara osynligt för filbaserad skanning. Angripare försöker kringgå AMSI genom att patcha amsi.dll i minnet så att den returnerar resultatet 'clean' för alla inskickade objekt, eller genom att förvränga skriptinnehållet för att undvika signaturmatchning. EDR-verktyg övervakar försök att patcha AMSI som en indikator på fileless-attackaktivitet.

För att upptäcka fileless malware måste Ni gå från filbaserad identifiering till beteendeövervakning. Viktiga identifieringsstrategier omfattar: PowerShell ScriptBlock Logging fångar avkodat skriptinnehåll även om det är kodat på kommandoraden; Sysmon loggar processkapande med fullständiga kommandorader, nätverksanslutningar med information om vilken process som skapade dem och registerändringar; EDR-regler för beteende larmar vid misstänkta processrelationer (Word startar PowerShell, PowerShell startar cmd, certutil laddar ned körbara filer); och Windows Event Forwarding skickar dessa loggar till ett centralt SIEM-system för korrelation och långsiktig lagring.

Organisationer kan minska attackytan för LotL genom att begränsa vilka användare som får köra kraftfulla verktyg. PowerShell Constrained Language Mode begränsar .NET-anrop, COM-objekt och reflection som angripare förlitar sig på. AppLocker och WDAC (Windows Defender Application Control) kan förhindra att specifika binärfiler körs av användare som inte är administratörer. LOLBAS-projektet katalogiserar kända LotL-binärfiler och deras attacktekniker, vilket hjälper försvarare att identifiera vilka binärfiler som bör övervakas eller begränsas. Alla LotL-binärfiler kan inte blockeras (många krävs för operativsystemets funktion), men det går att övervaka deras användning i rätt kontext.

MITRE ATT&CK-ramverket dokumenterar fileless- och LotL-tekniker utförligt. Viktiga undertekniker omfattar: T1059.001 (PowerShell), T1047 (WMI-körning), T1055 (processinjektion), T1140 (avkoda/dekryptera filer), T1003.001 (LSASS-minne för credential dumping) och T1546.003 (WMI-händelseprenumeration för persistens). Genom att mappa Er identifieringsförmåga mot dessa tekniker med ATT&CK Navigator synliggör Ni täckningsluckor och får vägledning vid utveckling av SIEM-regler. Ramverket tillhandahåller även vägledning om begränsning och identifiering för varje teknik.

En skiktad försvarsstrategi mot fileless malware omfattar: aktivering av PowerShell-loggning (ScriptBlock, Module, Transcription), distribution av Sysmon med en heltäckande konfiguration, implementering av AMSI med en uppdaterad antivirusmotor, tillämpning av PowerShell Constrained Language Mode via WDAC, begränsning av makrokörning i Office-dokument via Group Policy, distribution av EDR med funktioner för beteendebaserad identifiering samt vidarebefordran av alla loggar till ett SIEM-system med identifieringsregler för kända skadliga processkedjor. Kombinationen av en begränsad attackyta och bättre insyn gör fileless-attacker betydligt svårare att genomföra utan att upptäckas.

I den här lektionen lärde Ni Er att fileless malware körs i minnet och missbrukar legitima operativsystemverktyg som PowerShell, WMI och certutil för att undgå signaturbaserad identifiering, att tekniker för processinjektion döljer skadlig kod inuti betrodda processer genom att utnyttja Windows API:er för minneshantering och att beteendebaserad identifiering via SIEM, Sysmon och EDR, i kombination med PowerShell-loggning och AMSI, ger det starkaste försvaret mot dessa attackkedjor som undviker signaturidentifiering. Härnäst utforskar vi skillnaden mellan sårbarhetsskanning och penetrationstestning.