Forensic - Reise, Reise - Turbulences 1
MidnightCTF 2023
Catégorie : Forensic
📜Scenario
🔎Solve
First, download the file on your machine
$ ls
ram_dump Debian_4.19.178-amd64_profile.zip
Move the zip profile file into the volatility/plugins/overlays/linux path
Make sure that the profile is register by volatility 2 with this command :
$ vol.py --info | grep Debian
LinuxDebian_4_19_178-amd64-profilex64
When everything is set up correctly, we can start the analysis of the RAM capture
We start as always by listing all current process on the dump to check if something look weird
$ vol.py -f ram_dump --profile=LinuxDebian_4_19_178-amd64_profilex64 linux_pstree
[...]
.atd 897
.cron 898
..cron 933
...sh 947
....tcpdump 949
....python3 950
.systemd-logind 901
.dbus-daemon 909 110
.atop 945
.acpid 958
.netplugd 966
.zebra 1004 104
.bgpd 1011 104
.ripd 1019 104
.ripngd 1025 104
.ospfd 1029 104
.ospf6d 1033 104
.staticd 1037 104
.bfdd 1041 104
.watchfrr 974
.rsyslogd 1480
.ntpd 1575 105
.login 1652
..vbash 1679 1003
...sudo 1756
....bash 1757
.....insmod 1963
.sshd 1860
.agetty 1960
[...]
We get a lot a processus but at first sight none of them seem to be malicious
Let's put that aside for now
Let's check the contents of the command history
Maybe he will teach us something interesting
$ vol.py -f ram_dump --profile=LinuxDebian_4_19_178-amd64_profilex64 linux_bash
Volatility Foundation Volatility Framework 2.6.1
Pid Name Command Time Command
-------- -------------------- ------------------------------ -------
1757 bash 2023-04-13 19:22:18 UTC+0000 ??????????????????????
1757 bash 2023-04-13 19:22:19 UTC+0000 ???????????????????????????
1757 bash 2023-04-13 19:22:42 UTC+0000 reboot now
1757 bash 2023-04-13 19:28:25 UTC+0000 ls
1757 bash 2023-04-13 19:28:44 UTC+0000 ?????????????????
1757 bash 2023-04-13 19:29:02 UTC+0000 mv -t . /home/vyos/tesseract /home/vyos/fm
1757 bash 2023-04-13 19:29:02 UTC+0000 ????????????????????????????????
1757 bash 2023-04-13 19:29:02 UTC+0000 ???????????????????????????
1757 bash 2023-04-13 19:29:02 UTC+0000 ??????????????????????????
1757 bash 2023-04-13 19:29:03 UTC+0000 ????????????????????????
1757 bash 2023-04-13 19:29:21 UTC+0000 ????????????????? /u??/l??/f??/?????? eth0 10.?.1.?
1757 bash 2023-04-13 19:29:37 UTC+0000 ???????????????????????????
1757 bash 2023-04-13 19:29:37 UTC+0000 ??????????????????????
1757 bash 2023-04-13 19:30:34 UTC+0000 insmod /root/LiME/src/lime-4.19.178-amd64-vyos.ko "path=tcp:4444 format=lime"
In the scenario it is mentioned that the capture we have is from a network device. This confirms the OS VyOS we just found in the command history
something else is interesting in this history the command line
/u??/l??/f??/?????? eth0 10.?.1.?
It's like a path like /usr/lib/f??/?????? eth0 10.?.1.?
Remember that in the list of processes there was one named watchfrr
So we can supposed that the /f??/ is /frr/ so we get the /usr/lib/frr/?????? path
We therefore need to find the 6-character long frr process that has been launched
To understand exactly what FRR was do a little tour of the doc
So FRR implements all standard routing protocols such as BGP, RIP, OSPF, IS-IS and more (see Feature Matrix), as well as many of their extensions.
With this informations, why not check the Networking Information with the linux_netstat volatility plugin ?
$ vol.py -f ram_dump --profile=LinuxDebian_4_19_178-amd64_profilex64 linux_netstat
ripngd/1025 /var/run/frr/ripngd.vty
ospf6d/1033 /var/run/frr/ospf6d.vty
We get other processes but these two are interesting because they are 6 characters long
Unfortunately for us this is where our reasoning stops at the ctf, both processes mentioned above are legitimate and neither is the flag
At the end, we learn that we could use the linux_enumerate_files volatility plugin
This plugin provides information about files and directories that are currently open or have recently been closed, as well as executable files that are currently running.
$ vol.py -f ram_dump --profile=LinuxDebian_4_19_178-amd64_profilex64 linux_enumerate_files > files.txt
$ cat files.txt | grep /usr/lib/frr/
0xffff9efaf1f9b9c8 132989 **/boot/grub/boot/1.2.7/rw/usr/lib/frr/ospf5d**
0xffff9efaf9ddb010 8525 /usr/lib/frr/watchfrr
0xffff9efaf9ddbab0 8219 /usr/lib/frr/bfdd
0xffff9efaf9dda2c8 8218 /usr/lib/frr/staticd
0xffff9efaf9ddaac0 8217 /usr/lib/frr/ospf6d
0xffff9efaf9dd6818 8205 /usr/lib/frr/ospfd
0xffff9efaf9dd7560 8204 /usr/lib/frr/ripngd
0xffff9efaf9dd7010 8203 /usr/lib/frr/ripd
0xffff9efaf9dd7808 8202 /usr/lib/frr/bgpd
0xffff9efaf9dd7d58 8201 /usr/lib/frr/zebra
0xffff9efaf9efa2f8 22955 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/watchfrr.sh
0xffff9efaf9dd8878 22954 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/watchfrr
0xffff9efaf9dd85b8 22934 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/bfdd
0xffff9efaf9dd9638 22952 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/staticd
0xffff9efaf9dd90b8 22946 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/ospf6d
0xffff9efaf9dd4b38 22947 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/ospfd
0xffff9efaf9dd4878 22951 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/ripngd
0xffff9efaf9dd5bb8 22950 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/ripd
0xffff9efaf9dd45b8 22935 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/bgpd
0xffff9efaf9dd5638 22956 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/zebra
0xffff9efaf9daf8f8 22940 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/frrcommon.sh
0xffff9efaf9da10b8 22941 /lib/live/mount/rootfs/1.2.7.squashfs/usr/lib/frr/frrinit.sh
With this extract notice the /boot/grub/boot/1.2.7/rw/usr/lib/frr/ospf5d, ospf5d is not a FRR process, is not mentionned in the doc, so we can supposed that he's our malicious process.
Flag : MCTF{vyos-/usr/lib/frr/ospf5d}
