Шифровальщик почти никогда не начинается с шифрования. Ему предшествует вход с привилегированной учётной записи, которая раньше так себя не вела: новое устройство, первый успешный Kerberos-логин администратора, RDP-сессия в необычное время. Если SOC умеет ловить именно этот момент — до сканирования сети и бокового движения, — у команды есть часы или дни форы вместо минут. В этом практическая ценность UEBA: не сигнатура вредоноса, а статистическая аномалия в поведении учётной записи и устройства.
Что произошло
Два расследования Darktrace показывают эту логику на реальных атаках. В инциденте с Akira ransomware 21 мая 2023 года платформа зафиксировала «highly privileged credential being used for the first time on an internal server» — событие, которое само по себе не атака, но статистически аномально для аккаунта. Через неделю на тех же устройствах появились множественные RDP-подключения по порту 3389, а 30 мая — повторяющиеся ошибки Kerberos-аутентификации, типичные для перебора учётных данных. У другого клиента того же расследования домен-контроллер за короткое время установил 196 соединений на 34 внутренних IP-адреса по порту 445 с операциями чтения, записи и удаления по SMB — классическая подготовка к развёртыванию шифровальщика. Там, где атака дошла до финала, телеметрия показала почти 9000 неудачных попыток входа незадолго до появления файлов с расширением «.akira».
Похожая картина — в кейсе с DragonForce-аффилированной группой: в конце августа 2025 года Darktrace обнаружил устройство, впервые использовавшее учётную запись «administrator» через успешный Kerberos-логин. Дальше шёл перебор имён вроде «Admin», «rdpadmin», «ftpadmin», сетевое сканирование инструментом с user agent «OpenVAS-VT» и модификация реестра — и только 9 сентября, спустя почти две недели, началось шифрование файлов с расширением «.df_win». Экфильтрация данных на внешний IP произошла 2 сентября, за неделю до шифрования.
Как это работает
UEBA (User and Entity Behavior Analytics) строит поведенческий профиль — «pattern of life» — для каждого пользователя и устройства: с каких хостов он логинится, в какое время, к каким ресурсам обращается. Любое отклонение получает вес аномальности, а не бинарный вердикт «плохо/хорошо». Поэтому первый логин привилегированного аккаунта с нового устройства — сигнал, даже если аутентификация технически успешна.
Ключевое отличие от классических SIEM-правил в том, что UEBA не требует заранее описанного шаблона атаки: детектируется аномалия поведения, а не сам вредонос. Это подтверждает и более ранний кейс с неизвестным штаммом ransomware, обнаруженным без сигнатур — платформа училась «нормальному» поведению сети с первого дня и ловила отклонения до появления вредоноса в базах OSINT.
Но между обнаружением и реагированием есть разрыв, если автономный ответ не настроен. В кейсе DragonForce у клиента не была включена функция автономного реагирования, «allowing the threat to progress to data exfiltration and file encryption» — аномалия была видна рано, но без сдерживания атака всё равно дошла до финала. В кейсе Akira, где автономный ответ работал, Cyber AI Analyst собрал события в единый инцидент за 10 минут, после чего система заблокировала исходящий трафик с затронутых устройств.
Что внедрить у себя
- Стройте отдельный поведенческий профиль для привилегированных аккаунтов. Порог аномальности для администратора домена должен быть ниже, чем для рядового пользователя — первый логин с нового устройства для такого аккаунта обязан генерировать алерт всегда.
- Настройте алертинг на комбинацию признаков, а не на единичное событие. Новый IP или устройство сами по себе — слабый сигнал. Связка «новое устройство + привилегированный аккаунт + нетипичное время + последующие SMB/RDP-соединения» — сильный.
- Отслеживайте всплеск ошибок аутентификации как метрику, а не шум. Резкий рост числа неудачных входов должен эскалировать раньше, чем шифровальщик начнёт работу.
- Включайте автономное реагирование там, где это технически возможно. Разница между кейсами Akira и DragonForce — это разница между сдерживанием на этапе разведки и полноценной экфильтрацией с шифрованием.
- Учитывайте реальные временные окна между стадиями атаки. В кейсе DragonForce между первой компрометацией и шифрованием прошло около двух недель — это окно для расследования, если алерт не потерялся в очереди SOC.
- Документируйте типовые «первые» события для критичных систем: первый RDP с внешнего IP, первый Kerberos-логин с нового хоста, первое интерактивное использование сервисной учётной записи — готовые правила для UEBA-политик без сигнатур.
Чем быстрее аномальный логин превращается в приоритизированный инцидент, тем меньше нагрузка на аналитиков — похожий эффект от автоматизации триажа описан в материале о том, как специализированные модели атакующих меняют требования к телеметрии SOC, и в разборе того, как отличать реальные защитные сигналы от рекламного шума. По смежной теме полезен и разбор того, как атакующие ускоряют атаки на виртуализацию с помощью AI.
Источники: Darktrace, «How Darktrace Stopped Akira Ransomware» (darktrace.com/blog); Darktrace, «Tracking a Dragon: Investigating a DragonForce-affiliated ransomware attack with Darktrace» (darktrace.com/blog).
