Os invasores estão recorrendo cada vez mais ao sequestro de sessão para contornar a adoção generalizada do MFA. Os dados apoiam isso, como:
- 147.000 ataques de repetição de token foram detectados pela Microsoft em 2023, um aumento de 111% ano após ano (Microsoft).
- Os ataques a cookies de sessão agora acontecem na mesma ordem de grandeza que os ataques baseados em senha (Google).
Mas o sequestro de sessão não é uma técnica nova – então o que mudou?
O sequestro de sessão tem um novo visible
Quando pensamos no exemplo clássico de sequestro de sessão, pensamos nos antigos ataques Man-in-the-Center (MitM) que envolviam espionagem no tráfego de rede native 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 que comprometem uma página da Internet, 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 atualmente. O sequestro de sessão moderno, que não é mais baseado em rede, é um ataque baseado em identidade realizado na Web pública visando aplicativos e serviços baseados em nuvem.
Embora o meio seja diferente, os objetivos são basicamente os mesmos: roubar materials válido da sessão – cookies, tokens, IDs – para retomar a sessão do dispositivo do invasor (um dispositivo remoto, navegador e native diferente).
Ao contrário do sequestro de sessão legado, que muitas vezes 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 os controles defensivos padrão.
Também é importante notar que o contexto destes ataques mudou muito. Enquanto antigamente você provavelmente tentava roubar um conjunto de credenciais de domínio usadas para autenticação no Lively Listing interno, bem como em 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 conta. usuário em um amplo conjunto de aplicativos em nuvem.
Por que os invasores querem roubar suas sessões?
Resumindo: roubar sessões ao vivo permite que invasores contornem controles de autenticação como MFA. Se você conseguir sequestrar uma sessão existente, terá menos etapas com que se preocupar – sem 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, podem permanecer válidos por períodos mais longos (normalmente cerca de 30 dias) ou mesmo indefinidamente, desde que a atividade seja mantida.
Conforme mencionado acima, um invasor pode ganhar muito ao comprometer uma identidade. Se for uma identidade IdP como uma conta Okta ou Entra com acesso SSO aos seus aplicativos downstream, perfeito! Caso contrário, 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 seja considerada o novo perímetro de segurança e que os ataques baseados na identidade continuem a chegar às manchetes.
Se você quiser saber mais sobre o estado dos ataques de identidade no contexto de aplicativos SaaS, confira este relatório referente a 2023/4.
Porém, nem todos os métodos de sequestro de sessão são iguais, o que significa que eles reagem de maneira 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, existem duas abordagens principais para isso:
- Usando kits de ferramentas de phishing modernos, como AitM e BitM.
- Usando ferramentas que visam dados do navegador, como infostealers.
Vale a pena notar que ambos os métodos têm como alvo materials de credenciais típico (por exemplo, nomes de usuário e senhas), bem como cookies de sessão. Os invasores não estão necessariamente optando por cookies de sessão em vez de senhas – em vez disso, as ferramentas que usam oferecem suporte a ambos, ampliando os meios disponíveis para eles. Se forem identificadas contas sem MFA (e ainda existem muitas delas), as senhas funcionarão perfeitamente.
Ataques de phishing modernos: AitM e BitM
Os modernos kits de ferramentas de phishing permitem que a vítima conclua todas as 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 materials de autenticação – incluindo segredos como tokens de sessão. O BitM vai um passo além e vê a vítima sendo enganada para controlar remotamente o navegador do invasor – o equivalente digital a um invasor entregando seu laptop computer à vítima, pedindo-lhe para fazer login no Okta e, em seguida, levar seu laptop computer de volta.
Ao contrário do MitM tradicional, que muitas vezes é altamente oportunista, o AitM tende a ser muito mais direcionado – pois é o produto de uma campanha de phishing. Embora o AitM seja muito melhor dimensionado do que os ataques MitM tradicionais (que eram muito locais), com o AitM você naturalmente se concentra em contas pertencentes a um aplicativo ou serviço específico com base no aplicativo que você está emulando ou no website que você está personificando.
Falamos sobre phishing AitM e BitM e como detectá-lo e bloqueá-lo com muito mais detalhes em um artigo recente do Hacker Information: Se você perdeu, confira aqui.
Ladrões de informação
Por outro lado, os infostealers tendem a ser menos visados do que o AitM – muito mais como um ataque oportunista. Isto é particularmente evidente quando se olha para os mecanismos típicos de entrega de infostealers – infectando websites (ou plug-ins), publicidade maliciosa (malvertising), websites de obtain P2P, fóruns de jogos, anúncios em mídias sociais, repositórios públicos do GitHub… a lista continua.
No restante deste artigo, vamos nos concentrar especificamente nos infostealers. Existem boas razões para isso quando se fala em sequestro de sessão:
- Os infostealers têm como alvo todos os cookies de sessão salvos no(s) navegador(es) 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 com um ataque AitM mais direcionado que resultará apenas no comprometimento de um único aplicativo/serviço (a menos que seja uma conta IdP usada para SSO para outros aplicativos downstream).
- Por causa disso, os infostealers são bastante flexíveis. No cenário em que existem controles em nível de aplicativo que impedem que a sessão seja acessada a partir 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 em outros aplicativos. Embora seja comum haver controles mais robustos, por exemplo, no seu login do M365, é menos provável que eles sejam implementados para aplicativos downstream – o que pode ser igualmente frutífero para um invasor. Mesmo que essas contas sejam geralmente acessadas by way of SSO, as sessões ainda podem ser roubadas e retomadas por um invasor com as mãos nos cookies da sessão, sem a necessidade de autenticação 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 explicit, sabe-se que grupos de ameaças mais sofisticados e com bons recursos desenvolvem pacotes de malware personalizados ou sob medida para evitar a detecção. Portanto, é um jogo de gato e rato e sempre há exceções que escapam da 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 atribuídas ao comprometimento de dispositivos não gerenciados – como em organizações de suporte BYOD ou no caso de terceiros que usam seus próprios equipamentos. E a maioria dos comprometimentos históricos dos infostealers foi atribuída a dispositivos pessoais. No entanto, como os perfis do navegador podem ser sincronizados entre dispositivos, o comprometimento de um dispositivo pessoal pode facilmente resultar no comprometimento de credenciais corporativas:
- O usuário faz login em sua conta pessoal do Google em seu dispositivo de trabalho e salva o perfil.
- O usuário habilita a sincronização de perfis (é 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 por infostealer em seus dispositivos pessoais.
- Todas as credenciais salvas, incluindo as corporativas, são roubadas pelo malware.
Portanto, não se pode confiar no EDR para eliminar totalmente o risco representado pelos infostealers quando se considera a realidade de como funcionam os ataques de identidade e como as identidades pessoais e corporativas dos seus usuários podem convergir no native de trabalho moderno.
E quanto às chaves de acesso?
As chaves de acesso 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 múltiplas camadas de controles que, em teoria, funcionam para evitar o sequestro de sessão no ultimate da cadeia de ataque.
Etapa 1: entrega do malware
A vítima deve primeiro ser atraída para baixar o infostealer. Conforme mencionado anteriormente, isso pode acontecer em vários lugares diferentes e, às vezes, não acontece em um dispositivo corporativo com os controles esperados (por exemplo, segurança de e-mail, filtragem de conteúdo, listas de bloqueio reconhecidamente inválidas).
E mesmo quando estão em vigor, muitas vezes ficam aquém.
Estágio 2: Executando o malware
O principal controle que protege contra isso é a sua solução AV/EDR, que abordamos na seção anterior. DR não é infalível.
Etapa 3: Detecção de sessões não autorizadas
Depois que um invasor rouba seus cookies de sessão, a última probability que você tem de detectá-los é no momento em que eles são usados 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. Conforme mencionado anteriormente, geralmente não é tão difícil contornar as restrições de bloqueio de IP, por exemplo, a menos que sejam especialmente bloqueadas – como para o endereço IP de um escritório específico. Mesmo assim, se o invasor não conseguir acessar sua conta M365, é improvável que cada um dos seus aplicativos downstream tenha os mesmos níveis de política restritiva em vigor.
Portanto, embora haja uma probability razoável de que os infostealers sejam detectados e bloqueados em dispositivos corporativos, isso não é uma garantia absoluta – e muitos ataques de infostealers irão contorná-los 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 o vídeo de demonstração abaixo para ver a cadeia de ataque em ação desde o comprometimento do infostealer, mostrando o roubo de cookies de sessão, reimportando os cookies para o navegador do invasor e evitando controles baseados em políticas no M365. Ele também mostra o direcionamento de aplicativos downstream que geralmente são acessados by way of SSO no contexto de um compromisso Microsoft Entra e Okta.
Adicionando uma nova linha de defesa – o navegador
Os profissionais de segurança estão acostumados a aproveitar o conceito da Pirâmide da Dor nessas situações. Quando uma detecção falha, geralmente ela se concentra em detectar o tipo errado de indicador (ou seja, está vinculado a uma variável que é fácil de ser alterada pelo invasor).
Para que o ataque seja bem-sucedido, o invasor deve retomar a sessão da vítima em seu próprio navegador. Esta é 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 Push Safety 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 inscritos no Push. Ao analisar os logs do IdP, você pode identificar atividades da mesma sessão que possuem o marcador Push e que não possuem 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 última linha de defesa contra qualquer outro tipo de ataque de controle de conta, onde um aplicativo que normalmente é acessado de um navegador com o plug-in Push instalado é repentinamente acessado de um native diferente.
Para saber mais sobre o recurso, confira o lançamento aqui.
Saiba mais
A detecção de sessões roubadas é apenas um recurso poderoso projetado para fornecer uma defesa em camadas contra o controle de contas, juntamente com:
Para ver como o agente de navegador da Push Safety interrompe ataques de identidade para você mesmo, solicite uma demonstração com a equipe hoje mesmo ou inscreva-se para uma avaliação de autoatendimento.
