ScreenConnect Backdoor Deployed Through Malicious Email

Summary

An email phishing campaign impersonates the Social Security Administration to deliver a malicious payload. Victims are redirected to a fake website that prompts them to download a customized ScreenConnect client installer. Once installed, the software functions as a backdoor, giving attackers persistent remote access to the compromised system.

Investigation

The investigation examined malicious email headers, the phishing website, and associated network traffic. Analysts identified a specific IP address used to deliver the phishing emails and a domain hosting the fake SSA landing page. Network analysis also confirmed encrypted ScreenConnect communications over port 443.

Mitigation

Organizations should deploy robust email filtering to block phishing attempts and restrict access to known malicious domains. Users should be trained to identify spoofed sender addresses and avoid links in unsolicited emails. Limiting or controlling the installation of remote administration tools such as ScreenConnect can further reduce the attack surface.

Response

If malicious activity is detected, the affected host should be isolated immediately to stop further command-and-control communication. Responders should perform a full forensic analysis to determine the scope of compromise. Potentially exposed credentials should be revoked, and systems should be checked for additional persistence mechanisms introduced during the remote session.

Simulation Execution

• Attack Narrative & Commands: The adversary has established a foothold on the system and intends to use a ScreenConnect instance to maintain remote access. To bypass standard detection that looks for known malicious IPs, they utilize the official ScreenConnect relay mechanism. The attacker executes a connection to instance-udppxf-relay.screenconnect.com on port 443. This action is designed to look like legitimate encrypted web traffic, but it specifically matches the target domain defined in the detection rule.

• Regression Test Script:

  # Simulation Script: Trigger ScreenConnect Domain Detection
  # This script attempts to connect to the specific domain targeted by the rule.
  
  $TargetDomain = "instance-udppxf-relay.screenconnect.com"
  $Port = 443
  
  Write-Host "Attempting to connect to $TargetDomain on port $Port to trigger detection..." -ForegroundColor Cyan
  
  try {
      # We use a TCP client to simulate the connection attempt without needing a full web stack
      $TcpClient = New-Object System.Net.Sockets.TcpClient
      $Connect = $TcpClient.BeginConnect($TargetDomain, $Port, $null, $null)
      $Success = $Connect.AsyncWaitHandle.WaitOne(5000, $false)
  
      if ($Success) {
          Write-Host "Successfully established connection to $TargetDomain. Detection should trigger." -ForegroundColor Green
          $TcpClient.EndConnect($Connect)
          $TcpClient.Close()
      } else {
          Write-Host "Connection timed out. The domain might be offline, but the attempt should still be logged by the firewall." -ForegroundColor Yellow
      }
  } catch {
      Write-Host "Error occurred: $($_.Exception.Message)" -ForegroundColor Red
  }

• Cleanup Commands:

  # No persistent changes were made by the script. 
  # Simply ensure the TCP connection is closed (handled in script).
  Write-Host "Simulation cleanup complete. No artifacts left on host." -ForegroundColor Green