Malware of the Day – Tunneling RDP with Microsoft Dev Tunnels
What is Malware of the Day?
Lab Setup
Malware: RDP and MS Dev Tunnels
MITRE Tactics: TA0011 Command and Control, T1572_Protocol_Tunneling, T1021.100 Remote Service: Remote Desktop Protocol
Traffic Type: RDP tunneled in HTTPS
Connection Type: 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
Adversary Host: 70.24.242.42 (Kali Linux)
Beacon Delay: N/A
Beacon Jitter: N/A
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
As we explored in our previous post, Microsoft Dev Tunnels is a free tool intended to help developers easily create secure tunneled connections between external endpoints. As we also mentioned, it has several ways it can be exploited by threat actors for nefarious ends.
The Three Major Ways in Which MS Dev Tunnels Can Be Misused
As a quick recap, we mentioned that when executed, Microsoft Dev Tunnels introduces a server between the two connected systems, effectively serving as a proxy (see Image 1 below).
Image 1. The MS Dev Tunnel server is introduced between the victim and adversary, effectively serving as a proxy/redirector.
Based on the starting and endpoints of the tunnel, and the direction of traffic relative to the victim’s network, threat actors can misuse Dev Tunnels in three distinct ways.
Tunneling Egress C2 Traffic Using a Half-tunnel
The simplest configuration to set up, though its benefits are limited to providing a free redirector service protected by Microsoft’s certificate infrastructure.
Image 2. The half-tunnel runs from the MS Dev Tunnel server to the C2 Server, tunneling a C2 connection from the victim to the adversary host.
Tunneling Egress C2 Traffic Using a Full Tunnel
A full tunnel requires higher privileges, increasing operational security risks from the adversary’s perspective, but provides additional advantages: fully encapsulating traffic within the encrypted tunnel and using a Microsoft-signed process to mediate the outbound TLS connection.
Image 3. The funnel tunnel runs endpoint-to-endpoint, tunneling a C2 connection from the victim to the adversary host.
In our previous post we simulated this type of connection, exploring how Havoc C2 traffic appears when encapsulated in a full tunnel.
Tunneling Ingress Traffic Using a Full Tunnel
The adversary-to-victim connection presents both a significant limitation and an intriguing opportunity. The limitation arises from its incompatibility with C2 frameworks, which stems from how Dev Tunnels operates. When constructing a tunnel, Dev Tunnels only exposes listening ports from the host to the Dev Tunnel server. Since C2 agents run on the victim system and are designed to initiate connections rather than listen for them, this approach is incompatible with traditional C2 architecture.
Image 4. The funnel tunnel runs endpoint-to-endpoint, tunneling a non-C2 connection from the adversary to the victim host.
However, this limitation enables a powerful alternative use case. Consider a system that accepts RDP connections (port 3389) from other hosts within its network. While external RDP connections are typically blocked by perimeter firewalls, Dev Tunnels fundamentally changes this dynamic. By creating a tunnel, an outbound connection is established over port 443 to a Microsoft-certified server – a connection type commonly allowed through corporate firewalls. This tunnel then exposes the local RDP port via the Dev Tunnel server.
This creates a significant security risk since attackers can mask incoming connections to normally restricted local ports within an outbound port 443 connection. While traditional incoming connections to port 3389 would be blocked, this method conceals such access within what appears to be legitimate outbound HTTPS traffic.
In today’s Malware of the Day report, we will focus specifically on analyzing this type of connection.
Scenario and Setup
In today’s scenario, an adversary had previously established a foothold on a network via a compromised system. After performing password spraying on a local subnet, they obtained login credentials for a local user’s RDP account on another host (private IP: 10.0.0.4).
To create redundant means of persistence and enable less technically-proficient ransomware “affiliates” direct access to the target network, the adversary planned to use these credentials to establish an RDP connection to the host. However, since the host only allowed RDP connections from other systems on the same corporate LAN, the adversary first established a Microsoft Dev Tunnel from this host to a Microsoft Dev Tunnels server (20.120.56.11).
To complete the full tunnel configuration, the adversary executed the Dev Tunnels application on their system (70.24.242.42). Once completed, they logged into the local RDP service using the discovered credentials.
This setup allowed the adversary to establish an RDP connection through the corporate firewall to a local RDP port that appeared as legitimate outbound HTTPS traffic to Microsoft infrastructure. This strengthened the adversary’s campaign by creating additional means of persistence and operational channels for further control.
RITA
During routine network threat hunting using RITA, our organization discovered an interesting and unusual connection – see Image 5 below.
Image 5. RITA entry for the suspicious connection.
What initially caught our interest was the destination FQDN – use-data.rel.tunnels.api.visualstudio.com. Although a quick lookup indicated this is likely a legitimate Microsoft domain, it had not appeared in the company’s historical Microsoft service usage patterns.
While this novelty alone isn’t a major red flag – Microsoft background services frequently change and evolve – the presence of the word “tunnels” raised specific concerns. The company confirmed that no Microsoft tunneling services were sanctioned for use, and tunneling services are commonly exploited by threat actors.
Additionally, the connection duration spanned almost the entire 24-hour capture period at 23h46m09s, indicating a persistent connection rather than normal intermittent business traffic.
The final anomaly was the data transfer volume of 286.75 MiB. Given this amount was transferred in just 24 hours, it appears unusually high for a passive background service. For comparison, another Microsoft background service (Image 6) transferred only 377.56 KiB during the same period.
Image 6. RITA entry for tile-service.weather.microsoft.com
The volume is thus significantly higher than typical background services that push information updates, suggesting our connection of interest likely involved substantial data transfer.
Given these anomalies, we decided to proceed to investigate further by pivoting to Zeek.
Zeek – dns.log
Since RITA provides the destination FQDN, we used Zeek’s dns.log to identify the specific IP associated with this FQDN. Upon examining the dns.log (Image 7), we discovered an interesting DNS resolution chain.
Image 7. Using the Zed syntax language we located the IP that our FQDN of interest resolves to.
We observed that the query for use-data.rel.tunnels.api.visualstudio.com followed a CNAME chain – a series of DNS alias records that pointed to the final host. The chain traversed several intermediary domains before ultimately resolving to the IP address 20.120.56.11.
AC-Hunter
Having identified both the IP address and confirmed the connection’s persistence, we located 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.
AC-Hunter confirmed that the ASN is 8075, verifying this is indeed a legitimate Microsoft server. The tool also provides convenient access to multiple external reputation checks (see Image 9).
Image 9. A variety of reputation checks are readily available in AC-Hunter.
Our AlienVault review yielded multiple Passive DNS records confirming this server belongs to the Microsoft Dev Tunnels service. This finding aligns with our earlier observation of “tunnels” in the original destination FQDN.
Image 10. AlienVault entry for our IP of interest.
So what does this mean for our investigation? While Microsoft Dev Tunnels is a legitimate service, its use violates our company’s IT security policy. This is particularly concerning given recent reports of threat actors exploiting this service to tunnel Command and Control (C2) traffic.
Given the substantial data transfer we observed over this connection, examining its timing could provide valuable insights.
Custom Python Data Analysis
Since AC-Hunter analyzes data transfer per individual connection, and a persistent connection typically comprises one or just a few connections, this feature wouldn’t serve our current needs.
Instead, we need to examine data transfer rates over time rather than per connection. To accomplish this analysis, we created a Python script utilizing Scapy for pcap analysis, Pandas for data processing, and Matplotlib for visualization. (Note that data transfer graphing is a planned feature for AC-Hunter 7’s future release.)
This script, available for download at the bottom of this page, calculates hourly data transfer in both directions for a specific host pair and destination port. The resulting bar graph provides clear insight into the data flow between our local host and the Microsoft Dev Tunnels server over port 443 (see Image 11).
Image 11. A bar graph showing network traffic flow over time between our local host and MS Dev Tunnels server over port 443.
What immediately stands out is the remarkably consistent data transfer pattern, with only a single outlier at 01:00 AM. This pattern differs significantly from typical C2 operations involving large-scale data exfiltration, which characteristically show extended periods of minimal activity punctuated by brief bursts of high-volume transfers.
The same principle applies to incoming data traffic. If a threat actor were transferring toolsets to the target network via C2 infrastructure, we would expect to see brief spikes of high-volume transfers interspersed with long periods of minimal data transfer corresponding to command issuance.
Therefore, unless this transfer profile was intentionally crafted to appear this way (improbable but not impossible), the pattern suggests this isn’t C2 activity but rather another tunneled service.
While we could make educated guesses about the specific service or narrow it to likely candidates, such conclusions would be purely speculative at this stage.
Given this limitation, let’s examine the endpoint itself to establish which service is interfacing with Microsoft Dev Tunnels.
“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 then used System Informer (formerly Process Hacker) to identify the process responsible for this connection. After launching System Informer with administrative privileges and selecting the Network tab, we were presented with a list of processes and their associated external host IP connections.
Given our earlier confirmation of Microsoft Dev Tunnels’ involvement through AlienVault passive DNS records, we located its process (see Image 12). The established outbound connection over port 443 to 20.120.56.11 confirmed this was our connection of interest.
Image 12. An overview of processes and their outbound connections, including our connection of interest.
To gain more insight into the process, we double-clicked the entry, which takes us to its listing in the Processes tab. A second double-click revealed comprehensive process information (see Image 13).
Image 13. An overview of general process properties provided by System Informer.
Upon examining the General tab, we immediately noticed a significant detail in the process invocation command – the local port extended to the Microsoft Dev Tunnels server was 3389, the standard port for Remote Desktop Protocol (RDP).
This discovery aligns perfectly with our Python script’s findings that showed consistent, substantial data transfer between the hosts. An RDP session generates continuous traffic even when seemingly idle, as it constantly monitors the screen buffer for changes. Moreover, the frequent updates of Windows system elements ensure constant data flow between connected systems, even without active user input like mouse movements or keystrokes.
To further validate our RDP hypothesis, we returned to System Informer’s Network tab to identify the process listening on local port 3389 (see Image 14).
Image 14. System Informer entry for the process listening on local port 3389.
For inbound RDP connections, we indeed expect to see the “svchost.exe” process hosting the “TermService” (Terminal Services) service.
Having uncovered both unauthorized use of a tunneling service and RDP connections from outside the corporate LAN in violation of policy, we can confidently conclude this system is compromised. Given these findings, it is now appropriate for the Response team to assume complete control of the situation.
Conclusion
Today’s report highlights once again how Microsoft Dev Tunnels, a legitimate developer tool, can be weaponized for network intrusion. In this instance, we uncovered an attacker leveraging Dev Tunnels to establish unauthorized RDP access through corporate perimeter defenses – a technique that proved particularly cunning as it masqueraded incoming RDP traffic as outbound HTTPS connections to Microsoft infrastructure.
This attack pattern is especially concerning because it exploits multiple elements of trust. The connection originates from the internal network, uses standard port 443, communicates with Microsoft’s infrastructure, and employs Microsoft-signed executables. Furthermore, by tunneling RDP traffic through this channel, attackers gain persistent access that appears, at first glance, like routine Microsoft service traffic.
Our investigation revealed several key detection opportunities. The consistent, high-volume data transfer pattern characteristic of RDP traffic differs markedly from typical Microsoft background services. Additionally, the persistent nature of Dev Tunnels connections makes them stand out in long-duration connection analysis. Network security monitoring tools like RITA excel at identifying these anomalies through connection duration tracking and data volume analysis.
Organizations can implement multiple layers of defense against such attacks. At the policy level, explicitly prohibiting Dev Tunnels usage provides a clear baseline for security monitoring. Network defenders should maintain comprehensive asset inventories and routinely audit allowed Microsoft services. DNS monitoring proves particularly valuable, as Dev Tunnels employs specific, documented domains that can be monitored or blocked outright in environments where the service isn’t authorized.
This incident underscores a crucial lesson: while attackers increasingly leverage legitimate tools and trusted infrastructure, their operational patterns remain detectable through diligent network security monitoring. Tools like RITA and AC-Hunter, combined with thorough understanding of normal network behavior and proper security policies, enable organizations to effectively identify and investigate such sophisticated abuse of legitimate services.
Custom Python Script
The script used for our data transfer analysis can be found below. Please note that the trace file, source IP, target IP, port, as well as amount of packets (to allow for use of the tqdm progress bar) values were all hardcoded. If you’d like to repurpose this script to analyze other connections you will need to edit these values.
data_per_time.py
File size: 1.8 kB
SHA-256 Hash: 113E02659DAF2409C68C73169DF15EDA42D5AF0CA9F485DE1CF53C07496D4F9F
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.
RDP + Dev Tunnels 1 Hour Capture
RDP_MSDT_1h.pcapng
File Size: 126.5 MB
SHA-256 Hash: 1F81E6D940D6C8172AE03569B9DD72B6DECDAF972E0E71963EBC75297B2AD536
RDP + Dev Tunnels 24 Hour Capture
RDP_MSDT_24h.pcapng
File Size: 1.6 GB
SHA-256 Hash: D6D6CD0D8E504C5400707AAEAEDD5ABEDE67E388853F9B6D4BAD7B94AF58E174
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.gz’ extension) into a temporary directory on the server. In this example, we are uploading the Zeek logs into /tmp/RDP-MSDT-zeek-logs/
Then run the following command:
For AC-Hunter v6.x and RITA v4.x and earlier:
rita import /tmp/RDP-MSDT-zeek-logs/*.log rdp-msdt
For RITA v5.x+:
rita import --logs=/tmp/RDP-MSDT-zeek-logs/*.log --database=rdp-msdt
You will now have a new database in the AC-Hunter UI/web interface or RITA CLI titled “rdp-msdt” you can select and view.
RDP + Dev Tunnels 24 Hour Zeek Logs
RDP_MSDT_zeek_logs.zip
Size: 10.2 MB
SHA256 Checksum: 07BE702F86DFBF0A9D9CAAA4836D066936E5E3192E7405AF487F32434F5909EA
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.