Digital forensics basics: what it is and why not to clean up first

TL;DR — Digital forensics is the disciplined process of preserving, collecting, and analyzing digital evidence so you can answer questions like "what happened, when, and how far did it spread?" If you suspect an incident, the single most important rule is: do not delete files, rotate logs, reinstall servers, or "tidy up" first; isolate access if needed, then preserve evidence before changing the system. Reading time: ~7 min

What it is and where it sits

Digital forensics is the part of incident response that focuses on evidence: what data exists, how to preserve it, and how to reconstruct events from it. In plain terms, it is how you turn "something seems wrong" into a defensible timeline.

In a typical software system, forensic evidence does not live in one place. It is spread across:

• the application and web server logs
• the database audit trail or query logs
• cloud activity logs (who changed what in your provider account)
• authentication logs from your identity provider (login system)
• endpoint or laptop data
• backups, snapshots, and object storage
• email, chat, and ticketing records

Digital forensics sits beside, not instead of, normal operations and security tools:

• It talks to your hosting platform, cloud provider, identity system, app logs, and backups.
• It often uses exports, snapshots, and read-only copies instead of live systems.
• It replaces guesswork and "I think this happened" with preserved evidence and a chain of custody (record of who handled evidence and when).

In a normal request flow, your app serves users. In a forensic flow, investigators collect copies of the records those systems already produced.

[User] ---- 1. request ----> [Web/App]
[Web/App] ---- 2. query ----> [Database]
[Web/App] ---- 3. auth check ----> [IdP]
[Web/App] ---- 4. write logs ----> [Log Store]
[Cloud Control Plane] ---- 5. admin events ----> [Audit Logs]

[Investigator] ---- 6. export/copy ----> [Log Store]
[Investigator] ---- 7. snapshot ----> [Server/Disk]
[Investigator] ---- 8. review ----> [Audit Logs]

What it replaces is the instinct to "fix first, investigate later." That instinct is understandable, but dangerous. If you delete suspicious files, clear browser history, rotate logs, restart containers, or rebuild a server before preserving evidence, you can erase the very clues needed to answer:

• Was this a real compromise or a false alarm?
• Which accounts were used?
• What data was accessed or exfiltrated (copied out)?
• Did the attacker still have access elsewhere?
• Do you need to notify customers, regulators, or insurers?

How it actually works

The mechanism is simple in concept: preserve first, analyze second, remediate third. The hard part is being disciplined under pressure.

One realistic example: suspicious admin activity in a web app

Imagine your team notices that three customer accounts were modified overnight, and an admin user insists they did not log in.

Step by step, a forensic response looks like this:

1. Stabilize without destroying evidence. You do not wipe the server. You do not delete the admin account. You reduce risk by disabling new access where possible: revoke sessions, rotate the password after recording current state, or put the app behind maintenance mode if the incident is active.

2. Preserve volatile data first. Volatile means data that disappears quickly: active sessions, running processes, short-retention logs, temporary files, and cloud console events. In many environments, web access logs may rotate daily, and cloud audit events may be harder to interpret later if you do not export them now.

3. Create read-only copies. Instead of examining the live production database directly for hours, you export relevant logs and create a disk or volume snapshot. In a cloud environment, this often means using your provider’s snapshot feature on the affected VM or volume, then mounting the copy to a separate analysis machine.

4. Collect surrounding records. You gather:

   • web server access logs around the time window
   • application audit logs for account changes
   • identity provider sign-in logs for the admin account
   • cloud audit logs for API calls, SSH key changes, firewall edits, or snapshot deletions
   • database logs for unusual reads or updates

5. Build a timeline. This is the core of forensic analysis. You line up timestamps across systems and ask: what happened first? Example:

   • 01:12 UTC: admin account logged in from a new IP address
   • 01:13 UTC: MFA (multi-factor authentication) was not challenged because of a remembered device policy
   • 01:14 UTC: customer records changed through the admin panel
   • 01:17 UTC: a new API token was created
   • 01:19 UTC: bulk export endpoint was called

6. Test hypotheses against evidence. Was the password guessed? Was a session cookie stolen? Was there an insider? Did an attacker use the cloud console instead of the app? Good forensics narrows this using evidence, not intuition.

7. Only then remediate fully. Once you know the path, you can invalidate all sessions, rotate tokens, patch the vulnerable component, remove persistence (ways the attacker could come back), and notify affected parties based on facts.

The key idea: every cleanup action changes the scene. Reinstalling a server may remove malware, but it also removes shell history, temporary files, process artifacts, and timestamps. Deleting a suspicious user may stop abuse, but it also destroys direct evidence of what that account touched.

