“PhishForce” — Vulnerability Uncovered in Salesforce’s Email Services Exploited for Phishing Facebook Accounts In-The-Wild
By Oleg Zaytsev, Nati Tal (Guardio Labs)
Guardio’s Email Protection has detected a sophisticated email phishing campaign exploiting a 0-day vulnerability in Salesforce’s legitimate email services and SMTP servers. Guardio Labs’ research team has uncovered an actively exploited vulnerability enabling threat actors to craft targeted phishing emails under the Salesforce domain and infrastructure. Those phishing campaigns cleverly evade conventional detection methods by chaining the Salesforce vulnerability and legacy quirks in Facebook’s web games platform. Guardio Labs has disclosed these findings and worked with Salesforce and Meta to close the vulnerabilities and misuse.
In this write-up, we will analyze the campaign, dissect the vulnerability finding and discuss how exploiting it gave threat actors leverage on conventional email filtering methods.
Malicious Emails Sent by Trusted Email Gateways
Since the early days of the internet, we have been plagued by malicious emails, ranging from bothersome spam to highly targeted and personalized phishing attempts. Despite significant advancements in email detection and blocking over the years, bad actors will always manage to stay one step ahead, devising new techniques to evade filtering rules and other legal measures designed to clean up our inboxes.
One such technique involves hiding malicious email traffic within legitimate and trustworthy email gateway services. Those are regularly sent out in overwhelming volume we are all so used to — from advertisement campaigns and product newsletters to your sprint dev ticket updates. This gives bad actors not only volume but also access to the reputation of those gateways, usually getting their IPs and domains whitelisted in an organization or even network-wide.
As those Gateways play a crucial role, they must also assume the role of gatekeepers, ensuring no misuse occurs by diligently verifying the ownership of every email address used. However, what happens when the bad actors discover cunning methods to outsmart these safeguards?
A Phishy Salesforce Email
As part of our Email protection research, our research team here at Guardio Labs analyzed one such example lately, presenting quite a sophisticated Facebook phishing scheme. We’ve seen other variants of that phishing pages and directing emails in the past, yet something else triggered our attention while observing the mail metadata:
A phishing email sample as was sent from the “@salesforce.com” email addressThis is a well-created phishing email, that mentioned the target’s real name and seems to be mailed from “Meta Platforms”. The big blue button sends the target to the phishing page built to grab your Facebook account details.
This page is hosted as a game under the Facebook apps platform using the domain apps.facebook.com. This is yet another interesting piece of the puzzle, allowing the illusion as if this “Meta Support” page is an actual part of your real Facebook account (although the sharp-eyed will note that this was supposed to be a “Football Manager” game of some kind).
So it’s a no-brainer why we’ve seen this email slipping through traditional anti-spam and anti-phishing mechanisms. It includes legit links (to
facebook.com) and is sent from a legit email address of@salesforce.com, one of the worlds leading CRM providers.
Exploring Salesforce’s Email Gateway
The Email Gateway feature is a fundamental component of the Salesforce CRM system. It encompasses servers specifically designed to send a large volume of email notifications and various messages to customers across the globe. Before sending out an email, the Salesforces system validates the ownership of the domain name it is about to use to send an email. This domain will be shown alongside the “From” field and ensures Salesforce was given permission to send emails as the brand by the authentic brand owner.
This is why we are quite used to seeing phishing emails that might have “Facebook” as the name of the sender, yet are forced to use a non-facebook, usually newly registered, domain in the email address within the “From” field. Our case here is different and most intriguing.
Looking at the headers of this email sample reveals its source:
X-SFDC-EmailCategory: apiMassMail
Received: from smtp10-lo2-sp1.mta.salesforce.com (smtp10-lo2-sp1.mta.salesforce.com. [161.71.6.233])
From: Meta Platform <accviolation@21gjt96n3uz6hgxytsmo0tf72hqyt6wg3ifrbql7e7k1xfd9df.8e-sefdea4.um9.case.salesforce.com>We see that the sender is indeed a salesforce.com domain user of some kind, sending the email from the SMTP gateway used for mass-emailing:
How Salesforce Verifies the Sender Address
As mentioned earlier, you have to verify an email address to be able to send out emails using it. Only clicking on the verification link sent to your desired email inbox will give the Salesforce backend the permission to configure outgoing emails accordingly:
Once the address is verified — you can select it on the outgoing email prompt that will send out email messages using your selected address. Note that this is the user-owned address and domain and NOT a Salesforce domain address as we’ve seen in the phishing sample.
We tried manipulating the POST request sent to Salesforce’s BE to trigger the email transmission, changing the sender’s address to other values, yet this kind of behavior was blocked — kudos on that to Salesforce. Now the question arises: How did these malicious actors find a way around these protective measures?
Overpowering The Verification System With Another Salesforce System
Going back to where it all started, another small detail in the headers gave us the breakthrough clue on what actually happened here — the domain of the From address field is actually built of a sub-domain generated per a specific Salesforce account — using the “case” magic word:
21gjt96n3uz6hgxytsmo0tf72hqyt6wg3ifrbql7e7k1xfd9df.8e-sefdea4.um9.case.salesforce.comWe realized this address is actually user controlled under the “Email-To-Case” feature of Salesforce, used to automatically convert customer inbound emails into actionable tickets in the Salesforce system itself:
As an example — you configure a specific email address like “feedback@xxxxxx.case.salesforce.com” that if you send an email to — it will automatically open a new ticket in your system. This is a common feature that should have been used for inbound emails only! And so, how do you make Salesforce send emails out using this exact address?
Exploiting Salesforce to Get Brand Ownership
Digging deeper into the Salesforce email validation process got us to find a vulnerable flow. The trick lies in the possibility to receive emails that are sent to specific @salesforce.com addresses and access their content using the tickets system of Salesforce itself. That content, in our case, can include the verification link we are after.
We start with creating an “Email-To-Case” flow — giving us full control of the username part of the generated salesforce email address:
In our example, we selected “salesforce” as the username giving us this email address to abuse: salesforce@{account_id_hash}.case.salesforce.com
Now we have an email address that looks exactly like the one we’ve seen used in the wild on our phishing email sample. We go on to verify it as an “Organization-Wide Email Address” — which is the way to make the Salesforce Mass Mailer Gateway use this address in the official outbound flow. Note that the system will send a verification mail to this address, so we first add the salesforce address that sends those emails to the Acceptable Email Addresses. This way we will be able to receive the verification email:
Now creating a new Organization-Wide Email Address entity using the newly generated salesforce.com address:
This triggers the verification flow that sends the email to this routing address, ending up as a new task in our system — just as we’ve configured it to do:
Note how the full content of this email, specifically the verification link, is present in the newly created ticket. All that is left is just to copy and navigate to it:
From here you just go on and create any kind of phishing scheme, even targeting Salesforce customers directly with these kinds of emails:
And the above will end up in the victim's inbox, bypassing anti-spam and anti-phishing mechanisms, and even marked as Important by Google:
Full Disclosure to Salesforce
With the finding of the above, Guardio Labs contacted Salesforce to officially disclose the issue. Following the initial full disclosure on 28th of June ‘23, the security response team at Salesforce was prompt in reproducing the issue and moving on to remediation.
As of the 28th of July ’23, the vulnerability was resolved and a fix was deployed affecting all Salesforce services and instances. As we can see here when trying to set a “salesforce.com” email as an Organization-Wide Email address, the system will now check the validity of the domain in use against the approved domains list before even initiating the address verification process as earlier — leaving it impossible to use an address from the salesforce domain to send emails with:
The Salesforce Security team was effective and responsive, taking these kinds of issues very seriously and prioritizing accordingly:
At Salesforce, trust is our #1 value, and security is our top priority. We value the contributions of the security research community to help enhance our security efforts, and we are grateful to Guardio Labs for their responsible disclosure of this issue. Our team has resolved the issue, and at this time there is no evidence of impact to customer data. We continually encourage researchers to share their findings with our team at security@salesforce.com. (Salesforce)
At Guardio Labs, we greatly value our collaboration with the Salesforce security team. This partnership plays a pivotal role in enhancing the overall safety of the internet, making it increasingly difficult for cybercriminals to operate.
Getting Back to Facebook
And one last remaining debt, the abuse of apps.facbeook.com we witnessed in our phishing sample further down the road. As far as we know, there is no way to create those legacy game canvases under the Facebook eco-system anymore, as this feature retired starting in July 2020:
Yet, this campaign was live and kicking, giving it the power to insert malicious domain content directly into the Facebook platform — presenting a phishing kit designed specifically to steal Facebook accounts including 2FA mechanism bypasses.
According to the documentation provided by Meta, it is still possible to retain support for legacy games that were developed prior to the deprecation of this feature. Consequently, it appears that access to these accounts could prove valuable to malicious actors, thereby driving up the value of stolen accounts associated with gaming applications.
We’ve contacted Meta’s Engineering and security teams and provided all the details about this abuse, with it the team there quickly removed the malevolent accounts and web game and kept on investigating:
“We’re doing a root cause analysis to see why our detections and mitigations for these sorts of attacks didn’t work” (Meta’s Engineering)
While this kind of platform abuse is now hopefully a done deal, we still see a more “Old-fashioned” technique of being hosted as a webapp on Google’s Firebase and other simple hosting services that keep on bombarding email inboxes. These phishing landing pages stick with the same motive of a fake security risk that blocked your business/personal account on Facebook and asks you to provide (too many) details to the fake support teams:
All the above pages were spotted propagating with Salesforce exploited SMTP servers as well as with other mass email services. All are detected and blocked with our Email Protection here at Guardio.
Final Thoughts and Possible Remedies
The prevalence of phishing attacks and scams remains high, with bad actors continuously testing the limits of email distribution infrastructure and existing security measures. A concerning aspect of this ongoing battle is the exploitation of seemingly legitimate services, such as CRMs, marketing platforms, and cloud-based workspaces, to carry out malicious activities. This represents a significant security gap, where traditional methods often struggle to keep pace with the evolving and advanced techniques employed by threat actors.
It is imperative for these service providers to exercise additional caution and implement stringent measures to thwart such abuse. Taking proactive steps to keep scammers away from secure and reputable mail gateways is of utmost importance. This includes bolstering verification processes to ensure the legitimacy of users, as well as conducting comprehensive ongoing activity analysis to promptly identify any misuse of the gateway, whether through excessive volume or through analysis of metadata such as mailing lists and content characteristics.
Kudos to Salesforce and Meta’s Security teams for their prompt response to our discoveries and their ongoing efforts to enhance the security and resilience of their platforms against scammers’ attempts.
IOCs
Malicious Email Senders/Domains:
accviolation@21gjt96n3uz6hgxytsmo0tf72hqyt6wg3ifrbql7e7k1xfd9df.8e-sefdea4.um9.case.salesforce.com
*@1tawiicwxf2mrp7fd4repzfch96l9gtt1myvtiv2apknglhjwu.ho-18cikmaa.na232.le.salesforce.com
*@u-q6pb6lfa1ot5z8t71xk4j3bx76naw8uelmp1amymah4u3eeaz.hu-1phzsmak.na238.le.salesforce.com
*@i-9l2yj963pr7thwetz204690m6khza0kkq6i3aur57df94v241.hr-10outmam.na235.le.salesforce.com
*@1bi8v8qi7112kgzbabr8bnn0v18g2v2cb5scbqjfz00p1csn87.hp-1q004maa.na233.le.salesforce.com
Phishing Pages (Above Example):
https://apps[.]facebook[.]com/360554927295924
https://gulaqkogames[.]com
Other Campaign Related Phishing Domains:
fb-003applyonlines[.]web[.]app
facebook[.]com/104350419408426
facebook[.]com/124762450675931
qkemiskkd[.]top
aslpls[.]io
lucafaioni[.]com
g5e[.]tech
carlogamesaqol[.]com
panthergrandpa[.]com
metaoperations-inc[.]com
operations-ntfaccounts[.]com
page-account-restricted68540.firebaseapp.com
meta-business-appeal82[.]web[.]app
meta-business-appeal89[.]web[.]app
meta-business-appeal46[.]web[.]app
meta-business-appeal35[.]web[.]app
meta-business-appeal22[.]web[.]app
page-account-restricted68540[.]web[.]app/
case-report-1883849[.]com
pagerestricted-request-658021[.]web[.]app
pagerestricted-requestreview[.]web[.]app
meta-appeal-dashboard-5206-648[.]web[.]app
meta-appeal-dashboard-15689172[.]web[.]app
meta-appeal-request-1322951185[.]web[.]app
meta-business-appeal89[.]web[.]app
meta-business-security-6101621[.]web[.]app
meta-business-security-68420[.]web[.]app
meta-business-helpcenter-11694[.]web[.]app
metabusiness-109309686880[.]web[.]app
metabusiness-109309081074[.]web[.]app
metabusiness-10930909301[.]web[.]app
metabusiness-109680932[.]web[.]app
metabusiness-case189719825[.]web[.]app
meta-marketing-violation-57093[.]web[.]app
meta-appeal-review175980171[.]firebaseapp[.]com
meta-appeal-case151827296[.]web[.]app
meta-appeal-case167985122[.]web[.]app
meta-appeal-business-59049[.]web[.]app
meta-complain-copyright[.]com
business-request-review127989[.]web[.]app
business-account-15781759289[.]web[.]app