O dilema do intruso é o outro lado do dilema do defensor, que explica os desafios da defesa da segurança cibernética. Enquanto a defesa do Active Diretory (AD) contra todas as técnicas de ataque possíveis é o desafio para os defensores, os atacantes têm um problema diferente: depois de entrarem, têm de evitar ser apanhados.
Os atacantes podem precisar de encontrar apenas um ponto fraco para obter acesso, mas permanecer sem ser detectado é muito mais difícil. Têm de manter o acesso, mover-se lateralmente, aumentar os privilégios e executar os seus objectivos sem disparar alarmes ou ficar bloqueados.
E se pudéssemos transformar o dilema do intruso numa vantagem para nós?
Como transformar um ataque numa defesa AD prática
Compreender as formas como os maus actores procuram e utilizam as vulnerabilidades é fundamental para a defesa do AD. Para ilustrar o valor deste conhecimento, vamos destacar um método de ataque de identidade comum que aproveita as configurações incorrectas de certificados.
Os ataques contra os Serviços de Certificados do Active Diretory (AD CS) ganharam uma atenção significativa depois de a SpecterOps ter publicado uma investigação sobre a forma como as configurações incorrectas no AD CS podem ser exploradas para o aumento e persistência de privilégios. O seu relatório Certified Pre-Owned1 descreveu várias técnicas, incluindo ESC1, ESC4 e Golden Certificates, que permitem aos atacantes abusar da autenticação baseada em certificados para comprometer contas privilegiadas. Desde que esta investigação foi publicada, os agentes de ameaças e as equipas vermelhas têm cada vez mais utilizado estas técnicas como armas,2 tornando o AD CS um alvo de elevado valor.
É aqui que os defensores podem virar a mesa. Quando se configura um honeypot - como um modelo de certificado de chamariz que parece vulnerável - os atacantes são forçados a fazer uma escolha. Podem tentar explorar o que parece ser uma configuração incorrecta, arriscando a exposição no processo, ou ignorá-lo e procurar outra forma de aumentar os privilégios.
Imagine que um atacante que esteja a procurar modelos de certificados mal configurados encontra um em que tem direitos de modificação. Ele pode tentar ativar o Supply in Request o que lhes permitiria especificar uma identidade privilegiada num pedido de certificado.
A armadilha está montada.
DISCLAIMER: A implementação de um modelo de CA de engodo e a sua vulnerabilidade intencional a ataques como o ESC1 e o ESC4 expande a superfície de ataque. No entanto, com os mecanismos de segurança corretos para detetar e corrigir estas ameaças, pode ser uma abordagem eficaz.
Criar uma armadilha honeypot com um modelo de certificado de chamariz: Exemplo 1
A Figura 1 mostra o que um atacante encontra quando utiliza uma ferramenta como o Certify3 para procurar modelos de certificados exploráveis.
Este certificado, CiscoSSLVPNsuporta a Autenticação de Cliente e permite que os Computadores de Domínio se inscrevam. Mas como msPKI-Certificate-Name-Flag não está definido para ENROLLEE_SUPPLIES_OBJECTo ataque ESC1 não funciona.
Quando o atacante olha para os atributos AD do CiscoSSLVPN certificado (Figura 2), verificam que o msPKI-Certificate-Name-Flag é definido como 134217728, o que corresponde a SUBJECT_ALT_REQUIRE_DNS. Isto significa que o Supply in Request não está activada.
CiscoSSLVPN atributos de modelo de certificado, com msPKI-Certificate-Name-Flag definido como 134217728, indicando SUBJECT_ALT_REQUIRE_DNS.Uma vez que, neste exemplo, concedemos aos computadores de domínio controlo total sobre este modelo de CA, o nosso atacante poderia tirar partido de msDs-MachineAccountQuota (Figura 3), que é definido como 10 por predefinição, para criar um novo objeto de computador, autenticar como a conta de computador e, em seguida, modificar o Modelo CA.
TestPC), tirando partido de msDs-MachineAccountQuotaque é definido como 10 por defeito no AD.A seguir, o atacante autentica-se como a conta do computador e modifica o modelo da CA para o tornar vulnerável ao ESC1(Figura 4).
TestPC$ modificando a conta da máquina msPKI-Certificate-Name-Flag no CiscoSSLVPN modelo de certificado para o tornar vulnerável ao ESC1.Agora, o nosso atacante verifica os atributos AD do modelo CA modificado. Ele vê que o msPKI-Certificate-Name-Flag o valor foi alterado (Figura 5), que reflecte a modificação que o torna explorável.
CiscoSSLVPN modelo de certificado, onde o msPKI-Certificate-Name-Flag foi alterado, tornando-o vulnerável ao ESC1.No lado da defesa do AD: Em Directory Services Protector DSP)pode agora ver uma entrada que regista a alteração do AD no modelo de CA de engodo(Figura 6), destacando o atributo específico que foi modificado.
CiscoSSLVPN modelo de certificado, onde o msPKI-Certificate-Name-Flag foi alterado, permitindo uma investigação mais aprofundada sobre a conta responsável pela ação.DSP também mostra quem modificou o modelo da AC(Figura 7), permitindo-lhe investigar a conta responsável pela alteração e detetar qualquer outra atividade suspeita.
CiscoSSLVPN modelo de certificado foi modificado pelo TestPC$ conta de computador.Criar uma armadilha honeypot com um modelo de certificado de chamariz: Exemplo 2
O WebServer é normalmente utilizado para emitir certificados SSL/TLS para o Windows Server Update Services (WSUS), o Active Diretory Federation Services (ADFS), os servidores Web do Internet Information Services (IIS) e os equilibradores de carga. Garante a comunicação encriptada através de HTTP. Por predefinição, está configurado com Supply in Requestmas como a utilização alargada da chave (EKU) está definida para Server Authentication, ESC1 não pode ser explorado (Figura 8).
WebServer modelo de certificado, mostrando que Supply in Request (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) está ativado, mas a EKU está definida para Server Authentication.Para montar a nossa armadilha, pode começar por duplicar o WebServer e dando-lhe um nome realista para que pareça legítimo. Em seguida, modifique a DACL para que pareça uma configuração legítima, permitindo uma conta de computador falsa, como WSUS-2016, para se inscrever.
Ao mesmo tempo, o modelo é intencionalmente mal configurado, concedendo permissões de escrita a utilizadores autenticados(Figura 9), o que cria uma oportunidade de exploração.
WSUS-2016$) tem permissões de registo e os utilizadores autenticados foram incorretamente configurados com permissões de escrita, tornando o modelo vulnerável à exploração.Figura 10 mostra o aspeto do reconhecimento para um atacante que identifica modelos de AC exploráveis, em que os utilizadores autenticados têm permissões de escrita no engodo WSUSSSLCert modelo.
WSUSSSLCert modelo de certificado, em que os utilizadores autenticados têm WriteProperty permitindo-lhes modificar atributos como EKU.Agora, o nosso atacante examina os valores actuais do atributo AD deste modelo de AC, concentrando-se especificamente no atributo msPKI-Certificate-Application-Policy que define a utilização permitida do certificado (Figura 11).
WSUSSSLCert modelo de certificado, destacando o msPKI-Certificate-Application-Policy valor. O identificador de objeto 1.3.6.1.5.5.7.3.1 corresponde à Autenticação do servidor.Agora, modificam este modelo de AC para o tornar explorável em ESC1 e, em seguida, verificam como o msPKI-Certificate-Application-Policy alterações de valor (Figura 12).
WSUSSSLCert modelo de certificado, onde o msPKI-Certificate-Application-Policy foi alterado para 1.3.6.1.5.5.7.3.2activando a autenticação do cliente. Esta alteração torna o modelo vulnerável ao ESC1.Como Figura 13 espectáculos, o msPKI-Certificate-Application-Policy foi atualizado para um identificador de objeto diferente, que corresponde agora à autenticação do cliente.
WSUSSSLCert modelo de certificado, onde o msPKI-Certificate-Application-Policy foi alterado para 1.3.6.1.5.5.7.3.2e ativar a autenticação do cliente. Agora, o modelo não só é vulnerável como também pode ser explorado pelo ESC1.O passo final que o nosso atacante dá é conceder permissões de registo no modelo da CA, permitindo-lhe explorá-lo(Figura 14).
WSUSSSLCert modelo utilizando o PowerView.No lado da defesa do AD: No DSP, existe agora uma entrada no registo de alterações do AD que indica que alguém modificou este atributo específico do AD no modelo da AC(Figura 15).
WSUSSSLCert modelo de certificado, onde o msPKI-Certificate-Application-Policy foi alterado de Autenticação de servidor para Autenticação de cliente.Será registada outra entrada no DSP indicando que o atributo Security Descriptor (Descritor de segurança) foi modificado no modelo de CA de engodo(Figura 16).
WSUSSSLCert Modelo CA.A chave para os chamarizes na defesa do AD: Criar uma regra de notificação no DSP
No DSP, é possível criar uma regra de notificação para modelos de certificados de engodo(Figura 17), de modo a que quaisquer alterações efectuadas aos mesmos accionem um alerta.
WSUSSSLCert modelo de certificado, está configurado para acionar um alerta sempre que é feita uma modificação no msPKI-Certificate-Application-Policy atributo.Quando alguém modifica este atributo do AD no modelo de CA de engodo, DSP envia uma notificação por correio eletrónico que inclui detalhes sobre quem fez a alteração, em que Controlador de Domínio ocorreu e outras informações relevantes(Figura 18).
Instantâneo da Semperis
Para as organizações que executam o ADCS, a configuração de armadilhas de honeypot pode ser uma forma valiosa de detetar atacantes antes que eles possam aumentar os privilégios. As configurações incorrectas do ADCS são cada vez mais exploradas em ataques reais, conforme salientado no relatório da Mandiant4 sobre as tácticas de pós-exploração da Ivanti. Ao implementar modelos de certificados de engodo que parecem vulneráveis, mas que são monitorizados de perto, os defensores do AD podem levar os atacantes a revelarem-se no momento em que tentam a exploração.
Saiba mais sobre a defesa proactiva do Active Diretory
- Os dez principais erros de segurança cibernética da NSA: Uma perspetiva do Active Directory
- Ciber-resiliência 101: Principais dicas para a defesa de AD
- O que é a segurança do Active Directory?
- Práticas recomendadas de proteção do Active Directory
Referências
