SIEM’ный гамбит: может ли хакер обмануть сердце SOC?

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

Взаимное развитие техник атаки и технологий защиты — процесс непрерывный и циклический. Новые инструменты хакеров рано или поздно обрастают детектами, а средства защиты — способами обхода. При этом особое место в арсенале blue team занимают SIEM-системы. Их неслучайно называют сердцем SOC, ведь именно они агрегируют события безопасности от всех источников, в том числе от других защитных решений. Какие же технологии защиты применяются в SIEM? В чем их особенности? И может ли хакер обмануть сердце SOC? Давайте разбираться!

Дебют. Уровень сбора событий

«Самое большое искусство состоит в том, чтобы не показать сопернику, что он может делать», — говорил один известный шахматист. Возможности любой детектирующей логики напрямую зависят от полноты телеметрии, собираемой в SIEM. Соответственно, один из самых выигрышных ходов, который могут сделать хакеры, — ослепить SIEM-систему, так или иначе повлияв на уровень сбора событий. Или же воспользоваться тем, что где-то аудит отсутствует либо настроен некорректно. Чем могут ответить защитники?

Правильная защита всегда начинается с инвентаризации. Одна из ключевых технологий, которая должна лежать в основе эффективной SIEM-системы, — управление активами. Например, в MaxPatrol SIEM она реализована за счет активоцентричного подхода, позволяющего собирать данные обо всем, что есть в сети. Продукт уведомляет аналитиков SOC о недоступности источника, отсутствии определенного типа событий, задержках в их получении и т. д.

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

Злоумышленники регулярно изобретают новые способы нарушить журналирование событий Windows. Самый прямолинейный подход — напрямую остановить сервис логирования событий WinEventLog. Базовых методов изведано множество: злоумышленники могут отключить службу как с помощью штатных системных средств (например, SC или PowerShell), так и путем модификации соответствующих ключей реестра. Эти техники просты в реализации и не требуют внедрения в систему сторонних программ. Но так ли они удачны с точки зрения обхода СЗИ?

Защитники непрерывно изучают методы хакеров и покрывают их детектирующей логикой. Например, отключение службы EventLog с помощью встроенных утилит легко обнаружить по характерному содержимому командной строки в событиях запуска процессов. Или же отследить по событиям изменения состояния службы (Event ID 7036, см. рис. 2).

Но что, если атакующие окажутся хитрее и прибегнут к более продвинутым и менее шумным методам? Например, используют небезызвестный инструмент Phant0m/Invoke-Phant0m (см. рис. 3).

Утилита находит процесс svchost.exe, который хостит службу EventLog, а затем приостанавливает либо убивает все его потоки, отвечающие непосредственно за логирование. Следовательно, отключения сервиса не происходит и обнаружить данную активность по Event ID 7036 уже не выйдет. Теоретически факт запуска Phant0m/Invoke-Phant0m можно отследить по соответствующим командлетам в событиях PowerShell (событиям старта процесса).

Но судите сами: что может помешать злоумышленнику почистить логи без генерации событий очистки журналов (например, Event ID 1102 для журнала Security), пока сервис логирования не работает, и скрыть все улики? Правильно — ничего :) Таким образом, техника действительно не оставит следов в штатной телеметрии.

Однако праздновать победу рано: защитники могут сделать ход конем и обратиться к сторонним решениям для мониторинга. Деятельность таких утилит предполагает доступ к памяти процесса svchost.exe, причем с привилегированными правами, а не просто на чтение. Если blue team использует в качестве источника телеметрии Sysmon, защитники смогут отследить события доступа к памяти процесса svchost.exe (Sysmon EID 10) с соответствующими флагами. Еще проще, если на узлах установлены агенты EDR: в этом случае можно построить детектирующую логику на событиях EDR, основанных на WinAPI OpenProcess() к svchost.

Отметим, что хакеры могут зайти с другой стороны — нарушить не сбор, а транспортировку событий. Например, запретить на межсетевом экране исходящий трафик с узла к серверу — коллектору логов либо модифицировать конфигурационные файлы (изменив порт или адрес системы сбора событий). Для защитников это еще одна задача со звездочкой! Но даже подобные методы атакующих можно выявить, хоть и по косвенным признакам. Например, после блокировки соединений система все равно будет пытаться отправить логи в хранилище, генерируя при этом массу событий Event ID 5157 (блокировка подключения платформой фильтрации Windows). Эти события содержат IP-адрес и порт узла назначения (по умолчанию WEC-сервер прослушивает соединения от источников на 5985/TCP). Обилие неуспешных попыток подключения к WEC-серверу — явная аномалия, сигнализирующая blue team, что с узлом-источником что-то нечисто.

