แคมเปญนี้ต่อเรียงการโจมตีสามขั้นตอน โดยแต่ละขั้นตอนใช้ประโยชน์จากบริการที่ถูกกฎหมายเพื่อหลบเลี่ยงการตรวจจับ
ผู้โจมตีจะเริ่มจากการเจาะเข้าไปในคอนเทนเนอร์ Google Tag Manager บนเว็บไซต์ร้านค้าเป้าหมาย พวกเขาแทรกแท็กอันตรายที่โหลดบนทุกหน้าของเว็บ เนื่องจากสคริปต์มีต้นทางจาก googletagmanager.com ซึ่งเป็นโดเมนสำหรับวิเคราะห์ข้อมูลที่เชื่อถือได้ มันจึงเล็ดลอดผ่านนโยบาย Content Security Policy และตัวบล็อกโฆษณาทั่วไปได้โดยไม่ส่งสัญญาณเตือนใดๆ GTM จึงกลายเป็นกลไกส่งมอบที่ไม่สามารถบล็อกได้
แทนที่จะเรียกไปยังเซิร์ฟเวอร์ภายนอกที่น่าสงสัย แท็ก GTM จะร้องขอเพย์โหลดสกิมเมอร์จาก api.stripe.com ผู้โจมตีจะเก็บสกิมเมอร์ JavaScript ทั้งหมดไว้ใน ช่องข้อมูลเมตาดาต้าของลูกค้า (Customer metadata) บนบัญชี Stripe ของตนเอง โดยใช้คีย์ลับในโหมดทดสอบ (sk_test_...) ในการเขียนและเรียกอ่านข้อมูล สกิมเมอร์จึงมาถึงจากโดเมนที่ผู้ดูแลร้านค้าเชื่อใจโดยปริยายเพราะเป็นส่วนหนึ่งของระบบชำระเงิน ทำให้การตรวจสอบเครือข่ายและกฎ CSP แทบจะไม่เคยตั้งคำถามกับการเรียก API นี้เลย
เมื่อผู้ซื้อกรอกข้อมูลบัตรเครดิต ข้อมูลส่วนตัว และที่อยู่สำหรับออกบิลในหน้าชำระเงิน สกิมเมอร์ที่ถูกฉีดไว้จะดักจับข้อมูลดังกล่าวและส่งกลับไปยังบัญชี Stripe ของผู้โจมตี โดยเขียนข้อมูลในรูปแบบของระเบียนลูกค้าปลอมหรือข้อมูลเมตาดาต้าผ่าน API เดียวกันของ Stripe เนื่องจากการรับส่งข้อมูลเพื่อการขโมยข้อมูลถูกส่งกลับไปที่
api.stripe.com เหมือนเดิม มันจึงกลมกลืนไปกับการเรียก API ชำระเงินที่ถูกกฎหมายได้อย่างแนบเนียน ทำให้การขโมยแทบจะล่องหนในบันทึกไฟร์วอลล์และเครื่องมือตรวจจับความผิดปกติทั้งหลาย
คีย์ลับในโหมดทดสอบของ Stripe (sk_test_...) ให้สิทธิ์ในการอ่านและเขียนทั้งหมดภายในสภาพแวดล้อมแซนด์บ็อกซ์ และอนุญาตให้สร้างลูกค้าปลอมและช่องข้อมูลเมตาดาต้าได้ไม่จำกัดโดยไม่มีค่าใช้จ่าย เนื่องจากคีย์ทดสอบไม่เคยก่อให้เกิดธุรกรรมทางการเงินจริง การนำไปใช้ในทางที่ผิดจึงถูกมองข้ามได้ง่าย ผู้โจมตีใช้ประโยชน์จากข้อเท็จจริงที่ว่า หลายองค์กรปฏิบัติต่อคีย์ทดสอบราวกับว่ามีความเสี่ยงต่ำ และไม่ตรวจสอบกิจกรรมในแซนด์บ็อกซ์อย่างเข้มงวดเท่ากับการรับส่งข้อมูลในโหมดจริง
ภัยคุกคามที่เกี่ยวข้องแต่แยกจากกันคือ การเปิดเผยของคีย์ลับในโหมดจริง ซึ่งจะทำให้ผู้โจมตีเข้าถึงข้อมูลธุรกรรมจริงได้โดยตรง รวมถึงความสามารถในการคืนเงินหรือโอนย้ายเงินทุน แม้ว่าแคมเปญนี้จะใช้คีย์โหมดทดสอบเพื่ออำพรางตัว แต่หลักการเบื้องหลังก็เหมือนกัน: กุญแจ API ของ Stripe ไม่ว่าจะในโหมดใด ล้วนเป็นข้อมูลรับรองที่มีอำนาจสูง ซึ่งไม่ควรปรากฏในโค้ดฝั่งไคลเอ็นต์หรือคอนเทนเนอร์ Google Tag Manager โดยเด็ดขาด
ในขณะที่แคมเปญ 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 ครั้ง และรายงานว่าผู้โจมตีกำลังใช้การสร้างบัญชีผู้ดูแลระบบโดยไม่ได้รับอนุญาต เป็นส่วนหนึ่งของกระบวนการหลังการโจมตี เจ้าของเว็บไซต์ควรมองหาดัชนีชี้วัดการถูกโจมตี เช่น ผู้ใช้ระดับแอดมินใหม่ที่มีชื่อผิดสังเกต, ไฟล์ที่ผิดปกติบนเซิร์ฟเวอร์, หรือการเชื่อมต่อขาออกที่น่าสงสัย
api.stripe.com ไว้ในรายการ script-src หากไม่จำเป็นอย่างยิ่ง หากจำเป็นต้องมี ให้บังคับใช้แฮช Sub-resource Integrity (SRI) และการบล็อกสคริปต์อินไลน์จะช่วยเพิ่มการป้องกันอีกชั้น eval() ที่น่าสงสัย, และการเชื่อมต่อเครือข่ายขาออกไปยัง IP แปลกปลอม การตรวจสอบความสมบูรณ์ของ WordPress อย่างสมบูรณ์ ทั้งไฟล์หลัก, ธีม, และปลั๊กอิน เป็นสิ่งจำเป็นหลังจากการแก้ไข
Comments
0 comments