CyberStrikeAI в дикой природе: использование ИИ в реальных атаках на организации

Введение

В рамках проактивного мониторинга угроз специалисты киберразведки «Лаборатории Касперского» выявили вредоносную кампанию с использованием С2-агентов, управляемых искусственным интеллектом. Подтвержденными жертвами кампании стали организации образовательного сектора в странах Африки и Латинской Америки. Ключевую роль в постэксплуатации сыграл CyberStrikeAI — открытый фреймворк, в котором LLM-оркестратор на стороне управляющего сервера планирует действия, подбирает инструменты и формирует команды, а имплант исполняет их на скомпрометированных узлах. С помощью CyberStrikeAI атакующие прошли путь от разведки до полной компрометации домена.

По нашим данным, это одно из первых публичных описаний компрометации с использованием LLM в дикой природе. На примере обнаруженной нами кампании отлично видно, как меняется роль ИИ в арсенале злоумышленников: еще недавно языковые модели использовались в основном на подготовительных этапах (для написания фишинговых писем, отладки кода и поиска уязвимостей). Теперь же они встраиваются в само ядро атаки, автоматизируя действия на всех ее этапах: выполнения полезной нагрузки, закрепления на хосте, разведки, бокового перемещения и, наконец, сбора и эксфильтрации данных. Особое место здесь занимает постэксплуатация — тот этап, который традиционно требовал ручной работы опытного оператора.

Ключевая особенность схемы с использованием ИИ-фреймворка в том, что имплант перестает быть простым средством исполнения команд оператора. Решения распределяются между двумя уровнями: оператор ставит задачу в общем виде, а модель определяет, как ее выполнить, какие конкретно команды и в какой последовательности отправить на хост. Таким образом, стратегический замысел остается за человеком, а выбор технических шагов переходит к модели, и имплант исполняет уже ее решения.

Чтобы понять, как эта схема выглядит на практике, рассмотрим цепочку действий злоумышленников, восстановленную нашими аналитиками в ходе расследования инцидентов.

Хронология атаки

Рассмотрим хронологию атаки на примере одного инцидента из обнаруженной кампании.

Первая фаза представляет собой стандартный подход: живой оператор получает доступ к инфраструктуре жертвы через скомпрометированный SQL-сервер версии 16.0.1000, после чего собирает базовую информацию о хосте, разворачивает инструментарий и проводит разведку сети. Вся эта активность занимает почти сутки, после чего наступает пауза длиной в две недели.

Вторая фаза выглядит принципиально иначе. Первым шагом в ней разворачивается C2-агент CyberStrikeAI, который получает команды от серверного LLM-оркестратора. В рамках второй фазы агент:

• выполняет закрепление и локальную разведку за 2 минуты;
• выполняет доменную разведку в течение следующих 5 часов;
• после короткой паузы в несколько дней переходит к финальной стадии — горизонтальному перемещению через SMB и WMI, массовому сбору учетных данных на хостах и выгрузке базы данных — вся активность занимает не более одного часа.

Подробнее про эти этапы расскажем в следующем разделе.

Технические детали

Немного про CyberStrikeAI

CyberStrikeAI — модульная платформа на Go с открытым исходным кодом для автоматизации пентестов. Ключевая особенность: в одном серверном процессе объединены LLM-оркестрация атаки и встроенный C2-сервер с агентами (beacon).

При этом вся «интеллектуальная» надстройка изолирована на управляющем сервере. Функции C2 (вызов утилит разведки и эксплуатации, управление вебшелл-соединениями, постановка задач агентам, чтение результатов) доступны модели в виде MCP-инструментов. Имплант же, в свою очередь, — классический C2-агент, не имеющий ИИ-функциональности — ни API-ключей, ни обращений к API ИИ-сервисов, ни автономной логики. Он периодически опрашивает сервер-обработчик по HTTP/S, TCP или WebSocket, исполняет команды оболочки и работает с файловой системой. Для жертвы активность выглядит как обычная сессия удаленного управления, где вместо живого оператора задачи в очередь ставит серверный LLM-оркестратор. LLM влияет на то, как принимаются решения, но не на то, как соответствующие им команды доставляются на хост.

