The Ransomware That Was Not

Introduction

In most incidents, we are called in after the worst has happened: data exfiltrated, infrastructure crippled, and business at a standstill. Our job is to piece together what occurred and help the client rebuild and restart its business.

But this incident was different. We were called after the initial intrusion—but before the threat actor could launch their final, destructive phase. The client was still operational, turning the case into a race against time: could we find and contain the attacker before they triggered disaster?

The Worst Ten Words in English

To paraphrase President Reagan, perhaps the most terrifying ten words in English are: “I am from the Government, and I am here to help.” For private companies, hearing from government agencies is rarely good news.

Our story began with a call from the police: they, monitoring threat actor platforms, had found a fresh data dump from our client’s Active Directory environment—recent, authentic, and very much a problem. The bad news had just gotten worse.

This raised urgent questions: What had happened? What was about to happen? And how did it happen? That’s when Truesec entered the scene.

Here is how the investigation unfolded, step by step.

The Drowned Phish and the IT Guy from Kazakhstan

In early February, a handful of users reported a surge in spam—over 20 times their usual daily volume. Most of it slipped through the client’s antispam filters, with one user receiving nearly a hundred spam messages in a single day. This flood disrupted routines and heightened anxiety: something was clearly amiss.

Soon after, a couple of users received Microsoft Teams contact requests from someone claiming to be from the IT department. While the first user ignored the contact, the second accepted and started discussing.

This was, of course, the threat actor social-engineering their way to a single goal: have the user accept a Microsoft Quick Assist session, basically an on-demand, cloud-based RDP access to the user’s computer.

The user accepted the request.

Immediately, the threat actor transferred a tool onto the computer, the QaKBot (also known as QBot) malware (attack.mitre.org/software/S0650). This tool used a legitimate executable with DLL sideloading (attack.mitre.org/techniques/T1574/001): the executable was a legitimate, signed binary from Microsoft, while the DLL had been changed to include the malicious code in its loader.

Interestingly, the DLL was also signed, albeit with a certificate that the issuer explicitly revoked. Neither the OS nor the EDR present on the computer blocked the DLL, allowing the execution of the malware.

A searchable artefact QBot creates is the registry key “TitanPlus” that contains a list of C2 servers: this key consists of a string of encoded values, where “B” stands for a “.” and “A” for a “:”. The entry “1B2B3B4A443” reads as “1.2.3.4:443” and indicates that a C2 server is the IP address 1.2.3.4 using port 443. The string may contain multiple servers, separated with literal “;”.

Tell Me Who You Are. Or Want To Be.

The threat actor then accessed the corporate network via the VPN connection from the user’s computer. Quickly, it found the Active Directory servers and enumerated the AD objects, limited only by the privileged the user held. The data was dumped and exfiltrated to an external host using SSH.

Predictably, their next move is to escalate privileges until it reaches the Domain Administrator level, which has the ability to perform almost any action unconstrained.

We saw the threat actor exploit a misconfigured certificate template. Let’s explain a bit what happened.

In a Microsoft Public Key Infrastructure (PKI), the Certificate Authority (CA) may have certificate templates, these are configured “processes” a user may call to submit a certificate signing request (CSR) and obtain, if permitted and accepted, a certificate signed with the CA’s private key, that is a certificate recognized as trusted within the organization. A specific case is a user requesting a certificate with her or his account as the subject name, for example to authenticate against internal websites or sign emails.

These certificate templates are highly customizable and configurable. Among others, they enable administrators to allow users or groups of users to enroll their own certificates, that is to accept themselves their own CSR and receive the signed certificate in return, as opposed as to have to wait for an authorized person to manually accept the CSR. This option was set in the abused certificate template.

Another permission a user or group of users may have is the ability to provide a subject name in the CSR: the standard governing the certificates, X.509, has the provision for a “Subject Alternative Name” (SAN), a form of “also known as”: a typical example is a certificate being issued for several domain names, for example the same certificate covering “truesec.com”, “truesec.se” and “truesec.dk”. This option was also set in the abused certificate template.

The result is a certificate template which enabled any user to submit a CSR and approve the request, CSR that could contain a SAN. Now, a particular SAN that can be set is a “User Principal Name” (UPN), which in Microsoft AD parlance is a “user account name”. As there is no constraint on what SAN can be submitted, a user could submit a CSR containing an arbitrary UPN in the SAN, in essence, any user could request a certificate for any other user in the domain regardless of the privileges difference between the accounts.

The threat actor abused the vulnerable certificate template to submit and approve, under the unprivileged account it had access to, CSR for certificates containing a Domain Administrator’s UPN in the SAN. The privilege escalation was immediate.

From a detection standpoint, three event ID are relevant in the Security channel: 4886, 4887 and 4888. These indicates, respectively, the submission of a CSR, the approval of a CSR, and the denial of a CSR. The events contain all the relevant information such as the user requesting the certificate, the certificate template name and the SAN submitted.

From There to There

A few hours after the initial entry, the threat actor was on the network and possessed authentication tokens for Domain Administrators, effectively holding the “keys to the kingdom.”

