Accelerate your SASE deployment with the SASE Week Backstage Series. Explore sessions

close
close
  • Why Netskope chevron

    Changing the way networking and security work together.

  • Our Customers chevron

    Netskope serves more than 3,400 customers worldwide including more than 30 of the Fortune 100

  • Our Partners chevron

    We partner with security leaders to help you secure your journey to the cloud.

A Leader in SSE.
Now a Leader in Single-Vendor SASE.

Learn why Netskope debuted as a leader in the 2024 Gartner® Magic Quadrant™️ for Single-Vendor Secure Access Service Edge

Get the report
Customer Visionary Spotlights

Read how innovative customers are successfully navigating today’s changing networking & security landscape through the Netskope One platform.

Get the eBook
Customer Visionary Spotlights
Netskope’s partner-centric go-to-market strategy enables our partners to maximize their growth and profitability while transforming enterprise security.

Learn about Netskope Partners
Group of diverse young professionals smiling
Your Network of Tomorrow

Plan your path toward a faster, more secure, and more resilient network designed for the applications and users that you support.

Get the white paper
Your Network of Tomorrow
Introducing the Netskope One Platform

Netskope One is a cloud-native platform that offers converged security and networking services to enable your SASE and zero trust transformation.

Learn about Netskope One
Abstract with blue lighting
Embrace a Secure Access Service Edge (SASE) architecture

Netskope NewEdge is the world’s largest, highest-performing security private cloud and provides customers with unparalleled service coverage, performance and resilience.

Learn about NewEdge
NewEdge
Netskope Cloud Exchange

The Netskope Cloud Exchange (CE) provides customers with powerful integration tools to leverage investments across their security posture.

Learn about Cloud Exchange
Aerial view of a city
The platform of the future is Netskope

Intelligent Security Service Edge (SSE), Cloud Access Security Broker (CASB), Cloud Firewall, Next Generation Secure Web Gateway (SWG), and Private Access for ZTNA built natively into a single solution to help every business on its journey to Secure Access Service Edge (SASE) architecture.

Go to Products Overview
Netskope video
Next Gen SASE Branch is hybrid — connected, secured, and automated

Netskope Next Gen SASE Branch converges Context-Aware SASE Fabric, Zero-Trust Hybrid Security, and SkopeAI-powered Cloud Orchestrator into a unified cloud offering, ushering in a fully modernized branch experience for the borderless enterprise.

Learn about Next Gen SASE Branch
People at the open space office
Designing a SASE Architecture For Dummies

Get your complimentary copy of the only guide to SASE design you’ll ever need.

Get the eBook
Make the move to market-leading cloud security services with minimal latency and high reliability.

Learn about NewEdge
Lighted highway through mountainside switchbacks
Safely enable the use of generative AI applications with application access control, real-time user coaching, and best-in-class data protection.

Learn how we secure generative AI use
Safely Enable ChatGPT and Generative AI
Zero trust solutions for SSE and SASE deployments

Learn about Zero Trust
Boat driving through open sea
Netskope achieves FedRAMP High Authorization

Choose Netskope GovCloud to accelerate your agency’s transformation.

Learn about Netskope GovCloud
Netskope GovCloud
  • Resources chevron

    Learn more about how Netskope can help you secure your journey to the cloud.

  • Blog chevron

    Learn how Netskope enables security and networking transformation through secure access service edge (SASE)

  • Events and Workshops chevron

    Stay ahead of the latest security trends and connect with your peers.

  • Security Defined chevron

    Everything you need to know in our cybersecurity encyclopedia.

Security Visionaries Podcast

The Future of Security: Quantum, AI, and Macro-political Change
Emily Wearmouth and Max Havey speak with Netskope CEO Sanjay Beri and CTO Krishna Narayanaswamy about the future of security.

Play the podcast Browse all podcasts
The Future of Security: Quantum, AI, and Macro-political Change
Latest Blogs

Read how Netskope can enable the Zero Trust and SASE journey through secure access service edge (SASE) capabilities.

