Lab Experiment 001 — Reconnaissance, Disruption, and Detection Engineering

Scan 1 — SYN Scan (Stealth Scan)

• A SYN-based scan (-sS) was performed to simulate a stealthy reconnaissance technique. This scan initiates TCP handshakes without completing them, reducing visibility in some logging environments.

Observation — Limited Detection of SYN Scan Activity

During Phase 1, a SYN-based scan (nmap -sS) was conducted against the target system to simulate reconnaissance behaviour. This scan type is commonly referred to as a “stealth scan” because it does not complete the full TCP three-way handshake, instead sending SYN packets and interpreting responses without establishing a full connection.

Despite the scan successfully identifying open ports (22/SSH and 80/HTTP), no corresponding alerts were generated by Suricata, and no events were visible in EveBox during the observation window.

This outcome suggests that:

• The scan traffic did not match any active Suricata detection rules or alert thresholds.
• The behaviour may have been interpreted as low-noise or non-anomalous within the current rule set.
• Default or deployed rules may prioritise more explicit or aggressive patterns (e.g., full connections, malformed packets, or high-frequency bursts) over lightweight reconnaissance techniques.

From a defensive perspective, this highlights an important limitation:

Not all reconnaissance activity is inherently detected by default IDS configurations, particularly when using low-noise or “stealthy” scanning methods.

This reinforces the need for:

• Fine-tuned rule sets or custom signatures to detect scan patterns
• Correlation over time (e.g., repeated SYN attempts across ports)
• Supplementary monitoring approaches beyond signature-based detection

Scan 2 — Service/Version Detection (Aggressive Scan)

• A more aggressive scan (-A) was executed to enumerate services, versions, and OS details.

Observation — Detection of Aggressive Scan Activity

In this phase, an aggressive scan (nmap -A) was conducted against the target system. Unlike the earlier SYN scan, this method performs service detection, version enumeration, and additional probing, generating more noticeable network activity.

Suricata successfully generated multiple alerts during this scan, which were also visible in EveBox. These included:

• ET SCAN Possible Nmap User-Agent Observed — indicating identifiable Nmap probing behaviour
• Protocol anomalies such as one-directional application layer detection
• ICMP-related alerts reflecting auxiliary network activity during the scan

The presence of these alerts demonstrates that:

• More intrusive or feature-rich scans are easier for IDS systems to detect
• Signature-based rules can identify known scanning tools through patterns such as user-agent strings and traffic behaviour
• Increased interaction with services raises the likelihood of triggering detection mechanisms

Scan 3 — Aggressive Vulnerability Enumeration Scan

• An aggressive Nmap scan was conducted using service and vulnerability detection scripts to simulate deep reconnaissance and target profiling.
• This scan combined OS detection, service enumeration, and vulnerability mapping using NSE scripts.

Observation — High Visibility of Script-Based Enumeration

In this phase, an advanced scan (nmap -A -T4 --script vuln) was performed, incorporating vulnerability detection scripts alongside service and version enumeration. This significantly increased the level of interaction with the target system.

Suricata generated a high volume of alerts, clearly visible in EveBox. These included:

• ET SCAN Possible Nmap User-Agent Observed — confirming identifiable scanning behaviour
• Exploit-related signatures (e.g., Cisco config disclosure, Drupal SQLi attempts) triggered by vulnerability scripts
• Web server access attempts and application-layer interactions
• Informational alerts such as cleartext credential indicators and ICMP activity

This demonstrates that:

• Script-based scans generate highly detectable traffic due to their depth and interaction level
• IDS signatures can flag both reconnaissance and simulated exploitation attempts
• Increased scan complexity leads to broader alert coverage across multiple detection categories

Multiple traffic variations were used, including continuous flood mode, time-bound bursts, and randomised source addresses. These variations allowed observation of how Suricata responds to different disruption scenarios, including alert volume, signature repetition, and the impact of obfuscated source attribution.

Denial of Service (DoS) simulation - HPING3

• Generated a high-rate TCP SYN flood using hping3, simulating repeated connection attempts without completing handshakes, resulting in large volumes of valid but context-less traffic.

Observations

A TCP SYN flood was generated using hping3 in flood mode, producing a high volume of traffic targeting port 80 on the victim system. The command transmitted TCP SYN packets at maximum possible speed without completing the TCP handshake or processing responses.

Each packet simulated the initial stage of a connection request, resulting in a large number of half-open connection attempts. This behaviour is commonly associated with SYN flood denial-of-service activity, where system resources may be exhausted by incomplete connections.

Despite the intensity of the traffic, no corresponding alerts were generated within Suricata or EveBox. Analysis of the active rule set indicates that detection capabilities were primarily focused on protocol anomalies, malformed packets, and application-layer inconsistencies. The SYN flood traffic, while high in volume, consisted entirely of valid and well-formed TCP packets without anomalous characteristics or identifiable signatures.

