Backdoor Linux `PamDOORa` usa módulos `PAM` para persistência em `SSH` e coleta de credenciais

PamDOORa é oferecido em fórum russo como ferramenta de pós-exploração para servidores Linux x86_64, com senha mágica, gatilho por porta TCP, captura de credenciais e adulteração de logs de autenticação.

Componente	Backdoor Linux PamDOORa, implementado como módulo malicioso para a pilha PAM e voltado a autenticação via OpenSSH em sistemas x86_64.
Vetor	Implantação pós-exploração após obtenção prévia de privilégio root, seguida de alteração de módulos ou configuração PAM para interferir no fluxo de autenticação.
Impacto	Persistência por acesso SSH com senha mágica e combinação específica de porta TCP, além de captura de credenciais de usuários legítimos que se autenticam no host comprometido.
Prioridade	Auditar integridade de módulos e arquivos de configuração PAM, revisar alterações recentes em autenticação SSH, preservar logs antes de rotação e investigar sinais de adulteração antiforense.
Artefatos	Módulos PAM, fluxo OpenSSH, possível uso de pam_exec, logs de autenticação e binários ou scripts associados ao mecanismo de persistência.
Mitigação	Remover módulos não autorizados, restaurar configurações PAM conhecidas, rotacionar credenciais expostas, revisar chaves SSH e reconstruir hosts quando houver perda de confiança no privilégio root.

Resumo técnico

PamDOORa é um backdoor Linux posicionado como ferramenta de pós-exploração para ambientes em que o operador já conseguiu controle privilegiado do host. O implante usa a modularidade do PAM para interferir no processo normal de autenticação e criar um caminho persistente de entrada via OpenSSH. A característica mais relevante é que a persistência não depende apenas de criar uma conta local ou adicionar uma chave pública: o mecanismo atua em uma camada consultada por serviços que delegam autenticação ao PAM, o que permite manipular decisões de login e observar segredos apresentados por usuários legítimos durante sessões reais.

O backdoor foi anunciado no fórum russo Rehub por uma persona chamada darkworm. O preço inicial informado em 17 de março de 2026 foi de US$ 1.600, reduzido para US$ 900 em 9 de abril de 2026. Esse dado não comprova uso operacional, mas mostra tentativa de comercialização de uma ferramenta que combina técnicas já conhecidas, como ganchos em PAM, captura de credenciais e adulteração de logs, em um pacote mais integrado. Até o contexto técnico disponível, não há evidência confirmada de campanhas em produção usando PamDOORa; a avaliação defensiva deve tratar o artefato como risco de pós-comprometimento, especialmente em servidores Linux expostos por SSH ou usados como ponto de administração de infraestrutura.

Fluxo técnico

A cadeia provável começa fora do próprio PamDOORa: o operador precisa obter acesso administrativo por outro vetor, como credencial roubada, exploração de serviço, abuso de chave SSH, falha de configuração ou outro meio que permita escrita em áreas sensíveis do sistema. Com privilégio root, o invasor pode instalar um módulo PAM malicioso ou alterar a configuração que orienta quais módulos participam da autenticação. Como módulos PAM costumam executar com alto privilégio e recebem valores de autenticação durante o processamento, qualquer alteração maliciosa nesse ponto amplia o impacto de uma intrusão que já chegou ao sistema operacional.

O diferencial operacional de PamDOORa está na combinação de senha mágica e porta TCP específica para liberar autenticação persistente via OpenSSH. Em vez de depender de um usuário administrativo visível ou de um arquivo simples em diretórios de inicialização, o backdoor se conecta ao fluxo legítimo de login. Quando as condições esperadas pelo implante são satisfeitas, o processo de autenticação pode ser desviado para permitir acesso não autorizado. Quando usuários legítimos se autenticam, o mesmo ponto de interceptação pode capturar credenciais em texto claro durante a passagem pelo PAM, porque o framework não é um cofre de senhas; ele recebe e encaminha os valores necessários para que módulos de autenticação tomem decisões.

