El invitado indeseado

La mayoría de las personas involucradas en respuesta a incidentes o que han leído informes públicos de incidentes saben que los actores de amenazas suelen comprometer cuentas de usuario mediante ataques de fuerza bruta u otros métodos, o incluso crear nuevas cuentas de usuario en sistemas comprometidos, a menudo usando contraseñas similares en distintos incidentes.

Una variación interesante de esto es el uso de la cuenta integrada Guest. Esta es una cuenta incluida en la instalación predeterminada de Windows y, como se ilustra en la Figura 1, está deshabilitada de forma predeterminada cuando se instala el sistema operativo. Por eso, es una cuenta que los administradores de sistemas están acostumbrados a ver; es decir, no llama la atención ni activa ninguna alarma.

Figura 1: Configuración de la cuenta Guest

Para ser claros, de lo que estamos hablando aquí es de la cuenta integrada Guest; esto no se trata de mantener persistencia mediante RID hijacking, ni de acceso de nivel invitado a los sistemas. Específicamente, a lo que nos referimos en este artículo es a la cuenta integrada Guest que se encuentra en la base de datos SAM de los sistemas Windows, como se ilustra en la Figura 2.

Figura 2: Usuarios locales de Windows 11

Los analistas de Huntress han visto varios incidentes desde principios de 2025 en los que el actor de amenazas habilitó la cuenta Guest mediante el uso de una línea de comandos como la siguiente:

net user Guest /active:yes

Una vez habilitada la cuenta, el actor de amenazas cambia la contraseña por una de su elección y luego modifica la cuenta aún más, por ejemplo, agregándola a los grupos Local Administrators y Remote Desktop Users, lo que eleva los privilegios de la cuenta y permite usarla para acceso remoto.

Durante un incidente en particular, entre otras actividades, el actor de amenazas instaló la aplicación AnyDesk, habilitó la cuenta Guest y cambió la contraseña por una variación de algo que los analistas de Huntress habían observado en incidentes anteriores.

Los analistas de Huntress observaron recientemente otro incidente en el que el actor de amenazas habilitó la cuenta Guest, la agregó al grupo Local Administrators y habilitó RDP en el endpoint. Luego, iniciaron sesión en el endpoint vía RDP usando la cuenta previamente comprometida, agregaron una nueva cuenta de usuario llamada DefaultAcount y ocultaron la carpeta de perfil del nuevo usuario usando la utilidad nativa de Windows attrib.exe.

Además de usar net.exe para habilitar la cuenta Guest y hacer otras modificaciones, también se ha observado a actores de amenazas usar otras utilidades nativas o binarios “living off the land” (“LOLBins”), como WMI, para modificar la configuración de cuentas de usuario:

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

Los actores de amenazas suelen emplear múltiples métodos de persistencia, probablemente con la esperanza de que si uno es detectado, los demás pasen desapercibidos. Habilitar una cuenta predeterminada que normalmente está deshabilitada es uno de esos métodos, uno que puede pasar inadvertido, lo que permite al actor de amenazas volver a ingresar a los sistemas y continuar sus esfuerzos.

Recomendaciones

Supervisa la telemetría de EDR en busca del uso de utilidades nativas como net.exe, WMI o PowerShell para habilitar o modificar cuentas de usuario. Registra las contraseñas usadas al crear o habilitar cuentas, y úsalas como puntos de detección adicionales, así como puntos de referencia para el análisis en múltiples casos.

Supervisa los registros de eventos de seguridad o el SIEM en busca de registros de eventos Microsoft-Windows-Security-Auditing/4722 que incluyan el nombre de cuenta “Guest”, lo que indica que la cuenta Guest ha sido habilitada.

Realiza caza de amenazas en los endpoints buscando aquellos donde la cuenta Guest esté activa.

También te podría interesar