UDV Group: как злоумышленники скрываются в инфраструктуре

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, мелким аномалиям, которые раньше казались шумом. Чем лучше команды понимают свой технологический ландшафт, тем меньше пространства остается для скрытых входов. В итоге побеждает тот, кто знает свою инфраструктуру глубже, чем злоумышленник, пытающийся в ней спрятаться.

Источник: