First Impressions
The challenge comes with a ZIP file containing a memory image, raided-challenge-dump-vmem. It is a Kali Linux memory image, as detected by volatility3.
$ volatility3 -f raided-challenge-dump-vmem banners.Banners
Volatility 3 Framework 2.4.2
Progress: 100.00 PDB scanning finished
Offset Banner
0x7144cd0 Linux version 6.1.0-kali9-amd64 (devel@kali.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1kali1 (2023-05-12)
Create a Volatility Profile
To analyze Linux images, Volatility requires a custom profile. This process took ages, as I attempted to create profiles for both Volatility 2 and 3, and both kept returning errors, one error even breaking my VM. However, I'll save you the trouble and provide a gist of what worked.
Volatility 3 requires a symbol table, which can be generated from a DWARF file using a tool called dwarf2json. The symbol table differs depending on the kernel version.
The DWARF file for Kali Linux can be installed the debug symbols using apt. The version number is taken from the banner.
$ sudo apt upgrade
$ sudo apt install linux-image-6.1.0-kali9-amd64-dbg
Then I generated the symbol table with the DWARF file, located in /usr/lib/debug/boot. This may take some time.
$ git clone https://github.com/volatilityfoundation/dwarf2json
$ cd dwarf2json/
$ go build
$ ./dwarf2json linux --elf /lib/debug/boot/vmlinux-6.1.0-kali9-amd64 > linux-image-6.1.0-kali9-amd64.json
Once completed, I moved the table to volatility's symbols directory.
$ sudo mv linux-image-6.1.0-kali9-amd64.json > /opt/volatility3/volatility3/symbols
Initial Analysis
The first thing I checked after setting up the profile was the list of running processes, using the PsAux plugin.
$ volatility3 -f raided-challenge-dump-vmem linux.psaux.PsAux
Volatility 3 Framework 2.4.2
Progress: 100.00 Stacking attempts finished
PID PPID COMM ARGS
1 0 systemd /sbin/init splash
2 0 kthreadd [kthreadd]
3 2 rcu_gp [rcu_gp]
...
1266 1 qterminal /usr/bin/qterminal
1365 1266 zsh /usr/bin/zsh
1398 759 obexd /usr/libexec/bluetooth/obexd
1690 1365 ssh ssh -i /home/l33t/.ssh/id_ed25519 l33t@167.172.12.154
Based on the output, it seems like the user, l33t started a terminal session using qterminal, with zsh as the shell, and logged in to another server via ssh using a private key, id_ed25519.
At this point, my brain was pretty fried, and I was looking for attempts to extract interesting files, not realizing that an interesting file was right in front of my eyes. I followed another rabbit hole extracting SSH session keys, and that didn't lead anywhere.
And finally, it clicked. I checked if the host 167.172.12.154 was actually live, and it was. So all I needed was the private key to access this server.
Extract the SSH Private Key
I'd been used to extracting files using the dump_file plugin from volatility2, and volatility3 doesn't have that plugin.
I sat confused for a while, but soon remembered that SSH private keys start with the phrase -----BEGIN OPENSSH PRIVATE KEY----- which can be easily found through grep.
$ cat raided-challenge-dump-vmem | grep -A 20 -a 'BEGIN OPENSSH PRIVATE KEY'
...
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACDx5+PcHHdCbysQVTdmPbKyd1qZBRe4OEhD0YoBDH2IKgAAAJBE81SyRPNU
sgAAAAtzc2gtZWQyNTUxOQAAACDx5+PcHHdCbysQVTdmPbKyd1qZBRe4OEhD0YoBDH2IKg
AAAEBFmHMBRmsUnpUBeiO91vIYYjICQHypyprNdh9IoONK3fHn49wcd0JvKxBVN2Y9srJ3
WpkFF7g4SEPRigEMfYgqAAAACmwzM3RAaDR4MHIBAgM=
-----END OPENSSH PRIVATE KEY-----
...
I saved the key to a file, changed its permissions, logged in, and got the flag.
$ chmod 600 raided_id_ed25519
$ ssh -i raided_id_ed25519 l33t@167.172.12.154
flag{654e9dc4c424e25423c19c5e64fffb27}
Connection to 167.172.12.154 closed.
Well, that was easier than I thought.
Flag: flag{654e9dc4c424e25423c19c5e64fffb27}
More writeups from NahamCon CTF 2023