Using Microsoft Dev Tunnels for C2 Redirection

By Red Siege | April 9, 2024

by Justin Palk, Senior Security Consultant

 

As penetration testers, we’re always on the lookout for new ways to get our command-and-control (C2) traffic out of a client’s network, evading egress filters and reputation checks. The toolbox includes things like domain fronting, content delivery networks (CDN), and third-party services such as Slack or GitHub. One more thing we can add to the toolbox is Microsoft dev tunnels.

Microsoft advertises dev tunnels as a tool for securely sharing web services across the internet for development purposes. This is the system underlying VS Code remote tunnels, and it’s built on top of SSH. Dev tunnels allow for both authenticated and anonymous connections, persistent URLs hosted in a reputable Microsoft Azure domain, and multiple simultaneous forwarded ports. The service is currently in a public preview phase. As an aside, the devtunnel executable itself is signed by Microsoft, which is nice if you have to run it on a client machine, although for this application, it runs on our team server.

Getting Started

Creating dev tunnels requires either a GitHub or a Microsoft account. With no current information on how much inspection these tunnels are subject to by Microsoft, I recommend using a disposable GitHub account. The instructions below cover creating an anonymous tunnel which does not require authentication to access1, but is potentially discoverable by others scanning the whole spread of possible tunnel URLs. The devtunnel tool itself is available for Windows, Linux, and MacOS. If you want more information on the tool and its options, the full command reference is here.

1, Install the Linux devtunnel tool on your team server. It’s is a standalone binary that requires no elevated permissions to install or run.

wget https://aka.ms/TunnelsCliDownload/linux-x64; mv linux-x64 devtunnel; chmod +x devtunnel

2. Authenticate to the devtunnel service using your GitHub account and the device login flow using the command devtunnel user login -g -d.

Connecting Dev Tunnels to a Github Account

 

Open a web browser on your local machine and navigate to the device login page as directed by devtunnel. Authenticate to the GitHub account you want to use, then enter the provided code and authorize devtunnel to access your GitHub account.

Registering Dev Tunnels as a Device

 

3. Create a devtunnel to port 443 on localhost. The -a option allows for anonymous access. Choose http or https for your listener as necessary to meet your needs. If you only have one tunnel, port creation and hosting will be created in that tunnel by default.

./devtunnel create -a <tunnel name>
./devtunnel port create -p 443 --protocol https
./devtunnel host

Creating a Dev Tunnel

 

4. Stand up a team server as normal, including requesting a certificate (if you want an HTTPS listener), then create a listener using the port and URL of the devtunnel.

Creating a Listener for the Dev Tunnel

 

5. Create a beacon targeting the listener you just created, and deploy it to your client. You should receive a callback shortly.

Successful Beacon Callback

Troubleshooting

If your beacon doesn’t want to connect, there are a couple of things to check. First, Microsoft provides a web-based tool for monitoring traffic through the tunnel. The URL is provided in the devtunnel output, along with the tunnel URL, as shown below.

Tunnel Traffic Inspection URL

 

Visiting this URL lets you inspect tunnel traffic using an interface essentially identical to a browser’s web developer tools network tab, as shown below. This will show you whether your beacon is calling out to the dev tunnel.

Inspecting Tunnel Traffic

 

It should be noted that the dev tunnel does break TLS, so conceivably someone at Microsoft has the ability to access and inspect the raw traffic.

If your beacon is running on the target host but you’re not seeing any traffic reaching the tunnel in the inspection utility, one thing to check is your malleable C2 profile (assuming you’re running Cobalt Strike). When first connecting to a dev tunnel, Microsoft inserts a click-through interstitial warning users that this could be a phishing attempt, as shown below. Based on what I’ve seen, only requests that successfully transit the tunnel will show up in the inspector; requests hitting this interstitial won’t.

Anti-Phishing Click-Through

 

HTTP GET requests with an Accept header containing text/html will trigger the interstitial and prevent your beacon from phoning home. Other request types, such as POST or PUT, or requests not explicitly accepting text/html, will bypass the interstitial. If your beacon is getting hung up on the interstitial, you can either change your Accept header (*/* will bypass it), or you can add a X-Tunnel-Skip-AntiPhishing-Page: True header to the client http-get block in your profile, as shown below.

X-Skip-AntiPhishing-Page Header in Malleable C2 Profile

 

And that’s it! Dev tunnels are remarkably easy to set up and use, provide one more tool for smuggling our traffic out of a client’s network. Let us know what your experience is with them in our Discord.

 

 

1 – Dev tunnels do support authentication, but using them with Cobalt Strike is problematic as they 1.) Require the inclusion of a 373-character JWT in the request headers, consuming much of a malleable C2 profile’s allowed 508 byte limit for the client http-get and http-post blocks, and 2.) the JWT expires after 24 hours, limiting a beacon’s lifetime.

 


 

About Justin Palk, Senior Security Consultant:

Justin Palk has more than 16 years of experience in IT and information security, and has worked in the academic, federal civilian government and health research sectors. He has held a variety of roles including system administrator, developer, auditor, assessment team lead and web application penetration tester. He regularly competes in CTFs in the U.S. and Europe.

Certifications:
GCIH, GWAPT, GPEN, GMOB, GDSA

Connect on Twitter & LinkedIn

Adventures in Shellcode Obfuscation! Part 1: Overview

By Red Siege | June 17, 2024

by Mike Saunders, Principal Security Consultant This blog is the first in a series of articles on methods for obfuscating shellcode. I’ll be focusing on how to obfuscate shellcode to […]

Learn More
Adventures in Shellcode Obfuscation! Part 1: Overview

Essential Steps for Management to Maximize the Value of a Penetration Test Report

By Red Siege | June 3, 2024

by Tim Medin, CEO Penetration testing is a critical component of a well-rounded cybersecurity strategy. Penetration testing identifies vulnerabilities before malicious actors can exploit them. However, the true value of […]

Learn More
Essential Steps for Management to Maximize the Value of a Penetration Test Report

Fun With JWT X5u

By Red Siege | May 30, 2024

by Senior Security Consultant Douglas Berdeaux On a recent web application penetration test engagement, I came across a JSON Web Token (JWT) that contained an x5u header parameter. I almost […]

Learn More
Fun With JWT X5u

Find Out What’s Next

Stay in the loop with our upcoming events.