Advisory at a Glance

Title	#StopRansomware: Gunra Ransomware
Original Publication	August 10, 2026
Executive Summary	Gunra is a ransomware-as-a-service (RaaS) used by affiliates to target government, critical infrastructure, and other organizations. The Gunra ransomware variant first appeared in 2025 and expanded to RaaS operations in 2026. The actors leverage a double-extortion model, both encrypting data and threatening to publish exfiltrated data to a dedicated leak site (DLS) if the ransom is not paid. This advisory provides technical details of the activity, as well as tailored detection and mitigation guidance to protect at-risk organizations from Gunra.
Key Actions	Prioritize patching known exploited vulnerabilities in internet-facing systems, including virtual private network (VPN) gateways and remote desktop protocol (RDP)-exposed infrastructure. Implement and test offline, immutable backups stored in a physically separate, segmented location to ensure recoverability without ransom payment. Segment networks to restrict lateral movement from an initially compromised device to other systems in the organization.
Indicators of Compromise	For a downloadable copy of indicators of compromise, see: AA26-222A STIX XML (54 KB) AA26-222A STIX JSON (61 KB)
Intended Audience	Organizations: Government, Critical Infrastructure Sectors: Healthcare and public health, financial services and insurance, critical manufacturing and construction, transportation systems and logistics, government services and facilities, utilities, academia, media and communications, retail, and professional and nonprofit services. Roles: Cybersecurity architects, defensive cybersecurity analysts, vulnerability analysts, systems administrators, and security systems managers.

Introduction

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 Defense Cyber Crime Center (DC3), National Security Agency (NSA), U.S. Secret Service (USSS), and Republic of Korea’s National Police Agency (KNPA)—hereafter referred to as “the authoring agencies”—are releasing this joint advisory to alert organizations to the emerging Gunra ransomware threat and to provide detection and mitigation guidance.

Gunra first emerged in April 2025 as a sophisticated double-extortion ransomware variant derived from the leaked Conti¹ ransomware source code. As of early 2026, Gunra expanded its operations through a structured ransomware-as-a-service (RaaS) affiliate program advertised on dark web forums to financially motivated cybercriminals. Gunra actors demand ransom via a customized, Tor-based negotiation portal and threaten to publish exfiltrated data on a dedicated leak site (DLS) if victims do not comply.

Gunra victims observed on the actors’ DLS span organizations across multiple sectors in the Americas, Europe, Middle East, Africa, and the Asia-Pacific.² These sectors include:

• Healthcare and public health
• Financial services and insurance
• Critical manufacturing and construction
• Transportation systems and logistics
• Government services and facilities
• Utilities
• Academia
• Media and communications
• Retail
• Professional and nonprofit services  

The authoring agencies encourage organizations to implement the recommendations in the Mitigations section of this advisory to mitigate cyber threats related to Gunra ransomware, including:

• Prioritizing patching known exploited vulnerabilities in internet-facing systems, including virtual private network (VPN) gateways and remote desktop protocol (RDP)-exposed infrastructure.
• Implementing and testing offline, immutable backups stored in a physically separate, segmented location to ensure recoverability without ransom payment.
• Segmenting networks to restrict lateral movement from an initially compromised device to other systems in the organization.

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 19.1. 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.

Overview

The FBI originally observed Gunra ransomware in April 2025. The threat actors quickly established a DLS on the Tor network to list victims and publish exfiltrated data. As of January 2026, Gunra launched a formal RaaS affiliate program on dark web forums, providing affiliates with access to a management panel, a configurable ransomware builder, cross-platform locker payloads, and structured affiliate documentation.³  The FBI observed the group adopting new branding aliases (notably operating under the name Golden Community) to support this expansion. Gunra has further commercialized its platform by actively recruiting penetration testers and ethical hackers to serve as initial access brokers, offering a share of the ransom profits in exchange for enterprise network access.

Based on FBI observations, Gunra actors use a traditional double-extortion model, exfiltrating sensitive victim data prior to encryption and threatening to publish the leaked data on their DLS unless the ransom is paid. Victims receive a ransom note in every affected directory guiding them to a Tor-based negotiation portal where they are assigned a Client ID and an initial password. Subsequently, victims receive instructions to contact the Gunra actors via qTox (an encrypted messaging application) to negotiate ransom payments within five to seven days. If the ransom is not paid, Gunra actors threaten to sell victim data on the DLS.

Gunra ransomware appears to be based on, or significantly influenced by, the Conti ransomware source code leaked in 2022.⁴ Initially, Gunra actors’ campaigns focused on Windows environments; reporting in mid-2025 indicated the group introduced a Linux variant and moved toward broader cross-platform targeting.⁵ 

Initial Access

The FBI observed Gunra actors obtaining initial access [TA0001] primarily through the exploitation of known vulnerabilities in internet-facing devices [T1190], including firewall and VPN appliances. The FBI observed exploits based on the following Common Vulnerabilities and Exposures (CVEs):

• CVE-2024-55591 [CWE-288: Authentication Bypass Using an Alternate Path or Channel]: Authentication bypass vulnerability affecting specific FortiOS and FortiProxy versions (see CVE record for more details).
• CVE-2025-24472 [CWE-288: Authentication Bypass Using an Alternate Path or Channel]: Authentication bypass vulnerability affecting specific FortiOS and FortiProxy versions (see CVE record for more details).

Additionally, for initial access, KNPA observed Gunra actors exploit credential-exposure and Secure Shell (SSH) access control vulnerabilities in internet-facing VPN gateways to gain unauthorized remote access.

Execution

Gunra’s Windows encryptor relies on native operating system (OS) application programming interfaces (APIs) to drive both execution and targeted encryption activity. The binary uses the FindFirstFileW/FindNextFileW API calls [T1106] to enumerate files and directories on all accessible drive letters (A through Z), enabling comprehensive traversal of the file system prior to encryption of victim data.

Persistence, Privilege Escalation, Lateral Movement, and Command and Control

Gunra actors regularly exploit Impacket libraries psexec.py and smbclient.py to move laterally across victim networks using the Server Message Block (SMB) protocol [T1021.002].

KPNA observed that against one victim, Gunra actors gained access to an administrator account for a secure socket layer (SSL)-VPN appliance [T1133] by exploiting default credentials when account lockout controls were not present [T1078.001][T1078.002]. The actors subsequently downloaded OpenSSH (an SSH tunneling tool) [T1105] from an external attacker-controlled server to establish connections between compromised systems and maintain persistence in the victim’s environment [T1572].

After gaining access to an internet-connected workstation used by a network administrator, Gunra actors accessed the SSL-VPN administrative web console and identified an unused account that had access to both the internet-facing and internal corporate networks. The actors modified the account configuration to bypass the mandatory password change requirement enforced on the account and subsequently leveraged it for malicious activities [T1098].

Using stolen session information, Gunra actors gained initial access to the internal virtual desktop infrastructure (VDI) environment and conducted lateral movement via RDP [T1021.001]. The actors pivoted to multiple critical systems, including the VDI authentication web server, the internal Active Directory (AD) server, and virtual desktops assigned to IT personnel.

Credential Access

The FBI observed multiple instances of Gunra actors using secretsdump.py (another Impacket library) to conduct OS credential dumping [T1003.003] against compromised domain controllers to extract password hashes of user accounts from the NT Directory Services (NTDS) file. This enabled pass-the-hash [T1550.002] or pass-the-ticket [T1550.003] attacks for lateral movement into other privileged systems.

For one victim, Gunra actors manipulated the network traffic control functionality of an SSL-VPN appliance to collect credentials and session information transmitted by users authenticating to a corporate VDI authentication portal [T1040]. The actors then used stolen session cookies to conduct session hijacking [T1539], impersonating legitimate users to gain access to the internal network.

For the same victim, the Gunra actors modified authentication processing files on the corporate VDI authentication portal server to allow successful authentication when a specific, Gunra-designated one time password (OTP) value was entered, thereby enabling the continuous bypass of multi-factor authentication (MFA) [T1556.006].

Additionally, the actors accessed a Hiware system access control server via SSH from a compromised virtual desktop and stole a symmetric encryption key stored on the server. The stolen key enabled the actors to decrypt passwords for enterprise server accounts stored within the database [T1555] and perform credential dumping of credentials associated with all enterprise servers [T1003].

Stealth, Defense Impairment, and Discovery

Gunra employs multiple stealth and defense impairment techniques to hinder detection and analysis. While active within victim networks, Gunra actors typically attempt to mask their presence by deleting system/network access logs [T1685] and clearing command history [T1070.003]. Additionally, to evade administrator detection, Gunra actors primarily conduct malicious activities and internal infrastructure reconnaissance [T1049] during late-night and early-morning hours (10:00 p.m. – 06:00 a.m.) [T1678].

The ransomware binary is self-contained and performs full volume encryption without observable network indicators (e.g., domain name system, HTTP).⁶ The Windows binary includes the IsDebuggerPresent API [T1622], which defends against reverse engineering by detecting if the application is being run in a debugger.⁷ 

To avoid dedicating encryption resources to non-critical files, the binary includes filtering logic to exclude common system directories (e.g., C:\Windows, C:\Program Files, C:\Program Files (x86)) from the file system reconnaissance [T1679]. For files that pass the initial filter, the binary checks against a second set of filter rules that exclude file extensions related to system-critical files (e.g., .exe, .dll, .sys). Files with extensions consistent with user data (e.g., documents, databases, images, archives) are approved and added to the work queue for data encryption.⁸ 

Prior to encryption, Gunra performs file and directory discovery across all accessible drive letters (A through Z) to identify victim data for targeting [T1083].⁹ 

Collection and Exfiltration

Prior to data encryption, Gunra actors collect sensitive victim data as part of their double-extortion strategy. The FBI observed actors collecting files from victims that included business-critical documents, databases, personally identifiable information (PII), and internal email communications [TA0009][T1114]. Gunra actors’ custom support for filtering redundant system files during initial discovery/file system reconnaissance streamlines the actors’ collection of user-specific data from local victim machines [T1005].

The FBI observed Gunra actors use a malicious executable (main.exe) to exfiltrate victim data from Microsoft OneDrive and SharePoint [T1530]. For at least one known Gunra victim, the actors generated compressed archives with sensitive data [T1560] and exfiltrated the archives to the file-sharing service Mega [T1567]; the volume of exfiltrated data ranged up to tens of terabytes.¹⁰ 

In addition to collecting business-critical documents, the KNPA identified a victim case in which Gunra actors connected to the VDI environments of IT personnel and collected sensitive documents containing system and network configuration information [T1005]. The actors then leveraged enterprise server credentials stolen from a system access control server to deploy ransomware to encrypt key assets, including database servers and network attached storage (NAS) systems [T1486].

The FBI observed several common open source tools on Gunra infrastructure that Gunra actors use to facilitate collection and exfiltration of data, including 7-Zip, RClone, and FileZilla [T1048] (see Leveraged Tools for a full list of tools used maliciously by Gunra actors).

Impact

Gunra’s double-extortion model relies on both data exfiltration and data encryption for optimal success. The binary achieves high speed file encryption of entire file systems by leveraging a multi-threaded architecture that supports parallel encryption of multiple files simultaneously using strong ChaCha20 + RSA-4096 encryption [T1486]. Upon successful encryption of a file, the binary renames the encrypted file with the file extension .ENCRT. Gunra also used the .CRYPT file extension in one documented sample from July 2025.¹¹ 

After the binary completes the encryption process for all files in a specific directory, Gunra actors write a static ransom note named R3ADM3.txt to the directory. To avoid unnecessary overhead, the binary also contains logic to prevent encryption of the ransom notes (R3ADM3.txt) and re-encryption of already encrypted files (.ENCRT).¹² 

In their ransom notes, Gunra actors typically demand that victims initiate negotiation discussions within five to seven days via a Tor-based negotiation portal or qTox, or risk having their data leaked on Gunra’s DLS. The FBI observed Gunra actors attempting to communicate directly with management staff at victim companies via email to solicit ransom payments with limited success. Gunra actors instructed victims to send ransom payments to specific cryptocurrency wallet addresses [T1657] and generally started negotiations at arbitrarily high ransom amounts (over tens of millions in US dollars).

If Gunra victims do not negotiate or pay ransom, the actors publicly disclose the victims on their DLS and offer a preview of victims’ leaked data. This preview typically includes a directory listing of a victim’s exposed OneDrive and SharePoint files, but not the content of the files. Between June and July of 2025, Gunra actors operated a clearnet mirror of their Tor-based DLS at domain datapub.news. By March 2026, Gunra had moved their original Tor-based DLS to a different .onion address. On Gunra’s current Tor-based DLS, the actors advertise the sale of datasets from specific victims and instruct interested parties to contact them via qTox for more information.

To increase the likelihood of ransom payment and prevent system recovery [T1490], Gunra actors also used Windows Management Instrumentation (WMI) [T1047] to initiate deletion of volume shadow copies prior to encryption, as demonstrated in the following example [T1059.003]:¹³  

cmd.exe /c C:\Windows\System32\wbem\WMIC.exe shadowcopy where "ID='{guid of shadowcopy}'" delete

Additionally, against one Gunra victim, Gunra actors deleted backup and archived data stored on backup infrastructure at both the primary data center and disaster recovery center before and after the ransomware deployment [T1490].

Leveraged Tools

Table 1 lists publicly available tools and applications used by Gunra ransomware actors. If network defenders identify use of these tools on their network, they should investigate further to determine possible malicious activity.

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

Table 1. Tools Used by Gunra Ransomware Actors

Tool Name	Description
FileZilla	Open source, cross-platform File Transfer Protocol (FTP) application that supports file transfers between devices and remote servers.
Amass	Open source reconnaissance tool for network mapping and information gathering.
RClone	Open source command-line program designed to manage files in cloud storage.
Sliver	Penetration testing toolset that allows remote command and control of systems.
7-Zip	Open source, cross-platform file archiver utility.
WinRAR	Open source file archiver utility for Microsoft Windows.
DBeaver	Open source database management tool for managing Structured Query Language (SQL) databases like MySQL, MariaDB, PostgreSQL, SQLite, etc.
Slack	Cloud-based team communication and collaboration platform.
Microsoft Visual Studio Code	Open source extendable source code editor.
MobaXterm	Windows application with support for multiple remote computing protocols, including SSH, X11, RDP, virtual network computing (VNC), FTP, etc.
AnyDesk	Common, legitimate remote monitoring and management (RMM) tool that can be used by a cyber actor to obtain remote access and maintain persistence. AnyDesk also supports remote file transfer.
Google Remote Desktop	Web-based remote desktop software tool developed by Google that runs on a proprietary Google protocol.
Mimikatz	Post-exploitation tool that allows users to access and exfiltrate authentication credentials from Windows systems.
Impacket	Suite of networking utilities, including smbclient, psexec, secretsdump, etc. Gunra utilized several tools from this suite.

Indicators of Compromise

Table 2 lists IP addresses and domains associated with Gunra ransomware infrastructure since early 2025.

Disclaimer: Observed IP addresses/domains may be historical in nature. The authoring agencies recommend organizations investigate or vet these IP addresses prior to taking action, such as blocking.

Table 2. IP Addresses/Domains

IP Address/Domain	First Seen	Last Seen
23.239.119[.]2	July 2025	Nov. 6, 2025
23.239.119[.]3	July 2025	Nov. 6, 2025
23.239.119[.]4	July 2025	Nov. 6, 2025
23.239.119[.]5	July 2025	Nov. 6, 2025
23.239.119[.]6	July 2025	Nov. 6, 2025
86.54.28[.]216	June 7, 2025	July 23, 2025
103.125.234[.]14	Nov. 2025	Dec. 2025
70.36.99[.]82	Nov. 2025	Dec. 2025
211.21.210[.]181	Nov. 2025	Dec. 2025
123.184.143[.]105	Nov. 2025	Dec. 2025
182.204.21[.]240	Nov. 2025	Dec. 2025
182.204.16[.]112	Nov. 2025	Dec. 2025
123.244.187[.]144	Nov. 2025	Dec. 2025
182.204.39[.]118	Nov. 2025	Dec. 2025
67.43.53[.]10	Nov. 2025	Dec. 2025
123.246.37[.]108	Nov. 2025	Dec. 2025
91.201.66[.]146	Nov. 2025	Dec. 2025
Datapub[.]news	June 2025	July 2025
gunrabxbig445sjqa535uaymzerj6fp4nwc6ngc2xughf2pedjdhk4ad[.]onion	Apr. 2025	Feb. 2026
lgiil72vkmdtbc3qv4tyq6wedyjxqr2qd4ze7xl2cxgerdnymxj7soqd[.]onion	Mar. 2026	July 2026
nsnhzysbntsqdwpys6mhml33muccsvterxewh5rkbmcab7bg2ttevjqd[.]onion	Jan. 2026	Jan. 2026

 

Table 3 lists email addresses associated with Gunra actors.

Table 3. Gunra Email Addresses

Email Address	Description
a00f105546345756@proton[.]me	Ransom negotiation
4569f6322bc3b22e9@proton[.]me	Ransom negotiation
ilovemycubscout@gmail[.]com	Ransom negotiation
6449a3c1e612168526@proton[.]me	Ransom negotiation

The following qTox IDs are associated with Gunra actors:

• 2507312EC10BB44ED9DAA04E3C5C27E8C13154649B1A02E73ACFAE1681EE0208D05133A8FB22
• 0FE87CED0C611AE97E049C64288557F49E8271E91399E849328B078DA789A573031783235BEF
• 47829AF1C943D4C296C910706923AS199BDA4995B076ED9A9016F7DEF161D445DF00F13E6900
• 9500B1A73716BCF40745086F7184A33EA0141B7D3F852431C8FDD2E1E8FAF9277E9FDC117B47

Table 4 lists malicious files associated with Gunra ransomware.

Table 4. Malicious Files (SHA256)

Filename	Hash (SHA256)	Description
main.exe	2dc70a12d158d437e45a55b1d52f3d61c6082a1e1667573302ba3b62813e2751	Tool to exfil OneDrive and SharePoint
main.exe	834efe9b392c6c000877ea5613a079445affc16fe8af5997d68c55cafc95e5d1	Tool to exfil OneDrive and SharePoint
cryptor.exe	91f8fc7a3290611e28a35a403fd815554d9d856006cc2ee91ccdb64057ae53b0	Malicious executable
msmp.exe	a82e496b7b5279cb6b93393ec167dd3f50aff1557366784b25f9e51cb23689d9	Malicious executable

Table 5 lists malicious accounts created by Gunra actors to gain initial access to victim Fortinet devices.

Table 5. Malicious Fortinet User Accounts

Username	Details
forticloud-sync	CVE-2024-55591 and CVE-2025-24472 allow threat actors to exploit scheduled tasks on vulnerable FortiOS firewall devices to create a new, malicious persistent user forticloud-sync with super user privileges and a hard-coded password.

MITRE ATT&CK Tactics and Techniques

See Table 6 to Table 18 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 6. Initial Access

Technique Title	ID	Use
Exploit Public-Facing Application	T1190	Gunra actors exploited vulnerabilities in FortiGate firewall and SSL-VPN appliances to gain initial access to victim networks.

Table 7. Execution

Technique Title	ID	Use
Windows Management Instrumentation	T1047	The Gunra ransomware binary contained specific WMI commands to delete volume shadow copies on victim machines.
Native API	T1106	The Gunra ransomware binary utilized Native APIs (FindFirstFileW, FindNextFileW) for file system discovery.
Command and Scripting Interpreter: Windows Command Shell	T1059.003	Gunra actors executed commands via cmd.exe on Windows to initiate the WMI command.

Table 8. Persistence

Technique Title	ID	Use
Account Manipulation	T1098	Gunra actors gained access to an unused account for a victim network. They altered the account configuration to bypass the mandatory password change requirement, which allowed them to use the compromised account for subsequent malicious activities.
External Remote Services	T1133	Gunra actors used external-facing remote services in combination with an administrator account to gain access.

Table 9. Privilege Escalation

Technique Title	ID	Use
Valid Accounts: Default Accounts	T1078.001	Gunra actors compromised an SSL-VPN appliance by exploiting default credentials and the absence of account lockout controls to obtain administrator access to the victim network device.
Valid Accounts: Domain Accounts	T1078.002	Gunra actors gained access to an administrator account for an SSL appliance.

Table 10. Stealth

Technique Title	ID	Use
Debugger Evasion	T1622	The Gunra ransomware Windows encryptor binary contained the IsDebuggerPresent API to defend against reverse engineering and debugging activity.
Indicator Removal: Clear Command History	T1070.003	Gunra actors cleared command history files on victim machines to prevent detection of their malicious activity.
Delay Execution	T1678	Gunra actors strategically timed their reconnaissance and malicious network activities to late night or early morning to avoid detection by the victim.
Selective Exclusion	T1679	The Gunra ransomware binary programmatically excludes certain directories and filetypes from encryption to ensure system critical files continue to function and that ransom notes are readable. In addition, the binary contains logic to prevent re-encryption of already Gunra-encrypted files.

Table 11. Defense Impairment

Technique Title	ID	Use
Disable or Modify Tools	T1685	Gunra actors cleared system/network logs on victim machines to prevent detection of their malicious activity.

Table 12. Credential Access

Technique Title	ID	Use
OS Credential Dumping: NTDS	T1003.003	Gunra actors used secretsdump.py on multiple victim domain controllers to extract password hashes for user accounts from the NTDS files.
Network Sniffing	T1040	Gunra actors abused SSL-VPN network traffic controls to capture users’ VDI login credentials and session information in transit, effectively sniffing authentication traffic for a victim network.
Steal Web Session Cookie	T1539	Gunra actors captured legitimate VDI session data for a victim, which allowed them to steal and reuse session cookies to hijack active sessions and impersonate legitimate users on the internal victim network.
Credentials from Password Stores	T1555	From a compromised virtual desktop, Gunra actors accessed the Hiware access control server for a victim and stole its symmetric encryption key.
OS Credential Dumping	T1003	Gunra actors used a stolen symmetric encryption key from a Hiware system access control server to decrypt and dump stored enterprise server passwords.
Modify Authentication Process: Multi-Factor Authentication	T1556.006	Gunra actors altered files in a victim’s VDI authentication server portal so that a specific attacker-chosen OTP always succeeded, creating a persistent backdoor that bypassed MFA.

Table 13. Discovery

Technique Title	ID	Use
File and Directory Discovery	T1083	The Gunra ransomware binary contains custom instructions to enumerate the complete directory structure of victim machines to identify user-data files and directories for encryption.
System Network Connections Discovery	T1049	Gunra actors enumerated active system network connections to map reachable internal infrastructure prior to ransomware deployment.

Table 14. Lateral Movement

Technique Title	ID	Use
Remote Services: Remote Desktop Protocol	T1021.001	Gunra actors used stolen VDI session information to access a victim’s internal VDI environment, then moved laterally via RDP to access the victim’s VDI authentication web server, internal AD server, and IT staff virtual desktops.
Remote Services: SMB/Windows Admin Shares	T1021.002	Gunra actors used SMB administrative shares with valid credentials to move laterally and deploy tools across compromised systems.
Use Alternate Authentication Material: Pass the Hash	T1550.002	Gunra actors used pass-the-hash methods to move laterally to privileged systems.
Use Alternate Authentication Material: Pass the Ticket	T1550.003	Gunra actors used pass-the-ticket methods to move laterally to privileged systems.

Table 15. Collection

Technique Title	ID	Use
Collection	TA0009	Gunra actors were observed collecting business-critical documents, databases, PII, and internal email communications.
Archive Collected Data	T1560	Gunra actors were observed utilizing tools such as 7-Zip, WinRAR, RClone, and others to copy and archive victim data for exfiltration.
Data from Cloud Storage	T1530	Gunra actors launched a malicious application (main.exe) that specifically targeted Microsoft Cloud Services (OneDrive and SharePoint) for data exfiltration.
Data from Local System	T1005	The Gunra ransomware binary recursed through the full directory structure of a compromised device to identify user-data files and directories for targeted exfiltration and subsequent encryption. In one instance, Gunra actors were observed collecting system and network configuration network information by connecting to the VDI environments of IT personnel.
Email Collection	T1114	Gunra actors collected internal email communications.

Table 16. Command and Control

Technique Title	ID	Use
Ingress Tool Transfer	T1105	After obtaining admin access to a victim’s SSL-VPN appliance, Gunra actors downloaded an SSH tunneling tool from an external server to create and maintain persistent tunnel connections to compromised systems in the victim’s network.
Protocol Tunneling	T1572	Gunra actors used an SSH tunneling tool to establish connections and maintain persistence between compromised systems.

Table 17. Exfiltration

Technique Title	ID	Use
Exfiltration Over Web Service	T1567	Gunra actors were observed archiving victim data and exfiltrating it over the file-sharing service Mega.
Exfiltration Over Alternative Protocol	T1048	Gunra actors used Filezilla software to exfiltrate data over FTP.

Table 18. Impact

