לוגי האירועים של Windows וה-Event IDs שמגינים משתמשים בהם הכי הרבה

#מה הם לוגי האירועים של Windows

Windows מנהל רישום שוטף של מה שקורה במחשב: שירותים שעולים, תוכנות שקורסות, אנשים שמתחברים. כל רשומה היא אירוע. לכל אירוע יש חותמת זמן, provider (הרכיב שכתב אותו), Event ID מספרי, רמה ואוסף שדות שתלויים בסוג האירוע. האירועים מקובצים ללוגים, שנקראים גם ערוצים (channels), ונשמרים כקבצי .evtx תחת %SystemRoot%\System32\Winevt\Logs.

בהתחלה שלושה לוגים חשובים יותר מהשאר:

• Application מכיל אירועים שכותבות תוכנות וחלק מרכיבי Windows. אפליקציה שקורסת או עדכון שנכשל מגיעים בדרך כלל לכאן.
• System מכיל אירועים של Windows עצמו ושל דרייברים: שירותים שעולים ונעצרים, עליית שירות הלוגים בזמן האתחול (Event ID 6005), שגיאות דרייבר.
• Security מכיל אירועי audit: התחברויות, התנתקויות, שימוש בהרשאות רגישות, יצירת תהליכים, שינויים בחשבונות ובמדיניות. רוב המאמר עוסק בו, והוא היחיד מבין השלושה שמשתמש רגיל לא יכול לפתוח.

את ההבדל בגישה רואים מ-PowerShell. על המחשב ששימש למאמר הזה (Windows 11, Windows PowerShell 5.1), הפקודה הזו רצה ב-shell בלי הרשאות אדמין:

Get-WinEvent -ListLog System,Application | Format-Table LogName,RecordCount,IsEnabled -Auto

LogName     RecordCount IsEnabled
-------     ----------- ---------
System            36196      True
Application       19965      True

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

#למה זה משנה

הרבה זיהויים ב-Windows בנויים על לוג Security. חוק SIEM לניחוש סיסמאות סופר אירועי 4625. חוק לסשן אדמין חשוד מסתכל על 4624 ו-4672 יחד. חוק לחבלה בלוגים מחפש 1102. המאמר על SIEM במדריך השטח הסביר איך החוקים האלה עובדים. קריאה ידנית של האירועים במחשב אחד מאפשרת לבדוק אם ההנחות של חוק מסוים מתקיימות במערכות שלך.

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

#איך ה-audit עובד

#מדיניות ה-audit קובעת מה קיים

Windows מקבץ את הגדרות ה-audit לקטגוריות, וכל קטגוריה לתת־קטגוריות. כל תת־קטגוריה יכולה לתעד הצלחות, כישלונות, את שניהם או כלום. הקטגוריות הן Account Logon, Account Management, Detailed Tracking, DS Access, Logon/Logoff, Object Access, Policy Change, Privilege Use ו-System.

בקטגוריה Logon/Logoff נמצאות תת־הקטגוריות שמאחורי רוב האירועים במאמר: Logon (4624 ו-4625), Logoff (4634), Account Lockout (ש-Microsoft מציינת גם עבור 4625) ו-Special Logon (4672). יצירת תהליכים, אירוע 4688, שייכת לתת־הקטגוריה Process Creation תחת Detailed Tracking.

הכלי המובנה לקריאת המדיניות הוא auditpol. הפקודה auditpol /list מדפיסה שמות של קטגוריות ותת־קטגוריות ועובדת ב-shell רגיל. הפקודה auditpol /get קוראת את ההגדרות בפועל. לפי התיעוד של Microsoft היא דורשת הרשאת Read על המדיניות או את הזכות "Manage auditing and security log" (SeSecurityPrivilege), ול-shell רגיל בלי הרשאות אדמין אין אף אחת מהן.

auditpol /list /category /v

על המחשב ששימש למאמר, ששפת התצוגה שלו ב-Windows היא פורטוגזית, הפקודה הזו רצה בלי הרשאות אדמין והדפיסה כל קטגוריה עם שם מתורגם ו-GUID. ל-Logon/Logoff היה ה-GUID {69979849-797A-11D9-BED3-505054503030}. השם האנגלי עדיין עבד שם, בפקודה auditpol /list /subcategory:"Logon/Logoff", שהציגה שתים עשרה תת־קטגוריות. אם המערכת שלך דוחה שם, אפשר להעביר את ה-GUID.

#ה-Event IDs השימושיים ביותר

#4624 ו-4625: התחברויות

שני האירועים נכתבים במחשב שבו ההתחברות קרתה. אם מישהו מקליד סיסמה שגויה במחשב הנייד שלך, ה-4625 נוחת בלוג Security של אותו נייד. לשני האירועים יש ברובם אותם שדות:

• Subject הוא החשבון שדיווח על ההתחברות, לעיתים קרובות המחשב עצמו או SYSTEM.
• Logon Type מציין איך ההתחברות קרתה. הערכים הנפוצים הם 2 (Interactive, ליד המקלדת), 3 (Network, למשל שיתוף קבצים), 4 (Batch), 5 (Service), 7 (Unlock), 10 (RemoteInteractive, Remote Desktop) ו-11 (CachedInteractive, פרטי הזדהות של דומיין ששמורים במחשב).
• New Logon (ב-4624) או Account For Which Logon Failed (ב-4625) הוא החשבון שמתחבר, עם ה-Security ID, השם והדומיין שלו. ב-4624 החלק הזה כולל גם את Logon ID של הסשן החדש.
• Failure Information (רק ב-4625) כולל קוד Status וקוד Sub Status. העמוד של Microsoft מונה את הקודים ששווה לעקוב אחריהם: 0xC000006A לסיסמה שגויה, 0xC0000064 לשם משתמש שלא קיים, 0xC000006D לשם משתמש שגוי או לפרטי אימות שגויים, 0xC0000072 לחשבון מושבת. אותו עמוד מציין את 0xC0000234, "Account locked out", כסטטוס הטיפוסי כשהכישלון נובע מחשבון נעול. כמה כישלונות 0xC0000064 ברצף יכולים להעיד על מישהו שמנסה למפות שמות משתמשים.
• Process Information מציג את התהליך שניסה להתחבר, ו-Network Information נותן את שם תחנת העבודה, כתובת המקור ופורט המקור. הערכים 127.0.0.1 או ::1 פירושם localhost, והפורט הוא 0 בהתחברויות אינטראקטיביות.

ב-Windows 10 ואילך, 4624 כולל גם את Elevated Token, שמציין אם לסשן יש הרשאות אדמין.

#4634: התנתקות, ולמה ה-Logon ID חשוב

4634 אומר שסשן התחברות הסתיים. לבדו הוא מספר מעט. הערך שלו בא מה-Logon ID: אותו ערך הקסדצימלי מופיע ב-4624 שפתח את הסשן, בכל 4672 של אותו סשן, באירועי 4688 של תהליכים שהסשן הפעיל וב-4634 שסגר אותו. מעקב אחרי Logon ID אחד לאורך הלוג משחזר סשן מההתחלה ועד הסוף. Microsoft מציינת ש-Logon ID ייחודי רק בין אתחולים של אותו מחשב, ולכן תמיד צריך לצרף למזהה טווח זמן.

#4672: הרשאות מיוחדות

Windows כותב 4672 כשהתחברות חדשה מקבלת הרשאה מתוך רשימה של הרשאות רגישות, למשל SeDebugPrivilege (דיבוג תוכנות), SeBackupPrivilege (גיבוי קבצים ותיקיות) או SeTcbPrivilege (פעולה כחלק ממערכת ההפעלה).

כל התחברות של SYSTEM מפעילה 4672, ולכן יש הרבה כאלה בלוג. Microsoft ממליצה להתמקד באירועים שבהם החשבון איננו LOCAL SYSTEM, NETWORK SERVICE או LOCAL SERVICE, וגם לא אדמין שצפוי להחזיק בהרשאות האלה.

#4688: יצירת תהליכים

4688 נכתב בכל פעם שתהליך חדש עולה, כשתת־הקטגוריה Process Creation מתועדת. הוא רושם את שם התהליך החדש, את שם התהליך שיצר אותו (ה-parent), את החשבון, את Token Elevation Type (אם התהליך רץ עם טוקן מלא, מוגבה או מוגבל) ואת רמת ה-integrity.

יש בו גם שדה Process Command Line, שריק כברירת מחדל. לפי העמוד של Microsoft הוא מתמלא רק כשהגדרת ה-Group Policy "Administrative Templates\System\Audit Process Creation\Include command line in process creation events" מופעלת. בלעדיה ידוע רק שהתהליך powershell.exe עלה, ולא מה נאמר לו לעשות.

#1102: הלוג נמחק

1102 אומר שמישהו מחק את לוג Security. את האירוע כותב ה-provider Microsoft-Windows-Eventlog, והוא רושם את החשבון שעשה זאת. ההנחיה של Microsoft קצרה: בדרך כלל לא אמורים לראות את האירוע הזה, כמעט אין סיבה למחוק את לוג Security ידנית, וכל מקרה שווה חקירה.

#מה Sysmon מוסיף

Sysmon (System Monitor) הוא כלי של Sysinternals ש-Microsoft מפרסמת. הוא מותקן כשירות וכדרייבר, נשאר פעיל גם אחרי אתחולים וכותב אירועים משלו אל Applications and Services Logs/Microsoft/Windows/Sysmon/Operational. הוא הורדה נפרדת ולא חלק מהתקנת ברירת המחדל של Windows, ו-Microsoft מציינת תמיכה ב-Windows 11 וב-Windows Server 2019 ואילך.

