Executive Summary

The Cybersecurity and Infrastructure Security Agency (CISA) conducted a red team assessment (RTA) at the request of a critical infrastructure organization. During RTAs, CISA’s red team simulates real-world malicious cyber operations to assess an organization’s cybersecurity detection and response capabilities. In coordination with the assessed organization, CISA is releasing this Cybersecurity Advisory to detail the red team’s activity—including their tactics, techniques, and procedures (TTPs) and associated network defense activity. Additionally, the advisory contains lessons learned and key findings from the assessment to provide recommendations to network defenders and software manufacturers for improving their organizations’ and customers’ cybersecurity posture.

Within this assessment, the red team (also referred to as ‘the team’) gained initial access through a web shell left from a third party’s previous security assessment. The red team proceeded to move through the demilitarized zone (DMZ) and into the network to fully compromise the organization’s domain and several sensitive business system (SBS) targets. The assessed organization discovered evidence of the red team’s initial activity but failed to act promptly regarding the malicious network traffic through its DMZ or challenge much of the red team’s presence in the organization’s Windows environment.

The red team was able to compromise the domain and SBSs of the organization as it lacked sufficient controls to detect and respond to their activities. The red team’s findings illuminate lessons learned for network defenders and software manufacturers about how to respond to and reduce risk.

• Lesson Learned: The assessed organization had insufficient technical controls to prevent and detect malicious activity. The organization relied too heavily on host-based endpoint detection and response (EDR) solutions and did not implement sufficient network layer protections.
• Lesson Learned: The organization’s staff require continuous training, support, and resources to implement secure software configurations and detect malicious activity. Staff need to continuously enhance their technical competency, gain additional institutional knowledge of their systems, and ensure they are provided sufficient resources by management to have the conditions to succeed in protecting their networks.
• Lesson Learned: The organization’s leadership minimized the business risk of known attack vectors for the organization. Leadership deprioritized the treatment of a vulnerability their own cybersecurity team identified, and in their risk-based decision-making, miscalculated the potential impact and likelihood of its exploitation.

To reduce risk of similar malicious cyber activity, CISA encourages critical infrastructure organizations to apply the recommendations in the Mitigations section of this advisory to ensure security processes and procedures are up to date, effective, and enable timely detection and mitigation of malicious activity.

This document illustrates the outsized burden and costs of compensating for insecure software and hardware borne by critical infrastructure owners and operators. The expectation that owners and operators should maintain the requisite sophisticated cyber defense skills creates undue risk. Technology manufacturers must assume responsibility for product security. Recognizing that insecure software contributes to these identified issues, CISA urges software manufacturers to embrace Secure by Design principles and implement the recommendations in the Mitigations section of this advisory, including those listed below:

• Embed security into product architecture throughout the entire software development lifecycle (SDLC).
• Eliminate default passwords.
• Mandate MFA, ideally phishing-resistant MFA, for privileged users and make MFA a default, rather than opt-in, feature.

Download the PDF version of this report:

INTRODUCTION

CISA has authority to—upon request—provide analyses, expertise, and other technical assistance to critical infrastructure owners and operators and provide operational and timely technical assistance to federal and non-federal entities with respect to cybersecurity risks. (See generally 6 U.S.C. §§ 652[c][5], 659[c][6]). The target organization for this assessment was a critical infrastructure organization in the United States. After receiving a request for an RTA from the organization and coordinating the high-level details of the engagement, CISA conducted the RTA over approximately a three-month period.

During RTAs, a CISA red team simulates real-world threat actors to assess an organization’s cybersecurity detection and response capabilities. During Phase I, the red team attempts to gain and maintain persistent access to an organization’s enterprise network, avoid detection, evade defenses, and access SBSs. During Phase II, the red team attempts to trigger a security response from the organization’s people, processes, and/or technology.

Drafted in coordination with the assessed organization, this advisory details the red team’s activity and TTPs, associated network defense activity, and lessons learned to provide network defenders with recommendations for improving an organization’s cybersecurity posture. The advisory also provides recommendations for software manufacturers to harden their customer networks against malicious activity and reduce the likelihood of domain compromise.

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK^® Matrix for Enterprise framework, version 16. See Appendix: MITRE ATT&CK Tactics and Techniques for a table of the red team’s activity mapped to MITRE ATT&CK tactics and techniques.

Phase I: Red Team Cyber Threat Activity

Overview

The CISA red team operated without prior knowledge of the organization’s technology assets and began the assessment by conducting open source research on the target organization to gain information about its network [T1590], defensive tools [T1590.006], and employees [T1589.003]. The red team designed spearphishing campaigns [T1566] tailored to employees most likely to communicate with external parties. The phishing attempts were ultimately unsuccessful—targets ran the payloads [T1204], but their execution did not result in the red team gaining access into the network.

After the failed spearphishing campaigns, the red team continued external reconnaissance of the network [T1595] and discovered a web shell [T1505.003] left from a previous Vulnerability Disclosure Program (VDP). The red team used this for initial access [TA0001] and immediately reported it to the organization’s trusted agents (TAs). The red team leveraged that access to escalate privileges [TA0004] on the host, discover credential material on a misconfigured Network File System (NFS) share [T1552.001], and move from a DMZ to the internal network [TA0008].

With access to the internal network, the red team gained further access to several SBSs. The red team leveraged a certificate for client authentication [T1649] they discovered on the NFS share to compromise a system configured for Unconstrained Delegation. This allowed the red team to acquire a ticket granting ticket (TGT) for a domain controller [T1558.001], used to further compromise the domain. The red team leveraged this level of access to exploit SBS targets provided by the organization’s TAs.

The assessed organization detected much of the red team’s activity in their Linux infrastructure after CISA alerted them via other channels to the vulnerability the red team used for initial access. Once given an official notification of a vulnerability, the organization’s network defenders began mitigating the vulnerability. Network defenders removed the site hosting the web shell from the public internet but did not take the server itself offline. A week later, network defenders officially declared an incident once they determined the web shell was used to breach the internal network. For several weeks, network defenders terminated much of the red team’s access until the team maintained implants on only four hosts. Network defenders successfully delayed the red team from accessing many SBSs that required additional positioning, forcing the red team to spend time refortifying their access in the network. Despite these actions, the red team was still able to access a subset of SBSs. Eventually, the red team and TAs decided that the network defenders would stand down to allow the red team to continue its operations in a monitoring mode. In monitoring mode, network defenders would report what they observed of the red team’s access, but not continue to block and terminate it.

See Figure 1 for a timeline of the red team’s activity with key points access. See the following sections for additional details, including the red team’s TTPs.

Initial Access

Following an unsuccessful spearphishing campaign, the red team gained initial access to the target by exploiting an internet-facing Linux web server [T1190] discovered through reconnaissance [TA0043] of the organization’s external internet protocol (IP) space [T1590.005].

The red team first conducted open source research [T1593] to identify information about the organization’s network, including the tools used to protect the network and potential targets for spearphishing. The red team looked for email addresses [T1589.002] and names to infer email addresses from the organization’s email syntax (discovered during reconnaissance). Following this action, the red team sent tailored spearphishing emails to 13 targets [T1566.002]. Of these 13 targets, one user responded and executed two malicious payloads [T1204.002]. However, the payloads failed to bypass a previously undiscovered technical control employed by the victim organization, preventing the red team’s first attempt to gain initial access.

To find an alternate pathway for initial access, the red team conducted reconnaissance with several publicly available tools, such as Shodan and Censys, to discover accessible devices and services on the internet [T1596.005]. The red team identified an old and unpatched service with a known XML External Entity (XXE) vulnerability and leveraged a public proof of concept to deploy a web shell. The associated product had an exposed endpoint—one that system administrators should typically block from the public internet—that allowed the red team to discover a preexisting web shell on the organization’s Linux web server. The preexisting web shell allowed the red team to run arbitrary commands on the server [T1059] as a user (WEBUSER1). Using the web shell, the red team identified an open internal proxy server [T1016] to send outbound communications to the internet via Hypertext Transfer Protocol Secure (HTTPS). The red team then downloaded [T1105] and executed a Sliver payload that utilized this proxy to establish command and control (C2) over this host, calling back to their infrastructure [TA0011].

Note: Because the web shell and unpatched vulnerability allowed actors to easily gain initial access to the organization, the CISA red team determined this was a critical vulnerability. CISA reported both the vulnerability and the web shell to the organization in an official vulnerability notification so the organization could remediate both issues. Following this notification, the victim organization initiated threat hunting activities, detecting some of the red team’s activity. The TAs determined that network defenders had previously identified and reported the vulnerability but did not remediate it. Further, the TAs found that network defenders were unaware of the web shell and believed it was likely leftover from prior VDP activity. See the Defense Evasion and Victim Network Defense Activities section for more information.

Linux Infrastructure Compromise

Local Privilege Escalation and Credential Access

The red team then moved laterally from the web server to the organization’s internal network using valid accounts [T1078] as the DMZ was not properly segmented from the organization’s internal domain.

The red team acquired credentials [TA0006] by first escalating privileges on the web server. The team discovered that WEBUSER1 had excessive sudo rights, allowing them to run some commands as root commands without a password. They used these elevated rights to deploy a new callback with root access [T1548.003].

With root access to the web server, the team had full access to the organization’s directories and files on a NFS share with no_root_squash enabled. If no_root_squash is used, remote root users can read and change any file on the shared file system and leave a trojan horse [T1080] for other users to inadvertently execute. On Linux operating systems this option is disabled by default, yet the organization enabled it to accommodate several legacy systems. The organization’s decision to enable the no_root_squash option allowed the red team to read all the files on the NFS share once it escalated its privileges on a single host with the NFS share mounted. This NFS share hosted the home directories of hundreds of Linux users—many of which had privileged access to one or more servers—and was auto-mounted when those users logged into Linux hosts in the environment.

The red team used its escalated privileges to search for private certificate files, Secure Shell (SSH) private keys, passwords, bash command histories [T1552.003], and other sensitive data across all user files on the NFS share [T1039]. The team initially obtained 61 private SSH keys [T1552.004] and a file containing valid cleartext domain credentials (DOMAINUSER1) that the team used to authenticate to the organization’s domain [T1078.002].

Linux Command and Control

In the organization’s Linux environment, the red team leveraged HTTPS connections for C2 [T1071.001]. Most of the Linux systems could not directly access the internet, but the red team circumvented this by leveraging an open internal HTTPS proxy [T1090.001] for their traffic.

Lateral Movement and Persistence

The red team’s acquisition of SSH private keys generated for user and service accounts facilitated unrestricted lateral movement to other Linux hosts [T1021.004]. This acquisition included two highly privileged accounts with root access to hundreds of servers. Within one week of initial access, the team moved to multiple Linux servers and established persistence [TA0003] on four. The team used a different persistence mechanism on each Linux host, so network defenders would be less likely to discover the red team’s presence on all four hosts. The team temporarily backdoored several scripts run at boot time to maintain persistence [T1037], ensuring the original versions of the scripts were re-enabled once the team successfully achieved persistence. Some of the team’s techniques included modifying preexisting scripts run by the cron utility [T1053.003] and ifup-post scripts [T1037.003].

Of note, the team gained root access to an SBS-adjacent infrastructure management server that ran Ansible Tower. Access to this Ansible Tower system [T1072] provided easy access to multiple SBSs. The team discovered a root SSH private key on the host, which allowed the team to move to six SBSs across six different sensitive IP ranges. A week after the team provided screenshots of root access to the SBSs to the TAs, the TAs deconflicted the red team’s access to the Ansible Tower system that network defenders discovered. The organization detected the compromise by observing abnormal usage of the root SSH private key. The root SSH private key was used to log into multiple hosts at times and for durations outside of preestablished baselines. In a real compromise, the organization would have had to shut down the server, significantly impacting business operations.

Windows Domain Controller Compromise

Approximately two weeks after gaining initial access, the red team compromised a Windows domain controller. This compromise allowed the team to move laterally to all domain-joined Windows hosts within the organization.

To first gain situational awareness about the organization’s environment, the red team exfiltrated Active Directory (AD) information [TA0010] from a compromised Linux host that had network access to a Domain Controller (DC). The team queried Lightweight Directory Access Protocol (Over SSL)—(LDAPS)—to collect information about users [T1087.002], computers [T1018], groups [T1069.002], access control lists (ACL), organizational units (OU), and group policy objects (GPO) [T1615]. Unfortunately, the organization did not have detections to monitor for anomalous LDAP traffic. A non-privileged user querying LDAP from the organization’s Linux domain should have alerted network defenders.

