Анализ VBS-версии трояна WSHRAT выявил сложную цепочку бесфайлового внедрения и проблемы лабораторной маршрутизации

remote access Trojan

Исследование варианта известного трояна удалённого доступа WSHRAT (Houdini), написанного на VBScript, столкнулось с неожиданными препятствиями. Вместо стандартного выполнения полезной нагрузки вредоносная программа продемонстрировала синхронный цикл ожидания команд, а также обнаружила уязвимость в настройке виртуальной сети лаборатории. Этот случай представляет интерес для специалистов по анализу вредоносного кода и инженеров по реагированию на инциденты, так как наглядно показывает, как на первый взгляд второстепенные детали - такие как конфигурация DNS - могут полностью блокировать или искажать динамический анализ.

Описание

Исходный образец был получен из публичной базы вредоносных файлов MalwareBazaar. На этапе статического анализа, ещё до запуска, были обнаружены ключевые признаки небрежности автора. В начале скрипта, в комментарии, содержался псевдоним и контакт в Skype: recoder : kognito. Эта информация подтверждает, что угроза исходит от конкретного оператора, а не является массовой автоматической рассылкой. Дальнейший разбор кода показал развёрнутую цепочку действий. Вредоносная программа содержала функцию для опроса установленных антивирусных продуктов через WMI-запросы к пространству имён SecurityCenter2. Также была обнаружена функция faceMask, реализующая технику "бесфайлового" внедрения (fileless injection). Она предусматривала извлечение блоков Base64-кода, сохранение их в реестре Windows (ветка HKCU\SOFTWARE\Microsoft\mPluginC) и последующую рефлексивную загрузку через PowerShell в память легитимного процесса MSBuild.exe без записи на диск.

Для динамического анализа была развёрнута изолированная среда: хост-машина с Windows 10 и шлюз REMnux с запущенными INetSim (эмуляция сервисов) и Wireshark. После запуска VBS-файла ожидалось, что в журнале событий PowerShell появится запись (Event ID 4104) с командами внедрения. Однако вместо этого было зафиксировано выполнение штатных системных сценариев очистки диска. Бесфайловая инъекция не сработала. [Анализ] кода показал причину: WSHRAT является не дроппером, а бэкдором. Его логика построена на синхронном цикле while true. При запуске скрипт отправляет HTTP-POST запрос на сервер управления (snkcyp.duckdns.org) с вопросом "is-ready". Поскольку лаборатория была изолирована, запрос попадал в "заглушку" INetSim, которая возвращала стандартную страницу HTTP 200 OK. Вредоносная программа анализировала ответ, не находила в нём валидной команды и переходила в режим ожидания на пять секунд, после чего повторяла запрос. Именно поэтому PowerShell-инъекция оставалась неактивной - она запускалась только после получения прямой команды от оператора.

Второй проблемой стал сетевой "слепой" участок виртуальной маршрутизации. В конфигурации VMware по умолчанию виртуальный маршрутизатор (.254) выступает DNS-сервером для гостевой Windows (.128). Когда вредоносная программа пыталась разрешить домен C2 через unicast-запрос напрямую к маршрутизатору, этот трафик не проходил через анализатор REMnux (.129), так как тот находился на той же виртуальной сети, но не участвовал в процессе. Маршрутизатор не находил запись и просто отбрасывал запрос. В результате Wireshark на REMnux не фиксировал никаких DNS- или HTTP-соединений, хотя wscript.exe - скрытый процесс с флагом //B - уже работал из папки %appdata%\Roaming, куда вредонос скопировал себя и закрепился.

Исправление этой конфигурационной ошибки потребовало ручного переназначения предпочитаемого DNS-сервера в настройках IPv4 Windows на адрес REMnux (192.168.134.129). После сброса кэша DNS вредоносная программа, находившаяся в пятисекундном цикле ожидания, немедленно начала отправлять запросы. INetSim успешно перехватил DNS- и HTTP-биконы. Помимо основного C2-домена, были зафиксированы запросы к сервису ip-api.com - это подтвердило работу встроенной функции геолокации getCountry(), которая собирала данные о местоположении атакуемой машины.

Дополнительно статический анализ выявил возможность отключения контроля учётных записей (UAC) и защитника Windows путём изменения реестра, что требует повышенных привилегий. Ядро RAT функционирует как диспетчер команд: через коммутатор оператор может отдавать такие инструкции, как завершение процессов, загрузка дополнительных модулей или выполнение Shell-команд.

На заключительном этапе было разработано сигнатурное YARA-правило, нацеленное на строки авторства, домен C2 и ключи реестра, используемые для бесфайлового внедрения. Первоначальная компиляция выдала ошибку из-за неиспользуемой переменной - грубая, но типичная оплошность при написании правил обнаружения. После исправления YARA-сканер был запущен не на статическом файле, а на активном процессе wscript.exe (PID 8004). Результат подтвердил совпадения по всем трём искомым элементам: Skype-контакт, домен и команды PowerShell для подмены процесса. Это доказывает, что правило работоспособно для детектирования как на диске, так и в памяти.

Этот инцидент напоминает, что для точного анализа вредоносного ПО необходимо не только понимать его логику, но и тщательно проверять настройки лабораторной инфраструктуры. Ошибка в конфигурации DNS-маршрутизации привела к тому, что бэкдор оставался невидимым для инструментов мониторинга, хотя успешно функционировал. Кроме того, синхронный цикл ожидания команд от сервера отличает WSHRAT от обычных дропперов: он не самодостаточен, а является удалённым инструментом управления, который активирует опасные функции только по команде. Такой подход требует от аналитиков не только запуска образца, но и эмуляции командного сервера для полной проверки всей цепочки внедрения.

Индикаторы компрометации

Domain

  • snkcyp.duckdns.org

URL

  • http://snkcyp.duckdns.org:3369/is-ready

MD5

  • a1455a81d58689e88a962098e27bb004

SHA1

  • 4e756cdd328d705819da6cff1204c949110a60d2

SHA256

  • 207ac97e60aeb989a14feaae8a365f5b35233ac7800f1357b325a0bd8d3bdd5c

YARA

Комментарии: 0