Connor Moucka se Declara Culpado na Campanha de Roubo de Dados de Clientes da Snowflake

Connor Moucka se declarou culpado em um caso ligado a ataques contra pelo menos 165 clientes da Snowflake, segundo reportagens destacadas pela Techmeme. O caso canadense da techmeme liga um réu a uma campanha que expôs bilhões de registros sensíveis, incluindo dados associados à AT&T.

A confissão altera o cenário jurídico de uma das mais amplas campanhas de roubo de dados em nuvem de 2024. Ainda assim, ela não resolve a principal controvérsia de segurança revelada por esses ataques. A Snowflake afirmou que sua plataforma não foi violada, enquanto clientes dependiam de contas sem proteções de identidade suficientes.

Essa distinção é importante, mas oferece pouco consolo às organizações cujos dados foram roubados. Os ataques mostraram como credenciais válidas, autenticação fraca e dados concentrados na nuvem podem gerar consequências semelhantes às de uma violação em toda a plataforma.

O caso canadense da techmeme passa de alegações para admissão

A confissão de Moucka transforma uma parte importante do caso Snowflake de acusação em um processo criminal admitido.

Jonathan Greig, do The Record, informou que Moucka se declarou culpado de participar da campanha de hackers de 2024. A Techmeme destacou a reportagem em 5 de agosto de 2026. A reportagem disponível afirma que o cidadão canadense pode enfrentar décadas de prisão.

Moucka, também conhecido como Alexander Antonin Moucka, foi preso em Kitchener, Ontário, em 30 de outubro de 2024. Ele consentiu em se entregar para fins de extradição em março de 2025 e compareceu ao tribunal federal em Seattle em julho daquele ano.

Inicialmente, ele se declarou inocente de todas as acusações. A página do caso Moucka do Departamento de Justiça, atualizada pela última vez antes da confissão noticiada, listava uma data de julgamento para 19 de outubro de 2026.

O processo federal também nomeia John Erin Binns, que não estava sob custódia dos Estados Unidos quando o Departamento de Justiça atualizou sua página pela última vez. Os promotores acusaram os réus de fraude eletrônica, fraude informática, roubo de identidade agravado, crimes relacionados à extorsão e conspirações associadas.

A acusação original descreveu invasões em pelo menos 10 organizações vítimas. Ela alegava que os réus e seus associados acessaram bilhões de registros, exigiram resgates e anunciaram informações roubadas em fóruns de cibercrime.

Esses registros supostamente incluíam históricos de chamadas e mensagens de texto, informações bancárias, registros de folha de pagamento, números de passaporte e números da Previdência Social. Os promotores também alegaram que o grupo obteve milhões em pagamentos de extorsão.

O número de 165 organizações vem da investigação mais ampla sobre a ameaça, não da contagem de vítimas especificamente acusadas no processo. A Mandiant e a Snowflake afirmaram ter notificado aproximadamente 165 organizações cujos ambientes Snowflake poderiam ter sido expostos.

Essa distinção é importante. Um processo criminal normalmente apresenta incidentes selecionados necessários para provar acusações específicas. Uma investigação sobre ameaças pode descrever uma campanha mais ampla, incluindo incidentes que nunca aparecem como acusações criminais separadas.

A confissão noticiada não estabelece automaticamente todas as alegações públicas sobre as 165 organizações. Ela estabelece responsabilidade criminal dentro do escopo aceito pelo tribunal e pelo acordo de confissão. Os fatos exatos admitidos, as acusações descartadas, a exposição à pena e os termos de restituição dependem dos documentos protocolados no processo.

Ainda assim, a mudança é substancial. A defesa de Moucka já não parece caminhar para o julgamento agendado. A atenção agora se volta às admissões factuais e à forma como o tribunal avaliará a escala da campanha.

O caso também oferece às equipes de segurança algo mais concreto do que o rótulo de um cluster anônimo de ameaças. Uma campanha antes discutida principalmente por meio de relatórios de incidentes agora tem um réu que, segundo as reportagens, aceita responsabilidade.

Esse desdobramento jurídico torna mais aguda a questão maior. Quem era responsável por impedir que uma senha válida, mas roubada, abrisse um repositório repleto de dados corporativos sensíveis?

Um caminho simples de login causou danos extraordinários

A campanha não exigiu uma vulnerabilidade de software da Snowflake recém-descoberta, segundo as investigações publicadas após os ataques.

A Mandiant rastreou a atividade como UNC5537, um rótulo para um cluster de ameaças com motivação financeira. Seus investigadores afirmaram que os atacantes acessaram sistematicamente instâncias Snowflake de clientes usando credenciais roubadas.

Um infostealer é um malware projetado para coletar senhas, dados de navegador, informações de sessão e outras credenciais de um dispositivo infectado. Essas credenciais roubadas frequentemente são reunidas em logs e negociadas em mercados criminosos.

A Mandiant constatou que algumas credenciais usadas na campanha contra a Snowflake vieram de infecções por infostealer datadas de 2020. Em ambientes afetados, as senhas às vezes permaneceram válidas por anos após seu roubo.

Os investigadores identificaram três fragilidades recorrentes. As contas comprometidas não tinham autenticação multifator, as senhas não haviam sido rotacionadas e as listas de permissões de rede não restringiam os logins a locais confiáveis.

A Mandiant afirmou que pelo menos 79,7% das contas usadas pelos atacantes apresentavam evidências de exposição anterior de credenciais. Sua detalhada análise da UNC5537 atribuiu todos os incidentes que investigou a credenciais comprometidas de clientes.

A autenticação multifator, geralmente chamada de MFA, exige uma credencial adicional além da senha. Dependendo da implementação, esse segundo fator pode ser uma chave de segurança, passkey, código de autenticador ou dispositivo aprovado.

Sem MFA, um nome de usuário e uma senha funcionais podem bastar para personificar o usuário real. O serviço em nuvem vê uma autenticação bem-sucedida, a menos que outros controles detectem a origem ou o comportamento incomum.

Os atacantes teriam usado as interfaces comuns e os comandos de banco de dados compatíveis da Snowflake após fazer login. A Mandiant observou acessos pelo Snowsight, a interface de navegador da Snowflake, e pelo SnowSQL, seu cliente de linha de comando.

Os investigadores também observaram uma ferramenta de reconhecimento nomeada pelos atacantes e rastreada como FROSTBITE. A ferramenta consultava detalhes da conta, funções, usuários, nomes de organizações, sessões e outras informações que ajudavam os operadores a mapear ambientes acessíveis.

Depois que os atacantes localizavam tabelas úteis, podiam preparar os dados dentro da instância do cliente. SQL padrão e comandos da Snowflake permitiam selecionar registros, compactar arquivos exportados e recuperar esses arquivos.

Nada nesse fluxo de trabalho exigia que os atacantes quebrassem a criptografia ou derrotassem a infraestrutura de nuvem subjacente. Eles abusaram de permissões concedidas a contas cujas credenciais controlavam.

Esse ponto explica por que a campanha se tornou tão relevante. Os atacantes podiam usar o mesmo processo repetível contra diferentes organizações após obter outro conjunto de credenciais.

A centralização na nuvem ampliou os resultados. As empresas usam plataformas de dados para combinar registros de clientes, informações financeiras, dados operacionais e cargas de trabalho de análise. Portanto, uma conta comprometida pode fornecer acesso a informações reunidas de muitos sistemas empresariais.

O mecanismo técnico era comum o suficiente para passar despercebido. Não foi necessário nenhum exploit de dia zero. Um zero-day é uma falha de software previamente desconhecida para a qual os defensores ainda não implantaram uma correção.

Em vez disso, a campanha se integrou a uma cadeia madura de fornecimento criminosa. Infostealers coletavam credenciais, mercados clandestinos as distribuíam e operadores de extorsão convertiam o acesso em poder de negociação.

A Mandiant descreveu as técnicas como nem particularmente novas nem sofisticadas. Essa avaliação torna o incidente mais preocupante, não menos. Falhas básicas de identidade permitiram ataques com um impacto incomumente amplo.

A declaração de culpa não altera esse mecanismo. Ela confirma que a acusação pode alcançar um participante individual, enquanto o caminho de ataque reutilizável continua disponível para outros grupos.

O modelo de responsabilidade compartilhada da Snowflake encontra uma realidade incômoda

O conflito principal está entre responsabilidade contratual e controle operacional.

