Pesquisadores da ThreatMon identificaram uma infraestrutura controlada por atacantes que estava exposta publicamente, sem autenticação, e reunia ferramentas de pós-exploração e materiais coletados durante uma intrusão. A atividade foi vinculada a um ambiente associado à companhia aérea mexicana Viva Aerobus e ocorreu entre 25 e 29 de setembro de 2026.

O caso mostra como uma instância do Microsoft SQL Server pode deixar de ser apenas um banco de dados e se tornar um ponto de execução no sistema operacional. Os artefatos analisados indicam o abuso de xp_cmdshell para executar comandos do Windows e PowerShell codificado, além de scripts voltados à coleta de credenciais, ao teste de acessos em outros servidores SQL e a tentativas de acesso a compartilhamentos SMB.

É importante delimitar o que foi confirmado. A ThreatMon encontrou evidências de coleta de credenciais e de preparação para movimentação lateral, mas não confirmou acesso bem-sucedido a sistemas adicionais nem exfiltração de dados de passageiros, pagamentos ou outros dados corporativos sensíveis. Também não foi divulgado o vetor de acesso inicial à rede.

O que a ThreatMon encontrou

A investigação partiu de um servidor HTTP controlado pelos atacantes, no endereço 151.243.232.123. Como os diretórios de trabalho estavam acessíveis sem autenticação, a equipe conseguiu observar ferramentas, registros HTTP e arquivos armazenados pelos operadores.

Segundo a cronologia publicada, às 16h20 de 25 de setembro um SQL Server do ambiente investigado recuperou uma carga dessa infraestrutura. Entre 16h21 e 16h23, outro host externo já enumerava o mesmo servidor e seus diretórios expostos. Mais tarde, outros hosts acessaram ferramentas e artefatos disponíveis ali.

Essa falha operacional criou uma segunda camada de risco: além da intrusão original, qualquer material colocado no servidor pelos criminosos poderia ter sido visto por terceiros. A existência de uma ferramenta ou arquivo no servidor demonstra a capacidade ou a intenção dos operadores, mas não prova que cada ação correspondente tenha sido concluída com sucesso.

Como o SQL Server foi usado no ataque

O mecanismo central observado foi xp_cmdshell, um procedimento estendido do SQL Server que permite executar comandos do sistema operacional quando está habilitado e quando as permissões necessárias existem. Os scripts recuperados foram preparados para enviar comandos do Windows e PowerShell em Base64 por uma sessão MSSQL.

O mesmo canal foi usado como caminho de retorno para arquivos. Em vez de depender necessariamente de um servidor de comando e controle separado, as ferramentas podiam ler um arquivo, dividi-lo em partes, codificá-las em Base64 e devolver o conteúdo como resultado de consultas SQL. Essa técnica transforma a sessão de banco de dados em um canal para execução e transferência de dados.

Esse comportamento é especialmente perigoso porque os processos iniciados por xp_cmdshell podem ser executados no contexto da conta de serviço do SQL Server. Se essa conta possuir privilégios além do necessário, um invasor que obtenha esse caminho de execução pode ampliar o alcance da invasão para o sistema operacional e para recursos de rede acessíveis por ela.

Ferramentas e dados de interesse dos invasores

O servidor exposto continha 17 ferramentas e artefatos de pós-exploração. A lista incluía scripts para obter credenciais de navegadores e do armazenamento de credenciais do Windows, além de arquivos relacionados ao Mimikatz.

Entre os itens divulgados estavam chrome_dump.ps1, cred_dump.ps1 e cred_enum.ps1, usados para extrair ou enumerar credenciais; sqlspray.ps1 e mssqltest.ps1, voltados ao teste de credenciais em outros alvos SQL; e exfil.py e upload.py, destinados à transferência de arquivos. Havia também referências ao Credential Manager, ao Windows Vault e ao DPAPI, recurso usado pelo Windows para proteger dados como senhas salvas.

Os pesquisadores encontraram ainda dados de configuração do SQL Server Management Studio (SSMS). Esse tipo de material pode expor histórico de conexões, nomes de servidores, usuários de banco de dados e dados de senha protegidos por DPAPI. Mesmo quando a senha não pode ser usada diretamente, essas informações funcionam como um mapa de sistemas e contas que um invasor pode tentar reutilizar.

Os operadores também coletaram código-fonte e arquivos de configuração com referências a integrações SQL, OAuth, e-mail, SFTP, pagamentos e relatórios. A ThreatMon não divulgou os valores sensíveis, nomes internos ou credenciais presentes nos artefatos.

Indicadores de comprometimento

A ThreatMon publicou um conjunto limitado de indicadores relacionados à infraestrutura e às ferramentas dos atacantes. Eles devem ser usados para threat hunting e correlação de telemetria, sempre em conjunto com sinais comportamentais.

CategoriaIndicador
IPv4151.243.232.123
SHA-256 de exfil.pyc38f49ba68b891bb476510704cddf080798f3c70075e2a517e98e04e833f64fa
SHA-256 de upload.py33aeaaa3d57b7785ef2be5b8ccd39d534b8af50e0cd32a5036fdb64601a52fc9
SHA-256 de sqlspray.ps18b6c53e3d57b4c3049f3d0765a44d9a52feb6af78f1eaa5aff19daf1b9665998
Caminho WindowsC:\Windows\Temp\artex

Medidas recomendadas para ambientes SQL Server

  • Revise o uso de xp_cmdshell. Em instalações novas ele vem desabilitado por padrão. A orientação da Microsoft é mantê-lo desabilitado em código novo e, se uma aplicação legada exigir o recurso, habilitá-lo somente durante a tarefa estritamente necessária.
  • Investigue alterações e execuções inesperadas. Ativações de xp_cmdshell, bem como cmd.exe ou powershell.exe iniciados por sqlservr.exe ou pela conta de serviço do banco, devem gerar alertas de alta prioridade, principalmente quando houver comandos codificados.
  • Aplique o menor privilégio às contas de serviço. A conta do SQL Server não deve ter permissões administrativas ou acesso de rede mais amplo do que o necessário. Restringir a saída para a internet e o acesso a compartilhamentos administrativos reduz as opções do invasor.
  • Trate dados do SSMS como informação sensível. Histórico de conexões, usuários, senhas salvas e artefatos DPAPI precisam de proteção e auditoria equivalentes às de outras credenciais administrativas.
  • Monitore autenticações e reutilização de credenciais. Tentativas em sequência contra múltiplos servidores SQL, mudanças de papel de servidor e acessos inesperados a SMB são sinais que devem ser correlacionados com logs do banco, do endpoint e da rede.
  • Faça uma verificação direcionada. Procure conexões históricas para o IP e os hashes publicados, além do diretório C:\Windows\Temp\artex. Caso encontre evidências, isole o ativo, preserve logs e evidências e rotacione credenciais, segredos e tokens que possam ter sido expostos.