[REVIEW] forensics-checklist: add FVE recovery-key escrow and imaging feasibility gates
Skill Being Reviewed
Skill name: forensics-checklist
Skill path: skills/incident-response/forensics-checklist/
False Positive Analysis
Benign-looking collection plan that can be incorrectly scored as forensically complete:
## Evidence Collection Plan — LAPTOP-HR-119
- Step 4 (Disk): Image internal SSD with FTK Imager after volatile capture
- Encryption status: BitLocker enabled
- Recovery key: "available in IT portal"
- Authorization: HR manager email approval
- Expected outcome: Full disk image acquired tonight
Why this is a false positive:
The skill lists encryption status as context to gather, but does not require proof that a valid recovery key or escrowed credential is obtainable before promising disk imaging. "Available in IT portal" is not evidence. Many incidents fail at acquisition because the key is stored on the same device, tied to a user-only Entra ID profile, missing from escrow, or requires a TPM+PIN that cannot be satisfied offline. The plan can look complete while the least-volatile evidence source (disk) is practically unreachable.
Coverage Gaps
Missed variant 1: BitLocker with TPM-only protector and live session required
manage-bde -protectors -get C:
# Numerical Password protector: None
# TPM protector: ID {....}
# Recovery Password: None on deviceWhy it should be caught: Without a recovery password in escrow, offline imaging of powered-off media is impossible. The skill should require a branch: powered-on volatile capture first, then live logical imaging or memory capture before shutdown, rather than defaulting to offline full-disk imaging.
Missed variant 2: Recovery key stored only in user's personal cloud account
Intune/Entra escrow: not found for device LAPTOP-HR-119
User OneDrive note: "BitLocker key backup" — inaccessible because account disabled during containment
Why it should be caught: Containment often disables accounts before acquisition planning finishes. The skill should gate imaging feasibility on key custody independent of the compromised user session.
Missed variant 3: Cloud-managed encryption without exportable volume key
{
"platform": "AWS EC2",
"volume_encryption": "AES-256 via AWS KMS",
"snapshot_created": true,
"kms_key_policy_allows_forensics_role": false
}Why it should be caught: Step 6 cloud guidance mentions snapshots, but does not require KMS/key-policy evidence that the forensic account can decrypt or copy the snapshot. A snapshot without decrypt capability produces a false sense of acquisition completeness.
Edge Cases
- FileVault with unknown iCloud recovery eligibility: Mobile Mac acquisitions may lack institutional escrow; skill should branch to live triage or Apple API/legal process path.
- LUKS with clevis/Tang network unlock: Powered-off imaging fails if network unlock is blocked during containment.
- Partial volume encryption: Data partition encrypted, recovery partition not; imaging plan must identify which segments are readable.
- Legal hold vs key rotation: Escrow systems may rotate keys after incident start; hash and key version must be bound at collection time.
Remediation Quality
Comparison to Other Tools
| Tool |
Catches this? |
Notes |
| NIST SP 800-86 guidance |
Partial |
Covers encryption challenges conceptually; skill should operationalize them |
| Magnet AXIOM / FTK workflows |
Partial |
Tools surface unlock blockers, but skill text does not require the check |
| Semgrep/CodeQL |
No |
Not applicable |
Overall Assessment
Strengths: Excellent RFC 3227 volatility ordering, strong chain-of-custody template, and practical cloud snapshot guidance.
Needs improvement: Encryption is treated as metadata, not as a go/no-go gate. Failed key escrow is a common real-world blocker that can waste containment timing and destroy volatile evidence.
Priority recommendations:
- Add
FVE-ESCROW-01 checklist: prove recovery key ID, storage location, accessor role, and successful test unlock or decrypt before scheduling powered-off imaging.
- Add powered-on branch for TPM-only/FileVault-no-escrow devices: memory + logical collection before shutdown.
- For cloud snapshots, require KMS/grant evidence and copied-encrypted snapshot hash before marking disk evidence complete.
Bounty Info
[REVIEW] forensics-checklist: add FVE recovery-key escrow and imaging feasibility gates
Skill Being Reviewed
Skill name:
forensics-checklistSkill path:
skills/incident-response/forensics-checklist/False Positive Analysis
Benign-looking collection plan that can be incorrectly scored as forensically complete:
Why this is a false positive:
The skill lists encryption status as context to gather, but does not require proof that a valid recovery key or escrowed credential is obtainable before promising disk imaging. "Available in IT portal" is not evidence. Many incidents fail at acquisition because the key is stored on the same device, tied to a user-only Entra ID profile, missing from escrow, or requires a TPM+PIN that cannot be satisfied offline. The plan can look complete while the least-volatile evidence source (disk) is practically unreachable.
Coverage Gaps
Missed variant 1: BitLocker with TPM-only protector and live session required
Why it should be caught: Without a recovery password in escrow, offline imaging of powered-off media is impossible. The skill should require a branch: powered-on volatile capture first, then live logical imaging or memory capture before shutdown, rather than defaulting to offline full-disk imaging.
Missed variant 2: Recovery key stored only in user's personal cloud account
Why it should be caught: Containment often disables accounts before acquisition planning finishes. The skill should gate imaging feasibility on key custody independent of the compromised user session.
Missed variant 3: Cloud-managed encryption without exportable volume key
{ "platform": "AWS EC2", "volume_encryption": "AES-256 via AWS KMS", "snapshot_created": true, "kms_key_policy_allows_forensics_role": false }Why it should be caught: Step 6 cloud guidance mentions snapshots, but does not require KMS/key-policy evidence that the forensic account can decrypt or copy the snapshot. A snapshot without decrypt capability produces a false sense of acquisition completeness.
Edge Cases
Remediation Quality
Comparison to Other Tools
Overall Assessment
Strengths: Excellent RFC 3227 volatility ordering, strong chain-of-custody template, and practical cloud snapshot guidance.
Needs improvement: Encryption is treated as metadata, not as a go/no-go gate. Failed key escrow is a common real-world blocker that can waste containment timing and destroy volatile evidence.
Priority recommendations:
FVE-ESCROW-01checklist: prove recovery key ID, storage location, accessor role, and successful test unlock or decrypt before scheduling powered-off imaging.Bounty Info