Yleinen Archives - Cloud Protection for Salesforce by WithSecure™

2025 was the year Salesforce breaches went from a niche security concern to front-page news.

In 2026, we’re still seeing the aftershocks. McGraw Hill. The European Commission. Grubhub. The list keeps growing, and the ransom demands keep landing. It is never a good situation to be in. But can we honestly say we didn’t see this coming?

A gap the industry created together

For years, Salesforce sat in a strange middle ground inside most organizations. Too important to ignore, but somehow never quite in the security team’s lane. The CISO owned the firewall and The IT team owned the endpoints, while Salesforce grew into one of the most data-rich systems in the company, expanding through automations, Experience Cloud sites, third-party integrations, and connected apps – each one broadening the footprint a little further.

The platform got more complex. The security visibility around it did not always keep up. That is the gap that 2025 exposed in a spectacular way.

ShinyHunters made it impossible to look away

Starting in mid-2025, the ShinyHunters group ran the most sustained, targeted campaign against Salesforce environments the industry had ever seen. What made it so damaging was how it exploited the complexity of modern Salesforce deployments, rather than any single flaw.

The early attacks used vishing. A phone call. Someone pretending to be IT support. An employee convinced to enter an OAuth code into what looked like a legitimate Salesforce Data Loader page. By September 2025, the group had shifted again, this time scanning for Experience Cloud sites with misconfigured guest user permissions and pulling CRM data directly through exposed API endpoints. No credentials required. By March 2026, they were claiming between 300 and 400 compromised organizations from that campaign alone. The tactics kept evolving. The target never changed.

McGraw Hill is the latest reminder

Earlier this month, McGraw Hill confirmed that ShinyHunters had accessed a Salesforce-hosted environment through a misconfiguration, leaking over 100GB of data tied to 13.5 million accounts. Names, addresses, phone numbers, email addresses –  all out in the open after ransom negotiations fell through.

The company noted that its core systems were not touched. But for the 13.5 million people now potentially exposed to phishing and identity fraud, that distinction offered little reassurance. This is not a story about one misconfiguration at one company. It is the same story the industry has been telling itself for over a year now, with a different name at the top each time.

That context matters. This is a systemic challenge, not a story about one org getting something wrong.

The real problem is detection

What these incidents share is a common theme: the gap between when access was gained and when it was discovered. The detection gap is where the real damage happens, and closing it is the conversation the Security and Salesforce teams need to be having right now.

Security teams have spent years building detection-first programs around endpoints and email, operating on the principle that prevention matters. But this is never the whole story. Threats get through.

What determines the outcome is how quickly you see them. That same principle applies to Salesforce, arguably more so given how much sensitive data now lives there. Customer records, financial data, healthcare information, pipeline data, PII at scale, all wired into marketing platforms, analytics tools, AI systems, and third-party apps. The data footprint of a typical enterprise Salesforce org is enormous, and it is connected to everything.

Seeing the full picture

Here is where Salesforce security gets genuinely difficult. Individual signals, taken in isolation, can look harmless. A user with broad permissions is not unusual. A connected app accessing data is expected. A credential that appeared in a third-party breach might belong to someone who changed their password years ago.

But when you start combining those signals, the picture shifts. A user with ModifyAllData permissions whose email address appeared in a recent breach is a very different conversation. That is not a theoretical risk. That is an open door, and the kind of exposure that’s almost impossible to see without a dedicated view across identity, permissions, and breach data simultaneously.

Help is at hand

That is the gap our latest release of Cloud Protection for Salesforce addresses. Identity Protection now brings those signals together in one place, giving administrators a clear view of which users warrant attention and why, so the exposure is visible before an attacker has the chance to map it out first.

The organizations that will come out of this period in good shape are not necessarily the ones with the biggest security budgets. They are the ones that applied the same detection-first thinking to their Salesforce environment that they built everywhere else years ago.

The question worth asking today is a simple one: if an attacker was quietly moving through your Salesforce org right now, would you know? If you are not sure, our free Salesforce risk assessment is a good place to start.
Phishing attacks are no longer confined to the inbox.

In April 2026, WithSecure Cloud Protection for Salesforce (CPSF) identified a phishing campaign that did not rely on spoofed emails or compromised infrastructure. Instead, it leveraged Facebook’s own notification system to deliver malicious content through fully authenticated, legitimate communications.

What initially appeared to be a standard phishing operation revealed a more sophisticated design upon closer inspection, not because of the phishing infrastructure itself, but because the attack operated entirely within trusted Facebook Business Manager workflows.

The malicious URLs were not distributed through spoofed or compromised email systems. Instead, they were embedded in legitimate emails sent directly from Facebook’s own infrastructure. These messages passed SPF, DKIM, and DMARC authentication without issue, making them indistinguishable from genuine communications at the email security layer.

Further analysis revealed that this campaign does not rely on a single attack path. Instead, it combines a shared injection technique, multiple delivery channels, and different attack objectives, all operating within trusted Facebook Business Manager workflows.

Key Takeaways
- Attackers are exploiting platform-native workflows rather than relying on traditional email spoofing
- A single template injection technique can be reused across multiple Facebook notification workflows to distribute malicious content
- Legitimate Facebook notification emails can be repurposed as phishing delivery channels
- The campaign supports multiple objectives, including credential harvesting and unauthorized access to business assets
- Detection must extend beyond email into business platforms where content is consumed and acted upon
Detection Context

The campaign was detected not at the email layer, but within Salesforce workflows where the content was ultimately consumed. WithSecure Cloud Protection for Salesforce classified the malicious URLs as Malicious:Network/Generic during content inspection as they propagated through business processes.

