Web Shells: Cómo los atacantes los usan y cómo detectarlos

Los exploits dirigidos a aplicaciones web expuestas a Internet fueron el principal vector de acceso inicial por sexto año consecutivo en 2025, según Informe M-Trends 2026 de Mandiant. Las web shells son fundamentales para la forma en que se sostienen esos exploits: los grupos de amenazas las desplegaron en el 35 %% de los incidentes en el cuarto trimestre de 2024, más del triple que en el trimestre anterior. Una vez plantada en un servidor web comprometido, una web shell otorga a los atacantes persistencia a largo plazo, la capacidad de moverse lateralmente y acceso directo a datos confidenciales, todo ello sin activar las alertas que generaría el malware convencional.

En 2025, el tiempo mediano entre el compromiso inicial y el traspaso al atacante se redujo a 22 ssegundos. Las web shells son un facilitador clave de esa velocidad: permiten a los actores de amenazas mantener acceso sigiloso mientras un segundo grupo se encarga del despliegue de ransomware o la exfiltración de datos. Analicemos una web shell clásica de PHP para mostrar cómo funciona en la práctica y por qué estos scripts siguen siendo tan efectivos para convertir una sola vulnerabilidad sin parches en una brecha duradera.

Por qué importan las web shells

Un web shell es un script pequeño (generalmente escrito en PHP, ASP o JSP) que los atacantes suben a una aplicación web vulnerable.

Piensa en un web shell como un panel de control oculto. Una vez instalado, permite a los hackers ejecutar comandos, navegar por archivos y tomar el control del servidor desde su navegador. Lo que comienza como una sola falla en una aplicación web puede convertirse rápidamente en una puerta trasera permanente.

Según CISA, las web shells pueden operar en plataformas Linux, Microsoft Windows, macOS y de red.

Los atacantes suelen introducir scripts de web shell a través de:

• Errores de ejecución remota de código en aplicaciones web públicas
• Formularios de carga de archivos mal asegurados
• Vulnerabilidades de inclusión remota o local de archivos (RFI/LFI)
• Plugins o temas obsoletos del CMS, como en WordPress

A lo largo de los años, algunos shells se han vuelto infames:

• C99 web shellUna shell PHP repleta de funciones con herramientas para la gestión de archivos, ejecución de comandos y bases de datos
• China Chopper webshell: Una web shell diminuta pero potente que se utiliza a menudo para persistencia sigilosa
• R57 y Shells web de WSO: Shells web antiguas pero todavía activas con funciones básicas de archivos y comandos
• B374K shell web: Una web shell de PHP que puede ver procesos y ejecutar comandos

Veamos algunos de estos web shells en acción.

Estudios de caso: Incidentes de web shells en la vida real

Antes de desglosar sus componentes, veamos algunos ejemplos reales del daño que pueden causar las web shells. Representaron 35% de incidentes de ciberataque en el cuarto trimestre de 2024, lo que los convierte en un importante script malicioso a tener en cuenta.

• Abril de 2025: Según The Hacker News, error crítico que permite a los atacantes cargar web shells JSP, y luego usar herramientas como Brute Ratel para escalar y robar datos. Los escaneos encontraron cientos de servidores vulnerables expuestos en línea.
• Julio 2023: CISA se informó que actores de amenazas explotaron la falla de Citrix NetScaler/ADC (CVE-2023-3519) para instalar web shells (a menudo JSP), obtener ejecución remota de comandos y persistencia, y moverse lateralmente.
• Junio de 2022: MITRE ATT&CK documentado cómo se desplegó un web shell durante el ataque a la red eléctrica de Ucrania, ejecutado por un grupo de amenazas con conexiones rusas.

En resumen, los web shells pueden convertir rápidamente cualquier aplicación vulnerable en un servidor web comprometido, con consecuencias devastadoras.

C99: Un análisis de webshell

C99 es un ejemplo clásico de webshell de PHP que empaqueta mucha capacidad en un solo script, incluyendo:

• Administrador de archivos
• Subir/descargar
• Ejecución de comandos
• Ayudantes de base de datos
• Opción de autodestrucción

C99 demuestra claramente el flujo de trabajo completo del atacante: un adversario carga un pequeño archivo PHP a través de una carga vulnerable o RCE, luego usa ese mismo script para navegar por la raíz web, ejecutar comandos del sistema operativo, extraer credenciales y herramientas de etapa adicional.

Repasemos con más detalle cómo puede ser un webshell C99.

1. Navegación del sistema de archivos

