Security Incident Reporting

Security Incident Reporting

Source: https://github.com/dirnbauer/webconsulting-skills

Comprehensive framework for documenting and analyzing security incidents, drawing from NIST SP 800-61 and SANS methodologies.

When to Use

• After a security incident (DDoS, breach, vulnerability exploitation)
• Creating post-mortem documentation
• Communicating with stakeholders (C-level, legal, security teams)
• Correlating attack patterns with known CVEs
• Establishing incident response metrics (MTTR, dwell time)

Related Skills

• security-audit - Pre-incident vulnerability assessment
• typo3-security - TYPO3 hardening
• SKILL-TYPO3.md - TYPO3-specific incident reporting

---

1. Incident Response Framework

NIST SP 800-61 / SANS Harmonization

Documentation Principle

Logbuch-Prinzip: Document in real-time during the incident, then consolidate into the post-mortem report. Never create reports retrospectively from memory.

---

2. Severity Rating Systems

NCISS (National Cyber Incident Scoring System)

DDoS Resiliency Score (DRS)

CVSS Integration

For vulnerability-based incidents, include CVSS v3.1 base score from the security-audit skill.

---

3. Incident Report Template

Module A: Metadata & Executive Summary

# Security Incident Report

## Metadata
| Field | Value |
|-------|-------|
| Incident ID | SIR-2026-001 |
| Classification | Confidential |
| Status | Closed / Active / Under Investigation |
| Detection Time | 2026-01-21 14:32 UTC |
| Resolution Time | 2026-01-21 15:17 UTC |
| MTTR | 45 minutes |
| Severity | High (NCISS: 65) |
| Lead Analyst | Jane Doe |
| Affected Systems | web-cluster-01, cdn-edge-eu |

## Executive Summary (max 200 words)

On [DATE], our monitoring systems detected [INCIDENT TYPE] targeting [SYSTEMS].
The attack [IMPACT DESCRIPTION]. Through [RESPONSE ACTIONS], normal operations
were restored within [TIMEFRAME]. [DATA IMPACT STATEMENT].

### Business Impact
- Service Availability: [Degraded/Offline for X minutes]
- Data Impact: [None/Potential exposure of X records]
- Financial Impact: [Estimated cost]
- Reputation Impact: [Public/Internal]

Module B: Timeline (Chronological Analysis)

## Incident Timeline

| Time (UTC) | Event | Source | Action Taken |
|------------|-------|--------|--------------|
| 14:32 | Traffic spike detected | Cloudflare Alert | On-call notified |
| 14:35 | 5x baseline traffic confirmed | Grafana | Incident declared |
| 14:38 | Geo-blocking activated | Cloudflare | EU/US traffic filtered |
| 14:42 | Attack vector identified: UDP amplification | DPI Analysis | Null-route for UDP/427 |
| 14:55 | Traffic normalized | Monitoring | Mitigation confirmed |
| 15:17 | All systems stable | Status page | Incident closed |

### Dwell Time Analysis
- Time to Detection (TTD): 0 minutes (automated)
- Time to Containment (TTC): 10 minutes
- Time to Eradication (TTE): 23 minutes
- Time to Recovery (TTR): 45 minutes

Module C: Technical Analysis & IoCs

## Technical Analysis

### Attack Vectors (MITRE ATT&CK)
- T1498: Network Denial of Service
- T1498.001: Direct Network Flood
- T1498.002: Reflection Amplification

### Indicators of Compromise (IoCs)

#### Network Artifacts
| Type | Value | Context |
|------|-------|---------|
| IP Range | 192.0.2.0/24 | Source (spoofed) |
| ASN | AS12345 | Amplification source |
| Port | UDP/427 | SLP Amplification |
| Signature | \x00\x00\x00\x00SLP | Payload pattern |

#### System Artifacts
| Type | Value | Hash (SHA256) |
|------|-------|---------------|
| Modified File | /var/www/shell.php | a1b2c3... |
| New User | backdoor_admin | N/A |
| Cron Job | /tmp/.hidden/beacon | d4e5f6... |

### Root Cause Analysis (5-Whys)
1. Why did the attack succeed? → Amplification ports were exposed
2. Why were ports exposed? → Firewall rules not updated after migration
3. Why weren't rules updated? → No automated validation in deployment
4. Why no automation? → Security review not in CI/CD pipeline
5. Why not in pipeline? → Technical debt, prioritized features

**Root Cause**: Missing security validation in deployment pipeline

---

4. DDoS Post-Mortem Analysis

Metrics Table

Attack Vector Classification

Multi-Vector Detection

Was this a smoke-screen attack?
├── Volumetric attack started: 14:32
├── Application-layer probing detected: 14:38
├── Login brute-force attempts: 14:40-14:45
└── Conclusion: Coordinated multi-vector attack

---

5. CVE Correlation for DDoS

Map attack signatures to known vulnerabilities for threat intelligence.

Amplification Vector CVE Table

Analysis Example

## CVE Correlation Analysis

Traffic analysis shows 40% of UDP flood originated from port 427.
Deep Packet Inspection confirmed payloads typical for CVE-2023-29552.

**Conclusion**: Botnet leveraging unpatched VMware ESXi instances as
SLP reflectors. Recommend:
1. Verify our infrastructure is not acting as reflector
2. Block UDP/427 at edge
3. Report to upstream provider

---

6. Impact Assessment Matrix

Operational Impact

Financial Impact

Reputation Impact

---

7. Blameless Post-Mortem

Principles

1. Focus on systems, not individuals: "Why did the process allow X?" not "Who did X?" 2. Assume good intentions: Everyone acted with the best information available 3. Learn, don't punish: Goal is improvement, not blame 4. Share openly: Publish internally for organizational learning

Post-Mortem Template

## Post-Mortem: [Incident Title]

### What Happened
[Factual description of the incident]

### What Went Well
- Detection was automated (0 min TTD)
- On-call responded within SLA
- Communication was clear

### What Went Wrong
- Firewall rules were outdated
- No alerting for UDP traffic spikes
- Runbook was incomplete

### Action Items
| ID | Action | Owner | Due Date | Status |
|----|--------|-------|----------|--------|
| 1 | Add security validation to CI/CD | @devops | 2026-02-01 | Open |
| 2 | Update runbook with DDoS procedures | @security | 2026-01-28 | Open |
| 3 | Implement UDP traffic alerting | @sre | 2026-02-05 | Open |

### Lessons Learned
- Automated security gates prevent configuration drift
- Regular runbook reviews are essential
- Multi-vector attacks require layered defense

---

8. Report Distribution

Classification Levels

Retention Requirements

---

9. Checklists

Pre-Incident Preparation

• [ ] Incident response runbooks documented
• [ ] On-call rotation established
• [ ] Communication templates prepared
• [ ] Evidence collection tools ready
• [ ] Stakeholder contact list updated

During Incident

• [ ] Incident declared and logged
• [ ] Timeline documentation started
• [ ] Evidence preserved (logs, packets)
• [ ] Stakeholders notified
• [ ] Status page updated

Post-Incident

• [ ] Full incident report completed
• [ ] Post-mortem meeting scheduled
• [ ] Action items assigned and tracked
• [ ] Lessons learned documented
• [ ] Controls validated/improved

---

References

• NIST SP 800-61 Rev. 2
• SANS Incident Response
• MITRE ATT&CK
• DDoS Resiliency Score
• CISA NCISS

---

Credits & Attribution

This skill draws from the "Handbuch für Advanced Security Incident Reporting" methodology, incorporating elements of NIST SP 800-61, SANS frameworks, and industry best practices.

Developed by webconsulting.at for the Claude skill collection.

Source: https://github.com/dirnbauer/webconsulting-skills

TYPO3 Security Incident Reporting

Compatibility: TYPO3 v14.x

>

Related Skills:

- security-incident-reporting - General incident reporting framework

- typo3-security - TYPO3 hardening

---

1. TYPO3 System Inventory

Before analyzing an incident, document the exact system state.

System Inventory Template

## TYPO3 System Inventory

### Core Information
| Field | Value |
|-------|-------|
| TYPO3 Version | 14.x (document exact patch level) |
| Release Type | LTS / Sprint / ELTS |
| Installation Method | Composer / Legacy |
| PHP Version | 8.3.12 |
| Database | MySQL 8.0 / MariaDB 10.11 / PostgreSQL 15 |

### PHP Configuration
| Setting | Value |
|---------|-------|
| memory_limit | 512M |
| max_execution_time | 240 |
| disable_functions | exec, shell_exec, system, passthru |
| allow_url_fopen | Off |
| allow_url_include | Off |

### Extensions
| Extension | Version | Source | Status |
|-----------|---------|--------|--------|
| news | 11.4.0 | TER/Packagist | Active |
| solr | 12.0.0 | Packagist | Active |
| custom_ext | 1.2.3 | Private | Active |
| [abandoned_ext] | 2.0.0 | TER | ⚠️ Abandoned |

### Security-Relevant Configuration
| Setting | Value | Expected |
|---------|-------|----------|
| BE/debug | false | false |
| SYS/displayErrors | 0 | 0 |
| SYS/trustedHostsPattern | configured | configured |
| SYS/features/security.* | enabled | enabled |

---

2. TYPO3 Vulnerability Classification

Common Vulnerability Types

TYPO3-Specific Attack Vectors

