Você conseguiu um shell num sistema Linux — mas como um usuário comum, sem poderes. Raramente um comprometimento inicial te dá o topo; quase sempre você entra por baixo (um serviço rodando com privilégios limitados, um usuário sem importância) e precisa escalar até o root, o superusuário que pode tudo. A escalação de privilégios é uma das habilidades mais usadas e valorizadas do pentest, porque é o que transforma um acesso limitado em controle total. Esta aula sistematiza os caminhos de escalação em Linux — e você já conhece o primeiro deles, das permissões da aula Permissões, donos e privilégios: onde a escalação começa. Sempre em laboratório (a Metasploitable e as salas de privesc do TryHackMe são ideais).

Escalar começa por enumerar

O primeiro passo de toda escalação não é atacar — é enumerar localmente. Uma vez dentro, você precisa entender onde está e o que há de explorável: quem você é, o que pode fazer, o que roda na máquina, o que está mal configurado. É a mesma filosofia "enumerate, enumerate, enumerate" da aula Consolidando a enumeração: do inventário ao plano de ataque, agora aplicada de dentro. Os comandos que você roda ao pisar num Linux comprometido, muitos já vistos na aula Linux essencial: o terminal é a sua bancada:

id ; whoami                    # quem sou eu, meus grupos
uname -a                       # versão do kernel (para exploits de kernel)
sudo -l                        # o que posso rodar como root via sudo
find / -perm -4000 2>/dev/null # binários SUID
cat /etc/crontab               # tarefas agendadas
ps aux                         # processos em execução (o que roda como root?)
netstat -tulnp                 # serviços escutando (inclusive só-locais)
cat /etc/passwd                # usuários do sistema

LinPEAS: velocidade com entendimento

Rodar isso manualmente ensina, mas há scripts que automatizam a enumeração de escalação, varrendo dezenas de vetores de uma vez — o mais famoso é o LinPEAS. Ele examina o sistema e destaca, colorindo por probabilidade, os caminhos de escalação encontrados. O profissional usa o LinPEAS para velocidade, mas entende cada vetor que ele aponta — de novo, a ferramenta amplifica quem compreende.

SUID como primeiro vetor

Agora os vetores de escalação propriamente ditos, organizados por família. O primeiro você já domina: os binários SUID (aula Permissões, donos e privilégios: onde a escalação começa). Lembre — um binário SUID de root roda com privilégios de root independentemente de quem o executa; se um deles pode ser abusado para executar comandos ou abrir um shell, você vira root. O find / -perm -4000 lista os candidatos, e o GTFOBins (o catálogo da aula Permissões, donos e privilégios: onde a escalação começa) te diz quais binários comuns são abusáveis e como. Encontrar um binário incomum com SUID de root é frequentemente o caminho mais rápido.

Sudo mal configurado

O segundo vetor é o sudo mal configurado. O sudo -l mostra o que você pode executar como root sem (ou com) senha. Às vezes revela um caminho direto — permissão para rodar um programa que, como o SUID, pode ser abusado para escapar para um shell de root (o GTFOBins também cobre isso, para o contexto sudo). Uma configuração sudo permitindo rodar um editor, um interpretador, ou certas ferramentas frequentemente equivale a entregar o root.

Cron job gravável

O terceiro vetor são os cron jobs — tarefas agendadas que o sistema executa periodicamente, muitas vezes como root. A vulnerabilidade clássica: um cron job que roda como root executa um script que você pode editar. Se você tem permissão de escrita sobre um script que o root executa a cada minuto, você coloca seu código nele e espera — na próxima execução, seu código roda como root. Examinar o /etc/crontab e as permissões dos scripts referenciados é um vetor fértil, que combina o conhecimento de cron com o de permissões (aula Permissões, donos e privilégios: onde a escalação começa).

Kernel exploit e sua ressalva

