Archives

All posts by d3nni5

TryHackMe – Overpass 2 Hacked

Posted by d3nni5 on 24/03/2023
Posted in: Red, Windows. Tagged: , , , .

Walkthrough of forensic analysis,  backdoor code analysis and attack route simulation.

Forensics – Analyse the PCAP

After downloading and opening the *.pcap capture file we should apply the “HTTP” or similar filter (e.g. port 80) to narrow down the volume of displayed traffic logs. Then just clicking on the first one to follow the TCP stream to get all the interactions between the client and server for that particular request, however the first question can be answered even without that checking the GET requests in the list quick.

What was the URL of the page they used to upload a reverse shell?

The next question asking for the payload itself can be answered more easily with some further filtering narrowing down to the requests looking for the “upload” word and then following up the TCP stream as before. We can see that the payload applied the usual feline reverse shell connecting back to port 4242.

What payload did the attacker use to gain access?

The same data filtering technique can be used to answer the next question with following up the TCP stream as before.

What password did the attacker use to privesc?

The same TCP stream can be used to answer the next questions as the attacker downloaded an ssh backdoor script written in “Go”. 

How did the attacker establish persistence?

After getting the hashes from the same TCP stream, let us save them in a text file than crack it with John. I have downloaded an untouched fasttrack wordlist as mine has been modified and then tried to crack the hashes with John.

Using the fasttrack wordlist, how many of the system passwords were crackable?

Research – Analyse the code

First of all let’s get the ssh-backdoor code using the discovered URL in the packet capture file cloning it from GitHub as the attacker did, and then look-up the hash and the salt in question from the code.

What’s the default hash for the backdoor? 

What’s the hardcoded salt for the backdoor? 

From the packet capture file the hash used by the attacker can be pulled out.

What was the hash that the attacker used? 

Let’s crack it with Hashcat to answer the next question.

What’s the password?

Attack – Get back in!

First of all let us navigate to the IP-address to check the website.

The attackers defaced the website. What message did they leave as a heading?

Now let’s run some Nmap scans to figure out the open ports. 3 TCP ports are open, 22, 80, 2222. The first 2 ones are obvious, but let’s try out the last one as probably that is the SSH backdoor port. We already know the password, don’t we..

What’s the user flag? 

Now we have the user flag, but the final aim is the root flag. According to the hint there should be a quick way to raise privileges. Let’s check what else do we have in the same directory in which the user flag was found. Well, it seems there is a root owned copy of bash there which according to GTFOBins can be utilized to preserve privileged access if the SUID bit is set. Let’s try that.

Now, that we are root, there is nothing else just to find the root flag.

Thanks for reading and as always, any feedback is most welcome.

TryHackMe – Gatekeeper Walkthrough

Posted by d3nni5 on 09/02/2023
Posted in: Red, Windows. Tagged: , , , , , , , , , , , , , .

Walkthrough of exploiting a buffer overflow vulnerability on a Windows machine, privilege escalation via Firefox.

Initial scanning

Let us start with our usual Nmap scan which shows a couple of interesting ports which we could start with.

Altough 31337 is the most enthralling one, let’s have a quick look at an SMB-specific scan. It shows that not only signing is not required, but also brings up our target file in the shares.

Let’s get the file real quick.

Buffer Overflow

After downloading the file as we did earlier in similar rooms a proper investigation should be carried out on a Windows machine. We can use another THM box for this purpose. Due to the fact that this room is about buffer overflow exploitation, the best to transfer it to a BOF-related Windows machine like the BufferOverFlowPrep one on which we already have the necessary tools to play with them. Let’s start our usual HTTP server and download the files from Windows Explorer.

Let us attach the gatekeeper.exe to Immunity and then running it in order to do some fuzzing with it.

First of all we need to figure out at what location the memory stack is overflown causing the program to crash. Let’s generate a random string of 500 characters with the pattern_create module of Metasploit to single out the part which goes to the EIP (Extended Instruction Pointer) address.

Let us add the string as a payload to a general fuzzer script of our choice and run it against the executable running on our test machine.

