A $10 Cyber Threat Responsável pelas Maiores Violações de 2024

Você pode contar a história do estado atual dos ataques baseados em credenciais roubadas em três números:

As credenciais roubadas foram as #1 ação do atacante em 2023/24, e o vetor de violação para 80% dos ataques de aplicativos da web. (Fonte: Verizon).
Os orçamentos de segurança cibernética cresceram novamente em 2024, com as organizações gastando quase $1.100 por utilizador (Fonte: Forrester).
Credenciais roubadas em fóruns criminais custam tão pouco quanto $10 (Fonte: Verizon).

Algo não se soma. Então, o que se passa?

Neste artigo, abordaremos:

O que está contribuindo para o enorme aumento nos compromissos de conta ligados a créditos roubados e por que as abordagens existentes não estão funcionando.
O mundo da inteligência obscura em credenciais roubadas, e como cortar o ruído para encontrar os verdadeiros pontos positivos.
Recomendações para que as equipes de segurança impeçam os invasores de usar créditos roubados para obter a aquisição de contas.

Ataques baseados em credenciais roubadas estão aumentando#

Há evidências claras de que os ataques de identidade são agora a ameaça cibernética #1 enfrentada pelas organizações. Os ataques aos clientes Snowflake em 2024 constituíram colectivamente o maior evento de cibersegurança do ano em termos do número de organizações e indivíduos afectados (pelo menos, se excluirmos o CrowdStrike causando uma interrupção mundial em Julho) — certamente, foi o maior perpetrado por um grupo criminoso contra empresas comerciais. Ele foi apontado por alguns meios de comunicação como “uma das maiores violações de todos os tempos.”

Cerca de 165 organizações que usam o Snowflake (uma plataforma de armazenamento de dados e análise baseada em nuvem) foram alvo de credenciais roubadas colhidas de infecções por infostealers desde 2020. Essas contas afetadas também não tinham MFA, permitindo que os invasores fizessem login com um único fator comprometido.

O impacto foi enorme. Ao todo, 9 vítimas foram nomeadas publicamente após a violação, impactando centenas de milhões de dados confidenciais de pessoas. Pelo menos uma vítima pagou uma taxa de resgate não revelada.

Mas isto não foi único. Esses ataques estavam acontecendo constantemente ao longo de 2024.

A enorme violação da Change Healthcare, que culminou com o impacto de 100 milhões de clientes e uma demanda de resgate de $22 milhões, começou com credenciais roubadas da Citrix.
Os servidores do Confluence e a instância do Slack da Disney foram invadidos, resultando em enormes quantidades de dados comercialmente confidenciais e detalhes da infraestrutura de TI vazados, bem como mensagens de 10.000 canais do Slack.
A Microsoft sofreu uma violação significativa de seu ambiente do Office 365, com e-mails confidenciais vazados depois que um aplicativo OAuth de “teste” foi comprometido usando créditos roubados.
Finastra, Schneider Electric, Nidec, Foundation, ADT, HealthEquity, Park’N Fly, Roku, LA County Health Services e muitos mais sofreram violações de dados de gravidade variável como resultado de créditos roubados.

Os pesquisadores também estão entrando em ação. Em outubro, o locatário ServiceNow da Microsoft foi hackeado usando credenciais roubadas adquiridas on-line, acessando milhares de descrições e anexos de tickets de suporte e e-mails de funcionários 250k+.

Credenciais roubadas ainda são um problema? Realmente?

A chave para muitos dos ataques direcionados a identidades de força de trabalho e contas online é o uso de credenciais roubadas. E, infelizmente, um foco maior na adoção do MFA não resolveu o problema.

As lacunas do MFA permanecem abundantes. Pesquisa da Push Security mostra que quando uma senha é o único método de login para uma conta, essas contas não possuem MFA em 4 de 5 casos.
O número de credenciais violadas continua a crescer a um ritmo alarmante devido à prevalência de compromissos de infostealers. E as violações de dados tendem a gerar mais violações de dados à medida que as informações da conta são vazadas, criando um ciclo vicioso.
A mudança para aplicativos e serviços de terceiros para a maioria das principais operações de negócios, levando a mais contas, mais credenciais e dados de negócios mais valiosos na nuvem — todos os alvos de baixa pendência para invasores.

Portanto, há mais alvos para atacantes, mais credenciais para usar contra eles, e o MFA (em particular o MFA resistente a phishing) não está nem de longe tão presente quanto esperamos. Olhe para as violações que mencionamos anteriormente — muitas das vítimas são grandes empresas, com vastos orçamentos de segurança. Se eles não podem alcançar uma cobertura completa, então como alguém pode esperar?

A ascensão dos infostealers

O aumento do malware infostealer teve um impacto significativo no aumento dos ataques baseados em credenciais.

Embora o malware infostealer não seja exatamente novo, é uma preocupação crescente para muitas organizações de segurança. As ofertas comerciais de Malware como Serviço no submundo do crime estão sendo continuamente atualizadas para evitar controles de detecção, e os grupos de ameaças mais sofisticados, apoiados pelo Estado, são proficientes na criação de malware personalizado. É um jogo de gato e rato, e o grande número de credenciais comprometidas que remontam a infecções por infostealers é uma prova de seu sucesso.

Uma vez roubados, os dados de credenciais, como nomes de usuário, senhas e cookies de sessão, chegam a fóruns criminosos na clearweb e na darkweb. Infostealers populares ainda têm seus próprios canais Telegram dedicados para anunciar e vender dados roubados.

But the landscape in which they are deployed has evolved too. There’s a greater appetite for stolen credentials among cyber criminals, and ultimately the more apps that companies use (typically 200+ for the average organization), the more accounts they have connected to them, and the more credentials there are to steal. And because infostealers target all credentials saved on the victim’s device (not just those belonging to a single app/website as per phishing campaigns) they’re perfectly poised to smash and grab.

Modernos arranjos de trabalho abrem ainda mais a superfície de ataque. Tudo o que é preciso é que um usuário faça login em seu perfil pessoal do navegador em um dispositivo corporativo (ou o inverso) e seu dispositivo pessoal seja comprometido, para que as credenciais corporativas sejam roubadas. E porque os infostealers são empurrados através de canais pouco ortodoxos em comparação com os ataques mais tradicionais baseados em e-mail (como fóruns de jogos, anúncios no Facebook e descrições de vídeos do YouTube), não é surpresa que as vítimas inocentes estejam caindo em falta.

E com a reutilização de senhas incrivelmente comum (10% das contas têm uma senha violada, fraca ou reutilizada e nenhuma MFA), as credenciais roubadas de contas pessoais também podem ser usadas para acessar aplicativos corporativos. Basta um atacante com um pouco de paciência — ou a habilidade para automatizar o preenchimento de credenciais SaaS em escala.

O cenário moderno de ataque de identidade mudou (muito)

No passado, as equipes de segurança e TI eram mestres de seu próprio universo do Active Directory, possibilitando participar de exercícios de quebra de senha ou comparar listas de informações de ameaças com senhas em uso pelos funcionários.

Essa imagem mudou. As equipes de segurança agora enfrentam um emaranhado de SaaS gerenciado e não gerenciado, à medida que as operações comerciais críticas se movem on-line. Eles não têm visibilidade sobre a postura de identidade nesses aplicativos, e a grande maioria das organizações nem sequer tem um método plausível para identificar todas as suas contas e aplicativos em uso em toda a empresa.

Os caminhos de ataque SaaS deixam pouco espaço para erros

Os ataques de identidade são agora fundamentalmente diferentes. Ao contrário dos ataques tradicionais baseados em rede, os ataques direcionados a contas on-line seguem um caminho de ataque muito mais direto.

Os ataques tradicionais progridem por acesso à rede, movimento lateral, escalonamento de privilégios e outras atividades familiares. Esses tipos de ataques são bem compreendidos pelas equipes de segurança e as ferramentas existentes podem observar e detectar essas técnicas.

Mas a aquisição de conta requer que um invasor apenas comprometa uma conta (o ponto de acesso inicial) de onde eles podem coletar e exfiltrar dados do aplicativo comprometido.O ataque pode acabar muito rapidamente, e as ferramentas tradicionais oferecem pouco para evitar atividades maliciosas no aplicativo.

Dado o estado fraco do registro em log do SaaS, é provável que a maioria dos compromissos de aplicativos nem seja visível para a equipe de segurança. Mesmo que os dados estejam disponíveis, a detecção e a resposta se tornam muito mais difíceis após a aquisição da conta. Há dados de log limitados disponíveis no SaaS para começar, e distinguir a atividade legítima do usuário da atividade maliciosa é difícil.

Vimos com as violações do Snowflake que os invasores simplesmente fizeram login em contas de usuários usando credenciais roubadas e, em seguida, usaram um utilitário para executar a aquisição e reconhecimento de contas em escala, terminando usando comandos SQL para organizar e exfiltrar dados em vários locatários de clientes do Snowflake.

As atividades de resposta também são limitadas pelas circunstâncias: Você tem direitos de administrador para o aplicativo? O aplicativo fornece os tipos de atividades de resposta, como forçar um logout de sessão, que você precisa executar?

Cada incidente pode parecer uma investigação pontual, com peculiaridades em cada aplicativo para identificar e trabalhar, e poucas oportunidades para automatizar respostas de segurança – limitando as equipes de resposta a atividades post-mortem, que se encontram incapazes de conter ou reduzir o escopo da violação.

E a inteligência de ameaças?

A inteligência de ameaças em credenciais roubadas é abundante — muitos feeds comercialmente disponíveis podem ser adquiridos e ingeridos por equipes de segurança. No entanto, o desafio é descobrir onde esses créditos estão realmente sendo usados e separar os falsos positivos.

Pesquisadores da Push Security avaliaram recentemente dados de inteligência de ameaças representando 5.763 combinações de nome de usuário e senha que correspondiam aos domínios em uso pelos clientes da Push. Eles descobriram que menos de 1% das credenciais no conjunto de dados de vários fornecedores eram verdadeiros positivos —, o que significa que as credenciais roubadas suspeitas ainda estavam em uso pelos funcionários dessas organizações.

Em outras palavras, 99,5% das credenciais roubadas verificadas eram falsos positivos no momento da revisão.

Para cumprir a promessa de inteligência de ameaças de maneira significativa, as equipes de segurança precisam de uma abordagem diferente. Para começar, eles precisam ser capazes de observar e combinar com segurança as senhas encontradas nos feeds de credenciais com as que estão sendo usadas.

A maioria das organizações não consegue extrair muito valor dos feeds de credenciais comprometidos. No máximo, você pode estar automatizando o processo de solicitar que os usuários verifiquem suas credenciais para o login principal do SSO (por exemplo. Okta, Entra, Google Workspace) quando uma notificação de violação de credenciais é enviada. Mas esse fluxo de trabalho não será dimensionado quando você considerar com que frequência essas listas de credenciais violadas são recicladas — tudo começa a ficar um pouco spam. Depois de um tempo, os usuários começarão a reclamar e ignorar essas solicitações.

Como as equipes de segurança podem impedir a aquisição de contas de credenciais roubadas usando a telemetria do navegador

As equipes de segurança precisam de uma abordagem moderna para se defender contra a aquisição de contas, evitando que credenciais roubadas sejam usadas e que as lacunas de MFA sejam exploradas.

O Push Security fornece uma plataforma ITDR baseada em navegador que implanta um agente de navegador nos navegadores dos funcionários para impedir ataques de identidade.

O Push usa um agente de navegador que é capaz de observar com segurança as credenciais no momento do login em qualquer aplicativo, além de coletar uma telemetria avançada do navegador e fornecer controles de segurança projetados para interromper as aquisições de contas antes que elas ocorram.

