Cobalt strike beacon HTTP c2 heuristic detection

Abstract

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

Description

[Background technology]

[0001] Malware is a general term commonly used to refer to malicious software (e.g., including a variety of hostile, intrusive, 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 disrupting computer and / or network operations, stealing confidential information (e.g., sensitive information such as identity, financial, and / or intellectual property-related information), and / or gaining access to private / private computer systems and / or computer networks. Unfortunately, as technologies are developed to aid in the detection and mitigation of malware, nefarious authors find ways to circumvent these efforts. Thus, there is a continuing need for improvements to techniques for identifying and mitigating malware. [Brief explanation of the drawings]

[0002] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings. [Figure 1] FIG. 1 shows an example of an environment in which malicious applications are detected and prevented from causing harm. [Figure 2A] FIG. 2A shows an example of a data appliance. [Figure 2B] FIG. 2B is a functional diagram of the logical components of one embodiment of a data appliance. [Figure 3] FIG. 3 illustrates one example of logical components that may be included in a system for analyzing a sample. [Figure 4A]FIG. 4A illustrates portions of one example embodiment of a detection system and quality check system for processing network traffic to perform Cobalt Strike Beacon C2 HTTP traffic detection, according to some embodiments. [Figure 4B] FIG. 4B illustrates portions of one example embodiment of a detection system and quality check system for processing network traffic to perform Cobalt Strike Beacon C2 HTTPS traffic detection, according to some embodiments. [Figure 5A] FIG. 5A illustrates example attributes associated with Cobalt Strike Beacon HTTP traffic used for heuristic detection, according to some embodiments. [Figure 5A-1] FIG. 5A illustrates example attributes associated with Cobalt Strike Beacon HTTP traffic used for heuristic detection, according to some embodiments. [Figure 5B] FIG. 5B illustrates additional example attributes associated with Cobalt Strike Beacon HTTP traffic used for heuristic detection, according to some embodiments. [Figure 5C] FIG. 5C illustrates additional example attributes associated with Cobalt Strike Beacon HTTP traffic used for heuristic detection, according to some embodiments. [Figure 5D] FIG. 5D illustrates additional example attributes associated with Cobalt Strike Beacon HTTP traffic used for heuristic detection, according to some embodiments. [Figure 5E] FIG. 5E illustrates additional example attributes associated with Cobalt Strike Beacon HTTPS traffic used for heuristic detection, according to some embodiments. [Figure 5F]FIG. 5F illustrates additional example attributes associated with Cobalt Strike Beacon HTTPS traffic used for heuristic detection, according to some embodiments. [Figure 5F-1] FIG. 5F illustrates additional example attributes associated with Cobalt Strike Beacon HTTPS traffic used for heuristic detection, according to some embodiments. [Figure 5G] FIG. 5G illustrates additional example attributes associated with Cobalt Strike Beacon HTTPS traffic used for heuristic detection, according to some embodiments. [Figure 6] FIG. 6 is a flowchart of a process for Cobalt Strike Beacon HTTP C2 heuristic detection, according to some embodiments. [Figure 7] FIG. 7 is a flowchart of a process for Cobalt Strike Beacon HTTPS C2 heuristic detection, according to some embodiments. [Figure 8] FIG. 8 illustrates a checksum algorithm for probing logic for HTTP / HTTPS Cobalt Strike TeamServer detection, according to some embodiments. [Figure 9A] FIG. 9A illustrates an exemplary DNS request for performing active probing of a target, according to some embodiments. [Figure 9B] FIG. 9B illustrates an exemplary DNS response to active probing of a target, according to some embodiments. [Figure 10] FIG. 10 is a flowchart of the process of HTTP / HTTPS probing for Cobalt Strike Team server detection, according to some embodiments. [Figure 11] FIG. 11 is a flowchart of the process of DNS probing for Cobalt Strike Team server discovery, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0003] The present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer program product embodied on a computer-readable storage medium, and / or a processor, such as instructions stored on a memory and / or a processor configured to execute instructions stored and / or provided by a memory coupled to the processor. These implementations, or any other form the present invention may take, may be referred to herein as techniques. In general, the order of steps in disclosed processes may be varied within the scope of the present invention. Unless otherwise specified, components, such as a processor or memory, described as configured to perform a task may be implemented as general-purpose components temporarily configured to perform the task at a given time, or as specific components 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 accompanying figures that illustrate the principles of the invention. While the present invention will be described in connection with such embodiments, the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention encompasses numerous alternatives, modifications, and equivalents. Numerous specific details are set forth in the following description to provide a thorough understanding of the present invention. These details are provided for the purpose of example, and the present invention may be practiced according to the claims without some or all of these specific details. For the purposes of clarity, technical material known in the art related to the present invention has not been described in detail so as not to unnecessarily obscure the present invention.

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

[0006] Firewalls typically deny or allow network transmissions based on a set of rules. These sets of rules are often referred to as policies (e.g., network policies or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted external traffic from reaching 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 may be specified in a firewall rule or firewall policy, which may be triggered based on various criteria, as described herein). A firewall can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.

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

