Is Your Customer Portal Misconfigured—and Quietly Leaking Data to “City-Forum”?

Most data leaks don’t look like Hollywood hacks. They look like a “perfectly normal” customer portal that’s a little too generous with what it shows to the public. Reco’s City-Forum campaign is a clean example: no zero-day, no malware—just attackers pulling data from misconfigured Salesforce Experience Cloud and ServiceNow portals at scale, often from one IP (158.220.87.79) using the Go-http-client/1.1 user agent, sometimes racking up hundreds of thousands of events in a single environment . If you own a portal, this is the kind of quiet problem that can sit in production for months unless you go looking.

What “City-Forum” is really doing (and why it works)

City-Forum isn’t “breaking into” your customer portal. It’s doing something that’s often harder to notice: pulling data your portal already serves to anonymous (guest) users, then repeating that process at machine speed.

Reco’s research ties this data theft campaign to a consistent set of fingerprints: traffic coming from 158.220.87.79 (a VPS), and requests that “look generic” because they frequently use the default Go-http-client/1.1 user agent . If you’re skimming logs for obvious badness, this can slip by as “just another client.”

The core trick: “Guest user” isn’t harmless

Both Salesforce Experience Cloud and ServiceNow Service Portal support unauthenticated visitors using a guest account. That’s normal. The problem starts when that guest account is accidentally granted too much through:

• Overly permissive sharing rules
• Over-broad object/field permissions
• Portal configuration choices that expose records/files

Reco is blunt on the mechanism: this campaign isn’t exploiting a product vulnerability. It’s extracting data that organizations have already exposed to unauthenticated users .

That distinction matters. If you’re waiting on a patch, you’re waiting on the wrong thing.

Why it works so well: it scales cleanly

Once an attacker finds one exposed object or searchable source, the rest is rinse-and-repeat:

1. Probe what the guest can access
2. Enumerate records in bulk
3. Keep paging until nothing’s left
4. Come back later and do it again

Reco reports the “busiest” targeted Salesforce environment recorded 560,000+ events tied largely to guest-user enumeration behavior . That number is the quiet part. One portal, one “anonymous” user type, and suddenly you’re looking at a data export measured in hundreds of thousands of requests.

The campaign fingerprints you can actually hunt for

If you manage logs or SIEM alerts, City-Forum gives you a few practical anchors:

• Source IP: 158.220.87.79
• User-Agent: Go-http-client/1.1
• Behavioral signal: sustained bursts of guest-user activity at unnatural volume (hundreds of thousands of requests)
• Cross-platform consistency: the same basic fingerprint has shown up against both Salesforce and ServiceNow targets

If your portal is public-facing, assume it’s being tested. The only real question is whether your guest access settings turn those tests into a clean download.

Salesforce Experience Cloud: the exact abuse paths (Aura + LWR)

If you run Salesforce Experience Cloud, City-Forum-style data theft usually shows up as API-like traffic hitting community endpoints—even when nobody’s “logging in.” The attacker is basically asking Salesforce, “What can the guest see?” and then pulling it in bulk.

Path 1: Aura enumeration (the classic “/aura” pull)

On Aura-based Experience Cloud sites, the attacker probes these endpoints to see what responds:

• GET/POST /aura
• GET/POST /s/sfsites/aura

From there, the flow is very mechanical:

1. Map the exposed surface

• Calls HostConfigController.getConfigData to enumerate what’s available to the guest context
• Think of it as reading the “menu” of what objects/features the site will serve without auth.

2. Pull the actual records

• Uses SelectableListDataProviderController.getItems to retrieve records from whatever objects are reachable
• If the guest user can see Accounts/Contacts/Cases (or custom objects), this is where the data starts leaving.

Why this path is effective: Aura endpoints are meant to support dynamic UI behavior. If guest permissions are too open, the endpoint becomes a clean extraction channel.

Path 2: LWR + UI API GraphQL (newer sites, same outcome)

Reco also observed the attacker targeting Experience Cloud sites built on Lightning Web Runtime (LWR), using Salesforce’s UI API via GraphQL:

• POST /webruntime/api/services/data/{version}/graphql

This matters because it’s not the “old Aura scraping” story. LWR sites can still expose data to guest users, and GraphQL is a powerful way to request structured data—fast.

What the attacker is doing here: sending GraphQL queries that return whatever the guest user is allowed to access through the UI API . Same underlying issue, different interface.

Bonus probing: self-registration endpoints

City-Forum also checks whether your community allows self-registration—because that can widen access beyond pure guest:

• /SiteRegister
• /CommunitiesSelfReg

If self-registration is enabled, a “guest” can potentially become an external user. If your defaults, profiles, or sharing rules are sloppy, that step can turn a small exposure into a much bigger one.

The uncomfortable takeaway: in Experience Cloud, UI endpoints and API endpoints blur together. If a guest can see it in any form, an attacker can usually script it.

ServiceNow Service Portals: anonymous search as a data tap (and why logs won’t save you)

If Salesforce gets abused through UI frameworks and APIs, ServiceNow Service Portal gets abused through something even more “normal”: search.

Reco saw the City-Forum actor hitting the native ServiceNow portal search endpoint directly:

• POST /api/now/sp/search?sysparm_cancelable=true

That endpoint powers the portal’s own search box. So when it’s reachable without login, attackers treat it like a data tap.

How anonymous search turns into enumeration

This isn’t fancy. It’s systematic.

• The endpoint accepts anonymous requests
• It can return data when your search sources are configured to allow guest access
• Attackers then vary search terms to “walk” through exposed content and pull back whatever matches

