แก๊ง Magecart เปลี่ยน Stripe ให้เป็นฐานบัญชาการมัลแวร์ที่พรางตัวแนบเนียนที่สุด

แคมเปญนี้ต่อเรียงการโจมตีสามขั้นตอน โดยแต่ละขั้นตอนใช้ประโยชน์จากบริการที่ถูกกฎหมายเพื่อหลบเลี่ยงการตรวจจับ

ขั้นที่ 1: ฉีดตัวโหลดผ่าน Google Tag Manager

ผู้โจมตีจะเริ่มจากการเจาะเข้าไปในคอนเทนเนอร์ Google Tag Manager บนเว็บไซต์ร้านค้าเป้าหมาย พวกเขาแทรกแท็กอันตรายที่โหลดบนทุกหน้าของเว็บ เนื่องจากสคริปต์มีต้นทางจาก googletagmanager.com ซึ่งเป็นโดเมนสำหรับวิเคราะห์ข้อมูลที่เชื่อถือได้ มันจึงเล็ดลอดผ่านนโยบาย Content Security Policy และตัวบล็อกโฆษณาทั่วไปได้โดยไม่ส่งสัญญาณเตือนใดๆ GTM จึงกลายเป็นกลไกส่งมอบที่ไม่สามารถบล็อกได้

ขั้นที่ 2: ดึงสกิมเมอร์จาก API ของ Stripe

แทนที่จะเรียกไปยังเซิร์ฟเวอร์ภายนอกที่น่าสงสัย แท็ก GTM จะร้องขอเพย์โหลดสกิมเมอร์จาก api.stripe.com ผู้โจมตีจะเก็บสกิมเมอร์ JavaScript ทั้งหมดไว้ใน ช่องข้อมูลเมตาดาต้าของลูกค้า (Customer metadata) บนบัญชี Stripe ของตนเอง โดยใช้คีย์ลับในโหมดทดสอบ (sk_test_...) ในการเขียนและเรียกอ่านข้อมูล สกิมเมอร์จึงมาถึงจากโดเมนที่ผู้ดูแลร้านค้าเชื่อใจโดยปริยายเพราะเป็นส่วนหนึ่งของระบบชำระเงิน ทำให้การตรวจสอบเครือข่ายและกฎ CSP แทบจะไม่เคยตั้งคำถามกับการเรียก API นี้เลย

ขั้นที่ 3: ส่งข้อมูลที่ขโมยกลับไปยังบัญชี Stripe เดียวกัน

เมื่อผู้ซื้อกรอกข้อมูลบัตรเครดิต ข้อมูลส่วนตัว และที่อยู่สำหรับออกบิลในหน้าชำระเงิน สกิมเมอร์ที่ถูกฉีดไว้จะดักจับข้อมูลดังกล่าวและส่งกลับไปยังบัญชี Stripe ของผู้โจมตี โดยเขียนข้อมูลในรูปแบบของระเบียนลูกค้าปลอมหรือข้อมูลเมตาดาต้าผ่าน API เดียวกันของ Stripe เนื่องจากการรับส่งข้อมูลเพื่อการขโมยข้อมูลถูกส่งกลับไปที่ api.stripe.com เหมือนเดิม มันจึงกลมกลืนไปกับการเรียก API ชำระเงินที่ถูกกฎหมายได้อย่างแนบเนียน ทำให้การขโมยแทบจะล่องหนในบันทึกไฟร์วอลล์และเครื่องมือตรวจจับความผิดปกติทั้งหลาย

ปฏิบัติการทั้งหมดนี้ดำเนินมาตั้งแต่อย่างน้อยวันที่ 24 ธันวาคม 2025 ตามดัชนีชี้วัดที่นักวิจัยตรวจพบ

ทำไมคีย์ลับในโหมดทดสอบถึงอันตรายนัก

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

ภัยคุกคามที่เกี่ยวข้องแต่แยกจากกันคือ การเปิดเผยของคีย์ลับในโหมดจริง ซึ่งจะทำให้ผู้โจมตีเข้าถึงข้อมูลธุรกรรมจริงได้โดยตรง รวมถึงความสามารถในการคืนเงินหรือโอนย้ายเงินทุน แม้ว่าแคมเปญนี้จะใช้คีย์โหมดทดสอบเพื่ออำพรางตัว แต่หลักการเบื้องหลังก็เหมือนกัน: กุญแจ API ของ Stripe ไม่ว่าจะในโหมดใด ล้วนเป็นข้อมูลรับรองที่มีอำนาจสูง ซึ่งไม่ควรปรากฏในโค้ดฝั่งไคลเอ็นต์หรือคอนเทนเนอร์ Google Tag Manager โดยเด็ดขาด

CVE-2026-3300: ช่องโหว่รันโค้ดระยะไกลขั้นวิกฤตใน Everest Forms Pro

ในขณะที่แคมเปญ Stripe มุ่งเป้าไปที่หน้าชำระเงินของอีคอมเมิร์ซ เจ้าของเว็บไซต์ WordPress กำลังเผชิญกับภัยคุกคามเร่งด่วนไม่แพ้กันจากช่องโหว่ของปลั๊กอินที่ถูกโจมตีอย่างแข็งขันตั้งแต่วันที่ 13 เมษายน 2026

