Привет Хабр! Меня зовут Иван Костыря, и я работаю в команде VK SOC, а точнее — в группе реагирования, куда стекаются все подозрения на инциденты информационной безопасности в компании. Сегодня хочу рассказать немного о том, как мы ищем угрозы в периметре компании, какие средства и техники для этого используем. Если коротко, то этот процесс можно описать так — мы задаем себе очень много вопросов и постоянно ищем на них ответы. Статья будет интересна начинающим специалистам: здесь я обобщил основные практики и рекомендации, которые выработаны в индустрии и проверены опытом нашей команды.

Немного вводной теории

Threat Hunting — это непрерывный процесс проактивного поиска угроз в сети, которые не детектируются стандартными средствами защиты информации (СЗИ). Проще говоря, мы не заменим антивирус и дежурных SOC, но ищем всё то, о чем они даже не догадываются.

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

Частое заблуждение, что поиск угроз — это только проверка доступных индикаторов компрометации по данным SIEM. Это не совсем так. Отчеты (или фиды), содержащие конкретные индикаторы, это, конечно, хорошо, но они выходят уже после того, как инцидент случился и о нем стало известно. Искать его следы внутри компании хорошо и полезно, но уже немного поздно. Задача при поиске угроз — найти как можно раньше злоумышленника, не дожидаясь отчёта об уже случившемся инциденте.

Чем же отличается обычный мониторинг 24/7, от того, который дополнительно занимается постоянным поиском скрытых и неочевидных угроз. Поясню на примере с Kill Chain, на который накладываются реалии большой компании. У злоумышленника есть стандартные шаги, которые делятся на техники разведки, подготовки, донесения и так далее. Учитывая размеры компаний, не всё можно отсмотреть и не на каждую угрозу нужно реагировать мгновенно, в работу передаются точные сработки, которые точно имеют угрозу.

Такой подход имеет ряд слепых зон, в которых и может скрываться атакующий. Конечно, в какой‑то момент действий злоумышленника его заметит и команда дежурных SOC и стандартные средства защиты, однако время, пока злоумышленник может находиться внутри компании и вне зоны действия радаров систем обнаружения, может достигать месяцев, что недопустимо с точки зрения безопасности компании и конфиденциальности информации. Чем больше времени злоумышленник не видим, тем больше и качественнее он проникает и изучает сеть, закрепляется в ней и скрывает следы своего присутствия. Напомню, что SOC, в стандартном представлении мониторинга 24/7, смотрит на обнаружения правилами SIEM и за сработками различных СЗИ, выявляет угрозы и находит злоумышленника, однако, тут есть несколько «моментов»:

1. Дежурные смотрят и видят только то, что отгружается на поток — то есть надежные, проверенные правила с минимумом ложных срабатываний.

2. Большинство правил базируются на временной выборке — то есть проверке за определенный промежуток времени или срабатываний при достижении некоторого порога значений.

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

4. Оператор может не увидеть начало атаки на ранних этапах, а на поздних этапах часть действий злоумышленника может не отличаться от действий легитимного пользователя или администратора.

5. Написанные правила детектирования должны быть актуальными, разработанными с учетом используемых в дикой природе инструментов.

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

В идеальном мире

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

У нас в VK SOC на данный момент используется 1200+ правил для разностороннего мониторинга инфраструктуры, применяются различные методы поиска злоумышленника (будь то количественные показатели или единичные качественные события). Везде написаны Playbook‑и, и мы готовы к различным вызовам — будь то пентест, аудит или реальные злоумышленники. Написание Playbook к каждому правилу это не роскошь, а необходимость при используемом количестве контента — всё знать невозможно.

В самих правилах применяется маппинг на инструменты MITRE, ATT&CK® и D3FEND, как на картинке ниже.

Таким образом у дежурного есть вся доступная база знаний, а если чего‑то не хватает, то он всегда может передать кейс коллегам на вторую линию для глубокого расследования или обратиться за пояснениями.

Вообще, маппинг на ATT&CK позволяет посмотреть, насколько хорошо вы покрываете известные и популярные ТТР, что придает некоторую уверенность и спокойствие — мы все видим и защищаем. Следить за актуальностью можно с помощью разных средств — от таблицы в excel, где в одном столбце проставлены правила и дата их проверки боем в другом до более автоматических инструментов вроде Vectr.

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

