Sikkerhetsselskapet Reco har gitt denne pågående kampanjen navnet By-Forum, etter domenet city-forum.com som er registrert til angriperens infrastruktur. Siden minst mars 2025 har en enkelt leid server i Tyskland systematisk hentet data fra telekommunikasjonsleverandører, banker, finansielle tjenesteleverandører, programvareleverandører og offentlige portaler.

Hvordan utnyttelsen fungerer: Ingen sårbarhet nødvendig

Både Salesforce og ServiceNow leveres med permanente gjestebrukerkontoer for uautentiserte besøkende. Disse gjestebrukerne kan ikke slettes. Tillatelsene deres – hvilke oppføringer og objekter de kan lese – konfigureres av hver enkelt organisasjon. Hvis gjesteprofilen har lesetilgang til en oppføring, kan hvem som helst på internett hente den via helt legitime API-endepunkter.

På Salesforce (Aura-rammeverk):

• Verktøyet sender POST-forespørsler til endepunktet /aura eller /s/sfsites/aura.
• Det kaller først HostConfigController.getConfigData for å finne ut hvilke objekter (Konto, Kontakt, Sak, Lead, Bruker, ContentDocument, etc.) som er tilgjengelige for gjesten.
• Deretter bruker det SelectableListDataProviderController.getItems for å bla gjennom alle oppføringer på hvert tilgjengelig objekt.
• Det travleste enkeltmålet logget over 560 000 hendelser fra angriperens IP, nesten alle gjeste-Aura-oppramsing.

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

• Dette er den første observerte utnyttelsen i fri natur av Salesforces UI-API-gjesteflate på LWR-nettsteder.
• Verktøyet målretter et GraphQL-endepunkt ved POST /webruntime/api/services/data/{version}/graphql?asGuest=true, først ved å ramse opp skjemaet via EntityDefinition, deretter lese oppføringer med markørbasert paginering.
• Det sveiper over API-versjoner v56.0 til v66.0 i rekkefølge mot hvert oppdagede LWR-nettsted.

På ServiceNow:

• Verktøyet målretter endepunktet /api/now/sp/search – et innebygd Service Portal-søke-API som er stort sett udokumentert og har nesten ingen nettdokumentasjon eller open-source-verktøy som refererer til det.
• Dette endepunktet er offentlig av design. Hvilke data det returnerer avhenger helt av hvilke søkekilder som er koblet til en gjestevendt portal og om disse kildene håndhever tilgangskontroller.

Selvregistreringssonder (Salesforce):

• Verktøyet legger til /SiteRegister og /CommunitiesSelfReg til hver oppdagede opplevelsesnettstedssti for å teste om selvregistrering er aktivert. Hvis det er det, kan en gjest oppgradere seg selv til en autentisert ekstern bruker, og dermed få tilgang til langt mer data.

Det tilpassede verktøysettet og infrastrukturen

• Kilde-IP: 158.220.87.79, vert på en Contabo VPS (tysk nettvertleverandør), som løser til domenet city-forum.com (et domene registrert i 2002, forlatt, deretter gjenbrukt).
• Den samme IP-adressen har hatt det samme domenet siden mars 2025 uten rotasjon – minst 17 måneder på én adresse.
• Tilpasset Go-binær: Et enkelt Go-kompilert verktøy som treffer Salesforce via både Aura- og LWR-rammeverk og også treffer ServiceNow – alt fra samme server. Dette er et tilpasset multiplattform-verktøysett, ikke et hyllevareverktøy som AuraInspector.
• Verktøyet bruker Go's standard Go-http-client User-Agent-streng, noe som gjør det lett å identifisere i logger.

Organisasjoner som er målrettet

Reco rapporterer at primærmålene inkluderer:

• Telekomoperatører
• Banker og finansielle tjenesteleverandører
• Programvareleverandører (inkludert sikkerhets- og datapersonvernselskaper)
• Offentlige portaler

Hvorfor standard revisjonslogger ikke kan avsløre hvilke data som ble tatt

For ServiceNow: Plattformens transaksjonslogger (syslog_transaction) registrerer ikke POST-kroppen til /api/now/sp/search-forespørsler. Forsvarere kan se at automatiserte søk fant sted og hvor mye data som ble returnert (via kolonnen for utdatalengde), men kan ikke fastslå de nøyaktige søkeordene eller hvilke spesifikke oppføringer som ble hentet.

For Salesforce: Gjesteoppramsingstrafikken består av legitime, protokollkompatible API-kall som ser ut som normal nettstedtrafikk. Selv om hendelsesovervåking kan vise volumet av AuraRequest- og Sites-hendelser fra gjestebrukere, viser loggene at data ble forespurt, men ikke det spesifikke innholdet av hva som ble returnert i GraphQL- eller Aura-svarene.

Med andre ord: du kan se at angriperen var der og hvor mye de hentet, men du kan ikke rekonstruere nøyaktig hvilke oppføringer eller felt de hentet ut.

