Audit Local Administrator Accounts

What the privileged admin account auditor does

This Automox Worklet™ enumerates the local Administrators group on each Windows endpoint in scope and writes the membership to the Automox activity log. The evaluation script queries Win32_Group for the Administrators group through Get-CimInstance, follows the Win32_GroupUser association to pull each member account, and exits 1057 to flag the endpoint for remediation whenever members are returned. The remediation script repeats the lookup, projects each member's Caption onto a PSCustomObject, and renders the list as a Format-Table in the activity log so the audit output is readable on the policy run page.

The Worklet is read-only. It does not remove accounts, modify group membership, or rotate passwords. Because the remediation phase never changes endpoint state, the policy is safe to schedule against the entire fleet on a tight recurring cadence (daily during a privileged-access review, hourly during an incident response window) without the risk of surprise privilege changes on production servers.

Pair the audit with a separate remediation Worklet that removes unexpected accounts from BUILTIN\Administrators so the security team can act on findings during the same change window the audit surfaces them in.

Why audit local admin accounts at fleet scale

Local admin sprawl is one of the quietest privilege-escalation paths on a Windows fleet. A help-desk session three years ago added a user to local Administrators to unblock an installer; the user kept their account but no one took the privilege back. A contractor's domain account stayed in the Administrators group long after their engagement ended because no offboarding process touched per-endpoint groups. A vendor support visit left a local service account behind. Every one of those leftover accounts is a foothold an attacker who lands on the endpoint can claim.

Local Administrators membership compounds quietly. A vendor installer adds an OEM service account, a help-desk technician temporarily promotes a user during a break-fix, an old MDM enrollment leaves a stale principal behind. Schedule this read-only Worklet through your privileged-access review policy to enumerate BUILTIN\Administrators on every Windows endpoint and stream the results into the activity log, so the next least-privilege review starts from a current per-endpoint roster instead of from a guess. The control maps cleanly to CIS Control 6 (Access Control Management) and NIST 800-53 AC-6 (Least Privilege).

How the admin account audit works

1. Evaluation phase: The Worklet checks that PowerShell 3.0 or higher is available, then calls Get-CimInstance -ClassName win32_group -Filter "Name = 'Administrators'" piped into Get-CimAssociatedInstance -Association win32_groupuser to retrieve every account in the local Administrators group. If any members come back, the script writes "Local administrator accounts detected. Flagging for remediation." and exits 1057 to mark the endpoint non-compliant. If the group is empty, it writes a no-results message and exits 0.

2. Remediation phase: The remediation script repeats the same CIM query, reads the Caption property from each returned member (the DOMAIN\user or COMPUTER\user form Windows assigns to the principal), wraps each value in a PSCustomObject with a "Local Administrators Accounts" property, and pipes the collection through Format-Table -AutoSize. The resulting table is what Automox surfaces in the activity log. No accounts are removed, no group membership is changed, and no passwords are rotated.

Admin account audit requirements

• Windows 8, Windows Server 2012, or later (Windows 10, Windows 11, Server 2016, 2019, 2022, 2025 all qualify)

• PowerShell 3.0 or higher available on the endpoint (the script self-checks $PSVersionTable.PSVersion and exits 0 with an "Unsupported PowerShell version" message on older builds)

• The Automox agent runs in the default SYSTEM context, which has read access to win32_group and win32_groupuser through the CIM/WMI repository

• Activity log ingestion into a SIEM if the retention window is shorter than your audit cadence, since the per-endpoint table is straightforward to parse downstream

• A documented response procedure for non-compliant endpoints so a finding of "unexpected member in Administrators" routes to a remediation Worklet rather than sitting in the activity log

Expected audit output

After the Worklet runs, the activity log for each endpoint shows a table titled "Local Administrators Accounts" containing one row per member. Each row holds the Caption that win32_groupuser returns, typically DOMAIN\user for domain principals or COMPUTER\user for purely local accounts. Endpoints with any members are flagged non-compliant via exit code 1057 so the policy's compliance view highlights them; endpoints with an empty Administrators group exit 0 and report compliant.

Validate the Worklet on a single endpoint by running net localgroup Administrators in an elevated shell and confirming the principals match the table. For audit evidence, route the activity log into a SIEM dashboard that filters non-compliant runs and pivots on the unexpected member name. If a previously-clean endpoint suddenly shows a new Administrators member, the most common causes are a recent help-desk ticket, a vendor support session, or a Group Policy refresh that promoted a domain group into the local group; the audit data points the investigation at the right thread.