¿Qué pasó realmente con el hackeo a Oracle?

El 21 de marzo de 2025 surgió una de las filtraciones más graves del año, pero lo más desconcertante no fue el ataque en sí, sino la negación sistemática por parte de Oracle.
La información revela que más de 140,000 usuarios habrían sido afectados y que 6 millones de líneas de datos fueron exfiltradas desde servidores de Oracle Cloud.

Esto incluye contraseñas cifradas, archivos JKS, claves privadas y otros datos extremadamente sensibles usados en entornos empresariales.
“Es decir, si roban el JKS… es como pillar un cofre del tesoro para un pirata: lleno de contraseñas y absolutamente todo.”

El servidor comprometido fue el login.us2.oraclecloud.com, y tras el anuncio del atacante, Oracle negó que ese entorno tuviera uso productivo. Sin embargo, evidencias posteriores muestran que sí estaba en uso activo en sus propios tutoriales.

¿Por qué es tan grave un ataque a la cadena de suministro digital?

Porque no es un ataque directo a una empresa, sino a una plataforma que da servicio a cientos de compañías. Oracle es proveedor tecnológico de gigantes como Tesla, Mastercard, Nike o Chase.
Es el clásico escenario de riesgo en ciberseguridad: atacas a uno y multiplicas el daño.

“Ya sabéis, cadena de suministro: yo no te hackeo a ti como empresa, sino que hackeo a quien tú usas.”

Oracle ofrece desde infraestructura física hasta soluciones en la nube, CRM y sistemas ERP. Este incidente demuestra que incluso empresas históricamente confiables pueden ser vulnerables si no actualizan sus componentes críticos. En este caso, el servidor comprometido llevaba sin actualizarse desde 2014.

¿Qué evidencias indican que Oracle fue hackeado?

Tres evidencias clave, ignoradas públicamente por Oracle, apuntan a que sí hubo un ataque real:

1. Un archivo .txt en login.us2.oraclecloud.com contenía el email del atacante.
2. Referencias dentro del propio código de Oracle al servidor comprometido.
3. Listas de usuarios y contraseñas filtradas que coinciden con las bases de datos reales de empresas clientes.

Además, el servidor aparecía indexado en la Wayback Machine, con una dirección de contacto alojada en Protonmail: un servicio cifrado muy usado por ciberdelincuentes.
“Demasiada coincidencia que justo el tipo que vende los datos tenga acceso a ese servidor y haya dejado su email ahí.”

¿Qué son los archivos JKS y por qué preocupan tanto?

JKS significa Java Key Store, un almacén de certificados y claves privadas utilizado por aplicaciones Java para autenticarse.

Si se extraen estos archivos, el atacante puede acceder o suplantar aplicaciones internas sin ser detectado, especialmente si las claves están mal cifradas o las contraseñas también han sido filtradas.

“Estos almacenes… imagínalos como una base de datos. Están llenos de contraseñas, claves privadas y datos cifrados.”

Y lo peor: muchas veces las aplicaciones usan estas claves para firmar comunicaciones sensibles. El atacante no solo roba datos, también puede interceptar y manipular tráfico interno entre sistemas.

¿Qué es Single Sign-On (SSO) y cómo fue comprometido?

El ataque afectó los mecanismos de Single Sign-On (SSO), una funcionalidad que permite a los empleados de una empresa usar una sola cuenta para acceder a múltiples servicios.

“Imagínate que trabajas para Facebook y usas @facebook.com para loguearte no solo en tu correo, sino también en Oracle Cloud.”

Esta conexión se basa en confianza mutua entre servidores. Si Oracle guarda archivos de configuración de estos SSO (como contraseñas cifradas o tokens), y alguien los extrae, puede acceder a múltiples entornos empresariales con credenciales válidas.

Este tipo de ataque permite una escalada lateral muy peligrosa: acceder a Oracle y desde ahí a sus clientes.

¿Por qué Oracle niega el ataque?

Hasta ahora, Oracle sostiene que no hubo ninguna intrusión a Oracle Cloud y que, en el peor de los casos, algunos clientes fueron comprometidos de forma aislada.

