Эталонно, по плейбуку: валидируем сложные алерты и фолзы вместе с экспертами PT NAD

Пересказ

Мы сделали расшифровку вебинара для тех, кто предпочитает читать.

Главное

• «Фолс или Тру?» — премьера шоу Positive Technologies, где эксперты разбирают реальные алерты PT NAD и учат отличать ложные срабатывания от настоящих атак.
• Разобрано шесть кейсов: от атак на периметр до обнаружения вредоносного ПО — с конкретным алгоритмом верификации каждого.
• Сигнатура — не черный ящик, а взгляд живого эксперта на угрозу, и она может ошибаться. Слепо доверять алертам нельзя.
• Использовать ChatGPT для верификации алертов — плохая идея: нейросеть склонна подтверждать то, о чем ее спрашивают.

Философия экспертизы: почему сигнатура — это не приговор

Сигнатура — это «кусочек эксперта» (в записи с 02:15)

Значительная часть пользователей воспринимает экспертизу продукта как черный ящик, который не может ошибаться и которому можно безоговорочно доверять. На самом деле она основана на опыте эксперта — на том, что ему показалось интересным и важным в определенный момент. Получается, что на формирование сигнатуры может повлиять человеческий фактор. А значит, она может быть субъективной, неполной или даже ошибочной.

Два типа ложных срабатываний и почему их нельзя путать

• False positive: сигнатура сработала на то, на что срабатывать не должна была. Это ошибка правила — оно задетектировало легитимную активность как вредоносную.
• Неинтересный алерт: сигнатура сработала корректно, но событие не представляет реальной угрозы. Например, попытка эксплуатации уязвимости на периметре, которая происходит ежедневно и никогда не бывает успешной.

Почему это важно? Потому что работать с ними нужно по-разному. Первый тип — повод сообщить вендору об ошибке в сигнатуре. Второй — откалибровать приоритеты своего мониторинга.

Инструменты аналитика: что есть в PT NAD для верификации

Эксперт перечислил инструменты, доступные пользователям PT NAD (в записи с 06:46):

• Название правила — 5–7 слов, которые сразу должны давать понимание типа активности.
• Приоритет (красный, желтый, синий) — первый ориентир при триаже. Красные алерты требуют немедленного внимания, синие — это в основном информационный шум.
• Описание и рекомендации — вручную написанный текст от экспертов. Содержит объяснение атаки, подсказки по верификации и инструкции на случай истинного срабатывания.
• Плейбуки (появились в релизе PT NAD 12.3) — подробный документ с описанием атаки, скриншотами, алгоритмом проверки «фолз или не фолз» и инструкцией по дальнейшим действиям при подтверждённом инциденте. Плейбук закрывает потребности оператора любого уровня.
• Насмотренность — личный опыт аналитика. К сожалению, без нее никуда: знакомый алерт в третий раз воспринимается совсем иначе, чем в первый.
• Техподдержка и публичный чат — всегда можно написать тикет или задать вопрос в чате сообщества.

Почему ChatGPT не подходит для верификации алертов

Нейросети любят потакать пользователю. Если в описании сказано «атака», скорее всего, нейросеть подтвердит, что это атака. Более того, она может выдумать несуществующую атаку просто потому, что хочет казаться полезной. Вывод однозначный: для верификации конкретных алертов с реальным payload’ом необходимо использовать инструменты PT NAD, плейбуки и обращаться к экспертам.

Разбор реальных кейсов

Эксперты подготовили шесть кейсов, отсортированных от простых к сложным — это реальные алерты с сенсоров PT NAD, из обращений в техподдержку и с расследований.

Кейс 1: эксплуатация уязвимостей (в записи с 11:40)

Контекст: типичная ситуация для любого периметра. На экране — алерт желтого приоритета с описанием, указывающим на попытку эксплуатации уязвимости в серверных компонентах фреймворка React.

Алгоритм верификации:

