Как злоумышленники обходят вашу систему EDR/XDR и что вы можете с этим сделать

Недавний глобальный опрос показал, что руководители служб информационной безопасности и их организации могут слишком полагаться на системы обнаружения и реагирования на конечные точки (EDR) и расширенного обнаружения и реагирования (XDR), поскольку злоумышленники все чаще их обходят.

Это отчасти связано с тем, что уклонение от систем EDR/XDR было и будет оставаться основополагающим требованием для большинства современных злоумышленников. «Уклонение» использовалось в общем смысле для описания случаев, когда защитный ответ не наблюдался. Отсутствие конкретики мешает специалистам по кибербезопасности точно нацеливать усилия по исправлению. Например, исправление логики обнаружения сильно отличается от случаев, когда телеметрия отсутствует на платформе XDR.

Чтобы лучше понять, как атаки обходят системы EDR/XDR и что с этим делать, нам необходимо разобраться в трех областях, где это происходит: наблюдение, обнаружение, а также реагирование и предотвращение.

Как злоумышленники обходят XDR во время наблюдения

По своей сути система XDR потребляет события из различных источников, таких как операционная система конечной точки или поставщик облачных услуг. Эти события, обычно называемые телеметрией, формируют основу обнаружения. XDR может обнаружить только то, что система(ы) может предоставить и собрать. Первый тип уклонения происходит, когда XDR не получает события, необходимые для обнаружения вредоносного поведения.

Есть несколько распространенных причин для такого типа уклонения. Во-первых, и то, что я считаю «чистейшим» техническим уклонением, заключается в том, что действия противника не создали никакой релевантной телеметрии. Релевантно, потому что каждое действие, выполненное в системе, генерирует некоторое количество телеметрии, но эти события могут быть бесполезны для создания хороших обнаружений. Думайте об этом как об отсутствующем источнике событий в системе, а не как о недостатке в XDR.

Далее следуют случаи, когда телеметрия производится системой, но не потребляется XDR. Существуют тысячи источников событий, на которые может подписаться XDR, и работа поставщиков заключается в том, чтобы решить, какие из них требуются для удовлетворения их требований по обнаружению. Например, если поставщик XDR особенно заинтересован в обнаружении поведения, связанного с Active Directory, он отдаст приоритет сбору событий из AD, а не чему-то вроде сетевого трафика. Игнорирование определенных типов событий, будь то по выбору или по незнанию, создает эксплуатируемый пробел в покрытии XDR определенных методов атак.

Наконец, злоумышленник может активно вмешиваться в агента XDR, так что события не отправляются на централизованный сервер, отвечающий за сбор и корреляцию. Это вмешательство имеет множество форм, включая остановку или удаление агента, блокировку связи с сервером (например, через модификации хостового брандмауэра) или вмешательство в работу сенсоров (например, отключение AMSI (Antimalware Scan Interface — это компонент Microsoft Windows, который обеспечивает более глубокую проверку встроенных служб сценариев)).

В общем, это ошибки разработчика XDR. Если атака пропущена, потому что агент не собирает соответствующую телеметрию, вендор является единственным субъектом, который может исправить ошибку, поскольку это подразумевает добавление новых источников телеметрии или расширение/обогащение существующих. В случае вмешательства в работу XDR-агента поставщик должен реализовать меры по борьбе с несанкционированным доступом, чтобы обнаружить и предотвратить вмешательство. Эти проблемы являются самыми сложными для любой команды безопасности, потому что они ничего не могут сделать, кроме как обратиться к своему поставщику XDR.

Как злоумышленники обходят XDR во время обнаружения

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

Оба типа обнаружения имеют свои недостатки. Точные обнаружения склонны к уклонению, поскольку они часто слишком специфичны, что означает, что любое изменение целевого образца приведет к ложному отрицанию. Примером этого может быть злоумышленник, исправляющий строки аргументов Mimikatz, чтобы превратить «sekurlsa::logonpasswords» в «nothings::happening_here», нарушая хрупкую логику обнаружения, нацеленную на контролируемую злоумышленником строку.

Надежные обнаружения, несмотря на то, что на первый взгляд кажутся менее восприимчивыми к обходу, печально известны своими ложными срабатываниями, вынуждающими добавлять к исключения в правила детектирования, которые становятся доступными для злоумышленников. Примером, который я наблюдал на практике, является исключение процесса обновления Chrome, «GoogleUpdate.exe», из обнаружений сброса учетных данных, поскольку его обычная работа включает открытие привилегированного дескриптора для процесса службы локальной подсистемы безопасности (LSASS). Это исключение позволяет злоумышленнику либо маскироваться под помощника обновления, либо внедряться в него, чтобы извлечь учетные данные без обнаружения, несмотря на все поведенческие шаблоны, присутствующие в событиях, собранных XDR.

Эти уклонения используют логические проблемы в обнаружениях, встроенных в EDR, независимо от того, поставляются ли они поставщиком или написаны внутренними инженерами по обнаружению. Несовершенное понимание техники или процедуры, узкие места обнаружения, компромиссы, сделанные для того, чтобы сделать обнаружение жизнеспособным для использования в производстве, и неоптимальная телеметрия в XDR, приводящая к слабой логике обнаружения, являются обычным явлением в мире защиты конечных точек.

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

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

Как злоумышленники обходят XDR во время реагирования и предотвращения

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

Работая по конвейеру среднего SOC, первая возможность для уклонения возникает на этапе сортировки, когда аналитик уровня 1 получает оповещение и ошибочно помечает его как ложное срабатывание. Это приводит к тому, что поведение остается незамеченным, несмотря на то, что XDR выполняет свою работу. Это может быть вызвано усталостью от оповещений или из-за общего непонимания цели обнаружения и того, что означает информация о конкретном обнаружении. Устранение этой точки отказа обычно включает управление очередью и усталостью за счет сокращения ложных срабатываний (что имеет свои проблемы, как подробно описано в предыдущем разделе), а также за счет лучшего документирования и обучения аналитиков.

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

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

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

Самая большая ошибка, с которой я столкнулся на этом этапе, находясь в красной команде, заключалась в том, что команда защиты неправильно оценила масштаб инцидента, что привело к неполному выселению злоумышленника и позволило нам оставаться в среде почти 18 месяцев (в конечном итоге нас выгнали только тогда, когда сервер, на котором мы оставались, был выведен из эксплуатации их ИТ-отделом в рамках планового процесса обновления жизненного цикла). Улучшение процесса реагирования для снижения шансов злоумышленника избежать выселения сводится к наличию надежных отработанных процессов, способности определить весь масштаб компрометации и способности подтвердить полное выселение злоумышленника.

Документация

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

Мэтт Хэнд

Источник: https://www.csoonline.com/article/3476179/how-your-xdr-is-evaded.html