Sophos News

Clustering attacker behavior reveals hidden patterns

  • Andrew Brandt and Matt Wixey

    • 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

    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:

    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.

    The Royal ransomware ransom note. The redacted line is an alphanumeric string, unique to each victim, which is also used as a command-line parameter for the ransomware binary. A similar technique was used by the Hive ransomware gang.

    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 file1.bat script creates user accounts the attackers leverage during later stages of the attack, and sets up the file2.bat script to run on reboot.

    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:

    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 shellcode loader deployed by the attackers used several layers of encoding.

    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 final decode level of the Cobalt Strike loader included shellcode that embedded the IP address of the Cobalt Strike C2 (highlighted) and a generic-looking User-Agent string, as shown in a CyberChef recipe.

    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.

    The file2.bat script runs only after a reboot into Safe Mode. The script launches the ransomware while the computer is running in Safe Mode and then reboots it back to regular mode after the ransomware has completed its tasks

    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.

    Comparing some of Royal’s TTPs in recent attacks. Bolded items in the table constitute threat activity cluster data shared across these and other ransomware attacks. Attacks 3 and 4 comprise the two attacks we documented as part of the threat activity cluster. Bolded items highlight threat activity cluster details shared in these and other 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.

    One of the JAR application search commands used by the attackers during the information gathering phase of the attack.

    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.