Detecting unmanaged accounts via group audit

Detecting unmanaged accounts via group audit: advanced comparison guide for AD, Entra, SIEM, and PAM

Detecting unmanaged accounts via group audit means using group membership changes and “who got added where” telemetry to surface identities that operate outside expected governance: accounts not onboarded to PAM, not tied to HR/ITSM ownership, not covered by standard controls, or not behaving like a managed identity. In plain terms: it’s finding the accounts that can take power because they slipped past process.

This matters now because identity estates are rarely “one directory.” Most environments are hybrid: on-prem Active Directory, cloud identity in Microsoft Entra ID, SaaS groups, and a growing layer of machine identities. In that world, the fastest privilege escalation is often not “exploit a vulnerability,” but “land an account, then join (or get added to) the right group.” Group audit is one of the cleanest signals that privilege moved.

This is also a comparison problem. There are multiple ways to “do group audit,” and each produces different truth: Entra audit logs show cloud group actions; domain controller security logs show on-prem group membership changes; SIEM correlation turns raw events into detections; PAM platforms like CyberArk can highlight privileged use that bypasses vaulting through unmanaged privileged account (UPA) detection.

The goal here is not a basic tutorial. The goal is a defensible detection strategy that holds up when attackers are deliberate, admins are busy, and “unknown” identities multiply.

What “unmanaged” really means (and why the surface definition fails)

“Unmanaged account” is often misunderstood as “stale account” or “orphaned user.” Those are unmanaged sometimes, but the more dangerous class is active, privileged, and outside the control plane. An account can be active and legitimate, yet unmanaged: a break-glass admin created years ago, a vendor account left in a privileged group, a service account that never got onboarded to a vault, or a local admin that bypasses centralized governance.

A more useful definition is operational:

Managed means the account has known ownership, lifecycle controls, and expected telemetry paths.
Unmanaged means the account’s ownership, lifecycle, or control path cannot be proven reliably.

That second clause matters: unmanaged is often a negative space problem. The signal is not just “this account exists,” but “this account exists and it is missing from the systems that should define it.” Group audit is ideal for this because privilege generally flows through groups. When a group changes, privilege can change instantly, even if the account itself is old.

Why group audit is the highest-signal hunting method

Most identity monitoring dies in noise. Logon events are constant. Authentication failures are constant. File access is constant. Group changes are not constant. In healthy environments, membership changes in privileged groups are relatively rare and highly meaningful. That rarity makes group audit a “high-signal, low-volume” source—perfect for detection engineering.

The key is to treat group audit as more than “review a report.” Effective group audit answers four questions:

What changed? (membership, group type, group role assignment, nesting)
Who did it? (actor, tool used, session context)
What privilege did this create? (effective permissions after nesting and role mappings)
Is the resulting identity governed? (PAM onboarded, owned, monitored, and constrained)

That last step—governed or not—is where unmanaged accounts surface. Without it, group audit becomes a compliance checklist instead of a threat-hunting system.

Core mechanisms and first principles

Under the hood, detecting unmanaged accounts via group audit relies on three irreducible truths:

Privilege is mediated through membership and assignment. In Active Directory and Entra, rights are rarely granted to individuals directly; they’re granted to groups, roles, and scopes. That means group events are privilege events.
Membership changes are time-bound truth. A snapshot of “who is in Domain Admins” is useful, but it doesn’t prove how it happened. Audit events provide the “how” and “when.” That’s crucial for incident response and for detecting suspicious patterns (like rapid add-remove sequences).
Unmanaged is a correlation finding. It is proven by mismatch: group membership shows privilege, but HR/IAM/PAM does not show governance. Detection is the join between systems, not the report from one system.

These principles explain why many “audit once per quarter” programs miss real risk. Attackers do not wait for quarterly audits. They exploit the time between membership changes and governance validation. The modern approach is continuous delta monitoring: detect group changes as they happen, enrich them immediately, and decide whether they created unmanaged privilege.

Comparison: where group audit data comes from (and what each source can prove)

“Group audit” can mean different telemetry depending on platform. The differences matter because each source has blind spots.

Microsoft Entra ID audit logs (cloud truth)

Entra audit logs record traceable activities in the tenant, including group changes and role-related actions, and are commonly used to determine who made changes to groups and memberships. Microsoft documents audit log categories and activities in Entra’s audit log activity reference. (Microsoft Entra audit log activity reference)