A Snowflake tem sustentado de forma consistente que os investigadores não encontraram evidências de uma violação, vulnerabilidade ou configuração incorreta em seu ambiente corporativo. Sua posição traça uma fronteira clara entre a plataforma e as contas individuais dos clientes.

A empresa reiterou esse ponto em uma declaração regulatória. Ela afirmou que agentes de ameaça acessaram algumas contas de clientes depois que esses clientes deixaram de implementar proteções como MFA e políticas de acesso à rede.

Essa explicação condiz com as conclusões forenses disponíveis. A Mandiant também não encontrou evidências de que o acesso não autorizado tenha resultado do comprometimento dos sistemas corporativos da Snowflake.

No entanto, os clientes contrataram um serviço gerenciado de nuvem, em parte, para reduzir os encargos de infraestrutura e segurança. Quando aproximadamente 165 organizações podem ser expostas por fragilidades semelhantes nas contas, a responsabilidade se torna mais complexa do que uma lista de verificação de configuração.

Um modelo de responsabilidade compartilhada divide os deveres de segurança entre um provedor de nuvem e seus clientes. O provedor protege o serviço, enquanto os clientes gerenciam identidades, permissões, dados e determinadas configurações.

Essa divisão é necessária. Um fornecedor de nuvem não pode decidir qual funcionário precisa de acesso a cada conjunto de dados de um cliente. Tampouco pode rotacionar com segurança todas as credenciais dos clientes sem entender os aplicativos que dependem delas.

Ainda assim, um provedor controla padrões, opções de autenticação, alertas, documentação, interfaces administrativas e a implementação de proteções obrigatórias. Essas escolhas influenciam fortemente se os clientes tomam decisões seguras.

Antes de a Snowflake alterar suas políticas, contas recém-criadas não tinham uma regra de autenticação integrada que exigisse que todos os usuários relevantes se inscrevessem no MFA. Os clientes podiam ativar as proteções, mas disponibilidade não garantia adoção.

Mais tarde, a Snowflake introduziu uma política padrão que exige inscrição no MFA para usuários qualificados que usam senha em novas contas. Sua documentação de MFA registra a situação anterior e a mudança subsequente.

A empresa continuou avançando em direção a uma autenticação mais forte. Seus planos atuais preveem descontinuar o acesso por senha de fator único para usuários humanos e eliminar a autenticação por senha para usuários de serviço.

Essas medidas representam uma importante decisão de produto. Alguns controles são importantes demais para permanecerem opcionais, especialmente quando um serviço concentra dados sensíveis de milhares de empresas.

A inversão é sutil. A posição da Snowflake de que os clientes deixaram de usar controles disponíveis pode estar factualmente correta. Sua decisão posterior de impor padrões mais fortes também sugere que a mera disponibilidade não administrava o risco de forma adequada.

Isso não torna a Snowflake responsável por malware instalado no computador pessoal de um prestador de serviços. Tampouco elimina o dever do cliente de rotacionar senhas vazadas e monitorar contas privilegiadas.

Isso mostra que os resultados de segurança na nuvem surgem dos dois lados da fronteira do serviço. Um cliente escolhe usuários e permissões, mas o provedor projeta o caminho de menor resistência.

O acesso de prestadores de serviços ilustra o problema. A Mandiant encontrou casos em que infostealers comprometeram computadores de prestadores também usados para atividades pessoais, incluindo jogos ou downloads pirateados.

Um contratado pode trabalhar com várias organizações e ter permissões elevadas em cada ambiente. Portanto, um único dispositivo infectado pode expor credenciais vinculadas a várias contas corporativas.

As equipes de segurança não podem presumir que toda identidade se origina de um notebook corporativo gerenciado. Elas precisam de controles que permaneçam eficazes quando um endpoint fica fora de sua supervisão direta.

Os provedores enfrentam a mesma realidade em outra escala. Os sistemas de autenticação devem esperar que senhas vazem, usuários reutilizem credenciais e alguns clientes adiem salvaguardas opcionais.

O caso canadense da techmeme, portanto, desafia uma interpretação restrita de responsabilidade compartilhada. Atribuir uma obrigação não garante que milhares de clientes a cumprirão de forma consistente.