This reflects a broader pattern observed across multiple campaigns: attackers are designing threats to survive perimeter controls and rely on downstream interaction within trusted business systems.

Attack Model

This campaign is best understood across three layers:

Technique
- Template injection through Business Manager profile fields, allowing attacker-controlled content to be embedded in notification emails
Delivery Channels
- Partner access request notifications, which target organizations, can lead to credential compromise or unauthorized access if approved
- Business portfolio user invitations, which target individual users, are primarily used as a phishing delivery mechanism
Objectives
- Credential harvesting through phishing pages designed to capture user credentials and MFA codes
- Unauthorized access to business assets through approved partner relationships within Facebook Business Manager
The attacker reuses the same injection technique across multiple Facebook workflows to distribute malicious content through trusted communication channels. Rather than following a single linear path, the attack leverages different workflows to achieve different outcomes depending on how the victim interacts.

Attack Flow: Template Injection Across Multiple Workflows

The diagram below illustrates the conceptual model of the attack, starting from the injection technique and branching into multiple delivery workflows.

Facebook Business Manager Attack Flow

Step 1: Template Injection Setup

The attacker creates or compromises a Facebook Business Manager account.

Business Portfolio Information

Step 2: Delivery Mechanisms

The attacker selects one of two delivery mechanisms:

A: Partner Access Request
- Objectives: Account Access, Credential Phishing
- Target: Organizations with Business Manager accounts
- Lure Themes:
  
  “Meta Agency Partner Program“ presents targets with a “Partnership Registration Form” and a “Join Meta Agency Program” call to action
  
  “Account deletion / locked within 24 hours” uses urgency and an “Appeal Form”
- Attacker identifies target organizations’ business IDs via publicly accessible information
- Sends a legitimate partner access request, often requesting broad permissions across multiple business assets
- Facebook delivers an authenticated notification email
Access Request Process

Permission request includes full access control

If approved, the attacker gains authorized access. This requires minimal reconnaissance: only a Page ID or Ad Account ID is needed, which is often publicly accessible.

Impact:
- No credential theft required
- Access appears legitimate in audit logs
- Persistence remains even after password changes
- Enables control over ad accounts, pages, and associated assets
This is functionally similar to Business Email Compromise (BEC) but executed entirely within platform-native workflows.

B: Business Portfolio User Invitation
- Objective: Credential Phishing
- Target: Any user via email address
- Lure Theme: “Free verified blue badge” exploits aspiration for account credibility to trigger action
- Sends a legitimate invitation to join the attacker’s business portfolio, targeting users via email
- Facebook sends a legitimate invitation email
Business Portfolio User Invitation Form

Step 3: Template Injection in Notification Emails

In both delivery paths, Facebook inserts attacker-controlled business profile information directly into its email templates without sanitization. This allows phishing URLs and social engineering content to appear seamlessly within legitimate notification emails.
Sample Email Via Partner Access Request
Sample Email Via User Invitation

Step 4: Target Interaction

The target receives a legitimate Facebook email and interacts with it:

Path 1 — Phishing:
- Target clicks embedded link in the message
- Redirected to cloned Meta portal
- Target is prompted to provide personal information and credentials
- Personal data, credentials, and MFA codes are submitted
Loading page

Fake Meta Page for Meta Agency Partner Program Lure

Fake Meta Page for Page Deletion Lure

Fake Blue Badge Lure

Fake Partnership Registration Form

Fake Appeal Form

Fake Blue Badge Form

Password Prompt

MFA Prompt

MFA Prompt

Path 2 — Access Approval:
- Target clicks “View request” directly from Facebook email notification
- Approves partner access
Partner Access Request Link

Step 5: Outcomes

Credential harvesting path:

The attacker can use the collected identity data for:
- Account recovery abuse and full account takeover of compromised Facebook identities
- Reuse of collected identity data across other platforms or social engineering campaigns
- Perform ad fraud using compromised business assets and advertising accounts
- Resell access to compromised accounts or business assets for financial gain
Access approval path:
- The attacker gains sanctioned access within Facebook’s own platform
- No credentials stolen
- Access persists even if the user later changes their password
- The attacker can access Pages, Ad Accounts, Pixels, or whatever the target approves
- It looks like a legitimate business relationship in Facebook’s audit logs
These attack paths collectively result in:
- Social engineering content embedded in trusted communication
- Phishing URLs delivered through authenticated infrastructure
- Increased credibility due to platform branding
This is not a traditional vulnerability, but rather an abuse of unvalidated input within a trusted workflow.

Detection Telemetry

This threat is covered by our generic detection, Malicious:Network/Generic.

Detection telemetry indicates activity as early as May 2025, with a significant increase from March 2026 and a peak in April 2026. This gradual ramp-up suggests iterative refinement of the technique rather than opportunistic use.

Detection Activity Trend

Domain Usage

Domain age analysis reveals a consistent operational pattern:
- 96.4% of domains were registered within the last 7 days of being observed in customer environments
- 3.15% were between 8 and 14 days old
- Only a negligible proportion exceeding 90 days
This concentration in newly registered domains is operationally significant. At a domain age threshold of ≤7 days, this control alone would have covered the vast majority of observed detections.

For organisations seeking an additional defensive layer against campaigns relying on fresh infrastructure, enabling domain age filtering represents a low-friction, high-coverage mitigation.

Domain Age Blocking in CPSF Configuration

How This Differs from Previous Campaigns

