Microsoft SQL Server comprometido vira canal para comandos e exfiltração de dados

Uma intrusão ligada a um ambiente da Viva Aerobus mostra como um Microsoft SQL Server já comprometido pode deixar de ser apenas um repositório de dados e passar a funcionar como caminho para executar comandos no Windows, coletar credenciais e transportar arquivos. A investigação da ThreatMon reconstruiu a atividade pós-comprometimento, mas não determinou o vetor inicial nem confirmou acesso bem-sucedido a sistemas adicionais ou vazamento de dados de passageiros e pagamentos.

Entre 25 e 29 de setembro de 2026, pesquisadores da ThreatMon acompanharam uma operação que expôs uma cadeia de pós-exploração centrada em Microsoft SQL Server. A visibilidade surgiu de uma falha incomum do próprio atacante: um servidor de staging e armazenamento de material coletado ficou acessível pela Internet sem autenticação, permitindo que terceiros chegassem às ferramentas e aos diretórios usados na intrusão.

O servidor exposto continha 17 ferramentas nomeadas, incluindo scripts para coleta de credenciais, artefatos do Mimikatz, utilitários para testar logins SQL e mecanismos de transferência de arquivos. Os registros também mostraram histórico do SQL Server Management Studio (SSMS), nomes de usuários de banco e material de senhas protegidas pelo Windows DPAPI. Esse conjunto permitiu reconstruir parte relevante do que ocorreu depois do acesso inicial, embora não revele como o primeiro comprometimento aconteceu.

A distinção é importante. Não há evidência pública que associe o caso a uma CVE específica do SQL Server, a um ataque de senha determinado ou a uma família de malware nomeada. O que foi observado é o abuso de recursos legítimos e de credenciais em uma etapa posterior da intrusão.

SQL Server virou caminho para o Windows

O componente técnico mais significativo foi o uso de xp_cmdshell, procedimento estendido do SQL Server capaz de iniciar comandos no sistema operacional quando está habilitado. As ferramentas recuperadas foram preparadas para enviar comandos do Windows e PowerShell codificado em Base64 por uma sessão MSSQL, fazendo com que o acesso ao banco também funcionasse como ponto de execução no host.

Esse comportamento muda a fronteira de risco. Uma credencial com privilégios suficientes no SQL Server deixa de representar somente acesso a tabelas, procedures e dados armazenados. Se xp_cmdshell estiver disponível, o comprometimento pode alcançar o contexto do sistema operacional e herdar permissões associadas à conta de serviço usada pelo SQL Server.

A própria Microsoft mantém xp_cmdshell desabilitado por padrão em novas instalações e recomenda que o recurso permaneça desativado em geral. Quando uma aplicação legada realmente depende dele, a orientação é habilitá-lo apenas durante a tarefa necessária e restringir sua execução a usuários altamente privilegiados. A documentação da Microsoft também alerta que o processo Windows iniciado pelo recurso pode executar com o contexto de segurança da conta de serviço do SQL Server.

A mesma sessão SQL também carregava dados para fora

As ferramentas analisadas pela ThreatMon não usavam o banco apenas para disparar comandos. Arquivos podiam ser lidos, divididos em partes menores, convertidos para Base64 e devolvidos pelo resultado das próprias consultas MSSQL. Isso permitia transportar conteúdo coletado sem criar obrigatoriamente um canal separado de comando e controle.

Base64 não oferece criptografia; apenas representa conteúdo binário em formato textual. O valor ofensivo, nesse caso, estava em acomodar os dados dentro de um fluxo que já existia. Para equipes de defesa, esse detalhe merece atenção porque controles concentrados apenas na abertura de novas conexões de saída podem não enxergar toda a atividade quando um serviço corporativo permitido passa a carregar comandos e informação exfiltrada.

A ThreatMon mapeou o comportamento observado a técnicas do MITRE ATT&CK relacionadas a PowerShell, Windows Command Shell, credential dumping, credenciais armazenadas, dados em arquivos, serviços remotos, staging e exfiltração pelo canal de controle. A classificação descreve o que foi observado no pós-comprometimento; não prova que todas as tentativas seguintes tiveram sucesso.

Credenciais e metadados ampliaram a superfície de ataque

A operação também mostra por que informações aparentemente administrativas podem ganhar valor depois de uma invasão. O material recuperado continha histórico de conexões do SSMS, referências a servidores usados anteriormente, usuários de banco e senhas salvas protegidas por DPAPI. Não existe evidência de que todas essas senhas tenham sido descriptografadas, mas os registros ofereciam uma lista organizada de possíveis destinos para novas tentativas.

Outros arquivos coletados continham referências a conexões de banco, OAuth, e-mail, SFTP e integrações de pagamento ou relatórios. As ferramentas expostas incluíam ainda scripts para testar combinações de credenciais contra outros servidores SQL e verificar acesso a compartilhamentos administrativos SMB.

A investigação encontrou evidência de tentativa de reutilização de credenciais e preparação para movimentação lateral. Não encontrou, porém, comprovação pública de que os atacantes tenham alcançado com sucesso os sistemas adicionais. Essa diferença entre intenção, tentativa e comprometimento confirmado evita transformar indicadores técnicos em conclusões que os dados não sustentam.

Uma falha do atacante criou uma segunda exposição

O servidor de staging utilizado na operação estava aberto para a Internet. Segundo a ThreatMon, às 16h20 de 25 de setembro um ambiente MSSQL do lado da vítima buscou um payload naquela infraestrutura. Entre 16h21 e 16h23, um host externo sem relação conhecida começou a enumerar o mesmo servidor e seus diretórios. Mais tarde, outros sistemas recuperaram ferramentas e artefatos armazenados ali.

