Tim Beasley Consultor Sénior de Resposta a Incidentes

Nem todos os grupos perigosos no Active Directory parecem representar um risco.

Já trabalho na área da resposta a incidentes, análise forense de identidades e recuperação após violações há tempo suficiente para ter uma lista atualizada de grupos do AD que são descartados como «nada de especial». Operadores de cópias de segurança. Operadores de impressão. Operadores de servidores. Aqueles com quem ninguém se preocupa porque não são administradores de domínio.

Por que é que isto lhe interessa? Porque os atacantes não precisam de ser administradores de domínio . No que diz respeito a estes grupos, basta-lhes um único grupo que tenha sido ignorado, com as permissões certas — e que ninguém esteja a vigiar.

É esse o padrão que esta série se propõe a quebrar.

Em cada artigo desta série, vamos analisar mais detalhadamente um grupo de segurança do AD selecionado, e vou explicar:

  • Os direitos específicos de que esse grupo dispõe
  • Os riscos que podem acarretar
  • Como é que os atacantes as exploram na prática
  • O que verificar hoje no seu próprio ambiente

No final desta série, terás uma verdadeira lista de grupos menos visíveis que merecem uma segunda olhadela.

Leia este primeiro artigo sobre Operadores de Backup e ficará com uma lista de verificação concreta para auditoria e monitorização que poderá pôr em prática ainda esta semana. Depois, volte para ver o próximo grupo da lista.

Vamos mergulhar no assunto.


Que direitos têm, na realidade, os operadores de backup?

Este é um daqueles grupos do Active Directory que parece aborrecido… mas que, na verdade, é perigoso.

Os administradores de segurança tendem a não dar importância a isso porque não é tão chamativo como o grupo «Domain Admins». Isso é um erro. Nos bastidores, este grupo possui direitos que podem dar origem a abusos graves — e, nas mãos erradas, catastróficos.

Os membros da Backup Operators têm:

  • SeBackupPrivilege: Ler qualquer ficheiro no sistema, ignorando as ACLs do NTFS
  • SeRestorePrivilege: Escrever ou sobrescrever qualquer ficheiro no sistema, ignorando novamente as ACLs
  • SeShutdownPrivilege: Desligar o sistema
  • Possibilidade de iniciar sessão localmente por predefinição em controladores de domínio e servidores

Por que é que os privilégios dos operadores de cópia de segurança criam um problema no domínio — rapidamente

Os direitos deste grupo são, tecnicamente, direitos locais, mas num controlador de domínio têm um impacto imediato em todo o domínio. Um «Operador de Cópias de Segurança» comprometido pode aceder a um controlador de domínio, desligá-lo ou ler, escrever e sobrescrever ficheiros críticos, independentemente das permissões NTFS. Isso inclui ntds.dit, ramos do registo, ficheiros binários protegidos, caminhos de serviços e destinos de tarefas agendadas.

ntds.dit é a base de dados do AD, pelo que é aqui que tudo acaba. Se um atacante conseguir criar uma cópia de sombra desse ficheiro e obter o SYSTEM colmeia, podem extrato os hashes NTLM dos utilizadores do domínio, as chaves Kerberos, os segredos relacionados com o DPAPI e os dados relativos às contas de serviço com privilégios, mantidos fora de linha.

Tradução: Eles controlam-te.

Trata-se, basicamente, de um ataqueDCSync… semrecorrer ao DCSync. As equipas que se protegem contra este tipo de ataques costumam estar atentas aos direitos de replicação, à atividade do porta 4662 ou a outros indicadores de replicação. Os operadores de cópias de segurança podem contornar esses controlos copiando a base de dados diretamente — o resultado final é o mesmo, mas o caminho é diferente e é muito mais fácil passar despercebido.

A restauração dos direitos também é importante. Um atacante pode sobrescrever ficheiros protegidos, substituir ficheiros binários como, por exemplo, sethc.exe ou utilman.exe, alterar os ficheiros executáveis dos serviços ou alterar os destinos das tarefas agendadas.

Por outras palavras, um operador de cópias de segurança cuja segurança tenha sido comprometida pode roubar as chaves e instalar uma porta traseira.


Mesmo sem acesso ao controlador de domínio, o risco continua a ser grave

Em qualquer servidor em que a conta possa iniciar sessão, os Operadores de Cópia de Segurança podem ler tudo — incluindo ficheiros pertencentes a SYSTEM. Esse acesso pode expor dados do registo, diretórios de aplicações, repositórios de cópias de segurança e qualquer outra coisa gravada no disco, partindo do princípio de que as permissões NTFS irão protegê-los. (HA! NÃO!)

Isso significa, muitas vezes, que as credenciais de contas de serviço, as credenciais de domínio armazenadas utilizadas por aplicações ou tarefas de cópia de segurança, as cadeias de ligação a bases de dados, os tokens de API, os dados Kerberos e as chaves privadas dos certificados ficam acessíveis.

