Всем привет! После публикации статьи про Reverse Duck Test получили много вопросов от коллег по цеху — в основном о том, как метод ведёт себя на высокоприоритетных алертах и на активности, где злоумышленник долго и незаметно находился в инфраструктуре.
Разберём на примере (кейс собирательный, не привязан к конкретному инциденту) :
Алерт: подключение к RDP с ранее не встречавшегося внешнего IP, вход успешен, дальше — RDP-сессия длиной 40 минут, запуск легитимного
net.exeиwmic.exe. По базовой версии Reverse Duck Test — есть историческая активность с этой учётки (были RDP-сессии и раньше), есть подтверждение от пользователя ("да, это я, работал удалённо") — два из трёх пунктов, закрываем как FP. Осталось три дня до момента, когда та же учётка запустила Mimikatz на контроллере домена.
Разбираем ниже, что метод должен был поймать, но не поймал в этом кейсе — и как это чинить в методике.
Алерты, для которых метод неприменим в принципе
Прежде чем говорить про калибровку — отдельно про случаи, где сам вопрос "искать ли признаки легитимности" не имеет смысла в принципе:
ханипоты и приманки — по своей природе не имеют легитимного трафика, любое обращение к ним уже аномалия
сетевые алерты с нулевым уровнем ложноположительных срабатываний (правило написано так, что оно физически не может сработать на легитимную активность)
активность на целевых/эталонных системах, где сама природа сработки — нонсенс (то, чего там в принципе быть не должно ни при каких бизнес-процессах)
Это дополнение к уже указанным в оригинальной статье ограничениям (Initial Access, malware, известные hacktool'ы, сканирования с внешних адресов) — тот же список, просто с недостающими пунктами.
Когда время работает против метода
Один из пунктов ретроспективного анализа — аналогичная активность с данного хоста/УЗ ранее либо циклично (выглядит как утка). Формально это признак легитимности. Но здесь есть слепое пятно, и оно имеет два уровня глубины.
Первый уровень. Если учётная запись скомпрометирована давно, атакующий может специально "приучать" SIEM к своему паттерну поведения на протяжении недель, прежде чем перейти к целевым действиям. В этом случае историческая активность — не доказательство легитимности, а часть той же атаки на более ранней стадии, просто растянутой во времени. Именно это произошло в нашем кейсе: постфактум сверка с фидами киберразведки показала, что первые признаки компрометации домена появились за 12 дней до разбираемого алерта — то есть "историческая активность с этой учётки", которая формально засчиталась как признак легитимности, сама была частью атаки. Лечится это на уровне отдельного пункта методики:
ретроспектива засчитывается как признак только если она предшествует первому появлению индикаторов компрометации в среде (сверка по фидам киберразведки, IOC, данным от проактивного поиска угроз)
либо подтверждена внешним источником (тикет, переписка), а не только логами SIEM/NTA
Второй уровень — предельный случай первого. Методика по сути опирается на нормальное распределение: если наблюдаемая активность — небольшое отклонение от привычной картины, скорее всего перед нами шум. Но если в инфраструктуре давно и плотно присутствует APT-группировка, искажена уже сама картина распределения — то, что выглядит "нормальным" и "историческим", на самом деле новая норма, установленная атакующим. Здесь точечная проверка по IOC уже не спасает: в этой ситуации не работает практически ничего из стандартного триажа, и вопрос уже не в конкретной методике, а в необходимости полноценного threat hunting и пересмотра доверенной телеметрии как таковой.
Разница между уровнями простая: на первом — есть за что зацепиться и что перепроверить, поэтому метод остаётся рабочим при условии добавленной проверки по IOC (как в нашем кейсе). На втором — под вопросом сама точка отсчёта, и Reverse Duck Test как инструмент повседневного триажа здесь не применяется в принципе, ровно как и в блоке выше.
Не все "утки" одинаково крякают
В базовой версии методики три пункта (ретроспектива, бизнес-логика, опрос пользователя) по сути равнозначны: набрал хотя бы один — уже повод для сомнения в статусе инцидента. На практике это даёт разный уровень уверенности в зависимости от того, какой именно пункт присутствует и насколько он подтверждён:
тикет с чётким обоснованием и точной привязкой по времени — сильный сигнал
устное подтверждение пользователя без проверки логами — слабый сигнал, который сам по себе не должен закрывать алерт
"было что-то похожее раньше" без документов — самый слабый сигнал из трёх
В нашем кейсе оба набранных пункта были слабыми: устное подтверждение пользователя без сверки с логами и ретроспектива без документов. По базовой версии методики этого хватило для закрытия как FP. По новой модели — двух слабых сигналов недостаточно, требуется либо одно сильное подтверждение, либо совокупность из двух и более слабых, взаимно перепроверенных техническими данными (а перепроверка как раз и вскрыла бы признаки компрометации из предыдущего раздела). Предлагаем ввести это условное деление на сильные и слабые подтверждения как отдельное правило методики.
Критичность актива и приоритет алерта меняют порог
В исходной версии для алертов высокого приоритета и "недопустимых событий" мы указывали "применять с большой осторожностью", но не операционализировали, что это значит на практике. В разбираемом кейсе хост, с которого шла RDP-сессия, входил в группу контроллеров домена — то есть относился к критически значимым активам, и уже это само по себе должно было требовать более строгой проверки, а не два слабых сигнала и автоматическое закрытие. Дополняем:
для алертов на критически значимых активах и для категории "недопустимые события" — закрытие как ложноположительного требует наличия сильного подтверждения и повторной проверки вторым специалистом (L3 или тимлидом), независимо от количества набранных пунктов
для шумных низкокритичных потоков (например, повторяющиеся сработки при известных процессах на рядовых хостах) — допустимо закрытие одним аналитиком по совокупности двух и более пунктов методики без эскалации
Тревожные маркеры, которые перекрывают методику
Список технических индикаторов, при наличии которых алерт не может быть закрыт как ложноположительный, даже если формально все три пункта методики набраны:
несовпадение хэша бинарника с эталонным значением при внешне привычном процессе
нетипичное время или геолокация при обычной для пользователя активности
легитимные системные утилиты, запущенные в подозрительных целях, — из нехарактерной родительской цепочки процессов
расхождение между заявленной пользователем целью действия и фактическим объёмом или направлением передачи данных
В нашем кейсе как раз сработал третий пункт: wmic.exe был запущен не из explorer.exe, как это обычно бывает при интерактивной работе пользователя по RDP, а из процесса net.exe — нехарактерная родительская цепочка для рутинной активности. Этого маркера было достаточно, чтобы не закрывать алерт как FP, даже при формально пройденных двух пунктах методики.
Это своего рода предохранитель: методика снижает нагрузку на аналитика, но не должна отключать критическое мышление там, где злоумышленник осознанно мимикрирует под легитимный паттерн.
Опрос пользователя может выдать вас раньше времени
В оригинальной статье уже есть важная оговорка: подтверждение со стороны инициатора активности — не истина в последней инстанции, учётка может быть скомпрометирована, а ответы нужно всегда сверять с логами. Но у этого предупреждения есть операционное следствие, которое стоит проговорить отдельно.
Если по совокупности технических признаков есть обоснованное подозрение, что перед вами не ошибка добросовестного сотрудника, а действия инсайдера — прямой опрос по методике ("это ты запускал такую-то активность?") сам по себе становится риском, а не просто источником слабого сигнала. Вы тем самым раскрываете инициатору, что его действия попали в поле зрения SOC, а это может привести к тому, что он начнёт заметать следы, ускорит свои действия или свернёт активность до появления возможности зафиксировать полную картину.
Поэтому третий пункт методики (опрос пользователя) стоит разделить на два разных режима:
обычный режим — когда нет оснований подозревать умышленные действия инициатора, опрос идёт как описано в исходной методике: напрямую, с уточняющими вопросами
режим скрытой верификации — когда есть основания подозревать инсайдера, прямой контакт с инициатором исключается до завершения расследования. Подтверждение легитимности в этом случае ищем только через технические источники (логи, поведенческую аналитику, привилегии, историю доступа) и по параллельному треку с HR и службой внутренней безопасности (юристов подключаем дополнительно, если дело идёт к увольнению или иску), а не через опрос самого человека
Второй режим фактически исключает третий пункт методики из уравнения — при подозрении на инсайдера вердикт должен опираться только на ретроспективу и бизнес-логику, подкреплённые техническими данными, а подтверждение "изнутри" не запрашивается вовсе, пока расследование не закрыто.
Обязательное обоснование при закрытии как ложноположительного
Дополняем методику явным требованием: вердикт "ложноположительное" без зафиксированного обоснования по всем проверенным пунктам считается невалидным и трактуется как инцидент до выяснения. Это защищает от ситуации, когда аналитик под нагрузкой закрывает алерт "по ощущению", не проходя по факту ни один из трёх пунктов методики — как это, по сути, и произошло в разбираемом кейсе.
Как это меняет схему принятия решения
Проверяем, не относится ли алерт к классу, где методика неприменима в принципе (ханипоты, правила с нулевым FP, нонсенс-активность на целевых системах, инфраструктура с искажённой из-за APT картиной нормы).
Проверяем пункты методики (ретроспектива / бизнес-логика / опрос пользователя), фиксируя для каждого — сильный это сигнал или слабый. Если по совокупности признаков есть подозрение на инсайдера — переходим в режим скрытой верификации и исключаем прямой опрос инициатора из уравнения до завершения расследования.
Проверяем список тревожных маркеров — если сработал хотя бы один, закрытие как ложноположительного невозможно вне зависимости от предыдущего пункта.
Смотрим на критичность актива и приоритет алерта — определяем, нужна ли повторная проверка вторым специалистом.
Закрываем вердикт с обязательным документированием оснований.
Применительно к нашему кейсу: шаг 3 (нетипичная родительская цепочка wmic.exe) и шаг 4 (актив — контроллер домена) должны были остановить закрытие как FP ещё до того, как вопрос вообще дошёл до подсчёта пунктов методики.
Итог
Алерт, который формально проходит по методике, но с оговорками — слабые сигналы, скомпрометированный источник подтверждения, искажённая картина нормы — не должен закрываться как ложноположительный автоматически. Три дня между закрытием разбираемого алерта как FP и запуском Mimikatz на контроллере домена — это ровно то окно, которое калибровка метода должна закрывать: не за счёт замедления триажа в целом, а за счёт более строгих требований именно там, где цена ошибки высока.
Эти правки не меняют дух исходной методики: мы по-прежнему сначала ищем признаки легитимности, а не признаки атаки. Но добавляют калибровку под риск, вводят вес признаков вместо их равнозначности и явно очерчивают границы, где Reverse Duck Test работает, а где он бессилен и нужны совсем другие инструменты.
Спасибо за вопросы и обратную связь по первой статье — они и стали основой этой версии методики :-)
