Stuxnet
worm that was originally aimed at Iran's nuclear facilities, mutated and spread to other industrial and energy-producing facilities
Memory image
Download the memory image containing Stuxnet malware from here and unzip it.
Identifying the profile
First, we will start by identifying the profile of the memory image using
imageinfoplugin.
It shows various suggested profiles and we shall consider the first one.
Malicious processes
Now that we've found the profile of the memory image, we can start looking for suspicious activities in the memory.
Process scan
A good place to start is by looking at all the processes. So, we'll start with
psscan
Looking at the output, there doesn't seem to be any suspicious process.
However, I could spot that there are 3 "lsass.exe" processes in the memory. In an ideal scenario, there should be only 1 "lsass.exe" with "winlogon.exe" as the parent on WinXP systems.
"lsass.exe" is responsible for security-related functions, including handling user authentication.
Parent-child relationship
We can use
pstreeplugin to view the parent-child relationship between the processes.
I've grepped the output for better visibility. As we can see, 2 "lsass.exe" processes with PID 1928 and 868 have the parent of "services.exe" which is not normal. On WinXP systems, the parent process should be “winlogon.exe”.
It is also worth looking at "svchost.exe". In an ideal system, it should have a parent of "services.exe". Here it seems legit.
Process path
Now that we have 2 suspicious processes (1928, 868) to look out for, we'll check their path.
We can see from the output that these processes are running from a legit path.
Injected code
Next, we'll use the
malfindplugin to identify hidden and injected code in those processes.
As we see, these 2 processes have memory regions with the protection of
PAGE_EXECUTE_READWRITE. Typically, memory sections shouldn't be executable and writable simultaneously.The process name and path of those 2 suspicious processes are legit but we have multiple instances of those running with their memory regions with wrong protection.
This might be because the process is hollowed out, meaning the process would have been duplicated in a suspended state and the executable portion of the processes is replaced with malicious code. Now when that process resumes, the name and the path are maintained. This is called Hollow Process Injection.
We can use a plugin called
hollowfindfor those 2 PIDs to identify this.
From the output, along with other details, we can also see that the path of the process is empty in VAD but is present in PEB. This discrepancy is caused because of Hollow Process Injection.
The output also shows us similar processes and suspicious memory regions to look out for.
We can also verify the other "lsass.exe" (PID of 680 - which had the valid parent process) if it has injected code or not.
From the output, we can see that it is clean.
Now we can confirm from our analysis that the processes 1928 and 868 are hollowed out and in fact malicious.
Dump malicious processes
Finally, we can now proceed to dump those processes using
procdumpand verify our conclusions that those processes are malicious.Create a folder to dump those processes.
Investigate process hash
Let's find the hashes of those dumped files and investigate in VirusTotal.
By investigating those hashes with VirusTotal, we can confirm that those processes are indeed malicious.
Now that we have found the malicious processes, it is important to extract as many Indicators of Compromise (IOCs) as possible, so that it is easier to detect on other systems in the network.
C2 connections
Another common way to investigate is to look for suspicious network connections that the malicious processes might establish to their Command & Control servers.
We can see that there are no open connections from this memory. Let's move on.
Suspicious Registry entries
One important thing that malware does is persist system reboots. So let's check in the registry if there are any persistence mechanisms added by the malware.
List of hives
We can start by listing out the registry hives loaded in the memory using
hivelistplugin.
Dump registries
Now let us dump all these registries using
dumpregistryplugin for further analysis.Make sure to create an output directory for that.
Investigate registries
To find the entry of the malicious "lsass.exe" processes in the registry, we'll run
stringsagainst all those registry dumps.We'll use "strings" along with the following flags:
-f: to print the name of the file before each identified string-a: to scan the entire file and not just the data section-el: to specify the encoding to be 16-bit little-endian (encoding of Windows registries)
So the "lsass.exe" is mentioned in the "system" hive.
This hive can be used by malware to achieve system-level persistence, like adding drivers.
Unknown Drivers
Now that we know that the malicious process might have added drivers to achieve persistence, let's look at the drivers.
Malicious drivers
Since we don't know the driver names, we can look for callbacks that are used by processes in user space to communicate with kernel space. There is a plugin called
callbacksto identify them.
After manually reading about each module, we can zero down on "mrxcls.sys" and "mrxnet.sys" as being undesirable.
To investigate further, we need to dump the modules. To dump the modules, we need the base address of those modules. For this, we can use
modulesplugin and grep for those modules.
Dump drivers
Now that we know the base address of those drivers, we can proceed to dump them using
moddumpplugin and specify the base address.As always, create a dump directory.
Investigate driver hash
Also running
fileagainst those dumped modules shows us they are PE32 executable (native) which confirms they are driver files.
Now, let's find out the hashes of these possibly malicious drivers and investigate in VirusTotal.
This confirms that these drivers are malicious. Let's not stop here.
Search for driver entries
Now that we have the malicious driver names, we can also look if they have entries in the registries by running
stringson the registry dump as before and grep for those driver names.
We again see there are entries in the "system" hive which show the location of the drivers.
Now we will use
reglookupon the "system" hive and grep for those malicious drivers to find out where the location of the drivers is mentioned.
From the output, we can see various things:
The presence of the
MRxClsandMRxNetsubkey underServicesindicates that the malware is trying to register services with those names.ImagePathvalue name is set to the path of the drivers, linking the services "MRxCls" and "MRxNet" with the drivers "mrxcls.sys" and "mrxnet.sys" respectively.
Now, we would also like to see what other values are there within the malicious service names. We can see this by using the
printkeyplugin and giving the keys we found in thereglookupoutput.
While I missed adding the output of the
printkeycommand, it shows that theStartvalue of both services is set to 1.Upon research, we can see that the
Startvalue of 1 correspondsSERVICE_SYSTEM_STARTwhich means the service is started automatically during system boot. This is the persistence mechanism the malicious drivers are using.Also, don't forget to learn about the other details from the output, like Group, Type etc.
Now that we extracted most of the information from the memory (to the best of our knowledge), let's list them down!
Indicators Of Compromise
The presence of Stuxnet can be identified with the help of the below IOCs.
Processes
Process name: lsass.exe (multiple running instances in memory)
Drivers/Files
Driver name: mrxnet.sys
Driver path: C:\WINDOWS\system32\Drivers\mrxnet.sys
Driver name: mrxcls.sys
Driver path: C:\WINDOWS\system32\Drivers\mrxcls.sys
Registry entries
Registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\MRxNet
Value: ImagePath Data: C:\WINDOWS\system32\Drivers\mrxnet.sys
Value: Start Data: 1
Registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\MRxCls
Value: ImagePath Data: ??\C:\WINDOWS\system32\Drivers\mrxcls.sys
Value: Start Data: 1
Last updated
