This has been a pretty popular challenge and has been recommended to me quite a bit since my last write up. So, I thought why not give it a go and post my results!
I set out to follow the questions provided in the challenge and document my findings and how I came to the answer for each one.
I wasn’t sure how I would go so I thought to start small and just investigate the disk images for the server and desktop, then work from there. I ended up using the autoruns and pcap too.
Challenge Overview
“Your bedroom door bursts open, shattering your pleasant dreams. Your mad scientist of a boss begins dragging you out of bed by the ankle. He simultaneously explains between belches that the FBI contacted him. They found his recently-developed Szechuan sauce recipe on the dark web. As you careen past the door frame you are able to grab your incident response “Go-Bag”. Inside is your trusty incident thumb drive and laptop…”
Find the full details of the challenge here.
Timeline
Tools
To complete the challenge I used the following tools:
- KAPE
- Arsenal Image Mounter
- FTK Imager
- Timeline Explorer
- Wireshark
- ESEDatabaseViewer
Questions
Question 1: What’s the Operating System of the Server?
To find this we can check in a few places. First we can check using the file path C:\Windows\System32\license
Another way to identify the operating system is through the registry HKLM\Software\Microsoft\Windows NT\CurrentVersion
Answer: Windows Server 2012
Question 2: What’s the Operating System of the Desktop?
Following this same idea as above I was able to identify the OS of the Desktop.
Answer: Windows 10 Enterprise
Question 3: What was the local time of the Server?
This can be found in the control set registry
Alternatively, this information is also located in the event logs via the Event ID: 6013.
Answer: Pacific Standard Time (UTC−08:00)
NOTE: When reviewing the case summary, the location of this organisation is Colorado, which means the time zone is actually UTC-7 and the time is actually Mountain time not Pacific. This means the windows logs and packet capture times are not aligned. I have adjusted my answer regarding times to match that of the pcap which is the correctly configured time.
Question 4: Was there a breach?
In short, yes. We know from the case summary that the recipe was stolen, however this can lead to the question of how? Let’s find out.
Question 5: What was the initial entry vector (how did they get in)?
To begin, I started searching through the event logs of the server to identify any users who may have a high count of failed login attempts, any outlier or unfamiliar hosts.
From the event logs of CITADEL-DC1 we can note a large amount of failed remote logins to the Administrator account. These attempts are coming from a kali host and all within a short time of each other indicating a brute force attempt.
By searching for 4624 events after the these failed authentications, we can see the actor was successful as their as several connections were made from the IP address 194.64.24[.]102.
It was here I, noted the IP as a confirmed IOC for later reference in the investigation.
By examining the packet capture around the time noted in the event logs (~2:31 UTC), their is an initial ping request and response to the IP of the DC from the suspicious IP
Proceeding this is the beginning of the bruteforce attack against the DC.
Answer: Initial access was carried out by RDP Bruteforce to the DC.
Question 6: Was malware used? If there was malware answer the following…
6.a. What process was malicious?
When reviewing the pcap, I began searching for all traffic related to the suspect IP to see what happened beyond the initial access.
There are various GET requests from the noted IP for a suspicious looking URI “194.64.24[.]102/coreupdater[.]exe”. This initially occurred on the DC (10.45.85.10) and soon after on the desktop (10.45.85.115) from 194.64.24[.]102.
When inspecting these packets, we are provided further reasoning for suspicion as the method of delivery is a SimpleHTTP Python server. The use of quick hosting is a common method of deploying malware.
We can obtain the file downloaded using Wireshark to either run the hash through OSINT tools or run the file in a sandbox. This is done by going to File -> Export Objects -> HTTP…
then selecting and saving the identified file.
From here we can run Get-FileHash in Powershell to obtain the SHA256
Running the has with VT, it safe to say this is the malware we are looking for.
To confirm the download, we can check the webcache entries for any potential downloads matching this get request.
Knowing the initial download was on desktop, we can also check for any amcache entries.
Answer: coreupdater[.]exe
6.b What was the IP that delivered the payload?
Answer: 194.61.24[.]102
6.c. What IP Address is the malware calling to?
I took my chances with this question and thought to review the IoC’s from VT to see if it had reached out to any of the noted IP’s.
Running a search in Wireshark for the potential IP’s, we can identify one of the five had communicated with the hosts after the download of the coreupdater[.]exe file.
Answer: 203.78.103[.]109
6.d. When did it first appear?
Knowning the DC was the initial entry vector of the attacker, we can begin by reviewing the MFT entries of the system. There is an entry for coreupdater with the creation time of 2:24.06.
This matches the USNJrnl entries for the creation of the file
Answer: 2020–09–19 03:24:12 (UTC)
6.e. Did someone move it?
By analysing the webcache entries response header, we can confirm the the file was originally sent to the Administrators downloads folder.
Another indication is observed when we review the USNJrnl. By identifying the parent entry number of “coreupdater” (84880) on the DC , we can search for this in Timeline Explorer as an entry number. This shows the parent path of the file was the Downloads.
There is a second parent entry number at a later time which is the entry number of system32.
Similar events occurred on the Desktop when it was downloaded there. The parent entry number for this file was originally the downloads.
And was then later, entries of the file indicated the parent entry number to be that of System32.
Answer: It was then moved from the Administrators Downloads folder to the C drive of the DC and desktop systems.
Note: I tried passing the parent path of the USNJrnl various times but was unsuccessful, hence the workaround using the entry numbers.
6.f. What were the capabilities of this malware?
When we ran the file hash in VT for question 6.a., we can see community identifiers have indicated this to be Meterpreter/Metasploit.
This tool has a vast array of capabilities as it provides the attacker with a shell to the victim machine. From here they are able to further explore the victims device, pivot to other devices in the network or run/execute other payloads and commands.
6.g. Is this malware easily obtained?
Answer: Metasploit is a red teaming tool which is open source, so safe to say pretty accessible.
6.h. Was this malware installed with persistence on any machine? If so, when and where?
As persistence is commonly obtained through scheduled tasks, registry keys and services we can check the relavent artifacts around the time of the download and execution of the malware.
From the eventlogs we can check for the event id 7045 which logs any newly installed services. It is here, we can identify a newly installed service which is set to run at start up of the system.
The installation of the service, “coreupdater”, first occurred on the DC at 2:27:49 and at 2:42:42 on DESKTOP-SDN1RPT.
We can also see a registry key was created “coreupdater” on both systems. This key runs at start up of the system.
Answer: The malware created a service to run on startup on both the DC and Desktop as well as a registry key on both systems.
Question 7: What malicious IP Addresses were involved? Were any IP Addresses from known adversary infrastructure? Are these pieces of adversary infrastructure involved in other attacks around the time of the attack?
Answer: It appears at the time of the attack 194.61.24[.]102 was seen exploiting cve-2015–1635, a “HTTP.sys Remote Code Execution Vulnerability.” in windows servers.
It also appears the IP 203.78.103[.]109 was flagged in AlienVault at the time for being associated with Meterpreter in AV detection's.
These AV detection's were for files which have been flagged for similar network traffic observed in this attack.
Question 8: Did the attacker access any other systems? How? When?
When reviewing the pcap in Wireshark, we can search for RDP connections from the DC to the desktop after the initial access. By doing this we can see a connection from the DC to desktop at 2:36~.
We can also check the event logs of the desktop to confirm the successful RDP connection from the DC using the compromised Administrator account.
Answer: The attack was able to gain access to C137\DESKTOP-SDN1RPT$ via RDP from the DC using the Administrator account. This occurred at approx 2:36 on the 19th.
8.b. Did the attacker steal or access any data?
In order to identify any potentially accessed files we can check the MFT for the most recent documents in the file share accessed by the administrator account.
It appears the Administrator recently accessed all the files within the file share “Secret” folder.
Doing the same search in the desktop MFT entries, we see a similar event.
When exfiltrating data, it is common a malicious actor will create a staging zip file in which all the stolen data is stored to make the exfiltration a quick process.
We can search the USNJrnl for any newly created zip files. By doing so, we can identify a zip file on the desktop call “loot.zip” and on the DC, “secret.zip”.
In the images above (MFT entries) we can note two outlier LNK files. Loot and Secret, confirming these were created by the Administrator account and recently accessed.
Files Accessed entries from the webcache of both systems also show the administrator accessed these files.
Answer: The attacker was able to exfiltrate zip files from the DC and Desktop which appears to contain sensitive files from the DC’s fileshare and the desktop.
Question 9: What was the network layout of the victim network?
Answer: The network layout consisted of a DC and endpoint
Domain: C137 (10.42.85.0/24)
DESKTOP-SDN1RPT (10.42.85.10)
CITADEL-DC01 (10.42.85.115)
Question 10: What architecture changes should be made immediately?
Answer: Given the initial access was via an RDP bruteforce attack to the DC, the ability to RDP to the DC should be immediately disabled for external connections. The ability to RDP to the DC should only be accessible from those within the same local network.
Question 11: Did the attacker steal the Szechuan sauce? If so, what time?
Answer: Yes, this occurred at approximately 2:32pm as previously noted.
Question 12: Did the attacker steal or access any other sensitive files? If so, what times?
Answer: The attacker was able to access and exfiltrate various files from the fileshare on the DC.
It also appears a copy of SECRET_beth.txt was created at 3:38~, this was named Beth_Secret.txt. The original (SECRET_beth) was removed from the file system at 3:32~ as per the USNJrnl.
we can see this is a copy as the bytes of both files match in the MFT entry
Using FTK imager, we can view the recycle bin of the DC to confirm its removal.
FTK also allows us to view the contents of these text file which shows the that the contents of the replicated file was then modified.
Original:
Modified:
Question 13: Finally, when was the last known contact with the adversary?
Answer:When reviewing the event logs of the DC, we can see that the last user-initiated logoff was at 2:57.
Thanks to DFIR Madness for the awesome challenge and great resources. Check out more from DFIR Madness here
