FCSC2023 - Ransomémoire
This challenge of the FCSC in the forensic category was divided into 4 parts. Looking back, this was the hardest one I found in this category. Firstly, it was necessary to retrieve fairly basic information about the system from a memory dump. Then, we had to find a deleted file and decrypt it by reversing the code of a malicious executable. Next, we tried to recover information about C2 Meterpreter communications. Finally, we had to find the connection informations of the C2.
SHA256(
fcsc.7z) =754cb093af343356827d650270f9faa56cc4c44f44243ea08590edb1bc270b5e
Ransomémoire 0/3 - Pour commencer
Description
You are about to analyze a memory dump and you note down some information about the machine before diving into the analysis:
- username,
- machine name,
- browser used.
The flag is in the format FCSC{<username>:<machine name>:<browser name>} where :
<username>is the name of the user who uses the machine,<machine name>is the name of the analyzed machine, and<browser name>is the name of the browser currently running.
Resolution
Since this is a Windows memory dump, I immediately used Volweb to help me more easily observe the information in the rest of the challenge. While the analysis was running, I performed the actions manually.
To discover the name of the browser currently running, we use the windows.pslist module from volatility3, which allows us to find Brave as browser.
|
|
We can retreive the username of the last user logged into the system using HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\LastUsedUsername as registry key or HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\LastLoggedOnUser for the last logged on SAM user. However, neither of these could be retrieved using volatility. We searched the user who have used the system by listing the HKU hives present in C:\Users\<Username>\ntuser.dat. This yields the username Admin
|
|
Finally, to retrieve the name of the machine, there is the HKLM\SYSTEM\CurrentControlSet\Control\ComputerName key, but once again, this returns nothing. Knowing that computer names by default start with DESKTOP- under Windows, a good old strings/grep works perfectly. A smarter way would have been to grep on COMPUTERNAME.
|
|
Update : It seems that using
ControlSet001\Control\ComputerName\ComputerNameyou can retrieve the computer name with volatility.
Flag
FCSC{Admin:DESKTOP-PI234GP:Brave}
Ransomémoire 1/3 - Mon précieux
Description
You were looking at your beautiful cat pictures when suddenly, your super secret file on your desktop changed its extension and became unreadable…
You took a memory dump to understand what happened, in order to recover this precious file.
Resolution
Looking at files on the desktop in the memory dump, we don’t have much information except only th (9).webp which contains nothing when dumped.
Analyzing the files present on the disk, it is impossible to find a trace of the $USNJrnl file, which contains NTFS transactions and therefore probably the name of the encrypted file. We turn to the $MFT with the windows.mftscan module of volatility, unfortunately it does not display the path of the files. It is therefore impossible to sort by hand.
|
|
We try to dump the tree $MFT files still in the memory dump to analyze them. Once again, a failure because the extraction must not be perfect with volatility, indeed it is impossible to open the file in MFT Explorer and parsing with MFTECmd does not work too.
We can try to see if it is possible to recover information with Brave history about the user activity.
After dumping the file, we open the sqlite3 database with SQLiteBrowser. The downloads table indicates that there were 10 downloaded images.
Going into the downloads_url_chains table, we find the download URLs, which confirms that they are indeed pictures of cats.
In the downloads table, the start_time column is not in the classic Unix epoch format. To convert this time, we will use a customized SQL query based on a question asked on community.brave.com.
|
|
We see that the 10 images were downloaded between 5:22 pm and 5:24 pm, but this does not help us any further in finding the encrypted file. So, we go back to the forensic basic strings/grep.
|
|
We observe two files chats.odt and flag.fcsc, as well as two lines stdapi_fs_file.
Searching for this character string on Internet, we find that it is a class implemented by Meterpreter.
By analyzing the $MFT again, searching for these 2 files, we understand that the file flag.fcsc has been encrypted into flag.fcsc.enc.
|
|
We create a yara rule to find in which process we can find traces of these files or Meterpreter.
|
|
The windows.vadyarascan module is used to scan processes in the memory dump looking for our strings.
|
|
|
|
Analyzing the number of occurrences of each string per process, we notice that the stdapi_ is the most present one in the process VBoxService.exe (6424). Moreover, with the windows.malfind module, this same process comes up as an alert because it has a memory region in RWX. We see that the beginning starts with fc 48 89, which is typical for Meterpreter shellcode. If you have done malware development, you can also recognize the instruction mov rdx, qword ptr gs:[rdx + 0x60] with the gs segment register which is used to access the TEB on Windows. Then, the TEB pointer is dereferences to get the pointer to the PEB, etc. The VBoxTray process appears to be infected by a Meterpreter shellcode.
Furthermore, we can observe that chats string is present 869 times in process 4160, which is normal since it is the Brave process, the same one that was probably used to search for cat images.
For fcsc string, we can see that there are 54 occurrences in process 7684 and 29 in 3928. These processes are actually SearchProtocolHost.exe and explorer.exe, respectively, which seems logical since the former is related to file indexing and the latter to file navigation. However, the 14 occurrences for process 5540 is suspicious because they come from svchost.exe. Upon inspecting the command line of this process, we see that the file is being executed from C:\Windows\Temp instead of C:\Windows\System32, and with no arguments as it should.
The mistake here was forgetting to check the command line of all processes with
windows.cmdlineat the beginning, which would have allowed us to reach this step more quickly
We could also identify the fact that this was not the same executable as the other svchost processes because the base address is different.
Then, we dump the process and analyze it in IDA.
|
|
The problem is that upon opening this executable, it doesn’t seem to be complete, as we can’t find anything at byte_405125.
There are 2 options available to you at this point.
The first is to use volatility2, but since we don’t want to search for a profile, we’ll go directly to the second solution MemProcFS.
We run the command MemProcFS.exe -device fcsc.dmp -forensic 1, which will simulate a file system from the memory image. We can easily retrieve the executable associated with the svchost process.
When opening this executable, we have a complete PE this time.
In the main function, we will generate a key for each file on the desktop. Then encrypt those ending with .fcsc.
The key generation function will write a random 100 bytes key to a file C:\Windows\Temp\MsCmdRun%d.log (%d being incremented for each file present on the desktop).
The encryption function will read the first 100 bytes of the file, then XOR the initial text, the key, and the key ID. The result will be rewritten to the file, which will then be moved to <filename>.enc.
Since, the file fcsc.flag.enc is small enough (inferior to 1024 bytes), his content must be in the resident data of the $MFT. Although the file extracted with volatility3 seems corrupted, it is possible to open it in 010 Editor which has a plugin to parse the $MFT. By searching for fcsc.flag.enc, we recover the 71 bytes of the file in the resident data.
fcsc.flag.enc : 3b6517196403719fdd1a30ec37ba83c91bb044c98d054588ff4140d632e561095ff23207446a8d05c7fe822f22769a0832287aadff90c84d96ca99541c2c58f77a8be5c55d515a
In the memory dump, volatility only finds 2 files, whose keys do not seem to work.
C:\Windows\Temp\MsCmdRun19.logC:\Windows\Temp\MsCmdRun20.log
We can continue to use the $MFT to recover the other files (but some are missing 0, 1, and 5). Alternatively, with MemProcFS, it is possible to navigate as a file system to find them.
We can test each key one by one in CyberChef as there are few keys. We find that the correct key corresponds to the file MsCmdRun14.log.
We could guess it because there were 14 files on the desktop.
Flag
FCSC{776f25d811bf9ac262143d0f1fa97c382f7b5972121b37d0361c7d7ad1b27079}
Ransomémoire 2/3 - Début d’investigation
Description
You were able to recover your precious file. You are now investigating the origin of this encryption.
The flag is in the format FCSC{<pid>:<protocol>:<port>} where :
<pid>is the ID of the process that deposited and executed the encryptor, and<protocol>and<port>are the parameters of the connection with the C2.
Resolution
In this part, we are trying to first find the PID of the process that executed svchost.exe (5540), which is 6424 (VBoxTray.exe) that we have already seen earlier as it contains a Meterpreter shellcode.
We will dump the memory section that contains the shellcode using the windows.malfind module.
|
|
By searching for the constants in the shellcode, we can think that it is the assembly code of migrate.asm.
However, upon closer inspection, we can see that in our code, the line mov rdi, rax is actually an xchg rax, rdi.
This means that it corresponds to the assembly code present in migrate_tcp_x64.rb.
All that’s left is to find the port, for which we will use string/grep.
|
|
Flag
FCSC{6424:tcp:8080}
Ransomémoire 3/3 - Doppelgänger
Description
You don’t understand how the agent you found in Ransomémoire 2/3 - Début d'investigation ended up on the machine. You suspect the presence of a sleeping agent, hiding in memory…
The flag is in the format FCSC{<pid>:<ip>:<port>} where :
<pid>is the ID of the malicious process and<ip>and<port>are the parameters of the connection with the C2.
Resolution
First, we look into the process doppelgänging technique, which is a process injection technique. We learn from MITRE that this technique involves launching a legitimate executable and then replacing it with a malicious one.
The base address of the process will therefore be different from other processes coming from the same executable. Looking at the NetGraph of VolWeb, we see that there are very few connections, and most public IPs can quickly be excluded as legitimate in sandbox reports.
We will focus on the Brave processes because that would be the best place to hide a C2 stream.
Checking the base addresses, we discover that the Brave 6808 process is the only process with a base address at 15335424 instead of 140695088398336 for all other processes.
We will use strings to see if we can get more information.
|
|
These parameters look like a C2 configuration. Searching for main.psk in grep.app, we find that it is the agent for the C2 Merlin.
Flag
FCSC{6808:192.168.1.106:443}