Securing Zoom: How to Detect and Mitigate Threats in Remote Collaboration Tools

As remote work exploded during the pandemic, threat actors’ targets shifted to remote collaboration tools like Zoom, Slack, Teams, Discord, and many more. Attackers have used these in various ways: establishing command and control, as an initial access point to move laterally into other systems, for use in social engineering, and in most cases to compromise confidentiality and gain access to proprietary data.

In this blog, you’ll take a closer look at Zoom. You’ll understand why to monitor Zoom for malicious behavior and how to do this with Panther’s detection-as-code from start to finish: you’ll onboard Zoom as a log source, get to know Panther’s out-of-the-box Zoom detections, and write a custom detection in Python for a new Zoom monitoring use case. 

Zoom: Another target in the supply chain

Attackers target the supply chain because it has a wide reach. One style of attack is infecting the software product itself. While not the first one of its kind, the most notorious example is the SolarWinds breach in which malicious attacker code made it into a SolarWind software update and compromised thousands of SolarWinds customers over the course of seven months.

Another style of supply chain attack is targeting customers of third-party software. We saw this recently when Scattered Spider targeted roughly 136 Okta customers to gain access to their Okta admin consoles. Many of these attacks allowed Scatter Spider to successfully pivot into other systems to exfiltrate data and deploy ransomware.

However, sometimes there are just security flaws in third-party applications that organizations rely on. GitLab recently announced a critical vulnerability in which password reset emails could be sent to an unverified email address. Smart attackers could leverage this vulnerability to prevent access to code repositories, take intellectual property, and push malicious code downstream into the organization’s supply chain.

When it comes to security issues, Zoom has seen it all:

As flaws get fixed, new ones emerge; this is the nature of both tech and cybersecurity. What’s clear is that in a zero trust environment, third-party software within the supply chain must be monitored. Let’s see how to do this with Panther.

How to ingest Zoom into Panther

To ingest Zoom logs into Panther, you’ll need to have a few prerequisites in place: 

  • You are logged into your Zoom account with Admin level access
  • You have a paid Zoom account for reporting
  • View permissions are set for Usage Reports, Sign In/Sign Out, and Admin Activity Logs

With these prereqs, ingesting Zoom into Panther is a quick three-step process:

  1. Create a new Zoom log source within the Panther console 
  2. Create and configure a new OAuth app in Zoom. This allows Panther to integrate with the Zoom API and access Zoom logs
  3. Back in the Panther console, submit your Zoom OAuth app credentials and grant Panther access to your Zoom logs

In lieu of detailing each step here, follow the instructions outlined in the Panther docs. When you are done you’ll be greeted with a success page

Panther’s out-of-the-box Zoom detections

Monitoring Zoom is a part of preventing threat actors from hurting your organization’s reputation by using your account to impersonate and gain information, or by compromising the confidentiality of information. Panther covers these bases with out-of-the-box detections for Zoom operations, which are paired with Zoom sign in/sign out activity monitoring to identify suspicious changes to security measures:

  • Automatic sign out disabled: Detects when a Zoom user turned off your organization’s setting to automatically sign users out after a specified period of time
  • New meeting passcode disabled: Detects when a Zoom User turned off your organization’s setting to require passcodes for new meetings
  • Meeting passcode disabled: Detects when the meeting passcode requirement has been disabled for the user group
  • Sign in method modified: Detects when a Zoom user modified your organization’s sign in method
  • Sign in requirements changed: Detects when a Zoom user changed your organization’s sign in requirements
  • Two-factor authentication disabled: Detects when a Zoom user disabled your organization’s setting to sign in with Two-Factor Authentication
  • User promoted to privileged role: Detects when a Zoom user was promoted to a privileged role

To enable this detection pack within the Panther console, select Build > Packs, then search for Zoom. You’ll find the Panther Zoom Pack, with options to enable and set the version. If you are using the developer workflow, the Panther docs have you covered.

All Panther-managed detection content can be deployed as is, or further customized for your organization. Let’s take a closer look at how to create detections in Panther using detection-as-code, and then you’ll create a custom detection.

Detection as code

Panther uses a flexible and structured approach to writing detections called detection as code (DaC). With DaC, security practitioners author detection content using code and manage the detections using version control, just like software source code. This enables detection development to benefit from software engineering best practices: 

  • Expressive languages that support code reuse
  • Version control for change tracking, rollbacks, and collaboration
  • Test-driven development for quality assurance
  • Automation with continuous integration and continuous delivery (CI/CD) pipelines
  • Agile workflows that deliver updates incrementally to remain open to changing priorities

With Panther, detections are created with Python and YAML. Take a look at the next image that shows the Python detection logic for disabling Zoom two-factor authentication:  

In this Python detection, there are two functions that define the detection logic, rule() and title():

  • rule() is a required function that defines what log data constitutes a match for this detection
  • title() is one of many optional alert functions that defines a dynamic alert title with data from the log, in this case, the Zoom user that disabled 2FA. Log data is acquired using the helper function get(), among others, to access the event object

The return statement defines the value that each function produces: 

  • The rule() function always returns either true or false. True means the detection has a positive match—there’s potentially malicious behavior and an alert triggers. False means there isn’t a match and things are operating normally 
  • For the title() function, this is just a string, and it sets the title of the alert using log data 

