AI as a Tool

Threat actors are leveraging AI to augment various phases of the attack lifecycle. This includes supporting the development of vulnerability exploits and malware, facilitating autonomous execution of commands, enabling more targeted and well-researched reconnaissance, and improving the efficacy of social engineering and information operations.

AI-Augmented Vulnerability Discovery and Exploit Development

As the coding capabilities of AI models advance, we continue to observe adversaries increasingly leverage these tools as expert-level force multipliers for vulnerability research and exploit development, including for zero-day vulnerabilities. While these tools empower defensive research, they also lower the barrier for adversaries to reverse-engineer applications and develop sophisticated, AI-generated exploits.

State-Sponsored Threat Actors Demonstrate Sophisticated Approaches to Leveraging AI for Vulnerability Research

While we observe a variety of threat actors leveraging AI for vulnerability research, we noted a particular interest from several clusters of threat activity associated with the People’s Republic of China (PRC) and the Democratic People's Republic of Korea (DPRK). These actors have leveraged sophisticated approaches toward AI-augmented vulnerability discovery and exploitation, beginning with persona-driven jailbreaking attempts and the integration of specialized, high-fidelity security datasets to augment their vulnerability discovery and exploitation workflows.

• As we highlighted in prior blog posts, threat actors often leverage expert cybersecurity personas as a structured approach to prompt Gemini. For instance, we recently observed UNC2814 use this form of expert persona prompting by directing the model to act as a senior security auditor or C/C++ binary security expert. The fabricated scenarios were used to support vulnerability research into various embedded device targets, including TP-Link firmware and Odette File Transfer Protocol (OFTP) implementations.

Figure 1: Example of false narratives used to support persona-driven jailbreaking, a simple form of prompt injection

• In a more sophisticated use case, we observed threat actors experiment with a specialized vulnerability repository hosted on GitHub known as “wooyun-legacy.” The project is designed as a Claude code skill plugin that integrates a distilled knowledge base of over 85,000 real-world vulnerability cases collected by the Chinese bug bounty platform WooYun between 2010 and 2016. By priming the model with vulnerability data, it facilitates in-context learning to steer the model to approach code analysis like a seasoned expert and identify logic flaws that the base model might otherwise fail to prioritize.

In their pursuit of this vulnerability research, we see clear indications of automation and scaled research. In addition to leveraging individual prompts for real-time troubleshooting, we have observed APT45 sending thousands of repetitive prompts that recursively analyze different CVEs and validate PoC exploits. This results in a more robust arsenal of exploit capabilities that would be impractical to manage without AI assistance.

To facilitate these activities, actors are also experimenting with agentic tools such as OpenClaw and OneClaw alongside intentionally vulnerable testing environments. The use of these tools alongside vulnerability research suggests an interest in refining AI-generated payloads within controlled settings to increase exploit reliability prior to deployment.

Cyber Crime Threat Actors Discover and Weaponize Zero-Day Using AI

Cyber crime threat actors remain interested in leveraging AI for vulnerability development as well. In one notable example, we observed prominent cyber crime threat actors partnering to plan a mass vulnerability exploitation operation. Our analysis of exploits associated with this campaign identified a zero-day vulnerability implemented in a Python script that enables the user to bypass two-factor authentication (2FA) on a popular open-source, web-based system administration tool. GTIG worked with the impacted vendor to responsibly disclose this vulnerability and disrupt this threat activity.

Although we do not believe Gemini was used, based on the structure and content of these exploits, we have high confidence that the actor likely leveraged an AI model to support the discovery and weaponization of this vulnerability. For example, the script contains an abundance of educational docstrings, including a hallucinated CVSS score, and uses a structured, textbook Pythonic format highly characteristic of LLMs training data (e.g., detailed help menus and the clean _C ANSI color class).

