Discovering Hidden Email Gateways with OSINT Techniques

In this article, we elaborate how we managed to identify hidden internal email gateways by relying on various open-source intelligence (OSINT) data sources for our direct email spool attack research.

This is a multi-part article. In Part 1., we revealed how big law firms in Australia are susceptible to direct email spool attacks and what the implications were. In a nutshell, we found that email security solutions at one-third of the law firms assessed can be circumvented with a simple trick. Part 3. elaborates the configuration settings of the Postfix mail server we used for the research.

Prerequisites of the Direct Email Spool Attack

Normally, direct email spool attacks should not work as the major email security solution vendors advise customers to lock down their local email services and publish network ranges belonging to their service to enable administrators to lock down local email services. Local email servers should only accept emails from the upstream email security solution.

As the diagram shows, the list of requirements to carry out a successful direct email spool attack is relatively short. We only need three things:

• The hostname of the local email server running behind the email security solution;
• An email server feeding the emails directly to the local email server by ignoring the MX records; and
• A misconfigured local email server accepting emails from other servers than the upstream email security solution.

In order to assess whether an organisation is susceptible to direct email spool attacks, we have to attempt to get around the email security solution (as specified by the MX record) and deliver emails straight to the local email server.

The workflow of the assessment was also simple:

1. Set up and configure a remote email server to deliver emails to arbitrary destinations specified by the mail transport rules (i.e. the remote email server on the diagram);
2. Identify the hostname of the local email server by relying on various OSINT techniques (this article details some of them);
3. Update the mail transport rules on the sending remote email server;
4. Write and send an email through the remote email server. If the email is delivered to the recipient, it is likely the local email server is vulnerable to the direct email spool attack.

How We Managed to Discover Vulnerable Email Gateways

In our research, we relied on a combination of open data sources to identify the hostname of the relevant local email server running behind the email security solution at the organisations in-scope. Email administrators may think that by changing the MX records of the email service, bad actors will not be able to identify the connection details of the local email server.

This is far from the truth, however, as various clues are available in public datasets that can reveal the hostname of the local email server running behind the email security solution.

DNS Historical Data

One of the data sources we found the most valuable to identify local email servers was passive DNS historical data. Services like Farsight DNSDB and SecurityTrails let us look up what the DNS MX records of the assessed organisation were before the email administrators swapped the records with the details of the email security solution. As these services keep the DNS details for several years, we could go back in time as far as 2010 to look up the records.

For example, the British bank Barclays owns the domain name barclayssurveys.com, which was used for email marketing purposes at one point. Although the current MX host points to Mimecast (an email security solution), the hostname of the local email service was `mailhost1.chimegroup.com` between 2017 and 2018.

Indeed, the email service is still accepting connections over the internet:

Assuming the email server accepting mail from the upstream Mimecast service has not changed, mailhost1.chimegroup.com could potentially deliver emails to staff at Barclays.

Subdomain Lookup Services

The second most useful service was a DNS lookup service called DNSdumpster, which let us identify hard to find local email servers with more obscure subdomains than mail.mycompany.com.au. The service is a domain research tool that uses open source intelligence resources to discover domain data.

For example, the bank Westpac seems to be running multiple email servers:

Virustotal can also list the associated subdomains of Westpac:

Other OSINT subdomain search engines are also available such as FindSubdomains or Hacker Target.

Making an Educated Guess

The third method we heavily relied on was guessing. According to our in-house experience, the vast majority of legal practices are hosting their email service at Microsoft. Interestingly, Office 365 tenancies have a naming convention that helped us find the MX host of the backend server.

Every Office 365 tenancy has an organisation name that is prepended to the domain name .onmicrosoft.com. If an organisation has registered an Office 365 account, the DNS query of ORG.onmicrosoft.com should retrieve the hostname of the tenancy’s email server.

For example, the MX record of apple.onmicrosoft.com indicates that an organisation has an Office 365 account and the email server is available on apple.mail.protection.outlook.com.

The second way to guess whether an organisation is an Office 365 user is trying to establish a network connection to the assumed MX host at Microsoft. For example, if the organisation’s domain name is apple.com, the hostname of the MX host should be apple-com.mail.protection.outlook.com. We could easily test with netcat whether a tenancy exists on the hostname by attempting to connect to the TCP port 25.

Although we did not identify any law firms using G Suite for email hosting, guessing would also work with organisations with a Google subscription. As the primary MX host of every G Suite tenancy is ASPMX.L.GOOGLE.COM regardless of the name of the organisation, it always worth an attempt to deliver emails through G Suite if the other OSINT techniques fail.

SPF Record Entries

We have managed to identify potential candidates by inspecting the public SPF record. Although we rarely managed to determine the actual local email server with this method, we found IP addresses and hostnames of CRM systems and marketing automation platforms. If any of the hosts have an SMTP service running on them, emails fed into these hosts may end up in someone’s mailbox in unexpected ways.

Services like MXToolbox can look up the SPF record of an organisation:

For example, Santander Bank (UK) uses a third-party talent acquisition platform for hiring. Emails sent through this SMTP server may end up in the mailbox of the bank’s HR personnel.

Special Search Engines

Services like Censys and crt.sh Certificate Search also helped us to find potential email servers.

Censys is a search engine helping to find and analyse every reachable server and device on the Internet. Crt.sh is a web frontend for the distributed database called the certificate transparency logs.

With just a few simple search operators on Censys, we were able to identify the hostname of potential local email servers with port tcp/25 open at this particular organisation.

We could identify potential subdomains on crt.sh by searching for hosts with keywords like *mail*, *exch* (as in Microsoft Exchange), *mta* or *smtp* in them. These subdomains are potentially pointing to email servers accepting emails for the organisation.

Email servers on the internet are difficult to hide even when the connection details are not featuring in the MX records. As the various OSINT techniques demonstrate, traces are left everywhere allowing bad actors to identify the email server is running in the backend.

First of all, we suggest email administrators locking down the local email servers to prevent abuse instead of hiding them from plain sight with the hope that nobody will discover them.

Secondly, email security is a complex matter, and as a result, organisations frequently leave their local email servers wide-open for cybercriminals. This oversight leaves organisations susceptible to phishing attacks as our latest report on direct email spool attacks demonstrates. Also, considering the rising number of Business Email Compromise (BEC) fraud, we urge you to assess the security of your email gateways to prevent abuse.

This article was co-written by Gabor Szathmari and Nicholas Kavadias.