Campanha ligada ao Irã mira Microsoft 365 em Israel com pulverização de senhas

Campanha ligada ao Irã mira Microsoft 365 em Israel com pulverização de senhas

A atividade atingiu mais de 300 organizações israelenses e mais de 25 nos Emirados Árabes Unidos, usando nós de saída Tor, VPN comercial e tentativas distribuídas de autenticação contra ambientes em nuvem.

ComponenteAmbientes Microsoft 365 de organizações em Israel, Emirados Árabes Unidos e um conjunto menor de alvos na Europa, Estados Unidos, Reino Unido e Arábia Saudita.
VetorPulverização de senhas e tentativas de autenticação distribuídas a partir de nós de saída Tor e nós de VPN comercial hospedados no AS35758.
ImpactoA campanha buscava validar credenciais fracas em escala e, em fases posteriores, acessar contas Microsoft 365 para obter conteúdo sensível de caixas de correio.
PrioridadeRevisar logs de entrada do Microsoft 365, aplicar MFA para todos os usuários, restringir acesso por políticas condicionais e manter auditoria habilitada para investigação pós-comprometimento.
SetoresEntidades governamentais, municípios, tecnologia, transporte, energia e empresas privadas da região foram citados como alvos.
Linha do tempoTrês ondas de atividade foram observadas em 3, 13 e 23 de março de 2026.
Resumo técnico

Uma campanha atribuída a um ator com nexo iraniano mirou ambientes Microsoft 365 em Israel e nos Emirados Árabes Unidos por meio de pulverização de senhas, uma técnica de força bruta que troca volume agressivo contra uma única conta por tentativas controladas contra muitas identidades. O objetivo técnico é testar senhas comuns em larga escala sem concentrar falhas de autenticação em um único usuário, reduzindo a chance de acionar defesas simples baseadas apenas em bloqueio por conta. A atividade foi descrita como ainda em andamento e organizada em três ondas observadas em 3, 13 e 23 de março de 2026.

O escopo informado é significativo para operações de defesa em nuvem: mais de 300 organizações em Israel e mais de 25 nos Emirados Árabes Unidos foram impactadas, com observações adicionais contra um número limitado de alvos na Europa, Estados Unidos, Reino Unido e Arábia Saudita. Os alvos citados incluem órgãos governamentais, municípios, empresas de tecnologia, transporte, energia e organizações privadas. A concentração regional, combinada com o uso de infraestrutura de anonimização e VPN comercial, aponta para uma campanha de coleta de acesso e inteligência voltada a ambientes Microsoft 365, e não para uma exploração de vulnerabilidade específica em produto.

A atividade apresenta semelhanças com operações associadas anteriormente ao grupo Gray Sandstorm, incluindo o uso de ferramentas de red team e tráfego originado de nós de saída Tor. Também há referência ao uso de nós de VPN comercial hospedados no AS35758, infraestrutura alinhada a operações recentes vinculadas ao Irã no Oriente Médio. A atribuição deve ser tratada como avaliação de inteligência: o dado relevante para defesa é que o comportamento observado combina pulverização de senhas, autenticação em nuvem, anonimização de origem e busca por conteúdo de caixas de correio.

Fluxo técnico

A cadeia descrita começa com varredura agressiva ou pulverização de senhas a partir de nós de saída Tor. Nessa fase, o operador tenta validar combinações de usuários e senhas comuns contra o mesmo serviço, distribuindo tentativas para evitar padrões triviais de bloqueio. Em ambientes Microsoft 365, esse tipo de abuso costuma aparecer como múltiplas falhas de entrada contra várias contas, muitas vezes com alta diversidade de endereços de origem, user agents inconsistentes e tentativas fora do perfil geográfico normal da organização. O material analisado não indica exploração de falha no Microsoft 365; o vetor é autenticação abusiva com credenciais fracas ou reutilizadas.

A segunda fase envolve o processo de login quando uma combinação válida é encontrada. Esse ponto é crítico porque a autenticação bem-sucedida pode não gerar alerta se a organização depende apenas de senha, se MFA não está aplicado de forma universal ou se políticas condicionais permitem origens anômalas. A terceira fase mencionada é a coleta de dados sensíveis, incluindo conteúdo de caixas de correio. Para equipes de defesa, isso desloca a análise de simples bloqueio de força bruta para investigação de possível acesso a mensagens, regras de caixa postal, tokens de sessão, alterações de métodos de autenticação e atividade de leitura ou exportação incomum.

O uso de Tor e VPN comercial muda a leitura operacional dos logs. Um único país de origem pode não ser suficiente para classificar a atividade, porque a infraestrutura intermediária pode mascarar a localização real do operador. Ao mesmo tempo, a presença recorrente de nós de saída Tor, provedores de VPN e ASN específico em eventos de falha e sucesso ajuda a construir agrupamentos defensivos. O ponto de maior risco é a transição entre muitas falhas distribuídas e poucos sucessos de autenticação que, isoladamente, podem parecer entradas legítimas.

Superfície afetada

A superfície principal são contas de usuário do Microsoft 365 expostas à autenticação remota. Organizações com identidades sem MFA, exceções amplas em políticas condicionais, senhas reutilizadas, contas legadas ou monitoramento incompleto de entrada ficam mais vulneráveis ao fluxo descrito. O impacto não depende de exploração local, execução de código ou vulnerabilidade com CVE; ele depende da capacidade do operador de obter uma senha válida e concluir a autenticação no serviço em nuvem.