Sin embargo, múltiples fuentes como Reuters, Bloomberg, CloudSec y expertos en ciberseguridad contradicen esta versión.
“Oracle dice que esto no ha pasado y si ha pasado ha sido en tu cabeza. Así que déjanos en paz.”

Esto plantea una cuestión crítica: ¿está Oracle ignorando voluntariamente el incidente para evitar obligaciones legales, como notificar a clientes en menos de 48 horas?

¿Se puede probar que el servidor vulnerado estaba activo?

Sí. El servidor login.us2.oraclecloud.com aparece mencionado como endpoint oficial en tutoriales públicos de Oracle.
Además, las herramientas de archivado web demuestran que estuvo activo hasta días antes del escándalo. Esto invalida el argumento de que era un entorno de pruebas sin valor real.

“No me digas que no estás usando ese servidor… si aparece en tu documentación pública.”

¿Podrían las credenciales filtradas venir de GitHub?

Una teoría sugiere que algunas contraseñas llegaron al atacante por errores humanos: desarrolladores que subieron archivos con credenciales a repositorios públicos.

Este vector de ataque es conocido y, aunque posible, no explica cómo accedieron al servidor y colocaron un archivo .txt allí. Más bien indica que el atacante recopiló información desde múltiples frentes y usó ese acceso para moverse lateralmente dentro de la infraestructura.

¿Qué impacto puede tener este caso en Oracle?

Si se confirma el hackeo, Oracle se enfrentaría a:

• Sanciones regulatorias por no notificar a tiempo (GDPR, CCPA).
• Pérdida de confianza corporativa.
• Cancelación de contratos empresariales clave.
• Daño reputacional duradero.

El caso recuerda a Snowflake, otra empresa de infraestructura que negó un ataque y acabó admitiéndolo tras múltiples filtraciones.

“Snowflake fue hackeada, dijeron que no, luego que sí, y acabaron multados. Esto puede ser igual.”

¿Qué deben hacer las empresas que usan Oracle?

1. Auditar sus accesos y permisos SSO inmediatamente.
2. Cambiar claves asociadas a Oracle Cloud y revisar los logs de acceso.
3. Verificar si su infraestructura tiene dependencia del servidor login.us2.
4. Implementar controles de detección de anomalías en tráfico hacia Oracle.
5. Solicitar un informe oficial a Oracle sobre su estado de seguridad.

¿Cómo prevenir ataques similares a futuro?

• Segmentar accesos y no confiar ciegamente en proveedores externos.
• Auditorías regulares de sistemas heredados, especialmente servidores sin mantenimiento desde hace años.
• Verificación de credenciales expuestas en repos públicos mediante herramientas como GitGuardian.
• Adoptar Zero Trust como modelo operativo.

¿Qué debería haber hecho Oracle desde el primer momento?

Lo correcto habría sido:

• Confirmar el ataque en cuanto se tuvo evidencia.
• Comunicar a los clientes posibles riesgos de exfiltración.
• Colaborar con investigadores externos en lugar de minimizar el incidente.

La cultura de la negación, en ciberseguridad, solo retrasa lo inevitable: la verdad se sabrá, y cuanto más tarde llegue, más grave será la consecuencia.

¿Estamos ante uno de los peores hackeos de 2025?

Todo indica que sí. Por la cantidad de usuarios afectados, la criticidad de los sistemas involucrados y el silencio corporativo, el hackeo a Oracle puede ser uno de los eventos de ciberseguridad más significativos del año.

“Si esto es real, estamos ante uno de los grandes hackeos de supply chain de 2025. Y eso que estamos en marzo.”

Conclusión: ¿Qué lecciones deja este caso?

El caso Oracle enseña que la transparencia y la proactividad son más importantes que la reputación momentánea.
En un entorno donde todo queda registrado, negar lo evidente solo agrava las consecuencias. Las empresas deben entender que confiar en terceros no elimina la responsabilidad de proteger sus datos.

Y los proveedores como Oracle, por más grandes y confiables que hayan sido, no están exentos de fallos estructurales si no evolucionan.