COVID FEEDS

Что произошло

27 марта известный агрегатор Security Feeds – Anomali опубликовал отчет об использовании в атаках индикаторов, связанных с COVID-19. В первой части отчета содержится краткий анализ видов атак и тактик их проведения с учетом пандемии. Однако, наше внимание привлекла вторая часть отчета – список обнаруженных на момент публикации индикаторов компрометации (IOCs). И мы решили взглянуть на него поподробнее.

Для далеких от Threat Intelligence читателей стоит добавить краткое пояснение. Security Feeds – это списки участвовавших в реальных атаках IP-адресов, доменов, хэшей, названий файлов и т.д (далее – репутационные списки).  По сути, это перечень улик, по которому можно с большой вероятностью определить факт атаки при корреляции в SIEM-системе. Обычно репутационные списки делятся по типу индикаторов компрометации и содержат поля, указывающие на степень доверия к этому индикатору (кто нашел, когда, в каких атаках был замечен, ссылка на источник). С помощью этих полей можно ранжировать степень доверия к индикатору и повышать\понижать критичность связанных с ним инцидентов, отсюда и «репутационные» в названии. Далее мы проведем небольшой анализ опубликованных данных, обработаем их для использования в SIEM и рассмотрим основные кейсы применения с учетом технических вопросов.

Обработка данных

Внимание! Далее описывается сугубо техническая информация о процессе обработки данных, которая будет интересна исключительно ETL-инженерам. При желании можно пропустить этот раздел и сразу перейти к разделу Анализ данных, там классно.

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

Для начала рассмотрим модель данных исходного списка. Список состоит из 7 полей:

  1. Date Reported – дата обнаружения индикатора в формате мм/дд/гг;
  2. Indicator – сам индикатор, формат меняется в зависимости от типа;
  3. Type – тип индикатора. Варианты:
    • Ссылка (URL);
    • Домен (Domain);
    • Доменное имя (Hostname);
    • IP-адрес (IP Address);
    • Хэш в формате SHA-1 (SHA-1);
    • Хэш в формате SHA-256 (SHA-256);
    • Хэш в формате MD5 (MD5);
    • Хэш в формате SSDEEP (SSDEEP);
    • Имя файла (File Name);
    • Тема электронного письма (Subject Line);
    • Электронный адрес (Email Address).
  4. Comments – краткое описание типа атаки и/или сопоставление APT-группировки;
  5. Source – источник, с помощью которого выявлен индикатор;
  6. Source URL – ссылка на источник обнаружения индикатора.

Особое внимание стоит уделить полю «Type» — разделение на отдельные типы Url, Domain и Hostname, как и использование нескольких сущностей для хэшей не имеет практического смысла. Обычно при работе с репутационными списками, SIEM инженеры настраивают сравнение всего поля события или его части с полем из списка. В связи с этим имеет смысл выделить несколько уникальных типов, по которым в дальнейшем будут строиться корреляции и добавить новое поле «Subtype» в котором будет хранится тип хэша или тип ссылки, если кому-то они в будущем понадобятся.

После проведенных манипуляций у нас получилось 6 основных типов:

  1. URL;
  2. IP Address;
  3. Hash;
  4. File;
  5. Subject Line;
  6. Email Address.

Посмотрим на поле «Date Reported» — такой формат даты («мм/дд/гг») встречается очень редко, а SIEM-системы обычно используют либо более распространенные форматы, либо Epoch Time. Так как возможности извлечения дат отличаются от решения к решению, а наша задача – универсальность, то проще использовать Epoch формат, который смогут распознать все. Таким образом, поле «Date Reported» с датой «12/3/20» превратилось в поле timestamp с содержимым «1585947600».

Далее, в процессе изучения данных внезапно оказалось что формат содержимого поля «Indicator» отличался от строки к строке и данные пришлось дополнительно очищать от различных артефактов. Например, избавляться от экранирования точек в ip-адресах: 69[.]172[.]75[.]223 -> 69.172.75.223 и подобных проблем.

После очистки данных поля были финально отсортированы и переименованы.В итоге получилась следующая модель данных:

timestampioctypesubtypecommentssourcesource_url
158421960064551b04da5c87e5ecaa8e315cdd186fac570fbf47ad3cf5eb3daf4b1138859dHashSHA256Malspam using …MalwareByteshttps://twitter.com/MBThreatIntel/status/1239253487369605120

