La società di sicurezza Reco ha chiamato questa campagna in corso City-Forum, dal dominio city-forum.com utilizzato per l'infrastruttura dell'attaccante. Da almeno marzo 2025, un singolo server noleggiato in Germania sta sistematicamente raccogliendo dati da provider di telecomunicazioni, banche, società di servizi finanziari, vendor di software enterprise e portali del settore pubblico.

Come funziona lo sfruttamento: nessuna vulnerabilità necessaria

Sia Salesforce che ServiceNow includono account guest permanenti per visitatori non autenticati. Questi account guest non possono essere eliminati. I loro permessi – quali record e oggetti possono leggere – sono configurati da ogni organizzazione. Se il profilo guest ha accesso in lettura a un record, chiunque su Internet può recuperarlo tramite endpoint API perfettamente legittimi.

Su Salesforce (framework Aura):

• Lo strumento invia richieste POST all'endpoint /aura o /s/sfsites/aura.
• Prima chiama HostConfigController.getConfigData per enumerare quali oggetti (Account, Contact, Case, Lead, User, ContentDocument, ecc.) sono accessibili al guest.
• Poi usa SelectableListDataProviderController.getItems per scorrere tutti i record su ogni oggetto accessibile.
• Il singolo target più attivo ha registrato oltre 560.000 eventi dall'IP dell'attaccante, quasi tutti di enumerazione Aura guest.

Su Salesforce (framework LWR – Lightning Web Runtime):

• Questo è il primo sfruttamento in-the-wild della superficie guest UI-API di Salesforce sui siti LWR.
• Lo strumento prende di mira un endpoint GraphQL a POST /webruntime/api/services/data/{version}/graphql?asGuest=true, prima enumerando lo schema tramite EntityDefinition, poi leggendo i record con paginazione basata su cursore.
• Scansiona le versioni API dalla v56.0 alla v66.0 in sequenza contro ogni sito LWR scoperto.

Su ServiceNow:

• Lo strumento prende di mira l'endpoint /api/now/sp/search – un'API di ricerca nativa di Service Portal ampiamente non documentata con quasi nessuna documentazione online o strumento open-source che la menzioni.
• Questo endpoint è pubblico per progettazione. I dati che restituisce dipendono interamente da quali fonti di ricerca sono collegate a un portal guest e se tali fonti applicano controlli di accesso.

Sondaggio di auto-registrazione (Salesforce):

• Lo strumento aggiunge /SiteRegister e /CommunitiesSelfReg a ogni percorso di sito experience scoperto per testare se l'auto-registrazione è abilitata. Se lo è, un guest può promuoversi a utente esterno autenticato, ottenendo accesso a molti più dati.

Il toolset personalizzato e l'infrastruttura

• IP sorgente: 158.220.87.79, ospitato su un VPS Contabo (provider di hosting tedesco), che risolve al dominio city-forum.com (un dominio registrato nel 2002, abbandonato e poi riutilizzato).
• Lo stesso IP ha portato lo stesso dominio da marzo 2025 senza rotazione – almeno 17 mesi su un singolo indirizzo.
• Binario Go personalizzato: Un singolo binario compilato in Go che colpisce Salesforce sia su framework Aura che LWR e anche ServiceNow – tutto dallo stesso server. Questo è un toolset multi-piattaforma personalizzato, non uno strumento standard come AuraInspector.
• Lo strumento usa lo User-Agent predefinito Go-http-client, rendendolo facile da identificare nei log.

Organizzazioni prese di mira

Reco riporta che i bersagli principali includono:

• Operatori di telecomunicazioni
• Banche e società di servizi finanziari
• Vendor di software enterprise (incluse aziende di sicurezza e privacy dei dati)
• Portali del settore pubblico

Perché i log di audit standard non possono rivelare quali dati sono stati sottratti

