Adding Lab 0 & update main README · stuxnet999/MemLabs@2150829 · GitHub
@@ -0,0 +1,141 @@
1+
# **MemLabs Lab 0 - Never Too Late Mister**
2+3+
This directory has been created to aid first-timers in learning how to approach a CTF-styled memory forensics challenge and also learn the plugins of the memory analysis framework, **Volatility**.
4+5+
So here I'll be writing a very elaborate walkthrough of a memory forensics challenge which I made for the **BSides Delhi CTF 2018**. The challenge is fairly easy in difficulty and I believe will be a great example challenge for everyone new to this.
6+7+
Onto the challenge now.
8+9+
## **Challenge Description**
10+11+
My friend John is an "environmental" activist and a humanitarian. He hated the ideology of Thanos from the Avengers: Infinity War. He sucks at programming. He used too many variables while writing any program. One day, John gave me a memory dump and asked me to find out what he was doing while he took the dump. Can you figure it out for me?
12+13+
Challenge file: [Google drive](https://drive.google.com/file/d/1MjMGRiPzweCOdikO3DTaVfbdBK5kyynT/view)
14+15+
### Initial Thoughts
16+17+
In most beginner level CTFs whenever we are provided with a memory forensics challenge, we also have a description which gives out certain clues. Identifying these clues can be quite tricky at first but becomes easier if you go on playing more & more CTFs.
18+19+
Now the clues that we can pick from this description are as follows:
20+
+ Environmental Activist (Since the word is quoted)
21+
+ John hates Thanos (Maybe useless but let us see)
22+
+ John sucks at programming and used too many variables.
23+24+
Now let us move into analyzing the memory dump.
25+26+
### Memory dump analysis
27+28+
We'll be analyzing the memory dump file (challenge.raw) using **Volatility 2.6** as it is best suited to our needs. All the labs in the repository can be solved using Volatility 2.
29+30+
The very first thing that anyone needs to know before proceeding to forensic analysis of a memory dump is to determine the **profile** we are going to use.
31+32+
The profile tells us the OS of the system or computer from which the dump was extracted. Volatility has a built-in plugin to help us determine the profile of the dump
33+34+
Now, we'll be using the **imageinfo** plugin
35+36+
`$ volatility -f Challenge.raw imageinfo`
37+38+
![Imageinfo](./Images/imageinfo.png)
39+40+
Now as you can see, volatility provides a lot of suggestions as to which profile you should use. In some cases, all of the suggested profiles may not be correct. To help get over this barrier, you may use another plugin called **kdbgscan**. As far as this challenge is concerned, using kdbgscan isn't required.
41+42+
Now as a forensic analyst, one of the most important things we would like to know from a system during analysis would be:
43+
+ Active processes
44+
+ Commands executed in the shell/terminal/Command prompt
45+
+ Hidden processes (if any) or Exited processes
46+
+ Browser History (This is very much subjective to the scenario involved)
47+48+
And many more...
49+50+
Now, to list the active or running processes, we use the help of the plugin **pslist**.
51+52+
`volatility -f Challenge.raw --profile=Win7SP1x86 pslist`
53+54+
![pslist](./Images/pslist1.png)
55+56+
Executing this command gives us a list of processes which were running when the memory dump was taken. The output of the command gives a fully formatted view which includes the name, PID, PPID, Threads, Handles, start time etc..
57+58+
Observing closely, we notice some processes which require some attention.
59+60+
+ cmd.exe
61+
+ DumpIt.exe
62+
+ explorer.exe
63+64+
![pslist-2](./Images/pslist2.png)
65+66+
+ cmd.exe
67+
+ This is the process responsible for the command prompt. Extracting the content from this process might give us the details as to what commands were executed in the system
68+
+ DumpIt.exe
69+
+ This process was used by me to acquire the memory dump of the system.
70+
+ Explorer.exe
71+
+ This process is the one which handles the File Explorer.
72+73+
Now since we have seen that **cmd.exe** was running, let us try to see if there were any commands executed in the shell/terminal.
74+75+
For this, we use the **cmdscan** plugin.
76+77+
`volatility -f Challenge.raw --profile=Win7SP1x86 cmdscan`
78+79+
![cmdscan](./Images/cmdscan.png)
80+81+
If you can see from the above image, a python file was executed. The executed command was `C:\Python27\python.exe C:\Users\hello\Desktop\demon.py.txt`
82+83+
So our next step would be check if this python script sent any output to **stdout**. For this, we use the **consoles** plugin.
84+85+
`volatility -f Challenge.raw --profile=Win7SP1x86 consoles`
86+87+
![consoles](./Images/consoles.png)
88+89+
We see that a certain string `335d366f5d6031767631707f` has been written out to **stdout**. Now as one might observe, this is a **hex-encoded** string. Once we try to revert out the hex encoding, we get a gibberish text.
90+91+
![hex-revert](./Images/hexrevert.png)
92+93+
Now if you remember, we tried to deduce some clues from the challenge description. The first one was something with the word "environment". Now there are certain system determined variables called **Environment variables**
94+95+
To view the environment variables in a system, use the **envars** plugin. Going down the output, we see a strange variable by the name **Thanos** (Ah! so maybe that's why it was provided in the description.), the value of the variable is `xor and password`.
96+97+
`volatility -f Challenge.raw --profile=Win7SP1x86 envars`
98+99+
![envars](./Images/envars.png)
100+101+
Now, we have 3 things in total:
102+103+
+ The gibberish text resulted from reverting the hex-encoded string
104+
+ Xor
105+
+ Password
106+107+
Thinking for a while, makes us realise why the clue `xor` was provided. Let us try to attempt xor decoding on the gibberish text.
108+109+
```python
110+
a = "335d366f5d6031767631707f".decode("hex")
111+112+
for i in range(0, 255):
113+
b = ""
114+
for j in a:
115+
b = b + chr(ord(j) ^ i)
116+
print b
117+
```
118+119+
There are only 255 possibilities and if you see, the 3rd output is a suspicious text **1_4m_b3tt3r}**. That looks like part of the flag.
120+121+
Well, the next part is `password`. Using volatility, we can extract the NTLM password hashes using the **hashdump** plugin.
122+123+
`volatility -f Challenge.raw --profile=Win7SP1x86 hashdump`
124+125+
![hashdump](./Images/hashdump.png)
126+127+
Now the password hash we have to decrypt is `101da33f44e92c27835e64322d72e8b7`. We can use online NTLM hash cracking websites.
128+129+
![NTLM-cracker](./Images/ntlm.png)
130+131+
Well there you go, we have the other half of the flag --> **flag{you_are_good_but**. Concatenating the 2 parts gives us the whole flag.
132+133+
FLAG: **flag{you_are_good_but1_4m_b3tt3r}**
134+135+
I hope with the walkthrough provided for this simple CTF challenge, gives confidence and encourages you to try out the rest of the labs.
136+137+
If you have any doubts/queries, feel free to reach out to me --> [Contact me](https://github.com/stuxnet999/MemLabs#author)
138+139+
## Resources
140+141+
+ https://github.com/volatilityfoundation/volatility/wiki/Command-Reference