Hiding in the Shadows: Covert Tunnels via QEMU Virtualization

Attackers are getting increasingly creative—not just with their payloads, but with how they deliver and operate them. In a recent Incident Response engagement, TrustedSec investigated a case involving an attacker who used a combination of social engineering, remote support tools, and virtual machine (VM) deployment to gain access to a corporate endpoint and attempt covert communications. What started as a Microsoft Teams vishing attack escalated into an intrusion involving Qemu-based Tiny Core Linux virtual machines and an attempted reverse SSH tunnel. Though not highly sophisticated, this engagement highlighted how virtualization can be used to avoid host-based detection such as EDR and AV tools as well as the effectiveness of social engineering.

Initial Access

This intrusion started as a well-executed vishing attempt. A user was contacted via Microsoft Teams by someone claiming to be from their IT support team. This “support tech” was actually coming from an external Microsoft 365 tenant, and thanks to Team’s default settings, external communication was allowed.

Once the call started, the threat actor instructed the user to open Quick Assist, which is a native Windows feature that allows for interactive remote management of endpoints by relying on Remote Desktop Protocol (RDP). Essentially, this is a built-in remote monitoring and management (RMM) tool, much like familiar third-party options, such as: AnyDesk, Atera, TeamViewer, etc. The threat actor then instructed the user to download Zoho Meeting, another remote management tool. Often, attackers will place several different RMM tools on a host to have a better chance at persistence in case one is discovered and removed.

After opening the Quick Assist session, the threat actor instructed the user to run a curl command to download a ZIP file from an attacker-controlled IP address. Due to a lack of telemetry, TrustedSec was not able to capture this command; however, the process execution of the curl.exe process was captured, followed by the introduction of updqem.zip to the file system.

Leveraging the access the attacker had gained via Quick Assist, the following file extraction command was captured within the host’s ConsoleHost_history.txt file:

Over the course of one (1) week, the threat actor attacker contacted the user twice. Several days after the initial contact to the user, the threat actor contacted the user to inform them that the “IT support steps” they had taken days prior had not worked. In this second instance, the threat actor appeared to carry out the same steps.

QEMU VM Deployment

Digging into the host’s $MFT, the aftermath of the extraction of updqem.zip was tracked to a set of nested directories on the endpoint:

C:\ProgramData\update\

C:\ProgramData\update\update

C:\ProgramData\update\stl

C:\ProgramData\update\update\share

C:\ProgramData\update\stl\share

Within these directories, two (2) executables immediately stood out: C:\ProgramData\update\stl\stl.exe and C:\ProgramData\update\tc.exe (also present in the previously mentioned console history). Both files are tied to Qemu, an open-source emulation tool that allows users to run VMs on top of the existing OS. The attacker clearly opted for a portable VM deployment rather than a traditional malware drop, which allowed them to avoid detection.

In addition to the Qemu binaries themselves, two (2) VBS files were observed:

• C:\ProgramData\update\update\update.vbs
• C:\ProgramData\update\stl\##_START_##.vbs.

The contents of both files pertained to the deployment of a VM via Qemu but used slightly different methods. The first script, update.vbs, leverages the Wscript shell to execute tc.exe using a config file (upd.conf) to pass in VM parameters.

As the contents of the file demonstrate, the VM to be created included 512MB of RAM, attaches tc.qcow2 as the image file, defines the virtual hard disk to be emulated (IDE), and allows basic Internet access.

In contrast, the ##_START_##.vbs file forgoes the usage of a configuration file and instead explicitly states the configuration parameters within the command line. Additionally, this method makes use of a smaller RAM allocation. These differences in methods are likely associated with the threat actor’s claim that the initial setup was not functional.

From further $MFT analysis, two (2) separate image files were identified: C:\ProgramData\update\stl\tc.qcow2, introduced to the system first, and C:\ProgramData\update\update\tc.qcow2, which was introduced to the system several days later. It appears that after the first virtual environment failed to deliver results, the attacker tried again with a heavier setup—possibly with more tools or a more complete OS image. Fortunately, TrustedSec was able to extract the image files to have a better look into the attacker’s activities on the deployed VMs.

SSH Backdoor Attempts

Both image files deployed Tiny Core Linux VMs using small image files. Despite the minimal footprint of this OS, we still had access to bash history, which turned out to be quite revealing.

The first attempt at building a backdoor appeared unsuccessful. In this method, the attacker leveraged wget to download a payload from an attacker-controlled endpoint at 149.28.198[.]232.

This payload is suspected to contain backdoor code to allow the attacker continued access to the user’s machine.

In an attempt at persistence, the attacker is also observed editing several key files native to Tiny Core Linux. The first file to be edited, bootlocal.sh, is a script that runs defined commands at boot.

Taking a look at the contents of the bootlocal.sh file confirmed this method was used to ensure the persistence of the 123.out payload. This script creates a loop that pings 45.77.4[.]101, an attacker-controlled endpoint. If the ping fails, the output is ignored, and the process is restarted in two (2) seconds. Once the ping succeeds, 123.out is executed as the tc user.

The attacker also updated filetool.lst, which tells the OS which files and directories should persist after a reboot, as Tiny Core is stateless by default.

The contents of filetool.lst also confirm an attempt at persistence by defining the following directories to be included. The 123.out payload is contained within the home/tc directory, therefore confirming that this file will also persist after a reboot. The attacker also ensures their configuration of the machine is persistent by including the opt directory.

Several days later, the attacker determined this method was not functional and reached out to the user for a second time. The second image file presented was much larger than the first, suggesting a change in the attacker’s strategy. The attacker began on the second VM by ensuring SSL and NoSSL applications were present on the host by again leveraging wget.

Following this, the attacker was observed editing a file that is not native to the Tiny Core Linux OS, hostname.sh.

This custom script generated a randomized, five (5) character hostname prefixed with tc-, possibly to help the attacker track or mask individual VMs.

Next, the attacker leveraged the Tiny Core package manager command, tc-load, to install openssh.

Once SSH was set up, the attacker added the relevant configurations, scripts, and directories to filetool.lst to ensure everything persisted across reboots.

The bootlocal.sh script file was also updated to automatically run hostname.sh, launch the downloaded SSL tools, and start the SSH service on boot.

With the configuration of the machine now complete, the attacker attempted to build a reverse SSH tunnel back to their server, 137.184.4[.]169, over port 443—an effort to hide the traffic in plain sight using HTTPS.

The SSH command also showed some anti-forensic efforts by instructing the SSH configuration to store known hosts within /dev/null. Typically, this information is directed to the .ssh/known_hosts file, which records the public keys of hosts the user has connected to in the past. This method ensures this information is not stored and therefore cannot be referenced by investigators. StrictHostKeyChecking is also disabled, another effort to ensure public key information is not stored on the host.

What stands out here is not the technical complexity but rather, the creativity in the approach. Using a guest VM to build a reverse SSH tunnel is clever, especially in environments where EDR tools are focused on the host OS. It’s also a reminder that even unsophisticated actors can cause covert intrusions when social engineering is successful.

Remediation and Prevention

In similar intrusions, defenders should ensure that all traces of the threat actor are eradicated from the system through system reimaging and/or device confiscation and issuing the user a new device. Additionally, the affected user’s credentials should be reset and any active sessions destroyed.

Several steps can be taken by organizations to prevent similar intrusions:

• Restrict external communications in Microsoft Teams
  • Disable external tenant communication unless explicitly required. If some level of external communication is required for job functions, consider implementing a tenant whitelist.
• Disable or restrict remote access tools
  • Quick Assist can be removed from endpoints if not business critical. This can be done via Group Policy (Computer Configuration > Administrative Templates > System > Remote Assistance).
  • Block unauthorized remote tools like Zoho Meeting, AnyDesk, Atera, TeamViewer, etc., if not legitimately used for support functions.
• Monitor or restrict unauthorized virtualization software
  • Monitor endpoints for virtualization software such as Qemu, VirtualBox, VMware, etc., particularly if not approved for use. These can also be blocked on a per-user group basis if there is no legitimate business purpose for certain users to have this software.
  • Monitor for the introduction of image file types on endpoints where virtualization behavior is not expected.
• Review firewall and network segmentation policies
  • Block outbound SSH traffic to external IP addresses unless explicitly allowed.
  • Prevent guest VM traffic from traversing sensitive network segments.
• User awareness and training
  • Educate staff about the dangers of unapproved remote management tools and how to verify internal IT communication.

IOCs