Network Traffic Analysis (NTA)

1. What NTA Is

Network Traffic Analysis = capturing, inspecting and analyzing data as it moves through a network, to get full visibility of what's communicated inside the network and in and out of it.

NTA is NOT just Wireshark

NTA combines three things, each with a clear goal:

1. Correlating logs from several devices
2. Deep packet inspection: reading the actual packet contents
3. Flow statistics: counts and patterns (who talks to whom, how much, how often)

The core skill for a SOC L1 analyst

Know what normal looks like (the baseline), and spot what deviates from it.

You can't detect "unusual" until you know "usual". For example, if a host normally makes 50 DNS queries an hour, 5,000 an hour is the signal.

2. WHY — Logs Tell You That Something Happened, Packets Tell You What

The scenario: DNS tunneling and beaconing

An alert fires: host WIN-016 (192.168.1.16) is making an unusual number of DNS queries. The firewall's DNS log shows:

09:15:23  SRC=192.168.1.16  QUERY=aj39skdm.malicious-tld.com  QTYPE=A
09:15:31  SRC=192.168.1.16  QUERY=msd91azx.malicious-tld.com  QTYPE=A
09:15:45  SRC=192.168.1.16  QUERY=cmd01.malicious-tld.com     QTYPE=TXT
09:15:45  SRC=192.168.1.16  QUERY=cmd01.malicious-tld.com     QTYPE=TXT

What the log CAN tell you

What the log CANNOT tell you

What was inside the queries and the replies. Firewalls record that a DNS query happened, not its content.

Why that matters: how DNS tunneling works

DNS is almost always allowed out through the firewall, so attackers use it as a hidden channel:

The packet capture shows the content

Queries:  cmd1.evilc2.com: type TXT
Answers:  cmd1.evilc2.com: type TXT, TTL 60
          TXT: "SSBsb3ZlIHlvdXIgY3VyaW91c2l0eQ=="

• The == at the end is a giveaway for Base64.
• Decoded, it reads: "I love your curiosity". In a real attack this string would be a command, e.g. "download payload" or "send files".
• Only the packet capture revealed this. The firewall log just said "TXT query, answered".

What NTA is used for

General uses:

• Monitor network performance
• Spot abnormalities (sudden traffic spikes, slow network)
• Inspect suspicious communication, both internal and external (DNS exfiltration, malicious downloads, lateral movement)

SOC uses:

• Detect suspicious or malicious activity
• Reconstruct attacks during incident response
• Verify and validate alerts (real attack or false positive?)

Two more examples from the course:

1. A host starts behaving abnormally at 4 PM UTC → its traffic shows a suspicious HTTP request → analysts extract the ZIP file from the capture.
2. A host sends far more DNS requests than the baseline → inspection shows data being exfiltrated via DNS tunneling.

3. WHAT — What We Can See at Each Layer

Encapsulation: how a packet is built

Data travels down the TCP/IP stack when sent. Each layer wraps the data in its own header, like envelopes inside envelopes:

Application:                                 [App header + Data]
Transport:                  [Transport header][App header + Data]
Internet:        [IP header][Transport header][App header + Data]
Link:  [Link hdr][IP header][Transport header][App header + Data]

The receiver unwraps them in reverse order.

The key idea of this whole section: logs record a few fields from these headers. A full packet contains every header plus the data. Each layer has attacks that only show up in the fields logs don't keep.

Overview table

3a. Application Layer — the payload is the blind spot

Two parts: the application header and the application data (payload). Both depend on the protocol (HTTP, DNS, SMTP...).

HTTP request:

GET /downloads/suspicious_package.zip HTTP/1.1
Host: www.tryhackrne.thn
User-Agent: curl/7.85.0

HTTP response:

HTTP/1.1 200 OK
Content-Type: application/zip
Content-Length: 10485760
Content-Disposition: attachment; filename="suspicious_package.zip"

[binary ZIP file bytes follow — 10,485,760 bytes]   ← logs never capture this

