
Someone deletes cloud footage — that’s not the end of the evidence. In DFIR, deletion is often just the beginning of a reconstruction process. Even when raw data is missing, metadata, logs, and endpoint artifacts can tell the full story. Here’s how cloud forensics works in practice.
🧭 The Misconception: Delete Means Gone
Cloud platforms abstract deletion — users see a file disappear, but the backend systems retain much more:
- Soft delete states: Files are marked for deletion but stored for 30–90 days in backend object storage (e.g., S3 Glacier, Azure Blob Archive)
- Audit trails: Interactions (upload, access, delete) are logged with user ID, IP address, device type, and timestamps
- Redundant data stores: Replication and snapshots for disaster recovery may preserve deleted content temporarily
- Legal holds: A valid subpoena or warrant can pause deletion queues and freeze account data
🛡️ Hypothetical Scenario: Deleted Cloud Footage
Imagine a situation where footage from a home security system was deleted from both local storage and cloud backup. The DFIR team is asked to investigate. The cloud provider confirms the footage isn’t available through the user portal. What now?
📂 Step 1: Transactional Chain Reconstruction
The forensic team starts with the cloud provider’s API and access logs:
- Upload event: Shows when the footage was saved — includes file hash, timestamp, size, and device ID
- Deletion event: Logs the account used, timestamp of deletion, source IP, and app version or device type
- Correlate file properties: Size, hash, and camera ID help identify exactly what was deleted, even if the binary data is gone
📡 Step 2: Network and Device Attribution
- Source IP: Ties the action to a specific network (e.g., home router, mobile carrier)
- Device ID: Most mobile apps log device fingerprints (UUIDs, OS versions, push tokens)
- User session correlation: Confirms which device was logged in when the deletion occurred
💾 Step 3: Endpoint and App Artifacts
- Thumbnail caches: Many camera apps cache video preview frames locally
- Push notifications: Alerts about detected motion or recordings may be stored as logs or screenshots
- Local backup folders: Some systems (e.g., Google Photos, iCloud) automatically sync camera roll images and app thumbnails
🌐 Step 4: Network-Level Evidence
- Router logs: Show upload events to cloud endpoints (e.g., camera.api.vendor.net)
- ISP records (if available): Help verify outbound upload timing and file size estimates
- DNS logs: Resolve the cloud storage domain used, providing a timeline of access
🛠️ Step 5: Correlation and Proof Construction
Even without the original file, the DFIR team can link:
- Timestamped upload and deletion events
- Source IP and device fingerprints to a known user
- Mobile app metadata to specific activity (e.g., notification history, background sync logs)
- Evidence from multiple layers (cloud, local, network) that align chronologically
📌 Final Analysis: Metadata is Evidence
In DFIR, we don’t need the raw file to prove what happened. Logs and metadata are often just as powerful:
- File size and timestamps: Show what existed and when
- Account actions: Show intent and user involvement
- Network-level artifacts: Prove data left a device, even if it no longer exists on disk
❤️ Why I Do This Work
Digital forensics isn’t about watching footage or reading logs — it’s about seeing the invisible. Reconstructing timelines. Proving that what others claimed was gone still left a trace. Connecting a deletion timestamp on a cloud dashboard to a device fingerprint, an IP address, and a 117MB upload that “shouldn’t exist.
This is why I love digital forensics. Because even when the data’s been wiped, the story is still there — buried in logs, metadata, and motion. It’s technical detective work that rewards precision, patience, and pattern recognition. And when done right, it turns absence into evidence — to speak for those who can’t speak for themselves, and to bring truth into the light where silence once stood. I carried that same purpose into this field from my years as a paramedic: responding when others freeze, searching for signals beneath the chaos, and fighting for justice when every second counts. This work isn’t just about systems — it’s about impact.

💡 SOC and DFIR Takeaways
- Always issue legal holds early — cloud data retention windows are short
- Focus on logs, not just content — audit trails survive longer than files
- Correlate across systems — cloud, mobile, network, and local
- Use deletion as a pivot — it’s an indicator of tampering or cleanup behavior
- Soft deletes ≠ no evidence — they’re just delayed deletions
🧠 Final Reminder
In cloud investigations, deletion is just another log entry. If you move fast and correlate hard, you don’t need the file to tell the story.
Leave a comment