Cobalt Strike is an advanced adversary-simulation and penetration-testing tool widely used for both legitimate red teaming and malicious cyber attacks. Malware authors favor Cobalt Strike because of its rich feature set, customizable attack infrastructure, and powerful post-exploitation capabilities.

Why Do Malware Authors Use Cobalt Strike?

  • Powerful Payloads: The Beacon provides remote access, in-memory execution, and a wide range of post-exploitation features similar to custom backdoors.
  • Flexible C2 Communications: Attackers can disguise malicious traffic and make detection difficult for defensive tools by using malleable profiles and covert channels.
  • Rapid Deployment: Ready-made modules allow attackers to quickly set up implants, escalate privileges, and move laterally. This reduces development time and increases reliability.
  • Persistence & Evasion: Built-in features help attackers maintain persistence and evade security controls, enabling long-term control over compromised hosts.
  • Real-World Attack Simulation: Because Cobalt Strike is commonly used for red team assessments, attackers use it to mimic professional testing, which can confuse defenders during real incidents.

In summary, Cobalt Strike’s robust toolkit, stealth, and extensibility have made it popular among both ethical hackers and cybercriminals. As a result, it is widely used for initial access, lateral movement, and data exfiltration in both simulated and genuine attacks.

File Info

MD5: 076f518e35024cb62211e317081464b0

SHA-1: 9bddcd07059c1aad8ad0bc85877e996cac87b7fb

SHA256: 79eb0b7d16a706047cb43ce294e6d8deaea0868e879fbdbab32d9aba8ccb69b4

File Size: 316.50 KB

File Type: Win32 executable 

Technical Analysis:

Figure 1: File Info image

How Does Pipe Server Communication Happen in Cobalt Strike?

  • Creation: The pipe server process uses a function like CreateNamedPipe to create a named pipe, which acts as a communication endpoint.
  • Connection: The server then waits for a client process to connect to the pipe using the pipe’s name. Functions such as ConnectNamedPipe are used to wait for the client to establish a connection.
  • Communication: Once connected, the server and client can exchange data. The server writes to the pipe, while the client reads from it (and vice versa for two-way pipes).
  • Disconnection: The server can disconnect from the client and create a new instance of the pipe to handle the next client or manage multiple clients simultaneously using threads or asynchronous operations.
Figure 2: Named Pipe Server IPC Handler
Figure 3: ReadFile API 
Figure 4: WriteFile API 

The above Fig. 2 shows disassembly/code focused on operations involving Windows Named Pipes, which are commonly used for inter-process communication and often exploited by malware for C2 or payload delivery.

The following WinAPI functions are called in sequence:

  • CreateNamedPipeA – Creates the named pipe: \\.\pipe\MSSE-7904-server
  • ConnectNamedPipe – Waits for a client connection on the pipe
  • WriteFile – Writes data to the connected pipe
  • CloseHandle – Closes the pipe handle

During execution, ConnectNamedPipe waits for a client connection. Once connected, the code is structured to use ReadFile to receive data from the client, and then uses WriteFile to send data from the server side.

Analysis shows that the named pipe \\.\pipe\MSSE-7904-server is a known indicator of compromise associated with the post-exploitation tool Cobalt Strike. Specifically, it relates to Cobalt Strike’s default Artifact Kit binaries used for loading a backdoor into memory.

How does Payload load in memory?

The next function call is VirtualAlloc, a high-level Windows API function that internally calls the lower-level native system call NtAllocateVirtualMemory to allocate virtual address space. VirtualAlloc provides a simplified interface for reserving or committing memory, while NtAllocateVirtualMemory handles the core operation of managing the virtual memory pages in the process’s address space. This layering allows applications to work with virtual memory without interacting directly with the low-level system call.

Figure 5: NtAllocateVirtualMemory image

After returning from the function, we directly encounter the decryption loop. The following image shows this process.

Figure 6: Decrypted loop & CreateThread image

After the decryption loop ends, a PE image file is obtained in the allocated memory space.

Figure 7: PE image loaded in memory

“Basically, during execution, the loader allocates virtual memory, decrypts the next stage into it, adjusts memory protections by changing the protection to PAGE_EXECUTE_READ, and creates a thread to execute the decrypted code.” (as depicted in Figure 7)

After dumping the PE image loaded in memory, we further analyzed the PE file, which revealed that the file is a DLL image.

Figure 8: File Characteristics image

We examined the executable’s memory dump and analyzed its strings to find connections with our dynamic analysis. During this investigation, we found a reference to “beacon.dll,” which is likely the DLL version of the Cobalt Strike beacon. When we loaded the PE file into PeStudio, we also discovered an export named “_ReflectiveLoader@4,” a well-known export for Cobalt Strike DLLs. This export is typically associated with reflective DLL injection, allowing the beacon to be loaded directly into memory without touching the disk. This behavior is common for Cobalt Strike payloads and is a strong indicator of its presence in the sample.

Figure 9: String dumper in PE studio

Analysis of the Disassembly for beacon.dll

Now that we know this exported function is typically used in reflective DLL injection, we moved on to analyze the beacon.dll itself.

Analysis of the Disassembly of DOS stub for beacon.dll in below image –

Figure 10: Disassembly dump image of Dos Structure

The instructions indicate that this is x86 (32-bit) code.

  1. Typical prologue patterns are present, such as dec ebp, pop edx, push edx, and inc ebp, along with unusual function call patterns.
  2. The instruction at offset 0x6A0009 is an immediate call to a distant address, which is commonly seen in position-independent shellcode or reflective DLL injection for resolving runtime addresses.
  3. The instruction add ebx, 0x9cb7 followed by call ebx suggests that the code dynamically calculates the exported function to call for further execution after locating or loading a payload.

This behavior is characteristic of malware employing runtime address resolution and dynamic code execution.

In the above Fig. 10, we directly obtain the exported function call, and we calculate it as shown below.

Figure 11: Calculate export function address

After adding 6A0009 and 9CB7 (hardcoded value), the execution jumps to the exported function. Now we have obtained the actual exported function offset, as shown in the images below (Fig.12)

Figure 12: ReflectiveLoader image at the runtime
Figure 13: ReflectiveLoader image after separately loaded in debugger

Comparing both files (Fig. 12 and Fig. 13) after dumping them separately, you can see that the same instructions are loaded.

How does beacon get user info?

Figure 14: Host System Profiling and Beacon Identification Builder

This routine describes a system reconnaissance and identification builder. Its purpose is to collect details about the infected environment, such as the username, computer name, module (process) file name, and OS version, and then format these into a structured string for exfiltration, reporting, staging, or unique identification.

Figure 15: Taking User & Device name

The ReflectiveLoader also parses the host process’s kernel export table to calculate the addresses of three functions required by the loader: LoadLibraryA, GetProcAddress, and VirtualAlloc.

Figure 16: dynamic API resolver code

The code adds an offset (result += 251;) to store API addresses, likely as part of stealth or obfuscation. The presence of an API resolver like this strongly indicates attempts to execute payloads without relying on the Import Address Table (IAT).

Figure 17: API loaded on stack for further execution

How does a web session communication happen?

Figure 18:Wininet C2 Connection Initialization Routine, Session Customization and  HTTP Option Setter (A)
Figure 19: Wininet C2 Connection Initialization Routine, Session Customization and  HTTP Option Setter (B)

The file is using InternetOpenA, InternetConnectA, and InternetSetOptionA api for HTTPS connections in the Wininet library. The code also manages flags, buffers, and agent strings typically required for flexible, configurable malware networking.​ Such blocks are standard in many families of malware for backdoor activity that need to establish stealthy web-based C2 channels.

This type of code block describes the Wininet session customization and connection handler stub. It focuses on configuring WinInet session or connection parameters (such as buffer sizes, timeouts, headers, or proxy information) right after connecting to a remote server. Such routines are often called: 

The file uses the APIs InternetOpenA, InternetConnectA, and InternetSetOptionA from the Wininet library to establish HTTPS connections. The code manages flags, buffers, and agent strings typically required for flexible and configurable malware networking. Such blocks are standard in many malware families for backdoor activity that requires establishing stealthy web-based C2 channels. This type of code block describes the Wininet session customization and connection handler stub. It focuses on configuring Wininet session or connection parameters — such as buffer sizes, timeouts, headers, or proxy information — right after connecting to a remote server. Such routines are often called session customization or connection handler stubs.

Figure 20: Domain has connect with InternetConnectA api
Figure 21: Domain Image

In the above Fig.21, we get the domain “146.56.251.111”. also we get the browser user agent string Mozilla/5.0 (Macintosh; Intel Mac OS X 11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6307.206 Safari/537.36 suggesting that it checking the browser name, version, operating system, and other details like the device type.

This routine is typically called an HTTP C2 communication stub or network beaconing implementation.

Figure 22: HttpsendRequestA api image

In the above Fig.22, HttpSendRequestA is used to send an HTTP request to a server. Then the request is sent to the server, and it creates an active session.

Figure 23: Session image

In the above Fig.23, you can see that the string loaded on the stack is visible in the debugger and memory views as contiguous ASCII in buffers. It is pushed onto the stack immediately before an HTTP request. The session information ensures that each HTTP request sent is tracked and associated with the same infected host for C2 operations or data uploads. This design allows the malware to masquerade as normal web traffic, often bypassing proxies, firewalls, and network monitoring with minimal risk of detection, especially when user-agent strings and session patterns closely mimic those of a legitimate browser.

User impersonation activity code in beacon

Figure 24: Token Impersonation and Privilege Escalation Handler

This function is a token impersonation handler. It manages and escalates privileges by impersonating users on the system and is commonly seen in post-exploitation or lateral movement malware modules.

Key Routines:

  • WaitForSingleObject: Waits for a handle to be signaled, likely ensuring synchronization before processing the token.
  • ImpersonateLoggedOnUser: Attempts to impersonate a user if a valid token handle is available.
  • TokenHandle assignment and error handling: Designed to enable reliable privilege escalation or task automation, including fallback mechanisms to handle errors gracefully.
Figure 25: User Impersonation Routine

This function describes a domain user logon and impersonation handler. It attempts to log on as a provided user, impersonate them, and then execute further post-authentication actions — all classic behaviors of credential theft, privilege escalation, or lateral movement modules.

  • LogonUserA: Attempts to authenticate using the supplied domain, username, and password.
  • ImpersonateLoggedOnUser: If successful, the thread impersonates the provided user context.
  • Domain, username, and password buffers are allocated and manipulated for further actions, likely related to token handling or command execution routines.

This function appears to be performing credential validation and impersonation, for credential theft or privilege escalation routine.

void __cdecl sub_1000E272(LPCSTR lpszDomain, LPCSTR lpszUsername, LPCSTR lpszPassword)

Also, to dissect the Cobalt Strike beacon, we use a Python package command to decode and reveal the beacon configuration. After executing the command, you can see the configuration window in the image below.

Figure 26: Cobalt Strike beacon configuration

Removal

  1. Reboot into Safe Mode with Networking.
  2. Use updated UltraAV. 
  3. Detected as following name by UltraAV: Trojan.W32.171025.CobaltStrike.YR
Figure 27: Threat Detection with UltraAV

Conclusion:

Cobalt Strike is a valuable tool for security testing when legitimately used, its widespread abuse by cybercriminals and advanced persistent threat groups makes it a significant concern in modern cybersecurity. Vigilance, timely detection, and continuous endpoint security updates are essential to defend against its misuse.

Indicators of Compromise

SHA-256: 79eb0b7d16a706047cb43ce294e6d8deaea0868e879fbdbab32d9aba8ccb69b4 (Parent process)

SHA-256:06c92ba05b2be5d7585941ef02f07f8335413f161af58dfa213a5c5a5fce25b6 (Beacon DLL)

C2 Domain: http://146.56.251.111/api/websessionindex/open/Lists.jsp