Leaked internal chat logs reveal a coordinated strategy in which Black Basta affiliates use Extended Validation (EV) certificates to sign malicious files. This tactic leverages the enhanced trust typically associated with EV-signed applications. Organizations that rely on signature-based trust alone become vulnerable, as these certified binaries easily slip through conventional scanning mechanisms. The conversations detail how attackers acquire, manage, and automate the process of evading detection by signing malware, underscoring the degree of organizational discipline behind ransomware groups’ operations.
What are EV Certificates and How did Black Basta Get Them
Extended Validation (EV) certificates are special digital certificates that show a high level of trust in an application or website. The issuing certificate authority (CA) does extra checks on the company or individual requesting the certificate, making sure they really are who they say they are. In practice, users and many security solutions trust EV-signed software more because it’s “verified” by an official authority.
While some threat actors have been known to impersonate closed companies, the logs confirm that Black Basta either:
1. Directly purchased EV certificates
BlackBasta purchased EV certs for $4,000–$4,500 from underground forums or brokers.
"по $4000 каждый" (“$4000 each”)
"таких у нас еще не было" (“we’ve never had ones like these before”)
"сейчас возьму пару штук про запас" (“I’ll grab a couple more just in case”)
"скидоссссс)))" (“got a discount haha”)
These messages were typically paired with .rar files containing EV certs, often labeled with company names (e.g., EV56wallfort[SSL.com].rar, EV4Avikser-llc2023-10-27[GlobalSign].rar)
They also linked to hosting platforms like: https://send[.]exploit[.]in/download/... https://transfer[.]sh/... These hosted the actual stolen/fraudulently obtained certificate packages.
2. Compromised remote signing infrastructures
The group used VirtualHere and YubiKey Minidriver tools to remotely access EV tokens that were physically plugged into compromised.
**"You need Token17, double click to connect. Password: ******. Token PIN is 123456" "Run certmgr.msc and check if the cert was added" "Sign your files with signtool.exe"
In a critical chat, a user states:
"я переезжаю с той рдп – она в блеках" "I’m moving off that RDP – it’s blacklisted."
This refers to an RDP server that previously housed sensitive signing infrastructure (likely EV tokens) and was blacklisted. These tokens are typically stored on hardware (e.g., YubiKeys), but they were accessed and used remotely via tools like VirtualHere and signtool.exe, as detailed in other messages. It implies the EV certificate wasn’t bought anonymously—it was stolen from a real business or developer, likely through RDP compromise.
The leaked Black Basta conversations identify two specific EV certificate authorities (issuers) that were abused for malware signing: SSL.com and GlobalSign.
Black Basta’s EV Operational Workflow
MSI (Windows Installer files) and VBS (Visual Basic scripts) were used as initial infection vectors. These loaders dropped or launched the actual malware payload (e.g., ransomware, PikaBot, Cobalt Strike). Signing them with an EV cert reduced the chance that email filters, antivirus, or Windows SmartScreen would block them.
Once in possession of the EV certs, attackers:
- Signed payloads only after encrypting to avoid hash mismatches.
- Warned each other not to alter files after signing, as it invalidates the EV signature.
- Used these certs to sign repacked PikaBot installers, MSI and VBS loaders, and other malware stubs. The conversations reveal detailed instructions used by Black Basta affiliates for signing their malware with EV certificates—both for .pfx-based certs and hardware token-based (e.g., YubiKey) EV certs. Below is the extracted exact signing procedure and command-line usage:
Signing with .pfx-Based EV Certificates
Tooling Requirements
- Microsoft Windows SDK (providing signtool.exe)
- Valid .pfx certificate file plus the password Example Sign Script (sign.cmd)
Example Sign Script (sign.cmd)
@echo off
set SIGNTOOL="C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x64\signtool.exe"
set CERT=cert.pfx
set PASSWORD=********
set FILE=calc.exe
set TIMESTAMP=http://timestamp.digicert.com
%SIGNTOOL% sign /f %CERT% /p %PASSWORD% /fd SHA256 /tr %TIMESTAMP% %FILE%This script ensures the binary is time-stamped, preventing signature invalidation post-certificate expiration. Attackers sign only after encrypting to maintain signature integrity. Any binary change post-signature invalidates the EV mark.
Hardware-Token-Based EV Certificates (YubiKey & VirtualHere)
Remote Access Setup
- Attackers install VirtualHere on both client and server sides to forward the USB token connection across an RDP session.
- The YubiKey Smartcard Minidriver is loaded on the remote machine, enabling Windows to recognize the certificate in certmgr.msc.
Signing Command
signtool.exe sign /sha1 <certificate_thumbprint> /tr http://timestamp.digicert.com /td SHA256 /fd SHA256 <payload.exe>The certificate’s thumbprint is obtained via Windows certificate properties or certmgr.msc. The attackers highlight that adjusting the binary after signing destroys the EV signature’s validity, so they strictly sign last.
Additional insights in the Black Basta EV process
- Some affiliates built automation scripts to bulk-sign multiple files using predefined sign.cmd templates.
- Chat logs indicate that multiple EV certs were stored in a central repository. A documented “storage failure” event caused turmoil because “all our keys” resided on a single compromised VDS.
- References to certain archives (.rar files) containing EV certs (e.g., EV56wallfort[SSL.com].rar) confirm the group’s practice of keeping multiple certificates for on-demand usage.
- The group systematically watched for revoked certificates, swiftly rotating to a fresh EV cert when detection surfaced or when the signature authority blocked the known stolen credential.
What does this mean for your company?
When malware shows up wearing the badge of a trusted company (via an EV certificate), it’s like a criminal in a convincing police uniform. Many automated checks might initially let it in. This erodes the trustworthiness of digital certificates, makes it harder to spot malware, and can lead to very real damage—like ransomware encrypting an organization’s data or attackers stealing information.
If your systems rely solely on signature-based allowlists or only trust EV-signed code, you are at risk. EV-signed malware initially bypasses most conventional checks and user skepticism.
The attackers’ “socks bots” strategy also complicates IP-based detection or blocking. Even if one node is shut down, they can pivot to a fresh proxy node and maintain continuous distribution.
What should you do to defend against EV certs exploits?
The stolen EV certificates in threat actor’s possession serve as a powerful camouflage tool, enhancing the success rate of their infections. Black Basta’s chat logs confirm a recurring pattern: once detection thresholds rise for a given payload, the group modifies and re-signs it with another EV certificate, perpetuating a high-volume cycle of malicious file distribution. This systematic approach exploits vulnerabilities in how many security controls interpret signed code, making it crucial to deploy more advanced, behavior-focused defense strategies.
Tools that look beyond the signature and watch for suspicious behavior are your best defense. Even if a file has a seemingly legitimate signature, a product like the Vectra AI Platform can flag abnormal actions within your network. Combining it with your existing endpoint detection and response (EDR) solution would enable you to isolate or contain suspicious executables rapidly and stop them fom spreading—even if they are EV-signed.
Want to see Vectra AI in action? Request a demo today!