CISA has added six new vulnerabilities to its Known Exploited Vulnerabilities Catalog, based on evidence of active exploitation.

• CVE-2024-38189 Microsoft Project Remote Code Execution Vulnerability
• CVE-2024-38178 Microsoft Windows Scripting Engine Memory Corruption Vulnerability
• CVE-2024-38213 Microsoft Windows SmartScreen Security Feature Bypass Vulnerability
• CVE-2024-38193 Microsoft Windows Ancillary Function Driver for WinSock Privilege Escalation Vulnerability
• CVE-2024-38106 Microsoft Windows Kernel Privilege Escalation Vulnerability
• CVE-2024-38107 Microsoft Windows Power Dependency Coordinator Privilege Escalation Vulnerability

These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise.

Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities established the Known Exploited Vulnerabilities Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the BOD 22-01 Fact Sheet for more information.

Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the specified criteria.

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 15. See the MITRE ATT&CK Tactics and Techniques section for a table of the red team’s activity mapped to MITRE ATT&CK tactics and techniques with corresponding mitigation and/or detection recommendations. 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.

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 bug bounty program. 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]. The red team used that TGT 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, 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, which prevented 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.
  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.

SUMMARY

Note: This joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

The Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), Department of Health and Human Services (HHS), and Multi-State Information Sharing and Analysis Center (MS-ISAC) (hereafter referred to as the authoring organizations) are releasing this joint CSA to provide information on Black Basta, a ransomware variant whose actors have encrypted and stolen data from at least 12 out of 16 critical infrastructure sectors, including the Healthcare and Public Health (HPH) Sector.

This joint CSA provides TTPs and IOCs obtained from FBI investigations and third-party reporting. Black Basta is considered a ransomware-as-a-service (RaaS) variant and was first identified in April 2022. Black Basta affiliates have impacted a wide range of businesses and critical infrastructure in North America, Europe, and Australia. As of May 2024, Black Basta affiliates have impacted over 500 organizations globally.

Black Basta affiliates use common initial access techniques—such as phishing and exploiting known vulnerabilities—and then employ a double-extortion model, both encrypting systems and exfiltrating data. Ransom notes do not generally include an initial ransom demand or payment instructions. Instead, the notes provide victims with a unique code and instructs them to contact the ransomware group via a .onion URL (reachable through the Tor browser). Typically, the ransom notes give victims between 10 and 12 days to pay the ransom before the ransomware group publishes their data on the Black Basta TOR site, Basta News.

Healthcare organizations are attractive targets for cybercrime actors due to their size, technological dependence, access to personal health information, and unique impacts from patient care disruptions. The authoring organizations urge HPH Sector and all critical infrastructure organizations to apply the recommendations in the Mitigations section of this CSA to reduce the likelihood of compromise from Black Basta and other ransomware attacks. Victims of ransomware should report the incident to their local FBI field office or CISA (see the Reporting section for contact information).

Download the PDF version of this report:

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK for Enterprise framework, version 15. See the MITRE ATT&CK Tactics and Techniques section for a table of the 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.

Initial Access

Black Basta affiliates primarily use spearphishing [T1566] to obtain initial access. According to cybersecurity researchers, affiliates have also used Qakbot during initial access.[1]

Starting in February 2024, Black Basta affiliates began exploiting ConnectWise vulnerability CVE-2024-1709 [CWE-288] [T1190]. In some instances, affiliates have been observed abusing valid credentials [T1078].

Discovery and Execution

Black Basta affiliates use tools such as SoftPerfect network scanner (netscan.exe) to conduct network scanning. Cybersecurity researchers have observed affiliates conducting reconnaissance using utilities with innocuous file names such as Intel or Dell, left in the root drive C: [T1036].[1]

Lateral Movement

Black Basta affiliates use tools such as BITSAdmin and PsExec, along with Remote Desktop Protocol (RDP), for lateral movement. Some affiliates also use tools like Splashtop, Screen Connect, and Cobalt Strike beacons to assist with remote access and lateral movement.

Privilege Escalation and Lateral Movement

Black Basta affiliates use credential scraping tools like Mimikatz for privilege escalation. According to cybersecurity researchers, Black Basta affiliates have also exploited ZeroLogon (CVE-2020-1472, [CWE-330]), NoPac (CVE-2021-42278 [CWE-20] and CVE-2021-42287 [CWE-269]), and PrintNightmare (CVE-2021-34527, [CWE-269]) vulnerabilities for local and Windows Active Domain privilege escalation [T1068].[1],[2]

Exfiltration and Encryption

Black Basta affiliates use RClone to facilitate data exfiltration prior to encryption. Prior to exfiltration, cybersecurity researchers have observed Black Basta affiliates using PowerShell [T1059.001] to disable antivirus products, and in some instances, deploying a tool called Backstab, designed to disable endpoint detection and response (EDR) tooling [T1562.001].[3] Once antivirus programs are terminated, a ChaCha20 algorithm with an RSA-4096 public key fully encrypts files [T1486]. A .basta or otherwise random file extension is added to file names and a ransom note titled readme.txt is left on the compromised system.[4] To further inhibit system recovery, affiliates use the vssadmin.exe program to delete volume shadow copies [T1490].[5]

Leveraged Tools

See Table 1 for publicly available tools and applications used by Black Basta affiliates. This includes legitimate tools repurposed for their operations.

Disclaimer: Use of these tools and applications should not be attributed as malicious without analytical evidence to support threat actor use and/or control.

MITRE ATT&CK TACTICS AND TECHNIQUES

See Tables 2–6 for all referenced threat actor tactics and techniques in this advisory.

View CSAF

1. EXECUTIVE SUMMARY

• CVSS v4 8.5
• ATTENTION: Low attack complexity
• Vendor: Delta Electronics
• Equipment: CNCSoft-G2 DOPSoft
• Vulnerability: Stack-based Buffer Overflow

2. RISK EVALUATION

Successful exploitation of this vulnerability could allow an attacker to execute arbitrary code.

3. TECHNICAL DETAILS

3.1 AFFECTED PRODUCTS

The following versions of Delta Electronics CNCSoft-G2, a Human-Machine Interface (HMI) software, are affected:

• CNCSoft-G2: Versions 2.0.0.5 (with DOPSoft v5.0.0.93) and prior

3.2 Vulnerability Overview

3.2.1 STACK-BASED BUFFER OVERFLOW CWE-121

Delta Electronics CNCSoft-G2 lacks proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process.

CVE-2024-4192 has been assigned to this vulnerability. A CVSS v3.1 base score of 7.8 has been calculated; the CVSS vector string is (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H ).

A CVSS v4 score has also been calculated for CVE-2024-4192. A base score of 8.5 has been calculated; the CVSS vector string is (CVSS4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N).

3.3 BACKGROUND

• CRITICAL INFRASTRUCTURE SECTORS: Energy, Critical Manufacturing
• COUNTRIES/AREAS DEPLOYED: Worldwide
• COMPANY HEADQUARTERS LOCATION: Taiwan

3.4 RESEARCHER

Natnael Samson working with Trend Micro Zero Day Initiative reported this vulnerability to CISA.

4. MITIGATIONS

Delta Electronics recommends users update to CNCSoft-G2 v2.1.0.4 or later.

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability, such as:

• Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.
• Locate control system networks and remote devices behind firewalls and isolating them from business networks.
• When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

• Do not click web links or open attachments in unsolicited email messages.
• Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.
• Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely.

5. UPDATE HISTORY

• April 30, 2024: Initial Publication

How SVR-Attributed Actors are Adapting to the Move of Government and Corporations to Cloud Infrastructure

OVERVIEW

This advisory details recent tactics, techniques, and procedures (TTPs) of the group commonly known as APT29, also known as Midnight Blizzard, the Dukes, or Cozy Bear.

The UK National Cyber Security Centre (NCSC) and international partners assess that APT29 is a cyber espionage group, almost certainly part of the SVR, an element of the Russian intelligence services. The US National Security Agency (NSA), the US Cybersecurity and Infrastructure Security Agency (CISA), the US Cyber National Mission Force (CNMF), the Federal Bureau of Investigation (FBI), Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), the Canadian Centre for Cyber Security (CCCS), and New Zealand Government Communications Security Bureau (GCSB) agree with this attribution and the details provided in this advisory.

This advisory provides an overview of TTPs deployed by the actor to gain initial access into the cloud environment and includes advice to detect and mitigate this activity.

To download the PDF version of this report, click here.

PREVIOUS ACTOR ACTIVITY

The NCSC has previously detailed how Russian Foreign Intelligence Service (SVR) cyber actors have targeted governmental, think tank, healthcare, and energy targets for intelligence gain. It has now observed SVR actors expanding their targeting to include aviation, education, law enforcement, local and state councils, government financial departments, and military organizations.

SVR actors are also known for:

• The supply chain compromise of SolarWinds software.
• Activity that targeted organizations developing the COVID-19 vaccine.

EVOLVING TTPs

As organizations continue to modernize their systems and move to cloud-based infrastructure, the SVR has adapted to these changes in the operating environment.

They have to move beyond their traditional means of initial access, such as exploiting software vulnerabilities in an on-premises network, and instead target the cloud services themselves.

To access the majority of the victims’ cloud hosted network, actors must first successfully authenticate to the cloud provider. Denying initial access to the cloud environment can prohibit SVR from successfully compromising their target. In contrast, in an on-premises system, more of the network is typically exposed to threat actors.

Below describes in more detail how SVR actors are adapting to continue their cyber operations for intelligence gain. These TTPs have been observed in the last 12 months.

ACCESS VIA SERVICE AND DORMANT ACCOUNTS

Previous SVR campaigns reveal the actors have successfully used brute forcing [T1110] and password spraying to access service accounts. This type of account is typically used to run and manage applications and services. There is no human user behind them so they cannot be easily protected with multi-factor authentication (MFA), making these accounts more susceptible to a successful compromise. Service accounts are often also highly privileged depending on which applications and services they’re responsible for managing. Gaining access to these accounts provides threat actors with privileged initial access to a network, to launch further operations.

SVR campaigns have also targeted dormant accounts belonging to users who no longer work at a victim organization but whose accounts remain on the system [T1078.004].

Following an enforced password reset for all users during an incident, SVR actors have also been observed logging into inactive accounts and following instructions to reset the password. This has allowed the actor to regain access following incident response eviction activities.

CLOUD-BASED TOKEN AUTHENTICATION

Account access is typically authenticated by either username and password credentials or system-issued access tokens. The NCSC and partners have observed SVR actors using tokens to access their victims’ accounts, without needing a password [T1528].

The default validity time of system-issued tokens varies dependent on the system; however, cloud platforms should allow administrators to adjust the validity time as appropriate for their users. More information can be found on this in the mitigations section of this advisory.

ENROLLING NEW DEVICES TO THE CLOUD

On multiple occasions, the SVR have successfully bypassed password authentication on personal accounts using password spraying and credential reuse. SVR actors have also then bypassed MFA through a technique known as “MFA bombing” or “MFA fatigue,” in which the actors repeatedly push MFA requests to a victim’s device until the victim accepts the notification [T1621].

Once an actor has bypassed these systems to gain access to the cloud environment, SVR actors have been observed registering their own device as a new device on the cloud tenant [T1098.005]. If device validation rules are not set up, SVR actors can successfully register their own device and gain access to the network.

By configuring the network with device enrollment policies, there have been instances where these measures have defended against SVR actors and denied them access to the cloud tenant.

RESIDENTIAL PROXIES

As network-level defenses improve detection of suspicious activity, SVR actors have looked at other ways to stay covert on the internet. A TTP associated with this actor is the use of residential proxies [T1090.002]. Residential proxies typically make traffic appear to originate from IP addresses within internet service provider (ISP) ranges used for residential broadband customers and hide the true source. This can make it harder to distinguish malicious connections from typical users. This reduces the effectiveness of network defenses that use IP addresses as indicators of compromise, and so it is important to consider a variety of information sources such as application and host-based logging for detecting suspicious activity.

CONCLUSION

The SVR is a sophisticated actor capable of carrying out a global supply chain compromise such as the 2020 SolarWinds, however the guidance in this advisory shows that a strong baseline of cyber security fundamentals can help defend from such actors.

For organizations that have moved to cloud infrastructure, a first line of defense against an actor such as SVR should be to protect against SVR’s TTPs for initial access. By following the mitigations outlined in this advisory, organizations will be in a stronger position to defend against this threat.

Once the SVR gain initial access, the actor is capable of deploying highly sophisticated post compromise capabilities such as MagicWeb, as reported in 2022. Therefore, mitigating against the SVR’s initial access vectors is particularly important for network defenders.

CISA have also produced guidance through their Secure Cloud Business Applications (SCuBA) Project which is designed to protect assets stored in cloud environments.

Some of the TTPs listed in this report, such as residential proxies and exploitation of system accounts, are similar to those reported as recently as January 2024 by Microsoft.

MITRE ATT&CK®

This report has been compiled with respect to the MITRE ATT&CK® framework, a globally accessible knowledge base of adversary tactics and techniques based on real-world observations.

MITIGATION AND DETECTION

A number of mitigations will be useful in defending against the activity described in this advisory: 

