Microsoft seized websites and took down hundreds of virtual machines running a cybercrime service that allegedly sold code-signing certificates to ransomware gangs, thus making their malware look like legitimate software – and allowing criminals to infect thousands of machines in the US, including at least 12 owned and operated by the Windows giant. The malware signing-as-a-service operation called Fox Tempest has been around since May 2025, and abuses Microsoft’s Artifact Signing code-signing service. This service allows developers to digitally sign their software applications, signaling to the Windows operating system and end-user that the software is authentic, and hasn’t been tampered with. Since May 2025, the Fox Tempest crew – referred to as John Doe 1 and 2 in court documents unsealed on Tuesday – used fake identities and impersonated real organizations, allowing them to create more than 580 fraudulent Microsoft accounts. They then used these accounts to abuse Microsoft’s Artifact Signing service and obtain real code-signing credentials, then sold the code-signing certificates to other criminals for thousands of dollars. According to Microsoft, Fox Tempest’s customers included a ransomware group Redmond tracks as Vanilla Tempest (aka Vice Spider, Vice Society, Rhysida), which allegedly used the certificates to digitally sign malware and make it appear legitimate to Windows and users. This also allowed the ransomware slingers “to more easily deploy the malware onto the computers of unsuspecting victims without their consent,” according to the court documents [PDF]. Malware included Windows backdoor Oyster, infostealers Lumma and Vidar, and Rhysida ransomware. Vanilla Tempest “unlawfully accessed victims’ computers and devices, exfiltrated and stole the personal and confidential information of victims, deployed ransomware designed to encrypt victims’ files and systems, and extorted victims by demanding payment in exchange for restoring access to, or suppressing, their data,” the civil complaint continues, adding that the criminal activity remains ongoing. In a subsequent blog post, Microsoft Digital Crimes Unit attorney Steven Masada said the tech company's investigation “further linked Fox Tempest to various additional ransomware affiliates and families, including INC, Qilin, Akira, and others.” Between February and March, the Digital Crimes Unit (DCU), working with “a cooperating source,” anonymously bought and tested the code signing service from John Doe 2, aka SamCodeSign. “These test purchases allowed DCU investigators to observe first-hand how Fox Tempest Defendants operate the service, the information a purchaser is provided, and the instructions given by SamCodeSign to connect to the service and sign the test software created by Microsoft,” the court documents say. “Additionally, the test purchases allowed DCU to identify cryptocurrency wallets used by Fox Tempest Defendants.” During the first test purchase, the source filled out a Google Form asking them to select how quickly they needed the certificates. Standard costs $5,000, while priority runs $7,500 and expedited carries a hefty $9,500 price tag. SamCodeSign then sent a direct message to the source and requested the $7,500 payment to be sent to a bitcoin wallet, according to screenshots (translated from Russian) in the court documents. After the source paid up, SamCodeSign sent instructions on how to access the virtual machine and complete the code signing process. “Microsoft has identified thousands of customer machines, including more than a dozen machines owned and operated by Microsoft, in the United States that have been impacted by malware signed with certificates originating from the tenants created by Fox Tempest Defendants,” the complaint says. ®

The US Cybersecurity and Infrastructure Security Agency (CISA) left open a GitHub repository named “Private-CISA” containing plain-text passwords, private keys, tokens, and secrets – with obvious file names like “external-secret-repo-creds.yaml” and “AWS-Workspace-Firefox-Passwords.csv” – for six months. GitGuardian researcher Guillaume Valadon, fresh off a recent talk on Kubernetes secret leaks, found the public repository on May 14, and told The Register that he “quickly understood that the leak was bad and that time was running out. A national agency having 844 MB of production infrastructure material in a public GitHub repository for six months is as serious as a secrets leak gets.” Valadon, who previously spent nine years at France’s CISA equivalent, ANSSI, told us the leak included tokens for CISA's internal JFrog Artifactory, Azure registry keys, AWS credentials, Kubernetes manifests, ArgoCD application files, Terraform infrastructure code, GitHub personal access tokens, and Entra ID SAML certificates. GitGuardian reported the leaky repository to CISA on May 14, and the agency took it down a day later. A CISA spokesperson told The Register that it was aware of the report and is investigating. "Currently, there is no indication that any sensitive data was compromised as a result of this incident.” It’s not a good look for the nation’s infosec agency, which hasn’t had a permanent boss since Trump took office, is facing hundreds of millions of dollars in budgets cuts on top of deep cuts to staff and funding last year, and has suffered its share of embarrassing security snafus in the interim. In a Tuesday blog, Valadon said he initially thought the repo “was a hoax, given how suspicious the directory names (Backup-April-2026/, All Backups/, LZ-Artifactory/, Kubernetes-Important-Yaml-Files/, ENTRA ID - SAML Certificates/ ...), file names (external-secret-repo-creds.yaml, CAWS GitHub Token.txt, Important AWS Tokens.txt, AWS-Workspace-Firefox-Passwords.csv, Kube-Config.txt ...), and their contents (private keys, personal and professional GitHub tokens, AWS secrets, ...) seemed too good to be true,” Valadon wrote. It wasn’t a hoax – “The Cybersecurity and Infrastructure Security Agency is aware of the reported exposure and is continuing to investigate the situation,” but it was a “catalogue of unsafe practices,” he added, containing passwords stored in plain text, backups committed to Git, and an “explicit” how-to guide for disabling GitHub's secret scanning. After initially reporting the leak through the CERT/CC portal, and only receiving an auto-acknowledgement as of the morning of May 15 – a Friday – Valadon alerted security journalist Brian Krebs about the publicly exposed secrets, which seemed to speed up CISA’s processes. By 6 pm EST that night, the feds took down the repository. Valadon told The Reg he gives CISA credit for quickly deleting the repository. “Most of our responsible disclosures take much longer, and many are never fixed,” he said. “Managing to take the repository offline in a day is impressive work.” He doesn’t know if any other parties with less altruistic intentions found the secrets first, although the fact that the repository was never forked (based on public GitHub events) would seem to indicate that it wasn’t widely circulated on the dark web. “The only ones that can answer definitively is GitHub,” Valadon said. GitHub did not immediately respond to The Register’s inquiry. GitGuardian isn’t aware of any of the exposed credentials being abused by unauthorized individuals “Each category of secret in the repository unlocks a specific attack path,” Valadon said. “Stacked together, they cover the full range: from destructive attacks and ransomware extortion to quiet, long-term persistence inside CISA's build and deployment pipeline. That last scenario worried me the most, and it's why I escalated through every channel we had until the repository was taken offline.” Plus, the committer used both a CISA-issued contractor email and a personal Yahoo email across the same commits, and created the repository using a personal GitHub account. “That mixed-identity pattern is one of the hardest surfaces for security teams to cover, and it's where the worst leaks happen,” Valadon said.®

Updated: If you use Drupal, get ready to patch without delay. The org behind the popular open source content management system is warning of a highly critical vulnerability in Drupal core that is serious enough for it to tell users ahead of Wednesday’s patch release to set aside time to install the fix immediately. The Drupal Security Team’s Monday PSA announcing the imminent patch for Drupal core doesn’t include any specifics, with the PSA noting that Drupal isn’t willing to share additional information until the announcement is made alongside the patch release. That, says Drupal, will happen at some point between 1700 and 2100 UTC on Wednesday, May 20. To reiterate, this vulnerability is found in Drupal core, the bare-bones version of Drupal designed for developers, and not Drupal CMS, the preconfigured version for those who want Drupal but don’t have coding skills. Drupal noted that sites using Drupal Steward, its paid web application firewall service, are protected against known attack vectors, though it still recommends Steward customers update their core instances in case additional exploit methods emerge. “The Drupal Security Team urges you to reserve time for core updates at that time because exploits might be developed within hours or days,” the advisory warns. Drupal also recommends users update to the latest supported release prior to Wednesday’s patch “so that you can address any other upgrade issues before the security window." While it won’t get specific on the nature of the vulnerability, Drupal did share its severity score based on NIST’s standard scoring methodology, and it’s not good: The bug scored 20 out of a max of 25 on that scale, as defined by Drupal’s own documentation. More specifically, it’s trivially easy to leverage, doesn’t require any privilege level to exploit, could make all non-public data on an affected site accessible to the attacker, and could allow an attacker to modify or delete whatever they wanted. The only two things preventing it from scoring a perfect 25/25 are the fact that a known exploit doesn’t exist yet and that it doesn’t affect all configurations, only those using “uncommon module configurations.” Drupal noted that security releases will be published on Wednesday for all currently supported core branches (11.3.x, 11.2.x, 10.6.x, and 10.5.x), as well as unsupported Drupal 11.1.x and 10.4.x branches for sites that have not yet upgraded from older 10.x and 11.x releases. Drupal users on 8.9 and 9.5 are also getting patches “given the potential severity of this issue,” though the advisory warns 8.9 and 9.5 users will need to install those updates manually, which “might introduce other bugs or regressions,” leading Drupal to recommend a full upgrade to a supported core branch. “Drupal 8 and 9 include numerous other, previously disclosed, security vulnerabilities that will not be addressed by either Drupal Steward or the best-effort patch files,” the advisory said. Drupal 7 users are safe. Given the fact that not all Drupal core environments will be affected, the advisory recommends all Drupal core users set aside time on Wednesday to determine whether they’re part of the vulnerable class, and take action immediately if so. ® Updated to add on May 20: The Drupal Security Team has been in contact to warn that, while Core is the primarily vulnerable product, Core's inclusion in Drupal CMS means those environments might be vulnerable too, so anyone running Drupal will need to be sure their site is secure. As for the patch itself, Drupal told us it can be installed in "minutes or maybe seconds depending on the site," which likely won't need to be taken offline in order to install the patch.In other words, you really ought to be sure this gets installed before you're caught being a straggler.