Cobalt Strike Operators Leverage PowerShell Loaders Across Chinese, Russian, and Global Infrastructure

While analyzing open directories during a routine threat hunting session, we discovered a suspicious PowerShell script (y1.ps1) hosted in an open directory on a server in China (IP: 123.207.215.76).

The script functions as a shellcode loader utilizing in-memory execution techniques to evade disk-based detection. It resolves Windows API functions dynamically and decrypts embedded shellcode, which acts as a downloader. First seen on June 1, 2025, the script triggered a deeper investigation into post-exploitation infrastructure.

This PowerShell loader reflects an active post-exploitation setup leveraging stealth techniques and Cobalt Strike infrastructure.

In this article, we break down how the shellcode operates, its evasion methods, and how we traced its connection to known Cobalt Strike infrastructure.

Key Takeaways

• The PowerShell script (y1.ps1) executes shellcode directly in memory using reflective techniques.

• It connects to a second-stage C2 server hosted on Baidu Cloud Function Compute.

• The shellcode employs API hashing and sets forged User-Agent strings to evade detection.

• The final payload communicates with a known Cobalt Strike IP address in Russia.

• SSL metadata and loader behavior confirm links to Cobalt Strike post-exploitation tools.

Introduction

The decrypted shellcode initiates a connection to a second-stage command-and-control server hosted on Baidu Cloud Function Compute (y2n273y10j[.]cfc-execute[.]bj.baidubce[.]com). It uses API hashing to obfuscate function names, sets a forged User-Agent string, and employs reflective DLL injection to load the payload directly into memory.

Analysis of the decoded payload configuration revealed a Cobalt Strike Beacon communicating with the IP address 46.173.27.142, associated with Beget LLC (Russia).

SSL metadata indicates a certificate subject of "Major Cobalt Strike" and issuer "cobaltstrike." These findings are consistent with known Cobalt Strike infrastructure and usage patterns in post-exploitation and threat actor activity.

While most of the IOCs in this case are linked to Chinese and Russian servers, we also identified a few hosted in the United States, Singapore, and Hong Kong. This suggests that although the core staging environment relies heavily on infrastructure in China and Russia, cloud platforms in other regions are occasionally used to support distribution.

Script Metadata

The y1.ps1 script was hosted in an open directory on a Chinese server with the following attributes:

• File Name: y1.ps1

• File Size: 4 KB

• Host IP: 123.207.215.76:80

• Host Attribution: Shenzhen Tencent Computer Systems Company Ltd. (China)

• Capture Time: 2025-06-01 12:06 UTC

Technical analysis

To further examine the file's behavior and context, we used our internal analysis tools.

The PowerShell script was discovered using the Attack Capture File Manager. The file was flagged as malicious and made publicly accessible via an open directory.

The PowerShell script is a shellcode loader designed to execute malicious code in memory, a technique often used by malware to evade detection. It begins by enabling strict mode to ensure clean execution, then defines two key functions: func_get_proc_address, which retrieves memory addresses of Windows API functions (like VirtualAlloc) from DLLs using reflection, and func_get_delegate_type, which dynamically creates a delegate to call functions in memory.

The main execution block, triggered on 64-bit systems, decodes a Base64-encoded byte array, decrypts it with an XOR operation, and allocates executable memory using VirtualAlloc. The decrypted shellcode is copied into this memory and executed via a delegate, bypassing disk-based detection.

Hunting PowerShell Cobalt Strike shellcode

We used Code Search with the keyword "func_get_delegate_type", a function often associated with reflective execution in PowerShell-based loaders, and filtered for files with the ".ps" extension. This returned 129 results and helped uncover a set of suspicious scripts, along with the hostnames serving them. Identifying this pattern was key in linking the loaders to active Cobalt Strike infrastructure.

One of the retrieved scripts stood out for deeper inspection, leading us to examine its embedded shellcode.

Decrypting shellcode

We returned to the script and used CyberChef to decode the embedded shellcode. The payload was Base64-encoded and XOR-decrypted using a key of 35.

This shellcode functions as a downloader designed to connect to a remote server hosted on Baidu's Cloud Function Compute platform (y2n273y10j[.]cfc-execute[.]bj[.]baidubce[.]com). Its main job is to fetch and run a second-stage payload.

Evasion Technique: API Hashing

Instead of including API function names directly in the code (which would be easy to spot in a static analysis), the shellcode calculates a unique hash for each function it needs. It compares these calculated hashes to pre-computed values hardcoded into the shellcode. When it finds a match, it retrieves the corresponding function's address and calls it.

The hashing algorithm processes each character of the function name by converting it to uppercase (making it case-insensitive), rotating the accumulated hash value 13 bits to the right, and adding the character's value.

This continues until the end of the name, producing a unique hash that hides the original function name.

