From E-Sign to RMM: DocuSign Kit Targets Windows and macOS

What Happened? 

BlueVoyant SOC (Security Operations Center) and Threat Fusion Cell (TFC) teams are tracking a long-running phishing and remote access campaign that uses DocuSign/e-sign themed lures and a reusable web kit to drive victims into installing legitimate remote access tooling. The observed infrastructure relies on staged landing pages that mimic common business workflows (document viewing and signing), incorporates friction-reduction steps such as Cloudflare Turnstile, and uses user-agent based gating to steer victims into preferred environments. In one observed intrusion chain, BlueVoyant researchers identified a staging site where benign-looking content was presented at the root path while the operational phishing workflow was served from a subdirectory. This approach likely helps separate ‘legitimate-looking’ content from payload delivery and complicate superficial domain review. Separately, broader telemetry shows the DocuSign-themed kit is also hosted across numerous unrelated domains, indicating the kit is not tied to a single hosting model. 

This research details the staged phishing workflow—simulated document loading, user-agent based target gating, and payload delivery—and analyzes an associated VBS deployment script recovered during the investigation. The VBS logic requests elevation via User Account Control, performs a remote execution check, attempts to modify security settings, and installs remote management software for persistent access. Finally, we contextualize this activity within a broader DocuSign kit ecosystem that shows consistent patterns across many domains and includes both Windows and macOS delivery paths, suggesting an expansion in victim targeting and platform coverage over time. 

Executive Summary  

BlueVoyant identified a phishing campaign leveraging convincing DocuSign-themed lures to trick users into installing legitimate remote management software that provides attackers persistent remote access.  Unlike traditional malware campaigns, this activity abuses trusted administration tools such as MeshAgent and ScreenConnect, making detection more difficult.  The campaign also demonstrates increasing operational maturity through staged delivery, user environment validation, Cloudflare Turnstile verification, and support for both Windows and macOS targets. 

Attack Breakdown 

The phishing page is organized into a multi-stage workflow consisting of three distinct phases. Rather than immediately presenting download functionality, the page sequentially transitions the visitor through a simulated document loading interface, user-agent based target gating, and a final download interface. This staged approach appears intended to increase the perceived legitimacy of the page while limiting access to selected environments before initiating payload delivery. 

Phase One – Simulated Document Loading 