The threat actor started moving from the user’s computer they compromised to the rest of the infrastructure using the certificates they generated: Microsoft Active Directory possesses a feature called Certificate Based Authentication (CBA), this enables a user to submit a valid certificate signed by the domain CA, and in exchange to obtain a Kerberos ticket for a given account, provided that the account is a subject name in the certificate. Note that this does not require the account to be the principal subject name of the certificate: the presence of the account name in the SAN is enough to consider the certificate as valid for the purpose of authentication. The Kerberos ticket, in turn, can be used to authenticate in the domain joined machines. While there are some subtleties to it, the net result is the ability for the threat actor to get access to any machine joined to the domain. Truesec’s Fabio Viggiani and Alexander Mattsson have presented this attack in a webinar (event.truesec.com/all_webinar_ps_cyberattack-decode_13_may_2025_registration), in which they show how the attack works and demonstrate what can result from the exploitation of a misconfigured certificate template.

Microsoft Windows registers the use of a certificate as a mean for authentication in the channel “Microsoft Windows Kerberos KDC”, under the event ID 39. The message indicates that a valid certificate was submitted but that there is no secure mapping between the user and the certificate.

I Smell a RAT

At this stage, the only thing left to do for the threat actor is to establish persistence and find a way back into the network without having the re-compromise a user computer.

A typical remote access tool (RAT) threat actors install is AnyDesk. While this is a legitimate application used by administrators, it has become a favorite of the threat actors’, and we saw it being deployed in this incident as well.

More interestingly, the threat actor also deployed another RAT, Level Software’s Level RMM. This tool includes both the RAT and an inventory application, which the threat actor leveraged to enumerate the systems on the network. Lastly, on one server the threat actor installed another copy of QBot.

The threat actor added a few administrator accounts. Noteworthily, one of these fake accounts had a name that ended in “$”: these accounts are usually machine accounts or managed service accounts – but in no case are they user accounts. Another pattern is the mimicking of existing account names, with some replacements, for example using a “1” instead of an “i”.

Interlude

Within 12 hours, the threat actor had achieved the full compromise of the network and the Microsoft infrastructure, had the possibility to come back at will and to use high privileges accounts. The whole network was compromised.

This is when all activities paused for a bit less than a week. We don’t know for a fact why, the main theory is that, up to this point, this was the work of an initial access broker. After the full compromise, the access was for sale on the darkweb, waiting for an affiliated to purchase it for the data exfiltration and destruction.

Act II and Putting the S in “Tunnel”

After that hiatus, the threat actor resumed their activities. There were a few new techniques displayed, one of which is the use of SSH to tunnel the traffic to the client’s internal network.

SSH enables port forwarding. When forwarding ports, one can choose a static port forwarding, where the listening port on one end of the tunnel will always lead to the same host/port on the other end. The other type of forwarding is the dynamic forwarding: the listening end of the tunnel behaves like a SOCKS5 proxy, enabling the requester to choose which host and port the connection will be forwarded to on the other end of the tunnel.

In these SSH tunnels, we saw the threat actor accessing RDP and WinRM (Remote Powershell) on the internal hosts, thus bypassing all firewalls and network protections in place.

To obscure the type of traffic, the threat actor used port 443 for the outbound SSH connection instead of the usual port 22, which is consistent with previous activities, namely the exfiltration of the dump of data from Active Directory performed in the initial steps.

Exposing SSH on port TCP/443 is far from being rare on the Internet: a search on Censys, done in May 2025, showed more than 23k servers doing so. Not all of them are malicious: in our network sensors, we identified a few occurrences of companies using SSH on port TCP/443 for legitimate business applications.

More of the Same

The threat actor deployed additional RAT on servers. It also created more administrator accounts in the environment, still following the same pattern of either ending the account name with a “$” or variations on existing accounts.

Saturday Night Frenzy

Once we knew which machine was used as the initial entry point, we recommended that the client contact the user and request the machine to be off and not used again. Unfortunately, a local IT manager allowed the user to start the computer due to an urgent task and the difficulty to provide a new machine timely. This permitted the threat actor to return to the network while we were busy putting containment measures in place.

Understanding that it had been discovered and was about to be expelled, the threat actor threw a last ditch effort to exfiltrate data. To do so, it used rclone to copy files out from servers, focusing on documents created within the last 3 years. We spent the evening quashing these processes as they appeared while the team prepared for the eradication of the threat. After that, no more actions related to the threat actor were seen on the network.

Takeaways and Lessons Learned

Operational/tactical

• Review all the Microsoft Certificate Templates (if you use them) and plan to do so periodically
• Know your event IDs and search for them, in addition search for anything that behaves strangely
• Control the traffic coming from the VPN based on the user roles: a user has no need for RDP access to the servers
• Audit the RDP sessions to the servers, especially to the Active Directory servers, monitor more generally all management protocols
• Restrict, monitor and audit the Domain Administrator’s activities and privileged logons, which is facilitated when using a tiered structure
• Monitor the user creation, especially for those whose names do not conform to the naming convention in place, and send a notification when accounts are added to a high privilege group in Active Directory
• Look for any sign of strange or weird activities taking place, for example an application using the port reserved to another application or new applications appearing on the network
• Determine whether the infrastructure is hindering or helping the prevention and detection of a threat actor
• Do not be afraid to ask for help or a second opinion. As technologists, we understand it is oftentimes hard to admit gaps in our knowledge.

Strategic

Go beyond the mandatory phishing exercise: too often the cybersecurity awareness program is limited to sending a few phishing emails and berating the users who fell for it.