While this campaign shares similarities with previously observed Microsoft 365 phishing activity, particularly the use of trusted infrastructure, it introduces several notable differences:
- The attack operates entirely within platform-native workflows rather than relying solely on email delivery channels such as email attachments or calendar invites
- A single template injection technique is reused across multiple notification workflows, enabling consistent delivery of malicious content through different contexts
- Multiple delivery channels are leveraged simultaneously, including both organization-targeted and user-targeted workflows
- Attacker-controlled input is rendered inside legitimate platform notifications, effectively turning trusted templates into delivery mechanisms
- Successful compromise may not involve credential theft at all, instead relying on user-approved access grants that persist within the platform
Conclusion

This campaign reinforces a broader trend: attackers are increasingly operating within trusted systems rather than attempting to evade them. By exploiting multiple Facebook Business Manager workflows, the attacker transforms legitimate platform functionality into both a delivery mechanism and an attack surface. The ability to combine multiple workflows with different objectives, ranging from credential harvesting to unauthorized access, significantly increases both reach and effectiveness.

As demonstrated in this campaign, detection occurred not at the point of delivery, but within Salesforce workflows, where the content was ultimately consumed and acted upon. This highlights a fundamental shift: perimeter controls alone are insufficient when threats are designed to appear indistinguishable from legitimate platform activity.

Effective security must extend into business applications and workflows, where trust, context, and user interaction converge and where modern attacks are ultimately executed.

Recommendations

Governance and Access Control
- Define strict approval processes for Facebook Business Manager partner requests
- Treat partner access as equivalent to third-party vendor onboarding
- Limit approval authority to a controlled set of users
Monitoring and Audit
- Regularly audit Business Manager partner relationships
- Remove unrecognized or unnecessary access
User Awareness
- Train marketing and social media teams on platform-native attacks
- Emphasize that legitimate emails can still contain malicious content
Technical Controls
- Enable domain age filtering (e.g., block domains <7 days old)
- Implement content-level URL inspection across business platforms
- Extend detection beyond email gateways into SaaS environments
Operational Practices
- Treat unsolicited partner requests as suspicious by default
- Validate requests through independent communication channels
- Establish incident response playbooks specific to SaaS platform abuse
Indicators of Compromise
- member365[.]agency-partner-register[.]com
- pagequalitycenter[.]click
- pageoperationscenter[.]click
- pageperformancecenter[.]click
- trustedpageportal[.]click
- trustedpagesupport[.]click
- controlreport[.]click
- supportcenter[.]agency-partner-community[.]com
- smart-service-portal[.]help
- support254[.]agency-partner-manage[.]com
- online-service-portal[.]help
- contactauthcenter[.]click
- contactpagesupport[.]click
- helpforpage[.]online
- transparency-violations-compl[.]click
- freebluecheckfanpage[.]click
Here is what’s new in Sirius 3.2 and why it matters.

The threat Salesforce can’t see

Salesforce orgs are more complex than ever. Employees, contractors, partners, community users, AI agents — all operating with different levels of access inside your org. Every one of these identities has permissions. Permissions accumulate. Teams change. Nobody cleans up.

The result is a reality most Salesforce admins don’t have a clean answer to: who in your org has access they shouldn’t? And if one of those users had their credentials exposed in a third-party breach, would you know?

Stolen logins are behind 22% of all data breaches globally (Verizon DBIR 2025), and Salesforce has no native way to detect whether your users’ credentials have been compromised elsewhere. That’s the gap Identity Protection was built to close.

Identity Protection continuously monitors your Salesforce users against known breach databases, covering both internal employees and external community users, and surfaces compromised accounts before attackers can exploit them.

One view of every user that should be on your radar

Identity Protection gives administrators a single overview of every user that warrants attention, whether that’s because their email appeared in a data breach, because they’ve been assigned permissions that give them too much power, or because they’re missing a Cloud Protection license and flying under the radar completely.

But here’s what makes it really powerful. When you drill into a user, you don’t just see that they’re a risk; you see what they’ve been doing. What files have they uploaded or downloaded? What URLs have they accessed? What apps are connected to their account? This lets you map the potential impact of a compromised identity: what an attacker could reach, what may have already been touched, and where to focus your response.

Identity Protection 2.0: more visibility, faster response

Version 3.2 is a significant upgrade. Administrators can now see exactly which users carry excessive permissions and take action to enforce least privilege without leaving the dashboard. Reset passwords or freeze and unfreeze accounts directly from the Identity Protection interface and get email notifications when new breached user data is detected, so you’re never the last to know.

Not yet using Identity Protection? [Learn how to get started] or book a demo to see it in action.

Macro detection in files: flag the threat before it executes

Macros embedded in Microsoft Office and PDF files are one of the most common ways malwares get delivered, and they’re dangerous even when the file doesn’t contain malware at the time of scanning. Until now, files were only flagged when malicious content was actively detected.

Version 3.2 changes that. Files containing macros are now flagged regardless of whether malware is present, giving administrators the option to block or alert macro-containing files based on their organization’s risk tolerance.

A more reliable auto-update experience

Behind the scenes, the auto-update infrastructure has been redesigned for improved reliability. Administrators now have access to trail logs showing update history and will be alerted if an auto-update fails, so issues can be resolved quickly.

Available on AppExchange

Version 3.2 is available now. Here is when to expect updates:
- Available on AppExchange: April 20, 2026
- Automatic updates, sandbox environments: May 11, 2026
- Automatic updates, production environments: June 1, 2026
Already a customer? See the [Version 3.2 release notes] for the full technical details.

Not yet a customer? We’d love to show you what it can do for your organization. Book a demo and we’ll walk you through it personally. [Book a demo]

Our mission: security that keeps up with Salesforce

Salesforce is no longer just a CRM. It’s the operational backbone of modern businesses, running sales, service, marketing, and increasingly, AI-driven workflows. The attack surface has grown with it.

Our mission is to make sure security keeps pace. Every release we ship is a step toward a Salesforce environment where admins have full visibility into who is at risk, what an attacker could reach, and what to do about it. All without leaving the platform they already work in every day.

Version 3.2 is another step in that direction. We’re not done.
Phishing attacks are no longer confined to the inbox.

By combining legitimate Microsoft 365 infrastructure, HTML-based credential harvesting, and calendar invite abuse, this campaign achieves high delivery success and multiple opportunities for user interaction.

Notably, this activity was also observed propagating through Salesforce workflows, introducing a trusted business context that can further reduce user suspicion.

Key takeaways
- Attackers leveraged Microsoft 365 infrastructure to improve phishing email deliverability
- HTML attachments delivered credential-harvesting pages impersonating Microsoft services
- Calendar invites (ICS files) introduced a secondary interaction channel
- The campaign was observed within Salesforce workflows, where business context increases user trust
- The attack relies on abusing trusted platforms and user interaction rather than exploiting vulnerabilities
Timeframe and Scope

The earliest confirmed activity dates to September 2025, with the campaign still active as of today, 17 April 2026.

Most observed telemetry is concentrated in US-based organizations, with additional activity identified across Europe and other regions. Target organizations span multiple sectors, including legal services, financial services, manufacturing, education, and consumer goods.

The distribution of targets suggests an opportunistic campaign, rather than one focused on specific industries or geographies.

Social engineering lures

The campaign uses multiple convincing themes:

Domain expiry / renewal failure — urgent warnings of service disruption

Microsoft subscription payment failure — billing issues affecting service continuity

Payroll report delivery — impersonation of internal payroll communications

SharePoint file sharing — fake collaboration requests

Academic invitations — targeted institutional messaging

Example phishing email

Example phishing email

These lures rely on urgency or contextual authority to drive immediate action.

Email authentication evasion

The campaign achieves delivery by operating within the constraints of email authentication rather than bypassing them outright.

The sending domains were configured with the following SPF record:

v=spf1 include:spf.protection.outlook.com ~all

This configuration has several implications:
- Microsoft 365 infrastructure is explicitly authorized to send on behalf of the domain
- The ~all (softfail) policy allows messages to proceed even if SPF checks fail
- No DMARC policy is defined, leaving enforcement to receiving systems
This is the SPF result for one of the sender IP observed in the email headers:

Sender IP (146.20.65.91) fails SPF authentication for the domain, yet the email was still delivered due to the softfail policy and DKIM pass.

In observed samples, the sending IP failed SPF validation, but the message was still delivered because:
- DKIM validation succeeded (the attacker controls the signing domain)
- No DMARC policy enforced rejection
- Composite authentication results appeared acceptable to filtering systems
This shows that passing authentication checks does not indicate legitimacy. It only means that the message conforms to the authentication model.

M365 Tenant Abuse

The phishing emails were routed through Microsoft 365 tenant infrastructure.

Attackers likely registered or acquired tenants via free trials, compromised accounts, or underground markets, and used them to send messages through legitimate Microsoft infrastructure.

Microsoft-generated header fields observed in the emails identify the authenticated tenant associated with the sending session. These fields are written by Microsoft systems and cannot be forged externally, confirming the use of genuine tenant infrastructure.

Example Tenant ID used by threat actor

Email attachments: dual delivery approach

Each phishing email contains two attachments:
- HTML file — primary credential harvesting payload
- iCalendar (.ics) file — secondary delivery vector
This dual-delivery approach increases resilience against single-channel defenses and creates multiple interaction paths for the recipient.

HTML Attachment: Credential Harvester

The HTML attachment presents a fake Microsoft login experience.

When opened, it:
- Displays a Microsoft-branded loading sequence
- Dynamically generates attacker-controlled subdomains
- Loads a phishing interface designed to capture credentials
Fake loading process

Fake loading process

Fake login prompt

Fake login prompt

In addition to generic Microsoft-themed pages, some HTML attachments are tailored to specific scenarios, including domain renewal or subscription notices impersonating providers such as GoDaddy.

Fake GoDaddy login page

This phishing kit also tracks user interaction by issuing requests to attacker-controlled endpoints over non-standard ports (e.g., 8443, 2083), using URL paths such as /impact and /track-click. This allows the operators to monitor engagement and potentially tailor subsequent stages of the attack.

Tracking endpoint URL format

Tracking endpoint URL format

Calendar Invite: Secondary Delivery Vector

The iCalendar (.ics) attachment is delivered as a meeting request.

Because ICS is widely supported across platforms (Outlook, Google Calendar, Apple Calendar, and mobile clients), it provides a reliable cross-platform delivery mechanism.

Depending on email client behavior and configuration:
- Events may be automatically added to the calendar
- Events may appear upon preview or interaction
- Users may engage without explicitly accepting the invite
Calendar invite

Calendar invite added to calendar

The ICS attachment itself does not contain executable malicious content. Instead, it functions as a social engineering and delivery mechanism, guiding the user toward the phishing payload.

Observed in Salesforce workflows

We have observed this campaign within Salesforce workflows. This is significant because Salesforce operates within a trusted business context, where users expect legitimate operational content. Content appearing in CRM workflows aligns with expected business activity, which can reduce user skepticism.

In this context:
- Phishing content appears consistent with legitimate workflows (e.g., invoices, payroll, document sharing)
- The delivery channel reinforces perceived legitimacy
- The attack may fall outside traditional email-focused threat models
The phishing payload itself behaves the same regardless of delivery channel. However, delivery through Salesforce increases the likelihood of user interaction due to contextual trust.

Detection

WithSecure Cloud Protection for Salesforce detects the malicious HTML attachments associated with this campaign as PHISH/HTML.Agent.

This detection targets credential-harvesting pages that:
- Dynamically generate attacker-controlled URLs
- Impersonate Microsoft authentication portals
- Capture user credentials
Conclusion

This campaign demonstrates how attackers increasingly operate within trusted systems rather than attempting to evade them directly.

This approach reduces reliance on traditional evasion techniques and instead exploits trust in widely adopted platforms.

By combining these techniques, the attackers create messages that appear technically legitimate:
- Legitimate Microsoft 365 infrastructure
- Weak or absent DMARC enforcement
- Valid DKIM signatures
- Multi-channel delivery (email and calendar)
The observation of this activity within Salesforce workflows highlights a broader shift: Phishing threats are no longer limited to email. They are extending into business applications where users inherently trust the context.

As attackers continue to leverage trusted platforms and workflows, organizations that focus solely on email security risk overlooking exposure in systems that are deeply embedded in day-to-day operations.

Recommendations
- Treat urgent service-related emails and calendar invites with caution
- Avoid opening HTML attachments claiming to be Microsoft login portals
- Access Microsoft services directly via official domains
- Review calendar auto-acceptance settings
- Do not rely solely on SPF/DKIM/DMARC results as indicators of trust
Indicators of compromise

The following indicators were identified through analysis of the campaign samples.

Note that infrastructure indicators (IPs, domains, tenant IDs) are subject to rotation by the attackers.
- M365 Tenant IDs:
- 6449efea-a175-42ba-b4fe-aaf702600f14
- 7c8f16fe-b88a-438e-850b-cc8160aefa6d
- d87ee9b3-0568-4108-9977-1462d082e09b
- 0714db3d-882f-41c4-8579-3146af5c2abb
- IP addresses:
- 146.20.65.91
- 146.20.87.4
- 31.58.144.13
- Domains:
  anaksakti77[.]org
  touchepasamonflic[.]fr
  klinikdrdewi[.]com
  haoranchalerkotha[.]com
  khaskhoborbd[.]com
  bhkbbmta110[.]com
  cash4d10[.]xyz
  blitz168asia[.]com
  blitz168app[.]com
  walshmanagement[.]ca
  doctorsbusinesshub[.]com
  anaksakti[.]online
  automedsos[.]com
  richalfahad[.]com
  bishalacademy[.]com
  uttarabusinessclub[.]com
  cloudeducation[.]xyz
  nexgenictchampsolympiad[.]com
  102naga26[.]com
  igromaster[.]info
  n8nblitz[.]sbs
  waroengindo89[.]com
  ytccomputer[.]com
  css.nokhbabd[.]com
- Filename patterns:
  Admin_Center_MSA[username]_[digits]_.htm
  Admin_Center_[name]_[digits]_.htm
  Online admin center [random].PDF.HTM
  SharePoint_Workspace_Team_review, [timestamp]-[digits].htm
  Ms-Portal-SupportHub_[encoded].htm
  TUlNRS1WZXJzaW9uOiAxLjAKQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw (base64 decodes to “MIME-Version: 1.0\nContent-Type: text/html”)
  Remittance_Review_[string].htm
  PayOps Asset Ltd – RTI Full Payment Submission (FPS) for [month]_[random].htm
  ABH Asset Ltd – RTI Full Payment Submission (FPS) for [month]_[random].htm
The introduction of this native malware scanner reflects the continued evolution of security capabilities within SaaS platforms, as vendors respond to changing threat landscape and customer requirements.

With this addition, security teams naturally want to understand how this capability behaves operationally, particularly when files are uploaded through different workflows and when malicious content is encountered.

As part of our regular threat coverage validation program, where we periodically assess our own detection quality, we also evaluated the Salesforce Malware Scanner.

Why file security in Salesforce matters

Salesforce environments frequently store and distribute files as part of everyday workflows. These files may include:
- Office documents
- PDF files
- Archive files
- Images
Threat actors increasingly use these file types as delivery mechanisms. Instead of distributing standalone malware, attackers often rely on documents containing embedded links, redirect chains, or other mechanisms that lead users to malicious infrastructure.

Some common techniques include:
- Documents containing embedded phishing URLs
- Archive files used to bypass simple file inspection
- Multi-stage payload delivery (document → link → payload)
- Image-based lures such as QR-code phishing (“quishing”)
Because of these patterns, file security inside SaaS platforms has become an important layer of organizational defense.

How Salesforce Malware Scanner works

Testing revealed several behaviors related to how Salesforce Malware Scanner evaluates uploaded files.

It is important to note that this malware scanning capability applies only to files stored in Salesforce Files. Some environments still make use of the legacy Attachment object, which is not covered by this scanning capability.

Synchronous scanning for UI uploads

When files are uploaded through the Salesforce user interface, the malware scanner performs a synchronous scan.

If the file is identified as malicious during this scan, the upload is blocked immediately and the file is never stored in the Salesforce environment.

UI upload block message

This approach prevents malicious files from entering the platform but also means that blocked uploads do not appear in administrative detection views.

Asynchronous scanning for API uploads

Files uploaded through API workflows, such as via Data Loader or integrations, are handled differently.

In these cases, the file is first stored in Salesforce and the malware scanner then performs an asynchronous scan.

This means that potentially malicious files uploaded using APIs may temporarily be accessible in the environment before the scan completes.

If the file is later determined to be malicious, the file is flagged and prevented from being previewed.

Preview block message

Detection visibility and administrative actions

Detection records in Salesforce represent malware scan results. When files are detected asynchronously, they appear in the Malicious Files (Beta) view, where administrators can review flagged files.

Detected files view

Administrators also have the ability to mark files as safe if the detection is determined to be incorrect. During testing, we observed that doing so removes the corresponding entry from this view, meaning the interface primarily reflects current detections rather than a persistent historical log.

Marking as safe

In addition, subsequent access attempts, such as users attempting to download a flagged file, are not recorded as separate security events, limiting visibility into how the file was accessed after detection.

For organizations performing incident investigation or audit review, these distinctions may affect how security events are tracked and analyzed.

Download enforcement behavior

Once a file has been flagged as malicious, download enforcement depends on user permissions.

Standard users attempting to download a flagged file receive a block message preventing access. Administrative users, however, may still be able to download the file depending on their permissions.

Download block message

This behavior allows administrators to investigate files if needed, while preventing general users from accessing potentially malicious content.

Threat coverage observations

While the previous sections describe how the scanner behaves operationally, the following observations relate to how it performs against common threats.

During this threat coverage validation cycle, a dataset of samples representing common threats in Salesforce environments was evaluated. These primarily included Office documents, PDFs, archives, and image-based lures.

Salesforce Malware Scanner detected a small portion of the evaluated samples, identifying only 3 out of 85 malicious samples (3.5%), primarily those containing high-confidence indicators such as exploits or macro code. However, many modern threats rely on multi-stage delivery mechanisms in which the document itself acts as the initial stage of the attack. These documents often contain embedded URLs that redirect users to external infrastructure where additional payloads or phishing activity occurs.

This presents a key challenge for file-based security, as the malicious activity may not be fully visible within the file itself.

Layered protection in SaaS environments

Several operational observations from testing highlight how the Salesforce Malware Scanner behaves in practice:
- Detection focused on high-confidence malicious files
- Different behavior between UI and API upload workflows
- Detection records reflect scan results but not subsequent access attempts
- Detection records are removed when files are marked as safe
- Limited visibility into detection context and historical detection activity
Because many of the threats extend beyond the initial file, organizations often implement layered protection strategies around their SaaS platforms.

Layered protection solutions can complement built-in controls by providing capabilities such as:
- Deeper inspection of files and embedded links
- Detection of redirect chains and staged payload delivery
- Quarantine and mitigation of malicious content
- Operational visibility into detection events and file activity
In practice, these capabilities enable security teams to observe how threats progress beyond the initial file and provide additional context for investigation and response.

This becomes particularly relevant as many modern attacks rely on URL-based delivery stages. In our recent Threat Landscape Report, the majority of observed threats targeting Salesforce environments originated from URLs (98%), while a smaller portion were initially delivered as files (1.74%).

Conclusion

Salesforce Malware Scanner introduces a baseline capability for detecting malicious files uploaded into Salesforce environments. During testing, the platform demonstrated the ability to block high-confidence malicious files and enforce access controls when flagged content is encountered.

At the same time, modern threats increasingly rely on multi-stage delivery techniques and external infrastructure, where the initial file acts only as the first step in a broader attack chain.

As Salesforce environments increasingly support business-critical data and processes, the security controls protecting them are expected to meet enterprise-grade requirements.

Enterprise-grade security solutions are designed to provide comprehensive detection coverage, investigation context, mitigation, and operational visibility, with investment aligned to the level of protection required for these business-critical environments.

This built-in Salesforce capability, in contrast, provides a baseline level of protection as part of the broader service offering, with inherent limitations in detection scope and operational visibility. A detailed comparison of these capabilities can be found in our feature comparison page.

Understanding how these protections behave in real workflows helps organizations make informed decisions about protecting their Salesforce environments.
Overview

When a global brand discovered malicious attachments and URLs slipping past its email security defenses and into Salesforce, it faced a dilemma: maintain critical customer communication workflows or close a dangerous security gap.

As part of a global system managing complex supply chains and partner relationships across multiple continents, maintaining secure yet accessible communication channels is business-critical. The company operates multiple Salesforce instances across multiple business units to handle internal service requests and external customer interactions.

By partnering with WithSecure Cloud Protection for Salesforce, the company gained the visibility and control it needed to secure files and links uploaded through email-to-case—without disrupting vital customer communication channels.

The challenge: The email-to-case security gap

Salesforce plays a central role in the company’s daily operations, supporting internal ticketing and service requests while also serving as a key touchpoint for stakeholders around the world.

However, this broad connectivity created an unexpected risk. Emails sent from external users—often containing attachments or URLs—were automatically converted into Salesforce cases. Unlike standard email gateways, Salesforce’s email-to-case mechanism bypassed existing email security filters.

As a result, malicious links and attachments regularly reached users inside Salesforce, leading to security incidents including credential phishing attempts and potential malware infections. The cybersecurity team was responding reactively to threats that had already reached users—a situation that risked both data security and business continuity.

“We had strong protections on email,” explains the company’s representative, “but email-to-case wasn’t part of that pipeline. Salesforce simply didn’t scan or detect threats in the same way—and turning off the feature wasn’t an option because we rely on it to support customers.”

The team needed a way to maintain its external communication workflows while ensuring that every file and URL entering Salesforce was safe.

The solution: In-platform protection that fits existing workflows

After evaluating several vendors, the company selected WithSecure Cloud Protection for Salesforce to secure its Salesforce environments.

The solution was deployed as a native Salesforce package, requiring no additional infrastructure or complex setup. Once installed, it automatically intercepts and scans all files and URLs—including those from email-to-case workflows—in real-time, before users can access them. Suspicious content is quarantined automatically while clean files flow through without delay.