The vulnerability can be classified as a 2FA bypass, though it requires valid user credentials in the first place. It stems not from common implementation errors like memory corruption or improper input sanitization, but a high-level semantic logic flaw where the developer hardcoded a trust assumption. While fuzzers and static analysis tools are optimized to detect sinks and crashes, frontier LLMs excel at identifying these types of high-level flaws and hardcoded static anomalies. Though frontier LLMs struggle to navigate complex enterprise authorization logic, they have an increasing ability to perform contextual reasoning, effectively reading the developer's intent to correlate the 2FA enforcement logic with the contradictions of its hardcoded exceptions. This capability can allow models to surface dormant logic errors that appear functionally correct to traditional scanners but are strategically broken from a security perspective.

AI-Augmented Obfuscation: Evasion and Polymorphism

GTIG has identified multiple threat actors experimenting with AI models to develop malware and operational support tools to augment obfuscation capabilities. This has included innovative applications of AI to incorporate just-in-time dynamic modification of source code, enable dynamic payload generation, assist in development of ORB network management tools, and generate decoy code (Table 1). While often experimental, this transition underscores a move toward AI-driven, evasive software suites.

In prior reports, we highlighted malware families like PROMPTFLUX, notable for its experimentation using the Gemini API to generate code, and HONESTCUE, which interacts with Gemini's API to request specific VBScript obfuscation and evasion techniques to facilitate just-in-time self-modification to evade static signature-based detection. In this report, we highlight additional tools and malware families created with the assistance of AI to support obfuscation and defense evasion.

We observed activity associated with the PRC-nexus threat actor APT27, which has leveraged Gemini to accelerate the development of a fleet management application likely to support the management of an operational relay box (ORB) network. Our observations of the tool revealed a "maxHops" parameter hardcoded to 3 hops, an indicator that the tool was related to development of an anonymization network rather than a VPN since those are typically set to 1 hop. Additionally, the tool lists MOBILE_WIFI and ROUTER as supported device types, suggesting it uses 4G or 5G SIM cards to provide residential IP addresses to potentially obfuscate the true origin of the intrusion activity. 

Additionally, GTIG has continued to observe Russia-nexus intrusion activity targeting Ukrainian organizations to deliver AI-enabled malware as part of their operations. Analysis confirms the use of CANFAIL and LONGSTREAM, which utilize LLM-generated decoy code to obfuscate their malicious functionality. 

• We identified multiple developer (i.e., the LLM) comments throughout CANFAIL's source code that specifically call out certain blocks of code that are not used and were likely incorporated as filler content designed to obfuscate malicious activity. The explanatory nature of these comments surrounding the decoy logic likely indicates the threat actor requested the LLM generate outputs that intentionally contained large amounts of inert code potentially for obfuscation (Figure 4).

• Similarly, our examination of the LONGSTREAM code family suggests a large volume of decoy logic was likely generated to camouflage the malicious nature of the code family. LONGSTREAM contains coherent but inactive blocks of code related to administrative tasks that are unrelated to the primary objective of the downloader. For example, we identified 32 instances of the code querying the system's daylight saving status. This type of repetitive query exists to populate the script with activity that can appear benign (Figure 5).

AI-Augmented Attack Orchestration: PROMPTSPY

Adversaries are advancing their implementation of AI-enabled tooling, moving beyond content generation and tool development and into more sophisticated autonomous attack orchestration for malware commands. Threat actors have begun relying on LLMs for interactive system navigation and real-time decision making. By integrating LLMs into malware operations, attackers can enable payloads to act autonomously, independently interacting with the victim environment or device, synthesizing system states, and executing precise commands devoid of human supervision.

A primary example of this evolution is PROMPTSPY, an Android backdoor first identified by ESET. Initial public reporting highlighted PROMPTSPY’s use of the Google Gemini application programming interface (API) to facilitate persistence, specifically by navigating the Android UI to pin the malicious application in the "recent apps" list. However, GTIG's examination of the backdoor revealed additional capabilities and use cases for its AI integration. We assess the malware's LLM component was designed to be extensible to support a broader range of goals centered around navigating the Android user interface and autonomously interpreting real-time user activity for follow-on actions. 

PROMPTSPY contains an autonomous agent module named “GeminiAutomationAgent,” which leverages a hardcoded prompt to facilitate automated interaction with the targeted device.

