Phishing is not a new concept, nor is spoofing. After all editing or manipulating the FROM heading in an email is trivial. The ease of which this can be done led to not only Spam and Phishing filters (collectively dubbed email security) but also things like SPF (Sender Protection Filter), DKIM (DomainKeys Identified Email), and DMARC (Domain-based Message Authentication, Reporting and Conformance). Even with these protections are not perfect (no protection is perfect) and malicious emails and communications can still leak through, but for the most part these systems, when properly configured and layered) keep most threats at bay.
So, what happens when someone finds a way to use the same systems intended to protect us to deliver the malicious content? Well guess what?! That is exactly what has happened with one popular service, ProofPoint.
The researchers at Guardio Labs identified a large scale (they used the term massive) phishing campaign which were both DKIM signed, and SPF verified. These emails all appeared to be sent via a group of hosts operated by ProofPoint (pphosted[.]com).
workflow. Entice the target to click on a link, get them to enter credit card information along with account information and profit. This was not really the interesting part of the campaign. Instead it was how these all were signed and approved as a review of some of the emails showed (in the example below it was sent to gmail)
“Authentication-Results: mx[.]google[.]com;
dkim=pass header.i=[@]disney[.]com header.s=ppdkim header.b=MVl6clAB;
spf=pass (google.com: domain of admin_support.dnrj@disney[.]com designates 205[.]220[.]164[.]148 as permitted sender) smtp[.]mailfrom=admin_support[.]dnrj[@]disney[.]com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header[.]from=disney[.]com
ppdkim - The DKIM key code generated by Disney to be used with Proofpoint (pp) 205[.]220[.]164[.]148 - The Disney dedicated Proofpoint outbound server(mx0a-00278502[.]pphosted[.]com)”
A deeper look showed that the attackers were using an SMTP server to send though MS365 Exchange servers which then relayed via the proper domain specific ProofPoint server. Guardio Labs did not find any DNS Abuse in these attacks, it was all digital Judo with ProofPoint as the leverage point.
The abuse of MS365 Exchange servers as open relays is also nothing new. Attackers now that they cannot spoof a domain directly on an Exchange Online server, so they set up a connector (which does not care what it passes) to send from their own controlled SMTP service. Using this they can spoof the domain that they want knowing that Microsoft Outbound servers are not going to be blanket blocked. We actually see some of this in recent “group list” attack where someone will create a list of email addresses and send to that via exchange to other MS365 accounts to avoid detection.
The ProofPoint attack takes this to another level though and takes advantage of a lack of authentication or protection in the connection configuration. Yup that is right, inside ProofPoint to allow you to send email via MS365 Exchange or GSuite, it is a simple toggle. ProofPoint uses the IP Ranges of these services instead of any particular account to validate the sender. This leaves a rather large vector for abuse by an attacker.
It is easy for an attacker to see if their intended source company uses MS365 Exchange by reviewing SPF records of the target. They also can find the exact ProofPoint servers to point their Exchange relay to. Now that they know this they relay their malicious email via Exchange Online to the identified pphosted server and they also get the protections provided by ProofPoint as an extension.
Now before you break out the pitchforks and torches, ProofPoint does have custom options to limit this attack vector. However, this is not the default, and many customers were not aware of these options leaving them open to this style of digital judo.
The campaign identified by Guardio Labs began in January of 2024 with the SMTP and Exchange Online servers coming online about 2 months later. According to their forensic investigations, an average of 3 million emails were sent via this method per day with peak activity hitting as high as 14 million in a single day.
The attackers in this case seemed to understand that they had something they could exploit at scale, but also did not want to bur through this too quickly. They took their time to identify potential high-value domains to send from, but also waited to exploit them at scale after they confirmed they were a viable option. They also rotated their SMTP and Exchange relays to help keep them from being identified too quickly.
To control all of this the attackers appear to use legitimate software PowerMTA (although a cracked version). Guardio Labs noted that this software is often used by phishing groups to control their efforts at scale. They also identified a server which was using PowerMTA that was part of the EchoSpooing campaign and… well took a look.
Following responsible disclosure, Giardio Labs let ProofPoint know about their find in May of 2024. ProofPoint, for their part, had been tracking the issue since March. Guardio and ProofPoint began work on a mitigation. ProofPoint settled on X-OriginatorOrg header which could be appended to legitimate sender servers to that ProofPoint can validate the emails coming in. Guardio Labs then set about the task of testing this to see if this was open to additional spoofing attacks. Their testing revealed that, this was a valid mitigation.
ProofPoint has also updated their integration configuration page to make it easier to list which servers are authorized, and how to deal with any email sent from unauthorized servers. This last part makes for easier monitoring and identification of abuse attempts (which is nice).
What went wrong –
ProofPoint’s default integration options were bad, and a lack of proper documentation and customer awareness created an opening for an attack on this scale. Microsoft is not blameless in this either as abuse of their email system has become very common and yet there is often little to no movement to remove known malicious tenants from play. The fact that an attacker (or attackers) was able to send 3-14 million phishing emails per day via this method is extremely disappointing especially coming from a well-known and popular vendor. It represents a significant failure of imagination on the part of ProofPoint.
What went right –
Guardio Labs indicated that ProofPoint was open to and very willing to work with them to find a proper solution to this. ProofPoint also made the effort to directly contact and work with their customers who were affected by this and to assist them in remediating it with the existing tools while working on a better mitigation option. Their combined efforts allowed for a solid mitigation to the existing abuse campaign and to simplify setting up proper integration for clients without the need to use custom or advanced tools.
Phishing is not going away; it is too lucrative of an endeavor for threat groups to just stop doing it. This means that the companies who develop and offer protection services need to be continually evaluating their methods against the ever shifting tactical and logistical efforts observed in the threat landscape. This includes understanding that services like Microsoft Exchange Online and even GSuite are heavily leveraged by attackers (Microsoft more than Google). Knowing this it should have been a logical conclusion that you cannot just trust everything coming from Microsoft and protections put in place to stop malicious routing. I hope that this incident is a wakeup call for others in this space to double check their math to ensure there are no unintended gaps in protection and integration methods.
For the full details you can check out the report on Guardio Labs Site
A ProofPoint Spokesperson reached out with a comment on the issue. They also provided the a link to the ProofPoint Blog on this event
“In March, Proofpoint researchers identified spam campaigns being relayed through a small number of Proofpoint customers’ email infrastructure by sending spam from Microsoft 365 tenants. All analyses indicate this activity was conducted by one spam actor, whose activity we do not attribute to a known entity. Since discovering this spam campaign, we have worked diligently to provide corrective instructions, including implementing a streamlined administrative interface for customers to specify which M365 tenants are allowed to relay, with all other M365 tenants denied by default.
These campaigns did not expose any Proofpoint customer data, and no customer experienced any data loss as a result.
We greatly appreciated the support and information provided to us by the wider security and service provider community including Guardio Labs. In late May, while we were continuing to conduct customer outreach, Guardio Labs contacted us through our established security contact email address. They shared additional technical information that allowed us to more accurately reproduce the relay setup and validated that changes we instructed our customers to make were effective in stopping relay abuse.”
