How to Back Up a VMware ESXi Host Configuration?

Most organizations focus on backing up virtual machines and their workloads, but the hypervisor itself is often left unprotected. Many administrators treat ESXi hosts as disposable: if one fails, just reinstall and reconfigure. In practice, manually recreating network settings, storage configurations, security policies, and user permissions can take hours. A configuration backup turns that into a few-minute restore.

This article covers the available methods for backing up and restoring VMware ESXi host configurations, how to automate the process, and the best practices worth following.

Why back up ESXi host configurations?

Reinstalling ESXi from scratch is easy. Rebuilding the configuration is not. A typical host carries dozens of settings that accumulate over time: virtual switches, port groups, storage adapters, multipathing policies, firewall rules, user accounts, SSL certificates, and advanced system settings. In clustered environments with High Availability, losing a node doesn’t affect running workloads, which makes it tempting to skip host-level backups entirely. But when it’s time to bring that node back, every setting needs to be recreated manually, and each step is an opportunity for human error.

Configuration backups solve three problems. They cut recovery time from hours to minutes by restoring a host to its exact previous state. They serve as living documentation of your current setup, which is useful for troubleshooting or replicating settings across multiple hosts. And they give you a safety net before upgrades or major changes: if something goes wrong, you roll back.

What about Host Profiles and Configuration Profiles?

VMware offers cluster-level tools for managing host configurations at scale. It’s worth understanding how they relate to the backup methods covered in this article.

Host Profiles (legacy) were introduced in vSphere 4.

Figure 1: vSphere Host Profiles

They let you extract a configuration template from a reference ESXi host and apply it across a cluster, ensuring uniform network, storage, and security settings. Host Profiles require vCenter and an Enterprise Plus license.

Configuration Profiles are the modern replacement, introduced in vSphere 8.0 and generally available since 8.0 Update 1.

Figure 2: Example of editing settings via vSphere Configuration Profiles

Instead of the old Host Profile interface, Configuration Profiles manage host configuration at the cluster level using a human-readable JSON document backed by a JSON schema. Starting with vSphere 8.0 Update 3, they also support baseline-managed clusters, so converting to image-based lifecycle management is no longer a prerequisite. However, some limitations remain: NSX-enabled clusters and DPU-equipped clusters are not yet supported, and once Configuration Profiles are activated on a cluster, they cannot be deactivated. Like Host Profiles, they require Enterprise Plus licensing.

The key distinction is purpose. Both Host Profiles and Configuration Profiles are fleet standardization tools: they ensure all hosts in a cluster match a desired state and let you remediate drift. The vim-cmd and PowerCLI backup methods covered in this article capture the exact point-in-time state of an individual host for disaster recovery purposes. These approaches are complementary, not interchangeable. Use Configuration Profiles (or Host Profiles in older environments) to keep your cluster consistent, and use configuration backups to protect against host-level failures and to enable fast recovery.

What’s inside the backup bundle?

The backup is a compressed .tgz archive, typically just a few hundred KB to a few MB, containing configuration files from the /etc directory and other critical system settings. This includes network configuration (virtual switches, port groups, VMkernel adapters), storage configuration (iSCSI targets, NFS mounts, multipathing policies), security settings (firewall rules, user accounts, SSL certificates), and advanced system settings. It does not include custom VIBs or third-party drivers, VM data, or VMFS datastore contents. If you rely on custom drivers or VIBs, you’ll need to track and reinstall those separately after a restore.

A note on vCenter-managed configurations

If your hosts are managed through vCenter, be aware that some configuration elements live at the vCenter level rather than on the individual host. Distributed virtual switches, for example, are vCenter objects. Backing up an ESXi host configuration captures the host’s local view (standard switches, VMkernel adapters, local users), but not the distributed switch configuration itself. Make sure your backup strategy accounts for both layers.

Using the ESXi host CLI to perform a backup

The ESXi command-line interface has built-in backup functionality. No additional software is required. The process creates a compressed archive containing all configuration files necessary to restore the host.

First, enable SSH access through the vSphere Client (Host > Actions > Services > Enable Secure Shell) or directly on the host console.

Once connected via SSH, sync the configuration files with persistent storage:

vim-cmd hostsvc/firmware/sync_config

Then run the backup command:

vim-cmd hostsvc/firmware/backup_config

This generates a URL for downloading the configuration bundle. The output looks like:

Bundle can be downloaded at : http://<host>/downloads/configBundle-esxi01.tgz

Open this URL in a browser, or use curl from another system:

curl -k -u root https://<host>/downloads/configBundle-esxi01.tgz -o esxi01-backup.tgz

Store the backup file outside the ESXi host itself, on network storage or a dedicated backup repository.

Automate backups using the host CLI

Manual backups get forgotten. Automating the process ensures consistent protection without relying on anyone’s memory.

The following example stores backups on a local datastore for simplicity. In production, you should copy backups off-host using SCP or a similar mechanism.

1. Create a script file:

vi /vmfs/volumes/datastore1/backup-config.sh

2. Add the following content:

#!/bin/sh

vim-cmd hostsvc/firmware/sync_config

vim-cmd hostsvc/firmware/backup_config

find /scratch/downloads/ -name \*.tgz -exec cp {} \

/vmfs/volumes/datastore1/ESXi_backup/ESXi_config_backup_$(date +'%Y%m%d_%H%M%S').tgz \;

3. Save and exit (:wq), then make the script executable:

chmod +x /vmfs/volumes/datastore1/backup-config.sh

4. Schedule the script using cron. Edit the cron configuration:

vi /var/spool/cron/crontabs/root

5. Add the following line to run the backup daily at 2 AM:

0 2 * * * /vmfs/volumes/datastore1/backup-config.sh

6. Save the changes and restart cron:

kill $(cat /var/run/crond.pid)

crond

7. Cron changes do not survive ESXi reboots. To make them persistent, add the following to /etc/rc.local.d/local.sh (before the exit 0 line):

/bin/echo "0 2 * * * /vmfs/volumes/datastore1/backup-config.sh" >> /var/spool/cron/crontabs/root

/bin/kill $(cat /var/run/crond.pid)

crond

8. Test the script before walking away:

/vmfs/volumes/datastore1/backup-config.sh

Verify that backup files are being created in the expected location and, if you added an SCP step, that the remote copy completed.

Restore a configuration from backup

Restoring requires the host to be in maintenance mode or freshly installed. The restore process overwrites all existing settings with those from the backup file.

Upload the backup bundle to the ESXi host using SCP or place it on an accessible datastore. Then enter maintenance mode (if the host is running):

vim-cmd hostsvc/maintenance_mode_enter

Run the restore:

vim-cmd hostsvc/firmware/restore_config /vmfs/volumes/datastore1/esxi01-backup.tgz

The host reboots automatically once the restore completes. After restart, all configurations from the backup are applied.

Important: The backup must come from the same ESXi version or a compatible build. Restoring from a mismatched version may fail or produce an unstable configuration. With vSphere 9.0 and its more frequent update cadence, matching the exact build number is increasingly important.

Important: Starting with VMware vSphere 7.0 Update 2, if a host uses a TPM for configuration encryption, you cannot restore configuration backups to a different physical host without the recovery key. Plan accordingly and keep your TPM recovery keys accessible.

Using remote CLI tools to perform a backup

Managing backups host-by-host doesn’t scale. Remote CLI tools let you back up multiple ESXi hosts from a single workstation.

Two options are available: vSphere CLI (vCLI), a Perl-based toolkit for Linux, and PowerCLI, a PowerShell-based toolkit primarily for Windows (also available on Linux/macOS). Both provide equivalent backup and restore functionality. Choose based on your OS and scripting preferences.

Back up using vSphere CLI

With the vCLI package installed on a Linux system, use vicfg-cfgbackup:

vicfg-cfgbackup --server esxi01.example.com --username root \

--password 'yourpassword' --backup --output /backups/esxi01-config.tgz

Note: If vicfg commands are unavailable in your version, consult the ESXCLI reference for alternative methods.

Back up using PowerCLI

PowerCLI uses the Get-VMHostFirmware cmdlet. Connect to the host or vCenter Server first:

Connect-VIServer -Server esxi01.example.com -User root -Password 'yourpassword'

Get-VMHostFirmware -VMHost esxi01.example.com -BackupConfiguration -DestinationPath C:\Backups\

For environments with multiple hosts, loop through all of them:

Connect-VIServer -Server vcenter.example.com

Get-VMHost | ForEach-Object {

Get-VMHostFirmware -VMHost $_ -BackupConfiguration -DestinationPath "C:\Backups\$($_.Name)\"

}

Automate remote backups

When automating remote backups, follow these practices:

• For vSphere CLI, use credential stores or session files instead of hardcoding passwords in scripts.
• For PowerCLI, use New-VICredentialStoreItem or secure strings to avoid plaintext credentials.
• Make sure scripts are executable and schedule them using cron (Linux) or Task Scheduler (Windows).
• If running PowerShell scripts on Windows, you may need the -ExecutionPolicy Bypass flag.

Restore using remote CLI

The target ESXi host must be in maintenance mode or freshly installed.

Using vSphere CLI:

vicfg-cfgbackup --server esxi01.example.com --username root \

--password 'yourpassword' --restore --input /backups/esxi01-config.tgz

Using PowerCLI:

Connect-VIServer -Server esxi01.example.com -User root -Password 'yourpassword'

Set-VMHost -VMHost esxi01.example.com -State Maintenance

Set-VMHostFirmware -VMHost esxi01.example.com -Restore `

-SourcePath "C:\Backups\esxi01-20240115.tgz" -HostUser root -HostPassword 'yourpassword'

The host reboots automatically after the restore completes.

Best practices for ESXi host configuration backups

Back up regularly. At minimum, create configuration backups weekly. In dynamic environments, increase the frequency to daily or after every significant change. Automated, scheduled backups prevent the common scenario where administrators forget to back up before making critical changes.

• Store backups off-host.

Never keep backups solely on the ESXi host or on datastores that depend on it. Use network storage, a dedicated backup repository, or cloud storage. Follow the 3-2-1 rule: three copies, two different media types, one copy off-site.

• Implement a retention policy.

A common approach: retain daily backups for one week, weekly backups for one month, and monthly backups for one year. This gives you granular recovery options for recent changes while preserving long-term history.

• Use clear naming conventions.

Include the hostname, date, and ESXi version in backup filenames. For example: esxi01-v7.0U3-20240115.tgz. This makes it easy to find the right backup during a recovery.

• Test restores regularly.

A backup you’ve never restored from is a backup you can’t trust. Periodically test restores in a lab environment to verify integrity and to keep administrators familiar with the procedure. This also validates compatibility after ESXi version updates.

• Document your procedures.

Write down the specific commands, file locations, credential storage locations, and step-by-step restoration instructions. During a disaster recovery scenario, no one wants to be piecing together syntax from memory.

• Secure your backup files.

Configuration backups contain sensitive data: passwords, certificates, and network topology details. Restrict access to backup repositories and consider encrypting backups at rest and in transit.

• Plan for common failures.

Know what to do if the backup command produces no output, if the .tgz file is corrupt, or if a restore fails midway through. Having a fallback plan (even if it’s “reinstall and reconfigure manually”) documented in advance saves time during an incident.

Conclusion

ESXi host configuration backups turn a multi-hour rebuild into a quick restore. The methods available (host CLI, vSphere CLI, PowerCLI) all work well. The important thing is picking one, automating it, and testing your restores. A few minutes of setup now saves hours of recovery time later.

from StarWind Blog https://ift.tt/YaikDTJ
via IFTTT

From Access to Execution: Securing Identity in the Age of Autonomous Agents

The definition of identity is expanding. Employees are no longer the only actors – or ‘workers’ – inside enterprise environments. Service accounts, APIs, workload identities, and increasingly autonomous AI agents are now executing actions on behalf of humans and systems at machine speed and scale. This is the next generation of identity and its risks.

At SentinelOne®, we believe identity security must evolve to meet this reality by going beyond static gatekeeping. It must validate behavioral intent, ensuring protection is a continuous evaluation of what happens after access is granted.

The Authorization Gap

Many security frameworks focus heavily on the moment of authentication. The focus has long been on stronger gates: we see this in the push towards tighter governance and more granular permission models – these controls are fundamental. But authentication alone does not validate intent, and authorized access does not guarantee safe behavior.

A user can be fully authenticated and still perform reconnaissance, exfiltrate data via a browser, or feed proprietary code into a GenAI tool. A service account or AI agent can be correctly provisioned and still be used for lateral movement. Once access is granted, traditional identity controls assume legitimacy, and that assumption creates an authorization gap: a blind spot between who is allowed in and what they actually do once inside.

As the industry explores centralized broker models for agents and non-human identities, one principle remains constant: authorization alone is not sufficient. Access must be continuously validated and, when necessary, withdrawn at runtime. SentinelOne’s execution-first architecture is designed to ensure that even approved actions remain bounded by real-time behavioral guardrails within the execution layer, where intent turns into observable technical behavior. Our approach is an end-to-end execution defense that spans endpoints, browsers, and AI workflows to stop misuse as it happens. This creates a security model that ensures defense is defined by session behavior, not simply initiation.

The New Execution Surface

In the modern enterprise, the browser has become one of the most important operating environments. It’s where SaaS applications run and where cloud infrastructure is managed. At the same time, it’s operating alongside rich endpoint software, including local AI workloads and integrated development environments (IDEs) – all contributing to a complex digital footprint. Consequently, it’s also where identity risk increasingly manifests. Browsers now represent sophisticated execution surfaces where users (and attackers) interact with company secrets and sensitive intellectual property. Misuse shows up in interaction patterns, prompt content, and data movement across tools.

SentinelOne secures this surface through recently acquired Prompt Security, monitoring the execution signals that define modern work. This approach avoids the friction of specialized enterprise browsers or the instability of JavaScript virtualization, both of which can increase operational complexity and expand the attack surface. By delivering native inspection within the browsers enterprises already use, we enable security that is seamless, flexible and unobtrusive, allowing organizations to protect AI-driven workflows without disrupting user choice or productivity.

And because Prompt is deeply integrated within the Singularity Platform, browser and AI execution is correlated with identity context and endpoint telemetry. This unified view reveals how an identity is interacting with AI tools and web applications. When activity begins to drift into malicious behavior, the platform identifies the shift and autonomously mitigates risk in real time.

Identity Beyond Humans: Securing Non-Human Execution

Identity today extends far beyond employees – non-human identities (NHIs) are now one of the fastest growing and most critical areas in identity security. Service accounts, APIs, workload identities, and increasingly autonomous AI agents are executing actions across cloud, SaaS, and AI environments. These NHIs often operate with persistent privileges, broad access, and limited visibility. As organizations automate more workflows and adopt agentic AI systems, NHIs represent one of the fastest growing and least understood attack surfaces.

Traditional identity solutions were built around human users and their authentication lifecycles. That model does not translate cleanly to machine identities – NHIs are ephemeral, programmatic, and operate at a scale that far exceeds human activity. Superimposing human-oriented controls onto an ever expanding population service accounts and AI agents is neither scalable nor sufficient. Securing NHIs requires a different paradigm defined by a fundamental shift from authorization to behavioral validation.

SentinelOne is already protecting non-human identities through that lens. Within Singularity Identity, we provide a first-class inventory of service accounts and workload identities, applying identity security policies, detections, and posture checks purpose-built for non-human misconfigurations and misuse. On the AI front, Prompt Security extends visibility into emerging agentic AI activity and MCP monitoring. Through our agentic AI discovery capabilities – now in beta – organizations can identify autonomous AI identities interacting with enterprise systems, bringing clarity to a rapidly expanding class of machine actors.

These capabilities reflect a broader execution-first principle: non-human identities should be evaluated not only by what permissions they hold, but by how they behave over time. As automation accelerates, cohesion across human and non-human identity controls becomes essential. Aligning inventory and detection & response into a unified NHI control model is a natural next step in extending execution-based security across all identities operating in the enterprise.

Meet the New Singularity Identity: Simplified, Unified, Powerful

To support this evolution toward execution-based security, we are introducing the next chapter of our identity portfolio with the general availability of three critical capabilities across our unified identity protection experience, which spans on-premises and cloud identity providers:

• Policy-based Conditional Access: We are moving beyond static rules. This provides the granular, real-time control necessary to ensure that access is a living evaluation based on defined conditions across human and non-human identities.
• Compromised Credential Protection: We are stopping attacks before they even hit the front door by proactively identifying and neutralizing credentials that have been exposed in the wild.
• A Unified Approach to Identity Protection: This evolution is mirrored in our new streamlined portfolio. We have consolidated all of our identity capabilities into a single, unified solution: Singularity Identity. By bringing our identity innovations together into one comprehensive layer of the Singularity Platform, we have made it simpler for organizations to deploy the high-fidelity behavioral signals and autonomous containment required for modern defense – and to validate identities, not just authorize them.

But this launch represents more than a packaging update. It reflects a broader strategy that extends beyond traditional identity boundaries across the Singularity Platform. Prompt Security empowers visibility into browser activity, SaaS interaction patterns, and emerging agentic AI identities. This ensures that identity context is not confined to authentication events or directory objects, but enriched by real execution signals across AI and web workflows.

One Platform, One Continuous Execution Fabric

Modern attacks unfold across identities, browsers, endpoints, AI tools, and automated workloads. Securing authorized paths requires continuous validation across all of them.

As agentic AI proliferates, non-human identities now vastly outnumber human users. Every AI agent requires credentials, permissions, and governance. Traditional identity platforms were designed for human users and static service accounts, not autonomous agents executing and disappearing in milliseconds.

While human identity requires continuous verification of who is acting, non-human identity requires continuous verification of intent – whether a service account or AI agent is performing the actions it is supposed to, based on expected behavior patterns. Authorization alone cannot provide that validation, as a compromised non-human identity may still hold valid credentials and appear authorized, yet its behavior can deviate from its intended purpose. This creates the gap between access and safe execution. In practice, the framework splits: human identity is continuously verified for authenticity, non-human identity is continuously validated for intent, and both feed attribution and accountability across the enterprise.

SentinelOne’s architecture is built for this evolution. Grounded in execution, SentinelOne delivers end-to-end visibility and response across both human and non-human activity:

• Singularity Identity provides critical context for who or what is acting
• Prompt Security surfaces misuse within the browser and AI tools
• Singularity Endpoint validates behavior at the system level

Together, these capabilities form a continuous execution fabric, correlating activity across human and non-human identities, applications, and devices. SentinelOne is the only major platform delivering immediate, complete GenAI visibility and data protection at the point of every employee interaction on every managed device – all deployable without SASE rearchitecture or API-level code changes.

In an era where sophisticated threats are hiding behind legitimate access and automation is accelerating machine-driven activity, enterprise resilience depends on securing execution itself – at machine speed. SentinelOne is transforming identity from a static gate into a continuous engine of behavioral validation – securing the integrity of every action taken within the modern enterprise, whether initiated by a person, a service account, or an AI agent.

Ready to explore the new features?

Take the next step in securing your execution layer. See Singularity Identity in action against real-world attack scenarios. Contact us or request a demo to get started.

Existing identity customers can talk to their account manager for more information about the new Singularity Identity and its expanded capabilities.

from SentinelOne https://ift.tt/VLUSGrc
via IFTTT

Exposing the Undercurrent: Disrupting the GRIDTIDE Global Cyber Espionage Campaign

Introduction

Last week, Google Threat Intelligence Group (GTIG), Mandiant, and partners took action to disrupt a global espionage campaign targeting telecommunications and government organizations in dozens of nations across four continents. The threat actor, UNC2814, is a suspected People's Republic of China (PRC)-nexus cyber espionage group that GTIG has tracked since 2017. This prolific, elusive actor has a long history of targeting international governments and global telecommunications organizations across Africa, Asia, and the Americas and had confirmed intrusions in 42 countries when the disruption was executed. The attacker was using API calls to communicate with SaaS apps as command-and-control (C2) infrastructure to disguise their malicious traffic as benign, a common tactic used by threat actors when attempting to improve the stealth of their intrusions. Rather than abusing a weakness or security flaw, attackers rely on cloud-hosted products to function correctly and make their malicious traffic seem legitimate. This disruption, led by GTIG in partnership with other teams, included the following actions: 

• Terminating all Google Cloud Projects controlled by the attacker, effectively severing their persistent access to environments compromised by the novel GRIDTIDE backdoor.

• Identifying and disabling all known UNC2814 infrastructure. 

• Disabling attacker accounts and revoked access to the Google Sheets API calls leveraged by the actor for command-and-control (C2) purposes.

• Releasing a set of IOCs linked to UNC2814 infrastructure active since at least 2023. 

GTIG’s understanding of this campaign was accelerated by a recent Mandiant Threat Defense investigation into UNC2814 activity. Mandiant discovered that UNC2814 was leveraging a novel backdoor tracked as GRIDTIDE. This activity is not the result of a security vulnerability in Google’s products; rather, it abuses legitimate Google Sheets API functionality to disguise C2 traffic.

As of Feb. 18, GTIG's investigation confirmed that UNC2814 has impacted 53 victims in 42 countries across four continents, and identified suspected infections in at least 20 more countries. It is important to highlight that UNC2814 has no observed overlaps with activity publicly reported as “Salt Typhoon,” and targets different victims globally using distinct tactics, techniques, and procedures (TTPs). Although the specific initial access vector for this campaign has not been determined, UNC2814 has a history of gaining entry by exploiting and compromising web servers and edge systems.

Figure 1:GRIDTIDE infection lifecycle

Initial Detection

Mandiant leverages Google Security Operations (SecOps) to perform continuous detection, investigation, and response across our global customer base. During this investigation, a detection flagged suspicious activity on a CentOS server.

In this case, Mandiant’s investigation revealed a suspicious process tree: the binary /var/tmp/xapt initiated a shell with root privileges. The binary then executed the command sh -c id 2>&1 to retrieve the system's user and group identifiers. This reconnaissance technique enabled the threat actor to confirm their successful privilege escalation to root. Mandiant analysts triaged the alert, confirmed the malicious intent, and reported the activity to the customer. This rapid identification of a sophisticated threat actor’s TTPs demonstrates the value of Google Cloud’s Shared Fate model, which provides organizations with curated, out-of-the-box (OOB) detection content designed to help organizations better defend against modern intrusions.

[Process Tree]
/var/tmp/xapt
 └── /bin/sh
      └── sh -c id 2>&1
           └── [Output] uid=0(root) gid=0(root) groups=0(root)

The payload was likely named xapt to masquerade as the legacy tool used in Debian-based systems.

Post-Compromise Activity

The threat actor used a service account to move laterally within the environment via SSH. Leveraging living-off-the-land (LotL)binaries, the threat actor performed reconnaissance activities, escalated privileges, and set up persistence for the GRIDTIDE backdoor.

To achieve persistence, the threat actor created a service for the malware at /etc/systemd/system/xapt.service, and once enabled, a new instance of the malware was spawned from /usr/sbin/xapt.

The threat actor initially executed GRIDTIDE via the command nohup ./xapt. This allows the backdoor to continue running even after the session is closed.

Subsequently, SoftEther VPN Bridge was deployed to establish an outbound encrypted connection to an external IP address. VPN configuration metadata suggests UNC2814 has been leveraging this specific infrastructure since July 2018.

The threat actor dropped GRIDTIDE on to an endpoint containing personally identifiable information (PII), including:

• Full name

• Phone number

• Date of birth

• Place of birth

• Voter ID number

• National ID number

We assess the targeting of PII in this engagement is consistent with cyber espionage activity in telecommunications, which is primarily leveraged to identify, track, and monitor persons of interest. We expect UNC2814 used this access to exfiltrate a variety of data on persons and their communications. Similar campaigns have been used to exfiltrate call data records, monitor SMS messages, and to even monitor targeted individuals through the telco’s lawful intercept capabilities.

GTIG did not directly observe UNC2814 exfiltrate sensitive data during this campaign. However, historical PRC-nexus espionage intrusions against telecoms have resulted in the theft of call data records, unencrypted SMS messages, and the compromise and abuse of lawful intercept systems. This focus on sensitive communications historically is intended to enable the targeting of individuals and organizations for surveillance efforts, particularly dissidents and activists, as well as traditional espionage targets. The access UNC2814 achieved during this campaign would likely enable clandestine efforts to similarly surveil targets. 

GRIDTIDE

GRIDTIDE is a sophisticated C-based backdoor with the ability to execute arbitrary shell commands, upload files, and download files. The backdoor leverages Google Sheets as a high-availability C2 platform, treating the spreadsheet not as a document, but as a communication channel to facilitate the transfer of raw data and shell commands. GRIDTIDE hides its malicious traffic within legitimate cloud API requests, evading standard network detection. While the GRIDTIDE sample FLARE analyzed as part of this campaign leverages Google Sheets for its C2, the actor could easily make use of other cloud-based spreadsheet platforms in the same manner.

Google Sheets

GRIDTIDE expects a 16-byte cryptographic key to be present in a separate file on the host at the time of execution. The malware uses this key to decrypt its Google Drive configurations using AES-128 in Cipher Block Chaining (CBC) mode.

The Google Drive configuration data contains the service account associated with UNC2814’s Google Sheets document, and a private key for the account. It also contains the Google Spreadsheet ID and the private key to access the document. GRIDTIDE then connects to the malicious Google Spreadsheet using the Google Service Account for API authentication (the threat actor’s Google Service Account and associated Google Workspace have been disabled).

When executed, GRIDTIDE sanitizes its Google Sheet. It does this by deleting the first 1000 rows, across columns A to Z in the spreadsheet, by using the Google Sheets API batchClear method. This prevents previous commands or file data stored in the Sheet from interfering with the threat actor’s current session.

Once the Sheet is prepared, the backdoor conducts host-based reconnaissance. It fingerprints the endpoint by collecting the victim’s username, endpoint name, OS details, local IP address, and environmental data such as the current working directory, language settings, and local time zone. This information is then exfiltrated and stored in cell V1 of the attacker-controlled spreadsheet.

Command Syntax

The threat actor issues instructions using a four-part command syntax: <type>-<command_id>-<arg_1>-<arg_2>.

• <type> Commands originating from the threat actor are categorized as type C (Client).

• <command_id>

• C (Command): Executes Base64-encoded Bash shell commands on the endpoint and redirects the output to the spreadsheet.

• U (Upload): Upload the data stored in the cells A2:A<arg_2> to the target endpoint, reconstruct and write to the encoded file path <arg_1>.

• D (Download): Reads the data from the encoded local file path on the endpoint <arg_1> and transfers the contents in 45-KB fragments to the spreadsheet across the A2:An range.

In response, the malware posts a Server (S) status message to cell A1, confirming the successful completion of the task (R) or returning an error:

• <type> Responses originating from the malware are categorised as type S (Server).

• <command_id> Will match the <command_id> value sent by the threat actor.

• <arg_1> Indicating the command executed successfully (R), or an error message.

• <arg_2> Exfiltrated data is saved within the range A2:A<arg_2>. This value displays the upper cell number of the data.

Cell-Based C2

GRIDTIDE’s C2 communication works on a cell-based polling mechanism, assigning specific roles to spreadsheet cells to facilitate communication.

• A1: The malware polls this cell via the Google Sheets API for attacker commands, and subsequently overwrites it with a status response upon completion (e.g., S-C-R or Server-Command-Success. If no command exists in the cell, the malware sleeps for one second before trying again. If the number of trials reaches 120, it changes the sleep time to be a random duration between 5–10 minutes, likely to reduce noise when the threat actor is not active. When a command does exist in the cell, GRIDTIDE executes it and resets the wait time to one second.

• A2-An: Used for the transfer of data, such as command output, uploading tools, or exfiltrating files.

• V1: Stores system data from the victim endpoint. When executed, the malware updates this cell with an encoded string containing host-based metadata.

Obfuscation and Evasion

To evade detection and web filtering, GRIDTIDE employs a URL-safe Base64 encoding scheme for all data sent and received. This encoding variant replaces standard Base64 characters (+ and /) with alternatives (- and _).

Command Execution Lifecycle

Figure 2: GRIDTIDE execution lifecycle

Targeting

Figure 3: Countries with suspected or confirmed UNC2814 victims

UNC2814 is a suspected PRC-nexus threat actor that has conducted global operations since at least 2017. The group's recent activity leveraging GRIDTIDE malware has primarily focused on targeting telecommunications providers on a worldwide scale, but UNC2814 also targeted government organizations during this campaign. 

GTIG confirmed 53 intrusions by UNC2814 in 42 total nations globally, and identified suspected targeting in at least 20 other nations. This prolific scope is likely the result of a decade of concentrated effort.

Disrupting UNC2814

GTIG is committed to actively countering and disrupting malicious operations, ensuring the safety of our customers and mitigating the global impact of this malicious cyber activity. 

To counter UNC2814’s operations, GTIG executed a series of coordinated disruption actions:

• Elimination of GRIDTIDE Access: We terminated all Cloud Projects controlled by the attacker, effectively severing their persistent access to environments compromised by the GRIDTIDE backdoor.

• Infrastructure Takedown: In collaboration with partners, we identified and disabled all known UNC2814 infrastructure. This included the sinkholing of both current and historical domains used by the group in order to further dismantle UNC2814’s access to compromised environments.

• Account Disruption: GTIG and its partners disabled attacker accounts, revoked access to the Google Sheets, and disabled all Google Cloud projects leveraged by the actor for command-and-control (C2) purposes.

• Victim Notifications: GTIG has issued formal victim notifications and is actively supporting organizations with verified compromises resulting from this threat.

• Detection Signatures: We have refined and implemented a variety of signatures and signals designed to neutralize UNC2814 operations and intercept malware linked to GRIDTIDE.

• IOC Release: We are publicly releasing a collection of IOC’s related to UNC2814 infrastructure that the group has used since at least 2023 to help organizations identify this activity in their networks and better protect customers and organizations around the world.

Conclusion

The global scope of UNC2814’s activity, evidenced by confirmed or suspected operations in over 70 countries, underscores the serious threat facing telecommunications and government sectors, and the capacity for these intrusions to evade detection by defenders. Prolific intrusions of this scale are generally the result of years of focused effort and will not be easily re-established. We expect that UNC2814 will work hard to re-establish their global footprint.

Detection Through Google Security Operations

Google SecOps customers have access to these broad category rules and more under the Mandiant Hunting rule pack. The activity discussed in the blog post is detected in Google SecOps under the rule names:

• Suspicious Shell Execution From Var Directory

• Suspicious Sensitive File Access Via SSH

• Config File Staging in Sensitive Directories

• Shell Spawning Curl Archive Downloads from IP

• Numeric Permission Profiling in System Paths

• Sudo Shell Spawning Reconnaissance Tools

• Potential Google Sheets API Data Exfiltration

SecOps Hunting Queries

The following UDM queries can be used to identify potential compromises within your environment.

Suspicious Google Sheets API Connections

Search for a non-browser process initiating outbound HTTPS requests to specific Google Sheets URIs leveraged by GRIDTIDE.

target.url = /sheets\.googleapis\.com/
(
  target.url = /batchClear/ OR 
  target.url = /batchUpdate/ OR
  target.url = /valueRenderOption=FORMULA/
)
principal.process.file.full_path != /chrome|firefox|safari|msedge/

Config File Creation in Suspicious Directory

Identify configuration files being created at, modified, or moved to unexpected locations.

(
  metadata.event_type = "FILE_CREATION" OR
  metadata.event_type = "FILE_MODIFICATION" OR
  metadata.event_type = "FILE_MOVE"
)
AND target.file.full_path = /^(\/usr\/sbin|\/sbin|\/var\/tmp)\/[^\\\/]+\.cfg$/ nocase

Suspicious Shell Execution from /var/tmp/

Detects executables with short alphanumeric filenames, launching from the /var/tmp/ directory, and spawning a shell.

principal.process.file.full_path = /^\/var\/tmp\/[a-z0-9]{1,10}$/ nocase AND
target.process.file.full_path = /\b(ba)?sh$/ nocase

Indicators of Compromise (IOCs)

The following IOCs are available in a free Google Threat Intelligence (GTI) collection for registered users.

Host-Based Artifacts

Artifact	Description	Hash (SHA256)
xapt	GRIDTIDE	ce36a5fc44cbd7de947130b67be9e732a7b4086fb1df98a5afd724087c973b47
xapt.cfg	Key file used by GRIDTIDE to decrypt its Google Drive configuration.	01fc3bd5a78cd59255a867ffb3dfdd6e0b7713ee90098ea96cc01c640c6495eb
xapt.service	Malicious systemd service file created for GRIDTIDE persistence.	eb08c840f4c95e2fa5eff05e5f922f86c766f5368a63476f046b2b9dbffc2033
hamcore.se2	SoftEtherVPN Bridge component.	4eb994b816a1a24cf97bfd7551d00fe14b810859170dbf15180d39e05cd7c0f9
fire	SoftEtherVPN Bridge component (renamed from vmlog). Extracted from update.tar.gz.	4eb994b816a1a24cf97bfd7551d00fe14b810859170dbf15180d39e05cd7c0f9
vpn_bridge.config	SoftEtherVPN Bridge configuration.	669917bad46a57e5f2de037f8ec200a44fb579d723af3e2f1be1e8479a267966
apt.tar.gz	Archive downloaded from 130.94.6[.]228. Contained GRIDTIDE.	N/A
update.tar.gz	Additional archive downloaded. Contained vmlog (renamed to fire), a SoftEtherVPN Bridge component.	N/A
amp.tar.gz	Additional archive downloaded. Contained hamcore.se2, a SoftEtherVPN Bridge component.	N/A
pmp	GRIDTIDE variant.	N/A
pmp.cfg	GRIDTIDE variant key file.	N/A

Network-Based Artifacts

Type	Description	Artifact
IP	C2 server hosting apt.tar.gz, update.tar.gz, and amp.tar.gz.	130[.]94[.]6[.]228
IP	Target of a curl -ik command to verify HTTPS access to their infrastructure.	38[.]180[.]205[.]14
IP	Threat actor’s SoftEtherVPN server.	38[.]60[.]194[.]21
IP	Attacker IP	38[.]54[.]112[.]184
IP	Attacker IP	38[.]60[.]171[.]242
IP	Attacker IP	195[.]123[.]211[.]70
IP	Attacker IP	202[.]59[.]10[.]122
IP	Hosting malicious C2 domain.	38[.]60[.]252[.]66
IP	Hosting malicious C2 domain.	45[.]76[.]184[.]214
IP	Hosting malicious C2 domain.	45[.]90[.]59[.]129
IP	Hosting malicious C2 domain.	195[.]123[.]226[.]235
IP	Hosting malicious C2 domain.	65[.]20[.]104[.]91
IP	Hosting malicious C2 domain.	5[.]34[.]176[.]6
IP	Hosting malicious C2 domain.	139[.]84[.]236[.]237
IP	Hosting malicious C2 domain.	149[.]28[.]128[.]128
IP	Hosting malicious C2 domain.	38[.]54[.]31[.]146
IP	Hosting malicious C2 domain.	178[.]79[.]188[.]181
IP	Hosting malicious C2 domain.	38[.]54[.]37[.]196
IP	SoftEtherVPN server.	207[.]148[.]73[.]18
IP	SoftEtherVPN server.	38[.]60[.]224[.]25
IP	SoftEtherVPN server.	149[.]28[.]139[.]125
IP	SoftEtherVPN server.	38[.]54[.]32[.]244
IP	SoftEtherVPN server.	38[.]54[.]82[.]69
IP	SoftEtherVPN server.	45[.]76[.]157[.]113
IP	SoftEtherVPN server.	45[.]77[.]254[.]168
IP	SoftEtherVPN server.	139[.]180[.]219[.]115
User-Agent	GRIDTIDE User-Agent string.	Directory API Google-API-Java-Client/2.0.0 Google-HTTP-Java-Client/1.42.3 (gzip)
User-Agent	GRIDTIDE User-Agent string.	Google-HTTP-Java-Client/1.42.3 (gzip)
Domain	C2 domain	1cv2f3d5s6a9w[.]ddnsfree[.]com
Domain	C2 domain	admina[.]freeddns[.]org
Domain	C2 domain	afsaces[.]accesscam[.]org
Domain	C2 domain	ancisesic[.]accesscam[.]org
Domain	C2 domain	applebox[.]camdvr[.]org
Domain	C2 domain	appler[.]kozow[.]com
Domain	C2 domain	asdad21ww[.]freeddns[.]org
Domain	C2 domain	aw2o25forsbc[.]camdvr[.]org
Domain	C2 domain	awcc001jdaigfwdagdcew[.]giize[.]com
Domain	C2 domain	bab2o25com[.]accesscam[.]org
Domain	C2 domain	babaji[.]accesscam[.]org
Domain	C2 domain	babi5599ss[.]ddnsgeek[.]com
Domain	C2 domain	balabalabo[.]mywire[.]org
Domain	C2 domain	bggs[.]giize[.]com
Domain	C2 domain	bibabo[.]freeddns[.]org
Domain	C2 domain	binmol[.]webredirect[.]org
Domain	C2 domain	bioth[.]giize[.]com
Domain	C2 domain	Boemobww[.]ddnsfree[.]com
Domain	C2 domain	brcallletme[.]theworkpc[.]com
Domain	C2 domain	btbtutil[.]theworkpc[.]com
Domain	C2 domain	btltan[.]ooguy[.]com
Domain	C2 domain	camcampkes[.]ddnsfree[.]com
Domain	C2 domain	camsqewivo[.]kozow[.]com
Domain	C2 domain	ccammutom[.]ddnsgeek[.]com
Domain	C2 domain	cdnvmtools[.]theworkpc[.]com
Domain	C2 domain	cloacpae[.]ddnsfree[.]com
Domain	C2 domain	cmwwoods1[.]theworkpc[.]com
Domain	C2 domain	cnrpaslceas[.]freeddns[.]org
Domain	C2 domain	codemicros12[.]gleeze[.]com
Domain	C2 domain	cressmiss[.]ooguy[.]com
Domain	C2 domain	cvabiasbae[.]ddnsfree[.]com
Domain	C2 domain	cvnoc01da1cjmnftsd[.]accesscam[.]org
Domain	C2 domain	cvpc01aenusocirem[.]accesscam[.]org
Domain	C2 domain	cvpc01cgsdfn53hgd[.]giize[.]com
Domain	C2 domain	DCLCWPDTSDCC[.]ddnsfree[.]com
Domain	C2 domain	dlpossie[.]ddnsfree[.]com
Domain	C2 domain	dnsfreedb[.]ddnsfree[.]com
Domain	C2 domain	doboudix1024[.]mywire[.]org
Domain	C2 domain	evilginx2[.]loseyourip[.]com
Domain	C2 domain	examp1e[.]webredirect[.]org
Domain	C2 domain	faeelt[.]giize[.]com
Domain	C2 domain	fakjcsaeyhs[.]ddnsfree[.]com
Domain	C2 domain	fasceadvcva3[.]gleeze[.]com
Domain	C2 domain	ffosies2024[.]camdvr[.]org
Domain	C2 domain	fgdedd1dww[.]gleeze[.]com
Domain	C2 domain	filipinet[.]ddnsgeek[.]com
Domain	C2 domain	freeios[.]theworkpc[.]com
Domain	C2 domain	ftpuser14[.]gleeze[.]com
Domain	C2 domain	ftpzpak[.]kozow[.]com
Domain	C2 domain	globoss[.]kozow[.]com
Domain	C2 domain	gogo2025up[.]ddnsfree[.]com
Domain	C2 domain	googlel[.]gleeze[.]com
Domain	C2 domain	googles[.]accesscam[.]org
Domain	C2 domain	googles[.]ddnsfree[.]com
Domain	C2 domain	googlett[.]camdvr[.]org
Domain	C2 domain	googllabwws[.]gleeze[.]com
Domain	C2 domain	gtaldps31c[.]ddnsfree[.]com
Domain	C2 domain	hamkorg[.]kozow[.]com
Domain	C2 domain	honidoo[.]loseyourip[.]com
Domain	C2 domain	huygdr12[.]loseyourip[.]com
Domain	C2 domain	icekancusjhea[.]ddnsgeek[.]com
Domain	C2 domain	idstandsuui[.]kozow[.]com
Domain	C2 domain	indoodchat[.]theworkpc[.]com
Domain	C2 domain	jarvis001[.]freeddns[.]org
Domain	C2 domain	Kaushalya[.]freeddns[.]org
Domain	C2 domain	khyes001ndfpnuewdm[.]kozow[.]com
Domain	C2 domain	kskxoscieontrolanel[.]gleeze[.]com
Domain	C2 domain	ksv01sokudwongsj[.]theworkpc[.]com
Domain	C2 domain	lcskiecjj[.]loseyourip[.]com
Domain	C2 domain	lcskiecs[.]ddnsfree[.]com
Domain	C2 domain	losiesca[.]ddnsgeek[.]com
Domain	C2 domain	lps2staging[.]ddnsfree[.]com
Domain	C2 domain	lsls[.]casacam[.]net
Domain	C2 domain	ltiuys[.]ddnsgeek[.]com
Domain	C2 domain	ltiuys[.]kozow[.]com
Domain	C2 domain	mailsdy[.]gleeze[.]com
Domain	C2 domain	maliclick1[.]ddnsfree[.]com
Domain	C2 domain	mauritasszddb[.]ddnsfree[.]com
Domain	C2 domain	meetls[.]kozow[.]com
Domain	C2 domain	Microsoft[.]bumbleshrimp[.]com
Domain	C2 domain	ml3[.]freeddns[.]org
Domain	C2 domain	mlksucnayesk[.]kozow[.]com
Domain	C2 domain	mmmfaco2025[.]mywire[.]org
Domain	C2 domain	mms[.]bumbleshrimp[.]com
Domain	C2 domain	mmvmtools[.]giize[.]com
Domain	C2 domain	modgood[.]gleeze[.]com
Domain	C2 domain	Mosplosaq[.]accesscam[.]org
Domain	C2 domain	mysql[.]casacam[.]net
Domain	C2 domain	nenigncagvawr[.]giize[.]com
Domain	C2 domain	nenignenigoncqvoo[.]ooguy[.]com
Domain	C2 domain	nenigoncqnutgo[.]accesscam[.]org
Domain	C2 domain	nenigoncuopzc[.]giize[.]com
Domain	C2 domain	nims[.]gleeze[.]com
Domain	C2 domain	nisaldwoa[.]theworkpc[.]com
Domain	C2 domain	nmszablogs[.]ddnsfree[.]com
Domain	C2 domain	nodekeny11[.]freeddns[.]org
Domain	C2 domain	nodjs2o25nodjs[.]giize[.]com
Domain	C2 domain	Npeoples[.]theworkpc[.]com
Domain	C2 domain	officeshan[.]kozow[.]com
Domain	C2 domain	okkstt[.]ddnsgeek[.]com
Domain	C2 domain	oldatain1[.]ddnsgeek[.]com
Domain	C2 domain	onlyosun[.]ooguy[.]com
Domain	C2 domain	osix[.]ddnsgeek[.]com
Domain	C2 domain	ovmmiuy[.]mywire[.]org
Domain	C2 domain	palamolscueajfvc[.]gleeze[.]com
Domain	C2 domain	pawanp[.]kozow[.]com
Domain	C2 domain	pcmainecia[.]ddnsfree[.]com
Domain	C2 domain	pcvmts3[.]kozow[.]com
Domain	C2 domain	peisuesacae[.]loseyourip[.]com
Domain	C2 domain	peowork[.]ddnsgeek[.]com
Domain	C2 domain	pepesetup[.]ddnsfree[.]com
Domain	C2 domain	pewsus[.]freeddns[.]org
Domain	C2 domain	plcoaweniva[.]ddnsgeek[.]com
Domain	C2 domain	PolicyAgent[.]theworkpc[.]com
Domain	C2 domain	polokinyea[.]gleeze[.]com
Domain	C2 domain	pplodsssead222[.]loseyourip[.]com
Domain	C2 domain	pplosad231[.]kozow[.]com
Domain	C2 domain	ppsaBedon[.]gleeze[.]com
Domain	C2 domain	prdanjana01[.]ddnsfree[.]com
Domain	C2 domain	prepaid127[.]freeddns[.]org
Domain	C2 domain	PRIFTP[.]kozow[.]com
Domain	C2 domain	prihxlcs[.]ddnsfree[.]com
Domain	C2 domain	prihxlcsw[.]theworkpc[.]com
Domain	C2 domain	pxlaxvvva[.]freeddns[.]org
Domain	C2 domain	quitgod2023luck[.]giize[.]com
Domain	C2 domain	rabbit[.]ooguy[.]com
Domain	C2 domain	rsm323[.]kozow[.]com
Domain	C2 domain	saf3asg[.]giize[.]com
Domain	C2 domain	Scopps[.]ddnsgeek[.]com
Domain	C2 domain	sdhite43[.]ddnsfree[.]com
Domain	C2 domain	sdsuytoins63[.]kozow[.]com
Domain	C2 domain	selfad[.]gleeze[.]com
Domain	C2 domain	serious[.]kozow[.]com
Domain	C2 domain	setupcodpr2[.]freeddns[.]org
Domain	C2 domain	sgsn[.]accesscam[.]org
Domain	C2 domain	Smartfren[.]giize[.]com
Domain	C2 domain	sn0son4t31bbsvopou[.]camdvr[.]org
Domain	C2 domain	sn0son4t31opc[.]freeddns[.]org
Domain	C2 domain	soovuy[.]gleeze[.]com
Domain	C2 domain	styuij[.]mywire[.]org
Domain	C2 domain	supceasfg1[.]loseyourip[.]com
Domain	C2 domain	systemsz[.]kozow[.]com
Domain	C2 domain	t31c0mjumpcuyerop[.]ooguy[.]com
Domain	C2 domain	t31c0mopamcuiomx[.]kozow[.]com
Domain	C2 domain	t31c0mopmiuewklg[.]webredirect[.]org
Domain	C2 domain	t31c0mopocuveop[.]accesscam[.]org
Domain	C2 domain	t3lc0mcanyqbfac[.]loseyourip[.]com
Domain	C2 domain	t3lc0mczmoihwc[.]camdvr[.]org
Domain	C2 domain	t3lc0mh4udncifw[.]casacam[.]net
Domain	C2 domain	t3lc0mhasvnctsk[.]giize[.]com
Domain	C2 domain	t3lm0rtlcagratu[.]kozow[.]com
Domain	C2 domain	tch[.]giize[.]com
Domain	C2 domain	telcomn[.]giize[.]com
Domain	C2 domain	telen[.]bumbleshrimp[.]com
Domain	C2 domain	telkom[.]ooguy[.]com
Domain	C2 domain	telkomservices[.]theworkpc[.]com
Domain	C2 domain	thbio[.]kozow[.]com
Domain	C2 domain	timpe[.]kozow[.]com
Domain	C2 domain	timpe[.]webredirect[.]org
Domain	C2 domain	tlse001hdfuwwgdgpnn[.]theworkpc[.]com
Domain	C2 domain	tltlsktelko[.]ddnsfree[.]com
Domain	C2 domain	transport[.]dynuddns[.]net
Domain	C2 domain	trvcl[.]bumbleshrimp[.]com
Domain	C2 domain	ttsiou12[.]loseyourip[.]com
Domain	C2 domain	ua2o25yth[.]ddnsgeek[.]com
Domain	C2 domain	udieyg[.]gleeze[.]com
Domain	C2 domain	unnjunnani[.]ddnsfree[.]com
Domain	C2 domain	updatamail[.]kozow[.]com
Domain	C2 domain	updatasuccess[.]ddnsgeek[.]com
Domain	C2 domain	updateservices[.]kozow[.]com
Domain	C2 domain	updatetools[.]giize[.]com
Domain	C2 domain	uscplxsecjs[.]ddnsgeek[.]com
Domain	C2 domain	USOShared1[.]ddnsfree[.]com
Domain	C2 domain	vals[.]bumbleshrimp[.]com
Domain	C2 domain	vass[.]ooguy[.]com
Domain	C2 domain	vass2025[.]casacam[.]net
Domain	C2 domain	vmtools[.]camdvr[.]org
Domain	C2 domain	vmtools[.]loseyourip[.]com
Domain	C2 domain	vosies[.]ddnsfree[.]com
Domain	C2 domain	vpaspmine[.]freeddns[.]org
Domain	C2 domain	wdlcamaakc[.]ooguy[.]com
Domain	C2 domain	winfoss1[.]kozow[.]com
Domain	C2 domain	ysiohbk[.]camdvr[.]org
Domain	C2 domain	zammffayhd[.]ddnsfree[.]com
Domain	C2 domain	zmcmvmbm[.]ddnsfree[.]com
Domain	C2 domain	zwmn350n3o1fsdf3gs[.]kozow[.]com
Domain	C2 domain	zwmn350n3o1ugety2xbe[.]camdvr[.]org
Domain	C2 domain	zwmn350n3o1vsdrggs[.]ddnsfree[.]com
Domain	C2 domain	zwt310n3o1unety2kab[.]webredirect[.]org
Domain	C2 domain	zwt310n3o2unety6a3k[.]kozow[.]com
Domain	C2 domain	zwt31n3t0nidoqmve[.]camdvr[.]org
Domain	C2 domain	zwt3ln3t1aimckalw[.]theworkpc[.]com
SHA256 Hash	Self-signed X.509 SSL certificate	d25024ccea8eac85a9522289cfb709f2ed4e20176dd37855bacc2cd75c995606

Description	URLs
Archive contained GRIDTIDE.	http://130[.]94[.]6[.]228/apt.tar.gz
Archive contained a SoftEtherVPN Bridge component.	http://130[.]94[.]6[.]228/update.tar.gz
Archive contained a SoftEtherVPN Bridge component.	http://130[.]94[.]6[.]228/amp.tar.gz
GRIDTIDE leverages this API endpoint to monitor cell A1 of the spreadsheet for threat actor commands.	https://sheets[.]googleapis[.]com:443/v4/spreadsheets/<GoogleSheetID>/values/A1?valueRenderOption=FORMULA
GRIDTIDE leverages this API endpoint to clear data from the first 1000 rows of the spreadsheet.	https://sheets[.]googleapis[.]com:443/v4/spreadsheets/<GoogleSheetID>/values:batchClear
GRIDTIDE leverages this API endpoint to exfiltrate victim host metadata to cell V1, report command execution output and status messages to cell A1, and to transfer data into the A2:An cell range.	https://sheets[.]googleapis[.]com:443/v4/spreadsheets/<GoogleSheetID>/values:batchUpdate
GRIDTIDE leverages this API endpoint to transfer data from the A2:An cell range to the victim host.	https://sheets[.]googleapis[.]com:443/v4/spreadsheets/<GoogleSheetID>/values/A2:A<cell_number>?valueRenderOption=FORMULA

GRIDTIDE YARA Rule

rule G_APT_Backdoor_GRIDTIDE_1 {
        meta:
                author = "Google Threat Intelligence Group (GTIG)"
        strings:
                $s1 = { 7B 22 61 6C 67 22 3A 22 52 53 32 35 36 22 2C 22 6B 69 64 22 3A 22 25 73 22 2C 22 74 79 70 22 3A 22 4A 57 54 22 7D 00 }
                $s2 = { 2F 70 72 6F 63 2F 73 65 6C 66 2F 65 78 65 00 }
                $s3 = { 7B 22 72 61 6E 67 65 73 22 3A 5B 22 61 31 3A 7A 31 30 30 30 22 5D 7D 00 }
                $s4 = { 53 2D 55 2D 25 73 2D 31 00 }
                $s5 = { 53 2D 55 2D 52 2D 31 00 }
                $s6 = { 53 2D 44 2D 25 73 2D 30 00 }
                $s7 = { 53 2D 44 2D 52 2D 25 64 00 }
        condition:
                (uint32(0) == 0x464c457f) and 6 of ($*)
}

from Threat Intelligence https://ift.tt/NMms6FC
via IFTTT

Manual Processes Are Putting National Security at Risk

Why automating sensitive data transfers is now a mission-critical priority

More than half of national security organizations still rely on manual processes to transfer sensitive data, according to The CYBER360: Defending the Digital Battlespace report. This should alarm every defense and government leader because manual handling of sensitive data is not just inefficient, it is a systemic vulnerability. 

Recent breaches in defense supply chains show how manual processes create exploitable gaps that adversaries can weaponize. This is not just a technical issue. It is a strategic challenge for every organization operating in contested domains, where speed and certainty define mission success.

In an era defined by accelerating cyber threats and geopolitical tension, every second counts. Delays, errors, and gaps in control can cascade into consequences that compromise mission readiness, decision-making, and operational integrity. This is exactly what manual processes introduce: uncertainty in environments where certainty is non-negotiable. They create bottlenecks and increase the risk of human error. In short, they undermine the very principles of mission assurance: speed, accuracy, and trust.

Adversaries know this. They exploit seams in data movement. Every manual step is a potential breach point. In a contested environment, these vulnerabilities are operational, not theoretical.

Why Manual Persists

If manual processes are so risky, why do they remain? The answer lies in a mix of technical, cultural, and organizational factors. 

Legacy systems remain a major barrier. Many defense and government environments still run on infrastructure that predates modern automation capabilities. These systems were never designed for seamless integration with policy engines or encryption frameworks. Replacing them is costly and disruptive, so organizations layer manual steps as a workaround. 

Procurement cycles compound the problem. Acquiring new technology in national security contexts is often slow and complex. Approval chains are long, requirements are rigid, and by the time a solution is deployed, the threat landscape has shifted. Leaders often adopt manual processes as a stopgap, but these temporary measures quickly become permanent habits.

Cross-domain complexity adds another layer. Moving data between classification levels requires strict controls. Historically, these controls relied on human judgment to inspect and approve transfers. Automation was seen as too rigid for nuanced decisions. That perception persists even as modern solutions can enforce granular policies without sacrificing flexibility. 

Culture plays a role as well. Trust in people runs deep in national security organizations. Manual handling feels tangible and controllable. Leaders and operators believe that human oversight reduces risk, even when evidence shows the opposite. This slows the adoption of automation. 

In some cases, operators still print and hand-carry classified files because digital workflows are perceived as too risky. Regulatory inaction compounds this problem. Compliance frameworks often lag behind technology, reinforcing manual habits and slowing modernization efforts.

Finally, there is a fear of disruption. Missions cannot pause for technology transitions. Leaders worry the automation will introduce delays or errors during rollout. They prefer the known imperfections of manual processes to the unknown risks of change. 

These factors explain persistence, but they do not justify it. The environment has changed. Threats are faster, more sophisticated, and increasingly opportunistic.

The Risk of Manual Handling

1. Human error and variability: Sensitive data transfer should be consistent and precise. Manual steps introduce variance across teams and time. Even highly trained personnel face fatigue and workload pressure. Small errors can cascade into operational delays or unintended disclosures. Fatigue during high-tempo missions amplifies mistakes, and insider risk grows when oversight depends on trust alone.
2. Weak enforcement of policy: Automation turns policy into code. Manual handling turns policy into interpretation. Under pressure, exceptions grow, and workarounds become standard practice. Over time, compliance erodes. These gaps slow incident response and undermine accountability during investigations, leaving leaders without timely insights when decisions matter most.
3. Audit gaps and accountability risks: Manual movements are hard to track. Evidence is fragmented across emails and ad hoc logs. Investigations take too long. Leaders cannot rely on consistent chain-of-custody records.
4. Security blind spots across domains: Sensitive data often moves across classification levels and networks. Manual processes make these transitions opaque. Adversaries exploit seams where enforcement is inconsistent.
5. Mission performance drag: Speed is a security control. Manual transfers add handoffs and delays. Decision cycles slow down. People compensate by skipping steps, introducing new risks.

Manual processes are not resilient. They are fragile, and they fail quietly and then fail loudly.

Principles for Secure Automation: The Cybersecurity Trinity

Manual processes are not resilient. They fail quietly and then fail loudly. Eliminating these vulnerabilities requires more than simply automating steps. It demands a security architecture that enforces trust, protects data, and manages boundaries at scale. So, how do defense and government organizations close these gaps and make automation secure? The answer lies in three principles that work together to protect identity, data, and domain boundaries. This is the Cybersecurity Trinity

Automation alone is no longer enough. Modern missions demand a layered approach that addresses identity, data, and domain boundaries. The Cybersecurity Trinity of Zero Trust Architecture (ZTA), Data-Centric Security (DCS), and Cross Domain Solutions (CDS) is now a mission imperative for defense and government organizations. 

Zero Trust Architecture (ZTA) ensures that every user, device, and transaction is verified continuously. It eliminates implicit trust and enforces least privilege across all environments. ZTA is the foundation for identity assurance and access control. This reduces insider risk and ensures coalition partners operate under consistent trust models, even in dynamic mission environments.

Data-Centric Security (DCS) shifts the focus from perimeter defense to protecting the data itself. It applies encryption, classification, and policy enforcement wherever the data resides or moves. In sensitive workflows, DCS ensures that even if networks are compromised, the data remains secure. It supports interoperability by applying uniform controls across diverse networks, enabling secure collaboration without slowing operations.

Cross Domain Solutions (CDS) enable controlled, secure transfer of information between classification levels and operational domains. They enforce release authorities, sanitize content, and prevent unauthorized disclosure. CDS is critical for coalition operations, intelligence sharing, and mission agility. These solutions enable secure multinational sharing without introducing delays, which is critical for time-sensitive intelligence exchange.

Together, these three principles form the backbone of secure automation. They close the gaps that manual processes leave open. They make security measurable and mission success sustainable. 

Special Considerations for Defense and Government

Sensitive data transfer in national security contexts presents unique challenges. CDS requires automated inspection and enforcement of release authorities. Coalition operations demand federated identity and shared standards to maintain security across organizational boundaries. Tactical systems need lightweight agents and resilient synchronization for low-bandwidth environments. Supply chain exposure must be addressed by extending automation to contractors with strong verification and audit requirements.

In joint missions, delays caused by manual checks can stall intelligence sharing and compromise operational tempo. Automation mitigates these risks by enforcing common standards across partners. Emerging threats such as AI-driven attacks and deepfake data manipulation make manual verification obsolete, increasing the urgency for automated safeguards. Insider risk remains a concern, but automation reduces opportunities for misuse by limiting manual handling and providing detailed audit trails.

The Human Factor

Automation does not eliminate the need for skilled personnel. It changes their focus. People design policies, manage exceptions, and investigate alerts. To make the transition successful, invest in training and culture. Show teams how automation improves mission speed and reduces rework. Communicate clearly and consistently. Celebrate early wins. Create feedback loops where operators can refine workflows. Start with pilot programs in low-risk workflows to build confidence before scaling. Leadership buy-in and clear communication are essential to overcome resistance and accelerate adoption. When automation feels like support rather than surveillance, adoption accelerates.

Conclusion

Manual handling of sensitive data is a strategic liability. It slows missions, creates blind spots, and erodes trust. Automation is not optional; it is mission imperative. Start with high-impact workflows designed by subject matter experts, and in turn, appropriately test the policy into enforceable rules. Integrate identity, encryption, and audit. Measure outcomes, train teams, and fund initiatives that reduce risk. 

What should not remain true is that more than half rely on manual today. Your organization does not have to be among them tomorrow. The next conflict will not wait for manual processes to catch up. Leaders must act now to harden data flows, accelerate mission readiness, and ensure that automation becomes a force multiplier rather than a future aspiration.

Source: The CYBER360: Defending the Digital Battlespace.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/7gvRbH3
via IFTTT