• The prompt assigns a benign persona to bypass the LLM's safety filters, then requests an analysis of complex spatial mathematics by instructing the LLM to calculate the geometry of the targeted user interface bounds. This is paired with a set of "Core Judgment Rules" that implement anti-hallucination measures and a “User Goal” concatenated to the prompt as part of a separate routine (Figure 6).

• The module then serializes the device's visible user interface hierarchy into an XML-like format via the Accessibility API, sending this payload to the “gemini-2.5-flash-lite” model via an HTTP POST request in "JSON Mode." 

• The model returns a structured JSON response based on the supplied user goal, dictating specific action types and spatial coordinates, which the malware parses using a packed-switch instruction to simulate physical gestures (e.g., CLICK, SWIPE). Since the user goal is not hardcoded in the initial prompt but supplied as part of a separate routine, we believe PROMPTSPY was likely designed to facilitate multiple types of device interactions.

Additionally, PROMPTSPY can capture victim biometric data to replay authentication gestures (personal identification numbers or lock patterns) to regain access to a compromised device for follow-on exploitation. These AI-enabled capabilities are a notable evolution from conventional Android backdoors that heavily rely on human interaction.

To maintain persistence, PROMPTSPY utilizes a novel multi-layered defense mechanism to camouflage its activity and prevent uninstallation. 

• If the victim tries to uninstall PROMPTSPY, the malware employs its 'AppProtectionDetector' module to identify the on-screen coordinates of the 'Uninstall' button. The malware renders an invisible overlay directly over the button as a shield that silently intercepts and consumes the victim's touch events, making the button appear unresponsive to the user.

• If the victim device becomes inactive, PROMPTSPY operators can utilize Firebase Cloud Messaging (FCM) to relaunch the backdoor, allowing the threat actor to continue their intrusion activity without alerting the victim. 

While PROMPTSPY initializes using hardcoded default infrastructure and credentials, the malware is designed with high operational resilience, allowing adversaries to rotate critical components at runtime without redeploying the PROMPTSPY payload. Specifically, the malware’s command-and-control (C2) infrastructure, including the Gemini API keys and the VNC relay server, can be updated dynamically via the C2 channel. This configuration model demonstrates the developers anticipated defensive countermeasures and engineered the backdoor to maintain presence even if specific infrastructure endpoints are identified and blocked by defenders.

Google has taken action against this actor by disabling the assets associated with this activity. Based on our current detection, no apps containing PROMPTSPY are found on Google Play. Android users are automatically protected against known versions of this malware by Google Play Protect, which is on by default on Android devices with Google Play Services.

AI-Augmented Research, Reconnaissance, and Attack Lifecycle Support

Malicious adversaries' most common use case for LLMs mirrors that of standard users – they conduct research and troubleshoot tasks. GTIG has observed a variety of threat actors engaging in this type of prompting to support research, reconnaissance, and troubleshooting throughout various phases of the attack lifecycle. By automating intelligence gathering and task support, these interactions lower the barrier to entry for complex, multi-stage operations and enable threat actors to focus their human capital on the higher-order strategic elements of campaigns.

Adversaries frequently use LLMs to perform reconnaissance that would previously have required significant manual effort. For instance, we have observed actors prompting models to generate detailed organizational hierarchies for specific departments and third-party relationships of large enterprises, particularly those involving high-value functions like finance, internal security, and human resources. This data allows for the creation of higher-fidelity phishing lures tailored to individuals with administrative privileges or access to sensitive data, moving beyond the commodity tactics of traditional bulk phishing.

In more targeted scenarios, actors have used LLMs to identify specific hardware or software environments used by their victims. In one instance, a threat actor attempted to identify the exact make and model of a computer used by a high-value target, even requesting the LLM identify a collection of photos showing the targeted individual using the device. This level of environmental fingerprinting often precedes the development of tailored exploits or identification of side-channel attack opportunities.

Beyond basic chat interfaces, we see a sophisticated shift toward agentic workflows where adversaries operationalize autonomous frameworks to execute multi-stage security tasks. This marks a significant evolution in the maturity of AI-related threats: the LLM is no longer merely a passive advisor but an active participant in the offensive chain, capable of orchestrating complex toolsets and making tactical decisions at machine speed.

