Advisory at a Glance

Title	A Tale of Two SOCs: Insights From Two Red Team Assessments
Original Publication	August 25, 2026
Executive Summary	The Cybersecurity and Infrastructure Security Agency (CISA) conducted simultaneous red team assessments at two organizations and observed different defensive outcomes. In both environments, the red team achieved full domain compromise and accessed sensitive business systems (SBSs) and cloud resources. Organization A failed to detect or contain the activity, but Organization B rapidly identified initial compromise attempts, isolated affected systems, and forced the red team into an assume breach model. This advisory details the red team’s activity and organizations’ defensive actions, offering lessons learned and mitigations to help critical infrastructure organizations strengthen detection, response, and protections in IT, cloud, and operational technology (OT) environments.
Lessons Learned	Untuned detection tools lead to missed threats. Without well-defined baselines and alert filtering, false positives and routine alerts overwhelm network defenders. Organizational silos and bureaucratic hurdles prevent effective incident response. Detection tools are only as effective as the people, processes, and procedures supporting them; fragmented communication, unclear responsibilities, and limited defender authority hinder effective incident response. Cloud environments are often an underestimated risk. Organizations often lack security controls for cloud environments and processes for responding to a cloud compromise.
Key Actions	Establish and continuously maintain a baseline and reduce alert noise by fine tuning. Break down silos and empower network defenders. Implement Conditional Access policies for workload identities and monitor for excessive or unused permissions. Establish and regularly review comprehensive procedures for detecting, remediating, and revoking access/refresh tokens in the event of a cloud compromise.
Intended Audience	Organizations: Federal Civilian Executive Branch agencies; state, local, tribal, and territorial governments; critical infrastructure. Roles: System administrators, incident responders, defensive cybersecurity analysts, vulnerability analysts, network operators, security systems managers, and all network defenders.

Introduction

The Cybersecurity and Infrastructure Security Agency’s (CISA’s) red team simulates real‑world malicious cyber operations to assess an organization’s ability to detect, investigate, and respond to malicious cyber activity. Emulating cyber threat actor tradecraft, the red team attempts to gain and maintain persistent access to an organization’s network and sensitive business systems (SBSs) while avoiding detection.

CISA conducted two simultaneous red team assessments using similar tradecraft but observed different defensive responses. In one organization (Organization A), the team gained initial access to multiple workstations, gained elevated privileges over the domain, and moved laterally to SBSs and cloud resources undetected. In the second organization (Organization B), network defenders quickly detected the initial compromise and quarantined the affected systems.

Because Organization B detected the initial compromise, the red team moved to an assume breach model, where Organization B trusted agents (TAs) provided access to a host that replicated the level of access the red team would have had if defenders had not detected their activity. From there, the red team escalated privileges and moved laterally to SBSs, cloud resources, and a bastion host in the OT demilitarized zone (DMZ), where defenders again detected activity and isolated the system.

In coordination with the assessed organizations, CISA is releasing this Cybersecurity Advisory to describe the red team’s activity and the organization’s defensive responses and to share lessons learned that critical infrastructure organizations can use to strengthen their IT, cloud, and OT cybersecurity posture.

CISA encourages critical infrastructure organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of malicious cyber incidents.

Download the PDF version of this report:

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 a table of the red team’s activity mapped to MITRE ATT&CK tactics and techniques.

Overview

CISA is authorized—upon request—to provide analyses, expertise, and other technical assistance to critical infrastructure owners and operators and to provide operational and timely technical assistance to federal and non-federal entities, with respect to cybersecurity risks (see generally 6 U.S.C. §§ 652[c][5], 659[c][6]). CISA conducted two concurrent red team assessments: one at a Government Services and Facilities Sector organization (Organization A), and one at a Water and Wastewater Systems Sector organization (Organization B).

