Home Blog Daisy-Chaining Rogue RMM Tools: How Threat Actors Abuse Remote Management Software for Initial Access Published: March 11, 2026 Daisy-Chaining Rogue RMM Tools: How Threat Actors Abuse Remote Management Software for Initial Access By: Chad Hudson The abuse of remote monitoring and management (RMM) tools is a trend that has been quietly building for some time. As an industry, we recognise it well and tend to speak about it in hushed tones. But it isn’t flashy, it doesn't generate headlines, and it doesn’t carry the intrigue of DPRK intrusions or the sophistication of malware downloaders like ClickFix . Instead, it’s the familiar unease that sets in when we see certain legitimate tools being quietly, repeatedly abused. We’re seeing this abuse span every tier of threat actors, from individuals with little to no skill to more established groups. Given this, it should come as no surprise that RMM abuse was the most common threat we observed last year, accounting for nearly a quarter (24%) of all observed incidents. But the increasing rate at which these tools are being abused should raise alarms. According to our latest research , RMM abuse surged 277% last year, as threat actors abandoned traditional hacking tools and built entire playbooks around these tools to drop malware, steal credentials, and execute commands. This blog analyses several cases we investigated during December 2025 and January 2026 to demonstrate a common tactic we see with RMM abuse: daisy-chaining distinct RMM tools to fragment telemetry, distribute persistence, and complicate attribution and containment efforts. During this period, we also observed threat actors signing up directly to the Huntress platform itself. This provided us with rare, firsthand visibility into their RMM patterns, operational workflows, and post-installation behaviour, offering a unique lens into how these campaigns are orchestrated from the operator’s perspective. Tradecraft observed during intrusions In December 2025, we observed lower-skilled threat actors leveraging rogue RMM MSI installers to establish initial access and execute follow-on payloads. In multiple cases, these installers spawned large language model (LLM)-generated infostealer scripts designed to identify potentially valuable user accounts. The scripts primarily parsed browser history for references to financial and cryptocurrency platforms, including QuickBooks and Coinbase, indicating an objective of rapidly identifying monetisable access. Despite this intent, the script reflected limited technical maturity. In one example, code comments indicated that harvested data would be transmitted to a threat-actor-controlled Telegram channel; however, the script didn't actually implement the Telegram API functionality required to perform this exfiltration. As a result, while local data collection occurred as intended, the exfiltration stage was never successfully executed. Figure 1: Code comment from LLM created a script designed to send results to Telegram In January 2026, we observed threat actors leveraging vulnerability management software such as Action1 to deploy ScreenConnect clients via Microsoft Installer packages. There’s nothing particularly sophisticated about this approach; it relies on abusing legitimately signed deployment tooling to daisy-chain ScreenConnect installations for persistent remote access. Figure 2: ScreenConnect deployment via Action1 vulnerability management software Threat actors have also attempted to sidestep detection by reusing familiar daisy-chain techniques from vulnerability management and deployment tooling, this time relying on wscript to install additional payloads. The scripts themselves, once again, appear to have been assembled using LLMs, based on the coding style, comment structure, and overall syntax. Figure 3: ScreenConnect deployment via WScript During a similar campaign, we observed Telegram messages for “ InjectProx-hiro Remote Support ”. The tooling itself is relatively simple: it deploys a ScreenConnect client and sends a bot notification containing the victim system’s computer name. Figure 4: Telegram API notification via WScript The list keeps growing. We’ve observed abuse extending beyond widely used RMM platforms to lesser-known RMMs like HeartbeatRM , often delivered through familiar invitation-themed lures . At this point, any deployment or management software offering trial access or “free” deployment allowances is being actively abused or is likely to be abused in the near future. Figure 5: HeartbeatRM execution from invitation lure In most cases, the threat actors abusing this technique are low-level, seeking any foothold they can gain for initial access. We consistently see this spike around predictable themes such as the United States tax season , or lures impersonating the Social Security Administration , because they’re easy to mass-produce and reliably generate clicks. These lures are pushed via broad email campaigns or surfaced through search-engine poisoning, funnelling victims toward invitation or document-themed downloads that ultimately lead to RMM deployment rather than traditional malware. Figure 6: Fake Social Security Administration websites While investigating these watering-hole campaigns, we identified multiple GitHub repositories being abused to host phishing infrastructure, including repositories associated with VH851 and Drasticc user accounts . Huntress proactively reported these accounts, amongst others, to reduce the number of victims impacted by this activity; however, the activity tied to these repositories dates back to November and December 2025 , indicating sustained use rather than a short-lived campaign. Figure 7: VH851 GitHub repository While gathering artifacts from VH851, we identified multiple repositories linked to invitation-based lures, including invitatapartyTo.msi . One particular repository, rty , was of interest and demonstrates a more deliberate approach to infrastructure setup. Rather than hosting content on a disposable file-sharing platform, the threat actor likely configured a custom domain via GitHub that references the CNAME record, allowing full control over how the phishing site is presented and delivered within GitHub. The repository includes a minimal but functional phishing site ( index.html ) paired with supporting assets ( background.jpg ), designed to present a convincing invitation or RSVP-style lure. Figure 8: Contents of the rty repository The index.html file itself is deliberately minimal, but it’s doing more than just presenting a lure. The page attempts to force delivery of an MSI installer using multiple browser-native techniques, increasing the likelihood that at least one succeeds depending on browser configuration or security controls. Specifically, the page cycles through three distinct download mechanisms: Attempt 1: Programmatic anchor click , a hidden <a> element is dynamically created and clicked to trigger a direct download of the MSI from GitHub’s raw content endpoint. Attempt 2: Hidden iframe injection where if the anchor-based download fails, the page attempts to load the MSI via a hidden <iframe> , a common fallback that can still succeed in environments with relaxed download restrictions. Attempt 3: Fetch-to-blob download as a final attempt; the page fetches the MSI, converts it to a blob, and forces a local save. This technique is more verbose but can bypass simple blockers that rely on URL-based download heuristics. This approach is brute-force reliable. The threat actor isn’t exploiting a browser vulnerability; they’re stacking legitimate web APIs until one of them works. It’s a pattern we’ve seen repeatedly in low-effort RMM delivery campaigns, where reliability matters more than stealth. Figure 9: index.html and brute force download functions By searching for key strings and functional components from the index.html across other repositories, we identified Drasticc , another abused GitHub repository that predates VH851 and shows a longer period of activity. Compared to VH851 , Drasticc appears to have been more actively maintained. Figure 10: Drasticc GitHub repository Reviewing these repositories and their contents provides useful insight into the threat actor's activity, including which operating systems they targeted, how those platforms were delivered, and the types of phishing lures they consistently relied on. Taken together, these artifacts help build a clearer picture of the threat actor's intended targets. In related repositories focused on Social Security Administration lures, we also observed a simple yet deliberate control. When the user agent was set to anything other than Windows, the page returned an “ Access Denied ” message. Figure 11: Access Denied, only Windows is allowed This lightweight filtering is reflected in the client-side logic. The page fingerprints the visitor’s operating system using standard browser properties ( navigator.userAgent , navigator.platform , and userAgentData ) and makes a simple decision; Windows is allowed, and everything else is blocked. If the visitor is identified as running Windows, the page transitions to the “success” state and continues toward delivery. If not, the user is presented with an “Access Denied” message instructing them to use a Windows device instead. Figure 12: GetOS functionality to ensure only Windows devices We also observed a separate campaign that took the opposite approach, deliberately targeting only mobile users . In this case, the page would not load unless the user agent matched a mobile device. Desktop browsers were either blocked or served no meaningful content. When accessed from a mobile device, the page presented what appeared to be a legitimate online greeting card. From there, the victim was prompted to sign in to their email provider to “view” or “manage” the invitation. The main goal here was credential harvesting rather than malware or RMM delivery, leveraging mobile users