🥇Usando PowerShell para elevação de privilégios em contas locais

Elevação de privilégios é o uso, por um invasor, dos direitos atuais da conta para obter acesso adicional, geralmente em um nível mais alto no sistema. Embora a elevação de privilégios possa resultar da exploração de vulnerabilidades de dia zero, ou do trabalho de hackers de alto nível realizando um ataque direcionado, ou ainda de um malware bem disfarçado, na maioria das vezes isso ocorre devido à configuração inadequada do computador ou da conta. Ao desenvolver ainda mais o ataque, os invasores utilizam uma série de vulnerabilidades separadas, o que pode levar a uma vazamento de dados catastrófico.

Por que os usuários não devem ter direitos de administrador local?

Se você é um especialista em segurança, isso pode parecer óbvio, mas os usuários não devem ter direitos de administrador local, pois isso:

Torna suas contas mais vulneráveis a vários ataques
Torna esses ataques muito mais graves

Infelizmente, para muitas organizações, essa ainda é uma questão muito controversa e muitas vezes acompanhada de acalorados debates (veja, por exemplo, meu gerente diz que todos os usuários devem ser administradores locais). Sem entrar nos detalhes dessa discussão, acreditamos que um invasor obteve direitos de administrador local no sistema em questão: seja por meio de um exploit ou devido ao fato de que as máquinas não estavam devidamente protegidas.

Passo 1. Resolução reversa de nomes DNS via PowerShell

Por padrão, o PowerShell está instalado em muitas estações de trabalho locais e na maioria dos servidores Windows. E embora não seja exagero considerá-lo uma ferramenta de automação e gerenciamento extraordinariamente útil, ele também pode se transformar em um quase invisível malware fileless (um programa de invasão que não deixa vestígios do ataque).

No nosso caso, o invasor começa a realizar a reconhecimento de rede usando um script PowerShell, percorrendo sequencialmente o espaço de endereçamento IP da rede, tentando determinar se o determinado IP é resolvido para um nó e, se sim, qual é o nome da rede desse nó.
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 muito rico sobre cada nó:

 import-module activedirectory Get-ADComputer -property * -filter { ipv4address -eq '10.10.10.10'}

Se a velocidade de operação em grandes redes causar problemas, pode-se usar uma chamada de retorno de sistema DNS:

[System.Net.Dns]::GetHostEntry('10.10.10.10').HostName

Esse método de enumeração de nós na rede é muito popular, pois a maioria das redes não utiliza um modelo de segurança de confiança zero e não monitora solicitações DNS internas em picos suspeitos de atividade.

Passo 2: Seleção do Alvo

O resultado final deste passo é a obtenção de uma lista de nomes de host de servidores e estações de trabalho que pode ser usada para prosseguir com o ataque.

A julgar pelo nome, o servidor 'HUB-FILER' parece um alvo digno, pois, com o tempo, servidores de arquivos tendem a acumular uma grande quantidade de pastas de rede e acesso excessivo a elas por um número amplo de pessoas.

A visualização com o Windows Explorer nos permite determinar a existência de uma pasta compartilhada aberta, mas nossa conta atual não pode acessá-la (provavelmente, temos apenas permissões para listagem).

Passo 3: Analisando ACL

Agora, no nosso host HUB-FILER e na pasta compartilhada alvo share, podemos executar um script PowerShell para obter a lista de ACL. Podemos fazer isso a partir da máquina local, já que temos direitos de administrador local:

(get-acl hub-filershare).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –auto

Resultado da execução:

A partir disso, vemos que o grupo Usuários de Domínio tem acesso apenas para listagem, mas o grupo Helpdesk também possui direitos de modificação.

Passo 4: Identificação de Contas

Executando Get-ADGroupMember, conseguiremos obter todos os membros desse grupo:

Get-ADGroupMember -identity Helpdesk

Nesta lista, vemos a conta do computador que já identificamos e à qual já temos acesso:

Passo 5: Usando PSExec para operar a partir da conta do computador

PsExec da Microsoft Sysinternals permite executar comandos no contexto da conta do sistema SYSTEM@HUB-SHAREPOINT, que sabemos ser membro do grupo alvo Helpdesk. Isso significa que podemos simplesmente executar:

PsExec.exe -s -i cmd.exe

Agora você tem acesso total à pasta HUB-FILERshareHR, pois está operando no contexto da conta de computador HUB-SHAREPOINT. Com esse acesso, os dados podem ser copiados para um dispositivo de armazenamento portátil ou extraídos e transferidos pela rede.

Passo 6: Detecção deste ataque

Essa vulnerabilidade específica nas permissões de configuração das contas (contas de computador acessando pastas de rede compartilhadas em vez de contas de usuários ou contas de serviço) pode ser detectada. No entanto, sem as ferramentas adequadas, isso é muito difícil.

Para detectar e prevenir essa categoria de ataques, podemos usar DatAdvantage para identificar grupos com contas de computador dentro deles e, em seguida, restringir seu acesso. DatAlert vai além e permite criar um aviso especificamente para esse cenário.

Na captura de tela abaixo, está um aviso personalizado que será acionado sempre que uma conta de computador acessar dados no servidor monitorado.