CST 3510 – RESIT FOR

COURSEWORK 2
[Document subtitle]

[DATE]
TUHIN
[Company address]
 1

Table of Contents
Create a clean memory dump using WinPmem. (10%) ................................................ 2

Comparative analysis of the processes in both dumps ............................................... 3

Series of questions to answer covering all areas of analysis (75%) ............................... 5

1.Windows objects that you can find in both memory dumps ................................... 5

Windows objects in both Infected and clean dump: ............................................. 6

2. Enumerate how many connections .................................................................... 8

Clean Dump Connections: ................................................................................ 8

Infected Dump Connections: ............................................................................. 9

3. Describe 5 modules that are currently loaded in both dumps. ........................... 10

Windows modules in both Infected and clean dump: ......................................... 10

4. Recover the command history ......................................................................... 12

Command history both Infected and clean dump: ............................................. 13

5. Recover the password hashes and the LSA secret keys ...................................... 13

In clean dump: ................................................................................................ 14

In infected dump: ............................................................................................ 15

LSA in Infected Dump: ..................................................................................... 16

LSA IN clean: .................................................................................................. 17

Bibliography: ......................................................................................................... 19

References: ........................................................................................................... 19
 2

Create a clean memory dump using WinPmem. (10%)

Winpmem Image Acquisition:
Before delving into the memory analysis of images from both operating systems, the
initial step required us to acquire the memory image of the appropriate clean operating
system. This was accomplished using Winpmem, a memory acquisition tool designed
for capturing volatile memory across various architecture systems.Creating the clean
memory dump as “clean.raw” in figure 1.

Figure no.1

As you can see in the screenshot above, following command has been used to capture
the memory of 32-bit Windows XP system:

‘winpmem.exe -o test.raw –volume format raw -dd -t’

Where test1.raw will be the name of resulting image, format defines the extension in
which the memory image will be acquired.

And as you can also see in the screenshot below (figure no. 2), we have successfully
acquired our image of the clean Windows XP using volatility. The driver unloaded
instruction you see in the screenshot below corresponds to the working of Winpmem in
acquiring the bit-by-bit image of an operating system. It loads its own driver into the
system whose image needs to be acquired, creates a temporary image by an extension
of pmem and when the specific format image is completed it deletes the temporary
image and unloads its driver from the operating system.
 3

Figure no. 2

Perform comparative analysis of the processes in both

dumps (10%)

Analysis of the processes:

I used the following command to get the processes list on both infected and clean
images (Figure no. 3):

python2 vol.py -f <path to image file (infected & clean)> pslist

python2: Specifies using Python 2, ensuring compatibility with Volatility 2.x.

vol.py: The main script for running Volatility analyses on memory dumps.

-f: A flag to specify the memory image file to analyze.

<path to image file (infected & clean)>: The actual path to your memory dump file
(e.g., -f /path/to/infected_dump.raw).

pslist: A Volatility plugin that lists the processes running in the memory dump.
 4

Figure no. 3

I have highlighted suspicious processes in infected dump (wc.exe, mdd.exe,wuauclt.exe,

msimn.exe, msmsgs.exe and msmsgs.exe) as in Figure no 3.

Suspicious Processes in the Infected Dump

1. msmsgs.exe (Windows Messenger):

o Typically, this is a legitimate Windows Messenger process. However, in some
malware infections, this process name is used to disguise malicious activities.
2. msmsgs.exe (CTF Loader):
o This is a legitimate process related to the Windows input service. However, it
can be used by malware to persist on a system.
3. wuauclt.exe (Windows Update):
o This is a legitimate process for Windows Update. Malware sometimes uses
this process name to hide malicious activities.
4. msimn.exe (Outlook Express):
o This is a legitimate process for Outlook Express. It can be used by malware to
disguise its activities.
5. wc.exe:
o This is not a standard Windows process and is highly suspicious. Further
investigation is needed to determine its nature.
6. mdd.exe:
o This is not a standard Windows process and is highly suspicious. Further
investigation is needed to determine its nature.

Processes Unique to the Infected Dump

• msmsgs.exe
• ctfmon.exe
• wuauclt.exe
• msimn.exe
• wc.exe
 5

• mdd.exe

Processes Unique to the Clean Dump