Entra is strong at showing cloud-native membership and role changes. It is weaker at proving on-prem group nesting effects unless those memberships are synchronized and interpreted correctly. Entra is also the place where “guest” and “external collaborator” risk shows up sharply, because these identities may not appear in on-prem tooling at all.

Active Directory domain controller security logs (on-prem truth)

Domain controllers produce security events for group changes when the appropriate audit policies are enabled. For example, event 4728 logs a member being added to a security-enabled global group, and event 4729 logs a member being removed. Local group membership changes can appear as event 4732.

On-prem logs are strong for AD-native groups and can capture changes performed via many tools, including legacy administration pathways. They are weaker at “identity governance context” without enrichment (ownership, HR status, PAM onboarding).

SIEM detections (correlated truth)

SIEM tooling is where unmanaged detection becomes realistic because correlation can join group events with “who is managed.” Splunk’s security content includes analytics for privileged group modification that can be adapted into unmanaged-account detections. (Splunk Security Content: Windows Privileged Group Modification)

SIEM is not inherently “more accurate,” but it is where accuracy becomes possible because it can enrich events with inventory, identity governance data, and PAM status.

PAM / CyberArk UPA detection (control-plane truth)

PAM platforms can detect privileged activity that bypasses vaulting. CyberArk’s unmanaged privileged accounts (UPA) detection is designed to alert when a privileged account not managed by the CyberArk PAM Vault connects to a target machine. (CyberArk UPA overview)

This is a different kind of signal: it is not “a group changed,” but “privileged behavior occurred outside expected PAM control.” In unmanaged-account programs, that’s gold—because it reveals identities that matter in practice, not just in directory theory.

Hero technical section: a practical, high-precision detection architecture (step-by-step)

The most reliable way to detect unmanaged accounts via group audit is to build a pipeline that does five things continuously: capture group changes, expand effective privilege, normalize identity records, compare against governance sources, and alert on the mismatch. The details below are designed to be implementable in real environments.

Step 1: define “privileged groups” as a living inventory (not a static list)

Start with obvious high-impact groups (Domain Admins, Enterprise Admins, Schema Admins, built-in Administrators, etc.), but treat this as a graph problem. Privilege can be inherited through:

Nested groups (group inside group)
Local admin rights granted to a domain group on servers
Role assignment groups in Entra (PIM-eligible groups or role-assignable groups)
Application-specific privileged groups (backup operators, virtualization admins, database admins)

A strong approach is to maintain:

Tier 0: identities that control identity (domain controllers, federation, privileged role admins)
Tier 1: identities that control servers and core workloads
Tier 2: identities that control endpoints and user compute

This tiering aligns with common AD security models and makes detection prioritization much easier. For deeper background, see related topics like tiered administration and privileged access strategies (for example, Wikipedia’s overview of least privilege).

Suggested internal reading on Windows Active Directory (interlink aggressively as a cluster): Active Directory guides, Active Directory security, Active Directory auditing, AD hardening, Group Policy, SID concepts.

Step 2: enable and validate the right audit policies for group events (AD)

On Windows, “Security Group Management” auditing is specifically designed to generate events when members are added or removed from security groups. Microsoft documents the subcategory and its recommendations in “Audit Security Group Management.” (Microsoft: Audit Security Group Management)

In practice:

Enable Advanced Audit Policy Configuration on domain controllers.
Enable success auditing for security group management events.
Confirm events are generated for test membership changes.
Forward the security log to your SIEM (Windows Event Forwarding, agent, or collector).

The critical event families typically include:

4728 / 4729 for global security groups (add/remove) (4728, 4729)
4732 / 4733 for local security groups (add/remove) (4732)
4756 / 4757 for universal security groups (common in multi-domain designs)

Practical parsing matters. Many teams ingest events but fail to extract fields like “Subject” (actor) and “Member” (target) cleanly. If field extraction is weak, unmanaged detection becomes guesswork.

Step 3: capture Entra group audit actions (cloud)

Entra provides tenant audit logs that include group activity. Microsoft provides a reference for audit activities, which helps confirm what “activityDisplayName” values exist and how group actions appear. (Entra audit activities reference)

A practical automation pattern is to query audit logs for “Add member to group” and “Remove member from group” actions and then enrich each log record with the resolved group name and member identity.

One implementation example uses Microsoft Graph PowerShell to query “Add member to group” audit events and resolve the group details. (Track Add Member to Group events via Graph PowerShell)

Even if the environment uses UI-based review, the long-term goal should be automation. Manual review is too slow for the cadence of modern identity change.

Step 4: build an “effective privilege” expander (the part most programs skip)

