Top Security Breaches 2026-03-17

Auto-generated 2026-03-17T09:00:45.433235+00:00 (UTC)

UNC6426 Exploits nx npm Supply-Chain Attack to Gain AWS Admin Access in 72 Hours

Source: The Hacker News | Published: 2026-03-11T07:31:00+00:00 | Score: 17.921

A threat actor known as UNC6426 leveraged keys stolen following the supply chain compromise of the nx npm package last year to completely breach a victim’s cloud environment within a span of 72 hours.
The attack started with the theft of a developer’s GitHub token, which the threat actor then used to gain unauthorized access to the cloud and steal data.
“The threat actor, UNC6426, then used this

Original: https://thehackernews.com/2026/03/unc6426-exploits-nx-npm-supply-chain.html
Proactive Preparation and Hardening Against Destructive Attacks: 2026 Edition

Source: Threat Intelligence | Published: 2026-03-06T14:00:00+00:00 | Score: 15.801

Written by: Matthew McWhirt, Bhavesh Dhake, Emilio Oropeza, Gautam Krishnan, Stuart Carrera, Greg Blaum, Michael Rudden UPDATE (March 13): Added guidance around abuse or misuse of endpoint / MDM platforms . Background Threat actors leverage destructive malware to destroy data, eliminate evidence of malicious activity, or manipulate systems in a way that renders them inoperable. Destructive cyberattacks can be a powerful means to achieve strategic or tactical objectives; however, the risk of reprisal is likely to limit the frequency of use to very select incidents. Destructive cyberattacks can include destructive malware, wipers, or modified ransomware. When conflict erupts, cyber attacks are an inexpensive and easily deployable weapon. It should come as no surprise that instability leads to increases in attacks. This blog post provides proactive recommendations for organizations to prioritize for protecting against a destructive attack within an environment. The recommendations include practical and scalable methods that can help protect organizations from not only destructive attacks, but potential incidents where a threat actor is attempting to perform reconnaissance, escalate privileges, laterally move, maintain access, and achieve their mission. The detection opportunities outlined in this blog post are meant to act as supplementary monitoring to existing security tools. Organizations should leverage endpoint and network security tools as additional preventative and detective measures. These tools use a broad spectrum of detective capabilities, including signatures and heuristics, to detect malicious activity with a reasonable degree of fidelity. The custom detection opportunities referenced in this blog post are correlated to specific threat actor behavior and are meant to trigger anomalous activity that is identified by its divergence from normal patterns. Effective monitoring is dependent on a thorough understanding of an organization’s unique environment and usage of pre-established baselines. Organizational Resilience While the core focus of this blog post is aligned to technical- and tactical-focused security controls, technical preparation and recovery are not the only strategies. Organizations that include crisis preparation and orchestration as key components of security governance can naturally adopt a “living” resilience posture. This includes: Out-of-Band Incident Command and Communication : Establish a pre-validated, “out-of-band” communication platform that is completely decoupled from the corporate identity plane. This ensures that the key stakeholders and third-party support teams can coordinate and communicate securely, even if the primary communication platform is unavailable. Defined Operational Contingency and Recovery Plans: Establish baseline operational requirements, including manual procedures for vital business functions to ensure continuity during restoration or rebuild efforts. Organizations must also develop prioritized application recovery sequences and map the essential dependencies needed to establish a secure foundation for recovery goals. Pre-Establish Trusted Third-Party Vendor Relationships: Based on the range of technologies and platforms vital to business operations, develop predefined agreements with external partners to ensure access to specialists for legal / contractual requirements, incident response, remediation, recovery, and ransomware negotiations. Practice and Refine the Recovery: Conduct exercises that validate the end-to-end restoration of mission-critical services using isolated, immutable backups and out-of-band communication channels, ensuring that recovery timelines (RTO) and data integrity (RPO) are tested, practiced, and current. Google Security Operations Google Security Operations (SecOps) customers have access to these broad category rules and more under the Mandiant Intel Emerging Threats, Mandiant Frontline Threats, Mandiant Hunting Rules, CDIR SCC Enhanced Data Destruction Alerts rule packs. The activity discussed in the blog post is detected in Google SecOps under the rule names: BABYWIPER File Erasure Secure Evidence Destruction And Cleanup Commands CMD Launching Application Self Delete Copy Binary From Downloads Rundll32 Execution Of Dll Function Name Containing Special Character Services Launching Cmd System Process Execution Via Scheduled Task Dllhost Masquerading Backdoor Writing Dll To Disk For Injection Multiple Exclusions Added To Windows Defender In Single Command Path Exclusion Added to Windows Defender Registry Change to CurrentControlSet Services Powershell Set Content Value Of 0 Overwrite Disk Using DD Utility Bcdedit Modifications Via Command Disabling Crash Dump For Drive Wiping Suspicious Wbadmin Commands Fsutil File Zero Out Recommendations Summary Table 1 provides a high-level overview of guidance in this blog post. Focus Area Description External-Facing Assets Protect against the risk of threat actors exploiting an externally facing vector or leveraging existing technology for unauthorized remote access. Critical Asset Protections Protect specific high-value infrastructure and prepare for recovery from a destructive attack. On-Premises Lateral Movement Protections Protect against a threat actor with initial access into an environment from moving laterally to further expand their scope of access and persistence. Credential Exposure and Account Protections Protect against the exposure of privileged credentials to facilitate privilege escalation. Preventing Destructive Actions in Kubernetes and CI/CD Pipelines Protect the integrity and availability of Kubernetes environments and CI/CD pipelines. Table 1: Overview of recommendations 1. External-Facing Assets Identify, Enumerate, and Harden To protect against a threat actor exploiting vulnerabilities or misconfigurations via an external-facing vector, organizations must determine the scope of applications and organization-managed services that are externally accessible. Externally accessible applications and services (including both on-premises and cloud) are often targeted by threat actors for initial access by exploiting known vulnerabilities, brute-forcing common or default credentials, or authenticating using valid credentials. To proactively identify and validate external-facing applications and services, consider: Leveraging a vulnerability scanning technology to identify assets and associated vulnerabilities. Performing a focused vulnerability assessment or penetration test with the goal of identifying external-facing vectors that could be leveraged for authentication and access. Verifying with technology vendors if the products leveraged by an organization for external-facing services require patches or updates to mitigate known vulnerabilities. Any identified vulnerabilities should not only be patched and hardened, but the identified technology platforms should also be reviewed to ensure that evidence of suspicious activity or technology/device modifications have not already occurred. The following table provides an overview of capabilities to proactively review and identify external-facing assets and resources within common cloud-based infrastructures. Cloud Provider Attack Surface Discovery Capability Google Cloud Security Command Center Amazon Web Services AWS Config / Inspector Microsoft Azure Defender External Attack Surface Management (Defender EASM ) Table 2: Overview of cloud provider attack surface discovery capabilities Enforce Multi-Factor Authentication External-facing assets that leverage single-factor authentication (SFA) are highly susceptible to brute-forcing attacks, password spraying, or unauthorized remote access using valid (stolen) credentials. External-facing applications and services that currently allow for SFA should be configured to support multi-factor authentication (MFA). Additionally, MFA should be leveraged for accessing not only on-premises external-facing managed infrastructure, but also for cloud-based resources (e.g., software-as-a-service [SaaS] such as Microsoft 365 [M365]). When configuring multifactor authentication, the following methods are commonly considered (and ranked from most to least secure): Fast IDentity Online 2 (FIDO2)/WebAuthn security keys or passkeys Software/hardware Open Authentication (OAUTH) token Authenticator application (e.g., Duo/Microsoft [MS] Authenticator/Okta Verify) Time-based One Time Password (TOTP) Push notification (least preferred option) using number matching when possible Phone call Short Message Service (SMS) verification Email-based verification Risks of Specific MFA Methods Push Notifications If an organization is leveraging push notifications for MFA (e.g., a notification that requires acceptance via an application or automated call to a mobile device), threat actors can exploit this type of MFA configuration for attempted access, as a user may inadvertently accept a push notification on their device without the context of where the authentication was initiated. Phone/SMS Verification If an organization is leveraging phone calls or SMS-based verification for MFA, these methods are not encrypted and are susceptible to potentially being intercepted by a threat actor. These methods are also vulnerable if a threat actor is able to transfer an employee’s phone number to an attacker-controlled subscriber identification module (SIM) card. This would result in the MFA notifications being routed to the threat actor instead of the intended employee. Email-Based Verification If an organization is leveraging email-based verification for validating access or for retrieving MFA codes, and a threat actor has already established the ability to access the email of their target, the actor could potentially also retrieve the email(s) to validate and complete the MFA process. If any of these MFA methods are leveraged, consider: Training remote users to never accept or respond to a logon notification when they are not actively attempting to log in. Establishing a method for users to report suspicious MFA notifications, as this could be indicative of a compromised account. Ensuring there are messaging policies in place to prevent the auto-forwarding of email messages outside the organization. Time-Based One-Time Password Time-based one-time password (TOTP) relies on a shared secret, called a seed, known by both the authenticating system and the authenticator possessed by an end user. If a seed is compromised, the TOTP authenticator can be duplicated and used by a threat actor. Detection Opportunities for External-Facing Assets and MFA Attempts Use Case MITRE ID Description Brute Force T1110 – Brute Force Search for a single user with an excessive number of failed logins from external Internet Protocol (IP) addresses. This risk can be mitigated by enforcing a strong password, MFA, and lockout policy. Password Spray T1110.003 – Password Spray Search for a high number of accounts with failed logins, typically from the similar origination addresses. Multiple Failed MFA Same User T1110 – Brute Force T1078 – Valid Accounts Search for multiple failed MFA conditions for the same account. This may be indicative of a previously compromised credential. Multiple Failed MFA Same Source T1110.003 – Password Spray T1078 – Valid Accounts Search for multiple failed MFA prompts for different users from the same source. This may be indicative of multiple compromised credentials and an attempt to “spray” MFA prompts/tokens for access. External Authentication from an Account with Elevated Privileges T1078 – Valid Accounts Privileged accounts should use internally managed and secured privileged access workstations for access and should not be accessible directly from an external (untrusted) source. Adversary in the Middle (AiTM) Session Token Theft T1557 – Adversary in the Middle Monitor for sign-ins where the authentication method succeeds but the session originates from an IP/ASN inconsistent with the user’s prior sessions. Detect logins from newly registered domains or known reverse-proxy infrastructure (EvilProxy, Tycoon 2FA). Correlate sign-in logs for “isInteractive: true” sessions with anomalous user-agent strings or geographically impossible travel. MFA Fatigue / Prompt Bombing T1621 – MFA Request Generation Search for accounts receiving more than five MFA push notifications within a 10-minute window without a corresponding successful authentication. Post-Authentication MFA Device Registration T1098.005 – Account Manipulation – Device Registration Monitor audit logs for new MFA device registrations (AuthenticationMethodRegistered) occurring within 60 minutes of a sign-in from a new IP or device. Attackers who steal session tokens via AiTM immediately register their own MFA device for persistent access. OAuth/Consent Phishing T1550.001 – Use Alternate Authentication Material Monitor for OAuth application consent grants with high-privilege scopes (Mail.Read, Files.ReadWrite.All) from unrecognized application IDs. Table 3: Detection opportunities for external-facing assets and MFA attempts 2. Critical Asset Protections Domain Controller and Critical Asset Backups Organizations should verify that backups for domain controllers and critical assets are available and protected against unauthorized access or modification. Backup processes and procedures should be exercised on a continual basis. Backups should be protected and stored within secured enclaves that include both network and identity segmentation. If an organization’s Active Directory (AD) were to become corrupted or unavailable due to ransomware or a potentially destructive attack, restoring Active Directory from domain controller backups may be the only viable option to reconstitute domain services. The following domain controller recovery and reconstitution best practices should be proactively reviewed by organizations: Verify that there is a known good backup of domain controllers and SYSVOL shares (e.g., from a domain controller – backup C:\Windows\SYSVOL ). For domain controllers, a system state backup is preferred. Note: For a system state backup to occur, Windows Server Backup must be installed as a feature on a domain controller. The following command can be run from an elevated command prompt to initiate a system state backup of a domain controller. wbadmin start systemstatebackup -backuptarget:: Figure 1: Command to perform a system state backup The following command can be run from an elevated command prompt to perform a SYSVOL backup. ( Manage auditing and security log permissions must also be configured for the account performing the backup.) robocopy c:\windows\sysvol c:\sysvol-backup /copyall /mir /b /r:0 /xd Figure 2: Command to perform a SYSVOL backup Proactively identify domain controllers that hold flexible single master operation (FSMO) roles, as these domain controllers will need to be prioritized for recovery in the event that a full domain restoration is required. netdom query fsmo Figure 3: Command to identify domain controllers that hold FSMO roles Offline backups: Ensure offline domain controller backups are secured and stored separately from online backups. Encryption: Backup data should be encrypted both during transit (over the wire) and when at rest or mirrored for offsite storage. DSRM Password validation: Ensure that the Directory Services Restore Mode (DSRM) password is set to a known value for each domain controller. This password is required when performing an authoritative or nonauthoritative domain controller restoration. Configure alerting for backup operations: Backup products and technologies should be configured to detect and provide alerting for operations critical to the availability and integrity of backup data (e.g., deletion of backup data, purging of backup metadata, restoration events, media errors). Enforce role-based access control (RBAC): Access to backup media and the applications that govern and manage data backups should use RBAC to restrict the scope of accounts that have access to the stored data and configuration parameters. Testing and verification: Both authoritative and nonauthoritative domain controller restoration processes should be documented and tested on a regular basis. The same testing and verification processes should be enforced for critical assets and data. Business Continuity Planning Critical asset recovery is dependent upon in-depth planning and preparation, which is often included within an organization’s business continuity plan (BCP). Planning and recovery preparation should include the following core competencies: A well-defined understanding of crown jewels data and supporting applications that align to backup, failover, and restoration tasks that prioritize mission-critical business operations Clearly defined asset prioritization and recovery sequencing Thoroughly documented recovery processes for critical systems and data Trained personnel to support recovery efforts Validation of recovery processes to ensure successful execution Clear delineation of responsibility for managing and verifying data and application backups Online and offline data backup retention policies, including initiation, frequency, verification, and testing (for both on-premises and cloud-based data) Established service-level agreements (SLAs) with vendors to prioritize application and infrastructure-focused support Continuity and recovery planning can become stale over time, and processes are often not updated to reflect environment and personnel changes. Prioritizing evaluations, continuous training, and recovery validation exercises will enable an organization to be better prepared in the event of a disaster. Detection Opportunities for Backups Use Case MITRE ID Description Volume Shadow Deletion T1490 – Inhibit System Recovery Search for instances where a threat actor will delete volume shadow copies to inhibit system recovery. This can be accomplished using the command line, PowerShell, and other utilities. Unauthorized Access Attempt T1078 – Valid Accounts Search for unauthorized users attempting to access the media and applications that are used to manage data backups. Suspicious Usage of the DSRM Password T1078 – Valid Accounts Monitor security event logs on domain controllers for: Event ID 4794 – An attempt was made to set the Directory Services Restore Mode administrator password Monitoring the following registry key on domain controllers: HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior Figure 4: DSRM registry key for monitoring The possible values for the registry key noted in Figure 4 are: 0 (default): The DSRM Administrator account can only be used if the domain controller is restarted in Directory Services Restore Mode. 1 : The DSRM Administrator account can be used for a console-based log on if the local Active Directory Domain Services service is stopped. 2 : The DSRM Administrator account can be used for console or network access without needing to reboot a domain controller. Table 4: Detection opportunities for backups IT and OT Segmentation Organizations should ensure that there is both physical and logical segmentation between corporate information technology (IT) domains, identities, networks, and assets and those used in direct support of operational technology (OT) processes and control. By enforcing IT and OT segmentation, organizations can inhibit a threat actor’s ability to pivot from corporate environments to mission-critical OT assets using compromised accounts and existing network access paths. OT environments should leverage separate identity stores (e.g., dedicated Active Directory domains), which are not trusted or cross-used in support of corporate identity and authentication. The compromise of a corporate identity or asset should not result in a threat actor’s ability to directly pivot to accessing an asset that has the ability to influence an OT process. In addition to separate AD forests being leveraged for IT and OT, segmentation should also include technologies that may have a dual use in the IT and OT environments (backup servers, antivirus [AV], endpoint detection and response [EDR], jump servers, storage, virtual network infrastructure). OT segmentation should be designed such that if there is a disruption in the corporate (IT) environment, the OT process can safely function independently, without a direct dependency (account, asset, network pathway) with the corporate infrastructure. For any dependencies that cannot be readily segmented, organizations should identify potential short-term processes or manual controls to ensure that the OT environment can be effectively isolated if evidence of an IT (corporate)-focused incident were detected. Segmenting IT and OT environments is a best practice recommended by industry standards such as the National Institute of Standards and Technology (NIST) SP 800-82r3 : Guide to Operational Technology (OT) Security and IEC 62443 (formerly ISA99). According to these best-practice standards, segmenting IT and OT networks should include the following: OT attack surface reduction by restricting the scope of ports, services, and protocols that are directly accessible within the OT network from the corporate (IT) network. Incoming access from corporate (IT) into OT must terminate within a segmented OT demilitarized zone (DMZ). The OT DMZ must require that a separate level of authentication and access be granted (outside of leveraging an account or endpoint that resides within the corporate IT domain). Explicit firewall rules should restrict both incoming traffic from the corporate environment and outgoing traffic from the OT environment. Firewalls should be configured using the principle of deny by default, with only approved and authorized traffic flows permitted. Egress (internet) traffic flows for all assets that support OT should also follow the deny-by-default model. Identity (account) segmentation must be enforced between corporate IT and OT. An account or endpoint within either environment should not have any permissions or access rights assigned outside of the respective environment. Remote access to the OT environment should not leverage similar accounts that have remote access permissions assigned within the corporate IT environment. MFA using separate credentials should be enforced for remotely accessing OT assets and resources. Training and verification of manual control processes, including isolation and reliability verification for safety systems. Secured enclaves for storing backups, programming logic, and logistical diagrams for systems and devices that comprise the OT infrastructure. The default usernames and passwords associated with OT devices should always be changed from the default vendor configuration(s). Detection Opportunities for IT and OT Segmented Environments Use Case MITRE ID Description Network Service Scanning T1046 – Network Service Scanning Search for instances where a threat actor is performing internal network discovery to identify open ports and services between segmented environments. Unauthorized Authentication Attempts Between Segmented Environments T1078 – Valid Accounts Search for failed logins for accounts limited to one environment attempting to log in within another environment. This can detect threat actors attempting to reuse credentials for lateral movement between networks. Table 5: Detection opportunities for IT and OT segmented environments Egress Restrictions Servers and assets that are infrequently rebooted are highly targeted by threat actors for establishing backdoors to create persistent beacons to command-and-control (C2) infrastructure. By blocking or severely limiting internet access for these types of assets, an organization can effectively reduce the risk of a threat actor compromising servers, extracting data, or installing backdoors that leverage egress communications for maintaining access. Egress restrictions should be enforced so that servers, internal network devices, critical IT assets, OT assets, and field devices cannot attempt to communicate to external sites and addresses (internet resources). The concept of deny by default should apply to all servers, network devices, and critical assets (including both IT and OT), with only allow-listed and authorized egress traffic flows explicitly defined and enforced. Where possible, this should include blocking recursive Domain Name System (DNS) resolutions not included in an allow-list to prevent communication via DNS tunneling. If possible, egress traffic should be routed through an inspection layer (such as a proxy) to monitor external connections and block any connections to malicious domains or IP addresses. Connections to uncategorized network locations (e.g., a domain that has been recently registered) should not be permitted. Ideally, DNS requests would be routed through an external service (e.g., Cisco Umbrella, Infoblox DDI) to monitor for lookups to malicious domains. Threat actors often attempt to harvest credentials (including New Technology Local Area Network [LAN] Manager [NTLM] hashes) based upon outbound Server Message Block (SMB) or Web-based Distributed Authoring and Versioning (WebDAV) communications. Organizations should review and limit the scope of egress protocols that are permissible from any endpoint within the environment. While Hypertext Transfer Protocol (HTTP) (Transmission Control Protocol (TCP)/80) and HTTP Secure (HTTPS) (TCP/443) egress communications are likely required for many user-based endpoints, the scope of external sites and addresses can potentially be limited based upon web traffic-filtering technologies. Ideally, organizations should only permit egress protocols and communications based upon a predefined allow-list. Common high-risk ports for egress restrictions include: File Transfer Protocol (FTP) Remote Desktop Protocol (RDP) Secure Shell (SSH) Server Message Block (SMB) Trivial File Transfer Protocol (TFTP) WebDAV Detection Opportunities for Suspicious Egress Traffic Flows Use Case MITRE ID Description External Connection Attempt to a Known Malicious IP TA0011 – Command and Control Leverage threat feeds to identify attempted connections to known bad IP addresses. External Communications from Servers, Critical Assets, and Isolated Network Segments TA0011 – Command and Control Search for egress traffic flows from subnets and addresses that correlate to servers, critical assets, OT segments, and field devices. Outbound Connections Attempted Over SMB T1212 – Exploitation for Credential Access Search for external connection attempts over SMB, as this may be an attempt to harvest credential hashes. Table 6: Detection opportunities for suspicious egress traffic flows Virtualization Infrastructure Protections Threat actors often target virtualization infrastructure (e.g., VMware vSphere, Microsoft Hyper-V) as part of their reconnaissance, lateral movement, data theft, and potential ransomware deployment objectives. Securing virtualization infrastructure requires a Zero Trust network posture as a primary defense. Because management appliances often lack native MFA for local privileged accounts, identity-based security alone can be a high-risk single point of failure. If credentials are compromised, the logical network architecture becomes the final line of defense protecting the virtualization management plane. To reduce the attack surface of virtualized infrastructure, a best practice for VMware vSphere vCenter ESXi and Hyper-V appliances and servers is to isolate and restrict access to the management interfaces, essentially enclaving these interfaces within isolated virtual local area networks (VLANs) (network segments) where connectivity is only permissible from dedicated subnets where administrative actions can be initiated. To protect the virtualization control plane, organizations must consider a “defense-in-depth” network model. This architecture integrates physical isolation and east-west micro-segmentation to remove all access paths from untrusted networks. The result is a management zone that remains isolated and resilient, even during an active intrusion. VMware vSphere Zero-Trust Network Architecture The primary goal is to ensure that even if privileged credentials are compromised, the logical network remains the definitive defensive layer preventing access to virtualization management interfaces. Immutable VLAN Segmentation : Enforce strict isolation using distinct 802.1Q VLAN IDs for host management, Infrastructure/VCSA, vMotion (non-routable), Storage (non-routable), and production Guest VMs. Virtual Routing and Forwarding (VRF) : Transition all infrastructure VLANs into a dedicated VRF instance. This ensures that even a total compromise of the “User” or “Guest” zones results in no available route to the management zone(s). Layer 3 and 4 Access Policies The management network must be accessible only from trusted, hardened sources. PAW-Exclusive Access: Deconstruct all direct routes from the general corporate LAN to management subnets. Access must originate strictly from a designated Privileged Access Workstation (PAW) subnet. Ingress Filtering (Management Zone) : ALLOW: TCP/443 (UI/API) and TCP/902 (MKS) from the PAW subnet only. DENY : Explicitly block SSH (TCP/22) and VAMI (TCP/5480) from all sources except the PAW subnet. Restrictive Egress Policy: Enforce outbound filtering at the hardware gateway (as the VCSA GUI cannot manage egress). To prevent persistence using C2 traffic and data exfiltration, block all internet access except to specific, verified update servers (e.g., VMware Update Manager) and authorized identity providers. Host-Based Firewall Enforcement Complement network firewalls with host-level filtering to eliminate visibility gaps within the same VLAN. VCSA (Photon OS) : Transition the default policy to “Default Deny” via the VAMI or, preferably, at the OS level using iptables/nftables for granular source/destination mapping. ESXi Hypervisors: Restrict all services (SSH, Web Access, NFC/Storage) to specific management IPs by deselecting “Allow connections from any IP address.” Additional information related to VMware vSphere VCSA host based firewalls . A listing of administrative ports associated with VMWare vCenter (that should be targeted for isolation). Hyper-V Zero-Trust Network Architecture Similar to vSphere, Hyper-V requires strict isolation of its various traffic types to prevent lateral movement from guest workloads to the management plane. VLAN Segmentation: Organizations must enforce isolation using distinct VLANs for Host Management, Live Migration, Cluster Heartbeat (CSV), and Production Guest VMs. Non-Routable Networks: Traffic for Live Migration and Cluster Shared Volumes (CSV) should be placed on non-routable VLANs to ensure these high-bandwidth, sensitive streams cannot be intercepted from other segments. Layer 3 and 4 Access Policies The management network must be accessible only from trusted, hardened sources. PAW-Exclusive Access: Deconstruct all direct routes from the general corporate LAN to management subnets. Access must originate strictly from a designated Privileged Access Workstation (PAW) subnet. Ingress Filtering (Management Zone) : ALLOW : WinRM / PowerShell Remoting (TCP/5985 and TCP/5986), RDP (TCP/3389), and WMI/RPC (TCP/135 and dynamic RPC ports)strictly from the PAW subnet. If using Windows Admin Center, allow HTTPS (TCP/443) to the gateway. DENY : Explicitly block SMB (TCP/445), RPC/WMI (TCP/135), and all other management traffic from untrusted sources to prevent credential theft and lateral movement. Restrictive Egress Policy: Enforce outbound filtering at the network gateway. To prevent persistence using C2 traffic and data exfiltration, block all internet access from Hyper-V hosts except to specific, verified update servers (e.g., internal WSUS), authorized Active Directory Domain Controllers, and Key Management Servers (KMS). Host-Based Firewall Enforcement Use the Windows Firewall with Advanced Security (WFAS) to achieve a defense-in-depth posture at the host level. Scope Restriction: For all enabled management rules (e.g., File and Printer Sharing, WMI, PowerShell Remoting), modify the Remote IP Address scope to “These IP addresses” and enter only the PAW and management server subnets. Management Logging: Enable logging for Dropped Packets in the Windows Firewall profile. This allows the SIEM to ingest “denied” connection attempts, which serve as high-fidelity indicators of internal reconnaissance or unauthorized access attempts. Additional information related to Hyper-V host based firewalls . Additional information related to securing Hyper-V . General Virtualization Hardening To protect management interfaces for VMware vSphere the VMKernel network interface card (NIC) should not be bound to the same virtual network assigned to virtual machines running on the host. Additionally, ESXi servers can be configured in lockdown mode, which will only allow console access from the vCenter server(s). Additional information related to lockdown mode . The SSH protocol (TCP/22) provides a common channel for accessing a physical virtualization server or appliance (vCenter) for administration and troubleshooting. Threat actors commonly leverage SSH for direct access to virtualization infrastructure to conduct destructive attacks. In addition to enclaving access to administrative interfaces, SSH access to virtualization infrastructure should be disabled and only enabled for specific use-cases. If SSH is required, network ACLs should be used to limit where connections can originate. Identity segmentation should also be configured when accessing administrative interfaces associated with virtualization infrastructure. If Active Directory authentication provides direct integrated access to the physical virtualization stack, a threat actor that has compromised a valid Active Directory account (with permissions to manage the virtualization infrastructure) could potentially use the account to directly access virtualized systems to steal data or perform destructive actions. Authentication to virtualized infrastructure should rely upon dedicated and unique accounts that are configured with strong passwords and that are not co-used for additional access within an environment. Additionally, accessing management interfaces associated with virtualization infrastructure should only be initiated from isolated privileged access workstations, which prevent the storing and caching of passwords used for accessing critical infrastructure components. Protecting Hypervisors Against Offline Credential Theft and Exfiltration Organizations should implement a proactive, defense-in-depth technical hardening strategy to systematically address security gaps and mitigate the risk of offline credential theft from the hypervisor layer. The core of this attack is an offline credential theft technique known as a “Disk Swap.” Once an adversary has administrative control over the hypervisor (vSphere or Hyper-V), they perform the following steps: Target Identification: The actor identifies a critical virtualized asset, such as a Domain Controller (DC) Offline Manipulation: The target VM is powered off, and its virtual disk file (e.g., .vmdk for VMware or .vhd/.vhdx for Hyper-V) is detached. NTDS.dit Extraction : The disk is attached to a staging or “orphaned” VM under the attacker’s control. From this unmonitored machine, they copy the NTDS.dit Active Directory database. Stealthy Recovery : The disk is re-attached to the original DC, and the VM is powered back on, leaving minimal forensic evidence within the guest operating system. Hardening and Mitigation Guidance To defend against this logic, organizations must implement a defense-in-depth strategy that focuses on cryptographic isolation and strict lifecycle management. Virtual Machine Encryption : Organizations must encrypt all Tier 0 virtualized assets (e.g., Domain Controllers, PKI, and Backup Servers). Encryption ensures that even if a virtual disk file is stolen or detached, it remains unreadable without access to the specific keys. Strict Decommissioning Processes : Do not leave powered-off or “orphaned” virtual machines on datastores. These “ghost” VMs are ideal staging environments for attackers. Formally decommission assets by deleting their virtual disks rather than just removing them from the inventory. Harden Hypervisor Accounts : Disable or restrict default administrative accounts (such as root on ESXi or the local Administrator on Hyper-V hosts). Enforce Lockdown Mode (VMware ESXi feature) where possible to prevent direct host-level changes outside of the central management plane. Remote Audit Logging : Enable and forward all hypervisor-level audit logs (e.g., hostd.log, vpxa.log, or Windows Event Logs for Hyper-V) to a centralized SIEM. Protecting Backups Security measures must encompass both production and backup environments. An attack on the production plane is often coupled with a simultaneous focus on backup integrity, creating a total loss of operational continuity. Virtual disk files (VMDK for VMware and VHD/VHDX for Hyper-V) represent a high-value target for offline data theft and direct manipulation. Hardening and Mitigation Guidance To mitigate the risk of offline theft and backup manipulation, organizations must implement a “Default Encrypted” policy across the entire lifecycle of the virtual disk . At-Rest Encryption for all Tier-0 Assets: Implement vSphere VM Encryption or Hyper-V Shielded VMs for all critical infrastructure (e.g., Domain Controllers, Certificate Authorities). This ensures that the raw VMDK or VHDX files are cryptographically protected, rendering them unreadable if detached or mounted by an unauthorized party. Encrypted Backup Repositories : Ensure that the backup application is configured to encrypt backup data at rest using a unique key stored in a separate, hardened Key Management System (KMS). This prevents “direct manipulation” of the backup files even if the backup storage itself is compromised. Network Isolation of Storage & Backups: Isolate the storage management network and the backup infrastructure into dedicated, non-routable VLANs. Access to the backup console and repositories must require phishing-resistant MFA and originate from a designated Privileged Access Workstation (PAW). Immutability and Air-Gapping : Use Immutable Backup Repositories to ensure that once a backup is written, it cannot be modified or deleted by any user including a compromised administrator for a set period. This provides a definitive recovery point in the event of a ransomware attack or intentional data sabotage. Detection Opportunities for Monitoring Virtualization Infrastructure Use Case MITRE ID Description Unauthorized Access Attempt to Virtualized Infrastructure T1078 – Valid Accounts Search for attempted logins to virtualized infrastructure by unauthorized accounts. Unauthorized SSH Connection Attempt T1021.004 – Remote Services: SSH Search for instances where an SSH connection is attempted when SSH has not been enabled for an approved purpose or is not expected from a specific origination asset. ESXi Shell/SSH Enablement T1059.004 – Command and Scripting Interpreter Monitor ESXi hostd.log and shell.log for the SSH service being enabled via DCUI, vSphere client, or API calls. Alert on any ESXi SSH enablement event that was not preceded by an approved change request. Bulk VM Power-Off Events T1529 – System Shutdown/Reboot Detect sequences where multiple VMs are powered off within a short time window (e.g., >5 VMs in 10 minutes) via vCenter events. Correlate with vpxd.log “ReceivedPowerOffVM” events. VMDK File Access from Non-Standard Processes T1486 – Data Encrypted for Impact Monitor for processes accessing .vmdk, .vmx, .vmsd, or .vmsn files outside of normal VMware service processes (hostd, vpxd, fdm). execInstalledOnly Disablement T1562.001 – Impair Defenses: Disable or Modify Tools Monitor ESXi shell.log for execution of “esxcli system settings encryption set” with “–require-exec-installed-only=F” or “–require-secure-boot=F”. Alert on any cryptographic enforcement disablement event that was not preceded by an approved change request. vCenter SSO Identity Modification T1556 – Modify Authentication Process Monitor vCenter events and vpxd.log for modifications to SSO identity sources, including the addition of new LDAP providers or changes to vshphere.local administrator group membership. Alert on an identity source change not initiated from a designated PAW subnet. VM Disk Detach and Reattach to Non-Inventory VM T1486 – Data Encrypted for Impact Detect sequences where a virtual disk is removed from a Tier-0 asset via “vim.event.VmReconfiguredEvent” and subsequently attached to an orphaned or non-standard inventory VM. Correlate with “vim.event.VmRegisteredEvent” events on non-standard datastore paths within the same time window. VCSA Shell Command Anomaly T1059.004 – Command and Scripting Interpreter: Unix Shell Monitor VCSA shell audit logs for execution of high-risk commands (e.g., wget, curl, psql, certificate-manager) by any user following an interactive SSH session. Alert on any instance where these commands are executed outside of an approved change window. Bulk Snapshot Deletion T1490 – Inhibit System Recovery Detects sequences where snapshots are removed across multiple VMs within a short time window via vCenter events. Correlate with “vim-cmd vmsvc/snapshot.removeall” execution in hostd.log to confirm host-level action. Table 7: Detection opportunities for VMware vSphere Protecting Against DDoS Attacks A distributed denial-of-service (DDoS) attack is an example of a disruptive attack that could impact the availability of cloud-based resources and services. Modernized DDoS protection must extend beyond the legacy concepts of filtering and rate-limiting, and include cloud-native capabilities that can scale to combat adversarial capabilities. In addition to third-party DDoS and web application access protection services, the following table provides an overview of DDoS protection capabilities within common cloud-based infrastructures. Cloud Provider DDoS Protection Capability Google Cloud Google Cloud Armor Amazon Web Services AWS Shield Microsoft Azure Azure DDoS Protection Cloud Platform Agnostic Imperva WAF Akamai WAF Cloudflare DDoS Protection Table 8: Common cloud capabilities to mitigate DDoS attacks Hardening the Cloud Perimeter With the hybrid operating model of modern day infrastructure, cloud consoles and SaaS platforms are high-value targets for credential harvesting and data exfiltration. Minimizing these risks requires a dual-defense strategy: robust identity controls to prevent unauthorized access, and platform-specific guardrails to protect access to resources, data, and to minimize the attack surface. Strong Authentication Enforcement Strong authentication is the foundational requirement for cloud resilience and securing cloud infrastructure. Similar to on-premises environments, a compromise of a privileged credential, token, or session could lead to unintended consequences that result in a high-impact event for an organization. To mitigate these pervasive risks, organizations must unconditionally enforce strong authentication for all external-facing cloud services, administrative portals, and SaaS platforms. Organizations should enforce the usage of phishing-resistant authenticators such as FIDO2 (WebAuthn) hardware tokens or passkeys, or certificate based authentication for accounts assigned privileged roles and functions. For non-privileged users, authenticator software (Microsoft Authenticator or Okta Verify) should be configured to utilize device-bound factors such as Windows Hello for Business or TouchID. Additionally, organizations should leverage the concept of authenticators (identity + device attestation) as part of the authentication transaction. This includes enforcing a validated-device access policy that restricts privileged access to only originate from managed, compliant, and healthy devices. Trusted network zones should be defined in order to restrict access to cloud resources from the open internet. Untrusted network zones should be defined to restrict authentication from anonymizing services such as VPNs or TOR. Using device-bound session credentials where possible mitigates the risk of session token theft. Identity and Device Segmentation for Privileged Actions The implementation of privileged access workstations (PAWs) is a critical defense against threat actors attempting to compromise administrative sessions. A PAW is a highly hardened, dedicated hardware endpoint used exclusively for sensitive administrative tasks. Administrators should leverage a non-privileged account for daily tasks, while privileged actions are restricted to only being permissible from the hardened PAW, or from explicitly defined IP ranges. This “air-gap” between communication and administration prevents an adversary from moving laterally from a compromised non-privileged identity to a privileged context within hybrid environments. Just-in-Time Access and the Principle of Least Privilege Static, standing privileges present a security risk in hybrid environments. Following a zero-trust cloud architecture, administrative privileges should be entirely ephemeral. Implementing Just-In-Time (JIT) and Just-Enough-Access (JEA) mechanisms ensures that administrators are granted only the specific, granular permissions necessary to perform a discrete task, and only for a highly limited duration, after which the permissions are automatically revoked. This architectural model provides organizations with the ability to enforce approvals for privileged actions, enhanced monitoring, and detailed visibility regarding any privileged actions taken within a specific session. Securing Non-Human Identities Organizations should implement identity governance practices that include processes to rotate API keys, certificates, service account secrets, tokens, and sessions on a predefined basis. AI agents or identities correlating to autonomous outcomes should be configured with strictly scoped permissions and associated monitoring. Non-privileged users should be restricted from authorizing third-party application integrations or creating API keys without organizational approval. Continuous scanning should be performed to identify and remediate hard-coded secrets and sensitive credentials across all cloud and SaaS environments. Storage Infrastructure Security and Immutable Backups The strategic objective of a destructive cyberattack—whether for extortion or sabotage—is to prolong recovery and reconstitution efforts by ensuring data is irrecoverable. Modern adversaries systematically target the backup plane as part of a destructive event. If backups remain mutable or share an identity plane with the primary environment, attackers can delete or encrypt them, transforming an incident into a prolonged and chaotic recovery exercise. While modern-day redundancy for backups should include multiple data copies across diverse media, geographic separation can be a subverted defensive strategy if logical access is unified. To ensure resilience against destructive attacks, the secondary recovery environment should reside within a sovereign cloud tenant or isolated subscription. This environment should be governed by an independent Identity and Access Management (IAM) plane, using distinct credentials and administrative personas that share no commonality with the production environment. Backups within an isolated environment must be anchored by immutable storage architectures. By leveraging hardware-verified Write-Once, Read-Many (WORM) technology, the recovery plane ensures that data integrity is mathematically guaranteed. Once committed, data cannot be modified, encrypted, or deleted—even by accounts with root or global administrative privileges, until the retention period expires. This creates a definitive “fail-safe” that ensures a known-good recovery point remains accessible regardless of potential security risks in the primary environment. Additional defense-in-depth security architecture controls relevant to common cloud-based infrastructures are included in Table 9. Cloud Provider Identity Controls Secrets Governance Network Controls Policy Guardrails Google Cloud IAM Deny Policies Secret Manager VPC Service Controls Organization Policy Service Amazon Web Services IAM Identity Center Secrets Manager Verified Access Service Control Policies Microsoft Azure Entra ID (PIM) Azure Key Vault Azure Virtual Network Private Link Azure Policy Cloud Agnostic Security Solutions Okta SailPoint Ping Identity Hashicorp Vault CyberArk Zscaler Netskope SSE Wiz Palo Alto Prisma Cloud Orca Security Table 9: Common cloud capabilities for infrastructure hardening Detection Opportunities for Protecting Cloud Infrastructure and Resources Use Case MITRE ID Description Cloud Account Abuse T1078.004 – Valid Accounts: Cloud Accounts Monitor cloud audit logs for authentication from unseen source IPs, anomalous ASNs, or impossible travel patterns. Alert on IAM policy modifications, new role assignments, and service account key creation by accounts without prior administrative API activity. Lateral Movement via Cloud Interfaces T1021.007 – Remote Services: Cloud Services Detect interactive console sign-ins from IPs that previously only performed programmatic API/CLI access. Alert on cloud CLI execution from non-administrative endpoints. Monitor for cross-service lateral movement where a single identity authenticates to multiple cloud services in a compressed timeframe outside its historical access pattern. Modify Cloud Compute Configurations T1578.005 – Modify Cloud Compute Configurations Monitor for unauthorized compute changes including bulk instance creation or deletion deviating from change management baselines. Alert on snapshot creation of production volumes by non-backup accounts, disk detach/reattach targeting domain controller or database instances for offline credential theft, and network/firewall modifications exposing internal services to public access. Cloud Log Enumeration T1654 – Log Enumeration Monitor for API calls listing or accessing logging configurations from identities without documented operational need. Alert on enumeration of SIEM integration settings, log export destinations, and alert rule definitions. Mass Deletion & Impact T1490 – Inhibit System Recovery Alert when bulk delete API calls exceed baseline thresholds targeting compute instances, storage, databases, or virtual networks. Detect deletion or retention reduction of recovery-critical resources including backup vaults, snapshot schedules, and disaster recovery configurations. Backup Policy Modification or Deletion T1490 – Inhibit System Recovery Monitor for unauthorized modifications to backup configurations, including changes to WORM retention policies, backup vault access policies, snapshot deletion, or backup schedule disablement. Alert on backup storage account access from identities other than designated backup service accounts. Conditional Access or Security Policy Modification T1556.009 – Conditional Access Policies Monitor cloud identity provider audit logs for modifications to Conditional Access Policies, MFA enforcement rules, legacy authentication blocking rules, or PIM/JIT role settings. Alert on changes that add location or device exclusions to MFA policies, disable legacy protocol blocks, extend privilege role activation durations, or register new authentication methods on privileged accounts. Table 10: Detection opportunities for protecting cloud infrastructure and resources Securing Endpoint and Mobile Device Management Platforms Protecting endpoint and Mobile Device Management (MDM) platforms is crucial to ensuring the security and availability of devices used in support of operations. In the context of wiper and destructive-style attacks, these platforms represent the “keys to the kingdom” that threat actors can target to turn an organization’s own infrastructure against itself. Force Multiplier: MDM and endpoint management tools have the inherent ability to push configurations and scripts to enrolled and managed devices. If compromised, a threat actor can use these legitimate administrative platforms to deploy wiper malware or execute remote wipe commands simultaneously across the entire enterprise, achieving destruction in minutes. Unlike ransomware, where data might be recoverable via decryption, wiper attacks aim for the permanent destruction of the Master Boot Record (MBR), GUID Partition Table (GPT), Master File Table (MFT), or overwrite the file system making endpoint devices inaccessible. Proactive Hardening Enforcing strong identity and network controls for securing the management plane can prevent an attacker from gaining access to endpoint and MDM platforms and abusing intended functionality (e.g., deploying wiper scripts or issuing “Remote Wipe” or “Factory Reset” commands). Enforce strong authentication (e.g., phishing-resistant MFA, including FIDO2) for identities assigned privileged roles and functions. Enforce session lifetimes, idle session timeouts and utilize device-bound session protection to protect against token replay attacks. Require access policies and multi-admin approval for authorization of specific actions. Reduce long-standing administrative permissions and migrate to a Just-in-Time (JIT) or Just-Enough-Access (JEA) access model for privileged roles and actions. For Microsoft Intune, leverage a combination of role-based access control (RBAC) and scope tags to reduce the blast radius and minimize the risk of compromised privileged identities being leveraged to impact a large scope of managed devices / endpoints. Audit admin roles for anything including “Remote tasks/wipe/erase” permissions – and ensure these events are forwarded to a centralized SIEM. Additionally, reduce the scope of administrators that can perform these actions to the minimum required for business operations. Reduce scope of API token permissions following the principle of least privilege. Remove or expire tokens after a period of inactivity. Rotate tokens on a regular basis. For cloud-hosted MDM platforms, utilize access policies to enforce network- and location-based allow listing. For local/on-premises MDM servers, utilize firewalls to restrict access to MDM infrastructure (management plane). If supported, configure wipe protection to prevent against mass device wiping within a specific threshold. An example of this configuration within the Omnissa Workspace ONE platform is available here . Review existing scripts and configuration profiles deployed via the MDM platform to identify and remediate any hardcoded plain text passwords, API keys, or other sensitive secrets. Detection Opportunities for Securing Endpoint and Mobile Device Management Platforms Use Case MITRE ID Description Remote Wipe or Factory Reset Command Issued T1485 – Data Destruction Monitor endpoint management platform audit logs for issuance of remote wipe, factory reset, or retire commands. Alert on any wipe command targeting more than a threshold number of devices within a defined time window, or wipe commands issued outside approved change windows. Anomalous MDM/EDR Administrator Authentication T1078.004 – Valid accounts: Cloud accounts Monitor authentication logs for endpoint management platform admin consoles for sign-ins from unrecognized IPs, non-compliant devices, or locations inconsistent with the administrator’s historical access pattern. Alert on admin authentication that bypasses Conditional Access or lacks phishing-resistant MFA. Bulk Script or Configuration Profile Deployment T1072 – Software Deployment Tools Monitor of mass deployment of new scripts, configuration profiles, or software packages pushed to device groups via the management platform. Alert when a deployment targets all devices or broad scope tags rather than specific groups, particularly when initiated by an account that has not previously performed bulk deployments. Administrative Role or Permission Modification T1098 – Account Manipulation Monitor platform audit logs for changes to administrative roles, RBAC assignments, or scope tag modifications. Alert on elevation of accounts to roles with remote task, wipe, or retire permissions, and on removal of multi-admin approval requirements. API Key creation or Anomalous API access T1098.001 – Additional Cloud Credentials Monitor for creation of new API keys, tokens, or service principal credentials for the endpoint management platform. Alert on API calls from previously unseen source IPs or user-agents, and on API activity outside business hours. Management Platform Audit Log Tampering or Disablement T1562.008 – Impair Defenses: Disable or Modify Cloud Logs Monitor for modifications to the platform’s audit logging configuration, including disablement of change management logging, redirection of syslog export destinations, or deletion of audit log entries. Alert on changes to log retention settings or export configurations. 3. On-Premises Lateral Movement Protections Endpoint Hardening Windows Firewall Configurations Once initial access to on-premises infrastructure is established, threat actors will conduct lateral movement to attempt to further expand the scope of access and persistence. To protect Windows endpoints from being accessed using common lateral movement techniques, a Windows Firewall policy can be configured to restrict the scope of communications permitted between endpoints within an environment. A Windows Firewall policy can be enforced locally or centrally as part of a Group Policy Object (GPO) configuration. At a minimum, the common ports and protocols leveraged for lateral movement that should be blocked between workstation-to-workstation and workstations to non-domain controllers and non-file servers include: SMB (TCP/445, TCP/135, TCP/139) Remote Desktop Protocol (TCP/3389) Windows Remote Management (WinRM)/Remote PowerShell (TCP/80, TCP/5985, TCP/5986) Windows Management Instrumentation (WMI) (dynamic port range assigned through Distributed Component Object Model (DCOM)) Using a GPO (Figure 5), the settings listed in Table 11 can be configured for the Windows Firewall to control inbound communications to endpoints in a managed environment. The referenced settings will effectively block all inbound connections for the Private and Public profiles, and for the Domain profile, only allow connections that do not match a predefined block rule. Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security Figure 5: GPO path for creating Windows Firewall rules Profile Setting Firewall State Inbound Connections Log Dropped Packets Log Successful Connections Log File Path Log File Maximum Size (KB) Domain On Allow Yes Yes %systemroot%\system32\LogFiles\Firewall\pfirewall.log 4,096 Private On Block All Connections Yes Yes %systemroot%\system32\LogFiles\Firewall\pfirewall.log 4,096 Public On Block All Connections Yes Yes %systemroot%\system32\LogFiles\Firewall\pfirewall.log 4,096 Table 11: Windows Firewall recommended configuration state Figure 6: Windows Firewall recommendation configurations Additionally, to ensure that only centrally managed firewall rules are enforced (and cannot be overridden by a threat actor), the settings for Apply local firewall rules and Apply local connection security rules can be set to No for all profiles. Figure 7: Windows Firewall domain profile customized settings To quickly contain and isolate systems, the centralized Windows Firewall setting of Block all connections (Figure 8) will prevent any inbound connections from being established to a system. This is a setting that can be enforced on workstations and laptops, but will likely impact operations if enforced for servers, although if there is evidence of an active threat actor lateral pivoting within an environment, it may be a necessary step for rapid containment. Note: If this control is being used temporarily to facilitate containment as part of an active incident, once the incident has been contained and it has been deemed safe to re-establish connectivity among systems within an environment, the Inbound Connections setting can be changed back to Allow using a GPO. Figure 8: Windows Firewall – Block All Connections settings If blocking all inbound connectivity for endpoints during a containment event is not practical, or for the Domain profile configurations, at a minimum, the protocols listed in Table 12 should be enforced using either a GPO or via the commands referenced within the table. For any specific applications that may require inbound connectivity to end-user endpoints, the local firewall policy should be configured with specific IP address exceptions for origination systems that are authorized to initiate inbound connections to such devices. Protocol/Port Windows Firewall Rule Command Line Enforcement SMB TCP/445, TCP/139, TCP/135 Predefined Rule Name: File and Print Sharing Remote Desktop Windows Management Instrumentation (WMI) Windows Remote Management Windows Remote Management (Compatibility) TCP/5986 netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=no Remote Desktop Protocol TCP/3389 Predefined Rule Name: netsh advfirewall firewall set rule group=”Remote Desktop” new enable=no WMI Predefined Rule Name: netsh advfirewall firewall set rule group=”windows management instrumentation (wmi)” new enable=no Windows Remote Management/PowerShell Remoting TCP/80, TCP/5985, TCP/5986 Predefined Rule Name: netsh advfirewall firewall set rule group=”Windows Remote Management” new enable=no Via PowerShell: Disable-PSRemoting -Force Table 12: Windows Firewall suggested block rules Figure 9: Windows Firewall suggested rule blocks via Group Policy NTLM Authentication Configurations Threat actors often attempt to harvest credentials (including Windows NTLMv1 hashes) based upon outbound SMB or WebDAV communications. Organizations should review NTLM settings for Windows-based endpoints, and work to harden, disable, or restrict NTLMv1 authentication requests. To fully restrict NTLM authentication to remote servers, the following GPO settings can be leveraged: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers Allow all Audit all Deny all Note: If ” Deny all ” is selected, the client computer cannot authenticate (send credentials) to a remote server using NTLM authentication. Before setting to ” Deny all, ” organizations should configure the GPO setting with the ” Audit all ” enforcement. With this configuration, audit and block events will be recorded within the Operational event log on endpoints ( Applications and Services Log\Microsoft\Windows\NTLM ). If any recorded NTLM authentication events are required, organizations can configure the ” Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication ” setting to define a listing of remote servers, which are required to use NTLM authentication. Detection Opportunities for SMB, WMI, and NTLM Communications Use Case MITRE ID Description High Volume of SMB Connections T1021.002 – SMB/Windows Admin Shares Search for a sharp increase in SMB connections that fall outside of a normal pattern. Outbound Connection Attempted Over SMB T1212 – Exploitation for Credential Access Search for external connection attempts over SMB, as this may be an attempt to harvest credential hashes. WMI Being Used to Call a Remote Service T1047 – Windows Management Instrumentation Search for WMI being used via a command line or PowerShell to call a remote service for execution. WMI Being Used for Ingress Tool Transfer T1105 – Ingress Tool Transfer Search for suspicious usage of WMI to download external resources. Forced NTLM Authentication Using SMB or WebDAV T1187 – Forced Authentication Search for potential NTLM authentication attempts using SMB or WebDAV. NTLM Relay via Coercion T1187 – Forced Authentication Monitor for NTLM authentication attempts from Domain Controllers or privileged servers to unexpected destinations, particularly to HTTP endpoints (AD CS web enrollment). Detect PetitPotam by monitoring for EfsRpcOpenFileRaw calls, DFSCoerce via DFS-related named pipe access, and PrinterBug via SpoolService RPC calls. Table 13: Detection opportunities for SMB, WMI, and NTLM communications Remote Desktop Protocol Hardening Remote Desktop Protocol (RDP) is a common method used by threat actors to remotely connect to systems, laterally move from the perimeter onto a larger scope of internal systems, and perform malicious activities (such as data theft or ransomware deployment). External-facing systems with RDP open to the internet present an elevated risk. Threat actors may exploit this vector to gain initial access to an organization and then perform lateral movement into the organization to complete their mission objectives. Proactively, organizations should scan their public IP address ranges to identify systems with RDP (TCP/3389) and other protocols (SMB – TCP/445) open to the internet. At a minimum, RDP and SMB should not be directly exposed for ingress and egress access to/from the internet. If required for operational purposes, explicit controls should be implemented to restrict the source IP addresses, which can interface with systems using these protocols. The following hardening recommendations should also be implemented. Enforce Multi-Factor Authentication If external-facing RDP must be used for operational purposes, MFA should be enforced when connecting using this method. This can be accomplished either via the integration of a third-party MFA technology or by leveraging a Remote Desktop Gateway and Azure Multifactor Authentication Server using Remote Authentication Dial-In User Service ( RADIUS ) . Leverage Network-Level Authentication For external-facing RDP servers, Network-Level Authentication (NLA) provides an extra layer of preauthentication before a connection is established. NLA can also be useful for protecting against brute-force attacks, which often target open internet-facing RDP servers. NLA can be configured either via the user interface (UI) (Figure 10) or via Group Policy (Figure 11). Figure 10: Enabling NLA via the UI Using a GPO, the setting for NLA can be configured via: Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Require user authentication for remote connections by using Network Level Authentication Enabled Figure 11: Enabling NLA via Group Policy Some caveats about leveraging NLA for RDP: The Remote Desktop client v7.0 (or greater) must be leveraged. NLA uses CredSSP to pass authentication requests on the initiating system. CredSSP stores credentials in Local Security Authority (LSA) memory on the initiating system, and these credentials may remain in memory even after a user logs off the system. This provides a potential exposure risk for credentials in memory on the source system. On the RDP server, users permitted for remote access using RDP must be assigned the Access this computer from the network privilege when NLA is enforced. This privilege is often explicitly denied for user accounts to protect against lateral movement techniques. Restrict Administrative Accounts from Leveraging RDP on Internet-Facing Systems For external-facing RDP servers, highly privileged domain and local administrative accounts should not be permitted access to authenticate with the external-facing systems using RDP (Figure 12). This can be enforced using Group Policy, configurable via the following path: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Deny log on through Terminal Services Figure 12: Group Policy configuration for restricting highly privileged domain and local administrative accounts from leveraging RDP Detection Opportunities for RDP Usage Use Case MITRE ID Description RDP Authentication Integration T1110 – Brute Force T1078 – Valid Accounts T1021.001 – Remote Desktop Protocol Existing authentication rules should include RDP attempts. This includes use cases for: Brute Force Password Spraying MFA Failures Single User MFA Failures Single Source External Authentication from an Account with Elevated Privileges Anomalous Connection Attempts over RDP T1078 – Valid Accounts T1021.001 – Remote Desktop Protocol Searching for anomalous RDP connection attempts over known RDP ports such as TCP/3389. Table 14: Detection Opportunities for RDP Usage Disabling Administrative/Hidden Shares To conduct lateral movement, threat actors may attempt to identify administrative or hidden network shares, including those that are not explicitly mapped to a drive letter and use these for remotely binding to endpoints throughout an environment. As a protective or rapid containment measure, organizations may need to quickly disable default administrative or hidden shares from being accessible on endpoints. This can be accomplished by either modifying the registry, stopping a service, or by using the MSS (Legacy) Group Policy template . Common administrative and hidden shares on endpoints include: ADMIN$ C$ D$ IPC$ Note: Disabling administrative and hidden shares on servers, specifically including domain controllers, may significantly impact the operation and functionality of systems within a domain-based environment. Additionally, if PsExec is used in an environment, disabling the admin ( ADMIN$ ) share can restrict the capability for this tool to be used to remotely interface with endpoints. Registry Method Using the registry, administrative and hidden shares can be disabled on endpoints (Figure 13 and Figure 14). Workstations HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD Name = “AutoShareWks”
Value = “0” Figure 13: Registry value disabling administrative shares on workstations Servers HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD Name = “AutoShareServer”
Value = “0” Figure 14: Registry value disabling administrative shares on servers Service Method By stopping the Server service on an endpoint, the ability to access any shares hosted on the endpoint will be disabled (Figure 15). Figure 15: Server service properties Group Policy Method Using the MSS (Legacy) Group Policy template, administrative and hidden shares can be disabled on either a server or workstation via a GPO setting (Figure 16). Computer Configuration > Policies > Administrative Templates > MSS (Legacy) > MSS (AutoShareServer) Disabled Computer Configuration > Policies > Administrative Templates > MSS (Legacy) > MSS (AutoShareWks) Disabled Figure 16: Disabling administrative and hidden shares via the MSS (Legacy) Group Policy template Detection Opportunities for Accessing Administrative or Hidden Shares Use Case MITRE ID Description Network Discovery: Suspicious Usage of the Net Command T1049 – System Network Connections Discovery T1135 – Network Share Discovery Search for suspicious use of the net command to enumerate systems and file shares within an environment. Table 15: Detection opportunities for accessing administrative or hidden shares Hardening Windows Remote Management Threat actors may leverage Windows Remote Management (WinRM) to laterally move throughout an environment. WinRM is enabled by default on all Windows Server operating systems (since Windows Server 2012 and above) , but disabled on all client operating systems (Windows 7 and Windows 10) and older server platforms (Windows Server 2008 R2). PowerShell remoting (PS remoting) is a native Windows remote command execution feature that is built on top of the WinRM protocol. Windows client (nonserver) operating system platforms where WinRM is disabled indicates that there is: No WinRM listener configured No Windows firewall exception configured By default, WinRM uses TCP/5985 and TCP/5986, which can be either disabled using the Windows Firewall or configured so that a specific subset of IP addresses can be authorized for connecting to endpoints using WinRM. WinRM and PowerShell remoting can be explicitly disabled on endpoint using either a PowerShell command (Figure 17) or specific GPO settings. PowerShell Disable-PSRemoting -Force Figure 17: PowerShell command to disable WinRM/PowerShell remoting on an endpoint Note: Running Disable-PSRemoting -Force does not prevent local users from creating PowerShell sessions on the local computer or for sessions destined for remote computers. After running the command, the message recorded in Figure 18 will be displayed. These steps provide additional hardening, but after running the Disable-PSRemoting -Force command, PowerShell sessions destined for the target endpoint will not be successful. Figure 18: Warning message after disabling PSRemoting To enforce the additional steps for disabling WinRM via PowerShell (Figure 19 through Figure 22): Stop and disable the WinRM service. Stop-Service WinRM -PassThruSet-Service WinRM -StartupType Disabled Figure 19: PowerShell command to stop and disable the WinRM service Disable the listener that accepts requests on any IP address. dir wsman:\localhost\listener

