What Logs Should I Preserve During a Cyber Incident?

During a cyber incident, log preservation is one of the fastest ways to protect your ability to investigate, contain, recover, and meet legal/insurance obligations. This checklist focuses on the log sources that most reliably reconstruct who did what, when, and from where—and how to preserve them without destroying evidence.

TL;DR - Preserve identity/audit, endpoint (EDR), network (firewall/proxy/NAT/VPN), DNS, email, and cloud control‑plane logs—plus server/app/database logs tied to affected systems. - Export raw logs with timestamps and metadata, then lock them down with chain of custody (hashes, access control, immutable storage). - Act immediately: high-value sources roll over quickly, and attackers often try to clear traces.

Detailed Explanation: The Log Preservation Priority Order

The goal of log preservation is simple: reconstruct a defensible timeline that supports containment, eradication, and recovery—while keeping evidence usable for legal, compliance, or insurance follow-up.

A strong set of preserved logs should answer:

1. Who performed an action? (identity)
2. What did they do? (endpoint/app activity)
3. When did it happen? (accurate timestamps/time sync)
4. From where did it originate and where did it go? (network/cloud context)

Below is a practitioner checklist, ordered by typical incident value and volatility.

1) Identity and Authentication Logs (Highest Priority)

If you can only preserve one category, preserve identity logs. Many modern intrusions rely on credential abuse, token theft, OAuth consent abuse, or privilege escalation.

Preserve - IdP sign-in logs (successful/failed), MFA challenges, risk flags, conditional access decisions - Directory services logs (AD domain controller Security logs, LDAP auth logs) - Privileged access events: role changes, group membership changes, new service accounts, password resets, API key creation - SSO/OAuth events: app registrations, consent grants, token issuance/refresh use (where available)

What to capture - Raw event exports (not just dashboards) - Actor identity, source IP/geo/device, user agent, MFA method/result, session ID/correlation IDs

How far back? - Export as far back as retention allows (often 30–180 days). - If you suspect long dwell time or data theft, aim for 6–12 months where possible.

2) Endpoint and EDR/AV Telemetry (Very High Value, Often Volatile)

Endpoints show the “what happened on the box” view: process execution, persistence, credential dumping attempts, lateral movement, and file activity.

Preserve - EDR detections and raw telemetry (process tree, command line, parent/child, hash, signer, network connections) - AV quarantine/remediation history - Endpoint security configuration snapshots (tamper protection status, exclusions)

Key Windows logs from impacted hosts - Security, System, Application - PowerShell logs (Operational) - Windows Defender/Operational (if used) - Task Scheduler and WMI activity logs (where enabled)

Linux/macOS - Auth logs (/var/log/auth.log or /var/log/secure), sudo logs - System logs (syslog, journalctl) - Shell history can help but treat as unreliable (often modified)

Practical note: If your endpoint tooling is weak or visibility is limited, consider upgrading to a business-grade endpoint stack after the incident. For comparison context, see: best antivirus for windows business endpoints 2026. If you need a lightweight option for malware cleanup and scanning, Malwarebytes is commonly used in small environments: Get Malwarebytes →.

3) Network Edge and Egress Controls (Firewall/Proxy/NAT)

Network logs help confirm how attackers moved and what they exfiltrated (or attempted to).

Preserve - Perimeter firewall logs (allow/deny), including rule hit logs - NAT translation logs (critical for mapping internal hosts to public IP activity) - Web proxy / secure web gateway logs (URLs, categories, user identity if integrated) - IDS/IPS alerts (signature hits, anomalies)

Key fields - Source/destination IP and ports, action, rule, bytes transferred - TLS SNI (if logged), URL, authenticated user

4) DNS Logs (Fast Signal for C2 and Staging)

DNS is often the earliest signal of compromise and helps identify command-and-control, staging domains, and phishing infrastructure.

Preserve - Internal DNS resolver query logs (client IP → queried domain → response) - DNS security platform logs (blocked/allowed) - DHCP logs (IP ↔ MAC ↔ hostname mapping)

5) Email and Collaboration Logs (Phishing, BEC, Token Theft)

Email remains a primary initial access vector, and collaboration platforms are frequent targets for data theft.

Preserve - Email gateway logs: message trace, attachment detonation/sandbox results, URL rewrite/click logs - Mailbox audit logs: mailbox access, forwarding rule creation, mailbox delegation changes - Collaboration platform audit logs (file sharing links, external guest invites, mass downloads)

Also preserve - Copies of suspicious emails with full headers + body + attachments (export as EML/MSG in a forensically safe way)

6) VPN and Remote Access Logs (Where Compromise Often Starts)

Remote access is a common pivot point for credential stuffing, token theft, and “valid user” intrusions.

Preserve - VPN authentication logs (success/failure), MFA outcomes, device posture checks - Remote access gateway logs (RDP gateways, ZTNA access logs) - Geo/IP anomalies and new device enrollments

If your incident involves insecure remote access from hotels/airports or unmanaged devices, it’s also a good time to review your VPN posture. For small teams, NordVPN and Surfshark are widely used consumer-friendly options (they are not a replacement for enterprise ZTNA, but they can reduce risk for some use cases): Check NordVPN pricing →, Try Proton VPN →.

