Tracking use of default domain admin credentials

1) Define what you’re tracking (so you don’t miss the real risk)

A. Built-in domain Administrator (SID ends with -500)

• Do not rely on the name (it may be renamed). Track by SID ending -500.
• Flag any interactive use (console/RDP) and any use on non-DC systems as “high scrutiny.”

B. Any account in Domain Admins (and other “tier-0” groups)

• Domain Admins, Enterprise Admins, Schema Admins, Built-in Administrators, and any privileged custom groups.
• “Default” in practice often means: the accounts everyone knows exist and therefore are easy to target.

C. “Break-glass” / shared admin accounts

• Document them, label them, and track their usage like you would a fire alarm: rare and auditable.

If you haven’t already, review your admin account posture first: Securing administrator accounts in Active Directory.

2) Logging prerequisites that make tracking reliable

Tracking admin credential use only works if your logs can answer four questions consistently: who logged on, where they logged on, how they authenticated, and from where they came.

Enable Advanced Audit Policy (recommended baseline)

In a GPO linked to Domain Controllers OU (and another for servers), enable:

• Logon/Logoff
  • Audit Logon (Success, Failure)
  • Audit Logoff (Success)
  • Audit Special Logon (Success)
  • Audit Other Logon/Logoff Events (Success, Failure)
• Account Logon
  • Audit Credential Validation (Success, Failure)
  • Audit Kerberos Authentication Service (Success, Failure)
  • Audit Kerberos Service Ticket Operations (Success, Failure)

Make sure logs don’t overwrite the evidence

• Increase Security log size on DCs and critical servers.
• Forward Security events centrally (WEF) or to your SIEM/EDR.

If you’re using Microsoft Defender for Identity (MDI), set up event collection properly: Event collection with Microsoft Defender for Identity.

3) The event IDs that prove default admin credential use

Think of these as “building blocks.” One event rarely tells the whole story, but combinations do.

On servers/workstations (and sometimes DCs): interactive + network logons

• 4624 — Successful logon (look at Logon Type, Account, Source IP/Workstation)
• 4625 — Failed logon (great for password-sprays against Administrator / DA accounts)
• 4648 — Logon attempt using explicit credentials (“Run as”, mapped drives with alt creds)
• 4672 — Special privileges assigned to new logon (very useful on DCs)
• 4740 — Account lockout (often follows brute force / spray activity)

On domain controllers: authentication proofs (Kerberos/NTLM)

• 4768 — TGT request (Kerberos) — who requested a ticket (and from where)
• 4769 — Service ticket request (Kerberos) — what service was accessed
• 4776 — NTLM credential validation (useful in NTLM-heavy environments)
• 4771 — Kerberos pre-authentication failed (password guessing signals)

If you want deeper clarity on “how” auth is happening, refresh the fundamentals: NTLM authentication and Kerberos Authentication Protocols Explained.

Logon Types to memorize (high-signal)

• 2 = Interactive (console)
• 3 = Network (SMB, remote access to shares, many lateral movement paths)
• 10 = RemoteInteractive (RDP)
• 11 = CachedInteractive (laptops/offline scenarios)

4) High-signal hunts and alerts (practical filters + examples)

A. Detect usage of the built-in Administrator (SID ends with -500)

Your strongest anchor is the SID, not the username. In 4624/4625, filter by:

• TargetUserSid ends with -500
• AND LogonType IN (2, 10, 3)
• AND system is not an approved admin workstation / jump host (your allow-list)

# PowerShell (local hunt) - successful logons for the built-in Administrator (RID 500)
# Run on a system that has the Security log you're hunting (or point to a forwarded log store).

$start = (Get-Date).AddDays(-7)

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4624; StartTime=$start } |
  Where-Object {
    $_.Properties.Count -gt 0 -and
    ($_.Properties | ForEach-Object Value) -match '-500$'
  } |
  Select-Object TimeCreated, Id, MachineName, Message |
  Format-List

Alert recommendation: If RID-500 logs on to anything other than DCs or your designated tier-0 admin endpoints, treat it as urgent.

