Introducción

Oracle PeopleSoft sigue siendo la columna vertebral de sistemas de RRHH, reclutamiento y gestión administrativa en agencias gubernamentales y corporaciones Fortune 500. El 2026 arrancó con una advertencia concreta: ShinyHunters, el mismo grupo vinculado a la campaña de Clop contra Oracle E-Business Suite en 2025, declaró haber explotado una vulnerabilidad de ejecución remota de código (RCE) sin parche en PeopleSoft para comprometer infraestructura del FBI y extraer entre 2 y 3 TB de datos sensibles. El FBI confirmó que investiga la actividad en FBIjobs.gov sin validar todavía la intrusión, pero 404 Media verificó parcialmente un lote de aproximadamente 5.000 registros de empleados donde números telefónicos coincidían con personal del Departamento de Justicia. Para cualquier equipo que administre PeopleSoft on-premise o en cloud, el mensaje es directo: un vector RCE no parcheado en un ERP de RRHH habilita movimiento lateral hacia entornos AWS GovCloud, servicios de nómina, bases de datos de candidatos y registros médicos internos.

Qué ocurrió

ShinyHunters contactó a BleepingComputer y a 404 Media con capturas de pantalla del sitio apply.fbijobs.gov defaceado con el logo de Umbreon (un Pokémon de tipo Siniestro) y el mensaje «THIS SITE HAS BEEN SEIZED BY SHINYHUNTERS. rooting your systems since ’19 ;)». El grupo afirmó haber utilizado el zero-day de PeopleSoft un lunes por la noche para obtener acceso inicial, ejecutar código remoto en los servidores del portal de empleo y desde ahí pivotar hacia servicios internos: FBI Criminal Justice, HR, Medlink y otros sistemas de gestión de personal. Una vez dentro, el acceso derivó hacia la infraestructura AWS GovCloud que el FBI utiliza para almacenar información de empleados activos, exfuncionarios y solicitantes de ingreso.

El FBI respondió a BleepingComputer con una declaración acotada: «The FBI is aware of claims regarding unauthorized activity affecting FBIjobs.gov and is currently investigating.» No confirmaron ni negaron la exfiltración. Según ShinyHunters, la agencia detectó la intrusión de inmediato y «literalmente cortó la luz de todo», desconectando simultáneamente múltiples redes internas. El sitio de FBI Jobs pasó a mostrar un mensaje de mantenimiento. El grupo también declaró que intentó borrar evidencia de los servidores comprometidos para dificultar la identificación forense del exploit, una técnica que complica la respuesta de incidentes y la posterior clasificación del CVE.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

El vector de ataque no es teórico. PeopleSoft se despliega en cientos de organizaciones que gestionan datos de RRHH, nómina y salud ocupacional bajo marcos regulatorios estrictos (HIPAA, FISMA, GDPR). Si el zero-day es real, cualquier instancia de PeopleSoft expuesta a internet sin parche aplica un riesgo de RCE comparable al que Oracle E-Business Suite demostró en 2025, cuando la campaña de Clop comprometió a más de 1.000 organizaciones. La diferencia aquí es el salto desde un ERP de RRHH hacia AWS GovCloud: una vez que el atacante ejecuta código en el host de PeopleSoft, el movimiento lateral puede alcanzar credenciales IAM, buckets S3, bases de datos RDS y servicios internos que operan detrás de grupos de seguridad de VPC.

Para equipos de cloud security, el incidente refuerza una tensión operativa conocida: los entornos GovCloud de AWS y Google Cloud están diseñados con aislamiento y controles FedRAMP, pero ese aislamiento se diluye si un único servidor on-premise o en la periferia de la red funciona como puente. ShinyHunters no atacó AWS GovCloud directamente; atacó PeopleSoft y usó esa posición para alcanzar la nube. Los equipos de infraestructura que administran conexiones híbridas —VPN IPsec, AWS Direct Connect, Google Cloud Interconnect— deben revisar si los hosts que terminan esos túneles tienen segmentación suficiente para que una RCE en un ERP no derive en acceso a cargas de trabajo críticas.

Detalles técnicos

La vulnerabilidad se describe como un RCE en Oracle PeopleSoft sin CVE asignado y sin parche disponible al momento de la denuncia. BleepingComputer contactó a Oracle y al equipo de threat intelligence de Mandiant (Google Cloud) para confirmar la existencia del flaw; a la fecha de publicación del reportaje, ninguna de las dos organizaciones había emitido una confirmación pública. El precedente directo es CVE-2025-61882, la vulnerabilidad de Oracle E-Business Suite que Clop explotó masivamente en 2025 y cuyo proof-of-concept fue filtrado por un subgrupo llamado «Scattered Lapsus$ Hunters» que incluía a ShinyHunters. Oracle confirmó que ese PoC coincidía con el exploit real.

