Connor Moucka se declara culpable en la campaña de robo de datos de clientes de Snowflake

Connor Moucka se ha declarado culpable en un caso vinculado a ataques contra al menos 165 clientes de Snowflake, según informaciones destacadas por Techmeme. El caso canadiense de Snowflake citado por Techmeme vincula a un acusado con una campaña que expuso miles de millones de registros sensibles, incluidos datos asociados con AT&T.

La declaración de culpabilidad cambia la situación jurídica en torno a una de las campañas de robo de datos en la nube más extensas de 2024. Sin embargo, no resuelve la principal controversia de seguridad expuesta por esos ataques. Snowflake afirmó que su plataforma no fue vulnerada, mientras los clientes dependían de cuentas sin suficientes protecciones de identidad.

Esa distinción importa, pero ofrece poco consuelo a las organizaciones cuyos datos fueron robados. Los ataques demostraron cómo las credenciales válidas, una autenticación débil y los datos concentrados en la nube pueden generar consecuencias similares a las de una vulneración de toda la plataforma.

El caso canadiense destacado por Techmeme pasa de las acusaciones a la admisión de culpabilidad

La declaración de Moucka transforma una parte importante del caso Snowflake, de una acusación, en un asunto penal admitido.

Jonathan Greig, de The Record, informó que Moucka se declaró culpable de participar en la campaña de hackeo de 2024. Techmeme destacó ese informe el 5 de agosto de 2026. La información disponible indica que el ciudadano canadiense se enfrenta a décadas de prisión.

Moucka, también conocido como Alexander Antonin Moucka, fue detenido en Kitchener, Ontario, el 30 de octubre de 2024. En marzo de 2025 aceptó entregarse con fines de extradición y compareció ante un tribunal federal de Seattle en julio de ese año.

Inicialmente se declaró no culpable de todos los cargos. La página pública del Departamento de Justicia sobre el caso Moucka, actualizada por última vez antes de la declaración de culpabilidad informada, fijaba el inicio del juicio para el 19 de octubre de 2026.

El caso federal también nombra a John Erin Binns, quien no estaba bajo custodia de Estados Unidos cuando el Departamento de Justicia actualizó por última vez su página. Los fiscales acusaron a los imputados de fraude electrónico, fraude informático, robo de identidad agravado, delitos relacionados con extorsión y conspiraciones asociadas.

La acusación original describía intrusiones en al menos 10 organizaciones víctimas. Alegaba que los acusados y sus asociados accedieron a miles de millones de registros, exigieron rescates y anunciaron información robada en foros de ciberdelincuencia.

Esos registros presuntamente incluían historiales de llamadas y mensajes de texto, información bancaria, registros de nóminas, números de pasaporte y números de la Seguridad Social. Los fiscales también alegaron que el grupo obtuvo millones en pagos de extorsión.

La cifra de 165 organizaciones procede de la investigación de amenazas más amplia, no del número de víctimas específicamente imputadas. Mandiant y Snowflake indicaron que notificaron a aproximadamente 165 organizaciones cuyos entornos de Snowflake podrían haber estado expuestos.

Esa distinción es importante. Un caso penal suele presentar incidentes seleccionados necesarios para demostrar cargos concretos. Una investigación de amenazas puede describir una campaña más amplia, incluidos incidentes que nunca aparecen como cargos penales independientes.

La declaración de culpabilidad informada no establece automáticamente todas las afirmaciones públicas sobre las 165 organizaciones. Establece responsabilidad penal dentro del alcance aceptado por el tribunal y el acuerdo de culpabilidad. Los hechos concretos admitidos, los cargos desestimados, la posible condena y los términos de restitución dependen de los documentos presentados en el caso.

Aun así, el cambio es considerable. La defensa de Moucka ya no parece encaminada al juicio programado. La atención se centra ahora en las admisiones fácticas y en cómo el tribunal evaluará la escala de la campaña.

El caso también ofrece a los equipos de seguridad algo más concreto que la etiqueta de un grupo de amenazas anónimo. Una campaña antes analizada principalmente a través de informes de incidentes ahora cuenta con un acusado que, según se informa, acepta su responsabilidad.

Este avance jurídico agudiza la cuestión más amplia. ¿Quién era responsable de impedir que una contraseña válida pero robada desbloqueara un repositorio lleno de datos corporativos sensibles?

Una sencilla vía de inicio de sesión causó daños extraordinarios

La campaña no requirió una vulnerabilidad de software de Snowflake recién descubierta, según las investigaciones publicadas después de los ataques.

Mandiant rastreó la actividad como UNC5537, una etiqueta para un grupo de amenazas con motivación financiera. Sus investigadores indicaron que los atacantes accedieron sistemáticamente a instancias de Snowflake de clientes mediante credenciales robadas.

Un infostealer es un malware diseñado para recopilar contraseñas, datos del navegador, información de sesión y otras credenciales de un dispositivo infectado. Estas credenciales robadas suelen agruparse en registros y comercializarse en mercados criminales.

Mandiant descubrió que algunas credenciales utilizadas en la campaña contra Snowflake procedían de infecciones de infostealer que se remontaban a 2020. En los entornos afectados, las contraseñas a veces habían seguido siendo válidas durante años después de su robo.

Los investigadores identificaron tres debilidades recurrentes. Las cuentas comprometidas no tenían autenticación multifactor, las contraseñas no se habían rotado y las listas de permitidos de red no restringían los inicios de sesión a ubicaciones de confianza.

Mandiant indicó que al menos el 79,7 por ciento de las cuentas utilizadas por los atacantes mostraban indicios de exposición previa de credenciales. Su detallado análisis de UNC5537 atribuyó cada incidente que gestionó a credenciales de clientes comprometidas.

La autenticación multifactor, conocida habitualmente como MFA, exige una credencial adicional además de una contraseña. Dependiendo de la implementación, ese segundo factor puede ser una llave de seguridad, una passkey, un código de autenticación o un dispositivo aprobado.

Sin MFA, un nombre de usuario y una contraseña funcionales pueden bastar para suplantar al usuario real. El servicio en la nube detecta una autenticación correcta, salvo que otros controles identifiquen el origen o el comportamiento inusual.

Según los informes, los atacantes utilizaron las interfaces habituales de Snowflake y comandos de base de datos compatibles después de iniciar sesión. Mandiant observó accesos mediante Snowsight, la interfaz de navegador de Snowflake, y SnowSQL, su cliente de línea de comandos.

Los investigadores también observaron una utilidad de reconocimiento con nombre elegido por los atacantes, rastreada como FROSTBITE. La herramienta consultaba detalles de las cuentas, roles, usuarios, nombres de organizaciones, sesiones y otra información que ayudaba a los operadores a mapear los entornos accesibles.

Una vez que los atacantes localizaban tablas útiles, podían preparar los datos dentro de la instancia del cliente. Los comandos estándar de SQL y Snowflake les permitían seleccionar registros, comprimir archivos exportados y recuperar esos archivos.

Nada en ese flujo de trabajo requería que los atacantes rompieran el cifrado o derrotaran la infraestructura subyacente de la nube. Abusaron de los permisos otorgados a cuentas cuyas credenciales controlaban.

Ese punto explica por qué la campaña adquirió tanta relevancia. Los atacantes podían aplicar el mismo proceso repetible contra distintas organizaciones después de obtener otro conjunto de credenciales.

La centralización en la nube amplificó los resultados. Las empresas utilizan plataformas de datos para combinar registros de clientes, información financiera, datos operativos y cargas de trabajo analíticas. Por tanto, una cuenta comprometida puede proporcionar acceso a información recopilada desde numerosos sistemas empresariales.

El mecanismo técnico era lo bastante común como para pasar inadvertido. No fue necesario ningún exploit de día cero. Un día cero es una falla de software desconocida previamente para la cual los defensores aún no han implementado una corrección.

En su lugar, la campaña se integró en una cadena de suministro criminal consolidada. Los infostealers recopilaron credenciales, los mercados clandestinos las distribuyeron y los operadores de extorsión convirtieron el acceso en capacidad de presión.

Mandiant describió las técnicas como ni especialmente novedosas ni sofisticadas. Esa evaluación hace que el incidente sea más preocupante, no menos. Fallos básicos de identidad permitieron ataques con un impacto inusualmente amplio.

La declaración de culpabilidad no cambia ese mecanismo. Confirma que la acusación puede alcanzar a un participante individual, mientras la vía de ataque reutilizable sigue disponible para otros grupos.

El modelo de responsabilidad compartida de Snowflake se enfrenta a una realidad incómoda

El conflicto principal se sitúa entre la responsabilidad contractual y el control operativo.

Snowflake ha sostenido de forma constante que los investigadores no encontraron evidencia de una vulneración, una vulnerabilidad o una configuración errónea en su entorno empresarial. Su postura establece una frontera clara entre la plataforma y las cuentas individuales de los clientes.

La empresa reiteró ese punto en una presentación regulatoria. Afirmó que actores de amenazas accedieron a algunas cuentas de clientes después de que estos no implementaran salvaguardas como MFA y políticas de acceso a la red.

Esa explicación encaja con los hallazgos forenses disponibles. Mandiant tampoco encontró evidencia de que el acceso no autorizado procediera de un compromiso de los sistemas corporativos de Snowflake.

Sin embargo, los clientes adquirieron un servicio de nube gestionada, en parte para reducir las cargas de infraestructura y seguridad. Cuando aproximadamente 165 organizaciones pueden quedar expuestas por debilidades similares en las cuentas, la responsabilidad se vuelve más compleja que una lista de verificación de configuración.

Un modelo de responsabilidad compartida divide las obligaciones de seguridad entre un proveedor de nube y sus clientes. El proveedor protege el servicio, mientras los clientes gestionan identidades, permisos, datos y determinadas configuraciones.

Esta división es necesaria. Un proveedor de nube no puede decidir qué empleado necesita acceso a cada conjunto de datos de un cliente. Tampoco puede rotar de forma segura todas las credenciales de los clientes sin comprender las aplicaciones que dependen de ellas.

Sin embargo, un proveedor controla los valores predeterminados, las opciones de autenticación, las alertas, la documentación, las interfaces administrativas y el despliegue de protecciones obligatorias. Estas decisiones influyen de forma considerable en si los clientes toman decisiones seguras.

Antes de que Snowflake cambiara sus políticas, las cuentas recién creadas no contaban con una regla de autenticación integrada que exigiera a todos los usuarios pertinentes inscribirse en MFA. Los clientes podían habilitar protecciones, pero su disponibilidad no garantizaba su adopción.

Snowflake introdujo posteriormente una política predeterminada que exige la inscripción en MFA para usuarios de contraseña que cumplan los requisitos en cuentas nuevas. Su documentación sobre MFA registra el estado anterior y el cambio posterior.

La empresa ha seguido avanzando hacia una autenticación más sólida. Sus planes actuales contemplan dejar de admitir el acceso con contraseña de un solo factor para usuarios humanos y eliminar la autenticación por contraseña para usuarios de servicio.

Estas medidas representan una importante decisión de producto. Algunos controles son demasiado importantes para seguir siendo opcionales, especialmente cuando un servicio concentra datos sensibles de miles de empresas.

El cambio de postura es sutil. La afirmación de Snowflake de que los clientes no utilizaron los controles disponibles puede ser correcta desde el punto de vista factual. Su posterior decisión de imponer valores predeterminados más sólidos también sugiere que la mera disponibilidad no gestionaba adecuadamente el riesgo.

Esto no convierte a Snowflake en responsable del malware instalado en el ordenador personal de un contratista. Tampoco elimina el deber de un cliente de rotar contraseñas filtradas y supervisar cuentas privilegiadas.

Demuestra que los resultados de seguridad en la nube surgen de ambos lados del límite del servicio. Un cliente elige a los usuarios y los permisos, pero el proveedor diseña el camino de menor resistencia.

El acceso de contratistas ilustra el problema. Mandiant encontró casos en los que los infostealers comprometieron ordenadores de contratistas que también se usaban para actividades personales, incluidos videojuegos o descargas pirateadas.

Un contratista puede trabajar con varias organizaciones y tener permisos elevados en cada entorno. Por lo tanto, un solo dispositivo infectado puede exponer credenciales vinculadas a múltiples cuentas corporativas.

Los equipos de seguridad no pueden asumir que todas las identidades se originan en un portátil de empleado gestionado. Necesitan controles que sigan siendo eficaces cuando un endpoint queda fuera de su supervisión directa.

Los proveedores afrontan la misma realidad a otra escala. Los sistemas de autenticación deben prever que las contraseñas se filtrarán, que los usuarios reutilizarán credenciales y que algunos clientes pospondrán protecciones opcionales.

Por tanto, el caso canadiense de techmeme cuestiona una interpretación limitada de la responsabilidad compartida. Asignar una obligación no garantiza que miles de clientes la cumplan de manera consistente.

Un modelo más seguro combina la responsabilidad del cliente con mínimos exigidos por el proveedor. También hace que las excepciones sean visibles, limitadas en el tiempo y difíciles de crear por accidente.

