Inspired by recent threat intelligence, I am starting a series on Remote Monitoring and Management (RMM) tools. I wanted start with some testing on ScreenConnect to support investigators who may have a victim device where a user has been tricked into giving control over to an attacker. We want to be able to answer questions like these:
- What can we find out about what happened?
- Was malware introduced?
- Was sensitive data lost?
Here is some obligatory background nonsense from JetPack AI:
ScreenConnect is a comprehensive remote access tool developed by ConnectWise. With its robust capabilities, ScreenConnect empowers users to securely and conveniently access and control remote computers, servers, and devices from anywhere in the world. Designed with simplicity and efficiency in mind, ScreenConnect facilitates seamless collaboration, troubleshooting, and support for IT professionals and businesses alike. Whether you need to assist a colleague, provide remote technical support, or access your work computer while on the go, ScreenConnect offers a reliable solution that ensures a seamless and secure remote access experience.
Testing Details
Testing was done with ScreenConnect agent version 23.4.5.8571 with the “victim” device being Windows10 v1709 (OS Build 16299.309). Telemetry used was
- Sysmon (with the Swift-on-Security config),
- PowerShell script block logging and transcripts were enabled.
- Noriben was used to automate Procmon output.
- Memory strings analysis performed with ProcessHacker.
Installation
After signing up for a 14-day free trial and setting up my account, they gave me a custom URL to sign into a web UI where I could manage my fleet of “victim” devices. I was able to create my own subdomain like so: “amskatoff.screenconnect.com”.
After clicking on the “Build+” button (located at the top left corner), I was prompted to build an installer and given several options for the target operating system. This was followed by options to download the executable file or share a link to it. The provided link was:
https://amskatoff.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
Once executed, the installer launched msiexec.exe and installed a service called “ScreenConnect Client (429d9ba6e9123fb4)” which pointed to C:\Program Files (x86)\ScreenConnect Client (429d9ba6e9123fb4)\ScreenConnect.ClientService.exe.
This file then spawned two instances of a child process called ScreenConnect.WindowsClient.exe one with my default credentials and another one running as System.
The service running as SYSTEM was also recorded in a 4573 event in the Security Log, indicating sensitive privilege use (SeTcbPrivilege).
The remote control session was immediately available through the host web interface. There was no prompt to give full control. A telling application log event occurred at this time, showing that I was now connected to the victim’s device.
A similar event was logged when the remote connection was severed.
An apparently randomly generated C2 domain (instance-bw7a3j-relay.screenconnect.com) was contacted over port 443 as part of this channel. Similar domain name patterns have been observed in threat intelligence reports.
Chatting
I was unable to find any logs of chat messages. However, my chat strings were found in memory.
File Transfers
Running an arbitrary exe on the client was trivial via the web UI. I was given the option to run elevated. At this time, a folder was created and my exe file was placed into it: C:\Users\REM\Documents\ConnectWiseControl\Temp\evil.exe. The file executed about a minute later. I killed the process, and the file disappeared from the folder shortly thereafter. Shortly after that, the “Temp” folder also vanished.
Sending a file to the client was performed via the host software. This activity created a new folder: C:\Users\REM\Documents\ConnectWiseControl\Files containing my file.
Additionally, the event was recorded in the Application log of the client device.
When pulling a file/folder from my victim machine, no event log entries were observed, but changes were observed in the config file found at C:\Users\REM\AppData\Local\ScreenConnect Client (429d9ba6e9123fb4)\user.config. This file appears to change quite a lot during active sessions.
During my test to pull an entire folder, the current (at the time) version of the file showed the following; telling us which folder was exfiltrated.
It is unfortunate that the file is so volatile since it holds important evidence that I couldn’t find elsewhere. Timestamp correlation with shellbags or carving the user.config files from disk and/or memory could be good next steps to find out which files/folders were taken.
Remote Administration
Numerous administration tasks are available to the host in the web console, such as:
- list/kill tasks
- list/manage services
- list/manage “updates”
- Review a selection of event logs.
My testing showed that each of these is accomplished through randomly named ps1 files which are executed with PowerShell as a child process of ScreenConnect.ClientService.exe as follows:
powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -File C:\WINDOWS\TEMP\ScreenConnect\23.4.5.8571\f5955c63-3955-4c4a-ba98-672d4d6291eerun.ps1With script block logging and PowerShell transcripts, we can see what information is being leaked to the host and what other actions were taken.
The ps1 launched by the “Updates” query left the following 4104 event in the powershell (Operational) log. A review of any other 4104 events where the path includes “ScreenConnect” would answer additional remaining questions about these sorts of remote admin diagnostic tasks.
It’s nice to know what kinds of data we may have lost to the attacker, but in the case of vulnerabilities, we might want to know the exact data that was spilled. EventID 4103 and/or our PowerShell transcripts will tell us that story. Here’s a sample of the transcript file for the “Updates” query which shows that the host is now aware I haven’t patched this client machine since 2018! Additional samples can be found here: psh_trasnscript_samples
A Summary of Indicators / TTPs
| TTP / IOCs | Analytic |
| Screenconnect service installed with a part of the name being randomly generated: “ScreenConnect Client (429d9ba6e9123fb4)” | source=system.evtx EventCode=7045 Message = “*ScreenConnect Cient (*)” |
| The service running as SYSTEM was also recorded in a 4573 event in the Security Log indicating Sensitive Privilege Use (SeTcbPrivilege) | source=system.evtx EventCode=4573 Message = “*ScreenConnect*” AND Message = “*SeTcbPrivilege*” |
| https://amskatoff.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest | Review EDR/Sysmon commandlines, DNS events, and/or, Proxy Logs for URLs with pattern like: http*.screenconnect.com/ Bin/ScreenConnect*.exe* |
| ScreenConnect.ClientService.exe | Filename indicator for use in reviewing process execution events. |
| ScreenConnect.WindowsClient.exe | Filename indicator for use in reviewing process execution events. |
| Cloud Account Administrator Connected | source=Application.evtx EventCode=100 Source=ScreenConnect Message=”*Cloud Account Administrator Connected*” |
| Cloud Account Administrator Disconnected | source=Application.evtx EventCode=101 Source=ScreenConnect Message=”Cloud Account Administrator Disconnected“ |
| C:\Users\REM\Documents\ConnectWiseControl\Temp | Execution of any PE from this directory indicates it was likely provided by the ScreenConnect host. |
| C:\Users\REM\Documents\ConnectWiseControl\Files | source=Application.evtx EventCode=201 Source=ScreenConnect Message=”*transfer*” |
| powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -File C:\WINDOWS\TEMP\ScreenConnect\23.4.5.8571\f5955c63-3955-4c4a-ba98-672d4d6291eerun.ps1 | Source=Microsoft-Windows-Powershell-Operational EventID 4103 Message=*screenConnect*.ps1* |
Additional Resources
Although this research was independent, after I started it, I noticed several other excellent resources online with similar information. If you want to delve deeper, check them out:
DRIF TNT | Digital Forensics | Incident Response | Tips and Tricks 
One thought on “RMM – ScreenConnect: Client-Side Evidence”