Un ataque web shell es la instalación de un script malicioso en un servidor comprometido que le da a un atacante control remoto completo: ejecutar comandos, robar datos, modificar archivos y usar el servidor como plataforma para otros ataques. Sucuri detectó web shells en más del 12% de los sitios hackeados que limpiaron.
En 30 segundos
- Una web shell es un script (PHP, ASP, Python, entre otros) que un atacante sube a tu servidor para controlarlo remotamente sin necesidad de acceso SSH o FTP.
- Sucuri reporta que en 2026 las web shells siguen apareciendo en más del 12% de sitios comprometidos que pasan por su servicio de limpieza.
- Los vectores de entrada más comunes son: formularios de subida de archivos sin validación, inyecciones SQL, inclusión remota de archivos (RFI) y vulnerabilidades en plugins desactualizados.
- Para detectarlas necesitás revisión activa de archivos sospechosos, monitoreo de tráfico anómalo y herramientas como un WAF correctamente configurado.
- La limpieza no alcanza: si no parcheás la vulnerabilidad original, el atacante vuelve a subir la shell en horas.
Sucuri es una plataforma de seguridad web desarrollada por GoDaddy, que ofrece servicios de protección contra malware, firewall de aplicaciones web (WAF) y mitigación de ataques DDoS para sitios web. Está diseñada para detectar, eliminar y prevenir amenazas de seguridad en entornos web.
¿Qué es exactamente una web shell?
Una web shell es un script malicioso que un atacante deposita en un servidor web comprometido para mantener acceso remoto y ejecutar comandos como si tuviera una terminal abierta. A diferencia de un shell tradicional al que accedés por SSH, acá el vector es el propio servidor web: el script vive en el directorio público y el atacante lo invoca desde el navegador o por peticiones HTTP.
Según el blog de Sucuri, estas herramientas aparecieron en más del 12% de los sitios que pasaron por su proceso de limpieza. Para que tengas referencia: eso es mucho. Si atendés diez sitios hackeados, en al menos uno vas a encontrar una de estas cosas escondida en algún rincón del servidor.
La diferencia clave con otros tipos de malware es la persistencia y la interactividad. Una web shell no es un payload que corre una vez y desaparece. Es una puerta trasera que queda abierta, esperando que el atacante vuelva cuando quiera.
Cómo funcionan estos ataques paso a paso
Ponele que tenés un plugin de WordPress con una vulnerabilidad de subida de archivos sin validación. El atacante sube un archivo PHP con extensión disfrazada, lo ubica en wp-content/uploads/, accede a esa URL desde el navegador, y ya tiene una interfaz para ejecutar comandos en tu servidor. Todo eso puede pasar en menos de cinco minutos si el atacante sabe lo que hace.
El proceso típico tiene tres etapas: primero explotan una vulnerabilidad para ganar un punto de entrada (inyección SQL, inclusión remota de archivos, ejecución de código remoto), después suben el script malicioso a algún directorio con permisos de escritura, y finalmente lo ejecutan vía HTTP para tener control del servidor. A partir de ahí pueden hacer casi cualquier cosa: leer archivos de configuración, acceder a la base de datos, instalar más malware, o usar el servidor como punto de pivote para atacar otros sistemas.
Te llega el aviso de un plugin de monitoreo, entrás al admin de WordPress, ves que hay un archivo PHP en uploads que no debería estar ahí, revisás los logs del servidor, encontrás peticiones GET a ese archivo desde IPs en distintos países, mirás el contenido del script, es una shell completa con interfaz web para ejecutar comandos, y cuando intentás borrarlo te das cuenta de que el atacante ya creó otro en tres directorios distintos.
Principales tipos y lenguajes utilizados
PHP es el rey en entornos WordPress, por razones obvias: el 43% de la web corre en WordPress y casi todo servidor compartido tiene PHP habilitado. Pero los atacantes no se quedan ahí. En nuestra comparativa entre defensas perimetrales y microsegmentación profundizamos sobre esto.
Shells según el lenguaje del servidor
Las más comunes que vas a encontrar en la práctica:
- PHP: el tipo más frecuente en WordPress. Desde scripts de una sola línea con
eval(base64_decode(...))hasta interfaces completas como WSO Shell o b374k. - ASP/ASPX: aparecen en servidores Windows con IIS. Menos comunes en el mundo WordPress pero igual de peligrosas.
- Python y Perl: más raras en shared hosting, pero presentes en VPS o servidores dedicados donde esos intérpretes están disponibles.
- Bash: cuando el atacante ya tiene ejecución de comandos, puede dejar un script bash como persistencia adicional.
- Ruby: poco frecuente, pero existe en entornos que corren aplicaciones Rails junto a WordPress.
Un detalle que no es menor: Kali Linux, la distribución estándar para pentesting, incluye directorios con herramientas de web shell listas para usar. Eso habla de cuán accesibles son estas herramientas para cualquiera que quiera aprender (o atacar).
Los scripts se disfrazan de archivos legítimos. Nombres como wp-config-backup.php, cache-helper.php, o directamente con nombres aleatorios tipo a3f7b2c.php. Algunos imitan la estructura de plugins reales para pasar desapercibidos en una revisión rápida.
Métodos de entrada comunes en un ataque web shell
Subida de archivos sin validación
El vector más clásico en WordPress. Formularios de contacto, plugins de galería, gestores de medios con validación deficiente. Si el servidor acepta un .php renombrado como .jpg o no valida el tipo MIME real del archivo, estás en problemas.
Inyección SQL e inclusión de archivos
Con una inyección SQL bien ejecutada, un atacante puede escribir directamente en el sistema de archivos usando funciones como SELECT INTO OUTFILE en MySQL. La inclusión remota de archivos (RFI) y la inclusión local (LFI) también abren la puerta cuando el código no valida correctamente las rutas de archivos incluidos.
Vulnerabilidades en plugins y themes
Acá está el 80% de los casos en WordPress. Plugins desactualizados con vulnerabilidades conocidas, themes nulled con backdoors ya incorporadas (sí, esa «descarga gratis» de un theme premium que te conseguiste de un sitio dudoso). Cualquiera que haya revisado un sitio hackeado sabe que el camino casi siempre pasa por un plugin que nadie actualizó en seis meses.
Malas configuraciones del servidor
Permisos 777 en directorios, ejecución de PHP habilitada en wp-content/uploads/, credenciales de FTP débiles, paneles de administración expuestos sin restricción por IP. El servidor te da todas las facilidades para que el atacante se instale cómodo. Alguien revisó los permisos de ese directorio antes de que te hackearan? Exacto, nadie.
Riesgos y consecuencias reales para tu servidor
Con una web shell instalada, el atacante tiene acceso a todo lo que puede hacer el proceso del servidor web. Eso incluye leer wp-config.php (y con eso tiene las credenciales de la base de datos), modificar cualquier archivo del sitio, instalar malware adicional, agregar redireccionamientos a sitios de phishing, o usar tu servidor para enviar spam masivo. Más contexto en la guía sobre plugins gratuitos para WordPress.
Lo más preocupante es el uso como pivote. Tu servidor comprometido se convierte en una plataforma para atacar otros sistemas, y vos aparecés en listas negras sin haber hecho nada. Google te banea de los resultados de búsqueda. Tu hosting suspende la cuenta. Y todavía no sabés qué pasó.
La persistencia es el problema central. Un atacante inteligente no deja una sola shell: deja tres o cuatro en distintos directorios, modifica archivos core del sistema, y a veces agrega un usuario administrador en WordPress como respaldo (por si le limpian las shells). Si no resolvés el problema de raíz, vuelven.
Cómo detectar web shells en tu servidor
La detección tiene varios niveles. Ninguno es infalible solo, pero combinados te dan una cobertura razonable.
Revisión manual de archivos sospechosos
Buscá archivos PHP en directorios que no deberían tenerlos, especialmente en wp-content/uploads/. Desde la línea de comandos podés hacer algo como find /var/www/html -name "*.php" -path "*/uploads/*" para encontrarlos rápido. Después revisá fechas de modificación: si un archivo tiene fecha de modificación reciente y vos no tocaste nada, es una señal de alerta.
Patrones en el código
Las shells PHP suelen usar funciones como eval(), base64_decode(), system(), exec(), passthru(), o shell_exec(). Podés buscarlas con grep -r "eval(base64" /var/www/html. Ojo: hay código legítimo que usa algunas de estas funciones, así que no entres en pánico con cada resultado, revisá el contexto.
Monitoreo de tráfico y logs
Revisá los logs de acceso del servidor. Peticiones POST a archivos PHP en directorios de media, accesos a archivos con nombres raros, o tráfico desde IPs que nunca viste son señales claras. Un WAF bien configurado (ya sea en el servidor o como el que ofrece Sucuri en su plataforma) puede bloquear muchas de estas peticiones antes de que lleguen al servidor.
Tabla comparativa: vectores de ataque y nivel de riesgo
| Vector de entrada | Frecuencia en WordPress | Dificultad para el atacante | Mitigación principal |
|---|---|---|---|
| Plugin desactualizado con RCE | Muy alta | Baja (exploit público) | Actualizar plugins |
| Subida de archivos sin validación | Alta | Baja a media | Validar tipo MIME, deshabilitar ejecución PHP en uploads |
| Inyección SQL con FILE write | Media | Media | Prepared statements, permisos DB restrictivos |
| Credenciales FTP/Admin robadas | Media | Baja | 2FA, contraseñas únicas y fuertes |
| RFI/LFI en código custom | Media-baja | Media | Validación de rutas, deshabilitar allow_url_include |
| Theme/plugin nulled con backdoor | Alta | Ninguna (ya viene incluida) | No usar software pirata |
Estrategias de mitigación y prevención
La mitigación empieza antes del ataque, no después. Principio de mínimo privilegio: el proceso del servidor web no debería tener permisos para escribir en directorios que no necesita modificar. En WordPress, wp-content/uploads/ necesita escritura para los medios, pero no necesita ejecución de PHP.
Para deshabilitar la ejecución de PHP en el directorio de uploads, podés agregar un archivo .htaccess con esto: Cubrimos ese tema en detalle en los parches críticos de Windows en AWS.
php_flag engine off
O si usás Nginx, configurar el bloque de location correspondiente para denegar acceso a archivos PHP en ese path. Es una medida simple que corta de raíz el vector más común.
Eso sí: las actualizaciones constantes son innegociables. Un plugin desactualizado con CVE público es una invitación abierta. Si estás buscando un hosting que tenga actualizaciones automáticas configurables y soporte técnico que entienda de esto, vale la pena mirar opciones como donweb.com donde podés tener más control sobre la configuración del entorno.
Autenticación de dos factores en wp-admin, restricción de acceso al panel por IP si tu IP es fija, y un WAF que bloquee patrones de shell conocidos completan el panorama básico.
Proceso de remoción y limpieza paso a paso
Si ya tenés una web shell instalada, la secuencia correcta es esta:
- 1. Poner el sitio en modo mantenimiento y cortar acceso externo si el daño es severo. No sirve limpiar con el sitio activo si el atacante puede seguir operando.
- 2. Identificar todos los archivos maliciosos. No alcanza con encontrar uno. Buscá por patrones de código sospechoso, por fechas de modificación anómalas, y compará contra una instalación limpia de WordPress de la misma versión.
- 3. Restaurar desde un backup limpio si tenés uno verificado como anterior al compromiso. Esto es la opción más segura. Si no tenés backup… tomalo como una lección cara.
- 4. Eliminar los archivos maliciosos identificados en el paso 2. Después reinstalá los archivos core de WordPress desde cero.
- 5. Parchear la vulnerabilidad original. Si no hacés esto, el atacante vuelve en horas. Actualizá el plugin o tema vulnerable, o desactivalo si no tiene parche disponible.
- 6. Cambiar todas las credenciales: contraseñas de WordPress, base de datos, FTP, panel de hosting. Todas. Sin excepción.
- 7. Monitorizar la actividad post-limpieza durante al menos dos semanas. Los atacantes vuelven a verificar si su acceso sigue activo.
Y el hosting hizo algo durante todo esto? Depende. El «soporte de seguridad» de algunos hostings compartidos se limita a enviarte un mail diciendo que encontraron malware en tu cuenta y que tenés 48 horas para limpiarlo o te suspenden. (Si, así de útiles son.)
Errores comunes que facilitan los ataques de web shell
Confiar en que el firewall del hosting lo resuelve todo
El firewall del hosting compartido filtra tráfico de red, no analiza el contenido de tus archivos PHP ni detecta que alguien acaba de subir una shell vía un formulario de tu sitio. Son capas de protección distintas. Un WAF de aplicación web es diferente a un firewall de red, y confundir los dos te deja con una falsa sensación de seguridad.
Limpiar sin parchear la vulnerabilidad de entrada
Este es el error más caro. Borrás los archivos maliciosos, el sitio vuelve a funcionar, y dos días después te vuelven a hackear por exactamente el mismo vector. La limpieza sin parche es perder tiempo. Siempre identificá cómo entraron antes de declarar el sitio limpio.
Usar plugins «de seguridad» como única línea de defensa
Wordfence, iThemes Security, Sucuri Security: todos tienen valor, ninguno es suficiente solo. Un plugin de seguridad que no está actualizado, o que tiene su propia vulnerabilidad (lo cual pasó más de una vez), no te protege de nada. La «protección» que te da instalar un plugin sin configurarlo correctamente es más una ilusión que otra cosa.
No deshabilitar la ejecución de PHP en directorios de uploads
Es una configuración de cinco minutos que corta el vector de ataque más común. La mayoría de los sitios que limpio no la tienen configurada. El directorio de uploads sirve para guardar imágenes y documentos, no para ejecutar código PHP. Si deshabilitás la ejecución en ese directorio, una shell subida ahí no puede correr aunque el atacante la suba exitosamente. Ya lo cubrimos antes en el reciente compromiso de Trivy en CI/CD.
Si querés saber más sobre cómo identificarlas y eliminarlas, mirá Web Shells: Types, Mitigation & Removal.
Preguntas Frecuentes
¿Cómo puedo saber si mi servidor tiene una web shell instalada?
Buscá archivos PHP en directorios donde no deberían estar (especialmente uploads), revisá fechas de modificación de archivos core, y analizá los logs del servidor buscando peticiones a rutas inusuales. Herramientas como el escáner de Sucuri o la función de integridad de archivos de Wordfence te dan un punto de partida, aunque la revisión manual de logs y archivos sigue siendo necesaria para casos complejos.
¿Qué lenguajes usan las web shells más comunes?
En entornos WordPress, PHP es el lenguaje más usado por lejos dado que es el lenguaje del servidor en casi todos los casos. Le siguen ASP y ASPX en servidores Windows, y Python o Perl en VPS con esos intérpretes disponibles. El lenguaje elegido siempre depende de lo que el servidor tenga habilitado.
¿Cómo se instala una web shell en un servidor WordPress?
Los vectores más frecuentes son: formularios de subida de archivos sin validación correcta del tipo real del archivo, plugins vulnerables con ejecución remota de código, inyecciones SQL que permiten escribir archivos, e inclusión remota de archivos (RFI). En muchos casos la puerta de entrada es un plugin desactualizado con un CVE público conocido que el atacante explota de manera automática.
¿Cómo elimino una web shell de mi sitio?
La remoción correcta implica identificar todos los archivos maliciosos (no solo el primero que encontrás), restaurar archivos core desde una fuente limpia, parchear la vulnerabilidad que permitió la entrada, y cambiar todas las credenciales del entorno. Si tenés un backup verificado limpio, restaurar desde ahí es la opción más segura. Sin el parche de la vulnerabilidad original, cualquier limpieza es temporal.
Conclusión
Las web shells siguen siendo una de las herramientas más efectivas en el arsenal de un atacante porque combinan persistencia, flexibilidad y facilidad de ocultamiento. Que Sucuri las encuentre en más del 12% de los sitios que limpian en 2026 dice bastante sobre la escala del problema.
Lo que cambió en los últimos tiempos es la automatización: los atacantes ya no buscan sitios manualmente, tienen bots que escanean rangos de IPs buscando versiones de plugins vulnerables, y cuando encuentran una, el proceso de subir la shell es automático. El tiempo entre que se publica un CVE y que empieza la explotación masiva se redujo a horas en algunos casos.
La respuesta práctica es en tres capas: prevención (actualizaciones, validación de uploads, deshabilitar ejecución PHP donde no corresponde), detección (monitoreo de archivos, revisión de logs, WAF) y respuesta (tener el proceso de limpieza claro antes de necesitarlo, con backups verificados y listos). Si querés profundizar en la gestión de seguridad WordPress más allá de este tema, donweb.news tiene cobertura regular de vulnerabilidades y parches del ecosistema.
La clave sigue siendo la misma de siempre: no esperes a que te hackeen para revisar la configuración de seguridad de tu servidor.
¿Cómo sé si mi WordPress tiene una web shell instalada?
Buscá archivos PHP sospechosos en wp-content/uploads/ con find /var/www/html -name «*.php» -path «*/uploads/*», revisá fechas recientes de modificación, y monitoreá los logs de acceso para peticiones POST a archivos PHP en directorios de media. Un WAF o plugin de seguridad como Wordfence puede alertarte automáticamente.
¿Cuáles son los pasos para eliminar una web shell de mi servidor?
Primero, identifica todas las shells (pueden haber varias). Buscá funciones peligrosas con grep -r «eval(base64» en tu directorio root. Eliminá los archivos maliciosos, cambiá todas las contraseñas (FTP, SSH, base de datos, WordPress admin), revisá los plugins y themes desactualizados, y auditá los permisos de directorios (uploads debe tener 755, no 777).
Si elimino la web shell, ¿el atacante puede volver a instalarla?
Sí, si no cerrás la vulnerabilidad original. Si la shell entró por un plugin desactualizado, un formulario sin validación, o credenciales débiles, el atacante vuelve en horas. Después de limpiar, siempre parcheá la vulnerabilidad que permitió el acceso inicial.
¿Cómo sé si mi sitio WordPress tiene una web shell?
Podés detectarla buscando archivos PHP donde no deberían estar (especialmente en wp-content/uploads), revisando fechas de modificación recientes, y analizando logs del servidor para tráfico anómalo. Si encontrás código con eval(), base64_decode() o funciones de ejecución de comandos, es casi seguro que tenés una.
¿Es suficiente borrar la web shell para estar seguro?
No. Borrar el archivo es solo el primer paso. Necesitás identificar cómo entró el atacante (plugin desactualizado, validación deficiente, etc.), parcheá esa vulnerabilidad, verificá que no haya instalado otros backdoors o usuarios administrador ocultos, y monitoreá los logs para confirmar que no vuelva.
¿A qué se parece una web shell en el código PHP?
Buscá funciones como eval(), system(), exec(), shell_exec() o base64_decode(). Las shells simples son una sola línea con eval(base64_decode(…)). Las complejas tienen interfaces web con formularios para ejecutar comandos. Los nombres disfrazados (wp-config-backup.php, cache-helper.php) o aleatorios (a3f7b2c.php) también son señales de alerta.