A tool that needs no introduction, widely favored by threat actors and extensively scrutinized by defenders. After years of observing and analyzing real-world compromises, the time has come to produce what we believe to be the most comprehensive threat hunting guide to Cobalt Strike ever published.

One of the most widespread and well-established approaches in this context is to produce an up-to-date list of IP addresses associated with Cobalt Strike, which is extremely valuable for Threat Intelligence teams, as it enables proactive monitoring and blocking that can disrupt post-exploitation activity across a wide range of adversaries, from ransomware operators to espionage-driven Advanced Persistent Threats (APTs).

Equally important, however, is to remember that threat hunting activities should not be limited solely to the identification of malicious infrastructure, but also to be able to identify the presence of Cobalt Strike implants inside the organization's perimeter, before an intrusion has the opportunity to escalate into a full-scale incident.

In recent years, a vast amount of research, analysis, and investigative work has been released on the tool and its C2 infrastructure, some of it exceptionally detailed and heavily referenced during the writing of this article, yet none has attempted to describe Cobalt Strike in its entirety. The goal of this work is to provide a holistic view of the tool, its architecture, and its operational use, while presenting combined hunting techniques aimed both at detecting malicious payloads within the perimeter in post-compromise scenarios and at identifying active command-and-control servers in the wild for preventive purposes.

Cobalt Strike Overview

Cobalt Strike remains one of the most prevalent post-exploitation frameworks in modern intrusion activity. Ransomware operators, in particular, make extensive use of its core capabilities to expand access, maintain persistence, and operationalize lateral movement within compromised environments. Its combination of speed, adaptability, and mature feature set has made it a natural choice for adversaries, and it is difficult to ignore its role in the sustained growth of ransomware campaigns observed in recent years. Several high-profile ransomware groups are known to depend heavily on Cobalt Strike as part of their operational workflow.

Although Cobalt Strike is a commercial adversary simulation platform designed for red team operations, it has long been pirated and repurposed by a broad spectrum of threat actors, ranging from financially motivated ransomware crews to espionage-oriented Advanced Persistent Threats (APTs). While many defenders have encountered Cobalt Strike payloads during incident response, those without hands-on operator experience often struggle to fully grasp the framework's internal components, execution model, and operational tradecraft.

At scale, hunting for Cobalt Strike beacons across large and heterogeneous environments presents a non-trivial challenge for threat hunting teams. But with that comes a great amount of creativity and opportunity.

At its core, Cobalt Strike functions as the command-and-control (C2) platform orchestrating adversary operations. The application is composed of two primary elements: the team server and the client. Both are distributed within the same Java Archive (JAR) file, with their behavior determined solely by the execution parameters supplied by the operator.

• The Team Server represents the command-and-control component of Cobalt Strike. It is responsible for accepting operator client connections, handling beacon callbacks from compromised hosts, and serving generic web requests used during operations.
  By default, the team server listens for client connections on TCP port 50050 and is designed to run exclusively on Linux systems.
• Operators interact with the team server through the Cobalt Strike Client. The client may be executed on the same host as the team server or connect to it remotely, and it is supported across Windows, macOS, and Linux platforms.

Beacon is the name of Cobalt Strike's default malware payload and is used to establish communication with the team server. Active callback sessions originating from compromised systems are also referred to as "beacons," a naming convention that ultimately gave rise to the malware family's name. beacon exists in two primary forms.

• The stager is an optional, lightweight beacon payload that allows operators to stage their malware deployment. In this model, an initial, minimal shellcode performs basic checks and then reaches out to the configured C2 infrastructure to retrieve the fully featured backdoor.
• The full backdoor may be executed via a beacon stager, delivered by an external loader malware family, or launched directly by invoking the default DLL export, ReflectiveLoader. Once resident in memory, the backdoor is capable of establishing communication with the team server using multiple transport mechanisms.

Loaders themselves are not beacon. Beacon refers specifically to the backdoor component, which is typically executed through an external loader, regardless of whether the staged or full variant is used. While Cobalt Strike includes a set of default loaders, operators frequently develop custom implementations using PowerShell, .NET, C++, Go, or any other technology capable of executing shellcode.

Cobalt Strike Capabilities:

Core Components

Listeners are the Cobalt Strike components responsible for handling inbound connections from payloads such as beacon to the team server. The framework supports multiple listener types and allows extensive customization within each protocol. Depending on the nature of the change, modifying a listener may require regenerating payloads, restarting the listener itself, or, in some cases, restarting the entire team server.

