บริษัทรักษาความปลอดภัย Reco ตั้งชื่อแคมเปญนี้ว่า City-Forum ตามชื่อโดเมน city-forum.com ซึ่งเชื่อมโยงกับโครงสร้างพื้นฐานของผู้โจมตี นับตั้งแต่อย่างน้อยเดือนมีนาคมปี 2025 เซิร์ฟเวอร์เช่าเพียงเครื่องเดียวในเยอรมนีกำลังเก็บข้อมูลจากผู้ให้บริการโทรคมนาคม ธนาคาร บริษัทบริการทางการเงิน ผู้จำหน่ายซอฟต์แวร์องค์กร และพอร์ทัลภาครัฐอย่างเป็นระบบ

วิธีการทำงาน: ไม่ต้องมีช่องโหว่

ทั้ง Salesforce และ ServiceNow มีบัญชี ผู้เยี่ยมชม (Guest User) ถาวรสำหรับผู้ใช้ที่ไม่ต้องเข้าสู่ระบบ บัญชีนี้ไม่สามารถลบได้ สิทธิ์ในการเข้าถึงข้อมูลถูกกำหนดโดยแต่ละองค์กร หากโปรไฟล์ผู้เยี่ยมชมมีสิทธิ์อ่านบันทึกใดๆ บุคคลใดบนอินเทอร์เน็ตก็สามารถดึงข้อมูลนั้นผ่าน API ที่ถูกต้องตามกฎหมายได้

บน Salesforce (เฟรมเวิร์ก Aura):

• เครื่องมือจะส่งคำขอ POST ไปยัง /aura หรือ /s/sfsites/aura
• ขั้นแรก มันเรียก HostConfigController.getConfigData เพื่อดูว่าออบเจ็กต์ใดบ้าง (Account, Contact, Case, Lead, User, ContentDocument ฯลฯ) ที่ผู้เยี่ยมชมเข้าถึงได้
• จากนั้นใช้ SelectableListDataProviderController.getItems เพื่อเรียกดูบันทึกทั้งหมดในแต่ละออบเจ็กต์
• เป้าหมายที่มีการโจมตีหนักที่สุดถูกบันทึกไว้มากกว่า 560,000 อีเวนต์ จาก IP ของผู้โจมตี ซึ่งเกือบทั้งหมดเป็นการแจกแจง Aura ของผู้เยี่ยมชม

บน Salesforce (เฟรมเวิร์ก LWR - Lightning Web Runtime):

• นี่เป็นครั้งแรกที่มีการพบเห็นการโจมตี ในโลกจริง ที่ใช้ประโยชน์จาก UI-API ของ Salesforce บนเว็บไซต์ LWR
• เครื่องมือจะกำหนดเป้าหมายไปที่ GraphQL endpoint ที่ POST /webruntime/api/services/data/{version}/graphql?asGuest=true โดยเริ่มจากการแจกแจง Schema ผ่าน EntityDefinition จากนั้นอ่านบันทึกด้วยการแบ่งหน้าแบบ Cursor
• มันจะสแกน API เวอร์ชัน v56.0 ถึง v66.0 ตามลำดับในทุกเว็บไซต์ LWR ที่พบ

บน ServiceNow:

• เครื่องมือโจมตีที่ /api/now/sp/search ซึ่งเป็น API ค้นหาของ Service Portal ที่ แทบไม่มีเอกสารอ้างอิง และไม่มีเครื่องมือโอเพนซอร์สใดๆ กล่าวถึง
• โดยค่าเริ่มต้น endpoint นี้ถูกออกแบบให้เป็นสาธารณะ ข้อมูลที่ส่งคืนขึ้นอยู่กับว่าแหล่งค้นหาใดถูกแนบกับพอร์ทัลที่ผู้เยี่ยมชมเข้าถึงได้ และแหล่งเหล่านั้นบังคับใช้การควบคุมการเข้าถึงหรือไม่

การทดสอบการสมัครสมาชิกด้วยตนเอง (Salesforce):

