SUNG-HEE

City-Forum: Anonymous Data Enumeration Across Salesforce Aura / LWR and ServiceNow Guest Search

작성자

카테고리:

← 피드로
DEV Community · Anoymask · 2026-08-13 개발(SW)

Anoymask

City-Forum: Anonymous Data Enumeration Across Salesforce Aura / LWR and ServiceNow Guest Search

1. Basic Information

2. One-Sentence Summary

A single Go-based tool uses unauthenticated Salesforce guest permissions to enumerate Aura and LWR GraphQL APIs, and quickly scans ServiceNow’s private Service Portal search API from the same source to collect data that site administrators accidentally left public.

3. Attack Flow

Salesforce Aura

  1. Finds an Experience Cloud site.
  2. Sends a POST request to /aura or /s/sfsites/aura as a guest.
  3. Uses HostConfigController.getConfigData to list Accounts, Contacts, Cases, Leads, Users, and ContentDocuments available to guests.
  4. Uses SelectableListDataProviderController.getItems to page through records for each object.
  5. Adds /SiteRegister and /CommunitiesSelfReg to each subsite to check if self-registration is open. No successful registrations were observed.

Salesforce LWR

  1. Identifies LWR sites using the lwr_app Link header or LWR.define(...).
  2. Sends a guest POST request to /webruntime/api/services/data/vNN.0/graphql.
  3. Queries EntityDefinition to list objects available via the UI API.
  4. Scans versions continuously from v56.0 to v66.0.
  5. Uses cursors to retrieve records allowed by guest object permissions, FLS, and sharing rules.

ServiceNow

  1. Opens the guest Service Portal using /$sp.do?...&id=landing.
  2. Sends search terms, portal information, sources, and counts to POST /api/now/sp/search?sysparm_cancelable=true.
  3. Uses response length to distinguish between empty responses and search terms that return content.
  4. Collects results that Knowledge Bases and custom search sources expose to guests.

4. Attacker Position and Execution Location

  • The traffic source is 158.220.87.79 on Contabo, and city-forum.com has pointed to this IP since 2025-03-12.
  • The tool uses Go-http-client/1.1 and connects from the internet to public Salesforce and ServiceNow Web APIs.
  • The processes run under the SaaS Guest User context. No malware runs on victim corporate endpoints.

5. Visibility for Victims and Administrators

  • There are no user actions, logins, or MFA events.
  • In Salesforce, large amounts of AuraRequest, Sites, sequential API versions, and self-registration URLs appear.
  • In ServiceNow, syslog_transaction shows Created by = guest, REST requests, /api/now/sp/search, and non-human timing intervals.
  • HTTP 201 is returned even for empty responses, so status codes alone cannot confirm successful data leaks.

6. Success and Failure Conditions

Success Conditions

  • Salesforce Guest Users have read permissions for objects, fields, and sharing rules.
  • LWR has “Allow guest users to access public APIs” enabled.
  • ServiceNow public portals have search sources without login gates or have loose KB read criteria.
  • Rate limits and anomaly detection do not block fast enumeration.

Failure Conditions

  • Guest Users are set to minimum privilege, removing unnecessary sharing, FLS, files, and activity permissions.
  • LWR guest UI APIs are disabled.
  • ServiceNow search sources use gs.isLoggedIn(), GlideRecordSecure, and proper roles/read criteria.
  • Guest access, non-browser user agents, and high-frequency enumeration are blocked.

7. What Happens on Success

Without breaking authentication, an attacker can bulk-collect customers, contacts, cases, documents, and knowledge articles that site owners exposed to Guest Users. This does not breach the Salesforce or ServiceNow platforms themselves; it abuses the anonymous public settings of each tenant. No successful self-registration or escalation to authenticated privileges has been observed.

8. Observable Logs

  • Email: Not used in this chain. city-forum.com allows the IP as an SPF sender, but email attacks are unconfirmed.
  • Proxy/SWG/DNS: Limited on the external user side. DNS shows city-forum.com resolving to 158.220.87.79.
  • Endpoint/EDR: No execution on victim terminals.
  • Identity/IdP: Salesforce and ServiceNow Guest Users. Not visible in normal sign-in logs alone.
  • SaaS/Cloud: Salesforce Event Monitoring logs for AuraRequest/Sites, CLIENT_IP, USER_AGENT, ACTION_MESSAGE, and URIs. ServiceNow syslog_transaction logs for IP, URL, Created by, User agent, and Output length.
  • Network: WAF/CDN logs showing Go-http-client/1.1, sequential API versions, and high-frequency POST requests to /aura, /webruntime/, and /api/now/sp/search.

