The Complete Guide to Hunting Cobalt Strike - Part 1: Detecting Cobalt Strike in Open Directories

Welcome to the first post in our series on hunting Cobalt Strike. We started where many real investigations begin, on the open web.

Using AttackCapture™, we scanned exposed directories and pulled real files attackers left behind: PowerShell loaders, shortcut lures, and configuration scripts used in active campaigns. By connecting those files to SSL certificates and live hosts, we mapped a broad set of Cobalt Strike servers.

In this chapter, we show how to discover Cobalt Strike in open directories with AttackCapture™ - using targeted filename searches to map deployments, certificates, and fingerprint pivots to connect infrastructure, and practical ways to validate findings.

Open Directories: A Goldmine for Malware Detection

Open directories are one of the most overlooked sources of threat intelligence. When attackers leave staging environments or servers exposed, they often reveal files that show exactly how their operations work. These can include payloads, encoded PowerShell scripts, or configuration files that point straight to live C2 servers.

Unlike logs or telemetry, open directories contain artifacts used by real operators. That makes them invaluable for understanding active campaigns and how different clusters of infrastructure relate to each other.

AttackCapture™: Exposing the Exposed

AttackCapture™ is a continuous scanning engine built for the exposed web. It crawls open directories and public repositories looking for attacker tooling, payloads, and configuration files that many operations accidentally leave online. Every item it captures is enriched with metadata such as filenames, file hashes, directory paths, SSL certificates, and infrastructure links.

Because it focuses on what attackers themselves publish rather than what defenders detect afterward, AttackCapture™ gives early visibility into live adversary activity. It surfaces files before they’re widely reported and allows analysts to pivot instantly from a single “loader.ps1” to certificate subjects, directory structures, and live hosts. For example, the Hunt.io research team used AttackCapture™ to detect the full ERMAC banking trojan 3.0 source code in an open directory weeks before it was reported in the media.

Now, with AttackCapture™ as our starting point, let’s dive into how we used it to uncover deployments of Cobalt Strike in exposed directories - through filename searches, certificate and fingerprint pivots, and focused detection queries.

Detecting Cobalt Strike with AttackCapture™

We began by searching public repositories and exposed web directories in AttackCapture™ for signs of Cobalt Strike activity. Using simple filename searches, we quickly surfaced hundreds of results showing how widespread the framework remains across active operations.

Filename search

When you search for "CobaltStrike" in the AttackCapture™ system, the tool scans exposed servers and public databases looking for any files that contain this name or a related pattern, as you can see from the following screenshot:

The search discovered 404 configuration files related to Cobalt Strike deployments. These files include user credential files, password storage files, shell scripts, VBS scripts, batch files, and various configuration components.

Each file listed shows important metadata such as the filename, directory location, file size, and timestamp of discovery. Looking through those configuration files helps analysts trace how attackers deploy their tools, spot live servers, and move quickly to disrupt them.

To broaden context beyond filenames, we ran a malware name search to see how those artifacts map to confirmed instances in our data.

Malware name search

When searching for "Cobalt" as a malware name in the AttackCapture™ threat intelligence database, the system returns 1,224 distinct malware instances associated with Cobalt Strike, illustrating how widespread its use remains globally.

Each result shows an IP address and port representing either a C2 server or a compromised endpoint.

The timestamps show detections ranging from early 2024 through late 2025, highlighting continuous global activity. Many of these C2 servers are hosted on major cloud providers such as Alibaba, Tencent, and Amazon AWS.

Since automated matches can be noisy, we narrowed the set with manually verified labels to isolate high-confidence C2 servers.

Label-based verification

In a label-based search for the past 30 days, we focused on infrastructure that has been manually verified and tagged as Cobalt Strike C2 servers. This approach returned 76 confirmed servers, representing infrastructure analyzed and validated.

The results include IP addresses, associated ports, and timestamps showing that these C2 servers remained active over the last month, confirming the ongoing deployment of Cobalt Strike across multiple campaigns.

As the previous examples show, finding exposed Cobalt Strike servers in open directories is straightforward with AttackCapture™. From that verified set, we picked a representative server to walk a full pivot end-to-end.

