חוקרי XLab של QiAnXin פרסמו ב-17 ביולי ניתוח של בוטנט חדש שהם מכנים NadMesh, על שם המחרוזת "n4d mesh controller" שהתגלתה בקוד שלו. הוא כתוב ב-Go, הוא מפיץ את עצמו בלי שאף אדם יושב מולו ומכוון אותו, והוא מחפש דבר אחד בעדיפות גבוהה מכל השאר: שרתי בינה מלאכותית שנשארו פתוחים לאינטרנט.

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

למה דווקא שרתי AI

השנתיים האחרונות הכניסו לרשתות ארגוניות סוג חדש של שרת. ComfyUI הוא ממשק להרצת מודלים של יצירת תמונות, Ollama מריץ מודלי שפה מקומית, n8n הוא כלי אוטומציה שמחבר בין שירותים, ו-Gradio עוטף מודלים בממשק web מהיר. משותף לכולם שהם נועדו לעבוד מהר, לרוב הותקנו על ידי צוותי פיתוח או data science ולא על ידי מי שמנהל את אבטחת הרשת, ובברירת המחדל שלהם הם לא דורשים סיסמה.

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

Shodan כמנוע לאיתור מטרות

החלק שהכי מעיד על הכוונה נמצא ברכיב שהחוקרים מסמנים כ-ai_harvest.py. הוא לא סורק את האינטרנט בעצמו, אלא שולח שאילתות ל-API של Shodan, מנוע החיפוש שמאנדקס שרתים חשופים ברשת, ומבקש ממנו רשימות של מכונות שמריצות ComfyUI, Ollama, n8n, Open WebUI, Langflow ו-Gradio. את התוצאות הוא מזרים לתור הסריקה של הבוטנט בעדיפות הגבוהה ביותר שקיימת בו, priority=20.

כלומר הבוטנט לא נתקל בשרתי AI במקרה תוך כדי סריקה רחבה. הוא קונה את הרשימה שלהם מראש ורץ אליהם ראשון. מנוע הסריקה הרגיל שלו מכסה 30 פורטים, מהחשודים המיידיים כמו 2375 ו-2376 של Docker ו-6443, 10250 ו-2379 של Kubernetes, ועד 5432, 3306 ו-6379 של מסדי נתונים. בתוך הרשימה הזו ארבעה פורטים מקבלים יחס מיוחד בסבבי הסריקה החוזרים: 8188 של ComfyUI, 11434 של Ollama, 7860 של Gradio ו-5678 של n8n.

בנוסף מוטמעות במנוע יותר מ-90 טווחי כתובות של ספקי ענן, מה שמאפשר לו להתפשט בתוך רשתות ענן בלי הכוונה מבחוץ.

יותר מ-20 דרכי כניסה

לבוטנט יש ארסנל של מעל 20 שיטות להרצת קוד מרחוק, והוא מנסה אותן לפי מה שהוא מוצא. חלוקת התעבורה שהחוקרים מדדו מספרת סיפור מפוכח: ניצול של Docker API הוביל עם 30.31 אחוז, אחריו הרצת קוד ב-Jenkins עם 22.28 אחוז, סיסמאות Telnet חלשות עם 10.36 אחוז ו-Redis עם 8.29 אחוז. הווקטור שמכוון ל-MCP, הפרוטוקול שדרכו סוכני AI מדברים עם כלים חיצוניים, הופיע ב-0.78 אחוז בלבד.

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

השיטות עצמן מוכרות למי שמגן על תשתית containers, וזה בדיוק מה שהופך אותן ליעילות. מול Docker הבוטנט מרים container עם הרשאות רשת של המארח וגולש ממנו החוצה אל המכונה המארחת. מול Kubernetes הוא פונה ל-API ומבקש ליצור pod שממפה אליו ספרייה מהמארח עצמו דרך hostPath, מה שנותן לו קריאה וכתיבה למערכת הקבצים של השרת מתוך מה שאמור היה להיות סביבה מבודדת. מול Redis הוא משתמש ב-CONFIG SET כדי לגרום לשרת לכתוב קובץ למקום שיגרום להרצתו, ומול Elasticsearch הוא מנצל הרצת scripts. אף אחת מהטכניקות האלה אינה חדשה, אבל האוטומציה שמחברת את כולן לתור סריקה אחד היא כן.

