Network Security & Perimeter Monitoring

The Big Picture

An enterprise network is one connected ecosystem. Compromise one part and the attacker can reach the rest. The perimeter is the boundary between your network and the internet, and it's where attackers start. So it's usually where the SOC sees them first.

This room teaches four things:

1. What is in a network, and why attackers want each part
2. How we see what's happening (host vs network logs)
3. Where the perimeter is and what defends it
4. How to investigate a real attack through the logs, from first scan to stolen data

1. Network Components — What Attackers Want and What to Watch

One-line summary: endpoints are the door, AD is the master key, servers hold the treasure, the firewall is the gate, and routers/switches are the roads.

2. Visibility — You Can't Defend What You Can't See

Network visibility = being able to monitor and understand what's happening across the network. It's not about tracking every packet. It's about having the sources to build a clear picture.

What visibility enables

Two kinds of logs

Network-centric sources in detail

The key rule: neither log type is enough alone. Correlate both to build an accurate incident timeline.

3. The Network Perimeter

Perimeter = the boundary separating the internal network (trusted) from the internet (untrusted). All traffic in or out must pass through it, like the main gate of a secure building.

• It's not one device. It's a collection of controls working together.
• It's no longer just hardware at the edge: it also includes virtual gateways, cloud connections and remote access points.

Perimeter components

Small enterprise layout

                 INTERNET (untrusted)
                        │
                   [ ROUTER ]
                        │
                  [ FIREWALL ] ─────── [ DMZ ]  ← web server (public can reach it)
                        │
          ┌─────────────┼──────────────┐
     [ AD server ] [ File server ] [ Database ]   ← INTERNAL: employees only
                        │
                 [ Workstations ]

 Remote employees ──► [ VPN gateway ] ──► internal network

Why a DMZ? The public has to reach the web server, so it's exposed. Putting it in a separate zone means that if it's hacked, the attacker is still outside the internal network. Public services stay isolated; only controlled traffic reaches inside.

Why the perimeter matters

Attackers always probe from the outside first. A weak or misconfigured perimeter allows:

• Exploiting exposed services (RDP, SSH, MySQL, SMB) → unauthorized access
• Scanning and reconnaissance → mapping your network
• Brute-force attacks on login services
• Exfiltration channels → data breaches
• Malware infiltration

The analyst's job at the perimeter

• Review firewall logs (blocked and allowed)
• Spot scanning and brute-force attempts
• Flag unusual outbound traffic (beaconing, exfiltration)
• Know what should and shouldn't be exposed (e.g. RDP on the internet = never)

4. Reading Perimeter Logs — Three Classic Patterns

Scenario 1: Port scan (firewall log)

08:30:04 ALLOW TCP 198.51.100.45:49876 -> 10.0.0.51:80     ← normal web visitor
08:30:05 BLOCK TCP 203.0.113.10:50001  -> 10.0.0.20:21     ┐
08:30:06 BLOCK TCP 203.0.113.10:50002  -> 10.0.0.20:22     │
08:30:07 ALLOW TCP 192.0.2.115:51235   -> 10.0.0.50:443    │ same IP,
08:30:08 BLOCK TCP 203.0.113.10:50003  -> 10.0.0.20:23     │ same target,
08:30:09 BLOCK TCP 203.0.113.10:50004  -> 10.0.0.20:25     │ different port
08:30:11 BLOCK TCP 203.0.113.10:50005  -> 10.0.0.20:53     ┘ every second

Clues: one source → one host → many ports → in seconds. The ports (21 FTP, 22 SSH, 23 Telnet, 25 SMTP, 53 DNS) are common services. Even the source port counts up by 1 (50001, 50002...), a sign of a scanning tool. Verdict: port scan. The attacker is looking for an open service. The firewall blocked it, but this IP is now on your watchlist.

Scenario 2: Web attacks (WAF log)

A WAF (Web Application Firewall) inspects web requests and says what kind of attack it saw. That's more context than a normal firewall gives.

action=ALLOW request="GET /index.html"                               ← normal
action=ALLOW request="GET /products.php?id=9"                        ← normal
action=BLOCK request="GET /search.php?q=<script>alert('XSS')</script>"  rule_id=941100  attack_type=XSS
action=ALLOW request="GET /css/style.css"                            ← normal
action=BLOCK request="GET /../../../../etc/passwd"                   rule_id=930120  attack_type="Directory Traversal"

Fast triage: filter action=BLOCK → the WAF has already found and labelled the threats. Verdict: one source trying several attack types = high-confidence, active targeting of the website.

Scenario 3: VPN brute force

10:12:08 FAILED_AUTH  [REDACTED]:31249  -> 10.0.0.1:443 (user 'guest')
10:12:09 FAILED_AUTH  [REDACTED]:31250  -> 10.0.0.1:443 (user 'user')
10:12:11 FAILED_AUTH  [REDACTED]:31245  -> 10.0.0.1:443 (user 'admin')
10:12:15 FAILED_AUTH  [REDACTED]:31248  -> 10.0.0.1:443 (user 'admin')
10:12:21 SUCCESS_AUTH 198.51.100.88:41233 -> 10.0.0.1:443 (user 'b.jones')  ← normal employee

Method: group by source IP → one IP has hundreds of failures in a short time. Clues: generic usernames (admin, guest, user, root, test) = a username list, not a real person who forgot their password. Verdict: brute force against the VPN. The scattered successes from other IPs are normal employees.

⚠️ Notice the course's log isn't in time order (10:12:21 comes before 10:12:08). Real logs often arrive out of order, so sort by timestamp before building a timeline.

Pattern cheat sheet

Context beats volume. An IDS alert that says why something was flagged is worth more than a plain firewall block.

5. The Investigation — Following One Attack End to End

The challenge reconstructs a complete attack using three files: firewall.log, ids_alerts.log, vpn_auth.log. The method: find a suspicious indicator → pivot → find the next one. Each answer becomes the next search.

The attack chain you uncover

1. RECON           external IP scans the perimeter          (firewall BLOCKs)
2. INITIAL ACCESS  firewall ALLOWs + VPN brute force works  (firewall ALLOW, vpn_auth)
3. FOOTHOLD        attacker gets an internal VPN IP          (vpn_auth assigned_ip)
4. LATERAL MOVE    internal IP probes/exploits other hosts   (firewall + IDS)
5. C2              compromised host beacons to port 4444     (IDS TROJAN alerts)
6. EXFILTRATION    large HTTP POST uploads out               (firewall + IDS)

