Эта книга предназначена для всех, кто хочет разобраться в обнаружении угроз на конечных устройствах. Со стороны наступательной безопасности она станет руководством для исследователей, разработчиков средств и операторов красных команд: изложенные здесь сведения о внутреннем устройстве EDR и стратегиях уклонения от них помогут выстраивать атаки. Для специалистов по защитной безопасности та же информация служит иной цели. Понимание принципов работы вашей EDR поможет принимать обоснованные решения при расследовании оповещений, создании новых правил обнаружения, изучении слепых зон и закупке продуктов.

Каждая глава посвящена отдельному датчику EDR или группе компонентов, служащих для сбора определённого вида данных. Сначала мы последовательно разберём, как разработчики обычно реализуют такой компонент, а затем обсудим, какие данные он собирает. Наконец, мы рассмотрим распространённые способы обхода каждого компонента и причины их эффективности.

Это глубоко техническая книга, и, чтобы извлечь из неё максимум пользы, я настоятельно рекомендую заранее познакомиться со следующими темами. Во-первых, знание основных методов тестирования на проникновение поможет лучше понять, почему EDR может пытаться обнаружить определённое действие в системе. Освоить эту тему позволяют многие материалы; среди бесплатных можно назвать цикл публикаций Last Week in Security в блоге Bad Sector Labs, блог Мантвидаса Баранаускаса (Mantvydas Baranauskas) Red Team Notes и блог SpecterOps.

Если вы хотите самостоятельно опробовать рассматриваемые в книге методы, стоит настроить лабораторную среду. Я рекомендую следующую конфигурацию из двух виртуальных машин:

Чтобы понять, как продукты защиты конечных устройств применяют перехват кода, необходимо разобраться во взаимодействии кода пользовательского режима с ядром. Во время выполнения такой код обычно обращается к Win32 API, чтобы осуществлять определённые операции на узле, например запрашивать дескриптор другого процесса. Однако во многих случаях предоставленные Win32 возможности невозможно реализовать целиком в пользовательском режиме. За некоторые операции, в том числе управление памятью и объектами, отвечает ядро.

Для передачи выполнения ядру системы x64 используют инструкцию syscall. Но вместо того чтобы помещать инструкции syscall в каждую функцию, которой требуется взаимодействовать с ядром, Windows предоставляет их через функции в ntdll.dll. Достаточно передать необходимые параметры такой экспортируемой функции; она, в свою очередь, передаст управление ядру, а затем вернёт результаты операции. Например, на рисунке 2-1 показан поток выполнения, возникающий, когда приложение пользовательского режима вызывает функцию Win32 API kernel32!OpenProcess().

Рисунок 2-1. Поток выполнения из пользовательского режима в режим ядра

Чтобы выявлять вредоносные действия, поставщики часто перехватывают эти API Windows. Например, один из способов обнаружения EDR удалённого внедрения в процесс состоит в перехвате функций, которые открывают дескриптор другого процесса, выделяют область памяти, записывают данные в выделенную память и создают удалённый поток.

В ранних версиях Windows поставщики, как и авторы вредоносных программ, часто устанавливали перехватчики в таблице диспетчеризации системных служб (System Service Dispatch Table, SSDT). Это таблица в ядре, содержащая указатели на функции ядра, которые используются при вызове syscall. Защитные продукты заменяли указатели на эти функции указателями на функции собственного модуля ядра. Те регистрировали сведения о вызове, а затем выполняли целевую функцию, после чего передавали возвращённые значения исходному приложению.

С появлением Windows XP в 2005 году Microsoft решила запретить исправление SSDT, а также множества других критически важных структур, с помощью защиты Kernel Patch Protection (KPP), также известной как PatchGuard. Поэтому в современных 64-разрядных версиях Windows этот приём неприменим. Традиционный перехват приходится выполнять в пользовательском режиме. Поскольку функции ntdll.dll, выполняющие системные вызовы, являются последней точкой пользовательского режима, где можно наблюдать вызовы API, EDR часто перехватывают именно их, чтобы проверять вызов и выполнение. Некоторые часто перехватываемые функции перечислены в таблице 2-1.

Таблица 2-1. Часто перехватываемые функции в ntdll.dll

Перехватывая обращения к этим API, EDR может наблюдать как параметры, переданные исходной функции, так и значение, возвращённое вызвавшему API коду. Затем агент способен исследовать эти данные и определить, было ли действие вредоносным. Например, для выявления удалённого внедрения в процесс агент может отслеживать, была ли область памяти выделена с правами чтения, записи и выполнения, записывались ли в новую область данные и создавался ли поток с указателем на эти данные.

Существует множество библиотек, упрощающих реализацию перехвата функций, но внутри большинство из них применяет один и тот же приём. Причина в том, что в основе любого перехвата функций лежит исправление инструкций безусловного перехода (JMP), которое перенаправляет поток выполнения из перехватываемой функции в функцию, указанную разработчиком EDR.

Microsoft Detours - одна из наиболее распространённых библиотек для реализации перехвата функций. Внутри Detours заменяет первые несколько инструкций перехватываемой функции инструкцией безусловного перехода JMP, которая направляет выполнение в определённую разработчиком функцию, также называемую обходной функцией (detour). Она выполняет заданные разработчиком действия, например регистрирует параметры, переданные целевой функции. Затем управление передаётся другой функции, часто называемой трамплином (trampoline), которая выполняет целевую функцию и содержит первоначально перезаписанные инструкции. После завершения целевой функции управление возвращается обходной функции. Прежде чем вернуть управление исходному процессу, обходная функция может выполнить дополнительную обработку, например зарегистрировать возвращённое значение или вывод исходной функции.

На рисунке 2-2 обычный поток выполнения процесса сопоставляется с потоком при наличии обходной функции. Сплошная стрелка обозначает ожидаемый поток выполнения, а пунктирная - перехваченный.

Рисунок 2-2. Обычный и перехваченный пути выполнения

В этом примере EDR решила перехватывать ntdll!NtCreateFile() - системный вызов, который используется для создания нового устройства ввода-вывода либо открытия дескриптора существующего. В обычных условиях этот системный вызов немедленно передаёт выполнение ядру, где работу продолжает его аналог режима ядра. После установки перехватчика EDR выполнение теперь останавливается во внедрённой DLL. Функция edr!HookedNtCreateFile() совершает системный вызов от имени ntdll!NtCreateFile(), что позволяет ей собирать сведения о переданных системному вызову параметрах и о результате операции.

Если исследовать перехваченную функцию в отладчике, например WinDbg, различия между функцией с перехватчиком и без него станут очевидны. В листинге 2-1 показано, как выглядит в WinDbg неперехваченная функция kernel32!Sleep().

Листинг 2-1. Неперехваченная функция kernel32!SleepStub() в WinDbg

Дизассемблированный код функции показывает ожидаемый поток выполнения. Когда вызывающая сторона обращается к kernel32!Sleep(), выполняется заглушка перехода kernel32!SleepStub(), совершающая дальний переход (JMP) к kernel32!_imp_Sleep(), где реализованы настоящие возможности Sleep(), которых ожидает вызывающая сторона.

После внедрения DLL, применяющей Detours для перехвата функции, она выглядит совсем иначе, как показано в листинге 2-2.

Листинг 2-2. Перехваченная функция kernel32!Sleep() в WinDbg

Вместо перехода JMP к kernel32!_imp_Sleep() дизассемблированный код содержит последовательность инструкций JMP, вторая из которых передаёт выполнение в trampoline64!TimedSleep(), как показано в листинге 2-3.

Листинг 2-3. Функция перехвата kernel32!Sleep()

Чтобы собрать показатели выполнения перехваченной функции, этот трамплин определяет длительность сна в тактах процессора, вызывая настоящую функцию kernel32!Sleep() через внутреннюю функцию-обёртку trampoline64!TrueSleep(). Количество тактов выводится во всплывающем сообщении.

Хотя этот пример искусственный, он демонстрирует основу работы любой DLL EDR с перехватом функций: она становится посредником при выполнении целевой функции и собирает сведения о том, как та была вызвана. Здесь наша EDR лишь измеряет длительность сна перехваченной программы. В настоящей EDR таким же образом посредник обслуживал бы важные для действий противника функции, например ntdll!NtWriteVirtualMemory(), которая копирует код в удалённый процесс, но перехватчик уделял бы больше внимания переданным параметрам и возвращённым значениям.

DLL, перехватывающая функции, не особенно полезна, пока не загружена в целевой процесс. Некоторые библиотеки позволяют через API породить процесс и внедрить в него DLL, но для EDR это непрактично: им требуется внедрять свою DLL в процессы, которые пользователи запускают в любое время. К счастью, Windows предоставляет несколько способов сделать это.

До Windows 8 многие поставщики предпочитали использовать инфраструктуру AppInit_Dlls, чтобы загружать свои DLL в каждый интерактивный процесс, то есть процесс, импортирующий user32.dll. К сожалению, авторы вредоносных программ регулярно злоупотребляли этим приёмом для закрепления и сбора информации; кроме того, он был печально известен проблемами с производительностью системы. Microsoft больше не рекомендует этот способ внедрения DLL, а начиная с Windows 8 полностью блокирует его в системах с включённой безопасной загрузкой.

Самый распространённый способ внедрить DLL с перехватом функций в процессы - воспользоваться драйвером. Он может задействовать функцию уровня ядра, которая называется внедрением через асинхронный вызов процедуры ядра (kernel asynchronous procedure call, KAPC). Получив уведомление о создании нового процесса, драйвер выделяет часть памяти процесса под процедуру APC и имя внедряемой DLL. Затем он инициализирует новый объект APC, отвечающий за загрузку DLL в процесс, и копирует его в адресное пространство процесса. Наконец, драйвер изменяет флаг в состоянии APC потока, принудительно вызывая выполнение APC. Когда процесс возобновит работу, процедура APC запустится и загрузит DLL. Этот процесс подробнее объясняется в главе 5.

Специалисты по наступательной безопасности часто хотят определить, перехвачены ли функции, которые они собираются применять. Выявив такие функции, можно составить их список, а затем ограничить или полностью исключить их использование. Это позволяет противнику обойти проверку со стороны DLL EDR с перехватом функций, поскольку проверяющая функция никогда не будет вызвана. Обнаружить перехваченные функции чрезвычайно просто, особенно если речь идёт о функциях собственного API, экспортируемых ntdll.dll.

Каждая функция внутри ntdll.dll состоит из заглушки системного вызова. Составляющие её инструкции показаны в листинге 2-4.

Листинг 2-4. Инструкции ассемблера заглушки системного вызова

Эту заглушку можно увидеть, дизассемблировав экспортируемую ntdll.dll функцию в WinDbg, как показано в листинге 2-5.

Листинг 2-5. Неизменённая заглушка системного вызова для ntdll!NtAllocateVirtualMemory()

В дизассемблированном коде ntdll!NtAllocateVirtualMemory() видны основные строительные блоки заглушки системного вызова. Заглушка сохраняет изменяемый регистр RCX в регистре R10, а затем помещает в EAX номер системного вызова, соответствующий NtAllocateVirtualMemory(), - 0x18 в этой версии Windows. Следующие за MOV инструкции TEST и условного перехода JNE выполняют проверку, присутствующую во всех заглушках системных вызовов. Она используется Restricted User Mode, когда Hypervisor Code Integrity включена для кода режима ядра, но не для кода пользовательского режима. В данном контексте её можно спокойно игнорировать. Наконец, выполняется инструкция syscall, передающая управление ядру для выделения памяти. Когда функция завершается и управление возвращается ntdll!NtAllocateVirtualMemory(), та просто выполняет возврат.

Поскольку заглушка системного вызова одинакова для всех функций собственного API, любое её изменение указывает на присутствие перехватчика. Например, в листинге 2-6 показана изменённая заглушка системного вызова для функции ntdll!NtAllocateVirtualMemory().

Листинг 2-6. Перехваченная функция ntdll!NtAllocateVirtualMemory()

Обратите внимание: в точке входа ntdll!NtAllocateVirtualMemory() вместо заглушки системного вызова находится инструкция безусловного перехода JMP. EDR часто вносят такое изменение, чтобы перенаправить поток выполнения в свою DLL с перехватчиками.

Следовательно, чтобы обнаружить установленные EDR перехватчики, достаточно исследовать функции в копии ntdll.dll, которая в данный момент загружена в наш процесс, и сравнить инструкции в точках входа с ожидаемыми кодами операций неизменённой заглушки системного вызова. Обнаружив перехватчик нужной нам функции, можно попытаться обойти его способами, описанными в следующем разделе.

Среди всех компонентов датчиков, применяемых средствами защиты конечных устройств, перехват функций относится к наиболее тщательно изученным с точки зрения обхода. Атакующие могут уклоняться от перехвата функций множеством способов, которые в основном сводятся к одному из следующих приёмов:

• Выполнять прямые системные вызовы, исполняя инструкции неизменённой заглушки системного вызова.

• Повторно отображать ntdll.dll, чтобы получить указатели на неперехваченные функции, либо перезаписывать перехваченную ntdll.dll, уже отображённую в процессе.

• Блокировать загрузку DLL не от Microsoft в процесс, чтобы DLL EDR с перехватом функций не могла установить свои обходные функции.

Этот перечень ни в коем случае не исчерпывающий. Пример приёма, не относящегося ни к одной из этих категорий, - векторная обработка исключений, подробно описанная в публикации Питера Уинтера-Смита (Peter Winter-Smith) «FireWalker: A New Approach to Generically Bypass User-Space EDR Hooking». В его методе используется обработчик векторных исключений (vectored exception handler, VEH) - расширение структурированной обработки исключений, которое позволяет разработчику зарегистрировать собственную функцию для наблюдения за всеми исключениями заданного приложения и их обработки. Метод устанавливает флаг трассировки процессора, переводя программу в режим пошагового выполнения. На каждой новой инструкции код обхода создаёт исключение одиночного шага, которое VEH получает право обработать первым. Изменяя указатель инструкций так, чтобы он указывал на фрагмент с исходным неизменённым кодом, VEH переступает через установленный EDR перехватчик.

Несмотря на интересность, сейчас этот приём работает только в 32-разрядных приложениях и из-за пошагового выполнения может отрицательно сказаться на производительности программы. По этим причинам данный подход к обходу выходит за рамки главы. Вместо него мы сосредоточимся на приёмах с более широкой областью применения.

Безусловно, чаще всего для обхода перехватчиков функций ntdll.dll злоумышленники пользуются прямыми системными вызовами. Если самостоятельно выполнить инструкции заглушки системного вызова, можно имитировать неизменённую функцию. Для этого наш код должен содержать сигнатуру нужной функции, заглушку с правильным номером системного вызова и вызов целевой функции. При вызове сигнатура и заглушка используются для передачи необходимых параметров и выполнения целевой функции таким способом, который не будет замечен перехватчиками. В листинге 2-7 приведён первый файл, который необходимо создать для применения этого приёма.

Листинг 2-7. Ассемблерные инструкции для NtAllocateVirtualMemory()

Первый файл нашего проекта фактически содержит повторную реализацию ntdll!NtAllocateVirtualMemory(). Инструкции единственной функции заполняют регистр EAX номером системного вызова, после чего выполняется инструкция syscall. Этот ассемблерный код должен находиться в отдельном файле .asm; Visual Studio можно настроить так, чтобы он компилировался вместе с остальной частью проекта с помощью Microsoft Macro Assembler (MASM).

Хотя заглушка системного вызова уже создана, нам всё ещё нужен способ вызвать её из своего кода. Листинг 2-8 показывает, как это сделать.

Листинг 2-8. Определение NtAllocateVirtualMemory(), которое следует включить в заголовочный файл проекта

Определение функции содержит все необходимые параметры и их типы, а также тип возвращаемого значения. Оно должно находиться в нашем заголовочном файле syscall.h, который будет включён в файл исходного кода C, показанный в листинге 2-9.

Листинг 2-9. Выполнение прямого системного вызова на C

Функция wmain() в этом файле вызывает NtAllocateVirtualMemory() 1, чтобы выделить в текущем процессе буфер размером 0x1000 байт с правами чтения и записи. Эта функция не определена в заголовочных файлах, предоставляемых Microsoft разработчикам, поэтому нам приходится объявить её в собственном заголовочном файле. При вызове функции вместо перехода в ntdll.dll будет вызван включённый в проект ассемблерный код. Таким образом, мы фактически воспроизводим поведение неперехваченной ntdll!NtAllocateVirtualMemory(), не рискуя попасть в перехватчик EDR.

Одна из главных трудностей этого приёма заключается в том, что Microsoft часто меняет номера системных вызовов. Поэтому инструменты, где эти номера жёстко заданы, могут работать только в определённых сборках Windows. Например, в сборке 1909 Windows 10 номер системного вызова ntdll!NtCreateThreadEx() равен 0xBD, а в следующем выпуске, сборке 20H1, - 0xC1. Значит, инструмент, рассчитанный на сборку 1909, не будет работать в более поздних версиях Windows.

Для устранения этого ограничения многие разработчики отслеживают изменения по внешним источникам. Например, Матеуш Юрчик (Mateusz Jurczyk) из Google Project Zero ведёт список функций и соответствующих им номеров системных вызовов для каждого выпуска Windows. В декабре 2019 года Джексон Турайсами (Jackson Thuraisamy) опубликовал инструмент SysWhispers, который позволил атакующим динамически создавать сигнатуры функций и ассемблерный код системных вызовов для своих наступательных инструментов. В листинге 2-10 показан ассемблерный код, созданный SysWhispers для функции ntdll!NtCreateThreadEx() в сборках Windows 10 с 1903 по 20H2.

Листинг 2-10. Вывод SysWhispers для ntdll!NtCreateThreadEx()

Этот ассемблерный код извлекает номер сборки из блока окружения процесса 1, а затем использует полученное значение, чтобы поместить подходящий номер системного вызова в регистр EAX 2 перед выполнением самого вызова 3. Подход работает, но требует значительных усилий, поскольку после каждого выпуска новой сборки Windows со стороны Microsoft атакующему приходится обновлять номера системных вызовов в своём наборе данных.

В декабре 2020 года исследователь, известный в Twitter под именем @modexpblog, опубликовал статью «Bypassing User-Mode Hooks and Direct Invocation of System Calls for Red Teams». В ней описывался другой способ обхода перехватчиков функций: динамическое определение номеров системных вызовов во время выполнения, избавляющее атакующих от необходимости жёстко задавать значения для каждой сборки Windows. Для создания словаря имён функций и номеров системных вызовов этот приём предусматривает следующие действия:

1. Получить дескриптор отображённой в текущий процесс ntdll.dll.

2. Перечислить все экспортируемые функции, имена которых начинаются с Zw, чтобы выявить системные вызовы. Обратите внимание: функции с более привычным префиксом Nt при вызове из пользовательского режима работают точно так же. По всей видимости, решение использовать вариант Zw в данном случае произвольно.

3. Сохранить имена экспортируемых функций и связанные с ними относительные виртуальные адреса.

4. Отсортировать словарь по относительным виртуальным адресам.

5. Определить номер системного вызова функции как её индекс в словаре после сортировки.

С помощью этого приёма можно получать номера системных вызовов во время выполнения, вставлять их в нужное место заглушки, а затем вызывать целевые функции так же, как при использовании метода со статически заданными значениями.

Ещё один распространённый способ обхода перехватчиков функций пользовательского режима состоит в том, чтобы загрузить в процесс новую копию ntdll.dll, заменить содержимым только что загруженного файла существующую перехваченную версию, а затем вызвать нужные функции. Эта стратегия работает потому, что новая ntdll.dll не содержит перехватчиков, реализованных в загруженной ранее копии. Заменяя заражённую версию, она фактически удаляет все установленные EDR перехватчики. Простой пример показан в листинге 2-11. Для краткости некоторые строки опущены.

Листинг 2-11. Способ перезаписи перехваченной ntdll.dll

Сначала наш код получает базовый адрес загруженной в данный момент перехваченной ntdll.dll 1. Затем мы считываем содержимое ntdll.dll с диска и отображаем его в память 2. Теперь можно разобрать заголовки PE перехваченной ntdll.dll и найти адрес раздела .text 3, где в образе хранится исполняемый код. Обнаружив его, мы изменяем права этой области памяти, чтобы получить возможность записи 4, копируем в неё содержимое раздела .text из «чистого» файла 5, а затем возвращаем прежнюю защиту памяти 6. После выполнения этой последовательности первоначально установленные EDR перехватчики должны быть удалены, и разработчик сможет вызвать любую нужную функцию из ntdll.dll, не опасаясь, что выполнение будет перенаправлено во внедрённую DLL EDR.

Хотя чтение ntdll.dll с диска кажется простым, у него есть возможный недостаток. Многократная загрузка ntdll.dll в один процесс - нетипичное поведение. Защитники могут регистрировать такую активность с помощью Sysmon, бесплатной программы мониторинга системы, предоставляющей многие из тех же возможностей сбора телеметрии, что и EDR. Почти в каждом невредоносном процессе одному GUID процесса соответствует одна загрузка ntdll.dll. Когда я запросил эти свойства в крупной корпоративной среде, оказалось, что за месяц ntdll.dll более одного раза загрузили лишь около 0,04 процента из 37 миллионов процессов.

Чтобы избежать обнаружения по этой аномалии, можно породить новый процесс в приостановленном состоянии, получить дескриптор отображённой в него неизменённой ntdll.dll и скопировать её в текущий процесс. После этого можно либо получить указатели на функции описанным выше способом, либо заменить существующую перехваченную ntdll.dll, фактически перезаписав установленные EDR перехватчики. Этот приём показан в листинге 2-12.

Листинг 2-12. Повторное отображение ntdll.dll с помощью приостановленного процесса

