Category: Uncategorized

Posted on by

Name-That-Hash: A tool to identify hashes

Hello aspiring Ethical hackers. In this article, you will learn about a new tool named Name That Hash. Name That Hash is a hash identifying tool that can identify over 300 types including MD5 and SHA256. The other features of this tool include displaying summaries for the hashes identified, colored output and displaying in the order of their popularity etc. This tool can be installed from the repository of Kali as shown below.

Once this tool is installed, it can be started using command nth. To test a single hash, we can use “nth” with option “-t” as shown below. Let’s first give a MD5 hash.

nth -t <hash>

Just like hashid and hash-identifier, this tool also got it right but it is giving us some additional information like where the hash is actually used. For example, Md5 is used in Linux shadow files. What about SHA-1 hash?

It got this right too. Next, let’s give it a LM hash.

It put this in the Least likely section. Next, let’s give it a NTLM hash.

It failed to get spot on NTLM too. Just like its predecessors, it correctly detected the SHA-512 and SHA-256 hashes.

The good thing about name-that-hash is that instead of being blank, it gives us more information about actually where the hash is used. This can be useful when you grab a collection of hashes from a target network. You can easily decide which hashes to crack and which not to crack.         
If you have more number of hashes, giving it one by one can be cumbersome. Luckily, you can give them all at once by saving these hashes in a text file as shown below.

and using “-f” option to specify the file.

nth -f <path to the file that has saved hashes>

The output which is not shown here is same as above.

Name-That-Hash is only designed to identify hashes unlike the other two but if you have a base64 encoded string, it can be decoded by nth using the “-b64” option.

nth -b64 -t <base64 encoded string>

It correctly decoded it as “hackercool” All the above are also encrypted hashes of the text “hackercool”.  Suppose you want the result to only display the most likely result, you can get this by using the “-a” option as shown below.

nth -a -t <hash>

If you observe the above images, you can see the banner of name-that-hash occupying lot of space. Just like me if this is putting you off, you can view result without banner using the “–no-banner” option. 

nth –no-banner <hash>

Once go to the image above the above image, the one where we used the “-a” option. Once, carefully observe the result. It correctly detected the hash as SHA-512. Next to it, you can see the text “HC 1700 JtR: raw-sha512”.                    This is HashCat (HC stands for HashCat) and John (JtR stands for John The Ripper) information being displayed by the tool because the next thing you will do after identifying the hash is to crack it using Hashcat or John. This requires what you need to put into these tools to crack it. For example, let’s take a simpler hash.

John The Ripper says its raw-md5. We need to just supply this format as shown below in JTR to crack this.

Similarly, the HC number given is “0”. Let’s supply it as shown below in HashCat.

However, if you are an experienced ethical hacker with too much details hurting your ego, you can just view the result without the information of John The Ripper using “–no-john” option.

nth –no-john -t <hash>

This is the difference.

You can do the same with HashCat information using “–no-hashcat” information.

nth –no-hashcat -t <hash>

The difference can be seen below.

That was all about this tool.

Posted on by

ProxyLogon vulnerability : Explained In detail

Hello aspiring ethical hackers. In this article, you will learn about the ProxyLogon vulnerability. ProxyLogon is a vulnerability that impacts the Microsoft Exchange Server.  It is estimated that over 2,50,000 Microsoft Exchange Servers were victims of this vulnerability at the time of its detection.

The Proxy Logon vulnerability is related to the four zero day vulnerabilities that were detected in the Exchange Server in December 2020. On December 10, 2020, Orange Tsai, security researcher working in DEVCORE, discovered that attackers can combine some vulnerabilities in the Exchange Server to achieve remote code execution on the target and upload a webshell to it. The four vulnerabilities are,

CVE-2021-26855: SERVER SIDE REQUEST FORGERY

This is a Server-Side Request Forgery (SSRF) vulnerability in the Exchange Server that allows remote attackers to gain admin access once exploited. This can be exploited by sending a specially crafted web request to a vulnerable Exchange Server. The web request contains an XML SOAP payload directed at the Exchange Web Services (EWS) API endpoint.  This request bypasses authentication using specially crafted cookies. This vulnerability, combined with the knowledge of a victim’s email address, means the attacker can exfiltrate all emails from the target’s Exchange mailbox.

CVE-2021-26857: REMOTE CODE EXECUTION VULNERABILITY

This is a post-authentication insecure deserialization vulnerability in the Unified Messaging service of an Exchange Server that allows commands to be run with SYSTEM privileges. The SYSTEM account is used by the operating system and services that run under Windows. As readers have seen many times in our Magazine, a SYSTEM account in Windows has full permissions by default. A hacker can either steal credentials or use the above mentioned vulnerability to execute arbitrary commands on a vulnerable Exchange Server in the security context of SYSTEM.

CVE-2021-26858 AND CVE-2021-27065

These two vulnerabilities are post-authentication arbitrary file write vulnerabilities that allow attackers to write files to any path on a vulnerable Exchange Server. A malicious hacker can also exploit the previously mentioned SSRF vulnerability to achieve admin access and then exploit this vulnerability to write web shells to virtual directories (VDirs). These virtual directories are published to the internet by the server’s Internet Information Server (IIS).
IIS is Microsoft’s web server and a dependency that is installed with Exchange Server and provides services for Outlook on the web, previously known as Outlook Web Access (OWA), Outlook Anywhere, ActiveSync, Exchange Web Services, Exchange Control Panel (ECP), the Offline Address Book (OAB) and AutoDiscover.
According to Microsoft, these vulnerabilities were first exploited by HAFNIUM, a Chinese government sponsored APT (Advanced Persistent Threat) but operating out of China. This group is known to install the web shell named China Chopper. As of 12th March 2021, at least 9 other hacker groups exploited these vulnerabilities apart from HAFNIUM.  The versions of Exchange Servers vulnerable to these vulnerabilities are,                   

Exchange Server 2019 < 15.02.0792.010                   
Exchange Server 2019 < 15.02.0721.013                   
Exchange Server 2016 < 15.01.2106.013                   
Exchange Server 2013 < 15.00.1497.012

The exploit is named Proxy Logon as it exploits the proxy architecture and login mechanism in the Exchange Server.

How to detect ProxyLogon vulnerability?

Metasploit has some modules related to these vulnerabilities. Let’s have a look at these modules.

The auxiliary/gather/exchange_proxylogon_collector module exploits the CVE-2021-26855 vulnerability and dumps all the contents of the mailboxes.

The exploit/windows/http/exchange_proxylogon_rce module exploits the CVE-2021-26855 vulnerability to bypass authentication and gain admin access and then writes a arbitrary file to the target using CVE-2021-27065 to achieve remote code execution.  All the above mentioned versions are vulnerable by default.

The auxiliary/scanner/http/exchange_proxylogon module checks for the CVE-2021-26855 vulnerability that makes Exchange Servers vulnerable.

Microsoft has released a security update on March 2021 to patch these vulnerabilities in Exchange Server versions mentioned above. Applying these patches will fix these vulnerabilities. As soon as Microsoft released these security updates, hacker groups around the world went on a scanning spree to hunt for unpatched Exchange Servers.

As there was a delay in applying patches, Microsoft also released a one-click mitigation tool that fixed these vulnerabilities in Exchange Servers. Microsoft has also noted that this tool named Microsoft Exchange On-Premises Mitigation Tool (EOMT) is helpful for those organizations that don’t have a dedicated IT security staff. This tool also includes the Microsoft Safety Scanner and an URL Rewrite mitigation for CVE-2021-26855. However, it stressed that this tool was not an alternative for applying the released security patches.

Posted on by

Spring4Shell : Explained With POC

Hello, aspiring Ethical Hackers. In this article you will learn about Spring4shell, a new zero-day vulnerability that has been discovered in Spring Framework. Spring Framework is an open-source application framework for Java and is normally deployed with Apache Tomcat servers.

Vulnerability & Impact

There are two vulnerabilities affecting Spring Framework, one is in Spring Core and second is in Spring Cloud. The Spring Core RCE vulnerability impacts Java class objects.  The vulnerability in Spring Core has been given name Spring4shell in the lines of Log4shell as both vulnerabilities affect a library. Although, it took its name from Log4shell, it is not as dangerous as its namesake.

This vulnerability affects all versions of Spring Core Framework running on JDK versions 9 and after. This vulnerability is tracked as CVE-2022-22965. There is another RCE in Spring Cloud Function versions <=3.1.6 and <=3.2.2.

Proof Of Concept

It’s time to see the exploitation of Spring4shell practically. Let’s create a new directory named spring4shell.

Clone the repository shown in the image below. This repository contains both vulnerable docker image and exploit.

Build the Docker image vulnerable to spring4shell as shown below.

You can check if the target is set or not by visiting the URL in browser.

If you get the above message, the target is ready. Run the exploit. The python exploit uploads a java web shell on the target after exploiting vulnerability.

The exploit completed successfully. The web shell can be accessed at above highlighted address.

The POC is succesful,

Posted on by

Shellcode Injection into Windows Binaries

Hello aspiring Ethical Hackers. In this article, we will see how to perform Shellcode Injection into Windows executables. In hacking, Shellcode is a code usually written in machine language instructions that starts a command shell from which a hacker can control the compromised machine. Shellcode is normally used as a payload.

Windows  binaries are those binaries that are already present by default on a Windows system. Just imagine you are pen testing a Windows machine and you want to gain access to it without bringing any third party Malware to the target system. How about using the files already present on the target system to execute your payload. This is also known as file less malware.

Windows by default has some binaries for its own genuine functions. However these can be utilized by malicious actors to execute their own payload which is not benign. Examples of these binaries are regsrvr32.exe, notepad.exe, calc.exe and rundll32.exe etc. Rundll32.exe is a binary used in Windows to link library for other Windows applications. Of course, readers know about Notepad and Calculator.

In this article, we will see how to inject shellcode into these Windows executables. For this, we will be using a tool named CactusTorch. CactusTorch  is a shellcode launcher tool that can be used to launch 32 bit shellcode which can then be injected into any Windows binaries.

Let’s see how this tool works. CactusTorch can be cloned from GitHub as shown below from here.

Once the repository is cloned successfully, we need to create shellcode. Cactus torch is compatible with Metasploit and Cobalt strike. So let’s use msfvenom to create 32 bit shellcode.

The shellcode is successfully created and is stored in payload.bin file.

Next, encode this payload using base64 encoding as shown below.

This shellcode can be hosted in different formats as shown below. These formats are already provided by Cactustorch.

Let’s see the example of hta file. Open the cactustorch.hta file using any text editor.

We can specify the binary you want to inject this shellcode into. For example, here we want to inject shellcode into rundll32.exe. Copy the base64 encoded shellcode at  “Dim code”. Save the file. Start a Metasploit listener as shown below.

Next, all we have to do is make the user on target system execute the cactus torch.hta file. This can be done using social engineering. Now once someone clicks on it, we should get a successful meterpreter session as shown below.

Similarly, this shellcode can be hosted in JavaScript and also VB script and VBA files. That’s how shellcode injection can be performed in Windows binaries.

Posted on by

Buffer Overflow for Beginners : Part 2

Hello aspiring Ethical Hackers. In Part 2 of Buffer Overflow foe beginners, we will see how to write an exploit for a buffer overflow vulnerability. In Part 1 of this article, readers have learnt practically as to what buffer overflow is and how a buffer overflow vulnerability can be identified in a program using fuzzing. Our readers have also seen how we exploited it.
But manually fuzzing the program can be tiresome sometimes. In the example we have shown in the previous article, the buffer only needed 32 characters to be overflown but what if the buffer has a very large (let’s say 1000) size. Manual fuzzing in such cases becomes a tiresome process.

We need some automation and simplification. It’s time to introduce PEDA. PEDA is a Python Exploit Development Assistance for GNU Debugger. It enhances the functionality of the GNU Debugger by displaying disassembly codes, `registers and memory information during debugging. It also allows users to create a random pattern within the gdb console and also find the offset etc. We will learn more about the tool practically. This tool can be installed as shown below.

Now let’s go into our C lab and load the program “second” with GDB normally as shown below. This is the same program we have used in Part1 of this article. As the program loads, you will see that the interface now shows “gdb-peda” instead of just “gdb” as in the previous article.

Let us test this program once again for the buffer overflow vulnerability. Here’s the disassembled code of the program “second”.

Let’s create a string of random characters of a specific length, say 50. This can be done using the “pattern_create” command in peda. Copy the random string.

Now let’s run the program. When it prompts you the question, “Name which superhero you want to be”, paste the string we just copied and click on “Enter”. Gdb-peda gives us information about the memory registers as shown below.

It also shows us the code being executed but the most important thing it shows is the memory stack.

If you observe the stack of the program above, you can see that the string of random characters we provided as input is allocated into two memory areas. The highlighted part went into first buffer and the rest of the random characters went into the second memory area.

Instead of counting how many characters are in the first memory area, we can find the number of characters using “pattern_offset” command. We copy the random characters that went into the first buffer and use it as shown below to find the offset.

We call it as offset as we need to fill this area with random characters as no code will be executed in this offset area (as in the Part 1 of this article). The offset is 32. Well, since we no- w know the offset, let’s write an exploit for this vulnerable program. Open a new file and write the exploit as shown below.

This is a simple python exploit and the comments should explain you what it does. Let us give you more information about it. The first line of the code is basically telling the exploit to launch a python interpreter. In the second and third line, we are importing pwntools and OS modules respectively. The pwntools library has all the functions needed in penetration testing and OS module has operating system functions. In the next line we declare a variable named “path” and assign it a function os.getcwd() . This function gets the current working directory (If the OS module is not imported, this line will not work).

In the next line, another variable is declared with the name “program” and we assign it the program we want this exploit to target. As our target program is named “second” we give that name. In the next line, the “full_path” variable combines both the “path” and “program” variables to get the full working path of the program. Till this part of the code, we have reached the program we want to exploit.

Now the exploitation part. The “fill_buffer” variable fills the offset area with 32 iterations of “C” (It can be any character of your choice, but make sure its 32 for this program). In the next line we are specifying the command to be executed after the buffer is filled. Here its is “whoami”.

The exploit only works when the buffer is filled and then the command is executed. So we need to combine the “fill_buffer” and “cmd” results. The process() command start the target program while the p.sendline(bof) command sends the output of “bof” to the program already started. The p.interactive() gives the user the control after the exploit runs. Once coding is finished, save the exploit with any name you want. We named it bof1.py. Then run it as shown.

As you can see in the above image, after filling the buffer the exploit was successful in executing the command “whoami”. Now change the command to be executed and run the exploit again.

Once again it runs successfully and executes the command. This gives us a shell. This is how buffer overflow exploits are written.

When most of our readers ask as to which programming language to start learning with in the journey of ethical hacking or penetration testing, Our suggestion is always python and yo -u now know why? Python is very simple but still effective. It has a readable and easily maintainable code compared to other programming languages. Hence, it is very easy to learn. In just about ten lines, you have written the first buffer overflow exploit although its for a intentionally vulnerable program.