For example, we recently analyzed a suspected PRC-nexus threat actor deploying agentic tools like Hexstrike and Strix against a Japanese technology firm and a prominent East Asian cybersecurity platform. Hexstrike was utilized alongside the Graphiti memory system, a temporal knowledge graph, to maintain a persistent state of the attack surface, allowing the agent to autonomously pivot between tools like subfinder and httpx based on its internal reasoning. Simultaneously, the actor leveraged Strix, a multi-agent penetration testing framework, to automate the identification and validation of vulnerabilities. This combination of autonomous reconnaissance and automated verification suggests a transition toward AI-driven frameworks that can scale discovery activities with minimal human oversight.

AI-Augmented Information Operations

GTIG continues to observe information operations (IO) actors use AI for common productivity tasks like research, content creation, and localization. We have also identified activity indicating threat actors solicit the tool to help craft articles, generate assets, and assist in coding. However, we have not identified this generated content in the wild, and none of these attempts have created breakthrough capabilities for IO campaigns. 

Actors from Russia, Iran, China, and Saudi Arabia are producing political satire and materials to advance specific narratives across both digital platforms and physical media, such as printed posters. The primary advances we have seen in this area include actors appearing more successful in developing tooling in support of their workflows and the growing adoption of AI-generated narrative audio to address contentious political topics. 

AI to Support IO Tactics

GTIG’s tracking of IO threats across the open internet continues to uncover activity illustrating how threat actors use AI tooling to enhance established tactics. For example, GTIG uncovered activity linked to the pro-Russia IO campaign “Operation Overload,” involving video content that leveraged suspected AI voice cloning to impersonate real journalists. This likely represents an AI-supported advancement of the campaign's established tactics, which have long included inauthentic video content designed to appropriate the branding and legitimacy of media and other high profile organizations in support of campaign messaging. 

In identified instances, the actors appear to have manipulated an authentic video to convey a false message. This content appears to splice original vertical videos with montages and fabricated audio to create false and misleading messaging. The close voice match to the original suggests the use of AI tools (Figure 7).

Obfuscated and Scalable Access to LLMs

As the generative AI landscape matures, the methods by which threat actors procure and operationalize these models have shifted from simple experimentation to industrial-scale consumption. Although in prior blog posts we have highlighted AI tools and services offered in the underground, we continue to observe both state-sponsored and cyber crime threat actors leveraging commercially available foundation models and AI-native application building platforms in their pursuit of malicious activity. 

In threat actor engagement with these tools, GTIG has observed a sophisticated evolution to an emerging ecosystem of custom middleware, proxy relays, and automated registration pipelines designed to bypass safety guardrails and billing constraints. By leveraging anti-detect browsers and account-pooling services, actors are attempting to maintain high-volume, anonymized access to premium LLM tiers, effectively industrializing their adversarial workflows while subsidizing their operations through trial abuse and programmatic account cycling.

In our analysis of PRC-nexus threat activity associated with UNC6201, we observed attempted use of a publicly available Python script hosted on GitHub that automates a workflow to register and immediately cancel premium LLM accounts. The tool allegedly supports the entire process from automatic account registration, CAPTCHA bypassing, and SMS verification to account status confirmation and cancellation. This process highlights the methods adversaries leverage to procure high-tier AI capabilities at scale while insulating their malicious activity from account bans.

We have observed similar activity from UNC5673, a PRC-nexus threat cluster that has notable overlaps with TEMP.Hex and that has targeted government sectors primarily in South and Southeast Asia. Beyond LLM account registration, the actor has leveraged an array of publicly available commercial tools and GitHub projects that indicate the development of obfuscated and scalable LLM abuse. For example, they employ "Claude-Relay-Service" to aggregate multiple Gemini, Claude, and OpenAI accounts, enabling account pooling and cost-sharing. Similarly, they use "CLI-Proxy-API," a proxy server that provides compatible API interfaces for various models to support similar account pooling strategies.