Read the blog
Sunrise and cloudy sky
SASE Week 2024 On-Demand

Learn how to navigate the latest advancements in SASE and zero trust and explore how these frameworks are adapting to address cybersecurity and infrastructure challenges

Explore sessions
SASE Week 2024
What is SASE?

Learn about the future convergence of networking and security tools in today’s cloud dominant business model.

Learn about SASE
  • Company chevron

    We help you stay ahead of cloud, data, and network security challenges.

  • Careers chevron

    Join Netskope's 3,000+ amazing team members building the industry’s leading cloud-native security platform.

  • Customer Solutions chevron

    We are here for you and with you every step of the way, ensuring your success with Netskope.

  • Training and Accreditations chevron

    Netskope training will help you become a cloud security expert.

Supporting sustainability through data security

Netskope is proud to participate in Vision 2045: an initiative aimed to raise awareness on private industry’s role in sustainability.

Find out more
Supporting Sustainability Through Data Security
Help shape the future of cloud security

At Netskope, founders and leaders work shoulder-to-shoulder with their colleagues, even the most renowned experts check their egos at the door, and the best ideas win.

Join the team
Careers at Netskope
Netskope’s talented and experienced Professional Services team provides a prescriptive approach to your successful implementation.

Learn about Professional Services
Netskope Professional Services
Secure your digital transformation journey and make the most of your cloud, web, and private applications with Netskope training.

Learn about Training and Certifications
Group of young professionals working

Introduction link link

Attackers are adding new and sophisticated command-and-control (C2) capabilities in their malware that easily evade common static defenses based on IPS signatures or IP/domain/url block lists by using common, widely-available C2 framework tools like Cobalt Strike, Brute Ratel, Mythic, Metasploit, Sliver, and Merlin. These tools provide post-exploitation capabilities including command-and-control, privilege escalation, and actions on host and were originally designed for penetration testing and red team operations.

However, attackers have hijacked and embedded these same toolkits for malicious purposes as many products are open-source, such as Mythic and Merlin, while other commercial products, such as Cobalt Strike and Brute Ratel, have been stolen by attackers through hacked copies or leaked source code. This has effectively turned these same tools into adversarial C2 frameworks for malicious post-exploitation.

The tools can easily shape and change many parameters of C2 communications, enabling malware to evade current defenses even more easily and for longer periods, causing greater damage within victim networks, including: stealing more data, discovery of more valuable data, unavailability of business apps/services, and maintaining hidden access to networks for future damage.

Current approaches to detecting the latest malware using C2 frameworks utilize static signatures and indicators including detection of implant executables, IPS signatures for detection of C2 traffic, and IP/URL filters that are inadequate to dealing with the dynamic, malleable profiles of the widely-available C2 framework tools.

A new approach is required that is not so rigidly tied to known attacks, but based on anomaly detection of a comprehensive set of signals fed into trained machine-learning models with fine-grained tracking of device and user risk. This approach will supplement existing approaches, but can dramatically increase detection rates while keeping false positives low and future-proofing against evolving C2 traffic patterns that are easily enabled by these same C2 framework tools.

This paper discusses the gaps in current approaches and the increased efficacy from using a focused machine-learning approach with additional network signals and fine-grained risk metrics based on models at the user and organization level. We also discuss some of the key challenges in testing the efficacy of any C2 beacon detection solution.

 

Adversarial C2 Frameworks link link

Cobalt Strike, Metasploit, Mythic, and Brute Ratel are some of the commercial and open-source adversary simulation tools originally designed for red team testing of malware detection. These toolkits are sometimes referred to as threat emulation tools or C2 frameworks as they provide a rich feature set (Gill) for simulating real threat activity during red team operations with a focus on the post-exploit command-and-control parts of the attack chain.

We may use some of these terms interchangeably throughout the paper but will generally use C2 frameworks to emphasize that these tools are being used by malicious actors to impact production environments and that the problem to solve is much more than simulations or emulations by friendly internal red teams.

