Author: Matan Haim Guez
Most people will remember 2020 as the year of COVID-19 and the shift to remote work, but beneath the surface there are other reasons for infamy. For one, 2020 also saw a sharp spike in the number of global cyber-attacks, as attackers apparently were thrilled at the idea of remote workforces. This sharp increase led to the development of new attack techniques that were able to slip undetected by security products, forcing cyber security organizations to continue evolving much faster.
One of the most common attack tactics deployed by malicious actors in the past year was the use of legitimate OS tools such as PowerShell, VBA, mshta, PsExec, and more along with malicious files like Emotet and TrickBot to deliver real payloads (ransomware, malware, banking trojans) while evading security products. Cynet uncovered and deeply researched many of these tactics (you can read more here).
In November 2020, we received a request from a company that was not a customer of Cynet to handle a ransomware incident. Roughly 100 of their endpoints had been encrypted by a ransomware attack spread by a sophisticated adversary. The attacker first gained access to the company’s internal network through a user from a third-party organization connected to the company’s VPN server. The ransomware then spread from the inside using stolen user credentials, the endpoints’ own OS tools, timing, and patience.
The first indicators of trouble appeared on November 16th, 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 which 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 prior to 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 12th, 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.
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:
– 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:
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.
Watch how Cynet is able to detect and prevent remote execution of ransomware using PsExec:
This alert triggers when Cynet detects a suspicious process tree correlated wit suspicious command-line or is associated with malicious behaviour.
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
The alert triggers when Cynet’s AV/AI engine detects a malicious file that was loaded to the memory