1. Читаем описание — в нем явно указано, где именно в запросе содержится вредоносная команда (JSON-объект с ключом _prefix).
2. Смотрим payload и находим указанный объект. Внутри — конструкция на неизвестном языке, которая выполняет connect на определенный IP-адрес с портом. Не нужно быть программистом, чтобы понять: что-то неладное.
3. Проверяем IP-адрес — он совпадает с IP-адресом источника запроса. Это значит, что в случае успешной эксплуатации атакованный хост соединился бы обратно с атакующим.
4. Открываем плейбук и находим алгоритм проверки: прочитать описание уязвимости в карточке атаки, убедиться, что в указанном поле есть вредоносная команда, и проверить, были ли после попытки эксплуатации исходящие соединения на этот IP-адрес.
5. Проверяем сессии — во вкладке сессий используем фильтр dst.ip. Исходящих соединений не было.

Вывод: алерт оказался true positive, но атака была неуспешной. Злоумышленник пытался атаковать вслепую — не факт, что на сервере вообще есть React. Желтый приоритет обоснован: такие попытки происходят ежедневно и редко приводят к компрометации.

Кейс 2: /dev/tcp shell (в записи с 19:50)

Контекст: алерт срабатывает на взаимодействие между двумя хостами внутри локальной сети. Название сигнатуры — dev tcp shell.

/dev/tcp — это встроенный механизм Linux, позволяющий перенаправить ввод-вывод в TCP-сокет без дополнительного инструментария. Классический пример Living off the Land (LotL) — использование легитимных возможностей ОС для атаки. Именно поэтому сигнатура выглядит тревожно.

Алгоритм верификации:

1. Смотрим payload — строка /dev/tcp действительно присутствует, рядом слово bash. Но внимательно читаем дальше: в payload встречается Microsoft Windows Security Auditing и другие слова, характерные для системных логов.
2. Проверяем соединение — dev/tcp указывает на localhost, порт 25. Злоумышленник не стал бы устанавливать reverse shell на localhost.
3. Смотрим метаданные сессии: объем данных — около 100 МБ или 72 000 пакетов, продолжительность сессии 2 часа 3 минуты. Reverse shell 2 часа жить не будет — злоумышленник давно бы переключился на другой способ коммуникации.
4. Проверяем баннеры отправителя и получателя: User Agent — Grafana, сервер — LogSpace, что намекает на то, что это просто система мониторинга логов.

Может ли хакер мимикрировать под Grafana или Logspace? Может, но это требует значительных трудозатрат. Мимикрировать и под клиента, и под сервер одновременно — крайне низкая вероятность. Подделать ответы сервера и скрафтить сессию таким образом практически невозможно.

Вывод: алерт оказался false positive. Это штатная передача логов из Grafana в LogSpace. Сигнатура при этом правильная — при реальных инцидентах она успешно выявляет хакерские реверс-шеллы.

Кейс 3: шифрованное соединение (в записи с 27:05)

Контекст: два красных алерта на зашифрованное соединение. Сигнатуры — Ligolo и Fast Reverse Proxy. Оба инструмента используются для туннелирования трафика внутри TLS.

Как PT NAD детектирует зашифрованный трафик? Через технологию ETA (Encrypted Traffic Analysis) — анализ не содержимого пакетов, а их метаданных: длин пакетов, интервалов между ними, направлений. Конкретная последовательность длин пакетов является уникальным «отпечатком» инструмента.

Алгоритм верификации:

1. Смотрим описание → инструмент ligolo может применяться как легитимно, так и злоумышленниками.
2. Изучаем метаданные: есть домен из базы PDNS, таймлайн показывает, что алерты не единичные — они повторяются несколько суток подряд. Это серьезный аргумент: единичный алерт мог бы быть случайным, но постоянная активность говорит о реальном использовании инструмента.
3. Проверяем репутацию в VirusTotal. Один детект на IP-адрес (не приговор, но повод насторожиться). Домен зарегистрирован семь лет назад (внушает доверие). Связанные домены указывают на iitbuzz.net с иероглифами и доменной зоной .cm — напоминает IoT-сервис.
4. Делаем предположение — возможно, это IoT-устройство (камера, датчик), которое использует Ligolo для связи с сервером производителя.

Вывод: однозначно нельзя закрыть как фолз. Рекомендуется дальнейшее расследование: выяснить, что за хост генерирует эту активность, найти его серый IP-адрес, определить роль устройства в сети.