Infrastructure analysis

We will perform a focused infrastructure analysis on one of the identified servers: 47.103.218[.]35. This analysis will examine live/last-seen timestamps, associated ports, related hosts, and any discovered deployment artifacts to map the server's role in Cobalt Strike operations. Specifically, we will collect all C2 addresses associated with Cobalt Strike activity and then investigate each C2 for exposed/open directories (web-accessible folders or files) that could reveal configuration files, or payloads.

Pivot via Certificates of Cobalt Strike

Certificates help connect services that look separate at first glance, so we examined certificate metadata next.

Threat intelligence flagged 47.103.218[.]35 as "High Risk" due to confirmed Cobalt Strike activity running on port 8080. The IP has an operational history going back to December 12, 2023, with continuous activity recorded through October 4, 2025.

This shows consistent use of this infrastructure to maintain access to victim networks. The host also runs additional services, including SSH on port 22, HTTP on port 9080, PostgreSQL on port 5432, and other HTTP services on ports 14322 and 14323. This suggests the IP functions as a multi-purpose command infrastructure node supporting both C2 operations and reconnaissance activities.

Certificate analysis of 47.103.218[.]35 reveals further confirmation of its role in Cobalt Strike operations. The IP is associated with 77 x.509 certificates, including multiple certificates explicitly labeled "Major Cobalt Strike" in their subject and issuer fields.

Additional certificates show US-based subjects and issuers, likely used as cover for the C2 infrastructure. This certificate pattern is typical of Cobalt Strike deployments, where operators use legitimate-appearing SSL certificates to disguise malicious C2 communications as encrypted web traffic.

Once we confirmed those repeated certificate patterns, the next step was to turn that intelligence into something repeatable. We built a HuntSQL™ query that automatically surfaces any host using similar Cobalt Strike-related certificates.

Creating a Hunting SQL rule for Cobalt Strike

To identify additional Cobalt Strike C2 infrastructure, a certificate intelligence query was executed searching for "Major Cobalt Strike" certificates and known malicious certificate hashes across the past 300 days.

The query searched the global certificate database for any IP addresses using certificates with the issuer name "Major Cobalt Strike" or matching specific certificate fingerprints known to be associated with Cobalt Strike deployments.

SELECT
  ip,
  port,
  min(timestamp),
  max(timestamp)
FROM
  certificates
WHERE
  (
    subject.common_name == "Major Cobalt Strike"
    OR certificate_hash == "87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390C"
    OR certificate_hash == "56A06A233BD30F693DE25EF12CC19E8B2C92D3EB97DD969A2578DF084C376478"
  )
  AND timestamp > NOW - 300 DAY
GROUP BY
  ip,
  port

                
Copy

This search returned 3,355 unique IP and port combinations globally, indicating the widespread deployment of Cobalt Strike infrastructure across multiple threat actors and campaigns.

Investigating open directories of Cobalt Strike C2

Within these results, suspicious IP addresses appeared multiple times across different ports with continuous Cobalt Strike certificate activity. After running the 3,355 Cobalt Strike C2 results through our Bulk Extract and Enrich feature, we found that 173 servers (5.2 percent) had open directories exposing internal operational data.

Captured malware components

Drilling into one exposed folder revealed a compact set of files that shows the attacker's workflow end to end.

Going back to our initial AttackCapture™ discovery, the exposed directory from one compromised C2 server (141.98.197.31[:]81) includes six malware components totaling 10 MB. The delivery files (Master.lnk and SetupOffice.lnk) are Windows shortcuts designed to trick users through social engineering, while 111.out is a Linux ELF executable designed to target Unix-based systems.

The payload.txt contains the encoded PowerShell Cobalt Strike script with GZIP compression and XOR encryption. Setup_office.exe acts as a Cobalt loader disguised as an Office installer to trick users into execution. Master.exe is the primary Cobalt Strike beacon executable that establishes a command and control connection, giving the attacker complete remote access to infected systems with full capabilities for data theft, persistence, and lateral movement across networks.

Examining the contents of one open directory uncovered multiple payloads, giving us a complete look at the first infection stage and how victims are initially compromised. Now we can dig into the first payload.

