FERRAMENTAS LINUX: Detecção e Remoção do SSH Persistence no Linux

Guia avançado para detecção e remoção de persistência SSH em Linux. Auditoria de authorized_keys, análise temporal, remediação e hardening para profissionais de infraestrutura.

A persistência via SSH (SSH Persistence) é uma das técnicas mais silenciosas e eficazes no arsenal de um invasor.

Diferentemente de um ataque de força bruta ou da exploração de uma vulnerabilidade zero-day, a adição de uma chave pública ao arquivo authorized_keys não gera logs de falha, não dispara alertas de autenticação e não exige que o invasor mantenha uma shell interativa constante.

O login ocorre com normalidade, a sessão se abre de forma limpa e a conta já existe no servidor.

O problema é agravado pelo fato de que a maioria dos ambientes já possui tráfego SSH constante entre administradores, sistemas de automação, infraestrutura de backup, pipelines de deploy e workloads em nuvem.

Uma sessão maliciosa não se destaca imediatamente quando o mesmo protocolo já está lidando com acesso operacional legítimo durante todo o dia.

Este guia aborda de forma prática e aprofundada como identificar chaves SSH não autorizadas, revisar atividades de login, investigar acessos suspeitos e determinar se a persistência já se espalhou além da conta originalmente comprometida.

Público-alvo: Administradores de infraestrutura com conhecimento intermediário/avançado em linha de comando.

Pré-requisitos

Acesso root ou sudo ao sistema alvo.

Conhecimento sólido de SSH e do ecossistema OpenSSH.

Familiaridade com find, grep, stat, awk e sed.

Compreensão do MITRE ATT&CK T1098.004 (Account Manipulation: SSH Authorized Keys).

Idealmente, acesso a logs históricos de autenticação (/var/log/auth.log ou journalctl).

Passo a Passo

1. Auditoria do Arquivo authorized_keys

O primeiro passo é examinar o arquivo authorized_keys do usuário atual e do root.

# Verificar chaves do usuário atual
cat ~/.ssh/authorized_keys

# Verificar chaves do root
sudo cat /root/.ssh/authorized_keys

Por que isso importa: Ataques de persistência via SSH começam com a modificação do arquivo authorized_keys. O invasor adiciona sua própria chave pública para poder reconectar-se posteriormente sem precisar das credenciais originais novamente.

O que observar atentamente:

Nomes de usuário ou e-mails desconhecidos.

Chaves duplicadas em múltiplas contas.

Entradas adicionadas recentemente.

Comentários incomumente longos ou fora do padrão.

Contas que não deveriam mais ter acesso shell.

Chaves associadas a ex-funcionários

Atenção: Contas administrativas são as que mais importam aqui. Uma chave maliciosa anexada a uma conta com regras sudo ou acesso root concede ao invasor persistência de longo prazo que pode sobreviver a patches, redefinições de senha e remediações parciais.

Sistemas Linux mais antigos tendem a acumular acesso abandonado ao longo do tempo — contas de contratados, usuários antigos de deploy, credenciais de CI/CD que ninguém rotacionou após uma migração.

2. Análise Temporal dos Arquivos SSH

Invasores raramente param após adicionar uma única chave. Uma vez que a persistência funciona, eles frequentemente modificam arquivos SSH adicionais para garantir que o acesso sobreviva a uma limpeza posterior.

# Verificar o diretório .ssh e seus arquivos
ls -la ~/.ssh

# Timestamps detalhados do arquivo de chaves
stat ~/.ssh/authorized_keys

# Verificar configuração do daemon SSH
sudo stat /etc/ssh/sshd_config

Por que isso importa: Horários de modificação inesperados geralmente delimitam rapidamente a investigação, especialmente em sistemas de produção onde as configurações SSH não mudam com frequência.

Padrões suspeitos:

Múltiplos arquivos SSH modificados na mesma janela temporal.

Mudanças de configuração não documentadas.