These C2 framework tools have been embedded, hacked, or stolen and used by numerous attackers (“Cobalt Strike: International law enforcement operation tackles illegal uses of ‘Swiss army knife’ pentesting tool”), including nation-state actors such as Russia’s APT29 in SolarWinds (“SolarWinds Supply Chain Attack Uses SUNBURST Backdoor”) and the PRC’s TA415 (Larson and Blackford) to enhance and evolve the stealthy communication capabilities of various RATs, botnets, and C2-enabled malware.

Cobalt Strike is the most popular C2 framework tool, and we use it as a specific example throughout this paper, though the observations apply to all similar tools. The following Cobalt Strike high-level architecture diagram shows its basic components (Rahman) and the runtime attack flow.

Cobalt Strike High-Level Architecture

Figure 1: Cobalt Strike High-Level Architecture

 

#

Attack Step

Description

1

Initial access / infectionInitial infection vector, including downloader and loader for the beacon payload.

2

Call home (C2)

Beacon calls home to Team Server utilizing HTTP/HTTPS/DNS typically. May utilize domain/IP obfuscation via redirectors such as proxies, domain fronting (e.g. CDNs) or domain masquerading. Beacons may also chain communications to bypass internal network segmentation.

3

Attacker command and controlAttacker controls Beacon, issuing various commands. May utilize Aggressor Scripts to automate/optimize workflow.

4

Execute commandsThe Beacon may use Execute Assembly (.NET executables) in a separate process or Beacon Object Files within the Beacon session/process, extending post-exploit capabilities. Memory injection is used to evade detection from endpoint defenses focused on files and disk activity associated with malicious files.

5

Actions on hostNumerous built-in actions are provided for new capabilities via extensions as BOFs or Execute Assembly.

Table 1: Attack Chain using Cobalt Strike C2 Framework

 

Cobalt Strike and similar toolkits allow for an easy and wide range of configurability in the HTTP/S traffic, producing C2 traffic that often appears benign, looks like normal HTTP/web traffic, and is similar to web browser or popular application traffic. There are default configurations provided with the tools that emulate both known malware as well as known valid applications.

Although DNS is also supported as a C2 protocol, we will focus the discussion on HTTP/S C2 as it reflects the bulk of network traffic in/out of an organization, is more complex due to the variety of applications using HTTP/S, and attracts the majority of malicious actors who are trying to hide amidst the network noise including legitimate benign C2 beacons.

The toolkits are highly configurable (via malleable profiles) and can easily vary the timing, frequency, volume, application protocols, destination IPs/domains, user agents, HTTP headers, HTTP verbs, URIs, parameters, SSL/TLS certificates, beaconing delay with random jitter, and payload/content. C2 framework tools also allow for a large number of post-exploitation actions, which are encrypted, downloaded, and run in-memory, making post-compromise activity very difficult to detect on endpoints.

We will focus on the specific C2 communications capabilities of the C2 framework tools (e.g., C2 beaconing), and how easily the communications are changed (e.g., via Cobalt Strike’s C2 Malleable Profiles), and the challenges posed to organizations trying to detect stealthy malware.

There are multiple good resources discussing the functionality of Cobalt Strike’s Malleable Profiles (Gill), but we’ll point out some of the commonly used features. Here is a snippet of the malleable profile for mimicking the Gmail browser application in Cobalt Strike (Mudge):

Figure 2: C2 Malleable Profile (gmail)

Figure 2: C2 Malleable Profile (gmail)

 

Some of the key functionality and areas of the profile are:

Section | Settings

Description | Capabilities

https-certificate# Use an existing certificate or generate a self-signed certificate as seen in this
# example.
global options# These global options below set the C2 beacon sleep time to 60 seconds with a
# random jitter of +/- 15%, showing the ability to vary the call-home timing to avoid
# easy detection.
set sleeptime "60000";
set jitter "15";