“The deployment was smooth and straightforward,” notes the interviewee. “It fit right into our existing Salesforce setup without extra infrastructure. We quickly saw reduced risk and greater visibility across the environment.”

The results: Measurable security improvements and product innovation

The collaboration not only closed an immediate security gap but also led to joint innovation. As one of the early adopters of Cloud Protection for Salesforce, the company worked closely with WithSecure to share emerging threats observed in its environment—including QR code–based phishing attempts.

Through this collaboration, WithSecure was able to introduce QR code scanning capabilities into its protection engine—a feature that now benefits all customers.

“We were seeing more QR-based attacks coming through email,” the representative says. “By sharing what we were finding, WithSecure quickly added QR code detection into their product. That openness to feedback and rapid response really strengthened both our security and theirs.”

Looking ahead: A partnership built on shared responsibility

The company continues to work closely with Salesforce and WithSecure to ensure its environment remains secure as use of AI and automation expands.

” Partnerships like this aren’t optional—they’re essential,” the representative concludes. “As we expand our use of AI and automation in Salesforce, having purpose-built security that evolves with emerging threats gives us confidence to innovate safely. That shared responsibility—each focusing on their strengths—is what keeps environments like ours safe.”
Last week, Salesforce publicly disclosed unusual activity related to Gainsight applications connected to customer Salesforce environments. The investigation is still ongoing, but Salesforce’s initial findings indicate that this activity may have enabled unauthorized access to certain Gainsight customers’ Salesforce data via the app’s connection.

In response, Salesforce revoked all active access and refresh tokens associated with the Gainsight applications and temporarily removed the apps from the AppExchange as a precaution. Salesforce also clarified that there is no evidence of any vulnerability within the Salesforce platform itself.

Gainsight has confirmed that they are conducting a full forensic investigation to understand the root cause, impact and scope of the incident.

Why organizations should pay attention
- This is a connected-app compromise, not a Salesforce platform issue.
  Incidents involving third-party vendor integrations highlight that the connected-app layer must be treated as part of an organisation’s security perimeter.
- Some characteristics resemble previous campaign.
  The previous campaign involving Salesloft Drift used stolen OAuth tokens connected to Salesforce integrations. While the Gainsight investigation is not yet complete, some similarities have been observed. Gainsight was among the organisations affected in the Drift breach, but at this point, there is no confirmation that the previous incident led to or caused the current one.
- The investigation remains open and attribution is not final.
  Key details (including root cause, scope of data access and final attribution) are still unconfirmed, though the threat actor group ShinyHunters has publicly claimed responsibility.
What organizations should do right now
- Inventory all integrated apps: Identify all Gainsight-published applications and other high-risk connected apps within your Salesforce environment.
- Review permissions and scopes: For each connected app, verify the OAuth scopes and access rights. Remove or restrict any that are unused or over-privileged.
- Rotate credentials and tokens: Consider rotating OAuth tokens, API keys and integration credentials.
- Check telemetry and logs: Examine Salesforce audit logs, connected‐app usage logs, API call history for anomalies during the window of exposure.
- Strengthen vendor-integration governance: Ensure that your third-party app approval processes, monitoring measures and ongoing-security reviews include integration-level access and not just vendor-level risk.
Where to watch for updates
- Advisories from Salesforce
  - Security Advisory: Unusual Activity related to the Gainsight application
  - Trust Status
- Findings from Gainsight
  - Gainsight Status
This incident highlights a growing reality in SaaS ecosystems: the security boundary extends beyond the core platform to every integration, connected app and token behind it. For organisations using Salesforce, the most effective immediate step is to strengthen visibility, governance and control at the integration layer.
Artificial intelligence has transformed healthcare in ways few could have imagined just a decade ago. What began as predictive analytics powering dashboards has now evolved into autonomous AI agents operating inside Salesforce environments. These agents never sleep—they schedule patients, route urgent cases to clinicians, and update electronic health records around the clock.

The efficiency gains are undeniable. But the risks are equally real. AI agents process malicious file uploads with the same precision as legitimate patient documents. They don’t question context or recognize when something feels wrong. For healthcare security leaders, this represents a fundamental shift: patient data must be protected in an environment where AI acts independently, without human intuition.

Healthcare AI risk management now requires understanding how autonomous agents operate within clinical workflows and what happens when HIPAA compliance intersects with real-time patient care.

From predictive to autonomous

For years, AI in healthcare was about analysis. Systems generated dashboards, flagged risks, and suggested optimizations. Humans stayed in the loop, applying context and judgment before taking action.

While many organizations still maintain oversight for critical decisions, the trend toward autonomy is accelerating. Even human-in-the-loop systems face new security challenges when AI processes the initial inputs.

Today’s Salesforce-enabled healthcare AI agents:
- update patient records directly
- trigger clinical workflows without oversight
- engage with patients across multiple channels
- integrate with external healthcare systems
This shift—from predictive to autonomous—is more than just technological progress. It’s a paradigm change in security. Humans bring something irreplaceable: the ability to reflect and escalate when something seems off. AI agents, however sophisticated, lack that skepticism. In healthcare, where mistakes can compromise patient safety or trigger devastating regulatory violations, that gap matters.

Why healthcare data is a prime target

Healthcare Salesforce environments are treasure troves for attackers. They contain:
- complete patient demographics
- clinical notes and provider schedules
- insurance and billing data
- research participant records
This isn’t just PII—it’s the most sensitive personal data imaginable. Breaches here don’t just create financial costs; they erode patient trust, damage reputations, and invite regulatory action. HIPAA violations can run into millions. GDPR fines can reach billions. HITECH penalties compound rapidly.

