Escalada de Privilégios Explicada: Guia Linux e Windows (2026)

O que é escalada de privilégios?

O que é escalada de privilégios? Escalada de privilégios é obter acesso a recursos ou capacidades que uma conta de usuário, aplicação ou processo não recebeu originalmente, normalmente passando de um contexto restrito para um contexto administrativo. Em um ataque, é a etapa entre "eu tenho algum acesso" e "eu tenho o acesso que realmente quero".

Quase nenhuma invasão começa com root. Um atacante entra por meio de uma credencial obtida por phishing, uma aplicação web vulnerável ou um serviço exposto, e esse acesso inicial quase sempre vem com permissões limitadas: uma conta de servidor web pouco privilegiada, um usuário de domínio padrão, uma conta de serviço restrita a uma única tarefa. A escalada de privilégios é o que transforma esse ponto de apoio estreito em controle da máquina, e frequentemente em controle de toda a rede, uma vez que esse acesso permite movimento lateral.

O MITRE ATT&CK trata isso como uma tática própria, TA0004, com dezenas de técnicas documentadas mapeadas nela, o que reflete o quanto essa etapa é central em quase toda cadeia real de invasão. Em um trabalho profissional, ela costuma acontecer durante a fase de pós-exploração da metodologia de teste de invasão, logo após o acesso inicial e antes do movimento lateral ou da conclusão do objetivo.

Escalada horizontal vs. vertical

A escalada de privilégios se divide em duas direções, e a distinção importa porque cada uma explora uma classe diferente de falha.

Escalada vertical

Escalada vertical é subir na hierarquia de privilégios, de um usuário padrão para administrador, de uma conta de aplicação web para root, ou de um usuário de domínio para Domain Admin. É o que a maioria das pessoas quer dizer com "privesc", e é o foco deste guia. Um usuário pouco privilegiado que explora um binário SUID para obter um shell root é um exemplo clássico de escalada vertical.

Escalada horizontal

Escalada horizontal é obter acesso a uma conta diferente no mesmo nível de privilégio, não em um nível superior. Um cliente que edita o parâmetro de URL da própria fatura para visualizar a fatura de outro cliente realizou uma escalada horizontal: continua com um papel de usuário comum, apenas com dados de outra pessoa. Isso se sobrepõe bastante ao controle de acesso quebrado e às falhas de Insecure Direct Object Reference no lado web, enquanto a escalada vertical vive mais no sistema operacional, na configuração de serviços e no kernel.

Como funcionam os ataques de escalada de privilégios

Assim que um atacante tem qualquer shell, o processo segue um padrão previsível independente do sistema operacional: enumerar a máquina, procurar uma configuração incorreta ou vulnerabilidade específica, explorá-la e confirmar o novo nível de privilégio.

Os atacantes raramente enumeram todo um sistema de arquivos manualmente hoje em dia. Eles rodam um script automatizado como o LinPEAS no Linux ou o WinPEAS no Windows, que verifica a máquina contra uma longa lista de configurações incorretas conhecidas em poucos minutos e destaca o que encontra em uma saída colorida. Esses scripts não exploram nada sozinhos. Eles apontam a porta; ainda é preciso abri-la.

Na prática, em uma máquina de CTF recém-comprometida ou em um alvo de projeto real, rodar o LinPEAS é um dos três primeiros comandos digitados depois de conseguir um shell. Raramente ele entrega a resposta de bandeja, mas indica exatamente onde procurar em seguida, seja um script de cron gravável, um binário SUID que não deveria estar ali, ou uma versão de kernel com exploit público.

1. Estabeleça o ponto de partida. Confirme o usuário atual, seus grupos e quaisquer permissões de sudo ou capabilities já concedidas antes de mexer em qualquer coisa.
2. Rode a enumeração automatizada. LinPEAS ou WinPEAS revela as configurações incorretas óbvias em minutos e indica onde concentrar o esforço manual.
3. Investigue manualmente os achados sinalizados. Confirme que cada caminho candidato realmente funciona antes de se comprometer com ele, já que as ferramentas automatizadas sinalizam possibilidades, não garantias.
4. Explore e verifique. Execute a escalada e confirme o novo nível de privilégio com id ou whoami /priv antes de continuar.

Técnicas de escalada de privilégios no Linux

A escalada de privilégios no Linux quase sempre remete a uma entre um punhado de categorias de configuração incorreta. Aprenda essas cinco e você conseguirá resolver a maioria dos hosts Linux vulneráveis que encontrar em labs ou em projetos reais.

Binários SUID e SGID

Um binário com o bit SUID marcado é executado com as permissões do seu proprietário, não do usuário que o executa. Encontre todos os binários SUID da máquina com find / -perm -4000 -type f 2>/dev/null. A maioria dos resultados são binários de sistema legítimos como o passwd, mas qualquer entrada inesperada, ou um binário legítimo com capacidades perigosas, vale a pena verificar.

Ao encontrar um binário SUID desconhecido, verifique-o no GTFOBins, um projeto que documenta como binários Unix comuns podem ser abusados para contornar restrições de segurança locais. Se o binário SUID encontrado aparecer lá, o GTFOBins fornece o comando exato para abrir um shell root. Um exemplo clássico: se o próprio find tiver o bit SUID marcado, find . -exec /bin/sh -p \; -quit entrega um shell root diretamente, porque o find executa o comando com seus próprios privilégios elevados.

Configurações incorretas de sudo

Rode sudo -l para ver o que o usuário atual pode executar como root sem senha. Uma linha como (ALL) NOPASSWD: /usr/bin/vim parece inofensiva até você verificar o vim no GTFOBins e descobrir que vim -c ':!/bin/sh' escapa direto para um shell root, porque o vim herda a permissão de sudo e pode iniciar qualquer processo. Toda regra de sudo para um interpretador, editor ou gerenciador de arquivos merece essa verificação antes de ser considerada segura.

Sequestro de tarefas cron

Tarefas cron que rodam como root mas chamam um script gravável pelo usuário atual são um caminho direto para root. Verifique /etc/crontab e /etc/cron.d/ em busca de tarefas, e depois verifique as permissões do script ou binário que cada uma chama. Se uma tarefa cron pertencente ao root executa /opt/backup.sh e esse arquivo é gravável por qualquer usuário, basta acrescentar uma linha de reverse shell a esse arquivo e esperar a próxima execução agendada. Pratique exatamente esse cenário no lab Cronpocalypse, construído em torno de uma configuração de cron vulnerável.

Sequestro de PATH

Quando um script ou tarefa cron pertencente ao root chama um binário sem o caminho completo, como tar em vez de /bin/tar, o shell resolve isso procurando nos diretórios listados em $PATH, na ordem. Se um diretório gravável pelo atacante estiver mais cedo nessa ordem de busca, ou for colocado no início do $PATH, um binário malicioso com o mesmo nome é executado no lugar do real, herdando o privilégio do script que o chamou.

Exploits de kernel

Quando a enumeração não revela mais nada, a própria versão do kernel vira o último recurso. Dirty COW (CVE-2016-5195) é o exemplo mais conhecido, uma condição de corrida no tratamento de mapeamento de memória copy-on-write do kernel que permitia que qualquer usuário local escrevesse em arquivos mapeados em memória marcados como somente leitura, incluindo binários pertencentes ao root. Exploits de kernel funcionam de forma confiável contra sistemas sem correção, mas trazem risco real de travar o alvo, então são uma opção de último recurso em projetos, e algo a evitar totalmente sem autorização explícita para causar instabilidade.

Técnicas de escalada de privilégios no Windows

A escalada no Windows depende menos de um único bit de permissão e mais da configuração de serviços, permissões de arquivo, e de como o Windows resolve caminhos e tokens. As técnicas principais abaixo cobrem a maioria dos hosts Windows vulneráveis.

Caminhos de serviço sem aspas

Quando o caminho do executável de um serviço Windows contém espaços e não está entre aspas, como C:\Program Files\My App\service.exe, o Windows tenta cada segmento delimitado por espaço como um executável possível, na ordem: C:\Program.exe, depois C:\Program Files\My.exe, antes de finalmente tentar o caminho completo pretendido. Se um atacante conseguir escrever em algum desses diretórios pais, colocar um Program.exe malicioso faz com que ele seja executado com os privilégios do serviço, muitas vezes SYSTEM, na próxima vez que o serviço reiniciar.

Permissões de serviço fracas

Mesmo com um caminho corretamente entre aspas, se o usuário atual tiver acesso de escrita ao binário do serviço ou à sua configuração no registro, substituir o executável ou redirecionar o ImagePath para um binário malicioso alcança o mesmo resultado. Ferramentas como accesschk ou WinPEAS enumeram exatamente quais serviços um determinado usuário pode modificar.

AlwaysInstallElevated

Quando duas chaves de registro, HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated e sua equivalente em HKCU, estão ambas definidas como 1, qualquer usuário pode instalar um pacote MSI com privilégios SYSTEM, independentemente do seu próprio nível de permissão. Um atacante monta um MSI malicioso com msfvenom, roda msiexec /quiet /qn /i malicious.msi, e ganha um shell SYSTEM. Nosso guia rápido de msfvenom cobre a construção de payloads como esse.

Personificação de token