A membership change in an “innocent” group can create Tier 0 access via nesting. Therefore, unmanaged detection should evaluate effective privilege, not just direct membership.

Effective privilege expansion typically requires:

Recursive group membership expansion (group contains group contains user)
Cross-checking where groups are assigned rights (server local administrators, GPO user rights assignments, delegated OU control)
Cloud role assignments tied to groups (role-assignable groups, PIM activations)

This is where many teams stop too early because it feels complex. But complexity is exactly what attackers exploit.

Practical approach:

Maintain a “privilege map” table that links: group → privilege tier → scope → reason.
When an event adds a member to a group, resolve whether that group is in the privilege map, or whether it nests into a mapped group.
Tag the resulting identity with “effective tier” and “effective scope.”

The output should read like: “User X became effectively Tier 0 because group A nests into group B (Domain Admins).” That statement is far more actionable than “User X was added to group A.”

Step 5: define “managed” using multiple authoritative sources (not one)

Unmanaged detection becomes reliable when “managed” is defined by more than one system. Common sources include:

HR source of truth (employee status, department, manager, joiner/mover/leaver lifecycle)
IAM governance (access reviews, approvals, attestation)
PAM onboarding (vaulted credential, rotation policy, session recording)
ITSM ownership (service account ticket, business owner, renewal dates)

An account that is “known to AD” but unknown to HR/IAM/PAM is not automatically malicious—but it is unmanaged until proven otherwise. This is how mature identity teams prevent “ghost admin” drift.

Step 6: implement UPA detection to catch privileged use outside vaulting (CyberArk)

CyberArk’s UPA detection is designed to surface privileged accounts that connect to machines while not being managed by the vault. This directly addresses “unmanaged privileged accounts.” (CyberArk UPA overview)

Configuration guidance is also documented by CyberArk, including enabling detection and setting risk scoring. (Configure UPA detection (ISI), Configure unmanaged privileged accounts (Identity Protection))

Why this matters for group audit: group audit tells you privilege was granted; UPA tells you privilege was used outside control. If a newly privileged identity triggers UPA activity, that’s a high-confidence unmanaged pathway.

CyberArk also describes conditions under which unmanaged accounts are considered privileged in alerting contexts. (UPA alerts overview)

Step 7: SIEM correlation rules that actually detect unmanaged accounts (not just group changes)

Many SIEM dashboards stop at “show group changes.” That’s not unmanaged detection; that’s a feed. Unmanaged detection needs rules that join the feed with governance truth.

A practical baseline detection is:

Trigger: member added to privileged group OR role-assignment group
Enrich: resolve identity type (human, guest, service, workload), owner, HR status, PAM status
Decide: if PAM = false OR owner = null OR lifecycle state = unknown → flag unmanaged

For Splunk environments, there are public patterns for building searches around events like 4728/4729, and community discussions show how teams shape queries around membership add/remove events. For example: (Splunk Community discussion on AD security group changes, Example Splunk query for users added/removed from groups)

For Microsoft Sentinel / Log Analytics, a common approach is periodic queries over SecurityEvent for 4728 on domain controllers, which can trigger notifications when new members are added to Domain Admins. (Sentinel-oriented approach using Event ID 4728)

The “unmanaged” part requires one more join: a lookup table of managed identities (PAM onboarded, HR-backed, approved service accounts). That lookup can be maintained from IAM exports, CyberArk inventory, or ITSM.

Step 8: implement “diff-based” state monitoring to catch silent drift

Audit events are excellent, but they aren’t perfect in all environments. A complementary approach is state diffing: snapshot privileged group membership at a schedule (hourly or daily), then compute the delta. This catches cases where event ingestion failed, forwarding broke, or administrators used paths that didn’t generate expected telemetry.

Techniques to automate this exist, including scripts that compare group membership over time and alert on differences. (PowerShell diff-based notification pattern, Monitoring group membership changes approach)

The best programs use both: event-based detection for immediacy, and state-diff validation for integrity.

Step 9: triage playbook for “unmanaged privilege created” alerts

When detection fires, response needs to be consistent. A strong triage flow:

Confirm the change: validate membership in directory right now (don’t rely on old logs).
Identify the actor: who performed the addition, via event Subject / Entra actor fields.
Classify the identity: human, guest, service, workload; determine its owner and business purpose.
Check governance: is it in PAM? is it under MFA? is it in access review scope?
Assess blast radius: what systems does this group control (tier mapping)?
Contain if needed: remove membership or disable account pending verification.
Fix the gap: onboard to PAM / assign owner / enforce lifecycle controls.

