disk-forensics
Skill489 starsChanged 5 days agoMITView on GitHub
Analyze disk images, file systems, and memory captures for digital evidence recovery in forensic investigations and CTF challenges. Use when the user mentions 'disk forensics,' 'forensic analysis,' 'disk image,' 'file carving,' 'deleted files,' 'evidence recovery,' 'timeline analysis,' 'memory forensics,' 'volatility,' 'autopsy,' 'sleuthkit,' 'plaso,' 'log2timeline,' 'artifact analysis,' 'chain of custody,' or needs to examine a forensic image.
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 7 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Before analyzing any image, confirm:
- Distinctive: line 20
If lawful basis is unclear, ask before proceeding.
- Distinctive: line 24
Always work on copies, never originals
- Distinctive: line 25
Verify image integrity with hash comparison before analysis
- Distinctive: line 27
Document every command and finding
- Very specific: line 75
Deleted files: Use fls to find (marked with *), icat to extract by inode.
- Very specific: line 77
File carving: Run foremost or scalpel on unallocated space to recover files by header signatures.
- Very specific: line 82
Check image files for steganography: exiftool, binwalk, steghide
- Very specific: line 99
Use mactime (Sleuth Kit) to generate a unified timeline from body files.
- Very specific: line 107
Use bulk_extractor for automated extraction of emails, URLs, credit card numbers, and other structured data.
- Distinctive: line 156
Document chain of custody for real investigations
- Distinctive: line 158
Never modify evidence or suggest evidence tampering
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Disk Forensics — Digital Evidence Analysis
Analyze disk images and file systems to recover evidence, reconstruct timelines, and identify artifacts.
Cross-references: incident-triage for the upstream containment phase that captures the image this skill analyzes — that skill makes the bit-for-bit copy; this skill analyzes it. breach-patterns for translating the forensic findings into preemptive controls so the same root cause doesn't recur. malware-triage for files recovered from the image that need a verdict.
Authorization Check
Before analyzing any image, confirm:
- Lawful basis — the user has authorization for this analysis (internal investigation with documented scope, court-ordered work, signed IR engagement, your own system, CTF / lab environment)
- Chain of custody is preserved — the image and its hashes were captured in a way that survives evidentiary scrutiny, OR the scope is explicitly non-evidentiary (CTF, internal triage where chain-of-custody is not the goal)
- Privacy scope — the analysis stays within what was authorized; personal data outside the scope is not pulled, analyzed, or reported
If lawful basis is unclear, ask before proceeding. Never analyze an image you cannot confirm the user is authorized to possess.
Evidence Handling Principles
- Always work on copies, never originals
- Verify image integrity with hash comparison before analysis
- Mount everything read-only
- Document every command and finding
- Preserve timestamps — never modify source evidence
Methodology
Step 1: Image Identification and Integrity
Identify the image format and verify integrity:
file <image> # Identify format (E01, dd/raw, VMDK, VHD)
sha256sum <image> # Compare to provided hashFor E01 images, use ewfinfo to extract metadata.
Step 2: Partition Layout
Examine the partition structure:
fdisk -l <image> # Partition table
mmls <image> # Sleuth Kit partition layoutCalculate mount offsets: sector_start × sector_size
Step 3: Mount and Explore
Mount read-only and survey the file system:
mount -o ro,loop,offset=<bytes> <image> /mnt/evidence
ls -laR /mnt/evidenceFor encrypted volumes, identify the encryption type and request the key/passphrase.
Step 4: File System Analysis (Sleuth Kit)
fsstat -o <offset> <image> # File system details
fls -r -o <offset> <image> # Full file listing (deleted files marked with *)
icat -o <offset> <image> <inode> # Extract specific file by inodeStep 5: Artifact Recovery
Deleted files: Use fls to find (marked with *), icat to extract by inode.
File carving: Run foremost or scalpel on unallocated space to recover files by header signatures.
Hidden data:
- NTFS alternate data streams
- HFS+ resource forks
- Check image files for steganography:
exiftool,binwalk,steghide
System artifacts:
- Browser history:
~/.mozilla,~/Library/Safari,AppData\Local\Google - System logs:
/var/log/*, Windows Event Logs - Registry hives (Windows): SAM, SYSTEM, SOFTWARE, NTUSER.DAT
- Recently accessed files, USB device history, prefetch files
Step 6: Metadata and Timestamps
exiftool <file> # EXIF, XMP, IPTC metadata
stat <file> # MAC times (Modified, Accessed, Changed)For NTFS: examine $MFT timestamps and $UsnJrnl for change journal entries.
Use mactime (Sleuth Kit) to generate a unified timeline from body files.
Step 7: Keyword Search
strings <image> | grep -i <keyword> # Raw string search across imageUse bulk_extractor for automated extraction of emails, URLs, credit card numbers, and other structured data.
Step 8: Timeline Construction
Collect all timestamps into a unified timeline. Cross-reference file events with log entries. Flag anomalies:
- Timestamps before the OS install date
- Future-dated files
- Gaps in otherwise continuous log sequences
- Timestamps inconsistent with timezone settings
Output Format
# Forensic Analysis Report
## Case: [identifier]
## Image: [filename] — SHA256: [hash]
## Date of Analysis: [date]
### Image Integrity
- Hash verified: [yes/no]
- Algorithm: [SHA256]
### Partition Layout
| # | Type | Start | Size | File System |
|---|------|-------|------|-------------|
### Key Findings
#### Finding 1: [Title]
- **Evidence:** [file path or artifact]
- **Content:** [description]
- **Timestamp:** [UTC]
- **Significance:** [why this matters]
### Recovered Files
| File | Source | Recovery Method | SHA256 | Significance |
|------|--------|-----------------|--------|-------------|
### Timeline
| Timestamp (UTC) | Event | Source | Notes |
|-----------------|-------|--------|-------|
### Conclusions
[Summary of findings and their implications]Boundaries
- Work only on provided images and files
- Maintain read-only access at all times
- Document chain of custody for real investigations
- For CTF challenges, focus on finding flags and solving the challenge
- Never modify evidence or suggest evidence tampering
- Refuse requests involving unauthorized device access
References
- NIST SP 800-86: Guide to Integrating Forensic Techniques
- The Sleuth Kit documentation
- SANS Digital Forensics cheat sheets
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- imMamdouhaboammar/cybersecurity-skills★ 098% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository42 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- agent-supply-chain-auditSkill
- ai-risk-managementSkill
- api-auditSkill
- breach-patternsSkill
- business-logic-testingSkill
- cicd-securitySkill
- cloud-auditSkill
- container-auditSkill
- control-auditSkill
- crypto-auditSkill
- csf-mappingSkill
- dependency-auditSkill
- finding-triageSkill
- fuzzing-harnessSkill
- hipaa-auditSkill
- iam-auditSkill
- incident-triageSkill
- log-watchSkill
- malware-triageSkill
- mobile-auditSkill
- native-code-reviewSkill
- osint-reconSkill
- owasp-auditSkill
- patch-sweepSkill
- pci-auditSkill
- personal-opsecSkill
- privacy-engineeringSkill
- prompt-injectionSkill
- reconSkill
- red-team-engagementSkill
- scanner-pipelineSkill
- secrets-auditSkill
- security-commsSkill
- security-startSkill
- siem-detectionSkill
- soc-operationsSkill
- threat-huntingSkill
- threat-modelingSkill
- variant-analysisSkill
- vuln-researchSkill
- web-pentestSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

