Ir al contenido principal
Volver al archivo

Edición 17 · 28 de septiembre de 2026

Edition 17

El proceso de firma de Bitget autorizó una falsificación, Salesforce declaró bloqueo después de que los datos ya habían salido, un proveedor de MFA fraudulento sobrevive al restablecimiento de contraseña, Google no puede demostrar cumplimiento e ISO 9001 audita la cultura.

Por Christophe Mazzola, CISO en activo y fundador de Cyber Academy.

Recibe el próximo GRC Brief en tu correo.

Suscribirse a The GRC Brief

El proceso de firma de Bitget funcionó perfectamente. Firmó una falsificación.

El 24 de septiembre, el exchange de criptomonedas Bitget detectó 19 transferencias no autorizadas desde sus carteras calientes y templadas: aproximadamente 351,6 millones de dólares en ether, XRP y stablecoins distribuidos en siete cadenas. Las carteras frías no se vieron afectadas. El mecanismo es lo que debe llamar su atención. Según el propio equipo de seguridad del exchange, los atacantes vulneraron un sistema crítico de gestión de carteras en el backend, lo utilizaron para falsificar los detalles de las transferencias y, a continuación, activaron el proceso de firma autorizado habitual de Bitget para mover los fondos. La directora ejecutiva Gracy Chen descartó el compromiso de claves privadas. Por tanto, nada criptográfico falló. El control de firma hizo exactamente lo que se supone que debe hacer, siguiendo instrucciones que no tenía forma de cuestionar. La vía de entrada de los atacantes sigue bajo investigación. Bitget apunta a una infraestructura VPN vinculada previamente a actividad norcoreana, aunque esa atribución es preliminar y otros analistas la cuestionan. Los retiros están suspendidos y un fondo de protección de 464 millones de dólares cubre la pérdida.

Fuente: CNBC · Bitget breach, 25 Sep 2026

Mi análisis

Lea más allá de las criptomonedas, porque el patrón existe en su propia organización. Es un fallo de autorización. El control de firma protegía la clave, no la veracidad de la instrucción: se le pidió que autorizara una transferencia, confirmó que tenía permiso para hacerlo y firmó. Nadie verificó que la transferencia fuera legítima. Cambie cartera por proceso de pagos o por datos bancarios de un proveedor, y tendrá una estafa de compromiso de correo corporativo con mejor criptografía.

El control que realmente necesita está en la capa anterior, en la integridad de lo que llega al firmante. ¿De dónde proviene esta instrucción, coincide con una fuente aprobada, y el sistema que compone las transferencias recibe más escrutinio que el que las firma? Y mantenga la hipótesis norcoreana con cautela por ahora: es preliminar, el punto de entrada se desconoce, y Lazarus se ha convertido en una etiqueta para cualquier cosa vagamente asociada a la RPDC. El mecanismo es la lección, no la atribución.

Un proveedor de MFA fraudulento roba la contraseña y después sobrevive al restablecimiento.

Varonis Threat Labs publicó TrustSink, un abuso del modelo de autenticación externa demostrado contra Microsoft Entra. Entra permite delegar el segundo factor a un proveedor de MFA externo: el usuario introduce su contraseña, Entra redirige y, si el proveedor devuelve un token firmado válido, el requisito de MFA se considera satisfecho. Un atacante que ya controla una cuenta con privilegios en Entra puede registrar un proveedor fraudulento, que muestra una copia convincente de la página de contraseñas de Microsoft en el momento exacto en que el usuario espera el segundo paso. La contraseña llega al atacante en texto plano, el proveedor devuelve un token firmado válido y el inicio de sesión se completa sin ningún error. En el inquilino de prueba, cada inicio de sesión parecía normal mientras el servidor de los investigadores recopilaba contraseñas con marca de tiempo y direcciones IP de origen. Restablecer la contraseña no elimina el proveedor. Permanece en el flujo y captura la nueva contraseña.

Fuente: BleepingComputer · Varonis Threat Labs, 22 Sep 2026

Mi análisis

Segunda vez en dos meses que llega la misma lección: un restablecimiento de contraseña no desaloja a un atacante. En agosto fue un kit de phishing que registraba su propio passkey, y que sobrevivió al restablecimiento. Aquí el proveedor fraudulento sobrevive al restablecimiento y captura la contraseña de sustitución. El orden de las operaciones es, por tanto, un control en sí mismo. Elimine primero la persistencia: el proveedor, sus aplicaciones, claves y URIs de redirección; y rote las credenciales después. Al revés, habrá entregado la nueva contraseña.

Sea preciso sobre qué es esto, porque importa. Es post-compromiso, no acceso inicial: registrar un proveedor fraudulento requiere Global Administrator o Authentication Policy Administrator. El hallazgo upstream es el privilegio permanente, no el MFA roto. Y observe qué verificó Entra: una firma válida en un token que afirmaba que el segundo factor había ocurrido. Nunca que hubiera ocurrido realmente.

El agente dijo que los datos habían sido bloqueados. Ya habían sido enviados.

Zenity Labs encontró tres vulnerabilidades en Salesforce Agentforce, denominadas conjuntamente SalesBleed. El vector de entrada es Web-to-Lead, el formulario público de captación de clientes potenciales de Salesforce, que se alimenta directamente del CRM. Las instrucciones maliciosas enviadas a través de ese formulario permanecen inactivas hasta que un empleado solicita a un agente de Agentforce que trabaje con el registro; en ese momento, el agente las lee y las ejecuta. Dos de las vulnerabilidades permitían la exfiltración sin clic de datos de leads y cuentas mediante etiquetas de imagen HTML, eludiendo Trusted URLs, el mecanismo diseñado para impedir que el agente alcanzara dominios no aprobados, que no reconocía dominios de nivel superior. Zenity informa de que Agentforce indicó al usuario que el contenido había sido bloqueado por las políticas de seguridad de la organización, mientras los datos del CRM ya se encontraban en el servidor del atacante. La tercera vulnerabilidad permitía al agente publicar phishing en canales internos de Slack bajo su propia identidad. Notificado el 1 de junio, corregido el 19 de agosto.

Fuente: SecurityWeek · Zenity Labs, 25 Sep 2026

Mi análisis

Fije esa frase en la pared. El mecanismo de seguridad mostró un bloqueo de política después de que los datos ya habían salido. Recibió el mensaje tranquilizador y la brecha, del mismo control, en el mismo segundo. Si alguna vez necesitó una prueba de que un control que informa éxito no es lo mismo que un control que funciona, llegó esta semana con una captura de pantalla.

Dos aspectos que trasladar a su propio entorno. Primero: un formulario público de captación es entrada no confiable con camino directo a sus activos más críticos; por tanto, examine qué puede escribir en cualquier dato que sus agentes lean. Segundo: el agente no sabía quién lo estaba dirigiendo, de modo que firmó el phishing con su propio nombre de confianza. Esta es la versión concreta del consejo que di hace dos semanas: una identidad por agente y registros de lo que el agente realmente hizo, no de lo que se suponía que debía hacer.

Google multado con 403 millones de euros, en parte por no poder demostrar cumplimiento.

El 21 de septiembre, la Comisión de Protección de Datos de Irlanda multó a Google Ireland con 403 millones de euros y le ordenó adecuar su tratamiento a la normativa en un plazo de seis meses. La investigación, abierta en febrero de 2020 tras las reclamaciones de organizaciones europeas de consumidores, examinó los datos de ubicación en tres funciones: Actividad web y de aplicaciones, Historial de ubicación y Precisión de ubicación, entre mayo de 2018 y febrero de 2020. Las conclusiones: tratamiento ilícito e injusto en dos de ellas, falta de transparencia en las tres, conservación de datos de ubicación más allá de lo necesario y, en el caso de Precisión de ubicación, incapacidad para demostrar cumplimiento de los principios de licitud, lealtad y transparencia. El subcomisario Graham Doyle señaló que los datos de ubicación pueden revelar información inherentemente privada, que los usuarios posiblemente ignoraban que se utilizaban para dirigirles publicidad o inferir sus intereses, y que la conservación prolongada agravó esa pérdida de control.