9. Determining Attack Success

  • Contact Only: Public site GET requests, empty 201 responses, failed GraphQL calls.
  • Enumeration Started: getConfigData, EntityDefinition, API version sweeps, search term scans.
  • Data Retrieved: Increasing response size, paging in batches of 2000, hasNextPage cursors, and growing ServiceNow output lengths.
  • Self-Registration Attempted: Access to registration URLs only. Without account creation logs, privilege escalation is not confirmed.
  • Follow-on Abuse: Using retrieved data, authenticated accounts, or expanding to other SaaS platforms requires additional evidence.

10. Investigation Playbook

  • Trigger: 158.220.87.79, Go-http-client/1.1, massive guest Aura requests, LWR version sweeps, and sudden spikes in ServiceNow searches.
  • Initial Check: Identify the target portal, time, source IP, user agent, and response count/length to separate simple contact from data retrieval.
  • Terminals: Generally out of scope. Do not assume administrator terminals are compromised.
  • Authentication & Cloud: Audit Guest Profiles, sharing rules, FLS, UI APIs, self-registration, ServiceNow search sources, and KB read criteria.
  • Subsequent Actions: Look for phishing using the same data and email addresses, credential attacks, and unauthorized access to other SaaS apps.
  • Containment: Do not just block IOCs. Fix anonymous public permissions and identify the specific records that leaked.
  • Judgment Levels: Scanned / Enumeration Confirmed / Data Returned / Bulk Collection Confirmed / Self-Registration Confirmed / Follow-on Abuse.

11. Defense and Detection Ideas

  • Single Events: Guest user + Go-http-client/1.1, LWR UI API, ServiceNow guest search.
  • Time-Series Correlation: Site discovery -> configuration enumeration -> object paging -> self-registration checks. For ServiceNow, correlate search counts with output lengths.
  • Hunting: Look for ACTION$getConfigData, ACTION$getItems, v56.0→v66.0, SiteRegister, and guest sp/search requests.
  • Log Gaps: If Salesforce Event Monitoring licenses are missing, use CDN/WAF logs as a backup. ServiceNow does not log POST bodies, so search terms cannot be recovered.
  • Priority Fixes: Set Guest Users to minimum privilege, disable LWR guest UI APIs, stop self-registration, audit ServiceNow search sources and KB criteria, and implement rate limiting.

12. Facts / Inference / Hypothesis

Facts

  • The same IP address and Go tool crossed between Salesforce Aura, LWR, and ServiceNow.
  • The largest Salesforce target recorded over 560,000 events.
  • This is the first reported real-world observation of Salesforce LWR guest UI API abuse.
  • ServiceNow search APIs return HTTP 201 to both anonymous and authenticated users.
  • Reco has not attributed the attacker to a specific threat group.

Inference

  • Communications, financial, manufacturing, and public sector organizations with customer portals face similar configuration risks.
  • Blocking IOCs alone allows attackers to restart the same guest enumeration from a different IP address.

Hypothesis

  • The collected contact and case information may be used to improve the accuracy of targeted phishing or helpdesk fraud.

13. MITRE ATT&CK Mapping

  • High Confidence: T1589 Gather Victim Identity Information, T1595 Active Scanning, T1213 Data from Information Repositories, T1530 Data from Cloud Storage (if public documents are retrieved). T1190 Exploit Public-Facing Application is rated Low to Medium because this attack relies on configuration abuse.
  • Medium Confidence: T1114 / T1567, etc., are not confirmed in this material and apply only if follow-up abuse is discovered.

14. Unknowns and Additional Investigation

  • Attacker attribution, storage locations for collected data, and final goals.
  • The exact records and sensitivity levels returned to each organization.
  • Whether any environments succeeded in self-registration.
  • The time gap between infrastructure setup in March 2025 and the actual start of scanning.

15. Impact on SOCs and Organizations

SOCs that focus mainly on SaaS authentication logs easily miss this activity. Organizations that publicly expose Salesforce Experience Cloud or ServiceNow Portals must treat Guest Users not as “unauthenticated and therefore without privileges,” but rather audit them just like permanent service accounts.

16. Summary by Role

  • For SOCs: Monitor guest API enumeration and response volumes. Do not use HTTP 201 or the lack of logins as indicators of safety.
  • For Administrators: Audit Salesforce sharing, FLS, LWR UI APIs, and ServiceNow search sources/KB criteria.
  • For Portal Owners: Because this attack involves no user actions, portal owners must regularly review the scope of their public information.

원문에서 계속 ↗

추출 본문 · 출처: dev.to · https://dev.to/anoymask/city-forum-anonymous-data-enumeration-across-salesforce-aura-lwr-and-servicenow-guest-search-c1m

코멘트

답글 남기기

더 많은 게시물