Хотя CyberStrikeAI находится в открытом доступе, конкретные образцы фреймворка можно связать с конкретными злоумышленниками или кампаниями. Обнаружение и атрибуция возможны по следующим признакам.

• Панель управления: при запуске генерируется самоподписанный TLS-сертификат, в полях издателя и субъекта которого фигурирует название фреймворка. Сертификат создается в памяти при каждом старте, поэтому поле not_before фактически фиксирует время запуска процесса. Соответственно, как и у Cobalt Strike, по истории сканирования можно восстановить хронологию перезапусков.
  

  Самоподписанный TLS-сертификат панели управления CyberStrikeAI

• Имплант: в метаданных сборки (go version -m) присутствует путь к основному пакету, содержащий данные, которые указывают на встроенный генератор CyberStrikeAI — временный каталог с идентификатором сборки. Этот путь одинаков для всех нагрузок, что делает его устойчивой сигнатурой. Дополнительно в поле build info попадают метаданные системы контроля версий, пригодные для сопоставления образцов между собой.

• Аутентификация: при обращении к серверу имплант передает в HTTP-запросе заголовок X-Implant-Token с фиксированным значением. Токен уникален для каждого C2-сервера и вшивается во вредоносную нагрузку на этапе сборки, поэтому служит и сетевым индикатором, и признаком принадлежности образцов одному серверу.

Следует учитывать, что версия импланта не отражает версию сервера. Имплант может работать месяцами, пока оператор обновляет серверную часть: настройки обработчиков и ключи при обновлении сохраняются. В обнаруженных инцидентах мы наблюдали использование одной версии агента в течение всего инцидента. В таком случае дата сборки образца может указывать на нижнюю границу времени развертывания инфраструктуры CyberStrikeAI, но все еще не является оценкой срока компрометации.

Execution & Privilege Escalation

Первые вредоносные команды в системах жертв исследованной кампании исходили от процесса sqlservr.exe, что указывает на предполагаемый вектор первоначального доступа и контекст, в котором злоумышленники получили возможность исполнять код. Важно отметить: команды, помеченные как исполняемые до установки агента, выполнялись злоумышленником в ручном режиме именно в контексте этого процесса. На этом этапе мы имеем дело еще не с автоматизированной активностью импланта, а с ручными действиями оператора.

Перед запуском агента на машинах злоумышленники проверяли его наличие PS-скриптом, из которого можно сделать вывод о путях его размещения по умолчанию: C:\Windows\Temp\, C:\Windows\, C:\ProgramData\, C:\Temp. При этом злоумышленник может маскировать имя агента под легитимные системные процессы. Так, в примере ниже он мимикрирует под svchost.exe (svchosts.exe).

Как и большинство С2-агентов для Windows, CyberStrikeAI использует PowerShell для выполнения полезной нагрузки. При запросе от оператора выполняемые команды дополнительно оборачиваются в кодировку Base64 для обхода детектирования по ключевым словам.

Декодированный вид команды:

При наличии административных привилегий (например, учетной записи доменного администратора) вместо прямого исполнения команд агент на удаленных хостах часто создавал запланированные задачи, чтобы вредоносная нагрузка имела привилегии SYSTEM:

Альтернативный вариант без использования schtasks — создание задачи через COM-объект Schedule.Service:

Полезная нагрузка (p1.ps1) из примера выше представляет собой обратную оболочку (reverse shell), соединяющуюся с сервером по адресу 185.186.245[.]144:5501:

Распространение по сети p1.ps1 и подобных скриптов осуществлялось с помощью общих сетевых административных папок и протокола WMI, что мы подробнее опишем в разделе Lateral Movement.

Stealth

Помимо кодирования команд в Base64 и обфускации SQL/LDAP-запросов, которую мы опишем в разделах Collection & Exfiltration и Discovery соответственно, злоумышленники применяли разбиение вредоносной нагрузки на несколько файлов. Примечательно, что скрипты передавались подобным образом еще до установки агента, то есть на этапе, где обычно работает человек, но при этом носят явно сгенерированный LLM характер.

Ниже приведена последовательная запись нескольких кусков скрипта в файл d3.b64.

