Another CTF with CyberDefenders; Rick & Morty forensics challenges courtesy of DFIRMadness.
#1 What’s the Operating System version of the Server? (two words)
The Current Version value 6.3 can be checked using the sysinfo operating system guide.
Answer: Windows Server 2012 R2
#2 What’s the Operating System of the Desktop? (four words separated by spaces)
Can see Product name gives us the OS of Desktop:
Answer: Windows 10 Enterprise Evaluation
#3 What was the IP address assigned to the domain controller?
Using RegRipper we can rip the SYSTEM hive. You’ll have make the hive clean as it’s dirty on it’s own using RLA from EZ Tools. Below you see the output, and the interface hive values:
The IP Address value is 10.42.85.10.
#4 What was the timezone of the Server?
Looking at the same output from Reg Ripper:
Allegedly the admin set the wrong timezone on the DC… This is actually backed up by looking at the Network Time Protocol (NTP) packets in Wireshark of Case001.pcap:
Let’s compare the packet capture with the Event Logs using Wireshark and evtxecmd respectively:
Here you can see the 4624 logon type 10 (RDP logon) logs compared with the Negotiation and Response packets on the Domain Controller. Here you will see there is a difference in timezones. E.g., the first logon according to the event logs is 19 Septembmer 2020 03:21:48, whereas the requests leading up to this are roughly an hour beforehand according to the PCAP. Events are stored in UTC time but are shown in actual local time. The OS works with UTC timestamps. Taking the event logs as the accurate time would be appropriate here, therefore rather than UTC-7, because of the 1 hour diference, it would be UTC-6.
#5 What was the initial entry vector (how did they get in)?. Provide protocol name.
User logons for domain-joined accounts are logged on the security event logs.
From the Packet Capture in the previous question, the User of interest is the Administrator user. Initially all 4624 logs look unsuspicious, but then a Remote Host named ‘Kali’ is shown with a logon type of 3, followed by logon type of 10 (RDP).
Note that Type 3 is sometimes shown as NLA is an authentication from Remote Desktop Protocol.
Furthermore that remote IP address, 194.61.24.102 originated from Russia:
Answer: RDP
#6 What was the malicious process used by the malware? (one word)
For this question we’ll use the citadeldc01.mem memory capture with Volatility:
vol.exe -f C:\Users\SANSDFIR\Documents\c15-SzechuanSauce\citadeldc01.mem — profile=Win8SP0x64 psxviewThe following processes are hidden from the eprocess list:
Indicative of DKOM. Please note that on Volatility 2.6, process names are capped at 14 characters. To further assess which are suspicious we must check the parent-child processes:
vol.exe -f C:\Users\SANSDFIR\Documents\c15-SzechuanSauce\citadeldc01.mem — profile=Win8SP0x64 pstreeFrom the list, coreupdater.ex has an unknown parent process and was spawned at a time irregularly to other processes:
We will not be able to dump the process using procdump by process because it is unlinked to the eprocess doubly linked list. Instead either by offset or with regex. Unfortunately in both cases, the PEB for hte process is unvailable possibly due to paging:
Memdump can dump the process alternatively as a dmp file but that won’t demonstrate whether it is malicious or not. We can actually dump the file from the pcap as it was downloaded through HTTP objects.
And this is flagged as Metasploit; an injected process:
#7 Which process did malware migrate to after the initial compromise? (one word)
We can look for evidence of reflective or hidden code injection since this is what Meterpreter typically does in processes.
volatility.exe -f C:\Users\SANSDFIR\Documents\c15-SzechuanSauce\citadeldc01.mem — profile=Win2012R2x64_18340 malfind
PID 3724
#8 What IP address delivered the payload?
From Question 6 of following the HTTP objects we can see the IP address associated with CoreUpdater was 194.61.24.102
#9 What IP Address was the malware calling to?
Switching to PowerShell to use the Select-String command:
volatility.exe -f C:\Users\SANSDFIR\Documents\c15-SzechuanSauce\citadeldc01.mem — profile=Win2012R2x64_18340 netscan | Select-String “coreupdater”We see the malware was calling to 203.78.103.109 over port 443:
#10 Where did the malware reside on the disk?
Unfortunately volatility is unable to read the PEB for this task in order to retrieve through dlllist or from reading the eprocess block. For this one you could easily grab this from running filescan. Thereare multiple ways of getting this; super timelining, Usnjrnl, etc. But hte most obvious is to just analyse the MFT.
You can extract this from the Root in FTK imager of the actual .E01 image. From here use MFTEcmd.exe to then parse this into a CSV file to analyse:
MFTECmd.exe -f “C:\Users\SANSDFIR\Documents\c15-SzechuanSauce\Analysis\$MFT” — csv “C:\Users\SANSDFIR\Documents\c15-SzechuanSauce\Analysis”
Then search for coreupdater:
Parent path is there:
C:\Windows\System32\coreupdater.exe
Alternatively:
volatility.exe -f C:\Users\SANSDFIR\Documents\c15-SzechuanSauce\citadeldc01.mem — profile=Win2012R2x64_18340 filescan | Select-String “coreupdater”
11. What’s the name of the attack tool you think this malware belongs to? (one word)
We know this already from the signatures…
Metasploit
12. What IP adress is located in Thailand?
Switching to PowerShell to string select:
volatility.exe -f C:\Users\SANSDFIR\Documents\c15-SzechuanSauce\citadeldc01.mem — profile=Win2012R2x64_18340 netscan | Select-String ‘(coreupdater|spoolsv)’
There we see one IP of interest, let’s analyse it in VT:
There we see it’s associated with TH.
Answer: 203.78.103.109
13. Another malicious IP once resolved to klient-293.xyz . What is this IP?
We have two IP addresses that are malicious; 1 that delivered the payload and the other that is the C2.
The IP address delivering the CoreUpdater.exe file was 194.61.24.102. Checking VirusTotal:
#14 The attacker performed some lateral movements and accessed another system in the environment via RDP. What is the hostname of that system?
There are two (and probably more) ways of doing this; pcap analysis and looking back over the security event logs at RDP logins (Type 10 and 3). Type 7 is typically RDP reconnections also. This is also laterally moving from the Domain Controller with IP address 10.42.85.10
At the bottom of the pcap searching for rdp you can see a request from teh DC to a host with IP address 10.42.85.115.
To find the hostname, we can use LLMNR which is based on DNS but for local links to find hostnames based on IP addresses:
Here we see the machinename is Desktop-SDN1RPT.
This can also be seen by searching for the ServiceName corresponding to authentication logs form DC to machine with ip 10.42.85.115:
Searching by this destination IP, can therefore see the 4 different logons:
Answer: DESKTOP-SDN1RPT
#15 Other than the administrator, which user has logged into the Desktop machine? (two words)
Well we can see mortysmith and ricksanchez logged in around the time of interest:
The solution is after their full name however.
Answer: Rick Sanchez
#16 What was the password for “jerrysmith” account?
We can grab the domain hashes of all users across the domain from the Domain Controller ntds.dit file and SYSTEM hives.
I have already grabbed the SYSTEM hive located in C:\Windows\System32\config. Next we will grab the ntds.dit file located in C:\Windows\NTDS.
From there, we can grab the hashes with secretsdump. Transferring this over to Kali:
We run secretsdump and can see there are multiple hashes for jerrysmith.
None of these are cleartext so we will have to bruteforce or run a dicitonary attack using either John or Hashcat.
john hashes.txt.ntds — format=NTFrom running this you’ll find the password to be:
jerrysmith:!BETHEYBOO12!
Alternatively you can go to Hashes.com and search for the hash:
There you’ll see it!
#17 What was the original filename for Beth’s secrets?
This was found looking at the Web Cache for the domain controller. Interestingly enough this was accessed from a fileshare to the Domain Controller, indicating the device Desktop-SDN1RPT hosts this.
Answer: SECRET_BETH.TXT
#18 What was the content of Beth’s secret file? ( six words, spaces in between)
This was the WebCacheV01.dat file extracted from the Admnistrator subfolder on machine Desktop-SDN1RPT. The domain controller likely hosted this if they didn’t have a dedicated fileserver on the envrionment. I mean you could also look at Security event logs for file shares authenticated using 5140 event Ids but this CTF has only two machines so let’s hunt in the DC.
What do you know! Extract Beth_Secret.txt and we’re good.
This isn’t the flag… We’re missing something. Perhaps try the Recycle Bin then volume shadow copies if possible…
The RID of system Administrators is 500 so this is a good place to start!
Extract and view the two deleted files:
Answer: Earth Beth is the real beth
#19 The malware tried to obtain persistence in a similar way to how Carbanak malware obtains persistence. What is the corresponding MITRE technique ID?
There are multiple ways malware persists; DLL Injection, Autostart Extensibility Points, Services, Scheduled Tasks, etc. The malware itself also injected itself into a legitimate process with SYSTEM privileges also (spoolsv).
This can be done multiple ways; looking at the registry entries for System and Software also. What would be easier is to see the autoruns outputs as these would give these anyway. From there we can search for the coreupdater.exe malware:
Both services and ASEPs were triggered here. You’ll also see that the times are off indicating registry timestomping. It doesn’t seem like registry auditing was enabled for this device so you wouldn’t be able to see if registry values were modified in the event logs. Can find more on why it’s very difficult to prove registry timestomping without EDR/Sysmon in place here.
If we look at the System hive to see the services:
We will see the coreupdater service was last edited Sep 19 at 03:27:49 so this wasn’t timestomped but edited. Worrying there are 10-year old services, but anyway.
Going now to the Carbanak profile on Mitre:
We can see that Service Modification is a persistence mechanism that aligns with the persistence mechanism found in coreupdater!
We can even see the permissions in the Memory dump:
vol.exe -f C:\Users\SANSDFIR\Documents\c15-SzechuanSauce\citadeldc01.mem — profile=Win2012R2x64_18340 getsids -p 3644
Answer: T1643.003
Done, finished, complete.