Модификацию конфигурационных файлов (например, Winlogbeat или WinCollect) можно задетектить по событиям доступа к файлу и изменения файла (Event ID 4663 и 4656). В общем случае изменение конфигураций сборщиков событий — нечастое явление, и такую активность полезно мониторить.

В этом материале мы намеренно обошли стороной продвинутые методы нарушения сбора событий Windows. Например, патчинг функционала ETW (Microsoft Event Tracing for Windows) в ntdll.dll или отключение сервиса логирования через RPC-вызовы.

Детектирование подобных приемов, скорее, лежит на плечах EDR-решений, которые тоже служат источником телеметрии для SIEM.
Несмотря на то, что многие атаки на сбор событий можно обнаружить с помощью корреляционных правил, целесообразнее решать эту задачу на стороне продукта, а не детектирующей логики. Если в SIEM-системе реализован функционал мониторинга источников, любое воздействие на потоки событий будет оперативно обнаружено — независимо от того, какой ход сделал злоумышленник.

Миттельшпиль. Методы обнаружения злоумышленников

Представим, что защитники удачно разыграли дебют: поставка событий работает штатно, аудит сконфигурирован правильно, необходимая телеметрия поступает в SIEM. Противники переходят к активному маневрированию, в котором фигуры blue team — это методы обнаружения, а фигуры атакующих — способы их обхода.

Глобально правила обнаружения делятся на два класса. Первый — так называемые сигнатурные правила, в логике которых заложено выявление атак по конкретным артефактам и индикаторам. Например, к ним относятся детекты хакерских утилит по характерным ключам в командной строке. Очевидное преимущество сигнатурных правил корреляции в том, что они очень точны и характеризуются малым количеством false positive. Но из этого вытекает и их главный недостаток: такие детекты легко обойти. Хакеру достаточно немного модифицировать инструмент, чтобы сбить сигнатуру.

Второй класс — поведенческие правила, которые заточены на обнаружение атакующих техник, то есть буквально поведения хакера. Забайпасить такие детекты гораздо сложнее: злоумышленник может что-то переименовать или пересобрать, чтобы обмануть сигнатуры, а вот в корне изменить свое поведение, подход к проведению атаки — задача непростая (а иногда вообще нерешаемая). Кроме того, покрытие поведенческих правил заведомо шире, чем сигнатурных: вместо детектирования 100 разных хакерских утилит, которые выполняют дамп памяти процесса LSASS, можно сделать всего одно правило на основе Sysmon EID 10, отслеживающее все попытки доступа к памяти LSASS. Однако любой разработчик детектирующей логики знает: чем шире правило, тем больше у него FP-срабатываний. Как результат — у поведенческих детектов почти всегда высокий показатель false positive.

На самом деле существует и третий подход к разработке детектирующей логики — комбинированный метод, который нивелирует недостатки сигнатурных и поведенческих детектов. К слову, при создании экспертизы для MaxPatrol SIEM мы стараемся использовать именно его. Но как правильно комбинировать детекты? Рассмотрим пример отслеживания доступа к памяти процесса LSASS — в наших пакетах экспертизы реализованы все три метода.

• Сигнатурный

В правиле прописано: если хакерский инструмент (например, с именем mimikatz.exe) обратился к памяти процесса LSASS, то это инцидент. Не фолзит и имеет место быть, как детект для ленивых атакующих. Но как только хакер переименует инструмент в mimikatz1.exe, правило будет бессильно. Это далеко не идеальное решение, но коробочная экспертиза должна содержать и детекты такого плана.

• Поведенческий

В правило заложено отслеживание обращений к памяти LSASS любыми процессами. Но у массы ПО и процессов есть вполне легальные причины для доступа к памяти LSASS: полностью их отсеять или отфильтровать на уровне детектирующей логики довольно проблематично. Устраивает ли это нас? Определенно да, если мы можем внести дефолтные исключения в правило и исключить FP-срабатывания.

• Комбинированный

