Challenge Description

The challenge questions and the evidence files can be found at https://dfirmadness.com/the-stolen-szechuan-sauce/.

If you are learning different artefacts in Digital Forensics and want to apply it to a practice, then this challenge is more help for you. Some of the important artefacts covered in this challenge are:

  • LNK Files
  • Event Log
  • MFT
  • UsnJrnl
  • Autoruns
  • AmCache
  • Windows Registry
  • Memory image analysis
  • Network Capture, and so on.

During any investigation, we will have a lot of evidence files like Disk images, Memory images, Network captures etc. In my opinion only thing matters is the method how these evidence were approached.

In this challenge, we are provided with disk image from a domain controller, Desktop system. Their supporting memory images and autoruns files.

Note: This incident occurred at an organization located in Colorado in September. So, this places the incident at UTC -6. Keep this in mind when looking at the output of various tools.

Note: This post do not contain a static/dynamic analysis of any malicious binary during the investigation. It is completly based on the Forensics side of things in solving the challenge.

Initial Analysis

As per the description and file names, we can figure this seems to be a Windows box. Navigated the registry and got the extract OS information details.

DC01:

OS Info

DESKTOP-SDN1RPT:

OS Info

As we can see from the above screenshots, DC01 is running on Windows Server 2012 R2 Standard Evaluation and DESKTOP-SDN1RPT is running on Windows 10 Enterprise.

Now that we got the basic info about the disk image we have, let us start analyzing the Network capture given in the evidence.

Network Capture Analysis

For the Network Capture analysis, I will be using Wireshark to view the packets transferred between the devices.

After opening the Network capture in Wireshark and checking the Protocol Hierarchy, we can see a lot of information such as SMB, Kerberos, RDP, and some HTTP packets.

Analyzing HTTP Packets

By applying the HTTP filter to wireshark, we can see some files being accessed.

We can use Export Objects options in wireshark to export all the files that are accessed via http.

Most of the files seem to be certificate related, but somewhere in middle we can see an external IP address(194.61.24[.]102) visiting a simple fileshare for downloading a file named coreupdater[.]exe.

Exporting the file and searching the hash on Virus Total, we can see that this file is a malicious file.

As you can see from the virustotal, 59 out of 71 showed this file as a malicious file. And this file is part of meterpreter environment and is capable of Process Injection.

Now the file that was downloaded into the system(located on 10.42.85[.]10) is malicious, the IP address from which this file downloaded is also a malicious IP(194.61.24[.]102).

The relations tab from the virustotal, showed us that this file has contacted 4 other IPs, which may or may not be malicious.

To confirm which IP this coreupdater[.]exe contacted to, we may have to check the memory image given in the evidence files.

DC01 - Memory Image Analysis

We shall be using the memory image from DC01 (Domain Controller) system.

To analyze a memory dump, we can use Volatility.

Examining Process List

Let us check the process list that are running during the application was running from the memory dump.

PS > python.exe vol.py --plugins=D:\Tools\volatility-plugins\ -f .\citadeldc01.mem --profile=Win2012R2x64_18340 pslist

As you can see in the above image, the executable coreupdater[.]exe got exitted or stopped running at 2020-09-19 03:56:52.

Examining Network connections

Memory is one of the best place to check the network connections from any process. Lets use netscan plugin to find the Established or Listening.

As you can see in the above image, the coreupdater[.]exe has established a connection to an IP address (203.78.103[.]109).

Finding malicious injected process

From the virustotal analysis result, we can see that this malicious file is part of Metasploit Framework. It has the capability for Process Injection. So we can make use of malfind plugin to find any process injection.

You can add a -D flag to the command and we will get all the process that has the protection READ_EXECUTE_WRITECOPY. We can then pass it to clamscan or upload it to virustotal to find it has some malicious code injected to it.

As you can see in the above image, the our process named spoolsv.exe is malicious with the same Meterpreter. So now lets use FLOSS and try to get the obfuscated strings.

As you can see in the above image, we can see a tcp connection to out foreign IP (203.78.103[.]109), which we have seen from the netstat output.

From this we can say that the malicious file has established a connection and maybe has exfiltrated some files to that IP address.

Okay now let’s see what changes were made in the system when this malicious binary got into the system. Let’s analyze the DC01 disk image for this info.

DC01 - Disk Image analysis

During our network traffic analysis, we saw some RDP related network traffic. So lets check event logs related to RDP.

Analyzing RDP logs

To find all the RDP related activities, we can check Event IDs 4624, 4625 for Successful and Failed Logon on to the system.

4625-Failed Logons

As you can see in the above image, There are a lot of Failed logons from a Remote Host name ‘Kali‘ to the target username Administrator.

The first failed logon detected at 2020-09-19 03:21:25 and the last failed logon detected at 2020-09-19 03:21:46.

After a few failed logons, there is a successful logon (Logon Type 3) to the DC01 workstation. And after a few minutes, there is a 4624, Logon Type 3.

The sucessful logon for DC01 is at 2020-09-19 03:21:46 and the successful logon for Desktop is at 2020-09-19 03:28:21.

4624-Successful Logon

After this successful logon, attacker visited a file server hosted on a foreign IP (194.61.24[.]102) and downloaded - coreupdater.exe.

coreupdater.exe Download

As an evidence that this malicious file has been downloaded, we can verify it from $MFT and UsnJrnl.$J.

Malicious file creation and deletion

MFT:
MFT-coreupdater.exe

