00The problem
Enterprise networks do not let traffic out freely. Outbound connections pass through web proxies that inspect destinations against category databases, URL reputation lists, and TLS inspection engines. Content filters block known malicious domains. Firewalls restrict egress to approved ports and protocols. For a red team operator who has landed on an internal workstation, the challenge is not getting code execution. It is getting that code to talk to the outside world without triggering a single alert.
The conventional approach is to drop a payload, open a reverse shell, and hope the C2 domain survives long enough. That approach fails against mature environments. The proxy blocks unknown domains. The firewall logs unusual port usage. The EDR flags PowerShell reaching out to an external IP. The SOC is watching.
This methodology takes a different path. Instead of fighting the controls, it uses them. The firewall trusts certain cloud platforms. The proxy allows traffic to certain domain patterns. The content filter categorises certain hosting providers as legitimate business tools. By hosting attacker infrastructure on those trusted platforms and routing traffic through them, the red team's communications become invisible inside the noise of normal corporate internet usage.
01Living Off Trusted Sites (LOTS)
The concept is well-established in red team tradecraft and goes by the name LOTS: Living Off Trusted Sites. Most enterprise firewalls and web proxies maintain allowlists, either explicit or implicit, for cloud platforms that the business depends on. If the organisation uses Azure, then *.azurewebsites.net is almost certainly permitted through the proxy. If they use GitHub for anything, *.github.io passes. The same applies to other major platforms:
*.azurewebsites.net— Azure App Service*.github.io— GitHub Pages*.herokuapp.com— Heroku*.firebaseapp.com— Google Firebase Hosting*.cloudfront.net— AWS CloudFront CDN*.netlify.app— Netlify*.vercel.app— Vercel*.workers.dev— Cloudflare Workers
These are not obscure domains. They are the backbone of modern cloud hosting. Organisations trust them because they run their own applications on them. The attacker's job is to figure out which ones the target trusts, and then host attacker infrastructure on the same platform.
Reconnaissance: what do they trust?
This is not guesswork. The target's trusted platforms leak from half a dozen passive sources, none of which require touching the target network:
- Job descriptions. Engineering job postings name the cloud platforms, CI/CD tools, and infrastructure stack the team uses daily. A posting that asks for experience with a specific cloud provider tells the red team which provider's domains the proxy will allow.
- DNS records. Passive DNS enumeration reveals CNAME chains pointing to cloud hosting platforms, CDN edges, and SaaS providers. If the target's public-facing applications resolve to a specific platform's infrastructure, that platform's domain pattern is trusted internally.
- LinkedIn profiles. Developers and DevOps engineers list their tooling stack on their profiles. Security engineers often list the products they administer. A profile that mentions a specific web application firewall or proxy product tells the red team what they are bypassing.
- Technology fingerprinting. HTTP response headers, JavaScript library versions, and cookie names on the target's public sites reveal the hosting platform, the CDN, and often the proxy or WAF in front of them.
- Public repositories. Configuration files, deployment scripts, and infrastructure-as-code templates in public repositories reveal the cloud platforms, domain patterns, and service configurations the organisation depends on.
The output of this reconnaissance is a short list of cloud platform domain patterns that the target's proxy and firewall will allow without inspection. That list is the foundation of everything that follows.
Technique
Choosing the right platform
Not every trusted platform is equally useful. The ideal platform for hosting attacker infrastructure has three properties:
- Wildcard trust. The proxy allows
*.platform.tld, not just specific subdomains. This means the attacker can create a new subdomain and it is automatically trusted. - Free or anonymous hosting. The platform allows hosting static sites or web applications without identity verification that would expose the red team.
- HTTPS by default. The hosted site gets a valid TLS certificate automatically, so the traffic looks like legitimate encrypted web browsing.
Major cloud app-hosting services and static-site hosting platforms meet all three criteria. The attacker creates a site on the platform, gets a subdomain under the trusted wildcard, and the proxy waves it through.
02Testing connectivity without raising alerts
Once the attacker has internal network access, the first question is: can I reach my infrastructure? The wrong way to answer this is to open PowerShell and make an outbound HTTP request. That triggers EDR telemetry, proxy logs, and potentially a behavioural alert.
The right way is quieter. If the trusted-site infrastructure is already hosted and publicly accessible, the attacker can simply open a web browser on the compromised workstation and navigate to it. A user opening a browser and visiting a site on a trusted cloud platform is the most normal thing that happens on a corporate network. It generates no alert, no unusual process tree, no suspicious command-line argument.
This also serves as a connectivity test. If the page loads, the full chain works: DNS resolves, the proxy allows the domain, the firewall permits the port, and TLS terminates cleanly. If it does not load, the attacker knows which layer is blocking before committing to a more complex technique.
The best connectivity test is the one that looks like a user browsing the web, because that is exactly what the monitoring stack is configured to ignore.
03Cloud tunnels: reverse access without malware
The next challenge is turning that outbound web connectivity into a reverse channel back to the attacker's environment. Traditionally this requires dropping a reverse shell binary, which the EDR will flag, or running a scripted payload, which the proxy will log.
Cloud tunnel services solve this differently. These services create an encrypted tunnel from a machine inside the network to an external endpoint, wrapping the traffic in standard HTTPS. From the perspective of the firewall and proxy, the traffic is an outbound HTTPS connection to a well-known cloud provider's infrastructure. It passes through every inspection layer because the protocol, the port, and the destination are all legitimate.
The tunnel terminates at the attacker's server, giving the attacker a reverse connection into the target network without dropping a binary, without running PowerShell, and without making a single connection to a suspicious domain.
The limitation
There is one problem. The cloud tunnel service requires the attacker to configure a destination domain, and that domain is the attacker's own. It cannot be pointed at the trusted-site subdomain directly, because the tunnel service needs to know where to route traffic. The tunnel endpoint is the attacker's domain, not the trusted platform's domain.
This means the tunnel alone does not solve the proxy bypass. The traffic from the internal machine still needs to go to the trusted-site domain, not the attacker's tunnel domain. The proxy would block a direct connection to an unknown domain. What is needed is a way to chain the two together: the trusted site receives the traffic, and the tunnel carries it to the attacker.
04The nginx redirector: chaining trusted sites with tunnels
This is where the technique comes together. The trusted-site subdomain is not just a static page. It runs a reverse proxy, specifically nginx, configured to rewrite and forward all traffic it receives to the cloud tunnel endpoint.
How it works
The nginx instance on the trusted-site platform receives incoming requests on the trusted subdomain. It rewrites the Host header, replacing the trusted-site hostname with the attacker's tunnel hostname, and proxies the request to the tunnel endpoint. The tunnel service receives the request, forwards it through the encrypted tunnel to the attacker's server, and returns the response through the same chain in reverse. The nginx instance rewrites the response headers back to the trusted-site hostname before returning them to the client.
From the internal machine's perspective, it is talking to a trusted cloud platform over HTTPS. From the proxy's perspective, it is allowing traffic to a known-good domain. From the firewall's perspective, it is standard port 443 traffic. The cloud tunnel wraps the actual payload in HTTPS, so even TLS inspection that terminates at the proxy sees only a legitimate-looking web request to a trusted platform.
The header rewrite in detail
The nginx configuration is minimal. It listens on the trusted-site's default port, accepts all incoming requests, and uses proxy_pass to forward them to the cloud tunnel endpoint. The critical directives are the header rewrites: proxy_set_header Host replaces the incoming trusted-site hostname with the tunnel hostname on the way out, and proxy_redirect performs the reverse substitution on the way back. The effect is that neither the client nor the proxy ever sees the tunnel hostname. It exists only in the connection between the trusted-site platform and the tunnel service, both of which are external to the target's monitoring.
Architecture
Why this chain defeats each control layer
- Firewall. Sees outbound HTTPS on port 443 to a known cloud platform IP range. Allowed.
- Web proxy. Sees a request to a subdomain under a trusted wildcard pattern. Domain categorisation returns "cloud hosting" or "business application". Allowed.
- Content filter. The URL pattern matches a legitimate cloud-hosted application. No malicious indicators. Allowed.
- TLS inspection. Even if the proxy terminates TLS, it sees a standard HTTPS request to a trusted domain. The payload is a normal-looking HTTP exchange. The actual tunnel traffic is opaque inside the cloud tunnel's own encryption layer.
- EDR. No PowerShell, no scripted payload, no suspicious process. The traffic originates from a browser or a standard HTTP client making a request to a trusted site.
- SOC. The traffic blends perfectly with the thousands of other requests to the same cloud platform that happen every hour. There is no anomaly to investigate.
05Operational considerations
Infrastructure setup sequence
The order matters. The trusted-site and the tunnel must be operational before the attacker needs them on the internal network. Setting up infrastructure during an engagement window wastes time and increases the risk of being observed. The full chain should be tested from an external network against the same proxy and firewall configuration (often discoverable from the target's remote-access portal or VPN endpoint) before the internal phase begins.
Domain and subdomain selection
The subdomain on the trusted platform should not look suspicious on casual inspection. A name that resembles a legitimate internal application, a development environment, or a testing instance blends better than a random string. The attacker's tunnel domain is never visible to the target's monitoring, so it is less critical, but using a plausible domain with a valid certificate is good practice in case any layer inspects the tunnel connection.
Persistence and rotation
Trusted-site subdomains can be rotated quickly if one is burned. The nginx configuration is identical across instances; only the subdomain changes. The tunnel endpoint remains the same. This gives the attacker rapid recovery if the SOC blocks a specific subdomain, because the replacement is immediately trusted under the same wildcard pattern.
Bandwidth and latency
The chain adds latency: internal host to proxy to trusted site to tunnel to attacker. For interactive shells and real-time tool output, this is noticeable. For file transfers, command execution, and asynchronous tasking, it is acceptable. The cloud tunnel's throughput is usually the bottleneck, but for red team operations that prioritise stealth over speed, the trade-off is worth it.
06Why it works and how to stop it
| Defensive assumption | What actually happens | Defensive improvement |
|---|---|---|
| Blocking unknown domains is sufficient | The attacker uses domains the firewall explicitly trusts | Monitor for new subdomains under trusted wildcards. Alert on first-seen subdomains in cloud platform ranges. |
| TLS inspection catches malicious payloads | The payload is double-encrypted: once by the HTTPS connection to the trusted site, and again by the cloud tunnel | Inspect the content of requests to cloud platforms, not just the domain. Look for proxy-like behaviour in responses. |
| EDR catches reverse shells | No binary is dropped. No PowerShell runs. The traffic is standard HTTPS from a browser process. | Behavioural baselines for cloud platform usage per user and per machine. Alert on workstations that suddenly start making sustained connections to cloud app-hosting subdomains. |
| Category-based filtering is granular enough | The trusted site is categorised as "cloud hosting", the same category as the organisation's own applications | Move from wildcard trust to explicit subdomain allowlisting for cloud platforms. Only permit the specific subdomains the organisation actually uses. |
| Proxy logs capture the real destination | The proxy sees only the trusted-site domain. The tunnel hostname never appears in any log the target can see. | Deploy cloud-platform-specific monitoring that tracks subdomain creation and usage patterns. Correlate proxy logs with cloud platform audit logs where available. |
The core lesson is that wildcard trust is transitive trust. When an organisation allows *.azurewebsites.net or *.github.io, it is not trusting the platform. It is trusting every user of that platform, including the red team. Moving to explicit subdomain allowlisting is the single highest-impact defence, and it is the one that almost nobody implements because it breaks the convenience model that cloud platforms are built on.
The firewall was not bypassed. It was obeyed. Every packet followed the rules. The rules just did not anticipate an attacker who would follow them too.