This playbook avoids the most common failure mode: treating alerts as “FYI.” Unmanaged privilege is a state that must be resolved, not just observed.

Implications: the design tendencies that produce unmanaged accounts

Unmanaged accounts aren’t just “human mistakes.” They emerge from structural tendencies in identity systems and organizations.

Privilege sprawl is the default state

In large estates, groups proliferate. Projects create groups. Apps create groups. Admins create temporary groups that become permanent. Each group becomes a container for permissions. Over time, the privilege model becomes a patchwork, and unmanaged privilege sneaks in through nested membership and forgotten access paths.

Hybrid identity creates “control-plane gaps”

On-prem AD may be audited differently than Entra. PAM may cover domain admins but not local admins. IAM may govern employees but not vendors or guests. Each seam creates a place for unmanaged accounts to live.

Service accounts and automation identities resist governance

Many environments treat service accounts as exceptions: “no MFA,” “long-lived secrets,” “don’t rotate or the app breaks.” That exception culture is a factory for unmanaged privileged identities. Group audit is one of the few methods that can reliably surface when service accounts creep into privileged groups.

Audit data is often collected but not interpreted

Teams may ingest events like 4728/4729 but fail to convert them into “effective privilege changed” logic. Without privilege mapping, group audit produces activity reports, not risk signals.

Expert mental models: how mature teams think about unmanaged accounts

1) negative space is signal

The strongest unmanaged detection logic doesn’t just ask “who changed?” It asks “why isn’t this identity present in the systems that should define it?” If an account is privileged but absent from HR, absent from ITSM ownership, and absent from PAM onboarding, it is unmanaged until proven otherwise.

2) privilege by proxy

Privilege is often inherited indirectly. Experts assume the privilege model is a graph, not a list. That’s why recursive group expansion and role-scope mapping are non-negotiable.

3) continuous deltas beat periodic audits

Quarterly audits find structural issues but miss attacker timelines. Continuous group delta monitoring shortens the window from “privilege granted” to “privilege questioned.”

4) prove ownership, not just identity

Identity security is as much governance as technology. Mature programs demand a named owner, renewal date, and justification for each privileged identity. If any of those are missing, the account is unmanaged operationally, even if it is technically “known.”

Misunderstandings, risks, and correctives

Misunderstanding: “unmanaged equals inactive”

A dormant unmanaged account can be the most valuable to attackers: it is less watched, less used, and less likely to trigger behavior baselines. “Inactive” is not “safe.” It often means “unnoticed.”

Misunderstanding: “monitoring privileged groups is enough”

Privilege is also created through delegated control, GPO user rights assignments, server-local admin grants, and cloud scopes. Privileged groups are the starting point, not the finish line.

Risk: log gaps and ingestion failures create false confidence

If event forwarding breaks for a day, group audit can miss the one membership change that mattered. That’s why diff-based state snapshots should backstop event-based detections.

Risk: alert fatigue from “all group changes” detections

Alerting on every group membership change is a fast path to silence. The corrective is precision: alert on privilege map changes, and escalate only when governance mismatch exists.

Expert essentials checklist (non-negotiables)

Maintain a privilege map of groups → tiers → scopes.
Expand membership recursively; treat nesting as a first-class risk.
Correlate group changes with governance sources (HR/IAM/PAM/ITSM).
Use both event-based detection and diff-based validation.
Include guests, vendors, and service accounts explicitly in identity classification.
Track not only “added” but “used”: add PAM/UPA signals where available.

Applications: how this changes identity operations (and what comes next)

Once group audit is used to detect unmanaged accounts, it stops being “security monitoring” and becomes a driver of operational maturity. It forces improvements in:

Access request workflows: membership changes become tied to approvals and ownership records.
Privilege hygiene: high-risk groups become stable, not constantly edited.
PAM onboarding: privileged identities that matter in practice are brought into the vault.
Incident response speed: investigations become faster because “who changed what” is already structured.

The forward direction is clear:

More environments will treat identity as code and constrain who can create privileged memberships.
UPA-like detections will expand beyond human accounts to machine identities and ephemeral credentials.
Continuous access evaluation will push organizations toward real-time decisions, not periodic reviews.

For broader context on modern identity defense, consider Wikipedia references like zero trust and privileged access management.

Conclusion: group audit is not a report, it’s a control

Detecting unmanaged accounts via group audit works because it targets the moment privilege changes hands. It is one of the highest signal paths to finding hidden admins, ungoverned service accounts, risky guest memberships, and privilege drift.