Anbefalte utbedringstrinn

For Salesforce (Recos anbefalinger):

1. Stram inn gjestedelingsregler – den enkeltstående kontrollen med høyest effekt. Fjern enhver delingsregel som deler oppføringer med gjestebrukeren utover det nettstedet faktisk trenger for å betjene offentligheten.
2. Fjern objekt- og felttillatelser fra gjesteprofilen. Fjern lesetilgang på objekter nettstedet ikke trenger for anonyme besøkende.
3. Fjern tillatelsen "Tilgang til aktiviteter" fra gjesteprofilen (eksponerer oppgaver og hendelser).
4. Deaktiver "API aktivert" på gjestebrukeren.
5. Deaktiver selvregistrering med mindre nettstedet virkelig trenger det.
6. Deaktiver gjestefiltilgang og medlemssynlighet slik at gjester ikke kan hente ContentDocument-filer eller liste opp andre nettstedsmedlemmer.
7. For LWR-nettsteder kun: I Experience Builder → Arbeidsområder → Administrasjon → Innstillinger, fjern merket for "Tillat gjestebrukere tilgang til offentlige APIer." Dette stenger GraphQL og UI-API REST-endepunktene i én bevegelse.

For ServiceNow (Recos anbefalinger):

1. Kartlegg gjestevendte portaler til søkekildene deres. Sjekk tabellene sp_portal, m2m_sp_portal_search_source og sp_search_source. Koble fra enhver søkekilde en offentlig portal ikke trenger.
2. Gå gjennom hver søkekildes logikk – spesielt is_scripted_source, data_fetch_script, og om den bruker GlideRecordSecure (ACL-håndhever) vs. vanlig GlideRecord (som ikke gjør det).
3. Gå gjennom kunnskapsbasens "Kan lese"-brukerkriterier – se etter ubegrenset "Enhver bruker"-tilgang som eksponerer sensitive KB-er via gjestesøk.
4. Koble fra dårlige kb_uc_can_read_mtom-lenker i stedet for å redigere delingsregler blindt.

Deteksjonsveiledning:

• Salesforce-hendelsesovervåking: Se etter høye volumer av getItems og getConfigData fra USER_TYPE = 'Guest', /webruntime/.../vNN.0/graphql-versjonssveip, og treff på /SiteRegister og /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Se etter /api/now/sp/search-forespørsler gjort som gjest. Sorter etter utdatalengde – rader som returnerer betydelig mer enn den lille tomme resultat-baseline indikerer søk som returnerte innhold.

Sikkerhetsselskapet Reco har gitt denne pågående kampanjen navnet By-Forum, etter domenet city-forum.com som er registrert til angriperens infrastruktur. Siden minst mars 2025 har en enkelt leid server i Tyskland systematisk hentet data fra telekommunikasjonsleverandører, banker, finansielle tjenesteleverandører, programvareleverandører og offentlige portaler.

Hvordan utnyttelsen fungerer: Ingen sårbarhet nødvendig

Både Salesforce og ServiceNow leveres med permanente gjestebrukerkontoer for uautentiserte besøkende. Disse gjestebrukerne kan ikke slettes. Tillatelsene deres – hvilke oppføringer og objekter de kan lese – konfigureres av hver enkelt organisasjon. Hvis gjesteprofilen har lesetilgang til en oppføring, kan hvem som helst på internett hente den via helt legitime API-endepunkter.

På Salesforce (Aura-rammeverk):

• Verktøyet sender POST-forespørsler til endepunktet /aura eller /s/sfsites/aura.
• Det kaller først HostConfigController.getConfigData for å finne ut hvilke objekter (Konto, Kontakt, Sak, Lead, Bruker, ContentDocument, etc.) som er tilgjengelige for gjesten.
• Deretter bruker det SelectableListDataProviderController.getItems for å bla gjennom alle oppføringer på hvert tilgjengelig objekt.
• Det travleste enkeltmålet logget over 560 000 hendelser fra angriperens IP, nesten alle gjeste-Aura-oppramsing.

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

• Dette er den første observerte utnyttelsen i fri natur av Salesforces UI-API-gjesteflate på LWR-nettsteder.
• Verktøyet målretter et GraphQL-endepunkt ved POST /webruntime/api/services/data/{version}/graphql?asGuest=true, først ved å ramse opp skjemaet via EntityDefinition, deretter lese oppføringer med markørbasert paginering.
• Det sveiper over API-versjoner v56.0 til v66.0 i rekkefølge mot hvert oppdagede LWR-nettsted.

På ServiceNow:

• Verktøyet målretter endepunktet /api/now/sp/search – et innebygd Service Portal-søke-API som er stort sett udokumentert og har nesten ingen nettdokumentasjon eller open-source-verktøy som refererer til det.
• Dette endepunktet er offentlig av design. Hvilke data det returnerer avhenger helt av hvilke søkekilder som er koblet til en gjestevendt portal og om disse kildene håndhever tilgangskontroller.

Selvregistreringssonder (Salesforce):

• Verktøyet legger til /SiteRegister og /CommunitiesSelfReg til hver oppdagede opplevelsesnettstedssti for å teste om selvregistrering er aktivert. Hvis det er det, kan en gjest oppgradere seg selv til en autentisert ekstern bruker, og dermed få tilgang til langt mer data.

Det tilpassede verktøysettet og infrastrukturen

• Kilde-IP: 158.220.87.79, vert på en Contabo VPS (tysk nettvertleverandør), som løser til domenet city-forum.com (et domene registrert i 2002, forlatt, deretter gjenbrukt).
• Den samme IP-adressen har hatt det samme domenet siden mars 2025 uten rotasjon – minst 17 måneder på én adresse.
• Tilpasset Go-binær: Et enkelt Go-kompilert verktøy som treffer Salesforce via både Aura- og LWR-rammeverk og også treffer ServiceNow – alt fra samme server. Dette er et tilpasset multiplattform-verktøysett, ikke et hyllevareverktøy som AuraInspector.
• Verktøyet bruker Go's standard Go-http-client User-Agent-streng, noe som gjør det lett å identifisere i logger.

Organisasjoner som er målrettet

Reco rapporterer at primærmålene inkluderer:

• Telekomoperatører
• Banker og finansielle tjenesteleverandører
• Programvareleverandører (inkludert sikkerhets- og datapersonvernselskaper)
• Offentlige portaler

Hvorfor standard revisjonslogger ikke kan avsløre hvilke data som ble tatt

For ServiceNow: Plattformens transaksjonslogger (syslog_transaction) registrerer ikke POST-kroppen til /api/now/sp/search-forespørsler. Forsvarere kan se at automatiserte søk fant sted og hvor mye data som ble returnert (via kolonnen for utdatalengde), men kan ikke fastslå de nøyaktige søkeordene eller hvilke spesifikke oppføringer som ble hentet.

For Salesforce: Gjesteoppramsingstrafikken består av legitime, protokollkompatible API-kall som ser ut som normal nettstedtrafikk. Selv om hendelsesovervåking kan vise volumet av AuraRequest- og Sites-hendelser fra gjestebrukere, viser loggene at data ble forespurt, men ikke det spesifikke innholdet av hva som ble returnert i GraphQL- eller Aura-svarene.

Med andre ord: du kan se at angriperen var der og hvor mye de hentet, men du kan ikke rekonstruere nøyaktig hvilke oppføringer eller felt de hentet ut.

Anbefalte utbedringstrinn

For Salesforce (Recos anbefalinger):

1. Stram inn gjestedelingsregler – den enkeltstående kontrollen med høyest effekt. Fjern enhver delingsregel som deler oppføringer med gjestebrukeren utover det nettstedet faktisk trenger for å betjene offentligheten.
2. Fjern objekt- og felttillatelser fra gjesteprofilen. Fjern lesetilgang på objekter nettstedet ikke trenger for anonyme besøkende.
3. Fjern tillatelsen "Tilgang til aktiviteter" fra gjesteprofilen (eksponerer oppgaver og hendelser).
4. Deaktiver "API aktivert" på gjestebrukeren.
5. Deaktiver selvregistrering med mindre nettstedet virkelig trenger det.
6. Deaktiver gjestefiltilgang og medlemssynlighet slik at gjester ikke kan hente ContentDocument-filer eller liste opp andre nettstedsmedlemmer.
7. For LWR-nettsteder kun: I Experience Builder → Arbeidsområder → Administrasjon → Innstillinger, fjern merket for "Tillat gjestebrukere tilgang til offentlige APIer." Dette stenger GraphQL og UI-API REST-endepunktene i én bevegelse.

For ServiceNow (Recos anbefalinger):

1. Kartlegg gjestevendte portaler til søkekildene deres. Sjekk tabellene sp_portal, m2m_sp_portal_search_source og sp_search_source. Koble fra enhver søkekilde en offentlig portal ikke trenger.
2. Gå gjennom hver søkekildes logikk – spesielt is_scripted_source, data_fetch_script, og om den bruker GlideRecordSecure (ACL-håndhever) vs. vanlig GlideRecord (som ikke gjør det).
3. Gå gjennom kunnskapsbasens "Kan lese"-brukerkriterier – se etter ubegrenset "Enhver bruker"-tilgang som eksponerer sensitive KB-er via gjestesøk.
4. Koble fra dårlige kb_uc_can_read_mtom-lenker i stedet for å redigere delingsregler blindt.

Deteksjonsveiledning:

• Salesforce-hendelsesovervåking: Se etter høye volumer av getItems og getConfigData fra USER_TYPE = 'Guest', /webruntime/.../vNN.0/graphql-versjonssveip, og treff på /SiteRegister og /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Se etter /api/now/sp/search-forespørsler gjort som gjest. Sorter etter utdatalengde – rader som returnerer betydelig mer enn den lille tomme resultat-baseline indikerer søk som returnerte innhold.