Техника обхода EDR под названием process parameter poisoning получила практическое развитие: исследователи Flashpoint показали, что инъекцию кода можно спрятать в структурах инициализации процесса Windows, не трогая привычные API, за которыми обычно следят защитные продукты. Для русскоязычных команд это неприятный сигнал: часть правил детекта, заточенных под классическую process injection, может смотреть не туда.
Об исследовании сообщает Dark Reading. Речь не о новой вредоносной кампании и не о готовом массовом инструменте из подпольного магазина, а о технике, которую уже проверили на практике: сначала ее описали исследователи Max Hirschberger и Ogulcan Ugur в июле, затем Flashpoint собрала собственную реализацию на Rust и посмотрела, как она ведет себя в связке с дополнительными приемами уклонения от защиты.
Классическая инъекция процесса давно стала одной из любимых зон наблюдения для EDR. Защитные агенты отслеживают цепочки вызовов и операции с памятью, которые часто появляются при попытке внедрить код в другой процесс. В числе таких маркеров Dark Reading называет VirtualAllocEx(), WriteProcessMemory() и MapViewOfFile2(). Проблема process parameter poisoning в том, что атака обходит этот привычный маршрут: полезная нагрузка оказывается внутри стандартных структур инициализации, которые Windows передает новому процессу при старте.
Сценарий выглядит так: злоумышленник, который уже получил возможность выполнять код на Windows-хосте, создает «жертвенный» процесс и злоупотребляет стартовыми параметрами, автоматически передаваемыми системе. Для EDR это неудобная зона: сигналы меньше похожи на классическую инъекцию, потому что часть операций, на которые обычно срабатывают правила, просто не используется. Иными словами, защита может ждать подозрительного движения через парадную дверь, пока полезная нагрузка проходит через служебный вход.
Первичная проверка Hirschberger и Ugur была болезненной для рынка: исследователи тестировали подход против четырех неназванных крупных EDR-продуктов и заявили, что инъекция во всех случаях прошла без алертов, хотя решения были настроены на обнаружение, блокировку и remediation. Flashpoint не стала раскрывать коммерческие названия в своей части работы: компания тестировала Rust proof of concept против распространенной open source EDR-платформы с XDR-компонентом. Базовый бинарник не вызвал предупреждений со стороны EDR, но XDR заблокировал последующую активность второй стадии.
Дальше исследователи усложнили набор приемов. К process parameter poisoning добавили DLL unhooking — технику, при которой восстанавливаются функции Windows-библиотек, измененные защитным ПО для user-mode monitoring. Также применили политику, блокирующую загрузку DLL не от Microsoft: такой ход может мешать некоторым сторонним компонентам мониторинга попасть в процесс. После этой комбинации, по данным Flashpoint, XDR уже не блокировал выполнение и не показывал алертов.
Важно не перепутать выводы. Flashpoint не заявляет, что все EDR бесполезны, а Windows-защиту пора выбрасывать вместе с инструкциями по корпоративной гигиене. Исследование показывает более конкретную вещь: детект, построенный только вокруг известных API-вызовов и шаблонов process injection, становится хрупким. Когда злоумышленник переносит полезную нагрузку в менее ожидаемые структуры инициализации, сигнатурная логика и часть поведенческих правил теряют контекст.
Для SOC и blue team практический вывод довольно прямой. Flashpoint предлагает смотреть не только на то, какие Windows API вызваны, но и на то, что процесс делает после запуска. Среди направлений детекта: анализ аномальных данных в параметрах процесса, мониторинг hijacking потока исполнения, поиск кода, который исполняется из необычных областей памяти, и контроль изменения прав памяти на executable. Это не серебряная пуля, зато хорошая проверка зрелости: если телеметрия заканчивается на «кто вызвал WriteProcessMemory», покрытие явно требует пересмотра.
Разработчикам защитных средств эта история напоминает старую истину, которую рынок периодически забывает: attackers do not care about product categories, хотя по-русски это звучит еще суше. Если детект завязан на «типичный» путь атаки, то нетипичный путь быстро становится рабочим. Командам, которые пишут EDR/XDR-логику, придется внимательнее смотреть на состояние памяти, параметры старта, происхождение исполняемых участков и поведение процесса после инициализации, а не только на набор знакомых API.
Для бизнеса риск пока не выглядит как массовая угроза завтрашнего утра. Старший аналитик Flashpoint Paul Daubman заявил Dark Reading, что компания пока не видела применения этой техники в публичных образцах malware. При этом он добавил важную оговорку: технических барьеров для злоумышленников почти нет. По его оценке, широкого распространения за пределами red team и более продвинутых акторов ждать не стоит, но именно такие техники обычно первыми проверяют группы, которым важно пройти мимо зрелой защиты.
Главный вопрос теперь не в том, появится ли очередной детект под конкретный proof of concept. Появится, причем довольно быстро. Куда интереснее другое: смогут ли вендоры и корпоративные команды перейти от охоты за знакомыми вызовами к модели, где подозрительным становится само поведение процесса, его память и контекст запуска. Обход EDR все чаще упирается не в магию, а в слепые зоны телеметрии — и закрывать их придется до того, как техника окажется не в исследовательском блоге, а в реальном инциденте.