שיטות בעקיפת AMSI

מאמר שמדבר על AMSI ונוגע בצורה קלה באפשרויות תקיפה ספציפיות.   

Microsoft פיתחה את AMSI (ממשק סריקה נגד תוכנות/אפליקציות זדוניות) כשיטה להגנה מפני הרצת תוכנות זדוניות ולהגנה על מכונות. כברירת מחדל, Microsoft Defender מקיים אינטראקציה עם API כדי לסרוק סקריפטים, למשל, מבוססי PowerShell, או פקודות מאקרו של VBA, או JavaScript וסקריפטים אחרים ומגוונים באמצעות טכנולוגיות שונות, כמו Windows Script Host, וכל הפעולות אינטראקציה יכולות להיעשות על גבי הרצות בכדי למנוע קוד שרירותי. 

• ערפול קוד – תוקפים יכולים להשתמש בטכניקות ערפול קוד כדי להקשות על AMSI לזהות התנהגות זדונית. על ידי ערפול הקוד שלהם, התוקפים יכולים להסתיר את המטרה האמיתית של הסקריפט או הקוד שלהם מ AMSI.
• Fileless – תקיפות ותוכנות זדוניות יכולות להתבצע במלואן בזכרון מבלי להשאיר קבצים כלשהם בדיסק. זה יכול להקשות על AMSI לזהות את הפעולה או התוכנה הזדונית, מכיוון שייתכן שלא יהיו קבצים לסריקה.
• נקודות תורפה וחולשות – תוקפים עשויים לנסות למצוא נקודות חלשות ב AMSI עצמה כדי לעקוף את יכולות הסריקה שלה. לדוגמה, עשויים לנצל פגיעות בזכרון של AMSI DLL כדי להפעיל קוד זדוני.
• הוקינג – תוקפים עשויים לנסות להשתמש בטכניקה הנקראת הוקינג כדי לעקוף את AMSI. דבר זה כרוך ביירוט בקשות וגישות אל AMSI שנעשו ע״י אפליקציה ושינוי הנתונים הנשלחים ל AMSI. במצב כזה, תוקפים יכולים לעקוף את יכולות הסריקה של AMSI ולעוור את המנגנון.

כיצד פועל AMSI

AMSI.dll הינו קובץ DLL המספק ממשק בין יישומים לאנטי וירוס או כלי אבטחה אחרים. הוא אחראי על יירוט וסריקת קוד או קבצים שעלולים להיות זדוניים בזמן שיישום מנסה להפעיל אותו. AMSI.dll נטען לזיכרון בעת הפעלת יישום, והוא נשאר בזכרון לאורך כל חיי היישום. כאשר יישום מנסה להפעיל קוד שעלול להיות זדוני, AMSI.dll מיירט את הקוד ושולח אותו לאנטי וירוס או לכלי אבטחה אחר לניתוח (שעושה שימוש עם AMSI). הניתוח יכול לכלול בדיקת קוד מול חתימות ידועות, ניתוח מבוסס יוריסטיקה לאיתור התנהגות חשודה, או אלגוריתמים של למידת מכונה לזיהוי איומים חדשים ולא ידועים. אם נקבע שהקוד זדוני, AMSI.dll יחסום את ביצועו וימנע מהאפליקציה להפעיל אותו. לאחר מכן, האפליקציה תקבל הודעת שגיאה או התראה שהקוד נחסם עקב סיכון אבטחה או מינופלציה אחרת שאינה לגטימית.

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

• AmsiScanBuffer()
• AmsiScanString()

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

הבקשות מול API מספקות קבוצה של פונקציות שניתן להשתמש בהן כדי לשלב את AMSI.dll, בין היתר:

AmsiInitialize – מאתחל את מנגנון AMSI.
AmsiUninitialize – מבטל את האתחול של מנגנון AMSI.
AmsiOpenSession – טריגר להפעלה של סריקת תוכן.
AmsiCloseSession – סוגר את אותה הפעלה.
AmsiScanBuffer – סורק מאגר נתונים לאיומים פוטנציאליים.
AmsiScanString – סורק מחרוזת נתונים לאיומים פוטנציאליים.
AmsiScanInputStream – סורק נתונים לאיומים פוטנציאליים.

מידע נוסף לגבי Antimalware Scan Interface.

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

– UAC elevation requests 
– PowerShell (greater than 2.0)
– Windows Script Host
– JavaScript and VBScipt
– Office macros (VBA)
– Excel macros
– NET Framework
– WMI

התחמקויות וזה

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

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

– Obfuscation and/or encryption
– PowerShell downgrade
– Hooks and unhooks
– Memory patching
– Forcing an error
– Registry modifications
– DLL hijacking
– Reflection

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

צוותי אבטחה צריכים לשאות את עצמם, האם כלי EDR או כלים אחרים יכולים לזהות את מה שקורה עם עקיפת AMSI? חלקי בלבד, גם שמתאמצים.

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

הורדת גרסה – PowerShell 2.0

