This is written to be read like a book, not skimmed like flashcards. Every concept is explained the way a patient instructor would explain it at a whiteboard: what it is, why it exists, how it actually works, where people get it wrong, and how you'll use it on the job and on the exam.
Part A takes you through the fundamentals every security professional must own, mapped to the five CompTIA Security+ (SY0-701) domains — but taught in depth, not bullet-listed. Part B carries you past the exam into the adversary tradecraft, detection engineering, and investigation skill of a Senior / L3 SOC & Incident Response analyst — always from the defender's chair: how an attack works → the traces it leaves → how you catch and kill it.
A note on how to read this. Don't try to swallow it in one sitting. Each section below has an estimated read time and a study time (read time is a straight read-through; study time assumes you pause, take notes, and actually absorb it — roughly 3× longer). Read a section, close the doc, and try to explain it out loud to an imaginary student. If you can teach it, you know it. If you stumble, re-read. That "teach-back" loop is the fastest path to mastery.
Ethics & scope. This is a defender's manual. Offensive techniques are explained so you can detect, hunt, and respond — with the exact logs, telemetry, and logic a SOC uses. It deliberately contains no working exploit code or step-by-step weaponization. Practice only in labs you own or are explicitly authorized to test.
As you read, you'll see these signposts. They're not decoration — each one tells you how to treat the paragraph next to it.
| Marker | Meaning — and what to do with it |
|---|---|
🎯 |
Maps to a Security+ SY0-701 objective. If you're exam-focused, these are non-negotiable. |
🔬 |
Senior/L3 depth, beyond the exam. Skip on a first Security+ pass; return when you're pushing past certified. |
🔍 |
A detection / hunt / response application — how this shows up in real SOC work. |
🧨 |
A Tricky Question — the exact way exams (and interviewers) try to trip you. Read the trap, then the reasoning. These are worth their weight in gold. |
⚠️ |
A caveat or a place people reliably go wrong. |
💡 |
A pro insight — the thing that makes it click. |
📖 |
A worked example or analogy to cement the idea. |
This guide is ~23,896 words. At a straightforward reading pace (~200 words/min) that's about 119 minutes (~2.0 hours) to read through. But this is a study text — budget roughly 2.5× that (~5.0 hours) to actually absorb it with notes and teach-backs. Read times below are per section; study time is the read time × 2.5.
Tip: each row is a natural single sitting. Don't binge — one or two sections, then a teach-back, beats a marathon.
Part total: ~166 words · read ~1 min · study ~2 min
| Section | Words | Read | Study |
|---|---|---|---|
| How this guide is marked up | 166 | 1 min | 2 min |
Part total: ~3,417 words · read ~17 min · study ~42 min
| Section | Words | Read | Study |
|---|---|---|---|
| 0.1 The OSI Model — Deep Dive | 2,156 | 11 min | 28 min |
| 0.2 The TCP/IP Model (What Actually Runs) | 127 | 1 min | 2 min |
| 0.3 Common Ports — The Complete Working Reference | 1,134 | 6 min | 15 min |
Part total: ~11,268 words · read ~56 min · study ~140 min
| Section | Words | Read | Study |
|---|---|---|---|
| Domain 1 — General Security Concepts (12%) 🎯 | 57 | 1 min | 2 min |
| 1. The CIA Triad and Core Principles | 404 | 2 min | 5 min |
| 2. Security Control Types and Categories | 567 | 3 min | 8 min |
| 3. AAA, Identity, and Access Fundamentals | 685 | 3 min | 8 min |
| 4. Zero Trust and Defense in Depth | 514 | 3 min | 8 min |
| 5. Cryptography Fundamentals and PKI | 1,186 | 6 min | 15 min |
| 6. Physical Security and Deception | 340 | 2 min | 5 min |
| 7. Change Management | 280 | 1 min | 2 min |
| Domain 2 — Threats, Vulnerabilities & Mitigations (22%) 🎯 | 39 | 1 min | 2 min |
| 8. Threat Actors and Their Motivations | 383 | 2 min | 5 min |
| 9. Attack Vectors and Attack Surfaces | 322 | 2 min | 5 min |
| 10. Social Engineering | 532 | 3 min | 8 min |
| 11. Malware — The Families and How to Tell Them Apart | 563 | 3 min | 8 min |
| 12. Application, OS, Password, and Network Attacks | 568 | 3 min | 8 min |
| 13. Mitigations — Turning Knowledge into Defense | 226 | 1 min | 2 min |
| Domain 3 — Security Architecture (18%) 🎯 | 34 | 1 min | 2 min |
| 14. Architecture Models and the Cloud | 437 | 2 min | 5 min |
| 15. Network Security Design and Segmentation | 312 | 2 min | 5 min |
| 16. Secure Protocols | 156 | 1 min | 2 min |
| 17. Data Protection and Classification | 234 | 1 min | 2 min |
| 18. Resilience and Recovery | 420 | 2 min | 5 min |
| Domain 4 — Security Operations (28%) 🎯 | 45 | 1 min | 2 min |
| 19. Hardening and Secure Baselines | 147 | 1 min | 2 min |
| 20. Monitoring, Logging, and SIEM | 326 | 2 min | 5 min |
| 21. Identity and Access Management (Operational) | 340 | 2 min | 5 min |
| 22. Automation and Orchestration (SOAR) | 215 | 1 min | 2 min |
| 23. The Incident Response Lifecycle 🔥 | 372 | 2 min | 5 min |
| 24. Digital Forensics and the Order of Volatility | 302 | 2 min | 5 min |
| 25. Vulnerability Management | 261 | 1 min | 2 min |
| Domain 5 — Security Program Management & Oversight (20%) 🎯 | 55 | 1 min | 2 min |
| 26. Governance, Risk, and Compliance (GRC) | 425 | 2 min | 5 min |
| 27. Third-Party and Supply Chain Risk | 165 | 1 min | 2 min |
| 28. Security Awareness and Audits | 356 | 2 min | 5 min |
Part total: ~8,264 words · read ~41 min · study ~102 min
| Section | Words | Read | Study |
|---|---|---|---|
| 29. Adversary Frameworks — The Maps You Think With | 638 | 3 min | 8 min |
| 30. Reconnaissance and Initial Access | 450 | 2 min | 5 min |
| 31. Execution, Persistence, and Living-off-the-Land | 583 | 3 min | 8 min |
| 32. Privilege Escalation and Credential Access | 314 | 2 min | 5 min |
| 33. Active Directory and Kerberos Attacks 🔥 | 739 | 4 min | 10 min |
| 34. Lateral Movement | 251 | 1 min | 2 min |
| 35. Command & Control and Exfiltration | 374 | 2 min | 5 min |
| 36. Windows Internals and Telemetry — The Detailed Event ID Reference 🔥 | 1,593 | 8 min | 20 min |
| 37. Linux and Cloud Attack Surfaces | 444 | 2 min | 5 min |
| 38. Web Application Attacks (Deep) | 569 | 3 min | 8 min |
| 39. Detection Engineering | 480 | 2 min | 5 min |
| 40. Threat Hunting Methodology | 357 | 2 min | 5 min |
| 41. Malware Analysis Primer | 354 | 2 min | 5 min |
| 42. Advanced DFIR and Memory Forensics | 454 | 2 min | 5 min |
| 43. Threat Intelligence and Purple Teaming | 297 | 1 min | 2 min |
| 44. The Senior Analyst Mindset and Growth Path | 367 | 2 min | 5 min |
Part total: ~781 words · read ~4 min · study ~10 min
| Section | Words | Read | Study |
|---|---|---|---|
| 📅 Study & Skill-Building Plan | 424 | 2 min | 5 min |
| 📚 Resources | 168 | 1 min | 2 min |
| 🧨 A note on the tricky questions | 111 | 1 min | 2 min |
| 📜 License | 78 | 1 min | 2 min |
Grand total: ~23,896 words · full read ~119 min (2.0 h) · full study ~298 min (5.0 h)
You cannot secure, attack, or investigate what you don't understand. Security is applied networking plus applied systems knowledge. Before we touch a single control or attack, we build the mental model that everything else hangs on: the OSI model, how data actually moves, and the ports that identify services. Rush this and every later chapter will feel like memorization. Master it and the rest becomes reasoning.
The Open Systems Interconnection (OSI) model is a seven-layer conceptual framework that describes how data travels from an application on one computer, across a network, to an application on another. It was created by the ISO in 1984 so that equipment and software from different vendors could interoperate. Here's the thing to understand first: the OSI model is a teaching and troubleshooting tool, not the thing your computer literally runs. Real networks run the TCP/IP model, which is a slimmer four- (or five-) layer version. But the industry thinks, talks, and troubleshoots in OSI language — "that's a Layer 7 problem," "the load balancer works at Layer 4" — so you must know it fluently. It is also directly testable and it is the scaffold on which you'll hang firewalls, attacks, and protocols for the rest of your career.
Let's walk up the stack, from the physical wire to the human-facing application. I'll give each layer its number, its job, the protocol data unit (PDU) — the name for a chunk of data at that layer — the devices and protocols that live there, and, crucially, how attacks and defenses map to it.
This is the layer of raw bits — 1s and 0s as electrical voltage on copper, pulses of light in fiber, or radio waves in the air. There is no concept of "an address" or "a packet" here; there is only signal. The Physical layer defines connector shapes, cable types (Cat6, fiber), voltage levels, pin layouts, and radio frequencies. The PDU is the "bit."
- Devices: hubs, repeaters, cables, network interface transceivers, media converters.
- Attacks: cable tapping (splicing a fiber or copper line to eavesdrop), RF jamming of wireless, physical destruction, and simply unplugging things (a Layer 1 denial of service). Evil-maid hardware implants live here too.
- Defenses: locked wiring closets, shielded/armored cabling, tamper-evident seals, TEMPEST/shielding for high-security environments, and physical access control. 📖 If someone cuts your fiber with wire cutters, no amount of encryption or firewalling matters — that's why Layer 1 is a security layer, not just an engineering one.
Layer 2 turns the raw bit-stream into structured frames and handles delivery on the local network segment — that is, between devices that can reach each other without a router in between. Its addressing scheme is the MAC address (Media Access Control), a 48-bit hardware address burned into (or spoofed onto) each network interface, written like 00:1A:2B:3C:4D:5E. The first half of a MAC is the OUI, identifying the manufacturer. The PDU is the "frame."
Layer 2 is often split into two sublayers: LLC (Logical Link Control, which talks to the layer above) and MAC (which handles addressing and media access). Ethernet and Wi-Fi (802.11) are Layer 2 technologies. Switches operate here: a switch learns which MAC address lives on which physical port and forwards frames only to the correct port, which is why a switched network is more private than an old hub.
- Devices: switches, wireless access points, bridges, NICs.
- Protocols: Ethernet, 802.11 Wi-Fi, ARP (which straddles L2/L3), STP (Spanning Tree Protocol), VLANs (802.1Q).
- Attacks: ARP spoofing/poisoning (lying about which MAC owns an IP to become a man-in-the-middle), MAC flooding (overwhelming a switch's address table so it "fails open" and floods all traffic like a hub, enabling sniffing), MAC spoofing (impersonating another device's hardware address to bypass filtering), VLAN hopping (escaping your assigned VLAN to reach others), and rogue switches manipulating STP.
- Defenses: port security (limit MACs per switch port), DHCP snooping and Dynamic ARP Inspection, 802.1X network access control, disabling unused ports, and proper VLAN configuration.
💡 The Layer 2 insight that trips people up: MAC addresses are only meaningful within a single broadcast domain. The moment a packet crosses a router, the source and destination MAC addresses are rewritten, while the IP addresses stay the same. So the MAC you see in a capture is the last device that handed you the frame — often just your gateway — not the original sender across the internet.
Layer 3 is where routing happens — moving packets between different networks, across routers, potentially around the world. Its addressing scheme is the IP address (IPv4's 32-bit 192.168.1.10 or IPv6's 128-bit address). Unlike a MAC address, an IP address is logical and hierarchical — it encodes where on the internet you are, which is what makes global routing possible. The PDU is the "packet."
The router's entire job is to look at a packet's destination IP, consult its routing table, and forward the packet one hop closer to the destination — decrementing the TTL (Time To Live) each hop so packets can't loop forever. This is also the layer of ICMP (the diagnostic protocol behind ping and traceroute).
- Devices: routers, Layer 3 switches, and this is where basic packet-filtering firewalls make decisions.
- Protocols: IP (v4/v6), ICMP, IPsec, routing protocols (OSPF, BGP), and ARP bridges L2↔L3 here.
- Attacks: IP spoofing (forging a source address to hide or to reflect attacks), routing attacks (BGP hijacking to reroute traffic through attacker infrastructure — a real, internet-scale threat), ICMP-based reconnaissance and tunneling, fragmentation attacks, and Layer 3 DDoS.
- Defenses: router ACLs, anti-spoofing filters (BCP38/uRPF), IPsec for confidentiality/integrity, BGP security (RPKI), and segmentation.
📖 Analogy for L2 vs L3: The MAC address is like the name on an envelope inside your office — it gets a memo from your desk to the mailroom. The IP address is like the full postal address — it gets the letter across the country. Routers are the postal sorting centers; switches are the office mail carts.
Layer 4 provides end-to-end delivery between specific programs on two hosts, and it introduces the concept that dominates the rest of your security career: ports. An IP address gets you to the right computer; a port number gets you to the right service on that computer (web server on 443, mail on 25, and so on). The two great protocols here are TCP and UDP, and the difference between them is one of the most important distinctions in all of networking. The PDU is the "segment" (TCP) or "datagram" (UDP).
TCP (Transmission Control Protocol) is connection-oriented and reliable. Before any data flows, the two sides perform the three-way handshake (SYN → SYN/ACK → ACK) to agree they're both ready and to synchronize sequence numbers. Every byte is numbered; the receiver acknowledges what it got; anything lost is retransmitted; data is delivered to the application in order and without gaps. TCP also does flow control (don't overwhelm a slow receiver) and congestion control (don't overwhelm the network). This reliability costs overhead and latency. Web (HTTP/S), email, SSH, and file transfer use TCP because correctness matters more than speed.
UDP (User Datagram Protocol) is connectionless and unreliable — "fire and forget." No handshake, no acknowledgments, no retransmission, no ordering. It just sends datagrams and hopes they arrive. This makes it fast and lightweight, which is exactly what you want for DNS lookups (one small question, one small answer), live video/voice (a lost frame is better than a late one), gaming, and — importantly for security — broadcast and multicast traffic, which TCP can't do because a handshake requires exactly one peer.
- Devices/functions: stateful firewalls and Layer 4 load balancers operate here, tracking connections by IP:port pairs.
- Attacks: port scanning (mapping which services are open — the reconnaissance that precedes most attacks), SYN floods (a DoS that exhausts a server by opening half-finished handshakes), UDP floods and amplification/reflection attacks (small spoofed UDP request → huge response aimed at a victim, e.g. DNS/NTP amplification), and session hijacking by predicting sequence numbers.
- Defenses: stateful inspection, SYN cookies, rate limiting, and closing unnecessary ports (attack-surface reduction).
🧨 Tricky Question: "At which layer does a stateful firewall primarily operate?" People say Layer 3 because firewalls deal with IPs. But statefulness — tracking the state of a connection (new, established, related) — is fundamentally about the TCP/UDP session, so the classic answer is Layer 4. A next-generation firewall that inspects the actual HTTP content operates up at Layer 7. Match the answer to what the device is inspecting.
Layer 5 establishes, manages, and tears down the ongoing dialogue (session) between two applications. It handles things like setting up a session, keeping it alive, synchronizing (checkpoints so a big transfer can resume rather than restart), and closing it gracefully. In the real TCP/IP world this layer's duties are largely absorbed into the application and transport layers, which is why beginners find it fuzzy — that fuzziness is normal.
- Concepts/protocols: session setup and teardown, RPC, NetBIOS, PPTP, and authentication dialogues. Think "the conversation as a whole," not individual packets.
- Attacks: session hijacking (stealing a valid session identifier — like a web session cookie or token — to impersonate an already-authenticated user) and session fixation.
- Defenses: strong, random session tokens; binding sessions to context; session timeouts; regenerating session IDs after login; and, at the web layer, secure/HttpOnly cookies.
Layer 6 is the translator and formatter. It ensures data from the application layer of one system can be read by the application layer of another, handling character encoding (ASCII, Unicode), data serialization, compression, and — most importantly for security — encryption/decryption. This is the layer people point to when they say "TLS lives around Layer 6," because TLS presents encrypted, formatted data upward to the application. (In truth TLS spans layers, but the presentation framing is common and exam-friendly.)
- Concepts: TLS/SSL, encryption, encoding (Base64), compression, image/media formats (JPEG, etc.).
- Attacks: attacks on the encoding/encryption itself — SSL stripping (downgrading HTTPS to HTTP), downgrade attacks (forcing weak ciphers), padding-oracle attacks, and malicious deserialization when serialized objects are trusted.
- Defenses: strong TLS configuration (TLS 1.3, disable legacy versions), HSTS to prevent stripping, certificate validation, and safe deserialization practices.
Layer 7 is the layer you and your users actually touch — it's the interface between the network and the software a human uses. This does not mean "the application program" like Chrome itself; it means the protocols that applications speak: HTTP/HTTPS for web, DNS for name lookups, SMTP/IMAP/POP for email, FTP/SFTP for file transfer, SSH for remote shells, SNMP for device management, and so on. When a firewall can read the actual web request and block SQL injection in it, it's doing Layer 7 inspection.
- Devices: WAFs (Web Application Firewalls), NGFWs, application proxies, and Layer 7 load balancers.
- Attacks: the richest layer for offense — SQL injection, cross-site scripting (XSS), phishing, malware delivery, API abuse, application-layer DDoS (e.g. flooding an expensive search endpoint), and virtually all web attacks live here.
- Defenses: WAFs, input validation, secure coding, DNS filtering, email security gateways, and application allow-listing.
Bottom-to-top, the classic mnemonic is "Please Do Not Throw Sausage Pizza Away" — Physical, Data Link, Network, Transport, Session, Presentation, Application. Top-to-bottom, "All People Seem To Need Data Processing."
| # | Layer | PDU | Address / Identifier | Lives here |
|---|---|---|---|---|
| 7 | Application | Data | — | HTTP, DNS, SMTP, SSH, WAF |
| 6 | Presentation | Data | — | TLS, encryption, encoding |
| 5 | Session | Data | — | Sessions, RPC, NetBIOS |
| 4 | Transport | Segment / Datagram | Port | TCP, UDP, stateful firewall |
| 3 | Network | Packet | IP address | IP, ICMP, routers, IPsec |
| 2 | Data Link | Frame | MAC address | Ethernet, switches, ARP, VLANs |
| 1 | Physical | Bit | — | Cables, radio, hubs |
💡 Why professionals live in this model: it makes troubleshooting systematic. When something's broken, you climb the stack. No link light? Layer 1. Can't reach a device on your own subnet but the cable's fine? Suspect Layer 2 (ARP, switch, VLAN). Can ping by IP but not by name? That's DNS — Layer 7 — even though it feels like a network problem. Can reach the server's IP but the app won't load? Climb to 4 (is the port open?) and 7 (is the service healthy?). Attackers think this way too: they pick the layer where your defenses are thinnest.
🧨 Tricky Question: "A user can ping a website's IP address but the website won't load in the browser, and other sites work fine. Which layer is the most likely culprit?" The ping proves Layers 1–3 are healthy end-to-end. Other sites working suggests DNS is fine. The specific site failing to load points to Layer 7 (the web service/application itself, or its TLS at 6). The trap is choosing "Network" because it involves the network — but you already proved the network works by pinging successfully.
Because OSI is a model and not the implementation, you should also know the TCP/IP model, which is what real stacks use. It collapses the seven OSI layers into four:
| TCP/IP layer | Maps to OSI | Contains |
|---|---|---|
| Application | 5, 6, 7 | HTTP, DNS, TLS, SMTP, SSH… |
| Transport | 4 | TCP, UDP |
| Internet | 3 | IP, ICMP, IPsec |
| Link / Network Access | 1, 2 | Ethernet, Wi-Fi, ARP |
When someone says "the TCP/IP stack," this is it. The practical takeaway: OSI gives you seven precise boxes for talking and troubleshooting; TCP/IP gives you four boxes that match how the software is actually built. Know both, and know how they line up.
A port is a 16-bit number (0–65535) that identifies a specific service on a host. When your laptop opens a web page, it sends traffic to the server's IP on destination port 443 and picks a random high-numbered source port (an "ephemeral" port, typically 49152–65535) for the reply to come back to. Firewalls, IDS rules, and your own triage instincts all depend on knowing what normally lives on which port — and, just as importantly, recognizing when something is on a port it shouldn't be (malware loves to run C2 on 443 or 8080 to blend in).
Ports fall into three ranges: well-known (0–1023), assigned to core services and usually requiring admin privileges to bind; registered (1024–49151), used by vendor applications; and dynamic/ephemeral (49152–65535), used for the client side of connections. You do not need to memorize all 65,536 — but the following are the ones that appear constantly on exams and in real analysis. I've grouped them by function so they stick as a story rather than a random list, and flagged the insecure→secure pairs, which are a guaranteed exam theme.
- 80/TCP — HTTP. Unencrypted web. Anything sensitive here is a finding. Its presence where you expected HTTPS is a downgrade risk.
- 443/TCP — HTTPS (HTTP over TLS). Encrypted web. Also the port most abused by malware C2 precisely because it's almost never blocked.
- 8080/TCP, 8443/TCP — common alternate HTTP/HTTPS ports (proxies, dev servers, admin consoles). Frequently seen in attacks and misconfigurations.
- 22/TCP — SSH (Secure Shell). Encrypted remote command line and the secure transport under SFTP and SCP. The secure replacement for Telnet. Exposed SSH is a brute-force magnet.
- 23/TCP — Telnet. Remote shell in plaintext — credentials and commands travel unencrypted. Considered obsolete/insecure; finding it open is a serious issue. Telnet(23) → SSH(22) is the canonical insecure→secure swap.
- 3389/TCP — RDP (Remote Desktop Protocol). Windows graphical remote access. One of the top ransomware entry points on the internet; should never be exposed directly — put it behind a VPN and NLA.
- 5985/5986 — WinRM (HTTP/HTTPS). Windows Remote Management/PowerShell Remoting. Heavily used for legitimate admin and lateral movement.
- 5900/TCP — VNC. Cross-platform remote desktop, often weakly authenticated.
- 20/21/TCP — FTP. File Transfer Protocol; 21 is control, 20 is data. Plaintext credentials. Insecure.
- 22/TCP — SFTP (SSH File Transfer Protocol) — file transfer tunneled inside SSH. The secure replacement for FTP in most shops.
- 989/990/TCP — FTPS — FTP wrapped in TLS (a different approach to securing FTP than SFTP; know that SFTP≠FTPS).
- 69/UDP — TFTP (Trivial FTP). Tiny, no authentication; used for network booting and device configs. Abused to move payloads.
- 445/TCP — SMB (Server Message Block). Windows file/printer sharing. Enormously important for security: the vehicle for WannaCry/EternalBlue, for lateral movement (PsExec, admin shares like C$/ADMIN$), and for credential-relay attacks. Exposed 445 to the internet is a cardinal sin.
- 137/138/139 — NetBIOS (name/datagram/session). Legacy Windows networking; 137/139 and LLMNR/NBT-NS are abused for credential poisoning on LANs.
- 25/TCP — SMTP. Sends/relays mail between servers. Plaintext by default; also abused for spam relay.
- 587/TCP — SMTP submission (with STARTTLS) — the modern port for clients to submit outgoing mail with encryption.
- 465/TCP — SMTPS — SMTP over implicit TLS.
- 110/TCP — POP3 / 995/TCP — POP3S — retrieve mail (download-and-delete model); 995 is the TLS-secured version.
- 143/TCP — IMAP / 993/TCP — IMAPS — retrieve mail (server-side folders/sync); 993 is the TLS-secured version.
- 53/UDP and 53/TCP — DNS. Resolves names to IPs. UDP for normal quick lookups; TCP for zone transfers and responses too large for UDP. DNS is a top exfiltration and C2 channel — watch it closely. Secure variants: DNSSEC (integrity of records), DoT (853/TCP) and DoH (443/TCP) (encrypted DNS).
- 67/68/UDP — DHCP. Assigns IP addresses. Server 67, client 68 (remember: the higher-numbered port is the client asking). Rogue DHCP servers can redirect a whole subnet.
- 123/UDP — NTP. Network Time Protocol. Accurate time is security-critical (logs, Kerberos, certificates all depend on it) and NTP is an amplification-DDoS vector.
- 161/162/UDP — SNMP. Device monitoring/management; 161 queries, 162 traps. v1/v2c send community strings in plaintext (often left as "public"/"private"); SNMPv3 adds authentication and encryption — the secure choice.
- 389/TCP — LDAP / 636/TCP — LDAPS. Directory queries (Active Directory speaks LDAP). 389 is plaintext; 636 is TLS-secured.
- 88/TCP+UDP — Kerberos. The authentication protocol at the heart of Active Directory (tickets, TGTs). Central to Kerberoasting and Golden/Silver Ticket attacks (Part B).
- 1433/TCP — Microsoft SQL Server, 3306/TCP — MySQL/MariaDB, 5432/TCP — PostgreSQL, 1521/TCP — Oracle, 27017/TCP — MongoDB, 6379/TCP — Redis. Databases should almost never be internet-facing; exposed database ports are classic breach findings.
- 3268/3269 — Global Catalog (LDAP/LDAPS) in Active Directory forests.
This mapping is one of the most reliably tested ideas in Security+, because half of "secure architecture" is replacing a plaintext protocol with its encrypted equivalent.
| Insecure (avoid) | Port | Secure replacement | Port |
|---|---|---|---|
| Telnet | 23 | SSH | 22 |
| FTP | 20/21 | SFTP / FTPS | 22 / 989-990 |
| HTTP | 80 | HTTPS | 443 |
| SMTP (plain) | 25 | SMTP+STARTTLS / SMTPS | 587 / 465 |
| POP3 | 110 | POP3S | 995 |
| IMAP | 143 | IMAPS | 993 |
| LDAP | 389 | LDAPS | 636 |
| SNMP v1/v2c | 161 | SNMPv3 | 161 |
| DNS (plain) | 53 | DNSSEC / DoT / DoH | 53 / 853 / 443 |
🧨 Tricky Question patterns with ports. Exams love three moves. (1) The port-number swap: "Which port does IMAP over SSL use?" — the trap is 143 (plain IMAP); the answer is 993. Know the secure port, not just the base one. (2) TCP vs UDP: "DHCP uses which ports?" — 67 and 68, over UDP (not TCP). DNS is the famous both-TCP-and-UDP case. (3) The near-neighbor: 636 (LDAPS) vs 389 (LDAP), or 990 (FTPS) vs 989 — they bank on you fuzzing the digits. Slow down and picture the pair.
💡 The analyst's real use of ports: the value isn't reciting them — it's pattern-matching anomalies. Encrypted traffic on 4444 (a Metasploit default) or 8443? Suspicious. Outbound 445 to the internet? Almost certainly bad. 53 carrying oddly large, high-volume, hex-looking subdomains? DNS tunneling. A workstation suddenly listening on a high port and receiving inbound connections? Possible backdoor. You learn the norms so the abnormal jumps out.
Exam facts you should internalize before we start. The SY0-701 exam is up to 90 questions in 90 minutes, with a passing score of 750 out of 900 (note: it's a scaled score, not a straight percentage — you cannot simply calculate "X correct = pass"). It mixes standard multiple-choice with performance-based questions (PBQs) — interactive simulations that usually appear in the first few questions and are worth more. Most successful candidates skip the PBQs on first pass, clear the multiple-choice quickly, then return to the PBQs with the bulk of their remaining time. The five domains and their weights are: General Security Concepts 12%, Threats/Vulnerabilities/Mitigations 22%, Security Architecture 18%, Security Operations 28%, Security Program Management 20%. Domain 4 (Operations) is both the largest slice and the most PBQ-heavy, so it deserves the most study time even though we cover the domains in learning order below. Always verify the current exam version at CompTIA.org before you register.
Twelve percent sounds small, so people speed through this domain. That's a mistake. Domain 1 is the vocabulary and reasoning framework for the entire exam — if you can't instantly classify a control or reason about a cryptographic requirement, you'll bleed points on questions that live in other domains. Spend real time here; it pays compound interest.
Every decision in security ultimately serves one of three goals, known as the CIA triad. This is not filler — it's the lens through which you'll justify every control you ever recommend.
Confidentiality means information is accessible only to those authorized to see it. When you encrypt a laptop's disk, require a password, or lock a filing cabinet, you're protecting confidentiality. It is violated by data breaches, eavesdropping, shoulder surfing, and stolen credentials. The primary tools are encryption, access controls, and authentication.
Integrity means information is accurate, complete, and unaltered except by authorized parties. When you verify a downloaded file's hash matches the publisher's, you're checking integrity. It is violated by tampering, man-in-the-middle modification, and corruption. The primary tools are hashing, digital signatures, and checksums. 📖 A useful way to feel the difference: confidentiality is a sealed envelope no one can read; integrity is a tamper-evident seal that reveals if anyone opened it. You can have one without the other.
Availability means information and systems are accessible when legitimately needed. When you build redundant servers, keep backups, and deploy DDoS protection, you're protecting availability. It is violated by denial-of-service attacks, ransomware, hardware failure, and outages. The primary tools are redundancy, backups, fault tolerance, and capacity planning.
Two further principles round this out. Non-repudiation ensures someone cannot credibly deny having performed an action — it's provided by digital signatures (which cryptographically bind an action to a private key only one person holds) and thorough audit logs. Notice the subtle but exam-critical distinction: integrity proves data wasn't changed, while non-repudiation proves who did something and that they can't disown it. And AAA — Authentication, Authorization, and Accounting — is the operational trio we'll detail in section 3.
💡 The mirror image — the DAD triad. Attackers pursue the opposite of CIA: Disclosure (breaking confidentiality), Alteration (breaking integrity), and Denial/Destruction (breaking availability). When you assess a threat, ask "which leg of CIA does this attack, and how badly?" That instantly frames impact and the right control.
🧨 Tricky Question: "A company hashes all its log files hourly and stores the hashes separately. Which security goal is this primarily supporting?" The tempting answer is confidentiality because "security = hiding data." But hashing doesn't hide anything — it detects change. This is integrity (and it supports non-repudiation of the logs). Confidentiality would require encryption, not hashing. Always ask what the control actually does, not what it vaguely feels like.
A security control is any measure that reduces risk. CompTIA classifies controls along two independent axes, and questions frequently ask you to place a control on both — so learn them as a pair, not a single list.
The first axis is category — the nature or domain of the control:
A technical control (sometimes called a logical control) is implemented through technology: firewalls, encryption, intrusion detection systems, antivirus, and multifactor authentication. If a computer enforces it, it's technical.
A managerial control (also called administrative) is a policy, process, or decision made by management to govern security: risk assessments, security policies, background checks, and the secure development lifecycle. These control how the organization behaves.
An operational control is executed by people carrying out day-to-day security work: security guards, awareness training, incident response procedures, and change management execution. The distinction from managerial is subtle — managerial decides the policy, operational carries it out through human effort.
A physical control is a real-world barrier protecting facilities and hardware: locks, fences, badges, bollards, security lighting, and access control vestibules (mantraps).
The second axis is type — what the control does in the timeline of an attack:
A preventive control stops an incident before it happens: a firewall rule blocking a port, an access control list denying entry, a locked door. A deterrent control discourages an attacker from trying — it works on the mind, not the mechanism: warning banners, visible security cameras, "Beware of Dog" signs, and audit-trail notices. A detective control identifies that an incident is occurring or occurred: intrusion detection systems, SIEM alerts, log reviews, and motion sensors. A corrective control fixes or limits damage after the fact: restoring from backup, applying a patch, quarantining an infected host. A compensating control is an alternative you deploy when the ideal control isn't feasible — for example, if you can't patch a legacy system, you might isolate it on its own VLAN and wrap it in extra monitoring; those are compensating controls for the missing patch. Finally, a directive control instructs or mandates behavior: an acceptable-use policy, a sign reading "Authorized Personnel Only," or a rule requiring VPN use.
🧨 Tricky Question: "An organization installs bollards outside its data center entrance. Classify this control." Bollards are physical (category) and, because they physically stop a vehicle from ramming the building, preventive (type). The trap answers offer "deterrent" — bollards do deter, but their primary designed function is to physically prevent vehicle intrusion, and CompTIA usually wants the primary function. Read whether the question asks for "best" or "all that apply."
📖 Worked mapping to make it concrete. Encrypting a database: technical + preventive (it prevents unauthorized reading). A monthly access review that catches an over-privileged account: managerial (it's a governance process) + detective (it finds the problem). Restoring files after ransomware: operational/technical + corrective. Putting a legacy medical device on an isolated segment because you can't patch it: technical + compensating. Practice classifying every control you meet on both axes until it's automatic — PBQs literally make you drag controls into category/type buckets.
The three verbs that govern access are Authentication, Authorization, and Accounting — AAA. Keep them distinct because the exam deliberately blurs them. Authentication answers "are you who you claim to be?" Authorization answers "what are you allowed to do?" — and it happens after authentication. Accounting (or auditing) answers "what did you actually do?" by logging activity for later review and non-repudiation.
Authentication factors are the categories of evidence you can present to prove identity, and the exam tests them constantly:
- Something you know — a password, PIN, or the answer to a security question. Knowledge factors are the weakest because knowledge can be stolen, guessed, phished, or shared.
- Something you have — a possession: a hardware token, smart card, or your phone receiving a TOTP code or push notification. Possession factors are stronger but can be lost or, in the case of SMS codes, intercepted.
- Something you are — an inherent biometric trait: fingerprint, face, iris, or voice. Strong and convenient, but biometrics can't be changed if compromised, and they have false-accept/false-reject tradeoffs.
- Somewhere you are — location, via GPS or IP geolocation or geofencing. Often used as a conditional factor ("block logins from countries we don't operate in").
- Something you do — behavioral patterns like typing rhythm, gait, or mouse movement. Emerging and usually supplementary.
Multifactor authentication (MFA) means combining factors from two or more different categories. This "different categories" rule is the single most-tested subtlety in the whole topic.
🧨 Tricky Question: "A system requires a password and a PIN. Is this multifactor authentication?" No — and this is the classic trap. A password and a PIN are both 'something you know.' Requiring two knowledge factors is still single-factor authentication (specifically, two instances of one factor). True MFA would be a password (know) plus a phone code (have) plus optionally a fingerprint (are). Whenever you see two of the "same kind," it's not MFA.
Access control models define who gets to decide what a subject can access:
- Discretionary Access Control (DAC) — the resource's owner decides who gets access, at their discretion. Standard file permissions in Windows and Linux work this way: you own a file, you choose who can read it. Flexible but prone to error and privilege creep.
- Mandatory Access Control (MAC) — the system enforces access based on security labels and clearances, and users cannot override it. Think military classification (Confidential/Secret/Top Secret) or SELinux. Rigid and highly secure; used where the stakes justify the inflexibility.
- Role-Based Access Control (RBAC) — access is granted based on the user's job role ("Accountant," "HR Manager"), and users inherit the permissions of their role. This is the enterprise standard because it scales: change someone's role and their access follows automatically.
- Attribute-Based Access Control (ABAC) — access decisions consider multiple attributes of the user, resource, action, and context (department, device health, time of day, data sensitivity). It's the most granular and flexible, and it underpins zero-trust conditional access.
- Rule-Based Access Control — access follows predefined rules regardless of user identity, like a firewall ACL that blocks all traffic after 6 p.m. Don't confuse rule-based with role-based; the near-identical names are a deliberate trap.
Governing all of these are two foundational principles. Least privilege says every user, process, and system should have the minimum access required to do its job — nothing more — so that a compromised account can do limited damage. Separation of duties splits sensitive tasks across multiple people so no single individual can complete a fraud or abuse on their own (the person who requests a payment can't also approve it). A related idea is least privilege's cousin, "need to know," which limits access to information specifically required for one's tasks.
💡 Why least privilege is the most important idea in access control: nearly every major breach is worsened by excessive privilege. When a phished user account has admin rights it never needed, the attacker inherits those rights. Least privilege is the control that shrinks the blast radius of an inevitable compromise — which is why senior analysts obsess over it.
For decades, security followed a castle-and-moat model: build a strong perimeter (firewall), and trust everything inside it. This failed catastrophically, because once an attacker breached the perimeter — via one phished employee — they roamed freely inside the "trusted" network. Two philosophies replaced it.
Defense in depth (also called layered security) is the principle that you should never rely on a single control. Instead, you stack overlapping, diverse controls so that if one fails, others still stand. A single email might pass through a mail gateway, then the endpoint's antivirus, then application allow-listing, then network segmentation limiting where its payload can spread, then monitoring that catches the anomaly. No layer is perfect, but the combination is resilient. 📖 Think of a medieval castle: it doesn't just have a wall. It has a moat, a drawbridge, a gate, murder holes, an inner keep, and archers. Each assumes the previous might be breached.
Zero Trust goes further and attacks the very idea of a "trusted inside." Its motto is "never trust, always verify." Under zero trust, no request is trusted based on where it comes from — being "inside the network" grants you nothing. Every single access request must be authenticated, authorized, and encrypted, evaluated against policy in real time, using the identity of the user, the health of their device, and the context of the request. This is the model SY0-701 explicitly tests, based on NIST Special Publication 800-207.
Zero trust divides the world into two planes, and understanding which component lives where is exam-critical. The control plane is where decisions are made. It contains the Policy Engine (PE), which is the brain that actually decides "grant or deny" for a given request by evaluating policy and trust signals; the Policy Administrator (PA), which executes that decision by establishing or killing the connection and issuing credentials; and together they're often referred to as the Policy Decision Point (PDP). The data plane is where those decisions are enforced. Its key component is the Policy Enforcement Point (PEP) — a gatekeeper that sits directly in the path of traffic and physically allows or blocks each request according to what the control plane decided.
Around these components, zero trust emphasizes several concepts you should be able to define: adaptive identity (authentication strength that flexes with risk — a login from a new country triggers step-up verification), continuous authentication (you're re-verified throughout a session, not just once at login), least-privilege access (grant the minimum, per request), microsegmentation (isolating workloads down to the individual host or application so lateral movement is contained), threat scope reduction (shrinking what any one compromise can reach), and eliminating implicit trust zones.
🧨 Tricky Question: "In a zero-trust architecture, which component makes the access decision, and which enforces it?" The Policy Engine decides (control plane); the Policy Enforcement Point enforces (data plane). Candidates constantly swap these. Anchor it with a mental image: the Policy Engine is the judge who rules; the PEP is the bailiff who carries out the ruling at the door. The judge never touches the door; the bailiff never decides the case.
Cryptography is the mathematical machinery behind confidentiality, integrity, and non-repudiation. You don't need to do the math on the exam, but you must understand what each tool does, what problem it solves, and when to use which. We'll build it up piece by piece.
Symmetric encryption uses one shared secret key for both encryption and decryption. Because it's mathematically simple, it's fast — ideal for encrypting bulk data. Its flagship algorithm is AES (Advanced Encryption Standard, with 128/192/256-bit keys), which secures everything from your disk to your VPN. The catch — and it's a big one — is the key distribution problem: how do you get the shared secret to the other party securely in the first place? If you can already send them a secret safely, you arguably didn't need encryption. Older symmetric algorithms like DES and 3DES are deprecated (too-short keys); ChaCha20 is a modern alternative.
Asymmetric encryption (public-key cryptography) solves the distribution problem with a key pair: a public key you can share with the entire world, and a private key you guard absolutely. Data encrypted with the public key can only be decrypted with the matching private key, and vice versa. This is revolutionary — anyone can encrypt a message to you using your public key, and only you can read it. The flagship algorithms are RSA (based on the difficulty of factoring large numbers) and ECC (Elliptic Curve Cryptography, which achieves the same security with much smaller keys, so it's favored on mobile and IoT). The tradeoff is that asymmetric crypto is slow — impractical for large data.
💡 The killer insight — hybrid encryption. Real systems don't choose; they combine both to get the best of each. When you connect to an HTTPS website, your browser uses the server's public key (asymmetric) to securely exchange a freshly generated symmetric session key, and then all the actual page data is encrypted with that fast symmetric key. Asymmetric solves distribution; symmetric handles the bulk. Understanding this hybrid handshake is understanding how the secure internet works.
Hashing is a different beast entirely — it is one-way and used for integrity, not confidentiality. A hash function takes any input and produces a fixed-length digest (a fingerprint); the same input always yields the same digest, but you cannot reverse a digest back into the original. Change one bit of input and the digest changes completely. This lets you verify that data hasn't been altered: publish a file's hash, and anyone can re-hash the file to confirm it's untampered. Use SHA-256 or SHA-3 today; MD5 and SHA-1 are broken — attackers can craft collisions (two different inputs with the same hash), so recognizing them as deprecated is a common exam point. Add a secret key to a hash and you get an HMAC, which proves both integrity and authenticity (the message wasn't changed and came from someone who knows the key).
Several supporting concepts complete the picture. A salt is a random value added to a password before hashing, so that two users with the same password get different hashes — this defeats precomputed rainbow table attacks. Key stretching algorithms (bcrypt, PBKDF2, Argon2, scrypt) deliberately make hashing slow and resource-intensive, so brute-forcing millions of password guesses becomes infeasible. A nonce or initialization vector (IV) is a random value that ensures encrypting the same plaintext twice produces different ciphertext, preventing pattern analysis. Perfect Forward Secrecy (PFS), achieved with ephemeral key exchanges like ECDHE, guarantees that even if a server's long-term private key is later stolen, past recorded sessions still can't be decrypted, because each session used a unique throwaway key. And Diffie-Hellman key exchange is the clever math that lets two parties derive a shared secret over an open channel without ever transmitting the secret itself.
A digital signature deserves special attention because it combines several primitives. To sign a document, you hash it (for integrity) and then encrypt that hash with your private key (for authentication and non-repudiation). Anyone can verify the signature by decrypting it with your public key and comparing the result to their own hash of the document. If it matches, they know three things: the document wasn't altered (integrity), it genuinely came from you (authentication), and you can't deny signing it (non-repudiation).
Public Key Infrastructure (PKI) is the system of trust that makes public keys usable at scale. The problem it solves: how do you know a public key really belongs to who it claims to? PKI answers with digital certificates — documents binding a public key to an identity, vouched for by a trusted Certificate Authority (CA). The CA digitally signs the certificate, and because your browser already trusts a small set of root CAs, it transitively trusts any certificate in a valid chain: Root CA → Intermediate CA → the website's certificate. This is the chain of trust, and the root is the trust anchor. A Registration Authority (RA) verifies identity before the CA issues a certificate. When you want a certificate, you generate a Certificate Signing Request (CSR) containing your public key and identity. Certificates can be revoked before expiry (say, if a private key is stolen), and clients check revocation via a Certificate Revocation List (CRL) or the real-time Online Certificate Status Protocol (OCSP) — with OCSP stapling letting the server present its own fresh proof of validity to save a lookup. You'll also meet wildcard certificates (*.example.com, covering all subdomains), Subject Alternative Name (SAN) certificates (covering multiple specific hostnames), and key escrow (a trusted third party holds a copy of keys so encrypted data can be recovered if a key is lost).
Finally, a cluster of related protection techniques the exam groups here: steganography (hiding data inside other data, like concealing a message in the pixels of an image — hiding the very existence of the message, not just its contents), tokenization (replacing sensitive data such as a credit card number with a meaningless token that maps back to the real value only in a secure vault — heavily used for PCI compliance), data masking (showing ****-****-****-1234 instead of the full number), and homomorphic encryption (an advanced technique allowing computation on encrypted data without decrypting it). Hardware roots of trust include the TPM (Trusted Platform Module — a chip on a device's motherboard that securely stores keys and enables full-disk encryption and secure boot) and the HSM (Hardware Security Module — a dedicated, tamper-resistant appliance for generating and managing keys at enterprise scale).
🧨 Tricky Question: "You want to send a confidential message to Alice that only she can read. Whose key do you use, and is it public or private?" You encrypt with Alice's public key — because only Alice holds the matching private key to decrypt it. The trap answers suggest using your private key (that would be signing, not confidentiality) or Alice's private key (which you don't have and never should). Confidentiality → recipient's public key. Signing → sender's private key. Burn that pair of rules into memory.
Security isn't only digital — an attacker who can physically reach your hardware often wins outright. Physical controls form the outermost layer of defense in depth. These include bollards (posts that stop vehicle ramming), access control vestibules (also called mantraps — a two-door airlock where the second door won't open until the first closes, defeating tailgating), fencing, security lighting, and guards; badges and biometric readers for authentication at doors; and a family of sensors — infrared (detects body heat/motion), pressure (detects weight on a floor), microwave and ultrasonic (detect movement via reflected waves). For extreme cases, a Faraday cage blocks all radio signals (preventing wireless exfiltration or eavesdropping), and an air gap physically isolates a network from any other network, so there's literally no cable for data to escape through.
Deception and disruption technology is a clever, proactive category that SY0-701 explicitly tests. Rather than only blocking attackers, you lure them into revealing themselves. A honeypot is a decoy system deliberately made to look attractive and vulnerable; since no legitimate user has any reason to touch it, any interaction with it is almost certainly malicious — giving you high-confidence detection and a chance to study attacker behavior. A honeynet scales this up to an entire fake network. A honeyfile is a bait document (say, Executive_Salaries.xlsx) wired to alert the moment it's opened. And a honeytoken is a piece of fake data — a bogus set of credentials, a fake API key, a canary database record — planted where it should never be legitimately used; the instant it appears in a login attempt or a data dump, you know exactly where the breach came from.
🔍 Why senior defenders love honeytokens: they invert the usual false-positive problem. Most detections drown you in noise. A honeytoken produces near-zero false positives — a fake AWS access key that no real system uses has no legitimate reason to ever be used, so its use is a confirmed intrusion signal. Sprinkling honeytokens through your environment is one of the highest-signal, lowest-cost detections you can build.
It may seem odd that a security exam tests change management, but the reasoning is sound: unmanaged change is one of the biggest sources of risk and outages. An engineer who "quickly" reconfigures a firewall at 2 p.m. with no review can open a hole or break production. So security demands that changes flow through a disciplined process.
The core elements you should know: a documented approval process with a clear change owner and identified stakeholders; an impact analysis predicting what the change might affect; test results proving it works in a non-production environment first; a backout plan (how to reverse the change if it goes wrong); and a scheduled maintenance window (a low-traffic period when the change is applied, minimizing disruption). The exam also lists technical implications to weigh: updating allow/deny lists, understanding restricted activities, anticipating downtime, planning for service and application restarts, and — a big one — the risk posed by legacy applications and complex dependencies where changing one component breaks another. Every change should end with documentation updates (network diagrams, policies, procedures) and use version control so you can track exactly what changed and roll back cleanly.
🧨 Tricky Question: "During an emergency, an admin applies a critical patch to production immediately without testing or a backout plan. What is the biggest risk this introduces?" The exam wants you to recognize that skipping the backout plan means if the patch breaks production, there's no defined way to recover — potentially turning a small problem into a major outage. Even under emergency change procedures, a backout plan is the non-negotiable safety net. The "right process" answer almost always includes having a documented way to reverse course.
This is the largest pure-knowledge domain, and it answers three linked questions: Who attacks us? How do they get in? How do we stop them? Master the taxonomy here and the operational domains later will feel like applied practice.
Not all attackers are alike, and the type of adversary shapes how they operate and how you defend. The exam wants you to distinguish them by two things: their attributes (internal vs. external, how well-resourced, how sophisticated) and their motivations (why they attack).
A nation-state actor is the apex predator: government-backed, extraordinarily well-funded, patient, and sophisticated. They pursue espionage (stealing state or corporate secrets), sabotage (disrupting infrastructure), and geopolitical advantage. Their operations are the archetype of the Advanced Persistent Threat (APT) — "advanced" in capability, "persistent" in that they establish long-term, stealthy footholds and pursue objectives over months or years. Organized crime groups are highly capable and well-resourced but driven almost purely by financial gain — ransomware, banking fraud, and data theft for resale. Hacktivists are motivated by ideology or political messaging; they favor website defacements, data leaks, and DDoS to make a statement, and their skill varies widely. An insider threat is uniquely dangerous not because of skill but because they already have legitimate access — a disgruntled or bribed employee, or simply a negligent one; motivations range from revenge to money to carelessness. The unskilled attacker (the older term "script kiddie") uses tools others built without deeply understanding them, motivated by thrill or notoriety — low skill, but still capable of real damage with a downloaded exploit. Finally, shadow IT isn't a malicious actor at all but a risk source: employees deploying unsanctioned tools, cloud accounts, or devices for convenience, creating unmanaged, unmonitored attack surface.
🔬 A senior nuance the exam won't give you but interviewers will: "APT" really describes a behavior pattern — persistent, stealthy, objective-driven — more than a specific group. In practice you track adversaries by named clusters (APT29, FIN7, Lazarus) and, more usefully, by their TTPs mapped to MITRE ATT&CK. Attribution ("which country?") is hard, politically fraught, and rarely your job at L1/L2. Focus your energy on behavior-based detection that works regardless of who's behind the keyboard.
🧨 Tricky Question: "Which threat actor is characterized by having legitimate access and often the lowest technical barrier to causing damage?" The insider threat. The trap is picking "nation-state" because it sounds most dangerous — but the question's emphasis on legitimate access and low barrier points squarely at the insider, who doesn't need to break in because they're already inside.
Two terms people blur: your attack surface is the sum of all points where an attacker could attempt entry — every open port, every web form, every employee inbox, every third-party integration. An attack vector is the specific path or method used for a given attack. Good security reduces the attack surface (close unused ports, decommission old systems) and hardens the remaining vectors.
Common attack vectors include message-based vectors (email being the dominant one, plus SMS and instant messaging), image- and file-based vectors (a malicious document or a crafted image that exploits a parser), voice calls (vishing), removable media (a dropped USB stick that an employee plugs in), and unsecured networks (open Wi-Fi, exposed wired ports, vulnerable Bluetooth). Then there are the configuration-level vectors that show up constantly in real breaches: default credentials left unchanged on devices, open service ports exposing services to the internet, and the supply chain — compromising a trusted vendor, managed service provider, or software dependency to reach the real target.
The exam also enumerates vulnerability types you should recognize. Application vulnerabilities include memory injection and buffer overflows (writing past a buffer's boundary to corrupt memory and hijack execution), race conditions — specifically TOCTOU (time-of-check to time-of-use), where a resource changes between when it's validated and when it's used — and malicious updates. There are operating-system vulnerabilities; web vulnerabilities like SQL injection and XSS (covered in depth in Part B); hardware vulnerabilities including firmware flaws and end-of-life/legacy systems that no longer receive patches; virtualization vulnerabilities like VM escape (breaking out of a guest VM to attack the hypervisor or other guests) and resource reuse leakage; cloud-specific and supply-chain vulnerabilities; cryptographic weaknesses (weak ciphers or flawed implementations); plain misconfiguration (the most common root cause of cloud breaches); mobile issues like sideloading and jailbreaking; and the zero-day — a vulnerability for which no patch yet exists because the vendor doesn't know about it, making it especially prized by sophisticated attackers.
Technology can be hardened, but humans remain manipulable — which is why social engineering, the art of tricking people into compromising security, is behind a huge share of real breaches. Understanding these attacks and their psychological levers is essential.
Phishing is the fraudulent mass email designed to steal credentials or deliver malware, typically by impersonating a trusted brand and creating urgency ("Your account will be closed!"). Spear phishing is targeted — customized to a specific individual or organization using researched details, making it far more convincing. Whaling is spear phishing aimed at a "big fish" — a CEO, CFO, or other high-value executive. Vishing (voice phishing) uses phone calls, often impersonating IT support or a bank. Smishing uses SMS text messages. Pretexting is the fabricated backstory an attacker uses to build credibility ("I'm from the vendor's support team, we detected an issue..."). Business Email Compromise (BEC) impersonates an executive or vendor — frequently to redirect a wire transfer or change payment details — and is one of the costliest attacks by dollar losses. Pharming redirects victims from a legitimate site to a fake one by poisoning DNS or a hosts file, so even a correctly typed URL leads to the attacker. A watering hole attack compromises a website the target group is known to frequent, infecting them when they visit. Typosquatting registers lookalike domains (gooogle.com, micros0ft.com) to catch mistyped URLs or fool inattentive readers. Impersonation and identity fraud involve pretending to be someone else entirely. Tailgating (or piggybacking) is physically following an authorized person through a secure door. Dumpster diving recovers sensitive information from discarded trash, and shoulder surfing is simply watching someone type a password or read a screen.
What makes all of this work is a set of psychological principles of influence you should be able to name: authority (people obey perceived authority figures — "This is the CEO"), intimidation (threats and pressure), consensus / social proof ("everyone else has already done this"), scarcity ("only 3 left!"), urgency ("act in the next 10 minutes"), familiarity / liking (we trust people we like or feel we know), and trust built through pretexting. The exam also treats misinformation and disinformation as a named vector — deliberately false narratives used to manipulate.
🔍 The detection and defense angle: phishing leaves technical fingerprints — lookalike sender domains, mismatched Reply-To addresses, urgent or threatening language, and credential-harvesting links that don't match the displayed text. The operational defenses are email authentication (SPF, DKIM, DMARC) to verify sender legitimacy, secure email gateways with URL detonation, user reporting buttons, and — crucially — security awareness training with simulated phishing campaigns so employees become sensors rather than victims.
🧨 Tricky Question: "An attacker calls an employee pretending to be from the help desk, says there's an urgent security issue, and asks for their password to 'fix' it. Name the specific attack and the primary principle of influence." The attack is vishing (it's over the phone), built on a pretext (the fake help-desk story), and it leans primarily on authority and urgency. The trap is answering just "social engineering" — the exam wants the specific technique. And if the question stresses the phone channel, don't answer "phishing" (which implies email).
Malware (malicious software) comes in families defined by behavior, and the exam tests your ability to distinguish them by their defining characteristic. Learn each one's unique trait, because that's what questions hinge on.
A virus attaches itself to a legitimate file or program and requires a user to execute the host file to activate and spread — its defining trait is that it needs both a host and human action. A worm is far more dangerous because it is self-replicating and spreads across networks entirely on its own, needing no host file and no user interaction — this autonomy is why worms like WannaCry spread globally in hours. A Trojan disguises itself as legitimate, desirable software to trick the user into installing it; the deception is the delivery mechanism. A Remote Access Trojan (RAT) is a Trojan that specifically grants the attacker ongoing remote control of the victim's machine — a persistent backdoor. Ransomware encrypts the victim's files and demands payment for the decryption key; modern variants add double extortion, also stealing the data and threatening to leak it, so backups alone aren't a complete defense. Spyware covertly gathers information about the user, and a keylogger is spyware that specifically records keystrokes to capture passwords and messages. A rootkit is defined by stealth: it embeds deep in the system (often at the kernel or boot level) to hide its presence and that of other malware, making it extremely hard to detect and remove; a bootkit is a rootkit that infects the boot process itself, surviving even OS reinstalls. A logic bomb lies dormant until a specific condition triggers it — a date, an event, or the deletion of an employee's account (a classic insider-planted payload). A backdoor is any method that bypasses normal authentication to provide covert re-entry. Fileless malware is a modern, evasive category that runs entirely in memory using legitimate tools like PowerShell and WMI, leaving no file on disk for antivirus to scan (we go deep on this in Part B). A botnet is a network of compromised machines ("bots" or "zombies") controlled by an attacker for DDoS, spam, or mining, and a cryptominer hijacks a victim's CPU/GPU to mine cryptocurrency, draining resources.
The exam also lists indicators of malicious activity — the symptoms that should raise your suspicion: account lockouts, impossible travel (logins from two distant locations in an impossible timeframe), concurrent session usage, unusually high resource consumption, blocked content or inaccessible resources, out-of-cycle logging, published or leaked data appearing publicly, missing logs (attackers delete their tracks), and documented attacks in threat intel that match what you're seeing.
🔬 The reality beyond the taxonomy: the "virus vs. worm" categories are somewhat exam-era framing. Modern intrusions are multi-stage chains: a phishing email delivers a dropper or loader (a small first-stage program), which pulls down a payload (say, a Cobalt Strike beacon), which establishes C2, enables lateral movement, and ultimately deploys ransomware. Real malware is modular and staged. Part B walks this modern chain end to end.
🧨 Tricky Question: "Malware spreads across an organization's network overnight without anyone opening a file or clicking anything. Which type is it?" A worm — the defining clue is autonomous, self-propagating spread with no user action. The trap is "virus," but a virus requires a user to execute the infected host file. "No user interaction + self-spreading over the network" = worm, every time.
Beyond malware, attackers exploit weaknesses in applications, credentials, and network protocols. We'll survey them here at exam depth and go far deeper in Part B.
Application attacks center on feeding a program input it doesn't safely handle. Injection attacks insert malicious code into an input that the application then executes — SQL injection manipulates database queries, command injection runs OS commands, and LDAP injection targets directory queries. Cross-site scripting (XSS) injects malicious script into web pages viewed by other users (stored, reflected, or DOM-based). Cross-site request forgery (CSRF) tricks a logged-in user's browser into making an unwanted authenticated request. Buffer overflows and integer overflows corrupt memory to hijack execution. Privilege escalation comes in two flavors: vertical (a normal user gains admin/root) and horizontal (a user accesses another user's data at the same privilege level). A replay attack captures valid data (like an authentication token) and re-sends it to impersonate the original. Session hijacking steals an active session identifier to take over an authenticated session. Server-side request forgery (SSRF) tricks a server into making requests to internal resources on the attacker's behalf. Directory traversal uses ../ sequences to escape a web root and read arbitrary files. And race conditions / TOCTOU exploit timing gaps between validation and use.
Password attacks deserve their own attention because credentials are the perennial weak point. Brute force tries every possible combination. A dictionary attack tries likely words and common passwords. Password spraying is the clever inverse of brute force: instead of many passwords against one account (which triggers lockouts), it tries one common password against many accounts — staying under lockout thresholds and often succeeding because someone always uses "Winter2024!". Credential stuffing takes username/password pairs leaked from one breach and tries them everywhere, exploiting password reuse. Rainbow tables use precomputed hash lookups to reverse unsalted password hashes (which is exactly why salting exists).
Network attacks target the protocols themselves. An on-path attack (the modern term for man-in-the-middle) positions the attacker between two parties to intercept or alter traffic. DNS poisoning corrupts DNS responses to redirect victims to malicious sites. ARP poisoning (Layer 2) lies about MAC-to-IP mappings to become an on-path attacker on a local network. DDoS (Distributed Denial of Service) overwhelms a target from many sources, in volumetric (raw bandwidth), protocol (exhausting connection state, like SYN floods), or application-layer (hammering expensive app functions) forms. Amplification/reflection attacks abuse protocols like DNS and NTP, sending small spoofed requests that generate huge responses aimed at a victim. Wireless-specific attacks include the rogue access point and evil twin (a malicious AP impersonating a legitimate one to harvest credentials), deauthentication attacks (forcing clients off a network), VLAN hopping, and MAC flooding. Cryptographic attacks include the downgrade attack (forcing a connection to use a weaker, breakable protocol), collision attacks (finding two inputs with the same hash), and the birthday attack (a probability-based method of finding hash collisions).
🧨 Tricky Question: "An attacker tries the single password 'Password123' against 500 different user accounts, one attempt each. What attack is this, and why does it evade account lockout?" This is password spraying. It evades lockout because lockout policies count failed attempts per account — by trying only one password per account, the attacker never triggers any single account's threshold, while still statistically likely to crack a few weak-password users across the 500. The trap is "brute force," but brute force hammers one account with many guesses and would trigger lockout.
Knowing attacks is only half the job; the exam constantly asks "how do you prevent or reduce this?" Here are the mitigation techniques you must be able to select as answers, each with the threat it addresses. Segmentation divides the network to contain breaches and stop lateral movement, shrinking the blast radius. Access control (ACLs and permissions, grounded in least privilege) prevents unauthorized access. Application allow-listing (permitting only approved executables to run) blocks unknown and malicious programs — far stronger than blocklisting. Isolation and quarantine contain an infected host so it can't spread. Patching closes known vulnerabilities before they're exploited. Encryption protects data confidentiality even if it's stolen. Monitoring reduces attacker dwell time by detecting intrusions faster. Configuration enforcement prevents drift from a secure baseline. Decommissioning removes risky end-of-life systems. And hardening — disabling unnecessary ports and services, changing default credentials, deploying endpoint protection (EDR) and host firewalls — systematically shrinks the attack surface of every device.
💡 The framing that makes mitigations click: think in terms of prevent, detect, and limit. Some controls prevent the attack (patching, allow-listing, access control). Some detect it faster (monitoring, honeytokens). Some limit the damage when prevention inevitably fails (segmentation, least privilege, isolation). Mature security assumes breach and invests in all three — because no prevention is perfect, the controls that limit blast radius are often the highest-value ones.
Where Domain 2 was about what goes wrong, Domain 3 is about designing systems so less goes wrong. SY0-701 heavily expanded the cloud, hybrid, and zero-trust content here, reflecting how modern infrastructure actually looks.
Organizations run their systems across a spectrum of models, each with different security implications. On-premises means you own and control everything — and are responsible for everything. Cloud shifts infrastructure to a provider. Hybrid blends both. Serverless runs code without managing servers (you're billed per execution). Microservices break an application into small independent services. Infrastructure as Code (IaC) defines infrastructure in version-controlled configuration files, making it repeatable and auditable. Containerization (Docker) packages an app with its dependencies for portability, while virtualization runs full guest operating systems on a hypervisor. You'll also encounter IoT (internet-connected devices), ICS/SCADA (industrial control systems running physical processes — power plants, factories), and embedded/RTOS systems. Each model you evaluate on availability, resilience, cost, patch surface, and — critically — who is responsible for securing what.
That responsibility question is formalized in the Shared Responsibility Model, one of the most-tested cloud concepts. The rule of thumb: the provider secures the security of the cloud (the physical datacenter, the hypervisor, the network backbone), while you secure what you put in the cloud (your data, your configurations, your access management). How much falls to you depends on the service model. In Infrastructure as a Service (IaaS) — raw VMs like AWS EC2 — you manage the OS, applications, and data; the provider handles hardware and virtualization. In Platform as a Service (PaaS) — a managed app platform — the provider also handles the OS and runtime, leaving you responsible for your application and data. In Software as a Service (SaaS) — a finished application like Microsoft 365 — the provider manages nearly everything, and you're responsible mainly for your data and your users' access.
To secure cloud environments, a family of tools has emerged: a CASB (Cloud Access Security Broker) sits between users and cloud services to enforce security policy (visibility, DLP, threat protection); SASE (Secure Access Service Edge) delivers networking and security together as a cloud service for distributed workforces; a SWG (Secure Web Gateway) filters web traffic; and CSPM (Cloud Security Posture Management) continuously scans cloud configurations for misconfigurations and compliance drift. On the virtualization side, know the risks of VM escape (breaking out of a guest to the hypervisor), VM sprawl (unmanaged proliferation of VMs), and container escape.
Good architecture doesn't leave the network flat — a flat network lets an attacker who compromises one host reach everything. Segmentation divides the network into zones with controlled traffic between them, containing breaches. Microsegmentation takes this to the extreme, applying policy at the level of individual workloads — the enforcement mechanism behind zero trust. A DMZ (demilitarized zone) or screened subnet is an isolated segment for public-facing servers (web, mail), positioned so that even if those exposed servers are compromised, the attacker still can't directly reach the internal network.
A concept that separates junior from senior thinking is the distinction between north-south and east-west traffic. North-south traffic flows in and out of the datacenter/network boundary — the traditional focus of perimeter firewalls. East-west traffic flows laterally between internal systems (server to server, workstation to workstation). This matters enormously because lateral movement — the attacker's spread after initial compromise — is east-west, and perimeter defenses never see it. Mature organizations monitor and segment east-west traffic specifically to catch intruders moving internally.
The appliances that enforce all this: firewalls (from simple stateless packet filters, to stateful firewalls tracking connections, to next-generation firewalls (NGFW) that inspect application-layer content and integrate IPS, to web application firewalls (WAF) specialized for Layer 7 web attacks); IDS/IPS (an Intrusion Detection System alerts on malicious traffic; an Intrusion Prevention System sits inline and actively blocks it); proxies (intermediaries that can filter and log); load balancers (distributing traffic for availability); jump servers / bastion hosts (hardened gateways for administrative access into sensitive zones); and NAC (Network Access Control) using 802.1X to authenticate devices before granting network access. You should also understand failure modes: a control that fails open preserves availability but sacrifices security when it breaks, while one that fails closed preserves security by denying everything — the right choice depends on whether availability or security is paramount for that system.
A recurring theme of secure architecture is replacing plaintext protocols with encrypted equivalents — which is exactly why the ports reference in Chapter 0.3 matters so much. The pattern to internalize: for any legacy protocol that sends data (especially credentials) in the clear, there is a secure successor. Telnet → SSH. FTP → SFTP or FTPS. HTTP → HTTPS. Plain SMTP → SMTP with STARTTLS or SMTPS. POP3/IMAP → their TLS versions on 995/993. LDAP → LDAPS. SNMP v1/v2c → SNMPv3. For DNS, the successors add integrity (DNSSEC) and confidentiality (DoT/DoH). TLS 1.3 is the current standard for transport encryption — you should disable SSL and TLS 1.0/1.1 entirely as they're broken. IPsec secures network-layer traffic (the backbone of many VPNs), using AH (Authentication Header) for integrity/authentication and ESP (Encapsulating Security Payload) for confidentiality plus integrity, in either transport mode (encrypting just the payload) or tunnel mode (encrypting the entire original packet, used for site-to-site VPNs).
You can't protect data uniformly — you must know what data you have, how sensitive it is, and what state it's in. Data exists in three states, each needing different protection. Data at rest (stored on disk) is protected by encryption (full-disk or file-level). Data in transit (moving across a network) is protected by TLS or IPsec. Data in use (actively being processed in memory) is the hardest to protect and requires advanced techniques like secure enclaves or homomorphic encryption. 🧨 A common trap asks which state is hardest to protect — the answer is in use, because the data must be decrypted to be processed.
Data is also classified by sensitivity so controls can be applied proportionally: categories include public, private, sensitive, confidential, critical, and restricted, plus regulated types like PII (Personally Identifiable Information), PHI (Protected Health Information), financial data, intellectual property, and trade secrets. Data protection methods include encryption, tokenization, masking, obfuscation, and hashing, along with segmentation and permission/geographic restrictions (relevant to data sovereignty — laws requiring data stay within certain borders). Data Loss Prevention (DLP) systems detect and block sensitive data from leaving the organization, operating at the endpoint, network, and cloud. Finally, know the data roles: the data owner (accountable, usually a senior business figure), the data controller (decides why/how data is processed), the data processor (processes on the controller's behalf), and the data custodian/steward (handles day-to-day protection and storage).
Availability isn't luck — it's engineered through redundancy and planned recovery. High availability uses load balancing and clustering to keep services running through failures, plus geographic redundancy (multiple sites), NIC teaming, redundant power (UPS and generators), and dual power supplies. RAID provides disk redundancy: RAID 0 stripes for speed with no redundancy (a trap — RAID 0 gives you no fault tolerance), RAID 1 mirrors, RAID 5 stripes with distributed parity (survives one disk loss), RAID 6 survives two, and RAID 10 combines mirroring and striping for both speed and redundancy.
Backups are your last line against ransomware and disaster. Types include full (everything), incremental (only changes since the last backup of any kind — fast to back up, slower to restore), and differential (all changes since the last full backup — slower to back up, faster to restore), plus snapshots. The 3-2-1 rule is the gold standard: 3 copies of your data, on 2 different media types, with 1 stored off-site. And increasingly essential against ransomware are immutable backups — write-once copies that even an administrator (or an attacker who's stolen admin credentials) cannot alter or delete.
Recovery is measured by metrics you must know cold: RTO (Recovery Time Objective) is the maximum tolerable downtime — how fast you must be back up. RPO (Recovery Point Objective) is the maximum tolerable data loss — how far back in time you can afford to lose data, which dictates backup frequency. MTTR (Mean Time To Repair) is the average time to fix a failed component; MTBF (Mean Time Between Failures) measures reliability; and MTTD (Mean Time To Detect) measures how quickly you notice problems. Recovery capability is validated through testing: tabletop exercises (discussion-based walk-throughs), simulations, parallel processing, and full failover tests. Alternate sites come in three temperatures: a hot site is fully equipped and ready to take over immediately; a warm site has infrastructure but needs some setup; a cold site is just space and power, requiring everything to be brought in.
🧨 Tricky Question: "A business can tolerate losing at most 15 minutes of data but must be back online within 4 hours. Which metric is 15 minutes, and which is 4 hours?" The 15 minutes is the RPO (maximum data loss — it drives how often you back up), and the 4 hours is the RTO (maximum downtime — it drives your recovery infrastructure). Candidates swap these constantly. Anchor it: RPO = data (the P is for the point in time you recover to); RTO = time (downtime).
This is the largest domain and the beating heart of daily SOC and IR work — nearly a third of the exam, and the most performance-based questions. Everything here is what you'll actually do on the job, so learn it operationally, not just as definitions.
Hardening is the process of systematically reducing a system's attack surface, and it's foundational to operations. The core moves: disable unnecessary ports, services, and protocols (every running service is a potential entry point — if you don't need it, turn it off); remove or change default credentials (the number one cause of trivial compromises); and enforce least functionality (a server should do its one job and nothing else). On endpoints, deploy EDR/XDR (Endpoint/Extended Detection and Response — behavioral monitoring far beyond signature antivirus), host-based firewalls, and application allow-listing. Establish secure baselines — a documented, known-good configuration — then deploy them consistently (via Group Policy, MDM, or IaC) and maintain them against drift. Specialized environments need tailored hardening: mobile devices via MDM (Mobile Device Management) and clear BYOD/COPE/CYOD policies (Bring/Corporate-Owned/Choose Your Own Device), IoT and ICS/SCADA with network isolation, and wireless with WPA3, 802.1X/RADIUS authentication, and WPS disabled.
You cannot defend what you cannot see. Security monitoring collects telemetry from across the environment, and the central nervous system for this is the SIEM (Security Information and Event Management) platform — tools like Splunk, Microsoft Sentinel, QRadar, and Elastic. A SIEM aggregates logs from every source, correlates events across them to spot patterns no single log would reveal, generates alerts, and supports investigation, reporting, and long-term archiving for compliance. The activities of a monitoring program include log aggregation, alerting, scanning, reporting, archiving, and — a mature and underrated one — alert tuning to reduce false positives so analysts aren't drowned in noise.
The log sources you must know and learn to correlate are the raw material of the job: firewall logs, IDS/IPS alerts, endpoint/EDR telemetry, operating-system logs (Windows Event Log and Linux syslog/auditd), application logs, DNS logs (invaluable for catching C2 and tunneling), web proxy logs (where users browsed), authentication logs, VPN logs, and cloud audit logs (AWS CloudTrail, Azure Activity/Sign-in logs). Supporting tools include NetFlow/sFlow/IPFIX (flow records summarizing who talked to whom), full packet capture (Wireshark — the deepest visibility), SNMP, DLP, vulnerability scanners, and antivirus/EDR. Collection can be agent-based (software on each host, richer data) or agentless (collected remotely, easier to deploy).
🔍 The SOC alert triage loop — this is literally the L1/L2 job, so internalize it. An alert fires. You validate it (is this a true positive or a false alarm?). You scope it (what else is affected — one host or fifty?). You enrich it with context (threat intelligence on the IP/domain, the criticality of the asset, the role of the user). You then escalate to L2/L3 if it's a real incident, or close it if benign. And finally, you tune the detection so a benign pattern doesn't page you again, or so a missed detection now fires. Every day is many cycles of this loop. Doing it well — fast, accurate, well-documented — is what makes a good analyst.
Identity is the new perimeter, and managing it operationally is a huge part of security work. The lifecycle is provisioning and deprovisioning — the "joiner, mover, leaver" process of granting access when someone's hired or changes roles, and (critically) revoking it promptly when they leave, since orphaned accounts are a favorite attacker foothold. Identity proofing verifies someone is who they claim before issuing credentials.
For authentication across many systems, Single Sign-On (SSO) lets users authenticate once and access many services, implemented via several protocols you must distinguish. SAML (Security Assertion Markup Language) is the enterprise web-SSO standard, using signed XML assertions passed between an Identity Provider (IdP) and Service Provider (SP). OAuth 2.0 is an authorization framework — it lets one app access resources in another on your behalf without sharing your password (the "Sign in with Google to let this app see your calendar" flow). OIDC (OpenID Connect) adds an authentication layer on top of OAuth, providing verified identity. Kerberos is the ticket-based authentication protocol at the heart of on-premises Active Directory. Federation extends trust between organizations' identity systems. Network devices authenticate admins via RADIUS or TACACS+ — and a testable distinction is that TACACS+ separates authentication, authorization, and accounting and encrypts the entire payload, while RADIUS encrypts only the password.
Strengthening authentication, MFA is implemented through TOTP/HOTP (time- or counter-based one-time codes), push notifications, and increasingly FIDO2/WebAuthn passkeys — which are phishing-resistant because they're cryptographically bound to the legitimate site and can't be replayed on a fake one. Privileged Access Management (PAM) applies extra rigor to powerful accounts: just-in-time access (privileges granted only when needed, then revoked), password vaulting, ephemeral credentials, and session recording for accountability.
New and expanded in SY0-701, automation and orchestration address a hard truth: analysts can't manually handle the volume of modern alerts. SOAR (Security Orchestration, Automation, and Response) platforms run playbooks — predefined, automated response workflows — to handle repetitive, well-defined tasks at machine speed. Use cases include automated user provisioning, enforcing security guardrails and baselines, managing security groups, automated ticket creation and escalation, enabling/disabling services, securing CI/CD pipelines, and integrating tools via APIs. The benefits are compelling: efficiency and time savings, enforced consistency and baselines, secure scaling, faster reaction times, and freeing skilled analysts from drudgery (a "workforce multiplier" that also helps retention). But weigh the considerations: complexity, cost, the risk of a single point of failure, accumulating technical debt, and ongoing maintenance burden.
🔍 A concrete playbook to make SOAR real: a user reports a phishing email. The playbook automatically extracts the indicators (sender, URLs, attachment hashes), detonates the URL and attachment in a sandbox, checks reputation against threat intel, and if malicious, quarantines that email across every mailbox in the tenant, blocks the sender domain at the mail gateway and proxy, invalidates the sessions of anyone who clicked, and opens a ticket with the full context — all in seconds. What would take an analyst an hour happens before they've finished their coffee.
This is the single most important operational framework on the exam and in the job — know the phases cold, in order. When an incident hits, panic is the enemy; a rehearsed process is your lifeline. CompTIA follows the NIST-aligned lifecycle, often memorized as PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons learned).
Preparation happens before any incident — building the IR plan, assembling and training the team, deploying tools, establishing communication channels, and creating baselines so you know what "normal" looks like. This phase determines whether the others succeed. Identification (Detection & Analysis) is recognizing and validating that a real incident is occurring — triaging alerts, correlating indicators, and confirming it's not a false positive. Containment stops the bleeding: limiting the incident's spread before it worsens. It has a short-term aspect (immediately isolate the infected host — pull it off the network) and a long-term aspect (apply temporary fixes to keep operating while you prepare a clean rebuild). Eradication removes the threat entirely — deleting malware, closing the exploited vulnerability, disabling compromised accounts, removing attacker persistence. Recovery restores systems to normal production and carefully monitors to ensure the threat is truly gone and doesn't return. Lessons Learned is the post-incident review: what happened, how you responded, what worked, what didn't, and how to improve — feeding directly back into Preparation.
Supporting concepts round out the domain: the IR plan, playbooks, and runbooks (documented procedures); training, tabletop exercises, and simulations to rehearse; RACI matrices clarifying who's Responsible, Accountable, Consulted, and Informed; root cause analysis to find the true origin; a communication and escalation plan; and — a subtle but vital point — out-of-band communication, meaning you don't coordinate the response over the very email or chat system that may be compromised. Attackers watching your inbox learn your every move; use a separate channel.
When an incident may lead to legal action — or when you simply need to understand exactly what happened — digital forensics governs how you collect and handle evidence so it's accurate and admissible. The foundational rule is the order of volatility: collect evidence in order from most volatile (disappears fastest) to least, because the fleeting stuff is gone the moment you power down or wait too long.
The order, most to least volatile: (1) CPU registers and cache; (2) RAM — the crown jewel, holding running processes, active network connections, decryption keys, and injected malware that exists only in memory; (3) network state — routing tables, ARP cache, active connections; (4) running processes and kernel statistics; (5) disk — files and drives; (6) remote logging and monitoring data; (7) physical configuration and network topology; and (8) archival media and backups. 🔍 The practical consequence is profound: on a live compromised machine, capturing RAM before pulling the plug can be the difference between recovering an attacker's encryption keys, in-memory malware, and live C2 connections — versus losing all of it forever. This is why order of volatility exists and why "pull the plug immediately" is often the wrong first move.
The principles of sound forensics: maintain an unbroken chain of custody — meticulously documenting who handled each piece of evidence, when, where, and why, because any gap can render evidence inadmissible. Honor a legal hold (preserving relevant data once litigation is anticipated) and support e-discovery. For acquisition, create a bit-for-bit forensic image (never work on the original), use a write blocker when imaging disks so you can't accidentally alter them, and hash both the original and the copy (SHA-256) to prove they're identical and unaltered. Uphold provenance (where evidence came from), preservation, non-repudiation, and admissibility. Reporting must be factual, reproducible, and defensible.
Finally, operations includes the continuous cycle of vulnerability management: identify → analyze → prioritize → remediate → validate → report → repeat. You identify vulnerabilities through scanning (which can be credentialed — logging in for a deep, accurate view — or non-credentialed — an outside-in perspective), penetration testing, bug bounty programs, threat intelligence feeds, and OSINT. Application-specific scanning includes SAST (Static Application Security Testing — analyzing source code), DAST (Dynamic — testing the running app), and SCA (Software Composition Analysis — auditing third-party dependencies for known-vulnerable components). You analyze findings using the CVE (the unique identifier for a specific known vulnerability), the CVSS score (0–10 severity rating), and the CWE (weakness classification), while filtering out false positives and hunting for dangerous false negatives. You prioritize by combining severity with asset criticality, exploitability, and exposure (is it internet-facing?). You respond by patching, applying compensating controls, or formally accepting the risk via exceptions/exemptions. You validate by rescanning, and you report to stakeholders.
🔬 A senior reality that separates real practitioners from checkbox-fillers: CVSS score alone is a poor way to prioritize. A "critical" CVSS 9.8 on an internal test server with no network path matters far less than a "high" on an internet-facing app that's being actively exploited in the wild. Mature teams enrich CVSS with EPSS (Exploit Prediction Scoring System — likelihood of exploitation) and CISA's KEV catalog (Known Exploited Vulnerabilities — things attackers are actually using right now), plus asset value and exposure. Patch what attackers are exploiting on your exposed, valuable assets first — don't blindly chase every "critical."
The final domain zooms out from technology to the business and governance layer — how organizations manage security as a program. It grew from 14% to 20% in SY0-701, reflecting employers' demand for professionals who understand risk and compliance, not just tools. It's less technical, but dense with testable terminology, so learn the vocabulary precisely.
Governance is the system by which an organization directs and controls its security. It's expressed through a hierarchy of documents you should distinguish: policies are high-level statements of intent (an Acceptable Use Policy, an Information Security Policy, a Business Continuity Policy); standards are mandatory specific requirements (a password standard mandating length and complexity); procedures are step-by-step instructions for a task; and guidelines are recommended (not mandatory) best practices. Governance structures include boards, committees, and regulatory oversight, and organizations choose centralized (one authority) or decentralized governance models.
Risk management is the disciplined process of identifying, assessing, and treating risk, and it comes with a precise vocabulary. Risk assessments can be ad hoc, recurring, one-time, or continuous. You maintain a risk register cataloging each risk, its owner, and its status. Assessment can be qualitative (ranking risks subjectively as High/Medium/Low by likelihood and impact) or quantitative (assigning actual monetary values). The quantitative formulas are testable, so learn them: the Single Loss Expectancy (SLE) = Asset Value × Exposure Factor (the EF being the percentage of the asset lost in one incident), and the Annualized Loss Expectancy (ALE) = SLE × Annualized Rate of Occurrence (ARO) (how many times per year you expect it). 📖 Example: a $200,000 asset with a 25% exposure factor gives an SLE of $50,000. If you expect the event twice a year (ARO = 2), the ALE is $100,000. Now you can rationally decide: a control costing $60,000/year that eliminates this risk is clearly worth it; one costing $150,000/year is not. This is how security spending gets justified to a CFO.
Every organization defines its risk appetite and risk tolerance — how much risk it's willing to accept in pursuit of its goals — and tracks Key Risk Indicators (KRIs). When you've assessed a risk, you choose a risk treatment: mitigate (reduce it with controls), transfer (shift it to someone else, e.g., cyber insurance or outsourcing), accept (acknowledge and live with it, formally documented), or avoid (stop doing the risky activity altogether). A Business Impact Analysis (BIA) identifies the organization's critical functions and the impact of their disruption, which in turn drives the recovery metrics (RTO, RPO, MTTR) from Domain 3.
🧨 Tricky Question: "A company buys cyber-insurance to cover potential breach costs. Which risk treatment is this?" This is risk transfer — you're shifting the financial impact to the insurer. The trap is "mitigate," but insurance doesn't reduce the likelihood or the breach itself; it transfers the financial consequence. Mitigation would be deploying controls that make the breach less likely or less damaging.
SY0-701 substantially expanded this area because vendors have become a top breach vector — SolarWinds, MOVEit, and Kaseya all showed how compromising one supplier cascades to thousands of victims. You must assess third parties before and during a relationship: through penetration testing, a right-to-audit clause in the contract, reviewing their independent audit reports, supply-chain analysis, and security questionnaires. You should even consider fourth-party risk — your vendors' vendors.
These relationships are governed by agreements whose acronyms are heavily tested: an SLA (Service Level Agreement) defines guaranteed service levels and penalties; an MOU (Memorandum of Understanding) or MOA (Memorandum of Agreement) documents intentions between parties (an MOU is typically less formal/binding than an MOA); an MSA (Master Service Agreement) sets overarching terms for an ongoing relationship, with specific work defined in a SOW (Statement of Work); an NDA (Non-Disclosure Agreement) protects confidential information; a BPA (Business Partners Agreement) governs a partnership; and an ISA (Interconnection Security Agreement) specifies the security requirements for connecting two organizations' systems.
The last pieces are the human program and the verification of it all. A security awareness program turns employees from the weakest link into a sensor network. It includes phishing simulations and campaigns, training to recognize anomalous behavior (risky, unexpected, or unintentional actions), and guidance on policies, insider threats, password hygiene, social engineering, operational security, and the risks of hybrid/remote work — with ongoing reporting, monitoring, and program development.
Audits and assessments verify that controls actually work. They can be internal (self-assessments, internal audit committees) or external (regulatory examinations, independent third-party audits, and formal attestation). Penetration testing is a specialized assessment that actively attempts to breach systems, conducted with varying knowledge levels: known environment (white-box) where the tester has full information, unknown environment (black-box) simulating an outside attacker with no inside knowledge, and partially known (gray-box) in between. Pen tests begin with reconnaissance (which can be active — directly probing — or passive — OSINT only) and operate under agreed rules of engagement.
Compliance ties it together: adherence to laws and frameworks. Know the major ones — regulations like GDPR (EU data privacy), HIPAA (US healthcare), PCI-DSS (payment cards), and SOX (financial reporting) — and frameworks like NIST CSF (the flexible Identify-Protect-Detect-Respond-Recover model), ISO 27001 (a certifiable Information Security Management System standard), CIS Controls (a prioritized list of technical safeguards), and SOC 2 (a trust report for service organizations). Non-compliance brings fines, sanctions, reputational damage, contractual penalties, and loss of licensure. And underpinning privacy law is a vocabulary: the data subject (the person the data is about), the distinction between controller and processor, and rights like the right to be forgotten (data erasure).
💡 A quick framework map to keep them straight: NIST CSF = a flexible US risk-management framework organized around five functions. ISO 27001 = an internationally certifiable management-system standard. PCI-DSS = specific mandatory rules for anyone handling payment cards. CIS Controls = a prioritized, practical checklist of technical defenses. SOC 2 = an attestation report proving a service provider handles data securely. When a question describes certifiable ISMS, think ISO 27001; payment cards, think PCI-DSS; flexible five-function model, think NIST CSF.
Security+ gave you the vocabulary and the controls. Seniority is something different in kind, not just degree. An L1 analyst closes alerts against a playbook. A senior/L3 analyst is handed a pile of ambiguous telemetry and must reconstruct what an adversary did, decide what's real, contain a live intrusion, write the detection so it never recurs, and explain it all to leadership. That demands three things this half builds: a deep model of how attackers actually operate, the ability to engineer detections rather than just consume them, and the investigative discipline to work under uncertainty.
Everything here stays defensive. For each technique you get the same three-beat structure a good mentor uses: how it works → the telemetry it leaves → how you detect and respond. No weaponization — the goal is to make you the person who catches it.
Before diving into techniques, you need the frameworks senior analysts use to organize them. Without these, alerts are just noise; with them, alerts become a story with a beginning, middle, and end.
The Lockheed Martin Cyber Kill Chain models an intrusion as a linear sequence of seven stages: Reconnaissance (researching the target), Weaponization (building the malicious payload), Delivery (getting it to the victim), Exploitation (triggering the vulnerability), Installation (establishing a foothold), Command & Control (opening a remote channel), and Actions on Objectives (achieving the goal — theft, encryption, destruction). Its power is the idea that every stage is a chance to detect and break the chain, and the earlier you break it, the less damage occurs. Its weakness is that real intrusions aren't so tidily linear — attackers loop, skip, and improvise.
That's where MITRE ATT&CK comes in — and if you learn one framework deeply, make it this one, because it's the lingua franca of the entire blue-team world. ATT&CK is a giant, living knowledge base of real-world adversary behavior, organized into Tactics, Techniques, and Procedures (TTPs). A tactic is the attacker's goal at a phase (the "why" — e.g., Persistence, Credential Access, Lateral Movement). A technique is how they achieve it (e.g., T1003 OS Credential Dumping), and sub-techniques and procedures get more specific still. The tactics run roughly in attack order: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact. Senior analysts use ATT&CK four ways: to map their detections to the matrix and find coverage gaps, to communicate incidents in a shared language everyone understands, to drive threat hunts from techniques they can't yet detect, and to consume threat intelligence (which is written in ATT&CK terms — "this actor uses T1566.001 for initial access, then T1059.001 for execution").
The Pyramid of Pain is the concept that reorients your whole detection strategy from junior to senior. It ranks indicators by how much pain it causes the attacker when you detect and block them. At the bottom — trivial for attackers to change — are hash values (recompile and the hash changes), then IP addresses (rotate infrastructure in seconds), then domain names, then host and network artifacts, then tools, and at the apex, hardest of all to change: TTPs — the attacker's actual behavior. 💡 The lesson is transformative: blocking hashes and IPs is whack-a-mole — you'll never win, because the attacker changes them faster than you can enumerate them. But if you detect the behavior — "Microsoft Word spawned PowerShell, which made a network connection" or "a non-system process opened a handle to LSASS" — you force the attacker to fundamentally redesign their operation, which is expensive and slow. Invest your detection effort at the top of the pyramid. Internalizing this single idea is a genuine milestone in becoming a senior analyst.
Finally, the Diamond Model of Intrusion Analysis frames every event as four connected vertices: the Adversary, their Capability (malware/tools), their Infrastructure (domains/IPs), and the Victim. Its value is enabling pivoting: from one malicious domain you pivot to the IP it resolves to, then to other domains on that IP, then to other victims contacting them — expanding a single indicator into a full picture of a campaign. This is the core motion of both intrusion analysis and threat intelligence.
🧨 Tricky Question: "Your team currently blocks known-malicious file hashes and IP addresses. Per the Pyramid of Pain, why is this a fragile strategy, and what's more durable?" Hashes and IPs sit at the bottom of the pyramid — attackers change them trivially (recompile the binary, spin up a new server), so your blocks are obsolete almost immediately. The durable investment is detecting TTPs (behavior) at the top of the pyramid, which the attacker can't change without redesigning their entire tradecraft.
Every intrusion begins with the attacker learning about you and then getting a foot in the door. Reconnaissance splits into passive and active. Passive recon uses OSINT (Open-Source Intelligence) — mining DNS records, WHOIS data, certificate transparency logs (which publicly list every TLS certificate issued for your domains, inadvertently revealing subdomains), employee LinkedIn profiles, leaked credentials in breach dumps, GitHub repositories with hard-coded secrets, and search engines like Shodan and Censys that index internet-exposed devices. Passive recon leaves almost no trace on your systems because the attacker never touches them directly — a sobering reality that means you should assume your external footprint is already fully mapped. Active recon does touch you: port scanning, service enumeration, and vulnerability scanning, which show up as scan patterns in your network telemetry.
🔍 What you can actually detect at this stage is mostly the active portion: bursts of connection attempts across many ports (the SYN-scan pattern covered in the Wireshark guide), enumeration of your web applications, spikes in DNS NXDOMAIN responses from subdomain brute-forcing, and unusual authentication probing. Much recon is invisible, so senior analysts don't over-invest here — they focus detection on the next stage, access, which you can reliably catch.
Initial Access (Tactic TA0001) is the set of techniques for gaining that first foothold, and knowing the common vectors tells you where to concentrate detection. Phishing (T1566) — malicious links or attachments — remains the dominant vector; you detect it through email gateway analysis, URL detonation, user reports, and, on the endpoint, the tell-tale sign of an Office application spawning a child process like PowerShell. Exploiting a public-facing application (T1190) — hitting an unpatched web server, VPN, or firewall — reveals itself in web server logs, sudden error spikes, and the appearance of new files (web shells) in the web root. Using valid accounts (T1078) — logging in with credentials bought or phished — is insidious because it looks legitimate; you catch it through behavioral anomalies: impossible travel, logins from new countries or devices, off-hours access, and MFA anomalies. External remote services (T1133) like exposed RDP, VPN, or Citrix are brute-forced or accessed with stolen creds. And supply-chain compromise (T1195) delivers malicious code through trusted software updates.
🔬 A specifically modern initial-access technique worth calling out is MFA fatigue (also called push bombing). The attacker already has the victim's password (from a breach) and repeatedly triggers MFA push notifications, betting the annoyed or confused user will eventually tap "Approve" just to make it stop. You detect it as a pattern of many denied MFA prompts followed by an approval, and you mitigate it with number-matching MFA (the user must type a number shown on-screen, defeating blind approval) and phishing-resistant FIDO2 passkeys.
Once inside, the attacker must run code (Execution, TA0002), and here you meet the technique that dominates modern intrusions: T1059, Command and Scripting Interpreter — abuse of built-in interpreters, above all PowerShell, along with cmd, the Windows Script Host (wscript/cscript), bash, and Python. User Execution (T1204) — tricking the victim into running the malicious file or enabling a macro — often kicks it off. Attackers also execute via WMI (T1047), Scheduled Tasks (T1053), and Windows Services (T1569).
This leads to one of the most important concepts for a modern defender: Living-off-the-Land (LotL) and LOLBins (Living-off-the-Land Binaries). Rather than dropping custom malware that antivirus might catch, sophisticated attackers abuse legitimate, signed, built-in operating-system tools to do their dirty work — evading both signature detection and application allow-listing (because these tools are supposed to be there). The usual suspects you must recognize: powershell.exe (download and execute code, run encoded commands, operate entirely in memory), certutil.exe (ostensibly for certificates, abused to download files and decode Base64 payloads), mshta.exe (execute HTA files and embedded script), rundll32.exe and regsvr32.exe (proxy execution of malicious code through trusted binaries — the "Squiblydoo" technique), wmic.exe (remote execution and reconnaissance), bitsadmin.exe (download via background transfer jobs), and msbuild.exe (compile and run inline C#).
🔍 The crucial detection insight: you cannot block these binaries — they're essential system tools — so you detect them by context and behavior, not by their presence. The red flags are things like certutil reaching out to download from the internet, powershell invoked with an encoded (-enc) command, regsvr32 making a network connection to a URL, rundll32 running with no arguments, or — the highest-value signal of all — an Office application (Word, Excel, Outlook) spawning any of these as a child process. This is behavioral detection at the top of the Pyramid of Pain, and it requires logging command lines — via Windows Event 4688 with command-line auditing enabled, or better, Sysmon Event ID 1. Related is fileless malware, which runs entirely in memory (reflectively loaded DLLs, PowerShell held in RAM, WMI event subscriptions, registry-resident payloads) leaving no file to scan — you catch it with EDR memory scanning, AMSI (the Antimalware Scan Interface, which inspects scripts at runtime), PowerShell script-block logging, and anomalous parent-child process relationships.
Having executed, the attacker wants to survive reboots and logoffs — Persistence (TA0003). This is a rich hunting ground because the attacker must persist somewhere, and the locations are enumerable. The common techniques and where to look: Registry Run keys and the Startup folder (T1547.001) — check HKLM/HKCU\...\Run and Sysmon Event 13; Scheduled Tasks (T1053.005) — Event 4698 and the tasks folder; new or modified Services (T1543.003) — Events 7045 and 4697, a hallmark of tools like PsExec; WMI event subscriptions (T1546.003) — stealthy persistence via __EventFilter and __EventConsumer objects; DLL search-order hijacking (T1574) — a malicious DLL planted where a legitimate program will load it; web shells (T1505.003) on compromised servers; and simply creating a new privileged account (T1136) — Events 4720 (user created) and 4728 (added to a privileged group).
🔍 Persistence hunting is one of the highest-value proactive activities a senior analyst does. Because the attacker has to leave persistence artifacts, you can baseline the normal set of autoruns, scheduled tasks, services, and Run keys across your fleet (tools like Sysinternals Autoruns enumerate them all), then diff against that baseline to surface the anomalous new entry that shouldn't be there. Attackers hide in the noise of thousands of legitimate autoruns; a good baseline strips the noise away.
A foothold is rarely enough — attackers usually land as an ordinary user and need more power. Privilege Escalation (TA0004) comes in two directions. Vertical escalation goes from a low-privilege user up to Administrator, SYSTEM, or root, exploiting unpatched kernel or service vulnerabilities, UAC bypasses (T1548.002), access-token manipulation (T1134), DLL hijacking, or weak service configurations (unquoted service paths, writable service binaries on Windows; SUID misconfigurations on Linux). Horizontal escalation moves sideways to another account at the same level to access its data.
But the true prize is Credential Access (TA0006) — stealing the credentials that unlock everything else. The techniques here are the ones you must be able to detect, because credential theft is the pivot point of nearly every serious intrusion. LSASS memory dumping (T1003.001) is the most common: the LSASS process on Windows holds credentials in memory, so attackers dump its memory (with Mimikatz, procdump, or the built-in comsvcs.dll MiniDump) to extract password hashes and even plaintext. SAM/registry hive dumping (T1003.002) steals the local account database. DCSync (T1003.006) impersonates a domain controller to request password hashes via the AD replication protocol — devastating because it needs no code on a DC. Attackers also harvest credentials from files and Group Policy Preferences (T1552), steal from browser and credential stores (T1555), and attack Kerberos (next section).
🔍 If you build only one endpoint detection in your entire career, make it this: alert on any non-system process opening a handle to LSASS with read/dump access. Virtually every credential-theft tool must touch LSASS, and legitimate processes that do so are a short, known list. In Sysmon, this is Event ID 10 (ProcessAccess) targeting lsass.exe with suspicious GrantedAccess masks (values like 0x1010, 0x1410, or 0x1FFFFF). This single, behavior-based rule catches a large fraction of real-world intrusions at their most critical moment — the theft of the credentials that would otherwise let the attacker own your whole domain.
Here is where senior knowledge truly separates from junior. In the vast majority of enterprises, Active Directory (AD) is the central nervous system — it controls authentication and authorization for every user and computer. Consequently, most serious intrusions become AD intrusions, and an attacker who compromises AD owns the organization. A senior analyst must understand the Kerberos authentication protocol and the family of attacks against it. This is dense; read it slowly.
Kerberos in plain terms: When you log in, your machine contacts the Key Distribution Center (KDC) on a domain controller. It sends an AS-REQ (Authentication Service Request) and, if your identity checks out, receives a Ticket Granting Ticket (TGT) — a special ticket encrypted with the secret key of a hidden account called krbtgt. Later, when you want to access a specific service (a file share, a database), you present your TGT in a TGS-REQ and receive a service ticket (TGS) encrypted with that service's account password hash. You hand the service ticket to the service, which decrypts it to verify you. Every attack below abuses some step of this dance.
Kerberoasting (T1558.003) exploits the fact that any authenticated user can request a service ticket for any service account (identified by its SPN), and that ticket is encrypted with the service account's password hash. The attacker requests tickets for service accounts and cracks them offline — no further interaction with your systems, so it's stealthy. You detect it by watching for spikes in Kerberos service-ticket requests (Event 4769), especially requests using the weak RC4 encryption type (0x17), which cracking tools prefer.
AS-REP Roasting (T1558.004) targets accounts configured (misconfigured, really) with "do not require Kerberos pre-authentication." For those accounts, an attacker can request authentication data and crack it offline. Detect via Event 4768 for accounts with pre-auth disabled, and proactively audit for the DONT_REQ_PREAUTH flag.
Pass-the-Hash (T1550.002) exploits that Windows NTLM authentication accepts a password hash directly — the attacker never needs the plaintext. Steal the hash (from LSASS), and you can authenticate as that user. Pass-the-Ticket (T1550.003) is the Kerberos equivalent: steal and reuse a valid Kerberos ticket. You detect these through anomalous authentication patterns — NTLM logons (Event 4624 type 3) from unexpected hosts, or tickets used from the "wrong" machine.
The two most feared attacks are the forged tickets. A Golden Ticket (T1558.001) is created when the attacker has stolen the krbtgt account's hash — with it, they can forge a TGT for any user with any privileges, granting essentially unlimited, long-lived domain access that's very hard to detect. A Silver Ticket (T1558.002) is narrower: with a specific service account's hash, the attacker forges a service ticket for that one service, bypassing the KDC entirely (so there's no 4769 event — its very absence where you'd expect one is a clue). DCSync (T1003.006), mentioned earlier, impersonates a DC to pull hashes via replication — detectable as replication requests (Event 4662 with the replication GUID) coming from a host that isn't a domain controller. DCShadow (T1207) goes further, registering a rogue DC to inject malicious changes into AD.
🔍 Defensive priorities for a senior protecting AD: fiercely protect the krbtgt account (and rotate its password twice if you suspect a Golden Ticket, because AD keeps the current and previous password); implement a tiered administration model so domain admin credentials never touch ordinary workstations where they can be stolen; disable NTLM where feasible; alert on RC4 Kerberos ticket spikes (4769) and DCSync from non-DCs (4662); deploy honey accounts and honey SPNs (fake service accounts that no legitimate process would ever request — any Kerberoast attempt against them is a high-confidence alert); and run BloodHound yourself. BloodHound maps the graph of attack paths through your AD — "who can reach Domain Admin, and how" — so you can find and cut those paths before the adversary walks them. 🔬 That last point captures the senior mindset: don't just wait to detect the attack, proactively eliminate the conditions that make it possible.
🧨 Tricky Question: "An attacker has obtained the krbtgt account's password hash. What can they now do, and what's the remediation?" With the krbtgt hash they can forge Golden Tickets — TGTs impersonating any user with any privilege, granting persistent domain-wide control. The remediation trap is "reset krbtgt once" — you must reset it twice (AD retains the previous password for one rotation), and even then you should treat the entire domain as compromised and investigate thoroughly.
With stolen credentials, the attacker spreads from their initial foothold to other systems — hunting for the data or the domain controller they ultimately want. This is Lateral Movement, and it's precisely the east-west traffic that perimeter defenses never see, which is why internal visibility is so valuable. The common techniques leave distinctive traces. PsExec and remote service creation (T1021.002, T1569) create a service on the target — look for Event 7045 (service installed), access to the ADMIN$ share, and the psexesvc named pipe. RDP (T1021.001) shows as Event 4624 logon type 10 and an unusual internal RDP connection graph. WMI and WinRM (T1021.006, T1047) enable remote execution — watch for wmic /node: usage and WinRM traffic on 5985/5986. SMB/admin shares (T1021.002) give file access to C$/ADMIN$ — Events 5140/5145. And Pass-the-Hash/Ticket (above) enables authentication without cracking passwords.
🔍 The detection strategy that catches lateral movement is graphing internal authentication. In a healthy tiered environment, workstations don't authenticate to each other, and admin accounts don't log into ordinary desktops. So the signals of movement are stark once you look: one workstation suddenly authenticating to many hosts in a short window, admin logons appearing between peer workstations, or a service being created across several machines in sequence. Combine segmentation (which limits where movement is even possible) with east-west visibility (network detection, internal packet capture) and this authentication-graph analysis, and you turn lateral movement — otherwise nearly invisible — into one of your clearest signals. North-south egress monitoring alone would miss it entirely.
To operate remotely, the attacker needs a Command & Control (C2, TA0011) channel — and modern C2 is built to hide in plain sight. The dominant pattern is HTTPS beaconing using frameworks like Cobalt Strike, Sliver, and Mythic: the implant "phones home" at regular intervals (with jitter — random variation — to look less robotic) to fetch commands. Attackers also tunnel C2 through DNS (encoding data in subdomain queries and TXT records), abuse CDNs and domain fronting to disguise the true destination, and increasingly route C2 through legitimate services — Slack, Telegram, Discord, Google Docs, GitHub — so it blends perfectly with allowed traffic. Malleable C2 profiles let attackers shape their traffic to mimic real applications.
🔍 Detecting C2 draws directly on the packet-analysis skills from the Wireshark guide. The signatures: beacon regularity (traffic at suspiciously even intervals, even with jitter, unlike human browsing), long-lived low-volume conversations, JA3/JA3S TLS fingerprints matching known frameworks (a way to identify the client software even inside encrypted traffic), self-signed or mismatched certificates on odd ports, and DNS anomalies (long hex-looking subdomains, heavy TXT usage, or NXDOMAIN storms from domain-generation algorithms). The strongest signals are combinations: beaconing regularity plus a rare destination plus an unusual user-agent is a high-confidence C2 finding.
Finally, the attacker achieves their goal. Exfiltration (TA0010) moves data out — over the C2 channel (T1041), over DNS (T1048), or to cloud storage like Dropbox, Mega, or S3 (T1567), usually after staging and compressing it into an archive (T1560). Impact (TA0040) is the destructive endgame: ransomware (T1486), data destruction (T1485), defacement, cryptomining, or DDoS. A specifically vital detection is around inhibiting recovery (T1490) — before encrypting, ransomware almost always deletes Volume Shadow Copies (vssadmin delete shadows) so victims can't restore.
🔍 Pre-ransomware tripwires give you minutes to save the organization — treat them as critical, drop-everything alerts. The moments before mass encryption are noisy: mass shadow-copy deletion (vssadmin/wbadmin), sudden disabling of security services and backups, a spike in mass file renames or extension changes, and honeyfiles being touched. Catching any of these and isolating the host in that narrow window can be the difference between a contained incident and a company-ending event. This is where fast, well-tuned detection and a rehearsed containment playbook prove their entire worth.
You cannot investigate what you cannot see, and on Windows — which is what most enterprises run — seeing means knowing Windows Event Logs. This is arguably the most practically important reference in this entire guide for a working SOC/IR analyst, so we'll treat it properly: not just a list of numbers, but what each event means, why it matters, and how you weaponize it defensively.
Windows records security-relevant activity in the Security event log (plus System, Application, and specialized operational logs). Each event has an Event ID. The catch is that default logging is thin — many high-value events require you to enable the corresponding audit policy (via Group Policy: Advanced Audit Policy Configuration) and, ideally, to forward everything to a central SIEM via Windows Event Forwarding (WEF) so logs survive even if an attacker wipes the local copy. Here are the Event IDs a senior analyst knows by heart, grouped by investigative purpose.
Event 4624 — Successful logon. The workhorse of investigations. Every successful authentication generates one, and its most important field is the Logon Type, which tells you how the user logged in — this is what lets you distinguish a person sitting at a keyboard from a remote attack. Type 2 is interactive (physically at the console). Type 3 is network (accessing a share or resource over the network — the type you see in lateral movement and Pass-the-Hash). Type 4 is batch (scheduled task). Type 5 is a service starting. Type 7 is an unlock. Type 8 is network-cleartext (credentials sent in the clear — a red flag). Type 9 is "new credentials" (runas /netonly — associated with credential theft tooling). Type 10 is RemoteInteractive (RDP — critical for tracking remote-desktop lateral movement). Type 11 is cached credentials. 💡 Learning to read logon types transforms 4624 from noise into a precise map of who accessed what, how, and from where.
Event 4625 — Failed logon. The signature of brute-force and password-spraying attacks. A single 4625 is normal (fat-fingered password); hundreds across accounts, or a pattern of one-attempt-per-many-accounts, is an attack. The event includes the failure reason and source, so you can trace the origin.
Event 4634 / 4647 — Logoff / User-initiated logoff. Used to build session timelines — pairing logon and logoff events reconstructs exactly how long an attacker was active.
Event 4648 — Logon using explicit credentials. Generated when a process explicitly supplies alternate credentials (e.g., runas). A common footprint of lateral movement and credential use — worth watching when it originates from unusual processes.
Event 4672 — Special privileges assigned to new logon. Fires when an account with administrative/sensitive privileges logs on. Tracking 4672 highlights every privileged session — invaluable for spotting when an admin (or a stolen admin credential) becomes active.
Event 4776 — NTLM authentication attempt. Records credential validation via NTLM (the older protocol). Because Pass-the-Hash relies on NTLM, and because NTLM should be waning in favor of Kerberos, unexpected 4776 events from odd sources are worth scrutiny.
Event 4740 — Account locked out. Signals that lockout thresholds were hit — a symptom of brute force, spraying, or (occasionally) a service using stale credentials. A wave of lockouts can also be a denial-of-service side effect.
Event 4768 — A Kerberos TGT was requested. The initial authentication ticket request. Relevant to AS-REP Roasting detection (accounts lacking pre-auth) and to baselining normal authentication.
Event 4769 — A Kerberos service ticket was requested. The event for detecting Kerberoasting. Attackers requesting many service tickets — especially with the weak RC4 encryption type (0x17) — produce a detectable spike. Correlating 4769 volume and encryption types per user is a core AD hunt.
Event 4771 — Kerberos pre-authentication failed. Kerberos's equivalent of a failed logon; useful for spotting authentication attacks against the KDC.
Event 4688 — A new process was created. One of the most valuable events in existence if you enable command-line auditing (a Group Policy setting). With it, 4688 records the full command line of every process — letting you catch encoded PowerShell, LOLBin abuse, and suspicious parent-child relationships (Word spawning cmd). Without command-line auditing, you only get the process name, which is far weaker. Enable command-line auditing — it's one of the highest-return logging changes you can make. (Event 4689 records process exit, useful for timelines.)
Event 7045 — A new service was installed (in the System log). A hallmark of PsExec-style lateral movement and service-based persistence. A new, oddly named service appearing on a machine — especially one running an encoded command or pointing at a temp directory — is a classic intrusion signature. (Event 4697 is the Security-log equivalent when service-install auditing is on.)
Events 4698 / 4699 / 4702 — Scheduled task created / deleted / updated. Scheduled tasks are a favorite persistence mechanism. Monitoring their creation catches attackers establishing a foothold that survives reboots.
Event 4720 — A user account was created. Attackers create accounts for persistent access. An unexpected 4720 — especially outside normal provisioning processes or off-hours — demands investigation. (4726 is account deletion.)
Events 4728 / 4732 / 4756 — A member was added to a security-enabled (global / local / universal) group. These fire when an account is added to a privileged group like Domain Admins. Someone adding themselves or a new account to Domain Admins is a screaming-red-alert privilege-escalation signal. (4738 records account changes; 4735 records privileged group changes.)
Event 4662 — An operation was performed on an Active Directory object. Ordinarily noisy, but with the right auditing it is the detection for DCSync: replication operations (identifiable by specific control-access-right GUIDs) requested by anything that isn't a legitimate domain controller means an attacker is pulling password hashes. This is a high-value, senior-level detection.
Event 1102 — The audit log was cleared. Always investigate this. Clearing the security log is a deliberate anti-forensic act — legitimate administrators almost never do it, and attackers do it to cover their tracks. 1102 should be a high-priority alert every single time it fires. (On the System log, Event 104 indicates a specific log was cleared.)
Events 5140 / 5145 — A network share was accessed / checked. These reveal access to file shares (including administrative shares like C$ and ADMIN$), illuminating both lateral movement and data staging/collection.
Because PowerShell is the attacker's favorite tool, its dedicated logs are gold. Event 4104 (PowerShell Script Block Logging) records the actual deobfuscated content of PowerShell commands as they execute — defeating the encoding and obfuscation attackers rely on. Enabling script-block logging, module logging, and transcription turns PowerShell from a blind spot into one of your best sources of truth. Complementing this, AMSI (the Antimalware Scan Interface) lets security products inspect script content at runtime, even when it's generated in memory.
Windows's built-in logging, even tuned, has gaps. Sysmon (System Monitor, a free Microsoft Sysinternals tool) fills them, providing dramatically richer telemetry that ships to your SIEM. Its key Event IDs: 1 — Process creation (with full command line, hashes, and the parent process — better than 4688); 3 — Network connection (attributing a connection to the specific process that made it, which native logs don't easily do); 7 — Image/DLL loaded (catching unsigned DLLs and injection); 8 — CreateRemoteThread (a core signal of process injection); 10 — ProcessAccess (the LSASS-access detection discussed earlier — arguably the single best endpoint detection you can build); 11 — File created; 12/13/14 — Registry events (catching Run-key persistence); 15 — alternate data streams; 22 — DNS query (attributing DNS lookups to the process that made them — superb for catching malware C2 and tunneling); and 23/26 — file deletion (catching anti-forensic cleanup). 💡 Deploy Sysmon with a curated configuration (community baselines from SwiftOnSecurity or Olaf Hartong are the standard starting points — they filter out noise and highlight the suspicious), forward it to your SIEM, and you instantly gain process lineage, per-process network and DNS attribution, and injection detection that native logging can't match. Adopting Sysmon well is one of the clearest capability jumps a SOC can make.
Beyond live logs, Windows also leaves a wealth of forensic artifacts on disk that reconstruct past activity even when logs are gone: Prefetch (evidence of program execution), ShimCache and AmCache (execution history), the $MFT (master file table — every file's metadata), the USN Journal (a record of file changes), SRUM (resource usage including per-app network bytes), jump lists and LNK files (recently accessed files), and registry hives. A senior DFIR analyst mines these to build a timeline of exactly what executed and when, long after the fact.
🧨 Tricky Question: "You want to detect an attacker running an encoded PowerShell command and to see the exact command line and parent process. Which single log source is best, and what must be enabled?" The best native answer is Event 4688 with command-line process auditing enabled (to capture the command line) — but the superior answer, if Sysmon is deployed, is Sysmon Event ID 1, which captures the full command line, hashes, and parent process by default. The trap is answering "4688" alone without noting that command-line auditing must be explicitly enabled — by default, 4688 does not include the command line, so you'd see powershell.exe but not what it ran.
Windows dominates enterprises, but servers, containers, and cloud run Linux, and modern infrastructure lives in the cloud — a senior analyst must be fluent in both.
On Linux, your primary telemetry lives in /var/log/auth.log (or secure on Red Hat) for authentication events, syslog for general system messages, and — most powerfully — auditd, the Linux Audit daemon, which can log syscalls and file access with fine granularity (configure it to watch sensitive files and command execution). journalctl queries the systemd journal, shell history files reveal attacker commands, and /var/log/wtmp records logins. Privilege escalation on Linux commonly abuses SUID/SGID binaries (programs that run with the owner's privileges — a misconfigured one can grant root), sudo misconfigurations (check sudo -l; the GTFOBins project catalogs binaries that can be abused to escape restricted sudo), writable cron jobs, kernel exploits, dangerous capabilities, and PATH hijacking. Persistence hides in cron jobs, systemd services and timers, shell startup files (~/.bashrc), added SSH keys in authorized_keys, LD_PRELOAD tricks, and loadable kernel-module rootkits. You detect by watching for new SUID files, unexpected cron/systemd units, newly added SSH keys, auditd hits on sensitive paths, and outbound connections from binaries that have no business making them.
In the cloud (AWS, Azure, GCP), the game changes fundamentally: the perimeter is identity, not the network. Most cloud attacks are about credentials and permissions, and your primary evidence is the cloud audit log — AWS CloudTrail, Azure Activity and Sign-in logs, GCP Audit Logs — which record every API call. Key attack patterns: leaked or over-privileged access keys (an attacker who finds an AWS key in a public GitHub repo can pivot straight into your account — detect via CloudTrail anomalies and GuardDuty); SSRF against the instance metadata service (tricking a cloud VM's web app into requesting 169.254.169.254 to steal the VM's IAM role credentials — a top cloud attack, mitigated by enforcing IMDSv2); IAM privilege escalation (abusing permissions like AttachUserPolicy or CreatePolicyVersion to grant oneself more power — visible in CloudTrail); public storage exposure (world-readable S3 buckets — the cause of countless breaches); persistence via new IAM users, access keys, or backdoored Lambda functions; and console logins from new geographies without MFA. A particularly important anti-forensic signal is CloudTrail being disabled (StopLogging) — like clearing the Windows audit log, this should be a critical alert.
🔍 The cloud IR truth: cloud incident response is almost entirely log-driven. If your audit logging is off, misconfigured, or unmonitored, you are effectively blind — you cannot investigate what was never recorded. The senior move is to enforce organization-wide, tamper-resistant logging delivered to a separate, locked-down account an attacker can't reach, and to alert the instant logging is disabled anywhere.
Web applications are the most exposed part of most organizations, and Layer 7 is the richest attack surface. A senior analyst must understand the OWASP Top 10 and the deeper attacks that show up in real cases — both to investigate web incidents and to correlate them with endpoint telemetry.
SQL Injection (SQLi) occurs when untrusted input is concatenated into a database query, letting an attacker alter the query's logic — to bypass authentication (' OR 1=1--), dump entire tables (via UNION queries), or in severe cases execute commands on the database server. You spot it in web logs as suspicious SQL syntax in parameters, database errors, and WAF alerts. Cross-Site Scripting (XSS) injects attacker-controlled script into pages other users view, running in their browser to steal session cookies or perform actions as them; it comes in stored (persisted on the server, affecting everyone who views the page), reflected (bounced off the server via a crafted link), and DOM-based (entirely client-side) varieties. Cross-Site Request Forgery (CSRF) tricks an authenticated user's browser into submitting a forged request (transferring money, changing an email) by exploiting that the browser automatically includes session cookies — defended with anti-CSRF tokens.
Server-Side Request Forgery (SSRF) deserves special emphasis because it's the bridge to cloud compromise: the attacker tricks the server into making requests to destinations of the attacker's choosing — often internal-only services or, devastatingly, the cloud metadata endpoint to steal credentials. Insecure Deserialization exploits applications that trust serialized objects, potentially achieving remote code execution through crafted payloads. Directory/Path Traversal uses ../ sequences to read files outside the web root (../../etc/passwd). Command Injection reaches an underlying shell through unsanitized input containing shell metacharacters (;, |, $(...)). XML External Entity (XXE) abuse exploits XML parsers that process external entities, enabling file reads and SSRF. Insecure Direct Object Reference (IDOR) and broken authorization let an attacker access others' data simply by changing an ID in a request. And file upload flaws let an attacker upload a web shell — a script granting remote command execution on the server.
🔍 The senior investigation technique — correlate web logs with endpoint telemetry. A web attack rarely lives only in web logs. The powerful move is to connect them: when a web application server's process (w3wp.exe for IIS, php-fpm, or a Java process) suddenly spawns a child process like cmd.exe, powershell.exe, or whoami, that parent-child anomaly — visible in Sysmon Event 1 — is the fingerprint of a successful web exploitation or web shell in action. Tying the WAF alert and web server logs (the attempt) to the endpoint process spawn (the success) gives you a complete, high-confidence picture. This cross-domain correlation — refusing to look at any one log source in isolation — is a defining habit of senior analysis.
🧨 Tricky Question: "A web application lets an attacker make the server fetch a URL of their choosing, and the attacker uses it to reach http://169.254.169.254/. What attack is this, what are they after, and how do you prevent it in AWS?" This is SSRF (Server-Side Request Forgery), and 169.254.169.254 is the cloud instance metadata endpoint — they're trying to steal the VM's IAM role credentials to pivot into the cloud account. The AWS-specific prevention is enforcing IMDSv2, which requires a session token and blocks the naive SSRF fetch. The trap is calling it CSRF — CSRF forges requests from a user's browser; SSRF forges them from the server.
Here is the capability that most defines the leap from analyst-who-responds to analyst-who-builds: detection engineering — the discipline of creating the detections that catch attackers, rather than only reacting to the ones your tools ship with. An L1 works the alerts that fire; an L3 asks "why didn't we have an alert for that?" and builds one.
Detection engineering treats detections like software: you develop them, test them, version-control them, and continuously improve them — an approach called detection-as-code. The workflow: you start from a threat (a technique from ATT&CK, an incident you just handled, or a threat-intel report), form a hypothesis about what observable evidence it would produce, identify the data source that would contain that evidence (a specific Event ID, a Sysmon event, a network log), write the detection logic, then test it against both real attack data (does it catch the thing?) and normal data (does it flood you with false positives?), and finally tune and deploy it. Good detections are documented with the ATT&CK technique they cover, the data source they need, and known false-positive scenarios.
A common language for portable detections is Sigma — a generic, YAML-based rule format that can be translated into the query language of any SIEM (Splunk SPL, Elastic, Sentinel KQL). Writing a detection once in Sigma and converting it everywhere is a hallmark of a mature program. (On the network side, Snort/Suricata rules and YARA rules — for identifying malware by content patterns — are the equivalent craft.)
💡 The principle that makes detections good rather than merely present is, once again, the Pyramid of Pain. A detection for a specific file hash is brittle — it breaks the moment the attacker recompiles. A detection for a behavior — "an Office application spawned a scripting interpreter that made an external network connection," or "a process accessed LSASS memory with dump rights," or "a service was installed that runs an encoded command" — is durable, because the attacker can't evade it without abandoning the technique itself. Senior detection engineers deliberately build behavioral, TTP-level detections and treat hash/IP blocklists as a low-value supplement, not the core. They also think about detection coverage systematically: mapping every detection to the ATT&CK matrix reveals exactly which tactics and techniques you're blind to — turning "are we secure?" into the far more actionable "which specific attacker techniques would currently go undetected, and which do we fix next?"
🔬 A related senior skill is understanding the detection quality tradeoff. Every detection sits on a spectrum between too noisy (high recall, many false positives — analysts burn out and start ignoring it) and too narrow (high precision but misses variants — false negatives let attackers through). The art is writing logic robust enough to catch technique variants while precise enough to stay actionable, and then continuously tuning as the environment and adversaries evolve. A detection is never "done."
Detection engineering builds automated tripwires; threat hunting is the proactive, human-driven search for adversaries who slipped past them. It rests on the assumption of breach — you don't wait for an alert, you actively hypothesize that an attacker is already present and go looking for evidence. This is senior work by definition: it requires deep knowledge of both attacker behavior and your own environment's "normal."
The most rigorous approach is hypothesis-driven hunting. You form a specific, testable hypothesis — usually derived from an ATT&CK technique, a threat-intel report about an actor targeting your sector, or an anomaly you noticed. For example: "If an adversary is using Kerberoasting against us, I'll see accounts requesting an unusual number of service tickets with RC4 encryption (Event 4769)." You then gather the relevant data, analyze it against the hypothesis, and reach a conclusion: either you find evidence (escalate to incident response), or you don't (which still has value — you've validated a detection gap, and you turn the successful hunt into a permanent automated detection). Other hunt approaches include IOC-based hunting (searching for known-bad indicators from intel) and anomaly/baseline hunting (finding statistical outliers — the host talking to a country it never has, the account active at 3 a.m., the rare parent-child process pair).
🔍 A structured way many teams frame hunts is around the question "what would this technique look like in my telemetry, and do I see it?" You pick a technique you're worried about, enumerate the data sources that would reveal it, query for the behavior, filter out the legitimate causes, and investigate what remains. Crucially, every hunt should produce an outcome even when it finds nothing: either an incident, a new detection rule (so the gap is closed forever), a tuning improvement, or documented confidence that the technique isn't present. A hunt that changes nothing was run poorly. 🔬 The senior mindset here is turning one-time hunts into permanent, automated coverage — you don't want to hand-hunt the same technique every month; you want to hunt it once, then engineer a detection so the machine watches it for you and frees you to hunt the next thing.
When an incident yields a suspicious file, a senior analyst needs at least foundational malware analysis skill to answer "what does this do, and what should I hunt for as a result?" — even if deep reverse engineering goes to a specialist. Analysis divides into static and dynamic.
Static analysis examines the file without running it. The basics: compute its hashes (SHA-256) and check them against VirusTotal and threat intel; extract readable strings (which often reveal URLs, IP addresses, file paths, commands, and other indicators); inspect the file's structure (for a Windows PE, its headers, imported functions — which hint at capabilities like network or crypto use — and sections); and detect packing/obfuscation (attackers compress or encrypt their code to evade analysis; high entropy and few readable strings suggest a packed file that must be unpacked first). Static analysis is safe and fast but can be defeated by heavy obfuscation.
Dynamic analysis runs the malware in a controlled, isolated sandbox (an instrumented VM, ideally network-isolated or with simulated internet) and observes its behavior: what files it creates or modifies, what registry keys it sets (persistence!), what processes it spawns, and — most valuable for a defender — what network connections it makes (revealing C2 domains and IPs you can now block and hunt for). Automated sandboxes (Cuckoo, and commercial services) produce behavioral reports quickly. The tradeoff: sophisticated malware employs sandbox evasion — detecting the analysis environment (checking for VM artifacts, requiring user interaction, sleeping to outlast the analysis window) and refusing to detonate, so a "clean" sandbox result isn't proof of safety.
🔍 The defender's real goal in malware analysis isn't academic — it's producing actionable intelligence. From analyzing a sample you extract IOCs (hashes, C2 domains/IPs, file paths, registry keys, mutexes) and, more valuably, behaviors/TTPs (mapped to ATT&CK) that you feed straight back into detections and hunts across the whole environment. You analyze one sample to protect against the entire campaign — turning a single artifact into fleet-wide detection. And remember the Pyramid of Pain: the C2 domains you extract are useful but transient; the behavioral patterns you extract are the durable prize.
Domain 4 introduced forensic principles; senior Digital Forensics and Incident Response (DFIR) applies them under real pressure, across memory, disk, and network. The defining senior skill is timeline reconstruction — weaving artifacts from many sources into a single, chronological narrative of exactly what the adversary did, when, and how, from initial access to impact. This is what a real investigation is: not "we found malware," but "at 09:14 the user opened a phishing attachment, which at 09:15 spawned PowerShell that downloaded a beacon, which at 11:40 dumped LSASS, which enabled a 14:03 lateral move to the file server, from which 240 GB was staged and exfiltrated by 15:20."
Memory forensics is the senior capability that most distinguishes deep investigators, because — as the order of volatility taught us — RAM holds evidence that exists nowhere else: running processes (including malware with no file on disk), active network connections, injected code, decryption keys, and command history. You capture memory with tools like WinPmem or via EDR, then analyze the image with frameworks like Volatility or Rekall, which can list processes (including hidden ones), extract network connections, dump injected code, recover command lines, and pull credentials or keys from memory. Fileless and injection-based malware, which leaves nothing on disk, is often only catchable in memory — which is why "pull the plug" is frequently the wrong first move and live memory capture the right one.
On disk, senior DFIR mines the Windows forensic artifacts catalogued in section 36 — Prefetch, ShimCache, AmCache, the $MFT, USN Journal, SRUM, registry hives, LNK files, and browser history — to reconstruct execution and file-access history even long after logs have rolled or been wiped. On the network, full packet captures and flow logs reconstruct C2 and exfiltration (the Wireshark guide's domain). Throughout, the forensic discipline holds: image before you analyze, hash to prove integrity, maintain chain of custody, document everything. And a senior IR lead thinks beyond the technical — coordinating containment decisions against business impact, managing out-of-band communications, handling legal and regulatory notification obligations, and briefing leadership in terms they can act on.
🔍 A repeatable senior IR triage flow when handed a compromised host: capture volatile memory first (before anything changes it); collect key artifacts (event logs, Prefetch, registry, scheduled tasks, autoruns); identify the initial access vector and the timeline's start; map every observed action to ATT&CK; determine scope (what else did the attacker touch — check lateral-movement authentication graphs and shared IOCs across hosts); contain without tipping off the adversary prematurely; eradicate every foothold (all persistence, all compromised credentials — attackers plant multiple backdoors, so finding one is never "done"); recover and monitor closely for return; and document rigorously for the post-incident review and any legal proceedings.
Two final capabilities mark a mature, senior practitioner. Cyber Threat Intelligence (CTI) is the practice of turning raw information about adversaries into actionable knowledge, organized into three tiers: strategic intelligence (high-level trends and actor motivations, for leadership and risk decisions), operational intelligence (specific campaigns and adversary TTPs, for detection and hunting priorities), and tactical intelligence (concrete IOCs — hashes, domains, IPs — for immediate blocking and detection). Intelligence is shared through standardized formats — STIX (the data format) and TAXII (the transport) — and through communities like ISACs (Information Sharing and Analysis Centers) for your industry. The senior skill is not merely consuming feeds but operationalizing them: taking a report that "actor X targeting our sector uses techniques Y and Z" and turning it into specific hunts and detections tuned to your environment — and, going further, producing your own intelligence from the incidents you handle, feeding the community back.
Purple teaming unites offense and defense to measurably improve detection. Where a red team attacks and a blue team defends, often in isolation, a purple team has them collaborate: the red team (or an adversary emulation using frameworks like MITRE Caldera or Atomic Red Team to safely replay specific ATT&CK techniques) executes a known technique while the blue team watches to see whether their detections fire. Every technique that doesn't trigger an alert is an immediate, prioritized detection-engineering task. This closes the loop beautifully: emulate a real adversary technique → observe your visibility gap → build the detection → re-test to confirm it now fires. Purple teaming turns your ATT&CK coverage map from theoretical to empirically validated — you don't just believe you'd catch a technique, you've proven it. 🔬 This continuous, evidence-based improvement of detection coverage is arguably the highest expression of the senior defensive craft.
Techniques and tools are necessary but not sufficient. What ultimately makes a senior analyst is a set of habits of mind, worth stating plainly because they're the through-line of everything above.
Assume breach. The senior analyst doesn't ask "are we secure?" but "how would I know if we weren't?" — and goes looking. Think in behaviors, not indicators. Every instinct pulls toward the durable top of the Pyramid of Pain. Correlate across sources. No single log tells the truth; the picture emerges from tying web logs to endpoint process trees to network flows to authentication graphs. Understand normal deeply — you can only spot the anomaly if you've internalized the baseline, which means knowing your environment intimately. Close the loop. Every incident becomes a detection; every hunt becomes automated coverage; every gap becomes a fix — you never solve the same problem twice by hand. Reduce attacker options proactively — cut the AD attack paths, enforce least privilege, shrink the attack surface before the adversary arrives. And communicate impact, not jargon — translate packet-level findings into business risk that leadership can act on, because an investigation nobody understands changes nothing.
The growth path from here typically runs through hands-on practice and progressively harder credentials. Beyond Security+, the natural next steps for a defender are CompTIA CySA+ (analyst-focused) and Cisco CyberOps for SOC fundamentals; then blue-team certifications like the BTL1/BTL2 (Blue Team Level), GIAC's GCIH (incident handling), GCIA (intrusion analysis), GCFA/GCFE (forensics), and GNFA (network forensics); and for the well-rounded senior, understanding the offensive side through practical labs (in authorized environments only) sharpens defense. But certifications merely mark the path — the actual work is reps. Build a home lab. Analyze real malware traffic (Malware-Traffic-Analysis.net). Play the detection side of Capture-the-Flag and platforms like TryHackMe, HackTheBox, and LetsDefend. Set up Sysmon and a SIEM and hunt your own traffic. Read incident reports and map them to ATT&CK. Write detections. The theory in this guide is the map; thousands of hours of hands-on investigation is the territory, and there is no shortcut through it — only the deliberate, repeated practice that slowly turns knowledge into the instinct a senior analyst brings to a live incident at 3 a.m.
If your goal is passing Security+ (SY0-701): Plan roughly 8–10 weeks with prior IT/networking exposure, or 14–16 weeks without. The sequence that works:
- Week 1 — Foundations. Chapter 0 (OSI, TCP/IP, ports) and Domain 1. Do not move on until you can teach the OSI layers and classify any control on both axes. These are the vocabulary for everything else.
- Weeks 2–3 — Threats (Domain 2, 22%). The biggest knowledge domain. Drill the malware families, social-engineering types, and attack taxonomy until the distinctions are automatic. Use the tricky-question callouts as a self-quiz.
- Weeks 3–4 — Architecture (Domain 3, 18%). Cloud shared responsibility, segmentation, secure protocols (memorize the insecure→secure port swaps), data states, and recovery metrics (RTO vs RPO — don't swap them).
- Weeks 4–6 — Operations (Domain 4, 28%). Spend the most time here — it's the largest domain and the most performance-based. Make the incident response phases (PICERL) and order of volatility instinctive, not memorized. Practice reading logs in a real environment.
- Weeks 6–7 — Program Management (Domain 5, 20%). Governance vocabulary, the risk formulas (SLE/ALE — practice the math), agreement acronyms, and compliance frameworks.
- Weeks 7–8 — Practice exams under timed conditions (90 questions, 90 minutes). Review every wrong answer until you understand why it's wrong, not just which letter is right. CompTIA loves "most correct" framing where two answers look valid.
Study technique that beats re-reading: after each section, close the guide and explain it aloud as if teaching. Where you stumble, re-read. This "teach-back" plus the inline 🧨 tricky questions will surface your real gaps far faster than passive review. Also work the official CompTIA objectives PDF as a checklist — everything testable is on it, and nothing off it appears.
If your goal is Senior/L3 capability: certifications mark the path but reps build the skill. Concretely: (1) build a home lab (a Windows VM + a Linux VM + a SIEM like free Elastic or Splunk); (2) deploy Sysmon with a community config and forward logs to your SIEM, then hunt your own activity; (3) work real packet captures on Malware-Traffic-Analysis.net (pcaps with real malware and answer keys) — the single best free blue-team practice; (4) replay ATT&CK techniques safely with Atomic Red Team and watch whether your detections fire (personal purple teaming); (5) practice on LetsDefend, TryHackMe (Blue path), and Blue Team Labs Online; (6) read public incident reports and map each to ATT&CK. Progress through CySA+ → BTL1 → GCIH/GCIA/GCFA as milestones, but let the hands-on hours be the real curriculum.
- CompTIA official SY0-701 objectives PDF — the authoritative, finite list of what's testable. Get it from CompTIA.org and treat it as a checklist.
- NIST Special Publications — 800-207 (Zero Trust), 800-61 (Incident Handling), 800-53 (Controls). Primary sources, free.
- MITRE ATT&CK (attack.mitre.org) — the adversary-behavior knowledge base you'll use for your whole career. Free.
- Malware-Traffic-Analysis.net — free, dated exercises with real malicious pcaps, questions, and answers. Unmatched for hands-on blue-team practice.
- Sysmon + community configs (SwiftOnSecurity, Olaf Hartong) — deploy and hunt your own telemetry.
- The Wireshark Mastery guide (companion to this document) — for the packet-level detection skills referenced throughout Part B.
- Sigma (github.com/SigmaHQ) — portable detection rules to study and adapt.
- Practice platforms — LetsDefend, TryHackMe, Blue Team Labs Online, HackTheBox.
The 🧨 callouts throughout this guide are not decoration — they are the specific traps that exams and interviewers use, and they cluster around a few recurring themes: swapped pairs (RTO/RPO, encrypt-with-public vs sign-with-private, Policy Engine vs PEP, containment vs eradication, OAuth vs OIDC), "same-category" fakes (password+PIN isn't MFA), near-neighbor confusion (port 636 vs 389, virus vs worm, CSRF vs SSRF), and "most correct" framing where two answers look right but one is primary. When you meet a question that feels like it has two right answers, slow down and ask which one addresses the root of what's described. Reviewing just the tricky-question callouts before an exam is high-yield revision.
Released under CC BY 4.0 — free to share and adapt with attribution.
This is an independent educational study guide, framed for defenders. It references CompTIA Security+ (SY0-701) objectives current as of 2026 — always confirm the active exam version and objectives at CompTIA.org before you register. MITRE ATT&CK® is a registered trademark of The MITRE Corporation.
The map is now in your hands. The territory is thousands of hours of hands-on practice. Go build the lab. 🛡️