Archives for October 2020

Enhancing Email Security 101


While imitation may be the sincerest form of flattery, email impersonation and spoofing has proven to be a serious risk to organisations and their staff.

An email sent from an attacker that is convincing enough to fool the recipient into believing it is legitimate can have major consequences to the security of organisation’s infrastructure, as well as the data they possess. All it can take is one email carrying a document containing malicious code for an attacker to gain a foothold into a network (see our blog on Ryuk Ransomware for more information). As a result, email security is paramount when designing robust security controls. This guidance document will take a high-level look at three core controls areas, Sender Policy Framework, DomainKeys Identified Mail and Domain-based Message Authentication, Reporting and Conformance. Links to Microsoft and Google configuration guidance is included at the end of this document. 

Email 101

Email works in a way akin to traditional physical mail. the email server sends a message to the recipient address containing an array of data, most notably the sender user and domain, recipient and the message body. One significant flaw within the email process is due to the server or client receiving the email typically trusting the validity and authenticity of both the sender and the information received without question and handling it accordingly. No matter the sending mail server, all mail servers are treated equally. In reality, it can be a fairly trivial process for an attacker to host their own malicious mail server designed to spoof email content and sender details. To address this risk, there are a number of additional controls that can be utilised to enhance email security. 

Sender Policy Framework (SPF)

Sender Policy Framework is a method used to verify that an email is coming from a server authorised to send mail on behalf of the domain. This is achieved through use of DNS records which are publicly accessible tables regarding a domain which link domains and IP addresses for routing. SPF can be added to the DNS records of a domain which then provides a publicly accessible list of the authorised places where email can come from. This list is then checked once the recipient email server receives a message. The receiving mail server cross references the DNS records from ‘’ and the sending IP address that the email originated from in order to determine if the IP is on the list of authorised senders. If yes, then the email proceeds to the regular inbox. If the sending IP is not listed on the SPF DNS records, then it is used as a spam indicator.

While SPF is not a bulletproof solution as it only verifies servers used to send emails not user accounts it does typically enhance mail security and is one of the easier headers to implement properly.

DomainKeys Identified Mail (DKIM)

One area that SPF is not intended to provide assurance of is the integrity and authenticity of the contents of the email’s sender and message. This is of particular concern in the event that the message can be intercepted and modified in transit between the sender and recipient. To guard against this, a standard was developed known as DomainKeys Identified Mail (DKIM) it employs public-key cryptography to generate a hash value which is then signed using a private key, this is then appended as a header value to the email together with a number of other values needed for DKIM (such as information needed to retrieve a public key from DNS).

Upon receipt of the email, the recipient can use the corresponding public key (obtained from the sending domains DNS) to validate the hash value received. The recipient server will then it will generate its own hash value to compare against the received hash value to validate the email.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Domain-based Message Authentication, Reporting and Conformance (DMARC) is a method used to inform mail recipient servers of what should happen to an email if SPF and/or DKIM fail to validate. This removes the need for the recipient to make a judgement call (i.e Gmail will not mark an email as SPAM just because it fails SPF, without DMARC telling them to), providing further protection against phishing and other business email compromise attacks.

A DNS record entry is published by the sender containing instructions that typically include if SPF/DKIM should be validated and if so to what level. It will also tell the recipient what to do if either fail validation. Typically this may lead to emails that failed authentication being quarantined automatically or deleted but it’s possible to also request that failures are reported back to a business making it possible to evaluate if a failure is down to a technical problem or someone trying to spoof emails from the domain. 

A Layered Approach

While any of these measures can be used in isolation or combination, using all three measures provides a defence in depth approach to email security that can assist with protecting against many common attack vectors. Most enterprise email service providers offer their ow client or resource to implement and configure email security records and DMARC rulesets. Their tools will typically allow you to generate a domain key, associate the public key with the mail server’s DNS record and apply the relevant ruleset to the record for all outbound messages.


Out of the box, email and especially cloud based email services require additional hardening to protect against common attacks (such as spoofing). This guidance document has introduced at a high-level three core control areas that as individual components, combined or all together can provide a more robust email security posture. However, they are by no means a guarantee that future security vulnerabilities wont find away to work around those controls and result in trivial email spoofing. As such, a more in-depth approach to email security is required, and one that takes into account both technical controls such as those discussed, along with multi-factor authentication, and combine with more human elements such as phishing awareness training.

Platform Specific Links

Microsoft O365:






Phish and Clicks

7 Elements have been assisting businesses in investigating cybersecurity incidents for over 10 years. We’ve seen a significant increase in phishing incidentsover the last 6 months, mostly as a direct result of the increased use of remote services such as Zoom and Microsoft Teams. 

The increased use of these services results in the perfect environment for phishing, since their legitimate emails often include links requesting users to log in or even to install applications. Attackers have been exploiting this trained behaviour by sending phishing emails that closely match these legitimate emails, requesting passwords or instructing victims to install malware.  

This blog uses an example phishing email, claiming to contain a link to Zoom meetingto demonstrate how to spot a fraudulent email. We’ll also take a closer look at what exactly happens when a user clicks on the link inside it. 

screenshot of a recent phishing email
Screenshot of a recent phishing email

Tell-Tale Signs: How to Catch a Phish 

So, how can we tell that the email in question is fraudulent? To begin with, there are a couple of things that simply don’t look quite right. 

For starters, regular Zoom users may know that Zoom emails typically contain the meeting ID and details of who the meeting is from, whereas this email is much more generic. Or, we may notice that the blue “Zoom” text doesn’t match Zoom’s usual branding. Their real logo uses a different font and is all lower case: 

zoom brand
Zoom logo

Also, while the sender’s address does appear to contain the word “zoom”, the very last part (called the domain) is actually “”:

Image showing from address
Screenshot showing the sending email address

This is odd, since Zoom typically uses the domains and Of course, we may not always know where legitimate emails from a given company should come from. However, if the sender’s domain is different to what we would expect to type into a browser to visit their website, it’s worth being suspicious.

We do need to bear in mind that it’s often possible for attackers to “spoof” emails, meaning they can make them appear as though they actually did come from, or another legitimate address. Also, other attackers are better at copying the branding and email content of the real company. So, just because these things look good in an email, it doesn’t necessarily mean the email is legitimate. But if one or both of these things looks off, it’s a red flag.

So, how can we be sure? The crucial thing is the link which the email contains, since this is where the email is actually trying to get us to go. Rather than clicking on the link, we can hover over it with our mouse pointer to reveal where it goes:

screenshot showing the destination link
Screenshot showing the destination of the link

On mobile phones, this can usually be done by long pressing on the link until a pop-up appears.

In this case, we can see that the link begins with “”. While we may not recognise the address that’s used here, it doesn’t appear to be related to Zoom. We can confirm this by entering “” into a search engine – when we do, none of the results have anything to do with Zoom. If performing this check, be sure to visit the search engine’s website and enter the suspicious domain into their search bar. Don’t enter it directly into your browser’s address bar to perform the search. While the browser’s address bar can be used for typical searches, if a domain is entered you will actually be taken there – and in this case, there’s a good chance the webpage will be malicious.

Sometimes attackers may use an address here which does resemble the name of the company, similar to the “” which we saw earlier. But if the address in this link isn’t one which we know is legitimate, e.g. “”, we shouldn’t click on it.

If we’re concerned that something needs our attention, e.g. if the email claims that we’ve been locked out of our PayPal account or that we owe HMRC more money than usual, the best thing to do is to access the website or contact the organisation in question directly using a method which we trust. For the previous examples, that would mean visiting PayPal through a bookmark or trusted link, or phoning HMRC on the telephone number published on their official website. You can then find out from the website or member of staff whether the content of the suspicious email is legitimate.

A Closer Look

Let’s look more closely at the malicious link contained in the email, to see what happens when a victim clicks on it. This section is written from a more technical perspective.

The link is:,d7623c,1ac8b&

So, the email is pointing potential victims to a host on – a legitimate domain, belonging to the RAC breakdown cover and insurance company. The attacker appears to be taking advantage of the fact that a service hosted on an RAC subdomain contains an open redirect1. This is a type of web application vulnerability which allows attackers to direct victims to a malicious website via a link that begins with the address of a legitimate company. In this case, the address which the attacker is redirecting victims to is the section in red:,d7623c,1ac8b&

We can confirm this by replacing the red section with our own website’s address:,d7623c,1ac8b&

As expected, clicking this link takes us to the 7 Elements website. This is done by a simple HTTP 302 redirect from the RAC website.

Example of an Open Redirect

Let’s see what happens when we actually click the link in the attacker’s email. Our browser is redirected from to the address, and sends a request to that server. The server responds with an HTTP 404 page which contains a JavaScript redirect to the location in red:

HTTP/1.1 404 Not Found
<<HTTP headers removed>>
Link: <>; rel=""
<<HTTP headers removed>>
Content-Type: text/html; charset=UTF-8

<script type="text/javascript">window.location.href = ""</script>

Our browser is automatically redirected once again to this new link, which is hosted in Azure, and we’re presented with a fake Microsoft 365 login page asking the victim to “sign in to Zoom with your Microsoft 365 account”. The use of Azure in order to host this page on a “” URL gives the page some appearance of legitimacy:

Screenshot of a fake login page
Screenshot showing a fake login page

