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.
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.
To ingest Zoom logs into Panther, you’ll need to have a few prerequisites in place:
With these prereqs, ingesting Zoom into Panther is a quick three-step process:
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
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:
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.
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:
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():
The return statement defines the value that each function produces:
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:
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.
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:
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:
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:
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:
Next, run your tests to confirm they work as expected.
And that’s it! You are ready to deploy your custom detection.
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.