Hero image generated by ChatGPT
This is a personal blog and all content herein is my own opinion and not that of my employer.
Enjoying the content? If you value the time, effort, and resources invested in creating it, please consider supporting me on Ko-fi.
Introduction
Over the past few years, enterprises have dramatically expanded their use of SaaS platforms, cloud-native runtimes, and browser-based IDEs. This has brought incredible flexibility – but also new attack surfaces that legacy tooling struggles to monitor or control.
SPADE – Side-channel Platform Abuse & Data Exfiltration – is a term I’m proposing to describe a novel class of attacker techniques that take advantage of trusted SaaS-hosted compute environments (like Google Colab, make.com, or online IDEs) to perform stealthy, difficult-to-detect data exfiltration or abuse.
This isn’t a bug or a misconfiguration in one vendor’s product. It’s an architectural blind spot – a way to weaponize “everything works by design” against organizations that rely heavily on proxy inspection, CASB, EDR, or Zero Trust enforcement alone.
And yes – it works. I’ve tested it. With test data. Multiple ways. With multiple SaaS services. And the endpoint controls? Mostly silent.
What Is SPADE?
SPADE techniques rely on one foundational idea:
🎯 If an attacker can get access to a trusted SaaS platform that lets them execute code or trigger workflows, they can use that platform as a proxy to exfiltrate or manipulate data – outside the reach of local agents and proxies.
Example: Google Colab
I discovered this specific abuse path during a posture review of a Google Workspace tenant.
Despite Google Drive and Docs being disabled, Google Colab was still accessible – and critically, it allowed me to:
- Authenticate
- Open example notebooks (even if Drive was off)
- Paste test data directly into code cells
- Use Python
requeststo commit that data to a private GitHub repo
💥 Result? The data left the environment via Colab’s runtime, not the local browser.
No DLP alert. No EDR alert. No CASB block.
I even watched the browser’s DevTools:
- POSTs to
colab.research.google.com - Background fetches from
colab.devinfrastructure (e.g., not your compute or your prefered data region) - No file upload or clipboard activity detected by SASE or EDR
Even GitHub commits - normally blocked by policy - succeeded.
Because the Colab VM was the one doing the commit. Not me.
If you use the Enterprise version of Colab, you can have more control over the runtime execution including disabling public internet access: https://cloud.google.com/colab/docs/runtimes
With enterprise you can also create some organisation policies: https://cloud.google.com/colab/docs/custom-constraints
This also allows you to use compute that you control e.g. within your own Google Cloud organisation.
However, the free version of Colab is enabled by default in all Google tenants - even if you think you only use Google Cloud, there is an associated workspace instance that any directory account (local or federated from another Identity Provider) can access if you haven’t turned Colab off (this is true of many google workspace apps).
Key Characteristics of SPADE Techniques
| Characteristic | Description |
|---|---|
| Platform-native execution | Code runs inside trusted SaaS compute (e.g., Jupyter, Python, flows) |
| API-based exfiltration | Data siphoned via approved/trusted API domains (e.g., GitHub, S3) |
| Tenant obfuscation | Operations occur in cloud runtimes with opaque tenancy boundaries |
| Control evasion | EDR, CASB, and SWG controls see only trusted destinations and traffic |
| Browser artifact evasion | No clipboard, no drag/drop, no file upload - often just keyboard input |
Example TTPs (Tactics, Techniques, Procedures)
| Phase | Technique |
|---|---|
| Initial Access | Reuse of corporate SaaS credentials (e.g., via OAuth SSO to Colab, make.com, etc) |
| Execution | Python code, API keys, curl/wget inside notebook/flow runners |
| Exfiltration | Use of API calls (e.g., GitHub, AWS S3, Webhooks) to push data |
| Defense Evasion | Runs from remote cloud infra, no logs on endpoint |
| Command & Control | Remote callbacks or script triggers via cloud function scheduling |
Why This Works
Because SaaS runtimes are trusted.
They’re not your users’ laptops. They don’t have your endpoint agents installed.
They operate from Google’s IP ranges, or AWS, or Microsoft.
If your tooling is scoped to:
- “traffic from managed devices”
- “browsers controlled by endpoint agents”
- “uploads via corporate network”
…you’ve already lost the plot.
What Controls Missed This?
Let’s be specific:
- EDR: No alerts fired. API usage not flagged.
- CASB: Browser-based upload to GitHub was blocked. But commit via Colab runtime? Allowed.
- Proxy logs: Showed only
colab.research.google.com. No outbound data flagged.
Even GitHub’s API endpoint - api.github.com - was already sanctioned for dev work.
Nothing flagged the origin shift.
Relevant MITRE ATT&CK Techniques
SPADE aligns with and likely extends the following ATT&CK entries:
- T1567.002 – Exfiltration to Cloud Storage
- T1567.001 – Exfiltration to Code Repository
- T1553.xxx – New Sub-Technique? (Abuse of Trusted Cloud Execution Runtimes)
- T1648 – Serverless Execution Environment (Colab, make.com, JupyterHub)
This technique blurs the lines between exfiltration, command & control, and execution.
It doesn’t just exfiltrate – it executes on trusted SaaS compute.
| Technique | Focus | SPADE Fit |
|---|---|---|
| T1648 | Where the execution happens | ✅ Serverless (Colab, Replit, etc.) |
| T1553 | Why it evades controls | ✅ Abuses trusted SaaS environments |
| T1567 | Where the data is exfiltrated | ✅ GitHub, GCS, etc. via trusted APIs |
Together, they frame a 3D model of the attack path:
- Execution origin (T1648)
- Control bypass (T1553)
- Exfiltration vector (T1567)
Other Platforms At Risk
Any platform that supports remote code execution, API-based workflows, or cloud-based runtimes could be abused in a similar way:
| Platform | Risk Description |
|---|---|
| Google Colab | Jupyter notebooks with internet access and GitHub integration |
| make.com | Workflow orchestration with webhook input/output, token auth |
| Labs.iximiuz.com | Online containers with public IP and shell access |
| KASM Workspaces | Streamed desktop/browser with clipboard + network access |
| Online IDEs (e.g. Replit, Glitch) | Persistent storage + Git + webhooks + exec |
| ANY.RUN, Joe Sandbox, etc | Malware sandboxes with potential abuse of callback channels |
These tools are designed to be programmable, convenient, and networked.
And they often live outside your enterprise monitoring perimeter.
Detection and Mitigation Ideas
Detection
| Method | Description |
|---|---|
| Runtime-aware logging | Enable session recording, IP detection, notebook usage monitoring in SaaS |
| API traffic profiling | Monitor outbound calls from SaaS tenants to unusual external domains |
| Behavioral analytics | Flag unusual clipboard activity, long paste bursts, or large code payloads |
| Anomaly detection | Look for SaaS runtimes making commits, uploads, or API calls not typical of the org |
Mitigation
| Control | Impact |
|---|---|
| CASB (Clipboard + Upload Control) | Can block paste/file uploads into untrusted SaaS IDEs |
| Policy Hardening (SaaS Restrictions) | Restrict access to SaaS runtimes to approved user groups only |
| Privileged Access Workstations | Only allow services such as those mentioned within environments where access to sensitive data is restricted. |
CASB: A Partial Hero
While CASB tools can’t prevent remote runtime execution once the notebook or sandbox is running, they can block how data gets into the notebook/sandbox in the first place.
- Blocking clipboard paste
- Blocking file uploads
- Blocking browser extensions or copy/paste shortcuts
Combined with app detection and isolation policies, CASB becomes a partial but powerful control layer.
Variants and Naming Options
Originally dubbed SPADE, I’ve also toyed with:
- ALIEN – Abuse of Legitimate Integration ENgines
But SPADE feels right. Because you’re not digging a tunnel - you’re flipping the dirt over the fence using SaaS shovels.
Tying Into LOTS and Compliance frameworks
The LOTS project aims to catalogue “Living Off Trusted Sites” abuses - this technique fits right in.
And if you’re applying Compliance frameworks such as CIS or SCuBA (Secure Cloud Business Applications) guidance, ask yourself:
- Does it fully account for execution inside SaaS-hosted runtimes?
- Are your coverage gaps visible to you today?
- Where does Colab, make.com, or KASM fall in your sanctioned app posture?
Because if it’s not in your policy, and it’s not in your logs, it might be in your breach.
Mapping it out
I’ve added mind maps for this to my GitHub Repository:
KuShu-Atama/
├── artifacts/ # Exported visualizations (PDF/PNG)
│ ├── SPADE_MindMap_v1.pdf
│ └── SPADE_MindMap_v1.png
├── src/ # Source mind maps
│ ├── SPADE_MindMap_v1.mm
│ └── SPADE_MindMap_v1.smmx
Final Thoughts
This isn’t just about Colab. Or GitHub. Or test data.
It’s about a whole class of trusted compute surfaces that live in SaaS -
- where enterprise visibility fades, and attacker opportunity blooms.
SPADE is one more reminder that trust boundaries are dynamic. And our tooling? Often too static.
If we want to make modern enterprise cloud environments safer, we need to account for SaaS-native runtime abuse - before attackers do.