Impersonação de Atendimento ao Cliente no Microsoft Teams: Quando o Suporte de TI Envia a Primeira Mensagem

Resumo

Os atacantes estão se passando por suporte de TI através do Microsoft Teams, contactando usuários de inquilinos externos. Eles dependem de engenharia social para convencer as vítimas a instalar pacotes MSI maliciosos ou conceder acesso remoto através do Quick Assist. Os objetivos principais são o roubo de credenciais, controle remoto e estabelecimento de persistência dentro do ambiente da vítima.

Investigação

A investigação identificou um carregador de malware chamado SynkLoader que utiliza várias linguagens de programação e executa-se amplamente na memória para evadir o EDR. Os pesquisadores observaram um módulo falso de tela de bloqueio do Windows chamado PhishLocker, projetado para capturar senhas em texto simples, além de um proxy reverso TrafficRedirector usado para tunelamento de rede. As evidências também incluíam tarefas agendadas suspeitas e abuso de ferramentas legítimas como Rclone para exfiltração.

Mitigação

As organizações devem restringir o acesso externo do Microsoft Teams mantendo uma lista de domínios aprovados e bloqueando subdomínios não confiáveis. Os administradores devem desativar a capacidade de contas não gerenciadas de iniciar conversas e revisar as configurações relacionadas aos inquilinos apenas de teste. O Quick Assist também deve ser desativado ou restrito rigorosamente para evitar sessões remotas não autorizadas.

Resposta

Se uma atividade maliciosa for detectada, as máquinas afetadas devem ser isoladas da rede enquanto permanecem ligadas para preservar os artefatos na memória. Todas as sessões de identidade ativas devem ser revogadas e a senha do usuário redefinida de um dispositivo confiável. Recomenda-se uma reimagem completa do endpoint em vez de tentar uma limpeza, seguida por uma análise do raio de explosão usando logs de Single Sign-On (SSO).

Execução de Simulação

• Narrativa do Ataque & Comandos: O adversário ganhou acesso inicial à estação de trabalho Windows. Para facilitar o movimento lateral e exfiltrar dados, eles baixam o binário chisel. Seu objetivo é estabelecer um túnel que lhes permita alcançar recursos internos do seu servidor C2 remoto. Eles executam binary. Their goal is to set up a tunnel that allows them to reach internal resources from their remote C2 server. They execute chisel.exe para iniciar uma conexão. Como a regra de detecção procura a string “chisel” no caminho do processo, esta ação deve acionar um alerta de alta severidade.

• Script de Teste de Regressão:

  # Script de Simulação: Acionar Detecção de Proxy Reverso via Chisel
  # Nota: Este script assume que chisel.exe está presente no diretório atual.
  # Se não estiver presente, tentará baixar um substituto ou falhará.
  
  $toolName = "chisel.exe"
  $destination = "8.8.8.8" # Usando o DNS do Google como destino fictício para simular uma tentativa de conexão
  $port = "80"
  
  Write-Host "[+] Iniciando simulação: Executando $toolName" -ForegroundColor Cyan
  
  if (Test-Path $toolName) {
      # Executar chisel para criar uma tentativa de conexão.
      # Usamos o modo 'client' para tentar uma conexão de saída.
      Start-Process -FilePath . "$toolName" -ArgumentList "client $destination:$port" -WindowStyle Hidden
      Write-Host "[!] Comando de simulação enviado. Verifique o SIEM para um Evento ID 3 com imagem contendo 'chisel'." -ForegroundColor Yellow
  } else {
      Write-Error "[!] Erro: $toolName não encontrado no diretório atual. Por favor, coloque o binário aqui para rodar a simulação."
  }

• Comandos de Limpeza:

  # Limpeza: Encerrar quaisquer processos chisel em execução e remover o binário.
  Stop-Process -Name "chisel" -ErrorAction SilentlyContinue
  Remove-Item . "chisel.exe" -Force -ErrorAction SilentlyContinue
  Write-Host "[+] Limpeza completa." -ForegroundColor Green