Компания Rapid7, специализирующаяся на кибербезопасности, раскрыла детали инцидента, в ходе которого злоумышленники использовали скомпрометированные учетные данные AWS для развертывания фишинговой инфраструктуры. Вместо стандартного сервиса Amazon Simple Email Service (SES) атакующие применили AWS WorkMail, что позволило им обойти встроенные ограничения и маскироваться под легитимный бизнес. Этот подход демонстрирует растущую тенденцию эксплуатации облачных сервисов для скрытного проведения атак, перекладывая операционные расходы на жертву.
Описание
Инцидент начался с утечки долгосрочных ключей доступа AWS. Первым признаком компрометации стал вызов API "sts:GetCallerIdentity" с пользовательским агентом, указывающим на использование инструмента TruffleHog. Этот инструмент часто применяется для поиска и проверки учетных данных, случайно опубликованных в публичных репозиториях. Несколько дней спустя активизировался второй скомпрометированный пользователь IAM. Оба набора учетных данных использовались из одного географического региона, что не соответствовало обычной активности компании-жертвы, а трафик исходил из инфраструктуры публичных облачных провайдеров, таких как Amazon и DigitalOcean.
После получения доступа злоумышленники провели разведку среды. Первый пользователь обладал ограниченными правами, и его попытки вызвали множество ошибок "AccessDenied". Затем атака переключилась на второго пользователя с более широкими привилегиями. Используя AWS CLI, злоумышленники выполнили серию вызовов API, включая "iam:ListUsers", чтобы изучить ландшафт идентификаторов. Для проверки конкретных разрешений они применяли технику преднамеренного вызова ошибок API. Например, попытка создать уже существующего пользователя IAM подтвердила наличие права "iam:CreateUser", а попытка установить пароль, нарушающий политику безопасности, подтвердила возможность создания профиля для входа в консоль.
Особое внимание атакующие уделили сервису Amazon SES. Вызовы "ses:GetAccount" и "ses:ListIdentities" показали, что в аккаунте нет верифицированных доменов для рассылки, а сам аккаунт находится в "песочнице" SES. Этот режим строго ограничивает отправку писем: только на проверенные адреса, не более 200 писем в сутки и со скоростью 1 письмо в секунду. Такие ограничения делали SES непригодным для немедленной масштабной фишинговой кампании.
Не теряя времени, злоумышленники запросили у поддержки AWS выход из "песочницы" SES и увеличение дневного лимита отправки до 100 000 писем. Параллельно для обеспечения устойчивости (persistence) они создали нескольких новых пользователей IAM с именами, похожими на служебные аккаунты, и назначили им политики, ограниченные только работой с SES.
Ключевым маневром стал переход на AWS WorkMail - управляемый почтовый и календарный сервис. В отличие от SES, WorkMail не имеет режима "песочницы" для отправки писем внешним получателям. Используя API "workmail:CreateOrganization", атакующие создали несколько почтовых организаций. Затем они инициировали проверку доменов, предназначенных для фишинга, таких как "cloth-prelove[.]me" и "ipad-service-london[.]com". После верификации через SES были созданы почтовые ящики, например, "service@ipad-service-london[.]com", которые выглядели как легитимные корпоративные адреса.
Для отправки писем злоумышленники могли использовать два метода. Первый - веб-интерфейс WorkMail. Письма, отправленные через него, косвенно регистрируются в CloudTrail как события "ses:SendRawEmail", поскольку WorkMail использует SES как транспорт. Однако в этих логах исходный IP-адрес указывается как служебный адрес AWS (например, "workmail.us-east-1.amazonaws.com"), что скрывает истинное происхождение трафика атакующего. Второй, более скрытный метод - прямая отправка через SMTP-протокол WorkMail. Такая активность не генерирует событий в CloudTrail, создавая серьезную слепую зону для защитников.
Этот инцидент наглядно показывает, как злоумышленники используют многоуровневую архитектуру облачных сервисов для обхода защитных механизмов. WorkMail становится промежуточным звеном, позволяя начать рассылку до одобрения AWS высоких квот для SES. Для противодействия подобным угрозам эксперты рекомендуют применять превентивные меры. Если использование AWS WorkMail не требуется бизнес-процессам, его следует заблокировать с помощью политик контроля сервисов (SCPs) в AWS Organizations. Там, где сервис необходим, нужно применять строгий принцип наименьших привилей в IAM и рассматривать администрирование WorkMail и SES как привилегированные операции. Ключевой мерой предотвращения остается минимизация риска утечки учетных данных: регулярное сканирование репозиториев на наличие секретов, ротация ключей и отказ от долгосрочных ключей доступа там, где это возможно.
Индикаторы компрометации
IPv4
- 139.59.117.125
- 3.0.205.202
- 54.151.176.0
