הגנב שממתין בדף התשלום – Magecart וסקימרים בחנויות Magento
פורסם על-ידי צוות SPD Hosting | יוני 2026
הקדמה
דמיינו חנות פיזית שבה מישהו החליף את מכשיר קורא כרטיסי האשראי בקופה בעותק מזויף –
כזה שנראה זהה, עובד בדיוק אותו הדבר, אבל מצלם כל כרטיס שעובר דרכו ושולח את הפרטים לכתובת אחרת.
זה בדיוק מה ש-Magecart עושה באונליין.
לא מדובר בפריצה דרמטית שמורידה את האתר. לא מדובר בהודעת כופרה. האתר ממשיך לפעול בצורה מושלמת –
הלקוחות מבצעים רכישות, מקבלים אישורי הזמנה, הכל נראה תקין. בינתיים, פרטי כרטיסי האשראי שלהם עוברים לתוקף.
מה זה Magecart?
Magecart הוא שם כולל לקמפייני תקיפה שמטמיעים קוד JavaScript זדוני בדפי תשלום של חנויות אונליין.
המטרה תמיד אותה: לגנוב פרטי כרטיס אשראי ברגע שהלקוח מקליד אותם.
הקמפיינים הראשונים זוהו ב-2016, אבל הטכניקה התפשטה ונהייתה מתוחכמת יותר. חנויות Magento הן יעד מועדף –
בגלל הפופולריות שלהן, בגלל שהן מנהלות תשלומים ישירות, ובגלל שהארכיטקטורה של Magento מציעה כמה וקטורי תקיפה
שלא קיימים ב-WordPress.
הסיפור: חנות שנראתה תקינה לגמרי
קיבלנו פנייה על חנות Magento שסובלת מדיווחים של לקוחות על חיובים חשודים. האתר עצמו עבד ללא דופי –
ביצועים תקינים, הזמנות מתקבלות, שום שגיאה גלויה.
בבדיקה של קוד דף הצ'קאאוט מצאנו את מה שחיפשנו.
איך ה-Skimmer עבד – מבט מהיר לתוך הקוד
הקוד שמצאנו היה obfuscated – שמות משתנים שנראים כמו _0x4cf547, מחרוזות מקודדות,
מבנה שנועד להקשות על קריאה. אחרי פתיחת ה-obfuscation, התמונה הייתה ברורה.
שלב 1 – הזרקת טופס מזויף
ה-Skimmer הכיל פונקציה שיצרה טופס כרטיס אשראי מזויף ומוזרקת לתוך דף הצ'קאאוט.
הטופס נראה זהה לחלוטין לטופס המקורי – אותו עיצוב, אותם שדות, אותו כפתור. הלקוח לא ראה שום הבדל.
שלב 2 – האזנה ואיסוף
פונקציה נוספת האזינה לכל לחיצת כפתור ושליחת טופס בעמוד. ברגע שזוהה שדה CVV מלא –
כלומר, הלקוח סיים להקליד את פרטי הכרטיס – הנתונים קודדו ונשמרו ב-cookie בשם __mage_static.
שלב 3 – דליפה לשני יעדים
ברגע שה-CVV זוהה, ה-Skimmer יצר שני iframes נסתרים שהפנו לשני דומיינים חיצוניים
עם הנתונים הגנובים מקודדים ב-URL. שני יעדים – כנראה כ-redundancy, למקרה שאחד חסום.
שלב 4 – אנטי-דטקציה
הקוד דרס את פונקציות ה-console של הדפדפן כדי למנוע רישום. הוא גם בדק cookie ספציפי –
אם ה-cookie היה קיים עם ערך מסוים, ה-Skimmer לא הופעל.
כנראה שזה שימש את התוקפים עצמם כדי לא ל"גנוב" מעצמם בזמן שבדקו שהקוד עובד.
40 שורות קוד. בלתי נראה לעין בלתי מזוינת. פועל על כל לקוח שהגיע לצ'קאאוט.
איפה היה מוחבא הקוד?
זו אחת השאלות הראשונות שאנחנו שואלים – ובמקרה הזה התשובה הייתה: בתוך ה-database.
ה-Skimmer לא היה קובץ JavaScript חיצוני שהועלה לשרת. הוא היה מוזרק לתוך תוכן
שמנוהל ב-DB של Magento – CMS blocks, layout updates, הגדרות תצורה שמכילות JavaScript.
זה אומר שסריקת הקבצים על הדיסק לא הייתה מוצאת אותו. הוא היה שם מאז שהתוקף קיבל גישה לממשק האדמין.
כמה זמן זה רץ?
זו השאלה שהכי קשה לענות עליה – ואחת הנקודות הכי חשובות להבנה.
Magecart skimmers יכולים לרוץ שבועות ואפילו חודשים לפני שמישהו שם לב.
כל אחד מהלקוחות שביצע רכישה בתקופה הזו – פרטי הכרטיס שלו עשויים להיות בידי התוקף.
האינדיקטור שהוביל לגילוי במקרה הזה היה מהאנטי וירוס שלנו, Imunify360,
אבל – תחשבו שלא היה אנטיוירוס –
הנקודת התראה הבאה הייתה יכולה להיות דיווחים של לקוחות על חיובים חשודים.
כלומר, יכול לקחת זמן עד שמספיק לקוחות הבחינו, פנו לבנק, הבנקים יצרו קשר, ורק אז זה יגיע לבעל החנות.
מה נדרש לזיהוי וניקוי
בדיקת ה-DB לפני הקבצים. בניגוד לאינסטינקט הראשוני של "בואו נסרוק את הקבצים,"
פתחנו קודם ב-queries על ה-DB של Magento – בחיפוש אחר JavaScript חשוד בתוך CMS blocks, layout updates, ו-config values.
ניתוח הקוד המקודד. ה-obfuscation שימש להסתרה אבל לא הצליח להסתיר את הפונקציונליות לאחר פתיחה.
זיהינו את יעדי ה-exfiltration, חילצנו את ה-IOCs, וחסמנו את הדומיינים ברמת ה-firewall.
מיפוי חלון ההדבקה. ניסינו לזהות מתי ה-Skimmer הוכנס, כדי לדעת על אילו לקוחות להמליץ לבעל החנות לעדכן.
הקשחה לאחר הניקוי. ה-Skimmer נכנס כי מישהו קיבל גישה לממשק האדמין. לאחר הסרתו,
עברנו על כל חשבונות האדמין, sessions פעילים, API tokens – וסגרנו את הכניסה.
מה בעל חנות Magento יכול לעשות
Content Security Policy (CSP). הגדרת CSP header שמגדיר אילו דומיינים מורשים לטעון JavaScript על האתר –
זה לא ימנע הזרקה ל-DB, אבל יחסום את ה-exfiltration לדומיינים לא מוכרים. זו אחת ההגנות האפקטיביות ביותר נגד Magecart.
ניטור שינויים ב-DB. שינויים ב-CMS blocks וב-layout updates הם לא פעולה יומיומית.
ניטור שמתריע על שינויים בטבלאות האלה הוא early warning system שמוכיח את עצמו.
2FA על ממשק האדמין. ה-Skimmer הגיע דרך גישה לגיטימית לאדמין –
מישהו גנב credentials. 2FA לא מונע את גניבת הסיסמה, אבל עוצר את השימוש בה.
עדכונים שוטפים. Magento מפרסמת patches אבטחה שמטפלות בוקטורים שדרכם תוקפים מגיעים לאדמין –
SQLI, deserialization, admin path exposure. חנות לא מעודכנת היא חנות פגיעה.
איך SPD Hosting מגנה על לקוחותיה
ב-SPD Hosting אנחנו לא מחכים לדיווח מלקוח.
המערכות שלנו מנטרות באופן שוטף חריגות בקוד, שינויים חשודים בקבצים של חנויות Magento שמתארחות אצלנו,
בקשות שמתקבלות בשרתי ה-WEB וההתנהגות שלהם – אנחנו חוקרים כיצד תוקפים מתנהגים, ויוצרים חוקים ומערכות
שיכולים לנטר, ולהתריע בפני הצוותים שלנו.
כשמזוהה ממצא חשוד – בין אם מדובר בקוד זדוני מוטמע ב-DB, בהתנהגות חריגה של JavaScript בצ'קאאוט,
או בגישה חשודה לממשק האדמין – אנחנו יוצרים קשר עם בעל החנות באופן יזום, לפני שלקוחות נפגעים.
המטרה היא לסגור את החור לפני שמישהו הספיק לעבור דרכו.
הלקח
Magecart לא שובר את האתר. הוא לא מפריע לפעילות. הוא לא גורם ל-downtime.
הוא פשוט יושב שם, בשקט, ואוסף כרטיסי אשראי.
הזיהוי כמעט תמיד מגיע מאוחר מדי – אחרי שלקוחות כבר נפגעו. ההגנה היחידה שעובדת היא הגנה מונעת:
CSP, ניטור DB, 2FA, ועדכונים. לא לחכות לדיווח הראשון של לקוח.
צוות אבטחת המידע – SPD Hostingsecurity@spd.co.il
