Malicious Traffic Analysis

The following is a combination of notes, research, and knowledge acquired from a malicious traffic analysis course. The focus of this post is on identifying malicious activity in Wireshark. For basic Wireshark setup and tips for filtering, check here.

Note: A good rule of thumb in terms of physical requirements is that whatever the pcap size is, you should have four times that amount of RAM available.

Lifecycle: Reconnaissance

This includes discovery as well as scanning for hosts, fingerprinting, sevices, and network mapping.

TTL-OS Table

When you ping an ip address, the Operating System can sometimes be surmised by the TTL value. The table below is from this maintained website.

Device / OS	Version	Protocol	TTL
AIX		TCP	60
AIX		UDP	30
BSDI	3.2, 4.1	ICMP	255
Compa	BSD/OS 3.1 and 4.0	ICMP	255
Cisco		ICMP	64
DEC Pathworks		ICMP	254
Foundry	V5	TCP and UDP	30
FreeBSD	2.1R	ICMP	64
FreeBSD	3.4, 4.0	TCP and UDP	64
FreeBSD	5	ICMP	255
HP-UX	9.0x	ICMP	64
HP-UX	10.01	TCP and UDP	30
HP-UX	10.2	TCP and UDP	64
HP-UX	11	ICMP	255
Irix	11	ICMP	255
Irix	5.3	TCP	64
juniper	6.x	TCP and UDP	60
MPE/IX (HP)	6.5.3, 6.5.8	TCP and UDP	60
Linux		ICMP	255
Linux		ICMP	64
Linux	2.0.x kernel	ICMP	200
Linux	2.2.14 kernel	ICMP	64
Linux	2.4 kernel	ICMP	255
Linux	Red Hat 9	ICMP	255
MacOS/MacTCP	2.0.x	ICMP and TCP	64
MacOS/MacTCP	X (10.5.6)	TCP and UDP	60
NetBSD		ICMP	255
Netgear FVG318		ICMP and UDP	64
OpenBSD	2.6 & 2.7	ICMP	255
OpenVMS	07.01.2002	ICMP	255
OS/2	TCP/IP 3.0	ICMP	64
OSF/1	V3.2A	TCP	60
OSF/1	V3.2A	UDP	30
Solaris	2.5.1, 2.6, 2.7, 2.8	ICMP	255
Solaris	2.8	TCP	64
Stratus	TCP_OS	ICMP	255
Stratus	TCP_OS (14.2-)	TCP and UDP	30
Stratus	TCP_OS (14.3+)	TCP and UDP	64
SunOS	STCP	ICMP/TCP/UDP	60
SunOS	4.1.3/4.1.4	TCP and UDP	60
Ultrix	5.7	ICMP and TCP	255
VMS/Multinet	V4.1/V4.2A	TCP	60
VMS/TCPware	V4.1/V4.2A	UDP	30
VMS/Wollongong	V4.2 – 4.5	ICMP	255
VMS/UCX		TCP and UDP	64
Windows	1.1.1.1	TCP	128
Windows	1.1.1.1	UDP	30
Windows	for Workgroups	TCP and UDP	128
Windows	95	TCP and UDP	32
Windows	98	ICMP	32
Windows	98, 98 SE	ICMP	128
Windows	98	TCP	128
Windows	NT 3.51	TCP and UDP	32
Windows	NT 4.0	TCP and UDP	128
Windows	NT 4.0 SP5-		32
Windows	NT 4.0 SP6+		128
Windows	NT 4 WRKS SP 3, SP 6a	ICMP	128
Windows	NT 4 Server SP4	ICMP	128
Windows	ME	ICMP	128
Windows	2000 pro	ICMP/TCP/UDP	128
Windows	2000 family	ICMP	128
Windows	Server 2003		128
Windows	XP	ICMP/TCP/UDP	128
Windows	Vista	ICMP/TCP/UDP	128
Windows	7	ICMP/TCP/UDP	128
Windows	Server 2008	ICMP/TCP/UDP	128
Windows	10	ICMP/TCP/UDP	128

Display Anomalous TCP Flags

By applying the filter below, you will display packets with TCP flag combinations not included in the normal set, helping to identify potential anomalous activity.

Detect unusual TCP flag combinations:

tcp && (!(tcp.flags == 0x02 || tcp.flags == 0x12 || tcp.flags == 0x10 || tcp.flags == 0x01 || tcp.flags == 0x04 || tcp.flags == 0x18))

NMAP Scan Detection Filters

The following filters are designed to detect specific types of Nmap scans by identifying distinctive patterns in ICMP, UDP, and TCP packets. Recognizing these patterns can help threat hunters identify and mitigate reconnaissance activities that may be precursors to more sophisticated attacks. Each filter includes steps for contextual analysis to mitigate false positives since the filters alone will not eliminate legitimate traffic.

TCP Version Detection (-sV) Filters

These filters help identify Nmap service/version detection scans for TCP.

(tcp.flags == 0x12) && (tcp.seq == 0) && (tcp.ack == 0)

Contextual Analysis Steps

1. Review Connection Attempts: Check if the packets are part of legitimate service handshakes by looking at the surrounding traffic.
2. Source IP Analysis: Verify the source IP addresses. Frequent connection attempts from the same IP might indicate scanning.
3. Destination Ports: Determine if the destination ports are commonly used by legitimate services or are unusual.

UDP Version Detection (-sV) Filters

These filters help identify Nmap service/version detection scans.

(udp && not icmp) && (ip.id == 0x1042) && (udp.length == 1452)

Contextual Analysis Steps

1. Source and Destination Analysis: Evaluate if the source and destination IP addresses are associated with legitimate services.
2. Frequency of Occurrence: Check how often these packets appear. High frequency from the same source may suggest scanning.
3. Cross-reference with Logs: Compare with application logs to see if there are corresponding legitimate activities.

SYN Scan (-sS) Filters

These filters detect the SYN scan, which sends SYN packets and waits for SYN-ACK or RST responses.

(tcp.flags == 0x02) && (tcp.seq == 0) && (tcp.ack == 0) && (tcp.len == 0)

Contextual Analysis Steps

1. Check Connection Patterns: Look at the sequence of packets. Legitimate connections should show SYN, SYN-ACK, and ACK sequences.
2. Monitor Source IPs: Identify if the same IP is repeatedly sending SYN packets without completing the handshake.
3. Time of Day: Determine if the packets are occurring during expected network activity hours.

TCP Connect Scan (-sT) Filters

These filters detect the TCP Connect scan, which establishes a full TCP connection.

(tcp.flags == 0x02 || tcp.flags == 0x10) && (tcp.len == 0)

Contextual Analysis Steps

1. Complete Handshake: Verify if the full three-way handshake is occurring.
2. Source and Destination Consistency: Check if the source and destination IPs are consistent with legitimate traffic patterns.
3. Frequency and Patterns: Look for repetitive patterns or high frequency of connections from the same source.

ACK Scan (-sA) Filters

These filters detect ACK scans, used to map firewall rulesets.

(tcp.flags == 0x10) && (tcp.len == 0)

Contextual Analysis Steps

1. Analyze Traffic Flow: Check if these packets are part of normal ACK responses in established connections.
2. Source IP Behavior: Monitor if the source IP is generating unusual amounts of ACK packets.
3. Context with Other Scans: See if these packets coincide with other known scanning activities.

FIN Scan (-sF) Filters

These filters detect FIN scans, which send packets with the FIN flag set.

(tcp.flags == 0x01) && (tcp.len == 0)

Contextual Analysis Steps

1. End of Connections: Verify if these FIN packets are part of legitimate connection terminations.
2. IP Address Analysis: Check if the source IPs are repeatedly sending FIN packets without preceding connection attempts.
3. Time Analysis: Determine if the packets occur during normal shutdown activities or at unusual times.

Window Scan (-sW) Filters

These filters detect window scans, which analyze TCP window size.

(tcp.flags == 0x10) && (tcp.window_size_value > 0)

Contextual Analysis Steps

1. Normal Traffic Comparison: Compare window size values with typical traffic patterns for the network.
2. Source and Destination Analysis: Evaluate if the IP addresses involved are associated with normal activities.
3. Correlation with Other Scans: Look for patterns or correlation with other scanning activities.

NULL Scan (-sN) Filters

These filters detect NULL scans, which send packets with no TCP flags set.

(tcp.flags == 0x00) && (tcp.len == 0)

Contextual Analysis Steps

