---
url: 'https://www.corbado.com/es/blog/brecha-datos-optus'
title: '¿Cómo ocurrió la brecha de datos de Optus y cómo evitarla?'
description: 'Explore los fallos de seguridad clave detrás de la brecha de datos de Optus de 2022 que afectó a 10 millones de clientes. Conozca las mejores prácticas de seguridad de API y autenticación.'
lang: 'es'
author: 'Vincent Delitz'
date: '2026-05-27T09:34:15.384Z'
lastModified: '2026-05-27T09:34:31.531Z'
keywords: 'Optus, brecha de datos de Optus, ataque cibernético en Australia, privacidad de datos en Australia, vulnerabilidades de API, prevención de brechas'
category: 'Authentication'
---

# ¿Cómo ocurrió la brecha de datos de Optus y cómo evitarla?

## Key Facts

- La **API pública no segura** estuvo accesible para cualquier persona en internet durante hasta tres meses, lo que permitió la extracción directa de datos confidenciales de casi 10 millones de clientes de Optus.
- Los **identificadores de clientes secuenciales** (p. ej., 5332, 5333) permitieron a los atacantes automatizar la exfiltración completa de la base de datos con un simple script, acelerando la escala y la velocidad de la brecha.
- Un **error de codificación de 2018** debilitó los controles de acceso. Se parcheó en el sitio principal de Optus en agosto de 2021, pero nunca se aplicó a un dominio secundario, que permaneció expuesto hasta la brecha de 2022.
- Las **API sin autenticación** son la segunda vulnerabilidad más común según OWASP. La autenticación multifactor en cada solicitud de conexión y las pruebas de penetración son las contramedidas recomendadas para prevenir la explotación.

## 1. Introducción

En septiembre de 2022, Optus, uno de los principales proveedores de telecomunicaciones de Australia, sufrió una brecha de datos que expuso la información personal de casi 10 millones de clientes. Este incidente marcó uno de los mayores ataques cibernéticos en la historia de Australia, lo que generó grandes preocupaciones sobre la privacidad de los datos y las prácticas de seguridad en el país.

