COBALT STRIKE BEACON HTTP C2 heuristic detection

Abstract

The invention discloses a technology for the heuristic detection of a Cobalt Strike Beacon HTTP (Hyper Text Transport Protocol) C2 (C2). In some embodiments, a system / process / computer program product for Cobalt Strike Beacon HTTP C2 heuristic detection includes: monitoring hypertext transfer protocol (HTTP) network traffic at a firewall; pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic for forwarding to a cloud security service; determining, based on a plurality of heuristics, whether the subset of HTTP network traffic is associated with a Cobalt Strike Beacon HTTP C2 traffic activity, and if the subset of HTTP network traffic is associated with a Cobalt Strike Beacon HTTP C2 traffic activity; and in response to the fact that the Cobalt Strike Beacon HTTP C2 service activity is detected, an action is executed.

Description

Background Art

[0001] Malware is a general term that is often used to refer to rogue software (e.g., including a variety of hostile, intrusive and / or other unwanted software). Malware can be in the form of code, scripts, active content and / or other software. Example uses of malware include disrupting computer and / or network operations, stealing proprietary information (e.g., confidential information such as identity, financial and / or intellectual property related information) and / or gaining access to private / proprietary computer systems and / or computer networks. Unfortunately, as technology is developed to help detect and mitigate malware, the evil authors have found ways to circumvent such efforts. Therefore, there is a constant need to improve the technology for identifying and mitigating malware. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various embodiments of the invention are disclosed in the following detailed description and accompanying drawings.

[0003] Figure 1 An example of an environment in which malicious applications ("malware") are detected and prevented from causing damage is illustrated.

[0004] Figure 2A An embodiment of a data appliance is illustrated.

[0005] Figure 2B is a functional diagram of the logical components of an embodiment of a data appliance.

[0006] Figure 3 Examples of logical components that may be included in a system for analyzing a sample are illustrated.

[0007] Figure 4A Portions of example embodiments of a detection system and quality check system for processing network traffic to perform Cobalt Strike Beacon C2 HTTP traffic detection in accordance with some embodiments are illustrated.

[0008] Figure 4B Portions of example embodiments of a detection system and quality check system for processing network traffic to perform Cobalt Strike Beacon C2 HTTPS traffic detection in accordance with some embodiments are illustrated.

[0009] Figure 5A Illustrated are example properties associated with Cobalt Strike Beacon HTTP traffic for heuristic detection in accordance with some embodiments.

[0010] Figure 5BIllustrated are additional example properties associated with Cobalt Strike Beacon HTTP traffic for heuristic detection in accordance with some embodiments.

[0011] Figure 5C Illustrated are additional example properties associated with Cobalt Strike Beacon HTTP traffic for heuristic detection in accordance with some embodiments.

[0012] Figure 5D Illustrated are additional example properties associated with Cobalt Strike Beacon HTTP traffic for heuristic detection in accordance with some embodiments.

[0013] Figure 5E Illustrated are additional example properties associated with the Cobalt Strike Beacon HTTPS service for heuristic detection in accordance with some embodiments.

[0014] Fig. 5F Illustrated are additional example properties associated with the Cobalt Strike Beacon HTTPS service for heuristic detection in accordance with some embodiments.

[0015] Figure 5G Illustrated are additional example properties associated with the Cobalt Strike Beacon HTTPS service for heuristic detection in accordance with some embodiments.

[0016] Figure 6 is a flow diagram of a process for Cobalt Strike Beacon HTTP C2 heuristic detection according to some embodiments.

[0017] Figure 7 is a flow diagram of a process for Cobalt Strike Beacon HTTPS C2 heuristic detection according to some embodiments.

[0018] Figure 8 Illustrated is a checksum algorithm for a logical probe for HTTP / HTTPS Cobalt Strike team server detection in accordance with some embodiments.

[0019] Fig. 9A Illustrated are example DNS requests for performing active probing of a target in accordance with some embodiments.

[0020] Fig. 9B Illustrated is an example DNS response to an active probe of a target in accordance with some embodiments.

[0021] Fig.10 is a flow diagram of a process for HTTP / HTTPS probing for Cobalt Strike team server detection according to some embodiments.

[0022] Fig.11 is a flow diagram of a process for DNS probing for Cobalt Strike team server detection according to some embodiments. DETAILED DESCRIPTION

[0023] The present invention can be implemented in many ways, including as a process; an apparatus; a system; a material composition; a computer program product embodied on a computer-readable storage medium; and / or a processor, such as a processor configured to execute instructions stored on a memory coupled to the processor and / or provided by the memory. In this specification, these implementations or any other form that the present invention can take can be referred to as technology. In general, the order of the steps of the disclosed process can be changed within the scope of the present invention. Unless otherwise stated, a component described as being configured to perform a task (such as a processor or memory) can be implemented as a general component temporarily configured to perform the task at a given time, or a dedicated component manufactured to perform the 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).

[0024] The following is an attached diagram illustrating the principle of the present invention. Figure 1 A detailed description of one or more embodiments of the invention is provided. The invention is described in conjunction with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims, and the invention encompasses many alternatives, modifications, and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for illustrative purposes, and the invention may be practiced according to the claims without some or all of these specific details. For purposes of clarity, technical materials known in the technical field related to the invention are not described in detail so as not to unnecessarily obscure the invention.

[0025] A firewall generally protects a network from unauthorized access while allowing authorized communications to pass through the firewall. A firewall is generally a device, a group of devices, or software executed on a device that provides firewall functionality for network access. For example, a firewall may be integrated into an operating system of a device (e.g., a computer, a smart phone, or other types of devices capable of network communication). A firewall may also be integrated into one or more software applications on various types of devices (such as, computer servers, gateways, network / routing devices (e.g., network routers), and data appliances (e.g., security appliances or other types of dedicated devices)) or performed as the software application, and in various implementations, certain operations may be implemented in dedicated hardware (such as ASIC or FPGA).

[0026] Firewalls typically deny or allow network transmissions based on a set of rules. These rule sets 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 protected devices. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allowing, blocking, monitoring, notifying or logging, and / or other actions can be specified in a firewall rule or firewall policy, which can be triggered based on various criteria such as those described herein). A firewall can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.

[0027] Security devices (e.g., security appliances, security gateways, security services, and / or other security devices) may include various security functions (e.g., firewalls, anti-malware, intrusion prevention / detection, data loss prevention (DLP), and / or other security functions), networking functions (e.g., routing, quality of service (QoS), workload balancing of network-related resources, and / or other networking functions), and / or other functions. For example, routing functions may be based on source information (e.g., IP address and port), destination information (e.g., IP address and port), and protocol information.

[0028] Basic packet filtering firewalls filter network traffic by inspecting individual packets transmitted on the network (e.g., packet filtering firewalls or first generation firewalls, which are stateless packet filtering firewalls). Stateless packet filtering firewalls typically inspect each packet itself and apply rules based on the inspected packets (e.g., using a combination of the packet's source and destination address information, protocol information, and port number).

[0029] Application firewalls can also perform application layer filtering (e.g., application layer filtering firewalls or second generation firewalls, which work at the application level of the TCP / IP stack). Application layer filtering firewalls or application firewalls can generally identify certain applications and protocols (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 other protocols, such as Telnet (remote login), DHCP, TCP, UDP, and TFTP (GSS)). For example, an application firewall can block unauthorized protocols that attempt to communicate on standard ports (e.g., an application firewall can generally be used to identify unauthorized protocols / out-of-policy protocols that attempt to sneak through by using non-standard ports for the protocol).

[0030] A stateful firewall may also perform state-based packet inspection, where each packet is inspected within the context of a series of packets associated with the packet stream transmitted by the network. This firewall technology is often referred to as stateful packet inspection because it maintains a record of all connections passing through the firewall and is able to determine whether a packet is the beginning of a new connection, part of an existing connection, or an invalid packet. For example, the connection state itself can be one of the criteria for triggering a rule within a policy.

[0031] As discussed above, an advanced firewall or next-generation firewall can perform stateless packet filtering and stateful packet filtering and application layer filtering. Next-generation firewalls can also perform additional firewall technologies. For example, some newer firewalls, sometimes referred to as advanced firewalls or next-generation firewalls, can also identify users and content (e.g., next-generation firewalls). In particular, some next-generation firewalls extend 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., the PA series firewalls of Palo Alto Networks). For example, the next-generation firewalls of Palo Alto Networks enable enterprises to use various identification technologies to identify and control applications, users and content, rather than just ports, IP addresses and packets, such as the following: App-ID for accurate application identification, user ID for user identification (e.g., by user or user group), and content ID for real-time content scanning (e.g., controlling web surfing and limiting data and file transfer). These identification technologies allow enterprises to use business-related concepts to safely enable application use, rather than following the traditional methods provided by traditional port blocking firewalls. Moreover, for application inspection, dedicated hardware for next-generation firewalls (e.g., implemented as dedicated appliances) generally provides higher performance levels than software executing on general-purpose hardware (e.g., security appliances such as those offered by Palo Alto Networks, which use dedicated, function-specific processing tightly integrated with a single-pass software engine to maximize network throughput while minimizing latency).

[0032] Advanced or next-generation firewalls may 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 a variety of commercial virtualization environments, including, for example, ESXi TM and NSX TM , NetScaler SDX TM , KVM / OpenStack (Centos / RHEL, ) and Amazon Web Services (AWS)) and CN series container next-generation firewalls. For example, the virtualized firewall can support similar or identical next-generation firewall and advanced threat protection features available in physical form factor appliances, allowing enterprises to safely enable applications to flow into and across their private, public and hybrid cloud computing environments. Automation features such as VM monitoring, dynamic address groups, and REST-based APIs allow enterprises to proactively monitor VM changes to dynamically feed that context into security policies, eliminating policy lags that can occur when VMs change.

[0033] Overview of Technology for Cobalt Strike Beacon HTTP / HTTPS C2 Heuristic Detection Typically, existing anti-malware security solutions often fail to detect new malware or new malware variants based on malware signatures (e.g., predefined patterns, such as intrusion prevention system (IPS) signatures). Specifically, if a malware signature for the new malware or new malware variant does not yet exist, existing anti-malware security solutions often fail to detect the new malware or new malware variant (e.g., currently, signature-based content IPS solutions often fail to effectively detect Cobalt Strike Beacon C2 traffic because using existing signature-based content IPS solutions often only detect(s) default profiles or(s) known profiles). These deficiencies associated with existing malware solutions expose enterprises to significant security risks due to the inability to detect such new malware or new malware variants.

[0034] Cobalt Strike is an example of a type of malware that uses evasion techniques to bypass malware solutions that rely on pattern matching based on pre-existing malware signatures (e.g., penetration testing service providers (penetration testers) often use Cobalt Strike (CS) tools to test commercially available security solutions, such as firewall security solutions). Cobalt Strike is a commercially / publicly available toolkit that is 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., exfiltrating confidential / proprietary data associated with corporate networks, etc.).

[0035] Specifically, malware writers can configure their own command and control (C2 or C&C) profiles for Cobalt Strike to avoid malware solutions that rely on pattern matching based on pre-existing malware signatures. The Cobalt Strike toolkit generates C2 services that can be based on various protocols, including Hypertext Transfer Protocol (HTTP), Hypertext Transfer Secure Protocol (HTTPS), and Domain Name System (DNS) protocols.

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

[0037] Thus, new and improved techniques for Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection are disclosed.

[0038] A new malware detection solution is disclosed that includes a new behavior-based detection solution (e.g., using heuristics-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 a Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Secure Protocol (HTTPS) protocol. The new malware detection solution can use heuristics to determine the conclusion that a sample is malware in order to detect Cobalt Strike Beacon C2 HTTP / HTTPS traffic based on monitored network traffic activity, even if there is no existing IPS signature that effectively detects Cobalt Strike Beacon C2 HTTP / HTTPS traffic.

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

[0040] In some embodiments, a system / process / computer program product for Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection includes: monitoring HTTP / HTTPS network traffic at a firewall; pre-filtering the monitored HTTP / HTTPS network traffic at the firewall to select a subset of HTTPS network traffic to forward to a cloud security service; determining whether the subset of HTTPS network traffic is associated with Cobalt Strike Beacon HTTP / HTTPS C2 business activity based on multiple heuristics; and performing an action in response to detecting Cobalt Strike Beacon HTTP / HTTPS C2 business activity.

[0041] In some embodiments, the system / process / computer program product for Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection further includes using the detection system's quick match table to store previously detected Cobalt Strike Beacon HTTP / HTTPS C2 business activities, wherein the detection system's quick match table stores triplets of previously detected Cobalt Strike Beacon HTTP / HTTPS C2 business activities, and wherein the triplet includes a source IP address, a destination IP address, and a destination port.

[0042] 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 automatic heuristic analysis of a subset of HTTP / HTTPS network traffic, wherein the data statistics are stored in a data statistics table of the detection system.

[0043] 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 business activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTP / HTTPS C2 business activity and using a fingerprint data repository.

[0044] In some embodiments, a system / process / computer program product for Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection includes: monitoring Hypertext Transfer Protocol (HTTP) network traffic at a firewall; pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic to forward to a cloud security service, wherein pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic to forward to the cloud security service includes performing a heuristic analysis of the HTTP network traffic to select a subset of the HTTP network traffic to forward 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 determining the following to select a subset of the HTTP traffic to forward to the cloud security service for further analysis to detect potential Cobalt Strike Beacon HTTP C2 business: whether the network business includes a header value or URI length check that matches the range of 171 bytes to 256 bytes; and whether the network business includes a header value or URI length field that matches one of these types of encodings: base64, base64url, netbiosu, or mask; forwarding a subset of the HTTP network business to a cloud security service, wherein the cloud security service automatically determines whether the subset of the HTTP network business is associated with Cobalt Strike Beacon HTTP C2 business activity based on multiple heuristics; and receiving the following response from the cloud security service: the subset of the HTTP network business is associated with Cobalt Strike Beacon HTTP C2 business activity; and performing an action in response to determining that the subset of the HTTP network business is associated with Cobalt Strike Beacon HTTP C2 business activity.

[0045] In some embodiments, the system / process / computer program product for Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection further includes, wherein the cloud security service automatically determines whether a subset of HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity based on multiple heuristics, the heuristics including performing a statistical check of data for behavior-based detection of Cobalt Strike Beacon HTTP C2 traffic activity, the check including checking the timestamps of at least the previous twelve sessions to determine whether this is a Gaussian distribution or a normal distribution.

[0046] Example techniques for Cobalt Strike Beacon HTTPS C2 heuristic detection In some embodiments, a system / process / computer program product for Cobalt Strike Beacon HTTPS C2 heuristic detection includes: monitoring Hypertext Transfer Protocol Secure (HTTPS) network traffic at a firewall; pre-filtering the monitored HTTPS network traffic at the firewall to select a subset of the HTTPS network traffic to forward to a cloud security service; determining whether the subset of the HTTPS network traffic is associated with Cobalt Strike Beacon HTTPS C2 business activity based on multiple heuristics; and performing an action in response to detecting Cobalt Strike Beacon HTTPS C2 business activity.

[0047] In some embodiments, the system / process / computer program product for Cobalt Strike Beacon HTTPS C2 heuristic detection further includes, wherein a quick match table of the detection system stores previously detected Cobalt Strike Beacon HTTPS C2 traffic activity.

[0048] In some embodiments, the system / process / computer program product for Cobalt Strike Beacon HTTPS C2 heuristic detection further includes, wherein a quick match table of the detection system stores triplets of previously detected CobaltStrike Beacon HTTPS C2 business activities, wherein the triplets include a source IP address, a destination IP address, and a destination port.

[0049] In some embodiments, the system / process / computer program product for Cobalt Strike Beacon HTTPS C2 heuristic detection further includes where data statistics based on the automated heuristic analysis of a subset of HTTPS network traffic are stored in a data statistics table of the detection system.

[0050] In some embodiments, the system / process / computer program product for Cobalt Strike Beacon HTTPS C2 heuristic detection further comprises performing validation on the detected Cobalt Strike Beacon HTTPS C2 traffic activity.

[0051] 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 a destination IP address associated with the detected Cobalt Strike Beacon HTTPS C2 traffic activity.

[0052] 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 business activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTPS C2 business activity and using a fingerprint data repository.

[0053] Thus, in accordance with some embodiments, new and improved security solutions are disclosed that facilitate Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection using a security platform (e.g., a firewall (FW) / next-generation firewall (NGFW), a network sensor acting on behalf of a firewall, or another (virtual) appliance / component that can implement security policies using the disclosed techniques (including, for example, Palo Alto Networks' PA Series Next-Generation Firewalls, Palo Alto Networks' VM Series Virtualized Next-Generation Firewalls, and CN Series Container Next-Generation Firewalls and / or other commercially available virtual-based or container-based firewalls that can be similarly implemented and configured to perform the disclosed techniques)).

[0054] These and other embodiments and examples for Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection are further described below.

[0055] Example System Architecture for Cobalt Strike Beacon HTTP / HTTPS C2 Heuristic Detection Thus, in some embodiments, the disclosed technology includes providing a security platform (e.g., security function / platform(s) that can be implemented using a firewall (FW) / next-generation firewall (NGFW), a network sensor acting on behalf of a firewall, or another (virtual) device / component that can implement security policies using the disclosed technology, such as PANOS executed on a virtual / physical NGFW solution commercially available from Palo Alto Networks, or another security platform / NFGW, including, for example, Palo Alto Networks' PA Series Next-Generation Firewalls, Palo Alto Networks' VM Series Virtualized Next-Generation Firewalls, and CN Series Container Next-Generation Firewalls and / or other commercially available virtual-based or container-based firewalls that can be similarly implemented and configured to perform the disclosed technology), the security platform is configured to provide DPI capabilities (e.g., including stateful inspection), such as applying the disclosed technology to automatically detect Cobalt Strike beacon C2 HTTP / HTTPS traffic, as further described below.

[0056] Figure 1 An example of an environment in which malicious applications ("malware") are detected and prevented from causing damage is illustrated. As will be described in more detail below, malware classification (e.g., by security platform 122) may be performed in Figure 1 The various entities included in the illustrated environment are shared and / or complemented in various ways. Also, using the techniques described herein, devices (such as end-client devices 104 to 110) can be protected from such malware (e.g., including previously unknown malware / new variants of malware, such as C2 malware).

[0057] As used herein, "malware" refers to an application that engages in behavior that the user does not approve of / would not approve of if fully informed, whether or not it is done covertly (and whether or not it is illegal). Examples of malware include ransomware, Trojans, viruses, rootkits, spyware, hacker tools, and the like. An example of malware is a desktop / mobile application that encrypts data stored by a user (e.g., ransomware). Another example of malware is C2 malware, such as similarly described above. Other forms of malware (e.g., keyloggers) may also be detected and / or blocked using the disclosed techniques for self-learning malware detection based on sample traffic, as will be further described herein.

[0058] The techniques described herein can be used in conjunction with various platforms (e.g., servers, computers, virtual / container environments, desktops, mobile devices, gaming platforms, embedded systems, etc.) and / or for automated detection of various forms of malware (e.g., new malware and / or variants of malware, such as C2 malware, etc.). Figure 1 In the example environment shown, client devices 104-108 are a laptop computer, a desktop computer, and a tablet computer (respectively) that reside within an enterprise network 140. Client device 110 is a laptop computer that resides outside of enterprise network 140.

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

[0060] Figure 2A An embodiment of a data appliance is shown. In various embodiments, the example shown is a representation of the physical components included in the data appliance 102. Specifically, the data appliance 102 includes a high-performance multi-core central processing unit (CPU) 202 and a random access memory (RAM) 204. The data appliance 102 also includes a storage device 210 (such as one or more hard disks or solid-state storage units). In various embodiments, the data appliance 102 stores (whether in RAM 204, storage device 210 and / or other appropriate locations) information that is used to monitor the enterprise network 140 and implement the disclosed technology. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policies and other configuration information, signatures, host name / URL classification information, malware profiles, and machine learning (ML) models (e.g., such as for sample-based self-learning malware detection, including C2 ML models, 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 cryptography 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.

[0061] The functions described herein as being performed by data appliance 102 may be provided / implemented in a variety of ways. For example, data appliance 102 may be a dedicated device or a collection of devices. The functions provided by data appliance 102 may also be integrated into or executed 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 data appliance 102 are instead (or additionally) provided to a client device (e.g., client device 104 or client device 110) by software executed on the client device.

[0062] 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 collaborate 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 the component may perform the task together with other components. In various embodiments, portions 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 are adapted accordingly. Similarly, additional logical components / features may be included in the embodiments of the data appliance 102 when appropriate. An example of a component included in the data appliance 102 in various embodiments is an application identification engine, which is configured to identify an application (e.g., using various application signatures to identify an application based on packet flow analysis). For example, an application identification engine may determine the type of business involved in a session, such as web browsing-social networking, web browsing-news, SSH, etc.

[0063] Figure 2B is a functional diagram of the logical components of an embodiment of a data appliance. In various embodiments, the examples shown are representations of logical components that may be included in the data appliance 102. Unless otherwise specified, the various logical components of the data appliance 102 may generally be implemented in a variety of ways, including as a collection of one or more scripts (e.g., written in Java, Python, etc., if applicable).

[0064] As shown, the data appliance 102 includes a firewall, and includes a management plane 232 and a data plane 234. The management plane is responsible for managing user interactions, such as by providing a user interface for configuring policies and viewing log data. The data plane is responsible for managing data, such as by performing packet processing and session handling.

[0065] 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. When the flow module 238 identifies a packet as part of a new session, it creates a new session flow. Subsequent packets will be identified as belonging to the session based on the flow lookup. If applicable, SSL decryption is applied by the SSL decryption engine 240. Otherwise, the processing performed by the SSL decryption engine 240 is omitted. The decryption engine 240 can help the data appliance 102 to inspect and control SSL / TLS and SSH encrypted services, thereby helping to prevent threats that may otherwise remain hidden in encrypted services. The decryption engine 240 can also help prevent sensitive content from leaving the enterprise network 140. Decryption can be selectively controlled (e.g., enabled or disabled) based on parameters such as: URL classification, service source, service destination, user, user group, and port. In addition to decryption policies (e.g., specifying which sessions to decrypt), decryption profiles can also be assigned to control various options for policy-controlled sessions. For example, it may be necessary to use a specific cipher suite and encryption protocol version.

[0066] The application identification (APP-ID) engine 242 is configured to determine what type of business the session involves. As an example, the application identification engine 242 can identify a GET request in the received data and conclude that the session requires an HTTP decoder. In some cases, such as a web browsing session, the identified application can change, and such changes will be recorded by the data appliance 102. For example, a user may initially browse to a business Wiki (classified as "Web Browsing - Productivity" based on the URL visited), and then browse to a social networking site (classified as "Web Browsing - Social Networking" based on the URL visited). Different types of protocols have corresponding decoders.

[0067] Based on the determination made by the application identification engine 242, the threat engine 244 sends the packet to the appropriate decoder, which is configured to assemble the packets (which may be received out of order) into the correct order, perform tokenization, and extract the information. The threat engine 244 also performs signature matching to determine what should happen to the packet. The SSL encryption engine 246 can re-encrypt the decrypted data as needed. The forwarding module 248 is used to forward the packet for transmission (e.g., to a destination).

[0068] Also like Figure 2BAs shown, policies 252 are received and stored in the management plane 232. Policies may include one or more rules that may be specified using domains and / or host / server names, and the rules may apply one or more signatures or other matching criteria or heuristics, such as for enforcing security policies on subscriber / IP flows based on various extracted parameters / information from monitored session traffic flows. Example policies may include C2 malware detection policies using disclosed techniques for self-learning malware detection based on sample traffic. An interface (I / F) communicator 250 is provided for management communications (e.g., via (REST) ​​APIs, messaging or network protocol communications, or other communication mechanisms).

[0069] Security Platform Back to Figure 1 , assume that a malicious individual (using system 120) has created malware 130, such as malware for generating Cobalt Strike beacon C2 HTTP / HTTPS traffic using a new / variant profile to avoid detection by pre-existing IPS signatures (e.g., the malware can be delivered to a user's terminal device via a compromised website or through a phishing attack, etc. when the user visits / browses to the compromised website). The malicious individual hopes that a client device (such as client device 104) will execute a copy of the malware 130 to unpack the malware executable / payload, thereby compromising the client device and, for example, causing the client device to become a bot in a botnet. The compromised client device can then be instructed to perform tasks (e.g., cryptocurrency mining or engaging in a denial of service attack) and report information to an external entity (e.g., command and control (C2 / C&C) server 150) and receive instructions from the C2 server 150, if applicable.

[0070] Assume that data appliance 102 has intercepted an email sent (e.g., via system 120) to user "Alice" operating client device 104. In this example, Alice receives the email and clicks on a link to a phishing / compromised website, which may cause Alice's client device 104 to attempt to download malware 130. However, in this example, data appliance 102 may execute the disclosed techniques for self-learning malware detection based on sample traffic and block access to the packaged malware content from Alice's client device 104, thereby preempting and preventing any such downloading of malware 130 to Alice's client device 104. As will be further described below, data appliance 102 executes the disclosed techniques for self-learning malware detection based on sample traffic, such as described further below, to detect and block such malware 130 from compromising Alice's client device 104.

[0071] In various embodiments, the data appliance 102 is configured to work in conjunction with the security platform 122. As an example, the security platform 122 may provide a set of signatures of known malicious files to the data appliance 102 (e.g., as part of a subscription). If the signature of the malware 130 is included in the set (e.g., the MD5 hash value of the malware 130), the data appliance 102 may accordingly prevent the malware 130 from being transmitted to the client device 104 (e.g., by detecting that the MD5 hash value of the email attachment sent to the client device 104 matches the MD5 hash value of the malware 130). The security platform 122 may also provide a list of known malicious domains and / or IP addresses to the data appliance 102, thereby allowing the data appliance 102 to block traffic between the enterprise network 140 and the C2 server 150 (e.g., in the case where the C&C server 150 is known to be malicious). The list of malicious domains (and / or IP addresses) may also help the data appliance 102 determine when one of its nodes has been compromised. For example, if a client device 104 attempts to contact a C2 server 150, such an attempt is a strong indication that the client 104 has been compromised by malware (and remedial action should be taken accordingly, such as isolating the client device 104 from communicating with other nodes within the enterprise network 140).

[0072] As will be described in more detail below, the security platform 122 can also receive a copy of the malware 130 from the data appliance 102 to perform cloud-based security analysis for performing self-learning malware detection based on sample transactions, and the malware determination can be sent back to the data appliance 102 for use in implementing security policies to protect Alice's client device 104 from execution of the malware 130 (e.g., preventing the malware 130 from accessing the client device 104).

[0073] Further, the security platform 122 may also provide other types of information to the data appliance 102 (e.g., as part of a subscription), such as a collection of information for performing the disclosed techniques for self-learning malware detection based on sample traffic, which the data appliance 102 may use to perform inline analysis of such malware files, as further described below.

[0074] In various embodiments, if the signature of the attachment is not found, the data appliance 102 can take various actions. As a first example, the data appliance 102 can achieve 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). The disadvantage of this approach is that there may be many legitimate attachments that are unnecessarily blocked as potential malware, when they are actually benign. As a second example, the data appliance 102 can cause a fail-danger 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). The disadvantage of this approach is that it will not be possible to prevent newly created malware (not previously seen by the platform 122) from causing damage. As a third example, the data appliance 102 can be 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 otherwise classify it.

[0075] The security platform 122 stores a copy of the received sample in a storage device 142 and starts (or schedules, if applicable) analysis. An example of a storage device 142 is an Apache Hadoop cluster (HDFS). The results of the analysis (and additional information about the application) are stored in a database 146. In the event that the application is determined to be malicious, the data appliance can be configured to automatically block file downloads based on the analysis results. Further, a signature can be generated for the malware and distributed (e.g., to data appliances, such as data appliances 102, 136, and 148) to automatically block future file transfer requests to download files determined to be malicious.

[0076] In various embodiments, the security platform 122 includes one or more dedicated commercially available hardware servers (e.g., with (multiple) multi-core processors, 32G+ of RAM, (multiple) Gigabit network interface adapters, and (multiple) hard drives) that run typical server-class operating systems (e.g., Linux). The security platform 122 can be implemented across a scalable infrastructure that includes multiple such servers, solid-state drives, and / or other applicable high-performance hardware. The security platform 122 can include multiple distributed components, including components provided by one or more third parties. For example, part or all of the security platform 122 can be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). Further, as with the data appliance 102, whenever the security platform 122 is referred to as performing a task (such as storing data or processing data), it should be understood that a subcomponent or multiple subcomponents of the security platform 122 (whether alone or in cooperation with third-party components) can cooperate to perform the task. As an example, the security platform 122 can optionally perform static / dynamic analysis in cooperation with one or more virtual machine (VM) servers (such as VM server 124).

[0077] An example of a virtual machine server is a physical machine that includes commercially available server-class hardware (e.g., a multi-core processor, 32+ gigabytes of RAM, and one or more gigabit network interface adapters) that runs commercially available virtualization software, such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the virtual machine server is omitted. Further, the virtual machine server can be under the control of the same entity that manages the security platform 122, but can also be provided by a third party. As an example, the virtual machine server can rely on EC2, where the rest of the security platform 122 is provided by dedicated hardware owned by and under the control of the operator of the security platform 122. The VM server 124 is configured to provide one or more virtual machines 126-128 for emulating client devices. The virtual machines can execute various operating systems and / or versions thereof. The observed behavior resulting from the execution of applications in the virtual machines is logged and analyzed (e.g., for indications that the applications are 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 in part by other components of the security platform 122 , such as the orchestrator 144 .

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

[0079] In various embodiments, security platform 122 is configured to provide security services to various entities in addition to (or in lieu of, if applicable, the operator of data appliance 102). For example, other enterprises with their own respective enterprise networks 114 and 116 and their own respective data appliances 136 and 148 may contract with the operator of security platform 122. Other types of entities may also use the services of security platform 122. For example, an Internet service provider (ISP) that provides Internet service to client device 110 may contract with security platform 122 to analyze applications that client device 110 attempts to download. As another example, an owner of client device 110 may install software on client device 110 that communicates with security platform 122 (e.g., to receive content packages from security platform 122, use the received content packages to check attachments according to the techniques described herein, and transmit applications to security platform 122 for analysis).

[0080] Analyze samples using static / dynamic analysis Figure 3An example of logical components that may be included in a system for analyzing a sample is illustrated. Analysis system 300 may be implemented using a single device. For example, the functionality of analysis system 300 may be implemented in a malware analysis module 112 incorporated into data appliance 102. Analysis system 300 may also be implemented across multiple different devices. For example, the functionality of analysis system 300 may be provided by security platform 122.

[0081] In various embodiments, the analysis system 300 may use a list, database, or other collection of known safe content and / or known objectionable content (in Figure 3 The information included in set 314 is collectively shown as set 314 in the figure. Set 314 can be obtained in a variety of ways, including via a subscription service (e.g., provided by a third party) and / or as a result of other processing (e.g., processing performed by data appliance 102 and / or security platform 122). Examples of information included in set 314 are: 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, hash values, and / or other identifiers of known malicious applications; signatures, hash values, and / or other identifiers of known secure applications; signatures, hash values, and / or other identifiers of known malicious files (e.g., OS exploit files); signatures, hash values, and / or other identifiers of known secure libraries; and signatures, hash values, and / or other identifiers of known malicious libraries.

[0082] In various embodiments, when a new sample is received for analysis (e.g., an existing signature associated with the sample does not exist in the analysis system 300), it is added to the queue 302. Figure 3 As shown, application 130 is received by system 300 and added to queue 302 .

[0083] Coordinator 304 monitors queue 302, and when resources (e.g., static analysis workers) become available, coordinator 304 obtains samples from queue 302 for processing (e.g., obtaining a copy of malware 130). In particular, coordinator 304 first provides samples to static analysis engine 306 for static analysis. In some embodiments, one or more static analysis engines are included in analysis system 300, where analysis system 300 is a single device. In other embodiments, static analysis is performed by a separate static analysis server that includes multiple workers (i.e., multiple instances of static analysis engine 306).

[0084] The static analysis engine obtains general information about the sample and includes it (as well as heuristics and other information, if applicable) in a static analysis report 308. The report can be created by the static analysis engine or the coordinator 304 (or another appropriate component), which can be configured to receive information from the static analysis engine 306. As an example, static analysis of malware can include performing a signature-based analysis. In some embodiments, instead of creating a separate static analysis report 308 or in addition to creating a separate static analysis report 308 (i.e., a portion of the database record from the report 308), the collected information is stored in a database record for the sample (e.g., in a database 316). In some embodiments, the static analysis engine also forms a verdict about the application (e.g., "safe", "suspicious", or "malicious"). As an example, the verdict can be "malicious" even if there is a "malicious" static feature in the application (e.g., the application includes a hard link to a known malicious domain). As another example, points can be assigned to each feature (e.g., based on severity if found; based on the reliability of the feature for predicting malicious behavior; etc.), and a verdict can be assigned by the static analysis engine 306 (or the coordinator 304, if applicable) based on the number of points associated with the static analysis results.

[0085] Once the static analysis is complete, the coordinator 304 locates an available dynamic analysis engine 310 to perform dynamic analysis on the application. As with 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 that includes multiple workers (i.e., multiple instances of the dynamic analysis engine 310).

[0086] Each dynamic analysis worker manages a virtual machine instance (e.g., for emulation / sandbox analysis of samples for malware detection, such as the C2 malware detection based on monitored network traffic activity described above). In some embodiments, the results of the static analysis (e.g., performed by the static analysis engine 306), whether in report form (308) and / or stored in a database 316 or otherwise, are provided as input to the dynamic analysis engine 310. For example, the static report information can be used to help select / customize the virtual machine instance used by the dynamic analysis engine 310 (e.g., Microsoft Windows 7 SP 2 vs. Microsoft Windows 10 Enterprise, or iOS 11.0 vs. iOS 12.0). In the case of multiple virtual machine instances executing simultaneously, a single dynamic analysis engine can manage all instances, or multiple dynamic analysis engines (e.g., each of which manages its own virtual machine instance) can be used, if applicable. As explained in more detail below, during the dynamic portion of the analysis, the actions taken by the application (including network activity) are analyzed.

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

[0088] The environment used by the analysis system 300 is instrumented / hooked so that behaviors observed when executing the application are logged as they occur (e.g., using a custom kernel that supports hooks and logcat). Network traffic associated with the emulator is also captured (e.g., using pcap). The log / network data can be stored as temporary files on the analysis system 300, and can also be stored more permanently (e.g., using HDFS or other appropriate storage technology or combination of technologies, such as MongoDB). The dynamic analysis engine (or another appropriate component) can compare the sample's connections to a list of domains, IP addresses, etc. (314) and determine whether the sample has communicated (or attempted to communicate) with a malicious entity.

[0089] As with the static analysis engine, the dynamic analysis engine stores the results of its analysis in database 316 in a record associated with the application being tested (and / or includes the results in report 312, if applicable). In some embodiments, the dynamic analysis engine also forms a verdict (e.g., "safe," "suspicious," or "malicious") about the application. As an example, a verdict may be "malicious" even if the application takes a "malicious" action (e.g., an attempt to contact a known malicious domain or an attempt to leak sensitive information is observed). As another example, points may be assigned to the action taken (e.g., based on severity (if found); based on the reliability of the action for predicting maliciousness; etc.), and a verdict may be assigned by dynamic analysis engine 310 (or coordinator 304, if applicable) based on the number of points associated with the dynamic analysis results. In some embodiments, the final verdict associated with the sample is made (e.g., by coordinator 304) based on a combination of report 308 and report 312.

[0090] Heuristic Detection Figure 4A Portions of an example embodiment of a detection system and quality check system for processing network traffic to perform Cobalt Strike Beacon C2 HTTP traffic detection according to some embodiments are illustrated. As similarly discussed above, in various embodiments, the security platform 122 includes a Cobalt Strike Beacon (CSB) detector 154. Figure 4A Subcomponents of the CSB detector 154 are illustrated, including the following subcomponents: a detection system 402 and a quality inspection system 404 .

[0091] refer to Figure 4A The behavioral-based and cross-session detection solution for performing Cobalt Strike beacon C2 HTTP traffic detection is to use a cloud-based security service (e.g. Figure 1 The cloud security service 122 shown in the figure is executed in cooperation with a data appliance (eg, a data appliance implementing a firewall, hereinafter also referred to as a firewall) 102. The behavior-based detection solution performs cross-session inspection and includes three components, as will be described below.

[0092] Firewall 102 monitors network traffic on the enterprise network (e.g., including HTTP traffic on enterprise network 140, such as Figure 1As shown at 410, the firewall 102 monitors the network traffic using the data plane and performs a pre-filtering analysis of the network traffic using an HTTP pre-filtering module (e.g., a subcomponent). As shown at 412, if the following pre-filtering analysis of the HTTP traffic is a hit (i.e., meets two of the following example criteria based on header length and header encoding format, which are selected to reduce the volume of traffic to be forwarded to Cloud Security 122 for further analysis to detect potential Cobalt StrikeBeacon C2 traffic, such as will be further described below), the firewall 102 forwards the traffic (e.g., a packet capture (pcap) file of the network traffic associated with (multiple) sessions) to the detection system. First, the HTTP pre-filtering module determines whether the network traffic includes a header value or URI length check that matches a range of 171 bytes to 256 bytes. Second, the HTTP pre-filtering module determines whether the network traffic includes an encoded header value or URI length field that matches one of these types of encodings: base64, base64url, netbios, netbiosu, or mask. Based on experiments (eg, test results), pre-filtering reduces the amount of network traffic forwarded by the cloud security service for further analysis to only approximately 0.32% of the total network traffic.

[0093] The Cobalt Strike Beacon (CSB) detector 154 includes a detection system 402 that includes an HTTP logic inspection module (e.g., a subcomponent that can be implemented using 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 data statistics associated with each new session. As an initial logic check, the detection system 402 can determine whether there is a previous ruling stored in the quick match table, and if there is a match based on the triple of SrcIP, DstIP, and DstPort, the previous ruling is returned to the firewall 102 without further analysis / processing by the detection system 402.

[0094] Otherwise, processing continues to perform the following data statistics checks stored in the data statistics table, as shown at 414. The following data statistics checks are performed for each session and are stored in the data statistics table for use in performing behavior-based detection of CobaltStrike Beacon C2 HTTP traffic (e.g., using heuristic-based techniques, as will now be further described). In an example implementation, the quick match table and the data statistics table can be implemented using a data structure repository in memory, such as using an open source (e.g., Redis publicly available at https: / / redis.io / ) or commercially available data storage solution.

[0095] First, the timestamps of the first twelve (12) sessions are checked to determine whether this is a Gaussian distribution or a normal distribution. In an example implementation, the Gaussian distribution or normal distribution calculation 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 specifically, the timestamps from the first twelve (12) sessions are checked to see if they are normally distributed. 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 time of the timestamp difference (TSdiff) from 6 seconds to 556 seconds for the twelve (12) sessions (e.g., 6 / 10-556 / 10, 1 second to 55 seconds per session, in this example implementation, we choose 40 seconds to perform this connection count distribution calculation).

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

[0097] Third, check if the MD5 hash of the HTTP header is the same (e.g., metadata, including cookies associated with the session(s), is the same for each compromised machine, which results in the MD5 of the HTTP header being the same for each session, resulting in new communications to its C2 team server).

[0098] Fourth, check whether the HTTP header field number (ie, the number of fields included in the HTTP header) is less than 10 fields in the HTTP header (eg, due to a design limitation resulting from the design implementation of the Cobalt Strike Beacon toolkit).

[0099] Fifth, check whether the HTTP header does not include the custom header.

[0100] Sixth, check whether the HTTP User Agent (UA) is a popular UA (e.g., is a known / popular UA; an example list of popular UAs is publicly available at https: / / www.whatismybrowser.com / guides / the-latest-user-agent / ). Cobalt Strike Beacon C2 traffic is often associated with the use of known / popular UAs because such HTTP network traffic attempts to emulate typical user traffic associated with such known / popular UAs (e.g., commonly used web browsers such as Microsoft IE, Chrome, Mozilla, etc.).

[0101] Based on the above heuristics, if these logical checks result in a match, then the network traffic for such session is determined to be associated with Cobalt Strike Beacon C2 HTTP traffic. If there is no match, then the network traffic for such session is determined not to be associated with Cobalt Strike Beacon C2 HTTP traffic. The ruling is stored in the quick match table, as shown at 416. Specifically, after the ruling is determined using the detection system as described above, the triple (e.g., SrcIP, DstIP, Dstport) is added to the quick match table along with the ruling. Therefore, the detection system will query the quick match table for subsequent sessions, as similarly described above, in order to more efficiently determine the ruling for the previously analyzed HTTP traffic.

[0102] At 418, the quality check system 404 performs validation on the results of the detection system 402 to determine whether any previous verdicts on the CobaltStrike Beacon C2 HTTP traffic were false positives or false negatives. Specifically, the destination (Dest) IP detection and verification module (e.g., a subcomponent) performs automatic detection 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 at 420, the DestIP detection and verification module then determines whether the response includes a fingerprint associated with Cobalt Strike (e.g., the HTTP response data includes the default credentials provided by Cobalt Strike and / or the HTTP response matches the fingerprint of Cobalt Strike (CS); in an example implementation, the CS fingerprint is a predetermined string included in the response traffic from the CS team server, for example, when the client sends an HTTP request with a randomized URL to the CS team server, the team server will respond with an HTTP status code of 404 and the following example header Content-Type: text / plain\r\nDate: Wed, 27Feb2019 14:43:19GMT\r\nContent-Length: 0, therefore, we can use "Content-Type: text / plain" and Content-Length: 0 as a fingerprint to identify the CS team server, such as further described below with respect to various embodiments, to verify the Cobalt Strike Beacon for network traffic / sessions communicating with the destination IP address C2HTTP Traffic (CS) Verdict. As an 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 that was previously identified as Cobalt Strike Beacon-related malware based on previous malware analysis), and if so, the Cobalt Strike Beacon C2 HTTP Traffic (C2) verdict can be verified. Otherwise, the verdict is automatically changed from a CS verdict to a benign verdict (e.g., providing a feedback loop to improve the CS detection heuristics implemented in the detection system 402). Thus, the quality check system can verify the verdict in an attempt to detect any false positives or false negatives for Cobalt Strike Beacon C2 HTTP traffic.

[0103] The disclosed techniques for performing behavior-based and cross-session detection solutions for Cobalt Strike Beacon C2 HTTP traffic detection facilitate a 90% detection improvement rate for Cobalt Strike Beacon C2 HTTP traffic detection based on experimental / testing results, compared to pre-existing IPS signature-based approaches (e.g., default / known profiles for Cobalt Strike Beacon C2 HTTP traffic).

[0104] Heuristic Detection Figure 4B Portions of an example embodiment of a detection system and quality inspection system for processing network traffic to perform Cobalt Strike BeaconC2 HTTPS traffic detection according to some embodiments are illustrated. Figure 4A Similarly discussed, the security platform 122 includes a Cobalt Strike Beacon (CSB) detector 154 . Figure 4B The subcomponents of the CSB detector 154 are similarly illustrated, including the following subcomponents: a detection system 402 and a quality inspection system 404. However, as further described below, the HTTPS pre-filtering logic module / subcomponent and the HTTPS logic inspection module / subcomponent perform different pre-filtering and logic inspections on HTTPS traffic (e.g., because the HTTPS traffic headers / content are encrypted, different heuristics for automatically detecting Cobalt Strike beacon C2 HTTPS traffic are disclosed, as will be further described below).

[0105] refer to Figure 4B The behavioral-based and cross-session detection solution for performing Cobalt Strike beacon C2 HTTPS traffic detection is to use a cloud-based security service (e.g. Figure 1 The cloud security service 122 shown is executed in conjunction with the firewall 102. The behavior-based detection solution performs cross-session inspection and includes three components, as will be described below.

[0106] Firewall 102 monitors network traffic on the enterprise network (e.g., including HTTP traffic on enterprise network 140, such as Figure 1As shown at 410, the firewall 102 monitors the network traffic using the data plane and performs a pre-filtering analysis of the network traffic using an HTTPS pre-filtering module (e.g., a subcomponent). As shown at 412, if the following pre-filtering analysis of the HTTP traffic is a hit (i.e., meets two of the following example 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, so this pre-filtering is used before further analysis performed using the detection system described below, which will check further heuristics), the criteria is selected to reduce the volume of traffic to be forwarded to cloud security 122 for further analysis to detect potential Cobalt Strike Beacon C2 traffic, such as will be further described below), then the firewall 102 forwards the traffic (a packet capture (pcap) file of the network traffic associated with the (multiple) sessions) to the detection system 402. Specifically, the pre-filtering module determines whether the Server hello random field value includes a "DOWNGRD" value. Based on experiments (eg, test results), pre-filtering reduces the amount of network traffic forwarded by the cloud security service for further analysis to only about 0.002% of the total network traffic.

[0107] The Cobalt Strike Beacon (CSB) detector 154 includes a detection system 402 that includes an HTTPS logic inspection module (e.g., a subcomponent that can be implemented using 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 data statistics associated with each new session. As an initial logic check, the detection system 402 can determine whether there is a previous ruling stored in the quick match table, and if there is a match based on the triple of SrcIP, DstIP, and DstPort, the previous ruling is returned to the firewall 102 without further analysis / processing by the detection system 402.

[0108] Otherwise, processing continues to perform the following data statistics checks stored in the data statistics table, as shown at 414. The following data statistics checks are performed for each session and are stored in the data statistics table for use in performing behavior-based detection of CobaltStrike Beacon C2 HTTP traffic (e.g., using heuristic-based techniques, as will now be further described). In an example implementation, the quick match table and the data statistics table can be implemented using a data structure repository in memory, such as using an open source (e.g., Redis publicly available at https: / / redis.io / ) or commercially available data storage solution.

[0109] First, the timestamps of the first twelve (12) sessions are checked to determine whether this is a Gaussian distribution or a normal distribution. In an example implementation, the Gaussian distribution or normal distribution calculation 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 specifically, the timestamps of the first twelve (12) sessions are checked to see if they are normally distributed. 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 based on the time of the timestamp difference (TSdiff) of the twelve (12) sessions from 6 seconds to 556 seconds (e.g., 6 / 10-556 / 10, 1 second to 55 seconds per session, in this example implementation, we choose 40 seconds to perform this connection count distribution calculation).

[0110] Second, the application data packet length from the HTTPS request is checked to determine if it is the same. If the application data packet length from the HTTPS request from each of the 12 sessions is the same length, this is another heuristic that serves as another indicator that this may be associated with Cobalt Strike beacon C2 HTTPS traffic.

[0111] Third, we check if there is only one application requesting data in the request direction, and if so, this is another heuristic that serves as another indicator that this may be associated with Cobalt Strike beacon C2 HTTPS traffic.

[0112] Based on the above heuristics, if these logical checks result in a match, then the network traffic for such session is determined to be associated with Cobalt Strike Beacon C2 HTTP traffic. If there is no match, then the network traffic for such session is determined not to be associated with Cobalt Strike Beacon C2 HTTP traffic. The ruling is stored in the quick match table, as shown at 416. Specifically, after the ruling is determined using the detection system as described above, the triple (e.g., SrcIP, DstIP, Dstport) is added to the quick match table along with the ruling. Therefore, the detection system will query the quick match table for subsequent sessions, as similarly described above, in order to more efficiently determine the ruling for the previously analyzed HTTP traffic.

[0113] At 418, the quality check system 404 performs validation on the results of the detection system 402 to determine whether any previous verdicts on CobaltStrike Beacon C2 HTTPS traffic are false positives or false negatives. Specifically, the destination (Dest) IP detection and verification module (e.g., a subcomponent) performs automatic detection 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 at 420, the DestIP detection and verification module then determines whether the response includes a fingerprint associated with Cobalt Strike (e.g., the HTTPS response data includes the default credentials provided by Cobalt Strike and / or the HTTP response matches the fingerprint of Cobalt Strike (CS); in an example implementation, the CS fingerprint is a predetermined string included in the response traffic from the CS team server, for example, when a client sends an HTTPS request with client hello to the CS team server, the team server will respond to the client with Server hello and server credentials, and by default, the credentials include the CS keyword "Major Cobalt Strike", therefore, we can use the credential keyword "Major Cobalt Strike" as a fingerprint to identify the CS team server, such as further described below with respect to various embodiments, to verify the Cobalt Strike Beacon C2 HTTPS traffic (CS) ruling for the network traffic / session communicated with the destination IP address. As an example, the quality check system can perform a malware IP address lookup to determine whether the DestIP is malware associated with Cobalt Strike Beacon (e.g., previously identified as Cobalt based on previous malware analysis). Strike Beacon-related malware) and, if so, the Cobalt Strike Beacon C2 HTTPS traffic (C2) verdict can be verified. Otherwise, the verdict is automatically changed from a CS verdict to a benign verdict (e.g., providing a feedback loop to improve the CS detection heuristics implemented in the detection system 402). Thus, the quality check system can verify the verdict in an attempt to detect any false positives or false negatives for the Cobalt Strike Beacon C2 HTTPS traffic.

[0114] The disclosed techniques for performing behavior-based and cross-session detection solutions for Cobalt Strike Beacon C2 HTTPS traffic detection facilitate a 90% detection improvement rate for Cobalt Strike Beacon C2 HTTPS traffic detection based on experimental / testing results, compared to pre-existing IPS signature-based approaches (e.g., default / known profiles for Cobalt Strike Beacon C2 HTTPS traffic).

[0115] Example use case for heuristic detection Figure 5A Illustrated are example properties associated with Cobalt Strike Beacon HTTP traffic for heuristic detection in accordance with some embodiments. Figure 5A , the example network service illustrates the same HTTP request header MD5 hash value as the request URL shown at 502 and the cookie shown at 504 (e.g., encoded base64) associated with the session of such Cobalt Strike Beacon HTTP service. Thus, this example illustrates that the above requirements for Figure 4A The network traffic is similarly described for the pre-filtering rules. First, the header value or URI length check matches the range of 171 bytes 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: base64, base64url, netbios, netbiosu, or mask. Therefore, the network traffic shown at 506 is forwarded to cloud security 122 for further analysis using CSB detector 154, as described above with respect to Figure 4A Similar to what is described.

[0116] Figure 5B Figure 1 illustrates additional example properties associated with Cobalt Strike Beacon HTTP traffic for heuristic detection in accordance with some embodiments. Figure 5B, the example network traffic illustrates HTTP request header fields associated with a Cobalt Strike (CS) HTTP request (as shown at 520) having fewer than 10 request header fields (i.e., only six (6) request header fields in this example) compared to a benign HTTP request (as shown at 522) having a greater number of HTTP request header fields (i.e., greater than 10 request header fields). Thus, the example network traffic shown at 520 satisfies the fourth heuristic described above with respect 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 described above with respect to Figure 4A Similar to what is described.

[0117] Figure 5C Figure 1 illustrates additional example properties associated with Cobalt Strike Beacon HTTP traffic for heuristic detection in accordance with some embodiments. Figure 5C , the example network traffic illustrates that the HTTP user agent (UA) is a known UA and has no custom headers, as shown at 530. Therefore, the example network traffic shown at 530 satisfies the sixth heuristic described above regarding whether the HTTP user agent (UA) is a known / popular UA, as described above with respect to Figure 4A Similar to what is described.

[0118] Figure 5D Figure 1 illustrates additional example properties associated with Cobalt Strike Beacon HTTP traffic for heuristic detection in accordance with some embodiments. Figure 5D , the example network service illustrates the HTTP request header content without the custom header, as shown at 540. Therefore, the example network service shown at 540 satisfies the above fifth heuristic related to whether HTTP does not include a custom header, as described above with respect to Figure 4A Similar to what is described.

[0119] Example use case for heuristic detection Figure 5E FIG. 4 illustrates additional example properties associated with the Cobalt Strike Beacon HTTPS service for heuristic detection according to some embodiments. Figure 5E , as shown at 550, this example network service illustrates an HTTPS request, wherein the Server hello random field value includes a "DOWNGRD" value, as described above with respect to Figure 4B Thus, the network traffic shown at 506 is forwarded to cloud security 122 for further analysis using CSB detector 154, as described above with respect to Figure 4BSimilar to what is described.

[0120] Fig. 5F FIG. 4 illustrates additional example properties associated with the Cobalt Strike Beacon HTTPS service for heuristic detection according to some embodiments. Fig. 5F , as shown at 560, this example network service illustrates the amount of SSL application data in the request direction, as described above with respect to Figure 4B Specifically, as described above Figure 4B Similarly described, the second check performed by the HTTPS logic module is to determine if the application data packet lengths from the HTTPS requests are the same. If the application data packet lengths from the HTTPS requests from each of the 12 sessions are the same length, as shown at 560 (e.g., 1365 bytes), this is another heuristic that serves as another indicator that this may be associated with Cobalt Strike beacon C2 HTTPS traffic.

[0121] Figure 5G FIG. 4 illustrates additional example properties associated with the Cobalt Strike Beacon HTTPS service for heuristic detection according to some embodiments. Figure 5G , as shown at 570, this example network service illustrates the amount of SSL application data in the request direction, as described above with respect to Figure 4B Specifically, as described above Figure 4B Similarly described, the third check performed by the HTTPS logic module is to determine whether there is only one application request data (e.g., 459 bytes in length) in the request direction (e.g., a heuristic performed on each of the (12) sessions analyzed), which is another heuristic that serves as another indicator that this may be associated with Cobalt Strike beaconC2HTTPS traffic.

[0122] Additional example procedures for the disclosed techniques for Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection will now be described.

[0123] Example procedure for Cobalt Strike Beacon HTTP C2 heuristic detection Figure 6 is a flow chart of a process for Cobalt Strike Beacon HTTP C2 heuristic detection according to some embodiments. In some embodiments, Figure 6The illustrated process 600 is performed by a security platform and techniques similar to those described above, including the security platform and techniques described above with respect to Figures 1 to 5G In one embodiment, process 600 is performed by Figure 1 The data device 102 described above Figure 1 The described security platform 122 (e.g., as a cloud-based security service), a virtual appliance (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 may be similarly implemented and configured to perform the disclosed techniques), an SDN security solution, a cloud security solution, and / or a combination or hybrid implementation of the foregoing described herein.

[0124] At 602, HTTP network traffic is monitored at a firewall. For example, the firewall may detect HTTP traffic using application identifiers, such as described above with respect to Figure 1 and Figure 4A Similar to what is described.

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

[0126] At 606, a determination is performed based on a plurality of heuristics to determine whether a subset of HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity. For example, the HTTP logic inspection module may perform further heuristic analysis on the HTTP network traffic to automatically detect Cobalt Strike Beacon HTTP C2 traffic, such as described above with respect to Figure 4A and FIG. 5A to FIG. 5D Similar to what is described.

[0127] At 608, an action is performed in response to detecting Cobalt Strike Beacon HTTP C2 traffic activity. The security platform (122) and the data appliance (102) can then, in response to the malware verdict, perform an action based on a policy (e.g., a security / C2-related malware policy, which can be stored in the Figure 2BThe data appliance may be configured to block Cobalt Strike Beacon HTTP C2 business activities. Other example actions may include: blocking access to a destination IP address associated with detected Cobalt Strike Beacon HTTP C2 business activities; blocking / discarding network services associated with detected Cobalt Strike Beacon HTTP C2 business activities and / or associated with a destination IP address; alerting end users and / or network / security administrators that a terminal is associated with detected Cobalt Strike Beacon HTTP C2 business activities; isolating end devices associated with detected Cobalt Strike Beacon HTTP C2 business activities; identifying a destination IP address, URL, etc. associated with detected Cobalt Strike Beacon HTTP C2 business activities as malicious (or potentially malicious); and / or various other actions may also be performed based on policies.

[0128] Example procedure for Cobalt Strike Beacon HTTPS C2 heuristic detection Figure 7 is a flow chart of a process for Cobalt Strike Beacon HTTPS C2 heuristic detection according to some embodiments. In some embodiments, Figure 7 The illustrated process 700 is performed by a security platform and techniques similar to those described above, including the security platform and techniques described above with respect to Figures 1 to 5G In one embodiment, process 700 is performed by Figure 1 The data device 102 described above Figure 1 The described security platform 122 (e.g., as a cloud-based security service), a virtual appliance (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 may be similarly implemented and configured to perform the disclosed techniques), an SDN security solution, a cloud security solution, and / or a combination or hybrid implementation of the foregoing described herein.

[0129] At 702, HTTPS network traffic is monitored at the firewall. For example, the firewall may detect HTTPS traffic using application identification, such as described above with respect to Figure 1 and Figure 4B Similar to what is described.

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

[0131] At 706, a determination based on a plurality of heuristics is performed to determine whether a subset of HTTPS network traffic is associated with CobaltStrike Beacon HTTPS C2 traffic activity. For example, the HTTPS logic inspection module may perform further heuristic analysis on the HTTPS network traffic to automatically detect CobaltStrike Beacon HTTPS C2 traffic, such as described above with respect to Figure 4B and Figure 5E to Figure 5G Similar to what is described.

[0132] At 708, an action is performed in response to detecting Cobalt Strike Beacon HTTPS C2 traffic activity. The security platform (122) and the data appliance (102) can then respond to the malware verdict based on a policy (e.g., a security / C2-related malware policy, which can be stored in Figure 2B The data appliance may be configured to block Cobalt Strike Beacon HTTPS C2 business activities. Other example actions may include: blocking access to a destination IP address associated with detected Cobalt Strike Beacon HTTPS C2 business activities; blocking / discarding network services associated with detected Cobalt Strike Beacon HTTPS C2 business activities and / or associated with a destination IP address; alerting end users and / or network / security administrators that a terminal is associated with detected Cobalt Strike Beacon HTTPS C2 business activities; isolating end devices associated with detected Cobalt Strike Beacon HTTPSC2 business activities; identifying a destination IP address, URL, etc. associated with detected Cobalt Strike Beacon HTTPS C2 business activities as malicious (or potentially malicious); and / or various other actions may also be performed based on policies.

[0133] Probe for COBALT STRIKE team server detection Another technical challenge is to verify that the target IP address (e.g., extracted based on the above techniques) hosts the CobaltStrike team server.

[0134] Thus, 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 an IP address to detect whether the IP address hosts a Cobalt Strike team server based on responses to the active probing (e.g., packets sent from the target IP address in response to the probing packets).

[0135] 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 at a firewall; pre-filtering the monitored HTTP, HTTPS, and / or DNS network traffic at the firewall to select a subset of the HTTP, HTTPS, and / or DNS network traffic to forward 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 performing an action in response to detecting that the target is a Cobalt Strike team server.

[0136] In some embodiments, the system / process / computer program product for probing for Cobalt Strike team server detection further comprises: detection of the Cobalt Strike team server verifies malware determinations of Cobalt StrikeBeacon HTTP, HTTPS, and / or DNS C2 service activity.

[0137] In some embodiments, the system / process / computer program product for detection of a Cobalt Strike team server further comprises a quick match table of the detection system storing triplets of previously detected Cobalt StrikeBeacon HTTP, HTTPS and / or DNS C2 business activities, wherein the triplets include a source IP address, a destination IP address, and a destination port.

[0138] In some embodiments, the system / process / computer program product for detection of a Cobalt Strike team server further comprises storing data statistics based on automated heuristic analysis of a subset of HTTP, HTTPS, and / or DNS network traffic in a data statistics table of the detection system.

[0139] In some embodiments, the system / process / computer program product for probing for Cobalt Strike team server detection further comprises performing verification of Cobalt Strike Beacon HTTP, HTTPS, and / or DNS traffic activity based on active probing.

[0140] In some embodiments, the 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 business activity based on active probing of destination IP addresses associated with the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 business activity.

[0141] In some embodiments, the 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 business activity based on active probing of destination IP addresses associated with the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 business activity and using a fingerprint data repository.

[0142] As mentioned above Figure 4A and Figure 4B Similarly described, the destination IP detection and verification component / module of the quality check system 404 performs active probing (e.g., via HTTP or HTTPS) on the IP address to detect whether the IP address hosts a Cobalt Strike team server based on a response to the active probing (e.g., a packet originating 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 a variety of network protocols (e.g., HTTP, HTTPS, and / or DNS).

[0143] Typically, the destination IP detection and verification module extracts the destination (dst) IP address (dst IP) and port number (port) information from the network traffic that is forwarded / collected from the firewall that monitors the network traffic, as described above with respect to Figure 4A and Figure 4BNext, the destination IP detection and verification module sends a crafted request (e.g., a crafted HTTP / HTTPS / DNS request) to the dst IP and port (e.g., the target). The destination IP detection and verification module then checks / evaluates the response(s) received from the target. If the response content matches the predetermined fingerprint and detection logic, the dst IP, port, and malicious verdict are inserted into a quick match table (e.g., the quick match table of the detection system 402, as described above with respect to Figure 4A and Figure 4B Otherwise (i.e., does not match the predetermined fingerprint and detection logic), the dst IP, port, and benign verdict are inserted into the quick match table.

[0144] HTTP / HTTPS probe for Cobalt Strike team server detection An example implementation of HTTP / HTTPS active probing for Cobalt Strike team server detection will now be described. As an initial pre-check operation of the detection logic, the destination IP detection and verification module sends a carefully crafted pre-check HTTP / HTTPS request to the dst IP and port (e.g., the target). An example carefully crafted pre-check HTTP / HTTPS request is as follows: http[s]: / / [IP]:[Port] / index.html. The destination IP detection and verification module then checks / evaluates the response to the carefully crafted pre-check HTTP / HTTPS request. Specifically, if the following content is received from the target's response, it is considered suspicious (e.g., it can (probably) be a Cobalt Strike team server), and further active detection and evaluation will be performed. More specifically, the response includes a status code equal to 404, and the HTTP / HTTPS header includes the following fields and values: 'Date' and date value (e.g., 'Wednesday, February 9, 2022 23:09:48 GMT'), 'Content-Type': 'text / plain', and 'Content-Length': '0'. Otherwise (e.g., those fields and values ​​are not present in the target's response), then the target is determined not to be a Cobalt Strike team server, and further active probing and assessment will be performed, and the verdict will be determined to be benign (and the quick match table may be updated, as described above with respect to Figure 4A and Figure 4B similarly described).

[0145] As the last pre-check operation of the HTTP / HTTPS detection logic, the destination IP detection and verification module sends a crafted HTTP / HTTPS request to the target to download the beacon file. The example crafted 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 meet the following checksum requirements: The 4-byte URL checksum value is equal to 92 or 93 based on the platform, such as using Figure 8 Checksum algorithm shown, where the input string literal is a 4-byte URL value. Figure 8 Illustrated is a checksum algorithm for the detection logic for HTTP / HTTPS Cobalt Strike team server detection in accordance with certain embodiments. The destination IP detection and verification module then checks / evaluates the response to the crafted final 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 is greater than 200k and less than 300k, and the HTTP / HTTPS body is the first two words equal to 0xFC48 or 0xFCe8 (e.g., based on heuristic analysis of Cobalt Strike team server behavior and the content of its beacon file, such content is present in the Cobalt Strike shared code for the beacon file). Otherwise (e.g., the response does not match the above criteria), and therefore, it is determined that the target is not a Cobalt Strike team server, and further active detection and evaluation will be performed, and the ruling will be determined to be benign (and the quick match table may be updated, as described above with respect to Figure 4A and Figure 4B similarly described).

[0146] DNS Probing for Cobalt Strike Team Server Detection An example implementation of DNS active probing for Cobalt Strike team server detection will now be described. As an initial pre-check operation of the probing logic, the destination IP probing and verification module performs a final check of the DNS probing of the dst IP and port (e.g., the target). As a final pre-check operation of the DNS probing logic, the destination IP probing and verification module sends a carefully crafted DNS request to the target to download the beacon file. Fig. 9AAn example DNS request for performing active probing on a target according to some embodiments is illustrated. Specifically, a specially crafted DNS request is sent to the target to download a beacon file. More specifically, the specially crafted DNS request is a txt DNS request with the domain aaa.stage.xxxx, such as Fig. 9A shown.

[0147] The destination IP detection and verification module then checks the contents of the DNS response from the target. If the target is a Cobalt Strike team server, the response from the target will return a txt DNS record response with content starting with "WYIIIIIIIIIIII" (e.g., based on heuristic analysis of Cobalt Strike team server behavior and the contents of its beacon files, such content exists in the Cobalt Strike base64 encoding of the beacon file's shared code), such as Fig. 9B shown. Fig. 9B An example DNS response to an active probe of a target is illustrated in accordance with some embodiments. Otherwise (e.g., the response does not match the above criteria), and therefore, the target is determined not to be a Cobalt Strike team server, and further active probing and assessment will be performed, and a verdict will be determined to be benign (and the quick match table may be updated, as described above with respect to Figure 4A and Figure 4B similarly described).

[0148] Additional example procedures for the disclosed techniques for detecting Cobalt Strike team server detection will now be described.

[0149] Example procedure for HTTP / HTTPS probing against Cobalt Strike team server detection Fig.10 is a flow chart of a process for HTTP / HTTPS probing for Cobalt Strike team server detection according to some embodiments. In some embodiments, Fig.10 The illustrated process 1000 is performed by a security platform and techniques similar to those described above, including the security platform and techniques described above with respect to Figures 1 to 8 In one embodiment, process 1000 is performed as described above. Figure 1 The data device 102 described above Figure 1The described network platform 122 (e.g., as a cloud-based security service), a virtual appliance (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 may be 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.

[0150] At 1002, HTTP / HTTPS network traffic is monitored at a firewall. For example, the firewall may detect HTTP / HTTPS traffic using application identification, such as described above with respect to Figure 1 and FIG. 4A to FIG. 4B Similar to what is described.

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

[0152] At 1006, an HTTP / HTTPS probe of the target is performed to detect whether the target is a Cobalt Strike team server. For example, the destination IP detection and verification module can perform further heuristic analysis on the response from the target to automatically detect the Cobalt Strike team server, as described above with respect to FIG. 4A to FIG. 4B , FIG. 5A to FIG. 5G and Figure 8 Similar to what is described.

[0153] At 1008, an action is performed in response to detecting that the target is a Cobalt Strike team server. The security platform (122) and the data appliance (102) can then respond to the malware verdict based on a policy (e.g., a security / C2-related malware policy, which can be stored in Figure 2BThe data appliance may be configured to block Cobalt Strike Beacon HTTP / HTTPS C2 business activities. Other example actions may include: blocking access to a destination IP address associated with detected Cobalt Strike Beacon HTTP / HTTPS C2 business activities; blocking / discarding network services associated with detected Cobalt Strike Beacon HTTP / HTTPS C2 business activities and / or associated with a destination IP address; alerting end users and / or network / security administrators that a terminal is associated with detected Cobalt Strike Beacon HTTP / HTTPS C2 business activities; isolating end devices associated with detected Cobalt Strike Beacon HTTP / HTTPS C2 business activities; identifying a destination IP address, URL, etc. associated with detected Cobalt Strike Beacon HTTP / HTTPS C2 business activities as malicious (or potentially malicious); and / or various other actions may also be performed based on policies.

[0154] Example procedure for DNS probing against Cobalt Strike team server detection Fig.11 is a flow chart of a process for DNS probing for Cobalt Strike team server detection according to some embodiments. In some embodiments, Fig.11 The illustrated process 1100 is performed by a security platform and techniques similar to those described above, including the security platform and techniques described above with respect to Figures 1 to 7 and FIG. 9A to FIG. 9B In one embodiment, process 1100 is performed by Figure 1 The data device 102 described above Figure 1 The described network platform 122 (e.g., as a cloud-based security service), a virtual appliance (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 may be 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.

[0155] At 1102, DNS network traffic is monitored at a firewall. For example, the firewall may utilize application identification to detect DNS traffic, such as described above with respect to Figure 1 and FIG. 4A to FIG. 4B Similar to what is described.

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

[0157] DNS pre-filtering operations (such as Figure 4A An example implementation of (similarly shown at 410 in ) can be performed by a DNS pre-filtering module implemented on the 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 business is forwarded to the cloud for further CobaltStrike detection analysis.

[0158] At 1106, a DNS probe of the target is performed to detect whether the target is a Cobalt Strike team server. For example, the destination IP detection and verification module can perform further heuristic analysis on the response from the target to automatically detect the Cobalt Strike team server, as described above with respect to FIG. 4A to FIG. 4B , FIG. 5A to FIG. 5G and FIG. 9A to FIG. 9B Similar to what is described.

[0159] At 1108, an action is performed in response to detecting that the target is a Cobalt Strike team server. The security platform (122) and the data appliance (102) can then respond to the malware verdict based on a policy (e.g., a security / C2-related malware policy, which can be stored in Figure 2BThe data appliance may be configured to block Cobalt Strike Beacon DNS C2 business activities. Other example actions may include: blocking access to a destination IP address associated with detected Cobalt Strike Beacon DNS C2 business activities; blocking / discarding network services associated with detected Cobalt Strike Beacon DNS C2 business activities and / or associated with a destination IP address; alerting an end user and / or network / security administrator that a terminal is associated with detected Cobalt Strike Beacon DNS C2 business activities; isolating an end device associated with detected Cobalt Strike Beacon DNS C2 business activities; identifying a destination IP address, URL, etc. associated with detected Cobalt Strike Beacon DNS C2 business activities as malicious (or potentially malicious); and / or various other actions may also be performed based on the policy.

[0160] Although the above embodiments have been described in some detail for clarity of understanding, the invention is not limited to the details provided. There are many alternative ways to implement the invention. The disclosed embodiments are illustrative rather than restrictive.

Claims

1. A system comprising: The processor is configured as: Monitor Hypertext Transfer Protocol (HTTP) network traffic at the firewall; Pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic to forward to the cloud security service; determining, based on a plurality of heuristics, whether the subset of HTTP network traffic is associated with Cobalt Strike Beacon HTTPC2 traffic activity; as well as Performing actions in response to detecting Cobalt Strike Beacon HTTP C2 traffic activity; as well as The memory is coupled to the processor and configured to provide instructions to the processor.

2. The system of claim 1, wherein the detection system's quick match table stores previously detected CobaltStrike Beacon HTTP C2 business activities.

3. The system of claim 1 , wherein the quick match table of the detection system stores triplets of previously detected CobaltStrike Beacon HTTP C2 business activities, wherein the triplets include a source IP address, a destination IP address, and a destination port.

4. The system according to claim 1, wherein data statistics based on the automatic heuristic analysis of the subset of HTTP network services are stored in a data statistics table of the detection system.

5. The system of claim 1, wherein the processor is further configured to perform verification on the detected Cobalt StrikeBeacon HTTP C2 service activity.

6. The system of claim 1, wherein the processor is further configured to perform verification of the detected CobaltStrike Beacon HTTP C2 traffic activity based on probing a destination IP address associated with the detected CobaltStrike Beacon HTTP C2 traffic activity.

7. The system of claim 1, wherein the processor is further configured to perform verification of the detected Cobalt Strike Beacon HTTP C2 traffic activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity and using a fingerprint data repository.

8. A method comprising: Monitor Hypertext Transfer Protocol (HTTP) network traffic at the firewall; Pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic to forward to the cloud security service; determining, based on a plurality of heuristics, whether the subset of HTTP network traffic is associated with Cobalt Strike Beacon HTTPC2 traffic activity; as well as An action is performed in response to detecting Cobalt Strike Beacon HTTP C2 traffic activity.

9. The method of claim 8, wherein the detection system's quick match table stores previously detected CobaltStrike Beacon HTTP C2 business activities.

10. The method of claim 8, wherein the quick match table of the detection system stores triplets of previously detected CobaltStrike Beacon HTTP C2 business activities, wherein the triplets include a source IP address, a destination IP address, and a destination port.

11. The method according to claim 8, wherein data statistics based on the automatic heuristic analysis of the subset of HTTP network services are stored in a data statistics table of the detection system.

12. The method of claim 8, further comprising performing verification of detected Cobalt Strike Beacon HTTPC2 business activities.

13. The method of claim 8, further comprising performing verification of the detected Cobalt Strike Beacon HTTP C2 traffic activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity.

14. The method of claim 8, further comprising performing verification of the detected Cobalt Strike Beacon HTTP C2 traffic activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity and using a fingerprint data repository.

15. A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for: Monitor Hypertext Transfer Protocol (HTTP) network traffic at the firewall; Pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic to forward to the cloud security service; determining, based on a plurality of heuristics, whether the subset of HTTP network traffic is associated with Cobalt Strike Beacon HTTPC2 traffic activity; as well as An action is performed in response to detecting Cobalt Strike Beacon HTTP C2 traffic activity.

16. The computer program product of claim 15, wherein the quick match table of the detection system stores previously detected Cobalt Strike Beacon HTTP C2 traffic activity.

17. The computer program product of claim 15, wherein the quick match table of the detection system stores triplets of previously detected Cobalt Strike Beacon HTTP C2 traffic activity, wherein the triplets include a source IP address, a destination IP address, and a destination port.

18. The computer program product of claim 15, further comprising computer instructions for performing validation on detected Cobalt Strike Beacon HTTP C2 traffic activity.

19. The computer program product of claim 15, further comprising computer instructions for performing verification of the detected Cobalt Strike Beacon HTTP C2 traffic activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity.

20. The computer program product of claim 15, further comprising computer instructions for performing verification of the detected Cobalt Strike Beacon HTTP C2 traffic activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity and using a fingerprint data repository.

21. A system, comprising: The processor is configured as: Monitor Hypertext Transfer Protocol Secure (HTTPS) network traffic at the firewall; Pre-filtering the monitored HTTPS network traffic at the firewall to select a subset of the HTTPS network traffic to forward to the cloud security service; determining, based on a plurality of heuristics, whether the subset of HTTPS network traffic is associated with Cobalt Strike BeaconHTTPS C2 traffic activity; as well as Performing actions in response to detecting Cobalt Strike Beacon HTTPS C2 traffic activity; as well as The memory is coupled to the processor and configured to provide instructions to the processor.

22. The system of claim 21, wherein the quick match table of the detection system stores previously detected Cobalt Strike Beacon HTTPS C2 traffic activities.

23. The system of claim 21, wherein the quick match table of the detection system stores triplets of previously detected Cobalt Strike Beacon HTTPS C2 traffic activities, wherein the triplets include a source IP address, a destination IP address, and a destination port.

24. The system of claim 21, wherein data statistics based on the automatic heuristic analysis of the subset of HTTPS network services are stored in a data statistics table of the detection system.

25. The system of claim 21, wherein the processor is further configured to perform verification of the detected CobaltStrike Beacon HTTPS C2 service activity.

26. The system of claim 21, wherein the processor is further configured to perform verification of the detected Cobalt Strike Beacon HTTPS C2 traffic activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTPS C2 traffic activity.

27. The system of claim 21, wherein the processor is further configured to perform verification of the detected Cobalt Strike Beacon HTTPS C2 traffic activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTPS C2 traffic activity and using a fingerprint data repository.

28. A method comprising: Monitor Hypertext Transfer Protocol Secure (HTTPS) network traffic at the firewall; Pre-filtering the monitored HTTPS network traffic at the firewall to select a subset of the HTTPS network traffic to forward to the cloud security service; determining, based on a plurality of heuristics, whether the subset of HTTPS network traffic is associated with Cobalt Strike BeaconHTTPS C2 traffic activity; as well as An action is performed in response to detecting Cobalt Strike Beacon HTTPS C2 traffic activity.

29. The method of claim 28, wherein the detection system's quick match table stores previously detected Cobalt Strike Beacon HTTPS C2 traffic activity.

30. The method of claim 28, wherein the quick match table of the detection system stores triplets of previously detected Cobalt Strike Beacon HTTPS C2 traffic activities, wherein the triplets include a source IP address, a destination IP address, and a destination port.

31. The method of claim 28, wherein data statistics based on the automatic heuristic analysis of the subset of HTTPS network services are stored in a data statistics table of the detection system.

32. The method of claim 28, further comprising performing verification of detected Cobalt Strike BeaconHTTPS C2 traffic activity.

33. The method of claim 28, further comprising performing verification of the detected Cobalt StrikeBeacon HTTPS C2 traffic activity based on probing a destination IP address associated with the detected Cobalt StrikeBeacon HTTPS C2 traffic activity.

34. The method of claim 28, further comprising performing verification of the detected Cobalt Strike Beacon HTTPS C2 traffic activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTPS C2 traffic activity and using a fingerprint data repository.

35. A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for: Monitor Hypertext Transfer Protocol Secure (HTTPS) network traffic at the firewall; Pre-filtering the monitored HTTPS network traffic at the firewall to select a subset of the HTTPS network traffic to forward to the cloud security service; determining, based on a plurality of heuristics, whether the subset of HTTPS network traffic is associated with Cobalt Strike BeaconHTTPS C2 traffic activity; as well as An action is performed in response to detecting Cobalt Strike Beacon HTTPS C2 traffic activity.

36. The computer program product of claim 35, wherein the quick match table of the detection system stores previously detected Cobalt Strike Beacon HTTPS C2 traffic activity.

37. The computer program product of claim 35, wherein the quick match table of the detection system stores triplets of previously detected Cobalt Strike Beacon HTTPS C2 traffic activity, wherein the triplets include a source IP address, a destination IP address, and a destination port.

38. The computer program product of claim 35, further comprising computer instructions for performing verification of detected Cobalt Strike Beacon HTTPS C2 traffic activity.

39. The computer program product of claim 35, further comprising computer instructions for performing verification of the detected Cobalt Strike Beacon HTTPS C2 traffic activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTPS C2 traffic activity.

40. The computer program product of claim 35, further comprising computer instructions for performing verification of the detected Cobalt Strike Beacon HTTPS C2 traffic activity based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTPS C2 traffic activity and using a fingerprint data repository.

41. A system, comprising: The processor is configured as: Monitoring Hypertext Transfer Protocol (HTTP), HTTPS, and / or Domain Name System (DNS) network traffic at the firewall; pre-filtering the monitored HTTP, HTTPS and / or DNS network traffic at the firewall to select a subset of the HTTP, HTTPS and / or DNS network traffic to forward to the cloud security service; Perform HTTP, HTTPS, and / or DNS probing on a target to detect if said target is a Cobalt Strike team server; as well as performing an action in response to detecting that the target is a Cobalt Strike team server; as well as The memory is coupled to the processor and configured to provide instructions to the processor.

42. The system of claim 41, wherein detection of the Cobalt Strike team server verifies malware verdicts on CobaltStrike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity.

43. The system of claim 41, wherein the detection system's quick match table stores triplets of previously detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity, wherein the triplets include a source IP address, a destination IP address, and a destination port.

44. The system of claim 41, wherein data statistics based on the automatic heuristic analysis of the subset of HTTP, HTTPS and / or DNS network traffic are stored in a data statistics table of the detection system.

45. The system of claim 41, wherein the processor is further configured to perform verification of detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity based on active probing.

46. ​​The system of claim 41, wherein the processor is further configured to perform verification of the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity based on detection of a destination IP address associated with the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity.

47. The system of claim 41, wherein the processor is further configured to perform verification of the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic based on detection of a destination IP address associated with the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic and using a fingerprint data repository.

48. A method comprising: Monitoring Hypertext Transfer Protocol (HTTP), HTTPS, and / or Domain Name System (DNS) network traffic at the firewall; pre-filtering the monitored HTTP, HTTPS and / or DNS network traffic at the firewall to select a subset of the HTTP, HTTPS and / or DNS network traffic to forward to the cloud security service; Perform HTTP, HTTPS, and / or DNS probing on a target to detect if said target is a Cobalt Strike team server; as well as An action is performed in response to detecting that the target is a Cobalt Strike team server.

49. The method of claim 48, wherein detection of the Cobalt Strike team server verifies malware verdicts on Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 service activity.

50. The method of claim 48, wherein the detection system's quick match table stores triplets of previously detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity, wherein the triplets include a source IP address, a destination IP address, and a destination port.

51. The method of claim 48, wherein data statistics based on the automatic heuristic analysis of the subset of HTTP, HTTPS and / or DNS network traffic are stored in a data statistics table of the detection system.

52. The method of claim 48, further comprising performing verification of detected Cobalt StrikeBeacon HTTP, HTTPS, and / or DNS C2 traffic activity based on active probing.

53. The method of claim 48, further comprising performing verification of the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity based on probing of a destination IP address associated with the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity.

54. The method of claim 48, further comprising performing verification of the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic based on probing a destination IP address associated with the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic and using a fingerprint data repository.

55. A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for: Monitoring Hypertext Transfer Protocol (HTTP), HTTPS, and / or Domain Name System (DNS) network traffic at the firewall; pre-filtering the monitored HTTP, HTTPS and / or DNS network traffic at the firewall to select a subset of the HTTP, HTTPS and / or DNS network traffic to forward to the cloud security service; Perform HTTP, HTTPS, and / or DNS probing on a target to detect if said target is a Cobalt Strike team server; as well as An action is performed in response to detecting that the target is a Cobalt Strike team server.

56. The computer program product of claim 55, wherein detection of the Cobalt Strike team server verifies malware verdicts on Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity.

57. The computer program product of claim 55, wherein the detection system's quick match table stores triplets of previously detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity, wherein the triplets include a source IP address, a destination IP address, and a destination port.

58. The computer program product of claim 55, further comprising computer instructions for performing verification of detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity based on active probing.

59. The computer program product of claim 55, further comprising computer instructions for performing verification of the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity based on probing of a destination IP address associated with the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity.

60. The computer program product of claim 55, further comprising computer instructions for performing verification of the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic based on probing of destination IP addresses associated with the detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic and using a fingerprint data repository.

Images