Written by: Matthew McWhirt, Bhavesh Dhake, Emilio Oropeza, Gautam Krishnan, Stuart Carrera, Greg Blaum, Michael Rudden
UPDATE (March 13): Added guidance around abuse or misuse of endpoint / MDM platforms.
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.
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 (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
Table 1 provides a high-level overview of guidance in this blog post.
Focus Area
Description
External-Facing Assets
Protect against the risk of threat actors exploiting an externally facing vector or leveraging existing technology for unauthorized remote access.
Critical Asset Protections
Protect specific high-value infrastructure and prepare for recovery from a destructive attack.
On-Premises Lateral Movement Protections
Protect against a threat actor with initial access into an environment from moving laterally to further expand their scope of access and persistence.
Credential Exposure and Account Protections
Protect against the exposure of privileged credentials to facilitate privilege escalation.
Preventing Destructive Actions in Kubernetes and CI/CD Pipelines
Protect the integrity and availability of Kubernetes environments and CI/CD pipelines.
To protect against a threat actor exploiting vulnerabilities or misconfigurations via an external-facing vector, organizations must determine the scope of applications and organization-managed services that are externally accessible. Externally accessible applications and services (including both on-premises and cloud) are often targeted by threat actors for initial access by exploiting known vulnerabilities, brute-forcing common or default credentials, or authenticating using valid credentials.
To proactively identify and validate external-facing applications and services, consider:
Leveraging a vulnerability scanning technology to identify assets and associated vulnerabilities.
Performing a focused vulnerability assessment or penetration test with the goal of identifying external-facing vectors that could be leveraged for authentication and access.
Verifying with technology vendors if the products leveraged by an organization for external-facing services require patches or updates to mitigate known vulnerabilities.
Any identified vulnerabilities should not only be patched and hardened, but the identified technology platforms should also be reviewed to ensure that evidence of suspicious activity or technology/device modifications have not already occurred.
The following table provides an overview of capabilities to proactively review and identify external-facing assets and resources within common cloud-based infrastructures.
Cloud Provider
Attack Surface Discovery Capability
Google Cloud
Security Command Center
Amazon Web Services
AWS Config / Inspector
Microsoft Azure
Defender External Attack Surface Management (Defender EASM)
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
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.
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.
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 (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.
Use Case
MITRE ID
Description
Brute Force
T1110 – Brute Force
Search for a single user with an excessive number of failed logins from external Internet Protocol (IP) addresses.
This risk can be mitigated by enforcing a strong password, MFA, and lockout policy.
Password Spray
T1110.003 – Password Spray
Search for a high number of accounts with failed logins, typically from the similar origination addresses.
Multiple Failed MFA Same User
T1110 – Brute Force
T1078 – Valid Accounts
Search for multiple failed MFA conditions for the same account. This may be indicative of a previously compromised credential.
Multiple Failed MFA Same Source
T1110.003 – Password Spray
T1078 – Valid Accounts
Search for multiple failed MFA prompts for different users from the same source. This may be indicative of multiple compromised credentials and an attempt to "spray" MFA prompts/tokens for access.
External Authentication from an Account with Elevated Privileges
T1078 – Valid Accounts
Privileged accounts should use internally managed and secured privileged access workstations for access and should not be accessible directly from an external (untrusted) source.
Adversary in the Middle (AiTM) Session Token Theft
T1557 - Adversary in the Middle
Monitor for sign-ins where the authentication method succeeds but the session originates from an IP/ASN inconsistent with the user's prior sessions.
Detect logins from newly registered domains or known reverse-proxy infrastructure (EvilProxy, Tycoon 2FA).
Correlate sign-in logs for "isInteractive: true" sessions with anomalous user-agent strings or geographically impossible travel.
MFA Fatigue / Prompt Bombing
T1621 - MFA Request Generation
Search for accounts receiving more than five MFA push notifications within a 10-minute window without a corresponding successful authentication.
Post-Authentication MFA Device Registration
T1098.005 - Account Manipulation - Device Registration
Monitor audit logs for new MFA device registrations (AuthenticationMethodRegistered) occurring within 60 minutes of a sign-in from a new IP or device. Attackers who steal session tokens via AiTM immediately register their own MFA device for persistent access.
OAuth/Consent Phishing
T1550.001 - Use Alternate Authentication Material
Monitor for OAuth application consent grants with high-privilege scopes (Mail.Read, Files.ReadWrite.All) from unrecognized application IDs.
Table 3: Detection opportunities for external-facing assets and MFA attempts
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.
Figure 1: Command to perform a system state backup
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.
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
