mcp-hayabusa
This MCP server wraps the Hayabusa Windows event log forensic tool, enabling LLM clients to analyze .evtx files directly. Capabilities include:
Forensic analysis: Run detection timelines (CSV/JSON), keyword/regex search, extract and decode base64 strings, extract pivot keywords (users, IPs, processes, etc.), summarize logon events, and detect critical systems (domain controllers, file servers).
Metrics and summarization: Count events by Event ID or computer name, view log channel metadata (channels, event count, date range), and produce combined high-level first-pass scans (
scan_evtx).Rule and detection management: Get Hayabusa version and output profiles; update, list, and filter Sigma detection rules; analyze ATT&CK detection coverage; and suggest relevant rules by free-text query or ATT&CK technique.
Read-only resources: Browse rule catalogs by category, view full rule details by Sigma ID, and explore ATT&CK coverage by technique or tactic.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-hayabusa Generate a CSV timeline from the system.evtx file in C:\logs"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-hayabusa
See CHANGELOG.md for release notes.
An MCP (Model Context Protocol) server that wraps Hayabusa, the Rust-based Windows event log (.evtx) fast forensic timeline generator and threat hunting tool.
It shells out to a local hayabusa binary and exposes its analysis capabilities as MCP tools that an LLM client (Claude Desktop, Claude Code, etc.) can call directly against .evtx files.
Prerequisites
Python >= 3.10
The hayabusa binary, either on
PATHor pointed to via theHAYABUSA_BINenvironment variable.
Related MCP server: mcp-hayabusa
Install
pip install -e ".[dev]"Run
mcp-hayabusaor
python -m mcp_hayabusaThe server communicates over stdio, so it's meant to be launched by an MCP client rather than run interactively.
Example Claude Desktop / Claude Code config
{
"mcpServers": {
"hayabusa": {
"command": "mcp-hayabusa",
"env": {
"HAYABUSA_BIN": "C:\\tools\\hayabusa\\hayabusa.exe"
}
}
}
}Tools
Tool | Description |
| Get the installed hayabusa binary's version. |
| List available output profiles. |
| Update the Sigma detection rule set. |
| List available Hayabusa/Sigma detection rules from the local rules directory, with an optional keyword filter. |
| Run |
| Run |
| Count event occurrences by Event ID. |
| Count events per computer name. |
| Output |
| Summarize successful and failed logon events. |
| Extract pivot keywords (users, computers, IPs, processes, command lines, etc.) by category. |
| Extract and decode base64-encoded strings from event fields. |
| Detect likely domain controllers and file servers from the logs. |
| Keyword/regex search over |
| High-level first-pass scan: combines log metadata, a detection timeline (filtered by min level and an optional rule-title keyword filter), and event ID metrics. Returns a concise |
| ATT&CK detection coverage over the installed rule set: an overall technique/tactic breakdown sorted weakest-covered first, or a focused answer for one |
| Rank installed Sigma rules by relevance to a free-text query (title match > tags match > description match), optionally scoped to an ATT&CK |
Resources
Unlike the tools above (which run analysis against .evtx files you point them at), these are read-only MCP resources for browsing the installed detection rule set itself — no .evtx file required. ATT&CK technique/tactic data is derived entirely from each Sigma rule's own tags: field (e.g. attack.t1059.001, attack.execution), not a bundled MITRE dataset, so it always matches whatever rules are actually installed. Each technique also gets a mitre_url (computed from the ID, e.g. https://attack.mitre.org/techniques/T1059/001/) and each tactic a hand-maintained display_name (e.g. credential-access → "Credential Access") — see CLAUDE.md for why technique IDs are not similarly enriched with human-readable names.
Resource URI | Description |
| Browsable rule catalog index, grouped by category, with per-category rule counts. |
| Full detail for a single rule by its Sigma |
| ATT&CK technique ID -> detecting rules (detection coverage by technique). |
| Rules detecting a single ATT&CK technique, e.g. |
| ATT&CK tactic -> detecting rules (detection coverage by tactic). |
Tests
pytestAll tests run against mocked subprocess calls, so no real hayabusa binary or .evtx file is required. Coverage is split across tests/test_hayabusa.py (the CLI wrapper functions), tests/test_knowledge.py (rule catalog/ATT&CK aggregation, against real small YAML fixtures), tests/test_config.py (binary resolution via HAYABUSA_BIN/PATH), and tests/test_server.py (the MCP tool and resource registrations themselves).
This does not apply to validate-rule-execution.py below, which is a separate, real-binary-required check, not part of pytest.
Custom Detection Rule Validation
This project's custom Sigma rules under rules/ are checked two ways:
validate-rule.py(.claude/skills/detection-engineering/scripts/validate-rule.py) — metadata-only: ATT&CK tag,level,falsepositives, and that a sibling.testcases.mdfile exists. Needs onlypyyaml, no real binary. Runs in CI (validate-rulesjob).validate-rule-execution.py(.claude/skills/detection-engineering/scripts/validate-rule-execution.py) — actually runs each rule against a real.evtxfixture via a realhayabusabinary and checks it fires/doesn't fire as documented in machine-readable```yamlblocks embedded in the rule's.testcases.md. Requires themcp_hayabusapackage installed (pip install -e .) and a realhayabusabinary onPATH/HAYABUSA_BIN. Runs in CI (validate-rule-executionjob, which downloads a pinned hayabusa binary), but you can also run it locally before treating a rule change as done:python .claude/skills/detection-engineering/scripts/validate-rule-execution.py rules/Fixtures are resolved from the
HAYABUSA_SAMPLE_EVTX_DIRenvironment variable if set (point this at a fuller local corpus, e.g. EVTX-ATTACK-SAMPLES), otherwise from the small real fixtures vendored undertests/fixtures/evtx/(seetests/fixtures/evtx/PROVENANCE.mdfor their sourcing). Exit codes:0all cases passed,1a case contradicted its documented expectation,2a usage/parse error,3no failures but at least one rule's cases were all skipped (missing binary or fixture) — kept distinct from0so a missing prerequisite can never look like a clean pass.
Threat Intelligence Ingestion
The /ingest-ti command (.claude/commands/ingest-ti.md) ingests IOC data from local files, normalizes it, and correlates it against this project's Sigma rule coverage. Two scripts back it, under .claude/skills/ingest-ti/scripts/:
ingest_ti.py— normalizes one input file (a native{type, value, confidence, source, first_seen, attack_technique, notes}JSON list, or a MISPEvent.Attribute[]JSON export) into that fixed schema. Needs only the Python standard library. Exit codes:0clean,1some indicators skipped/coerced,2usage/parse error.correlate_ti.py— takes 1+ normalized files, dedups/merges IOCs sharing a(type, value)key, and checks every ATT&CK technique they reference against this repo's installed Sigma rules viaanalyze_coverage/suggest_rule(mcp_hayabusa.knowledge). Optionally correlates against a saved Hayabusa scan result (--hayabusa-result) via a textual substring match. Exit codes:0clean,1issues found and/or an uncovered technique,2usage/parse error.
python .claude/skills/ingest-ti/scripts/ingest_ti.py intel/misp_export.json > /tmp/norm1.json
python .claude/skills/ingest-ti/scripts/correlate_ti.py /tmp/norm1.json --hayabusa-result artifacts/scan.jsonv1 supports native and MISP JSON only — no STIX/TAXII or live TI feed APIs (see .claude/skills/ingest-ti/SKILL.md's "Explicitly out of scope for v1"). Both scripts are unit-tested the normal mocked-nothing way in tests/test_ingest_ti.py/tests/test_correlate_ti.py, covered by the existing pytest job — no dedicated CI job is needed since neither script touches an external binary or network.
Lint / Typecheck
ruff check .
mypyBoth run in CI (see the lint job in .github/workflows/test.yml), alongside mypy tests since the tests directory isn't covered by [tool.mypy]'s default package selection.
Available Tools
9 toolsanalyze_coverageA
Analyze ATT&CK detection coverage across the installed Sigma rule set.
With no technique_id, returns an overall breakdown of how many rules cover each ATT&CK technique/tactic referenced anywhere in the rule set, sorted ascending by rule count so the weakest-covered techniques/tactics are easy to spot. With technique_id, returns a focused answer for just that one technique instead (rule_count 0 / covered=False if no installed rule references it -- not an error, a normal coverage answer).
IMPORTANT: coverage here means "referenced by tags on installed rules," not a gap analysis against the full MITRE ATT&CK matrix -- no MITRE reference dataset is bundled, so this cannot report techniques with zero rules across all of ATT&CK, only the distribution across what is actually installed. See coverage_scope in the result for this caveat.
Args: technique_id: Optional single ATT&CK technique ID (e.g. "T1059.001") to report focused coverage for instead of the full breakdown. rules_dir: Optional path to a rules directory. Defaults to the "rules" directory next to the resolved hayabusa binary. max_items: Maximum number of techniques/tactics to include in the overall breakdown lists (default 200). Ignored when technique_id is given.
Inputs: max_items, rules_dir, technique_id.
hayabusa_config_critical_systemsA
Find likely domain controllers and file servers from .evtx event logs.
Detects domain controllers via Security EID 4768 (Kerberos TGT requests, only logged by DCs) and file servers via Security EID 5145 (network share access, excluding the universal IPC$ share).
Unlike other tools here, hayabusa has no file-output option for this subcommand and normally asks an interactive yes/no question about saving each found category to its local config. That prompt can't be answered non-interactively, so on a hit this call may take close to its timeout to return; when it does, prompt_interrupted will be true in the result and any category not present in "categories" was never reached, not confirmed as empty.
Args: target: Path to an .evtx file or a directory containing .evtx files. max_hosts: Maximum number of hostnames to return per category (default 200).
Inputs: target (required), max_hosts.
hayabusa_logon_summaryA
Summarize successful and failed logon events across .evtx file(s).
Returns two bounded result sets, "successful" and "failed", each with its own total_rows/returned_rows/truncated/rows.
Args: target: Path to an .evtx file or a directory containing .evtx files. max_rows: Maximum number of rows to return per result set (default 200).
Inputs: target (required), max_rows.
hayabusa_pivot_keywords_listA
Extract pivot keywords (users, computers, IPs, etc.) from .evtx file(s).
Returns a dict of category name -> bounded keyword list, e.g. "Users", "IP Addresses", "Processes", "Command Lines" (categories come from hayabusa's pivot_keywords.txt config).
Args: target: Path to an .evtx file or a directory containing .evtx files. min_level: Optional minimum alert level to include, e.g. "informational", "low", "medium", "high", or "critical". max_keywords: Maximum number of keywords to return per category (default 200).
Inputs: target (required), min_level, max_keywords.
hayabusa_searchB
Search .evtx event records for one or more keywords or regex patterns.
Args: target: Path to an .evtx file or a directory containing .evtx files. keywords: Keywords (or regex patterns, if regex=True) to search for. regex: Treat keywords as regular expressions instead of literal strings. max_rows: Maximum number of matching rows to return (default 200).
Inputs: target (required), keywords (required), regex, max_rows.
hayabusa_update_rulesB
Download or update hayabusa's Sigma detection rule set.
Inputs: no named parameters. Returns: result
hayabusa_versionA
Get the installed hayabusa binary's version string.
Inputs: no named parameters. Returns: result
scan_evtxA
Run a high-level first-pass scan of an .evtx file or directory.
A convenience tool that combines hayabusa_log_metrics, hayabusa_csv_timeline (filtered by min_level), and hayabusa_eid_metrics into one call, plus a compact "summary" section, so a first look at a target doesn't require several separate tool calls.
Args: target: Path to an .evtx file or a directory containing .evtx files. min_level: Optional minimum alert level for the detection timeline, e.g. "informational", "low", "medium", "high", or "critical". rule_filter: Optional keyword to filter detections by. Only detections whose rule title contains this keyword (case-insensitive) are included. Matching only considers detections already fetched within max_rows -- raise max_rows if a large, truncated result set might hide matches. output_format: "summary" (default) returns a concise result -- aggregate counts plus a bounded "top_findings" list -- suited for reasoning over. "full" returns the complete result: file metadata, the full detection timeline, event ID metrics, and the summary, all still subject to rule_filter/max_results. max_results: Optional maximum number of detections ("findings") to return, applied after rule_filter. Defaults to max_rows, preserving prior behavior when omitted. max_rows: Maximum number of rows to fetch per sub-result (default 200). Also bounds how many detections rule_filter can search.
Inputs: target (required), max_rows, min_level, max_results, +2 more.
suggest_ruleA
Suggest existing installed Sigma rules relevant to a free-text query.
Unlike get_hayabusa_rules (exact case-insensitive substring match, returns every match), this scores each rule by how many of query's terms it matches -- a title match outweighs a tags match, which outweighs a description-only match -- and returns only the top max_suggestions candidates, most relevant first. Use this for "is there already a rule for X" / "which existing rule is closest to Y"; it finds and ranks existing rules, it does not write or generate new ones.
Args: query: Free-text description of the detection you're looking for, e.g. "mimikatz credential dumping". Required, non-empty. technique_id: Optional ATT&CK technique ID (e.g. "T1003.001") to restrict candidates to rules already tagged with that technique before ranking. max_suggestions: Maximum number of ranked candidates to return (default 10). rules_dir: Optional path to a rules directory. Defaults to the "rules" directory next to the resolved hayabusa binary.
Inputs: query (required), rules_dir, technique_id, max_suggestions.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 9 tools
Each tool targets a distinct task: rule updates, logon summary, version retrieval, keyword extraction, critical system detection, search, combined scan, coverage analysis, and rule suggestion. No two tools have overlapping purposes.
Naming is inconsistent: six tools use the 'hayabusa_' prefix, while three (scan_evtx, analyze_coverage, suggest_rule) do not. Verb patterns also vary (e.g., 'update_rules' vs 'logon_summary').
With 9 tools, the server is well-scoped for Windows event log analysis. Each tool addresses a specific need without redundancy or excessive granularity.
The surface covers rule management, detection, search, keyword extraction, system identification, and coverage analysis. Minor gaps exist (e.g., no dedicated tool to list all rules or export results), but core workflows are supported.
Maintenance
Related MCP Connectors
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
MITRE ATT&CK MCP — STIX bundles from github.com/mitre/cti.
A paid remote MCP for ClawManager, built to return verdicts, receipts, usage logs, and audit-ready J
Offline methodology engine for authorized penetration testing, CTF, and security research.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables Windows Event Log (EVTX) analysis by wrapping Hayabusa, exposing scan and rule retrieval tools.MIT
- FlicenseNot gradedqualityDmaintenanceEnables scanning Windows EVTX event log files with Hayabusa, returning structured detection results through an MCP tool.-
- FlicenseNot gradedqualityDmaintenanceAn MCP server that wraps the Hayabusa CLI, enabling analysis of Windows EVTX event log files and browsing of its detection rule set.-
- AlicenseAqualityDmaintenanceEnables MCP clients to run Hayabusa detection scans over Windows event log (.evtx) files for forensic analysis and threat hunting.2MIT