2024 Ransomware Report

The Handoff from IABs to Ransomware Affiliates

Despite what some would have you believe, being victimized by a ransomware attack is not an inevitability.

In This Section

2 Groups, Same Attack

Mapping IABs and Ransomware Actors to MITRE ATT&CK

Monitoring Credentials and Access for Sale

Prevention Is Better Than Cure

If an organization can keep their systems fully patched, limit the ability of ransomware groups to conduct credential stuffing/reuse attacks, and prevent a phishing email from getting to an employee, the ransomware attack is over before it started.


The phases of the attack outlined throughout this website—reconnaissance, exfiltration, and ransomware deployment—are progressively more difficult to detect and stop in a timely fashion. That doesn’t mean that it’s impossible to stop such attacks—organizations do it all the time—but it is harder and often involves significant investment in tools, training, and personnel to succeed. These investments, as many security teams and CISOs know all too well, can be hard to come by until after a ransomware attack occurs.


On another page the importance of Initial Access Brokers (IABs) to the ransomware market is discussed. Other pages focus on how IABs conduct their scanning and gain access to exposed or vulnerable systems. This page focuses on the handoff between the IAB and the ransomware group.

2 Groups, Same Attack

2 Groups

People tend to assume that the cybercriminals who gain initial access are the same group carrying out the attack. That's not normally the case with ransomware attacks. There are some exceptions to this, but for the most part it's safe to assume that a ransomware incident involves at least two different threat actors.

2 Toolsets

Why does that make a difference? Two different actors means two different toolsets, so finding and removing one toolset doesn’t remove the second toolset. An organization may successfully stop a ransomware attack, but if the intrusion response team misses the IAB toolset, the same ransomware actor or a different one will likely be back in a couple of weeks to launch a new attack.

How Does the Handoff Work?

After an IAB successfully gains …
… initial access to a system, they install a web shell that can be used to run commands, upload tools, and gain remote access to that system. That web shell gives the IAB enough access to the compromised system to begin moving around the network and do some basic reconnaissance. The IAB investigates the compromised system and the organization it’s part of to determine things like:
  • Which organization they’ve accessed
  • Organizational revenue, via Google search
  • What level of access the IAB has (administrative access is always worth more)
  • Where the organization is located (ransomware groups won’t buy access to organizations in Russia or one of the Commonwealth of Independent State countries)
Once the IAB has all the relevant info …
… they may put the network up for sale (or, if they’re working exclusively for one ransomware group, hand over the network). They may also try to expand access by installing implants on another machine, depending on how tenuous the initial access is.
One thing IABs generally don’t do is spend a lot of time in the victim’s network. Initial access is a volume business, and they want to get the networks up for sale or turned over to the ransomware gang as quickly as possible.
PAY ATTENTION

Drastic or Necessary?

The FBI removing web shells may seem like a drastic step, but it was necessary. Many organizations don’t remove web shells dropped by attackers during initial access because they miss them. Web shells do more than help a ransomware actor or IAB gain a foothold into an organization—they also serve as a failsafe for the ransomware actors if the attack fails, allowing them to regain access.

Web Shells

Web shells are small bits of code that …
… attackers implant after successful exploitation for command-and-control purposes. Web shells are available in a number of programming languages, including PHP, JSP, ASP, Python, PowerShell, and many others. Collections of web shells exist in multiple repositories around the Internet.
The growth of web shell use is a “canary in the coalmine” indicator of surging ransomware attacks. For instance, in 2021 Microsoft reported a big spike in the number of web shells installed between August 2020 and January 2021.
Web shells are so concerning that in …
… April 2021, the FBI announced that it had scanned United States IP space for Microsoft Exchange Servers that were previously compromised by a state actor, and removed any web shells that had been left behind. This highly unusual action showed how serious the threat’s becoming.
Part of the reason web shells are so dangerous is that they’re surprisingly simple to operate, and they don’t set off alerts within most security tools since they’re the type of file expected to reside on the server.
The control panel of wwwolf’s PHP web shell
The image above shows the web interface …
… an attacker uses to control a typical PHP-based web shell, called wwwolf’s PHP web shell. The shell is a good example of the simplicity of these tools. The web shell is installed on a web server either through exploitation or by taking advantage of a server misconfiguration. Once the script has been uploaded, all the attacker has to do is visit the URL (e.g., example.com/subdirectory/webshell.php), after which they can issue server commands or upload files right from the web browser.
The attacker’s commands blend in with the rest of the web traffic, making the activity hard to detect. This web shell also benefits from simplicity; a console needs to be installed locally, after which everything is self-contained in a PHP script of fewer than 300 lines.
Although some web shells are more complex, most are designed to be light and carry out a few specific commands. Web shells aren’t used just in remote exploitation ransomware attacks—JavaScript- and PowerShell-based web shells are commonly used as part of phishing attacks. These are generally designed to run in memory, perform a few basic functions, then call back to a command-and-control server.
The image below shows an example of a PowerShell web shell in its entirety. It’s very basic, in that the web shell when run executes a command shell to call back to the command-and-control host, in this case study[.]roots[.]ru (which has been disabled). This will give the ransomware actor the ability to execute whatever command they want with the same user privileges as the account used to execute the shell.
A PowerShell-based simple web shell that calls back to a command-and-control host
This may limit the ability of the attacker to execute certain commands, unless the application is running as administrator or root. Once again, this web shell is designed to blend into the system, using commands and traffic that look normal to avoid detection—PowerShell isn’t inherently malicious. A lot of system administrators use PowerShell, and this script likely executed in memory, meaning it’s even less likely to be detected.

Get More Ransomware Tools Directly In Your Inbox

Sign Up To Receive Our Monthly Ransomware Newsletter
Don’t worry, we hate spam too

Detecting Web Shells

There are thousands of web shells available for download by ransomware groups. One GitHub repository alone has dozens. Overall, GitHub has more than 2,600 web shell repositories. A search on the MalwareBazaar database (a public platform sponsored at the abuse.ch research project from the Institute for Cybersecurity and Engineering ICE at the Bern University of Applied Sciences [BFH] in Switzerland) shows hundreds of different web shell samples used in attacks, as shown in the image below .
A partial list of web shells available in the Malware Bazaar repository
The diversity in type and complexity of web shells can make detecting their presence a challenge.
There’s no “one rule” that will allow an organization to detect all web shells and no one place to look for these web shells. Web shells can be found on any system that serves up web data, mail servers, and database servers. The web shells can also, of course, be placed on compromised systems inside the network.
Therefore, a web shell detection strategy has to be diverse and comprehensive, a task often difficult to implement. This is a reason web shells often go undetected after exploitation, even after cleanup. It’s also why it’s often better to completely wipe a compromised system and rebuild it from scratch (or, even better, replace it with new hardware) than to try to restore the system to its previous functioning.
Although difficult, it is possible to detect web shells. Detection requires a baseline understanding of expected traffic and files on the target system. One common way to detect web shells is to look for odd traffic in web server logs.
Web shells often reside in strange locations …
… on the web server or another server, and will usually not match the naming convention of the server’s other files. If the rest of the web logs have expected file names such as contact.html, about.html, and product.html, but also includes djrtyry.php, that should raise suspicion.
To determine the legitimacy of a web log, compare the list of files on the server to a known good image. And don’t just compare file names, but directory paths, as well. If contact.php is supposed to be in the root directory but is instead being accessed three subdirectories lower than expected, that should set off alarm bells in your head.
Another way to detect the presence of a web shell is to look at file timestamps. If every legitimate file in a directory is timestamped with the server installation date, but one file has a timestamp of three weeks ago, it’s likely a web shell. At the very least it’s suspicious. (Note that it is possible for ransomware groups or IABs to adjust the timestamp of the web shell to match the other files in the directory, but that’s extremely rare.)
Advanced endpoint detection solutions, which are called endpoint detection and response (EDR/XDR), can also detect the presence of web shells based on signature detection and the types of system calls they make. While many organizations are hesitant to run EDR on busy web servers, using an EDR to look for web shells on other types of servers or endpoints can be very effective.
And to re-emphasize—you should prioritize patching external-facing systems. The best way to stop a web shell is keep it from being installed. Ransomware groups are exploiting new vulnerabilities with increasing speed, and organizations must be faster than the attackers.
PAY ATTENTION

Restoring External-Facing Servers

One challenge in restoring a server used as the initial ransomware attack vector is the IAB. If an IAB gains access by exploiting a vulnerability on an external-facing server, they may hold that access for a few hours, days, or even weeks before selling it. When the ransomware actor takes over, they’ll use their tools to conduct reconnaissance and deploy the ransomware.

During the incident response (IR) process, if the team restores the server back to before the ransomware actor accessed the network, they run the risk of restoring it with the web shell intact, likely resulting in a second infection.

MITRE ATT&CK®

The MITRE Adversarial Tactics, Techniques & Common Knowledge (ATT&CK) is a framework that defenders can use to map cyberattacks. ATT&CK consists of tactics and techniques used by real-world cybercriminals during actual attacks. ATT&CK is a useful benchmark for understanding the different components of a cyberattack and discovering process holes that require mitigation.
The ATT&CK framework consists of 14 tactics:
  • Reconnaissance
  • Resource Development
  • Initial Access
  • Execution
  • Persistence
  • Privilege Escalation
  • Defense Evasion
  • Credential Access
  • Discovery
  • Lateral Movement
  • Collection
  • Command and Control
  • Exfiltration
  • Impact
Each tactic is associated with a series of techniques.
Some of these techniques also have sub-techniques. These combine to build out a matrix that maps an attack, creating a Rosetta Stone of sorts that allows different organizations to communicate information about an attack in a format that other organizations can easily understand.

For example, when explaining initial access vectors for ransomware attacks, a matrix for ransomware would look something like the table below.

Initial Access (TA001)

Technique

Valid Accounts
Phishing: Spearphishing Attachment
Exploit Public-Facing Application

ID

T1078
T1566.001
T1190

Description

IABs use credential-stuffing attacks to gain access to Internet-facing RDP servers.
IABs often gain initial access with phishing campaigns that contain Microsoft Office attachments.
IABs exploit public-facing systems such as Pulse Secure VPN and Citrix.
Mapping initial attack vectors for ransomware using the MITRE ATT&CK framework
The ATT&CK framework is typically used to map the events of a single attack.
Using a framework such as ATT&CK allows organizations not only to share information with other organizations, but also to characterize a cyberattack internally and ensure the organization is effectively monitoring every part of the attack chain.
ATT&CK also provides suggested mitigations for the attack techniques. These mitigations can be added to the matrix to demonstrate how the attack was stopped, or could be stopped in the future. The table below shows the same attack tactics and techniques mapped to appropriate mitigations.

Initial Access (TA001)

Technique

Valid Accounts
Phishing: Spearphishing Attachment
Exploit Public-Facing Application

ID

T1078
T1566.001
T1190

Description

IABs use credential-stuffing attacks to gain access to Internet-facing RDP servers.
IABs often gain initial access with phishing campaigns that contain Microsoft Office attachments.
IABs exploit public-facing systems such as Pulse Secure VPN and Citrix.

Mitigation

Privileged Account Management
User Training
Update Software

ID

M1026
M1017
M1051
Mapping initial attack vectors for ransomware using the MITRE ATT&CK framework with mitigations
There are often multiple mitigations for different attack techniques. For the Valid Accounts technique, in addition to the Privileged Account Management mitigation, organizations can opt to mitigate with:
  • Application Developer Guidance (M1013)
  • Password Policies (M1027)
Organizations can also use some combo of the three mitigations.
The advantage of ATT&CK, aside from being based on real-world cyberattacks, is that it provides a comprehensive framework for documenting ransomware and other types of attacks and the steps needed to mitigate the attacks.

Mapping IABs and Ransomware Actors to MITRE ATT&CK

When a ransomware attack is spearheaded by an IAB exploit, ATT&CK provides a good framework for showing how IABs and ransomware groups divide up the different parts of a ransomware attack. This is particularly important when recovering from a ransomware attack, as it helps IR teams ensure that they’ve investigated the correct systems for artifacts from both the IAB and the ransomware actor. The chart below lays out which threat actor is generally involved in which tactic.

Tactic

Reconnaissance
Resource Development
Initial Access
Execution
Persistence
Privilege Escalation
Defense Evasion
Credential Access
Discovery
Lateral Movement
Collection
Command and Control
Exfiltration
Impact

IAB

Ransomware

Using the ATT&CK framework to distinguish between IAB and ransomware activity
Why does any of this matter?
What difference does it make which part of a ransomware attack was carried out by one group versus another group? Generally, IABs and ransomware groups use different toolsets (not always, but for most ransomware attacks).
For example, referring back to the previous discussion, the IAB may leave behind one web shell and the ransomware group may leave a web shell of their own. By mapping out the different tactics and techniques used in the attack, IR teams who find one web shell on a server where the IAB didn’t have access know to keep looking for a second web shell if this fits with the TTPs associated with the threat actor.
Mapping a full ransomware attack …
… using the ATT&CK framework allows IR and security teams to better identify the different threat actors involved in the attack.

There was a strange ransomware case in September 2021 where a ransomware victim had all of their encrypted files deleted while they were negotiating with the ransomware group. Using the ATT&CK framework, IR teams could have determined whether it was the original ransomware actor that deleted the files or another Conti affiliate who felt ripped off (an increasingly common occurrence).
The ATT&CK framework is a powerful tool for determining where in the attack chain each step falls, and what mitigations are needed to prevent the ransomware actor from being successful.

Get Your Copy of Ransomware:
Understand. Prevent. Recover

It’s the ransomware resource you can’t afford to be without. 437 Pages of ransomware know-how. Stay ahead of the cybercriminals: get your copy now!

Buy on Amazon
Get it for free
Ransomware-2E_Book-cover-mockup-left

Download The Free 313 Page Book: Ransomware Understand. Prevent. Recover

Download The “How To Prevent Ransomware” Cheat Sheet

Grab this free PDF resource on how to prevent Ransomware
Download the pdf

Share This Resource With Others

Embed The “How To Prevent Ransomware” resource on your site or blog using this code.

Want More?

This site is adapted from a book on Ransomware. If you would like to learn more keep reading ...
READ MORE ABOUT THREAT HUNTING FOR RANSOMWARE

Need Help?

Get help now

Ransomware

Partners

Deep Dive
Share via
Facebook
Twitter
LinkedIn
Mix
Email
Print
Copy Link
Powered by Social Snap
Copy link
CopyCopied
Powered by Social Snap