AT&T demuestra por qué la seguridad de las cuentas cloud es seguridad empresarial

El incidente de AT&T convirtió una cuenta cloud comprometida en un evento de privacidad que afectó a casi toda una base nacional de clientes inalámbricos.

AT&T reveló en julio de 2024 que actores de amenazas habían descargado ilegalmente registros desde una plataforma cloud de terceros. El conjunto de datos abarcaba llamadas y mensajes de texto durante un periodo de seis meses en 2022, además de registros limitados de enero de 2023.

La empresa afirmó que los datos afectados incluían los números de teléfono involucrados en llamadas o mensajes de texto. Algunos registros también contenían números de identificación de estaciones celulares asociados a las interacciones.

AT&T afirmó que los registros descargados no incluían el contenido de las llamadas ni de los mensajes de texto. Tampoco contenían números de la Seguridad Social, fechas de nacimiento u otra información personal, como nombres.

Esa limitación no hacía que los registros fueran inocuos. Los metadatos de comunicaciones pueden revelar relaciones, rutinas, contactos empresariales y patrones sensibles incluso sin el contenido de los mensajes.

AT&T afirmó que los datos involucraban a casi todos sus clientes inalámbricos, a clientes de operadores móviles virtuales que utilizan su red y a algunos clientes de líneas fijas que interactuaron con esos números.

La presentación de la empresa indicó que el 19 de abril de 2024 se enteró de que un actor de amenazas afirmaba haber accedido y copiado registros de llamadas. AT&T investigó y colaboró con las fuerzas del orden.

No se trataba de un conjunto de datos marginal en un sistema experimental aislado. Era información derivada de las comunicaciones diarias de la base de clientes de un importante proveedor de telecomunicaciones.

El incidente demuestra por qué los almacenes de datos cloud merecen la misma atención de seguridad que los sistemas de identidad de producción. Las plataformas de datos suelen contener copias procedentes de numerosas aplicaciones, incluso cuando no operan directamente esas aplicaciones.

Los atacantes comprenden esa concentración. En lugar de penetrar varios sistemas operativos, pueden apuntar al repositorio analítico donde la organización ya ha combinado información valiosa.

Según los informes, la campaña contra Snowflake también afectó a otras organizaciones reconocidas, entre ellas Live Nation, matriz de Ticketmaster, Santander, Advance Auto Parts, Neiman Marcus y LendingTree.

Las distintas víctimas expusieron datos diferentes porque sus instancias de Snowflake contenían cargas de trabajo distintas. El elemento repetible fue el compromiso de identidades, no un único conjunto de datos estandarizado.

Ese patrón presiona tanto a los compradores empresariales como a Snowflake. Las revisiones de seguridad suelen centrarse en gran medida en el cifrado, las certificaciones, la disponibilidad y la gestión de vulnerabilidades de un proveedor.

Esos controles importan, pero no responden a si cada cuenta humana utiliza autenticación resistente al phishing. Tampoco revelan si antiguas credenciales de contratistas siguen activas.

Los equipos de compras deberían preguntar cómo una plataforma evita el acceso con un solo factor, distingue entre identidades humanas y de servicio, y detecta inicios de sesión desde redes inesperadas. Deberían examinar si las exportaciones con privilegios generan alertas inmediatas.

Los responsables de los datos también deben mapear qué ingresa en una plataforma analítica. Un almacén que acumula silenciosamente información de pasaportes, registros financieros o metadatos de comunicaciones puede convertirse en un objetivo de mayor valor de lo que su clasificación de riesgo original sugiere.

Ese inventario debe incluir copias y conjuntos de datos derivados. Eliminar un campo de una aplicación operativa no protege una exportación antigua conservada en otro lugar.

Un registro interno con capacidad de búsqueda puede ayudar a los equipos a preservar decisiones sobre acceso a datos y respuesta a incidentes. Por ejemplo, una base de conocimientos de ingeniería mantenida puede conectar manuales operativos, registros de propiedad y hallazgos de seguridad previos.

La documentación no es un control de seguridad por sí sola. Se vuelve útil cuando quienes responden pueden identificar rápidamente a los responsables, las dependencias, las excepciones de autenticación y el propósito empresarial de las tablas expuestas.

El ejemplo de AT&T también complica la expresión “incidente de terceros”. A los clientes rara vez les importa qué parte operaba la cuenta comprometida cuando su información aparece en manos criminales.