В правиле корреляции используется широкий фильтр из поведенческого детекта, который может провоцировать FP-сработки. Однако он содержит дополнительные условия, которые могут обогатить его контекстом и повысить важность алерта до инцидента. Также в детекте исключены срабатывания на легитимные процессы — за счет механизма дефолтного вайтлистинга. Таким образом мы получили правило корреляции с минимальным количеством false positive, которое охватывает и известные, и неизвестные техники.

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

Переименование инструментов и изменение метаданных

Продвинутые атакующие стараются не использовать узнаваемые инструменты, которые можно вычислить по именам, специфичным ключам запуска и схожим артефактам. Казалось бы, чтобы сбить сигнатуру на название, достаточно просто переименовать исполняемый файл утилиты... Но все не так просто, если blue team использует Sysmon в качестве источника телеметрии. В отличие от нативного события запуска процесса Windows (Event ID 4688), Sysmon EID 1 предоставляет ценную для мониторинга информацию — например, хеш и метаданные исполняемого файла процесса (описание, заданное разработчиком исходное имя, цифровую подпись и т. д.). Зачастую, переименовывая свои инструменты под легитимные процессы, хакеры забывают/ленятся убирать оригинальные метаданные или вписывать в них фейковые значения — как у исполняемого файла, под который маскируются (см. рис. 6).

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

В экспертизе MaxPatrol SIEM учтены техники очищения, а также изменения метаинформации хакерских утилит. Например, детектирующие правила Run_Executable_File_without_Meta (запуск процесса без подписи) и Masquerading_Microsoft_Signed_Library проверяют статус подписи и совпадения в имени подписи, похожей на легитимную (например, Microsoft). Все эти данные пишутся в событиях Sysmon EID 7 и Sysmon EID 1.

Обфускация, игры с флагами и недокументированные ключи в командных строках

Эти векторы весьма эффективны, потому что многие детекты строятся на базе регулярных выражений и поиске чего-либо в командной строке процессов. Этот подход широко применяется как для отслеживания запуска стандартных системных утилит, так и для обнаружения специфичного инструментария атакующих. Загвоздка в том, что ключи могут быть перемешаны, изменены или обфусцированы. Более того, постоянно всплывают новые недокументированные флаги. Посудите сами, какой простор для творчества открывается злоумышленникам... Но так ли это страшно для защитников, как кажется на первый взгляд?

Предположим, атакующий смог переписать код инструмента таким образом, чтобы он запускался вообще без ключей. Например, для того же mimikatz есть возможность убрать явные артефакты из командной строки (sekurlsa::logonPasswords() и др.). Но этот подход эффективен только для обхода сигнатурных детектов на основе ключей! Если blue team располагает поведенческими правилами, которые не завязаны на командные строки, трюк не сработает. Чтобы их обойти, хакеру потребуется буквально написать новый инструмент.

Обфускация же работает не для всех типов событий. Например, она может быть эффективна при запуске Powershell-скриптов, что доставит немало хлопот аналитикам SOC. Однако для обнаружения нелегитимной активности не всегда нужно анализировать артефакты в командной строке запускаемого скрипта. Защитники могут опираться и на другие события — например, корневые. Отработавший скрипт так или иначе повлияет на объекты системы (для этого атакующий его и запускает) — то есть что-то обязательно произойдет. А значит, в распоряжении blue team окажутся события и телеметрия, по которым можно будет сделать вывод о том, что именно произошло. В качестве примера возьмем дамп памяти процесса LSASS с помощью rundll32 и библиотеки comsvcs.dll.

В надежде остаться незамеченным хакер выполняет на скомпрометированном узле следующую команду (см. рис. 7).

В соответствующем событии 4104 (журнал Microsoft-Windows-PowerShell) можно будет увидеть тот же обфусцированный скрипт (см. рис. 8). 

Если же поискать в окрестностях другую подозрительную активность, мы наткнемся на срабатывание правила Comsvcs_Minidump_Usage, вызванное запуском процесса rundll32.exe с характерным содержимым командной строки:

c:\windows\system32\rundll32.exe" c:\windows\system32\comsvcs.dll #-99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999976-decoy 712 dmp.tmp full

В отличие от Windows, в Linux дела с обфускацией для защитников обстоят куда лучше. Рассмотрим пару примеров.

Как бы злоумышленник ни старался обфусцировать командную строку, события audit.d все равно будут содержать оригинал. А все потому, что audit.d видит команды в нужном blue team представлении, даже если злоумышленник использует вызовы через ярлыки (см. рис. 11).

