RMM – Action1: Client Side Evidence

Today we turn our attention to Action1 in this series on Remote Management and Monitoring (RMM) Tools. Action1 boasts patch management as a key capability they offer. However, threat actors are also using Action1 to establish footholds in victim organizations. Here is an example of a recently reported malicious Action1 installer where the threat actor has bundled their malware with an apparently legit MSI installation file. Once again, let’s examine Action1’s telemetry and forensic footprint to aid incident responders. Click here to skip straight to the IOCs and TTPs

1. Publisher
2. Capabilities
3. Testing Methodology
4. Installation
5. Persistence
6. Reconnaissance
7. Application Logs
8. Network
9. File System
10. Script/Command Execution
11. Remote Control
12. User Interaction
13. Data Exfil
14. IOCs and TTPs

Publisher

The agent software is signed by “Action 1 Corporation.” If you have a filename that matches what you expect from Action1, and it is not signed, it is likely malicious!

Capabilities

Action1 markets itself as a patch management tool, but it offers most of the basics of standard RMM tools:

• Hardware, OS, software inventory
• Remote security patch management (including third party software)
• Pre-selected software distribution/installation
• Remote Control, Reboot, etc.
• Arbitrary code/script execution

The free version allows up to 100 endpoint agents for free!

Testing Methodology

Testing was done with Xeox version 2.0.0.47 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.
• Manual process analysis performed with ProcessHacker.
• EvtxCmd and Timeline Explorer for event log review.

Installation

In the installation process, the account holder either provides a custom MSI installer or provides a URL an end user can use to pull down a copy of the custom installer. In my case, this was the custom URL:

https://app.action1.com/agent/2c40f624-30b6-11ee-85ae-a55fe9f288ad/Windows/agent(My_Organization).msi

During the installation a working directory was created containing the vast majority of the application files at C:\Windows\Action1\

The “logs” folder contains a simple yet verbose log file that keeps track of most operations. We will see later that select jobs sent to the client tend to create a second/similar log in the same folder.

During the installation, we can see that Powershell is heavily invoked. There is a pattern of *.ps1 files being sent, executed, and then deleted. We will see shortly that this is routine behavior and not just part of the installation.

One interesting file called “what_is_this.txt” was observed being created by the install.

Kudos to their team for the straight talk about how this could be used for good or evil.

• 

Persistence

The installer sets up up a service called “A1Agent” with system privileges pointing to a binary at C:\Windows\Action1\action1_agent.exe.

Reconnaissance

Without any action taken from the administrator side, the software begins collecting basic system information (e.g. OS, hardware, and software information) with PowerShell. While the associated ps1 files are deleted after use, the details of this activity are captured clearly within PowerShell transcript files.

Hardware
OS and Software
Environment Variables
Startup Programs
Routing Tables

If you don’t have PowerShell transcripts, similar information will also be found in PowerShell script block logging 4104 events.

Application Logs

Action1 does a great job logging it’s activities in it’s application log files, which captures (among many other things) the same information shown above in the PowerShell transcript logs). The location of these log files is C:\Windows\Action1\logs\ with filenames containing the timestamps of when they were created. Most activity is stored in this one log file.

The agent also logs certain errors to the windows Application log with EventCode==1.

Network

The agent appears to contact the RMM server roughly every two minutes with a “heartbeat” connection.

Action1_agent.exe appears in Sysmon EventCode==2 records for DNS requests to server.action1.com which returns an IP of 54.210.188.13 and 54.227.102.112 and an alias record status for “a1-server-prod-odd.action1.com”

File System

The filesystem/folders it creates at C:\Windows\Action1\ include a “Scripts” folder which serves as a temporary working space for script files. A review of file creation activity within this folder gives us an idea of the additional recon activities performed based on the names of the *.ps1 files.

Script/Command Execution

I could not use the remote script/command execution options without a verified account. Since they don’t accept noncorporate emails, I was stuck. I emailed them to ask for a workaround since I was doing research not affiliated with my employer. But they were unwilling to work with me.

Arbitrary Execution

However, lucky for us, some malicious threat actor was able to use Action1 to deploy malware to a victim host. Credit to the @Kostastsale of the fantastic @TheDFIRRepot for reporting the details we need for his part of the report. His full tweet thread is here.

As illustrated below, we should see a folder created under “C:\Windows\Action1\package_downloads\” with a binary executable inside. Using standard “evidence of execution” investigative techniques will easily detect this activity.

The behavior observed when the admin launches PowerShell or CMD commands and scripts is captured below:

^{Note: As I seem to have experienced, Action1 seems to have put in additional protections following this abuse.}

Enumerate open TCP sessions

I ran one of the built-in scripts to enumerate open TCP sessions to external IP addresses. During this process I observed the following process lineage: action1_agent.exe -> powershell.exe -> nslookup.exe.

Disable the windows firewall

I ran a pre-built job to disable the windows firewall which ran successfully.

This created a new *.log file in the logs directory. Several files and folders were also created to support his action as illustrated in the Noriben/procmon output below.

The log filename contains a timestamp indicating when the logging started. This correlates nicely with the MFT timestamps as well as the first line in the log file itself.

Deploy from “App Store”

I also tested deploying a software install package (Splashtop Streamer) from their “app store.” This also created a new log file in the logs directory.

Remote Control

After the user allows the Action1 admin to remote into the client machine, the action1_agent.exe process spawned three instances of action1_remote.exe, as seen below:

The timestamp of the execution of action1_remote.exe can serve investigators well to determine when this happened. But it is also recorded in the main log file.

From these events we can see that the software is using WMI to collect screen and monitoring information. This is corroborated by correlating events in the WMI logs (Microsoft-Windows-WMI-Activity/Operational.evtx).

We also will see this command line in process execution events:

CommandLine: "C:\WINDOWS\Action1\action1_agent.exe" monitorcount

Closing the session is not possible from the user side (aside from taskkill operations). It appears the only way to end the session is to simply close the browser window, returning you back to the previous tab with the admin console.

The session appears to be using some amount of VNC code perform this remote control capability. This is evident in the log file during the time the session is closed.

User Interaction

Upon initiating a remote view/control session, the user on the client device would see a popup message like this one:

Data Exfil

Apart from arbitrary script execution, I didn’t see a web GUI capability to pull files off the client device.

IOCs and TTPs

TTP/IOC	Description
https://app.action1.com/agent/*/Windows/agent(*).msi	URL to a downloadable MSI installer
Sysmon eventCode=1 c:\windows\action1\action1_agent.exe	Evidence of execution. The PE is designed to run as a service, so source=system.evtx EventCode=7045 could also be used.
action1_agent.exe -> powershell.exe -> nslookup.exe	nslookup as the grandchild process of action1_agent.exe suggests admin directed recon of open network sessions with external IPs.
Sysmon eventCode=1 action1_remote.exe	Evidence of action1 being used for remote control.
server.action1.com a1-server-prod-odd.action1.com us-cdn.action1.com	Domain IOCs
54.210.188.13 54.227.102.112	IP IOCs