SHEET#CREEP — APT36 / Transparent Tribe Google Sheets API RAT

SHEET#CREEP is an ongoing espionage campaign tracked by Securonix Threat Research, attributed with moderate confidence to APT36 / Transparent Tribe (Pakistan-aligned), a group historically targeting Indian government and military entities. The campaign delivers a compact (~20 KB) C# remote access trojan that abuses the Google Sheets API as its entire command-and-control channel. The malware family was first documented by Zscaler ThreatLabz (Jan 2026); the current Securonix analysis is a continuation/evolution with new obfuscation and evasion.

Initial access is a diplomatic-themed ISO lure (e.g. a UAE–India strategic-partnership theme, UAE-India_Strategic_Partnership_Week.iso) containing a LNK shortcut masquerading as a PDF. When the user double-clicks the mounted ISO, the LNK launches a C# dropper that shows a decoy PDF while installing the RAT (vaultsvc.exe) into %LOCALAPPDATA%\Microsoft\Vault\ with Hidden+System attributes, then self-deletes. Persistence is a COM-created scheduled task WindowsVaultSyncService with a deliberately confusing description mixing Edge/Windows/Discord terms.

For C2, the RAT authenticates to a single attacker-owned spreadsheet using an embedded GCP service-account RSA-2048 private key (JWT/OAuth2), then uses one spreadsheet tab per victim (keyed by a username-hostname-4charhash id). Operators write Base64-encoded commands to one column; the victim returns Base64 output in another column. To all network monitoring this looks like ordinary Google Workspace traffic to sheets.googleapis.com / oauth2.googleapis.com.

Two evolutions raise the bar for defenders: (1) C2 config strings (spreadsheet ID, service-account creds) that were previously plaintext are now XOR-obfuscated with the key "discrete" and decrypted only at runtime, defeating static config-string hunting; and (2) the RAT executes PowerShell entirely in-process via the System.Management.Automation namespace — no child powershell.exe is ever spawned. Researchers extracted the embedded creds, authenticated to the live sheet, and found 91 active victim tabs (including a high-confidence target in Islamabad, Pakistan), alongside numerous sandbox/researcher tabs.

Defender priority: The in-process PowerShell design removes the usual child-process command-line signal — this is a deliberate detection gap. Pivot the hunt to the durable spine: (1) a non-browser / unsigned .NET process talking to the Google Sheets API, and (2) the load points — execution from a mounted ISO/removable volume, a binary running out of %LOCALAPPDATA%\Microsoft\Vault\, and the WindowsVaultSyncService scheduled task. Any one confirmed hit is a probable live RAT — treat as active espionage intrusion.

Web-hunter note: Atomic file hashes and the C2 spreadsheet ID/service account ARE published and durable enough to block/hunt today, but APT36 routinely re-tools — the campaign-specific creds and ISO names will rotate. Lead with behavioral detection (network-to-Google-API by a non-browser .NET process; load-point execution) and treat the published hashes/IDs as high-value but perishable. The XOR-"discrete" config string is now obfuscated in memory, so do not rely on static plaintext config hunts.

Hypotheses (ordered by fidelity)

1. H1 (high): A non-browser process makes DNS / network connections to sheets.googleapis.com / oauth2.googleapis.com / www.googleapis.com — the signature Google Sheets API C2 channel (T1102.002). Strongest angle; tune hard by excluding browsers and legitimate Google API/sync clients.
2. H2 (high): A payload executes from a mounted ISO/IMG or removable volume (.exe / .lnk / .NET assembly) shortly after a disk-mount — the lure detonation (T1566.001 + T1204.002 + T1027.006).
3. H3 (high): A process runs from %LOCALAPPDATA%\Microsoft\Vault\ (e.g. vaultsvc.exe) — the dropped RAT load point, an unusual execution path for a CLR-hosted binary.
4. H4 (high): A scheduled task named WindowsVaultSyncService is created (or runs) pointing at a user-writable Vault path — the persistence mechanism (T1053.005).
5. H5 (medium): An unsigned / user-path .NET (CLR-hosted) binary beacons on an interval to googleapis endpoints — correlate CLR load + repeating Google-API connections from the same image.
6. H6 (medium): A freshly written PE in a user-writable/temp/Vault path is executed soon after (T1105 / T1204) — the dropper-to-RAT staging.
7. H7 (low): Known atomic IOCs present — file hashes for the ISO/dropper/RAT, the C2 spreadsheet ID, or the service-account string (perishable; APT36 re-tools).

Attack chain

Known detection gap: Because the RAT runs PowerShell in-process (no powershell.exe child, no script-block command line on a child), the classic "office app spawns powershell" / child-command-line hunts will NOT fire. Coverage is deliberately pivoted to the network (Google-API) and load-point (ISO mount, Vault path, scheduled task) angles. Where available, AMSI/script-block telemetry on the host CLR process is the only in-process visibility.

APT36 re-tools frequently. The file hashes, spreadsheet ID, and service-account string below are published by Securonix and usable today, but are perishable — validate in your own telemetry and pair with the behavioral signatures, which survive rotation. The C2 IP is a shared Google front (do NOT block).

Checks that do not require building CQL — run these directly on the host or via Falcon RTR sweeps:

• Vault directory sweep: on suspect hosts, list %LOCALAPPDATA%\Microsoft\Vault\ for any EXE (especially Hidden+System). The legitimate Windows Credential Vault does not place executables here. RTR: ls -force "$env:LOCALAPPDATA\Microsoft\Vault".
• Scheduled-task review: enumerate tasks for WindowsVaultSyncService or any task whose description mixes Edge/Windows/Discord terms or points at a user-writable Vault path. RTR: schtasks /query /fo LIST /v then grep for Vault / WinSync.
• ISO landing review: search Downloads / mail-attachment caches for recently written .iso / .img files with diplomatic-themed names; correlate with a subsequent mount.
• Mutex check: look for a running handle matching Global\WinSync_* as a quick live-RAT tell.
• Proxy / firewall logs: review egress to sheets.googleapis.com and oauth2.googleapis.com and identify which process initiated it — a non-browser client to the Sheets API on a host with no Google Workspace use case is suspect.

Promotion candidates from the hunt queries above (Windows platform, Process Create rule type unless noted):

The Google-Sheets-API C2 queries (Q2/Q4/Q5) are best deployed as scheduled-search detections / NGSIEM correlation rules, not Process-Create IOAs — they key on DNS/network telemetry and need the per-fleet browser/Google-client exclusion list maintained over time. Because the RAT runs PowerShell in-process, there is no child-process IOA for the command execution itself — that gap is covered by the network and load-point IOAs instead.

One-click copy blocks for ingestion. File hashes and the C2 sheet ID are published but perishable (APT36 re-tools); the Google IP is a shared front — enrich only, never block.

type,value,action,severity,expiration,description,tags
sha256,1ba67bb1cfad42446880cca53cbd05fe66d7514b2bb139b48e5c63adff14be7b,detect,high,2026-12-22,SHEETCREEP lure ISO,campaign:SHEETCREEP
sha256,2cc7c2d8653c98e5bac32fcaf5e45b861efb4bb87df3b3f96285edb475e75bba,detect,critical,2026-12-22,SHEETCREEP C# dropper,campaign:SHEETCREEP
sha256,62d62950ff7a0e43550a5d0ba55d32d5083b9de5538e0f012e406b6d951e16aa,detect,critical,2026-12-22,SHEETCREEP RAT vaultsvc.exe,campaign:SHEETCREEP

non_browser_proc -> DNS/conn: sheets.googleapis.com | oauth2.googleapis.com   # C2
proc_exec FROM mounted ISO/IMG / removable volume (D:-Z:)                     # lure
proc_exec FROM %LOCALAPPDATA%\Microsoft\Vault\*.exe                            # RAT load point
scheduled_task: WindowsVaultSyncService  (Vault path target)                  # persistence
mutex: Global\WinSync_<user>-<host>-<4char>                                     # live RAT tell
NOTE: PowerShell runs in-process (no child powershell.exe) — DETECTION GAP

SHEET#CREEP — APT36 / Transparent Tribe (moderate confidence)
Lure: diplomatic-themed ISO (e.g. UAE-India_Strategic_Partnership_Week.iso) w/ LNK-as-PDF
RAT: vaultsvc.exe (~20 KB C#) in %LOCALAPPDATA%\Microsoft\Vault\ (Hidden+System)
C2: Google Sheets API; one tab per victim; Base64 cmd/response columns
Auth: embedded GCP service account + RSA-2048 PKCS#8 key (JWT/OAuth2)
Config: XOR-obfuscated, key = "discrete"  |  Exec: in-process PowerShell, no child proc
Persistence: scheduled task WindowsVaultSyncService

# Google Sheets API C2 (hunt / enrich — do NOT block the shared Google IP)
c2_sheet_id      = 1Lb5BEIsehbCGe8p1jkfWf5Mw1dBAcw5RHWFdga5gFq8
service_account  = sheet5-495707@appspot.gserviceaccount.com
c2_domains       = sheets.googleapis.com  oauth2.googleapis.com  www.googleapis.com
c2_ip_shared     = 142.251.223.42  (Google LLC AS15169 — ENRICH ONLY)
mutex            = Global\WinSync_<username>-<hostname>-<4char-hash>
xor_config_key   = discrete

A · Block ISO / IMG / VHD double-click auto-mount (GPO / registry)

Removes the mount handler so standard users can't detonate an image lure by double-clicking. Deploy via GPO Preferences or Intune:

# Disable Explorer mount verb for .iso / .img / .vhd / .vhdx
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices" /v Deny_All /t REG_DWORD /d 0 /f
# Strip the default "mount" handler for disk images:
reg delete "HKCR\Windows.IsoFile\shell\mount" /f 2>nul
reg delete "HKCR\Windows.VhdFile\shell\mount" /f 2>nul
# (Optional) block image mounting policy where supported:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Explorer" /v NoUseStoreOpenWith /t REG_DWORD /d 1 /f

B · WDAC / AppLocker — deny unsigned .NET from user paths

# AppLocker EXE rule (deny) — block execution from AppData, Temp and removable media
# Computer Config > Windows Settings > Security > Application Control Policies > AppLocker
#   Executable Rules: DENY  Everyone
#     Path: %OSDRIVE%\Users\*\AppData\*
#     Path: %OSDRIVE%\Windows\Temp\*
#     Path: %REMOVABLE%\*
# Enforce signing for the rest:
#     Publisher rule: ALLOW signed by your trusted publishers; default-deny remainder
Set-AppLockerPolicy -XmlPolicy .\sheetcreep-applocker.xml -Merge

C · Microsoft Defender ASR rules (PowerShell)

# Block untrusted/unsigned processes from USB
Add-MpPreference -AttackSurfaceReductionRules_Ids b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4 -AttackSurfaceReductionRules_Actions Enabled
# Block executable files unless prevalence/age/trusted-list criteria met
Add-MpPreference -AttackSurfaceReductionRules_Ids 01443614-cd74-433a-b99e-2ecdc07bfc25 -AttackSurfaceReductionRules_Actions Enabled
# Block Office apps from creating child processes (covers doc-launched chains)
Add-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a -AttackSurfaceReductionRules_Actions Enabled

D · Live triage / IOC sweep (Falcon RTR)

# Vault drop + persistence + mutex sweep on a suspect host
ls -force "$env:LOCALAPPDATA\Microsoft\Vault"
schtasks /query /fo LIST /v | findstr /i "WindowsVaultSyncService WinSync Vault"
Get-ScheduledTask | Where-Object { $_.TaskName -match 'VaultSync|WinSync' }
# confirm what process is talking to the Sheets API:
Get-NetTCPConnection -RemotePort 443 | Sort-Object OwningProcess

Validation: The load-point spine (Q1/Q3/Q6) is strong and low-FP — a confirmed hit on any is a probable live RAT. The C2 spine (Q2/Q4/Q5) is the signature angle but FP-prone: it only stays clean if the browser/Google-client allowlist is maintained per fleet. The in-process PowerShell execution is an intentional detection gap — there is no child powershell.exe and no child command line, so command execution itself is only visible via AMSI/script-block telemetry on the CLR host where enabled; detection is deliberately pivoted to the network (Google-API) and load-point (ISO/Vault/task) angles. Validate all field names (esp. ContextBaseFileName, RegStringValue, TaskName/TaskExecutable) against your tenant before deploying.