למרות שגרסת PowerShell 2.0 הוצאה משימוש על ידי Microsoft, היא עדיין אינה הוסרה מתוך מערכות הפעלה רבות. גרסאות ישנות יותר של PowerShell אינן מכילות בקרות אבטחה כגון הגנת AMSI ויכולות לשמש כצורה של התחמקות. שדרוג לאחור של גרסת PowerShell לגרסה ישנה יותר הוא מוכר ודורש הרצת פקודה קצרה: powershell -version 2 

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

עם קצת אהבה אפשר לשנות את צורת ההורדה ולהפעיל ישירות מימי חתולים ולהתחמק מתוך כלי EDR.

אז למה הגרסאות הישנות יותר של PowerShell מעניינות תוקפים? קודם כל, כאשר מאלצים את PowerShell לפעול באמצעות גרסת PowerShell 2.0, אף אחת מתכונות האבטחה המתקדמות אינה זמינה, מכיוון ש NET Framework v2.0 הישנה יותר נטענה במכונה.

שנית, כשמסתכלים על ווקטור התקיפה, לכל המכונות המריצות Windows 7 ומעלה יהיו לפחות PowerShell 2.0. זה מכוון בקלות להרבה מכונות, ממש הרבה…
כברירת מחדל, עם Windows 10, NET Framework 2.0 אינו כלול והופך את זה (כברירת מחדל) ללא אפשרי להפעיל את PowerShell 5.x באמצעות גרסת PowerShell 2.0 מדור קודם.

שלישית, תוקפים אוהבים את PowerShell בשל יכולתה לספק גישה קלה לרכיבים/תכונות פלטפורמה רבים כמו ממשקי API של Win32, גישה לרישום, אינטראקציה עם סרוויסים, בחינת תהליכים, הורדת קבצים מהאינטרנט, ערפול קוד, גישה ליומן אירועים, יכולת להחדיר קוד או לטעון קוד באופן רפלקטיבי, גישה ל NET Framework ועוד… בקיצור, כל מה שתוקף יכול לאחל לו.

בשטח, בספירה קלה, שרתים רבים עדיין עובדים עם גרסת PowerShell 2.0 – כולל בגרסאות שרתים חדשות. והשאלה הגדולה, האם כלי EDR יזהו פעולות כאלה? 

הוקינג

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

• רישום ארגומנטים.
• לאפשר/חסימת ביצוע של פונקציה.
• החלפת ארגומנטים שהועברו לפונקציה והחלטה על הערך שיוחזר.

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

שינוי ערכי רישום

פרוביידרים של AMSI אחראים על תהליך הסריקה ע״י כלי האנטי וירוס ומתעדים רישומים בערכי רישום (Registry). ה GUID עבור Microsoft Defender הינו:

HKLM:\SOFTWARE\Microsoft\AMSI\Providers\{2781761E-28E0-4109-99FE-B9D127C57AFE}

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

CMD – REG DELETE HKLM\SOFTWARE\Microsoft\AMSI\Providers\{2781761E-28E0-4109-99FE-B9D127C57AFE} /f /s

PS – Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\AMSI\Providers\{2781761E-28E0-4109-99FE-B9D127C57AFE}" -Recurse

חטיפת DLL

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

כאמור, חטיפת DLL היא שיטה להחדרת קוד זדוני ליישום על ידי ניצול האופן שבו יישומי Windows מסוימים שמחפשים וטוענים ספריות קישורים דינמיים (DLL), ולכן AMSI מיושם כ DLL. ומה אנחנו יכולים עושים? אנו יוצרים DLL משלנו אשר מייצא את כל ממשקי AMSI. 

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

בדוגמה המצורפת, הקוד מנסה לעקוף את AMSI ולהפעיל את PowerShell מקובץ DLL.

• ראשית, הוא מפצל את התוכן של משתנה $DllBytes ומאחסן את מערך המתקבל במשתנה $temp.
• לאחר מכן, הוא כותב את התוכן של $temp לקובץ בשם amsi-dll.dll (קובץ ספציפי) בספריה הנוכחית.
• לאחר מכן, הוא יעתיק את קובץ ההפעלה של PowerShell ממיקום ברירת המחדל לספריה הנוכחית באמצעות פקודת העתקה.
• לבסוף, הוא צריך להתחיל מופע חדש של PowerShell מהספרחה הנוכחית באמצעות האופרטור & והנתיב לקובץ ההפעלה של PowerShell שהועתק.

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

כך זה נראה מתוך הממשקים של Microsoft Sentinel ושל Microsoft Defender for Endpoint. לשמחתי הרבה שמדובר על מערכות הפעלה מתקדמות כמו Windows 10 ומעלה או Windows Server 2016 (עם העדכונים האחרונים) ומעלה, הכלים של מיקרוסופט יודעים לתת כיסוי וזיהוי טוב עם דירוג גבוה. 

 

הכיסוי והזיהוי של כלי אבטחה מול שיטות העקיפה של AMSI הם בסביבות 80%. מה עושים עם היתר?   

רפרנסים

Amsi-Bypass-Powershell