The red team observed a total of 42 hosts in AD that were not DCs, but had Unconstrained Delegation enabled. Hosts with Unconstrained Delegation enabled store the Kerberos TGTs of any user that authenticates to them. With sufficient privileges, an actor can obtain those tickets and impersonate associated users. A compromise of any of these hosts could lead to the escalation of privileges within the domain. Network defenders should work with system administrators to determine whether Unconstrained Delegation is necessary for their systems and limit the number of systems with Unconstrained Delegation unnecessarily enabled.

The red team observed insufficient network segmentation between the organization’s Linux and Windows domains. This allowed for Server Message Block (SMB) and Kerberos traffic to a DC and a domain server with Unconstrained Delegation enabled (UDHOST). The team discovered an unprotected Personal Information Exchange (.pfx) file on the NFS home share that they believed was for UDHOST based on its naming convention.

Equipped with the .pfx file, the red team used Rubeus—an open source toolset for Kerberos interaction and abuses—to acquire a TGT and New Technology Local Area Network Manager (NTLM) hash for UDHOST from the DC. The team then used the TGT to abuse the Server-for-User-to-Self (S4U2Self) Kerberos extension to gain administrative access to UDHOST.

The red team leveraged this administrative access to upload a modified version of Rubeus in monitor mode to capture incoming tickets [T1040] on UDHOST with Rubeus’ /monitor command. Next, the team ran DFSCoerce.py to force the domain controller to authenticate to UDHOST [T1187]. The team then downloaded the captured tickets from UDHOST.

With the DC’s TGT, the team used Domain Controller Sync (DCSync) through their Linux tunnels to acquire the hash of several privileged accounts—including domain, enterprise, and server administrators—and the critical krbtgt account [T1003.006].

Gaining access to AD is not unusual for most of CISA’s Red Team engagements, but it is rare to find network defenders who can secure and monitor it quickly and effectively.

Once the team harvested the credentials needed, they moved laterally to nearly any system in the Windows domain (see Figure 2) through the following steps (hereafter, this combination of techniques is referred to as the “Preferred Lateral Movement Technique”):

1. The team either forged a golden ticket using the krbtgt hash or requested a valid TGT using the hashes they exfiltrated for a specific account before loading the ticket into their session for additional authentication.
2. The team dropped an inflated Dynamic Link Library (DLL) file associated with legitimate scheduled tasks on the organization’s domain.
3. When the scheduled task executed on its own or through the red team’s prompting, the DLL hijack launched a C2 implant.

Windows Command and Control

The red team initially established C2 on a workstation over HTTPS before connecting to servers over SMB [T1071.002] in the organization’s Windows environment. To connect to certain SBSs later in its activity, the team again relied on HTTPS for C2.

Post-Exploitation Activity: Gaining Access to SBSs

After the red team gained persistent access to Linux and Windows systems across the organization’s networks, the team began post-exploitation activities and attempted to access SBSs. The TAs provided a scope of the organization’s Classless Inter-Domain Routing (CIDR) ranges that contained SBSs. The team gained root access to multiple Linux servers in these ranges. The TAs then instructed the red team to exploit its list of primary targets: admin workstations and network ranges that included OT networks. The team only achieved access to the first two targets and did not find a path to the OT networks. While the team was able to affect the integrity of data derived from OT devices and applications, it was unable to find and access the organization’s internal network where the OT devices resided.

To gain access to the SBSs, the team first gained access to Microsoft System Center Configuration Manager (SCCM) servers, which managed most of the domain’s Windows systems. To access the SCCM servers, the team leveraged their AD data to identify administrators [T1087] of these targets. One of the users they previously acquired credentials for via DCSync was an administrator on the SCCM servers. The red team then used the Preferred Lateral Movement Technique to eventually authenticate to the SCCM servers. See Figure 3.

Admin Workstations

The first specific set of SBS targets provided by the TAs were admin workstations. These systems are used across various sensitive networks external to, or inaccessible from, the internal network where the team already had access. Normally, authorized personnel leverage these administrator workstations to perform administrator functions. CISA’s red team targeted these systems in the hopes that an authorized—but unwitting—user would move the tainted system to another network, resulting in a callback from the sensitive target network.

The red team reviewed AD data to identify these administrator systems. Through their review, the team discovered a subset of Windows workstations that could be identified with a prefix and determined a group likely to have administrative rights to the workstations.

With access to the SCCM server, the red team utilized their Preferred Lateral Movement Technique to gain access to each admin workstation target (see Figure 4).

The red team maintained access to these systems for several weeks, periodically checking where they were communicating from to determine if they had moved to another network. Eventually, the team lost access to these systems without a deconfliction. To the best of the red team’s knowledge, these systems either did not move to new networks or, if they did, those systems no longer had the ability to communicate with red team’s C2 infrastructure.

Additional Host and Other Subnets

After compromising admin workstations, the red team requested that the TAs prioritize additional systems or IP ranges. The TAs provided four CIDR ranges to target:

• A corporate DMZ that contained a mixture of systems and other subnets.
• A second subnet.
• A third subnet. 
• An internal network that contained OT devices.

Access to the corporate DMZ was necessary to reach the second and third ranges, and the red team hoped that gaining access to these would facilitate access to the fourth range.

The red team followed a familiar playbook to gain access to these SBSs from another SCCM server. First, the team performed reverse DNS lookups [T1596.001] on IP addresses within the ranges the TAs provided. They then scanned SMB port 445/TCP [T1046] from a previously compromised SCCM server to discover Windows hosts it could access on the corporate DMZ. The team discovered the server could connect to a host within the target IP range and that the system was running an outdated version of Windows Server 2012 R2. The default configuration of Windows Server 2012 R2 allows unprivileged users to query the group membership of local administrator groups. The red team discovered a user account [T1069] by querying the Windows Server 2012 R2 target that was in a database administrator group. The team leveraged its Preferred Lateral Movement Technique to authenticate to the target as that user, then repeated that technique to access a database. This database receives information from OT devices used to feed monitoring dashboards, information which factors into the organization’s decision-making process [T1213].

The new host had several active connections to systems in the internal ranges of the second and third subnets. Reverse domain name system (DNS) lookup requests for these hosts failed to return any results. However, the systems were also running Windows Server 2012 R2. The red team used Windows API calls to NetLocalGroupEnum and NetLocalGroupGetMembers to query local groups [T1069.001], revealing the system names for these targets as a result. The red team performed their Preferred Lateral Movement Technique to gain access to these hosts in the second and third provided network ranges.

With access to these subnets, the red team began exploring a path to systems on a private subnet where OT devices resided but failed to locate a path to that fourth subnet.

Corporate Workstations of Critical Infrastructure Administrators and Operators

Next, the red team targeted the corporate workstations of the administrators and operators of the organization’s critical infrastructure. Because the team lacked knowledge of the organization’s OT devices and failed to discover a path to the private subnet where they resided, they instead tried to locate users that interacted with human machine interfaces (HMI). Access to such users could enable the team to access the HMI, which serves as a dashboard for OT.

The red team leveraged its AD data once again, combining this data with user information from SCCM to identify targets by job role and their primary workstation. Then the team targeted the desktop of a critical infrastructure administrator, the workstation of another critical infrastructure administrator, and the workstations of three critical infrastructure operators spread across two geographically disparate sites.

The AD data revealed users in a group that were administrators of all the targets. The red team then repeated their Preferred Lateral Movement Technique and identified a logged-in user connected to a “System Status and Alarm Monitoring” interface. The team discovered credentials to the interface in the user’s home directory, proxied through the system, and accessed the HMI interface over HTTP. The team did not pursue further activity involving the interface because their remaining assessment time was limited. Additionally, they did not discover a way to compromise the underlying OT devices.

Command and Control

The team used third-party owned and operated infrastructure and services [T1583] throughout its assessment, including in certain cases for command and control (C2). The tools that the red team obtained included [T1588.002]:

• Sliver, Mythic, Cobalt Strike, and other commercial C2 frameworks.
  • The team maintained multiple command and control servers hosted by several cloud vendors. They configured each server with a different domain and used the servers for communication with compromised hosts. These servers retained all assessment data.
• Two commercially available cloud-computing platforms.
  • The team used these platforms to create flexible and dynamic redirect servers to send traffic to the team’s servers [T1090.002]. Redirecting servers make it difficult for defenders to attribute assessment activities to the backend team servers. The redirectors use HTTPS reverse proxies to redirect C2 traffic between the target organization’s network and the team servers. The team encrypted all data in transit [T1573] and secured all data at rest through a VPN with multifactor authentication.
• Content delivery network (CDN) services.
  • This technique leverages CDNs associated with high-reputation domains, causing malicious traffic to appear directed towards a reputational domain. However, it is redirected to red team-controlled servers. This allows the team to obfuscate some of their C2 traffic.

The team used domain fronting [T1090.004] to disguise outbound traffic, diversifying communications between the domains and the persistent beacons. This technique (which also leverages CDNs) allows the beacon to appear to connect to third-party domains but instead connects to the team’s redirect server.

Defense Evasion and Victim Network Defense Activities

Most of the encounters between the red team and network defenders occurred in the organization’s Linux environment. The red team leveraged Linux tradecraft in an attempt to evade network defenses. In response, network defenders’ threat hunting activities identified some of the team’s presence in their Linux environment. To evade defenses, the red team reordered the process identifier (PID) of its executable processes to appear closer to the kernel and minimize the team’s likelihood of detection. The team also modified its processes [T1055] by changing their names in memory and at execution. In addition, they used Python scripts [T1059.006] run in memory [T1620] to avoid on-disk detection. Some of the red team’s Linux persistence techniques included modifying preexisting scripts run by the cron utility and creating backdoors through ifup-post scripts and .bashrc. Network defenders ultimately identified the team’s backdoor in .bashrc [T1546.004].

Defenders also successfully detected anomalous activity on their Ansible Tower host and other systems in their Linux environment. The defenders actively analyzed NetFlow data, which helped them identify the red team’s persistence and lateral movement. To mitigate the impact of the red team’s tactics, network defenders would have needed to shut down a critical server as part of their incident response activities. A shut down would have resulted in downtime for hundreds of systems, including SBSs.

The organization’s EDR solutions largely failed to protect the organization. EDR detected only a few of the red team’s payloads in the organization’s Windows and Linux environments. In the instance the EDR protected the organization from the initial phishing payload, it generated an alert that network defenders neither read nor responded to. The red team excelled in bypassing EDR solutions by avoiding the use of basic “known-bad” detections the tools would capture. The team also inflated its file sizes above the upload threshold of the organization’s EDR [T1027.001]. In addition, the organization completely lacked any EDR solution in a legacy environment. As such, the red team’s persistence there went undetected throughout the assessment.

Network defenders failed to detect red team activity in the organization’s Windows environment due to a lack of proper identity management. Specifically, network defenders failed to detect and respond to the red team’s S4U2Self, asktgs, dcsync, and golden ticket activity. Had the organization monitored for unusual activity involving AD and Kerberos, they would have detected more red team activity.

Lastly, there were significant deficiencies in the organization’s DMZ that should have detected traffic into the organization’s internal network over the ports used by SMB and LDAPS. Network defenders never properly implemented an intrusion detection system (IDS) or intrusion prevention system (IPS) to monitor the DMZ at the network level. This lack of implementation resulted in a failure to detect malicious network traffic through their DMZ. Further, the red team was able to move laterally through the DMZ because there was an open internal proxy with internet access that enabled the team’s C2.

Phase II: Red Team Measurable Events Activity

The red team executed 13 measurable events designed to provoke a response from the people, processes, and technology defending the organization’s network. The red team did not have full visibility into the organization’s responses to these events and lacked the support of a white team to help assess the organization’s responses. See Table 1 for a description of the events, the organization’s actual response, and key takeaways.

LESSONS LEARNED AND KEY FINDINGS

The red team noted the following lessons learned relevant to all organizations generated from the security assessment of the organization’s network. These findings contributed to the team’s ability to gain persistent access across the organization’s network. See the Mitigations section for recommendations on how to mitigate these findings.

Lesson Learned: Insufficient Technical Controls

The assessed organization had insufficient technical controls to prevent and detect malicious activity. The organization relied too heavily on host-based EDR solutions and did not implement sufficient network layer protections.

