Распространение многофакторной аутентификации и популяризация облачных сервисов в организациях вынудили киберпреступников обновить свои тактики и инструменты. С одной стороны, для кражи информации и проведения мошеннических схем им даже необязательно проникать во внутреннюю сеть компании или распространять вредоносное ПО. Достаточно через легитимные учетные записи получить доступ к облачным сервисам, например к почте Microsoft 365 или файловым хранилищам MOVEit. С другой стороны, для этого не хватит украденной или подобранной пары логин-пароль и надо как-то обойти MFA. Большая серия кибератак на крупные организации, зарегистрированных за последнее время, затронувшая более 40 000 жертв, показывает, что злоумышленники освоились в новых условиях — применяют адаптированные к компании-жертве фишинговые техники и инструментарий Adversary-in-the-Middle в промышленных масштабах.
Что такое Adversary-in-the-Middle
Атака adversary-in-the-middle (AitM) является разновидностью известного класса атак Man-in-the-Middle. В коммуникации между легитимными участниками обмена информацией (клиентом и сервером) посередине встраивается атакующий, перехватывая запросы клиента и далее направляя их на сервер, а потом перехватывает ответы сервера и направляет их клиенту. При этом злоумышленник не просто прослушивает чужие коммуникации, а активно в них вмешивается, модифицируя контент в своих интересах.
Сложные атаки AitM могут включать компрометацию интернет-провайдера или Wi-Fi-сети организации. После этого атакующие манипулируют сетевыми протоколами (ARP poisoning, DNS spoofing) и демонстрируют поддельные веб-страницы или файлы, когда пользователь обращается к легитимным ресурсам. Но в случае с целевым фишингом такие ухищрения не нужны. Достаточно заманить пользователя на вредоносный веб-сервер, который с помощью обратного прокси (reverse proxy) будет одновременно поддерживать связь с атакуемым пользователем и легитимными серверами облачного сервиса. В целом ход атаки такой.
Пользователь получает фишинговое сообщение и переходит по ссылке.
Через цепочку маскировочных переадресаций (редиректов) браузер пользователя открывает страницу вредоносного сайта, она выглядит как портал входа облачного сервиса. Чтобы ее показать, обратный прокси злоумышленников обращается к легитимному серверу и передает все содержимое логин-страницы браузеру пользователя, при необходимости внося нужные атакующим изменения.
Пользователь видит привычный интерфейс, вводит свои имя и пароль.
Вредоносный сервер отправляет имя и пароль легитимному серверу, имитируя вход пользователя. Также логин и пароль сохраняются в базе данных злоумышленников.
Легитимный сервер проверяет пароль и, в случае его корректности, требует ввести одноразовый код; параллельно одноразовый код отправляется пользователю или генерируется у него в приложении, как обычно при процедуре MFA.
Вредоносный сервер отображает пользователю страницу с требованием ввести одноразовый код.
Пользователь вводит одноразовый код из приложения-аутентификатора или SMS.
Вредоносный сервер отправляет код легитимному серверу, тот проверяет код и при его корректности пускает пользователя в систему.
Легитимный сервер отправляет «браузеру», в роли которого выступает вредоносный сервер, сессионные куки (session cookies), нужные для нормальной работы в системе.
Вредоносный сервер пересылает куки злоумышленникам, которые с их помощью могут имитировать браузер пользователя, уже зашедшего в систему. Злоумышленникам не требуется вводить ни пароля, ни кодов MFA — это уже сделано!
Вредоносный сервер переадресует пользователя на другой сайт либо на обычную логин-страницу легитимного сервиса.
Дополнительные особенности современных атак AitM
Базовый сценарий атаки, описанный выше, злоумышленники поставили на поток. Существуют готовые фишинг-киты, обычно включающие в себя обратный прокси evilginx или muraena и позволяющие проводить такие атаки «из коробки» — с готовыми шаблонами модификации логин-страниц для популярных облачных сервисов и отлаженными сценариями кражи кодов MFA.
Но для успешной компрометации крупных организаций «коробочная» атака требует индивидуальной настройки. Хорошо обеспеченные ресурсами злоумышленники могут проводить ее сразу для многих организаций. В уже упомянутой атаке за три месяца целью стали около 500 крупных компаний, причем все они были юридическими фирмами. Каждая получила именной домен в инфраструктуре атакующих, поэтому жертвы (руководители этих организаций) попадали на домен с привычным и правильным названием в его начальной части.
Борьба брони и снаряда не прекращается. Например, многие компании и облачные сервисы переходят на способы MFA, устойчивые к фишингу, такие как аппаратные USB-токены и беспарольный вход в систему (passkeys). В принципе эти способы аутентификации устойчивы к атакам AitM, но большинство облачных систем предусматривает возможность «резервного» способа входа, включающего более старые методы проверки, такие как резервные одноразовые коды «из бумажного конверта» или одноразовые коды, отправляемые по SMS. Это сделано на тот случай, если пользователь потеряет физическое устройство второго фактора или оно сломается. Атакующие могут воспользоваться этой функцией: вредоносный сервер показывает жертве модифицированные страницы аутентификации легитимного сервера, с которых удалены более надежные способы аутентификации. Такая атака получила название Passkey redaction.
Как защититься от атак AitM
Защита от таргетированных фишинговых атак, направленных на доступ к облачным аккаунтам, требует скоординированных мер, принятых корпоративной службой ИБ, облачным провайдером и самими пользователями.
Необходимо использовать устойчивые к фишингу инструменты MFA, например аппаратные USB-токены. В идеале они применяются всеми сотрудниками, но как минимум — руководством и ответственными за критические бизнес-операции и ИТ.
В сотрудничестве с поставщиками решений SSO и при поддержке облачных сервисов нужно отключить «резервные» способы аутентификации, а также принять технические меры, затрудняющие кражу cookie с токенами аутентификации.
Следует обучать сотрудников внимательно относиться к изменениям на логин-страницах и не вводить данные, если «куда-то пропала аутентификация» или имя сайта кажется незнакомым. Регулярно проводите тренинги по кибербезопасности, учитывающие должностные обязанности и уровень подготовки сотрудника.
Изучите и корректно настройте доступные у облачного провайдера инструменты безопасности; проверьте, что протоколирование действий сотрудников (логгинг) ведется с достаточной детальностью и команда ИБ оперативно получает эти логи — в идеале они должны попадать прямо в SIEM-систему.
Убедитесь, что все компьютеры и смартфоны, используемые для доступа к корпоративным аккаунтам, имеют установленный агент EDR и подключены к системе управления корпоративной техникой EMM.