แคมเปญ 'City-Forum' กวาดข้อมูลจากพอร์ทัล Salesforce และ ServiceNow — ไม่ได้เจาะช่องโหว่ แต่ดูดของที่องค์กรเผลอเปิดให้ผู้ใช้นิรนาม

สรุปสั้น

บริษัท Reco ผู้ให้บริการด้านความปลอดภัยของซอฟต์แวร์แบบบริการ (SaaS) เปิดเผยแคมเปญขโมยข้อมูลที่ยังดำเนินอยู่ ซึ่งใช้เครื่องมือที่พัฒนาขึ้นเองไล่ดูดข้อมูลที่ถูกเปิดให้ผู้ใช้นิรนามเข้าถึงได้ผ่านพอร์ทัลลูกค้าของ Salesforce Experience Cloud และ ServiceNow โดยตั้งชื่อแคมเปญนี้ว่า City-Forum ตามโดเมนที่ผูกกับเซิร์ฟเวอร์ต้นทาง จุดที่ทำให้แคมเปญนี้ตามรอยได้ง่ายผิดปกติคือ การโจมตีทั้งหมดมาจากที่อยู่ไอพีเดียวคือ 158.220.87[.]79 ซึ่งโฮสต์อยู่กับผู้ให้บริการ VPS สัญชาติเยอรมันชื่อ Contabo และเกือบทุกครั้งใช้ user agent ค่าเริ่มต้นของภาษา Go คือ Go-http-client/1.1 ตอนดาวน์โหลดข้อมูล

องค์กรที่ตกเป็นเป้าหมายกระจายอยู่ทั่วโลกและครอบคลุมหลายอุตสาหกรรม ทั้งบริษัทโทรคมนาคม ธนาคารและบริษัทบริการทางการเงิน ผู้ผลิตซอฟต์แวร์สำหรับองค์กร บริษัทด้านความปลอดภัยและความเป็นส่วนตัวของข้อมูล ไปจนถึงพอร์ทัลของหน่วยงานภาครัฐ โดย Reco ระบุว่าการโจมตียังดำเนินต่อเนื่องและปริมาณกำลังไต่สูงขึ้น องค์กรที่ถูกยิงหนักที่สุดเท่าที่บันทึกได้พบเหตุการณ์จากไอพีของผู้โจมตีมากกว่า 560,000 ครั้ง ซึ่งเกือบทั้งหมดเป็นการไล่แจกแจงข้อมูลผ่านบัญชีผู้เยี่ยมชมบนเฟรมเวิร์ก Aura ของ Salesforce

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

รายละเอียดข่าว

เว็บไซต์ BleepingComputer รายงานเมื่อวันที่ 12 สิงหาคม 2569 อ้างรายงานของ Reco ว่าแคมเปญ City-Forum ถูกตามรอยจนพบว่ามาจากเซิร์ฟเวอร์เครื่องเดียวที่ไล่โจมตีองค์กรหลายแห่งทั่วโลก โดยที่อยู่ไอพีดังกล่าวเชื่อมโยงกับโดเมน city-forum[.]com ซึ่งชี้มาที่เซิร์ฟเวอร์เครื่องนี้มาตั้งแต่อย่างน้อยเดือนมีนาคม 2568 บ่งชี้ว่าโครงสร้างพื้นฐานชุดนี้ถูกตั้งทิ้งไว้และใช้งานต่อเนื่องมานานกว่าหนึ่งปี

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

อีกจุดที่ต้องอ่านอย่างระมัดระวังคือความเชื่อมโยงกับกลุ่ม ShinyHunters การละเมิดบัญชีผู้เยี่ยมชมบน Salesforce ไม่ใช่เทคนิคใหม่ และเคยถูกใช้ในแคมเปญขโมยข้อมูลของ ShinyHunters มาก่อน โดยกลุ่มนั้นเคยใช้เครื่องมือ AuraInspector ฉบับดัดแปลงดูดระเบียนข้อมูลจากพอร์ทัล Experience Cloud ที่ตั้งค่าผิด แต่ Reco ระบุชัดว่าไม่มีหลักฐานเชื่อมโยงแคมเปญปัจจุบันเข้ากับกลุ่มดังกล่าว และยังชี้ข้อแตกต่างเชิงพฤติกรรมไว้ด้วยว่า แคมเปญของ ShinyHunters ในอดีตมักใช้หลายระบบและหลายที่อยู่ไอพี ขณะที่โครงสร้างพื้นฐานของ City-Forum อยู่บนไอพีเดิมมาตั้งแต่เดือนมีนาคม 2568

วิธีการโจมตี

