Windows - Security - Disable Local Administrator

What the Local Administrator Disabler does

This Automox Worklet™ disables the built-in local Administrator account on Windows endpoints. The default Administrator account (SID ending in -500) exists on every Windows installation and represents a well-known target for attackers. Disabling this account forces administrators to use named accounts with individual accountability.

The Worklet uses WMI via Get-CimInstance to query the Win32_UserAccount class and verify account status. It checks whether the specified account is disabled and only takes action when the account is currently enabled. Set-CimInstance applies the configuration change to disable the account.

You can adapt this Worklet to disable any local account by changing the $accountName variable. This flexibility allows you to use the same Worklet pattern for disabling Guest accounts, service accounts that should be disabled, or any other local account that poses a security risk when enabled.

Why disable the local Administrator account

The built-in Administrator account exists on every Windows system with a predictable SID ending in -500, making it a consistent target for attackers. Brute force attacks, pass-the-hash exploits, and credential stuffing campaigns focus on this account because they know it exists regardless of system configuration. Organizations that rename the account still remain vulnerable since attackers enumerate local accounts by SID to find the -500 account regardless of its name. Audit logs show generic "Administrator" entries instead of individual user identities, preventing accountability and complicating incident investigation.

This Automox Worklet disables the built-in Administrator account to eliminate this attack vector while preserving administrative access through named administrator accounts. The approach provides stronger protection than renaming and helps meet CIS Benchmarks, NIST 800-53, and DISA STIG requirements for security hardening. You gain individual accountability for administrative actions in audit logs, showing which specific administrator performed each action instead of generic "Administrator" entries, improving incident investigation and compliance reporting.

How local Administrator disabling works

1. Evaluation phase: The Worklet queries Win32_UserAccount using Get-CimInstance to find the account matching $accountName (default: 'Administrator'). If the account does not exist, evaluation exits compliant. If the account exists and the Disabled property is True, the endpoint is compliant. If the account exists and Disabled is False, remediation is triggered.

2. Remediation phase: The Worklet retrieves the account object, sets the Disabled property to True, and applies the change using Set-CimInstance. It then re-queries the account to verify the disabled state was successfully applied. The change takes effect immediately without requiring a reboot.

Local Administrator disabling requirements

• Windows 7 or later, Windows Server 2008 R2 or later

• PowerShell 3.0 or later

• Administrative privileges to modify local accounts

• Another local administrator account must exist for system administration

• Domain-joined endpoints should use domain admin accounts for administrative access

Expected account state after remediation

After completion, the built-in Administrator account is disabled and login attempts fail with an error message indicating the account cannot be used. The account remains in the local user database with its SID and properties intact, allowing re-enablement through other administrative accounts if needed for recovery. Named administrator accounts continue functioning normally and provide administrative access to the endpoint.

Verify the account status by running Get-LocalUser Administrator | Select-Object Name,Enabled in PowerShell, which shows Enabled: False when successful. Check Computer Management > Local Users and Groups to see the account with a down arrow icon indicating disabled status. Test by attempting to log in with the Administrator account, which fails at the login screen. Note that Windows Safe Mode may still permit access to disabled Administrator accounts on some configurations, so set a strong password on the disabled account as an additional security layer.

How to validate disable local administrator changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for disable local administrator.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as Set-CimInstance, Get-CimInstance, Write-Output.

4. Validate remediation effects from script operations such as Set-CimInstance, Get-CimInstance, Write-Output, then rerun evaluation for compliance.