A Última Maneira Que Os Invasores Estão Contornando o MFA

Os invasores estão cada vez mais recorrendo ao sequestro de sessão para contornar a adoção generalizada de MFA. Os dados dão suporte a isso , como:

147.000 ataques de repetição de token foram detectados pela Microsoft em 2023, um aumento de 111% em relação ao ano anterior (Microsoft).
Ataques a cookies de sessão agora acontecem na mesma ordem de magnitude que ataques baseados em senha (Google).

O sequestro de sessão tem um novo visual#
Quando pensamos no exemplo clássico de sequestro de sessão, pensamos em ataques Man-in-the-Middle (MitM) da velha escola que envolviam espionagem em tráfego de rede local não seguro para capturar credenciais ou, mais comumente, detalhes financeiros como dados de cartão de crédito. Ou, conduzindo ataques do lado do cliente comprometendo uma página da web, executando JavaScript malicioso e usando cross-site scripting (XSS) para roubar o ID de sessão da vítima.

O sequestro de sessão parece bem diferente hoje em dia. Não mais baseado em rede, o sequestro de sessão moderno é um ataque baseado em identidade realizado pela internet pública visando aplicativos e serviços baseados em nuvem.

Embora o meio seja diferente, os objetivos são basicamente os mesmos: roubar material de sessão válido – cookies, tokens, IDs – para retomar a sessão do dispositivo do invasor (um dispositivo remoto, navegador e local diferentes).

Ao contrário do sequestro de sessão legado, que geralmente falha quando confrontado com controles básicos como tráfego criptografado, VPNs ou MFA, o sequestro de sessão moderno é muito mais confiável para contornar controles defensivos padrão.

Também vale a pena notar que o contexto desses ataques mudou muito. Enquanto antigamente você provavelmente tentava roubar um conjunto de credenciais de domínio usadas para autenticar o Active Directory interno, bem como seus aplicativos de e-mail e negócios principais, hoje em dia a superfície de identidade parece muito diferente – com dezenas ou centenas de contas separadas por usuário em um amplo conjunto de aplicativos em nuvem.

Por que os invasores querem roubar suas sessões?#
Em resumo: roubar sessões ao vivo permite que invasores ignorem controles de autenticação como MFA. Se você puder sequestrar uma sessão existente, terá menos etapas para se preocupar – sem precisar se preocupar em converter nomes de usuário e senhas roubados em uma sessão autenticada.

Embora, em teoria, os tokens de sessão tenham uma vida útil limitada, na realidade, eles podem permanecer válidos por períodos mais longos (geralmente em torno de 30 dias) ou até mesmo indefinidamente, desde que a atividade seja mantida.

Conforme mencionado acima, há muito que um invasor pode ganhar ao comprometer uma identidade. Se for uma identidade IdP como uma conta Okta ou Entra com acesso SSO aos seus aplicativos downstream, perfeito! Se não, bem, talvez seja um aplicativo valioso (como o Snowflake, talvez?) com acesso à maior parte dos dados do seu cliente. Ou talvez seja um aplicativo menos atraente, mas com integrações interessantes que podem ser exploradas.

Não é surpresa que a identidade esteja sendo mencionada como o novo perímetro de segurança e que ataques baseados em identidade continuem a aparecer nas manchetes.

Se você quiser saber mais sobre o estado dos ataques de identidade no contexto de aplicativos SaaS, confira este relatório retrospectivo de 2023/4.

No entanto, nem todos os métodos de sequestro de sessão são iguais, o que significa que eles reagem de forma diferente aos controles que enfrentam. Isso cria diferentes prós e contras com base na abordagem escolhida pelo invasor.

Comparando abordagens de sequestro de sessão#
Para sequestrar uma sessão, você precisa primeiro roubar os cookies de sessão associados a uma sessão de usuário ativa. No sentido moderno, há duas abordagens principais para isso:

Usando kits de ferramentas de phishing modernos, como AitM e BitM.
Usando ferramentas que têm como alvo dados do navegador, como infostealers.
Vale a pena notar que ambos os métodos têm como alvo tanto o material de credencial típico (por exemplo, nomes de usuários e senhas) quanto os cookies de sessão. Os invasores não estão necessariamente fazendo uma escolha para ir atrás de cookies de sessão em vez de senhas – em vez disso, as ferramentas que eles estão usando suportam ambos, ampliando os meios disponíveis para eles. Se contas sem MFA forem identificadas (e ainda há muitas delas), então as senhas funcionarão muito bem.

Ataques de phishing modernos: AitM e BitM#
Os kits de ferramentas de phishing modernos veem a vítima completar quaisquer verificações de MFA como parte do processo. No caso do AitM, a ferramenta atua como um proxy, o que significa que o invasor pode interceptar todo o material de autenticação – incluindo segredos como tokens de sessão. O BitM vai um passo além e vê a vítima enganada para controlar remotamente o navegador do invasor – o equivalente virtual de um invasor entregando seu laptop para sua vítima, pedindo que ela faça login no Okta para ela e, em seguida, pegando seu laptop de volta depois.

Ao contrário do MitM tradicional, que geralmente é altamente oportunista, o AitM tende a ser muito mais direcionado – já que é o produto de uma campanha de phishing. Embora o AitM seja muito melhor escalável do que os ataques MitM tradicionais (que eram muito locais), com o AitM você está naturalmente focado em contas pertencentes a um aplicativo ou serviço específico com base em qualquer aplicativo que você esteja emulando ou site que esteja personificando.

Falamos sobre phishing AitM e BitM e como detectá-los e bloqueá-los com muito mais detalhes em um artigo recente do Hacker News: Se você perdeu, confira aqui.

Ladrões de informações#
Por outro lado, os infostealers tendem a ser menos visados ​​do que o AitM – muito mais um oportunista smash-and-grab. Isso é particularmente evidente quando olhamos para os mecanismos de entrega típicos para infostealers – infectando sites (ou plugins), publicidade maliciosa (malvertising), sites de download P2P, fóruns de jogos, anúncios de mídia social, repositórios públicos do GitHub… a lista continua.

No restante deste artigo, vamos focar especificamente em infostealers. Há boas razões para isso quando falamos sobre sequestro de sessão:

Os infostealers têm como alvo todos os cookies de sessão salvos nos navegadores da vítima, bem como todas as outras informações e credenciais salvas, o que significa que mais sessões são colocadas em risco como resultado de um comprometimento do infostealer em comparação a um ataque AitM mais direcionado, que resultará no comprometimento de apenas um único aplicativo/serviço (a menos que seja uma conta IdP usada para SSO para outros aplicativos downstream).
Por isso, os infostealers são, na verdade, bem flexíveis. No cenário em que há controles de nível de aplicativo impedindo que a sessão seja acessada do dispositivo do hacker (como controles rigorosos de bloqueio de IP que exigem um endereço IP de escritório específico que não pode ser ignorado usando redes proxy residenciais), você pode tentar outros aplicativos. Embora seja comum que controles mais robustos, digamos, no seu login do M365, eles têm menos probabilidade de serem implementados para aplicativos downstream — o que pode ser igualmente proveitoso para um invasor. Mesmo que essas contas sejam geralmente acessadas via SSO, as sessões ainda podem ser roubadas e retomadas por um invasor com as mãos nos cookies da sessão sem precisar autenticar na conta do IdP.
Mas os infostealers não são bloqueados pelo EDR?#
Não necessariamente. Os melhores EDRs provavelmente detectarão a maioria dos infostealers comerciais, mas os invasores estão continuamente inovando e, em particular, grupos de ameaças mais sofisticados e com bons recursos são conhecidos por desenvolver pacotes de malware personalizados ou sob medida para evitar a detecção. Então é um jogo de gato e rato e sempre há exceções que escapam pela rede, ou vulnerabilidades que podem ser exploradas para contorná-las, como esta falha no Microsoft Defender SmartScreen, que foi recentemente explorada para entregar malware infostealer .

As infecções por infostealer são frequentemente rastreadas até o comprometimento de dispositivos não gerenciados – como em organizações que dão suporte a BYOD, ou no caso de contratados terceirizados usando seus próprios equipamentos. E a maioria dos comprometimentos históricos de infostealer foram atribuídos a dispositivos pessoais. No entanto, como os perfis do navegador podem ser sincronizados entre dispositivos, um comprometimento de dispositivo pessoal pode facilmente resultar no comprometimento de credenciais corporativas:

O usuário faz login em sua conta pessoal do Google no dispositivo de trabalho e salva o perfil.
O usuário habilita a sincronização de perfil (é fácil de fazer e incentivado pelo design) e começa a salvar credenciais corporativas no gerenciador de senhas do navegador.
O usuário faz login em seu dispositivo pessoal e o perfil é sincronizado.
Eles pegam uma infecção de infostealer em seus dispositivos pessoais.
Todas as credenciais salvas, incluindo as corporativas, são roubadas pelo malware.
Portanto, não é possível confiar que o EDR eliminará completamente o risco representado pelos ladrões de informações ao considerar a realidade de como os ataques de identidade funcionam e como as identidades pessoais e corporativas dos seus usuários podem convergir no ambiente de trabalho moderno.

