En resumen: Las cuentas de administrador ajenas solo las encuentra si revisa todos los niveles: el CMS o la tienda, el panel de alojamiento, los usuarios del sistema del servidor, los accesos SSH y los usuarios de la base de datos. No se fíe de la lista de usuarios del backend, porque el código inyectado puede esconder cuentas allí. Documente y bloquee primero los hallazgos, aclare después la causa y solo entonces borre.
Por qué un administrador desconocido es tan peligroso
Una cuenta de administrador adicional es para los atacantes la puerta trasera más cómoda. No necesita código malicioso, no llama la atención en los análisis de archivos y sobrevive a cualquier actualización. Quien más tarde inicia sesión con esa cuenta aparece en el registro como un redactor normal.
Tras PHP2Shell, esta revisión cobra peso. Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 permiten la ejecución de código malicioso sin inicio de sesión. Quien puede ejecutar código en el servidor también puede escribir en la base de datos y crear así cuentas. Una actualización de PHP cierra la vulnerabilidad, pero no elimina ninguna cuenta creada antes.
Para PHP2Shell no hay indicadores de compromiso publicados y confirmados, es decir, ninguna lista de huellas típicas. Una cuenta desconocida no es por ello una prueba de PHP2Shell, pero sí un claro indicio de acceso no autorizado, por el camino que sea. Una visión de conjunto de otros indicios figura en ¿Ya estoy comprometido?.
Dónde pueden esconderse cuentas de administrador ajenas
Muchos operadores miran solo el CMS. Los atacantes piensan en niveles, y cada nivel tiene sus propias cuentas:
| Nivel | Dónde mirar | A qué prestar atención |
|---|---|---|
| CMS o tienda | gestión de usuarios y tabla de usuarios de la base de datos | rol de administrador, fecha de creación, dirección de correo ajena |
| Panel de alojamiento | usuarios, cuentas adicionales, cuentas FTP | cuentas que nadie del equipo ha creado |
| Servidor Linux | /etc/passwd, grupos sudo o wheel, sudoers |
otras cuentas con UID 0, nuevas shells de inicio de sesión |
| SSH | authorized_keys de todos los usuarios |
claves sin propietario conocido |
| Base de datos | tabla de usuarios del servidor de base de datos | usuarios con permisos globales o host % |
| Servicios externos | dominio, DNS, Search Console, CDN | titulares o autorizados adicionales |
El nivel de SSH es lo bastante independiente como para merecer un artículo propio: Encontrar y eliminar claves SSH desconocidas.
Encontrar cuentas de administrador ajenas en el CMS, también las ocultas
La lista de usuarios del backend la genera la propia aplicación. Si se ejecuta código inyectado, este puede filtrar entradas concretas. Son por ello más fiables las herramientas que miran directamente los datos almacenados. Para WordPress, WP-CLI enumera todos los administradores con su fecha de creación:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Un nivel más profundo llega una consulta de lectura en la base de datos. Muestra cada cuenta a la que está asignado el rol de administrador, con independencia de lo que muestre la interfaz. El prefijo de tabla wp_ adáptelo a su instalación:
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;
Compare los resultados del backend, de WP-CLI y de la base de datos. Si una cuenta aparece solo en la base de datos, es una señal de alerta fuerte, porque entonces interviene además código que la oculta. Para otros sistemas como Shopware, TYPO3 o Joomla vale el mismo principio: consultar directamente la tabla de usuarios y compararla con lo que muestra el backend. Qué tablas son figura en la documentación del fabricante.
Revisar usuarios del sistema y de la base de datos
En el propio servidor interesan sobre todo las cuentas con derechos de root y las cuentas que pueden iniciar sesión. Los siguientes comandos solo leen:
# Cuentas con UID 0 (normalmente solo root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Cuentas con una shell de inicio de sesión real
grep -vE '(nologin|false)$' /etc/passwd
# Miembros de los grupos de administración
getent group sudo wheel
# Reglas sudo adicionales
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Últimos inicios de sesión con fecha completa
last -F | head -30
En el servidor de base de datos compruebe qué usuarios existen y qué permisos tienen:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Una aplicación necesita, por lo general, un usuario con permisos sobre exactamente una base de datos. Un usuario adicional con permisos globales que pueda acceder desde cualquier host (%) debe aclararse.
No olvide las cuentas fuera del servidor. Quien tiene acceso al contrato del dominio o a la gestión del DNS puede redirigir a los visitantes o hacer emitir certificados en servidores ajenos. Un titular adicional en Google Search Console puede enviar sitemaps y cambiar ajustes. Por eso, repase en el registrador, el proveedor de DNS, la CDN y Search Console la lista de autorizados y compárela con lo que conoce su equipo.
Cómo tratar correctamente un hallazgo
El primer impulso es borrar de inmediato la cuenta ajena. Pero con ello desaparece también una huella importante: la fecha de creación suele acotar cuándo estuvo el atacante en el sistema. Es mejor este orden:
- Documentar: anotar nombre de usuario, ID, correo, fecha de creación, rol y última actividad con la hora, a ser posible como captura de pantalla y exportación.
- Bloquear en lugar de borrar: retirar el rol, sustituir la contraseña por un valor aleatorio o desactivar la cuenta.
- Acotar el período: revisar los registros en torno a la fecha de creación. ¿Qué peticiones hubo poco antes, qué archivos cambiaron?
- Revisar otros niveles: quien crea una cuenta rara vez deja solo una. Revisar también archivos, tareas cron, claves SSH y base de datos.
- Limpiar y renovar los accesos: solo tras la limpieza y la actualización de PHP, renovar todas las contraseñas, claves y sesiones.
Una nota de cautela: no toda cuenta desconocida es malintencionada. Agencias, proveedores anteriores o plugins de mantenimiento crean a veces cuentas propias. Aclárelo antes de dar la alarma, pero aclárelo pronto.
Evitar la reaparición
Tras la limpieza, las cuentas de administrador deberían ser la excepción, no la regla. Han dado buen resultado las cuentas personales en lugar de accesos compartidos, el menor número posible de administradores y una autenticación de dos factores para los accesos de administración. Fije además quién puede crear cuentas de administrador nuevas y dónde se documenta.
Una consulta regular como las anteriores, por ejemplo semanal y con comparación con la semana anterior, hace visibles pronto las cuentas nuevas. En WordPress ayuda además la guía Encontrar puertas traseras en WordPress.
¿Cómo ayuda PHP SOS en concreto?
- Revisamos todos los niveles de cuentas, del CMS al servidor y la base de datos, y contrastamos lo que muestra el backend con los datos almacenados.
- Aseguramos los hallazgos con marcas de tiempo antes de bloquear o eliminar cuentas.
- En el marco de la respuesta a incidentes aclaramos cómo surgió la cuenta y si hay otras puertas traseras.
- Renovamos los accesos en el orden correcto y configuramos un control continuo de las cuentas de administrador nuevas.
Preguntas frecuentes
¿Debo borrar de inmediato una cuenta de administrador desconocida?
Mejor no de inmediato. Documente primero nombre de usuario, fecha de creación, dirección de correo y última actividad, y bloquee la cuenta. Solo se borra cuando las huellas están aseguradas, porque la fecha de creación suele ser un indicio importante del momento de la intrusión.
¿Puede una cuenta de administrador ser invisible en el backend?
Sí. El código inyectado puede ocultar cuentas concretas de la lista de usuarios de la interfaz. Una consulta directa a la base de datos o una herramienta de línea de comandos, en cambio, muestra todas las cuentas almacenadas. Por eso no debería mirar solo en el backend.
¿Qué niveles debo revisar además del CMS?
Panel de alojamiento, accesos FTP y SFTP, usuarios del sistema del servidor, incluidos los derechos sudo, claves SSH, usuarios de la base de datos y cuentas en dominio, DNS y Search Console. Un atacante solo necesita una de estas puertas para volver.
¿Basta con cambiar todas las contraseñas tras el hallazgo?
No. Una cuenta ajena muestra que alguien tuvo acceso. Entonces hay que aclarar también la puerta de entrada, otras puertas traseras y posibles fugas de datos. Las contraseñas se cambian solo tras la limpieza y desde un equipo limpio.