The Attacker’s View on Penetration Testing, RMM and Social Engineering (Interview)

Simple math. You compromise one MSP and you do not get one victim—you get dozens, sometimes hundreds. An MSP isn’t just a target. MSPs are the master key to an entire neighborhood. And most of them don’t know who else has a copy. From an attacker’s perspective, the return on investment is extraordinary. You invest effort once and collect from many. That is not a bug in the criminal business model. That is the feature.

All four matter, but trust is the silent killer. MSPs are granted deep, persistent, privileged access to their clients’ environments. Often, that means credentials that never rotate, accounts that never expire, and remote management tools that live permanently on the client’s network. Clients extend that trust because they have to. The relationship demands it.

But the other three factors feed the problem. Business pressure keeps MSPs lean. Margins are thin, technical teams are stretched, and security investment competes directly with profitability. Technology choices often get made for operational convenience, not security posture. Operational habits then calcify over time. The admin account created years ago, with a password nobody changed, may still be authenticating production systems today.

The honest answer is that MSPs were built to solve an IT problem, not a security problem. Many are still operating from that original design intent.

Operation Endgame exposed something the intelligence community has known for a long time: the criminal ecosystem is modular. There are specialists in initial access, specialists in credential harvesting, specialists in malware delivery, and specialists in monetization. They do not need to be brilliant across all of it. They just need one good entry point.

MSPs are that entry point.

What Operation Endgame showed is that botnets and malware-as-a-service operations were not simply attacking end targets directly. They were building access pipelines. MSPs represent one of the highest-value nodes in those pipelines.

The lesson is this: your environment is not only your target. You are the on-ramp. Attackers do not need to own you forever. They just need you long enough to pivot. That changes how MSPs should think about detection. You are not only looking for someone stealing your data. You are looking for someone moving through you.

Every MSP should be asking: if someone had silent access to my RMM platform right now, what could they see? What could they touch? How long would it take before I knew?

Most cannot answer that confidently. That is the problem.

The most dangerous compromise is the quiet one. Here’s what I’d look for:

Unexplained authentication events during off-hours. Credential use from geographies that don’t match your workforce. RMM agents executing scripts that nobody on the team remembers deploying. Service accounts authenticating to systems they have no legitimate reason to touch. Outbound traffic from management infrastructure to destinations that aren’t on any approved list.

But the deeper warning sign is structural: if your MSP can’t answer basic questions about its own environment—who has admin rights, what systems are reachable from your management plane, what’s running on your jump hosts—then you’re not compromised yet only because nobody has tried hard enough.

The MSPs that become gateways without realizing it share a common trait: they monitor their clients’ environments more carefully than their own. The cobbler’s children have no shoes.

Automated tools find known patterns. A skilled adversary finds unknown paths. A vulnerability scanner can tell you about unpatched software and misconfigured services. What it cannot tell you is that a helpdesk technician might reset an MFA enrollment over the phone after minimal social engineering. It will not tell you that your VPN solution, while technically current, is configured in a way that lets an authenticated user reach every client VLAN without restriction. It will not chain together a credential harvested from a phishing simulation, a forgotten test account, a misconfigured trust relationship, and a client with no endpoint detection—and arrive at “domain administrator” in under four hours. 

That is what a real adversarial test does. It proves the actual blast radius of a compromise, not the theoretical one. The other thing automated tools cannot simulate is decision-making under ambiguity. A real attacker adapts. They read the environment. They find the path of least resistance. That is a human skill, and it is what separates a penetration test from a compliance scan.

Technically, you want someone who has operated at the depth you’re worried about. Not just someone who runs frameworks—someone who has built their own tools, who understands the underlying protocols, who can operate without detection. Ask them to walk you through a previous engagement: how they got in, what they found, what they missed, what surprised them. Competence reveals itself in specificity.

Legally and ethically, this matters more than people acknowledge. The engagement scope must be explicit in writing. Rules of engagement need to cover data handling—what happens to credentials discovered during testing, what happens to client data the tester encounters while moving through your MSP infrastructure. If your tester touches client environments as part of the assessment, those clients may have contractual and regulatory rights you need to account for. An ethical hacker who doesn’t raise these questions themselves is a liability.

Commercially, be suspicious of both extremes. Rock-bottom pricing usually means automated tools dressed up as manual testing. But expensive doesn’t guarantee depth, either. Ask for a methodology. Ask what documentation you’ll receive. Ask whether findings will be validated to reduce false positives. And ask for references—not testimonials, but actual conversations with people who’ve worked with them.

The most important question you can ask a potential tester is this: Tell me about an engagement where you found nothing significant. How they answer that tells you whether they’re honest.

Start with visibility. You cannot defend what you cannot see. That means knowing—with certainty, not assumption—every privileged account in your management environment, every system reachable from your RMM platform, and every outbound connection your infrastructure makes. That inventory alone will surface problems.

Then attack yourself before someone else does. Commission an adversarial assessment scoped specifically to your MSP infrastructure and the trust relationships you have with clients. Not a generic pentest. The real question is: can a compromise of our environment lead to a compromise of our clients? The answer is almost always yes. The question is how fast and how completely.

Build an incident response plan that accounts for the MSP-specific scenario: simultaneous compromise across multiple clients. Most MSP IR plans aren’t written for that. They’re written for a single-environment breach. A coordinated MSP compromise is a different operational problem and requires a different response posture.

And have the honest conversation with your clients. They deserve to know what access you hold, how you protect it, and what your response plan looks like if something goes wrong. The MSPs who are going to survive the next five years are the ones who treat security as a value proposition, not a liability to manage.

I wouldn’t kick the front door. I’d call the help desk.

Social engineering remains the highest-yield, lowest-risk entry point in the industry. A well-constructed pretext targeting a junior technician can yield credential resets, MFA bypasses, or direct remote access in a single call. MSPs train their people to be helpful—that’s a cultural asset that attackers treat as a vulnerability.

From there, the RMM platform is the prize. Once I’m in the management layer, I’m not attacking one company. I’m attacking everyone they manage, simultaneously, from infrastructure those clients already trust.

That’s the view from my side of the table. The good news is that none of this is inevitable. The gaps are knowable, the fixes are achievable, and the MSPs that take this seriously today are the ones that won’t be in your next story about a breach.