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

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

O que é escalação de privilégios Linux? A escalação de privilégios Linux é a técnica de obter em um sistema Linux permissões superiores às da sua conta atual, geralmente passando de um usuário padrão ou de serviço para root. Ela explora configurações incorretas locais, e não a falha remota que lhe deu o shell no início.

O acesso inicial raramente o coloca como root. Uma aplicação web vulnerável roda como www-data, um serviço de banco de dados comprometido roda sob seu próprio usuário restrito, uma chave SSH lhe dá uma conta de login comum. Nenhum deles consegue ler /etc/shadow, instalar uma porta dos fundos persistente ou pivotar com controle total. O root consegue. A escalação é a ponte entre os dois, e o MITRE ATT&CK a rastreia como uma tática própria, TA0004, porque quase toda intrusão séria depende dela.

Boa notícia para quem aprende: a escalação no Linux é, na esmagadora maioria, uma questão de configuração, não de corrupção de memória. Você não precisa escrever uma única linha de assembly para virar root na maioria das máquinas. Você precisa enumerar com cuidado e reconhecer um punhado de padrões. Essa é uma habilidade construída pela repetição, não pelo talento.

Passo 1 - Enumerar a máquina

A enumeração é onde todo shell root começa. Antes de tentar qualquer coisa, você monta um retrato do sistema: quem você é, o que pode executar, e onde a máquina confia em algo que não deveria.

Comece pelos três comandos que não custam nada e muitas vezes entregam a resposta de cara:

id                    # your UID, GID, and group memberships
sudo -l               # what you can run as root, with or without a password
find / -perm -4000 -type f 2>/dev/null   # every SUID binary on the system

A participação em grupos naquela primeira linha importa mais do que os iniciantes imaginam. Se o id mostrar você no grupo docker, lxd ou disk, você tem um caminho quase imediato para root antes de olhar qualquer outra coisa, já que cada um desses grupos pode ser abusado para ler ou escrever além do limite do seu usuário.

A partir daí, amplie a rede: verifique o kernel com uname -a, liste as tarefas agendadas em /etc/crontab e /etc/cron.d/, procure capabilities com getcap -r / 2>/dev/null, e leia quaisquer arquivos de configuração legíveis por todos nas raízes web e nos diretórios pessoais em busca de credenciais armazenadas. Na prática, senhas de banco de dados jogadas em um config.php ou em um arquivo .env são um dos caminhos reais mais comuns, e nenhuma ferramenta automatizada as prioriza para você.

Fazer tudo isso à mão leva tempo, então a maioria dos testadores executa um script de enumeração automatizado para varrer a máquina em uma passada. Nosso guia do LinPEAS cobre a instalação, a execução sem tocar o disco e a leitura de sua saída colorida: vermelho sobre amarelo sinaliza um caminho de escalação de alta probabilidade. O script não explora nada. Ele diz onde olhar; você ainda tem de abrir a porta.

Binários SUID e SGID

O bit SUID (Set User ID) diz ao Linux para executar um binário com as permissões de seu dono, não do usuário que o lançou. Quando o dono é root, qualquer usuário que possa executar esse binário roda o código dele como root durante a execução. Isso é intencional para ferramentas como o passwd, que precisa escrever em /etc/shadow. Vira um caminho de escalação quando o bit SUID cai sobre um binário que pode ser induzido a executar comandos arbitrários.

Sua saída de find / -perm -4000 lista todos os candidatos. A maioria das entradas são binários de sistema padrão. O que você procura é qualquer coisa incomum: uma cópia de find, nmap, vim, python, ou uma ferramenta interna caseira com o bit ativado. Cruze cada entrada desconhecida com o GTFOBins, um catálogo de binários Unix e da sintaxe exata para abusar deles.

O exemplo clássico: se o find carrega o próprio bit SUID, este único comando lhe dá um shell root, porque o find executa o shell gerado com seus próprios privilégios elevados:

find . -exec /bin/sh -p \; -quit
# id
uid=0(root) gid=0(root) groups=0(root)

O parâmetro -p no shell é a parte que as pessoas esquecem. Sem ele, o bash e o sh abandonam os privilégios elevados na inicialização como recurso de segurança, e você acaba de volta ao seu usuário original se perguntando por que o exploit falhou.

Configurações incorretas de sudo

Execute sudo -l e leia cada linha. Ela mostra exatamente quais comandos seu usuário pode executar como root, e cada um é um candidato. Uma regra como (ALL) NOPASSWD: /usr/bin/vim parece uma conveniência administrativa inofensiva até você verificar o GTFOBins para o vim:

sudo vim -c ':!/bin/sh'

Isso escapa para um shell root, porque o vim roda como root sob a regra sudo e pode gerar um processo filho. A mesma lógica vale para awk, less, find, python, tar e dezenas de outros interpretadores e utilitários. Qualquer regra sudo apontando para algo que possa executar código, ler arquivos arbitrários ou escrever arquivos arbitrários merece verificação antes de você supor que é segura.

Dois truques baseados em ambiente valem a pena conhecer. Se o arquivo sudoers tiver env_keep+=LD_PRELOAD, você pode compilar um pequeno objeto compartilhado que gera um shell e pré-carregá-lo em qualquer comando permitido pelo sudo. E versões antigas do sudo trazem vulnerabilidades explícitas: o Baron Samedit (CVE-2021-3156) permitiu que qualquer usuário local chegasse ao root independentemente de sua entrada no sudoers, nas versões do sudo anteriores à 1.9.5p2. Sempre verifique sudo --version contra CVEs conhecidas.

Capabilities do Linux

As capabilities são a prima de grão fino do bit SUID. Em vez de conceder a um binário todo o poder do root, o Linux pode conceder-lhe um privilégio específico, e os administradores às vezes as configuram achando que são a opção mais segura. Muitas vezes não são.

