Firma bezpieczeństwa Reco nazwała tę kampanię City-Forum — od domeny city-forum.com powiązanej z infrastrukturą atakującego. Od co najmniej marca 2025 roku pojedynczy wynajęty serwer w Niemczech systematycznie zbiera dane od operatorów telekomunikacyjnych, banków, firm finansowych, dostawców oprogramowania korporacyjnego oraz portali sektora publicznego.

Jak działa exploit: bez podatności

Zarówno Salesforce, jak i ServiceNow mają wbudowane, stałe konta gościnne dla nieuwierzytelnionych odwiedzających. Tych kont nie można usunąć. Ich uprawnienia — jakie rekordy i obiekty mogą odczytywać — są konfigurowane przez każdą organizację. Jeśli profil gościa ma dostęp do odczytu do rekordu, każda osoba w Internecie może go pobrać za pomocą w pełni legalnych endpointów API.

W Salesforce (framework Aura):

• Narzędzie wysyła żądania POST do endpointu /aura lub /s/sfsites/aura.
• Najpierw wywołuje HostConfigController.getConfigData, aby wymienić obiekty (Konto, Kontakt, Sprawa, Lead, Użytkownik, ContentDocument itp.), do których gość ma dostęp.
• Następnie używa SelectableListDataProviderController.getItems do przewijania wszystkich rekordów w każdym dostępnym obiekcie.
• Najbardziej obciążony pojedynczy cel zarejestrował ponad 560 000 zdarzeń z adresu IP atakującego, prawie wyłącznie związanych z wyliczaniem Aura.

W Salesforce (framework LWR — Lightning Web Runtime):

• Jest to pierwsze zaobserwowane w środowisku produkcyjnym wykorzystanie powierzchni gościnnej UI-API Salesforce w witrynach LWR.
• Narzędzie celuje w endpoint GraphQL pod adresem POST /webruntime/api/services/data/{version}/graphql?asGuest=true, najpierw wyliczając schemat za pomocą EntityDefinition, a następnie odczytując rekordy z paginacją opartą na kursorach.
• Przeszukuje wersje API od v56.0 do v66.0 po kolei dla każdej odkrytej witryny LWR.

W ServiceNow:

• Narzędzie celuje w endpoint /api/now/sp/search — natywne API wyszukiwania Service Portal, które jest w dużej mierze nieudokumentowane i ma prawie zero dokumentacji online lub narzędzi open-source, które by się do niego odwoływały.
• Ten endpoint jest z założenia publiczny. To, jakie dane zwraca, zależy wyłącznie od tego, które źródła wyszukiwania są podłączone do portalu gościnnego i czy te źródła egzekwują kontrolę dostępu.

Próby samorejestracji (Salesforce):

• Narzędzie dodaje /SiteRegister i /CommunitiesSelfReg do każdej odkrytej ścieżki witryny experience, aby sprawdzić, czy samorejestracja jest włączona. Jeśli tak, gość może awansować do uwierzytelnionego użytkownika zewnętrznego, zyskując dostęp do znacznie większej ilości danych.

Niestandardowe narzędzia i infrastruktura

• Źródłowy adres IP: 158.220.87.79, hostowany na VPS Contabo (niemiecki dostawca), rozwiązywany do domeny city-forum.com (zarejestrowanej w 2002 r., porzuconej, a następnie ponownie wykorzystanej).
• Ten sam adres IP jest powiązany z tą samą domeną od marca 2025 roku bez rotacji — co najmniej 17 miesięcy na jednym adresie.
• Niestandardowa binarka Go: Pojedyncze narzędzie skompilowane w Go, które atakuje Salesforce zarówno przez Aura, jak i LWR, a także ServiceNow — wszystko z tego samego serwera. To niestandardowy, wieloplatformowy zestaw narzędzi, a nie gotowe narzędzie, takie jak AuraInspector.
• Narzędzie używa domyślnego ciągu Go Go-http-client jako User-Agent, co ułatwia jego identyfikację w logach.

Organizacje będące celem

Reco podaje, że główne cele to:

• Operatorzy telekomunikacyjni
• Banki i firmy usług finansowych
• Dostawcy oprogramowania korporacyjnego (w tym firmy zajmujące się bezpieczeństwem i ochroną danych)
• Portale sektora publicznego

Dlaczego standardowe logi audytowe nie ujawniają, jakie dane zostały skradzione

W przypadku ServiceNow: Logi transakcyjne platformy (syslog_transaction) nie rejestrują treści żądania POST dla zapytań /api/now/sp/search. Obrońcy mogą zobaczyć, że zautomatyzowane wyszukiwania miały miejsce i ile danych zostało zwróconych (poprzez kolumnę długości wyjścia), ale nie mogą określić dokładnych terminów wyszukiwania ani które konkretne rekordy zostały pobrane.

W przypadku Salesforce: Ruch związany z wyliczaniem gości składa się z legalnych, zgodnych z protokołem wywołań API, które wyglądają jak normalny ruch na stronie. Chociaż Event Monitoring może pokazać wolumen zdarzeń AuraRequest i Sites od użytkowników-gości, logi pokazują, że dane były żądane, ale nie konkretną treść tego, co zostało zwrócone w odpowiedziach GraphQL lub Aura.

Innymi słowy, możesz zobaczyć, że atakujący był obecny i ile danych pobrał, ale nie możesz odtworzyć dokładnie, które rekordy lub pola zostały wyodrębnione.

Zalecane kroki naprawcze

Dla Salesforce (zalecenia Reco):

1. Zaostrz reguły udostępniania gościom — pojedyncza kontrola o największym wpływie. Usuń wszelkie reguły udostępniania, które udostępniają rekordy użytkownikowi-gościowi poza tym, czego witryna naprawdę potrzebuje do publicznej obsługi.
2. Usuń uprawnienia na poziomie obiektu i pola z profilu gościa. Usuń dostęp do odczytu do obiektów, których witryna nie potrzebuje dla anonimowych odwiedzających.
3. Usuń uprawnienie „Access Activities” z profilu gościa (ujawnia zadania i zdarzenia).
4. Wyłącz „API Enabled” dla użytkownika-gościa.
5. Wyłącz samorejestrację, chyba że witryna naprawdę tego wymaga.
6. Wyłącz dostęp gościa do plików i widoczność członków, aby goście nie mogli pobierać plików ContentDocument ani wyliczać innych członków witryny.
7. Tylko dla witryn LWR: W Experience Builder → Workspaces → Administracja → Preferencje, odznacz „Allow guest users to access public APIs.” To zamyka GraphQL i REST endpointy UI-API jednym ruchem.

Dla ServiceNow (zalecenia Reco):

1. Zmapuj portale gościnne do ich źródeł wyszukiwania. Sprawdź tabele sp_portal, m2m_sp_portal_search_source i sp_search_source. Odłącz źródło wyszukiwania, którego publiczny portal nie potrzebuje.
2. Przejrzyj logikę każdego źródła wyszukiwania — zwłaszcza is_scripted_source, data_fetch_script i to, czy używa GlideRecordSecure (egzekwującego ACL) vs. zwykłego GlideRecord (który nie egzekwuje).
3. Przejrzyj kryteria użytkownika bazy wiedzy „Can Read” — szukaj nieograniczonego dostępu „Any User”, który ujawnia wrażliwe bazy wiedzy przez wyszukiwanie gościa.
4. Odłącz złe linki kb_uc_can_read_mtom zamiast ślepo edytować reguły udostępniania.

Wskazówki dotyczące wykrywania:

• Salesforce Event Monitoring: Szukaj dużej liczby getItems i getConfigData z USER_TYPE = 'Guest', przeszukiwania wersji /webruntime/.../vNN.0/graphql oraz trafień na /SiteRegister i /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Szukaj żądań /api/now/sp/search wykonanych jako gość. Sortuj według długości wyniku — wiersze zwracające znacznie więcej niż małą bazową wartość pustego wyniku wskazują na wyszukiwania, które zwróciły treść.

