Microsoft SQL Server comprometido pode executar comandos e servir à exfiltração de dados
Uma invasão associada a um ambiente da companhia aérea Viva Aerobus ilustra como um Microsoft SQL Server comprometido pode deixar de ser apenas um banco de dados e se transformar em uma ponte para o sistema Windows. No caso analisado, a mesma sessão SQL foi preparada para executar comandos, buscar credenciais e transferir arquivos.
A investigação da ThreatMon acompanhou atividades entre 25 e 29 de setembro de 2026. Os pesquisadores conseguiram reconstituir etapas da operação após o acesso inicial, mas não identificaram como a invasão começou. Também não confirmaram que o ataque tenha alcançado outros sistemas ou provocado o roubo de dados de passageiros e pagamentos.
A análise foi possível após uma falha operacional dos próprios invasores: um servidor usado para armazenar ferramentas e dados coletados ficou acessível pela internet sem exigir autenticação. A exposição permitiu examinar recursos empregados durante a intrusão e reconstruir parte do que ocorreu depois que o ambiente foi comprometido.
Entre os arquivos encontrados havia 17 ferramentas identificadas por nome. O conjunto incluía scripts para procurar credenciais, componentes do Mimikatz, programas de teste de logins SQL e utilitários 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 informações protegidas pelo Windows DPAPI.
Esses vestígios revelam aspectos da fase pós-comprometimento, mas não esclarecem o método usado para obter o primeiro acesso. Até o momento, não há evidências públicas que relacionem o incidente a uma vulnerabilidade específica do SQL Server, a uma técnica determinada de quebra de senha ou a uma família de malware identificada. O que a investigação aponta é o uso de credenciais e recursos legítimos durante a operação.
Do banco de dados ao sistema operacional
Um dos elementos centrais foi o uso de `xp_cmdshell`, recurso do SQL Server que pode iniciar comandos no Windows quando está habilitado. As ferramentas recuperadas permitiam enviar comandos do sistema e instruções PowerShell codificadas em Base64 por meio de uma sessão MSSQL.
Na prática, isso amplia o impacto de uma conta de banco comprometida. Com privilégios suficientes, o invasor pode deixar de se limitar a consultar tabelas ou manipular dados e passar a tentar executar ações no servidor que hospeda o SQL Server. O alcance dessas ações depende das permissões da conta de serviço e das configurações do ambiente.
A Microsoft mantém o `xp_cmdshell` desativado por padrão em novas instalações e, em geral, recomenda que ele permaneça assim. Se uma aplicação antiga exigir o recurso, o uso deve ser restrito a usuários altamente privilegiados e limitado ao período necessário. Isso é importante porque os comandos podem ser executados com o contexto de segurança da conta de serviço do SQL Server.
Consultas usadas para transportar arquivos
As ferramentas observadas não se restringiam à execução de comandos. Elas também podiam ler arquivos, dividi-los em partes menores, convertê-los para Base64 e devolver o conteúdo por meio dos resultados das consultas SQL. Dessa forma, a própria conexão com o banco poderia funcionar como um canal para transportar informações coletadas.
Base64 não cifra os dados: apenas converte conteúdo binário em uma representação textual. Nesse cenário, sua utilidade estava em adaptar arquivos a um fluxo de comunicação já disponível. Por isso, monitorar somente conexões de saída recém-abertas pode não ser suficiente. Uma sessão legítima com o banco também pode ser usada de maneira indevida para carregar comandos ou dados.
A exposição do servidor de staging ampliou ainda mais o risco. Além de revelar ferramentas, os registros e arquivos disponíveis podiam expor nomes de usuários, informações relacionadas a senhas e detalhes da operação. Uma falha na infraestrutura montada pelo atacante acabou criando uma segunda fonte de exposição, independente do acesso original ao banco.
O que as equipes de segurança devem observar
Para detectar atividades desse tipo, vale acompanhar o uso do `xp_cmdshell`, especialmente quando ele é ativado fora de uma janela de manutenção ou por contas que normalmente não precisam desse recurso. A execução de processos incomuns pelo serviço do SQL Server, como interpretadores de comandos e PowerShell, também merece investigação.
Outro sinal relevante é a alteração repentina no padrão das consultas. Respostas com grandes volumes de dados, resultados codificados em Base64 e consultas repetidas para recuperar blocos de conteúdo podem indicar tentativa de transferência de arquivos. A análise deve considerar o contexto: uma consulta isolada pode ser legítima, mas mudanças de comportamento combinadas podem apontar abuso.
É recomendável manter os registros do SQL Server, do Windows e das ferramentas de monitoramento sincronizados e preservados. Quando há indícios de intrusão, esses dados ajudam a identificar contas utilizadas, comandos executados e possíveis acessos a outros sistemas. A revisão deve incluir também os históricos do SSMS e as permissões concedidas a usuários e serviços.
A proteção começa pela redução de privilégios. Contas de serviço não devem ter permissões administrativas além das estritamente necessárias, e credenciais de banco precisam ser exclusivas, fortes e protegidas contra reutilização. O acesso administrativo deve ser limitado a redes e equipamentos autorizados, com autenticação multifator sempre que disponível.
Também é importante revisar configurações e dependências de aplicações antigas. Recursos como o `xp_cmdshell` devem permanecer desativados se não forem indispensáveis. Quando forem necessários, a ativação temporária, o controle rigoroso de quem pode executá-los e o registro de cada uso ajudam a reduzir a janela de exposição.
Por fim, equipes de resposta devem tratar o SQL Server como parte da infraestrutura de execução, e não como uma fronteira isolada que protege automaticamente os dados. Uma invasão no banco pode afetar o sistema operacional, alcançar credenciais e abrir caminhos para outros ativos. Monitorar as interações entre SQL Server, Windows, aplicações e tráfego de rede é essencial para perceber essa progressão antes que ela se transforme em um incidente mais amplo.