The shellcode starts by setting up its execution environment. It walks through the Process Environment Block (PEB) to locate loaded DLLs. Then, using its hashing routine, it identifies key functions like LoadLibraryA and others that it needs for network communication.

Once it locates LoadLibraryA, it loads wininet.dll, a system library used for internet-related functions. From there, it resolves APIs like InternetOpenA, laying the groundwork for contacting its command and control (C2) server.

C2 Communication

The shellcode initiates an HTTPS connection (port 443) to its C2 server at y2n273y10j.cfc-execute.bj.baidubce.com using InternetConnectA. During this stage, it sets a custom User-Agent string that mimics legitimate browser traffic:

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; yie9)

Below is an assembly snippet showing the actual call to InternetConnectA, used by the shellcode to initiate the HTTPS C2 connection.

Receiving And Executing Payload

After the connection is established, the shellcode sends an HTTP request using HttpOpenRequestA and HttpSendRequestA, with options set via InternetSetOptionA. It includes a retry loop that tries up to 10 times if the connection fails.

Once successful, it uses VirtualAlloc to create a memory region with read, write, and execute permissions. It then downloads the payload directly into this memory space using InternetReadFile.

Finally, the shellcode jumps to the start of the memory region and executes the downloaded payload.

Following the execution analysis, we investigated whether the script or its payload was associated with known Cobalt Strike infrastructure.

PowerShell Cobalt Strike Beacon

After analyzing the PowerShell scripts, we identified several encoded beacons associated with CobaltStrike loaders. An example of one such beacon is shown in the following figure.

Cobalt Strike Loader

After decoding the Cobalt Strike loader, we observed that it implements a reflective DLL loading technique, which allows a DLL to be loaded directly from memory without relying on the standard Windows loader.

Cobalt Strike Beacon C2

During analysis of the payload configuration, we extracted the command-and-control (C2) address 46.173.27.142.

This IP is associated with Beget LLC under ASN 198610, and geolocated to Russia (RU). Historical data from our platform indicates the IP was both first and last seen on May 28, 2025, suggesting short-lived or time-sensitive activity.

The C2 node operated over port 50050, and SSL certificate metadata reveals the Subject/Common Name as "Major Cobalt Strike", with the Issuer Organization listed as "cobaltstrike", strongly indicating usage of a Cobalt Strike Beacon.

This infrastructure aligns with known Cobalt Strike deployment patterns used in post-exploitation and red team operations, as well as by threat actors leveraging cracked versions of the framework.

To understand the broader infrastructure footprint, we queried our certificate dataset for other Cobalt Strike indicators.

Hunting Cobalt Strike C2 via SSL

The query "Certificates.IssuerOrganization:cobaltstrike" returns 801 IP addresses. These are systems with SSL certs showing "cobaltstrike" as the issuer. Since Cobalt Strike gets abused constantly by hackers, these IPs are likely command-and-control servers actively used to manage attacker infrastructure.

These findings reinforce the presence of an actively maintained, evasive post-exploitation framework leveraging Cobalt Strike infrastructure.

Summary

We uncovered a simple but effective delivery method for Cobalt Strike using a PowerShell loader hosted in an open directory. The loader executed entirely in memory, contacted a cloud-based C2 server, and relied on evasion techniques like API hashing and reflective DLL loading.

What made this stand out wasn't the techniques themselves, but how quietly they were combined. By tracing code patterns and SSL certificate metadata, we linked the activity to known Cobalt Strike infrastructure and exposed part of a broader setup likely used in post-compromise operations.

While attribution remains unclear, the use of cracked Cobalt Strike beacons and ephemeral infrastructure is consistent with techniques observed in financially motivated threat campaigns.

Recommended Mitigation Strategies

To reduce the risk of similar attacks, start by tightening PowerShell usage. Set execution policies to restrict unsigned scripts and enable logging to capture suspicious activity. Look out for unusual commands, such as Add-Type or custom memory allocation.

• Block known malicious IPs and domains, especially 46.173.27.142 and the Baidu Cloud endpoint used in this case. Watch for strange outbound traffic, especially with fake User-Agent strings that mimic browsers.

• Use a good EDR solution that can catch in-memory attacks and reflective DLL loading. Turn on Windows Defender's Exploit Guard and ASR rules to stop common post-exploitation techniques.

• Monitor for SSL certificates with names like "cobaltstrike"-they're often a giveaway. Deploy all known IOCs (IPs, domains, certificates) across your security tools and hunt through historical logs.

• Limit internet access from sensitive machines, and train users not to run unknown scripts or access unsecured web directories. Disable scripting tools like PowerShell if they're not needed.

Cobalt Strike IOCs

PowerShell Scripts

Cobalt Strike C2

Cobalt Strike Open Directory Hosts