Лучшие практики Threat Intelligence: советы

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

У нас были две коммерческие подписки APT, десять обменов информацией, около десятка бесплатных лент и обширный список узлов выхода TOR. Мы также использовали пару мощных обратных инструментов, мастерские скрипты Powershell, сканер Loki и платную подписку VirusTotal. Не то, чтобы центр реагирования на инциденты безопасности не сможет работать без всего этого, но если вы хотите поймать сложные атаки, вам нужно идти до конца.

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

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

Совет 1. Не возлагайте слишком больших надежд на поимку всего по хэшам: большинство вредоносного ПО сегодня полиморфно

Данные угрозовой интеллекта приходят в разных форматах и проявлениях. Они могут включать IP-адреса центров управления ботнетом, электронные адреса, участвующие в фишинговых кампаниях, и статьи о методах уклонения, которые группы APT собираются использовать. Коротко говоря, это могут быть разные вещи.

Чтобы разобраться в этом беспорядке, Дэвид Бьянко предложил использовать так называемую Пирамиду боли. Она описывает корреляцию между различными индикаторами, которые вы используете для обнаружения атакующего, и количеством “боли”, которую вы причините атакующему, если вы идентифицируете конкретный IOC.

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

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

Предвидя вопрос о том, как узнать, существует ли файл с заданным хэшем в нашей корпоративной сети, я скажу следующее: есть разные способы. Одним из самых простых методов является использование решения, которое поддерживает базу данных MD5-хэшей всех исполняемых файлов внутри предприятия.

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

Например, если вы знаете, что группа APT, нацеленная на ваш сектор экономики, отправляет фишинговые электронные письма с *.HTA-файлами на борту, то создание правила обнаружения, которое ищет такие вложения электронных писем, нанесет удар по атакующему ниже пояса. Им придется изменить тактику спама и, возможно, даже потратить деньги на покупку 0-дневных или 1-дневных эксплойтов, которые не дешевы.

Совет 3. Не возлагайте слишком больших надежд на правила обнаружения, созданные кем-то другим, поскольку вам нужно проверить эти правила на ложные положительные результаты и настроить их

Когда вы начинаете создавать правила обнаружения, всегда есть соблазн использовать готовые правила. Sigma – пример бесплатного репозитория. Это формат методов обнаружения, независимый от SIEM, который позволяет переводить правила из языка Sigma в ElasticSearch, а также в правила Splunk или ArcSight. Репозиторий включает сотни правил. Казалось бы, это отличная вещь, но, как всегда, дьявол кроется в деталях.

Давайте посмотрим на одно из правил обнаружения Mimikatz. Это правило обнаруживает процессы, которые пытались прочитать память процесса lsass.exe. Mimikatz делает это, когда пытается получить хэши NTLM, и правило обнаружит вредоносное ПО.

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

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

Совет 4. Проверяйте доменные имена и IP-адреса на наличие злонамеренного поведения не только на прокси-сервере и брандмауэре, но и в журналах DNS-сервера – и обязательно сосредоточьтесь на успешных и неудачных попытках разрешения

Злонамеренные доменные имена и IP-адреса – это оптимальные индикаторы с точки зрения простоты обнаружения и количества боли, которую вы причините атакующему. Однако они кажутся простыми в обращении только на первый взгляд. По крайней мере, вы должны задать себе вопрос, где взять журнал домена.

Если вы ограничиваете свою работу только проверкой журналов прокси-сервера, вы можете пропустить злонамеренный код, который пытается запросить сеть напрямую или запрашивает несуществующее доменное имя, сгенерированное с помощью DGA, не говоря уже о туннелировании DNS – ни один из этих不会 быть перечислен в журналах корпоративного прокси-сервера. Преступники также могут использовать VPN-сервисы с продвинутыми функциями или создавать пользовательские туннели.

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

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

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

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

Совет 6. Проверяйте все новые индикаторы на актуальность перед отслеживанием или блокировкой их

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

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

Совет 7. Автоматизируйте все рабочие процессы угрозовых данных до максимальной степени. Начните с полной автоматизации проверки ложных положительных результатов через список предупреждений, инструктируя SIEM отслеживать IOC, которые не вызывают ложных положительных результатов

Чтобы избежать большого количества ложных положительных результатов, связанных с интеллектом и полученных из открытых источников, вы можете выполнить предварительный поиск этих индикаторов в списках предупреждений. Чтобы создать эти списки, вы можете использовать топ-1000 сайтов по трафику, адреса внутренних подсетей, а также домены, используемые крупными сервис-провайдерами, такими как Google, Amazon AWS, MS Azure и другие. Также отличной идеей будет реализовать решение, которое динамически изменяет списки предупреждений, состоящие из топ-доменов/IP-адресов, которые сотрудники компании обращались в течение последней недели или месяца.

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

Совет 8. Сканируйте все предприятие на наличие индикаторов хостов, а не только хостов, подключенных к SIEM

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

1. Используйте сканеры IOC, такие как Loki. Вы можете использовать SCCM, чтобы запустить его на всех хостах предприятия, а затем передать результаты в общую сетевую папку.
2. Используйте сканеры уязвимостей. Некоторые из них имеют режимы соответствия, которые позволяют проверить сеть на наличие конкретного файла в конкретном пути.
3. Напишите скрипт Powershell и запустите его через WinRM.

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