Fake DocuSign and Teams Invites Hand Your PC to the Attacker’s MDM

Attackers are tricking staff into enrolling their PCs in device-management services the attackers control, then using that management channel to install remote-control software, Huntress says in new research. In two recent cases the lure was a fake DocuSign installer and a fake Microsoft Teams invite, the management tools were Hexnode and Rippling, and the payload was ScreenConnect. Neither product was hacked; both were used exactly as designed.

hxxps://webdocusign.viewportal[.]es/Windows/download/index.php
teams-microsoftcom5d41402abc4b2a76b9719d911017c592.kiratham[.]com
relay.bobdthjau[.]com:8041
relay.pronconetydesire[.]online:8041

Source article: Managed for Malice: How Attackers Turn MDM into Remote Access
Publisher: Huntress, author Ben Nahorney
Published: October 28, 2026
URL: https://www.huntress.com/blog/attackers-turn-mdm-into-remote-access

Executive Summary

Huntress describes an unattributed actor, not named or aliased by any vendor, that abuses legitimate mobile device management (MDM) platforms, specifically Hexnode and Rippling, as a privileged delivery channel for unauthorized remote monitoring and management (RMM) software, in each observed case ConnectWise ScreenConnect. Huntress says its list of abused MDMs is not exhaustive and gives no incident count or time range. The chain begins with business-themed email or messaging lures (proposal reviews, tax-preparation inquiries, meeting invitations) that lead the user either to download an MSI disguised as a DocuSign installer, which actually installs Hexnode MDM components, or to a lookalike Microsoft Teams “Calendar” page that enrolls the device into an attacker-controlled Rippling tenant. Once enrolled, the actor uses the MDM’s SYSTEM-level software deployment to install ScreenConnect, which connects to an attacker relay on TCP 8041; in the Hexnode case the actor reinstalled ScreenConnect through the MDM hours after the provider removed it. The objective is durable, legitimate-looking hands-on remote access; Huntress does not describe the follow-on actions. Hunt leads, false positive expectations and indicators are detailed below; the source publishes no hashes or detection rules.

ATT&CK chain: Initial Access → Execution → Persistence → Command and Control

Hunt Lead Grid

Lure and ScreenConnect Relay Infrastructure Sweep

In the Hexnode case, proposal-themed emails (“ATTN: Official Invitation to Submit Proposal”, “Review Required”) linked to hxxps://webdocusign.viewportal[.]es/Windows/download/index.php, which served eD0cuSign_Installer.msi into the Edge temporary downloads folder, and the ScreenConnect client installed afterwards connected to relay.bobdthjau[.]com:8041. In the Rippling case, a “Re: Tax Planning and Preparation Inquiry” email carried a Google redirect wrapper around hxxps://teams-microsoftcom5d41402abc4b2a76b9719d911017c592.kiratham[.]com/teams/?c4ca4238a0b923820dcc509a6f75849b, whose enrollment script lived at /teams/14/enroll14.php on the same host, and ScreenConnect then connected to relay.pronconetydesire[.]online:8041. The detection logic is a retrospective match of those hostnames, URLs, subject lines and the MSI file name in email, proxy, DNS and EDR logs.

Use secure email gateway message traces (subjects and embedded URLs, including unwrapped Google redirects), proxy and DNS logs, and EDR file-creation events. Sweep at least 90 days; Huntress gives no campaign start date and the actor can reuse lures. The lookalike Teams host was taken down quickly, so expect it in historical logs rather than live traffic. Blocking these specific domains is fine but brittle, since the relay names look randomly generated and the lure host embeds a hash-like string that is likely rotated; the durable signal is a ScreenConnect client talking to a relay that isn’t yours, covered in the Elite lead. Any host that resolved a relay hostname should be treated as under remote control: isolate it and check for MDM enrollment before removing the RMM.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Initial Access → T1566.002 (Phishing: Spearphishing Link); Command and Control → T1219.002 (Remote Access Tools: Remote Desktop Software) (our mapping; the source lists no ATT&CK IDs)

Sources: “Managed for Malice: How Attackers Turn MDM into Remote Access”, Huntress, Oct. 28, 2026, https://www.huntress.com/blog/attackers-turn-mdm-into-remote-access (source article)

Unsanctioned MDM Agent Inventory

Both attacks leave a fully functional MDM agent behind: Hexnode’s gateway and agent services plus bundled PostgreSQL components in the first case, and in the second a Rippling enrollment registry key, an agent MSI under C:\Windows\System32\config\systemprofile\AppData\Local\mdm\{GUID}.msi and the SYSTEM-level agent C:\Rippling\daemon.exe. In the Hexnode case, this agent is what let the actor reinstall ScreenConnect after it was removed. The detection logic is an inventory sweep of every Windows endpoint for MDM agents, services, install directories and enrollment registry entries, compared against the organization’s sanctioned MDM products and tenant identifiers, with any unknown product or tenant flagged.

Use EDR or asset-inventory software lists, service lists and file searches for vendor install paths (for example C:\Rippling\ and Hexnode service names), plus Windows MDM enrollment data under HKLM\SOFTWARE\Microsoft\Enrollments, which records the management server for each enrollment. Huntress doesn’t give the exact registry path it saw, so validate the enrollment-key location against a test device for each MDM you check. Run the sweep now and repeat it weekly. Organizations that legitimately use Hexnode or Rippling should compare tenant or server URLs, not just agent presence. This lead generalizes to any MDM, and to RMM tools: keep an allowlist of products and tenants and treat everything else as a security event. On a hit, remove the device from the rogue tenant and disable any attacker-created accounts first; removing only the RMM leaves the actor a way back in.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Execution → T1072 (Software Deployment Tools) (our mapping)