• HTTP and HTTPS listeners are by far the most commonly observed in real-world operations. Although Cobalt Strike ships with a default TLS certificate, this certificate is widely recognized by defenders and routinely flagged by enterprise security products. As a result, operators typically deploy valid certificates-often issued via services such as Let's Encrypt-to better blend C2 infrastructure into legitimate traffic patterns. Through the use of Malleable Profiles, discussed later in this article, operators can exert fine-grained control over the structure and behavior of beacon's network traffic, allowing it to closely resemble benign HTTP communications. Listener configuration also supports specifying multiple domains or IP addresses from which the team server will accept beacon callbacks, a capability commonly leveraged through redirector infrastructure, as well as defining custom Host header values to support domain fronting techniques.
• DNS listeners establish sessions by embedding command-and-control communications within DNS traffic for domains over which the team server is authoritative. Two operational modes are supported. In the default hybrid configuration, DNS is used as a beaconing channel while HTTP handles bulk data transfer. Alternatively, a pure DNS mode can be enabled, using standard A record queries for both beaconing and data exchange. While this approach is significantly slower, it avoids HTTPS entirely and can offer a stealthier communication path in constrained environments.
• SMB listeners operate as bind-style listeners and are most commonly employed for chaining beacons within compromised environments. In this model, a local port is opened on a targeted system, awaiting an inbound connection from an operator or another beacon instance. Raw TCP listeners follow a similar bind-style approach and provide a more recent alternative for chaining scenarios, offering flexibility when SMB-based communication is unavailable or undesirable.

Two additional listener types are encountered less frequently but exist to maintain interoperability with other tooling. Foreign listeners enable Metasploit Meterpreter sessions to be passed seamlessly into Cobalt Strike, facilitating operational continuity between the two frameworks. External C2 listeners, on the other hand, define an interface for reverse TCP communication, where the payload actively connects back to an external operator-controlled endpoint rather than waiting for an incoming connection, as is the case with traditional bind listeners.

Almost Everything Is Customizable

One of the defining characteristics of Cobalt Strike is the extent to which its behavior can be customized. Beyond default configurations, operators can significantly alter payloads, execution flow, memory obfuscation, post-exploitation capabilities, and network tradecraft through a combination of officially supported extension mechanisms.

This customization is primarily enabled through Arsenal Kits, Malleable C2 Profiles, Aggressor Scripts, and more recent extensions such as Beacon Object Files (BOFs) and in-memory .NET execution. Together, these components allow operators to reshape large portions of the framework, from how beacon communicates and executes to how post-exploitation actions are implemented and automated.

Disguise Techniques (anti-detection)

Redirectors

In many real-world deployments, beacons do not connect directly to the team server. Instead, operators frequently introduce one or more redirectors that terminate inbound connections and forward traffic to the underlying C2 infrastructure. This indirection provides several operational advantages, including the ability to rotate multiple domains for a single beacon, replace exposed or blocked redirectors without redeploying the team server, and leverage higher-reputation domains to help malicious traffic blend into normal network activity.

Redirectors also allow operators to selectively filter inbound traffic, blocking scanners, automated hunting tools, or other suspicious requests in order to shield the team server from exposure. While this defensive layer complicates analysis, it rarely eliminates all observable artifacts, and defenders can often still identify both redirectors and the associated team servers.

Domain Fronting

In its simplest form, a redirector may consist of nothing more than a cloud-hosted instance running a reverse proxy such as nginx. A more sophisticated and highly effective variant, however, is domain fronting. Domain fronting is a technique that conceals the true destination of a connection by routing traffic through the infrastructure of a Content Delivery Network (CDN). Originally documented as a method for bypassing internet censorship, it has since been adopted by multiple threat actors, including APT29, to mask command-and-control activity.

In a fronted HTTPS connection, the initial TLS session is established with a legitimate, high-reputation domain hosted by the CDN-the so-called front domain. Within the encrypted request, a secondary identifier, commonly conveyed via the HTTP Host header, instructs the CDN to forward the traffic to an operator-controlled backend. From a defender's perspective, the observed TLS session appears to terminate at the CDN and is protected by the CDN's legitimate SSL/TLS certificate.

