Cobalt Strike Beacon HTTP C2 Heuristic Detection

Abstract

Techniques for detecting Cobalt Strike beacon HTTP C2 heuristics are disclosed. In some embodiments, a system / process / computer program product for detecting Cobalt Strike beacon HTTP C2 heuristics includes monitoring hypertext transfer protocol (HTTP) network traffic with a firewall, pre-filtering the monitored HTTP network traffic with the firewall to select a subset of the HTTP network traffic for transfer to a cloud security service, determining whether the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity based on a plurality of heuristics, and executing an action in response to detecting the Cobalt Strike beacon HTTP C2 traffic activity.

Description

Background Art

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

Brief Description of the Drawings

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

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4A

Figure 4B

Figure 5A

Figure 5A-1

Figure 5B

Figure 5C

Figure 5D

Figure 5E

Figure 5F

Figure 5F-1

Figure 5G

Figure 6

Figure 7

Figure 8

Figure 9A

Figure 9B

Figure 10

Figure 11

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present invention can be implemented in a number of ways, including a processor, such as a process, an apparatus, a system, a composition, a computer program product embodied on a computer-readable storage medium, and / or instructions stored in a memory and / or instructions stored and / or provided by a memory coupled to a processor and configured to execute the instructions. In this specification, these implementations, or any other form the present invention may take, may be referred to as a technique. Generally, the order of steps of the disclosed process may be changed within the scope of the present invention. Unless otherwise specified, components such as a processor or a memory described as being configured to perform a task are implemented as a general-purpose component temporarily configured to perform the task at a given time or as a specific 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.

[0004] A detailed description of one or more embodiments of the present invention is provided below along with the accompanying drawings that illustrate the principles of the present invention. The present invention is described in relation to such embodiments, but the present invention is not limited to any particular embodiment. The scope of the present invention is limited only by the claims and the present invention includes numerous alternatives, modifications, and equivalents. To provide a complete understanding of the present invention, numerous specific details are set forth in the following description. These details are provided for purposes of illustration and the present invention may be practiced according to the claims without some or all of these specific details. To clarify, technical material known in the technical field related to the present invention is not described in detail so as not to unnecessarily obscure the present invention.

[0005] A firewall generally permits authorized communications to pass through the firewall while protecting the network from unauthorized access. A firewall is typically a device, a set of devices, or software running on a device that provides firewall functionality for network access. For example, a firewall can be integrated into the operating system of a device (such as a computer, smartphone, or other type of network - communicable device). A firewall can also be integrated or run as a software application on various types of devices or security devices, such as a computer server, a gateway, a network / routing device (such as a network router), or a data appliance (such as a security device or other type of special - purpose device), and in some implementations, certain operations can be implemented with special - purpose hardware such as an ASIC or FPGA. to.

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

[0007] A security device (e.g., a security appliance, a security gateway, a security service, and / or other security devices) can perform various security operations (e.g., firewall, anti-malware, intrusion prevention / detection, proxy, and / or other security functions), network functions (e.g., routing, quality of service (QoS), workload balancing of network-related resources, and / or other network functions), and / or other security and / or network-related functions. For example, routing can be performed based on source information (e.g., IP address and port), destination information (e.g., IP address and port), and protocol information.

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

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

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

[0011] As described above, advanced or next-generation firewalls can perform stateless and stateful packet filtering and application layer filtering. Next-generation firewalls can also perform additional firewall technologies. For example, a given new firewall often referred to as an advanced or next-generation firewall can also identify users and content. In particular, a given next-generation firewall has expanded 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 of firewalls from Palo Alto Networks). For example, Palo Alto Networks' next-generation firewalls use various identification technologies to enable enterprises and service providers to identify and control applications, users, and content - not just ports, IP addresses, and packets. The various identification technologies include Application ID (App-ID) for accurate application identification, User ID (User-ID) for user identification (e.g., User ID), Content ID (Content-ID) for real-time content scanning (e.g., to control web surfing and limit the transfer of data and files), and Device ID (Device-ID) (e.g., for identifying the type of IoT device). These identification technologies allow enterprises to use business-related concepts to safely enable the use of applications, rather than following the traditional approach provided by conventional port-blocking firewalls.In addition, specific-purpose hardware for next-generation firewalls (e.g., implemented as a dedicated device) generally provides a higher performance level for application inspection than software executed on general-purpose hardware (e.g., security devices provided by Palo Alto Networks, which utilize dedicated, function-specific processing tightly integrated with a single-pass software engine, minimizing latency while maximizing network throughput for Palo Alto Networks' PA series next-generation firewalls).

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

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

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

[0015] Cobalt Strike is an example of a type of malware that uses evasion techniques to bypass malware solutions that rely on pattern matching based on existing malware signatures (for example, penetration testing service providers (pen testers) often use the Cobalt Strike (CS) tool to test commercially available security solutions such as firewall security solutions). Cobalt Strike is a commercially available / publicly available tool kit that is often used by researchers and penetration testers. However, it can also be used by attackers / hackers to penetrate corporate networks for unauthorized / illicit purposes (such as extraction of confidential / proprietary data related to corporate networks, etc.).

[0016] Specifically, malware authors can use self-defined command and control (C2 or C&C) profile configurations for Cobalt Strike to avoid malware solutions that rely on pattern matching based on existing malware signatures. The Cobalt Strike tool kit can generate C2 traffic based on various protocols, including the Hypertext Transfer Protocol (HTTP), the Hypertext Transfer Protocol Secure (HTTPS), and the Domain Name System (DNS) protocol.

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

[0018] Accordingly, new and improved techniques for Cobalt Strike beacon HTTP / HTTPS C2 heuristic detection are disclosed.

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

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

[0021] In some embodiments, a system / process / computer program product for Cobalt Strike beacon HTTP / HTTPS C2 heuristic detection includes the following. That is, monitoring HTTP / HTTPS network traffic in a firewall, pre-filtering the monitored HTTP / HTTPS network traffic in the firewall to select a subset of the HTTPS network traffic for transfer to a cloud security service, determining whether a subset of the HTTP / HTTPS network traffic is associated with Cobalt Strike beacon HTTP / HTTPS C2 traffic activity based on a plurality of heuristics, and performing an action in response to detecting Cobalt Strike beacon HTTP / HTTPS C2 traffic activity.

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

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

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

[0025] In some embodiments, a system / process / computer program product for Cobalt Strike beacon HTTP / HTTPS C2 heuristic detection includes the following. Namely, monitoring Hypertext Transfer Protocol (HTTP) network traffic with a firewall. Prefiltering the HTTP network traffic monitored by the firewall to select a subset of the HTTP network traffic to forward to a cloud security service, where prefiltering the HTTP network traffic monitored by the firewall to select a subset of the HTTP network traffic to forward to a cloud security service includes performing a heuristic analysis of the HTTP network traffic 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 traffic, where the heuristic analysis of the HTTP network traffic includes selecting 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 traffic, namely, whether the network traffic includes a header value or URI length check that matches a range from 171 bytes to 256 bytes, and whether the network traffic includes a header value or URI length field with an encoding that matches one of these types related to base64, base64url, netbios, netbiosu, or mask encoding. Forwarding a subset of the HTTP network traffic to the cloud security service, where the cloud security service automatically determines whether the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity based on multiple heuristics.Receiving, from a cloud security service, a response that a subset of HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity. And, in response to a determination that a subset of HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity, performing an action.