Atividade na conta root fora do horário de manutenção.

Isoladamente, essas mudanças podem não parecer graves, mas o quadro muda rapidamente quando a mesma atividade começa a aparecer em múltiplos arquivos SSH e contas administrativas.

3. Busca Global por Arquivos authorized_keys

Uma conta comprometida raramente é todo o problema. Uma vez que os invasores obtêm acesso shell, eles geralmente espalham a persistência para usuários secundários, contas de serviço esquecidas, perfis de deployment ou infraestrutura de backup que ninguém revisa ativamente.

# Localizar TODOS os arquivos authorized_keys no sistema
sudo find / -name authorized_keys 2>/dev/null

# Buscar por arquivos modificados nos últimos 7 dias
sudo find /home -name authorized_keys -mtime -7

# Buscar por arquivos modificados em um período específico (ex: últimos 30 dias)
sudo find / -name authorized_keys -mtime -30 2>/dev/null

Por que isso importa: Perder uma conta não deve remover completamente o acesso do invasor. Esse é exatamente o objetivo da persistência distribuída.

Dica profissional: O período de tempo deve mudar dependendo da investigação e da janela de comprometimento suspeita. Em investigações de longo prazo, considere usar -mtime -90 ou até -mtime -365.

4. Análise de Logs de Autenticação

A detecção de persistência SSH não se limita a arquivos estáticos. Logs de autenticação revelam padrões de acesso que podem indicar o uso de chaves não autorizadas.

# Verificar logins bem-sucedidos nos últimos 7 dias
sudo grep "Accepted publickey" /var/log/auth.log | tail -50

# Usando journalctl em sistemas systemd
sudo journalctl -u ssh -g "Accepted publickey" --since "7 days ago"

# Verificar logins de contas específicas
sudo grep "Accepted publickey for usuario" /var/log/auth.log

# Identificar chaves usadas em logins recentes (fingerprint)
sudo grep "Accepted publickey" /var/log/auth.log | awk '{print $NF}' | sort | uniq -c | sort -nr

Por que isso importa: Cada login bem-sucedido com chave pública gera uma entrada no log de autenticação. Analisar esses registros permite correlacionar chaves suspeitas com atividade real de acesso.

5. Verificação de Configurações Suspeitas no sshd_config

Alterações no sshd_config podem redirecionar o arquivo authorized_keys para um local alternativo ou modificar comportamentos de autenticação.

# Verificar local do authorized_keys na configuração
sudo grep -i authorizedkeysfile /etc/ssh/sshd_config

# Verificar outras configurações sensíveis
sudo grep -E "PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AllowUsers|DenyUsers" /etc/ssh/sshd_config

# Verificar inclusões de configuração (Include)
sudo grep -i include /etc/ssh/sshd_config

Por que isso importa: Invasores podem modificar o caminho do authorized_keys para um local fora do diretório .ssh do usuário, escapando de auditorias superficiais.

6. Detecção de Persistência via PAM e Outros Mecanismos

Além do authorized_keys, invasores podem estabelecer persistência através de módulos PAM maliciosos, scripts em .bashrc, cron jobs e serviços systemd.

# Verificar módulos PAM suspeitos
sudo grep -v "^#" /etc/pam.d/sshd | grep -v "^$"

# Verificar arquivos de inicialização de shell
for user in $(getent passwd | cut -d: -f1); do
    [ -f /home/$user/.bashrc ] && echo "=== $user ===" && grep -v "^#" /home/$user/.bashrc | grep -v "^$"
done

# Verificar cron jobs de todos os usuários
sudo cat /etc/crontab
sudo ls -la /etc/cron.d/
sudo ls -la /var/spool/cron/crontabs/

# Verificar serviços systemd suspeitos
sudo systemctl list-unit-files --type=service --all | grep -E "^(ssh|backdoor|persist|dev|tmp|test)"

