Listen to this Post
Introduction: The Most Dangerous Door Is Sometimes the One Left Open for Everyone
Cybersecurity teams often focus on stolen credentials, sophisticated malware, ransomware gangs, and zero-day vulnerabilities. Yet some of the most serious exposures begin with something far less dramatic: a public-facing portal that gives anonymous visitors slightly more access than it should.
That is the uncomfortable lesson behind the City Forum campaign.
Researchers at Reco uncovered activity tied to a single server that has allegedly spent more than a year probing and extracting accessible records from Salesforce and ServiceNow customer portals across multiple industries. The infrastructure appears simple. The operation does not rely on an exotic zero-day vulnerability or a spectacular breach technique. Instead, it appears to take advantage of a much older and more fundamental security problem, permissions that were never meant to expose sensitive information but nevertheless gave anonymous users the ability to retrieve it.
The campaign is particularly concerning because of its persistence and technical range. The same infrastructure was observed interacting with different Salesforce technologies, including the older Aura framework and newer Lightning Web Runtime interfaces, while also targeting a ServiceNow Service Portal search API. This suggests that the operator was not experimenting randomly. The activity points toward a purpose-built tool capable of testing multiple application layers and identifying where guest identities had been granted excessive access.
For organizations using cloud platforms, the message is clear. Authentication screens can create a powerful illusion of security. A portal may look protected because users see a login page, but backend APIs, guest accounts, search functions, and public application components may still expose information that was never intended to become public.
The City Forum campaign is therefore not just another story about scanning. It is a warning about identity architecture, cloud permissions, and the dangerous gap between what an organization believes is public and what an anonymous system identity can actually read.
The Original Investigation: One IP Address, One Persistent Campaign
According to
The researchers named the activity the City Forum campaign after a domain associated with the attacker’s infrastructure.
What immediately stood out was consistency.
Requests originating from the server reportedly carried the same user-agent fingerprint, the default identifier commonly associated with Go’s net/http library. That detail suggests the traffic was generated by a compiled and purpose-built program rather than a human manually interacting with websites through a conventional browser.
Passive DNS information reportedly connected the domain to the same infrastructure as far back as March 2025. The server also appears to have remained in place instead of frequently rotating through new infrastructure.
That persistence matters.
Threat actors frequently change IP addresses, domains, and hosting providers to complicate detection. In this case, the apparent stability of the infrastructure may indicate that the campaign was able to operate for an extended period without enough defensive attention to force the operator to move.
Reco identified targets across several industries, including telecommunications, banking and financial services, enterprise software, cybersecurity and privacy-related companies, and public-sector portals.
The organizations themselves were not publicly named.
A Campaign That Goes Beyond Traditional Salesforce Guest Access Abuse
Salesforce guest access problems are not new.
Public-facing Experience Cloud sites rely on guest users to allow unauthenticated visitors to interact with specific resources. That functionality is useful for public portals, support pages, registration systems, and other services where users may need limited access without logging in.
The problem begins when the guest identity receives more permissions than necessary.
Previous attacks and research involving Salesforce exposure have often focused on the Aura framework. Attackers can generate large numbers of requests to identify accessible objects and retrieve records where permissions allow it.
City Forum reportedly follows this path too.
Reco observed significant Aura activity, including one environment that generated more than 560,000 events associated with the same source IP.
However, the campaign did not stop there.
Lightning Web Runtime Becomes Another Potential Attack Surface
One of the most interesting elements of the research is the campaign’s interaction with Salesforce’s newer Lightning Web Runtime environment.
Rather than limiting itself to older Aura requests, the tool reportedly accessed Salesforce’s UI-API through paths associated with the Lightning Web Runtime.
The activity reportedly walked through API versions from v56.0 through v66.0.
That sequential behavior is important because it resembles systematic reconnaissance.
Instead of assuming that every target uses the same configuration, a purpose-built scanner can test multiple API versions and application behaviors until it discovers a combination that returns useful data.
This makes defensive monitoring more complicated.
A security team watching only for known Aura-based patterns could miss activity occurring through newer application interfaces. The broader lesson is that cloud security monitoring cannot focus exclusively on one framework or endpoint.
Attackers evolve their tooling when platforms evolve.
If a new application layer exposes the same underlying permissions, a different API does not necessarily mean a different security model. It may simply provide another path toward the same data.
ServiceNow Was Also Part of the Operation
The City Forum campaign reportedly extended beyond Salesforce.
The same infrastructure was observed targeting a ServiceNow Service Portal search endpoint:
POST /api/now/sp/search
This endpoint is particularly interesting because it can process search requests and return information based on the permissions available to the requesting identity.
For a public-facing portal, that identity may be a guest or anonymous user.
If the
This is where the problem becomes larger than a Salesforce-specific issue.
The campaign appears to focus on a common architectural weakness shared across platforms: persistent guest identities that must exist to support public functionality.
The technology changes.
The security mistake remains the same.
The Real Weakness Is Not Necessarily the API
One of the most important conclusions from the research is that the Salesforce and ServiceNow endpoints themselves may be functioning as designed.
The dangerous condition is excessive authorization.
A public API can be technically secure from an implementation perspective while still exposing sensitive data because the identity making the request has permission to read it.
That distinction matters enormously.
Organizations often react to suspicious traffic by attempting to block a particular URL or disable a specific endpoint. While this can temporarily reduce exposure, it does not solve the root problem if the guest account still has excessive permissions elsewhere.
The central question security teams need to ask is simple:
What can an unauthenticated identity actually read?
If the answer includes customer records, internal knowledge articles, financial information, support data, personal information, or other sensitive assets, then the exposure exists regardless of whether a browser interface displays a login page.
A login screen does not automatically mean the underlying data is private.
Permissions decide that.
Guest Users Can Become Invisible Security Risks
Salesforce Experience Cloud and ServiceNow portals both rely on identities that enable anonymous visitors to interact with public content.
These identities cannot simply be treated as ordinary user accounts.
They are architectural components.
That can create a dangerous operational blind spot.
Human accounts receive attention because administrators know who owns them. Service accounts receive attention because they often have API keys or elevated permissions. Guest identities, however, can become background infrastructure that nobody actively reviews.
Over time, permissions accumulate.
A new object may be exposed to support a business process.
A sharing rule may be expanded during troubleshooting.
A field may become visible after an application update.
A knowledge base article may receive broader read access.
A search source may be added without a complete review of anonymous visibility.
Each change may appear harmless by itself.
Together, they can create an anonymous data extraction path.
That is why campaigns such as City Forum are so dangerous. Attackers do not need to understand an organization’s entire infrastructure. They only need to discover the places where access control does not match the organization’s expectations.
The Volume of Requests Suggests Automated Data Discovery
Reco observed extremely high request volumes associated with the infrastructure.
In one case, more than 560,000 events were linked to the same IP address.
That volume is unlikely to represent normal user behavior.
Automated tools can systematically enumerate accessible resources, test parameters, search for object names, request pages of records, and repeat the process across multiple targets.
A human attacker might spend hours navigating a portal.
A compiled tool can perform thousands of requests while maintaining a consistent fingerprint.
This automation changes the scale of the risk.
A small configuration mistake affecting a few records might once have remained unnoticed.
An automated scanner can now discover that mistake and rapidly determine whether the exposure is isolated or large enough to justify deeper collection.
For defenders, the lesson is that unusual volume should be treated as an investigative signal, especially when the activity originates from infrastructure that does not behave like a normal customer browser.
The Go HTTP User Agent Provides a Valuable Detection Clue
The campaign reportedly used the default Go HTTP client fingerprint.
This is not proof that every request using that user agent is malicious. Developers, monitoring systems, and legitimate automation tools can also use Go-based HTTP clients.
Context is therefore critical.
Security teams should not build a detection rule that automatically treats every Go HTTP client as an attacker.
Instead, they should combine multiple indicators.
For example:
The Go HTTP user agent.
The known source IP.
Unusually high request volume.
Sequential requests across API versions.
Repeated Aura or UI-API paths.
Guest-context access.
Large response sizes.
Repetitive ServiceNow search activity.
A single indicator can generate noise.
Several indicators appearing together can reveal a campaign.
This is the difference between simple indicator blocking and meaningful behavioral detection.
Salesforce Detection Requires Visibility Into More Than Login Events
Organizations with Salesforce Event Monitoring or Shield capabilities can review relevant event types for suspicious behavior.
According to the research, defenders should examine Aura-related activity and site events for patterns connected to the campaign.
Potential indicators include the source IP, the Go HTTP client user agent, and requests involving paths such as:
/webruntime/api/services/data
Security teams should also pay attention to unusual activity around self-registration paths, including:
/SiteRegister
and:
/CommunitiesSelfReg
These endpoints may be legitimate parts of a public workflow.
However, a sudden increase in requests, especially from automated infrastructure, can indicate reconnaissance or attempts to understand how an Experience Cloud site handles guest and newly created identities.
Detection should therefore combine logs with permission analysis.
Finding suspicious traffic is useful.
Understanding what that traffic was actually allowed to retrieve is far more important.
ServiceNow Search Logs Can Reveal Anonymous Sweeps
For ServiceNow environments,
Security teams can review the syslog_transaction table and search for activity associated with suspicious source IP addresses or URLs beginning with:
/api/now/sp/search
The most valuable signals may include guest-created activity, repetitive searches, unusual output lengths, and request patterns that do not resemble ordinary human interaction.
Search functionality is often underestimated as an attack surface.
Organizations may carefully protect direct access to records while forgetting that a search engine can become another interface for retrieving the same information.
A search endpoint is ultimately an authorization problem as much as it is a search problem.
The question is not merely whether someone can submit a search.
The question is what information the search engine is willing to return to that identity.
Salesforce Remediation Starts With Guest Permissions
The recommended response is not simply to block the observed IP address.
Blocking an IP is useful as an immediate containment measure, but another server can easily replace it.
The durable fix is to reduce unnecessary guest access.
Organizations should review Salesforce guest sharing rules and identify which records can actually be accessed by anonymous users.
Object-level permissions should be restricted.
Field-level permissions should be reviewed.
Self-registration should be disabled where it is not required.
Public API access through Experience Builder should also be reviewed and disabled where the business does not genuinely need it.
The guiding principle should be minimal access.
A guest user should receive only the permissions necessary to support a specific public function.
Nothing more.
ServiceNow Requires a Review of What Anonymous Search Can See
ServiceNow remediation follows the same principle but requires attention to portal architecture.
Organizations should map the search sources exposed through public portals and determine exactly which information repositories are included.
Knowledge Base read criteria should be audited carefully.
Administrators should test anonymous searches rather than assuming the portal configuration behaves as intended.
This testing should include sensitive keywords, internal project names, customer references, document categories, and other terms that could reveal unintended exposure.
The safest approach is to evaluate the portal from the perspective of someone who has no account at all.
If an anonymous visitor can retrieve information that employees assume requires authentication, the access model needs to be corrected.
Why the Campaign Matters Beyond the Named Platforms
City Forum is ultimately a cloud security story.
Modern organizations increasingly depend on SaaS applications, public portals, APIs, customer communities, self-service platforms, and AI-connected services.
Every one of these systems can contain identities that operate outside the normal employee login model.
Guest users.
Anonymous sessions.
Service accounts.
Application identities.
API tokens.
Temporary registration flows.
Third-party integrations.
Each identity creates another authorization boundary.
The attack surface is no longer defined only by exposed servers.
It is increasingly defined by exposed permissions.
An organization can patch every operating system and still leak sensitive information because a cloud application believes an anonymous identity is authorized to read it.
That is why identity security and application security are becoming inseparable.
The Infrastructure Is Reportedly Still Active
Reco reported that the infrastructure associated with the campaign remained active and that activity volume was increasing.
The company did not attribute the operation to a specific named threat group.
Attribution, however, is not the most urgent question for defenders.
Whether the operator is a known cybercrime group, an independent data broker, a reconnaissance operation, or another type of actor, organizations still face the same immediate requirement: determine whether their public-facing applications expose more information than intended.
Waiting for a famous threat actor name can be a mistake.
The evidence of suspicious activity is already enough to justify reviewing guest access.
What Undercode Say:
The Campaign Demonstrates That Misconfiguration Can Be More Dangerous Than Exploitation
City Forum is a powerful reminder that attackers do not always need to break security controls when they can simply discover permissions that were configured incorrectly.
The Real Target Appears to Be Authorization, Not a Single Vulnerability
The operation reportedly moves across Aura, Lightning Web Runtime, UI-API interfaces, and ServiceNow search functionality.
That Multi-Platform Behavior Suggests Reusable Reconnaissance Logic
The attacker appears to be looking for the same weakness expressed through different technologies: anonymous identities with excessive access.
This Is Why Endpoint Blocking Alone Is Not Enough
An endpoint can be removed from public access while another API exposes the same records through a different path.
Security Teams Need to Think in Terms of Data Reachability
The important question is not only which URL is public.
The More important question is which identity can reach which data
If a guest identity can retrieve the data, the attacker only needs to find the request format.
Sequential API Version Testing Is Particularly Interesting
Walking through multiple versions may allow automated tooling to adapt to differences between customer deployments.
Automation Changes the Economics of Data Exposure
A configuration mistake that might have been difficult to discover manually can become easy to locate at internet scale.
SaaS Security Often Suffers From False Confidence
Organizations assume that because the vendor provides authentication and access controls, their deployment is automatically secure.
The Platform Is Only as Secure as the Permissions Applied to It
Cloud providers can offer strong controls, but administrators still decide who can read what.
Guest Accounts Should Be Treated as High-Risk Identities
They are accessible from the internet by design and therefore deserve continuous review.
Public Portals Need Continuous Testing
A configuration that was safe six months ago may become unsafe after a new object, integration, search source, or business workflow is added.
Security Monitoring Must Include API Behavior
Traditional login monitoring will miss attacks that operate entirely through anonymous application interfaces.
The Go HTTP Signature Is Useful but Not Sufficient
Defenders should avoid treating one user agent as absolute proof of malicious activity.
Behavioral Correlation Is the Stronger Strategy
Volume, timing, request paths, response size, source infrastructure, and identity context should all be evaluated together.
Search Features Deserve More Security Attention
Search can silently become a bulk data extraction mechanism when authorization boundaries are weak.
The ServiceNow Element Is Especially Important
It demonstrates that the campaign is not limited to a single vendor’s implementation.
This Could Represent a Broader Methodology
Attackers may increasingly scan enterprise SaaS portals for anonymous access rather than focusing exclusively on traditional server vulnerabilities.
Exposure Management Must Include Business Applications
Asset inventories that only track servers, domains, and cloud instances are incomplete.
Organizations Need to Inventory Public Application Identities
Every anonymous user, guest profile, public API, and self-service workflow should have an explicit owner.
Permission Drift Is a Major Long-Term Risk
Small administrative changes can gradually transform a restricted guest profile into an overly privileged one.
Security Reviews Should Be Automated Where Possible
Manual quarterly reviews may not be fast enough for frequently changing SaaS environments.
Continuous Permission Testing Could Become Essential
Organizations should regularly simulate anonymous access and verify exactly what public identities can retrieve.
Detection Engineering Should Focus on Intent and Pattern
A single request may be harmless.
Hundreds of thousands of structured requests are a different story
High-volume enumeration should trigger investigation even when the application technically accepts every request.
The Campaign Also Raises Third-Party Risk Questions
Customer portals may expose data belonging not only to the organization operating the platform but also to partners and customers.
This Increases the Potential Business Impact
A guest permission error can become a privacy incident, contractual issue, regulatory problem, and reputational crisis at the same time.
Identity Has Become a Primary Security Perimeter
The old perimeter was the firewall.
The modern perimeter is increasingly the permission decision
Every API call eventually reaches a question: is this identity allowed to see this information?
City Forum Appears to Exploit the Gap Between Intended and Effective Access
Administrators may believe information is private while the application’s authorization model says otherwise.
That Gap Is Where Security Teams Must Focus
Configuration validation needs to test actual behavior rather than relying only on documentation or assumptions.
The Most Important Defensive Action Is Verification
Do not assume a public portal exposes only public information.
Test it from outside
Create a controlled anonymous testing process and continuously measure what the internet can actually access.
Evidence Supports the Existence of the Reported Research
✅ Reco’s investigation describes a campaign it calls City Forum and links the observed activity to persistent infrastructure, including a reported IP address and recurring request patterns.
Attribution Remains Unconfirmed
❌ There is no confirmed public attribution in the provided research linking the campaign to a specific named threat group, so claims identifying a particular actor would go beyond the available evidence.
The Core Security Risk Is Technically Plausible
✅ Salesforce and ServiceNow public-facing environments can expose information when guest or anonymous identities receive permissions broader than the intended public use case.
Prediction
(+1) Anonymous Access Reviews Will Become a Larger SaaS Security Priority
Security teams will increasingly test Salesforce, ServiceNow, and other SaaS portals from the perspective of completely unauthenticated users.
Vendors and security platforms will likely improve monitoring for unusual guest-user API behavior and high-volume automated enumeration.
Organizations that continuously validate effective permissions will reduce the chance that configuration drift quietly turns public functionality into a data exposure path.
Deep Analysis
Start by Investigating the Known Infrastructure
Security teams can search reverse proxy, firewall, and application logs for the reported source IP:
grep -R "158.220.87.79" /var/log/
Hunt for the Go HTTP Client Fingerprint
A basic Linux search across web logs can identify requests carrying the suspicious user agent:
grep -R "Go-http-client" /var/log/nginx/
Look for Salesforce Lightning Web Runtime Activity
Teams collecting application or proxy logs can search for the reported path pattern:
grep -R "/webruntime/api/services/data" /var/log/
Identify Potential ServiceNow Search Sweeps
Logs containing the Service Portal search endpoint can be reviewed with:
grep -R "/api/now/sp/search" /var/log/
Measure Request Volume From a Suspicious Source
A quick count can help determine whether an IP generated abnormal traffic:
grep "158.220.87.79" access.log | wc -l
Review the Most Frequently Requested Paths
This command can reveal whether an automated client repeatedly targeted a small set of API endpoints:
grep "158.220.87.79" access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -20
Examine Response Size for Possible Bulk Extraction
Large responses associated with guest traffic deserve additional attention:
grep "Go-http-client" access.log | awk '{print $10}' | sort -nr | head
Investigate Time-Based Automation Patterns
Automated activity often produces dense and repetitive request patterns:
grep "158.220.87.79" access.log | awk '{print $4}' | sort | uniq -c | sort -nr | head
Correlate Multiple Indicators Instead of Blocking One Signature
A simple hunting workflow can combine IP addresses, user agents, and targeted paths:
grep -E "158.220.87.79|Go-http-client|webruntime/api/services/data|api/now/sp/search" access.log
Use Anonymous Testing as a Defensive Control
Technical teams should also perform controlled testing against their own public portals to verify what guest identities can access.
For example, a basic HTTP request can help confirm whether an intentionally public endpoint responds anonymously:
curl -i https://example.com/public-endpoint
The goal is not to attack the platform. The goal is to compare expected access with effective access.
Build a Continuous Exposure Review Process
A strong defensive program should repeatedly test:
Public URL
↓
Anonymous Identity
↓
API Request
↓
Authorization Decision
↓
Returned Data
↓
Expected or Unexpected?
If the final result contains information that should require authentication, the organization has identified a configuration problem before an external actor does.
Final Thoughts: The Attack Surface Is Often Hidden Inside the Permissions
The City Forum campaign is a warning that modern data exposure does not always begin with malware, stolen passwords, or a dramatic software vulnerability.
Sometimes the attacker simply asks the application for information.
And the application answers.
That is what makes overprivileged guest identities so dangerous. They can create a silent path to sensitive data that looks, at the protocol level, like ordinary application traffic.
For Salesforce and ServiceNow administrators, the immediate priority is clear: review what anonymous and guest identities can actually access, not what the portal appears to expose through its user interface.
For security teams, the broader lesson is even more important.
The internet does not see an organization’s security assumptions.
It sees the permissions that are actually enforced.
And when those permissions are too broad, a single persistent server may be enough to find the gap and keep pulling data from it for months before anyone notices.
▶️ Related Video (72% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: thehackernews.com
Extra Source Hub (Possible Sources for article):
https://www.quora.com/topic/Technology
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
