Why Attackers Use GitHub and OneDrive Instead of Malicious Infrastructure

Corporate web filtering works on a straightforward premise: block known bad domains, allow everything else. For years this provided reasonable protection against commodity malware that relied on newly registered domains or hosting with poor reputation scores.

Attackers noticed, and adapted. A growing proportion of modern intrusions now use infrastructure from platforms that every organisation has already decided to trust — GitHub, OneDrive, Google Drive, Cloudflare, Discord. Your proxy allows these by default. Your URL filter has no reason to block them. Your domain reputation feed scores them clean. That is precisely why they are used.

What "living off trusted sites" means

The technique is sometimes called living off trusted sites, or LOTS — an extension of the better-known "living off the land" approach where attackers use built-in operating system tools to avoid introducing unfamiliar software. LOTS applies the same logic to network infrastructure: use platforms the target organisation has already permitted rather than building or buying dedicated attack infrastructure.

Dedicated attacker infrastructure has a problem. It requires registration, hosting, TLS certificates, and operational security to avoid being identified and blocked. It can be flagged by threat intelligence feeds, taken down by hosting providers, or identified through passive DNS analysis. Legitimate infrastructure has none of these weaknesses — it is maintained by well-resourced companies, carries trusted certificates, and processes billions of legitimate requests daily.

Where payloads actually get hosted

The following patterns have appeared in documented intrusions. They are not theoretical scenarios.

GitHub: Repositories and release assets are a common staging location for second-stage payloads. A script or implant uploaded as a release asset on a throwaway account is downloaded by a compromised system. The download request goes to objects.githubusercontent.com — a domain most corporate proxies permit without inspection.

OneDrive and SharePoint: Microsoft 365 infrastructure is present in nearly every enterprise environment. Attackers with access to a compromised Microsoft account — or one created for the purpose — can host files in OneDrive and retrieve them from a victim system. Proxy controls classify this as Microsoft traffic.

Google Drive: The same principle applies. A payload staged in Google Drive is retrieved over a connection that proxy controls classify as Google traffic — which is typically permitted at the broadest level.

Cloudflare Workers: Cloudflare's serverless platform allows arbitrary code to run at the edge. Attackers have used Workers as command-and-control relay points, with traffic passing through *.workers.dev or a custom domain sitting behind Cloudflare. To a proxy, this looks like CDN traffic.

Discord's content delivery network: Attachments uploaded to Discord channels are served from cdn.discordapp.com. This has been used extensively in commodity malware campaigns as a staging mechanism. Most organisations allow Discord CDN traffic, and some do not even have Discord itself blocked.

Why standard controls miss it

URL filtering operates on domain reputation. These domains have strong, longstanding reputations that took years to establish and are maintained by companies with security teams of their own. They will not be flagged.

Web proxy categorisation works by domain or certificate. Microsoft, Google, GitHub, and Cloudflare all carry trusted certificates and fall into categories — cloud storage, developer tools, CDN — that are allowed by default in most corporate filtering policies.

SIEM detection rules that look for connections to newly registered or low-reputation domains will not fire. These domains are old, well-established, and produce millions of legitimate connection events every day.

TLS encryption compounds this. Even where organisations have deployed TLS inspection — and most have not deployed it comprehensively — the traffic looks like ordinary file downloads or API calls without deep behavioural analysis.

What does catch it

This technique is not undetectable. It bypasses controls that operate at the domain level. Behavioural controls are more effective.

A well-configured endpoint detection and response (EDR) tool monitors which process initiated a network connection and what it does with retrieved content. A payload downloaded from GitHub and then executed by a scheduled task is identifiable through process behaviour — not because of where it came from, but because of what it does afterwards. The execution pattern is suspicious regardless of the download source.

Network anomaly detection, where it exists, can identify contextually unusual traffic. A server that has no legitimate reason to be syncing files with OneDrive making repeated requests to Microsoft Graph APIs is anomalous, even if the destination domain is trusted.

Reducing the attack surface at the perimeter is also relevant. LOTS techniques require a foothold first. The attacker needs to be inside your environment before they can use legitimate hosting platforms for staging and command-and-control. Unpatched internet-facing services, weak credentials, and exposed remote access interfaces are the entry points. Close those and the technique never gets deployed. This is covered in more detail in What Happens in the Weeks Before a Ransomware Attack.

What this means for security testing

Web filtering is not a substitute for endpoint protection or detection capability. An organisation that has invested in URL filtering but not in EDR coverage or security monitoring has a perimeter control that sophisticated attackers know how to route around. The protection stops at the network boundary; nothing inside it provides detection.

Penetration tests that include realistic post-exploitation phases will use techniques like these. A test that stops at "we identified a vulnerability and demonstrated it is exploitable" does not tell you what happens after the foothold is established, or whether your detection tooling would catch the follow-on activity. The more relevant question is how far an attacker can go, and what signals — if any — they leave behind.

Red team exercises test detection coverage directly. If your security operations team cannot identify command-and-control traffic routing through Cloudflare infrastructure, or a payload being staged from a GitHub release, that is a finding — not a vulnerability in the perimeter, but a gap in what your detection capability can see. For guidance on when a red team engagement is the right next step, see Do I Need A Red Team?