Windows Security & Active Directory: What Every SOC Analyst Must Know (Complete Guide)
I investigated my first Active Directory compromise at Inhok 2 weeks into my internship. Attacker gained one user credential. Then leveraged AD to move laterally. Accessed 50+ systems. Stole sensitive data. All because I didn't understand AD security.
That experience forced me to deep-dive into Windows security. How AD works. How attackers exploit it. How to detect attacks. This post captures everything I've learned.
One of the first dashboards I started checking regularly was Microsoft Defender. At first the alerts looked overwhelming, but after spending time reading them every day I became much more comfortable understanding what normal Windows activity looks like compared to suspicious behaviour.
Understanding identity management made Active Directory concepts much easier for me. Once I understood users, groups, roles and authentication, many attack techniques started making much more sense.
Active Directory: The Foundation
Active Directory is a database of every user, computer, and resource in a Windows domain. If you understand AD, you understand how 80% of attacks on enterprises work.
Central authentication system for Windows networks. Users log in once, get access to all authorized resources. Centralized, convenient, but also centralized point of attack.
Real SOC impact: If attacker compromises one AD account, they can access many systems. That's why we monitor AD logs obsessively.
Kerberos: Modern, secure authentication protocol. Uses tickets (TGT). Attacker needs to steal ticket to impersonate user.
NTLM: Legacy protocol. Still used as fallback. Weaker. Attacker only needs password hash to impersonate.
SOC implication: Monitor NTLM usage. If you see NTLM authentication where Kerberos should work, it's suspicious. Might indicate attacker forcing downgrade.
Most successful attacks don't start with advanced exploitation. They usually begin with stolen credentials. Strong authentication and MFA are still some of the simplest ways to stop attackers before they ever reach Active Directory.
Common AD Attack Vectors (What Attackers Actually Do)
How it works: Attacker requests Kerberos service tickets from any account (doesn't need admin). Tickets contain encrypted passwords. Can be cracked offline.
Real example: Attacker requested TGS ticket for SQL Server service. Cracked password offline. Got SQL admin access. Dumped database.
How it works: Attacker steals Kerberos ticket from one system. Injects it into their own system. AD accepts it as valid. Attacker now impersonates original user.
Real example: Attacker extracted Kerberos ticket from compromised workstation. Injected into Linux system (using Impacket). Accessed file shares as the original user.
How it works: Attacker intercepts NTLM authentication between client and server. Relays it to another service (SMB, HTTP). Gains access to that service as the authenticated user.
Real example: Attacker relayed NTLM authentication from workstation to Exchange server. Got access to CEO's email.
How it works: Attacker steals KRBTGT account password hash (domain admin only). Uses it to forge valid Kerberos tickets for ANY user. AD can't tell forged from real.
Real example: Attacker got domain admin. Stole KRBTGT hash. Created ticket for fake "super admin" account. Had permanent access even after password resets.
Learning about network segmentation completely changed how I viewed lateral movement. Once critical systems are isolated properly, attackers have a much harder time moving across the environment even after compromising one machine.
Lateral Movement: How Attackers Move Through the Domain
Step 1: Initial Access
Attacker phished employee. Got username/password. Logged into workstation as regular user (zero privileges).
Step 2: Credential Extraction
Ran Mimikatz (credential extraction tool). Dumped all cached credentials from workstation memory. Found password of domain admin who had logged in earlier.
Step 3: Lateral Movement
Used stolen domain admin credentials to access file server, database server, Exchange server. Installed backdoor on each.
Step 4: Persistence & Exfiltration
Created hidden admin accounts on critical servers. Downloaded sensitive data. Covered tracks by clearing logs.
Detection Missed: Why We Didn't Catch It
We weren't monitoring credential extraction. Weren't alerting on domain admin logons from unexpected locations. Weren't checking for new user account creation. All failures on our side.
Looking at Windows Event IDs inside a SIEM helped me connect theory with real monitoring. Instead of memorizing event numbers, I started understanding why each event matters during investigations.
Detection Strategies (How to Catch Attackers)
Critical Events to Monitor
- Event ID 4625: Failed logon. Spike = brute force attempt.
- Event ID 4688: Process creation. Baseline normal processes. Alert on unknown.
- Event ID 4769: Kerberos service ticket requested. Baseline. Alert on spike.
- Event ID 4720: User account created. Every creation = must be approved.
- Event ID 4722: User account enabled. Track all account enablements.
- Event ID 4728: User added to group. Domain admin group additions = critical.
- Event ID 4732: User added to local admin group. Must investigate.
- Event ID 5140: Network share accessed. Monitor file share access patterns.
The more Windows environments I studied, the more I realized that modern enterprise security is moving toward Zero Trust. Instead of automatically trusting devices inside the network, every request should be verified continuously.
0 Comments