Um modelo mais seguro combina a responsabilização do cliente com requisitos mínimos impostos pelo provedor. Ele também torna as exceções visíveis, limitadas no tempo e difíceis de criar acidentalmente.

AT&T mostra por que a segurança de contas na nuvem é segurança empresarial

O incidente da AT&T transformou uma conta na nuvem comprometida em um evento de privacidade que afetou quase toda uma base nacional de clientes de telefonia móvel.

A AT&T divulgou em julho de 2024 que agentes de ameaça haviam baixado ilegalmente registros de uma plataforma de nuvem de terceiros. O conjunto de dados abrangia chamadas e mensagens de texto durante um período de seis meses em 2022, além de registros limitados de janeiro de 2023.

A empresa afirmou que os dados afetados incluíam os números de telefone envolvidos em chamadas ou mensagens de texto. Alguns registros também continham números de identificação de estações celulares associados às interações.

A AT&T afirmou que os registros baixados não incluíam o conteúdo de chamadas ou mensagens de texto. Eles também não continham números de Seguro Social, datas de nascimento ou outras informações pessoais, como nomes.

Essa limitação não tornava os registros inofensivos. Metadados de comunicações podem revelar relacionamentos, rotinas, contatos comerciais e padrões sensíveis, mesmo sem o conteúdo das mensagens.

A AT&T afirmou que os dados envolviam quase todos os seus clientes de telefonia móvel, clientes de operadoras móveis virtuais que usam sua rede e alguns clientes de telefonia fixa que interagiram com esses números.

O registro da empresa informou que ela soube, em 19 de abril de 2024, que um agente de ameaça alegava ter acessado e copiado registros de chamadas. A AT&T investigou o caso e trabalhou com as autoridades.

Não se tratava de um conjunto de dados marginal em um sistema experimental isolado. Eram informações derivadas das comunicações diárias da base de clientes de uma grande provedora de telecomunicações.

O incidente demonstra por que data warehouses na nuvem merecem a mesma atenção de segurança dedicada a sistemas de identidade em produção. Plataformas de dados frequentemente mantêm cópias extraídas de inúmeros aplicativos, mesmo quando não operam esses aplicativos diretamente.

Os atacantes entendem essa concentração. Em vez de invadir vários sistemas operacionais, eles podem visar o repositório analítico em que a organização já reuniu informações valiosas.

A campanha contra Snowflake teria afetado outras organizações conhecidas, incluindo a controladora da Ticketmaster, Live Nation, Santander, Advance Auto Parts, Neiman Marcus e LendingTree.

Vítimas diferentes expuseram dados diferentes porque suas instâncias Snowflake armazenavam cargas de trabalho distintas. O elemento repetível foi o comprometimento de identidade, não um único conjunto de dados padronizado.

Esse padrão pressiona tanto os compradores empresariais quanto a Snowflake. Avaliações de segurança frequentemente se concentram muito na criptografia, nas certificações, na disponibilidade e na gestão de vulnerabilidades de um fornecedor.

Esses controles importam, mas não respondem se todas as contas humanas usam autenticação resistente a phishing. Tampouco revelam se credenciais antigas de contratados permanecem ativas.

As equipes de compras devem perguntar como uma plataforma impede o acesso de fator único, distingue identidades humanas e de serviço e detecta logins provenientes de redes inesperadas. Elas devem examinar se exportações privilegiadas geram alertas imediatos.

Os responsáveis pelos dados também precisam mapear o que entra em uma plataforma analítica. Um data warehouse que acumula silenciosamente informações de passaporte, registros financeiros ou metadados de comunicações pode se tornar um alvo mais valioso do que sua classificação de risco original sugere.

Esse inventário deve incluir cópias e conjuntos de dados derivados. Remover um campo de um aplicativo operacional não protege uma exportação mais antiga mantida em outro lugar.

Um registro interno pesquisável pode ajudar as equipes a preservar decisões sobre acesso a dados e resposta a incidentes. Por exemplo, uma base de conhecimento de engenharia mantida pode conectar runbooks, registros de propriedade e conclusões anteriores de segurança.

A documentação não é, por si só, um controle de segurança. Ela se torna útil quando os responsáveis pela resposta conseguem identificar rapidamente proprietários, dependências, exceções de autenticação e a finalidade comercial de tabelas expostas.

