# DeepDive Lab - Cyberdefenders

[Challenge](https://cyberdefenders.org/blueteam-ctf-challenges/deepdive/) - Sha1 : d3b61fe8df8a864090fb76f859e8838996abfc6e

## Discreption
You have given a memory image for a compromised machine. As a security blue team analyst Analyze the image and figure out attack details.

## Analysis

First Let's Dive to know the profile of the mem dump.
You will use `imageinfo` plugin to know the profile, but let's know how the plugin works.

### imageinfo :
1. The plugin first searches for and locates the "magic number" of the KDBG (Kernel Debugging Data Block), once this happen, it has an initial guess about what type of system the image came from.


2. Most often, you will see these two address spaces in the imageinfo output. The first is an address space for reading data from virtual addresses using the vtop methods we discussed earlier. The second lower address space is a simple wrapper around reading the input file from the disk.

3. Finally, it gives us the virtual address of the `_KUSER_SHARED_DATA` structure. It's a kernel data structure that holds some useful information (system date, time).


> From Service Pack, you should able to determine the profile, If there are many profiles with same service pack (that is because the KDBG header is same for a version of Windows), choose the generic one, If there any plugins doesn't work, try different profile with the same serivce pack.

>You can also use kdbgsan plugin to determine the most profile contains processes and modules to be the right profile.

So we determined the profile, let's get deep and list the processes to see what was runnig while dumping the memory, for that we will use `pslist`.

### pslist :
1. It uses the Kernel Debugging Data Block (KDBG) to find the PsActiveProcessHead variable. That variable points to the doubly linked list of processes (_EPROCESS).

2. `_EPROCESS` : It is a block contains process metadata. This metadata includes information such as Process Identifier, Parent Process Identifier, Process name, and the number of threads and handles within each process.

After listing all running processes, i noticed nothing malicious, maybe we can try pstree.

### pstree :
It is same as pslist but list processes in a tree view, but we can list the path the processes run form using `-v`


But still all processes run from their legitimate paths.

So the malicious process maybe it was unlinked from doubly linked list of processes (_EPROCESS), And if it is, we can look for it using 2 plugins `psscan`, `psxview` why??? from konwing the plugin functionality you will know.

### psscan :
It searches for the entire physical memory image for potential frames of pool memory that are "tagged" with a specific identifier, or pool tag, that indicates a process pool memory allocation. Once an allocation is identified, based on pattern matching, the psscan plugin extracts the process "metadata" from the `_EPROCESS` structure contained within the pool allocation using specific offsets.

> Pool Memory Concept 

> Pool Tag : Each pool header has a 4-byte tag that can identify the type of data stored in the entry.

### psxview :
It uses cross-view detection (Meaning though multiple methods).
1. `_EPROCESS` : So good that it's the default that is used with built-in Windows commands such as `tasklist`.
2. `ETHREAD` : Each ETHREAD has a pointer to a KTHREAD structure. This, in turn, points to a structure KAPC_STATE. This then turns to a KPROCESS structure for the process.
3. `Csrss.exe` : It has in its handle table a handle to all other processes on the system. This is because it is responsible for handling some setup and teardown of processes when they start and stop.
4. `PscpCidTable` : It contains a pointer to a list of HANDLE_TABLE structures which has a UniqueProcessId, which holds the process ID of the process.
5. `Sessions` : With the exception of System and smss.exe, processes will be associated with a session.
6. `Desktop Threads` : Desktops have Window Stations. Each Window Station has a pointer to a list of threads that are associated with the station which will point back to the process.

So let's compare the 2 plugins output.


You will notic that there is a process not listed in `psscan` plugin. But how???

The attacker can change the pooltag of a process to avoid detection. We know how the pooltage look like for a process `proc` and `Proã`.

> proc : it is normal pooltag.
> Proã : it is a protected pooltag to make it hard for malware to scan memory for it.

Let's go to the physical address of the malicious process `vds_ps.exe` `0x000000007d336950` we will see that each process when you go to the physical address, you will see the pooltage above it, actually there is a structure that you can go through and using `volshell` plugin you can determine the pooltag, but i prefer this way as it is easy.


The pooltag is not `proc` or `proã` it is `R0ot` located at `0x7D3368F4`. what if we fix it to the right pooltag and then run `psscan`.


So far so good...

let's dump this process from memory using `procdump` plugin.


Getting the sha-1 hash to virustotal.

It is `emotet` malware.


let's go to find the full path of that exe file in memory.

1. You can use `filescan` plugin to locate the exe in disk.
2. You can use `mftparser` or `usnparser` or `timeliner` to get the full path.
3. You can use `shimcache` to locate it if the attacker was opening the directory the he downloaded the exe to.


From shimcache we knew that the attacker opened a shared folder containing the malicious exe file to download exe from it `UNC\vmware-host\Shared Folders\Share-Win\vds_ps.exe`. And the full path on system is `C:\Users\john\AppData\Local\api-ms-win-service-management-l2-1-0\vds_ps.exe`.

Let's scan with malfind to see if there any injections inside the process.


There are 2 injections with `PAGE_EXECUTE_READWRITE` in memory, the first starts at address `0x2a10000`
and second at `0x2a80000`.

We can dump these MZs using `vaddump` plugin.


we will search for those start's with `0x2a10000` and `0x2a80000`.


It seemed that the second file has larger size so it will allocate virtual memory larger that first one.

Finally, there was a question about that the malicious process `vds_ps.exe` was hidden and he asked for the next process when tracing forward link.

Volatility `pslist` plugin is doing a great job while listing the process list `IDs` as it list them in order, so if you want to trace Blink or Flink of a process, it is recommneded to make pslist as a refernce for better detection, or just search and order the PIDs of each process to know the next process. This option will work if the attacker didn't implement `DKOM manupulation` to remove `_LIST_ENTRY` from `_EPROCESS` structure.


The mailcious process ID is `2448` so based on `pslist` it should be here between `vmtoolsd.exe` and `SearchIndexer.`. so the Flink will lead to` SearchIndexer.`.

-----

<iframe src="https://giphy.com/embed/8UF0EXzsc0Ckg" width="480" height="288" style="" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="https://giphy.com/gifs/finally-atlast-itsover-8UF0EXzsc0Ckg">via GIPHY</a></p>