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...