How WMI, CMD.exe and LOLbins Enable Stealthy Attacks

Waiting For The Right Time to Strike

The first indicators of trouble appeared on November 16^th, when multiple endpoints and servers triggered alerts for the presence of ransomware. In total, roughly 100 endpoints were encrypted, and the attackers demanded $6 million. The attack included key servers such as domain controllers, among other infected endpoints.

One of the crucial factors we observed on some servers that were completely encrypted was the lack of a fully functioning defense system. However, the team did manage to proactively shut down their production environment before Cynet and BugSec’s involvement, limiting the potential damage to only two units in the organization.

Our investigation revealed that the APT that initiated the attack was DopplePaymer. However, before diving deeper it’s worth going back in time to understand how the attacker gained entry into the system. This will let us track their footprints better, and show us that the attacker wasn’t a “script kiddie” having fun, but a well-prepared and advanced adversary.

Four days before the attack, a user from a third-party organization was able to access the company’s VPN for a short time before the account was disabled. The attacker was able to gain access to this external account and bide their time until November 12^th, when an opportunity presented itself. When the account was activated, the attacker made an RDP connection to the VPN server, and from there to one of the company’s internal servers (Server0). Once connected, he was able to drop the malicious content. It was interesting that they used Serve0’s local admin account to connect.

This method of infiltrating through the VPN with two users (one of which is usually disabled) in a limited time frame shows a high level of sophistication and targeting. Evidently, the threat actor did their homework ahead of time.

Time to Cash Out

The assumption is that in the four days between the first access and executing of ransomware, the Command & Control server of the attack was set up to be executed via the Startup folder, .lnk files, Run Keys, and Scheduled Tasks on user login (All those indicators were found on the infected servers and stations). On November 16 between 6:00 PM and 9:00 PM the attacker finally became overt, spreading the ransomwarer to multiple endpoints and activating it. The C&C file was executed (the file used to connect from the compromised hosts to the attacker’s C&C server), and the attacker could begin to reap the benefits of their efforts.

The below images show the setup of the attack. The first shows all the malicious files installed on 12/11/2020, and the second is after the service is created with Powershell Base64 encoded commands:

The adversary initiated the attack from an internal server (Server0) connected to the compromised VPN server and made a logon with a local administrator account. They used the tool PsExec from Sysinternals suite and made 98 connections to servers and workstations. PsExec is a tool that can be used to launch processes on a remote station, though user credentials are needed for that procedure.

What was interesting to see during the investigation is that the adversary used one account to connect to Server0 (the local administrator of that station), but used another user to actually spread the ransomware. We found that on Server0, the “Schema Admin” user made an interactive logon earlier that day, leaving their credentials in lsass.exe memory, and as you probably guessed, was dumped by the adversary.

So far, we saw only three compromised users, but further investigation uncovered that the attacker performed lateral movement (using RDP) in three other domains within the company, using additional account credentials that were probably stolen during the lateral movement or even before the attack. Morerover, they didn’t waste an opportunity to steal information and publish it later on the dark web.

Following an investigation on the file server, we consider it very likely that a large amount of data was exfiltrated. An internal user that was also compromised during the attack accessed hundreds of folders on the server on November 17 between 9:00 PM and 11:00 PM. Four Zip files were created on the server in that time, totalling a size of 7-8 GB. Furthermore, there is evidence that same user visited dropmefiles.com (a file uploading site) though there was no evidence they actually uploaded anything:

Another interesting finding is that on November 12, the attacker made a connection to Server0 using RDP from the VPN server. At that time, Server0 created a service that runs a PowerShell encoded command and visited an externall IP and URL. That day, the attacker also dropped the malicious content into Server0.

The day of the attack execution, the attacker connected to Server0 from an external IP, and the assumption is that the attacker set up the C&C file and infrastructure for the ransomware for four days. This way, when the attack was initiated, the attacker had “direct” access instead of having to log in through RDP.

