rykergogo.github.io

This is where I blog about reverse engineering, cybersecurity, and related things.

View on GitHub

Rykergogo - Ethical Hacking

Huntress CTF Solutions!

These are my solutions to Huntress challenges that I found to be the most fun.



[Malware] Zerion Solution For this challenge, participants are provided with a file named zerion.

At first glance, the contents of this file reveals some PHP code.



Digging in a little farther, there seems to be some encoded text at the end of the file.



In the first screenshot, the variable $L66Rgr is being assigned to an array containing the php code and the base64 string at the end of the file.

Specifically, the explode function is splitting the current file by the string ?> which would isolate the base64 string into the second element of the array. The array should look similar to this:

[php_code, base64_text]



A little further along the code is this variable $L6CRgr. Here, an array is created as so:

[/x/i, x, base64_text]

The first two arguments are just decoded base64 text. The third element is what we want to pay more attention to. It's doing some stuff to the second element of the array created before.

Following the function call, first run the third element of the array (base64 text at end of file) through a rot13 decoder.



Then take the output and reverse the string.



Then we get, surprise surprise, base64 text. Run that through a base64 decoder.



Now we're getting somewhere...



After searching through more php code, the flag is captured!

[Forensics] Traffic Solution ~~ NOTE: It's easier to complete this challenge within a Linux environment. ~~

 For this challenge, participants are provided with a file called traffic.7z.

After extracting the file, reveals a bunch of gzip files



The naming convention of the files suggests these are zeek logs. More Info

After extracting the gzip files, we can now spin up a database using Rita



rita import . logs will create a database including all the files in the present working directory and name it logs.



rita show-beacons logs -H will spit out some data to look at. We can already see some suspicious looking connections based on how many were made. However, this format is hard to read and doesn't really show much.



Running the command rita html-report logs will create an organized html report for us.



Looking at the Beacons, there are several outgoing connections that seem to be repeated more than usual. Along with a score that is VERY close to 1, this raises some red flags. Even more so with the highlighted IP.



Trying to access the IP directly reveals this is pointing to some github url. 104 connections being made to one github link? Something isn't right.



Switching to the Beacons SNI page, and searching for any github urls we find a github pages link.



Voilà! Flag is captured :-)

[Malware] Hot Off The Press Solution Participants are provided with a file hot_off_the_press. In the metadata of the file we see it's UHA compressed file.





Using UHARC Cmd we can extract the files provided we give the supplied password infected found on the challenge site.



The extracted file seems to be a .ps1 Powershell file.

Going inside the file, we see some gzip and base64 happening to a provided string that is being concatenated.



Going to the end of the string, we see that the string is first being decompressed using gzip, then decoded using Base64.

Looking closer, there is the -f Powershell string format specifier with replacement happening with 'L' and 'E'. This will be important further along...



Copying the string into a new file, we can start to clean it up and make sense of it. First, by removing all instances of '+' since it's purely Powershell code and has nothing to do with the actual string.



Next we can remove '. It's safe to assume it doesn't have anything to do with the string.



Remember the replacement with 'L' and 'E' mentioned before? Here it comes into play. There are several {0} and {1} placements throughout the string. Now, we can replace every {0} with L and every {1} with E.





Following the function call of the original Powershell code, put the cleaned up string into a gzip decompressor.



We have some more powershell code, and from first glance there doesn't seem to be anything interesting.



Until we notice a very long Base64 string.



Just copy and paste the string into a Base64 decoder and the flag is captured!
[Forensics] Backdoored Splunk Solution For this challenge, participants are provided with a zip file containing some files used for Splunk Add-on for Windows.



We want to direct our attention to the bin folder since these files were deemed suspicious. By viewing a certain powershell file within bin/powershell/nt6-health.ps1 we can see a web request being made to the provided container on the challenge site.



This web request includes an authorization header which is important to note... If we go to the challenge site we are met with this json message.



Now we can craft a HTTP GET request to the site adding in the authorization header with the value we found from the powershell file.



