Certiception

Certiception is a honeypot for Active Directory Certificate Services (ADCS), designed to trap attackers with a realistic and attractive bait that triggers highly relevant alerts.

Developed by the SRLabs Red Team, Certiception creates a vulnerable-looking certificate template in your ADCS environment, sets up restrictions to prevent exploitation, and supports in setting up effective alerting.

Originally released at Troopers24, Certiception comes with a strategic guide to effective deception: The Red Teamers' guide to deception

tl;dr: From an attacker's perspective: Looks vulnerable, Exploitation fails.

Background

In our Red Team and Incident Management engagements we regularly observe that lateral movement and privilege escalation go undetected. If detections trigger at all, they are not reacted to in a timely manner, because false positives are commonplace. We believe internal honeypots (aka. canaries, aka. deception tech) are an effective way for defenders to catch threats that make it through initial defenses.

Internal honeypots are intentional traps for attackers placed in your network. They look vulnerable but trigger an alert on exploitation. Here's why we think deception has great potential:

• Low effort and cost: Setup can rely on existing tools such as a SIEM.
• High relevance alerts: A triggered honeypot hints at a significant threat, so the alerts are worth investigating.
• Low noise: Designed to trigger only on malicious activity, internal honeypots have a low false positive rate.

Despite their potential, we regularly encounter fundamentally ineffective deception setups. To help defenders create more effective honeypots, Certiception comes with an extensive deception strategy guide.

Active Directory Certificate Services (ADCS) is an ideal location for a honeypot:

1. Easy Access: Accessible by all domain users, ADCS is easy for attackers to discover.
2. High Stakes: Vulnerabilities can lead to full domain compromise, making exploitation highly attractive.
3. Common Knowledge: Vulnerabilities and exploitation tools are widely known.
4. Authenticity: Vulnerable ADCS templates are commonplace, raising little contempt.
5. Under-Monitored: Many networks barely monitor ADCS, encouraging even cautious attackers to dare exploitation.

This is why we built Certiception.

Concept

Certiception sets up a new CA in your environment and configures an ESC1 honeypot.

It is implemented as an Ansible playbook calling multiple roles. Overall, the following steps are executed:

• Set up a new CA, add a “vulnerable” ESC1 template and enable it only on the new CA
• Install and configure the TameMyCerts policy module to prevent issuance if certificate signing requests contain a SAN
• Enable extended audit log to include template names in event logs
• Print a SIGMA rule to set up alerting in your SIEM
• Set up continuous checks with Certify to catch any other CA enabling the vulnerable template (not pushed yet, will be added to the repo in the next days)

Parameters like the CA or template name can be customized to disguise the honeypot.

So this is how Certiception works::

Support for other types of ESC vulnerabilities and the capability to add honey templates to existing CAs are planned for the future.

Alerting

Certiception uses built-in Windows events from the CA and events generated by the TameMyCerts policy module. To get the built-in CA events with the required information, Certiception enables the extended audit log on the honey CA server.

We suggest alerting on critical and medium events:

Certiception outputs ready-to-use SIGMA rules for the two different alerts. You only need to ensure the respective event IDs are onboarded into your SIEM and then setup alerting with the SIGMA rules.

Future releases might introduce new or additional SIGMA rules.

Usage

Follow these steps to set up your ADCS honeypot.

Prerequisites

• Domain-joined Windows server to install the CA
• Machine with Ansible and WinRM connectivity to server to clone this repository and execute Certiception
• Local admin privileges on server to install the CA and exploitation protections
• Enterprise Admin account to register the new CA
• Basic Domain account without any privileges to execute continuous Certify checks

Installing Certiception

Note: we are still improving the stability in different test lab setups with regards to what accounts are used for the setup tasks. If you want try it out, probably best to wait a week more :)

1. Configure your general Domain and Ansible connection parameters in inventory
2. Customize parameters for your honeypot in host_vars/honeypotCA.yml
3. Create EDR exception for future Certify location (used for monitoring if any non-honey CAs enable the vulnerable template, not required yet as Certify-based monitoring it not yet published)
4. Run Certiception Ansible playbook

ansible-playbook -i inventory playbooks/certiception.yml

4. Onboard the server's event logs to your SIEM and configure alerts with the printed SIGMA rules
5. Verify and manually test your setup

Safety and security considerations

This tooling is provided without any warranty or guarantees. It combines existing software, automating installation and configuration. You are responsible for all installation and configuration steps performed by Certiception.

If you use this tool, we strongly recommend you read the source code to understand what you configure and verify your setup after installation.

Additionally, we recommend considering the following:

1. At the time of release the tool was not scrutinized by the community yet - expect safety and hardening improvements over time. We do not recommend to run it unmodified in your production environment.
2. An ADCS honeypot only makes sense if the PKI team takes up the ownership for it. When performing configuration changes, the implications on the honeypot need to be considered. E.g. when migrating the honey CA to a new server without also migrating the policy module, the honey template becomes exploitable.
3. Besides the honey template, your honey CA should be secured, hardened and managed like any other ADCS CA in your network
4. The CA set up by this tool is a plain CA with the CA certificate stored on disk and no HSM
5. Certiception sets up basic checking for real vulnerable templates utilizing Certify on the CA server. For production environments we recommend running these continuous checks on a separate machine. Checks should not only be based on "find" commands for template identification but also attempt exploitation of the honey template (SIEM allow-listed) to catch configuration changes that make it exploitable on the honey CA.

Future work

• Support placing honey templates on existing CAs
• Implement support for more ESC misconfigurations (e.g. ESC3 and ESC8)
• Implement additional safeguards and hardening options to prevent things going wrong
• Use lower privilege accounts instead of enterprise admin
• Add less suspicious error message on denied CSRs
• Investigate and mitigate ways of fingerprinting Certiception
• Strengthen continuous monitoring intended to catch and mitigate insecure configurations
• Hardening of the installation script (e.g. investigate credential exposure of the used accounts)

License

• SRLabs' Certiception is released under the Apache-2.0 License
• Ashley McGlone's ADCSTemplate is available under the terms of the MIT License
• Uwe Gradenegger's TameMyCerts falls under the Apache-2.0 License

Acknowledgements

• Uwe Gradenegger for his great PKI and ADCS blog and as the developer of the TameMyCerts policy module
• Ashley McGlone for the ADCSTemplate scripts we use to create the honey template
• @harmj0y and @tifkin_ for their ADCS research and corresponding Certify tool
• @ly4k_ who found ESC9 and ESC10 (and develops Certipy)
• @sploutchy for ESC11
• Hans-Joachim Knobloch for ESC12
• @Jonas_B_K and @_wald0 auditing ADCS with Bloodhound and ESC13
• @PyroTek3 for his previous work on Active Directory honeypots
• @gentilkiwi for inspiration like this one