Attack attribution is always a very hard work. False Flags, Code Reuse
and Spaghetti Code
makes impossible to assert “This attack belongs to X”. Indeed nowadays makes more sense talking about Attribution Probability rather then Attribution by itself. “This attack belongs to X with 65% of attribution probability” it would be a correct sentence.
I made this quick introduction because the following analysis would probably take the reader to think about specific attribution, but it wont be so accurate, so please be prepared to have not such a clear conclusions.
Today I’d like to show an interesting analysis of a quite new InfoStealer Malware delivered by eMail to many International Companies. The analysis shows up interesting Code Reuse capabilities, apparently originated by Japanese Attackers reusing an English Speaker Attacker source code. Again I have not enough artifacts to give attributions but only few clues as follows. In the described analysis, the original sample was delivered by firstname.lastname@example.org (with high probability a compromised South Africa account) to one of my spamming email addresses.
The obtained sample is a Microsoft Word document within macro in it. The macros were heavily obfuscated by using four rounds of substitutions and UTF-8 encoding charsets (which, by the way, is super annoying). The following image shows the obfuscated macro code with UTF-8 charsets.
|Stage 1: Obfuscation
By using oletools
and “tons” of cups of coffee (to be awake until late night to make recursive steps) I finally was able to extract the invoked command, showed in the following image.
|Stage 1: Invoked Command
A fashionable powershell command drops and executes: hxxp://ssrdevelopments.co.za/a2/off.exe. Powershell seems to be a “must have” in contemporary Malware. Analyzing the “dropping” url and tracking down the time it is in “Index Of” mode (2017-0-13), I suspect it is not a compromised website rather a crafted web server or a compromised host of a dead company.
|Dropping Web Site
By surfing on the Malware propagator web site I founded out many malicious executables (sees IoC section) each one showing up specific behaviors such as: password stealers, RAT and Banking Trojans. Even if the samples were developed for different targets, all of them shared the following basic behaviors:
- Check for victims IP address before getting into Malicious activities (maybe related to targeted activities)
- Install itself into auto execution path
- Tries to fingerprint the target system (such as CPU, HD, Memory, Username, System, etc..)
- Sniff for Keystrokes
I’d like to write a simple analysis for each found sample, but today time is not my friend, so let’s focalize to one of the malicious samples. Let’s get done the received sample by digging into the “second stage” dropped by the powershell “first stage” from ssrdevelopments.co.za/a2/off.exe. After few seconds on second stage (off.exe) it became clear that it was a .NET software. By reversing the interpreted .NET language some clear text comments appeared interesting. Japanese language such as comments and variable names came out from static analysis. Let’s have a look to them.
|Stage 2: Apparently Japanese characters
While the sample pretends to be compiled from “Coca-Cola Enterprise” (maybe a target operation against Coca-Cola ? Or a targeted operation agains Coca-Cola Suppliers ? So why it ended up to my inbox ? Anyway … ) google translator suggests me that Japanese characters are in text: such as the “Entry Point”, “Class names” and “Function Names”.
|Stage 2: Japanese Names and Self Encoding Structures
It was not hard to figure out that Stage 2 was auto-extracting bytes from itself (local variables) and saving them back to hard drive after having set up auto execution registry key on windows local registry. The following image shows the xoring function used to decrypt converted bytes to the real payload.
|Stage 2: Xoring function to extract Stage 3
On my run, the xored payload took the name of GIL.exe; another .NET executable. We are now facing the third stage. By analyzing the decompiled sample it became clear that:
- The coding style was quite different from the previous stage (Stage 2)
- The implementation style was different from the previous stage as well
- The sample was interested on information about the user, the machine, the webservices on the PC and to many more windows specific parameters.
|Stage 3: New Language in Strings and Class names
|Stage 3: New Code Style
By closely investigating Stage 3, the analyst would probably notice the heavy presence of “decorators”, a different format in the definition style and last but not least the code composition. Everything looks like belonging to different single developers. The variable language, the comments structure and the general usage of terms, takes the analyst to believe in having found two different developers belonging to different cultures (maybe countries). Finally the malware looks for users, computes, and webservices informations and drops everything up to C2 by posting parameters to : ssrdevelopments.co.za/cgi-bin/
Following the principal IoC for the described threat.
- Hash Stage 1:
- Hash Stage 2:
- Hash Stage 3:
- Persistence: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\kij %APPDATA%\Roaming\kij\kij.exe
- Dropping URL:
- Command and Control:
- Related hashes from harvesting Dropping URL:
As final thought I’d like to highlight the following key concept of that analysis:
- From a single email, the analyst could discover attacker’s assets, mapping them and disarming them (through IoC).
- The analyzed code shows apparent evidences to belonging to different groups of attackers.
- The analyzed samples show code reuse. Code reuse is dangerous because it makes attackers more powerful and extremely quick to change Malware behavior.
Hope you enjoyed.
This is a Security Bloggers Network syndicated blog post authored by Marco Ramilli. Read the original post at: Marco Ramilli's Blog