Educated Manticore usa phishing com `React` e `WebSocket` contra acadêmicos de tecnologia em Israel

Campanha associada ao Irã mira especialistas de cibersegurança e ciência da computação com convites falsos, páginas de autenticação para Gmail, Outlook e Yahoo e coleta em tempo real de senhas e códigos de MFA.

Componente	Infraestrutura de phishing atribuída ao grupo Educated Manticore, com kits React para Gmail, Outlook e Yahoo e uso de páginas intermediárias no sites.google.com.
Vetor	Spear-phishing por e-mail e WhatsApp, com personagens falsos ligados a empresas de cibersegurança, convites para reuniões e redirecionamento posterior para páginas de autenticação controladas pelo atacante.
Impacto	Roubo de credenciais, captura de códigos de MFA, suporte a retransmissão de 2FA e registro de teclas digitadas mesmo quando o formulário não é enviado.
Prioridade	Bloquear domínios e subdomínios associados, investigar sessões de identidade após convites suspeitos, invalidar tokens e reforçar verificação fora de banda antes de reuniões com novos contatos.
Artefatos	Arquivo main.a184cc65.js, backend https://idea-home[.]online:8569, endpoints /info/param, /key/send e /sessions, rotas como yh_signin, yh_password e yh_enter_code.
IoCs	Mais de 130 domínios e subdomínios foram usados desde janeiro de 2025, com resolução para cerca de uma dúzia de endereços IP e registro predominante via NameCheap; a lista completa de domínios não foi incluída no material analisado.

Resumo técnico

O grupo iraniano Educated Manticore, também relacionado por diferentes comunidades de inteligência aos nomes APT42, Charming Kitten e Mint Sandstorm, conduziu uma nova fase de operações de spear-phishing contra alvos israelenses de alto valor. A atividade se concentrou em professores, pesquisadores e especialistas reconhecidos de cibersegurança e ciência da computação ligados a universidades israelenses. A campanha usa a credibilidade de empresas de cibersegurança como isca social: os operadores se apresentam como funcionários fictícios, assistentes ou contatos profissionais interessados em reuniões urgentes, aproveitando o ambiente de tensão entre Irã e Israel para pressionar a vítima a responder rapidamente.

A operação mantém o padrão histórico do grupo de buscar acesso a contas pessoais e profissionais por meio de engenharia social persistente. A primeira mensagem normalmente não contém link, o que reduz a chance de bloqueio automático por filtros de e-mail e mensagens. Depois que a vítima responde, os operadores pedem endereço de e-mail, conduzem a conversa por e-mail ou WhatsApp e só então enviam um link de reunião ou autenticação. Esse encadeamento permite personalizar a página falsa com o e-mail da vítima, aumentar a credibilidade visual do fluxo e preparar o roubo de senha, token de MFA e demais entradas digitadas no navegador.

A infraestrutura técnica combina páginas intermediárias, kits de phishing em React, roteamento no lado do cliente, comunicação assíncrona com APIs e conexão persistente por WebSocket. O kit não depende de submissões clássicas de formulário nem de recarregamento completo de página; ele renderiza etapas de autenticação dinamicamente conforme o estado da sessão e instruções retornadas pelo backend. Essa arquitetura permite que o operador acompanhe a vítima em tempo real, capture caracteres antes do envio do formulário e redirecione a sessão para telas específicas durante a tentativa de comprometimento.

Fluxo técnico

A etapa inicial é uma abordagem direcionada por e-mail ou WhatsApp. Os operadores criam personas compatíveis com o círculo profissional dos alvos, incluindo supostos contatos de empresas de cibersegurança, jornalistas, pesquisadores ou assistentes de executivos de tecnologia. Em alguns casos, a escrita formal, a estrutura organizada e a gramática sem erros indicam provável uso de auxílio automatizado para compor mensagens convincentes. Mesmo assim, inconsistências nos nomes usados no corpo da mensagem e no remetente foram observadas, como variações ortográficas entre a assinatura e a conta de envio, o que constitui sinal prático de falsificação de identidade.

Após estabelecer interação, o atacante solicita o endereço de e-mail da vítima antes de enviar o link. Esse dado é usado para pré-preencher a página de autenticação falsa, reproduzindo a experiência de login esperada em serviços como Google. Em uma amostra, o arquivo main.a184cc65.js carrega a interface visível do kit e se comunica com o backend https://idea-home[.]online:8569. Ao iniciar o fluxo, o navegador envia uma requisição POST para /info/param com informações da conexão da vítima. O servidor responde com uma configuração específica da tarefa, incluindo a tela a ser exibida e o endereço de e-mail que deve aparecer no formulário.

A coleta ocorre em múltiplas etapas. Cada senha, código de MFA ou dado digitado em uma etapa de autenticação é enviado por POST para /key/send. Além disso, o kit abre uma conexão persistente em /sessions logo no carregamento da página. Essa sessão por WebSocket transporta eventos em tempo real e inclui um keylogger passivo, marcando eventos de tecla com d: "kl". O resultado técnico é mais perigoso do que uma página de phishing estática: mesmo que a vítima perceba a fraude e abandone o formulário antes de clicar em enviar, caracteres já digitados podem ter sido transmitidos ao operador.

A campanha também usa páginas intermediárias no sites.google.com para aproveitar a reputação do domínio do Google. Essas páginas simulam convites ou telas relacionadas ao Google Meet e exibem uma imagem rígida com versões adaptadas para desktop, tablet e telefone. Ao clicar na imagem, a vítima é redirecionada para a infraestrutura do atacante, onde ocorre a autenticação falsa. A combinação de domínio legítimo no primeiro salto, aparência de reunião profissional e login pré-preenchido reduz a fricção psicológica e dificulta a decisão do usuário no momento da interação.

Superfície afetada

A superfície exposta envolve principalmente contas de identidade e comunicação usadas por pessoas com acesso a redes sensíveis, contatos estratégicos ou informações de pesquisa. Os alvos descritos incluem especialistas de cibersegurança, professores de ciência da computação, jornalistas e indivíduos em setores de governo, defesa, pesquisa, mídia e políticas públicas. O risco não se limita à conta pessoal comprometida: uma caixa de e-mail tomada pode permitir leitura de conversas antigas, descoberta de documentos, pivôs para contatos confiáveis, redefinição de senhas em serviços associados e criação de novas mensagens de phishing a partir de uma identidade legítima.

Os kits observados suportam fluxos de autenticação para Google/Gmail, Outlook e Yahoo. O kit de Gmail usa React Router para alternar telas sem recarregar a página, enquanto o kit de Yahoo emprega identificadores de rota com prefixo yh_, como yh_signin, yh_password e yh_enter_code. O kit de Outlook segue lógica semelhante, mas identifica internamente as etapas com valores como page: "out_signin", page: "out_2FA_email" e page: "out_authenticator_app". A existência de variações por provedor indica um conjunto operacional voltado a contas amplamente usadas em ambientes acadêmicos, jornalísticos e profissionais.

A infraestrutura em uso desde janeiro de 2025 inclui mais de 130 domínios e diversos subdomínios, com resolução para cerca de uma dúzia de endereços IP. Muitos domínios foram registrados via NameCheap. Endereços IP mais antigos do agrupamento coincidem com impressões públicas associadas ao subcluster GreenCharlie, tratado como parte do ecossistema operacional de Educated Manticore. Essa rotação de domínios e subdomínios reduz a vida útil de bloqueios simples por URL única e exige correlação por padrões de registro, hospedagem, certificados, caminhos de API, arquivos JavaScript e comportamento de sessão.

• Contas Google, Outlook e Yahoo usadas por acadêmicos, pesquisadores, jornalistas e especialistas de cibersegurança.
• Conversas iniciadas por e-mail ou WhatsApp que evoluem para link de reunião, Google Meet falso ou página de login pré-preenchida.
• Ambientes em que contas pessoais e profissionais compartilham contatos, documentos, convites de reunião ou canais de recuperação de senha.
• Infraestrutura com domínios recentes, subdomínios numerosos, backend em portas não usuais e APIs como /info/param, /key/send e /sessions.

Hunting e telemetria

A investigação deve começar por eventos de identidade e navegação relacionados a convites recebidos de contatos novos ou não verificados. Em provedores de e-mail corporativo, procure mensagens que simulem pedidos de reunião com linguagem urgente, menções a tensões geopolíticas, identidades de empresas de cibersegurança e divergência entre o nome exibido, assinatura e endereço do remetente. Em dispositivos de usuários sensíveis, a navegação para páginas no sites.google.com seguida de redirecionamento para domínios recém-registrados é um sinal de interesse, principalmente quando ocorre antes de eventos de login suspeitos ou prompts de MFA inesperados.

Em proxy, DNS, EDR e NDR, a telemetria deve destacar conexões para domínios desconhecidos usando caminhos de API consistentes com o kit. Requisições POST para /info/param e /key/send, abertura de WebSocket em /sessions e carregamento de arquivo JavaScript minificado como main.a184cc65.js formam uma sequência comportamental mais robusta do que a busca por um único domínio. Como o kit opera como SPA, a ausência de múltiplos carregamentos de página durante uma suposta autenticação não reduz o risco; ao contrário, a troca de telas pode ocorrer inteiramente no cliente com atualização de estado via JavaScript.

Em logs de identidade, sinais relevantes incluem autenticações bem-sucedidas logo após falhas incomuns, MFA aprovado a partir de localidade, ASN, dispositivo ou navegador atípico, criação de novas sessões persistentes e acesso subsequente a e-mail, contatos, documentos ou regras de encaminhamento. Como a campanha pode capturar códigos de 2FA em tempo real, aprovações recentes de MFA não devem ser tratadas como prova suficiente de legitimidade. Para contas de alto valor, a análise precisa incluir tokens ativos, dispositivos lembrados, aplicativos conectados via OAuth, regras de caixa postal e eventos de recuperação de conta.

• Mensagem inicial sem link que evolui para solicitação de endereço de e-mail e envio posterior de URL de reunião ou autenticação.
• Acesso a sites.google.com seguido por domínio externo não reconhecido em curto intervalo de tempo.
• Requisições POST para /info/param ou /key/send e conexão WebSocket para /sessions em infraestrutura desconhecida.
• Eventos de MFA aprovados perto de conversas por WhatsApp ou e-mail com contatos recém-criados.
• Login em conta Google, Outlook ou Yahoo a partir de infraestrutura, dispositivo ou localização incompatível com o padrão do usuário.

Mitigação

A resposta deve priorizar usuários com maior exposição a contatos externos e temas sensíveis. Para esses perfis, convites de reunião enviados por pessoas desconhecidas devem ser validados por canal independente antes de qualquer autenticação. Links recebidos por WhatsApp ou e-mail não devem ser usados para login quando a reunião também puder ser acessada por abertura manual do serviço oficial no navegador. O endereço digitado no navegador, o domínio final após redirecionamentos e a presença de prompts de senha ou MFA fora do fluxo esperado precisam ser avaliados antes da inserção de credenciais.

No controle técnico, organizações devem bloquear domínios identificados, monitorar registros recentes com nomes semelhantes a serviços de reunião ou empresas de cibersegurança e criar detecções comportamentais para o encadeamento sites.google.com mais redirecionamento externo. Gateways, navegadores gerenciados e soluções de proteção de identidade devem impedir submissão de credenciais corporativas em domínios não autorizados. Para contas com alto valor operacional, chaves de segurança resistentes a phishing, políticas de acesso condicional, validação por dispositivo gerenciado e restrição de sessões reduzem a eficácia de retransmissão de MFA.

Quando houver suspeita de interação com o kit, a contenção deve assumir que senha, código temporário e caracteres parcialmente digitados foram expostos. A ação correta inclui revogar sessões, invalidar tokens, trocar senha a partir de dispositivo confiável, revisar métodos de MFA, remover aplicativos OAuth desconhecidos e examinar regras de encaminhamento ou delegação de caixa postal. Em seguida, a equipe deve preservar mensagens, URLs, registros de DNS, capturas de proxy e logs de identidade para correlacionar a tentativa com outras abordagens contra contatos da mesma instituição.

A prevenção também depende de orientação específica para pesquisadores, professores, executivos técnicos e jornalistas. Treinamentos genéricos sobre links suspeitos são insuficientes contra uma campanha que começa sem link e usa conversa persuasiva antes da entrega da URL. O procedimento deve definir como confirmar reuniões com novas identidades, como reportar convites recebidos por mensageria pessoal, como encaminhar artefatos para análise sem clicar novamente e como tratar pedidos de autenticação em páginas abertas a partir de convites externos.

• Revogar sessões e tokens de contas que interagiram com páginas suspeitas, mesmo quando o usuário afirma não ter enviado o formulário.
• Habilitar MFA resistente a phishing para usuários de alto valor, com preferência por chaves de segurança vinculadas ao domínio legítimo.
• Criar alertas para /info/param, /key/send, /sessions, main.a184cc65.js e redirecionamentos de sites.google.com para domínios recentes.
• Revisar aplicativos OAuth, métodos de recuperação, regras de encaminhamento e dispositivos lembrados nas contas afetadas.
• Estabelecer validação fora de banda para reuniões solicitadas por novos contatos que usem identidade de empresa de cibersegurança, mídia ou pesquisa.