Sources: “Managed for Malice: How Attackers Turn MDM into Remote Access”, Huntress, Oct. 28, 2026, https://www.huntress.com/blog/attackers-turn-mdm-into-remote-access (source article)

MSI From Browser Download Folder Installs MDM Components

The Hexnode case started with eD0cuSign_Installer.msi, saved in Microsoft Edge’s temporary downloads folder and run by the user, which installed Hexnode Gateway, the Hexnode agent and PostgreSQL components rather than anything related to DocuSign. The name relies on a document-signing brand with deliberate character swaps. The detection logic is a process rule for msiexec.exe installing a package whose path is in a browser download or temp location (Edge, Chrome or Firefox download directories, %TEMP%) and whose name contains a document or meeting brand (DocuSign, Adobe, Teams, Zoom) or lookalike spelling, raised in severity when the install creates new services, a PostgreSQL instance or a management agent.

Use EDR process and service-creation telemetry or Windows Installer events (Application log, MsiInstaller event IDs 1033 and 11707) with the package path. Sweep 90 days. Some users do install legitimate tools from the browser, so tune by requiring the brand-name mismatch or a resulting service install, and allowlist packages signed by your own software distribution. Note that DocuSign itself has no need for a Windows installer to view an envelope, which makes a DocuSign-named MSI suspicious on its own. Blocking the MSI hash is the wrong control: the actor can rename and repack the vendor’s genuine agent indefinitely. Hits should be triaged with the user and treated as initial access if a management agent was installed.

Hunt Lead Level: 2 (Pro)

ATT&CK: Execution → T1204.002 (User Execution: Malicious File); Defense Evasion → T1036.005 (Masquerading: Match Legitimate Resource Name or Location) (our mapping)

Sources: “Managed for Malice: How Attackers Turn MDM into Remote Access”, Huntress, Oct. 28, 2026, https://www.huntress.com/blog/attackers-turn-mdm-into-remote-access (source article)

New MDM Enrollment Followed by RMM Install and External Relay

Huntress’s own guidance is to correlate the sequence: social engineering, then a new MDM enrollment, then an RMM installation, then an outbound connection to an unfamiliar relay. In the Rippling case the timing was tight: the enrollment registry key appeared about one minute after the user clicked, the agent installed as SYSTEM, and about 35 minutes later the MDM staged and ran a ScreenConnect installer as SYSTEM that connected to an external relay on port 8041. In the Hexnode case, ScreenConnect reappeared hours after removal on an already-enrolled device. The detection logic is a SIEM correlation on a single host: a new MDM enrollment or new management-agent service, followed within roughly 24 hours by an RMM installation (ScreenConnect, AnyDesk and similar) whose parent is the MDM agent or which runs as SYSTEM from the MDM’s staging path, followed by that RMM connecting to a relay hostname not on the organization’s allowlist, with a reinstall of a previously removed RMM as a high-confidence variant.

This needs EDR process and service telemetry, MDM or enrollment events, and DNS or proxy logs joined by host, plus an allowlist of sanctioned ScreenConnect relays and RMM instances. Sweep 90 days and keep the rule running. Legitimate onboarding by IT produces the same first two steps, so the anchor is the relay destination and the enrollment tenant, not the sequence alone; port 8041 by itself is ScreenConnect’s default relay port and is not suspicious. Do not “fix” a hit by uninstalling ScreenConnect only, which the Hexnode case shows the actor simply reverses through the MDM; remove the enrollment, disable attacker accounts, revoke sessions and tokens, reset credentials and reimage if integrity can’t be confirmed. Because many intrusion sets now abuse legitimate RMM tools, this correlation generalizes well beyond this actor.

Hunt Lead Level: 3 (Elite)

ATT&CK: Execution → T1072 (Software Deployment Tools); Command and Control → T1219.002 (Remote Access Tools: Remote Desktop Software) (our mapping)

Sources: “Managed for Malice: How Attackers Turn MDM into Remote Access”, Huntress, Oct. 28, 2026, https://www.huntress.com/blog/attackers-turn-mdm-into-remote-access (source article)

Hash Appendix

Lure installer and MDM agents

The source article publishes no hashes, and AlienVault OTX and VirusTotal were not queried in this run. The MSIs install the vendors’ genuine, signed Hexnode and Rippling agents and a genuine ScreenConnect client; blocking those hashes would break legitimate use of the same products, so detect the path, parent process, tenant and relay instead.

MD5s
(not available)  # eD0cuSign_Installer.msi -> Edge temporary downloads folder (installs Hexnode components)
(not available)  # {GUID}.msi -> C:\Windows\System32\config\systemprofile\AppData\Local\mdm\ (Rippling agent)
(not available)  # daemon.exe -> C:\Rippling\ (legitimate Rippling agent)

SHA1s
(not available)  # eD0cuSign_Installer.msi
(not available)  # {GUID}.msi
(not available)  # daemon.exe

SHA256s
(not available)  # eD0cuSign_Installer.msi
(not available)  # {GUID}.msi
(not available)  # daemon.exe

References Appendix

• “Managed for Malice: How Attackers Turn MDM into Remote Access”, Huntress (Ben Nahorney), Oct. 28, 2026, https://www.huntress.com/blog/attackers-turn-mdm-into-remote-access (source article; both cases, timing, indicators, recommendations)
• MITRE ATT&CK Enterprise technique pages linked above, MITRE, https://attack.mitre.org/