• Use multi-factor authentication (/2-factor authentication/two-step verification) to reduce the impact of password compromises. See NCSC guidance: Multifactor Authentication for Online Services and Setting up 2-Step Verification (2SV).
• Accounts that cannot use 2SV should have strong, unique passwords. User and system accounts should be disabled when no longer required with a “joiners, movers, and leavers” process in place and regular reviews to identify and disable inactive/dormant accounts. See NCSC guidance: 10 Steps to Cyber Security.
• System and service accounts should implement the principle of least privilege, providing tightly scoped access to resources required for the service to function.
• Canary service accounts should be created which appear to be valid service accounts but are never used by legitimate services. Monitoring and alerting on the use of these account provides a high confidence signal that they are being used illegitimately and should be investigated urgently.
• Session lifetimes should be kept as short as practical to reduce the window of opportunity for an adversary to use stolen session tokens. This should be paired with a suitable authentication method that strikes a balance between regular user authentication and user experience.
• Ensure device enrollment policies are configured to only permit authorized devices to enroll. Use zero-touch enrollment where possible, or if self-enrollment is required then use a strong form of 2SV that is resistant to phishing and prompt bombing. Old devices should be prevented from (re)enrolling when no longer required. See NCSC guidance: Device Security Guidance.
• Consider a variety of information sources such as application events and host-based logs to help prevent, detect and investigate potential malicious behavior. Focus on the information sources and indicators of compromise that have a better rate of false positives. For example, looking for changes to user agent strings that could indicate session hijacking may be more effective than trying to identify connections from suspicious IP addresses. See NCSC guidance: Introduction to Logging for Security Purposes.

DISCLAIMER

This report draws on information derived from NCSC and industry sources. Any NCSC findings and recommendations made have not been provided with the intention of avoiding all risks and following the recommendations will not remove all such risk. Ownership of information risks remains with the relevant system owner at all times.

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation.

Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk.

All material is UK Crown Copyright.

SUMMARY

The Cybersecurity and Infrastructure Security Agency (CISA) and the following partners (hereafter referred to as the authoring organizations) are releasing this joint Cybersecurity Advisory to warn that cyber threat actors are exploiting previously identified vulnerabilities in Ivanti Connect Secure and Ivanti Policy Secure gateways. CISA and authoring organizations appreciate the cooperation of Volexity, Ivanti, Mandiant and other industry partners in the development of this advisory and ongoing incident response activities. Authoring organizations:

• Federal Bureau of Investigation (FBI)
• Multi-State Information Sharing & Analysis Center (MS-ISAC)
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• United Kingdom National Cyber Security Centre (NCSC-UK)
• Canadian Centre for Cyber Security (Cyber Centre), a part of the Communications Security Establishment
• New Zealand National Cyber Security Centre (NCSC-NZ)
• CERT-New Zealand (CERT NZ)

Of particular concern, the authoring organizations and industry partners have determined that cyber threat actors are able to deceive Ivanti’s internal and external Integrity Checker Tool (ICT), resulting in a failure to detect compromise.

Cyber threat actors are actively exploiting multiple previously identified vulnerabilities—CVE-2023-46805, CVE-2024-21887, CVE-2024-22024, and CVE-2024-21893—affecting Ivanti Connect Secure and Ivanti Policy Secure gateways. The vulnerabilities impact all supported versions (9.x and 22.x) and can be used in a chain of exploits to enable malicious cyber threat actors to bypass authentication, craft malicious requests, and execute arbitrary commands with elevated privileges.

During multiple incident response engagements associated with this activity, CISA identified that Ivanti’s internal and previous external ICT failed to detect compromise. In addition, CISA has conducted independent research in a lab environment validating that the Ivanti ICT is not sufficient to detect compromise and that a cyber threat actor may be able to gain root-level persistence despite issuing factory resets.

The authoring organizations encourage network defenders to (1) assume that user and service account credentials stored within the affected Ivanti VPN appliances are likely compromised, (2) hunt for malicious activity on their networks using the detection methods and indicators of compromise (IOCs) within this advisory, (3) run Ivanti’s most recent external ICT, and (4) apply available patching guidance provided by Ivanti as version updates become available. If a potential compromise is detected, organizations should collect and analyze logs and artifacts for malicious activity and apply the incident response recommendations within this advisory.

Based upon the authoring organizations’ observations during incident response activities and available industry reporting, as supplemented by CISA’s research findings, the authoring organizations recommend that the safest course of action for network defenders is to assume a sophisticated threat actor may deploy rootkit level persistence on a device that has been reset and lay dormant for an arbitrary amount of time. For example, as outlined in PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure), sophisticated actors may remain silent on compromised networks for long periods. The authoring organizations strongly urge all organizations to consider the significant risk of adversary access to, and persistence on, Ivanti Connect Secure and Ivanti Policy Secure gateways when determining whether to continue operating these devices in an enterprise environment.

Note: On February 9, 2024, CISA issued Emergency Directive (ED) 24-01: Mitigate Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities, which requires emergency action from Federal Civilian Executive Branch (FCEB) agencies to perform specific actions on affected products.

The Canadian Centre for Cyber Security also issued an alert, Ivanti Connect Secure and Ivanti Policy Secure gateways zero-day vulnerabilities, which provides periodic updates for IT professionals and managers affected by the Ivanti vulnerabilities.

Download the PDF version of this report:

For a downloadable copy of IOCs, see:

TECHNICAL DETAILS

This advisory uses the MITRE ATT&CK^® for Enterprise framework, version 14. See the MITRE ATT&CK Tactics and Techniques in Appendix C for a table of the 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

On January 10, 2024, Volexity reported on two vulnerabilities in Ivanti Connect Secure and Ivanti Policy Secure gateways observed being chained to achieve unauthenticated remote code execution (RCE):[1]

• CVE 2023-46805
• CVE-2024-21887

Volexity first identified active exploitation in early December 2023, when they detected suspicious lateral movement [TA0008] on the network of one of their network security monitoring service customers. Volexity identified that threat actors exploited the vulnerabilities to implant web shells, including GLASSTOKEN and GIFTEDVISITOR, on internal and external-facing web servers [T1505.003]. Once successfully deployed, these web shells are used to execute commands on compromised devices.[1]

After Ivanti provided initial mitigation guidance in early January, threat actors developed a way to bypass those mitigations to deploy BUSHWALK, LIGHTWIRE, and CHAINLINE web shell variants.[2] Following the actors’ developments, Ivanti disclosed three additional vulnerabilities:

• CVE-2024-21893 is a server-side request forgery vulnerability in the SAML component of Ivanti Connect Secure (9.x, 22.x) Ivanti Policy Secure (9.x, 22.x), and Ivanti Neurons for ZTA that allows an attacker to access restricted resources without authentication.
• CVE-2024-22024 is an XML vulnerability in the SAML component of Ivanti Connect Secure (9.x, 22.x), Ivanti Policy Secure (9.x, 22.x), and ZTA gateways that allows an attacker to access restricted resources without authentication.
• CVE-2024-21888 is a privilege escalation vulnerability found in the web component of Ivanti Connect Secure and Ivanti Policy Secure. This vulnerability allows threat actors to gain elevated privileges to that of an administrator.

Observed Threat Actor Activity

CISA has responded to multiple incidents related to the above vulnerabilities in Ivanti Connect Secure and Policy Secure Gateways. In these incidents, actors exploited these CVEs for initial access to implant web shells and to harvest credentials stored on the devices. Post-compromise, the actors moved laterally into domain environments and have been observed leveraging tools that are native to the Ivanti appliances—such as freerdp, ssh, telnet, and nmap libraries—to expand their access to the domain environment. The result, in some cases, was a full domain compromise.