Analyzing the First Cobalt Strike Payload

Initial Infection Vector

The attack begins with an initial infection vector designed to download and execute a remote payload via PowerShell. Upon execution, the malicious LNK file triggers PowerShell from the legitimate system path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

The command embedded within the shortcut uses Invoke-WebRequest to download an executable named setup_office.exe from a remote host at http://141.98.197[.]31:81/setup_office.exe

The downloaded file is saved to the Windows directory (C:\Windows\setup_office.exe) and then executed using Start-Process, granting the attacker code execution on the victim's machine. From this point forward, the attacker has full control over the system.

Command and control communication

The malware creates a hidden communication channel using Windows named pipes. It starts by getting the current system tick count, which is a timestamp measurement of how long the system has been running. This tick count is used to generate a unique name for the communication pipe.

The malware constructs the pipe name by encoding special characters as individual decimal numbers. These numbers represent backslashes, dots, and letters that spell out a Windows named pipe path. The final name looks like " \\.\pipe\MSSE-XXXX-server" where XXXX is a random number generated from the system tick count. This randomization helps the malware evade detection because the pipe name changes each time the malware runs.

Once the pipe name is created, the malware spawns a new thread to handle incoming connections. This thread creates the named pipe and waits for external processes to connect to it. When a connection is established, the thread can receive data through the pipe without being easily detected by typical security monitoring tools.

Payload reception and injection

The malware receives encrypted payloads from an external command server through the named pipe communication channel. Malware uses the named pipe to listen for incoming data from a remote attacker.

When the malware receives the encrypted payload through the named pipe, it performs a multi-step process to execute it. First, it allocates memory space where it will store the decrypted payload. The memory is allocated with specific protection flags that make it executable, which is crucial for running injected code.

The malware then decrypts the received payload using an XOR cipher with a four-byte repeating key. For each byte of the encrypted data, the malware performs an XOR operation with the corresponding byte from the key. This is simple but effective encryption that can be quickly reversed when needed.

After decryption, the malware modifies the memory protection of the allocated region using the VirtualProtect function. This function changes the memory from standard readable state to executable state, allowing the decrypted code to be executed directly from memory.

The malware then creates a new thread pointing to this freshly decrypted and executable code. This spawned thread runs the injected payload with full system privileges. Because the payload runs in a separate thread, it operates independently from the main malware process.

Remote code execution

The complete chain of capabilities allows the malware to receive commands from a remote attacker, decrypt those commands, inject them into memory as executable code, and run them automatically. The attacker does not need to deploy additional files to the victim's disk. Everything happens in memory, making it harder for traditional antivirus solutions to detect the attack.

The malware includes functionality to read data from the named pipe communication channel. When the malware tries to connect to an incoming named pipe, it first attempts to open the pipe using a specific access mode that allows it to read data.

The malware then enters a reading loop where it continuously attempts to read chunks of data from the pipe. Each time a read operation succeeds, the code advances the buffer pointer and decrements the remaining byte count. This continues until all expected data has been received or the connection is closed.

Data reading from named pipes

The malware includes functionality to read data from the named pipe communication channel. When the malware tries to connect to an incoming named pipe, it first attempts to open the pipe using a specific access mode that allows it to read data.

The malware then enters a reading loop where it continuously attempts to read chunks of data from the pipe. Each time a read operation succeeds, the code advances the buffer pointer and decrements the remaining byte count. This continues until all expected data has been received or the connection is closed.

If the pipe connection is established successfully, the malware reads the entire payload and stores it in memory. Then it closes the pipe handle and continues with the decryption and execution process described above

Anti-analysis techniques

The next behaviors explain how the payload avoids inspection and stays active over time.

The malware uses several techniques to avoid detection and analysis. The named pipe name is randomized based on system time, making it difficult to set up detection rules based on specific pipe names.

The use of in-memory execution means that traditional file-based security scanning cannot detect the payload. The malware never writes the payload to disk, so tools that scan the file system will not find evidence of the attack.

Persistence and infinite operation

