One of the most evasive and hardest threats to detect are in memory frameworks using malleable command and control (C2) beacons to hide in benign traffic. They enable attackers to get in and remain invisible with hidden reconnaissance, discovery, C2, and data exploitation. For more than a decade, traditional security defenses using static signatures, IP address ranges, and URLs/domains have mostly failed to detect these evasive threats, plus being in memory on endpoints, these attacks can evade anti-virus and endpoint detection designed mainly to analyze file and disk activity for malware files. Originally created as penetration testing tools for red teams against blue teams, these frameworks fell into the hands of cybercrime and nation states as a leading kill chain tool after entering a network or exploiting a vulnerability for access.
So, let’s start the journey with beacons, as there are many good uses for C2 beacons from endpoints to servers to control and update software programs and applications. Taking a hammer approach and blocking all C2 beacons is not the answer. Even the Netskope Client uses beacons for its global load balancing service to find the fastest path across the NewEdge private network for each remote user. Benign beacons are useful and there are many of them in web, cloud, and application traffic. As a matter of fact, one the most popular adversary simulation frameworks, Cobalt Strike, includes more than 240 profiles for benign beacons to use to hide your malicious C2 ones. As a penetration testing tool, it’s almost certain red teams will get into blue team networks using Cobalt Strike as detection is very difficult, time consuming, and when using legacy defenses loaded with false positives.
Back in 2012, Raphael Mudge created Cobalt Strike for red team C2 pen-testing and almost invisible remote access. The framework aids in simulating attacks, identifying security flaws, and practicing defenses against potential threats like attacks, implant installation, and backdoors. Plus, it can create beacon loaders and payloads to detect network vulnerabilities and establish communication with attackers/testers online. One key design factor is malleability allowing threat actors to modify the behavior of components to mimic legitimate network traffic and evade detection by security defenses. How good is it? Well, the malicious shellcode remains invisible to antivirus and EDR detection and moves via named pipes in Windows and Linux systems. Thus, sandboxing requires emulation of named pipes, which is rare. So, criminal use of this highly effective framework was just a matter of time as an entry point used on infected networks to provide lateral mobility after a network intrusion, common in ransomware and advanced malware attacks.
There are other simulation frameworks including Brute Ratel, Mythic, Metasploit, Sliver, and Merlin. These toolkits are highly configurable (via malleable profiles) and can easily vary the timing, frequency, volume, application protocols, destination IPs/domains, setting user agents, HTTP headers, HTTP verbs, URIs, parameters, payload, SSL/TLS certificates, beaconing delay with random jitter, and content. C2 framework tools also allow for many post-exploitation actions, which are encrypted, downloaded, and run in-memory, making post-compromise activity very difficult to detect on endpoints.
Using firewall policy controls, you can block unused ports and protocols, plus stateful inspection and dynamic port allocations, however, malleable C2 beacons will likely hide in HTTP/HTTPS traffic in a sea of benign beacons. Intrusion prevention systems (IPS) are a more popular option, they allow you to develop malware C2 beacon signatures, and open source IPS solutions often provide known malware C2 beacon signatures. The problem is high false positives from static signatures and being late to the game to detect a malleable and always changing target. Anti-virus and EDR solutions struggle with in-memory framework attacks, and a secure web gateway (SWG) requires high performance for a good user experience in milliseconds, so detection falls to the background using web transaction events and post-event analysis. Using a SIEM or data lake and even traffic packet captures (PCAPs) with a network detection and response (NDR) solution takes time and skilled threat analysts for these highly evasive threats.
So, there must be a better way and in the age of AI and machine learning, a new approach has been created at Netskope. As noted above, having the traffic, transaction events, and rich context as data sources to feed ML models is a baseline requirement to address this problem. However, security service edge (SSE) solutions built on public cloud infrastructure are not open to all this valuable data including traffic packet captures. Netskope NewEdge as a private network does enable access to this data including traffic packet captures and you can read more about Netskope Cloud TAP and NDR integration in this blog.
Today, Netskope has more than 65 ML models in production with 130+ detectors for its advanced UEBA behavior anomaly detection across web, SaaS, IaaS, and user egress traffic, and adding three more patents to detect C2 beacons leveraging the experience and expertise of Netskope AI Labs and our Threat Labs teams. What these teams created was a more effective approach based not on static indicators, but instead 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 (C2) activity compared to what valid applications normally do for the specific users within the specific organization. Additionally, fine-grained risk metrics are tracked at the user level to provide the most accurate and effective mitigation actions. You can read more details in this white paper.
The outcome is Netskope C2 Beacon Detection using Advanced UEBA ML models and rich contextual network data to provide a substantially better detection rate with lower false positives than using an expertly tuned IPS for these highly evasive threats. Please review the white paper for testing results, as your mileage may vary. And yes, you should layer your defenses and block known threats with AV/EDR on endpoints, plus partnering with Netskope SSE for inline advanced threat protection including cloud firewall (FWaaS) policy controls, intrusion prevention system (IPS) detection, and remote browser isolation (RBI) to protect users and devices from malicious content and scripts.
If you are interested in this new defense after reading the white paper, please contact your Netskope sales representative to consider participating in our testing program as we finalize the solution and move it to production for our customers. Also, a thank you to our customers for challenging us on this topic and our research teams for thinking out of the box in an age of AI/ML innovations.
Learn more about the other exciting features from Netskope’s recent platform announcement, including: