15 ноября 2021
PT NAD
Работа с фильтрами
Содержание статьи
Запросить триальные лицензии вы можете заполнив форму
Получить триальную лицензию
Наш специалист свяжется с вами в ближайшее время
Приветствую всех на второй статье про систему глубокого анализа трафика от компании Positive Technologies - Network Attack Discovery. В прошлой статье я упоминал про фильтрацию сессий PT NAD, но не стал на этом останавливаться; в рамках же этой статьи предлагаю подробно рассмотреть данный функционал продукта. Фильтрация вам пригодится, чтобы найти подозрительную активность, нарушения регламентов ИБ и расследовать атаки. В конце статьи я приведу пример расследования цепочки атаки, используя фильтры PT NAD.
PT Network Attack Discovery хранит 1200 параметров сессий без ограничений по времени, и для того, чтобы стало проще сортировать сессии по этим параметрам, разработчики сделали строку фильтрации. Примеры хранимых параметров: ip адреса участников сессии, их сетевые группы, страны, порты отправителя и получателя, прикладной и транспортный протоколы и т.д.
Используя данную технологию, оператор PT NAD может легко отсеять все ненужные ему в данный момент сетевые соединения, чтобы заострить свое внимание на самых важных.
PT Network Attack Discovery хранит 1200 параметров сессий без ограничений по времени, и для того, чтобы стало проще сортировать сессии по этим параметрам, разработчики сделали строку фильтрации. Примеры хранимых параметров: ip адреса участников сессии, их сетевые группы, страны, порты отправителя и получателя, прикладной и транспортный протоколы и т.д.
Используя данную технологию, оператор PT NAD может легко отсеять все ненужные ему в данный момент сетевые соединения, чтобы заострить свое внимание на самых важных.
Фильтры
Синтаксис фильтров в PT NAD очень напоминает синтаксис Wireshark'а: указывается параметр, по которому необходимо произвести фильтрацию, далее указывается его значение через знак == (если параметр строковой, его необходимо указывать в кавычках).
Можно задать сразу несколько параметров, друг от друга они отделяются символами:
&& (или and) - логическое И, объединенный поиск по нескольким фильтрам
|| (или or) - логическое ИЛИ, поиск по одному из заданных фильтров.
&& (или and) - логическое И, объединенный поиск по нескольким фильтрам
|| (или or) - логическое ИЛИ, поиск по одному из заданных фильтров.
Такие выражения подчиняются правилам алгебры логики, поэтому можно объединять фильтры в скобки, но важно не ошибиться с правильным их объединением. Пример: FILTER1 && (FILTER2 or FILTER3) - будет произведен поиск по следующей логике: подходят сессии, которые попадают под FILTER1 и либо под FILTER2, либо FILTER3 (или же подходят по всем трем фильтрам):
В данном примере я отфильтровал только те сессии, которые происходили по протоколу tcp, при этом прикладной протокол должен быть либо http, либо dns. Однако при использовании выражения (FILTER1 && FILTER2) or FILTER3 фильтрация уже будет происходить по правилу: подходят сессии, удовлетворяющие одновременно фильтрам FILTER1 и FILTER2, либо подходят сессии, удовлетворяющие FILTER3.
На диаграмме протоколов видно, что при переносе скобок появляются сессии, происходившие по протоколу UDP.
Нетрудно догадаться, что присутствует логическое НЕ. Оно задается с помощью восклицательного знака или слова not: по фильтру !FILTER1(not FILTER1) будут отображены все сессии, которые не удовлетворяют фильтру FILTER1.
Нетрудно догадаться, что присутствует логическое НЕ. Оно задается с помощью восклицательного знака или слова not: по фильтру !FILTER1(not FILTER1) будут отображены все сессии, которые не удовлетворяют фильтру FILTER1.
В данном примере я захотел посмотреть все сессии, которые происходили не по протоколам dns или tls.
Кроме знака равенства (==) также могут быть использованы знаки неравенства(!=), знаки "больше"(>) или "меньше"(<), а также "не больше"(<=) или "не меньше"(>=).
Кроме знака равенства (==) также могут быть использованы знаки неравенства(!=), знаки "больше"(>) или "меньше"(<), а также "не больше"(<=) или "не меньше"(>=).
А здесь я решил посмотреть те сессии, которые происходили не по протоколу https, но при этом порт, по которому они проходили, должен быть больше или равен 80.
Стоит заметить, что запросы вида !FILTER(not FILTER) и FILTER != value будут давать разные результаты. Например: у нас есть сессия http, где был всего один запрос, на который вернулся код 200:
Стоит заметить, что запросы вида !FILTER(not FILTER) и FILTER != value будут давать разные результаты. Например: у нас есть сессия http, где был всего один запрос, на который вернулся код 200:
Фильтр http.rsp.code != 200 отфильтрует нам эту сессию:
Фильтр !http.rsp.code == 200 тоже отфильтрует:
Теперь рассмотрим ситуацию, что у нас в http сессии было 2 запроса. На первый вернулся ответ с кодом 304, на второй 200:
Фильтр http.rsp.code != 200 не отфильтрует эту сессию, так как в ней есть еще код 304:
С помощью оператора != можно будет только отфильтровать конструкцией http.rsp.code != 200 and http.rsp.code != 304. Фильтр !http.rsp.code == 200 отфильтрует сессию:
Потому что он исключает все сессии, где был ответ с кодом 200 (даже если там были и другие ответы с другим кодом).
Стоит упомянуть про функционал скобок: при фильтрации их можно использовать, как вариант, для поиска в рамках одной транзакции протокола. Например, при использовании конструкции http(rqs.method == "POST" && rsp.code == 200) продукт отобразит сессии с http транзакциями, где на POST запрос вернулся ответ с кодом 200:
Стоит упомянуть про функционал скобок: при фильтрации их можно использовать, как вариант, для поиска в рамках одной транзакции протокола. Например, при использовании конструкции http(rqs.method == "POST" && rsp.code == 200) продукт отобразит сессии с http транзакциями, где на POST запрос вернулся ответ с кодом 200:
Также скобки можно использовать для задания множества значений, которым может равняться интересующий нас параметр. Синтаксис следующий: FILTER1 in (value1,value2,value3,...). В следующем примере я хочу посмотреть все сессии, которые проходили по протоколам http, smb или ntp:
Аналогично можно задать список значений, которым параметр равняться не должен. Сделать это можно с помощью конструкции not in:
В данном случае я посмотрел все сессии, хост назначения в которых не находится в Нидерландах, Швеции или Германии.
Одним из ощутимых удобств стала возможность использования в фильтрах Wildcard поиска - метода описания поискового запроса с использованием метасимволов . Другими словами, система найдет все сессии, в указанном параметре которых есть заданная подстрока или часть какого то значения.
Синтаксис следующий: если после подстроки может стоять только один символ, то следует поставить ?; если же символов может быть какое-то количество, заранее неизвестное пользователю, следует воспользоваться знаком *; стоит отметить, что при задании фильтра с помощью регулярного выражения знаки равенства становятся неприменимыми, и следует использовать знак ~("тильда").
Одним из ощутимых удобств стала возможность использования в фильтрах Wildcard поиска - метода описания поискового запроса с использованием метасимволов . Другими словами, система найдет все сессии, в указанном параметре которых есть заданная подстрока или часть какого то значения.
Синтаксис следующий: если после подстроки может стоять только один символ, то следует поставить ?; если же символов может быть какое-то количество, заранее неизвестное пользователю, следует воспользоваться знаком *; стоит отметить, что при задании фильтра с помощью регулярного выражения знаки равенства становятся неприменимыми, и следует использовать знак ~("тильда").
Я захотел посмотреть все версии системы Microsoft Windows, которые используются в сети.
Также, для простоты использования данной технологией, разработчики PT NAD добавили функцию добавления фильтра по щелчку мышкой: пользователь может кликнуть на параметр, который подсвечивается синим цветом, и он будет автоматически добавлен в строку задания фильтров в конец со знаком && перед фильтром.
Также, для простоты использования данной технологией, разработчики PT NAD добавили функцию добавления фильтра по щелчку мышкой: пользователь может кликнуть на параметр, который подсвечивается синим цветом, и он будет автоматически добавлен в строку задания фильтров в конец со знаком && перед фильтром.
В этом примере я нажал на атаки высокой опасности и фильтр alert.pr == 1 автоматически добавился в строку фильтрации.
Для более тонкой фильтрации полезно использовать несколько фильтров сразу, объединяя их, но тут самое главное - не запутаться в логике выражения. Итак, я описал синтаксис фильтров системы глубокого анализа трафика PT Network Attack Discovery; сейчас же предлагаю перейти к небольшому примеру, который на практике показывает, для каких целей может использоваться данная технология и как с помощью нее можно расследовать сетевые атаки
Для более тонкой фильтрации полезно использовать несколько фильтров сразу, объединяя их, но тут самое главное - не запутаться в логике выражения. Итак, я описал синтаксис фильтров системы глубокого анализа трафика PT Network Attack Discovery; сейчас же предлагаю перейти к небольшому примеру, который на практике показывает, для каких целей может использоваться данная технология и как с помощью нее можно расследовать сетевые атаки
Пример цепочки
Итак, мы заходим в интерфейс продукта, переходим во вкладку Атаки и видим, что за достаточно небольшой отрезок времени PT NAD обнаружил 206 атак высокой опасности:
Начнем с атак, которые были совершены раньше по времени: отсортируем по времени атаки и обнаруживаем, что было много атак с использованием Meterpreter, причем сначала была попытка подключения с 10.159.12.2 (что скорее всего является контроллером домена), но она оказалась неудачной, после чего было удачно произведено подключение с 10.159.12.12:
Раскручиваем цепочку атаки: для начала следует понять, какие действия совершил злоумышленник после попадания в сеть. Для этого посмотрим сессии с участием скомпрометированного хоста с помощью фильтра src.ip == 10.159.12.12:
На скриншоте видно, что злоумышленник пытался получить информацию о локальных администраторах, что является частью разведки. Смотрим дальше и видим необычный AS-REQ запрос с одним выбранным шифром:
Это наводит на мысль о попытке проведения атаки Kerberosting - Метод извлечения служебных учетных записей из Active Directory от имени обычного пользователя (подробнее о данной атаке: https://attack.mitre.org/techniques/T1558/003/).
Но на скриншоте видно, что аутентификация не была пройдена, а значит, тикет не был выдан. Поскольку после этого не было успешных аутентификаций, можно сделать вывод, что попытка атаки успехом не увенчалась.
Далее для злоумышленника было бы логично повысить свои привилегии в системе. Проверим эту гипотезу с помощью следующего фильтра: src.ip == 10.159.12.12 && alert.cls == "Attempted Administrator Privilege Gain". Предположение оказалось верным: злоумышленник создает нового пользователя:
Но на скриншоте видно, что аутентификация не была пройдена, а значит, тикет не был выдан. Поскольку после этого не было успешных аутентификаций, можно сделать вывод, что попытка атаки успехом не увенчалась.
Далее для злоумышленника было бы логично повысить свои привилегии в системе. Проверим эту гипотезу с помощью следующего фильтра: src.ip == 10.159.12.12 && alert.cls == "Attempted Administrator Privilege Gain". Предположение оказалось верным: злоумышленник создает нового пользователя:
и проводит атаку DCSync - атака, которая имитирует поведение контроллера домена и просит другие контроллеры домена реплицировать информацию с помощью удаленного протокола службы репликации каталогов (подробнее о данной атаке: https://attack.mitre.org/techniques/T1003/006/). Ее признаки можно найти по фильтру src.ip == 10.159.12.12 && dcerpc.rqs.operation.name == "DsGetDomainControllerInfo" ):
Вывод
PT NAD хранит данные о всех сетевых взаимодействиях — это полезно, когда важно понимать, что предшествовало подозрительному событию. Фильтры в PT NAD — это мощный и полезный инструмент, позволяющий увидеть любую сетевую активность от начала и до конца как на ладони, однако для этого необходимо знать их основной синтаксис и уметь применять для своих целей.
Фильтруя информацию о сетевых сессиях, можно постепенно раскрутить цепочку атаки, чтобы понять хронологию ее развития, локализовать угрозу и принять компенсирующие меры.
Автор статьи: Никита Басынин, инженер отдела технического сопровождения проектов,
TS Solution.
Фильтруя информацию о сетевых сессиях, можно постепенно раскрутить цепочку атаки, чтобы понять хронологию ее развития, локализовать угрозу и принять компенсирующие меры.
Автор статьи: Никита Басынин, инженер отдела технического сопровождения проектов,
TS Solution.