Firma bezpieczeństwa Reco nazwała tę kampanię City-Forum — od domeny city-forum.com powiązanej z infrastrukturą atakującego. Od co najmniej marca 2025 roku pojedynczy wynajęty serwer w Niemczech systematycznie zbiera dane od operatorów telekomunikacyjnych, banków, firm finansowych, dostawców oprogramowania korporacyjnego oraz portali sektora publicznego.

Jak działa exploit: bez podatności

Zarówno Salesforce, jak i ServiceNow mają wbudowane, stałe konta gościnne dla nieuwierzytelnionych odwiedzających. Tych kont nie można usunąć. Ich uprawnienia — jakie rekordy i obiekty mogą odczytywać — są konfigurowane przez każdą organizację. Jeśli profil gościa ma dostęp do odczytu do rekordu, każda osoba w Internecie może go pobrać za pomocą w pełni legalnych endpointów API.

W Salesforce (framework Aura):

• Narzędzie wysyła żądania POST do endpointu /aura lub /s/sfsites/aura.
• Najpierw wywołuje HostConfigController.getConfigData, aby wymienić obiekty (Konto, Kontakt, Sprawa, Lead, Użytkownik, ContentDocument itp.), do których gość ma dostęp.
• Następnie używa SelectableListDataProviderController.getItems do przewijania wszystkich rekordów w każdym dostępnym obiekcie.
• Najbardziej obciążony pojedynczy cel zarejestrował ponad 560 000 zdarzeń z adresu IP atakującego, prawie wyłącznie związanych z wyliczaniem Aura.

W Salesforce (framework LWR — Lightning Web Runtime):

• Jest to pierwsze zaobserwowane w środowisku produkcyjnym wykorzystanie powierzchni gościnnej UI-API Salesforce w witrynach LWR.
• Narzędzie celuje w endpoint GraphQL pod adresem POST /webruntime/api/services/data/{version}/graphql?asGuest=true, najpierw wyliczając schemat za pomocą EntityDefinition, a następnie odczytując rekordy z paginacją opartą na kursorach.
• Przeszukuje wersje API od v56.0 do v66.0 po kolei dla każdej odkrytej witryny LWR.

W ServiceNow:

• Narzędzie celuje w endpoint /api/now/sp/search — natywne API wyszukiwania Service Portal, które jest w dużej mierze nieudokumentowane i ma prawie zero dokumentacji online lub narzędzi open-source, które by się do niego odwoływały.
• Ten endpoint jest z założenia publiczny. To, jakie dane zwraca, zależy wyłącznie od tego, które źródła wyszukiwania są podłączone do portalu gościnnego i czy te źródła egzekwują kontrolę dostępu.

Próby samorejestracji (Salesforce):

• Narzędzie dodaje /SiteRegister i /CommunitiesSelfReg do każdej odkrytej ścieżki witryny experience, aby sprawdzić, czy samorejestracja jest włączona. Jeśli tak, gość może awansować do uwierzytelnionego użytkownika zewnętrznego, zyskując dostęp do znacznie większej ilości danych.

Niestandardowe narzędzia i infrastruktura

• Źródłowy adres IP: 158.220.87.79, hostowany na VPS Contabo (niemiecki dostawca), rozwiązywany do domeny city-forum.com (zarejestrowanej w 2002 r., porzuconej, a następnie ponownie wykorzystanej).
• Ten sam adres IP jest powiązany z tą samą domeną od marca 2025 roku bez rotacji — co najmniej 17 miesięcy na jednym adresie.
• Niestandardowa binarka Go: Pojedyncze narzędzie skompilowane w Go, które atakuje Salesforce zarówno przez Aura, jak i LWR, a także ServiceNow — wszystko z tego samego serwera. To niestandardowy, wieloplatformowy zestaw narzędzi, a nie gotowe narzędzie, takie jak AuraInspector.
• Narzędzie używa domyślnego ciągu Go Go-http-client jako User-Agent, co ułatwia jego identyfikację w logach.

Organizacje będące celem

Reco podaje, że główne cele to:

• Operatorzy telekomunikacyjni
• Banki i firmy usług finansowych
• Dostawcy oprogramowania korporacyjnego (w tym firmy zajmujące się bezpieczeństwem i ochroną danych)
• Portale sektora publicznego

Dlaczego standardowe logi audytowe nie ujawniają, jakie dane zostały skradzione

W przypadku ServiceNow: Logi transakcyjne platformy (syslog_transaction) nie rejestrują treści żądania POST dla zapytań /api/now/sp/search. Obrońcy mogą zobaczyć, że zautomatyzowane wyszukiwania miały miejsce i ile danych zostało zwróconych (poprzez kolumnę długości wyjścia), ale nie mogą określić dokładnych terminów wyszukiwania ani które konkretne rekordy zostały pobrane.

W przypadku Salesforce: Ruch związany z wyliczaniem gości składa się z legalnych, zgodnych z protokołem wywołań API, które wyglądają jak normalny ruch na stronie. Chociaż Event Monitoring może pokazać wolumen zdarzeń AuraRequest i Sites od użytkowników-gości, logi pokazują, że dane były żądane, ale nie konkretną treść tego, co zostało zwrócone w odpowiedziach GraphQL lub Aura.

Innymi słowy, możesz zobaczyć, że atakujący był obecny i ile danych pobrał, ale nie możesz odtworzyć dokładnie, które rekordy lub pola zostały wyodrębnione.

Zalecane kroki naprawcze

Dla Salesforce (zalecenia Reco):

1. Zaostrz reguły udostępniania gościom — pojedyncza kontrola o największym wpływie. Usuń wszelkie reguły udostępniania, które udostępniają rekordy użytkownikowi-gościowi poza tym, czego witryna naprawdę potrzebuje do publicznej obsługi.
2. Usuń uprawnienia na poziomie obiektu i pola z profilu gościa. Usuń dostęp do odczytu do obiektów, których witryna nie potrzebuje dla anonimowych odwiedzających.
3. Usuń uprawnienie „Access Activities” z profilu gościa (ujawnia zadania i zdarzenia).
4. Wyłącz „API Enabled” dla użytkownika-gościa.
5. Wyłącz samorejestrację, chyba że witryna naprawdę tego wymaga.
6. Wyłącz dostęp gościa do plików i widoczność członków, aby goście nie mogli pobierać plików ContentDocument ani wyliczać innych członków witryny.
7. Tylko dla witryn LWR: W Experience Builder → Workspaces → Administracja → Preferencje, odznacz „Allow guest users to access public APIs.” To zamyka GraphQL i REST endpointy UI-API jednym ruchem.

Dla ServiceNow (zalecenia Reco):

1. Zmapuj portale gościnne do ich źródeł wyszukiwania. Sprawdź tabele sp_portal, m2m_sp_portal_search_source i sp_search_source. Odłącz źródło wyszukiwania, którego publiczny portal nie potrzebuje.
2. Przejrzyj logikę każdego źródła wyszukiwania — zwłaszcza is_scripted_source, data_fetch_script i to, czy używa GlideRecordSecure (egzekwującego ACL) vs. zwykłego GlideRecord (który nie egzekwuje).
3. Przejrzyj kryteria użytkownika bazy wiedzy „Can Read” — szukaj nieograniczonego dostępu „Any User”, który ujawnia wrażliwe bazy wiedzy przez wyszukiwanie gościa.
4. Odłącz złe linki kb_uc_can_read_mtom zamiast ślepo edytować reguły udostępniania.

Wskazówki dotyczące wykrywania:

• Salesforce Event Monitoring: Szukaj dużej liczby getItems i getConfigData z USER_TYPE = 'Guest', przeszukiwania wersji /webruntime/.../vNN.0/graphql oraz trafień na /SiteRegister i /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Szukaj żądań /api/now/sp/search wykonanych jako gość. Sortuj według długości wyniku — wiersze zwracające znacznie więcej niż małą bazową wartość pustego wyniku wskazują na wyszukiwania, które zwróciły treść.