The malware enters an infinite loop after initialization, continuously sleeping for ten seconds and then checking for new commands through the named pipe. This allows the malware to remain dormant but responsive on the infected system indefinitely.

An attacker can keep the malware running for months or years without the victim knowing that the system is compromised. Each time the attacker has a new target or objective, they can send a new payload through the named pipe, and the malware will automatically execute it.

Beyond the first executable chain, we also found a second PowerShell-based payload designed for in-memory execution. This section breaks down how it decompresses, decrypts, and injects shellcode directly into memory.

Dissecting the Second Cobalt Strike Payload

Hidden delivery

When you receive this malware, it comes hidden inside a PowerShell command that looks like random characters. The command starts with "powershell -nop -w hidden -encodedcommand" followed by a very long string of random-looking text. This is the delivery stage.

The "-nop" flag means PowerShell will not load user settings. The "-w hidden" flag means the PowerShell window will not show on your screen, so you won't see anything happening. The "-encodedcommand" flag tells PowerShell that what follows is encoded (hidden) code. When PowerShell runs this command, it takes the long random string and decodes it using Base64 encoding, which converts the hidden text back into readable instructions.

The decompression and code injection

After the PowerShell command decodes the hidden text, it reveals compressed data. PowerShell then decompresses this data using GZIP compression. Once decompressed, the malware code is revealed. The malware code contains two special PowerShell functions designed to do technical things to your computer.

The first function, called "func_get_proc_address", finds secret Windows functions that normally only system administrators can access. The second function, called "func_get_delegate_type", creates a bridge between PowerShell and the lowest level of Windows, allowing PowerShell to run machine-level code directly.

After setting up these functions, the malware contains a large piece of code that is encrypted using XOR encryption. This encrypted code is first converted to Base64 text so it can be hidden in the PowerShell script. The malware then decrypts this code by taking each character and scrambling it with the number 35 using XOR encryption.

This reveals the real malicious machine code that will do the actual damage. This encrypted machine code is about 3,535 bytes long. The malware keeps this code hidden inside PowerShell's memory, never writing it to your hard drive, where antivirus software could find it.

The memory injection and execution

The malware now calls a Windows function called "VirtualAlloc" which is normally used to request memory space. However, the malware misuses this function to allocate a special memory space where it has permission to read, write, and most importantly, execute code.

It requests memory with special parameters that tell Windows to allow code execution, which is normally restricted for security reasons. The malware then copies the decrypted machine code into this allocated memory space.

Once the code is in memory, the malware executes it by calling it as a function. The malware takes the memory address where it stored the code and treats it like a function, then immediately calls it to run. The machine code runs with the same permissions as your user account, and sometimes even with higher system privileges.

Finally, the malware checks if your computer is a 32-bit or 64-bit architecture. If it detects a 64-bit system, it runs the code in 32-bit compatibility mode. This switching between 32-bit and 64-bit execution is a technique to evade detection.

Once this check is done, the malware either runs the code directly (if 32-bit) or spawns a new 32-bit PowerShell process running in the background (if 64-bit) to execute the code.

The Cobalt Strike shellcode

Shellcode is the lowest level of machine code that runs directly on your computer's processor. It is raw binary instructions that tell your CPU exactly what to do, byte by byte. The shellcode contains several important parts embedded inside it.

The shellcode first finds several Windows functions it needs. These include LoadLibraryA and GetProcAddress for loading and resolving libraries, InternetOpenA, InternetConnectA, HttpOpenRequestA, HttpSendRequestA, and InternetReadFile for network activity, plus CreateProcessA and WriteFile for starting processes and writing data.

Inside the shellcode, there is a User-Agent string that says "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)". When the malware connects to the internet, it pretends to be an Internet Explorer web browser on Windows Vista. This disguises the malware's internet connection to look like normal web browsing.

At the end of the shellcode, there is an IP address: 141.98.197[.]31. This is the attacker's command and control server. Once this shellcode executes, it will connect to this IP address and wait for commands. The shellcode also contains port 7785, which is the port number where the Cobalt Strike server is listening for connections from infected computers.

