New SHEET#CREEP Variant Abuses Google Sheets to Evade Detection and Maintain Remote Access

The SHEET#CREEP malware family, initially documented by threat researchers in early 2026, has undergone significant engineering updates by sophisticated cyber-espionage threat actors. In this latest campaign iteration, adversaries have transitioned away from utilizing raw, plaintext configuration strings toward incorporating rigid, runtime-decrypted obfuscation methods designed to bypass static signature analysis and endpoint detection telemetry. By choosing to leverage highly trusted SaaS communication ecosystems—specifically the Google Sheets API v4—the operators manage to conceal their malicious command-and-control (C2) operations entirely inside standard HTTPS transactions directed at legitimate Google infrastructures. Security analysis teams inverted this operational framework by extracting hardcoded Google Cloud Platform (GCP) service account credentials from a live sample binary. This breakthrough enabled direct authentication to the adversary’s primary control node, uncovering 91 active victim tracking tabs, including high-confidence espionage targets located within diplomatic structures in Islamabad, Pakistan.

Initial Access Vectors via Diplomatic-Themed Lures

The primary infection vector relies on targeted spear-phishing maneuvers delivering a custom-engineered virtual disk image file named UAE-India_Strategic_Partnership_Week.iso. This file exploits current geopolitical discourse surrounding foreign affairs to trick personnel within diplomatic networks into executing malicious code. When the victim mounts this ISO file on a Windows workstation, they are presented with what appears to be an innocent, singular documentation file named UAE-India_Strategic_Partnership-Week.lnk. To ensure successful execution, the threat actor manipulates the LNK file configuration to display a standard PDF document icon, exploiting visual trust. In reality, double-clicking this shortcut does not launch a document reader; instead, it executes an underlying command sequence through the system command interpreter: C:\Windows\System32\cmd.exe /c start "" "Document_11052026-03578240540350-93.exe". This technique bridges the initial execution barrier, transitioning the malware from an un-scanned container file straight into active host memory.

Dropper Execution Mechanics and Deconstruction of CoreDeployment

The application spawned directly by the shortcut file is a lightweight, custom-built C# .NET dropper executable containing a core assembly class designated as CoreDeployment. Despite maintaining a remarkably small storage profile on disk, the dropper handles multi-stage extraction and installation workflows in immediate succession. Embedded deep within its manifest resources are two foundational components: InternalBait and InternalExe. The InternalBait asset contains a genuine-looking PDF decoy that the malware immediately drops into the host’s temporary folder as %TEMP%\<GUID>.pdf, calling Process.Start() to display it to the user and mitigate suspicion. Simultaneously, the core RAT payload contained within InternalExe is written directly to disk at %LOCALAPPDATA%\Microsoft\Vault\vaultsvc.exe. This specific file path is chosen to match legitimate Windows Credential Vault paths, ensuring that the malicious binary blends in with native operating system binaries during administrative inspections. Immediately after the file write completes, the dropper uses the programmatic call File.SetAttributes(text2, FileAttributes.Hidden | FileAttributes.System) to hide the executable from default File Explorer views.

Persistent Integration via Task Scheduler COM API Manipulation

Rather than relying on noisy, easily audited command-line utilities such as schtasks.exe (which regularly generate noticeable Windows Event Logs like Event ID 4698), the dropper leverages programmatic manipulation. It interacts directly with the Task Scheduler COM interface (Schedule.Service) to establish persistent execution rights on the infected machine. The malware creates a recurring background task named WindowsVaultSyncService. To evade detection during manual system audits, the task is given a highly deceptive description: "Windows Edge Core Update Task Machine Discord Update". This naming strategy combines components from Microsoft Edge, Windows Core, and Discord to appear benign. Crucially, the execution duration limit parameter is programmatically set to PT0S, which establishes an infinite execution limit. This ensures that the remote access trojan runs perpetually across active user logon sessions without triggering timeouts.

The Self-Deletion (Melt) and Counter-Forensic Routine

Once the local installation layout and persistent task architectures are verified, the dropper initiates an automated counter-forensic cleansing phase known as a “melt” routine. The binary spawns a hidden, independent cmd.exe process that enforces a strict two-second execution delay. This delay ensures the primary dropper process can close completely before the shell script issues an un-recoverable forced deletion command against the originating dropper file. Instantly following the removal of the binary payload, the routine moves the harmless decoy PDF document from the %TEMP% folder into the exact directory path where the dropper originally resided. This leaves the benign PDF in place of the malicious executable. Consequently, any post-incident investigation looking at the execution folder will only find a valid document, while the actual remote access trojan remains concealed inside the system’s hidden application folders.

Deconstructing the SHEETCREEP Remote Access Trojan (WinSyncSvc)

The functional core of this cyber-espionage threat resides entirely within the extracted vaultsvc.exe application, which operates as a compiled C# .NET assembly under the WinSyncSvc namespace. Measuring roughly 20 KB, the binary achieves its small footprint by offloading heavy execution workloads to native Windows systems. Instead of embedding standalone processing tools, the RAT spins up an in-process PowerShell runspace utilizing the System.Management.Automation library. To safely manage unique infections across a wide target base, the RAT generates an exclusive victim fingerprint tracking sequence upon initialization. It concatenates the active workstation username, the computer hostname, and an isolated four-character SHA256 cryptographic hash snippet to construct a standardized victim identity string (e.g., *username*-DESKTOP-R32QGHR-9CDE). This string defines the unique programmatic workspace identity for that host, while the malware enforces single-instance execution constraints globally via a system mutex labeled Global\WinSync_<UID>.

Cryptographic Obfuscation and Runtime Configuration Decryption

Unlike historical strains of SHEETCREEP that maintained open plaintext parameters within the application string tables, this updated payload uses robust configuration protection. The critical variables required to reach the control nodes—such as Google API project data and account paths—are encrypted using a symmetric XOR cipher mapped to the static string key "discrete". At runtime, the application passes these payloads through an inline decryption routine named JIT() to rebuild the required strings in memory. Reversing this routine reveals the core infrastructure endpoints used in the campaign:

  • Encrypted Base64 Spreadsheet ID Value: VSURVjAgPRYBAREgNQBMFVUDGAUlA0EoE1gXITMGA1A2ISQlFgIVUAMvAls=
  • Decrypted Target C2 Spreadsheet ID: 1Lb5BEIsehbCGe8p1jkfWf5Mw1dBAcw5RHWFdga5gFq8
  • Encrypted Base64 Service Account Value: FwEWBgZQNBYMDBYXR0hAXFFeQ1RcDBUISg4ABgATHQYBCBAAHRAaEUoKHA4=
  • Decrypted Google Cloud Service Account Email: [email protected]
  • Identified GCP Project Infrastructure ID: sheet5-495707

Exploiting Google Sheets API v4 for Bidirectional C2 Operations

The RAT establishes communication entirely across legitimate cloud pathways, sending traffic to the IP address 142.251.223.42 assigned to Google LLC (AS15169). The malware authorizes its requests against the Google Sheets API v4 endpoints (sheets.googleapis.com) by generating a signed JSON Web Token (JWT) constructed locally via an embedded RSA-2048 PKCS#8 private key. The resulting OAuth2 access token remains active for a 60-minute window, though the malware proactively requests an authentication refresh at the 50-minute mark to ensure continuous access.

The primary C2 traffic engine is driven by a recurring loop inside a function named Pulse(). On every cycle, the RAT queries the spreadsheet metadata to confirm whether a worksheet tab matching its unique victim UID exists; if missing, it requests the immediate creation of a new tab. On the initial beacon check-in, the malware seeds cell A1 with a First: execution timestamp, writes control headers (I, O, T) into row 2, and runs a native systeminfo command. It posts the Base64-encoded command string to cell A3 and returns the Base64-encoded response output inside cell B3. Subsequent operations follow a strict polling sequence focused on cells A4 through B100. The malware monitors for newly populated rows where Column A contains a Base64-encoded command while Column B remains completely empty. It decodes the instruction, runs the command within the hidden PowerShell runspace, and writes the Base64-encoded output back into Column B to complete the transaction loop.

Active Anti-Analysis and Sandbox Countermeasures

To protect the operation against security analysis and virtual sandbox processing plants, SHEETCREEP includes an aggressive tracking routine that actively scans the local system workspace. The malware continuously monitors active process handles, analyzing window title bars, application registries, and system folder layouts for common administrative debugging tools. It looks specifically for running instances of reverse-engineering and packet-capture software, including dnSpy, Wireshark, and Network Monitor. If any of these diagnostic utilities are detected on the target machine, the RAT immediately drops its communication handles and triggers a forced system crash. It executes an immediate system command by calling Restart-Computer -Force. This defensive mechanism disrupts the analyst’s debugging environment, clears volatile memory spaces, and closes active network analysis captures before deeper behavioral rules or tracking data can be pulled from the running application.

Defending Enterprise Environments Against Cloud-Native RATs

Defending enterprise architectures against malware that misuses legitimate cloud services requires moving beyond basic domain reputation blocklists. Since blocking outbound traffic to sheets.googleapis.com outright can cause severe operational issues within modern corporate environments, security teams must deploy behavioral analytical logic to identify anomalous non-browser processes initiating persistent HTTPS connections to Google Cloud API endpoints. Furthermore, directory monitoring solutions should flag any binary creation events within the %LOCALAPPDATA%\Microsoft\Vault\ directory, as standard Windows systems do not install user executable applications inside that folder path.

Because the malware executes tasks entirely in-memory via an embedded PowerShell runspace, traditional command-line auditing will fail to capture the malicious code. Organizations must implement Endpoint Detection and Response (EDR) platforms paired with active Antimalware Scan Interface (AMSI) visibility and System Monitor (Sysmon) logging. This approach allows security teams to inspect internal .NET assemblies, track Task Scheduler COM interactions, and decode runtime script blocks before they hide inside encrypted cloud streams.

Technical Matrix: MITRE ATT&CK Mapping

The operational tactics and techniques observed across the SHEET#CREEP campaign map directly to the following industry-standard MITRE ATT&CK classifications:

TacticMITRE ATT&CK IDTechnique Name & Description
Initial AccessT1566.001Spearphishing Attachment (Weaponized UAE-India_Strategic_Partnership_Week.iso file)
ExecutionT1204.002User Execution: Malicious File (Victim double-clicking the spoofed LNK file)
ExecutionT1059.001Command and Scripting Interpreter: PowerShell (In-process execution via .NET)
Execution / PersistenceT1053.005Scheduled Task/Job: Scheduled Task (Programmatic setup of WindowsVaultSyncService)
Defense EvasionT1564.001Hidden Files and Directories (Setting Hidden and System attributes on vaultsvc.exe)
CollectionT1005File and Directory Discovery (Target profiling using internal systeminfo queries)
Command and ControlT1102.002Web Service: Bidirectional Communication (Abusing the Google Sheets API v4 infrastructure)
Command and ControlT1573.002Encrypted Channel: Asymmetric Cryptography (JWT signing via embedded RSA-2048 key)
ExfiltrationT1041Exfiltration Over C2 Channel (Data exfiltration routed through Base64-encoded cells)

Our Opinion on the SHEET#CREEP Espionage Campaign

The evolution of the SHEET#CREEP malware family underscores a critical, accelerating shift in modern cyber-espionage tactics: the weaponization of trusted SaaS infrastructure. By shifting command-and-control operations from traditional hacker-controlled servers to legitimate Google Cloud environments, threat actors exploit the inherent blind spots of modern network defenses. Most corporate firewalls are blind to traffic directed at trusted endpoints like Google APIs, creating a perfect camouflage for malicious activities.

Furthermore, the transition from plaintext configurations to XOR-obfuscated parameters proves that these state-sponsored adversaries are actively adapting to public threat intelligence reports. They are no longer utilizing lazy design patterns; instead, they are deliberately hardening their code against static detection and automated analysis pipelines. The inclusion of aggressive anti-analysis payloads, such as forcing a full system reboot upon discovering debugging tools like dnSpy or Wireshark, demonstrates a highly combative operational style. For defenders, this highlights a sobering reality: traditional perimeter and signature-based defenses are completely obsolete against cloud-native threats. Securing modern diplomatic and enterprise networks now strictly requires deep behavior-based analysis, robust endpoint logging via AMSI, and an assumption of compromise within otherwise trusted channels. Ultimately, managing these risks requires zero-trust verification frameworks applied universally across internal tools and third-party SaaS ecosystems alike.