During incident response investigations, CISA identified that Ivanti’s internal and external ICT failed to detect compromise. The organizations leveraged the integrity checker to identify file mismatches in Ivanti devices; however, CISA incident response analysis confirmed that both the internal and external versions of the ICT were not reliable due to the existence of web shells found on systems that had no file mismatches according to the ICTs. Additionally, forensic analysis showed evidence the actors were able to clean up their efforts by overwriting files, time-stomping files, and re-mounting the runtime partition to return the appliance to a “clean state.” This reinforces that ICT scans are not reliable to indicate previous compromise and can result in a false sense of security that the device is free of compromise.

As detailed in Appendix A, CISA conducted independent research in a lab environment validating that the ICT is likely insufficient for detecting compromise and that a cyber threat actor may be able to maintain root level persistence despite issuing factory resets and appliance upgrades.

INDICATORS OF COMPROMISE

See Tables 1 – 4 in Appendix B for IOCs related to cyber actors exploiting multiple CVEs related to Ivanti appliances.

For additional indicators of compromise, see:

• Volexity: Active Exploitation of Two Zero-Day Vulnerabilities in Ivanti Connect Secure VPN
• Mandiant: Cutting Edge: Suspected APT Targets Ivanti Connect Secure VPN in New Zero-Day Exploitation
• Mandiant: Cutting Edge, Part 2: Investigating Ivanti Connect Secure VPN Zero-Day Exploitation
• Mandiant: Cutting Edge, Part 3: Investigating Ivanti Connect Secure VPN Exploitation and Persistence Attempts

Memory and disk forensics were used during forensic analysis, combined with the Integrity Checker Tool, to identify malicious files on the compromised Ivanti Connect Secure VPN appliance. This advisory provides a list of combined authoring organization IOCs and open source files identified by Volexity via network analysis.

Disclaimer: Some IP addresses in this advisory may be associated with legitimate activity. Organizations are encouraged to investigate the activity around these IP addresses prior to taking action such as blocking. Activity should not be attributed as malicious without analytical evidence to support it is used at the direction of, or controlled by, threat actors.

DETECTION METHODS

YARA Rules

See Appendix D for additional open source YARA rules, provided by Volexity, that may aid network defenders in detecting malicious activity within Ivanti Connect Secure VPN appliances. For more information on detection methods, visit Mandiant’s blog post Cutting Edge, Part 2: Investigating Ivanti Connect Secure VPN Zero-Day Exploitation or the Volexity GitHub page.

INCIDENT RESPONSE

The authoring organizations encourage you to assess your organization’s user interface (UI) software and systems for evidence of compromise and to hunt for malicious activity using signatures outlined within this advisory. If compromise is suspected or detected, organizations should assume that threat actors hold full administrative access and can perform all tasks associated with the Ivanti Connect Secure VPN appliance as well as executing arbitrary code and installing malicious payloads.

Note: These are vendor-managed appliances and systems may be encrypted with limited access. Thus, collecting artifacts may be limited on some versions of appliances. The authoring organizations recommend investigating associated devices on the network to identify lateral movement in the absence of access to the Secure Connect appliance.

If a potential compromise is detected, organizations should:

1. Quarantine or take offline potentially affected hosts.
2. Reimage compromised hosts.
3. Reset all credentials that may have been exposed during the compromise, including user and service accounts.
4. Identify Ivanti hosts with Active Directory (AD) access, threat actors can trivially export active domain administrator credentials during initial compromise. Until there is evidence to the contrary, it is assumed that AD access on compromised systems is connected to external authentication systems such as Lightweight Directory Access Protocol (LDAP) and AD.
5. Collect and review artifacts such as running processes/services, unusual authentications, and recent network connections.
   • Note: Removing malicious administrator accounts may not fully mitigate risk considering threat actors may have established additional persistence mechanisms.
6. Report the compromise to FBI Internet Crime Complaint Center (IC3) at IC3.gov, local FBI field Office, or CISA via the agency’s Incident Reporting System or its 24/7 Operations Center (report@cisa.gov or 888-282-0870). State, local, tribal, or territorial government entities can also report to MS-ISAC (SOC@cisecurity.org or 866-787-4722). Organizations outside of the United States should contact their national cyber center. (See the Reporting section.)

MITIGATIONS

These mitigations apply to all critical infrastructure organizations and network defenders using Ivanti Connect Secure VPN and Ivanti Policy Secure. The authoring organizations recommend that software manufacturers incorporate Secure by Design principles and tactics into their software development practices. These principles and tactics can limit the impact of exploitation—such as threat actors leveraging newly discovered, unpatched vulnerabilities within Ivanti appliances—thus, strengthening the secure posture for their customers.

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

The authoring organizations recommend organizations implement the mitigations below to improve your cybersecurity posture based on threat actor activity and to reduce the risk of compromise associated with Ivanti vulnerabilities. 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.

• As organizations make risk decisions in choosing a VPN, to include decisions regarding continued operation of Ivanti Connect Secure and Policy Secure gateways, avoid VPN solutions that use proprietary protocols or non-standard features. VPNs as a class of devices carry some specific risks that a non-expert implementer may trigger (e.g., authentication integration and patching). When choosing a VPN, organizations should consider vendors who:
  • Provide a Software Bill of Materials (SBOM) to proactively identify, and enable remediation of, embedded software vulnerabilities, such as deprecated operating systems.
  • Allow a restore from trusted media to establish a root of trust. If the software validation tooling can be modified by the software itself, there is no way to establish a root of trust other than returning the device to the manufacturer (return material authorization [RMA]).
  • Are a CVE Numbering Authority (CNA) so that CVEs are assigned to emerging vulnerabilities in a timely manner.
  • Have a public Vulnerability Disclosure Policy (VDP) to enable security researchers to proactively share and disclose vulnerabilities through coordinated vulnerability disclosure (CVD).
  • Have in place a clear end-of-life policy (EoL) to prepare customers for updating to supported product versions.
• Limit outbound internet connections from SSL VPN appliances to restrict access to required services. This will limit the ability of an actor to download tools or malware onto the device or establish outbound connections to command and control (C2) servers.
• Ensure SSL VPN appliances configured with Active Directory or LDAP authentication use low privilege accounts for the LDAP bind.
• Limit SSL VPN connections to unprivileged accounts only to help limit the exposure of privileged account credentials.
• Keep all operating systems, software, and firmware up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Organizations should patch vulnerable software and hardware systems within 24 to 48 hours of vulnerability disclosure. Prioritize patching known exploited vulnerabilities in internet-facing systems [CPG 1.E].
• Secure remote access tools.
  • Implement application controls to manage and control execution of software, including allowlisting remote access programs. Application controls should prevent installation and execution of portable versions of unauthorized remote access and other software. A properly configured application allowlisting solution will block any unlisted application execution. Allowlisting is important because antivirus solutions may fail to detect the execution of malicious portable executables when the files use any combination of compression, encryption, or obfuscation.
