Размышляя над списком IoC поймал себя на мысли, что данный список чаще всего пополняется из каталогов вроде ФСТЭК.
Для тех кто не в теме, IoC (Indicator of Compromise - индикаторы компроментации), это артефакты (информационные данные), если добавить данные этих артефактов в специальный софт (например антивирус), то можно проверить свою инфраструктуру на предмет наличия следов. Иногда бывает так что злоумышленники находятся в сети подолгу, никак себя не проявляя до определённого момента.
Данный метод борьбы называется Threat Hunting - охота за угрозами и является проактивным методом борьбы. Это один из ключевых методов кибербезопасности. В рамках этого метода безопасник получает IoC - например из отчётов APT, OSINT и иных расследований, где артефактами являются IP, хэши файлов, домены и т.п. Затем вносишь эти данные в специализированные программы, и ищешь их у себя в инфраструктуре, если эти артефакты оказались найдены, необходимо провести расследование с целью выяснить каким образом они попали в инфраструктуру (IR - Incident Response).
У данного метода есть один недостаток, это надо проводить постоянно, часто вручную (особенно если организация не имеет финансов на услуги от специальных организаций или покупку специализированного ПО)
Часто бывает так что работа устроена следующим образом, например сработал алерт в SIEM на брутфорс (самый простой пример). Аналитик (или администратор) получил алерт на почту, после чего идёт на VIRUS TOTAL, Abusel, Domaintools и т.п. инструменты для проверки, затем по результатам принимает решение о передаче полученной информации и рекомендациях, или самостоятельной блокировке (если есть такая возможность). Я например часть этой работы делегировал LLM настроив агента на n8n, по итогу работы получал готовый список артефактов и уже принимал решение о необходимых действиях.
Тогда у меня не стояло ни каких-то специальных задач, (я работал системным администратором и это было вне зоны моей компетенции) поэтому можно сказать это было факультативным занятием, к тому же если это происходит постоянно то это отнимает время и хотелось автоматизировать этот процесс.
Забегая вперёд у меня тогда не было таких инструментов вроде The Hive, Cortex, ELK, Velociraptor и подобного ПО. Поэтому все свелось к n8n но уже сейчас я думаю, что эти инструменты можно заставить работать в симбиозе.
Итак, давайте покажу на примере, как можно настроить Logstash для пополнения например IP в специально созданном для этого индексе.
Суть схемы следующая: кто-то пытается методом брутфорса попасть на некий сервер, например nginx. Logstash видит попытки и вносит IP в индекс, затем все последующие успешные попытки входа сравниваются с этим индексом и в случае положительного ответа получаем алерт.
Я думаю что схему работы ПО можно настроить довольно гибко вплоть до автоматический блокировки и изоляции отдельных хостов и узлов. Но у нас будет самый самый простой пример.
В SIEM настроено правило, которое например после 5-й неудачной попытки набрать пароль покажет что: с этого IP адреса идут попытки зайти туда-то.
Отдельно создадим индекс в который будут добавляться подозрительные IP адреса.
Создаём индекс:
3_finale_sprint_security_watchlist
"settings" - настройки и его опции
"number_of_shards": 1, // ← Сколько "кусочков" у индекса
"number_of_replicas": 0 // ← Сколько резервных копий каждого кусочка
шард это часть индекса, он у нас 1 и всё хранится в одном месте. (для продакшена нужно больше)
реплика это резервная копия, если его не указать то по умолчанию будет 1, это будет тратить ресурсы, поэтому 0. (Для продакшена обязательно)
"dynamic": true - если придёт поле "reason": "ssh_attack" - автоматически добавить, я использую в тестах, но для продакшена лучше убрать так как со временем там накопится много лишнего и лучше создать отдельный индекс если он не связан с текущей задачей.
"source.ip" тип keyword - позволит нам хранить данные как есть, самое-то для хранения хэшэй, IP и доменов.
"bruteforce_ioc" тип boolean - да нет "true" или "false"
"@timestamp" тип date - чтобы Elasticsearch знал что это дата - можно фильтровать по времени, спросить графики и так далее.
Параллельно в SIEM создаем простое EQL правило:
Затем добавляем в logstash conf
парсинг
Детектирование
вывод и проверка через enrich
Это мы добавляем для того чтобы данные сверялись с индексом и на лету вносились правки. Иными словами перед тем как будет проводится запись в условный logs* пропусти его через ingest pipeline c именем chek_ssh_watchlist, внутри моего пайплайна используется enrich-процессор который берёт source.ip из получаемого события затем ищет его в индексе
вывод и добавление в индексе 3_finale_sprint_security_watchlist и если находит добавляет новое поле например в нашем случае получается следующее:
Обогащение событие из списка:
Берет IP из source.ip ищет его в индексе привязанном к политике ssh_watchlist_policy и если находит то добавляет все поля из IoC в субобъект watchlist_match
Событие станет таким:
Добавляет удобный нам флаг через скрипт
"is_known_attacker": true
Что это даёт?
Мы можем искать все события с is_known_attacker: true и сразу видеть ВСЕ ДЕЙСТВИЯ этого IP даже если это не было связано с атакой из правил. Таким образом мы можем сделать дашбоард например: Активность известных атакующих и создавать алерты на любое взаимодействие с вредоносным IP (а не только как в нашем случае с SSH) а это уже расширяет наш SOC за пределы одного правила.
выглядит в целом это так:
ssh_watchlist_policy связывает индекс-источник данных 3_finale_sprint_security_watchlist поле для поиска source.ip
В результате мы получили автоматическое обогащение самого события.
И наконец если событие есть, вносим source.ip в индекс 3_finale_sprint_security_watchlist
По итогу после создания условного правила вроде:
Мы получим не только алерт с атакующим но и можем искать любую активность связанную с данным IP так как пометили её специальным образом.
Эта статья была создана просто как пример с IP, чуть (ну ладно не совсем чуть))) но такое можно и нужно сделать с хэшами так как это один из самых мощных методов обнаружения вредоносной активности. Обычно сбор хэшей получаем из EDR-агентов (например Velociraptor и тд), filebeat + auditd/sysmon (linux/windows) и песочниц (Virustotal или Cuckoo) парсить в Logstash поле условно: flie.hash.sha256 и сверять с IoC через enrich или indicator match rule в Kibana. Наполнять такой индекс можно не только так как в нашем примере но и в ручную из отчётов о APT.
Надеюсь эта статья была вам полезна.
Всем счастливого нового года и ни фишинга, ни брутфорса!!