How the RaaS Business Model Actually Works

When most people hear the word "disruption," they think about business growth, new markets, or a competitor making a bold move.

Ransomware crews have their own version.

Ransomware-as-a-Service, or RaaS, turns ransomware into a business model built to interrupt legitimate workflows at the worst possible moment. It gives threat actors a way to buy into proven tooling, proven workflows, and a proven extortion model without having to build the whole operation themselves. The result is more scale, more repeatability, and more attacks that hit the systems businesses rely on to keep the lights on.

With this model, ransomware leads to more than a security problem. It becomes a payroll problem. An operations problem. A weekend problem. A reputation problem.

In this post, we'll break down what RaaS is, how the model works, why it creates so many different intrusion paths, and what defenders should look for before encryption ever starts.

What is RaaS?

At a high level, RaaS is a cybercriminal service model where ransomware developers create and maintain the malware, then lease it or provide it to affiliates who use it in real attacks.

The structure feels familiar for a reason: It works a lot like a legitimate software business. The operator maintains the product. Supporting infrastructure stays online. Updates keep shipping. Affiliates get access to tooling that's already built and tested.

The difference is what the service is designed to do. RaaS exists to disrupt businesses, steal data, pressure victims, and turn downtime into stolen revenue.

That setup lowers the barrier to entry for attackers. A threat actor doesn't need to write ransomware from scratch to launch a catastrophic intrusion. They can buy into an ecosystem that already has the malware, the infrastructure, and sometimes even the negotiation playbook waiting for them.

Why RaaS is so dangerous

RaaS is dangerous because it gives attackers a model they can scale. By outsourcing all of some of their operations, threat actors specialize in certain phases of the attack chain for a higher success rate against more mission-critical systems.  

In the Huntress 2026 Cyber Threat Report: State of Ransomware, four groups—Akira, Medusa, Qilin, and Ransomhub—accounted for over half of observed ransomware incidents, which shows how effective shared playbooks have become. The attacks are getting more deliberate, too: average time-to-ransom jumped from 17 to 20 hours in 2025 as crews spent more time on stealth, staging, and data theft before encryption. 

That fallout doesn't stay technical. It spills into launches, deadlines, support queues, customer trust, and the personal lives of the people pulled into the response.

Ransomware went corporate

One of the clearest ways to understand RaaS is to stop thinking about ransomware as a one-team operation. The typical ransomware operator looks less like a lone crew and more like a criminal supply chain. 

Different players handle different parts of the business, from building the ransomware to selling access to running the intrusion. The people writing the malware don't have to be the same people stealing credentials, moving through the environment, or pressuring victims into paying. As each part of the work gets handed to someone who specializes in it, ransomware becomes easier to scale, repeat, and adapt.

Figure 1: The RaaS ecosystem

How the work gets divided

In practice, that specialization usually breaks down into a few core roles:

  • Operators build and maintain the ransomware, leak sites, payment portals, and sometimes lead the negotiation process.

  • Affiliates carry out the intrusion inside victim environments, including gaining access, moving laterally, staging data, disabling defenses, and deploying the payload.

  • Initial access brokers, or IABs, may sit even earlier in the chain by compromising environments, packaging access, and selling that foothold to someone else.

That split matters because the crew dropping ransomware isn't always the same crew that opened the door in the first place. It also helps explain why attacks tied to the same ransomware family can look very different, especially before encryption starts.

Figure 2: An example of the Qilin RaaS model

Why the same ransomware can show up in very different attacks

RaaS separates the payload from the rest of the intrusion. That's why two attacks tied to the same ransomware family can look very different before encryption hits.

One intrusion might start with phishing. Another might begin with exposed RDP. Another might come through a rogue remote monitoring and management (RMM) tool that blends in with normal admin activity. Same ransomware family, different path to impact.

The ransomware name on the ransom note only points to what hit your system at the end. It doesn't tell you how the attacker got in, what they abused along the way, or how long they were setting the stage.

That distinction is important for defenders.

If you treat ransomware like one fixed playbook, you'll miss the fact that RaaS affiliates can use different access paths, different persistence methods, and different tooling while still cashing out through the same operator.

What RaaS attacks can look like in the real world

In practice, RaaS-driven intrusions vary a lot, but the early stages tend to follow familiar patterns.

Some of the most common entry points include:

  • Phishing and social engineering

  • Exposed remote access services like RDP or VPNs

  • Help-desk scams

  • Stolen credentials

  • Rogue or abused RMM tools

  • Vulnerable edge devices

From there, attackers usually work to keep access, evade defenses, move laterally, and sometimes steal data before encrypting anything.

So much can happen before they send a ransom note. By the time encryption lands, the intrusion is already in motion.

 Figure 3: Huntress observed attackers using Bomgar RMM to gain access before launching ransomware.

A real example: from SonicWall access to Akira activity

This example of SonicWall VPN exploitation from our Security Operations Center (SOC) is a good reminder that the damage from ransomware starts long before files get encrypted.

In this incident, attackers moved from a compromised SonicWall appliance into post-exploitation activity within hours. The observed tradecraft included privilege abuse, lateral movement, persistence using Cloudflared and OpenSSH, credential theft, firewall tampering, shadow copy deletion, and eventually signs of Akira ransomware deployment.

It's the sequence defenders need to care about. The payload is the loudest moment, but it's only one moment in a longer chain of attacker activity that can be shut down much earlier.

And that chain doesn't wait for a convenient time. Once attackers have access, they can strike when your team is offline, distracted, short-staffed, or heading into a long weekend.

How defenders can interrupt the model earlier

The most useful mindset shift is simple: treat ransomware as an intrusion problem, not just a malware problem.

That means looking for the signals that show up before encryption and following these steps:

The goal isn't just to catch the payload. It's to catch the quiet setup before it turns into a full-stop business interruption.

Staying ahead of the RaaS threat

RaaS works because it treats cybercrime like a business.

It breaks the job into parts, assigns those parts to specialists, and repeats the model anywhere a foothold can be turned into leverage. That makes ransomware more scalable for attackers, but it also creates patterns defenders can learn from.

Repeatable tradecraft leaves repeatable signals. Suspicious access, credential misuse, remote tool abuse, staging activity, and data theft often show up before the ransom note does.

The earlier those signals are caught, the harder it becomes for attackers to turn quiet access into downtime, pressure, and a long recovery cycle.

That's the core lesson from RaaS. It's a criminal business model built to interrupt real work and real lives. Defenders have a better shot when they focus on everything that happens before the detonation point.