The campaign abusing Faronics Deploy to install ConnectWise ScreenConnect is an important example of how attackers increasingly avoid malware when legitimate administrative software already provides everything they need. Rather than exploiting a vulnerability in Faronics Deploy, the attackers appear to be abusing the platform’s intended functionality. Victims receive phishing emails disguised as invoices, tax documents, financial records, invitations or other routine business communications and are directed toward a malicious website. They are eventually persuaded to download what appears to be an Adobe document, reader application or plugin update, but the executable is actually a legitimate, digitally signed Faronics Deploy installer. Once the victim runs it, the computer becomes enrolled in a Faronics deployment controlled by the threat actor, effectively handing the attacker a legitimate remote administration channel into the endpoint.

This distinction is important because many organizations still equate malicious activity with malicious software. In this campaign, the Faronics executable itself is genuine and signed by the legitimate vendor. The problem is who controls the deployment environment to which the endpoint is enrolled. Faronics Deploy is designed to allow administrators to install applications, execute scripts and manage computers remotely. Once attackers persuade the victim to enroll their machine in the attackers’ environment, those same legitimate capabilities become offensive tools. The platform is not being forced to perform something outside its design. It is performing exactly what it was built to do, except the administrator giving the instructions is a criminal.

Huntress observed more than 457 endpoints encountering Faronics-related phishing lures between July 21 and August 20. The phishing infrastructure also incorporated visitor profiling and cloaking techniques intended to reduce exposure to researchers and automated security systems. When somebody follows the malicious link, JavaScript collects information including browser User-Agent, platform, screen resolution, time zone, language, touch capability and other environmental properties. The backend can then determine whether the visitor resembles a genuine desktop user or an automated analysis environment. Suspicious visitors may receive an error message, unrelated decoy site or other harmless content rather than the actual attack chain.

This kind of selective delivery is increasingly common because attackers understand that mass phishing infrastructure is continuously inspected by security crawlers, sandboxes and researchers. The malicious payload does not need to be shown to everyone who visits the URL. In fact, doing so would make the campaign easier to discover. By fingerprinting visitors first, attackers can reserve the genuine infection process for systems that look like real business endpoints. Security teams therefore should not automatically conclude that a reported phishing link is harmless simply because opening it from a sandbox produces an error or benign page.

Once a genuine victim reaches the delivery stage, the campaign makes extensive use of trusted branding. Files have reportedly used names such as `Adobe.exe` or `AdobeReader.exe`, creating the impression that the user is installing a document reader or update. The executable itself is digitally signed because it is legitimate Faronics software. This creates an uncomfortable situation for traditional security controls: the file may have a valid signature, a known publisher and no malware embedded within it. The malicious intent lies in the enrollment configuration rather than the binary.

Digital signatures are therefore not equivalent to proof of legitimate use. A signature establishes that the software came from the publisher whose certificate signed it and that the executable has not subsequently been modified. It does not establish that the person asking the user to install it is legitimate or that the management tenant controlling the newly enrolled endpoint belongs to the victim’s organization. Attackers can abuse perfectly legitimate signed software when the product is designed to give its controller powerful administrative capabilities.

After enrollment, the attacker can use Faronics Deploy to execute scripts remotely without further interaction from the victim. Huntress repeatedly observed PowerShell being launched through Faronics to retrieve additional content from attacker infrastructure and external hosting locations including GitHub. Different scripts used utilities such as `curl`, `mshta` and `msiexec` to retrieve or install further payloads. These are all standard Windows administration or execution mechanisms, which makes the attack chain even more difficult to classify using simplistic allow-and-block logic.

The attackers subsequently deploy ConnectWise ScreenConnect, another legitimate remote administration product. ScreenConnect is widely used by IT support teams and managed service providers to provide interactive remote assistance. In the malicious campaign, installing ScreenConnect gives the threat actor a second remote-access mechanism that is independent of Faronics. This redundancy is strategically useful. If defenders notice the unexpected Faronics agent and remove it, the attacker may still retain remote access through ScreenConnect. Likewise, ScreenConnect provides convenient hands-on-keyboard interaction better suited to manually exploring the victim environment.

The deployment of a second remote-management product should therefore be viewed as an intentional persistence and resilience strategy rather than unnecessary duplication. Attackers understand that their initial access mechanism may eventually be discovered. Establishing another legitimate remote-access channel reduces dependence on the original compromise path and makes eradication more difficult. Incident responders who remove only the Faronics agent but fail to identify the ScreenConnect installation could therefore believe they have contained the incident while the attacker remains connected through the secondary channel.

This campaign fits a much broader trend involving abuse of Remote Monitoring and Management software. Tools such as ScreenConnect, AnyDesk, TeamViewer, Atera, Splashtop and numerous RMM platforms are valuable to legitimate administrators precisely because they provide persistent remote control, file transfer, script execution and software-deployment capabilities. Those same features make them attractive to attackers. Installing a commercial remote-support application can provide many of the capabilities of a custom remote-access Trojan without requiring criminals to develop malware or evade antivirus signatures.

