FCSC 2023 - Ransomémoire - Forensics

11 minute read

Here is the write-up of “Ransomémoire” series of forensic challenges of the FCSC 2023 which involves investigation of a Windows 10 memory dump. The series is divided in four parts.

Ransomémoire 0/4 - Pour commencer | Description

You prepare to analyze a memory capture and note some information about the machine before diving into the analysis:
    machine name,
    browser used.

The flag is in FCSC{<username>:<machine name>:<browser name>} format where:
    <username> is the name of the user using the machine,
    <machine name> is the name of the machine being analyzed, and
    <browser name> is the name of the running browser.

For example: FCSC{toto:Computer-of-jojo:Firefox}.

Author : haxom

This is the warm-up phase, we just need to use volatility with classic commands on the provided memory dump to extract the three information.

Note : I used volatility2 (vol.py) and 3(vol3.py) to resolve the challenge, the profile for volatility2 is Win10x64_19041, obtained with imageinfo plugin.


Just a quick filescan and a grep to see the Users.

$ vol.py -f ./fcsc.dmp  --profile=Win10x64_19041 filescan > out/vol2/filescan.txt
$ cat out/vol2/filescan.txt| grep Desktop
0x0000818684ee8160     12      0 R--r-d \Device\HarddiskVolume2\Windows\System32\NPSMDesktopProvider.dll
0x0000818686c595a0      3      0 R--r-d \Device\HarddiskVolume2\Windows\System32\DispBroker.Desktop.dll
0x0000818687ecd680      9      0 R--r-d \Device\HarddiskVolume2\Windows\System32\DdcComImplementationsDesktop.dll
0x0000818687ed5ce0     14      0 R--r-d \Device\HarddiskVolume2\Windows\System32\SettingsEnvironment.Desktop.dll
0x0000818687ee9ec0     11      0 R--r-d \Device\HarddiskVolume2\Windows\System32\Windows.Cortana.Desktop.dll
0x0000818689b077d0     18      0 RW-rwd \Device\HarddiskVolume2\Users\Admin\Desktop\th (9).webp
0x0000818689b0d270     16      0 R--rwd \Device\HarddiskVolume2\Users\Public\Desktop\desktop.ini
0x0000818689b87700     16      0 R--rw- \Device\HarddiskVolume2\Users\Admin\Desktop\Microsoft Edge.lnk
0x0000818689b8b260     16      0 R--rwd \Device\HarddiskVolume2\Users\Admin\Desktop\desktop.ini
0x0000818689b8f590  32768      1 R--rwd \Device\HarddiskVolume2\Users\Admin\Desktop
0x0000818689b9cba0  32768      1 R--rwd \Device\HarddiskVolume2\Users\Public\Desktop
0x0000818689b9d1e0  32766      1 R--rwd \Device\HarddiskVolume2\Users\Admin\Desktop
0x0000818689b9e4a0  32768      1 R--rwd \Device\HarddiskVolume2\Users\Admin\Desktop
0x0000818689b9fda0  32768      1 R--rwd \Device\HarddiskVolume2\Users\Public\Desktop

So the username is Admin.

Computer name

With the printkey plugin, we can print the value of the registry key ComputerName.

$ vol3.py -f ./fcsc.dmp windows.registry.printkey.PrintKey --key "ControlSet001\Control\ComputerName\ComputerName"
Volatility 3 Framework 2.4.0
Progress:  100.00               PDB scanning finished
Last Write Time Hive Offset     Type    Key     Name    Data    Volatile

-       0xe306c7864000  Key     ?\ControlSet001\Control\ComputerName\ComputerName       -               -
2023-04-04 17:24:39.000000      0xe306c7889000  REG_SZ  \REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ComputerName        (Default)       "mnmsrvc"       False
2023-04-04 17:24:39.000000      0xe306c7889000  REG_SZ  \REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ComputerName        ComputerName    "DESKTOP-PI234GP"       False

The computer name is DESKTOP-PI234GP.