UsnJrnl.$J:
UsnJrnl-$J-coreupdater.exe

As this is a malicious executable which has the tendency to exfiltrate data from the system, so let’s check for any archive files that were created after this malicious file got created.

Data Exfiltration

From UsnJrnl.$J, got these ZIP files created and deleted from DC01 and Desktop systems:

DC01:

Desktop:

Every malicious binary, wants to stay in the system after exfiltrated the files.

Persistance

So let’s check some common persistence techniques like Autoruns and Service installs.

Autoruns (HKLM\SYSTEM\Microsoft\Windows\CurrentVersion\Run):
Autoruns

Service Install from Registry:
Services

Service Install from Event log (Event ID: 7045):
Service Install - 7045

Service Install - 7045

Autorun analysis

In the autoruns screenshot we can see that, the command is retreving some info from other registry keys. So by navigating to those registry keys, found an encoded base64 string.

autorun analysis

Decoding this base64 string, we get a powershell script.

Base64 Decode

From the decoded base64 command, it seems like the powershell script is trying to create a new memory stream object and injecting an another base64 command present in it.

By decoding the other base64 command, found an another powershell script compressed in a GunZIP file. By extracting this new powershell script, it seems like the script is trying to do Process Injection.

Autorun Analysis

A better view of the powershell script:

We can see GetProcAddress being used. A kernel32.dll is being used to free up memory addresses and creating a thread into the injected process. The base64 string that we are see in the code might be a shellcode which will be injected to a process. AFAIK, These GetProcAddress, VirtualAloc, CreateThread are some of the functions used to inject a process.

Communication between malicious IPs

There seems to be some data that has been send or received between the malicous IPs.

After the analysis of these the found malicious IP addresses, found the following:

Coreupdater.exe Download:
malicousFileDownload

Data Exfiltration:

With this analysis, I guess we have got answers to all questions asked on the author’s webpage.

Whether a Malicious File moved to different location?

As malicious file might have been downloaded somewhere and may have moved to an other location, So after analysing IE WebcacheV01.dat, found the URL accessed to download and after retreiving the Response headers, got the location of where the file was downloaded.

WebCacheV01.dat:
WebCacheV01.dat

Decoded Response headers:
Decoded Response Headers

As we can see in the above image, the file was originally downloaded to users download directory and as per MFT we can see that the file is in System32 directory.

It seems we may have got all the answers to the questions asked on the website, let’s answer them one by one.

Questions

  1. What’s the Operating System of the Server?

    • Windows Server 2012 R2
  2. What’s the Operating System of the Desktop?

    • Windows 10
  3. What was the local time of the Server?

    • Pacific Standard Time (UTC -7)
  4. Was there a breach?

    • Yes
  5. What was the initial entry vector (how did they get in)?

    • RDP Bruteforcing, as we have seen a lot of 4625 failed logon on the endpoint.
  6. Was malware used? If so what was it? If there was malware answer the following:

    1. What process was malicious?
      • coreupdater.exe
    2. Identify the IP Address that delivered the payload.
      • 194.61.24[.]102
    3. What IP Address is the malware calling to?
      • 203.78.103.109
    4. Where is this malware on disk?
      • C:\Windows\System32
    5. When did it first appear?
      • As per MFT the file appeared in the system on 2020-09-19 02:24:12.
    6. Did someone move it?
      • Yes, Downloads directory to System32 directory.
    7. What were the capabilities of this malware?
      • Coreupdater uses meterpreter/metasploit and is capable of process injection
    8. Is this malware easily obtained?
      • Yes, can be obtained from meterpreter.
    9. Was this malware installed with persistence on any machine?
      1. When?
        • Service Install: 2020-09-19 02:27:49
      2. Where?
        • Service Install and Autoruns
  7. What malicious IP Addresses were involved?

    • 194.61.24.102 and 203.78.103.109
    1. Were any IP Addresses from known adversary infrastructure?
      • Yes, One IP is related to RDP bruteforce and regarding another may require additional analysis.
    2. Are these pieces of adversary infrastructure involved in other attacks around the time of the attack?
      • Yes
  8. Did the attacker access any other systems?

    1. How?
      • The Desktop machine. DESKTOP-SDN1RPT was accessed using RDP from DC01.
    2. When?
      • RDP from DC01 System accessed DESKTOP-SDN1RPT. Started at 2020-09-19 02:28:21.
    3. Did the attacker steal or access any data?
      1. When?
        • 2020-09-19 02:32:39
  9. What was the network layout of the victim network?

    • DC01 located at 10.42.85[.]10 and Desktop located at 10.42.85[.]115. So they maybe hosted on 10.42.85.0/24
  10. What architecture changes should be made immediately?

    • Direct connection to RDP for DC01 should be removed/turned off. And RDP should be behind VPN or a trusted network.
  11. Did the attacker steal the Szechuan sauce? If so, what time?

    • Yes, Last Access: 2020-09-19 02:32:21 UTC
  12. Did the attacker steal or access any other sensitive files? If so, what times?

    • Secret.zip and loot.zip files have been created and deleted. So they have been stolen from the system.
  13. Finally, when was the last known contact with the adversary?

    • These are times when an user initiated logoff: 2020-09-19 03:22:20, 2020-09-19 03:52:46, 2020-09-19 03:57:40 (after the initial entry). But as per the logs, the attacker still interacting with the system.

Tools used

Below are some of the tools used for solving the challenge: (PS: All are open source or available for free)

If you have any queries or feedback reach out to me on Twitter / LinkedIn.