סייבר ואבטחת מידע · windows-identity

חקירת Privilege Escalation ב-Windows באמצעות לוגים

מאת תאיר מלכא 7 דק׳ קריאהפורסם: 5 באוגוסט 2026
המחשה חזותית מקצועית בנושא חקירת Privilege Escalation ב-Windows בתחום Windows ו-Identity
תשובה מהירה

חקירת Privilege Escalation ב-Windows מחייב קריאה של האירוע המלא ולא רק של Event ID: זמן, מחשב, משתמש, Logon ID, Process, מקור רשת והקשר ארגוני. המסקנה נוצרת מקורלציה בין כמה מקורות.

חקירת Windows ו-Identity נשענת על שילוב בין אירועי אימות, יצירת תהליכים, שינויים בהרשאות, Telemetry של Sysmon והקשר ארגוני. אירוע יחיד כמעט אף פעם אינו מספק מסקנה מלאה. המאמר הנוכחי מתמקד ב-חקירת Privilege Escalation ב-Windows ומיועד ל-אנליסטי SOC וחוקרי Endpoint. המטרה היא לתת שיטת עבודה שאפשר ליישם בתרגול, בראיון מקצועי ובסביבת עבודה, בלי להסתפק בהגדרה מילונית.

האתגר המרכזי הוא שהנתונים כמעט תמיד חלקיים. 4672 special privileges, group membership changes, service/task creation יכולים להצביע על כיוון, אך המשמעות שלהם תלויה בזמן, בנכס, במשתמש ובפעילות הצפויה. לכן נבנה את הבדיקה סביב שאלת חקירה, ראיות נדרשות וקריטריון ברור לסיום.

התרחיש המעשי במאמר הוא: תרחיש שבו משתמש רגיל מקבל הרשאות מקומיות.. כל הדוגמאות הן נתוני מעבדה או תיאור תהליכי. כאשר מדובר ב-Penetration Testing, Web או Cloud, יש לעבוד רק עם אישור מפורש, Scope מוגדר ויכולת לעצור את הבדיקה.

מה נחשב Escalation

הנושא 'מה נחשב Escalation' הוא חלק מרכזי בעבודה על חקירת Privilege Escalation ב-Windows. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את 4672 special privileges, group membership changes, service/task creation, UAC/elevation, process lineage, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

שינויי משתמשים וקבוצות

הנושא 'שינויי משתמשים וקבוצות' הוא חלק מרכזי בעבודה על חקירת Privilege Escalation ב-Windows. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את 4672 special privileges, group membership changes, service/task creation, UAC/elevation, process lineage, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

Services ו-Scheduled Tasks

הנושא 'Services ו-Scheduled Tasks' הוא חלק מרכזי בעבודה על חקירת Privilege Escalation ב-Windows. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את 4672 special privileges, group membership changes, service/task creation, UAC/elevation, process lineage, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

Process integrity ו-Tokens

הנושא 'Process integrity ו-Tokens' הוא חלק מרכזי בעבודה על חקירת Privilege Escalation ב-Windows. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את 4672 special privileges, group membership changes, service/task creation, UAC/elevation, process lineage, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

Containment ואיסוף ראיות

בשלב זה מגדירים אילו ראיות דרושות כדי לענות על שאלת החקירה. עבור חקירת Privilege Escalation ב-Windows, נקודות הבסיס הן Event ID וה-Provider, Computer, User ו-Logon ID, Process, Parent ו-Command Line, Source IP, Workstation ו-Logon Type. לכל מקור מתעדים בעלים, טווח שמירה, אזור זמן, עיכוב קליטה ושדות שעלולים להיות חסרים.

איכות איסוף אינה נמדדת בכך שהלוג 'מגיע'. יש לבדוק Completeness, Latency, Parsing, Duplicate events וסנכרון זמן. בדיקת Canary או אירוע מעבדה ידוע מאפשרת לוודא שהפעולה הופיעה במקור, עברה את ה-Pipeline וניתנת לחיפוש בשדות הנכונים.

מוקדי בדיקה ייחודיים

בנושא הזה מומלץ לבנות מראש מפת ראיות ממוקדת. מוקדי הבדיקה המרכזיים הם: 4672 special privileges, group membership changes, service/task creation, UAC/elevation, process lineage. הרשימה אינה Checklist אוטומטי; כל פריט נבחר משום שהוא יכול לקשור בין ישות, פעולה וזמן או להסביר התנהגות לגיטימית.

  • 4672 special privileges: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
  • group membership changes: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
  • service/task creation: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
  • UAC/elevation: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
  • process lineage: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.

