🔸Before any OT/ICS risk assessment, profile the system.

🔸System profiling = a deliberate inventory of components, connections, and weak points of the complete System under Consideration (SuC) so your risk model is built on facts, not assumptions.

🔸In practice, that means mapping interfaces, routes, listeners, identities, and services first. As shown in the depicted PDF file, I compiled a concise Linux/Windows cheat sheet for this phase.

🔸Use these commands: if the OT asset runs a general-purpose OS (e.g., HMI/SCADA servers, engineering workstations, jump hosts, historians).

Download the PDF

Download the PDF

The MITRE ATT&CK framework, created in 2013, is a detailed catalog of how attackers operate and common attack patterns. It maps real-world TTPs (Tactics (the “why”), Techniques (the “how”), and Procedures) instead of focusing on compliance or strategy. This helps teams detect threats, test defenses, and align their tools with actual attacker behavior.

The framework includes three main matrices:

• Enterprise: Covers Windows, Linux, cloud, and SaaS. It tracks tactics like data theft, lateral movement, and privilege escalation.
• ICS (Industrial Control Systems): Focuses on attacks against physical systems in OT environments such as factories or power plants. Techniques aim to disrupt operations or manipulate industrial controls.
• Mobile: Details threats specific to Android and iOS, including mobile-specific attack methods.

The key difference between Enterprise and ICS lies in the targets and impact. Enterprise attacks often steal data or gain control of IT systems. ICS attacks aim to disrupt physical processes and can threaten safety or cause large economic losses. MITRE ATT&CK highlights this gap by modeling threats for each environment, helping organizations secure both IT and OT systems.

Download the PDF

UDP flood attacks exploit the lack of connection control in the User Datagram Protocol. Unlike TCP, UDP doesn’t manage sessions, track connections, or limit traffic. Attackers take advantage by sending large numbers of UDP packets to various ports on a target.

If no application listens on a given port, the system often replies with an ICMP “Destination Unreachable” message. These replies consume bandwidth and processing power. Attackers also spoof source IP addresses to hide their identity and misdirect response traffic.

UDP floods resemble sudden spikes in legitimate traffic, but the cause differs. DDoS attacks are intentional and hostile, while user surges are natural. Many modern attacks also use amplification. An attacker sends small UDP requests to servers like DNS, NTP, or memcached, using the victim’s IP. The servers respond with much larger messages to the victim, greatly increasing the impact.

One major case was the 2018 attack on GitHub using memcached servers, which hit 1.3 Tbps. Even without amplification, a UDP flood can saturate a target if the upstream network pushes more traffic than the target can absorb.

Key Packet Indicators:

UDP floods involve a high rate of UDP packets aimed at one or many ports on a target. These packets have an IP protocol value of 17 (ip.proto==17) and no flags, unlike TCP. Attackers often target either known service ports to overload them or random ports to trigger ICMP “destination unreachable” replies. They usually spoof or randomize the source IP and port. In basic floods, the payload carries junk or is nearly empty, since the goal is volume. An important sign is an unusual spike in UDP traffic, especially if the system usually handles mostly TCP. A web server that typically sees 95% TCP traffic showing a jump in UDP, especially to odd ports, should raise concern. A related sign is a surge of ICMP Type 3 messages going out from the victim to spoofed sources. Monitoring tools should track UDP packet rates and bandwidth. A sharp rise above normal levels often signals a flood. If many destination ports on the target are hit rapidly, it may look like a scan but is more likely an attack meant to drain resources. Normal UDP traffic follows known patterns tied to services like DNS (port 53) or VoIP. It usually includes a clear request and response. UDP flood traffic, by contrast, is random or targets ports that cause heavy load. It often doesn’t expect a reply. Amplified floods, like DNS-based ones, use small queries to trigger large responses from third-party servers. This results in large UDP packets hitting the victim, often marked with a source port of 53. A pattern of high UDP volume, frequent ICMP “port unreachable” replies, or broad port targeting points strongly to a flood attack.

Wireshark:

Relationships are like CSVs—one wrong delimiter, and it all breaks.

