สรุปสั้น

แคมเปญ Magecart ใหม่กำลังใช้โครงสร้าง API ของ Stripe เป็นที่เก็บทั้ง payload ขโมยบัตรเครดิตและข้อมูลที่ขโมยมาจากหน้า checkout โดยกิจกรรมอันตรายทั้งหมดอาศัยโดเมนของ Google Tag Manager (googletagmanager.com) และ Stripe (api.stripe.com) ซึ่งร้านค้าออนไลน์ไว้ใจโดยปริยาย ทำให้เลี่ยงกฎ Content Security Policy และ network filter ที่ปกติจะตั้งธงทราฟฟิกไปยังโดเมน skimmer ที่ไม่รู้จัก

มัลแวร์ตระกูลใหม่นี้ถูกค้นพบโดยนักวิจัยจากบริษัทความปลอดภัย e-commerce ชื่อ Sansec ซึ่งพบว่าโค้ดอันตรายถูกโหลดจาก Google Tag Manager (GTM) container และทำงานบนทุกหน้าที่โหลดมัน โดย Sansec ระบุว่า “ทั้ง payload และบัตรที่ขโมยเคลื่อนผ่าน api.stripe.com ซึ่งร้านค้าอนุญาตโดเมนนี้เป็นค่าเริ่มต้น ทำให้ skimmer เล็ดลอดผ่านกฎ CSP และ network filter ที่ปกติจะตั้งธงทราฟฟิกไป skimmer ที่ไม่รู้จัก”

โค้ดอันตรายฝังอยู่ใน GTM container ที่ดูเหมือนถูกต้อง และทำงานเมื่อนักช้อปไปถึงหน้า checkout โดยจะ query Stripe API สำหรับ customer record เฉพาะ (ในกรณีนี้คือ cus_TfFjAAZQNOYENR) แล้วอ่านโค้ด JavaScript จากฟิลด์ metadata ของ record มาประกอบใหม่และรันด้วย new Function() จากนั้น skimmer จะมุ่งเป้าหน้า checkout ของ Magento/Adobe Commerce ดักข้อมูลการชำระเงิน ทั้งเลขบัตร วันหมดอายุ CVV ชื่อลูกค้า รวมถึงที่อยู่เรียกเก็บเงิน อีเมล และเบอร์โทร

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

เว็บไซต์ BleepingComputer รายงานเมื่อวันที่ 4 มิถุนายน 2569 ว่าบริษัท Sansec พบแคมเปญ Magecart ใหม่ที่ใช้โครงสร้าง API ของ Stripe เก็บ payload และข้อมูลบัตรที่ขโมย โดยอาศัยความน่าเชื่อถือของ Google Tag Manager และ Stripe

GTM เป็นระบบจัดการที่ให้เจ้าของเว็บเพิ่มและจัดการสคริปต์สำหรับ analytics โฆษณา และ tracking โดยไม่ต้องแก้ซอร์สโค้ดของเว็บ ส่วน Stripe เป็นแพลตฟอร์มประมวลผลการชำระเงินที่ร้านค้าออนไลน์ใช้กันแพร่หลายเพื่อรับบัตรเครดิต จัดการคำสั่งซื้อ และเรียกเก็บเงิน ตามข้อมูลของ Sansec โค้ดอันตรายฝังใน GTM container ที่ดูถูกต้อง ซึ่งจะ activate เมื่อนักช้อปถึงหน้า checkout โดย query Stripe API สำหรับ customer record เฉพาะ แล้วอ่านโค้ด JavaScript จากฟิลด์ metadata มาประกอบและรันด้วย new Function()

ข้อมูลที่ขโมยจะถูกต่อกันเป็นสตริงเดียว obfuscate ด้วยการ XOR และเก็บไว้ในเครื่อง (localStorage) แทนการส่งออกทันที การดึงข้อมูลทำผ่าน routine แยกที่ทำงานหลังโหลดหน้าและทุกหนึ่งนาที โดยแบ่งก้อนข้อมูลเป็นครึ่ง สร้าง Stripe customer object ใหม่ และเก็บข้อมูลที่ขโมยในฟิลด์ metadata กล่าวคือบัตรที่ขโมยทุกใบจะกลายเป็น customer record ปลอมในบัญชี Stripe ของผู้โจมตี เปลี่ยน Stripe ให้เป็น backend เก็บข้อมูลที่ขโมย เมื่อคัดลอกข้อมูลแล้ว ไฟล์ในเครื่องจะถูกลบเพื่อกำจัดร่องรอยและกันการอัปโหลดซ้ำ

Sansec ยังพบ variant ของการโจมตีที่ใช้ Google Firestore (บริการฐานข้อมูลคลาวด์) แทน Stripe โดย payload ถูกดึงจากเอกสาร Firestore ชื่อ tracking/captcha ในโปรเจกต์ชื่อ braintree-payment-app และเก็บข้อมูลที่ขโมยใน localStorage key อื่น (d_data_customer) ซึ่งชื่อเอกสารและโปรเจกต์ช่วยให้มัลแวร์กลมกลืนกับทราฟฟิกการชำระเงินและ bot-protection ที่ถูกต้อง ทั้งนี้ customer record ของ Stripe ที่มี skimmer ถูกสร้างเมื่อวันที่ 24 ธันวาคม 2568 บ่งชี้ว่าปฏิบัติการอาจเริ่มมาตั้งแต่วันนั้น

Credit card theft campaign abuses Stripe to host stolen payment info

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

หัวใจของแคมเปญคือการใช้บริการที่ร้านค้าไว้ใจโดยปริยาย (Google Tag Manager และ Stripe) เป็นทั้งช่องส่ง payload และที่เก็บข้อมูลที่ขโมย ทำให้ skimmer เลี่ยง CSP และ network filter ได้ เพราะโดเมน googletagmanager.com และ api.stripe.com มักถูกอนุญาตเป็นค่าเริ่มต้น

ขั้นตอนเริ่มจากโค้ดอันตรายใน GTM container ทำงานเมื่อถึงหน้า checkout query Stripe API สำหรับ customer record เฉพาะ (เช่น cus_TfFjAAZQNOYENR) อ่านโค้ด JavaScript จาก metadata มาประกอบและรันด้วย new Function() จากนั้น skimmer ดักข้อมูลบัตรบนหน้า Magento/Adobe Commerce ทั้งเลขบัตร วันหมดอายุ CVV ชื่อ ที่อยู่ อีเมล และเบอร์โทร

ข้อมูลที่ขโมยถูก XOR obfuscate เก็บใน localStorage แล้ว routine แยกจะทำงานทุกนาที สร้าง Stripe customer object ใหม่และเก็บข้อมูลในฟิลด์ metadata ทำให้บัตรที่ขโมยกลายเป็น customer record ปลอม เมื่อคัดลอกแล้วก็ลบไฟล์ในเครื่องเพื่อลบร่องรอย โดยมี variant ที่ใช้ Google Firestore แทน Stripe ในลักษณะเดียวกัน

ผลกระทบต่อไทย

ร้านค้าออนไลน์ในไทยจำนวนมากใช้ Magento/Adobe Commerce เป็นแพลตฟอร์ม e-commerce และใช้ Google Tag Manager กับ Stripe ในการจัดการสคริปต์และรับชำระเงิน ทำให้แคมเปญ Magecart นี้เป็นภัยโดยตรงต่อร้านค้าไทยและลูกค้าที่กรอกบัตรเครดิตบนหน้า checkout

จุดที่อันตรายที่สุดคือการใช้โดเมนที่ร้านค้าไทยไว้ใจ (Google, Stripe) ทำให้ skimmer เลี่ยงการตรวจจับด้วย CSP และ network filter ที่ร้านค้าไทยมักตั้งไว้ และเนื่องจากโค้ดฝังใน GTM container ผู้ดูแลเว็บที่ไม่ตรวจสอบ container อย่างละเอียดอาจไม่ทันสังเกต

ความเสียหายกระทบลูกค้าไทยโดยตรง เพราะข้อมูลบัตรเครดิต ที่อยู่ และข้อมูลส่วนตัวถูกขโมยไปโดยไม่รู้ตัว ซึ่งอาจนำไปสู่การฉ้อโกงทางการเงิน ร้านค้าไทยจึงควรตรวจสอบ GTM container และมาตรการความปลอดภัยของหน้า checkout อย่างจริงจัง

คำแนะนำ

  1. ตรวจสอบ GTM container อย่างละเอียด — หาสคริปต์ที่ไม่ได้เพิ่มเอง โดยเฉพาะที่ query Stripe API หรือ Firestore บนหน้า checkout
  2. เฝ้าระวังการสร้าง Stripe customer object ผิดปกติ — ตรวจบัญชี Stripe หา customer record ที่มี metadata น่าสงสัย
  3. จำกัดสคริปต์บนหน้า checkout — ใช้ CSP ที่เข้มงวดและ Subresource Integrity (SRI) แม้กับโดเมนที่ไว้ใจ
  4. ตรวจสอบความสมบูรณ์ของหน้า checkout เป็นประจำ — เปรียบเทียบโค้ดกับเวอร์ชันที่รู้ว่าปลอดภัย
  5. อัปเดต Magento/Adobe Commerce — และปลั๊กอินให้เป็นเวอร์ชันล่าสุด ลดช่องทางที่ผู้โจมตีฝังโค้ด
  6. แนะนำลูกค้าใช้บัตรเสมือน (virtual card) — แบบใช้ครั้งเดียวพร้อมตั้งวงเงิน เพื่อลดความเสียหายหากข้อมูลถูกขโมย

Indicators of Compromise (IoCs)

ประเภทตัวบ่งชี้คำอธิบาย
Stripe Customer IDcus_TfFjAAZQNOYENRcustomer record ของ Stripe ที่เก็บ skimmer payload
Domainapi.stripe[.]comใช้เป็นทั้งช่องส่ง payload และเก็บข้อมูลที่ขโมย (ถูกใช้ในทางผิด)
Domaingoogletagmanager[.]comGTM container ที่ฝังโค้ด skimmer
Firestore Doctracking/captcha (project: braintree-payment-app)variant ที่ใช้ Google Firestore แทน Stripe
localStorage Keyd_data_customerคีย์เก็บข้อมูลที่ขโมยใน variant Firestore
TargetMagento / Adobe Commerce checkoutหน้าเป้าหมายของ skimmer

หมายเหตุ: โดเมนถูก defang โดยเจตนา (เช่น [.]) ให้ re-fang เฉพาะในแพลตฟอร์ม threat intelligence ที่ควบคุมได้ เช่น MISP, VirusTotal หรือ SIEM

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