העמוד מציע כלי שימושי למק, קורא לו "macOS toolkit", ומסביר בשלוש שורות איך מתקינים אותו: מעתיקים את הטקסט שמופיע על המסך, פותחים Terminal, מדביקים, מקישים Enter. אין CAPTCHA, אין חלון אימות, ואין שום דבר על המסך שנראה שבור או דחוף. חוקר Unit 42 בראד דנקן עשה בדיוק את זה במעבדה שלו ב-5 באוגוסט, ופרסם את התיעוד ב-16 בספטמבר.

מה שיושב בסוף השרשרת הוא AMOS, נוזקת גניבת מידע ל-macOS. הפרט שהופך את התיעוד למעניין הוא לא הנוזקה עצמה אלא מה שנמצא בקובץ ה-zip שהיא בנתה לעצמה ב-/tmp לפני השליחה: תיקיות בשמות aws, gcloud, docker ו-filezilla, וקובץ zsh_history. המכונה שעליה זה רץ הייתה התקנה נקייה, בלי אפליקציה אחת נוספת. כלומר התיקיות האלה הן לא מה שנמצא על המחשב, אלא מה שחיפשו עליו. בהמשך נעבור על איך הלוכד עובד, למה Unit 42 מתעקשת שזה לא ClickFix, איפה הנוזקה מתמקמת, ומה בדיוק היא מדווחת הלאה.

למה זה לא ClickFix, ולמה ההבדל משנה

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

מה שקרה כאן שונה, ו-Unit 42 אומרת את זה במפורש: אף שקמפיינים כאלה מתוארים לפעמים כ-ClickFix, זה לא באמת ClickFix. אין CAPTCHA מזויף ואין הזרקה ללוח ההעתקה. יש עמוד הוראות התקנה שנראה סביר, והמשתמש מסמן את הטקסט ומעתיק אותו בידיים שלו.

ההבדל הוא לא סמנטי. מי שאומן לחשוד בדף אימות שמבקש להדביק פקודה לא בהכרח יחשוד בדף הוראות התקנה של כלי עבודה, וזה בדיוק הפער. Unit 42 ראתה את AMOS מופצת גם בקמפייני ClickFix אמיתיים, גם דרך מודעות, וגם באתרים שמציעים גרסאות פרוצות של תוכנות בתשלום. לפי היומן שדנקן פרסם ב-SANS ISC על הדבקה מוקדמת יותר, ב-31 ביולי, הגלישה הגיעה לאותו עמוד לוכד דרך שני דומיינים אחרים שהפנו אליו, מה שמתאים להפניה ממודעה ולא לחיפוש ישיר.

מה הפקודה שהודבקה עושה בפועל

הפקודה מורידה קובץ script של zsh בגודל 1,991 בתים משרת בשם ferncore13[.]com. בתוך ה-script יושב טקסט מקודד base64, ובתוכו קובץ דחוס ב-GZIP. הפריסה שלו מייצרת script שני, קטן אף יותר, שכל תפקידו הוא להוריד ולהריץ קובץ הרצה מקומפל למק בפורמט Mach-O. הקובץ הזה, המתקין של AMOS, נשמר כ-/tmp/helper ושוקל 330,768 בתים. הוא בנוי כ-universal binary, כלומר מכיל גם גרסת x86_64 וגם גרסת ARM64, כדי לרוץ גם על מקים עם מעבדי אינטל וגם על אלה עם שבבי אפל.

יש שם פרט קטן ששווה עצירה. בין הכתובות שחולצו מהמטען מופיעה קריאה לשרת שהפרמטר שלה הוא event=pasted. כלומר המפעילים סופרים כמה אנשים באמת הדביקו את השורה בטרמינל. (ומאותו מבנה כתובות בדיוק, api/metrics/run, בנויה גם התקשורת עם שרת השליטה, כך שמדידת יעילות הקמפיין והדיווח על הקורבן רצים על אותה תשתית.)

הנקודה שבה macOS אמור לעצור את כל זה מגיעה רגע אחר כך: המערכת מבקשת את סיסמת המשתמש. במעבדה של Unit 42 החשבון היה חשבון עם הרשאות מנהל, הסיסמה הוזנה, וההדבקה המשיכה משם. אחריה ביקש תהליך ה-Terminal ארבע הרשאות נפרדות, שליטה ב-Finder, גישה לקבצים בתיקיית Desktop, גישה לקבצים בתיקיית Documents, ושליטה באפליקציית Notes. כל אחת מהן הופיעה בחלון אישור רגיל של המערכת, כמו כל בקשת הרשאה של אפליקציה לגיטימית.

שמות שנראים כמו רכיבים של אפל

