In mid-June, Huntress saw an incident where a threat actor compromised an MSP’s Remote Monitoring and Management (RMM) tool in an attempt to target three of its customers. While the Huntress Security Operations Center (SOC) was able to isolate the impacted customer endpoints and work with the partner, we outlined how this attack is indicative of threat actors targeting MSP RMMs to remotely and quietly access customer endpoints.
After this initial incident occurred, we saw more incidents crop up that showed notable similarities to this one. In one of the more recent incidents, a Huntress agent was installed for a separate MSP mid-compromise. In this attack, which played out between June 23 and 25, the threat actors also targeted the MSP’s Atera RMM instance and deployed Cloudflare tunnels, as we had seen in the previous incident. The threat actors used the same account ID in their tunnel tokens as well.
One notable difference here is that the threat actors in this incident were able to get farther along in their attack: they succeeded in deploying Akira ransomware on some endpoints. The Huntress agent was installed after the initial compromise and ransomware deployment, so there were no ransomware canary reports, and endpoint detection and response (EDR) telemetry was not available until after the Huntress agent was installed.
As a result, definitively correlating the observed activity to the threat actor’s use of the partner’s Atera RMM instance fell to log analysis. Both incidents show how MSP RMM instances can allow threat actors to hit multiple companies in one attack by targeting MSPs’ downstream customers—in this case, with Akira ransomware.
The Huntress agent was installed mid-compromise after a slew of incidents on June 23 and June 24 set off managed antivirus (MAV) alerts for the Akira ransomware. During the initial stages of the agent deployment, four endpoints from the MSP were impacted—one from the MSP itself, and three from the MSP’s customers.
As seen in Figure 1 below, the endpoints had varying types of activities across them; some had Cloudflare tunnels installed, while others had ransomware (successfully) deployed, as indicated by MAV detection. On others, the threat actor had disabled Windows Defender after it detected and quarantined its initial attempt to deploy the ransomware.
This disparity of activity across impacted endpoints reinforces that the Huntress agent was deployed mid-compromise, while the threat actor was in the process of spreading out across the MSP’s customer base. Thanks to the lightning-fast response by the SOC, Tactical Response, and Support teams, Huntress was able to obviate the threat actor reaching further into the MSP’s customer base, severely limiting their impact.
As seen above, on “Endpoint 1,” threat actors were not able to deploy the Akira ransomware successfully—MAV caught and quarantined the ransomware attempt. Closer inspection of the Windows Event Logs showed a Cloudflare tunnel being created and run on June 23, as seen in the following System Event Log record:
Service Control Manager/7045C:\Windows\system32\cloudflared.exe tunnel run --token [REDACTED]
The Windows service or “autorun” detected by the Huntress platform is illustrated in Figure 2.
An account named bck was created shortly thereafter; then, on June 24 at 08:06 UTC the bck account accessed the endpoint, apparently via Remote Desktop Protocol (RDP), as seen in the following progression of Windows Event Log entries:
Microsoft-Windows-Security-Auditing/4624
Microsoft-Windows-TerminalServices-RemoteConnectionManager/1149
Microsoft-Windows-TerminalServices-LocalSessionManager/40
Microsoft-Windows-TerminalServices-LocalSessionManager/25
Notably, these log entries all included the source IP address 127.0.0.1 (localhost), which is a telltale sign that an RMM or some other means of remote access (besides RDP specifically) was used. The workstation name from which the authentication had originated had also been observed during the previous incident highlighted in our previous blog.
At 08:23 UTC, Windows Defender then detected and blocked an attempt to deploy Akira. At 08:24 UTC, a Microsoft-Windows-Windows Defender/5001 message indicated that Windows Defender Real-Time Protection (RTP) had been disabled. Then, about 35 minutes later, the bck account started running advanced_port_scanner.exe in order to map the network.
For this endpoint, Atera activity logs provided by the customer illustrated a connection to the endpoint, and the Security Event Log retrieved from the endpoint demonstrated the adm1 account was created. Logs further illustrated that the following day, the adm1 account was used to access the endpoint via RDP from another customer endpoint, one to which the Huntress agent had not been deployed. Shortly after the login, Windows Defender Event Log messages indicated that the ransomware executable, C:\ProgramData\akira.ex_, was detected and successfully quarantined.
Six seconds later, Windows Defender RTP was disabled, and the following PowerShell code was visible in Windows Event Logs, indicating the successful launch of the Akira ransomware executable:
powershell.exe -Command Get-WmiObject Win32_Shadowcopy , Remove-WmiObject
This was immediately followed by numerous Microsoft-Windows-RestartManager event records, which have been associated with the successful launch of the Akira ransomware executable.
Activity on this endpoint began on June 23 with a connection via the Atera RMM, illustrated in Atera activity logs provided by the customer. This was followed by a user account password being changed. Less than a minute later, Cloudflare was installed, and two and a half hours after the installation was complete, the modified user account was used to log into the endpoint briefly via RDP over the Cloudflare tunnel, apparently to test the connection. No other activity was observed on this endpoint.
Similar to the third endpoint, activity on this endpoint began with a connection via Atera; in this instance, Cloudflare was installed and then a user account password was changed. Then, about two hours and 10 minutes later, there was a brief connection via the Cloudflare tunnel, again, apparently to check the connection. No other activity was observed on this endpoint.
As we saw with the incident addressed in the first part of this blog series, the initial access vector for this more recent incident was determined to be the MSP’s Atera RMM instances.
However, there were some differences. For the previous incident outlined in our first part, we were able to rely on EDR telemetry to clearly illustrate the threat actor access to endpoints via the RMM (as seen in Figure 4 below).
For the attack addressed in this blog post, the Huntress agent was deployed mid-incident; as a result, artifacts such as encrypted canary files or EDR telemetry were not available. Instead, when we pieced the incident together, we relied solely on log files retrieved from the endpoints. In this incident, the MSP was also able to provide log data demonstrating access to their Atera RMM instance, and Huntress analysts were able to correlate this data with log data tasked from the endpoints.
In the more recent incident, “toolmarks” left in the Windows Event Logs on the impacted endpoints provided a clear view of the threat actor’s activities. These included service installation events for Cloudflare tunnels, PowerShell artifacts, Windows Defender detections, and evidence of the application being disabled, as well as “toolmarks” associated with the successful launch of the Akira ransomware executable.
Cloudflare tunnel token account tags and threat actor workstation names were common factors across both incidents, demonstrating extremely similar sets of tactics, techniques, and procedures (TTPs) alongside identical indicators of compromise (IOCs).
During the first week of July, the Huntress SOC began reporting a third attack where, again, the partner Atera RMM instance was identified as the source of the activity detected across multiple customer endpoints. This third attack was identical to the previous incidents in the following ways:
On one endpoint, Windows Defender was disabled after initially detecting and quarantining the Akira executable, which was successfully launched a short time later. Then, a regularly scheduled Windows Defender Quick Scan detected and quarantined the executable a second time.
Figure 5 illustrates the process lineage observed during this incident, which is identical to what was observed during the first incident (highlighted in Figure 4).
The Huntress SOC promptly responded after the installation of the Cloudflare tunnels and Windows Defender’s detection of initial attempts to deploy Akira ransomware. The SOC isolated endpoints and notified the MSP of the Atera RMM starting point, interrupting the threat actor’s efforts and obviating the remaining attack.
Due to the widespread impact that these types of incidents can incur, threat actors will continue to target MSPs to hit their customers. As we outlined in our previous post, MSPs can take several measures to secure their RMM tools and the RMM instances installed in customer environments. These steps include creating application controls that cover RMMs, reviewing logs for instances where RMMs were executed, and auditing remote access tools to keep tabs on potentially unauthorized instances.
Want to learn more about threat actor tradecraft like RMM abuse? Join our team each month for Tradecraft Tuesday, where we dissect hacker techniques, talk tech, and more.
Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.