To mitigate the nature of this obfuscation, LLM providers can build signal logic to analyze network infrastructure data associated with AI-related API aggregators. This data helps to enable the disruption efforts we highlight in this report.

AI as a Target

As organizations continue integrating large language models (LLMs) into production environments, the AI software ecosystem has emerged as a primary target for exploitation. While frontier models themselves remain highly resilient to direct compromise, the orchestration layers, including open-source wrapper libraries, API connectors, and skill configuration files, can be vulnerable. GTIG has observed adversaries increasingly target the integrated components that grant AI systems their utility, such as autonomous skills and third-party data connectors.

Supply Chain Attacks Against AI Components

Throughout early 2026, we observed that threat actors have not yet achieved breakthrough capabilities to bypass the core security logic of frontier models. Instead, these actors are leveraging traditional supply chain tactics, such as embedding malicious logic in popular integration libraries or distributing trojanized configuration files, to gain initial access to production AI environments. These incidents often align with risks described in the Secure AI Framework (SAIF) taxonomy, specifically:

• Insecure Integrated Component (IIC): Inclusion of compromised external dependencies that undermine the system.

• Rogue Actions (RA): Exploitation of AI systems with elevated permissions to execute unauthorized commands or exfiltrate credentials.

Weaponized OpenClaw Skills

These risks became more apparent in early February 2026, when VirusTotal researchers reported on security risks associated with the OpenClaw AI agent ecosystem, including AI software supply chain risks and vulnerabilities introduced via malicious and insecure skill packages. Most notably, we observed the distribution of malicious packages masquerading as OpenClaw skills containing hidden routines designed to execute unauthorized code and commands on the host system. Given the elevated level of system access that OpenClaw is granted, a skill could be used to perform various privileged actions such as executing code, downloading additional payloads, and discovering and exfiltrating local data.

Further, even if not inherently malicious, insecure packages could expose users to additional risks. Legitimate skills that fail to leverage secure practices when handling sensitive information, such as credentials or authentication information, could inadvertently expose this information to attackers. This could make this information susceptible to theft by techniques like prompt injection, other malicious skills, or traditional malware threats like infostealers.  

While the risk of malicious or insecure skills and agent components are not unique to the OpenClaw platform, the discovery of these packages highlights the growing attack surface among AI development platforms and the agentic ecosystem more broadly. Further, the difficulty in identifying and discerning malicious packages from legitimate skills presents significant challenges for defenders. Although this infection vector is opportunistic by nature, the ease by which these skills can be created and distributed could make it an attractive option for a myriad of threat actors seeking access to users’ systems.

To help mitigate these supply-chain risks, OpenClaw has partnered with VirusTotal to integrate automated security scanning directly into ClawHub, its public skill marketplace. Every skill published to the repository is now automatically analyzed using VirusTotal's Code Insight capability, which evaluates the package's actual code behavior to detect unauthorized network operations, malicious payloads, or unsafe embedded instructions. Based on this security-focused analysis, skills are either approved as benign, flagged with user warnings, or blocked entirely, providing an essential layer of defense against ecosystem abuse.

Compromised Code Packages

In late March 2026, the cyber crime threat actor "TeamPCP" (aka UNC6780) claimed responsibility for multiple supply chain compromises of popular GitHub repositories and associated GitHub Actions, including those associated with the Trivy vulnerability scanner, Checkmarx, LiteLLM, and BerriAI. Mandiant responded to numerous incident response engagements associated with this activity, highlighting the wide-impact nature of supply chain operations.

TeamPCP gained initial access through compromised PyPI packages and malicious pull requests to these GitHub repositories. The threat actor subsequently leveraged their access to these GitHub repositories to embed the SANDCLOCK credential stealer and extract high-value cloud secrets, such as AWS keys and GitHub tokens, directly from affected build environments. These stolen credentials were then monetized through partnerships with ransomware and data theft extortion groups.

The compromise of LiteLLM, an AI gateway utility for integrating multiple LLM providers is noteworthy. It highlights the expanding attack surface of AI platforms and the potential for impact across the software supply chain. Given the package's widespread use, this incident could lead to considerable exposure of AI API secrets from affected victims, which could be used to gain further access to systems for traditional intrusion operations. 