Fuente: Data Protection Commission · DPC decision, 21 Sep 2026

Mi análisis

Examine los fundamentos. Sin brecha, sin ataque, sin vulneración técnica. Licitud, equidad, transparencia, conservación e incapacidad de demostrar cumplimiento. Este último fundamento es el artículo 5(2), y es el mismo hilo que recorre todo lo anterior: ser conforme y poder evidenciarlo no son dos mitades opcionales. Si no puede mostrar su trabajo, el regulador lo trata como no hecho. La retención fue calificada como factor agravante; es la tercera vez este año que escribo sobre datos que sobreviven a su finalidad.

Preste atención al orden, no a la cifra. Lo mismo dije sobre la multa por la DMA en julio: para Alphabet el dinero es una partida contable; la medida correctora conductual es el instrumento real, y Google tiene ahora seis meses para cambiar cómo trata los datos de ubicación. Tenga en cuenta también el reloj. Abierto en febrero de 2020, resuelto en septiembre de 2026: seis años y medio, que es el tiempo transcurrido desde los hechos durante el que se le puede pedir que justifique decisiones tomadas por personas que ya no están en la organización.

ISO 9001:2026 hace auditable la cultura de calidad. No se puede escribir un procedimiento para eso.

ISO publicó la sexta edición de ISO 9001 el 16 de septiembre, cancelando la versión de 2015 e incorporando la enmienda climática de 2024. Diez cláusulas, mismo orden, la mayor parte del texto familiar, que es exactamente la trampa. Cuatro aspectos cambiaron. La alta dirección debe ahora promover la cultura de calidad y el comportamiento ético, y las personas que trabajan bajo su control deben ser conscientes de ello, lo que convierte la cultura en un tema de auditoría evaluado mediante entrevistas. Los riesgos y oportunidades se dividen en cláusulas separadas, cada una con el requisito de determinar, analizar y evaluar, y se vuelven a evaluar de forma independiente en la revisión por la dirección. La gestión del cambio pasa de cuatro consideraciones a siete, añadiendo la comunicación de los cambios, el seguimiento de su eficacia y la revisión de los resultados. Y gran parte del lenguaje sobre información documentada pasa de mantener y conservar a «deberá estar disponible». La transición finaliza el 30 de septiembre de 2029, fecha en que expiran los certificados de la versión 2015.

Fuente: My full breakdown · cyberacademy.net

Mi análisis

Una cultura no es un procedimiento. No se puede redactar, aprobar y archivar, y un auditor no la evaluará leyendo su página de política. La evaluará preguntando a sus personas cómo se notifican los defectos y si alguien duda antes de comunicar malas noticias. Su defensa es la evidencia de lo que la dirección hace realmente: actas del consejo, decisiones en las que la calidad prevaleció sobre el calendario, qué ocurrió con la última persona que escaló un problema. Recójalas ahora, porque no podrá reconstruirlas después.

Dos notas prácticas. El Anexo A.6.1.2 indica que el pensamiento basado en riesgos no implica un enfoque formal de gestión del riesgo ni un proceso documentado; por tanto, si un consultor le dice que la nueva versión le obliga a tener un registro de riesgos, le está vendiendo algo. Y no confíe en el margen de tres años. La mayoría de las organizaciones realizan la transición durante una auditoría de seguimiento o de recertificación programada, y esas fechas las asigna el organismo de certificación, no usted. Si cuenta hacia atrás desde su propio ciclo, generalmente encontrará una única ventana realista. La lectura completa cláusula por cláusula está enlazada más arriba.

¿Te gustó esta? Recibe la próxima.

Aterriza en la próxima.

Cinco cosas que se movieron en GRC, todos los lunes. Análisis honesto, sin reciclar notas de prensa.

Suscribirse a The GRC Brief