Abuse of Active Directory Certificate Services (AD CS) has become a staple of our internal network assessment methodology. In fact, I can’t recall an internal I’ve done in the past two or more years that didn’t feature ADCS abuse in some manner or another.
We can all agree that when AD CS abuse works as intended, it is fantastic. As Tinus Green stated in his BSides talk, AD CS abuse is the teleport scroll to the top of the mountain. It allows us to rapidly gain high-privileged access to the domain and, from there, can target more lucrative objectives.
Sometimes on an engagement, you’d like to construct a believable certificate chain, that you have the matching private keys for. An example might be that a mobile app is doing cert pinning, based on attributes of the signing certificate, such as the Canonical Name (CN), serial number, or Issuer, or that you are intercepting an embedded app that only supports a particular algorithm. Whatever the reason, it’s a fairly complicated process if you are not familiar with X509 certificates. And trying to kludge it together with OpenSSL and some shell scripts under time constraints will only make you tear your hair out! While Metasploit can do some of this, it only clones a single certificate and self-signs it, rather than cloning the entire chain. If you need more than that, keep reading!
With the recent buzz around the iMessage crypto bug from the John’s Hopkins team, several people pointed out that you would need a root CA to make it work. While getting access to the private key for a global root CA is probably hard, getting a device to trust a malicious root CA is sometimes phrased as difficult to do, but really isn’t. (There’s a brief technical note about this in the caveats section at the end.)