API Hammering как способ избежать детектирования в песочнице

API Hammering как способ избежать детектирования в песочнице

API Hammering как способ избежать детектирования в песочнице

Исследователи из Palo Alto Networks обнаружили образцы вредоносов Zloader и BazarLoader, использующие необычные способы реализации механизма API Hammering (от hammer — стучать, долбить). Эта техника маскировки позволяет сдержать исполнение вредоносного кода в песочнице за счет многочисленных мусорных вызовов API-функций Windows: пока они обрабатываются, зловред спит, и его намерения неясны.

Чаще всего для выполнения операции сна в контролируемой среде вредоносы, со слов экспертов, используют API-функцию Sleep. Более изощренный способ самозащиты предполагает циклическую отсылку ICMP-пакетов на какой-нибудь IP. Отправка и получение этих бесполезных пингов требуют времени, и запуск вредоносных функций в итоге происходит с задержкой.

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

Загрузчик BazarLoader ранее с этой целью вызывал 1550 раз функцию printf. Новая версия, попавшая в поле зрения Palo Alto, использует длинный цикл обращений к произвольным ключам системного реестра (вполне легитимное поведение), который может повторяться произвольное число раз.

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

Исследователи подчеркивают, что на разных Windows-машинах число итераций маскировочного цикла и создаваемые списки ключей реестра неодинаковы — из-за разницы в версиях ОС, наборах установленных обновлений и содержимого папки System32. Механизм API Hammering встроен в упаковщик BazarLoader и тормозит, таким образом, распаковку полезной нагрузки.

Модульный троян Zloader применяет ту же технику обхода сэндбокса, но вместо длинных повторяющихся циклов использует четыре больших подпрограммы с вложенными вызовами множества мелких процедур. Последние при выполнении обращаются к Windows API (каждая вызывает по четыре функции — GetFileAttributesW, ReadFile, CreateFileW и WriteFile). В сумме количество вводящих в заблуждение вызовов, которые генерирует зловред, превышает 1 млн, при этом его поведение схоже с легитимной программой, выполняющей файловые операции ввода-вывода.

Windows 11 после обновления может отрезать вас от проводного интернета

Похоже, у сисадминов снова «праздник»: в сообществе r/sysadmin на площадке Reddit обсуждают баг апгрейдов Windows 11, из-за которого рабочие станции после обновления внезапно теряют проводную 802.1X-аутентификацию и остаются без Сети.

Сценарий звучит неприятно: обновляете машину «поверх» (например, с 23H2 на 25H2; люди пишут, что это повторяется и на ежегодных переходах), перезагружаетесь — и всё, Ethernet молчит.

Причина, согласно описанию участников обсуждения, в том, что после апгрейда папка dot3svc оказывается очищенной, а вместе с ней пропадают политики / профили, которые нужны Wired AutoConfig для 802.1X.

Wired AutoConfig (dot3svc) — это тот самый компонент Windows, который держит проводной 802.1X в рабочем состоянии. А его политики лежат как раз в директории C:\Windows\dot3svc\Policies (плюс есть папки для миграции во время апгрейда). И вот когда эти файлы исчезают / не мигрируют корректно, машина не может пройти 802.1X на коммутаторе и получить доступ к корпоративной сети.

Самое злое тут — эффект «замкнутого круга». Без сети устройство не может дотянуться до контроллеров домена, чтобы подтянуть Group Policy и восстановить настройки автоматически. Поэтому в полях лечат по старинке: подключают устройство в «открытый» порт без 802.1X, делают gpupdate /force (часто именно /target:computer), и только потом возвращают на защищённый порт.

Есть и ещё один баг: в отдельных кейсах при апгрейде люди жаловались на проблемы с машинными сертификатами, что особенно больно организациям на EAP-TLS (когда 802.1X завязан на PKI).

При этом самое обидное — на официальных страницах Windows Release Health для 24H2 и 25H2 упоминаний про 802.1X/dot3svc в списке известных проблем сейчас не видно.

Что с этим делать прямо сейчас, если вы планируете массовые апгрейды: многие админы советуют хотя бы заложить «страховку» в процесс — например, заранее сохранить содержимое C:\Windows\dot3svc\Policies и вернуть его после обновления, либо обеспечить доступ к сети через временно открытый порт, чтобы успеть прогнать gpupdate.

RSS: Новости на портале Anti-Malware.ru