Before running the script against the gatekeeper executable attached to Immunity, we must make sure that the working directory of the Mona plugin in the debugger is configured.

After running the scripts from our attacker machine it crashes the immunity-attached process with an access violation error.

After this we have to calculate the EIP entry point using a Mona script using the length of the payload embedded in the fuzzer script. This comes back with the offset value of 146.

As consequence let us change the offset from 0 to 146 in our fuzzer script. Also let’s delete the payload for now and change the padding variable to BBBB to check the available space needed by the shellcode later on.

We can see our B’s as 42424242 as the value of the EIP register which shows the border of our offset and such having fully identified the memory space required.

Now we need to tailor a bit further our script and filter out the potential bad characters which would ruin the execution. This is to be achieved by using a Mona script generating a byte array of bad characters and a list of ours using a script. Subsequently placing the result into our fuzzing script and running it against the gatekeeper process on our test machine. So let’s generate a bad character string with the script below.

And our bad characters as a result..

Placing them into our fuzzer script as payload.

Also creating a collection of bad characters in the debugger with the exemption of null-byte as it is always bad anyways.

Ok, now let’s run our fuzzer loaded with a collection of bad characters after re-attaching the gatekeeper exe to Immunity. It crashes as usual and due to the fact that we need to make sure that all bad characters strained out which would render our final exploit later on comparison is needed between the list of bad characters and the state of memory at the present of crash. This is to be achieved with another Mona script. We can see that only the null-byte and it’s neighbor is present running the bytearray at our ESP register which is normal.

Now we need to find a legit JMP ESP instruction address to redirect the execution flow to the reverse shell code of ours. This is to be done using another Mona script. In this command all the bad characters which were listed during the comparison should be present. Two pointers discovered as per the logs.

Ok, so we are going to use the second address for now which is 0x080416bf. This address is to be placed into our fuzzer python code as a return address but in Little-Endian format as described in another post. Also, we now have to generate our reverse-shell code using msfvenom to actually get the Buffer OverFlow vulnerability exploited. In the command the identified bad characters should be specified amongst the payload type, format, encoder type and the name of the shellcode.

Let’s upgrade our fuzzer script with all our final modifications to a proper exploit code.

After running our exploit against the test machine the gatekeeper.exe should NOT crash but we should get back a reverse-shell.

Remember, this is just testing, let us run it against our actual victim machine changing the IP-address in our expoit code.

Locate and find the User Flag.

Privilege Escalation

There is an interesting shortcut on the desktop which cannot be there by accident, let’s have a closer look and try to get some credentials using Metasploit. First we need to generate a Meterpreter payload which is exactly the same than the previous one but instead of catching the backconnect with Netcat we would use a Metasploit multihandler.

After running our exploit code with the modified msfvenom payload we receive our reverse-shell on our Metasploit listener.

Now let us gather the Firefox credentials with a specialized module of Meterpreter.

After this we shall download a Firefox credential decrypter script from GitHub in order to get the data in cleartext.

Now, let’s rename all the downloaded credentials as per the instructions of the decrypter to cert9.db, cookies.sqlite, key4.db and logins.json respectively.

Dumping the credentials..

So, now, with the credentials, we are free to login to the victim computer and lookup the root flag.

Locate and find the Root Flag.

Thanks for reading and as always, any feedback is most welcome.

TryHackMe – Brainstorm Walkthrough

Posted by d3nni5 on 31/01/2023
Posted in: Red, Windows. Tagged: , , , , , , , , , , .

Walkthrough of exploiting a chat program on a Windows machine.

Initial scanning

Let us start with our usual Nmap scan which shows 3 open TCP ports, 22, 3389 and 9999. The slightly more interesting one is the highest which is used by the Brainstorm chat service however all ports should be investigated. 

A more specific Nmap scan shows us that anonymous FTP login is allowed.

Accessing Files

We can find 2 files in the chatserver directory, the chatserver executable itself and the essfunc dll support file. Let’s get them to have a look. Do not forget to switch to binary mode before the transfer to avoid errors.

