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

שתי גרסאות, שתי שיטות שליטה

הגרסה המוקדמת: שרת HTTP ותקשורת תכופה

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

ביקון הזיהוי של הנוזקה כולל פרטים כגון:

• שם המשתמש ב-Windows;
• שם המחשב ברשת ה-DNS;
• מזהה התהליך שבו פועלת C2Looper;
• מזהה בוט שנגזר משם המחשב ומשם המשתמש.

הביקון נשלח לנתיב /api/beacon, ותוצאות הפקודות מדווחות דרך /api/result/.

מערך הפקודות מעניק למפעיל שליטה מעשית במחשב הנגוע, ובכלל זה:

• הרצת פקודות Shell או פקודות מערכת לבחירת התוקף;
• איסוף מידע על מערכת ההפעלה, התהליכים והסביבה;
• הורדת קבצים;
• עדכון הנוזקה והפעלת מטענים נוספים.

עדכון עצמי באמצעות טעינת DLL דרך OneDrive

אחד המנגנונים הבולטים הוא פקודת upload. באמצעותה הנוזקה מורידה קובץ הרצה נייד מכתובת שמספק המפעיל ושומרת אותו כקובץ DLL בתיקיית OneDrive המקומית של המשתמש. בדגימות שדווחו, הקובץ נקרא wtsapi32.dll ונשמר תחת %LocalAppData%\\Microsoft\\OneDrive. לאחר מכן הנוזקה יכולה לעצור את תהליך OneDrive ולהשתמש בקובץ OneDrive לגיטימי כדי לטעון את הספרייה הזדונית באמצעות DLL sideloading — טעינת DLL זדוני לצד תוכנה לגיטימית.

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

מנגנוני התחמקות בדגימות המוקדמות

C2Looper מפענחת מחרוזות בזמן הריצה באמצעות XOR, לפי הדיווחים בעזרת מפתח בן שמונה בתים שנעשה בו שימוש חוזר. היא גם מאתרת באופן דינמי ממשקי API של Windows באמצעות LoadLibrary ו-GetProcAddress. שיטות אלה עלולות להפוך בדיקה סטטית פשוטה לפחות יעילה, ולכן מגדילות את החשיבות של ניטור התנהגותי באמצעות כלי EDR.

הגרסה החדשה: GitHub כתשתית שליטה

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

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

השימוש ב-GitHub עלול להקשות על חסימה המבוססת רק על שמות דומיין, משום שהשירות משמש גם מפתחים, צוותי IT ותהליכי CI/CD לגיטימיים. לכן ההגנה צריכה להתמקד בהתנהגות: יש לבדוק גישה מחזורית למאגרים או ל-API של GitHub מתחנות שאינן אמורות להשתמש בהם, ולבחון פעילות JSON חוזרת לפי מחשב. אין לחסום את GitHub באופן גורף.

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

חשד להדבקה באמצעות ClickFix

ThreatLabz מעריך ברמת ביטחון נמוכה עד בינונית כי C2Looper עשויה להיות מופצת באמצעות שרשרת הדבקה רב-שלבית מסוג ClickFix. בקמפיינים כאלה המשתמש נתקל בחלון אימות מזויף, הודעת שגיאה בדפדפן, CAPTCHA או הודעה שמתחזה לתיקון תקלה במערכת. לאחר מכן הוא מתבקש להעתיק ולהריץ פקודה ב-PowerShell, בחלון Run של Windows או בממשק פקודות אחר.

זהו גם אחד המקומות החשובים ביותר לעצירה מוקדמת של התקיפה. אתר אינטרנט, דפדפן או הודעת CAPTCHA אינם אמורים לבקש מהמשתמש להדביק פקודות ב-PowerShell, ב-Terminal או בחלון Run כדי להשלים אימות או תיקון.

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

מה ארגונים צריכים לנטר

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

• ביקוני HTTP תכופים: יש לבדוק תעבורת POST ב-JSON שחוזרת במרווחים קבועים, במיוחד בקשות המזכירות את /api/beacon או /api/result/, כאשר היא קשורה לתהליך חדש או חשוד.
• פעילות GitHub חריגה: יש לחפש גישה של תחנות קצה למאגרים או ל-API של GitHub בדפוס מחזורי, ובפרט תיקיות לפי מחשב הכוללות cmd.json ו-result.json. יש להחריג שימושים לגיטימיים של פיתוח ואוטומציה, ולא לחסום את GitHub indiscriminately — באופן גורף.
• טעינת DLL דרך OneDrive: יש להתריע כאשר קובץ OneDrive לגיטימי מופעל מנתיב חריג בפרופיל המשתמש, טוען DLL מתיקייה סמוכה שניתנת לכתיבה או יוצר תהליכי-בת לא צפויים.
• הרצת פקודות וסריקת מערכת: טלמטריית EDR יכולה לזהות פעילות חשודה של PowerShell, cmd.exe, חלון Run, סריקת מערכת, הורדות מדורגות והרצת Shell מקבצים שלא נראו בעבר.
• שילוב מאפיינים של נוזקת Rust: אין להסתמך על מאפיין יחיד. יש לחפש יחד רזולוציה דינמית של ממשקי API, מחרוזות מוצפנות, תקשורת מחזורית והפעלת מטענים.

צעדי מניעה מרכזיים

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

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

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

השורה התחתונה

המשמעות של C2Looper אינה רק בהיותה דלת אחורית חדשה, אלא בהתפתחות שלה: ממנגנון HTTP פשוט יחסית לנוזקה גמישה יותר, שיכולה להשתמש במאגרי GitHub כתשתית תפעולית. יכולות השליטה מרחוק, הסריקה, ההורדה והעדכון הופכות אותה לנקודת אחיזה אפשרית במתקפות הקשורות לכופרה — אך הראיות הקיימות מצדיקות הערכה זהירה, לא ייחוס חד-משמעי. ההגנה היעילה ביותר משלבת תהליכי עבודה עמידים בפני ClickFix עם ניטור התנהגותי של הרצת פקודות, טעינת DLL דרך OneDrive, ביקוני HTTP מהירים ופעילות GitHub שאינה מוסברת.

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

שתי גרסאות, שתי שיטות שליטה

הגרסה המוקדמת: שרת HTTP ותקשורת תכופה

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

ביקון הזיהוי של הנוזקה כולל פרטים כגון:

• שם המשתמש ב-Windows;
• שם המחשב ברשת ה-DNS;
• מזהה התהליך שבו פועלת C2Looper;
• מזהה בוט שנגזר משם המחשב ומשם המשתמש.

הביקון נשלח לנתיב /api/beacon, ותוצאות הפקודות מדווחות דרך /api/result/.

מערך הפקודות מעניק למפעיל שליטה מעשית במחשב הנגוע, ובכלל זה:

• הרצת פקודות Shell או פקודות מערכת לבחירת התוקף;
• איסוף מידע על מערכת ההפעלה, התהליכים והסביבה;
• הורדת קבצים;
• עדכון הנוזקה והפעלת מטענים נוספים.

עדכון עצמי באמצעות טעינת DLL דרך OneDrive

אחד המנגנונים הבולטים הוא פקודת upload. באמצעותה הנוזקה מורידה קובץ הרצה נייד מכתובת שמספק המפעיל ושומרת אותו כקובץ DLL בתיקיית OneDrive המקומית של המשתמש. בדגימות שדווחו, הקובץ נקרא wtsapi32.dll ונשמר תחת %LocalAppData%\\Microsoft\\OneDrive. לאחר מכן הנוזקה יכולה לעצור את תהליך OneDrive ולהשתמש בקובץ OneDrive לגיטימי כדי לטעון את הספרייה הזדונית באמצעות DLL sideloading — טעינת DLL זדוני לצד תוכנה לגיטימית.

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

מנגנוני התחמקות בדגימות המוקדמות

C2Looper מפענחת מחרוזות בזמן הריצה באמצעות XOR, לפי הדיווחים בעזרת מפתח בן שמונה בתים שנעשה בו שימוש חוזר. היא גם מאתרת באופן דינמי ממשקי API של Windows באמצעות LoadLibrary ו-GetProcAddress. שיטות אלה עלולות להפוך בדיקה סטטית פשוטה לפחות יעילה, ולכן מגדילות את החשיבות של ניטור התנהגותי באמצעות כלי EDR.