А теперь, как мы ведем поиск угроз 

В описанной картине мира мониторинга остается ряд слепых зон, в которых может прятаться злоумышленник, с этого момента начинаем его искать в рамках Threat Hunting (TH)/Threat Intelligence (TI) процесса. В VK он выведен в рамки отдельного ежедневного дежурства, чтобы можно было и свежий отчет проверить и в режиме реального времени проверить ПО или поведение пользователя, которое начало аномально себя вести, но при этом не попадает под правила детектирования.

На основе каких данных мы работаем? Конечно, основной рабочий стол TH‑аналитика — это SIEM с огромным множеством подключенных источников. Если данные слишком экзотичны и по какой‑то причине не заведены в SIEM, мы идём за сырыми данными, где нужно немного «погрепать».

Частое заблуждение, которое мне приходилось слышать, что для поиска угроз в реактивном и проактивном режиме используются одни и те же правила. Это не так. Правило может быть максимально полезным с точки зрения TH, например, вызов команд WHOAMI или SUDO SU на рабочей станции пользователя. Но разве подобный вызов будет являться сразу индикатором компрометации? Когда в команде несколько тысяч программистов и администраторов, таких вызовов за день может быть больше пары‑тройки десятков и все они будут помечены сменой как false. К слову, данную задачу с подтверждением не опасных команд, которые вводятся в консоль автоматизировали и убрали данные сработки с потока событий для первой линии. Логика простая, происходит детект на ввод команды в консоли, отрабатывает автоматика, которая идёт за подтверждением в мессенджер к пользователю и ждёт от него ответа:

Подобные детектирования, которые приносят много false‑обнаружений, но используемые в TH для понимания окрестности событий, у нас в команде помечаются с помощью «Building Block» и не тревожат смену дежурных, но просматриваются в ретроспективном порядке вместе с другими детектами.

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

Некоторые девиации поведения на хосте или авторизации пользователей может покрыть ML‑job.

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

Также стоит помнить про особенности компании. У нас внедрена полная конфиденциальность нашего пользователя и сотрудника, поэтому все, что у нас есть, это телеметрия продуктов, зачастую без контекста события, или логи после санитации.

Пирамида боли

SOC в рамках TH/TI ищет, в первую очередь, следы присутствия злоумышленника в сети, и проще всего это делать с применением «пирамиды боли».

Пройдемся по искомому снизу вверх:

• Хеши. Тут всё просто. У каждого файла в системе есть контрольная сумма, она более‑менее уникальна и позволяет быстро проверить, есть ли какой‑то известный вредоносный файл на подконтрольных хостах в сети. Хеш‑суммы вредоносных файлов мы можем получить из различных источников, это частый и распространенный индикатор компрометации, который может быть и банален, но может стать хорошей отправной точкой расследования. По разным причинам, некоторый вредоносный файл может попасть в сеть, в том числе не по вине пользователя и даже при самом идеально отстроенном периметре защиты можно найти способ доставки в сеть. На этапе проверки хешей мы пытаемся найти доставленное и у нас есть 2 основных подхода к проверке — в реальном времени и по ретроспективному анализу. В реальном времени всё просто — есть список контрольных сумм вредоносных файлов, если он встретится нам как запущенный «сейчас», то на него среагирует аналитик первой линии. В случае с ретроспективным анализом задача состоит сложнее. Нужно сделать поиск по запущенным файлам из прошлого, например, не встречался ли вредоносный файл неделю, месяц, год назад. На этом же уровне проверяются известные «имена», например, ID зараженного расширения браузера.

  

• IP‑адреса/имена доменов. Тут посложнее. Если подходить к вопросу стандартной проверки отчета, то, с одной стороны, есть список адресов/имен и время, когда они примерно были использованы злоумышленниками, и тут, соответственно, нужно смотреть на хостовые данные (куда делались коннекты) и данные сетевого оборудования, а дальше сопоставлять, что, где и как там было. Но где ещё могут быть IP‑адреса или доменные имена использованы? Конечно, в любом другом источнике — письма, web‑proxy, DNS и далее, далее, далее...

  