During CISA’s red team assessments, the red team simulates malicious cyber operations to assess an organization’s threat detection and response capabilities. The red team attempts to gain and maintain persistent access to an organization’s enterprise network, avoid detection, evade defenses, and access SBSs (applications, data stores, or infrastructure components where compromise would materially impact the organization's operations, finances, or customer data) selected by the organization. For the assessments described in this advisory, the team also attempted to gain access to cloud resources and to demonstrate their ability to access Organization B’s OT systems without actually doing so.

Organization A

Red Team Cyber Threat Activity

Initial Access and Active Directory Discovery

During reconnaissance, CISA’s red team identified a web application with default credentials [T1589.001] for multiple built-in user accounts that allowed the team to send emails from an internal email address. The team used the internal email address to send phishing emails [T1566] and gained initial access to four workstations.

From the workstations, the red team leveraged a modified BloodHound¹ collector, customized to avoid static endpoint detection and response (EDR) signatures, to query and scrape Active Directory (AD) information. This information included AD users [T1087.002], computers [T1018], groups [T1069.002], access control lists, organizational units, and group policy objects (GPOs) [T1615]. The team found that one compromised workstation had the default Machine Account Quota (MAQ) of 10, allowing unprivileged users to add up to 10 computer accounts to the domain.

The red team also queried the organization’s Active Directory Certificate Service (ADCS) certificate templates. Misconfigured ADCS templates are common and can allow low-privileged accounts to request a certificate on behalf of other users and computers, including highly privileged accounts. The team identified multiple templates with an ESC1 misconfiguration, which allows any user to request certificates for all users and computer accounts (see scenario ESC1 in SpecterOp’s Certified Pre-Owned: Abusing Active Directory Certificate Services). The red team exploited the misconfigured MAQ to create a machine account [T1136.002] and then exploited a misconfigured ADCS template to request a certificate for the newly created machine account [T1649]. They could then obtain certificates for any user account, providing means for lateral movement.

Post Exploitation: Privilege Escalation and Lateral Movement

Sensitive Business Systems

After the red team gained elevated privileges over the domain, they began post-exploitation activities and attempted to access SBSs. To access the SBSs, the team needed to identify their network location and security controls.

The team’s plan to achieve SBS access included the following steps:

1. Use previously acquired AD data to identify users and groups related to the SBS.
2. Query system center configuration manager (SCCM) servers to enumerate user-device relationships and identify the workstations assigned to each user [T1033].
3. Move laterally from the SCCM server to the target users’ workstations.
4. Find credential material on the target user’s workstation to access the SBS.
5. Verify administrative access to the SBS would allow compromise of the availability, integrity, and/or confidentiality of the system and its data.

For each SBS, the red team used similar discovery and initial access techniques but unique credential retrieval methods. For SBS 1, a database, the team located cleartext credentials on an administrative user’s workstation providing access to the system [T1552]. For SBS 2, also a database, the red team searched the targeted user’s workstations for connections.json and product-preferences.xml files for a Structured Query Language (SQL) developer tool. The team decrypted these files to obtain the cleartext password to the database [T1552.001]. For SBS 3, an automated processing system, the red team acquired long-lived static Amazon Web Service (AWS) identity and access management (IAM) user credentials saved in configuration files in targeted users’ home directories. These credentials do not expire because the organization had not configured credential expiration or rotation.

For SBS 2 and 3, the red team expanded access beyond users’ physical workstations to include their virtual desktops, which limited their access to the active, interactive sessions held by users. While virtual workstations add security controls, such as segmenting networks of sensitive systems to only allow virtual hosts, they are generally synchronized with a root drive of the distributed file system (DFS). The red team compromised the root DFS drive, granting them access to local files of all users’ virtual desktops, regardless of the existence of an active session. This allowed the team to quickly search for cloud configuration files containing credentials and database connection files for thousands of users.

The red team obtained administrative access to all targeted SBSs without defensive intervention by proxying tools [T1090.001] through compromised workstations and using the collected credentials.

Microsoft Entra Systems

After compromising the target SBSs, the red team attempted to compromise Organization A’s Microsoft cloud environment by compromising Organization A’s Microsoft Entra ID (formerly Azure AD) through applications. The team targeted Entra ID applications with Application permissions, which allow applications to access data without user consent (compared to Delegated permissions, which allow applications to access data with user consent). By compromising an application that had elevated Application permissions, the red team would gain the same permissions as the application because these applications operate outside the scope of traditional conditional access policies (CAPs) that provide controls for user access and activity.

Note: Microsoft’s Conditional Access for workload identities extends traditional CAPs to service principals (SPs) used by applications and governs Application permissions by allowing organizations to broadly apply access policies to applications. Implementing Conditional Access for workload identities would have protected against red team exploiting use of Application permissions; however, the red team never observed an organization using Conditional Access for workload identities.

The team compromised applications and used their permissions by:

1. Enumerating the organization’s cloud resources using the publicly available tools, including AzureHound² and ROADrecon,³ to gather information about applications, their permissions, and their owners [T1526] [T1588.002].
2. Identifying applications with elevated permissions to the Microsoft Graph Resource application programming interface (API), including the following:
   
   1. Mail.Read – Read Outlook emails.
   2. Mail.ReadWrite – Read and write Outlook emails.
   3. Chat.Read.All – Access Teams messages.
   4. Files.Read.All – Access OneDrive.
   5. Application.ReadWrite.All – Add Client Secrets to any application or SP.
   6. AppRoleAssignment.ReadWrite.All – Lets an SP grant itself powerful Graph application permissions such as Chat.Read.All or RoleManagement.ReadWrite.Directory.
3. Identifying the owner of an application with Mail.ReadWrite permissions.
4. Moving laterally to the owner’s machine.
5. Obtaining access to the user’s primary refresh token (PRT).
   
   1. A PRT is a secure artifact specifically issued to Microsoft first-party token brokers to enable single sign-on (SSO) across the applications used on those devices. For more information about PRT, see Microsoft’s Understanding Primary Refresh Token (PRT) in Microsoft Entra ID.
6. Using the PRT to request access and refresh tokens for the targeted application’s owner.
   
   1. Access tokens are short-lived tokens issued by Entra ID that grant a client permission to access specific resources or APIs on behalf of a user.
   2. Refresh tokens are longer-lived tokens issued by Entra ID that allow a client to silently request new access tokens without requiring the user to sign in again.
7. Using the access token to add a new client secret to the target application.
   
   1. A client secret is a confidential string used by the application to authenticate itself to Entra ID during token requests.
8. Using the new client secret to request a new access token for the target application.
9. Impersonating the application by using the access token [T1550.001] to retrieve and review target emails [T1114] via the Microsoft Graph API.

This allowed the red team to review security operations center (SOC) staff emails to see if SOC staff were aware of the compromise.

Organization A’s Response

The organization did not respond effectively to red team activity. The red team observed this during their engagement by accessing SOC personnel emails and moving laterally to SOC workstations where they captured screenshots [T1113], used keyloggers [T1056.001], and retrieved Microsoft Teams messages [T1213.005].

The red team observed that the SOC received medium- and low-severity EDR alerts related to the red team activity but did not respond to them. Thousands of false positive alerts corresponding to normal business operations, many with a higher severity, obscured the alerts triggered by red team activity.

Organizational silos further hindered detection and response. The organization had multiple SOCs and multiple EDR solutions. Staff did not communicate with staff from other SOCs or have visibility on their detection tools. SOC staff and system owners also did not communicate with each other.

This led to SOC staff not actioning alerts from red team activity. For example, red team members noted chat exchanges regarding an SCCM in which defenders tried and failed to identify the system owner, its function, and its typical use. The SOC team eventually flagged the alert as a false positive.

The red team believes this was because the SOC staff lacked standard operating procedures for escalating alerts and had limited personnel authority.

Organization B

Red Team Cyber Threat Activity

Initial Access

The CISA red team gained initial access to Organization B’s environment through a spearphishing campaign. The team gathered email addresses from public websites [T1589.002] and sent phishing emails that eventually led to three users clicking [T1204] on a malicious link, giving the red team access to three workstations.

Each payload execution generated a medium-severity alert: “An executable file loaded an unexpected DLL file.” SOC staff triaged these alerts and manually isolated all three workstations within 10, 2, and 20 minutes. This effectively terminated the team’s command and control (C2) communications with the workstations. Before staff isolated one workstation, the red team enumerated Organization B’s domain’s AD structure by executing various Lightweight Directory Access Protocol (LDAP) queries through the callback. The data gathered included all users, groups, computers, domains, GPO, and subsequent relationships for the entire domain.

Because the defenders removed their initial foothold, the red team switched to an assume breach model. Organization B’s TAs (organization IT staff who knew of the assessment and were in contact with the red team) executed a red-team-provided payload on a designated internal host. This host was associated with a standard user account with no administrative privileges, replicating the same level of access the red team would have maintained if Organization B’s defenders had not detected them.

Domain Compromise

With persistent access to the internal network, the red team searched for ways to escalate their privileges over the domain to facilitate lateral movement and access SBSs. The red team used the assume breach account to query the MAQ attribute of Organization B’s domain and discovered that all domain users were able to add accounts to the domain.

The red team created a new machine account with a hostname designed to resemble a legitimate host. The creation of the machine account provided the red team with a domain account and a password that they controlled. This allowed them to execute standalone tools from a red-team-controlled Linux workstation. The tool’s traffic was proxied through the assume breach host, circumventing restrictions imposed by host-based EDR.

The red team did not identify any escalation paths from the AD data; however, enumeration of SCCM distribution points led to the discovery of an XML file with cleartext credentials for a domain service account. AD data showed that the newly acquired service account had outbound object control over almost 1,000 accounts within the domain due to its group membership. Most notably, the service account had AllExtendedRights permission over a domain controller, which enabled the team to conduct a resource-based constrained delegation attack, granting them DCSync privileges [T1003.006] and the ability to obtain AD account credentials. The team used these credentials throughout the remainder of their assessment to access servers and workstations. One of the first accounts the red team DCSynced was the krbtgt account, which a malicious cyber actor could use to forge Golden Tickets that allow for impersonation of any user in Organization B’s domain.

Post Exploitation

Sensitive Business Systems

The TAs provided the names of two SBSs, one of which the red team successfully compromised. To do this, the team reviewed previously collected BloodHound data and identified a user account with access to an SBS web server that allowed Kerberos authentication. Because the red team had already compromised the on-premises (on-prem) AD environment, they could impersonate this user to access the server.

The team:

1. Used DCSync to acquire the user’s AES256 password hash.
2. Used the password hash to request a Kerberos ticket-granting ticket (TGT) for the user.
3. Used the TGT to request a Kerberos service ticket [T1558] for the web server’s service principal name (SPN).

After requesting the Kerberos service ticket, the red team imported it into a Windows virtual machine (VM) on their infrastructure. The red team configured their VM to proxy any traffic to Organization B’s network through a SOCKS proxy that tunneled traffic through a compromised host.

Operational Technology Network

The red team wanted to gain visibility of the OT network and identify OT network subnets. To do this, they first identified an IT workstation with Remote Desktop Protocol (RDP) files, including a file named ics-[redacted]-org, signifying that the user likely had remote access to the OT network. The red team identified that the workstation had remote access to a bastion host. A bastion host—sometimes referred to as a jump box or jump server—is a specialized, highly secured system (often a server or dedicated workstation) that serves as the sole access point between a network segment (such as an internal IT network) and a protected internal network (like an OT environment).

The red team gained access to this bastion host using File Transfer Protocol (FTP) credentials to log in over Secure Shell (SSH) [T1021.004]. At this point, they had visibility over the OT network.

They attempted to gain a C2 session on the server by dropping several payload files on the host and executing them. However, the callback never reached red team infrastructure because the host blocked outbound internet connections. The payload execution triggered an alert that led SOC staff to quarantine the host.

Microsoft Entra Systems

The red team attempted to access Organization B’s cloud-based Entra ID infrastructure to find a way to move from on-prem AD to the cloud. Organization B had a hybrid environment, and user credentials automatically synchronized between on-prem AD and cloud Entra ID. Given this, the red team looked for the on-prem server responsible for synchronization.

Entra ID Connect (formerly Azure AD Connect) sets up an on-prem account with the prefix MSOL_ to synchronize credentials with Entra ID. The red team used the open source tool ADConnectDump⁴  to obtain cleartext credentials for the on-prem Microsoft Online (MSOL) account and the Entra ID account Sync_[redacted] [T1003]. With cleartext credentials for Sync_[redacted], the red team logged into the Azure portal. Sync_[redacted] was not intended for interactive logins and, in this case, did not have multifactor authentication (MFA) enabled. However, the red team used this account to obtain access tokens for use with AzureHound and ROADrecon to gather Entra ID data for Organization B’s tenant.

Note: The red team obtained cleartext MSOL credentials and logged into the Azure portal because MSOL accounts used to have a large number of permissions; Microsoft has since removed these permissions. See Microsoft’s Action required: MSOnline and AzureAD PowerShell retirement - 2025 info and resources and Important update: Deprecation of Azure AD PowerShell and MSOnline PowerShell modules for more information.

The interactive login from Sync_[redacted] triggered an automated alert from Microsoft, which sent the information to Organization B’s SOC staff, who then blocked the suspicious activity.

The red team identified a computer account containing AZURESSO in its name, located in the on-prem AD environment. This account is part of the Seamless SSO implementation and allows users to use Kerberos tickets as the first step in authenticating to Entra ID. To abuse Seamless SSO, the red team acquired encrypted credentials of a target user via DCSync and then used the Rubeus “asktgs” module to request service tickets used for SSO. The red team imported the service tickets to their workstation and proxied their traffic through Organization B’s network using a SOCKS proxy. This allowed them to browse to https://portal[.]azure[.]com, while using legitimate Kerberos tickets, and the traffic appeared to originate from a trusted IP address.

This approach allowed the red team to gain access to Entra ID as any user synced to AD without the user’s cleartext password. However, they could only use Kerberos tickets for the first phase of the sign-in process. If a user was set up to use MFA, then Entra ID would prompt the red team for a second factor during the sign-in process. Therefore, the red team was only able to log into any Entra ID account that did not have MFA enabled, which seemed limited to service accounts. They reviewed the previously obtained Entra ID data and looked for applications that had excessive permissions and were accessible to AD-synced service accounts.

The red team identified an application that had permission to read, write, and send emails for all users within Organization B’s tenant. The application was owned by an AD-Synced account that was disabled in AD. Using a compromised host in the on-prem environment, they re-enabled this account, DCSynced its credentials, and used the AES256 hash to request Kerberos tickets. The red team used the tickets to authenticate to Entra ID and were then able to add a client secret to the application. This gave them the ability to retrieve the emails of every user within Organization B’s environment from the public internet.

Organization B’s Response

Organization B quickly triaged and responded to alerts after the red team gained initial access, effectively terminating the team’s C2 communications with the workstations and leading the red team to move to an assume breach model. These actions demonstrated a mature, proactive security posture and helped prevent wider compromise.

When the red team gained access to a bastion host in the OT DMZ, Organization B had defensive controls that blocked outbound connections to red team infrastructure, and SOC staff quickly triaged and responded to an alert by isolating the host.

When the red team logged into the organization’s Azure portal via a compromised account, it triggered an automated alert from Microsoft, which led the staff to block the suspicious account. In addition, Organization B had custom detections Entra ID Risky User Alerts for “Unfamiliar sign-in properties” and “Suspicious API traffic” that alerted to the AzureHound user agent and to accounts exceeding predefined request thresholds to the Microsoft Graph API.

See Table 1 for Organization B’s defensive measures and associated response.

Table 1. Red Team Activity and Organization B SOC Response

Red Team Activity	Defensive Measure	SOC Response	Outcome
C2 payload executed on a workstation.	Payload execution generated a medium-severity alert.	Staff quarantined workstation; staff analyzed and reimaged before putting workstation back online.	Red team lost access to a workstation.
C2 payload executed on a second workstation.	Payload execution generated a medium-severity alert.	Staff quarantined workstation; staff analyzed and reimaged before putting workstation back online.	Red team lost access to a workstation.
C2 payload executed on a third workstation.	Payload execution generated a medium-severity alert.	Staff quarantined workstation; staff analyzed and reimaged before putting workstation back online.	Red team lost access to a workstation.
C2 payload executed on bastion host in the OT DMZ.	Payload execution generated alerts.	Staff quarantined the host.	Red team lost access to the host.
Used compromised Entra ID account to log into Azure.	Automated alert from Microsoft.	Staff blocked the account.	Red team compromised a different account and accessed Entra ID by abusing Seamless SSO.

Despite these strengths, Organization B had areas for improvement. The red team was eventually able to access Entra ID through a computer account that was part of the organization’s Seamless SSO implementation. The account did not have MFA and had overly permissive application permissions, indicating the need for more mature cloud security processes.

Additionally, Organization B had excessive permissions and misconfigurations in AD and service accounts, which the red team leveraged for privilege escalation. This highlights the importance of regular audits and strict enforcement of least privilege principles. Organization B could improve credential hygiene, as the red team found credentials for OT systems stored in plaintext on jump servers. Finally, while segmentation and egress controls were effective, ongoing review and tightening of IT/OT connectivity and access architectures would reduce opportunities for lateral movement.

Lessons Learned

The red team identified lessons learned based on each organization’s response. Organization A and Organization B contrasted significantly in their ability to quickly identify and respond to red team activity. However, similar gaps in both organizations contributed to the red team’s compromise of their cloud systems.

Untuned Detection Tools Lead to Missed Threats

Organization A did not tune their detection tools to reduce alert noise, leading to an unmanageable level of alerts for SOC staff to review and action. The same red team activity that triggered alerts and action for Organization B led to no response for Organization A because SOC staff did not identify the activity as potentially malicious amid the overwhelming volume of alerts. Organization B had an established baseline and a fine-tuned alert system, allowing defenders to effectively filter out routine business activity and false positives. As a result, anomalies stood out, enabling the SOC staff to quickly detect and respond to red team activity.

Without well-defined baselines and alert filtering, false positives and routine alerts overwhelm defenders, obscuring real threats. Organizations that tune alerts to highlight anomalies and filter out normal business activity enable defenders to focus on genuine incidents and respond rapidly.

Organizational Silos and Bureaucratic Hurdles Prevent Effective Incident Response

In Organization A, lack of communication and visibility created by organizational silos (among multiple SOCs and between SOC staff and system owners) hindered effective incident response, resulting in missed opportunities for identification of a major breach.

Bureaucratic barriers arose because SOC staff managed systems without understanding their authorities as responsibilities and authorities varied across network segments. They had no escalation procedures and so defaulted to a “wait and see” approach.

In contrast, Organization B empowered its defenders to act decisively. Staff quickly triaged alerts, investigated root causes, identified misconfigurations, and coordinated remediation with engineering.

Detection tools are only as effective as the people, processes, and procedures supporting them. SOC staff should not operate in silos and should have clear authority unhindered by bureaucracy to effectively contain and resolve incidents.

Organizations Underestimate Risks in Cloud Environments

Both organizations underestimated the risks associated with cloud environments. They granted excessive permissions to cloud applications, allowing the red team to access cloud systems. They also lacked fully mature, defined processes for detecting and remediating compromise of cloud environments, allowing the red team to maintain access to cloud resources.

Use of Long-Lived User Identity and Access Management Credentials

Organization A used long-lived static IAM user credentials that were set to never expire. If a malicious actor obtains them, they will have all the user permissions, potentially enabling persistent, unrestricted access to the cloud environment.

Excessive Permissions

Both organizations lacked Conditional Access for workload identities. This feature extends Conditional Access beyond user accounts, covering non-human identities, such as applications. It allows organizations to broadly apply access policies to applications that control how and when the application is used to access resources. Instead, both organizations used broad application permissions for most apps, which the team was able to exploit for access to the environment. In both organizations, the team was able to exploit excessive permissions to read emails.

Lack of Mature Remediation Processes for Tokens

Both organizations lacked processes for revoking compromised access/refresh tokens. Without a well-defined, efficient process for remediating and revoking access/refresh tokens following a cloud compromise, malicious cyber actors evicted from on-prem environments may still leverage cloud access to regain entry. Organizations should establish mature procedures to detect and remediate compromises of cloud environments to prevent malicious cyber actors from reestablishing access.

Issues

The red team identified the following issues that contributed to their ability to maintain persistent access to Organization A and/or B and escalate privileges or move laterally:

• Misconfigured ADCS templates.
  
  • In Organization A, the red team identified and exploited a certificate template with common template misconfiguration known as ESC1, an overly permissive certificate template where the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is enabled and low-privileged users can request certificates. This allows malicious actors to impersonate users. See SpecterOp’s Certified Pre-Owned: Abusing Active Directory Certificate Services for information about the ESC1 misconfiguration.
• Workstations where MAQ was misconfigured.
  
  • In Organization A, the team gained access to a workstation where the MAQ was set to the default value of 10. This meant that unprivileged users could add up to 10 computer accounts to the domain.
  • In Organization B, the MAQ was set to 1,000 for all domain users, allowing any user to create a large number of machine accounts.
• Service accounts with excessive permissions.
  
  • In Organization B, the red team identified a domain service account with AllExtendedRights permission over a domain controller. AllExtendedRights enables malicious cyber actors to perform DCsync attacks and potentially impersonate any account in the domain, leading to full domain compromise.
• Cleartext credentials.
  
  • In Organization A, the red team found and used cleartext credentials to obtain administrative access to SBSs.
  • In Organization B, the red team identified a cleartext password in an XML file for a domain service account.
• Endpoint management systems that lacked additional security controls.
  
  • In Organization A, the red team moved laterally from the SCCM server to users’ workstations. SCCM and other endpoint configuration managers (e.g., Jamf, BigFix) have broad administrative reach and are Tier 0 assets. If compromised, Tier 0 assets provide malicious actors with powerful escalation paths and control over the enterprise.

The red team identified an additional issue that was not exploited during the assessment but could be exploited by malicious cyber actors:

• AD misconfigurations and user accounts with excessive permissions.
  
  • In Organization B, the red team discovered that standard user accounts were improperly assigned to privileged administrative groups within the AD.

MITRE ATT&CK Tactics and Techniques

See Table 2 to Table 11 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 2. Reconnaissance

Technique Title	ID	Use
Gather Victim Identity Information: Credentials	T1589.001	The red team performed reconnaissance and identified a web application with default credentials.
Gather Victim Identity Information: Email Addresses	T1589.002	The red team performed reconnaissance and gathered employee email addresses from public websites.

Table 3. Resource Development

Technique Title	ID	Use
Obtain Capabilities: Tool	T1588.002	The red team used publicly available tools, including AzureHound and ROADrecon.

Table 4. Initial Access

Technique Title	ID	Use
Phishing	T1566	The red team gained initial access to four Organization A workstations by sending phishing emails from an internal email address. The red team gained initial access to three Organization B workstations via spearphishing emails that eventually led users to click on a malicious payload.

Table 5. Execution

Technique Title	ID	Use
User Execution	T1204	The red team’s spearphishing emails eventually led to users clicking on a malicious payload.

Table 6. Persistence

Technique Title	ID	Use
Create Account: Domain Account	T1136.002	The red team exploited misconfigured MAQs to create machine accounts on a workstation.

Table 7. Credential Access

Technique Title	ID	Use
Unsecured Credentials	T1552	The red team located cleartext credentials on an administrative user’s workstation. The red team used the open source tool ADConnectDump to obtain cleartext credentials for cloud accounts.
Unsecured Credentials: Credentials In Files	T1552.001	The red team searched a targeted user’s workstations for connections.json and product-preferences.xml files for a SQL Developer tool. They then decrypted these files to obtain cleartext password to the database. The red team acquired long-lived static AWS IAM user credentials in configuration files in users’ home directories.
OS Credential Dumping	T1003	The red team obtained cleartext credentials for an on-prem MSOL account and Entra account.
OS Credential Dumping: DCSync	T1003.006	The red team used DCSync to obtain AD account credentials.
Steal or Forge Authentication Certificates	T1649	The red team could obtain certificates for any Organization A user account. This provided the means for lateral movement.
Steal or Forge Kerberos Tickets	T1558	The red team used a Kerberos TGT to request a Kerberos service ticket for a web server’s SPN. The red team used the Rubeus “asktgs” module to request service tickets used for SSO.

Table 8. Discovery

Technique Title	ID	Use
Account Discovery: Domain Account	T1087.002	The red team used a BloodHound collector to query and scrape AD information, including AD users.
Remote System Discovery	T1018	The red team used a BloodHound collector to query and scrape AD information, including computers.
Permission Groups Discovery: Domain Groups	T1069.002	The red team used a BloodHound collector to query and scrape AD information, including groups.
Group Policy Discovery	T1615	The red team used a BloodHound collector to query and scrape AD information, including GPOs.
System Owner/User Discovery	T1033	The red team queried SCCM servers to enumerate user-device relationships and identify the workstations assigned to users.
Cloud Service Discovery	T1526	The red team used publicly available tools to obtain a list of Entra applications, their permissions, and their owners.

Table 9. Lateral Movement

Technique Title	ID	Use
Use Alternate Authentication Material: Application Access Token	T1550.001	The red team used an application access token to access and review cloud emails.
Remote Services: SSH	T1021.004	The red team used FTP credentials to log into a bastion host over SSH.

Table 10. Collection

Technique Title	ID	Use
Email Collection	T1114	The red team reviewed Organization A SOC staff cloud emails to see if SOC staff were aware of the compromise. The red team had the ability to retrieve the emails of every user within Organization B’s environment from the public internet.
Screen Capture	T1113	The red team took screenshots of SOC staff workstations.
Input Capture: Keylogging	T1056.001	The red team used keyloggers on SOC staff workstations.
Data from Information Repositories: Messaging Applications	T1213.005	The red team pulled Microsoft Teams messages from SOC staff workstations.

Table 11. Command and Control

Technique Title	ID	Use
Proxy: Internal Proxy	T1090.001	The red team proxied through compromised workstations.

Mitigations

CISA recommends that organizations implement the mitigations below to strengthen their cybersecurity posture based on the Lessons Learned and identified Issues. 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.

Establish Baselines and Improve Monitoring

• Establish and continuously maintain a baseline of installed tools and software, account behavior, and network traffic.
• Reduce alert noise by refining monitoring tools and alerting mechanisms to differentiate between typical administrative actions and potential threat behavior.
  
  • For information on establishing a baseline and reducing alert noise, see CISA’s joint Guidance Identifying and Mitigating Living Off the Land Techniques.

Eliminate Silos and Bureaucratic Hurdles

• Break down silos by encouraging regular communication and collaboration between IT, security, and business units.
  
  • Consider using joint exercises, shared tools, and creating cross-functional teams.
  • Integrate detection with incident response workflows to enable rapid containment and remediation.
• Empower network defenders.
  
  • Develop and communicate policies [CPG 1.A, CPG 1.B] that support rapid, coordinated response and clarify when defenders can act independently versus when escalation is required.
    
    • Define clear roles and responsibilities so defenders know their authorities and escalation paths (if needed) during incidents.
    • Grant defenders the authority to take necessary actions (e.g., isolating systems, blocking traffic) without excessive approvals.
  • Conduct training and simulated incident response exercises to reinforce roles, improve coordination, and identify gaps in authorities or communication [CPG 6.A].

Enhance Cloud Security Controls

Note: While both organizations used Microsoft Entra ID and Organization B also used AWS, many of the techniques used by the red team are applicable across identity providers and cloud environments and not necessarily unique to Microsoft and AWS. CISA encourages all organizations using cloud environments to implement the recommendations below.

• Secure and monitor access/refresh tokens and establish and regularly review comprehensive procedures for detecting, remediating, and revoking access/refresh tokens in the event of a cloud compromise.
  
  • Implement automated token revocation and access reviews and conduct periodic incident response exercises to validate the effectiveness of these processes.
  • Restrict access based on trusted network locations, device compliance, and risk signals (such as unusual activity or sign-in patterns).
  • Monitor sign-in logs and policy evaluation results for workload identities to detect suspicious activity.
  • Regularly check application permissions; make a risk-informed decision to identify and remove any that are not necessary, so each application only has the access it needs to function.
  • Regularly audit SP credentials and rotate secrets or certificates to reduce exposure.
• Identify and disable legacy accounts.
• Enable phishing-resistant MFA for all user, administrative, and privileged accounts in cloud platforms [CPG 3.F].
• Protect keys and secrets by storing them securely and enforcing mandatory rotation schedules; apply cryptographic boundary controls to internal and third-party credentials.
• Set up automated alerts for suspicious cloud application activity, such as abnormal API calls, and credential activity, such as login attempts from unusual locations.
• Leverage user and entity behavior analytics to analyze and correlate activities across multiple data sources and identify unusual credential or token usage.
• Continuously audit authentication and access logs for signs of replay or unauthorized access.
• Implement just-in-time (JIT) access for privileged accounts, replacing standing administrative rights with temporary, time-bound privilege elevations.

For organizations using Entra ID:

• Monitor and control who has access to application identities.
  
  • Implement CAPs for workload identities and monitor for excessive or unused permissions.
  • Use Microsoft’s app governance to detect and manage risky SPs, which are special accounts used by applications and services. See Microsoft’s OAuth app visibility and insights with app governance - Microsoft Defender for Cloud Apps for more information.
• Integrate Entra ID tenant monitoring with on-prem security operations to promptly identify suspicious activity.
• Regularly review and restrict application permissions (e.g., Mail.Read, Files.Read.All).
  
  • For guidance, see CISA’s Secure Cloud Business Applications (SCuBA) Project, which provides secure configuration baselines for Microsoft 365 (M365), including Microsoft Entra ID.
  • Use CISA’s ScubaGear, a no-cost assessment tool that verifies M365 tenant configuration alignment to the policies described in SCuBA’s secure configuration baselines.
• Use certificate-based authentication certificates for application authentication instead of client secrets, when possible. See Microsoft’s Set Up Microsoft Entra CBA - Microsoft Entra ID.
• Review newly created secrets and/or certificates on existing applications.
• Limit secret lifetimes to a reasonable lifetime.

In AWS environments:

• Mitigate the risks of long-lived IAM user credentials.
  
  • Identify and audit all existing access keys and disable/delete unused or unnecessary keys.
• Require human users to use temporary AWS credentials through SSO.
  
  • Users will assume an IAM role for AWS access and receive temporary credentials that expire within an hour.
  • For more information on accessing AWS using temporary credentials, see Amazon’s documentation Security best practices in IAM and Compare IAM identities and credentials.
• Regularly review the environment to verify no long-lived credentials remain.

Secure Active Directory and Manage Credentials

• Apply secure configurations to ADCS implementations.
  
  • Disable the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag from templates to prevent users from supplying and editing sensitive security settings within these templates.
  • Restrict accounts that can enroll in all certificate templates to only those necessary, especially templates with the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag.
  • Remove FullControl, WriteDacl, and Write property permissions from low-privileged groups, such as domain users, to certificate template objects, where such permissions are not needed.
  • Enforce manager approval for requested certificates.
  • Apply additional guidance from CISA’s joint Guidance Detecting and Mitigating Active Directory Compromises (see Mitigating AD CS compromise, pages 15–16).
• Configure the MAQ to zero unless there is a specific operational need for non-administrative users to create computer accounts; this prevents standard user accounts from creating new machine accounts, reducing opportunities for malicious cyber actors to abuse this privilege.
  
  • If some standard user accounts need to create computer accounts, set MAQ to the lowest possible value and restrict this capability to only users or groups with a business justification.
• Improve credential hygiene.
  
  • Scan network shares and workstations for plaintext credentials and remove any found.
  • Train staff on secure password storage practices and enforce policies prohibiting plaintext password storage.
  • Use encrypted password vaults for storing credentials and limit access to only those who require it.
  • Periodically audit credential stores and access logs for signs of misuse.
• Periodically audit AD permissions for misconfigurations and excessively privileged groups and accounts.
  
  • Implement the principle of least privilege [CPG 3.H].
  • Grant standard user rights for standard user tasks such as email, web browsing, and using line-of-business applications.
  • Periodically audit standard user accounts and minimize privileged access.
  • Periodically audit AD permissions to verify that standard user accounts do not have excessive permissions and have not been added to admin groups.
  • Evaluate which administrative groups should administer specific servers and workstations.
  • Separate administrator accounts from standard user accounts [CPG 3.G].
    
    • Use designated workstations for administrators and standard users and prevent administrators from using admin workstations for non-admin purposes; this would reduce impact of credential theft from a user workstation.
    • Use designated administrative accounts exclusively for admin purposes.
    • If a standard user account needs administrative rights over their workstation, use a separate account that does not have administrative access to other hosts, such as servers.
  • Consider using a privileged access management (PAM) solution to manage access to privileged accounts and resources.
    
    • PAM solutions can log and alert usage to detect unusual activity, which could have alerted the assessed organizations when the red team accessed resources with admin accounts.
    • Note: Treat password vaults associated with PAM solutions as high value assets (HVAs) with additional restrictions and monitoring.
  • Configure time-based access for accounts set at the admin level and higher.
    
    • The just-in-time access method provisions privileged access when needed and can support enforcement of the principle of least privilege, as well as the zero trust model. A network-wide policy automatically disables administrator accounts at the AD level when the account is not needed. When standard user accounts need administrative access, they submit their requests through an automated process that enables access to a system, but only for a set timeframe to support task completion.

Secure Endpoint Configuration Managers

• Treat endpoint management systems (such as SCCM) as HVAs with additional restrictions and monitoring because they provide elevated access to thousands of hosts.

Segment Operational Technology Networks

• Implement strict firewall rules and access controls between IT and OT environments [CPG 3.I].
• Limit jump server access to OT networks and require MFA for all connections.
• Regularly review OT network architecture and access paths to minimize unnecessary connectivity.
• Monitor OT network traffic for signs of lateral movement or unauthorized access.
• Implement change management solutions to track and restrict modifications to OT components.

Validate Security Controls

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

To get started:

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

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

Resources

• Microsoft: Understanding primary refresh token (PRT)
• SpecterOps: Certified pre-owned: Abusing Active Directory Certificate Services

Contact Information

Organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA via CISA’s 24/7 Operations Center at contact@cisa.dhs.gov or 1-844-Say-CISA (1-844-729-2472). 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.

Disclaimer

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

Version History

August 25, 2026: Initial version.

Notes

¹ “SpecterOps / Bloodhound,” GitHub, last modified July 15, 2026, https://github.com/SpecterOps/BloodHound.

² “SpecterOps / AzureHound,” GitHub, last modified June 4, 2026, https://github.com/SpecterOps/AzureHound.

³ “ROADrecon,” GitHub, https://github.com/dirkjanm/ROADtools/tree/master/roadrecon.

⁴ “dirkjanm/adconnectdumb,” GitHub, last modified August 25, 2026, https://github.com/dirkjanm/adconnectdump.

Executive summary

Note: This advisory relates to an active threat to Siemens S7 Series programmable logic controllers (PLCs). However, ongoing PLC targeting activity is broader than Siemens PLCs. All PLC owners and operators should apply relevant mitigations to reduce the risk to their devices and systems. The Siemens-specific content in this advisory should be understood and applied as one subset of the wider threat landscape.

Top Mitigations

• Inventory all Siemens S7 Series programmable logic controllers (PLCs)
• Apply critical security patches 
• Ensure PLCs are not accessible from the Internet
• Strengthen access controls
• Monitor for unauthorized activity
• Harden PLC services, protocols, and ladder logic integrity 
• Hunt for anomalies that may indicate a compromise

The National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), Federal Bureau of Investigation (FBI), Department of Energy (DOE), and Environmental Protection Agency (EPA)—hereafter referred to as the authoring agencies—are releasing this Cybersecurity Advisory to warn owners and operators of industrial control systems (ICSs) of an active cyber threat to Siemens S7 Series PLCs and provide relevant mitigations to protect and defend them. 

