Introducing Fomorian: The Attack Simulation Engine That Validates Your Detections

Your detection rules are worthless until someone tests them.

You can have 10,000 Sigma rules deployed. Your SIEM can be perfectly tuned. But unless you’ve proven those rules fire under real attack conditions, you’re guessing. Fomorian exists to eliminate that guesswork.

What is Fomorian?

Fomorian is an attack simulation engine built for one purpose: validate that your detection rules actually work.

It’s not a penetration testing framework. It’s not an EDR bypass tool. It’s a purple team validation system that generates realistic attack telemetry, injects it into your SIEM, and proves whether your detections fire.

The Numbers

As of February 2026:

Every log represents a real attack executed in our lab, captured via Sysmon, and packaged for reproduction.

Why Fomorian Exists

The Detection Problem

Most security teams build detection rules like this:

  1. Read threat intel report: “Attackers use PowerShell -EncodedCommand”
  2. Write Sigma rule: commandLine|contains: '-enc'
  3. Deploy to production
  4. Never test it

Then six months later, an attacker uses -EncodedCommand (not -enc) and your rule misses it. You never knew because you never tested.

The Testing Gap

Testing detection rules is hard:

Fomorian solves this by providing precaptured, reproducible attack telemetry in standard Wazuh alert format.

How Fomorian Works

1. Attack Execution (Done For You)

We execute real attacks in our lab environment:

Every technique is executed multiple ways:

2. Telemetry Capture

All telemetry flows through our Wazuh deployment:

Logs are captured in native Wazuh alert JSON format - no custom schemas, no proprietary formats. If you run Wazuh, these logs work.

3. Attack Log Structure

Each Fomorian attack log contains:

{
  "_metadata": {
    "attack_id": "T1003.001",
    "variation": "001",
    "name": "LSASS Memory Dump via comsvcs.dll",
    "description": "Uses rundll32 to dump LSASS memory",
    "expected_detection": "HIGH",
    "kill_chain_phase": "credential-access",
    "format": "wazuh-native"
  },
  "logs": [
    {
      "sequence": 1,
      "timestamp": "2026-01-30T10:00:00.000Z",
      "log": {
        // Full Wazuh alert JSON
        "rule": {
          "level": 12,
          "description": "Sysmon - Event 1",
          "mitre": {
            "id": ["T1003.001"],
            "tactic": ["Credential Access"]
          }
        },
        "data": {
          "win": {
            "eventdata": {
              "image": "C:\\Windows\\System32\\rundll32.exe",
              "commandLine": "rundll32.exe C:\\Windows\\System32\\comsvcs.dll, MiniDump 656 C:\\Users\\Public\\lsass.dmp full"
            }
          }
        }
      }
    }
  ]
}

4. Customize Logs to Match Your Environment

Fomorian attack logs come with template placeholders that you replace with your actual environment details. This generates attack logs that look like they came from your real systems, making testing far more realistic.

Why Customize?

Generic attack logs with fake hostnames like “VICTIM PC” don’t test your environment properly. Your detection rules might key off specific hostnames, domain names, or IP ranges. Custom logs test your actual environment.

What You Can Customize:

Field Template Variable Your Real Value (Example)
Hostname `` DC01.contoso.local, WS FINANCE-05, WEBSERVER PROD
Username `` bob.smith, admin, svc_backup, CONTOSO\jdoe
Domain `` CONTOSO, CORP, PROD.INTERNAL
IP Address `` 10.50.20.x, 192.168.10.x, your actual subnet
External IP `` Simulated attacker IP matching your threat intel
Timestamp `` Actual time when you’re testing (autoadjusted to your timezone)

How It Works:

  1. Download attack log template (contains placeholders like ``)
  2. Run customization script with your real environment values
  3. Script replaces all placeholders with your actual hostnames, IPs, usernames
  4. Output: Custom attack log ready to inject, looking like it came from your systems

Example:

# Input your REAL environment details
./scripts/customize-logs.sh \
  --hostname "DC01.contoso.local" \           # Your actual domain controller
  --username "bob.smith" \                    # Real username from your AD
  --domain "CONTOSO" \                        # Your actual domain
  --ip-schema "10.50.20" \                    # Your actual subnet (10.50.20.x)
  --external-ip "203.0.113.45" \              # Simulated attacker IP
  --timezone "America/New_York" \             # Your timezone
  --input attacks/credential-access/T1003.001-lsass/logs/001-comsvcs-dll.json \
  --output customized-lsass-dump.jsonl