Organizations should consequently maintain an explicit inventory of approved remote-management products. The security question should not be whether ScreenConnect itself is malicious, because it plainly is not. The question is whether ScreenConnect is authorized on that particular endpoint and whether its installation corresponds to a legitimate administrative process. If an organization has standardized on another remote-support platform and ScreenConnect suddenly appears on a finance employee’s laptop, its presence deserves immediate investigation regardless of whether the executable carries a valid signature.

Application control policies can help enforce this distinction. Instead of allowing any signed remote-management application to execute, enterprises can allow only specific approved products, versions and installation paths. Unknown RMM software can then be blocked or placed into an approval workflow. This reduces the ability of attackers to choose whichever legitimate remote-access product happens to bypass endpoint controls most easily.

The campaign also exposes an important limitation in security models based heavily on software reputation. Reputation systems are excellent at identifying known malicious binaries, but legitimate administration tools naturally possess strong reputation scores. Attackers deliberately exploit this trust. The stronger the reputation of the tool, the more attractive it may become as an offensive mechanism because security products and administrators are less likely to challenge it immediately.

Behavior therefore becomes more important than binary identity. A signed Faronics agent appearing unexpectedly after a user visits a phishing page, followed by PowerShell execution, downloads from external infrastructure and the installation of ScreenConnect, represents a highly suspicious sequence even though every individual executable may be legitimate. EDR systems should correlate these events rather than evaluating each process independently.

Process ancestry provides useful context. Security teams should examine whether PowerShell, `mshta`, `curl` or `msiexec` was launched through Faronics-related components and whether those actions occurred on systems where Faronics is not normally used. Similarly, newly installed ScreenConnect services should be compared against the organization's approved remote-management inventory and deployment history.

