Domain Controller and Active Directory Monitoring

Domain Controller and Active Directory (AD) monitoring involves collecting and analyzing security events from domain controllers to detect malicious activities. AD is the identity store for Windows networks, storing user accounts, groups, computers, and policies. Domain controllers authenticate users and enforce security policies. Attackers target AD to gain persistence, escalate privileges, or move laterally. Monitoring focuses on detecting anomalies in authentication, replication, and privilege usage.

Domain controllers are the most sensitive servers in a Windows domain. Compromise of a DC gives an attacker control over the entire domain. Common AD attacks include: - DCSync: An attacker impersonates a domain controller and requests replication of password hashes from another DC. - Golden Ticket: An attacker forges a Kerberos Ticket Granting Ticket (TGT) using the KRBTGT account hash. - Silver Ticket: An attacker forges a service ticket for a specific service. - Kerberoasting: An attacker requests a service ticket for a service account and cracks its password offline. - Pass-the-Hash (PtH): An attacker uses an NTLM hash to authenticate without knowing the password. - Overpass-the-Hash: An attacker uses an NTLM hash to request a Kerberos TGT. - Skeleton Key: An attacker injects a backdoor into a DC that allows authentication with any password.

#### Windows Event Logs

Domain controllers generate critical security events. The most important event IDs for AD monitoring include:

#### Advanced Audit Policies

To capture relevant events, you must configure advanced audit policies on domain controllers. Key policies include:

You can configure these via Group Policy under Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies.

#### Microsoft Defender for Identity (MDI)

MDI is a cloud-based security solution that monitors on-premises AD traffic using sensors installed on domain controllers. It detects suspicious activities such as:

MDI alerts are integrated into Microsoft 365 Defender, providing a unified view of threats.

DCSync is a technique used by attackers to extract password hashes from a domain controller. The attacker uses a tool like Mimikatz to impersonate a domain controller and request replication of password data using the Directory Replication Service (DRS) Remote Protocol (MS-DRSR).

Steps: 1. The attacker gains administrative privileges on a machine that can communicate with a DC. 2. The attacker runs Mimikatz with the lsadump::dcsync command, specifying the target domain and user. 3. Mimikatz sends a DRSGetNCChanges request to the DC, impersonating a domain controller. 4. The DC responds with the requested password hashes (NTLM and Kerberos hashes).

Detection: Event ID 4662 with Object Type domainDNS and Access Mask 0x100 (Control Access) on the DS-Replication-Get-Changes extended right. Also, MDI alert "Directory Service Replication Request" is generated.

A Golden Ticket attack involves forging a Kerberos TGT using the KRBTGT account hash. The attacker extracts the KRBTGT hash from a compromised DC, then creates a fake TGT with arbitrary user and group memberships.

Steps: 1. Attacker compromises a DC and extracts the KRBTGT hash using Mimikatz (lsadump::dcsync /user:krbtgt). 2. Attacker forges a TGT using Mimikatz kerberos::golden command, specifying user (e.g., Administrator), domain SID, and KRBTGT hash. 3. The forged TGT is injected into memory and used to request service tickets. 4. The attacker gains access to any resource in the domain.

Detection: Event ID 4768 with unusual ticket options (e.g., forwardable flag set), or Event ID 4672 for logon with special privileges. MDI detects Golden Tickets by analyzing ticket validity periods (forged tickets often have long lifetimes) and anomalies in ticket issuance.

Kerberoasting is an attack where an attacker requests a Kerberos service ticket for a service account (with SPN) and then cracks the ticket offline to recover the account's password.

