מניפולציה בחשבונות משתמשים (T1098)

מהי מניפולציה בחשבונות משתמשים?

מניפולציה בחשבונות משתמשים היא מצב שבו תוקף שכבר יש לו גישה לחשבון משנה אותו כדי לשמור על הגישה. MITRE ATT&CK מסווג אותה כ-T1098, על פני שבע תתי טכניקות - מפרטי הזדהות בענן ועד מכשירי MFA רשומים. מכיוון שהשינוי ממשיך לאפשר גישה גם אחרי החלפת הסיסמה, איפוס הסיסמה לבדו לא מסיר את התוקף.

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

שני תיקונים לפני הפרטים, כי בשניהם טועים לעתים קרובות. ראשית, זו לא טקטיקה אחת אלא שתיים: ATT&CK ממפה מניפולציה בחשבונות משתמשים לשמירה על גישה (Persistence) ולהסלמת הרשאות (Privilege Escalation). שנית, היא מניחה מראש שיש גישה. במילות MITRE עצמה, בתרגום חופשי: "על התוקף כבר להיות בעל הרשאות מספיקות במערכות או בדומיין" לפני שהוא יכול לבצע מניפולציה בחשבון בכלל.

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

הסבר כאילו אני בן 10

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

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

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

טעות אחת חוזרת כמעט בכל הסבר בנושא.

הדוגמה שכולם פונים אליה היא רישום טוקני MFA על ידי Scattered Spider. ההתנהגות הזו נראית כמו מניפולציה בחשבונות משתמשים, אבל המסמך המשותף של CISA ו-FBI שמתעד אותה לא ממפה אותה ל-T1098. הוא ממפה את רישום טוקן ה-MFA ל-T1556.006 ול-T1606, ואת ניצול ספק הזהויות המאוחד על ידי הקבוצה ל-T1484.002. המזהה T1098 לא מופיע במסמך הזה כלל. המסמך גם מציין שטקטיקת ה-federation טרם זוהתה כ-TTP נוכחי, ולכן אין להציג אותה כדפוס פעולה פעיל.

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

שבע תתי הטכניקות

מאז 2017 ATT&CK כבר לא מתייחס למניפולציה בחשבונות משתמשים כהתנהגות אחת. היא מפוצלת לשבע תתי טכניקות, ואלו מהן בכלל נגישות תלוי במה שרץ בסביבה.

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

שלוש מהן ראויות לפירוט מדויק:

• פרטי הזדהות נוספים בענן (T1098.001): תוקף מוסיף פרטי הזדהות ל-service principals ול-applications בנוסף לאלה התקפים הקיימים. application שפתאום מבצע הזדהות ממקום חדש הוא ממצא של שמירה על גישה (Persistence), לא תקלה בקונפיגורציה.
• מפתחות SSH מורשים (T1098.004): קובץ ה-`authorized_keys` במארחי Linux, macOS ו-ESXi, שבו שורה אחת שנוספה ממשיכה לאפשר גישה גם אחרי כל החלפת סיסמה.
• קבוצות מקומיות או domain נוספות (T1098.007): זה מגיע רחוק יותר מ-Domain Admins. MITRE מציינת קבוצות משתמשי VPN, וב-Linux את קבוצת ה-sudoers, ומציינת שגם חשבונות מחשב יכולים להתווסף לקבוצות domain.

שום דבר מכל זה לא נראה כמו נוזקה. זה מפתח שני בקובץ, משתמש נוסף עם גישה לתיבת דואר, חברות נוספת בקבוצה. עבודת תחזוקה, שמבצע מישהו שלא אמור לבצע אותה. זה גם הופך אותה לדבר גרוע לחיפוש באמצעות אינדיקטורים: פרטי הזדהות שנוספו מוחלפים בקלות, בעוד שההתנהגות של הוספתם לא, וזו ההבחנה שפירמידת הכאב (pyramid of pain) קיימת בשבילה.

