התוקף לא צריך נוזקה. הוא צריך רק הרשאה אחת.

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

מה זה Living off the Land ולמה זה צריך להדאיג מנהלים

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

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

MITRE ATT&CK מתארת ב System Binary Proxy Execution שימוש בבינאריים חתומים או מהימנים כדי להריץ תוכן חשוד או לעקוף הגנות שמבוססות על תהליך או חתימה. זה לא תרחיש תאורטי. זה בדיוק המקום שבו ארגון מגלה שהרשאה, לוג והקשר חשובים יותר מהשאלה אם הקובץ מוכר.

איך תקיפה כזו נראית בפועל

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

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

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

למה אנטי וירוס לבד מפספס את הבעיה

אנטי וירוס יודע לעצור קובץ מזוהה, התנהגות מוכרת או חתימה בעייתית. אבל במתקפת Living off the Land התוקף לא תמיד מביא קובץ חדש. הוא משתמש בכלי שהמערכת כבר סומכת עליו. PowerShell משמש מנהלי מערכת. WMI משמש ניהול מרחוק. rundll32 קיים כחלק מהמערכת. regsvr32 הוא כלי לגיטימי. mshta יכול להריץ רכיבים שמבחינת המערכת אינם נראים כמו תוכנה חיצונית חשודה.

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

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

הסימנים שצריך לחפש לפני שהאירוע מתפוצץ

מתקפות Living off the Land לא תמיד צועקות. אבל הן כן משאירות סימנים. מי שמחפש אותם בזמן יכול לעצור אירוע כשהוא עדיין קטן. מי שמחכה להצפנה כבר משחק בשלב האחרון.

• יישומי Office שמפעילים PowerShell, cmd או כלי מערכת אחרים ללא סיבה עסקית ברורה.
• PowerShell שמריץ פקודות מקודדות, מתחבר החוצה או פועל מתוך נתיב משתמש זמני.
• שימוש חריג ב WMI לניהול עמדות שאינן קשורות לתפקיד המשתמש.
• rundll32 או regsvr32 שמופעלים עם פרמטרים לא שגרתיים או מול מקורות חיצוניים.
• חשבונות רגילים שמבצעים פעולות שמאפיינות צוות IT.
• כלי ניהול מרחוק שמופעלים מחוץ לשעות פעילות או מעמדה שאינה של איש תמיכה.
• גישה פתאומית לתיקיות רבות, שרתים רבים או מערכות רגישות בזמן קצר.
• ניסיונות לשנות מדיניות אבטחה, לכבות רכיבי הגנה או למחוק לוגים.
• פעילות ספקים שאינה תואמת את חלון העבודה, המדינה, הכלי או מטרת הגישה שאושרה.

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

הבעיה האמיתית היא לא הכלי. הבעיה היא אמון בלי גבולות

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

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

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

מה חייבים לחבר ל SIEM כדי לראות תקיפה כזו

SIEM שאינו מקבל את מקורות המידע הנכונים לא יראה את הסיפור. הוא יראה שברי משפטים. במתקפת Living off the Land, הסיפור נמצא בחיבור בין זהות, עמדה, תהליך, רשת, ענן והרשאה. אם כל שכבה נשארת לבד, התוקף נהנה מהפערים ביניהן.

• לוגים של יצירת תהליכים בעמדות קצה ובשרתים, כולל פרמטרים של שורת הפקודה.
• לוגים של PowerShell, כולל Script Block Logging כאשר הדבר מתאים למדיניות הארגון.
• אירועי WMI ופעולות ניהול מרחוק.
• לוגים של התחברות, כשלונות אימות, שינויי MFA ושינויי הרשאות.
• נתוני EDR על שרשרת תהליכים, קשר בין תהליך אב לתהליך בן, וגישה לקבצים רגישים.
• לוגים של דוא״ל, קישורים, קבצים מצורפים וכללי העברת דואר.
• לוגים של VPN, חומות אש ותקשורת יוצאת חריגה.
• לוגים של ענן ויישומי SaaS, בעיקר פעולות אדמין, הורדות חריגות והרשאות אפליקציה.
• לוגים של גיבוי, מחיקות, שינויי שמירה וכשלונות שחזור.

תיעוד Microsoft על Script Block Logging מדגיש שכאשר יכולת זו מופעלת, PowerShell מתעד את תוכן ה script blocks שהוא מעבד. זו דוגמה טובה לעיקרון הרחב יותר: בלי טלמטריה עשירה, אי אפשר להבין אם כלי חוקי שימש לעבודה תקינה או לתקיפה.

לא לחסום הכל. לשלוט במה שמותר

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

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

Microsoft מתארת ב כללי Attack Surface Reduction של Microsoft Defender בקרות שמצמצמות פעולות מסוכנות כמו יצירת תהליכים מתוך Office, שימוש ב WMI ו PsExec להפעלת תהליכים, והפעלת סקריפטים מעורפלים. אבל גם כאן, הכלי אינו כל הסיפור. צריך לבדוק התאמה עסקית, להפעיל תחילה במצב ניטור כאשר נדרש, למדוד השפעה ולבנות מדיניות שמחזיקה מעמד.

הקשר לעדכוני אבטחה

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

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

צ׳קליסט קצר למנהלים שרוצים לבדוק את עצמם השבוע

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

• בדקו מי בארגון רשאי להריץ PowerShell, WMI וכלי ניהול מרחוק.
• בדקו האם יש הבדל בין הרשאות מנהלי IT לבין הרשאות משתמשים רגילים.
• בדקו האם לוגים של יצירת תהליכים מגיעים למרכז ניטור ולא נשארים רק בעמדה.
• בדקו האם אתם רואים את הפרמטרים של שורת הפקודה ולא רק את שם התהליך.
• בדקו האם קיימות התרעות על Office שמפעיל כלי מערכת.
• בדקו האם פעילות ספקים נרשמת, מוגבלת ומחוברת לזהות ברורה.
• בדקו האם אפשר לבטל סשנים, לחסום חשבון ולבודד עמדה בזמן קצר.
• בדקו האם צוות ה SOC יודע להבדיל בין פעולה לגיטימית של מנהל מערכת לבין פעולה חשודה של משתמש רגיל.
• בדקו האם יש תרגיל תגובה לתרחיש שבו אין קובץ זדוני, אלא רק רצף פעולות חריג.

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

איך אנחנו ב 010 מסתכלים על הסיכון הזה

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

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

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

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

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

הפעולה המומלצת ברורה: בחרו עשר עמדות רגישות, שלושה שרתים קריטיים ושני חשבונות ספקים. בדקו אילו כלי ניהול רצים שם, מי מריץ אותם, האם הפעילות מתועדת, האם היא מגיעה ל SIEM, ומה יקרה אם מחר בבוקר תראו PowerShell חריג, WMI חריג או שימוש חשוד ב rundll32. אם אין לכם תשובה מבצעית, אין לכם בעיית כלי. יש לכם פער שליטה.

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