Built-in Accounts and Privileged Accounts: Taxonomy and Scope

Golden Rule of DFIR Clarification

Never conflate these five fundamentally distinct concepts:

• Account: A unique security principal holding cryptographic secrets (e.g., Administrator, RID 500).
• Group: A principal container simplifying access assignments (e.g., Domain Admins, RID 512).
• Privilege (User Right): An operating system capability to perform system tasks (e.g., SeDebugPrivilege).
• Permission: An access rule granted on a securable object via an ACL (e.g., GenericAll on an OU).
• Administrative Role: A functional operational state resulting from the combination of the four elements above.

Concept

The Windows operating system and Active Directory provide built-in accounts and privileged security groups configured out-of-the-box to facilitate bootstrapping, system maintenance, and core service operations.

These principals operate with strict boundaries defined by their execution context (local host vs forest-wide).

---

Why This Matters in DFIR

Privileged principals represent the primary objectives for adversaries advancing along the attack chain:

1. Abuse of Built-in Service Identities: Services running under NETWORK SERVICE or LOCAL SERVICE are frequently targeted for local privilege escalation (Potato exploits) abusing SeImpersonatePrivilege to reach SYSTEM.
2. Stealthy Tier-1 and Tier-0 Lateral Movement: Attackers do not always add themselves to Domain Admins. They frequently target secondary privileged groups such as Account Operators, Backup Operators (granting ntds.dit theft via SeBackupPrivilege), or DnsAdmins.
3. Infrastructure Identity Persistence: The krbtgt account (RID 502) is the core Kerberos service account. Extracting its password hash allows for unconstrained Golden Ticket creation.

---

How It Works

1. Operating System Built-in Service Accounts

Every Windows system includes three non-interactive service accounts:

Principal	SID	Password Handling	Network Identity	Key Privileges
SYSTEM (LocalSystem)	S-1-5-18	Managed by OS kernel	Authenticates as the computer account (COMPUTER$)	Full local OS privileges (SeDebug, SeTcb, SeImpersonate)
LOCAL SERVICE	S-1-5-19	None (internal context)	Anonymous / Null Session only	Highly restricted local privileges
NETWORK SERVICE	S-1-5-20	None (internal context)	Authenticates as the computer account (COMPUTER$)	Restricted local privileges, authenticated network reach

2. Active Directory Privileged Groups Hierarchy

               ┌───────────────────────────────┐
               │       Enterprise Admins       │  (Entire Forest)
               └───────────────┬───────────────┘
                               │
               ┌───────────────▼───────────────┐
               │         Domain Admins         │  (Specific Domain)
               └───────────────┬───────────────┘
                               │
               ┌───────────────▼───────────────┐
               │    BUILTIN\Administrators     │  (Local Machine or DC)
               └───────────────────────────────┘

• Enterprise Admins (RID 519): Exists only in the forest root domain. Holds absolute authority over forest schema, configuration, and all child domains.
• Domain Admins (RID 512): Administrative group for a specific domain. By default, added to the local Administrators group of every domain-joined workstation and server.
• Administrators (RID 544, S-1-5-32-544): Local group present on every Windows OS. On a DC, this group manages the DC itself.
• Backup Operators (RID 551): Holds SeBackupPrivilege and SeRestorePrivilege, permitting physical copies of ntds.dit regardless of directory ACLs.
• Account Operators (RID 548): Can create and modify accounts across the domain (outside protected groups).

---

What Is Possible

• Domain Theft via Backup Operators: An analyst must recognize that membership in Backup Operators enables complete domain credential theft without Domain Admins membership.
• Pivoting as COMPUTER$ from SYSTEM: If an application service runs as LocalSystem, outbound SMB/RPC requests present the machine’s domain credentials (APP01$).
• Enforcing Modern Guardrails: Placing accounts in the Protected Users group disables NTLM caching in LSASS and prevents unconstrained delegation.

---

What Is Not Possible

• Direct Schema Modification by Child Domain Admins: Modifying the forest schema requires membership in Schema Admins in the forest root.
• Network Impersonation via LOCAL SERVICE: Unlike NETWORK SERVICE and SYSTEM, it cannot present COMPUTER$ credentials over the wire.
• Permanent ACL Tampering on Protected Accounts: The SDProp background system process periodically overwrites modified ACLs on protected principals using the AdminSDHolder template.

---

Forensic Artifacts

EventID: 4672 # Special Privileges Assigned to New Logon
SubjectUserName: operator1
SubjectUserSid: S-1-5-21-111111111-222222222-333333333-1108
PrivilegeList:
  SeBackupPrivilege
  SeRestorePrivilege
  SeSecurityPrivilege

EventID: 4728 # Member Added to Security Group
TargetUserName: Domain Admins
TargetSid: S-1-5-21-111111111-222222222-333333333-512
MemberSid: S-1-5-21-111111111-222222222-333333333-1190

---

Key Takeaways

1. SYSTEM is not an Active Directory account: on the network, it acts as COMPUTER$.
2. Backup Operators is functionally equivalent to Domain Admins due to ntds.dit access.
3. Enterprise Admins is the sole true forest-wide security boundary.
4. Monitoring Event ID 4672 reveals high-privilege token generation.

---

Cross References

• Doc 01: Windows Identities: Local Accounts vs Domain Accounts
• Doc 04: Local Administrator vs Domain Administrator
• Doc 09: Privileges vs Permissions