Deep Malware Analysis of a Multi-Stage Cobalt Strike Loader

Network Investigation Walkthrough & Crypto Analysis

We first focused on the decrypted HTTPS traffic recorded by Joe Sandbox:

Before manually validating the network traffic, the most valuable starting point was the Stage 3 highlights identified by Joe Reverser. These results clearly indicated which parts of the implant were worth tracing in the debugger.

At a high level, the Stage 3 network execution path is:

This suggested a clear roadmap for the traffic analysis:

• understand how the request is constructed
• understand how the diagnostics field is decoded and decrypted
• understand the command path and the function it maps to

The observed network activity consists of short HTTP GET requests structured as follows:

GET /rest/funcStatus?_=<payload> HTTP/1.1

Using x64dbg, we identified that the API responsible for constructing this request is HttpOpenRequestA, which is used to set parameters within the HTTP GET query string. By tracing back the call stack, we determined that the caller is the function FUN_00700abc.

We then continued our analysis on this function using Joe Reverser to better understand how the payload is constructed. The results are summarized below:

Based on this analysis, the data flow can be described as follows:

128-byte input payload → XOR with a prepended 4-byte key → URL-safe Base64 encoding

The next step was to continue tracing this chain backward to identify the origin of the 128-byte input payload.

To do this, we again used Joe Reverser to move further up the call chain and determine where the input originates. The result is insightful:

The encryption path can be described as follows:

input data → RSA-1024 + PKCS#1 v1.5 padding encryption → 128-byte payload → XOR with prepended 4-byte key → URL-safe Base64 encoding

By placing a breakpoint at the start of the encryption routine, we observed the plaintext payload before it was processed. At this point, the buffer passed in RDX contained the complete input data (128 bytes).

Extracted data:

A possible interpretation of the input data, derived using Joe Reverser, is provided in Appendix A.

It is important to note that the payload contains a 16-byte session key compatible with AES. This reflects a common pattern in secure communications: asymmetric encryption (which is slower) is used to exchange the AES session key, which is then used for faster symmetric encryption of the remaining communication.

Please note the key currently observed 74 7C EF 54 C0 31 F4 BF 9A 72 29 AB 6E 47 00 5E was generated during analysis and therefore does not match the one used in the traffic captured within the Joe Sandbox environment.

To better understand the cryptographic context, we placed a breakpoint at the start of the RSA import function. At this point, we inspected the parameters used to initialize the public key. , RCX points to a DER-encoded blob, while RDX specifies its size (0xA2, or 162 bytes). The size of this DER blob suggests the use of an RSA-1024 public key.

Extracted DER blob:

We then moved to the analysis of the response traffic:

HTTP/1.1 200 OK 

{"version":1,"status":"ok","diagnostics":"oz4uLSHtluF9UffnfNz2wz7F2BpDvltvF/KLwBUXjRPdiopfuA0EEMGRMoUHDsW6uB/RGRU0r4YPU1cc/GJoxGJXUKQ="}

We implemented a minimal HTTPS replay server that emulates the original C2 endpoint and serves previously captured responses to the malware. As part of this setup, we generated custom TLS certificates and modified the Windows hosts file to redirect the target domains to our machine. This approach enabled a realistic simulation, allowing us to observe the malware’s behavior during the decryption phase in a fully controlled environment.

Using x64dbg, we identified that the API responsible for reading the HTTP response is InternetReadFile.

The second parameter (RDX) is a pointer to the output buffer where the response data is stored.

From the debugger, we observed that the instruction immediately following the call is located at 0x00700d36. Looking up this address in Ghidra shows that it resides within the already analyzed function FUN_00700abc.

We then analyzed this part using Joe Reverser to understand how the payload is processed:

The response handling includes an HMAC verification step to ensure message authenticity and integrity. After that, the AES key (the previously generated session key) is initialized, and the payload is finally decrypted.

This confirms the use of a standard hybrid cryptographic scheme: integrity is ensured through HMAC, while confidentiality is provided by symmetric encryption (AES), with the session key previously exchanged via RSA.

It became evident that attempting to decrypt the communication without access to the original session key is not a practical approach. The RSA-1024 scheme used for key exchange, even with PKCS#1 v1.5 padding, remains computationally difficult to break when properly implemented. RSA security relies on the difficulty of factoring the modulus 𝑛 = 𝑝 ⋅ 𝑞, where 𝑝 and 𝑞 are large prime numbers.

From a complexity perspective, breaking RSA-1024 would require on the order of 2^80 operations, which is far beyond feasible brute-force capabilities. Even with large-scale distributed computing, this would take an impractical amount of time ranging from thousands to millions of years, depending on assumptions. In terms of security equivalence, RSA-1024 offers roughly 80 bits of security, which is below modern recommendations but still computationally expensive to break in practice.

One potential avenue remains: the possibility that the threat actors used weak primes (i.e., primes generated with insufficient entropy or poor randomness), which could make the RSA modulus factorable in practice.

In such cases, the modulus 𝑛 can be checked against public databases such as FactorDB to determine whether its factorization is already known or can be computed efficiently.

To extract the modulus 𝑛 from a DER-encoded RSA public key, you can follow this structure:

SEQUENCE
 ├── AlgorithmIdentifier (rsaEncryption)
 └── BIT STRING
      └── SEQUENCE
           ├── INTEGER (modulus n)
           └── INTEGER (public exponent e)

