8.3 Port Scanning, DDoS, and Man-in-the-Middle

TryHackMe Security Analyst Level 1 SAL1

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current SAL1 Exam Facts 1.2 24-Hour Window, Check-In, and Delivery 1.3 Scoring, Retakes, Validity, and Access 1.4 MCQ Section Strategy

2 SOC Simulator Exam Skills

2.1 Analyst VM, Splunk, and Dynamic Alerts 2.2 Classification and Escalation Scoring 2.3 Case Reports and Investigation Notes

3 Network Essentials

3.1 OSI, TCP/IP, Devices, and the Three-Way Handshake 3.2 HTTP, TLS, VPN, Web Browsing, and Email Transmission

4 Operating System Basics

4.1 Windows and Linux Architecture, Auth, Filesystems, Processes 4.2 Active Directory and Event Logs for Tracing Activity

5 Cryptography, Cloud, Web and Scripting Basics

5.1 Encoding, Encryption, Hashing, and Decoding Tools 5.2 VMs vs Hosts, Cloud vs Virtual Hosting, SaaS and IaaS 5.3 Web Apps, APIs, JSON/XML, Scripts vs Compiled Programs

6 Cybersecurity Fundamentals and MITRE ATT&CK

6.1 CIA, Least Privilege, Human Factors, Log4Shell, EternalBlue 6.2 Navigating MITRE ATT&CK: Tactics, Techniques, Sub-techniques 6.3 Mapping Real Attacks onto ATT&CK Techniques

7 Kill Chain, NIST CSF, and Attack Indicators

7.1 Cyber Kill Chain Stages vs MITRE ATT&CK 7.2 NIST CSF: Identify, Protect, Detect, Respond, Recover 7.3 IoC vs IoA and the Pyramid of Pain

8 Social Engineering and Network Attacks

8.1 Phishing: Impersonation, Typosquatting, Spoofing, Header Analysis 8.2 SPF, DKIM, DMARC, and Email Authentication Results 8.3 Port Scanning, DDoS, and Man-in-the-Middle 8.4 DNS Poisoning, ARP Spoofing, Exfiltration, and C2 Traffic Patterns

9 Web Exploitation and Endpoint Attacks

9.1 Client vs Server Vulnerabilities, XSS, and SQL Injection 9.2 Code Injection, Path Traversal, Input Validation, Patching, WAF 9.3 Initial Access (RDP/SSH), Persistence, Privilege Escalation 9.4 Credential Theft, Mimikatz, Sysmon, and Auditd

10 Command and Control, Malware, and LOLBAS

10.1 Forward vs Reverse Shells, Beaconing, Metasploit, Cobalt Strike 10.2 Malware Types, Static vs Dynamic Analysis, LOLBAS

11 EDR, Firewalls, and WAF

11.1 EDR vs AV, Telemetry, Containment, Remote Shell 11.2 Firewall Deployments, Limits, and Log Analysis 11.3 WAF Capabilities, Limits, and Rule Creation

12 SIEM and SOAR

12.1 SIEM Deployments, Parsing, and Raw Logs to Alerts 12.2 Alert Management, Threat Hunting, Triage, Reporting 12.3 SOAR Playbooks, Enrichment, and TI Integration

13 Threat Intelligence and Vulnerability Scanning

13.1 Feeds, Indicators, Classifying IPs, Domains, and Hashes 13.2 YARA and TI Integration with SIEM/SOAR 13.3 External vs Internal, Web vs Network Scanning

14 SOC Team, Activities, and Alert Triage

14.1 Blue/Red Teams, Hierarchy, and SOC Roles 14.2 Proactive vs Reactive: FP Remediation, Detection Engineering, Tabletop, DFIR, Threat Hunting 14.3 Workbooks; Ticket vs Alert vs Detection Rule 14.4 Triage Workflow, Severity, Status, and Verdicts

15 SOC Metrics, Escalation, and Communication

15.1 MTTA, MTTD, MTTR, SLA, and Lookups 15.2 Escalation Matrix, Urgent Remediation, and Cross-Team Communication

8.3 Port Scanning, DDoS, and Man-in-the-Middle

Key Takeaways Explain This Topic AI

