Модульные бэкдоры: как злоумышленники скрываются в инфраструктуре

23.01.2026

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

Автор

Backdoor-механизмы сегодня это тонкие, адаптивные скрытые входы, которые могут прятаться в облачных сервисах, CI/CD-процессах и даже в штатных инструментах ОС. Cyber Media разбирает, как эволюционируют бэкдоры, какие техники используют злоумышленники и почему их обнаружение становится все сложнее.

Содержание

Что такое backdoor

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

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

Почему бэкдоры становятся более специализированными и модульными? Потому что универсальные инструменты давно перестали работать. Современные системы логирования ловят аномальные процессы, EDR умеет анализировать поведение, а DevSecOps-пайплайны стали куда жестче к «левой» активности. Поэтому злоумышленники переходят к минималистичным, почти хирургическим бэкдорам: один выполняет только команду запуска нужного процесса, другой отвечает за связь с C2, третий — маскируется под сервис мониторинга. Вместе они создают модульную экосистему, которую сложно заметить и еще сложнее собрать в единую картину угрозы.

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

Классические и современные типы бэкдоров

Когда-то все было просто: бэкдор — это отдельный файл, спрятанный в системе. Скомпилированный бинарь в /tmp, подозрительный PHP-скрипт в каталоге веб-сервера, измененный SSH-дев — классика жанра. Их находили так же просто: антивирус ругался на сигнатуру, SOC замечал подозрительный хэш, а администратор — странный файл, которого «точно не было вчера».

Но времена файловых закладок уходят, как и романтика поиска «того самого» исполняемого файла. Технические команды стали создавать многоступенчатые журналы, EDR научился видеть лишние процессы, а контейнеризация убрала часть старых укрытий. И злоумышленники адаптировались.

Дмитрий Калинин

Руководитель департамента по работе с уязвимостями и инцидентами ИБ Бастион

Наиболее опасными признаны аппаратные бэкдоры, которые вшиваются в BIOS|UEFI или прошивки какого-либо оборудования. Их практически невозможно обнаружить, они не оставляют в логах никаких следов. Опасность таких бэкдоров в том, что они могут доставляться по схеме Supply Chain, т. е. при атаке на поставщика. На втором месте по опасности и незаметности стоит отметить бэкдоры, встраиваемые в компоненты системы. Не так давно появилась информация о таком бэкдоре для системы Linux — Plague, который маскируется под легитимный модуль PAM, отвечающий за аутентификацию пользователей. В результате Plague позволяет обходить системную аутентификацию, а также перехватывать логины и пароли пользователей.

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

Fileless-механики, которые живут в PowerShell, WMI, cron или systemd-юнитах.
Маскировка под сервисы, когда закладка выглядит как обычный health-check или мониторинговый агент.
Инъекция в доверенные процессы, чтобы выглядеть как часть самой системы.
Зависимость или артефакт CI/CD, попадающий в прод через цепочку сборки.

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

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

Маскировка под легитимность: облака, микросервисы и API

Современные бэкдоры больше не прячутся в тени — они прикидываются частью нормальной инфраструктуры. И делают это так правдоподобно, что на них легко махнуть рукой: «да это же что-то из DevOps оставили». Злоумышленники отлично понимают, что облака и микросервисы перегружены легитимным шумом, и именно этот шум стал идеальной средой для сокрытия закладок.

Как злоумышленники используют популярные облачные платформы

Облачные провайдеры давно превратились в универсальную транспортную прослойку. Злоумышленники пользуются этим не хуже инженеров:

запускают командные серверы в serverless-функциях, которые выглядят как обычные обработчики событий;
прячут C2-трафик за CloudFront / CDN, маскируя его под доставку статического контента;
используют обычные storage-бакеты как каналы обмена командами — «положи файл, забери команду»;
маскируют управление доступом под IAM-ролями, созданными «для тестирования» или «для мониторинга».

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

Имитация микросервисной коммуникации, ложные health-checkи и подмена метрик

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

Олег Скулкин

Руководитель BI.ZONE Threat Intelligence

Нередко киберпреступники маскируют свое вредоносное ПО под вполне легитимные исполняемые файлы. В частности, они могут выдавать вредоносный компонент за официальный бинарный файл облачного сервиса. Например, кластер Core Werewolf называл вредоносные файлы как OneDrive.exe и использовал такую же иконку приложения. Кроме того, атакующие активно используют облачные платформы для доставки вредоносных программ, хранения похищенной информации и организации каналов управления. Так, кластер Fair Werewolf применял в ВПО для связи с управляющими серверами такие сервисы, как Yandex Cloud, Microsoft Graph и Dropbox. Что касается микросервисов, то встречались случаи, когда вредоносные компоненты закреплялись внутри Docker-контейнеров, что усложняло их обнаружение.

Самые популярные техники:

Имитация service-to-service вызовов. Закладка общается с C2 так же, как микросервисы между собой — через внутренний API-шлюз или service mesh. На графах это выглядит как еще один «малозаметный» сервис.
Фальшивые health-checkи. Бэкдор отправляет регулярные проверки состояния, которые никто не анализирует вручную. На самом деле эти проверки включают команды или передают данные.
Подмена метрик и логов. Закладка пишет в Prometheus или ELK как «обычный компонент», но часть метрик используется как скрытый канал. Например, увеличение «времени отклика» может быть сигналом C2.

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

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

