À medida que cresce a conscientização em torno de muitos métodos de MFA serem “phishable” (ou seja, não resistentes a phishing), métodos de autenticação baseados em FIDO2 sem senha (também conhecidos como senhas) como YubiKeys, Okta FastPass e Windows Hello estão sendo cada vez mais defendidos.
Isso é uma coisa boa. Os fatores de MFA mais comumente usados (como códigos SMS, notificações push e OTP baseado em aplicativo) são rotineiramente ignorados, com os modernos kits de phishing “Attacker-in-the-Middle” de proxy reverso sendo o método mais comum (e a escolha padrão para ataques de phishing hoje).
Eles funcionam interceptando a sessão autenticada criada quando uma vítima insere sua senha e conclui uma verificação de MFA. Para fazer isso, o site de phishing simplesmente passa mensagens entre o usuário e o site real – daí “Attacker-in-the-Middle”.
Por outro lado, logins baseados em senha não podem ser vítimas de phishing. Como os logins baseados em senha são vinculados ao domínio, tentar usar uma chave de acesso para microsoft.com em phishing.com simplesmente não gerará o valor correto para passar na verificação de autenticação, mesmo quando enviado por proxy usando um kit AitM.
Mas os invasores não desistiram tão facilmente. À medida que as chaves de acesso se tornam mais populares, estamos vendo uma série de técnicas projetadas para fazer downgrade ou contornar o processo de autenticação para torná-lo vulnerável a ataques de phishing.
Então, aqui estão todas as técnicas que os invasores usaram para contornar as senhas (até agora).
Ataques de downgrade
Ataques de downgrade são o método usado pelos invasores para contornar a MFA resistente a phishing. A funcionalidade de downgrade de MFA foi observada em vários kits AitM criminosos e é possível até mesmo usando kits de commodities como o Evilginx.
Ao realizar um ataque de phishing Attacker-in-the-Middle, o invasor não precisa retransmitir 100% das mensagens com precisão. Em vez disso, eles podem alterar alguns deles. O aplicativo pode perguntar ao usuário “Você precisa fazer MFA – deseja usar sua chave de acesso ou seu código de autenticador de backup?”, mas o site de phishing pode modificar esta página para dizer “Você precisa MFA – use seu código de autenticador de backup” não dando a você a opção de usar sua senha segura. Isso é chamado de ataque de downgrade.
Isso também pode ser aplicado a contas que usam o SSO como método de login padrão. Nesse cenário, o kit de phishing pode selecionar uma opção de nome de usuário e senha de backup para permitir que o ataque de phishing prossiga.
Aqui está um exemplo de Evilginx com um phishlet personalizado para fazer downgrade da autenticação de uma conta da Microsoft usando o Windows Hello.
Portanto, você tem uma situação em que, mesmo que exista um método de login resistente a phishing, a presença de um método de backup menos seguro significa que a conta ainda está vulnerável a ataques de phishing.
Phishing de código de dispositivo
Para contornar os métodos de autenticação resistentes a phishing, os invasores também estão usando Phishing de código de dispositivo ataques que aproveitam fluxos de autenticação alternativos para dispositivos que não oferecem suporte a logins baseados em senha, por exemplo, porque não têm navegadores da Web ou têm recursos de entrada limitados.
Esse fluxo de login alternativo opera fornecendo a um usuário um código exclusivo e instruindo-o a visitar uma página da Web em um navegador em um dispositivo diferente para inserir o código a fim de autorizar o dispositivo.
Isso pode ser usado por um adversário para realizar um ataque de phishing contra um alvo, convencendo-o a visitar o site do provedor de autenticação e inserir um código fornecido pelo adversário, concedendo acesso à sua conta.
Esse ataque tem a vantagem de vincular o alvo a um URL legítimo, sem solicitar permissão explícita além de inserir o código do dispositivo e fazer login. Além disso, os aplicativos verificados podem ser representados em alguns casos.
Essa técnica foi observada em várias campanhas recentes, incluindo o direcionamento repetido de contas do M365 patrocinado pela Rússia (1) (2).
Phishing de consentimento
Phishing de consentimento foi uma das primeiras técnicas adicionadas ao Matriz de ataques SaaS e já existe há algum tempo, mas com um recente aumento na atividade maliciosa.
O OAuth permite que os usuários concedam permissões a aplicativos de terceiros para acessar seus dados. Os adversários podem abusar dessa funcionalidade enganando os usuários para que autorizem o acesso de aplicativos OAuth maliciosos.
Em um ataque de phishing de consentimento, um adversário envia um link de phishing para um alvo que solicita permissões para acessar dados confidenciais ou permissões para executar ações perigosas. Se o alvo conceder consentimento para as permissões, o adversário obterá esse nível de acesso sobre a conta do alvo. Esse nível de acesso ignorará a MFA e persistirá por meio de alterações de senha.
O phishing de consentimento é mais comumente associado a ataques destinados a obter acesso a locatários do Microsoft Azure ou do Google Workspace. No entanto, tornou-se mais comum que os aplicativos SaaS implementem suas próprias APIs autenticadas por OAuth e lojas de aplicativos que podem ser direcionadas da mesma maneira — como visto neste exemplo recente direcionado a usuários do GitHub.
Uma vez autorizado, o invasor tem amplo acesso à conta. Neste exemplo que afeta o GitHub, o invasor seria capaz de modificar repositórios para realizar mais ataques contra usuários (por exemplo, infectando-os com malware), envenenar os repositórios e serviços conectados ao repositório e exfiltrar todos os dados confidenciais aos quais a conta tem acesso.
Phishing de verificação
A verificação de e-mail às vezes é usada como controle, como ao registrar novas contas. Isso geralmente é implementado enviando um e-mail ao usuário-alvo com um link clicável para ele verificar ou um código de verificação que ele precisa inserir.
Phishing de verificação é quando um adversário usa phishing, ou algum outro tipo de engenharia social, para convencer um usuário a clicar em um link de verificação ou passar o código de verificação para burlar esse controle.
Um exemplo dessa técnica sendo usada para ignorar a MFA é com representação entre IdP. É aqui que um invasor simplesmente registra uma nova conta IdP no domínio de e-mail corporativo da vítima. Em muitos casos, isso permite que você faça login via SSO usando o novo IdP sem nenhuma verificação adicional – na verdade, 3 em cada 5 aplicativos permitiram esse comportamento.
Quando você considera o grande número de aplicativos que podem funcionar como um IdP para fins de SSO, há alguns destinos possíveis (dependendo do aplicativo e dos métodos de login compatíveis).
Os IdPs gerenciados podem ser administrados centralmente pela organização (que possui e opera o IdP e as identidades nele), enquanto os IdPs “sociais” não gerenciados são controlados pelo fornecedor e as identidades são de propriedade e administradas pelo usuário.
Você pode ver um exemplo disso no vídeo abaixo, ou Leia uma análise de dois exemplos selvagens aqui.
Phishing de senha específica do aplicativo
Phishing de senha específica do aplicativo é uma técnica de engenharia social em que um adversário engana um usuário para gerar uma “senha específica do aplicativo” para sua conta e compartilhá-la com o invasor. Essas senhas herdadas são um recurso em alguns dos principais provedores de SaaS (como Google e Apple) projetado para permitir que aplicativos mais antigos que não dão suporte à autenticação moderna (como OAuth 2.0) acessem dados da conta.
O fluxo de ataque normalmente envolve um pretexto em que o invasor, se passando por uma entidade confiável (por exemplo, suporte técnico, um provedor de serviços), direciona o usuário para as configurações de segurança de sua conta. O usuário é então guiado pelo processo de criação de uma nova senha específica do aplicativo e é instruído a colar essa senha em um formulário ou janela de bate-papo controlada pelo invasor.
Como as senhas específicas do aplicativo são projetadas para uso em ambientes que não oferecem suporte à MFA, uma vez que o invasor possui essa senha, ele pode obter acesso programático persistente aos dados da conta do usuário (por exemplo, e-mails, contatos, arquivos) por meio de APIs, geralmente sem disparar o mesmo nível de alertas de segurança que um login interativo tradicional de um dispositivo não reconhecido.
Isso torna o acesso mais furtivo e durável do que um token de sessão, pois essas senhas normalmente permanecem válidas até serem revogadas manualmente pelo usuário.
Um exemplo recente disso foi divulgado onde um especialista em operações de informação russas foi alvo de um ataque de engenharia social sofisticado e personalizado, onde o invasor foi capaz de estabelecer acesso persistente à caixa de correio da vítima usando ASPs fazendo login em um cliente de e-mail.
Isso envolvia uma isca sofisticada que se passava pelo Departamento de Estado dos EUA, instruindo a vítima sobre como criar e compartilhar um ASP com o invasor, concedendo acesso à caixa de correio do Google.
Bônus: segmentação de contas locais que não usam chaves de acesso
Possivelmente, a maneira mais fácil de contornar as senhas, no entanto, é segmentar aplicativos que o fazemnão suporta senhas nativamente. As chaves de acesso são normalmente usadas em combinação com o SSO, onde você faz login no seu provedor de IdP principal com um login seguro e protegido por chave de acesso e, em seguida, nos aplicativos conectados via SSO. Muitos aplicativos não permitem logins de chave de acesso diretamente.
Como resultado, aplicativos como Slack, Mailchimp, Postman, GitHub e outros aplicativos de negócios comumente usados estão sendo cada vez mais direcionados diretamente, ignorando os IdPs (MS, Google, Okta etc.) que normalmente têm controles de autenticação mais robustos.
Assim como os métodos de MFA de backup geralmente são registrados junto com as senhas, “login fantasma” geralmente são registrados junto com o SSO, o que significa que as contas têm vários pontos de entrada possíveis.
Em muitos casos, eles não têm MFA implantada — tornando-os igualmente suscetíveis a ataques usando credenciais roubadas (como visto no Floco de neve ataques no ano passado, e Jira ataques este ano).
Isso resulta em um Superfície de ataque de identidade vasta e vulnerável para as organizações gerenciarem.
Conclusão
Na maioria das vezes, os invasores não precisam fazer nada diferente para contornar as senhas. Simplesmente usar as mesmas ferramentas e técnicas de phishing que eles geralmente aplicam fará o trabalho no caso provável de um método MFA de backup e sem chave de acesso ser registrado na conta.
As únicas contas que são realmente seguras são aquelas com apenas senhas e sem métodos de backup OU políticas de acesso condicional que impedem a autenticação sem chave de acesso.
Mas o diabo está nos detalhes aqui também (como Este exemplo recente de modelos de autoridade de certificação fornecidos pela Microsoft definindo entradas “arriscadas” como falsos positivos e permitindo que elas prossigam).
E auditar seu aplicativo e a expansão de identidade não é tarefa fácil quando você considera os vários níveis de visibilidade e controle disponíveis para as equipes de segurança por aplicativo (e o fato de que muitos aplicativos simplesmente não são adotados centralmente ou conhecidos para começar).
Previna e intercepte ataques de phishing com o Push Security
Os ataques de downgrade usando kits de phishing AitM constituem a grande maioria dos ataques de phishing que ignoram a chave de acesso.
A plataforma de segurança baseada em navegador da Push Security fornece recursos abrangentes de detecção e resposta a ataques de identidade contra técnicas como phishing AitM, preenchimento de credenciais, pulverização de senhas e sequestro de sessão usando tokens de sessão roubados.
Você também pode usar o Push para encontrar e corrigir vulnerabilidades de identidade em todos os aplicativos que seus funcionários usam, como: logins fantasmas; lacunas de cobertura de SSO; lacunas de MFA; senhas fracas, violadas e reutilizadas; integrações OAuth arriscadas; e muito mais.
Se você quiser saber mais sobre como o Push ajuda você a detectar e derrotar técnicas comuns de ataque de identidade, Reserve algum tempo com um membro da nossa equipe para uma demonstração ao vivo.
Patrocinado e escrito por Segurança Push.