Além do cofre: o privilégio permanente zero neutraliza mais do que ataques a senhas

Parte 2 de 3 da nossa série Rethinking Privileged Access. Comece pela Parte 1: A senha nunca foi o único problema.

Na Parte 1, traçamos a linha entre o modelo de cofre e check-out do PAM legado e o modelo de sessão e Activities do PAM moderno com o Netwrix Privilege Secure (NPS). Um protege a senha; o outro elimina o privilégio permanente que está por trás dela. Essa abordagem é um bom ponto de partida, mas subestima o problema. No Windows e no Active Directory, a senha é apenas a semente. Tudo o que um invasor usa para se mover lateralmente é derivado dela ou emitido por causa dela: um hash NTLM, um ticket Kerberos, um logon em cache, um certificado, um blob DPAPI. Uma ferramenta de PAM que protege apenas a senha protege um elo de uma cadeia muito mais longa.

É aqui que aparece a verdadeira diferença entre o PAM legado e o PAM moderno. Guardar a senha em um cofre a esconde, mas não toca em nada do que vem depois dela. O NPS remove o privilégio permanente ao rotacionar, desativar ou excluir contas no momento em que a sessão termina. Isso interrompe vários desses caminhos de ataque posteriores, porque a maioria deles depende de uma conta privilegiada existir, em estado utilizável, por mais tempo do que o necessário. O NPS, porém, não impede por completo ameaças de AD como o Kerberoasting. Outros produtos da Netwrix, como o Netwrix Threat Prevention, podem ajudar ao detectar atividades de autenticação suspeitas.

A superfície de credenciais que ninguém coloca em um cofre

Veja o que pode ser atacado em um ambiente Windows/AD além da senha em texto simples:

• Hashes NTLM: utilizáveis diretamente via Pass-the-Hash, sem necessidade de quebra.
• Tickets Kerberos (TGT/TGS): podem ser roubados e reutilizados via Pass-the-Ticket e forjados via Golden e Silver Tickets se a chave do krbtgt ou a chave de uma conta de serviço for comprometida.
• Material vulnerável a Kerberoasting/AS-REP roasting: qualquer usuário do domínio pode solicitar um ticket de serviço para uma conta com SPN, ou um AS-REP para uma conta com pré-autenticação desativada, e quebrá-lo offline.
• Credenciais de domínio em cache (MSCACHEv2): armazenadas no hive SECURITY local de qualquer máquina em que um usuário tenha feito logon.
• Certificados e entradas msDS-KeyCredentialLinkExpand: exploráveis por meio de configuração incorreta de modelos do AD CS ou de ataques de Shadow Credentials, autenticando-se como um usuário sem nunca tocar na senha dele.
• Senhas gerenciadas por LAPS/gMSA: protegidas apenas pela ACL do atributo que as armazena.
• Segredos protegidos por DPAPI: descriptografáveis se um invasor derivar a chave mestra do usuário ou roubar a chave de backup do DPAPI do domínio.

Nenhum desses itens exige a senha em texto simples, e todos concedem algo muito próximo disso.

Por que o privilégio permanente é o fio condutor

Quase todos os itens dessa lista são poderosos apenas porque a conta por trás deles tem privilégios reais agora mesmo e os mantém indefinidamente. Uma configuração de PAM legado, com uma senha guardada no cofre, rotacionada e injetada sobre uma associação permanente ao Domain Admins, ainda deixa um hash NTLM que vale a pena roubar, um TGS que vale a pena atacar com roasting e um logon em cache que vale a pena quebrar entre um check-out e outro.

Os modelos de conta do NPS (solicitante, gerenciada e efêmera, abordados em detalhe na Parte 1) atacam diretamente essa causa raiz comum. As contas gerenciadas são desativadas e rotacionadas novamente assim que a sessão termina, as contas efêmeras são excluídas por completo e até as contas do solicitante só têm associação a grupos elevados durante a sessão.

Como o privilégio tem início e fim em vez de existir para sempre, a maioria dos ataques acima perde o alvo no instante em que a sessão é encerrada. O NPS não precisa detectar o ataque, porque não sobra nada que valha a pena atacar.

O que o NPS muda em cada ataque

Com o NPS, uma conta comprometida tem privilégios limitados, o que restringe o dano que ela pode causar.

Dois recursos que ampliam ainda mais o efeito

Duas das Activities do NPS que não envolvem contas, ambas apresentadas na Parte 1, merecem ser destacadas novamente porque estendem essa mesma lógica além das credenciais:

• Ativar/desativar RDP. A maioria dos servidores deixa o RDP escutando de forma permanente. O NPS pode ativá-lo somente durante a sessão e desativá-lo logo depois. Isso remove uma superfície de ataque grande e sempre disponível, que não tem nada a ver com a credencial que o invasor possui.
• Modo de proteção. A varredura de recursos Windows e Linux em busca de contas locais não aprovadas detecta um modo de falha diferente: um insider (ou um invasor que já entrou) criando discretamente uma conta permanente para uso posterior. Ele aplica a mesma filosofia de “não deixar o privilégio não gerenciado se acumular” às contas que o NPS não criou originalmente.

O que isso não substitui

Vale ser preciso quanto ao limite, porque exagerar não ajuda ninguém. O NPS é eficaz contra ataques que dependem de uma conta privilegiada persistindo em estado utilizável, o que cobre uma parte surpreendentemente grande do catálogo de ataques a credenciais do Windows. Ele não afeta ataques que operam independentemente do status em tempo real de qualquer conta: um Golden Ticket forjado a partir de uma chave do krbtgt roubada, abuso de modelos do AD CS, uma Shadow Credential gravada em um atributo ou o roubo da chave de backup do DPAPI de todo o domínio. Esses casos exigem sua própria higiene (disciplina de rotação do krbtgt, revisão dos modelos de certificado, monitoramento de gravações em atributos, proteção da chave de backup), independentemente do rigor do modelo de sessão e Activities.

A conclusão

O PAM legado guarda uma senha em um cofre e protege um único artefato. Eliminar o privilégio permanente reduz o valor de quase tudo que vem depois dessa senha: hashes, tickets, logons em cache e atributos de contas gerenciadas. Esses artefatos só valem a pena ser roubados se o privilégio por trás deles ainda existir quando o invasor for usá-los. O NPS não vai impedir todos os ataques baseados em credenciais no Active Directory, mas fecha muito mais dessa superfície de ataque do que “proteger a senha” jamais poderia.

Próximos capítulos desta série

Tudo o que foi dito acima pressupõe que as contas funcionem totalmente com os modelos de conta do NPS. A Parte 3 aborda o Bring Your Own Vault (BYOV): como o NPS adiciona essa mesma proteção baseada em sessão sobre um cofre que você já utiliza (um cofre de PAM legado, CyberArk, BeyondTrust, HashiCorp Vault ou LAPS), para que você possa começar a reduzir essa exposição sem migrar tudo de uma vez.