การละเมิด Salesloft Drift: การโจมตีการเคลื่อนไหวทางด้านข้างระหว่างผู้ขายที่ต้องใช้รูปแบบความปลอดภัยร่วมกันแบบใหม่

เหตุใดการโจมตี (B2)ⁿ นี้จึงเน้นย้ำถึงความจำเป็นของโมเดลความรับผิดชอบร่วมกันสำหรับการบูรณาการ SaaS และการระบุตัวตนที่ไม่ใช่มนุษย์
Silverfort ภาพ
ภาพเด่นจากบล็อก Salesloft โดย Roy - หัวข้อบล็อก

ในช่วงกลางเดือนสิงหาคม 2025 มีรายงานการละเมิด Salesloft Drift ซึ่งส่งผลกระทบต่อบริษัทยักษ์ใหญ่อย่าง Palo Alto Networks, Salesforce, Cloudflare และลูกค้าของพวกเขา ผู้โจมตีได้ขโมยและละเมิดโทเค็น OAuth หลายร้อยรายการเพื่อเข้าถึงสภาพแวดล้อม Salesforce และดึงข้อมูลสำคัญออกมา ซึ่งแสดงให้เห็นถึงผลกระทบทั้งที่พิสูจน์แล้วและที่อาจเกิดขึ้นในวงกว้าง 

เมื่ออ่านรายงานเหล่านี้แล้ว ฉันปฏิเสธที่จะจัดประเภทว่าเป็น "การโจมตีห่วงโซ่อุปทาน" อีกครั้ง แต่การโจมตีครั้งนี้แตกต่างออกไป  

มันเกี่ยวข้องกับ การขโมยข้อมูลประจำตัวที่ไม่ใช่มนุษย์ และการละเมิดความไว้วางใจ โดยมีการเคลื่อนไหวด้านข้าง TTP ที่ใช้สเตียรอยด์ หรือที่เรียกอีกอย่างว่าการเคลื่อนไหวด้านข้างแบบข้ามผู้ขาย  มันเป็นการโจมตีแบบธุรกิจต่อธุรกิจ หรือเรียกอีกอย่างว่าการโจมตีแบบธุรกิจต่อธุรกิจ (B2)ⁿ โจมตีห่วงโซ่แห่งความไว้วางใจที่ขาดสะบั้นนี้ทำให้เหยื่อของการโจมตีปกป้องตัวเองได้ยาก 

คิดเกี่ยวกับเรื่องนี้: โจมตี → ดริฟท์ → Salesloft → Salesforce → ลูกค้า → ลูกค้าของลูกค้า 

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

องค์กรขนาดใหญ่มีพันธมิตรและการบูรณาการหลายพันราย และไม่มีรูปแบบ "การบูรณาการที่ปลอดภัย" อย่างแท้จริง ห่วงโซ่การบูรณาการนี้ส่งผลให้เกิดความสัมพันธ์แบบ 1:1 แล้วเราจะป้องกัน ตรวจจับ หรือตอบสนองต่อการโจมตีประเภทนี้ได้รวดเร็วยิ่งขึ้น และได้รับการปกป้องจากผลกระทบแบบโดมิโนได้อย่างไร 
 
เห็นได้ชัดว่าสิ่งนี้ยังทำให้เกิดคำถามที่ใหญ่กว่า: เราจำเป็นต้องผลักดันเพื่อ รูปแบบความปลอดภัยที่ใช้ร่วมกันสำหรับผู้ให้บริการ SaaSไม่ใช่แค่สำหรับยักษ์ใหญ่ด้านโครงสร้างพื้นฐานคลาวด์อย่าง AWS, Microsoft และ Google Cloud เท่านั้น ใครบ้างที่เคยตัดสินใจคล้ายๆ กันนี้ในปี 2020? ในบทความนี้ ฉันจะอธิบายว่าปัญหาที่แท้จริงอยู่ที่ใด และผู้จำหน่ายและ CISO สามารถสร้างกรอบการทำงานสำหรับความรับผิดชอบร่วมกันที่คำนึงถึงการพึ่งพาทั้งหมดและลดภาระงานในที่สุดได้อย่างไร ความเสี่ยงในการเคลื่อนไหวด้านข้าง. 
 
