Want to see Spyderbat in action?
This blog explains what Microsoft Visual Studio Code Remote Tunnel is, how it can be exploited and how Spyderbat can detect and restrict it in real time
“Microsoft VS Code Remote Tunnel" refers to a feature or functionality provided by Visual Studio Code (VS Code). This feature enables users to share their VS Code development environment on the web, creating a secure connection between their machine and the internet. This extension grants full access to the remote machine through the terminal, allowing seamless interaction and development capabilities without requiring the source code to reside in the local environment. It only requires you to authenticate via your GitHub account.
One notable avenue for potential exploitation arises from the method of tunnel establishment. Users can create tunnels either through the VS Code UI or by utilizing the command line, achieved by downloading the portable version of code.exe
However, this seemingly secure connection may pose risks, an attacker just has to upload the binary, which won't be detected by any anti-virus since it is a legitimate and signed Windows binary.
Once the binary is executed on the machine, it may enable the attacker to exploit vulnerabilities, gain unauthorized access, or conduct further malicious activities.
DNS Detection
As per the Microsoft documentation, “Tunneling requires outbound connections to be made to the service hosted in Azure. No inbound connections are required to use the service.”
Tunneling securely transmits data from one network to another via the following dev tunnels.
- Dev Tunnels
- global.rel.tunnels.api.visualstudio.com
- [clusterId].rel.tunnels.api.visualstudio.com
- [clusterId]-data.rel.tunnels.api.visualstudio.com
- *.[clusterId].devtunnels.ms
- *.devtunnels.ms
But, then the real question arises, how to monitor the network traffic effectively and know what’s happening within your system? One of the approaches could be using `tcpdump`, a command line packet analyzer, discussed below.
TCP DUMP
To specifically monitor outbound traffic to a particular domain, such as global.rel.tunnels.api.visualstudio.com, you can utilize the following tcpdump command with a filter for the destination (dst) host:
$ sudo tcpdump -i <interface> -n dst host global.rel.tunnels.api.visualstudio.com
> 14:25:58.660776 IP Inspiron-5490.51802 > 20.207.70.99.https: Flags [P.], seq 1317869176:1317869338, ack 2043159226, win 3024, options [nop,nop,TS val 1765887031 ecr 4221996349], length 162
The above tcpdump output indicates an established connection from my device ("Inspiron-5490.51802") to the destination IP "20.207.70.99" on the HTTPS port. The packet flags [P.] suggest that this packet contains data and is part of an ongoing communication session.
However, continually executing tcpdump commands to investigate network traffic is impractical. This is where Spyderbat comes into play.
Spyderbat is a cloud-native runtime security platform designed to monitor, alert, and fortify your development or production environments.
The implementation of Spyderbat involves installing Spyderbat eBPF nano agents onto your cluster, and from there, the platform works its magic. The nano agents collect kernel-level workload data with negligible performance impact and no management overhead which allows for continuous monitoring.
An easy-to-visualize graph database is also built in the Spyderbat console with the data collected.
It also offers different graphical view modes and allows you to go back in time up to 90 days by default and more, and see what all happened day by day, minute by minute! It’s like having a time machine!
Spyderbat Detection:
Spyderbat also employs advanced analytics that monitor your containerized and Linux workloads and the potential malicious activities involved and sends out alerts in real time. But first, let’s understand how Spyderbat detects a VS code remote tunnel.
Spyderbat analyzes and detects every outbound connection from your host machine to these domains, required to establish the tunnel.
- *.tunnels.api.visualstudio.com
- *.devtunnels.ms
It then generates a “Redflag” with high severity on the associated connection. A redflag on the connection lets the user know that a remote tunnel was established with the impact of it, the source machine (or container), connection details, and other necessary information involved. This way, a user has information even if the remote tunnel was established intentionally.
Spyderbat provides the overall context of connection details along with the process that initiated it and the flag details. You can find more on the general Spyderbat approach to network observability (using eBPF) here. >
To witness this Spyderbat detection in action and explore these functionalities firsthand, you can conveniently check out the Spydergraph public tracer. The best part? No account creation is required for this exploration.
Further, with Spyderbat’s new notification system, you can get notified via email/slack/AWS SNS targets whenever these incidents occur. Refer to the Notification docs here
Automating Response
But, what if your organization is against using a VS code remote tunnel and the potential risks involved with it? Spyderbat, allows you to go further by completely killing the process initiating the DNS request required to establish the tunnel. Note that, the killing of the process or the pod involved is quick, it happens within a few seconds from the time it is first observed in the Spyderbat environment. And all of this is achieved pretty straightforwardly, by having a network policy for the same.
Spyderbat offers a useful feature of Guardian which literally as the word suggests, guards your containerized applications through policies.
Spyderbat automatically creates a runtime “fingerprint” whenever a container or Linux service runs. These fingerprints capture or profile the container's normal runtime and network activity of the container. These fingerprints can then be turned into policies that specify the normal expected behavior or desired state of our workloads.
Guardian policies can also contain “response actions” that dictate the desired response when a workload is observed deviating from a policy from the desired behavior. For example, we can create alerts or notifications when workload behavior deviates, or even take remediative (data plane or control plane) actions such as killing a Kubernetes pod or killing a process inside the container.
Additionally, you can also use your custom actions via webhooks in Guardian.
Spyderbat further enhances the user experience by providing a graphical representation of the policy, as shown below, to understand the machine or container scope (selectors) mentioned in the policy in real time. It also provides a summary of all of the policy violations following the application of the policy.
To see it in action by yourself, you can also get started by creating an account at www.spyderbat.com for free, setting up in 2 minutes, and having a policy for one of these use cases (using less than 2% of your cloud resources).
Happy Tracing till then!
Spyderbat: Next generation runtime security built for Kubernetes and multi-cloud
Spyderbat is the next generation runtime security providing true IDS/IPS, posture management, and remediation in runtime for Kubernetes and Multi-cloud. See how you can:
- Gain complete visibility and control in all regions by harnessing the power of eBPF Spyderbat eBPF Nano Agents.
- Collect kernel-level workload data with negligible performance impact and no management overhead (using less than 2% of resources).
- Visualize runtime activity, detect attacks, recognize anomalies, and automatically take the right action to protect app behavior and minimize downtime.
Compare Spyderbat's critical capabilities with other cloud security solutions to see where they fall short. Elevate your cloud runtime security.
Want to see Spyderbat in action?