Кейс 4: загадочный PROXY SystemBC (в записи с 33:50)

Контекст: алерт на ВПО SystemBC — тип Proxy Malware. После запуска SystemBC соединяется с C2-сервером и по команде злоумышленника проксирует трафик внутрь зараженной инфраструктуры.

В карточке атаки написано: атакующий — хост внутри локальной сети, атакуемый — внешний узел в CDN-сети Akamai. Дело в том, что правила обнаружения ВПО настроены так, что атакующим считается адрес C2-сервера, даже если трафик инициирован изнутри. Потому что в 99% случаев ВПО стучится на сервер управления — и именно этот сервер является угрозой.

Но в данном случае все наоборот: инициатор соединения — внешний IP-адрес (172.105.80.201), порт 443. Это значит, что запрос пришел снаружи, прошел через reverse proxy или балансировщик и попал на внутренний хост.

Проверяем VirusTotal — по этому IP-адресу есть жалобы на beacon detection, port scanning, ICMP requests. Это признаки исследователей безопасности (Shodan, Censys и аналоги), которые сканируют весь IPv4-диапазон в поисках C2-серверов определенного ВПО, имитируя их приветственные пакеты.

По итогам обращений в техподдержку правило было исправлено — добавлено четкое направление HomeNet → ExternalNet. Параллельно создано новое правило синего приоритета, которое детектирует именно такие входящие сканы — для информирования аналитиков, но без ложной тревоги.

Вывод: алерт оказался false positive. Хост внутри сети не заражен — это внешние исследователи безопасности сканируют интернет.

Кейс 5: ужасный ROOTKIT Poortry (в записи с 43:00)

Контекст: алерт с названием Rootkit Poortry. Эксперт признается, что если бы он увидел такое срабатывание у себя, точно не смог бы спокойно уйти домой. Rootkit Poortry — вредоносный драйвер, который злоумышленники доставляют на зараженные хосты для деактивации средств защиты информации (антивирусов, EDR).

Алгоритм верификации:

1. Смотрим карточку — атакующий и атакуемый находятся в домашней сети. Первый вопрос: как руткит атакует изнутри?
2. Анализируем payload. Это SMB-сессия с очевидной передачей данных. Payload выглядит подозрительно — сигнатура правильно сработала на характерные байты.
3. Смотрим детали сессии → SMB-сессия с успешной аутентификацией и авторизацией. Передаются данные, похожие на логи или телеметрию.
4. Итог: с высокой вероятностью это передача телеметрии Kaspersky Antivirus по протоколу SMB.

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

В момент разбора этого кейса эксперты неверно атрибутировали активность — приняли ее за Rootkit Poortry, хотя на самом деле это был Ratnik (другое ВПО). Это иллюстрирует тезис из начала вебинара: человеческий фактор присутствует не только в ложных срабатываниях, но и в атрибуции.

Вывод: false positive. Это один из наиболее показательных примеров фолза первого типа — ошибки самой сигнатуры. Правило исправлено.

Кейс 6: подозрительный ET Conficker (в записи с 49:20)

Контекст: три алерта от правил Emerging Threats (ET) — внешней базы сигнатур, которую PT NAD также поддерживает. Правила написаны на несколько вредоносных семейств, в том числе на знаменитого червя Conficker.

Алгоритм верификации:

1. Смотрим payload — открытый текст, не зашифрован и похож на DNS-запрос в зоне .local.
2. Анализируем сессию: протокол определен как mDNS, адресат — не unicast IP, а broadcast/multicast.
3. Гуглим payload — запрос на pantum-5TDFB4.local. Pantum — производитель принтеров. Хост ищет принтер в локальной сети через mDNS.
4. Смотрим историю правила: правила давно закомментированы в стандартном наборе Emerging Threats. Само правило датируется 2010 годом.

Как эти правила вообще оказались включены? Эксперт предполагает, что кто-то из пользователей решил «включишь побольше — детектируешь получше». На самом деле больше правил не повышают защиту. Это лишь больше ложных срабатываний, которые затрудняют анализ. Правила PT Security разработаны по принципу «необходимо и достаточно». Даже без ET-правил ничего не будет пропущено в сети.

