Windows - Security - Rename Built-In Guest Account

What the Guest Account Renamer does

This Automox Worklet™ renames the built-in Guest account on Windows endpoints. The Guest account is a well-known local user account present on every Windows system, and by default it requires no password, making it a prime target for attackers seeking unauthorized access to system resources.

By renaming the Guest account to an obscure name, you remove a predictable attack vector that threat actors actively target. The Worklet uses PowerShell to detect the account and apply the new name consistently across your Windows fleet.

The Worklet supports renaming any local Windows account, not just the Guest account. You configure the source account name and target account name using PowerShell variables, allowing flexible customization for your security policies.

The Worklet supports renaming any local Windows account, not just the Guest account. You configure the source account name and target account name using PowerShell variables, allowing flexible customization for your security policies.

Why rename the Guest account on your endpoints

The built-in Guest account exists on every Windows system and is commonly exploited in account enumeration attacks. Attackers use scripts that attempt to authenticate as 'Guest' to enumerate valid local accounts and test for weak or missing passwords. Renaming this account breaks these automated attack patterns.

Many security frameworks and compliance standards recommend removing or hardening well-known accounts as a defense-in-depth measure. Renaming the Guest account aligns with security best practices recommended by NIST and CIS Benchmarks, improving your overall security posture without requiring account deletion.

This is particularly important for organizations managing large endpoint fleets where manual account management is impractical. Automox orchestrates the renaming across hundreds or thousands of endpoints simultaneously, verifying consistent security policy enforcement.

How Guest account renaming works

1. Evaluation phase: The Worklet queries the endpoint using PowerShell's Get-LocalUser cmdlet to check if the target account (default: Guest) exists. If found, the endpoint is flagged for remediation. If the account is already renamed or does not exist, the endpoint is marked compliant and the evaluation ends.

2. Remediation phase: The Worklet uses the Rename-LocalUser PowerShell cmdlet to rename the account to your specified new name. The operation includes error handling to catch and report any failures, and returns exit code 0 for success or 1 for failure. The script handles both 32-bit and 64-bit PowerShell environments automatically.

Guest account rename requirements

• Windows 10 or later, or Windows Server 2016 and newer

• PowerShell 5.1 or higher

• Administrative privileges required to rename local user accounts

• Configure $oldAccountName variable to match your target account (default is Guest)

• Configure $newAccountName variable with the desired account name in remediation script

Expected guest account state after remediation

After the Worklet runs successfully, the Guest account on affected endpoints will be renamed to your specified account name. The account remains active and functional but is no longer discoverable through standard account enumeration attempts targeting the well-known Guest name.

You can verify remediation by checking local user accounts in Windows Settings or by running Get-LocalUser in PowerShell. The original Guest account should no longer exist, replaced by the new account name you specified. This change persists across endpoint restarts and future Automox scans will report the endpoint as compliant.

How to validate rename built-in guest account changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for rename built-in guest account.

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 Built-In, Get-LocalUser, Write-Output.

4. Validate remediation effects from script operations such as Built-In, Get-LocalUser, Rename-LocalUser, then rerun evaluation for compliance.