Within the rule() function, the return statement uses the all() Python function to check that all of the three logical operations in the list return true, triggering an alert: 

  • The log action is equal to “Update”
  • The log category_type is equal to “Account”
  • The log operation_detail is equal to “Security — Sign in with Two-Factor Authentication: from On to Off”

Finally, Python detection logic is paired with a YAML metadata file that describes details about the alert, including a description, deduplication period, runbook, severity level, tests, and much more. Check out the corresponding metadata file for this detection in Panther’s panther-analysis repo: zoom_two_factor_authentication_disabled.yml

Customize your detection content

Let’s say your organization restricts Zoom meetings by company domain using a Zoom authentication profile. With this configuration, meetings can only be created and attended by people who have a login with a company domain email. The Panther detection pack for Zoom doesn’t cover this use case, so you’ll need to create a custom detection to monitor for changes to this configuration. 

What’s the best way to get started? A simple approach is to clone and build off of existing detections, like the 2FA detection you just reviewed. In fact, you can expect the 2FA detection to be similar to the new detection for authentication profiles, because changes to these settings are both logged through Zoom Operations logs and reported as account-level updates.

But the very first thing you’ll need is relevant log data before you can write detection logic. Within a Zoom admin account for development (as opposed to production), generate log data by disabling then reenabling your authentication profile and adding and removing a new domain configuration. 

Then head over to the Panther Console to explore your normalized Zoom log data: 

  • Select Investigate > Search to open the Search tool
  • Within the Search tool:
    • Select the All Tables drop-down, and then select the Zoom Operations checkbox
    • Choose a timeline for your search
    • Select the Search button to execute

The next image shows example search results from changing the authentication profile and configurations within Zoom. Notice how the action is “Update” and category_type is “Account”, just like the 2FA detection.

Scrolling to the left, you can get a closer look at the operation_detail key that reports which operation has changed and how. As shown in the next image, there are two values that represent the change to the authentication profile:

  • Security – Only authenticated meeting participants and webinar attendees can join meetings and webinars: from On to Off
  • Security – Only authenticated meeting participants and webinar attendees can join meetings and webinars: Delete Configuration …

This means that two detections are needed to cover changes to the authentication profile: one for disabling it and another for changing a configuration for domain name.

To keep things simple, let’s focus on the first case, detecting when an auth profile is disabled. Select the corresponding event log to open up the detail page and select Copy JSON and save it somewhere handy—you’ll use this log data to write tests. 

Now it’s time to craft the new detection by building off of a Panther-managed Zoom detection. Within the Panther Console, select Build > Detections, filter using “Zoom”, and open up the Zoom Two Factor Authentication Disabled detection. 

To build off of this detection, select the three dots in the upper right-hand corner to open a menu of options, as shown in the next image. There’s two ways to build on a detection. You can clone a detection to copy and update it for a new use case, or you can implement inheritance between a Base Detection and one or more Derived Detections. The latter is great for a use case like maintaining multiple copies of the same rule, each with different metadata. For the new Zoom detection, you’re working with a new use case, so cloning is perfect.

When you select Clone, you’ll be taken to the Simple Detection builder. 

Now comes the easy part, updating the existing detection logic to work for the new use case:

  1. Set a descriptive name. For example, you can use Zoom Require Authenticated Meeting and Webinar Participants Disabled
  2. Within the rule logic editor, update the value of the operation_flag variable to match the log data “Security  – Only authenticated meeting participants and webinar attendees can join meetings and webinars: from On to Off”
  3. Within the rule logic editor, update the return statement in the title() function to list a descriptive alert title. The next code snippet is an example of what this could look like: 

f”Zoom User [{event.get(‘operator’, ‘<NO_OPERATOR>’)}] disabled your organization’s “ 

f”setting to require authentication for users joining meetings and webinars.”
The rest of the logic stays the same! The next image shows what this should look like.

Scroll down in the Simple Detection builder to optionally update the severity level.

Next, you’ll update the tests using the log data you got earlier:

  1. For the 2FA Disabled test, update the name to Auth Req Disabled and within the JSON, change the value for “operation_detail” to “Security – Only authenticated meeting participants and webinar attendees can join meetings and webinars: from On to Off”
  2. For the 2FA Enabled test, update the name to Auth Req Enabled and within the JSON, change the value for “operation_detail” to “Security – Only authenticated meeting participants and webinar attendees can join meetings and webinars: from Off to On”
  3. Delete the last test called Sign In Apple ID

Next, run your tests to confirm they work as expected.

And that’s it! You are ready to deploy your custom detection. 

Conclusion

A decade earlier, you wouldn’t find Zoom logs in a SIEM, but now monitoring Zoom is as vital as monitoring any remote collaboration tools in the supply chain to protect your reputation and the confidentiality of your information. For a look into securing the software supply chain, read about GitHub monitoring with Panther.  

Panther is a cloud-native SIEM that empowers modern security teams with real-time threat detection, log aggregation, incident response, and continuous compliance, at cloud scale. Request a demo to talk with a Panther expert about your detection needs.

Table of Contents

Recommended Resources

Escape Cloud Noise. Detect Security Signal.
Request a Demo