Squiblydoo

Why, hello there, #solarmarker. virustotal.com/gui/file/1e791…

@k0ng0x64 Here: discord.gg/dvGXKaY5qr Though you have a good point, I should have posted it too.

@SquiblydooBlog How can I get an invite to the discord?

The RansomISAC published regarding "Zhengzhou 403 Network Technology Co., Ltd.", a cert we reported in 2025 after it was used to sign CobaltStrike. Their investigation seemed like a wild adventure, check it out. ransom-isac.org/blog/dragonbre… 1/3

@cyb3rops @itquartz Maybe you’ve seen this, but the bugzilla issue seems unrelated. That issue had not impacted DigiCert’s certificate. The Defender issue seems like an unfortunate mistake.

@itquartz Awesome, thanks

Anyone else seeing Microsoft #Defender flagging #DigiCert root certificate registry keys as malware? We’ve seen reports that Defender signature update from April 30 added a detection called: Trojan:Win32/Cerdigent.A!dha In some environments, Defender apparently detected DigiCert Root CA certificate registry entries and removed them from the trust store. The affected cert hashes mentioned so far: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 DDFB16CD4931C973A2037D3FC83A4D7D775D05E4 Example path: HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 There’s also a Reddit comment suggesting Microsoft has started restoring the certs and that admins can check this via Advanced Hunting in Defender: DeviceRegistryEvents | where RegistryKey contains "0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43" or RegistryKey contains "DDFB16CD4931C973A2037D3FC83A4D7D775D05E4" | where ActionType == "RegistryKeyCreated" | where Timestamp > datetime(2026-05-03T04:00:00) | project Timestamp, DeviceName, ActionType, InitiatingProcessFileName | order by Timestamp desc On an affected device, this can also be checked with: certutil -store AuthRoot | findstr -i "digicert" Could become an annoying day for admins if this spreads reddit.com/r/cybersecurit…

Relatedly, I added functionality to PKILab to extract and highlight the Authenticode Publisher for Windows Hardware drivers. I had hardly noticed these details before, so I'm glad PKILab can make it easy to find. 3/3

We see so many abused certificates, that we can't dig deep. If ya'll ever want to get in on the front lines of it, be sure to join the Debloat Discord where we monitor and chat about abused certificates. 2/3

Update to pkilab.certgraveyard.org - I originally hadn't planned for the analysis reports to be sharable, but it turned out people liked sharing them. They are now permanent. - Added P7X support, which was omitted by accident

@Meitzi_ That may be due to the hardware token for EV certs. Rather than sending the user an private key on the hardware token and risk it falling in the wrong hands; the user activates it using their account once they receive the key.

@SquiblydooBlog No. I'm talking with normal certificate, only server have private key. And all communication between are "public". So if anyone get all data from support, there is no private key. So why, in this case (EV certs) we do these things wrong. Im not sure.

We didn't know how an actor was using EV Certificates issued to Lenovo and others. We now do. From DigiCert's incident report: "the threat actor used a compromised analyst endpoint to access DigiCert's internal support portal. The threat actor used a limited function within the customer-support portal which allows authenticated DigiCert support analysts to access customer accounts from the customer's perspective to facilitate support tasks. The threat actor was able to use this function to access initialization codes for orders that were approved but pending delivery for EV Code Signing certificate orders across a finite set of customer accounts." "Possession of the initialization code, combined with an approved order, is functionally sufficient to generate and retrieve the corresponding certificate." The full report can be found here and explains the incident in great detail: bugzilla.mozilla.org/show_bug.cgi?i… The report mentions "Where we got lucky: A community member involved in security research reported the evolving pattern of misused certificates and engaged in dialogue with our support team. Without that report, the undetected compromise of ENDPOINT2 and the associated mis-issuance might have remained undiscovered for a longer period." Special thanks goes to the regular contributors to the Cert Graveyard; @g0njxa , @malwrhunterteam , and others. Also special thanks to DigiCert: this report has a high level of transparency, which is warranted, and also well executed.

@malwaremarcus Ultimate goal is ransomware deployment, primarily against businesses. The malware is primarily a loader that will download a second stage with more remote access capability.

@SquiblydooBlog Thank you! By chance do you know the ultimate goal of the malware? Ex: was it just doing recon on the infected system?

