RedSEC

Bridging Offensive and Defensive Security Through Log Correlation

How a red teamer’s logs can tell a defender exactly what they missed — and generate the SEC rules that would have caught it

The Problem Nobody Talks About

Every red team engagement ends the same way: you have a folder full of tool outputs. Nmap’s XML here. Nuclei’s JSONL there. Ffuf results scattered across three terminals. Hydra logs forgotten in /tmp.

Writing the final pentest report means manually piecing together what happened, when, and in what order. You’re the attacker — you know the full story. But translating it into something a defender can act on takes hours of manual work.

I kept running into this problem. And I couldn’t stop thinking about a different question:

What if offensive tool output could be automatically correlated, mapped to MITRE ATT&CK, and exported as detection rules — so the defender could see not just what happened, but what rule would have caught it?

That question became RedSEC.

The Inspiration: Risto Vaarandi’s SEC

While researching log correlation, I found a 2002 IEEE paper by Risto Vaarandi — the creator of SEC (Simple Event Correlator). SEC is a tool built for defenders: it reads log files, matches patterns using regular expressions, and fires alerts when attack patterns emerge.

Vaarandi built SEC for the blue team. I thought: what if we fed red team output into SEC?

What if a red teamer’s logs could directly tell a defender:

“Here is what I did. Here is the sequence of events. And here is the SEC rule that would have detected me.”

I emailed Vaarandi directly. He responded:

“a very interesting project 🙂 thanks for letting me know! using Single and SingleWithThreshold rules is perfectly fine. There are more complex rule types available (and also ways to combine rules together with contexts and synthetic events)…”

That email changed the direction of the project. I implemented everything he mentioned.

What RedSEC Does

RedSEC is an open-source Python tool that:

1. Parses output from 9 offensive security tools
2. Correlates events into attack chains using YAML rules
3. Maps every event to MITRE ATT&CK techniques automatically
4. Scores detection risk per event (0.0 to 1.0)
5. Exports to SEC .conf format — rules that defenders can run immediately
6. Generates a dark-theme HTML report with severity badges and MITRE tags

GitHub: https://github.com/alisalive/RedSEC

Supported Tools

RedSEC parses output from:

• nmap — Port scanning (-oX XML format)
• subfinder — Subdomain enumeration (-oJ JSON)
• ffuf — Web fuzzing (-o -of json)
• feroxbuster — Directory brute forcing (--output JSONL)
• nuclei — Vulnerability scanning (-json JSONL)
• sqlmap — SQL injection testing (--output-dir JSON)
• hydra — Brute force attacks (-o text)
• metasploit — Exploitation (JSON export)
• impacket — Active Directory attacks (secretsdump text)

The Pipeline

Here is what happens when you run RedSEC:

nmap XML + nuclei JSONL + ffuf JSON
         |
         v
   Parsers (per-tool)
   normalize to RedSecEvent
         |
         v
   MitreMapper
   enrich with T-ID and tactic
         |
         v
   DetectionScorer
   assign risk score 0.0-1.0
         |
         v
   CorrelationEngine
   match YAML rules → AttackChains
         |
         v
   SecExporter          HtmlExporter
   rules.conf           report.html
         |
         v
   sec --conf=rules.conf --input=redsec.log

The SEC Export: Four Rule Types

This is where RedSEC gets technically interesting. Vaarandi’s SEC supports several rule types. RedSEC v1.1.0 implements all of them.

Sequence rules fire when a defined sequence of events occurs within a time window. Each event becomes a type=Single rule; chain completion uses type=SingleWithThreshold:

type=Single
ptype=RegExp
pattern=\S+ nmap port_scan 10\.0\.0\.1 .*port 22
desc=redsec_RECON_CHAIN_nmap_port_scan_a1b2c3d4
action=write - CHAIN: %s | EVENT: port_scan | TARGET: 10.0.0.1 | MITRE: T1046

type=SingleWithThreshold
ptype=RegExp
pattern=CHAIN: Recon Chain
desc=Chain Recon Chain detected
action=write - REDSEC CHAIN COMPLETE: Recon Chain | severity=high
window=86400
thresh=2

PairWithWindow rules fire when event A is followed by event B within a time window. They fire a different action if B never arrives — distinguishing a successful attack chain from a failed one:

type=PairWithWindow
ptype=RegExp
pattern=\S+ nmap port_scan 10\.0\.0\.1 .*port 22
desc=redsec_PAIR_port_scan_first_desc
ptype2=RegExp
pattern2=\S+ metasploit exploit_success 10\.0\.0\.1
desc2=redsec_PAIR_exploit_success_second_desc
window=300
action=write - ATTACK CHAIN CONFIRMED: port_scan led to exploit_success
action2=write - RECON ONLY: port_scan detected but no exploitation followed

Context rules capture a field value (e.g. target IP) from a trigger event and check whether the next matching event shares the same value. This distinguishes a focused attack (same target) from scattered reconnaissance (different targets):

type=PairWithWindow
ptype=RegExp
pattern=\S+ nmap port_scan 10\.0\.0\.1
desc=redsec_CTX_port_scan_trigger_desc
ptype2=RegExp
pattern2=\S+ nuclei vuln_found 10\.0\.0\.1
desc2=redsec_CTX_vuln_found_match_desc
window=86400
action=write - FOCUSED ATTACK: port_scan and vuln_found on same target
action2=write - SCATTERED RECON: different targets

