Угроза TWINLOOT: как вредоносный код использует облачные сервисы Microsoft для атак

Для enterprise-архитектуры это означает, что доверие к cloud traffic по имени vendor больше не может быть достаточным критерием безопасности.

Узкое место — доверенный cloud traffic

TWINLOOT был обнаружен Ontinue Cyber Defense Center при расследовании активной кампании в июле. По данным CSO Online, вредоносный framework разделяет каналы управления:

• SharePoint Online используется как file-based dead drop.
• Teams TURN применяется для интерактивных соединений.
• Headless Edge отправляет запросы к Microsoft Graph API.
• Основной C2-трафик может завершаться в IP-пространстве Microsoft, а не на attacker-controlled domain.

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

SharePoint-канал, согласно материалу, примерно каждые 15 секунд проверяет drive на наличие команд. Через него TWINLOOT получает tasking, возвращает результаты и передаёт украденные credentials и reconnaissance data. Вредоносный код аутентифицируется в attacker-controlled Azure tenant, а не в Microsoft 365 environment жертвы. Поэтому события аутентификации и аудита не появляются в логах Entra ID организации-жертвы.

Это отдельный архитектурный риск. Наличие Microsoft 365 и Entra ID не гарантирует наблюдаемость всех операций, если взаимодействие идёт через внешний tenant.

Почему стандартный EDR-контур может пропустить атаку

Для интерактивного доступа TWINLOOT способен устанавливать reverse SOCKS5 tunnel через Teams TURN infrastructure. Оператор получает возможность работать с внутренней сетью через compromised endpoint. Подключения к SMB, RDP и WinRM при этом могут выглядеть как соединения, инициированные самой машиной жертвы.

CSO Online сообщает, что это второй наблюдаемый случай злоупотребления Teams TURN in the wild и первый, где для техники применялись реальные WebRTC DataChannels. Эти детали важны не как отдельная особенность malware, а как индикатор изменения threat model: trusted collaboration services становятся транспортным слоем для доступа к внутренним системам.

Отдельный канал построен на Edge. TWINLOOT запускает браузер в headless mode, подключается через Chrome DevTools Protocol и выполняет Graph API calls как same-origin fetch-запросы из браузера. На уровне network telemetry процесс выглядит как легитимный Edge, взаимодействующий с Microsoft.

Для SOC это означает переход от контроля только доменов и IP к анализу поведения:

• нетипичная активность Microsoft Graph API;
• неожиданные OAuth applications;
• подозрительные consent grants;
• аномалии в SharePoint;
• нестандартное поведение Teams;
• запуск Edge в headless mode;
• использование DevTools Protocol на рабочих станциях, где это не требуется.

Источник также описывает механизм кражи паролей через фальшивый экран блокировки Windows 10 или Windows 11. Экран заполняется реальными данными аккаунта жертвы. Пароль не проверяется: каждая попытка перехватывается, шифруется и отправляется через SharePoint C2. Пользователь получает обычное сообщение об ошибочном пароле.

Что проверить в enterprise-стеке

Оптимальный вариант здесь не сводится к отключению Microsoft 365-сервисов. Такой подход создаёт operational impact и не устраняет abuse легитимных каналов. Контроль должен быть распределён между identity, endpoint и cloud telemetry.

Минимальный контур проверки:

• Identity. Мониторить OAuth applications, consent grants и обращения к внешним Azure tenants.
• Graph API. Выделить нетипичные паттерны запросов, особенно с endpoint, где ранее не было такой активности.
• Endpoint. Контролировать headless Edge, Chrome DevTools Protocol и процессы, инициирующие browser-based API calls.
• SharePoint. Проверять частые обращения к drive, необычные file operations и последовательность командных запросов.
• Teams. Отслеживать аномалии TURN и WebRTC DataChannels.
• Network. Не считать Microsoft IP space признаком безопасности по умолчанию.
• Lateral movement. Коррелировать обращения к SMB, RDP и WinRM с событиями на endpoint и identity-уровне.

В подборке источников также присутствуют сообщения о лидерстве Microsoft и Alphabet в cloud growth, о силе Microsoft в AI и cloud, а также о статусе Microsoft в Frost Radar для Cloud Workload Protection Platforms. Однако доступные подтверждённые данные не содержат метрик роста, финансовых показателей или деталей методологии. Использовать эти заголовки как основание для оценки cloud vendor нельзя.

Чек-лист перед пересмотром cloud security policy

• Проверить, видит ли SIEM события внешних Azure tenants.
• Включить поведенческий контроль Graph API.
• Отдельно мониторить SharePoint и Teams, а не объединять их в общий trusted-сегмент.
• Зафиксировать baseline для headless browser и DevTools Protocol.
• Пересмотреть правило, по которому Microsoft traffic автоматически считается безопасным.
• Связать identity telemetry с EDR и network detection.

Для архитектурного комитета вывод ограничен: vendor trust не заменяет runtime detection. В случае TWINLOOT периметр по доменам и IP не является достаточным control plane.