ฟังดูน่าสนใจไหม? อ่านต่อได้เลย ถ้ามันมีประโยชน์ ฉันอยากฟังความคิดเห็นของคุณ 

รายละเอียดเพิ่มเติมของการละเมิด

จากแหล่งข้อมูลที่แตกต่างกัน (ดังที่ระบุไว้ด้านล่าง) ในเดือนสิงหาคม 2025 ผู้โจมตีที่ติดตาม UNC6395 ได้ขโมยโทเค็นรีเฟรช OAuth จากการผสานรวม Drift ของ Salesloft เข้ากับ Salesforce โทเค็นเหล่านี้ทำให้ Drift สามารถสืบค้นอินสแตนซ์ Salesforce ในนามของลูกค้ากว่า 700 ราย เมื่อเข้าไปแล้ว ผู้โจมตีได้ส่งออกข้อมูลติดต่อ บันทึกกรณี และแม้แต่คีย์ API ที่ฝังอยู่ในตั๋วหรือไฟล์แนบ 
 
บริษัทที่ได้รับผลกระทบรวมถึงบริษัทชั้นนำอย่าง Cloudflare, Proofpoint และ Palo Alto Networks Cloudflare เปิดเผยว่าโทเค็น API 104 รายการและข้อมูลกรณีที่ละเอียดอ่อนถูกบุกรุก Salesforce และ Salesloft ตอบโต้ด้วยการเพิกถอนโทเค็น Drift และลบแอปออกจาก AppExchange และลูกค้าปลายทางก็ปิดใช้งานการผสานรวมนี้เพื่อเป็นมาตรการตอบโต้ สำหรับบางรายก็สายเกินไปแล้ว เนื่องจากข้อมูลของพวกเขา รวมถึงความลับในการเข้าถึง ได้รั่วไหลไปแล้ว  
 
จากการวิเคราะห์เพิ่มเติมพบว่าผู้โจมตีสามารถเข้าถึงคลังข้อมูล GitHub ของ Salesloft ได้ ทำให้สามารถสืบหาได้ลึกขึ้นและอาจนำไปสู่การขโมยโทเค็น Google ยังรายงานถึงการละเมิดโทเค็น Drift Email OAuth ในสภาพแวดล้อม Google Workspace ในระดับจำกัด ยิ่งไปกว่านั้น ผู้โจมตียังค้นหาข้อมูลที่ถูกขโมยเพื่อหาคีย์ AWS, โทเค็น Snowflake และข้อมูลรับรองอื่นๆ ซึ่งยิ่งเพิ่มผลกระทบที่อาจเกิดขึ้นมากขึ้น 

แม้ว่าโพสต์และบทความจำนวนมากที่เผยแพร่ในช่วงไม่กี่สัปดาห์ที่ผ่านมาจะพูดถึงการโจมตีทางไซเบอร์ครั้งนี้ว่าเป็นการละเมิดข้อมูลแบบ “ดั้งเดิม” การใช้ประโยชน์จาก SaaS หรือแม้แต่การบุกรุกตัวแทน AI แต่เหตุการณ์นี้แตกต่างออกไป เป็นเพียงตัวอย่างที่ชัดเจนของ AMI ความซับซ้อน หรือพูดง่ายๆ ก็คือ ความยุ่งเหยิงของ IAM โดยสิ้นเชิง (ไม่ใช่แบบตาข่าย) ที่เราทุกคนกำลังเผชิญอยู่ในยุค SaaS, AI และการขยายตัวของอัตลักษณ์ที่ไม่ใช่มนุษย์ (NHI) แชทบอท Drift เป็นแอปพลิเคชันซอฟต์แวร์ที่ออกแบบมาเพื่อทำให้การสนทนาเป็นระบบอัตโนมัติ ดังนั้นจึงไม่ได้ทำงานอย่างอิสระหรือการตัดสินใจที่เป็นอิสระ แต่จะทำงานภายในเวิร์กโฟลว์และการผสานรวมที่กำหนดไว้ล่วงหน้า และ OAuth ที่ใช้สำหรับการผสานรวมนี้คือ NHI (ตัวตนที่ไม่ใช่มนุษย์). 

