Varonis debuts trailblazing features for securing Salesforce. Learn More

Varonis announces strategic partnership with Microsoft to acclerate the secure adoption of Copilot.

Learn more

Ghost Sites: Stealing Data From Deactivated Salesforce Communities

2 min read
Published May 31, 2023

Varonis Threat Labs discovered that improperly deactivated and unmaintained Salesforce "ghost sites” remain accessible and vulnerable to risk. By manipulating the host header, threat actors can gain access to sensitive PII and business data.

Salesforce Sites allow you to create customized communities, enabling partners and customers to collaborate within a company’s Salesforce environment.

When these communities are no longer needed, though, they are often set aside but not deactivated. Because these unused sites are not maintained, they aren’t tested against vulnerabilities, and admins fail to update the site’s security measures according to newer guidelines.

Varonis Threat Labs discovered that many of these improperly deactivated Salesforce Sites are still pulling fresh data and are easily found, accessible, and exploitable by attackers. We dubbed these abandoned, unprotected, and unmonitored Salesforce Communities “ghost sites.”

In this blog, we’ll show you how these ghost sites manifest, how to locate them, and how an attacker can use a simple exploit to access them.

Where do ghost sites come from?

The creation of a ghost site starts with custom domain names.

Instead of using unappealing internal URLs like “,” companies create custom domains so partners can browse "” instead. This is accomplished by configuring the DNS record so that “” points to the lovely, curated Salesforce Community Site at “

Note that the new DNS record should have a CNAME entry that points to your FQDN, followed by the organization ID, followed With the DNS record changed, partners visiting “” will be able to browse Acme’s Salesforce site.

The trouble begins when Acme decides to choose a new Community Site vendor.

Birth of a ghost site

Like any other technology, companies might replace a Salesforce Experience Site with an alternative.

Subsequently, Acme modifies the DNS record of “” to point toward a new site that might run in their AWS environment, for example, instead of “”

From the users’ viewpoint, the Salesforce Site is gone, and a new community page is available. The new page might be completely disconnected from Salesforce, not running in the environment, and no obvious integrations are detectable.

Varonis Threat Labs researchers discovered that many companies stop at just modifying DNS records. They do not remove the custom domain in Salesforce, nor do they deactivate the site. Instead, the site continues to exist, pulling data and becoming a ghost site.

Speaking with ghost sites

Now that Acme’s domain no longer points toward Salesforce, simply calling in endpoints such as Aura will not work.aura-not-working-1


But because ghost sites are still active in Salesforce, the siteforce domain still resolves, meaning it’s available under the right circumstances. A straightforward GET request results in an error — but there is another way to gain access.

Attackers can exploit these sites by simply changing the host header. This would trick Salesforce into believing that the site was accessed as and that Salesforce would serve the site to the attacker.


While it’s true that these sites are also accessible using the full internal URLs, these URLs are difficult for an external attacker to identify. However, using tools that index and archive DNS records — such as SecurityTrails and similar tools — make identifying ghost sites much easier.

Adding to the risk is the fact that old, obsolete sites are less maintained and, therefore, less secure, increasing the ease of an attack.

Ghost site secrets

Our research found many such sites with confidential data, including PII and sensitive business data that were not otherwise accessible. The exposed data is not restricted to only old data from when the site was in use; it also includes new records that were shared with the guest user due to the sharing configuration in their Salesforce environment.

Exorcising ghost sites

To solve the problem of ghost sites — and to mitigate other threats — sites that are no longer in use should be deactivated. It’s important to keep track of all Salesforce sites and their respective users’ permissions — including both community and guest users. Varonis Threat Labs created a guide for protecting your active Salesforce Communities against recon and data theft, and you can read more about keeping sensitive Salesforce data safe here.

What you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.
Try Varonis free.
Get a detailed data risk report based on your company’s data.
Deploys in minutes.
Keep reading
Security Vulnerabilities in Apex Code Could Leak Salesforce Data
Varonis' threat researchers identified high- and critical-severity vulnerabilities in Apex, a programming language for customizing Salesforce instances.
Outlook Vulnerability Discovery and New Ways to Leak NTLM Hashes
Varonis Threat Labs discovered a new Outlook exploit and three new ways to access NTLM v2 hashed passwords.
Taking Microsoft Office by "Storm"
The “Storm-0978” ransomware group is actively exploiting an unpatched Microsoft Office and Windows HTML remote code execution vulnerability.
Imposter Syndrome: UI Bug in Visual Studio Lets Attackers Impersonate Publishers
Varonis Threat Labs found a bug in Microsoft Visual Studio installer that allows an attacker to impersonate a publisher and issue a malicious extension to compromise a targeted system