De la petición a la consecuencia. Sin huecos.

Captura el código en el momento exacto en que el intérprete lo compila, ya sin ofuscación. Entonces comprueba dos cosas a la vez: que un trozo real de lo que envió el usuario haya llegado al argumento peligroso —no una coincidencia casual— y qué intención tiene ese código, con un motor propio embebido en el agente que puntúa por lo que el código hace. Del fichero en reposo se ocupa el motor antivirus de contenido en cuanto la webshell toca el disco. Y en paralelo se ve al propio proceso web abrir una shell del sistema.

Las siete clases de operación peligrosa —ejecutar, incluir, deserializar, escribir fichero, consultar SQL, comandos de Redis y consultas de MongoDB— se observan en el punto de uso, con su valor ya resuelto. El análisis es por valor: se exige que un fragmento real de la entrada del usuario llegue de verdad al argumento peligroso; por eso la ofuscación en la petición no sirve de nada. Ninguna clase queda fuera: el propio diseño impide añadir un punto peligroso sin decidir cómo se juzga.

SHIELD lee la consulta dentro del servidor, en el punto donde la aplicación la entrega al motor de datos —antes de que el cifrado la envuelva—, y reconoce el protocolo por su propia forma, así que funciona igual con puertos no estándar y con librerías sin nombres visibles. Sobre ese texto aplica el mismo análisis por valor: se marca cuando la entrada del usuario rompe la estructura de la consulta, que es lo que distingue una inyección de un dato normal. También ve la extracción: cuando, tras un payload sospechoso, la base de datos empieza a volcar registros hacia fuera.

Observa las operaciones exactas de un ataque sin fichero: crear memoria ejecutable y lanzarla sin tocar el disco, escribir en la memoria de otro proceso, pedir memoria de escritura y ejecución a la vez (la firma del shellcode), o cargar un programa dentro del propio núcleo del sistema. Todo desde el linaje web, que jamás debería hacer nada de esto.

Cada escritura se resuelve a su ruta real —a prueba de enlaces simbólicos y de rodeos por el árbol de directorios— y se compara con las ubicaciones de persistencia conocidas: claves de acceso remoto, tareas programadas, servicios de arranque, cuentas del sistema y ganchos de precarga. Solo cuenta si viene del proceso web; el mantenimiento legítimo del administrador queda exento.

Mantiene la historia de cada proceso y correla dentro de una ventana acotada: descarga externa → fichero marcado como ejecutable → su ejecución; webshell → conexión saliente; webshell → escritura en base de datos; webshell → fuga de datos por volumen; y el caso más silencioso, el fichero que la propia aplicación escribe y a continuación ejecuta, incluso si intenta disimular la ruta. Y por encima construye la campaña del atacante en etapas estándar del sector (acceso, ejecución, persistencia, mando y control, exfiltración), agregando todos sus incidentes bajo un mismo actor, aunque llegue por peticiones distintas.

La conexión saliente se deniega en el acto si la cuenta está en cuarentena o la IP figura en la lista de bloqueo (una única tabla que cubre IPv4 e IPv6, donde el permiso gana al bloqueo). El paquete entrante se descarta por su IP de origen en el punto más temprano posible, antes de entrar en la pila de red. La IP real del cliente se extrae del propio protocolo, aunque haya un proxy delante, y se atribuye a la petición correcta —no al proceso equivocado—. Y marca las conexiones que la aplicación abre hacia destinos internos vedados, el patrón clásico del robo de credenciales en la nube.

Aprende, cuenta por cuenta, qué encadenamientos de acciones son normales, y puntúa la rareza de cada paso, no su frecuencia. El umbral se autocalibra tras un periodo de observación; el modelo se actualiza solo, pero nunca aprende como normal algo que ya marcó como anómalo, así que un atacante no puede acostumbrarlo poco a poco.

Mata el proceso anclado a su identidad real, para no alcanzar a otro por reutilización de identificador. Aísla la cuenta con un candado dentro del núcleo que le corta la ejecución y la red, sin tocar a las vecinas. Y neutraliza el fichero moviéndolo fuera de donde se sirve o dejándolo inservible, guardando siempre cómo revertirlo; si no puede, lo dice en vez de fingir que contuvo. La regla de oro viene de fábrica: contener exige una señal de certeza —una regla determinista, o un fichero cuyo veredicto es tan alto que el propio antivirus se eleva a contención reversible—; lo que solo opina un modelo o la conducta se queda en aviso, y solo puede llegar a contener si tú lo habilitas y además dos fuentes independientes coinciden.