Вывод: алерт оказался false positive. Это безобидный mDNS-запрос для поиска принтера.

Вопросы от зрителей (в записи с 58:00)

Вопрос: зритель прислал скриншоты алерта.

Анализ в прямом эфире: сработала хорошо известная сигнатура на Snake Keylogger — вредоносное ПО, которое после запуска пытается определить свое местоположение (external IP check). Особенность правила: оно написано на конкретный захардкоженный User-Agent и конкретный набор заголовков, который используется именно в этом вредоносе.

Признаки истинного срабатывания:

• User-Agent выглядит обычным, но он устаревший.
• Порядок заголовков HTTP жестко зафиксирован — в реальных браузерах он другой.
• Отсутствуют дополнительные заголовки, характерные для легитимных HTTP-запросов.

Вывод: true positive. Рекомендуется разобраться в причинах появления ВПО в инфраструктуре.

Вопрос: почему направление атаки и направление сессии не совпадают?

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

Дополнительный нюанс: когда сигнатура срабатывает на DNS-запрос к вредоносному домену, атакующим может отображаться промежуточный DNS-резолвер (часто — контроллер домена), а не сам хост-инициатор запроса. Всегда проверяйте направление сессии — оно точно подскажет, кто с кем взаимодействовал в реальности.

Вопрос: как расследовать атаки с ICMP-туннелями?

Ответ: PT NAD обнаруживает ICMP-туннели через встроенный механизм PT DPI по статистическим признакам. Но ICMP используется настолько широко (роутеры, IoT, устройства Apple, системы телеметрии), что однозначно отличить туннель от легитимного трафика крайне сложно.

Рекомендованный алгоритм:

1. Посмотрите, как часто срабатывает алерт и с каких узлов.
2. Много ли таких хостов.
3. Проверьте репутацию IP-адреса назначения в VirusTotal.
4. Если ни один признак не поднял «флажок подозрительности» — скорее всего, это легитимная телеметрия.

Если хотите больше практики — следите за следующими выпусками, в которых мы будем разбирать репутационные списки, модули ленты активностей и другие типы экспертизы PT NAD.

FAQ

1. Что такое false positive в PT NAD и чем он отличается от ложного срабатывания? В PT NAD принято различать два случая. Первый — «классический» false positive: сигнатура сработала на легитимную активность, которую она не должна была детектировать (ошибка правила). Второй — «неинтересный алерт»: сигнатура сработала технически верно, но событие не несет реальной угрозы (например, ежедневные попытки эксплуатации уязвимостей на периметре, которые никогда не бывают успешными). Работать с ними нужно по-разному.
2. Как правильно использовать плейбуки в PT NAD? Плейбук — это подробный документ, прикрепленный к правилу. Он содержит описание атаки, скриншоты интерфейса, пошаговый алгоритм проверки на false positive и инструкции на случай подтвержденного инцидента. Для верификации: откройте плейбук из карточки атаки, следуйте алгоритму проверки, сверьте данные с payload и метаданными сессии. Плейбуки рассчитаны на операторов с любым уровнем подготовки.
3. Почему в PT NAD направление атаки не совпадает с направлением сессии? Для алертов на ВПО атакующим считается C2-сервер злоумышленника, даже если соединение инициировано изнутри. При анализе всегда проверяйте вкладку с деталями сессии — реальное направление сетевого соединения однозначно покажет, кто с кем взаимодействовал.
4. Можно ли доверять ChatGPT для верификации алертов PT NAD? Нет. Нейросети склонны подтверждать то, о чем их спрашивают: если в описании написано «атака», ChatGPT скорее всего согласится. Кроме того, нейросеть может выдумать несуществующую атаку, пытаясь быть полезной. Для верификации алертов используйте встроенные инструменты PT NAD: описание, рекомендации, плейбуки и вкладку с данными сессий.
5. Стоит ли подключать правила Emerging Threats в PT NAD? Не обязательно. Правила PT Security разработаны по принципу «необходимо и достаточно» — они покрывают актуальные угрозы без избыточного шума. Подключение большего числа правил не улучшает детектирование, но увеличивает количество ложных срабатываний.