Step 0 — Look at each log first

head firewall.log       # first 10 lines: date time ACTION proto src:port -> dst:port
head ids_alerts.log     # signature ID, alert name, classification, priority
head vpn_auth.log       # date time src_ip user SUCCESS/FAIL assigned_ip

Always learn the format first. You need to know which field is which before you can use cut.

Step 1 — Reconnaissance: who's getting blocked?

cat firewall.log | grep "BLOCK" | head

→ An external IP is probing internal IPs on 22, 23, 21, 445, 3389 (SSH, Telnet, FTP, SMB, RDP), exactly the services that should never be exposed.

Which IP has the most blocks?

cat firewall.log | grep "BLOCK" | cut -d' ' -f5 | cut -d: -f1 | sort | uniq -c | sort -nr

• cut -d' ' -f5 → 5th space-separated field = src_ip:port
• cut -d: -f1 → keep only the part before : = the IP
• Result: one IP with 279 blocks stands out → the suspect.

Step 2 — Did anything get through?

cat firewall.log | grep <suspect_ip> | grep "ALLOW"

→ ALLOWED connections from the suspect to 4444, 445, 22, 3389, 23.

• The firewall blocked some and allowed others: a misconfiguration.
• Port 4444 is the default Metasploit listener port, a big red flag.

Step 3 — Credential access: VPN brute force

cat vpn_auth.log | grep FAIL | cut -d' ' -f3 | sort | uniq -c | sort -nr

• Field 3 = source IP → the suspect has 118 failed logins.

cat vpn_auth.log | grep <suspect_ip>

02:19:00 svc_[REDACTED] FAIL
02:19:10 svc_[REDACTED] FAIL      ← every 10 seconds = automated tool
02:19:20 svc_[REDACTED] FAIL
02:19:30 svc_[REDACTED] FAIL
...
02:19:40 svc_[REDACTED] SUCCESS assigned_ip=[REDACTED]   ← BREACH

What happened: repeated failures against one account → then SUCCESS → the VPN gave the attacker an internal IP. They're inside now.

Why a svc_ account? Service accounts (used by applications, not people) are prime targets: their passwords often never expire, they usually have no MFA, they often have broad privileges, and nobody notices odd logins on them.

Pivot: the assigned internal IP is now the compromised host. Search for it next.

Step 4 — Lateral movement

cat firewall.log | grep <compromised_internal_ip> | grep "ALLOW" | head

06:00:00 → :22     06:10:00 → :445     06:20:00 → :22
06:40:00 → :3389   07:30:00 → :22      08:00:00 → :22

→ The compromised host is probing 10.0.0.20, 10.0.0.51, 10.0.0.60 on SMB / RDP / SSH (445 / 3389 / 22). These are the classic remote access and file sharing services used to spread. → The neat 10-minute spacing again suggests automation.

Confirm with the IDS:

cat ids_alerts.log | grep <compromised_ip> | head

→ Possible SSH Scan, Possible MS-SMB Lateral Movement, Possible RDP Brute Force, all Priority 1.

Narrow to SMB:

cat ids_alerts.log | grep -n <compromised_ip> | grep 'SMB' | cut -d' ' -f6,7,8,9,10,19,21 | head

• grep -n → adds line numbers (handy for jumping back to the full line)
• cut ... -f6,7,... → keep only the alert name and IP fields so it's readable → Repeated MS-SMB Lateral Movement to port 445 → SMB exploited, lateral movement achieved.

Step 5 — Command & Control (C2) beaconing

cat ids_alerts.log | grep C2 | head

2025-09-11 01:00:00  ET TROJAN Possible C2 Beaconing
2025-09-11 07:00:00  ET TROJAN Possible C2 Beaconing
2025-09-11 13:00:00  ET TROJAN Possible C2 Beaconing
2025-09-11 19:00:00  ...

→ Exactly every 6 hours, to the second. Perfectly regular timing = a machine, not a human. That's what beaconing means: the malware checks in with the attacker's server on a schedule. → Classification: "A network Trojan was detected", Priority 1.

Summarize all alerts for the infected host:

cat ids_alerts.log | grep -n <compromised_ip> | cut -d' ' -f6,7,8,9,10,19,22,23 | sort | uniq -c | sort -nr | head

