Stuxnet Trojan - Memory Forensics with Volatility | Part II

You can read the first part of this post here:

http://www.behindthefirewalls.com/2013/12/stuxnet-trojan-memory-forensics-with_16.html

DETECTING API CALLS

If we use the command below, we can see the strings of these exported files in order to try to locate some interesting words...

strings evidences/process.*

Thank to Volatility we can find the apihooks of this memory dump. In the picture below, you will see the apihooks related with the malicious process 1928.

python2 vol.py -f stuxnet.vmem malfind apihooks –p 1928

These calls are directly linked to the Stuxnet worm. You can read the article below from Symantec.

http://www.symantec.com/connect/blogs/w32stuxnet-installation-details

DETECTING MALICIOUS DRIVERS

With modscan we can pick up previously unloaded drivers and drivers that have been hidden/unlinked by rootkits.

python2 vol.py -f stuxnet.vmem modscan

The first driver draws our attention… Please, take notes of the “Base” value (0xb21d08000) because we will export it with the command bellow.

python2 vol.py -f stuxnet.vmem moddump --dump-dir evidences/ --base 0xb21d8000

We get the sha256 hash of this driver...

sha256sum evidences/driver.b21d8000.sys

...and we upload it to www.virustotal.com

Here you have the report where you will see that this drivers has been  recognized as malicious.

https://www.virustotal.com/en/file/6aa1f54fbd8c79a3109bfc3e7274f212e5bf9c92f740d5a194167ea940c3d06c/analysis/

We have just detected a malicious driver but I think that it’s necessary to look for more  drivers with a similar name in order to try to find a new ones...

python2 vol.py -f stuxnet.vmem modscan | grep mrx

Ok. Let’s go to export the second suspicious driver. We will follow the same steps as described above.

python2 vol.py -f stuxnet.vmem moddump --dump-dir evidences/ --base 0xf895a000

https://www.virustotal.com/en/file/6bc86d3bd3ec0333087141215559aec5b11b050cc49e42fc28c2ff6c9c119dbd/analysis/

We have just found two malicious drivers: mrxcls.sys and mrxnet.sys.

I checked with the same commands the other two drivers and they aren’t categorized as malicious files. This is the reason I haven't show you.

DETECTING REGISTER KEYS

In this section, we will detect the register keys that have been added to the computer. With the command below, we will see a lot of them.

strings stuxnet.vmem | grep –i mrx | grep -i Services

We can obtain valuable information about some of them with the next commands.

python2 vol.py -f stuxnet.vmem printkey -K 'ControlSet001\Services\MrxNet'

python2 vol.py stuxnet .vmem printkey -K 'ControlSet001\Services\MrxCls'

With these key registers, Stuxnet will be started in each computer restart.

Read More

Stuxnet Trojan - Memory Forensics with Volatility | Part I

Stuxnet could be the first advanced malware. It is thought that it was developed by the United States and Israel to attack Iran's nuclear facilities. It attacked Windows systems using a zero-day exploit and It was focused on SCADA systems in order to  affect critical infrastructures... Also, it may be spread from USB drivers. It is necessary a squad of highly capable programmers with depth of knowledge of industrial processes and an interest in attacking industrial infrastructure to develop this malware.

Kaspersky Lab concluded that the sophisticated attack could only have been conducted "with nation-state support" and a study of the spread of Stuxnet by Symantec says that it was spread to Iran (58.85%), Indonesia (18.22%), India (8.31%), Azerbaijan (2.57%)....

Thanks to Malware Cookbook we can download a memory dump from an infected host with this malware in the URL below: 

http://malwarecookbook.googlecode.com/svn/trunk/stuxnet.vmem.zip

Ok, let’s go. We are going to analyze it with Volatility.

STUXNET IMAGE INFO

First of all we want to get more info of the memory image. With the command below we can see the volatility suggested profile and when the image was dumped. In this case it was in 2011-06-03.

python2 vol.py -f stuxnet.vmem imageinfo

It is a good practice to export the profile WinXPSP3x86 in order not to specify more this profile in the Volatility commands.