Os operadores de cópias de segurança são, muitas vezes, um trampolim durante os ataques — não o objetivo final.


Percursos de escalamento a partir dos Operadores de Cópia de Segurança

Os atacantes também podem abusar dos direitos de restauração para gravar DLLs maliciosas em percursos protegidos, substituir ficheiros binários de serviços, modificar definições de arranque ou de recuperação e forçar a execução como SYSTEM.

Uma vez que as contas do grupo «Operadores de Cópia de Segurança» são frequentemente consideradas de confiança, podem acabar por ser atribuídas a servidores de cópia de segurança, escapar a alguns controlos de reforço de segurança ou funcionar com menos supervisão do que os grupos de administradores mais evidentes.


Por que razão as pessoas subestimam os riscos associados ao grupo dos operadores de backup

Ouço isto constantemente:

  • «Eles não são administradores.»
  • «Não podem alterar objetos do AD.»
  • «As contas de reserva precisam de acesso alargado.»
  • «As nossas ferramentas já estão a monitorizar a utilização abusiva da replicação.»

Tudo isso desmorona-se assim que um atacante copia o ntds.dit e registo.


«Então, o que fazemos?»

É simples: esvazie o grupo, acompanhe as alterações nos membros e mantenha-o vazio. Se não houver ninguém no grupo «Operadores de Cópia de Segurança», ninguém poderá abusar dele.

Essa é a melhor resposta possível e, francamente, aquela que eu gostaria que mais equipas aceitassem antes de um fornecedor as convencer a tomar uma decisão imprudente.

Mas raramente é assim tão simples. Na resposta a incidentes, vejo isto constantemente:

  • Um fornecedor afirma que a sua aplicação «requer» operadores de cópias de segurança.
  • As contas são adicionadas ao grupo.
  • Todos seguem em frente.

Se estiver nessa situação, o objetivo é reduzir o risco da forma mais enérgica possível e deixar de tratar estas contas como contas de baixo impacto.


Primeiro: Aplicar a classificação por níveis

As contas de operadores de cópias de segurança devem ser consideradas identidades adjacentes ao Nível 0. Se uma conta puder ajudar um atacante a aceder à sua base de dados do AD, aos seus segredos privilegiados ou aos seus servidores mais sensíveis, trata-se de uma conta de Nível 0.

  1. Mantenha o grupo vazio, acompanhe as alterações na composição do grupo e considere qualquer exceção como de alto risco.
  2. Nunca permita que os operadores de cópias de segurança iniciem sessão nos controladores de domínio a menos que não exista nenhuma alternativa viável. Utilizar Deny log on locally e Deny log on through Remote Desktop Services. E restringir essas contas apenas a servidores de cópia de segurança específicos.
  3. Monitorizar os inícios de sessão interativos. As contas de operador de cópias de segurança devem comportar-se como identidades de serviço, e não como pessoas a utilizar o teclado.
  4. Ativar a auditoria avançada do acesso aos ficheiros em ntds.dit, o SYSTEM hive, repositórios de cópias de segurança e locais de configuração das aplicações. Emitir alertas sobre «leituras impossíveis» — tais como 4663—relativamente aos ficheiros aos quais a conta não deve ter acesso apenas através do NTFS.
  5. Tenha cuidado com as ferramentas tais como diskshadow.exe, vssadmin.exe, wbadmin.exe, ntdsutil.exee esentutl.exe, especialmente em servidores de dados, fora dos intervalos de backup ou a partir de sessões interativas.
  6. Reduza o raio de impacto com gMSAs, APIs específicas para cada aplicação, ferramentas modernas de cópia de segurança com privilégios reduzidos e, sempre que possível, infraestruturas de cópia de segurança dedicadas ou isoladas.

Como auditar o uso indevido do SeBackupPrivilege

Auditoria SeBackupPrivilege A sua utilização é complicada porque o Windows não regista SeBackupPrivilege was used diretamente.

É possível verificar quando são atribuídos privilégios especiais a um início de sessão, mas não existe um evento claro que mostre o privilégio exercido sobre um ficheiro específico. A deteção baseia-se no contexto, no acesso ao ficheiro, no comportamento do processo e na correlação.

Começar com o evento 4672, que mostra quando um utilizador inicia sessão e recebe SeBackupPrivilege ou SeRestorePrivilege. Indica quando a sessão teve início e restringe o âmbito da pesquisa. Os operadores de cópia de segurança nos DCs, em servidores que não sejam de cópia de segurança ou em sessões interativas devem destacar-se imediatamente.

Em seguida, ative a auditoria avançada do sistema de ficheiros e aplique SACLs ao que é realmente importante:

  • C:\Windows\NTDS\ntds.dit
  • O SYSTEM colmeia
  • SAM
  • Repositórios de cópias de segurança
  • Diretórios de configuração das aplicações