Technique Title	ID	Use
Data Encrypted for Impact	T1486	Gunra actors encrypt victim data using combined ChaCha20 + RSA-4096 algorithms to prevent victim access to critical business files. Gunra encryptors are available for Windows and Linux, increasing the potential attack surface within a victim network. In one instance, Gunra actors encrypted key assets that included database servers and NAS systems.
Financial Theft	T1657	Under the double-extortion model, Gunra actors demand ransom payment through a ransom note (R34DM3.txt) in cryptocurrency. The note instructs victims to make the payment to prevent public leaks of their sensitive business data and acquire decryption keys to unlock encrypted files on compromised systems.
Inhibit System Recovery	T1490	To augment encryption of critical data on victim networks and prevent system recovery, Gunra actors disable backup features, such as volume shadow copies. In one instance, Gunra actors prevented restoration from backups by deleting backup and archived data stored at the primary data center and disaster recovery center.

Incident Response

If a potential compromise is detected, but ransomware actors have not (yet) encrypted items, organizations should take the following actions:

1. Determine which hosts were compromised and isolate them by quarantining or taking them offline.
   
   1. If the incident involves a Gunra Linux variant, preserve encrypted files, file timestamps, ransom notes, and relevant system logs.
      
      1. As of March 2026, researchers identified a weakness in the Gunra ransomware’s Linux Executable and Linkable Format (ELF) variants (appended with .GNRA); the encryption keys use a weak pseudorandom number generator (PRNG) seeded with the predictable system srand(time(NULL)).¹⁴ Defenders may leverage this to mathematically reconstruct the keys using file timestamps and recover files without paying the ransom.
2. Initiate threat hunting activities to scope the intrusion. Collect and review relevant artifacts, logs, and other data to identify threat actor TTPs, compromised devices and accounts, a timeline of activity, etc. Responders should consider:
   
   1. Reviewing logs of network appliances (e.g., edge devices) to audit actions associated with privileged users to identify anomalous activity.
   2. Collecting copies of ransom notes to identify current threat actor communication platforms.
   3. Auditing the creation of new files (particularly archives) to determine possible pre- or post-exfiltration activity.
3. Report the compromise to the FBI and other agencies as appropriate (see Reporting for contact information).
4. Apply eviction countermeasures, including those listed below, to contain the incident and eradicate the threat actor from the network (Note: Start applying countermeasures after collecting enough threat hunting data to inform effective countermeasure selection; this will likely overlap with threat hunting activities).
   
   1. Identify and disable malicious, actor-controlled accounts.
   2. Identify and secure legitimate, privileged accounts.
   3. Use CISA’s Eviction Strategies Tool to assemble countermeasures for a systematic eviction plan—the tool comprises Playbook-NG (a web application) and COUN7ER (a database of post-compromise countermeasures mapped to adversary TTPs).
      
      1. Use Playbook-NG and COUN7ER together to assemble a systematic eviction plan, or playbook, that leverages distinct countermeasures to contain and evict cyber threat actors. The playbook features a list of recommended response actions based on threat actor TTPs and includes each action’s intended outcome, preparatory steps, and associated risks. For more information, see CISA’s Eviction Strategies Tool Fact Sheet.
5. Harden the network to prevent additional malicious activity (see Mitigations for guidance).

If compromise is detected and items have been encrypted, see the “Ransomware and Data Extortion Response Checklist” in CISA’s joint #StopRansomware Guide.

Mitigations

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

• Prioritize patching known exploited vulnerabilities [CPG 2.B] and the CVEs in this advisory in internet-facing systems—including VPN gateways and RDP-exposed infrastructure—and keep all OSs, software, and firmware up to date to support this.
• Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (e.g., hard drive, storage device, the cloud) [CPG 3.I, 3.O, 1.C].
• Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts [CPG 2.A, 2.E].
• Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege [CPG 3.G].
• Segment networks [CPG 3.I] 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.
• Require MFA for all services to the extent possible, particularly for webmail, VPNs, and accounts that access critical systems [CPG 3.F].
• Disable command-line and scripting activities and permissions. Privilege escalation and lateral movement often depend on software utilities running from the command line. If threat actors are not able to run these tools, they will have difficulty escalating privileges and/or moving laterally [CPG 3.G, 3.M].

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 6 to Table 18).
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.
• #StopRansomware Guide: Resource to mitigate a ransomware attack.
• Cyber Hygiene Services, Ransomware Readiness Assessment: CISA’s no-cost cyber hygiene services.
• USSS’s Preparing for a Cyber Incident: Outlines basic steps an organization can take before, during, and after a cyber incident.

Reporting

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

The FBI and other authoring agencies are 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, cryptocurrency 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, the FBI and CISA urge you to promptly report ransomware incidents to the FBI’s Internet Crime Complaint Center (IC3) or a local FBI field office, to USSS via a local USSS Field Office, or CISA via the agency’s Incident Reporting System or its 24/7 Operations Center (contact@cisa.dhs.gov), or by calling 1-844-Say-CISA (1-844-729-2472).

South Korean organizations: Report cybersecurity incidents to KNPA via the online cybercrime reporting system or by calling 112.

Disclaimer

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

Version History

August 10, 2026: Initial version.

Notes

¹ For information on historical Conti ransomware activity, see CISA and FBI’s Conti Ransomware advisory.

² Breakglass Intelligence, “Gunra Ransomware’s Linux Variant Has a Fatal Flaw: time()-Seeded rand() Makes Encrypted Files Recoverable Without Paying,” Breakglass Intelligence, March 12, 2026, https://intel.breakglass.tech/post/gunra-ransomware-s-linux-variant-has-a-fatal-flaw-time-seeded-rand-makes-encrypted-files-recoverable-without-paying; Jeffrey Francis Bonaobra, Melvin Singwa, Emmanuel Panopio “Gunra Ransomware Group Unveils Efficient Linux Variant,” Trend Micro, July 29, 2025, https://www.trendmicro.com/en_us/research/25/g/gunra-ransomware-linux-variant.html; and CYFIRMA, “Gunra Ransomware – A Brief Analysis,” CYFIRMA, May 3, 2025, https://www.cyfirma.com/research/gunra-ransomware-a-brief-analysis/.

³ CloudSEK, “Inside Gunra RaaS: From Affiliate Recruitment on the Dark Web to Full Technical Dissection of their Locker,” CloudSEK, February 11, 2026, https://www.cloudsek.com/blog/inside-gunra-raas-from-affiliate-recruitment-on-the-dark-web-to-full-technical-dissection-of-their-locker.

⁴ CYFIRMA, “Gunra Ransomware – A Brief Analysis”; and Breakglass Intelligence, “Gunra Ransomware’s Linux Variant Has a Fatal Flaw.”

⁵ Bonaobra, “Gunra Ransomware Group Unveils Efficient Linux Variant”; and CloudSEK, “Inside Gunra RaaS.”

⁶ CloudSEK, “Inside Gunra RaaS.”

⁷ CYFIRMA, “Gunra Ransomware – A Brief Analysis.”

⁸ CloudSEK, “Inside Gunra RaaS.”

⁹ CloudSEK, “Inside Gunra RaaS.”

¹⁰ Bonaobra, “Gunra Ransomware Group Unveils Efficient Linux Variant.”

¹¹ VirusTotal, “VirusTotal - File - 91f8fc7a3290611e28a35a403fd815554d9d856006cc2ee91ccdb64057ae53b0,” VirusTotal, https://www.virustotal.com/gui/file/91f8fc7a3290611e28a35a403fd815554d9d856006cc2ee91ccdb64057ae53b0/details.

¹² CloudSEK, “Inside Gunra RaaS.”

¹³ CYFIRMA, “Gunra Ransomware – A Brief Analysis.”

¹⁴ Breakglass Intelligence, “Gunra Ransomware’s Linux Variant Has a Fatal Flaw.”

 

Executive summary 

A group of Russian state-supported cyber actors has been targeting and compromising various Western government and commercial organizations using the Zimbra Collaboration Suite (ZCS) software since at least July 2025. The Russian state-supported advanced persistent threat (APT) group’s activity is tracked in the cybersecurity community under several names (see Cybersecurity industry tracking), primarily as “LAUNDRY BEAR,” a name initially coined by the Netherlands General Intelligence and Security Service (AIVD) and Defence Intelligence and Security Service (MIVD) [1].

LAUNDRY BEAR’s targeting is almost certainly to gather sensitive information for the Russian Federation, with these actors primarily focusing on the covert acquisition of email data. Previous campaigns indicated LAUNDRY BEAR relied on unsophisticated initial access techniques—including password spraying, phishing, and pass-the-cookie—allowing the group to successfully run high-volume operations. The latest campaign targeting ZCS uses a novel exploit that was a zero-day vulnerability when first exploited and continues to be successfully exploited. The vulnerability, Common Vulnerabilities and Exposures (CVE) CVE-2025-66376, was patched in November 2025. This demonstrates LAUNDRY BEAR’s intent and ability to deploy increasingly sophisticated technical capabilities.

Unlike traditional phishing campaigns that persuade a user into taking an action, such as clicking a link or opening a file, LAUNDRY BEAR’s latest campaign leverages a view-based exploit that only requires a user to view a malicious email within a vulnerable version of the webmail service. Once viewed, the exploit attempts to exfiltrate the victim’s last 90 days of email communications, the organization email directory (i.e., Global Address List [GAL]), and other sensitive information to servers controlled by LAUNDRY BEAR. The exploit also attempts to establish persistent access to victim accounts through a variety of means as detailed in the Persistence and credential access section.

This Cybersecurity Advisory (CSA) warns of this ongoing malicious threat activity and urges organizations to update their vulnerable software and implement additional mitigations to thwart these Russian state-supported actors’ continued success. The CSA is being released by the following authoring and co-sealing agencies:

• United States National Security Agency (NSA)
• United States Federal Bureau of Investigation (FBI)
• Netherlands Defence Intelligence and Security Service (MIVD)
• Netherlands General Intelligence and Security Service (AIVD)
• United States Cybersecurity and Infrastructure Security Agency (CISA)
• United States Defense Counterintelligence and Security Agency (DCSA)
• United States Department of Defense Cyber Crime Center (DC3)
• United States Department of the Treasury
• United States Naval Criminal Investigative Service (NCIS)
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• Communications Security Establishment Canada’s (CSE’s) Canadian Centre for Cyber Security (Cyber Centre)
• 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)¹
• Danish Defence Intelligence Service (DDIS)²
• Estonian Foreign Intelligence Service (EFIS)³
• Finnish Defence Intelligence (FDI)⁴
• Finnish Security and Intelligence Service (SUPO)⁵
• French General Directorate for Internal Security (DGSI)⁶
• French National Cybersecurity Agency (ANSSI)⁷
• Italian External Intelligence and Security Agency (AISE)⁸
• Italian Internal Intelligence and Security Agency (AISI)⁹
• Security and Intelligence Service of the Republic of Moldova (SIS RM)¹⁰
• Polish Foreign Intelligence Agency (AW)¹¹
• The Military Counterintelligence Service of Poland (SKW)¹²
• Spain National Intelligence Centre (CNI)¹³
• Sweden National Cyber Security Centre (NCSC-SE)¹⁴

The authoring agencies urge any organizations using ZCS to implement the recommendations listed within the Mitigations section of this advisory to reduce the risk associated with this activity. This CSA also includes specific remediations for organizations to implement if they discover the presence of the listed Indicators of compromise (IOCs).  

As more organizations update their ZCS software based on this CSA, LAUNDRY BEAR may discontinue the current campaign exploiting this vulnerability; however, based on the success of this and previous campaigns, it is very likely that the group will continue to target ZCS and other email systems used by organizations in Western countries. The actors will almost certainly continue to rely on email to engage potential victims by exploiting novel vulnerabilities and, when necessary, use social engineering techniques to assist with their efforts. The authoring agencies recommend organizations regularly update their mail service software and continuously monitor their email systems and emails for malicious activity.

For a downloadable list of IOCs, see:

• AA26-204A.stix.xml (STIX XML)
• AA26-204A.stix.json (STIX JSON)

Cybersecurity industry tracking

The cybersecurity industry provides overlapping cyber threat intelligence, indicators of compromise (IOCs), and mitigation recommendations related to these Russian state-supported cyber actors. While not exhaustive, the following are threat group names commonly used for these actors within the cybersecurity community:

• LAUNDRY BEAR
• Void Blizzard [2]
• CL-STA-1114 [3]
• TA488 (formerly UNK_PitStop) [4]

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

Background

Public advisories from Netherlands General Intelligence and Security Service (AIVD), Netherlands Defence Intelligence and Security Service (MIVD), and Microsoft highlighted these Russian state-supported advanced persistent threat (APT) actors in May 2025, calling them LAUNDRY BEAR and Void Blizzard respectively [1] [2]. Both advisories assessed that the group was engaged in malicious cyber activity as early as April 2024.  

The May 2025 advisories highlighted a cluster of activity targeting cloud-based email environments, including Microsoft Exchange in particular, and abusing legitimate APIs to perform data exfiltration in bulk [T1114.002]. The group relied on unsophisticated means of initial access, including procuring stolen credentials on criminal marketplaces [T1078], and using social engineering techniques to lure targets into interacting with a malicious site masquerading as a legitimate one. As of April 2025, one of these sites resembled a European Defence & Security Summit registration portal that required registrants to sign in to their Microsoft account to view. Once a user entered their Microsoft credentials into this malicious site, LAUNDRY BEAR’s modified version of the open source adversary emulation toolkit, Evilginx, intercepted the user’s credentials. LAUNDRY BEAR then used this authentication data, including passwords and session tokens, to access the compromised account and conduct mass email exfiltration, as well as harvest other information. This method of compromise is commonly known as an adversary-in-the-middle (AiTM) technique [T1557].  

Beginning around July 2025, LAUNDRY BEAR shifted toward a more technical method of email compromise, highlighting their continued efforts to covertly acquire email communications from a variety of Western organizations of interest and deliver them to the Russian Federation. Using a custom-developed capability [T1587.001] named “Улей” or “Ulej” (Russian for beehive), LAUNDRY BEAR successfully targeted and exfiltrated sensitive user information from organizations who use the Zimbra Collaboration Suite (ZCS) product [T1114]. Data LAUNDRY BEAR attempted to exfiltrate from compromised accounts included:

• Last 90 days of emails,
• Email address,
• Password [T1589.001],
• Global Address List (GAL) [T1087],
• Two-factor authentication (2FA) tokens, and
• Newly-created Application Passcode [T1098].

The covert and persistent nature of this activity, along with the absence of any known financial extortion, almost certainly indicates this group’s involvement in espionage activities with Russian government backing. Additionally, extensive Ukrainian targeting, prior to use against U.S. and other NATO allies, outlines an increasing trend within Russian cyber threat groups to target Ukrainian users first—both as a priority target and as a testbench for malicious cyber techniques before broader global deployment.

Targeting details

LAUNDRY BEAR has targeted and compromised users in various organizations, including those associated with:

• the Defense Industrial Base (DIB),  
• the federal and local government,
• education,
• energy,
• law enforcement,  
• media,  
• non-governmental organizations, and
• technology.

Technical details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 19. This advisory also uses MITRE D3FEND^TM version 1.4.0¹⁵. See Appendix A and Appendix B for tables of the activity mapped to MITRE ATT&CK and D3FEND tactics, techniques, and countermeasures.