Steps: 1. Attacker enumerates service accounts with SPNs using tools like setspn -T domain -Q */*. 2. Attacker requests a TGS for the service account using a tool like Rubeus or GetUserSPNs. 3. The DC returns a TGS encrypted with the service account's NTLM hash. 4. Attacker extracts the TGS and cracks the hash offline (e.g., using Hashcat).

Detection: Event ID 4769 with RC4 encryption type (0x17) for service tickets. A single user requesting multiple TGSs for different service accounts is suspicious. MDI alert "Kerberos Service Ticket Request" may indicate Kerberoasting.

#### Enable Advanced Audit Policy

Use Group Policy Management Console (GPMC) to create a GPO linked to the Domain Controllers OU. Configure the following audit policies:

Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies
- Account Logon > Audit Kerberos Authentication Service: Success and Failure
- Account Logon > Audit Kerberos Service Ticket Operations: Success and Failure
- Account Logon > Audit Credential Validation: Success and Failure
- Logon/Logoff > Audit Logon: Success and Failure
- Logon/Logoff > Audit Special Logon: Success and Failure
- Object Access > Audit Directory Service Access: Success and Failure
- Object Access > Audit Directory Service Changes: Success and Failure

#### Enable SACL for Sensitive AD Objects

To audit access to sensitive objects like the AdminSDHolder container, you can set a System Access Control List (SACL) using ADSI Edit. For example, to audit modifications to the Domain Admins group:

Open ADSI Edit > right-click the Domain Admins group > Properties > Security > Advanced > Auditing > Add > Select Principal 'Everyone' > Type 'All' > Permissions 'Write all properties' > OK.

#### Deploy Microsoft Defender for Identity

MDI sensors are installed on domain controllers. The sensor captures network traffic and Windows events. Configuration steps: 1. In Microsoft 365 Defender, navigate to Settings > Identities > Data sources. 2. Download the sensor installer and install on each DC. 3. Configure the sensor to communicate with the MDI cloud service. 4. Verify sensor health in the MDI console.

// DCSync Detection
SecurityEvent
| where EventID == 4662
| where ObjectType == "domainDNS"
| where AccessMask == "0x100"
| where AdditionalInfo contains "DS-Replication-Get-Changes"
| project TimeGenerated, Account, Computer, ObjectName

// Kerberoasting Detection
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"  // RC4
| where ServiceName != "krbtgt"
| summarize Count = dcount(ServiceName) by Account, Computer, bin(TimeGenerated, 1h)
| where Count > 10

// Golden Ticket Detection - Unusual TGT Lifetime
SecurityEvent
| where EventID == 4768
| where TicketOptions contains "forwardable"
| extend Lifetime = datetime_diff('second', TicketEndTime, TicketStartTime)
| where Lifetime > 36000  // > 10 hours

A global bank with 50,000 users and 200 domain controllers deployed MDI across all DCs. They configured advanced audit policies to capture all AD changes. One day, MDI alerted on a DCSync attack from a non-DC server in a remote branch. The attacker had compromised a local admin account and used Mimikatz to replicate password hashes. The SOC isolated the server and reset the KRBTGT password twice (to invalidate any forged tickets). They also rotated all domain admin passwords. The key learning: MDI detection was critical because the attack used legitimate replication protocols, which traditional antivirus missed.

A hospital with 10,000 users and 30 DCs experienced a Kerberoasting attack. The attacker used a low-privilege account to enumerate SPNs and request TGS tickets for 50 service accounts. The SOC detected the attack via Sentinel analytic rule that flagged a single user requesting more than 10 TGS tickets with RC4 encryption in an hour. The rule had a threshold of 10; without it, the attack would have gone unnoticed. The attacker cracked three service account passwords offline and used them to access patient records. The hospital implemented strong service account passwords and disabled RC4 encryption for Kerberos (set Network security: Configure encryption types allowed for Kerberos to AES only).

A government agency with 100,000 users and 500 DCs suffered a Golden Ticket attack. The attacker compromised a DC via an unpatched vulnerability (EternalBlue) and extracted the KRBTGT hash. They forged a TGT for a domain admin account with a 10-year lifetime. The forged ticket was used to access classified data. Detection came from MDI, which flagged a TGT with an abnormally long lifetime (10 years vs default 10 hours). The agency reset the KRBTGT password twice and implemented additional monitoring for TGT lifetime anomalies. They also enforced smart card authentication for all privileged accounts. The lesson: Golden Tickets can only be detected through behavioral analysis, not signature-based detection.