האקרים המקושרים לרוסיה הופכים את ההתחברות לגוגל ולוואטסאפ למלכודת דיוג

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

מה עשתה כל אחת מהקבוצות?

UNC6293: התחזות, סיסמאות ייעודיות ו־OAuth

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

GTIG תיארה גם דיוג של הסכמה ל־OAuth, שבו התוקפים מנסים להשיג אסימוני גישה בהרשאה מהמשתמש, במקום לגנוב ממנו ישירות את הסיסמה.

ב־GTIG העריכו ברמת ביטחון בינונית כי UNC6293 היא תת־קבוצה המתמקדת בגישה ראשונית, השייכת ל־ICE RELIC — השם של Google לשחקן שנודע בעבר כ־APT29.

UNC7005, המוכרת גם כ־STORM-2945: וואטסאפ ופיתיונות מדורגים

UNC7005 השתמשה במגוון מתרחב של שיטות, ובהן:

• הונאות קישור מכשירים בוואטסאפ: הקורבנות שוכנעו לקשר לחשבון שלהם מכשיר שנשלט בידי התוקפים.
• שיחות קוליות מזויפות והזמנות לצ'אטים מוצפנים: האינטראקציות נועדו לבנות אמון לפני שליחת קישור או קוד זדוני.
• התחזות לתקשורת ארגונית: הודעות שנקשרו למרכז המבצעים הפיני שימשו לצד אתרי התחברות מזויפים של Microsoft.
• גניבת אסימוני OAuth והפצת נוזקות: הקבוצה השתמשה בזרימות OAuth של Google כדי להשיג אסימונים או גישה לחשבונות, ובמקביל הפיצה נוזקות גניבת מידע כמו VIDAR ו־ATOMIC.

הטכניקות והתשתיות של UNC7005 שונות מאלה של UNC6293. לכן GTIG עוקבת אחריהן כפעילויות נפרדות, אף שהמטרות וההסתמכות על תהליכי אימות לגיטימיים חופפות.

UNC5976: דיוג OAuth נגד יעדים ביטחוניים

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

מה אמרה Google על הקשר לרוסיה?

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

בדיווחים קיימים גם תיאורים של קשרים אפשריים בין חלק מהפעילות לבין ICE RELIC/APT29. הקישור של UNC6293 ל־ICE RELIC הוערך ברמת ביטחון בינונית, והקבוצות ממשיכות להיספר בנפרד משום שהטכניקות והתשתיות שלהן אינן זהות.

מדוע אימות רב־שלבי לבדו אינו מספיק?

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

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

ההגנות שממליצה Google

ההמלצות של GTIG מתמקדות בהאטת התהליך שהתוקפים מנסים לזרז:

• בדקו את כתובת הדפדפן המלאה לפני התחברות או אישור הרשאת OAuth.
• אמתו הזמנות ובקשות בערוץ נפרד: בדקו באופן עצמאי הזמנות לכנסים, שיחות, פניות בצ'אטים מוצפנים והודעות שמתיימרות להגיע מגורמי ממשל או מארגונים. השתמשו בפרטי קשר מוכרים, ולא באלה שמופיעים בהודעה החשודה.
• לעולם אל תמסרו סיסמה ייעודית לאפליקציה, קוד אימות חד־פעמי, קוד QR או קוד לקישור מכשיר. אל תאשרו התחברות או הרשאת OAuth שלא יזמתם.
• בדקו באופן קבוע את המכשירים המקושרים בוואטסאפ ובאפליקציות מסרים אחרות, והסירו מכשירים שאינכם מזהים.
• העדיפו אימות רב־שלבי עמיד בפני דיוג: ארגונים צריכים להעדיף מפתחות אבטחה או מפתחות גישה (passkeys), ולהגביל ככל האפשר אפליקציות OAuth מסוכנות ושימוש בסיסמאות ייעודיות לאפליקציות.

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