Cobalt Strike Beacon HTTP C2 Heuristic Detection

Abstract

To provide a system and method for Cobalt strike beacon HTTP C2 heuristic detection.SOLUTION: A method includes the steps of: monitoring HTTP network traffic at a firewall; prefiltering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic to forward to a cloud security service; determining whether the subset of the HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity based on a plurality of heuristics; and performing an action in response to detecting the Cobalt Strike Beacon HTTP C2 traffic activity.SELECTED DRAWING: Figure 7

Description

Background Art

[0001] Malware is a common term commonly used to refer to malicious software (e.g., including various hostile, intrusive, and / or otherwise unwanted software). Malware can be in the form of code, script, active content, and / or other software. Exemplary uses of malware include interrupting the operation of a computer and / or network, stealing confidential information (e.g., confidential information such as identity, financial, and / or intellectual property-related information), and / or obtaining access to a private / dedicated computer system and / or computer network. Unfortunately, as technologies for assisting in the detection and mitigation of malware are developed, nefarious authors are finding ways to avoid such efforts. Accordingly, there is a continuing need for improvements to techniques for identifying and mitigating malware.

Brief Description of the Drawings

[0002] Various embodiments of the present invention are disclosed in the following detailed description and the accompanying drawings. [Figure 1] FIG. 1 shows one example of an environment in which a malicious application is detected and prevented from causing harm. [Figure 2A] FIG. 2A shows one example of a data appliance. [Figure 2B] FIG. 2B is a functional diagram of the logical components of one embodiment of a data appliance. [Figure 3] FIG. 3 shows one example of the logical components that may be included in a system for analyzing a sample. [Figure 4A]Figure 4A shows a portion of one exemplary embodiment relating to a detection system and quality check system for processing network traffic in order to perform Cobalt Strike Beacon C2 HTTP traffic detection, according to several embodiments. [Figure 4B] Figure 4B shows a portion of one exemplary embodiment relating to a detection system and quality check system for processing network traffic to perform Cobalt Strike Beacon C2 HTTPS traffic detection, according to several embodiments. [Figure 5A] Figure 5A shows exemplary attributes associated with cobalt strike beacon HTTP traffic used for heuristic detection, according to several embodiments. [Figure 5A-1] Figure 5A shows exemplary attributes associated with cobalt strike beacon HTTP traffic used for heuristic detection, according to several embodiments. [Figure 5B] Figure 5B shows additional exemplary attributes associated with cobalt strike beacon HTTP traffic used for heuristic detection, according to several embodiments. [Figure 5C] Figure 5C shows additional exemplary attributes associated with cobalt strike beacon HTTP traffic used for heuristic detection, according to several embodiments. [Figure 5D] Figure 5D shows additional exemplary attributes associated with cobalt strike beacon HTTP traffic used for heuristic detection, according to several embodiments. [Figure 5E] Figure 5E shows additional exemplary attributes associated with cobalt strike beacon HTTPS traffic used for heuristic detection, according to several embodiments. [Figure 5F]Figure 5F shows additional exemplary attributes associated with cobalt strike beacon HTTPS traffic used for heuristic detection, according to several embodiments. [Figure 5F-1] Figure 5F shows additional exemplary attributes associated with cobalt strike beacon HTTPS traffic used for heuristic detection, according to several embodiments. [Figure 5G] Figure 5G shows additional exemplary attributes associated with cobalt strike beacon HTTPS traffic used for heuristic detection, according to several embodiments. [Figure 6] Figure 6 is a flowchart of a process for detecting cobalt strike beacons using HTTP C2 heuristics, according to several embodiments. [Figure 7] Figure 7 is a flowchart of a process for cobalt strike beacon HTTPS C2 heuristic detection according to several embodiments. [Figure 8] Figure 8 shows checksum algorithms for probing the logic for detecting HTTP / HTTPS Cobalt Strike TeamServers according to several embodiments. [Figure 9A] Figure 9A shows an exemplary DNS request for performing active probing on a target, according to several embodiments. [Figure 9B] Figure 9B shows an exemplary DNS response to active probing of a target, according to several embodiments. [Figure 10] Figure 10 is a flowchart of the HTTP / HTTPS probing process for detecting a Cobalt Strike team server, according to several embodiments. [Figure 11] Figure 11 is a flowchart of the DNS probing process for discovering a Cobalt Strike team server, according to several embodiments. [Modes for carrying out the invention]

[0003] The present invention can be implemented in numerous ways, including processes, apparatus, systems, compositions, computer program products embodied on computer-readable storage media, and / or instructions stored in memory, and / or processors configured to execute instructions stored and / or provided by memory coupled to the processor. In this specification, these implementations, or any other forms the present invention may take, may be referred to as techniques. Generally, the order of the steps of the disclosed process may be modified within the scope of the invention. Unless otherwise specified, components such as processors or memory described as configured to perform a task may be implemented as general-purpose components temporarily configured to perform a task at a given time, or as specific components manufactured to perform a task. As used herein, the term “processor” refers to one or more devices, circuits, and / or processing cores configured to process data, such as computer program instructions.

[0004] A detailed description of one or more embodiments of the present invention, along with accompanying drawings illustrating the principles of the invention, is provided below. While the invention is described in relation to such embodiments, it is not limited to any embodiment. The scope of the invention is limited solely by the claims, and the invention encompasses numerous alternatives, modifications, and equivalents. To provide a complete understanding of the invention, numerous specific details are provided below. These details are provided for illustrative purposes only, and the invention may be carried out in accordance with the claims without some or all of these specific details. For clarity, technical materials known in the art related to the invention are not described in detail so as not to unnecessarily obscure the invention.

[0005] A firewall generally allows authorized communications to pass through while protecting the network from unauthorized access. Typically, a firewall is a device, a set of devices, or software running on a device that provides firewall functionality for network access. For example, a firewall can be integrated into the operating system of a device (e.g., a computer, smartphone, or other type of network-enabled device). Firewalls can also be integrated or run as software applications on various types of devices or security devices, such as computer servers, gateways, network / routing devices (e.g., network routers), or data appliances (e.g., security equipment or other types of special-purpose devices), and in some implementations, specific operations can be implemented on special-purpose hardware such as ASICs or FPGAs. ru.

[0006] A firewall typically denies or allows network transmissions based on a set of rules. These sets of rules are often referred to as policies (e.g., network policies or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted external traffic from reaching the protected device. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allow, block, monitor, notify, log, and / or other actions that may be specified in a firewall rule or firewall policy, which can be triggered based on various criteria, as described herein). A firewall can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.

[0007] Security devices (e.g., security equipment, security gateways, security services, and / or other security devices) can perform a variety of security operations (e.g., firewalls, anti-malware, intrusion prevention / detection, proxies, and / or other security functions), network functions (e.g., routing, quality of service (QoS), workload balancing of network-related resources, and / or other network functions), and / or other security and / or network-related functions. For example, routing can be performed based on source information (e.g., IP address and port), destination information (e.g., IP address and port), and protocol information.

[0008] A basic packet filtering firewall filters network communication traffic by inspecting individual packets transmitted over the network (e.g., a stateless packet filtering firewall, a packet filtering firewall, or a first-generation firewall). A stateless packet filtering firewall typically inspects the individual packets themselves and then applies rules based on the inspected packets (e.g., using a combination of source and destination address information, protocol information, and port number).

[0009] An application firewall can also perform application layer filtering (for example, using an application layer filtering firewall or a second-generation firewall that operates at the application level of the TCP / IP stack). An application layer filtering firewall or application firewall can generally identify a given application and protocol (e.g., web browsing using Hypertext Transfer Protocol (HTTP), Domain Name System (DNS) requests, file transfers using File Transfer Protocol (FTP), and various other types of applications and protocols such as Telnet, DHCP, TCP, UDP, and TFTP (GSS)). For example, an application firewall can block unauthorized protocols attempting to communicate on standard ports (for example, unauthorized / unauthorized policy protocols attempting to sneak through by using non-standard ports for that protocol can generally be identified using an application firewall).

[0010] A stateful firewall can also perform stateful-based packet inspection, where each packet is examined within the context of the packet flow of its network transmission and the set of packets associated with it. This firewall technique is commonly referred to as stateful packet inspection because it maintains a record of all connections passing through the firewall and can determine whether a packet is the start of a new connection, part of an existing connection, or an invalid packet. For example, the state of a connection can itself be one of the criteria that trigger rules in a policy.

