Fake Adobe, Real RMM: The Hunt That Found 13 Missing Tools

Adobe_Helper.exe gives you a pretty clear idea of what someone wants you to think you are running. In the sample we reviewed, the file identified itself as RG Supervision, a remote monitoring and management agent from RG System. It carried an RG Systèmes SAS signature, and local verification of that signature succeeded. Someone had put an Adobe name on a real, signed RMM agent.

That file was one thread in a much larger collection of familiar names. Earlier Lavawall and Zecurit leads from @patialavii prompted us to look for other remote-management tools turning up as Zoom installers, Adobe downloads, and DocuSign documents. The more we checked the software underneath those names, the more products we found, including several missing from LOLRMM.

The work eventually identified 13 missing catalog entries: RG Supervision, plus 12 entries in a follow-up submission. Some came from suspicious delivery observations. Others emerged when we widened the research into product identification and static analysis. That distinction matters: we found gaps in our coverage of remote-management software, with different evidence behind each one. We did not establish 13 new abuse campaigns.

An obvious disguise can still conceal a tool your detections do not recognize yet. I wanted to know what else we were missing once we stopped taking the filenames at face value, and Adobe_Helper.exe gave us a concrete place to start.

The names are familiar for a reason

A Zoom installer supplies a reason to run an executable before a meeting. An Adobe download supplies a reason to install something before opening a document. DocuSign, remittance notices, and Social Security paperwork supply their own reasons to keep clicking. These themes fit routine work, which makes them useful covers for software a user would otherwise have little reason to install.

For an adversary, a remote-management agent is a particularly useful thing to put behind that request. Depending on the product and configuration, an installed agent can provide command execution, file transfer, software deployment, or interactive access. Those are normal administrative features. When the deployment belongs to an attacker, the same features can give that attacker a way to operate the endpoint.

Our first bounded review mapped 94 unique file hashes to 13 RMM products with familiar-brand or document-themed names. Twelve products had Adobe-themed names, eight had Zoom-themed names, and eight had DocuSign-themed names. The groups overlap because the same product, and sometimes the same file, appeared under several names.

Here are a few representative examples. The names came from sample records or reviewed delivery evidence; product identity came from supporting metadata, signatures, or static inspection.

A filename in a sample repository is a useful lead, but it does not show that someone received or ran the file. Where a recorded download URL was available, we reviewed that separately and checked the payload hash when the record exposed it. That let us distinguish an interesting alias from evidence tying a particular file to a download location.

The 94 hashes describe the collection we reviewed. They are not a measure of victims, successful installations, or overall prevalence. Shared Adobe and Zoom themes also give us no basis to put all these files under one operator. The repetition is useful because it tells us where to look next.

Lavawall and Zecurit got the hunt moving

The original Lavawall leads carried the names Zoom client_installer.exe and AdobeReaderInstaller.exe. Underneath, the inspected files retained Lavawall's product identity. That gave us two clear examples of remote-management software recorded under unrelated application names, although the reviewed records did not provide a download chain for either file.

Zecurit supplied a stronger delivery example. @patialavii reported a Zoom-themed page delivering a Zecurit payload, with the download named zoominstaller.exe. The reviewed relationship record corroborated the reported landing page, and the file review established the Zecurit identity. The name told one story; the software inside supplied remote-management functionality.

Both products received LOLRMM entries through Lavawall PR #248 and Zecurit PR #249. From there, we expanded the searches across familiar filenames, product metadata, publishers, and installer formats. That is how we reached the Adobe helper that was still missing from the catalog.

Adobe_Helper.exe was RG Supervision

The RG sample is the clearest example of why it helps to keep following the product identity. Its recorded download location was a Cloudflare R2 URL ending in Adobe_Helper.exe, and the URL record's response-body hash matched the file we inspected. That tied the Adobe filename to this specific payload, beyond its appearance in a list of submitted names.

The executable's own metadata consistently identified RG Supervision. The Adobe branding was in the download name, while the fields inside the file described the agent:

Local Authenticode verification succeeded, including the signed-content digest and certificate-chain checks. There was no need to invent an Adobe publisher inside the executable to make the filename misleading. The actual publisher remained visible to anyone who checked it.

RG System's deployment-kit documentation describes distributing a Windows executable with predefined configuration. The inspected agent contained deployment-kit configuration, consistent with that workflow. For legitimate administrators, this makes agent deployment convenient. In an unauthorized deployment, the same convenience is precisely why a user needs to know whose management environment the agent will join.

This is where a valid signature stops answering the question defenders care about. It helps establish the publisher of the signed content. It does not establish that your organization approved the installation, that the surrounding download page is legitimate, or that the deployment configuration belongs to your IT team. You still have to determine who put the agent there and who controls it.

Other researchers had already seen this file. MalwareBazaar's record credits @proxylife, and a public Triage report covers the same hash. The verified public sample records date to August 31, 2026. Our public-reporting review could not find a detailed incident or campaign write-up identifying RG Supervision behind this Adobe-themed delivery, but the sample itself was already public.

Our contribution was to connect the delivery observation to the signed RG agent and document the product's artifacts for LOLRMM. The available sandbox evidence included RG Systemes registry activity, a temporary rgsupv cache artifact, and a DNS lookup for a vendor host. It did not establish a completed installation or remote-control session, so the finding stays with the suspicious delivery and the identified software.

RG System / RG Supervision is now in LOLRMM through merged PR #250. The entry includes the sample hash, publisher metadata, and artifacts that remain useful when the next download has a different name.

Sometimes the disguise goes deeper than the filename

Rodex gave us a useful reminder that product metadata also needs corroboration. One reviewed sample called itself ZOOM RMM and ZOOM Agent; another used DocuSign RMM. The Zoom-labelled file still retained Rodex copyright information, and comparison of binary fingerprints and PE structure connected the builds to the existing Rodex RMM family.

That changes how you handle the result. Treating every unfamiliar product string as a new tool would have created extra entries for the disguise and split one family across several names. In this case, resolving the underlying family preserved the coverage we already had. The Zoom-labelled sample had a recorded download relationship, although that endpoint did not expose the filename used on the wire.

A later installer review also turned up Adobe_PDF_V709.422.msi. Static extraction identified Bluetrait Agent 3.8.4, signed by Dalegroup, with Bluetrait MSP Agent.exe and BluetraitUserAgent.exe inside. Bluetrait was already catalogued; the Adobe name was the interesting observation. It showed why the hunt needed to include MSI packages and installed components as well as the outer executable name.

Mremote was another missing piece

Mremote took more work to identify. An Adobe-themed executable described itself as Mremote Agent, but a self-reported name was not enough to create a new entry. We checked the file's implementation against EGSCI's Mremote product documentation and found a consistent remote-support product: an endpoint agent, a web console, screen and input control, file transfer, and service-based operation.

Static analysis of the Windows agent recovered Go code and functions for remote shell and PowerShell, file operations, screen capture, input control, service management, and updates. Its configured relay was wss://api.mremote.io/host-ws. Together, those details established a much stronger identity than the Adobe filename or the product string alone.

The reviewed delivery records linked the configured agent to a QR shortener and a third-party download host. We did not establish that the vendor controlled that host, and the evidence did not show a successful remote session. The supported finding is an identifiable remote-support agent in a suspicious Adobe-themed delivery context. Mremote is also distinct from mRemoteNG, the connection manager already covered by LOLRMM.

There are useful host artifacts here, including %APPDATA%\Mremote\agent.exe, %APPDATA%\Mremote\agent.log, and the fallback service name MremoteAgent. That service name can be overridden by deployment configuration, so it should not become a mandatory condition in every detection. The directory-qualified executable path is also much more useful than searching for every process named agent.exe.

How the hunt became 13 catalog additions