When to use it (and when not to)

You do not need a full forensic engagement for every bug. You do need forensic discipline whenever the answer affects legal, financial, contractual, or customer-impact decisions.

You probably do not need a deep forensic process if all of these are true:

• the event is clearly explained by a normal software defect
• there is no sign of unauthorized access
• no one disputes what happened
• you do not expect insurance, legal, HR, or compliance questions

Trade-offs

Forensics is valuable, but it is not free.

• Benefit: better answers about scope and cause
  Cost: time. Preserving and analyzing evidence slows down the urge to "just fix it now."

• Benefit: stronger legal and insurance position
  Cost: process overhead. You need notes, timestamps, exports, and controlled handling of evidence.

• Benefit: lower chance of missing attacker persistence
  Cost: money. External forensic specialists, extra storage, and longer incident handling all cost real budget.

• Benefit: more accurate customer and regulator notifications
  Cost: latency in communication. You may need a few more hours to confirm facts before making statements.

• Benefit: reusable lessons for future security improvements
  Cost: operational burden. Teams must keep logs long enough, enable audit trails, and know where to export them from.

• Benefit: less guesswork
  Cost: sometimes uncomfortable findings. Forensics may show an internal process failure, weak access policy, or missing logs you wish you had.

There is also a lock-in angle: if your logs only exist in one vendor’s dashboard and you never export them, your investigation depends heavily on that provider’s retention and search tools. A safer pattern is to centralize logs in a system you control or at least export regularly.

In practice

Below are practical actions you can adapt today. Start in dashboards where possible; use CLI only if your team already does.

Example 1: export cloud audit logs before they age out

In your cloud provider’s dashboard, look for a path like Monitoring/Logging → Audit Logs → Export or Security → Activity History → Download. Providers vary, but the action is the same: export the time window now.

aws cloudtrail lookup-events \
  --start-time "2026-10-29T00:00:00Z" \
  --end-time "2026-10-30T12:00:00Z" \
  --max-results 50 > cloudtrail-events.json

This exports recent AWS CloudTrail management events to a JSON file you can preserve with the incident ticket. Gotcha: lookup-events is not a full archive export; if you need complete history, preserve the underlying trail storage too.

Example 2: copy web logs without modifying the originals

If your hosting panel exposes logs, use a path like Sites/Web Apps → Logs → Access Log → Download and save the file with the date range in the filename.

cp -a /var/log/nginx/access.log /evidence/2026-10-30-access.log
cp -a /var/log/nginx/error.log /evidence/2026-10-30-error.log
sha256sum /evidence/2026-10-30-access.log /evidence/2026-10-30-error.log > /evidence/SHA256SUMS.txt

This copies nginx logs with timestamps preserved and then records SHA-256 hashes (fingerprints) so you can later show the copies were not altered. Gotcha: if log rotation is configured, also copy older files like access.log.1 and any compressed *.gz files from the same period.

Example 3: turn on database connection logging for future incidents

If you manage Postgres through a control panel, look for Databases → Parameters/Flags and enable connection and disconnection logging. On self-managed Postgres, add:

log_connections = on
log_disconnections = on
log_line_prefix = '%m [%p] %u@%d %r '

This improves future forensic visibility by recording when clients connect, from where, and as which user. Gotcha: do not enable every verbose logging option in production without checking disk growth; start with connection and prefix settings, then review volume.

⚠️ Do not run cleanup commands before preserving evidence. Commands like rm -rf, docker system prune, log truncation, database vacuum/reindex jobs, or server rebuilds can permanently destroy evidence and may increase downtime if you later discover the incident was broader than expected.

A simple first-hour checklist you can hand to your team:

1. Open an incident ticket and write down who noticed what, and when.
2. In your provider dashboard, export audit/activity logs for the affected time window.
3. Download app, web, and auth logs before rotation removes them.
4. Create a snapshot of the affected server, disk, or database volume.
5. Restrict access carefully: revoke sessions or disable exposed entry points, but record the action in the ticket.
6. Preserve copies and hashes in a dedicated evidence folder.
7. Only after that, begin broader cleanup and recovery.

Further reading

• NIST SP 800-61 Computer Security Incident Handling Guide
• NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
• RFC 3227 Guidelines for Evidence Collection and Archiving
• The "Logging" and "HTTP access control" sections of the MDN Web Docs
• Incident Response & Computer Forensics, Mandia, Prosise, Pepe

This article was written by an AI system and published pending human review. Verify anything you intend to act on.