• Finding #1: The organization’s perimeter network was not adequately firewalled from its internal network, which allowed the red team a path through the DMZ to internal networks. A properly configured network should block access to a path from the DMZ to other internal networks.
• Finding #2: The organization was too reliant on its host-based tools and lacked network layer protections, such as well-configured web proxies or intrusion prevention systems (IPS). The organization’s EDR solutions also failed to catch all the red team’s payloads. Below is a list of some of the higher risk activities conducted by the team that were opportunities for detection:
  • Phishing;
  • Kerberoasting;
  • Generation and use of golden tickets;
  • S4U2self abuse;
  • Anomalous LDAP traffic;
  • Anomalous NFS enumeration;
  • Unconstrained Delegation server compromise;
  • DCSync;
  • Anomalous account usage during lateral movement;
  • Anomalous outbound network traffic;
  • Anomalous outbound SSH connections to the team’s cloud servers from workstations; and
  • Use of proxy servers from hosts intended to be restricted from internet access.
• Finding #3: The organization had insufficient host monitoring in a legacy environment. The organization had hosts with a legacy operating system without a local EDR solution, which allowed the red team to persist for several months on the hosts undetected.

Lesson Learned: Continuous Training, Support, and Resources

The organization’s staff requires continuous training, support, and resources to implement secure software configurations and detect malicious activity. Staff need to continuously enhance their technical competency, gain additional institutional knowledge of their systems, and ensure are provided sufficient resources by management to adequately protect their networks.

• Finding #4: The organization had multiple systems configured insecurely. This allowed the red team to compromise, maintain persistence, and further exploit those systems (i.e., access credentials, elevate privileges, and move laterally). Insecure system configurations included:
  • Default server configurations. The organization used default configurations for hosts with Windows Server 2012 R2, which allows unprivileged users to query membership of local administrator groups. This enabled the red team to identify several standard user accounts with administrative access.
    Note: By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account. In this way, users with local root access are prevented from gaining root level access over the mounted NFS share. Here, the organization deviated from the secure by default configuration and implemented the no_root_squash option to support a few legacy systems instead. This deviation from the default allowed the red team to escalate their privileges over the domain.
  • Hosts with Unconstrained Delegation enabled unnecessarily. Hosts with Unconstrained Delegation enabled will store the Kerberos TGTs of all users that authenticate to that host. This affords threat actors the opportunity to steal TGTs, including the TGT for a domain controller, and use them to escalate their privileges over the domain.
  • Insecure Account Configuration. The organization had an account running a Linux webserver with excessive privileges. The entry for that user in the sudoers file—which controls user rights—contained paths with wildcards where that user had write access, allowing the team to escalate privileges.
    Note: This file should only contain specific paths to executable files that a user needs to run as another user or root, and not a wildcard. Users should not have write access over any file in the sudoers entry.
• Finding #5: The red team’s activities generated security alerts that network defenders did not review. In many instances, the organization relied too heavily on known IOCs and their EDR solutions instead of conducting independent analysis of their network activity compared against baselines.
• Finding #6: The organization lacked proper identity management. Because network defenders did not implement a centralized identity management system in their Linux network, they had to manually query every Linux host for artifacts related to the red team’s lateral movement through SSH. Defenders also failed to detect anomalous activity in their organization’s Windows environment because of poor identity management.

Lesson Learned: Business Risk

The organization’s leadership minimized the business risk of known attack vectors for their organization. Leadership deprioritized the treatment of a vulnerability their own cybersecurity team identified, and in their risk-based decision-making, miscalculated the potential impact and likelihood of its exploitation.

• Finding #7: The organization used known insecure and outdated software. The red team discovered software on one of the organization’s web servers that was outdated.
  • After their operations, the red team learned the insecure and outdated software was a known security concern. The organization’s security team alerted management to the risks associated this software, but management accepted the risk.
  • Next, the security team implemented a VDP program, which resulted in a participant exploiting the vulnerability for initial access. The VDP program helped the security team gain management support, and they implemented a web application firewall (WAF) as a compensating control. However, they did not adequately mitigate the vulnerability as they configured the WAF to be only in monitoring mode. The security team either did not have processes (or implement them properly) to scan, assess, and test whether they treated the vulnerability effectively.

Additional Findings

The red team noted the following additional issues relevant to the security of the organization’s network that contributed to their activity.

• Unsecured Keys and Credentials. The organization stored many private keys that lacked password protection, allowing the red team to steal the keys and use them for authentication purposes.
  • The private key of a PFX file was not password protected, allowing the red team to use that certificate to authenticate to active directory, access UDHOST, and eventually compromise the DC. In addition, the organization did not require password protection of SSH private keys.
    Note: Without a password protected key, an actor can more easily steal the private key and use it to authenticate to a system through SSH.
  • The organization had files in a home share that contained cleartext passwords. The accounts included, among other accounts, a system administrator.
    Note: The organization appeared to store cleartext passwords in the description and user password sections of Active Directory accounts. These passwords were accessible to all domain users.
• Email Address Verification. The active Microsoft Office 365 configuration allows an unauthenticated external user to validate email addresses through observing error messages in the form of HTTP 302 versus HTTP 200 responses. This misconfiguration helps threat actors verify email addresses before sending phishing emails.

Noted Strengths

The red team noted the following technical controls or defensive measures that prevented or hampered offensive actions:

• Network defenders detected the initial compromise and some red team movement. After being alerted of the web shell, the organization initiated hunt activities, detected initial access, and tracked some of the red team’s Phase I movements. The organization terminated much of the red team’s access to the organization’s internal network. Of note, once the organization’s defenders discovered the red team’s access, the red team spent significant time and resources continuously refortifying their access to the network.
• Host-based EDR solutions prevented initial access by phishing. The EDR stopped the execution of multiple payloads the red team sent to a user of the organization over a week long period. The organization leveraged two products on workstations, one that was publicly discoverable and another the red team did not learn about until gaining initial access. The product the red team was unaware of, and did not test their payload against, was responsible for stopping the execution of their payloads.
• Strong domain password policy. The organization’s domain password policy neutralized the red team’s attempts to crack hashes and spray passwords. The team was unable to crack any hashes of all 115 service accounts it targeted.
• Effective separation of privileges. The organization’s administrative users had separate accounts for performing privileged actions versus routine activities. This makes privilege escalation more difficult for threat actors.

MITIGATIONS

Network Defenders

CISA recommends organizations implement the recommendations in Table 2 to mitigate the findings listed in the Lessons Learned and Key Findings section of this advisory. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. See CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.

Additionally, CISA recommends organizations implement the mitigations below to improve their cybersecurity posture:

• Provide users with regular training and exercises, specifically related to phishing emails. Phishing accounts for majority of initial access intrusion events.
• Enforce phishing-resistant MFA to the greatest extent possible.
• Reduce the risk of credential compromise via the following:
  • Place domain admin accounts in the protected users group to prevent caching of password hashes locally; this also forces Kerberos AES authentication as opposed to weaker RC4 or NTLM authentication protocols.
  • Upgrade to Windows Server 2019 or greater and Windows 10 or greater. These versions have security features not included in older operating systems.

As a long-term effort, CISA recommends organizations prioritize implementing a more modern, Zero Trust network architecture that:

• Leverages secure cloud services for key enterprise security capabilities (e.g., identity and access management, endpoint detection and response, and policy enforcement).
• Upgrades applications and infrastructure to leverage modern identity management and network access practices.
• Centralizes and streamlines access to cybersecurity data to drive analytics for identifying and managing cybersecurity risks.
• Invests in technology and personnel to achieve these goals.

Software Manufacturers

The above mitigations apply to critical infrastructure organizations with on-premises or hybrid environments. Recognizing that insecure software is the root cause of many of these flaws and responsibility should not fall on the end user, CISA urges software manufacturers to implement the following:

• Embed security into product architecture throughout the entire software development lifecycle (SDLC).
• Eliminate default passwords. Do not provide software with default passwords. To eliminate default passwords, require administrators to set a strong password [CPG 2.B] during installation and configuration.
• Design products so that the compromise of a single security control does not result in compromise of the entire system. For example, narrowly provision user privileges by default and employ ACLs to reduce the impact of a compromised account. This will make it more difficult for a malicious cyber actor to escalate privileges and move laterally.
• Mandate MFA, ideally phishing-resistant MFA, for privileged users and make MFA a default, rather than opt-in, feature.
• Reduce hardening guide size, with a focus on systems being secure by default. In this scenario, the red team noticed default Windows Server 2012 configurations that allowed them to enumerate privileged accounts.

1. Important: Manufacturers need to implement routine nudges that are built into the product rather than relying on administrators to have the time, expertise, and awareness to interpret hardening guides.

These mitigations align with principles provided in the joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. CISA urges software manufacturers to take ownership of improving security outcomes of their customers by applying these and other secure by design practices. By adhering to secure by design principles, software manufacturers can make their product lines secure out of the box without requiring customers to spend additional resources making configuration changes, purchasing security software and logs, monitoring, and making routine updates.

For more information on secure by design, see CISA’s Secure by Design webpage. For more information on common misconfigurations and guidance on reducing their prevalence, see the joint advisory NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations.

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, CISA recommends exercising, testing, and validating your organization's security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. CISA recommends testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

1. Select an ATT&CK technique described in this advisory (see Table 3 to Table 16).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies’ performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

CISA recommends continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

RESOURCES

• See CISA’s RedEye tool on CISA’s GitHub page. RedEye is an interactive open source analytic tool used to visualize and report red team command and control activities. See CISA’s RedEye tool overview video for more information.
• See CISA’s Phishing Guidance.
• See CISA’s Secure by Design page to learn more about secure by design principles.

APPENDIX: MITRE ATT&CK TACTICS AND TECHNIQUES

See Table 3 to Table 16 for all referenced red team tactics and techniques in this advisory. Note: Unless noted, activity took place during Phase I. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

LodaRAT, a remote access tool active since 2016, has resurfaced in a new campaign that’s taking the cybersecurity world by storm. Originally designed for basic information theft, this tool has transformed into a sophisticated malware capable of carrying out global cyber-espionage operations. What’s alarming is that while LodaRAT hasn’t been updated since 2021, its reach and effectiveness have grown, making it a pressing concern for individuals and organisations worldwide.  

A Global Campaign with Far-Reaching Impact  

What sets this latest campaign apart is its global nature. Unlike previous efforts that targeted specific regions, LodaRAT is now aiming at victims across the world. Around 30% of related malware samples uploaded to VirusTotal came from the United States, suggesting widespread infection. This shift indicates that LodaRAT is no longer confined to limited geographic boundaries, and its operators are adapting to target more diverse networks and systems.  

How LodaRAT Works  

LodaRAT’s tactics have become more complex, allowing it to infiltrate systems and operate undetected. Its distribution relies on a mix of phishing emails, system vulnerabilities, and other malware like DonutLoader and Cobalt Strike. It also disguises itself as trusted software such as Skype, Discord, or Windows Update to trick users into installing it.  

Once installed, the malware carries out a variety of harmful activities, including:  

• Spying on users by recording audio and video through webcams and microphones.  
• Stealing credentials and cookies from popular browsers like Microsoft Edge and Brave.  
• Disabling security measures such as the Windows Firewall to create backdoors.  
• Spreading through networks, using SMB protocol exploits to infect other devices.  
• Hiding its tracks by storing stolen data in concealed locations on the victim's system.  

Increased Risks for Organizations  

This new campaign has heightened risks for businesses and organisations. LodaRAT is capable of spreading within internal networks by exploiting specific vulnerabilities, particularly via port 445. This allows attackers to move laterally, targeting multiple devices in the same network. Such breaches can lead to stolen data, operational disruptions, and significant financial losses.  

Protecting Against LodaRAT 

To defend against LodaRAT, organisations and individuals need to take proactive measures:  

1. Strengthen security systems by using advanced endpoint protection tools.  

2. Monitor network activity to detect unusual behaviours that could indicate malware presence.  

3. Educate users on phishing tactics to prevent accidental downloads.  

4. Adopt strong authentication practices to make credential theft harder.  

5. Use tools like Rapid7’s Insight Agent to identify potential threats and weak points.  

The return of LodaRAT shows how minor tweaks to existing malware can make it highly effective. This campaign is a reminder that even older threats can evolve and remain dangerous. Staying vigilant and updating cybersecurity measures regularly are key to staying ahead of such attacks.  

