Web shells, el archivo que no debía estar

La técnica de ATT&CK es T1505.003, un componente de servidor que persiste. Lo que enseñan las guías públicas de detección, entre ellas la de la NSA y el Australian Signals Directorate de 2020, es lo mismo en todos los casos: comparar contra lo conocido. Lo conocido es el manifiesto del último despliegue —la lista de archivos que el equipo puso— y lo normal en el tráfico y los procesos.

De ahí salen tres huellas. En el sistema de archivos: un archivo con extensión ejecutable (de script) nuevo, en una carpeta que solo debía recibir datos como imágenes o documentos, y que el despliegue no puso. En el registro de acceso: peticiones repetidas a ese archivo, casi siempre enviando datos, con respuestas de tamaño variable y un agente de usuario que no es el de un navegador. En los procesos: órdenes de sistema (un intérprete de órdenes, un listado, una consulta del sistema) cuyo proceso padre es el del servidor web, que en una tienda en línea no lanza nada.

Una sola huella es una pista; las tres juntas, una conclusión.

Un servidor de tienda en línea está lleno de archivos que no aparecen en el despliegue, y casi todos son normales: las portadas, fotos y documentos que suben los usuarios. Por eso comparar con el manifiesto no basta; se combina con la extensión y la carpeta. Una imagen en la carpeta de subidas no está en el manifiesto y no pasa nada. Un script en esa misma carpeta sí es raro: una carpeta que solo recibe datos no debería tener nada que el servidor sepa ejecutar.

Mira el inventario del sitio y busca, entre lo que el despliegue no puso, lo que no es una imagen. Fíjate también en la hora en que se creó.

La subida de ese archivo pasó por la página legítima de subir portadas: el formulario aceptó un archivo que no era una imagen, algo que la aplicación debería haber rechazado. Es el origen más habitual de un web shell: una subida de archivos sin comprobar el tipo. Una vez en el servidor, el atacante ya no usa el formulario, llama directamente al archivo.

En el registro de acceso eso se nota por el cambio de comportamiento: un origen que hasta ese momento solo visitaba el formulario empieza a pedir una única ruta, repetidamente y con el método de enviar datos, con un agente de usuario de programa y no de navegador. Los clientes normales de la tienda piden páginas distintas.

La tercera huella es la que convierte la sospecha en certeza. Un servidor de aplicaciones atiende peticiones y devuelve páginas: no lanza intérpretes de órdenes por su cuenta. Cuando el proceso del servidor aparece como padre de un intérprete de órdenes que ejecuta una orden de reconocimiento (quién soy, qué sistema es esto, qué hay en tal carpeta), alguien le está pasando esas órdenes por una petición.

Para casarlo con el registro de acceso, se cruzan las horas: el proceso hijo aparece uno o dos segundos después de la petición que lo provocó. Con ese cruce se sabe qué petición ejecutó qué orden, y se puede reconstruir qué miró el atacante. Nota que no todo lo que corre como el usuario del servidor es sospechoso: una tarea programada del propio sitio también corre con ese usuario, pero su padre es el programador de tareas.

Lo último que ejecutó el atacante fue leer el archivo de configuración del sitio, el que guarda las credenciales de la base de datos. Borrar el web shell es lo que apetece y es el primer error: destruye evidencia y no cierra el hueco por el que entró, ni lo que el atacante ya se llevó.

El orden de respuesta es otro: conservar una copia del archivo y su huella digital para análisis; contener el servidor siguiendo el procedimiento de respuesta (aislarlo de la red, o sacarlo del balanceador); escalar a respuesta a incidentes; tratar como expuestas las credenciales que ese archivo contenía; y arreglar la causa, que es la subida sin comprobar. Después se busca si hay otros archivos o accesos que dejó para volver.