Remove-Item -Path WSMan:\Localhost\listener\ Figure 20: PowerShell commands to delete a WSMan listener Disable the firewall exceptions for WS-Management communications. Set-NetFirewallRule -DisplayName ‘Windows Remote Management (HTTP-In)’ -Enabled False Figure 21: PowerShell command to disable firewall exceptions for WinRM Restore the value of the LocalAccountTokenFilterPolicy to 0, which restricts remote access to members of the Administrators group on the computer. Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system -Name LocalAccountTokenFilterPolicy -Value 0 Figure 22: PowerShell command to configure the registry key for LocalAccountTokenFilterPolicy Group Policy Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service > Allow remote server management through WinRM Disabled If this setting is configured as Disabled , the WinRM service will not respond to requests from a remote computer, regardless of whether any WinRM listeners are configured. Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Shell > Allow Remote Shell Access Disabled This policy setting will manage the configuration of remote access to all supported shells to execute scripts and commands. Detection Opportunities for WinRM Usage Use Case MITRE ID Description Unauthorized WinRM Execution Attempt T1021.006 – Remote Services: Windows Remote Management Search for command execution attempts for WinRM on a system where WinRM has been disabled. Suspicious Process Creation Using WinRM T1021.006 – Remote Services: Windows Remote Management Search for anomalous process creation events using WinRM that deviate from an established baseline. Suspicious Network Connection Using WinRM T1021.006 – Remote Services: Windows Remote Management Search for network activity over known WinRM ports, such as TCP/5985 and TCP/5986, to identify anomalous connections that deviate from an established baseline. Remote WMI Connection Using WinRM T1021.006 – Remote Services: Windows Remote Management Search for remote WMI connection attempts using WinRM. Table 16: Detection opportunities for WinRM use Restricting Common Lateral Movement Tools and Methods Table 17 provides a consolidated summary of security configurations that can be leveraged to combat against common remote access tools and methods used for lateral movement within environments. Tool/Tactic Mitigating Security Configurations (Target Endpoints) PsExec (using the current logged-on user account, without the -u switch) If the -u switch is not leveraged, authentication will use Kerberos or NTLM for the current logged-on user of the source endpoint and will register as a Type 3 (network) logon on the destination endpoint. PsExec high-level functionality: Connects to the hidden ADMIN$ share (mapping to the C:\Windows folder) on a remote endpoint via SMB (TCP/445). Uses the Service Control Manager (SCM) to start the PSExecsvc service and enable a named pipe on a remote endpoint. Input/output redirection for the console is achieved via the created named pipe. Option 1: GPO configuration: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment Deny access to this computer from the network Deny access to this computer from the network Deny log on locally Deny log on through Terminal Services DCOM:Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) Syntax Computer Configuration > Policies > Windows Settings > Local Policies > Security Options DCOM:Machine Access Restrictions in Security Descriptor Definition Language (SDDL) Syntax Deny access to this computer from the network Option 2: Windows Firewall rule: netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=no Figure 23: PowerShell command to disable inbound file and print sharing (SMB) for an endpoint using a local Windows Firewall rule Option 3: Disable administrative and hidden shares. PsExec (with Alternative Credentials, via the -u switch) If the -u switch is leveraged, authentication will use the alternate supplied credentials and will register as a Type 3 (network) and Type 2 (interactive) logon on the destination endpoint. Option 1: GPO configuration: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment Option 2: Windows Firewall rule: netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=no Figure 24: PowerShell command to disable inbound file and print sharing (SMB) for an endpoint using a local Windows Firewall rule Remote Desktop Protocol (RDP) Option 1: GPO configuration: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment Option 2: Windows Firewall rule: netsh advfirewall firewall set rule group=”Remote Desktop” new enable=no Figure 25: PowerShell command to disable inbound Remote Desktop (RDP) for an endpoint using a local Windows Firewall rule PS remoting and WinRM Option 1: PowerShell command: Disable-PSRemoting -Force Figure 26: PowerShell command to disable PowerShell remoting for an endpoint Option 2: GPO configuration: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service > Allow remote server management through WinRM Option 3: Windows Firewall rule: netsh advfirewall firewall set rule group=”Windows Remote Management” new enable=no Figure 27: PowerShell command to disable inbound WinRM for an endpoint using a local Windows Firewall rule Distributed Component Object Model (DCOM) Option 1: GPO configuration: Computer Configuration > Policies > Windows Settings > Local Policies > Security Options Both of these settings allow an organization to define additional computer-wide controls that govern access to all DCOM–based applications on an endpoint. When users or groups that are provided permissions are specified, the security descriptor field is populated with the SDDL representation of those groups and privileges. Users and groups can be given explicit Allow or Deny privileges for both local and remote access using DCOM. Option 2: Windows Firewall rules: netsh advfirewall firewall set rule group=”COM+ Network Access” new enable=no

