La banda de extorsión ShinyHunters ha reanudado su explotación masiva de la vulnerabilidad crítica CVE-2026-35273 en Oracle PeopleSoft mediante una nueva técnica de evasión que anula las protecciones de los cortafuegos de aplicaciones web. Al emplear URLs con codificación de caracteres, los atacantes consiguen que sus solicitudes lleguen al endpoint vulnerable sin ser bloqueadas por los WAF que muchas organizaciones desplegaron como medida compensatoria.
La nueva técnica de evasión de WAF que utiliza URL codificada
En lugar de enviar peticiones directas al punto final vulnerable /PSEMHUB/, la banda emplea ahora la variante /%50SEMHUB/. La secuencia %50 no es más que la representación percent-encoded de la letra «P». Esa simple conversión es suficiente para burlar los filtros que buscan coincidencias exactas con la ruta literal.
| Ruta enviada por el atacante | Ruta que inspecciona el WAF | Ruta que procesa WebLogic |
|---|---|---|
| /PSEMHUB/ | /PSEMHUB/ | /PSEMHUB/ |
| /%50SEMHUB/ | /%50SEMHUB/ | /PSEMHUB/ |
Muchos cortafuegos de aplicaciones web y proxies inversos comparan la ruta cruda de la solicitud antes de decodificarla. Ven %50SEMHUB como una ruta diferente y, por tanto, la regla diseñada para bloquear /PSEMHUB/ no se activa. Mientras tanto, Oracle WebLogic, que es el servidor de aplicaciones subyacente, decodifica la secuencia %50 al procesar la petición y la enruta directamente al componente vulnerable PSEMHUB.
¿Por qué la codificación de URL en la ruta logra evadir las reglas del WAF?
Porque los WAF inspeccionan el valor literal de la ruta sin decodificarlo, mientras que el servidor de aplicaciones lo interpreta tras haber decodificado la URL. Esa diferencia de interpretación permite que la solicitud maliciosa llegue al recurso protegido sin disparar las alertas, especialmente cuando los equipos de seguridad configuran excepciones demasiado específicas.
Detección y mitigación del compromiso en Oracle PeopleSoft
Mandiant, la empresa de seguridad que rastrea al grupo con el alias UNC6240, recomienda no confiar en los WAF y aplicar de inmediato el parche de Oracle para CVE-2026-35273. Para las organizaciones que no puedan actualizar de forma inmediata, la alternativa es revisar los registros de acceso de WebLogic y buscar patrones de ruta sospechosos. Además de la ruta literal /PSEMHUB/, hay que monitorizar variantes como /%50SEMHUB/, ya que el actor alterna esquemas de codificación para evitar su detección. Antes de intentar la explotación, el grupo envía entre cinco y quince solicitudes POST al recurso /%50SEMHUB/hub para comprobar si el servidor es vulnerable.
- Auditar los registros de acceso de WebLogic en busca de peticiones dirigidas a PSEMHUB, tanto en forma literal como codificada.
- Aplicar el parche de seguridad de Oracle correspondiente a CVE-2026-35273 antes de que se cierre la ventana de explotación activa.
- Configurar el WAF para normalizar las secuencias percent-encoded antes de comparar la URL con las reglas de bloqueo.
Impacto de la nueva campaña
La campaña más reciente ha afectado a docenas de servidores en sectores como la enseñanza superior, tecnología, servicios informáticos, salud, agricultura, transporte y administración pública. Los analistas de seguridad han identificado el despliegue de múltiples herramientas de acceso posterior, lo que evidencia la intención de mantener un acceso persistente a las redes comprometidas.
Entre las herramientas utilizadas se encuentran los shells x.jsp para ejecución de comandos, así como u.jsp y u2.jsp para transferencia de archivos. En sistemas Windows, la banda despliega un ejecutable llamado Ple64.exe, que se hace pasar por el instalador del reproductor multimedia Light Alloy pero que en realidad instala el malware SIDEEYE, capaz de robar credenciales, crear shells inversos y actuar como proxy. También utiliza el kit de túnel Neo-reGeorg para canalizar tráfico SOCKS5 a través de peticiones HTTP y HTTPS normales, así como los archivos tunnel.jsp y tunnel.jspx. En servidores Linux se ha observado el uso legítimo de MeshAgent para mantener el control remoto.
Contexto histórico: de la explotación inicial a la reivindicación del FBI
La actividad actual es la prolongación de una serie que comenzó el 10 de junio, cuando la banda aprovechó una vulnerabilidad de día cero para robar datos de cien organizaciones. Al día siguiente, Oracle publicó un parche urgente y asignó el identificador CVE-2026-35273, definiéndolo como un fallo de ejecución remota de código no autenticado. Ese mismo día, Google confirmó que ShinyHunters estaba atacando el sector educativo. La primera recomendación consistió en bloquear externamente el endpoint PSEMHUB mediante un WAF.
En septiembre, el grupo afirmó que había vuelto a comprometer servidores PeopleSoft para acceder a los sistemas del FBI, incluyendo la plataforma de empleo FBI Jobs y parte de la infraestructura en AWS GovCloud. Esas afirmaciones no han sido verificadas de forma independiente, y el FBI declaró que investigaba la posible actividad no autorizada. No obstante, ShinyHunters confirmó haber usado esta misma técnica de evasión de WAF contra FBI Jobs, aunque mantiene que también explotó una vulnerabilidad desconocida adicional en el mismo componente PSEMHUB.
La lección estratégica de este episodio es incómoda pero necesaria: los cortafuegos de aplicaciones son controles compensatorios que los atacantes estudian y superan con rapidez. La higiene de actualizaciones, la visibilidad sobre los registros y una postura defensiva en profundidad siguen siendo la salvaguarda real. A medida que ShinyHunters demuestra que puede adaptar sus herramientas a cada defensa, la comunidad de seguridad debe asumir que el siguiente avance de estas técnicas llegará antes de que muchas organizaciones hayan terminado de parchear los sistemas conocidos.