We list the processes and brave browser is running :

$ vol.py -f fcsc.dmp --profile=Win10x64_19041 pslist > out/vol2/pslist.txt
$ cat out/vol2/pslist.txt
➜  dump-analysis cat out/vol2/pslist.txt
         Name                    PID   PPID   Thds     Hnds   Sess  Wow64 Start                          Exit
-------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------
brave.exe              4072   3928     31        0      1      0 2023-04-17 17:21:31 UTC+0000
brave.exe              5064   4072      8        0      1      0 2023-04-17 17:21:39 UTC+0000
brave.exe              3952   4072     14        0      1      0 2023-04-17 17:21:44 UTC+0000
brave.exe              4060   4072     12        0      1      0 2023-04-17 17:21:44 UTC+0000
brave.exe              2844   4072      7        0      1      0 2023-04-17 17:21:44 UTC+0000
brave.exe              5500   4072     15        0      1      0 2023-04-17 17:21:46 UTC+0000

The browser is brave.

We have the flag for the part 0 : FCSC{Admin:DESKTOP-PI234GP:Brave}

Ransomémoire 3/3 - Doppelgänger | Description

You don't understand how the agent you found in Ransomemory 2/3 - Beginning of Investigation could be on the machine (Note: it is not necessary to have solved this challenge to solve Ransomemory 3/3 - Doppelgänger). You suspect the presence of a sleeping agent, which hides in memory...

The flag is in FCSC{<pid>:<ip>:<port>} format where:
    <pid> is the ID of the malicious process and
    <ip> and <port> are the parameters of the connection with the C2.

Author : haxom

I don’t write the 1/3 and 2/3 solutions now because they are more complex and during the competition I solved the 3/3 before the two remaining (1/3 and 2/3).

First, the title of the challenge : “Doppelgänger”, puts us on the track that we need to find a process which looks similar to another but which isn’t the same. If we link this information with the part 0/3, we could think about the browser, brave, which can be backdoored, but we are not sure.

I started to use the common volatility plugins related to processes and network, because we need to find an IP/port and a PID :

  • psscan
  • pstree
  • psxview
  • netscan
  • netstat

With the netstat plugin of vol3, I found this :

0x8186882a7a20  TCPv4       49836   443     CLOSE_WAIT      6808    brave.exe       2023-04-17 17:16:51.000000

A brave process communicates with an IP which seems to be related to a local network of the machine. ( and port 443)

I also used a tool called bulkextractor on the memory dump to extract many information about it.

$ ./bulk_extractor ./fcsc.dmp -o out_bulk
$ ls out_bulk
aes_keys.txt              domain.txt                  ether.txt           httplogs.txt         ntfslogfile_carved.txt  rar.txt            tcp.txt                   url_microsoft-live.txt  windirs.txt       zip.txt
alerts.txt                elf.txt                     evtx_carved.txt     ip_histogram.txt     ntfsmft_carved.txt      report.xml         telephone_histogram.txt   url_searches.txt        winlnk.txt
ccn_histogram.txt         email_domain_histogram.txt  exif.txt            ip.txt               ntfsusn_carved          rfc822.txt         telephone.txt             url_services.txt        winpe_carved
ccn_track2_histogram.txt  email_histogram.txt         facebook.txt        jpeg_carved.txt      ntfsusn_carved.txt      sin.txt            unrar_carved.txt          url.txt                 winpe_carved.txt
ccn_track2.txt            email.txt                   find_histogram.txt  json.txt             packets.pcap            sqlite_carved      url_facebook-address.txt  utmp_carved             winpe.txt
ccn.txt                   ether_histogram_1.txt       find.txt            kml_carved.txt       pii_teamviewer.txt      sqlite_carved.txt  url_facebook-id.txt       utmp_carved.txt         winprefetch.txt
domain_histogram.txt      ether_histogram.txt         gps.txt             ntfsindx_carved.txt  pii.txt                 tcp_histogram.txt  url_histogram.txt         vcard.txt               zip

