Have I Been Pwned creator and well-known security person Troy Hunt recently blogged about a phishing attack he fell for — a rare example of Attacker-in-the-Middle phishing being publicly discussed. Here’s what it tells us about how phishing is evolving and why even the best awareness training won't stop phishing attacks.
Have I Been Pwned creator and well-known security person Troy Hunt recently blogged about a phishing attack he fell for — a rare example of Attacker-in-the-Middle phishing being publicly discussed. Here’s what it tells us about how phishing is evolving and why even the best awareness training won't stop phishing attacks.
Phishing attacks using Attacker-in-the-Middle (AitM) kits are increasingly the default for both credential harvesting campaigns and targeted phishing attacks. It’s easy to see why, too:
They’re very difficult to spot as a user and often function like the real page should, logging the victim into the genuine site once the phish is complete
They’re incredibly scalable, and attackers have an increasing number of options to choose from when it comes to off-the-shelf tools and commercial Phishing-as-a-Service offerings
And most importantly, they reliably bypass 99% of the MFA methods encountered in the wild, defeating OTP, SMS and push-based authentication
There are basically no downsides to AitM for an attacker. But all the same, they don’t get all that much publicity — probably because traditional phishing prevention solutions are failing to detect them (before the attack succeeds, anyway — and nobody really wants to own up to that).
So, it’s refreshing to see Troy Hunt, creator of the widely used Have I Been Pwned (HIBP) service, publicly discussing a recent attack he fell victim to.
Before we consider the significance of Troy failing to spot the phish — the creator of one of the most widely used services for stolen passwords, working with government on phishing prevention guidance — let's start by breaking down the attack itself.
What happened
Troy received a phishing email appearing to be from MailChimp prompting him to sign into his account, with the lure informing him it had had been restricted due to a spam complaint
The email matched Mailchimp’s brand, but the sender address was obviously suspicious. Unfortunately, Troy initially accessed the email via mobile, which hid the sender address — which he then missed when accessing from his PC.
It’s notable that this email wasn’t actually sent from MailChimp as we’ve seen with other recent attacks where attackers have used third-party SaaS services to send their emails, making them appear more legitimate (such as in recent campaigns leveraging HubSpot and DocuSign).
Troy was directed to the page hxxps://mailchimp-sso.com. Troy entered his credentials and MFA token and logged in. The page hung and he realized he had been phished…
The attack then automatically executed, with the attacker exporting 16,000 contact records from MailChimp and creating an API key to provide backdoor access to the app (a form of ghost login).
Let’s have a look at what makes this attack interesting.
Breaking the attack down
As far as some of the AitM attacks we’ve observed in the wild go, this wasn’t the most advanced example we’ve seen:
It didn’t try to obfuscate the notably suspicious sender address or use a legit SaaS service to give the email sender a reputable domain.
It didn’t see the victim access the real login page, and instead terminated the connection at the point the credentials were captured — meaning Troy was immediately suspicious (I guess it doesn’t really matter given the attack executed instantly, automatically).
That said, it did use a few interesting tricks and techniques.
Enumerating suitable victims
It’s notable that Troy claims the email he used to access MailChimp wasn’t used anywhere else — meaning the attacker probably guessed it. The domain is partially obscured here but it's likely that this is Troy’s own personal domain. It isn’t too much of a stretch to imagine that organizations frequently set up dedicated email addresses for their MailChimp accounts or newsletters generally (e.g. mailchimp@exampledomain.com).
Undeniably, Troy’s MailChimp account is probably more of a target than most given the success of his newsletter, but it’s still likely that the attacker spammed many possible address and domain combinations to see what stuck. There’s a degree of luck, but also some smart guesswork at play here.
Using legit services like Cloudflare to defeat detections
The attacker used Cloudflare to host the domain, which is consistent with what we’ve observed attackers doing in the wild. Even if this means that Cloudflare will probably take the domain down eventually, they aren’t great at identifying the page right away. Given the rate at which attacker infrastructure is burned and rotated, the pros outweigh the cons for the attacker by giving the site legitimate hosting infrastructure, which can defeat some of the common checks performed by anti-phishing tools.
Troy also mentions seeing a 'Cloudflare anti-automation widget' when accessing the page, which is most likely Cloudflare Turnstile — a creative alternative to CAPTCHA to prevent security bots from accessing and loading malicious pages to analyse them. We've seen attackers use Turnstile along with a host of other obfuscation techniques to defeat common detections by preventing security tools from analysing the malicious page.
Although this page has now been taken down, the campaign undoubtedly continues — another will have been rotated in to take its place.
Configuring ghost logins via API keys to backdoor the account
The attacker also configured an API key — a smart way to backdoor an app and something we’ve previously demonstrated in our webinars as a SaaS-native attack technique for persistence. It means that even if the credentials are changed, the attacker can maintain access to the account.
Now, as a security pro, Troy noticed this and deleted it — but many less technical victims wouldn’t know to do this. It’s also not unusual for automated emails from applications to go to spam — meaning some victims potentially wouldn’t spot the notification sent to them.
But — why MailChimp?
This was the big question we asked ourselves when looking into this attack. Most phishing attacks targeting businesses tend to focus on core platforms like Microsoft, Google Workspace, etc. — usually Identity Providers (IdPs) that provide both access to email and downstream apps via SSO. It’s the biggest bang for their buck and most tooling is preconfigured to support these platforms. So MailChimp seems an unusual choice at first glance.
But, we’ve seen recently that it's getting easier for attackers to impersonate a broader range of brands. And there’s something to be said for targeting an app like MailChimp — your guard is naturally probably lower than it would be for a Microsoft-based phish, increasing the chance of success.
But what’s the payout? The data collected doesn’t seem to be overly valuable — 16k records including email address, IP, and rough geolocation data. Not particularly exploitable by itself…
Part of a multi stage attack?
This gets a lot more interesting when you consider the different things an attacker might do as part of a broader campaign.
With access to MailChimp, an attacker can send emails on behalf of the compromised account. These emails are highly trusted and expected from the sender, meaning people receiving them are much more likely to engage with the content, click the links, etc.
So what if an attacker compromised an account, inserted a load of malicious links into the newsletter, and used it in itself as a mass-phishing vector, designed to capture user credentials or deliver malware? Pretty devious! If you scale this up across multiple victims (and not all of them realize that they’ve been phished) you’ve suddenly got your hands on an incredibly valuable phishing vector that is much more likely to succeed than your average cold approach.
Then, with the additional victims, you could target accounts that are much more inherently valuable to an attacker. You could:
Deploy infostealer malware, which has dominated the headlines since the success of the Snowflake attacks last year, and are continually resulting in data breaches via attackers logging into apps using stolen credentials such as the recent attacks on Jira platforms.
Target personal apps for banking, email, e-com, and other easily monetizable services — which is increasingly easy to do at-scale using tooling for hire with stolen credentials.
Even attempt to deploy ransomware and other malicious software to progress an attack on user devices and networks (a pretty relevant use case for the many subscribers of Troy’s newsletter accessing it on their corporate device!).
Even grabbing the list of newsletter sign-ups could enable the attacker to perform this attack from a different MailChimp account, so anyone subscribed to Troy’s newsletter should be wary of emails impersonating Troy’s newsletter reaching them from a different sender address than usual.
Account security limitations
On the theme of MailChimp, it’s also notable that MailChimp doesn’t appear to offer SAML support. Okta lists the app as only available for SWA (where separate credentials are created to access the app, managed through Okta — more like a password manager than genuine SSO via SAML or OIDC).
This means you’re forced to use a username and password. Your only SSO option is to sign in with Google — which many non-Google Workspace users may not have access to.
As Troy points out, MailChimp also fails to offer support for phishing-resistant MFA. This is pretty typical (if disappointing) for the long tail of SaaS apps, which typically leave WebAuthn / passkey support to the IdP. Except in this case, support for SSO in general is limited, meaning you can only use passkeys if you’re logging in with Google.
So it’s possible that attackers have noticed that accounts in MailChimp are far more likely to have insecure accounts than other traditional phishing targets — simply because they cannot be configured as securely.
It might not just be MailChimp
It looks like the same attackers have previously targeted ActiveCampaign, a marketing email and automation platform, based on GitHub comments from December. A domain previously flagged as malicious relating to ActiveCampaign currently redirects to the malicious MailChimp domain seen in Troy’s attack.
hxxps://groupf.emlnk9.com/lt.php?x=3DZy~GE6KXOf6a4s-tI6hRVt3H2piwDuwehiY5THVXeZ5sF_y0y.zOlz5X2gk.~wjvYxZHPThis could point to a broader campaign targeting similar SaaS platforms for marketing automation and email distribution.
Closing thoughts
MailChimp might seem an unusual target but there are a lot of ways that attackers can abuse SaaS services, as we’ve discussed at length in our public research with the SaaS attacks matrix and many webinars and conference talks. Account takeover through modern phishing attacks like the one we've analysed here is key to unlocking this attack surface.
While the vast majority of phishing attacks that we observe do focus on core platforms like Microsoft, Google Workspace and Okta, it makes sense that attackers are broadening their focus to take advantage of the fact that phishing targeting these accounts is less obviously a target, and these accounts are often much less securely configured. But there are many ways to target the interconnected ecosystem of SaaS apps in creative ways that most organizations (and users) are seriously underprepared for.
Attackers have been targeting consumers and individuals via their sprawl of internet apps for some time — are more business-focused threat groups waking up to the opportunity of targeting SaaS? After all, it’s a great way to evade established controls elsewhere on the network and endpoints, and you can achieve your objectives simply by logging in to (often weakly secured) user accounts.
The moral of the story? Phishing attacks are getting pretty sophisticated (and often much more sophisticated than this). Even security pros get phished sometimes!
This is clear indicator that we need stronger technical controls to prevent phishing. If even someone like Troy can be phished, the only reasonable conclusion is that humans will always be susceptible to phishing, no matter how much awareness training they receive.
A big thanks to Troy for sharing his write-up of the incident!
How Push can help
Push takes a unique browser-based approach to detecting and intercepting phishing attacks that overcomes many of the tricks and techniques attackers use to defeat conventional anti-phishing controls. To learn more, check out our recent blog post.
And if you want to see how Push helps you to detect and defeat common identity attack techniques like AiTM phishing, credential stuffing, and session hijacking while improving your workforce identity posture, book some time with one of our team for a live demo.
