recon-reporting
Recon output formatting — report structure, CVSS v4.0 scoring (primary), MITRE ATT&CK mapping, finding prioritization, Markdown output, detection gap tracking, handoff checklists.
57
Quality
68%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Securityby
Critical
Do not install without reviewing
Fix and improve this skill with Tessl
tessl review fix ./packages/decepticon/decepticon/skills/standard/recon/reporting/SKILL.mdReconnaissance Reporting Knowledge Base
Effective reconnaissance is only as valuable as the intelligence it communicates. This skill defines how to structure, prioritize, and present findings for actionable handoff to the next engagement phase.
All agent-authored documents MUST be Markdown format (.md). Scan output files (.txt, .xml) are operational data and are not documents.
1. Report Structure
Every recon engagement produces a structured report with these sections:
Executive Summary
A 2-3 sentence overview of what was found, the overall attack surface size, and the most critical findings.
Target Overview
| Field | Value |
|---|---|
| Primary Domain | example.com |
| Scope | *.example.com, 10.0.0.0/24 |
| Engagement Type | External Recon |
| Recon Duration | Passive: X min, Active: Y min |
2. Finding Document Template
Each significant verified finding gets its own Markdown file in findings/ named by canonical ID: findings/FIND-{NNN}.md. Do not create placeholder finding files. Use this template:
---
id: FIND-001
severity: CRITICAL
cvss_score: 9.3
cvss_vector: "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N"
cwe: CWE-306
mitre: T1595.001
affected_target: api.example.com:3306
confidence: confirmed
objective_id: OBJ-REC-006
phase: recon
agent: recon-agent-run-42
detected: false
remediation_priority: immediate
discovered_at: 2026-04-06T14:30:00Z
---
# [CRITICAL] Exposed MySQL Database on api.example.com:3306 allows Unauthenticated Access
## Description
MySQL 5.7.42 is accessible from the internet on `api.example.com:3306` without network-level access controls. Any party that can reach this host can attempt authentication directly against the database engine.
## Steps to Reproduce
1. From an external IP, run:
```
nmap -sV -p 3306 api.example.com
```
2. Observe that port 3306 is open and the MySQL 5.7.42 banner is returned.
3. Attempt connection with no credentials:
```
mysql -h api.example.com -u root
```
4. Observe whether login succeeds or fails with an authentication error (both indicate the port is reachable).
## Impact
Direct internet exposure of the MySQL port enables brute-force, credential stuffing, and exploitation of any MySQL CVE applicable to version 5.7.42. Successful authentication yields full database read/write access to application data.
## Evidence
| Type | Path | Description |
|------|------|-------------|
| Scan output | findings/evidence/FIND-001_nmap.txt | nmap -sV -p 3306 full output |
| Screenshot | findings/evidence/FIND-001_mysql_banner.txt | Raw MySQL banner response |
## Detection Gap Analysis
| Control | Fired? | Notes |
|---------|--------|-------|
| Firewall / ACL | No | Port 3306 reachable from external IP |
| SIEM alert | Unknown | No alert observed during scan window |
| IDS/IPS | No | Scan completed without interruption |
| WAF | N/A | Not applicable to TCP/MySQL traffic |
Blue team detection status: **Not detected**. The reconnaissance activity produced no observable defensive response.
## Remediation
1. Add a firewall rule to block inbound TCP 3306 from all sources except application servers.
2. Upgrade MySQL to the latest 8.x release (5.7 is EOL).
3. Audit MySQL user accounts and remove anonymous/root remote logins.
4. Enable MySQL audit logging.
## References
- CVE database for MySQL 5.7: https://www.cvedetails.com/product/3300/
- CIS MySQL Benchmark: https://www.cisecurity.org/benchmark/mysql
- MITRE ATT&CK T1595.001: https://attack.mitre.org/techniques/T1595/001/3. Finding Categories
A. Domain & Subdomain Inventory
| Subdomain | IP Address | Status | Notes |
|-----------|-----------|--------|-------|
| www.example.com | 93.184.216.34 | Active | Main site, Cloudflare CDN |
| api.example.com | 10.0.1.50 | Active | REST API, no WAF detected |
| dev.example.com | 10.0.1.51 | Active | Development server, potential target |
| old.example.com | — | NXDOMAIN | Decommissioned |
| staging.example.com | CNAME → *.herokuapp.com | Dangling | Subdomain takeover candidate |B. DNS & Infrastructure Map
| Record Type | Value | Analysis |
|-------------|-------|----------|
| A | 93.184.216.34 | Primary web server |
| MX | aspmx.l.google.com (pri 10) | Google Workspace email |
| NS | ns1.cloudflare.com | Cloudflare DNS hosting |
| TXT (SPF) | v=spf1 include:_spf.google.com ~all | Soft fail SPF |
| TXT (DMARC) | v=DMARC1; p=none | DMARC not enforced |
| CAA | 0 issue "letsencrypt.org" | Only Let's Encrypt can issue certs |C. Open Ports & Services
| IP | Port | Protocol | Service | Version | Risk Notes |
|----|------|----------|---------|---------|------------|
| 10.0.1.50 | 22 | TCP | SSH | OpenSSH 8.9p1 | Current version |
| 10.0.1.50 | 80 | TCP | HTTP | nginx 1.18.0 | Outdated (CVE potential) |
| 10.0.1.50 | 443 | TCP | HTTPS | nginx 1.18.0 | TLS 1.2, missing HSTS |
| 10.0.1.50 | 3306 | TCP | MySQL | 5.7.42 | Exposed database port |
| 10.0.1.51 | 8080 | TCP | HTTP | Apache Tomcat 9.0.65 | Dev server, default page |D. Technology Stack
| Layer | Technology | Evidence |
|-------|-----------|----------|
| CDN | Cloudflare | CF-RAY header, NS records |
| Web Server | nginx 1.18.0 | Server header |
| Backend | PHP 8.1 | X-Powered-By header |
| CMS | WordPress 6.x | /wp-content/ paths |
| Database | MySQL 5.7 | Port 3306 open, banner |
| Email | Google Workspace | MX records |
| DNS | Cloudflare | NS records |E. Vulnerability Scan Results
| Source | Target | Finding | Severity | Template/CVE |
|--------|--------|---------|----------|--------------|
| nuclei | api.example.com | Exposed .env file | CRITICAL | exposure-env |
| nuclei | dev.example.com | Git config disclosure | HIGH | git-config |
| nikto | www.example.com | X-Frame-Options missing | MEDIUM | — |
| nmap | 10.0.1.50:443 | TLS 1.0 supported | MEDIUM | ssl-enum-ciphers |4. CVSS Scoring
CVSS 4.0 (Primary)
CVSS 4.0 is the primary scoring system for all findings. Use CVSS 3.1 only for dual-reporting when client systems require it.
Score Ranges
| Score | Severity | Response |
|---|---|---|
| 9.0 – 10.0 | Critical | Immediate remediation required |
| 7.0 – 8.9 | High | Remediate within days |
| 4.0 – 6.9 | Medium | Remediate within weeks |
| 0.1 – 3.9 | Low | Remediate within quarter |
| 0.0 | None | Informational |
CVSS 4.0 Metric Groups
Base (BTE — required):
AVAttack Vector: N (Network) / A (Adjacent) / L (Local) / P (Physical)ACAttack Complexity: L (Low) / H (High)ATAttack Requirements: N (None) / P (Present) — replaces Scope conceptPRPrivileges Required: N / L / HUIUser Interaction: N (None) / P (Passive) / A (Active)VC/VI/VAVulnerable System: Confidentiality / Integrity / Availability — N/L/HSC/SI/SASubsequent System: Confidentiality / Integrity / Availability — N/L/H
Threat (T — optional, adjusts exploitability):
EExploit Maturity: X (Not Defined) / A (Attacked) / P (POC) / U (Unreported)
Environmental (E — optional, adjusts for deployment context):
CR/IR/ARConfidentiality/Integrity/Availability RequirementsMAV/MAC/MAT/MPR/MUIModified Base metrics
Supplemental (S — informational only, no score impact):
AUAutomatable: Y/N — can the attack be scripted at scale?RRecovery: A (Automatic) / U (User) / I (Irrecoverable)VValue Density: D (Diffuse) / C (Concentrated)REResponse Effort: L (Low) / M (Moderate) / H (High)UProvider Urgency: Clear / Green / Amber / Red
Common Recon Finding CVSS 4.0 Scores
| Finding | CVSS 4.0 | Vector |
|---|---|---|
| Exposed database port (MySQL/Postgres) | 9.3 | AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N |
| Subdomain takeover | 8.7 | AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N |
| .env file exposure | 8.7 | AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N |
| Git config disclosure | 7.5 | AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N |
| Directory listing enabled | 6.9 | AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N |
| Missing security headers | 4.3 | AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N |
| Information disclosure (version) | 6.9 | AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N |
| DMARC not enforced | 4.0 | AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N |
Dual Reporting (when client requires CVSS 3.1 as well)
Include both scores in the finding frontmatter and the body:
- **CVSS 4.0**: 9.3 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N)
- **CVSS 3.1**: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)Set cvss_vector in the YAML frontmatter to the CVSS 4.0 vector. Add cvss_v31_score and cvss_v31_vector as additional frontmatter fields if dual-reporting.
5. Evidence Management
Storage Layout
Raw scan evidence is stored separately from finding documents:
findings/
├── FIND-001.md # Finding document (Markdown; id in frontmatter)
├── FIND-002.md
└── evidence/
├── FIND-001_nmap.txt # Raw nmap output
├── FIND-001_mysql_banner.txt # Raw banner grab
├── FIND-002_nuclei.txt # Raw nuclei output
└── FIND-002_curl_env.txt # Raw HTTP response
recon/
├── recon_<target>_passive.txt
├── recon_<target>_subdomains.txt
├── httpx_<target>.txt
├── nmap_<target>_<scan_type>.txt
├── nmap_<target>_<scan_type>.xml
├── ffuf_<target>.txt
└── nuclei_<target>.txtEvidence File Rules
- Evidence files in
findings/evidence/are plain text dumps of tool output, not Markdown. - Name format:
FIND-{NNN}_{tool}.txtwhere{tool}is the tool that produced the output (e.g.,nmap,nuclei,curl,httpx). - Multiple evidence files per finding are allowed; add one row per file to the Evidence table in the finding document.
- Do not truncate evidence files — preserve full raw output for re-analysis.
Evidence Table Format
In the finding document, list evidence as a table:
## Evidence
| Type | Path | Description |
|------|------|-------------|
| Scan output | findings/evidence/FIND-001_nmap.txt | nmap -sV -p 3306 full output |
| Banner grab | findings/evidence/FIND-001_mysql_banner.txt | Raw MySQL server banner |6. Detection Gap Analysis (Purple Team / TIBER-EU)
Every finding document MUST include a Detection Gap Analysis section. This is a core red team deliverable that distinguishes operational red teaming from standard penetration testing.
Purpose
Record whether the blue team (SOC/SIEM/IDS) detected the reconnaissance activity that led to this finding. This data feeds:
- TIBER-EU and CBEST purple team exercises
- SOC maturity assessments
- Control gap remediation roadmaps
Detection Gap Table
## Detection Gap Analysis
| Control | Fired? | Notes |
|---------|--------|-------|
| Firewall / ACL | No | Port 3306 reachable from external IP |
| SIEM alert | Unknown | No alert observed during scan window |
| IDS/IPS | No | Scan completed without interruption |
| WAF | N/A | Not applicable to TCP/MySQL traffic |
| EDR on host | Unknown | No endpoint visibility from external position |- Fired? values:
Yes,No,Unknown,N/A - Use
Unknownwhen detection cannot be confirmed or denied from the attacker position - Use
N/Awhen the control is not applicable to the attack vector
Detection Status Line
After the table, state the overall detection outcome explicitly:
Blue team detection status: **Not detected**. The reconnaissance activity produced no observable defensive response during the scan window (2026-04-06T14:00–14:45Z).Or if detected:
Blue team detection status: **Detected**. SIEM alert fired at 14:22Z, approximately 8 minutes after scanning began. Scanning was not interrupted, indicating detection-without-response gap.7. MITRE ATT&CK Mapping
Reconnaissance Tactics (TA0043)
| Technique ID | Name | Recon Activity |
|---|---|---|
| T1595.001 | Active Scanning: IP Blocks | nmap port scanning |
| T1595.002 | Active Scanning: Vulnerability Scanning | nuclei, nikto scans |
| T1595.003 | Active Scanning: Wordlist Scanning | ffuf, gobuster |
| T1592.001 | Gather Victim Host Info: Hardware | OS fingerprinting (-O) |
| T1592.002 | Gather Victim Host Info: Software | Service version detection (-sV) |
| T1593.001 | Search Open Websites: Social Media | OSINT gathering |
| T1593.002 | Search Open Websites: Search Engines | Google dorking |
| T1596.001 | Search Open Technical Databases: DNS/Passive DNS | dig, subfinder, amass |
| T1596.002 | Search Open Technical Databases: WHOIS | whois lookups |
| T1596.003 | Search Open Technical Databases: Digital Certificates | crt.sh CT log queries |
Use the mitre field in finding frontmatter for the primary technique. List secondary techniques in the References section of the finding document.
8. Finding Prioritization
Priority Levels
| Priority | Criteria | Example |
|---|---|---|
| CRITICAL | Immediate exploitation potential, CVSS 4.0 ≥ 9.0 | Exposed database, default creds, subdomain takeover |
| HIGH | Known CVE or significant misconfiguration, CVSS 7.0–8.9 | Outdated service with public exploit, missing auth |
| MEDIUM | Information disclosure or weak configuration, CVSS 4.0–6.9 | Verbose error pages, missing security headers |
| LOW | Informational or hardening recommendation, CVSS < 4.0 | DMARC not enforced, older TLS ciphers |
Prioritized Findings List Format
The consolidated report's findings section groups by priority:
## Critical Findings
### FIND-001 — [CRITICAL] Exposed MySQL on api.example.com:3306
- **CVSS 4.0**: 9.3 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N)
- **MITRE ATT&CK**: T1595.001
- **Evidence**: nmap -sV confirms MySQL 5.7.42 open from internet
- **Risk**: Unauthenticated database access
- **Recommendation**: Firewall TCP 3306, upgrade MySQL to 8.x
- **Full finding**: [findings/FIND-001.md](findings/FIND-001.md)
## High Findings
### FIND-002 — [HIGH] Dangling CNAME — staging.example.com
- **CVSS 4.0**: 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N)
- **MITRE ATT&CK**: T1596.001
- **Evidence**: CNAME points to deprovisioned Heroku app
- **Risk**: Subdomain takeover enables phishing and cookie theft
- **Recommendation**: Remove DNS record or reclaim the Heroku app
- **Full finding**: [findings/FIND-002.md](findings/FIND-002.md)9. Attack Chain Analysis
Identifying Exploit Chains
Individual findings combine into attack chains. Document these explicitly — they represent real-world risk better than isolated scores.
## Attack Chain: Unauthenticated Database Access
**Chain**: Subdomain discovery → Exposed MySQL → Credential extraction
**Combined Risk**: CRITICAL
1. Passive recon discovered `db.example.com` via CT logs (T1596.003)
2. Active scan confirmed MySQL 5.7.42 on port 3306, internet-facing (T1595.001)
3. No authentication required for `root` user (empty password)
4. Database contains PII for ~50,000 users
**Impact**: Full database compromise without any credentials
**Remediation**: Firewall MySQL port, set root password, audit access logs
**Detection gap**: Neither step 1 nor step 2 triggered a SOC alertChain Severity Escalation
| Individual Findings | Severity Alone | Chained Severity |
|---|---|---|
| Directory listing + .env exposure | Medium + High | CRITICAL (credentials leaked) |
| Subdomain takeover + cookie scope | High + Medium | CRITICAL (session hijack) |
| SSRF + cloud metadata | Medium + N/A | CRITICAL (IAM credential theft) |
| Weak TLS + HSTS missing | Low + Low | Medium (downgrade attack viable) |
10. File Management
Directory Layout
/workspace/
├── plan/
│ ├── roe.json # Rules of Engagement (read-only)
│ ├── conops.json # Threat actor profile
│ └── opplan.json # Objectives tracker
├── timeline.jsonl # Append-only activity/finding timeline
├── recon/
│ └── report_<target>.md # Consolidated recon report
├── findings/
│ ├── FIND-001.md # Individual finding (Markdown; id in frontmatter)
│ ├── FIND-002.md
│ └── evidence/
│ ├── FIND-001_nmap.txt # Raw scan output (plain text)
│ └── FIND-002_nuclei.txt
└── recon/
├── recon_<target>_passive.txt
├── recon_<target>_subdomains.txt
├── httpx_<target>.txt
├── nmap_<target>_<scan_type>.txt
├── nmap_<target>_<scan_type>.xml
├── ffuf_<target>.txt
└── nuclei_<target>.txtNaming and Persistence Rules
- Finding documents:
findings/FIND-{NNN}.md(e.g.,findings/FIND-001.md) - The file name and
idfield in YAML frontmatter (FIND-001,FIND-002, ...) are the canonical cross-reference - Evidence artifacts:
findings/evidence/FIND-{NNN}_{tool}.txt(keyed by finding ID) - Raw scan data:
recon/directory, named by tool and target - Always save scan output with
-oN(nmap),-o(subfinder/nuclei/httpx), or output flags (ffuf) - Keep raw data — the final report synthesizes, but raw data enables re-analysis
11. OPPLAN Feedback Loop
After generating the report, update plan/opplan.json to reflect actual findings.
Update Completed Objectives
For each recon objective:
- Set
"status": "completed"for finished objectives - Add an actual findings summary to a
"results"field - Note any objectives that were blocked or partially completed
Create Follow-Up Objectives
When the report reveals new targets or attack paths not in the original OPPLAN:
- Create new objectives following the
OBJ-{PHASE}-{NUMBER}convention - Assign priorities based on finding severity (CRITICAL findings → highest priority)
- Ensure new objectives have scope check, OPSEC check, and output persistence criteria
- Use
opplan-converterskill'sreferences/objective-rules.mdfor validation
Report → OPPLAN Mapping
| Report Finding | Completed Objective | New Objective (if authorized) |
|----------------|--------------------|-----------------------------|
| FIND-001: Exposed MySQL (CRITICAL, CVSS 9.3) | OBJ-REC-006 (port scan) | OBJ-EXP-001 (test MySQL default credentials) |
| FIND-002: Dangling CNAME (HIGH, CVSS 8.7) | OBJ-REC-003 (subdomain enum) | OBJ-EXP-002 (attempt subdomain takeover) |12. Handoff Checklist
Before concluding reconnaissance and handing off to the exploitation phase:
- All subdomains enumerated and resolved
- DNS infrastructure fully mapped
- All in-scope IPs port-scanned with service versions
- Technology stack identified for key assets
- Vulnerability scan (nuclei) run on all live web targets
- Each significant finding has a
findings/FIND-{NNN}.mddocument - All findings scored with CVSS 4.0 (v3.1 added if dual-reporting required)
- Findings mapped to MITRE ATT&CK techniques
- Detection gap analysis completed for each finding
- Findings prioritized by exploitability and chained risk
- Raw evidence saved to
findings/evidence/with correct naming - Raw scan data preserved in
recon/directory - Attack chains documented in consolidated report
- Consolidated recon report saved to
recon/report_<target>.md -
opplan.jsonupdated with completed objectives and findings - New follow-up objectives created for next phase (if authorized)
- Repository
- PurpleAILAB/Decepticon
- Commit
31e1c8e
- Last updated
- First committed
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.