O contexto também descreve capacidades antiforenses. A adulteração de logs de autenticação reduz a visibilidade de acessos feitos pelo canal secreto e dificulta reconstruir uma linha do tempo apenas com registros locais. Isso aumenta a importância de telemetria externa, como logs enviados em tempo real para coletores remotos, registros de rede, trilhas de EDR e históricos de alteração de arquivo. Em hosts nos quais o root foi comprometido, logs locais devem ser tratados como evidência potencialmente incompleta, principalmente quando há lacunas em eventos de sshd, divergência entre conexões de rede e autenticações registradas ou ausência de falhas esperadas em tentativas de acesso.

Superfície afetada

A superfície principal são servidores Linux x86_64 que usam PAM para autenticação e expõem OpenSSH para administração. O risco é maior em sistemas que concentram acesso de operadores, bastions, hosts de automação, servidores de build, nós de infraestrutura e máquinas que recebem logins frequentes de contas com privilégios. Nessas condições, um módulo malicioso consegue observar credenciais de múltiplos usuários e transformar um único host comprometido em ponto de coleta para movimentos laterais. Ambientes de nuvem também entram no escopo quando instâncias Linux mantêm SSH habilitado para administração direta ou quando imagens base e scripts de provisionamento não validam a integridade da pilha de autenticação.

A presença de PamDOORa não deve ser inferida apenas por tráfego externo incomum. O implante foi descrito como dependente de um gatilho de autenticação, o que significa que pode permanecer silencioso até que a combinação esperada seja usada ou até que usuários legítimos façam login. A ausência de processos persistentes óbvios não elimina a hipótese, porque a persistência pode residir no caminho de autenticação. Arquivos de configuração em /etc/pam.d/, bibliotecas de módulos em diretórios de segurança do sistema, referências a módulos incomuns e alterações em componentes relacionados ao sshd são pontos de inspeção mais relevantes do que somente listas de serviços ativos.

• Servidores Linux x86_64 com OpenSSH e autenticação integrada ao PAM.
• Hosts em que um invasor já obteve privilégio root ou capacidade equivalente de modificar módulos e arquivos de autenticação.
• Bastions, servidores administrativos, instâncias de nuvem e sistemas que concentram logins interativos de operadores.
• Configurações PAM que chamam módulos externos ou executam scripts, incluindo cenários em que pam_exec é usado sem controle rígido de integridade.

Hunting e telemetria

A investigação deve começar pela integridade do fluxo de autenticação, não apenas por indicadores de arquivo específicos, porque o material analisado não inclui hash, caminho fixo de instalação ou nome de binário confiável. Compare /etc/pam.d/sshd e outros arquivos de /etc/pam.d/ com uma imagem base conhecida, repositório de configuração ou pacote original da distribuição. Procure inclusões novas, ordem de módulos alterada, chamadas a módulos fora do padrão, uso inesperado de pam_exec e scripts referenciados por caminhos graváveis. Em paralelo, valide bibliotecas de módulos PAM contra o gerenciador de pacotes da distribuição e identifique arquivos sem origem conhecida, com carimbo de tempo recente ou permissões incompatíveis.

Como o backdoor pode apagar rastros de autenticação, a caça deve correlacionar múltiplas fontes. Conexões aceitas em sshd, sessões abertas, registros de wtmp, btmp, lastlog, eventos de sudo, trilhas de EDR, fluxo de rede e logs centralizados precisam contar a mesma história. Divergências entre conexão de rede e evento de autenticação, sessões interativas sem histórico coerente, redução incomum de falhas de login, lacunas em períodos de atividade administrativa e alteração de permissões em arquivos de log são sinais que justificam escalonamento da análise. Quando houver coleta remota em tempo real, priorize esses registros sobre artefatos locais do host comprometido.

