I Windows-miljøer er DLL- og procesinjektionsteknikker De er blevet et af de mest følsomme aspekter af moderne cybersikkerhed. De er ikke kun grundlaget for, hvor mange applikationer kører, men de giver også en meget bekvem måde for en angriber at infiltrere et system uden at lave meget støj.
Når du hører om DLL-injektion, DLL-kapring eller DLL-kapringDe beskriver faktisk forskellige måder at udnytte, hvordan Windows indlæser og administrerer sine dynamiske linkbiblioteker. En solid forståelse af disse koncepter er nøglen, uanset om du er softwareudvikler, medlem af Blue Team, retsmedicinsk analytiker eller penetrationstester.
Hvad er en DLL, og hvorfor er den så vigtig i Windows?
En DLL (Dynamic-Link Library) er, ganske enkelt sagt, en et bibliotek med prækompileret kode, som flere applikationer kan deleI stedet for at placere al koden i den eksekverbare fil (.exe), tillader Windows mange almindelige funktioner (grafik, netværk, kryptering, Windows osv.) at ligge i separate .dll-filer.
Dette har flere fordele: sparer hukommelse og diskplads fordi mange programmer deler det samme bibliotek i RAM; de kan opdater specifikke komponenter uden at skulle rekompilere hele applikationen; og det opfordrer til genbrug af testet og optimeret kode i stedet for at "genopfinde hjulet" hver gang.
Hvis du har programmeret i C eller C++, ved du, at linkeren kan fungere på to måder: med statisk link o con dynamisk linkI statisk biblioteksstyring kopieres bibliotekskoden til den eksekverbare fil ved kompilering. I dynamisk biblioteksstyring gemmer applikationen kun referencer, og det faktiske bibliotek indlæses i hukommelsen ved kørsel.
For Windows-brugere er disse dynamiske biblioteker de berømte dll. I praksis indlæses DLL'er i et hukommelsesområde, som processen har adgang til, men isoleret på adresserumsniveau af andre processer. Alligevel findes der Windows API'er, der tillader én proces at læse og skrive til en andens hukommelse, og det er netop her, sikkerhedsproblemerne begynder.
Sådan indlæser Windows DLL'er: implicit, eksplicit og søgebinding
Windows kan linke DLL'er på to hovedmåder: via implicit link og igennem eksplicit linkAt forstå denne forskel er fundamental for at forstå både DLL-injektion og DLL-kapring.
Ved implicit linkning deklareres DLL'en i den eksekverbare fils importtabel. Når programmet starter, vil Windows-indlæseren søger automatisk efter og indlæser de nødvendige DLL'er før den primære kodeudførelse begynder. Hvis en mangler, starter applikationen muligvis ikke engang.
Ved eksplicit linking er det selve programmet, der under kørsel kalder LoadLibrary / LoadLibraryEx at indlæse en specifik DLL. Nøgleparameteren er lpBibFilnavnsom kan være en absolut sti (f.eks. C:\Windows\System32\mylib.dll) eller blot filnavnet (mylib.dll).
Når kun navnet videregives, Windows anvender en foruddefineret DLL-søgerækkefølgeFørst kontrollerer den, om DLL'en allerede er indlæst i hukommelsen, eller om den tilhører listen over kendte DLL'er (systembiblioteker, der betragtes som betroede). Hvis ikke, gennemgår den en række mapper i en meget specifik rækkefølge.
Den rækkefølge varierer lidt afhængigt af, om den såkaldte sikker DLL-søgetilstand (Sikker DLL-søgningstilstand), men i bund og grund kontrollerer Windows normalt programmappen, systemmapperne, Windows-mappen, den aktuelle arbejdsmappe og endelig de mapper, der er defineret i PATH-miljøvariablen.
Problemet opstår, når en ansøgning Den angiver ikke den fulde sti Derudover kan en angriber skrive til nogle af disse mapper. I den situation vil det blot at placere en ondsindet DLL med samme navn som den legitime i en af disse "prioriterede" mapper få Windows til at indlæse den først.
Forskelle mellem programmering af en EXE og en DLL
Fra et udviklingsperspektiv er det ikke det samme at skrive en eksekverbar fil som at skrive en DLL. En EXE har typisk et indgangspunkt i funktionen. main (eller WinMain i Windows-programmer), hvilket er aktiveres direkte af operativsystemets indlæser når processen oprettes.
En DLL bruger derimod funktionen DllMain som et internt indgangspunkt for biblioteket. Denne funktion udføres, når DLL'en indlæses eller aflæses i en proces, eller når tråde oprettes eller ødelægges i den pågældende proces. Koden i DllMain skal udformes omhyggeligt, da den udføres i følsomme kontekster.
Mens en "legitim" DLL typisk eksporterer funktioner (f.eks. via en eksporttabel) til kald af andre applikationer, er der mange skadelige DLL'er, der De eksporterer ikke noget. og de koncentrerer al deres logik i DllMain, så blot at indlæse dem udløser ondsindet adfærd.
Desuden, når en DLL injiceres i en proces, arver sine privilegier og sin kontekstHvis processen kører med administratorrettigheder eller som en systemtjeneste, vil DLL'en have samme adgangsniveau, hvilket letter rettighedseskalering og -vedholdenhed.
Hvad er procesinjektion, og hvorfor er det så farligt?
Procesinjektion er en teknik, der tillader at introducere og udføre kode i hukommelsesrummet for en anden proces hvilket allerede er i gang. Det er ikke begrænset til DLL-injektion: det omfatter vilkårlig kodeinjektion, trådkapring, APC-injektion, procesudhuling osv.
I bund og grund får angriberen et referencepunkt til målprocessen, allokerer hukommelse i dens adresseområde, Skriv din kode eller stien til en DLL der. og tvinger derefter processen til at udføre den kode, normalt ved at oprette en fjerntråd eller ændre konteksten for en eksisterende.
Denne tilgang er dødelig med hensyn til sikkerhed, fordi den indsprøjtede kode Den kører med de samme tilladelser og den samme sikkerhedstoken at skæbnens proces. Desuden kan den, ved primært at leve i erindringen, undgå nogle af de kontroller, der er baseret på filanalyse (klassisk antivirus, statisk binær analyse osv.).
Det er ikke tilfældigt, at mange avancerede trusselsteknologier (APT'er), banktrojanere og målrettet malware injektion af misbrugsproces at spionere, stjæle data, deaktivere sikkerhedsløsninger eller opretholde vedvarende adgang til kompromitterede systemer.
Grundlæggende om proceshukommelse i Windows
For virkelig at forstå procesinjektion er det nyttigt at gennemgå, hvordan Windows administrerer hukommelse. Hver proces har sin egen hukommelsesallokering. eget virtuelle adresseområdelogisk isoleret fra resten, selvom det er placeret i den samme fysiske hukommelse.
I 32-bit processer virtuelt område Den ligger typisk fra 0 til 0x7FFFFFFFF, mens den i 64-bit går meget længere (for eksempel op til 0x7FFFFFFFFFF). Windows hukommelseshåndtering er ansvarlig for at oversætte disse virtuelle adresser til fysiske sider via paging.
Inden for det virtuelle rum er der forskellige regioner: processens eksekverbare kodeIndlæste DLL'er, heaps, thread stacks, områder reserveret til delt hukommelse osv. Hver region har specifikke adgangstilladelser og et specifikt formål.
Typiske hukommelsestilladelser inkluderer kombinationer som SIDE_LÆST, PAGE_WRITE, PAGE_EXECUTEeller blandede varianter som f.eks. PAGE_EXECUTE_READWRITEHvis en proces forsøger at gøre noget, der ikke er tilladt i en region (for eksempel at skrive, hvor kun udførelse er tilladt), udløser systemet en adgangsfejl.
Windows eksponerer lavniveau-API'er til manipulation af hukommelse: VirtualAlloc / VirtualAllocEx at reservere og forpligte hukommelsen; VirtualProtect / VirtualProtectEx at ændre tilladelser; LæseprocesHukommelse y SkriveprocesHukommelse at læse og skrive i andre menneskers processer; og VirtualFree / VirtualFreeEx at befri regioner.
De vigtigste procesinjektionsteknikker
Selvom de alle søger det samme mål – at udføre kode i en anden proces – bruger de forskellige injektionsteknikker forskellige kombinationer af API'er og hukommelsesmønstresom også genererer forskellige fingeraftryk til detektion.
Klassisk DLL-injektion
Den mest almindelige metode er indsprøjtning af en lærebogs-DLL. Den typiske arbejdsgang består af Åbn målprocessen med OpenProcessReserver hukommelse i din plads med VirtualAllocEx til at gemme DLL-stien, skriv den sti med WriteProcessMemory, og opret endelig en fjerntråd med CreateRemoteThread, der kalder LoadLibraryA/W ved hjælp af den sti.
Når du udfører LoadLibrary i den eksterne proces, vil dette Den indlæser den skadelige DLL, som om den var dens egen.Fra det øjeblik har biblioteket adgang til processens hukommelsesplads, dens indlæste moduler og dens ressourcer, hvilket muliggør alt fra keylogging til skærmbilleder, tyveri af legitimationsoplysninger eller installation af mere malware.
Direkte kodeindsprøjtning
En anden variant er "ren" kodeinjektion uden en mellemliggende DLL. I stedet for at sende en bibliotekssti videre, vil angriberen skriv shellcode eller maskinkode direkte i et eksekverbart hukommelsesområde i målprocessen og får en fjerntråd til at hoppe til den adresse.
Proceduren drejer sig igen om VirtualAllocEx, WriteProcessMemory og CreateRemoteThread (eller deres ntdll-ækvivalenter). Resultatet er det samme: vilkårlig kode, der kører i konteksten af en legitim proces, men i dette tilfælde, uden behov for en DLL-fil på disken.
Trådkapring
I stedet for at oprette nye tråde foretrækker nogle angribere kapre en eksisterende tråd i processenFor at gøre dette bruger de API'er som SuspendThread til at sætte tråden på pause, GetThreadContext til at læse dens tilstand (registre, instruktionspegere osv.), SetThreadContext til at omdirigere den til deres ondsindede kode og endelig ResumeThread til at fortsætte udførelsen fra den nye destination.
Ved at genbruge en legitim tråd kan denne teknik at være mere diskretfordi en ny mistænkelig tråd oprettet af CreateRemoteThread ikke vises, men i stedet genbruges en eksisterende og autoriseret tråd.
Injektion ved hjælp af APC (Asynchronous Procedure Call)
APC'er giver dig mulighed for at programmere funktioner til at køre, når en tråd går i en alarmtilstand. En angriber kan udnytte dette til at sætte opkald i kø til din kode i en måltråd ved hjælp af QueueUserAPC. Når den tråd behandler sin APC-kø (for eksempel under en venteoperation), vil den udføre den skadelige rutine.
Denne teknik ses ofte i angreb, der forsøger at blande sig med systemets normale aktivitet, da den er afhængig af standard Windows-mekanismer.
Reflekterende DLL-injektion
Reflekterende DLL-indsprøjtning omgår den almindelige Windows-indlæser. DLL'en indeholder sin egen intern oplader i stand til at mappe ind i hukommelsen, løse importer og anvende flytninger uden at skulle gennem LoadLibrary.
Angriberen indsætter både DLL-koden og den brugerdefinerede loader-kode i målprocessen og udfører loaderen. Da denne teknik ikke kræver en fil på filsystemet, er den yderst sårbar. reducerer diskens fodaftryk og komplicerer detektion baseret på traditionelle artefakter.
Procesudhulning
Processhollowing består af at oprette en legitim proces i en suspenderet tilstand (CreateProcess med CREATE_SUSPENDED), fjern mapping af dit originale billede (NtUnmapViewOfSection/ZwUnmapViewOfSection), reserver hukommelse til et nyt billede, skriv den skadelige eksekverbare fil til det med WriteProcessMemory, reparer headere og flytninger, juster hovedtrådens kontekst (SetThreadContext) til at pege på det nye indgangspunkt, og genoptag det endelig med ResumeThread.
Resultatet er, at en task manager ser ud til at køre. lovlig procesMen i virkeligheden er dens hukommelse blevet erstattet af ondsindet kode, som nu kører med den oprindelige binære fils identitet og tilladelser.
Hvad er DLL-kapring eller DLL-kapring?
DLL-kapring med udnyttelse Hvordan søger Windows efter DLL'er, når den fulde sti ikke er angivet?Hvis angriberen kan skrive til en af de mapper, som systemet kontrollerer, før den når den ægte DLL, kan de snige en skadelig version med samme navn ind.
Forestil dig et program, der forsøger at indlæse "mylib.dll" uden en fuld sti. Windows vil først kontrollere bestemte mapper: programmets egen mappe, systemmappen, Windows-mappen, den aktuelle arbejdsmappe og dem i PATH. i en bestemt rækkefølge afhængig af den sikre søgetilstand.
Hvis angriberen har skrivetilladelser, for eksempel i programmappen eller i en mappe i PATH, der evalueres før den legitime mappe, er det nok, at deponer din skadelige DLL derWindows finder den først og indlæser den, som om den var originalen.
Dette trick har været brugt siden mindst Windows 2000-æraen og er stadig gyldigt i dag, især når applikationer kører ved systemstart eller med forhøjede privilegierDette forvandler enhver kapret DLL til en sti til privilegieeskalering eller persistens.
Varianter af DLL-kapring: Sideloading og Phantom DLL
Inden for rammerne af DLL-kapring finder vi adskillige variationer. En af de mest kendte er DLL sideindlæsninghvor den skadelige DLL er placeret i en mappe, der er placeret tidligere i søgerækkefølgen end den mappe, hvor den originale DLL findes. Således prioriterer systemet den falske kopi.
I Phantom DLL-kapringDen legitime DLL findes ikke engang i nogen af de søgte mapper. Softwaren forsøger at indlæse den, fordi dens kode dikterer det, men da den ikke kan finde den, vil den første fil med det navn, der vises i en gyldig søgemappe, blive indlæst. Dette giver angriberen mulighed for opret en ikke-eksisterende DLL fra bunden med passende navn og placering.
KnownDLL'er, WinSxS og andre specialvektorer
Windows vedligeholder en liste over Kendte DLL'er i registreringsdatabasen (f.eks. i HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs). Hvis DLL-navnet matcher et navn på denne liste, bruger systemet sin egen betroede kopi, hvilket mindsker risikoen for hijacking for disse specifikke moduler.
Der findes dog mere sofistikerede vektorer, som f.eks. sideindlæsning i WinSxSMappen C:\Windows\WinSxS gemmer flere versioner af DLL'er. Programmer bruger manifester til at angive, hvilken version af en DLL der skal indlæses. Ved at manipulere disse manifester eller metadata er det muligt at indsætte forfalskede DLL'er, som systemet vil behandle som gyldige.
En anden mindre åbenlys vektor er justering af KnownDLLs-listen eller relaterede registreringsnøgler at ændre hvilke DLL'er der betragtes som system-DLL'er, eller hvordan de løses. En angriber med tilstrækkelige rettigheder kan forsøge at manipulere disse poster for at favorisere indlæsning af deres egne biblioteker.
Detektion af procesinjektion og DLL-kapring
Det er ikke let at opdage disse teknikker, fordi de er afhængige af systemets legitime mekanismer Og fordi meget af den ondsindede aktivitet foregår i hukommelsen, findes der dog flere effektive strategier.
Hukommelses- og adfærdsanalyse
En tilgang er at overvåge hukommelsesområderne i processer for at søge efter Usædvanlige eksekverbare områder eller områder, der ikke er knyttet til gyldige modulerSider markeret som PAGE_EXECUTE_READWRITE, pludselige ændringer i hukommelsestilladelser eller tilstedeværelsen af shellcode i regioner, der ikke svarer til diskbinære filer, er typiske indikatorer.
De bliver også overvåget dynamiske ændringer af hukommelseskortetDen usædvanlige oprettelse af tråde og forbindelser mellem processer, der normalt ikke interagerer, er også problemer. Mange moderne EDR'er implementerer korrelationsmotorer, der registrerer mistænkelige strenge såsom: OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread.
Overvågning af Windows API-kald
En anden tilgang er at overvåge brugen af kritiske API'er. Et typisk procesinjektionsmønster kalder på OpenProcess For at få styr på offerprocessen, brug VirtualAllocEx y SkriveprocesHukommelse at skrive data, og afslutte med OpretFjernTråd, QueueUserAPC eller SetThreadContext til at udløse udførelsen.
På samme måde bruges strenge af LoadLibrary / LoadLibraryEx Mistænkelige stier, kombineret med SearchPath eller forkert brug af den aktuelle arbejdsmappe, kan afsløre forsøg på DLL-kapring eller usikker forudindlæsning.
Værktøjer som Process Monitor / Process Explorer
Med forsyningsvirksomheder som Procesmonitor (Procmon) y Process Explorer Det er muligt at observere i realtid, hvilke .dll-filer en proces åbner, fra hvilke stier og med hvilket resultat. Filtre kan anvendes til kun at vise DLL'er og resultater af typen NAVN IKKE FUNDET, kan detekteres mislykkede indlæsningsforsøg eller fra uventede mapper.
Hvis et program indlæser DLL'er fra brugermappen, fra midlertidige stier eller fra ikke-standardiserede placeringer, anbefales det at kontrollere, om disse mapper er skrivbar af brugere uden privilegier eller via servicekonti.
AI og maskinlæringsmodeller
Nogle moderne løsninger, såsom visse SIEM'er og EDR-platforme, er begyndt at bruge maskinlæringsmodeller at identificere DLL-kapringsmønstre. Disse modeller tager metadata fra processen og biblioteket som input: stier, størrelse, intern struktur, digital signatur, navneændringer, placering (standard eller ikke-standard) osv.
Kombinering af disse oplysninger med anonym telemetri og cloud-omdømmeModellen kan markere et forsøg på at indlæse en usædvanlig DLL fra en usædvanlig sti som mistænkeligt, selvom filen ikke findes i nogen kendt malwaredatabase.
Sådan afbøder du procesinjektion og DLL-kapring
Der er ingen enkelt kontrol, der løser alt; forsvar involverer en blanding af God udviklingspraksis, systemhærdning og løbende overvågningAlligevel er der klare foranstaltninger, der reducerer risikoen betydeligt.
Bedste praksis for udviklere
Hvis du programmerer i Windows, er den første regel klar: Brug fulde stier, når det er muligt, i LoadLibrary, CreateProcess og ShellExecute.Stol ikke på standardsøgerækkefølgen til at finde kritiske DLL'er.
Derudover anbefales det kraftigt at ringe SetDllDirectory(«») I begyndelsen af processen fjernes den aktuelle arbejdsmappe (CWD) fra DLL-søgerækken. Dette forhindrer en angriber i at udnytte en kompromitteret CWD til at injicere sine biblioteker.
Det er også tilrådeligt at undgå mønstre som at bruge Søgesti at finde DLL'er, der derefter indlæses med LoadLibrary, da søgerækkefølgen for SearchPath er forskellig fra LoadLibrary og kan føre til uventede og usikre resultater.
Når det er muligt, brug Signerede DLL'er og verificer denne signatur før de indlæses. En anden mulighed er at kontrollere bibliotekets hash og sikre, at den matcher den forventede værdi. Dette reducerer muligheden for at indlæse en manipuleret DLL, selvom den er i den korrekte sti.
Windows-specifikke indstillinger
Windows tilbyder API'er som f.eks. Angiv søgestitilstand For at aktivere permanent sikker søgetilstand i en proces skal du flytte CWD'en til slutningen af søgelisten. Når den er permanent aktiveret, vil efterfølgende kald, der forsøger at ændre denne tilstand, mislykkes, hvilket styrker konsistensen.
En anden grundlæggende anbefaling er Installer ikke programmer i roden af et drev (for eksempel C:\), fordi mapper, der oprettes der, ofte arver bredere skrivetilladelser for godkendte brugere. Det er bedre at bruge stier under Programfiler eller mapper med velkontrollerede ACL'er.
Det er også vigtigt at konfigurere politikker korrekt, som f.eks. UAC, AppLocker eller Windows Defender Application Control (WDAC) at begrænse hvilke binære filer og DLL'er hver proces kan indlæse, og at håndhæve kodeintegritet (gyldige signaturer) hvor det er muligt.
System- og organisationsniveaukontroller
På systemniveau, teknologier som f.eks. DEP (Data Execution Prevention), ASLR (Randomisering af adressepladslayout), Kontrolflowvagt (CFG) o Beskyttet proceslys (PPL) De skaber yderligere hindringer for udførelsen af kode i hukommelsen og manipulationen af beskyttede processer.
På netværks- og organisationsniveau er det afgørende at opretholde opdaterede antivirus- og EDR-løsningerDa mange DLL-injektionsvarianter stadig kan detekteres ved hjælp af signaturer og heuristikker, kan specifikke værktøjer som DLLSPY hjælpe med at finde DLL-baserede sårbarheder for privilegieeskalering.
Endelig skal det huskes, at mange skadelige DLL'er kommer ind i miljøet via phishing, social engineering eller angreb i forsyningskædenUddannelse af personale, implementering af multifaktor-godkendelse, gennemgang af mistænkelige e-mails og implementering af tredjepartsløsninger til risikostyring (TPRM) hjælper med at reducere angrebsfladen.
Hele dette økosystem af teknikker – klassisk DLL-injektion, DLL-kapring, kodeinjektion, procesudhuling og lignende – demonstrerer, i hvilken grad dynamisk linkede biblioteker er et tveægget sværd: afgørende for systemeffektivitet, men også en primær vektor for avancerede angrebAt forstå, hvordan de fungerer internt, hvordan de indlæses, og hvilke værktøjer der findes til at overvåge dem, giver mulighed for at træffe langt mere robuste beslutninger, når man designer applikationer, beskytter endpoints og reagerer på hændelser i Windows-miljøer.