Hack Alerta

Campanha de phishing com Graph API visa funcionários de RH e folha de pagamento

Campanha de cibercrime utiliza ferramentas legítimas da Microsoft para alvos de RH e folha de pagamento, desviando salários via phishing AiTM e Graph API.

Introdução

Uma campanha de cibercrime sofisticada tem sido identificada por equipes de segurança, utilizando ferramentas legítimas da Microsoft para alvos específicos dentro de corporações. O ataque foca em funcionários de recursos humanos e folha de pagamento, com o objetivo de desviar salários para contas controladas por criminosos. A técnica explora a confiança inerente nas APIs de gerenciamento de identidade, permitindo que os atacantes operem sem deixar rastros tradicionais em endpoints.

Descoberta e escopo da campanha

A operação, vinculada aos clusters de ameaças Storm-2755 e Storm-2657, foi detalhada em relatórios recentes de inteligência de segurança. Diferente de ataques convencionais que dependem de malware ou exploração de vulnerabilidades de software, esta campanha utiliza phishing adversário-no-meio (AiTM) para interceptar sessões ativas. Uma vez que o token de sessão é capturado, ele é reutilizado para contornar a autenticação multifator (MFA) padrão, permitindo acesso direto às contas do Microsoft 365.

O vetor de ataque é particularmente preocupante porque não envolve a instalação de software malicioso nos dispositivos dos usuários. Isso significa que soluções tradicionais de detecção e resposta em endpoints (EDR) têm dificuldade em identificar a atividade maliciosa, já que o tráfego de rede e as ações ocorrem diretamente na nuvem, através de APIs legítimas.

Vetor e exploração técnica

Após o comprometimento inicial da conta, os atacantes pivotam para a Microsoft Graph API. Esta ferramenta de desenvolvedor é projetada para consultar informações de diretório, mas foi adaptada para fins maliciosos. Os criminosos executam consultas em massa para identificar usuários cujos títulos de trabalho ou nomes de exibição contenham palavras-chave como "payroll", "hr", "human", "resources", "finance" e "admin".

As consultas observadas nos ambientes comprometidos foram quase idênticas em sua estrutura. Os atacantes iniciam com uma extração em lote de todos os usuários usando o endpoint /v1.0/users?$top=999. Em seguida, aplicam filtros de pesquisa encadeados em campos como displayName, jobTitle, mail e userPrincipalName para termos relacionados à folha de pagamento. A paginação é realizada usando $skiptoken para garantir que todos os resultados sejam colhidos em lote.

Os tokens utilizados durante essa enumeração carregavam permissões delegadas amplas, incluindo Directory.Read.All, Files.ReadWrite.All, Group.ReadWrite.All, Chat.ReadWrite e User.ReadWrite. Isso concedeu aos atacantes muito mais acesso do que uma simples consulta de diretório, aumentando o risco de persistência baseada em OAuth através de aplicativos consentidos que podem sobreviver a redefinições de senha e revogação de tokens.

Evidências e limites da detecção

O tráfego de autenticação veio de intervalos de IP de operadoras móveis dos EUA, enquanto o tráfego de enumeração do Graph rastreou de volta para provedores de internet residenciais canadenses. Essa divisão é consistente com a infraestrutura de proxy residencial usada para mascarar a operação. Contas não remediadas continuaram gerando logins não interativos para o Office 365 Exchange Online a cada três horas, usando o user-agent Firefox 131.0 e identificadores de token rotativos em cada sessão.

Isso indica que os atacantes mantiveram acesso persistente muito tempo após o comprometimento inicial. A ausência de malware ou pegada no endpoint deixa as equipes de segurança dependentes quase inteiramente da telemetria de logon do Microsoft Entra e dos logs de atividade do Microsoft Graph para detecção.

Impacto e alcance

A campanha foi observada em ambientes de saúde, serviços alimentícios e manufatura. O objetivo final em todos os casos é o mesmo: redirecionar o depósito direto de um funcionário para uma conta bancária controlada pelo atacante. Isso é frequentemente feito entrando em contato diretamente com o RH ou modificando configurações em plataformas de RH como o Workday.

O impacto financeiro direto para as vítimas pode ser significativo, não apenas devido ao desvio de salários, mas também aos custos de resposta a incidentes, recuperação de dados e danos à reputação. Além disso, o acesso a contas de RH pode fornecer informações sensíveis sobre funcionários, facilitando ataques de engenharia social futuros.

Medidas de mitigação recomendadas

A detecção para esta campanha depende quase inteiramente da telemetria de logon do Microsoft Entra e dos logs de atividade do Microsoft Graph. A Security Risk Advisors (SRA) recomenda fortemente habilitar o log de atividade do Microsoft Graph e encaminhar esses logs para um SIEM ou data lake de segurança como o passo mais impactante que qualquer organização pode tomar.

No lado da autenticação, a implementação de MFA resistente a phishing usando chaves de segurança FIDO2, Windows Hello for Business ou autenticação baseada em certificados é crítica. Notificações push de aplicativos autenticadores padrão e códigos SMS não oferecem proteção contra o roubo de tokens AiTM. Políticas de Acesso Condicional devem ser configuradas para exigir dispositivos compatíveis ou híbridos e habilitar a avaliação contínua de acesso para cortar tokens reutilizados em tempo quase real.

Para organizações que já lidam com contas comprometidas, a remediação deve ser minuciosa. Revogar sessões e tokens de atualização através do Centro de Administração do Entra, redefinir credenciais, re-registrar métodos de MFA e auditar todas as concessões de consentimento de aplicativos empresariais são etapas necessárias. Qualquer alteração de depósito direto ou folha de pagamento feita durante a janela de comprometimento também deve ser revisada e revertida.

O que os CISOs devem fazer imediatamente

1. Habilitar Logs do Graph: Verifique se o log de atividade do Microsoft Graph está habilitado e sendo enviado para seu SIEM.

2. Revisar Permissões: Audite as permissões delegadas em aplicativos consentidos, especialmente aquelas com escopo amplo como Directory.Read.All.

3. Implementar MFA Resistente: Migre para chaves de segurança FIDO2 ou Windows Hello for Business para contas críticas de RH e Financeiro.

4. Monitorar User-Agents: Crie alertas para user-agents incomuns ou versões específicas de navegadores associadas à campanha (ex: Firefox 131.0 em contextos não interativos).

5. Verificar Alterações de Pagamento: Implemente um processo de verificação fora de banda para qualquer solicitação de alteração de dados bancários de funcionários.

Perguntas frequentes

Por que o EDR não detectou isso?
Porque o ataque ocorre inteiramente na nuvem, sem a necessidade de executar código malicioso no endpoint do usuário.

É seguro usar SMS para MFA?
Não neste contexto. O phishing AiTM intercepta o token de sessão, tornando o SMS irrelevante para a proteção contra esse vetor específico.

Como saber se minha organização foi afetada?
Analise os logs de logon do Microsoft Entra para atividades não interativas incomuns e verifique se há alterações recentes em contas de RH ou Financeiro.


Baseado em publicação original de Cyber Security News
Publicado pela Redação Hack Alerta com base em fontes externas citadas e monitoramento editorial do Hack Alerta. Para decisões técnicas, operacionais ou jurídicas, confirme sempre os detalhes na fonte original.