Digital Forensics · Topic 5 of 11
Analyzing Attack Traffic in Packet Captures
Spot SYN and UDP floods, HTTP floods, FTP and SMB password guessing, sniffing, malware beacons, SMTP and SNMP abuse in packet captures, for CHFI v11.
- 5 min
- SYN flood: many SYNs without the final ACK. Defense: SYN cookies.
- UDP flood causes ICMP port unreachable replies. HTTP flood is valid layer 7 requests in volume.
- FTP failure is reply 530 and success is 230. SMB failure is 0xc000006d.
What it is
Each attack leaves a recognizable pattern in a packet capture. The skill the exam tests is to look at a described pattern and name the attack, then say which field or filter shows it.
This page gives the signature of each attack in the outline and the Wireshark filters that find it.
How it works
TCP SYN and SYN-FIN flood
A SYN flood sends a high rate of SYN packets, often from spoofed addresses, and never completes the handshake. The server keeps half open connections and runs out of room.
In a capture you see many SYN packets with no final ACK, SYN-ACK packets retransmitted to addresses that never answer, and a very high connection rate to one port. Useful filter: tcp.flags.syn == 1 && tcp.flags.ack == 0. SYN cookies are a standard defense.
A SYN-FIN packet sets both flags at once, which is an illegal combination. It is used to probe or evade simple filters and floods. Filter: tcp.flags.syn == 1 && tcp.flags.fin == 1.
UDP and HTTP flood
A UDP flood sends a large number of UDP datagrams to random or chosen ports. The target answers each closed port with an ICMP destination unreachable (port unreachable) message, which adds load.
An HTTP flood is a layer 7 attack. Requests are valid and the TCP handshake completes, but they arrive in huge numbers, often for the same expensive URL, from many addresses.
| Attack | Layer | Capture clue |
|---|---|---|
| SYN flood | Transport | SYNs with no completing ACK |
| UDP flood | Transport | Huge UDP volume, many ICMP unreachable replies |
| HTTP flood | Application | Many complete GET or POST requests to one URL |
Filters: udp, icmp.type == 3 and http.request. In the Statistics menu, Conversations and Endpoints identify the top talkers.
FTP and SMB password cracking attempts
FTP sends credentials in clear text. A guessing attempt shows repeated USER and PASS commands with the reply 530 Login incorrect, and a success is 230 User logged in. Filter: ftp.response.code == 530.
SMB guessing shows many session setup attempts from one source. A failed logon returns STATUS_LOGON_FAILURE (0xc000006d) in the SMB2 response. Filter: smb2.nt_status == 0xc000006d. The matching server event is Security event ID 4625. A final success after many failures suggests the account is compromised.
Sniffing attempts
Active sniffing on a switched network often uses ARP spoofing. The attacker sends forged ARP replies so traffic is routed through the attacker's machine.
| Sign | Meaning |
|---|---|
| One MAC address claims several IP addresses | Possible ARP poisoning (a router doing proxy ARP also does this) |
| Two MAC addresses claim the same IP | Duplicate address, possible spoofing |
| Many unsolicited (gratuitous) ARP replies | Attack in progress |
| Host answers an ARP request sent to a non-broadcast MAC | Network card may be in promiscuous mode |
Wireshark flags duplicates as an expert warning, and arp.opcode == 2 shows replies. The Nmap script sniffer-detect tests for promiscuous interfaces.
Detecting malware activity in traffic
Malware needs the network to receive commands, send data or spread. Indicators are:
- Beaconing: connections to the same address at fixed intervals.
- Odd DNS: many failed lookups of random looking names, or lookups of newly registered domains.
- Unusual ports or protocols: web traffic on a non-standard port, or IRC traffic from a workstation.
- Large outbound transfers: data leaving at odd hours.
- Strange user agents: HTTP clients that do not match any installed browser.
Tools such as NetworkMiner and Zeek help extract files and connection logs. Hash extracted files and compare them with threat intelligence.
SMTP and SNMP traffic
SMTP uses TCP port 25 (also 587 and 465). Commands are EHLO, MAIL FROM, RCPT TO and DATA. Signs of abuse are one host sending to many recipients, a workstation sending mail directly to external servers, and attachments sent to unknown outside addresses. In Wireshark, Follow TCP Stream rebuilds the message.
SNMP uses UDP 161 for requests and 162 for traps. Versions 1 and 2c send the community string in clear text, with public and private as common defaults. Signs of abuse are many GetRequest messages that try different community strings, and SetRequest messages that change device configuration. SNMPv3 adds authentication and encryption.
A worked example
A web server is slow. A capture shows 60,000 SYN packets per minute from changing source addresses, each followed by a SYN-ACK and no ACK. Conversations show hundreds of half open connections to port 443.
The filter tcp.flags.syn == 1 && tcp.flags.ack == 0 isolates the SYNs. The investigator identifies a SYN flood and records the first packet time and the capture hash. A later capture of the same server shows normal ratios after SYN cookies are enabled.
How the exam asks about this
- "Many
530 Login incorrectreplies from one source indicate what?" -> An FTP password guessing attempt. - "A packet has both SYN and FIN set. What does it suggest?" -> A malformed packet used in scanning or flooding, a SYN-FIN attack.
- "Which SNMP element is sent in clear text in versions 1 and 2c?" -> The community string.
What to remember for the exam
- SYN flood: many SYNs without the final ACK. Defense: SYN cookies.
- UDP flood causes ICMP port unreachable replies. HTTP flood is valid layer 7 requests in volume.
- FTP failure is reply 530 and success is 230. SMB failure is 0xc000006d.
- ARP spoofing signs are duplicate IP to MAC claims and gratuitous ARP replies.
- SNMP v1 and v2c community strings are clear text. SMTP commands: EHLO, MAIL FROM, RCPT TO, DATA.
A high volume of traffic is not always an attack. A legitimate flash crowd looks like an HTTP flood until you check source variety, request patterns and timing.
Common mistakes
Calling every flood a SYN flood. Check the protocol and flags first. UDP and HTTP floods look different.
Missing the successful login. In password guessing, the key finding is the success after the failures, not the failures alone.
Ignoring encryption. HTTPS and SSH payloads cannot be read, so use metadata such as timing, volume and destination.
Check yourself
Which reply code in an FTP capture shows a failed login?
530.
What does the ICMP destination unreachable traffic in a UDP flood come from?
The target, replying for each datagram sent to a closed port.
Why is SNMP v1 or v2c weak?
Its community string travels in clear text and is often left as a default such as public.
Topic 5 of 11 in Digital Forensics
Test yourself on Digital Forensics
The full EC-Council 312-49 question bank has 900 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by EC-Council. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.