A screenshot of the ransom payment page:

The lateral movement and timeline of the diagram:

Keys finding of the investigation

– The ransomware was a DLL that was side-loaded (hijacking the execution of a legitimate DLL to take advantage of the way Windows OS searches for and executes dependencies at runtime) through legitimate Windows executables. We found similar processes on every infected host.

– The spreading mechanism used a PsExec from Sysinternals suite. The ability to launch remote processes on stations in other domains was available to the attacker because of the trust relationships between the domains, which also allowed them to perform the movement from domain to domain.

– The attacker gained access to the third-party user, a local admin of Server0, and the “Schema Admin” user. The investigation’s findings led us to believe that they also gained access to seven additional users, including some administrator accounts.

– The attacker gained access to the third-party organization network before launching the attack on the company. As demonstrated in the figure above, the attacker gained access on November 11, dropped the malicious content, and actually launched the attack on November 16.
They knew and used the opportunity window where the third-party user was enabled.

– The company implemented two security products on their endpoints, Trend Micro Machine Learning and Symantec, although both were slightly misconfigured. The ransomware was able to encrypt the endpoints that had not implemented both of the security products. Even if one was enabled the endpoint was still encrypted.

From Encrypted to Better Secured

Cynet and BugSec supported both the investigation and remediation processes led by the company’s teams between November 20 and November 25. As part of the process, we took several actions:

• Separating users’ privileges
• Changing users’ passwords
• Disabling the access of the third-party organization (since they had an attacker in their network that time) until they cleared the attacker from their network
• Enabling MFA on users in the VPN server
• Removing and cleaning malicious files and other indicators of compromise from the servers and endpoints

Along with these immediate remediation actions (many of which you can implement now to reduce the likelihood of a successful attack) and longer-term solutions, every machine that returned to production had Cynet deployed on it.

We also highly recommend hardening any environment connected to the internet with awareness of existing security risks. Additionally, it’s useful to have a Red Team that understands your orgnaization’s security gaps.

As we’ve demonstrated, it’s not enough to simply detect static indicators or malicious files. It’s crucial to have heuristics detection that can alert and remediate automatically when adversaries abuse legitimate tools to evade detection, or when files alter other files’ extensions (such as when ransomware encrypts them, or when lsass.exe is used to dump user credentials).

Cynet enables any organization to put its cybersecurity on autopilot, streamlining and automating their entire security operations while providing enhanced levels of visibility and protection, regardless of the security team’s size, skill or resources and without the need for a multi-product security stack. It does so by natively consolidating the essential security technologies needed to provide organizations with comprehensive threat protection into a single, easy-to-use XDR platform; automating the manual process of investigation and remediation across the environment; and providing a 24-7 proactive MDR service – monitoring, investigation, on-demand analysis, incident response and threat hunting – at no additional cost.

Remember that attackers are willing to play a long game and go a long way to execute successful attacks. This means they’re willing to spend days, weeks, or even months, in your network slowly infiltrating the tools your system admin uses daily or other legitimate tools for their own purposes. Today, static detection simply isn’t enough.

Cynet360 VS PsExec

Watch how Cynet is able to detect and prevent remote execution of ransomware using PsExec:

Process Monitoring

This alert triggers when Cynet detects a suspicious process tree correlated wit suspicious command-line or is associated with malicious behaviour.

Malicious Binary

This alert triggers when Cynet detects a file that is flagged as malicious in Cynet’s EPS (endpoint scanner) built-in threat intelligence database. This database contains only critical IoCs (such as IOCs of ransomware, hacking tools, etc.).

Detection Engine – Malicious Binary – Infected File – Attempt to Run

The alert triggers when Cynet’s AV/AI engine detects a malicious file that was loaded to the memory

Memory Pattern

The alert triggers when Cynet’s AV/AI engine detects a malicious file that was loaded to the memory