DEV Community

Bryant
Bryant

Posted on

Automating Purple Team Lifecycle: How I Built PILA Suite

The Problem No Single Tool Was Solving
Every purple team exercise I ran ended the same way: a spreadsheet of techniques tested, a list of gaps found, a few custom Suricata rules written, and a PDF report produced manually. The detection data lived in Elasticsearch. The engagement notes lived in a doc. The scores lived in my head.
There was no single tool that took you from “here’s the technique I want to test” all the way through “here’s a quantitative score of how well your detection stack performed, here’s the gap, here’s the fix confirmed working.” Caldera executes techniques. Vectr tracks engagements. Neither scores your detection program or validates that a remediation actually worked.
So I built PILA Suite.

What PILA Suite Is
PILA Suite (Purple Intelligence & Lifecycle Automation) is a purple team automation platform built on four integrated modules:

PSIL (Purple Structured Intelligence Language) — structured ATT&CK-mapped engagement documentation. Every scenario gets a technique ID, a tactic, a detection outcome, and a gap detail. Machine-readable, version-controllable, and exportable.

LMEP (Lateral Movement Emulation Proxy) — behavioral technique emulation against scoped targets, with automatic correlation against live Elasticsearch data from all connected detection sources. Run a technique, wait 30 seconds, get back a correlation result showing exactly what fired and what didn’t.

IRV (Incident Remediation Validator) — post-remediation validation. After cleaning a compromised host, IRV queries all connected detection sources and produces a timestamped, signed evidence bundle confirming the host shows no active malicious indicators.

AESP (Attack Effectiveness Scoring Platform) — quantitative scoring engine (Patent Pending). Every engagement produces an Effectiveness Score (0–100) and a Defense Maturity Tier (DMT-1 through DMT-5). The same technique set, run twice after closing gaps, produces a measurably higher score. That’s the point.

It is not an endpoint agent. It is not a SIEM. It does not replace your detection stack — it sits on top of it and measures how well it works.

The Detection Stack It Connects To
PILA Suite ships with six detection connectors, each querying a different data source after technique emulation:

• Suricata — network IDS alerts via Elasticsearch/Filebeat. PILA queries filebeat-* with event.dataset: suricata.eve and event.kind: alert.
• Zeek — network connection logs. Adds connection-level visibility alongside signature-based alerts.
• Wazuh — HIDS alerts from the Wazuh indexer. Endpoint-level detection: file integrity, authentication, process execution.
• Elastic Security — pre-built ATT&CK-mapped detection rules. 19 active alerts covering T1046 and T1595 in the current lab.
• Winlogbeat + Sysmon — Windows Event Logs from monitored endpoints. With Sysmon installed (SwiftOnSecurity config), PILA correlates process creation (EID 1), network connections (EID 3), file creation (EID 11), and DNS queries (EID 22). 520+ Sysmon events flowing in the current lab.
• Splunk Enterprise — newest connector, querying Splunk 8.x/9.x/10.x via REST API. Supports alert queries, ATT&CK technique correlation, host cleanliness checks, and technique frequency statistics.

Each connector follows the same pattern: after LMEP executes a technique, PILA queries all connected sources for matching alerts in the correlation window. The result tells you exactly which sources detected the technique and which missed it.

What the Lab Looks Like
The full deployment runs on a home Proxmox server:

192.168.10.172 ghostserver — PILA Suite + Elasticsearch + Suricata + Zeek
192.168.10.253 Wazuh LXC — Wazuh SIEM + 4 monitored agents
192.168.10.192 Bryant-PC — Windows 11 + Winlogbeat + Sysmon
192.168.10.122 Splunk LXC — Splunk Enterprise 10.2.3 test instance
192.168.10.120 bytexbit-web — Company website (nginx, Cloudflare proxied)

Everything on a single /24 host-only network. Suricata monitors the segment. Filebeat ships events to Elasticsearch. PILA queries Elasticsearch over HTTPS. The whole detection loop runs on hardware you can buy for under $1,500.

