Netskope BEAM: Open Source Detector for Supply Chain Compromise

Netskope Threat Labs is pleased to announce the release of a new open-source tool that detects supply chain attacks. Our new tool, Behavioral Evaluation of Application Metrics (BEAM), requires no endpoint agent deployment and will analyze the network traffic you are already capturing in your organization to determine if your applications are communicating with unusual hosts that could be part of an attack. This tool is the subject of a 2025 Black Hat USA briefing.

Supply chain attacks

In December 2020, news broke of a massive cyberattack targeting SolarWinds, a leading provider of observability software. The attack was particularly insidious because it exploited vulnerabilities not in SolarWinds’ own products, but rather in the supply chain that powers them. Malicious code was embedded into several releases of SolarWinds’ software. As a result, thousands of organizations around the world were compromised, including government agencies and major corporations.

This incident highlighted a growing threat to cybersecurity: the software supply chain attack. In this type of attack, malicious actors don’t just target individual companies or users, but rather the complex web of vendors, partners, and suppliers that underpin modern software development.

Why supply chain attacks are so effective

Supply chain attacks are particularly effective because they exploit trust and reliance on third-party vendors. Here are a few reasons why:

• Complexity: Modern software development involves countless vendors, partners, and suppliers. This complexity creates many entry points for attackers.
• Lack of visibility: It’s often difficult to monitor and manage the entire supply chain, making it challenging to detect anomalies or suspicious activity.
• Assumed trust: Organizations may assume that their vendors are secure, which can lead to a false sense of security.

Inspiration for the creation of BEAM

The SolarWinds attack sparked numerous discussions on how to identify and mitigate this type of attack. CISA issued an advisory regarding this attack, which contained the following advice:

Analyze stored network traffic for indications of compromise, including new external DNS domains to which a small number of agency hosts (e.g., SolarWinds systems) have had connections.

We found this particular advice interesting. It spurred some questions:

1. What in the traffic identifies the application that’s generating it, and should any of it be trusted?
2. The advice mentions external connections, but what specifically about the external connections would be suspicious?
3. Can we continuously monitor network traffic and successfully identify unusual behavior for specific applications?

Let’s address each of these questions:

1. In the security community, it appears that we generally avoid using user agent strings for anything because they are easily forgeable. However, when you monitor corporate environments all over the world, which largely consist of people who do not work in security, you’ll have a lot of traffic with unmodified user agent strings. This provides Netskope with the opportunity to build models about commonly used applications based on the user agent strings found in the traffic.
2. We examined numerous anonymized network traffic datasets and identified features that would typically reveal suspicious traffic patterns. After months of research, we identified more than 180 features that effectively profile traffic.
3. We created a proof of concept (POC) to analyze network traffic and identify strange behavior, which inspired this open-source project.

Our proof of concept

We built a POC, validated with some red team testing, that did these three things:

• Ingest network data (parse PCAPs, HAR files, etc.)
• Examine the user agent strings to see what the applications purported to be
• Compare the application traffic to our models to see if they are behaving as expected (given the features we selected)

We conducted a red team/blue team exercise with an early version of BEAM, which included models for a few common applications. Then, we had a red teamer compromise one of the applications to call out to a custom C2 URI without disclosing which application he had compromised or any information about its destination. We used a proxy to monitor all traffic and decrypt HTTPS, simulating a real-world corporate environment that may use a proxy.

At that time, the traffic was analyzed by BEAM using pre-trained models that contained over 60 different features of web traffic. BEAM’s analysis found a 94% probability that the application had been compromised, allowing us to easily identify the red teamer’s compromise. The results encouraged us to continue building and create a free, open-source version of what we developed.

How it works

BEAM accepts files that contain decrypted HTTPS or HTTP traffic, such as PCAP (via Zeek) or HAR files.  BEAM parses the traffic captures and extracts the user agent string to determine what applications the traffic came from. If the user agent string has not been seen before, then it attempts to identify the application based on the user agent string. BEAM uses a large language model (LLM), as well as user agent parser packages, to identify the application associated with the user agent strings. Once it has matched the user agent string to an application, that information is saved in a local database. Now, when BEAM encounters the same user agent string in the future, it obtains the application from the database.

The traffic is enriched with application information, and then the application’s behavior is compared against our pre-trained models. The comparison provides a probability that the application is behaving suspiciously.

The comparison is made by using XGBoost. The applications modelled out of the box are the following:

• Asana
• Box
• Canva
• Kandji
• Omnifocus
• Slack
• Spotify
• Todoist

These applications were chosen because they are quite popular third-party applications that have distinct trends and patterns. Although the current release only includes models for a specific group of applications, our training process allowed us to analyze a wider set. 

BEAM uses the following select set of features:

Running it in your environment

You can access the tool immediately from GitHub here: https://github.com/netskopeoss/beam. We included one sample HAR file as a part of BEAM so you can try it immediately without adding any of your own data. Below is an example of the output generated from our demo HAR file:

The HAR file that was analyzed above primarily contained traffic from Chrome and Box. The traffic from Box was compared against BEAM’s models. BEAM determined that there was more than a 99% possibility of a compromise here because the traffic in the HAR file showed communication from this Box application to an unusual endpoint (xqpt5z.dagmawi.io). It did this by flagging patterns in the traffic that did not match the typical communication patterns of a Box client instance.

In the beam/predictions directory, an accompanying image will be available that displays a SHAP Waterfall plot for each analyzed session. The plot illustrates the reasoning behind the prediction by breaking down the impact of each feature on the model’s output. In this particular case, the plot above shows the following top reasons that this session was indicative of a compromise:

• Reaching out to a strange endpoint that has a high level of entropy (url_entropy)
• Transferring much less data than usual to the server (min_server_bytes)
• Taking much less time than usual to transact with the server (median_time_taken_ms)
• Interacting with the wrong number of hosts for updates (key_hostname_cnt)

Running BEAM on your own applications

BEAM allows users to create models for their own bespoke applications that were not included in the original codebase. To create your own models, you must first capture traffic from the applications you want to model as HAR or PCAP files. BEAM requires at least 50 transactions to gather sufficient data for model building. However, more traffic is better. 

How does it work?

The bespoke application modeling uses unsupervised ensemble methods, which include Tensor Flow, Isolation Forests, and Single Class Support Vector Machines (SVM). BEAM attempts to build a new custom model for any application that has sufficient traffic in the sample and then stores it for use by the detection component. If an application does not have enough transactions in the traffic capture, then BEAM will not build a model for it.

Example usage

Conclusion

If you are interested in this project, please go ahead and sync the repo from GitHub and try it out!

We look forward to collaborating with the open-source community, so please feel free to log issues and contact us with your suggestions.