Skip to content

Improve forensic cloud and mobile preservation gates #1375

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
MAUROCERON wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Improve forensic cloud and mobile preservation gates #1375

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
151 changes: 137 additions & 14 deletions skills/incident-response/forensics-checklist/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,9 @@ Before beginning evidence collection, gather or confirm:
- [ ] **Evidence storage** -- Write-protected storage media available (forensic drives, NAS, S3 bucket with object lock).
- [ ] **Forensic tools available** -- Memory capture (WinPmem, LiME, DumpIt), disk imaging (dc3dd, FTK Imager, ewfacquire), network capture (tcpdump, Wireshark).
- [ ] **Cloud provider access** -- IAM permissions for snapshot creation, log export, and API access (if cloud environment).
- [ ] **Cloud evidence integrity controls** -- CloudTrail/Audit Logs validation, immutable/WORM retention, separate log archive account or project, data-event coverage, and deployed artifact hash evidence.
- [ ] **Mobile/BYOD scope** -- Device ownership, legal authority/consent, lock state, MDM enrollment, network state, cloud backup availability, and remote-wipe risk.
- [ ] **Preservation versus triage outputs** -- Which commands create preserved raw artifacts and which commands are only triage views.
- [ ] **Time synchronization** -- NTP configuration of affected systems; UTC timestamps preferred.
- [ ] **Encryption status** -- BitLocker, LUKS, FileVault, or cloud-managed encryption on affected volumes.

Expand Down Expand Up @@ -115,7 +118,24 @@ RFC 3227 Section 2.1 defines the order of volatility -- evidence sources ranked
| 6 | **Physical configuration, network topology** | Stable | Changes with infrastructure modifications | Network diagrams, switch/router configs, CMDB |
| 7 | **Archival media** | Long-term | Stable unless damaged or degaussed | Tape backups, offline backups, cold storage |

### Step 3: Volatile Data Capture
### Step 3: Containment Versus Collection Decision

Before collecting volatile data, decide whether immediate containment is needed
to stop active harm. Volatile-first collection is preferred, but ransomware,
active exfiltration, destructive activity, or remote wipe risk can justify
isolation before full acquisition.

Record the decision:

- Containment action taken, exact UTC time, actor, and authorization.
- Evidence changed by containment, such as network connections, remote sessions,
cloud access paths, mobile network state, or process state.
- Evidence preserved before containment and evidence made unavailable by
containment.
- Compensating evidence, such as network telemetry, EDR timeline, cloud audit
events, or MDM logs.

### Step 4: Volatile Data Capture

Capture volatile data BEFORE any containment action that would alter system state (network isolation may be acceptable; reboot, shutdown, or reimaging destroys volatile evidence).

Expand Down Expand Up @@ -194,8 +214,13 @@ listdlls.exe (Windows, Sysinternals) / cat /proc/[pid]/maps (Linux)
# Logged-in users
query user (Windows) / w (Linux)

# Recent logon events
wevtutil qe Security /q:"*[System[EventID=4624]]" /c:50 /f:text (Windows)
# Recent logon events for triage view only
wevtutil qe Security /q:"*[System[EventID=4624]]" /c:50 /f:text (Windows, triage)

# Preserve raw Windows event log artifact before relying on rendered text
wevtutil epl Security E:\evidence\[hostname]_Security_[YYYYMMDD].evtx (Windows, preserved artifact)
certutil -hashfile E:\evidence\[hostname]_Security_[YYYYMMDD].evtx SHA256

last -50 (Linux)

# Scheduled tasks / cron jobs
Expand All @@ -217,7 +242,7 @@ ls -latr /tmp /var/tmp /dev/shm
# Linux: Identify swap partitions with 'swapon --show' and image them
```

### Step 4: Non-Volatile Data Capture (Disk Imaging)
### Step 5: Non-Volatile Data Capture (Disk Imaging)

Create a forensically sound disk image -- a bit-for-bit copy that preserves all data including deleted files, slack space, and unallocated areas.

Expand Down Expand Up @@ -263,7 +288,13 @@ Evidence Integrity Record:
- Imaging End Time: [YYYY-MM-DD HH:MM UTC]
```

