RATs & Socks: Abusing Google Services

RATs & Socks: Abusing Google Services for Command and Control

Speakers: Valerio Alessandroni

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=cXZJlKLBBGE

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Valerio%20Alessandroni%20-%20RATs%20%26%20Socks%20abusing%20Google%20Services.pdf

Overview

Legitimate cloud services have increasingly become the preferred communication backbone for sophisticated malware — a technique sometimes called "living off trusted services" (LOTS). By channeling command and control (C2) traffic through platforms like Google Drive, Google Calendar, or Gmail, attackers can blend malicious traffic into the enormous volume of legitimate Google API communication that traverses any enterprise network, defeating domain-based blocklists and many network-level detection approaches.

Valerio Alessandroni, an offensive security lead at Haiku Italy, presents a two-part talk based on his own research and tooling. The first tool — Google Calendar RAT, released in 2023 and later adopted by real threat actors — uses Google Calendar as a covert C2 channel. The second, newer research introduces a SOCKS5-over-Google-Drive proxy that extends the attacker's capability from simple command execution to arbitrary TCP/IP tunneling through Google's infrastructure.

The talk provides a technical deep dive into both tool architectures, discusses the real-world adoption of the calendar C2 by APT41 (according to a Google Cyber Security Action Team threat horizon report), and examines what defenders can and cannot do against this class of attack.

Background

▶ Watch: Part 1: Google Calendar RAT — using calendar events as a C2 channel (0:58)

Living Off Trusted Services (LOTS)

The LOTS technique category exploits the fact that enterprise security infrastructure — firewalls, DNS filters, proxy systems, and network detection — relies heavily on domain and IP reputation to distinguish legitimate from malicious traffic. Cloud platform traffic to .googleapis.com, .google.com, and associated CDN infrastructure is almost universally allowed and rarely inspected with deep packet inspection or behavioral analysis, because the volume is enormous and the domains are among the most trusted on the internet.

Attackers who route their C2 traffic through Google APIs gain:

• Firewall bypass: Traffic to Google's API endpoints is allowed on virtually every enterprise and consumer network
• TLS encryption: All Google API traffic is TLS-encrypted, preventing content inspection by network monitors
• Domain trust: Reputation-based detection systems see traffic to highly trusted Google domains and do not flag it
• Infrastructure cost reduction: Google provides scalable, reliable cloud infrastructure for free (within quota limits), eliminating the need to maintain C2 server infrastructure

Prior research and known malware have used Dropbox, GitHub, Telegram, Slack, and Pastebin as C2 channels. Alessandroni's contribution is a detailed implementation using Google's specific services and a thorough analysis of how these channels work operationally.

The Threat Context

Shortly after Alessandroni released Google Calendar RAT in 2023, the Google Cyber Security Action Team (GCAT) mentioned the tool by name in their Threat Horizons report as a technique being evaluated and used by threat actors. More significantly, approximately two years later (around April 2025), APT41 — one of the most prolific and technically sophisticated state-sponsored threat groups, linked to Chinese intelligence — was observed using a similar Google Calendar-based C2 technique in the wild. This real-world adoption of the technique underscores its operational relevance.

Key Findings

▶ Watch: Demo setup: establishing bidirectional C2 over Google Calendar API (4:58)

Google Calendar RAT — Architecture and Operation

The Google Calendar RAT is a post-exploitation tool that uses a Google Calendar event as a shared communication channel between an attacker and an implant deployed on a target machine.

How it works:

1. The attacker creates a Google Calendar event with a specific, shared calendar
2. The attacker places a command in the event's description field (or title field)
3. The implant deployed on the target machine polls the calendar via the Google Calendar API at a configurable interval
4. The implant reads the command from the event description, executes it locally, and writes the output back to another field in the same event (or to a new event)
5. The attacker reads the output from the calendar event

The communication channel is the Google Calendar API, which operates over HTTPS to www.googleapis.com. Both the implant and the attacker authenticate to the calendar with the same Google account credentials (or a service account).

Key operational characteristics:

• The implant requires Google API credentials (OAuth token or service account key) — these are embedded at deployment time and can be rotated if discovered
• The polling interval is configurable; longer intervals reduce detection risk but increase command latency
• The calendar data is not encrypted end-to-end by default (Google can read it), but in practice Google's detection of the malicious use has relied on external reports rather than content inspection
• The original tool was implemented in Python, making it easily portable and modifiable

Two fields used for communication:

• Title: Can be used for short commands or identifiers
• Description: Used for longer command content and output

Alessandroni notes that Google Calendar has rate limits on API calls, which constrains polling frequency but does not prevent the technique from being operationally useful.

SOCKS5-over-Google-Drive Proxy

The more novel research presented in the talk is a SOCKS5 proxy that tunnels TCP/IP connections through Google Drive's file upload/download API.

Why SOCKS5 matters: A SOCKS5 proxy running on the target machine allows the attacker to tunnel arbitrary TCP connections (HTTP/S, RDP, SMB, SSH, etc.) through the compromised host. This is useful for lateral movement inside the target network. A SOCKS5 proxy that uses Google Drive as its transport channel means all of the tunneled traffic is wrapped in HTTPS requests to *.googleapis.com, making it extremely difficult to detect at the network layer.

How the SOCKS5-over-Drive works:

1. The implant on the target machine accepts SOCKS5 connections from the attacker (over the loopback interface if run with port forwarding, or via another covert channel to bootstrap)
2. For each SOCKS5 connection, the implant encapsulates the TCP stream data into chunks
3. Each chunk is uploaded to a Google Drive file (or appended to an existing file) via the Google Drive API
4. The attacker's C2 software polls and downloads the uploaded chunks from Google Drive, reassembles them, and delivers the data to the waiting local TCP connection
5. Return data follows the reverse path: attacker uploads data to Drive, implant downloads and injects it into the local TCP connection

The result is a full-duplex TCP tunnel over Google Drive's HTTPS API. Latency is higher than a direct connection (each direction involves an HTTP upload and download cycle), but it is sufficient for interactive sessions like RDP or SSH.

Chunking and framing: Alessandroni describes the framing protocol used to segment TCP stream data into Drive-compatible chunks and reassemble them correctly at the other end, handling out-of-order delivery and retransmissions.

APT41 Adoption

The GCAT Threat Horizons report's mention of Google Calendar RAT as an observed technique, and the subsequent report of APT41 using a similar Google Calendar C2 in April 2025, validates the operational concept. Alessandroni discusses this adoption as evidence that the technique crossed from proof-of-concept into active threat actor toolkits, which is the key reason for presenting it publicly at DEF CON — defenders need to understand the technique to detect and defend against it.

APT41's use of a similar technique suggests independent development or adaptation of the public tool, underscoring that this is a natural evolution of the LOTS technique category rather than a one-off novelty.

Technical Deep Dive

▶ Watch: Community response: researchers missed key operational nuance in GCR release (9:00)

Google Calendar API Mechanics

The Google Calendar API exposes events via the calendars.events resource. Key operations:

• events.list — retrieve events in a calendar (used by the implant to poll for commands)
• events.patch — update event fields (used to write command output)
• events.insert — create new events (can be used to create a new communication event)

Authentication uses OAuth 2.0. The implant stores a refresh token; if the access token expires, it uses the refresh token to obtain a new one. The refresh token itself needs to be protected — if extracted by a defender, it can be revoked to kill the channel.

Polling implementation:

The implant reads the description field of events matching a specific pattern (e.g., a specific event summary or a tag in the description) and extracts commands. Command output is written back:

Google Drive API Mechanics for SOCKS Proxy

The Drive-based SOCKS proxy uses the files.create and files.get endpoints:

• The implant uploads chunks using files.create with uploadType=multipart or uploadType=resumable
• The attacker downloads chunks using files.get with alt=media
• File naming or metadata is used to sequence chunks and identify the connection and direction

The chunked upload/download introduces latency of several hundred milliseconds to a few seconds per round trip, depending on chunk size and Google's API response times. Alessandroni optimizes chunk sizing to balance throughput and API call frequency (staying within Google's rate limits while achieving acceptable latency for interactive use).

Detection Evasion Analysis

Alessandroni provides an honest analysis of the technique's evasion properties:

What this evades:

• Domain-based blocklists (Google APIs are universally allowed)
• IP reputation (Google's API IP ranges are trusted infrastructure)
• Protocol analysis (everything is standard HTTPS)
• Non-inspecting network proxies (traffic appears as normal Google API calls)

What this does NOT evade:

• Detection of the Google API credentials (OAuth tokens) in implant memory or on disk
• Behavioral analysis: Google Calendar or Drive activity from a machine that doesn't otherwise use those services is anomalous
• Google's own abuse detection: Google can potentially identify API accounts used for C2 purposes and revoke them; Alessandroni notes that Google's detection of the technique in real-world use has been inconsistent
• Cloud access security broker (CASB) solutions that analyze Google API call patterns at the tenant level

Operational Security Considerations

For red teamers:

• Use a dedicated Google account (not linked to attacker identity) for the calendar/drive channel
• Implement beacon interval jitter to avoid predictable polling patterns
• Rotate credentials (refresh tokens) periodically or after suspected detection
• Combine with other evasion techniques (process injection, living-off-the-land execution) to avoid behavioral detection on the endpoint

Demo / Proof of Concept

▶ Watch: SOCKS5 demo: routing Metasploit/proxychains through Google Drive tunnel (12:59)

Alessandroni demonstrates both tools:

Google Calendar RAT demo:

1. A Google Calendar event is created with a command in the description field
2. The implant (running on a demo machine) polls the calendar and retrieves the command
3. The command executes and the output is written back to the event description
4. The attacker reads the output from the calendar event in a standard browser

SOCKS5 proxy demo:

1. The implant starts the Drive-based SOCKS5 proxy listener
2. The attacker configures their tooling (ProxyChains or similar) to route traffic through the SOCKS5 proxy
3. A connection is made to an internal target (e.g., an RDP session) through the proxy
4. The resulting traffic is shown as HTTPS to googleapis.com in a network capture, with no indication of RDP or other tunneled protocol content

Defensive Implications

▶ Watch: Red team application: full Windows exploitation chain through Google Drive SO... (15:02)

For network defenders:

• Implement a Cloud Access Security Broker (CASB) or equivalent solution that provides visibility into Google API calls by tenant and user — unexpected Google Calendar or Drive API activity from workstations should trigger investigation
• Consider restricting OAuth consent flows to approved Google Workspace applications within your tenant, preventing implants from authenticating with arbitrary Google accounts using the OAuth API
• Alert on Google API authentication from machine accounts or service accounts that do not normally access Calendar or Drive APIs

For endpoint defenders:

• Behavioral detection of unusual Google API library usage (e.g., google-auth, googleapiclient Python libraries spawned by non-application processes) should be included in EDR rules
• Memory scanning for OAuth refresh tokens associated with attacker-controlled Google accounts is a detection opportunity

For threat hunters:

• Review proxy/firewall logs for machines making unusually frequent or large-volume calls to www.googleapis.com/calendar/v3/ or www.googleapis.com/drive/v3/ from non-browser processes
• Google Workspace audit logs (for organizations using GSuite/Workspace) may show API access from accounts not provisioned in the tenant — though consumer Google accounts used for C2 would not appear in Workspace audit logs

For Google:

• Rate limiting, behavioral anomaly detection on API usage patterns, and rapid response to abuse reports are the platform-level mitigations. Alessandroni notes that Google has been inconsistent in detecting and disrupting calendar-based C2 accounts.

Key Takeaways

• Google Calendar and Google Drive can be used as covert C2 channels that are virtually indistinguishable from legitimate Google API traffic at the network layer, bypassing domain and IP reputation-based detection.
• The Google Calendar RAT tool released by Alessandroni in 2023 was acknowledged by Google GCAT and subsequently adopted by APT41 in 2025, validating the technique's operational effectiveness.
• A SOCKS5 proxy over Google Drive provides arbitrary TCP/IP tunneling through Google's infrastructure, enabling lateral movement that is fully encapsulated in trusted HTTPS traffic.
• Detection requires endpoint-level or CASB-level visibility into Google API usage by process and account — network-layer detection alone is insufficient.
• Both tools are released open-source to enable defensive research and to allow blue teams to develop and test detection capabilities.

About the Speaker

Valerio Alessandroni is an Offensive Security Lead at Haiku Italy, with a background in penetration testing and red teaming. He developed the Google Calendar RAT in 2023 as a research project aimed at exploring creative C2 infrastructure options, reducing operational costs, and testing defense bypass capabilities. The tool gained notoriety when mentioned in the Google GCAT Threat Horizons report and subsequently in APT41 threat intelligence. He presented this research at DEF CON 33 as a comprehensive public accounting of both tools and their defensive implications.