Network Monitoring & Intrusion Investigation

After an incident, the investigator's job is to reconstruct what happened using the traces the attacker left in network logs, captured packets, and router records. This chapter covers the monitoring tools and investigation techniques used to build that timeline.

10.1Live Network Monitoring

Network monitoring is the continuous observation of traffic flowing across a network. In a security context its purpose is threefold: detect anomalies early, measure performance baselines, and collect evidence when something goes wrong. The key challenge is scale — capturing every byte of traffic on a busy network generates enormous data, so investigators often combine lightweight flow records with selective full-packet capture.

NetFlow / IPFIX is a Cisco-developed protocol (IPFIX is the IETF standard version) that records summary statistics for every network conversation — source IP, destination IP, source port, destination port, protocol, byte count, packet count, start time, and end time — without capturing the actual payload. A router or switch exports these flow records to a NetFlow collector. Because there is no payload, the storage requirement is tiny compared to full packet capture. Forensically, NetFlow answers "who talked to whom, for how long, and how much data moved" even when the payload is encrypted — enough to identify a beaconing host or a data exfiltration event.

SPAN (Switched Port Analyzer) / Mirror port is a switch feature that copies all traffic on one or more source ports to a designated monitor port, where a sniffer or IDS is connected. The mirrored traffic does not interrupt the original flow. Under very heavy load a switch may silently drop mirror copies to protect forwarding performance — which can introduce gaps in an evidence capture.

Network TAP (Test Access Point) is a passive hardware device physically spliced into a network cable (or fibre). It copies every bit of traffic to a monitor port and cannot modify or drop traffic because it has no active switching logic. A TAP introduces no latency and cannot fail silently in a way that drops packets. For this reason, forensic practitioners prefer a TAP over SPAN when evidence quality is critical: the integrity of the captured stream can be defended in court more easily.

Common tools:

• Wireshark — GUI packet analyser; deep protocol dissection; export files, HTTP objects, and credentials from a pcap.
• tcpdump — command-line packet capture; fast, scriptable; writes to .pcap files for later Wireshark analysis.
• Zeek (formerly Bro) — network security monitor that generates structured high-level logs (conn.log, dns.log, http.log, files.log) from live traffic or a pcap; much smaller than raw pcap, easy to parse with scripts.
• Suricata / Snort — IDS/IPS with alerting; Suricata is multi-threaded and handles high-speed links.

10.2Packet Capture & Analysis

A packet capture (pcap) file records every frame passing a monitoring interface with a microsecond timestamp. It is the most granular network evidence possible. Wireshark is the standard tool for analysing pcap files — it decodes hundreds of protocols and allows filtering to find relevant traffic quickly.

Useful Wireshark display filters:

• ip.addr == 192.168.1.5 — all traffic to or from a specific IP
• tcp.port == 443 — HTTPS traffic only
• http — all HTTP traffic (cleartext web)
• dns — all DNS queries and responses
• tcp.flags.syn == 1 && tcp.flags.ack == 0 — SYN-only packets (new connection attempts; a high count from one IP = port scan)
• tcp.flags.reset == 1 — TCP RST packets (connection rejections, common in port scans)

Common attack patterns visible in pcap:

Port scan — one source IP sends SYN packets to many destination ports in rapid succession. Closed ports return RST; open ports return SYN-ACK. The pattern is unmistakable: one source IP, many destination ports, RST flood.

Beaconing (C2 malware) — an infected host makes regular outbound connections to a fixed external IP at suspiciously even intervals — for example, exactly every 60 seconds. This is a command-and-control (C2) check-in. Automated detection: filter for regular intervals in connection logs; human detection: look for a single IP appearing repeatedly on a regular schedule.

Data exfiltration — large volumes of outbound DNS queries (DNS tunnelling), unusual large uploads to cloud storage or unknown IPs, or a sudden spike in outbound encrypted traffic to a new destination.

Cleartext credentials — search the pcap for HTTP POST requests (login forms), FTP authentication sequences (USER/PASS commands in plaintext), or Telnet sessions (every keystroke is visible). Wireshark: follow TCP stream on any of these to read the cleartext content.

pcap file formats: .pcap (libpcap, legacy) and .pcapng (next-generation, more metadata, supports multiple interfaces in one file). Always compute and record the SHA-256 hash of the pcap file before analysis to demonstrate it was not modified.

Carving files from a pcap: Wireshark can extract files transferred over HTTP: File → Export Objects → HTTP. This recovers executables, documents, or images that were downloaded during the captured session.

10.3Detecting SQL Injection from Logs

SQL injection appears clearly in web server access logs as abnormal characters and SQL keywords embedded in request parameters. The investigator does not need database access to spot it — the evidence is in the HTTP logs.

Suspicious strings to look for in log entries:

• ' — single quote; attempts to break out of a SQL string literal and inject code
• -- or # — SQL comment marker; truncates the legitimate remainder of the query
• UNION SELECT — appends a second query to extract data from other tables
• 1=1 or 1'='1 — always-true condition used to bypass login (WHERE password='anything' OR '1'='1')
• DROP TABLE, INSERT INTO — destructive injection attempts
• sleep(5) or waitfor delay '0:0:5' — time-based blind injection; attacker infers results by measuring server response time