Ulej is a novel data exfiltration and aggregation capability, that currently (as of the publication of this report) supports a campaign specifically targeting users of ZCS webmail servers. This capability is used to exploit CVE-2025-66376 [Common Weakness Enumeration (CWE) CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')], but likely could be adapted to exploit other vulnerabilities. It exfiltrates emails and other sensitive user data from a victim’s system immediately after exploitation and stores the data in an actor-controlled unattributable virtual private server (VPS) [T1074.002] running LAUNDRY BEAR’s “Flowerbed” collection framework. The collected data is almost certainly further exfiltrated to internal network resources for review and long-term retention.

Reconnaissance

LAUNDRY BEAR uses the Ulej capability to exploit the CVE-2025-66376 vulnerability in organizations using ZCS. This campaign’s targeted victimology and limited exploitation capabilities likely indicate this group manually identifies and targets the victim organizations. LAUNDRY BEAR likely identifies organizations with public-facing Zimbra infrastructure by port scanning [T1595] and fingerprinting datasets easily procured through various commercial vendors [T1596.005].  

After identifying a target organization, the group likely compiles email addresses for individual users to target with the exploit [T1589.002] from datasets offered by commercial vendors [T1597.002], open source intelligence [T1593], or previously exfiltrated data [T1597].  

Resource development

The actors procure VPSs from a variety of providers [T1583.003], including those with Know Your Customer (KYC) requirements, and often use fabricated identities. LAUNDRY BEAR primarily uses Mullvad VPN [T1583] when interacting with these servers, further demonstrating the group’s intent to mask their identity and maintain operations security (OPSEC). After the server is provisioned, an automated process deploys the Docker containers necessary for Ulej’s Flowerbed framework [T1608], which then receives and aggregates the data Ulej exfiltrates. These servers are typically only used for 7-60 days before moving to new infrastructure.

Flowerbed framework

Flowerbed is a Python project that uses Docker for containerization. The project includes four different Docker containers:

• Catcher,
• Certbot,
• Nginx, and
• Gardener.

Catcher acts as both a DNS and HTTP server to receive and aggregate exfiltrated victim information [T1048]. For additional information on Catcher, refer to the Exfiltration section of this advisory. Flowerbed’s next container, Certbot, is based on one of the official Certbot containers, which allows for automated generation of Let’s Encrypt certificates using DNS challenges through Cloudflare. This certificate can then be used by the Nginx container, which serves as an HTTPS reverse proxy for Catcher, enabling Flowerbed to disguise some of its exfiltration activity through an encrypted communications channel [T1048.002]. The Nginx reverse proxy also validates that the Server Name Indicator (SNI) value contains “*.i.*” prior to forwarding the traffic to Catcher. If the SNI does not contain that string, the Nginx server returns a 444 error to the client. This is likely an attempt to reject non-Ulej connections. Finally, the Gardener container functions as a health check for the Catcher service. Gardener is a simple Python script that validates Catcher correctly receives and processes data.

The simplistic Flowerbed codebase has indications that artificial intelligence (AI) played a role in its development. This highlights how AI is increasingly being used to develop malicious capabilities [T1588.007]. The dependence on AI for a simple capability, such as Flowerbed, alongside a previous reliance on open source capabilities, such as Evilginx2 [T1588.002], likely indicates a lack of advanced technical knowledge within LAUNDRY BEAR, especially in relation to true software development capabilities.

Initial access

To gain initial access, LAUNDRY BEAR sends an email containing a malicious JavaScript payload to the target [T1566]. Through exploitation of CVE-2025-66376, this JavaScript payload is immediately executed once the user views the malicious email [T1203], such as the one shown in Figure 1, in the ZCS webmail platform. Since at least November 2025, LAUNDRY BEAR began sending these phishing emails from victim infrastructure through compromised accounts [T1199], as shown in the email metadata in Figure 2. These compromised accounts were likely previous victims of this, or another LAUNDRY BEAR, campaign and their use is intended to further obfuscate and frustrate anti-phishing tools and training.

According to the National Vulnerability Database (NVD), CVE-2025-66376 was initially published on 5 January 2026. This vulnerability allows for execution of a JavaScript payload included in email content due to improper sanitization of Cascading Style Sheet’s (CSS) @import directives within an email [5]. Because the activity attributed to this campaign began in July 2025—months before Synacor released a patch and the CVE was published—the payload initially exploited a zero-day vulnerability at that time [T1587.004].  

Utilization of a zero-day exploit within this campaign demonstrates the ability for even emerging threat groups like LAUNDRY BEAR to operationalize novel exploits into a highly successful capability.

Hidden in LAUNDRY BEAR’s email is a Base64 encoded payload within the “onload” field of a Scalable Vector Graphics (SVG) element [T1027.017], as shown in Figure 3. Leading up to the inclusion of this payload in the SVG element are various instances of @import directives, as required to leverage CVE-2025-66376. This payload includes an XOR encrypted final script encoded in a Base64 inner payload (see Figure 3) [T1027.013]. The outer payload decodes and decrypts the inner payload using an XOR function and a hardcoded key and then executes the script contained within the inner payload containing the collection and exfiltration logic. By changing the key used for the XOR encryption of the inner payload or adding additional @import directives with non-functional code [T1027.010], LAUNDRY BEAR can easily generate new payloads that bypass basic threat detection signatures. This malicious payload attempts to collect and exfiltrate information in 12 asynchronous stages [T1119]. The stages in order of appearance within the payload are as follows:

1. sendStartPing,
2. gather_email,
3. gather_environment,
4. gather_2fa_codes,
5. gather_app_password,
6. gather_device_status,
7. gather_oauth_consumers,
8. gather_autocomplete_password,
9. enable_mail_protocols,
10. gather_gal,
11. sendArchives, and
12. sendFinishPing. 

Use of a zero-day exploit within this campaign demonstrates the ability for even emerging threat groups like LAUNDRY BEAR to operationalize novel exploits into a highly successful capability [T1587].

Persistence and credential access

To establish sustained persistence into the victim’s email account, the script attempts to modify account preferences and collect authentication information. Any collected credentials are later exfiltrated, as further described in the Exfiltration section below. Other campaigns attributed to LAUNDRY BEAR also demonstrated the group’s ability to circumvent multi-factor authentication through session token replay [T1550.004], and the Zimbra campaign follows a similar trend.

The script used in this campaign tries to discover the victim’s email address during the gather_email stage [T1087]. The script searches for this email address in two ways. First, it examines the batchInfoResponse variable, which an HTML script element on the webpage can define, for an email address. Even if the script finds an email address there, it also checks whether it acquired a Cross-Site Request Forgery (CSRF) token as described later in the Collection section of this advisory. If so, the script uses the “GetIdentitiesRequest” Simple Object Access Protocol (SOAP) command under the “ZimbraAccount” namespace to determine the victim’s email address [T1185] and then exfiltrates it. However, if the script does not have a CSRF token or the SOAP request fails, the script exfiltrates the email value recovered from the first method instead. If both attempts fail to capture the victim’s email, the script sends a JavaScript Object Notation (JSON) payload with a key of “email” and value of null over HTTPS and does not attempt DNS exfiltration.

During the gather_autocomplete_password stage, the script attempts to collect the victim’s saved password via the autocomplete feature of the victim’s password manager. The script injects two HTML div elements requesting login credentials onto the page outside of the victim’s view, as shown in Figure 4 and Figure 5. After waiting five seconds, the script then attempts to extract the password provided automatically by the password manager from the input element shown in Figure 4. If there is no value in that input field, it checks the password input field shown in Figure 5. If neither input field contains a value, a JSON payload with a key of “autocomplete_password” and value of null is sent over HTTPS and DNS exfiltration is not attempted.

LAUNDRY BEAR almost certainly relies on a mail client using the Internet Message Access Protocol (IMAP) for persistent access to the victim’s mailbox. During the enable_mail_protocols stage, a SOAP request leveraging the “ModifyPrefsRequest” command under the “ZimbraAccount” namespace is sent. This request attempts to set the “zimbraPrefImapEnabled” preference to TRUE. While the default setting for “zimbraPrefImapEnabled” is not well documented, this action is almost certainly intended to ensure that IMAP access to the victim’s mailbox is enabled.

ZCS does not support 2FA for some mail clients, including IMAP. To support users who rely on IMAP clients, ZCS allows for the generation of Application Passcodes. Application Passcodes are randomly generated passwords that can be used for clients that cannot support the normal 2FA process to authenticate. During the gather_app_password stage, the script makes a SOAP request using the “CreateAppSpecificPasswordRequest” command under the “ZimbraAccount” namespace to create a new Application Passcode [T1556.006]. The SOAP request uses “ZimbraWeb” as the name of the application.

Additionally, the script also attempts to collect 2FA tokens. During the gather_2fa_codes stage, the script makes a SOAP request using the “GetScratchCodesRequest” command under the “ZimbraAccount” namespace. The script then attempts to exfiltrate any non-null 2FA codes collected this way. The number of codes can vary, and each code is exfiltrated to Flowerbed individually.

Collection

As demonstrated in the Persistence and credential access section, this script relies heavily on SOAP requests to collect victim information. To make these requests, the script aims to acquire the victim’s current CSRF token, which it attempts to access within the webpage’s local storage using localStorage.getItem("csrfToken"). If the script is unable to acquire this CSRF token, it will be unable to make any SOAP requests. In addition to the SOAP commands documented in the Persistence and credential access section, other SOAP commands executed to collect victim information are shown in Table 1.

Table 1: Additional SOAP commands used

SOAP Command	Namespace	Stage
GetInfoRequest	zimbraAccount	gather_environment
GetDeviceStatusRequest	zimbraSync	gather_device_status
GetOAuthConsumersRequest	zimbraAccount	gather_oauth_consumers
SearchGalRequest	zimbraAccount	gather_gal

The script attempts to collect the victim’s GAL through brute force by searching for each two-character combination from a character set of “abcdefghijklmnopqrstuvwxyz1234567890.-_”. These queries are conducted using 20 batches of SOAP requests with 77 “SearchGalRequest” SOAP commands in each batch except for the last request containing only 58.

During the gather_environment stage, the script attempts to determine which type of ZCS webmail client the victim is using. The script checks the user’s current URL to determine the client type being used, checking for certain indicators (shown in Table 2) to determine the client type. The corresponding value is then used as the payload when exfiltrating the client type.

Table 2: ZCS webmail client types

Indicator	Client Type	Associated Value
?client=advanced	Advanced	c
/h/	Standard	h
/modern/	Modern	m

As part of collection, the script attempts to harvest any emails not marked as “junk” from the last 90 days from the victim’s account. Emails are collected daily by an HTTP GET request to the URL path, “/home/~/?fmt=tgz&meta=0&query=date:-{DAY_OFFSET}d AND (not in:junk)”. The {DAY_OFFSET} value would be between 0 and 89 representing how many days ago the email was sent or received. To prevent redundant collection and exfiltration of emails, a variable with a name based on the email date being queried, using a format of zd_comp_YYYY-MM-DD, and value of true, is saved to the window.top.localStorage property. This variable is saved regardless of whether the email is successfully exfiltrated.  

According to Mozilla documentation, if the user is not in a private browsing session, any data stored to localStorage does not typically expire. This means that if the user happens to execute the script again from the same computer, the script avoids attempting to re-exfiltrate previously captured emails. However, the script always attempts to pull any emails with a {DAY_OFFSET} of zero. In other words, the script always pulls emails sent or received the same day it is run. After email results are returned from the query for each day of email activity, those results are then passed to Flowerbed as described in the Exfiltration section.

The script also provides LAUNDRY BEAR with telemetry on any errors that occur during the collection process. This is accomplished by executing any collection or exfiltration code through helper functions that contain error handling logic. If an error occurs, a payload containing information on the error itself, the context of the error happening, and the stage in which the error occurred is sent to Flowerbed as described in the Exfiltration section below. For cases where the error occurs within a SOAP request, “:api” is concatenated to the stage value in the payload. If an error occurs during the batch SOAP requests that occur when collecting the GAL of the victim, the stage value will use a format of gather_gal:{VAL}:api. The {VAL} placeholder indicates which batch request, a number from 0 to 19, the error occurred in. Errors that occur during the password autocomplete interception process will use “gather_autocomplete_password:dom” for the stage value. Finally, if an error occurs when attempting to collect or exfiltrate a specific day’s emails, the stage will include which day the error occurred on, using the previously defined placeholder {DAY_OFFSET}, with a format of sendArchive:day-{DAY_OFFSET}.

Exfiltration

At the end of each stage in the collection process, the script attempts to exfiltrate acquired information to Flowerbed. The script primarily relies on two forms of data exfiltration: DNS [T1048.003] and HTTPS. Some information is exfiltrated over both the DNS and HTTPS channels.

Prior to exfiltration, a randomized 10- or 11-character alphanumeric string is generated as an identifier for the victim. This identifier is included in the URL of both the DNS- and HTTPS-based exfiltration.  

DNS exfiltration

DNS exfiltration occurs through DNS A record queries. To ensure data exfiltrated through DNS is not corrupted when traversing through non-actor-controlled DNS infrastructure, Ulej maintains compliance with RFC 1035, Domain Names - Implementation and Specification, specifically accounting for the case insensitivity and subdomain length requirements. Base32 encoding is used to create a case-insensitive payload. Once the payload is encoded, a period (“.”) is added every 60 characters to ensure each subdomain is under 63 characters long. The script then creates a new image object sourced from a URL with the scheme defined in Figure 6. Any traffic involving DNS exfiltration will have “d-“ prefixing the victim identifier, and the subdomain immediately following indicates the type of information being exfiltrated.

When the script generates an image object, the browser tries to retrieve the complete domain of the URL specified as the source of the image. This triggers a DNS request sent to the actor-controlled server and processed by Flowerbed. Table 3 lists both the information exfiltrated via DNS and their corresponding data type identifiers in the DNS queries.  

Table 3: DNS exfiltration

Type of Information	Exfiltration Stage	Data Type
Victim’s Email Address	gather_email	e
Client Type	gather_environment	c
Zimbra Version	gather_environment	v
URL at Time of Exploitation	gather_environment	url
2FA Scratch Codes	gather_2fa_codes	2fa
Newly Created Application Password	gather_app_password	pa
Harvested Autocomplete Password	gather_autocomplete_password	pw

HTTPS exfiltration

Any information exfiltrated via DNS is also exfiltrated through HTTPS, as well as additional data including email content, contacts, attachments, and error logging information. By using Let’s Encrypt certificates, this group can quickly deploy new infrastructure and leverage encrypted HTTPS communications with valid server certificates when exfiltrating information from the victim’s environment. The HTTPS exfiltration capability only uses two HTTP content types, defined in Table 4. Traffic associated with HTTPS exfiltration will use the URL scheme shown in Figure 7.  

Table 4: HTTPS exfiltration types

Content Type	URL Path
application/json	/v/p
application/octet-stream	/v/d

Some of the data transmitted via HTTPS uses the standard JSON content type format. The script includes the information in a POST request to actor-controlled infrastructure.  

Table 5 provides a summary of the JSON-based exfiltration.

Table 5: HTTPS JSON exfiltration  

Type of Information	Exfiltration Stage	JSON Key(s)
Victim’s Email Address	gather_email	email
Client Type, Version, and Current URL	gather_environment	client, version, full_url
Newly Created Application Password	gather_app_password	app_password
Harvested Autocomplete Password	gather_autocomplete_password	autocomplete_password

The script transmits all HTTPS exfiltration not identified in Table 5 using the Octet-Stream content type as binary data. The POST requests for this method include a filename in the “X-Filename” header. Traditionally, developers use headers prefixed with “X-” to denote custom headers that do not follow a defined standard. The purpose of including this header remains unclear since the Catcher capability ignores the provided filename when saving the data. Table 6 summarizes the data exfiltrated in this format.

The script sends all exfiltrated data identified in Table 6 to the Catcher service exactly as received from the SOAP request in a JSON payload, except for email exfiltration. For email exfiltration, the script sends it as a GZIP compressed archive [T1560]. Although most of the exfiltration consists of valid JSON, the script still attempts to exfiltrate all information identified in Table 6 using the application/octet-stream content typing rather than application/json.

At the beginning and end of the collection and exfiltration activity, during the sendStartPing and sendFinishPing stages respectively, the script submits a POST request with a JSON payload to indicate that the script is starting or finishing execution. Throughout execution, the script also logs error events and send the logs using similar JSON payloads. The script sends the JSON in a POST request to the URL documented in Figure 2, using a URL path of “/v/p” and with a “subtype” key that shows which type of action it logged (start, finish, or error).  

Catcher

Ulej exfiltrates information to Flowerbed to be handled by a service named Catcher. Catcher is a containerized Python application, running in Docker as part of Flowerbed, which is detailed in the Resource development section. It receives exfiltrated data and temporarily stores it, enabling its eventual transfer to infrastructure designed for long-term, secure storage.

Catcher acts as an HTTP server over port 8000 and a DNS server on port 53. As described in the Resource development section, the Flowerbed project uses an additional Docker container running an Nginx reverse proxy to enable HTTPS support. This reverse proxy uses a certificate generated by Let’s Encrypt and forwards all traffic with an SNI containing “*.i.*” to port 8000 within the Catcher container.

The DNS service can accept A, AAAA, MX, TXT, and CAA queries. For any MX, AAAA, or CAA queries, the server will always provide an empty response. The system only supports TXT records as needed to process Automatic Certificate Management Environment (ACME) requests, which enable the assignment of Let’s Encrypt certificates. If the server receives an A query, Catcher will always respond with the public IP address of the Flowerbed server.  

However, if a query includes a domain formatted as shown in Figure 6 and Figure 7, the service saves a log file in JSON format to disk containing the following details of the DNS query:

• Time of query,
• Source IP address for query,
• Queried domain, and
• Type of query.

The HTTP server typically responds with OK, except in cases where the path is “pixel.gif” when the response contains a 1x1 gif image with a SHA-256 hash of ef1955ae757c8b966c83248350331bd3a30f658ced11f387f8ebf05ab3368629. Like the DNS service, the HTTP service will only log entries when the domain found in the host header of the request follows the expected formatting as seen in Figure 6 and Figure 7. As the HTTPS exfiltration uses non-standardized binary and JSON-formatted payloads when exfiltrating to Catcher, Catcher will check the content type of the request. If the content type is set to “application/json”, Catcher encodes the data in Base64 and includes it in the JSON log entry written to disk. If the content type is set to any other value, Catcher leaves the Base64 payload in the JSON log entry blank and saves the payload to a separate file with the same filename as the JSON log entry with a “.bin” file extension. An HTTPS exfiltration event causes Catcher to save a JSON formatted log file to disk containing the following information from the HTTP request:

• Time,
• Source IP address,
• Request method,
• Host,
• Path,
• Query string,
• Headers, and
• Base64 payload.

These JSON event log files and binary output files are then initially saved to the directory /root/hits/tmp and later moved to the /root/hits/ready directory once processed. This prevents incomplete files, which are still being uploaded to Catcher, from premature exfiltration from the server. Approximately every 60 seconds, a likely automated workflow establishes a Secure Shell (SSH) connection with the server hosting Flowerbed for a few seconds, almost certainly exfiltrating the data processed by Catcher to non-public-facing infrastructure. The command in Figure 8 also executes hourly to remove all files last modified at least two days ago from the /root/hits/ready directory.

Response strategies

Mitigations

In many cases, by the time an organization identifies a compromise related to this campaign, numerous sensitive and proprietary emails have already been exfiltrated. The significant risk posed by this cyber threat emphasizes the importance for organizations that use ZCS and other similar webmail solutions to take proactive steps to mitigate this risk.

All organizations that use the ZCS webmail service should immediately prioritize ensuring that their ZCS is not running a vulnerable version. A patch for CVE-2025-66376 was released for both 10.1.13 and 10.0.18 versions of ZCS [D3-AH]. If immediate patching is not feasible, organizations should advise employees to use alternative mail clients to access email and avoid using the Classic ZCS webmail client until ZCS is updated to a non-vulnerable version [d3f:Isolate].

System administrators should closely monitor any Internet-connected ZCS or other email systems and the workstations that access those systems and promptly apply available software updates [D3-AH]. Administrators can maintain awareness of active vulnerability exploitation by referencing open source resources, including CISA’s Known Exploited Vulnerabilities Catalog and NCSC-UK’s Responding to active exploitation of vulnerabilities guidance.

Organizations should consider using a third-party authentication service that supports passkeys for authentication to mediate access to ZCS and other services that do not natively support passkeys. By doing so, organizations can work to eliminate the possibility of automated password collection from autocomplete or password reuse [D3-CH]. However, Application Passcodes may still be necessary and should be monitored closely.  

Organizations should implement network monitoring capabilities with collection and short-term retention of packet capture or NetFlow data and maintain log collection and storage [CPG 3.Q]. This will allow organizations to monitor for and identify suspicious network activity [CPG 4.B], such as:

• Significant amounts of outbound data being sent to IPs associated with VPS providers not used by the organization [D3-NTA];
• Frequent DNS queries for a suspicious domain with seemingly random subdomains [D3-DNSTA];
• A sudden spike of connections to a server associated with a recently established domain [D3-NTCD]; and  
• Connections to internal services, such as webmail, from VPN providers frequently leveraged by this group for nefarious activity, such as Mullvad VPN [D3-NTCD].

Additionally, for organizations that can inspect the content of outbound HTTPS connections via break-and-inspect infrastructure, security teams should identify traffic matching the characteristics described in the Exfiltration section of this advisory.

Indicators of compromise (IOCs)

Flowerbed infrastructure

The following indicators have been attributed to use by LAUNDRY BEAR for their campaign targeting ZCS’s webmail service as of the publication of this advisory. (Disclaimer: Due to the frequency of operational structure changes by this group, these indicators are intended solely for historic attribution purposes. Some indicators, such as IPs, compromised emails, and domains, may be outdated, so organizations should check for current activity before acting on these IOCs.) Table 7 provides details about the server infrastructure used to host Flowerbed, and Table 8 lists the corresponding SHA-1 hash values for the Let’s Encrypt certificates used by that infrastructure [D3-IAA].

Table 7: Flowerbed server infrastructure

Domain	IP Address	First Seen	Last Seen
zmailanalytics[.]com	216.252.238[.]104	8 July 2025	15 October 2025
zimbra-metadata[.]com	216.252.238[.]18	20 August 2025	14 October 2025
analyticemailmeter[.]com	37.120.247[.]228	24 September 2025	18 March 2026
emailanalytics.com[.]ua	185.86.79[.]95	24 September 2025	18 March 2026
mailnalysis[.]com	104.248.134[.]194	11 November 2025	17 February 2026
zimbrastat[.]com	64.226.124[.]190	18 December 2025	18 March 2026
zimbrasoft.com[.]ua	193.238.152[.]66	20 January 2026	18 March 2026
synacorzimbra[.]nl	216.252.238[.]64	3 February 2026	30 March 2026
istc-cloud[.]com	194.156.103[.]193	5 February 2026	30 March 2026

Table 8: Flowerbed X.509 certificate SHA-1 hashes  

Associated Domain	X.509 SHA-1 Hash	First Seen	Last Seen
zmailanalytics[.]com	2e4f314bc9943cab5005d6fde0b271c74d47bc9d	8 Jul 2025	6 Aug 2025
*.i.zmailanalytics[.]com	50a87d926621dd06389ba50d86e0ff574ed713a8	6 Aug 2025	13 Oct 2025
*.i.zimbra-metadata[.]com	c5a72420e7bb308d078e62128430897f82194c95	20 Aug 2025	14 Oct 2025
*.i.analyticemailmeter[.]com	8959c4d29e29f02ea94ea8bb21c8df2594c5549d	24 Sep 2025	8 Nov 2025
*.i.emailanalytics.com[.]ua	62eb76432597694edb01c1fe57aab0cfe03a7178	25 Sep 2025	27 Sep 2025
*.i.mailnalysis[.]com	cddf5c3be1e07f28140aed165b929bf2d614922a	12 Nov 2025	17 Dec 2025
*.i.zimbrastat[.]com	18b3ad442ce73cc8656d51d75bbd7c855f2cb7e8	18 Dec 2025	28 Dec 2025
*.i.zimbrasoft.com[.]ua	1b25041ececf2457eef0270fc1d785cec8ec9ded	21 Jan 2026	10 Feb 2026
*.i.synacorzimbra[.]nl	e4fe6466a4f9a4249fe330651e914e45bbdca44a	5 Feb 2026	22 Mar 2026
*.i.istc-cloud[.]com	b6b77c9a455225d525834a403ca9ef5481ed0447	12 Feb 2026	30 Mar 2026

LAUNDRY BEAR has used the following email addresses to procure resources used for this campaign:

• ivanka.zurabishvili@proton[.]me,
• zmul1@buildandconsulting[.]com,
• garrysmithme@pinmx[.]net, and
• hostingclient@pinmx[.]net.

Phishing distribution

LAUNDRY BEAR primarily relied on ProtonMail for distribution of malicious email. However, as stated above, LAUNDRY BEAR’s more recent efforts likely have shifted to distributing the payload through previous victims.  

The following email addresses have distributed payloads attributed to this campaign:

• c.laurent.ejfa@proton[.]me,
• j.moreau.epsc@proton[.]me,
• liberty.insights@proton[.]me,
• certain email addresses (presumably compromised) at the isofts.kiev[.]ua domain (i.e., ending with @isofts.kiev[.]ua), and
• certain email addresses (presumably compromised) at the navs.edu[.]ua domain (i.e., ending with @navs.edu[.]ua).

Additionally, the following are SHA-256 hashes of email samples containing the malicious payload attributed to this campaign:

• 98df604ecc57f884a2e6ce3266a0013ad64455cac48442c2312cfa4765007aaf,
• 60db9abae75cd8ccc49dd7ea5feb41677566dcd442f12ebc5745ffd2810fb874,
• b1f5beb1175fc5c7d1806a2f0d900eb124c54f0286c5c52b66eea7a6633adb1d, and
• 1517b3caa495f6c4e832df9c75fc94667e3c233773f7fa4e056d5e30e5ead760.

Post-compromise artifacts

Currently, the script does not remove artifacts. This leaves additional opportunities to identify victims of this activity. While emphasis should always be placed on consistent monitoring of network traffic and endpoint activity, there are a variety of persistent artifacts described below that can be used to identify victims of this campaign.

This Ulej capability relies on creating a significant number of SOAP requests to collect account information for exfiltration. ZCS logs from these requests are stored, by default, in the /opt/zimbra/log/mailbox.log file [D3-PA]. A significant amount of SOAP request activity that aligns with what was described in the Persistence and credential access and Collection sections of this advisory could indicate a potential compromise. Specific examples of high-risk SOAP request activity might include:

• Many SearchGalRequest command requests from a single user over a short period of time;
• Use of the CreateAppSpecificPasswordRequest command, especially in cases where it is creating an Application Passcode named “ZimbraWeb”; and
• Use of the GetScratchCodesRequest command.

While LAUNDRY BEAR uses the localStorage property to track what days had emails previously exfiltrated, defenders can use this property to identify victims of this campaign and determine the scope of exfiltrated information [D3-PA]. Review of the items stored in that property for an organization’s ZCS webmail client page on an endpoint device could indicate compromise if there are items named with a format of zd_comp_YYYY-MM-DD, as explained in the Collection section of this advisory.

While Application Passcodes have non-malicious purposes, in this case instances of these passcodes with the name “ZimbraWeb” are almost certainly malicious. The ZCS webmail application can support 2FA natively and does not require the use of an Application Passcode, so there is no reason that there should be one named “ZimbraWeb.”

In instances where organizations identify victims of this campaign, they should also examine the inbox of the suspected victim for the original phishing email [D3-MA]. If an email that has a payload exploiting CVE-2025-66376 is discovered, steps should be taken immediately to identify and quarantine other instances of emails with similar body content, senders, and subject lines to prevent further exploitation and exfiltration.  

Remediation

In the event an organization identifies activity associated with this campaign, that organization should take steps to minimize further exploitation. The organization should consider requesting that employees minimize use of the ZCS webmail client until the organization updates to a patched version that is not vulnerable to CVE-2025-66376.

Organizations should use identifiers from the IOCs section of this report to identify any individuals compromised by this campaign and record the date(s) of compromise(s) to determine the scale and scope of emails exfiltrated.

All users from the organization should have all Application Passcodes and 2FA scratch keys revoked. Affected organizations should require all employees to change passwords in line with establishing minimum password strength requirements [CPG 3.B] and creating unique credentials [CPG 3.C], specifically noting that compromised employees might have had any password stored in a password manager exfiltrated.

Works cited

[1] Netherlands General Intelligence and Security Service (AIVD) and Netherlands Defence Intelligence and Security Service (MIVD). AIVD and MIVD identify a new Russian cyber threat actor. 2025. https://www.aivd.nl/site/binaries/site-content/collections/documents/2025/05/27/aivd-en-mivd-onderkennen-nieuwe-russische-cyberactor/Advisory+AIVD+en+MIVD+Public+report+on+new+cyber+actor.pdf

[2] Microsoft Corporation. New Russia-affiliated actor Void Blizzard targets critical sectors for espionage. 2025. https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/

[3] Palo Alto Networks Unit 42. Russian Global Webmail Espionage. 2026. https://unit42.paloaltonetworks.com/russian-webmail-espionage/ 

[4] Proofpoint. TA488 Targets Zimbra Mailservers with Half-Click Exploits. 2026. https://www.proofpoint.com/us/blog/threat-insight/ta488-zcs-exploit

[5] Seqrite. Operation GhostMail: Russian APT exploits Zimbra Webmail to Target Ukraine State Agency. 2026. https://www.seqrite.com/blog/operation-ghostmail-zimbra-xss-russian-apt-ukraine/  

Footnotes

¹ Národní úřad pro kybernetickou a informační bezpečnost
² Forsvarets Efterretningstjeneste
³ Välisluureamet
⁴ Sotilastiedustelu
⁵  Suojelupoliisi
⁶ Direction générale de la sécurité intérieure
⁷ Agence nationale de la sécurité des systèmes d’information
⁸ Agenzia Informazioni e Sicurezza Esterna
⁹ Agenzia Informazioni e Sicurezza Interna
¹⁰ Serviciul de Informații și Securitate al Republicii Moldova
¹¹ Agencja Wywiadu
¹² Służba Kontrwywiadu Wojskowego
¹³ Centro Nacional de Inteligencia
¹⁴ Nationellt Cybersäkerhetscenter
¹⁵ MITRE and ATT&CK are registered trademarks of The MITRE Corporation. MITRE D3FEND is a trademark of The MITRE Corporation.

Acknowledgements

The authoring agencies acknowledge the contributions to this advisory from Palo Alto Networks Unit 42 and Proofpoint.

Disclaimer of endorsement

The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Organizations have no obligation to respond or provide information back to the authoring organizations in response to this joint advisory. If, after reviewing the information provided, an organization decides to provide information to the authoring organizations, reporting must be consistent with all applicable laws and policies.

Purpose

This document was developed in furtherance of the authoring agencies’ cybersecurity missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.

Contact

Appendix A: MITRE ATT&CK tactics and techniques

See Table 9 through Table 19 for all the threat actor tactics and techniques referenced in this advisory.

Appendix B: MITRE D3FEND countermeasures

See Table 20 for a mapping of several of the cybersecurity countermeasures mentioned in this advisory.

Russian Government-Sponsored Activity Targets Poorly Configured and Vulnerable Devices Across Critical Sectors

Executive summary

Russian Federal Security Service (FSB) Center 16 cyber actors continue to exploit poorly configured and vulnerable networking devices worldwide, opportunistically compromising multiple critical infrastructure sector networks. This joint Cybersecurity Advisory (CSA) builds on FBI’s Russian Government Cyber Actors Targeting Networking Devices, Critical Infrastructure Public Service Announcement of the decade-plus FSB Center 16 cyber activity by providing additional tactics, techniques, and procedures (TTPs) to enable defenders to more fully understand and counter the threat. [1] 

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)
• Communications Security Establishment Canada’s (CSE’s) Canadian Centre for Cyber Security (Cyber Centre)
• 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)¹ 
• Danish Defence Intelligence Service (DDIS)² 
• Estonian Foreign Intelligence Service (EFIS)³ 
• Estonian Information System Authority (RIA)⁴
• Finnish Defence Intelligence (FDI)⁵
• Finnish Security and Intelligence Service (SUPO)⁶
• French National Cybersecurity Agency (ANSSI)⁷
• Italian External Intelligence and Security Agency (AISE)⁸ 
• Italian Internal Intelligence and Security Agency (AISI)⁹
• The Military Counterintelligence Service of Poland (SKW)¹⁰ 
• Sweden National Cyber Security Centre (NCSC-SE)¹¹ 

The authoring and co-sealing agencies strongly urge device owners and network defenders to take mitigation and remediation actions against Russian government-sponsored exploitation of vulnerable routers.

Download the PDF version of this report:

• Improve Router Hygiene to Protect Against Russian State-Sponsored Targeting (PDF, 816KB)

Cybersecurity industry tracking 

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

• Berserk Bear 
• Energetic Bear
• Crouching Yeti 
• Dragonfly
• Ghost Blizzard
• Static Tundra

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

Targeting details

Critical infrastructure sectors most at risk from the Russian Federal Security Service (FSB) Center 16 cyber actors’ targeting include:

• Communications,
• Defense Industrial Base,
• Energy,
• Financial Services,
• Government Services and Facilities, especially organizations at the state and local level, and
• Healthcare and Public Health.

Technical details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise¹² framework, version 19. See Appendix A for tables of the activity mapped to MITRE ATT&CK tactics and techniques. This advisory also uses MITRE DEFEND^TM version 1.4.0.

The Russian FSB Center 16 cyber actors primarily use scanning to identify poorly configured networking devices, primarily routers, for exploitation. The actors scan for Internet IP ranges with active Simple Network Management Protocol (SNMP) agents that accept common or default community strings for authentication [T1595.001, T1595.002]. These scans, run via proxies, consist of SNMP Set-Requests from a spoofed IP address [T1027] containing Object Identifiers (OIDs) that instruct the SNMP agent on poorly configured networking devices to [T1569, T1602.001, T1090]:

• Copy its configuration to a file, often called “config.bkp” or “output.txt” [T1003, T1602.002].
• Transfer the file, typically using Trivial File Transfer Protocol (TFTP), to an actor-controlled leased virtual private server (VPS) or compromised FTP server [T1583.003, T1090, T1071, T1048].

While SNMP scanning is the primary method the actors use to discover and exploit poorly configured networking devices, they occasionally exploit common vulnerabilities and exposures (CVEs) in Cisco devices, Cisco’s Smart Install (SMI) functionality, and web portals to manage network devices. The actors previously exploited at least the following CVEs [T1584.008, T1588.005, T1190, T1068]: 