В этом минимальном примере сначала открывается дескриптор копии ntdll.dll 1, в данный момент отображённой в наш процесс, получается её базовый адрес и разбираются заголовки PE 2. Затем создаётся приостановленный процесс 3 и разбираются заголовки PE его копии ntdll.dll 4, которую EDR ещё не успела перехватить. Остальной поток выполнения функции в точности совпадает с предыдущим примером; после его завершения перехваченная ntdll.dll должна вернуться в чистое состояние.

Как и всегда, здесь тоже приходится идти на компромисс: новый приостановленный процесс создаёт ещё одну возможность обнаружения, например перехваченной функцией ntdll!NtCreateProcessEx(), драйвером или поставщиком ETW. По моему опыту, законные программы крайне редко создают временный приостановленный процесс.

Перехват функций - один из первоначальных механизмов, с помощью которых продукт защиты конечных устройств способен отслеживать поток выполнения других процессов. Он предоставляет EDR весьма полезную информацию, однако из-за внутренних слабостей распространённых реализаций очень уязвим для обхода. Поэтому сегодня большинство зрелых EDR считает перехват функций вспомогательным источником телеметрии и вместо него полагается на более устойчивые датчики.

Одна из самых мощных возможностей драйверов в контексте EDR - получение уведомлений при наступлении системного события. К таким событиям относятся создание и завершение процессов и потоков, запросы на дублирование процессов и потоков, загрузка образов, действия в реестре и запросы на выключение системы. Например, разработчику может потребоваться узнать, пытается ли процесс открыть новый дескриптор lsass.exe, поскольку это важная составляющая большинства способов извлечения учётных данных.

Процедуры обратного вызова могут уведомлять драйвер при каждом создании или завершении процесса в системе. Такие уведомления являются неотъемлемой частью создания или завершения процесса. Это видно в листинге 3-1, где показан стек вызовов при создании программой cmd.exe дочернего процесса notepad.exe, которое привело к уведомлению зарегистрированных процедур обратного вызова.

Чтобы получить этот стек вызовов, с помощью WinDbg установите точку останова (bp) на nt!PspCallProcessNotifyRoutines() - внутренней функции ядра, уведомляющей драйверы с зарегистрированными процедурами о событиях создания процессов. Когда сработает точка останова, команда k вернёт стек вызовов процесса, в котором произошла остановка.

Листинг 3-1. Стек вызовов при создании процесса

Когда пользователь запускает исполняемый файл, cmd.exe вызывает функцию cmd!ExecPgm(). В этом стеке видно, что она обращается к заглушке, предназначенной для создания нового процесса, строка вывода 07. В конечном итоге заглушка выполняет системный вызов ntdll!NtCreateUserProcess(), где управление передаётся ядру, строка 04.

Теперь обратите внимание, что внутри ядра выполняется ещё одна функция, строка 00. Она сообщает каждой зарегистрированной процедуре обратного вызова о том, что создаётся процесс.

Для регистрации процедур обратного вызова для процессов EDR применяют одну из двух функций: nt!PsSetCreateProcessNotifyRoutineEx() или nt!PsSetCreateProcessNotifyRoutineEx2(). Вторая также может предоставлять уведомления о процессах подсистем, отличных от Win32. Эти функции получают указатель на функцию обратного вызова, которая выполняет некоторое действие при каждом создании или завершении процесса. В листинге 3-2 показана регистрация такой функции.

Листинг 3-2. Регистрация процедуры обратного вызова для создания процесса

Код регистрирует процедуру обратного вызова 1 и передаёт регистрирующей функции три аргумента. Первый, PsCreateProcessNotifySubsystems, указывает тип регистрируемого уведомления о процессе. На момент написания книги «подсистемы» - единственный тип, документированный Microsoft. Это значение сообщает системе, что процедуру обратного вызова следует вызывать для процессов, созданных во всех подсистемах, в том числе Win32 и Windows Subsystem for Linux (WSL).

Следующий аргумент задаёт точку входа процедуры обратного вызова, которую требуется выполнить при создании процесса. В нашем примере код указывает на внутреннюю функцию ProcessNotifyCallbackRoutine(). Когда происходит создание процесса, эта функция обратного вызова получает сведения о событии, которые мы вскоре обсудим.

Третий аргумент - логическое значение, показывающее, следует ли удалить процедуру обратного вызова. Поскольку в данном примере мы регистрируем процедуру, передаётся FALSE. При выгрузке драйвера мы указали бы TRUE, чтобы удалить процедуру из системы. Зарегистрировав процедуру обратного вызова, мы определяем саму функцию обратного вызова 2.

С помощью WinDbg можно увидеть список процедур обратного вызова для процессов в системе. При регистрации новой процедуры указатель на неё добавляется в массив структур EX_FAST_REF. Это выровненные по 16 байтам указатели, которые хранятся в массиве по адресу nt!PspCreateProcessNotifyRoutine, как показано в листинге 3-3.

Листинг 3-3. Массив структур EX_FAST_REF, содержащий адреса процедур обратного вызова для создания процессов

В листинге 3-4 показан способ перебора массива структур EX_FAST_REF для перечисления драйверов, реализующих процедуры обратного вызова для уведомлений о процессах.

Листинг 3-4. Перечисление зарегистрированных процедур обратного вызова для создания процессов

Здесь видны некоторые процедуры, зарегистрированные в системе по умолчанию. Обратите внимание, что не все они выполняют функции безопасности. Например, процедура, имя которой начинается с tcpip, используется в драйвере TCP/IP. Вместе с тем видно, что Microsoft Defender зарегистрировал процедуру WdFilter+0x45e00. Microsoft не публикует полные символы для драйвера WdFilter.sys. С помощью этого приёма можно найти процедуру обратного вызова EDR без обратной разработки драйвера Microsoft.

Как EDR получает доступ к информации после регистрации процедуры обратного вызова? При создании нового процесса процедуре передаётся указатель на структуру PS_CREATE_NOTIFY_INFO, определение которой приведено в листинге 3-5.

Листинг 3-5. Определение структуры PS_CREATE_NOTIFY_INFO

Эта структура содержит значительный объём ценных данных о событиях создания процессов в системе, в том числе:

ParentProcessId. Родитель вновь созданного процесса. Это не обязательно тот процесс, который создал новый.

CreatingThreadId. Дескрипторы уникального потока и процесса, отвечающих за создание нового процесса.

FileObject. Указатель на объект исполняемого файла процесса, то есть образ на диске.

ImageFileName. Указатель на строку, содержащую путь к исполняемому файлу вновь созданного процесса.

CommandLine. Аргументы командной строки, переданные создающему процессу.

FileOpenNameAvailable. Значение, указывающее, совпадает ли член ImageFileName с именем файла, использованным для открытия исполняемого файла нового процесса.

Один из распространённых способов взаимодействия EDR с телеметрией, возвращённой этим уведомлением, демонстрирует событие Sysmon с идентификатором 1 - событие создания процесса, показанное на рисунке 3-1.

Рисунок 3-1. Событие Sysmon с идентификатором 1, показывающее создание процесса

В этом событии видна часть сведений из структуры PS_CREATE_NOTIFY_INFO, переданной процедуре обратного вызова Sysmon. Например, свойства события Image, CommandLine и ParentProcessId соответствуют членам структуры ImageFileName, CommandLine и ParentProcessId.

Вас может удивить, почему в событии значительно больше свойств, чем в структуре, полученной процедурой обратного вызова. Драйвер собирает эти дополнительные сведения, исследуя контекст потока, в котором было создано событие, и дополняя члены структуры. Например, зная идентификатор родительского процесса, легко найти путь к его образу и заполнить свойство ParentImage.

Используя данные, собранные из этого события и связанной с ним структуры, EDR также может создавать внутренние отображения свойств и связей процессов, чтобы выявлять подозрительную активность, например создание powershell.exe программой Microsoft Word в качестве дочернего процесса. Эти данные способны предоставить агенту полезный контекст и для определения вредоносности другой активности. Например, агент может передать аргументы командной строки процесса модели машинного обучения, чтобы выяснить, является ли такой вызов команды необычным для среды.

Уведомления о создании потоков несколько менее ценны, чем события создания процессов. Они работают во многом сходным образом и возникают во время создания, но содержат меньше информации. И это несмотря на то, что потоки создаются значительно чаще: почти каждый процесс поддерживает многопоточность, а значит, на каждое событие создания процесса будет приходиться более одного уведомления о создании потока.

Хотя процедуры обратного вызова для создания потоков передают значительно меньше данных, они всё же предоставляют EDR ещё одну точку данных, на основе которой можно строить правила обнаружения. Рассмотрим их немного подробнее.

При создании или завершении потока процедура обратного вызова получает три элемента данных: идентификатор процесса, которому принадлежит поток, уникальный идентификатор потока и логическое значение, указывающее, создаётся ли поток. В листинге 3-6 показано, как драйвер регистрирует процедуру обратного вызова для событий создания потоков.

Листинг 3-6. Регистрация процедуры уведомления о создании потока

Как и в случае с созданием процесса, EDR может получать через драйвер уведомления о создании или завершении потока. Для этого процедура обратного вызова для уведомлений о потоке регистрируется функцией nt!PsSetCreateThreadNotifyRoutine() или расширенной функцией nt!PsSetCreateThreadNotifyRoutineEx(), которая дополнительно позволяет задавать тип уведомления.

Сначала пример драйвера регистрирует процедуру обратного вызова 1, передавая указатель на внутреннюю функцию обратного вызова. Та получает те же три элемента данных, что передаются процедурам обратного вызова для процессов. Если логическое значение, показывающее создание или завершение потока, равно TRUE, драйвер выполняет некоторое заданное разработчиком действие 2. В противном случае процедура просто игнорирует события потока, поскольку события завершения потока, возникающие после окончания его выполнения и возврата, обычно менее ценны для мониторинга безопасности.

Хотя уведомления о создании потоков предоставляют меньше сведений, чем процедуры обратного вызова для создания процессов, они дают EDR данные о событии, которое не способны выявить другие процедуры, - о создании удалённого потока. Создание удалённого потока происходит, когда один процесс создаёт поток внутри другого. Этот приём лежит в основе множества методов злоумышленников, которым часто требуется изменить контекст выполнения, например перейти от пользователя 1 к пользователю 2. В листинге 3-7 показано, как EDR может выявить такое поведение с помощью процедуры обратного вызова для создания потоков.

Листинг 3-7. Обнаружение создания удалённого потока

Поскольку уведомление выполняется в контексте процесса, создающего поток, разработчику достаточно проверить, совпадает ли идентификатор текущего процесса с переданным процедуре обратного вызова 1. Если нет, поток создаётся удалённо и это следует исследовать. Вот и всё: огромная возможность обеспечивается одной-двумя строками кода. Лучше почти не бывает. Реализацию этой функции в реальной системе можно увидеть в событии Sysmon с идентификатором 8, показанном на рисунке 3-2. Обратите внимание, что значения SourceProcessId и TargetProcessId различаются.

Рисунок 3-2. Событие Sysmon с идентификатором 8, выявляющее создание удалённого потока

Разумеется, удалённые потоки создаются во многих законных обстоятельствах. Один из примеров - создание дочернего процесса. При создании процесса первый поток выполняется в контексте родительского процесса. Чтобы учесть это обстоятельство, многие EDR просто не принимают во внимание первый поток, связанный с процессом.

Некоторые внутренние компоненты операционной системы также законно создают удалённые потоки. Примером служит система отчётов об ошибках Windows (werfault.exe). После возникновения системной ошибки операционная система порождает werfault.exe как дочерний процесс svchost.exe, а точнее службы WerSvc, после чего внедряется в процесс, вызвавший ошибку.

Таким образом, сам факт удалённого создания потока не делает его автоматически вредоносным. Чтобы это определить, EDR должна собрать дополнительные сведения, как показано в событии Sysmon с идентификатором 8.

С уведомлениями о процессах и потоках связано больше правил обнаружения, чем с любыми другими видами процедур обратного вызова. Отчасти это объясняется тем, что предоставляемые ими сведения критически важны для большинства стратегий обнаружения, ориентированных на процессы, и используются почти каждым коммерческим продуктом EDR. Кроме того, эти уведомления обычно проще всего понять. Однако это не означает, что их столь же легко обойти. И всё же существует множество процедур, повышающих наши шансы где-нибудь проскользнуть сквозь щели.

Один из чаще всего отслеживаемых атрибутов события создания процесса - аргументы командной строки, с которыми процесс был вызван. Некоторые стратегии обнаружения даже целиком строятся вокруг конкретных аргументов командной строки, связанных с известным наступательным инструментом или вредоносной программой.

EDR может найти аргументы в члене CommandLine структуры, переданной процедуре обратного вызова для создания процесса. При создании процесса аргументы его командной строки сохраняются в поле ProcessParameters блока окружения процесса (process environment block, PEB). Это поле содержит указатель на структуру RTL_USER_PROCESS_PARAMETERS, в которой, помимо прочего, находится UNICODE_STRING с параметрами, переданными процессу при вызове. В листинге 3-8 показано, как вручную получить аргументы командной строки процесса с помощью WinDbg.

Листинг 3-8. Получение параметров из PEB с помощью WinDbg

В этом примере мы извлекаем параметры из PEB текущего процесса, непосредственно обращаясь к члену Buffer структуры UNICODE_STRING, которая образует член CommandLine поля ProcessParameters.

Однако PEB находится в пространстве памяти пользовательского режима процесса, а не в ядре, поэтому процесс способен менять атрибуты собственного PEB. В публикации Адама Честера (Adam Chester) «How to Argue like Cobalt Strike» подробно объясняется, как изменить аргументы командной строки процесса. Прежде чем рассматривать этот приём, нужно понять, как выглядит создание дочернего процесса обычной программой. Простой пример такого поведения приведён в листинге 3-9.

Листинг 3-9. Обычное создание дочернего процесса

Эта базовая реализация порождает дочерний процесс cmd.exe с аргументами These are my sensitive arguments. При выполнении процесса любое стандартное средство мониторинга процессов должно увидеть дочерний процесс и его неизменённые аргументы, прочитав их из PEB. Например, на рисунке 3-3 мы извлекаем параметры командной строки с помощью инструмента Process Hacker.

Рисунок 3-3. Аргументы командной строки, полученные из PEB

Как и ожидалось, процесс cmd.exe был порождён с переданной ему строкой из пяти аргументов. Запомним этот пример: он станет нашей безобидной исходной точкой, когда мы начнём пытаться скрыть вредоносную программу.

В публикации Честера описан следующий порядок изменения аргументов командной строки, использованных для вызова процесса. Сначала создайте дочерний процесс в приостановленном состоянии, передав свои вредоносные аргументы. Затем с помощью ntdll!NtQueryInformationProcess() получите адрес PEB дочернего процесса и скопируйте его вызовом kernel32!ReadProcessMemory(). Получите поле ProcessParameters и замените поддельными аргументами структуру UNICODE_STRING, представленную членом CommandLine, на который указывает ProcessParameters. Наконец, возобновите дочерний процесс.

Заменим исходные аргументы из листинга 3-9 строкой Spoofed arguments passed instead. Такое поведение показано в листинге 3-10; изменения в оригинале выделены полужирным.

Листинг 3-10. Перезапись аргументов командной строки

При создании процесса мы передаём функции флаг CREATE_SUSPENDED, чтобы запустить его в приостановленном состоянии. Далее требуется получить адрес параметров процесса в PEB. Для краткости этот код опущен в листинге 3-10, но сделать это можно с помощью ntdll!NtQueryInformationProcess(), передав класс сведений ProcessBasicInformation. Функция должна вернуть структуру PROCESS_BASIC_INFORMATION, содержащую член PebBaseAddress.

Затем PEB дочернего процесса можно прочитать в локально выделенный буфер. Из него мы извлекаем параметры и передаём адрес PEB, после чего с помощью ProcessParameters копируем их в другой локальный буфер. В нашем коде этот последний буфер называется pParameters и приводится к указателю на структуру RTL_USER_PROCESS_PARAMETERS. Существующие параметры заменяются новой строкой посредством вызова kernel32!WriteProcessMemory(). Если всё завершилось без ошибок, мы вызываем kernel32!ResumeThread(), позволяя приостановленному дочернему процессу закончить инициализацию и начать выполнение.

Теперь Process Hacker показывает поддельные значения аргументов, как видно на рисунке 3-4.

Рисунок 3-4. Аргументы командной строки, заменённые поддельными значениями

Хотя этот приём остаётся одним из наиболее эффективных способов уклонения от обнаружения по подозрительным аргументам командной строки, у него есть несколько ограничений. Одно из них состоит в том, что процесс не может изменить собственные аргументы командной строки. Следовательно, если мы не управляем родительским процессом, как в случае полезной нагрузки первоначального доступа, процесс должен выполниться с исходными аргументами. Кроме того, значение, которым заменяются подозрительные аргументы в PEB, должно быть длиннее исходного. Если оно короче, перезапись будет неполной и часть подозрительных аргументов сохранится. Это ограничение показано на рисунке 3-5.

Рисунок 3-5. Частично перезаписанные аргументы командной строки

Здесь мы сократили аргументы до значения Spoofed arguments. Как видно, оно заменило лишь часть исходных аргументов. Обратное тоже верно: если поддельное значение длиннее исходных аргументов, поддельные аргументы будут усечены.

Почти каждая EDR умеет тем или иным способом сопоставлять родительские и дочерние процессы в системе. Это позволяет агенту выявлять подозрительные связи процессов, например порождение rundll32.exe программой Microsoft Word, что может указывать на первоначальный доступ атакующего или успешную эксплуатацию службы.

Поэтому, чтобы скрыть вредоносное поведение на узле, атакующие часто стремятся подменить родителя текущего процесса. Если заставить EDR поверить, что создание вредоносного процесса на самом деле нормально, вероятность обнаружения существенно снизится. Чаще всего для этого изменяют список атрибутов процесса и потока дочернего процесса - приём, который популяризировал Дидье Стивенс (Didier Stevens) в 2009 году. Такое уклонение основано на том, что в Windows дочерние процессы наследуют от родительских некоторые атрибуты, например текущий рабочий каталог и переменные среды. Между родительским и дочерним процессами не существует зависимостей, поэтому родительский процесс можно задать в значительной мере произвольно, как будет показано в этом разделе.

Чтобы лучше понять эту стратегию, углубимся в создание процессов в Windows. Основной API для этой цели имеет вполне ожидаемое имя kernel32!CreateProcess(). Его определение приведено в листинге 3-11.

Листинг 3-11. Определение API kernel32!CreateProcess()

Девятый параметр этой функции - указатель на структуру STARTUPINFO или STARTUPINFOEX. Структура STARTUPINFOEX, определённая в листинге 3-12, расширяет базовую структуру сведений о запуске указателем на структуру PROC_THREAD_ATTRIBUTE_LIST.

Листинг 3-12. Определение структуры STARTUPINFOEX

При создании процесса мы можем вызвать kernel32!InitializeProcThreadAttributeList(), чтобы инициализировать список атрибутов, а затем kernel32!UpdateProcThreadAttribute(), чтобы его изменить. Это позволяет задать пользовательские атрибуты создаваемого процесса. При подмене родительского процесса нас интересует атрибут PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, который показывает, что передаётся дескриптор желаемого родительского процесса. Чтобы получить этот дескриптор, необходимо приобрести дескриптор целевого процесса: открыть новый или воспользоваться уже имеющимся.

В листинге 3-13 приведён пример подмены родительского процесса, объединяющий все эти части. Мы изменим атрибуты утилиты Notepad, чтобы её родительским процессом казалась VMware Tools.

Листинг 3-13. Пример подмены родительского процесса

Сначала мы жёстко задаём идентификатор процесса vmtoolsd.exe 1, который хотим представить родительским. В реальных условиях вместо этого можно было бы найти идентификатор нужного родителя программно, но ради краткости я решил не включать этот код в пример. Затем функция SpoofParent() вызывает kernel32!OpenProcess() 2. Эта функция открывает новый дескриптор существующего процесса с правами доступа, запрошенными разработчиком. В большинстве наступательных инструментов вы, вероятно, привыкли видеть эту функцию с такими аргументами, как PROCESS_VM_READ для чтения памяти процесса или PROCESS_ALL_ACCESS, предоставляющим полный контроль над процессом. Однако в этом примере мы запрашиваем PROCESS_CREATE_PROCESS. Это право доступа необходимо, чтобы использовать целевой процесс в качестве родительского с нашей расширенной структурой сведений о запуске. После завершения функции у нас будет дескриптор vmtoolsd.exe с подходящими правами.

Далее необходимо создать и заполнить структуру PROC_THREAD_ATTRIBUTE_LIST. Для этого мы применяем довольно распространённый приём программирования Windows: узнаём размер структуры и выделяем ей нужный объём памяти. Мы вызываем функцию инициализации списка атрибутов 3, передавая нулевой указатель вместо адреса настоящего списка. Однако указатель на DWORD всё равно передаётся; после завершения в нём будет записан требуемый размер. Затем с помощью сохранённого в этой переменной размера мы выделяем память в куче функцией kernel32!HeapAlloc() 4. Теперь можно ещё раз вызвать функцию инициализации списка атрибутов, передав ей указатель на только что созданную область в куче.

На этом этапе всё готово к подмене. Сначала мы вызываем функцию изменения списка атрибутов и передаём ей сам список, флаг, указывающий на дескриптор родительского процесса, и открытый нами дескриптор vmtoolsd.exe 5. В результате vmtoolsd.exe становится родительским процессом для всего, что мы создадим с этим списком атрибутов. Остаётся передать список атрибутов функции создания процесса, указав создаваемый дочерний процесс и флаг EXTENDED_STARTUPINFO_PRESENT. После выполнения функции в Process Hacker программа notepad.exe будет выглядеть дочерней для vmtoolsd.exe, а не для своего настоящего родителя ppid-spoof.exe, как показано на рисунке 3-6.