Access

Ok, so now we have the files, but a proper investigation should be carried out on a Windows machine. We can use another THM box for this purpose. Due to the fact that this room is about buffer overflow exploitation, the best to transfer it to a BOF-related Windows machine like the BufferOverFlowPrep one on which we already have the necessary tools to play with them. Let’s start our usual HTTP server and download the files from Windows Explorer.

Upon connecting to the chatserver running on the Windows machine with Netcat from our attacker machine we can see that it works as expected.

After opening the process with Immunity Debugger let’s try to crash it with overloading the memory stack buffer. First let us generate 2000 A’s with python then sending it as a message.

Well, it has no effect on the chatserver. Let’s generate a bit more A’s with repeating the steps from above with the number of 3000. Yeah.. that crashes the server as we can see it stops in Immunity as well overwritting the EIP (Extended Instruction Pointer) with 41414141 in ASCII which represents our A’s from the chat message field.

Ok, so now we know that the process is vulnerable to BOF-attacks but we do not know where exactly the crash happens between 2000 and 3000 bytes of payload. Let’s find it out using a Python fuzzer script which can be found in the same room.

After quickly re-attaching and restarting the chatserver.exe – CTRL + F2 -> F9 – let’s run the fuzzer script against the process.

It crashes the process at 2200 bytes it seems. Now what we need to find is where exactly the payload lands in the EIP register of the process in order not only crashing but to hijack the chatserver.exe. So what is needed to be done is to generate a unique pattern which would allow us to map the memory. We can do that using a Mona script in the debugger itself.

Now, as the log window suggests, we should copy the created pattern from the relevant text file, so let’s do that.

Placing the generated code into our fuzzer script.

After sending the payload with our modified fuzzer script the process crashes as shown in the debugger.

Now that we now the exact entry point it is high time to calculate the offset of the EIP which is basically the relative memory space occupied by it. That is to be achieved by another Mona script in the debugger by quering the EIP 31704330. It comes back with a result of 2012 bytes.

We have enough space as but we need some more for the reverse shellcode itself. To check this we make some slight modifications  to our fuzzer script adding the exact offset size discovered, changing the ending of A’s to B’s to get that identifiable more easily and also adding some padding as C’s to distinguish the extra space needed.

After rerunning the script against the chatserver process, we can see that our C’s has overwritten the ESP (Extended Stack Pointer) as expected which means that we have enough space for the shellcode as well.

The next step should be to find the bad characters. Bad chars are basically just a bunch of unwanted characters that can break shell codes. Every application is different in acceptance of them and should be evaluated on a case by case basis but as this is a bit cumbersome process let’s just download a list of them from here and add it to our script as payload temporarily too see how the chatserver process reacts to it.

After running it against the program as usual we shall generate a bad char bytearray in Immunity with Mona as well to get it compared with ours to see whether any is missing which would render the execution of our shellcode.

The results of the comparison with following the ESP register at the time of crash is satisfactory, there is no uncovered bad character it seems. The only bad chars present are the null byte and its adjacent character which is also normal.

Our last move is to find the location of the JMP ESP memory address to point to our shellcode. A Mona script help us out again. Let’s do it after our usual CTRL+F2 -> F9 routine.

Mona has found 9 pointers, let’s use the first one placing it into our modified fuzzer script in Little-Endian format swapping the B’s currently there. Little-Endian is basically changing the order of the address starting with the least significant byte from the end. So, instead of 62-50-14-df we will use df-14-50-62. Also we need to generate an msfvenom reverse shell payload and placing that into the script too. Finally let’s change the padding to 20 non-operational bytes to avoid any potential memory attrition.

So, the final attack script would look like the one below.

Now before re-attaching and restarting the chatserver process and running the exploit code let’s not to forget our Netcat listener on the port which was identified in the msfvenom code. After running the script we should get back a reverse shell.

Ok, so it works against the test machine, let’s attack now our target machine and get the root flag as it should come back with a system shell.

After gaining access, what is the content of the root.txt file?

Thanks for reading and as always, any feedback is most welcome.