O Push também é capaz de fornecer telemetria do navegador e um inventário de toda a sua superfície de ataque de identidade de contas e aplicativos, bem como analisar a postura de segurança de senhas de funcionários, métodos de login e status de MFA — para fechar vulnerabilidades de contas de alto risco.

A Push lançou recentemente dois recursos voltados para ajudar as equipes de segurança a interromper as aquisições de contas causadas por credenciais roubadas e lacunas de MFA.

Correlacione as credenciais que seus funcionários usam com as encontradas nos feeds de credenciais comprometidos

O agente do navegador Push é capaz de comparar as credenciais roubadas suspeitas fornecidas pelos feeds TI com as credenciais realmente usadas pelos funcionários em toda a organização e, em seguida, sinalizar apenas os verdadeiros positivos verificados.

Os clientes Push podem consumir TI a partir das fontes fornecidas diretamente pela plataforma Push — ou usar a API REST Push para enviar os seus próprios combos de email/senha a partir de ferramentas TI existentes.

Este método funciona independentemente da fonte dos dados ou da sua idade. Este método também descobre onde uma credencial roubada em um aplicativo também está em uso em vários outros aplicativos.

Veja como funciona:

Push recebe TI em credenciais roubadas de feeds de fornecedores.
Para cada ambiente de cliente, o Push verifica os domínios de cliente no conjunto de dados.
Quando houver suspeita de roubo de credenciais para um ambiente de cliente, o Push hashes e sais as senhas e, em seguida, envia essas impressões digitais para os agentes do navegador relevantes para comparação. Para dados de credenciais fornecidos pelo cliente, o Push executa a mesma salga e hash para criar impressões digitais que pode usar para comparar com impressões digitais de senha observadas pelos agentes relevantes do navegador.
Se a impressão digital de credencial roubada corresponder a uma impressão digital de credencial conhecida observada em uso pelo agente do navegador Push, a plataforma retornará um alerta positivo verdadeiro validado.

Você pode receber alertas para essa detecção via webhook, notificação da plataforma de mensagens ou no console de administração Push.

Confira o vídeo de lançamento do recurso para obter mais informações abaixo:

Obtenha visibilidade MFA em todos os seus aplicativos e feche as lacunas

O Push também pode ajudar as equipes a fechar as lacunas do MFA. À medida que os usuários acessam aplicativos com suas identidades corporativas, o Push analisa o status e os métodos de registro do MFA e também identifica quais aplicativos eles estão usando e seus métodos de login. Usando controles no navegador, o Push pode orientar os usuários a registrar o MFA em diferentes aplicativos.

Imagine um cenário em que você precisa investigar rapidamente o impacto comercial de uma violação SaaS recentemente anunciada. Usando Push, você pode:

Verifique imediatamente se a extensão Push observou o uso dos funcionários do aplicativo violado. Você também pode ver quantas contas o Push viu nesse aplicativo e como eles estão acessando (SSO vs. outros métodos, como login de senha local).
Para essas contas no aplicativo violado, você pode ver rapidamente se elas têm MFA e quais métodos são registrados. Para determinar o status do MFA, a extensão Push usa a sessão ativa do usuário existente em um aplicativo para consultar o status de registro do MFA da conta usando a própria API do aplicativo, fornecendo uma verificação confiável.
Você também pode ver se as senhas dos usuários têm algum problema de segurança, como uma credencial roubada verificada ou uma senha fraca ou reutilizada.
Para contas que não possuem MFA, você pode configurar um controle de execução para solicitar que os funcionários que não possuem MFA o configurem sempre que usarem o aplicativo.
Em seguida, use os webhooks do Push para monitorar registros de MFA e alterações de senha consultando a telemetria do navegador fornecida pelo agente do Push.

Ao combinar alertas para credenciais roubadas verificadas com a capacidade de encontrar e aumentar a adoção de MFA mesmo em aplicativos não gerenciados, o Push oferece às equipes de segurança um kit de ferramentas formidável para interromper a aquisição de contas.

Fonte: https://thehackernews.com/