Саурабх Шарма Введение В 2024 году мы вкратце рассказывали о сложной кампании кибершпионажа, получившей название PassiveNeuron. Цель кампании заключалась в компрометации серверов правительственных организаций с помощью ранее неизвестных APT‑имплантов, получивших названия Neursite и NeuralExecutor. Однако тогда нам не удалось установить многие ключевые детали кампании PassiveNeuron — в частности, оставалось неизвестным, каким образом упомянутые импланты развертывались и кто именно стоял за этой операцией. После того как мы обнаружили эту кампанию и остановили ее распространение в июне 2024 года, в течение примерно полугода мы не фиксировали новых развертываний вредоносных компонентов, связанных с PassiveNeuron. Однако в декабре 2024 года наше внимание привлекла новая волна заражений, связанная с PassiveNeuron, при этом самые последние инциденты датировались августом 2025 года. Атаки затронули правительственные, финансовые и промышленные организации в Азии, Африке и Латинской Америке. После выявления этих случаев нам удалось пролить свет на многие ранее неизвестные аспекты кампании — в частности, определить порядок первоначального заражения и сделать предположения об атрибуции. SQL-серверы под ударом Расследуя заражения PassiveNeuron в 2024 и 2025 годах, мы отметили, что подавляющее большинство затронутых машин работало под управлением ОС Windows Server. В частности, в одном из случаев злоумышленники смогли удаленно выполнять команды на скомпрометированном сервере через программное обеспечение Microsoft SQL. Нам неизвестно, как именно происходила эксплуатация SQL-решения, но типовые способы компрометации SQL-серверов таковы: эксплуатация уязвимостей в самом серверном ПО; эксплуатация уязвимостей, позволяющих выполнить SQL-инъекции, в приложениях, работающих на сервере; получение доступа к учетной записи администратора базы данных (например, методом перебора паролей) и выполнение вредоносных SQL-запросов с администраторскими привилегиями. Получив возможность выполнения кода через ПО SQL, атакующие начали развертывание веб-шелла на основе ASPX для выполнения базовых вредоносных команд на скомпрометированной машине. Однако злоумышленникам не удалось реализовать этот этап так, как они планировали: установленные в системе решения «Лаборатории Касперского» заблокировали попытки развертывания веб-шелла, а процесс его установки в итоге оставил множество следов. Чтобы попытаться скрыть веб-шелл от средств защиты, злоумышленники организовали установку в следующем порядке: Сохранение в системе файла с веб-шеллом, закодированным по алгоритму Base64. Внедрение PowerShell-скрипта, отвечающего за декодирование указанного файла по алгоритму Base64. Запуск PowerShell-скрипта для сохранения в системе декодированной полезной нагрузки в виде веб-шелла. Поскольку решения «Лаборатории Касперского» препятствовали завершению установки, злоумышленники несколько раз повторяли описанные шаги с незначительными модификациями, в частности: применяли шестнадцатеричное кодирование веб-шелла вместо Base64; использовали VBS-скрипт вместо PowerShell-скрипта для декодирования; записывали содержимое скрипта построчно. Атакующим так и не удалось внедрить веб‑шелл, и тогда они перешли к использованию более сложных вредоносных имплантов, чтобы продолжить процесс компрометации. Вредоносные импланты За последние два года в инцидентах, связанных с PassiveNeuron, мы наблюдали три импланта: Neursite — кастомизированный модульный бэкдор, написанный на C++ и предназначенный для кибершпионажа; NeuralExecutor — кастомизированный .NET‑имплант, позволяющий выполнять дополнительные полезные нагрузки, написанные на .NET; фреймворк Cobalt Strike — коммерческий инструмент для редтиминга. Согласно нашим наблюдениям, в атакуемых системах развертывались различные сочетания этих имплантов, при этом в подавляющем большинстве случаев их загружали посредством цепочки DLL‑загрузчиков. В этой цепочке загрузчиком первого этапа выступает DLL-файл, размещенный в системном каталоге. Ниже приведены некоторые пути таких библиотек: C:\Windows\System32\wlbsctrl.dll; C:\Windows\System32\TSMSISrv.dll; C:\Windows\System32\oci.dll. Пути для сохранения библиотек выбраны неслучайно: подобное именование DLL‑файлов и их размещение в каталоге System32 позволяют обеспечить автоматическое закрепление в системе. Если эти библиотеки присутствуют в файловой системе, они будут автоматически загружаться вместе с системой ( техника подмены отсутствующих DLL ). Первые две DLL загружаются в процесс svchost.exe, а последняя — в процесс msdtc.exe. Также стоит отметить, что эти DLL‑файлы имеют размер более 100 МБ, — злоумышленники искусственно увеличили размер библиотек путем дописывания в конец файла мусорных байтов. Обычно это делается, чтобы затруднить детектирование вредоносных имплантов защитными решениями. При запуске DLL‑загрузчики первого этапа перебирают список установленных сетевых адаптеров и вычисляют 32‑битный хэш MAC‑адреса каждого из них. Если ни одно из вычисленных значений не совпадает с тем, которое указано в конфигурации загрузчика, тогда он завершает выполнение. Проверка по MAC‑адресу предназначена для того, чтобы эти DLL‑файлы запускались исключительно в системе выбранной жертвы, а не, например, в среде песочницы. Подобная точность в отсеивании потенциальных жертв указывает на интерес злоумышленников к конкретным организациям и подчеркивает целевой характер этой угрозы. Как только загрузчик подтверждает, что выполняется в целевой системе, он продолжает работу, загружая DLL второго этапа, хранящуюся на диске. Пути сохранения и имена DLL‑загрузчиков второго этапа различались между машинами (например, elscorewmyc.dll и wellgwlserejzuai.dll). Размер DLL второго этапа также был искусственно увеличен и составлял более 60 МБ. Их задачей было открыть текстовый файл, содержащий загрузчик третьего этапа, закодированный по алгоритму Base64 и зашифрованный с использованием AES, а затем запустить этот загрузчик. Фрагмент содержимого файла полезной нагрузки Эта полезная нагрузка также представляет собой DLL‑файл, отвечающий за выполнение шелл‑кода четвертого этапа внутри другого процесса (например, WmiPrvSE.exe или msiexec.exe), создаваемого в приостановленном режиме. Далее этот шелл‑код загружает конечную полезную нагрузку — PE‑файл, преобразованный в кастомный исполняемый формат. В итоге процесс загрузки конечной полезной нагрузки можно представить следующей схемой: Загрузка конечной полезной нагрузки В некоторых целевых организациях злоумышленники использовали слегка модифицированные варианты схемы загрузки. Например, в отдельных случаях полезная нагрузка не внедрялась в другой процесс, а также иногда сохраненные на диске DLL-файлы были обфусцированы с помощью VMProtect. Бэкдор Neursite Из трех упомянутых разновидностей имплантов, которые могли содержаться в конечной полезной нагрузке, самым многофункциональным является Neursite. Мы дали ему это название, опираясь на путь к исходному коду, найденный в обнаруженных образцах, — E:\pro\code\Neursite\client_server\nonspec\mbedtls\library\ssl_srv.c. Конфигурация этого импланта содержит следующие параметры: список командных серверов с указанием портов; список HTTP-прокси-серверов, через которые можно подключиться к командным серверам; список HTTP-заголовков, используемых для подключения к командным HTTP-серверам; относительный URL-адрес, используемый для обмена данными с командными HTTP-серверами; диапазон времени ожидания между двумя последовательными подключениями к командному серверу; байтовый массив с часами и днями недели, в которые должен работать бэкдор; порт, который должен быть открыт для ожидания входящих соединений (опционально). Имплант Neursite поддерживает обмен данными с командным сервером по протоколам TCP, SSL, HTTP и HTTPS. Как следует из описания параметров конфигурации, Neursite может подключаться к командному серверу напрямую или ожидать входящего соединения на заранее указанном порте. В проанализированных нами случаях конфигурации образцов Neursite подразумевали применение либо внешних серверов, либо скомпрометированной внутренней инфраструктуры для коммуникации с командным сервером. Стандартный набор команд, реализованный в этом бэкдоре, позволяет злоумышленникам: собирать информацию о системе; управлять запущенными процессами; проксировать трафик через другие зараженные компьютеры с имплантом Neursite для дальнейшего горизонтального перемещения. Кроме того, имплант содержит компонент для загрузки вспомогательных плагинов. В рассмотренных нами случаях атакующие развертывали плагины со следующими возможностями: выполнение команд терминала; операции с TCP‑сокетами. Загрузчик NeuralExecutor NeuralExecutor — еще один кастомизированный имплант, который внедрялся в ходе кампании PassiveNeuron. Он разработан на платформе .NET. Попавшие к нам образцы этого импланта были защищены от анализа с помощью ConfuserEx, обфускатора с открытым исходным кодом. В импланте реализовано несколько методов сетевого взаимодействия: связь по TCP, HTTP/HTTPS и WebSocket, а также через именованные каналы. После установления канала связи с командным сервером бэкдор может принимать команды и загружать .NET‑сборки. Другими словами, основная функциональность импланта заключается в возможности загружать из сети и выполнять дополнительные полезные нагрузки на базе .NET. Сложности атрибуции Оба кастомизированных импланта, которые применялись в кампании PassiveNeuron, — Neursite и NeuralExecutor — ранее не встречались в других атаках. Поэтому нам были нужны дополнительные улики, чтобы понять, кто стоит за кампанией PassiveNeuron. Еще в 2024 году, когда мы впервые начали расследование PassiveNeuron, мы натолкнулись на очевидную (даже слишком) подсказку: Имена функций, обнаруженные внутри NeuralExecutor В коде образцов NeuralExecutor, проанализированных нами в 2024 году, имена всех функций были заменены строками с русскоязычным префиксом «Супер обфускатор». Важно отметить, что эта строка была намеренно добавлена злоумышленниками при использовании обфускатора ConfuserEx. Конечно, нельзя преждевременно делать какие-либо выводы на основе строк, специально оставленных внутри вредоносного кода. Киберпреступники могут целенаправленно вставлять строки на языках, на которых они не говорят, чтобы запутать исследователей и специалистов по реагированию на инциденты, а также усложнить атрибуцию угрозы. По этой причине в 2024 году мы сочли строку «Супер обфускатор» сомнительной уликой. После анализа образцов NeuralExecutor, собранных в 2025 году, мы заметили, что русскоязычная строка исчезла. Однако появилась другая примечательная улика, связанная с этим имплантом. Образцы 2024 года извлекали адреса командных серверов напрямую из конфигурации, тогда как версии 2025 года использовали технику dead drop resolver . В частности, новые образцы NeuralExecutor загружали содержимое файла из репозитория на GitHub и извлекали из него строку: Содержимое файла конфигурации из репозитория на GitHub Чтобы найти нужную строку, вредоносная программа ищет два разделителя — wtyyvZQY и stU7BU0R, — обозначающие начало и конец конфигурационных данных. Байты этой строки затем декодируются по алгоритму Base64 и расшифровываются с помощью алгоритма AES для получения адреса командного сервера. Фрагмент конфигурации импланта Этот метод получения адресов командных серверов из файлов на GitHub, когда искомая строка заключена в специальные последовательности символов, которые выполняют роль разделителей, широко используется китаеязычными атакующими. Например, такой прием часто применялся в кампании EastWind , которая, как мы установили ранее, связана с китаеязычными группами APT31 и APT27. Также в ходе расследования мы выявили еще один интересный факт, который может быть полезен для атрибуции. Мы наблюдали многочисленные попытки развертывания загрузчика PassiveNeuron в одной из организаций. Нам удалось отразить все попытки атак, при этом в ходе одной из них мы обнаружили вредоносную библиотеку с именем imjp14k.dll. Проанализировав эту DLL, мы нашли следующий путь к PDB‑файлу: G:\Bee\Tree(pmrc)\Src\Dll_3F_imjp14k\Release\Dll.pdb. Эта строка упоминалась в отчете Cisco Talos , освещавшем активность, предположительно связанную с группой APT41. Кроме того, мы установили, что вредоносное поведение обнаруженной DLL соответствует описанному в отчете Cisco Talos. Однако непонятно, зачем она была загружена на целевую машину. Возможно, злоумышленники развернули ее в качестве замены основным имплантам PassiveNeuron либо она осталась от других злоумышленников, которые одновременно с организаторами кампании PassiveNeuron скомпрометировали системы этой организации. Если злоумышленники активно пытаются замаскировать происхождение своих атак, бывает сложно, а порой и невозможно отличить подлинные индикаторы от ложных. Тем не менее в целом тактики, техники и процедуры (TTP), наблюдаемые в кампании PassiveNeuron, наиболее схожи с активностью китаеязычных групп. Поскольку TTP обычно сложнее подделать, чем отдельные индикаторы, такие как строки, мы на данный момент приписываем кампанию PassiveNeuron китаеязычной группе, хотя и с низкой степенью уверенности. Заключение Отличительной особенностью кампании PassiveNeuron является то, что она была преимущественно нацелена на серверные системы. Такие серверы, особенно доступные из интернета, часто привлекают внимание APT-групп, поскольку служат точками входа в целевые организации. Это подчеркивает важность надлежащей защиты серверной инфраструктуры . По возможности поверхность атаки на такие системы должна быть сведена к минимуму. Также необходимо организовать постоянный мониторинг всех серверных приложений, чтобы своевременно обнаруживать и предотвращать заражения на ранних этапах. Особое внимание следует уделять защите приложений от SQL-инъекций, с помощью которых злоумышленникам нередко удается получить первоначальный доступ. Кроме того, рекомендуется предусмотреть защиту от развертывания веб-шеллов, используемых для компрометации серверов. Индикаторы компрометации Source: https://securelist.ru/passiveneuron-campaign-with-apt-implants-and-cobalt-strike/113810/