Campanha de phishing EvilProxy alavanca representações convincentes de aplicativos Enterprise

Resumo Executivo

A Okta Threat Intelligence identificou uma campanha de ataque de alto volume que, segundo pesquisas subsequentes, está ativa desde pelo menos março de 2025, utilizando o kit de ferramentas EvilProxy de phishing-as-a-service (PhaaS) para executar ataques de phishing em tempo real projetados para roubar credenciais de usuários e cookies de sessão ativos. Rastreamos esta campanha como O-UNC-035.

Esta operação tem como alvo organizações em vários setores, incluindo finanças, governo, saúde e tecnologia, usando principalmente iscas altamente convincentes que se passam por ferramentas de negócios populares, como SAP Concur, e serviços de assinatura de documentos, como Adobe ou DocuSign.

Análise de Ameaças

EvilProxy Phishing-as-a-Service

EvilProxy (O-TA-041) é um kit de ferramentas PhaaS que usa uma arquitetura de proxy reverso/adversário-no-meio (AitM) para interceptar logins e cookies de sessão das vítimas em tempo real, permitindo que os invasores burlem a autenticação multifator (MFA) e sequestrem contas.

Originalmente observado em 2022 e rapidamente transformado em produto nos mercados da dark web, o EvilProxy tem sido amplamente utilizado em campanhas direcionadas de roubo da conta e Business e-mail comprometimento porque ele faz o proxy de sites legítimos. Isso significa que os usuários veem prompts de MFA reais e que o invasor é capaz de capturar tokens e cookies para que o invasor possa reproduzir. Como o EvilProxy é vendido e mantido como um serviço, ele dimensiona ataques e diminui a barreira de habilidades para criminosos: os operadores podem iniciar grandes volumes de campanhas de phishing personalizadas.

Mecanismos de atração

Observamos softwares e serviços Enterprise confiáveis sendo personificados para enganar os usuários a clicar em links e inserir credenciais:

• Serviços de assinatura de documentos (como Docusign, Adobe Acrobat, Adobe Sign, EchoSign): Um tema recorrente observado nesta campanha foi a personificação de provedores de gerenciamento de documentos e assinatura eletrônica. Os invasores utilizam a promessa de um documento compartilhado ou uma solicitação de assinatura para atrair as vítimas.
• Plataformas de despesas e aquisição (como SAP Concur, Coupa): Esta foi a isca mais frequente observada nesta campanha. Ela tem como alvo funcionários, personificando sistemas populares de gerenciamento de despesas e viagens, geralmente com prompts para aprovar um relatório ou revisar uma despesa. Uma isca mais genérica usa termos como expense, expensereport ou expensesolutions.
• Microsoft SharePoint: A campanha também tem como alvo usuários do ecossistema Microsoft 365, simulando um link para um documento compartilhado ou um site colaborativo.
• Reuniões Online: Os invasores registraram domínios genéricos que incluem palavras como "reunião" para se passar por convites para plataformas de reunião.
• KnowBe4: Os invasores se passaram por uma empresa de treinamento de conscientização de segurança, em uma tentativa de induzir os usuários visados a presumir que a isca de phishing fazia parte de um teste de phishing oficial.

Análise de código

A cadeia de redirecionamento da isca começa com um link curto, no qual o endereço de e-mail da vítima é ofuscado dentro do caminho do URL. O usuário é então redirecionado por meio de um redirecionador com a marca da empresa-alvo no subdomínio e, finalmente, chega a uma página de phishing convincente com a marca Microsoft que rouba credenciais. O JavaScript no redirecionador extrai o e-mail do caminho, recodifica-o e cria um URL de redirecionamento personalizado que carrega essa identidade em cada salto.

Exemplo 1 de cadeia HTTP

Link Inicial:

hxxps[://]expensereport[.]ch/[coded_string]

Redirecionador:

hxxps[://][company][.]sapconcur[.]sa[.]com/expense/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[t]

URL final (mostrando o site de login para a coleta de credenciais):

hxxps[://][32_characters_string][.]laurimarierefling[.]com/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[token]&[string_7_characters]=[string_32_characters]

Exemplo 2 de cadeia HTTP

Link Inicial:

hxxps[://]sapconcursolutions[.]pl/[coded_string]

Redirecionador:

hxxps[://][company][.]sapconcur[.]sa[.]com/expense/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[t]

URL final (mostrando o site de login para coleta de credenciais):

hxxps[://][32_characters_string][.]concurmgt[.]pl//?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[token]&[string_7_characters]=[string_32_characters]

Como o redirecionador decodifica e personaliza a vítima

As páginas de phishing aceitam o último segmento de caminho e tentam o uso de vários decodificadores em sequência - mapeamento de token personalizado, hex, Base32 e Base64 - até que o resultado contenha "@". Esse valor se torna o e-mail da vítima para uso downstream, como visto neste exemplo de código de página de isca inicial:

let encodedValue = window.location.pathname.split('/').pop();
...
e-mail = decodeEmail(encodedValue); // custom tri-gram map
...
if (!decodingSuccessful && isHexadecimal(encodedValue)) e-mail = hexToString(encodedValue);
if (!decodingSuccessful && isBase32(encodedValue)) e-mail = base32ToString(encodedValue);
if (!decodingSuccessful && isBase64(encodedValue)) e-mail = base64ToString(encodedValue);

O decodificador personalizado substitui tokens de três caracteres de volta em caracteres, usando um mapa como:

const encodingMap = {
    "@":"MN3",".":"OP4","a":"QR5","e":"ST6","i":"UV7",
    "o":"WX8","u":"YZ9","s":"ABO","n":"CD1","r":"EF2",
    "d":"GH3","I":"JK4"
};

Portões anti-análise

Antes de redirecionar, o script tenta evitar rastreadores e sandboxes:

function isBot() {
    const botPatterns = ['bot','spider','crawl','slurp','baidu','yandex',
        'wget','curl','lighthouse','pagespeed','prerender','screaming frog',
        'semrush','ahrefs','duckduckgo'];
if (navigator.webdriver || navigator.plugins.length === 0 ||
    navigator.languages === "" || navigator.languages === undefined)
return true;
...
}

Se um sinal de bot/headless for encontrado - ou se a organização "bloqueada" do operador aparecer - a página redireciona diretamente para o login legítimo da Microsoft, dando às equipes de triagem uma página limpa enquanto os usuários reais continuam no phish. O serviço api.ipify.org é usado para retornar o endereço IP público da vítima, para comparar com uma lista de bloqueio de IP/faixa.

Domínios bloqueados

O código também contém dois domínios bloqueados que, se encontrados no endereço de e-mail da vítima, farão com que o fluxo de phishing saia em vez de ir para a página de login autêntica da Microsoft:

const blockedDomains = ['belfius', 'baringa'];
const emailDomain = email.split('@')[1].toLowerCase();

for (const blocked of blockedDomains) {
    if (emailDomain.startsWith(blocked)) {
        window.location.href = "https://login.microsoftonline.com/common/login";
return;
    }
}

A proveniência do bloqueio desses dois domínios é desconhecida. O domínio "belfius" parece se referir a um banco belga, enquanto "baringa" parece estar associado a uma consultoria de gestão do Reino Unido.

Parâmetros de consulta

Em todas as amostras observadas, o redirecionador cria o mesmo URL parametrizado e apenas a família de domínio varia. Dois parâmetros são o e-mail da vítima em diferentes invólucros; o restante são nonces mais um timestamp:

• uid → Base64(e-mail)
  • Pode ser decodificado usando uma receitado CyberChef
• hid → hex(Base64(e-mail))
  • Pode ser decodificado usando uma receitado CyberChef
• document, token → IDs aleatórios (semelhantes a nonce)
• t → Unix timestamp (ms)
  • Pode ser convertido para uma data legível usando a receitado CyberChef

fluxo de autenticação

Dentro do fluxo de autenticação, o nome da empresa personificada aparece em certos campos do redirecionador e do URL final. Além disso, a estrutura de phishing preenche automaticamente o endereço de e-mail da vítima no campo de nome de usuário da página de phishing.

Link inicial:

hxxps[://]expensereport[.]ch/616c6578616e6465722e652e6261754073662e6672622e6f7267

Redirecionador:

hxxps[://]sf[.]sapconcur[.]sa[.]com/expense/?uid=...&hid=...&document=...&token=...&t=...

URL Final

hxxps[://]299afcb76fac4238a0facad80c326230[.]concursolutions[.]asia/?uid=...&hid=...
&document=...&token=...&t=...&u9pPUdqL=...

resposta a ameaças

O que estamos fazendo:

Estamos ativamente engajados nas seguintes atividades para mitigar essa ameaça:

• Monitoramento contínuo de domínios de phishing e infraestrutura recém-registrados associados a esta campanha.
• Apresentar proativamente relatórios de abuso a registradores e provedores de hospedagem relevantes para iniciar solicitações de remoção para sites maliciosos identificados.
• Fornecer orientação e assistência às organizações para aprimorar a segurança de seus ambientes Okta e ajudá-las a investigar qualquer atividade suspeita relacionada a contas potencialmente comprometidas.

Controles Protetores

Recomendações para clientes

• Registre os usuários em autenticadores fortes, como Okta FastPass, FIDO2 WebAuthn e cartões inteligentes, e aplique a resistência ao phishing na política.
• As políticas de acesso de aplicativos Okta (anteriormente "políticas de autenticação") também podem ser usadas para restringir o acesso a contas do usuário com base em uma variedade de pré-requisitos configuráveis pelo cliente. Recomendamos que os administradores restrinjam o acesso a aplicativos confidenciais a dispositivos gerenciados por ferramentas de Endpoint Management e protegidos por ferramentas de segurança de endpoint. Para acesso a aplicativos menos confidenciais, exija dispositivos registrados (usando Okta FastPass) que exibam indicadores de higiene básica.
• Negue ou exija maior garantia para solicitações de redes raramente usadas. Com o Okta Network Zones, o acesso pode ser controlado por local, ASN (Número do Sistema Autônomo), IP e tipo de IP (que pode identificar proxies de anonimato conhecidos).
• As avaliações de Comportamento e Risco da Okta podem ser usadas para identificar solicitações de acesso a aplicativos que se desviam de padrões de atividade do usuário estabelecidos anteriormente. As políticas podem ser configuradas para aumento de nível ou negar solicitações usando este contexto.
• Treine os usuários para identificar indicadores de e-mails suspeitos, sites de phishing e técnicas comuns de engenharia social usadas por invasores. Facilite para os usuários relatarem problemas potenciais, configurando as Notificações para o Usuário Final e o Relatório de Atividade Suspeita.
• Documente, divulgue e siga um processo padronizado para validar a identidade de usuários remotos que entram em contato com o pessoal de suporte de TI e vice-versa.
• Adote uma abordagem de "Zero privilégios permanentes" para o acesso administrativo. Atribua aos administradores Funções de Administrador Personalizadas com as permissões mínimas necessárias para as tarefas diárias e exija autorização dupla para acesso JIT (just-in-time) a funções mais privilegiadas.
• Aplique o IP Session Binding a todos os aplicativos administrativos para impedir a reprodução de sessões administrativas roubadas.
• Habilite as Protected Actions para forçar a reautenticação sempre que um usuário administrativo tentar executar ações confidenciais.

Observando e respondendo à infraestrutura de phishing:

• Revise os registros de aplicativos (logs Okta, web proxies, sistemas de e-mail, servidores DNS, firewalls) para qualquer evidência de comunicação com quaisquer domínios suspeitos.
• Monitore os domínios regularmente para ver se o conteúdo muda.

Se o conteúdo hospedado no domínio violar direitos autorais ou marcas legais, considere fornecer evidências e emitir uma solicitação de remoção com o registrador de domínio e/ou provedor de hospedagem na web.