הגרסה החדשה: GitHub כתשתית שליטה

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

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

השימוש ב-GitHub עלול להקשות על חסימה המבוססת רק על שמות דומיין, משום שהשירות משמש גם מפתחים, צוותי IT ותהליכי CI/CD לגיטימיים. לכן ההגנה צריכה להתמקד בהתנהגות: יש לבדוק גישה מחזורית למאגרים או ל-API של GitHub מתחנות שאינן אמורות להשתמש בהם, ולבחון פעילות JSON חוזרת לפי מחשב. אין לחסום את GitHub באופן גורף.

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

חשד להדבקה באמצעות ClickFix

ThreatLabz מעריך ברמת ביטחון נמוכה עד בינונית כי C2Looper עשויה להיות מופצת באמצעות שרשרת הדבקה רב-שלבית מסוג ClickFix. בקמפיינים כאלה המשתמש נתקל בחלון אימות מזויף, הודעת שגיאה בדפדפן, CAPTCHA או הודעה שמתחזה לתיקון תקלה במערכת. לאחר מכן הוא מתבקש להעתיק ולהריץ פקודה ב-PowerShell, בחלון Run של Windows או בממשק פקודות אחר.

זהו גם אחד המקומות החשובים ביותר לעצירה מוקדמת של התקיפה. אתר אינטרנט, דפדפן או הודעת CAPTCHA אינם אמורים לבקש מהמשתמש להדביק פקודות ב-PowerShell, ב-Terminal או בחלון Run כדי להשלים אימות או תיקון.

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

מה ארגונים צריכים לנטר

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

• ביקוני HTTP תכופים: יש לבדוק תעבורת POST ב-JSON שחוזרת במרווחים קבועים, במיוחד בקשות המזכירות את /api/beacon או /api/result/, כאשר היא קשורה לתהליך חדש או חשוד.
• פעילות GitHub חריגה: יש לחפש גישה של תחנות קצה למאגרים או ל-API של GitHub בדפוס מחזורי, ובפרט תיקיות לפי מחשב הכוללות cmd.json ו-result.json. יש להחריג שימושים לגיטימיים של פיתוח ואוטומציה, ולא לחסום את GitHub indiscriminately — באופן גורף.
• טעינת DLL דרך OneDrive: יש להתריע כאשר קובץ OneDrive לגיטימי מופעל מנתיב חריג בפרופיל המשתמש, טוען DLL מתיקייה סמוכה שניתנת לכתיבה או יוצר תהליכי-בת לא צפויים.
• הרצת פקודות וסריקת מערכת: טלמטריית EDR יכולה לזהות פעילות חשודה של PowerShell, cmd.exe, חלון Run, סריקת מערכת, הורדות מדורגות והרצת Shell מקבצים שלא נראו בעבר.
• שילוב מאפיינים של נוזקת Rust: אין להסתמך על מאפיין יחיד. יש לחפש יחד רזולוציה דינמית של ממשקי API, מחרוזות מוצפנות, תקשורת מחזורית והפעלת מטענים.

צעדי מניעה מרכזיים

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

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

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

השורה התחתונה

המשמעות של C2Looper אינה רק בהיותה דלת אחורית חדשה, אלא בהתפתחות שלה: ממנגנון HTTP פשוט יחסית לנוזקה גמישה יותר, שיכולה להשתמש במאגרי GitHub כתשתית תפעולית. יכולות השליטה מרחוק, הסריקה, ההורדה והעדכון הופכות אותה לנקודת אחיזה אפשרית במתקפות הקשורות לכופרה — אך הראיות הקיימות מצדיקות הערכה זהירה, לא ייחוס חד-משמעי. ההגנה היעילה ביותר משלבת תהליכי עבודה עמידים בפני ClickFix עם ניטור התנהגותי של הרצת פקודות, טעינת DLL דרך OneDrive, ביקוני HTTP מהירים ופעילות GitHub שאינה מוסברת.