В апреле 2025 года Microsoft исправила 121 уязвимость в своих продуктах. Среди них была CVE-2025-29824 — единственная из исправленных уязвимостей, которая, по данным компании, на тот момент уже активно использовалась злоумышленниками в реальных атаках. Эксплоит к этой уязвимости был внедрен вредоносным ПО PipeMagic. Она позволяла повышать привилегии в ОС Windows из-за ошибки в драйвере логирования clfs.sys. Аналитики Microsoft Threat Intelligence обнаружили эту уязвимость в ходе атак группировки Storm-2460 на компании, находящиеся в Саудовской Аравии, Испании, Венесуэле и США. С помощью CVE-2025-29824 атакующие повышали привилегии до NT AUTHORITY\SYSTEM для последующего бокового перемещения и шифрования файлов жертвы.
Эта статья — результат совместного исследования «Лаборатории Касперского» и BI.ZONE, в рамках которого специалисты «Лаборатории Касперского» проследили развитие PipeMagic — от первого обнаружения в 2022 году до новых инцидентов в 2025 году — и выявили ключевые изменения в тактиках операторов этого ПО. Эксперты BI.ZONE, в свою очередь, провели технический анализ самой уязвимости CVE-2025-29824.
Предыстория
PipeMagic — это бэкдор, впервые обнаруженный специалистами «Лаборатории Касперского» в декабре 2022 года при исследовании вредоносной кампании с участием RansomExx. Жертвами атаки стали промышленные компании в Юго-Восточной Азии. Загрузчик бэкдора представлял собой троянизированное приложение Rufus для форматирования USB-дисков, а сам PipeMagic поддерживал два режима работы — как полноценный бэкдор, предоставляющий удаленный доступ, и как сетевой шлюз — и обеспечивал исполнение широкого набора команд.
В октябре 2024 года организации в Саудовской Аравии столкнулись с новой волной атак PipeMagic. В данном случае в качестве приманки использовалось поддельное приложение-клиент для ChatGPT. Оно было написано на Rust и использовало фреймворки Tauri для отрисовки графических приложений и Tokio для асинхронного выполнения задач. Однако никакой полезной функциональности в нем не оказалось, и при запуске оно просто показывало пользователю пустой экран.
MD5 |
|
Имя файла |
|
Одновременно с этим приложение извлекало из своего кода зашифрованный по алгоритму AES массив размером 105 615 байт, расшифровывало и выполняло его. Результат представлял собой шелл-код, отвечающий за загрузку исполняемого файла. Для затруднения анализа злоумышленники использовали хеширование API-функций с помощью алгоритма FNV-1a, и шелл-код динамически разрешал их адреса через GetProcAddress. Далее происходило выделение памяти, релокация необходимых смещений в таблице импортов и, наконец, запуск точки входа бэкдора.
Одной из уникальных особенностей PipeMagic является генерация случайного массива длиной 16 байт, который используется для создания именованного канала в формате: \\.\pipe\1.<hex string>. После этого запускается поток, который постоянно создает этот канал, пытается прочитать из него данные и уничтожает. Такой способ коммуникации нужен бэкдору для передачи зашифрованной полезной нагрузки и уведомлений. При этом для взаимодействия с именованным каналом используется стандартный сетевой интерфейс с IP-адресом 127.0.0.1:8082.
Для скачивания модулей (PipeMagic обычно задействует несколько плагинов, скачиваемых с C2-сервера) злоумышленники использовали домен, размещенный у облачного провайдера Microsoft Azure, со следующим именем: hxxp://aaaaabbbbbbb.eastus.cloudapp.azure[.]com.
PipeMagic в 2025 году
В январе 2025 года «Лаборатория Касперского» обнаружила новые заражения в Саудовской Аравии и Бразилии. При дальнейшем исследовании было замечено обращение к домену hxxp://aaaaabbbbbbb.eastus.cloudapp.azure[.]com, который навел специалистов компании на мысль о связи этой атаки с PipeMagic. Позже был обнаружен и сам бэкдор.
Изначальный загрузчик
MD5 |
|
Имя файла |
|
В этой атаке в роли загрузчика выступал файл формата Microsoft Help Index File. Обычно в таких файлах находится код, который читает данные из файлов-контейнеров .mshc, содержащих справочные материалы Microsoft. В случае загрузчика при первом просмотре видно, что он содержит обфусцированный код на C# и очень длинную шестнадцатеричную строку. Пример запуска такой нагрузки:
c:\windows\system32\cmd.exe "/k c:\windows\microsoft.net\framework\v4.0.30319\msbuild.exe c:\windows\help\metafile.mshi"
metafile.mshiКод на C# используется для двух целей — расшифровки и исполнения шелл-кода, который зашифрован с помощью поточного алгоритма RC4 с ключом 4829468622e6b82ff056e3c945dd99c94a1f0264d980774828aadda326b775e5 (шестнадцатеричная строка). После расшифровки полученный шелл-код исполняется при помощи WinAPI EnumDeviceMonitor. В качестве третьего параметра передается указатель на функцию — и сюда подставляется указатель на расшифрованный шелл-код.
Внедренный шелл-код представляет собой исполняемый код для 32-битных систем Windows. Он загружает незашифрованный исполняемый файл, который находится внутри шелл-кода. Для динамического получения адресов системных API, как и в версии 2024 года, используется парсинг таблицы экспортов и хеширование FNV-1a.
Загрузчик (ChatGPT)
MD5 |
|
Название файла |
|
В 2025 году были также обнаружены образцы загрузчика PipeMagic, имитирующие клиент ChatGPT. Это приложение похоже на то, что злоумышленники применяли в атаках на организации в Саудовской Аравии в 2024 году. Там также используются фреймворки Tokio и Tauri, причем, судя по строкам с информацией об авторских правах и метаданным PE-заголовка, исполняемый файл был собран в 2024 году, хотя и был впервые обнаружен в кампании 2025 года. Кроме того, в данном случае используется та же версия библиотеки libaes, что и в атаках годом ранее. По поведению и структуре образец также аналогичен приложению, которое видели в октябре 2024 года.
AESЗагрузчик с использованием DLL hijacking
MD5 |
|
Название файла |
|
Помимо изначального метода исполнения при помощи файла .mshi, который запускается через MSBuild, атакующие также использовали более популярный метод с расшифровыванием нагрузки и ее внедрением посредством исполняемого файла, который не нуждается во вспомогательных утилитах для запуска. При этом сам исполняемый файл был легитимным (в рамках данной кампании «Лаборатория Касперского» видела вариант с файлом обновления Google Chrome), а вредоносная логика была реализована при помощи библиотеки, которую он подгружает. Для этого на диске рядом с легитимным приложением размещалась вредоносная DLL, содержащая функцию, которую оно экспортирует (метод DLL hijacking).
Стоит отметить, что в конкретном образце библиотеки экспортируемые функции не были вредоносными — вредоносный код содержала функция инициализации (DllMain), которая всегда вызывается при загрузке DLL, так как инициализирует внутренние структуры, файловые дескрипторы и т. д.
В первую очередь загрузчик читает данные из зашифрованного файла, путь к которому злоумышленники передают ему через аргументы командной строки.
Далее содержимое файла расшифровывается с помощью симметричного шифра AES в режиме CBC, при этом ключ равен 9C 3B A5 B2 D3 22 2F E5 86 3C 14 D5 13 40 D7 F9, а вектор инициализации (IV) — 22 1B A5 09 15 04 20 98 AF 5F 8E E4 0E 55 59 C8.
Расшифрованный код библиотека внедряет в память и передает ему управление, а исходный файл впоследствии удаляется. В вариантах, обнаруженных во время анализа, полезной нагрузкой был шелл-код, аналогичный тому, что было обнаружено в 2024 году во время анализа вредоносной кампании с клиентом для ChatGPT.
Внедренный PE
MD5 |
|
Filename | — |
Во всех методах загрузки, описанных выше, полезной нагрузкой был исполняемый файл для 32-битных систем Windows. Любопытно, что во всех случаях этот файл поддерживал графический режим, хотя и не имел графического интерфейса. Этот исполняемый файл и есть бэкдор PipeMagic.
Образец первым делом генерирует случайные 16 байт для создания имени для канала (pipe), который он будет впоследствии использовать. Имя создается по тому же принципу, что и в оригинальном PipeMagic, который эксперты «Лаборатории Касперского» видели в 2022 и 2024 годах.
Сам образец не отличается от тех, что были замечены ранее, однако в нем появилась строка с заранее заданным путем канала \.\pipe\magic3301. При этом в самом бэкдоре она не используется в явном виде (то есть он не взаимодействует с каналом с таким именем).
Кроме того, аналогично образцам, найденным в 2022 и 2024 годах, в этой версии создается канал общения по адресу 127.0.0.1:8082.
Обнаруженные модули
В ходе исследования атак 2025 года специалисты «Лаборатории Касперского» обнаружили дополнительные плагины, используемые в данной вредоносной кампании. Всего было получено три модуля, реализующих различную функциональность, не присутствующую в основном бэкдоре. Все модули представляют собой исполняемые файлы для 32-битных систем Windows.
Модуль асинхронной коммуникации
Модуль реализует асинхронную модель ввода-вывода. Для этого используется механизм очереди ввода-вывода и портов завершения ввода-вывода (Completion Ports).
Сразу при входе в плагин происходит обработка команд. На данном этапе поддерживается пять команд:
Идентификатор команды | Описание |
| Инициализация и создание потока, постоянно получающего изменения из очереди ввода-вывода |
| Завершение работы плагина |
| Обработка файлового ввода-вывода |
| Завершение файловой операции по идентификатору |
| Завершение всех файловых операций |
Хотя изменения ввода-вывода через порты завершения обрабатываются в отдельном потоке, основной поток будет дожидаться завершения файловой операции. Поэтому данную модель нельзя назвать по-настоящему асинхронной.
Если была выбрана команда с идентификатором 0x3 (обработка файлового ввода-вывода), управление переходит на внутренний обработчик. Для этой команды существует набор подкоманд, который описан ниже. Вместе с подкомандой эта команда имеет длину больше или равную 4 байтам.
Идентификатор команды | Описание |
| Открытие файла в заданном режиме (чтение, запись, запись в конец файла и т. д.) |
| Запись в файл |
| Чтение из файла |
| Изменение состояния флага |
| Запись в файл данных, полученных от другого плагина |
| Закрытие файла |
| Дамп всех открытых файлов |
Команда с идентификатором 0x5, предположительно, отвечает за выставление флага ошибки чтения. Если выставлен этот флаг, операция чтения невозможна. При этом модуль не поддерживает команды, снимающие флаг, то есть по факту эта команда просто блокирует чтение из канала.
Для управления открытыми файлами используемые файловые дескрипторы хранятся в двусвязном списке в глобальной памяти.
Загрузчик
Данный модуль, обнаруженный в одном из заражений, отвечает за внедрение дополнительной нагрузки в память и ее исполнение.
В первую очередь при запуске создается канал с названием \.\pipe\test_pipe20.%d, где в форматную строку подставляется уникальный идентификатор процесса, внутри которого находится внедренный код. Далее данные из этого канала в бесконечном цикле читаются и отправляются на обработчик команд.
Уникальный идентификатор команды содержится в первых четырех байтах данных и имеет следующие возможные значения.
Идентификатор команды | Описание |
| Чтение данных из канала или отправка данных в канал |
| Инициирование нагрузки |
Загружаемая нагрузка — это исполняемый файл для 64-битных систем Windows. Обработчик команд парсит этот файл и извлекает еще один исполняемый файл из секции ресурсов. В дальнейшем этот файл проходит все процедуры загрузки — получение адресов импортируемых функций, релоцирование и т. д. При этом для получения адресов системных методов используется не хеширование, а простое сравнение имен.
Исполняемый файл обязан экспортировать функцию под названием DllRegisterService. После загрузки вызывается его точка входа (для инициализации внутренних структур), а затем — эта функция. Она предоставляет интерфейс со следующими возможными командами:
Идентификатор команды | Описание |
| Инициализация |
| Получение данных от модуля |
| Обратный вызов на получение данных от нагрузки |
Инжектор
Данный модуль также представляет собой исполняемый файл для 32-битных систем Windows. Он отвечает за запуск полезной нагрузки — исполняемого файла, изначально написанного на C# (.NET).
Для этого сначала создается канал с именем \.\pipe\0104201.%d, где в форматную строку подставляется уникальный идентификатор процесса, в котором выполняется модуль.
Из канала образец считывает данные, в которых ищет приложение на .NET. Интересной особенностью является то, что, в отличие от других модулей, вычитывание происходит не в отдельном потоке, а однократно.
Перед загрузкой полученного приложения модуль делает еще один важный шаг. Чтобы нагрузка не была обнаружена через интерфейс AMSI, злоумышленники сначала загружают локальную копию библиотеки amsi. Далее они открывают для записи участок памяти, где содержатся функции AmsiScanString и AmsiScanBuffer, и патчат эти функции. Например, вместо изначального кода функции AmsiScanString в памяти оказывается функция-пустышка, которая всегда возвращает 0 (то есть помечает файл как безопасный).
После этого образец подгружает библиотеку mscoree.dll. Поскольку злоумышленники не знают целевой версии библиотеки, они во время исполнения проверяют версию среды выполнения .NET, установленную на машине жертвы. Плагин поддерживает версии v4.0.30319 и v2.0.50727. Если на устройстве установлена одна из них, происходит запуск полезной нагрузки через интерфейc _Assembly, реализуемый в mscoree.dll.
Постэксплуатация
По информации Microsoft, эксплоит для CVE-2025-29824 запускался в адресном пространстве процесса dllhost.exe и использовал классические техники постэксплуатации: для получения адресов из пространства ядра применялась функция NtQuerySystemInformation, а для повышения привилегий — RtlSetAllBits изнутри ядра, чтобы включить все привилегии процесса при повреждении структуры EPROCESS.
Так как для эксплуатации требовалось взаимодействие с драйвером clfs.sys, атакующие создавали файл C:\ProgramData\SkyPdf\PDUDrv.blf.
После повышения привилегий полезная нагрузка сначала внедрялась в адресное пространство процесса winlogon.exe, оттуда — в procdump.exe, а затем — в адресное пространство процесса dllhost.exe, запущенного с помощью следующей команды:
C:\Windows\system32\dllhost.exe -accepteula -r -ma lsass.exe c:\programdata\[комбинация из случайных символов]Эти действия выполняются для того, чтобы затем появилась возможность получить данные LSASS из памяти, что ведет к краже учетных данных пользователей Windows. С повышенными привилегиями выполнялось шифрование файлов в скомпрометированной системе с использованием шифровальщика RansomEXX, также запущенного через dllhost.exe:
C:\Windows\system32\dllhost.exe --do [путь к вредоносному файлу RansomEXX]Информация об уязвимости
По информации на официальном сайте Microsoft, уязвимость связана с использованием данных на куче после освобождения выделенной памяти, что при дальнейшей эксплуатации могло привести к повышению привилегий в ОС Windows.
Немного о clfs.sys
clfs.sys — драйвер, работающий в пространстве ядра ОС Windows и предназначенный для логирования информации в файлы специального формата BLF (Base Log File). Драйвер появился в системе в 2005 году вместе с версией Windows Server 2003 R2. То, что clfs.sys находится в пространстве ядра, объясняется тем, что он требуется для работы некоторых других драйверов. Например, менеджер транзакций (tm.sys) использует его для журналирования транзакций с возможностью их отката.
На рисунке ниже можно увидеть используемые драйвером tm.sys функции, импортируемые из clfs.sys.
Также у clfs.sys есть собственный API (clfsw32.dll) для доступа к драйверу из пользовательского пространства. Например, чтобы создать основной файл лога, можно использовать функцию CreateLogFile, а чтобы добавить контейнер, где уже будут данные, — AddLogContainer. Кроме того, к драйверу можно обращаться через IOCTL, реализующийся в Windows через функцию NtDeviceIoControlFile, а создать дескриптор файла можно через NtCreateFile.
В последнее время clfs.sys наряду с afd.sys и win32k.sys стал популярной целью у злоумышленников: уязвимости в нем часто появляются «в дикой природе» в ходе различных кампаний.
Первоначальный анализ
Как BI.ZONE уже писала в одной из предыдущих статей, для получения разных версий можно использовать Winbindex. Загружаем версии с апрельским (от 8 апреля) и мартовским (от 11 марта) Security Update.
При сравнении двух файлов при помощи BinDiff можно обнаружить, что было изменено достаточно небольшое количество функций, а изменения преимущественно получили функции CClfsRequest::Close и CClfsLogCCb::Cleanup, вызывающиеся при закрытии дескриптора файла логирования.
В обновлениях, касающихся безопасности, Microsoft добавляет функцию следующего вида: Feature_[число]__private_IsEnabledDeviceUsage. По нашему предположению, это сделано, чтобы в случае каких-либо ошибок при исправлении можно было вернуть устройства в исходное состояние.
Так, декомпилированный код функции CClfsRequest::Close выглядит следующим образом:
В то время как измененный код функции CClfsLogCcb::Cleanup, вызывающийся изнутри CClfsRequest::Cleanup, выглядит так:
При закрытии дескриптора файла ядро отправляет два I/O-запроса к драйверу: первый — на очистку (IRP_MJ_CLEANUP), второй — на закрытие (IRP_MJ_CLOSE). Они обрабатываются следующим образом:
Порядок запросов можно также увидеть на диаграмме:
Здесь стоит отметить, что из пользовательского пространства нельзя отдельно вызвать IRP_MJ_CLEANUP или IRP_MJ_CLOSE, а также в момент IRP_MJ_CLEANUP операции с дескриптором все еще возможны из пользовательского пространства.
Уязвимость
При анализе измененного кода можно понять, что хотел сказать автор исправление связано с переносом вызова функции CClfsLogCcb::Release из CClfsLogCcb::Cleanup в CClfsRequest::Close.
CClfsLogCcb::Release — функция, которая уменьшает количество референсов для объекта CClfsLogCcb на 1. Если референсов больше нет, вызывает деструктор, а затем очищает память, выделенную под указанный объект:
Однако из-за того, что память, выделенная под объект CClfsLogCcb, высвобождалась в момент I/O-запроса IRP_MJ_CLEANUP, возможно реализовать такой IOCTL-вызов, который также использует уже освобожденный объект CClfsLogCcb. Это может привести к повреждению памяти внутри ядра.
Одной из функций, использующих объект CClfsLogCcb, является CClfsRequest::StartArchival:
Для успешного триггера уязвимости необходимо, чтобы цепочка выполнения следовала следующей диаграмме:
Стоит отметить, что освобождение происходит с использованием LookasideList:
То есть, если количество освобожденных объектов не превышает глубину LookasideList, объект на самом деле не будет освобожден, а только помечен внутри данного листа. Отметим, что глубина листа равна 24. Это значит, что для эксплуатации необходимо изначально создать как минимум 25 дескрипторов одного и того же файла логирования, затем закрыть 24 из них, чтобы заполнить лист, после чего эксплуатировать уязвимость в оставшихся.
При успешной реализации описанной стратегии в адресном пространстве ядра будет находиться освобожденная память, внутри которой может выделиться уже другой объект того же размера. Драйвер clfs.sys будет считать, что этот объект — CClfsLogCcb. Дальнейшая эксплуатация заключается в манипуляции этим «зависшим» объектом с помощью clfs.sys.
Вывод
Повторное обнаружение PipeMagic в атаках на организации в Саудовской Аравии и Бразилии свидетельствует о том, что вредоносное ПО по-прежнему активно и злоумышленники продолжают развивать его функциональность. В новых версиях, зафиксированных в 2024 году, наблюдаются усовершенствования, направленные на устойчивое закрепление в системах жертв и горизонтальное перемещение по внутренним сетям.
За последние несколько лет драйвер clfs.sys стал популярной целью у киберпреступников, особенно у тех, чья цель — финансовая выгода. Все чаще в ходу эксплоиты нулевого дня: не только для clfs.sys, но и для других драйверов. Основная цель — повысить привилегии и замести следы после проникновения. Защититься от таких атак довольно сложно: уязвимости появляются даже в последних версиях софта.
Что поможет? В первую очередь — EDR-решения. Они позволяют обнаружить злоумышленников на ранних этапах атаки и при проведении постэксплуатации. Это значительно снижает риски финансовых потерь. И конечно, нужно вовремя обновлять ПО и регулярно проводить пентесты.
Автор: Андрей Чижов, старший специалист по исследованию уязвимостей, BI.ZONE
