SANS Institute Information Security Reading Room
Creating a Baseline of Process Activity for Memory Forensics ______________________________ Gordon Fraser
Copyright SANS Institute 2020. Author Retains Full Rights. This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission.
http://www.sans.org/info/36909
http://www.sans.org/info/36914
!! [VERSION!June!2014]!
! ! !
Creating a Baseline of Process Activity for
Memory Forensics
GIAC (GCFA) Gold Certification
Author:!Gordon!Fraser,[email protected]! Advisor:!Richard!Carbone!
Accepted:!August!19th!2014!! !
Abstract! ! A!component!of!memory!forensics!is!the!examination!of!running!processes!looking! for!anomalies.!!However,!this!assumes!that!the!analyst!can!recognize!the!anomalies.!! A!frame!of!reference!to!assist!the!analyst!is!the!creation!of!a!baseline!which! identifies!what!is!expected!to!be!present!in!memory!for!a!given!configuration.!!The! analyst!can!use!the!baseline!as!a!reference!to!quickly!filter!out!expected!processes! and!to!focus!on!what!is!not!expected!to!be!there.!!This!paper!covers!the!creation!of!a! baseline!for!Windows!Server!2008!R2!with!several!different!configurations.!!! ! !
Creating a Baseline of Process Activity for Memory Forensics! 2 !
Gordon!Fraser,[email protected]! ! !
1. Introduction
SANSs Advanced Forensic Analysis and Incident Response course (Lee &
Tilbury, 2013) defines a process for the examination of memory to identify indicators of
compromise. It is comprised of the following six steps: identify rogue processes,
analyze process objects, review network artifacts, look for evidence of code injection,
check for signs of rootkits, and dump suspicious processes and drivers.
While identifying rogue processes the analyst is looking at what is running, parent
processes, and when they started. Should a process be there? What is the parent process
and is it what is expected? Did the process start when it was supposed to?
When analyzing process objects, the analyst examines the name of the executable,
the executables path, the command line parameters used for starting the process, and the
security identifiers associated with it. Did the executable start from the directory from
which it was expected? Are the command line parameters what we expected to see? Is
the context in which the process is running what is expected? That is, was it run as
System or was it run as a user? The analyst can also look at dynamic link libraries
(DLLs) and kernel modules, which have been loaded into memory.
Next, the analyst examines the network connections that have been established
and which process they are associated with. Are there any unusual network connections?
Are the network connections associated with the process expected to have initiated them?
The common thread for each of the first three steps is looking for anything
unusual. However, how does one know if something is unusual? Or, to turn the question
around, how does one know what is expected? Searches through the literature and the
web can provide some guidance, but it only provides a starting point. One solution is to
establish a baseline of what is expected and use it as a reference of what to expect. Such
a baseline could be used to filter out expected processes allowing the analyst to focus on
the unexpected.
This paper starts out by creating a baseline from the literature, such as Windows
Internals, 6th Edition Part 1 (Russinovich, Solomon & Ionescu, 2012a) and Part 2
(Russinovich, Solomon & Ionescu, 2012b), Know your Windows Processes or Die
Creating a Baseline of Process Activity for Memory Forensics! 3 !
Gordon!Fraser,[email protected]! ! !
Trying (Olsen, 2014), and The Art of Memory Forensics (Ligh, Case, Levy, and
Walters, 2014). It then tests the baseline against a series of Windows 2008 R2 servers in
order to validate and refine the baseline.
2. Creating and Validating a Windows Server 2008 R2 Baseline
2.1. Data Collection Approach 2.1.1. Memory Acquisition
The starting point for memory analysis is the acquisition of a memory image.
There are a number of tools that can be used to acquire memory; win64dd.exe from
MoonSols was used for this analysis. Best practice is to capture the memory image to an
external device in order to minimize the impact the capture process has on the system
being analyzed. Writing the image to a disk on the system, which is the subject of the
investigation, could result in important data be overwritten and lost. Given the amount of
memory being captured, this could amount to gigabytes of data. For this analysis, since
we are only interested in the memory image and not the disk contents, memory was
collected by running win64dd.exe from the C:tmp directory on the hard drive of the
server.
2.1.2. Memory Analysis
There are a number of tools that can be used to analyze the memory image. For
the purpose of this analysis, Volatility was chosen. It is an open source memory analysis
framework written in Python (Volatility Wiki, 2013).
Volatility requires the memory image format be defined when executing
Volatility commands, except when analyzing a Windows XP Service Pack 2 memory
image (Volatility Wiki, 2013). The format used in the analysis, Win2008R2SP1x64,
was determined by running the command: vol.py -f mem.img imageinfo, where
mem.img was the name of the image file being analyzed. An alternative to including the
image format in every Volatility commands is to set the VOLATILITY_PROFILE
environment variable using the command:
Creating a Baseline of Process Activity for Memory Forensics! 4 !
Gordon!Fraser,[email protected]! ! !
export VOLATILITY_PROFILE=Win2008R2SP1x64.
2.1.3. Server Installation
Windows Server 2008 R2 was installed in VMware Workstation 9.0 with
VMware Tools installed. All variations of Windows were installed from the same
installation ISO disk image. The Windows Server 2008 R2 version, obtained using the
command: systeminfo | find OS, was 6.1.760 Service Pack 1 Build 7601. Updates
to the operating system were not applied.
2.2. Establishing an Initial Baseline As a starting point for constructing a baseline of processes in memory one needs a
basic understanding of the core processes loaded by the operating system upon boot and
the processes that are loaded when a user logs on. This has been documented in detail in
Windows Internals, 6th Edition Part 1 (Russinovich, Solomon & Ionescu, 2012a) and
Part 2 (Russinovich, Solomon & Ionescu, 2012b). A summary of the critical Windows
processes can be found in the article Know your Windows Processes or Die Trying
(Olsen, 2014), in The Art of Memory Forensics (Ligh, Case, Levy, and Walters, 2014),
as well as on the SANS DFIR Digital Forensics and Incident Response Poster (Pilkington
& Lee, 2014).
The first process that appears in the process list from memory is System. System
is a container for kernel processes (Ligh, Case, Levy, and Walters, 2014). It has a static
process ID of 4 and no parent process. System starts the session manager (smss.exe)
(Olsen, 2014).
Smss.exe is the first user-mode process of the boot sequence. It is responsible for
creating sessions. Two sessions are created on boot. Session 0 contains processes owned
by the system and Windows services. Session 1 contains processes owned by the user.
(Ligh, Case, Levy, and Walters, 2014) Smss.exe starts a copy of the client/server runtime
subsystem (csrss.exe) for each session. It starts the Windows Initialization Process
(wininit.exe) to initialize session 0 and the Windows Logon Process (winlogon.exe) to
initialize user sessions. Each user logon has a unique session ID that is created when
they log on. When creating a new session, smss.exe creates a child instance of itself
Creating a Baseline of Process Activity for Memory Forensics! 5 !
Gordon!Fraser,[email protected]! ! !
which initializes the session and then exits. For this reason, the parent process ID (PPID)
of csrss.exe, wininit.exe, and winlogon.exe do not map back to the process ID (PID) of a
process in memory (Pilkington & Lee, 2014).
Wininit.exe performs the user-mode initialization processes that run in session 0.
These include Local Security Authority (lsass.exe), Load Session Manager Service
(lsm.exe), and Service Control Manager (services.exe). Lsass.exe is responsible for the
local security policy. Lsm.exe manages terminal server sessions, calling smss.exe when a
new session needs to be started (Olsen, 2014).
Windows, like most operating systems, has processes that are not associated
with a specific interactive user. Instead, they run independent of user logons. These are
services and are started by services.exe. Windows does not run each service as its own
process. Instead, it groups services together with common characteristics into service
groups. These service groups are started using a generic process called svchost.exe. This
is why multiple svchost.exe can be seen running in memory. Svchost.exe is launched
with a -k parameter specifying which service group to start. We will populate the initial
baseline with the major service groups defined in Windows Internals Part 1 (Russinovich,
Solomon & Ionescu, 2012a) listed in Table 1.
Service Group Owner Local Service Local Service LocalServiceAndNoImpersonation Local Service LocalServiceNetworkRestricted Local Service LocalServiceNoNetwork Local Service LocalSystemNetworkRestricted Local System NetworkService Network Service NetworkServiceAndNoImpersonation Network Service NetworkServiceNetworkRestricted Network Service Table 1: Major Service Groupings
An initial baseline for process memory analysis can be built using this description
of the Windows boot process. Table 2 summarizes the processes one would expect to
find in a memory dump for session 0.
Creating a Baseline of Process Activity for Memory Forensics! 6 !
Gordon!Fraser,[email protected]! ! !
Name Parent Process
Session Event Owner Path
System – 0 Boot Local System %SystemRoot%System32 smss.exe System 0 Boot Local System %SystemRoot%System32 csrss.exe smss.exe 0 Boot Local System %SystemRoot%System32 wininit.exe smss.exe 0 Boot Local System %SystemRoot%System32 services.exe wininit.exe 0 Boot Local System %SystemRoot%System32 lsass.exe wininit.exe 0 Boot Local System %SystemRoot%System32 lsm.exe wininit.exe 0 Boot Local System %SystemRoot%System32 svchost.exe services.exe 0 Boot %SystemRoot%System32 Table 2: Initial Process Baseline
Winlogon.exe is responsible for interactive logon processes. It launches the
LogonUI.exe process which manages the user logon interaction, changing of passwords,
and locking and unlocking the workstation (Russinovich, Solomon & Ionescu, 2012a).
Once the user successfully authenticates, the shell process, as defined in the registry
value HKLMSOFTWAREMicrosoftWindows NTCurrent VersionWinlogonshell, is
started. The default shell process is Explorer.exe. This is started by the process Userinit,
which ends once explorer.exe is started. Therefore, we should not find its parent process
running. If the users logon is via remote desktop, rather than the console, the process
rdpclip.exe will also be found in memory associated with the users session (Ligh, Case,
Levy, and Walters, 2014).
There are three states that a user session can be in: user not logged in, user logged
in from console, and user logged in remotely. Table 3 lists the processes that are
expected to be seen for each of these states. It constitutes the initial baseline for user
logon processes. The parent process is not listed because its parent exits and so the PPID
does not track back to a process in memory. Session n refers to any user session since a
user session could be session 1, session 2, etc.
Name Parent Process
Session Owner Path
User not logged in csrss.exe n Local System %SystemRoot%System32 winlogon.exe n Local System %SystemRoot%System32 LogonUI.exe winlogon.exe n Local System %SystemRoot%System32
User logged in on console csrss.exe n Local System %SystemRoot%System32 winlogon.exe n Local System %SystemRoot%System32 explorer.exe n User %SystemRoot%
User logged in remotely
Creating a Baseline of Process Activity for Memory Forensics! 7 !
Gordon!Fraser,[email protected]! ! !
Name Parent Process
Session Owner Path
csrss.exe n Local System %SystemRoot%System32 winlogon.exe n Local System %SystemRoot%System32 rdpclip.exe services.exe n User %SystemRoot%System32 explorer.exe n User %SystemRoot% Table 3: Initial Process Baseline for logon
In addition to processes, there are three other artifacts of interest when creating a
baseline for memory forensics — dynamic link libraries, modules, and drivers. Dynamic
link libraries (DLLs) contain code and resources that are shared between multiple
processes. Modules are code that is loaded into the Operating System kernel. Finally,
drivers are the code that allows the computer to communicate with hardware devices
(Ligh, Case, Levy, and Walters, 2014). Since each of these artifacts consists of a large
number of objects, the baseline will be created from the analysis of live systems rather
than from literature searches.
Another set of attributes of interest to the forensic analyst is the network
connections that have been opened up by processes. These can be viewed using the
netscan plugin. The network connections portion of the baseline will be built by
gathering data from live systems and then analyzing it.
2.3. Testing Baseline against Generic Windows Server 2008 R2 Now that we have an initial memory baseline, we can compare it against a
memory image collected from a live system in order to validate and improve it. The first
Windows 2008 R2 server was built using a generic standard edition installation with the
server being part of a workgroup. Since this is a fresh installation from Windows media,
it is assumed that it is clean.
2.3.1. Identify Rogue Processes
Following the memory analysis methodology, we will start with Step 1: looking
for rogue processes. Since there should be no rogue process, we are really looking for
processes that are not part of our initial baseline.
The output below provides a process listing using Volatilitys pslist plugin. In
order to fit it on the page the cut command was used to remove some irrelevant output.
Creating a Baseline of Process Activity for Memory Forensics! 8 !
Gordon!Fraser,[email protected]! ! !
To separate the boot process from the logon processes, there was a gap in time between
them. This is evident from the start time column, seen below.
$ vol.py -f win2008r2-01-a.img pslist | cut -c 20-76,84-104 Volatility Foundation Volatility Framework 2.3.1 Name PID PPID Thds Hnds Sess Start ——————– —— —— —— ——– —— ——————– System 4 0 76 460 —— 2014-06-22 13:26:36 smss.exe 232 4 2 29 —— 2014-06-22 13:26:36 csrss.exe 324 316 9 335 0 2014-06-22 13:26:42 csrss.exe 376 368 10 189 1 2014-06-22 13:26:43 wininit.exe 384 316 3 79 0 2014-06-22 13:26:43 winlogon.exe 420 368 3 96 1 2014-06-22 13:26:43 services.exe 480 384 8 189 0 2014-06-22 13:26:44 lsass.exe 488 384 6 530 0 2014-06-22 13:26:45 lsm.exe 496 384 10 145 0 2014-06-22 13:26:45 svchost.exe 588 480 11 345 0 2014-06-22 13:26:48 svchost.exe 656 480 6 233 0 2014-06-22 13:26:49 svchost.exe 744 480 13 288 0 2014-06-22 13:26:49 svchost.exe 788 480 26 824 0 2014-06-22 13:26:49 svchost.exe 836 480 10 508 0 2014-06-22 13:26:50 svchost.exe 884 480 7 198 0 2014-06-22 13:26:51 svchost.exe 928 480 16 429 0 2014-06-22 13:26:51 svchost.exe 216 480 17 289 0 2014-06-22 13:26:53 spoolsv.exe 904 480 13 313 0 2014-06-22 13:26:54 svchost.exe 1040 480 3 46 0 2014-06-22 13:26:56 vmtoolsd.exe 1096 480 9 253 0 2014-06-22 13:26:56 TPAutoConnSvc. 1292 480 10 140 0 2014-06-22 13:26:59 dllhost.exe 1456 480 13 194 0 2014-06-22 13:27:01 msdtc.exe 1612 480 12 147 0 2014-06-22 13:27:03 svchost.exe 1752 480 5 67 0 2014-06-22 13:29:01 taskhost.exe 1276 480 5 118 1 2014-06-22 13:34:03 TPAutoConnect. 1328 1292 5 126 1 2014-06-22 13:34:03 conhost.exe 1556 376 1 30 1 2014-06-22 13:34:03 dwm.exe 1116 884 3 65 1 2014-06-22 13:34:03 explorer.exe 848 968 15 478 1 2014-06-22 13:34:03 vmtoolsd.exe 2012 848 7 184 1 2014-06-22 13:34:06 cmd.exe 332 848 1 20 1 2014-06-22 13:39:31 conhost.exe 1228 376 2 36 1 2014-06-22 13:39:31 win64dd.exe 868 332 2 49 1 2014-06-22 13:52:33
The bolded lines above identify those processes that are not already present in the
baseline. These ones need to be examined more closely.
The servers are running on VMware Workstation, so there may be processes
associated with VMware that are not part of the normal generic Windows installation.
Indeed, we find three processes — TPAutoConnSvc.exe, TPAutoConnect.exe, and
vmtoolsd.exe. A clue to this association to VMware is given when examining the process
information in more detail. Each of these processes is being run out of the directory
C:Program FilesVMwareVMware Tools as shown in the output below from the dlllist
plugin.
Creating a Baseline of Process Activity for Memory Forensics! 9 !
Gordon!Fraser,[email protected]! ! !
$ vol.py -f win2008r2-01-a.img dlllist -p 1096 | grep -B 1 -i “command line” Volatility Foundation Volatility Framework 2.3.1 vmtoolsd.exe pid: 1096 Command line : “C:Program FilesVMwareVMware Toolsvmtoolsd.exe” $ vol.py -f win2008r2-01-a.img dlllist -p 1292 | grep -B 1 -i “command line” Volatility Foundation Volatility Framework 2.3.1 TPAutoConnSvc. pid: 1292 Command line : “C:Program FilesVMwareVMware ToolsTPAutoConnSvc.exe” $ vol.py -f win2008r2-01-a.img dlllist -p 1328 | grep -B 1 -i “command line” Volatility Foundation Volatility Framework 2.3.1 TPAutoConnect. pid: 1328 Command line : TPAutoConnect.exe -q -i vmware -a COM1 -F 30
The VMware Knowledge base (2014) identifies TPAutoConnect.exe and
TPAutoConnSvc.exe as being started when the Virtual Printing module is installed. We
can see from the pslist output that TPAutoConnSvc.exe is started by the services control
manager (SCM) in session 0. TPAutoConnect.exe is started as part of the initialization of
session 1 by TPAutoConnSvc.exe. The VMware tools service (vmtoolsd.exe) is installed
on guest Windows operating systems (VMware, 2011). From the output of pslist, we see
that there is an instance of vmtoolsd.exe running in both session 0 and session 1. Thus,
these processes are added to the baseline.
Some memory artifacts are introduced by a user logon. LogonUI.exe is not
present because a user is logged in. Instead, several processes associated with a
successful logon are present including: taskhost.exe, conhost.exe, and dwm.exe. These
processes where not part of the initial baseline. Table 4 provides a revised list of the
processes that are started when a user logs on.
Name Parent Process Session Owner Path User not logged in
csrss.exe n Local System
%SystemRoot%System32
winlogon.exe n Local System
%SystemRoot%System32
LogonUI.exe winlogon.exe n Local System
%SystemRoot%System32
User logged in on console csrss.exe n Local
System %SystemRoot%System32
winlogon.exe n Local System
%SystemRoot%System32
taskhost.exe services.exe n user %SystemRoot%System32 TPAutoConnect.exe TPAutoConnSvc.exe n user conhost.exe crsrr.exe n user %SystemRoot%System32
Creating a Baseline of Process Activity for Memory Forensics! 1 0 !
Gordon!Fraser,[email protected]! ! !
Name Parent Process Session Owner Path dwm.exe svchost.exe n user %SystemRoot%System32 explorer.exe n user %SystemRoot% vmtoolsd.exe explorer.exe n user C:Program
FilesVMwareVMware Tools
User logged in remotely csrss.exe n Local
System %SystemRoot%System32
winlogon.exe n Local System
%SystemRoot%System32
taskhost.exe services.exe n user %SystemRoot%System32 TPAutoConnect.exe TPAutoConnSvc.exe n user C:Program
FilesVMwareVMware Tools
conhost.exe crsrr.exe n user %SystemRoot%System32 dwm.exe svchost.exe n user %SystemRoot%System32 rdpclip.exe services.exe n user %SystemRoot%System32 explorer.exe n user %SystemRoot% vmtoolsd.exe explorer.exe n user C:Program
FilesVMwareVMware Tools
Table 4: Revised Process Baseline for logon
Another group of artifacts is associated with an actual memory acquisition.
Cmd.exe was run in administrative mode (PID – 332) to get a command window from
which win64dd.exe (PID 868) was started to capture the memory image. When cmd.exe
is run, Windows also starts up a supporting process, console host (conhost.exe – PID
1228). While these last processes are not part of the process baseline, they are taken into
account when analyzing the memory image.
We also see three more processes: spoolsvc.exe, dllhost.exe, and msdtc.exe, which
were started by services.exe that are not part of the initial baseline. Dllhost.exe is
associated with the management of Component Object Model (COM) objects (Startup
Programs Database, 2014c). Msdtc.exe is the Distributed Transaction Coordinator
(Startup Programs Database, 2014d). Spoolsvc.exe is the spooler service and is
associated with printing (Startup Programs Database, 2014e).
2.3.2. Analyze Process Objects
Step 2 in the memory analysis methodology is to examine process objects. We
will use several Volatility plugins to do this starting with the dlllist plugin. Since it is
Creating a Baseline of Process Activity for Memory Forensics! 1 1 !
Gordon!Fraser,[email protected]! ! !
very verbose, we ran the command limiting its output to one process, smss.exe, which has
a PID of 232. The output of this command provides information about the command
used to initiate the process as well as the DLLs associated with the process, as seen
below.
$ vol.py -f win2008r2-01-a.img -p 232 dlllist Volatility Foundation Volatility Framework 2.3.1 ************************************************************************ smss.exe pid: 232 Command line : SystemRootSystem32smss.exe Base Size LoadCount Path —————— ————– ————– —- 0x0000000047a50000 0x20000 0xffff SystemRootSystem32smss.exe 0x0000000077120000 0x1a9000 0xffff C:WindowsSYSTEM32ntdll.dll
Since what we are interested in are the names of the process, the process ID, and
the command line used to start the process, we can use grep to create an abbreviated
output from the dlllist plugin that only prints out the lines with the PID and the command
line, as seen below.
$ vol.py -f win2008r2-01-a.img dlllist | grep -B 1 -i “command line” Volatility Foundation Volatility Framework 2.3.1 smss.exe pid: 232 Command line : SystemRootSystem32smss.exe — csrss.exe pid: 324 Command line : %SystemRoot%system32csrss.exe ObjectDirectory=Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16 — csrss.exe pid: 376 Command line : %SystemRoot%system32csrss.exe ObjectDirectory=Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16 — wininit.exe pid: 384 Command line : wininit.exe — winlogon.exe pid: 420 Command line : winlogon.exe — services.exe pid: 480 Command line : C:Windowssystem32services.exe — lsass.exe pid: 488 Command line : C:Windowssystem32lsass.exe — lsm.exe pid: 496 Command line : C:Windowssystem32lsm.exe —
Creating a Baseline of Process Activity for Memory Forensics! 1 2 !
Gordon!Fraser,[email protected]! ! !
svchost.exe pid: 588 Command line : C:Windowssystem32svchost.exe -k DcomLaunch — svchost.exe pid: 656 Command line : C:Windowssystem32svchost.exe -k RPCSS — svchost.exe pid: 744 Command line : C:WindowsSystem32svchost.exe -k LocalServiceNetworkRestricted — svchost.exe pid: 788 Command line : C:Windowssystem32svchost.exe -k netsvcs — svchost.exe pid: 836 Command line : C:Windowssystem32svchost.exe -k LocalService — svchost.exe pid: 884 Command line : C:WindowsSystem32svchost.exe -k LocalSystemNetworkRestricted — svchost.exe pid: 928 Command line : C:Windowssystem32svchost.exe -k NetworkService — svchost.exe pid: 216 Command line : C:Windowssystem32svchost.exe -k LocalServiceNoNetwork — spoolsv.exe pid: 904 Command line : C:WindowsSystem32spoolsv.exe — svchost.exe pid: 1040 Command line : C:Windowssystem32svchost.exe -k regsvc — vmtoolsd.exe pid: 1096 Command line : “C:Program FilesVMwareVMware Toolsvmtoolsd.exe” — TPAutoConnSvc. pid: 1292 Command line : “C:Program FilesVMwareVMware ToolsTPAutoConnSvc.exe” — dllhost.exe pid: 1456 Command line : C:Windowssystem32dllhost.exe /Processid:{02D4B3F1-FD88-11D1- 960D-00805FC79235} — msdtc.exe pid: 1612 Command line : C:WindowsSystem32msdtc.exe — svchost.exe pid: 1752 Command line : C:Windowssystem32svchost.exe -k LocalServiceAndNoImpersonation — taskhost.exe pid: 1276 Command line : “taskhost.exe” — TPAutoConnect. pid: 1328 Command line : TPAutoConnect.exe -q -i vmware -a COM1 -F 30 — conhost.exe pid: 1556 Command line : ??C:Windowssystem32conhost.exe — dwm.exe pid: 1116 Command line : “C:Windowssystem32Dwm.exe” — explorer.exe pid: 848 Command line : C:WindowsExplorer.EXE — vmtoolsd.exe pid: 2012
Creating a Baseline of Process Activity for Memory Forensics! 1 3 !
Gordon!Fraser,[email protected]! ! !
Command line : “C:Program FilesVMwareVMware Toolsvmtoolsd.exe” -n vmusr — cmd.exe pid: 332 Command line : “C:Windowssystem32cmd.exe” — conhost.exe pid: 1228 Command line : ??C:Windowssystem32conhost.exe — win64dd.exe pid: 868 Command line : win64dd /f win2008r2-01-a.img
We compare the output of the dlllist plugin to our baseline to validate the
commands used to start processes and to identify the service groups started by
services.exe. In doing so, we quickly identify three service groups: DcomLaunch,
RPCSS, and regsvc; all of which are not in the baseline and need to be added.
The process analysis step includes checking to make sure the process is running
under the expected account. This information is available using the getsid Volatility
plugin. The example below shows the output for one process with a PID of 488.
$ vol.py -f win2008r2-01-a.img -p 488 getsids Volatility Foundation Volatility Framework 2.3.1 lsass.exe (488): S-1-5-18 (Local System) lsass.exe (488): S-1-5-32-544 (Administrators) lsass.exe (488): S-1-1-0 (Everyone) lsass.exe (488): S-1-5-11 (Authenticated Users) lsass.exe (488): S-1-16-16384 (System Mandatory Level)
The Volatility output can be shortened using the uniq command as shown below.
Here is a list of each process and the account it runs under. This technique of using uniq
is not perfect. A few duplicate lines show up for System, but it still simplifies the
analysis process.
$ vol.py -f win2008r2-01-a.img getsids | uniq -w 18 Volatility Foundation Volatility Framework 2.3.1 System (4): S-1-5-18 (Local System) System (4): S-1-1-0 (Everyone) System (4): S-1-5-11 (Authenticated Users) System (4): S-1-16-16384 (System Mandatory Level) smss.exe (232): S-1-5-18 (Local System) csrss.exe (324): S-1-5-18 (Local System) csrss.exe (376): S-1-5-18 (Local System) wininit.exe (384): S-1-5-18 (Local System) winlogon.exe (420): S-1-5-18 (Local System) services.exe (480): S-1-5-18 (Local System) lsass.exe (488): S-1-5-18 (Local System) lsm.exe (496): S-1-5-18 (Local System) svchost.exe (588): S-1-5-18
Read more
Applied Sciences
Architecture and Design
Biology
Business & Finance
Chemistry
Computer Science
Geography
Geology
Education
Engineering
English
Environmental science
Spanish
Government
History
Human Resource Management
Information Systems
Law
Literature
Mathematics
Nursing
Physics
Political Science
Psychology
Reading
Science
Social Science
Home
Homework Answers
Blog
Archive
Tags
Reviews
Contact
twitterfacebook
Copyright © 2021 SweetStudy.com
Recent Comments