Ликвидация фишинговой сети Kratos: как PhaaS-сервисы обходят защиту Microsoft 365

Немецкие правоохранительные органы при поддержке спецслужб США и Индонезии ликвидировали инфраструктуру фишингового сервиса Kratos — крупнейшей платформы типа PhaaS (Phishing-as-a-Service). По данным SC Media, платформа обеспечивала порядка 15 000 фишинговых кампаний ежемесячно, нацеленных на кражу учётных данных Microsoft 365. Для администраторов почтовых доменов событие — прямой повод перепроверить SPF, DKIM и DMARC-политику.

Что представлял собой Kratos

PhaaS-модель: злоумышленник с минимальной подготовкой получал готовые фишинговые страницы, имитирующие интерфейс Microsoft. Критический момент — сервис перехватывал не только пароли, но и session cookies. Это позволяет обходить многофакторную аутентификацию (MFA): аутентифицированная сессия реплеится атакующим без повторного ввода второго фактора.

По данным следствия, Kratos использовался примерно 1 800 криминальными группировками. Целевые отрасли — производство, ритейл, здравоохранение, образовательные учреждения в США и Европе. Оперативная выручка сервиса — свыше €300 000 с 2024 года. В ходе операции нейтрализовано более 200 серверов, задержан предполагаемый разработчик в Индонезии.

Почему это важно для почтовой инфраструктуры

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

Письма, отправленные через скомпрометированные учётные записи легитимных пользователей, проходят SPF- и DKIM-проверки. Домен отправителя подлинный, сервер авторизован, подпись валидна. Антиспам-фильтры получателя видят легитимное сообщение. Единственный механизм, способный остановить такую атаку на уровне домена, — DMARC с политикой p=reject, настроенный на стороне получателя. Статистика указывает, что значительная доля организаций по-прежнему использует p=none или вовсе не публикует DMARC-запись. Для Kratos-подобных сервисов это — открытая дверь.

Что проверить немедленно

SPF. Убедитесь, что запись включает только авторизованные IP/механизмы. Проверьте количество DNS-lookups — не более 10. Избыточные include раздувают цепочку и вызывают permerror.

DKIM. Ротация ключей. Статичный ключ, не обновлявшийся годами, — атакуемая поверхность. Проверьте длину ключа (минимум 2048 бит), корректность селектора и наличие t=y флага только для тестирования.

DMARC. Политика p=reject. Адрес rua для агрегированных отчётов настроен и обрабатывается автоматически. p=none — не защита, а сбор телеметрии.

MX и PTR. Корректные обратные записи, принудительный TLS на входящих и исходящих соединениях.

Пользователи. Обязательное обучение распознаванию фишинга, но обучение — дополнение к техническим контролям, а не замена.

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