The threat actors are conducting reconnaissance and capability development against U.S.-based Siemens PLC installations using AI-generated exploitation scripts disguised as legitimate monitoring tools. The actors leverage Internet scanning services to find Internet-exposed PLCs running outdated software or that are otherwise poorly protected. The U.S. critical infrastructure sectors most targeted by this threat activity include Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities. This is not a theoretical risk—it is an active threat. Depending on the specific circumstances, exploitation of poorly protected PLCs could lead to disruption of critical industrial processes, safety incidents, downtime or equipment damage, compromise of sensitive data, compliance violations, and cascading impacts across interconnected systems. 

The authoring agencies urge all owners and operators of operational technology (OT) systems using Siemens S7 Series and other PLC devices to proactively check their systems:

• are properly protected with all applicable security patches and updates, 
• are isolated from the Internet wherever possible, 
• have strong access controls, and 
• employ security tooling to monitor ICS environments for anomalous or malicious activity.

These mitigations are particularly important for owners and operators who work with third-party service providers or system integrators who may have remote access to PLCs, as the asset owners may not realize that their systems are exposed and at risk.

Technical details

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

Threat actor targeting

Threat actors are actively targeting the following Siemens PLC models:

• S7-200 Series (all CPU variants)
• S7-300 Series (all CPU variants including 314, 315, 317 models)
• S7-400 Series (all CPU variants)
• S7-1200 Series (CPU 1211C, 1212C, 1214C, 1215C, 1217C variants)
• S7-1500 Series (all CPU variants, including F-series safety controllers)

