כשהתוכנה המוכרת הופכת למלכודת: מתקפת Axios ואפליקציות Claude המזויפות

הגרסאות שנפגעו היו זמינות במשך כשלוש שעות. קבוצת Google Threat Intelligence תיעדה פעילות בין 00:21 ל־03:20 לפי UTC ב־31 במרץ, ודיווחים אחרים מתארים חלון חשיפה דומה של שעתיים עד שלוש שעות. Axios היא תלות בעלת תפוצה רחבה במיוחד: דיווחים שונים מעריכים את מספר ההורדות השבועיות שלה ב־npm בכ־80 מיליון ועד יותר מ־100 מיליון, בהתאם למקור.

כיצד נוצל חשבון המתחזק?

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

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

מה עשתה התלות הזדונית?

plain-crypto-js@4.2.1 הוסוותה כתלות רגילה, אך בפועל נועדה להריץ סקריפט postinstall. הסקריפט פנה לשרת פיקוד ושליטה והוריד מטען המשך המותאם למערכת ההפעלה של המחשב.

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

npm install

האם BlueNoroff עמדה מאחורי המתקפה?

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

לכן אין להציג את ההערכות האלה כמסקנה מאומתת אחת. דמיון בקוד, בתשתית ובשיטות פעולה יכול לספק כיוון לחקירה, אך אינו מוכיח לבדו איזו קבוצה ביצעה את המתקפה. המסקנה הזהירה היא שהאירוע כלל השתלטות על חשבון מתחזק, גרסאות מורעלות ו־RAT חוצה־פלטפורמות; זהות התוקף עדיין שנויה במחלוקת בין ההערכות הציבוריות.

כיצד SilverFox השתמשה באפליקציות Claude מזויפות?

SilverFox בחרה נתיב חדירה אחר: הפצת אפליקציות Claude מזויפות עבור Windows, macOS ו־Linux. הקמפיין כוון לארגונים בתחומי התעשייה, הייעוץ, המסחר והתחבורה בהודו, באינדונזיה, בדרום אפריקה וברוסיה.

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

מהודעות פישינג בנושא מס ועד לפיתוי של כלי AI

הקמפיין נשען גם על פעילות פישינג קודמת בנושא מיסים. בינואר ובפברואר 2026 תיעדו חוקרים יותר מ־1,600 הודעות דוא״ל זדוניות שהתחזו להודעות רשמיות על ביקורת מס או טענו שהן כוללות רשימות של הפרות מס.

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

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

הלקח המשותף: האמון הוא חלק ממשטח התקיפה

שתי המתקפות פגעו במערכות אמון שונות:

• אמון במתחזק: גרסאות Axios נראו כאילו פורסמו דרך מפרסם npm מורשה.
• אמון בתלות: מנהל החבילות התייחס לתלות הזדונית כחלק מנתיב התקנה רגיל.
• אמון במותג: מתקיני Claude המזויפים שאלו את הזהות של מוצר AI מוכר.
• אמון בתהליך העבודה: מפתחים ועובדים ביצעו פעולות שגרתיות — עדכון תלויות או התקנת תוכנת פרודוקטיביות.

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

מה ארגונים צריכים לעשות עכשיו?

בכל הנוגע ל־Axios, יש לבדוק קובצי נעילה, מניפסטים של חבילות, יומני בנייה, מטמונים ומלאי תלויות עבור axios@1.14.1, axios@0.30.4 ו־plain-crypto-js@4.2.1. יש לחקור כל מחשב שבו הותקנה אחת מהגרסאות שנפגעו במהלך חלון החשיפה, ולבדוק אם הורדו אליו מטענים נוספים, אם נוצרה התמדה לא מורשית ואם נחשפו פרטי גישה. ההמלצות הרשמיות מדגישות שיש להתייחס להתקנות שנפגעו כאל התקנות שעלולות להיות נגועות.

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

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