Рисунок 3-6. Поддельный родительский процесс в Process Hacker

К несчастью для противника, такое уклонение относительно легко обнаруживается несколькими способами. Первый из них использует драйвер. Вспомните, что структура, передаваемая драйверу при событии создания процесса, содержит два разных поля, связанных с родительскими процессами: ParentProcessId и CreatingThreadId. В большинстве обычных обстоятельств оба поля указывают на один процесс, но при подмене идентификатора родительского процесса (parent process ID, PPID) нового процесса поле CreatingThreadId.UniqueProcess будет содержать PID процесса, который вызвал функцию создания процесса. В листинге 3-14 показан вывод имитации драйвера EDR, захваченный программой DbgView, предназначенной для перехвата отладочных печатных сообщений.

Листинг 3-14. Получение сведений о родительском и создающем процессах из драйвера

Как видно, поддельный vmtoolsd.exe указан родительским процессом, однако создателем, то есть настоящим процессом, запустившим notepad.exe, определён ppid-spoof.exe.

Другой способ выявления подмены PPID основан на ETW, которую мы подробнее рассмотрим в главе 8. Компания F-Secure подробно описала этот приём в публикации «Detecting Parent PID Spoofing». Стратегия обнаружения опирается на то, что идентификатор процесса, указанный в заголовке события ETW, принадлежит создателю процесса, а не родительскому процессу из данных события. Поэтому в нашем примере защитники могут с помощью трассировки ETW регистрировать события создания процессов на узле при каждом порождении notepad.exe. Полученные данные события показаны на рисунке 3-7.

Рисунок 3-7. Поддельный родительский процесс в данных события ETW

На рисунке 3-7 выделен идентификатор vmtoolsd.exe, поддельного родительского процесса. Если сопоставить его с заголовком события на рисунке 3-8, становится заметно расхождение.

Рисунок 3-8. Идентификатор создающего процесса, зарегистрированный в заголовке события ETW

Обратите внимание на различие двух идентификаторов процесса. В данных события содержался идентификатор vmtoolsd.exe, тогда как заголовок содержит идентификатор настоящего создателя - ppid-spoof.exe.

Сведения от этого поставщика ETW не столь подробны, как информация, которую предоставил имитируемый драйвер EDR в листинге 3-14. Например, отсутствуют имена образов как родительского, так и создающего процесса. Причина в том, что поставщик ETW, в отличие от драйвера, не получает эти сведения за нас. В реальных условиях, вероятно, понадобилось бы добавить шаг получения информации посредством запроса к процессу или из другого источника данных. Тем не менее этот способ позволяет обнаружить подмену PPID, поскольку у нас есть ключевые сведения, необходимые для стратегии: несовпадающие идентификаторы родительского и создающего процессов.

Во многих случаях вредоносная программа стремится уклониться от обнаружения по образу или от правил, построенных на имени файла, который используется для создания процесса. Добиться этого можно множеством способов, однако один из приёмов, который мы назовём модификацией образа процесса, получил широкое распространение с 2017 года, хотя активные группы угроз применяли его по меньшей мере с 2014 года. Помимо сокрытия выполнения вредоносной программы или инструмента, такой приём может позволить атакующему обойти белые списки приложений, уклониться от правил межсетевого экрана узла для отдельных приложений либо пройти проверку безопасности вызывающего образа перед тем, как сервер разрешит выполнить чувствительную операцию.

В этом разделе рассматриваются четыре способа модификации образа процесса: hollowing, doppelgänging, herpaderping и ghosting. Все они достигают цели приблизительно одинаково - повторно отображают исходный образ процесса-контейнера, заменяя его собственным. Кроме того, все эти способы опираются на одно проектное решение Microsoft, принятое при реализации логики уведомления зарегистрированных процедур обратного вызова о создании процесса.

Это проектное решение заключается в следующем: создание процесса в Windows представляет собой сложную последовательность шагов, многие из которых выполняются до того, как ядро уведомляет драйверы. В результате атакующий получает возможность каким-либо образом изменить атрибуты процесса на этих ранних этапах. Полная последовательность создания процесса, где этап уведомления в оригинале выделен полужирным, выглядит так:

1. Проверить параметры, переданные API создания процесса.

2. Открыть дескриптор целевого образа.

3. Создать объект раздела из целевого образа.

4. Создать и инициализировать объект процесса.

5. Выделить PEB.

6. Создать и инициализировать объект потока.

7. Отправить уведомление о создании процесса зарегистрированным процедурам обратного вызова.

8. Выполнить операции, относящиеся к подсистеме Windows, чтобы завершить инициализацию.

9. Начать выполнение основного потока.

10. Завершить инициализацию процесса.

11. Начать выполнение с точки входа образа.

12. Вернуться к вызывающей стороне API создания процесса.

Описанные в этом разделе способы пользуются шагом 3, на котором ядро создаёт объект раздела из образа процесса. После создания диспетчер памяти кеширует этот раздел образа, а значит, раздел может отличаться от соответствующего целевого образа. Поэтому, когда драйвер получает уведомление от диспетчера процессов ядра, член FileObject обрабатываемой им структуры PS_CREATE_NOTIFY_INFO может не указывать на файл, который выполняется в действительности. Помимо эксплуатации этого обстоятельства, каждый из следующих способов имеет небольшие отличия.

Опустошение процесса (process hollowing) - один из самых старых способов использования модификации раздела, известный по меньшей мере с 2011 года. Поток выполнения этого приёма показан на рисунке 3-9.

Рисунок 3-9. Поток выполнения при опустошении процесса

Применяя этот способ, атакующий создаёт процесс в приостановленном состоянии, находит базовый адрес его образа в PEB и отменяет отображение образа. После этого противник отображает в процесс новый образ, например свой загрузчик шелл-кода, и выравнивает его раздел. В случае успеха выполнение процесса возобновляется.

В докладе «Lost in Transaction: Process Doppelgänging», представленном на Black Hat Europe в 2017 году, Таль Либерман (Tal Liberman) и Юджин Коган (Eugene Kogan) познакомили аудиторию с новым вариантом модификации образа процесса. Их приём, двойничество процесса (process doppelgänging), основан на двух возможностях Windows: транзакционной NTFS (Transactional NTFS, TxF) и устаревшем API создания процессов ntdll!NtCreateProcessEx().

TxF - ныне устаревший способ выполнения действий с файловой системой как единой атомарной операции. Он позволяет коду без труда откатывать изменения файлов, например во время обновления или при возникновении ошибки, и обладает собственным набором вспомогательных API.

Устаревший API создания процессов использовался до выпуска Windows 10, где появился более надёжный ntdll!NtCreateUserProcess(). Хотя для обычного создания процессов он устарел, в Windows 10 вплоть до версии 20H2 его всё ещё можно встретить при создании минимальных процессов. Его заметное преимущество заключается в том, что в качестве образа процесса он принимает дескриптор раздела, а не файл, однако это сопровождается значительными трудностями. Они возникают потому, что многие шаги создания процесса, в том числе запись параметров процесса в адресное пространство нового процесса и создание объекта основного потока, не выполняются автоматически. Чтобы воспользоваться устаревшей функцией создания процесса, разработчик должен воспроизвести отсутствующие шаги в собственном коде и тем самым обеспечить запуск процесса.

Сложный поток двойничества процесса показан на рисунке 3-10.

Рисунок 3-10. Поток выполнения при двойничестве процесса

В своей демонстрации концепции Либерман и Коган сначала создают объект транзакции и открывают целевой файл с помощью kernel32!CreateFileTransacted(). Затем они перезаписывают транзакционный файл вредоносным кодом, создают раздел образа, указывающий на вредоносный код, и откатывают транзакцию посредством kernel32!RollbackTransaction(). К этому моменту исполняемый файл вернулся в исходное состояние, но раздел образа остался закешированным с вредоносным кодом. После этого авторы вызывают ntdll!NtCreateProcessEx(), передавая дескриптор раздела как параметр, и создают основной поток, указывающий на точку входа вредоносного кода. Создав эти объекты, они возобновляют основной поток и тем самым позволяют двойнику процесса выполнить код.

Process herpaderping, изобретённый Джонни Шоу (Johnny Shaw) в 2020 году, использует многие из тех же приёмов, что и двойничество процесса, прежде всего устаревший API создания процессов, который создаёт процесс из объекта раздела. Herpaderping позволяет обойти основанные на образе правила драйвера, но его главная цель - уклониться от обнаружения содержимого записанного на диск исполняемого файла. Принцип работы показан на рисунке 3-11.

Рисунок 3-11. Поток выполнения при process herpaderping

Для выполнения herpaderping атакующий сначала записывает предназначенный для выполнения вредоносный код на диск и создаёт объект раздела, оставляя дескриптор записанного исполняемого файла открытым. Затем он вызывает устаревший API создания процессов, передаёт дескриптор раздела как параметр и создаёт объект процесса. Перед инициализацией процесса противник искажает исходный исполняемый файл на диске через открытый файловый дескриптор и kernel32!WriteFile() либо сходный API. Наконец, он создаёт объект основного потока и выполняет остальные задачи по запуску процесса.

В этот момент процедура обратного вызова драйвера получает уведомление и может просканировать содержимое файла через член FileObject структуры, переданной драйверу при создании процесса. Однако из-за изменения содержимого файла функция сканирования получит фиктивные данные. Кроме того, при закрытии файлового дескриптора всем зарегистрированным мини-фильтрам файловой системы будет отправлен управляющий код ввода-вывода IRP_MJ_CLEANUP. Если мини-фильтр захочет просканировать содержимое файла, его постигнет та же участь, что и драйвер, и результат сканирования может оказаться ложноотрицательным.

Один из новейших вариантов модификации образа процесса - призрачный процесс (process ghosting), представленный Габриэлем Ландау (Gabriel Landau) в июне 2021 года. Этот способ основан на том, что Windows запрещает удаление файлов лишь после их отображения в раздел образа и во время удаления не проверяет, существует ли на самом деле связанный раздел. Если пользователь попытается открыть отображённый исполняемый файл для изменения или удаления, Windows вернёт ошибку. Если же разработчик сначала пометит файл для удаления, а потом создаст из исполняемого файла раздел образа, при закрытии файлового дескриптора файл будет удалён, но объект раздела сохранится. Поток выполнения показан на рисунке 3-12.

Рисунок 3-12. Порядок работы при создании призрачного процесса

Для практической реализации вредоносная программа может создать на диске пустой файл, а затем немедленно перевести его в состояние ожидания удаления через API ntdll!NtSetInformationFile(). Пока файл находится в этом состоянии, вредоносная программа может записать в него полезную нагрузку. Обратите внимание: на этом этапе внешние запросы на открытие файла завершатся ошибкой ERROR_DELETE_PENDING. Далее вредоносная программа создаёт из файла раздел образа и закрывает файловый дескриптор, удаляя файл, но сохраняя раздел образа. Затем она выполняет описанные в предыдущих примерах шаги создания нового процесса из объекта раздела. Когда драйвер получит уведомление о создании процесса и попытается обратиться к лежащему в его основе FILE_OBJECT, то есть структуре, которой Windows представляет файловый объект, он получит ошибку STATUS_FILE_DELETED, не позволяющую исследовать файл.

Вариантов модификации образа процесса кажется бесконечно много, но все их можно выявлять одними и теми же базовыми способами, поскольку приём опирается на две особенности: создание раздела образа, который отличается от заявленного исполняемого файла, будь тот изменён или вовсе отсутствует, и применение устаревшего API создания процессов для создания из раздела образа нового неминимального процесса.

К сожалению, большинство правил для выявления этого приёма являются реактивными, то есть применяются лишь в ходе расследования, либо используют закрытые инструменты. И всё же, сосредоточившись на основах, можно представить несколько возможных способов обнаружения. Чтобы продемонстрировать их, Александра Донец (Aleksandra Doniec, @hasherezade) создала общедоступную демонстрацию концепции призрачного процесса, которую мы можем исследовать в контролируемой среде. Файл proc_ghost64.exe доступен по адресу github.com. Убедитесь, что его хеш SHA-256 совпадает со следующим: 8a74a522e9a91b777080d3cb95d8bbeea84cb71fda487bc3d4489188e3fd6855.

Во-первых, в режиме ядра драйвер может искать сведения, связанные с образом процесса, в PEB либо в соответствующей структуре EPROCESS, представляющей объект процесса в ядре. Поскольку пользователь способен управлять PEB, структура процесса является более надёжным источником. Она содержит сведения об образе процесса в нескольких местах, описанных в таблице 3-1.

Таблица 3-1. Сведения об образе процесса в структуре EPROCESS

Драйверы могут запрашивать эти пути через такие API, как nt!SeLocateProcessImageName() или nt!ZwQueryInformationProcess(), чтобы получить настоящий путь к образу. После этого всё равно требуется определить, был ли процесс изменён. Несмотря на ненадёжность, PEB предоставляет точку для сравнения. Выполним такое сравнение с помощью WinDbg. Сначала попробуем получить путь к файлу образа из одного из полей структуры процесса, как показано в листинге 3-15.

Листинг 3-15. Получение пути к файлу из SeAuditProcessCreationInfo

Любопытно, что WinDbg возвращает в качестве имени образа пустую строку. Это нетипично. Например, в листинге 3-16 возвращается значение, которое ожидается для неизменённого notepad.exe.

Листинг 3-16. Поле UNICODE_STRING, заполненное путём NT к образу

Проверим также другой член структуры процесса - ImageFileName. Он не вернёт полный путь к образу, но всё равно предоставит ценные сведения, как видно в листинге 3-17.

Листинг 3-17. Чтение члена ImageFileName структуры EPROCESS

Полученное имя файла уже должно привлечь внимание: файлы .tmp нечасто бывают исполняемыми. Чтобы определить возможное изменение образа, запросим PEB. Путь к образу возвращается из нескольких мест PEB: ProcessParameters.ImagePathName и Ldr.InMemoryOrderModuleList. Продемонстрируем это в WinDbg, листинг 3-18.

Листинг 3-18. Извлечение пути к образу процесса из ImagePathName

Как показывает вывод WinDbg, PEB сообщает путь к образу процесса C:\Windows\System32\notepad.exe. Проверим его запросом к полю Ldr.InMemoryOrderModuleList, показанному в листинге 3-19.

Листинг 3-19. Извлечение пути к образу процесса из InMemoryOrderModuleList

Здесь видно, что notepad.exe - первый образ в списке модулей 1. По результатам моих испытаний так должно быть всегда. Если EDR обнаружит подобное несовпадение между именем образа в структурах процесса и PEB, она может обоснованно заключить, что произошла модификация образа процесса. Однако определить конкретный способ, использованный атакующим, она не сможет. Для этого потребуется собрать дополнительные сведения.

Сначала EDR может попытаться исследовать файл напрямую, например просканировать его содержимое по указателю, хранящемуся в поле ImageFilePointer структуры процесса. Если вредоносная программа создала процесс, передав объект раздела образа через устаревший API создания процессов, как в демонстрации концепции, этот член окажется пустым, листинг 3-20.

Листинг 3-20. Пустое поле ImageFilePointer

Использование устаревшего API для создания процесса из раздела - важный признак того, что происходит нечто странное. На этом этапе EDR может обоснованно утверждать, что случилось именно это. Для подтверждения предположения EDR также способна проверить, является ли процесс минимальным или пико-процессом, производным от минимального, как показано в листинге 3-21.

Листинг 3-21. Члены Minimal и PicoCreated со значением false

Ещё одно место для поиска аномалий - дерево дескрипторов виртуальных адресов (virtual address descriptor, VAD), предназначенное для отслеживания непрерывных областей виртуальной памяти процесса. Дерево VAD может предоставить весьма полезные сведения о загруженных модулях и правах выделенной памяти. Корень дерева хранится в члене VadRoot структуры процесса. Получить его напрямую через предоставленный Microsoft API невозможно, однако эталонную реализацию можно найти в Blackbone - популярном драйвере для работы с памятью.

Для обнаружения модификации образа процесса, вероятно, следует исследовать типы отображённых областей. К ним относятся отображения файлов READONLY, например файлы каталога COM+ (C:\Windows\Registration\Rxxxxxxx1.clb), и исполняемые файлы EXECUTE_WRITECOPY. В дереве VAD обычно можно увидеть путь к образу процесса с корнем Win32, иными словами исполняемый файл, лежащий в основе процесса, как первый отображённый исполняемый файл. В листинге 3-22 приведён сокращённый вывод команды WinDbg !vad.

Листинг 3-22. Вывод команды !vad в WinDbg для обычного процесса

Вывод инструмента показывает отображённые области неизменённого процесса notepad.exe. Теперь посмотрим, как они выглядят в призрачном процессе, листинг 3-23.

Листинг 3-23. Вывод команды !vad для призрачного процесса

Эта отображённая область содержит путь к файлу .tmp, а не к notepad.exe.

Теперь, когда известен путь к интересующему образу, можно исследовать его дальше. Один из способов - вызвать API ntdll!NtQueryInformationFile() с классом FileStandardInformation, который вернёт структуру FILE_STANDARD_INFORMATION. Она содержит поле DeletePending - логическое значение, показывающее, помечен ли файл для удаления. В обычных обстоятельствах эти сведения также можно получить из члена DeletePending структуры FILE_OBJECT. В структуре EPROCESS соответствующего процесса на неё указывает член ImageFilePointer. У призрачного процесса этот указатель будет нулевым, поэтому EDR не сможет им воспользоваться. В листинге 3-24 показано, как должны выглядеть указатель на файл образа и состояние удаления обычного процесса.

Листинг 3-24. Обычные члены ImageFilePointer и DeletePending

Этот листинг получен из процесса notepad.exe, выполненного в обычных условиях. В призрачном процессе указатель на файл образа имел бы недопустимое значение, поэтому флаг состояния удаления тоже был бы недействительным.

Сопоставив обычный экземпляр notepad.exe с призрачным, мы выявили несколько индикаторов:

• Пути в ImagePathName внутри члена ProcessParameters структуры PEB процесса и в ImageFileName его структуры EPROCESS не будут совпадать.

• Указатель на файл образа в структуре процесса будет нулевым, а поля Minimal и PicoCreated - ложными.

• Имя файла может быть нетипичным, хотя это не обязательное условие и пользователь способен управлять его значением.

Когда драйвер EDR получит от процедуры обратного вызова новую структуру создания процесса, у него будут ключевые сведения для построения правила обнаружения. В частности, в случае призрачного процесса можно применить ImageFileName, FileObject и IsSubsystemProcess, чтобы выявить потенциально призрачные процессы. Возможная логика драйвера показана в листинге 3-25.

Листинг 3-25. Обнаружение призрачных процессов с помощью драйвера

Сначала мы проверяем, является ли файловый указатель нулевым при том, что создаваемый процесс не относится к процессам подсистемы 1. Это означает, что он, вероятно, был создан через устаревший API создания процессов. Далее мы используем две имитируемые вспомогательные функции 2, чтобы получить путь к образу процесса из PEB и преобразовать его в путь NT. Затем повторяем процедуру с именем файла образа из структуры вновь созданного процесса 3. После этого сравниваем пути к образу из PEB и структуры процесса. Если они не равны, то, вероятно, найден подозрительный процесс и EDR пора принимать меры.

Со временем изменения в методах злоумышленников повлияли на то, насколько важным поставщики EDR считают обнаружение подозрительных событий создания процессов. Получив доступ к целевой системе, атакующие могут использовать любое число командно-управляющих агентов для действий после первоначального проникновения. Разработчики каждого вредоносного агента должны решить, как обрабатывать обмен данными с агентом, чтобы выполнять команды в заражённой системе. Эту задачу можно решить множеством способов, но самая распространённая архитектура называется fork&run.

Мониторинг создания новых процессов и потоков - чрезвычайно важная возможность любой EDR. Он позволяет строить карту связей родительских и дочерних процессов, исследовать подозрительные процессы до начала их выполнения и выявлять создание удалённых потоков. Хотя Windows предоставляет и другие способы получения этих сведений, чаще всего применяются процедуры обратного вызова для создания процессов и потоков в драйвере EDR. Они дают обширное представление о действиях в системе, и обойти их трудно: приходится полагаться на пробелы в покрытии и слепые зоны, а не на фундаментальные недостатки лежащей в основе технологии.

Как и для всех остальных видов уведомлений, EDR может зарегистрировать процедуру обратного вызова для объектов одной функцией - в данном случае nt!ObRegisterCallbacks(). Рассмотрим эту функцию, разберёмся в принципе её работы, а затем попрактикуемся в реализации процедуры обратного вызова для объектов.

На первый взгляд функция регистрации проста и требует лишь два указателя в качестве параметров: CallbackRegistration, задающий саму процедуру обратного вызова и другие регистрационные сведения, и RegistrationHandle, получающий значение, которое передаётся, когда драйвер хочет отменить регистрацию процедуры.

Несмотря на простое определение функции, структура, передаваемая через параметр CallbackRegistration, совсем не проста. Её определение приведено в листинге 4-1.

Листинг 4-1. Определение структуры OB_CALLBACK_REGISTRATION

Некоторые из этих значений довольно понятны. Версия регистрации процедуры обратного вызова для объектов всегда равна OB_FLT_REGISTRATION_VERSION (0x0100). Член OperationRegistrationCount содержит число структур регистрации процедур, переданных в члене OperationRegistration, а RegistrationContext - некоторое значение, которое без изменений передаётся процедурам обратного вызова при каждом их вызове и чаще всего устанавливается в null.

Член Altitude - строка, определяющая порядок вызова процедур обратного вызова. Предоперационная процедура с большей высотой выполняется раньше, а послеоперационная процедура с большей высотой - позже. Этому члену можно присвоить любое значение, если его ещё не используют процедуры другого драйвера. К счастью, Microsoft разрешает применять десятичные дроби, а не только целые числа, что снижает общую вероятность столкновения высот.

Центральную роль в этой функции регистрации играет параметр OperationRegistration и массив регистрационных структур, на который он указывает. Определение такой структуры показано в листинге 4-2. Каждая структура массива указывает, регистрирует ли функция предоперационную или послеоперационную процедуру обратного вызова.

Листинг 4-2. Определение структуры OB_OPERATION_REGISTRATION

Каждый член и его назначение описаны в таблице 4-1. Если вам интересно, что именно отслеживает драйвер, эти структуры содержат основную часть нужной информации.

Таблица 4-1. Члены структуры OB_OPERATION_REGISTRATION

Мы подробнее обсудим эти члены в разделе «Определение действий драйвера после срабатывания» на странице 66 оригинала.

EDR часто реализуют предоперационные процедуры обратного вызова для отслеживания запросов новых и дублированных дескрипторов процессов. Мониторинг запросов дескрипторов потоков и рабочих столов тоже может быть полезен, но атакующие чаще запрашивают дескрипторы процессов, поэтому обычно именно они дают более существенную информацию. В листинге 4-3 показано, как EDR может реализовать такую процедуру в драйвере.

Листинг 4-3. Регистрация предоперационной процедуры обратного вызова для уведомлений

В этом примере драйвера мы начинаем с заполнения регистрационной структуры процедуры обратного вызова. Два наиболее важных члена - OperationRegistrationCount, которому присваивается значение 1, показывающее, что регистрируется только одна процедура обратного вызова 1, и высота, для которой выбирается произвольное значение 2, чтобы избежать столкновений с процедурами других драйверов.

Далее мы настраиваем структуру регистрации операции. Члену ObjectType присваивается PsProcessType 3, а члену Operations - значения, указывающие, что нас интересует мониторинг операций с новыми или дублированными дескрипторами процессов 4. Наконец, в члене PreOperation задаётся указатель на внутреннюю функцию обратного вызова 5.

В завершение мы связываем структуру регистрации операции с регистрационной структурой процедуры обратного вызова, передавая указатель на неё в члене OperationRegistration 6. Теперь можно вызвать функцию регистрации 7. После завершения функции наша процедура обратного вызова начнёт получать события, а мы получим значение, которое можно передать функции регистрации, чтобы отменить регистрацию процедуры.

Как определить, какие объекты отслеживает EDR? Как и для других видов уведомлений, при вызове функции регистрации система добавляет процедуру обратного вызова в массив процедур. Однако у обратных вызовов для объектов этот массив устроен не так просто, как другие.

Помните указатели, которые мы передали в структуру регистрации операции, чтобы сообщить, какой тип объектов хотим отслеживать? До сих пор в книге нам главным образом встречались указатели на структуры, но эти указатели вместо этого ссылаются на значения перечисления. Рассмотрим nt!PsProcessType и выясним, что происходит. Типы объектов вроде nt!PsProcessType в действительности являются структурами OBJECT_TYPE. В листинге 4-4 показано, как они выглядят в работающей системе при просмотре в отладчике WinDbg.

Листинг 4-4. Структура nt!_OBJECT_TYPE, на которую указывает nt!PsProcessType

Особенно интересен член CallbackList со смещением 0x0c8: он указывает на структуру LIST_ENTRY, которая служит точкой входа, или заголовком, двусвязного списка процедур обратного вызова, связанных с типом объекта процесса. Каждая запись списка указывает на недокументированную структуру CALLBACK_ENTRY_ITEM. Её определение приведено в листинге 4-5.

Листинг 4-5. Определение структуры CALLBACK_ENTRY_ITEM

Член PreOperation этой структуры находится по смещению 0x028. Если пройти связный список процедур обратного вызова и получить символ по адресу, на который указывает этот член в каждой структуре, можно перечислить драйверы, отслеживающие операции с дескрипторами процессов. И снова на помощь приходит WinDbg: он поддерживает сценарии, позволяющие сделать именно это, как показано в листинге 4-6.

Листинг 4-6. Перечисление предоперационных процедур обратного вызова для операций с дескрипторами процессов

По существу, эта команда отладчика означает: «Пройди связный список, начинающийся по адресу, на который указывает член CallbackList структуры nt!_OBJECT_TYPE для nt!PsProcessType, и выведи сведения о модуле, если адрес, на который указывает член PreOperation, не является нулевым».

В моей тестовой системе WdFilter.sys Защитника 1 - единственный драйвер с зарегистрированной процедурой обратного вызова. В настоящей системе с развёрнутой EDR рядом с Защитником почти наверняка будет зарегистрирован драйвер EDR. Тем же способом можно перечислить процедуры, отслеживающие операции с дескрипторами потоков или рабочих столов, но они обычно встречаются значительно реже. Кроме того, если Microsoft добавит возможность регистрировать процедуры для операций с дескрипторами других видов объектов, например токенов, этот способ позволит перечислить и их.

Полезно знать, какие типы объектов интересуют EDR, но наиболее ценная информация - что именно делает драйвер после срабатывания. EDR способна выполнять множество действий: от незаметного наблюдения за работой кода до активного вмешательства в запросы. Чтобы понять возможные действия драйвера, сначала нужно рассмотреть данные, с которыми он работает.

Когда некоторая операция с дескриптором вызывает зарегистрированную процедуру, та получает указатель либо на структуру OB_PRE_OPERATION_INFORMATION, если процедура предоперационная, либо на OB_POST_OPERATION_INFORMATION, если она послеоперационная. Эти структуры очень похожи, однако послеоперационная версия содержит только код возврата операции с дескриптором, и её данные нельзя изменить. Предоперационные процедуры встречаются намного чаще, поскольку позволяют драйверу перехватить и изменить операцию с дескриптором. Поэтому мы сосредоточимся на предоперационной структуре, показанной в листинге 4-7.

Листинг 4-7. Определение структуры OB_PRE_OPERATION_INFORMATION

Как и при регистрации процедуры, разбор данных уведомления немного сложнее, чем кажется. Последовательно рассмотрим важные части. Сначала дескриптор Operation показывает, выполняется ли создание нового дескриптора или дублирование существующего. Разработчик EDR может использовать его, чтобы выбирать разные действия в зависимости от вида обрабатываемой операции. Кроме того, если значение KernelHandle не равно нулю, дескриптор является дескриптором ядра, и функция обратного вызова редко будет его обрабатывать. Это позволяет EDR ещё сильнее сократить круг событий, которые требуется отслеживать для эффективного покрытия.

Указатель Object ссылается на цель операции с дескриптором. Драйвер может воспользоваться им для дальнейшего изучения цели, например чтобы получить сведения о её процессе. Указатель ObjectType показывает, направлена ли операция на процесс или поток, а Parameters ссылается на структуру, указывающую вид обрабатываемой операции: создание или дублирование дескриптора.

Для фильтрации операции драйвер использует почти всё, что находится в структуре до члена Parameters. Когда тип объекта и виды обрабатываемых операций известны, дополнительные проверки обычно ограничиваются определением того, является ли дескриптор дескриптором ядра. Настоящая магия начинается при обработке структуры, на которую указывает Parameters. Если операция создаёт новый дескриптор, мы получаем указатель на структуру из листинга 4-8.

Листинг 4-8. Определение структуры OB_PRE_CREATE_HANDLE_INFORMATION

Оба значения ACCESS_MASK задают права доступа, которые следует предоставить дескриптору. Это могут быть такие значения, как PROCESS_VM_OPERATION или THREAD_SET_THREAD_TOKEN, передаваемые функциям в параметре dwDesiredAccess при открытии процесса или потока.

Возможно, вы задаётесь вопросом, почему структура содержит две копии одного значения. Причина в том, что предоперационные уведомления позволяют драйверу изменять запросы. Допустим, драйвер хочет запретить процессам читать память lsass.exe. Сначала атакующему потребуется открыть дескриптор с соответствующими правами, поэтому он может запросить PROCESS_ALL_ACCESS. Драйвер получит уведомление о новом дескрипторе процесса и увидит запрошенную маску доступа в члене OriginalDesiredAccess. Чтобы запретить доступ, он может удалить PROCESS_VM_READ, инвертировав связанный с этим правом бит в члене DesiredAccess оператором побитового дополнения (~). Инвертирование бита не даёт дескриптору получить именно это право, но сохраняет все остальные запрошенные права.

Если операция дублирует существующий дескриптор, мы получим указатель на структуру из листинга 4-9, содержащую два дополнительных указателя.

Листинг 4-9. Определение структуры OB_PRE_DUPLICATE_HANDLE_INFORMATION

Член SourceProcess - указатель на объект процесса, из которого происходит дескриптор, а TargetProcess - указатель на процесс, получающий дескриптор. Они соответствуют параметрам hSourceProcessHandle и hTargetProcessHandle, передаваемым функции ядра для дублирования дескрипторов.

Бесспорно, один из процессов, на которые атакующие нацеливаются чаще всего, - lsass.exe, отвечающий за аутентификацию в пользовательском режиме. Его адресное пространство может содержать открытые учётные данные, которые злоумышленники способны извлечь с помощью таких инструментов, как Mimikatz, ProcDump и даже диспетчер задач.

Поскольку lsass.exe подвергается столь многочисленным атакам, поставщики средств безопасности вложили значительное время и усилия в выявление злоупотреблений этим процессом. Одним из самых надёжных источников данных для этой цели служат уведомления процедур обратного вызова для объектов. Чтобы определить вредоносность действия, многие EDR используют три элемента информации, которые передаются процедуре при каждом запросе нового дескриптора процесса: процесс-источник запроса, процесс, для которого запрашивается дескриптор, и маску доступа, то есть права, запрошенные вызывающим процессом.

Например, когда оператор запрашивает новый дескриптор процесса lsass.exe, драйвер EDR определяет вызывающий процесс и проверяет, является ли целью lsass.exe. Если да, он может оценить запрошенные права доступа и проверить наличие PROCESS_VM_READ, необходимого для чтения памяти процесса. Затем, если запрашивающий процесс не входит в список процессов, которым разрешён доступ к lsass.exe, драйвер может вернуть недопустимый дескриптор или дескриптор с изменённой маской доступа и уведомить агента о потенциально вредоносном поведении.

Примечание. Иногда защитники могут определить конкретный инструмент атакующего по запрошенным маскам доступа. Многие наступательные инструменты при открытии дескрипторов процессов запрашивают избыточные маски, например PROCESS_ALL_ACCESS, или нетипичные, например сочетание PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION, запрашиваемое Mimikatz.

Итак, стратегия обнаружения EDR опирается на три предположения: вызывающий процесс откроет новый дескриптор lsass.exe, этот процесс будет нетипичным, а запрошенная маска доступа позволит ему читать память lsass.exe. Атакующие могут воспользоваться этими предположениями, чтобы обойти логику обнаружения агента.

Один из способов уклонения состоит в том, чтобы продублировать принадлежащий другому процессу дескриптор lsass.exe. Найти такие дескрипторы можно через API ntdll!NtQuerySystemInformation(), который предоставляет чрезвычайно полезную возможность: непривилегированный пользователь может просмотреть системную таблицу дескрипторов. В ней перечислены все открытые в системе дескрипторы, включая такие объекты, как мьютексы, файлы и, что важнее всего, процессы. В листинге 4-10 показано, как вредоносная программа может запросить этот API.

Листинг 4-10. Получение таблицы дескрипторов

Передав этой функции класс сведений SystemHandleInformation 1, пользователь может получить массив со всеми активными дескрипторами системы. После завершения функция сохраняет массив в переменной-члене структуры SYSTEM_HANDLE_INFORMATION 2.

Далее вредоносная программа может перебрать массив дескрипторов, как показано в листинге 4-11, и отфильтровать непригодные.

Листинг 4-11. Фильтрация только дескрипторов процессов

Сначала мы убеждаемся, что дескриптор не принадлежит ни lsass.exe, ни системному процессу 1, поскольку это могло бы запустить некоторую логику оповещения. Затем вызывается ntdll!NtQueryObject() с аргументом ObjectTypeInformation 2, чтобы получить тип объекта, которому принадлежит дескриптор. После этого мы определяем, относится ли дескриптор к объекту процесса 3, и тем самым исключаем все остальные типы, например файлы и мьютексы.

Закончив базовую фильтрацию, необходимо исследовать дескрипторы подробнее и убедиться, что они обладают правами доступа, нужными для выгрузки памяти процесса. Листинг 4-12 продолжает код предыдущего листинга.

Листинг 4-12. Оценка дублированных дескрипторов и выгрузка памяти

Сначала мы получаем имя образа процесса 1 и передаём его внутренней функции IsLsassHandle(), которая проверяет, относится ли дескриптор процесса к lsass.exe. Затем проверяются права доступа дескриптора: нам нужны PROCESS_VM_READ и PROCESS_QUERY_INFORMATION, поскольку они требуются API, который будет читать память процесса lsass.exe. Если найден существующий дескриптор lsass.exe с нужными правами, мы передаём дубликат API и извлекаем сведения 2.

С помощью нового дескриптора можно создать дамп памяти lsass.exe и обработать его таким инструментом, как Mimikatz. Этот порядок действий показан в листинге 4-13.

Листинг 4-13. Выгрузка памяти lsass.exe и обработка мини-дампа с помощью Mimikatz

Как видно, наш инструмент определяет, что PID 17600, соответствующий Process Explorer на моей тестовой машине, обладает дескриптором lsass.exe с маской доступа PROCESS_ALL_ACCESS (0x1FFFFF). Мы используем этот дескриптор, чтобы выгрузить память в файл C:\lsa.dmp. Затем запускаем Mimikatz, обрабатываем файл и командой sekurlsa::logonpasswords извлекаем материалы учётных данных. Обратите внимание: для снижения риска обнаружения эти действия Mimikatz можно выполнить за пределами целевой системы, поскольку мы работаем с файлом, а не с живой памятью.

Хотя такой приём позволяет обойти некоторые датчики, EDR всё ещё способна выявить наше поведение множеством способов. Помните, что процедуры обратного вызова для объектов могут получать уведомления о запросах дублирования. Возможная логика обнаружения в драйвере EDR показана в листинге 4-14.

Листинг 4-14. Фильтрация событий дублирования дескрипторов по имени целевого процесса

Чтобы выявлять запросы дублирования, EDR может определить, равен ли член ObjectType структуры OB_PRE_OPERATION_INFORMATION, передаваемой процедуре обратного вызова, значению PsProcessType, и, если да, равен ли её член Operation значению OB_OPERATION_HANDLE_DUPLICATE 1. С помощью дополнительной фильтрации можно установить, не наблюдаем ли мы описанный выше приём. Затем можно сравнить имя целевого процесса с именем одного чувствительного процесса или их списка 2.

Драйвер с такой проверкой обнаружит дублирование дескриптора процесса, выполненное посредством kernel32!DuplicateHandle(). На рисунке 4-1 показана имитация EDR, сообщающая об этом событии.

Рисунок 4-1. Обнаружение дублирования дескриптора процесса

К сожалению, на момент написания книги многие датчики проверяют лишь запросы новых дескрипторов, но не запросы дублирования. В будущем это может измениться, поэтому всегда выясняйте, выполняет ли такую проверку драйвер конкретной EDR.

В работе 2020 года «Fast and Furious: Outrunning Windows Kernel Notification Routines from User-Mode» Пьер Сихолас (Pierre Ciholas), Хосе Мигель Суч (Jose Miguel Such), Ангелос К. Марнеридес (Angelos K. Marnerides), Бенджамин Грин (Benjamin Green), Цзяцзе Чжан (Jiajie Zhang) и Уц Рёдиг (Utz Roedig) продемонстрировали новый способ уклонения от обнаружения процедурами обратного вызова для объектов. Их приём запрашивает дескриптор процесса до того, как выполнение будет передано процедуре обратного вызова драйвера. Авторы описали два разных способа опередить процедуры; они рассматриваются в следующих разделах.

Первый способ работает, когда атакующему требуется получить доступ к процессу с известным родителем. Например, если пользователь дважды щёлкает приложение в графическом интерфейсе Windows, его родительским процессом должен быть explorer.exe. В таких случаях атакующий точно знает родителя целевого процесса, что позволяет с помощью некоторых особенностей Windows, которые мы вскоре обсудим, открыть дескриптор целевого дочернего процесса до того, как драйвер успеет отреагировать. Этот приём показан в листинге 4-15.

Листинг 4-15. Настройка объекта задания и порта завершения ввода-вывода для последующего запроса

Чтобы получить дескриптор защищённого процесса, оператор создаёт объект задания для известного родителя 1. В результате процесс, назначивший объект задания, будет получать уведомления обо всех новых дочерних процессах через порт завершения ввода-вывода 2. Затем процесс вредоносной программы должен как можно быстрее опрашивать этот порт. В нашем примере этим занимается внутренняя функция GetChildHandles() 3, раскрытая в листинге 4-16.

Листинг 4-16. Открытие дескрипторов новых процессов

В этой функции сначала проверяется порт завершения ввода-вывода в цикле do...while 3. Если мы видим, что в рамках завершённой операции переданы байты, то открываем новый дескриптор возвращённого PID 1, запрашивая полные права, то есть PROCESS_ALL_ACCESS. Получив дескриптор, мы проверяем имя его образа 2. Настоящая вредоносная программа сделала бы с дескриптором что-нибудь полезное, например прочитала память процесса или завершила его, но здесь вместо этого выводятся лишь некоторые сведения.

Приём работает потому, что уведомление объекта задания возникает в ядре раньше уведомления процедуры обратного вызова для объектов. В своей работе исследователи измерили время между созданием процесса и уведомлением процедуры: оно составило 8,75-14,5 мс. Это означает, что, если запросить дескриптор до передачи уведомления драйверу, атакующий сможет получить дескриптор со всеми правами, а не с маской доступа, изменённой драйвером.

Второй описанный в работе способ пытается предсказать PID целевого процесса. Авторы показали, что, удалив все известные PID и идентификаторы потоков (TID) из перечня возможных PID, можно эффективнее угадать PID цели. Для демонстрации они создали программу hThemAll.cpp. В основе инструмента лежит внутренняя функция OpenProcessThemAll(), показанная в листинге 4-17; программа выполняет её в четырёх параллельных потоках для открытия дескрипторов процессов.

Листинг 4-17. Функция OpenProcessThemAll(), запрашивающая дескрипторы процессов и проверяющая их PID

Функция без разбора запрашивает дескрипторы 1 всех процессов по PID из отфильтрованного списка. Если возвращённый дескриптор действителен, он добавляется в массив 2. После завершения функции можно проверить, соответствует ли какой-либо полученный дескриптор целевому процессу. Если нет, дескриптор закрывается.

Хотя демонстрация концепции работает, она не учитывает некоторые граничные случаи, например повторное использование идентификаторов завершившегося процесса или потока другим процессом либо потоком. Такие случаи, безусловно, можно учесть, но на момент написания книги общедоступных примеров не существовало.

Практические области применения обоих способов также могут быть ограничены. Например, чтобы первым способом открыть дескриптор процесса агента, нам пришлось бы выполнить свой код раньше запуска этого процесса. В реальной системе это чрезвычайно сложно, поскольку большинство EDR запускает процесс агента через службу, которая работает на раннем этапе порядка загрузки. Для создания собственной службы потребуются административные права, но даже они не гарантируют, что вредоносная программа начнёт выполняться до запуска службы агента.

Кроме того, оба способа направлены на преодоление превентивных мер EDR и не учитывают средства обнаружения. Даже если драйвер не сможет изменить права запрошенного дескриптора, он всё равно может сообщить о подозрительных событиях доступа к процессу. Microsoft заявила, что не станет исправлять эту проблему, поскольку это может вызвать затруднения с совместимостью приложений; ответственность за устранение возложена на сторонних разработчиков.

Мониторинг операций с дескрипторами, особенно открытия дескрипторов чувствительных процессов, предоставляет надёжный способ обнаружения методов противника. Драйвер с зарегистрированной процедурой обратного вызова для уведомлений об объектах располагается непосредственно на пути атакующего, чьи приёмы требуют открытия или дублирования дескрипторов таких объектов, как lsass.exe. При качественной реализации процедуры возможности обхода этого датчика ограничены, и многие атакующие изменили свои методы так, чтобы вообще свести к минимуму необходимость открывать новые дескрипторы процессов.

Можно предположить, что лучший способ обнаруживать вредоносный трафик - использовать сетевое устройство безопасности, однако это не всегда так. Эффективность таких сетевых устройств зависит от их положения в сети. Например, чтобы обнаруживать горизонтальное перемещение между узлами A и B, система обнаружения сетевых вторжений (NIDS) должна располагаться между ними.

Представьте, что противнику необходимо пересечь основные границы сети, например перейти из подсети VPN в подсеть центра обработки данных. В таких ситуациях инженеры безопасности могут стратегически разместить устройство в логической точке сужения, через которую должен проходить весь такой трафик. Эта ориентированная на границы архитектура будет похожа на показанную на рисунке 7-1.

Рисунок 7-1. NIDS между двумя сетями

Но как быть с горизонтальным перемещением внутри одной подсети, например с рабочей станции на рабочую станцию? Размещать устройство сетевого мониторинга между каждой парой узлов локальной сети было бы экономически нецелесообразно, однако командам безопасности всё равно нужна такая телеметрия для обнаружения действий противника в своих сетях.

Здесь вступает в действие датчик мониторинга трафика на конечном устройстве. Развернув датчик мониторинга на каждом клиенте, команда безопасности решает проблему выбора места в сети для своего устройства. В конце концов, если датчик отслеживает трафик на клиенте, как показано на рисунке 7-2, он фактически оказывается посредником между клиентом и всеми остальными системами, с которыми тот может обмениваться данными.