No endpoint, monitore escrita em diretórios de módulos PAM, mudanças em /etc/pam.d/, criação de bibliotecas compartilhadas desconhecidas, execução de scripts por pam_exec e reinícios ou recargas de sshd próximos das alterações. Em rede, procure conexões SSH para portas não usuais quando houver política que restringe administração a caminhos definidos. A combinação descrita de senha mágica e porta TCP torna relevante revisar exceções de firewall, regras de grupos de segurança, DNAT e listeners auxiliares, sem assumir que o backdoor sempre cria um serviço separado.

• Diferença entre arquivos /etc/pam.d/ atuais e versões esperadas pela distribuição ou por gerenciamento de configuração.
• Módulos PAM sem correspondência no banco do gerenciador de pacotes, com alteração recente ou permissões anormais.
• Referências inesperadas a pam_exec, scripts externos ou bibliotecas fora dos diretórios padrão de segurança.
• Eventos de rede SSH sem autenticação correspondente em logs locais ou centralizados.
• Lacunas, truncamento ou rotação fora do padrão em logs de autenticação após alterações em PAM ou sshd.
• Sessões administrativas sem histórico coerente em wtmp, lastlog, shell history, EDR e registros de comando.

Mitigação

A resposta deve partir da premissa de que a presença de um módulo PAM malicioso implica comprometimento privilegiado. Remover o arquivo suspeito pode interromper uma técnica de persistência, mas não prova que o invasor perdeu acesso nem que credenciais coletadas deixaram de ser válidas. Isole o host da rede administrativa, preserve uma imagem ou coleta forense antes de mudanças destrutivas, exporte logs centralizados e capture estado de processos, conexões, módulos carregados, pacotes instalados e arquivos de autenticação. Em seguida, compare a pilha PAM com uma referência confiável e restaure configurações a partir de artefatos versionados ou pacotes oficiais.

Quando houver suspeita forte, a reconstrução do host é mais defensável do que limpeza manual, porque o operador que instalou PamDOORa teria root e poderia ter implantado outros mecanismos de acesso. A contenção também precisa cobrir credenciais: senhas usadas no servidor após a janela provável de comprometimento devem ser rotacionadas, chaves SSH revisadas, tokens de automação revogados e contas privilegiadas auditadas. Para bastions e servidores de administração, verifique se credenciais capturadas permitem acesso a nuvem, repositórios, pipelines, bancos de dados ou painéis internos.

A prevenção exige controle de mudança e integridade sobre autenticação. Arquivos /etc/pam.d/ devem ser gerenciados por configuração declarativa, com revisão de alterações e alerta para drift. Diretórios de módulos precisam de monitoramento de escrita, validação por pacote e política de permissões restritiva. Logs de autenticação devem ser enviados para coletor remoto de forma contínua, reduzindo a eficácia de adulteração local. Em SSH, reduza exposição, aplique autenticação forte, desative caminhos não usados, limite usuários permitidos e monitore portas administrativas fora do padrão. Para ambientes de nuvem, confirme que grupos de segurança, regras de firewall e imagens base não mantêm exceções antigas que permitam contornar bastions ou controles de identidade.

• Isolar hosts suspeitos e preservar evidências antes de remover módulos, limpar logs ou reiniciar serviços.
• Comparar /etc/pam.d/, módulos PAM e configuração de sshd com uma referência confiável da distribuição ou do gerenciamento de configuração.
• Reconstruir sistemas quando houver confirmação de alteração maliciosa com privilégio root.
• Rotacionar senhas, revisar chaves SSH, revogar tokens e auditar contas que se autenticaram no host durante a janela de risco.
• Enviar logs de autenticação para armazenamento remoto e alertar para alterações em /etc/pam.d/, uso de pam_exec e módulos sem origem conhecida.
• Restringir SSH por rede, identidade e política de acesso, removendo portas administrativas não justificadas.