export VOLATILITY_PROFILE=WinXPSP3x86

DETECTING MALICIOUS PROCESS

First of all, I usually want to know what process was running the computer when the memory was dumped.

Notice you will see that three lsass.exe processes were running… It draws our attention.

• lsass.exe Pid 680
• lsass.exe Pid 868
• lsass.exe Pid 1928

python2 vol.py -f stuxnet.vmem pslist

We know that lsass.exe is one of the first processes to start when Windows boots. Because of this, it’s normal that “lsass.exe” has a lower Pid. You can see when the three lsass.exe process started in the picture above:

• Pid 680 started at 2010-10-29 17:08:54
• Pid 868 started at 2011-06-03 04:26:55
• Pid 1928 started at 2011-06-03 04:26:55

You can see the “lsass.exe” with lower Pid (680) started in 2010 and the other ones with higher Pid (868 and 1928) started in 2011. It isn’t a normal behavior.

In the picture below we can notice that Winlogon.exe (Pid 624) started one of the “lsass.exe” process (Pid 680). This is a really good indication of which “lsass.exe” isn’t malicious, because Winlogon.exe always starts the real “lsass.exe”. The “lsass.exe” with Pid 868 and 1928 was started by the “services.exe” process. It isn’t a normal behavior. They could be malicious processes.

python2 vol.py -f stuxnet.vmem pstree | egrep '(services.exe|lsass.exe|winlogon.exe)'

We have just discovered two suspicious processes.

DETECTING MALICIOUS CONNECTIONS

It is really important to indentify if theses suspicious processes were making connections.  With the command below we can check it.

python2 vol.py -f stuxnet.vmem connections

No connections were establishing when the memory was dumped. Now, we are going to see the ports that were listening in the computer.

In the picture bellow you will see a “lsass.exe” with Pid 680 is bound to Port 500 and 4500, while “lsass.exe” with Pid 868 and the another one with Pid 1928 are not listening in these ports. It seems again that the “lsass.exe” with the PID 680 has a normal behavior because this process usually listens on these ports.

python2 vol.py -f stuxnet.vmem sockets

DETECTING DLL

The “lsass.exe” process with PID 680 appears to be a normal process… What’s happened with the other ones?

With the command below, we can check that “lsass.exe” with Pid 868 and Pid 1928 have a load lower DLLs.

python2 vol.py -f stuxnet.vmem dlllist –p 680 | wc –l

python2 vol.py -f stuxnet.vmem dlllist –p 868 | wc –l

python2 vol.py -f stuxnet.vmem dlllist –p 1928 | wc –l

Also, we can detect that the process with Pid 1928 has unlinked DLLs.

python2 vol.py -f stuxnet.vmem ldrmoudles –p 1928

We can get more information about it with this command.

python2 vol.py -f stuxnet.vmem ldrmoudles –p 1928 -v

These kernel calls are directly related with stuxnet worm. See the URL below:

http://www.f-secure.com/v-descs/trojan-dropper_w32_stuxnet.shtml

DETECTING INJECTED CODE

The malfind command helps us to find hidden or injected code/DLLs in the user mode memory. Then we are going to export these DLLs and we will upload them to www.virustotal.com in order to check if an anti-virus detects them.

We already know that the process with PID 680 is normal. For this reason we will continue with the other ones.

python2 vol.py -f stuxnet.vmem malfind –p 868 –dump-dir evidences/

We can see two files have been created. We continue doing the same with the “lsass.exe” process with Pid 1928.

python2 vol.py -f stuxnet.vmem malfind –p 1928 –dump-dir evidences/

The next step will be to upload to www.virustotal.com these files in order to check if some anti-virus vendor detects them as malicious files. In order to not upload the files, we will obtain the sha256 checksum of the files and then we will search on the Virustotal website.

sha256sum *.dmp

Here, you have the links to Virustotal with the report of the files which have been analyzed:

https://www.virustotal.com/en/file/e97d61f7393ac5838a1800f3e9aa22c6205f4d7e2bde494573d35c57bc9b7819/analysis/

