viernes, 25 de julio de 2014

New Feodo variant follows Geodo steps

Cridex (aka Feodo/Bugat) activity reached its zenith towards the end of 2013 and early 2014 in which it almost disappeared until it returned again in June reincarnated as what the guys at baptized as Geodo.

Earlier this week, S21sec's Ecrime team detected what seems to be an evolution of one of the old variants -unrelated to Geodo- which has new and noteworthy features.

First of all, it uses a loader with limited functionality as the first infection step used to download the main trojan module in the form of a DLL using the following paths and injecting itself into explorer.exe as in earlier versions:

Trojan network communication is done through the typical 8080 although the path is a bit different from what we are used to:

Once the installation step is completed, the trojan downloads the configuration file which is just a gzip file with a fake header:

The config file uses the XML like format seen on previous versions which has the following structure:
  • modules: Embedded new modules encoded in Base64:
    • vnc_x32
    • vnc_x64
    • socks_x32
    • socks_x64
    • bot_x32
    • bot_x64
  • httpshots y clickshots: URL patterns for which the trojan must perform screenshots
  • formgrabber: URL patterns used for form grabbing
  • bconnect: Back Connect Server
  • vncconnect: VNC Server
  • redirects: External resources references used on injections
  • httpinjects: Entity URL patterns with their corresponding injections

Affected entities seems to be mainly from UK, Ireland, United Arabian Emirates and Qatar, with some injections designed to bypass second authentication factor which, in combination with the VNC module, will allow the attacker to supplant the victim's online banking session.

So it seems that after some months of silence on Cridex world, a new old friend (dressed up for the ocassion) joins Geodo on its journey.

Note: Originally published on S21sec's blog
Follow me on Twitter: @smvicente

The MD5 signatures of the files analyzed by S21sec were:
  • loader: 9d81ac7604ef2a0096537396a4a91193   
  • bot_x32: 04b55edf43a006f9c531287161fa2fa8               
  • vnc_x32: c73c3c18b74c67e88d5b3f4658016dcd
Other hashes for the rest of the modules are:
  • vnc_x64: 5ecfc1d3274845bf5ff3f66ca255945e
  • socks_x32: 53eb0e59b5bb574df5755527dc3d4f47
  • socks_x64: 0dfc66eadbd9e88b2262ac848eadee8f
  • bot_x64: 4df1cef98bbc174ba02f17d2ca6c0a58

jueves, 24 de julio de 2014

New GOZ first steps

From the very begining of the operation against the infamous Murofet/Gameover/ZeusP2P banking trojan (known as Operation Tovar) the botnet growth has stalled and it seems it has been abandoned since then. Instead of recovering control over the botnet, it seems that botmasters decided to create a new botnet from scratch using  a new GOZ version. We will analyze the main new features throughout the post.

  • The new trojan has replaced the Peer-to-Peer (P2P) mechanism in favor of a Fast-Flux network using a new domain generation algorithm (DGA).
  • The public key included within the trojan (which is XORed in the same way) is no longer used to verify the signature of the resources exchanged via P2P and is now used as part of the classic symmetric + asymmetric communication schema in which the payload is ciphered with the symmetric key whilst the random generated key is ciphered with the public key before it is sent to the command and control server. The scheme is similar to the one used, for instance, by Cridex/Bugat/Feodo/Geodo.
Taking into account DGA is based on a hardcoded seed, creating a new botnet is just a matter of changing both, the seed, and the public key in the binary.


Whereas the cypher has been kept unchanged in some way, there has been some modifications due to the new communication scheme seen above. In short:
  • RC4 is maintained for the configuration stored in the system registry
  • The communication with the command and control panel is now based on AES256 + RSA.


The configuration has remained largely unchanged. In fact, most injections and target entities are old and they even contain variables which belongs to features no longer present on the current version like those related with the P2P proxy:

Therefore, it seems that we are facing what seems to be a lite version of GOZ which, somehow, reminds us Licat, its predecessor. Far from reducing the prominence of the trojan, even if the configuration files may lead us to think that it has been released in haste, features such as the DGA seed may lead to a boom of new GOZ botnets which will start a new cat and mouse chase.

Note: Originally published on S21sec's blog

Follow me on Twitter: @smvicente

jueves, 22 de agosto de 2013

ZeuS: Because not all is banking

