Säkerhetsföretaget Reco har döpt den pågående kampanjen till City-Forum, efter domänen city-forum.com som är kopplad till angriparens infrastruktur. Sedan åtminstone mars 2025 har en enda hyrd server i Tyskland systematiskt hämtat data från telekomoperatörer, banker, finansiella tjänsteföretag, mjukvaruleverantörer och offentliga portaler.

Hur exploateringen fungerar: Ingen sårbarhet krävs

Både Salesforce och ServiceNow levereras med permanenta gästkonton för oautentiserade besökare. Dessa gästkonton kan inte tas bort. Deras behörigheter – vilka poster och objekt de kan läsa – konfigureras av varje organisation. Om gästprofilen har läsbehörighet till en post, kan vem som helst på internet hämta den via helt legitima API-slutpunkter.

På Salesforce (Aura-ramverket):

• Verktyget skickar POST-förfrågningar till slutpunkten /aura eller /s/sfsites/aura.
• Det anropar först HostConfigController.getConfigData för att räkna upp vilka objekt (Account, Contact, Case, Lead, User, ContentDocument, etc.) som är tillgängliga för gästen.
• Det använder sedan SelectableListDataProviderController.getItems för att bläddra igenom alla poster på varje tillgängligt objekt.
• Det mest belastade enskilda målet loggade över 560 000 händelser från angriparens IP, nästan allt Aura-enumrering från gäster.

På Salesforce (LWR-ramverket – Lightning Web Runtime):

• Detta är den första observerade exploateringen i verkligheten av Salesforces UI-API-gästyta på LWR-webbplatser.
• Verktyget riktar in sig på en GraphQL-slutpunkt på POST /webruntime/api/services/data/{version}/graphql?asGuest=true, enumererar först schemat via EntityDefinition och läser sedan poster med cursor-baserad paginering.
• Det sveper över API-versionerna v56.0 till v66.0 i följd mot varje upptäckt LWR-webbplats.

På ServiceNow:

• Verktyget riktar in sig på /api/now/sp/search-slutpunkten – ett inbyggt Service Portal-sök-API som är i stort sett odokumenterat och har nästan ingen dokumentation eller referens i open source-verktyg.
• Denna slutpunkt är offentlig av design. Vilken data den returnerar beror helt på vilka sökkällor som är kopplade till en gästportal och om dessa källor upprätthåller åtkomstkontroller.

Test av självregistrering (Salesforce):

• Verktyget lägger till /SiteRegister och /CommunitiesSelfReg till varje upptäckt experience site-sökväg för att testa om självregistrering är aktiverat. Om det är det kan en gäst uppgradera sig själv till en autentiserad extern användare och få tillgång till mycket mer data.

Den anpassade verktygsuppsättningen och infrastrukturen

• Käll-IP: 158.220.87.79, hostad på en Contabo VPS (tysk hosting-leverantör), som löser upp till domänen city-forum.com (en domän registrerad 2002, övergiven, sedan återanvänd).
• Samma IP har burit samma domän sedan mars 2025 utan rotation – minst 17 månader på en adress.
• Anpassad Go-binär: Ett enda Go-kompilerat verktyg som anropar Salesforce via både Aura- och LWR-ramverken och även anropar ServiceNow – allt från samma server. Detta är en anpassad multi-plattformsverktygssats, inte ett färdigt verktyg som AuraInspector.
• Verktyget använder Go:s standard Go-http-client User-Agent-sträng, vilket gör det lätt att identifiera i loggar.

Organisationer som är måltavlor

Reco rapporterar att de primära måltavlorna inkluderar:

• Telekomoperatörer
• Banker och finansiella tjänsteföretag
• Mjukvaruleverantörer (inklusive säkerhets- och dataskyddsföretag)
• Offentliga portaler

Varför standardrevisionsloggar inte kan avslöja vilken data som stulits

För ServiceNow: Plattformens transaktionsloggar (syslog_transaction) registrerar inte POST-kroppen för /api/now/sp/search-förfrågningar. Försvarare kan se att automatiserade sökningar inträffade och hur mycket data som returnerades (via kolumnen för utdatastorlek), men kan inte avgöra exakta söktermer eller vilka specifika poster som hämtades.

För Salesforce: Gäst-enumreringstrafiken består av legitima, protokollkompatibla API-anrop som ser ut som normal webbtrafik. Även om Event Monitoring kan visa volymen av AuraRequest- och Sites-händelser från gästanvändare, visar loggarna att data begärdes men inte det specifika innehållet av vad som returnerades i GraphQL- eller Aura-svaren.

Med andra ord: du kan se att angriparen var där och hur mycket de hämtade, men du kan inte rekonstruera exakt vilka poster eller fält de extraherade.

Rekommenderade åtgärder

För Salesforce (Recos rekommendationer):

1. Skärp gästdelningsreglerna – den enskilt mest effektiva kontrollen. Ta bort alla delningsregler som delar poster med gästanvändaren utöver vad webbplatsen verkligen behöver för att betjäna allmänheten.
2. Ta bort objekt- och fältnivåbehörigheter från gästprofilen. Ta bort läsbehörighet på objekt som webbplatsen inte behöver för anonyma besökare.
3. Ta bort behörigheten "Access Activities" från gästprofilen (exponerar Tasks och Events).
4. Inaktivera "API Enabled" på gästanvändaren.
5. Inaktivera självregistrering om inte webbplatsen verkligen kräver det.
6. Inaktivera gästfilåtkomst och medlemssynlighet så att gäster inte kan hämta ContentDocument-filer eller räkna upp andra webbplatsmedlemmar.
7. För LWR-webbplatser: I Experience Builder → Workspaces → Administration → Preferences, avmarkera "Allow guest users to access public APIs." Detta stänger GraphQL och UI-API REST-slutpunkterna i en åtgärd.

För ServiceNow (Recos rekommendationer):

1. Kartlägg gästportaler till deras sökkällor. Kontrollera tabellerna sp_portal, m2m_sp_portal_search_source och sp_search_source. Koppla bort alla sökkällor som en offentlig portal inte behöver.
2. Granska varje sökkällas logik – särskilt is_scripted_source, data_fetch_script och om den använder GlideRecordSecure (ACL-tvingande) vs. vanlig GlideRecord (som inte är det).
3. Granska kunskapsbasens "Can Read"-användarkriterier – leta efter obegränsad "Any User"-åtkomst som exponerar känsliga KB:er via gästsökning.
4. Koppla bort dåliga kb_uc_can_read_mtom-länkar snarare än att redigera delningsregler blint.

Detektionsvägledning:

• Salesforce Event Monitoring: Leta efter höga volymer av getItems och getConfigData från USER_TYPE = 'Guest', /webruntime/.../vNN.0/graphql-versionssvepningar och träffar på /SiteRegister och /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Leta efter /api/now/sp/search-förfrågningar som görs som gäst. Sortera efter utdatastorlek – rader som returnerar betydligt mer än den lilla baslinjen för tomt resultat indikerar sökningar som returnerat innehåll.

Säkerhetsföretaget Reco har döpt den pågående kampanjen till City-Forum, efter domänen city-forum.com som är kopplad till angriparens infrastruktur. Sedan åtminstone mars 2025 har en enda hyrd server i Tyskland systematiskt hämtat data från telekomoperatörer, banker, finansiella tjänsteföretag, mjukvaruleverantörer och offentliga portaler.

Hur exploateringen fungerar: Ingen sårbarhet krävs

Både Salesforce och ServiceNow levereras med permanenta gästkonton för oautentiserade besökare. Dessa gästkonton kan inte tas bort. Deras behörigheter – vilka poster och objekt de kan läsa – konfigureras av varje organisation. Om gästprofilen har läsbehörighet till en post, kan vem som helst på internet hämta den via helt legitima API-slutpunkter.

På Salesforce (Aura-ramverket):

• Verktyget skickar POST-förfrågningar till slutpunkten /aura eller /s/sfsites/aura.
• Det anropar först HostConfigController.getConfigData för att räkna upp vilka objekt (Account, Contact, Case, Lead, User, ContentDocument, etc.) som är tillgängliga för gästen.
• Det använder sedan SelectableListDataProviderController.getItems för att bläddra igenom alla poster på varje tillgängligt objekt.
• Det mest belastade enskilda målet loggade över 560 000 händelser från angriparens IP, nästan allt Aura-enumrering från gäster.

På Salesforce (LWR-ramverket – Lightning Web Runtime):

• Detta är den första observerade exploateringen i verkligheten av Salesforces UI-API-gästyta på LWR-webbplatser.
• Verktyget riktar in sig på en GraphQL-slutpunkt på POST /webruntime/api/services/data/{version}/graphql?asGuest=true, enumererar först schemat via EntityDefinition och läser sedan poster med cursor-baserad paginering.
• Det sveper över API-versionerna v56.0 till v66.0 i följd mot varje upptäckt LWR-webbplats.

På ServiceNow:

• Verktyget riktar in sig på /api/now/sp/search-slutpunkten – ett inbyggt Service Portal-sök-API som är i stort sett odokumenterat och har nästan ingen dokumentation eller referens i open source-verktyg.
• Denna slutpunkt är offentlig av design. Vilken data den returnerar beror helt på vilka sökkällor som är kopplade till en gästportal och om dessa källor upprätthåller åtkomstkontroller.

