בקצרה:
- לקוח התקין באתר שלו תוסף סליידר מסחרי בגרסה פרוצה (Nulled) שהוריד ממקור לא מוכר.
- מי שהפיץ את העותק הפרוץ שתל בתוכו קוד זדוני מראש — עוד לפני שהתוסף הגיע לאתר.
- Imunify360, שרץ על כל שרת אחסון שיתופי שלנו, זיהה את הקוד המעורפל בתוך קובץ Cache בשבת ב-04:35 לפנות בוקר.
- ה-SOC הסלים, ה-SecOps תחקר, והאתר נוקה מקצה לקצה — הכול באותו יום, בלי השבתה ובלי שהלקוח נגע במשהו.
- אפס פגיעה בצד השרת. אפס דליפת סיסמאות. אפס הזרקה למסד הנתונים.
שבת בבוקר, 04:35
רוב אירועי הסייבר שאנחנו מטפלים בהם מתחילים בצורה דרמטית: קריסה, הודעת כופר, הפניה לאתר מוזר, לקוח שמתקשר בבהלה. האירוע הזה התחיל אחרת לגמרי — בהתראה שקטה אחת, בשבת בבוקר, בזמן שכולם ישנו.
Imunify360 סיים סריקה ממוקדת בשעה 04:35. תוצאה: קובץ אחד נסרק, נוזקה אחת זוהתה. הקובץ ישב בתיקיית ה-Cache של תוסף האצה פופולרי, עם שם קובץ שנראה כמו כל קובץ JS ממוזער אחר:
wp-content/cache/min/1/<hash>.js Signature: SMW-BLKH-SA-CLOUDAV-js.obf-NP2681-0
התראה אחת. קובץ אחד. סיווג "js.obf" — כלומר JavaScript מעורפל. במערכת שחוסמת מעל 109 מיליון ניסיונות תקיפה בשנה, התראה בודדת כזו יכולה בקלות להיראות כמו רעש. וכאן בדיוק מתחיל ההבדל בין מערכת שמצפצפת לבין SOC שיודע מה לעשות עם הצפצוף.
מה קורה כשהתראה הופכת לתחקיר
ההתראה נכנסה לזרימת העבודה הרגילה שלנו. אנליסט SOC פתח את האירוע, ואחרי אימות ראשוני שמדובר ב-True Positive ולא בהתראת שווא, זה הועבר להמשך תחקור ב-SecOps. השאלה הראשונה של האנליסט לא הייתה "איך מנקים את זה", אלא "רגע, איך זה הגיע לשם מלכתחילה?"
זו השאלה שמפרידה בין ניקוי לבין טיפול. אפשר למחוק קובץ נגוע ולסגור קריאה תוך שתי דקות. אבל אם לא הבנת מי כתב את הקובץ הזה ולמה — אתה תפגוש אותו שוב מחר בבוקר.
התחקיר בנוי משלושה מקורות מידע שמצטלבים:
- Imunify360 — מה זוהה, איזו חתימה, מה נוקה ומתי.
- מערכת הקבצים — זמני יצירה ושינוי של כל קובץ רלוונטי. זה מה שמוביל אל המקור.
- מודיעין איומים חיצוני — האם היעד שאליו הנוזקה פונה מוכר לנו ממקומות אחרים.
שלושת אלה יחד הפכו התראה בת שורה אחת לתמונה מלאה.
הממצא: זה לא היה תוקף. זה היה התוסף.
הקוד הזדוני לא הוזרק לאתר על ידי מישהו שפרץ אליו. הוא הגיע ארוז מראש.
באתר היה מותקן תוסף סליידר מסחרי ופופולרי מאוד בעולם הוורדפרס, בגרסה ישנה. התוסף הזה הוא מוצר לגיטימי לחלוטין — כשקונים אותו. מה שהותקן באתר היה עותק Nulled: גרסה "פרוצה" שהלקוח הוריד מאתר הפצה כלשהו, בלי רישיון, בלי עדכונים, בלי מקור מוכר.
מי שהפיץ את העותק הפרוץ הזה לא עשה את זה בשביל הכיף. הוא הוסיף לקובץ ה-PHP של התוסף שורת קוד קטנה, בדיוק בנקודה שבה התוסף מדפיס JavaScript לגיטימי לכל עמוד באתר. התוצאה: כל עמוד שהכיל סליידר הגיש לגולש, יחד עם הקוד האמיתי, גם את התוספת של המפיץ.
איך הקוד נראה
הקוד הוסתר בטכניקת ערפול קלאסית — מחרוזת ארוכה של קודי תווים מספריים שמפוענחת בזמן ריצה:
var f=String; eval(f.fromCharCode(102,117,110,99,116,105,111,110, ... )); // [קוצר בכוונה]
אחרי פענוח, הלוגיקה פשוטה עד להכעיס:
- בדוק אם הסקריפט החיצוני כבר נטען בעמוד.
- אם לא — צור אלמנט
<script>חדש. - הפנה אותו אל שרת חיצוני [כתובת הוסרה].
- הזרק אותו לעמוד.
שימו לב לסעיף הראשון. בדיקת "האם כבר טענתי את עצמי" היא לא משהו שחובבן כותב. זו אופטימיזציה של מי שמנהל קמפיין: היא מונעת טעינה כפולה, מפחיתה שגיאות בקונסול, ומקטינה את הסיכוי שמישהו ישים לב. הקוד הזה נכתב על ידי מישהו שעושה את זה בקנה מידה גדול, לא על ידי ילד משועמם.
לאן הקוד פנה
הכתובת שאליה הנוזקה טענה סקריפט אינה אנונימית. בדיקה במקורות מודיעין ציבוריים החזירה תמונה חד-משמעית:
- ThreatFox — מסווגת כשרת שליטה ובקרה (C2) של בוטנט, ברמת ביטחון 100%.
- VirusTotal — עשרה מנועי אנטי-וירוס מסמנים אותה כזדונית, ביניהם ESET, Fortinet, Kaspersky, Dr.Web ו-VIPRE.
- Sucuri — אותה תשתית בדיוק תועדה בקמפיין ניצול המוני של תוסף אלמנטור פופולרי, ככלי הפצה רב-אתרי.
- מחקרי Ad-Security — קושרים אותה לשרשראות הפניה, מלברטייזינג והזרקת פופ-אפים דרך אתרי וורדפרס שנפרצו.
במילים פשוטות: כל גולש שנכנס לעמוד באתר טען לדפדפן שלו סקריפט משרת של בוטנט. מה הסקריפט הזה הגיש לו בפועל — פרסומות, הפניה, או ניסיון הדבקה — משתנה לפי גיאוגרפיה, שעה וסוג דפדפן.
ציר האירוע
| שלב | מה קרה |
|---|---|
| הרקע | הלקוח מתקין בהקמת האתר תוסף סליידר בגרסה פרוצה. הקוד הזדוני כבר בפנים. תוסף ההאצה ממזער אותו ושומר אותו בשכבת ה-Cache — 4,847 קבצים. |
| זיהוי | Imunify360 מזהה את הקוד המעורפל בקובץ Cache, בשבת לפנות בוקר. |
| נטרול מיידי | ניקוי אוטומטי: קובץ ה-PHP מטוהר, קובץ ה-Cache הנגוע מאופס. דקה אחת מהזיהוי. |
| הסלמה | ההתראה נכנסת לתור ה-SOC, אנליסט מאמת True Positive ומעביר ל-SecOps. |
| תחקיר | איתור נקודת ההזרקה, פענוח ה-payload, הצלבה מול מודיעין איומים, בדיקת מסד נתונים. |
| טיפול | הסרת התוסף הפרוץ וניקוי מלא של שכבת ה-Cache. |
| סגירה | סריקת אימות (תוצאה: אפס), חתימות WAF חדשות בכל מערך האחסון, דיווח ללקוח. |
מרגע הזיהוי ועד נטרול הקוד: דקה. מרגע הזיהוי ועד סגירת האירוע המלאה: שעה וחצי. בשבת, לפנות בוקר.
למה תוסף פרוץ הוא בעיה שמנציחה את עצמה
וכאן החלק שהכי מעניין טכנית, וגם הכי מפתיע.
תוספי האצה מודרניים ממזגים וממזערים קבצי JavaScript, ושומרים את התוצאה בקובץ שנוצר פעם אחת. שם הקובץ נגזר מתוכן הקבצים שממנו הוא נבנה. כל עוד התוכן לא משתנה — הקובץ לא נבנה מחדש. זה בדיוק מה שהופך Cache למהיר, וזה בדיוק מה שהפך אותו כאן למקפיא.
התוסף היה פרוץ, ולכן לא היה לו רישיון. בלי רישיון אין עדכונים. בלי עדכונים קובץ ה-PHP לא משתנה. וכשקובץ המקור לא משתנה — ה-Hash לא משתנה, ה-Cache לא מתרענן, והקוד הזדוני נשמר על הדיסק כמו בפורמלין.
התובנה: תוסף פרוץ הוא לא רק "תוסף בלי תמיכה". הוא תוסף שהארכיטקטורה שלו מבטיחה שכל דבר רע שנמצא בתוכו יישאר שם. אין עדכון שיסיר אותו, אין רענון שידרוס אותו, ואין התראה שתגיד לכם שמשהו לא בסדר. אם אתם רוצים להבין לעומק איך שכבות ה-Cache עובדות ומתי הן עוזרות, כתבנו על זה בהרחבה במאמר Object Cache – Redis, Memcached, OPCache או כלום?.
איך בכל זאת תפסנו את זה
נשאלת שאלה הוגנת: אם הקוד היה מעורפל, קבור בתוך חבילת JS ממוזערת, בתוסף שנראה תמים — איך הוא נתפס?
התשובה היא שאף מערכת בודדת לא תפסה את זה. השילוב תפס את זה.
1. Imunify360 — השכבה שסורקת בלי לשאול
Imunify רץ אצלנו על כל שרת אחסון שיתופי — כן, גם על החבילות של 9.90 ₪. הוא סורק לא רק קבצי PHP אלא גם תוצרי Cache, וזה מה שהאיר את הנורה כאן. זה הצד ה"מכני" של ההגנה, והוא גם זה שביצע את הניקוי הראשוני האוטומטי ב-04:35, בלי שאף בן אדם היה ער.
2. SOC — הסינון וההחלטה
התראה לבדה היא לא אירוע. ה-SOC שלנו הוא התהליך שמחליט אילו התראות הן רעש ואילו דורשות בן אדם. כאן ההחלטה הייתה: נוזקה מעורפלת בקובץ Cache היא לא תקלה, זה סימפטום. מעלים דרגה.
3. SecOps — התחקיר
זה החלק שלוקח שעות ולא דקות: לאתר את נקודת ההזרקה המדויקת בקוד התוסף, להצליב אילו עמודים הכילו את הרכיב הנגוע ואילו לא, לפענח את ה-payload, לבדוק את מסד הנתונים מקצה לקצה, ולמפות את האירוע למסגרת MITRE ATT&CK כדי להבין אם מדובר במקרה בודד או בקמפיין מוכר.
ההצלבה הזו היא גם מה שאפשר לנו לקבוע חד-משמעית שהזיהום הגיע מהתוסף ולא ממקור אחר: כל עמוד שהכיל את רכיב הסליידר היה נגוע, וכל עמוד שלא הכיל אותו — היה נקי. אין ראיה חותכת מזו.
4. מודיעין איומים
ההצלבה מול מקורות חיצוניים היא מה שהפך "קובץ JS חשוד" ל"טעינת C2 של בוטנט מוכר, בקמפיין שתועד גם מול תוספים אחרים". בלי השלב הזה, הסיווג היה נשאר "בינוני". איתו, הוא קפץ לגבוה.
מה עשינו בפועל
- ניקוי אוטומטי של קובץ המקור הנגוע ואיפוס קובץ ה-Cache שזוהה — בוצע על ידי Imunify תוך דקות מהזיהוי.
- השבתה ומחיקה מלאה של התוסף הפרוץ. לא עדכון, לא החלפה — הסרה.
- מחיקת כל שכבת ה-Cache של האתר, כדי לוודא שאף אחד מ-4,847 הקבצים לא שרד.
- סריקת אימות אחרי הניקוי: חיפוש דפוס ה-payload והכתובת החיצונית בכל הקבצים החדשים. תוצאה: אפס.
- בדיקת מסד נתונים מלאה — טבלאות ההגדרות, התכנים והסקריפטים. נקי לחלוטין. הזיהום היה כולו ברמת הקבצים.
- חתימות ייעודיות ב-WAF לחסימת דפוס ה-payload ותשתית ה-C2 — לא רק באתר הזה, אלא בכל מערך האחסון.
- דיווח מלא ללקוח, כולל רשימת התוספים הישנים באתר שדורשים עדכון מיידי.
שימו לב לסעיף 6. זה החלק שלקוח בודד אף פעם לא רואה: כל אירוע אצל לקוח אחד הופך מיד לשכבת הגנה אצל כל הלקוחות. תחקיר טוב הוא לא רק פתרון של בעיה, הוא חיסון.
למה זה מסווג "חמור" אם השרת לא נפגע?
שאלה שעולה כמעט תמיד. הרי לא הייתה השתלטות על השרת, לא דלפו סיסמאות, ולא הייתה תנועה רוחבית לחשבונות אחרים. אז למה החומרה גבוהה?
כי החומרה נמדדת גם לפי מי נפגע, לא רק לפי מה נפגע.
הנזק כאן היה כולו בצד הגולש. כל אדם שנכנס לאתר — לקוח פוטנציאלי, ספק, עובד, מישהו שהגיע מגוגל — קיבל לדפדפן שלו סקריפט מתשתית עוינת. בעל האתר לא ידע. הגולשים בוודאי לא ידעו. ומבחינת אמון, מוניטין, ובמקרים מסוימים גם חשיפה משפטית לפי דרישות הגנת הפרטיות — זה בדיוק סוג האירוע שאף עסק לא רוצה לגלות שהוא היה שותף לו בלי לדעת.
דרך אגב, אחת המסקנות מהתחקיר נגעה דווקא ללוגים: ככל שרזולוציית הלוגים ההיסטוריים גבוהה יותר, כך קל יותר לכמת חשיפה בדיוק. זו בדיוק הנקודה שעליה כתבנו במאמר לך תחקור אירוע סייבר כשאין לך לוגים! — ושבגללה שמירת לוגים היא גם דרישה רגולטורית וגם צורך מבצעי.
אז מה לוקחים מזה? (הצ'קליסט)
שבעה דברים לעשות השבוע:
- ספרו את התוספים בלי רישיון. כל תוסף מסחרי שמותקן אצלכם בלי מפתח רישיון תקף — או שקניתם אותו ושכחתם להפעיל, או שהוא לא באמת שלכם. שני המצבים דורשים בדיקה.
- תוסף שלא מציג עדכון הוא דגל אדום, לא "תוסף יציב". בדקו האם הוא באמת EOL או שפשוט מנותק ממנגנון העדכונים.
- אל תסתפקו בניקוי — תחקרו. אם מחקתם קובץ זדוני ולא יודעים איך הוא הגיע, לא סיימתם.
- ודאו שהסריקה מכסה גם קבצי Cache, לא רק PHP. כאן זו הייתה הנקודה הקריטית.
- שמרו לוגים. 90 יום זה מינימום מבצעי, והרגולציה הישראלית דורשת יותר.
- עדכנו את תוספי ההאצה עצמם. גרסה בת שנים של תוסף Cache היא לא רק פער אבטחה — היא גם מנגנון שמנציח בעיות.
- אם אתם לא בטוחים מה מותקן אצלכם — תשאלו. אנחנו פה בשביל זה 🙂
המשפט שחוזר על עצמו
אנחנו רואים את זה שוב ושוב: מישהו לוחץ על "הורד" באיזה אתר שמציע תוסף של 800 שקל בחינם, מתקין, האתר עובד יפה, הלקוח מרוצה, כולם ממשיכים הלאה. אף אחד לא בודק. אין סיבה לבדוק — הרי הכול עובד.
אבל תוסף פרוץ הוא לא "אותו תוסף בלי תשלום". הוא תוסף שמישהו פתח, ערך, וארז מחדש. אותו מישהו עשה את זה בשביל להרוויח. אם לא שילמתם לו כסף, שילמתם לו במשהו אחר — ובמקרה הזה, שילמתם לו בגולשים שלכם.
זו בדיוק הסיבה שאנחנו חוזרים על זה בכל הזדמנות, כולל במאמרים על פרצות בליבת וורדפרס: שרשרת האספקה של האתר שלכם — התוספים, התבניות, הסקריפטים החיצוניים — היא משטח התקיפה האמיתי. לא הסיסמה.
איפה אנחנו נכנסים לתמונה
האתר הזה יצא מהאירוע נקי לא בגלל שמישהו שם לב בזמן, אלא בגלל שהתשתית שמתחתיו עושה דברים גם כשאף אחד לא מסתכל:
- Imunify360 סורק כל קובץ בכל חשבון, בכל חבילות האחסון שלנו, כולל תוצרי Cache.
- WAF חוסם דפוסי תקיפה ברמת השרת, ומקבל חתימות חדשות אחרי כל אירוע כזה.
- SOC 24/7 מחליט מה זה רעש ומה זה אירוע — גם ב-04:35 בשבת.
- SecOps מתחקר לעומק, מוציא תובנות, וממיר אותן לכללי הגנה רוחביים לכלל הלקוחות.
- וורדפרס מנוהל — עדכונים, גיבויים, סטייג'ינג וניטור, כדי שתוסף ישן לא יישאר ישן.
הלקוח סיים את היום עם אתר נקי, דוח תחקיר מלא, ורשימת פעולות ברורה. בלי השבתה, בלי כופר, ובלי שיחת טלפון מבוהלת — כי הטיפול הסתיים לפני שהוא בכלל ידע שמשהו קרה.
יש לכם תוסף שאתם לא בטוחים מאיפה הוא הגיע?
אנחנו נבדוק. סריקה, תחקור ותוכנית טיפול — על ידי צוות שעושה את זה כל יום, על עשרות אלפי אתרים.
פרטי הלקוח, שם הדומיין, שם התוסף המדויק, שם השרת, כתובות ה-IP וכתובת התשתית הזדונית הוסרו מהמאמר. הלקוח עודכן במלוא הפרטים במסגרת האירוע.
לקריאה נוספת בבלוג: מה זה בעצם WAF? · Object Cache – מה באמת צריך? · wp2shell: הפרצה שדחפה עדכון בכוח למיליוני אתרים · ההסמכות שמאחורי התשתית · וורדפרס מנוהל ב-SPD