### Step 5: Log Preservation
If the incident scope is serverless, SaaS, managed database, mobile-only, or
another service-domain case where no host disk exists, mark disk collection as
`N/A with compensating evidence`. Preserve service logs, deployed artifact
hashes, IAM/config snapshots, provider audit logs, and immutable storage
evidence instead of forcing a false disk-imaging gap.

### Step 6: Log Preservation

Preserve logs before rotation policies destroy them. Export and hash logs from each source.

Expand All @@ -283,13 +314,26 @@ Preserve logs before rotation policies destroy them. Export and hash logs from e

**Log export procedure:**
```
1. Export raw logs to write-protected storage
1. Export raw logs or native containers to write-protected storage
2. Compute SHA-256 hash of each exported log file
3. Document: source, time range, export method, hash value
4. Store alongside disk and memory evidence in the case folder
```

### Step 6: Cloud Forensics
Prefer native or raw log artifacts for preservation:

| Platform | Preserved Artifact | Triage View Only |
|----------|-------------------|------------------|
| Windows | `.evtx` exported with `wevtutil epl` | `wevtutil qe ... /f:text` |
| Linux | copied log file/journal export with hash | `tail`, `grep`, rendered snippets |
| CloudTrail | S3 log objects plus digest files | `lookup-events` result only |
| SIEM | vendor export with event IDs and metadata | dashboard screenshot only |

Rendered text, dashboard screenshots, and filtered queries are useful for
triage, but they should not be the only preserved artifact when a raw or native
container export is available.

### Step 7: Cloud Forensics

Cloud environments require different acquisition techniques because direct hardware access is not available.

Expand Down Expand Up @@ -339,6 +383,46 @@ gcloud logging read 'timestamp>="YYYY-MM-DDT00:00:00Z" AND timestamp<="YYYY-MM-D
- Multi-region deployments require evidence collection across all regions
- Serverless environments (Lambda, Cloud Functions) produce only invocation logs -- there is no disk to image

#### Cloud Evidence Integrity Gate

For cloud-native, serverless, managed service, and SaaS investigations, verify
that service-domain evidence has integrity, immutability, and provenance:

| Evidence Control | What to Verify | Example Evidence |
|------------------|----------------|------------------|
| Log validation | Provider log integrity validation enabled and digest files retained | CloudTrail log file validation and digest chain |
| Immutable retention | WORM/Object Lock or equivalent retention configured | S3 Object Lock compliance mode, legal hold, retention date |
| Separate archive boundary | Logs stored outside the affected account/project/subscription where possible | security log archive account, restricted bucket policy |
| Data-event coverage | Data-plane events were enabled before incident scope | S3 object-level events, Lambda invoke events, audit data access logs |
| Artifact provenance | Deployed code/image/config can be tied to digest and release evidence | Lambda zip hash, container image digest, IaC state/export |
| Access trail | Break-glass, support, and responder access was logged | IAM role session logs, access approvals, ticket ID |

If any control is missing, report the evidence confidence as `Low` or
`Not Evaluable` instead of simply marking logs as collected.

### Step 8: Mobile and BYOD Evidence Scope

Mobile devices require a separate preservation decision path, especially when a
device was used for MFA approval, push notifications, messaging, or cloud
account access.

Record:

- Device owner and legal authority/consent, especially for BYOD or personal
devices.
- Device state: powered on/off, locked/unlocked, network-connected, battery
level, remote-wipe risk, and whether isolation was performed.
- MDM evidence: device identifiers, compliance state, installed apps, profiles,
jailbreak/root indicators, last check-in, and remote command history.
- Cloud and service evidence: backup metadata, push approval logs, identity
provider events, messaging app export availability, and provider audit logs.
- Acquisition decision: logical, file-system, cloud-backup, MDM-only, or not
authorized; include tool/version and hash where artifacts are exported.

Do not power on/off or unlock a device without examiner guidance. Record why a
mobile device is out of scope or `N/A` when only cloud-side MFA/provider logs are
legally collectable.

---

