Don’t get Mad, get wise

The Sophos X-Ops Incident Response team has been examining the tactics of a ransomware group called Mad Liberator.  This is a fairly new threat actor, first emerging in mid-July 2024. In this article, we’ll look at certain techniques the group is using, involving the popular remote-access application Anydesk. We’ll document the interesting social-engineering tactics the group has used and provide guidance both as to how to minimize your risk of becoming a victim and, for investigators, to how to see potential activity by this group.

Before we start, we should note that Anydesk is legitimate software that the attackers are abusing in this situation. The attackers misuse that application in the manner we’ll show below, but presumably any remote access program would suit their purposes. Also, we’ll note up front that SophosLabs has a detection in place, Troj/FakeUpd-K, for the binary described.

What is Mad Liberator?

The activity that Sophos X-Ops has observed so far indicates that Mad Liberator focuses on data exfiltration; in our own experience, we have not yet seen any incidents of data encryption traceable to Mad Liberator. That said, information on watchguard.com does suggest that the group uses encryption occasionally, and also undertakes double extortion (stealing data, then encrypting the victim’s systems and threatening to release the stolen data if the victim doesn’t pay to decrypt).

Typical of threat actors who perform data exfiltration, Mad Liberator operates a leak site on which it publishes victim details, in an effort to put additional pressure on victims to pay. The site claims that the files can be downloaded “for free.”

Figure 1: Mad Liberator’s disclosure site

Interestingly, Mad Liberator uses social engineering techniques to obtain environment access, targeting victims who use remote access tools installed on endpoints and servers. Anydesk, for instance, is popularly used by IT teams to manage their environments, particularly when working with remote users or devices.

How the attack works

Anydesk works by allocating a unique ID, in this a case a ten-digit address, to each device it is installed on.  Once the application is installed on a device, a user can either request to access a remote device to take control by entering the ID, or a user can invite another user to take control of their device via a remote session.

Figure 2: An Anydesk session with the ten-digit address prominently displayed

We don’t know at this point how, or if, the attacker targets a particular Anydesk ID. In theory it is possible to just cycle through potential addresses until someone accepts a connection request; however, with potentially 10 billion 10-digit numbers, this seems somewhat inefficient. In an instance that the Incident Response team investigated, we found no indications of any contact between the Mad Liberator attacker and the victim prior to the victim receiving an unsolicited Anydesk connection request. The user was not a prominent or publicly visible member of staff and there was no identifiable reason for them to be specifically targeted.

When an Anydesk connection request is received, the user sees the pop-up shown in Figure 3. The user must authorize the connection before it can be fully established.

Figure 3: A request from “User” to connect via Anydesk; as Anydesk admins know but end users may not, anyone can choose any username when setting up Anydesk, so an attacker could even call itself “Tech Support” or something similar

In the case our IR team handled, the victim was aware that Anydesk was used by their company’s IT department. They therefore assumed that the incoming connection request was just a usual instance of the IT department performing maintenance, and so clicked Accept.

Once the connection was established, the attacker transferred a binary to the victim’s device and executed it.  In our investigations this file has been titled “Microsoft Windows Update,” with the SHA256 hash:

f4b9207ab2ea98774819892f11b412cb63f4e7fb4008ca9f9a59abc2440056fe

This binary was a very simple program that displayed a splash screen mimicking a Windows Update screen. The screen was animated, making it appear that the system was updating, as shown in Figure 4.

Figure 4: An all-too-unremarkable Windows Update screen… or is it?

This program did not perform any other activity, which made it unlikely to be immediately detected as malicious by most antimalware packages. (Sophos has developed a detection [Troj/FakeUpd-K] for this particular binary and will continue to monitor developments on this.)

At this point, to protect the ruse from being discovered and stopped, the attacker took an extra step. Since this simple program could have been exited should the user happen to press the “Esc” key, the attacker utilized a feature within Anydesk to disable input from the user’s keyboard and mouse.

Since the victim was no longer able to use their keyboard, and since the above screen appeared to be something unremarkable to any Windows user, they were unaware of the activity that the attacker was performing in the background – and could not have stopped it easily even if they were suspicious.

The attacker proceeded to access the victim’s OneDrive account, which was linked to the device, as well as files that were stored on a central server and accessible via a mapped network share.  Using the Anydesk FileTransfer facility, the attacker stole and exfiltrated these company files.  The attacker then used Advanced IP Scanner to determine if there were other devices of interest that could be exploited within the same subnet. (They did not, in the end, laterally move to any other devices.)

Once the stolen files were under its control, the attacker then ran another program that created numerous ransom notes. Interestingly, these ransom notes were generated in multiple locations on a shared network location which was mapped to the device, rather than on the victim’s device itself.  These ransom notes announced that data had been stolen and provided details as to how the victim should pay the ransom to prevent disclosure of those stolen files. (Tactics such as these will be all too familiar to readers of our investigation of pressure tactics currently in use by ransomware gangs.)

Figure 5: The ransom note received by the victim; note the threats of reputational and regulatory damage, and note also that no ransom amount is cited

The fake Windows Update screen shielded the attacker’s actions from being seen on the victim’s screen. The attack lasted almost four hours, at the conclusion of which the attacker terminated the fake update screen and ended the Anydesk session, giving control of the device back to the victim. We did note that the binary was manually triggered by the attacker; with no scheduled task or automation in place to execute it again once the threat actor was gone, the file simply remained on the affected system.

Lessons and mitigations