O exemplo da AT&T também complica a expressão “incidente de terceiros”. Os clientes raramente se importam com qual parte operava a conta comprometida quando suas informações aparecem nas mãos de criminosos.

Reguladores, tribunais e indivíduos afetados examinam toda a cadeia. Essa cadeia inclui o proprietário dos dados, o provedor de nuvem, contratados, administradores de identidade e qualquer pessoa que tenha deixado uma conta desnecessária ativa.

Uma declaração de culpa não pode encerrar o debate sobre responsabilização em segurança

A responsabilização criminal e a responsabilização defensiva respondem a perguntas diferentes.

O processo contra Moucka pergunta se os réus identificados cometeram crimes federais específicos. O debate mais amplo sobre segurança pergunta quais organizações estavam em posição de prevenir ou limitar os ataques.

Uma declaração de culpa pode fornecer evidências sobre ferramentas, colaboradores, pagamentos e seleção de vítimas. Ela também pode embasar pedidos de restituição e ajudar investigadores a conectar atividades antes atribuídas apenas por indicadores técnicos.

Ela não pode estabelecer que todas as empresas afetadas tinham controles idênticos. Tampouco pode provar que uma política de um fornecedor teria impedido todos os incidentes na campanha mais ampla.

A cobertura pública também exige tratamento cuidadoso da escala. A Mandiant afirmou que aproximadamente 165 organizações foram potencialmente expostas e notificadas. A página do caso do Departamento de Justiça descreve supostos esquemas de invasão envolvendo pelo menos 10 organizações vítimas.

Esses números medem escopos diferentes. Apresentar todas as 165 como vítimas comprovadas na conduta admitida por Moucka iria além das evidências públicas disponíveis aqui.

Os termos exatos da declaração de culpa importam pelo mesmo motivo. Os leitores devem acompanhar o acordo de declaração de culpa protocolado e o registro judicial dos fatos admitidos, em vez de presumir que todas as acusações originais permaneceram intactas.

A sentença também permanece indefinida. Os máximos legais federais podem gerar grandes totais em manchetes, mas os juízes não simplesmente somam cada máximo e impõem o resultado.

O tribunal considera os crimes que resultaram em condenação, as diretrizes de sentença, o histórico criminal, as perdas das vítimas, a cooperação, a restituição e os argumentos de ambas as partes. Uma exposição noticiada de “décadas” descreve risco jurídico, não uma sentença final.

A resposta de segurança da Snowflake merece cautela semelhante. Requisitos mais rigorosos de MFA reduzem o risco de senhas roubadas, mas MFA não é uma defesa completa contra engenharia social moderna.

Pesquisadores de ameaças do Google relataram em 2026 que operações associadas à marca ShinyHunters expandiram suas táticas. Os atacantes usaram phishing por voz e sites de coleta de credenciais para obter credenciais de single sign-on e códigos de MFA.

Algumas operações persuadiram centrais de suporte ou usuários a aprovar ações maliciosas de inscrição. Outras capturaram tokens de sessão, o que pode permitir que um invasor opere após um evento de autenticação legítimo.

Essa evolução enfraquece qualquer afirmação de que MFA obrigatório resolve permanentemente o problema. No entanto, ela elimina a versão mais fácil do ataque, em que uma senha reutilizável fornece acesso direto.

As equipes de segurança precisam de autenticação resistente a phishing para funções sensíveis. Passkeys e chaves físicas de segurança vinculam a autenticação a sites legítimos de forma mais eficaz do que códigos que os usuários podem retransmitir.

Elas também precisam de controles após o login. Restrições de rede, análise comportamental, sessões de curta duração, monitoramento de exportações e permissões de menor privilégio reduzem os danos causados por uma identidade comprometida.

Contas de serviço exigem atenção separada. Essas identidades não humanas dão suporte a aplicativos e fluxos de trabalho automatizados, portanto MFA interativo normalmente não se adequa ao seu uso.

Alternativas mais robustas incluem autenticação por par de chaves, identidades de workload, permissões estritamente delimitadas e rotação automatizada de credenciais. As equipes devem impedir que credenciais de serviço se tornem chaves mestras permanentes.

A movimentação de dados merece monitoramento dedicado. Um usuário que de repente enumera muitas tabelas, cria estágios temporários, compacta grandes exportações e as recupera de um novo local cria uma sequência detectável.