Но что будет, если хакер использует base64-кодировку?

Мы снова наблюдаем в событии оригинальную декодированную команду (см. рис. 13).

Самое время перейти к манипуляциям с флагами, которые могут провести атакующие. Для начала отметим, что Windows и Linux в этом плане несколько различаются. У встроенных и пользовательских утилит присутствуют флаги: они используются в командной строке для получения определенного результата и могут иметь вид /i или -i. В Windows формат вызова не критичен, а при разработке детектирующей логики под Linux нужно учитывать регистр имен процессов и аргументов в командной строке. К примеру, процессы Curl и curl — совсем не одно и то же. Этим может воспользоваться злоумышленник: назвать свой инструмент с большой буквы и получить абсолютно другой процесс. Флаги /i и /I тоже не взаимозаменяемы: разный регистр порождает разную логику работы утилит. Мы учитываем это и при разработке правил корреляции для MaxPatrol SIEM, и при вайтлистинге. Рекомендуем следовать нашему примеру ;)

Также отметим, что можно изменить сам порядок флагов (см. рис. 14).

Более того, один и тот же флаг может иметь множество вариаций (см. рис. 15).

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

Последний (но не по значимости!) способ обхода сигнатурных правил, который мы рассмотрим, — использование недокументированных флагов. В качестве примера возьмем вызов функции base64 со скрытыми алиасами Powershell. Уклонение от обнаружения основывается на том, что атакующий может сокращать функции, а также менять символ у вызова флага (см. рис. 16).
 

В MaxPatrol SIEM мы решили эту проблему, изучив все возможные комбинации флагов и добавив их в правило Execute_Encoded_Powershell. При разработке экспертизы необходимо тщательно проверять все документированные и недокументированные комбинации, учитывать возможность смены расположения вызовов флагов и т. д.

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

Можно ли обойти поведенческие детекты

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

Выявление аномальных комбинаций «родительский процесс — дочерний процесс» — известная среди специалистов защиты методика детектирования нелегитимной активности. Классический пример атаки, которая может быть обнаружена подобным образом, — запуск фишингового вложения доверчивым пользователем. Атакующий формирует вредоносный документ с помощью макросов или маскирует бинарный файл с двойным расширением и отправляет вложение на почту сотрудникам компании. Пользователи открывают документ — и бинго! на их узле исполняется вредоносный код. Но в арсенале едва ли ни каждого SOC есть детекты, поднимающие алерт, когда процесс winword.exe порождает процесс cmd.exe/powershell.exe — ведь это явная аномалия! И атакующим об этом известно… В свою очередь, они изобрели ряд способов разрыва цепочек выполнения, в числе которых различные техники спуфинга и выполнение команд с помощью WMI.

С помощью Parent PID Spoofing хакеры могут подменить PID родительского процесса, скрыв настоящего инициатора запуска. Таким образом, родителем cmd.exe/powershell.exe будет выступать иной процесс, запущенный на узле. Признаем, что эта техника не оставляет следов в штатных логах Windows и событиях Sysmon. Но это не означает, что blue team нечем ответить! Если решение для мониторинга конечных точек способно поставлять телеметрию, которая содержит информацию о реальном инициаторе запуска процесса, действия злоумышленников можно будет обнаружить. На сегодняшний день такой функциональностью обладают многие EDR-решения, а также продвинутый узловой аудит — события ETW Microsoft-Windows-Kernel-Process, в которых значения полей EventHeader ProcessId и ParentProcessId не будут совпадать при применении Parent PID Spoofing.

Нарушить цепочку выполнения можно и без использования PPID Spoofing. Например, если злоумышленник создаст фишинговое вложение с использованием WMI, родителем cmd.exe/powershell.exe станет процесс WmiPrvSE.exe. Произойдет разрыв цепочки процессов — и правила обнаружения не отработают. Давайте рассуждать: любая интерактивная атака многоэтапна, ведь хакер редко ограничивается одним действием. После первичной компрометации узла он будет проводить разведку, перемещаться по инфраструктуре и т. д. Эта активность (или как минимум ее часть) определенно вызовет сработки других детектирующих правил и привлечет внимание аналитиков SOC. В целом нет ничего страшного в том, чтобы пропустить один из шагов атакующих, — все мы несовершенны... Главное — остановить атаку до того, как злоумышленник успеет причинить серьезный ущерб.

