Short version — messy but fixable

Bad actors tricked people into running a shiny, signed installer and used a legitimate admin platform to quietly enroll machines and give themselves remote control. In plain terms: attackers abused Faronics Deploy to drop a second remote tool, ScreenConnect, on victim computers — and they did it by pretending to be invoices, tax files, or update prompts.

This campaign ran roughly between July 21 and August 20 and hit hundreds of endpoints via email lures. Once a target ran the fake installer (often disguised with names like Adobe.exe), their machine got enrolled in an attacker-controlled deployment, which let the crooks run PowerShell scripts and pull down more tools from attacker servers or public hosting sites.

How it worked and what to look for

The attackers leaned on the legitimate remote-deployment features of the platform — no zero-days required, just trickery and abuse of admin capabilities. Key nuggets:

  • Phishing emails with links that lead to a profiling page and then a prompt to download a signed Faronics installer.
  • Installer runs enroll the computer into the attacker-controlled deployment, letting scripts run without more clicks.
  • Malicious scripts used various download methods (curl, mshta, msiexec) to fetch additional payloads, eventually installing a second remote-access tool for interactive control.
  • Attackers installed ScreenConnect as a fallback/interactive channel and redundancy in case the initial deploy was discovered.
  • Activity eased up after the vendor implemented anti-abuse changes around August 21, suggesting the fixes were effective.

Pro tip: once attackers get valid credentials, defenders often lose a lot of ground — many automated blocks don’t catch post-login activity, so prevention numbers can look better on paper than in practice.

If you’re an admin, here are the practical signs you should hunt for right now:

  • Check for a file called ScriptRunner.log under C:\ProgramData\Faronics\Logs\ — it can show script names and download URLs used by remote executions.
  • Inspect Faronics configuration requests for a ck parameter. That value ties back to a specific deployment and can help spot compromised accounts or customer deployments.
  • Search your network and endpoints for unexpected ScreenConnect installations or services where you never deployed them.
  • Look for recently created scheduled tasks, unusual PowerShell executions, or calls to mshta/curl/msiexec targeting external URLs.
  • Audit enrollment records and installers dropped with odd names like Adobe.exe or similarly deceptive labels.

Recommended cleanup and hardening:

  • Isolate any suspected machines immediately and preserve logs for investigation.
  • Revoke or rotate credentials tied to compromised deployments and force password resets for affected accounts; enable multifactor authentication where possible.
  • Update the endpoint-management product and apply any vendor guidance or anti-abuse settings they provide.
  • Hunt for lateral movement and other persistence mechanisms — remove unexpected remote-access tools and validate that no backdoors remain.
  • Block or monitor the attacker infrastructure and known malicious domains at the network perimeter and proxy level.
  • Consider a post-incident review and phishing-resistant training — the initial vector was social engineering, so user awareness matters.

Short takeaway: this was a case of social engineering plus clever misuse of a legitimate admin tool. Keep an eye on logs, hunt for unfamiliar remote-access installs, and lock down admin flows so a single clicked file can’t quietly enroll machines into a hostile deployment.