The Unwanted Guest

Most everyone who’s been involved in incident response or read publicly available incident write-ups is aware that threat actors will often compromise user accounts through brute force attacks or some other method, or even create new user accounts on compromised systems, often using similar passwords across different incidents.

An interesting variation on this is the use of the built-in Guest account. This is an account that’s included in the default installation of Windows, and as illustrated in Figure 1, is disabled by default when the operating system is installed. As such, it’s an account that system administrators are used to seeing; that is, it doesn’t stand out, and doesn’t set off any alarms. 

Figure 1: Guest Account Settings

Now, to be clear, what we’re talking about here is the built-in Guest account; this isn't about maintaining persistence via RID hijacking, and this isn't about guest-level access to systems. Specifically, what we’re referring to in this article is the built-in Guest account found in the SAM database on Windows systems, as illustrated in Figure 2.

Figure 2: Windows 11 Local Users

Huntress analysts have seen a number of incidents since the beginning of 2025 where the threat actor enabled the Guest account through the use of a command line such as the following:

net user Guest /active:yes

Once the account has been enabled, the threat actor will then change the password to something of their choosing, and then modify the account even further, such as by adding it to the Local Administrators and Remote Desktop Users groups, elevating the privileges of the account as well as allowing it be used for remote access.

During one incident in particular, among their other activities, the threat actor installed the AnyDesk application, enabled the Guest account, and changed the password to a variation of something that Huntress analysts had observed during previous incidents.

Huntress analysts recently observed another incident in which the threat actor enabled the Guest account, added it to the Local Administrators group, and enabled RDP on the endpoint. They then logged into the endpoint via RDP using the previously compromised account, added a new user account named DefaultAcount, and then hid the new user’s profile folder from view using the attrib.exe native Windows utility.

In addition to using net.exe to enable the Guest account and make other modifications, threat actors have also been observed using other native utilities or “living off the land” binaries (“LOLBins”), such as WMI, to modify user account settings:

"C:\Windows\system32\cmd.exe" /c wmic useraccount where "name='Guest' " set passwordexpires=false

Threat actors may often employ multiple means of persistence, likely in the hope that when one is detected, the others may escape notice. Enabling a default, usually disabled account is one such method, one that may go unnoticed, allowing the threat actor to re-enter systems and continue their efforts.

Recommendations

Monitor EDR telemetry for the use of native utilities such as net.exe, WMI, or PowerShell to enable or modify user accounts. Track the passwords used when creating or enabling accounts, and use these as additional detection points as well as pivot points for analysis across multiple engagements. 

Monitor Security Event Logs or SIEM for Microsoft-Windows-Security-Auditing/4722 event records that include the account name “Guest”, indicating that the Guest account has been enabled.

Conduct threat hunting across endpoints looking for those where the Guest account is active.