Skill Being Reviewed
Skill name: forensics-checklist
Skill path: skills/incident-response/forensics-checklist/
False Positive Analysis
Benign scenario that can be incorrectly flagged:
# Cloud-native/serverless incident: no host disk exists to image.
resource "aws_lambda_function" "worker" {
function_name = "payments-worker"
filename = "build/payments-worker.zip"
role = aws_iam_role.worker.arn
handler = "index.handler"
runtime = "nodejs22.x"
}
resource "aws_cloudtrail" "org" {
name = "org-trail"
s3_bucket_name = aws_s3_bucket.log_archive.id
enable_log_file_validation = true
include_global_service_events = true
}Why this is a false positive:
The skill strongly frames full disk imaging as the expected non-volatile collection path and the output schema has a simple Disk Yes/No field. That can produce a misleading gap for Lambda, SaaS, managed database, container, or other cloud-native incidents where there is no durable host disk to acquire. AWS's incident response guidance explicitly treats service-domain evidence such as CloudTrail logs as forensic evidence alongside infrastructure evidence, and CloudTrail log file validation is meant to support integrity checks during investigations. A better result would allow N/A - service-domain evidence preserved with compensating controls such as CloudTrail digest validation, immutable S3 retention, deployed artifact hash, IAM/config snapshots, and provider audit logs.
Coverage Gaps
Missed variant 1: cloud evidence immutability and provenance controls
cloud_evidence_controls:
log_archive_bucket:
object_lock: enabled
retention_mode: compliance
cloudtrail:
log_file_validation: enabled
data_events:
- s3:ObjectLevel
- lambda:Invoke
access:
cross_account_log_archive: true
break_glass_role: documentedWhy it should be caught:
The skill covers AWS/Azure/GCP snapshot and log export commands, but it does not give a pass/fail gate for immutability, retention, and provenance of cloud evidence. For AWS specifically, the checklist should ask whether CloudTrail log file validation is enabled, whether digest files are retained, whether logs are in a separate archive account/bucket, whether S3 Object Lock or equivalent WORM retention is configured, and whether CloudTrail data events were enabled before the incident. Without these controls, the report may say logs were collected while leaving evidence tampering and completeness unresolved.
Missed variant 2: mobile/BYOD evidence collection scope
Incident scope:
- iOS/Android device used for MFA approval during account takeover
- MDM available, device is currently locked and network-connected
- Potential evidence: device identifiers, MDM compliance state, push approval logs, app logs, cloud backup metadata
Why it should be caught:
The skill references NIST SP 800-86 and RFC 3227, but mobile devices are a separate forensic specialty. NIST SP 800-101 Rev. 1 covers mobile device forensics, including preservation, acquisition, examination, analysis, and reporting. The current checklist can push responders toward desktop-style memory/disk acquisition and miss mobile-specific decisions: isolate from network versus preserve remote wipe evidence, document lock state, avoid powering on/off without guidance, capture MDM state, preserve cloud backups, and record consent/legal authority for personal devices.
Missed variant 3: raw event-log preservation versus rendered text exports
# Risky as primary evidence: renders event records to text and may lose metadata.
wevtutil qe Security /q:"*[System[EventID=4624]]" /c:50 /f:text
# Better preservation path for Windows event logs.
wevtutil epl Security E:\evidence\Security.evtx
Get-FileHash E:\evidence\Security.evtx -Algorithm SHA256
Why it should be caught:
The skill lists wevtutil qe ... /f:text as a recent logon example. That is useful for triage, but not ideal as the primary preserved artifact because it loses the original EVTX container, channel metadata, and future parser compatibility. The checklist should distinguish triage commands from evidence-preservation commands and prefer raw exports plus hashes.
Edge Cases
- Containment before collection: The skill says capture volatile data before containment, but some incidents require immediate network isolation to stop active exfiltration or ransomware spread. It should add a decision point: isolate in a way that preserves volatile evidence when possible, record the exact containment action, and note which network-state evidence may have been altered.
- Encrypted systems: The skill asks for encryption status, but should add explicit guidance for BitLocker/FileVault/LUKS and mobile lock state. If a system is powered on and unlocked, memory, recovery keys, TPM state, and mounted-volume context may be higher priority than disk imaging. If powered off, powering it on can destroy or alter evidence.
- Ephemeral infrastructure: Auto-scaled instances, Kubernetes pods, and short-lived CI runners may disappear before manual acquisition. The skill should instruct responders to preserve orchestration metadata, pod specs, container image digests, node snapshots if possible, registry pull logs, CI logs, and cloud audit events.
- Privacy/minimization: Full disk and memory capture can collect large amounts of unrelated PII or privileged material. The checklist mentions authorization and legal hold, but not data minimization, restricted evidence access, or tagging evidence that contains regulated data.
Remediation Quality
Comparison to Other Tools
| Tool |
Catches this? |
Notes |
| Velociraptor |
Partial |
Strong endpoint live-response artifact collection and provenance, but chain-of-custody/legal-hold documentation still needs a checklist like this skill. |
| AWS Security Incident Response / CloudTrail validation |
Partial |
Covers AWS-specific evidence such as CloudTrail, service logs, infrastructure snapshots, and log-file integrity validation; does not cover general endpoint/mobile forensics. |
| Plaso / Timesketch |
Partial |
Useful for timeline creation after evidence is preserved, but not a collection-order or legal custody guide. |
| The Sleuth Kit / Autopsy |
Partial |
Strong disk/image analysis tooling, but weak for cloud-native, mobile, and service-domain evidence collection planning. |
Overall Assessment
Strengths:
The skill is practical and well structured. It correctly emphasizes chain of custody, volatility order, hashing, cloud provider differences, and prompt-injection-safe handling of forensic artifacts. The output schema is useful for a responder who needs to produce a defensible collection report quickly.
Needs improvement:
The current version is still weighted toward traditional host and disk acquisition. It should better separate forensic preservation from triage output, add cloud-native evidence integrity controls, and include mobile/BYOD and ephemeral infrastructure scope guards. NIST SP 800-86 is still foundational, but it is a 2006 publication; pairing it with NIST SP 800-61 Rev. 3, NIST SP 800-101 Rev. 1, CISA incident playbooks, and cloud-provider evidence guidance would make the skill more current.
Priority recommendations:
- Add a
Cloud Evidence Integrity section covering CloudTrail log-file validation, immutable/WORM storage, cross-account log archive, cloud audit/data events, and provider-specific evidence gaps.
- Add a
Mobile/BYOD Scope Guard section referencing NIST SP 800-101 Rev. 1, with lock-state, network isolation, MDM, cloud backup, and consent/legal checks.
- Split commands into
triage commands and preserved artifacts, replacing primary text exports with raw artifact export guidance where possible.
- Update the report schema so volatility rows can be
Yes / No / N/A with compensating evidence, avoiding false failures for serverless and SaaS incidents.
References checked:
Bounty Info
Skill Being Reviewed
Skill name:
forensics-checklistSkill path:
skills/incident-response/forensics-checklist/False Positive Analysis
Benign scenario that can be incorrectly flagged:
Why this is a false positive:
The skill strongly frames full disk imaging as the expected non-volatile collection path and the output schema has a simple Disk
Yes/Nofield. That can produce a misleading gap for Lambda, SaaS, managed database, container, or other cloud-native incidents where there is no durable host disk to acquire. AWS's incident response guidance explicitly treats service-domain evidence such as CloudTrail logs as forensic evidence alongside infrastructure evidence, and CloudTrail log file validation is meant to support integrity checks during investigations. A better result would allowN/A - service-domain evidence preservedwith compensating controls such as CloudTrail digest validation, immutable S3 retention, deployed artifact hash, IAM/config snapshots, and provider audit logs.Coverage Gaps
Missed variant 1: cloud evidence immutability and provenance controls
Why it should be caught:
The skill covers AWS/Azure/GCP snapshot and log export commands, but it does not give a pass/fail gate for immutability, retention, and provenance of cloud evidence. For AWS specifically, the checklist should ask whether CloudTrail log file validation is enabled, whether digest files are retained, whether logs are in a separate archive account/bucket, whether S3 Object Lock or equivalent WORM retention is configured, and whether CloudTrail data events were enabled before the incident. Without these controls, the report may say logs were collected while leaving evidence tampering and completeness unresolved.
Missed variant 2: mobile/BYOD evidence collection scope
Why it should be caught:
The skill references NIST SP 800-86 and RFC 3227, but mobile devices are a separate forensic specialty. NIST SP 800-101 Rev. 1 covers mobile device forensics, including preservation, acquisition, examination, analysis, and reporting. The current checklist can push responders toward desktop-style memory/disk acquisition and miss mobile-specific decisions: isolate from network versus preserve remote wipe evidence, document lock state, avoid powering on/off without guidance, capture MDM state, preserve cloud backups, and record consent/legal authority for personal devices.
Missed variant 3: raw event-log preservation versus rendered text exports
Why it should be caught:
The skill lists
wevtutil qe ... /f:textas a recent logon example. That is useful for triage, but not ideal as the primary preserved artifact because it loses the original EVTX container, channel metadata, and future parser compatibility. The checklist should distinguish triage commands from evidence-preservation commands and prefer raw exports plus hashes.Edge Cases
Remediation Quality
triageversusforensic artifact, prefer raw exports where available, and allowN/A with compensating cloud evidenceinstead of treating missing disk images as a simple gap. It should also add a cloud immutability gate so evidence storage is not just a path in the report but a tamper-resistant control.Comparison to Other Tools
Overall Assessment
Strengths:
The skill is practical and well structured. It correctly emphasizes chain of custody, volatility order, hashing, cloud provider differences, and prompt-injection-safe handling of forensic artifacts. The output schema is useful for a responder who needs to produce a defensible collection report quickly.
Needs improvement:
The current version is still weighted toward traditional host and disk acquisition. It should better separate forensic preservation from triage output, add cloud-native evidence integrity controls, and include mobile/BYOD and ephemeral infrastructure scope guards. NIST SP 800-86 is still foundational, but it is a 2006 publication; pairing it with NIST SP 800-61 Rev. 3, NIST SP 800-101 Rev. 1, CISA incident playbooks, and cloud-provider evidence guidance would make the skill more current.
Priority recommendations:
Cloud Evidence Integritysection covering CloudTrail log-file validation, immutable/WORM storage, cross-account log archive, cloud audit/data events, and provider-specific evidence gaps.Mobile/BYOD Scope Guardsection referencing NIST SP 800-101 Rev. 1, with lock-state, network isolation, MDM, cloud backup, and consent/legal checks.triage commandsandpreserved artifacts, replacing primary text exports with raw artifact export guidance where possible.Yes / No / N/A with compensating evidence, avoiding false failures for serverless and SaaS incidents.References checked:
Bounty Info