• ¿Qué hace?: La navegación por sistemas de archivos permite a un atacante listar carpetas, abrir archivos y leer su contenido. Podrían usar funciones como scandir() o opendir() para ver lo que hay en el servidor, file_get_contents() para leer archivos, y file_put_contents() soltar o actualizar archivos.
• Por qué es importante: Así es como los hackers pueden encontrar archivos de configuración, claves API, copias de seguridad y otros datos sensibles, y dónde preparan cargas útiles adicionales.
• Qué buscar: Solicitudes que impactan repetidamente la misma ruta PHP que devuelven listados de directorios. También verifique si hay archivos nuevos o modificados recientemente en la raíz web (marcas de tiempo extrañas), y lecturas repentinas de archivos de configuración o descargas grandes iniciadas desde el servidor web.

El fragmento a continuación es un ejemplo simplificado para mostrar el comportamiento, aunque las implementaciones exactas y los nombres de las funciones varían según la variante.

Figura 3: Ejemplo de navegación del sistema de archivos en el lenguaje de programación PHP.

2. Carga/descarga de archivos

• ¿Qué hace?: Las shells de estilo C99 a menudo incluyen un formulario de carga de archivos para que un atacante pueda introducir herramientas adicionales (malware, escáneres o cargas útiles grandes) en el servidor. También permiten a los atacantes descargar archivos del servidor. Los mecanismos de carga comunes son move_uploaded_file() (subidas de archivos del navegador estándar), manejadores que aceptan cuerpos POST en bruto o campos POST que transportan archivos codificados en base64.
• Por qué es importante: Un atacante utiliza cargas para preparar más malware o reemplazar archivos de aplicaciones. Las descargas les permiten extraer archivos de configuración o volcados de bases de datos de tu entorno, todo a través del proceso del servidor web.
• Qué buscar: Mantente atento a las grandes o inusuales solicitudes POST al mismo endpoint de PHP (especialmente aquellas que contienen cadenas base64 largas) seguidas de la aparición de archivos nuevos o con nombres extraños en carpetas accesibles desde la web o picos en el tráfico saliente.

3. Ejecución de comandos/Acceso remoto

• ¿Qué hace?: C99 le da a un atacante una pequeña terminal web. Pueden enviar un comando a través de la interfaz web o una solicitud POST y obtener la salida del comando de regreso en el navegador.
• Por qué es importante: Así es como los atacantes generan shells inversas, ejecutan scripts de escalada de privilegios o lanzan otras herramientas desde el servidor web.
• Qué buscar: Monitorizar que los procesos web generen comandos de shell o conexiones salientes inesperadas inmediatamente después de solicitudes a un único endpoint PHP.

4. Conexiones de base de datos y extracción de datos

• ¿Qué hace?: Los shells de estilo C99 a menudo incluyen herramientas rápidas para leer archivos de configuración (donde las aplicaciones almacenan las credenciales de la base de datos) y ejecutar consultas SQL utilizando esas credenciales. Esto permite a un atacante volcar tablas de usuarios, robar claves de API o escribir nuevos registros para ayudar a la persistencia.
• Por qué es importante: Con acceso a la base de datos, un atacante puede exfiltrar datos de clientes, apoderarse de cuentas o usa las mismas credenciales para acceder a otros servicios, multiplicando el impacto de la brecha.
• Qué buscar: Ten cuidado con lecturas inesperadas de archivos de configuración además de conexiones/consultas inusuales a la base de datos que se originan en el proceso del servidor web.

5. Ofuscación y anti-forense

Las variantes de C99 a veces ocultan cadenas de texto o lógica utilizando base64_decode(), gzinflate() o evaluar() envoltorios, y pueden comprimir o dividir cargas útiles para evitar la detección simple por firmas. También pueden auto-eliminarse después de su uso. Estos trucos hacen que los escáneres basados en firmas y las revisiones manuales rápidas no detecten el implante.

Cómo los atacantes entregan shells web

Ahora que hemos visto el funcionamiento interno de un sistema operativo de web shell, exploremos cómo los hackers logran introducirlo en un sistema comprometido en primer lugar.

• Ejecución remota de código (RCE) explotada en una aplicación pública: un atacante ejecuta código en su servidor
• Puntos de carga de archivos no seguros o permisos mal configurados que permiten a los atacantes cargar archivos
• Cadenas de Inclusión Remota de Archivos (RFI) o Inclusión Local de Archivos (LFI) que permiten a un atacante forzar al servidor a escribir o ejecutar un archivo remoto
• Plugins o temas comprometidos, credenciales de administrador robadas, o phishing que da acceso a paneles de administración (común en WordPress)

Lista de verificación: Cómo detectar una web shell

Aquí tienes una lista de verificación clara que puedes usar durante la caza o la clasificación. Cada elemento es un lugar donde buscar y lo que generalmente significa.