บน Salesforce กิจกรรมส่วนใหญ่ที่สังเกตได้พุ่งเป้าไปที่เฟรมเวิร์ก Aura ซึ่งเป็นของรุ่นเก่า โดยผู้โจมตีส่ง request ไปยังปลายทาง /aura หรือ /s/sfsites/aura เพื่อดูว่าออบเจ็กต์ใดบ้างที่เปิดให้เข้าถึงแบบสาธารณะ เช่น Accounts, Contacts หรือ Cases จากนั้นจึงเรียก HostConfigController.getConfigData เพื่อไล่แจกแจงออบเจ็กต์ที่บัญชีผู้เยี่ยมชมเข้าถึงได้ แล้วตามด้วย SelectableListDataProviderController.getItems เพื่อดึงระเบียนข้อมูลออกจากออบเจ็กต์ที่เข้าถึงได้จริง

สิ่งที่ทำให้ City-Forum ต่างจากเครื่องมือที่มีอยู่คือ ผู้โจมตีไม่ได้หยุดอยู่แค่ปลายทางของ Aura แต่ยังเล่นงานเว็บไซต์ Salesforce ที่สร้างด้วยเฟรมเวิร์กรุ่นใหม่กว่าอย่าง Lightning Web Runtime (LWR) ด้วย โดยบนเว็บไซต์ LWR ผู้โจมตีใช้ UI API ของ Salesforce ดูดข้อมูลที่เปิดให้บัญชีผู้เยี่ยมชม ผ่านคำขอแบบ GraphQL ที่ส่งไปยัง /webruntime/api/services/data/{version}/graphql ซึ่ง Reco ระบุว่ายังไม่เคยเห็นเครื่องมือโจมตีสาธารณะตัวใดใช้เทคนิคนี้ และเครื่องมือที่มีอยู่อย่าง AuraInspector, S-RET และ CirrusGo ก็ไม่ได้ใช้อินเทอร์เฟซ webruntime นั่นหมายความว่าเครื่องมือที่ทีมความปลอดภัยใช้จำลองการโจมตีหรือใช้ตรวจสอบตัวเองอาจมองไม่เห็นเส้นทางนี้เลย

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

ในฝั่ง ServiceNow ผู้โจมตีรายเดียวกันเล่นงาน Service Portal ผ่านปลายทางที่มีมาให้ในตัวคือ POST /api/now/sp/search?sysparm_cancelable=true ซึ่ง Reco ระบุว่าไม่เคยเห็นถูกนำมาใช้ในการโจมตีมาก่อน ปลายทางนี้เป็นตัวที่ฟังก์ชันค้นหาของพอร์ทัลเรียกใช้ โดยรับคำขอแบบไม่ยืนยันตัวตนได้ และสามารถคืนข้อมูลกลับมาได้หากแหล่งค้นหา (search source) ถูกตั้งค่าให้ผู้เยี่ยมชมเข้าถึงได้ ผู้โจมตีจึงสลับคำค้นไปเรื่อย ๆ เพื่อไล่แจกแจงข้อมูลที่เปิดอยู่ โดยในสภาพแวดล้อมหนึ่งที่ตรวจสอบ คำขอเพิ่มขึ้นจากหลักสิบเป็นหลักร้อยครั้งต่อวัน

จุดที่เป็นปัญหาสำหรับฝ่ายป้องกันคือ ล็อกธุรกรรมของ ServiceNow ไม่บันทึกเนื้อหาส่วน body ของคำขอแบบ POST ทำให้ผู้ดูแลระบบเห็นได้เพียงว่ามีการค้นหาแบบอัตโนมัติเกิดขึ้นและมีข้อมูลถูกส่งกลับไปมากเท่าใด แต่ไม่สามารถระบุได้ว่าผู้โจมตีใช้คำค้นอะไรบ้าง ซึ่งแปลว่าการประเมินขอบเขตความเสียหายหลังเหตุการณ์จะทำได้ไม่ครบถ้วน

ผลกระทบ

ลักษณะของแคมเปญนี้ทำให้ความเสียหายขึ้นอยู่กับการตั้งค่าของแต่ละองค์กรล้วน ๆ ไม่ใช่ขึ้นกับเวอร์ชันของซอฟต์แวร์ องค์กรที่ตั้งค่าสิทธิ์ของบัญชีผู้เยี่ยมชมไว้แน่นหนาจะไม่เสียอะไรเลยแม้จะถูกยิงด้วยชุดคำขอเดียวกัน ขณะที่องค์กรที่เผลอเปิดออบเจ็กต์สำคัญไว้อาจสูญเสียรายชื่อลูกค้า ข้อมูลติดต่อ หรือเนื้อหาของเคสบริการทั้งชุด โดยไม่มีเหตุการณ์ใดในระบบที่ดูเหมือน “การถูกแฮ็ก” ให้จับสังเกตได้ เพราะทุกคำขอเป็นการเรียกใช้งานปกติของแพลตฟอร์มที่ตอบกลับตามสิทธิ์ที่ตั้งไว้จริง