netsh advfirewall firewall set rule group=”COM+ Remote Administration” new enable=no Figure 28: PowerShell commands to disable inbound DCOM for an endpoint using a local Windows Firewall rule Third-party remote access applications (e.g., VNC/DameWare/ScreenConnect) that rely upon specific interactive and remote logon permissions being configured on an endpoint. GPO configuration: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment Table 17: Common lateral movement tools/methods and mitigating security controls Detection Opportunities for Common Lateral Movement Tools and Methods Use Case MITRE Description Anomalous PsExec Usage T1569.002 – System Services: Service Execution T1021.002 – Remote Services: SMB/Windows Admin Shares T1570 – Lateral Tool Transfer Search for attempted execution of PsExec on systems where PsExec is disabled or where it deviates from normal activity. Process Creation Event Involving a COM Object by Different User T1021.003 – Remote Services: Distributed Component Object Model T1078 – Valid Accounts Search for process creation events including COM objects that are initiated by an account that is not currently the logged-in user for the system. High Volume of DCOM-Related Activity T1021.003 – Remote Services: Distributed Component Object Model Search for a sharp increase in volume of DCOM-related activity. Third-Party Remote Access Applications T1219 – Remote Access Software Search for anomalous use of third-party remote access applications. This type of activity could indicate a threat actor is attempting to use third-party remote access applications as an alternate communication channel or for creating remote interactive sessions. BYOVD – EDR/AV Tampering via Vulnerable Drivers T1068 – Exploitation for Privilege Escalation T1562.001 – Impair Defenses Monitor for kernel driver installations (Sysmon Event ID 6) where the loaded driver hash matches known vulnerable drivers from the LOLDrivers project. Alert on new service creation (Event ID 7045) loading .sys files from user-writable paths (e.g., %TEMP%, %APPDATA%). RMM Tool Abuse for Lateral Movement T1219 – Remote Access Tools Monitor for installation or execution of legitimate RMM tools (ScreenConnect/ConnectWise, AnyDesk, Atera, Splashtop, TeamViewer) that are not part of the organization’s approved toolset. Monitor for new service installations matching known RMM tool signatures. Table 18: Detection opportunities for common lateral movement tools and methods Additional Endpoint Hardening To help protect against malicious binaries, malware, and encryptors being invoked on endpoints, additional security hardening technologies and controls should be considered. Examples of additional security controls for consideration for Windows-based endpoints are provided as follows. Windows Defender Application Control Windows Defender Application Control is a set of inherent configuration settings within Active Directory that provide lockdown and control mechanisms for controlling which applications and files users can run on endpoints. With this functionality, the following types of rules can be configured within GPOs: Publisher rules: Can be leveraged to allow or restrict execution of files based upon digital signatures and other attributes Path rules: Can be leveraged to allow or restrict file execution or access based upon files residing in specific path File hash rules: Can be leveraged to allow or restrict file execution based on a file’s hash Additional information related to Windows Defender Application Control . Microsoft Defender Attack Surface Reduction Microsoft Defender Attack Surface Reduction (ASR) rules can help protect against various threats, including: A threat actor launching executable files and scripts that attempt to download or run files A threat actor running obfuscated or suspicious scripts A threat actor invoking credential theft tools that interface with Local Security Authority Subsystem Service (LSASS) A threat actor invoking PsExec or WMI commands Normalizing and blocking behaviors that applications do not usually initiate as part of standardized activity Blocking executable content from email clients and web mail (phishing) ASR requires a Windows E3 license or above. A Windows E5 license provides advanced management capabilities for ASR. Additional information related to Microsoft Defender Attack Surface Reduction functionality . Controlled Folder Access Controlled folder access can help protect data from being encrypted by ransomware. Beginning with Windows 10 version 1709+ and Windows Server 2019+, controlled folder access was introduced within Windows Defender Antivirus (as part of Windows Defender Exploit Guard). Once controlled folder access is enabled, applications and executable files are assessed by Windows Defender Antivirus, which then determines if an application is malicious or safe. If an application is determined to be malicious or suspicious, it will be blocked from making changes to any files in a protected folder. Once enabled, controlled folder access will apply to a number of system folders and default locations, including: Documents C:\users\\Documents C:\users\Public\Documents Pictures C:\users\\Pictures C:\users\Public\Pictures Videos C:\users\\Videos C:\users\Public\Videos Music C:\users\\Music C:\users\Public\Music Desktop C:\users\\Desktop C:\users\Public\Desktop Favorites C:\users\\Favorites Additional folders can be added using the Windows Security application, Group Policy, PowerShell, or mobile device management (MDM) configuration service providers (CSPs). Additionally, applications can be allow-listed for access to protected folders. Note: For controlled folder access to fully function, Windows Defender’s Real Time Protection setting must be enabled. Additional information related to controlled folder access . Tamper Protection Threat actors will often attempt to disable security features on endpoints. Tamper protection either in Windows (via Microsoft Defender for Endpoint) or integrated within third-party AV/EDR platforms can help protect security tools from being modified or stopped by a threat actor. Organizations should review the configuration of security technologies that are deployed to endpoints and verify if tamper protection is (or can be) enabled to protect against unauthorized modification. Once implemented, organizations should test and validate that the tamper protection controls behave as expected as different products offer different levels of protection. Additional information related to tamper protection for Windows Defender for Endpoint . Detection Opportunities for Tamper Protection Events Use Case MITRE Description Threat Actor Attempting to Disable Security Tooling on an Endpoint T1562.001 – Disable or Modify Tools Monitor for evidence of processes or command-line arguments correlating to security tools/services being stopped. Table 19: Detection opportunities for tamper protection events 4. Credential Exposure and Account Protections Identification of Privileged Accounts and Groups Threat actors will prioritize identifying privileged accounts as part of reconnaissance efforts. Once identified, threat actors will attempt to obtain credentials for these accounts for lateral movement, persistence, and mission fulfillment. Organizations should proactively focus on identifying and reviewing the scope of accounts and groups within Active Directory that have an elevated level of privilege. An elevated level of privilege can be determined by the following criteria: Accounts or nested groups that are assigned membership into default domain and Exchange-based privileged groups (Figure 29) Accounts or nested groups that are assigned membership into security groups protected by AdminSDHolder Accounts or groups assigned permissions for organizational units (OUs) housing privileged accounts, groups, or endpoints Accounts or groups assigned specific extended right permissions either directly at the root of the domain or for OUs where permissions are inherited by child objects. Examples include: DS-Replication-Get-Changes-All Administer Exchange Information Store View Exchange Information Store Status Create-Inbound-Forest-Trust Migrate-SID-History Reanimate-Tombstones View Exchange Information Store Status User-Force-Change-Password Accounts or groups assigned permissions for modifying or linking GPOs Accounts or groups assigned explicit permissions on domain controllers or Tier 0 endpoints Accounts or groups assigned directory service replication permissions Accounts or groups with local administrative access on all endpoints (or a large scope of critical assets) in a domain To identify accounts that are provided membership into default domain-based privileged groups or are protected by AdminSDHolder , the following PowerShell cmdlets can be run from a domain controller. get-ADGroupMember -Identity “Domain Admins” -Recursive | export-csv -path \DomainAdmins.csv -NoTypeInformation

get-ADGroupMember -Identity “Enterprise Admins” -Recursive | export-csv -path \EnterpriseAdmins.csv -NoTypeInformation

get-ADGroupMember -Identity “Schema Admins” -Recursive | export-csv -path \SchemaAdmins.csv -NoTypeInformation

get-ADGroupMember -Identity “Administrators” -Recursive | export-csv -path \Administrators.csv -NoTypeInformation

get-ADGroupMember -Identity “Account Operators” -Recursive | export-csv -path \AccountOperators.csv -NoTypeInformation

get-ADGroupMember -Identity “Backup Operators” -Recursive | export-csv -path \BackupOperators.csv -NoTypeInformation

get-ADGroupMember -Identity “Cert Publishers” -Recursive | export-csv -path \CertPublishers.csv -NoTypeInformation

get-ADGroupMember -Identity “Print Operators” -Recursive | export-csv -path \PrintOperators.csv -NoTypeInformation

get-ADGroupMember -Identity “Server Operators” -Recursive | export-csv -path \ServerOperators.csv -NoTypeInformation

get-ADGroupMember -Identity “DNSAdmins” -Recursive | export-csv -path \DNSAdmins.csv -NoTypeInformation

get-ADGroupMember -Identity “Group Policy Creator Owners” -Recursive | export-csv -path \Group-Policy-Creator-Owners.csv -NoTypeInformation

get-ADGroupMember -Identity “Exchange Trusted Subsystem” -Recursive | export-csv -path \Exchange-Trusted-Subsystem.csv -NoTypeInformation

get-ADGroupMember -Identity “Exchange Windows Permissions” -Recursive | export-csv -path \Exchange-Windows-Permissions.csv -NoTypeInformation

get-ADGroupMember -Identity “Exchange Recipient Administrators” -Recursive | export-csv -path \Exchange-Recipient-Admins.csv -NoTypeInformation

get-ADUser -Filter {(AdminCount -eq 1) -And (Enabled -eq $True)} | Select-Object Name, DistinguishedName | export-csv -path \AdminSDHolder_Enabled.csv Figure 29: Commands to identify domain and exchange-based privileged accounts Any privileged accounts granted membership into additional security groups can provide a threat actor with a potential path to domain administration-level permissions based upon endpoints where the accounts have permissions to log on or remotely access systems. Ideally, only a small scope of accounts should be provided with highly privileged access within a domain. Accounts with highly privileged permissions should not be leveraged for daily use; used for interactive or remote logons to workstations, laptops, or common servers; or used for performing functions on non-domain controller (Tier 0) assets.For additional recommendations for restricting access for privileged accounts, reference the Privileged Account Logon Restrictions section of this blog post. Detection Opportunities for Privileged Accounts, Groups, and GPO Modifications Use Case MITRE Description Interactive or Remote Logon of a Highly Privileged Account to an Unauthorized System T1078 – Valid Accounts Search for logon attempts correlating to highly privileged accounts authenticating to systems that reside outside of the Tier 0 layer. Privileged Account and Group Discovery T1069 – Permission Groups Discovery T1078 – Valid Accounts Search for command-line events where a user is attempting to enumerate privileged accounts and groups. Account Added to Highly Privileged Group T1078 – Valid Accounts T1098 – Account Manipulation Identify when accounts are added to highly privileged groups. While this can occur as part of normal activity, it should be infrequent and limited to specific accounts. Modification of Group Policy Objects T1484.001 – Domain Policy Modification: Group Policy Modification Identify when GPOs are created or modified. GPOs can also be exported and reviewed to identify last modification timestamps. get-gpo -all | export-csv -path “c:\temp\gpo-listing-all.csv” -NoTypeInformation Figure 30: PowerShell cmdlet to export and review GPO creation and modification timestamps DCSync Attack T1003.006 – OS Credential Dumping Monitor for non-domain-controller sources issuing directory replication requests ( DS-Replication-Get-Changes and DS-Replication-Get-Changes-All ). Event ID 4662 with properties matching the replication GUIDs ( 1131f6aa-*, 1131f6ad-* ) from non-domain-controller source addresses is a high-fidelity indicator of DCSync. Table 20: Detection opportunities for privileged accounts, groups, and GPO modifications Privileged and Service Account Protections Identify and Review Noncomputer Accounts Configured with an SPN Accounts with service principal names (SPNs) are commonly targeted by threat actors for privilege escalation. Using Kerberos, any domain user can request a Kerberos service ticket (TGS) from a domain controller for any account configured with an SPN. Noncomputer accounts likely are configured with guessable (nonrandom) passwords. Regardless of the domain function level or the host’s Windows version, SPNs that are registered under a noncomputer account will use the legacy RC4-HMAC encryption suite rather than Advanced Encryption Standard (AES). The key used for encryption and decryption of the RC4-HMAC encryption type represents an unsalted NTLM hash version of the account’s password, which could be derived via cracking the ticket. Organizations should review Active Directory to identify noncomputer accounts configured with an SPN. Noncomputer accounts correlated to registered SPNs are likely service accounts and provide a method for a threat actor (without administrative privileges) to potentially derive (crack) the plain-text password for the account (Kerberoasting). To identify noncomputer accounts configured with an SPN, the PowerShell cmdlet referenced in Figure 31 can be run from a domain controller. Get-ADUser -Filter {(ServicePrincipalName -like “*”)} | Select-Object name,samaccountname,sid,enabled,DistinguishedName Figure 31: PowerShell cmdlet to identify noncomputer accounts configured with an SPN Where possible, organizations should deregister noncomputer accounts with SPNs configured. Where SPNs are needed, organizations should mitigate the risk associated with Kerberoasting attacks. Accounts with SPNs should be configured with strong, unique passwords (e.g., minimum 25+ characters) with the passwords rotated on a periodic basis for the accounts. Furthermore, privileges should be reviewed and reduced for these accounts to ensure that each account has the minimum required privileges needed for the intended function. Accounts with SPNs should be considered in-scope for the proactive hardening measures detailed throughout this blog post. Note: SPNs should never be associated with regular interactive user accounts. Detection Opportunities for Noncomputer Accounts Configured with an SPN Use Case MITRE ID Description Potential Kerberoasting Attempt Using RC4 T1558.003 – Steal or Forge Kerberos Tickets: Kerberoasting Searching for a Kerberos request using downgraded RC4 encryption. AS-REP Roasting T1558.004 – Steal or Forge Kerberos Tickets Monitor Event ID 4768 for Kerberos authentication requests using RC4 encryption (0x17) for accounts with the ” Do not require Kerberos preauthentication ” flag set. Unlike Kerberoasting (which targets SPNs), AS-REP Roasting targets accounts with disabled preauthentication (which should be reviewed and mitigated). Table 21: Detection opportunities for noncomputer accounts configured with an SPN Privileged Account Logon Restrictions Privileged and service account credentials are commonly used for lateral movement and establishing persistence. For any accounts that have privileged access throughout an environment, the accounts should not be used on standard workstations and laptops, but rather from designated systems (e.g., privileged access workstations [PAWs]) that reside in restricted and protected VLANs and tiers. Dedicated privileged accounts should be defined for each tier, with controls that enforce that the accounts can only be used within the designated tier. Guardrail enforcement for privileged accounts can be defined within GPOs or by using authentication policy silos (Windows Server 2012 R2 domain-functional level or above). The recommendations for restricting the scope of access for privileged accounts are based upon Microsoft’s guidance for securing privileged access. For additional information, reference: https://docs.microsoft.com/en-us/security/compass/privileged-access-access-model https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos User Rights Assignments As a proactive hardening or quick containment measure, consider blocking any accounts with privileged AD access from being able to log in (remotely or locally) to standard workstations, laptops, and common access servers (e.g., virtualized desktop infrastructure). The settings referenced as follows are configurable using user rights assignments defined within GPOs via the path of: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment Accounts delegated with domain-based privileged access should be explicitly denied access to standard workstations and laptop systems within the context of the following settings (which can be configured using GPO settings similar to what are depicted in Figure 32): Deny access to this computer from the network (also include S-1-5-114: NT AUTHORITY\Local account and member of Administrators group ) ( SeDenyNetworkLogonRight ) Deny logon as a batch job ( SeDenyBatchLogonRight ) Deny logon as a service ( SeDenyServiceLogonRight ) Deny logon locally ( SeDenyInteractiveLogonRight ) Deny logon through Terminal Services ( SeDenyRemoteInteractiveLogonRight ) Figure 32: Example of privileged account access restrictions for a standard workstation using GPO settings Additionally, using GPOs, permissions can be restricted on endpoints to protect against privilege escalation and potential data theft by reducing the scope of accounts that have the following user rights assignments: Debug programs ( SeDebugPrivilege ) Back up files and directories ( SeBackupPrivilege ) Restore files and directories ( SeRestorePrivilege ) Take ownership of files or other objects ( SeTakeOwnershipPrivilege ) Detection Opportunities for Privileged Account Logons Use Case MITRE ID Description Attempted Logon of a Privileged Account from a Nonprivileged Access Workstation T1078 – Valid Accounts Search for logon attempts correlating to highly privileged accounts authenticating to systems that reside outside of the Tier 0 layer. Table 22: Detection opportunities for privileged account logons Service Account Logon Restrictions Organizations should also consider enhancing the security of domain-based service accounts to restrict the capability for the accounts to be used for interactive, remote desktop, and, where possible, network-based logons. Minimum recommended logon hardening for service accounts (on endpoints where the service account is not required for interactive or remote logon purposes): Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment Deny logon locally ( SeDenyInteractiveLogonRight ) Deny logon through Terminal Services ( SeDenyRemoteInteractiveLogonRight ) Additional recommended logon hardening for service accounts (on endpoints where the service accounts is not required for network-based logon purposes): Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment Deny access to this computer from the network ( SeDenyNetworkLogonRight ) If a service account is only required to be leveraged on a single endpoint to run a specific service, the service account can be further restricted to only permit the account’s usage on a predefined listing of endpoints (Figure 33). Active Directory Users and Computers > Select the account Account tab Log On To button > Select the proper scope of computers for access Figure 33: Option to restrict an account to log onto specific endpoints Detection Opportunities for Service Account Logons Use Case MITRE ID Description Anomalous Logon from a Service Account T1078 – Valid Accounts Search for login attempts for a service account on a new (unexpected) endpoint. This will require baselining service accounts to expected (approved) systems. Table 23: Detection opportunities for service account logons Managed/Group Managed Service Accounts Organizations with static service accounts should review the feasibility of migrating the service accounts to be managed service accounts (MSAs) or group managed service accounts (gMSAs). MSAs were first introduced with the Windows Server 2008 R2 Active Directory schema (domain-functional level) and provide automatic password management (30-day rotation) for dedicated service accounts that are associated with running services on specific endpoints. Standard MSA: The account is associated with a single endpoint, and the complex password for the account is automatically managed and changed on a predefined frequency (30 days by default). While an MSA can only be associated with a single computer account, multiple services on the same endpoint can leverage the MSA. Group managed service account (gMSA): First introduced with Windows Server 2012 and are very similar to MSAs, but allow for a single gMSA to be leveraged across multiple endpoints. Common uses for MSAs and gMSAs: Scheduled Tasks Internet Information Services (IIS) application pools Structured Query Language (SQL) services (SQL 2012 and later) – Express editions are not supported by MSAs. Microsoft Exchange services Network Load Balancing (clustering) – gMSAs only Third-party applications that support MSAs Note: Threat actors can potentially discover accounts and groups that have permissions to read/leverage the password for a gMSA for privilege escalation and lateral movement. This can be accomplished by leveraging the get-adserviceaccount PowerShell cmdlet and enumerating the msDS-GroupMSAMembership ( PrincipalsAllowedToRetrieveManagedPassword ) configuration for a gMSA, which stores the security principals that can access the gMSA password. It is important that when configuring managed service accounts, organizations focus on restricting the scope of accounts and groups that have the ability to obtain and leverage the password for the managed service accounts and enforce structured monitoring of these accounts and groups. For additional information related to MSAs and gMSAs, reference: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/managed-service-accounts-understanding-implementing-best/ba-p/397009 https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview Detection Opportunities for Managed/Group Managed Service Accounts Use Case MITRE ID Description Group Membership Addition T1069 – Permission Groups Discovery T1098 – Account Manipulation Search for MSAs/gMSAs and the associated PrincipalsAllowedToRetrieveManagedPassword or PrincipalsAllowedToDelegateToAccount permissions, which could provide the ability to leverage the MSA/gMSA for malicious purposes. Example reconnaissance commands for querying for MSAs/gMSAs and associated attributes: get-adserviceaccount

get-adserviceaccount -filter {name -eq ‘account-name’} -prop * | select Name, MemberOf, PrincipalsAllowedToDelegateToAccount, PrincipalsAllowedToRetrieveManagedPassword Figure 34: Example reconnaissance commands for querying for MSAs/gMSAs Table 24: Detection opportunities for managed/group managed service accounts Protected Users Security Group By leveraging the Protected Users security group for privileged accounts, an organization can minimize various exposure factors and common exploitation methods by a threat actor or malware variant obtaining credentials for privileged accounts on disk or in memory from endpoints. Beginning with Microsoft Windows 8.1 and Microsoft Windows Server 2012 R2 (and above), the Protected Users security group was introduced to manage credential exposure within an environment. Members of this group automatically have specific protections applied to accounts, including: The Kerberos ticket granting ticket (TGT) expires after four hours, rather than the normal 10-hour default setting. No NTLM hash for an account is stored in LSASS, since only Kerberos authentication is used (NTLM authentication is disabled for an account). Cached credentials are blocked. A domain controller must be available to authenticate the account. WDigest authentication is disabled for an account, regardless of an endpoint’s applied policy settings. DES and RC4 cannot be used for Kerberos preauthentication (Server 2012 R2 or higher); rather, Kerberos with AES encryption will be enforced. Accounts cannot be used for either constrained or unconstrained delegation (equivalent to enforcing the Account is sensitive and cannot be delegated setting in Active Directory Users and Computers). To provide domain controller-side restrictions for members of the Protected Users security group, the domain functional level must be Windows Server 2012 R2 (or higher). Microsoft Security Advisory KB2871997 adds compatibility support for the protections enforced for members of the Protected Users security group for Windows 7, Windows Server 2008 R2, and Windows Server 2012 systems. Successful (Event IDs 303, 304) or failed (Event IDs 100, 104) logon events for members of the Protected Users security group can be recorded on domain controllers within the following event logs: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-Authentication%4ProtectedUserSuccesses-DomainController.evtx %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-Authentication%4ProtectedUserFailures-DomainController.evtx The event logs are disabled by default and must be enabled on each domain controller. The PowerShell cmdlets referenced in Figure 35 can be leveraged to enable the event logs for the Protected Users security group on a domain controller. $log1 = New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController
$log1.IsEnabled=$true
$log1.SaveChanges()

$log2 = New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController
$log2.IsEnabled=$true
$log2.SaveChanges() Figure 35: PowerShell cmdlets for enabling event logging for the Protected Users security group on domain controllers Note: Service accounts (including MSAs) should not be added to the Protected Users security group, as authentication will fail. If the Protected Users security group cannot be used, at a minimum, privileged accounts should be protected against delegation by configuring the account with the Account is Sensitive and Cannot Be Delegated flag in Active Directory. Detection Opportunities for the Protected Users Security Group Use Case MITRE ID Description Removal of Account from Protected User Group T1098 – Account Manipulation Search for an account that has been removed from the Protected Users group. Attempted Logon of an Account in the Protected User Group from a Nonprivileged Access Workstation T1078 – Valid Accounts Search for logon attempts from accounts in the Protected Users group authenticating from workstations of nonprivileged users. Table 25: Detection opportunities for the Protected Users security group Clear-Text Password Protections In addition to restricting access for privileged accounts, controls should be enforced that minimize the exposure of credentials and tokens in memory on endpoints. On older Windows versions, clear-text passwords are stored in memory (LSASS) to primarily support WDigest authentication. WDigest should be explicitly disabled on all Windows endpoints where it is not disabled by default. By default, WDigest authentication is disabled in Windows 8.1+ and in Windows Server 2012 R2+. Beginning with Windows 7 and Windows Server 2008 R2, after installing KB2871997, WDigest authentication can be configured either by modifying the registry or by using the Microsoft Security Guide GPO template from the Microsoft Security Compliance Toolkit . Registry Method HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential
REG_DWORD = “0” Figure 36: Registry key and value for disabling WDigest authentication Another registry setting that should be explicitly configured is the TokenLeakDetectDelaySecs setting (Figure 37), which will clear credentials in memory of logged-off users after 30 seconds, mimicking the behavior of Windows 8.1 and above. HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs
REG_DWORD = “30” Figure 37: Registry key and value for enforcing the TokenLeakDetectDelaySecs setting Group Policy Method Using the Microsoft Security Guide Group Policy template, WDigest authentication can be disabled via a GPO setting (Figure 38). Computer Configuration > Policies > Administrative Templates > MS Security Guide > WDigest Authentication Disabled Figure 38: Disabling WDigest authentication via the MS Security Guide Group Policy Template Additionally, an organization should verify that Allow* settings are not specified within the registry keys referenced in Figure 39, as this configuration would permit the tspkgs /CredSSP providers to store clear-text passwords in memory. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation Figure 39: Additional registry keys for hardening against clear-text password storage Group Policy Reprocessing Threat actors can manually enable WDigest authentication on endpoints by directly modifying the registry ( UseLogonCredential configured to a value of 1 ). Even on endpoints where WDigest authentication is automatically disabled by default, it is recommended to enforce the GPO settings noted as follows, which will enforce automatic group policy reprocessing for the configured (expected) settings on an automated basis. Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure security policy processing Enabled – Process even if the Group Policy objects have not changed Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure registry policy processing Enabled – Process even if the Group Policy objects have not changed Note: By default, Group Policy settings are only reprocessed and reapplied if the actual Group Policy was modified prior to the default refresh interval. As KB2871997 is not applicable for Windows XP, Windows Server 2003, and Windows Server 2008, to disable WDigest authentication on these platforms, prior to a system reboot, WDigest needs to be removed from the listing of LSA security packages within the registry (Figure 40 and Figure 41). HKLM\System\CurrentControlSet\Control\Lsa\Security Packages Figure 40: Registry key to modify LSA security packages Figure 41: LSA security package registry key before and after removal of WDigest authentication from listing of providers Detection Opportunities for WDigest Authentication Conditions Use Case MITRE ID Description Enable WDigest Authentication T1112 – Modify Registry Search for evidence of WDigest being enabled in the Windows Registry. HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential

REG_DWORD = “1” Figure 42: WDigest Windows Registry modification LSASS Memory Access T1003.002 – OS Credential Dumping – LSASS Memory Monitor for processes accessing lsass.exe memory (Sysmon Event ID 10 with GrantedAccess 0x1010 or 0x1FFFFF). Alert on any non-system process opening a handle to LSASS. Deploy LSA Protection (RunAsPPL) and Credential Guard on all supported endpoints. Table 26: Detection opportunities for WDigest authentication conditions Credential Protections When Using RDP Restricted Admin Mode for RDP Restricted Admin mode for RDP can be enabled for all end-user systems assigned to personnel that perform Remote Desktop connections to servers or workstations with administrative credentials. This feature can limit the in-memory exposure of administrative credentials on a destination endpoint when accessed using RDP. To leverage Restricted Admin RDP, the command referenced in Figure 43 can be invoked. mstsc.exe /RestrictedAdmin Figure 43: Command to invoke restricted admin RDP When an RDP connection uses the Restricted Admin mode, if the authenticating account is an administrator on the destination endpoint, the credentials for the user account are not stored in memory; rather, the context of the user account appears as the destination machine account ( domain\destination-computer$ ). To leverage Restricted Admin mode for RDP, settings must be enforced on the originating endpoint in addition to the destination endpoint. Originating Endpoint (Client Mode – Windows 7 and Windows Server 2008 R2 and above) A GPO setting must be applied to the originating endpoint initiating the remote desktop session using the Restricted Admin feature. Computer Configuration > Policies > Administrative Templates > System > Credential Delegation > Restrict delegation of credentials to remote servers Require Restricted Admin > set to Enabled Use the Following Restricted Mode > Required Restricted Admin Configuring this GPO setting will result in the registry keys noted in Figure 44 being configured on an endpoint. HKLM\Software\Policies\Microsoft\Windows\CredentialsDelegation\RestrictedRemoteAdministration
0 = Disabled
1 = Enabled

HKLM\Software\Policies\Microsoft\Windows\CredentialsDelegation\RestrictedRemoteAdministrationType
1 = Require Restricted Admin
2 = Require Remote Credential Guard
3 = Restrict Credential Delegation Figure 44: Registry settings for requiring Restricted Admin mode Destination Endpoint (Server Mode – Windows 8.1 and Windows Server 2012 R2 and above) A registry setting will need to be configured (Figure 45). HKLM\System\CurrentControlSet\Control\Lsa\DisableRestrictedAdmin
0 = Enabled
1 = Disabled Figure 45: Registry setting for enabling or disabling Restricted Admin RDP Recommended: Set the registry value to 0 to enable Restricted Admin mode. With Restricted Admin RDP, another setting that should be configured is the DisableRestrictedAdminOutboundCreds registry key (Figure 46). HKLM\System\CurrentControlSet\Control\Lsa\DisableRestrictedAdminOutboundCreds
0 = default value (doesn’t exist) – Admin Outbound Creds are Enabled
1 = Admin Outbound Creds are Disabled Figure 46: Registry setting for disabling admin outbound credentials Recommended: Set the registry value to 1 to disable admin outbound credentials. Note: With this setting set to 0 , any outbound authentication requests will appear as the system ( domain\destination-computer$) that a user connected to using Restricted Admin mode. Setting this to 1 disables the ability to authenticate to any downstream network resources when attempting to authenticate outbound from a system that a user connected to using Restricted Admin mode for RDP. For additional information regarding Restricted Admin mode for RDP, reference: https://support.microsoft.com/kb/2973351 https://blogs.technet.microsoft.com/kfalde/2013/08/14/restricted-admin-mode-for-rdp-in-windows-8-1-2012-r2/ Detection Opportunities for Restricted Admin Mode for RDP Use Case MITRE ID Description Disable Restricted Admin Mode for RDP T1112 – Modify Registry Search for an account disabling Restricted Admin mode for RDP in the Windows Registry. HKLM\System\CurrentControlSet\Control\Lsa\DisableRestrictedAdmin

REG_DWORD = “1” Figure 47: Restricted Admin mode for RDP being disabled in the Windows Registry on a destination endpoint Disable Require Restricted Admin T1484.001 – Domain Policy Modification: Group Policy Modification Search for the Require Restricted Admin option being disabled within a GPO configuration. Computer Configuration > Policies > Administrative Templates > System > Credential Delegation > Restrict delegation of credentials to remote servers

“Require Restricted Admin” > set to Disabled Figure 48: Require Restricted Admin being disabled in a GPO Table 27: Detection opportunities for Restricted Admin Mode for RDP Windows Defender Remote Credential Guard For Windows 10 and Windows Server 2016 endpoints, Windows Defender Remote Credential Guard can be leveraged to reduce the exposure of privileged accounts in memory on destination endpoints when Remote Desktop is used for connectivity. With Remote Credential Guard, all credentials remain on the client (origination system) and are not directly exposed to the destination endpoint. Instead, the destination endpoint requests service tickets from the source as needed. When a user logs in via RDP to an endpoint that has Remote Credential Guard enabled, none of the SSPs in memory store the account’s clear-text password or password hash. Note that Kerberos tickets remain in memory to allow interactive (and single sign-on [SSO]) experiences from the destination server. The Remote Desktop client (origination) host: Must be running at least Windows 10 (v1703) to be able to supply credentials Must be running at least Windows 10 (v1607) or Windows Server 2016 to use the user’s signed-in credentials (no prompt for credentials) User’s account must be able to sign into both the client (origination) and the remote (destination) endpoint Must be running the Remote Desktop Classic Windows application Must use Kerberos authentication to connect to the remote host The Remote Desktop Universal Windows Platform application does not support Windows Defender Remote Credential Guard. Note: If the client cannot connect to a domain controller, then RDP attempts to fall back to NTLM. Windows Defender Remote Credential Guard does not allow NTLM fallback because this would expose credentials to risk. The Remote Desktop remote (destination) host: Must be running at least Windows 10 (v1607) or Windows Server 2016 Must allow Restricted Admin connections Must allow the client’s domain user to access Remote Desktop connections Must allow delegation of nonexportable credentials To enable Remote Credential Guard on the client (origination) host using a GPO configuration: Computer Configuration > Administrative Templates > System > Credentials Delegation > Restrict delegation of credentials to remote servers To require either Restricted Admin mode or Windows Defender Remote Credential Guard, choose Prefer Windows Defender Remote Credential Guard . In this configuration, Remote Credential Guard is preferred, but it will use Restricted Admin mode (if supported) when Remote Credential Guard cannot be used. Neither Remote Credential Guard nor Restricted Admin mode for RDP will send credentials in clear text to the Remote Desktop server. To require Remote Credential Guard, choose Require Windows Defender Remote Credential Guard . In this configuration, a Remote Desktop connection will succeed only if the remote computer meets the requirements for Remote Credential Guard. To enable Remote Credential Guard on the remote (destination) host, see Figure 49. HKLM\System\CurrentControlSet\Control\Lsa
Registry Entry: DisableRestrictedAdmin
Value: 0
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD Figure 49: Registry key and command options to enable Remote Credential Guard on a remote (destination) host To leverage Remote Credential Guard, use the command referenced in Figure 50. mstsc.exe /remoteguard Figure 50: Command to leverage Remote Credential Guard Detection Opportunities for Windows Defender Remote Credential Guard Use Case MITRE ID Description Disable Remote Credential Guard T1112 – Modify Registry Search for an account disabling Remote Credential Guard in the Windows Registry. HKLM\System\CurrentControlSet\Control\Lsa

Registry Entry: DisableRestrictedAdmin