• VBoxService.exe
• VBoxTray.exe
• wscntfy.exe
• wpabaln.exe
• winpmem_3.2.exe

Processes in Both Dumps

• System
• smss.exe
• csrss.exe
• winlogon.exe
• services.exe
• lsass.exe
• svchost.exe
• spoolsv.exe
• alg.exe
• explorer.exe
• cmd.exe

Series of questions to answer covering all areas of

analysis (75%)
1. List the different types of Windows objects that you can find in
both memory dumps and explain them. Also, count the number
of instantiations (or repetitions) for every object.
Windows Objects:
Volatility uses multiple tags for displaying the objects present in the memory image.
One tag ‘objtypescan’ scans all windows objects currently present in the volatile
memory as shown in the screenshot below (figure no. 4).

Figure no. 4
 6

Windows objects in both Infected and clean dump:

As you can see in the screenshot below that I used ‘objtypescan’ to list all the objects
present in the infected Os’ memory dump and clean memory dump using the following
command: (figure no. 5).

python2 vol.py -f <path to image file (infected & clean)> objtypescan

• python2: Specifies using Python 2, ensuring compatibility with Volatility 2.x.

• vol.py: The main script for running Volatility analyses on memory dumps.
• -f: A flag to specify the memory image file to analyze.
• <path to image file (infected & clean)>: The actual path to your memory dump
file (e.g., -f /path/to/infected_dump.raw).
• objtypescan: A Volatility plugin that scans for and lists objects by type in the
memory dump.

Figure 5

I have analysed the windows objects in both infected and clean memory dump (figure
no. 5).

I have added the description of each objects (32) and counted the objects present in
both memory dump.
 7

Object Type Description Count in Count in

Clean Dump Infected
Dump
FilterConnectionPort Used by the Windows Filtering 2 2
Platform for communication
FilterCommunicationPort Similar to FilterConnectionPort, used 2 2
for communication
IoCompletion Represents I/O completion objects 2 2
Driver Represents device drivers loaded in 2 2
memory
Device Represents device objects created by 2 2
drivers
Controller Represents controller objects 2 2
managing hardware devices
Adapter Represents network adapters or 2 2
similar hardware devices
Key Represents registry keys 4 4
Section Represents memory sections 4 4
Desktop Represents desktop objects 4 4
WindowStation Represents window station objects 4 4
KeyedEvent Represents keyed event objects for 4 4
thread synchronization
Timer Represents timer objects 4 4
Semaphore Represents semaphore objects for 4 4
managing access to resources
Callback Represents callback objects 4 4
Mutant Represents mutant (mutex) objects for 4 4
thread synchronization
EventPair Represents paired event objects for 2 2
synchronization
Event Represents event objects for signalling 4 4
Process Represents process objects 4 4
Debug Object Represents debug objects used by the 2 2
debugging subsystem
Job Represents job objects, used to 2 2
manage groups of processes
Thread Represents thread objects 4 4
WmiGuid Represents WMI GUID objects used 2 2
for Windows Management
Instrumentation
File Represents file objects 4 4
WaitablePort Represents waitable port objects 2 2
Port Represents port objects 4 4
Token Represents security tokens 4 4
SymbolicLink Represents symbolic link objects 2 4
Directory Represents directory objects 2 4
 8

From the provided memory dump, check the live sockets. Enumerate
how many connections there are and where these connections are
pointing. Distinguish between localhost connections, local network
ones and public network connections

Here you can see in (Figure no. 6 & 7). There are number of connections in both dumps.
I have used command:

python2 vol.py -f <path to image file (infected & clean)> connscan

• python2: Specifies using Python 2, ensuring compatibility with Volatility 2.x.

• vol.py: The main script for running Volatility analyses on memory dumps.
• -f: A flag to specify the memory image file to analyze.
• <path to image file (infected & clean)>: The actual path to your memory dump
file (e.g., -f /path/to/infected_dump.raw).
• connscan: A Volatility plugin that scans for network connections in the memory
dump

Clean Dump Connections:

Figure no. 6

Localhost Connections: None (all connections are external)

Local Network Connections: None (all connections are to public IPs)
Public Network Connections:
• 10.0.2.15:1035 to 20.109.209.108:443
• 10.0.2.15:1030 to 110.93.229.226:80
 9

Infected Dump Connections:

Figure no. 7

Localhost Connections:
• 0.0.0.0:0 to 1.0.0.0:0 (indicative of various system processes)

Local Network Connections:

• 172.16.150.20:1291 to 58.64.132.141:80
• 172.16.150.20:1292 to 172.16.150.10:445
• 172.16.150.20:1281 to 172.16.150.10:389
• 172.16.150.20:2862 to 172.16.150.10:135
• 172.16.150.20:1280 to 172.16.150.10:389

Public Network Connections: None (all other connections are to private IPs)

Analysis:
Clean Dump: All connections are to public IP addresses (20.109.209.108,
110.93.229.226) from a local IP 10.0.2.15, suggesting external network
communications. (Figure no. 6)

Infected Dump: Includes a mix of local network connections (172.16.150.20) to various

ports on 172.16.150.10, and external connections to public IP 58.64.132.141. (Figure
no. 7)
 10

Describe 5 modules that are currently loaded in both dumps. (15%)

Volatility uses multiple tags for displaying the modules present in the memory image.
One tag ‘modules’ that list all the loaded modules currently in the volatile memory as
shown in the screenshot below (figure no. 8).

Figure no. 8

Here you can see the below screenshot. There are number of modules listed in both
dumps. I have used command (Figure no. 9):

python2 vol.py -f <path to image file (infected & clean)> modules

• python2: Specifies using Python 2, ensuring compatibility with Volatility 2.x.

• vol.py: The main script for running Volatility analyses on memory dumps.
• -f: A flag to specify the memory image file to analyze.
• <path to image file (infected & clean)>: The actual path to your memory dump
file (e.g., -f /path/to/infected_dump.raw).
• modules: A Volatility plugin to list loaded kernel modules in the memory dump.

Windows modules in both Infected and clean dump:

 11

Figure no. 9

Modules in Clean Dump:

1. ntoskrnl.exe: Windows NT Kernel & System - essential component managing

system resources, memory, and processes.

2. hal.dll: Hardware Abstraction Layer - facilitates communication between the

hardware and operating system, ensuring device independence.

3. pci.sys: PCI Bus Driver - controls PCI devices, enabling communication between
peripherals and the motherboard.

4. atapi.sys: IDE/ATAPI Port Driver - supports communication with IDE/ATAPI

devices like hard drives and optical drives.

5. Ntfs.sys: NT File System Driver - provides file system services and manages disk
operations for NTFS-formatted drives.

Modules in Infected Dump:

1. ntoskrnl.exe: Windows NT Kernel & System - core component managing system

resources and executing system functions.

2. hal.dll: Hardware Abstraction Layer - facilitates interaction between hardware

and the OS, ensuring hardware compatibility and functionality.

3. pci.sys: PCI Bus Driver - manages communication between the motherboard

and PCI devices, crucial for peripheral operation.
 12

4. atapi.sys: IDE/ATAPI Port Driver - enables communication with IDE/ATAPI

devices such as hard drives and optical drives.

5. Ntfs.sys: NT File System Driver - handles file system operations and manages
data on NTFS-formatted volumes.

Recover the command history and explain each command (including

input and output) that you can find inside it.

I have used the tag ‘cmdscan that list all the loaded modules currently in the volatile
memory as shown in the screenshot below (figure no. 10)

Figure no. 10

I have used the below command to see the command history in both memory dumps:

python2 vol.py -f <path to image file (infected & clean)> cmdscan

python2: Specifies using Python 2, ensuring compatibility with Volatility 2.x.

vol.py: The main script for running Volatility analyses on memory dumps.

-f: A flag to specify the memory image file to analyze.

<path to image file (infected & clean)>: The actual path to your memory dump file
(e.g., -f /path/to/infected_dump.raw).

cmdscan: A Volatility plugin that scans for command history within the memory dump.
 13

Command history both Infected and clean dump:

Figure no. 11

So you can see in figure this. I have highlighted the command “winpmem” Which I had
used for creating clean memory dump. (figure no. 11).

Highlighted command indicated that a suspicious process “mdd.exe” found which we

have discovered already in process list (pslist).

Provide a brief description of the RSA2 algorithm. Recover the

password hashes and the LSA secret keys of both memory dumps.
Report on any dilerences? How would you recover the original
passwords?