If your portal search can reach knowledge articles, case snippets, catalog item details, or anything indexed from sensitive tables, you’ve basically handed an attacker a fast filter. They don’t need to guess record IDs. They just keep asking better questions.

Reco describes the pattern as request volume ramping up over time (from tens to hundreds per day in one environment) as the attacker iterates on what works .

Why your logs won’t tell you what they stole

Here’s the part that burns teams during incident response.

ServiceNow transaction logs don’t record the POST body . So you may be able to see:

• the endpoint was hit,
• it was automated,
• how often it happened,
• how much data came back,

…but you can’t see the exact search terms the attacker used to hunt for sensitive topics .

That makes triage messy. You’re left reconstructing intent from timing and volume, instead of reading the actual keywords that would tell you what they were looking for (password resets, invoices, HR terms, customer names, internal project codes—whatever your portal might surface).

In plain terms: with ServiceNow portal search abuse, you can spot the hose—but the label on what flowed through it is missing.

Admin checklist: lock down guest access without breaking your portal

At this point, the goal isn’t to “turn off the portal.” It’s to stop anonymous (guest) users from seeing anything you wouldn’t want scraped at scale—and to do it in a way that doesn’t blow up legit customer journeys.

Salesforce Experience Cloud (Aura + LWR hardening)

1. Re-audit guest access like it’s an external API

Reco’s guidance maps to a tight set of controls admins can actually change:

• Review guest-user sharing rules
• Review object permissions and field permissions assigned to guest context
• Review file access (attachments, Salesforce Files, and anything exposed through community pages)
• Review member visibility settings in the community
• Review self-registration settings so you’re not widening access accidentally

If you want a practical way to run this: pick 3–5 objects you’d be upset to see in a paste site (Accounts, Contacts, Cases, custom “Support Request” objects) and verify guest access at both record-level sharing and field-level. Most leaks happen when one of those two layers is “open by mistake.”

2. Shut off guest access to public APIs (when you don’t need it)

For LWR sites, Reco specifically recommends disabling the Experience Builder option that allows guest users to access public APIs when it’s not required .

That one setting matters because it can block access to multiple API endpoints that get used for enumeration and bulk data pulls .

3. Treat self-registration as an access expansion event

If /SiteRegister or /CommunitiesSelfReg are enabled, treat that as “guest can become a user.” Reco calls out reviewing self-registration as part of the defensive checklist .

Basic rule: if self-registration stays on, the default external user profile has to be tight. No “helpful” defaults.

ServiceNow Service Portal (search exposure hardening)

1. Inventory what your portal search can reach

Reco’s recommendation is direct: review which search sources are exposed through Service Portals .

Translation: list every search source feeding the portal search experience and ask, “Should an unauthenticated person be able to query this at all?”

2. Require auth for anything sensitive

Reco advises making sure sensitive data search sources use strict authentication and access controls .

Don’t think about it as “search.” Think about it as: an endpoint that returns results based on attacker-controlled input. If you wouldn’t expose it through an API gateway without auth, don’t expose it through portal search without auth.

3. Put limits around anonymous search behavior

Even if you keep some anonymous search (public KB articles, basic help pages), set hard boundaries:

• narrow the search sources available to guest
• rate-limit where you can
• remove anything that could return record snippets, identifiers, or internal-only metadata

The big win is simple: keep the portal usable, but make “guest” mean public brochure, not internal index.

How to spot it early: simple signals, tight monitoring, and safer defaults

Once you’ve tightened configs, the next job is catching the next misstep fast. You don’t need fancy tooling to spot City-Forum-style portal scraping. You need a few high-signal alerts and the discipline to treat “guest activity” like real risk.

The simplest high-signal alerts (set these today)

1. Endpoint watchlist (Salesforce Experience Cloud)

Alert on spikes or repeated access to:

• /aura and /s/sfsites/aura (Aura enumeration traffic)
• /webruntime/api/services/data/{version}/graphql (LWR UI API GraphQL access)
• /SiteRegister and /CommunitiesSelfReg (self-registration probing)

What to flag:

• High request rates from one source
• High error rates (probing) followed by steady success (extraction)
• Any guest-context activity that looks like a scripted loop (same endpoint patterns, tight timing)

2. Endpoint watchlist (ServiceNow Service Portal)

Alert on:

• POST /api/now/sp/search?sysparm_cancelable=true

What to flag:

• bursts of anonymous search requests with a steady cadence
• responses returning meaningful payload sizes repeatedly (a sign the attacker’s search terms are working)

Reco notes the attacker can vary search terms to enumerate exposed info , so volume + repetition is the tell.

Fingerprints that cut through noise

Two indicators are especially actionable for this campaign:

• Known source IP: 158.220.87.79
• Suspiciously “default” User-Agent: Go-http-client/1.1

If you see either paired with the endpoint watchlist above, treat it as an investigation, not an “FYI.”

The logging trap: what you won’t see in ServiceNow

If you’re relying on ServiceNow transaction logs to tell you what was searched: careful. Reco points out that transaction logs don’t record the POST body .

So your monitoring should focus on what you can reliably capture:

• endpoint + method (POST)
• unauthenticated/guest context
• rate, timing patterns, returned data volume

Safer defaults for the real-world fallout (where Cloaked fits)

Even when you catch scraping early, exposed portal data can fuel downstream misuse: spam, phishing, account recovery attempts, and “we know who you are” social engineering.

When teams need to share a contact point publicly (support forms, community signups, vendor portals), Cloaked can reduce the blast radius by using alias emails and phone numbers. If something leaks, you can rotate or disable the alias without burning the real identifier. It’s not a substitute for fixing guest access, but it helps keep a portal mistake from turning into permanent personal-data collateral.

‍