רישום מכשיר, ולמה הוא מתחבר לכל השאר

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

ברגע שהמכשיר נרשם ב-Entra ID או ב-Intune, אפשר להשתמש בו כדי להגיע למשאבים תוך עקיפת מדיניות גישה מותנית. אפשר גם לשלוח דרכו spear phishing פנימי בדוא"ל ארגוני, שהלקוח המקבל נוטה פחות לזהות כחשוד.

זו הנקודה שבה מניפולציה בחשבונות משתמשים ו-MFA fatigue נפגשות. Prompt-bombing עוסק בהשגת אישור אחד ממשתמש; רישום אמצעי אימות שבשליטת התוקף עוסק בכך שלעולם לא יצטרכו לבקש אישור שוב.

איך מזהים מניפולציה בחשבונות משתמשים?

האות לטכניקה הזו נמצא בלוגי זהות וביקורת מערכת, לא ב-endpoint. לוג ההתחברות, לוג הביקורת של ה-directory, `auditd`, ה-unified log של macOS ולוג ה-admin של SaaS הם המקומות שבהם השינויים האלה נרשמים, וסוכן EDR לא יכלול את רובם.

MITRE מפרסמת אסטרטגיית זיהוי ייעודית לטכניקה, DET0096, עם שישה כללי זיהוי (analytics) המחולקים לפי פלטפורמה. הנה הם במונחים של המסגרת עצמה.

• Windows (AN0265): שינויים במאפייני חשבון כמו הגדרת סיסמה, חברות בקבוצה, `servicePrincipalName` ושעות התחברות, בקורלציה עם עץ תהליכים חריג או תזמון חריג. מקורות הלוג הם `WinEventLog:Security` עם מזהי אירוע 4738, 4728 ו-4670, בנוסף לאירוע 1 של Sysmon. מזהי האירוע כבר מופיעים בדפי הספקים; תנאי הקורלציה הוא מה שהופך אותם מרעש לזיהוי.
• ספק זהויות (IdP) (AN0268): שינויים במאפייני משתמש של SSO ו-SAML כמו `isAdmin`, תפקיד, עקיפת MFA והקצאות אפליקציות, שבוצעו דרך CLI, API או אפליקציות IdP לא מורשות. ב-Okta אלה מופיעים כאירועי User Attribute Modified ו-Role Assignment Changed. עבור רוב הקוראים זו השורה שחשובה.
• Linux (AN0266): שימוש ב-`usermod`, `passwd` או `groupmod` להסלמת הרשאות או לשמירה על גישה, בקורלציה עם אירועי התחברות או תהליכים, דרך רשומות syscall ו-path של `auditd` על `/etc/passwd` ו-`/etc/group`.
• macOS (AN0267): שינויי חשבון דרך `dscl`, `pwpolicy` או `sysadminctl` שמשנים קבוצות, מפעילים root או עוקפים MDM, ב-unified log.
• ESXi (AN0269): משתמשים חדשים או שינויי תפקיד כמו ReadOnly ל-Admin, במיוחד מכתובות שאינן jumpbox.
• SaaS (AN0270): הסלמת תפקיד כמו Editor ל-Owner בכלי שיתוף פעולה בענן, בלוג ה-admin המאוחד של Microsoft 365.

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

האם איפוס סיסמה מסיר את התוקף?

הוא מטפל בפרטי ההזדהות. הוא לא נוגע במה שנוסף לצידם.

אם עוברים על הרשימה שלמעלה, התבנית זהה בכל פעם. פרטי הזדהות שנוספו ל-service principal עדיין מאפשרים הזדהות. רשומה ב-`authorized_keys` עדיין מקבלת את המפתח שלה. משתמש נוסף עם גישה לתיבת הדואר עדיין קורא את תיבת הדואר. חברות בקבוצה עדיין מעניקה את מה שהקבוצה מעניקה. מכשיר רשום נשאר מכשיר רשום. אף אחד מאלה אינו הסיסמה, ולכן החלפת הסיסמה לא מגיעה אליהם.

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