Threat actors are using AI assistance to generate exploitation scripts using publicly available information on these Siemens S7 Series PLCs for initial access, credential access, denial of service, and other objectives. If these PLCs are exposed to the Internet or insufficiently segmented, then threat actors can exploit various critical and high severity known vulnerabilities in these PLCs.

Note: Using AI to generate exploitation scripts represents an evolution in threat actor capabilities, dramatically reducing the technical expertise and time required to develop working ICS exploitation scripts and malicious tools. In addition, AI enables adversaries to rapidly leverage additional attack vectors and adapt to defensive measures. Threat actors can easily collect public information about vulnerabilities and weaknesses, find exposed and exploitable PLCs, and use AI-generated scripts to act on that information. If PLCs are exposed to the Internet, they are at high risk for exploitation. 

Threat actors are leveraging open source industrial automation libraries—specifically snap7.dll/python-snap7—combined with AI-assisted scripting to create custom tools that mimic legitimate OT monitoring solutions. These tools provide read/write access to Siemens S7 Series PLC memory, configuration data, and ladder logic programs via the S7comm protocol.

Threat actor techniques

Threat actors are:

• Using Internet scanning services (e.g., Censys, ZoomEye) to identify Internet-exposed or insufficiently segmented Siemens S7 Series PLCs [T1596.005]
• Rapidly iterating exploit code through AI-assisted development, lowering technical barriers to ICS attacks [T1587.004, T1588.007]
• Taking advantage of insecure credentials to access exposed devices that have unconfigured (default) or minimally configured authentication [T1694]
• Deploying AI-generated Python scripts that incorporate the snap7.dll library from public repositories [T0834] to gain read/write access to the PLC and mimic legitimate tools
• Masquerading malicious scripts as legitimate monitoring tools to evade detection by security teams [T0849]
• Conducting read/write operations on data blocks, potentially for reconnaissance, capability testing, or pre-positioning for effects operations [T0893, T0821]