• เครื่องมือจะต่อท้าย /SiteRegister และ /CommunitiesSelfReg กับทุกเส้นทางของเว็บไซต์ที่พบเพื่อทดสอบว่าฟังก์ชันการสมัครด้วยตนเองเปิดใช้งานอยู่หรือไม่ หากเปิดใช้งาน ผู้เยี่ยมชมสามารถเลื่อนสถานะเป็นผู้ใช้ภายนอกที่ผ่านการรับรองความถูกต้อง ทำให้เข้าถึงข้อมูลได้มากขึ้น

เครื่องมือและโครงสร้างพื้นฐาน

• IP ต้นทาง: 158.220.87.79 โฮสต์บน Contabo VPS (ผู้ให้บริการโฮสต์ในเยอรมนี) แก้ไขไปยังโดเมน city-forum.com (โดเมนที่จดทะเบียนในปี 2002 ถูกทิ้งร้างแล้วนำกลับมาใช้ใหม่)
• IP เดียวกันนี้ใช้โดเมนเดียวกันตั้งแต่ มีนาคม 2025 โดยไม่มีการเปลี่ยน นานอย่างน้อย 17 เดือนในที่อยู่เดียว
• Go binary ที่กำหนดเอง: เครื่องมือที่คอมไพล์ด้วยภาษา Go เพียงตัวเดียวที่โจมตี Salesforce ทั้งเฟรมเวิร์ก Aura และ LWR และยังโจมตี ServiceNow จากเซิร์ฟเวอร์เดียวกัน นี่คือชุดเครื่องมือข้ามแพลตฟอร์มที่กำหนดเอง ไม่ใช่เครื่องมือสำเร็จรูปเช่น AuraInspector
• เครื่องมือใช้ User-Agent Go-http-client ปริยายของ Go ทำให้ระบุได้ง่ายในบันทึก

องค์กรที่ตกเป็นเป้าหมาย

Reco รายงานว่าเป้าหมายหลัก ได้แก่

• ผู้ให้บริการโทรคมนาคม
• ธนาคารและบริษัทบริการทางการเงิน
• ผู้จำหน่ายซอฟต์แวร์องค์กร (รวมถึงบริษัทรักษาความปลอดภัยและข้อมูลส่วนบุคคล)
• พอร์ทัลภาครัฐ

เหตุใดบันทึกตรวจสอบมาตรฐานจึงไม่สามารถบอกได้ว่าข้อมูลใดถูกขโมย

สำหรับ ServiceNow: บันทึกธุรกรรมของแพลตฟอร์ม (syslog_transaction) ไม่บันทึกเนื้อหาคำขอ POST ของ /api/now/sp/search ผู้ป้องกันสามารถเห็นว่ามีการค้นหาอัตโนมัติเกิดขึ้นและมีข้อมูลถูกส่งคืนมากน้อยเพียงใด แต่ ไม่สามารถระบุคำค้นหาที่แน่นอนหรือบันทึกเฉพาะที่ถูกเรียกดู

สำหรับ Salesforce: การรับส่งข้อมูลของผู้เยี่ยมชมประกอบด้วยการเรียก API ที่ถูกต้องและเป็นไปตามโปรโตคอล ซึ่งดูเหมือนการรับส่งข้อมูลปกติ แม้ว่า Event Monitoring จะแสดงปริมาณของอีเวนต์ AuraRequest และ Sites จากผู้เยี่ยมชมได้ แต่บันทึกจะแสดงเฉพาะว่ามีการร้องขอข้อมูล แต่ไม่สามารถระบุ เนื้อหาเฉพาะ ที่ส่งคืนในการตอบสนองของ GraphQL หรือ Aura

กล่าวคือ คุณเห็นว่ามีผู้โจมตีอยู่ในระบบและดึงข้อมูลไปเท่าไร แต่ไม่สามารถสร้างใหม่ได้ว่าบันทึกหรือฟิลด์ใดถูกขโมยไป

ขั้นตอนการแก้ไขที่แนะนำ

สำหรับ Salesforce (คำแนะนำจาก Reco):

1. ปรับกฎการแชร์ข้อมูลสำหรับผู้เยี่ยมชมให้รัดกุมขึ้น — นี่คือการควบคุมที่มีผลกระทบสูงที่สุด ลบกฎการแชร์ที่แชร์บันทึกกับบัญชีผู้เยี่ยมชมเกินกว่าที่เว็บไซต์จำเป็นต้องให้บริการสาธารณะ
2. ลบสิทธิ์ระดับออบเจ็กต์และฟิลด์ ออกจากโปรไฟล์ผู้เยี่ยมชม ลบสิทธิ์การอ่านในออบเจ็กต์ที่เว็บไซต์ไม่ต้องการให้ผู้เยี่ยมชมไม่ระบุตัวตนเข้าถึง
3. ลบสิทธิ์ "Access Activities" ออกจากโปรไฟล์ผู้เยี่ยมชม (ทำให้ Tasks และ Events ถูกเปิดเผย)
4. ปิด "API Enabled" ในบัญชีผู้เยี่ยมชม
5. ปิดการสมัครสมาชิกด้วยตนเอง เว้นแต่เว็บไซต์จำเป็นจริงๆ
6. ปิดการเข้าถึงไฟล์และการมองเห็นสมาชิกของผู้เยี่ยมชม เพื่อป้องกันไม่ให้ผู้เยี่ยมชมเรียกดูไฟล์ ContentDocument หรือแจกแจงสมาชิกคนอื่นๆ
7. สำหรับเว็บไซต์ LWR เท่านั้น: ใน Experience Builder → Workspaces → Administration → Preferences ยกเลิกการเลือก "Allow guest users to access public APIs" การดำเนินการนี้จะปิด GraphQL และ REST endpoints ของ UI-API ในครั้งเดียว

สำหรับ ServiceNow (คำแนะนำจาก Reco):

1. จับคู่พอร์ทัลที่ผู้เยี่ยมชมเข้าถึงได้กับแหล่งค้นหา ตรวจสอบตาราง sp_portal, m2m_sp_portal_search_source และ sp_search_source ถอดแหล่งค้นหาที่พอร์ทัลสาธารณะไม่จำเป็นต้องใช้ออก
2. ตรวจสอบตรรกะของแต่ละแหล่งค้นหา โดยเฉพาะ is_scripted_source, data_fetch_script และว่าใช้ GlideRecordSecure (บังคับใช้ ACL) หรือ GlideRecord (ไม่บังคับใช้) ธรรมดา
3. ตรวจสอบเกณฑ์ผู้ใช้ "Can Read" ของฐานความรู้ — ดูการเข้าถึง "ผู้ใช้ใดก็ได้" (Any User) ที่ไม่มีการจำกัด ซึ่งอาจเปิดเผยฐานความรู้ที่ละเอียดอ่อนผ่านการค้นหาของผู้เยี่ยมชม
4. ถอดลิงก์ kb_uc_can_read_mtom ที่ไม่เหมาะสม แทนที่จะแก้ไขกฎการแชร์อย่างไม่รอบคอบ

คำแนะนำในการตรวจจับ:

• Salesforce Event Monitoring: มองหาปริมาณ getItems และ getConfigData สูงจาก USER_TYPE = 'Guest', การสแกนเวอร์ชัน /webruntime/.../vNN.0/graphql และการเข้าถึง /SiteRegister และ /CommunitiesSelfReg
• ServiceNow syslog_transaction: มองหาคำขอ /api/now/sp/search ที่มาจากผู้เยี่ยมชม จัดเรียงตามความยาวของผลลัพธ์ (output length) แถวที่ส่งคืนข้อมูลมากกว่าเกณฑ์พื้นฐานปกติของผลลัพธ์ว่างเปล่า บ่งชี้ถึงการค้นหาที่พบข้อมูล

บริษัทรักษาความปลอดภัย Reco ตั้งชื่อแคมเปญนี้ว่า City-Forum ตามชื่อโดเมน city-forum.com ซึ่งเชื่อมโยงกับโครงสร้างพื้นฐานของผู้โจมตี นับตั้งแต่อย่างน้อยเดือนมีนาคมปี 2025 เซิร์ฟเวอร์เช่าเพียงเครื่องเดียวในเยอรมนีกำลังเก็บข้อมูลจากผู้ให้บริการโทรคมนาคม ธนาคาร บริษัทบริการทางการเงิน ผู้จำหน่ายซอฟต์แวร์องค์กร และพอร์ทัลภาครัฐอย่างเป็นระบบ

วิธีการทำงาน: ไม่ต้องมีช่องโหว่

ทั้ง Salesforce และ ServiceNow มีบัญชี ผู้เยี่ยมชม (Guest User) ถาวรสำหรับผู้ใช้ที่ไม่ต้องเข้าสู่ระบบ บัญชีนี้ไม่สามารถลบได้ สิทธิ์ในการเข้าถึงข้อมูลถูกกำหนดโดยแต่ละองค์กร หากโปรไฟล์ผู้เยี่ยมชมมีสิทธิ์อ่านบันทึกใดๆ บุคคลใดบนอินเทอร์เน็ตก็สามารถดึงข้อมูลนั้นผ่าน API ที่ถูกต้องตามกฎหมายได้

บน Salesforce (เฟรมเวิร์ก Aura):

• เครื่องมือจะส่งคำขอ POST ไปยัง /aura หรือ /s/sfsites/aura
• ขั้นแรก มันเรียก HostConfigController.getConfigData เพื่อดูว่าออบเจ็กต์ใดบ้าง (Account, Contact, Case, Lead, User, ContentDocument ฯลฯ) ที่ผู้เยี่ยมชมเข้าถึงได้
• จากนั้นใช้ SelectableListDataProviderController.getItems เพื่อเรียกดูบันทึกทั้งหมดในแต่ละออบเจ็กต์
• เป้าหมายที่มีการโจมตีหนักที่สุดถูกบันทึกไว้มากกว่า 560,000 อีเวนต์ จาก IP ของผู้โจมตี ซึ่งเกือบทั้งหมดเป็นการแจกแจง Aura ของผู้เยี่ยมชม

บน Salesforce (เฟรมเวิร์ก LWR - Lightning Web Runtime):

• นี่เป็นครั้งแรกที่มีการพบเห็นการโจมตี ในโลกจริง ที่ใช้ประโยชน์จาก UI-API ของ Salesforce บนเว็บไซต์ LWR
• เครื่องมือจะกำหนดเป้าหมายไปที่ GraphQL endpoint ที่ POST /webruntime/api/services/data/{version}/graphql?asGuest=true โดยเริ่มจากการแจกแจง Schema ผ่าน EntityDefinition จากนั้นอ่านบันทึกด้วยการแบ่งหน้าแบบ Cursor
• มันจะสแกน API เวอร์ชัน v56.0 ถึง v66.0 ตามลำดับในทุกเว็บไซต์ LWR ที่พบ

บน ServiceNow:

• เครื่องมือโจมตีที่ /api/now/sp/search ซึ่งเป็น API ค้นหาของ Service Portal ที่ แทบไม่มีเอกสารอ้างอิง และไม่มีเครื่องมือโอเพนซอร์สใดๆ กล่าวถึง
• โดยค่าเริ่มต้น endpoint นี้ถูกออกแบบให้เป็นสาธารณะ ข้อมูลที่ส่งคืนขึ้นอยู่กับว่าแหล่งค้นหาใดถูกแนบกับพอร์ทัลที่ผู้เยี่ยมชมเข้าถึงได้ และแหล่งเหล่านั้นบังคับใช้การควบคุมการเข้าถึงหรือไม่

การทดสอบการสมัครสมาชิกด้วยตนเอง (Salesforce):

• เครื่องมือจะต่อท้าย /SiteRegister และ /CommunitiesSelfReg กับทุกเส้นทางของเว็บไซต์ที่พบเพื่อทดสอบว่าฟังก์ชันการสมัครด้วยตนเองเปิดใช้งานอยู่หรือไม่ หากเปิดใช้งาน ผู้เยี่ยมชมสามารถเลื่อนสถานะเป็นผู้ใช้ภายนอกที่ผ่านการรับรองความถูกต้อง ทำให้เข้าถึงข้อมูลได้มากขึ้น

เครื่องมือและโครงสร้างพื้นฐาน

• IP ต้นทาง: 158.220.87.79 โฮสต์บน Contabo VPS (ผู้ให้บริการโฮสต์ในเยอรมนี) แก้ไขไปยังโดเมน city-forum.com (โดเมนที่จดทะเบียนในปี 2002 ถูกทิ้งร้างแล้วนำกลับมาใช้ใหม่)
• IP เดียวกันนี้ใช้โดเมนเดียวกันตั้งแต่ มีนาคม 2025 โดยไม่มีการเปลี่ยน นานอย่างน้อย 17 เดือนในที่อยู่เดียว
• Go binary ที่กำหนดเอง: เครื่องมือที่คอมไพล์ด้วยภาษา Go เพียงตัวเดียวที่โจมตี Salesforce ทั้งเฟรมเวิร์ก Aura และ LWR และยังโจมตี ServiceNow จากเซิร์ฟเวอร์เดียวกัน นี่คือชุดเครื่องมือข้ามแพลตฟอร์มที่กำหนดเอง ไม่ใช่เครื่องมือสำเร็จรูปเช่น AuraInspector
• เครื่องมือใช้ User-Agent Go-http-client ปริยายของ Go ทำให้ระบุได้ง่ายในบันทึก

องค์กรที่ตกเป็นเป้าหมาย

Reco รายงานว่าเป้าหมายหลัก ได้แก่

• ผู้ให้บริการโทรคมนาคม
• ธนาคารและบริษัทบริการทางการเงิน
• ผู้จำหน่ายซอฟต์แวร์องค์กร (รวมถึงบริษัทรักษาความปลอดภัยและข้อมูลส่วนบุคคล)
• พอร์ทัลภาครัฐ

เหตุใดบันทึกตรวจสอบมาตรฐานจึงไม่สามารถบอกได้ว่าข้อมูลใดถูกขโมย

สำหรับ ServiceNow: บันทึกธุรกรรมของแพลตฟอร์ม (syslog_transaction) ไม่บันทึกเนื้อหาคำขอ POST ของ /api/now/sp/search ผู้ป้องกันสามารถเห็นว่ามีการค้นหาอัตโนมัติเกิดขึ้นและมีข้อมูลถูกส่งคืนมากน้อยเพียงใด แต่ ไม่สามารถระบุคำค้นหาที่แน่นอนหรือบันทึกเฉพาะที่ถูกเรียกดู

สำหรับ Salesforce: การรับส่งข้อมูลของผู้เยี่ยมชมประกอบด้วยการเรียก API ที่ถูกต้องและเป็นไปตามโปรโตคอล ซึ่งดูเหมือนการรับส่งข้อมูลปกติ แม้ว่า Event Monitoring จะแสดงปริมาณของอีเวนต์ AuraRequest และ Sites จากผู้เยี่ยมชมได้ แต่บันทึกจะแสดงเฉพาะว่ามีการร้องขอข้อมูล แต่ไม่สามารถระบุ เนื้อหาเฉพาะ ที่ส่งคืนในการตอบสนองของ GraphQL หรือ Aura

กล่าวคือ คุณเห็นว่ามีผู้โจมตีอยู่ในระบบและดึงข้อมูลไปเท่าไร แต่ไม่สามารถสร้างใหม่ได้ว่าบันทึกหรือฟิลด์ใดถูกขโมยไป