CVE-2026-3300 เป็นช่องโหว่ในการรันโค้ดจากระยะไกล (RCE) โดยไม่ต้องรับรองตัวตนในปลั๊กอิน Everest Forms Pro ซึ่งมียอดการติดตั้งใช้งานอยู่ประมาณ 4,000 เว็บไซต์ ช่องโหว่นี้มีคะแนน CVSS 9.8 และส่งผลกระทบต่อทุกเวอร์ชันจนถึงและรวมถึง 1.9.12

จุดบกพร่องอยู่ในฟังก์ชัน process_filter() ภายในส่วนเสริม Calculation เมื่อเปิดใช้งานคุณสมบัติ "Complex Calculation" ปลั๊กอินจะนำค่าที่ผู้ใช้ป้อนมาจากฟิลด์ฟอร์มประเภทข้อความ มาต่อกันโดยตรงเป็นสตริงโค้ด PHP และส่งผลลัพธ์ไปยัง eval() โดยไม่มีการหนีอักขระ (escape) ที่เหมาะสม ฟังก์ชัน sanitize_text_field() ที่ใช้กับข้อมูลนำเข้า ไม่ได้จัดการกับเครื่องหมายคำพูดเดี่ยวหรืออักขระอื่นๆ ที่มีความหมายพิเศษในบริบทของโค้ด PHP ทำให้ผู้โจมตีสามารถหลุดออกจากสตริงที่ตั้งใจไว้ และแทรกคำสั่งตามอำเภอใจได้

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

มาตรการป้องกันสำหรับภัยคุกคามทั้งสอง

การสกัดกั้นห่วงโซ่การโจมตี Magecart บน Stripe

• ล็อกดาวน์ Google Tag Manager. จำกัดคอนเทนเนอร์ GTM ให้มีเฉพาะแท็กที่ผ่านการอนุมัติและตรวจสอบแล้ว และบังคับใช้กระบวนการอนุมัติการเปลี่ยนแปลงที่เข้มงวดก่อนเผยแพร่
• เข้มงวด Content Security Policy. อย่าเพิ่ม api.stripe.com ไว้ในรายการ script-src หากไม่จำเป็นอย่างยิ่ง หากจำเป็นต้องมี ให้บังคับใช้แฮช Sub-resource Integrity (SRI) และการบล็อกสคริปต์อินไลน์จะช่วยเพิ่มการป้องกันอีกชั้น
• ตรวจสอบกิจกรรมในแซนด์บ็อกซ์ของ Stripe. ตรวจสอบแดชบอร์ด Stripe ของคุณเพื่อหาปริมาณที่ผิดปกติของการสร้างออบเจ็กต์ลูกค้า หรือการเขียนข้อมูลเมตาดาต้าภายใต้คีย์โหมดทดสอบ ปฏิบัติต่อความผิดปกติในแซนด์บ็อกซ์ด้วยความจริงจังเทียบเท่ากับในโหมดจริง
• หมุนเวียนและปกป้องกุญแจ API. อย่าฝังคีย์ลับของ Stripe – ทั้งแบบทดสอบและแบบจริง – ลงใน JavaScript ฝั่งไคลเอ็นต์, ตัวแปร GTM, หรือที่เก็บโค้ดสาธารณะโดยเด็ดขาด หมุนเวียนคีย์ใดๆ ก็ตามที่อาจถูกเปิดเผย
• ใช้การตรวจสอบฝั่งไคลเอ็นต์. ใช้เครื่องมือตรวจสอบความสมบูรณ์ทางฝั่งเบราว์เซอร์ที่ตรวจจับการเปลี่ยนแปลง DOM ในหน้าชำระเงินโดยสคริปต์ที่ไม่ได้รับอนุญาต

การแก้ไขช่องโหว่ Everest Forms Pro

• อัปเดตทันที. อัปเกรดเป็น Everest Forms Pro เวอร์ชัน 1.9.13 หรือใหม่กว่า ซึ่งมีการแก้ไขแล้ว
• ปิดใช้งานฟีเจอร์ที่มีความเสี่ยงหากยังไม่ได้แพตช์. เพื่อเป็นการแก้ไขชั่วคราว ให้ปิดฟีเจอร์ "Complex Calculation" ในการตั้งค่าปลั๊กอิน เพื่อป้องกันการโจมตีผ่านข้อมูลที่ไม่ได้ escape ที่ส่งไปยัง eval()
• สแกนหาสัญญาณการบุกรุก. มองหาบัญชีผู้ดูแลระบบที่ไม่รู้จัก, ไฟล์ที่ผิดปกติ, การเรียกใช้ eval() ที่น่าสงสัย, และการเชื่อมต่อเครือข่ายขาออกไปยัง IP แปลกปลอม การตรวจสอบความสมบูรณ์ของ WordPress อย่างสมบูรณ์ ทั้งไฟล์หลัก, ธีม, และปลั๊กอิน เป็นสิ่งจำเป็นหลังจากการแก้ไข