Sofacy Recycles Carberp and Metasploit Code

1. Introduction

The Sofacy Group (also known as Pawn Storm or APT28) is well known for deploying zero-day exploits in their APT campaigns. For example, two recent zero-days used by the Sofacy Group were exploiting vulnerabilities in Microsoft Office CVE-2015-2424 and Java CVE-2015-2590.

If the exploit is successful, it installs a Sofacy downloader component, which is different from what we have seen before. This downloader was based on the notorious Carberp source code, which leaked out into the public domain in the summer of 2013.

1.1 Bootstrapped Firefox Add-on

Aside from zero-day exploits, we have also encountered the Carberp-based downloader deployed via other means, such as a bootstrapped Firefox add-on, during spring this year. But what is a bootstrapped add-on? According to Mozilla, it is a type of add-on that you can install and use without needing to restart the browser.

The installation of this Sofacy add-on mostly relies on social engineering. When the user visits the malicious or compromised website, they are prompted to install the add-on.

HTML5 Rendering Enhancements 1.0.

Figure 1: Sofacy HTML5 Rendering Enhancements add-on

The main code is stored in the bootstrap.js file within the add-on package. Once the add-on is activated, the JavaScript will download the Sofacy Carberp-based downloader from the following URL:


The payload will be saved locally as vmware_manager.exe.

This bootstrapped add-on technique isn’t entirely new, it has been documented since 2007, and has been used mostly by potentially unwanted applications. However, this is the first time that we have seen Sofacy use this method. Most of the code in Sofacy’s bootstrap.js file was copied directly from Metasploit, including the GUID {d0df471a-9896-4e6d-83e2-13a04ed6df33}, as well as the add-on name “HTML5 Rendering Enhancements“. Whereas, the downloading of the payload section was copied from one of Mozilla’s code snippets.

2. Technical information about the dropper and DLL

The exploit document or add-on carries a simple PE executable, which installs an embedded DLL to the system. The executable file is around 100KB in size, not packed with any file compressor, but the DLL is compressed using the standard Windows APIs and decompressed with RtlDecompressBuffer before dropped on the disk. One notable common feature appearing in all the samples we’ve seen is a temporary file named jhuhugit.temp. This filename is about the only clear text string in the EXE, most of the other strings are obfuscated with a XOR algorithm using a fixed 11-byte key. Another interesting string appearing in some of the samples is encryption key “bRS8yYQ0APq9xfzC“. This happens to be one of the fixed “main passwords” found from the Carberp source GitHub tree.

The DLL is executed with a system executable rundll32.exe, by running an export named as “init”. The DLL itself doesn’t have much functionality. It simply just sits in a loop, querying one of its fixed C2 servers every 30 minutes. We haven’t yet been able to retrieve any live payloads from the servers, but based on the code, the DLL would just execute the payloads exactly the way itself was executed in the first place. The C2 server addresses and other configuration data are obfuscated using the same 11-byte XOR key algorithm. Nothing really fancy here so far, but the same Carberp password, also used by all the DLL’s we’ve seen, got us curious enough to discover what’s the connection.

By carefully reverse engineering the DLL, it became apparent that this family is based on the Carberp source code. The code repository is not exactly the same as what can be found from GitHub, but close enough to make such claims, as we’ll see later. Features used by this Sofacy based on the Carberp sources include API resolving algorithm and code injection mechanism. Also the algorithm used for generating random URL’s is loosely based on the Carberp.

3. Comparison to Carberp source code

3.1. API resolving algorithm

In the public Carberp source code, APIs are resolved at run time using code constructs like this:

#define pLoadLibraryA   pushargEx< DLL_KERNEL32, 0xC8AC8026, 2 >

In this example, the function pLoadLibraryA is defined by another function, pushargEx, which gets the following arguments:

  • Module identifier is DLL_KERNEL32 in this example
  • Function name hash is C8AC8026, which is calculated at run time
  • Function cache index is 2

The function pushargEx has multiple definitions, including all possible amount of function arguments. Here is an example of a definition for 5 arguments:

inline LPVOID pushargEx(A a1, B a2, C a3, D a4, E a5)
    typedef LPVOID (WINAPI *newfunc)(A, B, C, D, E);
    newfunc func = (newfunc)GetProcAddressEx2( NULL, h, hash, CacheIndex );
    return func(a1, a2, a3, a4, a5);

PushargEx ends up to function GetProcAddressEx2, which locates the API function address based on the name hash and then the address is executed. The purpose of this construct is to be able to use standard Win32 API functions normally in the code, by just putting a character ‘p’ to the beginning. The resulting compiled code is not very easy to read, thus slowing down the reverse engineering process. It also has additional benefit of making the code truly position independent, which is good for code injections.

Carberp’s source tree includes a list of API hashes, and the corresponding cache indexes in a nice list like this.

Carberp API list.

Figure 2: Carberp API list

Now back to the Sofacy binary code. It is apparent from the decompiled example snippet that it uses the same hashing algorithm and index numbering.

Sofacy GetModuleHandleA

Figure 3: Sofacy GetModuleHandleA

GetModuleHandleA is just one of the many functions resolved dynamically by Sofacy. But they all fit exactly to the Carberp source code – the hashes and arguments match, as well as the indexing (see index number #43 from Figure 2).

Looking further to the API resolver, we can observe striking similarities in functions named as GetProcAddressEx and GetProcAddressEx2. Here’s a screenshot of GetProcAddressEx2 from Carberp sources and a decompiled code from Sofacy binary, side by side.

GetProcAddressEx2 from Carberp and Sofacy.

Figure 4: GetProcAddressEx2 from Carberp and Sofacy

And here’s a similar comparison for GetProcAddressEx from Carberp sources and decompiled code from a Sofacy binary.

GetProcAddressEx from Carberp and Sofacy

Figure 5: GetProcAddressEx from Carberp and Sofacy

In the decompiled code snippets, all the function names and variables have been named according to the Carberp sources on purpose, just for the sake of demonstration.

3.2. Code injection

Sofacy uses code injection for all networking code by injecting its own functions to browser processes. The processes are located using the Carberp process name hashing algorithm. The purpose of this setup is most likely to get around personal firewalls and other behavior detection systems.

The injection starts with a function named as InjectIntoProcess, which opens a process, injects code with InjectCode4 and runs it with CreateRemoteThread. Below is a snippet from Carberp.

InjectCode4 from the Carberp source.

Figure 6: InjectCode4 from the Carberp source

InjectIntoProcess and InjectCode4 from the Sofacy binary combines this functionality.

InjectIntoProcess from Sofacy

Figure 7: InjectIntoProcess from Sofacy

Figure 8: InjectCode4 from Sofacy

Figure 8: InjectCode4 from Sofacy

3.3. Mysterious Main Password

In the Carberp sources, there exists a password called as MainPassword, or RC2_Password or DebugPassword. One of the possible values of this password is “bRS8yYQ0APq9xfzC“, also used by Sofacy. The purpose of this password in Carberp is for example encrypting HTTP traffic. However, in Sofacy, it is used in quite a different manner. Sofacy has a modified algorithm for API resolution that uses the same password. In Carberp, the resolver has a clear text list of DLL names, which the index parameter in GetProcAddressEx2 refers to. In Sofacy, this list is obfuscated with a simple XOR-based algorithm, using the Carberp “main password”.

4. Conclusions

Based on the analysis presented in this blog post, it should now be evident that the new Sofacy downloader is based on Carberp source code. However, there are also some very strong differences, for example the API resolver and its use of the Carberp main password. What can we conclude about this connection? We think it means the Sofacy gang has a private source tree of Carberp source code. The use of the password for protecting DLL names in the resolver suggests that the source is more recent than what is publicly available in GitHub. Does it mean the Sofacy gang just cloned the source tree and continued development, or is it developed further by somebody else somewhere behind the scenes? That, we don’t know yet. But the Sofacy connection, in addition to recent incidents by Anunak/Carbanak (also based on Carberp) indicate that Carberp is still alive and kicking.

5. Hashes






5c3e709517f41febf03109fa9d597f2ccc495956 (decompiled code examples)

Articles with similar Tags