• CVE-2018-0171
• CVE-2008-4128¹³

Many of these TTPs overlap with activity by other malicious cyber actors, such as Salt Typhoon. Even though this CSA focuses on Russian FSB Center 16 cyber activity, the mitigations below should detect and counter these and similar TTPs used by other actors.

Mitigation actions

The authoring agencies highly recommend network defenders implement the following mitigations to harden networks against this exploitation:

• Disable Cisco Smart Install on all devices [D3-ACH]. [2]
• Use SNMPv3 with “authPriv” configured to the most modern encryption standard that is supported by the device instead of SNMPv1 or SNMPv2 [D3-ACH]. [3]
  • Disable SNMPv1 and SNMPv2. These are legacy protocols and should no longer be needed on current devices. If they are necessary, change all community strings from defaults and only allow read-only community strings rather than read-write access.
  • SNMPv3 adds strong authentication and data encryption that are unavailable in SNMPv1 and v2. SNMPv3 replaces clear text shared passwords, known as community strings, with more securely encoded parameters, and authenticates and encrypts data [D3-MAN, D3-MENCR].
• Use strong, unique passwords for local accounts on network devices and configure credentials to be stored securely to prevent reuse of compromised passwords [D3-CH].
  • Cisco devices protect passwords in the configuration file using different hashing types. Use hashing type 8 for user credentials. Avoid using hashing type 0, 4, and 7 as they are insecure or store passwords in plaintext in the configuration file. [4]
  • Monitor for unusual credentials that do not conform to standard organizational naming conventions [D3-PM]. 
  •  Monitor for and alert on logins using local accounts. Local accounts should only be used in emergency situations when accounts supported by centralized authentication servers are unavailable. Centralized authentication to network devices should support multi-factor authentication where feasible. [3]
• Monitor and restrict access to SNMP OIDs using a Management Information Base (MIB) allow list [D3-ACH]. [5] Reference the vendor-specific MIB for the network devices and monitor OIDs for indications of reconnaissance or misconfiguration in logs or intrusion detection systems (IDS). IDS rules should be written for inbound SNMP Set-Requests that contain OIDs targeting sensitive device data [D3-PM].
  
  • Example OIDs include:
    • 1.3.6.1.4.1.9.9.96.1.1 (Cisco Config Copy)
    • 1.3.6.1.4.1.9.9.96.1.1.1.1.5 (Config Copy Server Address, value for this OID is where the configuration file is being sent to) 
• Restrict management protocols [D3-NTF].
  • Use Access Control Lists (ACLs) to only allow management protocols, such as SNMP, from management devices, preferably on an out-of-band network. [3]
  • On edge firewalls and devices deny all external communications on the following ports unless mission critical, with strict monitoring if blocking is not feasible:
    • User Datagram Protocol (UDP) port 69 (TFTP) 
    • Transmission Control Protocol (TCP) port 4786 (SMI)
    • UDP ports 161 and 162 (SNMP)
    • TCP/UDP ports 10161 and 10162 (SNMPv3)
• Update network device software and firmware images, especially to patch known vulnerabilities, and upgrade end-of-life devices to supported ones. 
  
  • Use an attack surface management service to identify and secure Internet-facing systems with weak configurations and known vulnerabilities [D3-NVA].
    • U.S.-based federal, state, local, tribal, and territorial governments and U.S. critical infrastructure organiztions should consider signing up for CISA’s no-cost Cyber Hygiene services.
    • U.S. Defense Industrial Base organizations should consider signing up for NSA’s DIB Cybersecurity Services.

Resources

United States:

• Russia Threat Overview and Advisories
• Network Infrastructure Security Guide

Canada:

• Routers cyber security best practices (ITSAP.80.019)
• Security considerations for edge devices (ITSM.80.101)
• Guidance on securely configuring network protocols (ITSP.40.062)
• Baseline security requirements for network security zones (ITSP.80.022)
• Top 10 IT security actions to protect Internet-connected networks and information (ITSM.10.089)

Works cited

[1] FBI. Russian Government Cyber Actors Targeting Networking Devices, Critical Infrastructure. Alert Number: I-082025-PSA. 2025. https://www.ic3.gov/PSA/2025/PSA250820

[2] NSA. Cisco Smart Install Protocol Misuse. 2017. https://media.defense.gov/2019/Jul/16/2002157833/-1/-1/0/CSA-CISCO-SMART-INSTALL-PROTOCOL-MISUSE.PDF

[3] NSA. Network Infrastructure Security Guide. 2023. https://media.defense.gov/2022/Jun/15/2003018261/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDE_20220615.PDF

[4] NSA. Cybersecurity Information Sheet Cisco Password Types: Best Practices. 2022. https://media.defense.gov/2022/Feb/17/2002940795/-1/-1/0/CSI_CISCO_PASSWORD_TYPES_BEST_PRACTICES_20220217.PDF

[5] NSA. Cybersecurity Information Sheet: Reducing the Risk of Simple Network Management Protocol (SNMP) Abuse. 2026. https://media.defense.gov/2026/Jul/09/2003959459/-1/-1/0/CSI_REDUCING_RISK_OF_SNMP_ABUSE.PDF

Footnotes

¹  Národní úřad pro kybernetickou a informační bezpečnost

²  Forsvarets Efterretningstjeneste

³ Välisluureamet

⁴ Riigi Infosüsteem Amet

⁵ Sotilastiedustelu

⁶ Suojelupoliisi

⁷ Agence nationale de la sécurité des systèmes d’information

⁸ Agenzia Informazioni e Sicurezza Esterna

⁹ Agenzia Informazioni e Sicurezza Interna

¹⁰ Służba Kontrwywiadu Wojskowego

¹¹ Nationellt Cybersäkerhetscenter

¹² MITRE and ATT&CK are registered trademarks of The MITRE Corporation. MITRE DEFEND is a trademark of the MITRE Corporation.

¹³ CVE-2008-4128 only affects end-of-life Cisco devices.

Disclaimer of Endorsement

The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Purpose

This document was developed in furtherance of the authoring agencies’ cybersecurity missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.

Contact

United States organizations

• National Security Agency (NSA)
  • Cybersecurity Report Feedback: CybersecurityReports@nsa.gov 
  • Defense Industrial Base Inquiries and Cybersecurity Services: DIB_Defense@cyber.nsa.gov 
  • Media Inquiries / Press Desk: NSA Media Relations: 443-634-0721, MediaRelations@nsa.gov
• Cybersecurity and Infrastructure Security Agency (CISA) and Federal Bureau of Investigation (FBI)
  •  U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA via the agency’s Incident Reporting System, its 24/7 Operations Center (report@cisa.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 user for the activity; the name of the submitting company or organization; and a designated point of contact. 
• United States Department of Defense Cyber Crime Center (DC3)  
  • Defense Industrial Base Inquiries and Cybersecurity Services: DC3.DCISE@us.af.mil 
  • Defense Industrial Base mandatory cyber incident reporting as required by 10 U.S. Code Sections 391 and 393 and Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012 is submitted at https://dibnet.dod.mil.
  •  Media Inquiries / Press Desk: DC3.Information@us.af.mil

Australian organizations

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

Canadian organizations

• The Canadian Centre for Cyber Security (Cyber Centre), part of the Communications Security Establishment, encourages Canadian organizations to report cyber incidents and to strengthen the security of their networking devices. 
  • Report an incident or suspicious activity to the Cyber Centre by email at contact@cyber.gc.ca, online via the reporting tool Report a cyber incident - Canadian Centre for Cyber Security or by phone at 1-833-CYBER-88 (1-833-292-3788).

New Zealand organizations

• New Zealand National Cyber Security Centre (NCSC-NZ): info@ncsc.govt.nz

United Kingdom organizations

• Report significant cyber security incidents to ncsc.gov.uk/report-an-incident (monitored 24/7)

Estonia organizations

• Estonian Foreign Intelligence Service (EFIS): info@valisluureamet.ee

Finnish organizations

• Finnish Security and Intelligence Service: supo.fi/en/contact

French organizations

• French organizations are encouraged to report suspicious activity or incident related information found in this advisory by contacting ANSSI/CERT-FR at: cert-fr@ssi.gouv.fr or by phone at: 3218 or +33 9 70 83 32 18.

Italian Organizations

• Italian External Intelligence and Security Agency (AISE): 
  • Visit https://www.sicurezzanazionale.gov.it/ 
• Italian Internal Intelligence and Security Agency (AISI): 
  • Visit https://www.sicurezzanazionale.gov.it/ 

Appendix A: MITRE ATT&CK tactics and techniques

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

Table 1: Reconnaissance

Technique Title	ID	Use
Active Scanning: Scanning IP Blocks	T1595.001	Scan range of IP addresses
Active Scanning: Vulnerability Scanning	T1595.002	Scan victims for vulnerabilities that can be used during targeting

Table 2: Resource Development

Technique Title	ID	Use
Acquire Infrastructure: Virtual Private Servers	T1583.003	Leverage VPS as infrastructure
Compromise Infrastructure: Network Devices	T1584.008	Compromise intermediate routers
Obtain Capabilities: Exploits	T1588.005	Use publicly available code to exploit vulnerable devices

Table 3: Initial Access

Technique Title	ID	Use
Exploit Public-Facing Application	T1190	Exploit publicly known CVEs
Proxy	T1090	Use a connection proxy to direct network traffic

Table 4: Execution

Technique Title	ID	Use
System Services	T1569	Executing commands via SNMP

Table 5: Privilege Escalation

Technique Title	ID	Use
Exploitation for Privilege Escalation	T1068	Exploit publicly known CVEs for escalated privileges

Table 6: Stealth

Technique Title	ID	Use
Obfuscated Files or Information	T1027	Obfuscate source IP addresses in system logs, as actions may be recorded as originating from local IP addresses

Table 7: Credential Access

Technique Title	ID	Use
OS Credential Dumping	T1003	Collect router configuration with weak Cisco Type 7 passwords and Type 0

Table 8: Collection

Technique Title	ID	Use
Data from Configuration Repository: SNMP (MIB Dump)	T1602.001	Target MIB to collect network information via SNMP
Data from Configuration Repository: Network Device Configuration Dump	T1602.002	Acquire credentials by collecting network device configurations

Table 9: Command and Control

Technique Title	ID	Use
Proxy	T1090	Use VPS for C2
Application Layer Protocol	T1071	Open and expose a variety of different services, including TFTP and FTP

Table 10: Exfiltration

Technique Title	ID	Use
Exfiltration Over Alternative Protocol	T1048	Exfiltrating over a different protocol than that of the existing command and control channel.

Appendix B: MITRE D3FEND countermeasures

See Table 11 for a mapping of several of the cybersecurity countermeasures mentioned in this advisory.

Table 11: MITRE D3FEND Countermeasures

Countermeasure Title	ID	Description
Application Configuration Hardening	D3-ACH	Use SNMPv3 and disable SNMPv1 and SNMPv2.  Use SNMP allowlisting to restrict access to OIDs and MIBs.  Disable Cisco Smart Install.
Message Authentication	D3-MAN	Use SNMPv3 with strong authentication.
Message Encryption	D3-MENCR	Use SNMPv3 to encrypt payloads.
Credential Hardening	D3-CH	Use strong, unique passwords and store them securely.
Platform Monitoring	D3-PM	Monitor for unusual credentials.  Monitor SNMP Set-Requests for OIDs targeting sensitive device data.
Network Traffic Filtering	D3-NTF	Use ACLs to only allow management protocols from management devices.  Block TFTP, SMI, and SNMP at edge firewalls.
Network Vulnerability Assessment	D3-NVA	Use an attack surface management service.

Advisory at a Glance

Title	Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure
Original Publication	April 7, 2026
Last Update	July 22, 2026
Executive Summary	The authoring agencies urgently warn U.S. organizations of ongoing Iranian-affiliated cyber targeting of internet-connected operational technology (OT) devices, including programmable logic controllers (PLCs). These actions disrupted PLCs across several U.S. critical infrastructure sectors through malicious project file interactions and manipulation of data on human machine interface (HMI) and supervisory control and data acquisition (SCADA) displays, resulting in operational disruption and financial loss.
Last Update Description	This update adds new guidance on detecting malicious changes in reusable code modules exploited within Rockwell Automation PLC programs. It also expands scope to include observed targeting of Schneider Electric, Siemens, and potentially other branded/manufactured PLCs, emphasizing the importance of restricting direct internet access and providing best practices for secure deployment.
Affected Products	Potentially all internet exposed PLCs, including Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and other branded/manufactured PLCs.
Key Actions	Install PLCs consistent with manufacturers' guidelines and security best practices. Remove PLCs from direct internet exposure via secure gateway and firewall; work with IT/OT team members and/or integrators to perform this action. Query available logs for the provided indicators of compromise (IOCs) and check available logs for suspicious traffic on the ports associated with OT devices, including 44818, 2222, 102, and 502, especially traffic originating from foreign hosting providers. For Rockwell Automation devices, place the physical mode switch on the controller into run position. If you suspect your organization was targeted, including against other branded PLC devices, contact the authoring agencies and PLC manufacturer for guidance.
Indicators of Compromise	For a downloadable copy of July 22, 2026 IOCs, see: AA26-097A STIX XML (July 2026) (29 KB) AA26-097A STIX JSON (July 2026) (30 KB) For a downloadable copy of historical April 7, 2026 IOCs, see: AA26-097A STIX XML (36 KB) AA26-097A STIX JSON (12 KB)
Intended Audience	Organizations: Critical Infrastructure Sectors: Government Services and Facilities, Water and Wastewater Systems (WWS), and Energy  Roles: Integrators, asset owners, defensive cybersecurity analysts, OT cybersecurity engineers, cybersecurity architects, secure systems developer

Introduction

Note: This advisory was originally published on April 7, 2026, to provide tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) related to ongoing cyber exploitation of internet-connected operational technology (OT) devices by Iranian-affiliated advanced persistent threat (APT) actors. The authoring agencies updated this advisory on July 22, 2026, to add new guidance on detecting malicious changes in reusable code modules leveraged within Rockwell Automation PLC programs. It also expands the manufacturer scope to include observed targeting of Schneider Electric, Siemens, and potentially other branded/manufactured PLCs, emphasizing the importance of restricting direct internet access and providing best practice resources for secure deployment.

The Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Environmental Protection Agency (EPA), Department of Energy (DOE), United States Cyber Command – Cyber National Mission Force (CNMF), and Department of the Treasury (Treasury) (hereafter referred to as the “authoring agencies”) are urgently warning U.S. organizations of ongoing cyber exploitation of internet-connected OT devices—including PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other manufactured PLCs—across multiple U.S. critical infrastructure sectors. As a result of this activity, organizations from multiple U.S. critical infrastructure sectors experienced disruptions through malicious interactions with PLC project files¹ and the manipulation of data displayed on human machine interface (HMI) and supervisory control and data acquisition (SCADA) displays. In a few cases, this activity caused operational disruption and financial loss.

The authoring agencies assess a group of Iranian-affiliated APT actors is conducting this activity to cause disruptive effects within the United States. The group targeted devices spanning multiple U.S. critical infrastructure sectors, including Government Services and Facilities (to include local municipalities), Water and Wastewater Systems (WWS), and Energy Sectors. The authoring agencies previously reported on similar activity targeting PLCs by CyberAv3ngers (aka Shahid Kaveh Group)—a cyber threat actor affiliated with Iran’s Islamic Revolutionary Guard Corps (IRGC) Cyber Electronic Command (CEC).

Due to the widespread use of these PLCs, and the potential for additional targeting of other branded OT devices across critical infrastructure, the authoring agencies recommend U.S. organizations urgently review the TTPs and IOCs in this advisory for indications of current or historical activity on their networks, and apply the recommendations listed in the Mitigations section of this advisory to reduce the risk of compromise.

If owners and operators discover an affected internet-accessible device in their environment, additional technical measures may be necessary to evaluate the risk of compromise. Please engage your cyber incident response plans and contact the authoring agencies and applicable vendors through existing support channels available to customers and integrators (see Contact Information) to receive support, mitigation, and investigation assistance.

For more information on Iranian malicious cyber activity, see CISA’s Iran Threat Overview and Advisories webpage and the FBI’s Iran Threat and Iran Cyber Threat Overview webpages.

Download the PDF version of this report:

(New, July 22, 2026) For a downloadable copy of July 22, 2026 IOCs, see:

• AA26-097A STIX XML (XML, 29 KB)
• AA26-097A STIX JSON (JSON, 30 KB)

For a downloadable copy of historical April 7, 2026 IOCs, see:

Background Information

Similar Historical Activity Targeting Programmable Logic Controllers

During a similar campaign beginning in November 2023, the IRGC CEC-affiliated cyber threat actors known as "CyberAv3ngers” targeted U.S.-based PLCs and HMIs, causing disruptive effects. Private industry and open sources also refer to this group as Hydro Kitten, Storm-0784, APT Iran, Bauxite, Mr. Soul, Soldiers of Solomon, UNC5691, and the Shahid Kaveh Group. These attacks compromised at least 75 devices, targeting U.S.-based Unitronics PLC devices with an HMI used across multiple critical infrastructure sectors, including the WWS. APT actors developed and deployed custom ladder logic code to these devices, replacing the valid ladder logic with malicious code that continues to be observed to date.

For more information on this group’s activity, see the joint Cybersecurity Advisory IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities.

Ongoing Threat Actor Activity Against U.S.-Based Programmable Logic Controllers

The FBI observed Iranian-affiliated APT actors targeting internet-exposed PLCs with the intent to cause disruptions—including maliciously interacting with project files, and manipulating data displayed on HMI and SCADA displays—to U.S. critical infrastructure organizations. Iranian-affiliated APT targeting campaigns against U.S. critical infrastructure have recently escalated, likely in response to hostilities between Iran, and the United States and Israel.

(New, July 22, 2026) At one U.S. victim, the FBI observed the APT actors download a malicious project file to a targeted PLC using configuration software. Analysis indicated the project file retained ladder logic for downstream function but added logic that overrode specific instruction sets responsible for maintaining safe operating parameters in the victim’s environment.

Since at least March 2026, the authoring agencies identified (through engagements with victim organizations) an Iranian-affiliated APT group disrupted the function of PLCs. Organizations across several U.S. critical infrastructure sectors (including Government Services and Facilities, WWS, and Energy Sectors) deployed these PLCs within a wide variety of industrial automation processes. Some of the victims experienced operational disruption and financial loss.

Technical Details

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

Initial Access

(Updated, July 22, 2026) The authoring agencies observed Iranian-affiliated APT actors using several foreign-based IP addresses to access internet-facing PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other manufactured PLCs [T0883]. The actors used leased, third-party hosted infrastructure and manufacturers’ PLC programming software to connect to misconfigured victim PLCs. Inbound malicious traffic has been observed targeting PLC devices on the following ports: 44818, 2222, 102, and 502, as well as targeting modems on port 22. Targeted devices include:

• Rockwell Automation: CompactLogix and Micro850 PLCs
• Schneider Electric: BMX P34/Modicon M340 PLCs
• Siemens: S7-1200 series PLCs

Command and Control

(Updated, July 22, 2026) The targeting of ports [T0885] associated with other OT vendors’ protocols suggests these actors are opportunistically targeting devices manufactured by companies other than Rockwell Automation/Allen-Bradley, including Schneider Electric and Siemens. In one reported instance, the actors utilized Dropbear Secure Shell (SSH) software on victim modems to enable them to gain remote access through port 22 [T1219].

Exfiltration

(New, July 22, 2026) The authoring agencies observed Iranian-affiliated APT actors using configuration software—such as Rockwell Automation’s Studio 5000 Logix Designer, Schneider Electric’s EcoStruxure Control Expert, and Siemens’ Totally Integrated Automation (TIA) Portal—on leased, third-party hosted infrastructure to exfiltrate device project files from PLC devices to threat-actor-controlled infrastructure [T1041].

Impact

(Updated, July 22, 2026) After the actors extracted device project files, the FBI and CISA identified the modification and deletion of project file logic, to include Add-On Instructions (AOIs) and data manipulation on HMI and SCADA displays [T1565]. Additionally, the changes disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators of the anomalies.

Note: An AOI is analogous to a “Function Block” or “User Defined Function Block” used in other PLC vendor programs.

Indicators of Compromise

See Table 1 and Table 2 for recent IP addresses used by the Iranian-affiliated APT actors to communicate with PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, and Siemens in the United States.

Disclaimer: The FBI observed the threat actors using the IP addresses listed below in the specified time frames. This data is being provided for customers to query against logs for indications of historical targeting by the Iranian-affiliated APT actors. The authoring agencies recommend organizations investigate or vet these IP addresses prior to taking action, such as blocking.

Table 1. Indicators of Compromise (New, July 22, 2026)

Indicator	Beginning of Actor Association	End of Actor Association
185.82.73[.]175	September 2025	February 2026
141.11.164[.]153	January 2026	June 2026
175.110.121[.]42	February 2026	March 2026
175.110.121[.]39	February 2026	March 2026
175.110.121[.]41	February 2026	March 2026
175.110.121[.]107	February 2026	February 2026
192.142.54[.]79	May 2026	June 2026
84.200.205[.]165	May 2026	June 2026
185.225.17[.]225	June 2026	July 2026
79.133.46[.]209	July 2026	July 2026
88.80.150[.]199	July 2026	July 2026
88.80.150[.]200	July 2026	July 2026
88.80.150[.]202	July 2026	July 2026

Table 2. Indicators of Compromise 

Indicator	Beginning of Actor Association	End of Actor Association
185.82.73[.]162	January 2025	March 2026
185.82.73[.]164	January 2025	March 2026
185.82.73[.]165	January 2025	March 2026
185.82.73[.]167	January 2025	March 2026
185.82.73[.]168	January 2025	March 2026
185.82.73[.]170	January 2025	March 2026
185.82.73[.]171	January 2025	March 2026
135.136.1[.]133	March 2026	March 2026

MITRE ATT&CK Tactics and Techniques

See Table 3 to Table 6 for all referenced threat actor tactics and techniques in this advisory. The authoring agencies recommend organizations review historical TTPs for similar Iranian-affiliated cyber actor activity in IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities. 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 3. Initial Access

Technique Title	ID	Use
Internet Accessible Device	T0883	The actors accessed and interacted with publicly exposed, internet-accessible PLCs that lacked sufficient network and/or hardening security controls.

 

Table 4. Command and Control

Technique Title	ID	Use
Commonly Used Port	T0885	The actors leveraged commonly used OT ports to communicate with PLCs.
Remote Access Tools	T1219	The actors deployed Dropbear SSH software on victim modems to enable them to gain remote access through port 22.

Table 5. Exfiltration (New, July 22, 2026)

Technique Title	ID	Use
Exfiltration Over C2 Channel	T1041	The actors used remote, third-party hosted infrastructure as a C2 channel to transfer device project files out of victim environments.

Table 6. Impact

Technique Title	ID	Use
Data Manipulation	T1565	The actors maliciously interacted with project files, including modifying and deleting project file logic, and altered data displayed on HMI and SCADA displays.

Mitigations

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

Network Defenders

The cyber threat actors accessed PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other branded/manufactured PLCs to cause disruptions to victim systems. To safeguard against this threat and threats to other types of PLCs, the authoring agencies urge organizations to consider the following mitigations.

(Updated, July 22, 2026) In addition to contacting the authoring agencies, organizations and integrators operating PLCs from the manufacturers mentioned in this advisory should review the previously issued guidance to strengthen the security of their OT deployments:

• Rockwell Automation: Contact the Rockwell Automation Product Security Incident Response Team (PSIRT) at PSIRT@rockwellautomation.com for questions regarding this guidance, or to report cyber incidents related to Rockwell Automation products.
  
  • Refer to Rockwell Automation Security Advisory SD1771 for recommended PLC hardening measures and configuration guidance.
• Schneider Electric: Contact the Schneider Electric Corporate Product Cyber Emergency Response Team (CPCERT) at cpcert@se.com for questions regarding this guidance, or to report cyber incidents related to Schneider Electric products.
  
  • Refer to Schneider Electric’s Recommended Cybersecurity Best Practices and Cybersecurity User Guide for Modicon Controller Platform for guidance on securing and configuring PLCs.
• Siemens: Contact Siemens ProductCERT at productcert@siemens.com for questions regarding this guidance, or to report cyber incidents and vulnerabilities related to Siemens products.
  
  • Refer to Siemens Security Bulletin 104599 for a list of security measures to harden PLCs and in-depth configuration guides.
  • Siemens users should review the Cybersecurity for Industry Operational Guidelines and implement defense-in-depth controls within their automation systems.

Immediate steps to prevent the attack:

• Disconnect the PLC from the public-facing internet [CPG 3.S]. Follow the joint guidance Secure connectivity principles for OT to safely allow remote access. Specifically, “remove inbound port exposure,” so the OT system is never directly exposed to the internet or external networks, and to ensure all access is mediated, monitored, and controlled. Do this through a secure gateway (jump host) that brokers the connection.
  
  • Ensure cellular modems, used for remote field connectivity and access, are secured with strong authentication and updated.
  • Enable logs for connected modems and regularly review for suspicious activity to detect intrusions and improve incident response speed.
  • (New, July 22, 2026) To mitigate unauthorized access to OT via cellular modems, organizations should consider implementing isolated architectures, such as private Access Point Name (APN), 5G Public Network Integrated Non-Public Network (PNI-NPN), cellular Software-Defined Wide Area Network (SD-WAN), Zero Trust Network Access (ZTNA), or a site-to-site virtual private network (VPN).
• (New, July 22, 2026) Strictly control network access to PLC devices.
  
  • Configure firewall rules or access control list (ACL) security features on PLCs or programmable controllers to allow only authorized communications between expected control system devices. Block access from unauthorized or threat actor-controlled IP addresses, such as those associated with hosting providers.
• For controllers with a physical mode switch, place the physical mode switch into run position to prevent remote modification. Devices should only be in the program or remote position when updating or downloading software online and immediately switched back to the run position when complete. (See Rockwell Automation’s² System Security Design Guidelines for manufacturer’s instructions.)
  
  • (New, July 22, 2026) Prior to switching the device to run mode, review and validate project files, as changing modes will lock in the current project file downloaded to the device.
• For devices that allow software key switching, enable programming protection in PLC configuration software (S7 TIA Portal) to limit who can modify PLCs remotely. (See Siemens’ Cybersecurity for Industry Operational Guidelines for the manufacturer’s instructions.)

Follow-up steps to strengthen security posture:

• (New, July 22, 2026) Review project files running on PLCs for unauthorized changes. Use vendor-provided integrity checking tools and visually compare the running program to known good logic. Ensure reusable logic and input/output configurations are valid. For Rockwell Automation PLCs listed in the Customer Guidance to Disconnect Devices from the Internet, check the AOIs for any anomalous modifications.
  
  • If restoring from backups, verify the backup does not contain malicious logic before deployment.
  • Review logs and configurations on all connected devices, including modems, HMIs, and workstations, to assess potential lateral movement by threat actors. If it appears the actors connected to additional devices, reimage these devices to remove any potential malicious changes or access tools.
• (New, July 22, 2026) Ensure device passwords are changed from their default and are configured to use complex, unique combinations of letters, numbers, and symbols that are not easily guessable. Implementing robust password practices remains a critical security measure that can help prevent unauthorized access and strengthen the overall security posture of OT devices.
• (New, July 22, 2026) Take defensive measures to minimize the risk of exploitation. Conduct comprehensive impact analysis and risk assessments prior to deploying defensive measures.
• Create and test strong backups of the logic and configurations of PLCs. Store backup files offline and secure the physical removal media to enable fast recovery.
• Implement multifactor authentication (MFA) [CPG 3.F] for access to the OT network from an external network.
• If remote access is required, implement a network proxy, gateway, firewall, and/or VPN in front of the PLC to control network access.
  
  • A VPN or gateway device can enable MFA for remote access even if the PLC does not support MFA. Implement security rules on these higher-level network security mechanisms to prevent the type of repeated and sustained login attempts seen during a brute force attack. When possible, implement a device control list for workstations sending messages or connecting to OT components.
  • Use the device control list to monitor for logon activity for unexpected or unusual access to devices from the internet.
• Keep PLC devices updated with the latest software patches issued by the manufacturer. Use established downtime windows to install patches. Known Exploited Vulnerabilities may need to be prioritized outside a downtime window.
• Configure external and internal firewalls to block traffic using common ports associated with network protocols that are unnecessary for the particular network segment.
• Disable any unused authentication methods, logic, or features, such as default authentication keys and passwords, as well as unused or needed services such as Teletype Network (Telnet), File Transfer Protocol (FTP), Remote Desktop Protocol (RDP), Virtual Network Computing (VNC), and web services.
• Monitor asset management systems for device configuration changes, which can be used to understand expected parameter settings.
• Monitor the content of network traffic for the following:
  
  • Unusual logins to internet-connected devices or unexpected protocols to/from the internet. 
  • Functions of industrial control systems management protocols that change an asset’s operating mode or modify programs.
• (New, July 22, 2026) Ensure service providers are informed of active threats targeting internet-connected PLC devices. Owners and operators should communicate directly with service providers to address risks, especially when remote monitoring or maintenance is involved. Some service providers may rely on internet connectivity essential to monitor and maintain OT/ICS operations but may not be fully aware of active threats.

In addition, the authoring agencies recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques, as well as reduce the impact and risk of compromise by cyber threat actors:

• Reduce risk exposure. CISA offers a range of services at no cost, including scanning and testing, to help organizations reduce exposure to threats via mitigating attack vectors. CISA’s Cyber Hygiene Services can help provide additional review of organizations’ internet-accessible assets. 

Device Manufacturers

Note: The following guidance is general in nature and not specific to any OT vendor. Some of the features, settings, and practices may already be offered by certain vendors. The inclusion of this guidance should not be interpreted as an assertion that vendors referenced do not offer such security features. Also, this advisory is not highlighting a new vulnerability in the identified products, but instead discusses opportunistic targeting. Device manufacturers can make opportunistic attacks more difficult at scale by encouraging more secure behavior by default and in operations, as discussed below. 

Although critical infrastructure organizations using PLC devices can take steps to mitigate the risks, it is ultimately the responsibility of the device manufacturer to build products secured by design and default. The authoring agencies urge device manufacturers to take ownership of their customers’ security outcomes by following the principles in the joint guide Secure by Demand: Priority Considerations for OT Owners and Operators when Selecting Digital Products, primarily:

• Change the manufacturers’ default settings to prevent exposing administrative interfaces to the internet.
• Do not charge additional fees for basic security features needed to operate the product securely.
• Support MFA, including via phishing-resistant methods.

By using secure by design tactics, software manufacturers can make 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 common misconfigurations and guidance on reducing their prevalence, see joint advisory NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations. For more information on secure by design, see CISA’s Secure by Design webpage and joint guide.

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 3 to Table 6).
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 ATT&CK techniques identified in this advisory.

Resources

• Authoring Agencies: IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities
• CISA: Bulletproof Defense: Mitigating Risks From Bulletproof Hosting Providers
• EPA: Cybersecurity for the Water Sector
• CISA: Water and Wastewater Cybersecurity
• CISA: Exploitation of Unitronics PLCs used in Water and Wastewater Systems
• CISA: Iran Threat Overview and Advisories
• FBI: The Iran Threat and Cyber Threat Overview: Iran
• CISA, MITRE: Best Practices for MITRE ATT&CK Mapping
• CISA: Decider Tool
• CISA: Cross-Sector Cybersecurity Performance Goals 2.0
• CISA: No-Cost Cybersecurity Services and Tools
• CISA: Secure by Demand: Priority Considerations for OT Owners and Operators when Selecting Digital Products
• NSA, CISA: NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations
• CISA: Secure by Design
• FBI, CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• United Kingdom National Cyber Security Centre: Secure connectivity principles for operational technology

Contact Information

U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA, the 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). File a claim with FBI’s Internet Crime Complaint Center (IC3) or contact 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; and
  • Name of the submitting company or organization, and a designated point of contact.
• For NSA cybersecurity guidance inquiries, contact CybersecurityReports@nsa.gov.
• Entities required to report incidents to DOE should follow established reporting requirements, as appropriate. For other energy sector inquiries, contact EnergySRMA@hq.doe.gov.
• Contact the Rockwell Automation PSIRT for questions regarding their guidance or for reporting cyber incidents related to Rockwell Automation products at PSIRT@rockwellautomation.com.
• Contact the Schneider Electric CPCERT at cpcert@se.com for questions regarding this guidance, or to report cyber incidents related to Schneider Electric products.
• Contact Siemens ProductCERT for up-to-date information about the security of Siemens products or to report cybersecurity vulnerabilities at productcert@siemens.com. For support with increasing the security of installed Siemens PLCs, contact Siemens Industrial Cybersecurity Services at services.automation@siemens.com. See Siemens ProductCERT and Siemens CERT for more information.

Disclaimer

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

Version History

April 7, 2026: Initial version.

July 22, 2026: Update includes new guidance on detecting malicious activity, expanded scope of observed targeting, and best practices for secure PLCs deployment.

Notes

¹Project file refers to the software file that contains ladder logic and configuration settings. On Rockwell Automation devices, it is referred to as an .ACD file.

² See CompactLogix 5370 Controllers (Chapter 5: “Select the Operating Mode of the Controller”) for more information on functions available for the switch.

This report is a collaborative research effort by the cyber security authorities of five nations: Australia, Canada, New Zealand, the United Kingdom, and the United States.[1][2][3][4][5]

In it we highlight the use of five publicly available tools, which have been used for malicious purposes in recent cyber incidents around the world. The five tools are:

1. Remote Access Trojan: JBiFrost
2. Webshell: China Chopper
3. Credential Stealer: Mimikatz
4. Lateral Movement Framework: PowerShell Empire
5. C2 Obfuscation and Exfiltration: HUC Packet Transmitter

To aid the work of network defenders and systems administrators, we also provide advice on limiting the effectiveness of these tools and detecting their use on a network.

The individual tools we cover in this report are limited examples of the types of tools used by threat actors. You should not consider this an exhaustive list when planning your network defense.

Tools and techniques for exploiting networks and the data they hold are by no means the preserve of nation states or criminals on the dark web. Today, malicious tools with a variety of functions are widely and freely available for use by everyone from skilled penetration testers, hostile state actors and organized criminals, to amateur cyber criminals.

The tools in this Activity Alert have been used to compromise information across a wide range of critical sectors, including health, finance, government, and defense. Their widespread availability presents a challenge for network defense and threat-actor attribution.

Experience from all our countries makes it clear that, while cyber threat actors continue to develop their capabilities, they still make use of established tools and techniques. Even the most sophisticated threat actor groups use common, publicly available tools to achieve their objectives.

Whatever these objectives may be, initial compromises of victim systems are often established through exploitation of common security weaknesses. Abuse of unpatched software vulnerabilities or poorly configured systems are common ways for a threat actor to gain access. The tools detailed in this Activity Alert come into play once a compromise has been achieved, enabling attackers to further their objectives within the victim’s systems.

How to Use This Report

The tools detailed in this Activity Alert fall into five categories: Remote Access Trojans (RATs), webshells, credential stealers, lateral movement frameworks, and command and control (C2) obfuscators.

This Activity Alert provides an overview of the threat posed by each tool, along with insight into where and when it has been deployed by threat actors. Measures to aid detection and limit the effectiveness of each tool are also described.

The Activity Alert concludes with general advice for improving network defense practices.

Remote Access Trojan: JBiFrost

First observed in May 2015, the JBiFrost RAT is a variant of the Adwind RAT, with roots stretching back to the Frutas RAT from 2012.

A RAT is a program that, once installed on a victim’s machine, allows remote administrative control. In a malicious context, it can—among many other functions—be used to install backdoors and key loggers, take screen shots, and exfiltrate data.

Malicious RATs can be difficult to detect because they are normally designed not to appear in lists of running programs and can mimic the behavior of legitimate applications.

To prevent forensic analysis, RATs have been known to disable security measures (e.g., Task Manager) and network analysis tools (e.g., Wireshark) on the victim’s system.

In Use

JBiFrost RAT is typically employed by cyber criminals and low-skilled threat actors, but its capabilities could easily be adapted for use by state-sponsored threat actors.

Other RATs are widely used by Advanced Persistent Threat (APT) actor groups, such as Adwind RAT, against the aerospace and defense sector; or Quasar RAT, by APT10, against a broad range of sectors.

Threat actors have repeatedly compromised servers in our countries with the purpose of delivering malicious RATs to victims, either to gain remote access for further exploitation, or to steal valuable information such as banking credentials, intellectual property, or PII.

Capabilities

JBiFrost RAT is Java-based, cross-platform, and multifunctional. It poses a threat to several different operating systems, including Windows, Linux, MAC OS X, and Android.

JBiFrost RAT allows threat actors to pivot and move laterally across a network or install additional malicious software. It is primarily delivered through emails as an attachment, usually an invoice notice, request for quotation, remittance notice, shipment notification, payment notice, or with a link to a file hosting service.

Past infections have exfiltrated intellectual property, banking credentials, and personally identifiable information (PII). Machines infected with JBiFrost RAT can also be used in botnets to carry out distributed denial-of-service attacks.

Examples

Since early 2018, we have observed an increase in JBiFrost RAT being used in targeted attacks against critical national infrastructure owners and their supply chain operators. There has also been an increase in the RAT’s hosting on infrastructure located in our countries.

In early 2017, Adwind RAT was deployed via spoofed emails designed to look as if they originated from Society for Worldwide Interbank Financial Telecommunication, or SWIFT, network services.

Many other publicly available RATs, including variations of Gh0st RAT, have also been observed in use against a range of victims worldwide.

Detection and Protection

Some possible indications of a JBiFrost RAT infection can include, but are not limited to:

• Inability to restart the computer in safe mode,
• Inability to open the Windows Registry Editor or Task Manager,
• Significant increase in disk activity and/or network traffic,
• Connection attempts to known malicious Internet Protocol (IP) addresses, and
• Creation of new files and directories with obfuscated or random names.

Protection is best afforded by ensuring systems and installed applications are all fully patched and updated. The use of a modern antivirus program with automatic definition updates and regular system scans will also help ensure that most of the latest variants are stopped in their tracks. You should ensure that your organization is able to collect antivirus detections centrally across its estate and investigate RAT detections efficiently.

Strict application allow listing is recommended to prevent infections from occurring.

The initial infection mechanism for RATs, including JBiFrost RAT, can be via phishing emails. You can help prevent JBiFrost RAT infections by stopping these phishing emails from reaching your users, helping users to identify and report phishing emails, and implementing security controls so that the malicious email does not compromise your device. The United Kingdom National Cyber Security Centre (UK NCSC) has published phishing guidance.

Webshell: China Chopper

China Chopper is a publicly available, well-documented webshell that has been in widespread use since 2012.

Webshells are malicious scripts that are uploaded to a target host after an initial compromise and grant a threat actor remote administrative capability.

Once this access is established, webshells can also be used to pivot to additional hosts within a network.

In Use

China Chopper is extensively used by threat actors to remotely access compromised web servers, where it provides file and directory management, along with access to a virtual terminal on the compromised device.

As China Chopper is just 4 KB in size and has an easily modifiable payload, detection and mitigation are difficult for network defenders.

Capabilities

China Chopper has two main components: the China Chopper client-side, which is run by the attacker, and the China Chopper server, which is installed on the victim web server but is also attacker-controlled.