1. Archivos PHP nuevos o con nombres extraños en carpetas web: Verifica si hay archivos que no estaban allí antes, que tienen nombres extraños (cadenas aleatorias) o marcas de tiempo que no coinciden con tu última implementación.
2. Conexiones salientes inesperadas desde el servidor web: Conexiones repetidas y periódicas a IPs desconocidas pueden ser una señal de comando y control.
3. Servidor web que inicia nuevos procesos o ejecuta comandos shell: Si tu proceso web se bifurca de repente yo, bash, o binarios inesperados, trátelo como alta prioridad.
4. Cambios en archivos centrales del CMS, plugins o cuentas de administrador desconocidas. Busque archivos principales modificados, nuevos usuarios administradores o archivos de complementos que no coincidan con las sumas de verificación del proveedor.
5. Solicitudes POST extrañas con cuerpos largos o datos similares a base64: Los POST grandes o frecuentes al mismo endpoint de PHP (especialmente con cadenas codificadas largas) a menudo indican cargas o escrituras remotas.

También te puedes beneficiar de herramientas de monitoreo.

Por ejemplo, puedes usar la monitorización de la integridad de archivos para detectar archivos nuevos o modificados en la raíz web, logs del firewall de aplicaciones web (WAF) y del servidor web para POSTs extraños, alertas de EDR cuando el proceso web genera shells o escribe binarios, y red/IDS para beaconing o egresos inesperados. Combina esas fuentes y detectarás implantes más rápido.

CybelAngel puede complementar este proceso. Puede gestionar sus activos públicos y expuestos a Internet (que a menudo albergan los datos más sensibles) y señalar cualquier problema antes de que se convierta en una brecha a gran escala.

7 medidas tácticas de ciberseguridad para CISOs

Aquí hay algunas correcciones que CISOs debería priorizar para adelantarse a las web shells.

• Parchear aplicaciones y complementos públicos: Aplica correcciones de proveedores rápidamente y automatiza las actualizaciones cuando sea seguro.
• Puntos finales de carga de Harden: Validar tipos de archivo, eliminar metadatos, rechazar ejecutables y almacenar las subidas fuera del directorio raíz web.
• Ajusta tu WAF para POST sospechosos: Bloquear o desafiar cuerpos POST grandes/codificados y firmas conocidas de web-shell.
• Realizar comprobaciones de integridad de archivos en la raíz web: Hashea el contenido regularmente y alerta sobre archivos PHP nuevos o modificados.
• Bloquear la salida de los servidores web: Permitir destinos de salida y bloquear puertos de salida inesperados.
• Mejore la higiene de las credenciales: Rota secretos, aplica MFA en paneles de administración y alerta sobre cuentas nuevas/privilegiadas.
• Utilice la inteligencia de amenazas externas para priorizar la remediación: Mapear aplicaciones expuestas, enfocar las correcciones en activos de alto riesgo primero, con herramientas como CybelAngel para automatizar el proceso.

Preguntas frecuentes

Terminando

Las web shells no son sofisticadas. Eso es precisamente lo que las hace peligrosas. Unos pocos cientos de líneas de PHP, cargadas a través de una única vulnerabilidad sin parches, pueden dar a un atacante acceso persistente a tu entorno durante semanas o meses, mucho después de que el fallo original sea corregido.

Los datos de 2026 de Mandiant confirman el patrón: Los exploits siguen siendo el vector de acceso inicial número uno, y los servidores de aplicaciones web expuestos a Internet son el objetivo principal. Las web shells son el puente entre la explotación inicial y todo lo que sigue: movimiento lateral, robo de credenciales, despliegue de ransomware.

Las organizaciones que detectan los web shells de forma temprana comparten una capacidad: visibilidad continua de su superficie de ataque externa. Saben qué aplicaciones expuestas a Internet se están ejecutando, cuáles no están parcheadas y reciben alertas cuando aparecen archivos inesperados en los servidores web. La gestión de la superficie de ataque de CybelAngel mapea continuamente sus activos expuestos a Internet, identificando aplicaciones expuestas y vulnerables antes de que los atacantes puedan obtener una base.

Sobre el autor

Orlaith Traynor

Orlaith es una estratega de marketing de contenidos B2B con sede en París especializada en ciberseguridad y tecnología, con gran experiencia en SEO, AEO, planificación editorial y gestión de CMS. Tras haber dirigido contenidos en empresas como CybelAngel y PhantomBuster, ayuda a las marcas tecnológicas a crear estrategias de contenidos que impulsan la visibilidad orgánica y la confianza de los compradores en mercados competitivos.

lee todos los artículos