CSV stands for Comma-Separated Values. It’s a plain text format that stores tables. Each line holds one record, and fields within a record are split by commas. Many programs use CSV files because they’re easy to create, read, and move between systems. To work with CSV data from the command line, especially for filtering and analyzing, csvkit is a useful tool. Down are easy commands for basic CSV file EDA:

Step 1: Install or upgrade csvkit (in windows 11)

pip install --upgrade csvkit

Step 2: Extract rows where the “Attack_type” column contains “Normal”

csvgrep -c "Attack_type" -r "Normal" data.csv > normal_rows.csv

Step 3: View structure and summary stats of the filtered file

csvstat ransomware_rows.csv

Step 4: Check for missing or summary stats in the “dns.qry.name.len” column (same as step 3 but here for specific column)

csvstat -c "dns.qry.name.len" normal_rows.csv

Step 5: See frequency distribution for “dns.qry.name.len”

csvcut -c "dns.qry.name.len" normal_rows.csv | csvstat --freq

In IT network traffic, granularity refers to the level of detail at which network data is capturered or monitored.

High Granularity (packet-level):
Tracks network traffic at the packet level. Shows details for each connection and short-term changes. Helps with precise monitoring and troubleshooting. Needs more storage and processing power.

Datasets examples:

Low Granularity (flow-level):
Groups traffic data over longer periods. Shows general patterns and long-term trends. Misses specific events but helps spot broader shifts in behavior.

Datasets examples:

My TCP relationship status? It’s complicated, SYN but no ACK!!

TCP SYN Flood Attack exploits the fundamental weakness in TCP’s three-way handshake mechanism. During normal TCP connection establishment, a client sends a SYN packet, the server responds with SYN-ACK, and the client completes the handshake with an ACK. The server maintains connection state in a backlog queue during this process.

In a SYN flood, which is a type of volumetric DDoS attack, the attackers send a large number of SYN packets with fake source IP addresses. These spoofed packets prevent the server’s SYN-ACK replies from reaching a real client, leaving many half-open connections. The server reserves memory and processing power for each attempt, quickly filling its connection queue.

Once the queue is full, new legitimate requests can’t get through, blocking access. The attack is efficient because it takes little effort to send spoofed SYNs, but the server has to commit real resources for each one. The method exploits TCP’s stateful design, where a server must track each incoming connection. Unlike bandwidth attacks, this one overwhelms the server’s ability to manage new connections.

Key Packet Indicators:

As mentioned above, in a SYN flood, the attacker sends a large number of TCP SYN packets, which are normally used to start a connection, but never completes the handshake. These packets often have fake or inconsistent source IP addresses and ports. The destination port is usually an open service port, like TCP port 80 on a web server, because open ports force the server to allocate resources for each request.

Normal TCP connections use a three-way handshake: SYN, SYN-ACK, and ACK. But in a SYN flood, most packets are SYNs without matching ACKs. The server replies with SYN-ACKs, then waits. Its backlog of half-open connections fills up quickly. Packet captures show many SYNs, lots of SYN-ACKs, and few or no final ACKs. On the server, many connections remain in the SYN_RECV state, visible with tools like netstat.

Since the SYNs often use spoofed IPs, filtering by source is hard. These packets might have odd TTL values or uncommon IP options, but that’s not always the case. The TCP headers may also contain abnormal values, like a sequence number of 0, but this varies.

The main indicator is the skewed traffic pattern: a flood of SYNs with few ACKs or RSTs in return. In normal traffic, SYNs make up a small share. In a SYN flood, they dominate. You might also see some RST packets, often from real IP owners reacting to unexpected SYN-ACKs.

TCP flag analysis helps too. A stream of packets with only the SYN flag and no matching ACK or RST from the client side stands out. Some real clients abort incomplete connections with RST, but spoofed IPs often trigger stray RSTs instead.

This lopsided SYN-to-ACK ratio and the lack of full handshakes are the core signs of a SYN flood.

Wireshark:

• To find all SYNs without ACK: tcp.flags.syn==1 and tcp.flags.ack==0
•  Statistics → Conversations → TCP → Sort by “Packets”