Впоследствии злоумышленники использовали утилиту certutil для декодирования получившегося файла и запускали его следующей командой:

В собранном и декодированном виде содержимое скрипта выглядело так:

Скрипт представляет собой инструмент для расшифровки DPAPI-секретов из файла C:\ProgramData\dsn_line.txt. Файл, в свою очередь, заполняется следующей командой, которая ищет строку DSN, содержащую настройки подключения, в конфигурационном файле SQL Server Reporting Services rsreportserver.config и копирует ее содержимое в dsn_line.txt.

Отдельно стоит отметить, что в ряде скриптов, переданных и запущенных вышеописанным способом, встречаются комментарии на китайском языке (## — комментарии исследователя).

Persistence

В случае успешной доставки импланта CyberStrikeAI первым шагом было закрепление в целевой системе. Для этого агент создавал запланированную задачу с именем SystemUpdate, в которой был указан путь к импланту в качестве выполняемого действия:

Анализ исходного кода фреймворка показал и альтернативный способ закрепления: через добавление ключа в ветку реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Run, причем имя создаваемого ключа совпадает с именем задачи (SystemUpdate).

Закрепление агента в Linux-системах также реализовано в двух вариантах: через добавление записи @reboot <path_to_beacon> & в пользовательский crontab (в таком случае процесс запускается при старте системы) либо через добавление строки (nohup <path_to_beacon> &>/dev/null &) в ~/.bashrc (в этом случае агент стартует при открытии интерактивного bash-шелла).

Примечательно, что выбор конкретного метода закрепления делегируется подключенной к CyberStrikeAI LLM. Однако благодаря механизму Human-in-the-Loop (HITL) оператор сохраняет полный контроль над процессом: сгенерированные моделью команды могут требовать обязательного ручного согласования или корректировки перед их фактическим выполнением.

Discovery

Local Discovery

До установки агента на подконтрольном хосте злоумышленники в ручном режиме собирали базовую информацию о системе с помощью довольно тривиального набора команд:

Также в ручном режиме злоумышленники использовали для проверки доступа в интернет и получения внешнего IP зараженных машин китайский сервис dnslog[.]cn. Сервис генерирует случайный домен третьего уровня, после чего атакующий пытается разрешить его на скомпрометированной машине.

Если машина имеет доступ в интернет, запрос проходит успешно и на странице сервиса злоумышленники получают внешний IP-адрес подконтрольного устройства.

Агент же в целях разведки генерирует более сложный скрипт, назначение которого — наметить путь дальнейшего повышения привилегий через компрометацию SCCM или эксплуатацию msiexec (ключ AlwaysInstallElevated):

Также с целью поиска способов локально повысить привилегии агент исполнял скрипты для инвентаризации служб, запущенных от имени доменных учетных записей, и задач, работающих от имени SYSTEM:

В ходе своей активности злоумышленники периодически проверяли срабатывания Microsoft Defender:

Remote Discovery

После сбора информации о подконтрольном хосте злоумышленники переходили к разведке внутри сети. На подготовительном этапе атаки злоумышленники вручную собирали дополнительную информацию об удаленных узлах с помощью утилиты net.exe.

На основном этапе для обнаружения доступных узлов без дополнительных утилит (nmap, fscan и др.) агент использовал встроенную функциональность PowerShell:

Также карту сети помогали составить соответствующие LDAP-запросы к объектам Active Directory:

Дополнительно проверялось наличие установленного агента на удаленных хостах с помощью WMI:

Domain Discovery

Следующим этапом было получение информации о домене жертв. С этой целью до установки агента злоумышленники использовали стандартные утилиты ОС:

Однако впоследствии силами импланта CyberStrikeAI разведка выполнялась с помощью сгенерированных PS-скриптов:

Помимо базовой информации о домене, агент выполнял LDAP-запросы по сбору информации для атак Kerberoasting / AS-REP Roasting:

Дополнительно с помощью агента проводилась проверка наличия в домене LAPS и Microsoft Azure:

Также для обнаружения признаков использования Microsoft Azure в инфраструктуре злоумышленники выполняли поиск каталога .azcopy, создаваемого утилитой AzCopy (Microsoft Azure Storage Copy) в домашних директориях пользователей:

Credential Access

После успешной разведки и построения карты сети атакующие переходили к следующему этапу — дампу учетных данных. Для этой цели агент использовал классический набор из LOLBIN-утилит и известных сторонних инструментов.

Дамп кустов реестра с учетными данными осуществлялся агентом с помощью утилиты reg.exe:

Дамп процесса lsass.exe агент совершал через функцию MiniDump библиотеки comsvcs.dll. При этом вместо имени целевого процесса использовался его PID для затруднения статического детектирования по командной строке:

После успешной компрометации привилегированных доменных учетных записей (в частности, встроенного доменного администратора) злоумышленники также через агента проводили атаки DCSync и Golden Ticket с помощью переименованной утилиты mimikatz:

Lateral Movement

Для распространения по сети с использованием скомпрометированных учетных записей злоумышленники применяют утилиты из набора Impacket, в частности WMIExec, о чем говорит характерная командная строка утилиты:

Агент же после установки предпочитает использовать такие стандартные механизмы ОС, как общие сетевые папки.

Еще одним способом удаленного выполнения команд агентом является протокол WMI. С его помощью, в частности, агент распространял вышеупомянутый скрипт обратной оболочки p1.ps1. При этом использовались скомпрометированные учетные записи пользователей, имеющих привилегии локального администратора на целевых хостах:

Второй вариант реализации бокового перемещения через WMI использует командлет Invoke-CimMethod:

Command & Control

Для доставки вышеупомянутого инструментария (вредоносных скриптов, mimikatz и самого агента) на первичные узлы в цепочке заражения злоумышленники использовали стандартные утилиты ОС:

После установки агента он выполняет проверку доступности портов C2-сервера. Механизмы реализации здесь практически не ограничены и зависят от «фантазии» той или иной LLM, подключенной к серверу агентов:

Для загрузки дополнительных утилит имплант CyberStrikeAI также использовал встроенные утилиты (LOLBINS). Инструментарий мог размещаться на собственных серверах или скачиваться напрямую с GitHub:

Collection & Exfiltration

Отдельного внимания заслуживает этап сбора данных. На нем проявляется еще одна возможность LLM-оркестрации — автоматическая генерация SQL- и LDAP-запросов под конкретную задачу.
В одном из инцидентов кампании злоумышленники развернули имплант CyberStrikeAI на SQL-сервере образовательной организации и выполняли сбор информации из базы данных через PowerShell. Пример команды, которую выполнял агент:

Нормализованный вид выполняемого скрипта с комментариями:

Прежде чем обращаться к данным, агент проверял привилегии учетной записи, под которой он подключался к базе данных:

В декодированном виде проверка выглядит следующим образом:

На сетевых ресурсах сбору файлов предшествовал рекурсивный обход каталогов, позволявший выявить представляющие интерес файлы.

Для взаимодействия с файловой системой имплант предоставляет встроенный интерфейс, поддерживающий прямую загрузку и скачивание файлов. Передача файлов происходит непосредственно через основной зашифрованный канал связи с C2 (HTTP или TCP), а сами данные кодируются в Base64 и упаковываются в стандартные JSON-ответы агента.

К числу встроенных примитивов импланта относится и создание снимков экрана зараженной машины. Как и остальные действия, имплант не инициирует его самостоятельно: команду на захват экрана ставит LLM-оркестратор, а агент лишь выполняет ее и возвращает результат по тому же каналу управления.

В Windows команда для создания скриншотов выглядит следующим образом:

Linux-вариант выглядит следующим образом:

При этом сбор данных в обнаруженных нами атаках был конечным звеном атаки: цепочка на нем завершалась, и дальнейшей активности мы не наблюдали.

Атрибуция

Ключевым артефактом для атрибуции в этой кампании служат метаданные сборки имплантов. Атакующие собирали вредоносную нагрузку внутри git-клона проекта, поэтому компилятор Go встроил в бинарные файлы сведения системы контроля версий — хэш и время коммита, а также флаг vcs.modified=true (аналог суффикса +dirty), указывающий на незафиксированные локальные изменения в рабочей копии. Совокупность этих полей образует уникальный отпечаток конкретной сборки.

По этому отпечатку образцы распадаются на две независимые связки, в каждой из которых имплант под Windows и имплант под Linux имеют полностью идентичные метаданные сборки. Совпадение означает, что внутри каждой связки обе нагрузки собраны в одной и той же рабочей копии проекта.

Между собой эти связки, однако, не пересекаются. У них нет общей C2-инфраструктуры, а на управляющих серверах развернуты разные версии CyberStrikeAI. То есть метаданные сборки надежно объединяют образцы внутри каждой связки, но не дают оснований объединить обе связки между собой.

Имеющиеся данные не позволяют ни связать активность с какой-либо известной группой злоумышленников, ни уверенно утверждать, что за обеими связками стоит один и тот же оператор. Этому мешают два обстоятельства. Во-первых, открытость инструмента: CyberStrikeAI находится в публичном доступе, поэтому разные операторы могли независимо развернуть его и собрать вредоносную нагрузку в сходных условиях. Во-вторых, генерация команд моделью: характерный для конкретного оператора «почерк» в значительной степени формирует не человек, а LLM. Это, с одной стороны, увеличивает многообразие команд: одна и та же команда, сгенерированная несколько раз, может выглядеть по-разному. С другой — лишает их индивидуальных черт, что снижает ценность поведенческих метрик для атрибуции.

Однако найденные в скриптах злоумышленников комментарии на китайском языке и использование китайских сервисов все же позволяют предположить связь активности с китайскоязычным оператором. Кроме того, аналитики обратили внимание на распределение времени перезапуска управляющих серверов: поскольку самоподписанный TLS-сертификат пересоздается при каждом старте процесса, его поле not_before фиксирует момент перезапуска, и эти моменты в большинстве своем приходились на рабочие часы по времени UTC+8.

Косвенно в ту же сторону указывает и происхождение самого инструмента: CyberStrikeAI разрабатывался в китайском ИБ-сообществе и пользуется в нем известностью.

Подводя итог

CyberStrikeAI — показательный, но не уникальный пример сдвига, который происходит в классе C2-фреймворков: LLM-оркестратор перестает быть надстройкой над разведкой и становится управляющим слоем над постэксплуатацией. Если HexStrike AI и аналоги закрывают этап «найти и сломать», а Sliver/Mythic/Havoc — этап «закрепиться и управлять», то CyberStrikeAI замыкает цикл: единый серверный процесс на Go вызывает утилиты через MCP, обслуживает вебшелл-соединения и ставит задачи импланту, а модель анализирует результаты и решает, что делать дальше.

Ключевой вывод состоит в том, что появление ИИ в цепочке атаки пока не ставит перед детектированием принципиально новых задач. Вся «интеллектуальная» часть остается на стороне атакующего, а до скомпрометированного хоста доходят привычные действия: от разведки под Kerberoasting и AS-REP Roasting до дампа LSASS, DCSync и Golden Ticket. Это типовой, хорошо документированный набор техник компрометации домена. Новизна атаки заключается не в методах, а в скорости и легкости, с которыми их удалось реализовать: ИИ-оркестрация снизила требования к квалификации оператора, но не вывела атаку за пределы того, что защитникам уже известно и что они умеют обнаруживать. Показателен и тайминг: отдельные ключевые фазы активности (такие как закрепление, боковое перемещение и получение учетных данных) занимали считаные часы, а вся атака — от установки агента до компрометации доменных администраторов — укладывалась в 3–4 дня.

Однако ограничиваться описанным сценарием архитектура CyberStrikeAI не вынуждает. Те же механизмы позволяют по запросу собирать и более сложные цепочки — с извлечением секретов DPAPI, атаками на SCCM и Azure IMDS, — и все это оказывается в руках того же круга исполнителей, порог входа в который довольно низок. По мере развития моделей разрыв между сложностью оркестрации и уровнем применяемых техник будет сокращаться, а роль оператора — постепенно смещаться от постановки задач к контролю за действиями модели.

Детектирование решениями «Лаборатории Касперского»

Как может показаться, атаки с использованием ИИ-агентов требуют создания принципиально новых правил детектирования. Безусловно, для обнаружения активности агента LLM, который установлен на хост внутри инфраструктуры, необходимо создавать детектирующую логику, которая опирается на специфику агентов. Правила детектирования данной активности можно найти с помощью Hunt Hub, используя следующий фильтр.

Однако в случае описанной атаки работает иная логика. Главное отличие кроется в архитектуре самой атаки: агент LLM не находился внутри периметра корпоративной сети. Он работал удаленно через агент С2, оркестрируя действия, и не оставлял в инфраструктуре следов своего присутствия (например, специфических API-запросов к локальным LLM или аномальных паттернов потребления ресурсов хостами).

Ключевая разница между этой активностью и атакой опытного злоумышленника заключается по большей части в скорости. Тактически, технически и методологически ИИ в своей массе использует ровно те же инструменты, утилиты и техники, что и живой пентестер. Он не пишет уникальные эксплойты с нуля, а скорее комбинирует известные методы и динамически подстраивает их под ситуацию, справляясь с ошибками этих инструментов самостоятельно.

Поскольку действия, совершаемые под управлением ИИ-агента в сети, неотличимы от человеческих, для его обнаружения достаточно использовать классические, хорошо настроенные правила корреляции и поведенческого анализа. Вот несколько примеров того, как Kaspersky Endpoint Detection and Response (KEDR) Expert успешно детектирует представленную атаку:

• Для обнаружения исполнения вредоносного скрипта через удаленную запланированную задачу необходимо отслеживать создание процесса schtasks.exe с аргументами /s. Решение KEDR Expert детектирует эту активность с помощью правил create_task_on_remote_host_using_standard_tool, scheduled_task_creation_as_system_via_schtasks, scheduled_task_with_powershell_execution.
  
• В ходе атаки злоумышленнику потребуется доступ к учетным данным жертвы. В данном случае один из способов их получения — это широко известная техника с использованием легитимных инструментов для дампа LSASS, а именно вызов функции MiniDump из comsvcs.dll. Решение KEDR Expert детектирует эту активность с помощью правил dumping_memory_with_com_services_dll и suspicious_lsass_memory_access.
  
• Значимой частью цепочки атаки является горизонтальное перемещение, которое помогает злоумышленнику двигаться внутри инфраструктуры и достигать желаемых целей. В данном случае используется протокол WinRM, инициируя подключения напрямую из PowerShell. Это стандартная техника, которая позволяет злоумышленнику выполнять команды на удаленных машинах без использования дополнительных сетевых туннелей. Решение KEDR Expert детектирует эту активность с помощью правил using_powershell_for_remote_execution_via_wmi и winrm_send_command.
  

Для обнаружения вредоносной активности в сетевом трафике используется Kaspersky Anti Targeted Attack (KATA) с модулем NDR. Коммуникация агентов CyberStrikeAI с командным сервером происходит без обращения к ИИ-платформам, таким как ChatGPT или Claude. Вместо этого в роли С2-сервера агента выступает заранее подготовленная злоумышленниками инфраструктура, как и при атаках без использования ИИ-агентов. Анализ расшифрованного сетевого трафика решениями класса NDR позволяет выявлять характерные признаки коммуникации, свойственные активности агентов CyberStrikeAI.

При их наличии KATA генерирует оповещение с вердиктом Backdoor.CyberStrikeAI.HTTP.C&C.

Для обнаружения постэскплуатационной активности можно использовать не только технологию IDS, но и NAD (Network Anomaly Detection). Она анализирует весь трафик на предмет подозрительных признаков, которые не соответствуют типичной сетевой активности узла.

Например, действия, совершаемые CyberStrikeAI во время этапа Domain Discovery, обнаруживаются правилом NDR:NAD с именем «Изучение доменных учетных записей через LDAP-запросы».

Подробнее ознакомиться с технологией NDR:NAD можно в нашей статье на Securelist.

Также на портале Kaspersky Threat Intelligence в разделе Research Graph можно визуализировать и посмотреть связи C2-адресов и файлов, используемых злоумышленниками. В том числе можно отследить появление новых имплантов CyberStrikeAI, обращающихся к вредоносным адресам.

К тому же доступный на портале сервис Threat Lookup позволяет установить принадлежность вредоносных файлов к CyberStrikeAI при помощи механизмов атрибуции на основе кода исполняемого файла.

SIEM-система Kaspersky Unified Monitoring and Analysis Platform (KUMA) детектирует все стадии атаки агентом CyberStrikeAI. В репозитории продукта доступны более 100 правил для детектирования исследованных техник. Перечислим наиболее критичные из них.

Выполнение различных команд от процесса sqlservr.exe:

• R300_04_Запуск Windows shell веб-приложением

Загрузка и выполнение полезной нагрузки через PowerShell:

• R110_03_Загрузка и выполнение кода на PowerShell

Создание запланированных задач Windows:

• R099_04_Подозрительные аргументы при запуске schtasks.exe
• R300_03_Запуск Windows shell планировщиком

Закрепление через crontab или bashrc:

• R099_06_Подозрительные действия с задачами cron
• R405_02_Модификация конфигурации Shell

Сбор информации о хостах, настройках сети и домене различными утилитами разведки детектируют правила, расположенные в пакете по пути KUMA Packages/SOC package/Configuration discovery. Правила, агрегирующие детекты по инструментам разведки:

• R224_14_Разведывательная активность на Windows
• R224_09_Сбор информации о системе с помощью разных утилит в течение короткого промежутка времени
• R224_04_Сбор информации о системе стандартными средствами Linux

Сбор данных для Kerberoasting и AS-REP Roasting:

• R034_01_Массовый перебор TGS-билетов (Kerberoasting)
• R452_18_AS-REP Roasting

Дамп кустов реестра с учетными данными с помощью утилиты reg.exe:

• R230_02_Копирование данных с учетными данными из реестра Windows

Дамп процесса lsass.exe осуществлялся через функцию MiniDump библиотеки comsvcs.dll:

• R233_04_Дамп памяти процесса с помощью comsvcs.dll
• R262_Подозрительный доступ к процессу LSASS

Атаки DCSync и Golden Ticket с помощью переименованной утилиты mimikatz:

• R073_Атака DC Sync
• R450_41_Атака Golden ticket
• R100_03_Следы использования Mimikatz через cmd

Перемещение по сети при помощи WMIExec:

• R460_08_Горизонтальное перемещение с использованием WMIexec Impacket
• R460_09_Горизонтальное перемещение с использованием WMIexec Impacket

Для работы правил необходимо настроить поступление соответствующих событий в SIEM-систему:

• Запуск процессов (Windows security log — 4688, auditd — execve) и команды PowerShell (4104)
• Авторизация пользователей в системе (Windows security log — 4624, 4768, 4769)
• Манипуляции с различными объектами (Windows security log — 4662, 4663, 4656, auditd — openat)
• Взаимодействие с общими ресурсами (Windows security log — 5145)

Индикаторы компрометации

Файловые индикаторы:

CyberStrikeAI Windows Beacon
D726A8B4886C636F76CA6D30EF6A6FF4	c:\windows\temp\svchosts.exe
2770562d104391b92b42671c270079bb	c:\windows\temp\svcmon32.exe c:\programdata\svcmon32.exe
CyberStrikeAI Linux Beacon
09e1da2afa1216ecc55648ec8e122d2a
805B9E4AE74C903787416800999B8418
Tools & Scripts
29EFD64DD3C7FE1E2B022B7AD73A1BA5	C:\Windows\Temp\wdiag2.exe (mimikatz)
74F57B3E897A4960DCDD5B7E8A54F9DF	c:\rwx\RogueWinRM.exe
0BBD08AF95F877F1D568B03DE2EB76B4	c:\ProgramData\p1.ps1 (Reverse Shell PS Script)

Сетевые индикаторы:

185.186.245[.]144	C2 для Windows Beacon
fastcdn[.]bar	C2 для Windows Beacon
media.fastcdn[.]bar	С2 для Linux Beacon
104.234.26[.]163	С2 для доставки полезной нагрузки + Linux Beacon