# Output: Attack log showing "DC01.contoso.local" being attacked by "203.0.113.45"
# Uses username "bob.smith", IP 10.50.20.103, timestamp in your local timezone

Result:

Your customized logs will show:

This tests your detection rules against logs that look exactly like your production environment.

5. Log Variants

Each attack technique includes two log format variants:

Variant Description Use Case
Sysmon Sysmon Event logs with detailed telemetry Environments with Sysmon deployed
Windows Event Log Native Windows Event Log (Security, System, etc.) Baseline Windows logging without Sysmon

Example:

attacks/credential-access/T1003.001-lsass/logs/
├── 001-comsvcs-dll-sysmon.json      # Sysmon Event 10 (ProcessAccess)
├── 001-comsvcs-dll-winevent.json    # Security Event 4656 (Object Access)
├── 002-procdump-sysmon.json         # Sysmon Event 10
├── 002-procdump-winevent.json       # Security Event 4656
└── ...

This allows testing detection coverage across different logging configurations.

6. Injection & Validation

Inject logs into your Wazuh deployment:

# Simple injection
cat attack-log.jsonl >> /var/ossec/logs/alerts/alerts.json

# Or use Fomorian script
./scripts/inject-logs.sh attacks/credential-access/T1003.001-lsass/

Telemetry flows through your entire pipeline:

You now know if your rule works.

SIEM Agnostic Design

Fomorian logs are in standard Wazuh format - they work with ANY downstream SIEM:

Your Stack Compatibility
Wazuh + Graylog ✅ Native support
Wazuh + ELK ✅ Works (Filebeat adds filebeat_* prefix)
Wazuh + Splunk ✅ Works (HEC or file monitoring)
Standalone Wazuh ✅ Works (alerts.json)

The only requirement: You must have Wazuh processing the logs. Don’t inject directly into downstream SIEMs - that bypasses normalization and breaks field mappings.

Using Fomorian

Installation

# Clone the repository
git clone https://github.com/pookasec/fomorian.git
cd fomorian

# Browse available attacks
ls -la attacks/

# Directory structure:
# attacks/{tactic}/T{id}-{name}/logs/*.json

Example: Testing LSASS Credential Dumping

Step 1: Choose technique

cd attacks/credential-access/T1003.001-lsass-memory/logs/
ls -la

# Available variations:
# 001-comsvcs-dll.json       - rundll32 + comsvcs.dll
# 002-procdump.json          - Sysinternals ProcDump
# 003-task-manager.json      - GUI-based dump

Step 2: Review the attack

cat 001-comsvcs-dll.json | jq '._metadata'

# Output:
# {
#   "attack_id": "T1003.001",
#   "name": "LSASS Dump via comsvcs.dll",
#   "expected_detection": "HIGH",
#   "description": "Uses Windows built-in comsvcs.dll to dump LSASS"
# }

Step 3: Inject into Wazuh

# Convert to JSONL (one alert per line)
jq -c '.logs[].log' 001-comsvcs-dll.json > /tmp/attack.jsonl

# Copy to Wazuh manager
scp /tmp/attack.jsonl wazuh-server:/tmp/

# Append to alerts.json
ssh wazuh-server 'cat /tmp/attack.jsonl >> /var/ossec/logs/alerts/alerts.json'

Step 4: Check your SIEM

Wait 3-5 seconds for telemetry to flow, then search:

# Graylog query
filebeat_rule_mitre_id:T1003.001 AND timestamp:[now-5m TO now]

# Look for:
sigma_rule_title:"LSASS Process Access"
filebeat_data_win_eventdata_image:*rundll32.exe
filebeat_data_win_eventdata_targetImage:*lsass.exe

Did your detection fire?

Real World Example

Before Fomorian

Security Team: “We have Sigma rules for credential dumping.”
Auditor: “Have you tested them?”
Security Team: “Well.. we haven’t seen any real attacks yet, so we assume they work?”
Auditor: 🤨

After Fomorian

Security Team: “We validated all 15 credential dumping techniques.”
Auditor: “How?”
Security Team: “Injected Fomorian attack logs. 12 detected, 3 had gaps. We created new rules for the gaps. Want to see the test results?”
Auditor: 👍

Actual Detection Gap Found

Technique: T1003.001 - LSASS dump via Task Manager

Expected: Should be detected by Sigma rule lsass_access_suspicious

Reality: Rule had filter for taskmgr.exe because admins use it legitimately

Gap: Attacker with RDP access could dump LSASS undetected

Fix: Added context aware rule:

Result: Gap closed, now detected

We only found this because we tested with Fomorian.

Use Cases

1. Purple Team Operations

Scenario: Quarterly purple team exercise