Isso produziu um segundo risco sobre o incidente original. Credenciais, arquivos ou segredos que chegaram à infraestrutura do atacante não ficaram necessariamente restritos ao operador da intrusão. Uma vez expostos em um servidor sem controle de acesso, outros atores também puderam acessar o material.

Por essa razão, segredos identificados naquele staging devem ser tratados como comprometidos, mesmo sem evidência posterior de abuso. A ausência de uso observado não permite concluir que apenas o atacante inicial teve acesso.

Quando o comprometimento do banco alcança aplicações e operação

Um SQL Server comprometido pode ocupar uma posição sensível na arquitetura porque costuma manter conexões com aplicações, serviços de identidade, processos de integração, ferramentas administrativas e outros bancos. Quando a sessão de banco alcança o sistema operacional, o risco deixa de estar limitado à confidencialidade e integridade dos registros armazenados.

O alcance real depende dos privilégios da conta de serviço, da segmentação, das regras de saída, das credenciais disponíveis no host e da separação entre ambientes. Em uma arquitetura permissiva, a combinação de execução de comandos, coleta de credenciais e histórico de conexões pode acelerar o acesso a outros ativos. Em uma arquitetura restritiva, contas de serviço com menor privilégio, segmentação e controle de egress reduzem o raio de impacto mesmo depois de um servidor individual ser comprometido.

Também há um efeito operacional. Banco de dados é infraestrutura crítica para aplicações corporativas; uma investigação que exija isolamento, rotação de credenciais, validação de integridade e revisão de integrações pode afetar disponibilidade e continuidade. Se dados regulados forem efetivamente comprometidos em outro caso semelhante, passam a existir ainda impactos de privacidade, compliance, contratos e comunicação de incidente. No episódio analisado, entretanto, a ThreatMon não confirmou exfiltração de dados sensíveis de passageiros, pagamentos ou informações equivalentes de negócio.

Controles para reduzir exposição e detectar abuso

A proteção começa pela configuração do próprio SQL Server, mas precisa alcançar Windows, identidade e rede. Os controles mais diretamente relacionados ao mecanismo observado são:

• Manter xp_cmdshell desabilitado quando não houver dependência de negócio. Se o uso for indispensável, limitar a janela de habilitação e os usuários autorizados.
• Aplicar menor privilégio às contas de serviço do SQL Server. A Microsoft recomenda executar os serviços com os menores direitos possíveis e evitar permissões adicionais desnecessárias.
• Monitorar alterações e uso de xp_cmdshell. Execução inesperada de cmd.exe, powershell.exe, comandos codificados ou operações incomuns de arquivo sob a conta do SQL Server deve gerar investigação.
• Proteger e revisar metadados do SSMS. Histórico de conexão, nomes de servidores, usuários e senhas salvas são informações adjacentes a credenciais e podem orientar novas tentativas.
• Restringir egress e segmentar servidores de banco. SQL Servers não devem possuir caminhos de saída ou acesso lateral mais amplos do que o necessário para sua função.
• Revisar autenticações e reutilização de credenciais. Senhas ou segredos que tenham alcançado infraestrutura controlada pelo atacante devem ser rotacionados, inclusive quando ainda não houver abuso confirmado.
• Correlacionar telemetria de banco, endpoint e rede. Logs SQL isolados podem mostrar uma consulta; EDR e rede revelam quando a mesma atividade dispara PowerShell, acessa arquivos ou tenta alcançar SMB e outros servidores.

Para organizações que mantêm SQL Server exposto diretamente à Internet, o caso reforça a necessidade de revisar a justificativa dessa exposição, limitar origens por firewall e remover interfaces administrativas desnecessárias da superfície pública. A ausência de uma CVE conhecida não torna o serviço seguro se credenciais, privilégios ou configurações permitirem abuso após o acesso.

Indicadores publicados para caça a ameaças

A ThreatMon publicou indicadores limitados à infraestrutura e aos artefatos do atacante, preservando nomes internos, usuários, dados de credenciais e outros elementos sensíveis da vítima. Entre os indicadores mais úteis para buscas retrospectivas estão:

Indicadores devem ser usados em conjunto com contexto. Endereços IP podem mudar de função e nomes de arquivos podem ser alterados. A maior capacidade de detecção vem da combinação entre os IoCs publicados e comportamentos como uso inesperado de xp_cmdshell, PowerShell codificado, criação de processos pelo serviço SQL e tentativas de autenticação contra múltiplos servidores.

Referências

• An Open Server, an Exposed Toolkit Inside a Viva Aerobus-Linked Intrusion
• Hackers Turned a Microsoft SQL Server Into a Command and Data Exfiltration Channel
• Configuração do servidor: xp_cmdshell — SQL Server
• Configure Windows Service Accounts and Permissions — SQL Server

O banco não pode ser tratado como uma fronteira isolada

O caso ligado ao ambiente da Viva Aerobus expõe um problema mais amplo do que a segurança do dado armazenado. Depois que um atacante obtém acesso suficiente ao SQL Server, funcionalidades administrativas, contas de serviço, históricos de conexão e rotas de rede podem transformar o banco em uma ponte entre aplicação, sistema operacional e outros ativos.

A resposta defensiva precisa acompanhar essa cadeia. Desabilitar recursos desnecessários, reduzir privilégios, controlar comunicação lateral e de saída, tratar metadados administrativos como informação sensível e correlacionar eventos de banco com endpoint e rede reduz tanto a probabilidade de abuso quanto o alcance de um comprometimento. O episódio também deixa uma advertência útil para a investigação: evidência de tentativa não deve ser promovida a sucesso confirmado, mas sinais de pós-exploração em um servidor de banco exigem resposta antes que essa diferença desapareça.