Hackerween 2022 - Day 1
Armand Alvarez | Thursday, October 27, 2022
What is Hackerween?
Hackerween is a holiday-challenge that has 5 rooms, one released each day from the 27th of October up until Halloween! These rooms will increase in difficulty, with the first two rooms being for beginners, then getter harder and harder. You can read more at this blog post.
The first Room - PrintNightmare, Again!
The first room can be found here
The scenario describes an employee overhearing two co-workers discussing the PrintNightmare exploit and how they can use it to elevate their privileges on their local computers.
Our task is to inspect the artifacts on the endpoint and to detect the exploit they used.
We have a few more notes:
- Note: Use the FullEventLogView tool. Go to
Options > Advanced Options
and setShow events from all times
.
So, we know that this room deals with the PrintNightmare vulnerability, or CVE-2021-34527. You can read the Microsoft Security Response Center (MSRC) report on it here
To summarize the writeup, a RCE vuln exists when the Windows Print Spooler service improperly performs privileged file operations. It can allow an attacker to run code with SYSTEM privileges. The security update for Windows Server 2012, Win Server 2016, and Windows 10, version 1607 has been released.
We also see the notes: "In addition to installing the updates, in order to secure your system, you must confirm that the following registry settings are set to 0 (zero) or are not defined (Note: These registry keys do not exist by default, and therefore are already at the secure setting.), also that your Group Policy setting are correct (see FAQ):
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint
NoWarningNoElevationOnInstall = 0 (DWORD) or not defined (default setting)
UpdatePromptSettings = 0 (DWORD) or not defined (default setting)
Having NoWarningNoElevationOnInstall set to 1 makes your system vulnerable by design."
Once our machine has launched, we can click Show Split View at the top of the page to open a side window with the Windows machine.
Going through the tasks
The user downloaded a zip file. What was the zip file saved as?
We are greeted to a Desktop with two files on it: traffic.pcap (a PCAP, or packet capture, file) and Logfile.CSV, which we can presume to be some sort of log file.
Before we analyze, lets talk about the five tools we have on our Taskbar:
-
FullEventLogView: A tool that displays in a table the details of all events from the event logs of Windows
-
ProcDOT: Turns thousands of monitored activities into a big behavioral picture
-
Wireshark: Network protocol analyzer, this lets us view packet capture details
-
Brim: Network forensics and packet capture analyzer
-
Powershell: CLI tool to interact with the computer (kind of like the Windows version of Terminal)
Our Hint says to try using ProcDOT or FullEventLogView.
We can dump our Logfile.CSV into the Procmon portion of the ProcDOT application, and our traffic capture into the Windump portion. We can use the plugin "Files List" to view a list of files from our logfile and PCAP. If we search for any file with .zip, we see that the user BMurphy had a file in their Downloads folder called "levelup.zip". ProcDot also tells us that this file no longer exists.
The answer is levelup.zip
What is the full path to the exploit the user executed?
Now, lets look at the graph of how our user interacted with Powershell. We already loaded our Procmon and Windump monitoring logs into ProcDOT, now select the powershell process under "Render Configuration" and click Refresh. This generates a graph of all the processes and threads that Powershell created and how it interacted with different files. We see an interesting PS1 file, which is a powershell script. It is stored under a directory called CVE-2021-1675 which is related to the PrintNightmare vulnerability. If you put the full path of this Powershell script, you get the answer. This file was also deleted.
c:\users\bmurphy\Downloads\CVE-2021-1675-main\CVE-2021-1675.ps1
We could also find this PS1 file in our Files List plugin, using the same method as before.
What was the temp location the malicious DLL was saved to?
We are looking for a temp location, so we can go back to our Files List and search for any DLL by searching for the string ".dll". We see a temp location at c:\users\bmurphy\appdata\local\temp\3\nightmare.dll. This is the location.
What was the full location the DLL loads from?
We see another location that the nightmare.dll file used to be at, c:\windows\system32\spool\drivers\x64\3\new\nightmare.dll
What is the primary registry path associated with this attack?
This part requires a lot of digging on our graph. When looking under the processes to view (by selecting the Render Configuration Launcher in ProcDOT), I saw backgroundTaskHost. This is a normal windows EXE, but it seemed weird to me so I selected that and refreshed my graph. I then saw that it was touching an Autostart registry key (registry path.) This is really bizarre to me. Why would an Exe that is part of the Windows Cortana software be touching an Autostart location???
I started stepping through the event step-by-step. (You can do that with the controls ont he bottom of the application). We see that backgroundTaskHost.exe first kills its own process before setting the Autostart registry key. This kicks off spoolsv.exe which then copies the temporary exploit location to a more permanent one whcih we will call "New". Eventually it renames the file, taking out the "New" and it is just c:\Windows\System32\spool\drivers\x64\3\nightmare.dll.
Then, it creates the New file again, continues copying the temporary Nightmare.dll to it, then it queries and sets the PendingFileNameOperations registry, which can be used to automatically delete or move a file on reboot with values of a mxdwdrv.dll and nightmare.dll. We can guess the actor is probably trying to hide the nightmare.dll date in this system32/spool/driver location. They also create a new mxdwdrv.dll and rename it to the original one. Then it writes data to this mx dll. It finally sets the THMPrinter configuration file & Data file to the nightmare.dll information, and the driver to this new, fake mxdwdrv.dll file.
To summarize, it seems like it messed with Autostarts (super scary), hid this nightmare.dll in another, normal looking dll, then had the Printer data file load from this normal looking dll, which contained the malicious nightmare.dll code. Super scary stuff!
HKLM\System\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\THMPrinter\Data File
What was the PID for the process that would have been blocked from loading a non-Microsoft-signed binary?
The process that has been loading the malicious files is spoolsv.exe, with a PID of 2600. So, ideally, it should have been blocked from loading this non-Microsoft-signed binary.
What is the username of the newly created local administrator account?
We can run the command "net user" to see the users on a machine. We can see the user backup which is a bit suspicious on a workstation.
What is the password for this user?
To do this, the hint tells us to use ProcDOT to find the Powershell history file. We can go to the powershell.exe launcher in the Render Configuration, and load the graph. From there, open the Files List and you can see the powerhshell consolehost_history.txt file location. After, you can go on powershell and invoke the command get-content <location to powershell history file>
to see its contents. This gives you the username and password for the new user.
The password is ucGGDMyFHkqMRWwHtQ
What two commands did the user execute to cover their tracks? (no space after the comma)
In the same file we can see two commands that stick out for covering tracks, a rmdir command and a del command. These are the answers. Our actor removed the CVE directory and deleted the levelup.zip file.
rmdir .\CVE-2021-1675-main\,del .\levelup.zip
This was absolutely a difficult CTF, and if you didn't get it the first time, don't fret. I have done my fair share of CTF's on TryHackMe, and I struggled.... a lot. Read up on how to use ProcDOT, there are a lot of good articles out there. And if all else fails, just poke around a bit. You may find something you didn't expect.
*Notes: I could not get FullEventLogView to work. I gave it the full path for the .CSV log file and it wouldn't work. Kept giving me an error about the path being corrupted or something. If anybody has suggestions, please tweet me @_Armand_Alvarez. Happy Hacking!!