Os invasores estão cada vez mais fazendo uso de técnicas de ataque “sem rede” visando aplicativos e identidades em nuvem. Veja como os invasores podem (e estão) comprometendo as organizações – sem nunca precisar tocar no endpoint ou nos sistemas e serviços de rede convencionais.
Antes de entrar em detalhes sobre as técnicas de ataque utilizadas, vamos discutir por que esses ataques estão se tornando mais prevalentes.
A adoção de SaaS está mudando a composição da TI da empresa
A revolução SaaS e o crescimento liderado por produtos tiveram um enorme impacto na estrutura das redes das empresas e no native onde residem os principais sistemas e dados de negócios.
A maioria das organizações hoje usa dezenas a centenas de aplicativos SaaS em funções de negócios. Alguns são inteiramente nativos de SaaS, sem nenhuma rede tradicional digna de nota, mas a maioria adotou um modelo híbrido com uma mistura de serviços locais, em nuvem e SaaS formando a espinha dorsal dos aplicativos de negócios usados.
A maior parte da adoção de SaaS é orientada pelo usuário, em vez de ser gerenciada centralmente pela TI, já que a adoção de baixo para cima é inerente ao crescimento liderado pelo produto. Os dados mais recentes da Push Safety indicam que apenas 1 em cada 5 aplicativos SaaS foram sancionados pela empresa. A maioria é simplesmente desconhecida e, portanto, não foi revisada.
Os aplicativos em nuvem e SaaS são projetados para serem interconectados, funcionando como redes fechadas de aplicativos de negócios internos que você pode ter usado no passado. O veículo para esta interconectividade é a identidade.
As identidades digitais são cada vez mais complicadas e difíceis de proteger
A forma mais básica de identidade é uma conta de usuário criada para serviços nos quais você se inscreve com nome de usuário/e-mail e senha. Para reduzir o risco de controle de contas e a complexidade do gerenciamento de um número cada vez maior de contas, as organizações estão usando os serviços de provedores de identidade (IdPs) para centralizar o acesso a aplicativos em uma única plataforma e identidade, usando protocolos como logon único (SSO). ) e OAuth para gerenciar autenticação e autorização, respectivamente.
A composição específica de uma identidade pode variar muito. Dependendo do aplicativo, é possível ter vários mecanismos de autenticação para a mesma conta – por exemplo, through SAML, logins sociais (OIDC) e nome de usuário e senha. Embora o SAML exija que os administradores o configurem com antecedência para um determinado locatário de aplicativo, os usuários podem se inscrever em um aplicativo usando o OIDC simplesmente usando o recurso “fazer login com o Google”.
Na verdade, isso cria múltiplas identidades vinculadas a uma única conta, o que pode introduzir muita confusão e complexidade – por exemplo, só porque um administrador IdP exclui essa conta, não significa que o aplicativo/conta não possa ser acessado usando um dos outros métodos de login que foram criados. Isto pode dificultar saber quais aplicativos estão em uso e quais identidades existem na organização.
Então, na prática, é possível acabar com uma combinação do seguinte:
- Provedores de identidade (normalmente três por organização, em média) (por exemplo, Okta, Entra/Microsoft, Google)
- Aplicativos que atuam como plataforma SSO para aplicativos conectados (por exemplo, Atlassian Entry, Adobe Artistic Cloud)
- Aplicativos SaaS usando diferentes protocolos de autenticação (SAML, OIDC) e autorização (OAuth)
- Aplicativos SaaS com nome de usuário e senha locais
- Credenciais e segredos armazenados em aplicativos gerenciadores de senhas e autenticadores (que podem estar em navegadores, em sistemas operacionais locais e em aplicativos de terceiros)
Pode ficar bastante complicado – com a maioria das organizações tendo mais de 100 aplicativos em seu inventário, resultando em milhares de identidades espalhadas.
Então, dependendo dos escopos OAuth aprovados para um determinado aplicativo, as permissões e os fluxos de trabalho em um aplicativo podem afetar outros aplicativos onde a aprovação é concedida para que eles se comuniquem entre si.
A identidade é a cola que mantém este ecossistema unido. No entanto, os controlos existentes para proteger a identidade têm sérias limitações. As empresas muitas vezes pensam que todos os seus aplicativos e identidades têm MFA implementado ou que todos os aplicativos estão atrás de SSO. Mas a realidade é que apenas 1/3 dos aplicativos realmente suportam SSO (e muitos deles apenas no nível premium, com um forte aumento de preço). Além disso, cerca de 60% das identidades únicas (ou seja, que não utilizam SSO) não têm MFA registado.
Portanto, na realidade, existem lacunas significativas nos controlos de segurança que protegem as identidades na nuvem, enquanto as identidades e as aplicações na nuvem estão a tornar-se mais predominantes.
Os invasores têm como alvo vulnerabilidades de identidade na nuvem
Os invasores estão tomando nota disso. De acordo com o DBIR de 2024 da Verizon, 74% de todas as violações envolveram o elemento humano, visando contas de usuários comprometidas por meio de erro humano, uso indevido de privilégios, uso de credenciais comprometidas ou engenharia social.
Embora isso não seja novidade (algumas descrições de ataques de identidade/phishing têm sido o principal vetor de ataque desde pelo menos 2013), o último relatório de ameaças globais da Crowdstrike vai além, observando que 75% dos ataques para obter acesso foram livres de malwaree essa ataques “conscientes da nuvem” (direcionamento deliberado, em vez de oportunista, de serviços em nuvem para comprometer funcionalidades específicas) aumentou 110%. A Microsoft também observa em torno 4.000 ataques de senha por segundo visando especificamente identidades na nuvemembora haja sugestões de funcionários do Google que ataques que procuram roubar cookies de sessão (e, portanto, ignorar o MFA) acontecem aproximadamente na mesma ordem de magnitude que os ataques baseados em senha.
Olhando além dos números, as evidências de violações aos olhos do público contam a mesma história. Grupos de ameaças como APT29/Cozy Bear/The Dukes e Scattered Spider/0ktapus mostram como os invasores estão visando ativamente serviços IdP, aplicativos SaaS e SSO/OAuth para realizar ataques de alto perfil contra empresas como Microsoft e Okta.
Se quiser ler mais sobre isso, você pode conferir esta postagem do weblog que rastreia ataques de identidade vistos em estado selvagem.
Aplicativos e identidades em nuvem são a nova terra de oportunidades para os invasores. Devido à mudança para serviços em nuvem, eles oferecem o mesmo valor que um ataque tradicional projetado para violar um perímetro de rede através do endpoint. De muitas maneiras, a própria identidade é a nova superfície de ataque. Ao contrário de outros limites de segurança, como a rede ou o endpoint, também apresenta um obstáculo muito menor em termos dos controlos que existem atualmente para defender este novo perímetro.
Os ataques baseados em identidade costumavam ser localizados no endpoint ou em “sistemas de identidade” adjacentes, como o Energetic Listing. O objetivo do invasor period violar esse perímetro e mover-se dentro da organização. Agora, a identidade está muito mais dispersa – a porta de entrada para um ecossistema de aplicativos e serviços em nuvem interconectados, todos acessados pela Web. Isto mudou significativamente a magnitude do desafio enfrentado pelas equipes de segurança. Afinal, é muito mais difícil impedir ataques de preenchimento de credenciais contra 100 aplicativos SaaS do que o único endpoint externo centralizado de VPN/webmail de antigamente.
Identidades na nuvem são o novo perímetro
Parece bastante claro que as identidades na nuvem são o novo perímetro digital. Este não é o futuro, é agora. A única questão que ainda precisa ser determinada é quais técnicas e técnicas ofensivas surgirão e qual será a resposta da indústria para detê-las.
| Period da segurança | Técnicas do dia | Resposta da indústria |
| Anos 2000 Hacking de perímetro tradicional | Scanners de portas, scanners de vulnerabilidades, buffer overflows, ataques de aplicativos da net, hacking de WiFi, backdoors de cliente/servidor | Firewalls, DMZs, gerenciamento de patches, codificação segura, WPA, testes de penetração |
| década de 2010 Endpoint é o novo perímetro | Phishing, macros de escritório, bugs de formato de arquivo, explorações de navegador, implantes residentes em memória, estruturas C2 | Endpoint hardening, EDR, SIEMS, crimson teaming, caça a ameaças |
| 2020 As identidades na nuvem são novo perímetro | ??? | ??? |
No ano passado, a Push Safety lançou uma matriz de técnicas de ataque SaaS no GitHub (inspirada no MITRE ATT&CK Framework, mais focado em endpoints) que demonstra como os invasores podem atingir um negócio sem tocar em superfícies tradicionais, como a rede ou os endpoints.
Quando encadeadas, essas técnicas permitem que um invasor conclua um ataque ponta a ponta na nuvem.
Push também lançou uma série de postagens no weblog cobrindo como essas técnicas podem ser usadas – as técnicas mais populares estão resumidas abaixo:
| Técnica | Visão geral |
| Phishing AiTM | O phishing AiTM usa ferramentas dedicadas para atuar como um proxy da net entre a vítima e um portal de login legítimo para um aplicativo ao qual a vítima tem acesso, principalmente para facilitar a violação da proteção MFA. Ao fazer proxy em tempo actual para o portal de login de destino, o adversário recebe acesso a uma senha válida e a cookies de sessão válidos que ele pode roubar e usar para sequestrar a sessão. Uma vez logado, o usuário vítima verá todos os dados reais que esperaria ver normalmente (por exemplo, seus próprios e-mails/arquivos, and many others.), pois é um proxy do aplicativo actual. Isso reduz as probabilities de perceberem que foram comprometidos devido à natureza autêntica de funcionamento do aplicativo proxy. |
| Phishing de mensagens instantâneas | Aplicativos de mensagens instantâneas como Groups e Slack são uma ótima maneira para os invasores escaparem de proteções mais rigorosas contra phishing baseadas em e-mail em relação a hyperlinks e anexos maliciosos. A natureza imediata e em tempo actual das mensagens instantâneas torna-as um vetor útil para ataques de phishing, já que os usuários estão menos familiarizados com esses aplicativos como vetores de entrega para ataques de phishing. Usando mensagens instantâneas, é possível falsificar/representar usuários, usar contas de bot para criar diálogos confiáveis, abusar da funcionalidade de visualização de hyperlinks e editar mensagens e contas retrospectivamente para limpar seus rastros. |
| Sequestro de SAML | SAMLjacking é quando um invasor usa configurações de SSO SAML para um locatário SaaS que ele controla, a fim de redirecionar os usuários para um hyperlink malicioso de sua escolha durante o processo de autenticação. Isso pode ser altamente eficaz para phishing, pois o URL unique será um URL SaaS legítimo e os usuários esperam fornecer credenciais. Ele também pode ser usado para movimentação lateral se uma conta de administrador de um aplicativo SaaS for comprometida, modificando ou habilitando SAML, apontando o URL para uma página de phishing de credenciais que se parece ou faz proxy de um serviço de autenticação legítimo (por exemplo, Google ou Microsoft). O adversário pode então atingir os usuários enviando hyperlinks aparentemente legítimos para a página de login do aplicativo ao locatário, que então funciona como um ataque watering gap. |
| Oktajacking | Um invasor pode configurar seu próprio locatário Okta para ser usado em ataques de phishing altamente convincentes. Esse ataque funciona porque o Okta encaminha credenciais de logins de contas vinculadas ao AD para seu próprio agente AD que é executado na rede de destino. Em seguida, o Okta permite que o agente informe se o login deve ser bem-sucedido ou não. Isso permite que um invasor que tenha comprometido um agente AD, ou seja capaz de emular um, monitore as credenciais de login dos usuários do Okta e forneça funcionalidade semelhante a uma chave mestra para autenticar no Okta como qualquer usuário que desejar. Ele também pode ser usado de forma semelhante ao SAMLjacking para movimentação lateral – exceto que você não precisa redirecionar para um domínio malicioso separado. |
| Fluxos de trabalho de sombra | Um fluxo de trabalho paralelo é uma técnica para usar aplicativos de automação SaaS para fornecer um método semelhante à execução de código para conduzir ações maliciosas de uma fonte legítima usando integrações OAuth. Isso poderia ser uma exportação diária de arquivos de unidades de nuvem compartilhadas, encaminhamento e exclusão automática de e-mails, clonagem de mensagens instantâneas, exportação de diretórios de usuários – basicamente qualquer coisa que seja possível usando a API do aplicativo de destino. |
Técnicas de ataque sem rede em ação
Mas não há nada como vê-las em ação para entender o quão impactantes essas técnicas podem ser. Então confira o clipe abaixo de Luke Jennings, vice-presidente de P&D da Push. Neste vídeo, ele cobre:
- Acesso inicial through phishing AiTM usando EvilNoVNC, um navegador na estrutura de phishing Browser (BitB), para sequestrar uma sessão Okta de usuário
- Roubar credenciais da sessão do navegador e acessar outros aplicativos through Okta SSO, configurar esses aplicativos para criar acesso persistente e fazer backdoor nos aplicativos
- Realizar roubo adicional de credenciais para outros usuários desses aplicativos dentro do locatário corporativo, abusando de logins SAML e SWA
- Acessando diretamente dados confidenciais e funcionalidades em aplicativos comprometidos
Você poderia detectar e responder a este ataque?
Depois de ver o que é possível, é importante perguntar: você poderia detectar e responder a esse cenário de ataque?
- Você detectaria o phishing inicial do AiTM?
- Quantos usuários seriam comprometidos pelo ataque SAMLjacking?
- Você encontraria todos os diferentes backdoors em vários aplicativos SaaS?
- …ou apenas redefinir a senha e os tokens MFA da conta Okta?
- …e as senhas de todos os aplicativos não SAML?
A maioria das organizações apresenta uma lacuna de segurança quando se trata de ataques baseados em identidade. Isso ocorre em grande parte porque os controles em torno da segurança de identidade geralmente se concentram na proteção de sistemas centrais de identidade (pense no Energetic Listing/Entra ID), em oposição à infraestrutura de identidade maior no que se refere a aplicativos e serviços em nuvem.
Da mesma forma, os controlos em que as organizações investiram são largamente contornados por estes ataques. As ferramentas EDR usadas para proteger os sistemas operacionais subjacentes têm presença mínima aqui porque esses aplicativos são acessados no navegador – cada vez mais apontados como o novo sistema operacional. Conforme discutido aqui, proteger a identidade é absolutamente important para proteger os serviços na nuvem. E uma parte significativa da cadeia de ataque – por exemplo, tentativas de phishing em geral, incluindo técnicas AiTM e BitB projetadas para contornar MFA, ou compartilhamento de senha entre aplicativos e serviços, simplesmente não são cobertas por ferramentas de segurança de endpoint, logs IdP ou logs SaaS de aplicativos e serviços individuais.
Esses tipos de ataques são um verdadeiro desafio para muitas organizações neste momento, porque passam despercebidos pelas ferramentas e serviços de segurança existentes.
Interessado em aprender mais?
Se você quiser saber mais sobre ataques de identidade na nuvem e como impedi-los, dê uma olhada no Push Safety – você pode experimentar o agente baseado em navegador gratuitamente!