By understanding how LodaRAT operates and taking the necessary precautions, organisations and individuals can better protect themselves in an increasingly complex digital ecosystem.  

As Americans make their travel plans, scammers lie in wait. We’ve uncovered the top ten “riskiest” destinations for travel scams...

The post The Top 10 Riskiest Online Destinations Revealed appeared first on McAfee Blog.

• Cisco Talos discovered a malicious campaign in August 2022 delivering Cobalt Strike beacons that could be used in later, follow-on attacks.
• Lure themes in the phishing documents in this campaign are related to the job details of a government organization in the United States and a trade union in New Zealand.
• The attack involves a multistage and modular infection chain with fileless, malicious scripts.

Cisco Talos recently discovered a malicious campaign with a modularised attack technique to deliver Cobalt Strike beacons on infected endpoints.

The initial vector of this attack is a phishing email with a malicious Microsoft Word document attachment containing an exploit that attempts to exploit the vulnerability CVE-2017-0199, a remote code execution issue in Microsoft Office. If a victim opens the maldoc, it downloads a malicious Word document template hosted on an attacker-controlled Bitbucket repository.

Talos discovered two attack methodologies employed by the attacker in this campaign: One in which the downloaded DOTM template executes an embedded malicious Visual Basic script, which leads to the generation and execution of other obfuscated VB and PowerShell scripts and another that involves the malicious VB downloading and running a Windows executable that executes malicious PowerShell commands to download and implant the payload.

The payload discovered is a leaked version of a Cobalt Strike beacon. The beacon configuration contains commands to perform targeted process injection of arbitrary binaries and has a high reputation domain configured, exhibiting the redirection technique to masquerade the beacon's traffic.

Although the payload discovered in this campaign is a Cobalt Strike beacon, Talos also observed usage of the Redline information-stealer and Amadey botnet executables as payloads.

This campaign is a typical example of a threat actor using the technique of generating and executing malicious scripts in the victim's system memory. Defenders should implement behavioral protection capabilities in the organization's defense to effectively protect them against fileless threats.

Organizations should be constantly vigilant on the Cobalt Strike beacons and implement layered defense capabilities to thwart the attacker's attempts in the earlier stage of the attack's infection chain.

Initial vector

The initial infection email is themed to entice the recipient to review the attached Word document and provide some of their personal information.

Initial malicious email message.

The maldocs have lures containing text related to the collection of personally identifiable information (PII) which is used to determine the eligibility of the job applicant for employment with U.S. federal government contractors and their alleged enrollment status in the government's life insurance program.

The text in the maldoc resembles the contents of a declaration form of the U.S. Office of Personnel Management (OPM) which serves as the chief human resources agency and personnel policy manager for the U.S. federal government.

Contents of maldoc sample 1.

Another maldoc of the same campaign contains a job description advertising for roles related to delegating development, PSA plus — a prominent New Zealand trade union — and administrative support for National Secretaries at the Public Service Association office based out of Wellington, New Zealand. The contents of this maldoc lure resemble the legitimate job description documents for the New Zealand Public Service Association, another workers' union for New Zealand federal employees, headquartered in Wellington.

Contents of maldoc sample 2.

PSA New Zealand released this legitimate job description document in April 2022. The threat actor constructed the maldoc to contain the text lures to make it appear as a legitimate document on May 6, 2022. Talos' observation shows that the threat actors are also regular consumers of online news.

Attack methodologies

Attack methodologies employed by the actor in this campaign are highly modularised and have multiple stages in the infection chain.

Talos discovered two different attack methodologies of this campaign with a few variations in the TTPs', while the initial infection vector, use of remote template injection technique and the final payload remained the same.

Method 1

This is a modularised method with multiple stages in the infection chain to implant a Cobalt Strike beacon, as outlined below:

Summary of attack method 1 infection chain.

Stage 1 maldoc: DOTM template

The malicious Word document contains an embedded URL, https[://]bitbucket[.]org/atlasover/atlassiancore/downloads/EmmaJardi.dotm, within its relationship component "word/_rels/settings.xml.rels". When a victim opens the document, the malicious DOTM file is downloaded.

Contents of settings.xml.rels of maldoc.

Stage 2: VBA dropper

The downloaded DOTM executes the malicious Visual Basic for Applications (VBA) macro. The VBA dropper code contains an encoded data blob which is decoded and written into an HTA file, "example.hta," in the user profile local application temporary folder. The decoded content written to an HTA file is the next VB script, which is executed using the ShellExecuted method.

Stage 2 VBA dropper.

Stage 3 VB script

The third-stage VBS structure is similar to that of the stage 2 VB dropper. An array of the encoded data will be decoded to a PowerShell script, which is generated in the victim's system memory and executed.

Stage 3 VB script.

Stage 4 PowerShell script

The PowerShell dropper script executed in the victim's system memory contains an AES-encrypted data blob as a base64-encoded string and another base64-encoded string of a decryption key. The encoded strings are converted to generate the AES encrypted data block and the 256-bit AES decryption key. Using the decryption key, the encrypted data generates a PowerShell downloader script, which is executed using the PowerShell IEX function.

Stage 4 PowerShell script.

Stage 5 PowerShell downloader

The PowerShell downloader script is obfuscated and contains encoded blocks that are decoded to generate the download URL, file execution path and file extensions.

The following actions are performed by the script upon its execution in victim's system memory:

1. The script downloads the payload from the actor controlled remote location through the URL "https[://]bitbucket[.]org/atlasover/atlassiancore/downloads/newmodeler.dll" to the user profile local application temporary folder.
2. The script performs a check on the file extension of the downloaded payload file.
3. If the payload has the extension .dll, the script will run the DLL using rundll32.exe exhibiting the use of sideloading technique.
4. If the payload has an MSI file extension, the payload is executed using the command
   "msiexec /quiet /i ".
5. If the payload is an EXE file, then it will run it as a process using the PowerShell commandlet
   Start-Process.
6. Upon running the payload, the script will hide the payload file to establish persistence by setting the "hidden" file system attribute of the payload file.

During our analysis, we discovered that the downloaded payload is a Cobalt Strike DLL beacon.

Stage 5 PowerShell downloader.

Method 2

The second attack method of this campaign is also modular, but is using less sophisticated Visual Basic and PowerShell scripts. We spotted that, in the attack chain, the actor employed a 64-bit Windows executable downloader which executes the PowerShell commands responsible for downloading and running the Cobalt Strike payload.

Summary of attack method 2 infection chain.

Stage 1 maldoc: DOTM template

When a victim opens the malicious document, Windows attempts to download a malicious remote DOTM template through the URL "https[://]bitbucket[.]org/clouchfair/oneproject/downloads/ww.dotm," which was embedded in its relationship component of the file settings.xml.rels."

Contents of settings.xml.rels of maldoc.

Stage 2 VB script

The DOTM template contains a VBA macro that executes a function to decode an encoded data block of the macro to generate the PowerShell downloader script and execute it with the shell function.

Stage 2 VB script.

Stage 3 PowerShell downloader

The PowerShell downloader command downloads a 64-bit Windows executable and runs it as a process in the victim's machine.

Stage 3 PowerShell downloader.

Stage 4 downloader executable

The downloader is a 64-bit executable that runs as a process in the victim's environment. It executes the PowerShell command, which downloads the Cobalt Strike payload DLL through the URL "https[://]bitbucket[.]org/clouchfair/oneproject/downloads/strymon.png" to the userprofile local application temporary directory with a spoofed extension .png and sideloads the DLL using rundll32.exe.

Stage 4 downloader EXE.

The downloader also executes the ping command to the IP address 1[.]1[.]1[.]1 and executes the delete command to delete itself. The usage of ping command is to instill a delay before deleting the downloader.

Payload

Talos discovered that the final payload of this campaign is a Cobalt Strike beacon. Cobalt Strike is a modularised attack framework and is customizable. Threat actors can add or remove features according to their malicious intentions. Employing Cobalt Strike beacons in the attacks' infection chain allows the attackers to blend their malicious traffic with legitimate traffic and evade network detections. Also, with its capabilities to configure commands in the beacon configuration, the attacker can perform various malicious operations such as injecting other malicious binary into the running processes of the infected machines and can avoid having a separate injection module implants in their infection chain.

• C2 server.
• Communication protocols.
• Process injection techniques.
• Malleable C2 Instructions.
• Target process to spawn for x86 and x64 processes.
• Watermark : "Xi54kA==".

Cobalt Strike beacon configuration sample.

• Executes arbitrary codes in the target processes through process injection. Target processes described in the beacon configuration related to this campaign include:

• A high-reputation domain defined in the HostHeader component of the beacon configuration. The actor is using this redirector technique to make the beacon traffic appear legitimate and avoid detection.

Malicious repository

The attacker in this campaign has hosted malicious DOTM templates and Cobalt Strike DLLs on Bitbucket using different accounts. We spotted two attacker-controlled accounts "atlasover" and "clouchfair" in this campaign: https[://]bitbucket[.]org/atlasover/atlassiancore/downloads and https[://]bitbucket[.]org/clouchfair/oneproject/downloads.

During our analysis, the account "atlasover" was live and showed us the hosting information of some of the malicious files in this campaign.

Attacker-controlled bitbucket repository.

Talos also discovered in VirusTotal that the attacker operated the Bitbucket account "clouchfair," using the account to host two other information stealer executables, Redline and Amadey, along with a malicious DOTM template and Cobalt Strike DLL.

Command and control

Talos discovered the C2 server operated in this campaign with the IP address 185[.]225[.]73[.]238 running on Ubuntu Linux version 18.04, located in the Netherlands and is a part of the Alibaba cloud infrastructure.

Shodan search results showed us that the C2 server contained two self-signed SSL certificates with the serial numbers 6532815796879806872 and 1657766544761773100, which are valid from July 14, 2022 - July 14, 2023.

SSL certificate associated with the C2 servers.

Pivoting on the SSL certificates disclosed another Cobalt Strike C2 server with the IP address 43[.]154[.]175[.]230 running on Ubuntu Linux version 18.04 located in Hong Kong, which is also part of Alibaba cloud infrastructure and more likely is operated by the same actor of this campaign.

Coverage

IOC

SUMMARY

The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), and Federal Bureau of Investigation (FBI) assess that People’s Republic of China (PRC) state-sponsored cyber actors are seeking to pre-position themselves on IT networks for disruptive or destructive cyberattacks against U.S. critical infrastructure in the event of a major crisis or conflict with the United States.

CISA, NSA, FBI and the following partners are releasing this advisory to warn critical infrastructure organizations about this assessment, which is based on observations from the U.S. authoring agencies’ incident response activities at critical infrastructure organizations compromised by the PRC state-sponsored cyber group known as Volt Typhoon (also known as Vanguard Panda, BRONZE SILHOUETTE, Dev-0391, UNC3236, Voltzite, and Insidious Taurus):

• U.S. Department of Energy (DOE)
• U.S. Environmental Protection Agency (EPA)
• U.S. Transportation Security Administration (TSA)
• Australian Signals Directorate’s (ASD’s) Australian Cyber Security Centre (ACSC)
• Canadian Centre for Cyber Security (CCCS), a part of the Communications Security Establishment (CSE)
• United Kingdom National Cyber Security Centre (NCSC-UK)
• New Zealand National Cyber Security Centre (NCSC-NZ)

The U.S. authoring agencies have confirmed that Volt Typhoon has compromised the IT environments of multiple critical infrastructure organizations—primarily in Communications, Energy, Transportation Systems, and Water and Wastewater Systems Sectors—in the continental and non-continental United States and its territories, including Guam. Volt Typhoon’s choice of targets and pattern of behavior is not consistent with traditional cyber espionage or intelligence gathering operations, and the U.S. authoring agencies assess with high confidence that Volt Typhoon actors are pre-positioning themselves on IT networks to enable lateral movement to OT assets to disrupt functions. The U.S. authoring agencies are concerned about the potential for these actors to use their network access for disruptive effects in the event of potential geopolitical tensions and/or military conflicts. CCCS assesses that the direct threat to Canada’s critical infrastructure from PRC state-sponsored actors is likely lower than that to U.S. infrastructure, but should U.S. infrastructure be disrupted, Canada would likely be affected as well, due to cross-border integration. ASD’s ACSC and NCSC-NZ assess Australian and New Zealand critical infrastructure, respectively, could be vulnerable to similar activity from PRC state-sponsored actors.

As the authoring agencies have previously highlighted, the use of living off the land (LOTL) techniques is a hallmark of Volt Typhoon actors’ malicious cyber activity when targeting critical infrastructure. The group also relies on valid accounts and leverage strong operational security, which combined, allows for long-term undiscovered persistence. In fact, the U.S. authoring agencies have recently observed indications of Volt Typhoon actors maintaining access and footholds within some victim IT environments for at least five years. Volt Typhoon actors conduct extensive pre-exploitation reconnaissance to learn about the target organization and its environment; tailor their tactics, techniques, and procedures (TTPs) to the victim’s environment; and dedicate ongoing resources to maintaining persistence and understanding the target environment over time, even after initial compromise.

The authoring agencies urge critical infrastructure organizations to apply the mitigations in this advisory and to hunt for similar malicious activity using the guidance herein provided, along with the recommendations found in joint guide Identifying and Mitigating Living Off the Land Techniques. These mitigations are primarily intended for IT and OT administrators in critical infrastructure organizations. Following the mitigations for prevention of or in response to an incident will help disrupt Volt Typhoon’s accesses and reduce the threat to critical infrastructure entities.

If activity is identified, the authoring agencies strongly recommend that critical infrastructure organizations apply the incident response recommendations in this advisory and report the incident to the relevant agency (see Contact Information section).

For additional information, see joint advisory People’s Republic of China State-Sponsored Cyber Actor Living off the Land to Evade Detection and U.S. Department of Justice (DOJ) press release U.S. Government Disrupts Botnet People’s Republic of China Used to Conceal Hacking of Critical Infrastructure. For more information on PRC state-sponsored malicious cyber activity, see CISA’s China Cyber Threat Overview and Advisories webpage.

Download the PDF version of this report:

Read the accompanying Malware Analysis Report: MAR-10448362-1.v1 Volt Typhoon.

For a downloadable copy of indicators of compromise (IOCs), see:

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK for Enterprise framework, version 14. See Appendix C: MITRE ATT&CK Tactics and Techniques section for tables of the Volt Typhoon cyber threat actors’ activity mapped to MITRE ATT&CK^® tactics and techniques. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Overview of Activity

In May 2023, the authoring agencies—working with industry partners—disclosed information about activity attributed to Volt Typhoon (see joint advisory People’s Republic of China State-Sponsored Cyber Actor Living off the Land to Evade Detection). Since then, CISA, NSA, and FBI have determined that this activity is part of a broader campaign in which Volt Typhoon actors have successfully infiltrated the networks of critical infrastructure organizations in the continental and non-continental United States and its territories, including Guam.

The U.S. authoring agencies have primarily observed compromises linked to Volt Typhoon in Communications, Energy, Transportation Systems, and Water and Wastewater Systems sector organizations’ IT networks. Some victims are smaller organizations with limited cybersecurity capabilities that provide critical services to larger organizations or key geographic locations.

Volt Typhoon actors tailor their TTPs to the victim environment; however, the U.S. authoring agencies have observed the actors typically following the same pattern of behavior across identified intrusions. Their choice of targets and pattern of behavior is not consistent with traditional cyber espionage or intelligence gathering operations, and the U.S. authoring agencies assess with high confidence that Volt Typhoon actors are pre-positioning themselves on IT networks to enable the disruption of OT functions across multiple critical infrastructure sectors (see Figure 1).

1. Volt Typhoon conducts extensive pre-compromise reconnaissance to learn about the target organization’s network architecture and operational protocols. This reconnaissance includes identifying network topologies, security measures, typical user behaviors, and key network and IT staff. The intelligence gathered by Volt Typhoon actors is likely leveraged to enhance their operational security. For example, in some instances, Volt Typhoon actors may have abstained from using compromised credentials outside of normal working hours to avoid triggering security alerts on abnormal account activities.
2. Volt Typhoon typically gains initial access to the IT network by exploiting known or zero-day vulnerabilities in public-facing network appliances (e.g., routers, virtual private networks [VPNs], and firewalls) and then connects to the victim’s network via VPN for follow-on activities.
3. Volt Typhoon aims to obtain administrator credentials within the network, often by exploiting privilege escalation vulnerabilities in the operating system or network services. In some cases, Volt Typhoon has obtained credentials insecurely stored on a public-facing network appliance.
4. Volt Typhoon uses valid administrator credentials to move laterally to the domain controller (DC) and other devices via remote access services such as Remote Desktop Protocol (RDP).
5. Volt Typhoon conducts discovery in the victim’s network, leveraging LOTL binaries for stealth. A key tactic includes using PowerShell to perform targeted queries on Windows event logs, focusing on specific users and periods. These queries facilitate the discreet extraction of security event logs into .dat files, allowing Volt Typhoon actors to gather critical information while minimizing detection. This strategy, blending in-depth pre-compromise reconnaissance with meticulous post-exploitation intelligence collection, underscores their sophisticated and strategic approach to cyber operations.
6. Volt Typhoon achieves full domain compromise by extracting the Active Directory database (NTDS.dit) from the DC. Volt Typhoon frequently employs the Volume Shadow Copy Service (VSS) using command-line utilities such as vssadmin to access NTDS.dit. The NTDS.dit file is a centralized repository that contains critical Active Directory data, including user accounts, passwords (in hashed form), and other sensitive data, which can be leveraged for further exploitation. This method entails the creation of a shadow copy—a point-in-time snapshot—of the volume hosting the NTDS.dit file. By leveraging this snapshot, Volt Typhoon actors effectively bypass the file locking mechanisms inherent in a live Windows environment, which typically prevent direct access to the NTDS.dit file while the domain controller is operational.
7. Volt Typhoon likely uses offline password cracking techniques to decipher these hashes. This process involves extracting the hashes from the NTDS.dit file and then applying various password cracking methods, such as brute force attacks, dictionary attacks, or more sophisticated techniques like rainbow tables to uncover the plaintext passwords. The successful decryption of these passwords allows Volt Typhoon actors to obtain elevated access and further infiltrate and manipulate the network.
8. Volt Typhoon uses elevated credentials for strategic network infiltration and additional discovery, often focusing on gaining capabilities to access OT assets. Volt Typhoon actors have been observed testing access to domain-joint OT assets using default OT vendor credentials, and in certain instances, they have possessed the capability to access OT systems whose credentials were compromised via NTDS.dit theft. This access enables potential disruptions, such as manipulating heating, ventilation, and air conditioning (HVAC) systems in server rooms or disrupting critical energy and water controls, leading to significant infrastructure failures (in some cases, Volt Typhoon actors had the capability to access camera surveillance systems at critical infrastructure facilities). In one confirmed compromise, Volt Typhoon actors moved laterally to a control system and were positioned to move to a second control system.

After successfully gaining access to legitimate accounts, Volt Typhoon actors exhibit minimal activity within the compromised environment (except discovery as noted above), suggesting their objective is to maintain persistence rather than immediate exploitation. This assessment is supported by observed patterns where Volt Typhoon methodically re-targets the same organizations over extended periods, often spanning several years, to continuously validate and potentially enhance their unauthorized accesses. Evidence of their meticulous approach is seen in instances where they repeatedly exfiltrate domain credentials, ensuring access to current and valid accounts. For example, in one compromise, Volt Typhoon likely extracted NTDS.dit from three domain controllers in a four-year period. In another compromise, Volt Typhoon actors extracted NTDS.dit two times from a victim in a nine-month period.

Industry reporting—identifying that Volt Typhoon actors are silent on the network following credential dumping and perform discovery to learn about the environment, but do not exfiltrate data—is consistent with the U.S. authoring agencies’ observations. This indicates their aim is to achieve and maintain persistence on the network. In one confirmed compromise, an industry partner observed Volt Typhoon actors dumping credentials at regular intervals.

In addition to leveraging stolen account credentials, the actors use LOTL techniques and avoid leaving malware artifacts on systems that would cause alerts. Their strong focus on stealth and operational security allows them to maintain long-term, undiscovered persistence. Further, Volt Typhoon’s operational security is enhanced by targeted log deletion to conceal their actions within the compromised environment.

See the below sections for Volt Typhoon TTPs observed by the U.S. authoring agencies from multiple confirmed Volt Typhoon compromises.

Observed TTPs

Reconnaissance

Volt Typhoon actors conduct extensive pre-compromise reconnaissance [TA0043] to learn about the target organization [T1591], its network [T1590], and its staff [T1589]. This includes web searches [T1593]—including victim-owned sites [T1594]—for victim host [T1592], identity, and network information, especially for information on key network and IT administrators. According to industry reporting, Volt Typhoon actors use FOFA[1], Shodan, and Censys for querying or searching for exposed infrastructure. In some instances, the U.S. authoring agencies have observed Volt Typhoon actors targeting the personal emails of key network and IT staff [T1589.002] post compromise.

Resource Development

Historically, Volt Typhoon actors use multi-hop proxies for command and control (C2) infrastructure [T1090.003]. The proxy is typically composed of virtual private servers (VPSs) [T1583.003] or small office/home office (SOHO) routers. Recently, Volt Typhoon actors used Cisco and NETGEAR end-of-life SOHO routers implanted with KV Botnet malware to support their operations [T1584.005]. (See DOJ press release U.S. Government Disrupts Botnet People’s Republic of China Used to Conceal Hacking of Critical Infrastructure for more information).

Initial Access

To obtain initial access [TA0001], Volt Typhoon actors commonly exploit vulnerabilities in networking appliances such as those from Fortinet, Ivanti Connect Secure (formerly Pulse Secure), NETGEAR, Citrix, and Cisco [T1190]. They often use publicly available exploit code for known vulnerabilities [T1588.005] but are also adept at discovering and exploiting zero-day vulnerabilities [T1587.004].

• In one confirmed compromise, Volt Typhoon actors likely obtained initial access by exploiting CVE-2022-42475 in a network perimeter FortiGate 300D firewall that was not patched. There is evidence of a buffer overflow attack identified within the Secure Sockets Layer (SSL)-VPN crash logs.

Once initial access is achieved, Volt Typhoon actors typically shift to establishing persistent access [TA0003]. They often use VPN sessions to securely connect to victim environments [T1133], enabling discreet follow-on intrusion activities. This tactic not only provides a stable foothold in the network but also allows them to blend in with regular traffic, significantly reducing their chances of detection.

Execution

Volt Typhoon actors rarely use malware for post-compromise execution. Instead, once Volt Typhoon actors gain access to target environments, they use hands-on-keyboard activity via the command-line [T1059] and other native tools and processes on systems [T1218] (often referred to as “LOLBins”), known as LOTL, to maintain and expand access to the victim networks. According to industry reporting, some “commands appear to be exploratory or experimental, as the operators [i.e., malicious actors] adjust and repeat them multiple times.”[2]

For more details on LOTL activity, see the Credential Access and Discovery sections and Appendix A: Volt Typhoon LOTL Activity.

Similar to LOTL, Volt Typhoon actors also use legitimate but outdated versions of network admin tools. For example, in one confirmed compromise, actors downloaded [T1105] an outdated version of comsvcs.dll on the DC in a non-standard folder. comsvcs.dll is a legitimate Microsoft Dynamic Link Library (DLL) file normally found in the System32 folder. The actors used this DLL with MiniDump and the process ID of the Local Security Authority Subsystem Service (LSASS) to dump the LSASS process memory [T1003.001] and obtain credentials (LSASS process memory space contains hashes for the current user’s operating system (OS) credentials).

The actors also use legitimate non-native network admin and forensic tools. For example, Volt Typhoon actors have been observed using Magnet RAM Capture (MRC) version 1.20 on domain controllers. MRC is a free imaging tool that captures the physical memory of a computer, and Volt Typhoon actors likely used it to analyze in-memory data for sensitive information (such as credentials) and in-transit data not typically accessible on disk. Volt Typhoon actors have also been observed implanting Fast Reverse Proxy (FRP) for command and control.[3] (See the Command and Control section).

Persistence

Volt Typhoon primarily relies on valid credentials for persistence [T1078].

Defense Evasion

Volt Typhoon has strong operational security. Their actors primarily use LOTL for defense evasion [TA0005], which allows them to camouflage their malicious activity with typical system and network behavior, potentially circumventing simplistic endpoint security capabilities. For more information, see joint guide Identifying and Mitigating Living off the Land Techniques.

Volt Typhoon actors also obfuscate their malware. In one confirmed compromise, Volt Typhoon obfuscated FRP client files (BrightmetricAgent.exe and SMSvcService.exe) and the command-line port scanning utility ScanLine by packing the files with Ultimate Packer for Executables (UPX) [T1027.002]. FRP client applications support encryption, compression, and easy token authentication and work across multiple protocols—including transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), and hypertext transfer protocol secure (HTTPS). The FRP client applications use the Kuai connection protocol (KCP) for error-checked and anonymous data stream delivery over UDP, with packet-level encryption support. See Appendix C and CISA Malware Analysis Report (MAR)-10448362-1.v1 for more information.

In addition to LOTL and obfuscation techniques, Volt Typhoon actors have been observed selectively clearing Windows Event Logs [T1070.001], system logs, and other technical artifacts to remove evidence [T1070.009] of their intrusion activity and masquerading file names [T1036.005].

Credential Access

Volt Typhoon actors first obtain credentials from public-facing appliances after gaining initial access by exploiting privilege escalation vulnerabilities [T1068] in the operating system or network services. In some cases, they have obtained credentials insecurely stored on the appliance [T1552]. In one instance, where Volt Typhoon likely exploited CVE-2022-42475 in an unpatched Fortinet device, Volt Typhoon actors compromised a domain admin account stored inappropriately on the device.

Volt Typhoon also consistently obtains valid credentials by extracting the Active Directory database file (NTDS.dit)—in some cases multiple times from the same victim over long periods [T1003.003]. NTDS.dit contains usernames, hashed passwords, and group memberships for all domain accounts, essentially allowing for full domain compromise if the hashes can be cracked offline.

To obtain NTDS.dit, the U.S. authoring agencies have observed Volt Typhoon:

1. Move laterally [TA0008] to the domain controller via an interactive RDP session using a compromised account with domain administrator privileges [T1021.001];
2. Execute the Windows-native vssadmin [T1006] command to create a volume shadow copy;
3. Use Windows Management Instrumentation Console (WMIC) commands [T1047] to execute ntdsutil (a LOTL utility) to copy NTDS.dit and SYSTEM registry hive from the volume shadow copy; and
4. Exfiltrate [TA0010] NTDS.dit and SYSTEM registry hive to crack passwords offline) [T1110.002]. (For more details, including specific commands used, see Appendix A: Volt Typhoon LOTL Activity.)
   Note: A volume shadow copy contains a copy of all the files and folders that exist on the specified volume. Each volume shadow copy created on a DC includes its NTDS.dit and the SYSTEM registry hive, which provides keys to decrypt the NTDS.dit file.

Volt Typhoon actors have also been observed interacting with a PuTTY application by enumerating existing stored sessions [T1012]. Given this interaction and the exposure of cleartext-stored proxy passwords used in remote administration, Volt Typhoon actors potentially had access to PuTTY profiles that allow access to critical systems (see the Lateral Movement section).

According to industry reporting, Volt Typhoon actors attempted to dump credentials through LSASS (see Appendix B for commands used).[2]

The U.S. authoring agencies have observed Volt Typhoon actors leveraging Mimikatz to harvest credentials, and industry partners have observed Volt Typhoon leveraging Impacket.[2]

• Mimikatz is a credential dumping tool and Volt Typhoon actors use it to obtain credentials. In one confirmed compromise, the Volt Typhoon used RDP to connect to a server and run Mimikatz after leveraging a compromised administrator account to deploy it.
• Impacket is an open source Python toolkit for programmatically constructing and manipulating network protocols. It contains tools for Kerberos manipulation, Windows credential dumping, packet sniffing, and relay attacks—as well as remote service execution.

Discovery

Volt Typhoon actors have been observed using commercial tools, LOTL utilities, and appliances already present on the system for system information [T1082], network service [T1046], group [T1069] and user [T1033] discovery.

Volt Typhoon uses at least the following LOTL tools and commands for system information, network service, group, and user discovery techniques:

Some observed specific examples of discovery include:

• Capturing successful logon events [T1654].
  • Specifically, in one incident, analysis of the PowerShell console history of a domain controller indicated that security event logs were directed to a file named user.dat, as evidenced by the executed command Get-EventLog security -instanceid 4624 -after [year-month-date] | fl * | Out-File 'C:\users\public\documents\user.dat'. This indicates the group's specific interest in capturing successful logon events (event ID 4624) to analyze user authentication patterns within the network. Additionally, file system analysis, specifically of the Master File Table (MFT), uncovered evidence of a separate file, systeminfo.dat, which was created in C:\Users\Public\Documents but subsequently deleted [T1070.004]. The presence of these activities suggests a methodical approach by Volt Typhoon actors in collecting and then possibly removing traces of sensitive log information from the compromised system.
• Executing tasklist /v to gather a detailed process listing [T1057], followed by executing taskkill /f /im rdpservice.exe (the function of this executable is not known).
• Executing net user and quser for user account information [T1087.001].
• Creating and accessing a file named rult3uil.log on a domain controller in C:\Windows\System32\. The rult3uil.log file contained user activities on a compromised system, showcasing a combination of window title information [T1010] and focus shifts, keypresses, and command executions across Google Chrome and Windows PowerShell, with corresponding timestamps.
• Employing ping with various IP addresses to check network connectivity [T1016.001] and net start to list running services [T1007].

See Appendix A for additional LOTL examples.

In one confirmed compromise, Volt Typhoon actors attempted to use Advanced IP Scanner, which was on the network for admin use, to scan the network.

Volt Typhoon actors have been observed strategically targeting network administrator web browser data—focusing on both browsing history and stored credentials [T1555.003]—to facilitate targeting of personal email addresses (see the Reconnaissance section) for further discovery and possible network modifications that may impact the threat actor’s persistence within victim networks.

In one confirmed compromise:

• Volt Typhoon actors obtained the history file from the User Data directory of a network administrator user’s Chrome browser. To obtain the history file, Volt Typhoon actors first executed an RDP session to the user’s workstation where they initially attempted, and failed, to obtain the C$ File Name: users\{redacted}\appdata\local\Google\Chrome\UserData\default\History file, as evidenced by the accompanying 1016 (reopen failed) SMB error listed in the application event log. The threat actors then disconnected the RDP session to the workstation and accessed the file C:\Users\{redacted}\Downloads\History.zip. This file presumably contained data from the User Data directory of the user’s Chrome browser, which the actors likely saved in the Downloads directory for exfiltration [T1074]. Shortly after accessing the history.zip file, the actors terminated RDP sessions.
• About four months later, Volt Typhoon actors accessed the same user’s Chrome data C$ File Name: Users\{redacted}\AppData\Local\Google\Chrome\User Data\Local State and $ File Name: Users\{redacted}\AppData\Local\Google\Chrome\User Data\Default\Login Data via SMB. The Local State file contains the Advanced Encryption Standard (AES) encryption key [T1552.004] used to encrypt the passwords stored in the Chrome browser, which would enable the actors to obtain plaintext passwords stored in the Login Data file in the Chrome browser.

In another confirmed compromise, Volt Typhoon actors accessed directories containing Chrome and Edge user data on multiple systems. Directory interaction was observed over the network to paths such as C:\Users\{redacted}\AppData\Local\Google\Chrome\User Data\ and C:\Users\{redacted}\AppData\Local\Microsoft\Edge\User Data\. They also enumerated several directories, including directories containing vulnerability testing and cyber related content and facilities data, such as construction drawings [T1083].

Lateral Movement

For lateral movement, Volt Typhoon actors have been observed predominantly employing RDP with compromised valid administrator credentials. Note: With a full on-premises Microsoft Active Directory identity compromise (see the Credential Access section), the group may be capable of using other methods such as Pass the Hash or Pass the Ticket for lateral movement [T1550].

In one confirmed compromise of a Water and Wastewater Systems Sector entity, after obtaining initial access, Volt Typhoon actors connected to the network via a VPN with administrator credentials they obtained and opened an RDP session with the same credentials to move laterally. Over a nine-month period, they moved laterally to a file server, a domain controller, an Oracle Management Server (OMS), and a VMware vCenter server. The actors obtained domain credentials from the domain controller and performed discovery, collection, and exfiltration on the file server (see the Discovery and Collection and Exfiltration sections).

Volt Typhoon’s movement to the vCenter server was likely strategic for pre-positioning to OT assets. The vCenter server was adjacent to OT assets, and Volt Typhoon actors were observed interacting with the PuTTY application on the server by enumerating existing stored sessions. With this information, Volt Typhoon potentially had access to a range of critical PuTTY profiles, including those for water treatment plants, water wells, an electrical substation, OT systems, and network security devices. This would enable them to access these critical systems [T1563]. See Figure 2.

Additionally, Volt Typhoon actors have been observed using PSExec to execute remote processes, including the automated acceptance of the end-user license agreement (EULA) through an administrative account, signified by the accepteula command flag.

Volt Typhoon actors may have attempted to move laterally to a cloud environment in one victim’s network but direct attribution to the Volt Typhoon group was inconclusive. During the period of the their known network presence, there were anomalous login attempts to an Azure tenant [T1021.007] potentially using credentials [T1078.004] previously compromised from theft of NTDS.dit. These attempts, coupled with misconfigured virtual machines with open RDP ports, suggested a potential for cloud-based lateral movement. However, subsequent investigations, including password changes and multifactor authentication (MFA) implementations, revealed authentication failures from non-associated IP addresses, with no definitive link to Volt Typhoon.

Collection and Exfiltration

The U.S. authoring agencies assess Volt Typhoon primarily collects information that would facilitate follow-on actions with physical impacts. For example, in one confirmed compromise, they collected [TA0009] sensitive information obtained from a file server in multiple zipped files [T1560] and likely exfiltrated [TA0010] the files via Server Message Block (SMB) [T1048] (see Figure 3). Collected information included diagrams and documentation related to OT equipment, including supervisory control and data acquisition (SCADA) systems, relays, and switchgear. This data is crucial for understanding and potentially impacting critical infrastructure systems, indicating a focus on gathering intelligence that could be leveraged in actions targeting physical assets and systems.

In another compromise, Volt Typhoon actors leveraged WMIC to create and use temporary directories (C:\Users\Public\pro, C:\Windows\Temp\tmp, C:\Windows\Temp\tmp\Active Directory and C:\Windows\Temp\tmp\registry) to stage the extracted ntds.dit and SYSTEM registry hives from ntdsutil execution volume shadow copies (see the Credential Access section) obtained from two DCs. They then compressed and archived the extracted ntds.dit and accompanying registry files by executing ronf.exe, which was likely a renamed version of the archive utility rar.exe) [T1560.001].

Command and Control

Volt Typhoon actors have been observed leveraging compromised SOHO routers and virtual private servers (VPS) to proxy C2 traffic. For more information, see DOJ press release U.S. Government Disrupts Botnet People’s Republic of China Used to Conceal Hacking of Critical Infrastructure).

They have also been observed setting up FRP clients [T1090] on a victim’s corporate infrastructure to establish covert communications channels [T1573] for command and control. In one instance, Volt Typhoon actors implanted the FRP client with filename SMSvcService.exe on a Shortel Enterprise Contact Center (ECC) server and a second FRP client with filename Brightmetricagent.exe on another server. These clients, when executed via PowerShell [T1059.001], open reverse proxies between the compromised system and Volt Typhoon C2 servers. Brightmetricagent.exe has additional capabilities. The FRP client can locate servers behind a network firewall or obscured through Network Address Translation (NAT) [T1016]. It also contains multiplexer libraries that can bi-directionally stream data over NAT networks and contains a command-line interface (CLI) library that can leverage command shells such as PowerShell, Windows Management Instrumentation (WMI), and Z Shell (zsh) [T1059.004]. See Appendix C and MAR-10448362-1.v1 for more information.

In the same compromise, Volt Typhoon actors exploited a Paessler Router Traffic Grapher (PRTG) server as an intermediary for their FRP operations. To facilitate this, they used the netsh command, a legitimate Windows command, to create a PortProxy registry modification [T1112] on the PRTG server [T1090.001]. This key alteration redirected specific port traffic to Volt Typhoon’s proxy infrastructure, effectively converting the PRTG’s server into a proxy for their C2 traffic [T1584.004] (see Appendix B for details).

DETECTION/HUNT RECOMMENDATIONS

Apply Living off the Land Detection Best Practices

Apply the prioritized detection and hardening best practice recommendations provided in joint guide Identifying and Mitigating Living off the Land Techniques. Many organizations lack security and network management best practices (such as established baselines) that support detection of malicious LOTL activity—this makes it difficult for network defenders to discern legitimate behavior from malicious behavior and conduct behavior analytics, anomaly detection, and proactive hunting. Conventional IOCs associated with the malicious activity are generally lacking, complicating network defenders’ efforts to identify, track, and categorize this sort of malicious behavior. This advisory provides guidance for a multifaceted cybersecurity strategy that enables behavior analytics, anomaly detection, and proactive hunting, which are part of a comprehensive approach to mitigating cyber threats that employ LOTL techniques.

Review Application, Security, and System Event Logs

Routinely review application, security, and system event logs, focusing on Windows Extensible Storage Engine Technology (ESENT) Application Logs. Due to Volt Typhoon’s ability for long-term undetected persistence, network defenders should assume significant dwell time and review specific application event log IDs, which remain on endpoints for longer periods compared to security event logs and other ephemeral artifacts. Focus on Windows ESENT logs because certain ESENT Application Log event IDs (216, 325, 326, and 327) may indicate actors copying NTDS.dit.

See Table 1 for examples of ESENT and other key log indicators that should be investigated. Please note that incidents may not always have exact matches listed in the Event Detail column due to variations in event logging and TTPs.

Monitor and Review OT System Logs

• Review access logs for communication paths between IT and OT networks, looking for anomalous accesses or protocols.
• Measure the baseline of normal operations and network traffic for the industrial control system (ICS) and assess traffic anomalies for malicious activity.
• Configure intrusion detection systems (IDS) to create alarms for any ICS network traffic outside normal operations.
• Track and monitor audit trails on critical areas of ICS.
• Set up security incident and event monitoring (SIEM) to monitor, analyze, and correlate event logs from across the ICS network to identify intrusion attempts.

Review CISA’s Recommended Cybersecurity Practices for Industrial Control Systems and the joint advisory, NSA and CISA Recommend Immediate Actions to Reduce Exposure Across all Operational Technologies and Control Systems, for further OT system detection and mitigation guidance.

Use gait to Detect Possible Network Proxy Activities

Use gait[4] to detect network proxy activities. Developed by Sandia National Labs, gait is a publicly available Zeek[5] extension. The gait extension can help enrich Zeek’s network connection monitoring and SSL logs by including additional metadata in the logs. Specifically, gait captures unique TCP options and timing data such as a TCP, transport layer security (TLS), and Secure Shell (SSH) layer inferred round trip times (RTT), aiding in the identification of the software used by both endpoints and intermediaries.

While the gait extension for Zeek is an effective tool for enriching network monitoring logs with detailed metadata, it is not specifically designed to detect Volt Typhoon actor activities. The extension’s capabilities extend to general anomaly detection in network traffic, including—but not limited to—proxying activities. Therefore, while gait can be helpful in identifying tactics similar to those used by Volt Typhoon, such as proxy networks and FRP clients for C2 communication, not all proxying activities detected by using this additional metadata are necessarily indicative of Volt Typhoon presence. It serves as a valuable augmentation to current security stacks for a broader spectrum of threat detection.

For more information, see Sandia National Lab’s gait GitHub page sandialabs/gait: Zeek Extension to Collect Metadata for Profiling of Endpoints and Proxies.

Review Logins for Impossible Travel

Examine VPN or other account logon times, frequency, duration, and locations. Logons from two geographically distant locations within a short timeframe from a single user may indicate an account is being used maliciously. Logons of unusual frequency or duration may indicate a threat actor attempting to access a system repeatedly or maintain prolonged sessions for the purpose of data extraction.

Review Standard Directories for Unusual Files

Review directories, such as C:\windows\temp\ and C:\users\public\, for unexpected or unusual files. Monitor these temporary file storage directories for files typically located in standard system paths, such as the System32 directory. For example, Volt Typhoon has been observed downloading comsvcs.dll to a non-standard folder (this file is normally found in the System32 folder).

INCIDENT RESPONSE

If compromise, or potential compromise, is detected, organizations should assume full domain compromise because of Volt Typhoon’s known behavioral pattern of extracting the NTDS.dit from the DCs. Organizations should immediately implement the following immediate, defensive countermeasures:

1. Sever the enterprise network from the internet. Note: this step requires the agency to understand its internal and external connections. When making the decision to sever internet access, knowledge of connections must be combined with care to avoid disrupting critical functions.
   • If you cannot sever from the internet, shutdown all non-essential traffic between the affected enterprise network and the internet.
2. Reset credentials of privileged and non-privileged accounts within the trust boundary of each compromised account.
   • Reset passwords for all domain users and all local accounts, such as Guest, HelpAssistant, DefaultAccount, System, Administrator, and krbtgt. The krbtgt account is responsible for handling Kerberos ticket requests as well as encrypting and signing them. The krbtgt account should be reset twice because the account has a two-password history. The first account reset for the krbtgt needs to be allowed to replicate prior to the second reset to avoid any issues. See CISA’s Eviction Guidance for Networks Affected by the SolarWinds and Active Directory/M365 Compromise for more information. Although tailored to FCEB agencies compromised in the 2020 SolarWinds Orion supply chain compromise, the steps are applicable to organizations with Windows AD compromise.
     • Review access policies to temporarily revoke privileges/access for affected accounts/devices. If it is necessary to not alert the attacker (e.g., for intelligence purposes), then privileges can be reduced for affected accounts/devices to “contain” them.
   • Reset the relevant account credentials or access keys if the investigation finds the threat actor’s access is limited to non-elevated permissions.
     • Monitor related accounts, especially administrative accounts, for any further signs of unauthorized access.
3. Audit all network appliance and edge device configurations with indicators of malicious activity for signs of unauthorized or malicious configuration changes. Organizations should ensure they audit the current network device running configuration and any local configurations that could be loaded at boot time. If configuration changes are identified:
   • Change all credentials being used to manage network devices, to include keys and strings used to secure network device functions (SNMP strings/user credentials, IPsec/IKE preshared keys, routing secrets, TACACS/RADIUS secrets, RSA keys/certificates, etc.).
   • Update all firmware and software to the latest version.
4. Report the compromise to an authoring agency (see the Contact Information section).
5. For organizations with cloud or hybrid environments, apply best practices for identity and credential access management. 
   • Verify that all accounts with privileged role assignments are cloud native, not synced from Active Directory.
   • Audit conditional access policies to ensure Global Administrators and other highly privileged service principals and accounts are not exempted.
   • Audit privileged role assignments to ensure adherence to the principle of least privilege when assigning privileged roles.
   • Leverage just-in-time and just-enough access mechanisms when administrators need to elevate to a privileged role.
   • In hybrid environments, ensure federated systems (such as AD FS) are configured and monitored properly.
   • Audit Enterprise Applications for recently added applications and examine the API permissions assigned to each.
6. Reconnect to the internet. Note: The decision to reconnect to the internet depends on senior leadership’s confidence in the actions taken. It is possible—depending on the environment—that new information discovered during pre-eviction and eviction steps could add additional eviction tasks.
7. Minimize and control use of remote access tools and protocols by applying best practices from joint Guide to Securing Remote Access Software and joint Cybersecurity Information Sheet: Keeping PowerShell: Security Measures to Use and Embrace.
8. Consider sharing technical information with an authoring agency and/or a sector-specific information sharing and analysis center.

For more information on incident response and remediation, see:

• Joint advisory Technical Approaches to Uncovering and Remediating Malicious Activity. This advisory provides incident response best practices.
• CISA’s Federal Government Cybersecurity Incident and Vulnerability Response Playbooks. Although tailored to U.S. Federal Civilian Executive Branch (FCEB) agencies, the playbooks are applicable to all organizations. The incident response playbook provides procedures to identify, coordinate, remediate, recover, and track successful mitigations from incidents.
• Joint Water and Wastewater Sector - Incident Response Guide. This joint guide provides incident response best practices and information on federal resources for Water and Wastewater Systems Sector organizations.

MITIGATIONS

These mitigations are intended for IT administrators in critical infrastructure organizations. The authoring agencies recommend that software manufactures incorporate secure by design and default principles and tactics into their software development practices to strengthen the security posture for their customers.

For information on secure by design practices that may protect customers against common Volt Typhoon techniques, see joint guide Identifying and Mitigating Living off the Land Techniques and joint Secure by Design Alert Security Design Improvements for SOHO Device Manufacturers.

For more information on secure by design, see CISA’s Secure by Design webpage and joint guide.

The authoring agencies recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture on the basis of Volt Typhoon activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.

IT Network Administrators and Defenders

Harden the Attack Surface

• Apply patches for internet-facing systems within a risk-informed span of time [CPG 1E]. Prioritize patching critical assets, known exploited vulnerabilities, and vulnerabilities in appliances known to be frequently exploited by Volt Typhoon (e.g., Fortinet, Ivanti, NETGEAR, Citrix, and Cisco devices).
• Apply vendor-provided or industry standard hardening guidance to strengthen software and system configurations. Note: As part of CISA’s Secure by Design campaign, CISA urges software manufacturers to prioritize secure by default configurations to eliminate the need for customer implementation of hardening guidelines.
• Maintain and regularly update an inventory of all organizational IT assets [CPG 1A].
• Use third party assessments to validate current system and network security compliance via security architecture reviews, penetration tests, bug bounties, attack surface management services, incident simulations, or table-top exercises (both announced and unannounced) [CPG 1F].
• Limit internet exposure of systems when not necessary. An organization’s primary attack surface is the combination of the exposure of all its internet-facing systems. Decrease the attack surface by not exposing systems or management interfaces to the internet when not necessary.
• Plan “end of life” for technology beyond manufacturer supported lifecycle. Inventories of organizational assets should be leveraged in patch and configuration management as noted above. Inventories will also enable identification of technology beyond the manufacturer’s supported lifecycle. Where technology is beyond “end of life” or “end of support,” additional cybersecurity vigilance is necessary, and may warrant one or more of the following:
  • Supplemental support agreements;
  • Additional scanning and testing;
  • Configuration changes;
  • Isolation;
  • Segmentation; and
  • Development of forward-looking plans to facilitate replacement.

Secure Credentials

• Do not store credentials on edge appliances/devices. Ensure edge devices do not contain accounts that could provide domain admin access.
• Do not store plaintext credentials on any system [CPG 2L]. Credentials should be stored securely—such as with a credential/password manager or vault, or other privileged account management solutions—so they can only be accessed by authenticated and authorized users.
• Change default passwords [CPG 2A] and ensure they meet the policy requirements for complexity.
• Implement and enforce an organizational system-enforced policy that:
  • Requires passwords for all IT password-protected assets to be at least 15 characters;
  • Does not allow users to reuse passwords for accounts, applications, services, etc., [CPG 2C]; and
  • Does not allow service accounts/machine accounts to reuse passwords from member user accounts.
• Configure Group Policy settings to prevent web browsers from saving passwords and disable autofill functions.
• Disable the storage of clear text passwords in LSASS memory.

Secure Accounts

• Implement phishing-resistant MFA for access to assets [CPG 2H].
• Separate user and privileged accounts.
  • User accounts should never have administrator or super-user privileges [CPG 2E].
  • Administrators should never use administrator accounts for actions and activities not associated with the administrator role (e.g., checking email, web browsing).
• Enforce the principle of least privilege.
  • Ensure administrator accounts only have the minimum permissions necessary to complete their tasks.
  • Review account permissions for default/accounts for edge appliances/devices and remove domain administrator privileges, if identified.
  • Significantly limit the number of users with elevated privileges. Implement continuous monitoring for changes in group membership, especially in privileged groups, to detect and respond to unauthorized modifications.
  • Remove accounts from high-privilege groups like Enterprise Admins and Schema Admins. Temporarily reinstate these privileges only when necessary and under strict auditing to reduce the risk of privilege abuse.
  • Transition to Group Managed Service Accounts (gMSAs) where suitable for enhanced management and security of service account credentials. gMSAs provide automated password management and simplified Service Principal Name (SPN) management, enhancing security over traditional service accounts. See Microsoft’s Group Managed Service Accounts Overview.
• Enforce strict policies via Group Policy and User Rights Assignments to limit high-privilege service accounts.
• Consider using a privileged access management (PAM) solution to manage access to privileged accounts and resources [CPG 2L]. PAM solutions can also log and alert usage to detect any unusual activity.
• Complement the PAM solution with role-based access control (RBAC) for tailored access based on job requirements. This ensures that elevated access is granted only when required and for a limited duration, minimizing the window of opportunity for abuse or exploitation of privileged credentials.
• Implement an Active Directory tiering model to segregate administrative accounts based on their access level and associated risk. This approach reduces the potential impact of a compromised account. See Microsoft’s PAM environment tier model.
• Harden administrative workstations to only permit administrative activities from workstations appropriately hardened based on the administrative tier. See Microsoft’s Why are privileged access devices important - Privileged access.
• Disable all user accounts and access to organizational resources of employees on the day of their departure [CPG 2G]
• Regularly audit all user, admin, and service accounts and remove or disable unused or unneeded accounts as applicable.
• Regularly roll NTLM hashes of accounts that support token-based authentication.
• Improve management of hybrid (cloud and on-premises) identity federation by:
  • Using cloud only administrators that are asynchronous with on-premises environments and ensuring on-premises administrators are asynchronous to the cloud.
  • Using CISA’s SCuBAGear tool to discover cloud misconfigurations in Microsoft cloud tenants. SCuBA gear is automation script for comparing Federal Civilian Executive Branch (FCEB) agency tenant configurations against CISA M365 baseline recommendations. SCuBAGear is part of CISA’s Secure Cloud Business Applications (SCuBA) project, which provides guidance for FCEB agencies, securing their cloud business application environments and protecting federal information created, accessed, shared, and stored in those environments. Although tailored to FCEB agencies, the project provides security guidance applicable to all organizations with cloud environments. For more information on SCuBAGear see CISA’s Secure Cloud Business Applications (SCuBA) Project.
  • Using endpoint detection and response capabilities to actively defend on-premises federation servers.

Secure Remote Access Services

• Limit the use of RDP and other remote desktop services. If RDP is necessary, apply best practices, including auditing the network for systems using RDP, closing unused RDP ports, and logging RDP login attempts.
• Disable Server Message Block (SMB) protocol version 1 and upgrade to version 3 (SMBv3) after mitigating existing dependencies (on existing systems or applications), as they may break when disabled.
• Harden SMBv3 by implementing guidance included in joint #StopRansomware Guide (see page 8 of the guide).
• Apply mitigations from the joint Guide to Securing Remote Access Software.

Secure Sensitive Data

• Securely store sensitive data (including operational technology documentation, network diagrams, etc.), ensuring that only authenticated and authorized users can access the data.

Implement Network Segmentation

• Ensure that sensitive accounts use their administrator credentials only on hardened, secure computers. This practice can reduce lateral movement exposure within networks.
• Conduct comprehensive trust assessments to identify business-critical trusts and apply necessary controls to prevent unauthorized cross-forest/domain traversal.
• Harden federated authentication by enabling Secure Identifier (SID) Filtering and Selective Authentication on AD trust relationships to further restrict unauthorized access across domain boundaries.
• Implement network segmentation to isolate federation servers from other systems and limit allowed traffic to systems and protocols that require access in accordance with Zero Trust principles.

Secure Cloud Assets

• Harden cloud assets in accordance with vendor-provided or industry standard hardening guidance.
  • Organizations with Microsoft cloud infrastructure, see CISA’s Microsoft 365 Security Configuration Baseline Guides, which provide minimum viable secure configuration baselines for Microsoft Defender for Office 365, Azure Active Directory (now known as Microsoft Entra ID), Exchange Online, OneDrive for Business, Power BI, Power Platform, SharePoint Online, and Teams. For additional guidance, see the Australian Signals Directorate’s Blueprint for Secure Cloud.
  • Organizations with Google cloud infrastructure, see CISA’s Google Workspace Security Configuration Baseline Guides, which provide minimum viable secure configuration baselines for Groups for Business, GMAIL, Google Calendar, Google Chat, Google Common Controls, Google Classroom, Google Drive and Docs, Google Meet, and Google Sites.
• Revoke unnecessary public access to cloud environment. This involves reviewing and restricting public endpoints and ensuring that services like storage accounts, databases, and virtual machines are not publicly accessible unless absolutely necessary. Disable legacy authentication protocols across all cloud services and platforms. Legacy protocols frequently lack support for advanced security mechanisms such as multifactor authentication, rendering them susceptible to compromises. Instead, enforce the use of modern authentication protocols that support stronger security features like MFA, token-based authentication, and adaptive authentication measures.
  • Enforce this practice through the use of Conditional Access Policies. These policies can initially be run in report-only mode to identify potential impacts and plan mitigations before fully enforcing them. This approach allows organizations to systematically control access to their cloud resources, significantly reducing the risk of unauthorized access and potential compromise.
• Regularly monitor and audit privileged cloud-based accounts, including service accounts, which are frequently abused to enable broad cloud resource access and persistence.

Be Prepared

• Ensure logging is turned on for application, access, and security logs (e.g., intrusion detection systems/intrusion prevention systems, firewall, data loss prevention, and VPNs) [CPG 2T]. Given Volt Typhoon’s use of LOTL techniques and their significant dwell time, application event logs may be a valuable resource to hunt for Volt Typhoon activity because these logs typically remain on endpoints for relatively long periods of time.
  • For OT assets where logs are non-standard or not available, collect network traffic and communications between those assets and other assets.
  • Implement file integrity monitoring (FIM) tools to detect unauthorized changes.
• Store logs in a central system, such as a security information and event management (SIEM) tool or central database.
  • Ensure the logs can only be accessed or modified by authorized and authenticated users [CPG 2U].
  • Store logs for a period informed by risk or pertinent regulatory guidelines.
  • Tune log alerting to reduce noise while ensuring there are alerts for high-risk activities. (For information on alert tuning, see joint guide Identifying and Mitigating Living Off the Land Techniques.)
• Establish and continuously maintain a baseline of installed tools and software, account behavior, and network traffic. This way, network defenders can identify potential outliers, which may indicate malicious activity. Note: For information on establishing a baseline, see joint guide Identifying and Mitigating Living off the Land Techniques.
• Document a list of threats and cyber actor TTPs relevant to your organization (e.g., based on industry or sectors), and maintain the ability (such as via rules, alerting, or commercial prevention and detection systems) to detect instances of those key threats [CPG 3A].
• Implement periodic training for all employees and contractors that covers basic security concepts (such as phishing, business email compromise, basic operational security, password security, etc.), as well as fostering an internal culture of security and cyber awareness [CPG 2I].
  • Tailor the training to network IT personnel/administrators and other key staff based on relevant organizational cyber threats and TTPs, such as Volt Typhoon. For example, communicate that Volt Typhoon actors are known to target personal email accounts of IT staff, and encourage staff to protect their personal email accounts by using strong passwords and implementing MFA.
  • In addition to basic cybersecurity training, ensure personnel who maintain or secure OT as part of their regular duties receive OT-specific cybersecurity training on at least an annual basis [CPG 2J].
  • Educate users about the risks associated with storing unprotected passwords.

OT Administrators and Defenders

• Change default passwords [CPG 2A] and ensure they meet the policy requirements for complexity. If the asset’s password cannot be changed, implement compensating controls for the device; for example, segment the device into separate enclaves and implement increased monitoring and logging.
• Require that passwords for all OT password-protected assets be at least 15 characters, when technically feasible. In instances where minimum passwords lengths are not technically feasible (for example, assets in remote locations), apply compensating controls, record the controls, and log all login attempts. [CPG 2B].
• Enforce strict access policies for accessing OT networks. Develop strict operating procedures for OT operators that details secure configuration and usage.
• Segment OT assets from IT environments by [CPG 2F]:
  • Denying all connections to the OT network by default unless explicitly allowed (e.g., by IP address and port) for specific system functionality.
  • Requiring necessary communications paths between IT and OT networks to pass through an intermediary, such as a properly configured firewall, bastion host, “jump box,” or a demilitarized zone (DMZ), which is closely monitored, captures network logs, and only allows connections from approved assets.
• Closely monitor all connections into OT networks for misuse, anomalous activity, or OT protocols.
• Monitor for unauthorized controller change attempts. Implement integrity checks of controller process logic against a known good baseline. Ensure process controllers are prevented from remaining in remote program mode while in operation if possible.
• Lock or limit set points in control processes to reduce the consequences of unauthorized controller access.
• Be prepared by:
  • Determining your critical operational processes’ reliance on key IT infrastructure:
    • Maintain and regularly update an inventory of all organizational OT assets.
    • Understand and evaluate cyber risk on “as-operated” OT assets.
    • Create an accurate “as-operated” OT network map and identify OT and IT network inter-dependencies.
  • Identifying a resilience plan that addresses how to operate if you lose access to or control of the IT and/or OT environment.
    • Plan for how to continue operations if a control system is malfunctioning, inoperative, or actively acting contrary to the safe and reliable operation of the process.
    • Develop workarounds or manual controls to ensure ICS networks can be isolated if the connection to a compromised IT environment creates risk to the safe and reliable operation of OT processes.
  • Create and regularly exercise an incident response plan.
    • Regularly test manual controls so that critical functions can be kept running if OT networks need to be taken offline.
  • Implement regular data backup procedures on OT networks.
    • Regularly test backup procedures.
• Follow risk-informed guidance in the joint advisory NSA and CISA Recommend Immediate Actions to Reduce Exposure Across all Operational Technologies and Control Systems, the NSA advisory Stop Malicious Cyber Activity Against Connected Operational Technology.

CONTACT INFORMATION

US organizations: To report suspicious or criminal activity related to information found in this joint Cybersecurity Advisory, contact:

• CISA’s 24/7 Operations Center at [email protected] or 1-844-Say-CISA (1-844-729-2472) or your local FBI field office. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact.
• For NSA client requirements or general cybersecurity inquiries, contact [email protected].
• Water and Wastewater Systems Sector organizations, contact the EPA Water Infrastructure and Cyber Resilience Division at [email protected] to voluntarily provide situational awareness.
• Entities required to report incidents to DOE should follow established reporting requirements, as appropriate. For other energy sector inquiries, contact [email protected].
• For transportation entities regulated by TSA, report to CISA Central in accordance with the requirements found in applicable Security Directives, Security Programs, or TSA Order.

Australian organizations: Visit cyber.gov.au or call 1300 292 371 (1300 CYBER 1) to report cybersecurity incidents and access alerts and advisories.

Canadian organizations: Report incidents by emailing CCCS at [email protected].

New Zealand organizations: Report cyber security incidents to [email protected] or call 04 498 7654.

United Kingdom organizations: Report a significant cyber security incident: ncsc.gov.uk/report-an-incident (monitored 24 hours) or, for urgent assistance, call 03000 200 973.

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, the authoring agencies recommend exercising, testing, and validating your organization's security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. The authoring agencies recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

1. Select an ATT&CK technique described in this advisory (see Table 5 through Table 17).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies’ performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The authoring agencies recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

REFERENCES

[1] fofa
[2] Microsoft: Volt Typhoon targets US critical infrastructure with living-off-the-land techniques
[3] GitHub - fatedier/frp: A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet
[4] GitHub - sandialabs/gait: Zeek Extension to Collect Metadata for Profiling of Endpoints and Proxies
[5] The Zeek Network Security Monitor

RESOURCES

Microsoft: Volt Typhoon targets US critical infrastructure with living-off-the-land techniques
Secureworks: Chinese Cyberespionage Group BRONZE SILHOUETTE Targets U.S. Government and Defense Organizations

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. The authoring agencies do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by the authoring agencies.

ACKNOWLEDGEMENTS

Fortinet and Microsoft contributed to this advisory.

VERSION HISTORY

February 7, 2024: Initial Version.
March 7, 2024: Updated Mitigations section to add recommendation on “end of life” technology.

APPENDIX A: VOLT TYPHOON OBSERVED COMMANDS / LOTL ACTIVITY

See Table 2 and Table 3 for Volt Typhoon commands and PowerShell scripts observed by the U.S. authoring agencies during incident response activities. For additional commands used by Volt Typhoon, see joint advisory People's Republic of China State-Sponsored Cyber Actor Living off the Land to Evade Detection.

APPENDIX B: INDICATORS OF COMPROMISE

See Table 4 for Volt Typhoon IOCs obtained by the U.S. authoring agencies during incident response activities.

Note: See MAR-10448362-1.v1 for more information on this malware.

APPENDIX C: MITRE ATT&CK TACTICS AND TECHNIQUES

See Table 5 through Table 17 for all referenced threat actor tactics and techniques in this advisory.