Another day, another ransomware! It seems Brazil has been facing a ransomware wave and this time Embraer, the Brazilian aircraft manufacturer, was the target (Check news here). Here our brief analysis goes.
The file said to have attacked Embraer is available in our sandbox solution (link here). It is a 32-bit PE file, even though we could not parse this information directly from the PE header (see figure below). We could also not parse the subsystem. Something is weird in this binary!
If we extend our analysis to the compilation timestamp (figure below), it says it was compiled in 1969. But this field should start from 1970…OK, it is tampered!
This file is detected in virustotal (link here). Although it is detected, the labels do not provide clear information about which sample it is. Important to notice that we did not submit the file there, just searched for it using its hash. So, someone else already had access to this sample before us. Additional search in malware databases (link here) reveal that his sample might be a RansomExx variant.
Let’s look for something more indicative. Maybe a known string. The figure below shows what we got. The name of the ransom note file follows the same format as the RansomExx sample that targeted a Brazilian Justice Court (our analysis here). Interesting to notice that the string is only displayed in a double word encoding (be careful to not miss that!). More than that, the EMBRAER string in the name shows that the attackers knew what they were attacking.
Analyzing this string gives also other hints. Notice that IDA can’t find cross-references for the string address. This suggests that the code that references it is generated in runtime! Notice the N0E0W0S0 string in the background.
Delving into details, we find that this file has only two exports: an entry and a reflective loader function. Suspicious!
But, a reflective loader? like in DLLs? A Yara rule to detect generic loaders (link here) suggests that it might indeed be a loader.
OK, so a reflective injection, we know how it works, we even gave a talk about it last week (check it here). Makes sense, this kind of loading is getting common in many ransomware families (check here). In fact, a few minutes of ghidra decompilation reveals to us this part of the loader (figure below): the search for the 0x5a4d (‘MZ’) magic. I know what you are looking for in memory!
But there is something different in this binary, it does not have the DLL Characteristic set. So what? Maybe a stageless payload? (check it here). In fact, the binary does not have a WinMain function, but only an assembly-like code written directly at the entry point. Likely the bootstrap code.
Nice, now we know what the binary does and how it does. Let’s just run. And a surprise! It crashes in our sandbox and crashes in external ones too (check the link here). Debugging a little bit we can have an idea of what happens. This binary has a very intricate operation. Many internal function calls return addresses of other code excerpts to be called. For instance, the figure below shows that the __alloca_probe function returns an address that is referenced by the following instructions. The execution crashes in the instruction pointed by EIP. It seems that we are referencing an invalid address. Maybe the binary is expecting to be run in a specific location or injected somewhere.
If you manage to run it and have your system infected, the ransom note will redirect you to an onion link. In fact, we could have known it since the beginning because it was stored as a plain string (see the figure below).
Right now, if we open this link in a Tor browser (figure below), we got the leak of the stolen files, since Embraer did not pay the ransom (check here).
This post will be updated with more information as the analysis proceeds.