A TCP SYN scan shows high destination-port cardinality, tiny flows, and an incomplete handshake; a connect scan completes the handshake and then drops; a UDP scan is many small datagrams across scattered ports.

Volumetric DDoS exhausts bandwidth, protocol DDoS exhausts connection state, and application DDoS exhausts workers or databases — bits per second can look modest in the last case.

A SYN flood aims at one service port with enough embryonic connections to hurt; a SYN scan enumerates many ports with low bytes and is reconnaissance, not the same ticket.

Man-in-the-middle is a path position: TLS intercept shows up as an unexpected certificate issuer, while ARP-based LAN MitM symptoms are covered in section 8.4.

Netflow unique-port cardinality versus bytes, firewall session-table counters, and IDS rate signatures are corroborating sensors — none of them is a license to run a scan against a network you do not operate.

Last updated: September 2026

8.3 Port Scanning, DDoS, and Man-in-the-Middle

Network attacks in SAL1 training content include port scanning, distributed denial of service (DDoS), and man-in-the-middle (MitM, also written MiTM). This section treats them as traffic patterns and sensor stories , not as a lab to reproduce. You will not get exploit steps or scanner recipes. You will get what a firewall, netflow collector, or intrusion detection system (IDS) typically shows, and how an analyst writes the ticket.

Port scanning as a traffic pattern

A port scan is reconnaissance: which transport ports on a host or range accept connections. Scanners vary how much of the Transmission Control Protocol (TCP) handshake they complete. Those differences show up in flow records. The three-way handshake itself (SYN, SYN-ACK, ACK) is assumed from earlier networking study; here the question is how incomplete or complete sessions look when someone is enumerating ports.

SYN scan (half-open)

A SYN scan sends TCP segments with the SYN flag to many ports. If a port is open, the target replies SYN-ACK. The scanner then typically emits RST instead of completing with ACK, so an application never fully accepts the session.

Netflow and firewall picture:

One source IP, many destination ports on one host (vertical scan) or one port across many hosts (horizontal sweep).

Flows with tiny byte counts and durations of milliseconds.

Flag combinations: SYN out, SYN-ACK in, RST out. Application logs stay quiet because the handshake never finished.

Rate: tens to thousands of ports per minute, often sequential or pseudo-random.

IDS signatures historically key on "SYN to more than N ports in T seconds from one source." Tune with care: load balancers and health checks also open many short connections, but they repeat a small port set (80, 443, 8080) toward known targets.

Connect scan (full handshake)

A connect scan completes the three-way handshake and then tears down with RST or FIN. Operating-system socket APIs produce this pattern.

Compared with SYN scans:

Firewall "connection allowed" counters increment.

Some application banners may be collected, so IDS may see a payload byte or two.

Host-based logs (Windows Filtering Platform, Linux sshd pre-auth) may show completed connections that immediately drop.

From a SOC chair, a connect scan is noisier on the destination and more likely to correlate with authentication failures if the scanner also tries logins. The scan itself is still reconnaissance, not yet exploitation.

UDP scans

User Datagram Protocol (UDP) has no handshake. A scanner sends a short datagram to many UDP ports. Closed ports may return ICMP Port Unreachable. Open ports may stay silent or send an application reply. Firewalls often drop UDP, which makes "open or filtered" a common ambiguous result — for operators of scanners that is a tooling problem; for analysts the observation is a burst of small UDP flows to many destination ports, often with empty or cookie-sized payloads, plus a matching burst of ICMP type 3 code 3 if the site generates them.

Do not confuse UDP scanning with UDP DDoS. Scans are many destinations or ports, low bytes. Volumetric floods are few destination ports (or one service), enormous bits per second.

• Pattern Handshake Typical netflow Typical IDS or firewall clue
• TCP SYN scan Incomplete Many short flows, SYN then RST Port-sweep threshold; low application logs

TCP connect scan Complete then drop Short but established flows Allow/deny on completed connections; possible banner

• UDP scan None Many small UDP flows, scattered ports ICMP unreachables or silent drops
• DDoS types at analyst level

Denial of service (DoS) tries to make a service unavailable. Distributed DoS uses many sources (botnet, reflection). Analysts classify by what resource is exhausted , because mitigation differs.

Volumetric

The goal is to fill the circuit: gigabits of junk so legitimate packets cannot enter. Classic shapes include UDP floods and reflection, where small queries to an exposed service produce larger replies toward a spoofed victim. You do not need a construction recipe. You need the telemetry: inbound bits far above baseline, a protocol that is not the business service, source ports that look like well-known amplifier services, and a destination that is one virtual IP (VIP).

Protocol (state exhaustion)

The goal is to fill firewall, load-balancer, or host state tables . A SYN flood of half-open connections is the textbook case: many SYNs, few completed handshakes, table of embryonic connections grows. Compared with a SYN scan , a SYN flood targets one or a few ports (the real service) at a volume meant to hurt, not to enumerate. Fragmented or malformed packets that force expensive reassembly are also protocol-layer.

Application

The goal is to exhaust workers, database queries, or TLS handshakes with requests that look somewhat valid: HTTP GET floods, slow-send connections that hold sockets open, or expensive search URLs. Bits per second may look ordinary while requests per second and backend latency explode. Web application firewall (WAF) and origin logs matter more than netflow bit counters.

Class Exhausts Looks like in sensors First SOC question

Volumetric Bandwidth Interface utilization cliff; UDP or ICMP dominance Is the flood still at the ISP edge?

Protocol Connection state SYN ratio up; firewall session table full Which VIP and port is embryonic?

Application App, CPU, or DB HTTP 5xx, latency; modest Mbps Which URL or method is hot?

Flash crowds (a press hit) can mimic application DDoS. Distinguish with source reputation, geographic scatter versus a known customer base, User-Agent diversity, and whether a marketing event was scheduled.

Loading diagram... Analyst split: scan versus DDoS versus MitM

Lab example: unique destination ports from one source in 60 seconds (fictional)

Man-in-the-middle, conceptually

Man-in-the-middle (MitM) means an attacker or unauthorized device sits on the path and can read or modify traffic. Two pictures matter for SAL1:

Link-layer MitM via Address Resolution Protocol (ARP) spoofing on a local segment. Symptoms (duplicate IP, gateway MAC change) are taught in section 8.4 because they are LAN-specific.

Transport-layer intercept , especially TLS intercept . A box terminates Transport Layer Security (TLS), inspects plaintext, and opens a second TLS session onward. Enterprise secure web gateways do this with an internal certificate authority (CA) pushed to managed endpoints. A malicious intercept does the same idea without consent: the user sees a certificate issued by an unexpected CA, a hostname mismatch, or a sudden drop from TLS to cleartext HTTP.

Analyst observations without building an intercept:

Certificate issuer in browser or TLS-inspection logs is not the vendor the user expected.

HTTP CONNECT volume to an unknown proxy.

IDS alerts for SSL stripping or expired or self-signed certs on a site that historically used a public CA.

For LAN MitM, see 8.4: ARP tables and DHCP.

MitM is a position . Scanning is reconnaissance . DDoS is availability impact . Do not collapse them into "network attack" in a case report — name the pattern, the sensor, and the affected resource.

Detection in netflow, firewall, and IDS

Practical hunt observations (observe, do not reproduce):

Netflow / IPFIX: top talkers, unique destination-port cardinality per source, bytes per flow, TCP flags if exported, duration. High cardinality plus low bytes suggests a scan. High bytes plus few 5-tuples suggests a transfer or a flood.

Firewall: accept/deny counts by policy rule, SYN timeout counters, session-table utilization, geo or IP reputation hits. A deny storm on unused ports is often a scan hitting default-drop.

IDS/IPS: rate-based scan signatures, known flood signatures, TLS anomaly signatures. Always corroborate: IDS says "SYN flood" while netflow shows a single partner prefix — that may be a mis-set threshold during a file transfer.

Escalation notes should include start and stop time, targeted CIDR or VIP, protocol and ports, whether sources look spoofed (asymmetric traffic, no return path), and whether availability actually broke (user tickets) versus a noisy recon.

The fictional bar chart in this section is a teaching baseline: a SYN-scan pattern might touch 1800 distinct destination ports in a minute from one source, a connect scan fewer because it is slower, a workstation a handful of services, and a health checker a tiny fixed set. Use cardinality first, then bytes, then application logs. That order keeps you from paging the on-call engineer for a partner's backup job that merely completed many connections to port 443.