A campanha também deve ser analisada no contexto mais amplo de atividade iraniana citada no mesmo período. Um caso separado envolveu o grupo Pay2Key contra uma organização de saúde nos Estados Unidos no fim de fevereiro de 2026. Nesse incidente, o acesso inicial não foi determinado, mas houve uso de ferramenta legítima de acesso remoto como TeamViewer para estabelecer presença, coleta de credenciais para movimentação lateral, tentativa de desarmar o Microsoft Defender Antivirus por sinalização falsa de antivírus de terceiros, inibição de recuperação, implantação de ransomware, nota de resgate e limpeza de logs. Não houve exfiltração de dados nesse ataque, de acordo com o material analisado.

  • Contas Microsoft 365 sem MFA obrigatório ou com exceções amplas para autenticação remota.
  • Organizações governamentais, municipais, de tecnologia, transporte, energia e setor privado na região afetada.
  • Ambientes com auditoria de entrada, caixa postal e identidade desabilitada ou com retenção insuficiente.
  • Infraestrutura defensiva que trata falhas de senha apenas por conta individual, sem correlacionar campanhas distribuídas contra múltiplos usuários.
Hunting e telemetria

A investigação deve começar pelos logs de entrada do Microsoft 365, correlacionando falhas de autenticação em muitas contas com origens ligadas a Tor, VPN comercial e padrões de acesso geograficamente incompatíveis com a organização. A análise precisa separar ruído comum de internet de sequência operacional: picos em datas próximas às ondas observadas, tentativas contra múltiplos usuários com a mesma senha provável, alternância de IPs de saída e sucessos raros após grande volume de falhas. Quando houver entrada bem-sucedida, a prioridade passa a ser reconstruir a sessão e verificar acesso a caixas de correio.

Em contas com possível comprometimento, a telemetria deve incluir eventos de leitura incomum, criação ou alteração de regras de caixa postal, mudanças em métodos de autenticação, consentimentos anômalos de aplicativos, geração de tokens, acesso via protocolos ou clientes incomuns e exportação ou sincronização fora do padrão. A presença de Tor ou VPN não prova comprometimento sozinha, mas é um sinal forte quando combinada com falhas distribuídas, autenticação bem-sucedida inesperada e acesso a conteúdo sensível.

Para o episódio de ransomware Pay2Key citado como atividade relacionada no ecossistema de ameaças iranianas, a defesa deve procurar sinais separados: uso inesperado de TeamViewer, desativação ou alteração anômala do estado do Microsoft Defender Antivirus, limpeza de logs ao fim da execução, tentativas de impedir recuperação e criptografia de arquivos. A variante Linux mencionada exige privilégios de root, classifica montagens, usa ChaCha20 em modos completo ou parcial e tenta reduzir atrito interrompendo serviços, encerrando processos, desabilitando SELinux e AppArmor e persistindo por entrada de cron em reinicialização.

  • Múltiplas falhas de autenticação contra muitos usuários, especialmente com origens Tor ou VPN.
  • Entradas bem-sucedidas após sequência de falhas distribuídas em contas Microsoft 365.
  • Acesso incomum a caixas de correio, regras de email alteradas ou sincronização fora do perfil do usuário.
  • Eventos de identidade com país, ASN, dispositivo ou cliente incompatível com o histórico da conta.
  • Nos casos de ransomware relacionados, limpeza tardia de logs, tentativa de desativar defesas e uso indevido de ferramenta legítima de acesso remoto.
Mitigação

A resposta defensiva deve priorizar controles de identidade. MFA precisa ser obrigatório para todos os usuários, incluindo contas administrativas, contas privilegiadas de serviço interativo e usuários que historicamente ficaram fora de políticas por exceção operacional. Políticas de acesso condicional devem limitar autenticações a regiões, dispositivos, estados de conformidade e riscos aceitáveis, evitando permitir entrada irrestrita apenas porque a senha está correta. A redução de superfície também passa por bloquear autenticação legada quando aplicável e revisar contas sem uso, contas compartilhadas e senhas fracas.

Após suspeita de pulverização com sucesso, a organização deve tratar a conta como potencialmente comprometida: revogar sessões, redefinir credenciais, revisar métodos de MFA, examinar regras de caixa postal, validar consentimentos de aplicativos e preservar logs para análise. A habilitação de auditoria é essencial porque a campanha descrita inclui a possibilidade de acesso a conteúdo de caixa de correio; sem retenção adequada, a equipe perde a capacidade de diferenciar tentativa bloqueada de acesso efetivo.

Para ambientes com exposição simultânea a riscos de ransomware, as medidas de identidade devem ser acompanhadas de hardening de endpoint e recuperação. O caso Pay2Key mostra abuso de ferramenta legítima de acesso remoto, coleta de credenciais, tentativa de enfraquecer antivírus, inibição de recuperação e limpeza de rastros. Isso exige inventário de ferramentas remotas permitidas, alertas para alteração de estado do Microsoft Defender Antivirus, proteção de logs, backups testados e segmentação que reduza a utilidade de credenciais capturadas.

  • Aplicar MFA sem exceções amplas e revisar contas que ainda dependem apenas de senha.
  • Criar políticas condicionais para restringir origem, risco, dispositivo e contexto de autenticação.
  • Monitorar e alertar para pulverização de senhas em escala, correlacionando múltiplas contas e origens.
  • Habilitar e reter logs de entrada, auditoria de caixa postal e eventos de identidade para investigação.
  • Após autenticação suspeita, revogar sessões, redefinir credenciais e revisar regras, tokens, métodos de MFA e consentimentos de aplicativos.

Postar um comentário

0 Comentários