Маяки и временные проверки: как вредоносное ПО ускользает от анализа

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

Ключевые наблюдения

• Вредоносное ПО выполняет временные проверки окружения через системный вызов sys_rt_sigtimedwait, чтобы определить, находится ли оно в изолированной (sandbox) среде.
• После прохождения проверки запускается процедура «регистрации» — функция с меткой FUN_004013c6 отправляет HTTP GET-запрос на конечную точку C2.
• Другая проанализированная функция, переименованная в ping_cnc (ранее FUN_004014e2), регулярно посылает запросы на сервер C2 каждые 5 минут в течение 48 часов.
• Архитектура вредоносного ПО в рассматриваемом варианте реализует прежде всего маяки (beacons) и не содержит дополнительных бэкдор‑возможностей — очевидная тактика снижения вероятности обнаружения.

Что означает такое поведение

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

Последовательные пинги с интервалом в 5 минут в течение 48 часов позволяют оператору:

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

Индикаторы компрометации (IOCs) и сигнатуры для мониторинга

• Необычные вызовы или высокая частота использования системного вызова sys_rt_sigtimedwait в процессах, которые не должны выполнять такие операции.
• Исходящие HTTP GET‑запросы с нестандартными параметрами на неизвестные/подозрительные конечные точки — особенно на раннем этапе жизни процесса.
• Повторяющиеся периодические соединения с одинаковым интервалом (~5 минут) от одного и того же хоста в течение длительного периода (~48 часов).
• Процессы с минимальной функциональностью, ограниченные только до beacon‑поведения без явных дополнительных модулей бэкдора.

Рекомендации по защите и обнаружению

• Внедрить egress‑фильтрацию и контроль исходящего трафика: ограничить доступ к внешним HTTP(S)‑эндпоинтам и использовать прокси с проверкой репутации доменов и IP.
• Наладить мониторинг поведенческих индикаторов на уровне эндпоинта: отслеживать необычную последовательность системных вызовов и периодические сетевые соединения с фиксированными интервалами.
• Усилить телеметрию в песочницах: эмуляция реального времени и сети (time acceleration, network simulation) поможет обнаружить вредоносные образцы, которые используют временные проверки.
• Развернуть EDR‑решения с возможностью обнаружения фаз «регистрации» и beacon‑поведения, а также механизмов блокировки подозрительных исходящих запросов.
• Провести анализ аномалий трафика на шлюзах и прокси с целью выявления повторяющихся GET‑запросов и паттернов beacon.

Вывод

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

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

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.