Оглавление
1. Введение: Почему ручной разбор EVTX — это путь в никуда2. Что такое Hayabusa: Архитектура, Rust и философия DFIR
3. Установка и первичная настройка: От бинарников до профилей
4. Интерфейс и базовые команды: Синтаксис, флаги и опции
5. Работа с EVTX: Импорт, теневые копии и обход блокировок
6. Sigma Rules: Сердце детектирования угроз в Hayabusa
7. Профили анализа: От быстрого триажа до глубокого Threat Hunting
8. Практика: Разбор инцидента с компрометацией учетной записи
9. Продвинутые техники: Интеграция с Takajo и визуализация
10. Оптимизация производительности: Обработка терабайтов логов
11. Ложные срабатывания и тюнинг: Как не утонуть в шуме
12. Экспорт результатов: JSON, CSV и интеграция с SIEM/SOAR
13. FAQ: 12 горячих вопросов по Hayabusa и анализу логов
14. Чек-лист: Развернуть Hayabusa и найти следы хакера за вечер
15. Заключение
1. Введение: Почему ручной разбор EVTX — это путь в никуда
Ситуация классическая: пятница, 17:00, прилетает инцидент от SOC или, что хуже, от бизнеса — «что-то тормозит, возможно, нас взломали». У вас есть доступ к серверу. Вам нужно понять, что происходило в сети за последние 72 часа. Вы открываете Event Viewer. Он зависает. Вы выгружаете EVTX-файлы. Они весят 2 ГБ. Вы пытаетесь открыть их в Event Log Explorer. Интерфейс отрисовывает события по одному. Вы начинаете фильтровать по Event ID 4624, потом 4688, потом 4648. Время идет, а вы всё ещё не поняли, был ли это lateral movement или просто админ обновлял патчи.В цифровой криминалистике (DFIR) и Incident Response (IR) время — это единственный невосполнимый ресурс. Облачные SIEM (Splunk, Elastic) прекрасны, но они требуют времени на нормализацию данных, написание запросов и, главное, они требуют, чтобы агент был установлен до инцидента. Когда сервер уже горит, а агент сбора логов не был настроен, у вас остается только сырой дамп файлов `C:\Windows\System32\winevt\Logs`.
Именно здесь на сцену выходит Hayabusa. Это не просто «еще один парсер». Это консольный инструмент, написанный на Rust, который превращает гигабайты нечитаемых бинарных EVTX-файлов в структурированные CSV или JSON таймлайны за считанные минуты. Но главная магия Hayabusa не в скорости парсинга. Его сердце — это встроенный движок Sigma-правил. Он позволяет сканировать логи на наличие известных тактик, техник и процедур (TTP) MITRE ATT&CK прямо на лету.
В этом руководстве мы разберем Hayabusa от установки до продвинутых техник интеграции с Takajo. Мы не будем лить воду. Только хардкорный DFIR, реальные команды, разбор Event ID и практика поиска следов злоумышленника. Если вы аналитик ИБ, SOC-инженер или IR-специалист, этот гайд сэкономит вам сотни часов рутины.
> 💡 Примечание автора: Все примеры и команды в статье протестированы на актуальных версиях Hayabusa (v2.x) и Windows Server 2019/2022. Инструмент кроссплатформенный, но фокус статьи — именно на анализе Windows-среды.
2. Что такое Hayabusa: Архитектура, Rust и философия DFIR
Hayabusa (в честь японского сокола-сапсана, самого быстрого животного в мире) был создан Ямато Исеки и командой Yamato Security. Изначально это был пет-проект, который перерос в стандарт индустрии для быстрого триажа.Почему Rust? Парсинг EVTX — это работа с бинарными файлами сложной структуры. EVTX состоит из заголовков, чанков (chunks) и записей событий, которые сериализованы в XML, но упакованы в бинарный формат. Парсинг на Python (как это делает старый добрый `python-evtx`) работает, но он медленный. Rust дает скорость C++, но с безопасностью памяти. Hayabusa парсит файлы в многопоточном режиме, используя все ядра вашего процессора. Дамп логов контроллера домена на 10 ГБ обрабатывается за время, которое вы потратите на приготовление кофе.
Отличия от аналогов
На рынке есть несколько инструментов для работы с EVTX. Давайте сразу расставим точки над `i`, чтобы вы понимали, где место Hayabusa.| Инструмент | Язык / Основа | Главная фишка | Минусы |
|---|---|---|---|
| Event Viewer | C++ (Windows) | Встроен в ОС | Неудобный поиск, нет экспорта в SIEM, медленный |
| Event Log Explorer | Проприетарный | Отличный GUI, быстрые фильтры | Платный, нет встроенного детектирования угроз |
| Chainsaw | Rust | Быстрый парсинг, поддержка Sigma | Меньше встроенных правил, сложнее экспорт |
| Hayabusa | Rust | Sigma-детектирование, Takajo, скорость | Консольный интерфейс (нет GUI из коробки) |
Hayabusa не пытается заменить GUI-инструменты для глубокого ручного разбора одного конкретного события. Его задача — массовый скрининг и триаж. Вы скармливаете ему 50 ГБ логов с десяти серверов, и через 5 минут получаете CSV-файл, в котором подсвечены только критические алерты: попытки дампа LSASS, очистка логов, создание теневых копий VSS для кражи хешей NTDS.dit.
> 🔴 Главная ошибка новичков: Пытаться использовать Hayabusa как замену полноценному SIEM для мониторинга в реальном времени. Hayabusa — это инструмент для ретроспективного анализа (post-mortem) или анализа дампов. Для реалтайма используйте его в связке с скриптами, которые периодически скармливают новые логи парсеру, или интегрируйте через JSON в Elastic/Splunk.
3. Установка и первичная настройка: От бинарников до профилей
Hayabusa не требует сложной установки с зависимостями, если вы используете скомпилированные бинарники. Но для DFIR-задач мы рекомендуем собирать из исходников или использовать Git-версию, чтобы всегда иметь доступ к последним обновлениям Sigma-правил.Вариант 1: Готовые бинарники (Рекомендуется для быстрого старта)
1. Перейдите в официальный репозиторий Yamato Security.2. Скачайте архив для вашей ОС (Windows, Linux, macOS).
3. Распакуйте в рабочую директорию. Например, `C:\DFIR\Tools\Hayabusa`.
4. Внутри вы увидите исполняемый файл `hayabusa.exe` и папку `config`.
Вариант 2: Сборка из исходников (Для Linux/macOS и энтузиастов)
Вам понадобится Rust toolchain.bash
<h2 id="ustanovka-rust-esli-esche-ne-ustanovlen">Установка Rust (если еще не установлен)</h2>
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env
<h2 id="klonirovanie-repozitoriya">Клонирование репозитория</h2>
git clone https://github.com/Yamato-Security/hayabusa.git
cd hayabusa
<h2 id="kompilyatsiya-v-rezhime-reliza-optimizirovannyy-binarnik">Компиляция в режиме релиза (оптимизированный бинарник)</h2>
cargo build --release
Скомпилированный файл будет лежать в `target/release/hayabusa`.
Загрузка Sigma-правил
Сила Hayabusa — в правилах. По умолчанию в релизе идет базовый набор, но для полноценной работы нужно подтянуть актуальные правила из репозитория SigmaHQ.Внутри папки Hayabusa выполните:
bash
<h2 id="dlya-windows">Для Windows</h2>
hayabusa.exe update-rules
<h2 id="dlya-linux-macos">Для Linux/macOS</h2>
./hayabusa update-rules
Эта команда скачает последние правила Sigma в папку `rules`. Обновляйте их перед каждым серьезным инцидентом. Хакеры меняют TTP каждый день, ваши правила должны быть свежими.
Структура конфигурации
В папке `config` лежат важные файлы:- `default_profile.txt` — определяет, какие поля выводить в CSV/JSON по умолчанию.
- `channel_eid_info.txt` — маппинг Event ID на их описания (чтобы в выводе было не просто `4624`, а `An account was successfully logged on`).
- `exclude_rules.txt` — сюда можно добавлять ID правил Sigma, которые вы хотите игнорировать (например, специфичные ложные срабатывания вашей среды).
4. Интерфейс и базовые команды: Синтаксис, флаги и опции
Hayabusa работает исключительно через командную строку. Интерфейс спартанский, но функциональный. Давайте разберем базовый синтаксис.Общая структура команды:
`hayabusa [флаги] `
Основные команды (подкоманды)
Начиная с версии 2.x, Hayabusa разделил функционал на подкоманды:- `csv-timeline` — генерирует таймлайн в формате CSV (удобно для Excel, Timesketch).
- `json-timeline` — генерирует таймлайн в JSON (удобно для Takajo, SIEM, Elasticsearch).
- `logon-summary` — быстрая сводка по успешным и неуспешным входам в систему.
- `eid-metrics` — подсчет количества событий по каждому Event ID (помогает понять, что вообще происходило, если логов слишком много).
- `list-profiles` — показать доступные профили вывода.
- `update-rules` — обновить Sigma-правила.
Ключевые флаги
Флаги — это ваши инструменты тонкой настройки. Запомните самые важные:- `-f, --file ` — путь к одному EVTX файлу.
- `-d, --directory ` — путь к директории с EVTX файлами (рекурсивный обход).
- `-o, --output ` — сохранить результат в файл. Без этого флага вывод пойдет в stdout (в консоль).
- `-p, --profile ` — выбрать профиль вывода (об этом подробнее в разделе 7).
- `-t, --threads ` — количество потоков. По умолчанию используется максимум. На слабых ноутбуках лучше ограничить, чтобы система не зависла.
- `--no-color` — отключить цветной вывод в консоль (полезно при перенаправлении вывода в файл).
- `-q, --quiet` — не выводить стартовый баннер и прогресс-бары (для скриптов).
Пример базового запуска
Допустим, вы смонтировали образ диска подозреваемого сервера как `E:\`. Логи лежат в `E:\Windows\System32\winevt\Logs`.bash
hayabusa.exe csv-timeline -d "E:\Windows\System32\winevt\Logs" -o C:\DFIR\Results\server_timeline.csv -p verbose
Эта команда пройдет по всем файлам в директории, применит все Sigma-правила и сохранит подробный таймлайн в CSV.
> 💡 Совет от ForensicAnvil: Всегда используйте абсолютные пути. При работе с монтированными образами или сетевыми шариками относительные пути могут сбить с толку парсер, и вы получите пустой вывод, думая, что логов нет.
5. Работа с EVTX: Импорт, теневые копии и обход блокировок
Файлы EVTX (Windows Event Log) — это святой грааль для DFIR-специалиста. В них записано всё: кто заходил, что запускал, какие файлы трогал. Но есть нюансы работы с ними в полевых условиях.Где лежат логи
Стандартный путь: `C:\Windows\System32\winevt\Logs`.Самые важные для нас файлы:
- `Security.evtx` — аудит входа, доступа к объектам, изменения привилегий. (Требует включения аудита в Group Policy).
- `System.evtx` — запуск/остановка служб, драйверов, ошибки ядра.
- `Microsoft-Windows-Sysmon/Operational.evtx` — если установлен Sysmon, это кладезь данных о процессах, сетевых соединениях и изменениях реестра.
- `Microsoft-Windows-PowerShell/Operational.evtx` — логи выполнения скриптов (включая Script Block Logging).
- `Microsoft-Windows-WMI-Activity/Operational.evtx` — WMI-атаки.
Проблема заблокированных файлов
Если вы пытаетесь скопировать EVTX файлы с работающей системы, вы столкнетесь с ошибкой «Файл используется другим процессом». Windows блокирует файлы логов для записи.Решение 1: Теневые копии (Volume Shadow Copy)
Хакеры часто очищают логи (Event ID 1102), чтобы замести следы. Но они забывают про теневые копии.
powershell
<h2 id="sozdanie-tenevoy-kopii-diska-c">Создание теневой копии диска C:</h2>
vssadmin create shadow /for=C:
<h2 id="kopirovanie-logov-iz-tenevoy-kopii">Копирование логов из теневой копии</h2>
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\winevt\Logs\Security.evtx C:\DFIR\Extracted\
Примечание: Для создания VSS нужны права администратора. Если хакер их получил, он мог удалить и VSS. Но проверьте всегда.
Решение 2: Kape / FGET / WinPMEM
Используйте специализированные утилиты для сбора артефактов, которые работают на уровне ядра или используют API для обхода блокировок. KAPE (Kroll Artifact Parser and Extractor) отлично умеет собирать EVTX на лету.
Решение 3: Экспорт через Event Viewer
Если у вас есть RDP-доступ и права, просто откройте Event Viewer, найдите нужный лог, нажмите «Сохранить все события как...». Это создаст корректный EVTX или XML файл.
Обработка поврежденных логов
EVTX файлы могут повредиться при некорректном выключении сервера или при попытке хакера обнулить файл (записать нули в начало). Hayabusa устойчив к повреждениям. Он читает файл чанками. Если чанк поврежден, он выведет предупреждение в stderr и продолжит парсить остальные. Вы не потеряете данные из уцелевших частей файла.6. Sigma Rules: Сердце детектирования угроз в Hayabusa
Sigma — это открытый стандарт для написания правил обнаружения угроз в логах. Идея проста: вы описываете что искать (например, "запуск PowerShell с закодированной командой"), а не как это реализовать в конкретном SIEM. Hayabusa транслирует Sigma-правила в свой внутренний движок на лету.Как это работает внутри
Когда вы запускаете `hayabusa csv-timeline`, парсер читает каждое событие из EVTX и прогоняет его через движок Sigma. Если событие матчится с правилом, Hayabusa добавляет к нему алерт.В выводе вы увидите дополнительные поля:
- `RuleTitle` — название правила (например, "Suspicious PowerShell Command Line").
- `RuleLevel` — уровень критичности (critical, high, medium, low, informational).
- `MitreTAG` — теги MITRE ATT&CK (например, `T1059.001` - PowerShell).
Управление правилами
Все правила лежат в папке `rules`. Они сгруппированы по папкам:- `sigma/builtin` — правила, использующие стандартные Windows Event ID.
- `sigma/sysmon` — правила, требующие Sysmon.
- `hayabusa` — собственные правила от команды Yamato Security (часто более оптимизированные).
Фильтрация правил при запуске
Не всегда нужно запускать все 3000+ правил. Это может замедлить работу и завалить вас ложными срабатываниями. Hayabusa позволяет фильтровать правила на лету:bash
<h2 id="zapustit-tolko-kriticheskie-i-vysokie-pravila">Запустить только критические и высокие правила</h2>
hayabusa.exe csv-timeline -d ./logs -o out.csv --level critical,high
<h2 id="zapustit-tolko-pravila-dlya-sysmon">Запустить только правила для Sysmon</h2>
hayabusa.exe csv-timeline -d ./logs -o out.csv --include-tags sysmon
<h2 id="isklyuchit-konkretnoe-pravilo-po-id">Исключить конкретное правило по ID</h2>
hayabusa.exe csv-timeline -d ./logs -o out.csv --exclude-rule 4f3ee98d-6c29-4c8c-b763-23aef26a91bd
Написание своих правил
Если у вас в компании есть специфичный софт, который генерирует подозрительные события, вы можете написать свое правило Sigma.Формат YAML. Пример простого правила на очистку логов:
yaml
title: Windows Event Log Cleared
id: a62b3710-9c48-436c-9e25-61d5e351e34b
status: stable
description: Detects clearing of Windows Event Logs
author: ForensicAnvil
date: 2024/05/20
logsource:
product: windows
service: security
detection:
selection:
EventID: 1102
condition: selection
level: high
tags:
- attack.defense_evasion
- attack.t1070.001
Сохраните этот файл в `rules/hayabusa/custom/`, и при следующем запуске Hayabusa его подхватит.
> 🔴 Важно: Никогда не редактируйте оригинальные файлы в папке `rules/sigma/`. При следующем `update-rules` ваши изменения затрутся. Всегда создавайте папку `custom` и кладите правила туда.
7. Профили анализа: От быстрого триажа до глубокого Threat Hunting
Вывод Hayabusa может быть очень детальным. Но если вы выгрузите все возможные поля для каждого события, ваш CSV раздуется до неприличных размеров, а время парсинга увеличится. Профили (profiles) решают эту проблему.Профиль — это набор полей, которые Hayabusa будет извлекать и выводить. Они настраиваются в файле `config/default_profile.txt`.
Встроенные профили
1. minimal- Что внутри: Только время, Event ID, название правила и уровень.
- Когда использовать: Когда нужно быстро прикинуть объем алертов и понять, есть ли вообще что-то критическое. Идеально для первичного скрининга сотен серверов.
2. standard (по умолчанию)
- Что внутри: Время, Event ID, Computer, Channel, RuleTitle, RuleLevel, MitreTAG, плюс базовые поля из самого события (например, SubjectUserName для 4624).
- Когда использовать: Золотой стандарт для повседневного триажа. Баланс между информативностью и размером файла.
3. verbose
- Что внутри: Всё из standard + все доступные XML-поля из события.
- Когда использовать: Глубокий разбор конкретного инцидента. Когда вам нужно видеть каждый аргумент командной строки, каждый SID и каждый IP-адрес.
4. super-verbose
- Что внутри: Абсолютно всё, включая технические поля самого парсера (например, `ExtraFieldInfo`, если в событии есть нестандартные XML-теги).
- Когда использовать: Только если вы пишете собственные Sigma-правила и вам нужно понять структуру редкого события.
Как сменить профиль
Используйте флаг `-p` или `--profile`:bash
hayabusa.exe csv-timeline -d ./logs -o detailed.csv -p verbose
Кастомизация профилей
Вы можете создать свой профиль. Откройте `config/default_profile.txt`. Формат простой:ini
[my_custom_profile]
Timestamp = %Timestamp%
Computer = %Computer%
EventID = %EventID%
RuleTitle = %RuleTitle%
<h2 id="dobavlyaem-spetsifichnoe-pole-iz-xml">Добавляем специфичное поле из XML</h2>
TargetFileName = %Event.EventData.Data[Name='TargetFileName']%
Затем запускайте: `hayabusa csv-timeline ... -p my_custom_profile`.
> 💡 Лайфхак: Если вы готовите отчет для руководства, используйте профиль `minimal` или `standard`. Если готовите доказательную базу для суда или глубокий технический отчет — `verbose`. Никогда не отправляйте клиенту `super-verbose` без крайней необходимости — они утонут в мусоре.
8. Практика: Разбор инцидента с компрометацией учетной записи
Теория без практики мертва. Давайте разберем классический сценарий: хакер получил доступ к серверу, повысил привилегии и попытался украсть хеши. Посмотрим, как это выглядит в логах и как Hayabusa помогает это найти.Сценарий атаки
1. Злоумышленник использует Brute-Force или украденные учетные данные для RDP-входа.2. Отключает UAC (User Account Control) через реестр.
3. Запускает Mimikatz для дампа LSASS.
4. Пытается очистить логи.
Шаг 1: Быстрый триаж (Поиск критических алертов)
Мы не знаем, что именно произошло. Запускаем Hayabusa с фильтром только по критическим и высоким уровням.bash
hayabusa.exe csv-timeline -d "E:\Logs" -o triage.csv --level critical,high -p standard
Открываем `triage.csv` в Excel или O365. Сортируем по `RuleLevel`.
Сразу видим алерты:
- `[CRITICAL] Mimikatz Command Line` (Event ID 4688)
- `[HIGH] Suspicious Process Access to LSASS` (Event ID 10 / Sysmon или 4656 / Built-in)
- `[HIGH] Windows Event Log Cleared` (Event ID 1102)
Шаг 2: Восстановление таймлайна (Chronological Analysis)
Теперь нам нужно понять последовательность действий. Хакер действовал быстро, но мы видим, что Event ID 1102 (очистка логов) сработал до некоторых событий дампа. Это значит, что часть логов Security удалена. Но хакер забыл, что Sysmon и PowerShell логи пишутся в другие файлы!Запускаем полный таймлайн с фильтром по времени инцидента (допустим, с 14:00 до 15:00).
bash
hayabusa.exe csv-timeline -d "E:\Logs" -o full_timeline.csv -p verbose --timeline-start "2024-05-20T14:00:00Z" --timeline-end "2024-05-20T15:00:00Z"
Шаг 3: Анализ конкретных Event ID
В полученном CSV ищем ключевые события:Event ID 4624 (Logon Type 10)
Мы видим вход по RDP (Logon Type 10) с IP `192.168.1.50` под учеткой `admin_local`.
Действие: Блокируем IP `192.168.1.50` на фаерволе. Сбрасываем пароль `admin_local`.
Event ID 4688 (Process Creation) с Command Line
В логах Sysmon/Security видим запуск `cmd.exe` с аргументом `reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f`.
Действие: Это отключение UAC. Хакер готовится к выполнению действий от имени SYSTEM.
Event ID 10 (Sysmon) / 4656 (Security) - Process Access
Видим, что процесс `mimikatz.exe` (или процесс с переименованным бинарником, но с хешем, совпадающим с известными сигнатурами) запросил доступ `0x1010` к процессу `lsass.exe`.
Действие: Это 100% дамп памяти LSASS. Все учетные данные, которые были в памяти на момент атаки, скомпрометированы. Требуется полная ротация паролей и Kerberos-билетов (Double Kerberos reset).
Шаг 4: Использование logon-summary
Чтобы быстро понять, не создал ли хакер новую учетную запись или не заходил ли под другой, используем встроенную команду:bash
hayabusa.exe logon-summary -d "E:\Logs"
Вывод покажет красивую таблицу:
successful
Logons:
admin_local : 15 (Source IPs: 192.168.1.50, 10.0.0.5)
SYSTEM : 450
new_admin_hkr : 2 (Source IP: 192.168.1.50) <-- ВНИМАНИЕ!
Мы видим, что с того же IP заходили под `new_admin_hkr`. Хакер создал бэкдор-аккаунт.
> 💡 Вывод из практики: Hayabusa не делает расследование за вас. Он дает вам структурированные данные и подсвечивает аномалии. Решение о том, как интерпретировать `0x1010` доступ к LSASS, принимает аналитик. Но без Hayabusa вы бы искали эту иголку в стоге сена три дня.
9. Продвинутые техники: Интеграция с Takajo и визуализация
CSV и JSON — это хорошо, но когда таймлайн содержит 500,000 событий, Excel начинает тормозить, а grep в консоли утомляет. Команда Yamato Security создала инструмент-компаньон: Takajo (название в честь сокола).Что такое Takajo?
Takajo — это консольный инструмент для пост-обработки JSON-вывода Hayabusa. Если Hayabusa — это парсер и детектор, то Takajo — это аналитик и визуализатор. Он читает `json-timeline` от Hayabusa и позволяет делать с ним сложные вещи.Установка Takajo
Takajo тоже написан на Rust. Установка аналогична:bash
git clone https://github.com/Yamato-Security/takajo.git
cd takajo
cargo build --release
Ключевые команды Takajo
Предположим, вы сохранили вывод Hayabusa:`hayabusa.exe json-timeline -d ./logs -o timeline.json -p verbose`
Теперь запускаем Takajo:
1. Сортировка и фильтрация
bash
takajo sort-timeline -t timeline.json -o sorted.json
Takajo отсортирует события по времени, даже если в исходных логах были рассинхронизации часов (он пытается нормализовать время).
2. Извлечение уникальных IP-адресов и хешей
bash
takajo extract-ip -t sorted.json
takajo extract-hash -t sorted.json
Отлично подходит для быстрого сбора индикаторов компрометации (IoC) для загрузки в Threat Intelligence платформу.
3. Анализ латерального движения (Lateral Movement)
bash
takajo list-logons -t sorted.json
Покажет сводную таблицу: кто, откуда и куда заходил. Помогает быстро нарисовать граф перемещений хакера по сети.
4. Интеграция с Timesketch / Elasticsearch
JSON от Hayabusa уже имеет хорошую структуру, но Takajo может дополнительно обогатить его или конвертировать в форматы, которые легче грузятся в специфичные SIEM.
Визуализация с помощью Hayabusa GUI (сторонние решения)
Официального GUI у Hayabusa нет, и это осознанное решение (консоль = автоматизация). Но вы можете использовать:- Timesketch: Загружаете CSV от Hayabusa. Получаете веб-интерфейс с таймлайном, графами и возможностью аннотаций.
- Elasticsearch + Kibana: Скармливаете JSON через Logstash/Filebeat. Строите дашборды.
- Jupyter Notebooks: Загружаете CSV через pandas, строите графики с помощью matplotlib/seaborn.
> 🔴 Предупреждение: При загрузке данных в Timesketch или Elastic, убедитесь, что вы правильно маппите временные зоны. Hayabusa по умолчанию использует UTC. Если ваши серверы в разных часовых поясах, а вы не сконвертировали время, таймлайн будет нелогичным. Используйте флаг `--UTC` в Hayabusa или настраивайте парсинг времени в SIEM.
10. Оптимизация производительности: Обработка терабайтов логов
В корпоративной среде вам могут принести не 2 ГБ логов, а 500 ГБ с контроллеров домена, прокси-серверов и файловых помоек. Как не убить свой ноутбук и получить результат до конца смены?1. Железо имеет значение
- CPU: Hayabusa отлично масштабируется на многоядерные процессоры. 8 ядер — минимум, 16+ — комфортно.- RAM: Парсер хранит загруженные Sigma-правила в памяти. Для 3000 правил нужно около 1-2 ГБ RAM. Сами логи читаются потоково. 16 ГБ RAM достаточно для 95% задач.
- Диск: ТОЛЬКО SSD. Чтение EVTX — это случайное чтение (random read) мелких блоков. На HDD парсинг 50 ГБ займет часы. На NVMe SSD — минуты. Если анализируете логи с медленного сетевого диска (SMB), сначала скопируйте их на локальный NVMe.
2. Управление потоками (Threads)
По умолчанию Hayabusa использует все логические ядра. Если вы работаете на ноутбуке и параллельно открыты браузер, Jira и Teams, парсер может вызвать фриз системы.Ограничьте потоки:
bash
hayabusa.exe csv-timeline -d ./logs -o out.csv -t 4
3. Фильтрация на входе
Не парсите всё подряд. Если вы расследуете инцидент, связанный с PowerShell, нет смысла гонять через парсер логи `Microsoft-Windows-PrintService/Operational`.Используйте флаг `--include-channels`:
bash
hayabusa.exe csv-timeline -d ./logs -o out.csv --include-channels "Security,Microsoft-Windows-PowerShell/Operational,Microsoft-Windows-Sysmon/Operational"
Это ускорит работу в разы, так как парсер будет просто пропускать ненужные файлы на этапе открытия.
4. Разбиение больших файлов
Если у вас есть один гигантский EVTX файл (например, Security.evtx на 4 ГБ, что бывает на очень нагруженных серверах), используйте утилиты для разбиения (например, `EVTXtract` или скрипты на Python), чтобы разбить его на части по 500 МБ. Hayabusa может параллельно обрабатывать несколько файлов, но один огромный файл будет обрабатываться в один поток.11. Ложные срабатывания и тюнинг: Как не утонуть в шуме
Sigma-правила пишутся сообществом. Сообщество стремится к максимальной чувствительности (чтобы не пропустить хакера). В результате вы получаете сотни алертов уровня `medium` и `low`, которые в вашей среде являются нормой.Пример проблемы
Правило: "Suspicious Process Creation".Срабатывание: Администратор запустил `powershell.exe -enc ` для легитимного скрипта развертывания ПО.
Результат: 500 алертов в день. Аналитик привыкает к шуму и пропускает реальную атаку.
Стратегии тюнинга
1. Исключение на уровне Hayabusa (Глобально)Если правило полностью нерелевантно для вашей инфраструктуры (например, правило для специфичного промышленного софта, которого у вас нет), добавьте его ID в `config/exclude_rules.txt`.
text
# config/exclude_rules.txt
12345678-1234-1234-1234-123456789abc
2. Исключение на уровне Sigma-правил (Локально)
Скачайте правило из `rules/sigma/...` в `rules/hayabusa/custom/`. Отредактируйте секцию `condition` или добавьте `filter`.
yaml
detection:
selection:
EventID: 4688
CommandLine|contains: 'Invoke-Mimikatz'
filter_legit_admin:
User|contains: 'svc_deploy_bot'
condition: selection and not filter_legit_admin
3. Повышение порога срабатывания
Если правило срабатывает на единичное событие, но в вашей норме это событие происходит 10 раз в минуту, измените логику правила, чтобы оно срабатывало только при превышении порога (хотя Hayabusa пока не поддерживает агрегацию/статистику в реальном времени так же хорошо, как Sigma в SIEM, но можно использовать внешние скрипты).
4. Анализ ложных срабатываний через eid-metrics
Перед тем как тюнить правила, запустите:
bash
hayabusa.exe eid-metrics -d ./logs
Посмотрите, какие Event ID встречаются чаще всего. Если 90% алертов генерируются одним правилом на одно специфичное событие — это ваш кандидат на исключение.
> 💡 Золотое правило DFIR: Лучше пропустить одно событие низкого уровня, чем получить 10,000 ложных срабатываний, которые заставят аналитика отключить мониторинг. Тюнинг правил — это 50% работы SOC.
12. Экспорт результатов: JSON, CSV и интеграция с SIEM/SOAR
Результаты работы Hayabusa редко остаются только на ноутбуке аналитика. Их нужно интегрировать в системы управления инцидентами (IRP), SIEM или отправлять клиенту.Формат CSV
- Плюсы: Открывается в Excel, LibreOffice. Легко читается людьми. Поддерживается Timesketch.- Минусы: Проблемы с экранированием кавычек и переносов строк в полях (например, если в Command Line были кавычки). Теряется иерархия данных.
- Как использовать: Для быстрых отчетов, для загрузки в Timesketch.
- Совет: При открытии в Excel используйте «Текст по столбцам» с разделителем-запятой и обязательно указывайте UTF-8 кодировку, иначе кириллица превратится в кракозябры.
Формат JSON (JSONL)
Hayabusa выводит JSON в формате JSON Lines (каждая строка — отдельный JSON-объект).- Плюсы: Идеально для машинной обработки. Сохраняет все вложенные поля. Нет проблем с экранированием.
- Минусы: Человек не может читать это глазами.
- Как использовать: Для загрузки в Elasticsearch, Splunk, для обработки через Takajo, для передачи в SOAR-системы (TheHive, Cortex).
Интеграция с Elasticsearch / Elastic SIEM
1. Запускаем Hayabusa: `hayabusa json-timeline -d ./logs -o timeline.jsonl -p verbose`.2. Используем Logstash или Filebeat с конфигом для парсинга JSON.
3. В Elastic создаем Index Pattern.
4. Строим дашборды: количество алертов по времени, топ критических событий, карта MITRE ATT&CK (на основе поля `MitreTAG`).
Интеграция с Splunk
1. Запускаем CSV или JSON.2. В Splunk: `Settings -> Add Data -> Upload`.
3. Если CSV: указываете разделитель, экранирование.
4. Если JSON: Splunk сам распознает JSONL.
5. Пишите SPL-запросы: `index=hayabusa RuleLevel=critical | stats count by RuleTitle`.
Интеграция с TheHive / Cortex
Экспортируйте JSON. Напишите простой Python-скрипт (или используйте готовые интеграции от сообщества), который читает JSONL, фильтрует только `critical` и `high`, и через API TheHive создает тикеты инцидентов с прикрепленными артефактами (IP, хеши, имена процессов).13. FAQ: 12 горячих вопросов по Hayabusa и анализу логов
Q 01: Hayabusa находит все угрозы или только известные?
A: Только известные. Hayabusa работает на основе сигнатур (Sigma-правил). Если хакер использует новую, неизвестную технику (Zero-day или уникальную TTP, для которой еще не написали правило), Hayabusa ее не увидит. Для поиска неизвестного нужен поведенческий анализ и Threat Hunting руками.
Q 02: Можно ли анализировать логи Linux с помощью Hayabusa?
A: Нет. Hayabusa заточен исключительно под формат EVTX (Windows Event Logs). Для Linux используйте другие инструменты (например, парсеры для syslog, auditd, или тот же Chainsaw, который поддерживает больше форматов).
Q 03: Что делать, если в логах нет Sysmon, а правила требуют его?
A: Hayabusa автоматически пропустит правила, требующие Sysmon, если в логах нет канала `Microsoft-Windows-Sysmon/Operational`. Он будет использовать правила для стандартных Windows Event ID (builtin). Но помните: без Sysmon вы слепы к многим процессным и сетевым событиям. Установите Sysmon на все критичные серверы.
Q 04: Как понять, что хакер подменил системное время перед атакой?
A: Hayabusa выводит время из самого события. Если хакер сдвинул время на сервере, таймлайн будет "скакать". Обратите внимание на Event ID 4616 (System time changed). Если он есть в логах — доверяйте только времени из сетевых логов (например, NTP-синхронизации) или времени создания файлов на диске.
Q 05: Почему в CSV файле некоторые поля пустые?
A: Потому что этих полей не было в оригинальном XML-событии. Например, Event ID 4624 (вход) имеет разные "Logon Types". При Type 3 (Network) поле `ProcessName` часто пустое, так как вход произошел по сети, а не через запуск локального процесса. Это нормально.
Q 06: Можно ли использовать Hayabusa в коммерческих продуктах?
A: Да. Hayabusa распространяется под лицензией GNU General Public License v3.0 (GPLv3). Вы можете использовать его в коммерческих расследованиях, но если вы модифицируете исходный код и распространяете продукт, вы обязаны открыть исходники вашего модифицированного кода. Для внутреннего использования в компании ограничений нет.
Q 07: Как анализировать логи, если хакер использовал утилиту для затирания (например, Event Log Eraser)?
A: Утилиты для затирания часто не удаляют записи физически, а перезаписывают их нулями или мусором, оставляя структуру чанков. Hayabusa может выдать ошибки парсинга для поврежденных чанков. Используйте `EVTXtract` (инструмент от Willi Ballenthin) — он вырезает уцелевшие записи из поврежденных файлов на уровне сырых байтов, а затем скармливайте результат Hayabusa.
Q 08: Поддерживает ли Hayabusa анализ журналов IIS или DHCP?
A: Нет. IIS пишет в текстовые файлы (W3C) или бинарные ETL. DHCP пишет в текстовые файлы или базу данных. Hayabusa парсит только EVTX. Для IIS используйте LogParser или парсеры для SIEM.
Q 09: Как часто нужно обновлять правила Sigma?
A: Перед каждым серьезным расследованием. В идеале — раз в неделю. Команда SigmaHQ и Yamato Security выпускают обновления регулярно. Хакеры адаптируются, правила устаревают.
Q 10: Можно ли запустить Hayabusa прямо на зараженном сервере?
A: Можно, но НЕ РЕКОМЕНДУЕТСЯ. Запуск любого стороннего бинарника на скомпрометированной системе может триггернуть антивирус хакера, затереть следы в памяти или быть обнаруженным. Всегда копируйте логи (или делайте образ) и анализируйте их в изолированной среде (forensic workstation).
Q 11: Что такое "Channel" в выводе Hayabusa?
A: Channel — это имя журнала событий Windows (например, `Security`, `System`, `Application`, `Microsoft-Windows-Sysmon/Operational`). Это аналог "источника" или "лог-файла".
Q 12: Hayabusa не видит правила, которые я скачал. В чем проблема?
A: Убедитесь, что правила лежат в правильной директории (`rules/`). Проверьте синтаксис YAML (часто ошибка в отступах). Запустите с флагом `--debug`, чтобы увидеть, какие правила парсер успешно загрузил, а какие отбросил с ошибкой.
14. Чек-лист: Развернуть Hayabusa и найти следы хакера за один вечер
Используйте этот чек-лист, когда прилетает инцидент и нужно действовать быстро и методично.Этап 1: Подготовка и сбор (30 минут)
- [ ] Скачать актуальный релиз Hayabusa и Takajo с GitHub.
- [ ] Выполнить `hayabusa update-rules` для загрузки свежих Sigma-правил.
- [ ] Получить доступ к серверу (физический, RDP, или доступ к бэкапу/образу).
- [ ] Скопировать директорию `C:\Windows\System32\winevt\Logs` на свою forensic-машину. (Не забудьте про теневые копии, если подозреваете очистку логов!).
Этап 2: Первичный триаж (15 минут)
- [ ] Запустить `hayabusa eid-metrics -d ./logs`, чтобы понять общий объем и типы событий.
- [ ] Запустить `hayabusa logon-summary -d ./logs`, чтобы выявить аномальные входы и новые учетки.
- [ ] Запустить `hayabusa csv-timeline -d ./logs -o triage.csv --level critical,high -p standard`.
- [ ] Открыть `triage.csv`, отсортировать по критичности. Есть ли явные следы Mimikatz, очистки логов, подозрительных PowerShell-скриптов?
Этап 3: Глубокий анализ (1-2 часа)
- [ ] Если есть алерты, запустить полный таймлайн: `hayabusa json-timeline -d ./logs -o full.json -p verbose`.
- [ ] Передать JSON в Takajo: `takajo sort-timeline -t full.json -o sorted.json`.
- [ ] Извлечь IoC: `takajo extract-ip -t sorted.json`, `takajo extract-hash -t sorted.json`.
- [ ] Вручную пройтись по таймлайну вокруг времени срабатывания критических алертов. Искать смежные события (что было за 5 минут до и 5 минут после).
Этап 4: Документирование и реагирование (30 минут)
- [ ] Сохранить все CSV/JSON файлы, списки IoC, скриншоты вывода консоли.
- [ ] Составить краткий отчет: вектор атаки, затронутые системы, скомпрометированные учетные записи.
- [ ] Передать IoC (IP, хеши) сетевой команде для блокировки на периметре.
- [ ] Передать список скомпрометированных учеток команде IAM для принудительного сброса паролей и отзыва сессий.
> 🤖 Финальная мысль от ForensicAnvil: Инструменты — это только 20% успеха. Остальные 80% — это ваше понимание того, как работает Windows, как мыслят хакеры и как правильно задавать вопросы логам. Hayabusa дает вам фонарик в темной комнате. Но идти по этой комнате и принимать решения придется вам.
