Понедельник, 9:15 утра. SOC-аналитик фиксирует кластер алертов: 14 писем с .iso-вложением от домена, зарегистрированного 36 часов назад, разлетелись по трём департаментам за 20 минут. К 11:00 EDR ловит C2-beacon на хосте бухгалтера. К 14:00 - lateral movement через скомпрометированные credentials. SIEM забит индикаторами: IP, хеши, домен. Но три вопроса висят без ответа: кто стоит за атакой, какую инфраструктуру переиспользует группировка и кто станет следующей жертвой.
Блокировка единичного C2-домена закроет тикет. Кампанию - нет. И вот тут Diamond Model превращает россыпь IOC в структурированное расследование - от алерта до атрибуции.
Зачем SOC-аналитику модель Diamond в threat intelligence
Большинство SOC работают в режиме «алерт → IOC → блокировка → следующий алерт». По данным CrowdStrike Global Threat Report 2025, среднее время lateral movement после initial access - 62 минуты, рекорд - 51 секунда. При таких скоростях поиск по хешам и IP - тупик: атакующий сменит индикаторы быстрее, чем аналитик допишет правило. Подробнее - в нашем обзоре apt-группировки.Diamond Model предложили Sergio Caltagirone, Andrew Pendergast и Christopher Betz в 2013 году для Министерства обороны США. Она решает другую задачу - не «что заблокировать», а «что связано с чем». Каждое событие вторжения (intrusion event) раскладывается на четыре вершины ромба - adversary, capability, infrastructure, victim - и шесть двунаправленных рёбер между ними. Сила не в вершинах, а в рёбрах: зная инфраструктуру, аналитик pivotит на adversary; зная capability - предсказывает victim. Один IOC разворачивается в граф связей.
Финансовый контекст: по Mandiant M-Trends 2025, медианное время нахождения злоумышленника в сети до обнаружения - 11 дней. По Verizon DBIR 2025, медианный выкуп ransomware - $46 000, максимальный зафиксированный - $75 млн. Каждый из этих 11 дней - наращивание ущерба. Diamond Model позволяет обрезать его раньше: не через единичный IOC, а через инфраструктурные связи кампании.
Четыре вершины Diamond Model для расследования инцидентов
Adversary - кто атакует и зачем
Adversary - не абстрактная «хакерская группировка из страны X». Diamond Model различает adversary operator (исполнитель) и adversary customer (заказчик). В модели Ransomware-as-a-Service это разные сущности с разной инфраструктурой и разными TTPs: initial access broker продаёт доступ, ransomware-оператор шифрует, вымогатель ведёт переговоры. Три разных ромба, три разных набора индикаторов.Что заполняем на практике:
- Известные alias и APT-идентификаторы (если атрибуция возможна)
- Мотивация: финансовая (86% атак по CrowdStrike 2025), шпионаж, хактивизм
- Паттерны таргетинга: отрасли, географии, размер жертв
- Связь с предыдущими кампаниями через переиспользование инфраструктуры
Отдельная история - insider threat и скомпрометированные легитимные учётки. По CrowdStrike 2025, 75% вторжений используют valid credentials. Diamond Model обрабатывает это без проблем: adversary - сотрудник или владелец скомпрометированного аккаунта, infrastructure - корпоративные ресурсы, capability - легитимные инструменты администрирования (PowerShell, RDP, PsExec). Модель одинаково работает для внешнего APT и внутреннего нарушителя.
Infrastructure - C2, домены и скомпрометированные хосты
Infrastructure - физические и логические ресурсы для доставки capability и управления операцией. Два типа:Type 1 (собственная): зарегистрированные домены, арендованные VPS, купленные SSL-сертификаты - маппится на технику Acquire Infrastructure (T1583, Resource Development).
Type 2 (скомпрометированная): взломанные легитимные серверы, угнанные аккаунты облачных сервисов - Compromise Infrastructure (T1584, Resource Development).
Type 2 - головная боль для detection. Скомпрометированный легитимный хост выглядит как нормальный трафик. Пример: по данным Microsoft Threat Intelligence, операция CaptiveCrunch - группировка Storm-2945 (подкластер Midnight Blizzard) компрометировала порталы авторизации гостиниц для доставки malware и кражи credentials у путешественников. Infrastructure - легитимные сайты отелей. Блокировка по домену невозможна без анализа контекста.
Инструменты для работы с этой вершиной: пассивный DNS (SecurityTrails, RiskIQ) для выявления связанных доменов - техника DNS/Passive DNS (T1596.001); WHOIS-записи для идентификации регистранта - техника WHOIS (T1596.002); Shodan и Censys для fingerprinting серверов - Active Scanning (T1595); VirusTotal для поиска артефактов, коммуницирующих с IP или доменом.
Capability - инструменты и TTPs атакующего
Capability - совокупность инструментов и техник adversary: фишинговые письма, exploit-код, кастомные бэкдоры, living-off-the-land бинарники. Каждый capability маппится на конкретные техники MITRE ATT&CK: например, сбор информации о сетевой инфраструктуре жертвы - Gather Victim Network Information (T1590, Reconnaissance).Что фиксируем:
- Хеши malware (SHA-256 - не MD5, коллизии никто не отменял)
- TTPs по ATT&CK-матрице
- Exploit-код и CVE (если применимо)
- Классификация инструментария: коммерческий (Cobalt Strike), open-source (Sliver), кастомный
Victim - профиль цели и паттерны таргетинга
Victim декомпозируется на два уровня:Victim persona: отрасль, размер организации, география, роли атакуемых сотрудников.
Victim asset: конкретные системы, данные и сервисы под атакой.
Паттерны таргетинга позволяют предсказывать будущие атаки. Если adversary последовательно атакует финансовый сектор через email-адреса бухгалтерии - при получении фишинга на адреса финансового департамента порог алерта должен быть ниже.
По Verizon DBIR 2025, 68% утечек связаны с человеческим фактором. Victim-вершина фиксирует этот фактор: не только «какой хост скомпрометирован», но и «почему именно этот сотрудник стал entry point». Часто ответ прозаичен - он единственный кликнул на .iso.
Мета-фичи и activity threading
За пределами четырёх вершин Diamond Model определяет мета-фичи: socio-political axis (связь adversary-victim - мотивация: шпионаж, финансы, хактивизм) и technology axis (связь capability-infrastructure - протоколы, шифрование, каналы C2). Плюс: timestamp, phase (маппинг на Kill Chain), result (успех/провал), direction.Отдельные diamond-события редко существуют изолированно. Activity threading связывает их хронологически в единую нить: от initial access через lateral movement до exfiltration - каждый шаг представлен отдельным ромбом, объединённым общими вершинами. Activity group - кластер нитей с общими feature-значениями, фактически профиль кампании или adversary.
Практический кейс: от фишингового алерта до связывания кампании
Разберём пошагово, как заполнить Diamond Model на обезличенном инциденте.Шаг 1. Входная точка - Victim asset. SIEM-алерт: исходящий трафик к IP, отсутствующему в baseline. Хост - рабочая станция сотрудника HR-отдела. Фиксируем: victim persona = HR, victim asset = workstation (hostname, IP, OS).
Шаг 2. Capability. На хосте - .iso с .lnk внутри, запускающий PowerShell-загрузчик. EDR фиксирует SHA-256 дроппера. VirusTotal показывает 3/70 детектов - свежий образец, антивирусы ещё не переварили. Фиксируем: capability = PowerShell loader + custom implant, TTPs = фишинг с вложением, PowerShell execution.
Шаг 3. Infrastructure. C2-beacon ведёт на IP
198.51.100[.]42 (обезличен). Пассивный DNS через SecurityTrails раскрывает три домена, резолвящих на этот IP за последний месяц. WHOIS показывает регистрацию через privacy-прокси 48 часов назад. Shodan выявляет открытый порт 443 с self-signed сертификатом. Фиксируем: infrastructure Type 1 = три домена + один IP.Шаг 4. Pivoting на adversary. Один из трёх доменов фигурирует в фиде MISP CIRCL как индикатор фишинговой кампании, нацеленной на гостиничный сектор (event от 2026-06-01, Phishing Campaign Targeting Hotel Customers in Luxembourg). Совпадение инфраструктуры позволяет выдвинуть гипотезу: activity group с пересечением по Type 1 infrastructure. Adversary пока = «кластер активности», не конкретная группировка. И это нормально - атрибуция до имени APT приходит позже, если вообще приходит.
Шаг 5. Activity threading. Три diamond-события (три жертвы в разных организациях) объединяются в один activity thread через общую infrastructure и capability. Каждое событие - отдельный ромб, но с общими вершинами. Это позволяет предсказать: если adversary зарегистрирует новый домен на тот же privacy-прокси - мы увидим его ещё до начала рассылки.
Pivoting между вершинами: чеклист аналитика
Pivoting - переход от известной вершины к неизвестным через рёбра Diamond Model. Аксиома 7 (Infrastructure Reuse) - ключевая: adversary переиспользует инфраструктуру между кампаниями, потому что регистрация доменов и аренда серверов стоят денег и времени. Экономика атакующего работает на нас.От Infrastructure к Adversary:
- Какие ещё домены зарегистрированы на тот же email или privacy-прокси?
- Какие samples в VirusTotal коммуницируют с этим IP?
- Есть ли пересечения с известными adversary-кластерами в OpenCTI/MISP?
- Какие организации получали трафик от этого C2 (netflow, pDNS)?
- Какие другие хосты в нашей сети обращались к связанным доменам (DNS-логи SIEM)?
- Есть ли пересечения с доменами партнёров и подрядчиков?
- Какие C2-серверы прописаны в конфиге malware (config extraction)?
- Есть ли другие samples с аналогичным config-шаблоном?
- Какие уязвимости эксплуатирует этот capability - и какие из наших систем уязвимы?
- Какие detection-правила покрывают эти TTPs в нашем SIEM?
- Кто ещё атаковал организации в нашей отрасли/регионе (threat intel feeds)?
- Совпадает ли victim persona с известными targeting preferences?
Методология анализа вторжений: Diamond Model vs Cyber Kill Chain vs MITRE ATT&CK
Три фреймворка не конкурируют - они закрывают разные аналитические задачи. Ошибка: выбирать один и игнорировать остальные.| Критерий | Diamond Model | Cyber Kill Chain | MITRE ATT&CK |
|---|---|---|---|
| Тип анализа | Реляционный (связи между сущностями) | Последовательный (фазы атаки) | Поведенческий (каталог TTPs) |
| Главный вопрос | «Что связано с чем?» | «На каком этапе атака?» | «Какую технику использовали?» |
| Сильная сторона | Pivoting, атрибуция, campaign tracking | Визуализация прогрессии атаки | Стандартизация TTPs, маппинг detection |
| Слабая сторона | Не показывает хронологию фаз | Линейна, не учитывает параллельные действия | Каталог без реляционной структуры |
| Когда использовать | Threat intelligence, кластеризация кампаний | Incident response, отчёт для менеджмента | Detection engineering, threat hunting |
Рабочий workflow: Kill Chain определяет фазу, ATT&CK - конкретную технику, Diamond Model - связи между событиями. Activity thread в Diamond Model использует Kill Chain phases для упорядочивания событий внутри нити, а capability-вершина заполняется ATT&CK-техниками. Три фреймворка - три слоя одного расследования.
По анализу Vectra.ai, расширенная модель Cisco Talos 2025 года добавляет пятый Relationship Layer для multi-actor кампаний: initial access broker передаёт доступ ransomware-оператору, у каждого - свой Diamond с разными вершинами. Relationship Layer формализует связи между ромбами разных adversary-кластеров.
Detection из Diamond-событий: правила корреляции для SIEM
Девять из десяти SOC, с которыми я работал, строят detection вокруг отдельных IOC. Но IOC - моментальный снимок: IP живёт дни, домен - недели. Diamond Model сдвигает фокус с индикаторов на поведение adversary, и это принципиально другой уровень зрелости detection engineering.
Команда, которая после каждого значимого инцидента заполняет Diamond-событие и прогоняет pivoting-чеклист, через полгода имеет не набор разрозненных правил, а граф связей между кампаниями. Этот граф позволяет детектировать следующую атаку той же группировки до того, как EDR увидит первый beacon - по инфраструктурному пересечению.
Частое возражение: «Нет ресурсов на полноценный CTI-процесс». Но Diamond Model - не отдельная функция, а способ мышления при реагировании. Заполнение четырёх вершин для одного инцидента занимает 30–40 минут, если аналитик знает, какие вопросы задавать. Pivoting-чеклист из этой статьи - готовый шаблон. Проблема не в ресурсах, а в том, что после закрытия тикета никто не возвращается к инциденту для связывания с кампанией.
Попробуйте на следующем инциденте: заполните четыре вершины, прогоните pivoting-чеклист, загрузите событие в MISP. Через три месяца посмотрите, сколько связей всплыло. По свежим инцидентам этого типа на форуме codeby.net разбираем pivoting-кейсы и связки индикаторов - коллеги делятся рабочими корреляциями, которые не найдёшь в публичных отчётах.