Нарушение логических цепочек — не единственный метод уклонения от поведенческих детектов. Существует целый класс правил, в основе которых лежит склейка различных событий. Чаще всего логика склейки завязана на таймерах — заданных временных окнах, в течение которых в систему должны поступить ожидаемые события, чтобы произошла корреляция. Таймеры — еще одно скользкое место в разработке детектирующей логики. Почему? Из-за больших временных интервалов SIEM-система может связать что-то не то, а это чревато потоком FP-срабатываний. Кроме того, ресурсы SIEM не резиновые: продукт не может хранить инстансы в оперативной памяти бесконечно, что также служит препятствием для использования больших таймеров. Атакующий, в свою очередь, всегда может замедлиться и избежать обнаружения, если таймеры выставлены слишком жадно.

Среди распространенных сценариев нападения можно выделить «low and slow» — атаки, сильно распределенные во времени. Например, bruteforce или password spraying с продолжительными задержками, когда комбинация «пароль / учетная запись» пробуется не чаще одного раза в час. Это дает атакующим возможность успешно обходить детекты, поскольку длительные интервалы между попытками входа позволяют избежать превышения пороговых значений, которые заложены в детектирующую логику. Значит ли это, что такая активность останется незаметной для SOC? Нет, потому что даже растянутые во времени атаки провоцируют всплески событий неуспешных авторизаций: это легко обнаружить, если SIEM умеет строить наглядные графики и таблицы (см. рис. 17).

Существуют поведенческие обнаружения, которые опираются на поставку событий из разных ИБ-продуктов. В этом случае хакер может сделать так, что события от сенсоров придут в SIEM в измененном виде либо не придут вовсе. Тогда правило корреляции в SIEM не сработает и склейки не произойдет, хотя каждый из сенсоров  отработает честно. Простой пример поведенческого детекта, который строится на предикатах от других продуктов, — событие от сетевого СЗИ или EDR-решения плюс событие штатного аудита для выявления аномальной активности процессов в рамках одной сессии. Такие склейки требуют высокой производительности, кроме того, некоторые SIEM-системы в принципе не позволяют их строить. Одно из возможный решений — не завязываться на таймеры и снять нагрузку с оперативной памяти SIEM, записывая нужную информацию локально на диск и не создавая новые инстансы. Например, в MaxPatrol SIEM реализован механизм табличных списков, который позволяет сохранять определенные данные событий и обращаться к ним в будущем. Правила корреляции используют их не только на чтение, но и на запись.

На этом подведем черту и соберем воедино все, к чему пришли в этой главе. Методы обнаружения и способы уклонения — то, вокруг чего развиваются основные события «шахматной партии» хакеров и защитников. Это наиболее творческая часть их противостояния: blue team непрерывно расширяет свои возможности по детектированию угроз, а атакующие изобретают все более изощренные способы уклонения. Уже существует целый пласт техник, с помощью которых можно обмануть правила обнаружения. Но означает ли это безоговорочную победу хакеров над специалистами защиты? Нет, ведь детектирующая логика — не последний рубеж защиты в SIEM-системах.

Продвинутые методы обнаружения: ML и системы поведенческого анализа

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

UEBA (User and Entity Behavior Analytics) — это системы, которые используют ML-технологии и статистический анализ для обнаружения аномалий в действиях пользователей и их поведении. Это сущностно-центричные решения, в которых центральным объектом анализа становятся пользователи и сущности. Хотя есть и другие подходы: например, модуль BAD в MaxPatrol SIEM фокусируется на анализе событий безопасности.

Любая детектирующая логика основана на поиске каких-либо аномалий. С ними же в первую очередь работает и аналитик SOC. Поэтому две основные проблемы, которые защитники могут решить с помощью UEBA, — это снижение когнитивной нагрузки на операторов SIEM путем приоритизации инцидентов и выявление нелегитимной активности, которая обошла детектирующую логику. В то же время аномалии — это всегда сложности в валидации результата, множество фолзов и длительный процесс расследования. Поэтому, чтобы повысить точность финального решения, необходимо коррелировать вердикты от UEBA с вердиктами экспертизы SIEM. Но могут ли хакеры как-то нарушить работу UEBA-систем и повлиять на их вердикты?

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

