Active Espionage Campaign

GearDoor: The Backdoor That Hides Inside Google Drive

A China-linked espionage group has turned one of the world's most trusted cloud services into a covert command channel. GearDoor, a custom .NET backdoor tied to the Silver Dragon threat cluster, communicates entirely through Google Drive — leaving no suspicious server traffic for defenders to catch.

7+
Countries targeted across Europe and Southeast Asia
3
Distinct infection chains documented
5+
Google and Microsoft services abused by APT41 for C2

When Check Point Research published their findings on Silver Dragon in March 2026, one detail stood out immediately from the technical noise: the group's custom backdoor does not call home to an attacker-controlled server. It calls Google. Specifically, it uploads and downloads files from a dedicated Google Drive account — wrapping every piece of its command-and-control communication inside traffic that looks indistinguishable from what tens of millions of legitimate enterprise users generate every single day. LOTS

Why routing C2 through Google is structurally different from traditional malware
Traditional C2 infrastructure generates detectable signals: DNS lookups to newly registered or low-reputation domains, connections to IP addresses in unusual geographic locations, TLS certificates that don't match expected profiles, or beaconing patterns to infrastructure that threat intel feeds have flagged. GearDoor eliminates every one of these detection vectors simultaneously. The DNS lookup is to drive.google.com. The IP is Google's. The TLS certificate is valid and expected. The traffic volume is consistent with normal cloud storage use. The only signal left is behavioral — and behavioral detection requires a fundamentally different security architecture than signature or reputation-based approaches.

This is not an accident. It is a deliberate architectural choice by a threat group that has been operating since at least mid-2024, targeting government entities across Southeast Asia and Europe with a level of operational discipline that reflects both significant resources and an intimate understanding of where enterprise security tools have blind spots.

Silver Dragon: APT41's Newest Operational Arm

Silver Dragon is a newly designated activity cluster tracked by Check Point Research, assessed with high confidence to be operating within the umbrella of APT41 — the prolific Chinese state-sponsored group that has been active since at least 2012 under a rotating roster of aliases including Winnti, Wicked Panda, Brass Typhoon, Double Dragon, and BARIUM. APT41 is notable for running simultaneous espionage and financially motivated operations, a dual mission that sets it apart from many of its nation-state peers.

What APT41's dual mission means operationally
APT41 is one of the few state-sponsored threat actors documented to run both strategic intelligence collection and financially motivated cybercrime operations in parallel. The espionage arm targets governments, defense contractors, and critical infrastructure for geopolitical intelligence. The financial arm has hit gaming companies, cryptocurrency exchanges, and financial institutions. This dual-use structure means the group maintains a broader range of capabilities than purely state-directed actors — and that tools developed for espionage occasionally appear in financially motivated campaigns and vice versa. Silver Dragon sits squarely on the espionage side, but its tools reflect the same engineering investment visible across the entire umbrella.

Silver Dragon fits the espionage side of that profile. Confirmed targets include government entities in Russia, Poland, Hungary, and Italy across Europe, and Japan, Myanmar, and Uzbekistan in Southeast Asia. The campaign appears to have begun in mid-2024 and remained active through early 2026. The targeting pattern — government ministries across geopolitically significant regions — points squarely to strategic intelligence collection rather than financial crime.

A question the technical record leaves partially open is which specific vulnerabilities Silver Dragon exploited to gain that initial server access. The article does not name specific CVEs — but the picture is not entirely blank. The Italian National Cybersecurity Agency independently documented a very similar infection chain following what it described as the "ToolShell exploitation wave" in July 2025, a reference to a widely reported vulnerability in SharePoint and related Microsoft services — covered in detail in NoHackie's analysis of the ToolShell SharePoint exploitation chain — that was actively targeted by multiple China-linked groups in that period. The implication is that Silver Dragon was among the groups weaponizing that wave, using broadly exploited vulnerabilities in internet-facing infrastructure as an opportunistic door rather than investing in zero-day development for initial access. This pattern — relying on widely available exploits for the first foothold while reserving custom engineering for post-exploitation — is consistent with how APT41 has operated historically. The sophistication is concentrated where it matters most for long-duration access: after the door is open. Tradecraft

Why the initial access method matters for defenders
A group that uses zero-day vulnerabilities for initial access requires a fundamentally different defensive posture than one relying on known, patchable vulnerabilities. Silver Dragon's reliance on widely exploited server vulnerabilities — rather than custom zero-days — means that timely patching of internet-facing infrastructure is a directly relevant control, not an abstract best practice. The ToolShell exploitation wave that appears in the Italian ACN reporting was linked to vulnerabilities for which patches existed. Organizations that had applied those patches before mid-2025 were not accessible via that route. This is a meaningful defensive lever: while Silver Dragon's post-exploitation toolkit is sophisticated enough to resist detection once it is inside, blocking that initial entry through diligent patch management can prevent the entire chain from starting. The group's patience and tooling sophistication should not obscure the fact that it still needs an unlocked door.
Check Point Research characterizes Silver Dragon as "a well-resourced and adaptable threat group" that continuously tests and deploys new capabilities across campaigns, using diverse exploits, custom loaders, and sophisticated file-based C2 communication. Check Point Research, March 2026

The attribution to APT41 rests on two primary pillars. First, Check Point identified strong tradecraft overlaps between Silver Dragon's post-exploitation installation scripts and those previously documented in confirmed APT41 operations — specifically, a nearly identical command sequence for registering a DLL-based loader as a Windows service that aligns with APT41 tradecraft documented by Mandiant as far back as 2020. Second, the decryption mechanism embedded in Silver Dragon's BamboLoader matches shellcode loader patterns consistently linked to China-nexus APT activity. Neither overlap is coincidental, and together they give researchers high confidence that Silver Dragon is not an independent actor but an operational arm of a well-established program.

Sergey Shykevich, Threat Intelligence Group Manager at Check Point Software, observed that Silver Dragon hides "inside trusted Windows services and widely used platforms like Google Drive," and that this research proves security teams can no longer treat cloud traffic or core OS components as inherently safe. — Sergey Shykevich, Check Point Software — via Cybernews, March 2026

Silver Dragon is one of several subgroups that have emerged from what analysts now treat as an APT41 "umbrella." The group has a long track record of spinning up operationally distinct clusters that share tooling and tradecraft while pursuing their own target sets — a structure that complicates attribution and allows the parent organization plausible deniability. Each subcluster can be wound down or rebranded while the underlying infrastructure and personnel persist.

The tactical value of the umbrella structure for the Chinese state
When a specific threat cluster is publicly identified and attributed, the Chinese government's standard response is denial — and the umbrella structure makes that denial operationally viable. A named cluster like Silver Dragon can be allowed to go dormant, its infrastructure can be abandoned, and the same personnel and capabilities can re-emerge under a new designation with new tooling. Intelligence agencies and security researchers must then rebuild attribution from scratch. The underlying program never actually stops. This is a structurally different problem from tracking a static actor: it requires tracking techniques, tradecraft, and code-level similarities across discontinuous naming conventions.

How GearDoor Works

GearDoor is the technical centerpiece of Silver Dragon's post-exploitation toolkit. It is a .NET backdoor, meaning it runs on the .NET Framework that ships with Windows by default — no additional runtimes or unusual dependencies required on target machines. Its design is elegant in a threat-actor sense: rather than establishing a direct connection to attacker-controlled infrastructure that might be flagged by threat intelligence feeds, firewall rules, or DNS reputation systems, GearDoor conducts all of its operations through a Google Drive account controlled by the operators. LOTS

The mechanics work like this. When GearDoor executes on a compromised host, it authenticates to a pre-configured Google Drive account using hardcoded credentials embedded in the binary. It then creates a dedicated folder for that specific victim machine. The folder name is not random — it is derived from a SHA-256 hash of the machine's hostname, formatted as a GUID-like string using hyphens. Every infected machine gets its own unique, consistently named folder in Drive, allowing operators to manage many victims simultaneously without confusion or cross-contamination of data.

What deterministic folder naming reveals about operational scale
Using a SHA-256 hash of the hostname as the folder identifier is an elegant operational solution to a scale problem. If you are running implants across dozens or hundreds of targets, you need a way to consistently identify which Drive folder belongs to which victim — without maintaining a separate lookup table that could itself be compromised. The hash gives you a collision-resistant, human-unreadable, consistent identifier that is reproducible from the hostname alone. It also means that if operators lose access to their records, they can recalculate the correct folder name for any known victim. This level of operational engineering is not present in commodity malware.

Once that folder exists, GearDoor begins its operational routine by uploading a heartbeat file — a small document containing basic system information that tells the operators the implant is alive and accessible. From that point forward, all task assignments and results flow through file uploads and downloads. The file extension determines what kind of action the malware takes, turning ordinary-looking cloud file transfers into a fully functional command interface.

This architecture raises a question that the Check Point disclosure creates directly: when GearDoor's hardcoded Google credentials become public knowledge, what happens to the active implants still running on compromised hosts? The answer is more complicated than it might appear. Publishing the credential hashes or partial credential strings in an indicator release allows Google and defenders to identify and terminate the specific Drive accounts used in the campaign — and Google has previously taken exactly this kind of action against APT41 infrastructure, including terminating attacker-controlled Workspace projects documented during the VOLDEMORT campaign. But terminating the accounts does not remove the implant from the victim machine. GearDoor's self-update capability, delivered via the .rar command extension, means that as long as operators can reach even one active implant, they can push a fresh binary with new credentials before the old ones are burned. The race between disclosure and remediation is real — and the group's documented active development between versions suggests they anticipated needing to rotate infrastructure. Tradecraft

What Google can actually do — and what it cannot
Google can terminate the specific Drive accounts used by GearDoor's operators once they are identified. It can also use its threat intelligence sharing relationships with security researchers to act on disclosed indicators quickly. What Google cannot do is remove malware from victim machines — that requires the victim organization's own incident response. This creates a gap: even after Google terminates an attacker-controlled Drive account and breaks the active C2 channel, an organization that has not investigated and remediated the underlying infection still has a dormant GearDoor implant on its machines. The implant will fail to beacon — and may be mistaken for clean. When Silver Dragon rotates credentials and resumes operations under a new Drive account, those un-remediated implants can be reactivated. The disclosure is a disruption, not a cure. Organizations in the confirmed target geography should treat credential termination as a trigger to begin incident response, not as evidence that the threat has passed.
GearDoor File-Extension Command Protocol select an extension
.png
Heartbeat
.pdf
Command execution
.cab
Reconnaissance
.rar
Payload delivery
.7z
In-memory plugin
.png
Heartbeat — Implant Health Signal

The heartbeat file is uploaded periodically by GearDoor to confirm the implant is alive and reachable. It contains basic system information about the compromised host. To any proxy or DLP tool monitoring outbound traffic, this looks like a PNG image being uploaded to Google Drive — a completely routine enterprise event.

The heartbeat pattern itself is worth noting for defenders: GearDoor's uploads will be more temporally regular than human-generated Drive activity, because they are driven by a timer rather than user behavior. Proxy logs that capture upload frequency per process can potentially distinguish automated beaconing from organic use.

Uploads system info to Drive folder
.pdf
Command Execution — Task Delivery & Results Return

Operators place a .pdf file in the victim's Drive folder to deliver commands. GearDoor polls for new files, downloads the .pdf, decrypts its contents (using DES with a key derived from an MD5 hash of a hardcoded string), and executes the instructions — which can include running arbitrary commands, listing directory contents, or creating and removing directories.

Results are returned as a .db file uploaded back to the same Drive folder. The entire exchange — operator sends PDF, malware executes, malware uploads results as DB — looks like routine file sharing activity across a legitimate cloud storage account.

Results returned as .db file
.cab
Reconnaissance — Host Enumeration & Tasking

The .cab extension triggers the most comprehensive reconnaissance capability. GearDoor gathers host information, enumerates running processes, lists files, and can run commands via cmd.exe or scheduled tasks. Collected data is uploaded back to Drive for operator review.

This is the phase that gives operators a full situational picture of a compromised environment: what is running, what files exist, what the network looks like from inside the victim's machine. It mirrors the manual triage phase of a human attacker, automated and exfiltrated through what looks like a cabinet archive upload.

Enumeration data uploaded to Drive
.rar
Payload Delivery — Implant Update & Tool Drop

The .rar extension is used for payload delivery: dropping new tools onto the compromised host, or triggering a self-update of the GearDoor implant itself. This is how Silver Dragon can push new capabilities to already-compromised environments without re-exploiting the initial access vector.

The self-update capability is particularly significant: it means Check Point's disclosure of GearDoor's architecture and commands does not render the implant obsolete. Silver Dragon can modify the command protocol, add new extensions, change encryption keys, and push the updated binary to all active implants through the same Drive channel. Active tool development between GearDoor versions is already documented.

Drops or updates payloads on host
.7z
In-Memory Plugin Execution — Fileless Operation

The .7z extension triggers the most forensically evasive capability: running a .NET plugin entirely in memory, leaving no file on disk for endpoint detection tools to find. The plugin is loaded from the Drive-delivered file directly into the running process — it executes its function and disappears when the process ends, with no persistent artifact.

This capability is the logical endpoint of the LOTS architecture: not only is the C2 channel invisible at the network layer, but the payloads can execute invisibly at the host layer as well. Forensic investigators examining a compromised machine post-incident may find little evidence of what was run or what data was accessed during in-memory execution phases.

No disk artifact — memory only

The encryption layer underneath all of this is not trivial. Configuration data and all file-based communication with Google Drive are encrypted using DES. The encryption key is derived from the first eight characters of the MD5 hash of a hardcoded key string embedded in the binary. On top of that, GearDoor shares a Brainfuck-based string obfuscation technique with MonikerLoader — another tool in Silver Dragon's arsenal — which complicates static analysis and makes signature-based detection significantly harder. Code-level similarities between GearDoor and MonikerLoader samples also helped Check Point analysts tie the two tools to the same development environment, reinforcing the attribution case. Tradecraft

Why Brainfuck-based obfuscation matters for detection
Brainfuck is an esoteric programming language whose syntax consists entirely of eight single-character operators. Using its logic to obfuscate string constants means that static analysis tools looking for readable string artifacts — file paths, command keywords, encryption keys — will not find them in the binary in any recognizable form. The strings only become readable after the Brainfuck interpreter runs at execution time. This significantly raises the cost of static analysis: analysts cannot simply search for strings in the binary. They need to either execute the sample in a controlled environment or reverse-engineer the custom interpreter. The shared use of this specific technique across GearDoor and MonikerLoader is a strong code-provenance indicator that both tools came from the same developer or development environment.

Check Point notes that GearDoor's command set has evolved between versions, with some commands added and others removed. This is a meaningful signal: it indicates the group is not deploying a finished, static tool but actively developing and refining it based on operational experience — a hallmark of a professional, well-resourced threat program rather than a one-off campaign.

Check Point's blog notes that GearDoor's file-based model reflects "a broader trend in advanced threat operations: abusing trusted platforms to reduce detection risk" — with Google Drive traffic routinely permitted in enterprise environments, making the malicious communication effectively invisible. Check Point Research blog, March 2026

Three Ways In: The Infection Chains

GearDoor does not arrive on a victim system by itself. Silver Dragon uses three distinct infection chains to gain initial access and establish the foothold that eventually enables GearDoor's deployment. All three ultimately deliver Cobalt Strike as an intermediate payload before the group transitions to its custom tools for longer-term, quieter access. The group also employs DNS tunneling as an additional C2 mechanism — layering communication channels so that if one is disrupted, others remain available. Toolkit

Infection Chain Comparator — Select a Chain
Chain 01
AppDomain Hijacking
MonikerLoader
Chain 02
Service DLL Hijacking
BamboLoader
Chain 03
Phishing LNK Files
BamboLoader + DLL sideload
RAR archive
Delivery
Malicious .config
AppDomain hijack
MonikerLoader
In-memory decrypt
Cobalt Strike
Beacon (memory)
GearDoor
Persistent C2
The attack arrives as a RAR archive containing a malicious .config file designed to sit alongside a legitimate Windows binary such as dfsvc.exe or tzsync.exe. By overwriting the AppDomain entry point, attackers redirect execution to MonikerLoader every time the legitimate binary runs. MonikerLoader decrypts a second-stage payload entirely in memory, which then loads a Cobalt Strike beacon — also in memory. The entire chain produces minimal disk artifacts and rides on the authority of a legitimate Windows process. The Italian National Cybersecurity Agency independently observed a very similar chain following the ToolShell exploitation wave in July 2025, corroborating Silver Dragon's reach into European government networks.
File Paths (IOC)
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ (.config and DLL files) C:\Windows\AppPatch\ (shellcode file)
Batch script
Delivery
Delete legit service
Service impersonation
BamboLoader DLL
Recreated service
Cobalt Strike
Injected into taskhost.exe
GearDoor
Persistent C2
A batch script stops and deletes a legitimate Windows service, then recreates it pointing to BamboLoader — a heavily obfuscated x64 C++ DLL. Services impersonated include Windows Update, Bluetooth, and .NET Framework utilities. The recreated service entry is difficult to distinguish from the original without comparing the DLL path against a known-good baseline. BamboLoader decrypts shellcode and injects it into taskhost.exe, so the Cobalt Strike beacon runs inside a trusted system process. Event IDs 7045 (service creation) and 7034 (service crash) in Windows Security logs are the detection surface.
File Paths (IOC)
C:\Windows\System32\wbem\ (BamboLoader DLL) C:\Windows\Fonts\ (encrypted shellcode payload)
Malicious LNK file
Phishing email
PowerShell
Extracts components
DLL side-load
Signed binary cover
Cobalt Strike
Trusted process
GearDoor
Persistent C2
The only chain that does not require a previously compromised server. A targeted phishing email delivers a malicious Windows shortcut (.LNK) file formatted to look like official government correspondence. Documented cases primarily targeted government entities in Uzbekistan. On execution, a PowerShell command extracts several embedded components: a decoy document displayed to the victim, a legitimate signed executable, BamboLoader, and an encrypted Cobalt Strike payload. The side-loading technique executes the beacon under a trusted process signature. The decoy document display prevents immediate suspicion — the victim sees what appears to be a legitimate government file while the infection chain runs silently in the background.

The nature of those decoy documents is not incidental. Check Point's analysis notes that the lures were formatted to resemble official government correspondence relevant to the specific target country — the kind of document a government employee in Uzbekistan would plausibly receive and open without hesitation. This is a meaningful tradecraft distinction from mass phishing: Silver Dragon constructs decoys that are contextually credible to their specific target, which requires either prior reconnaissance of the target's work context or access to genuine government document formats as templates. A decoy that looks wrong to the recipient breaks the chain before execution. A decoy that looks routine completes it. This is why phishing awareness training for government personnel in targeted countries cannot be generic — it needs to specifically address the pattern of receiving official-looking correspondence as an attachment from an external sender, and establish clear internal verification channels for documents that appear to originate from government or partner institutions.
Detection Signal
LNK file executing PowerShell to extract and run embedded DLL components Signed binary loading unexpected DLL from same directory
Automated Payload Generation

Check Point found that all files within the initial archives shared identical creation timestamps — a strong indicator of an automated payload generation framework rather than manual assembly. A recovered log file from one archive explicitly documented per-attack configuration parameters: file paths, service names, encryption keys, and target process names. This suggests Silver Dragon operates infrastructure capable of generating customized attack packages at scale for each individual target, rather than reusing identical binaries that would be easier to detect by hash. Tradecraft

The Broader Toolkit: SilverScreen and SSHcmd

GearDoor is the most technically distinctive component of Silver Dragon's arsenal, but it operates alongside two other custom tools documented by Check Point that together form a complete, purpose-built post-exploitation platform.

GearDoor
Persistent covert C2
The Drive-based backdoor. Handles all command-and-control through file uploads and downloads to a Google Drive account. Encrypted via DES, obfuscated via Brainfuck-based strings. The long-duration, stealthy access layer.
SilverScreen
Passive intelligence collection
A covert .NET screen-monitoring implant. Captures screenshots across all connected displays, including precise cursor position. Uses grayscale thumbnail comparison to detect meaningful visual changes before triggering full-resolution capture — minimizing bandwidth and storage. Handles the SYSTEM-to-desktop session gap via token impersonation. Named internally as ComponentModel.dll to mirror .NET assembly naming conventions.
SSHcmd
Interactive operations
A lightweight .NET SSH wrapper for executing commands and transferring files. Provides a lower-latency, hands-on access channel when operators need to act quickly rather than waiting for the Drive polling cycle.

This is not a loosely assembled collection of off-the-shelf tools — it is a coherent, custom-built platform designed for sustained espionage inside high-value government networks. GearDoor provides persistent, covert command access. SilverScreen passively documents what users are doing without generating the high-volume data streams that anomaly detection might flag. SSHcmd enables interactive operations when the situation demands rapid response. Each tool addresses a different operational need, and together they constitute everything a nation-state operator needs to run a long-duration intelligence collection mission inside a government network. Toolkit

Why purpose-built platforms signal high-resource investment
Commodity threat actors use off-the-shelf tools: Cobalt Strike, Mimikatz, public exploit frameworks. These tools are well-documented and detectable. Building a custom platform with three coordinated, purpose-specific tools requires sustained engineering investment, operational security discipline to avoid code reuse that enables attribution, and a long-term commitment to maintaining the toolset across multiple campaigns. The presence of a custom platform is a reliable indicator of nation-state resources — and it signals that the group intends to conduct operations at this level of sophistication for years, not months.

SilverScreen's change-detection mechanism deserves particular attention. The tool only captures a full-resolution screenshot when significant visual changes are detected on screen, rather than at fixed intervals. This limits bandwidth and storage requirements while still providing operators with a detailed, contextual view of what users are doing. When a government employee opens a restricted document or accesses a sensitive system, SilverScreen captures it without generating the kind of high-volume data stream that anomaly detection tools might flag.

The intelligence value of change-triggered screenshots
A screenshot tool that fires constantly produces noise — mostly captures of idle desktops or screens that haven't changed. Change-triggered capture solves this by firing specifically when something interesting is happening: a document being opened, a form being filled, a system being accessed, a conversation being read. The resulting dataset is not a raw video feed but a curated record of meaningful user actions. From an intelligence collection perspective, this is more valuable than constant capture because it is already filtered for significance. For defenders, detecting this tool requires looking for periodic, low-frequency, process-level screenshot API calls rather than the high-frequency patterns more common in commodity spyware.

APT41's Long History of Cloud Abuse

GearDoor's use of Google Drive as a C2 channel is not Silver Dragon's invention, and it is not APT41's first experiment with the concept. Understanding how this technique fits into the group's broader history reveals a deliberate, multi-year commitment to what threat intelligence researchers now call "Living off Trusted Sites" (LOTS) — a category of evasion that treats legitimate cloud platforms as operational infrastructure rather than as targets. LOTS

LOTS as a strategic doctrine, not a tactical trick
"Living off Trusted Sites" is the cloud-era evolution of "Living off the Land" — the practice of using legitimate system tools rather than custom malware to avoid detection. LOTS takes this further: instead of just using the victim's own tools, it uses the victim's trusted cloud services as the attacker's own infrastructure. The reason this is a doctrine rather than a trick is that it requires architectural commitment: you build your entire C2 stack around a cloud service, which means you cannot easily fall back to traditional C2 infrastructure if the technique is burned. APT41's sustained investment in this approach across multiple campaigns and multiple cloud services — Google Sheets, Google Drive, Google Calendar, Microsoft OneDrive, Cloudflare Workers — signals that this is now a core operational philosophy, not an experiment.
APT41 Cloud Abuse History — A Multi-Year Pattern
April 2023
Google Sheets + Google Drive
Google Cloud CISO Threat Horizons Report documents APT41's use of Google Sheets and Google Drive for malware C2. This is the first major public documentation of the group treating Google's own infrastructure as an attack channel rather than a target.
Mid 2024
Google Workspace + Cloudflare Workers
DUSTTRAP campaign documented by Mandiant and Google's Threat Intelligence Group. APT41's post-exploitation framework communicates with compromised Google Workspace accounts. Cloudflare Workers are used as C2 proxies for Cobalt Strike beacons. Cloudflare is also used directly as a C2 channel, giving the group multiple fallback options if any single channel is disrupted.
Mid 2024
Cloud services (delivery + C2)
VOLDEMORT malware family attributed to APT41 by Proofpoint. Abuses cloud services for both delivery and C2. Google identifies and terminates the attacker-controlled Workspace projects, dismantling that campaign's infrastructure — but the technique remains available and is reused in subsequent operations.
Late October 2024
Google Calendar
TOUGHPROGRESS — a three-stage, memory-only loader — takes the cloud abuse concept to its logical extreme. All C2 operates through Google Calendar: zero-minute events at hardcoded dates carry encrypted host data in description fields. Operator commands arrive as new calendar events; TOUGHPROGRESS polls for them, decrypts and executes them, writes results back as new events. The entire command loop exists inside a legitimate Google Calendar account.
2024–2026
Google Drive (file-extension C2)
GearDoor / Silver Dragon — the current documented iteration. Victim-specific folders identified by SHA-256 hostname hashes. All C2 communication encoded in file extensions and encrypted file contents. Active tool development documented between versions. The Virus Bulletin analysis of related family Calendarwalk found APT41 had also abused Google Calendar events through Windows Workflow Foundation's XOML execution capability — assessed as the first documented instance of an APT using that specific technique in a real-world scenario.
Documented across campaigns
Microsoft OneDrive + public forum dead drops
Mandiant and Google GTIG document APT41 using Microsoft OneDrive for large-scale data exfiltration via PINEGROVE, and public community forum posts as "dead drop resolvers" — where malware fetches its true C2 address from an encoded message in a public post, so the only visible DNS lookup is to a legitimate website. The LOTS doctrine extends beyond Google's own services. (source: Mandiant / Google GTIG, July 2024)

What emerges from all of this is not a series of isolated experiments but a consistent strategic doctrine: APT41 invests significant engineering effort in routing its malicious traffic through platforms that organizations trust, need, and cannot inspect without creating meaningful operational friction. GearDoor and Silver Dragon are the current expression of that doctrine — and if history is any guide, the next iteration is already in development. LOTS

Why This Matters for Defenders

The conventional mental model for detecting command-and-control traffic assumes malicious traffic goes somewhere suspicious — an IP address with poor reputation, a recently registered domain, a geographic region inconsistent with the organization's business. GearDoor invalidates all of those assumptions simultaneously. The traffic goes to Google. The IP addresses are Google's. The domain is drive.google.com. There is nothing anomalous to detect at the network layer using traditional indicator-based methods. Blind spot

What the mental model failure costs in practice
Security teams that have invested heavily in threat intelligence feeds, domain reputation systems, and IP blocklists have built defenses against the previous generation of C2 infrastructure. That investment is not wasted — it is effective against the commodity threat actors who still use traditional infrastructure. But against GearDoor, it produces a false sense of security: the dashboard shows no suspicious outbound connections because every connection looks legitimate. The absence of alerts is not evidence of safety. It is evidence that the detection model is not designed for this threat class. Recognizing that gap is the first step toward addressing it.

This shifts the detection problem from network indicators to behavioral indicators — and behavioral detection is significantly harder to operationalize at scale. Several specific approaches are available to defenders, even when traditional network monitoring fails. Organizations already familiar with how attackers disable endpoint detection tools at the kernel level will recognize the pattern: when perimeter and endpoint defenses are bypassed by design, behavioral analytics become the last viable detection layer.

Detection Framework — When Network Indicators Fail
01
Process-to-Network Correlation
Behavioral
02
Windows Service Auditing
Event Log
03
AppDomain Hijack Detection
File Integrity
04
Proxy Behavioral Analysis
Network
Detection Surface 01 — Process-to-Network Correlation

GearDoor is a .NET process. If a .NET process that is not a recognized business application is making repeated, periodic HTTPS connections to Google Drive — especially with a consistent timing pattern resembling beaconing — that warrants investigation. SIEM platforms with behavioral analytics can model this, but only if the baseline of legitimate .NET-to-Drive traffic is already well understood.

The key behavioral signature is regularity: GearDoor's heartbeat and polling cycles are timer-driven, not user-driven. Human Google Drive usage is irregular and bursty. Automated C2 polling is steady and periodic. Proxy logs that capture connection timestamps and file transfer sizes per-process can reveal this pattern even when the destination is legitimate.

T1567.002 — Exfiltration to Cloud Storage T1071.001 — Application Layer Protocol: Web
Detection Surface 02 — Windows Service Auditing

BamboLoader achieves persistence by stopping a legitimate Windows service, deleting it, and recreating it pointing to a malicious DLL. This is detectable. Windows Security event logs capture service creation and deletion events. Any service that is deleted and immediately recreated under the same name — particularly services like Windows Update, Bluetooth, or .NET Framework utilities — warrants immediate investigation.

A service audit baseline of known-good service DLL paths is essential here. The recreated service will have the correct name but an incorrect DLL path, pointing to a file in C:\Windows\System32\wbem rather than the expected system path. Without a baseline, the malicious service entry is nearly indistinguishable from the legitimate original.

T1543.003 — Windows Service Event ID 7045 — Service Created Event ID 7034 — Service Crashed
Detection Surface 03 — AppDomain Hijack Detection

MonikerLoader's attack relies on placing a malicious .config file alongside a legitimate Windows binary to redirect AppDomain execution. File integrity monitoring on the directories where these files land would catch this modification. Changes to .config files in C:\Windows\Microsoft.NET\Framework64\v4.0.30319 outside of patch windows should trigger an alert — legitimate software updates to these paths are rare and scheduled, not ad hoc.

Similarly, unexpected files appearing in C:\Windows\AppPatch (where the shellcode file is placed) should be flagged. Both paths are obscure enough that most endpoint monitoring configurations do not specifically watch them — which is precisely why Silver Dragon chose them.

T1574.014 — AppDomain Manager Injection File Integrity Monitoring — .NET config paths
Detection Surface 04 — Proxy Behavioral Analysis

While GearDoor's traffic looks legitimate at the protocol level, the behavioral pattern — periodic heartbeat uploads, command retrieval, result uploads — produces a traffic signature different from human Drive usage. Automated, process-generated Drive traffic tends to be more temporally regular and more consistent in file size distribution than human-generated activity.

Proxy logs that capture user-agent strings, transfer sizes, and the process generating the connection may reveal processes generating Drive traffic that no recognized user or application would produce. Critically, Check Point's defensive guidance specifically recommends monitoring cloud storage traffic for unusual automated upload patterns originating from non-browser processes — this is the clearest practical signal available.

Organizations using Google Workspace can also check for unfamiliar Google account authentications from managed device processes — GearDoor's hardcoded Google credentials will authenticate from the victim machine, which may appear in Google's own access logs as an unusual service account access pattern.

T1567 — Exfiltration Over Web Service Non-browser process Google Drive auth
Defensive Actions Recommended by Check Point Research

Monitor cloud storage traffic — particularly Google Drive — for unusual automated upload patterns originating from non-browser processes. Audit Windows services for entries that mimic legitimate system names, especially services that were recently deleted and recreated. Enable detection for AppDomain hijacking (MITRE ATT&CK T1574.014). Implement phishing awareness training specifically for government personnel in Southeast Asia and Europe. Block and monitor all C2 domains and file hashes published in the Check Point Research disclosure at the network perimeter.

The broader policy implication is uncomfortable but important: organizations cannot simply trust a platform because it is well-known. The security posture that says "we allow Google Drive because we trust Google" conflates infrastructure trust with traffic trust. Google's infrastructure is trustworthy. The files and processes moving across that infrastructure may not be. Inspecting the behavior of processes that generate Drive traffic — rather than simply allowing any traffic destined for Google's IP ranges — is the conceptual shift that defenders need to make. As long as enterprise security architecture treats "going to Google" as a free pass, threat actors will continue to use Google as a highway. Blind spot

The infrastructure trust vs. traffic trust distinction
When a security team says "we trust Google," they mean two different things simultaneously: they trust Google's servers not to be malicious infrastructure, and they trust that traffic to Google's servers is not malicious activity. The first statement is true. The second is no longer valid. Google's servers are not the attacker's servers — but Google's services are carrying the attacker's commands. The distinction matters for policy: you cannot and should not block drive.google.com. But you should be inspecting which processes on your network are generating traffic to it, how often, in what patterns, and whether any of those processes are ones you recognize and authorized. This is process-level behavioral monitoring, not perimeter-level IP blocking, and it requires a different toolset and mindset.

Sources

This article is based on original primary source research and peer reporting. All technical claims are sourced to the documents below.

Key Takeaways

  1. GearDoor turns Google Drive into a covert command channel. By routing all C2 communication through a legitimate Google account, Silver Dragon eliminates the network indicators that traditional defenses depend on. There are no suspicious IP addresses, no newly registered domains, and no unusual geographies — only normal-looking cloud storage traffic that enterprise security tools are configured to ignore. LOTS
  2. Silver Dragon operates with APT41's resources and discipline. The automated payload generation framework, the multi-stage infection chains, the active tool development between GearDoor versions, and the geographic breadth of targeting all point to a well-funded, professionally operated program. This is not opportunistic activity — it is a sustained intelligence collection campaign. Tradecraft
  3. APT41 has been systematically abusing Google services for years. GearDoor is one entry in a documented pattern that includes Google Sheets, Google Drive, Google Calendar, and Google Workspace accounts, as well as Microsoft OneDrive and Cloudflare. Each iteration refines the same core strategy: hide malicious traffic inside platforms that organizations cannot afford to block. LOTS
  4. Behavioral detection must compensate where network detection fails. When adversaries route their traffic through trusted cloud services, signature-based and reputation-based network defenses become ineffective. Process-to-network correlation, service audit logging, file integrity monitoring on .NET directories, and proxy-layer behavioral analytics are the practical detection surfaces available to defenders. Blind spot
  5. Government entities in Europe and Southeast Asia are the confirmed target set — for now. Silver Dragon's current targeting is geopolitically focused, but the tooling and techniques it uses are applicable to any environment running Google Workspace and Windows. Organizations outside the confirmed target geography should treat this as a preview of methods likely to be adopted by other threat actors as the technique matures. Toolkit

The threat that Silver Dragon and GearDoor represent is not simply a new piece of malware. It is a demonstration that the security assumptions built into most enterprise network architectures — that traffic to well-known, legitimate platforms is safe traffic — are increasingly invalid. The same cloud services that make organizations more productive are being turned into operational infrastructure by threat actors who understand that the fastest path through a firewall is one the firewall has been configured to ignore. Closing that gap requires a fundamentally different way of thinking about what "trusted" means in a cloud-first world — and Silver Dragon is unlikely to be the last group to exploit the gap while defenders catch up.

← all articles