Potential FP on Windows certificate store addition

[antonio-fr]

Rule UUID

d223b46b-5621-4037-88fe-fda32eead684

Example EventLog

--

Description

It detects the addition of new root, CA or AuthRoot certificates to the Windows registry in a software that is never supposed to do that.
https://github.com/antonio-fr/uniblow/releases/tag/v2.7.7
Binary : https://uniblow.org/dist/Uniblow-win-amd64-2.7.7.exe
Source: https://github.com/antonio-fr/uniblow/tree/v2.7.7

[github-actions]

Welcome @antonio-fr 👋

It looks like this is your first issue on the Sigma rules repository!

The following repository accepts issues related to false positives or rule ideas.

If you're reporting an issue related to the pySigma library please consider submitting it here

Thanks for taking the time to open this issue, and welcome to the Sigma community! 😃

If you want to engage more with the community for official support, general discussions or announcements:

👉 Join our Discord server

[swachchhanda000]

Hi @antonio-fr,

Can you please share the full raw log? How do you know that it is caused by this particular software??

[munzzyy]

I went at this from the Uniblow side to find what would write to ...\SystemCertificates\...\Certificates\...\Blob, and I couldn't find a path that does.

Reading Uniblow's source at the referenced v2.7.7: the only certificate code is CertificateValidator.py, and it does in-memory X.509 chain validation with the cryptography library against two PEMs bundled in the package. It's there to validate the smartcard manufacturer's certificate, not to install anything into the Windows cert store. It never calls the Windows CryptoAPI (CertOpenStore / CertAddCertificateContextToStore) and never touches the registry. The only winreg use in the tree is a read of HKCU shell-folder paths, unrelated to certs. The Windows build is a single-file PyInstaller exe with no installer step, so there's no MSI or cert-provisioning phase either.

So the rule doesn't look like it's matching Uniblow's own behavior. My guess is the registry write was coincidental: something else on the machine touched the cert store around the same time and got attributed to the foreground process (Windows AuthRoot / CTL auto-update is a common culprit).

If the raw Sysmon event 13 is still around (the Image, the full TargetObject, and the timestamp), that would settle it. Without a write path in the source, though, I don't think a uniblow.exe filter is warranted here.