Fake Microsoft Teams, "MTSetup_v15.3.7191.msi" signed by "Tryphena Lewis" 18c5b7a39be2f4a4b2fd45f0f273874f5efcc8751d4e592e5f2bcf6dbf781277 FUD-lite Uploaded to MalwareBazaar here https://bazaar.abuse[.]ch/sample/18c5b7a39be2f4a4b2fd45f0f273874f5efcc8751d4e592e5f2bcf6dbf781277

@Meitzi_ In this case, only the client should receive the code to activate their signing certificate. But in this situation, the code was visible to support, so some with access could use the codes. They've now change that to make it only available to the end user.

@SquiblydooBlog How we end up like this? Like is it supposed to be that only client have private keys? Now with EV (which supposed to be more secured?) its full pack. Certificate + private keys.

It is a malware I'm tracking as "LoremIpsumLoader", I've needed to write more but haven't. It seems the actor "Vanilla Tempest" (think Rhysida ransomware) moved from using OysterLoader to this new malware. It loads shellcode containing LoremIpsum text which is used to decode a deaddrop on the site letsdiskuss[.]com to get the C2 addresses it needs.

@SquiblydooBlog any chance you have a write up on this one? interesting

@bettersafetynet Article from GitHub regarding how they are working to handle growth issues. github.blog/news-insights/…

Is github OK? This is the second day in a row I'm having difficulty signing in. If I can't sign in, my code can't get pushed. I really don't want have to fuss with running a local gitlab instance. boo.

@rekdt Kiddie: Claude, run the payload Claude: Script executed perfectly <Thinking: The host is a windows machine, but if I tell them, they'll shout at me again.>

Somewhere there’s a brilliant opportunist about to 100% HacktheBox via copy dot fail over the next 24 hours

@Slav636 For sure: they've already been discussing for a while how to be ready for "quantum threats".

It was inevitable, but EV validation process was comprehensively compromised in this case. I wonder if the commercial CA industry will now come up with XEV, or PQV (post-quantum validation), to keep charging gullible customers premium prices.

@huntnp007 Yeah 🥲 We are also all just doing it for the love of the game. Thankfully, DigiCert did implement some significant improvements. However, we're left hoping the other Cert Authorities (who are most likely being targeted too) respond appropriately and tighten their own processes.

@SquiblydooBlog 'We got lucky' isn't a detection strategy. Community caught what DigiCert's controls missed. Props to the researchers for the save.

@wessorh That YARA rule is not going to be good enough, since having a signature isn't indicative of a valid signature. I'll send you an email after a bit.

rick@support-intelligence.com daily I have hundreds that this yara sig identifies, if you would like me to use a different sig, just provide it via email import "pe" rule Signed_PE_Verified { meta: description = "Detects PE files with verified Authenticode signature(s)" condition: pe.is_pe and pe.number_of_signatures > 0 }

CertGraveyard's PKI Lab is available now. Want to better understand code-signing certificates? The site allows you to extract and view certificates. The Cert Inspection tool parses out all of the bits and flags anomalies. 1/2

@userlolxxl This has been an unfortunate consequence of the Cert Graveyard needing to change it's name. Our new domain has been flagged by a few places and I haven't been able to get it resolved everywhere.

@SquiblydooBlog 'The Cert Graveyard's PKILab — Certificate Inspector' pkilab(.)certgraveyard(.)org is false positive....🤔

@wessorh Thanks for the example. Currently, it takes the certificates out of the overlay, and checks the certificates itself, but it doesn't check if the certificate is valid for the file. This is because the PKILab doesn't ingest the whole file, so it can't check the computed hash.

@SquiblydooBlog I uploaded 6860f373d46beb41e33b3074f4d214cd which is detected as malware on VT which says it is not signed, but you say it is signed but expired virustotal.com/gui/file-analy… and pkilab.certgraveyard.org/inspect/result…

@wessorh The Cert Graveyard is a better space for submitting samples, rather than the PKILab. I'm happy to talk more regarding that, and I am interested. What is a good medium to do so?

@SquiblydooBlog how many samples per day can you handle, I can set up a feed of validated malware that is signed if you are interested

@laser_cool_gal Context regarding the picture: There is an actor deploying Vidar Stealer who takes TLS certificates and slaps them on EXEs. They add "Code-Signing" to the EKU. They somehow manage to "validly sign" them using the TLS certificate. I don't know how, but that is the repurposing.

@SquiblydooBlog tls certificates are not repurposed its a certificate revocation