Malware of the Day – Tunneling Havoc C2 with Microsoft Dev Tunnels
What is Malware of the Day?
Lab Setup
Malware: Havoc C2 and MS Dev Tunnels
MITRE Tactics: TA0011 Command and Control, T1572_Protocol_Tunneling
Traffic Type: HTTPS
Connection Type: Tunneled TCP
C2 Platform: Havoc C2
Origin of Sample: Active Countermeasures Threat Hunting Lab
Host Payload Delivery Method: Executable (*.exe)
Target Host/Victim/Agent: 10.0.0.4 (Windows 10 Pro x64)
MS Dev Tunnels Server: 20.120.56.11
C2 Server: 70.24.242.42 (Kali Linux)
Beacon Delay: 10 seconds
Beacon Jitter: 50%
Malware of the Day Mission
To identify and share examples of post-compromise network activity in order to better detect and respond to potential network threats. Specifically we are looking for command and control (C2) communication channels used by attackers to obtain intelligence, issue commands, and exfiltrate data through a compromised host or hosts.
Preface: The Treat Hunting Mindset
As threat hunters, we approach our work with the mindset of a detective, maintaining an open and unbiased perspective to ensure that all potential evidence is considered and interpreted objectively. Our investigation begins when we discover a piece of evidence that suggests something might be amiss. From this point, we employ a variety of supportive tools to either refute or strengthen our case.
The process of threat hunting involves layering evidence, gradually increasing the probability of a compromise as we gather different, independently verified pieces of information. Each new piece of evidence adds to the overall picture, allowing us to build a stronger case. Our ultimate goal is to construct a case that is sufficiently solid to inform the Incident Response team of a probable compromise.
Throughout the investigation, it is crucial to remember the golden rule of threat hunting: never cross the active-passive line. This means that we must use all the tools and techniques at our disposal in a manner that does not alert the intruder to the fact that they are being investigated. By maintaining a passive approach, we can gather the necessary evidence without compromising the investigation.
By adhering to this mindset and methodology, we can effectively investigate potential compromises, providing valuable insights and enabling our organization to respond to threats in an effective manner.
Background
Microsoft Dev Tunnels (2023) enables developers to create secure tunneled connections between external endpoints, effectively sharing local web services across the internet. The tool’s accessibility is noteworthy – it requires only a free executable (compatible with Windows, MacOS, and Linux) and a Microsoft account, without any verification requirements.
Like any powerful tool placed in the wrong hands, Dev Tunnels has become a double-edged sword – threat actors have discovered multiple ways to weaponize its capabilities, each method offering its own unique blend of advantages and trade-offs for malicious activities.
Understanding MS Dev Tunnels Role in Compromises
Before diving into the specific methods of misusing Dev Tunnels connections, let’s examine the core of any basic compromise – that crucial network connection between victim and adversary systems, illustrated in Image 1 below.
Image 1. If we peel away all the layers of what constitutes a compromise, what we’re typically left with is a “network connection that should not be”.
From this basic two-party scenario, Dev Tunnels introduces a critical third player to the equation – Microsoft’s Dev Tunnel server, shown in Image 2.
Image 2. The MS Dev Tunnel server is introduced between the victim and adversary, effectively serving as a proxy/redirector.
Based on this, Dev Tunnels can be configured in two fundamentally different ways. A half-tunnel establishes a connection between just one endpoint (either the victim system or the adversary system) and the Microsoft Dev Tunnels server. This creates only one segment of the potential communication path. In contrast, a full tunnel creates a complete endpoint-to-endpoint connection that bridges both systems through the Dev Tunnels server, enabling direct communication between the victim and adversary systems.
Further, the tunnel can accommodate different types of traffic flows to effectively mask their true nature. When used for Command and Control (C2), the tunnel carries egress traffic from victim to adversary, facilitating the typical command-response pattern of C2 communication. Alternatively, when used for remote access protocols like RDP or SSH, the tunnel carries ingress traffic flowing from the adversary to the victim system.
However, here’s the crucial aspect that makes this particularly significant for security: regardless of the actual traffic direction or protocol being used, the tunnel always presents itself to the victim’s network as outbound TLS traffic. This means that even when an adversary is actively connecting inbound to a victim’s system – for instance, through RDP – the connection appears in network logs and monitoring tools as a standard outbound HTTPS connection originating from the victim’s network.
Based on this, there are three main ways in which Dev Tunnels may be misused by threat actors: tunneling egress C2 traffic using a half-tunnel, tunneling egress C2 traffic using a full tunnel, or tunneling ingress traffic using a full tunnel.
Tunneling Egress C2 Traffic Using a Half-Tunnel
Using a half-tunnel for C2 traffic provides threat actors with a powerful advantage – a free redirector service protected by Microsoft’s certificate infrastructure. By simply registering with an email address, attackers gain access to Microsoft-signed domains and certificates that would typically require extensive verification or cloud service subscriptions to obtain legitimately. While the C2 traffic patterns remain unchanged and potentially detectable, the connection terminates at a trusted Microsoft endpoint, making it more likely to bypass initial security controls that rely on certificate and domain reputation.
Tunneling Egress C2 Traffic Using a Full Tunnel
By running Dev Tunnels on both systems, the C2 traffic is fully encapsulated within the tunnel, gaining the additional advantage of the Microsoft-signed process handling network communications on the victim’s end. However, this requires successfully deploying and executing the Dev Tunnels application on the victim’s system, which demands higher privileges and creates additional operational security risks.
Tunneling Ingress Traffic Using a Full Tunnel
The third approach – using a full tunnel for inbound remote access protocols like RDP or SSH – offers unique advantages for maintaining persistent access to compromised systems. While this method effectively bypasses common network security controls by disguising inbound connections as outbound HTTPS traffic, it’s limited to protocols that normally listen for incoming connections and isn’t compatible with traditional C2 frameworks.
For today’s Malware of the Day report we will focus specifically on analyzing the full tunnel configuration for egress C2 traffic using the Havoc C2 framework.
Scenario and Setup
The attack chain began when the adversary acquired initial access to the target system (private IP: 10.0.0.4) through an Initial Access Broker on the dark web. This access provided them with a foothold via a reverse shell, which offered the advantage of being relatively stealthy, but which also restricted their ability to execute more sophisticated attack sequences necessary for their intended campaign.
To advance their ultimate objectives of ransomware and extortion, the adversary decided to implement a Command and Control (C2) infrastructure. This would provide them with the required expanded capabilities within the victim’s network.
The adversary began by configuring their Havoc C2 server (70.24.242.42) to listen for incoming connections on port 443, bound to the local interface. They then executed the Dev Tunnels application on this same system, which established a connection to Microsoft’s Dev Tunnels server (20.120.56.11). This crucial step effectively transposed the listening port from their local interface to the Dev Tunnels server.
To complete the full tunnel configuration, the adversary leveraged their existing shell access to deploy and execute the Dev Tunnels application on the victim’s system. This additional tunnel segment had the effect of transposing the listening port once again – this time to the victim system’s localhost interface. The adversary then generated a Havoc HTTPS payload specifically configured to connect to this local listener.
For payload delivery, the adversary created a download link using WeTransfer. This choice was strategic – WeTransfer serves as a legitimate file-sharing service commonly used in business environments, making it less likely to trigger security alerts. Additionally, its high reputation score often allows it to bypass URL filtering.
Using their shell access, the adversary downloaded and executed the payload on the victim’s system. The payload connected to the local listener, which was mediated by the trusted MS Dev Tunnel process. It then tunneled this connection through the Microsoft Dev Tunnels server back to the adversary’s C2 server. This setup established a robust C2 channel that appeared as legitimate outbound HTTPS traffic to Microsoft infrastructure, while providing the adversary with the enhanced capabilities needed to pursue their broader campaign objectives.
RITA
During routine network threat hunting using RITA, our organization discovered an interesting and unusual connection – see Image 3 below.
Image 3. RITA entry for the suspicious connection
The connection caught our attention for several reasons. First, while the beacon score was low at 5.40%, the connection duration stretched across almost the entire 24-hour capture period at 23h59m21s, suggesting a persistent connection rather than normal intermittent business traffic.
Our team of analysts were also particularly intrigued by the destination FQDN – use-data.rel.tunnels.api.visualstudio.com. Though the domain appeared legitimate, being part of Microsoft’s infrastructure, it wasn’t one we recognized from our environment’s normal Microsoft service usage patterns.
To find out more about this specific connection we can pivot to Zeek.
Zeek
Since RITA provides us with the destination FQDN we can use Zeek’s dns.log to find the specific IP associated with this FQDN. In examining the dns.log (Image 4), we discovered an interesting DNS resolution chain.
Image 4. Using the Zed syntax language we located the IP that our FQDN of interest resolves to.
We can see that the query for use-data.rel.tunnels.api.visualstudio.com followed a CNAME (Canonical Name) chain – a series of DNS alias records that ultimately pointed to the actual host. The chain moved through several intermediary domains before resolving to the IP address 20.120.56.11.
Additionally, since we learned in RITA that this is an HTTPS connection we might do well to look at some key details of the certificate, which we can find in the Zeek x509.log. However, to get there we’ll first need to navigate through two other logs – conn.log and ssl.log.
Since we know our IP (10.0.0.4), as well as the destination IP (20.120.56.11) and port (443), we can locate any one of the 13 connections between this specific host pair over HTTPS in conn.log – see Image 5 below.
Image 5. We can once again make use of Zed to find a uid associated with our host pair of interest.
Critically, what we’re really after here is the uid, the “unique ID”. This is core to Zeek’s logging system – it allows us to track this same connection on other logs, much like how a key is used in relational databases to connect entries in different tables with one another.
We can now use this uid of CdG55j2ATfdGAYPru in ssl.log to find the cert_chain_fps – an ordered vector of all certificate fingerprints for the certificates offered by the server – see Image 6 below.
Image 6. Using Zed we can locate the certificate fingerprints in ssl.log.
We can see that ssl.log provides us with fingerprints for the server, intermediate, and root certificates. We can now use any one of these three to pivot one final time to Zeek’s x509.log – see Image 7.
Image 7. Using the certificate fingerprint we are able to find crucial details related to the X509 certificate.
As expected, given the Microsoft domain, we found a valid certificate issued by Microsoft Azure, issued to rel.tunnels.api.visualstudio.com with Microsoft Corporation listed as the subject organization.
Looking at the certificate details, we can also note that it is a relatively new certificate, valid from August 24, 2024, through August 19, 2025. The certificate used standard secure parameters, all of which align with current best practices for TLS certificates.
With the IP address now identified and the certificate details validated, we can turn to AC-Hunter to learn more about this connection.
AC-Hunter
Since we know both the IP, as well as the fact that this connection was persistent, we can easily find the connection of interest in AC-Hunter’s Long Connection module – see Image 8 below.
Image 8. The Long Connection module shows our connection of interest near the top of the list.
AC-Hunter also confirms that the ASN is 8075 and that this indeed appears to be a legitimate Microsoft server. AC-Hunter also provides a convenient way to select among a number of external reputation checks (Image 9).
Image 9. A variety of reputation checks are readily available in AC-Hunter.
We then reviewed the IP in AbuseIPDB (Image 10), which all but confirmed that this is indeed a legitimate Microsoft server. However, this verification did not mean we could relax our investigation – threat actors frequently misuse legitimate Microsoft infrastructure for malicious purposes. The validation of the server’s legitimacy simply confirmed we were dealing with authentic Microsoft services, which warranted even closer scrutiny of how these services were being utilized within our environment.
Image 10. AbuseIPDB entry for our IP of interest.
“Network for Breadth, Endpoint for Depth”
Our investigation has uncovered several suspicious and unusual properties of the connection in question. The evidence gathered from our primary threat hunting tools likely warrants alerting the Incident Response team for further investigation. Following their strict guidance and instructions – as we’re now under their jurisdiction – we can delve deeper into the endpoint to see what we may discover.
System Informer
Knowing our target IP, we can use System Informer (formerly Process Hacker) to identify the process mediating this connection. After opening System Informer with administrative privileges we click the Network tab at the top. This displays a list of processes, including the external host IP each is connecting to (Image 11).
Image 11. An overview of processes and their outbound connections.
Looking at the System Informer output, we identified devtunnel.exe (PID 18176) as the process responsible for the outbound connection to our IP of interest (20.120.56.11). This suggested we were dealing with a Microsoft Dev Tunnel, with this process acting as the mediator for the tunneled connection.
However, given that malware often attempts to masquerade as legitimate processes, we needed to verify that this was genuinely the Microsoft Dev Tunnels executable and not simply a malicious payload named to appear legitimate. To confirm this, we examined the process properties in System Informer, as shown in Image 12.
Image 12. Abbreviated overview of devtunnel.exe’s properties.
When examining the process details in System Informer, we noted that devtunnel.exe carried a verified Microsoft digital signature, confirming this was indeed the legitimate Microsoft Dev Tunnels application and not a malicious impersonator.
While this verification of authenticity might initially seem reassuring, our subsequent consultation with IT stakeholders revealed a concerning detail – Microsoft Dev Tunnels was not an approved application within our organization. This raised two possibilities: either this represented a Shadow IT scenario where an employee was using unauthorized tools, or more worryingly, given recent research showing how attackers can leverage Microsoft Dev Tunnels for C2 communications, this could indicate malicious activity.
With these concerns in mind, we returned to examine the System Informer process-connection overview shown in Image 8 more carefully, where we discovered we had initially overlooked something significant.
First, we see devtunnel.exe (PID 18176) listening on localhost (127.0.0.1) port 443, and also maintaining an established connection to the Microsoft Dev Tunnels server (20.120.56.11) on port 443.
When we examine bestfriend.exe’s connections, we notice it has an established connection to localhost (127.0.0.1) using port 49937. Crucially, we can also see devtunnel.exe has a corresponding established connection on this same port (49937), indicating these two processes are communicating with each other through this local connection.
This pattern of connections reveals that bestfriend.exe connects to devtunnel.exe’s listener on localhost, and devtunnel.exe then forwards this traffic through its established connection to the Microsoft Dev Tunnels server. This matches the behavior we would expect from tunneling C2 agent communication.
Finally by looking at bestfriend.exe’s properties (Image 13), we see that, unlike devtunnels.exe, it does not possess a digital certificate.
Image 13. Abbreviated overview of bestfriend.exe’s properties.
Conclusion
Microsoft Dev Tunnels represents a powerful dual-use tool that, while valuable for legitimate development purposes, introduces security concerns due to its accessibility and versatility as an attack vector. This analysis has revealed that misusing it presents three major opportunities:
- Egress traffic is mediated by a process with a valid Microsoft certificate
- Egress traffic is directed to a host over port 443 with a valid Microsoft X509 certificate
- Traffic is encrypted in the tunnel, obscuring the nature of the underlying traffic including its direction
Through our investigation, which began as routine threat hunting, we discovered how these characteristics manifest in real attacks. What started as an unusual persistent connection in RITA and AC-Hunter led us through network forensics and endpoint analysis, ultimately revealing a C2 channel tunneled through Microsoft’s infrastructure. The endpoint investigation proved crucial, showing how the legitimate, signed devtunnel.exe process was being used to tunnel traffic from an unsigned bestfriend.exe – a classic pattern for full-tunnel C2 configuration.
However, this case also reveals effective detection strategies. Network security monitoring tools like RITA and AC-Hunter are particularly valuable for identifying Dev Tunnels abuse through their connection duration tracking capabilities. Since Dev Tunnels maintains persistent connections, these will accumulate significant duration times and rise to the top of long-connection tables, making them relatively easy to spot during routine analysis, especially in environments where legitimate Dev Tunnels usage is uncommon or unauthorized.
Organizations can also implement straightforward detection rules at the DNS level. Microsoft Dev Tunnels uses specific, documented domains and subdomains for its operations, including global.rel.tunnels.api.visualstudio.com, [clusterId].rel.tunnels.api.visualstudio.com, [clusterId]-data.rel.tunnels.api.visualstudio.com, and various *.devtunnels.ms domains. Security teams can configure their IDS (such as Suricata) to alert on any DNS queries to these domains – a particularly effective approach in environments where Dev Tunnels isn’t explicitly permitted, as any resolution attempts for these domains would indicate unauthorized usage requiring investigation.
This case emphasizes that while attackers may leverage legitimate tools and infrastructure, their usage patterns often betray their presence. Through careful monitoring, organizations can effectively detect and investigate potential Dev Tunnels abuse, even when it comes wrapped in Microsoft’s trusted infrastructure.
Video Summary
Capture Files
PCAPs
Because… PCAPs, or it didn’t happen. 😊
The following PCAP files are packet captures taken from the same lab environment over a 1-hour time frame and a 24-hour time frame. The files were generated using Wireshark from the target host and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The PCAPs are safe, standard PCAP files and do not include any actual malware.
Havoc + Dev Tunnels 1 Hour Capture
havoc_MSDT_1h.pcapng
File Size: 64.4 MB
SHA-256 Hash: BADB39B64E07D3A2B680096806124BBAB9EF2CD15E4AC28719AD0458CCF00927
Havoc + Dev Tunnels 24 Hour Capture
havoc_MSDT_24h.pcapng
File Size: 1.4 GB
SHA-256 Hash: 220FFA72FC11939BE580BDB60DEFA41012B88AD56FF0E64753B66072D9B08AF9
Zeek Logs
If you are an AC-Hunter user, we are providing the 24-hour Zeek logs for you to import directly into AC-Hunter. The following Zeek Logs have been taken from the same lab environment over a 24-hour time frame and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The Zeek logs are safe, standard log files and do not include any actual malware.
Importing Zeek logs into AC-Hunter example:
ssh into your AC-Hunter server and upload all the Zeek logs contained in the zip file below (all files that have the ‘.log’ extension) into a temporary directory on the server. In this example, we are uploading the Zeek logs into /tmp/havoc-msdt-zeek-logs/
Then run the following command:
For AC-Hunter v6.x and RITA v4.x and earlier:
rita import /tmp/havoc-msdt-zeek-logs/*.log havoc-msdt
For RITA v5.x+:
rita import --logs=/tmp/havoc-msdt-zeek-logs/*.log --database=havoc-msdt
You will now have a new database in the AC-Hunter UI/web interface or RITA CLI titled “havoc-msdt” you can select and view.
Havoc + Dev Tunnels 24 Hour Zeek Logs
havoc_MSDT_zeek_logs.zip
Size: 11.4 MB
SHA256 Checksum: 2B1182A7AC61DD5B68EB60D80906C954A179C8AB94103F443CC88EBBD25866EB
Discussion
Want to talk about this or anything else concerning threat hunting? Want to share how good (or not so good) other detection tools were able to detect this sample?
You are welcome to join our Discord server titled “Threat Hunter Community” to discuss topics surrounding threat hunting. We invite you to join our server here.
A huge thanks to Keith Chew and Chris Brenton for allowing me the opportunity to contribute to this awesome initiative, as well as their guidance, helpful feedback, and for being a couple of stand-up gents.
Live long and prosper!
Faan has a profound love for the natural world, technology, design, and retro aesthetics. He is incredibly grateful to have discovered cybersecurity as a path relatively late in his life, and his main interests are threat hunting and post-exploitation custom tooling, in particular C2 frameworks and RATs.