Source: https://www.computersecuritystudent.com/FORENSICS/VOLATILITY/VOLATILITY2_2/lesson2/
Basic Stuxnet Description (sophisticated APT worm-like trojan):
Analyze Stuxnet Process Tree3. vol.py pstree –profile=WinXPSP3x86 -f stuxnet.vmem | egrep ‘(services.exe|lsass.exe|winlogon.exe)’ | tee pstree.txt
Note 3: Lsass
Analyze Sockets
4. vol.py sockets –profile=WinXPSP3x86 -fstuxnet.vmem | egrep ‘(Off|—|680|1928|868)’ | tee images/sockets.txt
Note 4: Lsass DLLsAnother suspicious characteristic of the two superfluous processes is the fact that they have very few DLLs loaded.
DLLs are automatically added … when a process call the LoadLibrary.
Notice that the good PID (680) has 64 DLLs attached to its’ process.
Notice that the bad PID (1928) has 35 DLLs attached to its’ process.
Notice that the bad PID (868) has 15 DLLs attached to its’ process.
Analyze Process IDs with malfind
vol.py malfind -p 680 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem
vol.py malfind -p 868 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem
vol.py malfind -p 868,1928 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem > images/stuxnet/output/malfind.txt
Bypassing Behavior Blocking When Loading DLLs
1. What is Address space layout randomization (ASLR)
Address space layout randomization (ASLR) is a computer security method which involves randomly arranging the positions of key data areas, usually including the base of the executable and position of libraries, heap, and stack, in a process’s address space.
2. Bypassing Behavior Blocking When Loading DLLs
Whenever Stuxnet needs to load a DLL, including itself, it uses a special method designed to bypass behavior-blocking and host intrusion-protection based technologies that monitor LoadLibrary calls. Stuxnet calls LoadLibrary with a specially crafted file name that does not exist on disk and normally causes LoadLibrary to fail. However, W32.Stuxnet has hooked Ntdll.dll to monitor for requests to load specially crafted file names. These specially crafted filenames are mapped to another location instead a location specified by W32.Stuxnet. That location is generally an area in memory where a .dll file has been decrypted and stored by the threat previously. The filenames used have the pattern of KERNEL32.DLL.ASLR.[HEXADECIMAL] or SHELL32.DLL.ASLR. [HEXADECIMAL], where the variable [HEXADECIMAL] is a hexadecimal value.
vol.py dlllist –profile=WinXPSP3x86 -f stuxnet.vmem | grep ASLR
vol.py dlllist –profile=WinXPSP3x86 -f stuxnet.vmem | grep ASLR > aslr.txt
ls -l images/stuxnet/output/aslr.txt
Using ldrmodules to find hidden DLLs
Note (FYI):
There are many ways to hide a DLL. One of the ways involves unlinking the DLL from one (or all) of the linked lists in the PEB (Process Environment Block). However, when this is done, there is still information contained within the VAD (Virtual Address Descriptor) which identifies the base address of the DLL and its full path on disk. To cross-reference this information (known as memory mapped files) with the 3 PEB lists, use the ldrmodules command. For each memory mapped Portable Executable (PE) file, the ldrmodules command prints a 0 or a 1 if the PE exists in the PEB lists.
a. vol.py ldrmodules -p 680 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem
This is normal
b. vol.py ldrmodules -p 868 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem
Notice the lines identified by the word “Problem.”
c. vol.py ldrmodules -p 1928 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem | egrep ‘(Pid|-$)’Note (FYI):
The lines identified as a problem are either suspicious because an entry is missing from one of the PEB (Process Environment Block) lists or because the path name is blank.