[0008] Basic packet filtering firewalls filter network communication traffic by inspecting individual packets sent over the network (e.g., stateless packet filtering firewalls, or first-generation firewalls). Stateless packet filtering firewalls typically inspect the individual packets themselves and then apply rules based on the inspected packets (e.g., using a combination of the packet's source and destination address information, protocol information, and port numbers).

[0009] Application firewalls 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). Application-layer filtering firewalls or application firewalls can generally identify certain applications and protocols (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 that attempt to communicate on standard ports (e.g., unauthorized / out-of-policy protocols that attempt to sneak through by using a non-standard port for that protocol can generally be identified using an application firewall).

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

[0011] Advanced or next-generation firewalls can perform stateless and stateful packet filtering and application layer filtering, as described above. Next-generation firewalls can also implement additional firewall technologies. For example, certain newer firewalls, often referred to as advanced or next-generation firewalls, can also identify users and content. In particular, certain next-generation firewalls have expanded the list of applications that they can automatically identify to thousands of applications. Examples of such next-generation firewalls are commercially available from Palo Alto Networks (e.g., the Palo Alto Networks PA Series firewalls). 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. Various identification technologies include Application ID (App-ID) for precise 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 restrict data and file transfers), and Device ID (e.g., for identifying IoT device types). These identification technologies allow enterprises to securely enable application usage using business-relevant concepts instead of following the traditional approach provided by traditional port-blocking firewalls.Additionally, special-purpose hardware for next-generation firewalls (e.g., implemented as dedicated devices) generally provides higher performance levels for application inspection than software running on general-purpose hardware (e.g., security appliances from Palo Alto Networks, Inc., which utilize dedicated, function-specific processing that is tightly integrated with a single-pass software engine to minimize latency while maximizing network throughput, as in the case of 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., the Palo Alto Networks VM Series firewalls, which are deployed on, for example, VMware® ESXi). TM and NSX TM , Citrix® Netscaler SDX TM It supports a variety of commercial virtualization environments, including KVM / OpenStack (Centos / RHEL, Ubuntu®), and Amazon Web Services (AWS), as well as the CN Series container next-generation firewall. For example, the virtualized firewall can support similar or identical next-generation firewall and advanced threat prevention features available in physical form factor devices, allowing enterprises to safely enable the influx of applications in private, public, and hybrid cloud computing environments. Automation capabilities such as VM monitoring, dynamic address groups, and a REST-based API allow enterprises to dynamically monitor VM changes and update security policies with that context, thereby eliminating policy lag that can occur when VMs change.

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

[0014] Generally, existing anti-malware security solutions are often unable to detect new malware or new malware variants based on malware signatures (e.g., predefined patterns such as Intrusion Prevention System (IPS) signatures). Specifically, existing anti-malware security solutions generally are unable to detect new malware or new malware variants when a malware signature for the new malware or new malware variant does not yet exist (e.g., currently, signature-based content IPS solutions generally cannot effectively detect Cobalt Strike Beacon C2 traffic because only default or known profiles can typically be detected using existing signature-based content IPS solutions). These shortcomings 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 (e.g., 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 toolkit that is often used by researchers and penetration testers. However, it can also be used by attackers / hackers to infiltrate corporate networks for unauthorized / illegal purposes (e.g., extracting confidential / private data related to the corporate network).

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

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

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

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

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

[0021] In some embodiments, a system / process / computer program product for Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection includes monitoring HTTP / HTTPS network traffic at a firewall, pre-filtering the monitored HTTP / HTTPS network traffic at the firewall to select a subset of the HTTPS network traffic for forwarding to a cloud security service, determining whether the 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, the system / process / computer program product for Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection further includes using a high-speed match table of the detection system to store previously detected Cobalt Strike Beacon HTTP / HTTPS C2 traffic activity, where the high-speed match table of the detection system stores a 3-tuple of the previously detected Cobalt Strike Beacon HTTP / HTTPS C2 traffic activity, and the 3-tuple includes a source IP address, a destination IP address, and a destination port.

[0023] In some embodiments, the system / process / computer program product for Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection further includes storing data statistics based on the automated heuristic analysis of the subset of the HTTP / HTTPS network traffic, wherein 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 validation of the detected Cobalt Strike Beacon HTTP / HTTPS C2 traffic activity based on probing of destination IP addresses 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: monitoring Hypertext Transfer Protocol (HTTP) network traffic at a firewall; and pre-filtering HTTP network traffic monitored by a firewall to select a subset of the HTTP network traffic for forwarding to a cloud security service, wherein pre-filtering the HTTP network traffic monitored by a firewall to select a subset of the HTTP network traffic for forwarding to a cloud security service includes performing a heuristic analysis of the HTTP network traffic to select the subset of the HTTP traffic for forwarding to a cloud security service for further analysis to detect potential Cobalt Strike Beacon HTTP C2 traffic, wherein the heuristic analysis of the HTTP network traffic includes selecting the subset of the HTTP traffic for forwarding to the cloud security service for further analysis to detect potential Cobalt Strike Beacon HTTP C2 traffic by: determining whether the network traffic includes a header value or URI length check that matches a range of 171 bytes to 256 bytes; and determining whether the network traffic includes a header value or URI length field with an encoding that matches one of these types: base64, base64url, netbios, netbiosu, or mask encoding. and forwarding a subset of the HTTP network traffic to a cloud security service, wherein 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 a plurality of heuristics.receiving 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 performing an action in response to determining that the subset of the HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity.

[0026] In some embodiments, the system / process / computer program product for Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection further includes the cloud security service automatically determining whether a subset of HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity based on a plurality of heuristics, including performing a data statistical check to perform behavior-based detection of Cobalt Strike Beacon HTTP C2 traffic activity, including checking the timestamps of the first at least 12 sessions to determine whether they are Gaussian or normally distributed.

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

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

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

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

[0031] In some embodiments, the system / process / computer program product for Cobalt Strike Beacon HTTPS C2 heuristic detection further includes: data statistics based on the automated heuristic analysis of the subset of HTTPS network traffic are stored in a 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 validation of detected Cobalt Strike Beacon HTTPS C2 traffic activity.

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

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

[0035] Thus, a new and improved security solution is disclosed, according to some embodiments, that uses a security platform to facilitate Cobalt Strike Beacon HTTP / HTTPS C2 heuristic detection (e.g., a firewall (FW) / Next Generation Firewall (NGFW), a network sensor acting in place of a firewall, or another (virtual) device / component that can implement security policies using the disclosed techniques, e.g., 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 can be similarly implemented and configured to perform the disclosed techniques).

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

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

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

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

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

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

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

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

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

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

[0046] 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 data appliance 102 in various embodiments. Unless otherwise specified, the various logical components of data appliance 102 may generally be implemented in a variety of ways, including as a set of one or more scripts (e.g., written in Java, Python, etc., where applicable).

[0047] As shown, 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, such as by providing a user interface for setting policies and displaying log data, and the data plane is responsible for data management, such as by performing packet processing and session handling.

[0048] The network processor 236 is configured to receive packets from client devices, such as the client device 108, and provide them to the data plane 234 for processing. The flow module 238 creates 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 the flow lookup. If applicable, SSL decryption is applied by the SSL decryption engine 240. Otherwise, processing by the SSL decryption engine 240 is skipped. The decryption engine 240 helps the data appliance 102 inspect and control SSL / TLS and SSH encrypted traffic and, therefore, helps stop threats that might otherwise remain hidden within the encrypted traffic. The decryption engine 240 can also help prevent sensitive content from leaving the enterprise network 140. Decryption can be selectively controlled (e.g., enabled or disabled) based on parameters such as URL category, traffic source, traffic destination, user, user group, and port. In addition to decryption policies (e.g., specifying which sessions to decrypt), decryption profiles can be assigned to control various options of the sessions controlled by the policy, for example, requiring the use of specific cipher suites and encryption protocol versions.

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

[0050] Based on the determination made by the application identification engine 242, the 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) into 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 forwarded using the forwarding module 248 for forwarding (e.g., to a destination).