Supply chain и CI/CD: внедрение бэкдоров на этапе разработки

Атаки на цепочки поставок стали способом проникновения еще до того, как продукт вообще попадет в прод. Вместо того чтобы ломиться через периметр, злоумышленники заходят в самое сердце разработки — в зависимости, скрипты сборки, артефактные репозитории и автоматические обновления. CI/CD дает им идеальную среду: все, что прошло через пайплайн, автоматически считается «чистым». Этим и пользуются.

Олег Скулкин

Руководитель BI.ZONE Threat Intelligence

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

Аналогично компрометация CI/CD-пайплайна позволяет злоумышленнику встроить вредоносный код прямо в процесс сборки. Отдельная зона риска — подготовка контейнерных образов: изменения в базовом образе или на стадии build могут распространиться на все последующие версии продукта.

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

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

Fileless-бэкдоры: когда искать нечего

Безфайловые бэкдоры — это та категория угроз, которая вызывает у аналитиков особое раздражение. С ними буквально нечего искать: ни бинарей, ни подозрительных скриптов, ни артефактов на диске. Все живет в оперативной памяти или в штатных механизмах системы, которые и так работают 24/7. Такие закладки похожи на арендатора, который использует вашу мебель, вашу посуду и ваши ключи — и поэтому остается практически невидимым.

Злоумышленники давно поняли, что проще не добавлять что-то свое, а переиспользовать то, что уже встроено в систему. Поэтому в ход идут PowerShell, WMI, планировщики задач, системные демоны и любые средства автоматизации, которые принято считать «нормальными» и не требующими лишнего внимания.

Ольга Луценко

Консультант по информационной безопасности UDV Group

Основной метод поиска таких бэкдоров — поведенческий анализ и поиск аномалий, поскольку сигнатурные способы в данном случае неэффективны:

Мониторинг цепочек выполнения процессов. Осуществляется с использованием EDR-систем. Ключевые индикаторы: запуск powershell.exe или cscript.exe из офисных приложений или почтовых клиентов; использование системных утилит для сетевой активности.

Анализ сетевой активности. Необходимо выявлять аномальные соединения для легитимных процессов. Например, установка внешних соединений служебными процессами вроде svchost.exe или msdtc.exe. Для полного анализа требуется инспектирование TLS-трафика для верификации содержимого соединений с внешними сервисами.

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

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

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

Вторичные и «резервные» бэкдоры: план B злоумышленника

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

Такие резервные механизмы обычно устроены так, чтобы полностью раствориться в инфраструктуре и не подавать признаков жизни. Они не общаются с C2 постоянно, не держат сетевые соединения и не делают ничего, что могло бы вызвать тревогу SOC. Работают они только по сигналу — или по заранее предусмотренному условию, которое почти невозможно заметить без глубокого поведенческого анализа.

Ольга Луценко

Консультант по информационной безопасности UDV Group

Речь идет о механизмах обеспечения персистентности. Они крайне разнообразны и часто остаются нетронутыми после первичного реагирования:

Дополнительные учетные данные. Злоумышленник заранее создает резервные наборы учетных данных (логины/пароли, сертификаты, API-ключи) и размещает их в различных частях системы. Обнаружение и удаление одного бэкдора не гарантирует устранения всех методов доступа.

Персистентность через подписки на события. Например, настройка подписки Windows Event Forwarding для выполнения скрипта при определенном событии, например, вход пользователя. Это не требует изменения файлов на диске и сложно для детектирования.

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

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

Компрометация резервных копий. Внедрение вредоносного кода в образы резервных копий. Процедура восстановления системы из такой резервной копии приводит к повторному заражению.

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

Как защититься: рекомендации для SOC, разработчиков и облачных команд

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

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

Укрепить защиту помогают такие практики:

Регулярный аудит и контроль целостности. Проверка конфигов, артефактов, зависимостей и контейнеров, автоматическое сравнение с эталонами, верификация хэшей и проверка подписей.
Логирование и мониторинг CI/CD. Фиксация всех шагов сборки, отслеживание изменений в pipeline, контроль «всплывающих» шагов, проверка прав сервис-аккаунтов, логирование всех операций в registry.
Отслеживание аномалий микросервисной коммуникации. Неожиданные сервис-to-service вызовы, нестандартные health-check, странные всплески внутренних API — все это признаки потенциальных скрытых каналов.
Периодический threat hunting на «скрытые входы». Поиск старых cron-заданий, забытых сервисных аккаунтов, странных systemd-юнитов, неактивных или редко вызываемых серверлес-функций, подозрительных IAM-ролей и любых механизмов, которые могут быть резервным бэкдором.

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

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

Заключение

Бэкдоры больше не выглядят как один спрятанный файл — они становятся распределенными, модульными и удивительно «естественными» для инфраструктуры. Именно поэтому защита от них требует не только инструментов, но и внимательности к деталям: поведения сервисов, изменениям в CI/CD, мелким аномалиям, которые раньше казались шумом. Чем лучше команды понимают свой технологический ландшафт, тем меньше пространства остается для скрытых входов. В итоге побеждает тот, кто знает свою инфраструктуру глубже, чем злоумышленник, пытающийся в ней спрятаться.