Clustering attacker behavior reveals hidden patterns

A collection of very specific behaviors, observed by Sophos X-Ops incident response analysts in the lead-up to four separate ransomware attacks in the first quarter of 2023, indicates an unexpected connection between the attacks.

In the parlance of the Managed Detection and Response (MDR) team, the peculiarly similar details constitute a threat activity cluster that Sophos can track. The Sophos MDR team performed postmortem investigations at the request of the targets. The attacks we examined targeted disparate businesses and geographies where they operate, and involved different ransomware groups.

Why this matters

• Knowing who is doing the attacking while a ransomware attack is taking place, and their usual behavior, can give a defender valuable insight into what the attacker might do next.
• A threat activity cluster isn’t an attribution, but is a stepping stone to making an attribution to who might be behind an attack.
• Threat activity clusters don’t necessarily include the more common aspects of attacker behavior; Rather, these include very narrowly-focused details that are not apparent to anyone other than the target and their defender(s), and would be hard for someone who isn’t the attacker (or who isn’t following a detailed attacker playbook) to replicate.
• The criminals who operate Royal ransomware reputedly don’t publicly solicit affiliates to work with them. The threat activity cluster indicates that this secretive group may actually be working with outside affiliates, and may be recruiting elsewhere.
• This threat activity cluster has already borne fruit, linking these attacks to a Cactus ransomware attack reported by Kroll.

A step towards attribution

Ransomware-deploying threat actors do have a tendency to reuse a lot of the same tools, techniques, and procedures; Some ransomware groups have even created playbooks for their affiliates to follow. For example, many of them deploy Cobalt Strike beacons as a form of remote access to the target’s network, or may perform brute-force attacks against Remote Desktop as a way to laterally move within a target’s network. Many also target an organization’s Domain Controller servers as a way to take control of other machines on the network.

But these are broad strokes; the behavioral details in this threat activity cluster are far more narrowly focused.

In the run-up to each ransomware attack, logs and records collected by Sophos MDR show very specific patterns of behavior:

• the attackers created their own administrator-level accounts on hijacked Domain Controller servers using the same usernames and complex passwords too specific to have been random chance
• installed persistence mechanisms for their tooling with the same names, and in the same ways
• employed identical pre-deployment batch scripts to lay the groundwork for the ransomware deployment
• deployed the final ransomware payload using the same paradigm: Dropping a .7z archive, named after the organization that was being targeted, that contained an executable also named after the targeted organization. The .7z archive was password-protected with the same password, and deployed with the same shell command.

What made the threat activity cluster all the more interesting to Sophos MDR is that, among the ransomware deployed during the attacks, two of the attacks involved ransomware known as Royal – a notoriously closed-off group of ransomware developers and attackers who, reputedly, do not solicit outsider “affiliate” attackers to work with them on cybercrime forums.

While a threat activity cluster is not the same thing as an attribution, it could eventually lead to an attribution, given enough high-confidence evidence. Observing the same behaviors does not necessarily mean that these attacks were all carried out by the same individuals. Rather, it seems like the attackers in these cases followed a playbook curiously similar to one another. A fifth attack, involving yet another different ransomware payload, analyzed by the company Kroll, also appears to share the characteristics of this threat activity cluster.

A closer analysis of six attacks involving Royal ransomware showed that the threat activity cluster characteristics lined up in two of the attacks.

Repeat use of the same files, passwords, and names

Sophos drew the threat activity cluster connection by studying the details of attacks against four targets, involving three ransomware families, over the course of three months.

Of the ransomware that was deployed in the incidents – Royal, Black Basta, and Hive – two of the ransom groups publicly disclose that they use affiliates, while Royal reportedly does not advertise on crimeware forums, soliciting affiliates to work with them, as the others do.

The threat activity cluster is based on specific behaviors and tooling, including:

• the use of the same batch scripts and files: file1.bat, file2.bat, ip.txt, and gp.bat
  • file1.bat: a batch file designed to set up the system with autologon as the newly-created administrative user AdminBac, reboot into Safe Mode (several ransomware groups leverage Safe Mode, because real-time detection and protection products are typically disabled in that environment), and execute File2.bat
  • file2bat: a second batch file, executed in Safe Mode via a registry key, designed to unpack the ransomware binary from the encrypted archive (using a bundled copy of 7-Zip), execute it, and wait for it to finish encrypting files before rebooting the affected computer back into normal mode.
  • ip.txt (sometimes ip1.txt): a list of hostnames on a given internal domain, generated using a widely-abused, legitimate tool called Advanced Port Scanner.
  • gp.bat executes file1.bat by forcing a Group Policy update
• When the attackers take over a Domain Controller or other system, they create one or more rogue user accounts with administrative privileges, with specific usernames and passwords, adding them to the local adminstrators group using net.exe and directly modifying Registry entries to remove restrictions.
  • Adm01/Adm02 | Pa$$w0rd991155 and AdminBac | P@ssW0dDP@ssW (first incident, Hive)
  • Adm04 | Pa$$w0rd12321 and AdminBac | P@ssW0dDP@ssW (second incident, Royal)
  • Adm066 | Pa$$w0rd11225 and WDAGUtilityAccount | P@ssw0rd123456789 (third incident, Black Basta)
  • AdminBac | P@ssW0dDP@ssW (fourth incident, Royal)
• The creation of persistence methods using Scheduled Tasks with tasks named Microsoft Update, Windows Update, Windows Update 1, Windows Update 2, Windows Sensor qe, Windows Sensor qe 1, etc.
• During the ransomware deployment, the threat actors deliver the final payload in a .7z archive named after the victim organization, password protected with the password The ransomware binary is named the same as the 7z archive. The threat actor extracts the ransomware executable to the C:\Windows directory and executes it from there.
• Retrieved Cobalt Strike beacons from public sites like Pastebin or Textbin, on presumably-compromised domains, or in the IPFS network.

In addition, the threat actors employed a range of tools and techniques common to many ransomware affiliates, but even here, there were particular details that were consistent:

• Network reconnaissance using Advanced Port Scanner
• The extensive use of PowerShell commands converted into base64 strings
  • However, in this threat activity cluster, the attacker also created a duplicate copy of PowerShell.exe named exe and executed PowerShell commands from it.
• Installation of a secondary, backup remote access with Cobalt Strike
  • This attacker typically dropped and ran a Cobalt Strike beacon with a specific name:tmp
• Use of commercial remote access tools, such as TeamViewer, WizTree, or Citrix Enterprise Browser.
• Lateral movement via Remote Desktop.
• Dumping the NTDS and Registry hive for credential extraction
• Use of dual-use tools like PsExec
• Payloads hosted on public services like Pastebin
• Staging network scan and exfiltrated data the same way, in the same locations, moved off the system using rclone.
• When malicious activity was thwarted through endpoint protection, the attackers rebooted the systems they controlled into Safe Mode as a last-ditch effort to sabotage protection.

We investigated these incidents post-mortem. In some cases, analysts were unable to retrieve the files themselves, but did receive telemetry with file hashes, and were able to correlate the same payload scripts delivered across multiple attacks in some cases.

We also observed shared infrastructure used by the attackers, with command-and-control traffic leading to the same IP addresses in attacks involving different ransomware families as the eventual payload.

And in at least one of the incidents, the attackers gained initial access to the target’s network via a webshell that had been placed into the location where the target had previously installed an IT management software called ManageEngine. In January 2023, at around the same timeframe in which the attacks took place, ManageEngine’s publisher Zoho released a security advisory detailing CVE-2022-47966 an unauthenticated remote code execution vulnerability. In January 2023 there were also reports of attacks against this vulnerability. Based on this timing we assess it a reasonable possibility that the attacker either leveraged this exploit themselves, or paid an initial access broker — a third party — to use these webshells. Other incidents began when the attacker used previously-stolen credentials for remote access tools already present on the “patient zero” device.

Threat activity first observed in a January Hive attack