[0026] In some embodiments, a system / process / computer program product for Cobalt Strike beacon HTTP / HTTPS C2 heuristic detection further includes performing a data statistics check to perform a behavior-based detection of Cobalt Strike beacon HTTP C2 traffic activity, including checking time stamps of at least the first 12 sessions to determine whether it is a Gaussian distribution or a normal distribution, and automatically determining, by a cloud security service, whether a subset of HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity based on a plurality of heuristics.

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

[0028] In some embodiments, a system / process / computer program product for Cobalt Strike beacon HTTPS C2 heuristic detection includes the following. Namely, 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 for transfer to a cloud security service, determining, based on a plurality of heuristics, whether the subset of the HTTPS network traffic is associated with Cobalt Strike beacon HTTPS C2 traffic activity, and performing an action in response to detecting Cobalt Strike beacon HTTPS C2 traffic activity.

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

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

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

[0032] 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.

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

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

[0035] Accordingly, new and improved security solutions that facilitate Cobalt Strike beacon HTTP / HTTPS C2 heuristic detection using a security platform are disclosed in accordance with some embodiments (e.g., a firewall (FW) / next-generation firewall (NGFW), a network sensor operating in place of a firewall, or another (virtual) device / component that can implement security policies using the disclosed techniques, such as Palo Alto Networks' PA series next-generation 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 can be similarly implemented and configured to execute the disclosed techniques).

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

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

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

[0039] FIG. 1 shows one example of an environment in which malicious applications (“malware”) are detected and prevented from causing harm. As described in more detail below, malware classification may be shared and / or refined among various entities included in the environment shown in FIG. 1 (e.g., as performed by security platform 122), and devices, such as endpoint client devices 104-110, may be protected from such malware (e.g., including previously unknown / new malware variants such as C2 malware) using the techniques described herein.

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

[0041] The techniques described herein can be used for the automatic detection of malware in various forms (e.g., new and / or mutant malware such as C2 malware) in conjunction with and / or on various platforms (e.g., servers, computing devices, virtual / container environments, desktops, mobile devices, game platforms, embedded systems, etc.). In the exemplary environment shown in FIG. 1, client devices 104-108 are laptop computers, desktop computers, and tablets (respectively) present in enterprise network 140. Client device 110 is a laptop computer that exists outside enterprise network 140.

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

[0043] One embodiment of the data appliance is shown in FIG. 2A. The example shown is a representation of the physical components included in the data appliance 102 in various embodiments. Specifically, the data appliance 102 includes a high-performance multi-core central processing unit (CPU) 202 and a random access memory (RAM) 204. The data appliance 102 also includes storage 210 (such as one or more hard disks or solid state units). In various embodiments, the data appliance 102 is used to monitor the enterprise network 110 and store information (in either RAM 204, storage 210, and / or other appropriate locations) used to implement the disclosed techniques. 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., including C2 ML models, such as for sample traffic-based self-learning malware detection as further described herein). The data appliance 102 may also include one or more optional hardware accelerators. For example, the data appliance 102 may include an encryption engine 206 configured to perform encryption and decryption operations, and one or more field programmable gate arrays (FPGAs) 208 configured to perform matching, operate as a network processor, and / or perform other tasks.

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

[0045] Whenever the data appliance 102 is described as performing a task, a single component, a subset of components, or all components of the data appliance 102 can cooperate to perform the task. Similarly, whenever a component of the data appliance 102 is described as performing a task, a sub-component can perform the task and / or a component can perform the task with other components. In various embodiments, a portion of the data appliance 102 is 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 can be included in embodiments of the data appliance 102 as applicable. One example of a component included in the data appliance 102 in various embodiments is an application identification engine configured to identify an application (e.g., using various application signatures to identify an application based on packet flow analysis). For example, the application identification engine can determine the type of traffic a session is involved in. Such as web browsing - social networking, web browsing - news, SSH, etc.

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

[0047] As shown in the figure, 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 interaction by providing a user interface for policy setting and display of log data. The data plane is responsible for data management by performing packet processing and session processing.

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

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

[0050] Based on the decisions made by the Application Identification engine 242, packets are sent by the Threat engine 244 to the appropriate decoder, which is configured to assemble the packets (which may be received out of order) in the correct order, perform tokenization, and extract information. The Threat engine 244 also performs signature matching to determine what should happen to the packets. If necessary, the SSL encryption engine 246 can re-encrypt the decrypted data. The packets are transferred for forwarding (e.g., to the destination) using the transfer module 248.

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

[0052] Security Platform

[0053] Returning to FIG. 1, assume that a malicious individual (using System 120) creates malware 130, such as malware that uses a new / modified profile to generate Cobalt Strike beacon C2 HTTP / HTTPS traffic to avoid detection by existing IPS signatures (e.g., the malware can be delivered to the user's endpoint device via a compromised website when the user visits / browses a compromised website or via a phishing attack). The malicious individual wants the client device, such as client device 104, to execute a copy of malware 130 to unpack the malware executable file / payload, compromising the client device and turning the client device into a bot within a botnet, etc. The compromised client device can then be instructed to execute tasks (e.g., cryptocurrency mining or participating in a denial-of-service attack) and report information to an external entity, such as command and control (C&C) server 150, and, if applicable, receive instructions from C&C server 150.

[0054] Assume that data appliance 102 intercepts an email sent (e.g., by system 120) to user “Alice” who operates client device 104. In this example, Alice receives the email and clicks on a link to a phishing / vulnerable site, which may result in an attempt by Alice's client device 104 to download malware 130. However, in this example, data appliance 102 implements the disclosed techniques for sample traffic-based self-learning malware detection and blocks access to the malware content packed from Alice's client device 104, and thereby can preempt and prevent any such download of malware 130 to Alice's client device 104. As further described below, data appliance 102 executes the disclosed techniques for sample traffic-based self-learning malware detection as further described below to detect such malware 130 and block it from harming Alice's client device 104.

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

[0056] 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 to perform sample traffic-based self-learning malware detection, and the malware determination is returned to the data appliance 102 to enforce the security policy, thereby protecting Alice's client device 104 from execution of the malware 130 (e.g., blocking the malware 130 from access on the client device 104).

[0057] Furthermore, the security platform 122 can also provide other types of information (e.g., as part of a subscription), such as a set of information for performing the techniques disclosed for sample traffic-based self-learning malware detection available by the data appliance 102 to perform in-line analysis of such malware files, to the data appliance 102.

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

[0059] The security platform 122 stores a copy of the received sample in the storage 142, and then analysis is initiated (or, if applicable, scheduled). One example of the storage 142 is an Apache Hadoop cluster (HDFS). The results of the analysis (and additional information about the application) are stored in the database 146. If 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 for the malware is generated and distributed (e.g., to data appliances such as data appliances 102, 136, and 148), and future file transfer requests for downloading files determined to be malicious can be automatically blocked.

[0060] In various embodiments, security platform 122 comprises one or more dedicated, off-the-shelf hardware servers (e.g., having multi-core processors, 32G+ RAM, gigabit network interface adapters, and hard drives) running a typical server-class operating system (e.g., Linux®). Security platform 122 may be implemented across a scalable infrastructure including multiple such servers, solid-state drives, and / or other applicable high-performance hardware. Security platform 122 may comprise several distributed components, including components provided by one or more third parties. For example, some or all of security platform 122 may be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). Additionally, similar to data appliance 102, whenever 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 subcomponents of security platform 122 may cooperate (individually or in cooperation with third-party components) to perform that task. As one example, security platform 122 can optionally cooperate with one or more virtual machine (VM) servers, such as VM server 124, to perform static and dynamic analysis.

[0061] One example of a virtual machine server is a commercial server-class hardware (e.g., a multi-core processor, 32+ gigabytes of RAM, and one or more gigabit network interface adapters) that runs commercial virtualization software such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V, which is a physical machine. In some embodiments, the virtual machine server is omitted. Further, the virtual machine server may be under the control of the same entity that manages the security platform 122, or it may be provided by a third party. As one example, the virtual machine server can rely on EC2, and the rest of the security platform 122 is provided by dedicated hardware owned 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 run various operating systems and / or their versions. The observed behavior resulting from running an application within a virtual machine is logged (e.g., for indications that the application is malicious) and analyzed. In some embodiments, the log analysis is performed by the VM server (e.g., VM server 124). In other embodiments, the analysis is at least partially performed by other components of the security platform 122, such as the coordinator 144.

[0062] In various embodiments, the security platform 122 makes the results of the analysis of samples available to the data appliance 102 as part of a subscription via a list of signatures (and / or other identifiers). For example, the security platform 122 can periodically send content packages that identify malware files, including network traffic-based heuristic IPS malware detection, etc. (e.g., daily, hourly, or at other intervals and / or based on events configured by one or more policies). One exemplary content package includes a Cobalt Strike beacon (CSB) detector 154, as further described below, and / or other information (e.g., an ML-based detection model). The subscription can be intercepted by the data appliance 102 and cover the analysis of only the files sent to the security platform 122 by the data appliance 102, and can also cover malware signatures 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 network traffic-based heuristic IPS malware detection. Specifically, the platform 122 can utilize the CSB detector 154 (e.g., a C2M L model that can be implemented as a plugin or sub-component of the platform 122, as further described below with respect to FIGS. 4A and 4B), which can help the data appliance 102 detect potentially new / transformed C2 malware (e.g., Cobalt Strike beacon C2 HTTP / HTTPS traffic) and perform in-line blocking.

[0063] In various embodiments, security platform 122 is configured to provide security services to various entities in addition to (or, if applicable, instead of) the operator of data appliance 102. For example, other businesses 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 utilize the services of security platform 122. For example, an Internet Service Provider (ISP) providing 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, the 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 in accordance with the techniques described herein, and then send applications to security platform 122 for analysis).

[0064] Analyzing samples using static and dynamic analysis

[0065] 3 illustrates one example of logical components that may be included in a system for analyzing samples. Analysis system 300 may be implemented using a single device. For example, the functionality of analysis system 300 may be implemented in malware analysis module 112 embedded in data appliance 102. Analysis system 300 may also be implemented collectively across multiple separate devices. For example, the functionality of analysis system 300 may be provided by security platform 122.

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

[0067] 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. As shown in FIG. 3, the application 130 is received by the system 300 and added to the queue 302.

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

[0069] The static analysis engine obtains general information about the sample and includes it in the static analysis report 308 (along with heuristic information and other information where applicable). The report can be created by the static analysis engine or by a coordinator 304 (or another appropriate component) configured to receive information from the static analysis engine 306. As one example, static analysis of malware can include performing signature-based analysis. In some embodiments, the information collected is stored in a database record of the sample (e.g., within database 316) instead of, or in addition to, a separate static analysis report 308 being created (i.e., portions of the database record form the report 308). In some embodiments, the static analysis engine also forms a determination about the application (e.g., "safe", "suspicious", or "malicious"). As one example, if there is even one "malicious" static characteristic in the application (e.g., the application includes a hard link to a known malicious domain), the determination can be "malicious". As another example, points can be assigned to each of the characteristics (e.g., based on severity if found, based on how reliable the characteristic is at predicting malice, etc.). And based on the number of points associated with the static analysis results, a determination can be assigned by the static analysis engine 306 (or by the coordinator 304 where applicable).

[0070] Once the static analysis is complete, the coordinator 304 locates an available dynamic analysis engine 310 to perform dynamic analysis on the application. Similar to the static analysis engine 306, the analysis system 300 can 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).

[0071] Each dynamic analysis worker manages a virtual machine instance (e.g., emulation / sandbox analysis of samples for malware detection such as the above-described C2 malware detection based on monitored network traffic activities). In some embodiments, the results of static analysis (e.g., performed by the static analysis engine 306), whether in report form (308) and / or stored in the database 316 or otherwise stored, 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 SP2 vs. Microsoft Windows 10 Enterprise, or iOS 11.0 vs. iOS 12.0). When multiple virtual machine instances are run simultaneously, a single dynamic analysis engine can manage all of the instances, or, where applicable, multiple dynamic analysis engines can be used (e.g., each managing its own virtual machine instance). As will be described in more detail below, during the dynamic part of the analysis, actions (including network activities) performed by the application are analyzed.

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

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

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

[0075] Cobalt Strike Beacon HTTP C2 Heuristic Detection

[0076] FIG. 4A shows a portion of one exemplary embodiment of a detection system and a quality check system for processing network traffic to perform Cobalt Strike beacon C2 HTTP traffic detection, according to some embodiments. As described above, in various embodiments, the security platform 122 includes a Cobalt Strike beacon (CSB) detector 154. FIG. 4A shows the sub-components of the CSB detector 154, including the following sub-components, namely, a detection system 402 and a quality check system 404.

[0077] Referring to FIG. 4A, a behavior-based cross-session detection solution for performing cobalt strike beacon C2 HTTP traffic detection is executed in cooperation with a data appliance (e.g., a data appliance implementing a firewall, also simply referred to as a firewall hereinafter) 102 using a cloud-based security service (e.g., cloud security service 122 as shown in FIG. 1). The behavior-based detection solution performs a cross-session check and includes three components as described below.

