Лучшие практики threat intelligence: советы и рекомендации

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

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

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

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

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

Данные threat intelligence приходят в различных форматах и проявлениях. Они могут включать 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 (например, некоторые антивирусные инструменты). Следовательно, в реальной ситуации правило, подобное этому, вызовет больше ложных положительных срабатываний, чем пользы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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