Атаки без следов: как работают бесфайловые угрозы и как их обнаружить

27.05.2026

Евгения Шафоростова

Автор

Современная атака может не оставить ни одного файла на диске — и при этом полностью скомпрометировать инфраструктуру. Антивирусы молчат, системы контроля целостности ничего не фиксируют, а злоумышленник уже выполняет команды от имени легитимных процессов. Бесфайловые атаки ломают привычную логику защиты: если раньше угрозу искали в файлах, то теперь — в поведении системы. Кибер Медиа разбирает, как работает «невидимое» вторжение, где оно оставляет следы и какие подходы позволяют его выявлять.

Содержание

Почему «файлов нет», а проблемы есть

Классическая ИБ-атака строится вокруг вредоносного файла: он попадает на диск, после чего его выявляют по сигнатуре или в песочнице. Сегодня эта модель устаревает. Все чаще злоумышленники работают без записи на накопитель.

Бесфайловые атаки выполняются в оперативной памяти или через легитимные системные инструменты. Нет файла — нет сигнатуры. При этом большинство средств защиты исторически ориентированы на контроль диска, а активность в RAM для них остается «белым шумом». В результате атака маскируется под штатные процессы — от сессии PowerShell до обновлений политик.

Концепция Living off the Land (атака с использованием легитимных инструментов и функций системы) стала стандартом для APT-группировок:

доверенные утилиты (PowerShell, WMI) нельзя просто заблокировать;
песочницы эффективны против файлов, но не против кода в памяти;
атакующим не нужны сложные обходы — достаточно скриптов;
вредоносная активность теряется среди легитимных процессов.

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

Как начинается «невидимое» вторжение

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

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

Константин Маслов

Эксперт по информационной безопасности, «Инфосистемы Джет»

В современных бесфайловых атаках (fileless attacks) злоумышленники избегают записи вредоносных файлов на диск, что позволяет обойти сигнатурные средства защиты. Первоначальное проникновение чаще всего происходит через следующие сценарии:

Фишинговые письма со скриптами. Жертве присылают документы с макросами или LNK-файлами вызывающими скрипт, который загружает полезную нагрузку в оперативную память.

Эксплуатация веб-уязвимостей. Использование инъекций или RCE для загрузки веб-шеллов и выполнения кода через легитимные процессы ОС.

Социальная инженерия. Манипуляции, например, вынуждающие пользователя скопировать и запустить опасный скрипт в консоли (ClickFix).

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

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

PowerShell как инструмент атаки: техники обхода защиты

PowerShell и WMI (инструменты управления Windows) — это фундамент автоматизации в Windows, который в руках злоумышленников превращается в мощное оружие. Основная проблема заключается в том, что эти инструменты имеют глубокий доступ к API (интерфейс программирования приложений) операционной системы и могут выполнять практически любые действия: от извлечения учетных данных из памяти до управления процессами. В бесфайловых сценариях PowerShell используется как «загрузчик», который загружает вредоносный код напрямую в память, делая атаку невидимой для классического антивируса.

Для борьбы с такими угрозами Microsoft внедрила AMSI (интерфейс проверки на наличие вредоносных программ). Он позволяет антивирусному ПО проверять содержимое скриптов непосредственно перед их исполнением, даже если они были зашифрованы или обфусцированы. Однако защитники и атакующие ведут постоянную «гонку вооружений»: как только AMSI научился эффективно распознавать вредоносные конструкции, появились методы, позволяющие ослепить этот механизм контроля.

Сергей Сидорин

Руководитель направления мониторинга и реагирования IZ:SOC «Информзащита»

Большинство актуальных техник обхода атакуют одну точку — функцию AmsiScanBuffer() в amsi.dll. Самый распространенный подход — это патчинг в памяти. Атакующий через .NET reflection или прямой вызов API находит AmsiScanBuffer() и перезаписывает ее первые байты так, чтобы она всегда возвращала AMSI_RESULT_CLEAN. Вариаций этого приема существует несколько десятков с разными способами найти адрес функции и разными патчами. Microsoft регулярно добавляет сигнатуры для детектирования — атакующие каждый раз чуть модифицируют код. Исследователи CrowdStrike на Black Hat MEA 2023 описали patchless-вариант через VEH (Vectored Exception Handler), который не трогает код amsi.dll напрямую и потому сложнее детектируется традиционными методами.

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

Отдельная линия — изменение amsi.dll, чтобы отключить или исказить проверку. Наконец, широко используются living-off-the-land bypass — использование легитимных инструментов, среди которых rundll32, mshta или regsvr32.

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

Александр Перевалов

Эксперт по информационной безопасности, «Инфосистемы Джет»

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

К счастью, в экосистеме Windows имеется множество различных средств, которые позволяют осуществить процесс настройки политик максимально «безболезненно» и гибко. Один из таких механизмов, который целесообразно внедрять — это WDAC (функция защиты от вредоносных программ) в режиме аудита. В результате настройки этой системы сотрудники все еще смогут пользоваться PowerShell без принудительных блокировок, но WDAC при этом будет формировать события «Это действие должно было быть заблокировано вашей политикой безопасности».

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

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

Жизнь в оперативной памяти: инъекции и скрытность

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

Александр Боярский

Директор по развитию SOC в К2 Кибербезопасность

Сегодня редко кто занимается постоянным анализом памяти на хосте — это слишком ресурсоемко и дает много шума. Вместо этого используют поведенческий подход. Сначала фиксируются аномальные действия, например, нетипичный запуск PowerShell или rundll32, странные аргументы командной строки, необычные цепочки «родитель-дочерний процесс». Уже после этого внимание переключается на конкретный процесс и его состояние в памяти. Дальше смотрят на признаки, характерные для инъекций и выполнения кода напрямую в памяти, без привычного файлового следа. За счет того, что такие проверки выполняются точечно, а не постоянно, удается сохранить производительность системы и при этом уверенно выявлять бесфайловые атаки.

Одной из наиболее продвинутых техник является Reflective DLL Injection (техника внедрения динамических библиотек). В отличие от стандартной загрузки библиотек, этот метод позволяет подгрузить DLL в память процесса напрямую, минуя системный загрузчик Windows. Код сам заботится о своем размещении и настройке связей в RAM, не обращаясь к API, которые обычно мониторят защитные решения. В результате вредоносная библиотека никогда не касается диска, что делает ее невидимой для большинства антивирусных сканеров и систем контроля целостности файлов.

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

Иван Трофименко

Эксперт по информационной безопасности, «Инфосистемы Джет»

На сегодняшний день оптимальный баланс дает комбинированный подход к мониторингу событий в системе: контроль создания удаленных потоков, контроль записи напрямую в память другого процесса, контроль аномалий в модулях ядра. Такой подход легче для системы, чем постоянное сканирование всех областей оперативной памяти, особенно в связке с точечными YARA/сигнатурными проверками и поведенческой корреляцией.

Для Windows систем хорошо работают решения класса EDR. Они сочетают настроенную конфигурацию для сбора системных событий встроенными средствами, такими, как, Sysmon и ETW.

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

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

Инфраструктурный след: логирование и мониторинг

Бесфайловые атаки сложно заметить в моменте, но они неизбежно оставляют цифровые следы в системных журналах. Проблема большинства компаний не в отсутствии инструментов, а в избытке «шума» или, наоборот, в слишком экономных настройках аудита. Чтобы SIEM могла восстановить цепочку атаки, ей нужны сырые данные о запуске процессов, изменениях в реестре и сетевых соединениях, которые инициируют штатные утилиты.

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

Журналы PowerShell (Event ID 4104). Регистрация содержимого всех блоков кода, что позволяет увидеть реальные команды даже после деобфускации.
События Sysmon. Особенно важны Event ID 1 (создание процесса с командной строкой), ID 7 (загрузка модулей/DLL) и ID 10 (доступ к памяти других процессов).
Аудит командной строки (Event ID 4688). Фиксация всех аргументов, с которыми запускаются системные программы.
WMI-логи. Мониторинг создания постоянных подписок, которые часто используются для закрепления в системе.

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

Артем Семагин

Эксперт по информационной безопасности, «Инфосистемы Джет»

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

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

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

Детектирование через SIEM

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

Эффективность обнаружения атак типа Living off the Land напрямую зависит от качества написанных правил корреляции. Одиночное событие — например, запуск certutil.exe — встречается в системе постоянно. Но если эта утилита внезапно начинает скачивать файл из интернета, а следом за ней активируется PowerShell с обфусцированной командной строкой, вероятность инцидента стремится к 100%. Сложность заключается в том, чтобы настроить эти фильтры достаточно тонко, минимизировав количество ложноположительных срабатываний.

Даниил Кирьяков

Эксперт по информационной безопасности, «Инфосистемы Джет»

Наиболее характерные индикаторы бесфайловой атаки для SIEM проявляются не в одном событии, а в устойчивой корреляции нескольких источников логирования: связка инъекций в память легитимных процессов с последующим запуском PowerShell, WMI или других системных интерпретаторов и механизмов выполнения кода. Для примера можно выделить цепочку событий: Sysmon Event ID 8 и 10, которые фиксируют CreateRemoteThread и доступ одного процесса к памяти другого, с последующим PowerShell Event ID 4104, где видны обфусцированные или Base64-команды.

Такая корреляция часто указывает на исполнение кода напрямую в памяти. Существенным маркером также является сочетание сетевых соединений с неизвестными внешними адресами и запуска LOLBins-инструментов, таких как mshta, rundll32, regsvr32 и другие.

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

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

Заключение

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

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