Last week, security researchers published a post regarding a new variant of ZeuS which took advantage of the fact that people is willing to gain popularity via Instagram "likes" even if they have to pay big bucks for it. This unusual behavior for a ZeuS does not seems to be exclusive to that variant as we have been following for a while another one that exhibits a similar behaviour and does not target traditional entities.

The first thing that caught our attention was that it did not inject itself into explorer.exe; instead, it created two visible process:

The first one: winsec32.exe, is located within %windir%/system32/ while the other is a typical ZeuS process with a pseudo-random name located within the usual path. Both are equal, however, the functionality of the first process seems limited to the monitorization and launch of the second one in case it is not running by whatever reason:
C:\WINDOWS\system32\winsec32.exe" -service "C:\Documents and Settings\\Application Data\Xuzove\efybym.exe
Besides that, it also manages to survive reboots by creating a new task:
Service: Security Center Server - 1972840912 (SecurityCenterServer1972840912) - OperA software - C:\WINDOWS\system32\winsec32.exe
Note: This is why, in an moment of inspiration, we called it "ZeuS Tasks"; the fact that it does not inject into explorer.exe reminded us an old variant seen about two years ago with visible processes, which contained this hidden message for reversers within the static config:

Anyway, the second process is the actual trojan, which, as stated above, seems to be Click Fraud oriented. Before getting down to work, let's see which are the main differences with regards to an standard ZeuS:

First of all, the static -or embedded- config is not managed as usual by the trojan, starting with the fact that is not XORed:

Within it we can find at least two different RC4 IVs and the hardcoded C&C URLs which, unlike the rest of ZeuS strains, do not have a path which points to a config:

Which can be confirmed by looking at the network traffic which shows many request with quite short responses that obiously are not ciphered config files:

We would like to remark the way it communicates with its C&C because we think is quite interesting. It encrypts the payload each time with a random RC4 key that is initialized from a combination of a Mersenne twister plus a time generated seed:

Then it sends the pseudo-random part of the key to the C&C so it can generate the same key and can hence decipher the payload and cipher the response with the command.

The only type of commands we have seen so far are like this:

All the URLs received are loaded in background to avoid arousing suspicion. The URLs usually points to an advertise site or a fake blog like this one:

Pages in which every link points to a different advert.

So here we have another example of the leaked source code of ZeuS being used for an unusual and, maybe less risky than banking, goal. Showing us that this is still one of the most loved trojans.

Note: Originally published on S21sec's blog

Follow me on Twitter: @smvicente

viernes, 11 de enero de 2013

Volatility VS Citadel

As a forensic and malware analyst, I have always been a big fan of Volatility, the Python coded memory analysis tool that keeps growing day by day. Thus, since I read Michael Ligh's article on his blog about the extraction of the ZeuS' encryption keys, I was willing to try out the same thing with another malware family as well.

I’ve chosen Citadel in this case, that is one of the most widely used ZeuS’s variants since its source code leakage. Specifically the version that, while not the last one, will be the basis for subsequent versions (although it is rumored that could be the last we see) or other families.

When using Volatillity and Yara together, the power available for automatic malware processing increases. "zeusscan2", one of the plugins resulting from the article mentioned above, is based on both things. It makes use of Yara rules against an infected machine’s memory to detect and access those memory regions that most likely contains the information we want to extract from the binary file. This requires a thorough analysis on the family prior to "automate", which in this case, being a variant of the well known and documented Zeus family, the work is limited to detecting differences within it.

As a start point, we know that ZeuS 2.X contains the following information embedded in the binary:
  • Initial config file download URL
  • RC4 key used to decipher the config file
  • Info about the location of the binary and his config on the infected machine
The first two can be found within the binary in a XOR encoded area with the bytes at the beginning of the last PE section, while the latter is an encrypted area using the RC4 key and with a fixed structure (For now on we will refer to it as the "magic object" to follow the convention used in the Volatility’s ZeuS plugin).

Note: In ZeuS’ case there’s a second RC4 encryption key contained in the last commented structure, but since Citadel lacks of it, is not relevant to the purpose of the article.

Thereby, the processing and extraction flow we are searching for should be something like:
  1. Embedded config finding.
  2. XORing with the bytes at the beginning of the last PE section to decode it.
  3. RC4 key and initial config file download URL extraction.
  4. Searching and decoding of the “magic object” with the RC4 key
  5. Rest of data extraction
Now that we know the base which supports Citadel, we can study the differences to adapt the plugin to the new family. The similarities (at binary level at least) are bigger than the differences, so once we understand it, the changes are not complicated.

The main difference comes from the cipher algorithm used to encrypt the downloaded config files (AES instead of RC4), but the “magic object” keeps RC4. The AES key, it’s not within the binary as so, but calculated on runtime in the following way:

The BO_LOGIN_KEY or binary key, is a 16 hexadecimal bytes key that can be found inside the binary and, in addition to compute the AES key, it’s used in the control panel communication, so to the localization of the embedded config and the "magic object", we must add the hardcoded key.

To the workflow above, it should be added:
  1. BO_LOGIN_KEY finding
  2. AES key computing
With all of this, we can choose the following disassembled code to generate the new Yara rules that help us find the commented variables in memory:

8BEC                  MOV EBP,ESP
83EC 0C               SUB ESP,0C
8A82 00010000         MOV AL,BYTE PTR DS:[EDX+100]
8845 FE               MOV BYTE PTR SS:[EBP-2],AL
8A82 01010000         MOV AL,BYTE PTR DS:[EDX+101]
8845 FD               MOV BYTE PTR SS:[EBP-3],AL
8A82 02010000         MOV AL,BYTE PTR DS:[EDX+102]
B9 801A1300           MOV ECX,131A80                      ; BO_LOGIN_KEY
8845 FF               MOV BYTE PTR SS:[EBP-1],AL
E8 BEF2FFFF           CALL 0015BC16
56                    PUSH ESI
BA 54050000           MOV EDX,554                         ; Embedded configuration length
52                    PUSH EDX
68 602A4000           PUSH pyko.00402A60                  ; Embedded configuration
50                    PUSH EAX
E8 47E30100           CALL pyko.004290C1
8B0D B4394300         MOV ECX,DWORD PTR DS:[4339B4]
030D 943D4300         ADD ECX,DWORD PTR DS:[433D94]
8BF2                  MOV ESI,EDX
2BC8                  SUB ECX,EAX
68 03010000           PUSH 103
8D85 10FBFFFF         LEA EAX,[LOCAL.316]
50                    PUSH EAX
8D85 FCFEFFFF         LEA EAX,[LOCAL.65]
50                    PUSH EAX
E8 B4E20100           CALL pyko.004290C1
B8 1C010000           MOV EAX,11C
50                    PUSH EAX
68 283C4300           PUSH pyko.00433C28                  ; Magic object
Once we get to the workflow processing part in which the “magic object” is decoded, we then face to a structure similar to:

This object, like happened with ZeuS 2.X, has a fixed length in most cases and a structure like the following:

{'_ZEUS_MAGIC' : [ 0x11C, {
'struct_size' : [ 0x0, ['unsigned int']], \
'guid' : [ 0x4, ['array', 0x30, ['unsigned short']]], \
'guid2' : [ 0x7C, ['array', 0x10, ['unsigned char']]], \
'exefile' : [ 0x9C, ['array', 0x14, ['unsigned char']]], \
'keyname' : [ 0xEC, ['array', 0xA, ['unsigned char']]], \
'value1' : [ 0xF6, ['array', 0xA, ['unsigned char']]], \
'value2' : [ 0x100, ['array', 0xA, ['unsigned char']]], \
'value3' : [ 0x10A, ['array', 0xA, ['unsigned char']]], \
'guid_xor_key' : [ 0x114, ['unsigned int']], \
'xorkey' : [ 0x118, ['unsigned int']], \
So we already have everything we wanted:

I hope this example helps to understand a little better all the capabilities Yara and Volatility offers when automating and analyzing malware.

The plugin for the version can be found here. Michael Ligh has also merged it with the previous versions of the ZeuS 1 & 2.X plugins, so from now on it will be shipped with Volatility too, though it won’t be enabled by default; Use the --plugins parameter to access them like this:

$ python --plugins=contrib/plugins/malware citadelscan1345 -f ....
Regarding version, the process to follow should be similar to the one described, except for a new hardcoded key and the size and structure of the “magic object”, that changes from sample to sample.

Happy analysis!

Note: Originally published on Buguroo's blog

Follow me on Twitter: @smvicente