E as chaves de acesso?#
Passkeys são um controle de autenticação resistente a phishing, o que significa que são eficazes na prevenção de ataques AitM e BitM que exigem que a vítima conclua o processo de autenticação para poder sequestrar a sessão. No entanto, no caso de infostealers, nenhuma autenticação ocorre. O ataque infostealer tem como alvo o endpoint (veja acima), enquanto a ação de importar cookies de sessão roubados para o navegador do invasor simplesmente retoma a sessão existente em vez de passar pelo processo de autenticação novamente.

Detectando e respondendo ao sequestro de sessão#
Existem várias camadas de controles que, em teoria, funcionam para evitar o sequestro de sessão no final da cadeia de ataque.

Etapa 1: Entrega do malware#
A vítima deve primeiro ser atraída para baixar o infostealer. Como mencionado anteriormente, isso pode acontecer em muitos lugares diferentes e, às vezes, não acontece em um dispositivo corporativo com controles esperados (por exemplo, segurança de e-mail, filtragem de conteúdo, lista de bloqueio de itens sabidamente ruins).

E mesmo quando estão em vigor, muitas vezes não atendem às expectativas.

Etapa 2: Executando o malware#
O principal controle que protege contra isso é sua solução AV/EDR, que abordamos na seção anterior. Resumindo, não é infalível.

Etapa 3: Detectando sessões não autorizadas#
Depois que um invasor rouba seus cookies de sessão, a última chance que você tem de detectá-lo é quando ele é usado para sequestrar a sessão.

A última linha de defesa para a maioria das organizações serão os controles no aplicativo, como políticas de restrição de acesso. Como mencionado anteriormente, geralmente não é tão difícil contornar as restrições de bloqueio de IP, por exemplo, a menos que elas sejam especialmente bloqueadas – como para o endereço IP de um escritório específico. Mesmo assim, se o invasor não puder acessar sua conta do M365, é improvável que cada um dos seus aplicativos downstream tenha os mesmos níveis de política restritiva em vigor.

Então, embora haja uma chance razoável de que infostealers sejam detectados e bloqueados em dispositivos corporativos, isso não é uma garantia absoluta – e muitos ataques de infostealers os contornarão completamente. Quando se trata de detectar e bloquear sessões não autorizadas, você depende de controles variáveis ​​no nível do aplicativo – que, novamente, não são tão eficazes.

Demonstração em vídeo: Sequestro de sessão em ação#
Confira a demonstração em vídeo abaixo para ver a cadeia de ataque em ação do ponto de comprometimento de um infostealer, mostrando o roubo de cookie de sessão, reimportando os cookies para o navegador do invasor e evadindo controles baseados em políticas no M365. Ele também mostra o direcionamento de aplicativos downstream que geralmente são acessados ​​via SSO no contexto de um comprometimento do Microsoft Entra e do Okta.

Demonstração: Sequestro de sessão usando cookies roubados

Adicionando uma nova linha de defesa – o navegador#
Os profissionais de segurança estão acostumados a alavancar o conceito da Pirâmide da Dor nessas situações. Quando uma detecção falha, ela geralmente se concentra em detectar o tipo errado de indicador (ou seja, está vinculado a uma variável que é fácil para o invasor alterar).

Para que o ataque tenha sucesso, o atacante precisa retomar a sessão da vítima em seu próprio navegador. Essa é uma ação, um comportamento, que não pode ser evitado.

Então, e se você pudesse detectar sempre que um invasor usa um token de sessão roubado e sequestra uma sessão?

A equipe do Push Security lançou um controle que detecta exatamente isso. Injetando um marcador exclusivo na sequência de sessões do agente do usuário que ocorrem em navegadores registrados no Push. Ao analisar logs do IdP, você pode identificar atividades da mesma sessão que têm o marcador Push e que não têm o marcador.

Isso só pode acontecer quando uma sessão é extraída de um navegador e importada maliciosamente para um navegador diferente. Como um benefício adicional, isso significa que também atua como uma última linha de defesa contra qualquer outro tipo de ataque de aquisição de conta, onde um aplicativo que geralmente é acessado de um navegador com o plugin Push instalado é acessado repentinamente de um local diferente.

Para saber mais sobre o recurso, confira o comunicado Aqui.
Fonte: thehackernews.com