I have used the tag ‘hashdump that list all the loaded modules currently in the volatile
memory as shown in the screenshot below (figure no. 12)

Figure no. 12
 14

I have used the below command to see the command history in both memory dumps:

python2 vol.py -f <path to image file (infected & clean)> hashdump

python2: Specifies using Python 2, ensuring compatibility with Volatility 2.x.

vol.py: The main script for running Volatility analyses on memory dumps.

-f: A flag to specify the memory image file to analyze.

<path to image file (infected & clean)>: The actual path to your memory dump file
(e.g., -f /path/to/infected_dump.raw).

lsadump: A Volatility plugin that extracts LSA (Local Security Authority) secrets,
including password hashes and other sensitive information, from the memory dump.

In clean dump:

Figure no. 13

Figure no. 14

I didn’t find any hash of password in clean dump.

 15

In infected dump:
In the below (figure no. 15), you can see that there are number of accounts
(Administrator, Guest, HelpAssistant, Support and Sysbackup) whose password hash
dump are found:

Figure no. 15

We can see further check these hash on different tools to recover this such as using
hashcat (a tool in kali linux) or online hash cracking tools such as (crackstation.net):

I have pasted the hash of the Guest account on crackstation.net. They found that hash
in their list (Figure 16)

Figure no. 16

LSA Secret:
I have used the below command to see the command history in both memory dumps:

python2 vol.py -f <path to image file (infected & clean)> hashdump

python2: Specifies using Python 2, ensuring compatibility with Volatility 2.x.

vol.py: The main script for running Volatility analyses on memory dumps.

-f: A flag to specify the memory image file to analyze.

<path to image file (infected & clean)>: The actual path to your memory dump file
(e.g., -f /path/to/infected_dump.raw).
 16

lsadump: A Volatility plugin that extracts LSA (Local Security Authority) secrets,
including password hashes and other sensitive information, from the memory dump.

LSA in Infected Dump:

LSA secrets can contain plaintext passwords for accounts and services, allowing
unauthorized access. Access to DPAPI_SYSTEM and other encryption keys enables
decryption of sensitive data. Knowledge of service-related secrets can facilitate service
manipulation or impersonation for privilege escalation or persistence. Additionally,
passwords and NTLM hashes can aid in password cracking or user and machine
authentication across the network. (Figure 17)

Figure no. 17
 17

In the LSA dump provided, you can see several important pieces of
information (Figure no. 18):
1. Service Control Manager (SCM) Secrets: These are prefixed with _SC_ and
include services like Alerter, WebClient, and SSDPSRV.

2. Remote Desktop Help Assistant Secrets: Including passwords and SIDs for
remote desktop help accounts.

3. DPAPI_SYSTEM: This is the system's Data Protection API master key, used to
encrypt and decrypt sensitive data.

4. Hydra Encryption Key (L$HYDRAENCKEY): This is an encryption key used

internally by Windows.

5. Machine Account Passwords ($MACHINE.ACC): These are passwords

associated with machine accounts in the domain.

6. DefaultPassword: This is the default password for the system.

7. NL$KM: This is the NTLM (NT LAN Manager) hash of the system key, used for
hashing user passwords.

8. Various other keys and secrets: These include keys for services, GUIDs
(Globally Unique Identifiers), and more.

LSA IN clean:

Figure no. 18
 18

Figure no. 19

I didn’t find any LSA secret in clean dump. I tried both plugins of volatility2 and
volatility3. (Figure no. 18 & 19)
 19

Bibliography:

VirtualBox. (n.d.). Retrieved June 30, 2024, from https://www.virtualbox.org/

Kali Linux. (n.d.). Retrieved June 30, 2024, from https://www.kali.org/

Volatility. (n.d.). Retrieved June 30, 2024, from https://volatilityfoundation.org/

CrackStation. (n.d.). Retrieved June 30, 2024, from https://crackstation.net/

Velocidex. (n.d.). c-aff4 Releases. Retrieved June 30, 2024, from

https://github.com/Velocidex/c-aff4/releases

References:
https://www.virtualbox.org/

https://www.kali.org/

https://volatilityfoundation.org/

https://crackstation.net/

https://github.com/Velocidex/c-aff4/releases