Microsoft SQL Server comprometido pode executar comandos no Windows e transportar dados para fora
Uma invasão associada ao ambiente da companhia aérea Viva Aerobus evidencia que um Microsoft SQL Server comprometido pode se tornar mais do que uma porta de acesso a informações armazenadas. Dependendo das permissões e da configuração do servidor, o banco também pode servir para executar comandos no Windows, buscar credenciais e transferir arquivos.
A análise conduzida pela ThreatMon reconstituiu atividades realizadas após o acesso inicial ao ambiente. No entanto, os pesquisadores não identificaram como a intrusão começou nem confirmaram que os invasores tenham alcançado outros sistemas ou roubado dados de passageiros e pagamentos. Também não foi associada ao caso uma vulnerabilidade específica do SQL Server, uma senha comprometida ou uma família conhecida de malware.
A investigação ocorreu entre 25 e 29 de setembro de 2026 e ganhou visibilidade por causa de um erro operacional dos próprios invasores. Um servidor usado para armazenar ferramentas e materiais coletados ficou exposto à internet sem autenticação. Com isso, terceiros puderam acessar arquivos e diretórios relacionados à operação e reconstruir parte das ações posteriores ao comprometimento.
Entre o conteúdo encontrado havia 17 ferramentas identificadas por nome, incluindo recursos para procurar credenciais, componentes do Mimikatz, utilitários para testar acessos ao SQL e mecanismos de transferência de arquivos. Também foram localizados registros do SQL Server Management Studio (SSMS), nomes de usuários de banco de dados e materiais protegidos pelo Windows DPAPI. Esses vestígios ajudam a entender como o ambiente foi explorado, mas não esclarecem o método usado para obter o primeiro acesso.
Como o banco foi usado para executar comandos
Um dos recursos centrais da atividade foi o `xp_cmdshell`, procedimento estendido que permite ao SQL Server iniciar comandos no sistema operacional. As ferramentas identificadas estavam preparadas para enviar instruções do Windows e comandos PowerShell codificados em Base64 por meio de uma sessão MSSQL.
Na prática, isso transforma uma conexão com o banco em um possível canal de execução no servidor que o hospeda. Se a conta comprometida tiver privilégios suficientes e o recurso estiver habilitado, o invasor poderá ultrapassar a camada dos dados e interagir com o sistema operacional, dentro das permissões associadas ao serviço do SQL Server.
A Microsoft mantém o `xp_cmdshell` desativado por padrão em novas instalações e recomenda que ele permaneça desligado na maioria dos ambientes. Organizações que dependem do recurso por causa de aplicações antigas devem limitar seu uso a situações específicas e restringir a execução a contas altamente privilegiadas. É importante considerar que os processos iniciados por essa função podem herdar o contexto de segurança da conta de serviço do banco.
Consultas também podem ser usadas para retirar arquivos
A operação não se limitava a emitir comandos. Segundo a análise, arquivos podiam ser lidos, divididos em partes menores, convertidos para Base64 e devolvidos como resultados de consultas SQL. Assim, o próprio tráfego do banco poderia ser aproveitado para transportar conteúdo, sem que fosse necessariamente criado um canal separado de comando e controle.
Base64 não é criptografia: trata-se de uma forma de representar dados binários como texto. Nesse cenário, sua utilidade estava em adaptar os arquivos a um fluxo que já existia. Por isso, monitorar apenas novas conexões externas pode não ser suficiente. Um serviço corporativo permitido também pode ser abusado para carregar comandos ou informações para fora da rede.
Esse padrão não comprova, por si só, que houve exfiltração de dados. A investigação descrita não confirmou o roubo de informações de passageiros ou de pagamentos. A distinção entre uma técnica observada e um impacto comprovado é essencial para avaliar o caso sem ampliar as conclusões além das evidências disponíveis.
O que equipes de segurança devem observar
O uso inesperado de `xp_cmdshell` é um sinal que merece investigação, sobretudo quando aparece em servidores que não deveriam executar comandos do sistema operacional. Também devem ser avaliadas alterações recentes na configuração, consultas administrativas fora do padrão e tentativas de utilizar contas de serviço para realizar ações não previstas.
Outros indícios relevantes incluem comandos PowerShell codificados em Base64, arquivos divididos em blocos e resultados SQL incomuns ou volumosos. Registros do SSMS e tentativas repetidas de autenticação podem ajudar a identificar a sequência de atividades, especialmente quando comparados com os horários de acesso e com as contas envolvidas.
Para reduzir a exposição, as empresas devem manter o SQL Server e seus componentes atualizados, remover contas e permissões desnecessárias e evitar o acesso direto ao banco a partir da internet. O acesso administrativo deve ser limitado a redes confiáveis, com autenticação forte e contas individuais, em vez de credenciais compartilhadas entre pessoas ou aplicações.
Também é recomendável revisar regularmente quais sistemas podem se conectar ao banco e quais permissões cada usuário possui. Uma aplicação que só precisa consultar determinadas tabelas não deve receber privilégios administrativos. Separar contas de serviço, restringir seus direitos no Windows e impedir que elas realizem ações fora da função prevista reduz o impacto de uma eventual invasão.
Quando o `xp_cmdshell` for indispensável, a organização deve documentar a necessidade, controlar rigorosamente quem pode acioná-lo e monitorar cada uso. Desativar o recurso após uma tarefa pontual e alertar sobre qualquer reativação inesperada são medidas que podem dificultar o abuso. A mesma lógica vale para outras funções administrativas: recursos habilitados sem necessidade ampliam as possibilidades disponíveis a um invasor.
O banco não deve ser tratado como uma fronteira isolada
A principal lição do episódio é que a segurança do SQL Server não se limita à proteção das tabelas. Um comprometimento pode alcançar o Windows, as credenciais disponíveis no host e os sistemas que confiam naquela máquina. Por isso, a defesa precisa combinar controles de banco de dados, segurança do sistema operacional, gestão de identidade e monitoramento de rede.
A contenção também deve considerar os possíveis caminhos entre serviços. Se um servidor SQL tiver comunicação ampla com outros ativos, uma intrusão pode ganhar oportunidades de expansão. Restringir conexões entre sistemas ao mínimo necessário ajuda a evitar que o banco se torne uma ponte para áreas mais sensíveis da infraestrutura.
Por fim, a exposição do servidor de staging mostra que ferramentas e arquivos temporários também exigem proteção. Ambientes usados para armazenar scripts, resultados de coleta ou cópias de trabalho precisam de autenticação, acesso restrito e revisão contínua. Uma falha nesse tipo de servidor pode revelar técnicas, credenciais ou evidências que ajudam a compreender – e potencialmente a prolongar – uma intrusão.