Quem Virou Root: Identificando Escalada de Privilégio em Logs de Autenticação Linux
O desafio
Algo nesta máquina Linux escalou para root. Administradores reais usam sudo o dia todo, então isso sozinho não é suspeito. Mas uma conta que deveria apenas rodar backups foi adicionada ao grupo sudo e logo em seguida abriu um shell root. Leia o log de autenticação, separe a atividade normal de admin, e envie a conta que escalou para root.
O que você vai aprender
- Ler eventos de log de autenticação e sudo do Linux como uma linha do tempo de comportamento
- Diferenciar o sudo rotineiro de admin de uma escalada anômala
- Reconhecer a cadeia usermod para sudo seguida de shell root
- Usar o propósito da conta como base para o que é normal
- Atribuir uma escalada de privilégio a uma conta específica
Habilidades testadas
Pré-requisitos
- Familiaridade com usuários, grupos e sudo no Linux
- Entendimento sobre contas de serviço versus contas interativas
- Conhecimento sobre su e shells root
Como funciona
Em um host Linux, escalar para root é normal - administradores fazem isso dezenas de vezes por dia com sudo. Então você não pode sinalizar toda ação privilegiada; você precisa saber o que cada conta deveria fazer e identificar aquela cujo comportamento quebra sua linha de base. Essa linha de base é a ideia central: uma conta de serviço como svc_backup existe para executar uma única tarefa (backup.sh) em um horário programado. Ela nunca deveria fazer login interativo, nunca ser adicionada a um grupo privilegiado, e nunca abrir um shell root.
Leia o log como uma linha do tempo e a cadeia para svc_backup se destaca: ela se autentica via SSH com uma senha a partir de um IP externo (203.0.113.45) em vez de rodar via cron, então root executa usermod -aG sudo svc_backup para conceder sudo a ela, e segundos depois ela executa sudo /bin/su - para abrir uma sessão root interativa completa. Dentro dessa sessão ela lê /etc/shadow, cria um novo usuário, e baixa e executa um script - atividade clara de pós-escalada. Enquanto isso, alice, bob, carol e dave usam sudo apenas para tarefas rotineiras de comando único e nunca recebem uma mudança de grupo ou um shell root.
É por isso que event:usermod e event:session são os filtros de maior valor. A escalada não é um único evento - é a combinação de um login fora do padrão, uma concessão de grupo, e um shell root, tudo na mesma conta que não é de admin.
Erros comuns
- Sinalizar a primeira conta que você vê usando sudo. O sudo de admin é ruído de fundo constante aqui; a escalada é a conta que nunca deveria tê-lo.
- Enviar root como resposta.
rootaparece nas linhas de usermod e session, mas a pergunta é qual conta escalou para root - essa conta ésvc_backup. - Parar na linha do usermod. Ser adicionado ao sudo é metade da história; a confirmação é o shell root
su -que vem em seguida. - Ignorar o propósito da conta. Sem saber que
svc_backupé uma conta de serviço apenas para backup, a atividade parece apenas mais um admin.
Como se proteger
Escalada de privilégio é detectável quando você alerta sobre mudanças em quem pode se tornar root, não apenas sobre a atividade root em si. Estabeleça uma linha de base para cada conta e observe os desvios.
- Alerte imediatamente sobre
usermodou mudanças de grupo que adicionem uma conta asudoouwheel, especialmente uma conta de serviço. - Proíba logins SSH interativos e por senha para contas de serviço - restrinja-as a um comando específico via forced command ou unidade systemd.
- Alerte quando uma conta que não é de admin abrir um shell root (
su -ousudo -i). - Use o princípio do menor privilégio: dê à conta de backup apenas as capacidades exatas que ela precisa, nunca sudo irrestrito.