Caught in the act: Ransomware attack sticks to our AI-created honeypot

Here is the story of how we caught a ransomware attack in our research honeypot.

Ransomware attacks on enterprise organizations lead the news. See Change Healthcare and Ascension. Attackers spend their time on the victim’s network, exfiltrate gigabytes of sensitive data, then lock victim’s systems — and ask for millions of dollars in ransom payment.   

We also hear news about how AI is used maliciously. Recently, a finance worker was deep faked by AI on a video call and paid out $25 million.  

But what do attacks on small to medium businesses (SMB) look like? And what does it look like to use AI in security research? 

To answer these questions, Forescout Research – Vedere  Labs uses generative AI to create realistic and persuasive honeypots on our Adversary Engagement Environment (AEE). We emulate SMBs to attract attackers and share our findings with the security community.  

In this case, our attacker attempted to use Phobos ransomware on our fake healthcare clinic in a large US city. All the copy on the company’s website and all the employee images were created by generative AI. 

How to catch a ransomware attack on an SMB: The setup

Our AEE collects threat intelligence in real time from real attacks. This environment includes:

• Medium-interaction honeypots replicating IoT devices
• Real OT devices exposed with weak configurations
• Simulations of large OT/ICS physical processes
• Networks of virtual machines masquerading as entire companies

Each type of honeypot serves a different purpose.

IoT device simulations are very good at catching attacks from botnets, crypto miners, and other common automated or opportunistic attacks to IoT devices. These simulations give us high-volume, low-level threat intelligence as individual indicators of compromise.

Real OT devices allow us to observe more targeted attacks from opportunistic hacktivists and state-sponsored actors. These devices show us the types of vulnerabilities being exploited in semi-automated attacks.

Company simulations entice attackers to spend some time and interact with the honeypot — and allow us to capture more complex attacks to study more TTPs.

To capture interesting attacks, you have to create a sophisticated honeypot – which is labor intensive. After a successful compromise, a honeypot’s identity is discarded, so the work must start again from the beginning.

To catch ransomware, create realistic honeypots with AI

To simplify the process of creating believable honeypots, we divide the problem in two parts: the network infrastructure and the corporate identity that goes over this infrastructure.

The network infrastructure for the honeypots is simple and remains fairly constant — with changes in domain names, IP addresses and other easily identifiable information every time a new identity is developed.
There is one Windows server, such as an e-mail or web server, and a Windows workstation on a portion of the network that has public and private IP addresses. Plus, it has a domain controller and another Windows workstation that only have private IP addresses, so they can only be reached after one of the public machines is compromised.

All the communication in that network and events in those machines are monitored by Forescout solutions, such as eyeInspect and TDR. The resulting detections become part of our shared threat intelligence.

On top of this basic network, we include a corporate identity that simulates an SMB in a specific domain. To do that efficiently, we turn to generative AI in two steps:

• Use LLMs, such as ChatGPT, to create a company name, description and information that will go on the company’s website.
• Use a plugin, such as GoDaddy on ChatGPT, to register a domain and build a website based on this LLM-generated information.

To an attacker searching for ways to breach healthcare businesses, this is what a list of possible targets with open Remote Desktop Protocol (RDP) servers – one of the favorite initial access techniques today – looks like when searching on an engine such as Shodan:

Among that list is the e-mail server of our AI-crafted target healthcare clinic:

If the attacker browses the website associated with that domain, they will encounter a seemingly real clinic, which could offer a quick reward for a ransomware operator.

Analysis of an incident: Phobos ransomware

We deployed the healthcare honeypot on February 19. On March 10, we noticed that the RDP login screen of the exposed e-mail server suddenly looked like the image below.

The message on the screen (and the associated e-mail address) points to a variant of the Phobos ransomware which was the subject of a recent advisory from CISA.

Then, we turned to Forescout TDR to understand how attackers gained access to the environment and their actions were once inside. Since this is a honeypot, it receives RDP scanning and brute-forcing attempts almost continuously – just like a real business.

The first clue of a real compromise was the creation of a new “ITadmin” account on the domain controller and a successful login using that account from 141.98.81[.]5, an IP address based in Panama which is known for RDP brute forcing. That information flowed to TDR from the Active Directory data source.

We then checked the TDR logs coming from eyeInspect and saw connections from 179.60.150[.]59 and 84.247.174[.]6 as well as many other bruteforcing attempts from other IP addresses that fit the incident’s timeline (list of IP addresses at the end of the blog).

Here is a TDR detection for one of the connections:

To reconstruct other details of the incident, we also analyzed the Windows logs on the e-mail server. We noticed that after initial access the attackers downloaded netscan.exe into C:\temp and used that executable to perform a network scan.

The attackers then created a directory C:\temp\[email protected] and downloaded a file MsMpEng.exe which was a variant of the Phobos encryptor. They tried to run the encryptor five times, but every time it was caught and quarantined by Windows Defender. Then, they disabled the antivirus and managed to execute the file. Since they did not clean the quarantine, we were able to recover the malware sample used in the attack:

The sample was compiled on March 31, 2020 and first seen on VirusTotal on August 4, 2023 – so it was not new to this attack. The sample was very similar to others that have been covered in previous research. The main differences to those samples were:

1. The 32-bit RSA key used to decrypt the embedded config file, as well as the public RSA key of the attackers used to encrypt files were different. However, the public key has been observed on other samples since 2019:bdc1491a732efa44d43dd19215d8ec5d0ddb950c3368c0a006e90c2444881b12f3dccc7038485577466cedb575906c8ec92d55094d66d87d46ab990987349f182a7e4d05bf2acce9aafeab53f6a3741ed867e4942de5df6b11c6de77faa400606fe7d78c233065b12a0c5042e0d911b08f67928ed905eeb0e81cb8eccb5baab7
2. The versions string present in the file indicates v2.9.1, which has not been often mentioned in the past, but it is also something that has been seen in other samples.
3. The lists of file names and extensions used for multiple purposes (encryption, exclusion, process termination) are set in the config file:

After executing the malware, the encrypted files had the following extension (with the unique victim ID redacted):

The victim ID is based on two parts, which we have not seen mentioned in previous research: the first (before the dash) is taken from the hard disk’s serial number (shown in the image below) and the second (after the dash) is hardcoded in the config file.

The ransom note dropped on the machine was the following (again with the victim ID redacted):

The whole incident took approximately 10 hours on March 10. From initial access to encryption – this is the cyber equivalent of a smash and grab.

While we were doing the analysis on March 13, the attackers connected to the compromised machines again and erased Windows logs via Powershell (we kept access to the machines open exactly to capture post-compromise activities like this):

After the incident, we searched for similar but more recent samples (the last 15 days) on VirusTotal and discovered:

• “AntiRecuvaDb.exe” (hash at the end of the blog) was submitted from Colombia only once on March 15.
• “program.exe” was submitted from the US and China twice on March 15.
• “Fast.exe” was submitted from Uzbekistan twice on March 14.
• f7833f259149a11e0ff804ad2eb538153034d4f14a0d3f7d2e821a0adf69f955 was submitted from Canada once on March 9.

Although they were first seen on VirusTotal, they all have the same creation date as the sample used in this incident (2020-03-31 14:17:25 UTC) and they all use the same RSA key. We did notice four e-mail addresses associated with these samples that were not mentioned previously in the CISA advisory: icanrestore@onionmail[.]org, data199@mailum[.]com, harry_whitest@zohomail[.]ca and nicetomeetyou@onionmail[.]org (they are used to contact the ransomware group).

We also contacted the attackers that targeted our honeypot on the provided address (helpforyou@gmx[.]com) and got the following initial response almost immediately:

Then, we contacted them again after a week asking for a discount of 50% (which is very normal in ransom negotiations), to which they agreed and shared their bitcoin wallet address. Unfortunately, the wallet was empty and had no associated transactions when we checked it (March 21). Clearly, we did not proceed with the payment.

What we learned for future honeypot work with AI

Convincing honeypots can entice cybercriminals. In our case, they were not the most sophisticated actors that would target a large organization – as evidenced by the five attempts to run the encryptor with Windows Defender with it still on — and by the use of an older sample of Phobos.

Had they paid more attention, they might have noticed that the machines were empty of meaningful files or that the doctors mentioned on the company’s website did not really exist. At least two elements were missing in this healthcare example that we plan on adding to future honeypots:

• Personas, a realistic set of employees that work at the company, exchange messages and have social media profiles.
• Pocket litter or honeyfiles, a set of documents that makes the attacker believe they are hitting a realistic target.

Generative AI can create those too. One of the experiments we realized was about a company in the architectural consulting and technology domains (“Archifection”). We first asked an LLM to generate a set of users for this company with meaningful titles, salaries, corporate accounts —and then a company profile with some of these employees on a website.

We also instructed the LLM to create several ‘confidential’ documents and e-mails from these ‘employees’ to each other about their tasks:

This type of file can then be kept on the e-mail server, exposed on a ‘misconfigured’ file server or kept in internal machines to lure attackers into exfiltrating them. Further, we can create social media accounts for these employees with posts that sound real and are based on domain knowledge relevant to the organization we are modeling.

Observed Phobos Indicators of Compromise (IoC)

The IoCs below, observed during our analysis, are automatically ingested into our Forescout Threat Feeds and into our eyeInspect and TDR solutions.

On-demand webinar: Learn how attackers use generative AI to enhance phishing campaigns and amplify cyber-attacks with our own VP of Research, Elisa Costante.

Share This: Share on LinkedinShare on TwitterShare on Facebook