// networking basics — course outline

Cybersecurity Foundations: Everything Before the Red/Blue Split

Soren Brumbach · · 30 min read

A ground-up course in the shared base of cybersecurity — the concepts, networks, tools, and scripting that both offensive (red team) and defensive (blue team) work stand on. Nobody starts as a specialist. Everyone starts here. By the time you finish, you'll have the vocabulary, the network literacy, the crypto and OS fundamentals, and the automation skills that make the eventual red-or-blue decision a matter of taste rather than capability — because you'll be able to do the groundwork either one requires.

This is the companion to the Linux Foundations curriculum, and it assumes you've done it. Where Linux comes up, we build on it rather than repeating it.

How to use this

  • Go in order. The networking modules build on each other, and almost everything later leans on networking. Concepts introduced early (the CIA triad, encapsulation, hashing) get reused constantly.
  • Do the exercises. You cannot learn to read a packet capture by reading about packet captures. You learn it by opening Wireshark and staring at a handshake until it clicks.
  • Build the lab in Module 1 before anything else hands-on. It's your legal, safe, breakable playground. Every later exercise assumes you have it.
  • Watch for the "→ Red/Blue" notes. Each one shows exactly how a foundation feeds both tracks — how an attacker uses it and how a defender uses the same knowledge. That's the whole point of learning it before the split.
  • One rule above all others (Module 0 covers it in full): only ever touch systems you own or have explicit written permission to test. The techniques here are neutral; the legality is about authorization.

A realistic pace is one module per few evenings. The networking and scripting blocks are the heaviest and deserve the most time — they're the two you'll use every single day, in either track.

Module 0 — Orientation: The Shared Language of Security

Before any tool or packet, you need the vocabulary. Security has a precise language, and beginners lose weeks to fuzzy definitions (mixing up "threat" and "vulnerability," or thinking Base64 is encryption). Nail these down now and everything else reads cleanly.

Topics

  • The CIA triad — the three goals all of security serves:
    • Confidentiality: only authorized people can read the data.
    • Integrity: the data hasn't been tampered with.
    • Availability: the data/system is there when it's needed.
    • Every attack violates at least one; every defense protects at least one.
  • AAA: Authentication (who are you?), Authorization (what are you allowed to do?), Accounting/Auditing (what did you do?).
  • The precise vocabulary (memorize the distinctions):
    • Asset — something worth protecting.
    • Threat — a potential cause of harm (a hurricane, a hacker).
    • Vulnerability — a weakness that a threat could exploit.
    • Exploit — the actual technique/code that takes advantage of a vulnerability.
    • Risk — the combination of how likely a threat is to hit a vulnerability and how bad it would be.
    • Attack surface — every point where an attacker could try to get in.
    • Attack vector — the specific path used.
  • Core principles: defense in depth (layers), least privilege (only the access you need), zero trust (verify everything, trust nothing by default), fail-safe defaults.
  • The split you're preparing for: Red team = offense (simulate attackers, find weaknesses). Blue team = defense (detect, respond, harden). Purple team = the two working together. Both read the same packets, use the same OS knowledge, write the same scripts — they just point them in opposite directions.
  • Ethics and law — non-negotiable: you may only test systems you own or have explicit written authorization to test. Scope, rules of engagement, and permission are what separate a penetration tester from a criminal. The skills are identical; the authorization is everything. Practice on your own lab, deliberately vulnerable targets (e.g., intentionally-vulnerable VMs), and sanctioned platforms only.

Why it matters This is the frame every later module hangs on. When you learn DNS, you'll immediately see how it touches confidentiality (leaking queries), integrity (poisoning), and availability (DDoS). The triad turns a pile of facts into a system.

→ Red/Blue: Red teams violate the CIA triad to prove risk; blue teams protect it. Both speak this exact vocabulary in every report they write. A finding is only useful if it names the asset, the vulnerability, and the risk clearly.

Exercises

  • For three everyday systems (your email, your bank, a game save), name one threat to each leg of the CIA triad.
  • Write one-sentence definitions of threat, vulnerability, exploit, and risk without looking. Check yourself.
  • Read a real published vulnerability advisory (a CVE) and identify the asset, vulnerability, and potential impact.

Module 1 — Build Your Lab (Virtualization & Safe Practice)

You cannot learn this safely or legally on the open internet or on machines you don't control. You need an isolated sandbox where breaking things is free and nothing leaks out. Building it is the first hands-on skill.