The webshell client can issue terminal commands and manage files on the victim server. Its MD5 hash is publicly available (originally posted on hxxp://www.maicaidao.com).

The MD5 hash of the web client is shown in table 1 below.

Table 1: China Chopper webshell client MD5 hash

Webshell Client	MD5 Hash
caidao.exe	5001ef50c7e869253a7c152a638eab8a

The webshell server is uploaded in plain text and can easily be changed by the attacker. This makes it harder to define a specific hash that can identify adversary activity. In summer 2018, threat actors were observed targeting public-facing web servers that were vulnerable to CVE-2017-3066. The activity was related to a vulnerability in the web application development platform Adobe ColdFusion, which enabled remote code execution.

China Chopper was intended as the second-stage payload, delivered once servers had been compromised, allowing the threat actor remote access to the victim host. After successful exploitation of a vulnerability on the victim machine, the text-based China Chopper is placed on the victim web server. Once uploaded, the webshell server can be accessed by the threat actor at any time using the client application. Once successfully connected, the threat actor proceeds to manipulate files and data on the web server.

China Chopper’s capabilities include uploading and downloading files to and from the victim using the file-retrieval tool wget to download files from the internet to the target; and editing, deleting, copying, renaming, and even changing the timestamp, of existing files.

Detection and protection

The most powerful defense against a webshell is to avoid the web server being compromised in the first place. Ensure that all the software running on public-facing web servers is up-to-date with security patches applied. Audit custom applications for common web vulnerabilities. [6]

One attribute of China Chopper is that every action generates a hypertext transfer protocol (HTTP) POST. This can be noisy and is easily spotted if investigated by a network defender.

While the China Chopper webshell server upload is plain text, commands issued by the client are Base64 encoded, although this is easily decodable.

The adoption of Transport Layer Security (TLS) by web servers has resulted in web server traffic becoming encrypted, making detection of China Chopper activity using network-based tools more challenging.

The most effective way to detect and mitigate China Chopper is on the host itself—specifically on public-facing web servers. There are simple ways to search for the presence of the web-shell using the command line on both Linux and Windows based operating systems. [7]

To detect webshells more broadly, network defenders should focus on spotting either suspicious process execution on web servers (e.g., Hypertext Preprocessor [PHP] binaries spawning processes) and out-of-pattern outbound network connections from web servers. Typically, web servers make predictable connections to an internal network. Changes in those patterns may indicate the presence of a web shell. You can manage network permissions to prevent web-server processes from writing to directories where PHP can be executed, or from modifying existing files.

We also recommend that you use web access logs as a source of monitoring, such as through traffic analytics. Unexpected pages or changes in traffic patterns can be early indicators.

Credential Stealer: Mimikatz

Developed in 2007, Mimikatz is mainly used by attackers to collect the credentials of other users, who are logged into a targeted Windows machine. It does this by accessing the credentials in memory within a Windows process called Local Security Authority Subsystem Service (LSASS).

These credentials, either in plain text, or in hashed form, can be reused to give access to other machines on a network.

Although it was not originally intended as a hacking tool, in recent years Mimikatz has been used by multiple actors for malicious purposes. Its use in compromises around the world has prompted organizations globally to re-evaluate their network defenses.

Mimikatz is typically used by threat actors once access has been gained to a host and the threat actor wishes to move throughout the internal network. Its use can significantly undermine poorly configured network security.

In Use

Mimikatz source code is publicly available, which means anyone can compile their own versions of the new tool and potentially develop new Mimikatz custom plug-ins and additional functionality.

Our cyber authorities have observed widespread use of Mimikatz among threat actors, including organized crime and state-sponsored groups.

Once a threat actor has gained local administrator privileges on a host, Mimikatz provides the ability to obtain the hashes and clear-text credentials of other users, enabling the threat actor to escalate privileges within a domain and perform many other post-exploitation and lateral movement tasks.

For this reason, Mimikatz has been bundled into other penetration testing and exploitation suites, such as PowerShell Empire and Metasploit.

Capabilities

Mimikatz is best known for its ability to retrieve clear text credentials and hashes from memory, but its full suite of capabilities is extensive.

The tool can obtain Local Area Network Manager and NT LAN Manager hashes, certificates, and long-term keys on Windows XP (2003) through Windows 8.1 (2012r2). In addition, it can perform pass-the-hash or pass-the-ticket tasks and build Kerberos “golden tickets.”

Many features of Mimikatz can be automated with scripts, such as PowerShell, allowing a threat actor to rapidly exploit and traverse a compromised network. Furthermore, when operating in memory through the freely available “Invoke-Mimikatz” PowerShell script, Mimikatz activity is very difficult to isolate and identify.

Examples

Mimikatz has been used across multiple incidents by a broad range of threat actors for several years. In 2011, it was used by unknown threat actors to obtain administrator credentials from the Dutch certificate authority, DigiNotar. The rapid loss of trust in DigiNotar led to the company filing for bankruptcy within a month of this compromise.

More recently, Mimikatz was used in conjunction with other malicious tools—in the NotPetya and BadRabbit ransomware attacks in 2017 to extract administrator credentials held on thousands of computers. These credentials were used to facilitate lateral movement and enabled the ransomware to propagate throughout networks, encrypting the hard drives of numerous systems where these credentials were valid.

In addition, a Microsoft research team identified use of Mimikatz during a sophisticated cyberattack targeting several high-profile technology and financial organizations. In combination with several other tools and exploited vulnerabilities, Mimikatz was used to dump and likely reuse system hashes.

Detection and Protection

Updating Windows will help reduce the information available to a threat actor from the Mimikatz tool, as Microsoft seeks to improve the protection offered in each new Windows version.

To prevent Mimikatz credential retrieval, network defenders should disable the storage of clear text passwords in LSASS memory. This is default behavior for Windows 8.1/Server 2012 R2 and later, but can be specified on older systems which have the relevant security patches installed.[8] Windows 10 and Windows Server 2016 systems can be protected by using newer security features, such as Credential Guard.

Credential Guard will be enabled by default if:

• The hardware meets Microsoft’s Windows Hardware Compatibility Program Specifications and Policies for Windows Server 2016 and Windows Server Semi-Annual Branch; and
• The server is not acting as a Domain Controller.

You should verify that your physical and virtualized servers meet Microsoft’s minimum requirements for each release of Windows 10 and Windows Server.

Password reuse across accounts, particularly administrator accounts, makes pass-the-hash attacks far simpler. You should set user policies within your organization that discourage password reuse, even across common level accounts on a network. The freely available Local Administrator Password Solution from Microsoft can allow easy management of local administrator passwords, preventing the need to set and store passwords manually.

Network administrators should monitor and respond to unusual or unauthorized account creation or authentication to prevent Kerberos ticket exploitation, or network persistence and lateral movement. For Windows, tools such as Microsoft Advanced Threat Analytics and Azure Advanced Threat Protection can help with this.

Network administrators should ensure that systems are patched and up-to-date. Numerous Mimikatz features are mitigated or significantly restricted by the latest system versions and updates. But no update is a perfect fix, as Mimikatz is continually evolving and new third-party modules are often developed.

Most up-to-date antivirus tools will detect and isolate non-customized Mimikatz use and should therefore be used to detect these instances. But threat actors can sometimes circumvent antivirus systems by running Mimikatz in memory, or by slightly modifying the original code of the tool. Wherever Mimikatz is detected, you should perform a rigorous investigation, as it almost certainly indicates a threat actor is actively present in the network, rather than an automated process at work.

Several of Mimikatz’s features rely on exploitation of administrator accounts. Therefore, you should ensure that administrator accounts are issued on an as-required basis only. Where administrative access is required, you should apply privileged access management principles.

Since Mimikatz can only capture the accounts of those users logged into a compromised machine, privileged users (e.g., domain administrators) should avoid logging into machines with their privileged credentials. Detailed information on securing Active Directory is available from Microsoft.[9]

Network defenders should audit the use of scripts, particularly PowerShell, and inspect logs to identify anomalies. This will aid in identifying Mimikatz or pass-the-hash abuse, as well as in providing some mitigation against attempts to bypass detection software.

Lateral Movement Framework: PowerShell Empire

PowerShell Empire is an example of a post-exploitation or lateral movement tool. It is designed to allow an attacker (or penetration tester) to move around a network after gaining initial access. Other examples of these tools include Cobalt Strike and Metasploit. PowerShell Empire can also be used to generate malicious documents and executables for social engineering access to networks.

The PowerShell Empire framework was designed as a legitimate penetration testing tool in 2015. PowerShell Empire acts as a framework for continued exploitation once a threat actor has gained access to a system.

The tool provides a threat actor with the ability to escalate privileges, harvest credentials, exfiltrate information, and move laterally across a network. These capabilities make it a powerful exploitation tool. Because it is built on a common legitimate application (PowerShell) and can operate almost entirely in memory, PowerShell Empire can be difficult to detect on a network using traditional antivirus tools.

In Use

PowerShell Empire has become increasingly popular among hostile state actors and organized criminals. In recent years we have seen it used in cyber incidents globally across a wide range of sectors.

Initial exploitation methods vary between compromises, and threat actors can configure the PowerShell Empire uniquely for each scenario and target. This, in combination with the wide range of skill and intent within the PowerShell Empire user community, means that the ease of detection will vary. Nonetheless, having a greater understanding and awareness of this tool is a step forward in defending against its use by threat actors.

Capabilities

PowerShell Empire enables a threat actor to carry out a range of actions on a victim’s machine and implements the ability to run PowerShell scripts without needing powershell.exe to be present on the system Its communications are encrypted and its architecture is flexible.

PowerShell Empire uses "modules" to perform more specific malicious actions. These modules provide the threat actor with a customizable range of options to pursue their goals on the victim’s systems. These goals include escalation of privileges, credential harvesting, host enumeration, keylogging, and the ability to move laterally across a network.

PowerShell Empire’s ease of use, flexible configuration, and ability to evade detection make it a popular choice for threat actors of varying abilities.

Examples

During an incident in February 2018, a UK energy sector company was compromised by an unknown threat actor. This compromise was detected through PowerShell Empire beaconing activity using the tool’s default profile settings. Weak credentials on one of the victim’s administrator accounts are believed to have provided the threat actor with initial access to the network.

In early 2018, an unknown threat actor used Winter Olympics-themed socially engineered emails and malicious attachments in a spear-phishing campaign targeting several South Korean organizations. This attack had an additional layer of sophistication, making use of Invoke-PSImage, a stenographic tool that will encode any PowerShell script into an image.

In December 2017, APT19 targeted a multinational law firm with a phishing campaign. APT19 used obfuscated PowerShell macros embedded within Microsoft Word documents generated by PowerShell Empire.

Our cybersecurity authorities are also aware of PowerShell Empire being used to target academia. In one reported instance, a threat actor attempted to use PowerShell Empire to gain persistence using a Windows Management Instrumentation event consumer. However, in this instance, the PowerShell Empire agent was unsuccessful in establishing network connections due to the HTTP connections being blocked by a local security appliance.

Detection and Protection

Identifying malicious PowerShell activity can be difficult due to the prevalence of legitimate PowerShell activity on hosts and the increased use of PowerShell in maintaining a corporate environment.

To identify potentially malicious scripts, PowerShell activity should be comprehensively logged. This should include script block logging and PowerShell transcripts.

Older versions of PowerShell should be removed from environments to ensure that they cannot be used to circumvent additional logging and controls added in more recent versions of PowerShell. This page provides a good summary of PowerShell security practices.[10]

The code integrity features in recent versions of Windows can be used to limit the functionality of PowerShell, preventing or hampering malicious PowerShell in the event of a successful intrusion.

A combination of script code signing, application allow listing, and constrained language mode will prevent or limit the effect of malicious PowerShell in the event of a successful intrusion. These controls will also impact legitimate PowerShell scripts and it is strongly advised that they be thoroughly tested before deployment.

When organizations profile their PowerShell usage, they often find it is only used legitimately by a small number of technical staff. Establishing the extent of this legitimate activity will make it easier to monitor and investigate suspicious or unexpected PowerShell usage elsewhere on the network.

C2 Obfuscation and Exfiltration: HUC Packet Transmitter 

Attackers will often want to disguise their location when compromising a target. To do this, they may use generic privacy tools (e.g., Tor) or more specific tools to obfuscate their location.

HUC Packet Transmitter (HTran) is a proxy tool used to intercept and redirect Transmission Control Protocol (TCP) connections from the local host to a remote host. This makes it possible to obfuscate an attacker’s communications with victim networks. The tool has been freely available on the internet since at least 2009.

HTran facilitates TCP connections between the victim and a hop point controlled by a threat actor. Malicious threat actors can use this technique to redirect their packets through multiple compromised hosts running HTran to gain greater access to hosts in a network.

In Use

The use of HTran has been regularly observed in compromises of both government and industry targets.

A broad range of threat actors have been observed using HTran and other connection proxy tools to

• Evade intrusion and detection systems on a network,
• Blend in with common traffic or leverage domain trust relationships to bypass security controls,
• Obfuscate or hide C2 infrastructure or communications, and
• Create peer-to-peer or meshed C2 infrastructure to evade detection and provide resilient connections to infrastructure.

Capabilities

HTran can run in several modes, each of which forwards traffic across a network by bridging two TCP sockets. They differ in terms of where the TCP sockets are initiated from, either locally or remotely. The three modes are

• Server (listen) – Both TCP sockets initiated remotely;
• Client (slave) – Both TCP sockets initiated locally; and
• Proxy (tran) – One TCP socket initiated remotely, the other initiated locally, upon receipt of traffic from the first connection.

HTran can inject itself into running processes and install a rootkit to hide network connections from the host operating system. Using these features also creates Windows registry entries to ensure that HTran maintains persistent access to the victim network.

Examples

Recent investigations by our cybersecurity authorities have identified the use of HTran to maintain and obfuscate remote access to targeted environments.

In one incident, the threat actor compromised externally-facing web servers running outdated and vulnerable web applications. This access enabled the upload of webshells, which were then used to deploy other tools, including HTran.

HTran was installed into the ProgramData directory and other deployed tools were used to reconfigure the server to accept Remote Desktop Protocol (RDP) communications.

The threat actor issued a command to start HTran as a client, initiating a connection to a server located on the internet over port 80, which forwards RDP traffic from the local interface.

In this case, HTTP was chosen to blend in with other traffic that was expected to be seen originating from a web server to the internet. Other well-known ports used included:

• Port 53 – Domain Name System
• Port 443 - HTTP over TLS/Secure Sockets Layer
• Port 3306 - MySQL
• By using HTran in this way, the threat actor was able to use RDP for several months without being detected.

Detection and Protection

Attackers need access to a machine to install and run HTran, so network defenders should apply security patches and use good access control to prevent attackers from installing malicious applications.

Network monitoring and firewalls can help prevent and detect unauthorized connections from tools such as HTran.

In some of the samples analyzed, the rootkit component of HTran only hides connection details when the proxy mode is used. When client mode is used, defenders can view details about the TCP connections being made.

HTran also includes a debugging condition that is useful for network defenders. In the event that a destination becomes unavailable, HTran generates an error message using the following format:

This error message is relayed to the connecting client in the clear. Network defenders can monitor for this error message to potentially detect HTran instances active in their environments.

There are several measures that will improve the overall cybersecurity of your organization and help protect it against the types of tools highlighted in this report. Network defenders are advised to seek further information using the links below.

• Protect your organization from malware.
  See NCCIC Guidance: https://www.us-cert.gov/ncas/tips/ST13-003.
  See UK NCSC Guidance: Small Business Guide: Cyber Security.
• Board toolkit: five question for your board’s agenda.
  See UK NCSC Guidance: https://www.ncsc.gov.uk/guidance/board-toolkit-five-questions-your-boards-agenda.
• Use a strong password policy and multifactor authentication (also known as two-factor authentication or two-step authentication) to reduce the impact of password compromises.
  See NCCIC Guidance: More than a Password.
  See UK NCSC Guidance: Multi-factor authentication for your corporate online services and Setting up 2-Step Verification (2SV).
• Protect your devices and networks by keeping them up to date. Use the latest supported versions, apply security patches promptly, use antivirus and scan regularly to guard against known malware threats.
  See NCCIC Guidance: Understanding Patches and Software Updates.
  See UK NCSC Guidance: Mitigating malware and ransomware attacks.
• Prevent and detect lateral movement in your organization’s networks.
  See UK NCSC Guidance: Preventing Lateral Movement.
• Implement architectural controls for network segregation.
  See UK NCSC Guidance: Architecture and configuration.
• Protect the management interfaces of your critical operational systems. In particular, use browse-down architecture to prevent attackers easily gaining privileged access to your most vital assets.
  See UK NCSC blog post: Protect your management interfaces.
• Set up a security monitoring capability so you are collecting the data that will be needed to analyze network intrusions.
  See UK NCSC Guidance: Introduction to logging for security purposes.
• Review and refresh your incident management processes.
  See UK NCSC Guidance: Incident management.
• Update your systems and software. Ensure your operating system and productivity applications are up to date. Users with Microsoft Office 365 licensing can use “click to run” to keep their office applications seamlessly updated.
• Use modern systems and software. These have better security built-in. If you cannot move off out-of-date platforms and applications straight away, there are short-term steps you can take to improve your position.
  See UK NCSC Guidance: Obsolete products.
• Manage bulk personal datasets properly.
  See UK NCSC Guidance: Protecting bulk personal data.
• Restrict intruders' ability to move freely around your systems and networks. Pay particular attention to potentially vulnerable entry points (e.g., third-party systems with onward access to your core network). During an incident, disable remote access from third-party systems until you are sure they are clean.
  See UK NCSC Guidance: Preventing Lateral Movement and Assessing supply chain security.
• Allow list applications. If supported by your operating environment, consider allow listing of permitted applications. This will help prevent malicious applications from running.
  See UK NCSC Guidance: Device security guidance - Windows.
• Manage macros carefully. Disable Microsoft Office macros, except in the specific applications where they are required.
  Only enable macros for users that need them day-to-day and use a recent and fully patched version of Office and the underlying platform, ideally configured in line with the UK NCSC’s End User Device Security Collection Guidance and UK NCSC’s Macro Security for Microsoft Office Guidance: Device security guidance and Macro Security for Microsoft Office.
• Use antivirus. Keep any antivirus software up to date, and consider use of a cloud-backed antivirus product that can benefit from the economies of scale this brings. Ensure that antivirus programs are also capable of scanning Microsoft Office macros.
  See NCCIC Guidance: Understanding Anti-Virus Software.
  See UK NCSC Guidance: Macro Security for Microsoft Office.
• Layer organization-wide phishing defenses. Detect and quarantine as many malicious email attachments and spam as possible, before they reach your end users. Multiple layers of defense will greatly cut the chances of a compromise.
• Treat people as your first line of defense. Tell personnel how to report suspected phishing emails, and ensure they feel confident to do so. Investigate their reports promptly and thoroughly. Never punish users for clicking phishing links or opening attachments.
  NCCIC encourages users and administrators to report phishing to SayCISA@cisa.dhs.gov.
  See NCCIC Guidance: Avoiding Social Engineering and Phishing Attacks.
  See UK NCSC Guidance: Phishing attacks: defending your organisation.
• Deploy a host-based intrusion detection system. A variety of products are available, free and paid-for, to suit different needs and budgets.
• Defend your systems and networks against denial-of-service attacks.
  See UK NCSC Guidance: Denial of Service (DoS) guidance.
• Defend your organization from ransomware. Keep safe backups of important files, protect from malware, and do not pay the ransom– it may not get your data back.
  See NCCIC Guidance: Stop Ransomware.
  See UK NCSC Guidance: Mitigating malware and ransomware attacks and Step 1 - Backing up your data.
• Make sure you are handling personal data appropriately and securely.
  See NCCIC Guidance: https://www.us-cert.gov/ncas/tips/ST04-013.
  See UK NCSC Guidance: GDPR security outcomes.  

Further information: invest in preventing malware-based attacks across various scenarios. See UK NCSC Guidance: Mitigating malware and ransomware attacks.

Additional Resources from International Partners

• Australian Cyber Security Centre (ACSC) Strategies - Strategies to mitigate cybersecurity incidents
• ACSC Essential Eight - Essential Eight
• Canadian Centre for Cyber Security (CCCS) Top 10 Security Actions - Top 10 IT security actions
• CCCS Cyber Hygiene - Cyber hygiene
• CERT New Zealand's Critical Controls 2018 - Critical Controls
• CERT New Zealand’s Top 11 Cyber Security Tips for Your Business - https://www.cert.govt.nz/businesses-and-individuals/guides/cyber-security-your-business/top-11-cyber-security-tips-for-your-business/
• New Zealand National Cyber Security Centre (NZ NCSC) Resources - Resources
• New Zealand Information Security Manual - New Zealand Information Security Manual
• UK NCSC 10 Steps to Cyber Security - 10 Steps to Cyber Security
• UK NCSC Board Toolkit: five questions for your board's agenda - https://www.ncsc.gov.uk/guidance/board-toolkit-five-questions-your-boards-agenda
• UK NCSC Cyber Security: Small Business Guide - Small Business Guide: Cyber Security

NCCIC encourages recipients of this report to contribute any additional information that they may have related to this threat. For any questions related to this report, please contact NCCIC at:

• 1-844-Say-CISA (From outside the United States: +1-703-235-8832)
• SayCISA@cisa.dhs.gov (UNCLASS)

NCCIC encourages you to report any suspicious activity, including cybersecurity incidents, possible malicious code, software vulnerabilities, and phishing-related scams. Reporting forms can be found at Incident Reporting Form Index - IRF.

Feedback

NCCIC strives to make this report a valuable tool for our partners and welcomes feedback on how this publication could be improved. You can help by answering a few short questions about this report at the following URL: Website Feedback.

October 11, 2018: Initial version

The Department of Homeland Security (DHS) National Cybersecurity and Communications Integration Center (NCCIC) and the Federal Bureau of Investigation (FBI) are issuing this activity alert to inform computer network defenders about SamSam ransomware, also known as MSIL/Samas.A. Specifically, this product shares analysis of vulnerabilities that cyber actors exploited to deploy this ransomware. In addition, this report provides recommendations for prevention and mitigation.

The SamSam actors targeted multiple industries, including some within critical infrastructure. Victims were located predominately in the United States, but also internationally. Network-wide infections against organizations are far more likely to garner large ransom payments than infections of individual systems. Organizations that provide essential functions have a critical need to resume operations quickly and are more likely to pay larger ransoms.

The actors exploit Windows servers to gain persistent access to a victim’s network and infect all reachable hosts. According to reporting from victims in early 2016, cyber actors used the JexBoss Exploit Kit to access vulnerable JBoss applications. Since mid-2016, FBI analysis of victims’ machines indicates that cyber actors use Remote Desktop Protocol (RDP) to gain persistent access to victims’ networks. Typically, actors either use brute force attacks or stolen login credentials. Detecting RDP intrusions can be challenging because the malware enters through an approved access point.

After gaining access to a particular network, the SamSam actors escalate privileges for administrator rights, drop malware onto the server, and run an executable file, all without victims’ action or authorization. While many ransomware campaigns rely on a victim completing an action, such as opening an email or visiting a compromised website, RDP allows cyber actors to infect victims with minimal detection.

Analysis of tools found on victims’ networks indicated that successful cyber actors purchased several of the stolen RDP credentials from known darknet marketplaces. FBI analysis of victims’ access logs revealed that the SamSam actors can infect a network within hours of purchasing the credentials. While remediating infected systems, several victims found suspicious activity on their networks unrelated to SamSam. This activity is a possible indicator that the victims’ credentials were stolen, sold on the darknet, and used for other illegal activity.

SamSam actors leave ransom notes on encrypted computers. These instructions direct victims to establish contact through a Tor hidden service site. After paying the ransom in Bitcoin and establishing contact, victims usually receive links to download cryptographic keys and tools to decrypt their network.

NCCIC recommends organizations review the following SamSam Malware Analysis Reports. The reports represent four SamSam malware variants. This is not an exhaustive list.

• MAR-10219351.r1.v2 – SamSam1
• MAR-10166283.r1.v1 – SamSam2
• MAR-10158513.r1.v1 – SamSam3
• MAR-10164494.r1.v1 – SamSam4

For general information on ransomware, see the NCCIC Security Publication at Stop Ransomware.

DHS and FBI recommend that users and administrators consider using the following best practices to strengthen the security posture of their organization's systems. System owners and administrators should review any configuration changes before implementation to avoid unwanted impacts.

• Audit your network for systems that use RDP for remote communication. Disable the service if unneeded or install available patches. Users may need to work with their technology venders to confirm that patches will not affect system processes.
• Verify that all cloud-based virtual machine instances with public IPs have no open RDP ports, especially port 3389, unless there is a valid business reason to keep open RDP ports. Place any system with an open RDP port behind a firewall and require users to use a virtual private network (VPN) to access that system.
• Enable strong passwords and account lockout policies to defend against brute force attacks.
• Where possible, apply two-factor authentication.
• Regularly apply system and software updates.
• Maintain a good back-up strategy.
• Enable logging and ensure that logging mechanisms capture RDP logins. Keep logs for a minimum of 90 days and review them regularly to detect intrusion attempts.
• When creating cloud-based virtual machines, adhere to the cloud provider’s best practices for remote access.
• Ensure that third parties that require RDP access follow internal policies on remote access.
• Minimize network exposure for all control system devices. Where possible, disable RDP on critical devices.
• Regulate and limit external-to-internal RDP connections. When external access to internal resources is required, use secure methods such as VPNs. Of course, VPNs are only as secure as the connected devices.
• Restrict users' ability (permissions) to install and run unwanted software applications.
• Scan for and remove suspicious email attachments; ensure the scanned attachment is its "true file type" (i.e., the extension matches the file header).
• Disable file and printer sharing services. If these services are required, use strong passwords or Active Directory authentication.

Additional information on malware incident prevention and handling can be found in Special Publication 800-83, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, from the National Institute of Standards and Technology.[1]

To report an intrusion and request resources for incident response or technical assistance, contact NCCIC, FBI, or the FBI’s Cyber Division via the following information:

• NCCIC
  • SayCISA@cisa.dhs.gov
  • 1-844-Say-CISA
• FBI’s Cyber Division
  • CyWatch@fbi.gov
  • 855-292-3937
• FBI through a local field office

Feedback

DHS strives to make this report a valuable tool for our partners and welcomes feedback on how this publication could be improved. You can help by answering a few short questions about this report at the following URL: Website Feedback.

December 3, 2018: Initial version

The National Cybersecurity and Communications Integration Center (NCCIC), part of the Cybersecurity and Infrastructure Security Agency (CISA), is aware of a global Domain Name System (DNS) infrastructure hijacking campaign. Using compromised credentials, an attacker can modify the location to which an organization’s domain name resources resolve. This enables the attacker to redirect user traffic to attacker-controlled infrastructure and obtain valid encryption certificates for an organization’s domain names, enabling man-in-the-middle attacks.

See the following links for downloadable copies of open-source indicators of compromise (IOCs) from the sources listed in the References section below:

• IOCs (.csv)
• IOCs (.stix)

Note: these files were last updated February 13, 2019, to remove the following three non-malicious IP addresses:

• 107.161.23.204
• 192.161.187.200
• 209.141.38.71

Using the following techniques, attackers have redirected and intercepted web and mail traffic, and could do so for other networked services.

1. The attacker begins by compromising user credentials, or obtaining them through alternate means, of an account that can make changes to DNS records.
2. Next, the attacker alters DNS records, like Address (A), Mail Exchanger (MX), or Name Server (NS) records, replacing the legitimate address of a service with an address the attacker controls. This enables them to direct user traffic to their own infrastructure for manipulation or inspection before passing it on to the legitimate service, should they choose. This creates a risk that persists beyond the period of traffic redirection.
3. Because the attacker can set DNS record values, they can also obtain valid encryption certificates for an organization’s domain names. This allows the redirected traffic to be decrypted, exposing any user-submitted data. Since the certificate is valid for the domain, end users receive no error warnings.

NCCIC recommends the following best practices to help safeguard networks against this threat:

• Update the passwords for all accounts that can change organizations’ DNS records.
• Implement multifactor authentication on domain registrar accounts, or on other systems used to modify DNS records.
• Audit public DNS records to verify they are resolving to the intended location.
• Search for encryption certificates related to domains and revoke any fraudulently requested certificates.

January 24, 2019: Initial version
February 6, 2019: Updated IOCs, added Crowdstrike blog
February 13, 2019: Updated IOCs

The Cybersecurity and Infrastructure Security Agency (CISA) is issuing this activity alert in response to recently disclosed exploits that target unsecure configurations of SAP components. [1]

A presentation at the April 2019 Operation for Community Development and Empowerment (OPCDE) cybersecurity conference describes SAP systems with unsecure configurations exposed to the internet. Typically, SAP systems are not intended to be exposed to the internet as it is an untrusted network. Malicious cyber actors can attack and compromise these unsecure systems with publicly available exploit tools, termed “10KBLAZE.” The presentation details the new exploit tools and reports on systems exposed to the internet.

SAP Gateway ACL

The SAP Gateway allows non-SAP applications to communicate with SAP applications. If SAP Gateway access control lists (ACLs) are not configured properly (e.g., gw/acl_mode = 0), anonymous users can run operating system (OS) commands.[2] According to the OPCDE presentation, about 900 U.S. internet-facing systems were detected in this vulnerable condition.

SAP Router secinfo

The SAP router is a program that helps connect SAP systems with external networks. The default secinfo configuration for a SAP Gateway allows any internal host to run OS commands anonymously. If an attacker can access a misconfigured SAP router, the router can act as an internal host and proxy the attacker’s requests, which may result in remote code execution.

According to the OPCDE presentation, 1,181 SAP routers were exposed to the internet. It is unclear if the exposed systems were confirmed to be vulnerable or were simply running the SAP router service.

SAP Message Server

SAP Message Servers act as brokers between Application Servers (AS). By default, Message Servers listen on a port 39XX and have no authentication. If an attacker can access a Message Server, they can redirect and/or execute legitimate man-in-the-middle (MITM) requests, thereby gaining credentials. Those credentials can be used to execute code or operations on AS servers (assuming the attacker can reach them). According to the OPCDE presentation, there are 693 Message Servers exposed to the internet in the United States. The Message Server ACL must be protected by the customer in all releases.

Signature

CISA worked with security researchers from Onapsis Inc.[3] to develop the following Snort signature that can be used to detect the exploits:

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"10KBLAZE SAP Exploit execute attempt"; flow:established,to_server; content:"|06 cb 03|"; offset:4; depth:3; content:"SAPXPG_START_XPG"; nocase; distance:0; fast_pattern; content:"37D581E3889AF16DA00A000C290099D0001"; nocase; distance:0; content:"extprog"; nocase; distance:0; sid:1; rev:1;)

Mitigations

CISA recommends administrators of SAP systems implement the following to mitigate the vulnerabilities included in the OPCDE presentation:

• Ensure a secure configuration of their SAP landscape.
• Restrict access to SAP Message Server.
  • Review SAP Notes 1408081 and 821875. Restrict authorized hosts via ACL files on Gateways (gw/acl_mode and secinfo) and Message Servers (ms/acl_info).[4], [5]
  • Review SAP Note 1421005. Split MS internal/public: rdisp/msserv=0 rdisp/msserv_internal=39NN. [6]
  • Restrict access to Message Server internal port (tcp/39NN) to clients or the internet.
  • Enable Secure Network Communications (SNC) for clients.
• Scan for exposed SAP components.
  • Ensure that SAP components are not exposed to the internet.
  • Remove or secure any exposed SAP components.

May 2, 2019: Initial version

The Cybersecurity and Infrastructure Security Agency (CISA) is issuing this Activity Alert to provide information on a vulnerability, known as “BlueKeep,” that exists in the following Microsoft Windows Operating Systems (OSs), including both 32- and 64-bit versions, as well as all Service Pack versions:

• Windows 2000
• Windows Vista
• Windows XP
• Windows 7
• Windows Server 2003
• Windows Server 2003 R2
• Windows Server 2008
• Windows Server 2008 R2

An attacker can exploit this vulnerability to take control of an affected system.     

BlueKeep (CVE-2019-0708) exists within the Remote Desktop Protocol (RDP) used by the Microsoft Windows OSs listed above. An attacker can exploit this vulnerability to perform remote code execution on an unprotected system. 

According to Microsoft, an attacker can send specially crafted packets to one of these operating systems that has RDP enabled.[1] After successfully sending the packets, the attacker would have the ability to perform a number of actions: adding accounts with full user rights; viewing, changing, or deleting data; or installing programs. This exploit, which requires no user interaction, must occur before authentication to be successful.

BlueKeep is considered “wormable” because malware exploiting this vulnerability on a system could propagate to other vulnerable systems; thus, a BlueKeep exploit would be capable of rapidly spreading in a fashion similar to the WannaCry malware attacks of 2017.[2]

CISA has coordinated with external stakeholders and determined that Windows 2000 is vulnerable to BlueKeep.

CISA encourages users and administrators review the Microsoft Security Advisory [1] and the Microsoft Customer Guidance for CVE-2019-0708 [3] and apply the appropriate mitigation measures as soon as possible:

• Install available patches. Microsoft has released security updates to patch this vulnerability. Microsoft has also released patches for a number of OSs that are no longer officially supported, including Windows Vista, Windows XP, and Windows Server 2003. As always, CISA encourages users and administrators to test patches before installation.

For OSs that do not have patches or systems that cannot be patched, other mitigation steps can be used to help protect against BlueKeep:

• Upgrade end-of-life (EOL) OSs. Consider upgrading any EOL OSs no longer supported by Microsoft to a newer, supported OS, such as Windows 10.
• Disable unnecessary services. Disable services not being used by the OS. This best practice limits exposure to vulnerabilities.  
• Enable Network Level Authentication. Enable Network Level Authentication in Windows 7, Windows Server 2008, and Windows Server 2008 R2. Doing so forces a session request to be authenticated and effectively mitigates against BlueKeep, as exploit of the vulnerability requires an unauthenticated session.
• Block Transmission Control Protocol (TCP) port 3389 at the enterprise perimeter firewall. Because port 3389 is used to initiate an RDP session, blocking it prevents an attacker from exploiting BlueKeep from outside the user’s network. However, this will block legitimate RDP sessions and may not prevent unauthenticated sessions from being initiated inside a network.

June 17, 2019: Initial version
June 17, 2019: Revised technical details section.

Note: This alert does not apply to federally certified voting systems running Windows 7. Microsoft will continue to provide free security updates to those systems through the 2020 election. See Microsoft’s article, Extending free Windows 7 security updates to voting systems, for more information.

On January 14, 2020, Microsoft will end extended support for their Windows 7 and Windows Server 2008 R2 operating systems.[1] After this date, these products will no longer receive free technical support, or software and security updates.

Organizations that have regulatory obligations may find that they are unable to satisfy compliance requirements while running Windows 7 and Windows Server 2008 R2.

All software products have a lifecycle. “End of support” refers to the date when the software vendor will no longer provide automatic fixes, updates, or online technical assistance. [2]

For more information on end of support for Microsoft products see the Microsoft End of Support FAQ.