The phishing page initially presents a full-screen interface designed to emulate the experience of opening a PDF document in Adobe Acrobat. This first phase consists of a blurred document viewer (#pdf-loader) that occupies the browser window and conceals the remainder of the webpage while the interface performs a timed transition. The layout recreates several recognizable Acrobat interface elements, including a blue title bar, a document title, an “Open in Acrobat” button, a navigation sidebar, a blurred document canvas populated with placeholder text, a PDF file icon, and a progress bar that advances over approximately three seconds. Additional visual components—including an “Activate Windows” watermark and a footer displaying “Loading secure document... Please wait”—further reinforce the appearance of a legitimate document viewer. 

Although the interface appears to simulate the loading of a secure document, no document processing or rendering occurs during this phase. Instead, the experience is presentation-driven, relying on CSS styling, animations, and a JavaScript timer to delay progression through the workflow. During initialization, the page waits for the duration specified by the loaderDuration configuration value before fading out the simulated viewer and revealing the next stage. 

This controlled delay creates the impression that a document is being securely prepared for viewing, increasing the perceived legitimacy of the phishing page before the user is presented with any actionable content. 

Phase Two – User-Agent Based Target Gating 

Following the simulated loading screen, the phishing page performs user-agent based filtering to decide whether the visitor should be permitted to continue. These checks occur before the primary interaction interface is revealed and act as gating logic controlling whether the visitor may proceed. 

The logic is implemented through the detectEnv() function, which examines the browser’s User-Agent string to identify the operating system and browser family. The first check searches for the Windows NT identifier to determine whether the visitor appears to be using Microsoft Windows. If this check fails, the normal workflow is terminated and the visitor is presented with a full-screen “Platform Not Supported” message (#os-blocker) stating that the document requires Adobe Document Cloud for Windows. 

A second check targets Microsoft Edge by searching for Edg/ or Edge/ in the User-Agent string. Visitors presenting as Edge are diverted to a separate blocking interface (#edge-blocker) indicating that their browser is unsupported and recommending switching to Chrome, Firefox, or Opera before continuing. This restriction is likely intended to reduce friction from Edge/SmartScreen prompts or to align with tested execution paths, rather than reflecting genuine compatibility constraints. 

These routines segment visitors before any download functionality becomes available, selectively limiting access based on predefined criteria. 

Phase Three – User Interaction and Payload Delivery 

After the visitor passes the user-agent gating checks, the phishing page transitions to its primary interaction interface. This final phase presents branding intended to resemble a legitimate electronic document-signing or document-access experience and guides the user through a verification step before initiating the download process. 

The interface adopts visual elements that imitate a trusted document workflow, including corporate-style branding, instructional messaging, and a professionally styled layout intended to reinforce legitimacy. Before the download option becomes available, the visitor must complete a Cloudflare Turnstile challenge. The Turnstile callback function (onTurnstileSuccess) stores the returned verification token and enables the previously disabled download button, preventing interaction until verification has been completed. 

When the download button is selected, the page executes a sequence of actions coordinating telemetry collection and payload delivery. The page enters a loading state while an asynchronous notification routine gathers the current UTC timestamp, the visitor’s public IP address (retrieved via api[.]ipify[.]org), the browser User-Agent string, and the configured filename. This information is formatted into a structured message and transmitted to a predefined Telegram bot through the Telegram Bot API, providing the operator near real-time notification that a visitor has initiated the download process. 

Following a brief delay, the page redirects the browser to the configured Dropbox URL by assigning downloadUrl to window.location.href. This causes the browser to retrieve the configured payload while the interface updates to display a success notification indicating the download is beginning. 

During the incident, BlueVoyant researchers observed the phishing page configured with a Dropbox link delivering a VBS file. At the time of publication, the threat group had shifted to delivering an RMM installer (ScreenConnect MSI) from Dropbox, suggesting iterative changes in the delivery mechanism and/or operator preference. 

VBS Analysis 

Analysis of the Visual Basic Script (VBS) indicates the script functions as an automated deployment utility responsible for validating execution, preparing the host environment, and installing a remote management agent with minimal user interaction. 

The script begins by defining a set of configurable parameters—including remote download locations, a deployment key, installation paths, and logging locations—allowing the operator to adjust deployment settings without altering the core logic. Before continuing, the script checks whether it is running with administrative privileges and, if necessary, relaunches itself using the Windows Script Host with the runas verb to request elevation via User Account Control (UAC). 

The script also validates a deployment key against a remote licensing endpoint, enabling the operator to remotely authorize or deny execution prior to installation. 

Following successful validation, the script performs actions intended to reduce the likelihood of detection or interference by built-in security controls. Specifically, it invokes PowerShell commands that attempt to disable Microsoft Defender real-time monitoring and attempt to add antivirus exclusions for the temporary working directory and the intended installation directory. These actions may be blocked in environments with Microsoft Defender Tamper Protection enabled or where security settings are centrally enforced via Mobile Device Management/Group Policy. 

The deployment process then focuses on replacing any existing MeshAgent installation. The script terminates active MeshAgent processes, removes associated Windows services, searches common installation directories for existing agent binaries, and invokes the agent’s built-in uninstaller where available. Residual installation directories are subsequently removed to reduce the chance that prior deployments interfere with installation of a replacement agent. 

Once the host has been prepared, the script downloads a new MeshAgent executable from a remote server, writes the binary to disk using an ADODB.Stream object, verifies that the download completed successfully, and executes the installer using the -fullinstall argument. Throughout execution, status and error details are recorded to a local log file. 

Although the script does not establish persistence via mechanisms such as registry Run keys or scheduled tasks, installing MeshAgent as a Windows service leverages the agent’s native service-based persistence, ensuring the remote management software starts automatically across reboots. Of course, legitimate RMM (Remote Monitoring and Management Tool) software allows attackers to blend into enterprise environments behind common IT tooling and makes detection more difficult. 

Campaign Overview 

This activity appears to be a sustained phishing and remote access campaign that leverages a reusable DocuSign/e-sign kit and rotates among multiple legitimate remote management tools over time. The infrastructure and telemetry indicate a clear emphasis on document-signing themed social engineering, with consistent URL structures such as `/docusign/.../utility.php` and heavily nested `/download/` path patterns that appear designed to complicate static URL detections and increase resilience as sites and paths are rotated. Based on telemetry of the broader infrastructure, campaign activity is visible from at least May 2026 through July 2026, with multiple DocuSign-themed Windows and macOS paths observed across this period. The consistent staging logic across network infrastructure suggests reuse of an effective phishing framework rather than one-off pages. 

A notable evolution in the campaign is the repeated observation of macOS-specific delivery paths within the DocuSign kit. Multiple domains host parallel Windows and Mac directory structures (for example, /docusign/d0cs/Windows/… and /docusign/d0cs/Mac/…). This Windows/Mac branching indicates the operators expanded the kit to route victims by platform and potentially serve platform-specific payloads or instructions, even when final tooling may differ between waves. 

Across various waves, the operators appear to deliberately cycle through multiple legitimate remote access and management tools rather than relying on a single payload family. MeshCentral/MeshAgent is a prominent component, supported by dedicated infrastructure, such as i8reactorsee[.]xyz, hosting MeshCentral-style agent distribution endpoints and websocket agent connectivity, with observed downloads of MeshAgent binaries from late May 2026 onward. The campaign also leverages ScreenConnect (ConnectWise Control) with the installer observed being delivered via magroys[.]lat. In addition, the campaign has delivered SimpleHelp RMM tooling and Zoho-signed UEMSAgent installer, retrieved from a DocuSign-themed delivery, indicating additional tracks where endpoint management tooling is used to establish managed access under the cover of a document-signing workflow. Taken together, these artifacts reinforce that the campaign’s core strategy is consistent—DocuSign/e-sign themed lures and kit-based staging—while the access tooling remains adaptable, shifting between MeshCentral/MeshAgent, ScreenConnect, and other signed management agents as needed to maintain reliability and evade containment. 

Conclusion 

BlueVoyant researchers identified a phishing campaign that blends convincing DocuSign/e-sign themed social engineering with staged web-based delivery to establish remote access using legitimate remote management tooling, confirming a widely observed trend abusing RMM tools for attacks. The observed landing pages guide users through a simulated document workflow, apply user-agent based gating (including Windows-only checks and Edge blocking), require Cloudflare Turnstile completion, and then initiate payload delivery—while relaying victim interaction telemetry to the operator. In parallel with the specific intrusion chain analyzed in this report, broader telemetry shows this kit is reused across multiple domains with highly consistent URL structures and “e-sign” page titles, indicating a scalable operation and an explicit expansion to macOS delivery paths in addition to Windows. Over time, the actors have demonstrated flexibility in access tooling, leveraging MeshCentral/MeshAgent infrastructure and delivering additional signed management tooling such as Zoho/ManageEngine UEMSAgent via DocuSign-themed download paths. 

Network defender recommendations: prioritize detections for (1) access to DocuSign kit-style paths—especially repeated /docusign/ + /Windows/ or /Mac/ + utility.php and deeply nested /download/ chains; (2) installation and execution of legitimate remote access tools from internet origin, including MeshCentral Agent activity and unexpected ScreenConnect infrastructure access; and (3) suspicious script-driven installation behavior such as wscript.exe spawning PowerShell and attempts to change Defender configuration (noting these may be blocked by Tamper Protection/MDM policy). Where feasible, restrict unauthorized RMM/UEM tooling via application control and software allowlisting, and alert on new service creation consistent with remote management agent installation. 

MITRE ATT&CK Techniques 

T1059.005 (Command and Scripting Interpreter: Visual Basic) 

T1548.002 (Abuse Elevation Control Mechanism: Bypass User Account Control) 

T1562.001 (Impair Defenses: Disable or Modify Tools) 

T1219 (Remote Access Tools)  

T1071.001 (Application Layer Protocol: Web Protocols)  

T1105 (Ingress Tool Transfer) 

T1036 (Masquerading) 

T1070.004 (Indicator Removal: File Deletion) 

T1543.003 (Create or Modify System Process: Windows Service) 

T1566.002 (Phishing: Spearphishing Link) 

Indicators 

hxxps://rosetomaz[.]com[.]br/it/ 

hxxps://www[.]dropbox[.]com/.../ScreenConnect.ClientSetup[.]msi 

hxxps://spearbit[.]com/license/check[.]php?... 

hxxps://spearbit[.]com/meshagents?... 

rosetomaz[.]com[.]br 

spearbit[.]com 

api[.]ipify[.]org 

i8reactorsee[.]xyz 

magroys[.]lat 

2A206B085FEDF8B20D1DB883814C15E0202617DA223DBB4E28B7109DF98645DF 

4F1C8DE304A855C2A4D1995B41069641DEE84F1B51B6FB4A6E24EEE59C6A30E4