O quarto vetor são os kernel exploits. Se o uname -a revela um kernel antigo e sem correções, pode haver um exploit público de escalação para aquela versão específica — um programa que, explorando uma falha no próprio núcleo do sistema, concede root. É poderoso, mas com uma ressalva importante de responsabilidade: exploits de kernel são frequentemente instáveis e podem travar o sistema (kernel panic). Por isso são um recurso mais arriscado, usado com cautela e, em testes reais, com acordo — derrubar o servidor do cliente com um kernel exploit malfeito é um incidente sério. Prefira os vetores de configuração (SUID, sudo, cron) quando existirem; eles são mais confiáveis e menos destrutivos.

Há ainda outros vetores que a enumeração revela e que vale conhecer: credenciais em arquivos (senhas hardcoded em scripts, arquivos de configuração, históricos de comando — o .bash_history da aula Linux essencial: o terminal é a sua bancada; a reutilização de senhas descobertas aqui alimenta a movimentação lateral), permissões de arquivo frouxas em arquivos sensíveis (um /etc/passwd ou /etc/shadow gravável é escalação garantida), capabilities do Linux mal atribuídas, e serviços internos vulneráveis rodando como root. A escalação é, no fundo, um exercício de encontrar a peça mal configurada num sistema cheio de peças — e a enumeração paciente é o que a revela.

O hardening de escalação

Do lado defensivo, cada vetor tem sua contramedida, e juntas elas formam o hardening de escalação em Linux: aplicar o princípio do menor privilégio rigorosamente (a raiz de tudo); auditar binários SUID (o mesmo find -perm -4000 que o atacante usa, para remover o que não deveria ter SUID); configurar sudo com cuidado (não conceder programas abusáveis); proteger cron jobs (garantir que scripts executados por root não sejam editáveis por usuários comuns); manter o kernel e o sistema atualizados (fechando os exploits de kernel — eco do EternalBlue); e jamais deixar credenciais em arquivos. A auditoria defensiva usa as mesmas ferramentas de enumeração (inclusive LinPEAS) para encontrar e fechar esses caminhos antes do atacante.

Fontes e leituras recomendadas

Exercícios

  1. Por que a enumeração local é o primeiro passo da escalação, e a que princípio já visto isso se conecta?

    ✓ Resposta:

    Porque, para escalar, é preciso primeiro entender onde se está e o que há de explorável (usuário, privilégios, configurações, o que roda como root). Conecta-se ao princípio "enumerate, enumerate, enumerate" (aula Consolidando a enumeração: do inventário ao plano de ataque), agora aplicado de dentro do sistema.

  2. Explique o vetor de escalação por binário SUID e o papel do GTFOBins.

    ✓ Resposta:

    Um binário SUID roda com os privilégios do dono (root) independentemente de quem o executa; se puder ser abusado para executar comandos ou abrir um shell, concede root. O find / -perm -4000 lista os SUID, e o GTFOBins indica quais binários comuns são abusáveis e como.

  3. Descreva a vulnerabilidade clássica de cron job que leva à escalação para root.

    ✓ Resposta:

    Um cron job executado como root roda um script sobre o qual o usuário comum tem permissão de escrita. O atacante edita esse script inserindo seu código; na próxima execução agendada, o código roda com privilégios de root.

  4. Por que os kernel exploits, apesar de poderosos, devem ser usados com cautela, e qual a alternativa preferível quando disponível?

    ✓ Resposta:

    Porque exploits de kernel são frequentemente instáveis e podem causar kernel panic, derrubando o sistema — um risco sério em ambientes reais. A alternativa preferível são os vetores de configuração (SUID, sudo, cron), mais confiáveis e menos destrutivos, quando disponíveis.

  5. Cite três contramedidas defensivas contra a escalação de privilégios em Linux.

    ✓ Resposta:

    Aplicar menor privilégio, auditar/remover binários SUID desnecessários, configurar sudo com cuidado, proteger cron jobs (scripts não editáveis por usuários comuns), manter kernel/sistema atualizados e não deixar credenciais em arquivos. (Três quaisquer.)