| name | forensic-intrusion-analysis |
| description | Forensic intrusion analysis combining application logs with source code review. Use when analyzing security incidents, investigating suspicious activity, or producing incident reports. |
| license | MIT |
| metadata | {"author":"SocialGouv","version":"1.0.0"} |
Forensic Intrusion Analysis
Forensic intrusion analysis methodology that cross-references two sources of truth: application logs and deployed source code. Log analysis alone systematically produces false positives. Source code review is essential to distinguish a real vulnerability from a log artifact.
When to Apply
Use this skill when:
- Analyzing application logs after a security incident
- Investigating suspicious user activity or unauthorized access
- Producing a post-mortem security report
- Reviewing an existing intrusion analysis for accuracy
- Determining whether observed log patterns indicate real vulnerabilities
This skill is NOT for: penetration testing, vulnerability scanning, or proactive security auditing (use dedicated tools for those).
Core Principle
Never conclude from logs alone. Every claim about a vulnerability, a successful attack, or an impact level must be verified against the source code. A log entry saying sql_query failed is not proof of SQL injection — it may be an ORM type error. A 200 OK on a sensitive endpoint is not proof of unauthorized access — the endpoint may have proper guards.
Methodology Overview
The analysis follows four sequential phases:
Phase 1: Log Extraction → Raw data collection
Phase 2: Log Analysis → Timeline, patterns, initial hypotheses
Phase 3: Source Code Challenge → Verify/refute each hypothesis against code
Phase 4: Amended Report → Accurate, evidence-based conclusions
Phase 1 — Log Extraction
Grafana/Loki
Use the extraction script provided in scripts/forensic-log-extract.sh. Configure via environment variables:
export GRAFANA_URL="https://grafana.example.com"
export GRAFANA_TOKEN="Bearer glsa_xxxx"
export LOKI_DATASOURCE_UID="your-loki-uid"
export LOGQL_QUERY='{app="your-backend-api"}'
export START_TIME="2026-03-17T09:00:00Z"
export END_TIME="2026-03-17T12:00:00Z"
./scripts/forensic-log-extract.sh
Other log sources
| Source | Command |
|---|
| Loki direct | curl "${LOKI_URL}/loki/api/v1/query_range?query={app='api'}&start=...&end=...&limit=5000&direction=forward" |
| Kubernetes | kubectl logs -n prod deploy/api --since-time="2026-03-17T09:00:00Z" > logs.jsonl |
| Docker | docker logs api --since "2026-03-17T09:00:00" --until "2026-03-17T12:00:00" > logs.jsonl |
| CloudWatch | aws logs filter-log-events --log-group-name /ecs/api --start-time $EPOCH_MS --end-time $EPOCH_MS |
| Files | jq -c 'select(.timestamp >= "2026-03-17T09:00:00")' /var/log/api/*.jsonl > logs.jsonl |
Log requirements
For this methodology to work, logs must include at minimum:
- Timestamp (ISO 8601 or epoch)
- HTTP method and URL (with path parameters)
- HTTP status code
- Authenticated user identifier (userId, sessionId)
- Client IP and ideally User-Agent
Bonus fields that significantly help: request body (for POST/PATCH), response body or message, error stack traces.
Phase 2 — Log Analysis (First Pass)
Statistical profiling, timeline construction, and attack typology cataloging. Do not assign severity yet — logs alone are misleading.
Read detailed instructions: reference/phase-2-log-analysis.md
Phase 3 — Source Code Confrontation (Second Pass)
The decisive phase. Every claim from Phase 2 must be verified against the source code. Includes endpoint verification checklist, common false-positive patterns, and key questions to resolve for each attack.
Read detailed instructions: reference/phase-3-source-code.md
Phase 4 — Amended Report
Produce the final evidence-based report with reclassified severities, report structure template, writing rules, and final checklist.
Read detailed instructions: reference/phase-4-report.md
