I am still reversing LockerGoga sample. This time I want to focus on network part. You would ask why ransomware even need networking part? Yes, the same question crossed my mind, but now I would like to stick to facts. And as you can see from Ida Imports subview there are two functions import from WS2_32 library.

Since there is no straightforward name of the symbol imported(only the ordinal number) I needed to check WS2_32 library against ordinals assigned to particular symbols. I loaded ws32.dll library into Ida and those are exports.

So it seems like LockerGoga is linked against two symbols, WSAStartup and WSACleanup. Those two calls are needed to initialize usage of winsocket by the calling process and to end using winsockets. That’s it. Not much for now. Let’s have a look where those symbols are called.

Winsock initialization is called nearby InterlockIncrement and InterlockExchange. Both those functions change the value of the variable in a atomic way – it is threadsafe. Why someone wanted to increment some variable near winsock initialization?

Crypto part – not the file encryption one

While going through interesting dissasembly strings I have found something like charset for the whole Latin alphabet.

So I googled to find what it can be, I used “EncodingLookupArray” string to look for it in Google because it seems for me to more meaningful that charset. The code comes from CryptoPP library – free C++ cryptographic library. It seems like the library was statically compiled and its code is included into the malware binary. The source code which is probably visible in the disassembly is available on the Grenoble university site. From there you can see that the code is responsible for Base64 encoding – maybe this is the code responsible for encoding file path strings to be available for exchanging between master and slave processes? This is very likely since LockerGoga processes communicate with each other exchanging Base64 encoded paths.

And yes, my hypothesis is true, this whole initialization of Bas64 encoder is done in the main function responsible for master process work. I have described this function in the previous post. Here you can see that this initializer is called from master process code – the one that is responsible for call CreateMutex and allocate file memory mapping to exchange information between processes

Since I know now that CryptoPP library is used there I would like to find where some asymmetric cryptography is used – that will lead me to the place where file encryption is done. Starting from the Ida strings view there is something interesting there.

Seems like something is generated in here some string. Let’s compare it with CryptoPP source code looking for ” for this public key” string.

But jumping to the xreference to this particular leaded me to nowhere. I just landed in .rdata segment where the offset to this functions is stored.

Let’s take easier path, I went to the list of file extensions, probably the one that should be encrypted – I guess so because there are lots of document extensions there. But what is interesting, there are also some source code extensions.

It seems like author does not like interpreted languages 🙂 I do not see any native extensions there. Okay, got to the point. I am jumping one layer above to xref in Ida and I again landed in the master process code.

What do I have in mind referring to the master code? I would try to explain it by zooming Ida graph view. In here you can find master process code, so the one that start from “scanning…” string which goes to the log file and the green line shows the loop that is constantly scanning for file extensions.

So the first arrow from top points you the loop which goes nearly from the beginning of the code block to its end. Inside it, there is a block responsible for getting attributes and comparing file extensions. This block works in a green line loop.