ขั้นตอนการแก้ไขที่แนะนำ

สำหรับ Salesforce (คำแนะนำจาก Reco):

1. ปรับกฎการแชร์ข้อมูลสำหรับผู้เยี่ยมชมให้รัดกุมขึ้น — นี่คือการควบคุมที่มีผลกระทบสูงที่สุด ลบกฎการแชร์ที่แชร์บันทึกกับบัญชีผู้เยี่ยมชมเกินกว่าที่เว็บไซต์จำเป็นต้องให้บริการสาธารณะ
2. ลบสิทธิ์ระดับออบเจ็กต์และฟิลด์ ออกจากโปรไฟล์ผู้เยี่ยมชม ลบสิทธิ์การอ่านในออบเจ็กต์ที่เว็บไซต์ไม่ต้องการให้ผู้เยี่ยมชมไม่ระบุตัวตนเข้าถึง
3. ลบสิทธิ์ "Access Activities" ออกจากโปรไฟล์ผู้เยี่ยมชม (ทำให้ Tasks และ Events ถูกเปิดเผย)
4. ปิด "API Enabled" ในบัญชีผู้เยี่ยมชม
5. ปิดการสมัครสมาชิกด้วยตนเอง เว้นแต่เว็บไซต์จำเป็นจริงๆ
6. ปิดการเข้าถึงไฟล์และการมองเห็นสมาชิกของผู้เยี่ยมชม เพื่อป้องกันไม่ให้ผู้เยี่ยมชมเรียกดูไฟล์ ContentDocument หรือแจกแจงสมาชิกคนอื่นๆ
7. สำหรับเว็บไซต์ LWR เท่านั้น: ใน Experience Builder → Workspaces → Administration → Preferences ยกเลิกการเลือก "Allow guest users to access public APIs" การดำเนินการนี้จะปิด GraphQL และ REST endpoints ของ UI-API ในครั้งเดียว

สำหรับ ServiceNow (คำแนะนำจาก Reco):

1. จับคู่พอร์ทัลที่ผู้เยี่ยมชมเข้าถึงได้กับแหล่งค้นหา ตรวจสอบตาราง sp_portal, m2m_sp_portal_search_source และ sp_search_source ถอดแหล่งค้นหาที่พอร์ทัลสาธารณะไม่จำเป็นต้องใช้ออก
2. ตรวจสอบตรรกะของแต่ละแหล่งค้นหา โดยเฉพาะ is_scripted_source, data_fetch_script และว่าใช้ GlideRecordSecure (บังคับใช้ ACL) หรือ GlideRecord (ไม่บังคับใช้) ธรรมดา
3. ตรวจสอบเกณฑ์ผู้ใช้ "Can Read" ของฐานความรู้ — ดูการเข้าถึง "ผู้ใช้ใดก็ได้" (Any User) ที่ไม่มีการจำกัด ซึ่งอาจเปิดเผยฐานความรู้ที่ละเอียดอ่อนผ่านการค้นหาของผู้เยี่ยมชม
4. ถอดลิงก์ kb_uc_can_read_mtom ที่ไม่เหมาะสม แทนที่จะแก้ไขกฎการแชร์อย่างไม่รอบคอบ

คำแนะนำในการตรวจจับ:

• Salesforce Event Monitoring: มองหาปริมาณ getItems และ getConfigData สูงจาก USER_TYPE = 'Guest', การสแกนเวอร์ชัน /webruntime/.../vNN.0/graphql และการเข้าถึง /SiteRegister และ /CommunitiesSelfReg
• ServiceNow syslog_transaction: มองหาคำขอ /api/now/sp/search ที่มาจากผู้เยี่ยมชม จัดเรียงตามความยาวของผลลัพธ์ (output length) แถวที่ส่งคืนข้อมูลมากกว่าเกณฑ์พื้นฐานปกติของผลลัพธ์ว่างเปล่า บ่งชี้ถึงการค้นหาที่พบข้อมูล