An MSP removed an unauthorized ScreenConnect agent from a Windows computer. Hours later, ScreenConnect came back and connected to the same attacker-controlled relay. Huntress traced the second installation to an unauthorized Hexnode mobile device management (MDM) client left on the machine. The attacker still had a privileged Hexnode management route to install software on that endpoint after the MSP removed ScreenConnect.
Huntress describes another intrusion in which a receptionist followed a fake Teams meeting link and an attacker-controlled Rippling MDM tenant enrolled the device. The agent installed with SYSTEM privileges and later delivered ScreenConnect as SYSTEM. Both cases concern abuse of legitimate management software after social engineering, rather than a product vulnerability in Hexnode or Rippling. Any team managing Windows endpoints, especially an MSP responding to rogue remote-access tools, needs to identify the enrollment behind the installation.
ScreenConnect returned through Hexnode
In the first case, proposal-themed phishing emails, including subjects such as “ATTN: Official Invitation to Submit Proposal” and “Review Required,” sent the target to a fake DocuSign installer. The downloaded eD0cuSign_Installer.msi installed Hexnode Gateway, the Hexnode agent and supporting PostgreSQL components. The attacker then installed ScreenConnect, which called relay[.]bobdthjau[.]com:8041. The MSP removed that unauthorized RMM instance after a Huntress alert.
Several hours later, a second ScreenConnect installation on the same computer reached the same relay. Huntress alerted again, isolated the endpoint and investigated the remaining Hexnode management client. Removing the visible remote-control tool left the Hexnode software-deployment channel in place. Huntress puts it plainly: “Removing the RMM did little to deter them. They simply staged and installed the RMM software again.”
MDM usually carries enough authority to deploy approved software to a managed workstation. Here, enrollment gave the attacker a way to replace the tool the defender had just deleted. Pair the installation event with its management origin and the new relay connection.
Rippling enrollment followed a meeting lure
The other case began with an email titled “Re: Tax Planning and Preparation Inquiry.” A receptionist clicked what appeared to be a Teams invitation on teams-microsoftcom5d41402abc4b2a76b9719d911017c592[.]kiratham[.]com.
Huntress says a redirect apparently facilitated enrollment into an attacker-controlled Rippling MDM tenant. A Rippling enrollment registry key appeared about a minute after the click. An agent installer then downloaded under C:\Windows\System32\config\systemprofile\AppData\Local\mdm\{GUID}.msi, and C:\Rippling\daemon.exe installed with SYSTEM privileges.
About 35 minutes after the agent installation, the attackers used MDM to stage and run a ScreenConnect installer as SYSTEM. That client contacted relay[.]pronconetydesire[.]online:8041 and triggered a Huntress alert. Huntress traced this activity to the online Rippling agent, suggesting the attacker had created an account before the incident. The Hexnode case involved a user running a disguised MSI; the Rippling case involved web-led enrollment followed by agent installation. The common risk is attacker-controlled enrollment and subsequent software deployment.
Trace enrollment before removing access
A ScreenConnect alert warrants a look upstream. On an affected Windows endpoint, line up the email or browser event, the new MDM enrollment or agent installation, the ScreenConnect installation and the outbound relay connection. Search for eD0cuSign_Installer.msi, Hexnode Gateway and agent components in the first case; in the second, look for the Rippling enrollment registry key, the installer under C:\Windows\System32\config\systemprofile\AppData\Local\mdm\{GUID}.msi and C:\Rippling\daemon.exe. Use the two observed :8041 relays as case-specific pivots and extend the search to unfamiliar relays. Correlate endpoint, MDM tenant, identity and network records to see who enrolled the device and which management tenant issued the installation.
Inventory the MDM products, tenants, agents and RMM instances you authorize, as Huntress recommends. Use that inventory to investigate a new or unfamiliar enrollment and software deployment. The management agent may be signed and legitimate even when the person directing it is an attacker; a reputation-based software allowlist alone will miss that change in authority. Restrict who may enroll devices and which applications a management tenant may deploy. Use an organization-approved enrollment process.
Remove the unauthorized management path
For a suspected compromise, isolate the endpoint and remove its enrollment from the unauthorized MDM tenant, then disable attacker-created accounts, revoke active sessions or tokens and reset affected credentials. Huntress advises reimaging if endpoint integrity cannot be confirmed. Remove the rogue ScreenConnect instance as part of that response, while checking the management client and tenant that deployed it.
After containment, compare the endpoint with the authorized MDM inventory. On the Rippling-affected device, verify that C:\Rippling\daemon.exe is gone; on the Hexnode-affected device, confirm the unauthorized management client is gone. Review enrollment and software-deployment events: the expected result is no new ScreenConnect installation or connection to the observed relay after the tenant enrollment is removed.