Internal Network & Active Directory · intermediate · ~11 min
**What you will learn** - Define *lateral movement* and explain how an attacker turns one compromised host into many, heading toward high-value targets such as a Domain Controller (DC). - Identify the legitimate remote-administration channels that get abused for movement: SMB/PsExec-style execution, WinRM/PowerShell Remoting, RDP, and WMI. - Explain *pass-the-hash (PtH)* and *pass-the-ticket (PtT)* — authenticating with a stolen secret instead of a cleartext password — and why cracking is unnecessary. - Describe how *network segmentation* (default-deny east-west) and *tiered administration* contain a breach, and how an authorized tester **verifies** they actually hold. - Explain why lateral movement evades signature-based detection and what *behavioural* detection and authentication logging look for instead. - Apply defensive controls — LAPS, host firewalls, disabling unused protocols, least-privilege/just-in-time admin — and prove each one works.
Security objective. The asset we are protecting is the identity backbone of a Windows domain — the Domain Controllers and Tier 0 systems, plus the credentials, file servers, and backups behind them. The threat is an attacker who has already landed on one ordinary host (a phished laptop, an exposed service) and now tries to cross internal trust boundaries to reach those crown jewels. By the end of this lesson you will be able to detect that movement in logs and prevent most of it with segmentation and tiering — and, just as important, verify that your controls actually hold instead of assuming they do.
Imagine an intruder picks the lock on one office door. If every interior door is unlocked, that single break-in becomes access to the entire building. Lateral movement is the network version of that: an attacker who owns one machine uses the access they already have to reach a second machine, then a third, usually working toward a Domain Controller that holds the keys to the whole Active Directory domain.
This lesson sits directly on top of two prerequisites. In Password spraying, roasting, and credential reuse you saw how attackers obtain passwords, NTLM hashes, and Kerberos tickets. In RDP and SMB you saw the protocols themselves. Lateral movement is where those two threads meet: the attacker takes a stolen secret and feeds it into a legitimate admin protocol to authenticate somewhere new.
The counter-intuitive core idea is that lateral movement rarely uses "hacking tools" in the Hollywood sense. It uses the same SMB, WinRM, RDP, and WMI that real administrators use every day. That is exactly why it is hard to catch: abuse looks almost identical to legitimate remote administration.
The defensive half of the lesson is containment: splitting the network into zones so a breach in one zone cannot automatically reach every other zone, and keeping powerful credentials off low-trust hosts. A core deliverable of an authorized internal engagement is answering one blunt question for the customer: from this subnet, what can an attacker actually reach — and does anything reach it that should not?
Authorization and ethics: Everything here is for defenders and for testers working under written authorization on systems they are permitted to assess. Run hands-on work only on localhost, lab VMs, intentionally vulnerable AD labs (e.g., a self-hosted practice range), or CTF environments. Never test systems you do not own or lack explicit permission to assess.
Lateral movement is the step that converts a minor incident into a catastrophe. A single phished laptop is a contained problem; the same laptop used as a launch pad to reach a file server, then a backup server, then a Domain Controller is a full domain compromise — and from a DC an attacker can create accounts, read every secret, and deploy ransomware everywhere at once. In real breaches, the gap between initial access and domain-wide impact is almost always spanned by lateral movement.
It matters to detection teams because it defeats naive defenses. Signature-based tools look for known-bad files and known-bad network patterns. Lateral movement produces neither: the traffic is real SMB and WinRM, the binaries are signed Windows tools, and the logins use valid credentials. Catching it requires watching behaviour — why is one workstation suddenly opening admin shares on twelve other hosts? — not signatures.
It matters to architects because the structural fix is design, not a product you bolt on afterward. Network segmentation and tiered administration decide, in advance, how far any single breach can spread. Verifying those controls actually contain movement — rather than assuming they do — is one of the highest-value outcomes of an internal security assessment, and it directly shrinks the blast radius of ransomware.
It matters to incident responders because containing an active intrusion means knowing the reachable paths in advance. A tested reachability matrix and tuned behavioural alerts are the difference between isolating one subnet and watching an attacker outrun you across a flat network.
Each concept below is a building block. Read the definition, the plain-language explanation, how it works, when it applies (and when not), and the pitfall.
THREAT MODEL — internal lateral movement
Assets (what we protect, ranked):
Tier 0: Domain Controllers, identity/AD infrastructure, backup servers
Tier 1: file/app/database servers, business data
Tier 2: user workstations, user credentials
Entry points (how the attacker starts inside):
phished workstation | exposed/vulnerable service | weak or reused credential
Trust boundaries (the lines movement must cross):
[ Workstation VLAN ] | [ Server VLAN ] | [ DC / Tier 0 zone ]
Tier 2 Tier 1 Tier 0
Adversary goal:
cross boundaries (lateral movement) upward toward Tier 0,
harvesting the next secret at each hop.
Defender goal:
make each boundary a real wall (default-deny), keep privileged
credentials off low-trust hosts, and DETECT any crossing attempt.
Definition. Using the access you already hold on one host to authenticate to and operate on another host, repeated until a target of value is reached.
Plain language. "I'm already on machine A. Machine A's admin can also log into machine B. So I become that admin and step onto B."
How it works internally. The attacker collects a usable secret on host A (a password, an NTLM hash, or a Kerberos ticket), then presents that secret to host B over a normal authentication protocol. Windows validates it exactly as it validates a real admin, and grants a session.
When it matters / when it doesn't. It matters whenever hosts trust the same credentials (shared local admin passwords, domain admins logging into workstations). It is far harder on networks with unique per-host credentials and strict tiering.
Pitfall. People assume movement requires malware on the target. Often it requires nothing new installed — just valid credentials used over built-in protocols.
Foothold Pivot Goal
Host A --creds--> Host B --creds--> Domain Controller
(phished) (file server) (domain keys)
| | |
+-- harvest secret +-- harvest secret +-- own the domain
Knowledge check: What asset is ultimately being protected here, and why does reaching a Domain Controller usually end the game for the defender?
Definition. The legitimate remote-administration services attackers repurpose to execute code or open sessions on a remote host.
| Channel | Legitimate use | How it gets abused | Typical port |
|---|---|---|---|
| SMB / PsExec-style | File sharing, admin shares (ADMIN$, C$), remote service control |
Copy a payload to a share and create/start a remote service to run it | 445/tcp |
| WinRM / PowerShell Remoting | Scripted remote management | Run commands remotely with stolen creds | 5985/5986 |
| RDP | Interactive remote desktop | Log in interactively as a stolen identity | 3389/tcp |
| WMI | Remote queries and management | Spawn processes remotely without copying obvious files | 135 + dynamic |
How it works. Each protocol authenticates the caller, then offers a way to do something remotely (run a service, run a command, open a desktop). With a valid secret, the attacker just... uses it.
When NOT to expect it. If a protocol is disabled, or blocked by host/firewall rules between zones, that channel is closed — which is the whole point of the defenses later.
Pitfall. Treating these as inherently malicious. They are essential admin tools; the abuse is in who uses them and toward what.
Knowledge check (predict): A monitoring rule alerts on any use of WinRM anywhere in the network. Why is that rule nearly useless where admins legitimately use WinRM daily — and what insecure assumption does it make about "normal"?
Definition. Authenticating to a remote system using stolen credential material — an NTLM password hash (PtH) or a Kerberos ticket (PtT) — without ever knowing the cleartext password.
Plain language. Windows authentication often accepts the hash or ticket as proof of identity. If you steal the proof, you don't need the password it came from.
How it works.
Normal: password --hash--> proof --> server says OK
PtH: [stolen hash] --> proof --> server says OK (no password needed)
PtT: [stolen ticket] --> present --> service says OK (no password needed)
When it matters. Anywhere the same hash/ticket is valid on multiple hosts (e.g., a reused local admin hash). It is blocked by unique per-host secrets and by limiting where privileged tickets are minted and used.
Pitfall. Believing that "we rotate passwords" stops PtH. If a single password (and thus one hash) is shared across many machines, rotating it everywhere at once is exactly what most orgs fail to do — which is why LAPS (unique per-host local admin passwords) exists.
Common misconception to correct: PtH/PtT are about authentication proof material, not about breaking cryptography. Likewise, decoding a token to read its contents is not the same as verifying it — possessing valid material is what grants access.
Knowledge check (explain): Which insecure assumption enables pass-the-hash to spread — and why does it mean cracking the password is unnecessary for the attacker?
Definition. The artifacts on compromised hosts that let an attacker find the next secret to move with.
Examples. World-readable SMB shares, scripts with passwords hardcoded in them, configuration files holding credentials, cached domain credentials, and credential files left by tools.
How it works. After landing on host A, the attacker searches local files and reachable shares for the next usable secret, then repeats the movement. Each hop is funded by what the last hop revealed.
Pitfall. Underestimating plaintext passwords in scripts and config files. They are one of the most common real-world enablers of the next hop.
Knowledge check (detect): Which logs would let you notice a workstation account suddenly enumerating and reading many SMB shares it never touched before?
Definition. Dividing the network into zones (using VLANs and firewall rules) so that traffic between zones is restricted, containing a breach to the zone it started in.
Plain language. Interior walls and locked doors inside the building. Breaking into one room should not grant the whole floor.
How it works. Firewall and routing rules between zones permit only the flows that are actually needed (e.g., workstations may reach a web proxy but not each other's admin ports). Movement channels that cross a boundary are simply dropped.
[ Workstation VLAN ] --X-- (admin ports blocked) --X-- [ Server VLAN ]
| |
only HTTPS to proxy ---------- allowed ----------> [ Web Proxy / Jump host ]
Tier 0 (DCs) <== reachable ONLY from dedicated admin workstations ==>
When NOT to over-do it. Segmentation that blocks required business traffic causes outages and gets "temporarily" disabled — a flat network in disguise. Segment by real trust and traffic needs.
Pitfall. A flat network: one foothold reaches everything. The most valuable test result is often "this workstation subnet can directly reach the DC's admin ports, which it should not."
Definition. A model where high-privilege accounts (e.g., Domain Admins, "Tier 0") may only log into high-trust systems, never into ordinary workstations.
How it works. If a Domain Admin never types their credential on a workstation, that credential is never present on a workstation to be stolen — cutting off the most damaging hops. Combine with just-in-time access so privileges exist only briefly.
Pitfall. Helpdesk or domain admins routinely RDP-ing into user laptops to "fix things" — that single habit drops a powerful credential onto a low-trust host and undoes the model.
Knowledge check (authorization): Why must the reachability and movement tests in this lesson run only in an authorized lab you own or are permitted to assess?
Concept lessons have no programming syntax, but they do have a defensive vocabulary and a couple of structural artifacts you must be able to read and write precisely.
Key terms:
The reachability matrix is the core artifact. It is a small table: source zone → destination zone → allowed ports. Annotated shape:
SOURCE ZONE DEST ZONE PORTS ALLOWED VERDICT
----------- --------- ------------- -------
WORKSTATIONS -> SERVERS 443/tcp OK (business HTTPS only)
WORKSTATIONS -> WORKSTATIONS none OK (no peer admin ports)
WORKSTATIONS -> DC none OK (DC admin off limits here)
ADMIN_WS -> DC 445,5985,3389 OK (Tier 0 admin path only)
Reading and producing that matrix — then testing it against reality — is the skill this lesson trains.
Lateral movement means using your access on one host to reach another, then repeating until you hit a high-value target (often a DC). It is how a single foothold becomes domain compromise.
With valid credentials, hashes, or tickets, you authenticate to other machines using legitimate admin channels:
Because these are legitimate admin tools, the activity blends into normal traffic. That is why behavioural detection matters.
Each hop is fueled by what the attacker finds along the way:
A flat network lets one foothold reach everything.
Network segmentation uses VLANs and firewall rules between zones to contain a breach. Testing it answers one question: from this subnet, what can I reach?
Reporting which segments are reachable, especially those that should not be, is a core internal-engagement deliverable.
Concept lessons illustrate with realistic, defensive artifacts rather than C. Below is a full insecure -> secure -> verify sequence for segmentation, plus a detection-logging snippet. Run any commands only in an authorized lab you own or are permitted to assess (localhost / lab VMs / practice AD range / CTF).
A. INSECURE baseline — flat-network firewall policy
WARNING: intentionally vulnerable — use only in a local, isolated, authorized lab. Do not deploy.
# Flat network: every host can reach every other host on admin ports.
# This is what makes lateral movement trivial.
zone WORKSTATIONS -> zone WORKSTATIONS : ALLOW 445/tcp (SMB), 5985/tcp (WinRM), 3389/tcp (RDP)
zone WORKSTATIONS -> zone SERVERS : ALLOW ALL
zone WORKSTATIONS -> zone DC : ALLOW ALL
Why this is unsafe: any single compromised workstation can immediately authenticate to every other workstation, every server, and the Domain Controller over the exact protocols admins use. One foothold equals domain reach.
B. SECURE fix — segmented, default-deny policy
# Default deny east-west; permit only required flows.
default zone-to-zone : DENY
# Workstations may NOT talk to each other on admin ports.
zone WORKSTATIONS -> zone WORKSTATIONS : DENY 445/tcp, 5985/tcp, 3389/tcp
# Workstations reach business services only, never DC admin ports.
zone WORKSTATIONS -> zone SERVERS : ALLOW 443/tcp
zone WORKSTATIONS -> zone DC : DENY 445/tcp, 5985/tcp, 3389/tcp
# Domain Controllers are administered ONLY from dedicated admin workstations (Tier 0).
zone ADMIN_WS -> zone DC : ALLOW 445/tcp, 5985/tcp, 3389/tcp
zone WORKSTATIONS -> zone ADMIN_WS : DENY ALL
C. VERIFY the fix — mitigation verification (lab only)
Prove the control both rejects bad paths and still accepts good ones. From an authorized test host inside the WORKSTATIONS zone:
# Authorization checklist before running anything:
# [ ] I own this lab or have written permission to test it
# [ ] It is isolated (localhost / lab VLAN / practice range / CTF) — no production, no third parties
# [ ] I have a cleanup/reset plan (snapshot or documented rollback)
# REJECT test: admin ports to the DC must now be CLOSED.
# Expect: timeouts / "failed". If any of these connect, segmentation is NOT holding.
nc -vz -w 3 dc-lab.internal 445
nc -vz -w 3 dc-lab.internal 5985
nc -vz -w 3 dc-lab.internal 3389
# ACCEPT test: legitimate business flow must still WORK.
# Expect: success — users still reach the app over HTTPS.
nc -vz -w 3 app-lab.internal 443
D. Detection logging — what to record (and what never to)
# Behavioural rule (pseudocode): one source touching many admin ports fast.
ALERT "possible lateral movement" WHEN
count(distinct dst_host) >= 5
AND dst_port IN (445, 5985, 3389)
AND src_host.type == "workstation"
WITHIN 5 minutes
# Log fields: timestamp, src_host, src_user, dst_host, dst_port,
# auth_type, result (allow/deny), correlation_id
# NEVER log: passwords, NTLM hashes, Kerberos tickets, session cookies,
# private keys, or any secret material.
What these do and expected outcome. Policy A is the dangerous baseline. Policy B contains movement with default-deny plus narrow allow-lists and isolates DC administration to a Tier 0 admin zone. In C, the three nc REJECT checks should fail to connect once B is applied (that failure is the proof the control works), while the ACCEPT check to app-lab.internal:443 should still succeed — proving you contained the attacker without breaking the business. The detection rule in D fires on the pattern of one host fanning out to many admin ports, which signature tools miss.
Edge cases / false positives. Legitimate management servers (patching, monitoring, inventory) also fan out — they must be allow-listed in detection or they generate false positives. And a single forgotten ALLOW ALL rule re-flattens the network, so policies must be reviewed as a whole, not line by line. Placeholders like dc-lab.internal and app-lab.internal stand in for your own lab hosts; never point these at systems you are not authorized to test.
Walking through the secure policy (B) and its verification (C).
default zone-to-zone : DENY — the foundation. Anything not explicitly allowed is dropped. This flips the model from "open unless blocked" to "closed unless needed," which is what contains a breach.WORKSTATIONS -> WORKSTATIONS : DENY 445/5985/3389 — removes peer-to-peer admin reach. An attacker on one laptop can no longer PsExec/WinRM/RDP to the next laptop. This kills the most common workstation-to-workstation hop.WORKSTATIONS -> SERVERS : ALLOW 443 — users still reach the apps they need over HTTPS, but not over admin protocols. Business keeps working; movement does not.WORKSTATIONS -> DC : DENY admin ports — even a compromised workstation cannot authenticate to the DC over SMB/WinRM/RDP. The crown jewels are off the direct path.ADMIN_WS -> DC : ALLOW admin ports — DCs are managed only from hardened Tier 0 admin workstations. Combined with tiered administration, privileged credentials are never typed on ordinary hosts.WORKSTATIONS -> ADMIN_WS : DENY ALL — closes the obvious bypass ("just hop to the admin box first").Verification trace (C):
| Step | Target | Before fix | After fix | Meaning |
|---|---|---|---|---|
| 1 | DC:445 (SMB) | connects | timeout | SMB movement to DC blocked (REJECT) |
| 2 | DC:5985 (WinRM) | connects | timeout | Remote command exec to DC blocked (REJECT) |
| 3 | DC:3389 (RDP) | connects | timeout | Interactive logon to DC blocked (REJECT) |
| 4 | app:443 (HTTPS) | connects | connects | Business flow still works (ACCEPT) |
Rows 1-3 flipping from connects to timeout prove the fix rejects the attack paths. Row 4 staying at connects proves you did not break legitimate use — a fix that also blocked row 4 would be over-segmentation and get disabled in production. If any "after fix" REJECT cell still connects, the segmentation has a hole — that is precisely the finding an internal engagement reports. The detection rule (D) is a backstop: even if some flow is allowed, an unusual fan-out pattern still raises an alert with logged who/where/when — and never the secret.
Mistake 1 — "We rotate the local admin password, so pass-the-hash can't hurt us." Wrong because: if the same password (hence the same NTLM hash) is set on many machines, the hash from one host works on all of them until every host is rotated — which rarely happens simultaneously. Corrected: deploy LAPS so every host has a unique, automatically rotated local admin password (and hash). One stolen hash then unlocks exactly one host. Recognize/prevent: audit for shared local admin credentials; confirm LAPS coverage on every machine; treat any host lacking a unique password as a movement risk.
Mistake 2 — Domain Admins routinely RDP into user workstations to troubleshoot. Wrong because: that drops a Tier 0 credential onto a low-trust host where it can be stolen, handing the attacker the whole domain in one hop. Corrected: tiered administration — privileged accounts log on only to hardened admin workstations; use lower-privilege accounts and just-in-time access for desktop support. Recognize/prevent: alert on Domain Admin interactive logons to non-Tier-0 systems.
Mistake 3 — Building detection on signatures of "hacking tools." Wrong because: lateral movement uses signed, legitimate admin tools and valid logins — there is no malware signature to match. Related trap: assuming a clean vulnerability-scanner run means you are secure; it does not. Corrected: behavioural detection (one host fanning out to many admin ports; unusual source-user/destination pairings) plus rich authentication logging. Recognize/prevent: test your own detection by performing authorized movement in a lab and confirming an alert fires.
Mistake 4 — Calling a network "segmented" without testing it.
Wrong because: documentation and reality drift; a single stray ALLOW rule re-flattens the network.
Corrected: actively verify reachability from each zone (the nc REJECT/ACCEPT matrix) and report what is reachable that should not be.
Recognize/prevent: schedule recurring segmentation tests, not one-time sign-off.
Mistake 5 — Leaving passwords in scripts and config files.
Wrong because: these are prime fuel for the next hop; an attacker who lands on the host gets the next credential for free.
Corrected: use a secrets manager / group managed service accounts; scan repos and shares for embedded credentials (use placeholders like API_KEY=<development-placeholder> in examples).
Recognize/prevent: automated secret scanning; treat any found secret as compromised and rotate it.
Because this is conceptual, "debugging" means diagnosing why a control isn't behaving as intended.
"My segmentation test connects when it shouldn't (REJECT check passes traffic)."
ALLOW rule earlier in the policy that shadows your DENY (rule order matters)."My ACCEPT check fails — legitimate traffic is now blocked."
ALLOW above the default-deny."My detection rule never fires."
"My detection rule fires constantly."
Questions to ask when something doesn't work:
Security & safety — detection, logging, and authorization. This is a security topic, so the focus is risk, detection, and defense rather than memory safety.
Threat model recap (text diagram):
Assets: Domain Controllers / identity (Tier 0), file & backup servers,
user credentials, business data.
Entry points: phished workstation, exposed service, weak/reused credential.
Trust boundary: between network zones (workstation VLAN | server VLAN | DC/Tier 0).
Adversary goal: cross boundaries (lateral movement) toward Tier 0.
What to LOG (per authentication / remote-exec event): timestamp, source host, source user/account, destination host, destination port, auth type (NTLM/Kerberos/negotiate), result (allow/deny/logon-type), and a correlation id so hops can be linked into a path. Ship these to a SIEM you can query.
What to NEVER log: passwords, NTLM hashes, Kerberos tickets, session cookies, private keys, full secrets of any kind, or unneeded PII. If a secret ever appears in a log, treat it as exposed and rotate it immediately.
Events that signal abuse: one workstation opening admin shares on many hosts in minutes; a privileged (Tier 0) account logging on interactively to a low-trust host; NTLM authentication where Kerberos is expected; a burst of remote service creation (SMB) or WinRM sessions from a non-admin source; access to a DC's admin ports from a workstation subnet.
How false positives arise: legitimate management, patching, monitoring, and inventory servers also fan out to many hosts and use admin protocols by design. Allow-list them explicitly and baseline normal admin behaviour, or these tools will bury real alerts in noise.
Defensive practices (do this):
Ethics / authorization: perform any movement or reachability testing only with written authorization, on systems you own or are permitted to assess, and only on isolated lab/CTF environments. Lab cleanup/reset: snapshot VMs before testing and revert afterward; remove any test files/shares you created; re-enable or restore any rule you toggled; and confirm the lab is back to its baseline. Defensive understanding here is meant to contain and detect attackers, not to attack others. Note the honest limits: no environment is ever "completely secure," and passing an automated scan does not prove a network is safe.
Concrete authorized real-world use case. An internal penetration test (with a signed scope and rules of engagement) is asked: from the standard employee workstation VLAN, can an attacker reach the Domain Controllers or backup servers? The tester builds the reachability matrix, runs REJECT/ACCEPT checks from an authorized jump host, and reports every cross-segment path that should not exist — plus whether the customer's detections fired during the test. The customer then closes the gaps and re-tests.
Where this shows up:
Professional best-practice habits.
Beginner rules:
Advanced habits:
Work these in order; difficulty increases. Use only authorized lab environments you own or are permitted to assess for anything hands-on. Each hands-on task ends by remediating and verifying, not attacking.
Beginner 1 — Classify the channel. Objective: Match each scenario to the movement channel it describes. Requirements: For each, name the channel (SMB/PsExec, WinRM, RDP, WMI, PtH, or PtT) and one sentence of justification: (a) "attacker opens an interactive desktop session on a server"; (b) "attacker authenticates with a stolen NTLM hash, never knowing the password"; (c) "attacker creates a remote service via an admin share to run a payload." Output: three labelled lines. Hint: re-read the channels table. Concepts: movement channels, PtH/PtT.
Beginner 2 — Spot the flat network.
Objective: Read a firewall policy and decide whether it is segmented.
Requirements: Given a policy where WORKSTATIONS -> DC : ALLOW ALL exists, state (1) whether the network is effectively flat for this path, (2) one realistic movement it enables, (3) the corrected rule. Example output: "flat for this path; enables direct SMB/WinRM/RDP to the DC from any workstation; fix: DENY admin ports, allow DC admin only from ADMIN_WS."
Hint: default-deny first. Concepts: segmentation.
Intermediate 1 — Build and verify a reachability matrix. Objective: Produce a 3-zone reachability matrix, mark violations, and define the verification test for each. Requirements: Zones = WORKSTATIONS, SERVERS, DC. For each source->destination pair, list the ports that should be allowed, flag any that violate least-privilege/tiering, and write the REJECT test (must fail to connect) and one ACCEPT test (must still connect). Include at least one intentional violation and explain why it is dangerous. Constraints: DC admin ports reachable only from a dedicated admin zone; lab only; snapshot before, revert after. Hint: use the secure policy in this lesson as a template. Concepts: segmentation, tiered administration, mitigation verification.
Intermediate 2 — Design a behavioural detection. Objective: Write pseudocode for a lateral-movement detection rule and its log schema. Requirements: Define the trigger condition (distinct destinations on admin ports within a time window), the exact log fields to record (include a correlation id), the fields you must NEVER log, and one false-positive source plus how you would allow-list it. Concepts: behavioural detection, logging hygiene.
Challenge — Assume-breach blast-radius report. Objective: Given a one-host compromise, reason out and document the containment story defensively. Requirements: Assume a single workstation is compromised. Write a short report covering: (1) the realistic next 2 hops in a flat network and why; (2) which of the lesson's defenses (segmentation, tiering, LAPS, host firewall, protocol disabling) would have blocked each hop and how; (3) a verification step (a concrete REJECT/ACCEPT test) for each chosen defense; (4) detection/logging that would have caught the attempt — with an explicit note that no secrets are logged; (5) a lab authorization checklist and cleanup/reset steps. Constraints: the defensive/remediation detail must be at least as detailed as the attack narrative; authorized-lab framing only; conclude with remediate-and-verify. Concepts: every concept in this lesson.