Summary:
A practical, visual-friendly guide to how logs and packet data help you detect intrusions and reconstruct attacks.

Reading time: ~7 minutes
Difficulty: Intermediate
Source: EC-Council Investigating Network Intrusions & Cybercrime Ch.1


What You’ll Learn

  • How attackers unknowingly leave evidence
  • How logs become a timeline of the intrusion
  • Which logs actually matter
  • How to preserve logs so they hold up legally
  • How to build a strong, defensive logging setup

What Network Forensics Really Is

Most people imagine network forensics as some magical Wireshark CSI moment.

In reality, it’s:

Collect → Analyze → Correlate → Preserve
All network-derived data that helps you understand what happened.

The book describes it as reconstructing events using network artifacts such as logs, packet captures, and device telemetry.

Think of it like this:

Firewall Logs       Router Logs       System Logs
      \                |                /
       \               |               /
            → Attack Timeline ←

Alone, each log is noise.
Together, they tell the story.


How Attacks Leave Traces (Even When Hackers Try to Hide)

Every intrusion follows a sequence.
Every step leaves a footprint:

Intrusion PhaseWhat HappensLogs That Trigger
ReconScanningFirewall, IDS
ExploitAttempting accessServer logs, event logs
Privilege EscalationNew permissionsSecurity logs
Lateral MovementInternal probingAuthentication logs
ExfiltrationData leavingRouter/Firewall logs

The book highlights that no attacker can avoid creating metadata — authentication attempts, packets, connections, timestamps… these betray them.


Logs as Evidence (and Why Lawyers Care About NTP)

Logs aren’t just “good for debugging.”
They’re admissible evidenceif they meet the following:

For logs to be credible:

  • They must be authentic
  • They must show tamper-resistant history
  • Timestamps must match real-world time (NTP!)
  • They must be retained consistently

The book heavily emphasizes proper clock synchronization — mismatched timestamps ruin your ability to correlate multiple logs.

A 17-second drift may seem harmless…
until your investigation turns into guesswork.


Correlating Logs: The Magic Moment

Here’s where the “investigator” part kicks in.

Example:

Step 1 — Web server logs show 50 /login attempts
Step 2 — Windows logs show 50 failed logins
Step 3 — Firewall shows 2GB outbound transfer
Step 4 — Router shows traffic headed to an unknown IP

Individually: meh.
Together: clear compromise + data exfiltration.

Chapter 1 calls this the end-to-end forensic view, combining multiple logs for a unified truth.


The Defensive Forensics Toolbox

From the book’s recommended log tools:

Syslog-ng / Socklog / Kiwi Syslog

Centralized log collection → prevents attackers from deleting evidence locally.

Microsoft Log Parser

Turns massive Windows/IIS logs into SQL-queryable data.

Firewall Analyzer / ASA Pro / GFI EventsManager

Aggregates logs from firewalls, IDS, routers, and servers into one timeline.

All tools serve one purpose: make evidence clean, consistent, and usable.


How to Build a Strong, Defensible Logging Architecture

If your goal is to make your environment “investigation-ready,” aim for this structure:

      [Endpoints]
        /  |  \
   Windows Linux Mac
        |    |
        --------
        Push logs
           ↓
   [Central Log Collector]
           ↓
       [SIEM / Analyzer]
           ↓
      Alerts + Reports

Key design principles:

  • Centralize logs away from endpoints
  • Encrypt in transit
  • Write-once storage (WORM or append-only)
  • Consistent retention (90–365 days)
  • NTP everywhere
  • Standard formats (JSON, Syslog RFC5424, etc.)

Safe Example: Secure Linux Log Forwarding

A fully defensive rsyslog config using TLS:

# /etc/rsyslog.d/secure-forwarding.conf

$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile /etc/rsyslog.d/ca.pem
$DefaultNetstreamDriverCertFile /etc/rsyslog.d/client.pem
$DefaultNetstreamDriverKeyFile /etc/rsyslog.d/client.key

# Send all logs securely to SIEM
*.* @@central-logs.mycompany.com:6514;RSYSLOG_SyslogProtocol23Format

This prevents log tampering and eavesdropping.


Legal & Ethics Reminder

Everything here supports:

  • defensive monitoring
  • incident response
  • cybercrime investigation
  • compliance

Never use forensic insights for unauthorized access or intrusion.
Log analysis must always follow proper authority and chain-of-custody rules.


Key Takeaways

  • Every attack leaves traces — logs are your evidence.
  • Correlation across systems reveals the attacker’s full path.
  • NTP time sync is essential for valid investigations.
  • Centralized, tamper-resistant logs make your environment “forensics-ready.”

Suggested Next Steps

  • Continue to Chapter 2: Investigating Network Traffic
  • OWASP Logging Cheat Sheet
  • NIST SP 800-92 (Log Management Guide)