# Other global options specify on-host post-exploit action parameters such as the
# process name spawned to execute commands using in-memory injection or the
# pipename used for IPC communications. These are not relevant to C2.
set pipename "interprocess_##";
set spawnto "userinit.exe";
http-get# The uri path used for beacon->server communications can be varied with a list
set uri "/_/scs/mail-static/_/js/";

# Client (beacon->server) communications including cookies, headers, and encoding
# can all be specified and varied easily at the HTTP protocol level
client {
metadata {}
header {}
}


# Similarly, server->beacon communications can also be varied at the HTTP
# protocol level
server {
header {}
}


# Cobalt Strike allows shaping of the 2-way communications flow between the
# Beacon client and C2 Team Server (“A Beacon HTTP Transaction Walk-through”):
# 0. http-stager {} optional stager to download full Beacon
# 1. http-get {client} client -- call home → server
# 2. http-get {server} server -- cmds → client
# 3. http-post {client} client -- cmd output → server
# 4. http-get {server} server -- confirm → client

Table 2: C2 Malleable Profile Description (gmail)

 

As can be seen above, simple modifications of these profiles can easily change C2 communications behavior to mimic common applications, their beacons, and web traffic. There are more than 240 public malleable profiles for Cobalt Strike alone, readily available for use or that can be easily modified.

 

Current Detection Approaches link link

Current approaches for detecting malicious C2 traffic tend to match hard-coded byte signatures or use regular expressions to match payload or headers (IPS signatures), or are based on matching of IP/domain/URL lists. These approaches are static and easily evaded by the dynamic, configurable nature of the C2 framework toolkits being embedded by attackers.

IPS Signatures

To illustrate the challenges with IPS solutions, here is one of the Snort rules to detect the Zeus Trojan (Snort):

Figure 3: Snort Rule (Zeus Trojan)

Figure 3: Snort Rule (Zeus Trojan)

 

Snort and many IPS solutions allow various matches of content or headers at layers 3 and 4, as well as at the application level as indicated by the action verbs in the rule. Many matches such as the content rule option are static byte/character matches, while the pcre rule option is a regular expression match.

When looking side-by-side at both the adversary side (e.g., the C2 Malleable Profile for gmail seen previously) and the the defensive side (e.g., the Zeus snort rule), the static hard-coded matching and fragility is clear. Imagine that an attacker had created and deployed a new Zeus variant that used Cobalt Strike and a Snort IPS had the above Zeus rule in place that effectively detected the new malware. The attacker could easily change one character in the profile, such as adding a space in MSIE to avoid matching: content:"|3B 20|MSIE|20|"; and the malware could evade the IPS signature.

While there is contextual awareness and state tracking, the IPS signature approach is inherently limited due to its static matching, which results in false negatives and easy evasion (literally changing one character in one field could bypass an IPS rule).

This is not to say that IPS solutions aren’t useful. Rather, IPS signatures should be retained, as they serve a useful perimeter defense, blocking many known network exploits in a quick and efficient manner. In this case, even if an IPS only achieved 60% detection rates, that 60% can be blocked/alerted on easily, avoiding costly downstream processing.

IP/URL Block Lists

Other traditional approaches, such as the use of block lists (IP or URLs), are often applied in an effort to prevent the initial access or download of malware during web browsing, as well as to block potential C2 traffic.

A common challenge with block lists is that they are often out-of-date, causing false positives and are reactive in that they are updated post-compromise of target #1 or patient zero.

This is exacerbated by IP/domain indirection techniques used to hide the domain or IP address of the C2 server. Cobalt Strike has redirectors, which could be as straight-forward as IP proxies, to obfuscate the true domain or IP of the C2 server. There are also other techniques such as domain fronting using CDNs, or domain masquerading, that take advantage of TLS (SNI) vs HTTPS (host) mismatches to hide the final malicious domain from some URL security filters.

Network Traffic Heuristics

A different approach involves the use of heuristics, typically applied to network traffic patterns based on volume or time. The classic example is to detect regular outbound communication (e.g., every 60 minutes), perhaps to an IP address with no registered DNS A record.

