В Windows среди, DLL и техники за инжектиране в процеси Те са се превърнали в един от най-чувствителните аспекти на съвременната киберсигурност. Те не само са в основата на това колко приложения се изпълняват, но и предоставят много удобен начин за нападателя да проникне в система, без да вдига много шум.
Когато чуете за DLL инжектиране, DLL отвличане или DLL отвличанеТе всъщност описват различни начини за използване на начина, по който Windows зарежда и управлява своите динамични библиотеки с връзки. Доброто разбиране на тези концепции е ключово, независимо дали сте софтуерен разработчик, член на Синия екип, криминалист или тестер за проникване.
Какво е DLL и защо е толкова важна в Windows?
DLL (Dynamic-Link Library) е, просто казано, библиотека с предварително компилиран код, която множество приложения могат да споделятВместо да поставя целия код в изпълнимия файл (.exe), Windows позволява много често срещани функции (графика, мрежи, криптиране, Windows и др.) да се намират в отделни .dll файлове.
Това има няколко предимства: спестява памет и дисково пространство защото много програми споделят една и съща библиотека в RAM паметта; те могат актуализиране на специфични компоненти без да се прекомпилира цялото приложение; и насърчава повторното използване на тестван и оптимизиран код, вместо всеки път да се „преоткрива колелото“.
Ако сте програмирали на C или C++, ще знаете, че линкерът може да работи по два начина: с статична връзка или с динамична връзкаПри статичното управление на библиотеки, кодът на библиотеката се копира в изпълнимия файл по време на компилация. При динамичното управление на библиотеки приложението съхранява само препратки, а самата библиотека се зарежда в паметта по време на изпълнение.
За потребителите на Windows тези динамични библиотеки са известните dll. На практика, DLL файловете се зареждат в памет, достъпна за процеса, но изолирани на ниво адресно пространство на други процеси. Въпреки това, има Windows API, които позволяват на един процес да чете и записва в паметта на друг и точно там започват проблемите със сигурността.
Как Windows зарежда DLL файлове: имплицитно, експлицитно и свързване за търсене
Windows може да свързва DLL файлове по два основни начина: чрез имплицитна връзка и чрез изрична връзкаРазбирането на тази разлика е от основно значение за разбирането както на DLL инжектирането, така и на DLL hijacking-а.
При имплицитно свързване, DLL библиотеката се декларира в таблицата за импортиране на изпълнимия файл. Когато програмата стартира, зареждащият файл на Windows... автоматично търси и зарежда необходимите DLL файлове преди да започне изпълнението на основния код. Ако такъв липсва, приложението може дори да не стартира.
При явното свързване, самата програма, по време на изпълнение, извиква LoadLibrary / LoadLibraryEx за зареждане на конкретна DLL. Ключовият параметър е lpLibFileNameкойто може да бъде абсолютен път (например C:\Windows\System32\mylib.dll) или само името на файла (mylib.dll).
Когато се предава само името, Windows прилага предварително зададен ред за търсене на DLL файловеПърво, проверява дали DLL вече е заредена в паметта или дали принадлежи към списъка с известни DLL файлове (системни библиотеки, считани за надеждни). Ако не, преглежда поредица от директории в много специфичен ред.
Тозият ред варира леко в зависимост от това дали т.нар. режим на безопасно търсене на DLL файлове (Безопасен режим на търсене на DLL файлове), но по същество Windows обикновено проверява директорията на приложението, системните директории, папката на Windows, текущата работна директория и накрая директориите, дефинирани в променливата на средата PATH.
Проблемът възниква, когато дадено приложение Не посочва пълния път Освен това, някои от тези директории са достъпни за запис от хакер. В тази ситуация, простото поставяне на злонамерен DLL файл със същото име като легитимния в една от тези „приоритетни“ директории ще накара Windows да го зареди първа.
Разлики между програмирането на EXE и DLL
От гледна точка на разработката, писането на изпълним файл не е същото като писането на DLL. EXE файлът обикновено има входна точка във функцията. основен (или WinMain в Windows приложения), което е извиква се директно от зареждащия механизъм на операционната система когато процесът е създаден.
DLL, от друга страна, използва функцията DllMain като вътрешна входна точка за библиотеката. Тази функция се изпълнява, когато DLL се зарежда или изтегля в процес или когато се създават или унищожават нишки в този процес. Кодът в DllMain трябва да бъде внимателно изработен, защото се изпълнява в чувствителни контексти.
Докато „легитимните“ DLL файлове обикновено експортират функции (например чрез таблица за експортиране), които други приложения могат да извикват, много злонамерени DLL файлове... Те не изнасят нищо. и те концентрират цялата си логика в DllMain, така че самото им зареждане задейства злонамерено поведение.
Освен това, когато DLL файл се инжектира в процес, наследява своите привилегии и контекстАко процесът се изпълнява с администраторски права или като системна услуга, DLL ще има същото ниво на достъп, което ще улесни ескалацията на привилегиите и запазването им.
Какво е инжектиране в процес и защо е толкова опасно?
Инжектирането в процес е техника, която позволява да въведе и изпълни код в паметта на друг процес което вече е в ход. Не се ограничава само до инжектиране на DLL: то обхваща инжектиране на произволен код, отвличане на нишки, инжектиране на APC, изпразване на процеси и др.
По същество, атакуващият получава дескриптор на целевия процес, разпределя памет в адресното му пространство, Напишете кода си или пътя до DLL там. и след това принуждава процеса да изпълни този код, обикновено чрез създаване на отдалечена нишка или промяна на контекста на съществуваща такава.
Този подход е смъртоносен от гледна точка на сигурността, защото инжектираният код Работи със същите разрешения и същия токен за сигурност че процесът на съдбата. Освен това, живеейки предимно в паметта, може избягвайте някои от контролите, базирани на анализ на файлове (класически антивирус, статичен двоичен анализ и др.).
Не е случайно, че много усъвършенствани технологии за защита от заплахи (APT), банкови троянски коне и целенасочен зловреден софтуер инжектиране в процес на злоупотреба да шпионират, да крадат данни, да деактивират решения за сигурност или да поддържат постоянен достъп до компрометирани системи.
Основи на процесорната памет в Windows
За да разберем напълно инжектирането на процеси, е полезно да прегледаме как Windows управлява паметта. Всеки процес има свое собствено разпределение на паметта. собствено виртуално адресно пространствологически изолирани от останалите, въпреки че се намират на същата физическа памет.
В 32-битовите процеси виртуален диапазон Обикновено варира от 0 до 0x7FFFFFFFF, докато в 64-битовата версия отива много по-далеч (например до 0x7FFFFFFFFFF). Мениджърът на паметта на Windows е отговорен за преобразуването на тези виртуални адреси във физически страници чрез пейджинг.
В това виртуално пространство има отделни региони: изпълним код на процесаЗаредени DLL файлове, купчини, стекове от нишки, области, запазени за споделена памет и др. Всеки регион има специфични разрешения за достъп и специфична цел.
Типичните разрешения за памет включват комбинации като ПРОЧЕТЕНА_СТРАНИЦА, PAGE_WRITE, ИЗПЪЛНЕНИЕ_НА_СТРАНИЦАили смесени варианти, като например PAGE_EXECUTE_READWRITEАко даден процес се опита да направи нещо, което не е позволено в дадена област (например, записване там, където е разрешено само изпълнение), системата генерира нарушение на достъпа.
Windows предоставя ниско ниво API за манипулиране на паметта: Виртуален Аллок / Виртуален АллокEx да се запази и ангажира паметта; Виртуална защита / Виртуална защитаEx да променяте разрешенията; ReadProcessMemory y Процес на записПамет да чете и пише в процесите на други хора; и ВиртуаленFree / ВиртуаленFreeEx да освободят региони.
Основни техники за инжектиране в процеса
Въпреки че всички те търсят една и съща цел – да изпълнят код в рамките на друг процес – различните техники за инжектиране използват различни комбинации от API и модели на паметтакоето също генерира различни пръстови отпечатъци за откриване.
Класическо DLL инжектиране
Най-разпространеният метод е инжектирането на DLL файлове от учебник. Типичният работен процес се състои от Отворете целевия процес с OpenProcessРезервирайте памет във вашето пространство с VirtualAllocEx, за да съхраните пътя до DLL файла, запишете този път с WriteProcessMemory и накрая създайте отдалечена нишка с CreateRemoteThread, която извиква LoadLibraryA/W, използвайки този път.
Когато изпълнявате LoadLibrary в отдалечения процес, това Зарежда злонамерената DLL, сякаш е своя собствена.От този момент нататък библиотеката има достъп до паметта на процеса, заредените му модули и ресурсите му, което позволява всичко - от кейлогинг до скрийншотове, кражба на идентификационни данни или инсталиране на още зловреден софтуер.
Директно инжектиране на код
Друг вариант е „чисто“ инжектиране на код, без междинен DLL. Вместо да предава път до библиотеката, атакуващият директно писане на шелкод или машинен код в изпълним регион на паметта на целевия процес и кара отдалечена нишка да премине към този адрес.
Процедурата отново се върти около VirtualAllocEx, WriteProcessMemory и CreateRemoteThread (или техните ntdll еквиваленти). Резултатът е същият: произволен код, изпълняващ се в контекста на легитимен процес, но в този случай, без необходимост от DLL файл на диска.
Отвличане на тема
Вместо да създават нови нишки, някои нападатели предпочитат отвличане на съществуваща нишка в рамките на процесаЗа да направят това, те използват API-та като SuspendThread, за да поставят нишката на пауза, GetThreadContext, за да прочетат състоянието ѝ (регистри, указатели към инструкции и др.), SetThreadContext, за да я пренасочат към злонамерения си код и накрая ResumeThread, за да продължат изпълнението от новата дестинация.
Чрез повторно използване на легитимна нишка, тази техника може да бъде по-скритзащото не се появява нова подозрителна нишка, създадена от CreateRemoteThread, а вместо това се използва повторно съществуваща и оторизирана такава.
Инжектиране чрез APC (асинхронно извикване на процедура)
APC ви позволяват да програмирате функции, които да се изпълняват, когато дадена нишка влезе в състояние на тревога. Атакуващ може да използва това, за да да поставите повикване към вашия код в опашка в целевата нишка, използваща QueueUserAPC. Когато тази нишка обработва своята APC опашка (например по време на операция за изчакване), тя ще изпълни злонамерената рутина.
Тази техника често се наблюдава при атаки, които се опитват да се слее с нормалната активност на системата, тъй като разчита на стандартните механизми на Windows.
Отразително инжектиране на DLL
Рефлективното инжектиране на DLL файлове заобикаля стандартния зареждащ файл на Windows. DLL файловете съдържат свои собствени вътрешно зарядно устройство способен да картографира в паметта, да разрешава импортиране и да прилага премествания без да преминава през LoadLibrary.
Атакуващият инжектира както DLL кода, така и персонализирания код за зареждане в целевия процес и изпълнява зареждащата програма. Тъй като тази техника не изисква файл във файловата система, тя е силно уязвима. намалява дисковото пространство и усложнява откриването въз основа на традиционни артефакти.
Процес на издълбаване
Изпразването на процес се състои в създаване на легитимен процес в спряно състояние (CreateProcess с CREATE_SUSPENDED), премахнете оригиналното си изображение (NtUnmapViewOfSection/ZwUnmapViewOfSection), резервиране на памет за ново изображение, записване на злонамерен изпълним файл в него с WriteProcessMemory, поправяне на заглавките и преместванията, настройване на контекста на главния поток (SetThreadContext), за да сочи към новата входна точка, и накрая възобновяване с ResumeThread.
Резултатът е, че изглежда работи диспечер на задачи. легитимен процесНо в действителност паметта му е заменена от зловреден код, който сега се изпълнява с идентичността и разрешенията на оригиналния двоичен файл.
Какво е DLL Hijacking или DLL hijacking?
Експлойти за отвличане на DLL Как Windows търси DLL файлове, когато не е посочен пълният път?Ако атакуващият може да запише в една от директориите, които системата проверява, преди да достигне до оригиналната DLL, той може да вмъкне злонамерена версия със същото име.
Представете си приложение, което се опитва да зареди "mylib.dll" без пълен път. Windows първо ще провери определени директории: собствената директория на приложението, системната директория, папката на Windows, текущата работна директория и тези в PATH. в определен ред в зависимост от режима на защитеното търсене.
Ако атакуващият има права за запис, например, в директорията на приложението или в някоя директория в PATH, която се оценява преди легитимната директория, е достатъчно това депозирайте злонамерения си DLL файл тамWindows ще го намери първо и ще го зареди, сякаш е оригиналът.
Този трик се използва поне от ерата на Windows 2000 и е валиден и днес, особено когато приложенията се изпълняват при стартиране на системата или с... повишени привилегииТова превръща всяка отвлечена DLL система в път за ескалация или запазване на привилегиите.
Варианти на отвличане на DLL файлове: странично зареждане и фантомни DLL файлове
В рамките на понятието „отвличане на DLL“ (DLL hijacking) откриваме няколко варианта. Един от най-известните е Странично зареждане на DLLкъдето злонамерената DLL се поставя в директория, която се намира по-рано в реда на търсене отколкото директорията, където се намира оригиналната DLL. По този начин системата дава приоритет на фалшивото копие.
В Отвличане на фантомни DLL файловеЛегитимният DLL файл дори не съществува в нито една от търсените директории. Софтуерът се опитва да го зареди, защото кодът му го диктува, но тъй като не може да го намери, ще бъде зареден първият файл с това име, който се появява във валидна директория за търсене. Това позволява на атакуващия... създаване на несъществуваща DLL от нулата с подходящо име и местоположение.
Известни DLL файлове, WinSxS и други специални вектори
Windows поддържа списък с Известни DLL файлове в системния регистър (например, в HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs). Ако името на DLL съвпада с такова в този списък, системата ще използва собствено надеждно копие, което ще намали риска от отвличане на тези специфични модули.
Съществуват обаче по-сложни вектори, като например странично зареждане в WinSxSДиректорията C:\Windows\WinSxS съхранява множество версии на DLL файлове. Приложенията използват манифести, за да укажат коя версия на DLL да заредят. Чрез манипулиране на тези манифести или метаданни е възможно да се инжектират фалшиви DLL файлове, които системата ще третира като валидни.
Друг, по-малко очевиден вектор е корекция на списъка с известни DLL файлове или свързани ключове в системния регистър да променя кои DLL файлове се считат за системни DLL файлове или как се разрешават. Атакуващ с достатъчни привилегии може да се опита да манипулира тези записи, за да облагодетелства зареждането на собствените си библиотеки.
Инжектиране на процеси и откриване на отвличане на DLL файлове
Откриването на тези техники не е лесно, защото те разчитат на легитимните механизми на системата И тъй като голяма част от злонамерената активност се случва в паметта. Въпреки това съществуват няколко ефективни стратегии.
Анализ на паметта и поведението
Един подход е да се наблюдават областите на паметта на процесите в търсене на необичайни изпълними области или области, които не са свързани с валидни модулиСтраници, маркирани като PAGE_EXECUTE_READWRITE, внезапни промени в разрешенията за достъп до паметта или наличието на шелкод в региони, които не съответстват на двоични файлове на диска, са типични индикатори.
Те също са наблюдавани динамични модификации на картата на паметтаНеобичайното създаване на нишки и връзки между процеси, които обикновено не взаимодействат, също са проблем. Много съвременни EDR внедряват корелационни механизми, които откриват подозрителни низове, като например: OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread.
Мониторинг на извикванията на Windows API
Друг подход е да се наблюдава използването на критични API. Типичен модел на инжектиране в процес изисква OpenProcess За да се справите с процеса на жертвата, използвайте VirtualAllocEx y Процес на записПамет да запишете данни и да завършите с Създаване на отдалечена нишка, QueueUserAPC или SetThreadContext за задействане на изпълнение.
По подобен начин, низовете за употреба на LoadLibrary / LoadLibraryEx Подозрителните пътища, комбинирани със SearchPath или неправилно използване на текущата работна директория, могат да разкрият опити за отвличане на DLL файлове или опасно предварително зареждане.
Инструменти като Process Monitor / Process Explorer
С комунални услуги като Монитор на процеси (Procmon) y Process Explorer Възможно е да се наблюдава в реално време кои .dll файлове отваря даден процес, от кои пътища и с какъв резултат. Могат да се прилагат филтри, за да се показват само DLL файлове и резултати от типа ИМЕТО НЕ Е НАМЕРЕНО, може да бъде открит неуспешни опити за зареждане или от неочаквани директории.
Ако дадено приложение зарежда DLL файлове от потребителската директория, от временни пътища или от нестандартни местоположения, препоръчително е да проверите дали тези директории са достъпно за запис от потребители без привилегии или чрез сервизни акаунти.
Модели на изкуствен интелект и машинно обучение
Някои съвременни решения, като например определени SIEM и EDR платформи, започнаха да използват модели за машинно обучение за идентифициране на модели на отвличане на DLL файлове. Тези модели приемат като вход метаданни от процеса и библиотеката: пътища, размер, вътрешна структура, цифров подпис, промени в името, местоположение (стандартно или нестандартно) и др.
Комбинирайки тази информация с анонимна телеметрия и репутация в облакаМоделът може да маркира като подозрителен опит за зареждане на необичайна DLL от необичаен път, дори ако файлът не е в никоя известна база данни за зловреден софтуер.
Как да се смекчат инжектирането в процес и отвличането на DLL файлове
Няма един-единствен контрол, който да решава всичко; защитата включва комбинация от добри практики за разработка, укрепване на системата и непрекъснато наблюдениеВъпреки това, има ясни мерки, които значително намаляват риска.
Най-добри практики за разработчици
Ако програмирате в Windows, първото правило е ясно: Използвайте пълни пътища, когато е възможно, в LoadLibrary, CreateProcess и ShellExecute.Не разчитайте на реда на търсене по подразбиране, за да намерите критични DLL файлове.
Освен това, силно се препоръчва да се обадите SetDllDirectory(«») В началото на процеса текущата работна директория (CWD) се премахва от реда за търсене на DLL файлове. Това предотвратява атакуващ да използва компрометирана CWD, за да инжектира своите библиотеки.
Препоръчително е също да се избягват модели като използването Път за търсене за да се намерят DLL файлове, които след това се зареждат с LoadLibrary, тъй като редът на търсене на SearchPath се различава от този на LoadLibrary и може да доведе до неочаквани и опасни резултати.
Когато е възможно, използвайте Подписани DLL файлове и проверка на този подпис преди да ги заредите. Друг вариант е да проверите хеша на библиотеката и да се уверите, че той съответства на очакваната стойност. Това намалява възможността за зареждане на манипулирана DLL, дори ако е в правилния път.
Настройки, специфични за Windows
Windows предлага API-та като например Задаване на режим на търсене За да активирате постоянен режим на безопасно търсене в даден процес, преместете CWD в края на списъка за търсене. След като бъде активиран за постоянно, последващите опити за промяна на този режим ще бъдат неуспешни, което ще засили съгласуваността.
Друга основна препоръка е Не инсталирайте приложения в корена на устройството (например, C:\), защото създадените там директории често наследяват по-широки права за запис за удостоверени потребители. По-добре е да използвате пътища под Program Files или директории с добре контролирани ACL.
Важно е също така правилно да конфигурирате политиките, като например UAC, AppLocker или контрол на приложенията на Windows Defender (WDAC) да се ограничи кои двоични файлове и DLL файлове може да зареди всеки процес и да се наложи целостта на кода (валидни подписи), където е възможно.
Контроли на системно и организационно ниво
На системно ниво, технологии като DEP (Превенция на изпълнението на данни), ASLR (Рандомизация на оформлението на адресното пространство), Защита на контролния поток (CFG) o Защитена технологична светлина (PPL) Те поставят допълнителни пречки пред изпълнението на код в паметта и манипулирането на защитени процеси.
На мрежово и организационно ниво е изключително важно да се поддържа актуализирани антивирусни и EDR решенияТъй като много варианти на DLL инжектиране остават откриваеми с помощта на сигнатури и евристики, специфични инструменти като DLLSPY могат да помогнат за локализирането на уязвимости за ескалация на привилегии, базирани на DLL.
Накрая, трябва да се помни, че много злонамерени DLL файлове навлизат в средата чрез фишинг, социално инженерство или атаки срещу веригата за доставкиОбучението на персонала, внедряването на многофакторно удостоверяване, прегледа на подозрителни имейли и приемането на решения за управление на риска (TPRM) от трети страни спомагат за намаляване на повърхността за атака.
Цялата тази екосистема от техники – класическо DLL инжектиране, DLL отвличане, инжектиране на код, изтичане на данни в процесите и други подобни – демонстрира до каква степен динамично свързаните библиотеки са нож с две остриета: от съществено значение за ефективността на системата, но също така и основен вектор за напреднали атакиРазбирането как работят вътрешно, как се зареждат и какви инструменти съществуват за тяхното наблюдение, позволява вземането на много по-стабилни решения при проектирането на приложения, защитата на крайни точки и реагирането на инциденти в Windows среди.