1. Application Behavior: Check if any known applications might generate packets with no flags.
2. Source IP Patterns: Monitor if the same IP is sending these packets frequently.
3. Network Behavior: Compare with typical network behavior to identify anomalies.

XMAS Scan (-sX) Filters

These filters detect XMAS scans, which set the FIN, PSH, and URG flags.

(tcp.flags == 0x29) && (tcp.len == 0)

Contextual Analysis Steps

1. Unusual Traffic Identification: Determine if there are legitimate reasons for packets with these flags in your network.
2. Source IP Consistency: Evaluate if the source IPs are repeatedly sending such packets.
3. Traffic Patterns: Look for abnormal traffic patterns and times of day when these packets appear.

NMAP OS Discovery filters

The following filters focus on ICMP, UDP, and TCP packets with distinctive characteristics used by Nmap during OS detection scans. Recognizing these patterns allows threat hunters to detect potential network scanning and OS fingerprinting activities, which are often precursors to more sophisticated attacks. This capability is critical in proactive threat detection and network defense strategies

ICMP1

(ip.flags == 0x02) && (ip.dsfield == 0) && (icmp.type == 8) && (icmp.code == 9) && (icmp.seq == 295) && (data.data matches "\x00+") && (data.len == 120)

Detects an ICMP Echo request (ping) with no IP options (ip.flags == 0x02), default DSCP (ip.dsfield == 0), type 8 (Echo Request), code 9, sequence number 295, 120 bytes of data filled with zeros. This specific combination is used by Nmap to identify certain OS responses.

ICMP2

(ip.flags == 0x00) && (ip.dsfield == 4) && (icmp.type == 8) && (icmp.code == 0) && (icmp.seq == 296) && (data.data matches "\x00+") && (data.len == 150)

Identifies an ICMP Echo request with no flags (ip.flags == 0x00), DSCP set to 4 (ip.dsfield == 4), type 8 (Echo Request), code 0, sequence number 296, and 150 bytes of data filled with zeros. This differs from ICMP1 by having a different DS field, ICMP code, sequence number, and data length, showing another pattern used by Nmap.

ICMP Response Types & Codes

Type	Description	Codes
0	Echo Reply	Expand Code 0: No Code
3	Destination Unreachable	Expand Code 0: Net Unreachable Code 1: Host Unreachable Code 2: Protocol Unreachable Code 3: Port Unreachable Code 4: Fragmentation Needed and Don't Fragment was Set Code 5: Source Route Failed Code 6: Destination Network Unknown Code 7: Destination Host Unknown Code 8: Source Host Isolated Code 9: Communication with Destination Network is Administratively Prohibited Code 10: Communication with Destination Host is Administratively Prohibited Code 11: Destination Network Unreachable for Type of Service Code 12: Destination Host Unreachable for Type of Service Code 13: Communication Administratively Prohibited Code 14: Host Precedence Violation Code 15: Precedence Cutoff in Effect
4	Source Quench	Expand Code 0: No Code
5	Redirect	Expand Code 0: Redirect Datagram for the Network Code 1: Redirect Datagram for the Host Code 2: Redirect Datagram for the Type of Service and Network Code 3: Redirect Datagram for the Type of Service and Host
8	Echo Request	Expand Code 0: No Code
11	Time Exceeded	Expand Code 0: Time to Live exceeded in Transit Code 1: Fragment Reassembly Time Exceeded
12	Parameter Problem	Expand Code 0: Pointer indicates the error Code 1: Missing a Required Option Code 2: Bad Length

UDP

(udp && not icmp) && (ip.id == 0x1042) && (data.len == 300) && (data.data matches "\x43{300}")

Matches UDP packets that are not ICMP responses (udp && not icmp), with IP ID set to 0x1042, data length of 300 bytes, and payload filled with the character 'C' (0x43) repeated 300 times. This is a distinct pattern Nmap uses to provoke specific responses for OS fingerprinting.

T2

(ip.flags == 0x02) && (tcp.flags == 0x0000) && (tcp.window_size_value == 128) && (tcp.options == 03:03:0a:01:02:04:01:09:08:0a:ff:ff:ff:ff:00:00:00:00:04:02)

Detects a TCP packet with no TCP flags set (tcp.flags == 0x0000), IP don't fragment flag set (ip.flags == 0x02), a window size of 128, and specific TCP options. This pattern is used by Nmap to test how different OSs handle a packet with these settings.

