Posted on

Heartbleed vulnerability explained

Hello, aspiring Ethical Hackers. In this blogpost, you will learn about Heartbleed vulnerability. This bug was publicly disclosed in 2014 and is rated as one of the most critical security vulnerabilities of the last decade.

What is Heartbleed bug?

Heartbleed is a buffer overread vulnerability that exists in an implementation of an extension in OpenSSL cryptography library. This OpenSSL library is widely used in Transport Layer Security (TLS) protocol. The name of the extension which is used in this OpenSSL library is heartbeat. Hence the name of the bug. Heartbleed can be exploited even if vulnerable OpenSSL is not running as a TLS server or client. In a buffer-over-read vulnerability, more data can be read than usually allowed. See how SSL/TLS works. By exploiting this vulnerability, the private key of the SSL certificate can be read.

Practical Walkthrough

Let’s see how this works. For demonstrating this, I will be using a Vulhub lab to setup a vulnerable instance of heartbleed as shown below.

Once the vulnerable instance is ready, I start Metasploit & load the heartbleed module.

I set the IP address and execute the module.

The module is by default set to scan for the vulnerability and it does exactly that. Apart from this action, this module has other actions.

For example, the “dump” action dumps the content of the memory.

When we set the action to “key”, the private key of the SSL server gets dumped.

Real World Examples

At the time of public disclosure of heartbleed, almost 17% of total web servers were found vulnerable to heartbleed, including Google, Yahoo, DropBox, Facebook etc. Here are some Real-world examples of the exploitation of the heartbleed bug.


Mumsnet is a parenting site in United Kingdom. Cyber thieves have obtained passwords and personal messages from Mumsnet by exploiting heatbleed in 2014. Mumsnet has over 1.5 million registered members and there is no idea how many details got hacked.

Canada Revenue Agency:

Social Insurance members of over 900 taxpayers were stolen from Canada Revenue Agency by exploiting heartbleed bug within a 6 hours period on 8 April 2014.

Mitigation and Prevention

The bug was fixed by updating to the latest version of OpenSSL version 1.0.1-9. This version adds bounds check to prevent buffer over read.

Posted on

Log4shell Explained For Beginners

Hello aspiring Ethical Hackers. In this article you will learn about the Log4shell vulnerability and why it is dangerous. According to Wiz and EY, this vulnerability affects over 93% of the total enterprise cloud environments. At the time of writing this article, Year 2022 has seen over a billion log4shell exploitation attempts.

The software that is affected by this vulnerability includes Apache Camel, Apache Druid, Apache Flink, Apache Solr, Apache struts2, Apache Tomcat, Elastic Search, Atllasian Bitbucket, almost all software of Avaya, some software of Cisco, Citrix,Cloudera, Dell, F-Secure, Hitachi Energy, HP, IBM, Intel, Lenovo, McAfee, Microsoft, MongoDB, Netapp, Neo4j (OMG, we just installed it in last Issue), Nulab, Oracle, Palantir, Palo -Alto, PaperCut, Rapid7, RedHat, Salesforce, Schneider Electric, Securonix, Siemens, SolarWinds, Sophos, Splunk, Thales, Varian, VMWare, Xylem, and Zendesk etc. The commercial services that are vulnerable to log4shell include Amazon Web Services, Cloudflare, iCloud, Minecraft: Java Edition, Steam and Tencent QQ.

If you read the above list of software vulnerable to log4shell, you will understand why it is given CVSS rating of 10.

What is Log4j or Log4shell vulnerability?

Log4j is actually an open source logging framework written in Java that software developers use to log or record data in their applications. The data that is logged can also include user input. For example, most web servers use logging. When you try to access a login webpage, apart from displaying you that webpage the server can create a record of your visit. Log4j was written in 2001 by Ceki Gülcü and now is part of Apache Logging Services which is a project of the Apache Software Foundation.

There is a feature in Log4j that allows remote users to specify custom code for formatting a log message. However, this feature can also be used to execute code on the target remotely by submitting it from a third party server. This allows a remote attacker to even take complete control of the target.

Enough theory, Let’s see it practically. For this, first we need a target. We have setup a vulnerable Docker container which we downloaded from here. This container can be started as shown below.

Once the container is up and running, check it’s IP address as shown below.

The target IP address is Now let’s set up the Attacker system. We have setup a new directory named log4shell to store all files belonging to log4shell.


We have downloaded a Java exploit to exploit log4j from here.

After extracting the contents of the zip archive, we navigate into the extracted directory to find the exploit. The command to run this exploit is given as shown below.