Рисунок 7-2. Сетевой мониторинг на конечных устройствах

У мониторинга на конечном устройстве есть ещё одно ценное преимущество перед сетевыми решениями: контекст. Поскольку работающий на конечном устройстве агент может собирать дополнительные сведения об узле, он способен составить более полную картину того, как и почему возник сетевой трафик. Например, он может определить, что дочерний процесс outlook.exe с определённым PID каждые 60 секунд обращается к конечной точке сети доставки содержимого; это может быть маяк управления и контроля от процесса, связанного с первоначальным доступом.

Датчик на узле может получить данные об исходном процессе, контексте пользователя и действиях, происходивших до установления соединения. Напротив, развёрнутое в сети устройство сможет видеть лишь характеристики соединения, например его источник и назначение, частоту пакетов и протокол. Хотя эти данные могут быть ценны для специалистов по реагированию, в них отсутствуют ключевые сведения, которые помогли бы расследованию.

Существует множество типов сетевых драйверов, большинство из которых основано на Network Driver Interface Specification (NDIS). NDIS - библиотека, абстрагирующая сетевое оборудование устройства. Она также определяет стандартный интерфейс между многоуровневыми сетевыми драйверами, работающими на разных сетевых уровнях и уровнях операционной системы, и хранит сведения о состоянии. NDIS поддерживает четыре типа драйверов.

Miniport. Управляет платой сетевого интерфейса, например отправляет и принимает данные. Это самый нижний уровень драйверов NDIS.

Protocol. Реализует стек транспортного протокола, например TCP/IP. Это самый верхний уровень драйверов NDIS.

Filter. Располагается между драйверами мини-порта и протокола, отслеживая и изменяя взаимодействие между этими двумя подтипами.

Intermediate. Располагается между драйверами мини-порта и протокола, предоставляя точки входа обоих драйверов для передачи запросов. Такие драйверы предоставляют виртуальный адаптер, которому драйвер протокола отправляет свои пакеты. Затем промежуточный драйвер направляет эти пакеты соответствующему мини-порту. После завершения операции мини-портом промежуточный драйвер передаёт сведения обратно драйверу протокола. Такие драйверы часто используются для балансировки трафика между несколькими платами сетевого интерфейса.

Взаимодействие этих драйверов с NDIS показано на сильно упрощённой схеме на рисунке 7-3.

Рисунок 7-3. Отношения драйверов NDIS

Для мониторинга безопасности лучше всего подходят драйверы фильтров, поскольку они могут перехватывать сетевой трафик на самых нижних уровнях сетевого стека непосредственно перед его передачей мини-порту и связанной плате сетевого интерфейса. Однако такие драйверы создают некоторые сложности, в том числе значительную сложность кода, ограниченную поддержку сетевого и транспортного уровней и трудный процесс установки.

Но, возможно, самая большая проблема драйверов фильтров для мониторинга безопасности - отсутствие контекста. Хотя они могут перехватывать обрабатываемый трафик, им неизвестен контекст вызывающей стороны, то есть процесс, инициировавший запрос, и у них нет метаданных, необходимых для предоставления агенту EDR ценной телеметрии. Поэтому EDR почти всегда используют другую платформу: Windows Filtering Platform (WFP).

WFP - это набор API и служб для создания приложений сетевой фильтрации, включающий компоненты как пользовательского режима, так и режима ядра. Начиная с Windows Vista и Server 2008, он предназначался для замены устаревших технологий фильтрации, включая фильтры NDIS. Хотя у WFP есть некоторые недостатки в отношении производительности сети, он обычно считается лучшим вариантом для создания драйверов фильтров. Даже сам брандмауэр Windows построен на WFP.

Платформа предоставляет множество преимуществ. Она позволяет EDR фильтровать трафик, относящийся к конкретным приложениям, пользователям, соединениям, платам сетевого интерфейса и портам. Она поддерживает как IPv4, так и IPv6, обеспечивает защиту во время загрузки до запуска базового механизма фильтрации и позволяет драйверам фильтровать, изменять и повторно внедрять трафик. Платформа также может обрабатывать пакеты IPsec до и после расшифрования и интегрируется с аппаратной разгрузкой, позволяя драйверам фильтров использовать оборудование для проверки пакетов.

Реализацию WFP бывает трудно понять: у неё сложная архитектура и особые названия основных компонентов, распределённых между пользовательским режимом и режимом ядра. Архитектура WFP выглядит примерно так, как показано на рисунке 7-4.

Рисунок 7-4. Архитектура WFP

Чтобы разобраться во всём этом, проследим за частью TCP-потока от клиента, подключённого к серверу в интернете. Сначала клиент вызывает функцию вроде WS2_32!send() или WS2_32!WSASend(), чтобы отправить данные через подключённый сокет. В конечном итоге эти функции передают пакет вниз сетевому стеку, который предоставляется tcpip.sys для IPv4 и tcpip6.sys для IPv6.

По мере прохождения пакета через сетевой стек он передаётся прокладке, связанной с соответствующим уровнем стека, например с потоковым уровнем. Прокладки - компоненты ядра, выполняющие несколько критически важных задач. Одна из первых их обязанностей - извлечь данные и свойства из пакета и передать их механизму фильтрации, запуская процесс применения фильтров.

Механизм фильтрации, иногда называемый общим механизмом фильтрации во избежание путаницы с базовым механизмом фильтрации пользовательского режима, выполняет фильтрацию на сетевом и транспортном уровнях. В нём есть собственные уровни - контейнеры, используемые для организации фильтров в наборы. Каждый из этих уровней, внутренне определённый как GUID, имеет схему, указывающую, какие типы фильтров в него можно добавлять. Уровни могут дополнительно делиться на подуровни, управляющие конфликтами фильтрации. Например, представьте, что на одном узле настроены правила «открыть порт 1028» и «заблокировать все порты выше 1024». Все уровни наследуют подуровни по умолчанию, а разработчики могут добавлять собственные.

Вам может быть интересно, как механизм фильтрации определяет порядок оценки подуровней и фильтров. Если бы правила применялись к трафику в случайном порядке, это могло бы привести к огромным проблемам. Например, первым правилом мог бы оказаться запрет по умолчанию, отбрасывающий весь трафик. Чтобы решить эту проблему, и подуровням, и фильтрам можно назначить значение приоритета, называемое весом, которое определяет порядок их обработки диспетчером фильтров. Эта логика упорядочивания называется арбитражем фильтров.

Во время арбитража фильтры оценивают разобранные из пакета данные от наибольшего приоритета к наименьшему, чтобы определить, что делать с пакетом. Каждый фильтр содержит условия и действие, как обычные правила брандмауэра, например «если порт назначения равен 4444, заблокировать пакет» или «если приложение - edge.exe, разрешить пакет». Основные действия, которые может вернуть фильтр, - Block и Permit, но ещё три поддерживаемых действия передают сведения о пакете драйверам выносных функций: FWP_ACTION_CALLOUT_TERMINATING, FWP_ACTION_CALLOUT_INSPECTION и FWP_ACTION_CALLOUT_UNKNOWN.

Драйверы выносных функций - сторонние драйверы, расширяющие возможности фильтрации WFP по сравнению с базовыми фильтрами. Они предоставляют расширенные функции, например глубокую проверку пакетов, родительский контроль и журналирование данных. Когда поставщик EDR заинтересован в сборе сетевого трафика, он обычно развёртывает в системе драйвер выносной функции.

Подобно базовым фильтрам, драйверы выносных функций могут выбирать интересующие их типы трафика. Когда вызываются драйверы выносных функций, связанные с конкретной операцией, они могут предложить действие над пакетом на основе собственной внутренней логики обработки. Драйвер выносной функции может разрешить некоторый трафик, заблокировать его, продолжить обработку, то есть передать другим драйверам выносных функций, отложить, отбросить или ничего не делать. Эти действия являются лишь предложениями, и драйвер может переопределить их в процессе арбитража фильтров.

Когда арбитраж фильтров завершается, результат возвращается прокладке, которая исполняет окончательное решение фильтрации, например разрешает пакету покинуть узел.

Когда продукт EDR хочет перехватывать и обрабатывать сетевой трафик на узле, он, скорее всего, использует драйвер выносной функции WFP. Чтобы настроить свою выносную функцию, такие драйверы должны выполнить довольно сложную последовательность действий, но она станет понятной, если учесть, как пакеты проходят через сетевой стек и диспетчер фильтров. Кроме того, с такими драйверами значительно проще работать, чем с их устаревшими аналогами NDIS, а документация Microsoft должна быть очень полезна разработчикам EDR, желающим добавить эту возможность в набор своих датчиков.

Подобно другим типам драйверов, драйверы выносных функций WFP начинают инициализацию внутри своей внутренней функции DriverEntry(). Одно из первых выполняемых драйвером действий, уникальное для WFP, - открытие сеанса с механизмом фильтрации. Для этого драйвер вызывает fltmgr!FwpmEngineOpen(), определённую в листинге 7-1.

Листинг 7-1. Определение функции fltmgr!FwpmEngineOpen()

Самый примечательный входной аргумент этой функции - authnService, определяющий используемую службу аутентификации. Он может иметь значение RPC_C_AUTHN_WINNT или RPC_C_AUTHN_DEFAULT, каждое из которых фактически просто предписывает драйверу использовать аутентификацию NTLM. При успешном завершении функции через параметр engineHandle возвращается дескриптор механизма фильтрации, который обычно сохраняется в глобальной переменной, поскольку понадобится драйверу во время выгрузки.

Затем драйвер регистрирует свои выносные функции. Для этого вызывается API fltmgr!FwpmCalloutRegister(). В системах Windows 8 и более поздних эта функция преобразуется в fltmgr!FwpsCalloutRegister2(), определение которой приведено в листинге 7-2.

Листинг 7-2. Определение функции fltmgr!FwpsCalloutRegister2()

Передаваемый этой функции как параметр callout входной указатель на структуру FWPS_CALLOUT2 содержит сведения о внутренних функциях драйвера выносной функции, которые будут обрабатывать фильтрацию пакетов. Структура определена в листинге 7-3.

Листинг 7-3. Определение структуры FWPS_CALLOUT2

Элементы notifyFn и flowDeleteFn - функции выносной функции, которые уведомляют драйвер соответственно о наличии относящихся к самой выносной функции сведений для передачи или о завершении данных, обрабатываемых выносной функцией. Поскольку эти функции не особенно важны для обнаружения, мы не будем рассматривать их подробнее. Однако элемент classifyFn - указатель на функцию, вызываемую всякий раз, когда требуется обработать пакет; в ней содержится основная часть логики проверки. Мы рассмотрим эти выносные функции в разделе «Обнаружение приёмов противника с помощью сетевых фильтров» на странице 135.

Определив выносную функцию, можно добавить её в механизм фильтрации вызовом fwpuclnt!FwpmCalloutAdd(), передав в качестве входных данных полученный ранее дескриптор механизма и указатель на структуру FWPM_CALLOUT, показанную в листинге 7-4.

Листинг 7-4. Определение структуры FWPM_CALLOUT

Эта структура содержит данные о выносной функции, например необязательные понятное имя и описание в элементе displayData, а также уровни, которым следует назначить выносную функцию, например FWPM_LAYER_STREAM_V4 для потоков IPv4. Microsoft документирует десятки идентификаторов уровней фильтрации, и у каждого обычно есть варианты для IPv4 и IPv6. Когда используемая драйвером функция добавления выносной функции завершается, она возвращает идентификатор времени выполнения выносной функции, который сохраняется для использования при выгрузке.

В отличие от уровней фильтрации, разработчик может добавлять в систему собственные подуровни. В таких случаях драйвер вызывает fwpuclnt!FwpmSublayerAdd(), которая принимает дескриптор механизма, указатель на структуру FWPM_SUBLAYER и необязательный дескриптор безопасности. Передаваемая на вход структура содержит ключ подуровня, GUID для однозначной идентификации подуровня, необязательные понятное имя и описание, необязательный флаг сохранения подуровня между перезагрузками, вес подуровня и другие элементы с относящимся к подуровню состоянием.

Последнее действие драйвера выносной функции - добавление в систему нового объекта фильтра. Этот объект фильтра является правилом, которое драйвер будет оценивать при обработке соединения. Для его создания драйвер вызывает fwpuclnt!FwpmFilterAdd(), передавая дескриптор механизма, указатель на структуру FWPM_FILTER, показанную в листинге 7-5, и необязательный указатель на дескриптор безопасности.

Листинг 7-5. Определение структуры FWPM_FILTER

В структуре FWPM_FILTER стоит выделить несколько ключевых элементов. Элемент flags содержит несколько флагов, описывающих атрибуты фильтра, например должен ли фильтр сохраняться после перезагрузок системы (FWPM_FILTER_FLAG_PERSISTENT) или является ли он фильтром времени загрузки (FWPM_FILTER_FLAG_BOOTTIME). Элемент weight определяет значение приоритета фильтра относительно других фильтров. numFilterConditions - число условий фильтрации, заданных в элементе filterCondition, массиве структур FWPM_FILTER_CONDITION, описывающих все условия фильтрации. Чтобы выносные функции обработали событие, все условия должны быть истинными. Наконец, action - значение FWP_ACTION_TYPE, указывающее действие, которое следует выполнить, если все условия фильтрации истинны. Среди этих действий есть разрешение, блокировка или передача запроса выносной функции.

Из этих элементов важнее всего filterCondition, поскольку каждое условие фильтра в массиве представляет отдельное правило, по которому будут оцениваться соединения. Само правило состоит из значения условия и типа совпадения. Определение этой структуры приведено в листинге 7-6.

Листинг 7-6. Определение структуры FWPM_FILTER_CONDITION

Первый элемент, fieldKey, указывает оцениваемый атрибут. У каждого уровня фильтрации есть собственные атрибуты, идентифицируемые GUID. Например, фильтр, вставленный в потоковый уровень, может работать с локальными и удалёнными IP-адресами и портами, направлением трафика, входящим или исходящим, и флагами, например указывающим, использует ли соединение прокси.

Элемент matchType задаёт тип выполняемого сопоставления. Эти виды сравнения определены в перечислении FWP_MATCH_TYPE, показанном в листинге 7-7, и позволяют сопоставлять строки, целые числа, диапазоны и другие типы данных.

Листинг 7-7. Перечисление FWP_MATCH_TYPE

Последний элемент структуры, conditionValue, - это условие, с которым должно сопоставляться соединение. Значение условия фильтра состоит из двух частей - типа данных и значения условия, - объединённых в структуре FWP_CONDITION_VALUE, показанной в листинге 7-8.

Листинг 7-8. Определение структуры FWP_CONDITION_VALUE

Значение FWP_DATA_TYPE указывает, какой элемент объединения драйвер должен использовать для оценки данных. Например, если элемент type имеет значение FWP_V4_ADDR_MASK, соответствующее адресу IPv4, будет использован элемент v4AddrMask.

В сочетании элементы типа совпадения и значения условия образуют отдельное требование фильтрации. Например, таким требованием может быть «IP-адрес назначения равен 1.1.1.1» или «TCP-порт больше 1024». Что должно произойти, когда условие оказывается истинным? Для определения этого используется элемент action структуры FWPM_FILTER. В драйверах выносных функций, выполняющих функции брандмауэра, можно разрешить или заблокировать трафик на основе определённых атрибутов. Однако при мониторинге безопасности большинство разработчиков направляют запрос выносным функциям, задавая флаг FWP_ACTION_CALLOUT_INSPECTION, который передаёт запрос выносной функции, не ожидая, что та примет решение разрешить или запретить соединение.

Если объединить все три компонента элемента filterCondition, условие фильтрации можно представить полным предложением, как показано на рисунке 7-5.

Рисунок 7-5. Условия фильтрации

Теперь у нас есть базовая логика правила «если это, сделать то», но ещё предстоит разобраться с некоторыми другими условиями, связанными с арбитражем фильтров.

Что, если у драйвера есть фильтры, например одновременно разрешающий трафик на TCP-порту 1080 и блокирующий исходящие соединения на TCP-портах выше 1024? Для разрешения таких конфликтов каждому фильтру нужно назначить вес. Чем больше вес, тем выше приоритет условия и тем раньше его следует оценить. Например, фильтр, разрешающий трафик на порту 1080, должен оцениваться раньше фильтра, блокирующего весь трафик на портах выше 1024, чтобы программы, использующие порт 1080, могли работать. В коде вес - это всего лишь значение FWP_VALUE (UINT8 или UINT64), назначенное элементу weight структуры FWPM_FILTER.

Помимо веса, фильтр нужно назначить подуровню, чтобы он оценивался в нужный момент. Для этого указывается GUID в элементе layerKey структуры. Если мы создали собственный подуровень, здесь указывается его GUID. В противном случае используется один из GUID подуровней по умолчанию, перечисленных в таблице 7-1.

Таблица 7-1. GUID подуровней по умолчанию

Обратите внимание: идентификатор подуровня FWPM_SUBLAYER_IPSEC_SECURITY_REALM определён в заголовке fwpmu.h, но не документирован.

Последний параметр, который можно передать fwpuclnt!FwpmFilterAdd(), - дескриптор безопасности. Хотя он необязателен, он позволяет разработчику явно задать список управления доступом для своего фильтра. В противном случае функция применит к фильтру значение по умолчанию. Этот стандартный дескриптор безопасности предоставляет права GenericAll членам локальной группы Administrators, а права GenericRead, GenericWrite и GenericExecute - членам группы Network Configuration Operators, а также службе узла диагностики (WdiServiceHost), агенту политики IPsec (PolicyAgent), службе списка сетей (NetProfm), службе удалённого вызова процедур (RpcSs) и службе брандмауэра Windows (MpsSvc). Наконец, права FWPM_ACTRL_OPEN и FWPM_ACTRL_CLASSIFY предоставляются группе Everyone.

После завершения вызова fwpuclnt!FwpmFilterAdd() драйвер выносной функции инициализирован и будет обрабатывать события, пока не придёт время его выгрузить. Процесс выгрузки выходит за рамки этой главы, поскольку в значительной степени не относится к мониторингу безопасности, но он закрывает все ранее открытые дескрипторы, удаляет созданные подуровни и фильтры и безопасно удаляет драйвер.

Основная часть телеметрии, собираемой драйвером фильтра WFP, поступает от его выносных функций. Чаще всего это классифицирующие выносные функции, которые получают на вход сведения о соединении. Из этих данных разработчики могут извлечь телеметрию, полезную для обнаружения вредоносной активности. Рассмотрим эти функции подробнее, начиная с определения в листинге 7-9.

Листинг 7-9. Определение FwpsCalloutClassifyFn

При вызове выносная функция получает указатели на несколько структур с интересными подробностями об обрабатываемых данных. Среди них есть как базовые сетевые сведения, которые ожидаешь получить от любого приложения захвата пакетов, например удалённый IP-адрес, так и метаданные с дополнительным контекстом, включая PID, путь к образу и токен запросившего процесса.

В ответ выносная функция задаёт действие для прокладки потокового уровня, если обрабатываемый пакет находится на потоковом уровне, а также действие для механизма фильтрации, например блокировать или разрешить пакет. Она также может передать принятие решения следующей зарегистрированной выносной функции. В следующих разделах этот процесс описан подробнее.

Первый параметр, указатель на структуру FWPS_INCOMING_VALUES, определён в листинге 7-10 и содержит сведения о соединении, переданном механизмом фильтрации выносной функции.

Листинг 7-10. Структура FWPS_INCOMING_VALUES

Первый элемент этой структуры содержит идентификатор уровня фильтрации, на котором были получены данные. Microsoft определяет эти значения, например FWPM_LAYER_INBOUND_IPPACKET_V4.

Второй элемент содержит число записей в массиве, на который указывает третий параметр, incomingValue. Это массив структур FWPS_INCOMING_VALUE с данными, которые механизм фильтрации передаёт выносной функции. В каждой структуре массива находится только структура FWP_VALUE, показанная в листинге 7-11 и описывающая тип и значение данных.

Листинг 7-11. Определение структуры FWP_VALUE

Чтобы обратиться к данным внутри массива, драйверу нужно знать индекс, по которому они расположены. Этот индекс зависит от идентификатора обрабатываемого уровня. Например, для уровня FWPS_LAYER_OUTBOUND_IPPACKET_V4 драйвер обращается к полям по их индексам в перечислении FWPS_FIELDS_OUTBOUND_IPPACKET_V4, определённом в листинге 7-12.

Листинг 7-12. Перечисление FWPS_FIELDS_OUTBOUND_IPPACKET_V4

Например, если драйвер EDR хочет проверить удалённый IP-адрес, он может получить это значение с помощью кода из листинга 7-13.

Листинг 7-13. Обращение к удалённому IP-адресу во входных значениях

В этом примере драйвер EDR извлекает IP-адрес, обращаясь к значению беззнакового 32-разрядного целого числа (uint32) по индексу FWPS_FIELD_OUTBOUND_IPPACKET_V4_IP_REMOTE_ADDRESS во входных значениях.

Следующий параметр, получаемый выносной функцией, - указатель на структуру FWPS_INCOMING_METADATA_VALUES0, которая предоставляет EDR невероятно ценные метаданные помимо сведений, ожидаемых от приложения захвата пакетов вроде Wireshark. Эти метаданные показаны в листинге 7-14.

Листинг 7-14. Определение структуры FWPS_INCOMING_METADATA_VALUES0

Мы упоминали, что одно из главных преимуществ мониторинга сетевого трафика на каждом конечном устройстве - контекст, предоставляемый таким подходом EDR. Его можно увидеть в элементах processPath, processId и token, которые дают сведения о процессе на конечном устройстве и связанном субъекте.