T3

(ip.flags == 0x00) && (tcp.flags == 0x002b) && (tcp.window_size_value == 256) && (tcp.options == 03:03:0a:01:02:04:01:09:08:0a:ff:ff:ff:ff:00:00:00:00:04:02)

Matches a TCP packet with PSH, URG, and FIN flags set (tcp.flags == 0x002b), no IP flags (ip.flags == 0x00), a window size of 256, and specific TCP options. This differs from T2 by having different TCP flags, IP flags, and window size, showing another Nmap scanning technique.

T4

(ip.flags == 0x02) && (tcp.flags == 0x0010) && (tcp.window_size_value == 1024) && (tcp.options == 03:03:0a:01:02:04:01:09:08:0a:ff:ff:ff:ff:00:00:00:00:04:02)

Detects a TCP packet with ACK flag set (tcp.flags == 0x0010), IP don't fragment flag set (ip.flags == 0x02), a window size of 1024, and specific TCP options. This is used by Nmap to identify OS behaviors with these particular settings.

T5

(ip.flags == 0x00) && (tcp.flags == 0x0002) && (tcp.window_size_value == 31337) && (tcp.options == 03:03:0a:01:02:04:01:09:08:0a:ff:ff:ff:ff:00:00:00:00:04:02)

Matches a TCP packet with SYN flag set (tcp.flags == 0x0002), no IP flags (ip.flags == 0x00), an unusual window size of 31337, and specific TCP options. This pattern is used by Nmap to probe for OS-specific responses to SYN packets with a unique window size.

T6

(ip.flags == 0x02) && (tcp.flags == 0x0010) && (tcp.window_size_value == 32768) && (tcp.options == 03:03:0a:01:02:04:01:09:08:0a:ff:ff:ff:ff:00:00:00:00:04:02)

Detects a TCP packet with ACK flag set (tcp.flags == 0x0010), IP don't fragment flag set (ip.flags == 0x02), a window size of 32768, and specific TCP options. This is another Nmap scan pattern used to differentiate OS behaviors based on this configuration.

T7

((tcp.flags == 0x0029) && (tcp.window_size_value == 65535)) && (tcp.options == 03:03:0f:01:02:04:01:09:08:0a:ff:ff:ff:ff:00:00:00:00:04:02)

Matches a TCP packet with PSH, URG, and FIN flags set (tcp.flags == 0x0029), a maximum window size of 65535, and specific TCP options. This pattern helps Nmap identify OS responses to packets with these particular settings, highlighting another method of OS fingerprinting.

Miscellaneous

AXFR Attempts

Look for DNS traffic on TCP rather than UDP

dns && tcp.port==53 && (_ws.col.info contains "AXFR")

or

dns.qry.type==252

The more narrowed filter for failed attempts would be:

(dns.qry.type == 252) && (dns.flags.rcode != 0)

HTTP Activity

POST requests that attempt to test for command injection, SQLi, etc.

http.request.method==POST

Lifecycle: Attack Phase

ARP Poisoning

ARP poisoning, also known as ARP spoofing, is a technique used by attackers to intercept, modify, or disrupt network traffic. This attack exploits the ARP protocol, which resolves IP addresses to MAC addresses, by sending false ARP messages to a network. Indicators of ARP poisoning can include an excessive number of ARP replies (arp.opcode==2) without corresponding ARP requests. These unsolicited ARP replies are a strong sign that a device on the network is attempting to poison the ARP cache of other devices, redirecting their traffic for malicious purposes. Monitoring network traffic for these anomalies using filters such as arp.opcode==2 can help identify and mitigate ARP poisoning attacks.

arp.opcode==2

Using the filter arp.duplicate-address-detected helps identify ARP poisoning by detecting instances where multiple devices claim the same IP address, a common sign of ARP spoofing attacks.

arp.duplicate-address-detected

DNS Spoofing

DNS spoofing, also known as DNS cache poisoning, involves an attacker inserting false DNS responses into a DNS server's cache, redirecting traffic to malicious sites. To detect DNS spoofing, you can use several filters:

1. Multiple DNS Responses

Monitoring for multiple DNS responses (dns.flags.response == 1) for the same query can indicate an attack, especially if they come from different sources.

dns.flags.response == 1

2. Checking Queried Domain

Use dns.qry.name to check the queried domain.