In the place of “your-private-ip”, we need to enter the attacker IP address ( Now, what does this exploit do? It starts a fake LDAP server and HTTP server as shown below.

The fake LDAP server is the third party server we need. Next, we need to trigger the exploit. Open a new terminal and run the command as shown below.

In the above command we are starting with curl, you can see “$(jndi)”. JNDI stands for Java Naming and Directory Interface and it is used for lookup of Java objects during program runtime. JNDI can interact with several directory interfaces which provide different scheme of files lookup.

One among them is the Lightweight Directory Access Protocol (LDAP). LDAP is a non-Java-specific protocol that can retrieve the object data as a URL which can be either local or remote. JNDI can be used to load data at an URL as Java object data by utilizing LDAP.

By specifying ${jndi:ldap://…..Ao=}, we are asking JNDI to use LDAP to query the URL and load the data there as Java object data. Well, what does the exploit do? As soon as we trigger the exploit, switch to the terminal on which our fake LDAP server is running.

It received a LDAP query and executed a command. It created a new file named “pwned” in the /tmp directory of the target (since that is what the exploit is programmed to do). Let’s check if the new file is created or not. This can be done as shown below.

All good, but what is “X-Api-version” we used while triggering the exploit? That’s a HTTP header. As soon as we trigger the exploit, it will query the fake malicious LDAP server and it is inputting a string that is logged to the target (-H and then loading the malicious code (In this case, creating a new file on target). That’s how Log4jshell exploit works.

Posted on

EternalBlue vulnerability: Explained with POC

Hello, aspiring Ethical Hackers. In this article, you will learn about the infamous EternalBlue vulnerability and its exploitation.

Vulnerability & Impact

Exploited by Wannacry ransomware, the EternalBlue vulnerability exists in the Server Message Block (SMB) protocol. Due to improper handling of specially crafted packets by SMB version 1 (SMBV1) of Microsoft windows this vulnerability allows attackers to execute malicious code on the vulnerable systems. This vulnerability affects Microsoft Windows versions Windows Vista, Windows 7, Windows 8.1, Windows 10, Windows Server 2008, Windows Server 2012, Windows XP, Windows 8 and Windows Server 2003. This vulnerability was observed being exploited as recently as 2020.

Proof Of Concept

As the vulnerability is so famous (I mean infamous), Metasploit has already released exploit modules for this particular vulnerability.

We are going to test some of these modules on a Windows 7 target. Let’s first use the scanner module of metasploit to test whether this machine is vulnerable to EternalBlue vulnerability.

Set the RHOSTS option and execute the module.

The scanner module confirms that the target is indeed vulnerable. Now, let’s load the module for exploiting Eternal Blue vulnerability and grab a session.

Set all the required options and use “check” command to see if the target is indeed vulnerable.

After all the required options are set, execute the module.


As you can see, we got a meterpreter session on the target system and that too with SYSTEM privileges.

Posted on

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,


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.


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

Follina : Explained with POC

Hello aspiring Ethical Hackers. In this article, readers will learn about Follina, the latest Zero-Day vulnerability in Microsoft.

Vulnerability & Impact

Follina is the name given to a remote code execution (RCE) vulnerability in the Microsoft Support Diagnostic Tool (MSDT). This vulnerability allows a remote attacker to use a Microsoft Office document template to execute code via MSDT and download a malicious payload from a remote URL. It affects Office 2013, 2016, 2019, 2021, Office ProPlus and Office 365.

What actually is Follina?

Follina is a municipality that is located 60 kms northwest of Venice in Italy. Completely unrelated, the vulnerability has been named Follina as the malicious file was referencing to an executable that was named 0438. This is the area code of Follina, hence the zero-day has been named so.

What is MSDT?

Follina exploits MSDT but what is MSDT? Microsoft Support Diagnostic Tool (MSDT) is a service used for gathering diagnostic data about the system.

Proof Of Concept

Let’s see how to exploit Follina practically. For this let’s download a exploit from Github. Navigate into the cloned directory and you will files as shown below.

Two files are important in this directory. The “clickme.docx” is the file that uses MSDT to connect to a remote website and execute the exploit. The exploit is present in the “exploit.html” file. If this POC is successful, the exploit will popup calc.exe.

I tested this exploit on MS Office 2019 running on Windows 10. I hosted the exploit using Wamp server running on localhost.

I opened the clickme.doc and waited. Nothing happened. Then I saved it as clickme.rtf file as shown below.

This time when I clicked on clickme.rtf file, this happened,

And the calculator popped up. The Proof Of Concept Is Successful.