forensic-intrusion-analysis

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