We present a very interesting malware analysis by Andreas Venieris who published exclusively the friendly SecNews.gr.
The distinguished security researcher IT Director / CIO Andreas Venieris has detected an extremely "persistent" spyware malware that steals personal information and installs on the terminal of unsuspecting users.
As we have announced, SecNews EXCLUSIVITY presents the extensive malware analysis conducted by one of the most experienced and distinguished Greek security researchers, Mr. Andreas Venieris. Mr. Venieris, by the most important collaborators of SecNews, has managed to analyze to a very large extent this software that has a specialized hiding functionality that has not been observed, at least in Greece!
The article is TECHNICAL, but given in the characteristic & special way of writing articles by Mr. Venieris, super-analytical and step-by-step so that it can be understood by almost everyone with average networking and programming skills. The files studied by the researcher can be found at the end of the article.
It is no exaggeration if we dared to say that his current article Mr. Venier constitutes an excellent manual (doctoral level) that could comfortably be used in university institutions as a sample of excellent writing and malware study! Well done!
Read below, without cuts, the study:
Active Malware- Analysis
Current Malware seems to be a variant of the Poweliks or Gootkit Trojan (http://support.eset.com/kb3587/). It's a malware that seems to be logging on to the registry and running there.
Before I start, I would like to clarify the following:
• The article does not make a 100% resolution (with all possible combinations) because it would simply not reach 100 pages. As a result, the article in many places provides food for additional research.
But let's take it from the beginning: Some time ago some users received a strange email and asked if they should open it.
The email contained an attachment titled: Notice_to_Appear_00000443430.zip (I attach it as a separate file). Zip contained a file with extension .js (jacascript). Making extract and opening the file seems to be obfuscated code:
The code appears in a compact form (for reasons of space economy):
After a quick study of it, it appears that the code is dynamically generated during program run, and finally it is entered into a final variable and then executed. So I decide to make 1 a known (and simpler) "decipherment" trick of the code, which assumes that the last function you are running is that it contains the final code, that is, the glnu ().
So I go to the main body of glnu () and I do it:
Immediately afterwards I paste the above code into an HTML file and run it locally. I get the following:
If we look well, the code that goes to run is as follows:
This is a JavaScript code that still does not look very good, so after putting it into a good JavaScript Formater, I got the following:
In general, what the above code does is try to download some files from the following domains:
- lincolnracing.com
- groupformingservices.com
- ncdivers.com
The following will in essence be executed:
http://www.lincolnracing.com/counter/?id=&rnd=9749811
http://www.groupformingservices.com/counter/?id=&rnd=9749811
http://ncdivers.com/counter/?id=&rnd=9749811
http://www.lincolnracing.com/counter/?id=&rnd=9749812
http://www.groupformingservices.com/counter/?id=&rnd=9749812
http://ncdivers.com/counter/?id=&rnd=9749812
http://www.lincolnracing.com/counter/?id=&rnd=9749813
http://www.groupformingservices.com/counter/?id=&rnd=9749813
http://ncdivers.com/counter/?id=&rnd=9749813
The above requests through javascript will download a file and write it to the disk (in the directory% temp% \ 669736, that is, in my case in C: \ Users \ venieris.a \ AppData \ Local \ Temp \ 669736 as executable files with EXE extension.) Immediately afterwards, it will be executed. In short, it is the Trojan's forerunner, that is, his "barking" (the one who will ... shout from where he is hiding!).
I tried to download files from the above links and currently only "play" what is from ncdivers.com and at www.groupformingservices.com. They downloaded the following three files:
28bf195b.gif
b.gif
b421486cdb15d58a.gif
As you can imagine (don't be fooled by the GIF extension) these are PE executables, as shown by the classic Header shown in a hex editor:
By renaming it to EXE (that's what the javascript code does) we have a ready executable:
I also found that all of the above files that were downloaded were exactly the same:
(I put you in the list Bad.EXEs)
So the javascript pre-transmitter program is probably downloading the basic trojan and even where it succeeds on the above servers ...
What we now have to do is look at what exactly this executable does when executed. My first choice is VirusTotal:
Hmm, the results are not so encouraging. Only 4 from 55 machines suspected that something creepy "runs" here ... So we are likely to be close to a relatively unknown (or well-encrypted) execution code. A good opportunity to analyze it myself.
First of all I take a look at it with a hexeditor. Interesting opinions of Trojan developers took place while reading:
Also interesting are some file infos within the executable, such as:
Although I will not go into a detailed offline analysis of executable, it is worth noting the use of "enough" SQL within the program (IDA Pro analysis):
A very efficient way to quickly check the behavior of a malware is to run it in one Virtual Machine, after first taking an Image Backup to restore it when you want to revert to a clean system at any time, cok.
I have to say that both the original javascript and the executable "anxious" especially the antivirus (both Nod and Windows Antivirus) and if you want to check it properly you have to disable it.
So I'm putting a Windows 7 VM on the front and running the b.exe bad. Here is an analysis:
Few Windows Processes and a Little Registry
As soon as the program starts running, the following "nice" processes occur along with TCP Live Connections:
In the beginning it seems to run for a few seconds the executable B.exe, after a while it closes and another process (known and not excluded) is called Powershell.exe (call me Command Executor!), Which also runs for some seconds and immediately closes and regsvr32.exe gets up and remains active.
Also, just before the Powershell launches, another process, mshta.exe, is still coming up. This process belongs to the Microsoft Windows Application Process and belongs to the family of Internet Explorer utilities. This Process runs with the following parameters:
More analytically, run the following:
The above code raises the command line shell and runs in javascript (with the help of mshta.exe) that is located within the Registry Key: HKCU \\ software \\ eebx7Aeby \\ 6tCMbfD3a (where HKCU = HKEY_CURRENT_USER)
But as I imagined, when I went to the Registry to check the value of that key, it did not exist ... Conclusion, we turn the VM into a clean state, re-run b.exe having this time open Registry Editor in that node by constantly refreshing f5) hoping that at some point we will see that the above key is made. In fact, we're gripping the key which is a bit ... encrypted:
We can not immediately get the above values because they just appear after they are deleted. Of course there are ways, but let's continue below if we find other interesting things.
Indeed, with the next refresh we see that another registry value has been created in this registry, this time constant:
Check out the best:
First we must say that all the variables (Name) used are random, that is, each time the malware runs they have a different name. We must also say that the above probably accesses a server and this is because the variable 456a6457 contains a value that appears to belong to a User Agent. I imagine that the rest of the encrypted values will probably be the URL as well as some values of the HTTP Headers to make the access. E.g. 864 might be the remote port.
TCP Connection
At the time of the above, an equally important energy is done in the communication of our computer with the "outside" world. This is what we see with SysInternal TCP Viewer. As soon as RegSvr32 runs, the following occur:
Give a base to the first process that seems to be the real Trojan through which the others open. Beats http://kysungobu.fvds.ru/
Right now the above address reports a database connection error, but when I did the tests, it was strange ...:
Maybe our friend wants to tell us something… do not you agree? ;)
Infinite time if someone can spend looking one by one for the above directories that seem to act as Zombie.
A little more Window Process
Let's go a little bit back to the processes and using SysInternals Process Explorer I will be a bit more strict with one of them. I will try to "freeze" the powershell.exe process when called from Trojan to look at it with my quietness. This will happen if I click Suspend as soon as I get started:
Immediately then go to properties:
Give a base to the parent process. It is mshta.exe that we saw above! This process calls powershell by passing the rppd variable as parameter (specifically as a environment variable). Something tells me that within this variable is hidden the encrypted value that started its "life" by the temporary Registry Value and that the trojan strives to preserve in every way!
Going to TAB Environment, things get clearer:
We have the value of the rppd environment variable just as it comes from the Trojan. I must definitely prick this honor because something tells me she has ... "bread"! So I'm trying a full dump of memory to see if it hides somewhere in there:
The results after a while of searching are encouraging:
I have finally managed to pinch the value of the variable in encrypted form though. Of course, as you can see, the encryption is Base64, i.e. just a piece of cake to break with a simple Base64 decoder and give us the desired result:
For space reasons, the binary-code piece containing the above is abbreviated (the whole is within the TheBadPowershell_formated.ps1 file).
I will not proceed to line-line analysis of the above code. Only a few say: This is a powershell script that uses a ready process in binary format (entered in the $ sc32 variable which appears to be inject at the start of Kernel32.DLL.
The query now is what exactly does this binary-code of the variable $ sc32?
It does not stand alone as executable. I tried this as follows. With the following C ++ program I put the binary-code into a executable:
(the executable extracted from the above you have in the file theEXE.exe)
I do compile and run:
And I try to run the final executable produced:
Ok .. maybe something did not go well ... But give the basis to: "16bit MS-DOS Subsystem", wtf !!
Let's also upload it to Virus total:
0 / 55? Innocent; I do not think!!
Let's go straight, run it straight from the Power Shell IDE:
Hm, .... We're eating a door! We have disabled running scripts ...? That's bad! I can not do it while the Trojan can! Interesting with ?! Do not say no!
To be able to run Powerscript Commands, I need to enable them with the following command: Set-ExecutionPolicy RemoteSigned
So let's do it to see if you run this script and what it does ... with a few attempts to run the program "kicked out" either without a message or with the known ... powershell has stopped working.
From the result, however, it seems that this is the process that after the injection tries to communicate with the various zombies…;)
Check if it affects Files
This check is simple and is done as follows:
Step 1: We start Windows in a clean environment and write in a text file all file names (hidden and not in all directories and subdirectories) that are on our disk. This will be done with the following simple command (from Command Line of course!):
A file that has changed and drew attention is PowerShell.evtx located in the Directory of C: \ Windows \ System32 \ winevt \ Logs
This is a file that the operating system records logs from program and process movements:
Moving on I find something equally interesting:
NTUSER.DAT is in the C: \ Users \ thiseas directory. It is a hidden file and contains entries in the registry under HKEY_CURRENT_USER. After the attack, it grew by 2Mb ... Interesting!
If we want to compare (file compare by content) the ntuser.dll file before and after the attack, we will have to mount the Windows disk with another operating (eg with some linux live CD distro) and go into disk to stamp the file. If we did this, we would see the following interesting differences:
For those who can not clearly understand the javascript code hidden here let them not be disappointed, we will have the opportunity to see it better, below;)
Important Note: I did not notice any other significant changes to the files. Consequently, malware only affected Registry!
Check if it affects Registry
By analogy with what we did in the previous paragraph for all the files on the disk, we will do it for the Registry by doing the export (before and after). This way we will see what changes the malware made to the Registry. An interesting introduction I found is the following:
The registry here tells us that malware has kept itself encrypted here.
If you do the above, make sure you do not confuse the malware moves with some legitimate moves that are recorded as well, like let's say what we did to export the registry to a file:
Behavior at startup
All right here. We've seen exactly where malware comes in and how it's hidden in our system. But to make a restart to see if it still exists. Indeed, after the start it seems that the problem in our box has not been corrected since the bizarre TCP / IP connections are still running:
Ok, before I analyze it, let's see Malware's behavior in "unpredictable" situations. I delete regsvr32.exe and reboot again to see what happens. Will the wolf ... wake up?
Indeed the bad wolf has awakened and now stuck to rundll32.exe. Ok, I also delete run32.exe and restart, ... To see:
This time Malware hangs in process explorer.exe! Our basic environment. Impressive!
But how the hell does Malware start??? File comparisons showed me no changes in either the Run Registry or even that ancient autoexec.bat file or the user's Start. Tools like SysInternals' Autoruns don't show me anything special:
So let me start looking manually. Somewhere in the above entries he must be hiding. No other way. So I open the regedit and I'm going to open the first entry that's favorite of everywhere malware:
You are welcome; What is going on here; Broken my registry? Symantec's reference to the really great "The Evolution of the fileless click-fraud malware Poweliks" (http://goo.gl/TfcHm3) comes to my mind:
The protection mechanism used here prevents the subkey from being opened. This in turn prevents the subkey from being deleted. This is achieved when Poweliks creates a subkey in Unicode with a ObjectName of 0608 that prevents users, even those with administrator privileges, from reading or deleting it. With tricks like these, it is obvious that the creators of Poweliks have an intimate knowledge of the Windows registry
Indeed, attempts to change or delete the Run key while showing that they succeed, in refresh all appear as before. Here it appears that Microsoft developers in the exception of try at deletion decided that they should not inform the user ...
So this is where our friend hides and runs every time that particular user starts. And it seems I can not turn it off! Do not be disappointed though, there is a way… Keep Reading;)
Behavior with user and / or admin rights
I also found that either the user has Administrator rights or simple users, the result is the same. Also impressive!
Behavior Windows Security Antivirus: Yes but ...
Windows Antivirus has to say that it's anxious enough to see all these "joyful" happen and take action:
In fact, he informs us that this action is a success. But it's a jerk ... J
The malware still lives on our Registry Run!
Can I get rid of it?
Although the best treatment is prevention, the question here is, what if I screw it up? Can I do anything besides Restore[*]?
*: I say Restore assuming you are holding backups! I do not know not to hold ...!
I managed to "kill" it as follows:
Πάτησα διαγραφή του Run key του συγκεκριμένου Registry location (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run) αλλά από κατάσταση Safe Mode και το κλειδί διαγράφηκε. Με ένα refresh είδα ότι ξαναφτιάχτηκε αυτόματα το key αυτό, από το λειτουργικό, αλλά αυτή την φορά χωρίς την κακιά enrollment inside him. It was absolutely clean!
Beginning after the system all seemed calm ... But was it? (till next attack !!)
Happing Reversing!
Andreas Venieris
We would like to congratulate SecNews's editorial team, Mr. Venieri, for a thorough analysis. Rarely (we have to confess) we find a corresponding high-level article, only on corresponding websites abroad!
It is a wonderful example to follow and we hope that Mr. Venieris' private initiative will find other supporters. He proves with his analysis that there are actually excellent experts in Greece who are active in background, offering a wealth of knowledge, pushing the information security industry several steps further. And of course without being advertised through the (admittedly boring now) marketing conferences, "security experts" whose sole goal is to sell products of (dubious?) effectiveness.
You can find the full analysis files as it sent them to us Mr. Venieris at the link [here]. The decryption code of the file is the word: "venieris_iguru" (without quotes)
At one point, we need to see other active Greek researchers either from university institutions (we can see that little or often irrelevant issues are made public) or from individuals making corresponding publications of the highest level with those of Mr. Venieris.