In the rfc822.txt file, I found this information:

So there are requests on the mal.server.notlocal domain, looks really suspicous.

Lets strings / strings -el the dump and grump for it.

strings -el is to extact UTF-16 strings

strings fcsc.dmp > strings.txt
strings -el fcsc.dmp > -el strings.txt

And grep it :

-X \"main.protocol=https\" -X
-X \"main.host=mal.server.notlocal\" -X \"main.psk=WyGRb98LKLQfZiO32\" -X \"main.sleep=30s\" -X \"main.proxy=\" -X \"main.useragent=Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/5
37.36\" -X \"main.headers=\" -X \"main.skew=3000\" -X \"main.padding=4096\" -X \"main.killdate=0\" -X \"main.maxretry=7\" -X \"main.parrot=\" -H=windowsgui -buildid="

This line looks like a Golang compilation command and we find the previous IP that we found before : in the main.url field. There is also a sleep field, that’s obviously a C2 beacon !

Let’s use procdump with the PID to dump the brave executable and analyze it.

$ vol.py -f fcsc.dmp --profile=Win10x64_19041 procdump --pid=6808 --dump-dir=./proc_dump_6808

Quick upload on virus total confirms it : https://www.virustotal.com/gui/file/9be810fedb8378987a9170ed8a261ef714120b4a3f50772d906d5928a715e9fc

That’s the malware which fake brave with his name.

Flag : FCSC{6808:}

Ransomémoire 1/3 - Mon précieux | Description

You were looking at your beautiful cat pictures when, lo and behold, your super secret file on your desktop changes extension and becomes unreadable...

You do a memory capture to understand what happened, in order to recover this precious file.

Author : haxom

So now we need to recover an encrypted file which we don’t know the name, we only know that this file was on the user Desktop.

The filescan plugin didn’t find anything, so the file was removed. A quick grep on strings with Desktop keyword allows us to find the two files.

$ cat strings.txt | grep -i '\\Desktop'

The file which contains the cats pictures is chats.odt, and the file that we need to recover is flag.fcsc.

Right after, I used the mftparser plugin of volatility which dump the MFT to see if the flag.fcsc content was not there.

$ vol.py -f ./fcsc.dmp  --profile=Win10x64_19041 mftparser > out/vol2/mftparser
$  cat out/vol2/mftparser| grep -A 10 "flag.fcsc"
2023-04-17 17:23:45 UTC+0000 2023-04-17 17:23:50 UTC+0000   2023-04-17 17:23:50 UTC+0000   2023-04-17 17:23:50 UTC+0000   Users\Admin\Desktop\flag.fcsc.enc

0000000000: 3b 65 17 19 64 03 71 9f dd 1a 30 ec 37 ba 83 c9   ;e..d.q...0.7...
0000000010: 1b b0 44 c9 8d 05 45 88 ff 41 40 d6 32 e5 61 09   ..D...E..A@.2.a.
0000000020: 5f f2 32 07 44 6a 8d 05 c7 fe 82 2f 22 76 9a 08   _.2.Dj...../"v..
0000000030: 32 28 7a ad ff 90 c8 4d 96 ca 99 54 1c 2c 58 f7   2(z....M...T.,X.
0000000040: 7a 8b e5 c5 5d 51 5a                              z...]QZ


Here it is, but it seems to be encrypted, now our goal is to find where it can come from.

The challenging step starts. My first thought when reading the challenge description was that the encryption of the flag.fcsc file was linked to the cats document. We found that this is an ODT file, so It’s possible that there is a malicious Macro into it which encrypted the flag.

I tried many things to dump the chats.odt content, binwalk, foremost, strings to retrieve the content. I even retrieved the text content with strings and grep :

Album photo de chats
(aucun flag ici, juste des photos de chats trop mignons)

So I moved away from this idea. I started to try to recover the file not encrypted directly.

I used the plugin memdump to dump the memory of specific processes. There were some interesting processes name like “Process Hacker” but gives nothing fascinating.

