On March 2, 2021, Microsoft rolled out a patch for several vulnerabilities in their products. Amongst these are the now dubbed ProxyLogon—four vulnerabilities that have been used to target Microsoft Exchange servers since January. While patching these CVEs, Microsoft disclosed their existence to the public and since then, several opportunistic threat actors have been trying to take advantage of unpatched servers and exploit these vulnerabilities.

In this blog post, we will adopt the point of view of a CERT or red team analyst and illustrate how to investigate servers that have not yet been patched and thereby protect proprietary systems against attacks from malicious actors.

What is ProxyLogon? 🔗︎

The ProxyLogon vulnerabilities can be chained together to launch an attack which can lead, among other things, to data theft, server hijacking and remote code execution. The vulnerabilities include:

• CVE-2021-26855: Allows attackers to authenticate themselves
• CVE-2021-26857: Related to code execution
• CVE-2021-26858 and CVE-2021-27065: Allow authenticated attackers to write file anywhere on the system.

They impact Microsoft Exchange versions 2013, 2016 and 2019.

In the following two use cases, we will demonstrate how to explore these vulnerabilities using Maltego’s Shodan data integration.

Let’s dive right in.

Use Case 1: Picking out a Vulnerable Target 🔗︎

According to Palo Alto Networks, 125,000 servers around the word remained unpatched as of March 9, 2021. We will use Maltego to investigate systems affected by the aforementioned CVEs.

DEVCORE, the company that broke out some of the vulnerabilities patched on March 2, described CVE-2021-26855 as a possible first link for the chain of attack that is currently being used against Exchange servers around the world. Therefore, we will start by looking into this particular CVE.

Let us begin our investigation by adding a CVE Entity to our graph and running the To Vulnerable IP Addresses [Shodan] Transform on it to query Shodan for IP addresses that are vulnerable to this CVE.

The link analysis power of Maltego allows us to pivot to new data points by running Transforms from various data sources. This helps us focus on a particular area during an investigation. In our case, we will run various Transforms to gain helpful insights and narrow down the amount of potentially vulnerable IP addresses.

First, we take a look at the location of these IP addresses by using the To Location [country] Transform. 

By selecting all the IPv4Address Entities and running the To Services [Shodan] Transform and then checking the results, we get a good overview of the services run on the IP addresses.

As we observe in the image below, the List View allows us to identify the most common services found on our graph by sorting them by the number of incoming links. Without surprise, three of the most common services are Microsoft Exchange servers. Ports such as 25 and 993 are in the list, in line with our expectations, as they are used by email servers (Port 25 being for SMTP and 993 for IMAP over SSL).

Shodan can also provide us with the other CVEs linked to these IP addresses if we run the To Vulnerabilities [Shodan] Transform. By choosing the Ball Size by Links (incoming) Viewlet, we can highlight the most common CVEs (shown below in green). Selecting the Ball Size by Links (outgoing) Viewlet will highlight the IP addresses with the most CVEs attached (shown below in orange).

Use Case 2: Identifying Weak Points in An IP Netblock 🔗︎

For this use case, we will use Maltego to identify unpatched servers in an IP netblock. For security purposes, we will not be disclosing any key details about the target of this use case. This use case can be of great value to red teams as well as blue teams looking for weaknesses in their own network.

Singling Out the IP Addresses Vulnerable to ProxyLogon 🔗︎

To start off, we pull a Netblock Entity or CIDR Entity with our target IP range set onto our graph and run the To Vulnerable IP Addresses [Shodan] Transform. This will return all the IP addresses that Shodan deemed to be vulnerable to at least one CVE. Then, by selecting these IPv4Address Entities and running the To Vulnerabilities [Shodan] Transform, we can obtain the vulnerabilities to which these IP addresses are exposed. We now have a list of vulnerable IP addresses and the CVEs linked to them.

Notice how CVE Entities have a little colored dot—Entity Overlay—at the top left corner of the Entity node. These overlays indicate the CVSS score of the vulnerability, with green being the lowest (less dangerous) and red being the highest (most dangerous). Grey means no CVSS was returned by Shodan. This score considers several factors such as the impact a vulnerability has on a system when exploited, the complexity of an attack weaponizing it, the level of privilege required to launch such an attack, and several other factors. It allows us to quickly gain a comprehensive idea of a CVE’s severity. 

To move forward with our investigation, we will focus only the IP addresses vulnerable to ProxyLogon. We select the ProxyLogon vulnerabilities among the CVE Entities and click on the Add Parents button in the Investigate tab, which adds the relevant IP addresses to our Entity selection. We then isolate that selection by copying it to a new graph.

Gathering Information on the Vulnerable Servers 🔗︎

Before taking any steps toward these servers, we will first gather information to establish what they are used for and if they are worth investigating further.

The first step is to analyze the banners grabbed by Shodan. After selecting the IPv4Address Entities, we run the To Banners [Shodan] Transform to bring these banners to the graph. By double-clicking a Banner Entity and looking at the Properties tab in the Details window, we can view several pieces of information like the last time Shodan queried that banner, the port on which it was grabbed, and most importantly, the banner itself.

The banner text often contains valuable data such as the exact version of the software running on that server.

Another way to understand the services provided by a server is to check which DNS record points to its IP address. We can do this by using passive DNS Transforms.

Whereas “normal” DNS works by consulting a server to obtain the IP address associated with a domain name, passive DNS consists of a database of DNS requests made by others. This allows investigators to conduct the reverse operation and see which domains have been historically associated with a specific IP address. Several of our Hub Items such as RiskIQ PassiveTotal and Farsight allow you to query a passive DNS database in Maltego.

For this example, we will run the To DNS Name from passive DNS [Robtex] Transform, which is part of the Maltego Standard Transforms. Some DNS records like the one with the label “cas.” (often associated with the eponymous authentication server) give us an insight into the kind of services run by these servers and help us to complete our understanding of these servers’ functions.

We now have a list of servers vulnerable to ProxyLogon and we can decide which one to prioritize based on what they are used for. Be aware that passive DNS data is by nature historical data. A DNS record might have pointed to an IP address at one point and have moved since then. To confirm that the DNS record still points to this IP address, you can run the To IP Address [DNS] Transform.

Go Beyond ProxyLogon 🔗︎

To complete our investigation, we can also look at other interesting DNS records in the second-level domains (SLDs) that were returned by the passive DNS Transform.

First, we map the DNSName Entities to Domain Entities using the To Domain [DNS] Transform. From there, we can pivot to other DNS records under that SLD by running the To DNS Name [Using Name Schema dictionary] Transform. This Transform will search for subdomains generated using a dictionary of common terms. For example, if ran on the Domain Entity “abc[.]com”, it will search for domain such as “mail[.]abc[.]com” or “blog[.]abc[.]com.”

After running this Transform on both SLDs, we can look for interesting subdomains like the one with the label ”admin,” query their IP address using the To IP Address [DNS] Transform and use the To Vulnerabilities [Shodan] Transform to outline unpatched servers.

The investigation does not have to stop there, but we demonstrated some basic steps one can follow to explore and understand the vulnerability and risk landscape of a network.

We hope that this blog post got you excited about the possibilities offered by Maltego to reduce the cyber risk faced by your organization.

Don’t forget to sign up to our email newsletter and follow our Twitter and LinkedIn for more interesting walkthroughs, announcements and use cases.

Happy investigating!