A Real Example: Finding and Closing a Detection Gap
Exercise 04 tested T1021.004 (Remote Services: SSH) using LMEP in SYNTHETIC/PASSIVE mode.
The initial correlation came back: 0 Suricata alerts, 0 Zeek connections, 0 Packetbeat flows. Detection gap confirmed. No existing Suricata rule covered the behavioral pattern of SYNTHETIC SSH lateral movement traffic.
Five minutes later, a custom local rule was written and deployed:

alert tcp any any -> 192.168.10.70 22 (msg:"LAB SSH Lateral Movement Attempt";
flow:to_server,established; content:"SSH"; depth:3; sid:9000001; rev:1;)

After restarting Suricata, a real SSH connection fired the rule twice. PILA’s alert endpoint returned the custom signature. The PSIL engagement was updated, the gap was marked closed, and AESP re-scored the engagement.
That is the complete purple team loop: emulate, identify gap, write detection, re-test, confirm closure, score. No external tools required.

The Scoring Model (Patent Pending)
AESP calculates the Effectiveness Score from five weighted sub-dimensions:

Sub-score Weight What it measures
Detection Efficacy (DE) 30% Did the technique trigger any detection?
Response Speed (RS) 20% How quickly was the alert generated?
Prevention Rate (PR) 20% Was the technique blocked before completing?
Coverage Breadth (CB) 15% What percentage of the attack surface is covered?
Remediation Quality (RQ) 15% Was the gap closed and validated?

The current lab baseline sits at ES ~62, DMT-3. The consistent 62.9 Coverage Breadth reflects a real finding: the detection stack has known gaps at the network connection layer that Zeek integration will close. The score is honest. It measures what your detection stack actually catches, not what you hope it catches.

Architecture: What PILA Is and Is Not
Before building anything on top of PILA Suite, placement matters:

Target hosts (Bryant-PC, UserPC, victim VMs)
↓ traffic
Sensors (Suricata, Zeek, Wazuh agents, Winlogbeat/Sysmon)
↓ events
Elasticsearch (all telemetry centralized)
↓ queries / ↑ correlation results
PILA Suite (orchestration layer)
→ LMEP emulates against targets
→ IRV validates remediation
→ AESP scores engagement outcomes
→ PSIL documents everything

PILA Suite is a central server component — one Linux host, Python 3.11+, no agents on monitored endpoints. It runs on port 8000. Everything else in your detection stack continues operating independently. PILA reads from it and measures it.

Open Core Model
PILA Suite is open source under Apache 2.0 with a Professional Edition for teams that need the full platform.

Community Edition (free, GitHub): PSIL SDK, all six detection connectors, REST API with Swagger docs, INSTALL.md, USAGE.md, FAQ.md.

Professional Edition ($99/month): LMEP adversary emulation, live Elasticsearch correlation, AESP quantitative scoring, IRV remediation validation with signed evidence bundles, ATT&CK coverage heatmap, report generation.

The detection connectors and PSIL SDK are freely available to the community. The emulation engine and scoring formula stay proprietary — that’s where the IP is (Patent Pending, USPTO).

Where It Goes Next
v1.1 (Q3 2026) — API authentication, LMEP and IRV persistence, FastAPI router refactor, pytest suite.
v1.2 (Q4 2026) — Microsoft Sentinel connector, CrowdStrike Falcon connector, full Zeek pipeline, report generation.
v2.0 (2027) — multi-tenancy for MSSP deployments, PostgreSQL backend, GHOST integration (coverage regression detection).

Try It
GitHub: github.com/nonducorduco311-cyber/pila-suite
Documentation: INSTALL.md, USAGE.md, FAQ.md all in the repo
Beta access: bryant@byte-x-bit.com (Professional Edition free trial in exchange for practitioner feedback)
Company: byte-x-bit.com

© 2026 ByTE X Bit Technologies LLC — Patent Pending. PILA Suite, PSIL, LMEP, IRV, and AESP are trademarks of ByTE X Bit Technologies LLC.

Top comments (0)