Для сравнения старая модель:

Date ReportedIndicatorTypeCommentsSourceSource Url
3/15/2064551b04da5c87e5ecaa8e315cdd186fac570fbf47ad3cf5eb3daf4b1138859dSHA-256Malspam using …MalwareByteshttps://twitter.com/MBThreatIntel/status/1239253487369605120

Полей стало на 1 больше, но существенно повысилась универсальность и применимость списка, он может использоваться в любом решении без дополнительной настройки. Дополнительно были сформированы одномерные списки по каждому типу индикаторов для максимально быстрой интеграции с любым SIEM-решением:

  • covid_feeds_url
  • covid_feeds_hash
  • covid_feeds_ip
  • covid_feeds_file
  • covid_feeds_email_subject
  • covid_feeds_email_address

Данные репутационные списки можно скачать отсюда

Подводя итог обработки, получилось сделать следующее:

  1. Объединены похожие типы индикаторов. [URL, Domain, Hostname -> URL]
  2. Объединены в один тип «Hash» все хэши. [SHA-1,SHA-256,MD5, SSDEEP -> Hash]
  3. Добавлено поле «subtype», в котором содержатся дополнительные пояснения к типу.
  4. Очищены и преобразованы индикаторы в поле «Indicator».
  5. Изменен формат временной метки. [мм/дд/гг -> Epoch]
  6. Переименованы поля для более удобной интеграции в SIEM.
  7. Сформирован  один итоговый список со всеми типами и отдельные одномерные списки по кажому типу индикаторов.

Анализ данных

Для анализа будем использовать уже обработанный список «covid_feeds_all» . Он содержит более 3000 записей в формате csv и разделен на 7 полей:

  1. timestamp – дата обнаружения индикатора;
  2. ioc – сам индикатор, меняющийся в зависимости от типа;
  3. type – тип индикатора;
  4. subtype – подкатегория индикатора, например алгоритм для типа «Hash»;
  5. сomments – краткое описание типа атаки и/или сопоставление APT-группировки;
  6. source – источник, с помощью которого выявлен индикатор;
  7. source_url – ссылка на источник индикатора.

Начнем с анализа дат появления индикаторов. Если построить график по полю «timestamp» с периодом в 1 неделю, то получится следующее:

Рисунок 1. Распределение IOCs по времени появления

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

  • доверие к источнику индикатора;
  • частота реального использования в атаках;
  • частота ложно-положителных срабатываний;
  • актуальность (время появления);
  • и т.д.

Часть данного функционала довольно просто реализовать в рамках SIEM-системы – достаточно ввести время жизни индикатора (TTL) по истечению которого он перестает участвовать в корреляции. Данный функционал поддерживается большинством решений и его настройка не займет много времени.

Вернемся к анализу и попробуем посмотреть на распределение по типам индикаторов. Построим статистику по полю «type»:

Рисунок 2. Распределение IOCs по типам

Абсолютное большинство индикаторов относится к 3 типам:

  • URL (36%);
  • Hash (32%);
  • IP-address (29%).

Такое соотношение легко объясняется спецификой атак – большинство из них связано с фишингом. Более подробно тактики рассмотрены в базовом отчете Anomali, нам же данная информация позволяет сформировать перечень основных источников данных, при наличии логов которых в SIEM мы сможем эффективно использовать репутационный список.

  • источники для типа «URL»: прокси-серверы, межсетевые экраны класса NGFW (Next Generation Firewall), UTM (Unified Threat Management), IDS/IPS, включая HIPS, DLP-системы с модулями контроля Интернет-активности сотрудников;
  • источники для типа «Hash»: решения класса Sandbox, антивирусное ПО, программное обеспечение, предназначенное для расширенного аудита клиентских операционных систем (например – Sysmon), агенты SIEM систем или СЗИ от НСД;
  • источники для типа «IP Address»: межсетевые экраны, IDS/IPS, прокси-серверы, активное сетевое оборудование.

Остальные типы находятся в рамках погрешности (менее 5% в сумме), поэтому источники мы им подберем, но отметим как дополнительные (*):

  • источники для типа «File Name»: Клиентские средства защиты от несанкционированного доступа, Sysmon, Антивирусное ПО;
  • источники для типа «Subject Line»: Почтовый сервер, Средства защиты корпоративной почты от спама.
  • источники для типа «Email Address»: Почтовый сервер, Средства защиты корпоративной почты от спама.

Сформируем итоговую таблицу источников с ссылками на тип списка, который необходимо использовать:

Тип спискаИсточникиИспользуемый список
1URLПрокси-серверы
Межсетевые экраны класса NGFW (Next Generation Firewall), UTM (Unified Threat Management)
IDS/IPS (Включая HIPS)
DLP-системы с модулями контроля Интернет-активности сотрудников
covid_feeds_url
2HashРешения класса Sandbox
Антивирусное ПО
Sysmon
СЗИ от НСД
covid_feeds_hash
3IP AddressМежсетевые экраны
IDS/IPS
Прокси-серверы
Активное сетевое оборудование
covid_feeds_ip
4File Name*Клиентские средства защиты от несанкционированного доступа
Sysmon
Антивирусное ПО
covid_feeds_file
5Subject Line*Почтовый сервер
Средства защиты корпоративной почты от спама
covid_feeds_email_subject
6Email Address*Почтовый сервер
Средства защиты корпоративной почты от спама
covid_feeds_email_address

Применение

Определившись с источниками, необходимыми для работы, перейдем к методам использования «нашего» репутационного списка. Попробуем описать типовой механизм интеграции:

  1. В зависимости от собираемых в SIEM логов выбираем источники и определяемся с видами списков, которые планируем использовать.
  2. В зависимости от SIEM-системы добавляем один или несколько списков в качестве внутреннего объекта системы (Splunk – Lookup, ArcSight – Active List, Qradar – Reference Set, MP SIEM – Табличный список).
  3. Используем для корреляции, сравнивая поле события со значением из репутационного списка или же определяя вхождение записи из списка в поле.

Например, при сравнении поля «URL» от источника Proxy со значением «coronavirus-map.com» из списка, необходимо детектировать ссылки вида «subdomain.coronavirus-map.com».

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

  1. Ограничить применимость корреляционного правила  для определенных пользователей\активов. Стандартный способ уменьшения количества ложных срабатываний для SIEM-системы. Максимально простой вариант для реализации, но часть срабатываний теряется.

    Пример: ограничение правила на срабатывание только для критичных учетных записей.
  2. Использовать в составе существующих правил, но с повышением критичности инцидентов. Хороший метод для работы с TI-источниками, актуальный для большинства компаний. Позволяет существенно снизить нагрузку на аналитиков за счет приоретизации инцидентов.

    Пример: добавление условия в правило для критичных активов, повышающее его Severity до максимального.
  3. Использовать в качестве дополнительного параметра при скоринге риска. Похоже на предыдущий пункт, но актуально только для команий, использующих скоринг системы на базе SIEM, либо Splunk или Smart Monitor. Если в рамках SIEM построена риск-модель, отслеживающая все срабатывания для УЗ\активов, то мы создаем новое правило, в результате которого повышается общий скоринг объекта, но не создается инцидент.
  4. Ввести TTL для записей репутационного списка. Уменьшая время жизни записей в списке, мы уменьшаем количество срабатываний и реагируем только на актульные угрозы.

Также хотелось бы отметить, что использование репутационных списков не ограничивается исключительно SIEM-системой. Многие современные СЗИ поддерживают подобные инструменты.

Примеры:

  • можно добавить email из репутационного списка в базы спам-фильтров почтовых серверов и средств защиты от спама;
  • легко контролировать e-mail сообщения с темами писем из категории «covid_feeds_email_subject». При использовании правил транспорта сообщений, можно направлять копии подозрительных писем на отдельный e-mail для дальнейшей проверки аналитиками ИБ. Также может быть использован подход с использованием утверждений  модератором потенциально вредоносных сообщений;
  • IP-адреса и URL из репутационного списка легко добавляются в запрещающие правила прокси-серверов и межсетевых экранов и вообще не требуют внимания аналитиков.

В заключение, хотелось бы отметить, что правильное применение репутационных списков и\или Threat Intelligence платформ существенно увеличивает потенциал SIEM-систем. Использование индикаторов, которые применяются в реальных атаках помогает выявлять даже атаки, не описанные в рамках корреляционных правил, существенно уменьшать количество ложно-положительных срабатываний и нагрузку на аналитиков.

COVID-19, FEEDS, Smart Monitor, TI

© VolgaBlob, 2007-2022. Все права защищены.