# Wazuh Detection Rules — Engineering Notes

Reference for each custom Wazuh rule defined in `wazuh_brute_force_rules.xml`. Designed to strictly align with interview defensibility requirements.

---

## Architecture Overview

**Why Wazuh?** 
Wazuh natively integrates with Kubernetes (via DaemonSets) and provides out-of-the-box File Integrity Monitoring (FIM), rootkit detection, and log correlation. It's lighter and more cost-effective than deploying a full Splunk forwarder on every node in Ghaymah Containers.

**Rule ID Strategy:** 
Standard Wazuh rules use IDs < 100,000. Custom user rules must be >= 100,000. We reserved `100200-100219` for Ghaymah Authentication Rules to maintain organized namespaces and prevent conflicts with future official updates.

---

## Rule Definitions

### Rule 100200: Base API Auth Failure
- **Purpose:** Acts as the foundational baseline rule, triggering on every single failed API login.
- **Parent Rule:** N/A (Standalone base rule)
- **Decoder:** `json` (Our API logs natively in structured JSON)
- **Rule ID selection:** 100200 (Start of our reserved auth block)
- **Alert Level:** 3 (Low) - High enough to index in Elastic, low enough to avoid spam.
- **MITRE ATT&CK Mapping:** T1110 (Brute Force)
- **Conditions:** `field name="event.action"` matches `login_failed`
- **False Positives:** Legitimate users mistyping passwords.
- **False Negatives:** Attackers exploiting token bypasses instead of password auth.
- **Example triggering log:** `{"timestamp":"2026-07-27T10:00:00Z", "event":{"action":"login_failed"}, "source":{"ip":"192.168.1.5"}}`
- **Expected alert:** Silent indexing. No active response.
- **Testing method:** `curl -X POST /api/login -d '{"user":"test", "pass":"wrong"}'`
- **Possible improvements:** Enrich with GeoIP data at the decoder level.

### Rule 100202: Confirmed Brute Force
- **Purpose:** Detects sustained, aggressive credential guessing from a single IP.
- **Parent Rule:** 100200
- **Decoder:** `json`
- **Rule ID selection:** 100202
- **Alert Level:** 10 (High)
- **MITRE ATT&CK Mapping:** T1110.001 (Password Guessing)
- **Frequency:** 20 occurrences
- **Timeframe:** 120 seconds
- **Conditions:** `<same_source_ip />`
- **False Positives:** Corporate NAT gateways where 20 different users are legitimately failing logins concurrently.
- **False Negatives:** "Low and slow" brute force (e.g., 1 attempt per hour).
- **Example triggering log:** (20x of Rule 100200 from the same IP)
- **Expected alert:** "Confirmed Brute Force Attack from IP X". Triggers Soft Block via n8n.
- **Testing method:** `hydra -l admin -P rockyou.txt https-post-form "/api/login"`
- **Possible improvements:** Dynamically adjust the timeframe based on the IP's previous reputation score.

### Rule 100204: Distributed Brute Force (Credential Stuffing)
- **Purpose:** Detects botnets using rotating proxies to attack a single account, bypassing per-IP rate limits.
- **Parent Rule:** 100200
- **Decoder:** `json`
- **Rule ID selection:** 100204
- **Alert Level:** 12 (High)
- **MITRE ATT&CK Mapping:** T1110.003 (Password Spraying)
- **Frequency:** 10 occurrences
- **Timeframe:** 300 seconds
- **Conditions:** `<same_field>data.target_user</same_field>` AND `<different_source_ip />`
- **False Positives:** Distributed team attempting to log into a shared service account concurrently (bad practice, but happens).
- **False Negatives:** Botnets targeting multiple accounts simultaneously (avoids `same_field` correlation).
- **Example triggering log:** 10 failures for `admin` from 10 different AWS/Ghaymah Cloud IPs.
- **Expected alert:** "Distributed Brute Force against Account X".
- **Testing method:** Custom Python script rotating proxies while attacking one account.
- **Possible improvements:** Integrate with Threat Intelligence feeds to identify known Tor exit nodes automatically.

### Rule 100206: Successful Login AFTER Brute Force (Compromise)
- **Purpose:** Identifies the moment a brute force attack transitions into a successful breach.
- **Parent Rule:** N/A (Correlates across auth success rule)
- **Decoder:** `json`
- **Rule ID selection:** 100206
- **Alert Level:** 14 (Critical)
- **MITRE ATT&CK Mapping:** T1078 (Valid Accounts)
- **Conditions:** `<if_matched_sid>100202</if_matched_sid>` AND `authentication_success` from the same IP.
- **False Positives:** A legitimate user legitimately forgets their password, fails 20 times, resets it, and logs in successfully.
- **False Negatives:** The attacker brute-forces the password from IP A, but uses it to log in via VPN from IP B.
- **Example triggering log:** Rule 100202 fires, followed immediately by `{"event":{"action":"login_success"}}`.
- **Expected alert:** "CRITICAL: Account Compromised following Brute Force".
- **Testing method:** Run hydra to trigger 100202, then immediately log in with correct credentials via curl.
- **Possible improvements:** Change correlation to track the target account rather than just the source IP to prevent the IP A/B bypass.

### Rule 100208: Service Account Brute Force
- **Purpose:** Protects non-MFA enabled machine accounts.
- **Parent Rule:** 100200
- **Decoder:** `json`
- **Rule ID selection:** 100208
- **Alert Level:** 14 (Critical)
- **MITRE ATT&CK Mapping:** T1078.003 (Local Accounts)
- **Frequency:** 5 occurrences
- **Timeframe:** 60 seconds
- **Conditions:** Regex match on `^svc-|^service-|^system-`
- **False Positives:** A misconfigured internal cronjob failing to authenticate.
- **False Negatives:** Service accounts that don't follow the naming convention.
- **Expected alert:** "CRITICAL: Service Account Brute Force Attempt".
- **Testing method:** `hydra -l svc-db-backup -P rockyou.txt https-post-form "/api/login"`
- **Possible improvements:** Query Active Directory/LDAP directly rather than relying on regex string matching for the username.