The initial detection of the threat activity cluster behavior was found in logs collected during a Hive ransomware attack that took place around the beginning of the year against a target organization that was using another company’s endpoint security product.

The Sophos analysts who performed the postmortem investigation believe the Hive phase of the compromise began with a brute force attack against an internet-facing Remote Desktop instance in the target’s network. But analysts retrospectively discovered that there were indications as early as  November 2022 that threat actors had already gained a foothold on the target’s network.

The threat actors installed a commercial remote access tool called DWservice then waited a full week before they began to collect information about the network and its users. Once they established a list of internal target machines, the attackers made two attempts to remove the endpoint security product; the second attempt was successful. Within 30 minutes they had pushed out a PowerShell script that disabled Windows Defender, simultaneously retrieving and executing an encoded form of a Cobalt Strike beacon from Pastebin, and the attackers were thereafter unhindered in the subsequent phases of the attack.

The Cobalt Strike loader came in the form of a PowerShell command with an enormously long base64 string. That decoded into a different script, with another base64 block in it (shown above). The second base64 block decoded to a Gzip archive that contained yet another script, and that script also included a base64 block which the script not only decoded but XORed to return the final payload – the beacon shellcode, which the final script writes directly into memory.

A simple CyberChef recipe can decode this.

The attackers spent the next three hours running automation that created administrative-level user accounts — Adm01, Adm02, Admin12, and AdminBac — on thousands of machines across the target’s network, then used that account to create Scheduled Tasks that established persistence of their Cobalt Strike beacon. We found logs that indicated the attackers ran files named 1de.bat and 2.bat to do that. Those scripts were, in turn, triggered by a third batch script named gp.bat, which forced a Group Policy update.

Just 13 hours after this burst of activity, the threat actors launched the Hive ransomware binary on the target’s network.

Near the end of January, law enforcement took control of (and action against) the network side of the operation for Hive ransomware, announcing that they had been involved in a half-year-long sting operation where they had infiltrated Hive’s backend systems. The Department of Justice press release was released after the first of the attack targets in this investigation was hit with Hive, and subsequently the target was able to decrypt their data without paying a ransom.

The disruption of the Hive network could very well have precipitated one of their affiliates to seek other employment, which may explain why the TTPs seem to repeat across multiple incidents that follow Hive’s end as a ransomware operation.

The Royal attachment

Sophos investigated Royal ransomware for the first time in late 2022, but Royal attacked several targets within a few days in February, 2023 and continued in March. Among the Royal incidents we investigated in February and March, Sophos observed the threat activity cluster behaviors in two of them.

In both of the Royal ransomware incidents (the third and fourth attacks in this investigation), access came through a trusted third party (also hit by the Royal threat actor at around the same time) that had a device on the organization’s network. The threat actor gained a foothold on the system, with Administrator privileges, after compromising that third party’s TeamViewer account. Discovery and lateral movement followed, with the threat actor using Advanced IP Scanner (for the former) and RDP (for the latter).

The threat actor spent time using Powershell commands to create new administrative user accounts and push out those credentials to any Windows machine it could reach, then turned their attention to locating, collecting, and exfiltrating a wide variety of sensitive, internal documents by packing them into an archive and using the tool Rclone to move them to a remote server. Roughly four days after the initial access, Royal struck.

Next, the threat actor ran a PowerShell script called TotalExec.ps1 – twice. On first execution, the script executed gp.bat to set up File1.bat to run on all the hosts listed in ip.txt and ip1.txt.

On its second run the script deployed File1.bat on all the targeted machines, which in turn set the whole encryption process in motion.

As previously mentioned, Sophos X-Ops was called in to perform an analysis of six Royal ransomware incidents in the last few months. A comparison of some of the techniques and tools we saw in those attacks shows that the threat activity cluster details described in this report were used in two of those attacks.

Looking at these attacks we can see some similarities, but also some significant deviations. For instance, initial access vectors vary across attacks, which may be the result of Royal purchasing access from different Initial Access Brokers (IABs) with different methods. In two cases, Royal leveraged a third party’s access to a targeted organization; in another case (possibly two), it used compromised VPN credentials. However, in a very different approach – possibly the result of malvertising or ‘callback phishing,’ both of which Royal has been known to use – a fake TeamViewer download provided an initial foothold.