Обратите внимание, что заполнены будут не все значения этой структуры. Чтобы увидеть, какие значения присутствуют, выносная функция проверяет элемент currentMetadataValues, представляющий побитовое ИЛИ комбинации идентификаторов фильтров метаданных. Microsoft предусмотрительно предоставила макрос FWPS_IS_METADATA_FIELD_PRESENT(), который вернёт истину, если интересующее нас значение присутствует.

После метаданных классифицирующая функция получает сведения о фильтруемом уровне и условиях вызова выносной функции. Например, если данные исходят с потокового уровня, параметр будет указывать на структуру FWPS_STREAM_CALLOUT_IO_PACKET0. Эти данные уровня содержат указатель на структуру FWPS_STREAM_DATA0 с флагами, кодирующими характеристики потока, например является ли он входящим или исходящим, имеет ли высокий приоритет и передаст ли сетевой стек флаг FIN в последнем пакете. Они также содержат смещение в потоке, размер данных в потоке и указатель на NET_BUFFER_LIST, описывающий текущую часть потока.

Этот список буферов представляет собой связанный список структур NET_BUFFER. Каждая структура списка содержит цепочку списков дескрипторов памяти, используемых для хранения данных, отправленных или полученных по сети. Обратите внимание: если запрос возник не на потоковом уровне, параметр layerData будет указывать только на NET_BUFFER_LIST, если он не равен null.

Структура данных уровня также содержит элемент streamAction - значение FWPS_STREAM_ACTION_TYPE, описывающее действие, которое выносная функция рекомендует выполнить прокладке потокового уровня. В их число входят следующие действия.

• Ничего не делать (FWPS_STREAM_ACTION_NONE).

• Разрешить всем будущим сегментам данных в потоке продолжать движение без проверки (FWPS_STREAM_ACTION_ALLOW_CONNECTION).

• Запросить дополнительные данные. Если задано это действие, выносная функция должна заполнить элемент countBytesRequired числом необходимых байтов потоковых данных (FWPS_STREAM_ACTION_NEED_MORE_DATA).

• Разорвать соединение (FWPS_STREAM_ACTION_DROP_CONNECTION).

• Отложить обработку до вызова fwpkclnt!FwpsStreamContinue0(). Это используется для управления потоком, чтобы снизить скорость поступления данных (FWPS_STREAM_ACTION_DEFER).

Не путайте этот элемент streamAction с параметром classifyOut, переданным классифицирующей функции для указания результата операции фильтрации.

Вероятно, обход сетевых фильтров интересует вас прежде всего потому, что вы хотите вывести в интернет свой трафик управления и контроля, однако фильтрации подвергаются и другие виды трафика, например горизонтальное перемещение и сетевая разведка.

Однако вариантов обхода драйверов выносных функций WFP немного, по крайней мере по сравнению с другими компонентами датчиков. Во многом обход сетевых фильтров очень похож на обычную оценку правил брандмауэра. Некоторые фильтры могут явно разрешать или запрещать трафик либо отправлять его содержимое выносной функции для проверки.

Как и при любом другом анализе покрытия правилами, основная работа сводится к перечислению различных фильтров в системе, их конфигураций и наборов правил. К счастью, множество доступных инструментов делает этот процесс относительно безболезненным. Встроенная команда netsh позволяет экспортировать зарегистрированные в настоящий момент фильтры в XML-документ, пример которого показан в листинге 7-15.

Листинг 7-15. Перечисление зарегистрированных фильтров с помощью netsh

Поскольку разбор XML может доставить некоторые неудобства, можно предпочесть альтернативный инструмент NtObjectManager. Он содержит командлеты для сбора сведений о компонентах WFP, включая идентификаторы подуровней и фильтры.

Чтобы получить представление о том, какие драйверы проверяют трафик в системе, одним из первых действий следует перечислить все нестандартные подуровни. Это можно сделать командами из листинга 7-16.

Листинг 7-16. Перечисление подуровней WFP с помощью NtObjectManager

Веса указывают порядок оценки подуровней во время арбитража фильтров. Ищите интересные подуровни, заслуживающие дальнейшего изучения, например связанные с приложениями мониторинга безопасности. Затем с помощью командлета Get-FwFilter получите фильтры, связанные с указанным подуровнем, как показано в листинге 7-17.

Листинг 7-17. Перечисление фильтров, связанных с подуровнем фильтров

Для наших целей самый интересный фильтр на этом уровне - CalloutInspection, поскольку он отправляет содержимое сетевого соединения драйверу, который определит, следует ли разорвать соединение. Выносные функции можно исследовать, передавая имена их ключей командлету Get-FwCallout. В листинге 7-18 показан процесс исследования одного из фильтров Windows Defender.

Листинг 7-18. Исследование фильтров WFP с помощью NtObjectManager

Эти сведения помогают определить тип проверяемого трафика: в них есть уровень, для которого зарегистрирована выносная функция; описание, способное облегчить понимание назначения выносной функции; и дескриптор безопасности, который можно проверить на возможные ошибки конфигурации, предоставляющие чрезмерный контроль. Но они всё равно не сообщают точно, что ищет драйвер. Ни два поставщика EDR не проверяют одни и те же атрибуты одинаковым образом, поэтому единственный способ узнать, что исследует драйвер, - выполнить обратную разработку его процедур выносных функций.

Однако фильтры WFP можно оценивать, разыскивая пробелы конфигурации, подобные встречающимся в обычных брандмауэрах. В самом деле, зачем выполнять обратную разработку драйвера, если можно просто найти правила, которыми удастся злоупотребить? Один из моих любимых способов обхода обнаружения - найти пробелы, позволяющие трафику проскользнуть. Например, если выносная функция отслеживает только трафик IPv4, трафик, отправленный по IPv6, не будет проверяться.

Поскольку способы обхода различаются между поставщиками и средами, ищите правила, явно разрешающие трафик к определённому адресу назначения. По моему опыту, обычно они реализуются для конкретной среды, где развёрнута EDR, а не входят в стандартную конфигурацию EDR. Некоторые правила могут даже устареть. Предположим, вы обнаружили старое правило, разрешающее весь исходящий трафик на TCP-порту 443 к определённому домену. Если срок регистрации домена истёк, вы можете приобрести его и использовать как канал управления и контроля по HTTPS.

Также ищите конкретные конфигурации фильтров, которыми можно воспользоваться. Например, фильтр может сбрасывать FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT. В результате фильтры с меньшим приоритетом не смогут переопределять решения этого фильтра. Предположим теперь, что EDR явно разрешает исходящий трафик к домену и сбрасывает упомянутый флаг. Даже если фильтр с меньшим приоритетом выдаст команду блокировки, трафик всё равно будет выпущен наружу.

Разумеется, как и всё в WFP, это не настолько просто. Существует флаг FWPS_RIGHT_ACTION_WRITE, который отменяет такое решение, если сброшен до оценки фильтра. Это называется конфликтом фильтров и приводит к нескольким последствиям: трафик блокируется, формируется событие аудита, а подписанные на уведомления приложения получают уведомление, позволяющее узнать об ошибке конфигурации.

Подводя итог, обход фильтров WFP очень похож на обход традиционных брандмауэров: можно искать пробелы в наборах правил, конфигурациях и логике проверки, реализованной драйвером сетевого фильтра EDR, чтобы найти способы вывести свой трафик наружу. Оценивайте применимость каждого метода в контексте среды и конкретных фильтров каждой EDR. В одних случаях достаточно просмотреть правила фильтрации. В других потребуется глубоко исследовать логику проверки драйвера, чтобы определить, что и как фильтруется.

Драйверы сетевых фильтров способны разрешать, запрещать или проверять сетевой трафик на узле. Для EDR особенно важна функция проверки, обеспечиваемая выносными функциями этих драйверов. Когда действия атакующего затрагивают сетевой стек, например маяк агента управления и контроля или горизонтальное перемещение, драйвер сетевого фильтра, расположенный непосредственно на пути трафика, может выделить их индикаторы. Для обхода этих выносных функций требуется понимать, какие виды трафика они хотят проверять, а затем находить пробелы покрытия, подобно обычному аудиту правил брандмауэра.

В ETW участвуют три основных компонента: поставщики, потребители и контроллеры. Каждый из них выполняет собственную задачу в сеансе трассировки событий. Следующий обзор описывает место каждого компонента в общей архитектуре ETW.

Проще говоря, поставщики - это программные компоненты, формирующие события. Ими могут быть части системы, например Планировщик заданий, стороннее приложение или даже само ядро. Обычно поставщик является не отдельным приложением или образом, а основным образом, связанным с компонентом.

Когда этот образ поставщика проходит по интересному или вызывающему опасения пути кода, разработчик может заставить его сформировать событие, связанное с выполнением. Например, если приложение обрабатывает аутентификацию пользователей, оно может формировать событие при каждой неудачной аутентификации. Такие события содержат любые данные, которые разработчик считает необходимыми для отладки или мониторинга приложения: от простой строки до сложных структур.

У поставщиков ETW есть GUID, по которым их идентифицируют другие программы. Кроме того, поставщики имеют более удобные для пользователя имена, чаще всего определённые в их манифестах, чтобы людям было легче их различать. В стандартной установке Windows 10 зарегистрировано около 1100 поставщиков. В таблице 8-1 перечислены те из них, которые могут быть полезны продуктам защиты конечных устройств.

Таблица 8-1. Стандартные поставщики ETW, относящиеся к мониторингу безопасности

Поставщики ETW являются защищаемыми объектами, то есть к ним можно применять дескриптор безопасности. Он позволяет Windows ограничивать доступ к объекту через дискреционный список управления доступом или журналировать попытки доступа через системный список управления доступом. В листинге 8-1 показан дескриптор безопасности, применённый к поставщику Microsoft-Windows-Services.

Листинг 8-1. Оценка дескриптора безопасности, применённого к поставщику

Эта команда разбирает двоичный дескриптор безопасности из конфигурации поставщика в реестре, используя его GUID. Затем с помощью класса WMI Win32_SecurityDescriptorHelper она преобразует массив байтов из реестра в строку языка определения дескрипторов безопасности. Строка передаётся командлету PowerShell ConvertFrom-SddlString, который возвращает удобочитаемые сведения дескриптора безопасности. По умолчанию этот дескриптор разрешает доступ только NT AUTHORITY\SYSTEM, NT AUTHORITY\LOCAL SERVICE и членам локальной группы Administrators. Следовательно, для прямого взаимодействия с поставщиками код контроллера должен выполняться с правами администратора.

В настоящее время разработчики могут формировать события из приложений-поставщиков с помощью четырёх основных технологий.

Managed Object Format (MOF). MOF - язык определения событий, позволяющий потребителям понимать, как принимать и обрабатывать их. Для регистрации и записи событий с помощью MOF поставщики используют соответственно функции sechost!RegisterTraceGuids() и advapi!TraceEvent().

Windows Software Trace Preprocessor (WPP). Подобно журналу событий Windows, WPP позволяет поставщику записать идентификатор и данные события: сначала в двоичном виде, а затем отформатировать их в удобочитаемый вид. WPP поддерживает более сложные типы данных, чем MOF, включая временные метки и GUID, и дополняет поставщиков на основе MOF. Подобно поставщикам MOF, поставщики WPP используют функции sechost!RegisterTraceGuids() и advapi!TraceEvent() для регистрации и записи событий. Кроме того, для регистрации GUID поставщика WPP может использовать макрос WPP_INIT_TRACING.

Манифесты. Манифесты - XML-файлы с элементами, определяющими поставщика, включая сведения о формате событий и самом поставщике. Эти манифесты встраиваются в двоичный файл поставщика во время компиляции и регистрируются в системе. Поставщики с манифестами используют функцию advapi!EventRegister() для регистрации событий и advapi!EventWrite() для их записи. Сегодня это, по-видимому, самый распространённый способ регистрации поставщиков, особенно поставляемых с Windows.

TraceLogging. Представленная в Windows 10 технология TraceLogging - самый новый способ предоставления событий. В отличие от остальных технологий, TraceLogging допускает самоописывающие события: потребителю не требуется зарегистрированный в системе класс или манифест, чтобы понимать, как их обрабатывать. Потребитель использует API Trace Data Helper (TDH) для декодирования событий и работы с ними. Такие поставщики используют advapi!TraceLoggingRegister() и advapi!TraceLoggingWrite() для регистрации и записи событий.

Независимо от выбранного разработчиком способа результат один: приложение формирует события для потребления другими приложениями.

Чтобы понять, почему поставщик формирует определённые события, часто полезно изучить сам поставщик. К сожалению, Windows не предоставляет простого способа преобразовать имя или GUID поставщика в образ на диске. Иногда эти сведения можно получить из метаданных события, но во многих случаях, например когда источником события служит DLL или драйвер, его поиск требует дополнительных усилий. В таких ситуациях учитывайте следующие свойства поставщиков ETW.

• PE-файл поставщика должен ссылаться на его GUID, чаще всего в разделе .rdata, где хранятся инициализированные данные только для чтения.

• Поставщик должен быть файлом исполняемого кода, обычно .exe, .dll или .sys.

• Поставщик должен вызывать API регистрации: advapi!EventRegister() или ntdll!EtwEventRegister() для приложений пользовательского режима и ntoskrnl!EtwRegister() для компонентов режима ядра.

• Если используется зарегистрированный в системе манифест, образ поставщика будет указан в значении ResourceFileName раздела реестра HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\<PROVIDER_GUID>. Этот файл будет содержать ресурс WEVT_TEMPLATE, представляющий собой двоичное представление манифеста.

Можно просканировать файлы операционной системы и вернуть соответствующие этим требованиям. Инструмент с открытым исходным кодом FindETWProviderImage, доступный на GitHub, упрощает процесс. В листинге 8-2 с его помощью находятся образы, ссылающиеся на GUID поставщика Microsoft-Windows-TaskScheduler.

Листинг 8-2. Поиск двоичных файлов поставщика с помощью FindETWProviderImage

Если изучить вывод, можно заметить, что у подхода есть пробелы. Например, инструмент вернул истинного поставщика событий, schedsvc.dll, но также три других образа. Ложноположительные результаты могут возникать потому, что образы потребляют события целевого поставщика и поэтому содержат его GUID либо формируют собственные события и потому импортируют один из API регистрации. Метод может выдавать и ложноотрицательные результаты: например, когда источником события является ntoskrnl.exe, образ не будет найден в реестре и не импортирует ни одну из функций регистрации.

Чтобы подтвердить личность поставщика, нужно глубже исследовать образ. Это можно сделать с помощью относительно простой методики. В дизассемблере перейдите к смещению или относительному виртуальному адресу, сообщённому FindETWProviderImage, и найдите ссылки на GUID из функции, вызывающей API регистрации. Адрес GUID должен передаваться функции регистрации в регистре RCX, как показано в листинге 8-3.

Листинг 8-3. Дизассемблированный код функции регистрации поставщика внутри schedsvc.dll

В этом дизассемблированном коде нас интересуют две инструкции. Первая загружает адрес GUID поставщика в RCX 1. Сразу после неё вызывается импортированная функция ntdll!EtwEventRegister() 2, регистрирующая поставщика в операционной системе.

Теперь поставщик определён. Далее многие инженеры по обнаружению начинают исследовать, какие условия заставили его сформировать событие. Подробности этого процесса выходят за рамки книги, поскольку могут существенно различаться в зависимости от поставщика, хотя в главе 12 тема будет рассмотрена подробнее. Однако типовой рабочий процесс выглядит следующим образом.

В дизассемблере пометьте REGHANDLE, возвращённый API регистрации событий, затем найдите ссылки на этот REGHANDLE из функции, записывающей события ETW, например ntoskrnl!EtwWrite(). Пошагово пройдите функцию, разыскивая источник переданного ей параметра UserData. Проследите выполнение от этого источника до функции записи событий, проверяя условные переходы, которые могли бы помешать формированию события. Повторите эти действия для каждой уникальной ссылки на глобальный REGHANDLE.

Контроллеры - компоненты, которые определяют сеансы трассировки и управляют ими; такие сеансы регистрируют события, записанные поставщиками, и передают их потребителям событий. Среди задач контроллера есть запуск и остановка сеансов, включение и отключение связанных с сеансом поставщиков, управление размером пула буферов событий и многое другое. Одно приложение может содержать код и контроллера, и потребителя; либо контроллер может быть полностью отдельным приложением, как Xperf и logman - две утилиты, упрощающие сбор и обработку событий ETW.

Контроллеры создают сеансы трассировки с помощью API sechost!StartTrace() и настраивают их с помощью sechost!ControlTrace() и advapi!EnableTraceEx() или sechost!EnableTraceEx2(). В Windows XP и более поздних версиях контроллеры могут одновременно запускать не более 64 сеансов трассировки и управлять ими. Для просмотра таких сеансов используйте logman, как показано в листинге 8-4.

Листинг 8-4. Перечисление сеансов трассировки с помощью logman.exe

Каждое имя в столбце Data Collector Set представляет уникальный контроллер с собственными подчинёнными сеансами трассировки. Контроллеры из листинга 8-4 встроены в Windows, поскольку операционная система также активно использует ETW для мониторинга активности.

Контроллеры могут также запрашивать существующие трассировки для получения сведений. В листинге 8-5 показано, как это делается.

Листинг 8-5. Запрос конкретной трассировки с помощью logman.exe

Этот запрос предоставляет сведения о включённых в сеансе поставщиках 2 и используемых ключевых словах фильтрации 3, о том, является ли трассировка трассировкой реального времени или файловой 1, а также показатели производительности. По этим сведениям можно начать определять, служит ли трассировка для мониторинга производительности или для сбора телеметрии EDR.

Потребители - программные компоненты, получающие события после их регистрации сеансом трассировки. Они могут либо читать события из файла журнала на диске, либо потреблять их в реальном времени. Поскольку почти каждый агент EDR является потребителем реального времени, мы сосредоточимся исключительно на них.

Потребители используют sechost!OpenTrace() для подключения к сеансу реального времени и sechost!ProcessTrace(), чтобы начать потреблять события из него. Каждый раз при получении нового события потребителем внутренняя функция обратного вызова разбирает данные события на основе сведений, предоставленных поставщиком, например манифеста события. Затем потребитель может делать со сведениями всё, что пожелает. В случае программы защиты конечных устройств это может означать создание предупреждения, выполнение превентивных действий или сопоставление активности с телеметрией, собранной другим датчиком.

Разберём процесс разработки потребителя и работы с событиями. В этом разделе мы выявим использование вредоносных сборок платформы .NET в памяти, например применяемых функцией execute-assembly агента Beacon из Cobalt Strike. Одна из стратегий выявления таких сборок - искать имена классов, принадлежащих известным наступательным проектам C#. Хотя атакующие легко могут обойти этот метод, изменив имена классов и методов вредоносной программы, он способен эффективно выявлять использование неизменённых инструментов менее опытными злоумышленниками.

Наш потребитель будет принимать отфильтрованные события поставщика Microsoft-Windows-DotNETRuntime, в частности отслеживая классы, связанные с Seatbelt - инструментом разведки Windows после эксплуатации.

Чтобы начать потреблять события, сначала нужно создать сеанс трассировки с помощью API sechost!StartTrace(). Эта функция принимает указатель на структуру EVENT_TRACE_PROPERTIES, определённую в листинге 8-6. В системах с версиями Windows новее 1703 функция вместо неё может принимать указатель на структуру EVENT_TRACE_PROPERTIES_V2.

Листинг 8-6. Определение структуры EVENT_TRACE_PROPERTIES

Эта структура описывает сеанс трассировки. Потребитель заполняет её и передаёт функции, запускающей сеанс трассировки, как показано в листинге 8-7.

Листинг 8-7. Настройка свойств трассировки

Мы заполняем структуру WNODE_HEADER, на которую указывают свойства трассировки. Обратите внимание: элемент Guid содержит GUID сеанса трассировки, а не нужного поставщика. Кроме того, элемент LogFileMode структуры свойств трассировки обычно получает значение EVENT_TRACE_REAL_TIME_MODE, чтобы включить трассировку событий в реальном времени.

Сеанс трассировки пока не собирает события, поскольку для него не включены поставщики. Для добавления поставщиков используется API sechost!EnableTraceEx2(). Эта функция принимает как параметр возвращённый ранее TRACEHANDLE и определена в листинге 8-8.

Листинг 8-8. Определение функции sechost!EnableTraceEx2()

Параметр ProviderId - GUID целевого поставщика, а Level определяет серьёзность событий, передаваемых потребителю. Он может принимать значения от TRACE_LEVEL_VERBOSE (5) до TRACE_LEVEL_CRITICAL (1). Потребитель будет получать все события, уровень которых меньше или равен заданному значению.

Параметр MatchAllKeyword - битовая маска, которая разрешает записать событие, только если биты ключевых слов события совпадают со всеми битами, установленными в этом значении, либо если у события не установлены биты ключевых слов. В большинстве случаев этот элемент равен нулю. Параметр MatchAnyKeyword - битовая маска, разрешающая записать событие, только если биты его ключевых слов совпадают с любым из битов, установленных в этом значении.

Параметр EnableParameters позволяет потребителю получать в каждом событии один или несколько элементов расширенных данных, в том числе следующие.

EVENT_ENABLE_PROPERTY_PROCESS_START_KEY. Порядковый номер, идентифицирующий процесс и гарантированно уникальный в текущем сеансе загрузки.

EVENT_ENABLE_PROPERTY_SID. Идентификатор безопасности субъекта, например пользователя системы, от имени которого было сформировано событие.

EVENT_ENABLE_PROPERTY_TS_ID. Идентификатор терминального сеанса, в котором было сформировано событие.

EVENT_ENABLE_PROPERTY_STACK_TRACE. Значение, добавляющее стек вызовов, если событие было записано с помощью API advapi!EventWrite().

API sechost!EnableTraceEx2() может добавить в сеанс трассировки любое число поставщиков, каждый со своей конфигурацией фильтрации. Листинг 8-9 продолжает код из листинга 8-7 и показывает типичное использование этого API.

Листинг 8-9. Настройка поставщика для сеанса трассировки

Мы добавляем в сеанс трассировки поставщика Microsoft-Windows-DotNETRuntime 1 и задаём MatchAnyKeyword для ключевых слов Interop (0x2000), NGen (0x20), Jit (0x10) и Loader (0x8) 2. Эти ключевые слова позволяют отфильтровать неинтересные события и собирать только относящиеся к тому, что мы хотим отслеживать.

После завершения всех подготовительных шагов можно запустить сеанс трассировки. Для этого агент EDR вызывает sechost!OpenTrace(), передавая единственный параметр - указатель на структуру EVENT_TRACE_LOGFILE, определённую в листинге 8-10.

Листинг 8-10. Определение структуры EVENT_TRACE_LOGFILE

В листинге 8-11 показано использование этой структуры.

Листинг 8-11. Передача структуры EVENT_TRACE_LOGFILE функции sechost!OpenTrace()

Хотя структура относительно велика, сейчас для нас важны только три элемента. LoggerName - имя сеанса трассировки 1, а ProcessTraceMode - битовая маска со значениями PROCESS_TRACE_MODE_EVENT_RECORD (0x10000000), указывающим, что события должны использовать формат EVENT_RECORD, представленный в Windows Vista, и PROCESS_TRACE_MODE_REAL_TIME (0x100), указывающим, что события следует получать в реальном времени 2. Наконец, EventRecordCallback - указатель на внутреннюю функцию обратного вызова 3, которую мы вскоре рассмотрим; ETW вызывает её для каждого нового события, передавая структуру EVENT_RECORD.

Когда sechost!OpenTrace() завершается, она возвращает новый TRACEHANDLE, в нашем примере hSession. Затем можно передать этот дескриптор функции sechost!ProcessTrace(), как показано в листинге 8-12, чтобы начать обработку событий.

Листинг 8-12. Создание потока для обработки событий

Мы передаём текущее системное время 1 функции sechost!ProcessTrace(), сообщая системе, что хотим регистрировать только события, возникшие после этого момента. После вызова функция захватывает управление текущим потоком, поэтому, чтобы полностью не заблокировать остальную часть приложения, мы создаём отдельный поток 2 только для сеанса трассировки.

Если ошибок не возникло, события начинают поступать от поставщика потребителю и обрабатываться внутренней функцией обратного вызова, указанной в элементе EventRecordCallback структуры EVENT_TRACE_LOGFILE. Мы рассмотрим эту функцию в разделе «Обработка событий» на странице 158.

Наконец, нужен способ при необходимости остановить трассировку. Один из вариантов - использовать глобальное логическое значение, которое можно переключить, когда трассировку требуется остановить, но подойдёт любой способ подать потоку сигнал выхода. Однако если применяемый метод может вызвать внешний пользователь, например через непроверенную функцию RPC, злоумышленник способен полностью остановить сбор событий агентом через сеанс трассировки. В листинге 8-13 показан возможный способ остановки трассировки.

Листинг 8-13. Использование обработчика управления консолью для подачи потоку сигнала выхода

В этом примере используется внутренняя процедура обработчика управления консолью ConsoleCtrlHandler() и объект события, ожидающий сочетания клавиш Ctrl-C 1. Когда обработчик замечает это сочетание, внутренняя функция уведомляет объект события 2 - часто используемый объект синхронизации, сообщающий потоку о наступлении некоторого события, - и возвращает управление. Поскольку объект события получил сигнал, приложение возобновляет выполнение и закрывает сеанс трассировки 3.

Когда поток потребителя получает новое событие, его функция обратного вызова, в нашем примере OnEvent(), вызывается с указателем на структуру EVENT_RECORD. Эта структура, определённая в листинге 8-14, представляет событие целиком.

Листинг 8-14. Определение структуры EVENT_RECORD

На первый взгляд структура может показаться простой, но она способна содержать огромное количество сведений. Первое поле, EventHeader, хранит базовые метаданные события, например идентификатор процесса двоичного файла поставщика, временную метку и EVENT_DESCRIPTOR, подробно описывающий само событие. Элемент ExtendedData соответствует данным, переданным в параметре EnableProperty функции sechost!EnableTraceEx2(). Это поле является указателем на EVENT_HEADER_EXTENDED_DATA_ITEM, определённую в листинге 8-15.

Листинг 8-15. Определение структуры EVENT_HEADER_EXTENDED_DATA_ITEM

Элемент ExtType содержит идентификатор, определённый в eventcons.h и показанный в листинге 8-16, который сообщает потребителю, на какой тип данных указывает элемент DataPtr. Обратите внимание: значительная часть значений из заголовочных файлов официально не поддерживается для вызывающих этот API в документации Microsoft.

Листинг 8-16. Константы EVENT_HEADER_EXT_TYPE

Элемент ExtendedData структуры EVENT_RECORD содержит ценные данные, но агенты обычно используют их для дополнения других источников, особенно элемента UserData структуры EVENT_RECORD. Здесь всё немного усложняется, поскольку Microsoft утверждает, что почти во всех случаях эти данные следует получать с помощью API TDH.

Мы разберём этот процесс в нашей функции обратного вызова, но помните: пример представляет лишь один подход к извлечению нужных сведений и может не соответствовать производственному коду. Чтобы начать обработку данных события, агент вызывает tdh!TdhGetEventInformation(), как показано в листинге 8-17.

Листинг 8-17. Начало обработки данных события

Выделив память нужного размера, мы передаём функции указатель на структуру TRACE_EVENT_INFO как первый параметр. Эта структура определена в листинге 8-18.

Листинг 8-18. Определение структуры TRACE_EVENT_INFO

После возврата функция заполняет структуру полезными метаданными, например DecodingSource 1, используемым для определения способа описания события: в манифесте инструментария, классе MOF или шаблоне WPP. Но самое важное значение - EventPropertyInfoArray 2, массив структур EVENT_PROPERTY_INFO, определённых в листинге 8-19, который предоставляет сведения о каждом свойстве элемента UserData структуры EVENT_RECORD.

Листинг 8-19. Структура EVENT_PROPERTY_INFO

Каждую структуру массива необходимо разбирать отдельно. Сначала определяется длина обрабатываемого свойства. Она зависит от способа определения события, например MOF или манифеста. Обычно размер свойства получают либо из элемента length 3, либо из размера известного типа данных, например размера беззнакового длинного целого ulong, либо вызовом tdh!TdhGetPropertySize(). Если само свойство является массивом, его размер нужно получить либо из элемента count 2, либо повторным вызовом tdh!TdhGetPropertySize().

Затем нужно определить, являются ли оцениваемые данные структурой. Поскольку вызывающей стороне обычно известен формат данных, с которыми она работает, в большинстве случаев это несложно и становится важным главным образом при разборе событий незнакомых поставщиков. Если агенту всё же нужно работать со структурами внутри событий, элемент Flags 1 будет содержать флаг PropertyStruct (0x1).

Когда данные не являются структурой, как в случае поставщика Microsoft-Windows-DotNETRuntime, они представляют простое отображение значений, сведения о котором можно получить с помощью tdh!TdhGetEventMapInformation(). Эта функция принимает указатель на TRACE_EVENT_INFO, а также указатель на смещение имени отображения, доступное через элемент MapNameOffset. По завершении она возвращает указатель на структуру EVENT_MAP_INFO, определённую в листинге 8-20 и описывающую метаданные отображения события.

Листинг 8-20. Определение структуры EVENT_MAP_INFO

В листинге 8-21 показано, как наша функция обратного вызова использует эту структуру.

Листинг 8-21. Разбор сведений отображения события

Чтобы разобрать сформированные поставщиком события, мы перебираем каждое свойство верхнего уровня события, используя общее число свойств из TopLevelPropertyCount структуры сведений о событии трассировки 1. Затем, если мы имеем дело не со структурой 2 и присутствует смещение имени элемента 3, передаём его функции tdh!TdhGetEventMapInformation() 4, чтобы получить сведения отображения события.

Теперь собраны все сведения, необходимые для полного разбора данных события. Далее вызывается tdh!TdhFormatProperty() с ранее собранными сведениями. В листинге 8-22 показана эта функция в действии.

Листинг 8-22. Получение данных события с помощью tdh!TdhFormatProperty()

После завершения функции имя свойства, то есть ключ в паре ключ-значение, хранится в элементе NameOffset структуры сведений отображения события; для краткости мы сохранили его в переменной pszPropertyName 2. Значение будет храниться в буфере, переданном tdh!TdhFormatProperty() как параметр Buffer 1, в нашем примере pszValue.

Фрагмент из листинга 8-23 получен от нашего потребителя событий .NET. Он показывает событие загрузки сборки инструмента разведки Seatbelt в память через агент управления и контроля.

Листинг 8-23. Потребитель поставщика Microsoft-Windows-DotNETRuntime, обнаруживший загрузку Seatbelt

Теперь агент может использовать значения по своему усмотрению. Например, если агент хочет завершать любой процесс, загружающий сборку Seatbelt, это событие может запустить такое превентивное действие. При более пассивном подходе он может взять сведения из события, дополнить их сведениями об исходном процессе и сформировать собственное событие для передачи логике обнаружения.

Как мы показали, ETW может быть невероятно полезным способом сбора сведений от системных компонентов, которые иначе получить невозможно. Однако у технологии есть ограничения. Поскольку ETW создавалась для мониторинга или отладки, а не как критически важный компонент безопасности, её защита не столь надёжна, как у других компонентов датчиков.

В 2021 году Клаудиу Теодореску, Игорь Коркин и Андрей Гольчиков из Binarly выступили на Black Hat Europe с прекрасным докладом, где каталогизировали существующие методы обхода ETW и представили новые. В докладе были выделены 36 уникальных тактик обхода поставщиков ETW и сеансов трассировки. Авторы разделили методы на пять групп: атаки изнутри контролируемого атакующим процесса; атаки на переменные среды ETW, реестр и файлы; атаки на поставщиков ETW пользовательского режима; атаки на поставщиков ETW режима ядра; атаки на сеансы ETW.

Многие из этих методов пересекаются и в других отношениях. Кроме того, одни работают с большинством поставщиков, а другие направлены на конкретных поставщиков или сеансы трассировки. Некоторые методы также рассматриваются в публикации Palantir «Tampering with Windows Event Tracing: Background, Offense, and Defense». Обобщая выводы обеих групп, этот раздел распределяет способы обхода по более широким категориям и обсуждает преимущества и недостатки каждой.

В наступательной практике, пожалуй, самый распространённый способ обхода ETW - исправление критически важных функций, структур и других областей памяти, участвующих в формировании событий. Такие исправления направлены либо на полное прекращение формирования событий поставщиком, либо на избирательную фильтрацию отправляемых им событий.

Чаще всего это исправление принимает форму перехвата функций, однако атакующие могут вмешиваться во множество других компонентов, изменяя поток событий. Например, атакующий может обнулить TRACEHANDLE, используемый поставщиком, или изменить его TraceLevel, чтобы не допустить формирования событий определённых типов. В ядре атакующий может также изменять такие структуры, как ETW_REG_ENTRY - представление объекта регистрации события в ядре. Мы подробнее обсудим этот метод в разделе «Обход потребителя .NET» на странице 166.

Другой распространённый метод состоит в изменении постоянных атрибутов системы, включая разделы реестра, файлы и переменные среды. К этой категории относится огромное число процедур, но обычно все они направлены на то, чтобы помешать сеансу трассировки или поставщику работать ожидаемым образом, чаще всего посредством злоупотребления чем-то вроде переключателя отключения в реестре.

Два примера переключателей отключения - переменная среды COMPlus_ETWEnabled и значение ETWEnabled в разделе реестра HKCU:\Software\Microsoft.NETFramework. Установив любое из них равным 0, противник может предписать clr.dll, образу поставщика Microsoft-Windows-DotNETRuntime, не регистрировать TRACEHANDLE, не позволяя поставщику формировать события ETW.

Следующий метод предполагает вмешательство в уже работающие в системе сеансы трассировки. Хотя обычно для этого требуются привилегии уровня SYSTEM, атакующий, повысивший уровень своего доступа, может взаимодействовать с сеансом трассировки, явным владельцем которого он не является. Например, противник может удалить поставщика из сеанса трассировки с помощью sechost!EnableTraceEx2() или, что проще, с помощью logman со следующим синтаксисом:

Ещё более прямой вариант - полностью остановить трассировку:

Последний метод дополняет предыдущий: он направлен на то, чтобы до запуска помешать сеансам трассировки, чаще всего автожурналам, работать ожидаемым образом, и вносит постоянные изменения в систему.

Один из примеров - ручное удаление поставщика из сеанса автожурнала посредством изменения реестра. Удалив связанный с поставщиком подраздел HKLM:\SYSTEM\CurrentControlSet\Control\WMI\Autologger\<AUTOLOGGER_NAME>\<PROVIDER_GUID> или установив его значение Enabled равным 0, атакующий может удалить поставщика из сеанса трассировки после следующей перезагрузки.

Атакующие также могут воспользоваться механизмами ETW, чтобы не позволить сеансам работать ожидаемым образом. Например, только один сеанс трассировки на узле может включить устаревшего поставщика, то есть поставщика MOF или WPP на основе TMF. Если новый сеанс включит такого поставщика, исходный сеанс больше не будет получать нужные события. Аналогично противник может создать сеанс трассировки с тем же именем, что и целевой, прежде чем продукт безопасности успеет запустить свой сеанс. При попытке агента запустить сеанс он получит код ошибки ERROR_ALREADY_EXISTS.

Попрактикуемся в обходе источников телеметрии на основе ETW, выбрав целью потребитель среды выполнения .NET, подобный созданному нами ранее в этой главе. В публикации «Hiding Your .NET-ETW» Адам Честер описывает, как запретить среде выполнения общего языка формировать события ETW, чтобы датчик не мог определить загрузку SharpHound - инструмента C#, собирающего данные для инструмента построения путей атаки BloodHound.

Способ обхода исправляет отвечающую за формирование события ETW функцию ntdll!EtwEventWrite() и заставляет её немедленно возвращать управление при входе. Честер обнаружил, что именно эта функция в конечном итоге отвечает за формирование события, установив на неё точку останова в WinDbg и отслеживая вызовы из clr.dll. Синтаксис установки такой условной точки останова выглядит следующим образом:

Условная логика команды предписывает WinDbg разобрать стек вызовов (k) и проверить каждую строку вывода. Если какие-либо строки начинаются с clr!, указывая, что вызов ntdll!EtwEventWrite() возник в среде выполнения общего языка, срабатывает останов. Если эта подстрока не встречается в стеке вызовов, приложение просто продолжает работу.

Просмотрев стек вызовов при обнаружении подстроки, показанный в листинге 8-24, можно увидеть, как среда выполнения общего языка формирует события.

Листинг 8-24. Сокращённый стек вызовов, показывающий формирование событий ETW в среде выполнения общего языка

Если читать снизу вверх, видно, что событие возникает в System.AppDomain.Load() - функции, отвечающей за загрузку сборки в текущий домен приложения 3. Цепочка внутренних вызовов ведёт к классу ETW::Loaderlog 2, который в итоге вызывает ntdll!EtwEventWrite() 1.

Хотя Microsoft не предполагает, что разработчики будут напрямую вызывать эту функцию, соответствующая практика документирована. Ожидается, что функция возвращает код ошибки Win32. Следовательно, если вручную установить значение регистра EAX, служащего возвращаемым значением в Windows, равным 0 для ERROR_SUCCESS, функция должна немедленно вернуть управление, создавая видимость неизменно успешного завершения без формирования события.

Исправление этой функции представляет собой относительно простой процесс из четырёх шагов. Подробно разберём его в листинге 8-25.

Листинг 8-25. Исправление функции ntdll!EtwEventWrite()

С помощью kernel32!GetProcAddress() 1 мы находим точку входа ntdll!EtwEventWrite() в загруженной в настоящий момент копии ntdll.dll. Найдя функцию, изменяем защиту первых трёх байтов, то есть размер исправления, с чтения-исполнения (RX) на чтение-запись (RW) 2, чтобы разрешить перезапись точки входа. Теперь остаётся скопировать исправление чем-либо вроде memcpy() 3, а затем восстановить исходную защиту памяти 4. После этого можно выполнять функцию загрузчика сборок, не опасаясь формирования событий загрузчика среды выполнения общего языка.

С помощью WinDbg можно проверить, что ntdll!EtwEventWrite() больше не будет формировать события, как показано в листинге 8-26.

Листинг 8-26. Исправленная функция ntdll!EtwEventWrite()

При вызове эта функция немедленно очищает регистр EAX, устанавливая его равным 0, и возвращает управление. Это не позволяет дойти до логики формирования событий ETW и фактически прекращает передачу телеметрии поставщика агенту EDR.

Тем не менее у этого обхода есть ограничения. Поскольку clr.dll и ntdll.dll отображаются в собственные процессы, они позволяют напрямую вмешиваться в работу поставщика. Однако в большинстве случаев поставщик выполняется как отдельный процесс вне непосредственного контроля атакующего. Исправление функции формирования событий в отображённой ntdll.dll не прекратит формирование событий в другом процессе.

В публикации «Universally Evading Sysmon and ETW» Дилан Холлс описывает другой метод предотвращения формирования событий ETW: исправление в режиме ядра ntdll!NtTraceEvent() - системного вызова, который в конечном итоге приводит к событию ETW. Это означает, что пока исправление действует, не будет сформировано ни одно системное событие ETW, проходящее через этот системный вызов. Метод использует Kernel Driver Utility (KDU) для нарушения Driver Signature Enforcement и InfinityHook для снижения риска аварийного завершения системы механизмом PatchGuard при обнаружении исправления. Хотя метод расширяет возможности обхода обнаружений на основе ETW, он требует загрузки драйвера и изменения защищённого кода режима ядра, поэтому подвержен любым мерам противодействия методам, которые применяют KDU или InfinityHook.

ETW - одна из важнейших технологий сбора телеметрии узлов в Windows. Она предоставляет EDR наблюдаемость компонентов и процессов, таких как Планировщик заданий и локальный DNS-клиент, которые не способен отслеживать никакой другой датчик. Агент может потреблять события почти от любого найденного поставщика и использовать эти сведения, чтобы получить огромный объём контекста о действиях в системе. Обход ETW хорошо изучен, и большинство стратегий направлено на отключение, отмену регистрации или иное приведение поставщика либо потребителя в состояние, в котором он не может обрабатывать события.

Языки сценариев обладают множеством преимуществ перед компилируемыми языками. Они требуют меньше времени и накладных расходов на разработку, обходят списки разрешённых приложений, могут выполняться в памяти и переносимы. Кроме того, они позволяют использовать возможности таких платформ, как .NET, и часто дают прямой доступ к API Win32, что значительно расширяет функциональность языка сценариев.

Хотя сценарные вредоносные программы существовали и до появления AMSI, выпуск в 2015 году Empire - платформы управления и контроля на основе PowerShell - сделал их использование массовым в наступательной сфере. Благодаря удобству, стандартному включению в Windows 7 и более поздние версии и большому объёму существующей документации PowerShell для многих стал фактическим языком разработки наступательных инструментов.

Этот всплеск сценарного вредоносного ПО породил крупный пробел в защите. Предыдущие инструменты рассчитывали, что вредоносная программа будет записана на диск и выполнена. Они оказывались недостаточными против вредоносных программ, запускавших установленный в системе по умолчанию исполняемый файл с подписью Microsoft, что иногда называют использованием штатных средств, например PowerShell. Даже агентам, пытавшимся обнаруживать вызов вредоносных сценариев, было трудно: атакующие легко адаптировали полезные нагрузки и инструменты для обхода применяемых поставщиками методов обнаружения. Microsoft подчёркивает эту проблему в публикации, объявляющей AMSI, следующим примером. Предположим, защитный продукт ищет в сценарии строку "malware", чтобы определить его вредоносность. Тогда он обнаружит такой код:

Узнав об этой логике обнаружения, авторы вредоносных программ могли обойти механизм простым объединением строк:

Для противодействия разработчики пытались применять простейшую эмуляцию языка. Например, перед сканированием содержимого блока сценария они могли объединять строки. К сожалению, такой подход подвержен ошибкам: языки часто предоставляют множество способов представления данных, и каталогизировать их все для эмуляции очень сложно. Тем не менее разработчики средств защиты от вредоносных программ добились с этим методом некоторого успеха. В ответ авторы вредоносных программ немного усложнили обфускацию, применив, например, кодирование. В листинге 10-1 строка "malware" закодирована в Base64 в PowerShell.

Листинг 10-1. Декодирование строки Base64 в PowerShell

Агенты снова задействовали эмуляцию языка, чтобы декодировать данные сценария и просканировать их на вредоносное содержимое. В ответ авторы вредоносных программ перешли от простого кодирования к шифрованию и алгоритмическому кодированию, например исключающему ИЛИ (XOR). Код в листинге 10-2 сначала декодирует данные Base64, а затем применяет к декодированным байтам XOR с двухбайтовым ключом gg.

Листинг 10-2. Пример XOR в PowerShell

Развитие шифрования превысило разумные возможности эмуляции механизмов защиты, поэтому распространились обнаружения по самому наличию методов обфускации. Это создаёт собственные сложности, поскольку обычные безвредные сценарии иногда используют то, что может выглядеть как обфускация. Пример, приведённый Microsoft в своей публикации и ставший стандартным способом выполнения кода PowerShell в памяти, - загрузочная конструкция из листинга 10-3.