Example malicious log entry:

GET /login.php?id=1'+UNION+SELECT+username,password+FROM+users--  HTTP/1.1

The URL-encoded + characters represent spaces. This entry shows a clear UNION-based injection attempt targeting a users table.

Investigation steps:

1. Extract all requests with suspicious strings from the web access log (grep, awk, or a SIEM query).
2. Check whether the HTTP response size was abnormal — a larger-than-usual response body may indicate data was returned to the attacker.
3. Check database error logs for SQL syntax errors left by failed or partially successful injection attempts.
4. Check database audit logs for unusual SELECT queries against sensitive tables (users, payments, sessions).
5. Identify the source IP and correlate it with firewall logs, IDS alerts, and authentication logs to build a full picture of attacker activity.
6. If a WAF was present, its logs may already contain blocked attempts with the complete payload recorded.

10.4Event Log Evidence & Chain of Custody

Building a reliable attack timeline requires correlating log evidence from multiple sources. No single log tells the whole story.

Converting timestamps to UTC is the first step: web servers, Windows domain controllers, routers, and cloud services may all be in different time zones or have different NTP synchronisation states. All timestamps must be converted to UTC before events from different sources can be placed on the same timeline.

Log sources to collect in an intrusion investigation:

Evidence from routers: The router's NAT translation table maps each external connection (public IP + port) to the internal host and port that originated it, with timestamps — essential for attributing a connection observed in firewall logs to a specific internal device. The ARP cache maps IP addresses to MAC addresses. Interface statistics show traffic volumes per link.

Evidence from DHCP server: Maps IP address to MAC address and hostname for a specific lease period. This is the critical bridge between an IP address seen in a network log and the physical device that held that address at the time. Without DHCP logs, an investigator cannot say which machine in the office had IP 192.168.1.47 last Tuesday at 14:23.

Preserving log integrity: Immediately on collection, compute and record the SHA-256 hash of each log file. Note the file size. If possible, sign the hash with the examiner's digital certificate. Document the collection in the seizure form: which system, which log file, what time, who collected it, what the hash was. This prevents any challenge that logs were modified after collection.

NTP (Network Time Protocol) synchronises device clocks. If a device's NTP is misconfigured or its clock drifted, all log timestamps from that device are shifted. The examiner must document the clock skew (difference between device clock and UTC) at the time of evidence collection so timestamps can be corrected during timeline analysis.

Chain of custody for digital logs follows the same principles as physical evidence: who collected it, when, from which system, what the hash was at collection, and where it has been stored since. Courts routinely challenge digital evidence on chain of custody grounds — an incomplete record can render logs inadmissible. Complete the seizure form at time of collection, not retrospectively.

10.5Cloud Evidence Collection

Cloud infrastructure generates extensive audit logs, but there are two important caveats: retention periods are often short (30–90 days by default) and some logs are not enabled by default. Investigators must act quickly to preserve cloud evidence before it is automatically deleted.

AWS CloudTrail logs every API call made to AWS services — who made the call (user or IAM role), which API action, to which resource, from which source IP, with which credentials, and at what time. CloudTrail must be explicitly enabled and configured to write to an S3 bucket. For an AWS intrusion investigation, CloudTrail is the primary evidence source: it shows every action the attacker took using compromised credentials — EC2 instance launches, S3 bucket access, IAM policy changes.

Azure Activity Log / Azure AD Sign-in Logs provide equivalent API audit trails for Microsoft Azure. The Activity Log captures control-plane operations (creating or deleting resources); the Sign-in log captures every authentication to Azure AD (Microsoft Entra ID), including application, IP address, and conditional access policy outcome.

Google Cloud Audit Logs come in two categories: Admin Activity logs (always on, no extra cost — records resource configuration changes) and Data Access logs (must be explicitly enabled — records who read data from which resource). In a GCP investigation, enabling Data Access logs before an incident is critical; they cannot be retrieved retroactively for activity before they were turned on.

Evidence collection approaches:

1. Legal hold / preservation request — contact the provider immediately to freeze the relevant logs before retention expiry. Most major providers (AWS, Azure, Google, Microsoft 365) have law-enforcement portals for this purpose.
2. Consent-based — if the organisation controls the cloud account, export logs directly to a controlled evidence store (hash on export).
3. Legal process — a court order or MLAT (Mutual Legal Assistance Treaty) is required to compel a third-party cloud provider to produce logs for an account the investigator does not control.

ACPO cloud investigation guidance (adapted): preserve before you investigate; never modify the original cloud environment; document that evidence was obtained and stored without modification; use the provider's law-enforcement portal rather than manual API calls to demonstrate a clean collection process.

On-premises evidence of cloud activity: Even if cloud provider logs are unavailable, local evidence of cloud activity is often present: browser history and proxy logs showing AWS/Azure management console access; installed CLI tools (aws, gcloud, az) with associated credential files and command history; cloud sync client logs (OneDrive, Dropbox, Google Drive) recording file upload/download timestamps and filenames.