I made a timeline with this little trick which uses volatility and mactime:

$ vol.py -f fcsc.dmp --profile=Win10x64_19041 timeliner --output=body > time.txt
$ vol.py -f fcsc.dmp --profile=Win10x64_19041 shellbags --output=body >> time.txt
$ vol.py -f fcsc.dmp --profile=Win10x64_19041 mftparser --output=body >> time.txt
$ mactime -b time.txt -d > timeline.csv

Now we have a cool csv which made my libreoffice laggy x).

This was cool, but didn’t help me to find where the encryption come from.

My last try was to use a yara, I didn’t know that, but the power of yara with volatility is that the process PID where the found content is found is written.

So I make two rules, one in UTF-8 and one in UTF-16. The UTF-16 was the good one.

$ vol.py -f fcsc.dmp --profile=Win10x64_19041 yarascan --yara-rules="{66 00 6c 00 61 00 67 00 2e 00 66 00 63 00 73 00 63}"

The string was found on explorer.exe process, not important, but especially on a svchost process !

We could try to dump the process :

$ vol.py -f fcsc.dmp --profile=Win10x64_19041 procdump --pid=5540 --dump-dir=./procdump_5540

Open it on IDA aaaaand :

Bingo we found it :)

Note: With string and grep I had already found a suspicous PATH : C:\Windows\Temp\svchost.exe, it was the malicious svchost.

Here are the two other functions of the binary :

The first function write random data in a file C:\\Windows\\Temp\\MsCmdRun%d.log, %d is changing.

The second function is just xoring the content of all .fcsc files with the random data generated and an index which is the number of time passed in the loop. (There’s a sleep between each iteration).

Now our goal is to recover the good MsCmdRun file to xor it with our flag.fcsc.enc. For the index, we are going to brute force to gain time.

We retrieve the MsCmdRun files with mftparser, but there are many. We need to find the good one. (During the challenge I decided to dump all of them, but It was not a good option).

The timestamp was the way, the MsCmdRun14.log file was created just before the content was modified, as you can see in the screenshot of the csv timeline.

So It was obviously the good one.

We just need to brute force the index and it was 0xe.

Here is the script to decrypt flag.fcsc.enc :

encrypted = open('./flag.fcsc.enc','rb').read()
key = open('./logs_file/MsCmdRun14.log','rb').read()

res = b""
for i in range(len(encrypted)):
    res += chr(encrypted[i] ^ key[i] ^ 0xe).encode() 

$ python3 decrypt.py

We got it, flag : FCSC{776f25d811bf9ac262143d0f1fa97c382f7b5972121b37d0361c7d7ad1b27079}

Ransomémoire 2/3 - Début d’investigation | Description

Phew, you were able to recover your precious file. Now you investigate the origin of this encryption.

The flag is in FCSC{<pid>:<protocol>:<port>} format where:
    <pid> is the ID of the process that dropped and executed the encryptor and
    <protocol> and <port> are the parameters of the connection with C2.
Author : haxom

Last part of the challenge, we need to find the process which executed the malicious svchost executable.

With the pstree plugin we can see this :

... 0xffff81868852e080:VBoxTray.exe                  6424   3928     13      0 2023-04-16 21:47:34 UTC+0000
.... 0xffff818687754080:svchost.exe                  5540   6424      1      0 2023-04-17 17:21:18 UTC+0000

The parent PID of svchost.exe is VBoxTray.exe. If we’re referring to his name, It’s a process link to VirtualBox Guest Additions. We could think that’s not what we search, but we’re going to check in case it’s a malicious process.

Let’s dump it.

$ vol.py -f fcsc.dmp --profile=Win10x64_19041 procdump --pid=6424 --dump-dir=./procdump_6424

Quick check on VT : https://www.virustotal.com/gui/file/58c73998bcd720a9694bb136f3c53fc9dcd1e4b653dcc796364a76b52f23de57

Seems to be legit, but the file has no signature. Let’s use IDA to reverse it quickly.