Листинг 10-3. Простая загрузочная конструкция PowerShell

В примере класс .NET Net.Webclient загружает сценарий PowerShell с произвольного сайта. Загруженный сценарий не записывается на диск, а существует в памяти как строка, связанная с объектом Webclient. Затем противник использует командлет Invoke-Expression, чтобы выполнить строку как команду PowerShell. В результате любое действие полезной нагрузки, например развёртывание нового агента управления и контроля, происходит полностью в памяти.

AMSI сканирует цель, а затем с помощью зарегистрированных в системе поставщиков защиты от вредоносных программ определяет, является ли она вредоносной. По умолчанию используется поставщик Microsoft Defender IOfficeAntivirus (MpOav.dll), но сторонние поставщики EDR также могут регистрировать собственных поставщиков. Дуэйн Майкл ведёт в своём проекте whoamsi на GitHub список поставщиков средств безопасности, регистрирующих поставщиков AMSI.

Чаще всего AMSI используется приложениями, которые содержат механизмы сценариев, например принимают произвольные сценарии и выполняют их связанным механизмом, работают с недоверенными буферами в памяти или взаимодействуют с исполняемым кодом не в формате PE, например файлами .docx и .pdf. AMSI интегрирован во многие компоненты Windows, включая современные версии PowerShell, .NET, JavaScript, VBScript, Windows Script Host, макросы Office VBA и контроль учётных записей. Он также интегрирован в Microsoft Exchange.

Поскольку PowerShell имеет открытый исходный код, можно изучить его реализацию AMSI и понять, как компоненты Windows используют этот инструмент. В этом разделе мы исследуем, как AMSI пытается не позволить приложению выполнять вредоносные сценарии.

Внутри System.Management.Automation.dll, DLL, предоставляющей среду выполнения для размещения кода PowerShell, есть неэкспортируемая функция PerformSecurityChecks(), отвечающая за сканирование предоставленного блока сценария и определение его вредоносности. Её вызывает созданный PowerShell обработчик команд как часть конвейера выполнения непосредственно перед компиляцией. Стек вызовов из листинга 10-4, полученный в dnSpy, показывает путь блока сценария до сканирования.

Листинг 10-4. Стек вызовов при сканировании блока сценария PowerShell

Эта функция вызывает внутреннюю утилиту AmsiUtils.ScanContent(), передавая ей блок сценария или сканируемый файл. Утилита является простой оболочкой другой внутренней функции, AmsiUtils.WinScanContent(), где и выполняется вся реальная работа.

Проверив блок сценария на тестовую строку European Institute for Computer Antivirus Research (EICAR), которую обязаны обнаруживать все антивирусы, WinScanContent первым делом создаёт новый сеанс AMSI вызовом amsi!AmsiOpenSession(). Сеансы AMSI используются для сопоставления нескольких запросов сканирования. Затем WinScanContent() вызывает amsi!AmsiScanBuffer() - функцию API Win32, которая вызывает зарегистрированных в системе поставщиков AMSI и возвращает окончательное решение о вредоносности блока сценария. В листинге 10-5 показана эта реализация в PowerShell с удалёнными несущественными частями.

Листинг 10-5. Реализация AMSI в PowerShell

В PowerShell код сначала вызывает amsi!AmsiOpenSession() 1, чтобы создать новый сеанс AMSI, в котором можно сопоставлять запросы сканирования. Если сеанс успешно открыт, сканируемые данные передаются amsi!AmsiScanBuffer() 2, которая фактически оценивает данные и определяет, выглядит ли содержимое буфера вредоносным. Результат вызова возвращается WinScanContent().

Функция WinScanContent() может вернуть одно из трёх значений.

AMSI_RESULT_NOT_DETECTED. Нейтральный результат.

AMSI_RESULT_CLEAN. Результат, указывающий, что блок сценария не содержит вредоносной программы.

AMSI_RESULT_DETECTED. Результат, указывающий, что блок сценария содержит вредоносную программу.

Если возвращено одно из первых двух значений, то есть AMSI не смог определить вредоносность блока сценария или счёл его безопасным, блоку разрешается выполняться в системе. Однако при возврате AMSI_RESULT_DETECTED создаётся ParseException, а выполнение блока сценария прекращается. В листинге 10-6 показана реализация этой логики внутри PowerShell.

Листинг 10-6. Создание ParseError при обнаружении вредоносного сценария

Поскольку AMSI создал исключение 1, выполнение сценария прекращается, а пользователю возвращается ошибка из ParseError. В листинге 10-7 показана ошибка, которую пользователь увидит в окне PowerShell.

Листинг 10-7. Созданная ошибка, показанная пользователю

Понимание того, как AMSI встроен в системные компоненты, даёт полезный контекст оценки пользовательского ввода, но не раскрывает всю картину. Что происходит, когда PowerShell вызывает amsi!AmsiScanBuffer()? Чтобы это понять, нужно глубоко погрузиться в саму реализацию AMSI. Поскольку состояние декомпиляторов C++ на момент написания книги несколько затрудняло статический анализ, придётся применить методы динамического анализа. К счастью, WinDbg делает процесс относительно безболезненным, особенно с учётом наличия отладочных символов для amsi.dll.

При запуске PowerShell сначала вызывает amsi!AmsiInitialize(). Как следует из имени, функция отвечает за инициализацию API AMSI. В основном она сводится к созданию фабрики классов COM вызовом DllGetClassObject(). В качестве аргумента функция получает идентификатор класса, соответствующий amsi.dll, вместе с идентификатором интерфейса IClassFactory, который позволяет создавать класс объектов. Затем указатель интерфейса используется для создания экземпляра интерфейса IAntimalware ({82d29c2e-f062-44e6-b5c9-3d9a2f24a2df}), показанного в листинге 10-8.

Листинг 10-8. Создание экземпляра IAntimalware

Вместо явного вызова некоторых функций иногда встречаются ссылки на _guard_dispatch_icall_fptr(). Это компонент Control Flow Guard (CFG) - технологии защиты от эксплуатации, пытающейся предотвращать косвенные вызовы, например при программировании, ориентированном на возвраты. Вкратце, эта функция проверяет битовую карту Control Flow Guard исходного образа, чтобы определить, является ли вызываемая функция допустимой целью. В контексте этого раздела для уменьшения путаницы читатель может считать такие места простыми инструкциями CALL.

В конечном итоге этот вызов приводит в amsi!AmsiComCreateProviders<IAntimalwareProvider>, где и происходит вся магия. В листинге 10-9 показан стек вызовов этого метода в WinDbg.

Листинг 10-9. Стек вызовов функции AmsiComCreateProviders

Первое крупное действие - вызов amsi!CGuidEnum::StartEnum(). Эта функция получает строку "Software\Microsoft\AMSI\Providers", которую передаёт вызову RegOpenKey(), а затем RegQueryInfoKeyW(), чтобы получить число подразделов. Далее amsi!CGuidEnum::NextGuid() перебирает подразделы и преобразует идентификаторы классов зарегистрированных поставщиков AMSI из строк в UUID. Перечислив все нужные идентификаторы классов, она передаёт выполнение amsi!AmsiComSecureLoadInProcServer(), где через RegGetValueW() запрашивается значение InProcServer32, соответствующее поставщику AMSI. В листинге 10-10 показан этот процесс для MpOav.dll.

Листинг 10-10. Параметры, переданные RegGetValueW

Затем вызывается amsi!CheckTrustLevel(), чтобы проверить значение раздела реестра SOFTWARE\Microsoft\AMSI\FeatureBits. Этот раздел содержит DWORD, который может быть равен 1, стандартное значение, или 2, чтобы соответственно отключить или включить проверку поставщиков по подписи Authenticode. Если проверки Authenticode включены, проверяется путь из раздела реестра InProcServer32. После успешной проверки путь передаётся LoadLibraryW() для загрузки DLL поставщика AMSI, как показано в листинге 10-11.

Листинг 10-11. Загрузка MpOav.dll с помощью LoadLibraryW()

Если DLL поставщика загружена успешно, вызывается её функция DllRegisterServer(), чтобы предписать ей создать записи реестра для всех классов COM, поддерживаемых поставщиком. Цикл повторяет вызовы amsi!CGuidEnum::NextGuid(), пока не будут загружены все поставщики. В листинге 10-12 показан последний шаг: вызов метода QueryInterface() для каждого поставщика с целью получить указатель на интерфейсы IAntimalware.

Листинг 10-12. Вызов QueryInterface для зарегистрированного поставщика

После возврата AmsiInitialize() AMSI готов к работе. Прежде чем PowerShell начнёт оценивать блок сценария, он вызывает AmsiOpenSession(). Как упоминалось ранее, функция позволяет AMSI сопоставлять несколько сканирований. По завершении она возвращает вызывающей стороне HAMSISESSION, который та может передавать всем последующим вызовам AMSI в текущем сеансе сканирования.

Когда встроенный в PowerShell AMSI получает блок сценария, а сеанс AMSI уже открыт, он вызывает AmsiScanBuffer() с блоком сценария на входе. Эта функция определена в листинге 10-13.

Листинг 10-13. Определение AmsiScanBuffer()

Основная обязанность функции - проверять допустимость переданных ей параметров. В том числе проверяется наличие содержимого во входном буфере и допустимого дескриптора HAMSICONTEXT с тегом AMSI, как видно в декомпилированном коде из листинга 10-14. Если любая проверка завершается неудачей, функция возвращает вызывающей стороне E_INVALIDARG (0x80070057).

Листинг 10-14. Внутренние проверки корректности AmsiScanBuffer()

Если проверки пройдены, AMSI вызывает amsi!CAmsiAntimalware::Scan(), как показано в стеке вызовов из листинга 10-15.

Листинг 10-15. Вызванный метод Scan()

Этот метод содержит цикл while, который перебирает каждого зарегистрированного поставщика AMSI; их число хранится по адресу R14 + 0x1c0. В цикле вызывается функция IAntimalwareProvider::Scan(), которую поставщик EDR может реализовать по своему усмотрению; от неё требуется лишь вернуть AMSI_RESULT, как определено в листинге 10-16.

Листинг 10-16. Определение функции CAmsiAntimalware::Scan()

В стандартной реализации AMSI Microsoft Defender, MpOav.dll, эта функция выполняет базовую инициализацию, а затем передаёт выполнение MpClient.dll - клиентскому интерфейсу Windows Defender. Обратите внимание: Microsoft не предоставляет файлы базы данных программы для компонентов Defender, поэтому имя функции MpOav.dll в стеке вызовов из листинга 10-17 неверно.

Листинг 10-17. Передача выполнения из MpOav.dll в MpClient.dll

AMSI передаёт результат сканирования обратно amsi!AmsiScanBuffer() через amsi!CAmsiAntimalware::Scan(), которая, в свою очередь, возвращает AMSI_RESULT вызывающей стороне. Если в блоке сценария обнаружено вредоносное содержимое, PowerShell создаёт исключение ScriptContainedMaliciousContent и не позволяет выполнить блок.

Как упоминалось в предыдущем разделе, разработчики могут реализовать функцию IAntimalwareProvider::Scan() по своему усмотрению. Например, можно просто журналировать сведения о сканируемом содержимом или пропускать содержимое буфера через обученную модель машинного обучения для оценки вредоносности. Чтобы понять общую архитектуру поставщиков AMSI всех производителей, в этом разделе по шагам разбирается устройство простой DLL поставщика, соответствующей минимальным требованиям Microsoft.

По своей сути поставщики AMSI - не что иное, как серверы COM, то есть DLL, загружаемые в процесс-хозяин и предоставляющие требуемую вызывающей стороне функцию, в данном случае IAntimalwareProvider. Эта функция расширяет интерфейс IUnknown тремя дополнительными методами: CloseSession закрывает сеанс AMSI по его дескриптору HAMSISESSION, DisplayName отображает имя поставщика AMSI, а Scan сканирует поток содержимого IAmsiStream и возвращает AMSI_RESULT.

В C++ базовое объявление класса, переопределяющего методы IAntimalwareProvider, может выглядеть как код в листинге 10-18.

Листинг 10-18. Пример определения класса IAntimalwareProvider

Наш код использует Windows Runtime C++ Template Library, сокращающую объём кода для создания компонентов COM. Методы CloseSession() и DisplayName() просто переопределяются собственными функциями, которые соответственно закрывают сеанс AMSI и возвращают имя поставщика. Функция Scan() получает сканируемый буфер как часть IAmsiStream, предоставляющего два метода, GetAttribute() и Read(), и определённого в листинге 10-19.

Листинг 10-19. Определение класса IAmsiStream

Метод GetAttribute() получает метаданные сканируемого содержимого. Разработчики запрашивают эти атрибуты, передавая значение AMSI_ATTRIBUTE, указывающее нужные сведения, вместе с буфером подходящего размера. AMSI_ATTRIBUTE - перечисление, определённое в листинге 10-20.

Листинг 10-20. Перечисление AMSI_ATTRIBUTE

Хотя перечисление содержит 10 атрибутов, Microsoft документирует только первые пять. AMSI_ATTRIBUTE_APP_NAME - строка с именем, версией или GUID вызывающего приложения; AMSI_ATTRIBUTE_CONTENT_NAME - строка с именем файла, URL, идентификатором сценария или эквивалентным идентификатором сканируемого содержимого; AMSI_ATTRIBUTE_CONTENT_SIZE - ULONGLONG с размером сканируемых данных; AMSI_ATTRIBUTE_CONTENT_ADDRESS - адрес содержимого в памяти, если оно полностью загружено в память; AMSI_ATTRIBUTE_SESSION содержит указатель на следующую часть сканируемого содержимого или NULL, если содержимое является самодостаточным.

В качестве примера в листинге 10-21 показано, как поставщик AMSI может использовать этот атрибут для получения имени приложения.

Листинг 10-21. Реализация функции сканирования AMSI

Когда PowerShell вызывает эту функцию, pszAppName 1 содержит имя приложения в виде строки, которую AMSI может использовать для обогащения данных сканирования. Это особенно полезно, если блок сценария признан вредоносным: EDR сможет по имени приложения завершить вызывающий процесс.

Если AMSI_ATTRIBUTE_CONTENT_ADDRESS возвращает адрес памяти, мы знаем, что сканируемое содержимое полностью загружено в память, и можем взаимодействовать с ним напрямую. Чаще всего данные предоставляются как поток; тогда для получения содержимого буфера по одному фрагменту используется метод Read(), определённый в листинге 10-22. Можно задать размер фрагментов, передаваемый методу Read() вместе с буфером того же размера.

Листинг 10-22. Определение метода IAmsiStream::Read()

Что поставщик делает с этими фрагментами данных, полностью зависит от разработчика. Он может сканировать каждый фрагмент, прочитать весь поток и вычислить хэш содержимого либо просто записать подробности в журнал. Единственное правило: при возврате метод Scan() должен передать вызывающей стороне HRESULT и AMSI_RESULT.

AMSI - одна из самых изученных областей обхода. В немалой степени это связано с его эффективностью в первые годы, которая создала серьёзные трудности наступательным командам, активно использовавшим PowerShell. Для них AMSI представлял экзистенциальный кризис, мешавший работать основным агентам.

Атакующие могут применять для обхода AMSI множество методов. Хотя некоторые поставщики пытались помечать часть из них как вредоносные, число возможностей обхода AMSI ошеломляет, поэтому поставщики обычно не способны учесть их все. В этом разделе рассмотрены некоторые наиболее популярные способы обхода в современной операционной среде, но помните, что у каждого есть множество вариантов.

Один из первых способов обхода AMSI основывался на простой обфускации строк. Если атакующий мог определить, какая часть блока сценария помечается как вредоносная, он часто обходил обнаружение, разделяя, кодируя или иным образом скрывая строку, как в листинге 10-23.

Листинг 10-23. Пример обфускации строки в PowerShell, обходящей AMSI

AMSI обычно помечает строку AmsiScanBuffer, распространённый компонент способов обхода на основе исправления, как вредоносную, но здесь видно, что объединение строк позволяет избежать обнаружения. Реализации AMSI часто получают обфусцированный код, который передают поставщикам для определения вредоносности. Следовательно, поставщик должен обрабатывать функции эмуляции языка, такие как объединение строк, декодирование и расшифрование. Однако многие поставщики, включая Microsoft, не обнаруживают даже такие тривиальные обходы, как показанный здесь.

Поскольку AMSI и связанные поставщики отображаются в процесс атакующего, он управляет этой памятью. Исправляя критически важные значения или функции внутри amsi.dll, атакующий может нарушить работу AMSI в своём процессе. Этот метод обхода чрезвычайно эффективен и примерно с 2016 года, когда Мэтт Гребер рассказал об использовании рефлексии в PowerShell для установки amsiInitFailed в true, стал стандартным выбором многих команд тестирования на проникновение. Его код из листинга 10-24 уместился в одном твите.

Листинг 10-24. Простое исправление AmsiInitFailed

При исправлении атакующие часто выбирают целью AmsiScanBuffer() - функцию, отвечающую за передачу содержимого буфера поставщикам. Дэниел Дагган описывает этот метод в публикации «Memory Patching AMSI Bypass», где перечисляет действия, которые должен выполнить код атакующего перед любой действительно вредоносной активностью.

1. Получить адрес AmsiScanBuffer() внутри amsi.dll, загруженной в процесс.

2. С помощью kernel32!VirtualProtect() изменить защиту памяти на чтение-запись, что позволит атакующему разместить исправление.

3. Скопировать исправление в точку входа функции AmsiScanBuffer().

4. Снова вызвать kernel32!VirtualProtect(), чтобы вернуть защите памяти значение чтение-исполнение.

Само исправление использует тот факт, что внутри AmsiScanBuffer() возвращает E_INVALIDARG, если первоначальные проверки завершаются неудачей. Среди них есть попытки проверить адрес сканируемого буфера. Код Даггана добавляет массив байтов, представляющий ассемблерный код из листинга 10-25. После исправления при выполнении AmsiScanBuffer() функция немедленно возвращает этот код ошибки, поскольку настоящая инструкция исходной функции была перезаписана.

Листинг 10-25. Код ошибки, возвращаемый вызывающей стороне AmsiScanBuffer() после исправления

Существует множество вариантов этого метода, и все работают очень похоже. Например, атакующий может исправить AmsiOpenSession() вместо AmsiScanBuffer(). Он также может повредить один из параметров, передаваемых AmsiScanBuffer(), например длину буфера или контекст, заставив AMSI самостоятельно вернуть E_INVALIDARG.

Microsoft довольно быстро узнала об этом методе обхода и приняла меры защиты. Одно из реализованных обнаружений основано на последовательности кодов операций, составляющих описанное исправление. Однако атакующие могут обойти такие обнаружения множеством способов. Например, они могут просто изменить ассемблерный код, чтобы менее прямым способом получить тот же результат: поместить 0x80070057 в EAX и вернуть управление. Рассмотрим пример из листинга 10-26, где значение 0x80070057 разбивается, а не помещается в регистр целиком.

Листинг 10-26. Разбиение жёстко заданных значений для обхода обнаружения исправления

Представьте, что EDR ищет помещение значения 0x80070057 в регистр EAX. Эта стратегия обойдёт логику обнаружения, поскольку значение нигде не упоминается напрямую. Вместо этого оно разделено на два значения, сумма которых оказывается равна нужному результату.

В апреле 2022 года Сери Коберн представил метод обхода AMSI без исправления amsi.dll - действия, которое начали отслеживать многие поставщики EDR. Кроме того, метод Коберна не требует fork&run, позволяя атакующему оставаться в исходном процессе.

Метод весьма изобретателен. Сначала атакующий получает указатель на функцию amsi!AmsiScanBuffer() либо из загруженной amsi.dll, либо принудительно загружая её в процесс вызовом LoadLibrary(). Затем он регистрирует векторный обработчик исключений с помощью kernel32!AddVectoredExceptionHandler(). Этот обработчик позволяет разработчикам зарегистрировать функцию, которая отслеживает все исключения приложения и управляет ими. Наконец, атакующий устанавливает аппаратную точку останова на адресе AmsiScanBuffer(), изменяя отладочные регистры текущего потока DR0, DR6 и DR7.

Когда атакующий выполняет свой код .NET непосредственно в процессе, система в итоге вызывает AmsiScanBuffer(), что приводит к срабатыванию аппаратной точки останова и вызову векторного обработчика исключений. Эта функция берёт текущий контекст потока и обновляет регистры так, чтобы они соответствовали значениям, задаваемым, когда AMSI не обнаруживает вредоносное содержимое: возвращаемому значению 0 (S-OK) в RAX и результату 0 (AMSI_RESULT_CLEAN) по адресу RSP+48.

Кроме того, функция извлекает адрес возврата из стека (RSP) и направляет указатель инструкций (RIP) обратно вызывающей стороне AmsiScanBuffer(). Затем она возвращает указатель стека в положение до вызова AmsiScanBuffer(), очищает аппаратную точку останова и возвращает код EXCEPTION_CONTINUE_EXECUTION. Выполнение возобновляется в точке срабатывания. Теперь Windows использует изменённый атакующим контекст потока и продолжает выполнение с внесёнными изменениями, передавая поддельные значения вызывающей стороне и позволяя вредоносному коду продолжить работу незамеченным.

AMSI - невероятно важная часть головоломки обнаружения на узле. Интеграция в PowerShell, .NET и Microsoft Office означает, что он расположен непосредственно на пути многих действий противника: от первоначального доступа до постэксплуатации. AMSI тщательно исследовали из-за огромного влияния на наступательные операции в момент выпуска. Сегодня AMSI играет скорее вспомогательную роль, поскольку существует почти неисчислимое множество стратегий обхода. Однако поставщики это заметили и начали вкладываться в мониторинг распространённых способов обхода AMSI, используя их как самостоятельные индикаторы активности противника.