When the shellcode runs, it first locates all the Windows functions it needs by reading the Windows system libraries in memory and finding the addresses of each function. The shellcode then uses InternetOpenA and InternetConnectA functions to connect to the command and control server at 141.98.197[.]31 on port 7785. It uses the fake User-Agent string to disguise itself as a web browser.

Once connected, the shellcode enters a loop where it constantly checks for new commands from the Cobalt Strike server. The attacker can send commands like download a file, execute a program, steal files, take screenshots, record keystrokes, dump passwords, spread to other computers, delete files, or encrypt files for ransomware. Whatever command the Cobalt Strike server sends, the shellcode executes it immediately.

After executing each command, the shellcode sends the results back to the Cobalt Strike server. The shellcode keeps the connection open and maintains it continuously. If the connection drops, the shellcode reconnects automatically. This ensures the attacker always maintains access to your computer.

Together, these two payloads show the full infection lifecycle of a Cobalt Strike operation. The following mitigation steps translate those findings into concrete defensive actions.

Mitigation strategies

• Track certificate reuse linked to Cobalt Strike infrastructure. Several servers in this campaign shared identical certificate subjects and fingerprints labeled "Major Cobalt Strike." Add these fingerprints to your monitoring systems and alert when new hosts present the same values. Certificate overlap was one of the clearest signals of related C2 activity.

• Secure or disable open directories. About 5% of identified Cobalt Strike servers exposed web directories containing payloads, configuration files, and shortcut lures. Prevent similar exposure by disabling directory listing and restricting public access to any folder hosting administrative or executable files.

• Detect encoded PowerShell activity. The initial stage relied on PowerShell with -encodedcommand, -nop, and -w hidden flags to download and execute payloads like setup_office.exe. Enable detailed PowerShell logging and alert when these flags appear together.

• Monitor named pipe creation. The beacon established randomized named pipes such as \\.\pipe\MSSE-<random>-server for internal command exchange. Log named pipe creation events and flag unusual patterns not tied to legitimate Windows services.

• Identify memory injection sequences. The loader used VirtualAlloc and VirtualProtect to execute decrypted code in memory. Watch for these API calls initiated by PowerShell or unknown binaries, especially when combined with network connections to suspicious ports.

• Review network traffic for fake browser headers. The shellcode used a User-Agent string mimicking Internet Explorer (MSIE 9.0) and connected over uncommon ports like 7785, 8080, and 14323. Filter outbound HTTP traffic for these signatures to catch active beacons.

• Correlate filenames, certificates, and ports. Multiple open directories contained similar files (setup_office.exe, Master.lnk, payload.txt). Combine filename indicators with certificate fingerprints and port data to uncover connected infrastructure.

• Block known indicators of compromise. All IPs, domains, and certificates listed in the IOC table are confirmed to be part of active or historical Cobalt Strike infrastructure. Import these indicators into your blocklists or enrichment pipelines to immediately reduce exposure and detect related activity.

Cobalt Strike IOCs

The following indicators were confirmed during this investigation. These IOCs represent a mix of some active samples and historical Cobalt Strike infrastructure observed through AttackCapture™.

If you want access to the full IOC list or a step-by-step HuntSQL™ pack to ingest into your SIEM, request it here: https://hunt.io/contact-us

MITRE ATTACK MATRIX

To provide a broader context, we mapped every observed behavior to the MITRE ATT&CK framework, showing where defenders can align detections across tactics and techniques.

All of these elements (from exposed directories to reused certificates and encoded PowerShell) connect to a consistent Cobalt Strike playbook that defenders can detect and disrupt using the same methods.

Conclusion

Cobalt Strike continues to be one of the most widely abused frameworks used for post-exploitation and command-and-control. Our analysis of more than three thousand servers showed how small details (like reused certificates, encoded PowerShell loaders, and exposed directories) can reveal entire clusters of attacker infrastructure.

AttackCapture™ allowed us to rebuild live operations from open web folders and link them to specific certificates, ports, and hosts. The result is a high-confidence set of IOCs that defenders can use to block and hunt with precision.

If you want to try these searches yourself, open a free Hunt.io account to explore AttackCapture™ or book a demo to see how it works in real time.