[0051] 2B, a policy 252 is also received and stored in the management plane 232. The policy can include one or more rules, which can be specified using domain names and / or host / server names, and the rules can apply one or more signatures or other matching criteria or heuristics, such as for security policy enforcement, to subscriber / IP flows based on various extracted parameters / information from the monitored session traffic flows. An example 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 communications (e.g., via (REST) ​​APIs, messages, or network protocol communications, or other communication mechanisms).

[0052] Security Platform

[0053] Returning to FIG. 1 , assume that a malicious individual (using system 120) has created malware 130, such as malware for generating Cobalt Strike Beacon C2 HTTP / HTTPS traffic using a new / variant profile to avoid detection by existing IPS signatures (e.g., the malware could be delivered to a user's endpoint device via a compromised website when the user visits / browses the compromised website or via a phishing attack). The malicious individual wants a client device, such as client device 104, to execute a copy of malware 130 to unpack a malware executable / payload, compromising the client device and causing it to become a bot in a botnet, etc. The compromised client device can then perform a task (e.g., cryptocurrency mining or participating in a denial-of-service attack) and can be instructed to 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 / compromised 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 packed malware content from Alice's client device 104, thereby preempting and preventing any such download of malware 130 to Alice's client device 104. As described further below, data appliance 102 executes the disclosed techniques for sample traffic-based self-learning malware detection, as described further below, to detect and block such malware 130 from harming Alice's client device 104.

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

[0056] As described in more detail below, security platform 122 can also receive copies of malware 130 from data appliance 102 to perform cloud-based security analysis to perform sample traffic-based self-learning malware detection, and the malware verdict can be sent back to data appliance 102 to enforce security policies, thereby protecting Alice's client device 104 from execution of malware 130 (e.g., blocking malware 130 from access on client device 104).

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

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

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

[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 physical machine including commercially available server-class hardware (e.g., a multi-core processor, 32+ gigabytes of RAM, and one or more gigabit network interface adapters) running commercially available virtualization software such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the virtual machine server is omitted. Furthermore, the virtual machine server may be under the control of the same entity that manages security platform 122, but may also be provided by a third party. As one example, the virtual machine server may rely on EC2, while the remainder of security platform 122 is provided by dedicated hardware owned and under the control of the operator of security platform 122. VM server 124 is configured to provide one or more virtual machines 126-128 for emulating client devices. The virtual machines may run various operating systems and / or versions thereof. Observed behavior resulting from running applications within the virtual machines is logged and analyzed (e.g., for indications that the application is malicious). In some embodiments, the log analysis is performed by a VM server (e.g., VM server 124). In other embodiments, the analysis is performed at least in part by other components of security platform 122, such as 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 the subscription via a list of signatures (and / or other identifiers). For example, the security platform 122 can periodically (e.g., daily, hourly, or at some other interval and / or based on events configured by one or more policies) send a content package identifying malware files, including network traffic-based heuristic IPS malware detection. One exemplary content package includes a Cobalt Strike Beacon (CSB) detector 154 and / or other information (e.g., ML-based detection models), as described further below. The subscription can cover analysis of only files intercepted by the data appliance 102 and transmitted by the data appliance 102 to the security platform 122, and can also cover malware signatures known to the security platform 122. As 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, platform 122 may utilize CSB detector 154 (e.g., a C2M L model, which may be implemented as a plug-in or subcomponent of platform 122, as further described below with respect to Figures 4A and 4B), which may help data appliance 102 detect potentially new / variant C2 malware (e.g., Cobalt Strike Beacon C2 HTTP / HTTPS traffic) and perform inline 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, analysis system 300 utilizes a list, database, or other collection of known good content and / or known bad content (collectively shown in FIG. 3 as collection 314). Collection 314 may be obtained in various ways, including via a subscription service (e.g., provided by a third party) and / or as a result of other processing (e.g., performed by data appliance 102 and / or security platform 122). Examples of information included in collection 314 include: 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., there is no existing signature associated with the sample in the analysis system 300), it is added to the queue 302. As shown in Figure 3, an application 130 is received by the system 300 and added to the queue 302.

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

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

[0070] Once static analysis is complete, coordinator 304 locates an available dynamic analysis engine 310 to perform dynamic analysis on the application. Similar to static analysis engine 306, analysis system 300 can directly include one or more dynamic analysis engines. In other embodiments, dynamic analysis is performed by a separate dynamic analysis server that includes multiple workers (i.e., multiple instances of 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 C2 malware detection described above based on monitored network traffic activity). In some embodiments, the results of the static analysis (e.g., performed by static analysis engine 306), whether in report format (308) and / or stored in database 316 or otherwise, are provided as input to dynamic analysis engine 310. For example, static report information may be used to help select / customize the virtual machine instance used by dynamic analysis engine 310 (e.g., Microsoft Windows 7 SP2 vs. Microsoft Windows 10 Enterprise, or iOS 11.0 vs. iOS 12.0). When multiple virtual machine instances run simultaneously, a single dynamic analysis engine can manage all of the instances, or, if applicable, multiple dynamic analysis engines may be used (e.g., each managing its own virtual machine instance). During the dynamic portion of the analysis, actions taken by the application (including network activity) are analyzed, as described in more detail below.

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

[0073] The environment used by analysis system 300 is instrumented / hooked so that behaviors observed while the application is running are logged as they occur (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 may be stored as temporary files in analysis system 300, or may be stored more permanently (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 connections made by the sample to a list (314) of domains, IP addresses, etc., and determine whether the sample communicated (or attempted to communicate) with a malicious entity.

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

[0075] Cobalt Strike Beacon HTTP C2 Heuristic Detection

[0076] 4A illustrates portions of one exemplary embodiment of a detection system and quality check system for processing network traffic to perform Cobalt Strike Beacon C2 HTTP traffic detection, according to some embodiments. As also described above, in various embodiments, security platform 122 includes Cobalt Strike Beacon (CSB) detector 154. FIG. 4A illustrates subcomponents of CSB detector 154, including the following subcomponents: detection system 402 and quality check system 404.

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

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

[0079] The Cobalt Strike Beacon (CSB) detector 154 includes a detection system 402, which includes an HTTP logic check module (a subcomponent that can be implemented using, for example, Python or another high-level programming language) that implements a decision tree based on the source IP address (SrcIP), destination IP address (DstIP), and destination port (DstPort) associated with each new session and performs the following checks based on data statistics associated with each new session: As an initial logic check, the detection system 402 can determine whether there is a prior verdict stored in a fast match table, 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, processing proceeds to perform the following data statistics checks, which are stored in a data statistics table, as shown at 414. The following data statistics checks are performed for each session and stored in a data statistics table to perform behavior-based detection of Cobalt Strike Beacon C2 HTTP traffic (e.g., using heuristic-based techniques as described further below). In an exemplary implementation, the fast match table and data statistics table may be implemented using an in-memory data structure store, such as using an open source (e.g., Redis, publicly available at https: / / redis.io / ) or commercially available data store solution.

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

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

[0083] Third, it checks whether the MD5 hash value of the HTTP header is the same (e.g., the metadata, including cookies associated with the session, is the same for each compromised machine, and as a result, the MD5 of the HTTP header will be the same for each session and new communication to that C2 team server).

[0084] Fourth, check whether the HTTP header field amount (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 Toolkit design implementation).

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

[0086] Sixth, check whether the HTTP User Agent (UA) is a popular UA (e.g., a known / popular UA; 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 commonly associated with using known / popular UAs, and thus the HTTP network traffic attempts to simulate typical user traffic that would be associated with such known / popular UAs (e.g., commonly used web browsers such as Microsoft IE, Chrome, Mozilla, etc.).

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

[0088] At 418, the quality check system 404 performs validation of the results of the detection system 402 to determine whether any previous determinations were false positives or false negatives for Cobalt Strike Beacon C2 HTTP traffic. Specifically, the destination IP probing and validation module (e.g., a subcomponent) performs automated probing of the destination IP address by sending a custom HTTP request (e.g., a custom HTTP / HTTPS / DNS request) to the destination IP address. As shown at 420, the destination IP probing and verification module then determines whether the response includes a fingerprint associated with Cobalt Strike (e.g., the HTTP response data includes a default certificate provided by Cobalt Strike and / or the HTTP response matches a Cobalt Strike (CS) fingerprint. That is, in an exemplary implementation, the CS fingerprint is a default string included in response traffic from a CS team server; for example, when a client sends an HTTP request with a randomized URL to a CS team server, the team server returns an HTTP status code of 404 and the following exemplary header: Content-Type: text / plain\r\Gmt: Wed, 27 Feb 2019 14:43:19 nDate\r\nContent-Length: 0. Thus, as described further below with respect to various embodiments, "Content-Type: text / plain" and Content-Length: 0 can be used as a fingerprint to identify a CS team server), verifying the Cobalt Strike Beacon C2 HTTP Traffic (CS) verdict of network traffic / sessions communicating with the destination IP address.As one example, the quality check system can perform a malware IP address lookup to determine whether the DestIP is associated with Cobalt Strike Beacon-related malware (e.g., a known malware sample previously identified as Cobalt Strike Beacon-related malware based on previous malware analysis), and if so, can validate the verdict of the Cobalt Strike Beacon C2 HTTP traffic (CS). If not, the verdict is automatically changed from a CS verdict to a benign verdict (e.g., providing a feedback loop to improve the CS detection heuristics implemented in the detection system 402). Thus, the quality check system can validate the verdict to attempt to detect any false positives or false negatives for Cobalt Strike Beacon C2 HTTP traffic.

[0089] The disclosed techniques for a behavior-based and cross-session detection solution for performing Cobalt Strike Beacon C2 HTTP traffic detection facilitate a 90% detection improvement rate for detecting Cobalt Strike Beacon C2 HTTP traffic based on experimental / testing 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] 4B illustrates portions of one exemplary embodiment of a detection system and quality check system for processing network traffic to perform Cobalt Strike Beacon C2 HTTPS traffic detection, according to some embodiments. As also described above with respect to FIG. 4A, security platform 122 includes Cobalt Strike Beacon (CSB) detector 154. FIG. 4B also illustrates subcomponents of CSB detector 154, including the following subcomponents: detection system 402 and quality check system 404. However, as described further below, the HTTPS pre-filtering logic module / subcomponent and the HTTPS logic check module / subcomponent perform different pre-filtering and logic checks on HTTPS traffic (e.g., because HTTPS traffic headers / content are encrypted, separate heuristics are disclosed herein for automatically detecting Cobalt Strike Beacon C2 HTTPS traffic, as described further below).

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

[0093] Firewall 102 monitors network traffic on an enterprise network (including, for example, HTTP traffic in enterprise network 140 as shown in FIG. 1 ). As shown at 410, firewall 102 monitors the network traffic using a data plane and performs pre-filtering analysis of the network traffic using an HTTPS pre-filter module (e.g., a subcomponent). As shown at 412, the firewall 102 forwards traffic (e.g., a packet capture (pcap) file of network traffic associated with a session) to the detection system if the following pre-filtering analysis for HTTP traffic is hit (i.e., meets both of the following example criteria based on the Server hello random field value and includes “DOWNGRD” (e.g., this field value is present in Cobalt Strike Beacon C2 HTTPS traffic but is also associated with benign traffic, so this pre-filtering is used before further analysis performed using the detection system, described below, that checks for additional heuristics, which are selected to reduce the amount of traffic forwarded to Cloud Security 122 for further analysis to detect potential Cobalt Strike Beacon C2 traffic, as described further below). In particular, the pre-filtering module determines whether the Server Hello Random field value includes the “DOWNGRD” value: Based on experiments (eg, test results), pre-filtering reduces the amount of network traffic forwarded for further analysis by cloud security services, which is approximately only 0.002% of the total network traffic.

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

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

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

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

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

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

[0100] At 418, the quality check system 404 performs validation of the results of the detection system 402 to determine whether any previous determinations were false positives or false negatives for Cobalt Strike Beacon C2 HTTPS traffic. Specifically, the destination IP probing and validation module (e.g., a subcomponent) performs automated probing of the destination IP address by sending a custom HTTPS request (e.g., a custom HTTP / HTTPS / DNS request) to the destination IP address. As shown at 420, the destination IP probing and verification module then determines whether the response includes a fingerprint associated with Cobalt Strike (e.g., the HTTPS response data includes a default certificate provided by Cobalt Strike and / or the HTTPS response matches a fingerprint of Cobalt Strike (CS). That is, in an exemplary implementation, the CS fingerprint is a default string included in response traffic from a CS team server; e.g., when a client sends an HTTPS request with a client hello to a CS team server, the team server responds to the client with a server hello and server certificate, and by default, the certificate includes the CS keyword "Major Cobalt Strike." Thus, as described further 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 identifies the Cobalt Strike beacon C2 of the network traffic / session communicating with the destination IP address. Verify HTTPS traffic (CS) verdict.As one example, the quality check system can perform a malware IP address lookup to determine whether the DestIP is associated with Cobalt Strike Beacon-related malware (e.g., a known malware sample previously identified as Cobalt Strike Beacon-related malware based on previous malware analysis), and then the verdict of Cobalt Strike Beacon C2 HTTPS traffic (CS) can be validated. If not, the verdict is automatically changed from a CS verdict to a benign verdict (e.g., providing a feedback loop to improve the CS detection heuristics implemented in the detection system 402). Thus, the quality check system can validate the verdict to attempt to detect any false positives or false negatives for Cobalt Strike Beacon C2 HTTPS traffic.

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

[0102] Cobalt Strike Beacon HTTP C2 Heuristic Detection Example Use Case

[0103] FIG. 5A illustrates exemplary attributes associated with Cobalt Strike Beacon HTTP traffic used for heuristic detection, according to some embodiments. Referring to FIG. 5A, this exemplary network traffic shows an HTTP request header MD5 hash that is identical to the request URL, as shown at 502, and a cookie (e.g., coding base 64), as shown at 504, associated with the session for such Cobalt Strike Beacon HTTP traffic. Thus, this example illustrates network traffic that meets the pre-filtering criteria, as also described above with respect to FIG. 4A. First, a header value or URI length check matches the range of 171 bytes to 256 bytes. Second, the network traffic includes a header value or URI length field with base64 encoding and therefore matches one of these types of encoding: base64, base64url, netbios, netbiosu, or mask. As a result, this network traffic, indicated at 506, is forwarded to Cloud Security 122 for further analysis using CSB detector 154, as also described above with respect to FIG. 4A.

[0104] 5B illustrates additional exemplary attributes associated with Cobalt Strike beacon HTTP traffic used for heuristic detection, according to some embodiments. Referring to FIG. 5B, this exemplary network traffic illustrates fewer than 10 request header fields (i.e., there are only six request header fields in this example) associated with a Cobalt Strike (CS) HTTP request, as shown at 520, compared to a benign HTTP request at 522, which has a greater number of HTTP request header fields (i.e., more than ten request header fields). Thus, as shown at 520, this exemplary network traffic satisfies the fourth heuristic discussed above related to HTTP header field quantity (i.e., the number of fields included in the HTTP header is less than ten fields in the HTTP header), as also discussed above with respect to FIG. 4A.

[0105] 5C illustrates additional exemplary attributes associated with Cobalt Strike Beacon HTTP traffic used for heuristic detection, according to some embodiments. Referring to FIG. 5C, this exemplary network traffic shows an HTTP user agent that is a known user agent (UA) and does not have a custom header, as shown at 530. Thus, as shown at 530, this exemplary network traffic satisfies the sixth heuristic discussed above, which relates to whether the HTTP user agent (UA) is a known / popular UA, as also discussed above with respect to FIG. 4A.

[0106]

[0033] Figure 5D illustrates 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 at 540. Thus, as indicated at 540, this exemplary network traffic satisfies the fifth heuristic discussed above, which relates to whether the HTTP header does not include a custom header, as also discussed above with respect to Figure 4A.

[0107] Cobalt Strike Beacon HTTPS C2 Heuristic Detection Example Use Case

[0108]

[0033] Figure 5E illustrates additional exemplary attributes associated with Cobalt Strike Beacon HTTPS traffic used for heuristic detection, according to some embodiments. Referring to Figure 5E, as shown at 550, this exemplary network traffic indicates an HTTPS request in which the Server Hello Random field value includes the value "DOWNGRD," as similarly described above with respect to Figure 4B. As a result, as shown at 506, this network traffic is forwarded to Cloud Security 122 for further analysis using CSB detector 154, as similarly described above with respect to Figure 4B.

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

[0110]

[0047] Figure 5G illustrates additional exemplary attributes associated with Cobalt Strike Beacon HTTPS traffic used for heuristic detection, according to some embodiments. Referring to Figure 5G, as indicated at 570, this exemplary network traffic indicates the amount of SSL application data in the request direction, as similarly described above with respect to Figure 4B. Specifically, as similarly described above with respect to Figure 4B, a third check performed by the HTTPS logic module is to determine whether there is only one application request data in the request direction (e.g., 459 bytes in length) (e.g., a heuristic performed for each of these analyzed (12) sessions), which is another heuristic used as another indicator that this is likely 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] Example Process for Cobalt Strike Beacon HTTP C2 Heuristic Detection

[0113] 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 performed by the security platforms and techniques similarly described above, including the embodiments described above with respect to FIGS. 1-5G. In one embodiment, the process 600 is performed 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 may also be implemented and configured to perform the disclosed techniques), an SDN security solution, a cloud security service, and / or a combination or hybrid implementation of the foregoing described herein.

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

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

[0116] At 606, determining whether a subset of the HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity based on a plurality of heuristics is performed. 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, similar to that described above with respect to Figures 4A and 5A-5D.

[0117] At 608, an action is performed in response to detecting Cobalt Strike Beacon HTTP C2 traffic activity. 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 HTTP C2 traffic activity. Other example actions may include: Blocking access to destination IP addresses 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 associated with the destination IP addresses, alerting endpoint users and / or network / security administrators that an endpoint is associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity, quarantining endpoint devices associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity, identifying destination IP addresses, URLs, etc. associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity as malicious (or potentially malicious), and / or various other actions may also be performed based on policy.

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

[0119] 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 FIG. 7 is performed by the security platforms and techniques similarly described above, including the embodiments described above with respect to FIGS. 1-5G. In one embodiment, the process 700 is performed 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 may similarly be implemented and configured to perform the disclosed techniques), an SDN security solution, a cloud security service, and / or a combination or hybrid implementation of the foregoing described herein.

[0120] At 702, HTTPS network traffic is monitored at 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, pre-filtering of the monitored HTTPS network traffic is performed at the firewall to select a subset of the HTTPS network traffic for forwarding to the cloud security service. For example, the HTTPS pre-filtering module may perform heuristic analysis of the HTTPS network traffic to select a subset of HTTPS traffic sessions to forward to the cloud security service for further analysis, as similarly described above with respect to Figures 4B and 5E-5G.

[0122] At 706, determining whether a subset of HTTPS network traffic is associated with Cobalt Strike Beacon HTTPS C2 traffic activity based on a plurality of heuristics is performed. 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 FIG. 4B and FIG. 5E-FIG. 5G.

[0123] At 708, an action is performed in response to detecting Cobalt Strike Beacon HTTPS C2 traffic activity. 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 HTTPS C2 traffic activity. Other example actions may include: Blocking access to destination IP addresses 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 associated with the destination IP addresses, alerting endpoint users and / or network / security administrators that an endpoint is associated with the detected Cobalt Strike Beacon HTTPS C2 traffic activity, quarantining endpoint devices associated with the detected Cobalt Strike Beacon HTTPS C2 traffic activity, identifying destination IP addresses, URLs, etc. associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity as malicious (or potentially malicious), and / or various other actions may also be performed based on policy.

[0124] Probing to detect Cobalt Strike Team servers

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

[0126] Accordingly, various techniques are disclosed for probing (e.g., active probing) to detect Cobalt Strike Team servers. For example, the disclosed techniques utilize active probing of IP addresses 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 probe packets).

[0127] In some embodiments, a system / process / computer program product for probing for Cobalt Strike Team server detection includes monitoring Hypertext Transfer Protocol (HTTP), HTTPS, and / or Domain Name System (DNS) network traffic at a firewall, pre-filtering the HTTP, HTTPS, and / or DNS network traffic monitored at the firewall to select a subset of the HTTP, HTTPS, and / or DNS network traffic for forwarding to a cloud security service, performing HTTP, HTTPS, and / or DNS probing 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, the system / process / computer program product for probing for Cobalt Strike Team server detection further includes detecting Cobalt Strike Team servers by verifying a malware verdict of Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity.

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

[0130] In some embodiments, the system / process / computer program product for probing for Cobalt Strike Team server detection further includes: data statistics based on an 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, the system / process / computer program product for probing for Cobalt Strike Team server detection further includes performing validation of detected Cobalt Strike Beacon HTTP, HTTPS, and / or DNS C2 traffic activity based on active probing.

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

[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 forwarded / collected from a firewall monitoring the network traffic, as similarly described above with respect to FIGS. 4A and 4B. Next, the destination IP probing and verification module sends a crafted request (e.g., a crafted HTTP / HTTPS / DNS request) to the dst IP and port (e.g., the target). The destination IP 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 a fast match table (e.g., the fast match table of the detection system 402, as similarly described above with respect to FIGS. 4A and 4B). Otherwise (i.e., if there was 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 to Discover Cobalt Strike Team Servers

[0137] An exemplary implementation of 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 validation module sends a crafted precheck HTTP / HTTPS request to a dst IP and port (e.g., the target). An example of a crafted precheck HTTP / HTTPS request is: http[s]: / / [IP]:[Port] / index.html. The destination IP probing and validation module then checks / evaluates the response to the crafted precheck HTTP / HTTPS request. Specifically, if the following is received in the response from the target, it is considered suspicious (e.g., it may (likely) be a Cobalt Strike Team server), and further active probing and evaluation is performed. More specifically, the response includes a status code equal to 404, and the HTTP / HTTPS header includes the following fields and values: That is, "Date" and date value (e.g., "Wed, 9 Feb 2022 23:09:48 GMT"), "Content-Type", "text / plain", and "Content-Length": "0". Otherwise (e.g., these fields and values ​​are not present in the response from the target), it is determined that the target is not a Cobalt Strike Team server, and no further active probing and evaluation is performed, and the verdict is determined to be benign (and the fast match table may be updated in a similar manner as described above with respect to Figures 4A and 4B).

[0138] As a final pre-check operation of the HTTP / HTTPS probing logic, the destination IP probing and verification module sends a refined HTTP / HTTPS request to the target to download a beacon file. An exemplary refined final pre-check HTTP / HTTPS request includes a URL value of "Swb1" and is as follows: http[s]: / / [IP]:[Port] / Swb1. In this example, "Swb1" can be any four bytes that meet the following checksum requirements: the input string text is a four-byte URL value, and the four-byte URL checksum value is equal to 92 or 93 based on the platform, such as using the checksum algorithm shown in FIG. 8. FIG. 8 illustrates the checksum algorithm for probing 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 constructed final check HTTP / HTTPS request. If 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 has the first two bytes equal to 0xFC48 or 0xFCe8 (e.g., thus present in the Cobalt Strike shared code of the beacon file based on a heuristic analysis of the Cobalt Strike Team server's behavior and the contents of its beacon file). Otherwise (e.g., if the response does not match the above criteria), it is determined that the target is not a Cobalt Strike Team server, and further active probing and evaluation is not performed, and the verdict is determined to be benign (and the fast match table may be updated, as described above with respect to Figures 4A and 4B).

[0139] DNS Probing to Discover Cobalt Strike Team Servers

[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 DNS probing of the dst IP and port (e.g., target). As a final pre-check operation of the DNS probing logic, the destination IP probing and verification module sends a sophisticated DNS request to the target to download a beacon file. FIG. 9A illustrates an 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 with the domain aaa.stage.xxxx, as shown in FIG. 9A.

[0141] The destination IP probing and validation module then checks the contents of the DNS response from the target. If the target is a Cobalt Strike Team server, the response from the target returns a txt DNS record response with content beginning with "WYIIIIIIIIIIII" (as present in Cobalt Strike Base 64 encoding a shared code for the beacon file based on heuristic analysis of the Cobalt Strike Team server's behavior and the contents of its beacon file), as shown in FIG. 9B. FIG. 9B illustrates an exemplary DNS response to active probing of the target, according to some embodiments. Otherwise (e.g., the response does not match the above-described criteria), the target is determined not to be a Cobalt Strike Team server, and further active probing and evaluation is not performed, and a verdict is determined to be benign (the fast match table may be updated in the same manner as described above with respect to FIGS. 4A and 4B).

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

[0143] Example process of HTTP / HTTPS probing to detect Cobalt Strike Team servers

[0144] 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 performed by security platforms and techniques as also described above, including the embodiments described above with respect to FIGS. 1-8. In one embodiment, process 1000 is performed by the data appliance 102 as described above with respect to FIG. 1, the security platform 122 as 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 may also be implemented and configured to perform the disclosed techniques), an SDN security solution, a cloud security service, and / or a combination or hybrid implementation of the foregoing as described herein.

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

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

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

[0148] At 1008, 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 HTTP / HTTPS C2 traffic activity. Other example actions may include: Blocking access to destination IP addresses 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 associated with the destination IP addresses, alerting endpoint users and / or network / security administrators that an endpoint is associated with the detected Cobalt Strike Beacon HTTP / HTTPS C2 traffic activity, quarantining endpoint devices associated with the detected Cobalt Strike Beacon HTTP / HTTPS C2 traffic activity, identifying destination IP addresses, URLs, etc. associated with the detected Cobalt Strike Beacon HTTP / HTTPS C2 traffic activity as malicious (or potentially malicious), and / or various other actions may also be performed based on policy.

[0149] An example process for DNS probing to detect Cobalt Strike Team servers

[0150] 11 is a flowchart of a process for DNS probing to locate Cobalt Strike Team servers, according to some embodiments. In some embodiments, the process 1100 shown in FIG. 11 is performed by the security platforms and techniques similarly described above, including the embodiments described above with respect to FIGS. 1-7 and 9A-9B. In one embodiment, the process 1100 is performed 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 may also be implemented and configured to perform the disclosed techniques), an SDN security solution, a cloud security service, and / or a combination or hybrid implementation of the foregoing described herein.

[0151] At 1102, DNS network traffic is monitored at a firewall. For example, the firewall can utilize application identification to detect DNS traffic, as similarly described above with respect to Figures 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 forwarding to the cloud security service. For example, the DNS pre-filtering module may perform heuristic analysis of the DNS network traffic to select a subset of DNS traffic sessions to forward to the cloud security service for further analysis, as also described above with respect to Figures 4A-4B and 5A-5G and further described below.

[0153] An example implementation of a DNS pre-filtering operation, also shown at 410 in FIG. 4A, may be performed by a DNS pre-filter module implemented on firewall 102 by performing the following heuristic analysis: if the DNS request is a DNS txt record (e.g., dns.qry.type==16(txt record)), then 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 Figures 4A-4B, 5A-5G, and 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. 1. A system including a processor and a memory, The processor: Monitor Hypertext Transfer Protocol (HTTP) network traffic at the firewall. pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic for forwarding to a cloud security service; pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic for forwarding to the cloud security service includes performing a heuristic analysis of the HTTP network traffic to select the subset of the HTTP network traffic for forwarding to the cloud security service for further analysis to detect potential Cobalt Strike Beacon HTTP C2 traffic; the heuristic analysis of the HTTP network traffic is such that the firewall selects a subset of the HTTP network traffic for forwarding to the cloud security service for further analysis to detect potential Cobalt Strike Beacon HTTP C2 traffic; (1) whether the network traffic contains a predefined header value or a predefined URI length check that matches a range of 171 bytes to 256 bytes; and (2) whether the network traffic contains a header value or URI length field with an encoding that matches a predefined type of encoding, including one or more of the following encoding types: base64, base64url, netbios, netbiosu, or mask; determining 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 executed in the cloud security service; the cloud security service automatically determines whether a subset of the HTTP network traffic is associated with Cobalt Strike Beacon HTTP C2 traffic activity based on multiple heuristics, including performing a data statistical check to perform behavior-based detection of Cobalt Strike Beacon HTTP C2 traffic activity, including checking timestamps of at least the first 12 sessions to determine whether they are Gaussian or normally distributed; and, performing an action at the firewall in response to detecting the Cobalt Strike Beacon HTTP C2 traffic activity; It is structured as follows: The memory includes: coupled to the processor; and configured to provide instructions to the processor; system.

2. The detection system's high-speed match table stores previously detected Cobalt Strike Beacon HTTP C2 traffic activity. The system of claim 1 .

3. The detection system's fast match table stores 3-tuples of previously detected Cobalt Strike Beacon HTTP C2 traffic activity. The 3-tuple includes a source IP address, a destination IP address, and a destination port. The system of claim 1 .

4. storing data statistics based on the automated heuristic analysis of the subset of HTTP network traffic in a data statistics table of the detection system; The system of claim 1 .

5. The processor further comprises: performing validation of the detected Cobalt Strike Beacon HTTP C2 traffic activity; It is configured as follows: The system of claim 1 .

6. The processor further comprises: performing validation 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; It is configured as follows: The system of claim 1 .

7. The processor further comprises: performing validation of the detected Cobalt Strike Beacon HTTP C2 traffic activity based on probing of destination IP addresses associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity and using a fingerprint data store; It is configured as follows: The system of claim 1 .

8. 1. A method comprising: monitoring Hypertext Transfer Protocol (HTTP) network traffic at a firewall; pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic for forwarding to a cloud security service; pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic for forwarding to the cloud security service includes performing a heuristic analysis of the HTTP network traffic to select the subset of the HTTP network traffic for forwarding to the cloud security service for further analysis to detect potential Cobalt Strike Beacon HTTP C2 traffic; the heuristic analysis of the HTTP network traffic is such that the firewall selects a subset of the HTTP network traffic for forwarding to the cloud security service for further analysis to detect potential Cobalt Strike Beacon HTTP C2 traffic; (1) whether the network traffic contains a predefined header value or a predefined URI length check that matches a range of 171 bytes to 256 bytes; and (2) whether the network traffic contains a header value or URI length field with an encoding that matches a predefined type of encoding, including one or more of the following encoding types: base64, base64url, netbios, netbiosu, or mask; determining the Steps and 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 executed in the cloud security service; the cloud security service automatically determines whether a 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 statistical check to perform behavior-based detection of Cobalt Strike Beacon HTTP C2 traffic activity, including checking timestamps of at least the first 12 sessions to determine whether they are Gaussian or normally distributed; performing an action at the firewall in response to detecting the Cobalt Strike Beacon HTTP C2 traffic activity; A method comprising:

9. The detection system's high-speed match table stores previously detected Cobalt Strike Beacon HTTP C2 traffic activity. The method of claim 8.

10. The detection system's fast match table stores 3-tuples of previously detected Cobalt Strike Beacon HTTP C2 traffic activity. The 3-tuple includes a source IP address, a destination IP address, and a destination port. The method of claim 8.

11. storing data statistics based on the automated heuristic analysis of the subset of HTTP network traffic in a data statistics table of the detection system; The method of claim 8.

12. The method further comprises: performing a verification of the detected Cobalt Strike Beacon HTTP C2 traffic activity; The method of claim 8, comprising:

13. The method further comprises: performing validation 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 of claim 8, comprising:

14. The method further comprises: performing validation of the detected Cobalt Strike Beacon HTTP C2 traffic activity based on probing of destination IP addresses associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity and using a fingerprint data store; The method of claim 8, comprising:

15. A computer program stored on a tangible computer-readable storage medium, the computer program comprising computer instructions; The computer instructions, when executed, cause the computer to: monitoring Hypertext Transfer Protocol (HTTP) network traffic at a firewall; pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic for forwarding to a cloud security service; pre-filtering the monitored HTTP network traffic at the firewall to select a subset of the HTTP network traffic for forwarding to the cloud security service includes performing a heuristic analysis of the HTTP network traffic to select the subset of the HTTP network traffic for forwarding to the cloud security service for further analysis to detect potential Cobalt Strike Beacon HTTP C2 traffic; the heuristic analysis of the HTTP network traffic is such that the firewall selects a subset of the HTTP network traffic for forwarding to the cloud security service for further analysis to detect potential Cobalt Strike Beacon HTTP C2 traffic; (1) whether the network traffic contains a predefined header value or a predefined URI length check that matches a range of 171 bytes to 256 bytes; and (2) whether the network traffic contains a header value or URI length field with an encoding that matches a predefined type of encoding, including one or more of the following encoding types: base64, base64url, netbios, netbiosu, or mask; determining the Steps and 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 executed in the cloud security service; the cloud security service automatically determines whether a 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 statistical check to perform behavior-based detection of Cobalt Strike Beacon HTTP C2 traffic activity, including checking timestamps of at least the first 12 sessions to determine whether they are Gaussian or normally distributed; performing an action at the firewall in response to detecting the Cobalt Strike Beacon HTTP C2 traffic activity; performing a method comprising: Computer program.

16. The detection system's high-speed match table stores previously detected Cobalt Strike Beacon HTTP C2 traffic activity.

16. A computer program according to claim 15.

17. The detection system's fast match table stores 3-tuples of previously detected Cobalt Strike Beacon HTTP C2 traffic activity. The 3-tuple includes a source IP address, a destination IP address, and a destination port.

16. A computer program according to claim 15.

18. The computer program further comprises computer instructions: The computer instructions, when executed, cause the computer to: performing a verification of the detected Cobalt Strike Beacon HTTP C2 traffic activity; performing a method comprising:

16. A computer program according to claim 15.

19. The computer program further comprises computer instructions: The computer instructions, when executed, cause the computer to: performing validation 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; performing a method comprising:

16. A computer program according to claim 15.

20. The computer program further comprises computer instructions: The computer instructions, when executed, cause the computer to: performing validation of the detected Cobalt Strike Beacon HTTP C2 traffic activity based on probing of destination IP addresses associated with the detected Cobalt Strike Beacon HTTP C2 traffic activity and using a fingerprint data store; performing a method comprising:

16. A computer program according to claim 15.

Images