לצד טעויות התצורה הבוטנט משתמש גם בחולשות מתועדות. שתיים מהן נמצאות ברשימת ה-KEV של CISA, רשימת החולשות שידוע שמנוצלות בשטח: CVE-2026-39987, חולשת הרצת קוד ללא אימות ב-Marimo שנוספה לרשימה ב-23 באפריל 2026, ו-CVE-2022-22947 ב-Spring Cloud Gateway, ותיקה מ-2022. לצידן משמשות גם CVE-2026-41176, עקיפת אימות בשרת ה-RC של rclone, ו-CVE-2017-12611 ב-Struts, חולשה בת תשע שנים.

מה הוא לוקח כשהוא נכנס

כאן מתבררת ההבדלה בין הבוטנט הזה לכורה מטבעות רגיל. NadMesh לא מגיע כדי לשרוף מעבד, הוא מגיע כדי לחלץ פרטי אימות. הוא קורא משתני סביבה ומחפש בהם ערכים כמו AWS_ACCESS_KEY_ID, הוא מושך את התוכן של ~/.aws/config ושל ~/.docker/config.json, הוא אוסף קבצי env. שמפתחים משאירים ליד הקוד, והוא לוקח token-ים של ServiceAccount מתוך אשכולות Kubernetes.

ה-token-ים האחרונים הם החלק המדאיג. ServiceAccount באשכול Kubernetes הוא זהות שירות, ואם ההרשאות שלו רחבות, מי שמחזיק ב-token שלו יכול ליצור ולהריץ containers חדשים באשכול. החוקרים מציינים שלוח הבקרה של המפעיל מציג במפורש את רמת ההרשאות של כל ServiceAccount שנתפס, מה שאומר שהוא ממיין את השלל לפי כמה עמוק הוא מגיע.

גם התוצרים של סביבת ה-AI עצמה נאספים. לפי הרשומות שהחוקרים בחנו, הבוטנט מתעד לאילו מודלים יש למכונה שנפרצה גישה, ובהם DeepSeek, GLM ו-Kimi. במילים אחרות, גישה בתשלום למודלים היא בעצמה פריט מלאי.

בוטנט שמנוהל כמו מוצר

הצד שמסביר את שם הדוח הוא הצד התפעולי. למפעיל יש ממשק web עם סטטיסטיקות המרה, כלומר הוא מודד כמה מהמכונות שהותקפו הפכו בפועל להתקנה פעילה. הוא מחזיק חמש גרסאות build במקביל ומגלגל עדכונים בשיטת canary, פרסום הדרגתי לקבוצה קטנה לפני החלה על הכלל. כל build עובר ערפול סמלים ומחרוזות בעזרת Garble, נדחס ב-UPX ברמה 9 ומקבל ריפוד אקראי, כך שלכל עותק יש hash שונה ואין חתימה אחת שתופסת את כולם.

"NadMesh הוא לא צירוף מקרי של script kiddie. זו נוזקה ברמה תעשייתית עם כוונה מסחרית ברורה", כתבו החוקרים. הנתונים שהם אספו תומכים בכך: מספר כתובות ה-IP הייחודיות שמהן נצפתה תקיפה עלה מכמעט אפס בסוף יוני לכ-139 ביום בתחילת יולי, ולוח הבקרה מדווח על 17,700 התקנות מצטברות.

גם התשתית שמחוץ למכונה הנגועה נבנתה כדי לא למשוך תשומת לב. שרת השליטה והבקרה (C2, השרת שדרכו התוקף שולח פקודות לתוכנה הזדונית) יושב על הכתובת 209.99.186.235, ולצידו נרשם דומיין ששמו נבחר בקפידה, cdnorigin.net. השם נועד להיראות בלוגים כמו תעבורה שגרתית אל רשת הפצת תוכן, סוג התעבורה שאיש רשת עסוק לא יעצור לבדוק פעמיים.

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

מה זה אומר בפועל

מי שמריץ בארגון ממשק AI כלשהו צריך לוודא קודם כול שהוא לא זמין ישירות מהאינטרנט, ובמיוחד בפורטים 8188, 11434, 7860 ו-5678. הכלים האלה נבנו לרשת פנימית ורובם לא מביאים איתם אימות בברירת המחדל.

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