Sapphire Sleet: כך נוזקות npm מסתירות שרתי שליטה בתוך עסקאות Ethereum ריקות

ציר הזמן של החבילות שנפגעו :

• typo-crypto — מרץ 2025: אמזון מעריכה שהפגיעה הראשונית שימשה ככל הנראה כניסוי, שאפשר לתוקפים לשפר את שיטות הפעולה שלהם לקראת מתקפות רחבות יותר .
• debug ו-chalk — ספטמבר 2025: שתי ספריות npm פופולריות במיוחד. ל-debug לבדה יש מיליארדי הורדות בשבוע. התוקפים התחזו לאתר npm באמצעות דומיין דומה, פישינג למתחזק החבילה, ולאחר מכן העלו קוד שרוקן ארנקי קריפטו לפחות ב-18 גרסאות זדוניות . לפי ההערכות, הפגיעה הגיעה לכ-10% מסביבות הענן בתוך שעתיים מפרסום הגרסאות .
• axios — מרץ 2026: ספריית HTTP מרכזית באקוסיסטם של JavaScript, עם יותר מ-70 מיליון הורדות שבועיות באותה תקופה . שתי גרסאות נגועות — v1.14.1 ו-v0.30.4 — הוסיפו תלות זדונית שפרסה סוס טרויאני לגישה מרחוק .

התוקפים שילבו הנדסה חברתית — יצירת קשר עם מתחזקי חבילות וגניבת פרטי התחברות — עם קוד שנוצר בסיוע בינה מלאכותית ונועד להקשות על מערכות גילוי . במקום לשנות ישירות את התנהגות הספרייה בזמן הריצה, הם הזריקו עדכונים שנראו לגיטימיים והפעילו בעת ההתקנה סקריפטים לגניבת מטבעות, סיסמאות ופרטי גישה .

גם Mastra AI נפגעה

ב-17 ביוני 2026 זיהתה Microsoft Threat Intelligence מתקפת שרשרת אספקה נפרדת נגד אקוסיסטם Mastra AI. התוקפים פרסמו 141 חבילות זדוניות בתוך חלון של 45 דקות, והמתקפה השפיעה על יותר מ-140 חבילות npm .

מיקרוסופט ייחסה את הפעילות ל-Sapphire Sleet ברמת ביטחון גבוהה. בעת התקנת החבילות הופעל hook מסוג post-install, שהוריד רכיב זדוני שנועד לגנוב אישורים, מפתחות API, אסימוני אימות וארנקי מטבעות קריפטוגרפיים .

NullReceiver: כתובת שרת שמסתתרת בעסקה ריקה

במחקר שפורסם ב-2–4 באוגוסט 2026 תיעדו חוקרי OpenSource Malware טכניקת פיקוד ושליטה חדשה בשם NullReceiver. היא נמצאה בשתי חבילות npm נוספות — bianira-ui@1.27.0 ו-fluid-type-ui@2.0.8 — שמתחזות לתוספים לגיטימיים של Tailwind CSS ומקושרות לקמפיין Contagious Interview .

כך פועלת השיטה :

1. הנוזקה כוללת בתוכה כתובת ארנק Ethereum קבועה: 0xa322e5f3d311d3080e6f0121063e9adc2490ef1a .
2. בזמן הריצה היא פונה לבלוקצ'יין ומאתרת את העסקה היוצאת האחרונה מאותו ארנק.
3. היא קוראת את כתובת היעד של העברת Ethereum שערכה אפס ושאינה כוללת נתוני עסקה.
4. הבייטים של כתובת היעד מפוענחים לכתובת ה-IP של שרת הפיקוד והשליטה הבא.

במילים פשוטות: במקום לשתול בקוד דומיין חשוד או כתובת IP קבועה, התוקפים משתמשים בכתובת יעד שנראית כמו חלק מעסקת קריפטו רגילה. אין בה payload מוסתר ואין בה סכום להעברה — אבל הכתובת עצמה מכילה את המידע שהנוזקה צריכה כדי למצוא את השרת הבא.