הנוזקה לא נשארת ב-/tmp. Unit 42 מצאה שתי תיקיות חדשות תחת Library/Application Support של המשתמש, אחת בשם .com.apple.accountsd והשנייה בשם .com.apple.metadata.mds. בכל אחת מהן יושב זוג קבצים: script של shell שמריץ קובץ Mach-O שמונח לידו. בראשונה זה AccountsHelper בגודל 438,576 בתים, בשנייה mdworker_shared בגודל 568,368 בתים. השמות לא נבחרו באקראי, accountsd ו-mdworker_shared הם שמות של רכיבי מערכת אמיתיים ב-macOS, והנקודה שבתחילת שם התיקייה מסתירה אותה מהתצוגה הרגילה ב-Finder וב-ls.

על הכפילות עצמה כדאי דווקא להיזהר. ביומן על ההדבקה מ-31 ביולי כתב דנקן שהוא הריץ את הטקסט ב-Terminal פעמיים, כדי להספיק להעתיק קבצים מ-/tmp לפני הזנת הסיסמה, ושזו כנראה הסיבה שנוצרו אצלו שתי תיקיות שבהן הנוזקה נשארת. התיעוד החדש לא חוזר על ההסבר הזה ולא שולל אותו, ולכן אין כאן בסיס לקבוע ששני עותקים הם חלק מהתכנון של הנוזקה.

מה נכנס ל-out.zip

את החומר שהיא אוספת הנוזקה מרכזת ב-/tmp ודוחסת לקובץ בשם out.zip. המבנה שבתוכו הוא הדבר הקרוב ביותר לרשימת הקניות של המפעילים: תיקייה deskwallets עם תיקיות משנה לארנקי Binance ו-TonKeeper, תיקייה FileGrabber עם התיקיות aws, docker, filezilla ו-gcloud, קובץ zsh_history, תיקייה בשם Telegram Data, וקבצים בשמות info ו-username.

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

לרקע, Sophos סקרה את המשפחה ומתארת אותה כנוזקה שנמכרת כשירות (malware-as-a-service), כלומר מפעילים שונים קונים גישה לאותה תוכנה ומריצים איתה קמפיינים משלהם. לפי נתוני Sophos, AMOS הייתה אחראית לכמעט 40% מעדכוני ההגנה שהחברה הוציאה ל-macOS במהלך 2025. Sophos מציינת שהנוזקה מכוונת לנתוני ה-Keychain של המערכת, לפרטי אימות ול-cookies מהדפדפנים, ולמידע על ארנקי קריפטו. לפי Unit 42, AMOS מוצעת למכירה בטלגרם כבר מאפריל 2024.

הדיווח לשרת בנוי לפי שלבים

התקשורת שאחרי ההדבקה היא בעיקר בקשות HTTP POST לשרת שליטה ובקרה (C2, השרת שדרכו התוקף מקבל את המידע ושולח פקודות לנוזקה) בכתובת 161.35.146[.]120. הכתובות שאליהן נשלחות הבקשות נגמרות כולן בפרמטר stage, והרשימה שלו נקראת כמו יומן התקדמות: boot, init_session, messengers, credentials, browsers, wallets, resolve_auth, local_data. במקום לשלוח הכול בבת אחת בסוף, הנוזקה מדווחת לשרת בסיום כל שלב איסוף בנפרד.

ההשוואה להדבקה מ-31 ביולי היא מה שהופך את זה לשימושי. שם, לפי היומן ב-SANS ISC, תבנית הכתובות הייתה זהה, כולל אותם שמות שלבים ואותו api/metrics/run, אבל ה-C2 היה כתובת אחרת לגמרי, 188.166.78[.]138, ושרת ההורדה הראשוני היה דומיין אחר. בחמישה ימים בלבד התחלפו הדומיין, כתובת ה-IP, ה-hashes וגדלי הקבצים. מה שלא התחלף הוא צורת הפעולה.

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

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

עבור מי שמנהל מקים בארגון, הערך של התיעוד הזה הוא לא ברשימת הכתובות שבסופו. הוא בצורה של השרשרת: תהליך Terminal שמוריד script, מפרסר ממנו base64, כותב קובץ הרצה ל-/tmp ואז מייצר תיקייה מוסתרת תחת Library/Application Support הוא רצף שאפשר לחפש גם כששמות הקבצים וה-hashes מתחלפים כל שבוע. אם יש אצלכם מק שעליו יושבים פרטי אימות לענן, כדאי להניח שהם היעד, ולבדוק אם ההרשאות שהמכונה הזאת מקבלת בענן רחבות יותר ממה שהיא באמת צריכה. והשורה שהמשתמש מדביק בטרמינל היא עדיין הרגע היחיד בשרשרת שבו אדם יכול לעצור את כל זה.