To evade detection, C2 framework toolkits allow easy configuration of a random factor in the beaconing delay by use of the jitter setting in a Cobalt Strike Malleable Profile:

Figure 4: C2 Malleable Profile Settings (beaconing timing)

Figure 4: C2 Malleable Profile Settings (beaconing timing)

 

These settings specify a call-home interval of 60 seconds +/- 15%, which means the actual interval will range from 51 to 69 seconds, evading simple checks for recurring beaconing at constant intervals.

Efficacy

The problem with current approaches is that they do not effectively detect malleable C2 communications and are easily evaded even if specifically tuned. They do serve a purpose in efficiently detecting attack techniques that are static with well-known indicators, but miss more dynamic or sophisticated attacks or create a large number of false positives.

As one data point, when testing the most common Cobalt Strike C2 Malleable Profiles from public repos, out of the box IPS solutions such as Snort and Suricata detected substantially less than 20% of the C2 communications from the most common C2 framework toolkits.

Even after specifically adding rules to match as many of the public profiles as possible, optimizing for this specific test, coverage could only increase reasonably to ~60% without introducing significant false positives that would be very problematic in a production environment.

There are numerous problems with efficacy: not only higher false positives, but also the resulting configuration is rigidly constructed for the specific test in question, and is easily evaded by slight tweaking of the profiles. And at the end of the day, there are still ~40% of the profiles which remain undetected, which is a very high false negative rate. Not to mention the additional false negatives from a determined attacker who customizes the C2 profiles to mimic existing well known applications in a slightly different way.

New Detection Approach link link

A more effective approach is required, based not purely on static indicators, but based on focused machine-learning models that can detect anomalies in network traffic using a multitude of network signals that indicate suspicious command-and-control activity compared to what valid applications normally do for the specific users within the specific organization. Additionally, fine-grained risk metrics should be tracked at the user level to provide the most accurate and effective mitigation actions. Innovations in these three areas are required to make large improvements in detecting stealthy C2 beaconing from the C2 framework tools:

Figure 5: New Approach C2 Beacon Detection

Figure 5: New Approach C2 Beacon Detection

 

Comprehensive Signals

A comprehensive set of signals is required and should include source, destination, and traffic characteristics such as SSL/TLS certificates used on both source (malware inside environment) and destination (C2 server), domain/IP/URL, source characteristics such as the user agent/process characteristics, traffic size/burstiness/patterns, HTTP headers/payload/URI, to name just a few.

When looking at various signals across time, volume, network layers, and overall traffic profiling, behavioral detection can provide a general and effective mechanism for detecting the latest malware via suspicious and malicious C2 beaconing activity.

Figure 6: Comprehensive Signals

Figure 6: Comprehensive Signals

 

There are several dimensions to the signal types:

  • Network flow: source and destination attributes, as well as traffic patterns
  • Network layers: different signals from layer 3 to 7 (anomalies across TCP/IP headers, SSL/TLS fingerprints, HTTP headers/payloads, and application-level content)
  • Time: frequency, anomalous timing patterns to detect infrequent and slow activity
  • Data: content and volume (anomalous packet sizes, bursts, cumulative stats)

Additionally, there are several signal types:

  • Traffic pattern-based (volume, timing, content) including repeated beaconing in conjunction with unusual user agent or domain.
  • Heuristics (e.g., suspect registrars or known malicious SSL fingerprints)
  • Anomalies (unusual domain, user agents, or SSL fingerprints)

One important point is that some of the above signals are part of current approaches and existing solutions. This reinforces the point that a particular signal such as traffic spike (large volume) is neither good or bad, effective or ineffective by itself. Rather, the context and processing of the signal is the determining factor. When used at a network perimeter to block/allow traffic, a signal that is prone to false positives can cause severe operational problems. However, when fed into an anomaly detection system that incorporates that signal into a granular risk metric (discussed below) and a well-trained model, it can be extremely effective at detecting new threats in a robust manner with low false positives.

Anomaly Detection