Por que isso importa: Persistência via SSH é apenas uma das muitas técnicas. Uma auditoria completa deve considerar o espectro completo de mecanismos de persistência. O MITRE ATT&CK lista systemd services (T1501) e cron-based persistence (T1053.003) como técnicas igualmente relevantes.

7. Automação com Scripts de Auditoria

Para ambientes com múltiplos servidores, a automação é essencial. Um script básico de auditoria:

#!/bin/bash
# ssh_persistence_audit.sh - Auditoria de persistência SSH

REPORT="/tmp/ssh_audit_$(date +%Y%m%d_%H%M%S).txt"

echo "=== SSH Persistence Audit Report ===" > $REPORT
echo "Data: $(date)" >> $REPORT
echo "" >> $REPORT

# 1. Listar todos os authorized_keys
echo "=== ALL authorized_keys files ===" >> $REPORT
sudo find / -name authorized_keys 2>/dev/null >> $REPORT

# 2. Verificar arquivos modificados nos últimos 7 dias
echo "" >> $REPORT
echo "=== authorized_keys modified in last 7 days ===" >> $REPORT
sudo find / -name authorized_keys -mtime -7 2>/dev/null >> $REPORT

# 3. Verificar configurações sensíveis do sshd
echo "" >> $REPORT
echo "=== SSHD sensitive config ===" >> $REPORT
sudo grep -E "PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AuthorizedKeysFile" /etc/ssh/sshd_config >> $REPORT

# 4. Logins recentes com chave pública
echo "" >> $REPORT
echo "=== Recent publickey logins ===" >> $REPORT
sudo journalctl -u ssh -g "Accepted publickey" --since "7 days ago" | tail -20 >> $REPORT

echo "Report saved to: $REPORT"

8. Remoção e Remediação

Após identificar chaves não autorizadas, a remoção deve ser cuidadosa para não interromper acesso legítimo.

Remoção manual:

# Fazer backup antes de remover
cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.bak.$(date +%Y%m%d)

# Editar e remover linhas suspeitas
vi ~/.ssh/authorized_keys

# Ou remover por comentário/fingerprint
sed -i '/comentario_suspeito/d' ~/.ssh/authorized_keys

Remoção em massa:

# Remover chaves de todos os usuários que correspondem a um padrão suspeito
for user in $(getent passwd | cut -d: -f1); do
    if [ -f /home/$user/.ssh/authorized_keys ]; then
        sed -i '/padrao_suspeito/d' /home/$user/.ssh/authorized_keys
    fi
done

Pós-remoção:

1. Rotacionar todas as chaves legítimas — chaves comprometidas podem ter sido copiadas.

2. Resetar senhas de todas as contas envolvidas.

3. Revisar sudoers para garantir que não há regras adicionadas.

4. Verificar processos em execução para backdoors ativos.

5. Revisar regras de firewall para portas de saída suspeitas.

9. Hardening Preventivo

A melhor detecção é a prevenção. Implemente estas medidas:

Monitoramento contínuo com FIM (File Integrity Monitoring):

Configure o Wazuh, o OSSEC ou o Auditd para monitorar ~/.ssh/authorized_keys e /etc/ssh/sshd_config

Alertas em tempo real para modificações não autorizadas

Políticas de chave SSH:

# Restringir comandos permitidos via forced commands
command="/usr/bin/rsync --server ...",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAA...

# Usar certificados SSH em vez de chaves individuais
# Configurar AuthorizedKeysCommand para validar chaves via script centralizado

Automação de rotação:

# Script para rotacionar chaves periodicamente
# Revogar chaves de ex-funcionários via cron job diário

Auditoria regular:

Auditoria mensal de todos os arquivos authorized_keys

Revisão trimestral de acessos SSH com eliminação de contas órfãs

📘 Indicação de Leitura

Livro: Segurança em Servidores Linux Ataque e Defesa

