Reco zufolge lässt sich die Kampagne auf einen einzigen Server zurückverfolgen. Jede Anfrage von 158.220.87.79 trage denselben Fingerabdruck: den Standard-User-Agent der Go-Bibliothek net/http. Das deute darauf hin, dass das eingesetzte Werkzeug ein kompiliertes, eigens entwickeltes Programm ist und kein aus einem Browser gestartetes Tool. Passive DNS zeige zudem, dass dieselbe Domain bereits seit März 2025 auf diese IP-Adresse verwies; der Server sei seitdem nicht umgezogen.
Von früheren Fällen des Missbrauchs von Salesforce-Gastzugängen – einschließlich der vielfach berichteten Aktivitäten, die ShinyHunters zugeschrieben wurden – unterscheide sich die Kampagne laut Reco durch die Breite der angegriffenen Oberflächen. Viele bekannte Akteure in diesem Bereich setzen vor allem auf Salesforces älteres Aura-Framework, um mit einer hohen Zahl von Gastanfragen Objekte aufzuzählen und Datensätze seitenweise auszulesen. Auch dieser Akteur tue das. Aura mache weiterhin den Großteil des von Reco beobachteten Verkehrs aus; bei einem Ziel wurden demnach mehr als 560.000 Ereignisse von derselben IP protokolliert.
Die Infrastruktur greife jedoch zusätzlich auf neuere Lightning Web Runtime-Seiten von Salesforce über die UI-API zu. Reco beschreibt diese als Datenschicht, zu der es weder öffentliche technische Analysen noch bekannte Scan-Werkzeuge gebe. Das Werkzeug taste dabei nacheinander die API-Versionen v56.0 bis v66.0 ab. Darüber hinaus bearbeite derselbe Server intensiv einen nativen Suchendpunkt des ServiceNow Service Portal: POST /api/now/sp/search, für den es laut Reco kaum öffentliche Dokumentation gibt.
Der gemeinsame Nenner aller beobachteten Techniken sei eine zu weitreichend berechtigte Gastidentität. Sowohl Salesforce-Experience-Cloud-Seiten als auch ServiceNow-Portale arbeiteten mit einem dauerhaften Gastnutzer, unter dessen Identität nicht authentifizierte Besucher agieren. Dieser Nutzer lasse sich nicht löschen, sondern nur einschränken. Kann das Gastprofil einen Datensatz lesen, ist er laut Reco faktisch öffentlich.
Für die Erkennung nennt Reco konkrete Schritte. In Salesforce können Verteidiger mit Event Monitoring oder Shield die Protokollereignisse AuraRequest und Sites auswerten und nach dem User-Agent Go-http-client, der konkreten IP-Adresse sowie Anfragepfaden mit /webruntime/api/services/data suchen. Ebenfalls relevant seien Spitzen bei Selbstregistrierungsversuchen über /SiteRegister und /CommunitiesSelfReg. In ServiceNow lasse sich die Tabelle syslog_transaction nach der Quell-IP und nach URLs filtern, die mit /api/now/sp/search beginnen. Als deutlichstes Signal für ein laufendes massenhaftes Auslesen nennt Reco von Gastnutzern erzeugte Einträge und ungewöhnliche Ausgabelängen.
Bei der Abhilfe gehe es laut Reco nicht um die Endpunkte selbst, da sowohl die UI-API als auch der ServiceNow-Suchendpunkt wie vorgesehen funktionierten. In Salesforce sollten daher Gastfreigaberegeln überprüft, unnötige Zugriffe auf Objekte und Felder aus dem Gastprofil entfernt, die Selbstregistrierung deaktiviert werden, wo sie nicht benötigt wird, und die Experience-Builder-Einstellung abgeschaltet werden, die Gastnutzern den Zugriff auf öffentliche APIs erlaubt. In ServiceNow empfiehlt Reco, offengelegte Suchquellen in öffentlich erreichbaren Portalen zu kartieren und die Lesekriterien der Knowledge Base zu prüfen, die festlegen, was eine anonyme Suche tatsächlich zurückliefert.
Reco zufolge ist die hinter der Kampagne stehende Infrastruktur weiterhin aktiv, und das Volumen steigt. Eine Zuordnung zu einer konkret benannten Gruppe nimmt das Unternehmen nicht vor.