Eventos como o 4663 e, quando pertinente, o 4656, mostram o que foi efetivamente afetado.

O sinal mais claro é a «leitura impossível» — uma leitura bem-sucedida de um ficheiro ao qual o utilizador não deveria ter acesso apenas com base nas permissões do NTFS. Se a conta for de um Operador de Cópias de Segurança, foi o privilégio de cópia de segurança que tornou isso possível.

  • 4672: Quem iniciou sessão com o privilégio
  • 4663: Que ficheiros protegidos ou caminhos de instantâneos foram lidos
  • 4688: Que processo ou ferramenta tornou isso possível?
  • Contexto: Onde aconteceu, quando aconteceu, se foi interativo e se fazia sentido do ponto de vista operacional

A telemetria de criação de processos acrescenta mais uma camada. Ativar 4688 com registo na linha de comandos e monitorizar ntdsutil.exe, diskshadow.exe, wbadmin.exe, esentutl.exe, vssadmin.exe, e comandos «copy» ou do PowerShell direcionados para percursos confidenciais. A combinação de 4672, 4688e 4663 é aí que começam as deteções de elevada fiabilidade.


Como detetar o uso indevido de cópias de sombra

O uso indevido das cópias de sombra merece uma atenção especial, pois é uma das formas mais discretas de contornar os bloqueios de ficheiros e copiar dados confidenciais de um sistema em funcionamento sem deixar rasto. Num servidor de domínio, isso significa normalmente que ntds.dit e o SYSTEM hive. Noutros contextos, pode referir-se a «hives» do registo, segredos de aplicações e material de cópia de segurança.

Para detetar isso de forma eficaz, é necessário recorrer à auditoria à criação de processos, à auditoria ao sistema de ficheiros em percursos sensíveis e à visibilidade dos inícios de sessão com privilégios. O registo da linha de comandos é importante porque o nome do processo, por si só, não indica se um instantâneo foi criado, exposto ou a partir do qual foi feita uma cópia.

Os indicadores de sinal forte incluem vssadmin.exe, diskshadow.exe, wbadmin.exe, ntdsutil.exee esentutl.exe gerido por uma organização não-SYSTEM utilizador, especialmente num servidor DC, fora dos intervalos de cópia de segurança conhecidos ou a partir de uma sessão interativa. Os scripts do DiskShadow executados a partir de diretórios temporários merecem uma análise mais aprofundada.

Um dos indicadores mais significativos é o acesso a percursos que incluem HarddiskVolumeShadowCopy. Lê a partir desses caminhos — especialmente visando ntds.dit, SYSTEM, ou SAM—por um não-SYSTEM O utilizador deve ser considerado como tendo cometido abuso até prova em contrário.

  • 4672 a mostrar SeBackupPrivilege atribuído a um Operador de Cópias de Segurança ou a uma conta com privilégios semelhantes
  • 4688 que mostra a execução de ferramentas relacionadas com o VSS, tais como diskshadow, vssadmin, wbadmin, ntdsutil, ou esentutl
  • 4663 exibindo leituras a partir de um caminho de cópia de sombra, ntds.dit, o SYSTEM colmeia, SAM, ou outro alvo protegido
  • Atividade que ocorre num curto intervalo de tempo, especialmente num controlador de domínio ou noutro sistema de Nível 0
  • A utilização interativa, a programação ad hoc ou a execução fora do calendário normal de cópias de segurança aumentam ainda mais a confiança

Conclusão: «Backup Operators» merece atenção

Os «Operadores de Cópia de Segurança» parecem inofensivos, mas, na prática, estão perigosamente próximos de comprometer totalmente o domínio.

O abuso deste grupo num DC pode expor a base de dados de diretórios, contornar deteções centradas na replicação, recolher credenciais offline e estabelecer persistência através da substituição de ficheiros protegidos. Mesmo sem acesso ao DC, os mesmos direitos podem expor credenciais de serviços, segredos de aplicações e vias de escalonamento em todo o parque de servidores.

A resposta correta consiste em tratar estas contas como altamente sensíveis. Mantenha o grupo vazio sempre que possível, restrinja os locais onde as contas podem iniciar sessão, monitorize os inícios de sessão com privilégios e o acesso a ficheiros sensíveis, esteja atento ao comportamento das cópias de sombra e parta do princípio de que a violação é grave até poder excluir a possibilidade de acesso aos dados que importam.

Acompanhe a conversa sobre os Operadores de Backup no LinkedIn.

E se pretender ajuda especializada para identificar e colmatar as falhas de segurança do seu AD, contacte-nos para uma Avaliação de Segurança do Active Directory. Estamos aqui para o ajudar.

Ler mais