Bloodhounds are dogs prized for their ability to sniff out targets. Towards the end of April 2023, ReliaQuest turned the tables when we picked up on suspicious activity that suggested the use of Bloodhound—a tool for analysis of Active Directory (AD) rights and relations.
GreyMatter Intelligent Analysis enabled us to escalate an initial summary of events to the targeted client, a manufacturing company (“KILO-32325”), within 15 minutes. The company confirmed the activity was suspicious and then engaged the ReliaQuest Threat Hunting team, a specialized unit under our Threat Research Team.
About three weeks later, despite KILO-32325’s efforts to contain the intrusion, we detected a remote interactive login to a service account intended for Windows Virtual Machine Management on a licensed server. At this point, we re-engaged with the client. Let’s follow the trail of evidence that has led us to attribute this intrusion to a state-sponsored group operating in the interest of the People’s Republic of China (PRC).
Mining Data, Missing Malware: What Happened and Why?
What we discovered, and what we didn’t, provided a wealth of insight into the motivation behind this intrusion. Financially motived threat actors—particularly those focused on single or double extortion via ransomware and data theft—often operate in broad strokes. They aim to discover and exfiltrate, or at least impact, all data located on file servers, network shares, SharePoint sites, etc. During this intrusion, the threat actor focused on targeted exfiltration of research-and-development data, initially targeting documents about IT configurations and network topology, most likely for additional discovery.
What’s more revealing is that, despite having about a month of network and critical-infrastructure access, the threat actor didn’t deploy ransomware—or any malware at all. By matching those insights with the fact that our Threat Intelligence team has not (so far) discovered initial access broker listings, exposed credentials, or data sales related to this intrusion, we’ve arrived at the highly likely conclusion that espionage was the objective.
As April 2023 wound down, the threat actor appears to have used a combination of tactics to gain initial access to KILO-32325’s environment: two attacks, password guessing, and vulnerability exploitation. Notably, they first successfully authenticated to KILO-32325’s firewall using a local firewall account. KILO-32325 believes that a vulnerability in their FortiGate firewall was exploited for initial access.
Following authentication to the local firewall account, the threat actor moved on to try authenticating to a service account intended for backups 20 times in two minutes, striking out on each attempt. That seems to be the end of their password guessing for the backup account.
Two days later, we observed the backup account
KILO-32325-backup successfully authenticating to make use of Microsoft O365 services. On the same day, a VPN authentication was established using the local firewall account which was followed by the usage of a second service account,
KILO-32325-change, in a remote interactive login onto a domain controller. Both the O365 and VPN network access was most likely accomplished through offline password cracking or the use of already obtained valid credentials.
Fast-forward to about two weeks after initial access. A second, local firewall account was authenticated to from the threat actor’s IP address
96.70.174[.]189. This was a patched firewall, so it’s not clear if this account was acquired during initial access in April through exploitation of the firewall or was the result of additional vulnerability exploitation. But it wasn’t until mid-May that the threat actor again authenticated to the VPN with a new account,
After authenticating to the VPN using
admin@[KILO-32325].com, the attacker then performed a remote interactive login to a license server, using a different highly privileged service account that was intended for Windows virtual machine management. We didn’t see any password guessing for either of these accounts, which lends support to the theory that the threat actor probably relied on offline password cracking and valid credentials.
In total, the threat actor used four service accounts, including an additional database service account obtained after first initial access, and two local firewall accounts for network edge access. All authentications came from the IP address
96.70.174[.]189, a Comcast Business IP address leased to a SOHO Fortinet router with an exposed management console.
Where was the MFA?
You’re probably wondering why an MFA tool didn’t factor into the initial-access story. KILO-32325 did have an MFA solution, which included all the affected domain accounts used in VPN authentications. But because each of them were service accounts and not used interactively, they hadn’t been manually validated and set up with MFA. When MFA is deployed across an organization but edge cases exist, you can see how a false sense of security might settle in.
Discovery and Lateral Movement
Over about one month of access, the threat actor focused primarily on Living off the Land (LotL) commands, to blend into KILO-32325’s environment. They employed RDP for lateral movement and actions on objectives.
During April 2023, using the privileged
KILO-32325-change account, as well as a compromised database service account,
KILO-32325-sql, the threat actor conducted a wide range of host and account discovery actions, including the Bloodhound-like Lightweight Directory Access Protocol (LDAP) enumeration. The threat actor primarily conducted data discovery through SharePoint interaction. Data exfiltration was staged on the file server
KILO-32325-FS-01. All files that the attacker viewed, downloaded, and accessed were related to operations and research and development, plus VPN and FortiClient configurations.
In May 2023, when the threat actor re-entered the environment, their activity featured the same tools and patterns; data discovery was again centered on SharePoint, and data exfiltration was staged on a second file server,
KILO-32325-FS-02. Here are tools/commands they used for host and network discovery:
- Opening Computer Management and DNS Manager Snap-ins
view \\<IP ADDRESS >
use \\<IP ADDRESS >
group “domain computers” /domain
dsquery subnet -limit 10000
- This was used against numerous CIDR ranges after “dsquery” was run
Ingress Tool Transfer
The threat actor additionally transferred tools into the environment for further discovery and stored it within the Downloads folder of the
KILO-32325-change account. These tools were used against groups and users, probably for enumeration. Batch scripts were also interactively written to the disk via notepad.exe, potentially to avoid security measures (e.g., Mark-of-the-Web) that restrict the execution of untrusted content from the internet.
Here’s a sample of the tools and their usage:
“local administrators \\<IP>”
global.exe “domain computers”
Figure 1: Screenshot of
global.exe "domain computers" output captured in a file named 1.txt
Through partial-file analysis, we determined that the tool
getu.exe was a renamed version of a free JoeWare utility. We determined that it was likely GetUserInfo, based on observed use that matched documented usage syntax.
Finally, command lines like the examples below indicate the threat actor was using the Impacket script wmiexec, a tool known to be used by financially motivated actors as well as state-sponsored actors, for executing remote commands.
cmd.exe /Q /c quser 1> \\127.0.0.1\ADMIN$\__1684228650.2245219 2>&1
cmd.exe /Q /c cd \ 1> \\127.0.0.1\ADMIN$\__1684228650.2245219 2>&1
During April 2023, the actor had used
ntdsutil.exe to create a snapshot of the AD database, then dumped the
HKLM/SYSTEM hive using the
reg save command. Using
ntdsutil.exe to acquire an
NTDS.dit file led to the exposure of more than 1,200 domain accounts.
The threat actor also harvested plaintext passwords for local administrator accounts for all servers and computers managed by the LAPS (Local Administrator Password Solution) used to manage local account passwords on domain joined computers. As this data is in
NTDS.dit all local administrator accounts were considered compromised, in addition to the more sensitive privileged domain accounts.
Figure 2: Command used to create an
While blocked exploitation attempts for
CVE-2020-1472 were detected against several domain controllers, successful privilege escalation appears to have been achieved through valid account usage. Following LAPS credential exposure after an
NTDS.dit dump, a local administrator account,
KILO-32325-IT, ran Impacket WMIexec commands on different hosts; this points to the use of plaintext administrator passwords exposed in the LAPS file.
What’s more, as access was re-obtained in May 2023 via a highly privileged account, credentials for that account probably came from the exposed
NTDS.dit. But regardless, given the privilege of the accounts initially compromised, the threat actor had the requisite permissions to realize most of their goals even without additional escalation.
Staging for Data Exfiltration
During April 2023, the threat actor was observed using WinRAR, masquerading as
sap.exe, to stage data on
KILO-32325-FS-01 within the
D:\ drive. Like some of the discovery tools, this utility was brought into the environment by the threat actor tool and initially stored in the Downloads folder of the
KILO-32325-change account before being relocated to the
D:\ drive on the file server. Targeted data included spreadsheets detailing production instructions for stable operations and reports on production metrics, which were staged using the following command line.
SAP.exe a d:\APPS\<filename>.rar -k -r -s -v512m -hp<passwordhere> d:\<foldername >
After the threat actor reauthenticated to the environment, they targeted
KILO-32325-FS-02. To archive and encrypt data using the password “
Justx9ajsa,” they used WinRAR, masquerading as
dell.exe, located in:
In this instance, the threat actor used the existing Dell updatepackage folder to hide their renamed WinRAR, and archived data remotely through the UNC path. Remember how we observed the threat actor using notepad.exe to interactively write BATCH scripts to disk? Many of those were deleted, but we found that the following file path executed the archiving by calling
That process also saved output to the file path…
…with the command line:
dell a qa.rar -k -r -s -v1024m -x*.hst -x*.dat -m1 -hpJustx9ajsa \\ KILO-32325-FS-02\Folder1\Folder2 >> .\1.txt
WinRAR was also renamed as
citrix.exe but we didn’t discern any use attached to that name.
We didn’t detect any evidence of endpoint persistence, such as scheduled task creations, service installations, or network configuration changes. In all cases, access to the domain was achieved through valid accounts.
A new MFA device was seen being enrolled for
admin@[KILO-32325].com, as well as
KILO-32325-backup. As we said earlier, this doesn’t seem to show explicit persistence, but rather a requirement to use the account.
Throughout the intrusion, the threat actor deleted Windows event logs to avoid detection through interactive use of Event Viewer during RDP sessions. They also frequently deleted their tools and batch scripts, such as
dell.exe (WinRAR) and
global.exe (enumeration utility), to shrink their footprint.
This paid off in April 2023, as some of the compromised hosts were not forwarding Windows logs and did not have functioning EDR agents. By May 2023,
KILO-32325 had expanded EDR coverage to all hosts and additionally rectified logging gaps, drastically improving detection and available telemetry.
Figure 3: Screenshot from GreyMatter showing cleared audit log events correlated with Event Viewer
Impact and C2
Despite the visibility gaps, no malware or command-and-control (C2) implants seemed present at any stage of the intrusion. When you consider that the threat actor maintained access to the environment for nearly a month, all signs point to a non-financially motivated threat actor. Their actions were centered almost exclusively on data discovery, exfiltration, and gathering credentials, suggesting espionage as a motive.
Trail of Cyber-crumbs: Attributing the Attack
Adding up all the above factors, including privileged knowledge of the data targeted staged for exfiltration, we’re highly confident that the threat actor was operating in the interest of the PRC. The tactics, techniques, and procedures (TTPs) and victim entity echo those of attack campaigns carried out by an actor or actors acting in the interest of the PRC. Although we can’t attribute this intrusion to a specific group, let’s talk through the evidence we have.
Consider the TTPs; initial access stemming from a likely compromised SOHO Fortinet router, a focus on VPN and firewall compromise, password spraying, and use of valid accounts are all known are all known to be used and preferred techniques used by actors backed by the PRC. And post-access, the focus on LotL activity, log clearing, and password-protected archives are consistent with espionage-focused APTs, as is the absence of malware.
There is a notable difference in how recent APT groups targeting critical manufacturing and infrastructure perform credential dumping. Firstly, if a compromised account is privileged, some threat groups use that account to dump the Local Security Authority Subsystem Service (LSASS) process. We didn’t observe LSASS dumps, but given the visibility gaps, we can’t say with certainty it did not occur. Alternatively, the usage of
ntdsutil.exe to harvest credentials from domain controllers by creating installation media is another common technique. We did detect
ntdsutil.exe, but credential dumping was achieved by creating a snapshot of the
Unfortunately, infrastructure and TTPs are often the same across a lot of APT groups’ activity, making definitive attribution difficult. But it does enable defenders to focus on en masse detections, rather than countless specific detections tailored to each APT group.
Espionage, especially the nation-state variety, is a daunting threat for any organization. The events above have shown how valuable it is for threat actors to fly under the radar for as long as possible, maintaining access and collecting data (the two primary objectives). Detection isn’t easy when threat activity blends into a compromised environment, masquerading as normal.
Thankfully, the distinction between espionage and financial objectives is slim. Why thankfully? Well, although espionage may be a part of an organizations’ threat-defense model, for most entities, it’s hardly a primary concern. Although there might be long-term business impacts if intellectual property is stolen, short-term operations will largely escape impact. But a financially motivated threat actor will employ many, if not all, of the TTPs detailed above, and simply move one more step right into Impact, the last MITRE Tactic, to encrypt or destroy data and inhibit network operations. As defenders, focusing on “detecting left” (as early as possible following initial access) enables us to account for both espionage and extortion simultaneously, through security controls and detections targeting the same TTPs.
The ReliaQuest GreyMatter security operations platform empowers customers to investigate, detect, and respond to the threats that matter most. The platform increases visibility, to help you get the most out of existing security investments, and reduces the complexity of the DIR lifecycle. This ultimately allows ReliaQuest and our customers to efficiently counter known and emerging threats. We provide customers with detection capabilities and actionable intelligence to mitigate the efforts of espionage and financially motivated threat actors alike.
Based on this case study, here are some recommendations to help protect your organization from similar threats:
- Update and apply patches to all network-edge devices, particularly Fortinet appliances.
- Ensure that no network-edge devices have publicly exposed management interfaces.
- Implement GPOs preventing/restricting remote interactive logins to service accounts.
- Use device certificates for remote authentications, to mitigate the risk of exposed credentials.
- Require MFA for all remote authentications, at a minimum.
- Ensure MFA is properly configured for all required accounts.
- Run all EDR solutions in prevent/block modes, rather than detect, to proactively prevent actions on objectives.
- Implement GPOs specifying RDP timeouts and session terminations, to reduce the risk of stale RDP connections subject to hijacking.
- Enforce a robust password policy and management solution requiring rotations.
- Audit service and local accounts to ensure each account has a documented owner and purpose.
- Segment and properly secure sensitive data.