Analyzing Stuxnet Với Volatility

Download stuxnet vmem https://drive.google.com/open?id=0B23yo4Wg98gBUE1zSDhoVjVNOEU


Determine Volatility Image
  1. Determine Which Profile to Use
    • Instructions
      1. cd /pentest/forensics/volatility-2.2
      2. chmod 700 vol.py
        • Make vol.py executable.
      3. ./vol.py imageinfo -f images/stuxnet/stuxnet.vmem
    • Note(FYI):
      • For this image Volatility tells us to use the WinXPSP3x86 profile.

Section 1. Analyze Stuxnet Process Tree
  1. Basic Stuxnet Description
    • Note(FYI):
      1. A normal Windows XP installation has just one instance of lsass.exe that the Winlogon process creates when the system boots. (Wininit creates it on Windows Vista and higher).
      2. [The following] process tree [example] reveals that the two new lsass.exe instances were both created by services.exe [], the Service Control Manager, which implies that Stuxnet somehow got its’ code into the Services.exe process. [1][2].
      3. Mrxnet.sys is the driver that … implements the rootkit that hides files, and Mrxcls.sys is a second Stuxnet driver file that launches the malware when the system boots. [1]
  2. What is lsass.exe
    • Note(FYI):
      • LSASS, or local security authority subsystem service, is a process that functions as part of the Microsoft Windows operating system.
      • LSASS is part of the process for maintaining and enforcing the security protocols on the operating system.
      • LSASS performs several important functions
        1. To ensure that the system remains free from unauthorized access
        2. LSASS oversees access to a computer or server.
        3. LSASS recognizes any restrictions on access to any information on the hard drive or the server.
        4. LSASS makes sure that only recognized access codes or other login credentials will allow persons to interact with password protected files, directories, etc.
  3. Analyze Stuxnet Process Tree
    • Instructions
      1. ./vol.py pstree –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem | egrep ‘(services.exe|lsass.exe|winlogon.exe)’ | tee images/stuxnet/output/pstree.txt
      2. ls -l images/stuxnet/output/pstree.txt
    • Note(FYI):
      • The normal Parent-Child relation
        • winlogon.exe (624) kicks off, DATE: 2010-10-29 17:08:54
          • services.exe (668), DATE: 2010-10-29 17:08:54
          • lsass.exe (680), 2010-10-29 17:08:54
      • The Stuxnet Parent-Child relation
        • services.exe(668) is NOT supposed to, but kicks off
          • lsass.exe (1928), DATE: 2011-06-03 04:26:55
          • lsass.exe (868), DATE: 2011-06-03 04:26:55
        • Notice these two lsass.exe processes were created 216 after winlogin.exe was started.

Section 2 Analyze Sockets
  1. Analyze Sockets
    • Instructions
      1. ./vol.py sockets –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem | egrep ‘(Off|—|680|1928|868)’ | tee images/stuxnet/output/sockets.txt
      2. ls -l images/stuxnet/output/sockets.txt
    • Note(FYI):
      • Another way that you can tell the good lsass.exe (680) processes from the bad (1928 & 868) lsass.exe process is that PID 680 are bound to Port 500 and 4500, while PIDs 1928 & 868 are not.

Section 3. Analyze DLL’s
  1. Analyze lsass dll’s
    • Instructions
      1. ./vol.py dlllist -p 680 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem 2>/dev/null | wc -l
      2. ./vol.py dlllist -p 1928 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem 2>/dev/null | wc -l
      3. ./vol.py dlllist -p 868 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem 2>/dev/null | wc -l
      4. ./vol.py dlllist -p 680,1928,868 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem > images/stuxnet/output/dlllist.txt
      5. ls -l images/stuxnet/output/dlllist.txt
    • Note(FYI):
      • [A]nother suspicious characteristic of the two superfluous processes is the fact that they have very few DLLs loaded. [1][2].
      • DLLs are automatically added … when a process call the  LoadLibrary. [3]
      • 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.

Section 4. Analyze Process IDs with malfind
  1. Analyze Process IDs with malfind
    • Instructions
      1. ./vol.py malfind -p 680 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem
      2. ./vol.py malfind -p 868 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem
      3. ./vol.py malfind -p 868,1928 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem > images/stuxnet/output/malfind.txt
      4. ls -l images/stuxnet/output/malfind.txt
    • Note(FYI):
      • The malfind command has several purposes. You can use it to find hidden or injected code/DLLs in user mode memory, based on characteristics such as VAD tag and page permissions. [3]
      • Services.exe, Lsass.exe or Explorer.exe should not have write permission. 
      • Notice, that PID(680) did not return any results, while PID(868 & 1928) do.

Section 5. Bypassing Behavior Blocking Wheb Loading DLLs
  1. What is Address space layout randomization (ASLR)
    • Note(FYI):
      • 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
    • Note(FYI):
      • 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 Load – Library 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. [HEXA – DECIMAL], where the variable [HEXADECIMAL]is a hexadecimal values. [4]
  3. Hiding DLLs
    • Instructions
      1. ./vol.py dlllist –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem | grep ASLR
      2. ./vol.py dlllist –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem | grep ASLR > images/stuxnet/output/aslr.txt
      3. ls -l images/stuxnet/output/aslr.txt
    • Note(FYI):
      • Step 1 displays the Stuxnet specially crafted files designed to bypass the ASRL.

Section 6. Using ldrmodules to find hidden DLLs
  1. 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 Enviroment 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. [3]

     

  2. Using ldrmodules
    • Instructions
      1. ./vol.py ldrmodules -p 680 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem
        • This is normal.
      2. ./vol.py ldrmodules -p 868 –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem
        • Notice the lines identified by the word “Problem”.
      3. ./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 Enviroment Block) lists or because the path name is blank.

Section 7. Using procexedump to dump process executables
  1. Using procexedump to dump process executables
    • Note(FYI):
      • To dump a process’s executable (not including the slack space), use the procexedump command.
  2. Using procexedump
    • Instructions
      1. ./vol.py procexedump -p 680,868,1928 -D images/stuxnet/output/ –profile=WinXPSP3x86 -f images/stuxnet/stuxnet.vmem
      2. ls -l images/stuxnet/output/*.exe
  3. Looking at Malicious Hooks
    • Instructions
      1. strings images/stuxnet/output/executable.868.exe | more
    • Note(FYI):

Comments