dns.qry.name == "example.com"

3. Verifying Response IP Address

Use dns.a for IPv4 addresses and dns.aaaa for IPv6 addresses to verify the response IP address against known good values.

dns.a == 1.2.3.4 || dns.aaaa == 2001:db8::1

4. Discrepancies in TTL Values

Observing discrepancies in TTL values (dns.resp.ttl) for the same domain can help identify suspicious activity, as legitimate DNS responses typically have consistent TTL values.

dns.resp.ttl

IP Spoofing

IP spoofing involves an attacker sending IP packets with a forged source IP address to disguise their identity or impersonate another system. Detecting IP spoofing can be challenging, but certain indicators and filters can help. Monitoring for inconsistencies in IP packet headers, such as mismatched ip.src and mac.src addresses, can reveal spoofed packets. This discrepancy arises because while the attacker can forge the source IP address, they often cannot forge the MAC address in the same way.

Example

Say you have a device with the following network configuration: - Device A: IP address 192.168.1.10, MAC address 00:11:22:33:44:55

In normal traffic from Device A, a packet might look like this:

• Source IP (ip.src): 192.168.1.10
• Source MAC (mac.src): 00:11:22:33:44:55

Now, imagine an attacker on the same network trying to spoof Device A's IP address:

• Attacker: IP address 192.168.1.10 (forged), MAC address 66:77:88:99:AA:BB (attacker's real MAC)

A packet from the attacker would look like this:

• Source IP (ip.src): 192.168.1.10 (forged)
• Source MAC (mac.src): 66:77:88:99:AA:BB (attacker's actual MAC)

Detection

By monitoring for mismatches between the ip.src and mac.src fields, you can detect potential IP spoofing:

ip.src==192.168.1.10 && mac.src!=00:11:22:33:44:55

To find such inconsistencies, the following example display filter could help:

(ip.src==192.168.1.10 && eth.src!=00:11:22:33:44:55)

This filter will highlight packets claiming to come from 192.168.1.10 but with a MAC address different from 00:11:22:33:44:55, helping to identify IP spoofing attempts.

Additionally, check for unusual patterns of ip.id and ip.ttl values that don't align with expected traffic from the purported source. Filters like ip.src to track source IP addresses and eth.src to monitor corresponding MAC addresses can aid in identifying and mitigating IP spoofing attempts.

Unusual IP ID and TTL Patterns:

ip.id != expected_id || ip.ttl != expected_ttl

Source IP Address:

ip.src == 192.168.1.1

Source MAC Address:

eth.src == 00:11:22:33:44:55

What is the ip.id?

The ip.id field, also known as the Identification field, is a 16-bit field in the IP header used to uniquely identify fragments of an original IP datagram. When an IP packet is fragmented into smaller packets to be transmitted over the network, the ip.id value remains the same for all fragments of the original packet, allowing the receiving end to reassemble them correctly.

DHCP Poisoning

DHCP poisoning, also known as DHCP spoofing, is an attack where a rogue DHCP server is introduced to the network, distributing incorrect IP configurations to clients. This can redirect traffic to malicious servers or disrupt network connectivity.

DHCP Process

• DHCPDISCOVER: The client broadcasts a DHCPDISCOVER packet to locate available DHCP servers.
  
• DHCPOFFER: The DHCP server responds with a DHCPOFFER packet. This packet includes the client's new IP address, subnet mask, lease duration, and other configuration parameters.
  
• DHCPREQUEST: The client broadcasts a DHCPREQUEST packet, indicating its acceptance of the offered IP address and configuration parameters.
  
• DHCPACK: The DHCP server sends a DHCPACK packet to the client, finalizing the lease and confirming the IP address and configuration parameters.
  

Scenario:

In a legitimate network:

• DHCP Server: IP 192.168.1.1, MAC 00:11:22:33:44:55
• Expected IP Range: 192.168.1.100 to 192.168.1.200
• Subnet Mask: 255.255.255.0
• Gateway: 192.168.1.1

An attacker sets up a rogue DHCP server:

• Rogue DHCP Server: IP 192.168.1.2, MAC 66:77:88:99:AA:BB
• Provides a different IP range or gateway: IP 192.168.2.100 to 192.168.2.200

Here are some indicators and suggested filters for detecting DHCP poisoning:

1. Multiple DHCP Offers:

   • Legitimate networks typically have a single DHCP server. Multiple DHCP offer packets (dhcp.option.dhcp == 2) from different MAC addresses can indicate a rogue DHCP server.

     dhcp.option.dhcp==2
     

2. Unexpected DHCP Servers:

   • Monitor for DHCP offers originating from unexpected MAC addresses or IP addresses. Compare these against a whitelist of known, legitimate DHCP servers.

     dhcp.option.dhcp==2 && !(eth.src == known_mac_1 || eth.src == known_mac_2)
     

3. Inconsistent IP Lease Information:

   • DHCP leases providing unusual or inconsistent IP address ranges, subnet masks, or gateways that don't match the network's expected configuration can signal a DHCP poisoning attack.

     bootp.option.subnet_mask != 255.255.255.0 || bootp.option.router != 192.168.1.1
     

4. Rogue DHCP Acknowledgements:

   • Similar to multiple offers, acknowledgements from unknown or multiple sources (dhcp.option.dhcp == 5) can indicate a rogue server.

     dhcp.option.dhcp==5
     

5. Client Requests with Multiple Servers Replies:

   • Observe the pattern of DHCP requests (dhcp.option.dhcp == 3) and replies. Anomalies in the expected sequence or multiple servers responding can highlight an issue.

     dhcp.option.dhcp==3
     

FTP

Malicious FTP traffic can involve unauthorized access, data exfiltration, or the transfer of malicious files.

Unusual FTP Commands

Look for unexpected or rarely used FTP commands, such as MKD (make directory), DELE (delete file), and RMD (remove directory).

ftp.request.command == "MKD" || ftp.request.command == "DELE" || ftp.request.command == "RMD"

Large Data Transfers

Monitor for unusually large file transfers, which could indicate data exfiltration.

ftp-data && (data.len > 1000000)  // Adjust the size threshold as needed

Repeated Login Attempts

Multiple failed login attempts can signify brute force attacks.

ftp.response.code == 530  // Indicates login failed

Anonymous Logins

Anonymous access or logins outside of expected times can be suspicious.

ftp.request.command == "USER" && ftp.request.arg == "anonymous"

Transfers of Executable Files

Detect the transfer of potentially malicious files, such as .exe, .bat, or scripts.

ftp-data && (ftp-data contains ".exe" || ftp-data contains ".bat" || ftp-data contains ".vbs" || ftp-data contains ".sh")

Using these filters in combination can help identify and mitigate malicious FTP activity, contributing to a proactive network defense strategy.

HTTP

HTTP Response Codes

200 OK: The resource has been modified since the specified date; the full resource is returned.
301 Moved Permanently: The resource has been moved to a new URL.
302 Found is the most commonly used code for indicating a temporary redirection.
304 Not Modified: The resource has not been modified since the specified date; no body content is returned.
307 Temporary Redirect is a stricter version of 302, ensuring that the HTTP method remains unchanged.
400 Bad Request: The request is malformed or invalid.
404 Not Found: The resource could not be found on the server.
412 Precondition Failed: The server cannot meet one of the preconditions in the request.

Session Hijacking Indicators

1. Multiple Sessions from Different IPs but Same Session ID

   • An indication of session hijacking is when the same session ID is observed from different IP addresses.

     http.cookie contains session_id && ip.src != user_ip_address
     

2. Unusual User-Agent Strings

   • An indication of session hijacking is when requests with different User-Agent strings come from the same session.

     http.request && http.cookie contains session_id && http.user_agent != expected_user_agent
     

3. Sudden Geolocation Changes

   • An indication of session hijacking is when the same session ID is seen originating from different geolocations in a short time span.

     (Note: Requires external geolocation analysis)
     

4. Abnormal Request Patterns

   • An indication of session hijacking is when there are unusual patterns of HTTP requests, such as accessing admin pages or sensitive resources unexpectedly.

     http.request.method==POST && http.cookie contains session_id && http.request.uri_path contains sensitive_resource
     

5. Reused Session IDs

   • An indication of session hijacking is when session IDs are reused after logout or expiration.

     http.cookie contains session_id && session_id in expired_sessions
     

Use these filters with IDS or SIEM systems to monitor for session hijacking attempts. Implementing HTTPS, secure cookie attributes, and proper session management also helps mitigate risks.

When a conditional HTTP GET request is submitted with an "If-Modified-Since" header, the server can respond with one of the following HTTP status codes: 200, 304, 400, and 412.

Malware Indicators

The following filter is designed to find executables or files downloaded that could be associated with malware. It does not mean the files are malicious, but it indicates they are worth examining if malware is suspected.

http.request.uri matches "(?i)\\.(exe|dll|bin|com|dat|scr|zip|vbs|js|jar|pif|bat)"

Using the Filter in Wireshark

1. Open Wireshark and load your capture file.
2. Enter the filter provided above into the filter bar at the top of the Wireshark window and press Enter.
3. Analyze the filtered traffic to identify any HTTP requests that contain the specified file extensions.
4. Right-click on a suspicious packet and select Follow > HTTP Stream to view the entire download session.
5. Export the suspicious object:
6. Right-click on the packet again and choose Export Objects > HTTP.
7. In the dialog that appears, select the suspicious file and click Save to download it.

Uploading to VirusTotal

1. Go to VirusTotal.
2. Click on "Choose file" and select the downloaded file.
3. Upload the file and wait for VirusTotal to analyze it.
4. Review the results to determine if the file is flagged as malicious by any of the antivirus engines.

This process helps identify and analyze potentially malicious files that have been downloaded, providing an extra layer of security analysis when investigating suspicious network activity.

SMB

SMB (Server Message Block) protocol can be exploited for various malicious activities, including unauthorized access, data theft, and buffer overflow attacks. Detecting suspicious SMB traffic is vital for protecting network resources.

Suspicious SMB Operations

Monitor for specific SMB operations that may indicate malicious activity. For example, the operation srvsvc.opnum == 31 corresponds to the NetPathCanonicalize function, which can be exploited in certain attacks.

srvsvc.opnum == 31

Buffer Overflow Attempts

Buffer overflow vulnerabilities occur when an attacker sends more data to a buffer than it can handle, potentially allowing execution of malicious code. Monitoring for unusually large buffer sizes in SMB requests can help identify such attempts. The filter srvsvc.srv.svc_NetPathCanonicalize.maxbuf > 200 checks for buffer sizes larger than 200, which can be indicative of a buffer overflow attempt.

srvsvc.srv.svc_NetPathCanonicalize.maxbuf > 200

Unusual File Access Patterns

Look for unusual or unexpected file access patterns, such as repeated access to sensitive files or directories.

smb2.filename contains "sensitive_file" || smb2.filename contains "confidential"

Failed Login Attempts

Multiple failed login attempts can signify brute force attacks aimed at gaining unauthorized access to SMB shares.

smb2.nt_status == 0xc000006d  // STATUS_LOGON_FAILURE

Transfers of Executable Files

Detect the transfer of potentially malicious executable files over SMB, such as .exe, .bat, or scripts.

smb2.filename contains ".exe" || smb2.filename contains ".bat" || smb2.filename contains ".vbs" || smb2.filename contains ".sh"

Lifecycle: Postexploitation/Proliferation Phase

Botnets

Botnets are networks of compromised devices controlled by an attacker, often used for large-scale malicious activities like DDoS attacks, spamming, and data theft. Detecting botnet activity involves monitoring for unusual network traffic patterns and known botnet command and control (C&C) communication indicators.

Unusual Outbound Traffic

Monitor for large volumes of outbound traffic to unusual or known malicious IP addresses.

ip.dst == suspicious_ip

C&C Communication

Detect communication with known C&C servers using threat intelligence feeds.

ip.dst in [list_of_known_c2_ips]

Beaconing Patterns

Identify regular, periodic traffic that may indicate beaconing to a C&C server.

frame.time_delta > beacon_threshold

Anomalous Protocol Usage

Look for uncommon protocols or ports being used within the network.

(tcp.port == uncommon_port) || (udp.port == uncommon_port)

SMB

SMB (Server Message Block) protocol can be exploited for various malicious activities, including unauthorized access, data theft, and buffer overflow attacks. Detecting suspicious SMB traffic is vital for protecting network resources.

Suspicious SMB Operations

Monitor for specific SMB operations that may indicate malicious activity. For example, the operation srvsvc.opnum == 31 corresponds to the NetPathCanonicalize function, which can be exploited in certain attacks.

srvsvc.opnum == 31

Buffer Overflow Attempts

Buffer overflow vulnerabilities occur when an attacker sends more data to a buffer than it can handle, potentially allowing execution of malicious code. Monitoring for unusually large buffer sizes in SMB requests can help identify such attempts.

srvsvc.srv.svc_NetPathCanonicalize.maxbuf > 200

Unusual File Access Patterns

Look for unusual or unexpected file access patterns, such as repeated access to sensitive files or directories.

smb2.filename contains "sensitive_file" || smb2.filename contains "confidential"

Failed Login Attempts

Multiple failed login attempts can signify brute force attacks aimed at gaining unauthorized access to SMB shares.

smb2.nt_status == 0xc000006d  // STATUS_LOGON_FAILURE

Transfers of Executable Files

Detect the transfer of potentially malicious executable files over SMB, such as .exe, .bat, or scripts.

smb2.filename contains ".exe" || smb2.filename contains ".bat" || smb2.filename contains ".vbs" || smb2.filename contains ".sh"

NBNS

NBNS (NetBIOS Name Service) spoofing can be used by attackers to redirect network traffic to malicious devices by responding to name resolution requests with false information.

Unexpected NBNS Responses

Monitor for NBNS responses (nbns.flags.response == 1) from unauthorized sources.

nbns.flags.response == 1 && !(eth.src == known_mac_1 || eth.src == known_mac_2)

Multiple NBNS Responses

Detect multiple NBNS responses to the same query, which can indicate a spoofing attempt.

nbns.flags.response == 1 && nbns.id == query_id && nbns.count.answers > 1

Unusual NBNS Traffic Patterns

Look for unusual or unexpected patterns in NBNS traffic that may signify malicious activity.

nbns && frame.time_delta > threshold

RPC

Remote Procedure Call (RPC) protocol can be exploited by attackers to execute commands on remote systems without proper authorization.

Unauthorized RPC Requests

Monitor for RPC requests from unauthorized sources.

rpc.req_id && !(ip.src == known_ip_1 || ip.src == known_ip_2)

Suspicious RPC Operations

Detect specific RPC operations that are often associated with attacks.

rpc.opnum == suspicious_opnum

Anomalous RPC Traffic

Look for unusual traffic patterns in RPC communications.

rpc && frame.time_delta > threshold

TLS

TLS (Transport Layer Security) is used to encrypt communications, but certain metadata and handshake patterns can be analyzed to detect anomalies and potential threats. Additionally, I found the following resources helpful:

• RFC5246
  
• RFC8446
  
• TLS Handshake Deep-Dive video resource The TLS Handshake is discussed at 22:50.

Client Hello

Identify initial handshake attempts which can indicate probing or unauthorized access attempts.

tls.handshake.type == 1

Server Hello

Monitor for server responses to client hello messages.

tls.handshake.type == 2

Certificates

Analyze certificate exchanges for anomalies or the use of compromised certificates.

tls.handshake.type == 11

Change Cipher Spec

Detect the transition to encrypted communications which may hide malicious activity.

tls.record.content_type == 20

Random Notes

Man-in-the-middle (MitM) attacks are generally easier to perform at the lower layers of the OSI model, specifically at the Data Link layer (Layer 2) and the Network layer (Layer 3). Here’s why:

Data Link Layer (Layer 2)

• ARP Spoofing: Attackers can exploit the Address Resolution Protocol (ARP) to associate their MAC address with the IP address of a legitimate host, allowing them to intercept, modify, or block traffic intended for that host.

Network Layer (Layer 3)

• IP Spoofing: Attackers can manipulate IP packets to masquerade as a different device, potentially routing traffic through their machine.
• DNS Spoofing: Attackers can manipulate DNS responses to redirect traffic to malicious sites.

Reasons for Easier Attacks at Lower Layers:

1. Less Security: Lower layers often have fewer security mechanisms compared to higher layers.
2. Traffic Control: These layers are responsible for routing and forwarding packets, making it easier for attackers to intercept and manipulate data.
3. Protocol Vulnerabilities: Protocols at these layers (like ARP and DNS) are inherently vulnerable to spoofing and other manipulation techniques.

Higher layers, such as the Transport (Layer 4) and Application (Layer 7) layers, typically have more robust security mechanisms like encryption (e.g., SSL/TLS) that make MitM attacks more challenging without additional sophisticated techniques.