בהשוואה ללוג Security המובנה, Sysmon נותן יותר פרטים על פעילות שאחרת רואים רק חלקית:

• Event ID 1, יצירת תהליך, כולל את שורת הפקודה המלאה, גיבובי קבצים (SHA1 כברירת מחדל, ואפשר גם MD5, SHA256 ו-IMPHASH) וגם ProcessGuid שנשאר ייחודי גם כש-Windows ממחזר מזהי תהליכים.
• Event ID 3 מתעד חיבורי רשת ואת התהליך שמאחורי כל אחד מהם. הוא מכובה כברירת מחדל.
• מזהים אחרים מכסים יצירת קבצים (11), שאילתות DNS (22), שינויים ברג׳יסטרי, named pipes, מנויי WMI ותהליך שפותח תהליך אחר, למשל lsass.exe (10).

קובץ תצורה ב-XML קובע אילו אירועים Sysmon כולל או מחריג. Microsoft מציינת ש-Sysmon לא מנתח את האירועים שלו ולא מנסה להסתתר מתוקפים. את הקריאה עושים SIEM או אנליסט.

התקנת Sysmon משנה את המערכת, ולכן המעבדה במאמר הזה לא כוללת אותה.

#תרגול: למצוא את ההתחברות הכושלת שלך

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

#שלב 1: לפתוח PowerShell עם הרשאות אדמין

ללחוץ לחיצה ימנית על Windows PowerShell או על Terminal ולבחור Run as administrator. לאחר מכן לבדוק שה-shell באמת רץ עם הרשאות אדמין:

([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

הערך True אומר שאפשר לקרוא את לוג Security. על המחשב ששימש למאמר, ה-shell הזמין החזיר False. הפקודות שלהלן הורצו שם בכל זאת, והכישלונות מדווחים כפי שנצפו, כי כדאי להכיר אותם. במקומות שבהם היה אמור להופיע פלט עם הרשאות אדמין, המאמר מתאר את השדות שצריך לחפש, לפי התיעוד של Microsoft.

#שלב 2: לבדוק את מדיניות ה-audit

auditpol /get /category:"Logon/Logoff"

ב-shell עם הרשאות אדמין הפקודה מדפיסה כל תת־קטגוריה עם ההגדרה שלה. צריך למצוא את השורה Logon. במעבדה הזו היא חייבת לכלול Failure, כלומר "Success and Failure" או "Failure". אם כתוב "No Auditing", Windows לא יכתוב 4625 ושאר המעבדה לא תמצא כלום.

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

#שלב 3: ליצור את האירוע

ללחוץ Win+L כדי לנעול את המסך. להקליד סיסמה שגויה פעם אחת ואז להתחבר עם הנכונה. לרשום את השעה.

צריך להשתמש בסיסמה, לא ב-PIN. אם בדרך כלל נכנסים עם Windows Hello, צריך לבחור באפשרות הסיסמה במסך הכניסה. המאמר לא בדק מה נוצר מ-PIN שגוי.

#שלב 4: למצוא את הכישלון עם Get-WinEvent

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

הפרמטר -FilterHashtable מחיל את הסינון בזמן קריאת האירועים, ולפי התיעוד של Microsoft זה יעיל יותר מהעברת הכול דרך pipe אל Where-Object. הפרמטר -MaxEvents 5 שומר את חמש ההתאמות החדשות ביותר, כי Get-WinEvent מחזיר קודם את החדשות.

ב-shell עם הרשאות אדמין, התוצאה העליונה אמורה לשאת את השעה שרשמת. בתוך Message צריך לבדוק:

• Logon Type. הדוגמה של Microsoft ל-4625 היא התחברות אינטראקטיבית, סוג 2, עם תהליך הקורא C:\Windows\System32\winlogon.exe.
• Account For Which Logon Failed, שאמור להיות החשבון שלך.
• Status ו-Sub Status. בסיסמה שגויה צריך לחפש את 0xC000006A באחד מהם.
• Source Network Address ו-Source Port. בהתחברות מהמקלדת שלך, הערך הצפוי הוא מקומי, למשל 127.0.0.1 ופורט 0, כמו בדוגמה של Microsoft.

בלי הרשאות אדמין, הפקודה המדויקת הזו מטעה. על המחשב ששימש למאמר היא לא דיווחה על בעיית הרשאות, אלא הדפיסה שגיאה שלא נמצאו אירועים התואמים לקריטריונים. פקודה פשוטה Get-WinEvent -LogName Security -MaxEvents 1 באותו shell דיווחה על הסיבה האמיתית, פעולה לא מורשית. אם מופיע "no events found" ב-shell בלי הרשאות אדמין, צריך לבדוק את ההרשאות לפני שמסיקים שהלוג ריק.

#שלב 5: למצוא את ההתחברות המוצלחת

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5 | Select-Object TimeCreated, Id

אמור להופיע 4624 כמה שניות אחרי ה-4625, עם עוד אירועי 4624 סביבו, כי שירותים והמערכת מתחברים כל הזמן. כדאי לפתוח את ההודעה המלאה של האירוע הקרוב ביותר לשעה שרשמת ולבדוק את Logon Type ואת שם החשבון. הוספת StartTime=(Get-Date).AddMinutes(-15) ל-hashtable מגבילה את החיפוש לחמש עשרה הדקות האחרונות.

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

#שלב 6: אותו חיפוש עם wevtutil

wevtutil qe Security /c:5 /rd:true /f:text /q:"*[System[(EventID=4625)]]"

wevtutil הוא כלי שורת הפקודה הוותיק ללוגי אירועים. qe מריץ שאילתה על אירועים, /c:5 מגביל את הכמות, /rd:true קורא מהחדש לישן, /f:text מדפיס טקסט במקום XML, והדגל /q מקבל מסנן XPath. עם הרשאות אדמין מתקבלים אותם אירועים כמו בשלב 4. בלי /f:text רואים את ה-XML הגולמי, עם שמות השדות שבהם משתמשים חוקי זיהוי, כמו TargetUserName, Status וגם LogonType. ב-Windows בשפה אחרת טקסט ההודעה מתורגם, ושמות השדות ב-XML נשארים באנגלית.

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

#שלב 7: לראות את זה ב-Event Viewer

להריץ את eventvwr.msc. אם מופיעה בקשה, לאשר הרצה כאדמין. לעבור אל Windows Logs > Security, לבחור Filter Current Log ולהזין 4625 בתיבה Event IDs. לפתוח את האירוע. הלשונית General מציגה את אותה הודעה שקראת ב-PowerShell. הלשונית Details, בתצוגת XML, מציגה את שמות השדות הגולמיים. כדאי להשאיר את האירוע פתוח: המאמר על Sigma משווה מולו חוק.

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

• להאמין ל-"no events found" מ-shell רגיל. כפי שראינו בשלב 4, שאילתת Get-WinEvent -FilterHashtable בלי הרשאות אדמין על לוג Security יכולה לדווח שאין התאמות במקום שהגישה נדחתה.
• להניח שאירוע קיים בלי לבדוק את המדיניות. אין הגדרת audit, אין אירוע. כך גם עם שדות: שורת הפקודה ב-4688 נשארת ריקה עד שמדיניות נפרדת מפעילה אותה.
• לקרוא אירוע אחד במנותק. 4625 בודד אומר מעט. צריך להסתכל על ה-4624 שאחריו, על ה-Logon ID ועל טווח הזמן.
• למחוק את הלוג אחרי מעבדה כדי לעשות סדר. זה משמיד את הראיות שיצרת זה עתה ויוצר 1102 שמישהו אולי יצטרך לחקור.
• לשכוח שלוגים מתגלגלים. על המחשב ששימש למאמר, Get-WinEvent -ListLog Application הראה גודל מרבי של 20971520 בתים במצב Circular: כשהלוג מתמלא, אירועים ישנים נדרסים. כדאי לבדוק את לוג Security באותה דרך, עם הרשאות אדמין, לפני שסומכים על אירועים מהחודש שעבר.

#איך להמשיך

• לקרוא את העמוד של Microsoft לכל אירוע במאמר. כל עמוד מסתיים בהמלצות לניטור אבטחה שקרובות לרעיונות מוכנים לזיהוי.
• להקים מכונה וירטואלית במעבדה ביתית חוקית, להתקין בה Sysmon עם קובץ תצורה, להריץ כמה פקודות ולהשוות בין אירוע 1 של Sysmon ל-4688 עבור אותו תהליך.
• להפוך את האירוע שמצאת לזיהוי: המאמר הבא, כתיבת חוק Sigma ראשון, בונה ובודק חוק בדיוק ל-4625 הזה.

#מקורות

• Microsoft Learn, 4625(F) An account failed to log on
• Microsoft Learn, 4624(S) An account was successfully logged on
• Microsoft Learn, 4634(S) An account was logged off
• Microsoft Learn, 4672(S) Special privileges assigned to new logon
• Microsoft Learn, 4688(S) A new process has been created
• Microsoft Learn, 1102(S) The audit log was cleared
• Microsoft Learn, Get-WinEvent
• Microsoft Learn, Sysmon
• Microsoft Learn, auditpol get
• Microsoft Learn, wevtutil