Analysing a Cobalt-Strike Beacon

Before diving into a detailed analysis of this malware sample, I will begin with an initial enumeration phase to gather basic intelligence and identify key characteristics. Using tools such as Detect It Easy (DIE) and CFF Explorer, I will examine the file structure, compiler information, packing techniques, metadata, and other indicators that may provide valuable insights before proceeding with deeper static and behavioral analysis.

After analyzing the file's magic bytes, I confirmed that the sample is a Windows Portable Executable (PE) file. The next step was to identify whether the binary was protected or obfuscated using any known packers.

By reviewing the binary's entropy levels, which remained below 7.0, I determined that the sample does not appear to be packed. A lower entropy value generally indicates that the file maintains a more natural structure rather than containing heavily compressed or encrypted sections commonly associated with packers.

With the initial static checks completed, the next phase involves deeper reverse engineering using x64dbg. Since the binary is compiled for a 64-bit architecture, x64dbg will allow further analysis of the executable flow, API interactions, memory operations, and runtime behavior within a controlled analysis environment before executing any potentially malicious code.

I will click "RUN" Arrow key in the above tab until I go to the Entry Point of the malware sample in the x64dbg

Now I'll add 2 breakpoints on the 2 commonly used API's in malware which are "VirtualAlloc" and "VirtualProtect" using the x64dbg command line.

Using the 'bp' command which are commands in the debugger I was able to add breakpoints in those to API's in the Malware Sample.

The above analysis confirms that breakpoints have been successfully placed on the targeted API calls within the sample. The primary objective of this debugging approach is to identify the memory region allocated during runtime by the VirtualAlloc API.

By tracing the execution flow and using the "Execute Until Return" functionality in x64dbg, I can follow the API call execution and locate the returned memory address. This allows me to inspect the allocated buffer, analyze its contents, and understand how the malware manages memory during execution.

As shown in the debugger, the execution has reached the applied breakpoint successfully. At this stage, the focus is to retrieve and analyze the memory buffer allocated by the triggered API call.

By examining the function return values and the allocated memory region, I can identify the buffer address, inspect its contents, and determine how the sample utilizes dynamically allocated memory during execution. This step is important for understanding the runtime behavior and potential payload handling mechanisms of the binary.

The above image shows that I have successfully executed the program from the "VirtualAlloc" API to the next RETURN function. Next highlight the memory address on the RAX register and right click on it and follow the DUMP.

After a hectic process, I was able to find the Allocated memory of the sample which is filled with Null bytes. :)

As you can see the whole memory sector is filled with null bytes since the "VirtualAlloc" allocated the required memory buffer to allocate the shellcode.

MONITORING MEMORY WITH HARDWARE BREAKPOINTS

After the VirtualAlloc API completes execution, it successfully creates the memory buffer, which has now been identified. To monitor any modifications made to this allocated memory region during runtime, the next step is to configure a Hardware Breakpoint.

A hardware breakpoint allows us to track access or modifications to a specific memory address without modifying the binary itself. To configure it, I select the first byte of the allocated buffer, right-click on the address, navigate to Breakpoints → Hardware Access → Byte, and apply the breakpoint.

This will allow me to monitor when the sample reads from or writes to the allocated buffer, providing visibility into how the malware modifies memory during execution.

After setting up the breakpoint I will continue running the malware in the debugger hoping to get something interesting stuff in the buffer.

After continuing the execution, I encountered the well-known 0xFC byte, which indicates that the allocated memory region may contain shellcode or a dynamically generated payload intended for execution.

To retrieve the complete payload, I will continue execution using the "Execute Until Return" option. This allows the routine responsible for populating the allocated buffer to complete, revealing the full contents written into memory. Once the buffer is fully populated, I can extract and analyze the shellcode to understand its behavior and execution flow within the sample.

Next, I will validate the extracted shellcode by disassembling the contents of the allocated memory region. The objective of this step is to identify the instructions, execution flow, API interactions, and any loops or routines implemented within the shellcode.

By analyzing the disassembly, I can better understand the shellcode's functionality, including how it initializes, resolves required functions, and performs its intended actions during runtime.

VALIDATE THE SHELLCODE BY DISASSEMBLING

Since we are still treating this extracted buffer as a potential shellcode, the next step is to validate it through disassembly. By analyzing the raw bytes stored in the memory region, we can determine whether they represent valid executable instructions rather than random data.

To perform this validation, I will right-click on the 0xFC byte and select "Follow in Disassembler". If the bytes successfully translate into meaningful assembly instructions without disassembly errors, it provides further confirmation that the buffer contains executable code.

After following it in the disassembler I was able to find the assembly code with valid functions and loops with no error which makes me confirm that this is a shellcode.

Next, I will use a shellcode analysis tool, Speakeasy, to emulate the extracted shellcode in a controlled environment. The purpose of this step is to observe the shellcode's behavior without executing it directly on a real system.

Through emulation, I can monitor the shellcode's execution flow, API calls, memory operations, and other runtime activities to better understand the functionality and intent of the malicious sample.

EMULATING THE SHELLCODE WITH THE SPEAKYEASY

To emulate the shellcode safely, the extracted payload first needs to be saved from the allocated memory region into a separate memory dump for further analysis.

To do this, I will select the 0xFC byte and choose "Follow in Dump" to navigate to the corresponding memory region. From there, the shellcode bytes can be reviewed, extracted, and prepared for analysis within the emulation environment.

I will save the dump as "cobalt.bin" for further analysis using SpeakyEasy.

Using the below command I am able to emulate the shellcode in the system to get more information about it.

After executing the emulation process, I observed that the shellcode initiated outbound network connections to a remote command-and-control (C2) server. The communication was established using standard Win32 API calls, indicating direct system-level networking behavior.

Additionally, the traffic included a custom User-Agent string embedded by the malware, which is often used to blend malicious requests with legitimate-looking HTTP traffic or to fingerprint infected systems. This confirms that the shellcode is not only executable in memory but also actively designed for remote communication and control.

The observed User-Agent, IP address, and other extracted indicators of compromise (IOCs) can now be leveraged for threat hunting across multiple environments. These artifacts can be used to identify potential infections by correlating them with proxy logs, firewall logs, endpoint telemetry, and network traffic records.

Additionally, the same IOCs can be submitted to threat intelligence platforms and search engines to determine whether the infrastructure or behavior has been previously reported. This enables broader visibility into the malware’s footprint and helps in assessing its prevalence, attribution, and potential impact across different environments.

SUMMARY

In this analysis, I examined a Cobalt Strike Beacon, a commonly used post-exploitation implant designed to establish covert communication with a Command-and-Control (C2) server and retrieve additional payloads, such as a dropper.

Using x64dbg, I performed dynamic analysis to observe the beacon’s runtime behavior, carefully tracing memory allocation, execution flow, and shellcode injection routines. This allowed me to reverse-engineer key components of its functionality and extract the embedded shellcode for further inspection.

To validate and understand the payload’s behavior in a controlled environment, I leveraged advanced emulation techniques using Speakeasy. This enabled safe simulation of the shellcode’s execution, providing visibility into its API usage, network communication patterns, and operational intent without risking direct execution on a live system.

Through this process, I was able to identify critical indicators of compromise (IOCs), including network artifacts and behavioral signatures, which can be used for threat hunting across proxy logs, firewall logs, and threat intelligence platforms to detect and respond to potential infections.