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.

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:

hxxp://dailyforeignnews.com/2015/04/Qih/north-korea-declares-no-sail-zone-missile-launch-seen-as-possible-reports/579382/hazard.edn

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.

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.

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 asGetProcAddressEx and GetProcAddressEx2. Here’s a screenshot of GetProcAddressEx2 from Carberp sources and a decompiled code from Sofacy binary, side by side.

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.

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.

Figure 6: InjectCode4 from the Carberp source

InjectIntoProcess and InjectCode4 from the Sofacy binary combines this functionality.

Figure 7: InjectIntoProcess 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

Bootstrap.js:

e7d13aed50bedb5e67d92753f6e0eda8a3c9b4f0

Droppers:

b8aabe12502f7d55ae332905acee80a10e3bc399
015425010bd4cf9d511f7fcd0fc17fc17c23eec1
51b0e3cd6360d50424bf776b3cd673dd45fd0f97
4fae67d3988da117608a7548d9029caddbfb3ebf
b7788af2ef073d7b3fb84086496896e7404e625e
63d1d33e7418daf200dc4660fc9a59492ddd50d9
b4a515ef9de037f18d96b9b0e48271180f5725b7
f3d50c1f7d5f322c1a1f9a72ff122cac990881ee

DLL’s:

5c3e709517f41febf03109fa9d597f2ccc495956 (decompiled code examples)
ed9f3e5e889d281437b945993c6c2a80c60fdedc
21835aafe6d46840bb697e8b0d4aac06dec44f5b
d85e44d386315b0258847495be1711450ac02d9f
ac61a299f81d1cff4ea857afd1b323724aac3f04
7319a2751bd13b2364031f1e69035acfc4fd4d18
b8b3f53ca2cd64bd101cb59c6553f6289a72d9bb
f7608ef62a45822e9300d390064e667028b75dea
9fc43e32c887b7697bf6d6933e9859d29581ead0
3b52046dd7e1d5684eabbd9038b651726714ab69
d3aa282b390a5cb29d15a97e0a046305038dbefe