המגבלה החשובה ביותר היא כזו שספק הזהויות (IdP) מתעד על עצמו:

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

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

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

איפה הטיעון הזה נעצר

שלושה גבולות, כי את הטיעון שלמעלה קל לפרש יתר על המידה.

• איפוס הסיסמה הוא פעולה נדרשת, לא חסרת תועלת. הרצף של Microsoft עצמה משבית את החשבון ואז מאפס את הסיסמה פעמיים, בתרגום חופשי "כדי לצמצם את הסיכון ל-pass-the-hash, במיוחד כשיש עיכובים בשכפול סיסמאות on-premises." הקריאה הכנה היא שנחוץ אך לא מספיק; חסר תועלת - לא.
• העיכוב בטוקנים הוא ברירת מחדל, לא חוק. מנגנון Continuous Access Evaluation מבטל טוקני סשן וטוקני גישה באפליקציות שתומכות בו, ו-Microsoft אומרת שהיא פועלת כדי להרחיב ביטול כמעט בזמן אמת לעוד אפליקציות. השעה היא פער קונפיגורציה, לא תקרה.
• לכללי הזיהוי יש תנאי מקדים. שישה כללי זיהוי שפורסמו שווים בדיוק כמה שאיסוף הלוגים בסביבה מאפשר להם. הטיעון כאן הוא שהאות קיים, לא שמניפולציה בחשבונות משתמשים נתפסת באופן אמין.

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

מה שהבקרות באמת עושות הוא לצמצם מי יכול להגיע אל תתי הטכניקות האלה. Phishing-resistant MFA, גישה מותנית וסקירה שוטפת של תפקידים בעלי הרשאות גבוהות מצמצמים את אוכלוסיית החשבונות שתוקף יכול לבצע בהם מניפולציה. אף אחד מהם לא ממפה מה שכבר נוסף, וזה נשאר משימת ציד.

שאלות נפוצות על מניפולציה בחשבונות משתמשים

לאיזו טקטיקה שייכת מניפולציה בחשבונות משתמשים? גם לשמירה על גישה וגם להסלמת הרשאות. זו אחת הטכניקות ש-ATT&CK ממפה לשתי טקטיקות, כי אותה פעולה ששומרת על הגישה יכולה גם להרחיב אותה: הוספת תפקיד או חברות בקבוצה עושה את שני הדברים בבת אחת.

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

אילו גורמי איום מתועדים כמשתמשים ב-T1098? דוגמאות הנהלים של MITRE עצמה מציינות את Sandworm Team, Calisto, HAFNIUM, Lazarus Group, ואת פונקציונליות Skeleton Key של Mimikatz. אלה המקרים שממופים ל-T1098. את Scattered Spider עדיף לא לצטט כאן, מהסיבה שצוינה למעלה.

האם T1098.005 זהה להתקפת MFA Fatigue? לא, וההבדל שימושי. התקפת MFA Fatigue עוסקת בחילוץ אישור אחד ממשתמש תחת לחץ. רישום מכשיר עוסק ברישום אמצעי אימות שבשליטת התוקף, כך שלעולם לא יידרש שוב אישור.

מה כדאי לבדוק

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

חמישה מקומות, בסביבה שלכם:

1. פרטי הזדהות שנוספו ל-service principals וליישומים.
2. משתמשים נוספים עם גישה לתיבת הדואר וכללי העברה.
3. רשומות `authorized_keys` במארחי Linux, macOS ו-ESXi.
4. חברויות בקבוצות, כולל קבוצות VPN ו-sudoers.
5. מכשירים ואמצעי אימות רשומים, במיוחד בחשבונות רדומים.

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

אפסו את פרטי ההזדהות, ואז ספרו מה עוד מאפשר כניסה.