how to monitor for new admin users in your org

how to monitor for new admin users in your org

TL;DR

New admin accounts are one of the highest-signal events in security: attackers create them for persistence, and insiders abuse them quietly. Baseline who is an admin today across your cloud, identity provider, and key SaaS apps, alert on every grant within minutes, and review the full list weekly. Every admin you cannot explain is an incident until proven otherwise.

how to monitor for new admin users in your org

Use this when

• You have never listed all your admins in one place
• You want alerting on privilege grants, not just logins
• A compliance or security review asks "who has admin and why"
• You suspect stale or mystery admin accounts exist

Not for this skill when

• You need full identity governance or access certification (bigger program, different skill)
• You are designing the admin role model itself (do that first, then monitor it)
• You only care about one SaaS app's admins (use that app's audit log directly)
• You need real-time blocking of grants (that is policy enforcement, not monitoring)

Steps

1. Define what counts as admin in each system

Admin means different things per system: full admin policy in AWS, Global Admin in your identity provider, owner in GitHub, super admin in Google Workspace. Write the list down; you cannot alert on what you have not defined.

printf 'aws: AdministratorAccess policy\nidp: Global Admin role\ngithub: org owner\nworkspace: super admin\n' | tee admin-definitions.txt

Expected: a short list mapping each system to its admin-level roles. If two people define "admin" differently, the monitoring will have holes; agree once, in writing.

2. Baseline the current admins

Pull the actual admin list from each system today. Expect surprises; every org finds accounts it forgot about.

aws iam list-entities-for-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --query "[PolicyGroups[].GroupName, PolicyUsers[].UserName, PolicyRoles[].RoleName]"

Expected: every user, group, and role with full admin. Save the output as your baseline file; every future alert gets compared against it. (AWS CLI v2.)

3. Alert on every admin grant

Watch the audit log for privilege-grant events and alert within minutes. In AWS that is AttachUserPolicy, AttachRolePolicy, AttachGroupPolicy, and adding users to admin groups; your identity provider and SaaS apps have equivalents.

aws cloudtrail lookup-events --start-time $(date -u -d '1 hour ago' +%FT%TZ) --max-items 200 | tee grants.json | grep -c "AttachUserPolicy"

Expected: a count of recent policy-attachment events (0 is normal). Wire this lookup into alerting on a 5 to 15 minute schedule and alert on any nonzero count; a daily digest is too slow for persistence mechanisms.

4. Run a weekly review of the full list

Automation catches events; humans catch drift. Once a week, someone with authority looks at the whole admin list and confirms every entry is still needed and still owned by the right person.

echo "$(date -u +%F) admin review: [N] admins, [N] removed, [N] questioned" | tee -a admin-review-log.txt

Expected: one log line per week and a shrinking list. Anyone who cannot say why an account is admin gets it removed; "just in case" is not a reason to keep privilege.

5. Remove or justify every unexplained admin

For each admin you cannot explain: disable first, ask questions second. Break-glass accounts stay but get sealed: monitored, rarely used, with every use generating an alert.

printf 'unexplained: [account]\naction: disabled [date]\nowner: [name]\n' | tee -a admin-cleanup.txt

Expected: zero unexplained admins. Break-glass accounts are documented, their credentials sealed, and any use pages someone. Re-run the baseline after cleanup; the list should be boring.

Variant: GitHub org owners and SaaS super-admins

Same pattern, different API: list org owners from the platform's admin audit log and alert on owner additions. SaaS admin grants often hide in the app's own audit log rather than your identity provider, so check both.

Variant: just-in-time admin elevation

If you use just-in-time elevation, monitor the elevation grants instead of static roles, and alert on elevations that outlast the policy or happen outside change windows. The baseline becomes "who is elevated right now".

Variant: you found an admin you did not create

Treat it as an incident: do not just remove it. Preserve the audit trail of when it was created and by what, check what it touched, then disable it and investigate. An unknown admin is evidence, not just hygiene.

Why this happens

Admin sprawl is the default: someone gets temporary admin for a migration and keeps it, a script creates a service admin nobody tracks, an ex-employee's account lingers. Attackers know this, which is why creating a new admin is step one of persistence after initial access; it survives password resets and looks legitimate. Monitoring grants closes the loop: legitimate changes are expected and explainable, everything else gets investigated.

Edge cases and pitfalls

• Group-nested admin: the user is not directly admin but sits in a group that is; resolve group membership, not just direct grants.
• Break-glass accounts look like unexplained admins to automation; allowlist them explicitly and alert on their use instead.
• Federated admin via SSO: the grant happens in the identity provider's group mapping, not in the target system; monitor the provider side.
• Alert on grants, not just on "is admin" snapshots; a grant that is quickly reverted still happened and still matters.
• Ownerless service accounts with admin are the worst kind; inventory them separately with a documented owner each.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst5t2emsjXjNj2BjVpO-tqA