to track processes, the kernel uses a doubly linked list.

Each EPROCESS block (or EPROCESS

malware can unlink itself by a process called Direct Kernel Object Manipulation process) will have a flink (forward link) to the next process in the list, and a blink
(back link) to the previous process. When a process exits, the links are removed.

Command / use tool

online tool that provides a lot of information on a process like ID, parent process, Analyse Rogue Processes
normal location... + an EPS score on how frequent a process occurs on a windows EchoTrail
system (higher scores indicate more common processes)
Internal Content (what is in the file or log described)

Audit / Place to look up forensic artifacts

Feature/functionality
print all running processes within the EPROCESS doubly linked list why is it used...
- Virtual offset of EPROCESS block
- process name
- process identifier (pid) sub category
for each process pslist provides:
- parent process identifier (ppid)
(look for anomalies like stated in tree "analyse rogue processes")
- number of threads
- number of handles pslist
- process start time
Description/extra info
Use Virtual offsets
Find First Hit:
if you want to specify a process 1. Identify Rogue Processes
psscan plugin doesn't trust the standard kernel mechanisms for tracking processes ->
scans the entire memory
malware can unlink itself by a process called Direct Kernel Object Manipulation Tool
Scan physical memory for EPROCESS pool allocations

Scanners do not following the normal procedure to find processes. It does not make Solution/something_positive
finds unlinked/unallocated processes within the memory
use of the double linked list, instead it scans all of the memory

- Virtual offset of EPROCESS block

- process name
double test to check if process was indeed exit (and not just unlinked), is by - process identifier (pid) psscan Bad, needs extra attention
for each process pslist provides:
enumerating its process objects like DLLs and handlesm which are typically unlinked - parent process identifier (ppid)
(look for anomalies like stated in tree "analyse rogue processes")
(and hence missing) upon exit. - process start time
- process exit time
- page directory base offset
Bad standard config that need a config.
Uses Physical offsets "-o"
if you want to specify a process

print process list as a tree showing parent relationships (using EPROCESS linked wsmprovhost.exe powershell remoting was used
Powershell
list)
parant should be explorer.exe
- Virtual offset of EPROCESS block powershell.exe
pstree Powershell and WMI processes: svchost.exe as parant -> indicates admin account was used
- process name
- process identifier (pid)
for each process pslist provides (same as pslist): wmiprvse.exe look at its children for suspicious behaviors
- parent process identifier (ppid)
(look for anomalies like stated in tree "analyse rogue processes") WMI
- number of threads
ActiveScript consumer
- number of handles parant should be Scrons.exe
- process start time notorious event consumers
CommandLine consumer
Automatically identify suspicious system processes
like missing/wrong parents,proper process name, path,... Volatility Plugins

- PPID: expected parant

- Name: permutation malprocfind
- Path: execution from correct folder
- Priority: correct priority
- cmdline: expected args
- user: proper SID
- Sess: most run in session 0
- Time: time after boot
- CMD: cmd.exe parent
- PHollow: missing binary
- SPath: is the process running from a suspicious path like Temp

Compare processes and loaded DLLs with a baseline image

This plugin allows you to upload 2 images to compare them (one clean one as a
baseline and than also the one you want to analyse)

compares processes and their loaded DLLs (using data objects similar to pslist and
ldrmodules)
Processbl
matches Image Name
extra plugins
compares services using the svcscan components to perfrom comparisons
Servicebl
processbl
matches Service Name

compares loaded drivers with modscan functionality

driverbl
matches Service Key Name

- -K: "known" entries can be displayed (if a match is found)

both can be very helpful and they should both be used and analysed
- -U: "unknown" entries can be displayed (not a match)

have a baseline image of the workstation/server

Physical offset is the actual location of an entity. With the right tools, you can
provide this hex valua and go to the the physical location of, for example, the
EPROCESS block. Virtual vs Physical offset: be shure to use the right kind of offset (Physical vs Virtual)
Certain tools, like pslist, ask for the Virtual offset.
Virtual offset: the location of how the system uses the entity. If this is different from
the physical, a mapper should be used somewhere. So it is the physical memory +
all its virtual pages it uses.