Operação de hack-for-hire usou engenharia social persistente, consentimento OAuth e iscas de suporte falso para tentar acessar contas de jornalistas e críticos na região MENA.
| Componente | Contas Apple e Google de jornalistas, ativistas e autoridades, com uso de LinkedIn, Apple Messages/iMessage, WhatsApp e consentimento OAuth 2.0 do Google. |
| Vetor | Spear-phishing com perfis falsos, links encurtados, páginas de verificação fraudulentas, impersonação de suporte Apple e aplicativo malicioso de consentimento associado a en-account[.]info. |
| Impacto | Tentativa de captura de credenciais e códigos de autenticação de dois fatores; em um caso, conta Apple comprometida e dispositivo virtual adicionado para manter acesso aos dados da vítima. |
| Prioridade | Revisar consentimentos OAuth, sessões e dispositivos vinculados, reforçar proteção contra phishing em contas de alto risco e caçar domínios defangados associados à campanha. |
| Artefatos | Infraestrutura mencionada inclui com-ae[.]net, encryption-plug-in-signal[.]com-ae[.]net, youtubepremiumapp[.]com e iscas relacionadas a ProSpy, ToSpy e Dracarys. |
| Alvos | Jornalistas egípcios, um jornalista libanês anônimo e indícios de vítimas ou alvos em Bahrain, Emirados Árabes Unidos, Arábia Saudita, Reino Unido, Egito e possivelmente Estados Unidos ou ex-alunos de universidades norte-americanas. |
Uma campanha de espionagem digital com características de operação de hack-for-hire mirou jornalistas, ativistas e autoridades na região do Oriente Médio e Norte da África entre 2023 e 2025. A atividade foi vinculada por análise de infraestrutura e sobreposição de famílias móveis ao ecossistema associado ao cluster Bitter, grupo historicamente relacionado a operações de coleta de inteligência. A atribuição permanece limitada: os dados sustentam uma ligação técnica com infraestrutura e padrões já associados ao Bitter, mas também deixam aberta a hipótese de um operador contratado que reutiliza, compartilha ou acessa recursos próximos ao mesmo conjunto operacional.
O foco principal da campanha foi o comprometimento de contas pessoais e profissionais em serviços Apple e Google. Dois jornalistas egípcios críticos ao governo foram alvo de ataques em outubro de 2023 e janeiro de 2024, com páginas falsas preparadas para capturar credenciais e códigos de autenticação de dois fatores. Um jornalista libanês anônimo recebeu mensagens em maio de 2025 por Apple Messages/iMessage e WhatsApp com links que simulavam uma etapa de verificação da Apple. Nesse caso, a primeira onda comprometeu completamente a conta Apple da vítima e permitiu a adição de um dispositivo virtual, mecanismo que pode manter acesso persistente a dados sincronizados sem depender de uma nova senha em cada interação.
A campanha combina engenharia social manual, identidades falsas em redes sociais, encurtadores de URL, consentimento OAuth fraudulento e páginas de login ou verificação visualmente alinhadas a serviços legítimos. Não há confirmação de que os três jornalistas citados tenham recebido spyware, mas parte da mesma infraestrutura se sobrepõe a iscas móveis usadas para entregar ProSpy e ToSpy em campanhas Android. O dado mais relevante para defesa é a convergência entre roubo de conta, persistência por dispositivo vinculado e capacidade potencial de direcionar a vítima para malware móvel conforme o sistema operacional, o idioma, o serviço usado e a resposta ao contato inicial.
No ataque contra Mostafa Al-A'sar, a aproximação começou por uma persona falsa no LinkedIn chamada Haifa Kareem, que ofereceu uma oportunidade de trabalho. Depois que a vítima compartilhou número de telefone e endereço de e-mail, recebeu uma mensagem em 24 de janeiro de 2024 instruindo a entrada em uma chamada Zoom por meio de um link encurtado pelo Rebrandly. O link não funcionava apenas como redirecionamento para uma página genérica: a análise do fluxo indicou phishing baseado em consentimento, explorando a familiaridade do usuário com o login de terceiros do Google e com telas legítimas de permissão OAuth.
A técnica de consentimento OAuth muda o ponto de falha defensivo. Em vez de depender exclusivamente de uma página falsa que coleta senha e código de autenticação, o operador tenta fazer com que a vítima autorize um aplicativo controlado pelo atacante. Se o usuário não estiver autenticado no Google, o fluxo pode solicitar credenciais; se já estiver autenticado, o elemento crítico passa a ser a concessão de permissões ao aplicativo malicioso. O nome associado ao aplicativo foi en-account[.]info, e a aparência do processo aproveita elementos conhecidos de autenticação federada, o que reduz a fricção psicológica para alvos acostumados a autorizar integrações em serviços de produtividade.
Nos ataques voltados a contas Apple, o operador impersonou suporte ou verificação de conta. As mensagens foram enviadas por canais que normalmente carregam confiança contextual, como Apple Messages/iMessage e WhatsApp, e direcionavam a vítima a links maliciosos. O objetivo era obter credenciais e códigos 2FA em tempo suficiente para assumir a sessão. No caso libanês, a consequência observada foi mais grave do que uma tentativa bloqueada: a conta Apple foi comprometida e um dispositivo virtual foi adicionado. Essa alteração deve ser tratada como persistência de identidade, porque um dispositivo vinculado pode ampliar acesso a sincronização, notificações, dados de conta e processos de recuperação, dependendo das permissões e das configurações ativas.
A campanha também possui uma camada móvel relacionada. O domínio defangado com-ae[.]net apareceu em uma campanha Android posterior documentada com sites falsos que imitavam Signal, ToTok e Botim para distribuir ProSpy e ToSpy a alvos nos Emirados Árabes Unidos. Um exemplo citado foi encryption-plug-in-signal[.]com-ae[.]net, apresentado como um suposto plugin de criptografia para Signal, inexistente no produto legítimo. O ProSpy foi descrito com capacidades de coleta de contatos, mensagens SMS, metadados do dispositivo e arquivos locais. Esse vínculo não prova que os jornalistas tenham sido infectados por spyware, mas mostra que a infraestrutura da operação não se limita a phishing de credenciais e pode suportar entrega de payload móvel quando o operador decide escalar o acesso.
A superfície de risco abrange contas de alto valor mantidas por jornalistas, defensores de direitos, opositores, ativistas e funcionários públicos, principalmente quando essas identidades usam serviços pessoais como Apple Account e Google como base de comunicação, armazenamento, autenticação e recuperação de outros serviços. O risco aumenta quando a mesma conta participa de contatos profissionais, mensagens com fontes, armazenamento de documentos, backup de dispositivos e autenticação em aplicativos de terceiros. Nesses cenários, um único consentimento OAuth malicioso ou uma sessão Apple assumida pode expor mais do que uma caixa de entrada isolada.
Os canais usados indicam seleção individual e persistência social. LinkedIn foi usado para construir uma relação inicial com pretexto profissional; WhatsApp e Apple Messages/iMessage foram usados para entrega direta de links; Telegram e Signal aparecem como plataformas potencialmente visadas por evidências de campanha. A operação não se apresenta como disparo massivo. O padrão é compatível com alvos previamente escolhidos, mensagens adaptadas e repetição de contato até que uma ação de autenticação ocorra. Essa característica torna a detecção puramente volumétrica fraca, pois os eventos podem ser poucos, espaçados e distribuídos entre serviços externos.
- Contas Apple com novos dispositivos, dispositivos virtuais ou alterações de recuperação após contato por mensagens de suporte falso.
- Contas Google com consentimentos recentes a aplicativos desconhecidos, especialmente quando o fluxo envolveu links encurtados ou convites profissionais externos.
- Usuários expostos em MENA, incluindo jornalistas egípcios e libaneses, além de possíveis alvos em Bahrain, Emirados Árabes Unidos, Arábia Saudita, Reino Unido, Egito e Estados Unidos.
- Dispositivos Android de alvos sensíveis que receberam iscas de aplicativos, plugins ou páginas imitando Signal, ToTok, Botim, Telegram, WhatsApp ou YouTube.
A caça deve começar por identidade, não por malware. Em contas Google, equipes devem revisar aplicativos OAuth autorizados, escopos concedidos, horário da concessão, origem do navegador, endereço IP de autenticação e qualquer sequência em que uma mensagem externa anteceda a permissão. O ponto crítico é diferenciar um login legítimo de uma concessão abusiva: o usuário pode ter digitado a senha corretamente e ainda assim ter entregue acesso a um aplicativo controlado pelo operador. Registros de segurança, alertas de aplicativos de terceiros e eventos de consentimento são mais úteis do que buscar apenas falhas de senha.
Em contas Apple, a prioridade é examinar dispositivos vinculados, alterações de autenticação, eventos de recuperação, notificações de login, sessões recentes e mudanças feitas logo após mensagens recebidas por iMessage ou WhatsApp. A adição de dispositivo virtual deve ser considerada um artefato de comprometimento até prova em contrário, principalmente quando a vítima recebeu uma solicitação de verificação fora do fluxo normal do serviço. A investigação deve preservar horários de mensagens, remetentes, links defangados, capturas de tela e cabeçalhos de e-mail quando houver, porque a campanha usa múltiplos canais para sustentar a mesma narrativa fraudulenta.
Na camada de rede e endpoint, a busca por indicadores deve ser seletiva e defensiva. Domínios como com-ae[.]net, encryption-plug-in-signal[.]com-ae[.]net, en-account[.]info e youtubepremiumapp[.]com devem ser tratados como exemplos defangados para correlação histórica, não como lista completa. A campanha também usa encurtadores e infraestrutura intermediária, o que exige análise de resolução, redirecionamentos, User-Agent, horário de clique e destino final. Em dispositivos Android, telemetria de instalação fora de loja oficial, permissões incomuns para SMS, contatos e arquivos, além de comunicação com endpoints associados a famílias ProSpy, ToSpy ou Dracarys, deve receber prioridade.
- Concessão OAuth recente a aplicativo desconhecido após contato por LinkedIn, e-mail, WhatsApp ou iMessage.
- Link encurtado por serviço legítimo que redireciona para consentimento Google ou página de verificação falsa.
- Novo dispositivo ou dispositivo virtual vinculado a conta Apple logo após mensagem de suposto suporte.
- Tentativas de login ou autorização em contas de jornalistas e ativistas vindas de infraestrutura não habitual.
- Instalação Android com promessa de plugin de criptografia, aplicativo de mensagens modificado ou serviço popular clonado.
- Tráfego para domínios defangados relacionados a
com-ae[.]netou infraestrutura previamente conectada a Dracarys, ProSpy e ToSpy.
A resposta deve separar três frentes: contenção de conta, revisão de dispositivos e validação de exposição móvel. Para Google, revogar aplicativos OAuth não reconhecidos, encerrar sessões, trocar senha e revisar métodos de recuperação são etapas necessárias, mas insuficientes se o consentimento abusivo não for removido. Para Apple, qualquer dispositivo desconhecido deve ser removido, sessões devem ser invalidadas e métodos de recuperação precisam ser conferidos. Em ambos os casos, a equipe deve registrar a linha do tempo do contato inicial, do clique, da autenticação e das mudanças de conta para identificar se houve acesso a conteúdo sensível.
Para usuários de alto risco, a mitigação preventiva deve reduzir a dependência de códigos 2FA reutilizáveis em fluxos phisháveis. Chaves de segurança resistentes a phishing, políticas de acesso condicional, alertas de consentimento OAuth, bloqueio ou aprovação administrativa para aplicativos de terceiros e treinamento específico sobre consentimento malicioso são controles diretamente alinhados ao caso. O treinamento genérico contra páginas falsas não cobre completamente o ataque, porque o fluxo OAuth pode exibir telas legítimas de login e permissão. A mensagem defensiva precisa enfatizar que autorizar um aplicativo desconhecido pode ser tão perigoso quanto entregar a senha.
Organizações que apoiam jornalistas, defensores de direitos e pesquisadores devem manter procedimentos curtos para verificação fora de banda quando uma mensagem pedir validação urgente de conta. O usuário deve ter canal interno para encaminhar links suspeitos sem abrir o destino, e a equipe de segurança deve conseguir expandir encurtadores em ambiente controlado, preservar evidências e acionar recuperação de conta rapidamente. Quando houver suspeita de spyware Android, a contenção deve evitar manipulação excessiva do aparelho antes da coleta forense apropriada, pois instalações, permissões e artefatos de comunicação podem ser necessários para confirmar a cadeia.
A atribuição não deve conduzir a resposta operacional mais do que a técnica observada. A ligação com Bitter, a hipótese de hack-for-hire e as sobreposições com Dracarys, ProSpy e ToSpy ajudam a priorizar ameaças e a mapear TTPs, mas a defesa imediata depende de controles de identidade, revisão de dispositivos e detecção de engenharia social direcionada. A campanha demonstra que operadores podem alternar entre roubo de credenciais, abuso de consentimento e iscas móveis conforme a superfície do alvo. A proteção efetiva exige monitorar esses caminhos como uma única cadeia de comprometimento de identidade e dispositivo.
- Revogar consentimentos OAuth desconhecidos e exigir revisão administrativa para aplicativos de terceiros em contas sensíveis.
- Remover dispositivos Apple não reconhecidos, invalidar sessões e verificar métodos de recuperação e autenticação multifator.
- Trocar senhas após revogação de sessões e consentimentos, evitando preservar acesso concedido a aplicativos maliciosos.
- Implantar autenticação resistente a phishing para jornalistas, ativistas, executivos e equipes com exposição pública.
- Correlacionar mensagens suspeitas, links encurtados, concessões de permissão e alterações de conta em uma mesma linha do tempo.
- Investigar dispositivos Android com sinais de instalação de aplicativo clonado, permissões extensivas ou comunicação com infraestrutura suspeita.
0 Comentários