This was a straightforward attack that relied on the victim believing that the Anydesk request was part of day-to-day activity. As far as our investigators could determine, the attack did not involve any additional social engineering efforts by the attacker — no email contact, no phishing attempts, and so forth. As such it highlights the importance of ongoing, up-to-date staff training, and it indicates that organizations should set and make known a clear policy regarding how IT departments will contact and arrange remote sessions.

Beyond user education, we highly recommend that administrators implement the Anydesk Access Control Lists to only allow connections from specific devices in order to greatly minimize the risk of this type of attack, AnyDesk provide some very valuable guidance and how to do this as well as additional security measures in the following link:

• https://support.anydesk.com/knowledge/security-tips

With additional advice available here:

• https://blog.anydesk.com/the-ultimate-guide-to-anydesks-security-features/
• https://anydesk.com/en/security

Procedural notes for investigators follow the conclusion of this article.

Conclusion

Ransomware groups rise and fall constantly, and Mad Liberator may prove to be a significant new player, or just another flash in the pan. However, the social-engineering tactics the group used in the case described above are noteworthy – but they are not unique. Attackers will always continue to develop and employ a variety of tactics to try and exploit both the human element and the technical security layers.

It can be a difficult task to balance security against usability when implementing tools within an environment, especially when these tools help facilitate remote access for the very people tasked with caring for business-critical systems.  However, we always recommend that when applications are deployed across a network, especially ones that can be leveraged to obtain remote access to devices, that careful review of the security recommendations by the vendor is considered. Where those recommendations are not followed, that choice should be documented as part of your risk management process so that it can be continually reviewed, or so other mitigations can be put in place to ensure it remains within the risk appetite of your organization.

Appendix: Investigating Mad Liberator

If you are investigating an incident in which you suspect that attackers may have leveraged Anydesk, look for useful event and connection data stored in the following files:

• C:ProgramDataAnyDeskconnection_trace.txt
• C:ProgramDataAnyDeskad_svc.trace
• C:Users%AppDataRoamingAnyDeskad.trace

The connection_trace.txt  file only contains the Address ID of recent connections and may not be all that useful on its own.  But it does at least allow you to narrow down the offending ID.

Figure 6: A look at connection_trace.txt, with information on the result of each event

There are four possible states for each connection:

• REJECTED – the end-user rejected a connection request
• User – the end-user accepted a connection request
• Passwd – password entered by the remote system to gain access
• Token – ‘Login Automatically’ option checked by the remote system

The ad_svc.trace and ad.trace files contain quite a lot of granular detail. These can be opened and viewed with a text editor such as Notepad and along with other events also contains connection data.  The ad_svc.trace file contains details of the source IP addresses of remote connections.

Figure 7: A look at ad_svc.trace; a questionable connection is highlighted in the image

The ad.trace file contains logs relating to file transfers, and events such as where user input is disabled.

Figure 8: The user’s input options are disabled

Figure 9: The file-transfer events

Although the logs will indicate the folder and how many files were transferred during data exfiltration, unfortunately the logs will not detail each file name.

If you have Sophos Intercept X installed, collecting this data is simplified. The following OSquery can be used within Live Discover in the Sophos Central Dashboard:

SELECT      strftime('%Y-%m-%dT%H:%M:%S', substr(grep.line, instr(grep.line, 'info') + 5, 19)) AS Datetime,     grep.path,     CASE        WHEN grep.pattern = 'Logged in from' THEN 'Login'        WHEN grep.pattern = 'Preparing files' THEN 'File Transfer from this Host'        WHEN grep.pattern = 'Accepting from' THEN 'Accepted Connection Request'        WHEN grep.pattern = 'Incoming session request:' THEN 'Incoming Session Request'        WHEN grep.pattern = 'Remote OS:' THEN 'Remote OS'        WHEN grep.pattern = 'Disabling user input.' THEN 'Disable Mouse and Keyboard'        WHEN grep.pattern = 'Download started' THEN 'File Transfer to this Host'        WHEN grep.pattern = 'Received a sysinfo request.' THEN 'System Information Request'        WHEN grep.pattern = 'Authenticated with permanent token' THEN 'Authenticated with Token'        WHEN grep.pattern = 'Authenticated with correct passphrase' THEN 'Authenticated with Password'        WHEN grep.pattern = 'Profile was used:' THEN 'Profile Assigned'     END AS 'Operation',     grep.line as Data  FROM file  CROSS JOIN grep ON (grep.path = file.path)  WHERE  (     file.path LIKE 'C:ProgramDataAnyDeskad_svc.trace'     OR file.path LIKE 'C:Users%AppDataRoamingAnyDeskad.trace'  )  AND  (     --AnyDesk     grep.pattern = 'Logged in from'     OR grep.pattern = 'Preparing files'     OR grep.pattern = 'Accepting from'     OR grep.pattern = 'Incoming session request:'     OR grep.pattern = 'Remote OS:'     OR grep.pattern = 'Disabling user input.'     OR grep.pattern = 'Download started'     OR grep.pattern = 'Received a sysinfo request.'     OR grep.pattern = 'Authenticated with permanent token'     OR grep.pattern = 'Authenticated with correct passphrase'     OR grep.pattern = 'Profile was used:'     )     ORDER BY Datetime DESC

The query even helps to sort the data into a usable table, as seen in Figure 10.

Figure 10: The output of the OSquery shown above, in useful tabular format

Acknowledgements

Harshal Gosalia, Ollie Jones, and Andy French contributed to this research.