El movimiento lateral desde PeopleSoft hacia AWS GovCloud implica al menos dos pasos técnicos: (1) ejecución de código en el sistema operativo del host PeopleSoft —típicamente Oracle Linux o Windows Server— con privilegios suficientes para leer credenciales de aplicación, tokens de sesión o archivos de configuración que contengan access keys de AWS; (2) uso de esas credenciales para interactuar con la API de AWS GovCloud y enumerar recursos S3, RDS o EC2. La mención de «Medlink» sugiere acceso a sistemas de salud ocupacional, lo que eleva la criticidad de los datos a PHI (Protected Health Information).

ShinyHunters declaró que borró logs y artefactos en los servidores comprometidos. Esto reduce la ventana de forense y obliga a depender de telemetría externa: CloudTrail, VPC Flow Logs, y logs de red en los concentradores VPN (Cisco ASA, Palo Alto GlobalProtect, AWS Client VPN) que registren conexiones desde el segmento de PeopleSoft hacia subredes de AWS durante la ventana temporal del ataque.

Qué deberían hacer los administradores y equipos técnicos

Inventario y exposición de PeopleSoft. Listar todas las instancias de Oracle PeopleSoft (HR, Financials, Campus Solutions) con su versión exacta. Ejecutar un escaneo de puertos y servicios expuestos a internet:

nmap -sV -p 80,443,7000-7003,9000,9001,9500 \
–script http-headers,http-methods \
-oG peoplesoft_exposure.txt \
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

Si alguna instancia responde a internet sin WAF o sin acceso restringido por IP, cerrarla inmediatamente.

Revisar telemetría de AWS GovCloud y cuentas híbridas. Filtrar CloudTrail por eventos ConsoleLogin, AssumeRole, ListBuckets, DescribeDBInstances y RunInstances en las últimas 96 horas. Identificar cualquier sesión que origine desde IPs del segmento de red donde vive PeopleSoft:

aws cloudtrail lookup-events \
–lookup-attributes AttributeKey=EventSource,AttributeValue=s3.amazonaws.com \
–start-time $(date -u -d ’96 hours ago’ +%Y-%m-%dT%H:%M:%SZ) \
–query ‘Events[?contains(UserIdentity.SessionContext.SessionIssuer, `peoplesoft`)]’

Reforzar segmentación de red. Aplicar reglas de security group y NACL en AWS que impidan tráfico este-oeste desde la subred de PeopleSoft hacia cargas de trabajo de datos. Si usan VPN para acceso administrativo, forzar MFA y restringir rutas permitidas. En concentradores como Cisco ASA o Palo Alto, auditar las políticas de split-tunnel:

# Ejemplo: regla de VPC Security Group (deny-all inbound desde subred Peoplesoft)
– Description: «Block lateral from PeopleSoft subnet to data tier»
GroupId: sg-data-tier-01
IpPermissions:
– IpProtocol: tcp
FromPort: 3306
ToPort: 3306
CidrIp: 10.20.0.0/16 # Subred PeopleSoft
Policy: «deny»

Preparar respuesta ante un RCE no parcheado. Si Oracle publica un advisory, priorizar la aplicación del parche con ventana de downtime planificada. Mientras no exista parche, aplicar reglas de WAF específicas para bloquear payloads de deserialización y paths de PeopleSoft (/PSIGW/, /psc/, /psp/), y monitorear procesos hijos anómalos del demonio de PeopleSoft (psadmin, pslist, jboss, weblogic) con herramientas como osquery o Falco:

osquery query: SELECT pid, name, cmdline, parent
FROM processes
WHERE parent IN (SELECT pid FROM processes WHERE name=’psadmin’)
AND name NOT IN (‘psadmin’,’pslist’,’pswatch’,’pswatchd’);

Verificar integridad de backups. Confirmar que los snapshots de RDS y las copias de S3 están en cuentas distintas a la que PeopleSoft puede alcanzar con sus credenciales IAM. Si el atacante borra evidencia en los servidores locales, la recuperación depende de copias aisladas.

Conclusión

BleepingComputer no verificó de forma independiente la existencia del zero-day ni el volumen exacto de datos exfiltrados. Sin embargo, el patrón de ataque es coherente con la actividad previa de ShinyHunters en Oracle E-Business Suite y con el playbook de extorsión que el grupo viene ejecutando contra el sector educativo y corporativo desde 2025. El FBI investiga. Oracle y Mandiant no han emitido confirmación. Para los equipos que no administran infraestructura del FBI pero sí corren PeopleSoft en producción, la ventana de acción es ahora: cerrar exposición innecesaria, validar segmentación hacia entornos cloud y tener los playbooks de respuesta listos antes de que un advisory confirme el CVE.

Fuentes

  • https://www.bleepingcomputer.com/news/security/shinyhunters-claims-fbi-hack-data-theft-in-peoplesoft-zero-day-breach/

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *