Skip to main content
Glama
mcp-hayabusa

mcp-hayabusa

by omeryemba

mcp-hayabusa

Tests Version

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 PATH or pointed to via the HAYABUSA_BIN environment variable.

Related MCP server: mcp-hayabusa

Install

pip install -e ".[dev]"

Run

mcp-hayabusa

or

python -m mcp_hayabusa

The 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

hayabusa_version

Get the installed hayabusa binary's version.

hayabusa_list_profiles

List available output profiles.

hayabusa_update_rules

Update the Sigma detection rule set.

get_hayabusa_rules

List available Hayabusa/Sigma detection rules from the local rules directory, with an optional keyword filter.

hayabusa_csv_timeline

Run csv-timeline over an .evtx file or directory; returns bounded rows + total count.

hayabusa_json_timeline

Run json-timeline over an .evtx file or directory; returns bounded JSON records + total count.

hayabusa_eid_metrics

Count event occurrences by Event ID.

hayabusa_computer_metrics

Count events per computer name.

hayabusa_log_metrics

Output .evtx file metadata (channels, event count, date range, etc.).

hayabusa_logon_summary

Summarize successful and failed logon events.

hayabusa_pivot_keywords_list

Extract pivot keywords (users, computers, IPs, processes, command lines, etc.) by category.

hayabusa_extract_base64

Extract and decode base64-encoded strings from event fields.

hayabusa_config_critical_systems

Detect likely domain controllers and file servers from the logs.

hayabusa_search

Keyword/regex search over .evtx event records.

scan_evtx

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 summary/top_findings result by default, or the full combined result with output_format="full".

analyze_coverage

ATT&CK detection coverage over the installed rule set: an overall technique/tactic breakdown sorted weakest-covered first, or a focused answer for one technique_id. Coverage is measured only against techniques/tactics referenced by installed rules, not the full ATT&CK matrix — see the tool's coverage_scope caveat.

suggest_rule

Rank installed Sigma rules by relevance to a free-text query (title match > tags match > description match), optionally scoped to an ATT&CK technique_id. Finds and ranks existing rules; unlike get_hayabusa_rules's exact substring match, results are relevance-ordered and capped at max_suggestions.

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

hayabusa://rules

Browsable rule catalog index, grouped by category, with per-category rule counts.

hayabusa://rules/{rule_id}

Full detail for a single rule by its Sigma id.

hayabusa://attack/techniques

ATT&CK technique ID -> detecting rules (detection coverage by technique).

hayabusa://attack/techniques/{technique_id}

Rules detecting a single ATT&CK technique, e.g. hayabusa://attack/techniques/T1059.001.

hayabusa://attack/tactics

ATT&CK tactic -> detecting rules (detection coverage by tactic).

Tests

pytest

All 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.md file exists. Needs only pyyaml, no real binary. Runs in CI (validate-rules job).

  • validate-rule-execution.py (.claude/skills/detection-engineering/scripts/validate-rule-execution.py) — actually runs each rule against a real .evtx fixture via a real hayabusa binary and checks it fires/doesn't fire as documented in machine-readable ```yaml blocks embedded in the rule's .testcases.md. Requires the mcp_hayabusa package installed (pip install -e .) and a real hayabusa binary on PATH/HAYABUSA_BIN. Runs in CI (validate-rule-execution job, 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_DIR environment variable if set (point this at a fuller local corpus, e.g. EVTX-ATTACK-SAMPLES), otherwise from the small real fixtures vendored under tests/fixtures/evtx/ (see tests/fixtures/evtx/PROVENANCE.md for their sourcing). Exit codes: 0 all cases passed, 1 a case contradicted its documented expectation, 2 a usage/parse error, 3 no failures but at least one rule's cases were all skipped (missing binary or fixture) — kept distinct from 0 so 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 MISP Event.Attribute[] JSON export) into that fixed schema. Needs only the Python standard library. Exit codes: 0 clean, 1 some indicators skipped/coerced, 2 usage/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 via analyze_coverage/suggest_rule (mcp_hayabusa.knowledge). Optionally correlates against a saved Hayabusa scan result (--hayabusa-result) via a textual substring match. Exit codes: 0 clean, 1 issues found and/or an uncovered technique, 2 usage/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.json

v1 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 .
mypy

Both 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 tools
analyze_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_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

    A3.9/5.0

    Scored across 9 tools

    Disambiguation5/5

    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 Consistency2/5

    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').

    Tool Count5/5

    With 9 tools, the server is well-scoped for Windows event log analysis. Each tool addresses a specific need without redundancy or excessive granularity.

    Completeness4/5

    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

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      Enables Windows Event Log (EVTX) analysis by wrapping Hayabusa, exposing scan and rule retrieval tools.
      MIT
    • F
      license
      Not graded
      quality
      D
      maintenance
      Enables scanning Windows EVTX event log files with Hayabusa, returning structured detection results through an MCP tool.
      -
    • F
      license
      Not graded
      quality
      D
      maintenance
      An MCP server that wraps the Hayabusa CLI, enabling analysis of Windows EVTX event log files and browsing of its detection rule set.
      -
    • A
      license
      A
      quality
      D
      maintenance
      Enables MCP clients to run Hayabusa detection scans over Windows event log (.evtx) files for forensic analysis and threat hunting.
      2
      MIT