What proxies/firewalls log: the headers. The client requested suspicious_package.zip, and the server answered 200 OK (success). What they don't log: the ZIP file itself. To analyze the malware, you need the packet capture to carve the file out.

Analyst eye — three red flags in those headers:

• Content-Length: 10485760 → the file size in bytes (= exactly 10 MB). (Quiz answer)
• User-Agent: curl → a command-line tool, not a browser. On a normal user's PC that suggests a script or malware made the request.
• Host: www.tryhackrne.thn → "rn" disguised as "m" (try-hack-rn-e). Lookalike domain trick, same as in phishing.

3b. Transport Layer — sequence numbers reveal hijacking

The transport layer splits the application data into segments and adds a header, usually TCP or UDP.

Firewall logs keep: ports and flags.

ACCEPT TCP src=192.168.1.45 dst=172.217.22.14 sport=51432 dport=443 flags=SYN
ACCEPT TCP src=172.217.22.14 dst=192.168.1.45 sport=443 dport=51432 flags=SYN,ACK

They drop: the sequence numbers.

Sequence numbers, explained

TCP numbers every byte it sends so the receiver can put data back in order and detect anything missing. Each side tracks the next number it expects. In a normal conversation the numbers grow smoothly, by exactly the number of bytes sent.

Session hijacking in the capture

No. Source          Dest           Info
1   192.168.1.45 → 172.217.22.14  [SYN]      Seq=0                      ┐
2   172.217.22.14 → 192.168.1.45  [SYN,ACK]  Seq=0 Ack=1               ├ 3-way handshake (normal)
3   192.168.1.45 → 172.217.22.14  [ACK]      Seq=1 Ack=1               ┘
4   192.168.1.45 → 172.217.22.14  [PSH,ACK]  Seq=1  Len=1460           ┐ normal data transfer
5   172.217.22.14 → 192.168.1.45  [ACK]      Ack=1461                  ┘ (server confirms 1460 bytes)
6   192.168.99.200 → 172.217.22.14 [PSH,ACK] Seq=34567232  Len=20      ← INJECTED

Packet 6 has two problems:

1. A different source IP (192.168.99.200) is sending data into someone else's session.
2. The sequence number jumps from ~1461 to 34,567,232. Real conversations don't leap like that.

Rule: sequence numbers suddenly far apart = someone may be injecting into the session. (Quiz answer: the sequence number field)

Note: Wireshark shows relative sequence numbers starting at 0 for readability. The real starting number is random, but the jump is still the giveaway.

3c. Internet Layer — fragmentation to evade the IDS

The internet layer adds the IP header. If a packet is bigger than the MTU (the largest size the link carries, usually 1500 bytes), it gets split into fragments, each with its own header.

Logs keep: source/destination IP and TTL. That's enough for most cases. Fragmentation attacks need: fragment offset (where this piece belongs in the original) and total length.

How fragments normally fit together

Like puzzle pieces: piece 1 covers bytes 0–1479, piece 2 starts at 1480, and so on. No gaps, no overlaps.

Two attack variants

The overlap in the capture

1  Fragment  [MF]  Offset=0,     Len=1480    → bytes 0–1479
2  Fragment  [MF]  Offset=1480,  Len=1480    → bytes 1480–2959
3  Fragment        Offset=1480,  Len=64      → bytes 1480–1543   ← OVERLAPS #2
4  ICMP  Destination unreachable (Fragment reassembly time exceeded)

• MF = More Fragments flag (more pieces to come). The last fragment has no MF.
• Fragment 3 claims bytes already covered by fragment 2. Which version wins? It depends on the system, and that ambiguity is exactly what the attacker exploits.
• Packet 4: the target gave up reassembling, another sign something was wrong.

Quiz answer: attackers use fragmentation to try to evade an IDS.

3d. Link Layer — ARP poisoning needs context

The link layer adds MAC addresses (the hardware address of each network card).