[0011] Advanced or next-generation firewalls, as described above, can perform stateless and stateful packet filtering and application layer filtering. Next-generation firewalls can also perform additional firewall technologies. For example, a given new firewall, often referred to as an advanced or next-generation firewall, can also identify users and content. In particular, a given next-generation firewall extends the list of applications that these firewalls can automatically identify to thousands of applications. Examples of such next-generation firewalls are commercially available from Palo Alto Networks (e.g., Palo Alto Networks' PA series firewalls). For example, Palo Alto Networks' next-generation firewalls use a variety of identification technologies to enable enterprises and service providers to identify and control applications, users, and content—not just ports, IP addresses, and packets. Various identification technologies include application IDs (App-IDs) for accurate application identification, user IDs (User-IDs) for user identification (e.g., User ID), content IDs (Content-IDs) for real-time content scanning (e.g., to control web surfing and restrict data and file transfers), and device IDs (Device-IDs) (e.g., for identifying IoT device types). These identification technologies allow businesses to securely enable application use using business-relevant concepts, instead of following the traditional approach provided by conventional port-blocking firewalls.In addition, dedicated hardware for next-generation firewalls (e.g., implemented as a dedicated device) generally provides a higher performance level for application inspection than software executed on general-purpose hardware (e.g., security devices provided by Palo Alto Networks, which utilize dedicated, function-specific processing tightly integrated with a single-pass software engine to minimize latency and maximize network throughput for Palo Alto Networks' PA series next-generation firewalls).

[0012] Advanced or next-generation firewalls can also be implemented using virtualized firewalls. Examples of such next-generation firewalls are commercially available from Palo Alto Networks (e.g., Palo Alto Networks' VM series firewalls, which support various commercial virtualization environments including VMware(R) ESXi TM and NSX TM , Citrix(R) Netscaler SDX TM , KVM / OpenStack (Centos / RHEL, Ubuntu(R)), and Amazon Web Services (AWS), and also include the CN series container next-generation firewall). For example, virtualized firewalls can support the same or exactly the same next-generation firewall and advanced threat prevention capabilities available on physical form factor devices, enabling enterprises to safely allow the flow of applications into private, public, and hybrid cloud computing environments. Through automation features such as VM monitoring, dynamic address groups, and REST-based APIs, enterprises can dynamically monitor changes to VMs and reflect their context in security policies, thereby eliminating policy lag that can occur when VMs change.

[0013] Overview of Techniques for Cobalt Strike Beacon HTTP / HTTPS C2 Heuristic Detection

[0014] Generally, existing anti-malware security solutions often cannot detect new malware or new malware variants (e.g., pre-defined patterns such as Intrusion Prevention System (IPS) signatures). Specifically, existing anti-malware security solutions generally cannot detect new malware or new malware variants when the malware signatures of the new malware or new malware variants do not yet exist (e.g., currently, signature-based content IPS solutions generally cannot effectively detect Cobalt Strike beacon C2 traffic because only default profiles or known profiles can typically be detected using existing signature-based content IPS solutions). These drawbacks associated with existing malware solutions expose enterprises to significant security risks due to their inability to detect such new malware or new malware variants.

[0015] Cobalt Strike is an example of a type of malware that uses evasion techniques to bypass malware solutions by relying on pattern matching based on existing malware signatures (for example, penetration testing service providers (pen testers) often use Cobalt Strike (CS) tools to test commercially available security solutions, such as firewall security solutions). Cobalt Strike is a commercially available / publicly available toolkit often used by researchers and penetration testers. However, it can also be used by attackers / hackers to infiltrate corporate networks for unauthorized / malicious purposes (e.g., extracting sensitive / private data related to corporate networks, etc.).

[0016] Specifically, malware authors can use self-defined command and control (C2 or C&C) profile configurations for CobaltStrike to circumvent malware solutions that rely on pattern matching based on existing malware signatures. The CobaltStrike toolkit generates C2 traffic that can be based on a variety of protocols, including Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), and Domain Name System (DNS) protocols.

[0017] Therefore, what is needed is an anti-malware security solution that can efficiently and effectively detect Cobalt Strike Beacon C2 HTTP / HTTPS traffic.

[0018] Therefore, a new and improved technique for detecting cobalt strike beacons via HTTP / HTTPS C2 heuristics is disclosed.

[0019] A novel malware detection solution is disclosed, including a new behavior-based detection solution (e.g., using heuristic-based techniques) for efficiently and effectively detecting Cobalt Strike Beacon command and control (C2 or C&C) traffic (e.g., a type of malicious network communication between a C2 server and malware on an infected host) using the Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) protocols. The novel malware detection solution can determine a sample as malware by using heuristics to facilitate the detection of Cobalt Strike Beacon C2 HTTP / HTTPS traffic based on monitored network traffic activity, in the absence of existing IPS signatures that would effectively detect Cobalt Strike Beacon C2 HTTP / HTTPS traffic.

[0020] Specifically, a novel behavior-based detection solution for detecting Cobalt Strike Beacon C2 HTTP / HTTPS traffic is disclosed, including a detection system (e.g., including an intrusion prevention system (IPS)) and a quality check system. The detection system can facilitate the detection of Cobalt Strike Beacon C2 HTTP / HTTPS traffic using heuristic-based techniques, as further described below with respect to various embodiments.

[0021] In some embodiments, a system / process / computer program product for cobalt strike beacon HTTP / HTTPS C2 heuristic detection includes: monitoring HTTP / HTTPS network traffic in a firewall; pre-filtering the monitored HTTP / HTTPS network traffic in the firewall to select a subset of HTTPS network traffic for forwarding to a cloud security service; determining, based on multiple heuristics, whether a subset of HTTP / HTTPS network traffic is associated with cobalt strike beacon HTTP / HTTPS C2 traffic activity; and taking action in response to the detection of cobalt strike beacon HTTP / HTTPS C2 traffic activity.

[0022] In some embodiments, the system / process / computer program product for cobalt strike beacon HTTP / HTTPS C2 heuristic detection further includes using a fast match table of the detection system to store previously detected cobalt strike beacon HTTP / HTTPS C2 traffic activity, where the fast match table of the detection system stores a 3-tuple of previously detected cobalt strike beacon HTTP / HTTPS C2 traffic activity, and the 3-tuple includes a source IP address, a destination IP address, and a destination port.

[0023] In some embodiments, the system / process / computer program product for cobalt strike beacon HTTP / HTTPS C2 heuristic detection further includes storing data statistics based on an automated heuristic analysis of a subset of HTTP / HTTPS network traffic, where the data statistics are stored in the detection system's data statistics table.

[0024] In some embodiments, the system / process / computer program product for cobalt strike beacon HTTP / HTTPS C2 heuristic detection further includes performing verification of the detected cobalt strike beacon HTTP / HTTPS C2 traffic activity based on probing of the destination IP address associated with the detected cobalt strike beacon HTTP / HTTPS C2 traffic activity and using a fingerprint data store.

[0025] In some embodiments, a system / process / computer program product for cobalt strike beacon HTTP / HTTPS C2 heuristic detection includes, namely, monitoring hypertext transfer protocol (HTTP) network traffic on a firewall. This involves pre-filtering the HTTP network traffic monitored by the firewall to select a subset of HTTP network traffic to be forwarded to the cloud security service, wherein pre-filtering the HTTP network traffic monitored by the firewall to select a subset of HTTP network traffic to be forwarded to the cloud security service includes performing a heuristic analysis of the HTTP network traffic to select a subset of HTTP traffic to be forwarded to the cloud security service for further analysis to detect potential cobalt strike beacon HTTP C2 traffic, wherein the heuristic analysis of the HTTP network traffic includes selecting whether the network traffic contains a header value or URI length check that matches the range of 171 to 256 bytes, and whether the network traffic contains a header value or URI length field with an encoding that matches one of these types relating to base64, base64url, netbios, netbiosu, or mask encoding. This involves forwarding a subset of HTTP network traffic to a cloud security service, which automatically determines, based on multiple heuristics, whether the subset of HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity.The process involves receiving a response from the cloud security service indicating that a subset of HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity, and taking action in response to the determination that a subset of HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity.

[0026] In some embodiments, the system / process / computer program product for cobalt strike beacon HTTP / HTTPS C2 heuristic detection further includes the cloud security service automatically determining whether a subset of HTTP network traffic is associated with cobalt strike beacon HTTP C2 traffic activity based on multiple heuristics, which include performing data statistics checks to perform behavior-based detection of cobalt strike beacon HTTP C2 traffic activity, which includes checking the timestamps of the first 12 sessions to determine whether they are Gaussian or normally distributed.

[0027] Exemplary Techniques for Cobalt Strike Beacon HTTPS C2 Heuristic Detection

[0028] In some embodiments, a system / process / computer program product for cobalt strike beacon HTTPS C2 heuristic detection includes: monitoring hypertext transport protocol secure (HTTPS) network traffic in a firewall; pre-filtering the monitored HTTPS network traffic in the firewall to select a subset of the HTTPS network traffic for forwarding to a cloud security service; determining, based on a plurality of heuristics, whether a subset of the HTTPS network traffic is associated with cobalt strike beacon HTTPS C2 traffic activity; and taking action in response to the detection of cobalt strike beacon HTTPS C2 traffic activity.

[0029] In some embodiments, the system / process / computer program product for cobalt strike beacon HTTPS C2 heuristic detection further includes a fast match table of the detection system that stores previously detected cobalt strike beacon HTTPS C2 traffic activity.

[0030] In some embodiments, the system / process / computer program product for cobalt strike beacon HTTPS C2 heuristic detection further includes a fast match table of the detection system storing 3-tuples of previously detected cobalt strike beacon HTTPS C2 traffic activity, where the 3-tuple includes a source IP address, a destination IP address, and a destination port.

[0031] In some embodiments, the system / process / computer program product for cobalt strike beacon HTTPS C2 heuristic detection further includes storing data statistics based on automated heuristic analysis of a subset of HTTPS network traffic in the detection system's data statistics table.

[0032] In some embodiments, the system / process / computer program product for cobalt strike beacon HTTPS C2 heuristic detection further includes performing verification of detected cobalt strike beacon HTTPS C2 traffic activity.

[0033] In some embodiments, the system / process / computer program product for cobalt strike beacon HTTPS C2 heuristic detection further includes performing verification of the detected cobalt strike beacon HTTPS C2 traffic activity based on probing of the destination IP address associated with the detected cobalt strike beacon HTTPS C2 traffic activity.

[0034] In some embodiments, the system / process / computer program product for cobalt strike beacon HTTPS C2 heuristic detection further includes performing verification of the detected cobalt strike beacon HTTPS C2 traffic activity based on probing of the destination IP address associated with the detected cobalt strike beacon HTTPS C2 traffic activity and using a fingerprint datastore.

[0035] Accordingly, a new and improved security solution that uses a security platform to facilitate Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection is disclosed according to several embodiments (including, for example, a firewall (FW) / next-generation firewall (NGFW), a network sensor acting in place of a firewall, or another (virtual) device / component that can implement security policies using the disclosed techniques, such as Palo Alto Networks' PA Series Next Generation Firewall, Palo Alto Networks' VM Series Virtualized Next Generation Firewall, and CN Series Container Next Generation Firewall, and / or other commercially available virtual-based or container-based firewalls may be similarly implemented and configured to perform the disclosed techniques).

[0036] These and other embodiments and examples for cobalt strike beacon HTTP / HTTPS C2 heuristic detection are further described below.

[0037] Exemplary System Architecture for Cobalt Strike Beacon HTTP / HTTPS C2 Heuristic Detection

[0038] Accordingly, in some embodiments, the disclosed techniques include providing a security platform configured to provide DPI capabilities (including, for example, stateful inspection) by applying the disclosed techniques to automatically detect Cobalt Strike Beacon C2 HTTP / HTTPS traffic, as further described below (for example, the security function / platform may be implemented using: a firewall (FW) / next-generation firewall (NGFW), a network sensor acting in place of a firewall, or another (virtual) device / component capable of implementing security policies using the disclosed techniques, such as PANOS running on a commercially available virtual / physical NGFW solution from Palo Alto Networks, for example, or another security platform / NFGW, including, for example, Palo Alto Networks' PA Series Next Generation Firewall, Palo Alto Networks' VM Series Virtualized Next Generation Firewall, and CN Series Container Next Generation Firewall, and / or other commercially available virtual-based or container-based firewalls may be similarly implemented and configured to perform the disclosed techniques).

[0039] Figure 1 illustrates an example of an environment in which malicious applications ("malware") are detected and prevented from causing harm. As will be described in more detail below, malware classification (for example, as performed by security platform 122) can be shared and / or refined in various ways among the various entities included in the environment shown in Figure 1. Using the techniques described herein, devices such as endpoint client devices 104-110 can be protected from such malware (including previously unknown / novel malware variants, such as C2 malware).

[0040] As used herein, “malware” refers to an application that engages in behavior that the user would not authorize or would not authorize if fully informed, whether or not it is confidential (and illegal). Examples of malware include ransomware, Trojans, viruses, rootkits, spyware, hacking tools, etc. One example of malware is a desktop / mobile application that encrypts the user’s stored data (e.g., ransomware). Another example of malware is C2 malware, similarly described above. Other forms of malware (e.g., keyloggers) can also be detected / blocked using the disclosed techniques for sample traffic-based self-learning malware detection, as further described herein.

[0041] The techniques described herein can be used in conjunction with various platforms (e.g., servers, computing equipment, virtual / container environments, desktops, mobile devices, game platforms, embedded systems, etc.) and / or for the automated detection of various forms of malware (e.g., new and / or variant malware, such as C2 malware). In the exemplary environment shown in Figure 1, client devices 104-108 are a laptop computer, a desktop computer, and a tablet, respectively, located within the corporate network 140. Client device 110 is a laptop computer located outside the corporate network 140.

[0042] The data appliance 102 is configured to enforce policies regarding communication between client devices, such as client devices 104 and 106, and nodes outside the corporate network 140 (e.g., those reachable via the external network 118). Examples of such policies include those that manage traffic shaping, quality of service, and traffic routing. Other examples of policies include security policies that require scanning for threats in incoming (and / or outgoing) email attachments, website content, files exchanged via instant messaging programs, and / or other file transfers. In some embodiments, the data appliance 102 is also configured to enforce policies regarding traffic that remains within the corporate network 140.

[0043] One embodiment of the data appliance is shown in Figure 2A. The example shown is a representation of the physical components included in the data appliance 102 in various embodiments. Specifically, the data appliance 102 includes a high-performance multi-core central processing unit (CPU) 202 and random access memory (RAM) 204. The data appliance 102 also includes storage 210 (such as one or more hard disks or solid-state units). In various embodiments, the data appliance 102 stores information (in either RAM 204, storage 210, and / or other appropriate locations) used to monitor the enterprise network 110 and implement the disclosed technology. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policy and other configuration information, signatures, hostname / URL classification information, malware profiles, and machine learning (ML) models (e.g., including C2 ML models for sample traffic-based self-learning malware detection, as further described herein). The data appliance 102 may also include one or more optional hardware accelerators. For example, the data appliance 102 may include a cryptographic engine 206 configured to perform encryption and decryption operations, and one or more field-programmable gate arrays (FPGAs) 208 configured to perform matching, act as a network processor, and / or perform other tasks.

[0044] The functionality described herein as being performed by the data appliance 102 can be provided / implemented in a variety of ways. For example, the data appliance 102 may be a dedicated device or a set of devices. The functionality provided by the data appliance 102 may also be integrated or run as software on a general-purpose computer, computer server, gateway, and / or network / routing device. In some embodiments, at least some of the services described as being provided by the data appliance 102 are instead (or in addition to) provided to a client device (e.g., client device 104 or client device 110) by software running on the client device.

[0045] Whenever the data appliance 102 is described as performing a task, a single component, a subset of components, or all components of the data appliance 102 may work together to perform the task. Similarly, whenever a component of the data appliance 102 is described as performing a task, a subcomponent may perform the task, and / or a component may perform the task together with other components. In various embodiments, parts of the data appliance 102 are provided by one or more third parties. Depending on factors such as the amount of computing resources available to the data appliance 102, various logical components and / or features of the data appliance 102 may be omitted, and the techniques described herein will be adapted accordingly. Similarly, additional logical components / features may be included in embodiments of the data appliance 102 as applicable. One example of a component included in the data appliance 102 in various embodiments is an application identification engine configured to identify applications (e.g., using various application signatures to identify applications based on packet flow analysis). For example, the application identification engine may determine the type of traffic a session is involved in, such as web browsing-social networking, web browsing-news, SSH, etc.

[0046] Figure 2B is a functional diagram of a logical component in one embodiment of a data appliance. The example shown is a representation of a logical component that may be included in the data appliance 102 in various embodiments. Unless otherwise specified, the various logical components of the data appliance 102 can generally be implemented in various ways, including a set of one or more scripts (e.g., written in Java®, Python, etc., where applicable).

[0047] As shown in the diagram, the data appliance 102 includes a firewall and contains a management plane 232 and a data plane 234. The management plane is responsible for managing user interaction by providing a user interface for setting policies and displaying log data. The data plane is responsible for data management by performing packet processing and session processing.

[0048] The network processor 236 is configured to receive packets from client devices, such as client device 108, and provide them to the data plane 234 for processing. Whenever the flow module 238 identifies a packet as part of a new session, it generates a new session flow. Subsequent packets are identified as belonging to the session based on the flow lookup. SSL decryption is applied by the SSL decryption engine 240 where applicable; otherwise, processing by the SSL decryption engine 240 is omitted. The decryption engine 240 helps the data appliance 102 inspect and control SSL / TLS and SSH encrypted traffic, and therefore helps stop threats that might otherwise remain hidden within encrypted traffic. The decryption engine 240 can also help prevent sensitive content from leaving the corporate network 140. Decryption can be selectively controlled (e.g., enabled or disabled) based on parameters such as URL category, traffic source, traffic destination, user, user group, and port. In addition to the decryption policy (for example, specifying the session to decrypt), a decryption profile may be assigned to control various options for the session controlled by the policy. For example, the use of a specific cipher suite and encryption protocol version may be required.

[0049] The Application Identification (APP-ID) engine 242 is configured to determine the type of traffic a session is involved in. For example, the application identification engine 242 can recognize a GET request in incoming data and conclude that the session requires an HTTP decoder. In some cases, the identified application, such as a web browsing session, can be modified, and such modifications are noted by the data appliance 102. For example, a user might first browse a company wiki (classified as "Web Browsing - Productivity" based on the visited URL) and then browse a social networking site (classified as "Web Browsing - Social Networking" based on the visited URL). Different types of protocols have corresponding decoders.

[0050] Based on the decision made by the application identification engine 242, the packet is sent by the threat engine 244 to the appropriate decoder, which is configured to assemble the packet (which may be received out of order) into the correct order, perform tokenization, and extract information. The threat engine 244 also performs signature matching to determine what should happen to the packet. If necessary, the SSL encryption engine 246 can re-encrypt the decrypted data. The packet is forwarded using the forwarding module 248 for forwarding (e.g., to the destination).

[0051] Furthermore, as shown in Figure 2B, policy 252 is also received and stored in the management plane 232. A policy may include one or more rules, which can be specified using a domain name and / or host / server name, and the rules may apply one or more signatures or other matching criteria or heuristic methods, such as for security policy enforcement on subscriber / IP flows, based on various extracted parameters / information from the monitored session traffic flow. An exemplary policy may include a C2 malware detection policy using disclosed techniques for sample traffic-based self-learning malware detection. An interface (I / F) communicator 250 is provided for management communications (e.g., via (REST) ​​APIs, messages, or network protocol communications, or other communication mechanisms).

[0052] Security platform

[0053] Returning to Figure 1, suppose a malicious individual (using System 120) has created malware 130, such as malware that generates Cobalt Strike Beacon C2 HTTP / HTTPS traffic using a new / modified profile to evade detection by existing IPS signatures (for example, the malware could be delivered to a user's endpoint device via a compromised website when the user visits / browses the compromised website, or via a phishing attack). The malicious individual wants a client device, such as client device 104, to run a copy of malware 130 to unpack the malware executable / payload, compromising the client device, and then to turn the client device into a bot in a botnet, etc. The compromised client device may then be commanded to perform tasks (for example, cryptocurrency mining or participating in a denial-of-service attack) and report information to an external entity, such as a command and control (C&C) server 150, and, where applicable, to receive commands from the C&C server 150.

[0054] Assume that data appliance 102 intercepts an email sent (for example, by system 120) to a user "Alice" operating client device 104. In this embodiment, Alice receives the email and clicks a link to a phishing / dangerous site, which could result in an attempt by Alice's client device 104 to download malware 130. However, in this embodiment, data appliance 102 can implement the disclosed techniques for sample traffic-based self-learning malware detection and block access to the packed malware content from Alice's client device 104, thereby preempting and preventing any such download of malware 130 to Alice's client device 104. As further described below, data appliance 102 detects such malware 130 and blocks it from harming Alice's client device 104 by implementing the disclosed techniques for sample traffic-based self-learning malware detection, as further described below.

[0055] In various embodiments, the data appliance 102 is configured to work in cooperation with the security platform 122. As one example, the security platform 122 may provide the data appliance 102 with a set of signatures for known malicious files (e.g., as part of a subscription). If the signature set includes a signature for malware 130 (e.g., the MD5 hash of malware 130), the data appliance 102 may accordingly prevent the transmission of malware 130 to the client device 104 (e.g., by detecting that the MD5 hash of an email attachment sent to the client device 104 matches the MD5 hash of malware 130). The security platform 122 may also provide the data appliance 102 with a list of known malicious domains and / or IP addresses, enabling the data appliance 102 to block traffic between the corporate network 140 and the C2 server 150 (e.g., if the C2 server 150 is known to be malicious). A list of malicious domains (and / or IP addresses) can also help the data appliance 102 determine when one of its nodes was compromised. For example, if client device 104 attempts to contact C2 server 150, such an attempt is a strong indicator that client 104 is compromised by malware (and corrective action should be taken accordingly, such as quarantining client device 104 from communicating with other nodes in the corporate network 140).

[0056] As will be described in more detail below, the security platform 122 may also receive a copy of the malware 130 from the data appliance 102 to perform cloud-based security analysis to perform sample traffic-based self-learning malware detection, and the malware determination is returned to the data appliance 102 to enforce security policies, thereby protecting Alice's client device 104 from the execution of the malware 130 (for example, blocking access to the malware 130 on the client device 104).

[0057] Furthermore, the security platform 122 may also provide the data appliance 102 with other types of information (for example, as part of a subscription), such as a set of information for performing the techniques disclosed for sample traffic-based self-learning malware detection that can be used by the data appliance 102 to perform inline analysis of such malware files, as will be further described below.

[0058] In various embodiments, the data appliance 102 may take various actions if the signature of an attachment is not found. As a first example, the data appliance 102 can fail-safe by blocking the transmission of any attachment that is not whitelisted as benign (e.g., does not match the signature of a known good file). A potential drawback of this approach is that many legitimate attachments may be unnecessarily blocked as potential malware when they are actually benign. As a second example, the data appliance 102 can fail-safe by allowing the transmission of any attachment that is not blacklisted as malicious (e.g., does not match the signature of a known bad file). A potential drawback of this approach is that newly created malware (that has not been previously seen by platform 122) may cause harm. As a third example, the data appliance 102 is configured to provide a file (e.g., malware 130) to the security platform 122 for static / dynamic analysis to determine whether it is malicious and / or, if not, to classify it.

[0059] The security platform 122 stores a copy of the received sample in storage 142, and analysis is initiated (or scheduled, if applicable). One example of storage 142 is an Apache Hadoop cluster (HDFS). The results of the analysis (and additional information about the application) are stored in database 146. If the application is determined to be malicious, the data appliance may be configured to automatically block file downloads based on the analysis results. Furthermore, a signature is generated for the malware and distributed (for example, to data appliances such as data appliances 102, 136, and 148) to automatically block future file transfer requests for downloading files determined to be malicious.

[0060] In various embodiments, the security platform 122 comprises one or more dedicated commercial hardware servers running a typical server-class operating system (e.g., Linux®) (e.g., having a multi-core processor, 32G+ RAM, a Gigabit network interface adapter, and a hard drive). The security platform 122 may be implemented across a scalable infrastructure including multiple such servers, solid-state drives, and / or other applicable high-performance hardware. The security platform 122 may comprise several distributed components, including components provided by one or more third parties. For example, some or all of the security platform 122 may be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). Furthermore, as with the data appliance 102, whenever the security platform 122 is referred to as performing tasks such as storing or processing data, it should be understood that subcomponents or multiple subcomponents of the security platform 122 may cooperate (individually or in cooperation with third-party components) to perform those tasks. As one example, the security platform 122 can optionally collaborate with one or more virtual machine (VM) servers, such as VM server 124, to perform static / dynamic analysis.

[0061] One example of a virtual machine server is a physical machine containing commercial server-class hardware (e.g., a multi-core processor, 32+ gigabytes of RAM, and one or more gigabit network interface adapters) running commercially available virtualization software such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the virtual machine server is omitted. Furthermore, the virtual machine server may be under the control of the same entity managing the security platform 122, or it may be provided by a third party. As one example, the virtual machine server may rely on EC2, and the rest of the security platform 122 is owned by and provided by dedicated hardware under the control of the operator of the security platform 122. VM server 124 is configured to provide one or more virtual machines 126-128 for emulating client devices. The virtual machines can run various operating systems and / or versions thereof. Observed behavior resulting from running applications within the virtual machines is logged and analyzed (e.g., for indications that the application is malicious). In some embodiments, log analysis is performed by a VM server (e.g., VM server 124). In other embodiments, the analysis is performed at least partially by other components of the security platform 122, such as a coordinator 144.

[0062] In various embodiments, the security platform 122 makes the results of sample analysis available to the data appliance 102 as part of a subscription, via a list of signatures (and / or other identifiers). For example, the security platform 122 may periodically send content packages that identify malware files, including network traffic-based heuristic IPS malware detection, etc. (e.g., daily, hourly, or at some other interval, and / or based on events configured by one or more policies). One exemplary content package includes a cobalt strike beacon (CSB) detector 154 and / or other information (e.g., an ML-based detection model), as further described below. The subscription may cover analysis only of files intercepted by the data appliance 102 and sent to the security platform 122 by the data appliance 102, and may also cover malware signatures known to the security platform 122. As described in more detail below, the platform 122 may also utilize other types of information / ML models to perform network traffic-based heuristic IPS malware detection. Specifically, platform 122 can utilize a CSB detector 154 (which can be implemented as a plug-in or subcomponent of platform 122, for example, as further described below with respect to Figures 4A and 4B, in the C2M L model), which can help data appliance 102 detect potentially new / modified C2 malware (e.g., Cobalt Strike Beacon C2 HTTP / HTTPS traffic) and perform inline blocking.

[0063] In various embodiments, the security platform 122 is configured to provide security services to various entities in addition to (or, where applicable, instead of) the operators of the data appliance 102. For example, other companies, each with its own corporate networks 114 and 116, and each with its own data appliances 136 and 148, can contract with the operator of the security platform 122. Other types of entities can also utilize the services of the security platform 122. For example, an Internet service provider (ISP) providing internet services to a client device 110 can contract with the security platform 122 to analyze applications that the client device 110 attempts to download. As another example, the owner of the client device 110 can install software on the client device 110 to communicate with the security platform 122 (for example, to receive a content package from the security platform 122, use the received content package to check attachments according to the techniques described herein, and send the application to the security platform 122 for analysis).

[0064] Sample analysis using static / dynamic analysis

[0065] Figure 3 shows an example of a logical component that may be included in a system for analyzing a sample. The analysis system 300 may be implemented using a single device. For example, the functionality of the analysis system 300 may be implemented in a malware analysis module 112 incorporated into the data appliance 102. The analysis system 300 may also be implemented collectively across multiple separate devices. For example, the functionality of the analysis system 300 may be provided by a security platform 122.

[0066] In various embodiments, the analysis system 300 utilizes a list, database, or other collection of known secure content and / or known bad content (collectively shown as collection 314 in Figure 3). Collection 314 can be obtained in various ways, including through a subscription service (e.g., provided by a third party) and / or as a result of other processing (e.g., performed by the data appliance 102 and / or security platform 122). Examples of information contained in collection 314 are as follows: That is, URLs, domain names, and / or IP addresses of known malicious servers; URLs, domain names, and / or IP addresses of known secure servers; URLs, domain names, and / or IP addresses of known command and control (C2 / C&C) domains; signatures, hashes, and / or other identifiers of known malicious applications; signatures, hashes, and / or other identifiers of known secure applications; signatures, hashes, and / or other identifiers of known malicious files (e.g., OS exploit files); signatures, hashes, and / or other identifiers of known secure libraries; and signatures, hashes, and / or other identifiers of known malicious libraries.

[0067] In various embodiments, when a new sample is received for analysis (for example, when no existing signature associated with the sample exists in the analysis system 300), it is added to queue 302. As shown in Figure 3, application 130 is received by system 300 and added to queue 302.

[0068] The coordinator 304 monitors the queue 302, and when a resource (e.g., a static analysis worker) becomes available, the coordinator 304 fetches a sample from the queue 302 for processing (e.g., fetching a copy of malware 130). In particular, the coordinator first provides the sample to the static analysis engine 306 for static analysis (305). In some embodiments, one or more static analysis engines are included within the analysis system 300, where the analysis system 300 is a single device. In other embodiments, static analysis is performed by a separate static analysis server containing multiple workers (i.e., multiple instances of the static analysis engine 306).

[0069] The static analysis engine obtains general information about the sample and includes it (along with heuristic information and other information, where applicable) in a static analysis report 308. The report may be generated by the static analysis engine or by the coordinator 304 (or by another appropriate component), which may be configured to receive information from the static analysis engine 306. As one example, static analysis of malware may include performing signature-based analysis. In some embodiments, the collected information is stored in a database record of the sample (e.g., in database 316) instead of, or in addition to, a separate static analysis report 308 being generated (i.e., a portion of the database record forms report 308). In some embodiments, the static analysis engine also forms a determination about the application (e.g., “safe”, “suspicious”, or “malicious”). As one example, if the application has any “malicious” static feature (e.g., the application contains hard links to known malicious domains), the determination may be “malicious”. As another example, points may be assigned to each feature (for example, based on severity if found, based on how reliable the feature is in predicting malice, etc.). Then, a judgment may be assigned by the static analysis engine 306 (or, if applicable, the coordinator 304) based on the number of points associated with the static analysis results.

[0070] Once the static analysis is complete, the coordinator 304 locates an available dynamic analysis engine 310 to perform dynamic analysis on the application. Similar to the static analysis engine 306, the analysis system 300 may directly include one or more dynamic analysis engines. In other embodiments, the dynamic analysis is performed by a separate dynamic analysis server, which includes multiple workers (i.e., multiple instances of the dynamic analysis engine 310).

[0071] Each dynamic analysis worker manages virtual machine instances (e.g., emulation / sandbox analysis of samples for malware detection, such as the C2 malware detection described above based on monitored network traffic activity). In some embodiments, the results of static analysis (e.g., performed by static analysis engine 306) are provided as input to dynamic analysis engine 310, whether in report format (308) and / or stored in database 316 or otherwise. For example, static report information may be used to help select / customize the virtual machine instances used by dynamic analysis engine 310 (e.g., Microsoft Windows 7 SP2 vs. Microsoft Windows 10 Enterprise, or iOS 11.0 vs. iOS 12.0). If multiple virtual machine instances are running concurrently, a single dynamic analysis engine may manage all instances, or multiple dynamic analysis engines may be used where applicable (e.g., each managing its own virtual machine instances). Actions performed by applications (including network activity) are analyzed during the dynamic part of the analysis, as will be described in more detail below.

[0072] In various embodiments, static analysis of a sample is omitted or performed by a separate entity, where applicable. As one example, conventional static and / or dynamic analysis may be performed on a file by a first entity. Once a given file is determined to be malicious (e.g., by the first entity), the file may be provided to a second entity (e.g., an operator of the security platform 122) for additional analysis, particularly regarding the use of malware in network activity (e.g., by the dynamic analysis engine 310).

[0073] The environment used by the analysis system 300 is instrumented / hooked so that any behavior observed while the application is running is logged as it occurs (e.g., using a customized kernel that supports hooking and logcat). Network traffic associated with the emulator is also captured (e.g., using pcap). Log / network data may be stored as temporary files in the analysis system 300, and may also be stored more permanently (e.g., using HDFS or another suitable storage technology, or a combination of technologies such as MongoDB). A dynamic analysis engine (or another suitable component) can compare connections made by the sample to a list of domains, IP addresses, etc. (314) and determine whether the sample communicated with (or attempted to communicate with) a malicious entity.

[0074] Similar to the static analysis engine, the dynamic analysis engine stores the results of its analysis in database 316 in records associated with the application being tested (and / or, where applicable, includes the results in report 312). In some embodiments, the dynamic analysis engine also forms a determination about the application (e.g., “safe,” “suspicious,” or “malicious”). For example, even if only one “malicious” action is taken by the application (e.g., an attempt is made to contact a known malicious domain, or an attempt is observed to exfiltrate sensitive information), the determination may be “malicious.” For another example, points may be assigned to actions performed (e.g., based on severity if found, based on how reliable the action is in predicting malice, etc.). The determination may then be assigned by the dynamic analysis engine 310 (or, where applicable, the coordinator 304) based on the number of points associated with the dynamic analysis results. In some embodiments, the final determination related to the sample is made (e.g., by the coordinator 304) based on a combination of report 308 and report 312.

[0075] Cobalt Strike Beacon HTTP C2 Heuristic Detection

[0076] Figure 4A shows a portion of one exemplary embodiment relating to a detection system and quality check system for processing network traffic to perform cobalt strike beacon C2 HTTP traffic detection, according to several embodiments. As similarly described above, in various embodiments, the security platform 122 includes a cobalt strike beacon (CSB) detector 154. Figure 4A shows the subcomponents of the CSB detector 154, namely the detection system 402 and the quality check system 404.

[0077] Referring to Figure 4A, a behavior-based cross-session detection solution for performing Cobalt Strike Beacon C2 HTTP traffic detection is executed in conjunction with a data appliance (e.g., a data appliance implementing a firewall, also hereafter simply called a firewall) 102, using a cloud-based security service (e.g., a cloud security service 122 as shown in Figure 1). The behavior-based detection solution performs cross-session checks and includes three components, as described below.

[0078] Firewall 102 monitors network traffic in the corporate network (including, for example, HTTP traffic in corporate network 140 as shown in Figure 1). As shown in 410, firewall 102 uses the data plane to monitor network traffic and performs pre-filtering analysis of network traffic using the HTTP pre-filtering module (e.g., subcomponents). As shown in 412, if the following pre-filtering analysis of HTTP traffic is hit (i.e., both of the following exemplary criteria are met based on header length and header encoding format, which are selected to reduce the amount of traffic forwarded to cloud security 122 for further analysis to detect potential cobalt strike beacon C2 traffic), firewall 102 forwards the traffic (e.g., a packet capture (pcap) file of the network traffic associated with the session) to the detection system. Firstly, the HTTP pre-filtering module determines whether the network traffic contains a header value or URI length check that matches a range of 171 to 256 bytes. Secondly, the HTTP pre-filtering module determines whether network traffic contains header values ​​or URI length fields using an encoding that matches one of the following encoding types: base64, base64url, netbios, netbiosu, or a mask. Based on experiments (e.g., test results), pre-filtering reduces the amount of network traffic forwarded for further analysis by the cloud security service to approximately 0.32% of the total network traffic.

[0079] The Cobalt Strike Beacon (CSB) detector 154 includes a detection system 402, which includes an HTTP logical check module (a subcomponent that can be implemented using, for example, Python or another high-level programming language) that implements a decision tree based on the source IP address (SrcIP), destination IP address (DstIP), and destination port (DstPort) associated with each new session, and performs the following checks based on the data statistics associated with each new session. As an initial logic check, the detection system 402 can determine whether a prior verdict exists stored in the fast match table, and if a match exists based on a 3-tuple relating to SrcIP, DstIP, and DstPort, the prior verdict is returned to the firewall 102 without further analysis / processing by the detection system 402.

[0080] Otherwise, the process proceeds to perform the following data statistics checks, stored in the data statistics table, as shown in 414. The following data statistics checks are performed for each session and stored in the data statistics table to perform behavior-based detection of Cobalt Strike Beacon C2 HTTP traffic (e.g., using heuristic-based techniques as further described below). In an exemplary implementation, the fast match table and data statistics table may be implemented using an in-memory data structure store, such as using open source (e.g., Redis, publicly available at https: / / redis.io / ) or a commercial data store solution.

[0081] First, the timestamps of the first 12 sessions are checked to determine whether they follow a Gaussian or normal distribution. In an exemplary implementation, the calculation of a Gaussian or normal distribution can be implemented using the Bowley Skewness algorithm for normal distribution calculation (e.g., the Bowley Skewness algorithm is publicly available at https: / / www.statisticshowto.com / bowley-skewness / ), and in particular, it is checked whether it follows a normal distribution for the timestamps from the first 12 sessions. The median absolute deviation is determined using the median absolute deviation algorithm (e.g., the median absolute deviation algorithm is publicly available at https: / / en.wikipedia.org / wiki / Median_absolute_deviation). Finally, the connection count distribution is determined for the timestamp difference (TSdiff) over 12 sessions from 6 seconds to 556 seconds (e.g., 6 / 10 - 556 / 10, 1 to 55 seconds per session; in this exemplary implementation, 40 seconds is chosen for this connection count distribution calculation).

[0082] Secondly, check whether the timestamp gap between different sessions is less than 10 minutes (for example, Cobalt Strike Beacon C2 HTTP traffic typically sends heartbeat traffic every 5-10 minutes to check in / communicate with its C2 / Cobalt Strike Beacon team server using metadata).

[0083] Thirdly, check whether the MD5 hash values ​​of the HTTP headers are the same (for example, metadata including cookies associated with the session will be the same for each compromised machine, and as a result the MD5 of the HTTP headers will be the same for each session, representing new communications to that C2 team server).

[0084] Fourth, check whether the number of HTTP header fields (i.e., the number of fields included in the HTTP header) is less than 10 fields in the HTTP header (for example, due to design limitations resulting from the design implementation of the Cobalt Strike Beacon Toolkit).

[0085] Fifth, check whether the HTTP headers contain any custom headers.

[0086] Sixth, it checks whether the HTTP User Agent (UA) is a popular UA (e.g., a known / popular UA, i.e., an exemplary list of popular UAs is publicly available at https: / / www.whatismybrowser.com / guides / the-latest-user-agent / ). Cobalt Strike Beacon C2 traffic is generally associated with using known / popular UAs, and thus the HTTP network traffic attempts to simulate typical user traffic that would be associated with such known / popular UAs (e.g., commonly used web browsers such as Microsoft IE, Chrome, Mozilla, etc.).

[0087] Based on the heuristics described above, if these logical checks result in a match, it is determined that the network traffic for such a session is associated with Cobalt Strike Beacon C2 HTTP traffic. If no match is found, it is determined that the network traffic for such a session is not associated with Cobalt Strike Beacon C2 HTTP traffic. The determination is stored in a fast match table, as shown in 416. Specifically, after the determination is made as described above, the detection system adds a 3-tuple (e.g., SrcIP, DstIP, Dstport) along with the determination to the fast match table. Thus, the detection system queries the fast match table for subsequent sessions, as described above, to facilitate more efficient determination of determinations for previously analyzed HTTP traffic.

[0088] In 418, the quality check system 404 performs verification of the results of the detection system 402 to determine whether any previous determination for the Cobalt Strike Beacon C2 HTTP traffic was a false positive or a false negative. Specifically, the destination IP probing and verification module (e.g., a subcomponent) performs automated probing of the destination IP address by sending a custom HTTP request (e.g., a custom HTTP / HTTPS / DNS request) to the destination IP address. As shown in 420, the destination IP probing and verification module then determines whether the response contains a fingerprint associated with Cobalt Strike (for example, the HTTP response data contains the default proof provided by Cobalt Strike and / or the HTTP response matches the fingerprint of Cobalt Strike (CS)). In an exemplary implementation, the CS fingerprint is a default string included in the response traffic from the CS team server. For example, when a client sends an HTTP request with a randomized URL to the CS team server, the team server returns an HTTP status code 404 and the following exemplary header: Content-Type: text / plain\r\Gmt:Wed,27Feb2019 14:43:19 The response uses nDate\r\nContent-Length:0. Thus, the CS team server can be identified using "Content-Type:text / plain" and Content-Length:0 as a fingerprint, as will be further described below for various embodiments, and the Cobalt Strike Beacon C2 HTTP Traffic (CS) determination of the network traffic / session communicating with the destination IP address is verified.As one example, the quality check system can perform a malware IP address lookup to determine whether DestIP is associated with Cobalt Strike Beacon-related malware (e.g., a known malware sample previously identified as Cobalt Strike Beacon-related malware based on previous malware analysis), and if so, verify the determination of Cobalt Strike Beacon C2 HTTP traffic (CS). Otherwise, the determination is automatically changed from CS to benign (e.g., providing a feedback loop to improve the CS detection heuristics implemented in detection system 402). Thus, the quality check system can verify the determination in an attempt to detect any false positives or false negatives for Cobalt Strike Beacon C2 HTTP traffic.

[0089] The behavior-based techniques disclosed for performing Cobalt Strike Beacon C2 HTTP traffic detection, and for inter-session detection solutions, promote a 90% improvement in detection rates for Cobalt Strike Beacon C2 HTTP traffic detection, based on experimental / test results, compared to existing IPS signature-based approaches (e.g., for default / known profiles for Cobalt Strike Beacon C2 HTTP traffic).

[0090] Cobalt Strike Beacon HTTPS C2 Heuristic Detection

[0091] Figure 4B shows a portion of one exemplary embodiment relating to a detection system and quality check system for processing network traffic to perform cobalt strike beacon C2 HTTPS traffic detection, according to several embodiments. As similarly described above with respect to Figure 4A, the security platform 122 includes a cobalt strike beacon (CSB) detector 154. Figure 4B similarly shows subcomponents of the CSB detector 154, namely the following subcomponents, namely the detection system 402 and the quality check system 404. However, as will be further described below, the HTTPS pre-filtering logical module / subcomponent and the HTTPS logical check module / subcomponent perform different pre-filtering and logical checks on HTTPS traffic (for example, since HTTPS traffic headers / content are encrypted, separate heuristics for automatically detecting cobalt strike beacon C2 HTTPS traffic are disclosed herein, as will be further described below).

[0092] Referring to Figure 4B, a behavior-based inter-session detection solution for performing Cobalt Strike Beacon C2 HTTPS traffic detection is implemented in conjunction with firewall 102 using a cloud-based security service (e.g., cloud security service 122 as shown in Figure 1). The behavior-based detection solution performs inter-session checks and includes three components, as described below.

[0093] Firewall 102 monitors network traffic on the corporate network (including, for example, HTTP traffic on corporate network 140 as shown in Figure 1). As shown in 410, firewall 102 uses the data plane to monitor network traffic and performs pre-filtering analysis of network traffic using an HTTPS pre-filter module (e.g., a subcomponent). As shown in 412, firewall 102 forwards traffic (e.g., a packet capture (pcap) file of network traffic associated with a session) to the detection system if the following pre-filtering analysis of HTTP traffic hits (i.e., it satisfies both of the following exemplary criteria based on the Server hello random field value and includes "DOWNGRD" (e.g., this field value is present in Cobalt Strike Beacon C2 HTTPS traffic but is also associated with benign traffic, and thus this pre-filtering is used before further analysis, which is performed using the detection system described below to check for further heuristics), and it is selected to reduce the amount of traffic forwarded to cloud security 122 for further analysis to detect potential Cobalt Strike Beacon C2 traffic, as described further below). Specifically, the pre-filtering module determines whether the Server hello random field value includes the "DOWNGRD" value. Based on experiments (e.g., test results), pre-filtering reduces the amount of network traffic forwarded for further analysis by cloud security services, which is approximately 0.002% of total network traffic.

[0094] The Cobalt Strike Beacon (CSB) detector 154 includes a detection system 402, which implements a decision tree based on the source IP address (SrcIP), destination IP address (DstIP), and destination port (DstPort) associated with each new session, and includes an HTTPS logical check module (a subcomponent that can be implemented using, for example, Python, or another high-level programming language) that performs the following checks based on the data statistics associated with each new session. As an initial logical check, the detection system 402 can determine whether a previous determination exists stored in the fast match table, and if a match exists based on a 3-tuple relating to SrcIP, DstIP, and DstPort, the previous determination is returned to the firewall 102 without further analysis / processing by the detection system 402.

[0095] Otherwise, the process proceeds to perform the following data statistics checks, stored in the data statistics table, as shown in 414. The following data statistics checks are performed for each session and stored in the data statistics table to perform behavior-based detection of Cobalt Strike Beacon C2 HTTP traffic (e.g., using heuristic-based techniques as further described below). In an exemplary implementation, the fast match table and data statistics table may be implemented using an in-memory data structure store, such as using open source (e.g., Redis, publicly available at https: / / redis.io / ) or a commercial data store solution.

[0096] First, the timestamps of the first 12 sessions are checked to determine whether they follow a Gaussian or normal distribution. In an exemplary implementation, the calculation of a Gaussian or normal distribution can be implemented using the Bowley Skewness algorithm for normal distribution calculation (e.g., the Bowley Skewness algorithm is publicly available at https: / / www.statisticshowto.com / bowley-skewness / ), and in particular, it checks whether the timestamps from the first 12 sessions follow a normal distribution. The median absolute deviation is determined using the median absolute deviation algorithm (e.g., the median absolute deviation algorithm is publicly available at https: / / en.wikipedia.org / wiki / Median_absolute_deviation). Finally, the connection count distribution is determined for the timestamp difference (TSdiff) of 12 sessions from 6 seconds to 556 seconds (e.g., 6 / 10 - 556 / 10, 1 to 55 seconds per session; in this exemplary implementation, 40 seconds is chosen for this connection count distribution calculation).

[0097] Secondly, we check the application data packet length from the HTTPS requests to determine if they are the same. If the application data packet lengths from the HTTPS requests for each of these 12 sessions are the same length, this is another heuristic used as another indicator that it is likely to be associated with Cobalt Strike Beacon C2 HTTPS traffic.

[0098] Thirdly, another heuristic checks whether there is only one application request data within the request direction, and if so, this is used as another indicator that it is likely to be associated with Cobalt Strike Beacon C2 HTTPS traffic.

[0099] Based on the heuristics described above, if these logical checks result in a match, it is determined that the network traffic for such a session is associated with Cobalt Strike Beacon C2 HTTP traffic. If no match is found, it is determined that the network traffic for such a session is not associated with Cobalt Strike Beacon C2 HTTP traffic. The determination is stored in the fast match table, as shown in 416. Specifically, after the determination is made as described above, the detection system adds a 3-tuple (e.g., SrcIP, DstIP, Dstport) along with the determination to the fast match table. Thus, the detection system queries the fast match table for subsequent sessions, as described above, to facilitate more efficient determination of determinations for previously analyzed HTTP traffic.

[0100] In 418, the quality check system 404 performs verification of the results of the detection system 402 to determine whether any previous determination for the Cobalt Strike Beacon C2 HTTPS traffic was a false positive or a false negative. Specifically, the destination IP probing and verification module (e.g., a subcomponent) performs automated probing of the destination IP address by sending a custom HTTPS request (e.g., a custom HTTP / HTTPS / DNS request) to the destination IP address. As shown in 420, the destination IP probing and verification module then determines whether the response contains a fingerprint associated with Cobalt Strike (for example, HTTPS response data contains a default certificate provided by Cobalt Strike and / or the HTTPS response matches the fingerprint of Cobalt Strike (CS). That is, in an exemplary implementation, the CS fingerprint is a default string included in the response traffic from the CS team server. For example, when a client sends an HTTPS request with a client hello to a CS team server, the team server responds to the client with a server hello and a server certificate, and by default, the certificate contains the CS keyword "Major Cobalt Strike" ("Major Cobalt Strike"), and thus the certificate keyword "Major Cobalt Strike" can be used as a fingerprint to identify the CS team server, as will be further described below with respect to various embodiments), and the Cobalt Strike beacon C2 of the network traffic / session communicating with the destination IP address. Verify HTTPS traffic (CS) detection.As one example, the quality check system may perform a malware IP address lookup to determine whether DestIP is associated with Cobalt Strike Beacon-related malware (e.g., a known malware sample previously identified as Cobalt Strike Beacon-related malware based on previous malware analysis), and then the determination of Cobalt Strike Beacon C2 HTTPS traffic (CS) may be verified. Otherwise, the determination is automatically changed from CS to benign (e.g., providing a feedback loop to improve the CS detection heuristics implemented in detection system 402). Thus, the quality check system may verify the determination in an attempt to detect any false positives or false negatives for Cobalt Strike Beacon C2 HTTPS traffic.

[0101] The behavior-based and inter-session detection techniques disclosed for performing Cobalt Strike Beacon C2 HTTPS traffic detection, based on experimental / test results, promote a 90% improvement in detection rate for Cobalt Strike Beacon C2 HTTPS traffic detection compared to existing IPS signature-based approaches (e.g., for default / known profiles for Cobalt Strike Beacon C2 HTTPS traffic).

[0102] Exemplary use cases of Cobalt Strike Beacon HTTP C2 heuristic detection

[0103] Figure 5A shows exemplary attributes associated with cobalt strike beacon HTTP traffic used for heuristic detection according to several embodiments. Referring to Figure 5A, this exemplary network traffic shows an HTTP request header MD5 hash which is identical to the request URL as shown in 502, and a cookie (e.g., codingbase64) as shown in 504, associated with the session for such cobalt strike beacon HTTP traffic. Thus, this example shows network traffic that satisfies the pre-filtering criteria, as similarly described above with respect to Figure 4A. First, the header value or URI length check matches the range of 171 to 256 bytes. Second, the network traffic includes a header value or URI length field with base64 encoding, and therefore matches one of these types of encodings, namely base64, base64url, netbios, netbiosu, or mask. As a result, this network traffic, indicated by 506, is forwarded to Cloud Security 122 for further analysis using the CSB detector 154, as similarly described above with respect to Figure 4A.

[0104] Figure 5B shows additional exemplary attributes associated with cobalt strike beacon HTTP traffic used for heuristic detection according to several embodiments. Referring to Figure 5B, this exemplary network traffic has fewer than 10 request header fields, as shown in 520 (i.e., only 6 request header fields are present in this example), which is associated with a cobalt strike (CS) HTTP request, compared to a benign HTTP request in 522, which has more HTTP request header fields (i.e., more than 10 request header fields). Thus, as shown in 520, this exemplary network traffic satisfies the fourth heuristic described above relating to the number of HTTP header fields (i.e., the number of fields included in the HTTP header is less than 10 fields in the HTTP header), as similarly described above with respect to Figure 4A.

[0105] Figure 5C shows additional exemplary attributes associated with cobalt strike beacon HTTP traffic used for heuristic detection according to several embodiments. Referring to Figure 5C, this exemplary network traffic represents an HTTP user agent that is a known user agent (UA) and does not have a custom header, as shown in 530. Thus, as shown in 530, this exemplary network traffic satisfies the sixth heuristic described above relating to whether the HTTP user agent (UA) is a known / popular UA, as similarly described above with respect to Figure 4A.

[0106] Figure 5D shows additional exemplary attributes associated with cobalt strike beacon HTTP traffic used for heuristic detection according to several embodiments. Referring to Figure 5D, this exemplary network traffic shows HTTP request header content that does not have a custom header, as shown in 540. Thus, as shown in 540, this exemplary network traffic satisfies the fifth heuristic described above, relating to whether the HTTP header does not contain a custom header, as similarly described above with respect to Figure 4A.

[0107] Exemplary use cases of Cobalt Strike Beacon HTTPS C2 heuristic detection

[0108] Figure 5E shows additional exemplary attributes associated with cobalt strike beacon HTTPS traffic used for heuristic detection, according to several embodiments. Referring to Figure 5E, as shown at 550, this exemplary network traffic represents an HTTPS request in which the Server Halo Random Field value includes the value "DOWNGRD", as similarly described above with respect to Figure 4B. Consequently, as shown at 506, this network traffic is forwarded to Cloud Security 122 for further analysis using the CSB detector 154, as similarly described above with respect to Figure 4B.

[0109] Figure 5F shows additional exemplary attributes associated with cobalt strike beacon HTTPS traffic used for heuristic detection according to several embodiments. Referring to Figure 5F, as shown in 560, this exemplary network traffic shows the amount of SSL application data in the request direction, as similarly described above with respect to Figure 4B. Specifically, as similarly described above with respect to Figure 4B, the second check performed by the HTTPS logical module is to determine whether the application data packet lengths from the HTTPS requests are identical. If the application data packet lengths from the HTTPS requests for each of these 12 sessions are the same length as shown in 560 (e.g., 1365 bytes), this is used as another indicator that it is likely to be associated with cobalt strike beacon C2 HTTPS traffic, which is another heuristic.

[0110] Figure 5G shows additional exemplary attributes associated with cobaltstrike beacon HTTPS traffic used for heuristic detection according to several embodiments. Referring to Figure 5G, as shown in 570, this exemplary network traffic shows the amount of SSL application data in the request direction, as similarly described above with respect to Figure 4B. Specifically, as similarly described above with respect to Figure 4B, the third check performed by the HTTPS logical module is to determine whether there is only one application request data in the request direction (e.g., with a length of 459 bytes) (e.g., a heuristic performed for each of these analyzed (12) sessions), which is another heuristic used as another indicator that this is likely to be associated with cobaltstrike beacon C2 HTTPS traffic.

[0111] An additional exemplary process for the disclosed techniques for cobalt strike beacon HTTP / HTTPS C2 heuristic detection will now be described.

[0112] Exemplary Process for Cobalt Strike Beacon HTTP C2 Heuristic Detection

[0113] Figure 6 is a flowchart relating to a process for cobalt strike beacon HTTP C2 heuristic detection according to several embodiments. In some embodiments, the process 600 shown in Figure 6 is performed by the security platform and techniques similarly described above, including embodiments described with respect to Figures 1-5G. In one embodiment, the process 600 is performed by the data appliance 102 described with respect to Figure 1, the security platform 122 described with respect to Figure 1 (e.g., as a cloud-based security service), a virtual appliance (e.g., Palo Alto Networks' VM Series virtualized next-generation firewall, CN Series container next-generation firewall, and / or other commercially available virtual-based or container-based firewalls similarly implemented and configured to perform the disclosed techniques), an SDN security solution, a cloud security service, and / or a combination or hybrid implementation of the foregoing described herein.

[0114] In 602, HTTP network traffic is monitored by the firewall. For example, the firewall can use application identification to detect HTTP traffic, as similarly described above with respect to Figures 1 and 4A.

[0115] In 604, pre-filtering of monitored HTTP network traffic is performed at the firewall to select a subset of HTTP network traffic to forward to the cloud security service. For example, the HTTP pre-filtering module can perform heuristic analysis of HTTP network traffic to select a subset of HTTP traffic sessions to forward to the cloud security service for further analysis, as similarly described above with respect to Figures 4A and 5A-5D.

[0116] In 606, a determination is made based on multiple heuristics as to whether a subset of HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity. For example, the HTTP logical module can perform further heuristic analysis of HTTP network traffic to automatically detect Cobalt Strike Beacon HTTP C2 traffic, as described above with respect to Figures 4A and 5A-5D.

[0117] In 608, an action is taken in response to the detection of Cobalt Strike Beacon HTTP C2 traffic activity. The security platform (122) and / or data appliance (102) can then take action in response to the malware determination based on a policy (for example, a security / C2-related malware policy which may be stored in policy 252 as shown in Figure 2B). For example, the data appliance may be configured to block Cobalt Strike Beacon HTTP C2 traffic activity. Other exemplary actions may include: This includes blocking access to destination IP addresses associated with detected Cobalt Strike Beacon HTTP C2 traffic activity, blocking / dropping network traffic associated with and / or that destination IP address, alerting endpoint users and / or network / security administrators that an endpoint has been associated with detected Cobalt Strike Beacon HTTP C2 traffic activity, isolating endpoint devices associated with detected Cobalt Strike Beacon HTTP C2 traffic activity, and identifying destination IP addresses, URLs, etc. associated with Cobalt Strike Beacon HTTP C2 traffic activity that have been detected as malicious (or potentially malicious). And / or various other actions may also be taken based on the policy.

[0118] Exemplary Process for Cobalt Strike Beacon HTTPS C2 Heuristic Detection

[0119] Figure 7 is a flowchart relating to a process for cobalt strike beacon HTTPS C2 heuristic detection according to several embodiments. In some embodiments, the process 700 shown in Figure 7 is performed by the security platforms and techniques similarly described above, including embodiments described above with respect to Figures 1-5G. In one embodiment, the process 700 is performed by the data appliance 102 described above with respect to Figure 1, the security platform 122 described above with respect to Figure 1 (e.g., as a cloud-based security service), a virtual appliance (e.g., Palo Alto Networks' VM Series virtualized next-generation firewall, CN Series container next-generation firewall, and / or other commercially available virtual-based or container-based firewalls similarly implemented and configured to perform the disclosed techniques), an SDN security solution, a cloud security service, and / or a combination or hybrid implementation of the foregoing described herein.

[0120] In 702, HTTPS network traffic is monitored by the firewall. For example, the firewall can use application identification to detect HTTPS traffic, as similarly described above with respect to Figures 1 and 4B.

[0121] In 704, pre-filtering of monitored HTTPS network traffic is performed at the firewall to select a subset of HTTPS network traffic to forward to the cloud security service. For example, the HTTPS pre-filtering module can perform heuristic analysis of HTTPS network traffic to select a subset of HTTPS traffic sessions to forward to the cloud security service for further analysis, as similarly described above with respect to Figures 4B and 5E-5G.

[0122] In 706, based on multiple heuristics, it is performed to determine whether a subset of HTTPS network traffic is associated with Cobalt Strike Beacon HTTPS C2 traffic activity. For example, the HTTPS logical check module can perform further heuristic analysis of HTTPS network traffic to automatically detect Cobalt Strike Beacon HTTPS C2 traffic, as similarly described above with respect to Figures 4B and 5E-5G.

[0123] In 708, an action is taken in response to the detection of Cobalt Strike Beacon HTTPS C2 traffic activity. The security platform (122) and / or data appliance (102) can then take action in response to malware determination based on a policy (for example, a security / C2-related malware policy which may be stored in policy 252 as shown in Figure 2B). For example, the data appliance may be configured to block Cobalt Strike Beacon HTTPS C2 traffic activity. Other exemplary actions may include: This includes blocking access to destination IP addresses associated with detected Cobalt Strike Beacon HTTPS C2 traffic activity, blocking / dropping network traffic associated with and / or that destination IP address, alerting endpoint users and / or network / security administrators that an endpoint has been associated with detected Cobalt Strike Beacon HTTPS C2 traffic activity, isolating endpoint devices associated with detected Cobalt Strike Beacon HTTPS C2 traffic activity, and identifying destination IP addresses, URLs, etc. associated with Cobalt Strike Beacon HTTP C2 traffic activity that have been detected as malicious (or potentially malicious). And / or various other actions may also be taken based on the policy.

[0124] Probing for Cobalt Strike Team Server Detection

[0125] Another technical challenge is verifying that the target IP address (e.g., one extracted based on the techniques described above) is hosting the Cobalt Strike team server.

[0126] Accordingly, various techniques for probing (e.g., active probing) for Cobalt Strike Team server detection are disclosed. For example, the disclosed techniques utilize active probing of IP addresses to detect whether an IP address hosts a Cobalt Strike Team server based on the response to the active probing (e.g., packets sent from a target IP address in response to a probe packet).

[0127] In some embodiments, a system / process / computer program product for probing for Cobalt Strike Team server detection includes: monitoring Hypertext Transfer Protocol (HTTP), HTTPS, and / or Domain Name System (DNS) network traffic in a firewall; pre-filtering the monitored HTTP, HTTPS, and / or DNS network traffic in the firewall to select a subset of the HTTP, HTTPS, and / or DNS network traffic for forwarding to a cloud security service; performing HTTP, HTTPS, and / or DNS probing on a target to detect whether the target is a Cobalt Strike Team server; and taking action in response to the detection that the target is a Cobalt Strike Team server.

[0128] In some embodiments, a system / process / computer program product for probing for Cobalt Strike Team Server detection further includes verifying malware determination of Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity.

[0129] In some embodiments, a system / process / computer program product for probing for cobalt strike team server detection further includes a detection system's fast match table storing 3-tuples of previously detected cobalt strike beacon HTTP, HTTPS, and / or DNS C2 traffic activity, where the 3-tuple includes a source IP address, a destination IP address, and a destination port.

[0130] In some embodiments, the system / process / computer program product for probing for cobalt strike team server detection further includes storing data statistics based on automated heuristic analysis of a subset of HTTP, HTTPS, and / or DNS network traffic in the detection system's data statistics table.

[0131] In some embodiments, a system / process / computer program product for probing for Cobalt Strike Team Server detection further includes, based on active probing, performing verification of detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity.

[0132] In some embodiments, a system / process / computer program product for probing for Cobalt Strike Team Server detection further includes performing verification of the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity based on active probing of the destination IP address associated with the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity.

[0133] In some embodiments, a system / process / computer program product for probing for Cobalt Strike Team Server detection further includes performing verification of detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity based on active probing of destination IP addresses associated with detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity, and using a fingerprint data store.

[0134] As similarly described above with respect to Figures 4A and 4B, the destination IP probing and verification component / module of the quality check system 404 performs active probing of IP addresses (e.g., via HTTP or HTTPS) to detect whether an IP address hosts a Cobalt Strike Team Server based on the response to the active probing (e.g., packets sent from the target IP address in response to the probe packet). As will be further described below, the disclosed active probing techniques for Cobalt Strike Team Server detection can be performed using various network protocols, including, for example, HTTP, HTTPS, and / or DNS.

[0135] Generally, the destination IP probing and verification module extracts destination (dst) IP address (dst IP) and port number information from network traffic forwarded / collected from a firewall that monitors network traffic, as similarly described above with respect to Figures 4A and 4B. The destination IP probing and verification module then sends a crafted request (e.g., a sophisticated HTTP / HTTPS / DNS request) to the dst IP and port (e.g., the target). The destination IP probing and verification module then checks / evaluates the response received from the target. If the response content matches a default fingerprint and detection logic, the dst IP, port, and a malicious verdict are inserted into the fast match table (e.g., the fast match table of detection system 402, as similarly described above with respect to Figures 4A and 4B). Otherwise (i.e., there is no match with the default fingerprint and detection logic), the dst IP, port, and a benign verdict are inserted into the fast match table.

[0136] HTTP / HTTPS Probing for Cobalt Strike Team Server Detection

[0137] An exemplary implementation of HTTP / HTTPS active probing for Cobalt Strike Team server detection is described below. As an initial precheck operation of the probing logic, the destination IP probing and verification module sends an elaborate precheck HTTP / HTTPS request to the destination IP and port (e.g., target). An example of an elaborate precheck HTTP / HTTPS request is as follows: http[s]: / / [IP]:[Port] / index.html. The destination IP probing and verification module then checks / evaluates the response to the cleverly crafted precheck HTTP / HTTPS request. Specifically, if the following is received in the response from the target, it is considered suspicious (e.g., it could (likely) be a Cobalt Strike Team server), and further active probing and evaluation are performed. More specifically, the response contains a status code equal to 404, and the HTTP / HTTPS headers contain the following fields and values. That is, “Date” and date value (e.g., “Wed, 9Feb2022 23:09:48 GMT”), “Content-Type”, “text / plain” and “Content-Length”: “0”. Otherwise (e.g., these fields and values ​​are not present in the response from the target), it is determined that the target is not a Cobalt Strike team server, and no further active probing and evaluation are performed, and the determination is deemed benign (and the fast match table may be updated, as described above with respect to Figures 4A and 4B).

[0138] As a final pre-check operation of the HTTP / HTTPS probing logic, the destination IP probing and verification module sends an elaborate HTTP / HTTPS request to the target to download the beacon file. An exemplary elaborate final pre-check HTTP / HTTPS request includes the URL value "Swb1" and is as follows: http[s]: / / [IP]:[Port] / Swb1. In this example, "Swb1" can be any 4 bytes that satisfy the following checksum requirements: the input string text is a 4-byte URL value, and the 4-byte URL checksum value is equal to 92 or 93, depending on the platform, such as using the checksum algorithm shown in Figure 8. Figure 8 shows a checksum algorithm for probing logic for HTTP / HTTPS Cobalt Strike Team Server Detection according to several embodiments. The destination IP probing and verification module then checks / evaluates the response to the created final check HTTP / HTTPS request. If the target is a Cobalt Strike team server, the response from the target will return a status code equal to 200, the HTTP / HTTPS header "Content Length" value will be greater than 200k and less than 300k, and the HTTP / HTTPS body will have the first two bytes equal to 0xFC48 or 0xFCe8 (for example, thus present in the Cobalt Strike shared code of the beacon file based on heuristic analysis of the behavior of the Cobalt Strike team server and the content of its beacon file). Otherwise (for example, if the response does not match the above criteria), it will be determined that the target is not a Cobalt Strike team server, no further active probing and evaluation will be performed, and the verdict will be determined to be benign (and the fast match table may be updated as described above with respect to Figures 4A and 4B).

[0139] DNS probing for Cobalt Strike team server detection

[0140] An exemplary implementation of DNS active probing for Cobalt Strike Team server detection is described below. As an initial pre-check operation of the probing logic, the destination IP probing and verification module performs a final check on DNS probing of the dst IP and port (e.g., target). As a final pre-check operation of the DNS probing logic, the destination IP probing and verification module sends an elaborate DNS request to the target to download a beacon file. Figure 9A shows one exemplary DNS request for performing active probing of a target according to several embodiments. Specifically, an elaborate DNS request is sent to the target to download a beacon file. More specifically, the elaborate DNS request is a txt DNS request with the domain aaa.stage.xxxx, as shown in Figure 9A.

[0141] The destination IP probing and verification module then checks the content of the DNS response from the target. If the target is a Cobalt Strike team server, the response from the target returns a txt DNS record response with content beginning with "WYIIIIIIIIIIII" as shown in Figure 9B (such as existing within Cobalt Strike Base 64 which encodes the shared code for the beacon file based on heuristic analysis of the behavior of the Cobalt Strike team server and the content of its beacon file). Figure 9B shows one exemplary DNS response to active probing of a target according to several embodiments. Otherwise (for example, if the response does not match the above criteria), the target is determined not to be a Cobalt Strike team server, and no further active probing and evaluation are performed, and the verdict is determined to be benign (the fast match table may be updated as described above with respect to Figures 4A and 4B).

[0142] Additional exemplary processes for the disclosed techniques for probing for Cobalt Strike Team server detection are described below.

[0143] Exemplary process of HTTP / HTTPS probing for Cobalt Strike team server detection

[0144] Figure 10 is a flowchart relating to the HTTP / HTTPS probing process for Cobalt Strike Team server detection according to several embodiments. In some embodiments, process 1000 as shown in Figure 10 is performed by security platforms and techniques similarly described above, including embodiments described with respect to Figures 1-8. In one embodiment, process 1000 is performed by the data appliance 102 described with respect to Figure 1, the security platform 122 described with respect to Figure 1 (e.g., as a cloud-based security service), virtual appliances (e.g., Palo Alto Networks' VM Series virtualized next-generation firewalls, CN Series container next-generation firewalls, and / or other commercially available virtual-based or container-based firewalls similarly implemented and configured to perform the disclosed techniques), SDN security solutions, cloud security services, and / or combinations or hybrid implementations of the foregoing described herein.

[0145] In 1002, HTTP / HTTPS network traffic is monitored by the firewall. For example, the firewall can use application identification to detect HTTP / HTTPS traffic, as similarly described above with respect to Figures 1 and 4A-4B.

[0146] In 1004, pre-filtering of monitored HTTP / HTTPS network traffic is performed in the firewall to select a subset of HTTP / HTTPS network traffic to forward to the cloud security service. For example, the HTTP / HTTPS pre-filtering module can perform heuristic analysis of HTTP / HTTPS network traffic to select a subset of HTTP / HTTPS traffic sessions to forward to the cloud security service for further analysis, as similarly described above with respect to Figures 4A-4B and 5A-5G.

[0147] In 1006, HTTP / HTTPS probing of the target is performed to detect whether the target is a Cobalt Strike Team server. For example, the destination IP probing and verification module can perform further heuristic analysis of the response from the target to automatically detect a Cobalt Strike Team server, as described above with respect to Figures 4A-4B, 5A-5G, and 8.

[0148] In 1008, an action is taken in response to the detection that the target is a Cobalt Strike team server. The security platform (122) and / or data appliance (102) can then take action in response to the malware determination based on a policy (for example, a security / C2-related malware policy which may be stored in policy 252 as shown in Figure 2B). For example, the data appliance may be configured to block Cobalt Strike beacon HTTP / HTTPS C2 traffic activity. Other exemplary actions may include: This includes blocking access to destination IP addresses associated with detected Cobalt Strike Beacon HTTP / HTTPS C2 traffic activity, blocking / dropping network traffic associated with and / or that destination IP address, alerting endpoint users and / or network / security administrators that an endpoint has been associated with detected Cobalt Strike Beacon HTTP / HTTPS C2 traffic activity, isolating endpoint devices associated with detected Cobalt Strike Beacon HTTP / HTTPS C2 traffic activity, and identifying destination IP addresses, URLs, etc. associated with Cobalt Strike Beacon HTTP / HTTPS C2 traffic activity that have been detected as malicious (or potentially malicious). And / or various other actions may also be taken based on the policy.

[0149] Exemplary DNS probing process for Cobalt Strike team server detection

[0150] Figure 11 is a flowchart relating to the DNS probing process for Cobalt Strike Team Server Discovery according to several embodiments. In some embodiments, the process 1100 shown in Figure 11 is performed by the security platforms and techniques similarly described above, including embodiments described with respect to Figures 1-7 and 9A-9B. In one embodiment, the process 1100 is performed by the data appliance 102 described with respect to Figure 1, the security platform 122 described with respect to Figure 1 (e.g., as a cloud-based security service), a virtual appliance (e.g., Palo Alto Networks' VM Series virtualized next-generation firewall, CN Series container next-generation firewall, and / or other commercially available virtual-based or container-based firewalls similarly implemented and configured to perform the disclosed techniques), an SDN security solution, a cloud security service, and / or a combination or hybrid implementation of the foregoing described herein.

[0151] In version 1102, DNS network traffic is monitored by the firewall. For example, the firewall can use application identification to detect DNS traffic, as similarly described above with respect to Figures 1 and 4A-4B.

[0152] In 1104, pre-filtering of monitored DNS network traffic is performed at the firewall to select a subset of DNS network traffic to forward to the cloud security service. For example, the DNS pre-filtering module can perform heuristic analysis of DNS network traffic to select a subset of DNS traffic sessions to forward to the cloud security service for further analysis, as similarly described above with respect to Figures 4A-4B and 5A-5G and further described below.

[0153] An exemplary implementation of DNS pre-filtering operation, similarly shown in 410 in Figure 4A, can be performed by a DNS pre-filter module implemented on firewall 102 by performing the following heuristic analysis: if the DNS request is a DNS txt record (e.g., dns.qry.type==16(txt record)), the traffic is forwarded to the cloud for further cobalt strike detection analysis.

[0154] In 1106, DNS probing of the target is performed to detect whether the target is a Cobalt Strike Team server. For example, the destination IP probing and verification module can perform further heuristic analysis of the response from the target to automatically detect a Cobalt Strike Team server, as similarly described above with respect to Figures 4A-4B, 5A-5G, and 9A-9B.

[0155] In 1108, an action is taken in response to the detection that the target is a Cobalt Strike team server. The security platform (122) and / or data appliance (102) can then take action in response to the malware determination based on a policy (for example, a security / C2-related malware policy which may be stored in policy 252 as shown in Figure 2B). For example, the data appliance may be configured to block Cobalt Strike beacon DNS C2 traffic activity. Other exemplary actions may include: This includes blocking access to destination IP addresses associated with detected Cobalt Strike Beacon DNS C2 traffic activity, blocking / dropping network traffic associated with and / or that destination IP address, alerting endpoint users and / or network / security administrators that an endpoint has been associated with detected Cobalt Strike Beacon DNS C2 traffic activity, isolating endpoint devices associated with detected Cobalt Strike Beacon DNS C2 traffic activity, and identifying destination IP addresses, URLs, etc. associated with Cobalt Strike Beacon DNS C2 traffic activity that have been detected as malicious (or potentially malicious). And / or various other actions may also be taken based on the policy.

[0156] While the embodiments described above have been explained in some detail for the purpose of clarifying understanding, the present invention is not limited to the details provided. Many alternative methods exist for carrying out the present invention. The disclosed embodiments are illustrative and not limiting.

Claims

1. A system including a processor and memory, The aforementioned system includes a detection system and a quality check system, The aforementioned processor, Hypertext Transfer Protocol (HTTP) network traffic is monitored by the firewall. The monitored HTTP network traffic is pre-filtered by the firewall to select a subset of the HTTP network traffic for forwarding to the cloud security service. Pre-filtering the monitored HTTP network traffic in the firewall to select a subset of the HTTP network traffic for forwarding to the cloud security service includes performing heuristic analysis on the HTTP network traffic to select a subset of the HTTP network traffic for forwarding to the cloud security service for further analysis to detect potential cobalt strike beacon HTTP C2 traffic. The heuristic analysis of the HTTP network traffic is performed so that the firewall selects a subset of the HTTP network traffic for further analysis to detect potential cobalt strike beacon HTTP C2 traffic, and forwards this analysis to the cloud security service. (1) Whether the HTTP network traffic includes a default header value or default URI length check data that matches the range of 171 bytes to 256 bytes, and (2) Whether the HTTP network traffic includes a header value or URI length field with an encoding that matches the default type of encoding, which includes one or more of the following encoding types: base64, base64url, netbios, or netbiosu. Including determining, Based on multiple heuristics performed in the aforementioned cloud security service, it is determined whether the subset of the HTTP network traffic is associated with cobalt strike beacon HTTP C2 traffic activity. Based on multiple heuristics, including performing data statistics checks to perform behavior-based detection of Cobalt Strike Beacon HTTP C2 traffic activity, which includes checking the timestamp of the last active time for at least the first 12 sessions to determine whether it is Gaussian or normal, the cloud security service automatically determines whether a subset of the HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity. and, In response to detecting the aforementioned Cobalt Strike Beacon HTTP C2 traffic activity, the firewall takes action: It is configured in such a way, The aforementioned memory is It is coupled to the aforementioned processor, and The processor is configured to give instructions, system.

2. The high-speed match table of the aforementioned detection system stores previously detected cobalt strike beacon HTTP C2 traffic activity. The system according to claim 1.

3. The high-speed match table of the aforementioned detection system stores 3-tuples of previously detected cobalt strike beacon HTTP C2 traffic activity. The aforementioned 3-tuple includes the source IP address, the destination IP address, and the destination port. The system according to claim 1.

4. Data statistics based on automated heuristic analysis of the subset of HTTP network traffic are stored in the data statistics table of the detection system. The system according to claim 1.

5. The aforementioned processor further, The following steps are performed to verify the detected cobalt strike beacon HTTP C2 traffic activity: It is structured in such a way. The system according to claim 1.

6. The aforementioned processor further, Based on the probing of the destination IP address associated with the detected cobalt strike beacon HTTP C2 traffic activity, the system performs verification of the detected cobalt strike beacon HTTP C2 traffic activity. It is structured in such a way. The system according to claim 1.

7. The aforementioned processor further, Based on the probing of the destination IP address associated with the detected cobalt strike beacon HTTP C2 traffic activity, and using the fingerprint datastore, the detected cobalt strike beacon HTTP C2 traffic activity is verified. It is structured in such a way. The system according to claim 1.

8. It is a method, Steps to monitor Hypertext Transfer Protocol (HTTP) network traffic using a firewall, The step involves pre-filtering the monitored HTTP network traffic in the firewall so as to select a subset of the HTTP network traffic for forwarding to the cloud security service. Pre-filtering the monitored HTTP network traffic in the firewall to select a subset of the HTTP network traffic for forwarding to the cloud security service includes performing heuristic analysis on the HTTP network traffic to select a subset of the HTTP network traffic for forwarding to the cloud security service for further analysis to detect potential cobalt strike beacon HTTP C2 traffic. The heuristic analysis of the HTTP network traffic is performed so that the firewall selects a subset of the HTTP network traffic for further analysis to detect potential cobalt strike beacon HTTP C2 traffic, and forwards this analysis to the cloud security service. (1) Whether the HTTP network traffic includes a default header value or default URI length check data that matches the range of 171 bytes to 256 bytes, and (2) Whether the HTTP network traffic includes a header value or URI length field with an encoding that matches the default type of encoding, which includes one or more of the following encoding types: base64, base64url, netbios, or netbiosu. Including determining Steps and The step of determining whether the subset of HTTP network traffic is associated with cobalt strike beacon HTTP C2 traffic activity, based on a plurality of heuristics performed in the cloud security service, Based on multiple heuristics, including performing data statistics checks to perform behavior-based detection of Cobalt Strike Beacon HTTP C2 traffic activity, which includes checking the timestamp of the last active time for at least the first 12 sessions to determine whether it is Gaussian or normal, the cloud security service automatically determines whether a subset of the HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity, in the following steps: The steps include: taking action on the firewall in response to detecting the aforementioned cobalt strike beacon HTTP C2 traffic activity; Methods that include...

9. The above method further, The step of performing verification of the detected cobalt strike beacon HTTP C2 traffic activity, The method according to claim 8, including the method described in claim 8.

10. The above method further, The step of verifying the detected cobalt strike beacon HTTP C2 traffic activity based on probing the destination IP address associated with the detected cobalt strike beacon HTTP C2 traffic activity, The method according to claim 8, including the method described in claim 8.

11. The above method further, The steps include: performing verification of the detected cobalt strike beacon HTTP C2 traffic activity based on probing the destination IP address associated with the detected cobalt strike beacon HTTP C2 traffic activity, and using a fingerprint datastore; The method according to claim 8, including the method described in claim 8.

12. A computer program stored on a tangible computer-readable storage medium, which includes computer instructions, When the computer instruction is executed, the computer will, Steps to monitor Hypertext Transfer Protocol (HTTP) network traffic using a firewall, The step involves pre-filtering the monitored HTTP network traffic in the firewall so as to select a subset of the HTTP network traffic for forwarding to the cloud security service. Pre-filtering the monitored HTTP network traffic in the firewall to select a subset of the HTTP network traffic for forwarding to the cloud security service includes performing heuristic analysis on the HTTP network traffic to select a subset of the HTTP network traffic for forwarding to the cloud security service for further analysis to detect potential cobalt strike beacon HTTP C2 traffic. The heuristic analysis of the HTTP network traffic is performed so that the firewall selects a subset of the HTTP network traffic for further analysis to detect potential cobalt strike beacon HTTP C2 traffic, and forwards this analysis to the cloud security service. (1) Whether the HTTP network traffic includes a default header value or default URI length check data that matches the range of 171 bytes to 256 bytes, and (2) Whether the HTTP network traffic includes a header value or URI length field with an encoding that matches the default type of encoding, which includes one or more of the following encoding types: base64, base64url, netbios, or netbiosu. Including determining Steps and The step of determining whether the subset of HTTP network traffic is associated with cobalt strike beacon HTTP C2 traffic activity, based on a plurality of heuristics performed in the cloud security service, Based on multiple heuristics, including performing data statistics checks to perform behavior-based detection of Cobalt Strike Beacon HTTP C2 traffic activity, which includes checking the timestamp of the last active time for at least the first 12 sessions to determine whether it is Gaussian or normal, the cloud security service automatically determines whether a subset of the HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity, in the following steps: The steps include: taking action on the firewall in response to detecting the aforementioned cobalt strike beacon HTTP C2 traffic activity; To implement a method that includes, Computer program.

13. The aforementioned computer program, When the aforementioned computer instruction is executed, the computer further: The step of performing verification of the detected cobalt strike beacon HTTP C2 traffic activity, To implement a method that includes, The computer program according to claim 12.

14. The aforementioned computer program, When the aforementioned computer instruction is executed, the computer further: The step of verifying the detected cobalt strike beacon HTTP C2 traffic activity based on probing the destination IP address associated with the detected cobalt strike beacon HTTP C2 traffic activity, To implement a method that includes, The computer program according to claim 12.

15. The aforementioned computer program, When the aforementioned computer instruction is executed, the computer further: The steps include: performing verification of the detected cobalt strike beacon HTTP C2 traffic activity based on probing the destination IP address associated with the detected cobalt strike beacon HTTP C2 traffic activity, and using a fingerprint datastore; To implement a method that includes, The computer program according to claim 12.

Images