PKI Threat Detection and Recon: Code Signing – “The Signed Back Door” Webinar

Below are the key highlights, Q&A from our PKI Solutions “Office Hours”: The PKI Threat Detection and Recon: Code Signing Episode

While our focus was on default check boxes and PKI misconfigurations, which can give adversaries access to a code signing certificate or they can just create their own, we touched on may topics.

Presenter Shawn Rabourn demonstrated how easy it is for bad guys to set up a back door that evades detection. Topics covered included:

1. Threat modeling basics: your business, Public Key Infrastructure, and adversarial POV
2. Kinds of misconfigurations that can lead to signed backed doors and malicious code signing
3. How antivirus software will just trust malware and treat it as legit – like putting Fluffy to sleep
4. PKI Best Practices and hardening measures you can take
5. How PKI Spotlight can monitor code signing certs and associated events to get notified of threats in real time

It was demonstrated to attendees that think they have100% of their threat detection, recon and code signing issues handled by the right staff with the right skillset, there are OFTEN issues that slip through the cracks.

If you are facing challenges with your PKI and have issues with code signing, threat detection, recon, remote access, availability, scale, and management, we are here to help.

Attendees had an opportunity to ask us anything within the webinar’s chat function, and Questions & Answers are listed here:

Below is the entire downloadable presentation: PKI Threat Detection and Recon: Code Signing!

Entire video is added to the bottom of this post.

The video playlist of some of the questions and highlights from the webinar to go with the slides (for context), can be found here:

PKI Threat Detection and Recon: Code Signing Office Hours Snippet Q&A Transcript

Q: What happens if code is signed and you find out the code is compromised …if the code sign cert is timestamped but then revoked is the software signed still trusted?

A: It depends on if the mechanism verifying the code is checking revocation. If it is… there is a scenario where the certificate expires and because the certificate is expired it may disappear from the CRL, but the Timestamp signature will render the certificate valid. ADCS has a registry setting called EKUOIDsForPublishExpiredCertInCRL to set to ensure expired Code Signing certificates are included in the CRL

Q: If a code signed certificate is expired / out of date, but application is still needed (e.g. legacy) is there a way to validate if the certificate can still be trusted?

A:This is the reason you reach out to a Timestamping authority to provide a countersignature. The assumption is always that the software is going to exceed the lifetime of the certificate and a key risk mitigation is a short lifetime on the code signing certificate.

Q: Is that why you shouldn’t use the same code signing cert for all code?

A: It depends on the enterprise. You may need to have separate certificates for different software suites or even for Production/Development/Test. The more granularity you have the more control you end up with at the expense of introducing additional potential for misuse.

Q: What is Best Practices in regards to Security permissions on ADCS PKI cert templates in relation to the 2 highly privileged groups Domain Admins & Enterprise Admins.; Ex.. by default they get Read, Write, Enroll.; I’m presuming Enroll should be removed, if accounts in those groups don’t need to enroll?

A: Absolutely. I like the ESAE/Red Forest tier model and you can actually down-tier a CA to Tier 1 if you pull all of those EA/DA permissions away post-delegation.

Q: What would be your recommendations for detecting code-signing abuse? Espcially anything endpoint-related?

A: Scan for PFX, P12, and PEM files. Check for group policies adjusting Trusted Publishers or associated registry keys.

Q: Wouldn’t signed code with timestamping be valid if prior to the effective date of when the cert was revoked? Assuming true, couldn’t you backdate the effective revoke to a little before the timestamp of the discovered bad code?

A: Changing the clock for any reason is bad. But I would have to test this out. I would presume the presence of a legitimate revocation would supersede everything else.

Q: What is your opinion about create a Internal PKI for signing code used inside of a company. Do you agreed which this model is good or you will suggest the Public PKI integrated Mode? I don’t see companies using the Internal PKIs to Sign Scripts codes for example. I only see companies singing code for apps what are used for externals customers.

A: There definitely are use cases for an internal PKI, however the most likely use case and the one I am most concerned about is the use of an external certificate. There are 800 developers for every IT security person. If you can meet the requirements for an EV certificate from a public CA, life is much smoother for the end-user.

Q: Hi Shawn. In the example you used a DigiCert timestamp service. Is there any reason why you wouldn’t use this in a production environment?

A: Nope. Digicert signs their Timestamps with a trusted issuer.

Q: Will spotlight report on configuration issues such as what is and should not be configured under security for templates?

A: The Q1 release of Spotlight includes several enhancements for Certificate Templates and the modification of security for templates will fire an alert as well as common misconfigurations. Current release of Spotlight alerts on the creation and enablement of templates.

Q: …Worse you can use the SAN UPN to gain Domain Admin rights via PKINIT as one example (or LDAPS)

A: This is one of the best vectors to attack if you are a pentester because it is a fairly common misconfiguration to identify.

Q: In the newly trending DevSecOps, what could be best? A different Code-Signing for each pod? What would be the best practice?

A: It depends on the situation. There are several considerations. First and foremost is the protection of the keys. There’s nothing that says you can’t use the same key for everything, however the risk increases especially if the keys are somehow exposed, the more code you sign with one key, the more code you have to re-key if the key is exposed. If you are in control of the keys and you are using k of n on an HSM, it might not be realistic to perform a ceremony for every single release. A good practice is to use test-specific certificates with lower lifetimes, especially if revocation is retained after expiry.

Q: What is the platform key that should be on a Microsoft Surface Pro 9? There are conflicting PKI documents floating around on the web that have different page counts and keys, but the same unique docusign envelope ID?

A: Misrepresented attestation documentation is certainly a bad look, especially considering the recent news around WQHL certificates being used for Malware, though I would be leery of reading too much into it as there are several legitimate reasons for not posting an intact attestation document publicly, especially if it contains esoteric information.

Q: Does it install the full trust chain for that certificate?

A: When you are using Powershell and you sign the code, you have the choice of including the entire chain or just the end-entity. If you attempt to install a certificate into trusted publishers, a root verification occurs in advance of the attempt.

The entire PKI Threat Detection and Recon: Code Signing Office Hours video can be seen here: