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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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

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

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

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

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

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

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.

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.

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

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.

Figure 5: GPO path for creating Windows Firewall rules

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.

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.

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.

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

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

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

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

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$

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

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

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.

To enforce the additional steps for disabling WinRM via PowerShell (Figure 19 through Figure 22):

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

   
   
2. Disable the listener that accepts requests on any IP address.
   
   

   dir wsman:\localhost\listener
   
   Remove-Item -Path WSMan:\Localhost\listener\<Listener name>

   Figure 20: PowerShell commands to delete a WSMan listener

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

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

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.

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\<username>\Documents
  • C:\users\Public\Documents
• Pictures
  • C:\users\<username>\Pictures
  • C:\users\Public\Pictures
• Videos
  • C:\users\<username>\Videos
  • C:\users\Public\Videos
• Music
  • C:\users\<username>\Music
  • C:\users\Public\Music
• Desktop
  • C:\users\<username>\Desktop
  • C:\users\Public\Desktop
• Favorites
  • C:\users\<username>\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

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 <output directory>\DomainAdmins.csv -NoTypeInformation 

get-ADGroupMember -Identity "Enterprise Admins" -Recursive | export-csv -path <output directory>\EnterpriseAdmins.csv -NoTypeInformation 

get-ADGroupMember -Identity "Schema Admins" -Recursive | export-csv -path <output directory>\SchemaAdmins.csv -NoTypeInformation

get-ADGroupMember -Identity "Administrators" -Recursive | export-csv -path <output directory>\Administrators.csv -NoTypeInformation 

get-ADGroupMember -Identity "Account Operators" -Recursive | export-csv -path <output directory>\AccountOperators.csv -NoTypeInformation 

get-ADGroupMember -Identity "Backup Operators" -Recursive | export-csv -path <output directory>\BackupOperators.csv -NoTypeInformation 

get-ADGroupMember -Identity "Cert Publishers" -Recursive | export-csv -path <output directory>\CertPublishers.csv -NoTypeInformation 

get-ADGroupMember -Identity "Print Operators" -Recursive | export-csv -path <output directory>\PrintOperators.csv -NoTypeInformation 

get-ADGroupMember -Identity "Server Operators" -Recursive | export-csv -path <output directory>\ServerOperators.csv -NoTypeInformation 

get-ADGroupMember -Identity "DNSAdmins" -Recursive | export-csv -path <output directory>\DNSAdmins.csv -NoTypeInformation 

get-ADGroupMember -Identity "Group Policy Creator Owners" -Recursive | export-csv -path <output directory>\Group-Policy-Creator-Owners.csv -NoTypeInformation 

get-ADGroupMember -Identity "Exchange Trusted Subsystem" -Recursive | export-csv -path <output directory>\Exchange-Trusted-Subsystem.csv -NoTypeInformation

get-ADGroupMember -Identity "Exchange Windows Permissions" -Recursive | export-csv -path <output directory>\Exchange-Windows-Permissions.csv -NoTypeInformation 

get-ADGroupMember -Identity "Exchange Recipient Administrators" -Recursive | export-csv -path <output directory>\Exchange-Recipient-Admins.csv -NoTypeInformation 

get-ADUser -Filter {(AdminCount -eq 1) -And (Enabled -eq $True)} | Select-Object Name, DistinguishedName | export-csv -path <output directory>\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

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

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)

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

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

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

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.

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

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

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

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