Topics

  • Why a lab: isolation (nothing you do escapes), legality (you own it), and repeatability (snapshots let you reset).
  • Hypervisors: the software that runs virtual machines.
    • Type 1 (bare-metal: ESXi, Proxmox/KVM) runs directly on hardware.
    • Type 2 (hosted: VirtualBox, VMware Workstation) runs as an app on your OS. Type 2 is where you'll start.
  • VM essentials: allocating CPU/RAM/disk, installing a guest OS, guest additions/tools, and snapshots — the save-state you take before doing anything risky so you can roll back instantly.
  • Virtual networking modes (understand these precisely — it's how you keep the lab safe):
    • NAT — VM shares the host's internet, isolated from your LAN.
    • Host-only — VM talks only to the host and other VMs, no internet.
    • Internal — VMs talk only to each other.
    • Bridged — VM appears as a real device on your physical network (use with caution).
    • For attack/defense practice, keep targets on a host-only or internal network so nothing escapes.
  • A starter lab: an attacker box (a security-focused Linux distro), a Linux target, and a Windows target, all on an isolated virtual network.
  • Deliberately vulnerable targets for practice (intentionally-broken VMs and web apps built for training).

Why it matters Every exercise from here forward assumes a safe place to run it. The snapshot habit alone will save you countless hours.

→ Red/Blue: Red teams build lab replicas of targets to develop and test attacks safely. Blue teams build labs to practice detection and response, and to safely detonate suspicious files. Same lab, both uses.

Exercises

  • Install a Type 2 hypervisor and stand up one Linux VM.
  • Take a snapshot, deliberately break something (delete a config), then roll back to prove the snapshot works.
  • Create a host-only network and confirm the VM can reach the host but not the internet.

Module 2 — Networking I: The Models, Addressing, and the Stack

Networking is the single most important pre-split skill, so we spend three modules on it plus a fourth on reading it live. Start with the mental models and how a packet is actually built.

Topics

  • Why models exist: they break the impossibly complex job of "get data from here to there" into layers, each with one responsibility.
  • The OSI model (7 layers) — the teaching model:
    1. Physical — cables, radio, voltages, bits on a wire.
    2. Data Link — local delivery on one network segment; MAC addresses, switches, frames.
    3. Network — delivery between networks; IP addresses, routers, packets.
    4. Transport — end-to-end delivery to the right program; TCP/UDP, ports, segments.
    5. Session — setting up/maintaining conversations.
    6. Presentation — formatting, encoding, encryption.
    7. Application — what the user's program speaks; HTTP, DNS, SSH.
  • The TCP/IP model (4 layers) — the practical model the internet actually uses: Link, Internet, Transport, Application — and how it maps onto OSI.
  • Encapsulation — the core "aha": as data goes down the stack, each layer wraps it in its own header (application data → segment → packet → frame → bits). Going up the stack on the other end, each layer unwraps its header. A packet is an onion.
  • IP addressing (IPv4): the 32-bit dotted-quad structure, private ranges (10.x, 172.16–31.x, 192.168.x) vs public addresses, loopback (127.0.0.1). IPv6 at a glance and why it exists.
  • Subnetting & CIDR — how a network is carved into pieces:
    • The netmask splits an address into a network part and a host part.
    • CIDR notation (/24, /16) says how many bits are the network part.
    • Network address, broadcast address, and usable host range — what they are and how to reason about them in plain terms.
  • MAC addresses & ARP: MACs identify devices on the local segment; ARP is the protocol that asks "who has this IP? tell me your MAC" — the bridge between Layer 3 (IP) and Layer 2 (MAC).
  • Routing basics: the default gateway as your network's exit door, and how routers forward packets hop by hop toward a destination.
  • NAT: why the whole office shares one public IP, and why your private IP isn't what a website sees.

Why it matters Every attack and every defense moves over this stack. Knowing which layer a thing lives on tells you which tools and which attacks apply. "Is this a Layer 2 problem or a Layer 3 problem?" is a question you'll ask constantly.

→ Red/Blue: Attackers pick a layer to target (ARP spoofing at L2, IP spoofing at L3, app attacks at L7). Defenders monitor and segment at those same layers (VLANs at L2, firewalls at L3/L4). Encapsulation is literally what you'll be reading in Module 5.

Exercises

  • Run ip addr (Linux) / ipconfig (Windows); identify your IP, subnet mask (CIDR), and MAC.
  • Run ip route / route print and find your default gateway.
  • Inspect your ARP table (ip neigh / arp -a) and match an IP to a MAC.
  • On paper: given 192.168.1.0/24, state the network address, the broadcast address, and how many usable hosts it holds. Then do it for a /26.

Module 3 — Networking II: Transport, Ports, and the Three-Way Handshake

Now zoom into Layer 4, where connections are actually made and where a huge amount of both scanning (red) and monitoring (blue) happens.

Topics

  • TCP vs UDP — the two transport protocols:
    • TCP: connection-oriented, reliable, ordered, error-checked. Slower, but nothing is lost. Used by web, email, SSH, file transfer.
    • UDP: connectionless, "fire and forget," no delivery guarantee. Fast and lightweight. Used by DNS, DHCP, VoIP, streaming, games.
  • Ports and sockets: a port number identifies which program on a host should get the data. A socket is the full (IP address : port) pair. Port ranges: well-known (0–1023), registered (1024–49151), ephemeral/dynamic (49152–65535).
  • The three-way handshake — how every TCP connection begins (memorize this cold):
    1. SYN — client says "I'd like to talk; here's my starting sequence number."
    2. SYN/ACK — server says "OK, I acknowledge yours; here's mine."
    3. ACK — client says "acknowledged — we're connected." After this, data flows. Sequence and acknowledgment numbers track every byte so nothing is lost or reordered.
  • Connection teardown: the polite FIN/ACK exchange to close, and the abrupt RST to reset/reject.
  • TCP flags and why they matter: SYN, ACK, FIN, RST, PSH, URG. Different scan techniques manipulate these flags to probe hosts.
  • TCP connection states: LISTEN, SYN-SENT, ESTABLISHED, TIME_WAIT, CLOSE_WAIT — what they mean when you inspect live connections.
  • UDP's model: no handshake, no state — which is exactly why it's fast and why it behaves differently under scanning and monitoring.

Why it matters The handshake is the heartbeat of the internet, and understanding it is the prerequisite for understanding port scanning, firewalls, connection tracking, and half of what you'll see in a packet capture.

→ Red/Blue: Port scanning (recon) is entirely about manipulating the handshake — a full connect scan completes it, a SYN scan sends SYN and never finishes, other scans abuse flag combinations to fingerprint hosts. Defenders detect scans precisely by watching for these abnormal handshake patterns and read connection states to spot suspicious sessions.

Exercises

  • Run ss -tulnp (Linux) / netstat -ano (Windows) and list what's listening, on which ports, over TCP vs UDP.
  • Establish a connection (e.g., curl a website) and, in another terminal, watch its state transitions.
  • Draw the three-way handshake from memory, labeling the flags and what each step accomplishes. You'll verify it against a real capture in Module 5.

Module 4 — Networking III: The Protocols You'll Live In (and DNS in Depth)

Layer 7 is where named services live. You need a core set of ports/protocols memorized and a deep understanding of DNS, because DNS shows up in nearly every investigation and every attack chain.

Topics

  • The core ports to memorize (know these on sight):
    • 20/21 FTP, 22 SSH, 23 Telnet, 25 SMTP, 53 DNS, 67/68 DHCP, 80 HTTP, 110 POP3, 143 IMAP, 161 SNMP, 389 LDAP, 443 HTTPS, 445 SMB, 465/587 SMTPS, 636 LDAPS, 993 IMAPS, 3306 MySQL, 3389 RDP, 5432 PostgreSQL.
    • Note which are plaintext (Telnet, FTP, HTTP, POP3) vs. encrypted (SSH, HTTPS, IMAPS) — this distinction matters enormously for both attack and defense.
  • DNS — the internet's phone book (learn this thoroughly):
    • What it does: translates human names (example.com) into IP addresses.
    • The resolution process: your resolver asks a root server → a TLD server (.com) → the domain's authoritative server, walking down until it gets the answer. Recursive vs iterative queries.
    • Record types: A (name→IPv4), AAAA (name→IPv6), CNAME (alias), MX (mail servers), TXT (arbitrary text, used for verification/SPF), NS (name servers), PTR (reverse: IP→name), SOA (zone authority).
    • Caching & TTL: answers are cached for a time-to-live to reduce load — and stale caches matter for both troubleshooting and attacks.
    • Why DNS is a security battleground: attackers abuse it for command-and-control and data exfiltration (hiding traffic in DNS queries); defenders treat DNS logs as one of the richest sources of detection.
  • DHCP — how a device gets its IP automatically, via the DORA exchange: Discover → Offer → Request → Acknowledge.
  • HTTP/HTTPS — the web's protocol (full deep dive in Module 6): request/response, methods, status codes.
  • ICMP — the "network diagnostics" protocol behind ping and traceroute.
  • The remote-access/file trio you'll see everywhere: SSH (secure remote shell), RDP (Windows remote desktop), SMB (Windows file sharing) — all high-value targets and high-value telemetry.
  • Plaintext vs encrypted as a recurring theme: anything plaintext can be read straight off the wire (you'll prove this in Module 5).

Why it matters You can't interpret traffic, triage an alert, or plan an assessment without knowing what normally talks on which port. When port 4444 lights up where you expected 443, that instinct comes from this module.

→ Red/Blue: Red teams enumerate services by port and abuse protocols (DNS tunneling, SMB exploitation). Blue teams baseline "normal" per port and alert on anomalies (DNS to weird domains, SMB from unexpected hosts, plaintext creds on the wire).

Exercises

  • Use dig / nslookup to resolve a domain and request its A, MX, and NS records specifically.
  • Trace a full DNS resolution and identify each server tier involved.
  • ping and traceroute/tracert a host and explain, per hop, what ICMP is telling you.
  • Make a flashcard set of the core ports above and drill until instant.

Module 5 — Reading Traffic: tcpdump & Wireshark

You can't attack or defend traffic you can't read. This is the module that turns all that networking theory into something you can see with your own eyes. Packet analysis is the ground truth of networking — when documentation and reality disagree, the capture is right.

Topics

  • Why packet analysis: it's the unfiltered truth of what actually crossed the wire — no summaries, no assumptions.
  • Capturing traffic: network interfaces, promiscuous mode (grab everything the NIC sees, not just your own traffic), where to capture (on a host, at a tap/SPAN port), and capturing safely inside your lab.
  • tcpdump — the command-line workhorse:
    • Basic syntax and choosing an interface.
    • BPF filters (host, port, tcp, udp, and/or) to grab only what you want.
    • Reading the terse output and writing captures to a .pcap file for later.
  • Wireshark — the graphical powerhouse:
    • The three panes: packet list, packet details (the layered breakdown — encapsulation made visible!), packet bytes.
    • Follow TCP/HTTP stream to reconstruct a whole conversation.
    • Display filters (e.g., http, dns, ip.addr == x, tcp.flags.syn == 1) — and the critical distinction from capture filters:
      • Capture filter = decide what to record (applied before capture, can't be undone).
      • Display filter = decide what to show from what you already recorded (applied after, changeable anytime).
      • Confusing these two is the #1 beginner mistake — keep them straight.
    • Expert info, coloring rules, and statistics (protocol hierarchy, conversations).
  • Reading real things (tie every earlier module to reality):
    • Spot the three-way handshake (SYN, SYN/ACK, ACK) from Module 3.
    • Read a DNS query and response from Module 4.
    • Read an HTTP request/response and a plaintext login (see why plaintext protocols are dangerous).
    • See ARP doing its who-has dance from Module 2.
    • Recognize retransmissions, resets, and scan patterns.
  • Extracting artifacts: pulling files/objects out of a capture.
  • pcap in both worlds: as evidence (defenders reconstruct an incident) and as recon/interception (attackers sniff for credentials and secrets).

Why it matters This is where networking stops being abstract. After this module, "the three-way handshake" isn't a diagram you memorized — it's three highlighted lines you can point to. That transformation is the whole reason networking comes before everything else.

→ Red/Blue: Attackers sniff traffic to steal plaintext creds and map a network; they craft and inspect packets to understand a target. Defenders live in packet captures during incident response and use them to build and validate detections. Identical tool, identical skill, opposite intent.

Exercises

  • Capture your own traffic while browsing an HTTP (not HTTPS) test site and find your own request in Wireshark.
  • Capture a DNS lookup and identify the query name, record type, and the answer.
  • Isolate a single TCP connection and confirm the handshake, data, and teardown in order.
  • Practice the same capture with both a capture filter and a display filter and articulate the difference out loud.
  • Analyze a pre-made practice .pcap and answer: who talked to whom, over what protocol, and what was transferred?

Module 6 — How the Web Works (Because Everything Is Web Now)

The web is the largest attack surface in existence and the busiest source of logs. Both tracks need HTTP in their bones. You met HTTP as a protocol in Module 4; here you learn it as a system.

Topics

  • HTTP anatomy: the request (method + path + headers + optional body) and the response (status code + headers + body).
  • Methods: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS — and which are "safe" vs. state-changing.
  • Status codes: the families — 2xx success, 3xx redirect, 4xx client error (401/403/404), 5xx server error — and the ones you'll see constantly.
  • Headers: what they do (content types, caching, auth, security headers) and why they're a rich signal.
  • URLs/URIs: scheme, host, port, path, query string, fragment — how to read one precisely.
  • State on a stateless protocol: HTTP forgets you between requests, so cookies and sessions carry identity. Session IDs, what a session cookie is, and why stealing one matters.
  • Web authentication: HTTP basic/bearer, cookie-based sessions, tokens/JWT at a glance.
  • HTTPS/TLS in transit: what the padlock actually guarantees (encryption + server identity) and what it does not (it doesn't mean the site is safe). Full crypto in Module 7.
  • The browser model: client vs. server, the DOM, and the same-origin policy conceptually (why a page can't freely read another site's data).
  • APIs: REST, endpoints, and JSON as the data format you'll parse endlessly (ties into scripting, Module 10).
  • Infrastructure at a glance: web servers, reverse proxies, load balancers, and where logs get generated.

Why it matters A huge share of real-world attacks and defenses happen over HTTP. If you can read a request/response fluently, web security later becomes learnable instead of overwhelming.

→ Red/Blue: Web apps are the most common entry point, so red teams probe requests, tamper with parameters, and hijack sessions. Blue teams read web-server and proxy logs, watch for anomalous requests, and tune protections. Both need to read an HTTP exchange without hesitation.

Exercises

  • Open your browser's developer tools (Network tab), load a site, and read a full request/response including headers.
  • Use curl -v to make a GET and a POST by hand and inspect exactly what's sent and returned.
  • Find a session cookie in your browser and explain what would happen if someone copied it.
  • Call a public JSON API with curl and read the response structure.

Module 7 — Cryptography Fundamentals

Crypto underpins passwords, HTTPS, SSH, signatures, and disk encryption. You don't need the math, but you absolutely need to stop conflating three different things that beginners constantly mix up.

Topics

  • The three things people confuse — get this crystal clear:
    • Encoding (e.g., Base64, hex, URL-encoding): reversible, not secret, no key. It's about representing data, not hiding it. Anyone can decode it. Base64 is not encryption.
    • Hashing (e.g., SHA-256): one-way. You cannot reverse it back to the input. Same input always gives the same fixed-length output. Used for integrity checks and password storage.
    • Encryption: reversible with a key. Without the key, it's unreadable. This is the one that provides confidentiality.
  • Encoding in practice: Base64 and hex — where you'll meet them (data in transit, tokens, obfuscation) and how to decode them.
  • Hashing in depth: properties (deterministic, fixed-length, avalanche effect, collision resistance), why MD5/SHA-1 are broken for security, and the SHA-2 family. Salting and why it defeats precomputed attacks. How passwords should be stored (salted, slow hashes) vs. how they shouldn't.
  • Symmetric encryption: one shared key for encrypt and decrypt (AES). Fast, but you must get the key to the other side securely — the key-distribution problem.
  • Asymmetric encryption: a public/private key pair (RSA, ECC). Encrypt with the public key, decrypt with the private; or sign with the private, verify with the public. Solves key distribution and enables digital signatures.
  • Hybrid systems: why the real world (like TLS) uses asymmetric crypto to exchange a key, then fast symmetric crypto for the bulk data.
  • PKI & certificates: Certificate Authorities, chains of trust, and what a certificate actually proves. How the TLS handshake uses certificates to establish an encrypted, authenticated channel (high level).
  • Where it all shows up: HTTPS, SSH keys, signed software, encrypted disks, password databases.

Why it matters "Is this encoded, hashed, or encrypted?" is a question you'll ask on the job constantly, and getting it wrong wastes hours. Understanding hashing is the prerequisite for understanding password attacks and defenses alike.

→ Red/Blue: Red teams crack weak/unsalted password hashes, decode "obfuscated" (merely encoded) data, and abuse weak or misconfigured crypto. Blue teams enforce strong hashing and TLS, validate certificates, and spot when data is only encoded (not protected) or when weak algorithms are in use.

Exercises

  • Base64-encode a string, then decode it — prove to yourself it's reversible and keyless.
  • Hash the same word twice and confirm identical output; change one letter and watch the whole hash change (avalanche).
  • Inspect a real website's TLS certificate in your browser: who issued it, to whom, and when it expires.
  • Explain, in one sentence each, when you'd use hashing vs. symmetric vs. asymmetric.

Module 8 — Operating Systems Under a Security Lens: Linux & Windows

You've learned Linux fundamentals already. Now revisit them through a security lens and — crucially — pick up Windows, which most Linux-first learners under-know and which dominates enterprise environments (and CCDC/NCL-style competitions).

Topics

  • Linux, security-relevant recap: users/groups and permissions (including setuid/setgid), processes and how programs run, where logs live (/var/log), systemd/journald for services and logs, and scheduled tasks (cron). (See the Linux Foundations curriculum for depth.)
  • Windows fundamentals — the gap to close:
    • The registry: the central hierarchical config database; hives and keys; why it's both a config store and a forensic goldmine.
    • The security model: user accounts, SIDs (security identifiers), access tokens, and UAC (User Account Control).
    • NTFS permissions/ACLs: how Windows controls file access (the Windows analog to Linux permissions).
    • Processes and services: how Windows runs background programs, and how to inspect them.
    • Windows Event Logs and Event Viewer (Security, System, Application channels) — the primary source of defensive telemetry on Windows.
    • The Windows command lines: cmd and, importantly, PowerShell — the scripting/automation and administration layer (previewed here, used in Module 10).
  • Active Directory (AD) fundamentals — because both tracks live in it:
    • What AD is: a centralized directory that manages authentication, authorization, and policy for a whole organization.
    • Domains and domain controllers; OUs (organizational units); group policy (centralized configuration) at a glance.
    • Why AD is the "crown jewel": compromise the domain and you often control everything.
  • The cross-cutting idea: every OS enforces identity, permissions, processes, and logging — the names differ between Linux and Windows, but the concepts are the same.

Why it matters Real environments are mixed. If you only know Linux, half the battlefield is invisible to you. Understanding both operating systems' security models — and AD as the thing that ties enterprise Windows together — is mandatory before either track.

→ Red/Blue: Red teams enumerate and attack AD (it's the top target in most engagements) and pivot across Windows and Linux hosts. Blue teams harden AD, monitor Windows Event Logs and Linux logs, and detect malicious use of built-in OS features. The same OS internals are the terrain for both.

Exercises

  • On a Windows VM: open Event Viewer and find the Security log; identify a successful and a failed logon event.
  • Inspect NTFS permissions on a folder and compare the model to Linux rwx.
  • Open the registry editor (read-only mindset) and navigate the hive structure.
  • Diagram, in your own words, what a domain controller centralizes for an organization.

Module 9 — Identity, Authentication & Access

Credentials are the single most fought-over thing in security — the front door to everything. Both tracks spend enormous energy attacking or protecting identity, so understand the machinery before the split.

Topics

  • AuthN vs AuthZ (reinforced): authentication proves who you are; authorization decides what you can do. They're different steps and fail differently.
  • Authentication factors: something you know (password), have (token/phone), are (biometric). MFA combines factors and is one of the highest-impact defenses.
  • Passwords under the hood: how they should be stored (salted, slow hashes — ties to Module 7), password policies, and why length beats complexity. What makes a password database a jackpot.
  • Windows authentication: NTLM (older, hash-based) and Kerberos (ticket-based) at a conceptual level — the KDC, tickets, and the TGT. You don't need every detail yet, but you need the shape, because credential attacks and defenses both revolve around these.
  • Sessions and tokens: how you stay logged in after authenticating (session cookies, access tokens), and why token/session theft bypasses passwords entirely.
  • SSO and federation: OAuth and SAML at a glance — logging into many services via one identity provider.
  • Least privilege in practice: local vs. domain admin, service accounts, and why over-privileged accounts are the root of so many breaches.

Why it matters Most real intrusions don't "hack in" — they log in with stolen or guessed credentials. Understanding identity is understanding how attackers actually move and how defenders actually stop them.

→ Red/Blue: Red teams steal, crack, relay, and abuse credentials and tickets to move through a network. Blue teams enforce MFA and least privilege, monitor authentication logs, and detect credential abuse. Every technique on both sides assumes the identity fundamentals in this module.

Exercises

  • Turn on MFA somewhere you have an account and observe which factor each step uses.
  • Explain why a long passphrase can beat a short complex password against cracking.
  • Describe, at a high level, the difference between authenticating with NTLM and with Kerberos.
  • Identify one account on your systems that has more privilege than it needs.

Module 10 — Scripting & Automation: Bash, Python, and Regex

Bash for glue, Python for tooling, regex for parsing. Every serious task — mangling scan output, writing a quick exploit, automating log triage — runs through automation. This module sits before the split because both tracks depend on it equally. Manual doesn't scale; scripting is the force multiplier that separates operators from button-pushers.

Topics

  • Why automate: security work drowns you in repetitive, high-volume tasks (thousands of log lines, hundreds of hosts). Scripting turns hours into seconds and makes your work repeatable.
  • Bash — the glue (builds directly on the Linux curriculum):
    • Variables, quoting, and command substitution.
    • Conditionals and loops (if, for, while).
    • Pipes and redirection as the heart of Unix composition (from Linux Module 5).
    • The text-processing toolkit: grep, sed, awk, cut, sort, uniq, tr, wc, xargs — chaining small tools to slice and reshape output.
    • Writing reusable scripts: shebang, arguments ($1, $@), exit codes.
    • The niche: quick one-liners and stitching existing tools together.
  • Python — the tooling (when Bash gets awkward):
    • Core syntax: variables, types, conditionals, loops, functions.
    • Data structures: lists, dictionaries, sets, tuples — and why dictionaries are perfect for structured data.
    • File I/O: reading and writing files line by line.
    • Working with JSON (parsing API and tool output) and CSV.
    • The requests library for HTTP (talk to web apps and APIs from code).
    • socket basics for raw network interaction.
    • The re module for regex in code.
    • Virtual environments and installing packages with pip.
    • The niche: real tools with logic, state, libraries, and structure — parsers, scanners, small exploits, automation.
  • Regex — the parser (the shared superpower):
    • Literals, character classes (\d, \w, \s, [...]), anchors (^, $), quantifiers (*, +, ?, {n,m}), groups and alternation, capture groups.
    • Why regex is everywhere: extracting IPs, hashes, URLs, and fields from unstructured text; filtering logs; validating input.
    • Testing regex safely and reading someone else's pattern.
  • Choosing the right tool: a quick Bash one-liner for glue; Python when you need data structures, libraries, or real logic; regex embedded in either for pattern extraction.

Why it matters This is the module that scales you. Whether you end up red or blue, the difference between a slow analyst and a fast one is almost always automation. The exercises here should become reflexes.

→ Red/Blue: Red teams script exploit chains, parse scan results, and automate enumeration. Blue teams automate log triage, parse alerts, and build detection tooling. The scripts differ; the skills — Bash glue, Python tooling, regex parsing — are identical.

Exercises

  • Bash: given a file of mixed log lines, extract every unique IP address using grep/sort/uniq in one pipeline.
  • Bash: write a script that takes a filename as an argument and reports how many lines contain "error."
  • Python: read a JSON file (or API response), pull out a specific field from every record, and print a summary.
  • Python: use requests to fetch a page and report its status code and a header.
  • Regex: write one pattern that matches an IPv4 address and another that matches a SHA-256 hash, and test them against sample text.
  • Combine: take raw output from a tool, parse the fields you care about with regex, and reshape it into clean CSV.

Module 11 — Logging, Telemetry & Evidence

Both tracks revolve around what systems record. Attackers want to avoid or erase it; defenders want to collect and read it. Before the split, understand what gets logged, where it lives, and in what form — the raw material of detection and forensics.

Topics

  • The core idea: nearly everything a system does can leave a record. Security is often the art of finding the meaningful record in a mountain of noise.
  • Where logs live:
    • Linux: /var/log, syslog, and the systemd journal (journalctl).
    • Windows: Event Logs (Security/System/Application) via Event Viewer.
    • Applications, web servers, firewalls, and network devices each keep their own.
  • Log formats: plaintext lines, key-value, JSON, CSV — and why structured formats are easier to parse (ties straight into Module 10's parsing skills).
  • What's worth logging for security: authentication events, process creation, network connections, privilege changes, file access.
  • Centralization: the concept of shipping logs to one place (a SIEM) so you can search across an entire environment at once — introduced here conceptually; it becomes central on the blue side.
  • Time matters: timestamps, time zones, and clock synchronization — because reconstructing an incident means ordering events correctly.
  • Evidence handling at a glance: the idea that logs and captures can be evidence, and integrity (hashing from Module 7) matters when they are.

Why it matters Detection, investigation, and even measuring the success of an attack all come down to telemetry. Knowing where the evidence lives — and how to parse it with the scripting skills from Module 10 — is a genuinely shared prerequisite.

→ Red/Blue: Red teams study logging to understand what they'll trip and how to stay quiet; blue teams collect, centralize, and mine that same telemetry to catch them. Both are reading the same event streams with opposite goals.

Exercises

  • On Linux, use journalctl and grep to find every failed login in the last day.
  • On Windows, find the Event ID for a failed logon and locate one in the Security log.
  • Take a sample log file and, using Module 10 skills, extract and count events by type.
  • Explain why synchronized clocks matter when correlating events across two machines.

Module 12 — Threats, Vulnerabilities & the Frameworks That Organize Them

Finally, the shared mental map: how the field names, scores, and organizes attacks. This vocabulary lets red and blue talk to each other — and it's how you'll structure your own thinking in either role.

Topics

  • Vulnerabilities, tracked: CVE (the global catalog of known vulnerabilities — each gets an ID) and CVSS (a 0–10 score of severity). How to read an advisory and judge "how bad is this, really?"
  • The attacker lifecycle — the stages an intrusion tends to move through: reconnaissance → initial access → execution → persistence → privilege escalation → lateral movement → collection → exfiltration → impact. (Different frameworks name these slightly differently, but the shape is consistent.)
  • The Cyber Kill Chain: a classic staged model of an attack from recon to action-on-objectives.
  • MITRE ATT&CK: the shared, detailed knowledge base of real-world attacker tactics (the why) and techniques (the how). It's the common language both tracks use — red teams to plan and describe, blue teams to map detections.
  • Common threat categories at a glance: malware families (virus, worm, trojan, ransomware), phishing/social engineering, web attacks, network attacks, and misconfiguration. (Deep technique study belongs to the tracks; here you learn the map.)
  • The vulnerability lifecycle: discovery → disclosure → patch → (and the danger window of unpatched or zero-day issues).
  • Defense concepts to carry forward: detection vs. prevention, indicators of compromise, and the reality that you're managing risk, not achieving perfect security (back to Module 0).

Why it matters Frameworks are how the whole industry shares knowledge. When a red teamer says "we used a T-number technique for lateral movement" and a blue teamer replies "we have a detection for that," they're speaking ATT&CK. Learning the map now means the track-specific material later has somewhere to attach.

→ Red/Blue: Red teams use these frameworks to plan realistic operations and to communicate findings; blue teams use the same frameworks to prioritize defenses and map coverage. The frameworks are literally the meeting point of the two tracks (this is what "purple team" runs on).

Exercises

  • Look up a recent high-severity CVE and read its CVSS score and description; explain the risk in plain terms.
  • Pick one MITRE ATT&CK tactic and read two techniques under it.
  • Map a simple hypothetical breach onto the attacker-lifecycle stages.
  • Explain the difference between a vulnerability, an exploit, and a zero-day (callback to Module 0).

Capstone — You're Ready to Choose a Track

If you can do all of the following without notes, you have the complete shared foundation, and the red/blue decision is now about interest, not readiness:

  • Explain the CIA triad and use the precise vocabulary (threat/vulnerability/exploit/risk) correctly.
  • Trace data down and up the OSI/TCP-IP stack and explain encapsulation.
  • Reason about IP addressing and subnetting, and identify what talks on the core ports.
  • Draw the three-way handshake and then find it in a live packet capture.
  • Read an HTTP request/response and a DNS exchange fluently.
  • Correctly distinguish encoding, hashing, and encryption, and explain symmetric vs. asymmetric.
  • Navigate both Linux and Windows security models and explain what Active Directory centralizes.
  • Explain how authentication works and why credentials are the main battleground.
  • Write Bash to reshape output, Python to build a small tool, and regex to extract fields from text.
  • Say where logs live and pull meaningful events out of them.
  • Speak in CVE/CVSS/ATT&CK terms and map an attack to its lifecycle.

How the split builds on this foundation:

  • Red team / offense takes these fundamentals toward reconnaissance, exploitation, post-exploitation, and reporting — everything you learned, aimed at finding and proving weaknesses.
  • Blue team / defense takes the same fundamentals toward monitoring, detection engineering, incident response, threat hunting, and hardening — aimed at catching and stopping attacks.
  • Purple is simply both, working from the shared vocabulary (Module 12) you now speak.

Notice that every track-specific skill lands on a foundation above: exploitation on networking + web + OS, detection on logging + telemetry + networking, credential attacks and defenses on identity + crypto, and all of it accelerated by the scripting from Module 10. That's why the foundation comes first — pick either track and you're standing on ground you already understand.

  • Wireshark & tcpdump — practice reading real traffic constantly; it's the highest-leverage skill here.
  • A vulnerable-by-design practice environment (intentionally weak VMs and web apps) and sanctioned learning platforms — your legal playground.
  • dig/nslookup, curl, ss/netstat, nmap (used gently for learning) — everyday network literacy tools.
  • CyberChef — a browser tool for encoding/decoding, hashing, and data transformation; superb for building crypto/encoding intuition (Module 7).
  • The MITRE ATT&CK website — the shared map from Module 12; browse it early and often.
  • Python's requests and re docs, and a good regex tester — your scripting reference set.
  • Official OS documentation (Linux man pages, Microsoft's Windows/AD docs) for the OS module.
  • A note-taking habit (your second brain): document every command, capture, and finding — professional security work is documentation.

Above all: build the lab, break things in it, and read real packets and real logs. Every concept in this curriculum becomes permanent the moment you see it happen with your own eyes rather than just reading about it here.