Zoom doesn’t actually appear to allow signing in with a Microsoft ID currently, but the creator of this phishing page seems to have opted to run the risk of arousing suspicions through this request in order to capture Microsoft passwords rather than Zoom passwords. This is presumably because a Microsoft ID will potentially grant the attacker access to the victim’s personal or business email account. Email accounts are more valuable to an attacker than Zoom credentials, since they typically contain greater amounts of sensitive information and can often be used to reset the victim’s password for other websites. In the case of a business account being compromised, information found in the victim’s emails and calendar can then be used for further attacks against the business.

The victim’s email address is pre-filled in the login form above. This is tied to the link in the attacker’s email – for each phishing email that the attacker sends, the recipient’s email address is embedded in that email’s link. This means each potential target receives a unique link, tied to their email address. This allows the attacker to see who has clicked on their link, and also helps to make the login page more convincing – when the victim sees a login form with their email address pre-filled, it seems as though it’s a website they’ve used before.

The email address is Base64 encoded before being embedded in the phishing link. In our example, the encoded email address is the section in red:,d7623c,1ac8b&

This string (“Ym9iQGJvYi5jb20=”) decodes to “”, the address which is also seen in the fake login page above. When we received this phishing email, the Base64-encoded section of the link contained the actual email address of the recipient – this has just been changed to “” as an example for this blog. Interestingly, when we attempt to use the link with the email address completely removed or with a Base64-encoded value of “”, the link redirects us to the legitimate Zoom website. This appears to be an attempt to hide the fact that the link is being used for phishing, and potentially also to stop the attacker from receiving submissions for known invalid email addresses.

When we submit a dummy password to the fake login page, we receive an error message telling us that we entered an incorrect password:

Response to incorrect password
Screenshot showing response to incorrect credentials

Behind the scenes, the user’s password is submitted to a PHP script hosted on each time the user attempts to log in:

POST /mp.php HTTP/1.1
<<HTTP headers removed>>!

The server at responds with the following:

HTTP/1.1 200 OK
<<HTTP headers removed>>

Or, when no password was entered, it responds with:

HTTP/1.1 200 OK
<<HTTP headers removed>>

This may be a clue as to the origin of the phishing attempt, or at least the author of the phishing kit being used – “kosong” means “empty” in Indonesian, while “gagal” means “failed”.

These responses tell our fake login page what message to display to the victim who has just entered their password. Let’s take a closer look at the login page:

Azure hosted phishing site
Screenshot showing an Azure hosted phishing site

The script has been obfuscated, but we can simply run it through an online JavaScript deobfuscator. When we do that, we can see the code which tells the login page present the “sign in failed” message when the server responds with GAGAL:

source code 1
Screenshot showing the clear text code

A similar if statement exists for the KOSONG (no password entered) response. Interestingly, we noticed that the page has also been coded to handle responses of “VALID”. As shown in the following screenshot, then this response is received the login page will redirect the user to the legitimate Zoom website. Before redirecting, the “Finish” class which is referenced will display the message “This video conferencing has been cancelled. You will be redirected to Zoom”.

source code 2
Screenshot showing further code

We created a new Microsoft ID and entered its credentials into the fake login page, to see whether the attacker’s script was attempting to use the credentials and would respond VALID if it was successful. The server responded with GAGAL as before. We then entered credentials for our Office365 honeypot. This time, the credentials were verified by the phishing server and we received the “cancellation” message followed by a redirect to

Cancellation Message
Screenshot showing the cancelled meeting message

We suspect the reason that only our Office 365 honeypot credentials were successful here was the fact that we have legacy authentication enabled on our honeypot. Legacy authentication doesn’t use MFA and is likely what the phishing script uses to verify the credentials that are submitted. It’s worth noting that legacy authentication can be used to bypass MFA in tenancies which support it, even if they also have modern authentication enabled ( – so disabling legacy authentication wherever possible is highly recommended.


Despite the initial email not being the most convincing, the fake login page which it linked to was much more sophisticated. The phishing chain makes use of an open redirect vulnerability within a legitimate service, leverages Microsoft’s own hosting and involves two compromised web sites. The Microsoft 365 branding was well imitated, and the attacker’s script even checks to see whether the credentials are valid. As well as helping the attacker to filter out submissions which they can’t use, this also makes the page appear more genuine to victims. Users who mistype their password the first time will be prompted to try again, before receiving a different message when they enter the correct password, just like the real thing.

It’s easy to see how a victim could give away their password without even noticing. Learning to spot the tell-tale signs is an important defence for users – and we can’t finish without a reminder to enable MFA and disable legacy authentication!


7 Elements worked with the RAC Group to ensure that the open redirect detailed in this report was resolved prior to publication.