Red Team · 7 min read · Log Academy training team
Active Directory security: the misconfigurations that lead to domain admin
Active Directory security is mostly a configuration problem. Most paths to domain admin are opened not by exploit code but by weak passwords, too many privileged group members, over-permissive ACLs, service accounts with weak passwords and legacy protocols. Defenders close these gaps through regular auditing, event log monitoring and a tiered administration model.
- Domain compromise usually comes not from a single mistake but from several small misconfigurations chained together.
- The fewer members privileged groups (Domain Admins, Enterprise Admins) have, the smaller the attack surface.
- Service accounts with SPNs must not have weak passwords; use gMSA wherever possible.
- With the right audit policy, event IDs such as 4624, 4625, 4662 and 4769 give valuable signals in a SIEM.
- A tiered admin model stops privileged accounts from being used on ordinary workstations.
- Offensive testing of AD is done only with written authorisation or in an isolated lab.
Why is Active Directory a prime target for attackers?
Active Directory (AD) is the central directory that defines who is who in an organisation and what each identity can access. Users, computers, groups and Group Policy are all managed from it. That is why full control of a domain controller in practice means control of the entire network.
That control rarely comes from a single critical vulnerability. A far more common picture is this: small mistakes accumulated over years link up and create a path from an ordinary user account to domain admin. Active Directory security is about spotting and breaking those paths in time. For cybersecurity teams, AD is therefore one of the most important assets to defend.
Which misconfigurations raise the risk of domain compromise?
The five groups below are the problems most often found in AD reviews. Each may look minor on its own, but together they create serious risk.
- Weak and reused passwords: if one account's password is exposed, the same password may work for other accounts. An identical local administrator password on every computer falls into the same category.
- Too many privileged group members: every account added to Domain Admins, Enterprise Admins or Administrators widens the attack surface. Forgotten memberships left over from old projects are especially dangerous.
- Over-permissive ACLs and delegation: if the right to reset an object's password or add members to a group is granted to the wrong group, it opens a hidden privilege escalation path. Unconstrained delegation is risky for the same reason.
- Service accounts with weak passwords and SPNs: any domain user can request a service ticket for an account with a registered Service Principal Name. If the password is weak, it can be guessed offline — MITRE ATT&CK describes this technique as Kerberoasting (T1558.003).
- Legacy protocols: NTLMv1, SMBv1, unsigned LDAP and RC4 encryption in Kerberos weaken modern protections and make credential theft easier.
Note
This article is written from the defender's side: the goal is to recognise weak spots and close them. Offensive testing of Active Directory is carried out only with the system owner's written authorisation, within an agreed scope, or in an isolated lab. Unauthorised testing is illegal and can disrupt services in production.
Which event IDs should defenders monitor?
The Windows Security log records AD activity in considerable detail — provided the audit policy is configured correctly. Forwarded to a SIEM, these events are the defender's main data source.
- 4624 — successful logon. Shows the logon type, the source computer and the authentication package (Kerberos or NTLM). A privileged account logging on from an unexpected host deserves attention.
- 4625 — failed logon. Many failed attempts against one account in a short time, or attempts from one source against many accounts, can indicate password guessing.
- 4662 — an operation was performed on an AD object. If auditing (a SACL) is set on the object, it records access to sensitive attributes and replication rights. A replication request from a host that is not a domain controller is a serious signal.
- 4769 — a Kerberos service ticket was requested. Shows which account obtained a ticket for which service and the ticket's encryption type. Requests for many services from one account in a short time, or requests using legacy RC4 encryption, may be an anomaly.
- 4728, 4732 and 4756 — a member was added to a security group. Every addition to a privileged group should raise an alert immediately.
A single event rarely proves an attack. The value lies in correlation: for example, a series of failed logons, then a successful logon, then an addition to a privileged group reads as one chain. A detection rule that sees such chains is far more useful than isolated alerts.
How do you detect and fix these misconfigurations?
| Misconfiguration | Why it is risky | What to monitor | How to fix |
|---|---|---|---|
| Weak and reused passwords | One password unlocks several accounts | Bursts of 4625, 4624 from an unusual source | Strong password policy, MFA, unique local admin passwords with LAPS |
| Too many privileged group members | Every extra account is a direct path to the domain | 4728, 4732, 4756 — member added to a group | Minimal membership, regular group reviews, separate admin accounts |
| Over-permissive ACLs and delegation | An invisible privilege escalation path | 4662 and 5136 — object and permission changes | ACL audits, removing unconstrained delegation |
| Weak service accounts with SPNs | The password can be guessed offline | 4769 — anomalous ticket requests, RC4 encryption | gMSA or a long unique password, AES encryption, least privilege |
| Legacy protocols | Credential theft becomes easier | NTLM package in 4624, 4776 — NTLM validation | Disabling NTLMv1 and SMBv1, LDAP and SMB signing |
None of these fixes requires a new product — most are done with built-in Windows Server features and Group Policy. The hard part is discipline: documenting each change, testing it in a staging environment and rolling it out in phases. Before disabling a legacy protocol, use the logs to find out which systems still depend on it.
How do the tiered model and least privilege help?
In a tiered administration model the infrastructure is split into three levels: Tier 0 — domain controllers and the accounts that manage AD, Tier 1 — servers and applications, Tier 2 — user workstations. The core rule is simple: an account from a higher tier never logs on to a machine in a lower tier. That way, compromising an ordinary workstation does not expose privileged credentials.
The principle of least privilege means giving each account only the rights it needs for its job. In practice that means separate everyday and privileged accounts for administrators, adding privileged accounts to the Protected Users group, denying interactive logon to service accounts and using dedicated hardened workstations for administration.
For service accounts, the most reliable option is group Managed Service Accounts (gMSA): the system generates the password itself, keeps it long and random and rotates it automatically. Where gMSA is not possible, a long unique password and enforced AES encryption are the minimum.
Why do you need regular AD security assessments?
AD is not static: every new project, staff change and hastily granted permission alters the configuration. That is why a one-off audit is not enough. A regular assessment reviews privileged group membership, ACLs, accounts with SPNs, delegation settings and the use of legacy protocols.
Alongside internal audits, an authorised pentest measures how effective the defences really are: it reveals which paths are still open and which activity stays invisible in the SIEM. From a cybersecurity standpoint, the most useful outcome is not the list of gaps found but a remediation plan for each of them.
How we do it in our lab
In Log Academy's Red Team program, Active Directory is covered as a dedicated module: Kerberoasting, ACL abuse and privilege escalation paths are studied only in a closed lab, in each student's individual virtual environment. The core principle works both ways — the student builds the scenario in the lab, then detects the same activity in their own SIEM and sees which event IDs it produces. The module closes with a report covering risk level, scope of impact and remediation steps.
Frequently asked questions
- Where should you start with Active Directory security?
- With a review of privileged group membership. Find out who is in Domain Admins and similar groups, why, and whether each account is still in use. This gives a large risk reduction for little effort.
- How can Kerberoasting be detected?
- The main source is event 4769. Ticket requests for many services from one account in a short time, and requests using legacy RC4 encryption, are suspicious. The most effective protection is gMSA or long unique passwords for service accounts.
- What is gMSA and why is it recommended?
- With a group Managed Service Account (gMSA), Windows itself generates the password and rotates it automatically. No person knows the password, so the problem of weak or never-changed passwords goes away.
- Is it legal to run a pentest against Active Directory?
- Only with the system owner's written authorisation and an agreed scope. For learning, an isolated lab is used — testing a real company network without permission is illegal.
- What background do you need to learn this topic?
- Windows and networking fundamentals, plus some log analysis experience, help. Log Academy's Red Team program is intermediate level, runs for 6 months and is designed for people with Blue Team or networking experience. A free consultation helps you pick the right level, and the first lesson is free.