
Escalonamento de privilégios é o uso por um invasor dos direitos da conta atual para obter um nível adicional, geralmente mais alto, de acesso ao sistema. Apesar do fato de que a escalação de privilégios pode ser o resultado da exploração de vulnerabilidades de dia zero ou o trabalho de hackers de primeira classe que conduzem um ataque direcionado ou um malware adequadamente disfarçado, mas na maioria das vezes isso ocorre devido à configuração incorreta do computador ou da conta. Desenvolvendo o ataque ainda mais, os invasores exploram várias vulnerabilidades separadas, que juntas podem levar a um vazamento de dados catastrófico.
Por que os usuários não deveriam ter direitos de administrador local?
Se você é um especialista em segurança, pode parecer óbvio que os usuários não devem ter direitos de administrador local, como este:
- Torna suas contas mais vulneráveis a vários ataques.
- Torna esses ataques muito mais graves.
Infelizmente, para muitas organizações, esse ainda é um assunto muito controverso e, às vezes, é acompanhado por discussões acaloradas (veja, por exemplo,
meu gerente diz que todos os usuários devem ser administradores locais ). Sem entrar nos detalhes desta discussão, acreditamos que o invasor obteve os direitos de um administrador local no sistema sob investigação: por meio de uma exploração ou porque as máquinas não estavam protegidas adequadamente.
Etapa 1. Inverter a resolução de nomes DNS através do PowerShell
Por padrão, o PowerShell é instalado em muitas estações de trabalho locais e na maioria dos servidores Windows. Embora não sem exagero, é considerada uma ferramenta incrivelmente útil para automação e controle, é igualmente capaz de se transformar em um
malware sem arquivo quase invisível (um programa de hackers que não deixa vestígios de um ataque).
No nosso caso, o invasor começa a executar o reconhecimento de rede usando o script do PowerShell, classificando sequencialmente o espaço de endereço IP da rede, tentando determinar se esse IP é permitido ao host e, em caso afirmativo, qual é o nome da rede desse host.
Existem várias maneiras de realizar essa tarefa, mas o uso do cmdlet
Get- ADComputer é uma opção confiável, pois retorna um conjunto de dados realmente rico sobre cada nó:
import-module activedirectory Get-ADComputer -property * -filter { ipv4address -eq '10.10.10.10'}
Se a velocidade do trabalho em redes grandes causar problemas, o retorno de chamada do sistema DNS poderá ser usado:
[System.Net.Dns]::GetHostEntry('10.10.10.10').HostName

Esse método de listagem de hosts em uma rede é muito popular, pois a maioria das redes não usa um modelo de segurança de confiança zero e não rastreia solicitações DNS internas para picos de atividade suspeitos.
Etapa 2: seleção de metas
O resultado final desta etapa é obter uma lista de nomes de host de servidores e estações de trabalho que podem ser usados para continuar o ataque.

A julgar pelo nome, o servidor 'HUB-FILER' parece ser um objetivo digno, porque com o tempo, os servidores de arquivos tendem a acumular um grande número de pastas de rede e acesso excessivo a elas por muitas pessoas.
A visualização com o Windows Explorer nos permite determinar se existe uma pasta compartilhada aberta, mas nossa conta atual não pode acessá-la (provavelmente só temos direitos de listagem).
Etapa 3: Aprenda a ACL
Agora, no host HUB-FILER e na pasta de compartilhamento de destino, podemos executar o script do PowerShell para obter a ACL. Podemos fazer isso na máquina local, pois já temos direitos de administrador local:
(get-acl \\hub-filer\share).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –auto
Resultado da execução:

A partir dele, vemos que o grupo Usuários do Domínio tem acesso apenas à listagem, mas o grupo de Suporte Técnico também tem o direito de alterar.
Etapa 4: identificar contas
Executando
Get-ADGroupMember , podemos obter todos os membros deste grupo:
Get-ADGroupMember -identity Helpdesk

Nesta lista, vemos uma conta de computador que já identificamos e que já acessamos:

Etapa 5: use o PSExec para trabalhar em uma conta de computador
O PsExec do Microsoft Sysinternals permite executar comandos no contexto da conta do sistema SYSTEM @ HUB-SHAREPOINT, que, como sabemos, é membro da força-tarefa do Helpdesk. Ou seja, é o suficiente para executarmos:
PsExec.exe -s -i cmd.exe
Bem, você tem acesso total à pasta de destino \\ HUB-FILER \ share \ HR, pois trabalha no contexto da conta do computador HUB-SHAREPOINT. E com esse acesso, os dados podem ser copiados para um dispositivo de armazenamento portátil ou recuperados e transferidos pela rede.
Etapa 6: detectar este ataque
Essa vulnerabilidade específica para definir privilégios de conta (contas de computador acessando pastas de rede compartilhadas em vez de contas de usuário ou contas de serviço) pode ser detectada. No entanto, sem as ferramentas certas, isso é muito difícil.
Para detectar e impedir essa categoria de ataques, podemos usar o
DatAdvantage para identificar grupos com contas de computador e, em seguida, fechar o acesso a eles.
O DatAlert vai além e permite que você crie uma notificação especificamente para esse cenário.
A captura de tela abaixo mostra uma notificação do usuário que será acionada sempre que uma conta de computador acessar dados em um servidor monitorado.

Próximas etapas usando o PowerShell
Deseja saber mais? Use o código de desbloqueio do "blog" para obter acesso gratuito ao
curso em vídeo completo do
PowerShell e aos Fundamentos do Active Directory .