• Отдельно также стоит заранее подумать о том, как обогатить IP — данный шаг позволит сильно сэкономить время во время анализа. Для внешних адресов и гео‑метка нужна и репутационная информация, сервисы на адресе, если адрес внутренний, то принадлежность сервису, инвентарная информация. К примеру, мы используем обогащение на основе открытых данных — сделали скрипт, который получает список активных TOR‑exit‑node каждые 30 минут, складывает их в два отдельных индекса (текущие ноды и все нам известные), после чего SIEM отрабатывает правилом Indicator‑Match (заодно происходит обогащение информации о внешнем IP) на предмет взаимодействия с данными адресами. Так, например, мы видим коннекты к TOR‑сети.

• Аналогично будем искать и артефакты, схожие с уже известными по различным TI, будь то SSH‑ключи, TLS‑сертификаты, различные прокси и не только. Тут всё ещё подразумевается, что мы либо ищем что‑то новое и не знакомое (например, добавление нового SSH‑ключа в прод‑хосты) или уже известное по данным отчета (то есть, поиск известных IoC).

• Инструменты и Техники/процедуры для поиска и подтверждения. Это совокупность нескольких событий по данным хоста или систем. Например, мы знаем, что несколько группировок использует какой‑то легитимный инструмент в своих атаках и этот же инструмент можно встретить в ежедневной работе пользователей:

  

Значит, нам нужно определить не только запуск какого‑то ПО, но и его контекст — кем, когда и что было источником запуска, какой контекст операции. Тут уже без корреляций, хорошей нормализации данных, обогащения и в том числе кросс‑индекс поиска будет сложно. Когда определились с используемыми инструментами, нужно понять тактики и техники, которые используются злоумышленниками. Это уже более сложная последовательность событий и задействованных средств, которые в разных случаях пытаемся детектировать правилами. Для обкатки детектирования и ознакомления с тем, что нужно найти в потоке событий, можно взять atomicredteam — поиграть в сам‑себе‑пентестер и понять какие события будут при использовании распространенных средств взлома, т. е. что будет видно мониторингу, когда атака на самом деле произойдет с той или иной утилитой.

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

А теперь про логику

С индикаторами всё более‑менее понятно, давайте попробуем разобраться с логикой аналитика. Зачастую, отправной точкой становится выход очередного отчёта коллег по цеху или пост про раскрытые инциденты. В них можно найти хороший пласт информации для начала поиска:

• известные IoC;

• используемые инструменты (а значит, и поведение систем при эксплуатации озвученных средств);

• тактики и техники злоумышленников;

• иногда (но далеко не всегда), атакованные цели. При наличии, можно искать ещё и точки взаимодействия с атакованной инфраструктурой.

Как говорится, все вводные хороши.

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

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

А если индикаторы из отчета не нашлись? Тогда идем на второй виток проводимого исследования, и новая серия вопросов: а все ли описанные инструменты и техники мы отслеживаем, а все ли используемые злоумышленниками (а значит, и актуальные уязвимости) у нас закрыты?

С этого момента начинается работа в двух направлениях:

• проверить на применимость атаки к нашей инфраструктуре (например, легитимно ли ПО, действительно ли используется, содержит ли уязвимости);

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

Разложим оба этапа работы на несколько вопросов, которые проверяет специалист TH.

1. Применимость атаки к инфраструктуре:

• Установленное ПО: есть ли у нас уязвимые версии ПО? Когда проводилось сканирование, какие есть данные с инвентаризации хостов? Знает ли инфраструктура о том, что есть CVE/PoC?

• Используется не легитимное ПО: откуда оно появилось на хосте и как давно?

• Используется уязвимое ПО, а патча нет: какие будут следы эксплуатации уязвимости, есть ли они на сети? Какие есть контрмеры и приняты ли они?

• Вектор атаки известен, поставлен на мониторинг, но были ли сработки и знает ли первая линия SOC, что с этим делать?