The authoring agencies assess this activity pattern is likely intended as persistent reconnaissance in targeted sectors and facilities to develop capabilities and prepare to cause operational effects against critical infrastructure. For capability development, actors are testing and refining their exploitation techniques against specific PLC models to improve their ability to compromise the PLCs. To prepare for operational effects, actors are leveraging read access to understand target environments, enabling preparation and positioning for future write operations to cause disruption or other operational impacts.

Potential operational impacts

The U.S. critical infrastructure sectors most targeted by this threat activity include Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities. Additionally, Siemens S7 Series PLCs are used in other sectors, including the Defense Industrial Base (DIB), and could be targeted there as well. Unauthorized access to PLCs could result in:

• Disruption of critical industrial processes affecting production throughput, product quality, and public services
• Safety incidents affecting personnel through manipulation of safety interlocks, emergency shutdown systems, or process parameters
• Equipment damage and extended operational downtime from process upsets, improper sequencing, or forced equipment operation outside design parameters
• Compromise of sensitive operational data, including proprietary process recipes, control strategies, and facility configurations
• Cascading impacts across interconnected systems affecting supply chains, dependent facilities, and integrated business operations
• Regulatory compliance violations and potential liability from process safety management failures

Mitigation actions

Since threat actors are developing capabilities using AI to compromise PLCs using known vulnerabilities, misconfigurations, and other weaknesses and then may use compromised PLCs to interfere with normal operations, the authoring agencies urge organizations to implement comprehensive defense-in-depth strategies, in addition to Common Vulnerabilities and Exposures (CVE) remediation, to protect and defend their PLCs.

