Skip to content

the-opalgupta/Blue-Watch

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

6 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Blue Watch

A mini SIEM-style detection engine built from scratch in Python. Parses logs from multiple sources, applies configurable detection rules, scores threats, and generates a full incident report — all from a single command.

What it does

Blue Watch simulates a realistic, multi-stage attack scenario spanning two log sources:

  • Web recon (Apache): an attacker scans for admin panels, gets 404s and 401s, is eventually blocked (403).
  • SSH attack (auth.log): the same attacker brute-forces the admin account, succeeds, escalates privileges via sudo, creates a backdoor account (shelly), and reads /etc/shadow.
  • Legitimate noise: an unrelated employee (luna) logs in normally from an internal IP, interleaved into the same timeline — included deliberately to test that detection correctly distinguishes signal from noise.

Blue Watch detects the full attack chain across both sources using config-driven rules mapped to MITRE ATT&CK techniques, and unifies everything under a single attacker identity in the final report.

Features

  • Custom regex-based log parsers for two log formats (sshd/sudo/useradd auth logs, and Apache Combined Log Format)
  • Multi-source log support — both sources normalize into one shared event schema and share the same detection pipeline
  • Config-driven detection rules (YAML) — no hardcoded logic
  • Threshold-based rules (e.g. brute force, repeated web scanning) and sequence-based rules (e.g. privilege escalation chains)
  • Entity resolution — links IP-based and user-based alerts back to a single attacker identity
  • Threat scoring with severity levels (LOW/MEDIUM/HIGH/CRITICAL)
  • MITRE ATT&CK technique mapping
  • JSON output for machine-readable alerts
  • Auto-generated Markdown incident report (executive summary, timeline, MITRE mapping, IOCs, recommendations)

How to run

python3 main.py

Output is saved to:

  • output/alerts.json — structured alert + score data
  • output/incident_report.md — full incident report

Project structure

siem/
├── parsers/
│ ├── auth_parser.py # auth.log parsing + normalization
│ └── apache_parser.py # Apache access log parsing + normalization
├── rules/
│ └── rules.yaml # detection rules config
├── detector.py # rule engine (threshold + sequence rules)
├── scorer.py # threat scoring + entity resolution
├── timeline.py # chronological event reconstruction
└── report.py # incident report generation

Design decisions

  • Normalized event schema: every log line, regardless of source, is converted into one consistent shape (timestamp, user, event_type, ip). This is what let Apache support get added without touching the detector, scorer, timeline, or report logic at all — only a new parser was needed.
  • Config-driven rules: detection logic lives in rules.yaml, not hardcoded in Python. Adding the Apache-specific detection rule required zero changes to detector.py — just a new YAML entry.
  • Entity resolution: alerts triggered by an IP are automatically linked back to the real user seen using that IP (derived from auth events, not incidental request data like URL paths), so a single attacker's activity across both log sources scores as one unified threat instead of fragmenting across multiple entities.
  • Deliberately hand-crafted test data: rather than using messy real-world logs, the attack scenario was designed with a known "ground truth" so detection logic could be verified against a specific, understood incident — including a legitimate, unrelated login interleaved into the attack window to test for false positives.

Known limitations

  • Currently parses sshd/sudo/useradd (auth.log) and standard Combined Log Format (Apache) lines only. Other log formats or message types are not yet recognized (tracked via an "unmatched lines" counter in each parser).
  • Test data is a hand-crafted, realistic attack scenario rather than production log data, chosen deliberately to validate detection logic against a known ground truth.

Roadmap

  • Sigma rule format support
  • Correlation engine for linking multi-stage incidents automatically
  • Live log tailing / real-time monitoring
  • IOC enrichment (AbuseIPDB, VirusTotal)

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages