“EchoSpoofing: A Major Phishing Campaign Bypassing Proofpoint’s Email Protection”

“`html

Short Summary

The article discusses a significant phishing campaign named “EchoSpoofing,” which exploits Proofpoint’s email protection service to send millions of perfectly spoofed emails from well-known brands like Disney, IBM, and Coca-Cola. The campaign leverages authenticated SPF and DKIM signatures to bypass security measures, aiming to deceive recipients into revealing sensitive information. Guardio Labs collaborated with Proofpoint to address the vulnerabilities and enhance email security protocols, highlighting the need for continuous vigilance against sophisticated cyber threats.

Key Points

• Campaign Name: EchoSpoofing
• Exploited Service: Proofpoint’s email protection service
• Targeted Brands: Disney, IBM, Nike, Best Buy, Coca-Cola
• Attack Method: Sending spoofed emails with authenticated SPF and DKIM signatures
• Goal: Stealing funds and credit card details from recipients
• Collaboration: Guardio Labs worked with Proofpoint to mitigate the issue
• Technical Insight: Attackers used misconfigurations in email relaying to bypass security
• Volume of Attacks: Estimated at 3 million spoofed emails daily, peaking at 14 million
• Mitigation Strategy: Implementing unique vendor-specific headers to verify email sources

MITRE ATT&CK TTPs – created by AI

• Phishing (T1566)
  • Procedure: Sending spoofed emails that appear to be from legitimate brands to deceive recipients.
• Email Spoofing (T1566.001)
  • Procedure: Utilizing misconfigured email relays to send emails with forged sender addresses.
• Credential Dumping (T1003)
  • Procedure: Attempting to steal user credentials through phishing tactics.

“`

“EchoSpoofing” — A Massive Phishing Campaign Exploiting Proofpoint’s Email Protection to Dispatch Millions of Perfectly Spoofed Emails

By Nati Tal (Head of Guardio Labs)

Guardio Labs has uncovered a critical in-the-wild exploit of Proofpoint’s email protection service, responsible for securing 87 of the Fortune 100 companies. Dubbed “EchoSpoofing”, this issue allowed threat actors to dispatch millions of perfectly spoofed phishing emails, leveraging Proofpoint’s customer base of well-known companies and brands such as Disney, IBM, Nike, Best Buy, and Coca-Cola. These emails echoed from official Proofpoint email relays with authenticated SPF and DKIM signatures, thus bypassing major security protections — all to deceive recipients and steal funds and credit card details.

The following comprehensive report outlines the mechanisms of this ongoing malicious campaign, from its initial detection and the discovery of the exploit to its full replication, notably involving the abuse of Microsoft’s Office365 accounts.

This research underscores our collaboration with Proofpoint, which swiftly took action and implemented measures to mitigate the issue, thereby protecting their customers and the broader public. This effort not only illuminates persistent vulnerabilities within email protocols but also highlights the need for continuous vigilance and cooperation within the cybersecurity community to safeguard digital communications against sophisticated threats.

The Perfect Spoof of Major Brands

Just a few years ago, spoofing an email's “FROM” header was straightforward; you could write whatever you wanted. Nowadays, security protocols require emails to be sent from approved servers and authenticated with the domain’s private DKIM encryption key — all aligned with the domain mentioned in the FROM header. And yet, threat actors still manage to launch large-scale phishing email campaigns, swiftly taking hold of the identities of major brands like Disney, IBM, and Coca-Cola.

Our team recently uncovered a massive phishing campaign that takes spoofing to the next level. Attackers successfully sent millions of emails that appeared to be from well-known companies and brands, all properly signed and authenticated, with the ultimate goal of stealing our credit cards.

Digging deeper, we realized this is a well-orchestrated campaign that somehow manages to get their phishing emails properly DKIM signed and SPF approved. More notably, all those emails were dispatched from one specific family of email relay servers — pphosted.com — owned and operated by the Email security vendor Proofpoint.

“Now Spoofing on Disney+”

To understand the inner workings of this, we start with analyzing a sample of one of the millions of daily sent emails — a spoofed Disney+ account notification email sent from the real disney.com domain:

Clicking on this compelling offer will send you to a classic phishing flow. It presents a fake branded landing page with an offer you can’t refuse disguised as a customer quiz.

This is followed by the infamous purchase page hiding its real intention in the smallest font size the browser allows:

Back to the email itself, we see it was sent from the address admin_support.XXXX@disney.com, when the XXXX is randomly generated per each email in this batch. This is the real disney.com domain presented in the FROM header. It even gets the Disney logo next to it. This means that, Amazingly, this email fully complied with authentication and security measures explicitly built to fight this:

• SPF (Sender Policy Framework)— The Email was dispatched from an approved server as set on the SPF record on the disney.com domain
• DKIM (DomainKeys Identified Mail) — The email content was signed with the authentic key owned only by disney.com.

Looking at the email headers, where the metadata of the delivery and authentication process is logged, we can clearly see that the receiving service, Gmail, has fully authenticated this email:

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)

Looking at disney.com’s DNS record, we couldn’t find any misconfiguration that can be abused for SPF approval or use of other arbitrary IPs or domains. Plus, getting the genuine private DKIM key to sign those emails suggests Disney’s data was breached?! Well, this is not the case here, not at all…

Proofpoint’s Relay Servers as the Enabler

When we analyzed the path those emails took to reach the victims' inboxes, we realized they all share the same characteristics—starting at a simple SMTP server on a virtual server, going through an Office365 Online Exchange server, and later entering a domain-specific Proofpoint server that dispatches the email to the targets.

We see different SMTP servers, as well as different Office365 instances, in other samples from this campaign. Yet, the endpoint is always a Proofpoint pphosted.com server —so it’s time to understand better what this relay server is all about.

The Proofpoint Email security solution is a kind of “Firewall” for emails. The SMTP protocol allows an email message to travel through different points heading to your inbox, just like we’ve seen in the above sample. This is how Proofpoint offers its customers an easy integration method—just point all your organization's outgoing and incoming emails to Proofpoint’s server.

Incoming emails are sent directly to Proofpoint servers using the MX record on the domain’s DNS record. Outgoing emails are a bit trickier, depending on the email service used to deliver messages. Specifically, if you use the Office365 business email account, you can comply by using the “Connectors” option of the Exchange server. You need to configure it to redirect your selected outbound emails to a pre-defined Proofpoint endpoint, which will do all the rest for you.

What is “all the rest” you ask? Well, this is the interesting part. Proofpoint’s server is the latest point to dispatch the outgoing email. It will be the one that needs to comply with the mentioned email security standards and ensure the receiving party later authenticates the email.

Remember that those malicious emails got DKIM signature and SPF approved? This is precisely what’s done on the Proofpoint outgoing relay server:

In the above example, Disney (or any other Proofpoint customer) configured their private DKIM signature key on the Proofpoint service and set their SPF records on their domain to approve the Proofpoint server as an allowed email sender. This is how Disney authorized Proofpoint to send authenticated emails on their behalf.

An attacker needs only find a way to send spoofed emails through the Proofpoint relay, and Proofpoint will do all the rest. They needed to find a way in for that, and they did.

Injecting Spoofed Headers with Email Relaying

To kick this off, we need to create a spoofed email. This means we need to use our own SMTP server, which we can manipulate to include any spoofed headers in our phishing email—including the “FROM” header indicating the email was sent from Disney.com, for example.

However, sending malicious emails from temporary, unreputable servers will definitely doom these emails to the spam folder and probably ban this server due to rate limits and the new anti-spam rules initiated by Gmail lately. Yet, we see this threat actor send millions of those each day!

When we look a bit deeper into the “Received” headers, we notice that the Office365 part is clearly not a Disney-approved server, and it looks like it’s being relayed through the Exchange email server and not created directly on it. Notice the term via Frontend Transport used on these header values — suggesting Exchange is configured to blindly relay emails without altering them. This is an interesting conclusion, as email relaying, although a benign part of the SMTP protocol, is well known for being heavily abused.

One of the most notable abuses of this email server configuration is sending spoofed emails through it. In our example, attackers make the Office365 account send an email with spoofed headers that originated from their own controlled SMTP server. Note that using someone else's domain in your emails’ FROM field can’t be done when initiating the emails directly from your Office365 account. You first need to provide proof for Microsoft that you own this domain! But when relaying? looks like Microsoft couldn’t care less….

Now, the attackers have a disney.com branded email sent by a genuine Microsoft Office365 account. Gmail will never block Outlook’s servers due to rate limits as those are built to send millions of emails each hour — by feature. Also, this works well for SPF, as this email is being outbound by the official Microsoft email relay server (protection.outlook.com), which is part of Disney’s SPF record:

TXT Record of spf.disney.com:

"v=spf1 ip4:204.128.192.17 ip4:204.128.192.36 ip4:204.128.192.43
ip4:192.195.66.26 ip4:192.195.66.28 ip4:192.195.66.36
include:spf.protection.outlook.com include:spf-00278502.pphosted.com
include:spfb.disney.com -all"

Spoofed headers? Check.
SPF? Check!
Now, what about DKIM?

A Permissive Configuration Turned Detrimental

This is where the use (or, better say, abuse) of Proofpoint in this attack chain comes in handy.

The attacker wants to mimic the benign Disney → Proofpoint's day-to-day activity, making Proofpoint interact with the spoofed email just as it would have with a benign one sent from a Disney email service. This means it will be DKIM-signed and sent to the target’s inbox.

Yet, the Proofpoint outgoing server will ONLY accept incoming emails from approved servers, as configured in the Email Flow feature. In the case of hosted services like Office365 or Google’s GSuite, it’s a single-click configuration:

Notice that on the above configuration screen, no authentication (passwords or key pairs) is used to add approved email services — this is impossible due to how SMTP works. The actual authentication is by IP address, just like SPF in general. Proofpoint is aware of the IP ranges used by those hosted services, and once a service is enabled — Proofpoint will accept connectivity from that range of IPs. This is crucial, as hosted services like Office365 are usually distributed and use multiple servers and locations simultaneously for all their customers.

But, and this is a big but… to use its own Office365 account, the customer has just configured a generic “Office 365” option. Which account? Whose account? There is no way to set it on this screen…

If no other special rules or enforcement are manually added later on, will any Office365 account be able to interact with the Proofpoint relay server? Well, the answer is — YES!

The attacker exploits this super-permissive misconfiguration flaw, adding it to the blind relay on the Office365 instance to generate any spoofed email, deliver it to Proofpoint’s servers, and have it accepted and processed. From Proofpoint, it is “echoed” back and dispatched as a fully genuine email, including DKIM and SPF checks, totally aligned with the actual domain name!

Note that there are ways to add specific rules to Proofpoint’s account to prevent this and other kinds of spoofing by manually filtering emails from unknown sources and other specific headers and properties (e.g., emails that you or your partners did not send). However, this process is entirely manual and requires custom rules, scripts, and maintenance, as shown on this tutorial page from Proofpoint. Most customers were not aware of this in the first place, and the default option was not secure at all.

Finalizing the Email Flow with Connectors

The only missing part of the puzzle is: to which pphosted.com server do we send a spoofed “Disney.com” email? Each Proofpoint customer gets a specific host that handles its own authenticated traffic. The attackers need the specific hostname per each spoofed domain. Yet, this is exactly what the actualdisney.com owners also need to use this service. As such, Disney sets it on their MX record, publicly available under the DNS protocol:

;QUESTION
disney.com. IN MX
;ANSWER
disney.com. 453 IN MX 10 mxa-00278502.gslb.pphosted.com.
disney.com. 453 IN MX 10 mxb-00278502.gslb.pphosted.com.

All the attacker needs is the unique ID (in this case, it's00278502) With it, one can generate the relevant outbound addresses like so:

mx0a-00278502.pphosted.com
mx0b-00278502.pphosted.com

Now the attacker returns to their controlled Exchange online server and sets it up as any other Proofpoint user — add a connector to your Exchange Online Server for your outgoing emails pointing to the above pphosted.com server.

Now, adding to the blind-relay configuration— the attacker has a full delivery chain for perfectly spoofed emails!

“EchoSpoofing” in Numbers

This activity started around January 2024, and we can see how those servers, domains, and Office365 accounts were set up to 2 months earlier. Our data allows us to approximate a daily average of 3 million perfectly spoofed emails ever since, with some peaks reaching a daily number of up to 14M!

This technique can be leveraged by a threat actor to spoof both high-value and reputable brands and, even more importantly, to do so on a mass scale. Those spoofed domains and the Proofpoint relay are allowed to send emails in massive numbers, which is one of the most significant leverages here.

We can see how the threat actor harnesses this capability and manages a massive delivery system of malicious emails, spoofing a different domain each time, with an arsenal of SMTP servers and rogue Office365 Accounts owned and controlled by the actor.

The threat actor is very strict about using and potentially exposing their resources. Once it finds a vulnerable Proofpoint account (by testing out this exploit on a small scale), it saves the domain for later use, forcing time gaps between delivery opportunities. It switches abused domains and Office365 accounts each time, making it harder to spot the activity and trying to stay “under the radar” as much as possible.

It was quite interesting to see how, once the campaign was spotted and Proofpoint customers started to patch and block this exploit, the threat actor realized the decline and started burning out assets — realizing “the end is near” — as can be seen with the disney.com domain usage in the above graph in early June 2024.

The Powerful Backend Behind the Operation

We’ve noticed that most operations are initiated with a cluster of VPSs (Virtual Private Servers), mainly hosted on OVH, tightly connected under some actor-owned domains, and managed with special software called PowerMTA.

PowerMTA is a high-performance, enterprise-grade email delivery software owned by Bird. It is designed to handle large-scale email-sending needs and can leverage server clustering to scale up the delivery times and performance. It’s important to note that this is legit software! Yet, as you can realize from its description, it is also the weapon of choice for many spammers. When looking around some dark-web markets, you quickly realize this is not the first time this tool is being abused:

Our case is no different. Looking into some of the domains and IPs used to deliver those spoofed emails, we got a glimpse of this campaign's inner workings. The dashboard of one of those PowerMTA clusters was populated on an open port, and we couldn’t resist…

Here, the basic PowerMTA configuration was set to deliver around 2.8 Million emails on each batch. If we dive deeper into our data, we realize this is indeed true. With a single command, this system took one delivery chain (an Office365 account and a Proofpoint customer relay server) and, in minutes, delivered up to 3 Million emails worldwide. The above specific server cluster was used in April 2024 for several days, delivering millions of emails on behalf of Disney, IBM, Best Buy, and Nike.

One of the system init logs, which was also publicly available, shows more insights into the backend system:

2024-05-01 22:35:02 PowerMTA(TM) v5.0r3 (2020-02-06 19:49:17, 64-bit; v5_0r3@200206.beacabb) starting
2024-05-01 22:35:02 Copyright(c) 1999-2020, Port25 Solutions, Inc.  All Rights Reserved.
2024-05-01 22:35:02 OS: Linux 3.10.0-1160.118.1.el7.x86_64 (CentOS Linux release 7.9.2009 (Core))
...
2024-05-01 22:35:02 Max. opened files: 32768, somaxconn: 128, max. threads: infinite
2024-05-01 22:35:02 Non-IP host names: ***.**********.com
2024-05-01 22:35:02 Name servers: 127.0.0.1, 213.***.***.***
2024-05-01 22:35:02 SMTP source IP addresses:
2024-05-01 22:35:02     virtual MTA "pmta-vmta1": 51.*.*.*
2024-05-01 22:35:02     virtual MTA "pmta-vmta5": 51.*.*.*
2024-05-01 22:35:02     virtual MTA "pmta-vmta9": 51.*.*.*
2024-05-01 22:35:02     virtual MTA "pmta-vmta10": 51.*.*.*
2024-05-01 22:35:02     virtual MTA "{default}": (any local)
2024-05-01 22:35:02     virtual MTA "pmta-vmta2": 51.*.*.*
2024-05-01 22:35:02     virtual MTA "pmta-vmta6": 51.*.*.*
2024-05-01 22:35:02     virtual MTA "pmta-vmta11": 51.*.*.*
2024-05-01 22:35:02     virtual MTA "pmta-vmta3": 51.*.*.*
2024-05-01 22:35:02     virtual MTA "pmta-vmta7": 51.*.*.*
2024-05-01 22:35:02     virtual MTA "pmta-vmta4": 51.*.*.*
2024-05-01 22:35:02     virtual MTA "pmta-vmta8": 51.*.*.*
...
2024-05-01 22:35:02 Priority nice range: min. 15, max. 0
2024-05-01 22:35:02 Using license key SKYPE: rony.raskhit
2024-05-01 22:35:02 Spool initialization starting
2024-05-01 22:35:02 Scanning spool directory /var/spool/pmta...
2024-05-01 22:35:02 ...complete! Found 1 file, 1 directory
...

This PowerMTA configuration operates across a cluster of 11 servers, capable of dispatching up to 2,880,000 emails per batch. Notably, the system’s license key is set to SKYPE: rony.raskhit. A quick online search reveals that “Rony” is publicly offering cracked versions of PowerMTA, complete with installation and configuration services — advertised as ideal for spamming and phishing operations. While there is no direct evidence to suggest Rony is behind this particular campaign, the public availability of such services hints at his potential involvement in various illicit activities. This assumption is supported by multiple forum posts and product listings that align with phishing and software hacking:

Disclosure and Cooperation with Proofpoint

Upon discovering this campaign at Guardio, we quickly contacted Proofpoint in May 2024 to share our findings and initiate a collaborative response. Proofpoint responded within hours, setting the stage for our joint efforts.

Proofpoint noted that they had been aware of the activity since late March 2024 and had already started tracking it. Recognizing that the issue stemmed from misconfigurations, they launched a comprehensive outreach to notify affected customers through automated messages and direct contact with their support teams and engineers.

In our collaboration, we shared IOCs to help identify and trace the operation. Despite Proofpoint’s efforts to alert Microsoft about compromised Office365 accounts, these accounts remained active for over seven months and counting. In parallel, we contacted OVH and Centrilogic to report the VPSs used to dispatch these spoofed emails, aiming to disrupt the scammers’ operations and make it more challenging for them to continue.

To address this issue, revising the default configuration approach for adding Office365 accounts became crucial. Proofpoint customers had been setting up their Office365 integrations in a way that inadvertently left them exposed. A more secure configuration method was needed to filter out unauthorized Office365 sources effectively.

Proofpoint proposed a mitigation strategy utilizing a unique vendor-specific header X-OriginatorOrg which the Exchange server automatically appends to all outgoing emails, including blindly relayed emails. This header contains the distinct Office365 account name, or “tenant,” providing a reliable means to verify the source of each email. By using this header, customers can ensure that only emails from their own authorized Office365 tenants are accepted, effectively blocking any malicious actors from further exploiting this flow.

The proposed solution involves the X-OriginatorOrg header is effective, yet it relies on assumptions that carry inherent risks. As an “X” header, it is a custom header used internally by Microsoft, not officially documented, and could be subject to removal, modification, or misrepresentation. Moreover, there’s the potential for this header to be spoofed or for threat actors to manipulate the Exchange server into omitting or altering its value.

In response, our team at Guardio, in collaboration with Proofpoint, conducted rigorous tests to challenge the integrity of this header — from targeting the Exchange mechanism to testing the header decoding on Proofpoint’s end. Despite some Unicode-fabricated X-OriginatorOrg headers that were relayed through Exchange but rejected by Proofpoint, we found no breaches in the security of this mitigation approach. It appears that Exchange has implemented additional safeguards, such as stripping any spoofed X-OriginatorOrg headers from outgoing emails, further bolstering this solution.

Finally, integrating a straightforward and default configuration process into the Proofpoint admin panel was essential for a sustainable and robust defense. The Proofpoint product team acted swiftly, designing and deploying a significant update now available to all users. This enhancement alerts and clearly describes the potential risks, allowing customers to approve tenants and easily monitor for any signs of misuse.

Conclusion and Final Thoughts

Addressing security issues often appears straightforward theoretically, but the reality presents unexpected complexities. With “EchoSpoofing”, the technical challenge lies in enhancing an old, insecure protocol like SMTP, which suffers from fragmentation and inconsistent implementation across different vendors. Moreover, integrating security measures with Microsoft Exchange, a nearly 30-year-old platform over which users have little control, adds another layer of complexity.

Altering customers’ configurations isn’t a simple task either. Such changes can lead to operational disruptions and potentially cause even more damage. Proofpoint demonstrated a valuable commitment to both its customers and the wider public affected by this attack. They undertook a substantial effort to contact customers and provide direct support to update configurations carefully, ensuring the integration of fixes did not disrupt the environments of organizations that rely on multiple approved email delivery inputs.

This scenario required mature, professional, and constructive decision-making, with meticulous risk management to weigh the potential impacts of various actions. At Guardio, we were privileged to collaborate closely with Proofpoint in challenging and testing proposed solutions and exploring alternative attack vectors to ensure that the final measures were robust and reassuring.

Kudos to Proofpoint for their cooperative spirit and responsible actions. This incident highlights the broader challenge of securing foundational internet infrastructures that, while privately held, serve and impact the entire open ecosystem. Entities like these bear a dual responsibility: not only to their direct customers but also to the broader community of internet users—a responsibility that is too easy to overlook these days.

IOCs

Updated July 27, 2024:

# Office365 Tenants

novamixnf.onmicrosoft.com
skypesksm.onmicrosoft.com
munimariquina.onmicrosoft.com
edc2015.onmicrosoft.com
farocapital365.onmicrosoft.com
gmdk.onmicrosoft.com
x8674lj.onmicrosoft.com
ramirocaroguamuchil.onmicrosoft.com
bandalignano.onmicrosoft.com
skyvictory.onmicrosoft.com
redesmedicasips.onmicrosoft.com
t1chile.onmicrosoft.com
cfcnglns65p07a512l.onmicrosoft.com
dsumed.onmicrosoft.com
meleamita.onmicrosoft.com
blancom.onmicrosoft.com
idorganization.onmicrosoft.com
opam.onmicrosoft.com
saiani.onmicrosoft.com
stacey025.onmicrosoft.com
bolmendo.onmicrosoft.com
emailcontact132.onmicrosoft.com
jerem236.onmicrosoft.com
frantisekvesely.onmicrosoft.com
mitwarehouse.onmicrosoft.com
gourmoud.onmicrosoft.com
grupmacrolim.onmicrosoft.com
veroty.onmicrosoft.com
teclive.onmicrosoft.com
sdht.onmicrosoft.com
nahjaltaj.onmicrosoft.com
fas83.onmicrosoft.com
snnssmartact.onmicrosoft.com
jordi619.onmicrosoft.com
antonya777.onmicrosoft.com
bernadno.onmicrosoft.com
reonenergy.onmicrosoft.com
furgeson862.onmicrosoft.com
frend265.onmicrosoft.com
domnef.onmicrosoft.com
berga015.onmicrosoft.com
lukk989.onmicrosoft.com
6zc8sx.onmicrosoft.com
angelicoo.onmicrosoft.com
molebeek.onmicrosoft.com
zbmxs.onmicrosoft.com
clementy618.onmicrosoft.com
nordany390.onmicrosoft.com
sofrane.onmicrosoft.com
fgbgfbtsbg.onmicrosoft.com
molanbeek.onmicrosoft.com
volman683.onmicrosoft.com
gafaacat.onmicrosoft.com
kleop.onmicrosoft.com
omran035.onmicrosoft.com
antlisa.onmicrosoft.com
gregorioa.onmicrosoft.com
hollman250.onmicrosoft.com
mailv077.onmicrosoft.com
felnder.onmicrosoft.com
lukana108.onmicrosoft.com
lkstubc.onmicrosoft.com
lisalfr.onmicrosoft.com
clemon108.onmicrosoft.com
amana770.onmicrosoft.com
nertvoxss.onmicrosoft.com

# SMTP Servers

103.114.217.36
51.81.235.59
51.81.214.179
51.81.210.13
51.81.206.120
51.81.206.119
51.81.206.118
51.81.204.120
51.81.195.94
51.81.150.17
51.81.150.15
51.81.150.14
51.81.150.13
51.81.150.12
51.81.150.11
51.81.150.10
51.81.149.245
51.81.149.211
51.81.149.175
51.81.148.234
51.81.142.68
51.81.142.64
51.81.142.62
51.81.140.123
15.204.50.179
15.204.50.178
15.204.50.177
15.204.50.176
15.204.50.175
15.204.41.218
15.204.41.213
15.204.40.128
15.204.226.108
15.204.20.226
15.204.12.95
15.204.12.122
15.204.12.120
15.204.12.119
15.204.12.117
147.135.40.42
147.135.40.11

# Spoofed Domains

ibm.com
disney.com
ibm.com
bestbuy.com
coca-cola.com
foxnews.com
hoka.com
converse.com
espn.com
reebok.com
danone.com
sodexo.com
nike.com
novartis.com
acehardware.com
agc.com
bjs.com
chsinc.com
cmsenergy.com
columbiagasohio.com
edenred.com
labcorp.com
mckesson.com
nexteraenergy.com
nutrien.com
suez.com
sunnova.com
sysco.com
unfi.com
wesco.com
wmf.com

# SMTP Domains

tonalimail.org
x0ican.org
amassou.org
developmentsreaders.org
nsusiuko.info
towdirection.org
fenugrek.info
gandermail.info
starssky.agency
newservicestc.net
aniview.org
detawatch.com
wheatrusks.town
llksbcosa.org
upchecked.org
playnz.org
delaysearly.org
lastlist.org
resultnosc.org
comebackpilots.com
vscali.org
mirajcloud.org

Source: Original Post