Detection opportunities

Organizations should implement detection strategies and hunt for anomalies that may indicate a compromise, focusing on [D3-PM]:

• Anomalous S7comm behavior: Connections from non-engineering workstations, unusual data block access patterns, or write operations outside change windows
• Reconnaissance indicators: Sequential IP scanning on port 102, repeated connection attempts with varying parameters, or enumeration of CPU properties
• Tool artifacts: Snap7.dll library usage outside approved engineering workstations, Python scripts with S7comm functionality, or unauthorized monitoring software installations
• Temporal anomalies: S7comm activity during off-hours, unexpected connection patterns consistent with automated scripting rather than human operators, or configuration changes without corresponding work orders or change tickets
• Geographic anomalies: Connections originating from unexpected countries or IP ranges not associated with vendors or integrators

Preventative hardening actions

To counter threats to PLCs, the authoring agencies recommend all PLC owners and operators follow the mitigations in joint guidance Primary Mitigations to Reduce Cyber Threats to Operational Technology.

To harden Siemens S7 Series PLCs, the authoring agencies strongly urge all owners implement the hardening steps below. Entities that rely on systems integrators or third-party managed service providers should share this advisory with those parties and request implementation of the following mitigations:

1. Conduct an immediate inventory of all Siemens S7 Series PLCs in your environment [D3-HCI]:

• Verify current firmware versions for all S7-200, S7-300, S7-400, S7-1200, and S7-1500 controllers against backup gold copy
• Identify any systems directly or indirectly accessible from untrusted networks
• Map all engineering workstations with Totally Integrated Automation (TIA) Portal, STEP 7, or S7 programming access

2. Apply critical security patches as soon as possible [D3-SU]:

• Update Siemens S7 Series PLC firmware to the latest versions that address known vulnerabilities
• Prioritize Internet-facing or demilitarized zone (DMZ)-resident controllers
• Update TIA Portal and STEP 7 software to current versions
• Consult Siemens ProductCERT advisories for information on known vulnerabilities, along with relevant workarounds and mitigations
• Test all updates in a development environment before production deployment

3. Verify network segmentation and ensure PLCs are NOT accessible from the Internet [D3-NI]:

• Audit firewall rules for any exposed S7comm services (Transmission Control Protocol [TCP] port 102)
• Block TCP port 102 at perimeter firewalls entirely
• Implement a DMZ architecture that separates OT and IT networks
• Deploy unidirectional gateways for data historian connections where appropriate
• Verify there is no unauthorized routing between corporate and industrial networks

4. Review and strengthen access controls [D3-NAM, D3-CH]:

• Restrict TIA Portal/STEP 7 access to authorized engineering workstations only by MAC/IP allowlisting on PLCs
• Enable PLC password protection on all Siemens S7 Series controllers 
• Configure protection levels (such as write protection and read/write protection) on Siemens S7 Series devices
• Remove or change default SNMP community strings
• Implement application allowlisting on all engineering workstations
• Enable multi-factor authentication for all remote access to OT networks