Test av självregistrering (Salesforce):

• Verktyget lägger till /SiteRegister och /CommunitiesSelfReg till varje upptäckt experience site-sökväg för att testa om självregistrering är aktiverat. Om det är det kan en gäst uppgradera sig själv till en autentiserad extern användare och få tillgång till mycket mer data.

Den anpassade verktygsuppsättningen och infrastrukturen

• Käll-IP: 158.220.87.79, hostad på en Contabo VPS (tysk hosting-leverantör), som löser upp till domänen city-forum.com (en domän registrerad 2002, övergiven, sedan återanvänd).
• Samma IP har burit samma domän sedan mars 2025 utan rotation – minst 17 månader på en adress.
• Anpassad Go-binär: Ett enda Go-kompilerat verktyg som anropar Salesforce via både Aura- och LWR-ramverken och även anropar ServiceNow – allt från samma server. Detta är en anpassad multi-plattformsverktygssats, inte ett färdigt verktyg som AuraInspector.
• Verktyget använder Go:s standard Go-http-client User-Agent-sträng, vilket gör det lätt att identifiera i loggar.

Organisationer som är måltavlor

Reco rapporterar att de primära måltavlorna inkluderar:

• Telekomoperatörer
• Banker och finansiella tjänsteföretag
• Mjukvaruleverantörer (inklusive säkerhets- och dataskyddsföretag)
• Offentliga portaler

Varför standardrevisionsloggar inte kan avslöja vilken data som stulits

För ServiceNow: Plattformens transaktionsloggar (syslog_transaction) registrerar inte POST-kroppen för /api/now/sp/search-förfrågningar. Försvarare kan se att automatiserade sökningar inträffade och hur mycket data som returnerades (via kolumnen för utdatastorlek), men kan inte avgöra exakta söktermer eller vilka specifika poster som hämtades.

För Salesforce: Gäst-enumreringstrafiken består av legitima, protokollkompatibla API-anrop som ser ut som normal webbtrafik. Även om Event Monitoring kan visa volymen av AuraRequest- och Sites-händelser från gästanvändare, visar loggarna att data begärdes men inte det specifika innehållet av vad som returnerades i GraphQL- eller Aura-svaren.

Med andra ord: du kan se att angriparen var där och hur mycket de hämtade, men du kan inte rekonstruera exakt vilka poster eller fält de extraherade.

Rekommenderade åtgärder

För Salesforce (Recos rekommendationer):

1. Skärp gästdelningsreglerna – den enskilt mest effektiva kontrollen. Ta bort alla delningsregler som delar poster med gästanvändaren utöver vad webbplatsen verkligen behöver för att betjäna allmänheten.
2. Ta bort objekt- och fältnivåbehörigheter från gästprofilen. Ta bort läsbehörighet på objekt som webbplatsen inte behöver för anonyma besökare.
3. Ta bort behörigheten "Access Activities" från gästprofilen (exponerar Tasks och Events).
4. Inaktivera "API Enabled" på gästanvändaren.
5. Inaktivera självregistrering om inte webbplatsen verkligen kräver det.
6. Inaktivera gästfilåtkomst och medlemssynlighet så att gäster inte kan hämta ContentDocument-filer eller räkna upp andra webbplatsmedlemmar.
7. För LWR-webbplatser: I Experience Builder → Workspaces → Administration → Preferences, avmarkera "Allow guest users to access public APIs." Detta stänger GraphQL och UI-API REST-slutpunkterna i en åtgärd.

För ServiceNow (Recos rekommendationer):

1. Kartlägg gästportaler till deras sökkällor. Kontrollera tabellerna sp_portal, m2m_sp_portal_search_source och sp_search_source. Koppla bort alla sökkällor som en offentlig portal inte behöver.
2. Granska varje sökkällas logik – särskilt is_scripted_source, data_fetch_script och om den använder GlideRecordSecure (ACL-tvingande) vs. vanlig GlideRecord (som inte är det).
3. Granska kunskapsbasens "Can Read"-användarkriterier – leta efter obegränsad "Any User"-åtkomst som exponerar känsliga KB:er via gästsökning.
4. Koppla bort dåliga kb_uc_can_read_mtom-länkar snarare än att redigera delningsregler blint.

Detektionsvägledning:

• Salesforce Event Monitoring: Leta efter höga volymer av getItems och getConfigData från USER_TYPE = 'Guest', /webruntime/.../vNN.0/graphql-versionssvepningar och träffar på /SiteRegister och /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Leta efter /api/now/sp/search-förfrågningar som görs som gäst. Sortera efter utdatastorlek – rader som returnerar betydligt mer än den lilla baslinjen för tomt resultat indikerar sökningar som returnerat innehåll.