С августа 2022 года мы фиксируем волну атак на десятки российских компаний малого и среднего бизнеса. Злоумышленники пишут жертвам с предложением заплатить деньги за «аудит безопасности», а в противном случае грозят опубликовать конфиденциальные данные. Метод проникновения во всех случаях — SSRF-уязвимость из цепочки ProxyShell. Рассказываем об общем механизме атак и рекомендуем базовые меры защиты от угрозы.

Как проходит атака

Письмо от «аудиторов»

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

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

Чтобы эта информация не стала публичной, злоумышленники предлагают оплатить их «‎услуги по аудиту безопасности» и даже обещают прислать отчет с рекомендациями по устранению уязвимостей. Сумма выкупа может разниться; расследуя инциденты, мы встречали требования перечислить 9–10 тыс. долларов.

На отказ «аудиторы» угрожают реагировать поэтапно. Сначала рассылкой о взломе компании-жертвы всем ее сотрудникам, а также клиентам и партнерам. Затем, если жертву не убедит первый этап, обещают опубликовать выгруженные данные в открытый доступ.

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

Поначалу злоумышленники писали с почтовых ящиков своих предыдущих жертв. При этом в первом же сообщении мошенники поясняли, что не имеют отношения к компании, от имени которой выступают. С ноября они перешли на сервис анонимной электронной почты Proton Mail: большая часть писем приходит с адреса security4real@proton.me.

Взлом почтового сервера

Во всех известных нам атаках злоумышленники эксплуатируют одну и ту же уязвимость в почтовых серверах Microsoft Exchange.

Анализы журналов доступа к MS Exchange показывают, что атакующие используют скрипт с открытым исходным кодом exchange_ssrf_attacks.py. Он эксплуатирует известную SSRF-уязвимость MS Exchange с идентификатором CVE-2021-34473, которая входит в цепочку уязвимостей ProxyShell. С помощью этого инструмента злоумышленники получают список почтовых ящиков пользователей, список контактов, а также выгружают письма вместе с их вложениями.

Взломав почтовый сервер и получив содержимое ящиков, атакующие изучают переписки, в которых находят учетные данные от внутренних ресурсов компаний-жертв, в том числе от корпоративной частной виртуальной сети (VPN), системы трекинга задач Jira, внутренней wiki-платформы Confluence и проч.

Чтобы оставаться анонимными, злоумышленники используют публичные VPN-сервисы. К примеру, все обнаруженные в наших расследованиях IP-адреса, связанные с активностью мошенников, принадлежат сервису Mullvad.

Как защититься от угрозы

Все уязвимые серверы MS Exchange перед злоумышленниками равны: под наблюдаемую нами волну атак попали десятки малых и средних по масштабам компаний из самых разных отраслей.

Если ваша организация использует MS Exchange и не имеет строгой политики обновления ПО, то у нее есть риск стать жертвой описываемой нами группировки. Несмотря на то что Microsoft выпустила патч для ProxyShell еще в июле 2021 года, практика показывает, что многие компании не успели обновить свои почтовые серверы.

Если вдобавок к тому, что вы используете MS Exchange, вам пришло письмо с требованием заплатить за непрошеный «аудит безопасности», особенно с адреса security4real@proton.me, то, вероятнее всего, вам уже пора реагировать на инцидент. Но пока не спешите перечислять 10 тыс. долларов.

Ниже мы дадим базовые рекомендации по защите от угрозы в обоих случаях.

Если вы получили письмо

Поводы для подозрения

С высокой долей вероятности вы попали под волну атак при следующих условиях:

1. Вы получили письмо с требованием оплатить аудит безопасности инфраструктуры, который не заказывали (особое внимание обратите на письма с адреса security4real@proton.me).

2. В вашей компании используются серверы Microsoft Exchange, которые не обновлялись с мая 2021 года.

3. Эти серверы доступны напрямую из интернета.

Первые меры

Если у вас есть перечисленные выше поводы для подозрения, необходимо в срочном порядке:

1. Ограничить доступ к вашему серверу Microsoft Exchange из интернета.

2. Установить на этот сервер последние обновления безопасности.

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

