מתקפות סייבר יצירתיות מחייבות שינוי פרדיגמה בניהול סיכוני הסייבר

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

במקום לתקוף את תחנת הקצה של העובד, קבוצות תקיפה עוקפות את כל שכבות ההגנה המקומיות – כולל אימות דו-שלבי או רב-שלבי (MFA) – ונכנסות ישר לתוך סביבות העבודה הענניות דוגמת Microsoft 365, Google Workspace או AWS. רוב אמצעי הזיהוי האוטומטיים לא מצליחים לזהות את הפריצה, והיא נראית לגיטימית לחלוטין במערכות ניהול הזהויות – משום שההרשאות ניתנו "בהסכמת המשתמש" (לפחות כך המערכת רואה זאת). ממצאים שפורסמו באפריל 2025 על ידי חברת Volexity ממחישים את האיום. בקמפיין שהופעל על ידי גורמים המזוהים עם ממשלת רוסיה, הותקפו ארגונים הקשורים לאוקראינה, זכויות אדם וקהילות מודיעיניות.

כיצד מתבצעת הפריצה לחשבון
המתקפה מתחילה בדרך כלל בפנייה ישירה לקורבן, לרוב באמצעות אפליקציות מסרים מיידיים כמו וואטסאפ או סיגנל. בשלב זה, התוקפים מתחזים לגורם שמוכר או ידוע לקורבן – דוגמת נציג מארגון בינלאומי מכובד על מנת לבסס אמינות ראשונית.
לאחר יצירת הקשר הראשוני התוקפים שולחים לקורבן הזמנה לפגישה דחופה אונליין או בקשה לעיין במסמכים רלוונטיים שדורשים התייחסות מידית. כמובן, שכדי להשתתף בפגישה או לעיין במסמכים הקורבן מתבקש ללחוץ על קישור.
קישור זה מוביל את הקורבן לדף שנחזה לעמוד ההתחברות לחשבון המיקרוסופט של העובד, וכאן בא לידי ביטוי התחכום של המתקפה: במקום לגנוב את סיסמת המשתמש באופן ישיר, המתקפה מנצלת את מנגנון האימות OAuth – העמוד המתחזה יגרום לקורבן לאשר מתן הרשאות לאפליקציה שנמצאת למעשה בשליטת התוקפים.
מדובר בתכונה שמאפשרת לנו להתחבר לאתרים ושירותים רבים באמצעות חשבון הגוגל או הפייסבוק שלנו – במקום ליצור שם משתמש וסיסמה חדשים בכל פעם. ההבדל הקריטי הוא שבמתקפה זו, ה"אפליקציה" שמבקשת גישה היא זדונית, וההרשאות שהיא מבקשת נרחבות ומאפשרות גישה לתיבת המייל, לקבצים רגישים ועוד.
לאחר שהקורבן מאשר את ההרשאות לאפליקציה התוקפים מקבלים לידיהם "טוקן" (Access Token) שמאפשר להם גישה להודעות מייל, לקבצים ולעיתים גם לאפשרות להוסיף מכשירים מאומתים לענן הארגוני. כל זאת מבלי להשתמש בסיסמה של החשבון וללא כל צורך באימות רב שלבי.

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

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

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

צעדים ארגוניים מומלצים להגנה מפני מתקפות OAuth

• ניטור ואכיפה של הרשאות OAuth: כל אפליקציה חיצונית המקבלת גישה למשאבים ארגוניים חייבת להיבחן לפי קריטריונים מחמירים. יש לבצע סקירה תקופתית של האפליקציות המחוברות לכל משתמש, לבחון אילו הרשאות הוענקו ומתי, ולהסיר אפליקציות שאינן בשימוש. מערכות רבות מאפשרות הגדרת Allow/Block list – כלי חשוב במיוחד כאשר מדובר בארגונים עם אלפי משתמשים.
• איסור על שימוש ב-device code flow עבור משתמשים שאינם מוגדרים כ-administrators: זרימת device code נוחה במיוחד לתוקפים מכיוון שהיא מאפשרת הפעלת הרשאות על מכשיר אחר ללא צורך בהקלדת סיסמה. ניהול מדיניות OAuth צריך לכלול ניטור של כל OAuth grant לאפליקציה חדשה, עם התראה בזמן אמת על הרשאות חריגות.
• שימוש ב-Cloud Access Security Broker (ראשי תיבות CASB): מערכות CASB מודרניות מסוגלות לזהות מגמות שימוש חשודות, כגון הרשאות מלאות לאפליקציה שזה עתה נוספה, או גישה מקבילה ממשתמשים שונים ברחבי העולם. 
• שילוב כל מערך הענן בניתוח SIEM: לא רק לוגים של נקודות קצה. אם הארגון משתמש ב-Splunk, Exabeam או Sentinel, עליו לוודא שה-SIEM מקבל גם נתונים מהענן – כולל פעילויות OAuth, token issuance, והרשאות מתמשכות (persistent grants). 
• אכיפה ברורה של מדיניות least privilege גם ברמת OAuth: משתמשים לא אמורים לאשר אפליקציות המאפשרות קריאה וכתיבה לכל תיבת הדוא״ל או גישה מלאה ל-SharePoint – אלא אם כן מדובר בכלים פנימיים מאומתים. על מנהלי אבטחת מידע לדרוש מהמחלקות העסקיות להצדיק כל חיבור לאפליקציה חיצונית.
• הדרכות מודעות ממוקדות: יש לערוך הדרכות הכוללות הסבר על מנגנוני הרשאה ועל המשמעות של לחיצה על "Accept" בחלון הרשאות. עובדים רבים אינם מודעים לכך שלחיצה אחת מעניקה לתוקף גישה מקיפה, גם אם ההודעה לא נראית כמו פישינג מסורתי.

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

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