1-minute read of a 4 min report

Attackers Abuse Hexnode and Rippling MDM to Install ScreenConnect

By

1-minute read

What a defender needs to know

An MSP removed an unauthorized ScreenConnect agent from a Windows endpoint, then saw it return hours later on the same attacker relay. Huntress traced the repeat installation to a Hexnode MDM client the attacker had previously installed through a fake DocuSign MSI, eD0cuSign_Installer.msi. The first agent connected to relay[.]bobdthjau[.]com:8041; the second instance reached that same relay. Deleting the RMM left the attacker-controlled management channel intact.

In another Huntress case, a fake Teams meeting invitation led a receptionist to an attacker-controlled Rippling MDM enrollment. A registry key appeared about a minute after the click, C:\Rippling\daemon.exe installed with SYSTEM privileges, and MDM deployed ScreenConnect as SYSTEM roughly 35 minutes later. That RMM used relay[.]pronconetydesire[.]online:8041. Both products are legitimate; the attacker abused enrollment and software-deployment authority.

Compare new enrollments and management agents with your authorized MDM product and tenant inventory. For a ScreenConnect alert, line up the lure, enrollment, agent installation, RMM installation and outbound relay in endpoint, tenant, identity and network records. Isolate a compromised endpoint, remove its unauthorized MDM enrollment, disable attacker accounts, revoke sessions or tokens and reset affected credentials; reimage when integrity is uncertain. On the Rippling-affected device, verify that C:\Rippling\daemon.exe and the unauthorized enrollment are gone; the expected result is no new ScreenConnect installation or connection to relay[.]pronconetydesire[.]online:8041 after removal.

Primary sources