As a result, the traffic did not match any existing detection rules and was treated as normal network behaviour. This highlights a limitation of signature-based IDS configurations, where high-rate or disruptive traffic may remain undetected in the absence of specific DoS or threshold-based rules.

Detection Gap Mitigation — Custom SYN Flood Rule Engineering

After reviewing the existing Suricata rule set and performing targeted experimentation, it was observed that there were no rules designed to detect high-rate SYN traffic or flood-based behaviour. To address this gap, four custom rules were developed to improve visibility of SYN-based scanning and denial-of-service patterns.

1. alert tcp any any -> any 80 (msg:"LOCAL Possible SYN Flood to HTTP (high rate)"; flags:S; flow:stateless; detection_filter:track by_src, count 100, seconds 1; classtype:attempted-dos; sid:1000001; rev:1;)
2. alert tcp any any -> any 80 (msg:"LOCAL Possible SYN Flood to HTTP (lab threshold)"; flags:S; flow:stateless; detection_filter:track by_src, count 30, seconds 1; classtype:attempted-dos; sid:1000002; rev:1;)

The first two rules focus specifically on traffic targeting port 80. One uses a higher threshold (100 packets per second) to detect more aggressive flood behaviour, while the second uses a lower threshold (30 packets per second) to make detection easier within a lab environment. This ensures that both realistic and constrained test scenarios can be captured effectively.

3. alert tcp any any -> any any (msg:"LOCAL Possible SYN Flood (any port, high rate)"; flags:S; flow:stateless; detection_filter:track by_src, count 150, seconds 1; classtype:attempted-dos; sid:1000003; rev:1;)

The third rule expands detection across all ports, allowing identification of SYN flood behaviour regardless of the targeted service. This makes the detection more flexible and applicable beyond just web traffic.

4. alert tcp any any -> any any (msg:"LOCAL Possible SYN Scan or Burst SYN Activity"; flags:S; flow:stateless; detection_filter:track by_src, count 40, seconds 5; classtype:network-scan; sid:1000004; rev:1;)

The fourth rule is designed to detect slower or burst-based SYN activity, which may indicate scanning rather than flooding. By using a longer time window with a moderate threshold, it helps differentiate between rapid floods and distributed or less aggressive probing behaviour.

Updates

1. hping3 SYN Flood Execution

A high-volume TCP SYN flood was initiated using hping3 in flood mode, rapidly transmitting SYN packets to the target system on port 80 without completing the TCP handshake.

2. Suricata Detection Output (fast.log)

Following the implementation of custom rules, Suricata successfully detected the SYN flood activity, generating repeated alerts indicating high-rate SYN traffic and potential denial-of-service behaviour.

3. EveBox Alert Correlation

EveBox presents the generated alerts in a structured format, grouping and categorising the SYN flood activity, providing clear visibility into detection events triggered by the custom rules.

DoS Attempt - 2

A TCP SYN flood was initiated from the Kali system using hping3, rapidly transmitting a large volume of SYN packets to the target host on port 80. This generated sustained, high-rate traffic without completing TCP handshakes, simulating denial-of-service behaviour.

The impact of this activity is reflected in the Suricata logs on the Ubuntu system, where the previously implemented custom rules triggered repeatedly. Multiple alerts were generated in quick succession, indicating high-rate SYN traffic and classifying the behaviour as potential SYN flood and burst scanning activity. This demonstrates a direct correlation between the attack traffic generated from Kali and the detection output observed on the Suricata sensor.

As the traffic intensity increased, the EveBox interface became unresponsive and failed to load. This suggests that the volume of traffic and alert generation placed significant strain on the system, reinforcing the effectiveness of the simulated denial-of-service condition. The loss of responsiveness highlights how high-rate traffic can impact not only target services but also monitoring and analysis tools within the environment.

* No further disruptive traffic was generated beyond this point to maintain controlled test conditions and preserve system stability.

Detection Output

• Suricata generated multiple alerts corresponding to both reconnaissance and disruption activity. These included TCP stream anomalies (such as invalid ACKs and out-of-window packets), repeated signatures triggered by sustained traffic patterns, and background network activity including DNS and HTTPS traffic.

• EveBox provided structured visibility into these alerts, enabling filtering based on source IP, timestamps, and event type. This made it easier to correlate specific alert patterns with the simulated attack activity.

• The combination of raw log output and visual analysis highlighted how different traffic behaviours influence detection. While aggressive and high-frequency activity resulted in repeated alert generation, lower-noise traffic produced minimal or no alerts, reinforcing the importance of rule tuning and context-aware analysis.