Deagler's 4n6 Blog

Time flies and finally we have made it into the last week of Magnet Weekly CTF. This week was still a two-parter. The 1st part of the challenge asked of a PID: Using HxD to search the key phrase " how hackers hack, and how to stop them " inside the memory dump, a hit could be found quickly:  After that, the Volatility yarascan plugin was used to find the PID that related to  " how hackers hack, and how to stop them ".  The Hex value corresponding to the " How Hackers Hack, and How To Stop Them " string value discovered from HxD could be reused as the search criterion for yarascan , the  " python vol.py -f ../memdump.mem --profile=Win7SP0x64 yarascan -Y "{48 6F 77 20 48 61 63 6B 65 72 73 20 48 61 63 6B 2C 20 61 6E 64 20 48 6F 77 20 54 6F 20 53 74 6F 70 20 54 68 65 6D} " command was issued in terminal: From the yarascan output, all hits came from the " iexplore.exe " process with PID 4480 . Therefore, the answer for the part 1 chal...

The challenge of this week was a standard 2-parter. Even though it was not a lengthy challenge, I had learnt that one could reconstruct network pcaps from a memory image . 😁 Upon reading the question, I was initially puzzled by it. Nonetheless, I still tried to look for the answer from the Volatility netscan output and tried dumping the " C:\Windows\System32\drivers\etc\hosts " file from memory. Sadly , none of these two paths gave me any answer. Things took an unexpected turn when I was reading other participants' week 10 writeups, some interesting content from Stark4n6's writeup  caught my attention. In that writeup, he referenced an articl e that talked about reconstructing network pcaps from a memory image . Using the " bulk_extractor64.exe -x all -e net -o test/ memdump.mem"   command, a packets.pcap file would be obtained.  Wireshark could open the   packets.pcap file and the answer ( 172.217.10.238 ) could be seen immediately. Part 2 of the challen...

There were 5 parts in the week 10 challenge of the ongoing Magnet Weekly CTF. I managed to solve 4 parts out of 5 and the following would cover my walkthrough for this challenges: Notice the wording "established connection" was used in the challenge description. Therefore, the term "ESTABLISHED" was searched inside the the  Volatility  netscan plugin output: There were 4 known established connections at the time of RAM collection. According to whois output, the 1st IP address (151.101.116.106) belongs to fastly. However, the 2nd IP address (172.253.63.188) belongs to Google. Thus, the answer should be 172.253.63.188:443 . Part 2 of the question immediately asked for the local IP address and the port number. From the Part 1 netscan screenshot, the answer should be  192.168.10.146:54282 . The browsed URL should be lurking somewhere inside the Chrome History SQLite database, which could be dumped with the following Volatility command: python vol.py -f ../memdump.mem ...

This week's Magnet Weekly CTF challenge was broken into 7 parts and I learnt a lot from it. Without further ado, let's jump right into the challenge questions.  The 1st challenge question was: To be honest, I did spend a lot of time on the 1st challenge question as I did not catch the full context in the first place. Eventually it took me roughly 1 day to see through it.  As there were some slack.exe processes found from the Volatility pslist plugin output and the fact that " The user had a conversation with themselves about changing their password. ", the first thought that came to my mind was the slack.exe processes might very well had something to do with the answer. However, it turned out to be a wrong rabbit hole. Clueless, I resorted to using the GNU strings utility to capture all printable character sequences that are at least 4 characters long: strings memdump.mem > memdump_strings.txt Then the term password was searched within the memdump_strings.txt ...

This week's Magnet Weekly CTF Challenge is once again another two-parter. Part I of the challenge asked the following: What package(s) were installed by the threat actor? Select the most correct answer! From the user hadoop 's .bash_history file, there was an entry that indicated hadoop used ll command to list out the details of a /usr/local/hadoop/bin/cluster.php file. Since Hadoop does not run on PHP, why on Earth would there be a cluster.php file inside the Hadoop binary folder? Moreover, from either /var/log/apt/history.log or /var/log/apt/term.log , it was shown that the php package was installed on 2019-10-17 and most of the packages were installed on 2017. Therefore, it was highly likely that the threat actor installed the php package on the HDFS primary node and it turned out to be correct. After that, Part II of the challenge was released and it asked the following: Why?  hosting a database  serving a webpage  to run a php webshell  create a fake syste...

After two weeks of challenging questions, week 7's Magnet Weekly CTF challenge is much more relenting and gentle than before. Despite the challenge was created as a three-parter, all the answers could be found from one single file. So this week's challenge questions are: What is the IP address of the HDFS primary node? Is the IP address on HDFS-Primary dynamically or statically assigned? What is the interface name for the primary HDFS node? In order to locate the answers to these questions, the /etc/network/interfaces file from the HDFS primary node should be looked at: And boom, all the answers could be found here!  What is the IP address of the HDFS primary node? ( 192.168.2.100 ) Is the IP address on HDFS-Primary dynamically or statically assigned? ( static ) What is the interface name for the primary HDFS node? ( ens33 ) Case closed for this week.

Here comes the week 6 challenge of the Magnet Weekly CTF challenge. For the first time, the challenge was divided into a two-parter. Participants would need to solve the 1st part of the challenge in order to view and solve the 2nd. The 1st part was relatively easy, as a gentle warm-up to the 2nd part. Part I The 1st part of the challenge asked the following: Because the flag was a numerical error code attributed to a failed Hadoop dependency installation, the first thing to check had to be the Linux package manager logs. Since " apt " package manager was used on all nodes, the directory " /var/log/apt " on both HDFS secondary nodes should be inspected carefully: From the contents of " history.log " file, there were errors occurred during the installation of Oracle Java 7 and 8 packages and the " dpkg " subprocess returned a "1" error code.  So the answer to part 1 challenge should be "1" and sadly it was not the correct answer...