ScreenConnect Spread at Scale Through App Store-Themed Phishing

Summary

A large-scale phishing campaign is using advanced social engineering techniques to deploy unauthorized ConnectWise ScreenConnect clients. Attackers impersonate trusted services such as the Microsoft Store, Apple App Store, and Google Meet through dynamic web content and fraudulent update prompts. Once installed, the RMM software gives threat actors persistent remote access to compromised systems.

Investigation

The LevelBlue OpsCTI Team uncovered the campaign through analysis of a fake update phishing framework and reused infrastructure. Researchers identified consistent directory structures, recurring HTTP resource hashes, and AI-assisted scripts used to profile potential victims. The investigation also revealed abuse of Telegram Bot APIs for real-time telemetry and infection reporting.

Mitigation

Organizations should prioritize detecting unauthorized RMM software and monitor executable downloads from unfamiliar public cloud services such as Amazon S3 or Cloudflare R2. Controls for identifying brand impersonation and unauthorized Telegram Bot API traffic are also recommended. Regular endpoint inventory reviews can help uncover rogue ScreenConnect installations and existing compromises.

Response

If compromise is suspected, affected systems should be isolated immediately and any ScreenConnect clients communicating with unauthorized relay instances should be investigated. Network logs should be reviewed for suspicious connections to known phishing domains or public cloud storage endpoints. Responders should also examine processes launched by msiexec.exe or PowerShell that download files from external sources.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre-flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic. Abstract or unrelated examples will lead to misdiagnosis.

• Attack Narrative & Commands: An attacker has established a phishing campaign. To avoid detection by file-based antivirus, they host a legitimate remote access tool (ScreenConnect) on a public AWS S3 bucket that mimics legitimate software distribution. The attacker instructs a victim to download the installer. This action triggers a GetObject event in AWS CloudTrail, targeting the specific malicious bucket eobtdk.s3.us-east-2.amazonaws.com and the specific filename ScreenConnect.ClientSetup.msi.

• Regression Test Script: [Note: Since we cannot interact with real malicious buckets, this script simulates the request that would generate the log entry if the bucket existed.]

  #!/bin/bash
  # Simulation script to trigger the CloudTrail detection rule
  # This mimics the API call an adversary would make to download the tool
  
  echo "[+] Starting Simulation: Downloading ScreenConnect from Malicious S3..."
  
  # We use the AWS CLI to attempt a GET request. 
  # Even if the bucket doesn't exist, the 'request' attempt generates the CloudTrail event 
  # in a real environment where the bucket is configured.
  
  aws s3 cp s3://eobtdk/ScreenConnect.ClientSetup.msi . --region us-east-2
  
  echo "[+] Simulation command sent. Check CloudTrail for GetObject events targeting 'eobtdk.s3.us-east-2.amazonaws.com'."

• Cleanup Commands:

  # Remove any files downloaded during the simulation
  rm -f ScreenConnect.ClientSetup.msi