AI introduces new attack surfaces: malicious patient uploads designed to exploit AI processing; over-privileged agents with more access than needed; crafted prompts that manipulate algorithmic responses; and patient-facing AI interfaces that accidentally expose protected health information.

Why legacy security falls short

Most healthcare providers still rely on perimeter defenses—firewalls, endpoint protection, email filtering. These remain important, but they weren’t built for the AI era.

Here’s why:
- Salesforce AI challenges arise inside the platform, bypassing traditional perimeter tools
- AI behavior patterns differ dramatically from humans, making anomalies harder to detect
- under the shared responsibility model, Salesforce secures infrastructure, but customers must secure application-layer access and data
The result? Traditional tools can’t reliably detect malicious AI behavior. Security leaders need visibility and controls that live where AI operates—inside Salesforce itself. Healthcare organizations should explicitly clarify with Salesforce which AI security controls are included versus which require third-party solutions.

Five principles for healthcare AI risk management

Through research and industry conversations, five best practices are emerging as essential for securing Salesforce AI in healthcare:
- Zero-trust agent access: Inventory every AI agent and grant only the minimum permissions required. Privilege creep occurs quickly and often unnoticed.
- External input validation: AI can’t spot suspicious files or prompts on its own. Platform-level scanning is essential to detect malicious payloads and injection attempts.
- Context-aware authentication: Not all data requires equal protection. Adaptive authentication—such as flagging bulk exports or unusual access times—adds crucial safeguards.
- Separate AI behavior monitoring: Don’t lump AI and human activity together. Track agent volumes, access patterns, and error rates separately to reveal anomalies.
- Compliance transparency: Document how each agent processes data and maintain audit trails regulators can follow. Transparency is fast becoming a compliance requirement.
The leadership checklist

Healthcare leaders can start by asking three critical questions about their Salesforce AI security posture:
- Can we list every AI agent in our Salesforce environment and identify what data it accesses?
- Do we validate external inputs before AI processes them?
- Could we demonstrate HIPAA, GDPR, and FDA compliance for all AI operations if regulators arrived tomorrow?
If the answer to any is uncertain, there are likely critical gaps between current defenses and what AI-era healthcare demands.

For resource-constrained organizations, prioritize based on risk exposure: start with agent access controls and input validation, then layer in advanced monitoring as capacity allows.

Balancing innovation with HIPAA compliance

Here’s the challenge: healthcare can’t slow down. Patients expect instant, personalized service. Rising administrative costs demand automation. Clinical workflows benefit enormously from AI assistance. Competitive pressures make adoption mandatory.

But rushing AI deployment without security frameworks is a dangerous gamble. The solution isn’t to hit pause—it’s to build security architectures that enable safe, rapid adoption. The initial investment in AI-ready security typically pays for itself by avoiding the higher costs of retrofitting security later—not to mention potential breach costs that average $10.93 million in healthcare.

Organizations that invest in AI-ready security now gain the flexibility to embrace new capabilities with confidence. Those that delay risk being forced into a painful trade-off: slow innovation to patch security gaps, or accept escalating risks.

Expert voices: Insights from Salesforce

On our Guardians of Salesforce podcast, Doug Cox, Distinguished Security Architect at Salesforce, shared practical strategies for securing healthcare AI. He explained how organizations can combine zero-trust access, input validation, and behavior monitoring to protect both patients and compliance standing.

🎧 Listen to the full episode

Related insights
- Securing Healthcare AI in Salesforce | Free eBook
- Salesforce Attacks in 2025: Why, How and What’s Next – Explore the evolving tactics behind Salesforce breaches.
- Secure-by-Design: How to Protect Agentforce in Salesforce – Best practices for building safe, autonomous workflows.
- Salesforce Security Buyer’s Guide 2025 – Compare approaches to securing Salesforce data and AI operations.

A gap the industry created together

ShinyHunters made it impossible to look away

McGraw Hill is the latest reminder

The real problem is detection

Seeing the full picture

Help is at hand

Phishing attacks are no longer confined to the inbox.

Key Takeaways

Detection Context

Attack Model

Attack Flow: Template Injection Across Multiple Workflows

Step 1: Template Injection Setup

Step 2: Delivery Mechanisms

Step 3: Template Injection in Notification Emails

Step 4: Target Interaction

Step 5: Outcomes

Detection Telemetry

Domain Usage

How This Differs from Previous Campaigns

Conclusion

Recommendations

The threat Salesforce can’t see

One view of every user that should be on your radar

Identity Protection 2.0: more visibility, faster response

Macro detection in files: flag the threat before it executes

A more reliable auto-update experience

Available on AppExchange

Our mission: security that keeps up with Salesforce

Phishing attacks are no longer confined to the inbox.

Key takeaways

Timeframe and Scope

Social engineering lures

Email authentication evasion

Email attachments: dual delivery approach

Observed in Salesforce workflows

Detection

Conclusion

Recommendations

Indicators of compromise

Why file security in Salesforce matters

How Salesforce Malware Scanner works

Threat coverage observations

Layered protection in SaaS environments

Conclusion

Overview

The challenge: The email-to-case security gap

The solution: In-platform protection that fits existing workflows

The results: Measurable security improvements and product innovation

Looking ahead: A partnership built on shared responsibility

Why organizations should pay attention

What organizations should do right now

Where to watch for updates

From predictive to autonomous

Why healthcare data is a prime target

Why legacy security falls short

Five principles for healthcare AI risk management

The leadership checklist

Balancing innovation with HIPAA compliance

Expert voices: Insights from Salesforce

Related insights