Systems running Windows 7 and Windows Server 2008 R2 will continue to work at their current capacity even after support ends on January 14, 2020. However, using unsupported software may increase the likelihood of malware and other security threats. Mission and business functions supported by systems running Windows 7 and Windows Server 2008 R2 could experience negative consequences resulting from unpatched vulnerabilities and software bugs. These negative consequences could include the loss of confidentiality, integrity, and availability of data, system resources, and business assets.

The Cybersecurity and Infrastructure Security Agency (CISA) encourages users and organizations to:

• Upgrade to a newer operating system.
• Identify affected devices to determine breadth of the problem and assess risk of not upgrading. 
• Establish and execute a plan to systematically migrate to currently supported operating systems or employ a cloud-based service. 
• Contact the operating system vendor to explore opportunities for fee-for-service maintenance, if unable to upgrade.   

October 17, 2019: Initial version|October 18, 2019: Added note

This Alert is the result of recent collaboration between the Department of the Treasury Financial Sector Cyber Information Group (CIG) and the Department of the Treasury’s Financial Crimes Enforcement Network (FinCEN) to identify and share information with the financial services sector. Treasury and the Cybersecurity and Infrastructure Security Agency (CISA) are providing this report to inform the sector about the Dridex malware and variants. The report provides an overview of the malware, related activity, and a list of previously unreported indicators of compromise derived from information reported to FinCEN by private sector financial institutions. Because actors using Dridex malware and its derivatives continue to target the financial services sector, including financial institutions and customers, the techniques, tactics, and procedures contained in this report warrant renewed attention. Treasury and CISA encourage network security specialists to incorporate these indicators into existing Dridex-related network defense capabilities and planning. For information regarding the malicious cyber actors responsible for the development and distribution of the Dridex malware, see the Treasury press release, Treasury Sanctions Evil Corp, the Russia-Based Cybercriminal Group Behind Dridex Malware and the FBI press release, Russian National Charged with Decade-Long Series of Hacking and Bank Fraud Offenses Resulting in Tens of Millions in Losses and Second Russian National Charged with Involvement in Deployment of “Bugat” Malware.

This Alert does not introduce a new regulatory interpretation, nor impose any new requirements on regulated entities. Except where noted, there is no indication that the actual owner of the email address was involved in the suspicious or malicious activity. If activity related to these indicators of compromise is detected, please notify appropriate law enforcement and the CIG.

For a downloadable copy of IOCs, see:

• AA19-339A CSV
• AA19-339A STIX XML

The Dridex malware, and its various iterations, has the capability to impact confidentiality of customer data and availability of data and systems for business processes. According to industry reporting, the original version of Dridex first appeared in 2012, and by 2015 had become one of the most prevalent financial Trojans. We expect actors using Dridex malware and its derivatives to continue targeting the financial services sector, including both financial institutions and customers.

Dridex-related Phishing Attributes

Actors typically distribute Dridex malware through phishing e-mail spam campaigns. Phishing messages employ a combination of legitimate business names and domains, professional terminology, and language implying urgency to persuade victims to activate open attachments. Sender e-mail addresses can simulate individuals (name@domain.com), administrative (admin@domain.com, support@domain.com), or common “do not reply” local parts (noreply@domain.com). Subject and attachment titles can include typical terms such as “invoice”, “order”, “scan”, “receipt”, “debit note”, “itinerary”, and others.

The e-mail messages vary widely. The e-mail body may contain no text at all, except to include attachments with names that are strings of numbers, apparently relying on the subject line and victim curiosity to coerce the opening of the malicious file. Where there is a message body, the body may specifically state that the contents of the e-mail underwent virus scanning or simply directs the victim toward the link or attachment. In other cases, the body may include a long, substantive message, providing multiple points of contact and context for the malicious attachment. Attachment and hyperlink names vary from random sets of numbers or imitation automatic filenames from scanners to filenames purporting to reference financial records. Attachments may or may not have direct references using the same file name or strings of numbers in the bodies of the e-mails.

Example Links and Filenames (Note: link information is representative. Italicized statements are automatically generated by the cloud storage provider. # represents a random number.):

• Link: HTTPS://WWW.GOOGLE[.]COM/URL?Q=HTTPS://WWW.(Cloud Services Provider)[.]COM/S/(Cloud Account Value) /RECENT%20WIRE%20PAYMENT %######.SCR?(Cloud Provided Sequence)
• Link: HTTPS://WWW.GOOGLE[.]COM/URL?Q=HTTPS://WWW.(Cloud Services Provider) [.]COM/S/ Cloud Account Value/AUTOMATEDCLEARINGHOUSE%20 PAYMENT####.DOC? (Cloud Provided Sequence)
• Link: Malicious File: ID201NLD0012192016.DOC

Attachments or eventual downloads can take a variety of formats. In some instances, malware downloaders are concealed in compressed files using the ZIP or RAR file formats.  Occasionally compressed files within compressed files (double zipped) are used. The compressed files can include extensible markup language (.xml), Microsoft Office (.doc, .xls), Visual Basic (.vbs), JavaScript (.jar), or portable document format (.pdf) files. Many of the files, rather than containing the actual malware, contain hidden or obfuscated macros. Upon activation, the macros reach to a command and control server, FTP server, or cloud storage site to download the actual Dridex malware. In other cases, macros launch scripts that extract executables imbedded in the document as opposed to downloading the payload.

By default, software generally prevents execution of macros without user permission. Attached files, particularly .doc and .xls files, contain instructions on how a user should enable content and specifically macros, effectively using social engineering to facilitate the download. Malicious files sometimes even include screenshots of the necessary actions to enable macros.

Malware Capabilities

Dridex malware operates from multiple modules that may be downloaded together or following the initial download of a “loader” module. Modules include provisions for capturing screenshots, acting as a virtual machine, or incorporating the victim machine into a botnet. Through its history and development, Dridex has used several exploits and methods for execution, including modification of directory files, using system recovery to escalate privileges, and modification of firewall rules to facilitate peer-to-peer communication for extraction of data. Recent versions of Dridex exploit vulnerability CVE-2017-0199, which allows remote execution of code. This vulnerability is specific to Microsoft Office and WordPad. Microsoft released a patch in 2017.

Once downloaded and active, Dridex has a wide range of capabilities, from downloading additional software to establishing a virtual network to deletion of files.  The primary threat to financial activity is the Dridex’s ability to infiltrate browsers, detect access to online banking applications and websites, and inject malware or keylogging software, via API hooking, to steal customer login information. Dridex modules package, encrypt, and transmit captured information, screenshots, etc., via peer-to-peer (P2P) networks in the XML format or in binary format, as seen in newer versions. After stealing the login data, the attackers have the potential to facilitate fraudulent automated clearing house (ACH) and wire transfers, open fraudulent accounts, and potentially adapt victim accounts for other scams involving business e-mail compromise or money mule activity.

The Dridex malware has evolved through several versions since its inception, partially to adapt to updated browsers. Although the characteristics described reflect some of the most recent configurations, actors continue to identify and exploit vulnerabilities in widely used software.

Dridex Malware and Variants

While Dridex is among the most prevalent sources of infection, previous variants and similar malware continue to represent a threat. Dridex is itself an improved variant of the Cridex and Bugat Trojans that preceded it, and it shares some of their codes. Although the previous variants’ theft activities operate in mostly the same way, the P2P communication aspects of Dridex improve its concealment and redundancy.

Ransomware

Actors distributing Dridex likely employ ransomware with similar configurations. Code for BitPaymer, also known as Friedex, includes numerous similarities to Dridex, despite its function as ransomware rather than data extraction. The two malwares use the same mechanics for several functions, and the authors compiled the codes at nearly the same time. The ransomware distributed through these malwares has targeted U.S. financial institutions and resulted in data and financial loss.

Locky ransomware operates using the same delivery method for the downloader, with similar subject lines and attachments. Attackers also use the same botnets to deliver both Dridex and Locky ransomware, sometimes simultaneously. Variants of Locky include Zepto and Osiris. Locky ransomware and its variants have a wide footprint, with varying impact depending on victim IT policies and practices and network configurations.

Dridex-related Activity

Although the highest infection rates took place in late 2015 and early 2016, concurrent with Locky ransomware distribution, Dridex continues to impact numerous countries. The Dridex hackers appear to direct the majority of attacks at English-speaking countries. Cybersecurity industry reporting attributes Dridex, BitPaymer, and Locky campaigns, as well as other massive malware spam (malspam) campaigns to actors known alternately as Evil Corp or TA505. (Note: some cybersecurity industry reporting simply refers to the actors as “Dridex” or the “Dridex hackers.”) Actors distribute the malware via massive spam campaigns, sending up to millions of messages per day, although volume of messages varies widely.

Indicators of Compromise

The following indicators are associated with the activity described in this report:

Indicator Type	Indicator Value	Associated Activity
Email address	info[@]antonioscognamiglio[.]it	Dridex
Email address	info[@]golfprogroup[.]com	Dridex
Email address	cariola72[@]teletu[.]it	Dridex
Email address	faturamento[@]sudestecaminhoes[.]com.br	Dridex
Email address	info[@]melvale[.]co.uk	Dridex
Email address	fabianurquiza[@]correo.dalvear[.]com.ar	Dridex
Email address	web1587p16[@]mail.flw-buero[.]at	Dridex
Email address	bounce[@]bestvaluestore[.]org	Dridex
Email address	farid[@]abc-telecom[.]az	Dridex
Email address	bounce[@]bestvaluestore[.]org	Dridex
Email address	admin[@]sevpazarlama[.]com	Dridex
Email address	faturamento[@]sudestecaminhoes[.]com.br	Dridex
Email address	pranab[@]pdrassocs[.]com	Dridex
Email address	tom[@]blackburnpowerltd[.]co.uk	Dridex
Email address	yportocarrero[@]elevenca[.]com	Dridex
Email address	s.palani[@]itifsl.co[.]in	Dridex
Email address	faber[@]imaba[.]nl	Dridex
Email address	admin[@]belpay[.]by	Dridex
IP address	62[.]149[.]158[.]252	Dridex
IP address	177[.]34[.]32[.]109	Dridex
IP address	2[.]138[.]111[.]86	Dridex
IP address	122[.]172[.]96[.]18	Dridex
IP address	69[.]93[.]243[.]5	Dridex
IP address	200[.]43[.]183[.]102	Dridex
IP address	79[.]124[.]76[.]30	Dridex
IP address	188[.]125[.]166[.]114	Dridex
IP address	37[.]59[.]52[.]64	Dridex
IP address	50[.]28[.]35[.]36	Dridex
IP address	154[.]70[.]39[.]158	Dridex
IP address	108[.]29[.]37[.]11	Dridex
IP address	65[.]112[.]218[.]2	Dridex

 

Treasury and CISA encourage users and organizations to:

1. Contact law enforcement immediately report regarding any identified activity related to Dridex malware or its derivatives. Please see contact information for FBI and CISA at the end of this report.
2. Incorporate the indicators of compromise identified in this report into intrusion detection systems and security alert systems to enable active blocking or reporting of suspected malicious activity. Note that the above list is not a comprehensive list of all indicators associated with this activity.
3. Report suspicious activity, highlighting the presence of “Cyber Event Indicators.” Indicators of Compromise, such as suspicious e-mail addresses, file names, hashes, domains, and IP addresses, can be provided under Item 44 of the Suspicious Activity Report (SAR) form. FinCEN welcomes voluntary SAR filing in circumstances where reporting is not required.

Recommendations for All Organizations

The following mitigation recommendations respond directly to Dridex TTPs:

• Ensuring systems are set by default to prevent execution of macros.
• Inform and educate employees on the appearance of phishing messages, especially those used by the hackers for distribution of malware in the past.
• Update intrusion detection and prevention systems frequently to ensure the latest variants of malware and downloaders are included.
• Conduct regular backup of data, ensuring backups are protected from potential ransomware attack.
• Exercise employees’ response to phishing messages and unauthorized intrusion.
• If there is any doubt about message validity, call and confirm the message with the sender using a number or e-mail address already on file.
• Treasury and CISA remind users and administrators to use the following best practices to strengthen the security posture of their organization’s systems:
• Maintain up-to-date antivirus signatures and engines.
• Keep operating system patches up-to-date.
• Disable file and printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
• Restrict users’ ability (permissions) to install and run unwanted software applications. Do not add users to the local administrators group unless required.
• Enforce a strong password policy and require regular password changes.
• Exercise caution when opening email attachments even if the attachment is expected and the sender appears to be known.
• Enable a personal firewall on workstations, and configure it to deny unsolicited connection requests.
• Disable unnecessary services on agency workstations and servers.
• Scan for and remove suspicious email attachments; ensure the scanned attachment is its “true file type” (i.e., the extension matches the file header).
• Monitor users' web browsing habits; restrict access to sites with unfavorable content.
• Exercise caution when using removable media (e.g., USB thumb drives, external drives, CDs).
• Scan all software downloaded from the Internet before executing.
• Maintain situational awareness of the latest threats.
• Implement appropriate access control lists.
• Exercise cybersecurity procedures and continuity of operations plans to enhance and maintain ability to respond during and following a cyber incident.

The National Institute of Standards and Technology (NIST) has published additional information on malware incident prevention and handling in their Special Publication 800-83, Guide to Malware Incident Prevention and Handling for Desktops and Laptops.

Why Best Practices Matter

The National Security Agency (NSA) recently published its Top Ten Cybersecurity Mitigation Strategies (this is the current website for Top 10 mitigation strategies). Aligned with the NIST Cybersecurity Framework, the Strategies offer a risk-based approach to mitigating exploitation techniques used by Advance Persistent Threat (APT) actors.

The Strategies counter a broad range of exploitation techniques used by malicious cyber actors. NSA’s mitigations set priorities for enterprise organizations to minimize mission impact. The mitigations also build upon the NIST Cybersecurity Framework functions to manage cybersecurity risk and promote a defense-in-depth security posture. The mitigation strategies are ranked by effectiveness against known APT tactics. Additional strategies and best practices will be required to mitigate the occurrence of new tactics.

1. Update and Upgrade Software Immediately. Apply all available software updates, automate the process to the extent possible, and use an update service provided directly from the vendor. Automation is necessary because threat actors study patches and create exploits, often soon after a patch is released. These “N-day” exploits can be as damaging as a zero-day. Vendor updates must also be authentic; updates are typically signed and delivered over protected links to assure the integrity of the content. Without rapid and thorough patch application, threat actors can operate inside a defender’s patch cycle.
2. Defend Privileges and Accounts. Assign privileges based on risk exposure and as required to maintain operations. Use a Privileged Access Management (PAM) solution to automate credential management and fine-grained access control. Another way to manage privilege is through tiered administrative access in which each higher tier provides additional access, but is limited to fewer personnel. Create procedures to securely reset credentials (e.g., passwords, tokens, tickets). Privileged accounts and services must be controlled because threat actors continue to target administrator credentials to access high-value assets, and to move laterally through the network.
3. Enforce Signed Software Execution Policies. Use a modern operating system that enforces signed software execution policies for scripts, executables, device drivers, and system firmware. Maintain a list of trusted certificates to prevent and detect the use and injection of illegitimate executables. Execution policies, when used in conjunction with a secure boot capability, can assure system integrity. Application Allow listing should be used with signed software execution policies to provide greater control. Allowing unsigned software enables threat actors to gain a foothold and establish persistence through embedded malicious code.
4. Exercise a System Recovery Plan. Create, review, and exercise a system recovery plan to ensure the restoration of data as part of a comprehensive disaster recovery strategy. The plan must protect critical data, configurations, and logs to ensure continuity of operations due to unexpected events. For additional protection, backups should be encrypted, stored offsite, offline when possible, and support complete recovery and reconstitution of systems and devices. Perform periodic testing and evaluate the backup plan. Update the plan as necessary to accommodate the ever-changing network environment. A recovery plan is a necessary mitigation for natural disasters as well as malicious threats including ransomware.
5. Actively Manage Systems and Configurations. Take inventory of network devices and software. Remove unwanted, unneeded, or unexpected hardware and software from the network. Starting from a known baseline reduces the attack surface and establishes control of the operational environment. Thereafter, actively manage devices, applications, operating systems, and security configurations. Active enterprise management ensures that systems can adapt to dynamic threat environments while scaling and streamlining administrative operations.
6. Continuously Hunt for Network Intrusions. Take proactive steps to detect, contain, and remove any malicious presence within the network. Enterprise organizations should assume that a compromise has taken place and use dedicated teams to continuously seek out, contain, and remove threat actors within the network. Passive detection mechanisms, such as logs, Security Information and Event Management (SIEM) products, Endpoint Detection and Response (EDR) solutions, and other data analytic capabilities are invaluable tools to find malicious or anomalous behaviors. Active pursuits should also include hunt operations and penetration testing using well documented incident response procedures to address any discovered breaches in security. Establishing proactive steps will transition the organization beyond basic detection methods, enabling real-time threat detection and remediation using a continuous monitoring and mitigation strategy.
7. Leverage Modern Hardware Security Features. Use hardware security features like Unified Extensible Firmware Interface (UEFI) Secure Boot, Trusted Platform Module (TPM), and hardware virtualization. Schedule older devices for a hardware refresh. Modern hardware features increase the integrity of the boot process, provide system attestation, and support features for high-risk application containment. Using a modern operating system on outdated hardware results in a reduced ability to protect the system, critical data, and user credentials from threat actors.
8. Segregate Networks Using Application-Aware Defenses. Segregate critical networks and services. Deploy application-aware network defenses to block improperly formed traffic and restrict content, according to policy and legal authorizations. Traditional intrusion detection based on known-bad signatures is quickly decreasing in effectiveness due to encryption and obfuscation techniques. Threat actors hide malicious actions and remove data over common protocols, making the need for sophisticated, application-aware defensive mechanisms critical for modern network defenses.
9. Integrate Threat Reputation Services. Leverage multi-sourced threat reputation services for files, DNS, URLs, IPs, and email addresses. Reputation services assist in the detection and prevention of malicious events and allow for rapid global responses to threats, a reduction of exposure from known threats, and provide access to a much larger threat analysis and tipping capability than an organization can provide on its own. Emerging threats, whether targeted or global campaigns, occur faster than most organizations can handle, resulting in poor coverage of new threats. Multi-source reputation and information sharing services can provide a more timely and effective security posture against dynamic threat actors.
10. Transition to Multi-Factor Authentication. Prioritize protection for accounts with elevated privileges, remote access, and/or used on high value assets. Physical token-based authentication systems should be used to supplement knowledge-based factors such as passwords and PINs. Organizations should migrate away from single factor authentication, such as password-based systems, which are subject to poor user choices and susceptible to credential theft, forgery, and reuse across multiple systems.

Reporting Suspected Malicious Activity

To report an intrusion and request resources for incident response or technical assistance, contact CISA (central@mail.cisa.dhs.gov or 1-844-Say-CISA), FBI through a local field office, or FBI’s Cyber Division (CyWatch@fbi.gov or 855-292-3937).

Institutions should determine whether filing of a Suspicious Activity Report (“SAR”) is required under Bank Secrecy Act regulations.  In instances where filing is not required, institutions may file a SAR voluntarily to aid FinCEN and law enforcement efforts in protecting the financial sector.  Financial institutions are encouraged to provide relevant cyber-related information and indicators in their SAR reporting.  For questions regarding cyber SAR filing, please contact the FinCEN Resource Center (FRC@fincen.gov or 1-800-767-2825).

Open-Source Reporting on Dridex

The following represents an alphabetized selection of open-source reporting by U.S. government and industry sources on Dridex malware and its derivatives:

• “Dridex P2P Malware,” US-CERT Alert (TA15-286A), https://www.cisa.gov/news-events/alerts/2015/10/13/dridex-p2p-malware, 13 October 2015.
• “Dridex Threat Profile,” New Jersey Cybersecurity & Communications Integration Cell, https://www.cyber.nj.gov/threat-landscape/malware/trojans/dridex, accessed 15 April 2019.
• Alert Logic, “Dridex malware has evolved to Locky Ransomware,” No date, https://www.alertlogic.com/resources/industry-reports/ransomware-in-focus/, accessed 11 March 2019.
• Avast Blog, “A closer look at the Locky ransomware,” 10 March 2016, https://blog.avast.com/a-closer-look-at-the-locky-ransomware, accessed 6 February 2019.
• Brett Stone-Gross, Ph.D., “Dridex (Bugat v5) Botnet Takeover Operation,” Secureworks, 13 October 2015, https://www.secureworks.com/research/dridex-bugat-v5-botnet-takeover-operation, accessed 6 February 2019.
• Brewster, Thomas, “Cops Knock Down Dridex Malware that Earned ‘Evil Corp’ Cybercriminals At Least $50 Million,” Forbes, 13 October 2015, https://www.forbes.com/sites/thomasbrewster/2015/10/13/dridex-botnet-takedown/#2b883f00415b.
• Chandler, Andy, “FBI announces Dridex gang indictment and praises Fox-IT,” Fox-IT, 13 October 2015, https://www.fox-it.com/en/about-fox-it/corporate/news/fbi-announces-dridex-gang-indictments-praises-fox/, accessed 7 February 2019.
• DHS CISA, “Alert (TA15-286A), Dridex P2P Malware,” https://www.cisa.gov/news-events/alerts/2015/10/13/dridex-p2p-malware, accessed 4 June 2019.
• Eduard Kovacs, “Dridex still active after takedown attempt,” Security Week, 19 October 2015, https://www.securityweek.com/dridex-still-active-after-takedown-attempt, accessed 11 March 2019.
• Geoff White, “How the Dridex Gang makes millions from bespoke ransomware,” Forbes, 26 September 2018, https://www.forbes.com/sites/geoffwhite/2018/09/26/how-the-dridex-gang-makes-millions-from-bespoke-ransomware/, accessed 11 March 2019.
• MS-ISAC, “Cybercrime Technical Desk Reference,” 31 August 2018, https://www.cisecurity.org/wp-content/uploads/2018/09/MS-ISAC-Cyber-Crime-Technical-Desk-Reference.pdf, accessed 6 February 2019.
• O’Brien, Dick. “Dridex: Tidal waves of spam pushing dangerous financial Trojan,” Symantec, February 2016, https://docs.broadcom.com/doc/dridex-financial-trojan, accessed 4 February 2019.
• Poslušný, Michal, “FriedEx: BitPaymer ransomware the work of Dridex authors,” welivesecurity by ESET, 26 January 2018, https://www.welivesecurity.com/2018/01/26/friedex-bitpaymer-ransomware-work-dridex-authors/, accessed 6 February 2019.
• Proofpoint, “Dridex Campaigns Hitting Millions of Recipients Using Unpatched Microsoft Zero-Day,” https://www.proofpoint.com/us/threat-insight/post/dridex-campaigns-millions-recipients-unpatched-microsoft-zero-day, accessed 5 February 2019.
• Proofpoint, “High-Volume Dridex Banking Trojan Campaigns Return.” https://www.proofpoint.com/us/threat-insight/post/high-volume-dridex-campaigns-return, accessed 1 February 2019.
• Proofpoint, “Threat Actor Profile: TA505, From Dridex to GlobeImposter,” https://www.proofpoint.com/us/threat-insight/post/threat-actor-profile-ta505-dridex-globeimposter, accessed 6 February 2019.
• Roland Dela Paz and Ran Mosessco. “New year, new look – Dridex via compromised FTP,” ForcePoint, 18 January 2018, https://blogs.forcepoint.com/blog/security-labs/new-year-new-look-dridex-compromised-ftp, accessed 4 February 2019.
• Sanghavi, Mithun. “DRIDEX and how to overcome it.” Symantec Official Blog, 30 March 2015, https://community.broadcom.com/symantecenterprise/viewdocument/dridex-and-how-to-overcome-it?CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments, accessed 4 February 2019.
• Security Intelligence Blog, “URSNIF, EMOTET, DRIDEX and BitPaymer Gangs Linked by a Similar Loader,” Trend Micro, 18 December 2018, https://www.trendmicro.com/en_us/research/18/l/ursnif-emotet-dridex-and-bitpaymer-gangs-linked-by-a-similar-loader.html, accessed 6 February 2019.
• Talos Group, “Threat Spotlight: Spam Served With a Side of Dridex,” Cisco Blogs, 6 April 2015, https://blogs.cisco.com/security/talos/spam-dridex, accessed 4 February 2019.

December 5, 2019: Initial version
December 5, 2019: Added links to Treasury and FBI press releases
January 2, 2020: Updated CISA contact information

The Cybersecurity and Infrastructure Security Agency (CISA) is sharing the following information with the cybersecurity community as a primer for assisting in the protection of our Nation’s critical infrastructure in light of the current tensions between the Islamic Republic of Iran and the United States and Iran’s historic use of cyber offensive activities to retaliate against perceived harm. Foremost, CISA recommends organizations take the following actions:

1. Adopt a state of heightened awareness. This includes minimizing coverage gaps in personnel availability, more consistently consuming relevant threat intelligence, and making sure emergency call trees are up to date.
2. Increase organizational vigilance. Ensure security personnel are monitoring key internal security capabilities and that they know how to identify anomalous behavior. Flag any known Iranian indicators of compromise and tactics, techniques, and procedures (TTPs) for immediate response.
3. Confirm reporting processes. Ensure personnel know how and when to report an incident. The well-being of an organization’s workforce and cyber infrastructure depends on awareness of threat activity. Consider reporting incidents to CISA to help serve as part of CISA’s early warning system (see Contact Information section below).
4. Exercise organizational incident response plans. Ensure personnel are familiar with the key steps they need to take during an incident. Do they have the accesses they need? Do they know the processes? Are your various data sources logging as expected? Ensure personnel are positioned to act in a calm and unified manner.

Iranian Cyber Threat Profile

Iran has a history of leveraging asymmetric tactics to pursue national interests beyond its conventional capabilities. More recently, its use of offensive cyber operations is an extension of that doctrine. Iran has exercised its increasingly sophisticated capabilities to suppress both social and political perspectives deemed dangerous to Iran and to harm regional and international opponents.

Iranian cyber threat actors have continuously improved their offensive cyber capabilities. They continue to engage in more “conventional” activities ranging from website defacement, distributed denial of service (DDoS) attacks, and theft of personally identifiable information (PII), but they have also demonstrated a willingness to push the boundaries of their activities, which include destructive wiper malware and, potentially, cyber-enabled kinetic attacks.

The U.S. intelligence community and various private sector threat intelligence organizations have identified the Islamic Revolutionary Guard Corps (IRGC) as a driving force behind Iranian state-sponsored cyberattacks–either through contractors in the Iranian private sector or by the IRGC itself.

Iranian Cyber Activity

According to open-source information, offensive cyber operations targeting a variety of industries and organizations—including financial services, energy, government facilities, chemical, healthcare, critical manufacturing, communications, and the defense industrial base—have been attributed, or allegedly attributed, to the Iranian government. The same reporting has associated Iranian actors with a range of high-profile attacks, including the following:

• Late 2011 to Mid-2013 – DDoS Targeting U.S. Financial Sector: In response to this activity, in March 2016, the U.S. Department of Justice indicted seven Iranian actors employed by companies performing work on behalf of the IRGC for conducting DDoS attacks primarily targeting the public-facing websites of U.S. banks. The attacks prevented customers from accessing their accounts and cost the banks millions of dollars in remediation.[1]
• August/September 2013 – Unauthorized Access to Dam in New York State: In response, in March 2016, the U.S. Department of Justice indicted one Iranian actor employed by a company performing work on behalf of the IRGC for illegally accessing the supervisory control and data acquisition (SCADA) systems of the Bowman Dam in Rye, New York. The access allowed the actor to obtain information regarding the status and operation of the dam.[1]
• February 2014 – Sands Las Vegas Corporation Hacked: Cyber threat actors hacked into the Sands Las Vegas Corporation in Las Vegas, Nevada, and stole customer data, including credit card data, Social Security Numbers, and driver’s license numbers. According to a Bloomberg article from December 2014, the attack also involved a destructive portion, in which the Sands Las Vegas Corporation’s computer systems were wiped. In September 2015, the U.S. Director of National Intelligence identified the Iranian government as the perpetrator of the attack in a Statement for the Record to the House Permanent Select Committee on Intelligence.[2]
• 2013 to 2017 – Cyber Theft Campaign on Behalf of IRGC: In response, in March 2018, the U.S. Justice Department indicted nine Iranian actors associated with the Mabna Institute for conducting a massive cyber theft campaign containing dozens of individual incidents, including “many on behalf of the IRGC.” The thefts targeted academic and intellectual property data as well as email account credentials. According to the indictment, the campaign targeted “144 U.S. universities, 176 universities across 21 foreign countries, 47 domestic and foreign private sector companies, the U.S. Department of Labor, the Federal Energy Regulatory Commission, the State of Hawaii, the State of Indiana, the United Nations, and the United Nations Children’s Fund.”[3]

Recommended Actions

The following is a composite of actionable technical recommendations for IT professionals and providers to reduce their overall vulnerability. These recommendations are not exhaustive; rather they focus on the actions that will likely have the highest return on investment. In general, CISA recommends two courses of action in the face of potential threat from Iranian actors: 1) vulnerability mitigation and 2) incident preparation.

