Varonis recently helped a customer who observed a spike in CPU activity on a server in their environment, where a shallow review of the device revealed an in-progress compromise by an advanced threat actor we later attributed to RansomHub affiliates.
Over the next 48 hours, our team worked closely with the customer to investigate, hunt, contain, and remediate the threat before it could become ransomware.
Due to our team’s advanced intervention capabilities, we secured the customer’s network with zero business downtime. Continue reading to see how the incident started.
Initial Access
The incident started when a user downloaded and subsequently executed a file that they were led to believe was a legitimate browser update. In this case, it was a malicious JavaScript payload.
The download kicked off a chain of automated reconnaissance and initial command and control activity, including enumerating Active Directory users and computers, querying key local system information, hunting for credentials in memory, and various other discovery techniques.
Within minutes, second-stage malware was deployed as a recurring Scheduled Task for persistence. Following this, a legitimate Python distribution was downloaded to % LOCALAPPDATA%ConnectedDevicesPlatform, along with an encrypted Python script that served as a SOCKS proxy with attacker infrastructure, exposing the corporate network directly over the Internet.
The encrypted script was protected by an unpacking routine consisting of 10 layers of multi-stage encryption, with each stage unpacking the next along with other components.
Each level of the decryption process had randomized variable names designed to thwart unpacking attempts. Additionally, each stage attempted to implement basic anti-analysis techniques, including VM detection, Debug detection, and Process Tracing detection.
Our team wrote an unpacking routine for this specific variant to assist us in retrieving the final payload in plaintext. If you are a Varonis customer and need help with this task, please contact our IR team.
The final payload was a SOCKS proxy designed to facilitate communication between attacker endpoints and internal network infrastructure using the compromised host as a transport pivot.
Additionally, our forensics team noted that this TA was manipulating all email signatures stored at $env:APPDATAMicrosoftSignatures by embedding a malicious image reference at the end.
This type of change would go unnoticed by end users. Still, it could potentially be used on vulnerable clients to coerce an NTLM authentication attempt and result in additional credential harvesting.
Our team analyzed data from 1,000 real-world IT environments and found that no organization was breach-proof.
In fact, 99% of organizations have exposed sensitive data that can easily be surfaced by AI.
Read the report
Discovery
After initially compromising the endpoint, the adversary immediately began hunting for credentials and privilege escalation opportunities in the customer’s network. This included scanning network shares for credential-containing material such as RDP/. As shown below, OVPN files, KeePass Vaults, and other extensions or file names commonly contain authentication data.
The above command was launched against all network shares attached to the device as part of an automatic recon stage by the malware. In addition, the threat attempted to identify credentials stored in browsers by analyzing local state databases for Chrome and Edge. The snippet below demonstrates their attempts to use Data Protection API (DPAPI) to decrypt passwords stored in the browsers from files, including:
- $env:LOCALAPPDATA(Google|Microsoft)(Chrome|Edge)User DataDefaultLogin Data
- $env:LOCALAPPDATA(Google|Microsoft)(Chrome|Edge)\User DataLocal State
Privilege Escalation
At this point, the threat had direct network access to the environment through a network tunnel and direct command of the initially compromised device. Our analysis determined that the attacker began controlling a Domain Admin account approximately four hours after the initial breach.
In addition to hunting across the network to identify compromised devices, we investigated exactly how this privilege escalation occurred to lock down any misconfigurations or weakened posture areas.
Approximately two hours after the initial compromise, this customer’s ADFS account was observed authenticating from the compromised workstation into a read-only Domain Controller, where it subsequently had administrative privileges, indicated by the Elevated Token parameter inside the related 4624 authentication event.
This logon session also possessed the SeTcbPrivilege privilege assignment, a hazardous role that allows the grantee to impersonate any other user in the environment, including Domain Admins or SYSTEM.
Shortly thereafter, we observed the threat beginning to abuse multiple Domain Admin accounts. Due to limited telemetry, we could not pinpoint the exact escalation method.
We did perform an audit on the customers’ Active Directory environment and identified a few key issues that would have provided an attack surface for escalation.
Key among our findings were misconfigured certificates in Certificate Services (AD CS) that would have allowed privilege escalation via ESC1. Misconfigured AD CS is extremely dangerous as it often allows regular users to escalate privileges to the Domain Administrator with little resistance.
We believe the threat actor recognized this and exploited the configuration error to obtain access to multiple high-privileged accounts, including Domain Admin users. This rapid escalation from regular user to administrator occurred less than four hours after the initial click of a malicious file, demonstrating the need to act as soon as possible when threats are detected.
Additional Discovery
Once the attacker had privileges, they embarked on an exploration journey throughout the network. One of the first things they did was target laptops belonging to domain admins. To do this, they ensured that RDP was enabled and allowed on the relevant machines through remote service and registry interaction. Then, they interactively accessed the device after ensuring no one else was logged on, as demonstrated below.
The threat actor also abused reg.exe and netsh.exe to configure appropriate registry settings to allow remote connections and ensure that port 3389 was open on targeted devices. Following this, quser was used to check for logged-in users.
Once it was determined that a device was not in use, the TA deployed additional information and credential gathering scripts in a batch file on endpoints. These scripts were immediately deleted following execution, as shown below.
In addition to standard discovery techniques such as the abuse of ping, nltest, net, qwinsta, etc, the threat also did something we found surprising — they used installed copies of Word, Visio, and Excel to open specific files of interest about the internal architecture, networking, and server environments of the client.
We found this unique because this type of data is typically taken offline for analysis. Still, this threat actor opened the files from compromised servers with Microsoft Office utilities installed, giving us high visibility into their motivations and processes.
Examples of files opened included:
- ESXi Host Cheat Sheets
- Azure VM Networking Solutions
- Server Readmes
- General information about client architecture/databases
The activity was deliberate and targeted and is just one example of the lengths threat actors will go. Monitoring data access is critical for any company’s security posture and risk appetite.
Data Exfiltration
Approximately 24 hours after the initial compromise, the attacker had successfully obtained Domain Admin, deployed multiple persistence mechanisms throughout the environment, enumerated almost the entire Active Directory, and performed extensive network and file discovery.
Satisfied with their progress, the threat deployed AzCopy, a Microsoft Azure Storage Account interaction utility. As shown below, the threat used this to achieve mass data exfiltration across a few targeted directories..
On average, this user read 1k files per day, and on the day of exfiltration, nearly 270k, generating corresponding alerts in Varonis
The exfiltration activity caused the initial CPU spike and drew the customer’s attention. Shortly afterwards, our team identified the threat’s persistence mechanism and associated IOCs and organized a joint cut-off with the customer to ensure all malicious access was simultaneously severed across the network. This gave the customer breathing room for remediation and ensured the threat did not evolve into ransomware.
Our analysis of the tactics, techniques, and procedures (TTPs) and the relevant Indicators of Compromise (IOCs) tied this intrusion to affiliates of the RansomHub group utilizing SocGhoulish malware for initial access activities.
Fortunately, our intervention services were able to help this customer completely eradicate the threat with zero business downtime. Had this gone unnoticed for even a few hours longer, ransomware would likely have been deployed across the customer’s environment.
Sponsored and written by Varonis.