Последний пункт может быть не совсем очевидным, и он отвечает за то, когда сотрудник первой линии SOC из тысячи сработок одного и того же правила детектирования не видит реальной угрозы. Качество, точность и понятность написанного и разрабатываемого контента для мониторинга (правила, дашборды, написанные инструкции, обогащения и нормализация данных) тоже постоянно должно дорабатываться. С другой стороны, мы не можем оставить на мониторинге только на 100% точные и только особо критичные события, вроде дампа LSASS. Если у вас уже сделан дамп для извлечения паролей, а все предыдущие шаги злоумышленник совершил без малейшего скрипа, то что‑то в работе идёт неправильно. Если оставить только точные и только критичные сработки правил, тогда первую линию заменит скрипт, оповещающих ответственных, но процент детектирования злоумышленника на ранних этапах будет ниже.

И обратная сторона медали — это фолсы в написанных правилах. Предположим, исследуемый отчет содержит простые вызовы PowerShell и мы решили по следам чужого инцидента сделать аналогичный мониторинг на своей сети:

Не стоит ставить на мониторинг все вызовы PowerShell или запуск любого скрипта, правильным решением будет организовать точечный мониторинг - скачивание файлов с неизвестного адреса, запуски с привилегиями системы, использование base64 либо попытки отключения систем защиты, то есть, то, что в более явном виде несет угрозу. Остальные вещи, которые не приносят положительного результата в 90% случае можно поставить на поиск с пометкой «TH», чтобы проверять отдельно и не беспокоить дежурную смену.

Серые зоны, или Когда вопросов больше, чем ответов

Не стоит так же забывать о ретроспективном анализе данных, как в плане сработавших правил и поиска индикаторов, так и без всего этого. Допустим, узнали что‑то новое и написали новое правило, оно будет отрабатывать на новых данных, которые получаете «сейчас» и в них сработок нет, а при ручной проверке того же нового вектора, который раньше не отслеживали, открылись новые горизонты происходящего на сети (предположим, в ретро‑данных за прошлый месяц найдена установка руткита или стороннее SSH‑подключение и последовавшее отключение агента мониторинга). Что делаем? Спокойно смотрим на полученные находки, подтверждаем, что инцидент имел место быть, расследуем, собираем список собственных артефактов и обязательно возвращаемся на шаг проверки найденных индикаторов на сети, смотрим что было дальше и плавно реагируем на случившееся, ищем пробелы в мониторинге и исправляемся, т. е. цикл поиска замкнулся. Не хватает данных из‑за давности в SIEM — подключаем возможности извлечения журналов и артефактов с рабочей станции.

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

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

Посмотрим ещё на один пример, где инцидент мог начаться с письма. Это письмо не дошло до конечного пользователя, и на просторах интернета можно найти TI‑отчет по доступным индикаторам из аналогичного письма:

Из доступного образца, логов систем и опубликованного отчета другими исследователями проверили всё, что только могли: хеши, отправителя, тему письма, но что, если тема письма была другая? Есть ли переписка не только с отправителями, но и в целом с найденным почтовым доменом? Как отработает антиспам на подобное донесение, какие правила отработают на попытки отправки фишинга по различным схемам? Есть ли статистика однотипным письмам/отправителям, особенно с вложениями или ссылками? Не было ли там подозрительных рассылок, особенно с ключевыми словами вроде «Срочно, в бухгалтерию, приказ всем установить...». Хорошим тоном будет поиск по теме и названию вложений, где можно встретить добавление переменных, например, «Оплата №XXX от Дата » или «DocXXX.xls». Всё это идёт в дополнение к известным артефактам, вроде исполняемых вложений, архивов с паролями, *.lnk или *.img экзотических вложений.

Так же не стоит забывать про заголовки из писем, в них содержится много полезной информации:

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

Рано или поздно инцидент случится и любой инцидент закончится, а мы снова на исходной.
Все отчеты проверены — никаких находок. Все правила написаны и разделены: что‑то в реактивном мониторинге 24/7, что‑то для ретроспективного TH. Все детекты посмотрели — никаких аномалий. Наладили своевременное информирование о выходящих уязвимостях, патчах, опубликованных PoC. Множественных аномалий нигде нет. Настроен ML, который ищет девиации в поведении пользователей/DNS‑запросов/почтовых писем и тоже ничего. Настроили мониторинг работоспособности средств защиты и самих правил. Подключили всевозможные фиды и настроили индикаторные правила — тоже никаких аномалий.

Кажется, что можно успокоиться и уйти в режим наблюдения? Нет.

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

Главное, не терять мотивации и продолжать свой поиск, к чему бы он нас не привел.