Другим слабым местом UEBA-систем являются time-based-аномалии: когда модель обучается на активности в определенные временные промежутки. Например, каждое утро на определенном узле запускается запланированная задача any_task: для конкретной инфраструктуры и конкретного сетевого актива это нормально. Предположим, аналитики SOC давно завайтлистили эту активность. В свою очередь, модель в момент обучения проанализировала события старта сервисов (Event ID 4698) и собрала профиль. Но что, если кто-то другой создаст задачу с таким же названием, но уже на другом узле? Посчитает ли UEBA-система это аномалией? Учитывает ли она контекст всех полей события: содержимое задачи, узел на котором она создана, название задачи?

Ответ прост: все зависит от вендора и реализации конкретного решения. Производитель может забыть добавить контекст узла, контекст события или же изменение содержимого задачи, и тогда атакующий сможет обойти систему. К радости защитников, на данный момент универсальных и на 100% эффективных методов обхода UEBA-систем не существует. Или же широкой общественности о них неизвестно…

Эндшпиль. Человеческий фактор в работе SIEM-систем

SIEM — наиболее «человекоемкий» класс защитных решений. При выявлении атак теми же песочницами или EDR участие человека сводится к минимуму, а финальный вердикт по срабатываниям SIEM всегда выносит аналитик SOC. Как результат, одной из причин пропуска угроз неизбежно становится человеческий фактор. Даже идеальное покрытие телеметрией, передовая детектирующая логика и инструменты не гарантируют успешного обнаружения атаки. Но что же все-таки сложнее обойти — человека или технологии? И что может предпринять злоумышленник, чтобы обмануть ИБ-специалиста?

Не секрет, что спустя определенное время у аналитиков SOC развивается alert fatigue (усталость от алертов). Продолжительное воздействие источника стресса повышает устойчивость человека и приводит к игнорированию этого воздействия. На долю аналитиков L1 и L2 ежедневно выпадает масса алертов, большая часть которых — ложные и/или повторяющиеся. Собственно, это ведет к ошибочной интерпретации TP-алертов как FP, то есть к пропущенным либо игнорируемым атакам.

Как правило, все алерты, с которыми сталкиваются аналитики, можно разделить на три категории:

• Что-то «точно нехорошее»: очевидно аномальная активность, которая требует расследования и реагирования. Например, сканирование Nmap во внутренней сети и запуск Powershell процессом winword.exe.
• Что-то «точно нормальное»: очевидно легитимная активность, которая не была своевременно внесена в исключения или вызвала FP-срабатывание по иной причине. К примеру, обращение к LSASS от АВПО: создание нового пользователя в установленном порядке администратором или выделенной сервисной УЗ.
• Что-то «серое»: активность, природу которой нельзя понять сразу и однозначно отнести к нелегитимной или легитимной. Это могут быть легитимные RAT-утилиты или же «легитимное» ПО, ведущее себя странно.

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

Какую выгоду могут извлечь из этого злоумышленники? Грамотные атакующие, изучив сложившиеся в инфраструктуре процессы, могут начать мимикрировать настолько качественно, что их действия будут практически неотличимы от действий администраторов и рядовых пользователей. Вероятность пропуска атаки аналитиком возрастает в разы. Но из этой ситуации тоже есть выход!

Еще в начале главы мы пришли к выводу о том, что одной из главных причин пропуска угроз являются ложные срабатывания. То есть борьба с человеческим фактором перетекает в борьбу с false positive! Как же бороться эффективно?

В первую очередь необходимо адаптировать коробочные правила обнаружения к конкретной инфраструктуре путем регулярного вайтлистинга (то есть внесения контекстных исключений в правила). Любая детектирующая логика, будь то вендорская или Open Source, разрабатывается под абстрактную общую ситуацию, но у каждой компании есть свои особенности. Более того, правила, которые раньше не фолзили, после очередных изменений в инфраструктуре могут начать генерировать множество false positive. Поэтому вайтлистинг должен быть регулярным и непрерывным!

Близится финал

Кому же будет поставлен шах и мат? В этой статье мы испытали на прочность все технологии защиты, которые применяются в SIEM-системах. Убедились ли мы в том, что у каждой из них есть недостатки, которые могут способствовать уклонению от обнаружения? Безусловно да! Означает ли это, что у атакующих есть фундаментальное преимущество перед защитниками? Безусловно нет :)

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