Qué está pasando y por qué te toca de cerca
Si vives en República Dominicana y tienes una línea móvil, es probable que en las últimas horas hayas visto circular capturas de pantalla, mensajes de WhatsApp o publicaciones diciendo que "hackearon a Claro". Y es probable también que, en la misma conversación, alguien haya mencionado FortiBleed, una campaña global contra firewalls que se hizo pública en junio de 2026.
Son dos cosas distintas. Pueden estar conectadas o pueden no tener nada que ver. A día de hoy, nadie ha demostrado públicamente que lo estén.
Este texto intenta ordenar lo que hay: qué es FortiBleed y qué no es, qué se alega exactamente sobre Claro Dominicana, cuál es el estado real de verificación, y qué escenarios técnicos son plausibles, posibles o poco probables. Al final hay recomendaciones concretas para ti como cliente, que sirven tanto si la filtración se confirma como si resulta ser falsa.
¿Por qué importa distinguir? Porque "aparecer en un listado de credenciales de firewall" y "que se haya exfiltrado la base de clientes de un operador" son afirmaciones de peso muy diferente, y el ruido tiende a fundirlas en una sola.
Qué es FortiBleed (y qué no es)
Empecemos por lo que no es. A pesar del nombre, FortiBleed no es un día cero de Fortinet, y no hay evidencia de que los productos Fortinet hayan sido vulnerados por una falla desconocida. No tiene un CVE asociado. No es un "bleed" en el sentido de Heartbleed, donde un fallo de memoria permitía extraer datos de un servidor sin credenciales. El nombre es desafortunado y ha generado buena parte de la confusión.
Lo que sí es: a mediados de junio de 2026, investigadores identificaron una campaña activa y a gran escala de compromiso de credenciales que afectaba a firewalls Fortinet FortiGate, bautizada FortiBleed. Los actores habrían estado extrayendo de forma sistemática archivos de configuración de dispositivos FortiGate expuestos a internet y crackeando los hashes de credenciales almacenados, obteniendo credenciales de administrador verificadas como funcionales en entre 30.000 y 75.000 dispositivos repartidos en 194 países. La investigación de SOCRadar identificó infraestructura operativa del grupo, incluyendo bases de datos de credenciales validadas organizadas por país, sector e ingresos de la organización.
El hallazgo inicial se atribuye al investigador Volodymyr "Bob" Diachenko, y firmas como SOCRadar y Hudson Rock lo analizaron y divulgaron formalmente entre el 16 y el 17 de junio de 2026. Las estimaciones de alcance varían entre 73.932 y 86.644 dispositivos según la fuente. La causa técnica señalada de forma repetida es el almacenamiento de contraseñas con hashes SHA-256 heredados, vulnerables a crackeo por GPU, y la actividad asociada se rastrea al menos desde febrero de 2026.
El mecanismo completo mezcla varias técnicas, no una sola: la campaña no explota una vulnerabilidad específica, sino que utiliza credenciales obtenidas previamente —mediante filtraciones de datos e infecciones por malware de robo de información (infostealers)— para realizar intentos automatizados contra dispositivos Fortinet expuestos hasta identificar accesos válidos. A eso se suman contraseñas reutilizadas, configuraciones robadas y, en dispositivos ya comprometidos, la posibilidad de capturar más credenciales en tránsito.
La posición de Fortinet ha sido consistente: no se trata de un fallo nuevo del producto, sino de higiene de credenciales. Contraseñas filtradas previamente, reutilizadas y nunca rotadas tras actualizaciones de firmware, junto con interfaces de gestión expuestas a internet y ausencia de MFA. El 18 de junio, CISA emitió una alerta instando a endurecer la configuración de dispositivos Fortinet: renombrar cuentas de administrador predeterminadas, implementar MFA, restringir el acceso administrativo desde internet y auditar logs en busca de actividad sospechosa.
Y aquí está el dato regional que explica por qué la conversación llegó al Caribe: los productos Fortinet tienen amplia adopción en el sector corporativo, gobierno y telecomunicaciones de América Latina. Reportes posteriores han señalado a telecomunicaciones entre los sectores con presencia relevante en los datos, aunque sin nombrar operadores concretos de forma verificable.
Lo importante para lo que sigue: FortiBleed es un problema de perímetro. Es una llave, no una casa. Tener la llave de una puerta no equivale a haber entrado, ni a haberse llevado lo que hay dentro.
Qué se alega sobre Claro Dominicana
El 13 de septiembre de 2026, cuentas de inteligencia de amenazas y medios dominicanos reportaron una publicación en un foro. Un usuario identificado como "jarol1488″ afirmó haber vulnerado presuntamente los sistemas de Claro en República Dominicana y obtenido una base de datos que, según su publicación, contendría información vinculada a 2.889.256 clientes. De acuerdo con lo expuesto por el usuario, los registros presuntamente contienen números de identificación y teléfonos, información sobre suscripciones, identificadores de tarjetas SIM o ICCID, estado de las cuentas, categorías de planes, fechas de activación, ciclos de facturación y códigos internos utilizados por la empresa. También compartió muestras de los datos, que aparentan incluir identificadores asociados con líneas móviles, información de tarjetas SIM y detalles correspondientes a planes prepago.
El estado de verificación es el punto que más se pierde en la reproducción del tema. La afirmación no ha podido comprobarse de manera independiente. Tampoco existe confirmación de que las muestras difundidas sean auténticas o procedan de las plataformas de Claro Dominicana. Por esa razón, no puede establecerse que la compañía haya sufrido una vulneración ni que la cantidad de clientes mencionada corresponda con personas realmente afectadas. Hasta el momento no se ha localizado un pronunciamiento público de Claro ni de las autoridades dominicanas sobre la alegada filtración.
Un elemento de contexto sobre el actor, sin extrapolarlo: el mismo alias, "jarol1488″, apareció días antes en foros afirmando haber comprometido la infraestructura de una entidad del sector de seguridad pública y tecnología en República Dominicana, con más de 3,2 millones de registros de expedientes de denuncias y más de 2 millones de fotografías. Ese incidente también permanece sin confirmación independiente, aunque las muestras compartidas presentaban estructuras de datos coherentes con registros oficiales.
Eso dice dos cosas a la vez, y conviene sostener ambas: el actor tiene actividad reciente y enfocada en objetivos dominicanos, lo que le da cierta consistencia al claim; y al mismo tiempo, un patrón de reclamaciones no verificadas no es prueba de nada en particular.
Recuadro: qué se sabe / qué no se sabe
Qué se sabe
- Que existe una campaña real y documentada llamada FortiBleed, activa desde al menos febrero de 2026 y divulgada en junio, contra dispositivos Fortinet expuestos a internet.
- Que FortiBleed es una campaña de credenciales, no una vulnerabilidad nueva del producto.
- Que el 13 de septiembre de 2026 un actor de foro publicó un claim sobre Claro Dominicana, con una cifra concreta de registros y muestras.
- Que el tipo de campos descritos (cédula, teléfono, ICCID, plan, ciclo de facturación) es coherente con sistemas de gestión de clientes de un operador.
Qué no se sabe
- Si los datos son auténticos.
- Si, siendo auténticos, provienen de sistemas de Claro Dominicana o de un tercero de la cadena (distribuidor, integrador, proveedor, agregador).
- Si son datos actuales o un conjunto antiguo recompuesto y revendido.
- Cuál fue el vector de acceso, si lo hubo.
- Si algún dispositivo Fortinet de Claro RD figura en los datasets asociados a FortiBleed.
- Cuántas personas estarían realmente afectadas.
- Qué posición oficial tienen Claro Dominicana e INDOTEL, que al momento de escribir no se han pronunciado públicamente.
La relación Claro–Fortinet: lo que significa y lo que no
Claro Dominicana ha utilizado y comercializado soluciones de Fortinet, incluidos servicios administrados con FortiGate. Esto no es un secreto ni una acusación: es el modelo habitual de un operador grande, que además vende seguridad gestionada a sus clientes corporativos.
Pero esa relación comercial, por sí sola, no prueba nada sobre este caso. En América Latina, decir que una telco grande tiene equipos Fortinet es casi como decir que tiene routers Cisco o servidores Dell. La base instalada es tan amplia que la coincidencia pierde valor probatorio.
Para que la relación fuera relevante haría falta algo que hoy no existe públicamente: evidencia de que un dispositivo concreto de Claro RD aparece en los conjuntos de credenciales asociados a la campaña, y de que ese acceso se usó, y de que derivó en movimiento lateral hasta los sistemas donde vive la base de clientes.
Escenarios de conexión: probable, posible, improbable
Ninguno de los siguientes está confirmado. Son marcos de análisis, no conclusiones.
Escenario 1 — Sin relación directa con FortiBleed (a mi juicio, el más probable hoy)
La hipótesis más económica es que se trate de dos hechos independientes que coinciden en el tiempo y que la conversación pública ha unido. Las filtraciones de bases de clientes de operadores latinoamericanos han venido, históricamente, de vectores muy variados: aplicaciones web expuestas, APIs mal autenticadas, portales de distribuidores, credenciales de empleados obtenidas por infostealers, o acceso de terceros con permisos amplios.
A favor de este escenario: no hay ningún indicador público que vincule ambos hechos, y median casi tres meses entre la divulgación de FortiBleed y el claim. En contra: tres meses también es exactamente el tiempo que suele transcurrir entre un acceso inicial y una exfiltración monetizable, así que la distancia temporal no descarta nada.
Escenario 2 — Acceso por perímetro con Fortinet como puerta de entrada (posible, no demostrado)
Una hipótesis técnica plausible sería la siguiente cadena: dispositivo Fortinet expuesto a internet, con credenciales reutilizadas o no rotadas tras la divulgación de junio → acceso administrativo o de VPN al perímetro → reconocimiento interno → movimiento lateral hacia sistemas de CRM u OSS/BSS → exfiltración de la base de clientes.
Es plausible porque describe exactamente lo que los organismos de respuesta advirtieron como consecuencia posible de un acceso exitoso: monitorear tráfico, obtener credenciales adicionales y facilitar el acceso a recursos internos de la organización. Pero "plausible" no es "ocurrido". Para sostenerlo haría falta evidencia de cada eslabón, y hoy no hay ninguno público.
Escenario 3 — Datos reciclados o de un tercero (posible, y frecuentemente subestimado)
Buena parte de los datasets que circulan en foros son agregaciones: fragmentos de incidentes antiguos, bases de distribuidores, padrones cruzados con listados comerciales. Un conjunto puede ser real, contener datos verdaderos de personas reales, y aun así no proceder de una intrusión reciente en la empresa que se nombra en el título del post. Nombrar a la marca más grande del mercado le da valor comercial al anuncio.
Escenario 4 — Claim total o parcialmente falso (posible)
Ocurre. Muestras generadas o adaptadas, cifras infladas, o un volumen real mucho menor presentado como una base completa. La existencia de muestras públicas no resuelve esto: unas decenas de registros auténticos no demuestran que existan 2,8 millones detrás.
Escenario 5 — FortiBleed como causa directa y única (improbable como afirmación, en el estado actual)
No porque sea técnicamente imposible, sino porque afirmarlo requeriría evidencia que hoy no está disponible para nadie fuera de la empresa y sus forenses. Decir "Claro fue hackeada por FortiBleed" no es una conclusión: es un salto sobre tres o cuatro eslabones ausentes.
La distinción que conviene llevarse: perímetro no es base de datos
Vale la pena dejar esto explícito, porque es el nudo del asunto.
Una campaña de credenciales en firewalls afecta al borde de la red. Lo que se obtiene es acceso a un equipo que controla conexiones: puede permitir entrar a la red interna, ver tráfico, crear túneles. Es un punto de partida. Por sí solo no contiene los datos de tus facturas ni tu cédula.
Una filtración de CRM u OSS/BSS es otra cosa: son los sistemas donde vive la relación comercial con cada cliente. El CRM guarda quién eres, qué contrataste, cómo pagas. El OSS/BSS guarda cómo se aprovisiona y factura tu servicio: tu SIM, tu plan, tu ciclo. Ahí sí está la información que aparece descrita en el claim.
Ir del primero al segundo exige atravesar segmentación de red, autenticación adicional, controles de acceso y, en una operación madura, detección. Puede pasar, y pasa. Pero es un recorrido con varios pasos, cada uno de los cuales deja rastro. Esa es exactamente la evidencia que hoy falta.
Qué riesgos reales tendrías si la base fuera auténtica
Este apartado es condicional. Si se confirmara la autenticidad y el origen del conjunto, el perfil de riesgo para un cliente sería el siguiente.
El dato más sensible no es el teléfono, ni siquiera la cédula por separado. Es la combinación. Cédula + número + ICCID + plan + fecha de activación + ciclo de facturación describe a una persona con una precisión que ninguna estafa genérica alcanza.
- Ingeniería social con credibilidad prestada. Una llamada que empiece recitando tu cédula, tu plan exacto y tu fecha de corte se siente legítima. Ese es todo el trabajo que necesita hacer quien llama: que bajes la guardia.
- Riesgo de suplantación de SIM. Los procesos de reposición o portabilidad se apoyan en verificar identidad. Cuantos más datos verificables tenga un tercero, más fricción puede superar. Un cambio de SIM exitoso convierte tu número en la puerta de entrada a todo lo que use SMS como segundo factor: banca, correo, redes.
- Phishing y smishing dirigidos. Mensajes que citan tu ciclo de facturación real, tu plan real y tu monto aproximado tienen tasas de éxito muy superiores a las campañas masivas.
- Fraude de servicio y contrataciones a tu nombre. Con identificadores suficientes, se pueden intentar altas, financiamientos de equipos o servicios asociados a tu identidad.
- Cruce con otras filtraciones. Un conjunto con cédulas se vuelve mucho más peligroso al combinarse con otros disponibles en el mercado clandestino. El riesgo agregado crece más rápido que el riesgo individual de cada base.
Nada de esto exige conocimientos técnicos por parte de quien te llama. Esa es la parte incómoda: el vector no es el hackeo, eres tú atendiendo el teléfono.
Qué correspondería hacer mientras no hay confirmación
Del lado de la empresa y del regulador, lo esperable en un caso así, y lo que la práctica internacional recomienda: adquirir las muestras públicas y verificar si los registros corresponden a clientes reales, preservar logs y evidencia forense antes de cualquier remediación que los sobrescriba, revisar accesos de administración y VPN en el perímetro —incluida la rotación de credenciales Fortinet si no se hizo tras junio—, auditar accesos de terceros y distribuidores a sistemas de clientes, y comunicar algo. Incluso un "estamos investigando" reduce más daño reputacional que el silencio, porque el vacío informativo lo llena el rumor.
Del lado del regulador, el papel natural sería requerir información formalmente y, si se confirma, determinar obligaciones de notificación a los afectados.
Del lado tuyo, que es donde hay acción inmediata posible, van las recomendaciones del cierre.
Cierre: la pregunta sigue abierta
Al cierre de este texto, las preguntas honestas son cuatro, y ninguna tiene respuesta pública:
¿Hubo acceso por el perímetro, con Fortinet como una posible vía? ¿Fue otro vector completamente distinto —una API, un portal, un tercero, un empleado comprometido por infostealer—? ¿Son datos reales pero reciclados de incidentes anteriores? ¿O es un claim inflado que no resistirá el primer análisis serio de las muestras?
La única forma de responderlas es evidencia forense: correlación de logs, análisis de las muestras contra registros reales, revisión de accesos en el período relevante. Eso lo puede hacer la empresa, o un tercero independiente con acceso, o el regulador si lo requiere. No lo puede hacer un hilo en redes sociales, por más rápido que circule.
Mientras tanto, la posición razonable no es el pánico ni el descarte. Es asumir que el riesgo de ingeniería social es real ya mismo, independientemente de si la filtración se confirma. Porque la estafa que usa tu cédula para sonar creíble funciona igual si el dato salió de esta base, de otra anterior, o de cualquier otro lugar.
Cinco cosas concretas que puedes hacer esta semana
- Cambia la clave de Mi Claro y de tu correo asociado. Usa una contraseña única para cada uno: si reutilizas la misma en varios servicios, una filtración ajena se convierte en tu problema. Un gestor de contraseñas te lo resuelve sin esfuerzo mental.
- No compartas códigos de verificación por SMS con nadie. Nunca. Ni con quien diga llamar de la operadora, ni del banco, ni de soporte técnico. Ninguna empresa legítima te pedirá leerle un código en voz alta. Esa regla, sola, bloquea la mayoría de los intentos de toma de cuenta.
- Vigila tu SIM. Si tu teléfono pierde señal de forma inexplicable y no vuelve tras reiniciar, no lo dejes para mañana: puede ser una reposición de SIM no autorizada. Llama de inmediato desde otra línea. Y si tu operador ofrece un bloqueo de portabilidad o una clave adicional para cambios de SIM, actívalo.
- Desconfía de llamadas que citen tus datos personales. Que alguien conozca tu cédula, tu plan o tu fecha de facturación ya no es prueba de que sea quien dice ser. Cuelga y llama tú al número oficial. Si es real, la gestión te esperará cinco minutos.
- Saca el SMS de donde puedas. Para banca, correo y redes, cambia el segundo factor de SMS a una app de autenticación o una llave física. Es el cambio que más reduce tu exposición al riesgo de suplantación de SIM, y toma menos de diez minutos por cuenta.
- Revisa tus estados de cuenta y servicios contratados durante las próximas semanas, y reporta cualquier alta o cargo que no reconozcas. La detección temprana marca la diferencia entre un susto y un problema.
— Explorando juntos la soberanía digital.