[0078] The firewall 102 monitors network traffic in the enterprise network (including, for example, HTTP traffic in the enterprise network 140 as shown in FIG. 1). As shown at 410, the firewall 102 uses the data plane to monitor network traffic and uses an HTTP filter module (e.g., a sub-component) to perform pre-filtering analysis of the network traffic. As shown at 412, when the following pre-filtering analysis of the HTTP traffic hits (i.e., is selected to reduce the amount of traffic transferred to the cloud security 122 for further analysis to detect potential cobalt strike beacon C2 traffic, as further described below) and meets both of the following exemplary criteria based on the header length and header encoding format, the firewall 102 transfers the traffic (e.g., a packet capture (pcap) file of the network traffic related to the session) to the detection system. First, the HTTP filtering module determines whether the network traffic includes a header value or URI length check that matches a range from 171 bytes to 256 bytes. Second, the HTTP filtering module determines whether the network traffic includes a header value or URI length field using an encoding that matches one of these types related to encoding, which is base64, base64url, netbios, netbiosu, or a mask. Based on experiments (e.g., test results), the pre-filtering reduces the amount of network traffic transferred for further analysis by the cloud security service to only approximately 0.32% of the total network traffic.

[0079] The Cobalt Strike Beacon (CSB) detector 154 includes a detection system 402, which implements a decision tree based on the source IP address (SrcIP), destination IP address (DstIP), and destination port (DstPort) associated with each new session, and executes the following checks based on the data statistics associated with each new session. The detection system 402 can determine whether there is a prior verdict stored in the fast match table as an initial logic check, and if there is a match based on the 3-tuple of SrcIP, DstIP, and DstPort, the prior verdict is returned to the firewall 102 without further analysis / processing by the detection system 402.

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

[0081] First, check the timestamps of the first 12 sessions to determine whether it is a Gaussian distribution or a normal distribution. In an exemplary implementation, the Bowley Skewness algorithm for normal distribution calculation (for example, the Bowley Skewness algorithm is publicly available at https: / / www.statisticshowto.com / bowley-skewness / ) can be used to implement Gaussian distribution or normal distribution calculation, and in particular, check whether it is a normal distribution for the timestamps from the first 12 sessions. The median absolute deviation is determined using the median absolute deviation algorithm (for example, 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) for 12 sessions from 6 seconds to 556 seconds (for example, 6 / 10 - 556 / 10, 1 second to 55 seconds per session, and in this exemplary implementation, 40 seconds is selected for this connection count distribution calculation).

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

[0083] Third, check whether the MD5 hash values of the HTTP headers are the same (for example, the metadata including cookies associated with the session is the same for each machine at risk, and as a result, the MD5 of the HTTP header will be the same value for each session, which becomes a new communication to its C2 team server).

[0084] Fourth, check whether the amount of HTTP header fields (i.e., the number of fields included in the HTTP header) is less than 10 fields in the HTTP header (e.g., due to design limitations resulting from the Cobalt Strike beacon tool kit design implementation).

[0085] Fifth, check whether the HTTP header does not contain custom headers.

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

[0087] Based on the above heuristics, if these logical checks result in a match, the network traffic of such sessions is determined to be associated with Cobalt Strike beacon C2 HTTP traffic. If no match exists, the network traffic for such sessions is determined not to be associated with Cobalt Strike beacon C2 HTTP traffic. The determination is stored in a fast match table, as shown at 416. Specifically, after the determination is made as described above using a detection system, a triple (e.g., SrcIP, DstIP, Dstport) is added to the fast match table along with the determination. Thus, the detection system queries the fast match table for subsequent sessions, as described above, facilitating a more efficient determination of the previous analysis of HTTP traffic.

