ad_1_.jpg unpacking/analysis - Aurora
In this post we'll try to run Aurora as non-administrative user, and debug ad_1_.jpg which used by the attackers right after the attack. Well, I was very curious about other files in the attack, after not able to unpack the msconfig32.sys, and thought, maybe other files will give me clues on msconfig32.sys and might give me a way of unpacking it.
I've looked into USCERT advisory regarding the Aurora attack, and saw interesting file, with no explain of what it does, named ad_1_.jpg, it says that the file is XOR'd with 0x95, but nothing else :
Original advisory looked like this :
I've looked into USCERT advisory regarding the Aurora attack, and saw interesting file, with no explain of what it does, named ad_1_.jpg, it says that the file is XOR'd with 0x95, but nothing else :
Original advisory looked like this :
So it got me curious. I got the file from my friends where I write as-well : malwareint.com
It took me a while to get from this file in the advisory to the original file, the problem was, that I didn't know on how this file got dropped and that what was hard to find out how the attacker opened it in the computer of the victim. It wasn't very important if the file wasn't also packed with other packer (UPX) so every byte was important to be restored as original.
I've understood how to DeXOR it correctly (it was XOR to every byte which is not 0x00 or 0x95, with 0x95), attached python algorithm for it :
I've understood how to DeXOR it correctly (it was XOR to every byte which is not 0x00 or 0x95, with 0x95), attached python algorithm for it :
After unpacking the file to the original file (inside the UPX), I've uploaded it to virustotal, and saw the file was analyzed in the beginning of February (now, 36 out of 40 Anti-Virus catches it).
So, I had it in mind that the file might have been already analyzed, and after analyzing it myself, I've seen that the reports I've read, were from this file (Service creation name, querying important files such as rasmon.dll). So people have already analyzed it for us. I get to save time.
I also wanted to check 2 interesting stuff :
1. Why there was used a BAT file in the attack (and what it did?).
2. Can the attack run as simple user (not admin).
The answer for 1 was simple, (file name was : c:\windows\DFS.bat)
after quick reverse-engineering tricks you can get the value of it before it's deleted :
The batch file supposed to run in loop and wait for the handle that catches the exe to allow it to be deleted. If it's not deleted, it will try again. After the file was deleted (it uses dynamic name, that's why it's running from my desktop[on VM]), it deletes the bat file himself. Actually it's a nice trick to verify deletion of exe file after it's done executing, because deleting the exe within the file himself will not succeed without any trick (handle will be locked).
A little tip to this module-writer would be : next time use the /f on del command, it might give you better chances :P
2. Did it work as non-administrative-user? It didn't work as a normal user and didn't try to use any kind of privilege escalation while I was testing it. It also failed doing changes in the registry, and dropping files on c:\windows.
I didn't test it too much because of what I said above (that it's already got tested by others), but from a regular behavior-check tests, it didn't work as non-administrative user.
What can we learn from 2? That if Google have used proper user rights on their computer, initial installation of Aurora, wouldn't have work. It appears that non-admin user would have been enough since the exploit which the attackers used, runs remote code as the user who run internet-explorer.
Regarding the msconfig32.sys? Well... I've tried to implement my unpacker to do the same here, didn't go quite well yet. But I still got hope on this one :). For Mcafee, I wouldn't say it's not related to the attack, I actually think it is :
Two patterns which we see here :
1. Both files used some kind of repeating XOR in every section of the file.
2. Both files used different extension for the file from what it really was.
Under this scenario I'd say that they are related and from the same authors in the attack. Sorry Mcafee,
If it was up to me to decide, I would have suggested USCERT to put msconfig32.sys back on their advisory if it was up to me to decide.
source:imthezuk
Category Article Hacking