7) Cloud Control-Plane and SaaS Audit Logs (AWS/Azure/GCP/M365, etc.)

Cloud incidents often hinge on “who changed what” in the control plane.

Preserve - Cloud audit trails: management/API calls, console logins, role assumption events - IAM changes: role policy edits, access key creation, service principal changes - Storage access logs (object reads/downloads, ACL changes) - Kubernetes audit logs (if applicable) and container registry pull logs

Tip: Export logs out-of-account/out-of-tenant if you suspect the admin plane is compromised.

8) Server, Application, and Database Logs (Incident-Specific)

These confirm exploitation, data access, and tampering. They’re often the difference between “we think” and “we can prove.”

Preserve (as relevant) - Web server logs (access/error) and WAF logs - Application logs (auth events, admin actions, API requests) - Database audit logs (logins, SELECT/EXPORT activity, schema changes) - File server logs (SMB access, mass read/copy, permission changes)

If ransomware is suspected - Backup logs, snapshot logs, VSS events (Windows), hypervisor logs

9) Time Sources and “Evidence About the Evidence”

To make logs usable, preserve the context that makes timelines defensible.

Preserve - NTP configuration and time sync logs (time drift can derail correlation) - SIEM ingestion health (parsing rules, drop counts, collector backpressure) - Log retention settings and any recent changes to logging policies

How Far Back Should You Preserve Logs?

Use two overlapping windows:

• Immediate window (high confidence): from first alert/IOC back 7–14 days
• Hunt window (dwell time): back 30–180 days (or 6–12 months for suspected data theft, persistent access, or repeated credential abuse)

If you’re working from a specific indicator (hash, domain, IP, username), pivot across log sources to widen the time range until you can identify the earliest related activity.

Practical Preservation Steps (Do This Before It Rolls Over)

1) Freeze retention and stop log loss

• Increase retention where you can
• Disable overly aggressive rotation/rollover on critical sources
• Confirm SIEM collectors/agents aren’t dropping events due to load

2) Export raw logs to immutable storage

• Prefer write-once/object-lock/immutable storage
• Restrict access tightly (need-to-know)
• Consider a separate account/tenant if the primary admin plane may be compromised

3) Record chain of custody

At minimum, document: - Who collected what, when, and from where - Tools and export method used - Where the evidence was stored - Hashes for exported files (so you can prove integrity later)

4) Preserve incident context

• Asset inventory, hostname ↔ IP mapping, user lists
• Ticketing notes, chat logs related to response decisions
• Any emergency changes made (firewall blocks, account disables, policy changes)

Quick Collection Commands (Examples)

Windows: export core event logs (impacted hosts)

# Run as admin on impacted endpoints/servers
$dest="D:\IR\Logs"
New-Item -ItemType Directory -Force -Path $dest | Out-Null

wevtutil epl Security    "$dest\Security.evtx"
wevtutil epl System      "$dest\System.evtx"
wevtutil epl Application "$dest\Application.evtx"

# PowerShell Operational (often useful for script-based attacks)
wevtutil epl "Microsoft-Windows-PowerShell/Operational" "$dest\PowerShell-Operational.evtx"

Linux: preserve journal and auth logs

mkdir -p /root/ir-logs
journalctl --since "30 days ago" --no-pager > /root/ir-logs/journalctl-30d.txt
cp -a /var/log/auth.log /var/log/secure /root/ir-logs/ 2>/dev/null || true
tar -czf /root/ir-logs.tgz /root/ir-logs

Hash exports for integrity (chain of custody)

sha256sum /root/ir-logs.tgz > /root/ir-logs.tgz.sha256

Log Patterns Worth Searching Early

• New admin creation / role assignment / group membership changes
• Sudden MFA fatigue prompts or repeated MFA failures
• PowerShell with encoded commands; suspicious LOLBins (e.g., rundll32, regsvr32, mshta)
• Large outbound transfers or unusual destinations (especially after-hours)
• New email forwarding rules; OAuth consent grants; mailbox delegation changes
• DNS bursts to newly registered domains or high-entropy subdomains

Common Misconceptions (That Cause Lost Evidence)

“The SIEM already has everything.”

SIEMs often store normalized fields rather than full-fidelity raw events, collectors can drop data under load, and retention is frequently shorter than assumed. Preserve source exports where possible.

“Only the compromised server’s logs matter.”

Lateral movement and credential abuse often show up first in identity, VPN, DNS, and EDR telemetry—sometimes before the “victim” host tells the story.

“Screenshots of dashboards are enough.”

Screenshots rarely capture full payloads, correlation IDs, or integrity proof. Preserve raw exports (EVTX/JSON/CSV/original format) and document collection details.

“We should reboot systems to ‘clear issues’ before collecting logs.”

Reboots can destroy volatile evidence and rotate logs. Collect first, then make controlled changes.

“We can collect logs later once things calm down.”

DNS, VPN, NAT, and EDR telemetry can roll over quickly. Attackers may also delete logs after gaining admin rights. Early preservation is a containment action.

Related Reading

• NIST SP 800-61 (Computer Security Incident Handling Guide)
• NIST SP 800-92 (Guide to Computer Security Log Management)
• If you’re standardizing terminology across your IR documentation, see: what is mdr

---

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.