## Insecure Deserialization
- Location: Cookies, session data, mailer file spool
- Example CVE: TYPO3-CORE-SA-2026-004 (Mailer File Spool)
- Detection: Monitor `unserialize()` calls, phar:// wrappers
- Prevention: Use JSON, validate serialized data sources

## XSS in Fluid Templates
- Location: f:format.raw on user input, custom ViewHelpers
- Detection: Search for `f:format.raw` usage on dynamic content
- Prevention: Default escaping, f:format.htmlspecialchars

## SQL Injection in Extensions
- Location: Custom QueryBuilder usage, direct SQL
- Detection: DB error logs showing SQL syntax errors
- Prevention: Always use createNamedParameter()

---

3. Forensic Checklist

Phase 1: Integrity Verification

# 1. Verify TYPO3 Core Integrity (Composer Installation)
cd /var/www/html
composer install --dry-run 2>&1 | grep -i "warning\|error"

# 2. Check for modified core files
find vendor/typo3/cms-* -type f -name "*.php" -mtime -7

# 3. Verify package checksums
composer audit

# 4. Check for unexpected PHP files in public directories
find public/fileadmin public/typo3temp -name "*.php" -o -name "*.phtml"

# 5. Search for common webshell patterns
grep -r "eval\|base64_decode\|system\|exec\|shell_exec" public/fileadmin/

Phase 2: Log Analysis

## Log Sources

### TYPO3 Application Logs
| Log | Location | Content |
|-----|----------|---------|
| sys_log | Database table | Backend actions, errors |
| TYPO3 Logs | var/log/*.log | Application events |
| Deprecation | var/log/typo3_deprecations_*.log | API changes |

### Server Logs
| Log | Location | Content |
|-----|----------|---------|
| Apache Access | /var/log/apache2/access.log | HTTP requests |
| Apache Error | /var/log/apache2/error.log | PHP errors |
| Nginx Access | /var/log/nginx/access.log | HTTP requests |
| PHP-FPM | /var/log/php-fpm/*.log | PHP process errors |

### Analysis Queries

-- Suspicious backend logins SELECT * FROM sys_log WHERE type = 255 AND action = 1 AND tstamp > UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY) ORDER BY tstamp DESC;

-- Failed login attempts SELECT * FROM sys_log WHERE type = 255 AND action = 3 AND tstamp > UNIX_TIMESTAMP(NOW() - INTERVAL 24 HOUR) ORDER BY tstamp DESC;

-- Recent backend user changes SELECT * FROM be_users WHERE tstamp > UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY) OR crdate > UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY);

Phase 3: File System Analysis

# Recently modified PHP files
find /var/www/html -name "*.php" -mtime -7 -ls

# Files with suspicious permissions
find /var/www/html -type f -perm /u+x -name "*.php"

# Hidden files and directories
find /var/www/html -name ".*" -type f

# Large files in upload directories (potential dumps)
find public/fileadmin -size +10M -type f

# Check cron jobs
crontab -l
cat /etc/cron.d/*
ls -la /var/spool/cron/

Phase 4: Database Analysis

-- Check for new admin users
SELECT uid, username, admin, disable, crdate, tstamp 
FROM be_users 
WHERE admin = 1;

-- Check for suspicious content (webshells in bodytext)
SELECT uid, pid, header, bodytext 
FROM tt_content 
WHERE bodytext LIKE '%<?php%' 
   OR bodytext LIKE '%eval(%' 
   OR bodytext LIKE '%base64_decode%';

-- Check fe_users for mass creation
SELECT DATE(FROM_UNIXTIME(crdate)) as date, COUNT(*) as count 
FROM fe_users 
GROUP BY DATE(FROM_UNIXTIME(crdate)) 
ORDER BY date DESC 
LIMIT 30;

-- Verify file references
SELECT * FROM sys_file 
WHERE name LIKE '%.php%' 
   OR name LIKE '%.phtml%';

---

4. TYPO3 Security Team Communication

Policy of Least Disclosure

CRITICAL: Never discuss vulnerabilities publicly before the official advisory is released.

- No posts in Slack, StackOverflow, or forums

- Use PGP-encrypted email only

- Respect the embargo period

PGP Key Information

Import PGP Key

# From keyserver
gpg --keyserver keys.openpgp.org --recv-keys C05FBE60

# Verify fingerprint
gpg --fingerprint C05FBE60
# Should show: B41C C3EF 373E 0F5C 7018 7FE9 3BEF BD27 C05F BE60

---

5. Vulnerability Report Template

E-Mail Template for security@typo3.org

Subject: Suspected Vulnerability in [EXTENSION_NAME] - [VULNERABILITY_TYPE]
To: security@typo3.org
Encryption: PGP (Key ID: C05FBE60)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear TYPO3 Security Team,

I am writing to report a suspected security vulnerability in [COMPONENT].
In accordance with your coordinated disclosure policy, I am sharing this
information confidentially.

## 1. VULNERABILITY METADATA

| Field | Value |
|-------|-------|
| Project | [TYPO3 Core / Extension Name] |
| Affected Versions | [e.g., 11.5.0 - 11.5.24, 12.0.0 - 12.4.8] |
| Tested Version | [e.g., 12.4.8] |
| Vulnerability Type | [e.g., SQL Injection, XSS, Deserialization] |
| Severity Estimation | [e.g., High (CVSS 7.5)] |

## 2. DESCRIPTION

[Detailed description of the vulnerability. How does it work?
What is the root cause?]

Example: "The 'search' parameter in the Pi1 Controller is passed
directly to the QueryBuilder without sanitization or using
createNamedParameter(), allowing SQL injection."

## 3. PROOF OF CONCEPT (PoC)

Step-by-step instructions to reproduce:

1. Install Extension X via Composer
2. Create a page with the plugin
3. Send the following HTTP request:

GET /index.php?id=1&tx_ext_pi1[search]=' OR 1=1-- HTTP/1.1 Host: example.com

4. Observed Result: [Database error / data leakage]
5. Expected Result: [Input should be sanitized]

## 4. IMPACT

[What can an attacker achieve?]

Example: "An unauthenticated attacker can read the entire 'fe_users'
table, including password hashes and personal data, leading to
data breach and potential account takeover."

## 5. PROPOSED FIX (Optional)

[If you have a patch, describe it or attach a diff]

// Before (vulnerable) $query->where('title LIKE "' . $searchTerm . '"');

// After (fixed) $query->where( $queryBuilder->expr()->like( 'title', $queryBuilder->createNamedParameter('%' . $searchTerm . '%') ) );

## 6. REPORTER DETAILS

| Field | Value |
|-------|-------|
| Name | [Your Name] |
| Organization | [Your Company] |
| Email | [your.email@example.com] |
| PGP Key ID | [Your Key ID] |
| Credit Preference | [Named / Anonymous] |

I will adhere to the embargo until an official advisory is released.

Best regards,
[Your Name]

-----BEGIN PGP SIGNATURE-----
[Your PGP Signature]
-----END PGP SIGNATURE-----

---

6. Disclosure Process

Timeline After Reporting

Embargo Rules

• DO NOT discuss the vulnerability publicly
• DO NOT share PoC code outside the report
• DO NOT exploit the vulnerability beyond PoC
• DO respond to Security Team questions promptly
• DO test patches if requested

Core vs. Extension Responsibility

---

7. TYPO3 Security Advisory Format

Understanding Advisory IDs

TYPO3-CORE-SA-2026-004
       │    │   │   │
       │    │   │   └── Sequential number
       │    │   └────── Year
       │    └────────── Security Advisory
       └─────────────── Affected component (CORE / EXT)

Advisory Sections

---

8. Incident Response Checklist (TYPO3)

Immediate Actions (0-4 hours)

• [ ] Isolate affected TYPO3 instance
• [ ] Preserve logs (access, error, sys_log)
• [ ] Create database backup for forensics
• [ ] Document system state (inventory template)
• [ ] Check for known CVEs in installed versions

Investigation (4-24 hours)

• [ ] Run integrity verification (Phase 1)
• [ ] Analyze logs for indicators (Phase 2)
• [ ] Check filesystem for modifications (Phase 3)
• [ ] Analyze database for anomalies (Phase 4)
• [ ] Identify attack vector and timeline

Remediation (24-72 hours)

• [ ] Update TYPO3 Core to latest version
• [ ] Update all extensions
• [ ] Remove abandoned extensions
• [ ] Reset all backend user passwords
• [ ] Review and rotate API keys
• [ ] Verify file permissions
• [ ] Clear all caches

Post-Incident

• [ ] Complete incident report (SKILL.md template)
• [ ] Report vulnerability to TYPO3 Security Team if new
• [ ] Schedule post-mortem meeting
• [ ] Implement lessons learned
• [ ] Update security monitoring

---

9. Resources

TYPO3 Security

• Security Team: https://typo3.org/community/teams/security
• Security Bulletins: https://typo3.org/security/advisory
• Security Guide: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Security/
• Report Issues: security@typo3.org (PGP encrypted)

Version support

Use the official TYPO3 lifecycle and security advisories as the source of truth (dates change over time).

---

Credits & Attribution

This skill is based on the "Handbuch für Advanced Security Incident Reporting" methodology and TYPO3 Security Team guidelines.

Developed by webconsulting.at for the Claude skill collection.