![mapa de la brecha de Optus](https://www.corbado.com/website-assets/optus_breach_5f928dbf73.jpg)

Este artículo se centrará en las siguientes preguntas:

- ¿Qué fallos de seguridad tenía Optus que llevaron a la brecha de datos?
- ¿Cuáles son algunos métodos de contramedida que Optus podría haber utilizado para evitar la brecha de seguridad?

## 2. Fallos de seguridad que llevaron a la brecha de datos de Optus

A continuación, encontrará los 5 fallos de seguridad de la brecha de datos en Optus.

### 2.1 Fallo de seguridad n.º 1: API pública expuesta

El primer gran fallo de seguridad en la brecha de Optus fue el uso de una API (interfaz de programación de aplicaciones) pública que facilitaba el acceso a datos internos confidenciales. Las API públicas están diseñadas para permitir que los sistemas externos interactúen con los servicios de una empresa, pero cuando estas API no están debidamente aseguradas, pueden convertirse en una puerta de entrada para los atacantes.

**¿Para qué se utilizan las API públicas?**

Las API públicas seguras, como por ejemplo la API de Google Maps o la API del clima, proporcionan datos limitados y no confidenciales a sistemas externos. Están diseñadas para aislar cualquier dato compartido de las operaciones comerciales centrales, lo que las hace inherentemente más seguras.

**¿Por qué las API públicas son un problema en este caso?**

A diferencia de las [API seguras](https://www.wiz.io/academy/api-security-best-practices), la API de Optus exponía información confidencial de los clientes y carecía de las medidas de seguridad esenciales. Esto la hacía vulnerable a los atacantes que podían localizarla a través de escaneos en internet.

**¿Cómo podrían los atacantes explotar esta API?**

Sin autenticación ni aislamiento de datos, los atacantes podían conectarse directamente a la API y extraer información confidencial de los clientes, eludiendo las medidas de seguridad internas.

### 2.2 Fallo de seguridad n.º 2: API no segura que concede acceso a datos confidenciales de clientes

El segundo gran fallo de seguridad en la brecha de datos de Optus fue que **la API no estaba asegurada**. Por lo tanto, concedía acceso a datos de clientes altamente confidenciales. Si bien el primer problema giraba en torno a que la API fuera pública, el problema crítico aquí fue su falta de controles de acceso adecuados, lo que permitió un acceso sin restricciones a información confidencial.

Cuando un cliente de Optus accede a su cuenta a través de la aplicación móvil o el sitio web de Optus, las API facilitan la comunicación entre los sistemas frontend y backend para recuperar los datos necesarios. Estos procesos backend a menudo manejan información confidencial para cargar los perfiles de los clientes.

En este caso, la API expuesta proporcionó a los atacantes acceso directo a los siguientes tipos de datos personales, que son particularmente valiosos para el robo de identidad y el fraude:

• Números de licencia de conducir • Números de teléfono • Fechas de nacimiento • Direcciones particulares

Un análisis de los registros públicos del sistema de nombres de dominio (DNS) reveló más tarde que esta API probablemente era de cara al público y estuvo accesible para cualquier persona en internet durante un máximo de tres meses.

### 2.3 Fallo de seguridad n.º 3: Uso de identificadores de clientes incrementales

El tercer fallo de seguridad en la brecha de datos de Optus fue el uso de identificadores de clientes incrementales. En el mundo digital, los identificadores únicos de clientes (compuestos por secuencias aleatorias de números y letras) se utilizan para diferenciar las cuentas de forma segura. **Las mejores prácticas de ciberseguridad dictan que estos identificadores deben ser aleatorios** y no estar relacionados, para evitar que los piratas informáticos identifiquen patrones.

**Identificador de cliente de Optus**: En este caso, los identificadores de clientes seguían un patrón predecible, difiriendo por un incremento de 1. Por ejemplo, si el identificador de un cliente era 5332, el siguiente sería 5333. Una vez que el pirata informático obtuvo acceso a la base de datos, pudo escribir un script automatizado para extraer cada registro simplemente incrementando el identificador.

Este enfoque automatizado aceleró el proceso de robo de datos, permitiendo al atacante exfiltrar datos confidenciales de clientes a gran escala. El fallo de diseño predecible permitió que la brecha de Optus se produjera más rápido y afectara a más clientes de lo que hubiera sido posible de otro modo.

### 2.4 Fallo de seguridad n.º 4: Controles de acceso debilitados debido a un error de codificación

Aparte de las vulnerabilidades de la API y de los ID de los clientes, hubo más problemas de seguridad: En 2018, **un error de codificación debilitó los controles de acceso en ciertos dominios de Optus**, haciéndolos menos seguros. Aunque Optus solucionó este problema en su sitio web principal en agosto de 2021, no aplicó la misma solución a un sitio web secundario que era accesible en internet. Este dominio secundario permaneció vulnerable hasta que se descubrió la brecha en septiembre de 2022.

Este descuido dejó una importante brecha de seguridad. Los dominios públicos son un objetivo común para los atacantes, y cualquier fallo no parcheado aumenta el riesgo de acceso no autorizado. En este caso, el error de codificación hizo posible que los atacantes eludieran los controles de acceso y accedieran a datos confidenciales.

Pasar por alto los dominios secundarios o menos visibles puede dejar abiertas vulnerabilidades críticas, que los atacantes pueden explotar con facilidad. Las auditorías periódicas y las pruebas exhaustivas son esenciales para garantizar que las actualizaciones de seguridad se apliquen en todos los lugares donde se necesiten.

### 2.5 Fallo de seguridad n.º 5: Segundo dominio vulnerable

Esta falta de supervisión adecuada se extendió al dominio secundario, que desempeñó un papel clave en la brecha. Aunque el dominio no estaba en uso activo, permaneció en línea y desprotegido durante un período prolongado. A pesar de ser innecesario para las operaciones diarias, no se aseguró con controles de acceso adecuados ni se desmanteló, creando un punto de entrada fácil para que los atacantes lo explotaran.

Incluso cuando no están en uso activo, dichos dominios pueden servir como vectores de ataque si existen vulnerabilidades. Para mitigar estos riesgos, las empresas deben auditar regularmente sus activos digitales, desmantelar de inmediato los dominios no utilizados o aplicar el mismo nivel de seguridad que a los sistemas activos.

## 3. ¿Cómo evitar tales brechas de datos?

Para evitar brechas de datos similares al hackeo de Optus y mitigar el riesgo de daño a la reputación, las organizaciones pueden adoptar diferentes estrategias de seguridad que puede encontrar a continuación:

### 3.1 Contramedida n.º 1: Consultar el proyecto de seguridad de API de OWASP

El Proyecto de seguridad de API de OWASP es un recurso que se actualiza periódicamente y que destaca los riesgos de seguridad conocidos de las API. Es fundamental que los equipos de ciberseguridad supervisen habitualmente esta base de datos para identificar y abordar las vulnerabilidades que podrían afectar a su negocio. Abarca una amplia gama de riesgos potenciales, por ejemplo:

- **Autorización de nivel de objeto rota (BOLA):** Brechas en los permisos de acceso de los usuarios que permiten el acceso no autorizado a los datos.

- **Exposición excesiva de datos:** API que devuelven más información de la necesaria, lo que aumenta el riesgo de fugas de datos confidenciales.

- **Configuraciones de seguridad incorrectas:** Configuraciones o valores predeterminados mal alineados que exponen las API confidenciales a ataques.

- **Fallas de inyección:** Atacantes que explotan las API para inyectar comandos o datos maliciosos.

### 3.2 Contramedida n.º 2: Asegurar todas las API con un protocolo de autenticación

El Proyecto de seguridad de API de OWASP **destaca a las API sin autenticación como la segunda vulnerabilidad de API más común**. Estas API no requieren un nombre de usuario, contraseña ni ningún otro método de autenticación para establecer una conexión, lo que las deja altamente vulnerables a la explotación. Este tipo de debilidad jugó un papel central en la brecha de datos de Optus.

En algunos casos, las API se dejan sin autenticar de forma intencionada para mantener la compatibilidad con los sistemas heredados o para fines de prueba. Es probable que Optus dejara su API sin autenticar por razones similares. Sin embargo, no importa cuán críticos puedan ser los requisitos del sistema heredado o de las pruebas, implementar cualquier API, ya sea interna o pública, sin autenticación es un riesgo de seguridad significativo.

**Cómo prevenir la explotación de API sin autenticación**

Para salvaguardar sus API, cada solicitud de conexión debe estar asegurada con **Autenticación multifactor (MFA)**. MFA agrega una capa adicional de protección al requerir múltiples formas de verificación, lo que la convierte en una de las formas más efectivas y sencillas de bloquear el acceso no autorizado a las API y a las cuentas de los usuarios.

**Identificación de vulnerabilidades de API ocultas**

Una política de seguridad de API solo es efectiva si se tienen en cuenta todas las API que requieren protección. Pero, ¿qué sucede si su organización está expuesta sin saberlo por una API pública, como fue el caso de Optus?

Las API ocultas o ignoradas son difíciles de detectar con las herramientas de escaneo estándar. La forma más efectiva de descubrirlas es mediante **pruebas de penetración** para exponer vulnerabilidades como:

- **Mecanismos de autenticación débiles:** Sistemas que aceptan contraseñas en texto plano o credenciales mal cifradas.

- **Exposición al relleno de credenciales o ataques de fuerza bruta:** Explotación de nombres de usuario y contraseñas robados a gran escala.

- **Manipulación de parámetros de la API:** Revelación de detalles de autenticación confidenciales en direcciones URL o respuestas.

## 4. Conclusión

En conclusión, la brecha de datos de Optus subraya la importancia crítica de implementar medidas de ciberseguridad sólidas y auditar periódicamente los activos digitales. El no asegurar las API, no hacer cumplir los protocolos de autenticación adecuados y no abordar las vulnerabilidades ignoradas en los dominios secundarios contribuyó significativamente a este incidente. Al adoptar las mejores prácticas de la industria, como las descritas en el Proyecto de seguridad de API de OWASP, y priorizar estrategias de seguridad integrales, las organizaciones pueden protegerse contra brechas similares, proteger los datos confidenciales de los clientes y, lo más importante, mantener la confianza de sus usuarios.

## Preguntas frecuentes

### ¿Qué datos personales se robaron en la brecha de Optus y por qué es tan perjudicial?

La API expuesta dio a los atacantes acceso directo a números de licencia de conducir, números de teléfono, fechas de nacimiento y direcciones particulares. Estos tipos de datos son especialmente valiosos para el robo de identidad y el fraude, lo que hace que la brecha sea particularmente dañina para los clientes afectados.

### ¿Por qué una empresa dejaría una API sin autenticar en primer lugar?

A veces, las API se dejan sin autenticar de forma intencionada para mantener la compatibilidad con los sistemas heredados o para fines de prueba, que probablemente fue el caso de Optus. Sin embargo, implementar cualquier API, ya sea interna o pública, sin autenticación es un riesgo de seguridad significativo, independientemente de la justificación operativa.

### ¿Cómo pueden los equipos de seguridad descubrir las API ocultas o ignoradas antes de que los atacantes las exploten?

Las herramientas de escaneo estándar tienen dificultades para detectar las API ocultas o ignoradas. El enfoque más eficaz son las pruebas de penetración, que pueden exponer mecanismos de autenticación débiles, la exposición a ataques de relleno de credenciales y los detalles de autenticación confidenciales revelados en las URL o en las respuestas de la API.

### ¿Qué es el Proyecto de seguridad de API de OWASP y cómo ayuda a las organizaciones a evitar brechas como la de Optus?

El Proyecto de seguridad de API de OWASP es un recurso que se actualiza periódicamente y que cataloga los riesgos de seguridad conocidos de las API, como la autorización de nivel de objeto rota, la exposición excesiva de datos, las configuraciones de seguridad incorrectas y las fallas de inyección. Los equipos de ciberseguridad deben monitorearlo de manera rutinaria para identificar y abordar las vulnerabilidades antes de que los atacantes puedan explotarlas.