Huntress has identified useful forensic artifacts for organizations investigating possible exposure. Administrators should examine `C:\ProgramData\Faronics\Logs\`, particularly the `ScriptRunner.log` file. This log may preserve details of PowerShell or other scripts executed remotely through Faronics, external URLs used to retrieve additional content and evidence relating to ScreenConnect deployment. Even when the original phishing email is no longer available, these logs may help reconstruct what the attacker instructed the Faronics agent to execute.

Another potentially valuable indicator is the `ck` parameter appearing in Faronics configuration requests. According to Huntress and information received from Faronics, this value identifies the customer or deployment environment associated with the agent. Because the attack relies on enrolling victims into attacker-controlled deployments, the `ck` value can help defenders and the vendor cluster affected endpoints and identify malicious deployment infrastructure. This type of contextual identifier can remain useful even if attackers change filenames, hosting domains or installer hashes.

The presence of Faronics should nevertheless not be treated as inherently malicious. Organizations legitimately using the platform will naturally have the same software, services and communication patterns. Detection therefore needs to establish whether the installation was expected and whether the device enrolled into the organization's legitimate tenant. An unexpected enrollment identifier combined with remotely executed PowerShell and an unauthorized ScreenConnect installation provides much stronger evidence than simply detecting `Faronics.exe`.

The phishing stage should also receive attention because preventing the initial enrollment is considerably easier than removing multiple remote-access channels afterward. Email security systems should analyze messages containing unexpected invoice, tax or document-sharing links, but attackers will continue modifying wording and infrastructure. Browser and DNS controls capable of blocking newly registered or low-reputation domains can reduce exposure, while web isolation can provide another layer for higher-risk browsing.

User education remains relevant because the victim ultimately launches the Faronics installer. Employees should understand that a document, invoice or PDF normally should not require installation of an executable application from an unfamiliar website. A file named `Adobe.exe` is not a document simply because somebody gave it a reassuring filename. Security awareness works best when it teaches this underlying principle rather than expecting employees to memorize individual phishing templates.

Application installation rights can further reduce impact. Ordinary users often do not need the ability to enroll their computers into arbitrary endpoint-management platforms or install remote-access software. Where administrative privileges are required, privileged installation workflows can introduce additional verification before powerful management agents become active. The goal is not to prevent users from performing their jobs, but to recognize that installing an endpoint-management agent effectively delegates administrative control over the computer to somebody else.

Organizations should consider whether endpoint-management platforms themselves should support stronger enrollment restrictions. An administrator may legitimately need to enroll many machines, but allowing any downloaded agent to attach a workstation immediately to an arbitrary tenant creates obvious abuse potential. Enrollment approvals, device registration policies, tenant restrictions and warnings when joining external management domains can make social-engineering-based enrollment harder.

Faronics was notified by Huntress on August 5 and subsequently confirmed the malicious activity. The company introduced additional anti-abuse measures and contacted organizations believed to have been victimized. Huntress observed a dramatic reduction in campaign activity beginning around August 21, suggesting those measures successfully disrupted the specific infrastructure being used. That is encouraging, but it does not eliminate the broader technique because attackers can adapt the same model to other legitimate management platforms.

This is why defenders should focus on the attack pattern rather than only the Faronics brand. The generalized sequence is phishing, trusted administrative software, enrollment into attacker-controlled infrastructure, remote script execution and deployment of a secondary remote-management tool. Any product capable of remotely controlling or deploying software to endpoints could theoretically be abused in a similar way if attackers can convince users to enroll devices into a malicious tenant.

The technique also demonstrates why Zero Trust principles should extend to software administration. A binary should not receive unrestricted trust merely because it is signed. A remote-management session should not be trusted merely because it originates through a legitimate vendor's cloud platform. Security policy needs to consider whether the user, device, tenant and action belong together.

For example, an endpoint normally managed by the organization's approved RMM platform suddenly contacting an unrelated Faronics deployment should be anomalous. An employee in finance should not automatically be permitted to introduce a new endpoint-management platform simply because the installer is legitimate. Application identity, organizational authorization and device context need to be evaluated together.

Outbound network controls can provide another useful signal. Endpoint-management tools naturally communicate with their vendors’ cloud infrastructure, and ScreenConnect instances often connect to specific servers associated with the organization deploying them. Devices suddenly communicating with previously unseen management domains can therefore trigger investigation. DNS and proxy telemetry may reveal these patterns even when TLS prevents inspection of the actual remote-management session.

Incident responders encountering this activity should assume that finding ScreenConnect represents a potentially active remote-control channel. The endpoint should be isolated from the network while evidence is collected, and investigators should establish when Faronics was installed, which scripts it executed and when ScreenConnect became active. Simply uninstalling both applications may destroy useful forensic information without establishing what the attacker did while connected.

The investigation should extend to credentials used from the endpoint during the compromise window. Once attackers obtain interactive ScreenConnect access, they may search browsers, password managers, mapped drives, email clients and administrative tools for reusable credentials. Authentication logs should therefore be examined for unusual activity originating from the compromised machine or involving accounts used on it.

Privileged administrators who accessed the affected endpoint deserve particular attention. If a domain administrator or help-desk technician logged into the system while attackers possessed remote access, privileged credentials or authentication tokens may have been exposed. Tiered administration and dedicated privileged workstations can reduce this risk by preventing high-value credentials from appearing on ordinary user devices in the first place.

Network segmentation can limit what attackers achieve after obtaining remote access. A compromised employee workstation should not automatically reach domain controllers, backup infrastructure, databases or server-management interfaces. The attacker may control the endpoint completely, but segmentation ensures that endpoint compromise does not immediately become enterprise compromise.

RMM abuse is also a good example of why identity and network security need to work together. If ScreenConnect gives attackers control of an endpoint but sensitive applications still require strong identity verification and device trust, lateral access becomes more difficult. Conversely, strong MFA alone provides limited protection when the attacker is operating directly from the already authenticated employee device.

Behavioral monitoring can help identify this distinction. A user normally working with a handful of applications suddenly accessing administrative shares, enumerating servers or downloading large quantities of data should generate investigation even if the actions originate from their legitimate workstation. Endpoint compromise effectively allows attackers to inherit the victim's location and session context, making simple location-based trust much less useful.

The Faronics campaign therefore represents a broader shift from malware-centric intrusion toward abuse of legitimate control planes. Attackers increasingly ask a straightforward question: why write a custom remote-access Trojan when a trusted commercial tool already provides remote shell access, file transfer, persistence and software deployment? Legitimate tools reduce development cost, frequently bypass application reputation controls and blend into activity defenders are accustomed to seeing.

The defensive response is not to declare every administration tool dangerous. Enterprises depend on these products. The answer is governance and context: know which remote-management platforms are approved, which administrators may deploy them, which endpoints they may manage and which network destinations represent legitimate tenants. Anything outside those relationships should be investigated.

The immediate hunting priorities are therefore straightforward. Organizations should look for unexpected Faronics Deploy installations, inspect `C:\ProgramData\Faronics\Logs\ScriptRunner.log`, examine deployment `ck` identifiers, review PowerShell and related script execution initiated through Faronics and identify ScreenConnect installations that are not part of the approved IT environment. Systems showing the complete chain should be treated as compromised rather than merely misconfigured.

The broader lesson is that trust in legitimate software needs boundaries. Faronics Deploy and ScreenConnect are powerful because organizations deliberately give them administrative authority. That authority becomes dangerous when attackers can place their own management infrastructure behind the same trusted software. Security controls therefore need to verify not only what software is running, but who controls it and whether that control relationship is expected.

This campaign did not need to defeat Faronics' administrative capabilities. It borrowed them. It did not need custom remote-access malware because ScreenConnect already provided remote control. And it did not need to convince security systems that an obviously malicious executable was harmless because much of the software involved was genuinely legitimate.

That is precisely why this type of attack deserves attention. As organizations become better at blocking unknown malware, attackers will increasingly search for ways to turn trusted administrative infrastructure into their own attack platform. The defensive challenge is no longer simply identifying bad software. It is identifying when good software is operating for the wrong administrator.

Phishing actors are abusing the legitimate Faronics Deploy endpoint-management platform to gain remote administrative control over victim computers and install the ScreenConnect remote support software. [...]

Source: Hackers abuse Faronics Deploy admin tool to install ScreenConnect via Bleeping Computer — published 01 Sep 2026.