Some of the tactics we observed seemed to differ from those described by other researchers, which could be an indication that the group’s MO continues to evolve. For example, we didn’t see the threat actor attempt to disable antivirus or EDR (a behavior change also noted by researchers from VMware’s Carbon Black unit in a case they investigated). Sophos did respond to a case last autumn where a Qakbot infection led to a Royal ransomware attack. Of course, that’s not to say that Royal has abandoned these tactics altogether, but we didn’t see evidence of that in the attacks where we performed a postmortem analysis.

Royal ransomware is a growing threat. Despite not openly running an affiliate program on the criminal forums where ransomware groups typically solicit the affiliates to sign on with them, this attack and others demonstrate that the group is capable of perpetrating frequent, large-scale attacks, and adapting its tactics to devastating effect. If anything, the data suggests that Royal may be soliciting affiliate work through a more covert channel of communication.

Enough Basta

While some of the behaviors in the Black Basta attack — the second of the four incidents that make up this threat activity cluster investigation — varied slightly from the Hive and Royal attacks, several behaviors raised questions about the threat actor’s familiarity with the Hive and Royal playbooks.

Initial access, in this case, came from a JSP web shell installed on an internet-facing ManageEngine server that had a vulnerability. They used the shell to retrieve and run an executable, and add it to the Windows Defender exclusion list.

The Black Basta attacker also employed a number of scripts that scanned the network for Java .JAR apps that might be vulnerable to the Log4j exploit, several of which were recovered.

The threat actor in the Black Basta incident also tried to run the file1.bat script from the C:\Windows folder, but was thwarted by endpoint protection on the machines running Sophos. They succeeded in using the net.exe command to create a user with administrative privileges, with the username (Adm066) and password (Pa$$w0rd12321) following a paradigm close to the user credentials created in the other three incidents.

The attacker in this incident struggled with multiple blocking actions when executing Cobalt Strike and Meterpreter payloads, running PowerShell scripts, engaging in lateral movement via RDP or by trying to execute reverse shells using certutil.exe, and make password dumps. Sophos endpoint protection stopped the vast majority of the attempts. The attacker tried to run a program that would uninstall Sophos multiple times, but tamper protection prevented the removal.

Eventually the attacker attempted to install AnyDesk through the creative use of base64-encoded PowerShell commands four separate times, but failed. They then used a tunneling software called PuTTYlink to move files to the infected host.

The attacker eventually rebooted the machine three times in an attempt to get around endpoint protection, but failed. They were able to encrypt a portion of the target’s network that had machines not protected by Sophos software.

What a cluster

While most organizations cannot perform attribution with high confidence, there is clear value for security companies tracking campaigns, activity clusters, and threat groups. Sophos uses the intelligence we gain through analysis to protect our customers.  That is why  our primary outcome is to determine the best ways to stop that malicious behavior and detect it as early as possible, to limit the damage threat actors can cause.

In that vein, analyzing threat activity clusters makes a lot of practical sense, because the MDR team can use that knowledge of threat actor behavior and activity to improve its ability to quickly identify undesirable behavior on a network, and isolate the machines where those behaviors appear to originate.

Between our AMSI behavioral detections, in-memory detections of tools like Cobalt Strike, and signatures that can detect malicious scripts and command-line commands, Sophos software can prevent malicious activity before the attackers can gain a foothold. The attack analysis and fusion of knowledge about threat activity clusters helps inform the teams who work on those detections how threat actor behavior evolves over time — or doesn’t, as the case may be.

Acknowledgments

Sophos X-Ops would like to thank Sergio Bestulic, Harinder Bhathal, Nathan Mante, and Robert Weiland of Sophos’ Incident Response (IR) team, and Colin Cowie and Paul Jaramillo of Sophos’ Managed Detection and Response (MDR) team for their contributions to this article.