https://www.virustotal.com/en/file/163b7da37df4ae6dafbfb5bf88b319dabf7846cee73d4192c6a7593e835857a8/analysis/

https://www.virustotal.com/en/file/abce3e79e26b5116fe7f3d40d21eaa4c8563e433b6086f9ec07c2925593f69dc/analysis/

https://www.virustotal.com/en/file/2b2945f7cc7cf5b30ccdf37e2adbb236594208e409133bcd56f57f7c009ffe6d/analysis/

https://www.virustotal.com/en/file/10f07b9fbbc6a8c6dc4abf7a3d31a01e478accd115b33ec94fe885cb296a3586/analysis/

https://www.virustotal.com/en/file/a4b4b29f0df45283b629203b080c09ddb5bc6eb4cd8e9b725f75121a8b7e728e/analysis/

https://www.virustotal.com/en/file/2b2945f7cc7cf5b30ccdf37e2adbb236594208e409133bcd56f57f7c009ffe6d/analysis/

Notice that the majority of them have been detected as Stuxnet Worm

Stuxnet Trojan - Memory Forensics with Volatility |  Part II

Continue reading the second part here:
http://www.behindthefirewalls.com/2014/01/stuxnet-memory-forensics-volatility-II.html

Read More

Zeus Trojan - Memory Forensics with Volatility

In this post I'm going to talk about Volatility. Volatility is one of  the best tools for memory forensics. It is an open source framework writen in python for incident response and malware analysis.

Thanks to Malware Analyst's Cookbook we can get a real memory dump from an infected host with Zeus Trojan. You can donwload zeus.vmem.zip [41,4 MB]

1) With the option "imageinfo" you can find out what type of OS was running.

python vol.py -f zeus.vmem imageinfo

2) Now, we are going to watch what processes were running on the computer when the memory dump was recorder.

python vol.py -f zeus.vmem pstree

3) I couldn't see anything weird... I wanted to know if the machine was making connections...

python vol.py -f zeus.vmem connscan

4) Ok. Our machine was making connections with 193.104.47.75 by the 80/tcp port. The proccess Pid is 856. We want to know whether this process belong to an Internet Browser.

We run it again:

python vol.py -f zeus.vmem pstree

5) We can see that svchost.exe is the process which is making connections with193.104.47.75 instead of an Internet Browser... This is not common... Is this IP address blacklisted?

http://www.ipvoid.com/scan/193.104.41.75/

6) As you can see, this IP is blacklisted. It is common that a trojan adds a registry key to be sure that it will be running every time the computer is restarted. Take a look at the Winlongon register key...

python vol.py -f zeus.vmem printkey -K "Microsoft\Windows NT\CurrentVersion\Winlogon"

You can see sdra64.exe will run when the computer starts. If you search on Google you can see a lot of websites talking about this process... It seems to be a trojan....

7) Now, we are going to try find a hidden or injected code/DLLs in the user mode memory and dump it...

python vol.py -f zeus.vmem malfind --dump-dir evidencias/

8) We are really interested in dumping the process with the Pid 856 which has established connections with the blacklisted servers.

9) Now, I'm going to get the SHA256 hash in order to search in Virustotal and see if this process is recognized by any Antivirus.

https://www.virustotal.com/en/file/8e3be5dc65aa35d68fd2aba1d3d9bf0f40d5118fe22eb2e6c97c8463bd1f1ba1/analysis/

 

Ok, so far so good.


10) We are going to use the mutantscan command. With this option, we can display all objects.

python vol.py -f zeus.vmem mutantscan

We noticed _AVIRA_2108... I don't know where I've heard this before...

python vol.py -f zeus.vmem mutantscan | grep AVIRA

I was looking for this object on Google. I visited www.fortiguard.com and found this.

11) This trojan usually shuts down our Firewall.. We can check it with the next command.

python vol.py -f zeus.vmem printkey -K "ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile"

This is evidence that the computer was infected with Zeus Trojan. In the next post, we are going to analyze another memory dump with Volatility.

Interesting links:

• Volatility - CommandReference 
• Volatility Documentation Project
• Volatility - FeaturesByPlugin  

Read More