Under these conditions, blocking access to the operator-controlled domain requires decrypting the HTTPS traffic to reveal the true internal routing destination, an approach that is often impractical in enterprise environments. Beyond the performance and operational costs associated with large-scale TLS interception, decryption may be infeasible altogether for certain CDNs. Some providers enforce certificate pinning on their SSL/TLS infrastructure, preventing interception through organization-trusted root certificates and further limiting visibility into fronted command-and-control traffic.

Masquerading

Masqueraded traffic is engineered to resemble communication with a legitimate service while, in reality, establishing a direct connection to infrastructure controlled by an operator. Fronted traffic, by contrast, is initially sent to a legitimate third-party service (typically a CDN) and only then forwarded internally to the operator's server. While both techniques aim to obscure command-and-control activity, the underlying routing behavior differs in ways that are often observable.

When the destination domain and the HTTP Host header match, the connection represents a standard, direct HTTP or HTTPS request. Divergence between these two values, however, is frequently indicative of deliberate obfuscation. If the Host header references a well-known, high-reputation domain (such as one appearing in the Alexa Top 1M) while the destination resolves elsewhere, the activity is more consistent with domain masquerading. If instead the Host header points to an endpoint associated with a CDN (for example, domains under *.azureedge.net) the traffic may represent domain fronting.

A number of publicly available resources exist to help determine whether a given domain supports fronting, and this repository includes a precompiled list of frontable domains organized by CDN provider. That said, such public lists should be treated with caution. CDN behavior changes over time, and fronting support is frequently restricted or removed, making manual validation a necessary step when assessing suspected fronted infrastructure.

Hunting InsideThe Perimeter (Detection)

Execution

A significant portion of Cobalt Strike's post-exploitation capabilities is implemented as Windows DLLs. When an operator invokes these built-in tools, Cobalt Strike spawns a temporary process and leverages rundll32.exe to load and execute the malicious code. Execution results are then relayed back to the active beacon session through inter-process communication mechanisms based on named pipes. This execution pattern makes command-line activity involving rundll32.exe a notable signal worthy of closer inspection, particularly instances where it is launched without meaningful arguments.

Named pipes serve as the transport channel used to return the output of post-exploitation actions to the beacon. By default, Cobalt Strike relies on a set of predictable pipe name patterns, which can be leveraged by defenders for detection and hunting purposes. Although the framework allows operators to arbitrarily rename these pipes through configuration of the malleable C2 profile, this customization is not commonly observed in practice. While trivial to implement, altering pipe names introduces additional operational overhead and is therefore often neglected by less disciplined actors.

The default named pipe patterns used by Cobalt Strike include the following, where the asterisk denotes a variable prefix or suffix:

• \postex_*
• \postex*ssh**
• \status_*
• \msagent_*
• \MSSE-*
• *-server

On Windows systems, named pipe creation and access can be captured through Sysmon events 17 and 18. It is important to note, however, that Sysmon does not log named pipe activity by default and must be explicitly configured to do so in order for these events to be available for analysis.

During its execution phase, Cobalt Strike performs several suspicious activities that can be leveraged as useful detection patterns in the hunting process, including the following:

