Hexnode and Rippling MDM abused in ScreenConnect intrusions

Huntress reports that attackers are using phishing lures to get legitimate mobile device management (MDM) clients from Hexnode and Rippling onto Windows endpoints, followed by ScreenConnect. No product flaw is involved, so the control to review is who and what can enroll a device.

What happened

In an October 28 post, Huntress says it has seen several recent incidents of this kind and details two. It gives no incident count, dates or attribution. It clears both vendors: the trick lay in persuading people to install genuine software.

• Hexnode: proposal-themed emails carried a link that fetched eD0cuSign_Installer.msi, a name meant to pass for DocuSign. Inside were Hexnode's agent and Gateway, plus PostgreSQL components. ScreenConnect arrived soon afterward, talking to relay.bobdthjau[.]com:8041. The victim's MSP uninstalled it. Several hours later a second copy was on the machine and back on the relay. Huntress answered that alert by isolating the machine and starting remediation.
• Rippling: the target was a receptionist, sent an email titled "Re: Tax Planning and Preparation Inquiry." Its link was dressed up as a Teams meeting and opened a page titled "Calendar," probably meant to pass for Teams, which redirected to a PHP file. Huntress's read is that the file appears to have played a part in enrolling the machine in an attacker-controlled Rippling tenant. Roughly a minute after the receptionist clicked, an enrollment registry key was present. The agent was installed at C:\Rippling\daemon.exe with SYSTEM permissions. ScreenConnect came about 35 minutes after installation, staged and launched through the MDM as SYSTEM, and connected to relay.pronconetydesire[.]online:8041.

Huntress traced the Rippling activity to the online management agent and reads that as a sign the attacker held an account beforehand. As for Hexnode, the post leaves open who controlled the tenant, whether the client came off during cleanup, and how ScreenConnect returned.

Why it matters

Enrolling a device is a trust decision. It gives an outside tenant privileged control of the endpoint, which in the Rippling case meant running software as SYSTEM. Huntress notes that an attacker holding this access has no need for recognizable malware to add further tools. The agents are legitimate, so a hash or reputation check may not help; what matters is whose tenant they serve.

In the Hexnode case, the MSP removed the RMM tool, yet ScreenConnect returned within hours. Huntress points to the earlier Hexnode install but does not spell out the mechanism. Our inference: the MDM client may have been the way back, so removing only the visible tool may not close the access.

Huntress puts it plainly:

MDM enrollment should be treated as security-sensitive activity as opposed to a routine administrative task. — Huntress

Huntress does not describe credential theft in these cases. Its response steps still cover accounts, sessions and credentials; we read those as scoping work, not evidence that identities were taken.

What to check in your environment

• Build the allow list. List every approved MDM product, tenant and agent, plus your RMM instances, and give each an owner. Huntress wants anything off that list handled as a security event.
• Look for agents you don't run. Search endpoints for Hexnode components and C:\Rippling\daemon.exe. If you do use either product, confirm each device reports to your own tenant, since the agent's presence alone proves little.
• Review the enrollment path. Huntress says to control both the route into management and what the MDM platform can push. It names no specific settings, so test whether a standard user on your builds can install an MSI or complete link-based enrollment into an outside tenant.
• Alert on the sequence. Huntress finds the combination more telling than any one step: a lure, enrollment, an RMM tool appearing, then contact with a relay you don't recognize. Bring identity, MDM, endpoint and network data together; the pattern can differ between intrusions.
• Hunt the published indicators. Check proxy and DNS logs for the two relay hosts above, webdocusign.viewportal[.]es and kiratham[.]com subdomains. Huntress's list has full URLs but no hashes or IP addresses.
• Update the RMM alert runbook. We suggest internal teams and any MSP check for management agents before closing an unauthorized RMM alert. Huntress's response list starts with isolation and taking the machine out of the unauthorized tenant. Attacker-created accounts get disabled, sessions or tokens revoked and affected credentials reset. Reimage if you can't confirm integrity.
• Brief the likely targets. Ask staff, including front-desk roles, to confirm meeting invitations, document-signing prompts and proposal reviews they weren't expecting. Tune email and web filtering to catch these same themes, too.

References

• Huntress: Managed for Malice: How Attackers Turn MDM into Remote Access