Digital Express

Archive for the ‘Malware Analysis’ Category

1. Malware Analysis: Initial Steps

Malware Symptoms

The initial step inside my investigation was discovering the symptoms how the program causes. My friend informed me when he first ran the program, it induced a Blue Screen of Death, but nothing out of the ordinary occurred when he rebooted the pc. This informed me 2 aspects of the malware:

Considering that the “virus” caused a Blue Screen of Death, what this means is it smudged somewhere. Malware aims to cause only a small amount disruption as you can, since events say for example a blue screen can alert the person that something is wrong.

The malware programmer just isn’t advanced. A seasoned malware author couldn’t survive foolish enough to cause a BSOD. BSODs are often a result of mistakes for example null pointers, along with other memory reference issues. By comprehending the author, you can better understand his work.

Just in the undeniable fact that herpes caused a Blue Screen of Death, I many userful stuff here concerning the program and its particular author. By better comprehending the malware and author, I will take educated guesses regarding its amount of complexity, in addition to motivation and goals.

File Information Gathering

After going through the symptoms, I next took an incredibly brief examine parts of this program itself. I ran this over a A linux systemunix to be able to prevent accidental infection. Even then, I ran the tests on the non work related computer, then one that was isolated all networks. As with other cases involving malware analysis, its smart to get careful. The very last thing you want to happen is to accidentally infect yourself, simply to spread it for a other, more vital computers. Later, I end up using VMware for this very reason.

File: When i first run the “file” utility to determine what precisely I’m coping with. The outcome showed this:

w89e85t5.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit Mono/.Net assembly

The output informs me a couple of things. First, it’s a portable executable, meaning it really is generated for maximum portability. While this malware analysis, this will make sense, as the malware author will probably are looking for this operate on as numerous computer types as it can be. The second 50 % of the output shows us that it must be designed to are powered by 32 bit computers, and is appeared using Mono with all the.Net Framework.

Another useful tool in malware analysis is often a program called PEiD, which scans an executable for warning signs of being packed. Packers are utilities found in order to obfuscate the executable, making it tougher for reverse engineers to disassemble the malware using programs such as IDA Pro. PEiD returned due to ????”Microsoft Visual C# / Basic.NET”, confirming that.NET was used in creating the malware. The Visual C# portion also gave me more information regarding the text accustomed to create the herpes virus.

2. Malware Analysis: Virtual Pc

After finding some preliminary information regarding the malware, I next wished to begin something a little more risky, namely running the malware under a virtual computer. Rerversing malware under virtual systems has several advantages:

No worry of affecting production computers
No chance of infecting other computers on network
“Sandbox” environment
View the malware in the native habitat

However, in addition there are a number of negative points linked to running malware in virtual computers:

Some malware might be conscious of it is running under a virtual machine
Malware can try to exploit and get out of the virtual machine
If networking access isn’t cut, worms can make an effort to compromise other systems around the network

That being said, I felt positive that the huge benefits outweighed the potential for loss. From before, I needed thoughts that individual little bit of malware wasn’t advanced, therefore the chance of it detecting it was at a virtual machine and in actual fact exploiting it seemed slim. However, I became running the VM on top of Linux, so even if it did get away, it wasn’t within the system it was made to exploit (Windows).

I began up VMware on Ubuntu, and loaded a Windows XP disk image. The most important step is setting up the network correctly. I set it up which has a NAT connection, so that VMware sends the requests from the host machine towards the actual hardware. However, I made sure to hold disconnected in the network constantly. That is critical! The final thing you should do when analyzing a worm is to unleash it all on your own systems.

Using the virtual machine build, I moved everything into position, including using Wireshark to sniff traffic from VMware, which uses traffic about the vmnet8 interface.

3. Malware Analysis: Network Traffic Analysis

The initial running didn’t show greatly of anything. No Blue Screen of Death was encountered, and incredibly little network data was sent. This is what Wireshark showed:

The packets clearly show the malware trying to generate an association with 23U.NO-IP.INFO in the DNS requests it is making. As it isn’t buying a reply, we are really not getting anything further than that for the present time. A WHOIS search wound up showing no most current listings for this domain. My instincts were telling me that was almost certainly some kind of script kiddie work for balance a botnet. So, I attempted looking just a little further to the network traffic. Since i have wasn’t going to get anywhere without contacting the server itself, I could connecting the virtual machine to the network. Underneath the careful eye given by Wireshark, I watched what precisely this malware was doing. Please note this isn’t the preferred method, but I had taken all the computers in this little network down through this little experiment. Some tips about what Wireshark shows now:

Seeing that the malware can sent packets to and receive packets from the server it’s looking to hook up with, I had been capable of seeing just what this kind of program was attempting to do. I uploaded the packet capture file above. Packets 1-8 show some form of connection being create relating to the remote server and our victim computer. Packet 9 appears to be show a password being provided for the remote server, with all the password being “\google_cache2.tmp”. Then, packet 17 shows a goldmine of info: it’s the welcome message associated with an IRC channel. Bingo! The malware is surely an IRC botnet recruiter. To obtain more information, I checked out the TCP stream:

:FBI.GoV NOTICE AUTH:*** Learning about your hostname…
:FBI.GoV NOTICE AUTH:*** Couldn’t resolve your hostname; utilizing your Ip instead
PASS \google_cache2.tmp
NICK NEWXP085587
USER 1854 “” “TsGh”:1854
:FBI.GoV 001 NEWEpicBot-AUT085587
:FBI.GoV 002 NEWXP085587: M0dded by uNkn0wn Crew
:FBI.GoV 003 NEWEpicBot-AUT085587
:FBI.GoV 004 NEWXP085587: uNkn0wn – iD@ uNkn0wn
:FBI.GoV 005 NEWEpicBot-AUT085587
:FBI.GoV 005 NEWEpicBot-AUT085587
:FBI.GoV 005 NEWEpicBot-AUT085587
:FBI.GoV 422 NEWXP085587:MOTD File is missing
JOIN #Cheese#
:NEWXP085587!1854@192.35.222.192 JOIN:#Cheese#
PING:FBI.GoV
PONG:FBI.GoV

So, out of this we could observe that the IRC channel password is “\google_cache2.tmp”, our victim’s nickname is NEWXP085587, the channel we participate in #Cheese#. All of this from the Wireshark traffic analysis!

Now, being the adventurous person I am, I was interested in learning this botnet. So, I took it upon myself to connect with the IRC where you can loot for myself, hopefully talking the article author of the malware himself. So, I headed over a web IRC client in order that the botnet master would not be capable of seeing my very own IP address and perhaps launch a DDos attack against me. I logged in utilizing the password and other information found from the packet capture file. I logged in and waited. Every now and then, I’d go to a user issue commands using the kind of “UDP “. I assumed which he was directing his bots to DDos the victim with UDP packets. Eventually, I personally started typing, and caught the botmaster’s attention. The conversation went something like this:

Me: Hello? Anyone there?
Botmaster: lulz you arnt too smart
Botmaster: u shoulda used a vpn
Me: Don’t get worried, I’m utilizing an web IRC, so I’m good. Precisely what exactly is being conducted here?

Now, I had been booted from your chat. I believed my work was done, i really didn’t bother reconnecting. A few days later, I checked last, and the IRC channel along with the host itself transpired. I figure he thought he was caught, and merely shut everything down.

4. Malware Analysis: Conclusions

On the whole, my first wild malware analysis proved rather interesting. I had been capable of taking the unknown file and manage a few basic utilities to find out what exactly it absolutely was hiding. This afflicted me with a pretty good idea of what are the program was able to, and from this point I ran it in a confined system to view it for doing things. Further investigation brought me for an IRC botnet channel, where I actual chatted with the botmaster. Pretty good to get a try. Anyway, all the techniques I made use of on this example can be applied with malware samples. The main thing that it is cautious, and be patient. Quite often, simply watching network traffic won’t completely reveal what a worm or trojan does, and instead you can be being forced to reverse engineer the file. Reversing malware can be very time-consuming, specifically if the file was obfuscated utilizing an exe packer. Dolphins, good luck your personal endeavors, and i also hope this helped!