Value: 1 Figure 51: Remote Credential Guard being disabled in the Windows Registry on a destination endpoint Disable Require Remote Credential Guard T1484.001 – Domain Policy Modification: Group Policy Modification Search for the Require Remote Credential Guard option being disabled within a GPO configuration. Computer Configuration > Administrative Templates > System > Credentials Delegation > Restrict delegation of credentials to remote servers Figure 52: Remote Credential Guard being disabled in a GPO Table 28: Detection opportunities for Windows Defender Remote Credential Guard Restrict Remote Usage of Local Accounts Local accounts that exist on endpoints are often a common avenue leveraged by threat actors to laterally move throughout an environment. This tactic is especially impactful when the password for the built-in local administrator account is configured to the same value across multiple endpoints. To mitigate the impact of local accounts being leveraged for lateral movement, organizations should consider both limiting the ability of local administrator accounts to establish remote connections and creating unique and randomized passwords for local administrator accounts across the environment. KB2871997 introduced two well-known SIDs that can be leveraged within GPO settings to restrict the use of local accounts for lateral movement. S-1-5-113: NT AUTHORITY\Local account S-1-5-114: NT AUTHORITY\Local account and member of Administrators group Specifically, the SID S-1-5-114: NT AUTHORITY\Local account and member of Administrators group is added to an account’s access token if the local account is a member of the BUILTIN\Administrators group. This is the most beneficial SID to leverage to help stop a threat actor (or ransomware variant) that propagates using credentials for any local administrative accounts. Note: For SID S-1-5-114: NT AUTHORITY\Local account and member of Administrators group , if Failover Clustering is used, this feature should leverage a nonadministrative local account ( CLIUSR ) for cluster node management. If this account is a member of the local Administrators group on an endpoint that is part of a cluster, blocking the network logon permissions can cause cluster services to fail. Be cautious and thoroughly test this configuration on servers where Failover Clustering is used. Step 1 – Option 1: S-1-5-114 SID To mitigate the use of local administrative accounts from being used for lateral movement, use the SID S-1-5-114: NT AUTHORITY\Local account and member of Administrators group within the following settings: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment Deny access to this computer from the network ( SeDenyNetworkLogonRight ) Deny logon as a batch job ( SeDenyBatchLogonRight ) Deny logon as a service ( SeDenyServiceLogonRight ) Deny logon through Terminal Services ( SeDenyRemoteInteractiveLogonRight ) Debug programs ( SeDebugPrivilege : Permission used for attempted privilege escalation and process injection) Step 1 – Option 2: UAC Token-Filtering An additional control that can be enforced via GPO settings pertains to the usage of local accounts for remote administration and connectivity during a network logon. If the full scope of permissions (referenced previously) cannot be implemented in a short timeframe, consider applying the User Account Control (UAC) token-filtering method to local accounts for network-based logons. To leverage this configuration via a GPO setting: Download the Security Compliance Toolkit ( https://www.microsoft.com/en-us/download/details.aspx?id=55319 ) to use the MS Security Guide ADMX file. Once downloaded, the SecGuide.admx and SecGuide.adml files must be copied to the \Windows\PolicyDefinitions and \Windows\PolicyDefinitions\en-US directories respectively. If a centralized GPO store is configured for the domain, copy the PolicyDefinitions folder to the C:\Windows\SYSVOL\sysvol\\Policies folder. GPO Setting Computer Configuration > Policies > Administrative Templates > MS Security Guide > Apply UAC restrictions to local accounts on network logons Enabled Once enabled, the registry value (Figure 53) will be configured on each endpoint. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy

REG_DWORD = “0” (Enabled) Figure 53: Registry key and value for enabling UAC restrictions for local accounts When set to 0 , remote connections with high-integrity access tokens are only possible using either the plain-text credential or password hash of the RID 500 local administrator (and only then depending on the setting of FilterAdministratorToken , which is configurable via the GPO setting of User Account Control: Admin Approval Mode for the built-in Administrator account ). The FilterAdministratorToken option can either enable (1) or disable (0) (default) Admin Approval mode for the RID 500 local administrator. When enabled, the access token for the RID 500 local administrator account is filtered and therefore UAC is enforced for this account (which can ultimately stop attempts to leverage this account for lateral movement across endpoints). GPO Setting Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > User Account Control: Admin Approval Mode for the built-in Administrator account Once enabled, the registry value (Figure 54) will be configured on each endpoint. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken

REG_DWORD = “1” (Enabled) Figure 54: Registry key and value for requiring Admin Approval Mode for local administrative accounts Note: It is also prudent to ensure that the default setting for User Account Control: Run all administrators in Admin Approval Mode ( EnableLUA option) is not changed from Enabled (default, as shown in Figure 55) to Disabled . If this setting is disabled, all UAC policies are also disabled . With this setting disabled, it is possible to perform privileged remote authentication using plain-text credentials or password hashes with any local account that is a member of the local Administrators group. GPO Setting Computer Configuration > Policies > Administrative Templates > MS Security Guide > User Account Control: Run all administrators in Admin Approval Mode Enabled Once enabled, the registry value (Figure 55) will be configured on each endpoint. This is the default setting. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA

REG_DWORD = “1” (Enabled) Figure 55: Registry key and value for requiring Admin Approval Mode for all local administrative accounts UAC access token filtering will not affect any domain accounts in the local Administrators group on an endpoint. Step 2: LAPS In addition to blocking the use of local administrator accounts from remote authentication to access endpoints, an organization should align a strategy to enforce password randomization for the built-in local administrator account. For many organizations, the easiest way to accomplish this task is by deploying and leveraging Microsoft’s Local Administrator Password Solutions (LAPS). Additional information regarding LAPS , and here too . Detection Opportunities for Local Accounts Use Case MITRE ID Description Attempted Remote Logon of Local Account T1078.003 – Valid Accounts: Local Accounts Search for remote logon attempts for local accounts on an endpoint. Table 29: Detection opportunities for local accounts Active Directory Certificate Services (AD CS) Protections Active Directory Certificate Services (AD CS) is Microsoft’s implementation of Public Key Infrastructure (PKI) and integrates directly with Active Directory forests and domains. It can be utilized for a variety of purposes, including digital signatures and user authentication. Certificate Templates are used in AD CS to issue certificates that have been preconfigured for particular tasks. They contain settings and rules that are applied to incoming certificate requests and provide instructions on how a valid certificate request is provided. In June of 2021, SpecterOps published a blog post named Certified Pre-Owned , which details their research into possible attacks against AD CS. Since that publication, Mandiant has continued to observe both threat actors and red teamers enhance targeting of AD CS in support of post-compromise objectives. Mandiant’s blog post and hardening guide address the continued abuse scenarios and AD CS attack vectors identified through our frontline observations of recent security breaches. Discover Vulnerable Certificate Templates Certificate templates that have been configured and published by AD CS are stored in Active Directory as objects with an object class of pKICertificateTemplate and can be discovered by blue teams as well as threat actors. Any account that is authenticated to Active Directory can query LDAP directly, with the built-in Windows command certutil.exe , or with specialized tools such as PSPKIAudit , Certipy , and Certify . Mandiant recommends using one of these methods to discover vulnerable certificate templates. Harden Vulnerable Certificate Templates Once discovered, vulnerable certificate templates should be hardened to prevent abuse. Ensure that all domain controllers and Certificate Authority servers are patched with the latest updates and hotfixes. After installing Windows update ( KB5014754 ) and monitoring/remediating for Event IDs 39 and 41, configure Active Directory to support full enforcement mode to reject authentications based on weaker mappings in certificates. Using one of the aforementioned methods, regularly review published certificate templates, specifically for any settings related to SAN specifications configured in existing templates. Review the security permissions assigned to all published certificate templates and validate the scope of enrollment and write permissions are delegated to the correct security principals. Review published templates configured with the following Enhanced Key Usages (EKUs) that support domain authentication and verify the operational requirement for these configurations. Any Purpose (2.5.29.37.0) Subordinate CA (None) Client Authentication (1.3.6.1.5.5.7.3.2) PKINIT Client Authentication (1.3.6.1.5.2.3.4) Smart Card Logon (1.3.6.1.4.1.311.20.2.2) For templates with sensitive Enhanced Key Usage (EKU), limit enrollment permissions to predefined users or groups, as certificates with EKUs can be used for multiple purposes. Access control lists for templates should be audited to ensure that they align with the principle of least privilege. Templates that allow for domain authentication should be carefully reviewed to verify that built-in groups that contain a large scope of accounts are not assigned enrollment permissions. Example: built-in groups that could increase the risk for abuse include: Everyone NT AUTHORITY\Authenticated Users Domain Users Domain Computers Where possible, enforce “CA Certificate Manager approval” for any templates that include a SAN as an issuance requirement. This will require that any certificate issuance requests be manually reviewed and approved by an identity assigned the “Issue and Manage Certificates” permission on a certificate authority server. Ensure that Certificate Authorities have not been configured to accept any SAN (irrelevant of the template configuration). This is a non-default configuration and should be avoided wherever possible. This abuse vector is mitigated by KB5014754, but until enforcement of strong mappings is enforced, abuse could still occur based upon historical certificates missing the new OID containing the requester’s SID. For additional information, reference the following Microsoft article . Treat both root and subordinate certificate authorities as Tier 0 assets and enforce logon restrictions or authentication policy silos to limit the scope of accounts that have elevated access to the servers where certificate services are installed and configured. Audit and review the NTAuthCertificates container in AD to validate the referenced CA certificates, as this container references CA certificates that enable authentication within AD. Before authenticating a principal, AD checks the NTAuthCertificates container for the CA specified in the authenticating certificate’s Issuer field to validate the authenticity of the CA. If rogue or unauthorized CA certificates are present, this could be indicative of a security event that requires further triage and investigation. To avoid the theft of a CA’s private keys (e.g., via the DPAPI backup protocol), protect the private keys by leveraging a Hardware Security Module (HSM) on servers where certificate authority services are installed and configured. Enforce multifactor authentication (MFA) for CA and AD management and operations. Keep the root CA offline and use subordinate CAs to issue certificates. Regularly validate and identify potential misconfigurations within existing certificate templates using the built-in Windows command certutil.exe , or with specialized tools such as PSPKIAudit , Certipy , and Certify . Public tools (e.g., PSPKIAudit, Certipy, or Certify) may be flagged by EDR products as they are frequently used by red teams and threat actors. To mitigate NTLM Relay attacks in AD CS, enable Extended Protection For Authentication for Certificate Authority Web Enrollment and Certificate Enrollment Web Service. Additionally, require that AD CS accept only HTTPS connections. For additional details, reference the following Microsoft Article . Enable audit logging for Certificate Services on CA servers and Kerberos Authentication Service on Domain Controllers by using group policy. Ensure that event IDs 4886 and 4887 from CA servers and 4768 from domain controllers are aggregated in the organization’s SIEM solution. Enable the audit filter on each CA server. This is a bitmask value that represents the seven different audit categories that can be enabled; if all values are enabled, the audit filter will have a value of 127. Log and monitor events from the CA servers and domain controllers to enhance detections related to AD CS activities (steps 16 and 17 are needed to ensure the appropriate logs are generated). Detection Opportunities for AD CS Abuse Certificate Request with Mismatched SAN (ESC1) T1649 – Steal or Forge Authentication Certificates Monitor event IDs 4886 (certificate request received) and 4887 (certificate issued) on CA servers. Alert when the requesting account’s identity differs from the Subject Alternative Name (SAN) specified in the certificate. NTLM Relay to AD CS Web Enrollment (ESC8) T1557.001 – LLMNR/NBT-NS Poisoning and SMB Relay T1649 – Steal or Forge Authentication Certificates Monitor for NTLM authentication to AD CS HTTP enrollment endpoints from domain controllers or privileged servers. Correlate with PetitPotam coercion indicators. This attack chain provides a direct path from any domain user to Domain Admin. Table 30: Detection opportunities for AD CS abuse 5. Preventing Destructive Actions in Kubernetes and CI/CD Pipelines Organizations should implement a proactive, defense-in-depth technical hardening strategy to systematically address foundational security gaps and mitigate the risk of destructive actions across their Kubernetes environments and Continuous Integration/Continuous Delivery or Deployment (CI/CD) pipelines. Adversaries increasingly target the CI/CD pipeline and the Kubernetes control plane because they serve as centralized hubs with direct access to application deployments and underlying infrastructure. Source and Build Compromise: Threat actors target code repositories (e.g., GitHub, GitLab, Azure DevOps) and build environments to steal injected environment variables and secrets. Attackers can then commit malicious workflow files designed to exfiltrate repository data or deploy unauthorized infrastructure. Container Registry Poisoning: By compromising developer credentials or CI/CD pipeline permissions, attackers overwrite legitimate application images in the container registry. When the Kubernetes cluster pulls the updated image, it unknowingly deploys a poisoned container embedded with backdoors, ransomware, or destructive data-wiping logic. Cluster-Level Destruction: Once an attacker gains a foothold inside the Kubernetes cluster, they often abuse over-permissive role-based access control (RBAC) configurations. This provides the capability to execute destructive commands using application programming interfaces (APIs) (e.g., kubectl delete deployments), wipe persistent volumes, or delete critical namespaces, effectively causing a loss of availability and application denial of service. Secrets Extraction and Lateral Movement: Attackers routinely execute Kubernetes-specific attack tools to harvest secrets from compromised Kubernetes pods. These secrets often contain database passwords and cloud identity and access management (IAM) keys, allowing the attacker to pivot out of the cluster and impact cloud-based resources. Additional information related to securing CI/CD . Hardening and Mitigation Guidance To defend against CI/CD compromises and destructive actions within Kubernetes, organizations must enforce strict identity boundaries, cryptographic trust, and a least-privilege architecture. Isolate the Kubernetes Control Plane: Disable unrestricted and public internet access to the Kubernetes API server. For managed services like GKE, EKS, and AKS, ensure the control plane is configured as a private endpoint or heavily restricted via authorized network IP allow-listing. Access to the API should only be permitted from trusted, designated internal management subnets or secure corporate VPNs. Secure Management Interfaces and CI/CD Pipelines: Enforce mandatory MFA for all access to infrastructure management platforms, including source code repositories such as GitLab/GitHub, and container registries. Utilize hardened container images (e.g., Chainguard containers, Docker Hardened Images) as base images. Implement software supply chain security frameworks (like SLSA ) by requiring image signing, provenance generation, and admission controllers (such as Binary Authorization). This ensures that the Kubernetes cluster will definitively reject and block any unverified or poisoned container images from running. Enforce Strict RBAC and Least Privilege: To limit the “blast radius” of a compromised pod, restrict the use of the cluster-admin role and strictly prohibit wildcard (*) permissions for standard service accounts. Workloads must run under strict security contexts—blocking containers from executing as root, preventing privilege escalation, and restricting access to the underlying worker node (e.g., disabling hostPID and hostNetwork). Implement Immutable Cluster Backups: Protect the cluster’s state (etcd) and stateful workload data (Persistent Volumes) by utilizing immutable backup repositories. This ensures that even if an attacker gains administrative access to the cluster or CI/CD pipeline and attempts to maliciously delete all resources, the backups cannot be destroyed or altered. Enable Audit Logging and Threat Detection: Ensure Kubernetes Control Plane audit logs, node-level telemetry, and CI/CD pipeline logs are actively forwarded to a centralized SIEM. Deploy dedicated container threat detection capabilities to immediately alert on malicious exec commands, suspicious Kubernetes enumeration tools, or bulk data deletion attempts within the pods. Additional information related to securing Kubernetes . Detection Opportunities for Kubernetes and CI/CD Use Case MITRE ID Description Bulk Kubernetes Resource Deletion T1485 – Data Destruction Monitor Kubernetes API audit logs for bulk delete operations targeting Deployments, StatefulSets, Persistent Volume Claims, Namespaces, or ConfigMaps. Unsigned or Modified Container Image Deployed to Cluster T1525 – Implant Internal Image Monitor container registries and Kubernetes admission events for deployment of images that fail signature verification, lack provenance attestation, or originate from untrusted registries. Anomalous Kubernetes Secret Access T1552.007 – Unsecured Credentials: Container API Monitor Kubernetes audit logs for API calls to /api/v1/secrets or /api/v1/namespaces/*/secrets from service accounts or users that do not normally access secrets. Alert on bulk secret enumeration and on access to secrets in sensitive namespaces. Unauthorized Modification to CI/CD Pipeline Configuration T1195.002 – Supply Chain Compromise: Compromise Software Supply Chain Monitor source code repositories for modifications to CI/CD pipeline configuration files. Alert on changes to pipeline definitions made by accounts that are not members of designated pipeline-owner groups, or changes pushed code outside of an approved pull request/merge request workflow. Privileged Container or Host Namespace Access T1611 – Escape to Host Monitor Kubernetes audit logs for pod creation or modification events requesting privileged security contexts, host namespace access, or volume mounts to sensitive host paths. These configurations allow container escape and direct access to the underlying worker node. Alert on any workload requesting these capabilities outside or pre-approved system namespaces. Kubernetes Audit Logging or Security Agent Tampering T1562.007 – Impair Defenses: Disable or Modify Cloud Firewall Monitor for modifications to Kubernetes API server audit policy configurations, deletion or redirection of log export sinks, and disablement or removal of container runtime security agents. Alert on changes to cluster-level logging configurations in managed services (GKE Cloud Audit Logs, EKS Control Plane Logging, AKS Diagnostic Settings) including disablement of API server, authenticator, or scheduler log streams. Table 31: Detection opportunities for Kubernetes and CI/CD Conclusion Destructive attacks, including ransomware, pose a serious threat to organizations. This blog post provides practical guidance on protecting against common techniques used by threat actors for initial access, reconnaissance, privilege escalation, and mission objectives. This blog post should not be considered as a comprehensive defensive guide for every tactic, but it can serve as a valuable resource for organizations to prepare for such attacks. It is based on front-line expertise with helping organizations prepare, contain, eradicate, and recover from potentially destructive threat actors and incidents.

Original: https://cloud.google.com/blog/topics/threat-intelligence/preparation-hardening-destructive-attacks/
Look What You Made Us Patch: 2025 Zero-Days in Review

Source: Threat Intelligence | Published: 2026-03-05T14:00:00+00:00 | Score: 15.635

Written by: Casey Charrier, James Sadowski, Zander Work, Clement Lecigne, Benoît Sevens, Fred Plan Executive Summary Google Threat Intelligence Group (GTIG) tracked 90 zero-day vulnerabilities exploited in-the-wild in 2025. Although that volume of zero-days is lower than the record high observed in 2023 (100), it is higher than 2024’s count (78) and remained within the 60–100 range established over the previous four years, indicating a trend toward stabilization at these levels. In 2025, we continued to observe the structural shift, first identified in 2024, toward increased enterprise exploitation. Both the raw number (43) and proportion (48%) of vulnerabilities impacting enterprise technologies reached all-time highs, accounting for almost 50% of total zero-days exploited in 2025. We observed a sustained decrease in detected browser-based exploitation, which fell to historical lows, while seeing increased abuse of operating system vulnerabilities. State-sponsored espionage groups continue to prioritize edge devices and security appliances as prime entry points into victim networks, with just over half of attributed zero-day exploitation by these groups focused on these technologies. Commercial surveillance vendors (CSVs) maintained an interest in mobile and browser exploitation, adapting and expanding their exploit chains to bypass more recently implemented security boundaries and other mobile security improvements. Multiple intrusions linked to BRICKSTORM malware deployment demonstrated a range of objectives, but the targeting of technology companies demonstrated the potential theft of valuable IP to further the development of zero-day exploits. Key Takeaways Complexity drives higher mobile vulnerability counts. Mobile zero-day discovery counts fluctuated over the last three years, dropping from 17 in 2023 to 9 in 2024, before rebounding to 15 in 2025. As vendor mitigations evolve and increasingly prevent more simplistic exploitation, threat actors have been forced to expand or adjust their techniques. In some cases, attackers have increased the number of chained vulnerabilities to reach desired levels of access within highly protected components. Conversely, threat actors have also managed successful exploitation with fewer or singular bugs by targeting lower levels of access within a single capability, such as an application or service. Enterprise software and edge devices remain prime targets. Marking a new high, 48% of 2025’s zero-days targeted enterprise-grade technology. Increased exploitation of security and networking devices highlights the critical risk that can be posed by trusted edge infrastructure, while targeting of enterprise software exhibits the value of highly interconnected platforms that provide privileged access across networks and data assets. Networking and security appliances continued to be highly targeted, by a variety of threat actors, to gain initial access. Commercial surveillance vendors (CSVs) further reduce barriers to zero-day access. For the first time since we began tracking zero-day exploitation, we attributed more zero-days to CSVs than to traditional state-sponsored cyber espionage groups. This illustrates the expansion of access to zero-day exploitation via these vendors to a wider array of customers than ever before. People’s Republic of China (PRC)-nexus cyber espionage groups continue to dominate traditional state-sponsored espionage zero-day exploitation. Consistent with the trend we have observed for nearly a decade, in comparison to other state sponsors, PRC-nexus groups remained the most prolific users of zero-day vulnerabilities in 2025. These groups, such as UNC5221 and UNC3886, continued to focus heavily on security appliances and edge devices to maintain persistent access to strategic targets. Zero-day exploitation by financially motivated threat groups ties previous high. In 2025, we attributed the exploitation of 9 zero-days to confirmed or likely financially motivated threat groups. This nearly matches the total volume of 2023 and represents a higher proportion of all attributed vulnerabilities in 2025. 2026 Zero-Day Forecast Targets and Techniques Continue to Expand As certain vendors continue to drive improvements that have made vulnerability exploitation more difficult, particularly in the browser and mobile space, adversaries will continue to adapt with more expansive techniques and diverse targets. Enterprise exploitation will continue to be further enabled by the breadth of applications used across infrastructure. Increased numbers of software, devices, and applications expand attack surfaces, with successful exploitation requiring only a single point of failure to achieve a breach. AI Changes the Game We anticipate that AI will accelerate the ongoing race between attackers and defenders in 2026 creating a more dynamic threat environment. We expect adversaries will utilize AI to automate and scale attacks by accelerating reconnaissance, vulnerability discovery, and exploit development. Reducing the time required for these phases will place further pressure on defenders to better detect and respond to zero-day exploitation. At the same time, AI will empower defenders to harness tools like agentic solutions to enhance security operations. AI agents can proactively discover and help patch previously unknown security flaws, enabling vendors to neutralize vulnerabilities before exploitation. Using Access for Research A BRICKSTORM malware campaign in 2025 , attributed to PRC-nexus espionage operators, may indicate a new paradigm for zero-day exploitation where data theft has the potential to enable long-term zero-day development. Instead of just exfiltrating sensitive client data, the threat actors targeted intellectual property from the victim companies, potentially including source code and proprietary development documents. This IP could be used to discover new vulnerabilities in the vendor’s software, not only posing a threat to the victims themselves but also to victims’ downstream customers. Scope This report describes what Google Threat Intelligence Group (GTIG) knows about zero-day exploitation in 2025. GTIG defines a zero-day as a vulnerability that was maliciously exploited in the wild before a patch was made publicly available. The following analysis leverages original research conducted by GTIG combined with reliable open-source reporting, though we cannot independently confirm the reports of every source. Research in this space is dynamic and the numbers may adjust due to the ongoing discovery of past incidents. Our analysis represents exploitation tracked by GTIG but may not reflect all zero-day exploitation. The numbers presented here reflect our best understanding of current data, and we note that all zero-days included in our 2025 dataset have patches available. GTIG acknowledges that the trends observed and discussed in this report are based on detected and disclosed zero-days, with a cutoff date of Dec. 31, 2025. A Numerical Analysis Figure 1: Zero-days by year GTIG tracked 90 vulnerabilities that were disclosed in 2025 and exploited as zero-days. This number is consistent with a consolidating upward trend that we have observed over the last five years; the total annual volume of zero-days has fluctuated within a 60-100 range over this time period, but has remained elevated compared to pre-2021 levels. As certain categories of exploitation shift over time, whether due to vendor mitigations or newer high-value opportunities, total zero-day counts continue to appear within an expected range, rather than seeing drastic overall decreases or increases. Enterprise Exploitation Expands Further in 2025 Figure 2: 2025 zero-days in end-user vs enterprise products Enterprise Technologies We identified 43 (48%) zero-days in enterprise software and appliances in 2025, up from 36 (46%) in 2024. This consistent proportion underscores the shift toward enterprise infrastructure as a structural change in the threat landscape, reflecting the value of tools that enable privilege escalation, high-level access, and broad scale of impact. Security & Networking: These vulnerabilities made up about half (21) of the enterprise-related zero-days in 2025, remaining a prominent target for achieving code execution and unauthorized access via privileged infrastructure components. A lack of input validation and incomplete authorization processes were common flaws within these products, demonstrating how basic systemic failures continue to persist, but are fixable with proper implementation standards and approaches. Edge devices–often including security and networking devices–sit at the perimeter of an organization’s infrastructure and remain high value targets . The absence of EDR technology on most edge devices, like routers, switches, and security appliances, can create a blind spot for defenders, making it an ideal attack surface. This limitation can hinder the ability to detect anomalies or gather host-based evidence once these devices are compromised. While 14 zero-days in 2025 were identified as affecting edge devices, this figure likely underrepresents the true scale of activity due to inhibited detection capabilities. Enterprise Software: High-profile exploitation of enterprise tools and virtualization technologies demonstrates that attackers are deeply embedding themselves in critical business infrastructure. Threat actors continue to pursue the most vulnerable and exposed assets to work around mitigations that may exist in specific areas of or products within an infrastructure. End User Platforms and Products In 2025, 52% (47) of the tracked zero-days were used to exploit end-user platforms and products. Operating Systems (OSs): OSs, including both desktop and mobile, were the most exploited product category in 2025, accounting for 44% (39) of all zero-days. This is a rise from previous years when comparing both raw numbers (31 in 2024, and 33 in 2023) and proportions of total zero-day exploitation (40% in 2024 and 33% in 2023). Desktop OS zero-days have fluctuated between 16 and 23 annually while maintaining a gradual upward trajectory, illustrating the foundational role of these platforms and the massive scale of effect permitted by OS-level exploitation. Mobile Devices: Mobile OS exploitation in particular saw a notable increase, with a total of 15 zero-days in 2025 compared to the 9 identified in 2024. Given that we observed 17 mobile-related zero-days in 2023, the following factors likely accounted for this temporary decline and the subsequent resurgence in activity: Multiple exploit chains discovered in 2025 included three or more vulnerabilities, inflating the number of individual vulnerabilities required to achieve a single objective. Threat researchers discovered more complete exploit chains in 2025 than have been found in the past, when sometimes only partial chains or a single vulnerability was identified and could be accounted for. Threat actors, and CSVs in particular, have found novel techniques to bypass new security boundary implementations. Browsers: Browsers accounted for less than 10% of 2025 zero-day exploitation, a marked decrease from the browser-heavy years of 2021-2022. This suggests that browser hardening measures are working. However, we also assess that attackers’ operational security has improved and therefore made their actions more difficult to observe and track, potentially reducing the volume of observed exploitation in this space. Exploitation by Vendor Figure 3: 2025 zero-day exploitation by vendor 2025’s exploited vendors followed the same pattern we observed last year, with big tech experiencing the most zero-day exploitation and security vendors following directly behind. Big tech companies continue to dominate the user base for consumer products, making them prime targets for exploitation, particularly in desktop OSs , browsers and mobile systems . Cisco and Fortinet remain commonly targeted networking and security vendors, while Ivanti and VMware continue to see exploitation that reflects the high value threat actors place on VPNs and virtualization platforms. We observed 20 vendors who were exploited by just one zero-day each, further demonstrating threat actors’ success in targeting varying vendors and products to find successful footholds in desired targets. Types of Exploited Vulnerabilities As observed in prior years, zero-day exploitation was primarily used to achieve remote code execution, followed by gaining privilege escalation. These were especially common consequences in observed exploitation of big tech and security vendors. Both code execution and unauthorized access were common goals of network and edge infrastructure exploitation, displaying the advantage of exploiting high-privilege assets with widespread reach across systems and networks. 2025 saw an array of both structural design flaws and pervasive implementation issues, exemplifying the omnipresence of known, yet prolific, problems. Injection & Deserialization: Command injection and deserialization were critical vectors in the enterprise space. These types of vulnerabilities often allow for reliable remote code execution (RCE) without the complexity of memory corruption exploits. SQL and command injection vulnerabilities were common in web-facing enterprise appliances, providing rudimentary avenues for initial access. Memory Corruption : Threat actors continued to rely on memory corruption, with memory safety issues (particularly use-after-free [UAF] and out-of-bounds write) accounting for roughly 35% of the vulnerabilities. UAF weaknesses remained a top vector for user-centered products like browsers and OS kernels. Access Control: The prevalence of authentication and authorization bypass vulnerabilities highlights the difficulty edge devices face in securing both the network perimeter and their own administrative interfaces. Logic and Design Flaws: Frequently exploited in enterprise appliances, these issues represent fundamental architectural weaknesses where the system’s intended logic or design is inherently insecure. Because the software is behaving as designed, these flaws are harder for vendors to detect. Who Is Driving Exploitation Figure 4: Attributed 2025 zero-day exploitation Commercial Surveillance Vendor Exploitation Grows For the first time since we started tracking zero-day exploitation, we attributed more exploitation to CSVs than to traditional state-sponsored cyber espionage groups. Despite these actors’ increased focus on operational security that likely hinders discovery, this continues to reflect a trend we began to observe over the last several years–a growing proportion of zero-day exploitation is conducted by CSVs and/or their customers, demonstrating a slow but sure movement in the landscape. Historically, traditional state-sponsored cyber espionage groups have been the most prolific attributed users of zero-day vulnerabilities. Over the last few years, the increase of zero-day exploitation attributed to CSVs and their customers has demonstrated the growing ability of these vendors to provide zero-day access to a wider range of threat actors than ever before. GTIG has reported extensively on the capabilities CSVs provide their clients as well as how many CSV customers use zero-day exploits in attacks which erode civil liberties and human rights. In late 2025, we reported on how Intellexa, a prolific procurer and user of zero-days, adapted its operations and tool suite and continues to deliver extremely capable spyware to high paying customers. People’s Republic of China (PRC)-Nexus Cyber Espionage Groups Still Most Prolific Although the proportion of 2025 zero-day exploitation that we attributed to traditional state-sponsored cyber espionage groups was lower than in previous years, these groups remained significant developers and users of zero-day exploits in 2025. Consistent with the trend we have observed for nearly a decade, PRC-nexus cyber espionage groups remained the most prolific users of zero-days across state actors in 2025. We attributed the use of at least 10 zero-days to assessed PRC-nexus cyber espionage groups. This was double what we attributed to these groups in 2024, but below the 12 zero-days we attributed in 2023. PRC-nexus espionage zero-day exploitation continued to focus on edge and networking devices that are difficult to monitor, allowing them to maintain long-term footholds in strategic networks. Examples of this include the exploitation of CVE-2025-21590 by UNC3886 and the exploitation of CVE-2025-0282 by UNC5221 . Observed mass exploitation of vulnerabilities suggests that PRC-nexus espionage operators are increasingly adept at developing, sharing, and distributing exploits among themselves. Historically, zero-day exploits were closely held and leveraged only by the most resourced threat groups. Over time, however, we have observed that an increasing number of activity clusters are exploiting vulnerabilities closer to public disclosure, indicating that PRC-nexus espionage operators have potentially reduced the time to both develop exploits and distribute them among otherwise separate groups. This is reflected not only in the gradual proliferation of exploit code targeting specific vulnerabilities, but also by the shrinking gap between the public disclosure of n-day vulnerabilities and their widespread exploitation by multiple groups. In sharp contrast to 2024, during which we attributed the exploitation of five zero-days to North Korean state-sponsored threat actors, we did not attribute any zero-days to North Korean groups in 2025. Financially Motivated Exploitation Spikes We tracked the exploitation in 2025 of nine zero-days by likely or confirmed financially motivated threat groups, including the reported exploitation of two zero-days in operations that led to ransomware deployment. This almost ties the previous high of 10 zero-days we attributed to financially motivated groups in 2023 and is nearly double the five zero-days we attributed to financially motivated actors in 2024. Although the total volume of zero-day exploitation we have attributed to financially motivated groups has varied year over year, the sustained presence of these threat actors in the zero-day landscape reflects their continued investment in zero-day exploit development and deployment. Financially motivated actors, including ransomware affiliates, were linked to a substantial number of enterprise exploits, reflecting a trend we observed across multiple motivations. We observed zero-day exploitation by FIN11 or associated clusters in four of the last five years–2021, 2023, 2024, and 2025. In late September 2025, GTIG began tracking a new, large-scale extortion campaign by a threat actor claiming affiliation with the CL0P extortion brand, which has predominantly been used by FIN11. The actor sent a high volume of emails to executives at numerous organizations, alleging the theft of sensitive data from the victims’ Oracle E-Business Suite (EBS) environments. Our analysis indicated that the CL0P extortion campaign followed months of intrusion activity targeting EBS customer environments. The threat actor exploited CVE-2025-61882 and/or CVE-2025-61884 as a zero-day against Oracle EBS customers as early as Aug. 9, 2025, weeks before a patch was available, with additional suspicious activity dating back to July 10, 2025. GTIG identified UNC2165, a financially motivated group that overlaps with public reporting on Evil Corp and has prominent members in Russia, leveraging CVE-2025-8088 to distribute malware in mid-July 2025. This activity marked the first instance where we observed UNC2165 use a zero-day for initial access. Additional evidence from underground activity and VirusTotal RAR archive submissions indicate that CVE-2025-8088 was also exploited during this same period by other actors, including a threat cluster with suspected overlaps with CIGAR/UNC4895 (publicly reported as RomCom). UNC4895 is another Russian threat group that has conducted both financially motivated and espionage operations, including the exploitation of two other zero-days in 2024. Spotlights: Notable Threat Actor Activity and Techniques Browser Sandbox Escapes The discovery of various browser sandbox escapes in 2025 provided an opportunity to evaluate current trends and developments in this area. Analysis of those identified this year revealed a significant trend: none were generic to the browser sandbox itself (e.g., CVE-2021-37973, CVE-2023-6345 , CVE-2023-2136); instead, these sandbox escapes were specifically designed to exploit components of either the underlying operating system or hardware used. This section gives a brief technical overview of these vulnerabilities. Operating System-Based Sandbox Escapes CVE-2025-2783 targeted the Chrome sandbox on Windows. The vulnerability was caused by the improper handling of sentinel OS handles (-2) that weren’t properly validated. By manipulating inter-process communication (IPC) messages via the ipcz framework, an attacker could relay these special handles back to a renderer process. The exploit allowed a compromised renderer to gain access to handles, leading to code injection within more privileged processes and ultimately to a sandbox escape. CVE-2025-48543 affected the Android Runtime (ART), the system that translates application bytecode into native machine instructions to improve execution speed and power efficiency. A UAF vulnerability occurred during the deserialization of Java objects, such as abstract classes, that should not be instantiable in the first place. The most notable aspect of the exploit is how the bug can be reached from a compromised Chrome renderer. On recent Android versions, the exploit sent a Binder transaction to deliver a serialized payload embedded into a Notification Parcel object. The subsequent unparceling of the malicious object caused a UAF in ART, leading to arbitrary code execution within system_server, a service that operates with system-level privileges. While this specific vulnerability class and attack vector may be new publicly, we have observed Parcel mismatch n-day vulnerabilities being exploited to achieve Chrome sandbox escapes using the same attack vector in the past. Device-Specific Sandbox Escapes CVE-2025-27038 is a UAF vulnerability in the Qualcomm Adreno GPU user-land library that can be triggered through a sequence of WebGL commands followed by a specifically crafted glFenceSync call. The vulnerability allows attackers to achieve code execution within the Chrome GPU process on Android devices. We observed in-the-wild exploitation of this vulnerability in a chain with vulnerabilities in the Chrome renderer (CVE-2024-0519) and the KGSL driver (CVE-2023-33106). In a similar instance, CVE-2025-6558 targeted the Mali GPU user-land library. This vulnerability was triggered by a sequence of OpenGLES calls that were not properly validated by the browser. Specifically, an out-of-bounds write was caused within the user-land driver due to the issuance of glBufferData() with the GL_TRANSFORM_FEEDBACK_BUFFER parameter while a previous glBeginTransformFeedback() operation remained active. Google addressed this issue in ANGLE by implementing validation to invalidate this specific call sequence. We observed in-the-wild exploitation of this vulnerability in a chain with vulnerabilities in the Chrome renderer (CVE-2025-5419) and in the Linux kernel’s posix CPU timers implementation (CVE-2025-38352). Additionally, CVE-2025-14174 is a vulnerability that affected the Metal backend on Apple devices. In that case, ANGLE incorrectly communicated a buffer size during the implementation of texImage2D operation, resulting in an out-of-bounds memory access within the Metal GPU user-mode driver. SonicWall Full-Chain Exploit In late 2025, GTIG collected a multi-stage exploit for SonicWall Secure Mobile Access (SMA) 1000 series appliances. The exploit chain leveraged multiple vulnerabilities to provide either authenticated or unauthenticated remote code execution as root on a targeted appliance, including one that was being leveraged as zero-day. Authentication Bypass (n-day) The exploit can be leveraged with or without an authenticated JSESSIONID session token. When executed without a token, the exploit attempts to get one for the built-in admin user by exploiting a weakness in SSO token generation within the Central Management Server feature in SMA 1000. This vulnerability was patched as a part of CVE-2025-23006. It was reported to SonicWall by Microsoft Threat Intelligence Center (MSTIC), and was reportedly exploited in the wild prior to it being patched in January 2025. GTIG is currently unable to assess if prior exploitation of this vulnerability is linked to use of this new exploit chain. Remote Code Execution (n-day) Once the exploit has a valid session cookie for the target, it attempts to attain remote code execution through a deserialization vulnerability, where an object is serialized and encoded with Base64, and then passed between the web application client and the appliance server without any integrity checks. This allows an attacker to forge a malicious Java object and send it to the server, which parses the object and causes arbitrary Java bytecode to be executed. The exploit leverages this primitive to run arbitrary shell commands using a payload generated by ysoserial , a common tool used to assist with exploiting Java serialization-related vulnerabilities. This vulnerability was patched by encrypting objects with AES-256-ECB prior to sending them to the client, using an ephemeral key generated randomly at server startup and stored in-memory. Payloads mutated without knowledge of the key won’t be successfully parsed, which mitigates the risk of deserializing untrusted objects without another vulnerability leaking the encryption key. The patch was silently released in March 2024 without a CVE. Local Privilege Escalation (0-day) After exploiting the aforementioned deserialization vulnerability, the exploit is able to execute arbitrary shell commands as the mgmt-server user, which runs the Java process hosting the management web application. To escalate to root privileges, the exploit used a zero-day in ctrl-service , a custom XML-RPC service written in Python and bound to a loopback address on port 8081. This makes it inaccessible directly to a remote attacker, but accessible after already gaining code execution on the device at a lower privilege level. While this vulnerability could be exploited when combined with a newly discovered RCE vulnerability, or with direct console/SSH access to the appliance, we’ve presently only observed it being chained with the RCE exploit previously discussed. GTIG reported this vulnerability to SonicWall, who published a patch for it in December 2025 as CVE-2025-40602. To fix this vulnerability, SonicWall added signature verification to the service to prevent it from executing unsigned files. DNG Vulnerabilities This section specifically examines samples exploiting CVE-2025-21042, a vulnerability for which GTIG has not confirmed zero-day exploitation; however, we include this discussion of the underlying exploitation techniques because zero-days CVE-2025-21043 and CVE-2025-43300 share identical exploitation conditions. Between July 2024 and February 2025, several suspicious image files were uploaded to VirusTotal. Thanks to a lead from Meta, these samples came to the attention of Google Threat Intelligence Group. Upon investigation of these images, we discovered that they were digital negative (DNG) images targeting the Quram library, an image parsing library specific to Samsung devices. The VirusTotal submission filenames of several of these exploits indicated that these images were received over WhatsApp. The final payload, however, indicated that the exploit expects to run within the com.samsung.ipservice process. This is a Samsung-specific system service responsible for providing “intelligent” or AI-powered features to other Samsung applications, and will periodically scan and parse images and videos in Android’s MediaStore. When WhatsApp receives and downloads an image, it will insert the image in MediaStore. This permits downloaded WhatsApp images (and videos) to hit the image parsing attack surface within the com.samsung.ipservice application. However, WhatsApp does not intend to automatically download images from untrusted contacts. Without additional bypasses, and assuming the image is sent by an untrusted contact, a target would have to click the image to trigger the download and have it added to the MediaStore. This classifies as a “1-click” exploit. GTIG does not have any knowledge or evidence of the attacker using such a bypass to achieve 0-click exploitation. com.samsung.ipservice comes with a proprietary image parsing library named “Quram,” which is written in C++. The image parsing is done in-process, unsandboxed with respect to the service’s privilege. This breaks the Rule Of 2 and means a single memory corruption vulnerability can grant attackers access to everything to which com.samsung.ipservice has access, i.e. a phone’s entire MediaStore. This is exactly what the attackers did when they discovered a powerful memory corruption vulnerability (CVE-2025-21042), which allows controlled out-of-bounds write at controlled offsets from a heap buffer. With this single vulnerability, they were able to obtain code execution within the com.samsung.ipservice process and execute a payload with that process’ privileges. There were no significant hurdles for the attackers aside from some ASLR bypassing tricks. No control flow integrity mitigations, like pointer authentication code (PAC) or branch target identification (BTI), are compiled into the Quram library. This allowed the attackers to use arbitrary addresses as jump-oriented programming (JOP) gadgets and construct a bogus vtable. The scudo allocator also failed to engage proper hardening techniques. The heap spraying primitives – more or less inherent to the DNG format – are powerful and allow for a predictable heap layout, even with scudo’s randomization strategy. The absence of scudo’s “quarantine” feature on Android is also convenient for deterministically reclaiming a free’d allocation. This case illustrates how certain image formats can provide strong primitives out of the box for turning a single memory corruption bug into 0-click ASLR bypasses and resulting remote code execution. By corrupting the bounds of the pixel buffer using CVE-2025-21042, subsequent exploitation can occur by taking advantage of the DNG specification and its implementation. The bug exploited in this case is both powerful and quite shallow. As Project Zero’s Reporting Transparency illustrates, several other vulnerabilities in the same component have been discovered over the recent months. These types of exploits do not need to be part of long and complex exploit chains to achieve something useful for attackers. By finding ways to reach the right attack surface with a single relevant vulnerability, attackers are able to access all the images and videos of an Android’s MediaStore, posing a powerful capability for surveillance vendors. A more detailed technical analysis of the exploit can be found on Project Zero’s blog . Prioritizing Defenses and Mitigating Zero-Day Threats Defenders should prepare for when, not if, a compromise happens. GTIG continues to observe vulnerability exploitation as the number one initial access vector in Mandiant incident response investigations , outnumbering other vectors like stolen credentials and phishing. System architectures should be designed and built with ingrained security awareness, enabling inherent segmentation and least privilege access. Comprehensive defensive measures as well as response efforts require a real-time inventory of all assets to be audited and maintained. While not preventative, continuous monitoring and anomaly detection, within both systems and networks, paired with refined and actionable alerting capabilities is a real-time way to detect and act against threats as they occur. The following is a non-comprehensive set of approaches and guidelines for defending against zero-day exploitation on both personal devices and within organizational infrastructure: 1. Architectural Hardening & Surface Reduction Infrastructure: Ensure your DMZ, firewalls, and VPNs are properly segmented from critical assets, including the core network and domain controllers, in order to prevent lateral movement from compromised external components. Monitor execution flow within applications in order to block unauthorized database queries and shell commands Do not expose network ports of devices to the internet when not strictly required Personal devices: Turn off the device and/or leave the device at home when under increased risk of exploitation. Put the device in before first unlock (BFU) mode and USB restricted mode when under increased risk of physical attacks. Turn off cellular, WiFi and bluetooth when under increased risk of close proximity attacks. Apply patches as soon as they become available. Use ad blockers, configure Apple ad privacy settings, and enable the Android privacy sandbox options when possible. Enable Android Advanced Protection Mode and iOS Lockdown Mode. Remove applications, and disable services and features- including ones enabled by default- when not used. 2. Advanced Detection & Behavioral Monitoring Infrastructure: Enforce strict driver blocklists and flag anomalous kernel-level behavior that traditional EDR might overlook. Establish a baseline for system processes in order to be able to flag “Living off the Land” (LotL) activity and other persistence mechanisms. Deploy canary tokens and files to collect high-fidelity alerts of lateral movement. Personal devices: Seek expert advice (e.g., Amnesty, CitizenLab, and Access Now) when receiving suspicious links or attachments, as well as when observing suspicious application and or operating system crashes. Enroll in Google’s Advanced Protection Program . Enable Android Advanced Protection Mode . Enable Enhanced Safe Browsing in Chrome . Enable Safari fraudulent website warning . Enable Edge enhanced security protections . 3. Operational Response Infrastructure: Maintain a Software Bill of Materials (SBoM) to reference and locate affected libraries of disclosed zero-days (e.g., Log4j) across the environment. Establish a process for bypassing standard change management when vulnerabilities require immediate attention. If a patch is unavailable, isolate systems and components with stop-gap measures such as disabling specific services or blocking specific ports at the perimeter. Personal devices: Reboot phone regularly. Do not click on links or download attachments from unknown contacts. Prioritization is a consistent struggle for most organizations due to limited resources requiring deciding what solutions are implemented–and for every choice of where to put resources, a different security need is neglected. Know your threats and your attack surface in order to prioritize decisions for best defending your systems and infrastructure.

Original: https://cloud.google.com/blog/topics/threat-intelligence/2025-zero-day-review/
UNC4899 Breached Crypto Firm After Developer AirDropped Trojanized File to Work Device

Source: The Hacker News | Published: 2026-03-09T14:50:00+00:00 | Score: 15.613

The North Korean threat actor known as UNC4899 is suspected to be behind a sophisticated cloud compromise campaign targeting a cryptocurrency organization in 2025 to steal millions of dollars in cryptocurrency.
The activity has been attributed with moderate confidence to the state-sponsored adversary, which is also tracked under the cryptonyms Jade Sleet, PUKCHONG, Slow Pisces, and

Original: https://thehackernews.com/2026/03/unc4899-used-airdrop-file-transfer-and.html
Ransomware Under Pressure: Tactics, Techniques, and Procedures in a Shifting Threat Landscape

Source: Threat Intelligence | Published: 2026-03-16T14:00:00+00:00 | Score: 14.468

Written by: Bavi Sadayappan, Zach Riddle, Ioana Teaca, Kimberly Goody, Genevieve Stark Introduction Since 2018, when many financially motivated threat actors began shifting their monetization strategy to post-compromise ransomware deployments, ransomware has become one of the most pervasive threats to organizations across almost every industry vertical and region. In recent years ransomware operations have evolved, creating a robust ecosystem that has lowered the barrier to entry via the commoditization and specialization of the supporting underground communities, which is exemplified by the proliferation of the ransomware-as-a-service (RaaS) business model. While ransomware remains a dominant threat due to the volume of activity and the potential for serious operational disruptions, we have observed multiple indicators that suggest the overall profitability of ransomware operations is in decline. This trend is likely the result of multiple factors, including improved cybersecurity practices, increased ability of organizations to recover, and declining ransom payment amounts and rates. Further, numerous disruptions have impacted the ransomware ecosystem in recent years, from external forces like law enforcement operations to internal conflict between actors; both have led to the disappearance or significant debilitation of previously prolific RaaS groups like LockBit, ALPHV, Basta, and RansomHub. However, despite these shakeups, the well-established Qilin and Akira RaaS brands rose up to fill the vacuum, leading to a record high number of victims posted to data leak sites (DLS) in 2025 (Figure 1). This report provides an overview of the ransomware landscape and common tactics, techniques, and procedures (TTPs) directly observed in the 2025 ransomware incidents that Mandiant Consulting responded to. In this analysis, we excluded activity focused only on data theft extortion. Key insights include: In a third of incidents, the initial access vector was confirmed or suspected exploitation of vulnerabilities, most often in common VPNs and firewalls. 77 percent of analyzed ransomware intrusions included suspected data theft, a notable uptick from 57 percent of incidents in 2024. In approximately 43% of ransomware intrusions we responded to in 2025, the threat actors were observed targeting virtualization infrastructure, an increase from 29% in 2024. REDBIKE was the most frequently deployed ransomware family, accounting for 30 percent of analyzed ransomware incidents. Several trends from prior years remained consistent, including a decreased use of certain intrusion tools like BEACON and MIMIKATZ and a plateau in the reliance of remote management tools. Google Threat Intelligence Group (GTIG) analysis of TTPs relies primarily on data from Mandiant engagements and therefore represents only a sample of global ransomware intrusion activity. These incidents involved the post-compromise deployment of ransomware following network intrusion activity, with the majority of incidents also involving data theft extortion. The impacted organizations were based across the Asia Pacific region, Europe, North America, and South America and within nearly every industry sector. While we anticipate ransomware will remain one of the most impactful cyber threats in 2026, the reduction in profits may cause some threat actors to leverage other monetization methods and tactics, such as continuing targeting shifts, further increasing data theft extortion operations, the use of more aggressive extortion tactics, or opportunistically using access to victim environments for secondary monetization mechanisms. Recommendations to assist in addressing the threat posed by ransomware are captured in our white paper, Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment . Figure 1: Top 10 DLS in 2025 and associated ransomware families 2025 Ransomware Landscape In 2025, the ransomware landscape became increasingly crowded, with a record high number of unique DLS with at least one post. The growing pool of ransomware actors engaging in extortion operations combined with persistent targeted efforts by law enforcement and enhanced organizational security has likely shrunk profit margins for ransomware operators in recent years. In response, threat actors appear to be adopting new strategies from who they target to the technologies they use. This evolution has included an apparent increase in targeting smaller organizations, and a possible focus on data theft extortion without ransomware deployment. Furthermore, threat actors are incorporating artificial intelligence (AI) into aspects of their operations (e.g., negotiations) and leveraging Web3 technologies to bolster the resilience of their infrastructure. While we see expansions in these aspects, internal and external disruptions seen in recent years have prompted some threat actors to become more cautious resulting in more rigorous vetting of potential partners. We expect ransomware actors to continue to adjust and evolve their tactics in an attempt to maintain some level of success or regain the levels of profitability they reached historically. 2025 marked a record year for the number of posts on DLS, with the total number of posts surpassing that of 2024 by almost 50%. Despite these record setting numbers, we caution against relying solely on DLS data to ascertain the overall volume of ransomware activity. Threat actors typically only create DLS posts for victims that have refused to initiate or complete extortion negotiations. Public reporting indicates that ransom payment rates have been declining, which could, at least partially, fuel the steady increase of posts on shaming sites. It can also be difficult to differentiate between DLS posts associated with data theft-only operations and those that also include ransomware deployment. For example, threat actors associated with the CL0P DLS continue to occasionally deploy ransomware but have shifted primarily to data-theft-extortion-only operations. So while CL0P was the third most prolific DLS in 2025, the vast majority of incidents associated with these posts did not involve ransomware. We have also observed numerous instances of threat actors, such as those associated with BABUK 2.0, fabricating and exaggerating claims as well as reposting claims that would at least slightly inflate victim counts. Finally, not all claims are of equal significance. For example, between December 2024 and January 2025, FUNKSEC was the highest volume DLS; however, many of the associated incidents appeared to be lower impact events involving compromising websites for data theft extortion. Figure 2: Volume of posts and unique data leak sites from 2020 through 2025 Although ransomware has historically been highly lucrative, recent disruptions and enhanced organizational security may be impacting these profits. Public reporting indicates that both ransom payment rates and average ransom demands are decreasing. In February 2026, Coveware reported that ransom payment rates have generally decreased over the past few years, reaching a historic low in Q4 2025. Similarly, in June 2025, Sophos reported that the average ransom demand has dropped by one-third during the last year, to $1.34 million in 2025 from $2 million in 2024. Public reporting further suggests that organizations that have been impacted by ransomware are able to recover more easily, which also likely contributes to reduced ransom payments. For example, in February 2025, Unit 42 reported that companies have improved their ability to recover from ransomware incidents; nearly half of ransomware victims were able to restore from backup in 2024 compared to around 28% in 2023 and only 11% in 2022. Improvements in organizational security and the growing ability of victims to recover from ransomware attacks may be leading some adversaries to view data theft as a more reliable method for securing payments. In intrusions investigated by Mandiant, we observed a decline in traditional ransomware deployment coinciding with a rise in data theft extortion. Further, some RaaS programs are providing data-theft-extortion-only options in addition to ransomware, which may reflect demand from their customer base. It is also plausible that more robust security posture, particularly at larger organizations, is forcing threat actors to adjust their targeting to focus on a higher volume of attacks targeting smaller organizations with less mature security programs. Analysis of organization size (based on estimated number of employees, when available) of victims posted on DLS indicates threat actors have shifted away from larger organizations and toward smaller organizations (Figure 3). Threat actors have directly commented on this trend. For example, in leaked April and May 2024 chats, a Basta actor theorized that targeting smaller company networks would be more effective compared to “normal networks.” Figure 3: Percentage of DLS posts for victims with an estimated company size of less than 200 employees During 2025, numerous disruptive events impacted the ransomware ecosystem, including both a range of law enforcement and government actions as well as threat actor-related data leaks and disputes, at least some of which appear to be the result of turmoil amongst threat actors (Figure 4). Not only did many of these events result in direct disruption such as arrests, seizures, and sanctions, but some also forced threat actors to shift TTPs and provided valuable insights to security researchers on the inner workings and individuals behind some ransomware operations. Yet the dominance of long-standing Qilin and Akira brands in 2025 demonstrate the resilience of ransomware actors and their ability to fill voids following takedowns and exit scams of competing RaaS operators. There are some indications that the overall instability in the ransomware threat landscape, coupled with pressure from law enforcement, have caused ransomware teams to increase their operational security, which has translated into more rigorous vetting of potential affiliates. We’ve also seen some private or semi-private offerings gain prominence. For example, 2025 marked the first time in four years that one of the top two most prolific RaaS operations was not public; while Akira appears to have affiliates, they do not have a public advertisement for their operations. Figure 4: Key disruptive events impacting the ransomware landscape In 2025, ransomware actors continued to evolve their operations by adopting emerging or established technologies to increase the efficiency and efficacy of their operations. Some threat actors are integrating Web3 technologies into their operations, likely as a way to make their infrastructure more resilient to takedown and detection efforts. The Cry0 RaaS claims to leverage Internet Computer Protocol (ICP) blockchain to host negotiation sites via decentralized canister smart contracts, enabling clearnet access without requiring TOR while DEADLOCK ransomware has leveraged Polygon smart contracts in order to store and rotate C2 infrastructure. We have also seen threat actors incorporating AI-features into their RaaS offerings: the GLOBAL RaaS reportedly has an AI-assisted chat that provides victim analysis and assists with communications, CHAOS purportedly includes a “built-in AI chatbot,” although its specific use is unclear, while BERT allegedly uses AI-based data analysis to identify victim pressure points. Finally, we have observed twice the number of ransomware families that were capable of running on both Windows and Linux systems compared to 2024. This could suggest that threat actors are shifting toward cross-platform ransomware rather than creating multiple, separate variants to support their operations. Commonly Observed Tactics, Techniques, and Procedures The following sections discuss trends in the TTPs observed in post-compromise ransomware deployment incidents, organized into the corresponding stages of GTIG’s attack lifecycle model (Figure 5). The TTPs outlined in this section were observed at Mandiant-led ransomware investigations during 2025. Figure 5: Attack lifecycle associated with 2025 ransomware incidents Initial Access During 2025, the most commonly identified initial access vector in ransomware incidents was the exploitation or suspected exploitation of vulnerabilities, accounting for a third of incidents, followed by web compromise, stolen credentials, and bruteforce attacks (Figure 6). Notably, while voice phishing was a commonly leveraged tactic in several high profile data theft extortion campaigns, it was not observed in ransomware incidents. This year we included suspected initial access vectors in our analysis to provide a more holistic view, given that some vectors can be more difficult to verify. For example, it can be difficult to confirm the use of stolen credentials, given that the credentials may have been harvested in a separate incident that occurred weeks prior or even on a personal device. Conversely, bruteforce attacks tend to generate many log entries that can be used to confirm the vector. Throughout 2025 we observed ransomware operators leveraging a wide range of exploits for initial access (Table 1). While the majority of observed or suspected exploitation activity involved vulnerabilities disclosed prior to 2025, we observed multiple indicators that at least some ransomware actors were leveraging zero-day exploits in their operations. In the majority of instances where exploits were used or suspected, the threat actors targeted vulnerabilities in common VPNs and firewalls such as Fortinet (CVE-2024-55591, CVE-2024-21762, and CVE-2019-6693), SonicWall (CVE-2024-40766), Palo Alto (CVE-2024-3400), and Citrix (CVE-2023-4966). We also observed malicious actors successfully exploit a variety of other exposed services, including Veritas Backup Exec, Zoho ManageEngine, Microsoft Sharepoint, and SAP Netweaver. We observed evidence that multiple ransomware and/or data theft extortion operations leveraged zero-day vulnerabilities for initial access throughout the year. During mid-July 2025, an UNC6357 actor attempted to exploit Microsoft Sharepoint vulnerabilities CVE-2025-53770 and CVE-2025-53771 to gain access to the victim’s environment and ultimately deploy LOCKBIT.WARLOCK. While this was observed after disclosure of the vulnerability, we observed evidence—including log data and public reporting —suggesting the same actor attempted to exploit the same vulnerability as a zero-day. In August 2025, GTIG assessed with high confidence that UNC2165 leveraged a zero-day exploit for CVE-2025-8088 to deploy MYTHICAGENT. While the observed incidents did not involve ransomware deployment, threat actors associated with the CL0P DLS may have exploited CVE-2025-61882 as a zero-day against Oracle EBS environments. The CL0P DLS has been associated with multifaceted extortion operations involving CLOP ransomware; however, it is primarily associated with data theft extortion operations rather than ransomware deployment. We observed multiple threat clusters leverage malvertising and/or search engine optimization (SEO) tactics to distribute malware payloads for initial access, including both ransomware operators themselves and initial access partners that ultimately led to follow-on ransomware intrusions. We observed multiple UNC6016 malware distribution operations leverage malvertising to distribute malware payloads masquerading as legitimate software tools such as PuTTY to gain initial access. At least a portion of observed UNC6016 access operations ultimately lead to NITROGEN or RHYSIDA ransomware deployments. UNC2465 routinely leveraged malvertising and/or SEO techniques to distribute SMOKEDHAM payloads masquerading as RVTOOLs installers. While less frequent this year, many threat actors continued to rely on stolen credentials for initial access. In 21% of intrusions where the initial access vector was identified, the threat actor leveraged compromised legitimate credentials to access the victim environment, typically involving authentication to a victim’s VPN or a Remote Desktop Protocol (RDP) login. While the source of stolen credentials cannot always be determined, actors can obtain them via numerous techniques including purchasing credentials from underground forums or using credentials exposed in infostealer logs. We continued to see a subset of actors leveraging bruteforce attacks against victims’ VPNs. In one incident involving ransomware that identified itself as Daixin, the threat actor conducted periodic bruteforce attacks against various VPN user accounts over the course of nearly a year before successfully gaining initial access. We observed multiple intrusions where the ransomware operator gained access to the victim through an intermediary network. We observed multiple disparate ransomware operations that leveraged network access to subsidiaries of victims to subsequently access the victim’s network. In one instance the threat actor leveraged access to the subsidiary to bruteforce access to the victim’s VPN. In a separate incident, the threat actor leveraged a VPN connection owned by a third-party vendor to access an operational technology (OT) system within the victim’s environment. During one intrusion leading to CLOP ransomware deployment, UNC5833 gained access from an initial access partner who impersonated a helpdesk user to social engineer an employee via a Microsoft Teams chat session to install Quick Assist. While we observed limited use of social engineering by ransomware operators during 2025 in incidents we observed, it remained a popular technique among financially motivated intrusion actors more broadly. Figure 6: Initial intrusion vectors Vendor Product CVE Fortinet FortiOS / FortiProxy CVE-2024-21762 Veritas Backup Exec CVE-2021-27877 Veritas Backup Exec CVE-2021-27878 Zoho ManageEngine ADSelfService Plus CVE-2021-40539 Fortinet FortiOS / FortiProxy CVE-2024-55591 Fortinet FortiOS CVE-2019-6693 SonicWall SonicOS CVE-2024-40766 Citrix NetScaler CVE-2023-4966 Microsoft SharePoint CVE-2025-53771 Microsoft SharePoint CVE-2025-53770 SAP Netweaver CVE-2025-31324 Palo Alto PAN-OS GlobalProtect CVE-2024-3400 CrushFTP CrushFTP CVE-2025-31161 Table 1: Vulnerabilities likely leveraged for initial access in 2025 ransomware incidents Establish Foothold and Maintain Presence Once inside victim environments, threat actors engaged in many different techniques to establish a foothold and maintain presence, including leveraging valid credentials, tunnelers, backdoors, or legitimate remote access tools. Threat actors continued to use remote management tools to support both these phases of the attack lifecycle, albeit at slightly lower rates than 2024. Ransomware actors consistently relied on compromised credentials to establish a foothold in victim environments. Once authenticated to network services, they also often used these credentials to provision or modify highly privileged accounts to maintain access. For example, in a RIFTTEAR incident, the threat actor authenticated via Kerberos to a privileged system, provisioned an AD domain user, and added the account to a high-privileged group. We also saw multiple threat actors change passwords to root accounts on ESXi hosts. In 2025, an increased number of threat actors adopted tunnelers to support these phases compared to 2024 observations. Observed tunnelers included publicly available offerings such as PYSOXY, CHISEL, CLOUDFLARED, RPIVOT, and REVSOCKS.CLIENT alongside seemingly private tunnelers like LIONSHARE, VIPERTUNNEL, and BLUNDERBLIGHT. In a LOCKBIT.WARLOCK incident, the exploitation of a Microsoft SharePoint vulnerability enabled remote code execution, granting the access required to install CLOUDFLARED from Github via the Windows msiexec command-line utility, establishing an outbound-only C2 channel. A subset of threat actors deployed backdoors—including CORNFLAKE.V3.JAVASCRIPT, SQUIDGATE, FIREHAWK, HAVOCDEMON, and SMOKEDHAM—to establish a foothold. UNC6021, a suspected FIN6 threat cluster, used SQUIDGATE’s built-in functionality to deploy FIREHAWK, a toehold backdoor written in C. Consistent with FIN6 infections, a social engineering engagement on LinkedIn prompted a user to access a malicious website hosting a ZIP archive containing the BULLZLINK downloader. Once executed, it retrieved a dropper variant of SQUIDSLEEP with an embedded SQUIDGATE payload. In 2025, multiple ransomware actors relied on remote monitoring and management tools (RMMs) for multiple phases of the attack lifecycle. We observed a variety of these legitimate tools abused in incidents, including ANYDESK, SCREENCONNECT, and SPLASHTOP (Table 2). In an UNC2465 incident, several weeks after the initial intrusion, the threat actors installed the TERAMIND RMM alongside Time Doctor. Time Doctor is an employee monitoring tool, which is capable of taking screenshots and screen recordings of the system as well as track website and application usage. Threat actors continued to reduce their reliance on BEACON in ransomware operations; we observed BEACON in around 2% of intrusions, a decrease from an already diminished 11% in 2024. However, multiple threat clusters used other post-exploitation frameworks like AdaptixC2 (ADAPTAGENT), Exploration C2 (EXPLORATIONC2), or MYTHIC. In an UNC2165 RANSOMHUB incident, the threat actors used COM hijacking as a persistence mechanism for MYTHIC. UNC2165 created MYTHIC in the “Temp” folder, renamed it to “msedge.dll,” and modified the registry key for InprocServer32 to point to the MYTHIC payload. Threat actors often used native Windows features to create services and register scheduled tasks to programmatically and recurrently execute malware, such as backdoors or tunnelers. For example, in a RHYSIDA incident, threat actors registered a scheduled task to run the LIONSHARE tunneler every 12 hours (Figure 7). In a TridentLocker-branded incident, the threat actors uploaded WAVECALL, a downloader implemented as a .NET assembly, to a victim server running CrushFTP. They modified the command-line instruction used for processing file previews, replacing the configured executable paths for ImageMagick and ExifTool utilities with the WAVECALL assembly, thereby executing it whenever a file preview operation was initiated. The actors later reverted this configuration and updated the command-line instruction to execute a Base64-encoded PowerShell script to deploy a follow-on payload. /Create /SC MINUTE /MO 720 /TN Reg /TR “C:\Windows\System32\rundll32.exe C:\windows\system32\config\red.dll Test” /ru system Figure 7: Scheduled task for LIONSHARE ANYDESK ATERA CHROMEREMOTEDESKTOP DAMEWARE DWAGENT MESHAGENT RUSTDESK SCREENCONNECT SPLASHTOP TERAMIND Table 2: Legitimate remote access tools used to establish a foothold and maintain a presence Escalate Privileges Gaining access to highly privileged accounts is a critical step for ransomware actors as it enables further stages of the attack, such as disabling AV software, deleting backups, and deploying ransomware across the network. Threat actors continue to rely on a variety of privilege escalation tools and techniques, including leveraging MIMIKATZ, dumping credentials stored by the Windows operating system, and abusing Active Directory (AD). We observed threat actors leverage MIMIKATZ in approximately 18% of ransomware intrusions in 2025, demonstrating a slight, but continued decline in its overall use in recent years dropping from use in 20% of all ransomware intrusions in 2024. Notably, we observed a decline in other publicly available privilege escalation and credential stealing tools as well; for example, we did not observe LAZAGNE in any ransomware intrusions in 2025, a reduction from 2% of intrusions in 2024, 4% in 2023, and 6% in 2022. Consistent with recent years, throughout 2025 threat actors used a myriad of techniques to target Windows authentication systems to gain access to privileged accounts. We observed threat actors frequently attempting to obtain credentials stored by Windows systems by dumping the Local Security Authority Subsystem Service (LSASS) process memory, copying the Active Directory domain database (NTDS.dit) file, and exporting the Security Account Manager (SAM), SYSTEM, and SECURITY registry hives. Other observed methods include Kerberoasting, modifying the registry to enable WDigest credentials caching, and the recovery of credentials via the Windows Data Protection API (DPAPI). Threat actors routinely elevated privileges of compromised and actor-provisioned accounts by adding them to local and domain administrator groups and/or granting the accounts additional privileges such as SeRemoteInteractiveLogonRight, SeDebugPrivilege, SeLoadDriverPrivilege, and SeBackupPrivilege. In some intrusions, threat actors abused AD roles to obtain elevated privileges through a variety of means, including DCSync replication and the misuse of AD Certificate Services (AD CS). In a MEDUSALOCKER.V2 incident, the threat actors executed the “Move-ADDirectoryServerOperationMasterRole” cmdlet to transfer Flexible Single Master Operation (FSMO) roles from the victim’s AD domain controller to a suspected rogue domain controller. We observed multiple threat actors attempt to harvest credentials from various internal sources, including backup tools, browsers, password managers, and credentials stored in cleartext. In approximately 10% of intrusions we observed threat actors targeting Veeam Backup & Replication for credential harvesting, which is consistent with activity observed in 2024. Multiple threat actors used the publicly available Veeam-Get-Creds.ps1 script or custom PowerShell scripts to obtain credentials stored in the Veeam configuration database. In a handful of incidents, threat actors targeted Chromium-based browsers to obtain stored credentials. For example, in an UNC2165 RANSOMHUB incident, the threat actors executed inline PowerShell to retrieve and decrypt DPAPI-protected master encryption key from the Local State files of Google Chrome and Microsoft Edge allowing access to stored credentials within the browsers. Threat actors accessed or attempted to access common password management tools, including KeePass, Bitwarden, and the Windows Credential Manager. During one UNC2465 intrusion involving AGENDA ransomware, the threat actor accessed a self-hosted Bitwarden server and exported and exfiltrated the contents of the vault database. During a REDBIKE ransomware incident, the threat actor likely harvested a cleartext password from a SonicWall appliance, which was also shared with an admin account, granting the actor domain administrator privileges. During one ransomware incident targeting a victim’s virtualized environment, the threat actor exploited CVE-2024-37085 to gain administrator access to an ESXi hypervisor. Internal Reconnaissance In 2025, the tactics leveraged for internal reconnaissance remained fairly consistent with recent years; threat actors continued to rely on native system utilities, PowerShell commands, and publicly available software. Threat actors consistently used PowerShell to query Active Directory (AD) objects for running processes, network shares, and user group memberships. This activity ranged from using native cmdlets like Get-ADComputer and Get-ADUser to using script blocks to query other system data. In several cases, threat actors used Get-ADComputer and Get-ADUser to export lists of AD objects to a separate file. For example, in an incident involving MEDUSALOCKER.V2, the threat actors queried specific user object properties, exported account identity, contact information, and organizational metadata (Figure 8). At the same incident, the threat actors executed a different command to query domain-joined computers, capturing properties such as the operating system (OS), IPv4 address, and last logon date (Figure 9). In some instances, threat actors executed PowerShell script blocks that ran a multitude of commands at once. For example, in an INTERLOCK incident, the threat actors ran a condensed one-line script that performed user profiling—including identifying the current user’s username, Security Identifier (SID), and group memberships—checked for a domain connection, and enumerated the Domain Admins group. Notably, the script included a jitter, or time delay, to create random pauses between command execution, likely in an attempt to evade detection against rapid-fire command execution. Threat actors continued to rely heavily on internal Windows utilities in this phase of the attack lifecycle, including ipconfig, netstat, ping, and nltest, among others. Publicly available reconnaissance utilities were used in numerous intrusions. These publicly available tools ranged from those specialized in probing networks, such as Advanced IP Scanner, Softperfect Network Scanner (NETSCAN), and Angry IP Scanner, to red-teaming tools like PowerSploit and IMPACKET. Notably, network reconnaissance utilities like Advanced IP Scanner, NETSCAN, and Angry IP Scanner were used in approximately 50% of intrusions, similar to their observed usage in 2023 and 2024. We often saw threat actors accessing files and folders related to potentially sensitive information. In some cases, they appeared to search for backup scripts and password managers, while in other cases they were likely attempting to find sensitive files to exfiltrate in order to increase the pressure applied by data theft extortion. In a REDBIKE intrusion, the threat actors searched for keywords like “passport,” “i9,” and “cyber insurance.” In addition to searching for personally identifiable information (PII) like passports and employment eligibility forms, it is plausible that the threat actors were also seeking to obtain the victim’s cyber insurance policies to help them determine a negotiation strategy or maximum ransom amount to demand. Several threat actors performed targeted internal reconnaissance for information about virtualized infrastructure within the victim environment, likely to facilitate ransomware deployment on these systems. In a REDBIKE incident, threat actors enumerated hypervisors by running the Get-VM cmdlet and accessed the internal VMware vSphere web portal. powershell Import-Module ActiveDirectory; Get-ADUser -filter * -properties Enabled,DisplayName,Mail,SAMAccountName,homephone,ipphone,TelephoneNumber,comment,description,title | select Enabled,DisplayName,Mail,SAMAccountName,homephone,ipphone,TelephoneNumber,comment,description,title | export-csv C:\Users\Public\Music\users.csv Figure 8: Get-ADUser HostCmd powershell Import-Module ActiveDirectory; Get-ADComputer -Filter {enabled -eq $true} -properties *|select comment, description, Name, DNSHostName, OperatingSystem, LastLogonDate, ipv4address | Export-CSV C:\users\public\music\AllWindows.csv -NoTypeInformation -Encoding UTF8 Figure 9: Get-ADComputer HostCmd Lateral Movement Throughout 2025, actors extensively used common built-in protocols, including RDP, Server Message Block (SMB), and Secure Shell (SSH), combined with compromised credentials or attacker-created accounts for lateral movement. We also observed actors leveraging a variety of tools and utilities to tunnel and proxy traffic within victim environments. In approximately 85% of intrusions, threat actors leveraged RDP with either compromised or attacker-created accounts for lateral movement. Across a range of incidents we observed threat actors leveraging SMB for lateral movement to access network shares, stage payloads, and execute remote commands. During one SAFEPAY ransomware incident, the threat actor leveraged SMB to access various network shares and used this access to stage a copy of NETSCAN on multiple hosts. We also observed multiple actors leverage IMPACKET.SMBEXEC to execute remote commands. For example, in one intrusion leading to MEDUSALOCKER.V2 ransomware, the threat actor leveraged IMPACKET.SMBEXEC to run commands to create a new local administrator account on a remote host. Across numerous incidents we observed various threat actors leverage common public utilities like PuTTY and KiTTY to establish SSH connections to hosts, particularly when moving laterally to ESXi systems. We continued to observe frequent use of common Windows utilities like PsExec, Windows Remote Management (WinRM), and to a lesser extent Windows Management Instrumentation Command-line (WMIC), for remote execution and lateral movement. In a handful of intrusions, threat actors used PowerShell to establish interactive remote sessions via WinRM using the “Enter-PSSession” cmdlet. In an UNC5774 INTERLOCK ransomware incident, the threat actors used WinRM to establish a connection to a domain controller and execute remote commands, including using net.exe to reset the password of a user account. During an UNC2465 incident, the threat actor moved laterally by using WMIC to execute a SMOKEDHAM payload on a remote host. In numerous incidents, threat actors manipulated firewall rules in order to enable different types of traffic, such as RDP or SMB, to be allowed within the victim environment. In one incident, UNC6021, a suspected FIN6 threat cluster, created a scheduled task that ran a netsh command to modify firewall rules to enable remote desktop access (Figure 10). During one UNC6276 intrusion, the threat actor disabled the firewall on an ESXi host before deploying SYSTEMBC.LINUX on the host. In one incident the threat actor installed OpenSSH on a host and ran a PowerShell command to configure a new firewall rule to allow inbound traffic on port 22 (Figure 11). In an intrusion leading to the deployment of INC ransomware, the threat actor leveraged an attacker-created account to create new firewall policies that granted access to multiple additional subnets within the network. Threat actors leveraged a variety of malicious and legitimate utilities to tunnel and proxy traffic within victim networks, including SYSTEMBC, VIPERTUNEL, PYSOXY, CLOUDFLARED, and OpenSSH. During one LOCKBIT.WARLOCK intrusions the threat actor leveraged CLOUDFLARED to tunnel an RDP connection between two hosts. In a minimal number of incidents, threat actors leveraged publicly available post-exploitation tools including METASPLOIT and AMNESIAC. Threat actors often abused access to various management consoles for virtual systems to move laterally to virtual hosts. In multiple instances, the threat actors appeared to leverage this access to enable SSH on ESXi hosts prior to establishing SSH connections for lateral movement. For example, in a FOULFOG.LINUX incident, threat actors leveraged access from the victim’s VMware vSphere centralized management portal to enable SSH on a vm-host, created user root1, SSHed using the newly created user, and disabled firewall. During one incident the threat actor leveraged access to the victim’s Nutanix Prism Central management tool along with a compromised account to move laterally to multiple additional systems. In the same incident, the threat actor also used the VMware web user interface to access numerous ESXi hosts. In a subset of intrusions we observed evidence of threat actors conducting bruteforce attacks to gain access to accounts on additional systems. cmd.exe /C netsh advfirewall firewall set rule group=”remote desktop” new enable=No Figure 10: netsh command to modify firewall rules to enable remote access powershell.exe -Command New-NetFirewallRule -Name sshd -DisplayName ‘OpenSSH Server (sshd)’ -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22 Figure 11: PowerShell command to allow inbound SSH traffic Complete Mission The following sections highlight observations from the complete mission phase of the attack lifecycle, covering ransomware deployment, data exfiltration, and anti-analysis and recovery techniques. Threat actors conducting ransomware attacks routinely conduct multifaceted extortion operations involving data theft as it provides additional leverage during negotiations. Threat actors also consistently engage in a diverse range of tactics to ensure the success of their operations and reduce the ability for victims to recover, including tampering with security software, deleting backups, and clearing logs. Notable trends in 2025 include the prevalence of REDBIKE ransomware, an increase in the percentage of incidents involving data theft extortion, and indications that the techniques used to target virtual systems may be maturing. Ransomware Families REDBIKE was the most prominent ransomware observed in 2025 Mandiant incident response investigations, followed by AGENDA and then INC ransomware (Figure 12). In 2024, REDBIKE was tied for the number one spot with LOCKBIT.BLACK and RANSOMHUB; however, in 2024 LOCKBIT experienced significant disruptive actions stemming from law enforcement actions and in 2025 RansomHub abruptly ceased operations. Throughout 2025 we also observed a handful of incidents involving newly identified ransomware, such as NINTHBEE and SILVERPINE, demonstrating that at least a subset of threat actors are developing and maintaining new ransomware families. REDBIKE was seen in almost 30% of 2025 ransomware incidents, surpassing previous highs for single ransomware families, including LOCKBIT and ALPHV reaching 17% each in 2023. We continue to observe threat actors reusing existing ransomware families in seemingly unrelated operations conducted under different extortion brands. While we have seen a significant decrease in LOCKBIT ransomware incidents since the legal actions taken against the RaaS in 2024, in 2025 we did observe a handful of LOCKBIT.WARLOCK incidents. The WarLock DLS emerged in July 2025 and has listed over 75 victims since. LOCKBIT.WARLOCK largely leverages the original LOCKBIT codebase; however, it uses different encryption algorithms, and refactors previously inlined operations into dedicated functions. In 2025, we observed a handful of intrusions involving CONTI ransomware, though the CONTI RaaS was shut down in May 2022 following the leak of associated chat logs and the CONTI source code. For example, we observed CONTI deployed in a 2025 incident associated with the Gunra ransomware group; analysis of the ransomware payload identified it was heavily based on CONTI’s source code, with slight variations in obfuscation. We observed three different extortion brands leveraging INC ransomware in their operations: INC Ransom, Sinobi, and Lynx. The INC ransomware source code was advertised in an underground forum in May 2024 but the Lynx and INC Ransom DLS domains were acquired by a common threat actor. GTIG observed ODDSIDE ransomware in an incident in 2025; ODDSIDE is PowerShell-based ransomware that refers to itself as DARKMATTER. While not completely unheard of, PowerShell-based ransomware is fairly rare. Notably, in one incident we observed threat actors deploy CLOP ransomware. This is the first time we’ve responded to a CLOP ransomware incident since 2020, though we have occasionally identified CLOP ransomware samples uploaded to malware repositories. In recent years, threat actors associated with the CL0P data leak site have primarily conducted data-theft-extortion-only operations rather than performing encryption. In a subset of incidents, we were unable to obtain the ransomware payloads. For example, we observed a handful of TridentLocker-branded ransomware incidents in which there is evidence to suggest that the ransomware payload was executed in memory. It’s plausible the threat actors used in-memory execution to deploy ransomware to try and bypass security detections and potentially make analysis and recovery efforts more difficult. Threat actors occasionally abuse legitimate encryption tools in their extortion operations. In 2025, we observed an incident in which threat actors used BitLocker to encrypt over 200 remote hosts. Figure 12: Distribution of ransomware families observed in 2025 investigations Ransomware Families Observed in 2025 Mandiant Investigations AGENDA AGENDA.ESXI AGENDA.RUST BABUK BABUK.MARIO CLOP CONTI CRYTOX DOLLARLOCKER FOULFOG.LINUX INC INC.LINUX INTERLOCK LOCKBIT.UNIX LOCKBIT.WARLOCK MEDUSALOCKER.V2 NINTHBEE NITROGEN ODDSIDE PLAYCRYPT RANSOMHUB REDBIKE RHYSIDA RIFTTEAR SAFEPAY SILVERPINE WHITERABBIT Table 3: Ransomware families observed in Mandiant’s 2025 incident response investigations Data Exfiltration In 2025, we observed confirmed or suspected data theft in approximately 77% of ransomware intrusions, a notable increase from approximately 57% in 2024. In these incidents, the most frequently observed strategies for identifying, staging, and exfiltrating data included the use of legitimate data synchronization tools such as Rclone and MEGASync, file compression using built-in tools or portable versions of WinRar or 7Zip, and FTP clients such as Filezilla or Winscp. During intrusions where data was stolen, we routinely observed threat actors targeting a variety of sensitive data types, including legal, human resources, accounting, and business development data. We observed evidence of threat actors conducting manual reconnaissance of systems likely to gather sensitive data for exfiltration such as accessing emails and attempting to access SharePoint and other Microsoft 365 environments via the browser. In 2025, threat actors continued to rely on publicly available tools and utilities—including Rclone, MEGASync, Megatools, restic, and possibly Cyberduck—to exfiltrate data. We observed Rclone in approximately 28% of intrusions where data theft was confirmed or suspected to exfiltrate data to attacker-controlled infrastructure. In one INC ransomware incident, the threat actor used the wget and curl commands to download Rclone and an INC.LINUX ransomware payload respectively to a network-attached storage (NAS) server. The threat actor subsequently ran Rclone to exfiltrate data from the server prior to manually executing the INC.LINUX payload. Threat actors installed and/or leveraged legitimate FTP/SFTP clients in 26% of intrusions where data theft was observed or suspected. Commonly observed software included FileZilla, WinSCP, and PuTTY Secure Copy. While not confirmed to be used for data exfiltration, we observed threat actors installing and/or executing various utilities that could be used to aid in the reconnaissance, staging, and export of stolen data such as Total Commander, Xcopy, and Gpg4win. Threat actors leveraged a myriad of legitimate cloud services and infrastructure to exfiltrate stolen data, including Azure, AWS, Backblaze, Cloudzy, Filemail, Google Drive, and MEGA, and OneDrive. In one UNC5471 intrusion leading to AGENDA ransomware, the threat actor leveraged batch scripts alongside WinRAR to automate the archiving of files in directories. The actor then used Megatools and SLEETSEND to exfiltrate the data to the MEGA and Cloudzy cloud storage services. We observed multiple threat actors transferring stolen data to attacker-controlled OneDrive accounts. During one UNC5496 intrusion, the threat actor ran commands to have Rclone transfer all files that matched a list of common file extension types to a threat actor-controlled OneDrive account. In multiple incidents, we observed threat actors leveraging AzCopy to transfer stolen files to attacker-controlled Azure storage. During one UNC6098 intrusion, the threat actor leveraged the SQL Server Import and Export Wizard to export a SQL database. Ransomware Deployment We observed a diverse set of ransomware deployment techniques leveraged in intrusions throughout 2025. Threat actors employed both manual and automated deployment techniques, including the use of batch scripts, scheduled tasks, Group Policy Objects (GPOs), registry keys, and PowerShell scripts. Notably, in almost 20% of incidents, threat actors targeted virtualization infrastructure, and we observed multiple incidents where operators automated portions of their ransomware deployment against ESXi hosts, suggesting techniques used to target virtual systems may be maturing. Threat actors often relied on automated mechanisms to deploy ransomware. In many cases, they relied on native Windows mechanisms to facilitate ransomware execution. Multiple threat clusters leveraged batch scripts to facilitate ransomware payload execution in victim environments. In one LOCKBIT.WARLOCK intrusion, the threat actor staged NetExec on a domain controller along with files to run the ransomware payload. The threat actor then used NetExec to copy a batch file to numerous hosts via SMB and run it to execute the ransomware payload. In a separate LOCKBIT.WARLOCK intrusion, the threat actor staged ransomware payloads on multiple hosts via SMB before executing them via scheduled tasks. During a NINTHBEE ransomware incident, the threat actor modified a GPO to include a malicious scheduled task that disabled Windows Defender and subsequently executed the ransomware payload. In the same intrusion, the threat actor also attempted to execute the NINTHBEE payload on multiple remote hosts via PsExec. In an incident likely involving DOLLARLOCKER, a threat actor created a Windows service to run a command to execute the ransomware payload. Multiple threat clusters leveraged the Windows Registry to complete their ransomware deployment objectives. During an UNC5471 intrusion, the threat actor created registry Run keys to execute AGENDA ransomware on multiple servers persistently. In one INTERLOCK ransomware intrusion, following encryption, the threat actor modified the LegalNoticeCaption and LegalNoticeText registry values to display a banner indicating the system was ransomed on start up. In addition to using SMB to stage ransomware payloads, we also observed threat actors leverage SMB to facilitate more expansive ransomware deployment across victim networks. In one incident, actors identified network shares via the “Invoke-ShareFinder” PowerShell cmdlet and likely supplied this list to REDBIKE as a list of targets. Ultimately, encryption was attempted on more than 500 endpoints via SMB. In a small subset of observed intrusions, threat actors leverage PowerShell to automate the deployment of BitLocker encryption across victims’ environments. During one intrusion, the threat actor used a PowerShell script to install, configure, and assign passwords for BitLocker on multiple hosts. The threat actor then enabled encryption on multiple drives on these hosts and scheduled a system restart to force the hosts into a locked state. The actor also modified the registry to display a ransom note on the BitLocker preboot recovery screen. In approximately 43% of ransomware intrusions we responded to in 2025, the threat actors were observed targeting virtualization infrastructure, an increase from 29% in 2024. While ransomware deployment to virtual systems is often done manually, in 2025 we observed at least some incidents where threat actors attempted to automate portions of the ransomware deployment stage. During an UNC5495 intrusion, the threat actor automated the deployment of BABUK.MARIO by leveraging a batch script that accepted credentials for ESXi hosts. The batch script used a staged copy of KiTTY to copy the ransomware payload to the host and then connect via SSH and run a command to execute the payload on each host. In a separate intrusion, a threat actor leveraged a PowerShell script to authenticate to the victim’s vCenter server, set new root passwords, and enable SSH on ESXi hosts. The same script was used to subsequently copy a RIFTEAR ransomware payload to the hosts, delete backups, shutdown virtual machines (VMs), and disable security policies prior to executing the ransomware payload. Prior to ransomware deployment on ESXi hosts, threat actors commonly disabled the ExecInstalledOnly setting on hosts to allow for the execution of custom binaries (Figure 13). During one intrusion, the threat actor also accessed a vCenter server and modified the Lockdown Mode Exception Users settings, which controls users that are allowed to maintain privileges when the host is in lockdown mode. Across multiple intrusions, threat actors took steps to stop virtual machines and unlock files prior to decryption, almost certainly to maximize the impact of their ransomware payloads. In multiple instances threat actors used or attempted to use IOBIT, a legitimate uninstaller utility, to unlock files in use by other programs prior to executing ransomware payloads. We also observed multiple actors shutting down virtual machines and deleting backups and snapshots prior to encryption. In at least one intrusion, an actor leveraged a PowerShell script to automate the process of powering off virtual machines. During one intrusion, the threat actor accessed the victim’s Commvault server and deleted vCenter backup volumes prior to encryption to hinder recovery. During a TridentLocker-branded ransomware incident, we assess with moderate confidence that the threat actor leveraged the same CrushFTP preview hijacking technique used for WAVECALL persistence to download and execute a ransomware payload from the WAVECALL C2 server. esxcli system settings advanced set -o /User/execInstalledOnly -i 0 Figure 13: Command to disable ExecInstalledOnly setting on ESXi hosts Anti-Detection, Analysis, and Recovery Tactics Ransomware actors consistently engage in anti-detection, anti-analysis, and anti-recovery tactics in their operations in an effort to not only prevent detection during the intrusion, but increase the difficulty for victims to recover post-encryption. While these tactics are often manually performed by threat actors, numerous ransomware families feature built-in capabilities to hinder analysis and delete backups prior to encryption. Threat actors consistently disabled and tampered with security controls during ransomware intrusions to avoid detection and/or block of execution of malicious payloads. Most commonly, we observed threat actors disabling Windows Defender, often by modifying the Windows registry. In some other cases, the threat actors modified Defender configurations via the Set-MpPreference PowerShell cmdlet to add exclusions for their malware and ransomware payloads. Threat actors also were observed leveraging GPOs, scheduled tasks, and PowerShell scripts in order to tamper with a variety of security controls. In a REDBIKE incident, threat actors used PowerShell to disable a multitude of Windows Defender features by running commands to modify a variety of values associated with Windows Defender registry keys, including DisableRealtimeMonitoring, DisableScanOnRealtimeEnable, and DisableOnAccessProtection (Figure 14). In an intrusion involving WHITERABBIT, threat actors executed a Base64-encoded PowerShell command that used the “Add-MpPreference” cmdlet to modify the Defender Exclusion list to include the ransomware binary; a variety of file extensions, such as “.cmd,” “.bat,” and “.exe”; as well as User Data folders. In an incident involving NINTHBEE, threat actors registered a scheduled task to execute daily a command that disables Microsoft Defender’s real-time scanning for downloaded files and email attachments. Ransomware actors often deleted artifacts and cleared event logs to remove evidence of their activity. These records included information about command execution, firewall traffic, and stolen credentials. The wevtutil utility was used to facilitate log deletion in multiple instances. In a FOULFOG.LINUX incident, the threat actors renamed the ransomware binary to a less suspicious name, “filerw”; deleted the command history for the system; and created an empty file to replace the deleted file. In some cases, threat actors used benign names in their operations in an attempt to masquerade as legitimate software or system resources. For example, in a RIFTTEAR incident, threat actors registered a scheduled task named “\Microsoft\Update” to execute a malicious command likely intended to kill endpoint detection and response (EDR) processes. In a separate case involving CONTI, the ransomware binary had its filename renamed from “enc_lin” to “rsync” in an attempt to appear as the native synchronization command-line utility. Ransomware actors often disabled or deleted backups to inhibit and/or limit recovery options. In some cases, threat actors stopped backup servers and/or deleted Volume Shadow Copies (VSS) via PowerShell scripts. Notably, in a RANSOMHUB incident, the threat actors used the access to Cisco Integrated Management Controller (CIMC) to map a Debian Linux ISO image via Virtual Media across a nine-node Cohesity cluster. By modifying the boot priority and hardware power-cycling, the nodes booted into the external Linux environment, overwriting the Cohesity operating system (OS) and rendering the backup data inaccessible. In a handful of intrusions, the threat actors used tooling to terminate processes and services associated with security software solutions, specifically those abusing signed kernel mode drivers. Examples include the open-source TERMINATOR and WATCHDOGKILLER, as well as non-publicly available tools such as WARCLAW, a utility that decodes and installs a vulnerable kernel mode driver. cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection” /v “DisableRealtimeMonitoring” /t REG_DWORD /d “1” /f

cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection” /v “DisableScanOnRealtimeEnable” /t REG_DWORD /d “1” /f

cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection” /v “DisableOnAccessProtection” /t REG_DWORD /d “1” /f

cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection” /v “DisableIOAVProtection” /t REG_DWORD /d “1” /f

cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender\Reporting” /v “DisableEnhancedNotifications” /t REG_DWORD /d “1” /f

cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender\SpyNet” /v “DisableBlockAtFirstSeen” /t REG_DWORD /d “1” /f

cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender\SpyNet” /v “SubmitSamplesConsent” /t REG_DWORD /d “0” /f

cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender\MpEngine” /v “MpEnablePus” /t REG_DWORD /d “0” /f

cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender” /v “DisableAntiSpyware” /t REG_DWORD /d “1”

cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender” /v “DisableAntiVirus” /t REG_DWORD /d “1” /f

cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender\SpyNet” /v “SpynetReporting” /t REG_DWORD /d “0” /f

cmd.exe /c reg add “HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection” /v “DisableBehaviorMonitoring” /t REG_DWORD /d “1” /f Figure 14: Windows Defender registry key modification Tool Prevalence Throughout 2025, we continued to see ransomware actors rely heavily on publicly available tools and legitimate software across various stages of ransomware intrusions. While legitimate software remains popular, we observed a slight decrease in the use of RMM tools and post-exploitation C2 frameworks. Notably, both WinRAR and Rclone were observed in almost one-fourth of incidents, likely corresponding with the increase in incidents involving data theft, given that these tools are regularly used to stage and exfiltrate data respectively. Threat actors used post-exploitation C2 frameworks in about 15% of 2025 ransomware incidents, a decrease from almost 20% in 2024. The decline in the use of post-exploitation frameworks is largely due to the continued reduction in use of Cobalt Strike BEACON. Cobalt Strike BEACON was deployed in only 2% of 2025 ransomware incidents, continuing a multi-year downward trend; in 2021 roughly 60% of ransomware incidents involved BEACON, dropping to around 38% in 2022, 20% in 2023, and 11% in 2024. This decrease could in part be attributed to some subset of actors exploring new frameworks, like AdaptixC2. We observed approximately 8% of intrusions involving the AdaptixC2 (ADAPTAGENT) post-exploitation framework. AdaptixC2 is an open-source post-exploitation framework developed for penetration testers; however, similar to the use of CobaltStrike for many years, threat actors often abuse these types of pentesting tools to facilitate their operations. Less frequently, we observed the penetration frameworks associated with MYTHICAGENT, METASPLOIT, HAVOC, and EXPLORATIONC2. Extending a trend identified last year, threat actors appear slightly less reliant on remote management tools. Around 24% of 2025 incidents involved at least one RMM, compared to 28% in 2024, and 40% in 2023. We observed 10 unique remote management tools in ransomware incidents in 2025 comparable to nine in 2024, but an overall decrease from 13 in 2023. We also saw a decrease in instances of threat actors leveraging multiple different RMMs within the same intrusion. In 2025, multiple RMMs were only observed in ~5% of incidents, compared to 8% in 2024, and 16% in 2023. Consistent with recent years, AnyDesk remained the most commonly deployed RMM in ransomware incidents in 2025; however, overall use decreased from roughly 31% in 2023 and 16% in 2024 to 10% in 2025. Threat actors’ use of tunnelers remained fairly consistent as compared to 2024; however, there were small shifts in the use of specific tunnelers. For example, CLOUDFLARED was observed in 8% of incidents in 2025 compared to around 4% in 2024. We’ve observed a negligible decline in the use of SYSTEMBC, with around 14% of incidents involving the tunneler in 2023, a little over 7% in 2024, and down to a little over 6% in 2025. Notably, Operation Endgame disrupted SYSTEMBC infrastructure in May 2024; while the malware is still being sold on forums, it’s plausible that the law enforcement disruption dissuaded some threat actors from continuing to use the malware in their operations. Throughout 2025, threat actors continued to leverage common publicly available network scanning tools such as Advanced IP Scanner and SoftPerfect Network Scanner in around 50% of intrusions, consistent with the 2024 rate. In 2025, we observed an increase in the use of public tools like WinRAR and Rclone that are often used by threat actors to facilitate data theft, which aligns with our overall increase in incidents involving suspected or confirmed data theft from 2024 to 2025. Both WinRAR and Rclone were observed in approximately 23% of incidents; in 2024, we observed around 16% of intrusions involving Rclone and only around 8% involving WinRAR. Remediation and Hardening Recommendations to assist in addressing the threat posed by ransomware are captured in our white paper, Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment . Outlook and Implications Despite ongoing turmoil caused by actor conflicts and disruption, ransomware actors remain highly motivated and the extortion ecosystem demonstrates continued resilience. Several indicators suggest the overall profitability of these operations is, however, declining, and at least some threat actors are shifting their targeting calculus away from large companies to instead focus on higher volume attacks against smaller organizations. This is likely due to increased difficulty in successful deployments due to victims’ improved security postures, a greater refusal to pay ransom demands, and enhanced recovery capabilities. In the coming years, evolving regulations, including reporting requirements and payment bans, may further dissuade some companies from making ransom payments. While we anticipate ransomware to remain one of the most dominant threats globally, the reduction in profits may cause some threat actors to seek other monetization methods. This could manifest as increased data theft extortion operations, the use of more aggressive extortion tactics, or opportunistically using access to victim environments for secondary monetization mechanisms such as using compromised infrastructure to send phishing messages. Detections YARA Rules AGENDA rule M_APTFIN_Ransom_AGENDA_1 {
meta:
author = “Google Threat Intelligence Group (GTIG)”

strings:
$conf1 = “public_rsa_pem” fullword
$conf2 = “private_rsa_pem” fullword
$conf3 = “directory_black_list” fullword
$conf4 = “file_black_list” fullword
$conf5 = “file_pattern_black_list” fullword
$conf6 = “process_black_list” fullword
$conf7 = “win_services_black_list” fullword
$conf8 = “company_id” fullword
$conf9 = “note” fullword
$load_const1 = { 21 B7 F6 F7 }
$load_const2 = { F6 36 A4 69 }
$load_s1 = “run_portable_executable” fullword
$load_s2 = “MemoryLoadLibrary” fullword
$load_s3 = “_ZN9morph_poc4main”
$note1 = “Extension: ”
$note2 = “Domain: ”
$note3 = “login: ”
$note4 = “password: ”
$note5 = “Enter credentials– Credentials”
$note6 = “– Qilin”
$note7 = “– Recovery”
$note8 = “www.torproject.org”
$note9 = “.onion”
$note10 = “Employees personal data, CVs, DL , SSN.”
$note11 = “%s/%s_RECOVER.txt”
condition:
uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and (7 of ($conf*) or 7 of ($note*) or all of ($load*))
} AGENDA.RUST rule M_Hunting_Win_Ransomware_AGENDA_RUST_2_MBeta {
meta:
author = “Google Threat Intelligence Group (GTIG)”

strings:
$rust = “/rust/”
$conf1 = “\”public_rsa_pem\”:”
$conf2 = “\”private_rsa_pem\”:”
$conf3 = “\”directory_black_list\”:”
$conf4 = “\”file_black_list\”:”
$conf5 = “\”file_pattern_black_list\”:”
$conf6 = “\”process_black_list\”:”
$conf7 = “\”win_services_black_list\”:”
$conf8 = “\”company_id\”:”
$conf9 = “\”n\”:”
$conf10 = “\”p\”:”
$conf11 = “\”fast\”:”
$conf12 = “\”skip\”:”
$conf13 = “\”step\”:”
$conf14 = “\”accounts\”:”
$conf15 = “\”note\”:”
condition:
uint16(0) == 0x5a4d and uint32(uint32(0x3C)) == 0x00004550 and filesize < 5MB and (($rust and 8 of ($conf*)) or (13 of ($conf*))) } REDBIKE rule M_Ransom_REDBIKE_2 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $a1 = ".akira" $a2 = "akira_readme.txt" $a3 = "akiralkzxzq2dsrzsrvbr2xgbbu2wgsmxryd4csgfameg52n7efvr2id" $s1 = "--encryption_percent" ascii wide nocase $s2 = "--encryption_path" ascii wide nocase $s3 = "--share_file" ascii wide nocase condition: ((all of ($s*)) and (any of ($a*))) and (uint16(0) == 0x5A4D) and filesize > 500KB and filesize < 2MB } REDBIKE.LINUX rule M_APTFIN_Ransom_REDBIKE_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $a = "akira_readme.txt" $b = "save your TIME, MONEY, EFFORTS" $c = "akiral2iz6a7qgd3ayp3l6yub7xx2uep76idk3u2kollpj5z3z636bad.onion" $d = "--encryption_percent" $e = "--encryption_path" $f = "--share_file" condition: all of them and (uint32be(0) == 0x7F454C46) } CLOP rule M_Hunting_CLOP_rol7XorHash32_ConfigHashes_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $hex_asm_literal_a = { 92 F7 53 7A } $hex_asm_literal_b = { 43 29 79 71 } $hex_asm_literal_c = { 2A 81 C4 E2 } $hex_asm_literal_d = { 2E F4 FA 7E } $hex_asm_literal_e = { 31 E5 7F 91 } $hex_asm_literal_f = { 16 24 45 D6 } $hex_asm_literal_g = { 56 22 93 EA } condition: all of them } CLOP.LINUX rule M_Ransom_CLOP_3 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $str_jobmessage_a = "Successfully started daemon-name" $str_jobmessage_b = "Could not change working directory to /" $str_jobmessage_c = "Could not generate session ID for child process" $asm_code_fileordirectory = { 25 00 F0 00 00 3D 00 40 00 00 75 } $asm_functioncall_open64_readfile = { 80 01 00 00 C7 44 ( 2? | 6? | A? | E? ) ?? 02 00 00 00 } $asm_functioncall_open64_writebytes = { B4 01 00 00 C7 44 ( 2? | 6? | A? | E? ) ?? 42 00 00 00 } $asm_encryption_filebuffersize = { 00 E1 F5 05 76 ?? C7 45 ?? 00 E1 F5 05 } $asm_encryption_generatekey = { 1F 89 ( C? | D? | E? | F? ) C1 ( C? | D? | E? | F? ) 18 8D ( 0? | 1? ) ( 0? | 1? ) 25 FF 00 [0-2] 29 ( C? | D? | E? | F? ) 83 ( C? | D? | E? | F? ) 01 C9 } condition: uint32(0) == 0x464C457F and all of ($str_*) or (#asm_code_fileordirectory == 2 and #asm_functioncall_open64_writebytes == 2 and ($asm_encryption_generatekey and $asm_functioncall_open64_readfile and $asm_encryption_filebuffersize)) } PLAYCRYPT rule M_Ransomware_PLAYCRYPT_1 { meta: author = "Google Threat Intelligence Group (GTIG)" date_created = "2022-12-21" date_modified = "2022-12-21" rev = "1" strings: $c1 = { 8A CB 0F B6 D0 8B F2 8B FA D3 EE 8D 4B 01 D3 EF 83 E6 01 83 E7 01 } $c2 = { 8D 45 F0 C7 85 D0 FD FF FF 00 00 00 00 50 83 EC 08 } $c3 = { 8B 14 0A 8B 4C 32 20 03 D6 89 55 E0 03 CE } $c4 = { 8D 8D 80 ?? FF FF E8 C8 ?? FF FF 85 C0 75 61 83 BD [2] FF FF 05 76 58 } $c5 = { FF 76 ?? C6 45 EE 00 E8 [2] 00 00 8B F0 8B CF 33 C0 85 F6 0F 48 F0 E8 } $c6 = { FF D0 8B F8 83 FF 05 0F [2] 01 00 00 83 FF 06 0F [2] 01 00 00 8B 0E 3B 4E 04 0F [2] 01 00 00 83 FF 04 74 6D 83 FF 01 } $s1 = "OpaqueKeyBlob" wide $s2 = "AppPolicyGetProcessTerminationMethod" condition: uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and filesize > 100KB and filesize < 200KB and ((2 of ($c*) and all of ($s*)) or (4 of ($c*))) } PLAYCRYPT.LINUX rule G_Ransom_PLAYCRYPT_LINUX_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $s1 = "First step is done." $s2 = "/dev/urandom" $s3 = "esxcli storage filesystem list > storage”
$s4 = “hosts in exclusion:”
$s5 = “encrypt: ”
$s6 = “.PLAY” fullword
condition:
uint32(0) == 0x464C457F and all of them
} SAFEPAY import “pe”

rule G_Ransom_SAFEPAY_1 {
meta:
author = “Google Threat Intelligence Group (GTIG)”
strings:
$hex_asm_snippet = { 10 27 00 00 [0-4] 10 27 00 00 }
condition:
pe.imphash() == “ff67c703589f775db9aed5a03e4489b0” and ($hex_asm_snippet)
} rule G_Ransom_SAFEPAY_2 {
meta:
author = “Google Threat Intelligence Group (GTIG)”
strings:
$code_string_decode = { 8A C2 32 C1 32 44 0D ?? 34 ?? 88 44 0D ?? 41 83 F9 04 [4-64] B? 4D 5A 00 00 }
$code_hardware_aes_check = { 0F A2 8B F3 5B 89 07 89 77 ?? 89 4F ?? 89 57 [0-12] ( 00 00 00 02 | C1 ?? 19 ) }
$code_encrypt_file = { 14 00 10 00 [2-24] 14 00 10 00 [2-32] 00 10 00 5? [0-8] FF ( 15 | D? ) }
$enc_str1 = { C7 45 ?? 67 4B 3D 49 C7 45 ?? 2F 4F 2F 4D }
$enc_str2 = { C7 45 ?? 10 3C 51 3E C7 45 ?? 5C 38 4F 3A C7 45 ?? 42 34 58 36 C7 45 ?? 43 30 58 32 66 C7 45 ?? 2D 2C }
$enc_str3 = { C7 45 ?? A3 8F FF 8D C7 45 ?? EF 8B E4 89 C7 45 ?? E0 87 E0 85 C7 45 ?? E7 83 EC 81 C7 45 ?? FB 9F E8 9D C7 45 ?? FF 9B 98 99 }
$enc_str4 = { C7 45 ?? 44 40 51 47 C7 45 ?? 51 49 10 10 C7 45 ?? 03 48 43 42 C6 45 ?? 29 }
$enc_str5 = { C7 45 ?? 77 77 73 74 C7 45 ?? 75 6D 64 70 C7 45 ?? 23 68 63 62 C6 45 ?? 09 }
condition:
uint16(0) == 0x5a4d and (all of ($code*) or (any of ($code*) and any of ($enc*)) or (2 of ($enc*)))
} INC rule M_Ransom_INC_1 {
meta:
author = “Google Threat Intelligence Group (GTIG)”
strings:
$s1 = “[*] Count of arguments: %d” wide
$s2 = “[-] Failed” wide
$s3 = “[+] Start” wide
$s4 = “INC-README” wide
$s5 = “–debug” wide
$s6 = “RECYCLE” wide
condition:
all of them and (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550)
} INC (Lynx Branded) rule M_Ransom_INC_2 {
meta:
author = “Google Threat Intelligence Group (GTIG)”
strings:
$s1 = “[+] Proccess %s with PID: %d was killed succesffully” wide
$s2 = “[*] Sending note to printer:” wide
$s3 = “[+] Recycling bin…” wide
$s4 = “[*] Starting full encryption in 5s” wide
$s5 = “[+] Successfully decoded readme!” wide
$s6 = “[-] Failed” wide
$lynx = “lynx” ascii wide nocase
condition:
$lynx and 4 of ($s*) and (uint16(0) == 0x5A4D) and filesize < 300KB and filesize > 50KB
} INC (Sinobi Branded) rule G_Ransom_INC_3 {
meta:
author = “Google Threat Intelligence Group (GTIG)”
strings:
$s1 = “[+] Proccess %s with PID: %d was killed succesffully” wide
$s2 = “[*] Sending note to printer:” wide
$s3 = “[+] Recycling bin…” wide
$s4 = “[*] Starting full encryption in 5s” wide
$s5 = “[+] Successfully decoded readme!” wide
$s6 = “[-] Failed” wide
$sin = “sinobi” ascii wide nocase
condition:
$sin and 4 of ($s*) and (uint16(0) == 0x5A4D) and filesize < 400KB and filesize > 50KB
} INC.LINUX rule M_Ransom_INC_2 {
meta:
author = “Google Threat Intelligence Group (GTIG)”
strings:
$s1 = “[*] Count of arguments: %d”
$s2 = “[-] Failed”
$s3 = “[+] Start”
$s4 = “INC-README”
$s5 = “–debug”
$s6 = “vmsvc”
condition:
all of them and uint32(0) == 0x464c457f
} RANSOMHUB rule M_Ransom_RANSOMHUB_1 {
meta:
author = “Google Threat Intelligence Group (GTIG)”
strings:
$str1 = “json:\”settings\””
$str2 = “json:\”extension\””
$str3 = “json:\”net_spread\””
$str4 = “json:\”local_disks\””
$str5 = “json:\”running_one\””
$str6 = “json:\”self_delete\””
$str7 = “json:\”white_files\””
$str8 = “json:\”white_hosts\””
$str9 = “json:\”credentials\””
$str10 = “json:\”kill_services\””
$str11 = “json:\”set_wallpaper\””
$str12 = “json:\”white_folders\””
$str13 = “json:\”note_file_name\””
$str14 = “json:\”note_full_text\””
$str15 = “json:\”kill_processes\””
$str16 = “json:\”network_shares\””
$str17 = “json:\”note_short_text\””
$str18 = “json:\”master_public_key\””
condition:
14 of them
} FURYSTORM rule G_Ransom_FURYSTORM_1 {
meta:
author = “Google Threat Intelligence Group (GTIG)”
strings:
$s1 = “Whitelist VM id”
$s2 = “gwfn6l3bk45o2zecvi7xtyqrpsudmahj”
$s3 = “Dry-run”
$s4 = “-paths”
$s5 = “-vmsvc”
$s6 = “Note: motd=%d login=%d clean=%d”
$s7 = “Cryptor args”
$s8 = “VMX found”
$s9 = “Keys: %016l”
$s10 = “vim-cmd”
$s11 = “Dropping readme”
$s12 = “Encryption params”
condition:
uint32(0) == 0x464c457f and filesize > 50KB and filesize < 700KB and 6 of them } rule G_Ransom_FURYSTORM_2 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $s1 = "Failed decrypt file:" $s2 = "Decryptor args:" $s3 = "Private key loaded" $s4 = "Keys: %016l" $s5 = "Dry-run" $s6 = "Encryption params" $s7 = "Whitelist paths" $s8 = "Note: motd=%d" condition: uint32(0) == 0x464c457f and filesize > 50KB and filesize < 300KB and 6 of them } FIREFLAME rule M_Autopatt_Ransom_FIREFLAME_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $p00_0 = { 8B CE 8D 5F ?? 8A 01 8D 49 ?? 0F B6 C0 83 E8 ?? 8D 04 40 C1 E0 ?? 99 } $p00_1 = { 55 8B EC FF 75 ?? E8 [4] 59 8B 4D ?? 89 01 F7 D8 1B C0 } condition: uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and (($p00_0 in (0 .. 380000) and $p00_1 in (260000 .. 280000))) } Acknowledgements This analysis would not have been possible without the assistance of Dima Lenz, Chastine Altares, Ana Foreman, and the Advanced Practices, Mandiant Consulting, and FLARE teams.

Original: https://cloud.google.com/blog/topics/threat-intelligence/ransomware-ttps-shifting-threat-landscape/
⚡ Weekly Recap: Chrome 0-Days, Router Botnets, AWS Breach, Rogue AI Agents & More

Source: The Hacker News | Published: 2026-03-16T14:17:00+00:00 | Score: 14.466

Some weeks in security feel normal. Then you read a few tabs and get that immediate “ah, great, we’re doing this now” feeling.
This week has that energy. Fresh messes, old problems getting sharper, and research that stops feeling theoretical real fast. A few bits hit a little too close to real life, too. There’s a good mix here: weird abuse of trusted stuff, quiet infrastructure ugliness,

Original: https://thehackernews.com/2026/03/weekly-recap-chrome-0-days-router.html
Attackers Don’t Just Send Phishing Emails. They Weaponize Your SOC’s Workload

Source: The Hacker News | Published: 2026-03-12T11:30:00+00:00 | Score: 13.231

The most dangerous phishing campaigns aren’t just designed to fool employees. Many are designed to exhaust the analysts investigating them. When a phishing investigation takes 12 hours instead of five minutes, the outcome can shift from a contained incident to a breach.
For years, the cybersecurity industry has focused on the front door of phishing defense: employee training, email gateways that

Original: https://thehackernews.com/2026/03/attackers-dont-just-send-phishing.html
UK’s Companies House confirms security flaw exposed business data

Source: BleepingComputer | Published: 2026-03-16T17:07:25+00:00 | Score: 12.924

Companies House, a British government agency that operates the registry for all U.K. companies, says its WebFiling service is back online after it was closed on Friday to fix a security flaw that exposed companies’ information since October 2025. […]

Original: https://www.bleepingcomputer.com/news/security/uks-companies-house-confirms-security-flaw-exposed-business-data/