[0088] In 418, the quality check system 404 executes verification of the results of the detection system 402 to determine whether any previous determination for Cobalt Strike beacon C2 HTTP traffic was a false positive or a false negative. Specifically, the destination (Dest) IP probing and verification module (e.g., a sub-component) performs automatic probing of the destination IP address by sending a custom HTTP request (e.g., a custom HTTP / HTTPS / DNS request) to the destination IP address. As shown at 420, the destination IP probing and verification module then determines whether the response contains a fingerprint associated with Cobalt Strike (e.g., the HTTP response data contains the default proof provided by Cobalt Strike and / or the HTTP response matches the fingerprint of Cobalt Strike (CS). That is, in an exemplary implementation, the CS fingerprint is a predefined string included in the response traffic from the CS team server. For example, when a client sends an HTTP request with a randomized URL to the CS team server, the team server responds with an HTTP status code 404 and the following exemplary headers Content-Type:text / plain\r\Gmt:Wed,27Feb2019 14:43:19 nDate\r\nContent-Length:0. Thus, as further described below with respect to various embodiments, "Content-Type:text / plain" and Content-Length:0 can be used as fingerprints to identify the CS team server), and verifies the Cobalt Strike beacon C2 HTTP traffic (CS) determination of the network traffic / session communicating 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 associated with malware related to Cobalt Strike beacons (e.g., known malware samples previously identified as malware related to Cobalt Strike beacons based on previous malware analysis), and if so, can verify the determination of Cobalt Strike beacon C2 HTTP traffic (CS). If not, the determination is automatically changed from a CS determination to a benign determination (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 determination to attempt to detect any false positives or false negatives for Cobalt Strike beacon C HTTP traffic.

[0089] The behavior-based and session-intermediate detection solution disclosed for performing Cobalt Strike beacon C2 HTTP traffic detection promotes a 90% detection improvement rate for the detection of Cobalt Strike beacon C2 HTTP traffic based on experimental / test results compared to existing IPS signature-based approaches (e.g., for default / known profiles for Cobalt Strike beacon C2 HTTP traffic).

[0090] Cobalt Strike Beacon HTTPS C2 Heuristic Detection

[0091] Figure 4B shows a portion of one exemplary embodiment of a detection system and a quality check system for processing network traffic to perform Cobalt Strike beacon C2 HTTPS traffic detection, according to some embodiments. As similarly described above with respect to Figure 4A, the security platform 122 includes a Cobalt Strike beacon (CSB) detector 154. Figure 4B similarly shows sub-components of the CSB detector 154, namely, a detection system 402 and a quality check system 404. However, as further described below, the HTTPS prefiltering logic module / sub-component and the HTTPS logic check module / sub-component perform different prefiltering and logic checks on HTTPS traffic (e.g., since the HTTPS traffic headers / content are encrypted, separate heuristics for automatically detecting Cobalt Strike beacon C2 HTTPS traffic are disclosed herein, as further described below).

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

[0093] Firewall 102 monitors network traffic on the enterprise network (including, for example, HTTP traffic in enterprise network 140 as shown in FIG. 1). As shown at 410, firewall 102 uses the data plane to monitor network traffic and uses an HTTPS prefilter module (e.g., a subcomponent) to perform prefiltering analysis of the network traffic. As shown at 412, firewall 102 transfers traffic (e.g., a packet capture (pcap) file of network traffic related to a session) to the detection system when the following prefiltering analysis for HTTP traffic hits (i.e., meets both of the following exemplary criteria based on the Server hello random field value and includes "DOWNGRD" (e.g., this field value is present in Cobalt Strike beacon C2 HTTPS traffic but is also associated with benign traffic, and thus this prefiltering is used before further analysis is performed using the detection system described below that checks for additional heuristics), which is selected to reduce the amount of traffic transferred to cloud security 122 for further analysis to detect potential Cobalt Strike beacon C2 traffic, as further described below). In particular, the prefiltering module determines whether the Server hello random field value contains the "DOWNGRD" value. Based on experiments (e.g., test results), the prefiltering reduces the amount of network traffic transferred for further analysis by the cloud security service, which is only approximately 0.002% of the total network traffic.

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

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

[0096] First, check the timestamps of the first 12 sessions to determine whether it is a Gaussian distribution or a normal distribution. In an exemplary implementation, the Bowley Skewness algorithm for normal distribution calculation (for example, the Bowley Skewness algorithm is publicly available at https: / / www.statisticshowto.com / bowley-skewness / ) can be used to implement Gaussian distribution or normal distribution calculation, and in particular, check whether it is a normal distribution of timestamps from the first 12 sessions. The median absolute deviation is determined using the median absolute deviation algorithm (for example, 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) of 12 sessions from 6 seconds to 556 seconds (for example, 6 / 10 - 556 / 10, 1 second to 55 seconds per session, and in this exemplary implementation, 40 seconds is selected for this connection count distribution calculation).

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

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

[0099] Based on the above heuristics, if these logical checks result in a match, the network traffic of such sessions is determined to be associated with Cobalt Strike beacon C2 HTTP traffic. If no match exists, the network traffic for such sessions is determined not to be associated with Cobalt Strike beacon C2 HTTP traffic. The determination is stored in the fast match table as shown at 416. Specifically, after the determination is made as described above using the detection system, a 3-tuple (e.g., SrcIP, DstIP, Dstport) is added to the fast match table along with the determination. Thus, the detection system queries the fast match table for subsequent sessions in the same manner as described above, facilitating a more efficient determination of the previous analysis of HTTP traffic.

[0100] At 418, the quality check system 404 executes verification of the results of the detection system 402 to determine whether any previous determination for Cobalt Strike beacon C2 HTTPS traffic was a false positive or a false negative. Specifically, the destination (Dest) IP probing and verification module (e.g., a sub-component) performs automated probing of the destination IP address by sending a custom HTTPS request (e.g., a custom HTTP / HTTPS / DNS request) to the destination IP address. As shown at 420, the destination IP probing and verification module then determines whether the response contains a fingerprint associated with Cobalt Strike (e.g., the HTTPS response data includes the default certificate provided by Cobalt Strike and / or the HTTPS response matches the fingerprint of Cobalt Strike (CS). That is, in an exemplary implementation, the CS fingerprint is a predefined string included in the response traffic from the CS team server. For example, when a client sends an HTTPS request with a client hello to the CS team server, the team server responds to the client with a server hello and a server certificate, and by default, the certificate includes the CS keyword "Major Cobalt Strike", and thus, as further described below with respect to various embodiments, the certificate keyword "Major Cobalt Strike" can be used as a fingerprint to identify the CS team server), and verifies the Cobalt Strike beacon C2 HTTPS traffic (CS) determination of the network traffic / session communicating 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 associated with malware related to the Cobalt Strike beacon (e.g., known malware samples previously identified as malware related to the Cobalt Strike beacon based on previous malware analysis), and then the determination of Cobalt Strike beacon C2 HTTPS traffic (CS) can be verified. Otherwise, the determination is automatically changed from a CS determination to a benign determination (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 determination in an attempt to detect any false positives or false negatives for Cobalt Strike beacon C2 HTTPS traffic.

[0101] Behavior - based for performing Cobalt Strike beacon C2 HTTPS traffic detection, and the disclosed techniques for the detection solution across sessions promote a 90% detection improvement rate for the detection of Cobalt Strike beacon C2 HTTPS traffic based on experimental / test results compared to existing IPS signature - based approaches (e.g., for the default / known profile for Cobalt Strike beacon C2 HTTPS traffic).

[0102] Exemplary Use Cases for Cobalt Strike Beacon HTTP C2 Heuristic Detection

[0103] Figure 5A shows exemplary attributes associated with Cobalt Strike beacon HTTP traffic used for heuristic detection, according to some embodiments. Referring to Figure 5A, this exemplary network traffic shows an HTTP request header MD5 hash that is identical to the requested URL as shown at 502, and a cookie (e.g., base64-encoded) as shown at 504 associated with a session for such Cobalt Strike beacon HTTP traffic. Thus, this example shows network traffic that meets the prefiltering criteria, as similarly described above with respect to Figure 4A. First, the header value or URI length check matches in the range of 171 bytes to 256 bytes. Second, the network traffic includes a header value or URI length field with base64 encoding, and thus matches one of these types of encoding, namely base64, base64url, netbios, netbiosu, or mask. As a result, this network traffic shown at 506 is transferred to cloud security 122 for further analysis using the CSB detector 154, as similarly described above with respect to Figure 4A.

[0104] Figure 5B shows additional exemplary attributes associated with Cobalt Strike beacon HTTP traffic used for heuristic detection, according to some embodiments. Referring to Figure 5B, this exemplary network traffic has fewer request header fields (i.e., fewer than 10 request header fields) associated with the Cobalt Strike (CS) HTTP requests compared to benign HTTP requests at 522, which have a greater number of HTTP request header fields (i.e., more than 10 request header fields), as shown at 520 (i.e., in this example only 6 request header fields are present). Thus, as shown at 520, this exemplary network traffic meets the above-described fourth heuristic related to the amount of HTTP header fields, as described above with respect to Figure 4A (i.e., the number of fields included in the HTTP header is less than 10 fields within the HTTP header).

[0105] Figure 5C shows additional exemplary attributes associated with Cobalt Strike beacon HTTP traffic used for heuristic detection, according to some embodiments. Referring to Figure 5C, this exemplary network traffic shows an HTTP user agent that is a known user agent (UA) and has no custom headers, as shown at 530. Thus, as shown at 530, this exemplary network traffic meets the above-described sixth heuristic related to whether the HTTP user agent (UA) is a known / popular UA, as described above with respect to Figure 4A.

[0106] Figure 5D shows additional exemplary attributes associated with Cobalt Strike beacon HTTP traffic used for heuristic detection, according to some embodiments. Referring to Figure 5D, this exemplary network traffic shows HTTP request header content without a custom header, as indicated by 540. Thus, as indicated by 540, this exemplary network traffic meets the above-described fifth heuristic related to whether the HTTP header contains a custom header or not, as described above with respect to Figure 4A as well.

[0107] Exemplary Use Cases for Cobalt Strike Beacon HTTPS C2 Heuristic Detection

[0108] Figure 5E shows additional exemplary attributes associated with Cobalt Strike beacon HTTPS traffic used for heuristic detection, according to some embodiments. Referring to Figure 5E, as indicated by 550, this exemplary network traffic shows an HTTPS request where the server hello random field value contains the "DOWNGRD" value, as described above with respect to Figure 4B as well. As a result, as indicated by 506, this network traffic is forwarded to cloud security 122 for further analysis using CSB detector 154, as described above with respect to Figure 4B as well.

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

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

[0111] Additional exemplary processes for the disclosed techniques for Cobalt Strike beacon HTTP / HTTPS C2 heuristic detection will now be described.

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

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

[0114] At 602, HTTP network traffic is monitored at the firewall. For example, the firewall can utilize application identification to detect HTTP traffic, as similarly described above with respect to FIGS. 1 and 4A.

[0115] At 604, in the firewall, prefiltering of monitored HTTP network traffic is performed to select a subset of the HTTP network traffic for transfer to the cloud security service. For example, the HTTP prefiltering module can perform heuristic analysis of the HTTP network traffic to select a subset of the HTTP traffic sessions for transfer to the cloud security service for further analysis, as described above with respect to FIGS. 4A and 5A - 5D.

[0116] At 606, it is performed to determine whether a subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity based on multiple heuristics. For example, the HTTP logic module can perform further heuristic analysis of the HTTP network traffic to automatically detect Cobalt Strike beacon HTTP C2 traffic, as described above with respect to FIGS. 4A and 5A - 5D.

[0117] At 608, in response to detecting Cobalt Strike beacon HTTP C2 traffic activity, an action is executed. The security platform (122) and / or the data appliance (102) can then execute an action based on a policy (e.g., a security / C2 related malware policy that can be stored in policy 252 as shown in FIG. 2B) in response to a malware determination. For example, the data appliance can be configured to block Cobalt Strike beacon HTTP C2 traffic activity. Other exemplary actions can include the following. Blocking access to the destination IP address associated with the detected Cobalt Strike beacon HTTP C2 traffic activity, blocking / dropping network traffic associated with the detected Cobalt Strike beacon HTTP C2 traffic activity and / or its destination IP address, warning the endpoint user and / or the network / security administrator that the endpoint is associated with the detected Cobalt Strike beacon HTTP C2 traffic activity, isolating the endpoint device associated with the detected Cobalt Strike beacon HTTP C2 traffic activity, identifying the destination IP address, URL, etc. associated with the Cobalt Strike beacon HTTP C2 traffic activity detected as malicious (or potentially malicious). And / or various other actions can also be executed based on the policy.

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

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

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

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

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

[0123] In 708, actions are executed in response to detecting Cobalt Strike beacon HTTPS C2 traffic activity. The security platform (122) and / or data appliance (102) can then execute an action based on a policy (e.g., a security / C2 related malware policy that can be stored in policy 252 as shown in FIG. 2B) in response to a malware determination. For example, the data appliance can be configured to block Cobalt Strike beacon HTTPS C2 traffic activity. Other exemplary actions can include the following. Blocking access to the destination IP address associated with the detected Cobalt Strike beacon HTTPS C2 traffic activity, blocking / dropping network traffic associated with the detected Cobalt Strike beacon HTTPS C2 traffic activity and / or its destination IP address, warning the endpoint user and / or network / security administrator that the endpoint is associated with the detected Cobalt Strike beacon HTTPS C2 traffic activity, isolating the endpoint device associated with the detected Cobalt Strike beacon HTTPS C2 traffic activity, identifying the destination IP address, URL, etc. associated with the Cobalt Strike beacon HTTP C2 traffic activity detected as malicious (or potentially malicious). And / or various other actions can also be executed based on the policy.

[0124] Probing for Cobalt Strike Team Server Detection

[0125] Another technical problem is to verify that the target IP address (e.g., extracted based on the above-described technology) hosts a Cobalt Strike team server.

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

[0127] In some embodiments, a system / process / computer program product for probing for Cobalt Strike team server detection includes the following. Monitoring hypertext transfer protocol (HTTP), HTTPS, and / or domain name system (DNS) network traffic in a firewall, pre-filtering the monitored HTTP, HTTPS, and / or DNS network traffic in the firewall to select a subset of the HTTP, HTTPS, and / or DNS network traffic for transfer to a cloud security service, performing HTTP, HTTPS, and / or DNS probing of 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.

[0128] In some embodiments, a system / process / computer program product for probing for Cobalt Strike team server detection further includes verifying that detection of a Cobalt Strike team server validates malware determination of Cobalt Strike beacon HTTP, HTTPS, and / or DNS C2 traffic activities.

[0129] In some embodiments, a system / process / computer program product for probing for Cobalt Strike team server detection further includes that a fast match table of the detection system stores 3-tuples of previously detected Cobalt Strike beacon HTTP, HTTPS, and / or DNS C2 traffic activities, where the 3-tuples include a source IP address, a destination IP address, and a destination port.

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

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

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

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

[0134] 4A and 4B, the destination IP probing and validation component / module of the quality check system 404 performs active probing of IP addresses (e.g., via HTTP or HTTPS) to detect whether the IP addresses host Cobalt Strike Team servers based on responses to the active probing (e.g., packets sent from the target IP address in response to the probe packets). As described further below, the disclosed active probing techniques for Cobalt Strike Team server detection may be performed using a variety of network protocols, including, for example, HTTP, HTTPS, and / or DNS.

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

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

[0137] Exemplary implementations for HTTP / HTTPS active probing for Cobalt Strike team server detection will now be described. As an initial precheck operation of the probing logic, the destination IP probing and verification module sends a sophisticated precheck HTTP / HTTPS request to the dst IP and port (e.g., the target). An example of a sophisticated precheck HTTP / HTTPS request is as follows, namely, http[s]: / / [IP]:[Port] / index.html. The destination IP probing and verification module then checks / evaluates the response to the cleverly crafted precheck HTTP / HTTPS request. Specifically, if the following is received in the response from the target, it is considered suspicious (e.g., it could be a Cobalt Strike team server (high likelihood)), and further active probing and evaluation are performed. More specifically, the response includes a status code equal to 404, and the HTTP / HTTPS header includes the following fields and values. Namely, "Date" and the date value (e.g., "Wed, 9Feb2022 23:09:48 GMT"), "Content-Type", "text / plain", and "Content-Length": "0". Otherwise (e.g., these fields and values do not exist in the response from the target), it is determined that the target is not a Cobalt Strike team server, and no further active probing and evaluation are performed, and the determination is made that it is benign (and, similar to what was described above with respect to FIGS. 4A and 4B, the fast match table can be updated).

[0138] As the final pre-check operation of the HTTP / HTTPS probing logic, the destination IP probing and verification module sends sophisticated HTTP / HTTPS requests targeted at downloading the beacon file. An exemplary sophisticated final pre-check HTTP / HTTPS request includes the URL value of "Swb1", and is as follows, namely, http[s]: / / [IP]:[Port] / Swb1. In this example, "Swb1" can be any 4 bytes that meet the following checksum requirements. That is, the input string text is a 4-byte URL value, using the checksum algorithm shown in Figure 8, etc., based on the platform, the 4-byte URL checksum value is equal to 92 or 93. Figure 8 shows the checksum algorithm for probing the logic for HTTP / HTTPS Cobalt Strike team server detection according to some embodiments. The destination IP probing and verification module then checks / evaluates the response to the created final check HTTP / HTTPS request. When the target is a Cobalt Strike team server, the response from the target returns 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 2 bytes equal to 0xFC48 or 0xFCe8 (for example, thus, based on the behavior of the Cobalt Strike team server and the heuristic analysis of the content of its beacon file, it exists in the Cobalt Strike shared code of the beacon file). Otherwise (for example, if the response does not meet the above criteria), as a result, it is determined that the target is not a Cobalt Strike team server, and further active probing and evaluation are not performed, and the verdict is determined to be benign (and, similar to what was described above with respect to Figures 4A and 4B, the fast match table can be updated).

[0139] DNS Probing for Cobalt Strike Team Server Detection

[0140] An exemplary 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 on 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 sophisticated DNS request to the target to download the beacon file. FIG. 9A shows one exemplary DNS request for performing active probing of a target according to some embodiments. Specifically, a sophisticated DNS request is sent to the target to download the beacon file. More specifically, the sophisticated DNS request is a txt DNS request having the domain aaa.stage.xxxx as shown in FIG. 9A.

[0141] The destination IP probing and verification module then checks the content of the DNS response from the target. If the target is a Cobalt Strike team server, the response from the target returns a txt DNS record response with content starting with "WYIIIIIIIIIIII" as shown in FIG. 9B (encoded in Cobalt Strike base64 for the shared code for the beacon file based on heuristic analysis of the behavior of the Cobalt Strike team server and the content of its beacon file). FIG. 9B shows one exemplary DNS response to the active probing of a target according to some embodiments. Otherwise (e.g., the response does not meet the above criteria), as a result, the target is determined not to be a Cobalt Strike team server, and further active probing and evaluation are not performed, and the evaluation decision is determined to be benign (the fast match table can be updated as described above with respect to FIGS. 4A and 4B).

[0142] Additional exemplary processes for the techniques disclosed for Cobalt Strike team server detection probing will now be described.

[0143] Exemplary Process for HTTP / HTTPS Probing for Cobalt Strike Team Server Detection

[0144] FIG. 10 is a flowchart of a process for HTTP / HTTPS probing for Cobalt Strike team server detection according to some embodiments. In some embodiments, process 1000 as shown in FIG. 10 is executed by a security platform and techniques as described above, including the embodiments described above with respect to FIGS. 1-8. In one embodiment, process 1000 is the data appliance 102 described above with respect to FIG. 1, the security platform 122 described above with respect to FIG. 1 (e.g., as a cloud-based security service), a virtual appliance (e.g., Palo Alto Networks' VM series virtualized next-generation firewall, CN series container next-generation firewall, and / or other commercially available virtual-based or container-based firewalls can be similarly implemented and configured to execute the disclosed techniques), an SDN security solution, a cloud security service, and / or a combination or hybrid implementation of the foregoing described herein.

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

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

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

[0148] In 1008, in response to detecting that the target is a Cobalt Strike team server, an action is executed. The security platform (122) and / or the data appliance (102) can then execute an action based on a policy (e.g., a security / C2-related malware policy that can be stored in policy 252 as shown in FIG. 2B) in response to a malware determination. For example, the data appliance can be configured to block Cobalt Strike beacon HTTP / HTTPS C2 traffic activity. Other exemplary actions can include the following. Blocking access to the destination IP address associated with the detected Cobalt Strike beacon HTTP / HTTPS C2 traffic activity, blocking / dropping network traffic associated with the detected Cobalt Strike beacon HTTP / HTTPS C2 traffic activity and / or its destination IP address, warning the endpoint user and / or the network / security administrator that the endpoint is associated with the detected Cobalt Strike beacon HTTP / HTTPS C2 traffic activity, isolating the endpoint device associated with the detected Cobalt Strike beacon HTTP / HTTPS C2 traffic activity, identifying the destination IP address, URL, etc. associated with the Cobalt Strike beacon HTTP / HTTPS C2 traffic activity detected as malicious (or potentially malicious). And / or various other actions can also be executed based on the policy.

[0149] Exemplary Process for DNS Probing for Cobalt Strike Team Server Detection

[0150] Figure 11 is a flowchart relating to the process of DNS probing for Cobalt Strike team server detection according to some embodiments. In some embodiments, the process 1100 shown in FIG. 11 is executed by the security platforms and techniques described above, including the embodiments described above with respect to FIGS. 1-7 and FIGS. 9A-9B. In one embodiment, the process 1100 may be executed by the data appliance 102 described above with respect to FIG. 1, the security platform 122 described above with respect to FIG. 1 (e.g., as a cloud-based security service), a virtual appliance (e.g., Palo Alto Networks' VM series virtualized next-generation firewall, CN series container next-generation firewall, and / or other commercially available virtual-based or container-based firewalls that can similarly implement and be configured to execute the disclosed techniques), an SDN security solution, a cloud security service, and / or a combination or hybrid implementation of the foregoing described herein.

[0151] At 1102, DNS network traffic is monitored at the firewall. For example, the firewall can utilize application identification to detect DNS traffic, as similarly described above with respect to FIGS. 1 and 4A-4B.

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

[0153] An exemplary implementation of DNS prefiltering operation as similarly shown at 410 in FIG. 4A can be performed by a DNS prefilter module implemented on firewall 102 by performing the following heuristic analysis. That is, when a DNS request is a DNS txt record (e.g., dns.qry.type==16 (txt record)), the traffic is forwarded to the cloud for further Cobalt Strike detection analysis.

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

[0155] At 1108, an action is performed in response to detecting that the target is a Cobalt Strike Team server. The security platform 122 and / or the data appliance 102 can then perform an action based on a policy (e.g., a security / C2-related malware policy, which may be stored in policy 252 as shown in FIG. 2B) in response to the malware determination. For example, the data appliance may be configured to block Cobalt Strike beacon DNS C2 traffic activity. Other example actions may include: Blocking access to the destination IP address associated with the detected Cobalt Strike Beacon DNS C2 traffic activity, blocking / dropping network traffic associated with the detected Cobalt Strike Beacon DNS C2 traffic activity and / or associated with the destination IP address, alerting the endpoint user and / or network / security administrator that the endpoint is associated with the detected Cobalt Strike Beacon DNS C2 traffic activity, quarantining the endpoint device associated with the detected Cobalt Strike Beacon DNS C2 traffic activity, identifying the destination IP address, URL, etc. associated with the detected Cobalt Strike Beacon DNS C2 traffic activity as malicious (or potentially malicious), and / or various other actions may also be performed based on policy.

[0156] Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not limiting.

Claims

1. A system comprising a processor and a memory, wherein the processor monitors Hypertext Transfer Protocol (HTTP) network traffic with a firewall and prefilters the monitored HTTP network traffic with the firewall to select a subset of the HTTP network traffic for transfer to a cloud security service prefiltering the monitored HTTP network traffic with the firewall to select a subset of the HTTP network traffic for transfer to the cloud security service includes performing a heuristic analysis of the HTTP network traffic to select a subset of the HTTP network traffic for transfer to the cloud security service for further analysis to detect potential Cobalt Strike beacon HTTP C2 traffic the heuristic analysis of the HTTP network traffic includes selecting a subset of the HTTP network traffic for transfer to the cloud security service for further analysis to detect potential Cobalt Strike beacon HTTP C2 traffic (1) determining whether the network traffic includes a header value or URI length check that matches a range from 171 bytes to 256 bytes, and (2) determining whether the network traffic includes a header value or URI length field with an encoding that matches one of the encodings of base64, base64url, netbios, netbiosu, or mask and transferring the subset of the HTTP network traffic to the cloud security service, the cloud security service automatically determining whether the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity based on a plurality of heuristics Receive a response from the cloud security service that the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity, and, In response to detecting that the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity, perform an action, Is configured as, The memory is, Is coupled to the processor and, Is configured to provide instructions to the processor, System.

2. The fast match table of the detection system stores previously detected Cobalt Strike beacon HTTP C2 traffic activity, The system according to claim 1.

3. The fast match table of the detection system stores 3-tuples of previously detected Cobalt Strike beacon HTTP C2 traffic activity, The 3-tuples include a source IP address, a destination IP address, and a destination port, The system according to claim 1.

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

5. The processor further, Performs verification of the detected Cobalt Strike beacon HTTP C2 traffic activity, Is configured as, The system according to claim 1.

6. The processor further, Performs verification of the detected Cobalt Strike beacon HTTP C2 traffic activity based on probing of the destination IP address associated with the detected Cobalt Strike beacon HTTP C2 traffic activity, Is configured as, The system according to claim 1.

7. The processor further, Performs verification of the detected Cobalt Strike beacon HTTP C2 traffic activity based on probing of the destination IP address associated with the detected Cobalt Strike beacon HTTP C2 traffic activity and using a fingerprint data store, Is configured as, The system according to claim 1. [

8. ] A method comprising: monitoring Hypertext Transfer Protocol (HTTP) network traffic with a firewall; prefiltering the monitored HTTP network traffic with the firewall to select a subset of the HTTP network traffic for transfer to a cloud security service; wherein prefiltering the monitored HTTP network traffic with the firewall to select a subset of the HTTP network traffic for transfer to the cloud security service includes performing a heuristic analysis of the HTTP network traffic to select a subset of the HTTP network traffic for transfer 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 performing a heuristic analysis of the HTTP network traffic to select a subset of the HTTP network traffic for transfer to the cloud security service for further analysis to detect potential Cobalt Strike beacon HTTP C2 traffic; determining (1) whether the network traffic includes a header value or URI length check that matches a range from 171 bytes to 256 bytes, and (2) whether the network traffic includes a header value or URI length field with an encoding that matches one of the encodings of base64, base64url, netbios, netbiosu, or mask; including; steps; transferring the subset of the HTTP network traffic to the cloud security service, the cloud security service automatically determining whether the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity based on a plurality of heuristics. Receiving, from the cloud security service, a response that the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity; Performing an action in response to detecting that the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity; A method comprising the above.

9. The fast match table of the detection system stores previously detected Cobalt Strike beacon HTTP C2 traffic activity. The method according to claim 8.

10. The fast match table of the detection system stores 3-tuples of previously detected Cobalt Strike beacon HTTP C2 traffic activity. The 3-tuples include a source IP address, a destination IP address, and a destination port. The method according to claim 8.

11. Data statistics based on an automated heuristic analysis of a subset of the HTTP network traffic are stored in a data statistics table of the detection system. The method according to claim 8.

12. The method further comprises: Performing a verification of the detected Cobalt Strike beacon HTTP C2 traffic activity. The method according to claim 8, comprising the above.

13. The method further comprises: Performing a verification of the detected Cobalt Strike beacon HTTP C2 traffic activity based on probing of a destination IP address associated with the detected Cobalt Strike beacon HTTP C2 traffic activity. The method according to claim 8, comprising the above.

14. The method further comprises: Performing a verification of the detected Cobalt Strike beacon HTTP C2 traffic activity based on probing of a destination IP address associated with the detected Cobalt Strike beacon HTTP C2 traffic activity and using a fingerprint data store. The method according to claim 8, comprising the above.

15. A computer program stored on a tangible computer-readable storage medium, comprising computer instructions. When the computer instructions are executed, the computer monitors Hypertext Transfer Protocol (HTTP) network traffic with a firewall, prefiltering the monitored HTTP network traffic with the firewall to select a subset of the HTTP network traffic for transfer to a cloud security service, wherein prefiltering the monitored HTTP network traffic with the firewall to select a subset of the HTTP network traffic for transfer to the cloud security service includes performing a heuristic analysis of the HTTP network traffic to select a subset of the HTTP network traffic for transfer 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 performing a heuristic analysis of the HTTP network traffic to select a subset of the HTTP network traffic for transfer to the cloud security service for further analysis to detect potential Cobalt Strike beacon HTTP C2 traffic, (1) whether the network traffic includes a header value or URI length check that matches a range from 171 bytes to 256 bytes, and (2) whether the network traffic includes a header value or URI length field with an encoding that matches one of the encodings of base64, base64url, netbios, netbiosu, or mask, including determining steps, transferring the subset of the HTTP network traffic to the cloud security service, the cloud security service automatically determining whether the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity based on multiple heuristics, Receiving, from the cloud security service, a response that the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity; Performing an action in response to detecting that the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity; Implementing a method comprising: A computer program.

16. The fast match table of the detection system stores previously detected Cobalt Strike beacon HTTP C2 traffic activity. The computer program according to claim 15.

17. The fast match table of the detection system stores a 3-tuple of previously detected Cobalt Strike beacon HTTP C2 traffic activity, wherein the 3-tuple includes a source IP address, a destination IP address, and a destination port. The computer program according to claim 15.

18. The computer program further includes computer instructions, which, when executed, cause a computer to perform a step of verifying the detected Cobalt Strike beacon HTTP C2 traffic activity, implementing a method comprising: The computer program according to claim 15.

19. The computer program further includes computer instructions, which, when executed, cause a computer to perform a step of verifying the detected Cobalt Strike beacon HTTP C2 traffic activity based on probing of a destination IP address associated with the detected Cobalt Strike beacon HTTP C2 traffic activity, implementing a method comprising: The computer program according to claim 15.

20. The computer program further includes computer instructions, which, when executed, cause a computer to Based on the probing of the destination IP address associated with the detected Cobalt Strike beacon HTTP C2 traffic activity and using a fingerprint data store, performing a step of verifying the detected Cobalt Strike beacon HTTP C2 traffic activity Implementing a method, including The computer program according to claim 15 **Claim 21** The cloud security service includes checking timestamps of at least 12 sessions in the first to automatically determine whether the subset of the HTTP network traffic is associated with Cobalt Strike beacon HTTP C2 traffic activity based on a plurality of heuristics, including performing a data statistics check to perform a behavior-based detection of Cobalt Strike beacon HTTP C2 traffic activity to determine whether it is a Gaussian distribution or a normal distribution The system according to claim 1

Images