Ransomémoire 1/3 - Mon précieux
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.
$ python3 ~/ctf/forensic/volatility3/vol.py -f fcsc.dmp windows.mftscan
Offset Record Type Record Number Link Count MFT Type Permissions Attribute Type Created Modified Updated Accessed Filename
0x81867fcb8450 FILE 242429 65535 File Archive FILE_NAME 2023-04-04 18:11:47.000000 2023-04-04 18:11:47.000000 2023-04-04 18:11:47.000000 2023-04-04 18:11:47.000000 SPACED~1.SYS
* 0x81867fcb84c8 FILE 242429 65535 File Archive FILE_NAME 2023-04-04 18:11:47.000000 2023-04-04 18:11:47.000000 2023-04-04 18:11:47.000000 2023-04-04 18:11:47.000000 spacedump.sys
0x81867fcb8850 FILE 242430 2 File N/A STANDARD_INFORMATION 2023-04-04 18:03:39.000000 2023-04-04 18:03:29.000000 2023-04-04 18:03:33.000000 2023-04-04 18:03:39.000000 N/A
* 0x81867fcb88b0 FILE 242430 2 File Archive FILE_NAME 2023-04-04 18:03:39.000000 2023-04-04 18:03:39.000000 2023-04-04 18:03:39.000000 2023-04-04 18:03:39.000000 MSFT_M~1.WPR
* 0x81867fcb8928 FILE 242430 2 File Archive FILE_NAME 2023-04-04 18:03:39.000000 2023-04-04 18:03:39.000000 2023-04-04 18:03:39.000000 2023-04-04 18:03:39.000000 MSFT_MpPerformanceRecording.wprp
* 0x81867fcb8c50 FILE 242431 0 File Archive FILE_NAME 2023-04-04 17:48:08.000000 2023-04-04 17:48:08.000000 2023-04-04 17:48:08.000000 2023-04-04 17:48:08.000000 spacedump.sys
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.
SELECT d.current_path, du.url , datetime(d.start_time / 1000000 + (strftime('%s', '1601-01-01')), 'unixepoch', 'localtime') AS start_time
FROM downloads d
LEFT JOIN downloads_url_chains du on d.id = du.id
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.
$ strings fcsc.dmp | grep -i 'Users\\Admin\\Desktop -C 5
[...]
3stdapi_fs_file
C:\Users\Admin\Desktop\chats.odt
47356039989504321872891306727343
61376899975370051322534324446423
3stdapi_fs_file
C:\Users\Admin\Desktop\flag.fcsc
[...]
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.
Offset Record Type Record Number Link Count MFT Type Permissions Attribute Type Created Modified Updated Accessed Filename
0xcc04be15b450 FILE 102253 1 File N/A STANDARD_INFORMATION 2023-04-17 17:23:45.000000 2023-04-17 17:23:46.000000 2023-04-17 17:23:46.000000 2023-04-17 17:23:48.000000 N/A
* 0xcc04be15b4b0 FILE 102253 1 File Archive FILE_NAME 2023-04-17 17:23:45.000000 2023-04-17 17:23:45.000000 2023-04-17 17:23:45.000000 2023-04-17 17:23:45.000000 chats.odt
0xcc04cd429450 FILE 96165 2 File N/A STANDARD_INFORMATION 2023-04-17 17:23:45.000000 2023-04-17 17:23:50.000000 2023-04-17 17:23:50.000000 2023-04-17 17:23:50.000000 N/A
* 0xcc04cd4294b0 FILE 96165 2 File Archive FILE_NAME 2023-04-17 17:23:45.000000 2023-04-17 17:23:50.000000 2023-04-17 17:23:50.000000 2023-04-17 17:23:50.000000 FLAGFC~1.ENC
* 0xcc04cd429528 FILE 96165 2 File Archive FILE_NAME 2023-04-17 17:23:45.000000 2023-04-17 17:23:50.000000 2023-04-17 17:23:50.000000 2023-04-17 17:23:50.000000 flag.fcsc.enc
We create a yara rule to find in which process we can find traces of these files or Meterpreter.
rule flag_plz
{
strings:
$chats = "chats" ascii wide
$fcsc = "fcsc" ascii wide
$meterpreter = "stdapi_" ascii wide
condition:
any of them
}
The windows.vadyarascan module is used to scan processes in the memory dump looking for our strings.
$ python3 vol.py -f fcsc.dmp windows.vadyarascan --yara-file ransomemoire.yara
Volatility 3 Framework 2.4.2
Progress: 100.00 PDB scanning finished
Offset PID Rule Component Value
0x24d2df4d026 108 flag_plz $chats 63 00 68 00 61 00 74 00 73 00
0x24d2df4d42e 108 flag_plz $fcsc 66 00 63 00 73 0 63 00
0x24d2fbf911c 108 flag_plz $chats 63 68 61 74 73
0x255ad8dce08 1484 flag_plz $chats 63 68 61 74 73
0xdf57e2 3928 flag_plz $fcsc 66 00 63 00 73 00 63 00
0x91b6ec6 3928 flag_plz $fcsc 66 63 73 63
0x91b7f52 3928 flag_plz $chats 63 00 68 00 61 00 74 00 73 00
0xc4a189e 3928 flag_plz $chats 63 68 61 74 73
0xb7335f0ac8 4568 flag_plz $chats 63 00 68 00 61 00 74 00 73 00
0x1bdaa63eac2 4568 flag_plz $fcsc 66 00 63 00 73 00 63 00
0x20dc71cf428 5720 flag_plz $chats 63 00 68 00 61 00 74 00 73 00
0x22d80f4ca9c 6424 flag_plz $fcsc 66 63 73 63
0x22d80f4d007 6424 flag_plz $chats 63 68 61 74 73
0x22d828ff990 6424 flag_plz $meterpreter 73 74 64 61 70 69 5f
0x2171ff5fc26 7704 flag_plz $chats 63 00 68 00 61 00 74 00 73 00
0x217358900f1 7704 flag_plz $meterpreter 73 74 64 61 70 69 5f
0x2174c7df08d 7704 flag_plz $chats 63 68 61 74 73
0x1929bb175f8 620 flag_plz $chats 63 00 68 00 61 00 74 00 73 00
0x1929dfa1e98 620 flag_plz $chats 63 68 61 74 73
0x25c0c8f5fb7 6936 flag_plz $fcsc 66 63 73 63
0x402054 5540 flag_plz $fcsc 66 00 63 00 73 00 63 00
0x1c7940e0036 4072 flag_plz $chats 63 68 61 74 73
0x5d50008d8364 4072 flag_plz $chats 63 00 68 00 61 00 74 00 73 00
0x169835c12c6 4160 flag_plz $chats 63 00 68 00 61 00 74 00 73 00
0x2610010dfc5 4160 flag_plz $chats 63 68 61 74 73
0xe1eb1faec6 7684 flag_plz $chats 63 00 68 00 61 00 74 00 73 00
0x258f06d6c66 7684 flag_plz $fcsc 66 63 73 63
0x258f06d6ca3 7684 flag_plz $fcsc 66 00 63 00 73 00 63 00
0x258f06fe0b1 7684 flag_plz $chats 63 68 61 74 73
$ cat ransomemoire_result | awk '{print $2" "$4}' | sort -n | uniq -c
[...]
5 108 $chats
2 108 $fcsc
18 620 $chats
3 1484 $chats
14 3928 $chats
29 3928 $fcsc
6 4072 $chats
869 4160 $chats
14 4568 $chats
12 4568 $fcsc
2 5124 $chats
14 5540 $fcsc
32 5720 $chats
5 6424 $chats
2 6424 $fcsc
6 6424 $meterpreter
2 6936 $fcsc
6 7684 $chats
54 7684 $fcsc
3 7704 $chats
1 7704 $meterpreter
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.
$ python3 vol.py -o svchost -f fcsc.dmp windows.dumpfiles --pid 5540
$ file svchost/file.0x818687285610.0x818688495050./RansomemoireectionObject.svchost.exe.img
[...] PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows, 5 sections
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}