Contas de serviço frequentemente têm o direito SeImpersonatePrivilege, que permite que um processo personifique o token de segurança de outro usuário que se conecta a ele. Ferramentas construídas em torno dessa técnica, comumente chamadas de ataques Potato, enganam um serviço de nível SYSTEM para se autenticar em um listener controlado pelo atacante, e depois reutilizam esse token capturado para abrir um processo SYSTEM. É um dos caminhos de escalada mais confiáveis contra serviços Windows modernos e bem corrigidos, justamente por abusar de um recurso pretendido em vez de um bug.

Linux vs. Windows: referência rápida

Os dois sistemas falham de formas diferentes. A escalada no Linux costuma girar em torno de permissões de arquivo e scripts interpretados; a escalada no Windows costuma girar em torno da configuração de serviços e do tratamento de tokens. Use esta tabela para ir direto ao vetor mais provável no seu alvo.

Vulnerabilidades reais de escalada de privilégios

Essas não são apenas técnicas de laboratório. Cada uma das seguintes ficou em software de produção por anos antes de ser descoberta e foi ativamente explorada assim que se tornou pública.

PwnKit (CVE-2021-4034) ficou sem ser descoberta no utilitário pkexec do Polkit por mais de doze anos antes de a Qualys divulgá-la em janeiro de 2022. Ela funcionava de imediato, sem nenhuma configuração especial, em instalações padrão de Ubuntu, Debian, Fedora e CentOS, permitindo que qualquer usuário local chegasse a root com um único binário especialmente criado.

Dirty COW (CVE-2016-5195) explorava uma condição de corrida em como o kernel Linux tratava mapeamentos de memória copy-on-write, permitindo que um usuário local sem privilégios escrevesse em arquivos mapeados em memória marcados como somente leitura. Ela afetava praticamente toda versão de kernel Linux em uso na época e esteve presente no kernel por nove anos antes de uma correção ser lançada.

PrintNightmare (CVE-2021-34527) tinha como alvo o serviço Windows Print Spooler, que roda como SYSTEM e vem habilitado por padrão na maioria das instalações Windows. Uma falha na validação de solicitações de instalação de driver permitia que um usuário autenticado instalasse um driver de impressora malicioso e executasse código como SYSTEM. A Cybersecurity and Infrastructure Security Agency emitiu uma diretiva de emergência sobre isso, uma medida rara reservada para vulnerabilidades sob exploração ativa e generalizada; leia o comunicado completo no site da CISA.

Como prevenir a escalada de privilégios

Como prevenir a escalada de privilégios? Nenhum controle único a impede. Prevenção é uma pilha de higiene de configuração e monitoramento que remove as configurações incorretas específicas nas quais os atacantes se apoiam.

• Aplique o privilégio mínimo. Contas de serviço e usuários de aplicação devem ter apenas as permissões que sua função exige, nada a mais "só por precaução".
• Audite regularmente binários SUID e regras do sudoers. Remova o bit SUID de tudo que não precisa dele, e nunca conceda acesso sudo NOPASSWD a um interpretador, editor ou binário capaz de abrir um shell.
• Corrija em um ritmo real. PwnKit e Dirty COW eram ambos corrigíveis com uma atualização. A maioria das escaladas bem-sucedidas em nível de kernel acontece em sistemas que já estavam meses atrasados nas correções.
• Coloque aspas em todo caminho de serviço que contenha espaços, e restrinja o acesso de escrita aos binários de serviço e seus diretórios pais.
• Desative o AlwaysInstallElevated a menos que haja um motivo de negócio específico e documentado, e verifique isso em qualquer revisão de hardening do Windows.
• Monitore padrões de abuso conhecidos. Produtos de EDR podem sinalizar abusos no estilo GTFOBins e tentativas de personificação de token no estilo Potato, mas só se estiverem ajustados para observar especificamente isso.

Ao testar aplicações e hosts reais, a forma mais rápida de encontrar essas brechas antes de um atacante é rodar a mesma enumeração que um atacante rodaria: LinPEAS ou WinPEAS, uma auditoria de sudoers e uma verificação de permissões de serviço, em um cronograma regular, não apenas uma vez na implantação.

Considerações legais e éticas

Toda técnica deste guia é exatamente o que um atacante real usa para transformar um ponto de apoio em comprometimento total. A única diferença entre um pentester e um criminoso rodando os mesmos comandos é a autorização, documentada por escrito antes do primeiro comando.

Pratique legalmente em três lugares: programas de bug bounty com escopo publicado em plataformas como HackerOne e Bugcrowd, projetos remunerados sob um contrato de trabalho assinado, e plataformas de laboratório isoladas ou eventos de CTF construídos especificamente para serem quebrados. Tudo acima é escrito apenas para esses três cenários.