Тихая установка: Новая кампания использует уязвимости Ivanti EPMM для отложенного доступа

information security

Эксплуатация критических уязвимостей в Ivanti Endpoint Manager Mobile (EPMM, ранее MobileIron) продолжается с момента их раскрытия. Это уже привело к компрометации ряда крупных организаций, включая государственные структуры. Однако новая волна атак, начавшаяся 4 февраля 2026 года, демонстрирует иной, более скрытный подход, который может указывать на деятельность брокеров начального доступа.

Описание

В отличие от привычных сценариев массовой эксплуатации, когда злоумышленники после взлома быстро устанавливают веб-шеллы для выполнения команд или кражи данных, в этой кампании используется иная тактика. Оператор загружает полезную нагрузку, проверяет её успешную установку и покидает систему, не выполняя никаких дополнительных действий. Таким образом, имплант остаётся в памяти в спящем состоянии, ожидая активации.

Ключевой особенностью кампании стало развёртывание бездействующего загрузчика Java-классов в памяти по пути "/mifs/403.jsp". Этот путь для веб-шелла встречается не так часто. Имплант активируется только при получении специального триггерного параметра, а последующая вредоносная активность пока не наблюдалась. Подобная модель поведения характерна для брокеров начального доступа: они получают первоначальный доступ к системе, чтобы впоследствии продать или передать его другим злоумышленникам.

Уязвимости в основе атак

Атаки стали возможны благодаря двум критическим уязвимостям в EPMM - CVE-2026-1281 и CVE-2026-1340. Обе позволяют обойти аутентификацию и выполнить произвольный код удалённо, затрагивая разные пакеты (aftstore и appstore соответственно). Практический результат одинаков: неавторизованный доступ к конечным точкам на уровне приложения. Ivanti опубликовала рекомендации по устранению уязвимостей, однако эксплуатация в реальных условиях началась почти сразу. Большая часть первоначальной активности была предсказуемой: сканирование, массовые атаки и установка стандартных веб-шеллов.

Особенности кампании с использованием 403.jsp

Каждая успешная эксплуатация в рамках этой кампании приводила к размещению веб-шелла по пути "/mifs/403.jsp". Сам по себе этот путь не нов, его уже наблюдали в предыдущих компрометациях инфраструктуры Ivanti и MobileIron. Однако важной особенностью стала не точка размещения, а функционал полезной нагрузки.

Вместо развёртывания традиционного интерактивного веб-шелла оператор доставлял файл Java-класса в кодировке Base64 через HTTP-параметры. Каждая полезная нагрузка декодировалась в вайтбайт-код Java, функционирующий как бездействующий загрузчик классов в памяти, а не как готовый бэкдор. Это важное отличие.

Внутри base.Info: загрузчик в памяти

Полезная нагрузка представляет собой скомпилированный Java-класс "base.Info". Это не веб-шелл в традиционном понимании, он не предоставляет возможности выполнения команд или доступа к файлам. Его единственная цель - принять, загрузить и выполнить второй Java-класс, который будет доставлен через HTTP позже.

Класс использует метод "equals(Object)" в качестве точки входа, что необычно, но сделано намеренно. Стандартные методы сервлетов, такие как "doGet" или "doPost", с большей вероятностью будут замечены системами безопасности. Метод "parseObj" извлекает объекты "HttpServletRequest" и "HttpServletResponse" из аргумента, что обеспечивает переносимость загрузчика в различных средах.

После вызова загрузчик проверяет наличие HTTP-параметра с именем "k0f53cf964d387". Если параметр присутствует, загрузчик удаляет двухсимвольный префикс из его значения и декодирует оставшуюся часть из Base64 в сырые байты. Эти байты затем загружаются как Java-класс в память с помощью рефлексивного вызова "ClassLoader#defineClass", без записи на диск. Полученный класс инстанцируется, а результат его работы возвращается в HTTP-ответе.

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

Отсутствующая активность как индикатор угрозы

С оборонительной точки зрения, ключевым наблюдением стало полное отсутствие последующей активности. Загрузчик был развёрнут и подтвердил свою работоспособность, но не было зафиксировано ни одного запроса, который бы передавал класс второй стадии через триггерный параметр. Доступ был установлен и оставлен в спящем режиме.

Это соответствует модели работы брокеров начального доступа. Инструментарий является универсальным и не зависит от среды, его задача - надёжно работать в разных окружениях, а не выполнять конкретные постэксплуатационные действия. Оператор развернул его в больших масштабах, подтвердил установку и продолжил работу. Вероятная цель - упаковать подтверждённый рабочий доступ для передачи или продажи другой стороне, которая активирует его позже с другой инфраструктуры.

Именно это разделение ролей - когда один актор устанавливает доступ, а другой его использует - делает подобные схемы трудными для обнаружения. Между первоначальной компрометацией и конечным использованием возникает тихий промежуток, в котором следы в телеметрии практически отсутствуют.

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

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

Необходимо немедленно установить патчи для EPMM в соответствии с рекомендациями вендора. Критически важно перезапустить затронутые серверы приложений, чтобы удалить импланты из памяти, поскольку полезная нагрузка не записывается на диск. После этого следует проанализировать логи доступа на наличие ключевых индикаторов компрометации.

К таким индикаторам относятся любые запросы к "/mifs/403.jsp", большие параметры Base64, начинающиеся с "yv66vg" (кодировка магических байтов Java "CAFEBABE"), наличие параметра "k0f53cf964d387" в строках запросов, а также тела ответов, содержащие маркеры "3cd3d" или "e60537". Также стоит обратить внимание на любые ответы, содержащие строку "ERROR://", которая является форматом сообщений об ошибках загрузчика.

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

IPv4

  • 104.219.171.96
  • 108.64.229.100
  • 115.167.65.16
  • 138.36.92.162
  • 146.103.53.35
  • 148.135.183.63
  • 151.247.221.59
  • 166.0.83.171
  • 172.59.92.152
  • 185.239.140.40
  • 185.240.120.91
  • 193.41.68.58
  • 194.35.226.128
  • 45.66.95.235
  • 46.34.44.66
  • 62.84.168.208
  • 77.78.79.243

SHA256

  • 097b051c9c9138ada0d2a9fb4dfe463d358299d4bd0e81a1db2f69f32578747a
Комментарии: 0