Web shells y backdoors: los IoC que delatan una puerta trasera

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Cuando una web se reinfecta una y otra vez pese a que la «limpias», el problema casi nunca es el spam visible: es la puerta trasera que sigue abierta. Saber detectar una web shell en el servidor es la diferencia entre cerrar el incidente y perseguirlo eternamente. En la guía sobre la anatomía del hackeo, la persistencia y el SEO-spam lo enmarcamos dentro del ciclo de vida de un compromiso; aquí bajamos al detalle de los indicadores de compromiso (IoC) que delatan un backdoor.

Qué es una web shell y por qué necesitas detectarla en el servidor

Una web shell es un fichero, normalmente PHP en el mundo WordPress, que da al atacante control remoto sobre el servidor a través del navegador. Con ella puede ejecutar comandos, subir y descargar ficheros, leer la base de datos o reinstalar el resto del malware cada vez que lo eliminas. Es la técnica catalogada como Web Shell (T1505.003) en MITRE ATT&CK, y es la razón por la que un SEO spam de casino o un pharma hack «vuelven» sin explicación. Detectarla en el servidor es, por tanto, el paso que hace que cualquier limpieza sea definitiva.

Dónde se esconden: los IoC en el sistema de ficheros

Las web shells buscan pasar desapercibidas mezclándose con ficheros legítimos. Estos son los indicadores más fiables:

• PHP donde no debería haberlo: ficheros .php dentro de wp-content/uploads, en carpetas de caché o en directorios de imágenes. Ahí nunca hay código ejecutable legítimo.
• Nombres que imitan al núcleo: ficheros como wp-conf.php, wp-load-old.php o nombres pseudoaleatorios que fingen pertenecer a WordPress.
• Código ofuscado: uso de eval, base64_decode, gzinflate, str_rot13 o assert encadenados, y cadenas largas de texto codificado.
• Timestamps incoherentes: un fichero del núcleo con fecha de modificación reciente, o varios ficheros con la misma fecha exacta, son un IoC claro. Lo tratamos a fondo en el caso de tu web en Google con texto japonés o chino, donde los timestamps delatan la inyección.
• Permisos anómalos: ficheros con permisos 777 o propiedad de un usuario que no corresponde al del servicio web.

IoC más allá de los ficheros

Una web shell deja rastro también fuera del disco. Revisa:

• Logs de acceso: peticiones POST repetidas a un único fichero, accesos desde IPs desconocidas a rutas que no existen en tu menú, o User-Agents vacíos o falsificados.
• Procesos y conexiones: procesos PHP lanzando comandos de sistema, conexiones salientes hacia servidores de mando y control.
• Usuarios administradores fantasma en WordPress creados fuera de tu control.
• Tareas programadas: entradas cron o eventos de wp-cron que reinyectan malware. La técnica de servir contenido distinto a bots la analizamos en nuestra guía práctica para detectar cloaking con curl y user-agents, útil para confirmar qué hace realmente el backdoor.

Cómo confirmarlo con método

La detección fiable combina tres enfoques. Primero, comparación de integridad: coteja tus ficheros de núcleo con una copia oficial de la misma versión de WordPress; cualquier diferencia es sospechosa. Segundo, búsqueda de patrones: rastrea el árbol de ficheros en busca de funciones peligrosas y código ofuscado. Tercero, correlación temporal: ordena los ficheros por fecha de modificación y examina todo lo que cambió alrededor de la fecha del incidente. Un backdoor rara vez viaja solo; suele haber varios, unos como respaldo de otros.

Ten cuidado con los falsos positivos: no todo base64 es malicioso y algunos plugins legítimos ofuscan código. El criterio es el contexto: ubicación del fichero, coherencia con el resto del proyecto y correlación con el resto de IoC.

Cómo erradicar la persistencia

• Aísla y rota credenciales antes de tocar nada: SFTP, base de datos, panel y WordPress.
• Elimina todas las web shells localizadas y no des por cerrada la búsqueda tras encontrar la primera.
• Purga usuarios fantasma, cron malicioso y cualquier inyección en tema y plugins.
• Restaura el núcleo desde ficheros oficiales y actualiza todo a la última versión.
• Endurece: desactiva la ejecución de PHP en uploads, deshabilita la edición de ficheros desde el panel y activa monitorización de integridad para detectar reapariciones.

Aplicamos esta metodología tanto en pymes con un WordPress como en entornos exigentes de banca y comercios con datos de tarjeta, donde una web shell no encontrada es una brecha con implicaciones legales, no solo un problema de SEO. En esos casos documentamos cada IoC y cada acción para que la respuesta sea auditable.

Para el detalle del contenido spam que estas puertas traseras sostienen, conviene entender las políticas de spam de Google, y el blog de Sucuri publica análisis de web shells reales que ayudan a reconocer variantes nuevas. Si quieres una revisión guiada de tu servidor, contacta con nosotros.