החוקרים מתארים את NullReceiver כהתפתחות של EtherHiding. בשיטות קודמות הוסתר המידע הזדוני בתוך נתוני העסקה או בחוזה חכם; כאן ה"סוד" הועבר לכתובת המקבלת של עסקה ריקה, מה שמצמצם את טביעת הרגל הסטטית ומקשה על זיהוי .

מה אומרים גופי הסייבר בעולם?

כמה מספקי המודיעין והאבטחה הגדולים הגיעו לייחוס דומה, אם כי ברמות ביטחון שונות:

• Amazon Threat Intelligence: קישרה את ארבע פגיעויות npm ל-Sapphire Sleet ברמת ביטחון בינונית, על בסיס אינדיקטורים משותפים של שרתי פיקוד ושליטה, שימוש חוזר בקוד, hooks של התקנה וטקטיקות דומות .
• Microsoft Threat Intelligence: ייחסה ברמת ביטחון גבוהה את מתקפת Mastra AI ל-Sapphire Sleet, וכן קישרה את הקבוצה למתקפת axios. מיקרוסופט תיעדה גם קמפיינים ממוקדי macOS שהשתמשו בפיתיונות הנראים כמו Microsoft Teams .
• Google Threat Intelligence: ייחסה את מתקפת axios לאותו גורם, שאותו היא עוקבת תחת השם UNC1069 .
• ממשלת ארצות הברית וגופי סייבר של מדינות בעלות בריתה: הזהירו בשנים האחרונות יותר ויותר מפני גניבת מטבעות קריפטוגרפיים בידי גורמים צפון־קוריאניים, בין היתר באמצעות פגיעה בשרשרת האספקה של תוכנות קוד פתוח . לפי TRM Labs, צפון קוריאה הייתה אחראית להערכת 76% מהשווי שנגנב בפריצות קריפטו בשנת 2026 — נתון שאינו מיוחס כולו למתקפות npm הללו .

במקורות שנבדקו לא נמצא פרסום רשמי וספציפי של ממשלת צפון קוריאה המכחיש את הטענות בנוגע ל-Sapphire Sleet או ל-NullReceiver. לכן אי אפשר לקבוע על סמך מערך הראיות הזה שנמסרה הכחשה ישירה לקמפיינים המסוימים הללו.

מה יכולים מפתחים וצוותי אבטחה לעשות?

NullReceiver ממחישה מדוע חסימת דומיינים וכתובות IP לבדה כבר אינה מספיקה. במקרה הזה אין בקוד כתובת שרת חשודה שאפשר לחסום מראש; הנוזקה מפיקה אותה בזמן אמת מהבלוקצ'יין.

ההמלצות המרכזיות שעלו מהמקורות כוללות :

• לתחזק SBOM — רשימת רכיבי התוכנה והתלויות — ולנטר שינויים בלתי צפויים בחבילות.
• להפעיל חלון הסגר: להימנע מהתקנת גרסאות שפורסמו ב-24–72 השעות האחרונות, כדי לאפשר זיהוי והסרה של גרסאות מורעלות לפני שהן נכנסות לבנייה.
• להשבית סקריפטים של מחזור החיים, כולל סקריפטי התקנה, כאשר הדבר אפשרי.
• להתקין גרסאות באופן דטרמיניסטי ולנעול את התלויות לגרסאות שנבדקו.
• להתייחס לחשד לפגיעה בתלות כאל אירוע אבטחה רחב יותר: לבודד מערכות, להחליף סודות ומפתחות גישה, לבדוק אישורים ואסימוני API, ולנטר פעילות המשך.

הלקח המרכזי הוא שהתקפה על חבילת קוד פתוח אינה נעצרת בהכרח במפתח או בספרייה שנפרצו. ברגע שהעדכון הזדוני נכנס לתהליך הבנייה, הוא עלול להפוך את מחשב המפתח, שרת ה-CI או סביבת הענן לנקודת זינוק למתקפות נוספות.