## 4. Findings Classification
Expand Down Expand Up @@ -379,11 +463,11 @@ the order of collection, and any evidence that could not be obtained.]
| RFC 3227 Priority | Evidence Source | Collected | Notes |
|---|---|---|---|
| 1 | Registers/cache | [Yes/No/N/A] | [Notes] |
| 2 | Routing/ARP/process table/memory | [Yes/No] | [Notes] |
| 3 | Temporary file systems | [Yes/No] | [Notes] |
| 4 | Disk | [Yes/No] | [Notes] |
| 5 | Remote logging data | [Yes/No] | [Notes] |
| 6 | Physical configuration | [Yes/No] | [Notes] |
| 2 | Routing/ARP/process table/memory | [Yes/No/N/A with compensating evidence] | [Notes] |
| 3 | Temporary file systems | [Yes/No/N/A with compensating evidence] | [Notes] |
| 4 | Disk | [Yes/No/N/A with compensating evidence] | [Notes] |
| 5 | Remote logging data | [Yes/No/N/A with compensating evidence] | [Notes] |
| 6 | Physical configuration | [Yes/No/N/A with compensating evidence] | [Notes] |
| 7 | Archival media | [Yes/No/N/A] | [Notes] |

### Chain of Custody
Expand All @@ -398,9 +482,20 @@ the order of collection, and any evidence that could not be obtained.]
[List any evidence that could not be collected and the reason]

### Cloud Evidence (if applicable)
| Cloud Provider | Resource | Evidence Type | Collected | Notes |
| Cloud Provider | Resource | Evidence Type | Collected | Integrity / Immutability | Notes |
|---|---|---|---|---|---|
| [AWS/Azure/GCP] | [Resource ID] | [Snapshot/Logs/Config] | [Yes/No/N/A with compensating evidence] | [Digest/Object Lock/archive account/etc.] | [Notes] |

### Preservation Versus Triage Outputs
| Artifact | Preserved Evidence? | Triage View? | Hash / Provenance | Notes |
|---|---|---|---|---|
| [AWS/Azure/GCP] | [Resource ID] | [Snapshot/Logs/Config] | [Yes/No] | [Notes] |
| [Security.evtx] | Yes | No | SHA-256: [hash] | Raw event log export |
| [wevtutil text output] | No | Yes | N/A | Used only to scope preserved event ranges |

### Mobile / BYOD Evidence (if applicable)
| Device | Ownership | Lock / Network State | MDM / Cloud Evidence | Acquisition Decision | Legal Basis |
|---|---|---|---|---|---|
| [device id] | [corporate/BYOD/unknown] | [state] | [logs/backups/MDM] | [logical/cloud/MDM-only/N/A] | [authorization] |
```

---
Expand Down Expand Up @@ -461,6 +556,28 @@ Applying traditional forensic methods to cloud environments without adaptation l

Every action on a live system modifies it -- writing memory dump files to the evidence drive changes timestamps and consumes disk space, running commands updates shell history and modifies access times. Minimize evidence contamination by writing collection output to external media (USB, network share, S3 bucket), documenting every command executed on the system, and noting the expected impact of each collection action on the evidence state.

### Pitfall 6: Treating Triage Text as Preserved Evidence

Rendered text output from a command or dashboard can help decide where to look,
but it may omit original event metadata, channel context, signatures, parser
compatibility, or provider digest links. Preserve raw or native artifacts where
possible, then use rendered views for analysis.

### Pitfall 7: Marking Serverless or SaaS Incidents as Disk Gaps

Some incidents have no host disk to image. For Lambda, Cloud Functions, managed
databases, SaaS, and similar systems, the defensible path is service-domain
evidence: immutable logs, deployed artifact hashes, configuration snapshots,
identity events, and provider audit trails. Record `N/A with compensating
evidence` rather than a misleading disk-imaging failure.

### Pitfall 8: Applying Desktop Forensics Assumptions to Mobile/BYOD

Mobile lock state, remote wipe risk, cloud backups, MDM telemetry, and consent
constraints can determine what evidence is legally and technically collectable.
Avoid powering devices on/off or changing network state without documenting the
decision and expected evidence impact.

---

## 8. Prompt Injection Safety Notice
Expand All @@ -487,3 +604,9 @@ This skill processes forensic artifacts, log files, memory dumps, and system con
8. **ACSC Digital Forensics Guide** -- https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/publications/digital-forensics
9. **SWGDE Best Practices for Computer Forensics** -- https://www.swgde.org/documents
10. **AWS Security Incident Response Guide** -- https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/
11. **NIST SP 800-101 Rev. 1** -- Guidelines on Mobile Device Forensics -- https://csrc.nist.gov/pubs/sp/800/101/r1/final
12. **NIST SP 800-61 Rev. 3** -- Incident Response Recommendations and Considerations for Cybersecurity Risk Management -- https://csrc.nist.gov/pubs/sp/800/61/r3/final
13. **AWS Collect and Analyze Forensic Evidence** -- https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/collect-analyze-forensic-evidence.html
14. **AWS CloudTrail Log File Validation** -- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html
15. **Amazon S3 Object Lock** -- https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
16. **CISA Incident and Vulnerability Response Playbooks** -- https://www.cisa.gov/news-events/news/incident-and-vulnerability-response-playbooks
103 changes: 103 additions & 0 deletions ...dent-response/forensics-checklist/tests/cloud-mobile-preservation-edge-cases.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,103 @@
# Cloud, Mobile, And Raw Preservation Edge Cases

Use these cases to verify that `forensics-checklist` distinguishes forensic
preservation from triage views and handles cloud-native or mobile evidence
without forcing inappropriate disk-imaging failures.

## False Positive Guard: Serverless Incident With Compensating Evidence

```yaml
incident_scope:
service: aws_lambda
host_disk_available: false
cloud_evidence:
cloudtrail_log_file_validation: enabled
digest_files_retained: true
log_archive_bucket:
separate_account: true
object_lock: compliance
data_events:
lambda_invoke: enabled_before_incident
deployed_artifact:
zip_sha256: recorded
release_commit: recorded
```

Expected outcome: Disk collection is `N/A with compensating evidence`, not a
failure. Evidence confidence is high when logs, digests, archive controls, and
artifact provenance are present.

## Missed Variant: Cloud Logs Collected Without Immutability

```yaml
cloud_evidence:
cloudtrail_lookup_events_exported: true
log_file_validation: disabled
digest_files_retained: false
archive_bucket_same_account: true
object_lock: disabled
data_events:
s3_object_level: disabled
```

Expected outcome: Medium or High evidence-quality gap. Do not claim strong
forensic integrity just because logs were exported.

## Missed Variant: Rendered Windows Event Text Used As Primary Evidence

```yaml
triage_command:
command: wevtutil qe Security /q:"*[System[EventID=4624]]" /c:50 /f:text
preserved_artifact:
evtx_export: missing
sha256_hash: missing
impact:
original_channel_metadata_lost: true
```

Expected outcome: Evidence preservation gap. Text output is useful for triage,
but the primary artifact should be raw `.evtx` export with a hash when
available.

## Missed Variant: Mobile MFA Device In Scope

```yaml
incident_scope:
identity_takeover: true
mobile_device_used_for_mfa: true
device:
ownership: byod
lock_state: locked
network_state: connected
remote_wipe_risk: unknown
evidence_available:
mdm_last_checkin: present
push_approval_logs: present
cloud_backup_metadata: unknown
legal:
consent: missing
```

Expected outcome: Not Evaluable or scoped mobile evidence plan. Require legal
authority/consent, lock/network-state documentation, MDM/provider logs, and a
clear decision not to power on/off or alter the device without examiner
guidance.

## Missed Variant: Containment Alters Volatile Evidence

```yaml
containment:
action: isolate_host_from_network
time_utc: 2026-06-06T10:15:00Z
reason: active_exfiltration
pre_containment_collection:
memory: not_collected
active_connections: not_collected
compensating_evidence:
edr_network_timeline: present
firewall_session_logs: present
```

Expected outcome: Documented containment-versus-collection tradeoff. The report
should record which volatile evidence was altered and which compensating
telemetry preserves the investigative path.