Per ServiceNow: I log di transazione della piattaforma (syslog_transaction) non registrano il corpo POST delle richieste /api/now/sp/search. I difensori possono vedere che sono avvenute ricerche automatizzate e quanti dati sono stati restituiti (tramite la colonna della lunghezza dell'output), ma non possono determinare i termini di ricerca esatti o quali record specifici sono stati recuperati.

Per Salesforce: Il traffico di enumerazione guest consiste in chiamate API legittime e conformi al protocollo che sembrano traffico normale del sito. Sebbene Event Monitoring possa mostrare il volume di eventi AuraRequest e Sites da utenti guest, i log mostrano che i dati sono stati richiesti ma non il contenuto specifico di ciò che è stato restituito nelle risposte GraphQL o Aura.

In altre parole, puoi vedere che l'attaccante era presente e quanto ha prelevato, ma non puoi ricostruire esattamente quali record o campi sono stati estratti.

Passaggi di remediation raccomandati

Per Salesforce (raccomandazioni di Reco):

1. Rafforzare le regole di condivisione guest – il controllo a più alto impatto. Rimuovi qualsiasi regola di condivisione che condivida record con l'Utente Guest oltre quanto strettamente necessario per il sito.
2. Rimuovere i permessi a livello di oggetto e campo dal profilo guest. Rimuovi l'accesso in lettura su oggetti che il sito non necessita per visitatori anonimi.
3. Rimuovere il permesso "Access Activities" dal profilo guest (espone Tasks ed Events).
4. Disabilitare "API Enabled" sull'utente guest.
5. Disabilitare l'auto-registrazione a meno che il sito non la richieda veramente.
6. Disabilitare l'accesso guest ai file e la visibilità dei membri così che i guest non possano recuperare file ContentDocument o enumerare altri membri del sito.
7. Solo per siti LWR: In Experience Builder → Workspaces → Administration → Preferences, deseleziona "Allow guest users to access public APIs." Questo chiude GraphQL e gli endpoint REST UI-API in un solo gesto.

Per ServiceNow (raccomandazioni di Reco):

1. Mappare i portal guest alle loro fonti di ricerca. Controlla le tabelle sp_portal, m2m_sp_portal_search_source e sp_search_source. Scollega qualsiasi fonte di ricerca di cui un portal pubblico non ha bisogno.
2. Revisionare la logica di ogni fonte di ricerca – specialmente is_scripted_source, data_fetch_script e se usa GlideRecordSecure (che applica ACL) rispetto al semplice GlideRecord (che non lo fa).
3. Revisionare i criteri utente "Can Read" della knowledge base – cerca accesso non vincolato "Any User" che espone KB sensibili attraverso la ricerca guest.
4. Scollegare i link kb_uc_can_read_mtom errati piuttosto che modificare ciecamente le regole di condivisione.

Guida al rilevamento:

• Salesforce Event Monitoring: Cerca alti volumi di getItems e getConfigData da USER_TYPE = 'Guest', scansioni di versione /webruntime/.../vNN.0/graphql e hit su /SiteRegister e /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Cerca richieste /api/now/sp/search fatte come guest. Ordina per lunghezza dell'output – righe che restituiscono significativamente più della piccola baseline di risultato vuoto indicano ricerche che hanno restituito contenuto.

La società di sicurezza Reco ha chiamato questa campagna in corso City-Forum, dal dominio city-forum.com utilizzato per l'infrastruttura dell'attaccante. Da almeno marzo 2025, un singolo server noleggiato in Germania sta sistematicamente raccogliendo dati da provider di telecomunicazioni, banche, società di servizi finanziari, vendor di software enterprise e portali del settore pubblico.

Come funziona lo sfruttamento: nessuna vulnerabilità necessaria

Sia Salesforce che ServiceNow includono account guest permanenti per visitatori non autenticati. Questi account guest non possono essere eliminati. I loro permessi – quali record e oggetti possono leggere – sono configurati da ogni organizzazione. Se il profilo guest ha accesso in lettura a un record, chiunque su Internet può recuperarlo tramite endpoint API perfettamente legittimi.

Su Salesforce (framework Aura):

• Lo strumento invia richieste POST all'endpoint /aura o /s/sfsites/aura.
• Prima chiama HostConfigController.getConfigData per enumerare quali oggetti (Account, Contact, Case, Lead, User, ContentDocument, ecc.) sono accessibili al guest.
• Poi usa SelectableListDataProviderController.getItems per scorrere tutti i record su ogni oggetto accessibile.
• Il singolo target più attivo ha registrato oltre 560.000 eventi dall'IP dell'attaccante, quasi tutti di enumerazione Aura guest.

Su Salesforce (framework LWR – Lightning Web Runtime):

• Questo è il primo sfruttamento in-the-wild della superficie guest UI-API di Salesforce sui siti LWR.
• Lo strumento prende di mira un endpoint GraphQL a POST /webruntime/api/services/data/{version}/graphql?asGuest=true, prima enumerando lo schema tramite EntityDefinition, poi leggendo i record con paginazione basata su cursore.
• Scansiona le versioni API dalla v56.0 alla v66.0 in sequenza contro ogni sito LWR scoperto.

Su ServiceNow:

• Lo strumento prende di mira l'endpoint /api/now/sp/search – un'API di ricerca nativa di Service Portal ampiamente non documentata con quasi nessuna documentazione online o strumento open-source che la menzioni.
• Questo endpoint è pubblico per progettazione. I dati che restituisce dipendono interamente da quali fonti di ricerca sono collegate a un portal guest e se tali fonti applicano controlli di accesso.

Sondaggio di auto-registrazione (Salesforce):

• Lo strumento aggiunge /SiteRegister e /CommunitiesSelfReg a ogni percorso di sito experience scoperto per testare se l'auto-registrazione è abilitata. Se lo è, un guest può promuoversi a utente esterno autenticato, ottenendo accesso a molti più dati.

Il toolset personalizzato e l'infrastruttura

• IP sorgente: 158.220.87.79, ospitato su un VPS Contabo (provider di hosting tedesco), che risolve al dominio city-forum.com (un dominio registrato nel 2002, abbandonato e poi riutilizzato).
• Lo stesso IP ha portato lo stesso dominio da marzo 2025 senza rotazione – almeno 17 mesi su un singolo indirizzo.
• Binario Go personalizzato: Un singolo binario compilato in Go che colpisce Salesforce sia su framework Aura che LWR e anche ServiceNow – tutto dallo stesso server. Questo è un toolset multi-piattaforma personalizzato, non uno strumento standard come AuraInspector.
• Lo strumento usa lo User-Agent predefinito Go-http-client, rendendolo facile da identificare nei log.

Organizzazioni prese di mira

Reco riporta che i bersagli principali includono:

• Operatori di telecomunicazioni
• Banche e società di servizi finanziari
• Vendor di software enterprise (incluse aziende di sicurezza e privacy dei dati)
• Portali del settore pubblico

Perché i log di audit standard non possono rivelare quali dati sono stati sottratti

Per ServiceNow: I log di transazione della piattaforma (syslog_transaction) non registrano il corpo POST delle richieste /api/now/sp/search. I difensori possono vedere che sono avvenute ricerche automatizzate e quanti dati sono stati restituiti (tramite la colonna della lunghezza dell'output), ma non possono determinare i termini di ricerca esatti o quali record specifici sono stati recuperati.

Per Salesforce: Il traffico di enumerazione guest consiste in chiamate API legittime e conformi al protocollo che sembrano traffico normale del sito. Sebbene Event Monitoring possa mostrare il volume di eventi AuraRequest e Sites da utenti guest, i log mostrano che i dati sono stati richiesti ma non il contenuto specifico di ciò che è stato restituito nelle risposte GraphQL o Aura.

In altre parole, puoi vedere che l'attaccante era presente e quanto ha prelevato, ma non puoi ricostruire esattamente quali record o campi sono stati estratti.

Passaggi di remediation raccomandati

Per Salesforce (raccomandazioni di Reco):

1. Rafforzare le regole di condivisione guest – il controllo a più alto impatto. Rimuovi qualsiasi regola di condivisione che condivida record con l'Utente Guest oltre quanto strettamente necessario per il sito.
2. Rimuovere i permessi a livello di oggetto e campo dal profilo guest. Rimuovi l'accesso in lettura su oggetti che il sito non necessita per visitatori anonimi.
3. Rimuovere il permesso "Access Activities" dal profilo guest (espone Tasks ed Events).
4. Disabilitare "API Enabled" sull'utente guest.
5. Disabilitare l'auto-registrazione a meno che il sito non la richieda veramente.
6. Disabilitare l'accesso guest ai file e la visibilità dei membri così che i guest non possano recuperare file ContentDocument o enumerare altri membri del sito.
7. Solo per siti LWR: In Experience Builder → Workspaces → Administration → Preferences, deseleziona "Allow guest users to access public APIs." Questo chiude GraphQL e gli endpoint REST UI-API in un solo gesto.

Per ServiceNow (raccomandazioni di Reco):

1. Mappare i portal guest alle loro fonti di ricerca. Controlla le tabelle sp_portal, m2m_sp_portal_search_source e sp_search_source. Scollega qualsiasi fonte di ricerca di cui un portal pubblico non ha bisogno.
2. Revisionare la logica di ogni fonte di ricerca – specialmente is_scripted_source, data_fetch_script e se usa GlideRecordSecure (che applica ACL) rispetto al semplice GlideRecord (che non lo fa).
3. Revisionare i criteri utente "Can Read" della knowledge base – cerca accesso non vincolato "Any User" che espone KB sensibili attraverso la ricerca guest.
4. Scollegare i link kb_uc_can_read_mtom errati piuttosto che modificare ciecamente le regole di condivisione.

Guida al rilevamento:

• Salesforce Event Monitoring: Cerca alti volumi di getItems e getConfigData da USER_TYPE = 'Guest', scansioni di versione /webruntime/.../vNN.0/graphql e hit su /SiteRegister e /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Cerca richieste /api/now/sp/search fatte come guest. Ordina per lunghezza dell'output – righe che restituiscono significativamente più della piccola baseline di risultato vuoto indicano ricerche che hanno restituito contenuto.