We can find many GetProcAddress call, really suspicious.

The TEB strcture is retrieved, a common move in malwares to bypass Antivirus and EDRs.

I tried to run it on my VM but It crashes, :/ I tried one or two Sandbox online but get nothing interesting except one or two signatures.

Note: It was a legit VBoxTray, but a shellcode was injected into his memory

So I came back to the memory dump and use the malfind plugin (I had already run it but a result in VBoxTray.exe made me go through other things)

$ cat out/vol2/malfind.txt
Process: VBoxTray.exe Pid: 6424 Address: 0x22d82840000
Flags: PrivateMemory: 1, Protection: 6

0x0000022d82840000  fc 48 89 ce 48 81 ec 00 20 00 00 48 83 e4 f0 e8   .H..H......H....
0x0000022d82840010  cc 00 00 00 41 51 41 50 52 48 31 d2 51 56 65 48   ....AQAPRH1.QVeH
0x0000022d82840020  8b 52 60 48 8b 52 18 48 8b 52 20 48 0f b7 4a 4a   .R`H.R.H.R.H..JJ
0x0000022d82840030  48 8b 72 50 4d 31 c9 48 31 c0 ac 3c 61 7c 02 2c   H.rPM1.H1..<a|.,

0x0000000082840000 fc               CLD
0x0000000082840001 48               DEC EAX
0x0000000082840002 89ce             MOV ESI, ECX
0x0000000082840004 48               DEC EAX
0x0000000082840005 81ec00200000     SUB ESP, 0x2000
0x000000008284000b 48               DEC EAX
0x000000008284000c 83e4f0           AND ESP, -0x10
0x000000008284000f e8cc000000       CALL 0x828400e0
0x0000000082840014 41               INC ECX
0x0000000082840015 51               PUSH ECX
0x0000000082840016 41               INC ECX
0x0000000082840017 50               PUSH EAX
0x0000000082840018 52               PUSH EDX
0x0000000082840019 48               DEC EAX
0x000000008284001a 31d2             XOR EDX, EDX
0x000000008284001c 51               PUSH ECX
0x000000008284001d 56               PUSH ESI
0x000000008284001e 6548             DEC EAX
0x0000000082840020 8b5260           MOV EDX, [EDX+0x60]
0x0000000082840023 48               DEC EAX
0x0000000082840024 8b5218           MOV EDX, [EDX+0x18]
0x0000000082840027 48               DEC EAX
0x0000000082840028 8b5220           MOV EDX, [EDX+0x20]
0x000000008284002b 48               DEC EAX
0x000000008284002c 0fb74a4a         MOVZX ECX, WORD [EDX+0x4a]
0x0000000082840030 48               DEC EAX
0x0000000082840031 8b7250           MOV ESI, [EDX+0x50]
0x0000000082840034 4d               DEC EBP
0x0000000082840035 31c9             XOR ECX, ECX
0x0000000082840037 48               DEC EAX
0x0000000082840038 31c0             XOR EAX, EAX
0x000000008284003a ac               LODSB
0x000000008284003b 3c61             CMP AL, 0x61
0x000000008284003d 7c02             JL 0x82840041
0x000000008284003f 2c               DB 0x2c

There is an RWX section in the VBoxTray.exe process memory. It is probably a shellcode.

Let’s dump it with the plugin.

$ vol3.py -f ./fcsc.dmp windows.malfind.Malfind --pid 6424 --dump

The shellcode seems to be hard to reverse when seeing it in IDA. Let’s just use string / strings -el to find the port and the protocol.

$ strings -el pid.6424.vad.0x22d82840000-0x22d82871fff.dmp | tail

Here it is :) the protocol is tcp and port 8080 ! We have all the information to flag.

Flag : FCSC{6424:tcp:8080}


This challenge was really cool, It allows playing with many different volatility plugins to find what we need. The confusion in process names for brave / svchost and VBoxTray was interesting because it reminds us that even if a process name seems legit, it is not necessarily.