Esse livro é um guia prático e abrangente sobre a segurança do sistema operacional Linux como um todo. O livro ensina a pensar como um atacante para fortalecer a defesa do servidor, abordando tópicos fundamentais como:

Ferramentas de rede: Nmap, Netcat, knockd.

Monitoramento: de arquivos e sistemas de arquivos.

Defesas: contra malware e ataques DDoS.

Descoberta de vulnerabilidades: como invasores encontram pontos fracos.

Segurança em Servidores Linux Ataque e Defesa: (anúncio) -> https://link.amazon/B00Oln1Rw

Eu ganho uma comissão quando você faz uma compra.

Troubleshooting

Problema Comum: Chave Legítima Identificada como Suspeita

Cenário: Durante a auditoria, você identifica uma chave que parece suspeita mas pode ser legítima — talvez de um pipeline de CI/CD, um sistema de backup ou um administrador que usa um nome de usuário incomum.

Solução: Antes de remover qualquer chave:

1. Verifique o fingerprint da chave nos logs:

# Extrair fingerprint da chave suspeita
ssh-keygen -l -f ~/.ssh/authorized_keys

# Procurar logins com este fingerprint
sudo grep "fingerprint_do_hash" /var/log/auth.log

2. Correlacione com atividade real:

# Verificar se a chave foi usada recentemente
sudo journalctl -u ssh --since "30 days ago" | grep "Accepted publickey" | grep "fingerprint_parcial"

3. Consulte a equipe:

Documente a chave suspeita

Envie para aprovação antes da remoção

Mantenha um changelog de todas as remoções

4. Crie um whitelist:

# Manter um arquivo de chaves conhecidas para referência
echo "chave_legitima_1" >> /etc/ssh/known_keys_whitelist
echo "chave_legitima_2" >> /etc/ssh/known_keys_whitelist

Armadilha Comum

❌ Erro: Confiar Apenas no Conteúdo do authorized_keys

O problema: Muitos administradores verificam apenas o conteúdo do arquivo ~/.ssh/authorized_keys e ignoram outras formas de persistência SSH.

O que pode ser perdido:

AuthorizedKeysFile redirecionado no sshd_config para um local alternativo

AuthorizedKeysCommand executando um script que retorna chaves dinamicamente

Chaves em contas de serviço que não estão em /home/

Persistência via PAM executando scripts em todo login

Arquivos .ssh/authorized_keys em diretórios não padrão como /opt/, /var/, /srv/

Solução correta:

# NUNCA confie apenas em um único local
# SEMPRE faça uma busca global
sudo find / -name authorized_keys -type f 2>/dev/null

# SEMPRE verifique a configuração do sshd
sudo grep -i authorizedkeysfile /etc/ssh/sshd_config

# SEMPRE verifique Include files
sudo grep -i include /etc/ssh/sshd_config

# SEMPRE verifique PAM
sudo grep -v "^#" /etc/pam.d/sshd | grep -v "^$"

Por que isso é crítico: Um invasor experiente não vai simplesmente adicionar uma chave no local óbvio. Ele vai modificar a configuração para apontar para um local que você não está verificando, garantindo que sua persistência sobreviva à sua auditoria.

Conclusão

A detecção e remoção de persistência via SSH é uma habilidade essencial para qualquer administrador de sistemas Linux. A chave para o sucesso está em:

1. Auditoria abrangente — não se limite ao diretório .ssh do usuário atual

2. Análise temporal — timestamps revelam muito sobre a linha do tempo do comprometimento

3. Busca global — invasores espalham persistência para contas secundárias

4. Correlação com logs — autenticação e atividade real validam descobertas

5. Remediação cuidadosa — remova sem interromper acesso legítimo

6. Prevenção contínua — monitoramento FIM e rotação regular de chaves

Lembre-se: a persistência SSH é silenciosa por natureza. O login ocorre com normalidade, a sessão se abre de forma limpa e a conta já existe no servidor. É exatamente por isso que a auditoria proativa e sistemática é sua melhor defesa.