Adversary Techniques
AD/Windows attack techniques framed for defenders — Kerberoasting, AS-REP roasting, Pass-the-Hash/Ticket, Golden/Silver tickets, DCSync, delegation abuse, LLMNR poisoning, C2 and attack-path analysis. Detection and mitigation only.
12 questions
JuniorTheoryVery commonWhere does Windows keep credential material, and what do Credential Guard and LSA protection change?
Where does Windows keep credential material, and what do Credential Guard and LSA protection change?
Windows holds authentication secrets in LSASS memory and local hashes in the SAM hive, so an admin-level attacker reads them rather than cracking. Alert on unusual LSASS handle opens; Credential Guard isolates secrets and RunAsPPL blocks access.
Common mistakes
- ✗Assuming stored hashes are useless to an attacker without cracking the plaintext
- ✗Believing Credential Guard removes the need to limit local administrator rights
- ✗Overlooking that reading LSASS needs privileges the attacker must already hold
Follow-up questions
- →Why does Credential Guard not help against a keylogger on the same host?
- →What does the local security authority
LSAprotection setting RunAsPPL actually block?
JuniorTheoryVery commonWhich Linux misconfigurations lead to root, and what hardening removes each of them?
Which Linux misconfigurations lead to root, and what hardening removes each of them?
The usual paths are misconfiguration, not exploits: SUID binaries able to run arbitrary commands, over-broad sudoers rules such as NOPASSWD, and world-writable cron files. Harden by auditing SUID, scoping sudoers and fixing ownership.
Common mistakes
- ✗Treating root escalation as a kernel-exploit problem instead of a configuration one
- ✗Granting
NOPASSWDon an editor or interpreter that can spawn a shell - ✗Auditing SUID binaries once and never re-checking after package changes
Follow-up questions
- →Why is a sudoers rule allowing an editor effectively equal to full root?
- →Which host telemetry would show an unexpected root process appearing?
JuniorTheoryCommonWhat makes command-and-control (C2) traffic detectable, and why does blocking ports not stop it?
What makes command-and-control (C2) traffic detectable, and why does blocking ports not stop it?
C2 hides inside protocols you already allow out, such as DNS and HTTPS, so blocking ports misses it. Behaviour betrays it: regular call-home intervals, uniformly small requests, rare long-lived destinations. Answer with an authenticated egress proxy.
Common mistakes
- ✗Expecting a port-based rule to stop a channel riding an allowed protocol
- ✗Assuming encryption removes every observable signal from the traffic
- ✗Treating DNS as infrastructure noise rather than a monitored egress path
Follow-up questions
- →Which fields of a proxy log would you baseline to surface periodic call-home traffic?
- →Why does a default-deny outbound policy change the cost of this technique for an attacker?
JuniorTheoryCommonWhy is authentication protocol NTLM called legacy, and what do SMB signing and channel binding prevent?
Why is authentication protocol NTLM called legacy, and what do SMB signing and channel binding prevent?
NTLM does not authenticate the target server, so a response captured on one host can be presented to another, and the hash itself is a usable credential. SMB signing rejects relayed messages; channel binding ties auth to the TLS channel.
Common mistakes
- ✗Thinking NTLM's flaw is weak hashing rather than the missing target authentication
- ✗Believing SMB signing encrypts traffic instead of proving message integrity
- ✗Assuming a captured response only works against the server it was sent to
Follow-up questions
- →Why does SMB signing still leave the directory protocol
LDAPopen to relay? - →How would you inventory remaining NTLM authentication before disabling it?
MiddleTheoryCommonHow does password spraying show up in Active Directory logs, and why is lockout policy not enough?
How does password spraying show up in Active Directory logs, and why is lockout policy not enough?
Spraying tries one password across many accounts, so none reaches the lockout threshold. The signal is horizontal: many accounts failing from one source in a short window — Kerberos pre-authentication and NTLM logon failures. Lockout alone is also a DoS lever.
Common mistakes
- ✗Looking for a vertical burst against one account instead of a horizontal pattern
- ✗Treating a lockout threshold as detection rather than a crude reaction
- ✗Forgetting an aggressive lockout policy can itself be abused to deny service
Follow-up questions
- →Which correlation window and threshold would you pick for the horizontal rule?
- →Why does phishing-resistant multi-factor authentication
MFAchange the outcome here?
SeniorTheoryOccasionalWhat enables AS-REP roasting and Golden/Silver ticket forgery, and how does krbtgt rotation respond?
What enables AS-REP roasting and Golden/Silver ticket forgery, and how does krbtgt rotation respond?
AS-REP roasting is enabled by accounts flagged as not requiring Kerberos pre-authentication — find and clear that flag. Golden and Silver tickets follow from theft of the krbtgt or a service key, not a protocol flaw. Rotate krbtgt twice, but only after eviction.
Common mistakes
- ✗Treating ticket forgery as a protocol bug rather than a consequence of key theft
- ✗Rotating
krbtgtonce, which leaves previously forged tickets still valid - ✗Rotating keys before eviction is complete, so the new keys are stolen again
Follow-up questions
- →Why must the second
krbtgtrotation wait for replication to complete? - →Which accounts would legitimately carry the pre-authentication exemption?
SeniorTheoryOccasionalWhat does graph-based attack-path analysis show that a vulnerability scan cannot?
What does graph-based attack-path analysis show that a vulnerability scan cannot?
A scanner lists issues host by host; path analysis models identities, sessions, group membership and ACLs as a graph, showing the shortest chain from an ordinary user to Domain Admin. You then cut the few edges most paths cross and re-measure.
Common mistakes
- ✗Reading the graph as a host-centric risk list instead of an identity-relationship model
- ✗Trying to remediate every path rather than the shared edges most paths cross
- ✗Skipping the re-measurement that proves the remediation actually shortened paths
Follow-up questions
- →Which graph edges usually turn out to be the cheapest to remove in practice?
- →Why do administrator sessions on ordinary workstations create so many paths?
SeniorTheoryOccasionalHow do you detect DCSync replication abuse, and why is unconstrained delegation a domain risk?
How do you detect DCSync replication abuse, and why is unconstrained delegation a domain risk?
DCSync abuses the directory replication right, so its traffic resembles normal controller replication. Alert on replication requests from non-controller sources, and audit who holds that right. Unconstrained delegation caches tickets on a host — replace it with RBCD.
Common mistakes
- ✗Assuming replication traffic cannot be attributed to a requesting source
- ✗Leaving the replication right assigned to non-controller accounts unreviewed
- ✗Thinking unconstrained delegation is safer than constrained delegation or RBCD
Follow-up questions
- →Which directory rights would you review first when hunting for this exposure?
- →Why is a host with unconstrained delegation effectively a tier-zero asset?
SeniorTheoryOccasionalWhy is credential attack Kerberoasting hard to detect, and how do gMSA accounts remove it?
Why is credential attack Kerberoasting hard to detect, and how do gMSA accounts remove it?
Any domain user may legitimately request a service ticket, and cracking runs offline, so no later event exists to alert on. Weak signals: ticket requests using RC4, or one account asking for many service names. The fix is gMSA accounts with long rotated passwords.
Common mistakes
- ✗Expecting a noisy alert from an operation that is ordinary domain traffic
- ✗Believing the offline cracking stage produces events on your own network
- ✗Rotating service-account passwords by hand instead of removing human-set ones
Follow-up questions
- →Why does moving service accounts off RC4 encryption change the attacker's economics?
- →How would you inventory which accounts carry a service principal name
SPN?
SeniorTheoryOccasionalHow does poisoning of name-resolution fallback LLMNR/NBT-NS capture credentials, and what disables it?
How does poisoning of name-resolution fallback LLMNR/NBT-NS capture credentials, and what disables it?
When DNS lookup fails, Windows falls back to broadcast name resolution and any host on the segment may answer. The victim authenticates to that responder, handing over an NTLM challenge-response usable offline or for relay. Disable LLMNR and NBT-NS by policy.
Common mistakes
- ✗Treating the fallback as a performance quirk rather than an authentication exposure
- ✗Assuming the responder captures a plaintext password rather than a challenge-response
- ✗Disabling LLMNR without fixing the DNS gaps that trigger the fallback
Follow-up questions
- →Why does enforcing SMB signing reduce the impact even while the fallback stays enabled?
- →Which legitimate name-resolution failures would you expect to surface after disabling it?
SeniorTheoryOccasionalWhy is most privilege escalation misconfiguration, not exploitation, and what does least privilege change?
Why is most privilege escalation misconfiguration, not exploitation, and what does least privilege change?
Exploits need a vulnerable build and get patched; misconfigured rights are permanent and silent: local admin for all, over-broad groups, service accounts with domain rights, secrets in scripts. Least privilege removes the edge instead of watching it.
Common mistakes
- ✗Assuming escalation is dominated by exploits, so patching alone is sufficient
- ✗Investing only in detection while leaving the standing rights in place
- ✗Treating least privilege as paperwork rather than removal of an escalation path
Follow-up questions
- →How would you measure standing privilege across an estate before reducing it?
- →What does tiered administration prevent that per-host hardening cannot?
SeniorTheoryOccasionalWhich Windows privilege-escalation paths recur, and what telemetry exposes each of them?
Which Windows privilege-escalation paths recur, and what telemetry exposes each of them?
They are mostly misconfiguration: service binaries with weak path ACLs, SYSTEM services users may reconfigure, token impersonation from an over-privileged process, and UAC mistaken for a security boundary. Telemetry: service change events and odd process chains.
Common mistakes
- ✗Framing Windows escalation as a patching problem rather than a configuration one
- ✗Treating UAC as a security boundary instead of a convenience prompt
- ✗Monitoring only logons while ignoring service creation and modification events
Follow-up questions
- →Why does a weak ACL on a service binary path grant the same power as SYSTEM?
- →Which parent-child process relationships would you baseline as normal on a workstation?