Выполнив первичные меры безопасности, вы можете перейти к экспресс-анализу сервера MS Exchange, чтобы подтвердить или опровергнуть подозрение на инцидент.

Экспресс-анализ сервера MS Exchange

Чтобы убедиться в том, что на вашем сервере MS Exchange проэксплуатировали цепочку уязвимостей ProxyShell, нужно будет проверить два журнала:

• журнал событий Internet Information Services (IIS);

• журнал Exchange Web Services (EWS).

Если проверка покажет успешные попытки эксплуатации, мы рекомендуем провести полноценное расследование инцидента. Оно позволит вам понять, что злоумышленники сделали в инфраструктуре и какие ресурсы, помимо MS Exchange, они могли скомпрометировать. Расследование киберинцидента входит в нашу услугу «Управление киберинцидентами».

Ниже мы расскажем, на какие артефакты в каждом журнале стоит обратить внимание при экспресс-анализе.

Журналы событий IIS

Журналы событий Internet Information Services хранят события доступа к веб-серверу.

Журналы можно найти на сервере MS Exchange в директории C:\inetpub\logs\LogFiles.

Используемый нашими злоумышленниками скрипт exchange_ssrf_attacks.py оставляет в журналах IIS два специфических артефакта, которые могут указать нам на успешную эксплуатацию ProxyShell:

1. POST-запросы следующего вида:

   POST /autodiscover/autodiscover.json?a=a@edu.edu/ews/exchange.asmx

2. Поле User-Agent в запросе со следующим значением:

   Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36.

При анализе POST-запросов важно убедиться, что они имеют код ответа 200, указывающий на успех эксплуатации. В иных случаях мы имеем только неудачные попытки, которые любой сервер MS  Exchange, доступный из интернета, может рутинно фиксировать по несколько раз в сутки, — такие запросы внимания не достойны.

Примеры записей из журнала событий IIS, в которых зафиксированы оба артефакта, приведены на рис. 1.

Журналы EWS

Exchange Web Services — API для предоставления различным приложениям доступа к компонентам почтовых ящиков. Журналы этой службы содержат информацию о клиентском взаимодействии с ней.

Журналы можно найти в директории C:\Program Files\Microsoft\Exchange Server\<version number>\Logging\Ews, где <version number> — версия Microsoft Exchange.

Среди прочего в этих журналах фиксируются IP-адреса источников запроса, тип операции, электронный адрес, для которого выполняется операция, и User-Agent клиента.

Как мы указали выше, один из артефактов скрипта exchange_ssrf_attacks.py — специфическое значение User-Agent:

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36.

По нему в журналах EWS вы сможете отыскать операции, которые мошенники выполняли с помощью своего инструмента.

Среди операций стоит обратить внимание на те, которые выполняются при выгрузке электронных писем:

• FindItem — получение элементов, находящихся в почтовом ящике пользователя;

• GetItem — получение информации о сообщениях в электронной почте;

• GetAttachment — извлечение вложений из писем.

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

Фрагмент журнала EWS с нужными операциями приведен на рис. 2.

Если вы не получили письмо

Если вам не написали «аудиторы», но при этом ваша компания использует сервер Microsoft Exchange, доступный из интернета, расслабляться не стоит.

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

Чтобы свести риски к минимуму, мы рекомендуем следующие меры:

1. Регулярно обновляйте Microsoft Exchange. Эксплуатация уязвимостей MS Exchange часто становится первичным вектором атак на инфраструктуры компаний. Вовремя устанавливать критические обновления сервера важно, чтобы не стать легкой добычей для злоумышленников, в том числе использующих известные уязвимости, такие как ProxyLogon и ProxyShell.

2. Закройте доступ из интернета к почтовому серверу и другим чувствительным сервисам. Даже в отсутствие явных уязвимостей злоумышленники могут получить доступ к конфиденциальной информации, хранящейся на той же почте, — например, с помощью атаки перебором. Лучше исключить эту вероятность, организовав доступ к таким сервисам через один из двух промежуточных узлов:

   • корпоративный VPN;

   • прокси-сервер, требующий от клиентов предъявления TLS-сертификатов и проверяющий эти сертификаты (подключения по HTTP или без сертификатов должны быть в этом случае запрещены).