# The 5 Active Directory Attacks Every Developer Should Understand These techniques are for authorized penetration testing and educational purposes only. Never use them against systems you do not have explicit permission to test. If you work at a company with more than 50 employees, chances are you are on an Active Directory network. And if you are a developer, you probably never think about it. But attackers do. Here are 5 attacks that happen in real AD environments, explained so a developer can understand them. ## 1. LLMNR Poisoning **The analogy:** Imagine you are in a crowded room and you shout "Hey, does anyone know where the bathroom is?" LLMNR poisoning is someone answering "Yeah, follow me" and leading you to a fake bathroom where they steal your wallet. LLMNR (Link-Local Multicast Name Resolution) is what Windows uses when DNS fails. The machine broadcasts a question to the network: "Does anyone know where server-xyz is?" An attacker running Responder answers: "Yeah, that is me. Send me your credentials." {`$ sudo responder -I eth0 -dPv [+] Listening for events... [*] [LLMNR] Poisoned answer sent to 192.168.1.50 [+] NTLMv2 Hash captured: User: jsmith Domain: CORP Hash: jsmith::CORP:a1b2c3d4e5f6...`} ## 2. SMB Relay Once you capture those credentials, sometimes you do not even need to crack them. If SMB signing is not required (and it often is not), you can relay those credentials to another machine. This means an attacker does not need to know a single password. They just redirect traffic from one machine to authenticate as that user on another machine. ## 3. Kerberoasting **The analogy:** Kerberos tickets are like movie tickets. When you buy a ticket (request a TGS), it is encrypted with the service account's password hash. A Kerberoast attack requests tickets for every service account, then cracks them offline. {`$ GetUserSPNs.py CORP.local/jsmith:Password1 -dc-ip 192.168.1.10 -request ServicePrincipalName Name PasswordLastSet CORP-DC/SQLService.local SQLService 2025-08-30 20:09:32 $krb5tgs$23$*SQLService$CORP.LOCAL$CORP-DC/SQLService.local*$a1b2c3...`} The fix? Use long, random passwords on service accounts and monitor for TGS requests. ## 4. GPP (Group Policy Preferences) Attacks **The analogy:** Imagine your building manager writes the master key combination on a sticky note and puts it in a shared folder that every tenant can access. That is GPP. Microsoft used to let admins set local admin passwords via Group Policy Preferences. The password was stored in an XML file on the SYSVOL share, "encrypted" with an AES key that Microsoft published in their own documentation. Yes, really. {`$ gpp-decrypt "+bsY0V3d4/KgX3VJdO/vyepPfAN1zMFTiQDApgR92JE" Password: LocalAdmin123!`} Microsoft patched this in MS14-025 (2014), but any group policy created before the patch still has the password sitting in SYSVOL. Old policies do not get cleaned up automatically. On older domains, this is still a free win. ## 5. Token Impersonation If you compromise a machine where a domain admin is logged in, you can steal their token and impersonate them without knowing their password. Think of it like finding someone's badge on a desk and wearing it. ## What Should Developers Do? 1. Push for SMB signing to be required 2. Advocate for long service account passwords 3. Never use the same local admin password across machines 4. Keep systems patched 5. Understand that your network is only as strong as its weakest configuration You do not need to become a pentester to make your organization more secure. Understanding these attacks makes you a better advocate for security during code reviews and architecture discussions.