• Rundll32.exe process with no command-line parameters_
• Rundll32.exe spawned by rundll.exe with loopback connections on a high random port_
• Multiple rundll32.exe processes spawned by a single powershell process._
• Multiple similarly-named processes spawned by a single powershell process._
• Powershell spawned by powershell_
• Powershell spawned by wmi (esp. if it contains BASE64 encoded commands_

Defense Evasion

Process injection is a recurring characteristic of virtually every Cobalt Strike-backed intrusion and is routinely observed across compromised environments. It is most commonly employed to inject malicious code into remote processes and, in many cases, into lsass.exe to facilitate credential extraction from memory. By injecting a payload into a remote process, operators effectively spawn a new execution context aligned with the security context of the target process, enabling privilege escalation or lateral movement under the guise of legitimate user activity.

Detection of Cobalt Strike's default process injection behavior can be achieved using Sysmon by correlating a sequence of specific event identifiers. In the canonical injection flow, you will typically observe:

• Event ID 10 - Process Access;
• Event ID 8 - CreateRemoteThread detected;
• Event ID 3/22 - Network query/DNS query (network related activity).

When these events occur in close temporal proximity, they can strongly indicate malicious injection activity associated with beacon execution.

Example process injection on remote process (RuntimeBroker.exe):

It is important to note that not all injection techniques generate the same telemetry. Alternative methods, such as process hollowing, do not rely on remote thread creation and therefore will not produce Event ID 8. As a result, detection strategies must account for multiple execution paths. Without enhanced visibility provided by Sysmon, identifying process injection through native Windows security logs alone remains extremely challenging, as the required low-level process interaction events are not consistently captured.

Credential Access

Following initial access with Cobalt Strike, one of the first tasks that operators take is to collect credentials and hashes from LSASS. This activity most commonly targets the Local Security Authority Subsystem Service (LSASS) in order to extract credential material from memory. Cobalt Strike provides multiple built-in mechanisms to facilitate this process. The hashdump command is used to retrieve stored password hashes, while the logonpasswords command invokes Mimikatz functionality to extract plaintext credentials and NTLM hashes directly from LSASS.

Unfortunately, this technique yields limited native telemetry. In most observed cases, the only consistently captured events are related to process lifecycle activity:

• Event ID 4688 - Process Creation (rundll32.exe loading the malicious DLL payload);
• Event ID 4689 - Process Termination (once execution completes).

Cobalt Strike beacon implant

This detection analytic focuses on adversary activity involving a Cobalt Strike beacon implant pivoting laterally and issuing commands over SMB through the use of named pipes. Cobalt Strike supports SMB-based communication by allowing operators to configure beacon to exchange data via named pipes, relying on a set of default pipe names that are frequently reused across intrusions. From a hunting perspective, analysis should prioritize identifying suspicious interactions with named pipes within the affected process tree, with particular attention to anomalous file or pipe-related activity that deviates from expected system behavior.

File_modifications_include:

('pipe\msagent*' || 'pipe\interprocess*' || 'pipe\lsarpc*' || 'pipe\samr*' || 'pipe\netlogon*' || 'pipe\wkssvc*' || 'pipe\srvsvc*' || 'pipe\mojo*' || 'pipe\postex' || 'pipe\status_' || 'pipe\msse-')

Powershell scripts import

Another common artifact left behind during a cobalt compromise is the following powershell command:

Where the command "IEX (New-Object Net.Webclient).DownloadString('[http://127.0.0\.]1:45246/')" is how Cobalt Strike manages imported PowerShell scripts within a Beacon session.

Abuse of rundll32.exe to spawn SQL Server Client Configuration Utility

A related execution pattern involves rundll32.exe spawning the SQL Server Client Configuration Utility (cliconfg.exe). This process relationship is commonly observed when Cobalt Strike abuses DLL search order hijacking as part of a User Account Control (UAC) bypass technique. In these cases, cliconfg.exe is leveraged as a trusted binary to load a malicious DLL from an attacker-controlled location, allowing code execution to proceed with elevated privileges while minimizing overt indicators of compromise.

parent_process == rundll32.exe
&&
process == cliconfg.exe

Privilege Escalation via GetSystem

This detection analytic highlights command-line patterns commonly observed when Cobalt Strike beacons escalate privileges using the GetSystem feature. In this execution path, operators leverage GetSystem to impersonate a token associated with the SYSTEM account, enabling actions that exceed standard administrative privileges and facilitating deeper control over the compromised host.

In practice, this technique results in a distinctive command-line invocation pattern. The escalation process relies on cmd.exe to echo a hexadecimal token into a named pipe, which is subsequently consumed by the beacon process to complete the privilege escalation workflow. This interaction creates a narrow but reliable detection opportunity when command-line logging is available.

A representative analytic can be constructed by monitoring for cmd.exe executions where the command line matches the following pattern:

process == cmd.exe
&&
command_includes ('/(?i)echo\s+[0-9a-f]{11}\s+\>\;?\s+\\\\\.\\pipe\\[0-9a-f]{6}/.match')*

This regular expression captures the characteristic structure produced by GetSystem execution. An example of such activity, as generated by a Cobalt Strike beacon, is shown below:

C:\Windows\system32\cmd.exe /c echo 92d8cc45954 >; \\.\pipe\446b3c

[](file:///.\pipe\446b3c)

When observed in context, particularly alongside prior beacon execution artifacts and named pipe activity, this pattern can serve as a strong indicator of SYSTEM-level privilege escalation via Cobalt Strike.

Useful Resources

If you want to deep more into internal threat hunting activities, you can take a look at the following resources:

• Awesome-CobaltStrike-Defence: collection of hunting and detection tools for Cobalt Strike.
• Cobalt Strike Beacon Decoder: useful for forensics activities, in the case a beacon is found.

Hunting Outside The Perimeter (Prevention)

After making sure that there are no "friendly" malicious payloads already lurking inside the environment, it is time to turn our attention to prevention.

The goal is to identify Cobalt Strike command-and-control servers that are active in the wild, with the intent of preemptively blocking them and preventing the infection chain from progressing should contact with this type of payload occur.

Over the past few years, a wide range of techniques has been proposed, dissecting the entirety of HTTP and DNS responses associated with Cobalt Strike configurations and typically relying on Shodan during the server identification phase.

In my experience, however, many of these approaches lack sufficient precision or reliability. Some rely on artifacts that are common to a broad set of services, including legitimate ones, resulting in a high volume of false positives that are difficult to distinguish in practice. Others focus on indicators that are too fragile and easily modified by operators, ultimately rendering the detection technique more theoretical than operational.

For this reason, the following selection is not intended to be exhaustive, but instead includes what I consider to be the most effective techniques for achieving the intended objective:

• Shodan Product:"Cobalt Strike Beacon"
• SSL certificates and serial numbers
• Default port 50050 + Banner hash
• JA3 fingerprint
• JA3S fingerprint
• JARM TLS fingerprint
• Watermark (License ID)

1. Shodan Product:"Cobalt Strike Beacon"

This is the most straightforward and also the most precise technique (in term of false-positives).

Since it is able to perform detection, Shodan allows to filter on "Cobalt strike beacon" as a product. At the time of writing over 250 Cobalt Strike servers have been detected. China, Hong Kong, and the US are the main involved countries:

2. SSL certificates and serial numbers

Cobalt Strike is shipped with a default SSL certificate used for HTTPS communication. This self-signed certificate has no real place in a mature or well-run operation, yet it continues to appear in a significant number of real-world Cobalt Strike deployments.

One of the most straightforward ways to identify Cobalt Strike beacon controllers is to search for the SHA-256 or SHA-1 fingerprints of this default certificate, or for its associated SSL serial number.

Default certificate:

md5:950098276A495286EB2A2556FBAB6D83
sha1:6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C
sha256:87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390CDefault Serial number:
ssl.cert.serial:146473198

In practice, searches based on certificate hashes and serial numbers yield identical results, as the two fields are intrinsically linked. When matched, these indicators provide a relatively high level of confidence, since the SSL fingerprint is both unique and tightly associated with Cobalt Strike's default configuration.
That said, this technique is far from foolproof. The default certificate can be replaced with a legitimate one, or its characteristics altered through the use of a Malleable C2 profile, allowing operators to easily evade detections that rely solely on static SSL artifacts.

3. Default port 50050 and Banner Hash

By default, the Cobalt Strike team server listens for client connections on TCP port 50050. Taken in isolation, however, this characteristic is far too generic to be useful, as filtering solely on this port inevitably produces an overwhelming number of results.

To be operationally viable, this approach requires additional constraints. One effective refinement is to incorporate the banner exposed by the service. Each banner includes a hash field, which represents a numeric hash derived from the corresponding data field. The hashing algorithm used by Cobalt Strike-documented elsewhere-can be leveraged as a secondary filter, significantly reducing noise and improving the reliability of the results.

4. JA3 and JA3S fingerprint

JA3 is an open-source technique designed to generate TLS fingerprints by observing the parameters exchanged during SSL/TLS communication between clients and servers. These fingerprints are derived from a combination of values extracted from the Client Hello packet and can, in some cases, be used to characterize specific implementations.

Following the introduction of JA3, an analogous approach was developed to fingerprint the server side of the TLS handshake by analyzing the Server Hello message. This technique, commonly referred to as JA3S, is based on collecting the decimal values of selected fields within the Server Hello packet, including the TLS version, the negotiated cipher suite, and the list of supported extensions.

In theory, JA3S fingerprints extracted from known Cobalt Strike C2 infrastructure can be clustered and used to expand the search space by identifying servers that exhibit similar characteristics. In practice, however, this approach quickly runs into the same limitations seen with JA3. The resulting datasets tend to be noisy, and without strong additional constraints, the risk of generating an excessive number of false positives remains high. As a result, this technique falls outside the scope of this article.

5. JARM TLS fingerprint

Similar to JA3 and JA3S, JARM is designed to fingerprint TLS behavior by actively interacting with a remote server. Rather than passively observing traffic, JARM sends a series of ten crafted TLS Client Hello packets and records specific attributes from the corresponding responses. These values are then hashed to produce a single JARM fingerprint that can be used for comparison and clustering.

When applied to Cobalt Strike infrastructure, JARM results are closely tied to the Java runtime used by the team server. According to Cobalt Strike documentation, OpenJDK 11 is the recommended version for operators, which leads to a relatively consistent fingerprint across default deployments. While this consistency can help narrow down potential Cobalt Strike servers, it also introduces a significant limitation: a large number of legitimate internet-facing services rely on the same Java version, making false positives unavoidable.

In a default configuration, Cobalt Strike produces the following JARM fingerprint:

07d14d16d21d21d00042d41d00041de5fb3038104f457d92ba02e9311512c2

Additional JARM fingerprints associated with Cobalt Strike deployments have been observed and documented elsewhere. Even so, this technique should be treated strictly as a supporting signal. On its own, JARM is insufficient as a primary method for identifying command-and-control servers in the wild, and its results are best interpreted as an indication that an IP may be related to Cobalt Strike activity.

Another important consideration is that JARM fingerprints are not immutable. As demonstrated by Raphael Mudge, server-side configuration changes can materially alter the resulting fingerprint, further reducing its reliability when used in isolation. For this reason, it is often more effective to combine JARM with other data points available in large-scale internet scanning datasets, such as fuzzy JARM hashes, service banners, and TLS serial numbers or certificate hashes, to improve overall confidence.

6. Watermark (License ID)

One piece of information that often proves valuable during the analysis of intrusions involving Cobalt Strike is the watermark parameter embedded within the beacon configuration. This identifier is a numeric value derived from the Cobalt Strike license file and, when present, can be used to correlate multiple intrusions or campaigns back to the same operator or threat actor.

In practice, a large number of observed deployments use a watermark value of 0, a pattern commonly associated with pirated versions of Cobalt Strike distributed through underground forums. While this value offers little in terms of attribution, non-zero watermarks have historically provided useful context when combined with other intelligence.

Several watermark values have been publicly attributed to specific threat actors or malware ecosystems:

• 305419896: has been linked to an affiliate of the Maze ransomware group;
• 1359593325: has been observed in TrickBot-related operations;
• 1580103814: has been associated with BazarLoader activity;
• 688983459: is associated with the version 4.10;
• 1580103824: reported by CERT-UA;
• 987654321, 666666666, 391144938: associated with "Cobalt Strike products" on Shodan.

As with all single indicators, watermark values should not be treated as definitive attribution on their own. When used in conjunction with infrastructure patterns, payload characteristics, and operational tradecraft, however, they can contribute meaningful context to broader investigative and attribution efforts.

Conclusions

Throughout this article, we approached Cobalt Strike from two complementary angles: the detection of beacon implants operating within the perimeter and the identification of external command-and-control infrastructure in the wild. Infrastructure-based detection without internal visibility leaves defenders blind once a foothold is established, while endpoint-only hunting ignores the preventive value of disrupting C2 before it is ever reached.

Despite the framework's extensive customization options, operators frequently rely on familiar patterns, reused profiles, and infrastructure that changes far less than expected. This operational inertia consistently creates detection opportunities for defenders who prioritize tradecraft, behavioral consistency, and longitudinal analysis over one-off indicators.

Ultimately, hunting Cobalt Strike is not about identifying a specific tool or configuration, but about recognizing the behaviors it enables across different stages of an intrusion. When approached from this perspective, Cobalt Strike becomes a tractable problem, one that can be methodically observed, understood, and disrupted.

References

Mandiant - Defining Cobalt Strike Components So You Can BEA-CONfident in Your Analysis

Hunting Cobalt Strike Servers

Red Canary - Cobalt Strike threat detection

Microsoft - Hunting for Cobalt Strike: Mining and plotting for fun and profit

The DFIR Report Cobalt Strike, a Defender's Guide - Part 1

The DFIR Report - Cobalt Strike, a Defender's Guide - Part 2

Unit42 - Cobalt Strike Analysis and Tutorial: Identifying Beacon Team Servers in the Wild

Salesforce - Easily Identify Malicious Servers on the Internet with JARM

Mandiant - SCANdalous! (External Detection Using Network Scan Data and Automation)

MITRE ATT&CK - Cobalt Strike

GitHub/MichaelKoczwara - Awesome-CobaltStrike-Defence

GitHub/CAPE - Beacon Config Decoder