1. Disable all unnecessary ports and protocols. Review network security device logs and determine whether to shut off unnecessary ports and protocols. Monitor common ports and protocols for command and control activity.
2. Enhance monitoring of network and email traffic. Review network signatures and indicators for focused operations activities, monitor for new phishing themes and adjust email rules accordingly, and follow best practices of restricting attachments via email or other mechanisms.  
3. Patch externally facing equipment. Focus on patching critical and high vulnerabilities that allow for remote code execution or denial of service on externally facing equipment.
4. Log and limit usage of PowerShell. Limit the usage of PowerShell to only users and accounts that need it, enable code signing of PowerShell scripts, and enable logging of all PowerShell commands.
5. Ensure backups are up to date and stored in an easily retrievable location that is air-gapped from the organizational network.

Patterns of Publicly Known Iranian Advanced Persistent Threats

The following mitigations and detection recommendations regarding publicly known Iranian advanced persistent threat (APT) techniques are based on the MITRE ATT&CK Framework.

Iranian APT Technique	Mitigation and Detection
Credential Dumping	Mitigation Manage the access control list for "Replicating Directory Changes" and other permissions associated with domain controller replication. Consider disabling or restricting NTLM. Ensure that local administrator accounts have complex, unique passwords across all systems on the network. Limit credential overlap across accounts and systems by training users and administrators not to use the same password for multiple accounts. Detection Windows: Monitor for unexpected processes interacting with Isass.exe. Linux: The AuditD monitoring tool can be used to watch for hostile processes opening a maps file in the proc file system, alerting on the pid, process name, and arguments for such programs.
Obfuscated Files or Information	Mitigation Consider utilizing the Antimalware Scan Interface (AMSI) on Windows 10 to analyze commands after being processed/interpreted. Detection Windows: Monitor for unexpected processes interacting with Isass.exe. Linux: The AuditD monitoring tool can be used to watch for hostile processes opening a maps file in the proc file system, alerting on the pid, process name, and arguments for such programs.
Data Compressed	Mitigation Network intrusion prevention or data loss prevention tools may be set to block specific file types from leaving the network over unencrypted channels. Detection Process monitoring and monitoring for command-line arguments for known compression utilities. If the communications channel is unencrypted, compressed files can be detected in transit during exfiltration with a network intrusion detection or data loss prevention system analyzing file headers.
PowerShell	Mitigation Set PowerShell execution policy to execute only signed scripts. Remove PowerShell from systems when not needed, but a review should be performed to assess the impact to an environment, since it could be in use for many legitimate purposes and administrative functions. Disable/restrict the WinRM Service to help prevent uses of PowerShell for remote execution. Restrict PowerShell execution policy to administrators. Detection If PowerShell is not used in an environment, looking for PowerShell execution may detect malicious activity. Monitor for loading and/or execution of artifacts associated with PowerShell specific assemblies, such as System. Management.Automation.dll (especially to unusual process names/locations). Turn on PowerShell logging to gain increased fidelity in what occurs during execution (which is applied to .NET invocations).
User Execution	Mitigation Application allow listing may be able to prevent the running of executables masquerading as other files. If a link is being visited by a user, network intrusion prevention systems and systems designed to scan and remove malicious downloads can be used to block activity. Block unknown or unused files in transit by default that should not be downloaded or by policy from suspicious sites as a best practice to prevent some vectors, such as .scr., .exe, .pif, .cpl, etc. Use user training as a way to bring awareness to common phishing and spearphishing techniques and how to raise suspicion for potentially malicious events. Detection Monitor the execution of and command-line arguments for applications that may be used by an adversary to gain Initial Access that require user interaction. This includes compression applications, such as those for zip files that can be used to Deobfuscate/Decode Files or Information in payloads. Anti-virus can potentially detect malicious documents and files that are downloaded and executed on the user's computer. Endpoint sensing or network sensing can potentially detect malicious events once the file is opened (such as a Microsoft Word document or PDF reaching out to the internet or spawning Powershell.exe) for techniques such as Exploitation for Client Execution and Scripting.
Scripting	Mitigation Configure Office security settings enable Protected View, to execute within a sandbox environment, and to block macros through Group Policy. Other types of virtualization and application microsegmentation may also mitigate the impact of compromise. Turn off unused features or restrict access to scripting engines such as VBScript or scriptable administration frameworks such as PowerShell. Detection Examine scripting user restrictions. Evaluate any attempts to enable scripts running on a system that would be considered suspicious. Scripts should be captured from the file system when possible to determine their actions and intent. Monitor processes and command-line arguments for script execution and subsequent behavior. Analyze Office file attachments for potentially malicious macros. Office processes, such as winword.exe, spawning instances of cmd.exe, script application like wscript.exe or powershell.exe, or other suspicious processes may indicate malicious activity.
Registry Run Keys/Startup Folder	Mitigation This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features. Detection Monitor Registry for changes to run keys that do not correlate with known software, patch cycles, etc. Monitor the start folder for additions or changes. Tools such as Sysinternals Autoruns may also be used to detect system changes that could be attempts at persistence, including listing the run keys' Registry locations and startup folders. To increase confidence of malicious activity, data and events should not be viewed in isolation, but as part of a chain of behavior that could lead to other activities, such as network connections made for Command and Control, learning details about the environment through Discovery, and Lateral Movement.
Remote File Copy	Mitigation Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware or unusual data transfer over known tools and protocols like FTP can be used to mitigate activity at the network level. Detection Monitor for file creation and files transferred within a network over SMB. Monitor use of utilities, such as FTP, that does not normally occur. Analyze network data for uncommon data flows (e.g., a client sending significantly more data than it receives from a server). Analyze packet contents to detect communications that do not follow the expected protocol behavior for the port that is being used.
Spearphishing Link	Mitigation Determine if certain websites that can be used for spearphishing are necessary for business operations and consider blocking access if activity cannot be monitored well or if it poses a significant risk. Users can be trained to identify social engineering techniques and spearphishing emails with malicious links. Detection URL inspection within email (including expanding shortened links) can help detect links leading to known malicious sites. Detonation chambers can be used to detect these links and either automatically go to these sites to determine if they're potentially malicious, or wait and capture the content if a user visits the link.
Spearphishing Attachment	Mitigation Anti-virus can automatically quarantine suspicious files. Network intrusion prevention systems and systems designed to scan and remove malicious email attachments can be used to block activity. Block unknown or unused attachments by default that should not be transmitted over email as a best practice to prevent some vectors, such as .scr, .exe, .pif, .cpl, etc. Some email scanning devices can open and analyze compressed and encrypted formats, such as zip and rar that may be used to conceal malicious attachments in Obfuscated Files or Information. Users can be trained to identify social engineering techniques and spearphishing emails. Detection Network intrusion detection systems and email gateways can be used to detect spearphishing with malicious attachments in transit. Detonation chambers may also be used to identify malicious attachments. Solutions can be signature and behavior based, but adversaries may construct attachments in a way to avoid these systems. Anti-virus can potentially detect malicious documents and attachments as they're scanned to be stored on the email server or on the user's computer.

CISA encourages recipients of this report to contribute any additional information that they may have related to this threat. For any questions related to this report, please contact CISA at

• 1-888-282-0870 (From outside the United States: +1-703-235-8832)
• central@cisa.dhs.gov (UNCLASS)

CISA encourages you to report any suspicious activity, including cybersecurity incidents, possible malicious code, software vulnerabilities, and phishing-related scams. Reporting forms can be found on the CISA homepage.

January 6, 2019: Initial version
October 23, 2020

Unpatched Pulse Secure VPN servers continue to be an attractive target for malicious actors. Affected organizations that have not applied the software patch to fix an arbitrary file reading vulnerability, known as CVE-2019-11510, can become compromised in an attack.[1]

Although Pulse Secure [2] disclosed the vulnerability and provided software patches for the various affected products in April 2019, the Cybersecurity and Infrastructure Security Agency (CISA) continues to observe wide exploitation of CVE-2019-11510.[3],[4],[5]

CISA expects to see continued attacks exploiting unpatched Pulse Secure VPN environments and strongly urges users and administrators to upgrade to the corresponding fixes.[2]

Timelines of Specific Events

• April 24, 2019 – Pulse Secure releases initial advisory and software updates addressing multiple vulnerabilities.
• May 28, 2019 – Large commercial vendors get reports of vulnerable VPN through HackerOne.
• July 31, 2019 – Full use of exploit demonstrated using the admin session hash to get complete shell.
• August 8, 2019 – Meh Chang and Orange Tsai demonstrate the VPN issues across multiple vendors (Pulse Secure) with detailed attack on active VPN exploitation.
• August 24, 2019 – Bad Packets identifies over 14,500 vulnerable VPN servers globally still unpatched and in need of an upgrade.
• October 7, 2019 – The National Security Agency (NSA) produces a Cybersecurity Advisory on Pulse Secure and other VPN products being targeted actively by advanced persistent threat actors.
• October 16, 2019 – The CERT Coordination Center (CERT/CC) releases Vulnerability Note VU#927237: Pulse Secure VPN contains multiple vulnerabilities.
• January 2020 – Media reports cybercriminals now targeting unpatched Pulse Secure VPN servers to install REvil (Sodinokibi) ransomware.   

A remote, unauthenticated attacker may be able to compromise a vulnerable VPN server. The attacker may be able to gain access to all active users and their plain-text credentials. It may also be possible for the attacker to execute arbitrary commands on each VPN client as it successfully connects to the VPN server.

Affected versions:

• Pulse Connect Secure 9.0R1 - 9.0R3.3
• Pulse Connect Secure 8.3R1 - 8.3R7
• Pulse Connect Secure 8.2R1 - 8.2R12
• Pulse Connect Secure 8.1R1 - 8.1R15
• Pulse Policy Secure 9.0R1 - 9.0R3.1
• Pulse Policy Secure 5.4R1 - 5.4R7
• Pulse Policy Secure 5.3R1 - 5.3R12
• Pulse Policy Secure 5.2R1 - 5.2R12
• Pulse Policy Secure 5.1R1 - 5.1R15

This vulnerability has no viable workarounds except for applying the patches provided by the vendor and performing required system updates.

CISA strongly urges users and administrators to upgrade to the corresponding fixes.[2]

January 10, 2020: Initial Version
April 15, 2020: Revised to correct type of vulnerability.

New vulnerabilities are continually emerging, but the best defense against attackers exploiting patched vulnerabilities is simple: keep software up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats.

On January 14, 2020, Microsoft released software fixes to address 49 vulnerabilities as part of their monthly Patch Tuesday announcement. Among the vulnerabilities patched were critical weaknesses in Windows CryptoAPI, Windows Remote Desktop Gateway (RD Gateway), and Windows Remote Desktop Client. An attacker could remotely exploit these vulnerabilities to decrypt, modify, or inject data on user connections:

• CryptoAPI spoofing vulnerability – CVE-2020-0601: This vulnerability affects all machines running 32- or 64-bit Windows 10 operating systems, including Windows Server versions 2016 and 2019. This vulnerability allows Elliptic Curve Cryptography (ECC) certificate validation to bypass the trust store, enabling unwanted or malicious software to masquerade as authentically signed by a trusted or trustworthy organization. This could deceive users or thwart malware detection methods such as antivirus. Additionally, a maliciously crafted certificate could be issued for a hostname that did not authorize it, and a browser that relies on Windows CryptoAPI would not issue a warning, allowing an attacker to decrypt, modify, or inject data on user connections without detection.
• Windows RD Gateway and Windows Remote Desktop Client vulnerabilities – CVE-2020-0609, CVE-2020-0610, and CVE-2020-0611: These vulnerabilities affect Windows Server 2012 and newer. In addition, CVE-2020-0611 affects Windows 7 and newer. These vulnerabilities—in the Windows Remote Desktop Client and RD Gateway Server—allow for remote code execution, where arbitrary code could be run freely. The server vulnerabilities do not require authentication or user interaction and can be exploited by a specially crafted request. The client vulnerability can be exploited by convincing a user to connect to a malicious server.

The Cybersecurity and Infrastructure Security Agency (CISA) is unaware of active exploitation of these vulnerabilities. However, because patches have been publicly released, the underlying vulnerabilities can be reverse-engineered to create exploits that target unpatched systems.

CISA strongly recommends organizations install these critical patches as soon as possible—prioritize patching by starting with mission critical systems, internet-facing systems, and networked servers. Organizations should then prioritize patching other affected information technology/operational technology (IT/OT) assets.

CryptoAPI Spoofing Vulnerability – CVE-2020-0601

A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates ECC certificates.

According to Microsoft, “an attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source. The user would have no way of knowing the file was malicious, because the digital signature would appear to be from a trusted provider.” Additionally, “a successful exploit could also allow the attacker to conduct man-in-the-middle attacks and decrypt confidential information on user connections to the affected software.”[1]

A cyber attacker could exploit CVE-2020-0601 to obtain sensitive information, such as financial information, or run malware on a targeted system; for example:

• A maliciously crafted certificate could appear to be issued for a hostname that did not authorize it, preventing a browser that relies on Windows CryptoAPI from validating its authenticity and issuing warnings. If the certificate impersonates a user’s bank website, their financial information could be exposed.
• Signed malware can bypass protections (e.g., antivirus) that only run applications with valid signatures. Malicious files, emails, and executables can appear legitimate to unpatched users.

The Microsoft Security Advisory for CVE-2020-0601 addresses this vulnerability by ensuring that Windows CryptoAPI completely validates ECC certificates.

Detection Measures

The National Security Agency (NSA) provides detection measures for CVE-2020-0601 in their Cybersecurity Advisory: Patch Critical Cryptographic Vulnerability in Microsoft Windows Clients and Servers.[2]

Windows RD Gateway Vulnerabilities – CVE-2020-0609/CVE-2020-0610

According to Microsoft, “A remote code execution vulnerability exists in Windows Remote Desktop Gateway (RD Gateway) when an unauthenticated attacker connects to the target system using RDP and sends specially crafted requests. This vulnerability is pre-authentication and requires no user interaction.”[3],[4]

CVE-2020-0609/CVE-2020-0610:

• Affects all supported Windows Server versions (Server 2012 and newer; support for Server 2008 ends January 14, 2020);
• Occurs pre-authentication; and
• Requires no user interaction to perform.

The Microsoft Security Advisories for CVE-2020-0609 and CVE-2020-0610 address these vulnerabilities.

Windows Remote Desktop Client Vulnerability – CVE-2020-0611

According to Microsoft, “A remote code execution vulnerability exists in the Windows Remote Desktop Client when a user connects to a malicious server. An attacker who successfully exploited this vulnerability could execute arbitrary code on the computer of the connecting client.”[5]

CVE-2020-0611 requires the user to connect to a malicious server via social engineering, Domain Name Server (DNS) poisoning, a man-in the-middle attack, or by the attacker compromising a legitimate server.

The Microsoft Security Advisory for CVE-2020-0611 addresses this vulnerability.

 

Impact

A successful network intrusion can have severe impacts, particularly if the compromise becomes public and sensitive information is exposed. Possible impacts include:

• Temporary or permanent loss of sensitive or proprietary information,
• Disruption to regular operations,
• Financial losses relating to restoring systems and files, and
• Potential harm to an organization’s reputation.

 

CISA strongly recommends organizations read the Microsoft January 2020 Release Notes page for more information and apply critical patches as soon as possible—prioritize patching by starting with mission critical systems, internet-facing systems, and networked servers. Organizations should then prioritize patching other affected IT/OT assets.

General Guidance

• Review Guide to Enterprise Patch Management Technologies, NIST Special Publication 800-40 Revision 3. Patch management is the process for identifying, acquiring, installing, and verifying patches for products and systems. This publication is designed to assist organizations in understanding the basics of enterprise patch management technologies. It explains the importance of patch management and examines the challenges inherent in performing patch management. It provides an overview of enterprise patch management technologies, and also briefly discusses metrics for measuring the technologies’ effectiveness.
• Review CISA Insights publications. Informed by U.S. cyber intelligence and real-world events, each CISA Insight provides background information on particular cyber threats and the vulnerabilities they exploit, as well as a ready-made set of mitigation activities that non-federal partners can implement. Printable materials can be found by visiting: https://www.cisa.gov/publication/cisa-insights-publications.
• Review CISA’s Cyber Essentials. CISA’s Cyber Essentials is a guide for leaders of small businesses as well as leaders of small and local government agencies to develop an actionable understanding of where to start implementing organizational cybersecurity practices. Essentials are the starting point to cyber readiness. To download the guide, visit: https://www.cisa.gov/publication/cisa-cyber-essentials.

January 14, 2020: Initial version|January 14, 2020: Minor technical edits

Summary

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.

Table 1. Reconnaissance

Technique Title	ID	Use
Gather Victim Organization Information	T1591	Threat actors use information available on the internet to determine what systems they believe they have compromised and post the information on their social media. This methodology frequently leads to the threat actors misidentifying their claimed victims.
Active Scanning: Vulnerability Scanning	T1595.002	Threat actors use open source tools to look for IP addresses in target countries with visible VNC services on common ports.

Table 2. Resource Development

Technique Title	ID	Use
Acquire Infrastructure: Virtual Private Server	T1583.003	Threat actors use virtual infrastructure to obfuscate identifiers.

Table 3. Initial Access

Technique Title	ID	Use
Internet Accessible Device	T0883	Threat actors gain access through less secure HMI devices exposed to the internet.

Table 4. Persistence

Technique Title	ID	Use
Valid Accounts	T0859	Threat actors use password guessing tools to access legitimate accounts on the HMI devices.

Table 5. Credential Access

Technique Title	ID	Use
Brute Force: Password Spraying	T1110.003	Threat actors use tools to rapidly guess common or simple passwords.

Table 6. Lateral Movement

Technique Title	ID	Use
Default Credentials	T0812	Threat actors seek and build libraries of known default passwords for control devices to access legitimate user accounts.
Remote Services	T0886	Threat actors leverage VNC services to access system HMI devices.
Remote Services: VNC	T1021.005	Threat actors hunt VNC-enabled devices visible on the internet and connect with remote viewer software.

Table 7. Execution

Technique Title	ID	Use
Graphical User Interface	T0823	Threat actors interact with HMI devices via GUIs, attempting to modify control devices.

Table 8. Inhibit Response Function

Technique Title	ID	Use
Device Restart/Shutdown	T0816	While threat actors claim to turn off HMIs, it is possible that operators (not the threat actors) turn the devices off during incident response.
Alarm Suppression	T0878	Threat actors use HMI interfaces to clear alarms caused by their activity and alarms already present on the system at the time of their intrusion.
Change Credential	T0892	Threat actors change the usernames and passwords of HMI devices in operator lockout attempts, usually resulting in a loss of view and operators switching to manual operations.

Table 9. Impair Process Control

Technique Title	ID	Use
Modify Parameter	T0836	Threat actors attempt to change upper and lower limits of operational devices as available from the HMI.
Unauthorized Command Message	T0855	Threat actors attempt to send unauthorized command messages to instruct control system assets to perform actions outside of their intended functionality, causing possible impact.

Table 10. Impact

Technique Title	ID	Use
Loss of Productivity and Revenue	T0828	Threat actors purposefully attempt to impact productivity and create additional costs for the affected entities.
Loss of View	T0829	Threat actors change credentials on HMI devices, preventing operators from modifying processes remotely.
Manipulation of Control	T0831	Threat actors change setpoints in processes, impacting the efficiency of operations for those specific processes.

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 3.S].
  • 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 3.I].
  • 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 2.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 3.A] [CPG 3.B] [CPG 3.C] [CPG 3.F].
  • 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 3.E].
  • 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 3.R].
  • 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 3.G].
• 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 6.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 3.O].
• 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

Advisory at a Glance

Executive Summary	CISA began incident response efforts at a U.S. federal civilian executive branch (FCEB) agency following the detection of potential malicious activity identified through security alerts generated by the agency’s endpoint detection and response (EDR) tool. CISA identified three lessons learned from the engagement that illuminate how to effectively mitigate risk, prepare for, and respond to incidents: vulnerabilities were not promptly remediated, the agency did not test or exercise their incident response plan (IRP), and EDR alerts were not continuously reviewed.
Key Actions	Prevent compromise by prioritizing the patching of critical vulnerabilities in public-facing systems and known exploited vulnerabilities. Prepare for incidents by maintaining, practicing, and updating incident response plans. Prepare for incidents by implementing comprehensive and verbose logging and aggregate logs in a centralized out-of-band location.
Indicators of Compromise	For a downloadable copy of indicators of compromise, see:  AA25-266A-JSON.stix_.json AA25-266A-STIX.stix_.xml
Intended Audience	Organizations: FCEB agencies and critical infrastructure organizations. Roles: Defensive Cybersecurity Analysts, Vulnerability Analysts, Security Systems Managers, Systems Security Analysts, and Cybersecurity Policy and Planning Professionals.
Download the PDF version of this report	AA25-266A advisory cisa shares lessons learned from ir engagement

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: