MS Exchange — история взлома и советы по улучшению защиты

Совсем недавно в IT-шных новостях прогремела весть о том, что Microsoft внепланово выпускает обновления для поддерживаемых версий почтового сервера MS EXchange, которое закрывает zero-day уязвимость, эксплуатация которой может привести к заливке веб-шелла на сервер и получению на нём командной оболочки для дальнейшего развития атаки.

Это напомнило мне о собственном опыте попадания в похожую ситуацию, давно хотел выложить ряд заметок, посвящённых повышению безопасности «наземного» Exchange и Active Directory и вот сейчас похоже отличное время. Сразу скажу, если у вас есть хорошая IDS/IPS система, а также работает следящий за сетевым трафиком SIEM, то с большой долей вероятности вашу организацию такие проблемы не затронут. Но я по опыту общения с коллегами знаю, что очень часто почтовый сервер настраивается по инструкции из интернета и к его обслуживанию и безопасности относятся несколько халатно, что чревато проблемами, особенно в том случае, если веб-интерфейс почтового сервера доступен в сети интернет без дополнительного VPN и прочих заградительных систем.

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

• Как понять, что сервер взломан — куда смотреть, какие инструменты использовать.
• Как ограничить доступ к ECP средствами IIS.
• Lithnet Password Protection for Active Directory (LPP) — аналог Azure AD Password Protection.
• IPBan Service — аналог юниксового fail2ban, но для MS Exchange.

Как устроен современный взлом

Если вы всё ещё думаете, что современный взлом — это обязательно удаление ваших данных или их шифрование с требованием выкупа, то спешу вас разочаровать. Современный взлом, как правило, заключается в том, чтобы как можно дольше оставаться незамеченным в системе, собирать ваши данные и потихоньку передавать их на сторону. Причём какую-то активность зловреды начинают проявлять только в том случае, если «чувствуют» наличие выхода с хоста в интернет и предпочитают действовать исключительно по ночам в выходные дни, чтобы с минимальными шансами нарваться на живого администратора на сервере или на какой-нибудь триггер в мониторинге. Хорошо подготовленный взлом может оставаться в системе месяцами, а порой и годами и обслуживающие систему айтишники будут уверенно всем отвечать, что «взломов у нас никогда не было, в дополнительных мерах защиты не нуждаемся!».

У современных вирусов нет привычного «тела», поэтому стандартные антивирусы для них практически полностью бесполезны. Скрипт шелла не является угрозой сам по себе, тем более что он подготавливается для каждой атаки индивидуально и сигнатуры на нём не сработают. Дальнейшие действия вируса тоже, как правило, не вызывают никаких подозрений у систем защиты, ведь они просто используют стандартные компоненты OS, PowerShell, Exchange и так далее. Для них желаний выгрузить стандартными средствами почтовый ящик в PST и потом передать этот файл по HTTPS куда-то в сторону Китая ничем не отличается от, например, настроенных по расписанию бэкапов.

В общем основная моя мысль заключается в том, что если вы не видите последствий взлома — это не значит, что вас не взломали. Скорее всего у вас просто недостаточно хорошо исследуются логи и анализируется сетевой трафик.

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

Универсального метода, к сожалению, нет, но есть общие рекомендации, которые помогут вам с большой долей вероятности. Веб-шелл для MS Exchange, как правило, заливается в формате aspx файла и кладётся в папку с самим почтовым сервером или же в inetpub к другим файлам IIS. Часто шеллов может быть несколько — здесь и один и тот же взломщик может подстраховаться, а может быть просто несколько атакующих забрались к вам одновременно. Пример размещения таких файлов:

\inetpub\wwwroot\aspnet_client\OutlookCN.aspx
\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\rediection.aspx

Разумеется, они могут называться как угодно и находиться в других директориях тоже. Также признаками взлома можно считать запуск скриптов *.ps1 и исполняемых файлов *.exe из временной папки C:\Windows\TEMP, однако отследить их не так просто, глазами вы их не увидите, потому что вирус за собой всё подчищает и работает, как я уже говорил, обычно по ночам. Однако если вы всё-таки нашли непонятные скрипты и программы в TEMP — это очень весомый повод как следует всё проверить и отнестись к проверке максимально серьёзно.

Конкретно для взлома MS Exchange следующий совет не очень актуален, но вообще очень часто определить наличие в системе какой-то пакости помогает банальный Autoruns — с его помощью можно быстро посмотреть всё, что запускается при старте системы и выявить мутные записи — службы без цифровой подписи, непонятные DLL’ки, CMD со странными параметрами. Не забывайте пользоваться этим простым, но мощным инструментом.

Что стоит предпринять в первую очередь

Может прозвучать нелогично, но главное не бросаться в первую очередь требовать всех пользователей сменить пароли через OWA — если сервер заражён, то новый пароль будет перехвачен в момент смены и тогда у взломщиков будут не только выгрузки писем в PST, но и доступ в ящик по обычным реквизитам, что только усугубит ситуацию, особенно если используется только парольная аутентификация без второго фактора или клиентских сертификатов. А вот максимально сократить список админов и заменить им пароли через стандартную оснастку dsa.msc — это действительно будет хорошим началом. Также будет более безопасно, если у самих админов не будет привязанного почтового ящика, почтой лучше пользоваться под обычной, непривилегированной учёткой.

Я выше уже писал, что современный антивирус практически бесполезен в данной ситуации, однако облачные репутационные сервисы наподобие KSN в теории могут оказаться полезны и всё-таки ругнутся на закинутый вам веб-шелл. Функция KSN есть в продукте Kaspersky Endpoint Security, который нормально ставится и работает на Windows Server. Хотя функционал KSN есть и в Kaspersky Security for Windows Servers, почему-то в нашем случае срабатывал и ругался только KES. Бесплатный KVRT, равно как и VirusTotal на тот момент никак не реагировали на вредоносный aspx файл. Если у вас нет лицензии на KES, то им можно 30 дней пользоваться с тестовой лицензией, этого как раз должно хватить на комплексную проверку сервера.

Простого и бесплатного способа отслеживать все запуски ПО из папки C:\Windows\TEMP я не знаю, буду благодарен, если подскажите в комментариях. А вот запуск PowerShell скриптов можно отслеживать через соответствующий журнал событий. Вот пример настройки из интернета, процесс не особенно сложный, скорее у вас потом возникнут проблемы с разбором полученных логов, потому что сам Exchange вызывает много скриптов и не всегда просто отличить легитимный код, от действий злоумышленника.

Последний совет может прозвучать банально, но в случае с веб-шеллом в достаточной степени действенно. Просто переустановите сервер в режиме Recovery, разумеется предварительно устранив все известные уязвимости, чтобы ваш чистый сервер тут же не взломали повторно. После переустановки убедитесь, что список автозагрузки в Autoruns по-прежнему чистый и с большой долей вероятности можете считать проблему закрытой. До следующей найденной уязвимости 🙂.

В следующих частях данного цикла мы рассмотрим дополнительные меры защиты, которые можно применить для защиты «наземного» Exchange без применения платных продуктов и облаков Azure.