Tu web no siempre es atacada con ruido y explosiones digitales. A veces, el ataque es silencioso. Invisible. Y cuando te das cuenta, ya hay alguien dentro.
Entender qué es una web shell, cómo funciona y cómo detectarla a tiempo, marca la diferencia entre un susto y una brecha de seguridad con consecuencias legales, económicas y reputacionales. En este artículo vamos a aprender a detectarlas y también como prevenirlas.
¿Qué es una web shell?
Una web shell es, en términos muy sencillos, un script o archivo malicioso que un atacante «esconde» en tu servidor para que funcione como un mando a distancia. Una vez instalada, le permite al hacker controlar tu sitio web, robar datos o borrar archivos sin necesidad de volver a «romper» la seguridad cada vez que quiera entrar.
Diferencias entre web shell y reverse shell
La diferencia entre una web shell y una reverse shell está en el origen de la conexión. En una web shell, tenemos un script malicioso que una vez instalado en un servidor web, nos da una interfaz donde podemos ejecutar comandos directamente a través de pteiciones HTTP o HTTPS. En una reverse shell, es la propia máquina comprometida la que inicia la comunicación con el equipo atacante, que estará preparado para escuchar y redirigir la línea de comandos del sistema a su propia terminal.
En muchos escenarios de ataque, se usa primero una web shell para acceder al servidor y montar ahí una reverse shell.
¿Cómo funcionan?
- Pérdida de Datos Confidenciales
- Control Remoto del Servidor
- Distribución de Malware
- Ataques de Denegación de Servicio (DDoS)
- Costos de Recuperación
Técnicas de detección
Es difícil detectar una web shell, ya que son sigilosas y suelen usar cifrados, codificaciones o técnicas de ofuscación para camuflarse como tráfico legitimo. Sin embargo hay algunas técnicas que podemos usar para ayudarnos en esta tarea.
Known good
La comparación con el «Estado Bueno Conocido» (Known-Good) es considerada por la NSA como la técnica más fiable para detectar web shells que modifican o añaden archivos a aplicaciones existentes.
Consiste en comparar de manera recursiva una copia de seguridad verificada y limpia contra la versión que está actualmente en producción para identificar discrepancias. Se pueden usar scripts de PowerShell (como dirChecker.ps1) que comparan los hashes de los archivos, o la utilidad diff en sistemas Linux.
¡Ojo! No debemos confiar únicamente en las marcas de tiempo de los archivos, ya que los hackers utilizan el «timestomping» para falsificar las fechas de creación y modificación.
Análisis de tráfico y logs
- Anomalías en User-Agents e IPs: Los atacantes suelen usar User-Agents inusuales o direcciones IP que no pertenecen al espacio geográfico esperado.
- Cabeceras sospechosas: La ausencia de la cabecera «referer» o el uso de cabeceras HTTP personalizadas para enviar comandos de forma oculta son señales de alerta.
- Métodos HTTP: Muchos atacantes prefieren el método POST sobre GET, ya que los parámetros del comando no suelen quedar registrados en los logs estándar de acceso.
- Herramientas: Se pueden implementar consultas en sistemas SIEM como Splunk para identificar URIs accedidas por muy pocos usuarios o IPs únicas.
Monitoreo de procesos y comportamiento del sistema (EDR)
Es muy raro que un proceso de servidor web lance comandos de reconocimiento como whoami, ipconfig, netstat, hostname, arp o systeminfo. Si vemos algo así, sería un proceso sospechoso.
Se recomienda el uso de Sysmon en Windows y auditd en Linux para auditar en tiempo real qué aplicaciones está ejecutando el usuario del servidor web.
Monitoreo de Integridad de Archivos (FIM)
El software FIM alerta o bloquea cambios no autorizados en los directorios donde se aloja la web. En entornos bien configurados, el FIM puede bloquear cualquier escritura que no tenga una extensión permitida (por ejemplo, permitir solo .pdf y bloquear .php).
Herramientas: McAfee HBSS, Wazuh o Elastic
Herramientas de Análisis Estático y Firmas
Permiten detectar shells como China Chopper, WSO, C99 o B374K mediante reglas de Snort o herramientas como Shell Detector.
Herramientas como NeoPI analizan el código en busca de entropía de información, firmas de funciones peligrosas (system, eval) y cadenas de texto excesivamente largas que indican ofuscación.
Análisis de Red y Flujos Inesperados
Esta técnica se enfoca en detectar el uso de la web shell para expandir el ataque dentro de la organización.
- Pivoting: Se detecta cuando un servidor web en el perímetro inicia conexiones hacia nodos internos de la red que no debería contactar.
- Servidores Rogue: Permite identificar aplicaciones web maliciosas que escuchan en puertos previamente no utilizados o que corren exclusivamente en memoria (sin archivos físicos).
- Herramientas: El uso de escáneres de vulnerabilidades (Nessus), IDS (Snort) y monitores de seguridad de red (Zeek/Bro) ayuda a visibilizar estos flujos no autorizados.
Estrategias de prevención y hardening
Gestión Crítica de Actualizaciones y Parches
Los hackers suelen explotar vulnerabilidades en aplicaciones web apenas 24 horas después de publicar un parche, es decir, cuando se publica un parche, los atacantes analizan qué vulnerabilidad están arreglando, y buscan webs que no tengan este parche puesto aun para explotar dicha vulnerabilidad. Por esto es muy importante mantener actualizado, no solo el CMS, sino también el sistema operativo y todos los plugins o bibliotecas de terceros que tengamos.
También tenemos que tener en cuenta plugins o software innecesario que tengamos instalado. Siempre es recomendable eliminarlo si no se usa, ya que así reducimos el vector potencial de ataque.
Configuración de Privilegios Mínimos
Restricción de acceso
Minimizar los privilegios de las cuentas y emplear autenticación de dos factores (2FA) reduce significativamente el riesgo de recibir un ataque.
Permisos del servidor web
La aplicación web no debe tener permisos para escribir directamente en directorios accesibles desde la web ni para modificar el código fuente. Si el servidor bloquea la escritura en el «document root«, el atacante no podrá subir la web shell aunque explote una vulnerabilidad.
Deshabilitar Funciones «Peligrosas»
El funcionamiento de muchas web shells se basa en abusar de funciones del servidor que permiten ejecutar comandos del sistema. Se recomienda deshabilitar estas funciones en el archivo de configuración (como el php.ini en PHP):
- exec()
- eval()
- shell_exec()
- system()
- passthru()
- assert()
Para ello podemos usar la siguiente directiva:
disable_functions = exec, shell_exec, system, passthru, eval, assertImplementación de Capas de Seguridad Técnica
WAF (Web Application Firewall)
Herramientas como Wazuh o agentes de McAfee HBSS pueden alertar o incluso bloquear en tiempo real cualquier cambio no autorizado en los directorios web.
Segmentación de red
Aislar los servidores en una DMZ o bajo una arquitectura de Zero Trust evita que un atacante use una web shell para saltar hacia la red interna de la organización.
Configuración y Vigilancia del Servidor
Hardening del sistema operativo
Bloquear el acceso a puertos y servicios no utilizados y restringir los servicios solo a clientes esperados.
Filtrado de archivos
Si el sitio permite subir archivos, configura filtros estrictos que solo admitan extensiones necesarias (ej. solo .pdf) y asegúrate de que se guarden en una ruta no accesible desde la web.
Respuesta a incidentes
La respueta a incidentes después de descubrir una web shell es un proceso crítico, ya que nos avisa de dos problemas: Tenemos una web shell instalada y hay una vulnerabilidad que ha permitido que esto pase.
Evaluación de alcance y análisis forense
Determinar la profundidad
Es vital analizar el alcance y profundidad del ataque. Podemos usar capturas de paquetes (PCAP) y datos de flujo de red para determinar si la web shell se ha utilizado para realizar pivoting hacia otros nodos internos de la red.
Análisis forense digital
Se debe realizar un análisis para comprender cómo ocurrió el ataque y mejorar las medidas de seguridad futuras.
Contención
Debemos identificar las direcciones IP sospechosas en los logs de acceso (como el access.log de Apache) y bloquearlas mediante herramientas como iptables.
Estrategias de limpieza
Si tenemos una copia de seguridad limpia y actual, restableceremos la copia, instalando inmediatamente todos los parches y actualizaciones de software, y corrigiendo la vulnerabilidad de raíz.
Si tenemos una copia de seguridad limpia pero no actual, crearemos una imagen de disco del sitio infectado usando comandos como dd. Restableceremos la copia limpia antigua y actualizaremos todo el software (SO y aplicaciones). Usaremos la herramienta diff para comparar la versión limpia con la infectada y así rescatar solo el contenido nuevo que sea legítimo.
Si no tenemos copia seguridad, realizaremos dos copias del sitio infectado (una imagen de disco y otra del sistema de archivos) antes de intentar limpiar manualmente. Eliminaremos los archivos maliciosos, limpiaremos los registros modificados en la base de datos y corregiremos la vulnerabilidad en el código o las contraseñas.
Erradicación y restablecimiento
Instalación limpia
Se recomienda realizar una instalación nueva del sistema operativo y las aplicaciones, no solo una actualización, ya que las actualizaciones pueden dejar archivos infectados de versiones anteriores.
Cambio total de credenciales
Es obligatorio restablecer todas las contraseñas relacionadas: accesos FTP, bases de datos, administradores de sistemas y cuentas del CMS (como WordPress).
Gestión de la presencia online
Si el hacker ha creado URLs nuevas visibles, debemos desindexarlas, si no sabes como te dejo este artículo de Cómo desindexar una URL de Google.
Conclusión
Una web shell no aparece por arte de magia. Siempre entra por una puerta abierta: una vulnerabilidad sin parchear, permisos mal configurados, credenciales débiles o software abandonado.
Detectarla es importante. Pero aún más importante es asumir que, si ha aparecido, el problema real no es el archivo malicioso en sí, sino el fallo que permitió que estuviera ahí. ¿Te has encontrado con este problema? ¡Te leemos en comentarios!