Los reguladores, los tribunales y las personas afectadas examinan toda la cadena. Esa cadena incluye al propietario de los datos, al proveedor cloud, a los contratistas, a los administradores de identidades y a cualquiera que haya dejado activa una cuenta innecesaria.

Una declaración de culpabilidad no puede resolver el debate sobre la responsabilidad en seguridad

La responsabilidad penal y la responsabilidad defensiva responden a preguntas distintas.

El proceso contra Moucka pregunta si los acusados identificados cometieron delitos federales específicos. El debate más amplio sobre seguridad pregunta qué organizaciones estaban en posición de prevenir o limitar los ataques.

Una declaración de culpabilidad puede aportar pruebas sobre herramientas, colaboradores, pagos y selección de víctimas. También puede respaldar reclamaciones de restitución y ayudar a los investigadores a conectar actividades que antes solo se atribuían mediante indicadores técnicos.

No puede establecer que todas las empresas afectadas tuvieran controles idénticos. Tampoco puede demostrar que una política de un proveedor habría detenido todos los incidentes de la campaña más amplia.

Los informes públicos también exigen un tratamiento cuidadoso de la escala. Mandiant afirmó que aproximadamente 165 organizaciones fueron potencialmente expuestas y notificadas. La página del caso del Departamento de Justicia describe presuntos esquemas de hackeo que involucraban al menos a 10 organizaciones víctimas.

Esas cifras miden ámbitos diferentes. Presentar a las 165 como víctimas probadas en la conducta admitida por Moucka iría más allá de la evidencia pública disponible aquí.

Los términos exactos de la declaración de culpabilidad importan por la misma razón. Los lectores deberían seguir el acuerdo de declaración presentado y el registro del tribunal sobre los hechos admitidos, en lugar de asumir que todos los cargos originales se mantuvieron intactos.

La sentencia también sigue sin resolverse. Los máximos legales federales pueden producir grandes totales para los titulares, pero los jueces no simplemente suman cada máximo e imponen el resultado.

El tribunal considera los delitos objeto de condena, las directrices de sentencia, los antecedentes penales, las pérdidas de las víctimas, la cooperación, la restitución y los argumentos de ambas partes. Una exposición reportada de “décadas” describe el riesgo legal, no una sentencia definitiva.

La respuesta de seguridad de Snowflake merece una cautela similar. Requisitos de MFA más estrictos reducen el riesgo derivado de contraseñas robadas, pero MFA no es una defensa completa contra la ingeniería social moderna.

Investigadores de amenazas de Google informaron en 2026 que las operaciones identificadas con la marca ShinyHunters habían ampliado sus tácticas. Los atacantes utilizaron phishing por voz y sitios de captación de credenciales para obtener credenciales de inicio de sesión único y códigos MFA.

Algunas operaciones persuadieron a mesas de ayuda o usuarios para aprobar acciones maliciosas de inscripción. Otras capturaron tokens de sesión, lo que puede permitir que un atacante opere después de un evento de autenticación legítimo.

Esa evolución debilita cualquier afirmación de que el MFA obligatorio cierra el problema de forma permanente. Sin embargo, elimina la versión más fácil del ataque, en la que una contraseña reutilizable proporciona acceso directo.

Los equipos de seguridad necesitan autenticación resistente al phishing para los roles sensibles. Las passkeys y las llaves de seguridad de hardware vinculan la autenticación a sitios legítimos con mayor eficacia que los códigos que los usuarios pueden retransmitir.

También necesitan controles posteriores al inicio de sesión. Las restricciones de red, la analítica de comportamiento, las sesiones de corta duración, la supervisión de exportaciones y los permisos de mínimo privilegio reducen el daño derivado de una identidad comprometida.

Las cuentas de servicio requieren atención independiente. Estas identidades no humanas respaldan aplicaciones y flujos de trabajo automatizados, por lo que el MFA interactivo normalmente no se adapta a su uso.

Entre las alternativas más sólidas figuran la autenticación mediante pares de claves, las identidades de carga de trabajo, los permisos de alcance limitado y la rotación automatizada de credenciales. Los equipos deberían evitar que las credenciales de servicio se conviertan en llaves maestras permanentes.

El movimiento de datos merece una supervisión específica. Un usuario que de repente enumera muchas tablas, crea stages temporales, comprime grandes exportaciones y las recupera desde una ubicación nueva genera una secuencia detectable.

Las organizaciones deberían comprobar si esas acciones generan alertas útiles. Una función de registro nominal ofrece poca protección si nadie recibe la señal o sabe cómo investigarla.

Los proveedores cloud pueden reducir la ambigüedad proporcionando detecciones de alta confianza de forma predeterminada. Después, los clientes pueden ajustar esas detecciones sin diseñar cada regla desde cero.

El informe canadiense de techmeme añade un hito legal, pero la conclusión escéptica sigue siendo necesaria. Arrestar y procesar a operadores individuales no desmantela la economía de credenciales que les proporcionó acceso.

Los registros de infostealers siguen siendo abundantes. Los grupos criminales pueden comprar credenciales antiguas a bajo coste, probarlas a escala y concentrar sus esfuerzos en las cuentas que aún funcionan.

Por ello, los defensores deben tratar la exposición de contraseñas como un evento esperado. La pregunta relevante es si una credencial robada sigue siendo útil el tiempo suficiente para causar un daño material.

Tres señales mostrarán si las lecciones de Snowflake perduraron

La siguiente fase debería medirse mediante registros judiciales, aplicación de la autenticación y evidencia de ataques cloud repetidos.

La primera señal es el acuerdo escrito de declaración de culpabilidad de Moucka y el registro de la sentencia. Esos documentos deberían definir qué conducta admitió, las víctimas cubiertas por esa admisión y cualquier cálculo de pérdidas acordado.

Una declaración fáctica detallada reforzaría la comprensión pública de cómo operó la campaña. Un acuerdo limitado exigiría mantener la cautela al vincular a Moucka con cada incidente atribuido a UNC5537.

La sentencia también mostrará cómo los fiscales y el tribunal valoran el daño producido mediante credenciales robadas. Las determinaciones de restitución pueden revelar costes que los avisos públicos de brechas no captaron.

La segunda señal es la finalización por parte de Snowflake de su despliegue de autenticación más sólida. La medida más significativa no es si existen funciones de MFA, sino si el acceso con contraseña de un solo factor desaparece realmente de las cuentas humanas ordinarias.

Las excepciones merecen un escrutinio minucioso. Las herramientas heredadas de inteligencia empresarial, las cuentas de lector, los entornos de prueba y las integraciones de servicio pueden preservar vías más débiles si las organizaciones no completan las migraciones.

Los compradores empresariales deberían pedir a los proveedores fechas de aplicación e inventarios de excepciones. También deberían verificar esas respuestas mediante sus propias configuraciones de cuenta.

Una transición exitosa debilitaría la vía de ataque original. Las excepciones persistentes o una aplicación retrasada mostrarían que las presiones de usabilidad y compatibilidad siguen superando el objetivo de seguridad declarado.

La tercera señal es si los atacantes reproducen la campaña contra otras plataformas de software como servicio. Mandiant advirtió en 2024 que el enfoque de UNC5537 podría extenderse más allá de Snowflake.

Sus informes posteriores mostraron que la actividad de extorsión relacionada ya había evolucionado hacia el phishing por voz, el compromiso de inicio de sesión único y el robo desde múltiples aplicaciones cloud.

Esa evolución reforzaría el juicio central del artículo. El problema duradero no es un proveedor ni un acusado, sino la brecha entre los datos cloud centralizados y la aplicación inconsistente de identidades.

Una disminución de los incidentes comprometidos por contraseñas demostraría que los controles obligatorios están funcionando. La persistencia de brechas mediante el robo de sesiones o la manipulación del servicio de asistencia desplazaría la atención hacia la identidad resistente al phishing y la detección posterior al inicio de sesión.

Por tanto, la historia canadiense de techmeme no es simplemente el capítulo final de un caso de piratería informática de 2024. Es una prueba de si los proveedores de nube y sus clientes modificaron las condiciones que hicieron repetible la campaña.

La presunta declaración de culpabilidad de Moucka ofrece al caso penal una respuesta más clara sobre la responsabilidad individual. La respuesta empresarial sigue pendiente.

Los responsables de seguridad deberían aprovechar este momento para verificar todas las cuentas con privilegios, eliminar identidades inactivas, restringir las redes de confianza y supervisar las exportaciones masivas. También deberían preguntar a los proveedores qué protecciones se aplican obligatoriamente, en lugar de cuáles simplemente se ofrecen.

La pregunta final es práctica: si la contraseña de un empleado o contratista apareciera esta noche en un registro criminal, ¿qué control la detendría mañana por la mañana?