5. Enable comprehensive logging and monitoring [D3-PM, D3-NTA]:

• Deploy ICS-aware intrusion detection (e.g., Claroty, Dragos Platform, Nozomi Networks, or similar)
• Monitor all S7comm traffic on TCP port 102 for connections outside maintenance windows
• Alert on unauthorized PUT/GET operations, especially write commands to data blocks or configuration areas of memory
• Log all TIA Portal/STEP 7 connections to PLCs with timestamps and source IPs
• Establish a baseline for legitimate behavior and configure monitoring tools to alert on deviations
• Monitor for Python processes with snap7.dll library imports on engineering workstations
• Watch for sequential IP scanning patterns or block reads of configuration data

6. Implement S7-specific hardening measures [D3-ACH]:

• Disable web servers on Siemens S7 Series devices if not operationally required
• Disable unused communication protocols (such as Modbus TCP and PROFINET, if they are not required)
• Configure connection resources to limit simultaneous S7comm sessions
• Enable TIA Portal/STEP 7 “complete restart protection” and “know-how protection” features where available
• Evaluate for ladder logic changes in online/offline modes

7. Contact Siemens for model-specific guidance:

• Engage Siemens Technical Support for hardening recommendations specific to your CPU models and firmware versions
• Verify patch compatibility with your specific operational environment and third-party integrations
• Request assistance with protection level configuration and access control implementation

Conclusion

There is an active threat targeting Internet-exposed Siemens S7 Series PLCs. The combination of known vulnerabilities, accessible exploitation libraries, and AI-assisted development creates a high-probability attack scenario against inadequately protected PLC installations. Organizations should treat this Cybersecurity Advisory with urgency and coordinate response efforts across security, engineering, executive leadership, plant operations, and vendor support teams to implement the recommended detection and hardening actions.

Resources

• Primary Mitigations to Reduce Cyber Threats to Operational Technology
• Secure connectivity principles for Operational Technology (OT): How organisations should design, secure, and manage connectivity in OT
• Control System Defense: Know the Opponent

Incident reporting 

U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA and/or the FBI. 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.

Entities required to report incidents to DOE should follow established reporting requirements, as appropriate. For other energy sector inquiries, contact EnergySRMA@hq.doe.gov.

In addition, consider contacting Siemens ProductCERT via https://www.siemens.com/cert or email productcert@siemens.com. 

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

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.

Appendix A: MITRE ATT&CK tactics and techniques

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

Table 1: MITRE ATT&CK tactics and techniques

Tactic	Technique Title	ID	Use
Reconnaissance	Search Open Technical Databases: Scan Databases	T1596.005	Using Internet scanning services to identify Internet-exposed or poorly segmented Siemens S7 Series PLCs
Resource Development	Develop Capabilities: Exploits	T1587.004	Developing exploits for known Siemens S7 Series PLC vulnerabilities
Resource Development	Obtain Capabilities: Artificial Intelligence	T1588.007	Rapidly iterating exploit code through AI-assisted development
Execution	Native API	T0834	Deploying AI-generated Python scripts incorporating the snap7.dll library
Execution	Modify Controller Tasking	T0821	Conducting write operations on data blocks, potentially for pre-positioning for effects operations
Evasion	Masquerading	T0849	Masquerading as legitimate monitoring tools to evade detection
Lateral Movement	Insecure Credentials	T1694	Accessing exposed devices that have unconfigured (default) or minimally configured authentication
Collection	Data from Local System	T0893	Conducting read operations on data blocks, potentially for reconnaissance

Appendix B: MITRE D3FEND countermeasures

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

Table 2: MITRE D3FEND Countermeasures

Countermeasure Title	ID	Description
Hardware Component Inventory	D3-HCI	Conduct an immediate inventory of all Siemens S7 Series PLCs
Software Update	D3-SU	Apply critical security patches as soon as possible
Network Isolation	D3-NI	Verify network segmentation and ensure PLCs are not accessible from the Internet
Network Access Mediation	D3-NAM	Restrict TIA Portal/STEP 7 access to authorized engineering workstations only via MAC/IP allowlisting on PLCs
Credential Hardening	D3-CH	Enable PLC password protection on all S7 controllers Enable multi-factor authentication for all remote access to OT networks
Platform Monitoring	D3-PM	Deploy ICS-aware intrusion detection Alert on unauthorized PUT/GET operations Monitor for unexpected behavior deviations Monitor for snap7.dll library imports Hunt for indicators of compromise
Network Traffic Analysis	D3-NTA	Alert on unexpected S7comm traffic on TCP port 102  Watch for sequential IP scanning patterns
Application Configuration Hardening	D3-ACH	Disable unused web servers and protocols Remove SNMP community strings Watch for ladder logic changes

Notes

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

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