A Microsoft Threat Intelligence revelou uma campanha de invasão que começa com uma mensagem ou chamada via Microsoft Teams de uma entidade externa que se faz passar por funcionários de tecnologia da informação ou da central de suporte. O invasor tenta convencer o funcionário a ignorar os avisos sobre o contato externo e a conceder-lhe controle interativo do dispositivo por meio de ferramentas como sessões de suporte remoto ou o Quick Assist e, em seguida, usa o PowerShell para baixar e instalar silenciosamente um pacote MSI malicioso.
A campanha não explora uma vulnerabilidade técnica no Microsoft Teams, segundo a Microsoft, mas depende de engenharia social e da persuasão do usuário para que ele contorne as proteções existentes. O perigo está no fato de que o ponto de entrada parece um procedimento de suporte familiar, enquanto concede ao invasor acesso interativo, respaldado pelas credenciais do usuário, a um dispositivo dentro da organização.
Cadeia de ataque usa ferramentas confiáveis
Após a instalação do pacote MSI, a campanha coloca um carregador baseado em texto e um arquivo criptografado contendo um implante JavaScript dentro da pasta LocalAppData. Se o Node.js não estiver instalado no dispositivo, o pacote baixa uma versão portátil legítima do ambiente de execução da distribuição oficial do Node.js e então a utiliza para descriptografar e executar o implante.
O processo é iniciado por meio do PowerShell, do cmd.exe ou do WScript e usa mecanismos de persistência por usuário, como um valor Run no registro ou um atalho dentro da pasta Startup com o nome EdgeUpdate. O implante se conecta ao comando e controle por meio de solicitações HTTPS periódicas e aleatórias e recebe tarefas JavaScript capazes de executar comandos, verificar o dispositivo, os programas de segurança e o ambiente virtual, além de capturar periodicamente imagens da área de trabalho.
As amostras analisadas pela Microsoft também continham lógica desativada para consultar um contrato inteligente na rede Ethereum a fim de obter um endereço atualizado do servidor de comando e controle. A empresa explicou que o contrato não armazena nem executa a carga maliciosa e que as amostras recuperadas usaram um endereço alternativo fixo.
Do dispositivo infectado aos sistemas de identidade
A atividade não termina com a instalação do implante. Os operadores usaram comandos nativos e consultas ADSI para enumerar contas do domínio, servidores e usuários e, em seguida, executaram cargas adicionais por meio do rundll32.exe. Depois disso, o implante iniciou conexões WinRM pela porta TCP 5985 com um grande número de sistemas ingressados no domínio, incluindo servidores de arquivos, bancos de dados e aplicativos, além de controladores de domínio e autoridades de certificação.
Essa movimentação representa uma transição prática do engano de um único usuário para uma tentativa de ampliar o controle dentro da organização. O material não comprova que a campanha tenha implantado ransomware ou efetivamente roubado dados, mas indica que o reconhecimento e o movimento em direção aos sistemas de identidade são compatíveis com etapas que antecedem objetivos posteriores, como roubo de dados, extorsão ou disseminação de ransomware.
Por que esta notícia é importante?
A campanha mostra que a confiança em uma ferramenta legítima pode se tornar mais perigosa do que um arquivo executável desconhecido. A presença do Microsoft Teams, do Node.js, do Windows Installer e do WinRM na cadeia não significa que essas ferramentas sejam maliciosas, mas torna insuficiente depender apenas de listas de programas permitidos. O indicador mais importante é uma sequência comportamental incomum: um contato externo urgente, seguido por uma sessão de suporte remoto, depois a execução do PowerShell ou do cmd.exe e a instalação de um MSI ou a execução do Node.js a partir de um caminho gravável pelo usuário.
A Microsoft recomenda verificar qualquer solicitação de suporte externo por meio de um canal interno conhecido, restringir a colaboração externa no Teams a domínios confiáveis, exigir autenticação multifator e acesso condicional e monitorar ferramentas de suporte remoto. A empresa também sugere ativar regras de redução da superfície de ataque e proteções de rede e web, limitar o WinRM a estações de administração autorizadas e gerar alertas quando ele for executado a partir do contexto de um usuário ou processo não administrativo.
As organizações que encontrarem indicadores associados a esta campanha devem tratar o dispositivo afetado como um possível ponto de acesso à rede e priorizar a investigação e a rotação das credenciais que poderiam ter sido acessadas a partir dele, incluindo, quando apropriado, as contas de administradores do domínio.