You can use any tool you want to do this. Personally, I'm using Postman because it's simple and gets the job done, but other tools like Burp Suite should work fine.



Once the request is sent, the server responds back with some Base64 encoded text inside a HTML comment.



Decode the text using your favorite tool, and flag captured!
[Misc.] Rock, Paper, Psychic Solution
Participants are provided with a 7zip archive which contains an exe file. Using DIE we can see it's a 64-bit exe file.





From the entropy analysis page, the binary seems to not be packed, which makes our job a lot easier.



Next open the binary in a dissassembler and begin to look for any interesting strings. I'm using IDA Freeware



Here we can see several interesting strings that have to do with the gameplay along with some interesting Hex and seemingly random string of characters.



Clicking into the Hex string, we see it's referenced in a function called printFlag.



Searching through the function, it will lead you to a fromRC4 function and then to a genKeystream function. Now we have an understanding that the flag is not hardcoded in the binary, rather it's generated at run time. To investigate further, we need a debugger.



Before going further, take note of the address where printFlag is since we can try to trigger it during run time.



Open the binary in a debugger of your choice, I'm using x64dbg



Run through the game, and the instruction will go to a different location in memory. We can exploit this by changing the next instruction to jump to the location of printFlag we saved earlier. Instruction should look similar to jmp 0x4168F0. Your address might be different.



Continue with execution, and if done properly, flag should appear. Well done!
[Misc.] PRESS PLAY ON TAPE Solution
This challenge is one of my personal favorites simply because of how unique it is.

Participants are provided with a wav file named pressplayontape.wav. Playing the audio file reveals an ear piercing sound, and a spectrogram reveals nothing.



This requires us to think a little outside the box... Do a quick search on the filename and this will pop up.



Hmm.... Commodore 64. That's computer related, right? Turns out, Commodore 64 had it's own special audio file format with the extension .tap that could be used to hide messages and data when recorded from VHS tapes. So, now it's time to try to convert this .wav into .tap.



To accomplish this, I'm using C64 Tape Decode. Specifically, wav2tap.exe. Now we have the raw Tape data.



We can now take this data and save it into a tap file. I've named it output.tap.



Here, I'm using a tap analysis tool TapEx to analyze output.tap. Another tool from commodore.software. Going to the View tab we see several sections. The section that looks the most interesting seems to be the CBM DATA FIRST. It contains some hex.



Pop this hex into an online tool and convert to ascii, and there's the flag!
[Forensics] Texas Chainsaw Massacre: Tokyo Drift Solution
This challenge is difficult and therefore one of my favorites.

Participants are provided with a Windows Event Log named Application Logs.evtx.



Viewing this file with the built in Windows Event Viewer, not much can be found from the log alone.



If we take a look at the event log, there is some interesting obfuscated text planted in the file here.



This text is obfuscated powershell code, so we can edit it. Remove the last statement to print it separately and run the script. Now we have our first stage of deobfuscation.



Copy the output and modify it so the first statement is on a separate line. Make additional edits as needed and run, and now we have something that is starting to look like recognizable code. This task is all about trial and error...



You know the drill, copy the output and make modifications as necessary to get it to run properly. However, this time, it's not spitting anything out. Hmm... We need to try something else.



Maybe it's nothing we're doing wrong, the code just isn't supposed to print anything at this stage. So we force it to print output with Write-Output $output. With $output assigned to the code.



Taking the output from the previous run, copy that output and format it so it spits out the result. Your code should look similar to mine, and now we run and get something that looks like pure Powershell code. Now we're close.



Looking closer at the output from the previous run, the code seems to be trying to get some data from the Dns Name eventlog.zip.



We also notice the data taken from the remote server is being decoded from base64 and converted into a readable string. We can force this to run by taking the code out of the try catch block and just running it independently on the next line.



Run that code, and flag is down!

NOTE: This challenge is based off a fairly recent attack which involves hiding shellcode in Windows Event Logs. More info here.
[Malware] Speakfriend Solution
Participants are provided with a 7zip archive named main.7z. Within this archive is a main file which seems to be an ELF file.





We can use Ghidra to dissassemble the file and we can already see some weird Hex in the main function.



Take the hex and convert to Ascii, and you get a string that's reversed. By reversing the string again, we get something that looks meaningful. Take note of this string it will be important later.



If we notice the response from a simple GET request to the container, there is a header User-Agent that looks very similar to the string we just extracted from the main.elf.



Make a GET request to the container again, but this time replace the User-Agent header with the string we extracted from the main file. The response we get is a link to somewhere else on the server.



Make a GET request to the provided url, and you win!
[Malware] RAT Solution
Participants are provided with a 7zip archive named rat.7z. Extracting the archive reveals a file rat.



This file has the "MZ" signature which indicates a PE (Portable Executable). Now it's time to analyze this further within a virtual environment.



Detect It Easy indicates this is a .NET 64 Bit exe file.



It's always good to check entropy to see if it needs unpacking. All indications point to not being packed which makes the job easier.



Here, we can use a .NET dissassembler and debugger dnSpy to take a look inside the code. There's a decrypt function that's worth looking at.



If we place a breakpoint on the return array after decrypting and run, we get an array with the magic bytes signature 4D 5A. This indicates it's decrypting and probably going to try to execute the PE file contained within the array.



We can view the array in a Memory Map and dump the selection to a file to analyze this file further.



Using DIE, this file seems to be a .NET 32 Bit exe.



This file seems to also not be packed.



Using dnSpy again, this file seems to be the actual RAT that will attempt to spin up a reverse shell (Client.Helper probably) along with applying some features in Settings.



Going into Settings, there's more decryption going on that seems to be getting the settings for the stub. This will be important in a little bit...



Scrolling down we notice a string Flag that isn't used by any code present in the file. Copy this string down as we'll use it.



What we can do now is place a breakpoint on the return statement in Decrypt and replace the input with the string we just copied down.



Step over the return statement to view the return value, and nice job! We took down the RAT.
[Malware] Batchfuscation Solution
Participants are provided with a file batchfuscation and upon inspection, it's a batch script.





To print the output of the script into a text file, we can add this code to the top of the file and run it.



The output prints something like this, and we can notice some replacement going on with the alphabet, numbers, and some special characters.



Using the replacement provided, we can craft the word flag. We need to include %% as we'll be searching for it in the script.



Searching for this word, we find several instances. It looks like flag is apart of some sentences here, and looking closer each sentence flag is apart of, starts the same. Let's print this out during runtime and log it.



Copy the entire sentence including flag and replace with echo + (sentence + flag) as shown.



After running the script again, the log will now show the characters of the flag indexed from 1 to 37 (including flag{}). We basically have the flag, now it's just a matter of magic string formatting.



We can narrow the text down to just the flag characters by using a regex expression.



At this point, use whatever methods and tools you want to format the string further to piece together the flag. For example, I just stripped the text down to the (index)=(flag_character) and semi-ordered by the index to make it easier to piece together.

[Forensics] Tragedy Redux


Participants are provided with a 7zip file containing a file tragedy_redux. Upon inspection it has a magic bytes signature that doesn't signify any known file type.



Looking through the contents of the file for clues to it's type, it has a word/vbaProject.bin which means it's likely a word document with macro(s).



The magic bytes signature for word documents is 50 4B 03 04, so we can overwrite the previous incorrect signature. List of file signatures.



Opening the file in Microsoft Word or any software that can handle word documents, reveals a page with the dictionary definition of tragedy.



Checking the macros in the document we see some interesting VB code that's jumping through hoops to decode a string. You can sit and manually step through the code yourself, but I think it's best to run this and see what the output string is.



Now, we can take this code and modify as needed to fit the VB program we're going to run. We can also remove the If ActiveDocument.Name snippet as this isn't going to be triggered in a word document.



Running the code reveals a Base64 encoded string.



Decode the message using a Base64 decoder. Nice work!