# Inject full ransomware kill chain
./scripts/inject-engagement.sh engagements/ransomware/

# 148 logs covering:
# - Initial access (phishing)
# - Execution (macros, scripts)
# - Discovery (network scanning)
# - Lateral movement (PsExec, WMI)
# - Impact (file encryption)

Validate your detections catch each phase.

2. Detection Rule QA

Scenario: New Sigma rule deployed

# Test the specific technique it should detect
./scripts/inject-logs.sh attacks/execution/T1059.001-powershell/

# Check if rule fires
# If it doesn't, fix the rule
# Re-inject to verify fix

3. MITRE ATT&CK Coverage Assessment

Scenario: Compliance audit asks for ATT&CK coverage

# Test all 244 techniques
for dir in attacks/**/T*/; do
  ./scripts/inject-logs.sh "$dir"
done

# Query SIEM for detection rate
# Generate coverage matrix
# Show auditor which techniques are covered

6. SIEM Migration Validation

Scenario: Migrating from Splunk to Graylog

# Inject Fomorian logs into NEW Graylog deployment
# Verify same detections fire as old Splunk deployment
# No detections lost in migration

Fomorian vs. Other Tools

Tool Purpose Use Case
Fomorian Validate existing detections Purple team, QA, coverage assessment
Atomic Red Team Execute attacks on endpoints Red team, endpoint testing
Caldera Automated adversary emulation Red team, autonomous operations
MITRE ATT&CK Evaluations Vendor testing Compare EDR products

Key Difference: Fomorian has precaptured logs - you don’t need to execute attacks. This means:

Attack Coverage

By Tactic

Tactic Techniques Example Attacks
Initial Access 12 Phishing, drive by, supply chain
Execution 24 PowerShell, WMI, scheduled tasks
Persistence 18 Registry run keys, services, DLL hijacking
Privilege Escalation 16 UAC bypass, token manipulation
Defense Evasion 32 Event log clearing, DLL injection, masquerading
Credential Access 15 LSASS dump, SAM dump, Kerberoasting
Discovery 22 Network scanning, account enumeration
Lateral Movement 14 PsExec, WMI, RDP hijacking
Collection 18 Clipboard, screen capture, keylogging
Command & Control 16 DNS tunneling, web protocols
Exfiltration 12 Cloud storage, web services
Impact 14 Data encryption, disk wipe, defacement

By Platform

Platform Techniques Log Source
Windows 182 Sysmon, Event Logs, PowerShell
Linux 48 Sysmon for Linux, auditd
macOS 14 OSQuery, ES logs

Engagement Scenarios

Full multiphase attack chains:

1. Ransomware (148 logs)

2. Persistent APT (96 logs)

3. Insider Threat (39 logs)

6. Destructive Attack (56 logs)

5. Business Email Compromise (15 logs)

6. Data Exfiltration (66 logs)

7. Account Takeover (46 logs)

Getting Started

1. Clone Fomorian

git clone https://github.com/pookasec/fomorian.git
cd fomorian

2. Pick a Technique

# Browse by tactic
ls attacks/credential-access/

# Or search by ID
find attacks/ -name "T1003.001*"

3. Inject & Validate

# Convert to JSONL
jq -c '.logs[].log' attacks/credential-access/T1003.001-lsass/logs/001-comsvcs-dll.json > /tmp/attack.jsonl

# Inject (adjust for your Wazuh deployment)
cat /tmp/attack.jsonl >> /var/ossec/logs/alerts/alerts.json

# Check SIEM for detections

6. Document Results

## T1003.001 - LSASS Memory Dump

- Method 1 (comsvcs.dll): ✅ Detected by rule 100201
- Method 2 (procdump): ✅ Detected by rule 100201
- Method 3 (task manager): ⚠️ Filtered - need context-aware rule

Coverage: 2/3 methods (66%)

Best Practices

1. Test All Variations

Don’t just test one method per technique. Attackers use multiple tools:

# Test ALL LSASS dump methods
./scripts/inject-logs.sh attacks/credential-access/T1003.001-lsass/

2. Test Edge Cases

Look for:

3. Document Gaps

When a technique isn’t detected:

❌ T1055.001 - Process Injection via CreateRemoteThread

Gap: No Sysmon Event 8 logging enabled
Fix: Enable CreateRemoteThread detection in Sysmon config
Priority: HIGH (common ransomware technique)

6. Regression Testing

Rerun Fomorian tests after:

Fomorian is named after the Fomorians - mythical invaders in Irish mythology, fitting for an adversary simulation tool built by PookaSec.