Moreover, similar attacks against AI-related dependencies could grant attackers access to unique AI systems, allowing them to conduct novel AI-centric attacks and leverage them in support of traditional intrusion operations. Attackers could leverage this vector not only to pivot to enterprise infrastructure for traditional financially motivated operations (e.g., data theft and ransomware) but also to directly facilitate their operations using AI systems. For example, threat actors with access to an organization’s AI systems could leverage internal models and tools to identify, collect, and exfiltrate sensitive information at scale or perform reconnaissance tasks to move deeper within a network. While the level of access and particular use depends heavily on the organization and the specific compromised dependency, this case study demonstrates the broadened landscape of software supply chain threats to AI systems.

Building AI Safely and Responsibly

We believe our approach to AI must be both bold and responsible. That means developing AI in a way that maximizes the positive benefits to society while addressing the challenges. Guided by our AI Principles, Google designs AI systems with robust security measures and strong safety guardrails, and we continuously test the security and safety of our models to improve them. 

Our policy guidelines and prohibited use policies prioritize safety and responsible use of Google's generative AI tools. Google's policy development process includes identifying emerging trends, thinking end-to-end, and designing for safety. We continuously enhance safeguards in our products to offer scaled protections to users across the globe.  

At Google, we leverage threat intelligence to disrupt adversary operations. We investigate abuse of our products, services, users, and platforms, including malicious cyber activities by government-backed threat actors, and work with law enforcement when appropriate. Moreover, our learnings from countering malicious activities are fed back into our product development to improve safety and security for our AI models. These changes, which can be made to both our classifiers and at the model level, are essential to maintaining agility in our defenses and preventing further misuse.

Google DeepMind also develops threat models for generative AI to identify potential vulnerabilities and creates new evaluation and training techniques to address misuse. In conjunction with this research, Google DeepMind has shared how they're actively deploying defenses in AI systems, along with measurement and monitoring tools, including a robust evaluation framework that can automatically red team an AI vulnerability to indirect prompt injection attacks. 

Our AI development and Trust & Safety teams also work closely with our threat intelligence, security, and modelling teams to stem misuse.

The potential of AI, especially generative AI, is immense. As innovation moves forward, the industry needs security standards for building and deploying AI responsibly. That's why we introduced the Secure AI Framework (SAIF), a conceptual framework to secure AI systems. We've shared a comprehensive toolkit for developers with resources and guidance for designing, building, and evaluating AI models responsibly. We've also shared best practices for implementing safeguards, evaluating model safety, red teaming to test and secure AI systems, and our comprehensive prompt injection approach.

Working closely with industry partners is crucial to building stronger protections for all of our users. To that end, we're fortunate to have strong collaborative partnerships with security experts via the Coalition for Secure AI (CoSAI) and numerous researchers. We appreciate the work of these researchers and others in the community to help us red team and refine our defenses.

Google also continuously invests in AI research, helping to ensure AI is built responsibly, and that we're leveraging its potential to automatically find risks. Last year, we introduced Big Sleep, an AI agent developed by Google DeepMind and Google Project Zero, that actively searches and finds unknown security vulnerabilities in software. Big Sleep has since found its first real-world security vulnerability and assisted in finding a vulnerability that was imminently going to be used by threat actors, which GTIG was able to cut off beforehand. We're also experimenting with AI to not only find vulnerabilities, but also patch them. We recently introduced CodeMender, an experimental AI-powered agent using the advanced reasoning capabilities of our Gemini models to automatically fix critical code vulnerabilities.

About the Authors

Google Threat Intelligence Group focuses on identifying, analyzing, mitigating, and eliminating entire classes of cyber threats against Alphabet, our users, and our customers. Our work includes countering threats from government-backed actors, targeted zero-day exploits, coordinated IO, and serious cyber crime networks. We apply our intelligence to improve Google's defenses and protect our users and customers.

Appendix

MITRE ATLAS

MITRE ATT&CK

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