สิ่งที่เราเรียนรู้ได้

เราในฐานะลูกค้าไม่พร้อมที่จะปกป้องจาก (B2)ⁿ การโจมตีของ NHI

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

ความเสี่ยง B2B2B มีอยู่จริง และเราต้องการโมเดลความรับผิดชอบร่วมกัน

นี่ไม่ใช่แค่ Drift → Salesforce → ลูกค้า แต่มันคือ Drift → Salesforce → ข้อมูล SaaS ของลูกค้า → บริการคลาวด์ แต่ละฮอปทำให้รัศมีการโจมตีกว้างขึ้น ผู้ขายต้องรับผิดชอบต่อผู้ขายของผู้ขาย 

โทเค็นคือตัวตน – และควรได้รับการจัดการในลักษณะนั้น โดยไม่คำนึงถึงระยะห่างระหว่าง B2B

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

ความลับและข้อมูลประจำตัวของคุณยังอยู่ในข้อมูลด้วย ไม่ใช่แค่ของคุณเท่านั้น แต่รวมถึงของพันธมิตรของคุณด้วย

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

สวิตช์หยุดการทำงานแบบรวมศูนย์มีความสำคัญ

ความสามารถของ Salesforce ในการเพิกถอนโทเค็น Drift ได้ทั่วโลกช่วยควบคุมการแพร่กระจาย แพลตฟอร์มทั้งหมดควรมีความสามารถในการเปิดใช้งานการเพิกถอนฉุกเฉินได้ในระดับขนาดใหญ่

เกินกว่าห่วงโซ่อุปทาน: ความเข้าใจ (B2)ⁿ 

เราอาจมองว่านี่เป็นแค่การโจมตีห่วงโซ่อุปทานหรือความเสี่ยงจากบุคคลที่สาม แต่กรอบความคิดนี้กว้างเกินไปและซ่อนกลไกเฉพาะตัวเอาไว้ 
 
สิ่งที่เราเห็นที่นี่ใกล้เคียงกับการโจมตีแบบข้าม (B2)ⁿ ซึ่งเป็นรูปแบบหนึ่งของการเคลื่อนไหวด้านข้างระหว่างผู้ขาย 
 
โดยพื้นฐานแล้วมันมีลักษณะดังนี้: 

การละเมิดการดริฟท์ดำเนินการอย่างไรโดยใช้เทคนิคการเคลื่อนไหวด้านข้างข้ามผู้ขาย

  1. ลูกค้า เช่น Palo Alto Networks ใช้แพลตฟอร์ม SaaS เช่น Salesforce 
  2. เพื่อเพิ่มมูลค่า Palo Alto Networks เชื่อมต่อ 3rd แอปปาร์ตี้ – จาก Salesloft ถึง Salesforce 
  3. Salesloft เข้าซื้อ Drift ซึ่งถือครองโทเค็น OAuth ที่ให้สิทธิ์การเข้าถึงจาก Saleloft ไปยัง Salesforce ในนามของ Palo Alto Networks 
  4. หากข้อมูล Salesforce ของ Palo Alto Networks มีข้อมูลลับที่ฝังอยู่ (เช่น คีย์ API) ผู้โจมตีที่เจาะ Drift จะสามารถใช้ประโยชน์จากข้อมูลของ Salesforce เพื่อเข้าถึงสภาพแวดล้อมของผู้จำหน่ายรายอื่นได้มากขึ้น  

