ProxyLogon: веб-шелл в OWA и форензика по IIS-логам

Мы писали про ProxyLogon в начале февраля, когда стало известно об атаках HAFNIUM и всё ещё выглядело как «срочно обновиться и выдохнуть». С тех пор картина стала значительно хуже: сканирование интернета на уязвимые Exchange шло ещё до публикации патчей, и часть серверов была скомпрометирована задолго до того, как их владельцы вообще услышали про CVE-2021-26855.

На прошлой неделе один из наших клиентов попросил разобраться: после установки патча в их IDS пошли странные алерты, внутри Exchange вёл себя не так. Пришлось идти смотреть руками.

Что обнаружили

Первое, что бросилось в глаза после входа на сервер - нехарактерный .aspx-файл в каталоге /inetpub/wwwroot/aspnet_client/system_web/. Exchange туда не пишет. Файл назывался что-то невинное, вроде log.aspx, дата создания - несколько недель назад. Открыли - классический China Chopper, минималистичный веб-шелл на одну строку кода, принимающий команды через POST-параметр. Работает, пока IIS живёт.

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

Восстановление хронологии по IIS-логам

Дальше - форензика. У клиента IIS-логи не ротировались слишком агрессивно, что нам повезло: несколько недель истории сохранились. Логи Exchange хранятся в нескольких местах, и важно смотреть все:

• W3SVC-логи (C:\inetpub\logs\LogFiles\W3SVC1\) - основной HTTP-трафик.
• HTTPErr-логи (C:\Windows\System32\LogFiles\HTTPERR\) - отклонённые запросы и 400-е ошибки, там тоже бывает интересное.
• Exchange OWA/ECP логи (C:\Program Files\Microsoft\Exchange Server\V15\Logging\) - отдельные компоненты пишут туда.

По логам W3SVC восстановили картину. Первые попытки эксплуатации CVE-2021-26855 - характерные POST-запросы к /ecp/DDI/DDIService.svc/GetObject с параметрами, которые Exchange в норме не получает. Несколько дней тишины - сканер, судя по всему, просто нашёл и пометил цель. Потом серия запросов к /ecp/ с заголовком X-AnonResource-Backend, содержащим путь на внутреннюю точку - это CVE-2021-26855 в действии, SSRF. Следом - POST к /ecp/y.js с телом: это CVE-2021-27065, запись файла. После этой пары запросов шелл появился на диске.

Весь сценарий занял несколько минут. Дальше было несколько обращений к самому шеллу с разных IP - видимо, перекладывали доступ или тестировали.

Индикаторы компрометации - что искать

По итогам разбора зафиксировали список для себя. Это не исчерпывающий IoC-лист, но достаточный для первичной проверки:

В файловой системе:

• Нехарактерные .aspx-файлы в /inetpub/wwwroot/aspnet_client/ и подкаталогах - Exchange не должен туда писать ничего.
• .aspx-файлы в C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\ - тоже тревожный признак.
• Любые исполняемые файлы с датой создания в период после начала массовой эксплуатации (конец февраля - начало марта).

В IIS-логах:

• POST-запросы к /ecp/DDI/DDIService.svc/GetObject с нестандартными параметрами.
• Запросы к /ecp/ с заголовком X-AnonResource-Backend, содержащим двоеточие и внутренний путь.
• POST-запросы к /ecp/*.js с непустым телом - Exchange так не работает.
• Запросы к .aspx-файлам в /aspnet_client/ - если файл там есть и к нему обращаются, это уже плохо.

В Windows Event Log:

• Событие 4688 (создание процесса) с родительским процессом w3wp.exe - IIS Worker не должен порождать cmd.exe или PowerShell в нормальной жизни.
• Нехарактерная активность MSExchange Unified Messaging - если используется CVE-2021-26857.

Microsoft выложила скрипт Test-ProxyLogon.ps1, он автоматизирует часть проверок по логам. Используйте его как отправную точку, но не как финальный ответ - скрипт ищет известные паттерны, ручной анализ логов может показать то, что паттерн не покрывает.

Что делали дальше

После того как нашли шелл и восстановили хронологию, дальнейшие шаги оказались стандартными:

• Удалить веб-шелл и любые другие нехарактерные файлы.
• Проверить задания Task Scheduler и реестр автозапуска - если атакующий успел закрепиться, шелл мог быть не единственным артефактом.
• Сбросить пароли сервисных аккаунтов Exchange и смежных учёток с привилегиями.
• Проверить Active Directory на предмет новых учёток, изменений в группах и изменений прав - если Exchange был точкой входа, атакующий мог двигаться дальше.
• Изолировать сервер до завершения проверки и только потом возвращать в строй.

Клиенту повезло в двух вещах: до критической инфраструктуры за периметром Exchange добраться не успели, и IIS-логи сохранились достаточно, чтобы восстановить хронологию. В другом случае обоих этих везений могло не быть.

Практический вывод

Весь февральский нарратив «поставь патч и спи спокойно» оказался неполным. Правильная формулировка: поставь патч, а потом убедись, что до тебя не добрались до патча. Это разные задачи.

Для тех, у кого Exchange on-premise - провести аудит состояния сервера после этой волны атак стоит в любом случае, даже если кажется, что всё чисто. IIS-логи за нужный период ещё есть - через несколько недель могут исчезнуть при ротации.