Screen sharing applications have changed the landscape of the modern office. These tools allow users to remotely control another PC and receive image data that represents what the local user would see on their monitor. This greatly simplifies telecommuting, support calls, or remote access to files. A question we often receive from customers using Scrutinizer for monitoring network utilization and traffic is, “How can we identify screen sharing traffic on our network?” With vulnerabilities recently found in products like TeamViewer, it is more important than ever to gain visibility into the who, what, when, and where of screen sharing network traffic.

In early December of 2017, a vulnerability was found in the popular sharing application TeamViewer. The vulnerability allowed an attacker to access the permissions that govern who can control the sharing host. All screen sharing applications have the ability to pass keyboard and mouse input, with a rigid permission structure in place that dictates who has the authority to send and receive remote control. This means that an attacker who can modify these permissions can then gain control of machines without the consent of the sharing user. Furthermore, this exploit alters values in memory that allow the user to gain additional options in the GUI. These would otherwise have been suppressed. While a patch has been issued to prevent this specific TeamViewer exploit, it is a clear example of why it is important to have visibility into this type of traffic.

How to Identify Screen Sharing Network Traffic

There are a few ways we can detect screen sharing network traffic. In the case of TeamViewer, a unique port, 5938 TCP, is used to communicate between the client and the server. This is helpful information because we can simply search our NetFlow data for flows that list 5938 as a SRC or DST port. To accomplish this in Scrutinizer, we can take advantage of the “Conversations by Well-Known Port (WKP)” pair report.

Reporting by Well Known PortFrom the Status Tab in Scrutinizer, use the search field in the device explorer to find the NetFlow-exporting device you would expect the screen sharing traffic to have traversed. Expand the device and click on reports, in the menu that opens select Pair > Conversation WKP.

This report defines a row as all of the flows in a given time interval grouped by unique combinations of SRC host, DST host and DST port. In our TeamViewer example, we know the port that will be used, so we will create a filter to only show us traffic that was conducted over 5938.

To add a filter to a report in Scrutinizer: Adding Filters in Scrutinizer

  1. Click the “Add” button next to the filters label on the left-hand side of the report.
  2. In the window that opens, select “Source / Destination Port”
  3. Enter the port number you are looking for—in this case, “5938”
  4. We will leave the directionality set to “both” in case we are considering multiple interfaces
  5. Finally, we will leave this as an “include” filter so we only see traffic that meets our criteria

Reviewing Our Results in Scrutinizer

Netwrok Traffic Report Results

Our resulting report shows us all of the TeamViewer traffic that has traversed this exporting device. Without knowing any of the hosts that could have possibly been running the application, we have now identified both the source and destination, simply by filtering on port. While it is easy to identify the local machine, we now have some public IP addresses to consider. Some of the external hosts have resolved via DNS, showing us that they are in fact TeamViewer servers, but others have not. In these instances, Scrutinizer allows you to quickly pivot into a lookup.

Clicking on one of the IP addresses in question will IP Lookup in Scrutinizerdisplay another report menu. This time, we want to select the “Other Options” category, then “Lookup”.

In this case, I selected “185.188.32.2” to perform a lookup against. The result shows this to be another legitimate TeamViewer server, as the address is registered to the company that provides the product.
IP Lookup Result

 

Now that we can easily identify screen sharing network traffic, we can further take advantage of Scrutinizer by setting up TeamViewer as an approved application.

To set up an application to be automatically recognized in Scrutinizer, navigate to Admin > Definitions > Applications

Define Applications in ScrutinizerClick “Add” and a window will open that allows you to define the application. This can be applied to a subset of hosts or all IP addresses.

While patching the application is the first step to ensuring that vulnerabilities are not present in your environment, monitoring the network for activity is essential in the continued safe use of products that allow remote control. Using a tool like Scrutinizer gives you a new perspective into your network traffic, providing deep insight and visibility that would otherwise not be available. If you’re a current Scrutinizer user, try the above method and see if you can find Screen Sharing traffic in your environment. If you’re new to Scrutinizer, you can get the product up and running quickly to start looking into your network in a whole new way!

Adam Howarth author pic

Adam Howarth

Adam Howarth is a technical support representative at Plixer. He works with customers from all over the world, making sure they are getting the most out of their Plixer products. Adam holds CCNA Security certification as well as CNSS 4011 recognition. He also has experience in retail networking, POS systems, ERP administration and has a background in statistical analysis. In his free time he enjoys playing music and audio engineering.

Related

Leave a Reply