ผลที่ตามมาในเชิงปฏิบัติคือ องค์กรจำนวนมากจะไม่รู้ตัวว่าถูกดูดข้อมูลไปแล้ว เพราะการเฝ้าระวังส่วนใหญ่ตั้งอยู่บนสมมติฐานว่าการรั่วไหลต้องมาพร้อมการยึดบัญชีหรือการใช้ช่องโหว่ ยิ่งไปกว่านั้น การที่ข้อมูลถูกดึงผ่านปลายทาง GraphQL ของ LWR ซึ่งเครื่องมือตรวจสอบสาธารณะยังไม่รองรับ ทำให้การตรวจสอบตัวเองด้วยเครื่องมือมาตรฐานอาจให้ผลว่า “ปลอดภัย” ทั้งที่ยังมีเส้นทางเปิดอยู่ ส่วนในฝั่ง ServiceNow ข้อจำกัดของล็อกที่ไม่เก็บ body ของคำขอ POST หมายความว่าองค์กรที่ถูกโจมตีจะประเมินได้เพียงปริมาณข้อมูลที่ไหลออก แต่ไม่รู้ว่าผู้โจมตีตั้งใจมองหาอะไร ซึ่งเป็นข้อมูลสำคัญต่อการประเมินว่าใครคือผู้โจมตีและจะกลับมาอีกหรือไม่

Indicators of Compromise (IoCs)

หมายเหตุ: ตัวบ่งชี้ด้านล่างผ่านการ defang แล้ว (ใส่วงเล็บคร่อมจุด) เพื่อป้องกันการคลิกโดยไม่ตั้งใจ

คำแนะนำ

ผู้ดูแลระบบ Salesforce ควรทบทวนกฎการแบ่งปันข้อมูลสำหรับผู้ใช้ระดับผู้เยี่ยมชมทั้งชุด ทั้งสิทธิ์ระดับออบเจ็กต์และระดับฟิลด์ สิทธิ์เข้าถึงไฟล์ การมองเห็นสมาชิก และการตั้งค่าสมัครสมาชิกด้วยตัวเอง สำหรับเว็บไซต์ที่สร้างด้วย LWR ทาง Reco แนะนำเพิ่มเติมให้ปิดตัวเลือกใน Experience Builder ที่อนุญาตให้ผู้ใช้ระดับผู้เยี่ยมชมเข้าถึง API สาธารณะ เมื่อไม่มีความจำเป็นต้องใช้ เพราะการปิดตัวเลือกนี้จะตัดการเข้าถึงปลายทาง API หลายเส้นทางที่ใช้ไล่แจกแจงและดูดข้อมูลได้ในคราวเดียว

ผู้ดูแลระบบ ServiceNow ควรตรวจสอบว่ามีแหล่งค้นหา (search source) ใดบ้างที่ถูกเปิดผ่าน Service Portal และต้องมั่นใจว่าแหล่งค้นหาที่เชื่อมกับข้อมูลอ่อนไหวถูกบังคับให้ยืนยันตัวตนและมีการควบคุมการเข้าถึงอย่างเข้มงวด เนื่องจากล็อกไม่เก็บคำค้นที่ใช้ การป้องกันจึงต้องทำที่ต้นทางคือการจำกัดว่าอะไรบ้างที่ค้นหาได้โดยไม่ล็อกอิน มากกว่าจะหวังพึ่งการตรวจย้อนหลัง

ในฝั่งการตรวจจับ ควรตั้งกฎเฝ้าระวังจากลายนิ้วมือที่เผยแพร่ไว้ในตารางด้านบน โดยเฉพาะการเรียกปลายทาง Aura และ GraphQL จำนวนมากจากต้นทางเดียว และ user agent ที่เป็นค่าเริ่มต้นของไลบรารีภาษาโปรแกรม ซึ่งแทบไม่ปรากฏในทราฟฟิกของผู้ใช้จริงที่มาจากเบราว์เซอร์ อย่างไรก็ตาม ไม่ควรยึดที่อยู่ไอพีเป็นมาตรการหลัก เพราะผู้โจมตีเปลี่ยนเซิร์ฟเวอร์ได้ทุกเมื่อ สิ่งที่ยั่งยืนกว่าคือการปิดข้อมูลที่ไม่ควรเปิดตั้งแต่แรก

แหล่งอ้างอิง

• BleepingComputer — “City-Forum” data-theft attacks target Salesforce, ServiceNow portals
• Reco — The City-Forum campaign targeting Salesforce and ServiceNow
• Salesforce Developers — Lightning Web Runtime (LWR) Overview