כאשר אחד המוקדים אינו זמין, יש לתעד את הפער ולבחור חלופה. לדוגמה, אם Process identifier אינו יציב, אפשר להיעזר בזמן, Host, User ו-Parent; אם Payload מוצפן, משתמשים ב-Metadata, נפח, תדירות ו-TLS/DNS context.

תהליך עבודה מומלץ

  1. הגדירו Scope ושאלת עבודה אחת בנושא חקירת Privilege Escalation ב-Windows.
  2. רשמו את מקורות הנתונים והראיות הדרושים: 4672 special privileges, group membership changes, service/task creation, UAC/elevation.
  3. צרו Baseline קצר של התנהגות תקינה או תוצאה צפויה.
  4. בצעו את הבדיקה המינימלית בסביבת מעבדה ושמרו זמן, קלט ופלט.
  5. בנו Timeline או טבלת השוואה והפרידו בין עובדה לפרשנות.
  6. בצעו Pivot למקור נוסף כדי לאמת או להפריך את ההסבר הראשוני.
  7. סכמו החלטה, מגבלות, פעולה מומלצת וקריטריון Retest.

תרחיש מעשי

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

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

שלבמה מבצעיםתוצר
הכנההגדירו Scope, זמן ויעד. רשמו אילו שדות או ראיות מתוך 4672 special privileges, group membership changes, service/task creation צפויים להופיע.תוכנית בדיקה קצרה
יצירת נתוןבצעו פעולה בטוחה ומדומה הקשורה ל-חקירת Privilege Escalation ב-Windows, ללא מידע אמיתי או השפעה על מערכת ייצור.אירוע/Request/Flow מבוקר
איסוףאספו את הראיה הגולמית ואת ההקשר ממקור נוסף. ודאו Time zone, מזהים ושלמות.שתי ראיות מקושרות
ניתוחכתבו מה כל ראיה מוכיחה, מה אינה מוכיחה ומהו ההסבר הלגיטימי האפשרי.מסקנת ביניים
סיוםבחרו סגירה, הסלמה, Finding או Tuning; הוסיפו המלצה ו-Retest.תוצר מתועד

Checklist מעשי

  • בדקו ותעדו: Event ID וה-Provider.
  • בדקו ותעדו: Computer, User ו-Logon ID.
  • בדקו ותעדו: Process, Parent ו-Command Line.
  • בדקו ותעדו: Source IP, Workstation ו-Logon Type.
  • בדקו ותעדו: Group/Privilege changes.
  • בדקו ותעדו: Sysmon ProcessGuid או SessionGuid.
  • ציינו Time zone, גרסת כלי ושעת איסוף.
  • שמרו את הנתון הגולמי לפני סינון או שינוי.
  • כתבו מה הממצא מוכיח ומה עדיין אינו ידוע.
  • הגדירו בעלים ופעולת המשך עם מועד.

טעויות נפוצות

  • להסתמך על Event ID בלי שדות.
  • לבלבל בין Logon למקור התקיפה.
  • להתעלם מ-Logon Type.
  • לקשר Processes לפי PID בלבד.
  • להניח שכל PowerShell הוא זדוני.
  • לסגור אירוע בלי לבדוק Domain Controller.

סיכום ו-CTA

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

במסלול Cybersecurity & AI של HPI מתרגלים את העקרונות האלה באמצעות מערכות, לוגים ומעבדות. המשך טבעי הוא לעבור למאמרים המקושרים, לבצע את תרגיל המעבדה ולשמור את התוצר כחלק מתיק עבודות מקצועי.

שאלות ותשובות

האם חקירת Privilege Escalation ב-Windows לבדו מוכיח תקיפה או חולשה?

לא. הוא מספק אות או ממצא שצריך הקשר, אימות ומקור נוסף. מסקנה מקצועית נשענת על רצף ראיות ועל התאמה להתנהגות הצפויה.

מה עושים כאשר חלק מהנתונים חסרים?

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

כמה זמן צריך לשמור את הראיות?

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

איך מתרגלים בלי לסכן מערכת אמיתית?

משתמשים במכונות וירטואליות, נתונים מדומים, CTF או מעבדה ייעודית. בבדיקות מורשות מגדירים Scope, Stop conditions וגיבוי לפני תחילת העבודה.

מקורות

רוצים לבדוק אם המסלול מתאים לכם?

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

פרטייך נשמרים באופן מאובטח.

ללימודי SOC וסייבר במסגרת תוכנית Cybersecurity & AI

רוצים לשמוע פרטים על התוכנית? השאירו פרטים ונחזור אליכם.

על הכותב
תאיר מלכא
מייסד ומנכ״ל HPI ומרצה לסייבר

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

מאמרים קשורים