It’s not just Zoom, Hunting for All Video Conference Traffic using Awake
The last few weeks have seen an endless stream of news articles, tweets and blogs discussing Zoom’s apparent security shortfalls. Many security teams are being asked to hunt for not just usage of Zoom but also other services out there that may have similar concerns and are in use by the organization. Forbes also uncovered a recent Microsoft Teams’ security issue.
Traditionally security teams track down these services on the network by IP, the use of non-standard ports, domain names, or TLS certificate metadata.
The problem with using these methods include:
- IP Addresses: You need to know the IP addresses you are looking for before you can search your environment and identify the traffic (assuming you have that data recorded somewhere too). This is complicated, especially with the bigger conference calling services, there are way too many globally distributed servers and IP addresses, and they can change.
- Non-Standard Ports: A lot of the services use standard ports and to detect the ones that may use non-standard ports you again need prior knowledge of what those ports are.
- Domains: Domains can be effective, but a lot of these services leverage multiple fully qualified domain names (FQDNs) not just a single domain like “zoom.us”. Again, it’s easy to keep a list of the popular service domains, but there are a lot of video chat services that are unknown to your security team and tracking them domain by domain doesn’t scale.
- TLS Certificates: You get the trend line here. These can change too and it’s one more item you need to keep track of somehow.
Leveraging Awake for Visibility
Using the Awake Platform, it’s easy to track these services by using classifications. As traffic is analyzed by the Awake Platform, our analytics engine creates a classification path all the way from the interface to the application. In case of Zoom, the path would be Zoom over HTTPS over SSL over TCP over IPV4 over ETH
Each of these items can be searched as a group or individually.
In this example below, we are running a search for Zoom using the query “activity.classification contains ZOOM”, which is looking at “ZOOM” inside the classification section. Notice we make no mention of domains, IPs, TLS certificates or anything else. This makes it far easier for even a relatively junior analyst to hunt with.
This is great, but as mentioned above, there are a lot more conference calling /telepresence/video sharing apps than Zoom. Don’t limit yourself to just identifying the popular ones. To expand this search to all video chat apps is trivial with Awake. We can search all traffic for classifications that contain VIDEO_CHAT or AUDIO_CHAT.
In this example, google.com is flagged for using of Google Meet / Hangouts, zoom.us is self-explanatory, Discord is a chat application that can be used for collaboration, and wbx2 is related to Cisco’s WebEx.
We can now fine tune this view. For instance, a use case we hear about often is filtering out connections from mobile devices on “dirty” networks. This is also trivial and shows the flexibility of Awake’s adversarial modeling language (AML).
At first, we run a search for any VIDEO_CHAT application usage. In our example dataset, this returns upwards of 272 devices.
Next, we will run that same query, except we now exclude any device that’s a mobile device and any device that’s within a guest network.
We have now filtered the data set down to approximately 200 devices. We can tweak the filters as you can easily see to broaden or narrow the list based on information such as the users involved, the length of access, operating system version and literally thousands of other parameters. Most importantly, as explained in a prior blog post on network threat hunting, we can even save this as a model that automatically hunts and can alert if new behaviors emerge!
In closing, you can see how Awake’s built-in network traffic classification analytics make it easy to identify devices leveraging not only Zoom, but many other video conference services; all without having to track down IPs, domains, TLS metadata or anything else.
In the meantime, if you’re the host of a meeting, do the following items to make your meetings more secure.
- Set meeting passwords
- Limit the number of people attending meetings
- Don’t use your personal meeting id, use a randomly generated one.
- Don’t share your meeting IDs on social media / publicly etc.
- Validate the individuals connected during roll call
- Require your internal staff to use their full names
- Enable the “ding” bell when a new person joins and take the time to validate them
- Set up wait rooms and manually pull people into the meeting
- Have a plan for what to do if someone that’s uninvited joins the meeting. Be prepared to end the meeting immediately.
Also, consider as an organization maintaining a list of approved conference applications and set up your security operations team to hunt for those that might be unapproved and potentially leaking data.
If you liked what you just read, subscribe to hear about our threat research and security analysis.
Director, Awake Labs
Dig Deeper with These Resources
Awake Security 2 Minute Explainer Video
What if security could think? What if it could sense danger, calculate risk, and react quickly based…
The Internet’s New Arms Dealers: Malicious Domain Registrars
This report dives into the results of a multi-month investigation that uncovered a massive global surveillance campaign…