Windows - Security - Disable Local Administrator

What the Local Administrator Disabler does

This Automox Worklet™ disables the built-in local Administrator account on Windows workstations and servers. The default Administrator account exists on every Windows installation and carries the well-known relative identifier 500, so its security identifier always ends in -500 regardless of the local domain or machine name. Disabling it forces every administrative action through a named account that maps back to a real person in the audit log.

The evaluation script queries Win32_UserAccount through Get-CimInstance with a filter on Name='Administrator'. If the account is missing, the endpoint exits compliant. If the Disabled property is already True, the endpoint exits compliant. Only when the account exists and is currently enabled does the Worklet flag the endpoint for remediation. The remediation script pipes the same CIM instance through ForEach-Object, sets Disabled to $true, and applies the change with Set-CimInstance. It then re-queries the account to confirm the new state before exiting 0, or returns exit code 1 if the disable fails or the catch block trips.

Although the default target is the Administrator account, the $accountName variable can be retargeted to any local account. The same Worklet pattern works for the built-in Guest account, dormant local service accounts, or any user account that should be disabled rather than deleted. The Worklet only ever acts on a single account name per run, so a policy targeting multiple accounts should be split into separate Worklets.

Why disable the built-in Administrator account

Every Windows endpoint ships with the local Administrator account, and every attacker knows it. The account uses a fixed relative identifier of 500, so even when the account is renamed, an attacker who can enumerate local SIDs through PowerShell (Get-LocalUser | Where-Object SID -Like '*-500'), through the Win32_UserAccount class, or through SAMR over the network can locate the original Administrator account immediately. That predictability is what makes the account a permanent target for password spray, brute force against SMB and RDP, and pass-the-hash chains that reuse a leaked local hash across the fleet. CIS Microsoft Windows 10 Benchmark control 2.3.1.1, which sets the Accounts: Administrator account status policy to Disabled, codifies exactly this guidance. DISA STIGs and NIST 800-53 AC-2 expect the same control.

This Worklet runs the CIM-based disable on every Windows endpoint in scope and records the result in the Automox activity log for change-control evidence. The Get-CimInstance check is idempotent, so repeat runs are cheap on already-hardened hosts. Any new laptop, server, or VM template that joins the fleet with the default Administrator enabled re-converges on the next evaluation, satisfying CIS Benchmark control 2.3.1.1 with deterministic per-host evidence rather than spot checks.

How built-in Administrator disabling works

1. Evaluation phase: The Worklet calls Get-CimInstance -ClassName Win32_UserAccount -Filter "Name='$accountName'" with $accountName defaulting to 'Administrator'. If the query returns $null, the account does not exist on this endpoint and the script exits 0 (compliant). If the returned object has Disabled = $true, the endpoint is already hardened and exits 0. If Disabled = $false, the script writes a remediation message to stdout and exits 1, which queues the remediation script for the next policy interval.

2. Remediation phase: The remediation script re-runs the same Get-CimInstance query, then pipes the account object through ForEach-Object and sets both LocalAccount = $true and Disabled = $true before applying the change with Set-CimInstance -CimInstance $_. After the change, the script re-queries the account and checks the refreshed Disabled property. A True value returns exit code 0; anything else returns exit code 1. The entire flow is wrapped in a try/catch that captures the exception message into stdout so the Automox activity log shows the failure mode instead of a silent non-zero exit. No reboot is required; the disable takes effect on the next logon attempt.

Built-in Administrator hardening requirements

• Windows 7 or later on workstations, Windows Server 2008 R2 or later on servers (every supported Windows SKU exposes Win32_UserAccount through CIM)

• PowerShell 3.0 or later for Get-CimInstance and Set-CimInstance (PowerShell 5.1 ships in-box on Windows 10 and later)

• The Automox agent runs as SYSTEM, which already has the rights to modify local accounts; no additional credentials needed

• At least one other local member of the Administrators group, or a domain administrator on domain-joined endpoints, so recovery access survives the disable

• Optional: set a long random password on the disabled account before running this Worklet, because Windows Safe Mode can re-enable a disabled built-in Administrator under specific conditions

• Optional: change $accountName in both evaluation.ps1 and remediation.ps1 to target a different local account; the scripts only operate on a single account per run

Expected built-in Administrator state after remediation

After a successful remediation, the local Administrator account is disabled but not deleted. The SID, group membership, profile, and any stored credentials remain intact, so an authorized administrator can re-enable the account later if a recovery scenario calls for it. Interactive logon attempts (RDP, console, and runas) for the account fail with the message "Your account has been disabled. Please see your system administrator." Named members of the local Administrators group continue to log on normally and run elevated tasks through UAC.

Validate the change directly on the endpoint with Get-LocalUser Administrator | Select-Object Name, Enabled, which returns Enabled : False on a hardened endpoint. The CIM path returns the same answer through Get-CimInstance -ClassName Win32_UserAccount -Filter "Name='Administrator'" | Select-Object Name, Disabled. Either query is a clean evidence artifact for a CIS 2.3.1.1 audit. The Local Users and Groups MMC snap-in (lusrmgr.msc) shows the account with a downward arrow on the icon. Running the Worklet again on a compliant endpoint returns exit code 0 on the evaluation script without invoking remediation, which is how scheduled policies keep the account disabled across image refreshes and provisioning drift.