นี่คือความไว้วางใจแบบรวมศูนย์ (federated trust) รวมถึงความไว้วางใจโดยปริยาย (implicit trust) ซึ่งกำลังกลายเป็นความเสี่ยงแบบรวมศูนย์ การผสานรวมแต่ละครั้งดูเหมือนจะไม่เป็นอันตรายเมื่อแยกจากกัน แต่เมื่อนำมารวมกัน จะสร้างเส้นทางของผู้โจมตีข้ามองค์กรต่างๆ ดังนั้นแนวคิด (B2)ⁿ จึงเกิดขึ้น นั่นคือ การเชื่อมโยงระหว่างธุรกิจกับธุรกิจทวีคูณ และเพิ่มความเสี่ยงให้มากขึ้น 

การสร้างแบบจำลองความรับผิดชอบร่วมกันสำหรับ (B2)ⁿ การบูรณาการ SaaS

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

รูปแบบการแบ่งปันความรับผิดชอบที่เสนอสำหรับการรวม SaaS

เส้นทางข้างหน้าผ่านความรับผิดชอบร่วมกัน

จนกว่าจะมีข้อตกลงร่วมกันเกี่ยวกับรูปแบบความปลอดภัยที่ใช้ร่วมกันแบบใหม่ สำหรับการผสานรวมหรือโทเค็น/คีย์/ใบรับรอง/ข้อมูลประจำตัวที่สร้างขึ้นสำหรับบุคคลที่สามหรือสี่ ผู้นำ CISO และ IAM ควรเรียกร้องให้ผู้จำหน่ายของตนให้ข้อมูลบางอย่างเกี่ยวกับวงจรชีวิตโทเค็น ปริมาณการใช้งาน การตรวจสอบพื้นฐานสำหรับความผิดปกติในการใช้งาน และอื่นๆ อย่างน้อยที่สุด ควรทำงานร่วมกับผู้จำหน่ายเพื่อยืนยันความพร้อมของ "kill switch" หรือปุ่มรีเฟรช   

สำหรับผู้ขายเอง เราต้องแน่ใจว่าเราส่งเสริมให้พันธมิตรการรวมระบบและลูกค้าปลายทางของเรามองเห็นข้อมูลนี้ และเป็นส่วนหนึ่งของกำแพงการชำระเงิน เป็นส่วนหนึ่งของแพ็คเกจพื้นฐาน

อ้างอิง

กลุ่มวิเคราะห์ภัยคุกคามของ Google: การอัปเดต UNC6395 –
https://cloud.google.com/blog/topics/threat-intelligence/unc6395-drift-attack

คำแนะนำของ Salesforce เกี่ยวกับการลบแอป Drift 
https://help.salesforce.com/s/articleView?id=005134951&language=en_US&type=1 

การวิเคราะห์หน่วยที่ 42 ของ Palo Alto Networks  
https://unit42.paloaltonetworks.com/threat-brief-compromised-salesforce-instances/

การเปิดเผยข้อมูลของ Cloudflare เกี่ยวกับโทเค็นที่ถูกบุกรุก 
https://blog.cloudflare.com/response-to-salesloft-drift-incident/

การสอบสวนของ Mandiant เกี่ยวกับการประนีประนอม GitHub ของ Salesloft –
https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift

เรากล้าที่จะผลักดันการรักษาความปลอดภัยข้อมูลประจำตัวไปไกลยิ่งขึ้น

ค้นพบสิ่งที่เป็นไปได้

ตั้งค่าการสาธิตเพื่อดู Silverfort แพลตฟอร์มการรักษาความปลอดภัยข้อมูลประจำตัวในการดำเนินการ

ฮีโร่ใหม่ (1)

Silverfort เข้าซื้อกิจการ Fabrix Security

มอบการรักษาความปลอดภัยข้อมูลประจำตัวแบบอัตโนมัติในระหว่างการทำงาน

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