Once these leads started exposing gaps, we widened the research to ask which other remote-management products and custom agents were missing from LOLRMM. That meant checking vendor documentation, matching official releases where available, and inspecting code when a file lacked a clear public product history. We required evidence of a distinct management tool or coherent remote-management functionality before treating a name as a catalog candidate.

That broader work produced 12 new entries in PR #251. Together with RG Supervision in #250, that accounts for the 13 missing entries in this article. Lavawall and Zecurit were the earlier additions that started the investigation and are outside this count.

These entries have different evidence behind them, and the catalog preserves those differences. RG Supervision and Mremote have the suspicious delivery contexts discussed above. For the other entries, this research did not establish abuse. Several are custom tools whose publishers and operating context remain unverified; placing them in the catalog does not certify them as legitimate commercial products.

Basic RMM is a good example of why that qualification matters. Alongside ordinary management functions, recovered command dispatch included keylogging, webcam and audio access, and hidden virtual desktop controls. Those capabilities deserve scrutiny. The code establishes that the command surfaces exist, while the available evidence does not tell us who used them or against whom.

We also identified a PixoIT-branded build with Breeze RMM code lineage. That became an update to the existing Breeze entry, rather than another new product. Consequently, #251 changes 13 catalog files while adding 12 entries. The separate first-pass finding of 94 hashes across 13 products measures a different research set and should not be combined with this additions count.

Hunt the identity that survives the rename

The download name helps explain what a user may have thought they were opening. Product-specific artifacts help you find what actually arrived. For RG Supervision, the new catalog entry brings those clues together:

The installation directory is configurable, and these artifacts identify software rather than proving malicious use. Their value is that another filename change does not erase every clue. Correlate them with the download source, installer ancestry, service creation, software inventory, and the organization's approved management tools.

The deeper work also produced artifacts for products without an abuse finding. Allocentra's Windows installation code copies allocentra-agent.exe into C:\Program Files\Allocentra\Agent, registers AllocentraAgent, and uses HKLM\SOFTWARE\Allocentra\Agent for configuration. Those details can help identify a deployment regardless of the name used to deliver the installer. Keeping that evidence in the catalog gives the next analyst a better starting point.

The same care applies across operating systems. We inspected official Breeze Linux and macOS artifacts and expanded its entry with verified service, configuration, and launchd information. Where other vendors documented Unix support but we had no package to inspect, we left the platform-specific artifact gaps explicit. A support matrix does not tell you the path or service label you should be hunting.

For prevention, start with an approved inventory of remote-management software and a policy for how it may be installed. Products with no business use are candidates for execution restrictions. Where an RMM is approved, check the deployment account or management destination when the product makes that information available; recognizing the vendor alone leaves a substantial question unanswered. Product service names and vendor domains help with identification, but they need context before you treat them as malicious indicators.

That is the part I care about most. A legitimate management agent can give an unwanted operator very useful capabilities without needing to look like a traditional malware payload. If the download says Adobe and the executable says RG Supervision, the mismatch deserves an explanation before the agent becomes part of your environment. Following that mismatch gave us one concrete catalog addition, then enough leads to pursue twelve more.

Thanks to @patialavii for the Lavawall and Zecurit leads that started the digging, and to the researchers who made the earlier sample records available. The RG artifacts are in LOLRMM now, and the follow-up additions are available for review. We'll keep documenting the software underneath the filenames.

Selected sample hashes

These SHA-256 values identify the specific files discussed above. The table includes both delivery observations and alias-only examples; it is not a blanket malware classification.

The research combined existing file and URL records, vendor documentation, static inspection, and previously available sandbox evidence. No samples were executed or enrolled as part of the research, and no new sandbox runs or live remote-control tests were performed. Tenant identifiers, enrollment values, and raw third-party delivery URLs are omitted.

LOLRMM now has 13 more entries because of this hunt. MagicSword enforces that catalog automatically across your fleet.

If you want to see what remote management tools are running in your environment: book a demo.