As organizações devem testar se essas ações geram alertas úteis. Um recurso nominal de registro oferece pouca proteção se ninguém recebe o sinal ou sabe como investigá-lo.

Os provedores de nuvem podem reduzir a ambiguidade fornecendo detecções de alta confiança como padrão. Os clientes podem então ajustar essas detecções sem criar cada regra do zero.

A reportagem canadense da techmeme acrescenta um marco jurídico, mas a conclusão cética continua necessária. Prender e processar operadores individuais não desmantela a economia de credenciais que forneceu seu acesso.

Registros de infostealers continuam abundantes. Grupos criminosos podem comprar credenciais antigas por baixo custo, testá-las em escala e concentrar esforços nas contas que ainda funcionam.

Portanto, os defensores precisam tratar a exposição de senhas como um evento esperado. A questão relevante é se uma credencial roubada permanece útil tempo suficiente para causar dano material.

Três sinais mostrarão se as lições da Snowflake perduraram

A próxima fase deve ser medida por meio de registros judiciais, aplicação de autenticação e evidências de ataques repetidos à nuvem.

O primeiro sinal é o acordo escrito de declaração de culpa e o registro de sentença de Moucka. Esses documentos devem definir qual conduta ele admitiu, as vítimas abrangidas por essa admissão e qualquer cálculo de perda acordado.

Uma declaração factual detalhada fortaleceria a compreensão pública sobre como a campanha operava. Um acordo restrito exigiria cautela contínua ao conectar Moucka a cada incidente atribuído à UNC5537.

A sentença também mostrará como os promotores e o tribunal avaliam os danos produzidos por credenciais roubadas. As conclusões sobre restituição podem revelar custos que os avisos públicos de violação não capturaram.

O segundo sinal é a conclusão, pela Snowflake, de sua implementação mais rigorosa de autenticação. A medida mais significativa não é se recursos de MFA existem, mas se o acesso por senha de fator único realmente desaparece das contas humanas comuns.

As exceções merecem análise rigorosa. Ferramentas legadas de business intelligence, contas de leitor, ambientes de teste e integrações de serviço podem preservar caminhos mais fracos caso as organizações não concluam as migrações.

Compradores empresariais devem pedir aos fornecedores datas de aplicação e inventários de exceções. Eles também devem verificar essas respostas por meio de suas próprias configurações de conta.

Uma transição bem-sucedida enfraqueceria o caminho original do ataque. Exceções persistentes ou aplicação adiada mostrariam que as pressões por usabilidade e compatibilidade ainda superam o objetivo de segurança declarado.

O terceiro sinal é se os atacantes reproduzem a campanha contra outras plataformas de software como serviço. A Mandiant alertou em 2024 que a abordagem da UNC5537 poderia se estender além da Snowflake.

Seu relato posterior mostrou que a atividade de extorsão relacionada já havia evoluído para phishing por voz, comprometimento de single sign-on e roubo em vários aplicativos de nuvem.

Essa evolução reforçaria o julgamento central do artigo. A questão duradoura não é um fornecedor ou um réu, mas a lacuna entre dados centralizados na nuvem e a aplicação inconsistente de identidade.

Uma queda nos comprometimentos impulsionados por senhas mostraria que os controles obrigatórios estão funcionando. Violações contínuas por roubo de sessão ou manipulação do help desk deslocariam a atenção para identidades resistentes a phishing e detecção pós-login.

A história canadense do techmeme, portanto, não é apenas o capítulo final de um caso de hacking de 2024. É um teste para saber se os provedores de nuvem e os clientes mudaram as condições que tornaram a campanha repetível.

A confissão de culpa de Moucka, segundo relatos, oferece ao caso criminal uma resposta mais clara sobre a responsabilidade individual. A resposta no âmbito empresarial continua incompleta.

Líderes de segurança devem aproveitar o momento para verificar todas as contas privilegiadas, remover identidades inativas, restringir redes confiáveis e monitorar exportações em massa. Eles também devem perguntar aos fornecedores quais proteções são efetivamente impostas, em vez de apenas oferecidas.

A pergunta final é prática: se a senha de um funcionário ou contratado entrasse hoje à noite em um registro criminoso, qual controle a impediria amanhã de manhã?