Logs keep: source and destination MAC. They can't show: patterns across packets, such as one MAC claiming several IPs, or a flood of unrequested ARP replies.

ARP in one sentence

ARP answers "which MAC address has this IP?" on the local network. It has no authentication: any device can answer, even for an IP that isn't its own.

ARP poisoning in the capture

1  192.168.1.1   → Broadcast    Who has 192.168.1.10? Tell 192.168.1.1     (router asks)
2  192.168.1.10  → 192.168.1.1  192.168.1.10 is at 00:11:22:33:44:55        (real answer)
3  192.168.1.200 → 192.168.1.1  192.168.1.10 is at aa:bb:cc:dd:ee:ff  ← lie to the router
4  192.168.1.200 → 192.168.1.10 192.168.1.1  is at aa:bb:cc:dd:ee:ff  ← lie to the victim
5  192.168.1.10  → 172.217.22.14 [SYN]                                       (victim connects)
6  192.168.1.200 → 172.217.22.14 [SYN]  ← relayed through the attacker

What happened:

• The attacker (.200) told the router "I am the victim", and told the victim "I am the router".
• Now all traffic between them goes through the attacker = Man-in-the-Middle.
• The fingerprint: one MAC (aa:bb:cc:dd:ee:ff) claiming two different IPs, plus ARP replies nobody asked for.

A single log line looks normal. Only the sequence of packets reveals the attack.

4. WHERE — Sources and Flows

Theory (layers) shows what is possible. In practice, you focus on which devices and which directions matter.

Two kinds of traffic sources

Quiz answer: endpoints generate the most traffic. Analyst view: intermediaries are where you observe; endpoints are what you're observing.

Two directions of traffic flow

Picture a map with the internet at the top and the internal network spread out sideways:

Why East-West is the dangerous blind spot

Once an attacker is inside, they move laterally, hopping from machine to machine using normal internal services (SMB, RDP, Kerberos). That traffic never crosses the firewall, so a network that only watches North-South won't see it.

East-West services by category

Flow Example 1 — HTTPS through a TLS-inspecting proxy

Problem: HTTPS is encrypted, so a security device in the middle can't see inside it. Solution: the proxy splits the connection in two.

HOST ⇄ [TLS session #1] ⇄ NGFW / WEB PROXY ⇄ [TLS session #2] ⇄ WEB SERVER
         (LAN)              decrypts, inspects,      (WAN)
                            re-encrypts

1. The host requests a website → the request goes to the NGFW's web proxy.
2. The proxy pretends to be the web server to the host (session #1).
3. The proxy opens its own session with the real web server (session #2) and forwards the request.
4. The reply comes back to the proxy, which decrypts it, inspects it, and forwards it to the host only if it's safe.
5. The host thinks it's talking directly to the web server.

Extra detail: this works only because the organization installs the proxy's certificate on company machines. Otherwise browsers would show a security warning.

Flow Example 2 — External DNS

HOST → internal DNS server (port 53) → cache hit? → answer immediately
                                     → cache miss → router → firewall → external DNS
                                       answer returns the same path → internal DNS → HOST

• The internal DNS server acts on the host's behalf. The host never talks to the internet directly for DNS.
• Analyst consequence: in firewall logs, outbound DNS appears to come from the DNS server, not the infected host. To find the real host, check the internal DNS server's logs.

Flow Example 3 — SMB file share with Kerberos (pure East-West)

Opening \\FILESERVER\MARKETING:

At login:  HOST ──authenticates──► KDC (Domain Controller) ──► gives TGT
Step 1:    HOST ──"TGT, please give me a ticket for FILESERVER"──► KDC ──► Service Ticket
Step 2:    HOST ──presents Service Ticket──► SMB SERVER ──► session opens, share accessible

Think of it like a theme park: the TGT is your entry wristband; each service ticket is a ride ticket you get by showing the wristband.

Quiz answer: before an SMB session, Kerberos must be contacted for authentication.

5. HOW — Three Ways to Collect Data

NTA = combine sources → analyze → find patterns → act.

5a. Logs — the first entry point

• Every system logs, but there is no universal standard. Each vendor decides the format and which fields to keep (Microsoft uses Windows Event Logs, Linux uses Syslog, and so on).
• Almost no vendor logs the full packet. They keep fields they consider useful, like source and destination IP.

Linux auth log (Syslog format):

Oct 8 11:20:15 web01 sshd[2145]: Accepted password for gensane from 192.168.1.50 port 52234 ssh2

→ When, which server, which service, successful login, which user, from which IP.

Apache access log (CLF, Common Log Format):

192.168.1.50 - - [08/Oct/2025:11:20:18 +0200] "GET /index.html HTTP/1.1" 200 2326 "-" "Mozilla/5.0"

→ Client IP, time, request, status (200 = OK), response size in bytes, referrer, browser.

Correlation example: the same IP logged in via SSH at 11:20:15, then browsed the website 3 seconds later. Linking events across sources like this is the "correlating logs" part of NTA.

• Logs differ in format, but sending them is standardized by Syslog and SNMP.
• When logs aren't enough → correlate them, use packet capture, check statistics.

5b. Full Packet Capture — two ways to get a copy of the traffic

You need a copy of the traffic without disturbing it:

Cisco SPAN configuration:

Switch(config)# monitor session 1 source interface fastEthernet0/1        ← watch this port
Switch(config)# monitor session 1 destination interface fastEthernet0/2   ← send copies here

Everything passing Fa0/1 is duplicated to Fa0/2, where the monitoring device is connected.

Diagram meaning: WIN-001 sends a packet to the server through the switch (1→2). The switch also sends a copy to the monitoring device (3).

Not only physical: mirroring works on virtual switches (VMware vSwitch) and in the cloud (AWS VPC Traffic Mirroring).

Vendor names differ: SPAN is Cisco's name for port mirroring.

5c. Network Statistics — NetFlow and IPFIX

Sometimes you don't need the content, just the pattern: "this host sent 5,000 DNS queries", "this server sent 2 GB to an unknown IP at 3 AM".

A flow = one conversation, summarized: source, destination, ports, protocol, how many packets/bytes, start/end time. It's like a phone bill: you see who called whom, when and for how long, but not what was said.

NetFlow (Cisco)

Collects flow metadata, ideal for detecting C2 traffic, data exfiltration and lateral movement.

Reading the sample record:

In plain English: 12.1.1.1 sent 5 ping packets (640 bytes) over ~2.5 seconds to 13.1.1.2. No content, but enough to spot patterns.

Useful protocol numbers: 1 = ICMP, 6 = TCP, 17 = UDP.

IPFIX — the open successor

Setting it up is cheap: most devices support it already. Just enable it and point it at a collector. Many NGFWs, IDS and IPS can collect and analyze flows themselves, with no dedicated server needed.

6. How It All Fits Together — A Real Investigation

1. ALERT        Statistics/NetFlow: "WIN-016 is making 10× its normal DNS queries"   (HOW: stats)
2. TRIAGE       Firewall DNS logs: random subdomains + TXT queries to one domain    (HOW: logs)
3. DEEP DIVE    Packet capture from a TAP/SPAN: TXT replies contain Base64 commands (HOW: FPC)
4. LAYER        Application-layer payload revealed it                               (WHAT)
5. SCOPE        Check East-West traffic: did WIN-016 talk to other internal hosts?  (WHERE)
6. CONCLUSION   DNS tunneling C2 → isolate host, block domain

Golden rules:

1. Logs = summary. Packets = proof. Flows = patterns. You need all three.
2. Know the baseline; investigate the deviation.
3. Every layer hides its own attack: payload → sequence numbers → fragment offset → MAC/ARP patterns.
4. East-West is the blind spot. Attackers move laterally where few people watch.
5. Encrypted traffic is invisible unless something (like a TLS proxy) decrypts it.

Quiz Answers From This Room

Acronym List