Feature idea: list certificates & private keys in user and system stores

[SAERXCIT]

Hi!

I think PrivescCheck's Audit or Extended mode could list certificates and private keys in My system and user stores. This is interesting info, notably to know if they'll be extractable once admin privileges are obtained. The storage provider is the key data point to get.

I looked into it, and most certificate info can be retrieved from the .NET classes in System.Security.Cryptography.X509Certificates (available in .NET 2.0). For instance, here's how to open the system store:

PS C:\> $obj = new-object System.Security.Cryptography.X509Certificates.X509Store -ArgumentList @([System.Security.Cryptography.X509Certificates.StoreName]::My, [System.Security.Cryptography.X509Certificates.StoreLocation]::LocalMachine)
PS C:\> $obj.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadOnly -band [System.Security.Cryptography.X509Certificates.OpenFlags]::OpenExistingOnly)

From there, the $obj.Certificates property will contain all certificates in the store, along with their properties (thumbprint, issuer, subject, validity...). Importantly, I did not find a way to get the storage provider from .NET 2.

certutil -store My manages to retrieve the info when running as a non-admin user, so it should be possible to get it from this context. I procmon'd it when listing the system store, and it reads registry property HKLM\SOFTWARE\Microsoft\SystemCertificates\MY\Certificates\<CERT_THUMBPRINT>\Blob. In this blob is a UTF-16LE encoded string of the storage provider used. Instead of parsing the blob back into its structure, it should be possible to grep existing providers (list here https://www.pkisolutions.com/understanding-microsoft-crypto-providers/). That's just an idea, you may have a better one 🙂

Note: this seems to be the certificate storage provider. There's also the concept of key storage provider. This can be retrieved in HKLM\SOFTWARE\Microsoft\SystemCertificates\MY\Keys\<KEY_THUMBPRINT>\Blob (also listable and retrievable by non-privileged users). In my testing they were always the same for cert & key, but I don't know if it could differ in some edge case. There would also have to be an additional step of matching a cert to its key.

That's for the system store. I did not look into user stores.

That's the state of my research, if you choose to add it to PrivescCheck I leave implementation to you since you prefer that 😉

Cheers!

[itm4n]

Sounds like a decent idea. Thanks for the suggestion, and the very detailed description. :)

[itm4n]

In the end, I implemented the feature using the native Windows API rather than the .NET framework as it offered more granular control over the information I could collect.

I enumerate certificates stored in the registry and on the filesystem. Parsing the blobs was easy with the Windows API. Unfortunately, the enumeration is rather limited due to the fact that we can only access "shared" certificates (in HKLM). We cannot enumerate certificates of other users without administrator privileges (which is expected). Same thing goes for certificates stored on the filesystem obviously.

I also found a way to obtain the private key file path. Unfortunately, even with "shared" certificates owned by SYSTEM this can fail unless we have administrator privileges.

I'll see if I refactor this feature completely in the future.