# Revision Room: revision-first network security and blue-team plan

Version 2 · 1 October 2026

## Purpose

For an experienced practitioner who needs a structured revision before deeper work. The sequence is 14 weeks, but progress follows completed sessions rather than elapsed dates. Network security is primary, SOC/detection secondary; DevSecOps is conditional. This is preparation and consolidation, not a promise of mastery or an offer.

## Daily rhythm

Five study days, one review day, one actual day off. Standard day: 90 min refresh, 120 min practical work, 45 min recall, 45 min notes/evidence, 30 min spaced review, 30 min applications (six hours total). Short day: 20/60/20/10 minutes plus 10 minutes applications; stay on an unfinished session. Interviews can replace study time. Time budgets are guides, not completion gates.

Weeks 1–2 allow references first: refresh, follow one example, try independently, then explain. Do not skip this revision because you have work experience. Later assessments use unfamiliar variations.

## Completion and review

Check Refresh, Practise, Recall and Record only after doing them. Session completion records work, not mastery. Weekly gate: score accuracy, reasoning, practical evidence and communication 0–2 each. Aim for 7/8 with no zero. Repair failed prerequisites before dependent work. Self-rated recall: Again in 1 day, With a hint in 3 days, Got it in 7 days then doubling up to 30. Unseen questions are introduced through sessions; the queue is not an automatic exam grader.

## Scope and evidence

Reuse fwdelta, sb-siem-mcp and the existing rules repository where relevant. Aim first for three PCAP reports, five validated detections (positive and benign tests) and three full incident reports. Extend to 15 rules only when useful. Keep a topology, versions, collection prerequisites and one reproducible regression check per important detection. Use isolated labs and safe training datasets. No real employer secrets or personal incident data in portfolios.

Microsoft Kusto KQL is the primary query language in this version; Wazuh is the lab foundation, not a Kusto execution engine. Use Microsoft Learn sample data for Kusto. If target jobs consistently demand Splunk, substitute SPL practice rather than adding an equal second track. Pin the Wazuh version and its XML-manager or Sigma-indexer rule path.

Write initial queries/rules unaided. Use docs and feedback to repair errors, then repeat on a new example. Scripts must be explainable and debuggable. No compulsory certification. Review AZ-900, SC-200 or SC-500 only after role selection and practical evidence.

## Applications and interviews

Start suitable applications in week 1; update the relevant résumé weekly. Use revision-week verbal explanations as low-pressure interview practice; run weekly timed mocks from week 4 inside review time. Track applications, responses, interviews, outcomes and recurring feedback. Prepare real work stories while clearly distinguishing labs.

## Lab and budget

Start with Packet Tracer, existing VMs and Wazuh. Use one training platform at a time. Check resource requirements, evaluation licences and current free-tier limits before provisioning. Set a budget and remove unneeded cloud resources after use. If hardware cannot run AD and SIEM simultaneously, use staged labs or supplied datasets.

## Week 1: Reconnect the network basics

Phase: Foundation reset

**Gate:** Explain a packet journey and diagnose simple addressing, switching and DNS faults with notes available first.

Reference: [Cisco Packet Tracer](https://www.netacad.com/courses/packet-tracer)

### Session 1: Follow a packet

**Understand:** Start with the path you already know: application → transport → IP → Ethernet. IP addresses identify endpoints across networks; MAC addresses deliver frames on the local link. For a remote destination, your host sends a frame to its gateway. Each router replaces link-layer headers while forwarding the IP packet. NAT, when present, can change IP addresses and ports.

**Worked example:** Example: your laptop is 192.168.1.20/24; its gateway is 192.168.1.1. To contact 93.184.215.14, the laptop keeps 93.184.215.14 as the destination IP but first looks up the gateway’s MAC. The Ethernet frame goes to that MAC. The router receives the frame, consults its route table, then puts the packet in a new link-layer frame for the next hop.

**Follow along:**

1. Write four boxes on paper: your laptop, default gateway, DNS resolver, website. Mark what each box knows before the request.
2. On Windows run `ipconfig /all`, `route print`, `arp -a`; on Linux run `ip -br addr`, `ip route`, `ip neigh`. Find your local IP/prefix and default gateway. If `ip` is unavailable, use `ifconfig` or your network settings.
3. Run `nslookup example.com` or `dig example.com`. Record the resolver and returned address. DNS gives an address; it does not deliver the page.
4. Open Wireshark on the active interface. Set display filter `dns or tcp.port == 443`. Visit `https://example.com` in a new tab. Find the DNS exchange, then a TCP SYN/SYN-ACK/ACK to one returned IP.
5. Return to your diagram. For the first packet to a remote IP, label destination IP and destination MAC separately. Say aloud which one changes at each router and why.

**Expected result:** You should find a default route via your gateway. The DNS response should contain at least one address (often IPv4 and/or IPv6). A normal TCP connection usually begins with SYN, SYN-ACK, ACK; HTTPS follows. DNS or browser caches can remove packets you expected.

**If stuck:** No DNS packet? Flush only your lab/browser cache or query a new hostname, and confirm you captured the active interface. No SYN? The browser may reuse a connection, choose IPv6, use HTTP/3 over UDP 443, or use a proxy. Use `curl -vI https://example.com` for a separate request and widen the filter to `dns or tcp or udp.port == 443`. Do not guess from a blank capture.

**Recall:** Why does a packet to a remote server use the gateway’s MAC address?

**Reference answer:** The host uses its subnet and route table to decide the destination is remote. It resolves the next-hop gateway’s link-layer address using ARP for IPv4, then sends the frame to that gateway. The remote server remains the IP destination unless translation changes it.

### Session 2: IPv4 without panic

**Understand:** A prefix length splits network and host bits. /24 leaves 8 host bits: 256 total addresses, conventionally 254 usable. /26 leaves 6: 64 addresses per subnet. Practise finding the containing block before calculating usable ranges. /31 point-to-point links and /32 host routes are special cases.

**Worked example:** Worked /26: 192.168.10.77/26. Six host bits means blocks of 64 in the last octet: 0–63, 64–127, 128–191, 192–255. Since 77 sits in 64–127, network is .64, broadcast .127 and usual host range .65–.126. For /31 and /32, do not apply that ordinary host-range rule blindly.

**Follow along:**

1. Write the formula `block size = 256 − mask value in the changing octet`. For /26 the mask is 255.255.255.192, so block size is 64.
2. Locate the block containing an address before calculating anything else. Try 10.24.6.201/27: /27 is 255.255.255.224, block size 32; 201 belongs to 192–223. Write network, broadcast and usual hosts.
3. Check: network 10.24.6.192; broadcast .223; hosts .193–.222. If you missed it, repeat with .65/27 and .254/27.
4. Allocate a /25 for 100 hosts and a /27 for 25 hosts from 10.40.8.0/24. Start with the larger subnet. Write the unused space.
5. Test one answer by assigning two addresses inside it to lab hosts, then ping. Change one mask intentionally and explain why communication changes.

**Expected result:** For the allocation, a valid answer is 10.40.8.0/25 (126 usual hosts) and 10.40.8.128/27 (30 usual hosts). The next free /27 block begins at 10.40.8.160. There are other valid placements that do not overlap.

**If stuck:** If results differ, write the mask in decimal and list each block boundary. Check whether you calculated a network address or assigned a host address. Ping failure also depends on firewall and topology; it does not by itself disprove the subnet arithmetic.

**Recall:** For 192.168.10.77/26, what are the network, broadcast and usual host range?

**Reference answer:** A /26 advances in blocks of 64. Network: 192.168.10.64. Broadcast: 192.168.10.127. Usual hosts: .65 through .126. Do not optimise for speed until the method is reliable.

### Session 3: Switching, VLANs and ARP

**Understand:** A switch learns source MAC addresses per VLAN. A VLAN is a separate Layer 2 broadcast domain. An access port normally carries one VLAN; a trunk carries multiple tagged VLANs with platform-specific native-VLAN behaviour. Communication between VLANs requires routing.

**Worked example:** Worked example: A and B are in VLAN 10 on different switches. The trunk between the switches carries VLAN 10 and 20. A’s ARP broadcast remains in VLAN 10; it crosses the trunk tagged for VLAN 10. C in VLAN 20 never receives it. A and C need a router or Layer 3 switch to exchange IP packets.

**Follow along:**

1. In Packet Tracer, add two switches and three PCs. Cable A and B to different switches, C to the second switch. Give A=192.168.10.10/24, B=.11/24 and C=192.168.20.10/24.
2. Create VLANs 10 and 20 on both switches. Put A and B access ports in VLAN 10, C’s port in VLAN 20. Configure the inter-switch link as a trunk that allows both. Save `show vlan brief` and `show interfaces trunk` outputs.
3. Ping A→B. It should work. Ping A→C. It should fail until you add routing and gateways for both VLANs. Explain why an ARP broadcast cannot supply that routing.
4. Remove VLAN 10 from the trunk allowed list. Ping A→B again. Inspect trunk output and switch MAC tables before fixing it. Restore VLAN 10 and retest.
5. Draw the forwarding path for a same-VLAN packet and for an inter-VLAN packet. Mark where the source/destination MACs change.

**Expected result:** A→B should succeed with VLAN 10 on the trunk and fail when it is removed. A→C needs inter-VLAN routing, matching gateway settings and any required policies. Cisco commands vary by simulator/device; inspect the actual interface names.

**If stuck:** If A→B fails before the deliberate break, check link lights, IP/mask, access VLAN on both ports, trunk state/allowed VLANs, spanning-tree state and ARP. If A→C unexpectedly works, inspect whether the simulator has routing or bridge configuration you did not account for.

**Recall:** Two hosts in the same VLAN cannot communicate across a trunk. What do you check?

**Reference answer:** Verify addressing, link state, access-port VLANs, trunk state and allowed VLANs, spanning-tree forwarding state, MAC learning and ARP. Compare both ends and test one hypothesis at a time before changing configuration.

### Session 4: TCP, UDP and the first capture

**Understand:** TCP provides an ordered byte stream with acknowledgements and retransmission. SYN, SYN-ACK and ACK establish a normal connection. UDP does not provide those delivery guarantees. A TCP connection can succeed while the application fails; separate transport success from application success.

**Worked example:** Compare two captures. If a client sends SYN and receives RST, something actively refused the TCP connection. If SYN repeats unanswered, a firewall, path, host or return route may be dropping it. If the handshake completes then the server sends HTTP 500, transport worked and the application failed.

**Follow along:**

1. Start a harmless listener in a lab (`python3 -m http.server 8080` on Linux/macOS, or another available local web server). Visit it and capture `tcp.port == 8080`. Label SYN, SYN-ACK, ACK, request and response.
2. Stop the listener and connect again. Capture the reset/refused behaviour. Record who sent the RST.
3. Try an unused address in your isolated lab. Limit the test duration. Compare retransmitted SYNs or ICMP errors with the refused connection.
4. In Wireshark follow one TCP stream. Find any retransmission and inspect sequence/acknowledgement numbers. Do not call every duplicate ACK packet loss without context.
5. Draw where an application error would appear after a successful transport connection.

**Expected result:** Successful local server: TCP handshake, HTTP request and HTTP response. Closed local port: typically RST or a connection-refused error. An unreachable target may produce no reply or ICMP depending on topology and firewall.

**If stuck:** No packet capture? Capture loopback for a loopback listener, or bind the server to a lab interface and use that interface. On Windows, loopback capture support varies. Avoid public address probing for this lesson.

**Recall:** How do a reset and repeated unanswered SYNs change your investigation?

**Reference answer:** A reset suggests an active rejection by an endpoint or intermediary. Unanswered SYNs can indicate filtering, loss, a missing return route or an unavailable host. Neither alone identifies the exact cause; compare captures, routes and firewall logs.

### Session 5: DNS, DHCP and a troubleshooting habit

**Understand:** DNS resolves names; DHCP supplies address configuration. A lease can include gateway and resolver settings. Diagnose from a concrete symptom: one user or everyone, one name or all names, recent change or longstanding issue. Separate name resolution, connectivity, TLS and application behaviour.

**Worked example:** Example: `https://app.example.test` fails, but `curl http://192.0.2.10/` returns something. That does not prove “DNS broken”: the hostname may resolve to another IP, or the app may require the HTTP Host header, TLS SNI and a matching certificate. Ask one question per test.

**Follow along:**

1. Write the failure chain: application → name resolution → route → transport → TLS → HTTP → backend. Mark which step each test probes.
2. Run `nslookup example.com` twice and note resolver, A and AAAA answers. Compare the returned IP to the one you are testing.
3. Use `curl -vI https://example.com` and read the DNS, connection, certificate and HTTP stages. Record the first stage that fails; do not paste the whole output as your conclusion.
4. In a lab, break only the client’s DNS resolver and repeat. Restore it. Then break only the default gateway and repeat. Write how the symptoms differ.
5. Report a one-paragraph ticket: who is affected, target, time, exact symptom, tests with results and next discriminating test.

**Expected result:** Bad resolver: lookup often fails before any TCP connection. Bad gateway: local DNS might still work if the resolver is local, but off-subnet connections fail. A TLS certificate mismatch is a later failure after DNS and TCP.

**If stuck:** If `curl` or `dig` is missing, use `nslookup` plus browser developer tools and OS network status. If there is a corporate proxy, VPN or DoH browser setting, write it down; it may change the observed path.

**Recall:** An app works by IP but not by hostname. Is DNS definitely broken?

**Reference answer:** DNS is a leading hypothesis, but verify resolution and returned addresses. Host headers, virtual hosting, SNI and certificate name validation also differ when using an IP. Compare those layers instead of declaring DNS guilty from one test.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Explain a packet journey and diagnose simple addressing, switching and DNS faults with notes available first. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 2: Rebuild your defender foundations

Phase: Foundation reset

**Gate:** Navigate Linux and Windows evidence, explain TLS and authentication basics, and identify your actual weak areas.

Reference: [Microsoft Sysmon guide](https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon)

### Session 1: Linux essentials, hands on

**Understand:** Revisit users, groups, permissions, processes, services, sockets and logs. Read-only commands such as id, ps, ss, systemctl status and journalctl answer different questions. An open port is evidence of a listener, not proof that the remote path works.

**Worked example:** Example: `systemctl status ssh` says active, but remote clients fail. `ss -lntp` shows `127.0.0.1:22`. The service is running yet bound only to loopback. A remote packet addressed to the host’s LAN IP cannot reach that listener. This is a different fault from a host firewall block.

**Follow along:**

1. On a Linux VM run `id`, `ps -ef | head`, `ss -lntp`, `systemctl --type=service --state=running` and `journalctl -b -p warning --no-pager | tail`. Explain one question each answers.
2. Pick a noncritical service in your lab. Note its PID, listener address/port, config file and last 20 journal lines.
3. Start a temporary server with `python3 -m http.server 8080 --bind 127.0.0.1`. Check `curl -I http://127.0.0.1:8080`; compare with access from another VM to the VM’s LAN IP.
4. Restart the same test server bound to the lab interface address, then test again. Stop it when finished.
5. Write a diagnosis using listener, firewall, route and journal evidence in that order.

**Expected result:** A loopback-bound server answers local requests but not direct requests to the LAN IP from another host. A LAN-bound server becomes reachable only if the network path and host firewall permit it.

**If stuck:** If another VM still fails, inspect `ss`, local `curl` to the LAN IP, `nft list ruleset` or the distro firewall, then routes and packets on both hosts. Do not disable the firewall globally as a shortcut.

**Recall:** A Linux service is running but clients cannot connect. What next?

**Reference answer:** Check the listening address and port with ss, local requests, host firewall, network path and service logs. A loopback-only listener will not accept remote traffic. Establish where traffic stops before restarting things.

### Session 2: Windows essentials, hands on

**Understand:** Revisit processes, services, scheduled tasks, registry persistence and Event Viewer. An event ID only makes sense with its provider and channel. Security events depend on audit policy; Sysmon events depend on installation and configuration.

**Worked example:** Example: an analyst asks for “Event ID 1”. Windows Security ID 1 is not Sysmon process creation. You must name provider and channel: Microsoft-Windows-Sysmon/Operational, Event ID 1. Similarly, Security 4688 is process creation only when process-creation auditing is enabled, and command-line fields need separate settings.

**Follow along:**

1. Open Event Viewer. Locate Windows Logs → Security and Applications and Services Logs → Microsoft → Windows → Sysmon → Operational if Sysmon is installed. Write each full channel name.
2. Start Notepad or another benign app. Find its process in Task Manager, parent where visible, user and start time. Search Sysmon Event 1 or Security 4688 within a small time window; note which is present.
3. Create and delete a harmless scheduled task in a lab using Task Scheduler. Search Security 4698 and Task Scheduler Operational events. Check relevant audit settings if missing.
4. Compare the process fields: PID, parent, command line, hash and process GUID where available. Avoid pretending any event always has every field.
5. Record the audit/Sysmon configuration needed to reproduce your observation.

**Expected result:** The app should appear as a process. Whether 4688, Sysmon 1 or 4698 appears depends on Windows version, audit policy and Sysmon configuration. Absence is a finding to investigate, not proof the action did not happen.

**If stuck:** If Sysmon is absent, use Security 4688 with suitable audit policy for this lesson and add Sysmon later in the isolated VM. Never apply a community Sysmon config to an employer system without approval.

**Recall:** Why might an expected event be missing even though an action happened?

**Reference answer:** The relevant audit category or provider may be disabled, filters may exclude it, the event may live on another host/channel, or retention/collection may have lost it. Validate source generation before blaming a detection rule.

### Session 3: TLS, certificates and VPN recall

**Understand:** TLS authenticates peers and protects application traffic. Certificate validation includes trust chain, hostname and validity dates. In TLS 1.3, much of the handshake after ServerHello is encrypted. A passive capture does not automatically expose application content or the server certificate.

**Worked example:** Example: visiting `https://wrong.host` while the server presents a certificate for `right.host` may establish TCP and negotiate TLS, yet hostname validation fails. A trustworthy CA signature does not make the wrong hostname acceptable.

**Follow along:**

1. Draw the sequence: DNS address → TCP (or QUIC) reachability → TLS ClientHello → server response → certificate validation → encrypted HTTP. Mark that TLS 1.3 encrypts much of the later handshake.
2. In a browser open a public HTTPS site and inspect the certificate subject, SANs, issuer and validity dates. Note the exact hostname you visited.
3. Run `openssl s_client -connect example.com:443 -servername example.com -brief` if OpenSSL is available, then `curl -vI https://example.com`. Identify the point at which certificate validation is reported.
4. In a disposable lab, present a certificate with a mismatched hostname. Observe the browser/curl error without bypassing it.
5. Explain separately what TCP success proves and what a valid certificate chain plus hostname proves.

**Expected result:** A valid site should show a certificate chain trusted by the client, a matching name, valid dates and an HTTP response after TLS. A mismatch should be rejected even if TCP succeeds.

**If stuck:** If the certificate appears to be issued by a company proxy, you may be seeing TLS interception. Do not disable validation; document the intermediary and test only within your permitted lab.

**Recall:** A TCP connection works but HTTPS fails. Which evidence matters?

**Reference answer:** Check hostname/SNI, certificate chain and trust, validity dates and client time, protocol compatibility and TLS alerts. Successful TCP only establishes transport reachability. Proxy interception can also alter the trust path.

### Session 4: Identity, AD and authentication

**Understand:** A domain centralises identities and policy. Kerberos typically uses tickets issued by a domain controller; NTLM uses challenge-response. Authentication proves an identity; authorisation determines its permissions. DNS and time are important dependencies for a working AD environment.

**Worked example:** Example: Alice enters a correct domain password and gets a Kerberos ticket. She still cannot read a shared folder because the share/NTFS permissions do not grant her group access. Authentication succeeded; authorisation failed. A password change cannot fix the permission decision.

**Follow along:**

1. Draw user → workstation → domain controller → file server. Mark DNS queries and ticket requests. Locate where each system has relevant logs.
2. If you have a lab domain, sign in as a normal user and access one permitted share, then one denied share. Record the host, account, logon type and timestamps.
3. Check `whoami /groups` on the client and the resource’s share/NTFS permissions. Correlate with DC and file-server Security logs, using exact channels and audit settings.
4. If you do not have AD hardware, use a supplied Windows authentication dataset. Reconstruct the identity and access decision without installing a domain.
5. Write two sentences: one proving identity was accepted, the second explaining access denial.

**Expected result:** Authentication success does not guarantee access. For a real lab, a successful sign-in and denied share access should have distinct evidence and causes.

**If stuck:** If events do not line up, check time synchronisation, DNS/DC discovery, host and user identifiers, audit policy and whether the access used cached or alternate credentials.

**Recall:** What is the difference between authenticating and being authorised?

**Reference answer:** A valid credential or ticket can establish identity while access is still denied by permissions or policy. Investigate authentication results separately from group membership, resource ACLs and applicable access policy.

### Session 5: A gentle baseline, after revision

**Understand:** Now assess what revision restored. Use three levels: explain the idea, demonstrate it, troubleshoot an unfamiliar variation. Treat a miss as a scheduling signal. You are assessing the next useful practice, not judging your previous experience.

**Worked example:** This is an open-book-to-closed-book transition. You do not need every port or event ID memorised. You do need a reliable method for a basic fault. Example: “site fails” → first ask whether name resolution, TCP or TLS is the first failing stage; test each and state the next step.

**Follow along:**

1. Without notes, solve 192.168.10.77/26 and explain why its gateway must be reachable on the local subnet. Check against Week 1 Day 2.
2. Use an unseen hostname in your lab. Resolve it, identify next hop, make a connection and state whether TLS was reached.
3. In a short sample PCAP, find a DNS query and one TCP stream. Cite frame numbers and distinguish observation from inference.
4. Find one Windows or Linux event you generated. Name its provider/source, host, account, time and logging prerequisite.
5. Score yourself 0–2 for accuracy, reasoning, evidence and communication. Schedule a new variant for anything below 2.

**Expected result:** A pass is a complete reasoning chain and reproducible evidence, not perfect speed. Any missing prerequisite goes in the weak queue before its dependent work.

**If stuck:** If a lab setup blocks the exercise, use the included worked examples and a training capture/log dataset. Record the setup failure separately from the knowledge question so you repair the right problem.

**Recall:** When is it reasonable to move beyond revision?

**Reference answer:** When you can explain the common flow and complete a small unfamiliar task without a walkthrough. Move on with a recorded weak list; revisit blocking fundamentals before dependent labs. Perfect recall of every detail is not required.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Navigate Linux and Windows evidence, explain TLS and authentication basics, and identify your actual weak areas. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 3: Routing and network operations

Phase: Network practice

**Gate:** Diagnose routing and switching faults and justify a safe fix and rollback.

Reference: [Cisco network labs](https://www.netacad.com/courses/packet-tracer)

### Session 1: Routes, next hops and return paths

**Understand:** Revisit longest-prefix matching, connected/static/default routes and administrative preference. Forward and return traffic can follow different paths.

**Worked example:** A route for 10.2.3.0/24 beats a default route for traffic to 10.2.3.9 because it is more specific. The reverse flow from 10.2.3.9 still needs its own route back; neither side learns that automatically.

**Follow along:**

1. Build three routers and two endpoint LANs in Packet Tracer. Record all interface addresses and directly connected routes before adding anything.
2. Add a forward static route but deliberately omit one return route. Ping end to end, then inspect both route tables with `show ip route` and test each hop.
3. Add the return route and repeat. Remove the more specific route and predict whether the default route takes over; verify the actual next hop.
4. Write a two-column trace of outbound and return paths. Mark any stateful firewall or NAT point that depends on seeing both directions.

**Expected result:** The one-way route should prevent complete communication. After return routing is restored, the flow should work if policies and host gateways are correct.

**If stuck:** If pings still fail, check host gateways, interface state, ACLs and whether each intermediate router knows both destinations. A routing table entry alone does not prove packets traverse the link.

**Recall:** Why can the forward route be correct while the connection fails?

**Reference answer:** Replies still need a valid return path. Asymmetric paths may also cross a stateful firewall lacking session state. Check both directions and any translation.

### Session 2: OSPF in a small topology

**Understand:** Revisit neighbours, areas, router IDs, costs and DR/BDR on applicable network types. Learn neighbour states in the context of actual failure evidence.

**Worked example:** Two OSPF routers on the same link agree on area and compatible parameters before they become neighbours. If one interface is in area 0 and the other in area 1, they do not simply “sort it out”.

**Follow along:**

1. Build two routers on one subnet. Give both interfaces IPs and enable OSPF in the same area. Verify interface reachability before debugging OSPF.
2. Run `show ip ospf neighbor` and `show ip ospf interface`. Identify router IDs, area and neighbour state; then verify a learned route.
3. Change one side to a different area. Observe adjacency loss and any log. Restore it. Separately test a safe MTU mismatch in the lab.
4. Explain which observation was a transport/addressing issue and which was an OSPF compatibility issue.

**Expected result:** A healthy two-router adjacency should reach Full and exchange routes when topology and network type permit it. A deliberate area mismatch should prevent formation.

**If stuck:** If the adjacency fails before any deliberate change, check IP/mask, interface state, OSPF enabled on correct interface, area, hello/dead timers, network type, authentication and multicast reachability.

**Recall:** Why might OSPF neighbours remain in ExStart or Exchange?

**Reference answer:** Possible causes include MTU mismatch, duplicate router IDs or packet exchange problems. Inspect adjacency state, interface parameters and packet evidence instead of assuming one cause.

### Session 3: IPv6 and dual-stack reality

**Understand:** Learn link-local and global addresses, prefix notation, NDP, router advertisements and SLAAC. IPv6 does not use ARP. Dual-stack applications may choose a different address family than your manual test.

**Worked example:** IPv6 link-local addresses begin with fe80:: and work only on a link. A host can learn a prefix/router by Router Advertisement and resolve a neighbour’s link-layer address with NDP. None of this uses ARP.

**Follow along:**

1. On a dual-stack lab host inspect `ip -6 addr` and `ip -6 route` or Windows `ipconfig /all` and `route print -6`. Find a link-local address and default route.
2. Run `ping -6` to a reachable lab host and capture ICMPv6. Locate neighbour solicitation/advertisement and router advertisement if present.
3. Query A and AAAA answers for an allowed hostname. Connect once with `curl -4 -vI` and once with `curl -6 -vI`; record which family succeeds.
4. Break only the IPv6 route in an isolated lab, then repeat. Restore it and explain why a browser might seem intermittent.

**Expected result:** IPv4 and IPv6 tests may follow different routes and produce different failures. An AAAA answer does not prove IPv6 connectivity.

**If stuck:** If there is no IPv6 infrastructure, use a supplied dual-stack PCAP to identify NDP and RA. Do not disable or modify your real network adapter just to create a fault.

**Recall:** IPv4 works but the browser hangs. What could dual stack explain?

**Reference answer:** DNS may return an AAAA record and the client may attempt an impaired IPv6 path. Compare family-specific connections, routes, DNS answers and captures before disabling IPv6.

### Session 4: MTU, retransmissions and performance

**Understand:** Distinguish latency, loss, throughput and application delay. Path MTU and TCP MSS affect packet sizing; a blocked control message can hide a path problem.

**Worked example:** A 1500-byte LAN path plus VPN overhead may need a lower packet size inside the tunnel. Small ICMP messages can pass while larger TCP transfers stall; that points to, but does not prove, a path MTU problem.

**Follow along:**

1. Use a training PCAP with a slow transfer. Add display filters `tcp.analysis.retransmission` and `icmp`; compare packet sizes and time gaps.
2. In a lab tunnel or reduced-MTU link, send small then larger payloads. Record where packets stop and whether ICMP “fragmentation needed” or IPv6 Packet Too Big appears.
3. Compare TCP MSS on the SYN with observed payload sizes. Verify one successful small and one failing large request before changing settings.
4. Restore the MTU and repeat. Summarise alternative causes such as packet loss or server delay.

**Expected result:** A genuine MTU black hole should correlate failure with packet size and path, not just elapsed time.

**If stuck:** If symptoms do not depend on size, examine loss, latency, retransmissions, application processing and proxy behaviour. Do not treat every retransmission as MTU evidence.

**Recall:** Small pings work but larger transfers stall. What do you investigate?

**Reference answer:** Investigate MTU/fragmentation and path-MTU discovery, tunnel overhead and blocked ICMP messages, while checking loss and application behaviour. Small packets alone do not validate the full path.

### Session 5: Operational hygiene and safe changes

**Understand:** Revisit STP/RSTP, EtherChannel and first-hop redundancy. Add NTP, SNMP, syslog, interface counters, configuration backups and rollback planning. Keep BGP conceptual unless your target roles require depth.

**Worked example:** A safe network change has a baseline and a way back. For example, before modifying a trunk, save its current allowed VLANs and confirm two test flows. After the change, test both expected and forbidden traffic.

**Follow along:**

1. Choose one small lab change: trunk allowlist, route preference or firewall object. Save the running config and record current connectivity.
2. Write the exact commands, expected effect, rollback commands and a time-bound rollback trigger before applying the change.
3. Apply it once, validate positive and negative flows and inspect syslog/interface counters. Trigger rollback if a stated check fails.
4. Explain the outcome to a colleague in one paragraph, including what you actually observed.

**Expected result:** The final evidence should include before/after tests and either a successful change or a proven rollback.

**If stuck:** If you cannot establish a baseline, stop the lab change. Fix monitoring or capture first; otherwise you cannot tell whether you improved or broke the service.

**Recall:** What belongs in a network change plan?

**Reference answer:** Scope and dependencies, baseline evidence, exact steps, expected impact, validation, rollback trigger and commands, ownership and communication. Confirm restored service after rollback.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Diagnose routing and switching faults and justify a safe fix and rollback. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 4: Firewalls, VPNs and packet evidence

Phase: Network practice

**Gate:** Build and test a segmented service and diagnose a VPN or firewall failure.

Reference: [OPNsense documentation](https://docs.opnsense.org/)

### Session 1: Stateful policy and segmentation

**Understand:** Use zones, least privilege, rule order and clear logging. Allowing a source/destination pair is not enough: direction, service, state and translation matter.

**Worked example:** For web→app→database, allow only web to app on its actual port and app to database on its actual port. “Deny all other inter-zone traffic” needs negative tests: a direct web→database connection should fail even if the web service works.

**Follow along:**

1. Create three isolated lab networks/zones and one host per zone. Write the required source, destination, port and direction for each allowed flow.
2. Add the minimum firewall rules. For each allowed flow, run a connection test and inspect a matching log or capture.
3. Test at least three forbidden flows, including web→database and database→web initiation. Capture the deny decision.
4. Disable one allow rule, predict the precise failure, observe it, then restore the rule.

**Expected result:** Two required flows succeed and the forbidden flows fail. A working webpage alone cannot prove segmentation.

**If stuck:** If a forbidden connection succeeds, check rule order, default policy, same-zone paths, aliases and NAT. If a required flow fails, check service listener and return traffic before broadening the policy.

**Recall:** What evidence proves a segmentation policy works?

**Reference answer:** Positive tests for required flows, negative tests for prohibited flows, matching logs and captures, and validation in both directions. A screenshot of rules alone proves configuration, not behaviour.

### Session 2: NAT and asymmetric traffic

**Understand:** Revisit SNAT, DNAT and PAT. Firewalls differ in where policy evaluation sees original versus translated addresses. Learn the chosen platform’s packet flow.

**Worked example:** DNAT maps an incoming address/port to an internal service. The firewall still has to permit traffic according to its platform’s rule-evaluation order; the server must listen and reply through a valid route.

**Follow along:**

1. On an isolated firewall, publish a test web server on a chosen external port. Record the public and translated address/port.
2. From outside the lab zone, attempt the connection. Inspect firewall session/log output and packet captures on both sides.
3. Remove only the server’s return route or block the return path. Repeat and locate the last observable packet.
4. Restore the route. Explain each address/port translation and which policy matched.

**Expected result:** The ingress packet is translated, reaches the service, and a reply returns through the firewall for the successful case.

**If stuck:** If DNAT appears correct but the server sees nothing, check upstream reachability and policy. If server responds but client times out, inspect return route, NAT state and asymmetric paths.

**Recall:** A DNAT rule exists but the service is unreachable. What do you check?

**Reference answer:** Inbound reachability, original/translated addresses, policy evaluation order, listening service, route and return path, plus session and packet evidence. NAT does not necessarily imply an allow rule.

### Session 3: VPNs you can troubleshoot

**Understand:** Revisit IPsec IKEv2 exchanges, authentication, proposals, traffic selectors, routing and NAT traversal. Separate tunnel establishment from protected data flow.

**Worked example:** An IKEv2 IKE SA can establish while the intended data flow fails because Child SA selectors, routes or firewall policy are wrong. Treat control-plane “up” and application reachability as separate questions.

**Follow along:**

1. Use two isolated lab peers or a vendor tutorial. Record peer addresses, credentials, proposals, selectors and expected protected subnets.
2. Establish the IKE SA. Observe IKE_SA_INIT and IKE_AUTH in logs or capture; record whether a Child SA exists.
3. Test one permitted host-to-host flow and inspect encrypt/decrypt counters on both ends.
4. Break one selector or route, repeat the flow, locate the last good stage and restore it.

**Expected result:** A healthy tunnel has negotiated SAs plus successful protected traffic and counters increasing in the expected direction.

**If stuck:** If negotiation fails, inspect authentication/proposals/time. If negotiation succeeds but data fails, inspect selectors, routes, firewall rules, NAT exemption, MTU and return path.

**Recall:** The tunnel is up but traffic does not pass. What next?

**Reference answer:** Check Child SAs, selectors, routes, firewall rules, NAT exemptions and return paths. Compare encryption/decryption counters and captures. An established IKE SA does not prove the intended application flow.

### Session 4: Useful packet filters

**Understand:** Separate capture filters (BPF) from Wireshark display filters. Captures have a vantage point and may omit important traffic. Start with time, endpoints and protocol.

**Worked example:** Capture filter `host 192.0.2.10 and port 53` is BPF applied before packets are saved. Wireshark display filter `ip.addr == 192.0.2.10 and dns` hides rows after capture. If capture filter removed packets, a display filter cannot recover them.

**Follow along:**

1. Capture a short DNS and web session without a capture filter. Save the original PCAP.
2. Apply display filters for DNS, TCP resets and a single stream. Record three frame numbers that support a specific conclusion.
3. Recapture using a BPF filter for one host. Compare file size and which packets are irretrievably absent.
4. Write the capture point/interface and any packet-drop count next to your finding.

**Expected result:** Changing a display filter does not change the saved packet set; changing a capture filter does.

**If stuck:** If evidence is missing, check NIC/interface, direction, tunnel, span port, filter, drop counters and timestamp range before claiming traffic never existed.

**Recall:** Can the absence of packets in a capture prove no traffic occurred?

**Reference answer:** Only within the capture’s visibility and reliability. Check interface, span/tap setup, direction, capture filter, timestamps, packet drops and whether the traffic traversed that point.

### Session 5: Network interview rehearsal

**Understand:** Review DNS, HTTP, TLS, proxies, load balancers, WAF, Wi-Fi/802.1X and DDoS at explanation level. Prioritise diagnosis over product lists.

**Worked example:** In a mock incident, “the app is down” is too broad. One test each for resolution, route, TCP, TLS and HTTP turns it into a bounded fault. Your answer should state the next test and why.

**Follow along:**

1. Have a friend choose one lab failure from DNS, routing, firewall or VPN, or randomly select from your previous labs without looking at its answer.
2. State scope: one user or many, one host or many, one location or many. Capture the exact error.
3. Run at most one discriminating test per hypothesis. Record result, revised hypothesis and safe fix.
4. Give a five-minute handover with evidence, uncertainty, validation and rollback.

**Expected result:** A strong answer is a justified fault location and a verified restoration, or a precise next step when evidence is insufficient.

**If stuck:** If you get stuck, return to packet direction and visibility. Do not change multiple layers at once.

**Recall:** How do you avoid changing five things during an outage?

**Reference answer:** State one hypothesis, select the smallest discriminating test, record the result and make one justified change. Preserve a baseline and rollback path; escalate when evidence or authority is insufficient.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Build and test a segmented service and diagnose a VPN or firewall failure. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 5: Build dependable host telemetry

Phase: Defender foundation

**Gate:** Generate, collect and interpret Windows/Linux events, including a deliberately broken collection path.

Reference: [Wazuh getting started](https://documentation.wazuh.com/current/getting-started/index.html)

### Session 1: A lab that survives mistakes

**Understand:** Use isolated VMs, snapshots and benign test data. Inventory the Windows client, Linux host, collector and network paths. Record versions and a restore procedure.

**Worked example:** A lab diagram should say exactly where logs come from. For example: Windows VM → Sysmon Operational → Wazuh agent → manager decoder/rule → indexer → dashboard. If the alert is missing, test each link.

**Follow along:**

1. Inventory VMs, versions, IPs, time settings and snapshot names. Draw log transport paths before installing more tools.
2. Generate one benign Windows event and one Linux event; confirm them locally first.
3. Find the same events in the collector and compare source time to ingest time.
4. Restore a snapshot and verify you can reproduce at least one event.

**Expected result:** Both events are visible locally and centrally with expected identities and times.

**If stuck:** If the central event is missing, inspect agent health, firewall/port, manager ingestion, parsing and dashboard time window in order.

**Recall:** Why record software versions and logging configuration?

**Reference answer:** Event fields, defaults and rule support vary by version and configuration. Reproducible tests need those details to distinguish a detection problem from an environment change.

### Session 2: Windows Security logs

**Understand:** Revisit 4624/4625 logons, 4672 special privileges, 4688 process creation and 4698 scheduled tasks in the Security channel. Pair IDs with useful fields and audit prerequisites.

**Worked example:** Windows Security 4625 describes a failed logon, but the account, status/substatus, source address and logon type determine the story. Ten failures from a known service after a password change differ from spraying across many accounts.

**Follow along:**

1. Enable/verify appropriate audit policy in a lab; generate one good and one bad logon.
2. Filter the Security channel for 4624 and 4625. Record account, workstation, source, logon type, status and timestamp.
3. Start a benign process and find 4688 if enabled. Note whether command-line data is present.
4. Correlate a later success to the same account/source; write two benign and one suspicious explanation.

**Expected result:** Events appear only with the relevant logging configured. The later success alone does not establish compromise.

**If stuck:** If 4688 is absent, inspect Audit Process Creation policy; if its command line is absent, inspect the separate command-line policy. Check collector filters before rewriting detections.

**Recall:** Does 4624 following 4625 prove compromise?

**Reference answer:** No. Correlate account, host, source, logon type, time and normal behaviour. A user correcting a password can produce the same sequence; seek supporting evidence and scope.

### Session 3: Sysmon and PowerShell evidence

**Understand:** Revisit Sysmon 1, 3, 7, 10, 11 and 13; add DNS event 22 where configured. PowerShell 4104 is script-block logging in its own provider/channel. Collection needs deliberate configuration.

**Worked example:** Sysmon Event 1 records process creation and uses ProcessGuid for correlation. Event 3 covers network connection only when enabled. Event 10 (ProcessAccess) may help investigate LSASS access but needs careful noise filtering.

**Follow along:**

1. Install Sysmon only in a lab with a reviewed config. Record version, config hash and included/excluded rules.
2. Generate a benign process, file write and network request. Find Event 1, 11 and 3 where configured; compare fields.
3. Create a harmless PowerShell command and look for PowerShell Operational 4104 only if script-block logging is enabled.
4. Confirm which of those events reached Wazuh and which did not. Write the missing prerequisite for each gap.

**Expected result:** The chosen config determines which events appear. Sysmon ID 7 and 10 can be noisy; do not enable everything without a reason.

**If stuck:** If local event exists but Wazuh lacks it, check collection path. If local event is absent, check provider/audit configuration and exclusions before changing Wazuh rules.

**Recall:** What makes Sysmon ProcessGuid useful?

**Reference answer:** It helps correlate events for a particular process instance across event types. A PID alone can be reused. Check timestamps, host and provider context as well.

### Session 4: Linux logs and persistence

**Understand:** Follow authentication logs/journal, service changes, cron and auditd. Know what is collected by default on your distribution and what requires rules.

**Worked example:** A cron entry is a persistence mechanism only in context. A known backup job and an unknown script both appear as scheduled tasks; file owner, path, command, creation time and process history distinguish them.

**Follow along:**

1. Create a harmless cron or systemd timer on a Linux VM that writes a timestamp to a file. Record where you placed it.
2. Inspect the unit/cron entry, journal and resulting file. Find the execution identity and process.
3. Remove it, verify it no longer executes, and check whether the collector saw the related logs.
4. Write a short investigation note that distinguishes observed persistence from malicious intent.

**Expected result:** You should be able to point to the schedule, command, execution and output. Whether central logs exist depends on configured collection.

**If stuck:** If no event is generated centrally, confirm local logging and the collector rule/path. Do not call absence of logs absence of execution.

**Recall:** How do you investigate an unfamiliar scheduled job?

**Reference answer:** Identify owner, command, file path, creation/change evidence and execution history; compare with approved administration. Scope related processes and network activity before deciding it is malicious.

### Session 5: Break the ingestion path

**Understand:** Telemetry health is part of detection. Trace source generation, collection, transport, parsing, indexing and query time range. Check clock skew, event time and ingestion time.

**Worked example:** The path is source → agent → transport → decoder → indexer → query. If a dashboard graph falls to zero, a source outage and a collector outage can look identical until you test upstream.

**Follow along:**

1. Record a normal five-minute event count for one harmless lab source.
2. Stop only the lab agent or collector. Generate three known events and record local timestamps.
3. Observe central silence; then restore the component and check which events backfill and which are lost.
4. Create a health check: expected heartbeat/source count, allowable delay and who investigates a gap.

**Expected result:** Local events remain visible while central events stop. Recovery behaviour depends on buffering/retention settings.

**If stuck:** If the dashboard still shows events, verify their event and ingest timestamps. They may be delayed old data rather than new healthy collection.

**Recall:** A detection suddenly goes quiet. What do you check before calling it success?

**Reference answer:** Source activity and logging, agent health, transport, parser/schema changes, filters, indexing and time windows. Silence may indicate missing telemetry rather than reduced risk.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Generate, collect and interpret Windows/Linux events, including a deliberately broken collection path. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 6: AD and network monitoring

Phase: Defender foundation

**Gate:** Correlate host, identity and network evidence without treating one indicator as proof.

Reference: [Zeek log reference](https://docs.zeek.org/en/current/logs/index.html)

### Session 1: A small AD environment

**Understand:** Revisit domain users/groups, GPO, DNS and Kerberos. A joined client and domain controller make authentication evidence concrete.

**Worked example:** A client needs DNS to locate domain services and a reasonably synchronised clock for Kerberos. A joined client’s logon can involve the workstation, domain controller and target server; one log stream rarely tells the whole story.

**Follow along:**

1. In an isolated AD lab or supplied dataset, record client, DC and server names and time zones.
2. Sign in as a standard user and access a share. Find relevant events on DC and destination server.
3. Change a harmless group membership or GPO in the lab and locate the audit event if policy permits it.
4. Draw an evidence map: authentication request, ticket activity, resource access and policy change.

**Expected result:** Events should line up by user/host/time, though different providers record different stages.

**If stuck:** If logon fails, inspect DNS/DC discovery and clock first. If you lack hardware, analyse a provided dataset instead of spending days building a domain.

**Recall:** Where should you look for Kerberos ticket activity?

**Reference answer:** Domain-controller Security logs with appropriate auditing, alongside client/server logons and endpoint evidence. Event location and collection prerequisites matter as much as the ID.

### Session 2: Credential attacks in context

**Understand:** Compare password spraying, pass-the-hash, pass-the-ticket and Kerberoasting by prerequisites, action and observable evidence. Avoid expecting one universal event signature.

**Worked example:** Password spraying = few candidate passwords across many accounts. Pass-the-hash = using NTLM credential material rather than a plaintext password. Kerberoasting = requesting service-ticket material to attack offline. Each has different prerequisites and telemetry.

**Follow along:**

1. Create a four-row comparison for spraying, pass-the-hash, pass-the-ticket and Kerberoasting: prerequisite, attacker goal, primary logs and benign overlap.
2. In a provided dataset, count failed accounts per source over a time window. Check whether one source is a shared proxy or scanner.
3. Trace one suspicious success to later host activity; do not stop at the logon event.
4. Write one detection hypothesis and one blind spot for each technique.

**Expected result:** You should produce evidence for breadth of accounts, credential/ticket behaviour or correlated post-auth activity rather than one universal event ID.

**If stuck:** If the source IP is missing or shared, pivot on account, host, logon type and time. A single IP cannot always represent a single actor.

**Recall:** Why is password spraying different from brute forcing one account?

**Reference answer:** Spraying tries a small number of passwords across many accounts, often slowly. Detection needs breadth across identities and time, with context for shared IPs and legitimate failures.

### Session 3: Zeek as a network notebook

**Understand:** Use conn, dns, http, ssl and files logs as available. Correlate connection identifiers, endpoints, duration, byte counts and timestamps. Encrypted traffic limits content visibility.

**Worked example:** Zeek conn.log is a connection summary. Its uid links to protocol logs such as dns.log or http.log. Repeated connections at near-regular intervals can suggest beaconing but can also be software updates.

**Follow along:**

1. Run Zeek on a training PCAP in your lab. Record the capture timezone and Zeek version.
2. Pick one DNS query and its uid, then find matching connection and any application log. Write a timeline with original row references.
3. For one repeated destination, calculate intervals between starts and compare bytes/duration. Identify one legitimate competing explanation.
4. List what encryption hides and what endpoint log could resolve uncertainty.

**Expected result:** A correlated timeline should retain source/destination, time, uid and evidence. Zeek may not produce every protocol log for every flow.

**If stuck:** If uids do not match, confirm files came from the same run/PCAP and check protocol detection. Do not join events on IP alone across a long time window.

**Recall:** What would make repeated connections worth investigating?

**Reference answer:** Regular timing, unusual destinations, rare process/domain context, consistent sizes or unexpected hours can support a hypothesis. Updaters and monitoring also repeat; periodicity alone is not proof of C2.

### Session 4: Suricata and flow evidence

**Understand:** Read rule headers/options and EVE JSON. Distinguish signature alerts from flow context. NetFlow/IPFIX provides summaries, not full packet payloads.

**Worked example:** Suricata EVE JSON separates alert details from flow and protocol fields. An alert is a signature match; a flow record gives context such as direction and bytes. Neither automatically proves compromise.

**Follow along:**

1. Run Suricata on a training PCAP. Save rule set version and EVE output.
2. Choose one alert. Read signature ID, source/destination, protocol and time. Locate the corresponding packets.
3. Inspect response traffic and any host evidence. Decide whether it shows attempt, delivery or effect.
4. Write a false-positive explanation and one better validation test.

**Expected result:** You should be able to trace the alert to packet evidence and state whether success is established.

**If stuck:** If no alert fires, check rules loaded, capture type, checksum settings, variables/home network and whether the training traffic matches that rule version.

**Recall:** Does an IDS alert prove successful exploitation?

**Reference answer:** No. It may match an attempt, test, benign overlap or incomplete transaction. Inspect packet content, response and host evidence to determine success and scope.

### Session 5: Your first PCAP case report

**Understand:** Use a fixed report: question, time range, sources, timeline, evidence, assessment, uncertainty and next actions. Keep factual observations separate from interpretations.

**Worked example:** A good PCAP report begins with a question, not a claim. Example: “Was this host contacting a suspicious external server between 10:00 and 10:30?” Observations cite frames; interpretations state confidence.

**Follow along:**

1. Open one malware-traffic-analysis training PCAP. Record hash, capture window, host IPs and your question.
2. Build a short timeline: DNS, connection, HTTP/TLS, file indicators if visible. Cite frame numbers for each fact.
3. Consider NAT, proxies, clock and encryption limitations. State what endpoint evidence would change your judgement.
4. Write a one-page report: summary, evidence table, assessment, uncertainty and next action.

**Expected result:** Another analyst should be able to open the same file, locate your frame references and reproduce the core assessment.

**If stuck:** If you cannot identify the infection or intent, report the bounded observations and unknowns; do not invent a story to make the report feel complete.

**Recall:** How should you report a likely malicious connection with incomplete visibility?

**Reference answer:** State the observed facts and confidence, explain the suspicious pattern and alternative explanations, name missing evidence, and propose the next collection or investigation step.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Correlate host, identity and network evidence without treating one indicator as proof. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 7: SOC investigation and response

Phase: Blue-team practice

**Gate:** Triage unfamiliar cases and produce useful escalation notes, including benign dispositions.

Reference: [NIST incident response guidance](https://csrc.nist.gov/pubs/sp/800/61/r3/final)

### Session 1: From alert to decision

**Understand:** Revisit alert versus incident, severity versus priority, asset importance and scope. Use NIST SP 800-61 Rev. 3 and CSF 2.0 for current response framing.

**Worked example:** An alert is a signal. An incident is a decision that activity requires coordinated response. A malware alert on an isolated lab host has a different priority from the same evidence on a domain controller or payment system.

**Follow along:**

1. Open a training alert and record who/what/when, original evidence and detection logic.
2. Confirm whether the underlying event happened. Check the host/account importance and whether the activity continued or spread.
3. Write one benign and one malicious explanation. Run one test that distinguishes them.
4. Set a provisional severity and next owner. Note what would make you raise or lower it.

**Expected result:** Your ticket should separate observation, interpretation, impact and action.

**If stuck:** If the alert has sparse context, validate source telemetry and seek asset/identity context before assigning certainty.

**Recall:** What makes an alert high priority?

**Reference answer:** Credible activity, potential/observed impact, affected asset and identity importance, spread, urgency and available context. A tool’s severity label is an input, not the entire decision.

### Session 2: Phishing triage

**Understand:** Inspect headers, routing, sender authentication, URLs and attachments. SPF/DKIM/DMARC outcomes need context and do not establish harmless content.

**Worked example:** SPF checks authorised senders, DKIM validates a signed message and DMARC aligns those results with the visible sender domain. Passing all three does not prove the sender account or content is benign.

**Follow along:**

1. Use a training phishing email, not a live risky attachment. Save the original headers.
2. Identify From, Reply-To, Return-Path, Received chain, SPF/DKIM/DMARC results and embedded destinations.
3. Check whether the message was delivered, opened or clicked using training evidence. Defang indicators in notes.
4. Write a decision: user guidance, search for similar messages, account/session checks and containment as warranted.

**Expected result:** A strong report distinguishes delivery from user interaction and content from sender authentication.

**If stuck:** If header dates or hops conflict, look for time zones and forwarding. Do not upload private mail to public scanners without permission.

**Recall:** An email passes SPF, DKIM and DMARC. Can it still be phishing?

**Reference answer:** Yes. An attacker can use an authenticated domain or a compromised account. Inspect identity, content, destination, user interaction and related activity.

### Session 3: Endpoint process trees

**Understand:** Trace parent/child relationships, command lines, signer/hash context, user, time and network connections. A legitimate binary can be abused.

**Worked example:** A normal process tree has context. Office spawning a PDF viewer might fit a document workflow; Office spawning a shell that downloads a script needs closer investigation. Neither process name alone proves intent.

**Follow along:**

1. In a training case, list process, parent, child, command line, user, host and time.
2. Find the earliest suspicious ancestor and follow children and network/file events by process identifier.
3. Check whether the binary, path and command are common for the host and user. Seek one independent corroborating event.
4. Draw the tree and write what happened, what remains uncertain and what you would collect next.

**Expected result:** The final tree should show an evidence-backed sequence rather than a list of “bad” binary names.

**If stuck:** If parent PID seems impossible, consider PID reuse; prefer ProcessGuid and bounded timestamps when available.

**Recall:** Why is a signed binary not automatically safe?

**Reference answer:** Signing supports publisher/integrity checks but does not establish benign intent. Legitimate tools can execute attacker-controlled commands or load malicious content; context and behaviour are essential.

### Session 4: Scope and containment

**Understand:** Determine affected accounts, hosts and time range. Preserve evidence while choosing actions proportionate to urgency and authority. Consider operational impact and restoration.

**Worked example:** Containment is a decision with costs. Isolating a workstation may stop spread, but cutting a critical server can disrupt care or business. Decide with incident severity, scope, ownership and evidence preservation in mind.

**Follow along:**

1. Choose a training compromised-account case. List affected identities, hosts and the time window.
2. Write two immediate options: revoke sessions/reset credentials or temporarily restrict access. State what each stops and may miss.
3. Identify evidence to preserve first where time permits: relevant logs, volatile context and original alerts.
4. Write an escalation to the owner plus a recovery validation plan.

**Expected result:** The decision should have a trigger, rationale, owner, expected effect and verification.

**If stuck:** If impact and authority are unclear, escalate quickly while taking reversible evidence-preserving steps available to your role.

**Recall:** Why not immediately wipe every suspicious host?

**Reference answer:** Wiping destroys useful evidence and can interrupt operations without addressing the entry point or broader compromise. Urgent isolation may be justified; preservation, scoping and recovery should be deliberate.

### Session 5: Triage under a time limit

**Understand:** Use unfamiliar lab cases, including a false alarm. Practise concise handover: what happened, evidence, impact, actions taken, unknowns and next owner.

**Worked example:** A useful handover answers: what fired, what you verified, what is affected, what you did and what the next analyst should do. “Investigate further” without a specific lead is weak.

**Follow along:**

1. Select two unseen training cases, one benign and one requiring escalation if possible.
2. Set 30 minutes per case. Build a timeline and scope using only available evidence.
3. Write a disposition and confidence, with citations to source events. Give a five-minute spoken handover.
4. Compare with case notes and mark each unsupported claim or missed decision point.

**Expected result:** Both cases should end in defensible next actions, not necessarily a perfect label.

**If stuck:** If you run out of time, state the highest-risk unresolved question and the next discriminating check.

**Recall:** What makes an escalation useful to the next analyst?

**Reference answer:** A clear question and severity rationale, affected entities/time range, evidence links, queries performed, actions already taken, unresolved hypotheses and explicit next steps.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Triage unfamiliar cases and produce useful escalation notes, including benign dispositions. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 8: One query language, properly

Phase: Blue-team practice

**Gate:** Use Microsoft Kusto KQL to filter, summarise and correlate security data; keep SPL as a later translation option.

Reference: [Microsoft KQL learning path](https://learn.microsoft.com/en-us/training/paths/sc-200-utilize-kql-for-azure-sentinel/)

### Session 1: Kusto foundations

**Understand:** Microsoft Kusto KQL is different from Kibana KQL. Begin with a table, time window, where filters and project. Inspect the real schema rather than assuming field names.

**Worked example:** Kusto starts with a table then pipes. Example: `SigninLogs | where TimeGenerated > ago(1d) | where ResultType != 0 | project TimeGenerated, UserPrincipalName, IPAddress`. The exact schema depends on the data source.

**Follow along:**

1. Open the Microsoft Learn KQL tutorial or a permitted Sentinel sample workspace. Inspect a few raw rows of the chosen table.
2. Write a query that limits time first, filters one account or result, and projects five useful fields.
3. Change the time range and explain why zero rows may reflect ingestion or schema rather than “no attack”.
4. Write the query from memory on a fresh dataset, then compare with docs.

**Expected result:** The query should return only the intended window/identity and named columns.

**If stuck:** If it fails, run just the table name, inspect column names/types, then add one pipe at a time. Do not paste Wazuh or Elastic KQL syntax into Kusto.

**Recall:** Why inspect schema and a sample event before writing the full query?

**Reference answer:** Field names, types and semantics vary by source and connector. A syntactically valid query can return misleading or empty results if it filters the wrong fields or types.

### Session 2: Count, group and baseline

**Understand:** Use summarize, count, dcount and bin to describe activity over time. Counts need context: population size, source coverage and usual behaviour.

**Worked example:** Example: 100 failed sign-ins from one IP can be one noisy user, a shared proxy or a spray. `summarize Failures=count(), Accounts=dcount(UserPrincipalName) by IPAddress, bin(TimeGenerated,1h)` gives shape, not verdict.

**Follow along:**

1. Filter a sample failed-sign-in table to a bounded day.
2. Group by source IP and hourly bin. Add count and distinct accounts; inspect the top results.
3. Pick one source and drill down to account, success/failure and device/user-agent context.
4. Write a two-sentence assessment that names the shared-IP limitation.

**Expected result:** The grouped count should reconcile with raw rows for the same filter.

**If stuck:** If totals inflate, check duplicate ingestion, joins and whether failed-result values were filtered correctly.

**Recall:** Why can one busy IP create a misleading password-spray alert?

**Reference answer:** A NAT gateway, proxy or shared service may represent many legitimate users. Correlate identities, outcomes, timing and normal patterns before treating the source as one attacker.

### Session 3: Correlate without fooling yourself

**Understand:** Use joins with deliberate keys, time bounds and join kinds. Many-to-many matches can multiply results. Missing data is different from a negative result.

**Worked example:** A join on username alone can pair yesterday’s endpoint process with today’s login. Add host and time context, and check for many-to-many multiplication.

**Follow along:**

1. Prepare two small sample tables or training datasets: logons and process events with overlapping user names.
2. Count each input and join on the best available stable identity plus host. Restrict each side to a relevant time window.
3. Compare output count to inputs; inspect a few matched pairs manually for temporal plausibility.
4. Remove one join condition and observe how false pairings multiply. Restore it.

**Expected result:** The final query should produce fewer, explainable pairs than a broad username join.

**If stuck:** If no stable key exists, describe the correlation as tentative and include other evidence instead of forcing a join.

**Recall:** What can go wrong when joining events on username alone?

**Reference answer:** Different domains, machines and time periods can share a name, creating unrelated matches and inflated counts. Use stable identifiers and bounded temporal/entity context.

### Session 4: Parse and onboard a source

**Understand:** Revisit JSON/dynamic values, extraction and normalisation. Document event time, source identity, required fields and collector health. Learn CIM/ECS at concept level.

**Worked example:** A detection asking for `process.command_line` fails if the collector only stores a raw message or uses a different field name. Field mapping is part of the detection, not cleanup after it.

**Follow along:**

1. Generate one known lab event and find its raw local record.
2. Trace it into Wazuh, note arrival time and inspect its parsed JSON fields and types.
3. Map the original process/user/host/time values to stored fields. Record any absent field.
4. Run a simple query for that exact event and write a source-onboarding note with a volume/health check.

**Expected result:** The source event and indexed event should correspond in identity and time; important fields should be queryable.

**If stuck:** If a field is missing, inspect source config and parser before adding a rule that assumes it exists.

**Recall:** How do you validate a new log source?

**Reference answer:** Generate known events, confirm arrival and timestamps, inspect parsed types/fields, check volume and gaps, validate identity mapping, and test a concrete use case against raw evidence.

### Session 5: Queries from investigation questions

**Understand:** Begin with an investigative question, then translate it into fields, filters, aggregation and correlation. Hand-write the first attempt; use docs to repair it, then repeat unaided.

**Worked example:** Start with an investigation question such as “Which accounts failed from one source before a successful sign-in?” Convert it to required tables, fields, time window, filters and joins, then write Kusto.

**Follow along:**

1. Write five concrete questions from your lab: failures, new processes, rare destinations, service changes, host timeline.
2. For each, list source table and minimum fields before touching query syntax.
3. Hand-write a query, execute it, compare at least one row to the raw event, then record assumptions.
4. Rewrite one query from memory after a break using different entity values.

**Expected result:** Each query should answer its named question and identify its coverage limits.

**If stuck:** For zero results, widen time, verify source arrival, inspect schema and remove filters one by one.

**Recall:** A query returns zero results. What does that establish?

**Reference answer:** Only that the query matched nothing in the selected data and time range. Verify ingestion, schema, filter logic, timestamps, permissions and expected source events before concluding absence of activity.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Use Microsoft Kusto KQL to filter, summarise and correlate security data; keep SPL as a later translation option. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 9: Build five defensible detections

Phase: Detection practice

**Gate:** Deliver five tested detections with benign cases, required telemetry, tuning and documented limitations.

Reference: [Sigma documentation](https://sigmahq.io/docs/guide/getting-started.html)

### Session 1: Hypothesis before YAML

**Understand:** Write the behaviour you want to detect, affected entities, required data and likely benign matches. ATT&CK mapping explains relevance but does not prove coverage.

**Worked example:** “Detect credential theft” is too vague. “Alert when an unusual process opens LSASS with rights consistent with memory access on a workstation” names behaviour, source, target and likely benign overlap.

**Follow along:**

1. Pick five concrete behaviours that your current lab can actually generate and log.
2. For each, write hypothesis, required provider/channel and fields, malicious test, benign test and analyst action.
3. Check one raw event from each required source before writing the rule.
4. Rank by relevance to target roles and available data; keep five, defer the rest.

**Expected result:** A rule idea is feasible only if the needed telemetry is present and correctly parsed.

**If stuck:** If a source field is absent, change instrumentation or choose another behaviour. Do not simulate coverage by tagging an ATT&CK ID.

**Recall:** What should exist before a detection rule?

**Reference answer:** A concrete behaviour hypothesis, available telemetry with verified fields, expected malicious and benign examples, intended response and known blind spots.

### Session 2: Sigma and the actual backend

**Understand:** Sigma expresses detection logic; deployment needs a compatible backend and correct field mappings. Wazuh manager XML and indexer Sigma workflows differ: pin your lab version.

**Worked example:** Sigma is a portable description, not a guarantee of identical execution. A selector on `Image|endswith: powershell.exe` depends on correct backend field mapping and modifier support.

**Follow along:**

1. Write a small Sigma rule for a benign lab behaviour, including logsource, detection and false-positive notes.
2. Convert or import it using the backend appropriate for the pinned Wazuh version or a supported search backend.
3. Inspect the generated query/rule. Map every field back to an actual stored event.
4. Generate the behaviour and verify event, parsed field, rule match and alert end to end.

**Expected result:** You should be able to show both the Sigma source and the actual executable rule/query plus a firing event.

**If stuck:** If conversion succeeds but no alert fires, inspect field mapping and backend semantics before changing the hypothesis.

**Recall:** Does successful rule conversion prove correct detection?

**Reference answer:** No. Validate schema mappings, supported modifiers/conditions, query semantics, actual telemetry and positive/negative cases in the deployed backend.

### Session 3: Test malicious and benign cases

**Understand:** Use controlled training activity only in your isolated lab. An Atomic test running is not proof of an alert. Check activity → event → collection → parse → match → alert.

**Worked example:** A positive test that fires on “powershell.exe” proves only that the string matched. A benign administrator doing routine work might fire too. Test both and document why a true case should remain after tuning.

**Follow along:**

1. For two rules, write exact positive and benign input events plus expected outcomes before running them.
2. Run controlled activity in the isolated lab or replay a permitted dataset.
3. Trace each outcome through source event, agent, parser, rule and alert. Capture event IDs and query results.
4. Tune one condition and rerun all four cases. Keep the before/after evidence.

**Expected result:** The rule should match intended cases and avoid at least the tested benign overlap.

**If stuck:** If activity occurs but no source event exists, fix collection. If the event exists but no alert, fix mapping or rule logic. Keep those failure types separate.

**Recall:** Why include a benign test for a detection?

**Reference answer:** It tests whether similar legitimate behaviour creates noise and whether tuning changes the intended discrimination. Positive tests alone can reward a rule that matches everything.

### Session 4: Tune with evidence

**Understand:** Scope allowlists by the narrowest justified conditions and owner. Distinguish precision from recall; unknown missed attacks prevent reliable real-world recall estimates.

**Worked example:** Ten true and ninety false alerts give precision 10%. Recall cannot be computed without knowing missed true cases. A noisy alert can be narrowed by process lineage, user, path or signed-tool context, but each exclusion can hide attacks.

**Follow along:**

1. Label 20 sample matches from a lab rule as relevant or benign with evidence.
2. Calculate sample precision; state why this is not necessarily production precision or recall.
3. Add one narrow suppression or threshold, naming the benign case it handles.
4. Replay malicious and benign cases and record which outcomes changed.

**Expected result:** The tuning change should reduce measured noise while preserving your known positive test.

**If stuck:** If you cannot explain an allowlist’s owner and boundary, do not add it. Investigate the recurring benign workflow first.

**Recall:** A rule produces 10 true and 90 false alerts. What is precision, and can you calculate recall?

**Reference answer:** Precision is 10/(10+90) = 10%. Recall needs the total actual positives, including missed ones; alert counts alone cannot provide it.

### Session 5: Detection as code, minimally

**Understand:** Use Git history, readable rule metadata, validation and reproducible tests. Assign an owner/review date and document expected action. Reuse an existing repository.

**Worked example:** A detection repository is useful when another person can reproduce a result. A rule without source prerequisites, test data and response advice will quietly fail as telemetry changes.

**Follow along:**

1. Pick five tested rules. For each, document behaviour, log source/config, fields, ATT&CK link, test command/data and expected alert.
2. Put the source rules, sample events and one small validation command in Git.
3. Run validation and a clean replay from a fresh checkout or VM snapshot.
4. Add review date and one known blind spot to each rule.

**Expected result:** A reviewer should know exactly how to make each rule fire and one situation it misses.

**If stuck:** If a rule depends on a private proprietary source, document its schema with safe synthetic samples rather than exposing employer logs.

**Recall:** What makes a detection maintainable?

**Reference answer:** Clear purpose, field/source dependencies, test cases, false-positive guidance, response instructions, ownership and review history. A rule title and ATT&CK tag are not enough.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Deliver five tested detections with benign cases, required telemetry, tuning and documented limitations. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 10: Investigate endpoint and AD cases

Phase: Detection practice

**Gate:** Explain common identity attacks and investigate evidence without relying on one magic event ID.

Reference: [MITRE ATT&CK](https://attack.mitre.org/)

### Session 1: Credential access evidence

**Understand:** Revisit LSASS process access, dumps, suspicious callers and context. Sysmon 10 can provide process-access evidence when configured; legitimate tools may also access processes.

**Worked example:** Sysmon ProcessAccess Event 10 can show one process opening another, including LSASS. A diagnostic tool can do the same. Evaluate caller, access rights, lineage and surrounding file/network events.

**Follow along:**

1. In a training dataset, find all events targeting lsass.exe in a bounded hour.
2. Group by caller, host and user. Compare expected security tools to unusual callers.
3. For one suspicious caller, build a process tree and look for dump-file creation or follow-on logons.
4. Write a detection with at least one benign test and a configuration prerequisite.

**Expected result:** Your assessment should explain why context changes confidence, not claim Event 10 itself proves theft.

**If stuck:** If Event 10 is absent, confirm Sysmon config before abandoning the hypothesis. Do not enable high-volume telemetry indiscriminately on production.

**Recall:** Why is LSASS process access alone insufficient proof of credential theft?

**Reference answer:** Access can be legitimate, and access events do not necessarily show successful extraction. Correlate caller, rights, command line, file creation, user context and subsequent authentication activity.

### Session 2: Kerberos attacks and prerequisites

**Understand:** Compare Kerberoasting and AS-REP roasting, then pass-the-ticket and golden tickets. Tie each to account configuration, keys/tickets and available DC/endpoint evidence.

**Worked example:** Kerberoasting targets service-ticket material tied to a service principal; AS-REP roasting targets accounts without Kerberos pre-authentication. The difference changes both the misconfiguration to look for and the relevant DC evidence.

**Follow along:**

1. Make two columns: prerequisite, requested ticket/message, offline attack goal and hardening action.
2. Use safe training logs to find a suspicious service-ticket request and compare it to normal application access.
3. Check account context, source host, timing and volume rather than one event ID alone.
4. Write what evidence would support or weaken a credential attack assessment.

**Expected result:** The comparison should correctly distinguish service-account ticket requests from no-preauth account AS replies.

**If stuck:** If you only have a written scenario, still trace the authentication flow; do not run offensive tools on a real domain.

**Recall:** What separates Kerberoasting from AS-REP roasting?

**Reference answer:** Kerberoasting targets service-ticket material associated with service accounts; AS-REP roasting targets accounts without required Kerberos pre-authentication. Detection and hardening depend on different prerequisites and evidence.

### Session 3: Replication and privilege abuse

**Understand:** Understand DCSync as abuse of directory replication privileges. Treat DCShadow as awareness unless a target role requires deeper work. Investigate permissions and origin.

**Worked example:** DCSync abuses directory replication rights. Expected DC-to-DC replication is normal; an unusual user or workstation invoking replication operations is the signal to investigate.

**Follow along:**

1. In a training case, identify the principal, origin host and time of replication-related activity.
2. Check whether the principal had replication rights and whether the origin is an expected DC.
3. Search nearby privilege changes, remote execution and authentication events.
4. Write scope and containment recommendations that preserve evidence.

**Expected result:** A well-scoped finding identifies why the requester was unusual and what data/privileges were at risk.

**If stuck:** If directory-service auditing is absent, say so and use available privilege/host evidence. Do not equate every replication event with compromise.

**Recall:** Why is the origin of replication activity important?

**Reference answer:** Expected domain-controller replication differs from replication requests by an unusual host or identity. Validate authorised topology and rights before treating replication itself as malicious.

### Session 4: Persistence and ransomware timelines

**Understand:** Revisit services, scheduled tasks, startup locations and account changes. Investigate a chain of activity: entry, execution, access, lateral movement and impact.

**Worked example:** Encryption is often the last visible stage of ransomware. An earlier process, account or remote-access event may explain entry and spread. Recovery needs to address that path as well as restore files.

**Follow along:**

1. From a supplied case, order entry, execution, credential access, lateral movement, exfiltration and encryption when evidence exists.
2. For each stage, cite a source event and distinguish missing evidence from no activity.
3. Propose urgent containment, then recovery tests for identity, hosts, backups and monitoring.
4. Write a short business-impact summary without unsupported claims.

**Expected result:** The timeline and remediation should cover more than the final file-encryption alert.

**If stuck:** If stages cannot be established, keep them unknown; do not fill a dramatic kill chain from assumptions.

**Recall:** Why is a ransomware investigation broader than encrypted files?

**Reference answer:** The intrusion may include credential theft, persistence, lateral movement and exfiltration before encryption. Recovery needs scope and entry-point remediation as well as restoring data.

### Session 5: Hypothesis-driven hunting

**Understand:** A hunt starts with a testable hypothesis and available data, not a list of search terms. Record methods, negative findings and visibility limits.

**Worked example:** A hunt hypothesis might be: “An attacker used remote administration from a user workstation outside normal admin hosts.” The hunt needs a time range, asset baseline, data sources and a result criterion.

**Follow along:**

1. List approved admin hosts/tools in an isolated or sample environment.
2. Query network/endpoint logs for the relevant remote-admin protocols from unexpected sources.
3. Inspect the top anomalous cases for user, process and target context.
4. Report matches, negative findings, coverage gaps and one detection improvement.

**Expected result:** A valid hunt may find nothing, but it must show what data/time it covered and which hypothesis was tested.

**If stuck:** If there is no baseline, build one from known-good inventory or clearly label the comparison provisional.

**Recall:** What is a useful outcome when a hunt finds nothing?

**Reference answer:** A bounded negative result, verified data coverage, documented queries and limitations, plus any telemetry or detection improvements. Do not claim the environment is clean beyond that scope.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Explain common identity attacks and investigate evidence without relying on one magic event ID. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 11: Cloud identity and response

Phase: Response practice

**Gate:** Investigate one cloud identity case and prioritise remediation using exposure and evidence.

Reference: [Microsoft Entra monitoring](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/overview-monitoring-health)

### Session 1: Read cloud logs in context

**Understand:** Distinguish Entra sign-in/audit logs, Azure Activity logs and resource-specific logs. Retention, licences and collection settings affect availability. Keep AWS CloudTrail/GuardDuty at awareness level.

**Worked example:** Entra sign-in logs describe identity access; Azure Activity records control-plane changes; a storage account’s data access may need its own resource logs. Searching only one of those sources can miss the action you care about.

**Follow along:**

1. Use a permitted sample tenant or Microsoft Learn dataset. Inspect one sign-in, one identity audit change and one resource control-plane action.
2. For each event, record actor, target, action, outcome, time and log source.
3. Write the question each log can answer and one data-plane question it cannot.
4. Check retention/collection prerequisites for your tenant before writing a detection.

**Expected result:** You should identify distinct identity, control-plane and data-plane evidence needs.

**If stuck:** If sample data is unavailable, use documentation examples and create a table of required fields; do not incur cloud charges just to finish this session.

**Recall:** Why are Azure Activity logs not a complete record of every data access?

**Reference answer:** They principally describe control-plane activity. Resource data-plane operations require relevant service-specific logging. Identify the action and corresponding log source before searching.

### Session 2: MFA, tokens and suspicious consent

**Understand:** Revisit MFA, Conditional Access, sessions, application identities and consent grants. A valid session can still be abused; successful MFA does not rule out compromise.

**Worked example:** After a compromised account’s password is reset, active sessions or malicious app consent may remain. Scoping sign-ins, token/session changes, consent grants and mailbox rules is part of containment.

**Follow along:**

1. Read a safe training account-compromise case. Build a timeline of unusual sign-ins and identity changes.
2. Identify any MFA result, device, IP, app grant and mailbox configuration change. Do not treat “MFA passed” as a clean verdict.
3. Draft a containment sequence: preserve evidence, revoke sessions through the platform, reset credentials, review consent and recheck access.
4. List which actions need owner approval or operations coordination in a real environment.

**Expected result:** Your plan should address persistence beyond the password and specify how to verify access is restored safely.

**If stuck:** If the case lacks token data, name that visibility gap and avoid claiming the attacker could or could not reuse a session.

**Recall:** Why might a password reset alone fail to contain an account incident?

**Reference answer:** Existing sessions/tokens, malicious app grants, persistence or other compromised credentials may remain. Scope the identity and use platform-supported revocation and remediation as appropriate.

### Session 3: One useful response playbook

**Understand:** Define trigger, inputs, enrichment, human decision, action, failure handling and audit trail. Automate low-risk enrichment before disruptive containment.

**Worked example:** A phishing enrichment playbook can collect sender reputation and related messages, but if a lookup API fails, the original alert must remain visible. A failed lookup is “unknown”, never “benign”.

**Follow along:**

1. Define one trigger and the exact fields available from it.
2. Choose two low-risk enrichments, such as related-message count and known sender/domain context. Keep disruptive actions behind human review.
3. Run one normal case and one missing-field or failed-lookup case in a lab.
4. Write an audit note of inputs, outputs, errors and what the analyst should do next.

**Expected result:** Both cases should preserve original evidence; the failed enrichment should show an explicit unavailable state.

**If stuck:** If the workflow automatically closes on missing data, change the branch before considering it deployable.

**Recall:** What should happen when an enrichment API fails?

**Reference answer:** Preserve the original alert and evidence, mark enrichment unavailable, record the error and route to a safe fallback or human review. Do not treat lookup failure as a benign verdict.

### Session 4: Vulnerability prioritisation

**Understand:** CVSS describes severity, EPSS estimates exploitation probability, and CISA KEV identifies known exploited vulnerabilities. Add exposure, asset importance and compensating controls.

**Worked example:** CVSS 9.8 on an isolated test server may rank below a lower-scored vulnerability actively exploited on an internet-facing critical service. Use severity, exploit likelihood, known exploitation, exposure and business impact together.

**Follow along:**

1. Make a table of five fictional findings with CVSS, EPSS, KEV status, exposure, asset criticality and existing controls.
2. Rank them and explain the top two in two sentences each.
3. Assign owner and verification method for the top finding, then describe an exception review date if patching is delayed.
4. Compare your choices with CISA KEV and official vendor remediation guidance for a real example.

**Expected result:** The final ranking should be defensible with context rather than sorted by CVSS alone.

**If stuck:** If EPSS or KEV data is missing, state it as unknown; do not convert an absent flag into “not exploited”.

**Recall:** Should the highest CVSS score always be fixed first?

**Reference answer:** No. Active exploitation, reachability, asset impact and controls can make a lower-score issue more urgent. Use severity as one input and verify remediation.

### Session 5: Recovery and a clear incident report

**Understand:** Include summary, evidence-backed timeline, affected scope, decisions, containment, remediation, recovery tests and lessons. Map to controls only where useful.

**Worked example:** A recovery claim needs more than a quiet dashboard. Example: an attacker’s account is disabled, but the collector is offline; zero new alerts tells you nothing. Verify entry point, remediated identities, restored service and working telemetry.

**Follow along:**

1. Choose a completed identity or endpoint training case and outline impact and scope.
2. Write an evidence-backed timeline with key decision points and one missing evidence source.
3. List containment, eradication and recovery checks separately. Include a test proving collection is still healthy.
4. Prepare a five-minute analyst handover and a one-paragraph business summary.

**Expected result:** Another reader should be able to trace claims to evidence and see what was verified after recovery.

**If stuck:** If the case’s outcome is unknown, report “not verified” and specify the check needed; do not fill a template with invented closure.

**Recall:** How do you establish recovery beyond “the alert stopped”?

**Reference answer:** Verify the entry point is addressed, affected systems/identities are remediated, services restored safely and monitoring covers recurrence. Silence without working telemetry is not validation.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Investigate one cloud identity case and prioritise remediation using exposure and evidence. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 12: Connect the whole investigation

Phase: Consolidation

**Gate:** Complete a network-to-host case and present your existing projects with reproducible evidence.

Reference: [PCAP training exercises](https://www.malware-traffic-analysis.net/training-exercises.html)

### Session 1: Capstone: define the case

**Understand:** Use your existing firewall and Wazuh work. Define a benign simulation or training dataset involving a network observation and host/identity evidence.

**Worked example:** A capstone can connect DNS, network flow, endpoint process and an alert around one benign simulated event. Success is a reproducible investigation, not adding another tool.

**Follow along:**

1. Choose a narrow question such as “Which host made this unexpected DNS request, and which process caused it?”
2. Draw the existing lab topology and list exact required logs and timestamps.
3. Define one benign test action, expected records and clean-up steps.
4. Write pass criteria: evidence chain, one alternative explanation and a readable handover.

**Expected result:** You should have a one-page scope before generating or collecting evidence.

**If stuck:** If the required log does not exist, revise instrumentation or reduce the question; do not add multiple new platforms to salvage scope.

**Recall:** What keeps a capstone manageable?

**Reference answer:** One concrete investigation question, bounded sources/time, a reproducible setup and explicit evidence criteria. Reuse existing projects instead of adding unrelated features.

### Session 2: Capstone: gather evidence

**Understand:** Preserve originals, record time zones and note source limitations. Use consistent identifiers to correlate network and host data.

**Worked example:** A DNS record may show a client IP, a Zeek connection may show a NAT address and Sysmon may show the process on the original host. Correlation requires a time-bounded mapping, not assuming all IPs are identical.

**Follow along:**

1. Collect the capstone’s source records without editing originals. Record hashes/versions and time zones.
2. Extract a timeline with DNS query, network connection, endpoint process and any alert, citing source row or frame ID.
3. Check NAT/proxy mappings and event-time versus ingest-time differences.
4. Rerun the query from the raw data to see whether your timeline is reproducible.

**Expected result:** Every timeline row should point back to a record and use a consistent time reference.

**If stuck:** If correlation is ambiguous, record candidate matches and missing mapping evidence instead of assigning an arbitrary process.

**Recall:** How do you reconcile conflicting timestamps?

**Reference answer:** Check time zone, clock sync, event versus ingestion time, precision and source semantics. Document corrections and uncertainty rather than silently forcing a sequence.

### Session 3: Capstone: decide and respond

**Understand:** Test alternative explanations. State scope, confidence, containment recommendation and what further evidence would change your decision.

**Worked example:** Suppose the endpoint process is a known updater. That weakens a malicious hypothesis but does not prove safety: verify signer/path, expected destination and host baseline. A good decision includes alternatives and confidence.

**Follow along:**

1. List two plausible interpretations of the capstone observations.
2. For each, identify supporting evidence, contradictory evidence and one discriminating test.
3. Make a provisional triage decision and containment recommendation proportionate to confidence/impact.
4. Write an analyst handover plus a three-sentence nontechnical summary.

**Expected result:** The assessment should clearly separate facts, inference and uncertainty.

**If stuck:** If you cannot obtain a decisive test, make the next collection step explicit and preserve the case as inconclusive.

**Recall:** Why record alternative explanations?

**Reference answer:** It prevents premature closure and makes the reasoning reviewable. State what evidence supports or weakens each plausible explanation.

### Session 4: Portfolio, not project sprawl

**Understand:** Use the projects already listed in your original plan. Explain the problem, your contribution, how it works, validation and known limitations.

**Worked example:** A portfolio README for your existing firewall-diff or SIEM project should let a reviewer reproduce one useful result and understand one limitation. A screenshot with no data flow or test case is weak evidence.

**Follow along:**

1. Choose one existing project; describe problem, inputs, key flow and your own contribution.
2. Add a small architecture diagram, sample safe input, command or UI path, and expected output.
3. Reproduce the result from clean instructions. Record any environment dependency or known failure.
4. Review files for credentials, private hostnames and employer information before sharing.

**Expected result:** A stranger should be able to explain the project and reproduce the demonstration.

**If stuck:** If setup is long, provide a small sample mode rather than building a new showcase app.

**Recall:** What should you be able to explain about code on your résumé?

**Reference answer:** Its purpose, data flow, key design choices, failure handling, security boundaries, validation and your exact contribution. Be honest about assistance and unfinished parts.

### Session 5: Experience into interview stories

**Understand:** Prepare situation, task, actions and results using real experience. Separate professional work from lab simulations. Avoid invented metrics.

**Worked example:** “I improved firewall policy” is vague. “I found a shadowed rule, measured affected traffic, proposed a replacement, tested allowed/denied flows and prepared rollback” shows judgement. Keep results truthful and bounded.

**Follow along:**

1. Choose four real work situations: troubleshooting, incident, change and mistake/learning.
2. For each, write situation, responsibility, your action, evidence and result in five lines.
3. Rehearse a three-minute answer aloud. Have someone ask why you chose that action and what you would do differently.
4. Remove employer secrets and unsupported metrics; label lab examples as labs.

**Expected result:** The listener should know your exact contribution and how you verified the result.

**If stuck:** If you cannot share specifics, explain the general constraint and method without inventing numbers or claiming work you did not own.

**Recall:** What makes an experience answer credible?

**Reference answer:** Specific constraints, your decisions and evidence, clear ownership, actual outcomes and lessons. Do not claim team results or lab exercises as work you personally performed.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Complete a network-to-host case and present your existing projects with reproducible evidence. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 13: Close the gaps that matter

Phase: Consolidation

**Gate:** Retest priority weaknesses and use interview feedback to choose the next depth investment.

Reference: [KQL practice reference](https://learn.microsoft.com/en-us/training/paths/sc-200-utilize-kql-for-azure-sentinel/)

### Session 1: Repair your weakest network skill

**Understand:** Choose the highest-impact unresolved networking topic from reviews or interviews. Relearn only what the failed task exposed.

**Worked example:** Weakness repair should use an unfamiliar variant. If the original mistake was a missing return route, fixing the same topology from memory tests recall. A changed topology with a similar symptom tests transfer.

**Follow along:**

1. Open your saved weak queue and select the highest-impact network item.
2. Read its original error and the smallest piece of documentation needed.
3. Build or obtain a different scenario. Solve it without following the old steps.
4. Compare results, then write the new rule of thumb and one remaining blind spot.

**Expected result:** A pass is correct reasoning in the new situation, not faster replay of the old answer.

**If stuck:** If the variation still fails, return to the first unsupported assumption and practise that prerequisite before adding more topics.

**Recall:** How do you know remediation transferred beyond memorisation?

**Reference answer:** You can solve a changed example, justify the next test and explain the root cause without replaying the original walkthrough.

### Session 2: Repair your weakest investigation skill

**Understand:** Pick a gap in scoping, timelines, process trees, authentication or escalation. Use an unfamiliar case at comparable difficulty.

**Worked example:** A correct alert verdict can be luck. Rebuild the chain: original signal → corroborating event → scope → alternative explanation → decision. Missing links make a good label fragile.

**Follow along:**

1. Choose an unseen triage case in your weakest area.
2. Set a 45-minute limit. Track every query and evidence source as you go.
3. Write a timeline and disposition with confidence and missing evidence.
4. Compare to the case solution. Retest only the reasoning step you missed using another case.

**Expected result:** You should be able to defend each conclusion with a cited event or test.

**If stuck:** If the case dataset omits required evidence, state the limitation; do not fill it with intuition.

**Recall:** What if the final verdict is correct but the reasoning is weak?

**Reference answer:** Treat it as a gap. A lucky label does not demonstrate investigation skill; explain the chain of evidence and test competing explanations.

### Session 3: Repair your weakest query or detection

**Understand:** Inspect data before changing logic. Revisit failed joins, missing fields, overly broad rules or undocumented blind spots.

**Worked example:** A regression check is an event that previously produced the wrong outcome and now behaves correctly. Example: an allowlist once hid a malicious process; retain that malicious event and a benign counterpart when tuning.

**Follow along:**

1. Choose one previously failed query or detection.
2. Reproduce the original failure using saved safe input.
3. Change only the necessary field mapping, condition or join.
4. Run original, positive and benign checks again and save results.

**Expected result:** The old failure should now be corrected without breaking the relevant positive and benign cases.

**If stuck:** If a test only asserts the current rule text, replace it with an event and expected behaviour.

**Recall:** What is the smallest useful regression test?

**Reference answer:** A concrete input and expected outcome that reproduces the previous failure, with a relevant benign/negative case where needed. It should test behaviour rather than merely restate implementation.

### Session 4: Optional bridge: secure one pipeline

**Understand:** Do this only if the core gates pass and deployment basics are familiar; otherwise repeat a weak-topic lab. Reuse an existing repo. Add secrets, SAST and dependency/container checks before expanding to IaC or DAST.

**Worked example:** A minimal security pipeline fails when a safe test secret or vulnerable dependency is deliberately introduced, then passes after removal. Green badges with no exercised failure path are weak evidence.

**Follow along:**

1. First decide whether your core network/SOC gates pass. If not, repeat the weakest lab instead of starting DevSecOps.
2. If they pass, reuse an existing repo and add a secrets scan, SAST and dependency/container scan.
3. Introduce a harmless synthetic test finding on a branch. Confirm the expected job fails and explains why.
4. Remove the finding, rerun and document thresholds and exception owner.

**Expected result:** Either a new weak-topic pass or a verified pipeline gate is a complete session.

**If stuck:** If a scanner requires paid services or adds large setup cost, use existing tools and keep this optional bridge small.

**Recall:** What makes a scan gate useful beyond a green badge?

**Reference answer:** Meaningful scope and thresholds, actionable findings, controlled exceptions, safe secret handling and verified failure behaviour. Running tools without interpreting results is insufficient.

### Session 5: Target roles using actual feedback

**Understand:** Review recent suitable job descriptions and your application funnel. Choose one primary role narrative and one adjacent role. Certifications remain optional.

**Worked example:** A job description mentioning five technologies does not require equal time on all five. Repeated requirements across suitable roles and your own interview misses tell you where to spend the next week.

**Follow along:**

1. Review ten relevant roles in your desired location/seniority range. Count recurring skills, not one-off buzzwords.
2. Compare those requirements with your documented projects and work examples.
3. Update résumé claims only where you have evidence. Record applications and responses.
4. Choose one primary role narrative and one adjacent role to target.

**Expected result:** The next learning choice should follow repeated demand and observed gaps.

**If stuck:** If response rates are low without technical screens, adjust targeting and résumé clarity before adding another certification.

**Recall:** What should drive the next learning investment?

**Reference answer:** Repeated requirements and observed interview/practical gaps relative to the role you want, balanced against existing strengths. Do not expand into every technology mentioned once.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Retest priority weaknesses and use interview feedback to choose the next depth investment. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**

## Week 14: Demonstrate readiness

Phase: Interview readiness

**Gate:** Pass unfamiliar practical checks and explain your work clearly; carry remaining gaps into a focused next cycle.

Reference: [ATT&CK reference](https://attack.mitre.org/)

### Session 1: Network practical, unseen

**Understand:** Assess addressing, DNS, routing, firewall or VPN using a fault you did not just rehearse. Use a 45-minute investigation limit.

**Worked example:** In a live practical, a clear partial diagnosis is better than an unjustified fix. State what you know, what you ruled out and the next test with its expected outcomes.

**Follow along:**

1. Ask a peer to choose an unseen DNS, route, firewall or VPN fault, or use a fresh case you have not solved.
2. Work for 45 minutes. Record scope, topology, tests and results as you go.
3. Present fault location, validation/rollback or precise next step in five minutes.
4. Score accuracy, reasoning, evidence and communication 0–2 each; mark the weakest dimension.

**Expected result:** Aim for 7/8 with no zero. An inconclusive but well-bounded investigation can still score for method.

**If stuck:** If blocked by environment, state which tool/data is missing and how you would obtain it safely.

**Recall:** What is a strong answer when you cannot finish the diagnosis?

**Reference answer:** Explain what you verified, what evidence remains, your leading hypotheses, the next discriminating test and safe escalation. Do not invent certainty.

### Session 2: SOC practical, unseen

**Understand:** Investigate a new alert or dataset under time pressure. Include scoping and a concise disposition. Use the same 0–2 rubric across four dimensions.

**Worked example:** For an unfamiliar SOC case, do not force a malicious or benign label. A defensible conclusion can be “inconclusive, high impact if confirmed, escalate for endpoint evidence”.

**Follow along:**

1. Choose an unseen training alert and set a 45-minute clock.
2. Confirm the underlying event, scope related hosts/accounts and test an alternate explanation.
3. Write an escalation with evidence links, actions, risk and next owner.
4. Score the same four dimensions and retest the weakest one on a new case.

**Expected result:** The report should distinguish observed facts, inference and action.

**If stuck:** If key logs are absent, describe the collection gap and choose the safest decision consistent with impact.

**Recall:** When should a case remain inconclusive?

**Reference answer:** When available evidence cannot reliably distinguish plausible outcomes. State the limits, risk, required next evidence and escalation decision rather than forcing a benign/malicious label.

### Session 3: Project demonstration

**Understand:** Demonstrate one existing project from a clean starting point. Be ready to explain an implementation choice and a failure path.

**Worked example:** A project demo should start from a reproducible scenario. Show one input, run the actual flow, inspect output, then explain a failure mode. Avoid a slideshow of features.

**Follow along:**

1. From a clean checkout or lab snapshot, run the setup instructions for one existing project.
2. Demonstrate one useful result in 10 minutes using safe sample data.
3. Explain the data flow, trust boundary and test that proves the result.
4. Show one known limitation and the next check you would add if requirements changed.

**Expected result:** A reviewer should see the real system behave as described, not just screenshots.

**If stuck:** If setup fails, record the exact dependency and repair instructions; do not silently switch to a preconfigured machine.

**Recall:** How do you answer a question outside your project’s scope?

**Reference answer:** State the boundary honestly, explain what you know and propose how you would investigate or extend it. Avoid claiming unsupported production readiness.

### Session 4: Behavioural and technical mock

**Understand:** Practise an introduction, a troubleshooting story, an incident story and questions about trade-offs. Use unfamiliar follow-ups.

**Worked example:** A good interview answer is a trace of decisions: situation, what you tested, what evidence changed your hypothesis, what you did and how you verified. Memorising jargon does not replace that chain.

**Follow along:**

1. Run a 45-minute mock with technical and behavioural follow-ups for your primary role.
2. Record four answers: network fault, security case, project trade-off and mistake/learning.
3. Afterward, mark unsupported claims and places where you skipped verification.
4. Repeat the weakest answer with a changed follow-up question.

**Expected result:** The revised answer should be shorter, more specific and evidence-based.

**If stuck:** If no peer is available, record yourself and pause to challenge each conclusion: “What else could cause that?”

**Recall:** How do you discuss a mistake professionally?

**Reference answer:** Describe the context, your responsibility, how you detected and corrected it, its real impact and what changed to prevent recurrence. Avoid blame and invented success.

### Session 5: Next cycle, based on evidence

**Understand:** Review gates, completed artifacts, recall misses and application outcomes. Passing means demonstrated performance, not completing a calendar.

**Worked example:** The calendar ends; the skill loop continues. Use completed practical evidence, weak cards and job outcomes to choose a focused next cycle. A missed gate becomes a concrete task, not a reason to restart all 14 weeks.

**Follow along:**

1. List passed gates and attach one artifact to each.
2. Rank remaining gaps by job relevance and prerequisite importance.
3. Plan two weeks with three specific retests and one expected proof each.
4. Keep applications going and add a certification or DevSecOps only where it serves a target role.

**Expected result:** The next cycle should fit on one page and have observable pass conditions.

**If stuck:** If most misses are the same prerequisite, work on that root skill before adding more content.

**Recall:** What happens if you have not passed every gate after 14 weeks?

**Reference answer:** Keep completed evidence, prioritise the blocking gaps and extend the relevant practice. Continue suitable applications. The plan is a feedback loop, not a promise that every skill matures on a fixed date.

### Session 6: Review, repair & rehearse

**Understand:** No new material today. Revisit this week’s recall cards, repeat a failed practical task and explain one scenario aloud. Update your résumé with completed evidence, then take the next day off.

**Worked example:** Review is a coached retest, not another content dump. First explain two ideas from this week without notes, then solve a changed practical example. Score what your evidence supports.

**Follow along:**

1. Open this week’s five sessions. Pick the two recall answers you could not explain cleanly; answer them aloud before revealing their references.
2. Repeat one lab with a changed host, IP, source event or question. Write your prediction before running it and compare with the observed result.
3. Run a 20–30 minute mock: describe the problem, your first three tests, the actual evidence and a safe fix or escalation.
4. Score accuracy, reasoning, evidence and communication 0–2 each. Put any zero or repeated miss into next week’s review queue.

**Expected result:** Aim for at least 7/8 with no zero. A correct label without evidence is still a gap. Take day 7 off.

**If stuck:** If the lab will not run, use a supplied PCAP/log dataset and record the environmental blocker separately from the skill gap.

**Recall:** What did your evidence show you can do this week, and what still needs practice?

**Reference answer:** Use this week’s gate: Pass unfamiliar practical checks and explain your work clearly; carry remaining gaps into a focused next cycle. Cite a completed task or artifact, name remaining uncertainty and schedule one concrete retest. This is a self-assessment, not an automatically graded exam.

**Day 7: rest. No compulsory catch-up.**