Enumere-as com getcap -r / 2>/dev/null. A que se deve observar é a cap_setuid. Se um interpretador Python a carrega, por exemplo, a saída fica assim:

/usr/bin/python3.11 = cap_setuid+ep

Essa única capability basta para virar root, porque o binário pode definir seu próprio UID como 0 e então executar um shell:

/usr/bin/python3.11 -c 'import os; os.setuid(0); os.system("/bin/sh")'

As capabilities passam despercebidas justamente porque parecem granulares e controladas. Na prática, uma capability cap_setuid ou cap_dac_read_search em um binário scriptável é tão perigosa quanto um binário SUID root puro, e escapa aos revisores que só checam o bit SUID.

Abuso de tarefas cron

Tarefas agendadas que rodam como root mas executam um arquivo que você pode gravar são um dos caminhos de escalação mais limpos no Linux. Verifique /etc/crontab, o diretório /etc/cron.d/ e /etc/cron.daily/ em busca de tarefas, e então olhe as permissões do script que cada tarefa chama.

Se uma tarefa cron root executa /opt/scripts/backup.sh e esse arquivo, ou o diretório que o contém, é gravável pelo seu usuário, você é dono da próxima execução. Acrescente uma carga e espere:

echo 'cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash' >> /opt/scripts/backup.sh
# after the job runs on schedule:
/tmp/rootbash -p
# id -> uid=0(root)

Um curinga em um comando tar ou chown executado por cron abre um ataque relacionado chamado injeção de curinga, no qual nomes de arquivos forjados são interpretados como parâmetros de linha de comando. O sinal a observar é qualquer automação de root que toque um local que um usuário não root possa gravar. Esse descompasso é toda a vulnerabilidade.

Abuso de PATH e de arquivos graváveis

Quando um script de propriedade do root chama um binário apenas pelo nome, tar em vez de /bin/tar, o shell procura nos diretórios de $PATH em ordem e executa a primeira correspondência. Se você puder escrever em um diretório que apareça mais cedo nessa ordem de busca, ou influenciar $PATH antes de o script rodar, seu tar malicioso é executado com os privilégios do script. Deixe um script de duas linhas com o nome do binário chamado em um diretório gravável e de maior prioridade, e você herda o root.

Duas verificações de permissão de arquivo pertencem à mesma categoria. Primeiro, um /etc/passwd gravável é o fim do jogo: adicione uma linha com um hash de senha conhecido e um UID de 0, depois faça su para essa conta. Segundo, um /etc/shadow gravável, ou legível com um hash de root quebrável, alimenta diretamente a quebra de senhas offline. Sempre execute ls -l /etc/passwd /etc/shadow cedo, pois uma única permissão frouxa aqui encerra o trabalho.

Exploits de kernel

Quando os caminhos baseados em configuração não dão em nada, a própria versão do kernel vira o alvo. Este é um último recurso, não um primeiro movimento, porque exploits de kernel podem travar a máquina e tirar o alvo do ar, o que raramente é aceitável em um trabalho real sem aprovação explícita.

Os dois nomes a conhecer: o PwnKit (CVE-2021-4034) explorou o componente pkexec do Polkit e deu root a qualquer usuário local em instalações padrão de Ubuntu, Debian, Fedora e CentOS, depois de ficar sem ser descoberto por mais de doze anos. O Dirty Pipe (CVE-2022-0847) permitiu que um usuário sem privilégios sobrescrevesse dados em arquivos somente leitura em kernels a partir do 5.8, inclusive o /etc/passwd, tornando o root trivial.

Compare a versão do kernel obtida com uname -r às CVEs conhecidas antes de recorrer a um exploit, e confirme que o alvo é um lab ou um trabalho onde a instabilidade é autorizada. Uma máquina de produção travada é um problema muito maior do que uma flag de root perdida.

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

Mantenha esta ordem de enumeração ao lado do seu terminal. Ela vai das verificações mais propensas a dar retorno rápido às que você aciona quando os caminhos fáceis se esgotam.

Como se defender

Como prevenir a escalação de privilégios Linux? Remova as configurações incorretas específicas das quais os atacantes dependem. Nenhum controle isolado a impede por completo, mas cada caminho acima se fecha com uma correção concreta e barata.

• Remova bits SUID desnecessários. Audite com find / -perm -4000 e retire o bit de tudo que não precise dele de verdade. Nada caseiro deve carregá-lo sem revisão.
• Nunca conceda sudo NOPASSWD a interpretadores. Uma regra sudo para vim, awk, python ou find é uma porta aberta para um shell root. Restrinja as regras sudo a ações específicas e não scriptáveis.
• Revise as capabilities dos arquivos. Execute getcap -r / durante o endurecimento e trate cap_setuid em qualquer binário de uso geral como equivalente a um bit SUID root.
• Tranque os scripts cron. Tarefas agendadas de propriedade do root devem chamar arquivos de propriedade do root em diretórios de propriedade do root, sem acesso de escrita para mais ninguém.
• Aplique correções em um ritmo real. PwnKit e Dirty Pipe foram ambos corrigidos por uma atualização. A maioria das escalações de kernel bem-sucedidas atinge sistemas atrasados em meses.

Ao testar máquinas reais, o jeito mais rápido de encontrar essas falhas antes de um atacante é executar a mesma enumeração que um atacante faria, LinPEAS mais uma revisão manual de sudoers e capabilities, 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 de o trabalho começar.

Pratique legalmente em três lugares: programas de bug bounty dentro de seu escopo publicado, trabalhos remunerados sob um contrato de serviço assinado, e plataformas de labs isoladas feitas para serem quebradas. Tudo acima foi escrito para esses três e nada mais.