The modulus 𝑛 is the first INTEGER within the inner SEQUENCE contained in the BIT STRING. In our case, it corresponds to the INTEGER starting with 02 81 81 00, where the leading 00 serves only as padding and should be ignored. The remaining 128 bytes represent the modulus 𝑛 (a 1024-bit value in big-endian format).

The extracted modulus is:

Conversion to an integer:

110184884688415439795711230143574517181508241647470899063735803461492087268723102603190077051628865754550758005609791532201838063958475688195812856331830546156341046250116980890747801414006477246396281261485689144105469563250715805600041697639217989522437411948624766391915664181642807419253042757050978827357

Attempt at factorization:

Unfortunately, the FactorDB check shows that no factors are currently known for this modulus. This means that the value of 𝑛 has not been factorized, and the private key cannot be derived.

As a result, breaking the RSA encryption through factorization is not feasible. In this case, the threat actors implemented it correctly: the primes appear strong, and the key generation process is sound.

For completeness, Appendix B provides the Joe Reverser analysis of the network protocol pseudocode summary.

Command Parsing

We then continued analyzing the command parser. The command parsing path begins at FUN_0070db5c:

The structure of the decrypted packet:

A partial command mapping is provided in Appendix C.

The recovered dispatcher reveals several high-value operational capabilities:

• anti-forensics: command buffers are cleared after processing
• in-memory execution: full PE images can be loaded and executed without being written to disk in the usual way
• live C2 pivoting: the C2 configuration can be modified in memory at runtime
• desktop takeover: desktop enumeration, switching, and control are supported
• token impersonation: the implant can enumerate and impersonate security tokens
• screen and input control: screenshot capture, streaming, and input injection are supported
• file and process control: the implant provides a wide range of capabilities for filesystem and process management
• channelized network operations: dedicated opcodes manage separate channels for tunneling or pivot-like behavior

Threat Intel

To confirm attribution, we pivoted to threat intelligence using the recovered C2 indicators: entity:file (behavior:"microsoft[.]otp[.]lu" or behavior:"analytics[.]green-it[.]lu")

This led to the identification of two matching samples:

• https://www.virustotal.com/gui/file/dff61a394c14f23537b490f7ea1530a456c57bca24bfc317691ce118aa34ee6a
• https://www.virustotal.com/gui/file/8bf7886775bfd69b6867b44a6bad2ee06df4243d814c6245975e78bb1ca2f4ab

In both cases, the Behavior tab reveals an extracted Cobalt Strike Beacon configuration (see Appendix D).

The configuration shows strong overlap with our sample, including the same C2 domains and identical endpoints. Most notably, one detail stands out immediately: the public key.

The extracted public key perfectly matches the DER blob we previously recovered:

This provides strong evidence that the original sample is a Cobalt Strike Beacon implant. More specifically, it appears to be a stageless (embedded) beacon, meaning that the payload is already included within the binary rather than being retrieved from the C2 server at runtime. This behavior aligns with known configurations in which the beacon contains its full configuration and communication profile internally.

Final Words

What began as a low-signal sample in Joe Sandbox Cloud Basic quickly revealed a carefully layered malware chain built to evade superficial analysis. The domain-joined check was the first strong indicator that the sample was intended to execute only in environments resembling real corporate workstations.

By peeling back each stage, we reconstructed the full execution path and ultimately reached a Cobalt Strike Beacon with an embedded configuration. Along the way, we recovered intermediate loaders, rebuilt runnable PE files from memory, and traced the handoff logic that linked one stage to the next.

The network protocol completed the picture. The implant uses a hybrid cryptographic design in which RSA protects the initial session material, while AES and HMAC secure the rest of the communication. The implementation is clean and consistent with a mature beaconing framework, and the recovered configuration, protocol behavior, and public key all align with known Cobalt Strike tradecraft.

Rather than relying on traffic decryption alone, we followed the execution flow directly through the code and runtime behavior. This allowed us to reconstruct the dispatcher, map the supported opcodes, and determine the implant’s operational capabilities from the implementation itself.

Overall, this case shows how combining Joe Sandbox, Joe Reverser, debugger-assisted tracing, and memory reconstruction can turn a seemingly unremarkable sample into a fully understood multi-stage intrusion chain. Starting from a loader that initially appeared harmless, we were able to recover the final implant, analyze its communication model, extract actionable IOCs, and confidently attribute the payload to a stageless Cobalt Strike Beacon.

Indicators of Compromise (IOCs)

SHA-256: 4e791c25ea3e6fe490e9b53a1b13eaafef56d9cfc75930b380fc49fb843212b9

C2 domains:

• microsoft[.]otp[.]lu
• analytics[.]green-it[.]lu

URIs:

• /rest/funcStatus
• /rest/policy/3/

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)

Implant public key:

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCc6JJrOt79fx+sWuznKQGUdXDN
NJ/G2zQDxTMeq5wFjNK5z2/kMiLjjMlb63kFRZpuYGPNJ+V3UQJSHm1NctuJeyXK
eQU19r0dBz0RQqe7hC9OrfmKAEeKTCm/hkow/WfioKzsPcsg7xJ63PHAv9C8KwTW
mhMbbrhxmK/LF/B8XQIDAQAB
-----END PUBLIC KEY-----