When "Working as Designed" Means Total Exposure: Inside the 17-Month 'City-Forum' SaaS Data Harvesting Campaign
By DigitalSpying Research Team | August 16, 2026
Executive Summary
Most major enterprise cybersecurity investigations begin with a broken component: an unpatched remote code execution vulnerability, an exposed administrative credential, or a zero-day exploit payload. However, an alarming discovery by SaaS security firm Reco demonstrates that the most insidious data breaches often occur when enterprise platforms function strictly as designed.
Dubbed the "City-Forum" campaign by Reco researchers and reported by Help Net Security, an unidentified threat actor has operated a covert, large-scale data harvesting campaign since at least March 2025—spanning over 17 months of undetected reconnaissance and exfiltration. Operating from a single rented server tied to an abandoned 2002 web domain in Germany, the threat actor has systematically scraped millions of records from public-facing Salesforce Experience Cloud (formerly Community Cloud) sites and ServiceNow Customer Service Management (CSM) / Service Portals across hundreds of multinational corporations, telecommunications providers, healthcare organizations, and government agencies worldwide (BleepingComputer).
The attack required no exploit payloads, no phishing lures, and no stolen employee credentials. Instead, the adversary weaponized permissive Guest User Profiles and misconfigured Access Control Lists (ACLs) to harvest Personally Identifiable Information (PII), customer support case histories, internal employee rosters, and confidential enterprise knowledge base articles while evading traditional Security Information and Event Management (SIEM) systems and anomaly detection platforms (SecurityWeek).
Deep-Dive Technical Analysis: The Mechanics of the City-Forum Campaign
1. Infrastructure and Reconnaissance Profile
According to threat intelligence telemetry from Reco and Dark Reading, the campaign derived its name from city-forum[.]com, a domain originally registered in 2002 that had long been abandoned and subsequently re-routed. Threat actors pointed the domain to a generic virtual private server (VPS) hosted by a German hosting provider (158.220.87[.]79).
From this centralized egress node, the threat actor generated more than 560,000 automated API probes and enumeration queries targeting public SaaS portal endpoints across targeted organizations (Help Net Security). Rather than using broad, noisy web crawlers, the adversary developed custom automation toolsets engineered specifically to interact with the underlying data-binding frameworks of modern SaaS architectures.
Phase
Methodology
Targets & Outcomes
Reconnaissance
Mapping Enterprise SaaS Domains
Identification of public Salesforce/ServiceNow endpoints
Salesforce Exploitation
LWR Data Access Layer Probes
Unauthenticated Aura/Apex queries; sObject dumping via Guest Profile
ServiceNow Exploitation
Native Endpoint Targeting
Abuse of /api/now/sp/search and Public Widget data streaming
Exfiltration
Low-and-Slow Read Activity
Harvesting of PII, Knowledge Bases, and Support Tickets
2. Salesforce Exploitation: Bypassing the UI via Lightning Web Runtime (LWR)
In Salesforce Experience Cloud environments, organizations build interactive digital portals for customers, partners, and employees. By default, anonymous site visitors interact with the site through a specialized identity context: the Guest User Profile.
While Salesforce has progressively tightened guest user defaults over recent major releases—such as enforcing the Secure guest user record access setting—custom business configurations, third-party AppExchange packages, and legacy portal migrations frequently introduce permissive sharing rules that grant the Guest User profile read access to standard and custom Salesforce objects (sObjects) (CSO Online).
The City-Forum threat actor avoided interacting with the visual web interface, which often hides sensitive data fields via client-side UI logic. Instead, the attacker's custom scripts interfaced directly with the Lightning Web Runtime (LWR) data-access layer and underlying Aura endpoints:
1. Aura Component Endpoint Enumeration: The attacker sent crafted POST requests to /s/sfsites/aura targeting controller actions (such as aura://RecordUiController/ACTION$getRecord and custom Apex controllers).
2. Object Schema Brute-Forcing: By iterating through standard Salesforce object identifiers (e.g., Account, Contact, Lead, Case, User) and common custom object suffixes (__c), the scripts enumerated all records exposed to the guest context.
3. Bulk Data Extraction: Because the Guest User permissions permitted access at the API level, Salesforce serialized and returned full record graphs—including unmasked email addresses, phone numbers, billing metadata, and internal agent notes—in JSON responses.
3. ServiceNow Exploitation: Undocumented Search Endpoints & Public Widget Data Streaming
In ServiceNow environments, the Service Portal and Customer Service Management (CSM) frameworks allow organizations to expose self-service catalogs, knowledge bases, and ticket submission forms to external users.
The City-Forum campaign targeted specific structural configurations within ServiceNow's Service Portal architecture (SecurityWeek):
* Undocumented Native Search Sinks: The adversary utilized a less-documented native search API endpoint (/api/now/sp/search) to issue broad wildcard queries (*) across configured search sources.
* Public Service Portal Widgets: In ServiceNow, UI components known as Widgets execute server-side JavaScript scripts (Server Script) to retrieve and format database records. If a widget is marked as Public so that anonymous visitors can view a basic landing page, but the developer failed to implement explicit server-side access evaluations (GlideRecord.canRead() or table-level Access Control Lists [ACLs]), the widget streams the raw database output directly to anyone querying the widget's API endpoint (/api/now/sp/widget/
* Table Harvesting: Attackers abused these exposed data providers to query core tables, including sys_user (extracting employee names, usernames, and role assignments), sn_customerservice_case (harvesting active customer support disputes and sensitive attachments), and kb_knowledge (downloading proprietary internal runbooks and operational procedures).
Why the Campaign Remained Undetected for 17 Months
The 17-month dwell time achieved by the City-Forum campaign represents a masterclass in exploiting the blind spots of modern cybersecurity operations (Help Net Security):
1. "Working as Designed" Authentication Semantics: Every single HTTP request made by the threat actor was authorized by the application stack. From the perspective of Salesforce and ServiceNow, an anonymous external guest was simply reading records that the tenant's administrators had explicitly permitted the Guest role to view.
2. Absence of Malicious Signatures: The attacker executed no shellcode, injected no SQL payloads, uploaded no web shells, and established no binary command-and-control (C2) persistence. Web Application Firewalls (WAFs) looking for malicious exploit syntax (e.g., OWASP Top 10 injection strings) categorized the requests as benign HTTPS JSON calls.
3. Low-and-Slow Query Throttling: Rather than generating massive volumetric denial-of-service spikes, the threat actor carefully paced API enumeration queries to stay beneath standard rate-limiting and threshold alerts.
4. Log Fragmentation: Many enterprise SOCs ingest firewall and endpoint logs into their SIEMs but fail to ingest granular SaaS application access logs (such as Salesforce Event Monitoring ReportEvent and AuraRequestEvent, or ServiceNow transaction logs). Without centralized visibility into guest data-reading volumes, the sustained exfiltration went unnoticed.
Broader Industry Impact & SaaS Supply Chain Exposure
The City-Forum campaign underscores a systemic shift in the cyber threat landscape. As enterprise network perimeters dissolve into distributed multi-tenant SaaS environments, misconfiguration has become the primary vector for mass data theft (Dark Reading).
Similar to earlier high-profile extortion waves conducted by groups like ShinyHunters and ExfilSquad targeting misconfigured Microsoft Power Pages and Snowflake data warehouses, threat actors no longer need to spend months developing zero-day exploits when thousands of enterprise SaaS portals inadvertently broadcast confidential business data to the public internet.
The exfiltrated data poses severe secondary risks to affected organizations:
* Targeted Spear-Phishing & Social Engineering: Detailed customer support tickets, contact rosters, and internal IT jargon provide threat actors with pristine reconnaissance material to execute highly convincing voice phishing (vishing) and Business Email Compromise (BEC) attacks.
* Regulatory Penalties: Exposing unmasked customer PII, health details, and financial records violates strict data privacy frameworks, including GDPR, CCPA, and HIPAA, exposing enterprises to substantial regulatory fines and class-action litigation.
* Corporate Espionage: Leaked internal knowledge base articles and operational tickets expose trade secrets, system architectures, and internal security weaknesses to competitors and nation-state adversaries.
Actionable Mitigations and Hardening Playbook
Enterprise security teams and platform administrators must immediately audit public-facing SaaS portals to ensure internal records are completely inaccessible to unauthenticated external users (Help Net Security, Reco).
1. Salesforce Experience Cloud Hardening
* Audit Guest User Sharing Rules: Review all Guest User Sharing Rules across every standard and custom object. Ensure that guest access is restricted strictly to records intended for public consumption.
* Verify Guest User Record Access Settings: Confirm that the Secure guest user record access default setting is enforced and that organization-wide sharing defaults (OWDs) are set to Private.
* Disable Sensitive Object Permissions on Guest Profiles: Access the Guest User Profile via Public Access Settings. Remove View All and Modify All permissions and explicitly disable read permissions for sensitive objects like Account, Contact, Lead, Case, and User.
* Restrict API and File Access: Disable API Enabled on the Guest User Profile and ensure Allow guest users to access public files is disabled if unneeded.
* Implement Event Monitoring: Enable Salesforce Event Monitoring to alert on AuraRequestEvent and URIEvent streams where USER_TYPE = 'Guest' shows anomalous activity.
2. ServiceNow Service Portal Hardening
* Enforce Table-Level Access Control Lists (ACLs): Review all table ACLs (sys_security_acl). Ensure the public role is stripped from sensitive tables like sys_user, sn_customerservice_case, and incident.
* Audit and Secure Service Portal Widgets: Identify all widgets marked as Public. Inspect the Server Script of every public widget to verify that database queries do not return unauthenticated data.
* Restrict Search Sources: Ensure sensitive internal tables are excluded from public search sources within the Service Portal configuration.
* Disable Unused Public API Endpoints: Audit Scripted REST APIs to ensure endpoints requiring authentication cannot be triggered by the guest user.
3. Enterprise-Wide SaaS Security Governance
* Deploy SaaS Security Posture Management (SSPM): Implement automated SSPM solutions (such as Reco, AppOmni, or Obsidian) to continuously discover shadow permissions and identify exposed public assets.
* Threat Hunt for City-Forum Indicators: Inspect logs for HTTP requests originating from the following infrastructure:
* IP Address: 158.220.87[.]79
* Domain: city-forum[.]com
* Implement Adaptive Rate-Limiting: Place public SaaS domains behind edge CASBs or WAFs with bot management and behavioral scraping rate limits on /api/ and /s/sfsites/ paths.
Conclusion
The City-Forum campaign serves as a critical wake-up call for enterprise security leaders. In the modern SaaS era, verifying that your software is patched against known CVEs is only half the battle. Organizations must actively govern what their public SaaS portals are authorized to share, ensuring that permissive guest user configurations do not turn standard application features into an open doorway for global data harvesting.
For more technical threat briefings and cybersecurity research, visit digitalspying.com.