Here’s the uncomfortable truth: if you haven’t implemented IP restrictions on your RMM tools yet, you’re one stolen session cookie away from a company-ending disaster.

We’re not talking about some theoretical attack here. We’re talking about something so simple that any technician can demonstrate it in under 30 seconds using nothing but their web browser.

How Ridiculously Easy Session Cookie Theft Really Is

Let’s cut through the technical jargon and show you exactly how vulnerable you are right now.

Fire up your RMM tool. Log in normally. Hit F12 to open developer tools. Click the “Application” tab, then navigate to Storage > Cookies, and look for your server name.

See that authentication token? That 36-character alphanumeric string with dashes? That’s your golden ticket. Anyone with that string can interact with the GraphQL API that your web frontend uses. They can do anything a logged-in user can do, with all the permissions of whoever’s session they stole.

We actually use this technique legitimately for automating tasks in our RMM that aren’t available through the standard API. It works. It’s reliable. And if we can do it for legitimate purposes, bad actors certainly can too.

How Attackers Get Your Cookies (And It’s Easier Than You Think)

An attacker doesn’t need to be some elite hacker to steal your session cookies. Here are the most common methods:

Network Sniffing: If they’ve found their way into your network or positioned themselves between your technician’s workstation and the internet.

Malicious Browser Extensions: These can easily steal session information without most users ever knowing. That “productivity tool” your technician installed last week? It might be harvesting more than just bookmarks.

Endpoint Malware: A virus on the endpoint can collect this information. Since it’s just grabbing a small piece of data, it might not even trigger antivirus definitions. The exfiltration can be incredibly subtle – imagine a DNS request where the stolen token is sent as “your-stolen-token-here.malicious-domain.com” out port 53. Your firewall won’t block it, and you’ll never notice unless you’re specifically looking for it in your DNS logs.

The Nightmare Scenario

Once an attacker has that token, they can load malicious components into your RMM or alter existing ones to deliver ransomware. Picture this: all of your clients’ endpoints get encrypted simultaneously, and your RMM tool was the delivery mechanism.

That’s not just a bad day. That’s the end of your company.

We’ve seen instances where RMM tools were compromised before. The goal here isn’t to debate whether it’ll happen again – it’s to make sure it doesn’t happen to you.

IP Restrictions: Your Only Real Defense

Here’s what makes this attack particularly dangerous: even if you have multi-factor authentication enabled, it won’t help. Once someone has your session cookie, they’re already “authenticated” as far as the system is concerned.

IP restrictions are the only effective defense against session hijacking. Even if your session gets stolen, if the attacker’s IP address doesn’t match your approved list, they can’t use those stolen credentials.

“But Managing Static IPs Is Too Complicated”

This is where most MSPs get stuck. They understand the risk but haven’t implemented IP restrictions because they’re worried about the infrastructure overhead.

The solution is simpler than you think: SASE (Secure Access Service Edge) platforms. Your technicians’ computers will always come from the same IP addresses, regardless of where they’re working.

There are plenty of options – Control1, Perimeter 81 (now called Harmony), and others. We personally use Citricoms Control1 with Harmony as a backup. We’ve heard of Control1 going down once, but we’ve never been affected personally.

The key is having that backup option. If your primary SASE solution ever has issues, you still have your backup IP address to maintain access.

Critical Implementation Notes

Test After Implementation: Once you’ve enabled IP restrictions, test that they’re actually working. Try accessing your RMM from an unauthorized IP to confirm you’re properly blocked.

Documentation Platforms Need This Too: Your RMM isn’t the only target. Your documentation platform has all your IP addresses and passwords in one place. IP restrictions are just as critical there.

API Behavior Varies: This is important – some tools treat APIs differently. Datto RMM’s IP restrictions don’t apply to their standard API usage, but tools like IT Glue apply IP restrictions to everything, including APIs. If you have integrations like LionGard updating information in IT Glue, you’ll need to specifically allow those IP addresses or you’ll break the integration.

The Bottom Line

We’re not here to debate whether you should implement IP restrictions. You should. If you haven’t done it already, do it immediately. If not sooner.

Yes, it’s a small inconvenience during setup. But if you have a good SASE solution or static IP addresses at your office, you won’t feel any impact day-to-day.

The alternative – having your RMM compromised and potentially losing every client you have – isn’t really an alternative at all.

Your MSP should have someone on staff smart enough to figure out the implementation details. What you need to understand is that this isn’t optional anymore. The attack vectors are too simple, the potential damage too severe, and the protection too straightforward to ignore.

Stop making excuses. Implement IP restrictions on your RMM tools now.