Synthetic rules count trigger events within a sliding window. When the threshold is reached, the engine generates a synthetic event and groups all contributing events into a chain:

# SYNTHETIC EVENT CHAIN — generated by RedSEC correlation engine
# Fires when 3+ port_scan events occur within 300 seconds
# SYNTHETIC: Mass port scan detected — 3+ scans in 300 seconds

MITRE ATT&CK Coverage

Every event in RedSEC is automatically enriched with MITRE ATT&CK technique IDs:

• T1046 — Network Service Discovery (nmap port scans)
• T1595 — Active Scanning (subfinder recon)
• T1083 — File and Directory Discovery (ffuf/feroxbuster)
• T1190 — Exploit Public-Facing Application (nuclei findings)
• T1110 — Brute Force (hydra credential attacks)
• T1078 — Valid Accounts (successful logins)
• T1021 — Remote Services (lateral movement)
• T1003 — OS Credential Dumping (impacket secretsdump)
• T1059 — Command and Scripting Interpreter (exploitation)
• T1018 — Remote System Discovery (AD enumeration)
• T1133 — External Remote Services (VPN/RDP exposure)

For the Red Team

The workflow is simple:

# Run your tools as normal
nmap -oX scan.xml target.com
nuclei -u target.com -json -o nuclei.jsonl
ffuf -u target.com/FUZZ -o dirs.json -of json

# Feed everything to RedSEC
redsec scan \
  --nmap scan.xml \
  --nuclei nuclei.jsonl \
  --ffuf dirs.json \
  --out-html report.html \
  --out-sec rules.conf \
  --out-log redsec.log

You get:

• A dark-theme HTML report with your full attack timeline
• A SEC .conf file ready for the defender
• A structured event log with MITRE technique mapping

For the Blue Team

The defender receives the .conf file and runs it against their own log infrastructure:

sec --conf=rules.conf --input=redsec.log --fromstart

SEC fires alerts for every detected event and chain completion. The defender sees not just what happened — but the exact SEC rule that would have caught each stage of the attack.

This is the core idea: the attacker’s output becomes the defender’s detection rule.

The Community Response

After building the initial version, I emailed Risto Vaarandi directly. He is the creator of SEC and a professor at TalTech (Tallinn University of Technology, Estonia).

His response:

“a very interesting project 🙂 thanks for letting me know! using Single and SingleWithThreshold rules is perfectly fine. There are more complex rule types available (and also ways to combine rules together with contexts and synthetic events), but for many scenarios which require immediate action or event counting, Single and SingleWithThreshold work, and there is no need to use more complex things.”

He also suggested I post to the SEC mailing list — which I did. Within hours, Clayton Dukes, CEO of LogZilla (a commercial log management platform built on top of SEC), reached out:

“I’m the CEO of LogZilla. We have SEC integrated into LogZilla (and have for many years). My colleague Tom forwarded your email to me and I found it interesting. I’m wondering if you might be interested in a zoom call to run through it and possibly include it for our user base. One of the cool things I see here is that our AI could also be integrated with it.”

A Zoom call is scheduled. A 16-year-old from Baku, Azerbaijan built a tool that got the attention of both the academic creator of SEC and the CEO of a commercial company built on top of it — within 24 hours of posting to a mailing list.

Technical Details

Language: Python 3.11+ Key dependencies: Pydantic, PyYAML, Jinja2, Click Tests: 96 passing on Python 3.11 and 3.12 CI/CD: GitHub Actions License: MIT

The correlation engine is YAML-driven. You can write your own rules:

rules:
  - name: "Custom Web Attack Chain"
    description: "Directory scan followed by vulnerability exploitation"
    conditions:
      - dir_found
      - vuln_found
    window_seconds: 3600
    chain_name: "Web Attack Chain"
    severity: high

  - name: "Recon to Exploit Pair"
    type: pair_with_window
    first: port_scan
    second: exploit_success
    window_seconds: 300
    chain_name: "Recon to Exploit Pair"
    severity: critical
    on_match: "ATTACK CHAIN CONFIRMED"
    on_timeout: "RECON ONLY: no exploitation detected"

Why I Built This

I am a 16-year-old security researcher from Baku, Azerbaijan. I completed MilliSec LLC’s intensive cybersecurity training program and hold eJPTv2, CRTA, Web-RTA, AD-RTS, and MCRTA certifications.

During red team engagements, I kept writing the same thing in every report: “The attacker could have been detected at this stage if the following rule was in place.”

I wanted a tool that would write that sentence automatically — and generate the actual detection rule alongside it.

That is RedSEC. Not a product. Not a demo. A tool I use, built to solve a real problem I kept hitting.

What’s Next

• Context and Synthetic rule support (v1.1.0 — already shipped)
• LogZilla integration (in discussion)
• More parsers: Burp Suite, CrackMapExec, BloodHound
• Real-time monitoring mode (tail mode for live engagements)

Links

GitHub: https://github.com/alisalive/RedSEC

Portfolio: https://alisalive.vercel.app

LinkedIn: https://linkedin.com/in/camalzads

GitHub profile: https://github.com/alisalive

If you’re a red teamer who’s tired of manually correlating tool output — or a blue teamer who wants to understand what an attacker’s logs actually look like — RedSEC might be useful to you.

Feedback, issues, and pull requests are welcome.

— Shikhali Jamalzade