B. Detect Domain Admin usage on “non-admin” endpoints

The best method in a SIEM is to enrich logons with group membership (Domain Admins) and then alert on:

• 4624 LogonType 10 (RDP) to a workstation
• 4624 LogonType 3 (Network) to a workstation or low-tier server
• 4672 on DCs tied to the same Logon ID as a suspicious 4624

If you don’t have enrichment, build an allow-list of privileged accounts and alert on their logons outside:

• approved hosts (PAWs / jump servers / DCs)
• approved hours (change windows)
• approved protocols (avoid DA over SMB/NTLM where possible)

C. Detect “explicit credentials” usage (often precedes lateral movement)

Event 4648 is your friend when someone uses Run as or supplies alternate credentials. Hunt for 4648 where the account is RID-500 or a Domain Admin, and the target server is unusual.

D. Detect password spray / brute force attempts against default admin identities

Combine:

• 4625 bursts on many hosts (or many attempts on one host)
• 4771 (Kerberos pre-auth failed) on DCs for the same usernames
• 4740 lockouts shortly after the failures

For lockout tracing workflows and context: Account Lockout Event ID: How to Find Account Lockouts.

5) Behavior patterns that strongly indicate misuse

High-confidence red flags

• RID-500 authenticating to file servers, user workstations, or application servers without a clear reason.
• Domain Admin RDP logon (Type 10) to non-admin endpoints.
• Domain Admin network logon (Type 3) to many servers in a short period (possible lateral movement).
• Switch from Kerberos to NTLM unexpectedly for privileged accounts (often a sign of tooling or misconfig forcing NTLM).
• Privileged account activity outside maintenance windows, from unusual source IPs/subnets, or from endpoints that fail health/compliance checks.

Medium-confidence signals (needs context)

• 4624 + 4648 pairings (“explicit creds”) from admin workstations (could be normal admin workflow).
• 4769 service tickets for CIFS/HTTP/MSSQL to unusual hosts (could be automation or scheduled jobs).

6) Triage + response playbook (what to do when you get an alert)

1. Confirm the identity
   • Is this RID-500 (SID ends -500) or a Domain Admin?
   • Is the account expected to be active right now (change record/ticket)?
2. Confirm the “where” and “from where”
   • Destination host: DC vs server vs workstation
   • Source workstation/IP: is it an approved admin endpoint?
   • Logon type: 2/10 (interactive) is usually higher concern than some 3 (network), depending on environment.
3. Confirm the “how”
   • Kerberos vs NTLM
   • Was 4648 involved (explicit creds)?
4. Contain if suspicious
   • Isolate the source endpoint (most compromises originate there).
   • Reset the privileged credential(s) and invalidate sessions/tokens where applicable.
   • Hunt for lateral movement: additional 4624 Type 3/10 on other servers after the first event.
5. Eradicate + recover
   • Remove persistence (scheduled tasks, services, startup items, GPO modifications).
   • Rotate any secrets that may have been exposed (service accounts, app secrets).

7) Reduce future exposure (so “default admin” alerts become rare)

Limit where privileged accounts can log on

• Adopt a tiering model (Tier 0: DCs/identity; Tier 1: servers; Tier 2: workstations).
• Use admin workstations (PAWs/jump servers) and deny DA logon to workstations.

Make RID-500 usage exceptional

• Disable interactive logon for the built-in Administrator where possible.
• Use it only as a tightly controlled break-glass account with strong monitoring and access controls.

Improve password and lockout posture

• Strong password policy and meaningful rotation for privileged accounts.
• Lockout/Smart Lockout strategies to reduce spray success and alert early.

For password policy foundations: How to Configure a Password Policy – An Overview & Guide.

Related reading on Windows-Active-Directory.com

• Securing administrator accounts in Active Directory
• Event collection with Microsoft Defender for Identity
• NTLM authentication and Kerberos Authentication Protocols Explained
• Account Lockout Event ID: How to Find Account Lockouts
• How to Configure a Password Policy – An Overview & Guide