• Strictly limit the use of Remote Desktop Protocols (RDP) and other remote desktop services. If RDP is necessary, rigorously apply best practices, for example [CPG 2.W]:
  • Audit the network for systems using RDP.
  • Close unused RDP ports.
  • Enforce account lockouts after a specified number of attempts.
  • Apply phishing-resistant multifactor authentication (MFA).
  • Log RDP login attempts.

• Configure the Windows Registry to require User Account Control (UAC) approval for any PsExec operations requiring administrator privileges to reduce the risk of lateral movement by PsExec.
• Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (e.g., hard drive, storage device, or the cloud).
• Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts) to comply with NIST’s standards for developing and managing password policies.
  • Use longer passwords consisting of at least 15 characters [CPG 2.B].
  • Store passwords in hashed format using industry-recognized password managers.
  • Add password user “salts” to shared login credentials.
  • Avoid reusing passwords [CPG 2.C].
  • Implement multiple failed login attempt account lockouts [CPG 2.G].
  • Disable password “hints.”
  • Require administrator credentials to install software.
• Review the CISA and NSA joint guidance for Selecting and Hardening Remote Access VPN Solutions.

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, the authoring organizations 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 organizations recommend testing your existing security controls inventory to assess how the controls perform against the ATT&CK techniques described in this advisory.

To get started:

1. Select an ATT&CK technique described in this advisory (Appendix C).
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 organizations 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.

REPORTING

U.S. organizations should report every potential cyber incident to the U.S. government. When available, each report submitted should include the date, time, location, type of activity, number of people, and type of equipment used for the activity, the name of the submitting company or organization, and a designated point of contact. Reports can be submitted to the FBI’s Internet Crime Complaint Center (IC3), local FBI Field Office, or CISA via the agency’s Incident Reporting System or its 24/7 Operations Center at report@cisa.gov or (888) 282-0870.

The FBI encourages organizations to report information concerning suspicious or criminal activity to their local FBI Field Office.

Australian organizations that have been impacted or require assistance regarding Ivanti compromise, contact ASD’s ACSC via 1300 CYBER1 (1300 292 371), or by submitting a report to cyber.gov.au.

UK organizations that have been impacted by Ivanti compromise, should report the incident to the National Cyber Security Centre.

Organizations outside of the United States or Australia should contact their national cyber center.

REFERENCES

1. Active Exploitation of Two Zero-Day Vulnerabilities in Ivanti Connect Secure VPN | Volexity
2. Ivanti Connect Secure VPN Exploitation Goes Global | Volexity
3. KB CVE-2023-46805 (Authentication Bypass) & CVE-2024-21887 (Command Injection) for Ivanti Connect Secure and Ivanti Policy Secure Gateways
4. Cutting Edge, Part 2: Investigating Ivanti Connect Secure VPN Zero-Day Exploitation | Mandiant

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. CISA and authoring organizations 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 CISA and authoring organizations.

ACKNOWLEDGEMENTS

Volexity, Mandiant, and Ivanti contributed to this advisory.

VERSION HISTORY

February 29, 2024: Initial version.

APPENDIX A: CISA’S PRODUCT EVALUATION FINDINGS

Research Approach

As part of ongoing efforts to effectively serve the cybersecurity community with actionable insights and guidance, CISA conducted research by using a free and downloadable version of the Ivanti Connect Secure virtual appliance to assess potential attack paths and adversary persistence mechanisms. The virtual appliances were not connected to the internet, and were deployed in a closed virtualized network, with a non-internet connected Active Directory. This research included a variety of tests on version 22.3R1 Build 1647, connected to Active Directory credentials, to leverage the access obtained through CVE-2023-46805, CVE-2024-21887 and CVE-2024-21893. Put simply, CISA’s research team wanted to answer the question: “How far could an attacker go if they set were to exploit these CVEs remotely?”

Persistent Post-Reset and -Upgrade Access

Leveraging these vulnerabilities, CISA researchers were able to exfiltrate domain administrator cleartext credentials [TA0006], gain root-level persistence [TA0003], and bypass integrity checks used by the Integrity Checker application. CISA’s Incident Response team observed these specific techniques leveraged during the agency’s incident response engagements, along with the native tools and libraries to conduct internal reconnaissance and compromise domains behind the Ivanti appliances. CISA researchers assess that threat actors are able to use the credentials to move deeper into the environment.

The ability to exfiltrate domain administrator cleartext credentials, if saved when adding an “Active Directory Authentication server” during setup, was accomplished by using the root-level access obtained from the vulnerabilities to interface directly with the internal server and retrieve the cached credentials as shown in Figure 4, APPENDIX A. Users who currently have active sessions to the appliance could have their base64 encoded active directory cleartext passwords, in addition to the New Technology LAN Manager (NTLM) password hashes, retrieved with the same access, as shown in Figure 10, APPENDIX A. In addition to users with active sessions, users previously authenticated can have base64 encoded active directory plaintext passwords and NTLM hashes harvested from the backups of the data.mdb database files stored on the appliance, as shown in Figure 15 and 16, APPENDIX A.

The root-level access allows adversaries to maintain persistence despite issuing factory resets and appliance upgrades while deceiving the provided integrity checkers, creating the illusion of a clean installation. Due to the persistence mechanism being stored on the encrypted partition of the drive and inaccurate integrity check results, it is untenable for network administrators to validate their application has not been compromised without also decrypting the partition and validating against a clean installation of the appliance, which are actions not easily accomplished at present. Without major alterations of the integrity checking process, it is conceivable that new vulnerabilities that afford root-level access to the appliance could also result in root-kit level persistence to the appliance.

Below is proof of concept being released by CISA, which demonstrates the capacity of and opportunity for a threat actor to exfiltrate Domain Administrator credentials that were used during appliance configuration:

Below is a demonstration of the capacity for post exploitation exfiltration of base64 encoded cleartext credentials for active directory users and their associated NTLM password hashes:

APPENDIX B: INDICATORS OF COMPROMISE

APPENDIX C: MITRE ATT&CK TACTICS AND TECHNIQUES

APPENDIX D: DETECTION METHODS

SUMMARY

The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint Cybersecurity Advisory (CSA) to disseminate known indicators of compromise (IOCs) and tactics, techniques, and procedures (TTPs) associated with threat actors deploying Androxgh0st malware. Multiple, ongoing investigations and trusted third party reporting yielded the IOCs and TTPs, and provided information on Androxgh0st malware’s ability to establish a botnet that can further identify and compromise vulnerable networks.

The FBI and CISA encourage organizations to implement the recommendations in the Mitigations section of this CSA to reduce the likelihood and impact of cybersecurity incidents caused by Androxgh0st infections.

Download the PDF version of this report:

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK^® for Enterprise framework, version 14. See the MITRE ATT&CK Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques with corresponding mitigation and/or detection recommendations. 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

Androxgh0st malware has been observed establishing a botnet [T1583.005] for victim identification and exploitation in target networks. According to open source reporting[1], Androxgh0st is a Python-scripted malware [T1059.006] primarily used to target .env files that contain confidential information, such as credentials [T1552.001] for various high profile applications (i.e., Amazon Web Services [AWS], Microsoft Office 365, SendGrid, and Twilio from the Laravel web application framework). Androxgh0st malware also supports numerous functions capable of abusing the Simple Mail Transfer Protocol (SMTP), such as scanning [T1046] and exploiting exposed credentials [T1078] and application programming interfaces (APIs) [T1114], and web shell deployment [T1505.003].

Targeting the PHPUnit

Androxgh0st malware TTPs commonly involves the use of scripts, conducting scanning [T1595] and searching for websites with specific vulnerabilities. In particular, threat actors deploying Androxgh0st have been observed exploiting CVE-2017-9841 to remotely run hypertext preprocessor (PHP) code on fallible websites via PHPUnit [T1190]. Websites using the PHPUnit module that have internet-accessible (exposed) /vendor folders are subject to malicious HTTP POST requests to the /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php uniform resource identifier (URI). This PHP page runs PHP code submitted through a POST request, which allows the threat actors to remotely execute code.

Malicious actors likely use Androxgh0st to download malicious files [T1105] to the system hosting the website. Threat actors are further able to set up a fake (illegitimate) page accessible via the URI to provide backdoor access to the website. This allows threat actors to download additional malicious files for their operations and access databases.

Laravel Framework Targeting

Androxgh0st malware establishes a botnet to scan for websites using the Laravel web application framework. After identifying websites using the Laravel web application, threat actors attempt to determine if the domain’s root-level .env file is exposed and contains credentials for accessing additional services. Note: .env files commonly store credentials and tokens. Threat actors often target .env files to steal these credentials within the environment variables.

If the .env file is exposed, threat actors will issue a GET request to the /.env URI to attempt to access the data on the page. Alternatively, Androxgh0st may issue a POST request to the same URI with a POST variable named 0x[] containing certain data sent to the web server. This data is frequently used as an identifier for the threat actor. This method appears to be used for websites in debug mode (i.e., when non-production websites are exposed to the internet). A successful response from either of these methods allows the threat actors to look for usernames, passwords, and/or other credentials pertaining to services such as email (via SMTP) and AWS accounts.

Androxgh0st malware can also access the application key [TA0006] for the Laravel application on the website. If the threat actors successfully identify the Laravel application key, they will attempt exploitation by using the key to encrypt PHP code [T1027.010]. The encrypted code is then passed to the website as a value in the cross-site forgery request (XSRF) token cookie, XSRF-TOKEN, and included in a future GET request to the website. The vulnerability defined in CVE-2018-15133 indicates that on Laravel applications, XSRF token values are subject to an un-serialized call, which can allow for remote code execution. In doing so, the threat actors can upload files to the website via remote access.

Apache Web Server Targeting

In correlation with CVE-2021-41773, Androxgh0st actors have been observed scanning vulnerable web servers [T1595.002] running Apache HTTP Server versions 2.4.49 or 2.4.50. Threat actors can identify uniform resource locators (URLs) for files outside root directory through a path traversal attack [T1083]. If these files are not protected by the “request all denied” configuration and Common Gateway Interface (CGI) scripts are enabled, this may allow for remote code execution.

If threat actors obtain credentials for any services using the above methods, they may use these credentials to access sensitive data or use these services to conduct additional malicious operations. For example, when threat actors successfully identify and compromise AWS credentials from a vulnerable website, they have been observed attempting to create new users and user policies [T1136]. Additionally, Andoxgh0st actors have been observed creating new AWS instances to use for conducting additional scanning activity [T1583.006].

INDICATORS OF COMPROMISE (IOCs)

Based on investigations and analysis, the following requests are associated with Androxgh0st activity:

• Incoming GET and POST requests to the following URIs:
  • /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
  • /.env
• Incoming POST requests with the following strings:
  • [0x%5B%5D=androxgh0st]
  • ImmutableMultiDict([('0x[]', 'androxgh0st')])

In both previously listed POST request strings, the name androxgh0st has been observed to be replaced with other monikers.

Additional URIs observed by the FBI and a trusted third party used by these threat actors for credential exfiltration include:

• /info
• /phpinfo
• /phpinfo.php
• /?phpinfo=1
• /frontend_dev.php/$
• /_profiler/phpinfo
• /debug/default/view?panel=config
• /config.json
• /.json
• /.git/config
• /live_env
• /.env.dist
• /.env.save
• /environments/.env.production
• /.env.production.local
• /.env.project
• /.env.development
• /.env.production
• /.env.prod
• /.env.development.local
• /.env.old
• //.env
  • Note: the actor may attempt multiple different potential URI endpoints scanning for the .env file, for example /docker/.env or /local/.env.
• /.aws/credentials
• /aws/credentials
• /.aws/config
• /.git
• /.test
• /admin
• /backend
• /app
• /current
• /demo
• /api
• /backup
• /beta
• /cron
• /develop
• /Laravel
• /laravel/core
• /gists/cache
• /test.php
• /info.php
• //.env
• /admin-app/.env%20
• /laravel/.env%20
• /shared/.env%20
• /.env.project%20
• /apps/.env%20
• /development/.env%20
• /live_env%20
• /.env.development%20

Targeted URIs for web-shell drop:

• /.env/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //admin/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //api/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //backup/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //blog/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //cms/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //demo/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //dev/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //laravel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //lib/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //lib/phpunit/phpunit/Util/PHP/eval-stdin.php
• //lib/phpunit/src/Util/PHP/eval-stdin.php
• //lib/phpunit/Util/PHP/eval-stdin.php
• //new/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //old/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //panel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //phpunit/phpunit/Util/PHP/eval-stdin.php
• //phpunit/src/Util/PHP/eval-stdin.php
• //phpunit/Util/PHP/eval-stdin.php
• //protected/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //sites/all/libraries/mailchimp/vendor/phpunit/phpunit/src/Util/PHP/evalstdin.php
• //vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //vendor/phpunit/phpunit/Util/PHP/eval-stdin.php
• //vendor/phpunit/src/Util/PHP/eval-stdin.php
• //vendor/phpunit/Util/PHP/eval-stdin.php
• //wp-content/plugins/cloudflare/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //wp-content/plugins/dzs-videogallery/class_parts/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //wp-content/plugins/jekyll-exporter/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //wp-content/plugins/mm-plugin/inc/vendors/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• //www/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /admin/ckeditor/plugins/ajaxplorer/phpunit/src/Util/PHP/eval-stdin.php
• /admin/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /api/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /api/vendor/phpunit/phpunit/src/Util/PHP/Template/eval-stdin.php
• /lab/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /laravel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /laravel_web/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /laravel52/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /laravelao/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /lib/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /lib/phpunit/phpunit/Util/PHP/eval-stdin.php
• /lib/phpunit/phpunit/Util/PHP/eval
• stdin.php%20/lib/phpunit/src/Util/PHP/eval-stdin.php
• /lib/phpunit/src/Util/PHP/eval-stdin.php
• /lib/phpunit/Util/PHP/eval-stdin.php
• /lib/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /libraries/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /phpunit/phpunit/Util/PHP/eval-stdin.php
• /phpunit/phpunit/Util/PHP/eval-stdin.php%20/phpunit/src/Util/PHP/evalstdin.php
• /phpunit/src/Util/PHP/eval-stdin.php
• ./phpunit/Util/PHP/eval-stdin.php
• /phpunit/Util/PHP/eval-stdin.php%20/lib/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php.dev
• /vendor/phpunit/phpunit/Util/PHP/eval-stdin.php
• /vendor/phpunit/phpunit/Util/PHP/eval-stdin.php%20/vendor/phpunit/src/Util/PHP/eval-stdin.php
• /vendor/phpunit/src/Util/PHP/eval-stdin.php
• /vendor/phpunit/Util/PHP/eval-stdin.php
• /vendor/phpunit/Util/PHP/eval-stdin.php%20
• /phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /yii/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• /zend/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php

An example of attempted credential exfiltration through (honeypot) open proxies:

POST /.aws/credentials HTTP/1.1
host: www.example.com
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36
accept-encoding: gzip, deflate
accept: */*
connection: keep-alive
content-length: 20
content-type: application/x-www-form-urlencoded

0x%5B%5D=androxgh0st

An example of attempted web-shell drop through (honeypot) open proxies:

GET http://www.example.com/lib/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1
host: www.example.com
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 Edg/116.0.1938.76
accept-encoding: gzip, deflate
accept: */*
connection: keep-alive
x-forwarded-for: 200.172.238.135
content-length: 279

Monikers used instead of Androxgh0st (0x%5B%5D=???):

• Ridho
• Aws
• 0x_0x
• x_X
• nopebee7
• SMTPEX
• evileyes0
• privangga
• drcrypter
• errorcool
• drosteam
• androxmen
• crack3rz
• b4bbyghost
• 0x0day
• janc0xsec
• blackb0x
• 0x1331day
• Graber

Example malware drops through eval-stdin.php:

hxxps://mc.rockylinux[.]si/seoforce/triggers/files/evil.txt
59e90be75e51c86b4b9b69dcede2cf815da5a79f7e05cac27c95ec35294151f4

hxxps://chainventures.co[.]uk/.well-known/aas
dcf8f640dd7cc27d2399cce96b1cf4b75e3b9f2dfdf19cee0a170e5a6d2ce6b6

hxxp://download.asyncfox[.]xyz/download/xmrig.x86_64
23fc51fde90d98daee27499a7ff94065f7ed4ac09c22867ebd9199e025dee066

hxxps://pastebin[.]com/raw/zw0gAmpC
ca45a14d0e88e4aa408a6ac2ee3012bf9994b16b74e3c66b588c7eabaaec4d72

hxxp://raw.githubusercontent[.]com/0x5a455553/MARIJUANA/master/MARIJUANA.php
0df17ad20bf796ed549c240856ac2bf9ceb19f21a8cae2dbd7d99369ecd317ef

hxxp://45.95.147[.]236/tmp.x86_64
6b5846f32d8009e6b54743d6f817f0c3519be6f370a0917bf455d3d114820bbc

hxxp://main.dsn[.]ovh/dns/pwer
bb7070cbede294963328119d1145546c2e26709c5cea1d876d234b991682c0b7

hxxp://tangible-drink.surge[.]sh/configx.txt
de1114a09cbab5ae9c1011ddd11719f15087cc29c8303da2e71d861b0594a1ba

MITRE ATT&CK TACTICS AND TECHNIQUES

See Tables 1-10 for all referenced threat actor tactics and techniques in this advisory.

MITIGATIONS

The FBI and CISA recommend implementing the mitigations below to improve your organization’s cybersecurity posture based on Androxgh0st threat actor 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.

These mitigations apply to all critical infrastructure organizations and network defenders. FBI and CISA recommend that software manufacturers incorporate secure by design principles and tactics into their software development practices, limiting the impact of actor techniques and strengthening their customers’ security posture. For more information on secure by design, see CISA’s Secure by Design webpage.

The FBI and CISA recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques and to reduce the risk of compromise by actors using Androxgh0st malware.

• Keep all operating systems, software, and firmware up to date. Specifically, ensure that Apache servers are not running versions 2.4.49 or 2.4.50. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Prioritize patching known exploited vulnerabilities in internet-facing systems.
• Verify that the default configuration for all URIs is to deny all requests unless there is a specific need for it to be accessible.
• Ensure that any live Laravel applications are not in “debug” or testing mode. Remove all cloud credentials from .env files and revoke them. All cloud providers have safer ways to provide temporary, frequently rotated credentials to code running inside a web server without storing them in any file.
• On a one-time basis for previously stored cloud credentials, and on an on-going basis for other types of credentials that cannot be removed, review any platforms or services that have credentials listed in the .env file for unauthorized access or use.
• Scan the server’s file system for unrecognized PHP files, particularly in the root directory or /vendor/phpunit/phpunit/src/Util/PHP folder.
• Review outgoing GET requests (via cURL command) to file hosting sites such as GitHub, pastebin, etc., particularly when the request accesses a .php file.

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, FBI and CISA 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 Tables 1-10).
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.

FBI and CISA 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.

REPORTING

The FBI encourages organizations to report information concerning suspicious or criminal activity to their local FBI field office. With regards to specific information that appears in this CSA, indicators should always be evaluated in light of an organization’s complete security situation.

When available, each report submitted should include the date, time, location, type of activity, number of people, and type of equipment used for the activity, the name of the submitting company or organization, and a designated point of contact. Reports can be submitted to the FBI Internet Crime Complaint Center (IC3), a local FBI Field Office, or to CISA via its Incident Reporting System or its 24/7 Operations Center at report@cisa.gov or (888) 282-0870.

RESOURCES

• CISA: Known Exploited Vulnerabilities Catalog
• CISA, MITRE: Best Practices for MITRE ATT&CK Mapping
• CISA: Decider Tool
• NIST: CVE-2017-9841
• NIST: CVE-2018-15133
• NIST: CVE-2021-41773
• CISA: Cross-Sector Cybersecurity Performance Goals
• CISA: Secure by Design

REFERENCES

1. Fortinet – FortiGuard Labs: Threat Signal Report: AndroxGh0st Malware Actively Used in the Wild

ACKNOWLEDGEMENTS

Amazon contributed to this CSA.

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. FBI and CISA 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 FBI and CISA.

VERSION HISTORY

January 16, 2024: Initial version.

SUMMARY

Note: This joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint CSA to disseminate known IOCs and TTPs associated with the ALPHV Blackcat ransomware as a service (RaaS) identified through FBI investigations as recently as Dec. 6, 2023.

This advisory provides updates to the FBI FLASH BlackCat/ALPHV Ransomware Indicators of Compromise released April 19, 2022. Since previous reporting, ALPHV Blackcat actors released a new version of the malware, and the FBI identified over 1000 victims worldwide targeted via ransomware and/or data extortion.

FBI and CISA encourage critical infrastructure organizations to implement the recommendations in the Mitigations section of this CSA to reduce the likelihood and impact of ALPHV Blackcat ransomware and data extortion incidents.

In February 2023, ALPHV Blackcat administrators announced the ALPHV Blackcat Ransomware 2.0 Sphynx update, which was rewritten to provide additional features to affiliates, such as better defense evasion and additional tooling. This ALPHV Blackcat update has the capability to encrypt both Windows and Linux devices, and VMWare instances. ALPHV Blackcat affiliates have extensive networks and experience with ransomware and data extortion operations. According to the FBI, as of September 2023, ALPHV Blackcat affiliates have compromised over 1000 entities—nearly 75 percent of which are in the United States and approximately 250 outside the United States—, demanded over $500 million, and received nearly $300 million in ransom payments.

Download the PDF version of this report:

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK^® for Enterprise framework, version 14. See the MITRE ATT&CK Tactics and Techniques section for a table of the 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.

ALPHV Blackcat affiliates use advanced social engineering techniques and open source research on a company to gain initial access. Actors pose as company IT and/or helpdesk staff and use phone calls or SMS messages [T1598] to obtain credentials from employees to access the target network [T1586]. ALPHV Blackcat affiliates use uniform resource locators (URLs) to live-chat with victims to convey demands and initiate processes to restore the victims’ encrypted files.

After gaining access to a victim network, ALPHV Blackcat affiliates deploy remote access software such as AnyDesk, Mega sync, and Splashtop in preparation of data exfiltration. After gaining access to networks, ALPHV Blackcat affiliates use legitimate remote access and tunneling tools, such as Plink and Ngrok [S0508]. ALPHV Blackcat affiliates claim to use Brute Ratel C4 [S1063] and Cobalt Strike [S1054] as beacons to command and control servers. ALPHV Blackcat affiliates use the open source adversary-in-the-middle attack [T1557] framework Evilginx2, which allows them to obtain multifactor authentication (MFA) credentials, login credentials, and session cookies. The actors also obtain passwords from the domain controller, local network, and deleted backup servers to move laterally throughout the network [T1555].

To evade detection, affiliates employ allowlisted applications such as Metasploit. Once installed on the domain controller, the logs are cleared on the exchange server. Then Mega.nz or Dropbox are used to move, exfiltrate, and/or download victim data. The ransomware is then deployed, and the ransom note is embedded as a file.txt. According to public reporting, affiliates have additionally used POORTRY and STONESTOP to terminate security processes.

Some ALPHV Blackcat affiliates exfiltrate data after gaining access and extort victims without deploying ransomware. After exfiltrating and/or encrypting data, ALPHV Blackcat affiliates communicate with victims via TOR [S0183], Tox, email, or encrypted applications. The threat actors then delete victim data from the victim’s system.

ALPHV Blackcat affiliates offer to provide unsolicited cyber remediation advice as an incentive for payment, offering to provide victims with “vulnerability reports” and “security recommendations” detailing how they penetrated the system and how to prevent future re-victimization upon receipt of ransom payment.

MITRE ATT&CK TACTICS AND TECHNIQUES

See Table 1 through Table 3 for all referenced threat actor tactics and techniques in this advisory.

INCIDENT RESPONSE

If compromise is detected, organizations should:

1. Quarantine or take offline potentially affected hosts.
2. Reimage compromised hosts.
3. Provision new account credentials.
4. Collect and review artifacts such as running processes/services, unusual authentications, and recent network connections.
5. Report the compromise or phishing incident to CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870). State, local, tribal, or territorial government entities can also report to MS-ISAC (SOC@cisecurity.org or 866-787-4722).
6. To report spoofing or phishing attempts (or to report that you’ve been a victim), file a complaint with the FBI’s Internet Crime Complaint Center (IC3), or contact your local FBI Field Office to report an incident.

MITIGATIONS

These mitigations apply to all critical infrastructure organizations and network defenders. The FBI and CISA recommend that software manufactures incorporate secure-by-design and -default principles and tactics into their software development practices limiting the impact of ransomware techniques, thus, strengthening the security posture for their customers.

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

FBI and CISA recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture based on threat actor activity and to reduce the risk of compromise by ALPHV Blackcat threat actors. 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.

• Secure remote access tools by:
  • Implementing application controls to manage and control execution of software, including allowlisting remote access programs. Application controls should prevent installation and execution of portable versions of unauthorized remote access and other software. A properly configured application allowlisting solution will block any unlisted application execution. Allowlisting is important because antivirus solutions may fail to detect the execution of malicious portable executables when the files use any combination of compression, encryption, or obfuscation.
  • Applying recommendations in CISA’s joint Guide to Securing Remote Access Software.
• Implementing FIDO/WebAuthn authentication or Public key Infrastructure (PKI)-based MFA [CPG 2.H]. These MFA implementations are resistant to phishing and not susceptible to push bombing or SIM swap attacks, which are techniques known be used by ALPHV Blackcat affiliates. See CISA’s Fact Sheet Implementing Phishing-Resistant MFA for more information.
• Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting ransomware, implement a tool that logs and reports all network traffic [CPG 5.1], including lateral movement activity on a network. Endpoint detection and response (EDR) tools are useful for detecting lateral connections as they have insight into common and uncommon network connections for each host.
• Implement user training on social engineering and phishing attacks [CPG 2.I]. Regularly educate users on identifying suspicious emails and links, not interacting with those suspicious items, and the importance of reporting instances of opening suspicious emails, links, attachments, or other potential lures.
• Implement internal mail and messaging monitoring. Monitoring internal mail and messaging traffic to identify suspicious activity is essential as users may be phished from outside the targeted network or without the knowledge of the organizational security team. Establish a baseline of normal network traffic and scrutinize any deviations.
• Implement free security tools to prevent cyber threat actors from redirecting users to malicious websites to steal their credentials. For more information see, CISA’s Free Cybersecurity Services and Tools webpage.
• Install and maintain antivirus software. Antivirus software recognizes malware and protects your computer against it. Installing antivirus software from a reputable vendor is an important step in preventing and detecting infections. Always visit vendor sites directly rather than clicking on advertisements or email links. Because attackers are continually creating new viruses and other forms of malicious code, it is important to keep your antivirus software up to date.

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 Tables 1-3).
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 and FBI 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.

RESOURCES

• Stopransomware.gov is a whole-of-government approach that gives one central location for ransomware resources and alerts.
• Resource to reduce the risk of a ransomware attack: #StopRansomware Guide.
• No-cost cyber hygiene services: Cyber Hygiene Services and Ransomware Readiness Assessment.

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. CISA and FBI 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 CISA and FBI.

VERSION HISTORY

December 19, 2023: Initial version.