Huntress reported it yesterday: 6 MSPs breached, 286 endpoints hit, 47 downstream orgs.
The entry point wasn’t the ScreenConnect server. It was a customer endpoint — already authenticated to the MSP’s relay.
How it works:
Attacker gets SYSTEM on a customer endpoint
Reads the ScreenConnect agent’s local state: relay URL, deployment creds, session tokens, connection policies
Authenticates to the relay as that customer’s agent
Enumerates other sessions, potentially impersonates a technician, reaches every other customer
Why it’s invisible: The traffic looks like a legitimate session. The connection exists. The anomaly is the direction of the command — customer → MSP — which almost no monitoring stack flags.
No CVE. No patch. ScreenConnect is working as designed. The weakness is the threat model.
What to do:
MFA on every technician account — no interactive exceptions for automation accounts
Rotate relay certs and deployment keys after any customer compromise, not just the endpoint
Segment the relay so customer endpoints can’t reach the management API
Alert on technician sessions originating from customer IP ranges
Treat every customer compromise as an MSP-side event
The step everyone skips: the customer reimages the box and closes the ticket. The attacker already has the cert. The reimage doesn’t invalidate it. Only the MSP-side rotation does.
Full analysis + IOCs: threataft.com/articles/screenconnect-msp-reverse-pivot-customer-attacker
Top comments (0)