In-Memory Loader Drops ScreenConnect

Summary

ThreatLabz identified a multi-stage attack chain that starts with a fake Adobe Acrobat Reader download and culminates in the deployment of the legitimate remote access tool ScreenConnect. The operation relies on a heavily obfuscated VBScript loader that triggers a PowerShell command to fetch C# source code from Google Drive, compile it directly in memory, and launch a .NET loader without dropping the final payload to disk. That loader then applies process masquerading, alters PEB structures, and abuses auto-elevated COM objects to obtain higher privileges before installing ScreenConnect on the victim host.

Investigation

Researchers outlined how the VBScript assembles its commands through Chr() obfuscation, while PowerShell retrieves and compiles the payload entirely in memory to minimize disk artifacts. The in-memory .NET loader then uses reflection to execute an embedded assembly. Additional analysis showed the malware calling NtAllocateVirtualMemory, rewriting PEB fields to impersonate winhlp32.exe, and leveraging COM auto-elevation to bypass User Account Control and continue execution with elevated privileges.

Mitigation

Defenders should block access to the malicious download domains and apply strict controls to PowerShell and VBScript execution. Security teams should also monitor for suspicious COM object creation, unexpected PEB tampering, and other signs of in-memory execution abuse. Access to legitimate remote administration tools such as ScreenConnect should be tightly limited to approved users and trusted workflows to reduce the risk of unauthorized installation.

Response

If this activity is detected, isolate the affected system immediately, stop the malicious processes, and remove any ScreenConnect components installed as part of the intrusion. Perform forensic analysis focused on volatile memory artifacts to recover evidence of the fileless execution chain. Reset potentially exposed credentials, review logs for COM auto-elevation abuse, and update detections to identify the observed command-line patterns, loader behavior, and associated file naming conventions.

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.

• Attack Narrative & Commands:
  The adversary has obtained the ScreenConnect MSI (often delivered via phishing attachment). To avoid user interaction, they use the trusted msiexec.exe binary to perform a silent install. They also demonstrate the alternative ShellExec.exe proxy, which simply forwards arguments to msiexec. Both commands embed the literal string “ScreenConnect” in the command line, satisfying the rule’s condition.

  1. Copy the MSI to the victim host (simulating T1025).

  2. Execute a silent install via msiexec:

      msiexec.exe /i "C:TempScreenConnect.msi" /quiet /norestart

  3. Execute the same installation via ShellExec.exe (if present on the host):

      ShellExec.exe /i "C:TempScreenConnect.msi" /quiet /norestart

  These actions generate Windows Event 4688 entries where Image is *\msiexec.exe or *\ShellExec.exe and CommandLine contains “ScreenConnect”, causing the Sigma rule to fire.

• Regression Test Script:

  #=============================================================
  # ScreenConnect Installation Simulation – triggers Sigma rule
  #=============================================================
  $msiPath = "C:TempScreenConnect.msi"
  
  # Ensure the MSI exists (placeholder – in a real test, drop the file first)
  if (-Not (Test-Path $msiPath)) {
      Write-Error "ScreenConnect MSI not found at $msiPath"
      exit 1
  }
  
  # 1. Silent install using msiexec
  Write-Host "[*] Installing ScreenConnect via msiexec..."
  Start-Process -FilePath "$env:SystemRootSystem32msiexec.exe" `
                -ArgumentList "/i `"$msiPath`" /quiet /norestart" `
                -Wait -NoNewWindow
  
  # 2. Silent install using ShellExec (if present)
  $shellExec = "$env:ProgramFilesScreenConnectShellExec.exe"
  if (Test-Path $shellExec) {
      Write-Host "[*] Installing ScreenConnect via ShellExec..."
      Start-Process -FilePath $shellExec `
                    -ArgumentList "/i `"$msiPath`" /quiet /norestart" `
                    -Wait -NoNewWindow
  } else {
      Write-Warning "ShellExec.exe not found; skipping second install."
  }
  
  Write-Host "[+] Simulation complete. Check your SIEM for the Alert."

• Cleanup Commands:

  # Uninstall ScreenConnect (uses its registered product GUID; adjust as needed)
  $productGuid = (Get-ItemProperty "HKLM:SoftwareMicrosoftWindowsCurrentVersionUninstall*" |
                  Where-Object { $_.DisplayName -like "*ScreenConnect*" }).PSChildName
  
  if ($productGuid) {
      Write-Host "[*] Uninstalling ScreenConnect (GUID: $productGuid)..."
      & "$env:SystemRootSystem32msiexec.exe" /x $productGuid /quiet /norestart
  } else {
      Write-Warning "ScreenConnect product GUID not found; manual cleanup may be required."
  }
  
  # Remove the copied MSI file
  Remove-Item -Path "C:TempScreenConnect.msi" -Force -ErrorAction SilentlyContinue
  Write-Host "[+] Cleanup completed."