Digging Deeper on Mailgun Phishing (October 2024)

A few days ago, I published an article about a recent Mailgun phishing campaign. Naturally, I received several additional phishing emails attempting to steal Mailgun credentials. In this post, we will take a deep dive into the recent Mailgun phishing emails I received after my last post.

Initial Email Analysis

The first email that I received in this next batch had a similar overall structure, however, the pretext was different. Previously, the pretext was that our credit card on file was no longer valid. This time, however, the pretext was that an API key had been added to our account.

This theme was consistent with both emails. Seems we've caught on that maybe invalid credit cards was a less than effective call to action. After all, an API key being added to our account would generally indicate a potential compromise.

Interestingly enough, both emails had the same Key ID, near same creation date timestamp, and the same API key name. This begs the question: Are these the same actors sending two somewhat different emails?

Our first email had the same tactic as our previous email post. The tactic being a link to a /ICS resource, followed by a redirect. In this case, to the following host hxxps://sinch-dud9gkqeb2c7ql.toeic-taisaku[.]xyz/ICS/ .

Unlike our last email that had a support email to appsupport@intersystems-rl[.]com, we now see it within the x-apparently-to email header. We also observe that the attackers have a reply-to header of Avinode Support appsupport@intersystems-rl[.]com . Interesting they have a name set to Avinode Support. Avinode Group (the company they have set their name to) is an Aviation service. I'm not sure exactly what the connection would be. Other than Intersystems-Rl is a supposed defense contractor that may use charter services?

Avinode?

Back to confusing methods and maybe nothing here.

Sender Identification

The spam email was sent from the address [email protected][.]eg, as indicated by the Return-Path header. This header shows where bounce messages (for undeliverable emails) are directed, confirming this as the sending address.

Authentication Details

While the email originated from iesr.asu.edu[.]eg, it also passed DKIM authentication for avinode.com, which is noted in the authentication-results-original header. The DKIM result of dkim=pass indicates that the email was authorized to be sent from the avinode[.]com domain. This suggests that the sender may have used a legitimate email service that is configured to send on behalf of avinode[.]com.

In summary, the spam email was sent from 9700197674360825@iesr[.]asu[.]edu[.]eg, while also being authenticated through avinode[.]com. This setup may imply that a legitimate service or system is involved in sending emails from iesr[.]asu[.]edu[.]eg, but the nature of the spam indicates potential misuse of this configuration.

Avinode Compromise?

We can see within the headers that the x-mailer is set to Zendesk Mailer. This makes me start to wonder if some component of Avinode's Zendesk is compromised.

Here is a flow of the email

User/Script
   |
   v
9700197674360825@iesr[].asu[.]eg
   |
   v
[Zendesk Mailer]
   |
   v
[Outgoing Mail Server]
   |
   v
[Intermediate Mail Servers]
   |
   v
[Authentication Checks]
   |              |           |
 DKIM           SPF        DMARC
   |              |           |
Pass           Fail      Quarantine
   |              |           |
   v              |           v
[avinode[.]com]   v
               [Recipient's Mail Server]
                      |
                      v
                 [email protected]
                      |
                      v
               [Recipient's Inbox]
                      |
                      v
     Reply-To: appsupport@intersystems-rl[.]com

Overall, this ends up being quite the campaign complexity just to steal Mailgun credentials. We may have a potentially compromised defense contractor and a potentially compromised Zendesk service.

In the second email, however, we saw abuse of legitimate resources, instead of just blanket sending links to the initial phishing gateway and a bunch of weird email trickery.

Secondary Email Analysis

When looking at the second email, we see mostly the same content. That is, until we take a look at the actual email message headers and body HTML.

When investigating headers, we can see that the email originated from a domain attached to Substack.

Given the content of the blog, I would assume this user has been compromised.

When taking a look at the html body content of the email, we can see that there's--what I assume is--a Mailgun campaign link from email[.]mg[.]edit[.]si.

[Correctly] assuming that this is a Mailgun campaign link, we can easily decode it. This is because Mailgun/Substack zlib compress and base64 encode links. All we need to do now is base64 decode and deflate the link ;). It's worth noting that Substack, from what I've seen, uses Mailgun to send emails.

category=post
d=cbe6b
e=1728338828
email_generated_at=1728318601203
h=a4092ae0ae707501baf8fa896105bed8
[email protected]
is_freemail=true
l=https://saboraa[.]click/mailgun
post_audience=everyone
post_id=149917155
post_type=newsletter
pub_community_enabled=true
publication_id=295937
r=(VICTIM EMAIL)
subdomain=freddiedeboer
t=post
user_id=91965638
v=2

There it is. We're now able to see that the email campaign is sending us to saboraa[.]click/mailgun. This gateway then sends us over to hxxps://login[.]maulgin[.]network/. Sadly, the domain doesn't resolve anywhere. Maybe it did, but we missed our window?

After taking a look at saboraa[.]click at the root, we see a VERY similar method to not only the other email in this post, but also my last article about Mailgun phishing.

Taking a look at ICS/ also shows us the near-identical JavaScript we previously encountered:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ICS Tool</title>
</head>
<body>
    <h1>Welcome to the ICS Tool Page</h1>

    <script>
        // Base64 decoding function
        b = atob;
meth = "re" + "pla" + "ce";
sodani = (el) => el[meth]( /#/gi, '' )[meth](/\!/gi, '' );
jkk = b("ZG9jdW1lbnQ");
jkk = this[jkk];
jkk[sodani('ti#'+'t!l##e')] = '._.';
jkk[sodani('b!#od'+'!y#')].style[sodani('op#a!'+'c!it'+'#y#')] = 0x0;

// Redirect to Google
window.location.href = 'hxxps://login[.]maulgin[.]network/SluRfaVN';

    </script>
</body>
</html>

Even the variable names are the same. It's quite amazing how simple of a phish gateway this is. Not to mention how easy it is to deploy. Essentially, an attacker only needs to put that HTML either on a compromised web site or on a host of their own control. Sadly, EVERYTHING is behind Cloudflare...removing our ability to easily obtain what the actual host IP is.

I'm going to keep an eye out to see if we get any more of these spam emails. I'm curious if we see the same methods going forward.