Whenever I reverse a sample, I am mostly interested in how it was developed, even if in the end the techniques employed are generally the same, I am always curious about what was the way to achieve a task, or just simply understand the code philosophy of a piece of code. It is a very nice way to spot different trending and discovering (sometimes) new tricks that you never know it was possible to do. This is one of the main reasons, I love digging mostly into stealers/clippers for their accessibility for being reversed, and enjoying malware analysis as a kind of game (unless some exceptions like Nymaim that is literally hell).
It's been 1 year and a half now that I start looking into "Predator The Thief", and this malware has evolved over time in terms of content added and code structure. This impression could be totally different from others in terms of stealing tasks performed, but based on my first in-depth analysis,, the code has changed too much and it was necessary to make another post on it.
This one will focus on some major aspects of the 3.3.2 version, but will not explain everything (because some details have already been mentioned in other papers, some subjects are known). Also, times to times I will add some extra commentary about malware analysis in general.
When you open an unpacked binary in IDA or other disassembler software like GHIDRA, there is an amount of code that is not interpreted correctly which leads to rubbish code, the incapacity to construct instructions or showing some graph. Behind this, it's obvious that an anti-disassembly trick is used.
The technique exploited here is known and used in the wild by other malware, it requires just a few opcodes to process and leads at the end at the creation of a false branch. In this case, it begins with a simple xor instruction that focuses on configuring the zero flag and forcing the JZ jump condition to work no matter what, so, at this stage, it's understandable that something suspicious is in progress. Then the MOV opcode (0xB8) next to the jump is a 5 bytes instruction and disturbing the disassembler to consider that this instruction is the right one to interpret beside that the correct opcode is inside this one, and in the end, by choosing this wrong path malicious tasks are hidden.
Of course, fixing this issue is simple, and required just a few seconds. For example with IDA, you need to undefine the MOV instruction by pressing the keyboard shortcut "U", to produce this pattern.
Then skip the 0xB8 opcode, and pushing on "C" at the 0xE8 position, to configure the disassembler to interpret instruction at this point.
Replacing the 0xB8 opcode by 0x90. with a hexadecimal editor, will fix the issue. Opening again the patched PE, you will see that IDA is now able to even show the graph mode.
After patching it, there are still some parts that can't be correctly parsed by the disassembler, but after reading some of the code locations, some of them are correct, so if you want to create a function, you can select the "loc" section then pushed on "P" to create a sub-function, of course, this action could lead to some irreversible thing if you are not sure about your actions and end to restart again the whole process to remove a the ant-disassembly tricks, so this action must be done only at last resort.
Whenever you are analyzing Predator, you know that you will have to deal with some obfuscation tricks almost everywhere just for slowing down your code analysis. Of course, they are not complicated to assimilate, but as always, simple tricks used at their finest could turn a simple fun afternoon to literally "welcome to Dark Souls". The concept was already there in the first in-depth analysis of this malware, and the idea remains over and over with further updates on it. The only differences are easy to guess :
- More layers of obfuscation have been added
- Techniques already used are just adjusted.
- More dose of randomness
As a reversing point of view, I am considering this part as one the main thing to recognized this stealer, even if of course, you can add network communication and C&C pattern as other ways for identifying it, inspecting the code is one way to clarify doubts (and I understand that this statement is for sure not working for every malware), but the idea is that nowadays it's incredibly easy to make mistakes by being dupe by rules or tags on sandboxes, due to similarities based on code-sharing, or just literally creating false flag.
Already there in a previous analysis, recreating the GetProcAddress is a popular trick to hide an API call behind a simple register call. Over the updates, the main idea is still there but the main procedures have been modified, reworked or slightly optimized.
First of all, we recognized easily the PEB retrieved by spotting fs[0x30] behind some extra instructions.
then from it, the loader data section is requested for two things:
- Getting the InLoadOrderModuleList pointer
- Getting the InMemoryOrderModuleList pointer
For those who are unfamiliar by this, basically, the PEB_LDR_DATA is a structure is where is stored all the information related to the loaded modules of the process.
Then, a loop is performing a basic search on every entry of the module list but in "memory order" on the loader data, by retrieving the module name, generating a hash of it and when it's done, it is compared with a hardcoded obfuscated hash of the kernel32 module and obviously, if it matches, the module base address is saved, if it's not, the process is repeated again and again.
Nowadays, using hashes for a function name or module name is something that you can see in many other malware, purposes are multiple and this is one of the ways to hide some actions. An example of this code behavior could be found easily on the internet and as I said above, this one is popular and already used.
GetProcAddress / GetLoadLibrary
Always followed by GetModuleAddress, the code for recreating GetProcAddress is by far the same architecture model than the v2, in term of the concept used. If the function is forwarded, it will basically perform a recursive call of itself by getting the forward address, checking if the library is loaded then call GetProcAddress again with new values.
It's almost unnecessary to talk about it, but as in-depth analysis, if you have never read the other article before, it's always worth to say some words on the subject (as a reminder). The XOR encryption is a common cipher that required a rudimentary implementation for being effective :
- Only one operator is used (XOR)
- it's not consuming resources.
- It could be used as a component of other ciphers
This one is extremely popular in malware and the goal is not really to produce strong encryption because it's ridiculously easy to break most of the time, they are used for hiding information or keywords that could be triggering alerts, rules...
- Communication between host & server
- Hiding strings
- Or... simply used as an absurd step for obfuscating the code
A typical example in Predator could be seeing huge blocks with only two instructions (XOR & MOV), where stacks strings are decrypted X bytes per X bytes by just moving content on a temporary value (stored on EAX), XORed then pushed back to EBP, and the principle is reproduced endlessly again and again. This is rudimentary, In this scenario, it's just part of the obfuscation process heavily abused by predator, for having an absurd amount of instruction for simple things.
Also for some cases, When a hexadecimal/integer value is required for an API call, it could be possible to spot another pattern of a hardcoded string moved to a register then only one XOR instruction is performed for revealing the correct value, this trivial thing is used for some specific cases like the correct position in the TEB for retrieving the PEB, an RVA of a specific module, ...
Finally, the most common one, there is also the classic one used by using a for loop for a one key length XOR key, seen for decrypting modules, functions, and other things...
str = ... # encrypted string for i, s in enumerate(str): s[i] = s[i] ^ s[len(str)-1]
Let's consider this as a perfect example of "let's do the same exact thing by just changing one single instruction", so in the end, a new encryption method is used with no effort for the development. That's how a SUB instruction is used for doing the substitution cipher. The only difference that I could notice it's how the key is retrieved.
Besides having something hardcoded directly, a signed 32-bit division is performed, easily noticeable by the use of cdq & idiv instructions, then the dl register (the remainder) is used for the substitution.
What's the result in the end?
Merging these obfuscation techniques leads to a nonsense amount of instructions for a basic task, which will obviously burn you some hours of analysis if you don't take some time for cleaning a bit all that mess with the help of some scripts or plenty other ideas, that could trigger in your mind. It could be nice to see these days some scripts released by the community.
There are plenty of techniques abused here that was not in the first analysis, this is not anymore a simple PEB.BeingDebugged or checking if you are running a virtual machine, so let's dig into them. one per one except CheckRemoteDebugger! This one is enough to understand by itself :')
One of the oldest tricks in windows and still doing its work over the years. Basically in a very simple way (because there is a lot thing happening during the process), NtSetInformationThread is called with a value (0x11) obfuscated by a XOR operator. This parameter is a ThreadInformationClass with a specific enum called ThreadHideFromDebugger and when it's executed, the debugger is not able to catch any debug information. So the supposed pointer to the corresponding thread is, of course, the malware and when you are analyzing it with a debugger, it will result to detach itself.
Inside WinMain, a huge function is called with a lot of consecutive anti-debug tricks, they were almost all indirectly related to some techniques patched by TitanHide (or strongly looks like), the first one performed is a really basic one, but pretty efficient to do the task.
Basically, when CloseHandle is called with an inexistent handle or an invalid one, it will raise an exception and whenever you have a debugger attached to the process, it will not like that at all. To guarantee that it's not an issue for a normal interaction a simple __try / __except method is used, so if this API call is requested, it will safely lead to the end without any issue.
The invalid handle used here is a static one and it's L33T code with the value 0xBAADAA55 and makes me bored as much as this face.
That's not a surprise to see stuff like this from the malware developer. Inside jokes, l33t values, animes and probably other content that I missed are something usual to spot on Predator.
When you are debugging a process, Microsoft Windows is creating a "Debug" object and a handle corresponding to it. At this point, when you want to check if this object exists on the process, NtQueryInformationProcess is used with the ProcessInfoClass initialized by 0x1e (that is in fact, ProcessDebugObjectHandle).
In this case, the NTStatus value (returning result by the API call) is an error who as the ID 0xC0000353, aka STATUS_PORT_NOT_SET. This means, "An attempt to remove a process's DebugPort was made, but a port was not already associated with the process.". The anti-debug trick is to verify if this error is there, that's all.
This one is maybe considered as pretty wild if you are not familiar with some hardware breakpoints. Basically, there are some registers that are called "Debug Register" and they are using the DRX nomenclature (DR0 to DR7). When GetThreadContext is called, the function will retrieve al the context information from a thread.
For those that are not familiar with a context structure, it contains all the register data from the corresponding element. So, with this data in possession, it only needs to check if those DRX registers are initiated with a value not equal to 0.
On the case here, it's easily spottable to see that 4 registers are checked
if (ctx->Dr0 != 0 || ctx->Dr1 != 0 || ctx->Dr2 != 0 || ctx->Dr3 != 0)
Int 3 breakpoint
int 3 (or Interrupt 3) is a popular opcode to force the debugger to stop at a specific offset. As said in the title, this is a breakpoint but if it's executed without any debugging environment, the exception handler is able to deal with this behavior and will continue to run without any issue. Unless I missed something, here is the scenario.
By the way, as another scenario used for this one (the int 3), the number of this specific opcode triggered could be also used as an incremented counter, if the counter is above a specific value, a simplistic condition is sufficient to check if it's executed into a debugger in that way.
With all the techniques explained above, in the end, they all lead to a final condition step if of course, the debugger hasn't crashed. The checking task is pretty easy to understand and it remains to a simple operation: "setting up a value to EAX during the anti-debug function", if everything is correct this register will be set to zero, if not we could see all the different values that could be possible.
...And when the Anti-Debug function is done, the register EAX is checked by the test operator, so the ZF flag is determinant for entering into the most important loop that contains the main function of the stealer.
The Anti VM is presented as an option in Predator and is performed just after the first C&C requests.
Tricks used are pretty olds and basically using Anti-VM Instructions
- CPUID (Hypervisor Trick)
By curiosity, this option is not by default performed if the C&C is not reachable.
Paranoid & Organized Predator
When entering into the "big main function", the stealer is doing "again" extra validations if you have a valid payload (and not a modded one), you are running it correctly and being sure again that you are not analyzing it.
This kind of paranoid checking step is a result of the multiple cases of cracked builders developed and released in the wild (mostly or exclusively at a time coming from XakFor.Net). Pretty wild and fun to see when Anti-Piracy protocols are also seen in the malware scape.
Then the malware is doing a classic organized setup to perform all the requested actions and could be represented in that way.
Of course as usual and already a bit explained in the first paper, the C&C domain is retrieved in a table of function pointers before the execution of the WinMain function (where the payload is starting to do tasks).
You can see easily all the functions that will be called based on the starting location (__xc_z) and the ending location (__xc_z).
Then you can spot easily the XOR strings that hide the C&C domain like the usual old predator malware.
Data Encryption & Encoding
Besides using XOR almost absolutely everywhere, this info stealer is using a mix of RC4 encryption and base64 encoding whenever it is receiving data from the C&C. Without using specialized tools or paid versions of IDA (or whatever other software), it could be a bit challenging to recognize it (when you are a junior analyst), due to some modification of some part of the code.
For the Base64 functions, it's extremely easy to spot them, with the symbol values on the register before and after calls. The only thing to notice with them, it's that they are using a typical signature... A whole bloc of XOR stack strings, I believed that this trick is designed to hide an eventual Base64 alphabet from some Yara rules.
By the way, the rest of the code remains identical to standard base64 algorithms.
For RC4, things could be a little bit messy if you are not familiar at all with encryption algorithm on a disassembler/debugger, for some cases it could be hell, for some case not. Here, it's, in fact, this amount of code for performing the process.
Blocs are representing the Generation of the array S, then performing the Key-Scheduling Algorithm (KSA) by using a specific secret key that is, in fact, the C&C domain! (if there is no domain, but an IP hardcoded, this IP is the secret key), then the last one is the Pseudo-random generation algorithm (PRGA).
For more info, some resources about this algorithm below:
Mutex & Hardware ID
The Hardware ID (HWID) and mutex are related, and the generation is quite funky, I would say, even if most of the people will consider this as something not important to investigate, I love small details in malware, even if their role is maybe meaningless, but for me, every detail counts no matter what (even the stupidest one).
Here the hardware ID generation is split into 3 main parts. I had a lot of fun to understand how this one was created.
First, it will grab all the available logical drives on the compromised machine, and for each of them, the serial number is saved into a temporary variable. Then, whenever a new drive is found, the hexadecimal value is added to it. so basically if the two drives have the serial number "44C5-F04D" and "1130-DDFF", so ESI will receive 0x44C5F04D then will add 0x1130DFF.
When it's done, this value is put into a while loop that will divide the value on ESI by 0xA and saved the remainder into another temporary variable, the loop condition breaks when ESI is below 1. Then the results of this operation are saved, duplicated and added to itself the last 4 bytes (i.e 1122334455 will be 112233445522334455).
If this is not sufficient, the value is put into another loop for performing this operation.
for i, s in enumerate(str): if i & 1: a += chr(s) + 0x40 else: a += chr(s)
It results in the creation of an alphanumeric string that will be the archive filename used during the POST request to the C&C.
But wait! there is more... This value is in part of the creation of the mutex name... with a simple base64 operation on it and some bit operand operation for cutting part of the base64 encoding string for having finally the mutex name!
A classic thing in malware, this feature is used for avoiding infecting machines coming from the Commonwealth of Independent States (CIS) by using a simple API call GetUserDefaultLangID.
The value returned is the language identifier of the region format setting for the user and checked by a lot of specific language identifier, of courses in every situation, all the values that are tested, are encrypted.
|Language ID||SubLanguage Symbol||Country|
Files, files where are you?
When I reversed for the first time this stealer, files and malicious archive were stored on the disk then deleted. But right now, this is not the case anymore. Predator is managing all the stolen data into memory for avoiding as much as possible any extra traces during the execution.
Predator is nowadays creating in memory a lot of allocated pages and temporary files that will be used for interactions with real files that exist on the disk. Most of the time it's basically getting handles, size and doing some operation for opening, grabbing content and saving them to a place in memory. This explanation is summarized in a "very" simplify way because there are a lot of cases and scenarios to manage this.
Another point to notice is that the archive (using ZIP compression), is also created in memory by selecting folder/files.
It doesn't mean that the whole architecture for the files is different, it's the same format as before.
After explaining this many times about how this stuff, the fundamental idea is boringly the same for every stealer:
- Analyzing (optional)
- Parsing (optional)
What could be different behind that, is how they are obfuscating the files or values to check... and guess what... every malware has their specialties (whenever they are not decided to copy the same piece of code on Github or some whatever generic .NET stealer) and in the end, there is no black magic, just simple (or complex) enigma to solve. As a malware analyst, when you are starting into analyzing stealers, you want literally to understand everything, because everything is new, and with the time, you realized the routine performed to fetch the data and how stupid it is working well (as reminder, it might be not always that easy for some highly specific stuff).
In the end, you just want to know the targeted software, and only dig into those you haven't seen before, but every time the thing is the same:
- Checking dumbly a path
- Checking a register key to have the correct path of a software
- Checking a shortcut path based on an icon
Beside that Predator the Thief is stealing a lot of different things:
- Grabbing content from Browsers (Cookies, History, Credentials)
- Harvesting/Fetching Credit Cards
- Stealing sensible information & files from Crypto-Wallets
- Credentials from FTP Software
- Data coming from Instant communication software
- Data coming from Messenger software
- 2FA Authenticator software
- Fetching Gaming accounts
- Credentials coming from VPN software
- Grabbing specific files (also dynamically)
- Harvesting all the information from the computer (Specs, Software)
- Stealing Clipboard (if during the execution of it, there is some content)
- Making a picture of yourself (if your webcam is connected)
- Making screenshot of your desktop
- It could also include a Clipper (as a modular feature).
- And... due to the module manager, other tasks that I still don't have mentioned there (that also I don't know who they are).
Let's explain just some of them that I found worth to dig into.
Since my last analysis, things changed for the browser part and it's now divided into three major parts.
- Internet Explorer is analyzed in a specific function developed due that the data is contained into a "Vault", so it requires a specific Windows API to read it.
- Microsoft Edge is also split into another part of the stealing process due that this one is using unique files and needs some tasks for the parsing.
- Then, the other browsers are fetched by using a homemade static grabber
Grabber n°1 (The generic one)
It's pretty fun to see that the stealing process is using at least one single function for catching a lot of things. This generic grabber is pretty "cleaned" based on what I saw before even if there is no magic at all, it's sufficient to make enough damages by using a recursive loop at a specific place that will search all the required files & folders.
By comparing older versions of predator, when it was attempting to steal content from browsers and some wallets, it was checking step by step specific repositories or registry keys then processing into some loops and tasks for fetching the credentials. Nowadays, this step has been removed (for the browser part) and being part of this raw grabber that will parse everything starting to %USERS% repository.
As usual, all the variables that contain required files are obfuscated and encrypted by a simple XOR algorithm and in the end, this is the "static" list that the info stealer will be focused
|Login Data||Chrome / Chromium based||Copy & Parse|
|Cookies||Chrome / Chromium based||Copy & Parse|
|Web Data||Browsers||Copy & Parse|
|History||Browsers||Copy & Parse|
|formhistory.sqlite||Mozilla Firefox & Others||Copy & Parse|
|cookies.sqlite||Mozilla Firefox & Others||Copy & Parse|
|wallet.dat||Bitcoin||Copy & Parse|
|.sln||Visual Studio Projects||Copy filename into Project.txt|
|main.db||Skype||Copy & Parse|
|logins.json||Chrome||Copy & Parse|
|signons.sqlite||Mozilla Firefox & Others||Copy & Parse|
|places.sqlite||Mozilla Firefox & Others||Copy & Parse|
|Last Version||Mozilla Firefox & Others||Copy & Parse|
Grabber n°2 (The dynamic one)
There is a second grabber in Predator The Thief, and this not only used when there is available config loaded in memory based on the first request done to the C&C. In fact, it's also used as part of the process of searching & copying critical files coming from wallets software, communication software, and others...
The "main function" of this dynamic grabber only required three arguments:
- The path where you want to search files
- the requested file or mask
- A path where the found files will be put in the final archive sent to the C&C
When the grabber is configured for a recursive search, it's simply adding at the end of the path the value ".." and checking if the next file is a folder to enter again into the same function again and again.
In the end, in the fundamentals, this is almost the same pattern as the first grabber with the only difference that in this case, there are no parsing/analyzing files in an in-depth way. It's simply this follow-up
- Find a matched file based on the requested search
- creating an entry on the stolen archive folder
- setting a handle/pointer from the grabbed file
- Save the whole content to memory
Of course, there is a lot of particular cases that are to take in consideration here, but the main idea is like this.
What Predator is stealing in the end?
If we removed the dynamic grabber, this is the current list (for 3.3.2) about what kind of software that is impacted by this stealer, for sure, it's hard to know precisely on the browser all the one that is impacted due to the generic grabber, but in the end, the most important one is listed here.
- Authy (Inspired by Vidar)
- Battle.net (Inspired by Kpot)
- Mozilla Firefox (also Gecko browsers using same files)
- Chrome (also Chromium browsers using same files)
- Internet Explorer
- Unmentioned browsers using the same files detected by the grabber.
Also beside stealing other actions are performed like:
- Performing a webcam picture capture
- Performing a desktop screenshot
There is currently 4 kind of loader implemented into this info stealer
For all the cases, I have explained below (on another part of this analysis) what are the options of each of the techniques performed. There is no magic, there is nothing to explain more about this feature these days. There are enough articles and tutorials that are talking about this. The only thing to notice is that Predator is designed to load the payload in different ways, just by a simple process creation or abusing some process injections (i recommend on this part, to read the work from endgame).
Something really interesting about this stealer these days, it that it developed a feature for being able to add the additional tasks as part of a module/plugin package. Maybe the name of this thing is wrongly named (i will probably be fixed soon about this statement). But now it's definitely sure that we can consider this malware as a modular one.
When decrypting the config from check.get, you can understand fast that a module will be launched, by looking at the last entry...
This will be the name of the module that will be requested to the C&C. (this is also the easiest way to spot a new module).
The first request is giving you the config of the module (on my case it was like this), it's saved but NOT decrypted (looks like it will be dealt by the module on this part). The other request is focused on downloading the payload, decrypting it and saving it to the disk in a random folder in %PROGRAMDATA% (also the filename is generated also randomly), when it's done, it's simply executed by ShellExecuteA.
Also, another thing to notice, you know that it's designed to launch multiple modules/plugins.
Clipper (Optional module)
The clipper is one example of the Module that could be loaded by the module manager. As far as I saw, I only see this one (maybe they are other things, maybe not, I don't have the visibility for that).
Disclaimer: Before people will maybe mistaken, the clipper is proper to Predator the Thief and this is NOT something coming from another actor (if it's the case, the loader part would be used).
This malware module is developed in C++, and like Predator itself, you recognized pretty well the obfuscation proper to it (Stack strings, XOR, SUB, Code spaghetti, GetProcAddress recreated...). Well, everything that you love for slowing down again your analysis.
As detailed already a little above, the module is designed to grab the config from the main program, decrypting it and starting to do the process routine indefinitely:
- Open Clipboard
- Checking content based on the config loaded
- If something matches put the malicious wallet
The clipper config is rudimentary using "|" as a delimiter. Mask/Regex on the left, malicious wallet on the right.
1*:1Eh8gHDVCS8xuKQNhCtZKiE1dVuRQiQ58H| 3*:1Eh8gHDVCS8xuKQNhCtZKiE1dVuRQiQ58H| 0x*:0x7996ad65556859C0F795Fe590018b08699092B9C| q*:qztrpt42h78ks7h6jlgtqtvhp3q6utm7sqrsupgwv0| G*:GaJvoTcC4Bw3kitxHWU4nrdDK3izXCTmFQ| X*:XruZmSaEYPX2mH48nGkPSGTzFiPfKXDLWn| L*:LdPvBrWvimse3WuVNg6pjH15GgBUtSUaWy| t*:t1dLgBbvV6sXNCMUSS5JeLjF4XhhbJYSDAe| 4*:44tLjmXrQNrWJ5NBsEj2R77ZBEgDa3fEe9GLpSf2FRmhexPvfYDUAB7EXX1Hdb3aMQ9FLqdJ56yaAhiXoRsceGJCRS3Jxkn| D*:DUMKwVVAaMcbtdWipMkXoGfRistK1cC26C| A*:AaUgfMh5iVkGKLVpMUZW8tGuyjZQNViwDt|
There is no communication with the C&C when the clipper is switching wallet, it's an offline one.
When the parameters are set to 1 in the Predator config got by check.get, the malware is performing a really simple task to erase itself from the machine when all the tasks are done.
By looking at the bottom of the main big function where all the task is performed, you can see two main blocs that could be skipped. these two are huge stack strings that will generate two things.
- the API request "ShellExecuteA"
- The command "ping 127.0.0.1 & del %PATH%"
When all is prepared the thing is simply executed behind the classic register call. By the way, doing a ping request is one of the dozen way to do a sleep call and waiting for a little before performing the deletion.
This option is not performed by default when the malware is not able to get data from the C&C.
There is a bunch of files that are proper to this stealer, which are generated during the whole infection process. Each of them has a specific meaning.
- Signature of the stealer
- Stealing statistics
- Computer specs
- Number of users in the machine
- List of logical drives
- Current usage resources
- Clipboard content
- Network info
- Compile-time of the payload
Also, this generated file is literally "hell" when you want to dig into it by the amount of obfuscated code.
I can quote these following important telemetry files:
- Windows Build Version
- Generated User-Agent
- List of software installed in the machine (checking for x32 and x64 architecture folders)
- List of actions & telemetry performed by the stealer itself during the stealing process
- List of SLN filename found during the grabber research (the static one)
- List of cookies content fetched/parsed
Sometimes features are fun to dig in when I heard about that predator is now generating dynamic user-agent, I was thinking about some things but in fact, it's way simpler than I thought.
The User-Agent is generated in 5 steps
- Decrypting a static string that contains the first part of the User-Agent
- Using GetTickCount and grabbing the last bytes of it for generating a fake builder version of Chrome
- Decrypting another static string that contains the end of the User-Agent
- Concat Everything
Tihs User-Agent is shown into the software.txt logfile.
There is currently 4 kind of request seen in Predator 3.3.2 (it's always a POST request)
|api/check.get||Get dynamic config, tasks and network info|
|api/gate.get ?……||Send stolen data|
|api/.get||Get modular dynamic config|
|api/.post||Get modular dynamic payload (was like this with the clipper)|
The first step - Get the config & extra Infos
For the first request, the response from the server is always in a specific form :
- String obviously base64 encoded
- Encrypted using RC4 encryption by using the domain name as the key
When decrypted, the config is pretty easy to guess and also a bit complex (due to the number of options & parameters that the threat actor is able to do).
[0;1;0;1;1;0;1;1;0;512;]#[[%userprofile%\Desktop|%userprofile%\Downloads|%userprofile%\Documents;*.xls,*.xlsx,*.doc,*.txt;128;;0]]#[Trakai;Republic of Lithuania;54.6378;24.9343;184.108.40.206;Europe/Vilnius;21001]##[Clipper]
It's easily understandable that the config is split by the "#" and each data and could be summarized like this
- The stealer config
- The grabber config
- The network config
- The loader config
- The dynamic modular config (i.e Clipper)
I have represented each of them into an array with the meaning of each of the parameters (when it was possible).
|Field 1||Webcam screenshot|
|Field 2||Anti VM|
|Field 5||Desktop screenshot|
|Field 7||Self Destroy|
|Field 9||Windows Cookie|
|Field 10||Max size for files grabbed|
|Field 11||Powershell script (in base64)|
|Field 1||%PATH% using "|" as a delimiter|
|Field 2||Files to grab|
|Field 3||Max sized for each file grabbed|
|Field 5||Recursive search (0 - off | 1 - on)|
|Field 3||GPS Coordinate|
|Field 4||Time Zone|
|Field 5||Postal Code|
- Loader URL
- Loader Type
- Targeted Countries ("," as a delimiter)
- Blacklisted Countries ("," as a delimiter)
- Arguments on startup
- Injected process OR Where it's saved and executed
- Pushing loader if the specific domain(s) is(are) seen in the stolen data
- Pushing loader if wallets are presents
- Executing in admin mode
- Random file generated
- Repeating execution
Loader type (argument 2)
Architecture (argument 3)
|1||x32 / x64|
If it's RunPE (argument 7)
If it's CreateProcess / ShellExecuteA / LoadLibrary (argument 7)
The second step - Sending stolen data
- Sending stolen data
- Also victim telemetry
|p10||OS Version (encrypted + encoded)*|
This is an example of crafted request performed by Predator the thief
Third step - Modular tasks (optional)
Give the dynamic clipper config
Give the predator clipper payload
The C&C is nowadays way different than the beginning, it has been reworked with some fancy designed and being able to do some stuff:
- Modulable C&C
- Classic fancy index with statistics
- Possibility to configure your panel itself
- Dynamic grabber configuration
- Telegram notifications
- Tags for specific domains
The predator panel changed a lot between the v2 and v3. This is currently a fancy theme one, and you can easily spot the whole statistics at first glance. the thing to notice is that the panel is fully in Russian (and I don't know at that time if there is an English one).
Menu on the left is divide like this (but I'm not really sure about the correct translation)
- Логов (Logs)
- По странам (Country stats)
- Лоадера (Loader Stats)
- Загрузить модуль (Download/Upload Module)
- Настройки сайта (Site settings)
- Телеграм бот (Telegram Bot)
- Конфиг (Config)
Конвертация (Converter => Netscape Json converter)
Statistics / Landscape
In term of configuring predator, the choices are pretty wild:
- The actor is able to tweak its panel, by modifying some details, like the title and detail that made me laugh is you can choose a dark theme.
- There is also another form, the payload config is configured by just ticking options. When done, this will update the request coming from check.get
- As usual, there is also a telegram bot feature
Creating Tags for domains seen
Small details which were also mentioned in Vidar, but if the actor wants specific attention for bots that have data coming from specific domains, it will create a tag that will help him to filter easily which of them is probably worth to dig into.
The loader configuration is by far really interesting in my point of view and even it has been explained totally for its functionalities, I considered it pretty complete and user-friendly for the Threat Actor that is using it.
Hashes for this analysis
p_pckd.exe - 21ebdc3a58f3d346247b2893d41c80126edabb060759af846273f9c9d0c92a9a
p_upkd.exe - 6e27a2b223ef076d952aaa7c69725c831997898bebcd2d99654f4a1aa3358619
p_clipper.exe - 01ef26b464faf08081fceeeb2cdff7a66ffdbd31072fe47b4eb43c219da287e8
Other predator hashes
Infostealer is not considered as harmful as recent highly mediatize ransomware attacks, but they are enough effective to perform severe damage and they should not be underrated, furthermore, with the use of cryptocurrencies that are more and more common, or something totally normal nowadays, the lack of security hygiene on this subject is awfully insane. that I am not surprised at all to see so much money stolen, so they will be still really active, it's always interesting to keep an eye on this malware family (and also on clippers), whenever there is a new wallet software or trading cryptocurrency software on the list, you know easily what are the possible trends (if you have a lack of knowledge in that area).
Nowadays, it's easy to see fresh activities in the wild for this info stealer, it could be dropped by important malware campaigns where notorious malware like ISFB Gozi is also used. It's unnecessary (on my side) to speculate about what will be next move with Predator, I have clearly no idea and not interested in that kind of stuff. The thing is the malware scene nowadays is evolving really fast, threat actor teams are moving/switching easily and it could take only hours for new updates and rework of malware by just modifying a piece of code with something already developed on some GitHub repository, or copying code from another malware. Also, the price of the malware has been adjusted, or the support communication is moved to something else.
Due to this, I am pretty sure at that time, this current in-depth analysis could be already outdated by some modifications. it's always a risk to take and on my side, I am only interested in the malware itself, the main ideas/facts of the major version are explained and it's plenty sufficient. There is, of course, some topics that I haven't talk like nowadays predator is now being to work as a classic executable file or a DLL, but it was developed some times ago and this subject is now a bit popular. Also, another point that I didn't find any explanation, is that seeing some decrypting process for strings that leads to some encryption algorithm related to Tor.
This in-depth analysis is also focused on showing that even simple tricks are an efficient way to slow down analysis and it is a good exercise to practice your skills if you want to improve yourself into malware analysis. Also, reverse engineering is not as hard as people could think when the fundamental concepts are assimilated, It's just time, practice and motivation.
On my side, I am, as usual, typically irregular into releasing stuff due to some stuff (again...). By the way, updating projects are still one of my main focus, I still have some things that I would love to finish which are not necessarily into malware analysis, it's cool to change topics sometimes.