Correct counts (from the course's own screenshot):

80  TROJAN Possible C2 Beaconing        → :4444
32  INFO Possible HTTP POST Large       → :80
28  INFO Possible HTTP POST Large       → :8080
23  POLICY Suspicious HTTP
 2  WEB_SERVER Possible SQL Injection   → various ports

→ The external IP on port 4444 is the C2 server. The internal network is fully compromised.

Step 6 — Data exfiltration

cat firewall.log | grep <compromised_ip> | cut -d' ' -f5,6,7 | sort | uniq

[host]:40000 -> [external]:8080
[host]:40001 -> [external]:8080
[host]:40003 -> [external]:80
...  (40000, 40001, 40002 ... sequential source ports)

→ Many connections to an external IP on 80 / 8080 (web ports, which blend in with normal traffic). → Sequential source ports = a script sending data in chunks.

cat ids_alerts.log | grep <compromised_ip> | tail

→ ET INFO Possible HTTP POST Large Upload | Classification: Potential Data Exfiltration, every 4 hours.

• POST = sending data to a server. Large POSTs out of a network = data leaving.

Verdict: evidence of data exfiltration.

The whole story in one table

Lesson: no single log showed the attack. Firewall + VPN + IDS together, each pivot feeding the next, revealed the full chain.

6. Linux Command Toolkit

⚠️ The sort/uniq trap — the course's own screenshots prove it

uniq only merges duplicates that are next to each other. If identical lines are scattered, it counts them as separate groups.

The course ran the same search in two orders:

Always use:

... | sort | uniq -c | sort -nr
#     group  count     biggest first

• First sort → puts identical lines next to each other
• uniq -c → counts each group correctly
• Last sort -nr → ranks by count, biggest offender on top

The universal "who's doing this most?" recipe:

cat file.log | grep "<filter>" | cut -d' ' -f<field> | sort | uniq -c | sort -nr | head

7. Method 2 — Splunk (a SIEM)

Manual grep is fine for small files but tedious at scale. Splunk ingests logs from all sources into one searchable place.

Access: browser → localhost:8000 → Search & Reporting → search index="network_logs"

The logs are already loaded:

Splunk terms:

The same investigation as Splunk searches (SPL). Field names here are typical; confirm the exact names in the Fields sidebar:

index="network_logs" sourcetype="firewall_logs" action="BLOCK" | stats count by src_ip | sort -count
index="network_logs" sourcetype="vpn_logs" "FAIL" | stats count by src_ip | sort -count
index="network_logs" sourcetype="ids_logs" "C2" | table _time alert src_ip dest_ip
index="network_logs" "<suspect_ip>" | sort _time

• stats count by X = Splunk's version of sort | uniq -c, but always correct, with no adjacency trap.
• sort -count = biggest first.
• The last search shows every log type for one IP in time order: an instant cross-log timeline.

8. The Analyst's Role

1. Recognize normal vs suspicious traffic (know the baseline)
2. Escalate unusual activity to higher SOC tiers (L2/L3), with your evidence
3. Understand how each component fits into enterprise defense

Core Rules

1. Endpoints are the door, AD is the master key, the perimeter is the gate.
2. Host logs = inside the room; network logs = who came and went. Correlate both.
3. The perimeter is where attackers show up first, so watch it closely.
4. Read the pattern: many ports = scan; many logins = brute force; regular timing = beaconing; big uploads = exfiltration.
5. Check ALLOWs, not just BLOCKs. Blocks show attempts; allows show successes.
6. Pivot: every suspicious value (IP, user, assigned IP) is the next search.
7. Always sort before uniq -c.
8. Context beats volume. An IDS/WAF alert that says why beats a bare block.

Port Cheat Sheet (ports in this room)

Acronyms

Network Discovery & Scanning Detection

The Big Picture

Before attacking, an attacker has to find a way in. Scanning is how they map your attack surface. Defenders scan too, and so do search engines and researchers. So the SOC's real job isn't "detect scanning". It's:

Tell good scanning from bad, and work out how far the attacker has already got.

The single most important question about any scan: Where did it come from?

• Outside → in = attacker is still knocking on the door (low severity)
• Inside → in = attacker is already in the house (high severity)

1. Attack Surface — What Everyone Is Trying to Map

Attack surface = all of an organization's assets reachable from the public internet.

Same activity, opposite goals

Attacker and defender run the same scans and get the same answers. The difference is what they do with them.

2. The Detection Problem — Good vs Bad Discovery

Scanning comes from many sources:

• Attackers
• Your own security team (vulnerability scanners, asset discovery)
• Search engines and web crawlers
• Research organizations mapping the internet

Alerting on all of it = drowning in noise. SOC teams handle it three ways:

The lesson: threat intel is best for ranking alerts, not as the only reason to alert.

Know your own scanners

Organizations run internal scans to find vulnerabilities, spot rogue assets, and reduce the attack surface. A SOC analyst should know:

• Which IPs the authorized scanners run from
• What type of scan they do
• When they're scheduled

These should be excluded from detection rules to reduce noise. Good practice: allowlist by source IP + expected schedule. A "scanner" running at 3 AM outside its window is suspicious.

3. External vs Internal Scanning — The Severity Rule

Caveats

• External: blocking an IP is whack-a-mole. Attackers return from a new IP (VPNs, proxies, cloud servers, botnets). It also matters what followed the scan: a scan followed by a successful connection is no longer low severity.
• Internal: always check first that it isn't your own vulnerability scanner or IT team. That's the most common "false alarm".

Private IP ranges (how to recognize "internal")

Both source and destination in these ranges = internal scanning.

4. MITRE ATT&CK — Where Scanning Sits

MITRE ATT&CK = a public knowledge base of adversary tactics (the attacker's goals) and techniques (how they achieve them).

The 14 Enterprise tactics

Relevant techniques:

• T1595 Active Scanning → under Reconnaissance
• T1046 Network Service Discovery → under Discovery

⚠️ Two corrections to the course diagram

1. ATT&CK is a matrix, not a strict sequence. Real attacks skip, repeat and loop through tactics. The numbering shows the typical flow, not a rule.
2. The course diagram puts Exfiltration before Command and Control. In the official ATT&CK order Command and Control comes first (12), then Exfiltration (13). In practice C2 is usually set up early, since attackers need it to control the machine in the first place.

Why this matters for the SOC: the further right an activity sits, the deeper the attacker is and the more urgent the response. Recon = early warning. Discovery = active intrusion.

5. Horizontal vs Vertical Scans

Once attackers know which hosts exist, they look for which ports are open.

Horizontal scan — one port, many hosts

Attacker ──:445──► 192.168.1.1
         ──:445──► 192.168.1.2
         ──:445──► 192.168.1.3
         ──:445──► 192.168.1.4
         ──:445──► 192.168.1.5

• Goal: find every machine exposing a specific port, usually because the attacker already has an exploit for that service.
• Classic example: WannaCry (2017). The ransomware scanned for port 445 to spread through the SMBv1 vulnerability (the EternalBlue exploit, patched by MS17-010). It hopped worm-like from machine to machine.
• Log signature: same source IP + same destination port + many destination IPs

Vertical scan — one host, many ports

                 ┌─ :80
                 ├─ :25
Attacker ──────► ├─ :22     192.168.1.25
                 ├─ :445
                 ├─ :3389
                 └─ :443

• Goal: footprint one valuable host. Find everything it exposes, then look for a weakness.
• Example: an organization exposes only one server to the internet, so an attacker vertically scans that server to see every service on it.
• Log signature: same source IP + same destination IP + many destination ports

Side by side

Mixed / block scans = many hosts × many ports at once, combining both.

Detecting them by counting (concept)

Count distinct values per source:

• Horizontal: for each (source IP, destination port), count distinct destination IPs → high number = horizontal scan
• Vertical: for each (source IP, destination IP), count distinct destination ports → high number = vertical scan

Splunk-style example (exact field names depend on the data):

... | stats dc(dest_ip) AS hosts BY src_ip, dest_port | where hosts > 20     ← horizontal
... | stats dc(dest_port) AS ports BY src_ip, dest_ip | where ports > 20    ← vertical

dc() = distinct count. The threshold (20 here) is a tuning choice; set it from your baseline.

6. How Scans Work — Three Techniques

Ping sweep (ICMP) — "Is anyone home?"

Scanner ──ICMP Echo Request──► Host
Scanner ◄──ICMP Echo Reply──── Host   = host is ONLINE

• Sends an ICMP packet to each address; a reply means the host is alive.
• Most basic technique; finds hosts, not ports.
• ⚠️ Often blocked by firewalls nowadays, so it's easy to defeat. A host that doesn't answer pings may still be online.
• Log signature: one source → ICMP to many sequential IPs in a short time.

TCP SYN scan — "half-open" scan

Normal TCP 3-way handshake: SYN → SYN-ACK → ACK (connection open). A SYN scan never finishes it:

Scanner ──SYN──────► Host:port
Scanner ◄──SYN-ACK── Host        → port OPEN   (scanner then sends RST, never ACK)
Scanner ◄──RST────── Host        → port CLOSED (host is online)
        (no reply)               → port FILTERED (a firewall is likely dropping it)

• Why "stealthy": the connection is never completed, so many applications never log it. A single SYN also looks like the start of normal traffic.
• But: IDS/IPS and firewalls can detect it, through many SYNs with no completed handshakes from one source.
• The most popular default scan type (e.g. Nmap's default when run with admin rights).

UDP scan — slow and unreliable

UDP has no handshake, so the scanner sends a (usually empty) UDP packet and interprets the reaction:

• Unreliable: silence is ambiguous. A firewall dropping packets looks identical to an open port.
  • The course says the scanner "marks it open". Tools like Nmap actually label it open|filtered, admitting they can't tell.
• Slow: the scanner must wait for a timeout on every silent port, and hosts often rate-limit ICMP replies.

Technique comparison

7. Analyst Decision Flow

Scanning detected
 │
 ├─ Is the source an authorized scanner (known IP + schedule)?
 │     └─ YES → expected, ignore (should already be excluded)
 │
 ├─ Is the source EXTERNAL → our public assets?
 │     └─ Reconnaissance → LOW severity
 │          → check threat intel (raises priority if known-bad)
 │          → did any connection SUCCEED after the scan? If yes → escalate
 │          → block the IP at the perimeter firewall
 │
 └─ Is the source INTERNAL → internal hosts?
       └─ Discovery → HIGH severity (attacker likely inside)
            → confirm it isn't authorized IT activity
            → ESCALATE + start Incident Response
            → investigate the source machine + root cause analysis
              (blocking the IP is NOT enough)

Core Rules

1. Everyone scans. The skill is telling good scans from bad.
2. Direction decides severity: outside→in = low (Recon); inside→inside = high (Discovery).
3. External: block, but expect them back from a new IP.
4. Internal: don't just block. Investigate the host and escalate.
5. Horizontal = one port, many hosts (worm/exploit hunting). Vertical = one host, many ports (targeted footprinting).
6. Threat intel should raise priority, not be the only trigger.
7. Allowlisting creates blind spots. Allowlist narrowly (IP + schedule).
8. SYN scans are quiet; UDP scans are slow and ambiguous; ping sweeps are often blocked.

Terms

Data Exfiltration — Detection Notes

The Big Picture

Data exfiltration = the unauthorized transfer of data from an organization to an external destination controlled by an adversary.

It happens in three ways:

The core difficulty: exfiltration hides inside normal traffic: web uploads, DNS lookups, pings, cloud sync. You rarely catch it with one alert. You catch it by correlating host, network and cloud evidence.

What a good investigation answers:

1. Who accessed the data? (user / host / process)
2. What was transferred? (files, volume)
3. How was it staged? (compressed, encoded, encrypted)
4. Where was it sent? (IP, domain, cloud account)

1. Why Adversaries Steal Data

2. Real Threat Actors & Their Methods

The course table says "dual extortion"; the common industry term is double extortion. Same thing.

3. The Exfiltration Lifecycle

Data theft isn't one event. It's a sequence, and each stage leaves different evidence:

1. DISCOVERY / COLLECTION ─► 2. STAGING / COMPRESSION ─► 3. TRANSPORT ─► (4. C2 coordinates it all)
   find the files              bundle, shrink, hide       move it out      orders + confirms receipt

Catch it at staging if you can. A 4 GB archive appearing in a temp folder at 2 AM is a better early warning than the upload itself.

4. Techniques and Where to Look

General triage signals (any technique)

• Large outbound volume to external IPs/domains
• Unknown destination domains (never seen in the baseline)
• Suspicious processes / command lines
• Many file reads followed by an outbound connection. This is the single strongest pattern.
• Multipart / streamed uploads

Sysmon & Windows event IDs worth memorizing

4663/4656 only appear if object access auditing is enabled on the files or folders. Many organizations never turn it on.

Living off the land

Most tools in the host-based row are legitimate admin software (rclone, awscli, curl, PowerShell). They're signed, trusted and often allowed. So the tool alone isn't the indicator. The indicator is who runs it, on which host, with which arguments, to which destination. rclone on a developer's laptop may be normal; rclone on a domain controller at 3 AM is not.

5. DNS Exfiltration & Tunneling

Why attackers love DNS

DNS basics: mostly UDP port 53. TCP 53 is used for zone transfers and large responses. Record types: A (IPv4), AAAA (IPv6), TXT (text), MX (mail), CNAME (alias).

How it works

Stolen data:  "password123"
   └─ encode → cGFzc3dvcmQxMjM
       └─ query: cGFzc3dvcmQxMjM.exfil.attacker.com
           └─ your DNS server can't answer → forwards it to the attacker's
              authoritative server for attacker.com → attacker logs the subdomain = data received

The attacker owns the authoritative DNS server for their domain, so every query reaches them, even through your internal DNS.

DNS size limits (why exfil needs many queries):

• Max 63 characters per label (each part between dots)
• Max 253 characters for the full name

So a file becomes thousands of queries to one domain. That volume is what gives it away.

Indicators

Encoding giveaways:

Base32 and hex are popular for DNS because DNS names are case-insensitive and + and / aren't allowed in hostnames.

Hunting it

Wireshark:

dns                                 all DNS
dns.qry.name.len > 50               long query names
dns.qry.type == 16                  TXT queries
dns.flags.rcode == 3                NXDOMAIN responses
dns.qry.name contains "attacker"    one suspicious domain

Then use Statistics → Conversations or Statistics → DNS to see which host sends the most queries.

Splunk (field names vary by data source):

index=* sourcetype=dns | eval qlen=len(query) | where qlen > 60
| stats count dc(query) AS unique_queries BY src_ip, domain | sort -count

Many unique subdomains under one domain from one host is the classic tunneling fingerprint.

6. FTP Exfiltration

FTP = one of the oldest file transfer protocols. Attackers use it to move large amounts of data, often through compromised credentials, misconfigured servers or ephemeral accounts.

How attackers use it

• Legitimate FTP servers (public or misconfigured internal ones) to stage or transfer data
• Compromised credentials (service accounts, user accounts)
• Non-standard ports or tunneling to blend in

Why FTP is easy to analyse

Plain FTP is cleartext. Credentials, commands and file contents all travel unencrypted, so packet capture shows everything.

FTP uses two channels:

Commands that matter

Direction: for exfiltration, look for STOR from your host to an external server. RETR from outside to your server can also be theft, if your server is the one being emptied.

Indicators

• USER/PASS from internal hosts to unusual external IPs
• Repeated or large STOR/RETR transfers
• Large data connections, especially outside business hours
• PASV data channels on ephemeral ports paired with large payloads

Hunting it

Wireshark:

ftp                                   control channel
ftp.request.command == "USER"         logins
ftp.request.command == "STOR"         uploads
ftp-data                              the file contents

• Follow → TCP Stream on the control channel to read the whole session.
• File → Export Objects → FTP-DATA to recover the transferred files (in a lab only).

⚠️ Encrypted cousins

SFTP / SCP (over SSH, port 22) and FTPS (FTP over TLS) are encrypted. You can't read commands or files, only metadata: who connected to where, when, how long and how many bytes. That's why the course mentions "SSH session metadata": for SSH, flow volume and duration are your evidence.

7. HTTP / HTTPS Exfiltration

Why HTTP is the most common channel

• Blends with normal web traffic. Everyone browses all day.
• Gets through firewalls and proxies, since 80/443 are always open
• Easy to obfuscate: encoding, encryption, tunneling

Techniques

Adversaries adapt: low-and-slow pacing, encryption or encoding, and legitimate services to evade detection.

Indicators

• Unusually large POST requests to external or unexpected hosts
• Requests to domains with low reputation or rarely seen in the baseline
• Frequent small requests (beaconing) to the same host, followed by large uploads
• Chunked/multipart transfers where many requests add up to one larger file

Hunting it

Wireshark:

http.request.method == "POST"
http.request.method == "POST" && frame.len > 1000
http.request.uri contains "="                     data in query strings
tls.handshake.extensions_server_name              SNI: the domain an HTTPS connection asks for

• Follow → HTTP Stream to read what was posted.
• File → Export Objects → HTTP to recover uploaded content.

Splunk (field names vary):

index=* sourcetype=proxy http_method=POST
| stats sum(bytes_out) AS total_out count BY src_ip, dest_host
| where total_out > 10000000 | sort -total_out

This is total bytes out per host-and-destination pair. Summing catches chunked uploads that each look small.

Encrypted traffic: what you can still see

Even without decryption:

• SNI: the domain the client asked for
• Bytes out vs bytes in: browsing downloads much more than it uploads, so a high outbound ratio is suspicious
• Destination reputation, connection timing and frequency
• JA3/JA4 fingerprints of the TLS client, which identify specific malware or tools

8. ICMP Exfiltration & Tunneling

ICMP = network-layer protocol for diagnostics and control (ping, "TTL exceeded"). It's commonly allowed and inspected less strictly than TCP/UDP, which makes it a covert channel.

How it works

A ping packet has a payload field. Normally it's filler bytes. Attackers put encoded file chunks there instead, and a listener under their control collects and decodes them.

Techniques

⚠️ The course writes "Encrypting or encrypting payloads (base64 is common)". Base64 is encoding, not encryption. Anyone can decode it without a key. Encoding hides data from a casual glance; encryption hides it from everyone without the key.

What normal ping looks like (your baseline)

Anything much bigger, or random-looking, is abnormal.

ICMP types to know

Indicators

• Persistent ICMP sessions to an external host not used for monitoring
• Payloads larger than a normal ping, especially if frequent
• High-entropy or Base64/hex-looking payloads
• Bursts of ICMP with no other application traffic from the same host

Hunting in Wireshark

icmp                                   all ICMP
icmp.type == 8                         echo requests only
icmp.type == 8 && data.len > 64        oversized pings
icmp.type == 13 || icmp.type == 14     timestamp messages
ip.flags.mf == 1 && icmp               fragmented ICMP

Look for:

• Volume: one host sending many echo requests to one external IP (Statistics → Conversations)
• Size: large frame.len or data.len
• Periodicity: evenly spaced packets with similar payload sizes
• Content: open the Packet Bytes pane. Normal pings show the alphabet pattern; tunnels show encoded text or random bytes

9. Channel Comparison

10. SOC L1 Triage Checklist

For any suspected exfiltration, gather these and corroborate across sources:

Alert (volume spike / odd DNS / big POST)
  → identify host + user + process
  → check destination reputation + baseline
  → look backwards: file reads? archive created?   (collection / staging)
  → look sideways: same destination from other hosts?   (scope)
  → confirmed or unexplained → ESCALATE with the evidence

Core Rules

1. Exfiltration hides in normal traffic. Detection is correlation, not one alert.
2. Many file reads → archive → outbound connection is the strongest pattern.
3. Catch it at staging if you can, before the data leaves.
4. Legitimate tools are the norm. Judge context: who, where, when, what arguments.
5. DNS: long, random subdomains plus high volume to one domain = tunneling.
6. FTP: STOR = upload. Cleartext means the PCAP shows everything.
7. HTTP: big or many POSTs and a high bytes-out ratio. HTTPS still leaks metadata.
8. ICMP: pings should be small, boring and predictable. Anything else is suspicious.
9. Base64 is encoding, not encryption.
10. Ransomware usually means exfiltration too (double extortion).

Acronyms

Man-in-the-Middle (MITM) Attacks — Detection Notes

The Big Picture

MITM = an attacker secretly sits between two parties (a user and a service), intercepting and possibly altering their communication without either side knowing.

Normal:   VICTIM ─────────────────────────► SERVER

MITM:     VICTIM ──► ATTACKER ──► SERVER
                 ◄──          ◄──
          both sides think they're talking directly to each other

What the attacker gains:

• Eavesdropping: steal credentials, credit cards, session tokens
• Manipulation: inject malicious content, fake login forms, malware

Where it works best: wherever encryption or authentication is weak or missing.

The key idea: MITM attacks abuse trust built into old protocols. ARP and DNS were designed for cooperative networks and believe whatever answer arrives. Every attack in this room exploits that.

1. How MITM Works — Two Steps

Step 1 gets them in the path. Step 2 makes being in the path worth something. Against properly encrypted, authenticated traffic, step 1 alone gives the attacker little.

2. Common Types of MITM

Note: IP spoofing on its own is rarely a full MITM. The attacker can send forged packets but doesn't receive the replies. It becomes MITM only when combined with something that reroutes traffic.

3. Real-World Examples — ⚠️ One Is Wrong

❌ Equifax 2017 was NOT a MITM attack

The course says Equifax was breached "due to an MITM attack". That's incorrect.

• Real cause: an unpatched Apache Struts vulnerability (CVE-2017-5638) in a public web application.
• Impact: about 147 million people's data (the course says "over 100 million").
• Real lesson: patch management, not MITM.
• Possible source of the confusion: in the same year, Equifax's mobile apps were found to have weak HTTPS handling that left them vulnerable to MITM. That was a separate finding, not the breach.

For the quiz, answer what the course expects. In real work, Equifax = unpatched Struts.

✅ Better real examples of MITM

The course's "state actors intercepting search traffic via SSL spoofing" fits the DigiNotar pattern: fake certificates let an attacker impersonate HTTPS sites.

4. MITM and the Cyber Kill Chain

TTPs = Tactics (the goal), Techniques (the method), Procedures (the exact steps). A single alert means more once you place it in the attacker's overall plan.

Lockheed Martin Cyber Kill Chain — 7 phases

Where MITM fits (per the course)

⚠️ A contradiction worth noticing

The course says MITM "provides the adversary with their initial foothold". But ARP spoofing only works from inside the local network: the attacker must already have a device on your LAN (a compromised PC, a plugged-in device, or Wi-Fi access).

• So internal MITM (ARP/DNS on the LAN) = the attacker is already in. Treat it like internal scanning: high severity.
• Rogue Wi-Fi / open public Wi-Fi is the case where MITM really can be the first step.

How MITRE ATT&CK classifies it

T1557 — Adversary-in-the-Middle, listed under Credential Access and Collection, with sub-techniques:

• T1557.002 ARP Cache Poisoning
• T1557.001 LLMNR/NBT-NS Poisoning and SMB Relay (a very common Windows variant)

Why it matters to the SOC: a confirmed MITM means an adversary is active mid-intrusion. That's the moment to disrupt the chain before Actions on Objectives: isolate the attacker's device, reset exposed credentials.

5. ARP Spoofing (ARP Cache Poisoning)

ARP in one line

ARP maps IP addresses to MAC addresses on a local network.

Device:  "Who has 192.168.1.1? Tell 192.168.1.50"    (broadcast request)
Router:  "192.168.1.1 is at aa:aa:aa:aa:aa:aa"        (reply)
Device saves this in its ARP cache → sends future frames to that MAC

Why spoofing works

ARP has no authentication. Any device can send an unsolicited "is-at" reply, and most devices accept and cache it, even if they never asked.

The attack

The attacker sends fake replies to both sides:

To the VICTIM:   "192.168.1.1 (gateway) is at ATTACKER_MAC"
To the GATEWAY:  "192.168.1.50 (victim)  is at ATTACKER_MAC"

Course example: 192.16.10.100 is at 02:fe:BB:cd:55:55. The attacker claims to be the gateway.

• 192.16.10.100 is probably a typo for 192.168.10.100. 192.16.x.x isn't a private range.
• A MAC starting with 02 has the "locally administered" bit set, meaning it was set by software, not burned in by a manufacturer. That's common for VMs and spoofed MACs, so it's a small but useful clue.

Result:

• The victim's ARP cache is poisoned.
• All traffic meant for the gateway flows through the attacker first. The attacker forwards it on so nothing seems broken: a silent MITM.

Indicators

⚠️ "Gratuitous ARP" isn't automatically malicious

The course equates unsolicited replies with gratuitous ARP. Gratuitous ARP is a legitimate mechanism: a device announces its own IP-MAC pair after booting, changing IP, or in failover (e.g. two firewalls sharing a virtual IP). The red flag is a device announcing an IP that belongs to someone else, especially the gateway, and repeatedly.

Hunting in Wireshark

arp                                   all ARP
arp.opcode == 1                       requests ("who has")
arp.opcode == 2                       replies ("is at")
arp.duplicate-address-detected        Wireshark's own duplicate-IP flag
arp.src.proto_ipv4 == 192.168.1.1     everything claiming to be the gateway
eth.src == 02:fe:bb:cd:55:55          everything from the suspect MAC

• Expert Info often shows "Duplicate IP address configured" warnings. That's a fast way in.
• Statistics → Endpoints → Ethernet: a MAC tied to more IPs than it should be stands out.
• Compare the gateway's real MAC (from the earliest replies, or from IT documentation) with what appears later.

Defenses

• Dynamic ARP Inspection (DAI) on switches, which checks ARP against DHCP snooping records
• Static ARP entries for critical devices such as the gateway
• Port security / 802.1X, so unknown devices can't plug in
• Encryption everywhere (TLS), so interception yields nothing readable

6. DNS Spoofing

DNS in one line

DNS is the network's contact list: you tap a name (www.google.com), it gives you the number (the IP address).

DNS spoofing = giving the victim the wrong number for a site.

The attack, step by step

1. Victim looks up my-real-bank.com.
2. Attacker, already on the local network (often via ARP spoofing), sees the query.
3. The spoof: the attacker sends a fake DNS response first: my-real-bank.com is at ATTACKER_IP.
4. Interception: the victim caches the fake answer and connects to the attacker's server, which hosts a replica of the bank site.
5. The attacker captures everything typed: usernames, passwords.

Why it works: the victim accepts the first response that matches its query. The attacker wins by answering faster than the real resolver.

⚠️ Two terms the course merges

Both end the same way: wrong IP, victim lands on the attacker's server.

⚠️ What stops it on HTTPS sites

If the bank uses HTTPS, the fake server can't present a valid certificate for my-real-bank.com, so the browser shows a certificate warning. Attackers get around this by:

• hoping the user clicks through the warning, or
• combining it with SSL stripping so the victim never uses HTTPS at all (next section).

Indicators

⚠️ Short TTL on its own is weak evidence. CDNs and cloud load balancers legitimately use TTLs of 20–60 seconds. Use it only alongside the other indicators.

Hunting in Wireshark

dns                                     all DNS
dns.flags.response == 1                 responses only
dns.qry.name == "my-real-bank.com"      one domain
dns.resp.ttl < 30                       short TTLs
dns.id == 0x1a2b                        all packets with one transaction ID

Spotting duplicate responses: every DNS query has a transaction ID. Filter on one ID. A legitimate exchange shows one query and one response. Two responses with different IPs, or from different source IPs, means someone forged one.

Defenses

• DNSSEC: cryptographically signed DNS records
• Encrypted DNS (DNS over HTTPS / TLS)
• HTTPS + HSTS, so a fake server can't pass certificate checks
• Block clients from using any resolver except the approved ones

7. SSL Stripping

SSL stripping = the attacker removes or prevents TLS encryption between client and server, so the victim talks plain HTTP while the attacker keeps HTTPS with the real server.

VICTIM ◄──── HTTP (plaintext) ────► ATTACKER ◄──── HTTPS (encrypted) ────► SERVER
       everything readable here                server sees a normal secure session

How it works (per the course)

1. Victim makes a request to a website.
2. Attacker intercepts it, using ARP spoofing or a rogue access point.
3. Attacker connects to the site over HTTPS but relays responses to the victim over HTTP.
4. Victim interacts over HTTP, exposing data in plaintext.

⚠️ The important detail the course skips

SSL stripping works because users rarely type https://. They type mybank.com:

1. Browser sends  http://mybank.com          ← unencrypted first request
2. Real server replies  301 → https://mybank.com
3. ATTACKER intercepts that redirect and removes it,
   rewriting every https:// link in the page to http://
4. Victim never reaches HTTPS. No certificate warning appears.

• The attack hits the first unencrypted request and the HTTP → HTTPS redirect.
• If the victim really did start with HTTPS (as the course's step 1 says), stripping fails: the attacker would need a fake certificate, which triggers a warning. That's a different attack (TLS interception).

The defense that kills it: HSTS (HTTP Strict Transport Security). A site tells the browser "always use HTTPS for me". With HSTS preload, the browser knows this before the first visit. That's why classic SSL stripping fails against Google, banks and most major sites today.

Indicators

Hunting in Wireshark

http.request && http.host == "mybank.com"     plain-HTTP requests to a site that should be HTTPS
http.response.code == 301 || http.response.code == 302
http.location contains "http://"              redirects pointing to plaintext
http.request.method == "POST"                 form submissions in cleartext
tls.handshake.type == 1                       TLS Client Hello (who started HTTPS)
tls.handshake.extensions_server_name          SNI: which domain the TLS session was for
tls.alert_message                             handshake failures

Then Follow → HTTP Stream on a suspicious POST. If you can read the password, the victim was stripped.

Tell-tale pairing in the capture: the attacker's IP has a TLS session with the real server at the same moment the victim has an HTTP session for the same domain.

8. How the Three Attacks Chain Together

ARP SPOOFING  ──►  attacker gets INTO THE PATH (all victim traffic flows through them)
     │
     ├──► DNS SPOOFING  ──► send the victim to a FAKE SITE
     │
     └──► SSL STRIPPING ──► keep the victim on HTTP so passwords are READABLE
                             (and no certificate warning appears)

In an investigation, find ARP spoofing first. It's usually the enabler for the other two. Once you know the attacker's MAC/IP, filter on it to find the DNS and HTTP manipulation.

9. Response Checklist

1. Identify the attacker's device: MAC, IP and switch port
2. Isolate it: shut the switch port or block it on Wi-Fi
3. Scope: which victims' ARP caches were poisoned? Which hosts got forged DNS answers?
4. Assume credentials are compromised for any victim who logged in over HTTP during the window → reset passwords, revoke sessions
5. Flush ARP and DNS caches on affected hosts (arp -d *, ipconfig /flushdns)
6. Root cause: how did the attacker get on the LAN? (rogue device, compromised host, weak Wi-Fi)
7. Harden: DAI, DHCP snooping, 802.1X, HSTS, DNSSEC

Core Rules

1. MITM abuses trust. ARP and DNS believe the first answer they get.
2. Interception gets them in the path; manipulation makes it pay.
3. Internal ARP/DNS spoofing means the attacker is already on your LAN. High severity.
4. Two MACs for one IP = ARP spoofing. Two answers for one DNS query = DNS spoofing.
5. Gratuitous ARP and short TTLs aren't malicious by themselves. Look for the combination.
6. SSL stripping hits the first HTTP request. HSTS defeats it.
7. Encryption is the backstop. Correct TLS makes interception worthless.
8. Equifax 2017 = unpatched Apache Struts, not MITM.

Acronyms

Intrusion Detection Systems (IDS) & Snort

The Big Picture

A firewall decides whether a connection may happen. Once it's allowed through, the firewall's job is mostly done. But attackers often get in through legitimate-looking connections (a valid VPN login, a normal web request). Something has to watch what happens after they're in. That's the IDS.

Firewall = the guard at the gate (checks who enters and leaves). IDS = the CCTV cameras inside (watches what people do once they're in, and raises the alarm).

What an IDS does and doesn't do

IDS only notifies; humans act. Its counterpart, the IPS (Intrusion Prevention System), sits inline and can drop malicious traffic automatically.

1. Two Ways to Classify an IDS

Every IDS is described by two independent questions:

1. Where is it deployed? → HIDS or NIDS
2. How does it detect? → Signature, Anomaly or Hybrid

So "Snort" = a network IDS using mostly signature detection.

2. Deployment Modes — Where It Lives

HIDS = a camera inside each room. NIDS = cameras on the corridors. Real environments use both, because each covers the other's blind spots.

3. Detection Modes — How It Decides

Signature-based

• Every known attack has a unique pattern = its signature.
• The IDS stores signatures in a database and compares traffic against them.
• Strength: fast, accurate, few false positives for known threats. The bigger and better the database, the better the detection.
• Weakness: can't detect zero-days. No signature means no detection, so it only catches attacks seen before.

Anomaly-based

• First learns normal behaviour (the baseline), then alerts on deviations.
• Strength: can detect zero-day attacks, since it doesn't need a known pattern.
• Weakness: many false positives. Unusual ≠ malicious: a new backup job, a software update or a busy sales day all look "abnormal".
• Fix: tune it, by manually defining what normal looks like.

⚠️ The course explains the false positives as "the nature of most legitimate programs matches the malicious ones". The clearer reason: anomaly detection flags anything different, and plenty of legitimate activity is different.

⚠️ Hidden risk the course skips: if an attacker is already present while the IDS learns its baseline, the malicious activity becomes part of "normal" (baseline poisoning).

Hybrid

• Combines both: known threats → signature matching; new threats → anomaly detection.
• Gets the speed and accuracy of signatures plus the zero-day coverage of anomalies.

Comparison

Signature = a "wanted" poster. Catches only faces it already knows. Anomaly = a guard who knows everyone's routine. Notices strangers, but also stops the new employee.

4. Snort — Overview

⚠️ The course says Snort uses "signature-based and anomaly-based detections". Snort is fundamentally signature/rule-based. Its inspectors catch some protocol anomalies (malformed packets, protocol violations), but it doesn't learn a behavioural baseline. Don't call it an anomaly-based IDS in an interview.

5. Snort's Three Modes

⚠️ The course's description of packet logging mode starts by describing detection and alerts, which is really NIDS mode. Keep it simple: sniffer = show, logger = save, NIDS = detect.

The NIDS mode is what makes Snort an IDS. The other two are utilities.

6. Promiscuous Mode — and Why It Isn't Enough

To monitor the whole network, the sensor's interface must be in promiscuous mode.

⚠️ What the course leaves out: on a modern switched network, the switch only sends a host its own traffic. Promiscuous mode lets the card accept everything, but it can't accept frames that never arrive. To really see the whole network, the sensor must be connected to a SPAN/mirror port or a network TAP (see network.md).

Promiscuous mode = willing to listen. SPAN/TAP = actually hearing everything. You need both.

7. Snort Files & Directories

• In Snort 3 the location isn't fixed: it's chosen at install time. Always load the config explicitly with -c <path>.
• The lab machine shows both snort.conf and snort.lua. snort.lua is the one Snort 3 actually uses.
• In Snort 3, a rule file must be included in snort.lua (in the ips section) to take effect. Writing to local.rules does nothing unless it's referenced.

8. Rule Format

alert  icmp  any  any  ->  $HOME_NET  any  (msg:"Ping Detected"; sid:10001; rev:1;)
└─┬─┘  └─┬┘  └┬┘  └┬┘  └┬┘ └───┬───┘  └┬┘  └──────────────────┬───────────────────┘
action proto src  src  dir   dest    dest            rule options (metadata)
              IP  port         IP    port

The header (before the parentheses)

Note: ICMP has no ports, but the rule syntax still requires the port fields, so they're written as any.

Rule actions

Rule options (inside the parentheses)

Other options you'll meet soon:

Syntax rules: options are separated by ;, the last option also ends with ;, and the whole block is in parentheses.

⚠️ SID ranges — the course breaks the convention

The course's examples use sid:10001 and sid:10003, which fall in the official range. They work in a lab, but in production they can clash with real rules. Use sid:1000001 and up.

9. Creating & Testing a Rule

Step 1 — Add the rule to local.rules

sudo nano /etc/snort/rules/local.rules

Add after the existing rules:

alert icmp any any -> 127.0.0.1 any (msg:"Loopback Ping Detected"; sid:10003; rev:1;)

Save: Ctrl+X → Y → Enter. ⚠️ Don't delete the existing rules. The next task needs them.

Step 2 — Run Snort on the live interface

sudo snort -q -l /var/log/snort -i lo -A alert_fast -c /etc/snort/snort.lua

Step 3 — Trigger the rule

ping 127.0.0.1

Step 4 — Read the alert

12.401504 [**] [1:1000001:1] "Loopback Ping Detected" [**] [Priority: 0] {ICMP} 127.0.0.1 -> 127.0.0.1

⚠️ Mismatch in the course screenshot: the rule you added has sid:10003, but the alert shows SID 1000001. Either the screenshot came from a different version of the rule, or another rule with the same message already exists in local.rules. In your lab, the SID in the alert should match the SID you wrote. If it doesn't, check local.rules for duplicates.

Three alerts, one per second = one alert per ping packet. ping sends one request per second.

10. Running Snort on a PCAP (Forensics)

For historical traffic saved in a capture file, replace the live interface with a file:

sudo snort -q -l /var/log/snort -r Task.pcap -A alert_fast -c /etc/snort/snort.lua

Replace Task.pcap with the path to your capture.

Useful trick: write a new rule, run it against an old PCAP, and you find out whether a newly discovered attack already happened in your network.

11. Command Flags Cheat Sheet

Reading the course command as a sentence:

sudo snort  -q      -l /var/log/snort   -i lo          -A alert_fast     -c /etc/snort/snort.lua
     run    quietly, log here,           on loopback,   short alerts,      with this config

Core Rules

1. Firewall = gate; IDS = cameras. The IDS watches what got through.
2. IDS alerts; IPS blocks. IDS is passive, IPS is inline.
3. HIDS = deep on one host; NIDS = broad across the network. Use both.
4. Signature = known attacks, few false positives. Anomaly = zero-days, many false positives. Hybrid = both.
5. Snort is rule-based, with modes sniffer (show), logger (save) and NIDS (detect).
6. Promiscuous mode isn't enough on a switch. You need SPAN or a TAP.
7. Rule = action, protocol, src, src port, direction, dst, dst port, (options).
8. Custom SIDs start at 1,000,000. Bump rev on every change.
9. -i for live traffic, -r for a PCAP. Always load the config with -c.
10. Test with -T, then trigger the rule yourself to prove it works.

Acronyms