audit policy ב-Windows וחקירת Event Log בפועל — איך להפוך לצוות IT שיודע לקרוא את 4625

“חשבון ננעל שוב ושוב מאמש. תבררו למה.” “רוצה לבדוק אם מישהו ניסה לעשות logon עם חשבון של עובד שעזב.” “אפשר לדעת מי עשה מה, ומתי, בשרת הזה?” — אלה הבקשות שאנשי IT בעסקים קטנים ובינוניים, או מפתחים שמסרו מערכת ללקוח, מקבלים פתאום ביום אחד. והדבר שהם נשענים עליו הוא Security Event Log של Windows.

אבל כשבאמת פותחים את Event Viewer, מחכות שתי מציאויות. האירוע שרציתם לראות כלל לא נרשם (audit policy לא הופעלה), או הוא קבור תחת הר אירועים שאי אפשר לקרוא (טבוע ברעש ובניפוח). Security audit הוא דבר שאפשר לתעד “אם מפעילים אותו”, אבל בלי לתכנן מה לתעד ועד כמה, הוא לא יעזור ברגע שבאמת צריך אותו.

flowchart TB
    accTitle: שתי המציאויות שמחכות ב-Event Viewer
    accDescr: כשפותחים את Event Viewer מחכות שתי מציאויות, ש-audit policy אינה מופעלת והאירוע הרצוי לא נרשם, או שהיומן מנופח ברעש והאירועים קבורים בכמות שאי אפשר לקרוא, ולכן נדרש לתכנן מה לרשום ועד כמה
    open["פתיחת Event Viewer"] --> real{"איזו מציאות מחכה?"}
    real -->|לא נרשם| none["האירוע הרצוי לא נרשם"]
    real -->|קבור| noise["לא ניתן לקרוא מרוב אירועים"]
    none -.-> cause1["audit policy כבויה"]
    noise -.-> cause2["מנופח ברעש"]
    none --> design["לתכנן מה לרשום ועד כמה"]
    noise --> design

איור 1: “לא נרשם” או “קבור ולא ניתן לקרוא”. בשני המקרים הסיבה היא שלא תכננו את טווח הרישום.

המאמר מסדר את מנגנון ה-audit policy (שתי המערכות — basic ו-advanced), את ה-subcategories שכדאי להפעיל לפחות בסביבה קטנה-עד-בינונית, איך לקרוא את Event IDs הסטנדרטיים — 4624/4625/4740/4688 ואחרים — תכנון קיבולת Security log, ואיך חוקרים ב-PowerShell, על בסיס מקורות ראשוניים נכון לאוגוסט 2026. אם מאמרי ביקורת NTLM, SMB signing, BitLocker ו-Firewall באתר הזה הם כולם על “חיזוק ההגנות”, המאמר הזה הוא על “לאפשר לאשר אחר כך מה קרה” — המשך שקושר אותם יחד.

1. קודם כל, המסקנות

• ל-audit policy יש שתי מערכות — “basic” ו-“Advanced Audit Policy” — ואסור לערבב אותן. Microsoft קובעת במפורש ששימוש בשתיהן משאיר את תוצאות ה-audit במצב בלתי צפוי. מאחדים לצד המתקדם (יותר מ-40 subcategories).¹
• את המצב הנוכחי בודקים ב-auditpol /get /category:*. זו רשימה של מה שבתוקף עכשיו בפועל, בלי קשר אם זה הגיע מ-GPO או מהגדרה מקומית.²
• “להפעיל הכול” זה דבר שאסור לעשות. הפעלת subcategories שמייצרות נפח אירועים עצום קוברת את האירועים שחשובים באמת תחת רעש, ופוגעת גם בביצועים. מתחילים מהמלצות הבסיס של Microsoft ומוסיפים רק מה שצריך.³⁴
• Logon מוצלח הוא 4624; logon שנכשל הוא 4625. ב-4624 קוראים “איזה סוג logon זו הייתה” מסוג ה-logon (2 = Interactive, 3 = Network, 10 = RemoteInteractive, וכן הלאה).⁵
• ב-4625, קוד Status/Sub Status אומר את סיבת הכישלון. הסטנדרטיים הם 0xC0000064 = שם משתמש שאינו קיים, 0xC000006A = סיסמה שגויה, 0xC0000072 = חשבון מושבת, ו-0xC0000234 = החשבון נעול.⁶
• איפה Event נרשם קבוע. 4624/4625 נרשמים במכונה שאליה ניגשו; Credential validation (4776) וכישלון Kerberos pre-authentication (4771) נרשמים ב-domain controller. מסתכלים במכונה הלא נכונה ומסיקים בטעות “אין יומן”.⁶⁷⁸
• חצי מתכנון Security log הוא המיכל עצמו — גודל מרבי ושמירה. אם השמירה מוגדרת לדריסה, אירועים ישנים נעלמים ראשונים. בודקים גודל מרבי ומספר רשומות ב-Get-WinEvent -ListLog Security, ומרחיבים בחישוב לאחור ממספר הימים שצריך באמת לשמור.⁹¹⁰
• רישום command line ל-process creation (4688) חזק, אבל המחיר הוא שסודות נוחתים ביומן בטקסט גלוי. בודקים את הסקריפטים לפני שמפעילים.¹¹¹²

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 34, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. יסודות audit policy — לא לערבב “basic” ו-“advanced”

ל-audit policy של Windows יש שתי מערכות.¹

• Basic audit policy: תשע הגדרות הקטגוריה תחת “Local Policies > Audit Policy”. זו המערכת הישנה, מלפני Windows Vista.
• Advanced Audit Policy Configuration: יותר מ-40 הגדרות subcategory תחת “Security Settings > Advanced Audit Policy Configuration”. היא מפרקת כל קטגוריה בסיסית לכמה subcategories — למשל, הקטגוריה הבסיסית היחידה “Audit account logon events” מקבילה לארבע subcategories בצד המתקדם. הפעלת קטגוריה בסיסית אחת שקולה להפעלת כל ה-subcategories המתאימות, וזה רושם נפח גדול של אירועים שאולי כלל לא מעניינים אתכם.¹

הנקודה החשובה היא ששתי המערכות האלה אינן תואמות זו לזו. Microsoft אומרת בפשטות: “אל תשתמשו גם ב-basic audit policy וגם ב-advanced — זה יכול להוביל לתוצאות audit בלתי צפויות.” כש-Advanced Audit Policy מוחלת דרך Group Policy, הגדרות ה-audit הקיימות במחשב מנוקות תחילה ואז מוחלות ההגדרות המתקדמות; משם והלאה רק הצד המתקדם יכול לשלוט ב-audit באופן אמין. בסביבות שמשתמשות בצד המתקדם, מפעילים את אפשרות האבטחה “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” כדי שההגדרות הבסיסיות לא יוכלו לדרוס אותה (במכונות עצמאיות זה מופעל כברירת מחדל).¹⁴

flowchart TB
    accTitle: הקשר בין basic audit policy ל-Advanced Audit Policy
    accDescr: Basic audit policy ו-Advanced Audit Policy אינן תואמות, ושימוש בשתיהן משאיר תוצאות audit במצב בלתי צפוי, לכן מאחדים לצד המתקדם ומפעילים אכיפת subcategories כדי למנוע דריסה מצד הבסיס
    basic["basic audit policy (9 קטגוריות)"] --> both{"משתמשים בשתיהן?"}
    adv["Advanced Audit Policy (40+ subcategories)"] --> both
    both -->|כן| bad["תוצאות audit בלתי צפויות"]
    both -->|לא| unify["איחוד לצד המתקדם"]
    unify --> force["הפעלת אכיפת subcategories"]
    force -.-> guard["מונע דריסה מצד הבסיס"]

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

בדיקת המצב הנוכחי היא פקודה אחת, משורת פקודה elevated.²

rem רשימת הגדרות ה-audit שבתוקף כעת, לפי subcategory
auditpol /get /category:*

rem גיבוי (CSV) לפני שינוי ושחזור
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

הפלט של auditpol הוא “המדיניות שבתוקף בפועל”, בלי קשר אם המקור הוא GPO או הגדרה מקומית. הוא שימושי גם להצלבה כשהגדרה שחולקה ב-GPO נראית שלא נכנסה לתוקף. שימו לב ששינוי בהגדרות ה-audit עצמן נרשם כ-Event 4719, כך שגם “ה-audit כובה בלי שאף אחד שם לב” ניתן לעקוב אחריו בדיעבד.¹²

flowchart TB
    accTitle: מה ש-auditpol מראה הוא המדיניות שבתוצאה
    accDescr: הפלט של auditpol הוא ה-audit policy שבתוקף בפועל בלי קשר אם המקור הוא GPO או הגדרה מקומית, והוא שימושי להצלבה כש-GPO לא חלה, ושינוי ב-audit policy עצמה נשאר ב-Event 4719
    gpo["הגדרה שחולקה ב-GPO"] --> eff["המדיניות שבתוקף בפועל"]
    local["הגדרה מקומית"] --> eff
    eff --> get["רשימה ב-auditpol /get"]
    get -.-> diff["שימושי כש-GPO לא חלה"]
    change["שינוי audit policy עצמה"] -.-> e4719["4719 נרשם ואפשר לעקוב"]

איור 3: auditpol מחזיר את “ההגדרה שבתוקף” בלי קשר למקור. שינוי ב-audit policy עצמה נשאר ב-4719.

3. טבלת החלטה ל-subcategories המינימליות להפעלה

ברור למה “פשוט נפעיל הכול, ליתר ביטחון” הוא מהלך גרוע. למשל, Microsoft מזהירה ש-audit הצלחה ל-subcategories של Privilege Use מייצרת נפח אירועים כה עצום עד שקשה למצוא ערכים אחרים ב-Security log, ושיש גם השפעה משמעותית על הביצועים.⁴ מיכל היומן (פרק 5) סופי, ולכן ככל שרושמים יותר רעש, כך נאכל יותר מטווח השמירה של האירועים שבאמת צריך. תכנון audit הוא בעצם להחליט מה לא לרשום.

flowchart TB
    accTitle: למה "להפעיל הכול" הוא מהלך גרוע
    accDescr: הפעלת כל ה-subcategories מייצרת נפח אירועים גדול, קוברת את האירועים החשובים ברעש ופוגעת בביצועים, ובכלי יומן סופי גם מקצרת את ימי השמירה של האירועים הנחוצים
    all["הפעלת כל ה-subcategories"] --> flood["נוצרים אירועים רבים"]
    flood --> noise["האירועים החשובים נקברים"]
    flood --> perf["השפעה על הביצועים"]
    flood --> keep["ימי השמירה מתקצרים"]
    noise --> lesson["תכנון audit הוא להחליט מה לא לרשום"]
    perf --> lesson
    keep --> lesson

איור 4: “להפעיל הכול” קובר את האירועים החשובים. תכנון audit הוא להחליט מה לא לרשום.

Microsoft מפרסמת המלצות בסיס והמלצות מחמירות לפי workstation ושרת, ואלה נקודת הפתיחה.³ משם, הטבלה שלמטה מסודרת סביב נקודת המבט של סביבה קטנה-עד-בינונית: “מה אנחנו רוצים להיות מסוגלים לקרוא לפחות בזמן אירוע”.

ולהפך, בדרך כלל בטוח ביותר לא לגעת כברירת מחדל ב-audit של Object Access למערכת קבצים או Registry, ב-Privilege Use, או ב-subcategories של packet filter (5152 ודומיהן). אלה מועילות כשמצמצמים אותן לתצורת SACL ממוקדת או לחקירה מוגבלת בזמן, לא כמשהו שמשאירים פתוח תמיד על כל הלוח — כך תאכלו את היומן חי.⁴

flowchart TB
    accTitle: איך מטפלים ב-subcategories עתירות אירועים
    accDescr: Audit של Object Access למערכת קבצים או Registry, Privilege Use ו-packet filter אוכלים את היומן אם משאירים אותם פתוחים תמיד, ולכן הם מועילים רק ב-SACL מצומצם או בתקופת isolation מוגבלת
    heavy["subcategories עתירות אירועים"] --> use{"איך מפעילים?"}
    heavy -.-> ex1["Object Access audit"]
    heavy -.-> ex2["Privilege Use ו-packet filter"]
    use -->|פתוח תמיד| eat["היומן נאכל"]
    use -->|SACL מצומצם| ok1["מועיל"]
    use -->|רק לתקופת isolation| ok2["מועיל"]

איור 5: Object Access ו-Privilege Use לא נשארים פתוחים תמיד. הם מועילים כשמצמצמים יעד ותקופה.

4. איך לקרוא את Event IDs הסטנדרטיים

4.1. 4624 —‏ logons מוצלחים ממוינים לפי Logon Type

4624, “An account was successfully logged on”, נרשם במכונה שבה נוצרה הפעלת ה-logon (המכונה שאליה ניגשו).⁵ משום שזה Event בנפח גבוה, הצעד הראשון בקריאה הוא למיין לפי Logon Type.⁵

שדות נוספים שכדאי לבדוק לצד זה הם שם החשבון תחת “New Logon”, כתובת המקור תחת “Network Information”, “Authentication Package” (NTLM או Kerberos), ו-“Elevated Token” (האם להפעלה יש הרשאות Administrator). אם רוצים לעקוב רק אחרי logons עם הרשאות Administrator, גם Event 4672 (Special privileges assigned to new logon), שנרשם תחת אותו Logon ID, שימושי.⁵

flowchart TB
    accTitle: סדר הקריאה המבדיל של 4624
    accDescr: 4624 שנרשם בכמויות ממוין קודם לפי Logon Type, אחר כך בודקים שם חשבון ומקור, Authentication Package ו-Elevated Token, ו-logon עם הרשאות Administrator מצליבים עם 4672 של אותו Logon ID
    ev["4624 logon מוצלח"] --> type["מיון לפי Logon Type"]
    type --> fields["בדיקת שדות עיקריים"]
    fields -.-> f1["שם חשבון ומקור"]
    fields -.-> f2["Authentication Package"]
    fields -.-> f3["Elevated Token"]
    fields --> admin["מעקב אחרי הרשאות Administrator"]
    admin -.-> e4672["4672 עם אותו Logon ID"]

איור 6: ב-4624 ממיינים לפי Logon Type ואז קוראים שדות. Logon עם הרשאות Administrator מצליבים עם 4672.

4.2. 4625 — קובעים את סיבת הכישלון בקוד Status/Sub Status

4625, “An account failed to log on”, נרשם במכונה שבה ניסו לעשות logon.⁶ במקום לסמוך על ניסוח השדה “Failure Reason”, הדרך האמינה לקרוא היא לפי קוד Status/Sub Status ההקסדצימלי. הסטנדרטיים הם כדלקמן.⁶

• 0xC0000064: שם משתמש שאינו קיים. רצף מהיר של אלה בחלון קצר יכול להצביע על התקפת account enumeration
• 0xC000006A: סיסמה שגויה. כשלונות חוזרים מול חשבון מסוים יכולים להצביע על התקפת ניחוש סיסמה
• 0xC000006D: שם משתמש או מידע אימות לא חוקיים
• 0xC000006F: מחוץ לשעות ה-logon המותרות
• 0xC0000070: מתחנת עבודה שאינה מותרת
• 0xC0000072: חשבון שהושבת בידי Administrator (ניסיונות מול חשבון של עובד שעזב מופיעים כאן)
• 0xC000015B: סוג ה-logon המבוקש אינו מותר במכונה הזאת
• 0xC0000193: חשבון שפג תוקפו
• 0xC0000234: נעול

“מי, מאיפה, ולמה זה נכשל” נקבע בשלישייה של חשבון היעד, המקור (שם workstation / כתובת IP), והקוד הזה. פרק 6 כולל PowerShell ששולף את שלושתם יחד בפעם אחת.

flowchart TB
    accTitle: זרימת קביעת סיבת הכישלון של 4625
    accDescr: סיבת הכישלון של 4625 נקבעת לפי קוד Status/Sub Status ההקסדצימלי, מגמת הקוד נקראת כסימן להתקפה, ואז מזהים בשלישייה של חשבון יעד, מקור והקוד
    ev["4625 logon שנכשל"] --> code["בדיקת קוד Sub Status"]
    code --> sign{"מה מגמת הקוד?"}
    sign -->|רצף 0xC0000064| enum["סימן ל-account enumeration"]
    sign -->|רצף 0xC000006A| guess["סימן לניחוש סיסמה"]
    sign -->|0xC0000072| disabled["ניסיון בחשבון עובד שעזב"]
    enum --> triple["קובעים בשלישייה"]
    guess --> triple
    disabled --> triple
    triple -.-> t1["חשבון יעד+מקור+קוד"]

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

4.3. 4740 — מקור הנעילה הוא Caller Computer Name

4740, “A user account was locked out” (subcategory: User Account Management). השדה המרכזי ב-Event הזה הוא Caller Computer Name, שרושם את המחשב שממנו יצא ניסיון ה-logon שהפעיל את הנעילה.¹⁶ ההליך הסטנדרטי הוא לזהות את מכונת המקור מהשדה הזה, ואז לחפש credentials ישנים שעדיין שמורים באותה מכונה. ברוב המקרים הסיבה היא משהו שממשיך להשתמש ב-credentials ישנים אחרי החלפת סיסמה — credentials שמורים, הפעלת RDP מנותקת שנשארה תלויה, או service ו-scheduled task שהוגדרו עם הסיסמה הישנה.

flowchart TB
    accTitle: סדר החקירה הקבוע של נעילת חשבון
    accDescr: מזהים את מחשב המקור מ-Caller Computer Name ב-4740, ואז שוטפים במחשב הזה credentials שמורים, הפעלת RDP מנותקת שנשארה, ו-service או task עם סיסמה ישנה
    ev["4740 נעילה התרחשה"] --> caller["בדיקת Caller Computer Name"]
    caller --> src["זיהוי מחשב המקור"]
    src --> sweep["שטיפת credentials ישנים"]
    sweep -.-> c1["credentials שמורים"]
    sweep -.-> c2["הפעלת RDP מנותקת שנשארה"]
    sweep -.-> c3["service או task עם סיסמה ישנה"]

איור 8: מזהים את מקור הנעילה מ-Caller Computer Name ב-4740, ושוטפים credentials ישנים באותו מחשב.

יש דבר אחד להיזהר ממנו. 4625 נרשם במחשב שקיבל את ניסיון ה-logon. אם הסיבה היא network logon ממכונת המקור אל, למשל, file server, אין 4625 ב-Security log של מכונת המקור עצמה; במקום זה העקבות נשארות ב-4625 בשרת היעד, או בחשבון domain ב-4776 (NTLM) או 4771 (כישלון Kerberos pre-authentication) ב-DC.⁷⁸ כש”אין דבר ביומן במכונת המקור”, הולכים להסתכל בצד המקבל.

flowchart TB
    accTitle: המכונה שבה נשארות עקבות הכישלון
    accDescr: כישלון network logon אינו נשאר במחשב המקור עצמו אלא נרשם ב-4625 של שרת היעד שקיבל את הניסיון, ובחשבון domain גם ב-4776 או 4771 בצד ה-DC
    src["מחשב מקור (אין בו 4625)"] -->|network logon| target["שרת היעד"]
    target -.-> e4625["4625 נרשם"]
    src -->|אימות חשבון domain| dc["domain controller"]
    dc -.-> e4776["4776 (NTLM) / 4771 (Kerberos)"]

איור 9: 4625 נשאר בצד שקיבל. אם במחשב המקור אין דבר, בודקים את שרת היעד ואת צד ה-DC.

4.4. משפחת 4720 — יצירת חשבון, שינוי והוספה לקבוצה

אירועי Account Management יוצרים רצף של מספרים סמוכים: 4720 (A user account was created)¹⁷, 4726 (נמחק), 4738 (שונה), ובצד הקבוצה, חבר נוסף/הוסר. שימו לב שאיזה Event ID נורה לשינוי חברות בקבוצה תלוי בסוג הקבוצה. זה 4732/4733 לקבוצות מקומיות, 4728/4729 לקבוצות global, ו-4756/4757 לקבוצות universal.¹⁴ Domain Admins היא קבוצה global, ולכן הוספה אליה מופיעה כ-4728 — אם מתריעים רק על 4732, מחמיצים בדיוק את האירוע שרוצים לתפוס ביותר. ביום-יום זה בעיקר תיעוד של עבודת תמיכה, אבל “משתמש רגיל נוסף פתאום לקבוצת Administrators” או “נוצר חשבון שאף אחד לא מכיר” מצדיקים חקירה גם כמופע בודד. Microsoft עצמה נותנת הוספות בלתי צפויות של חברים לקבוצות מורשות כדוגמה לאירוע שכדאי להתריע עליו בנפרד.³

flowchart TB
    accTitle: סוג הקבוצה ו-Event ID של הוספת חבר
    accDescr: הוספת חבר לקבוצה מתפצלת לפי סוג הקבוצה ל-Event ID, מקומית ב-4732, global ב-4728 ו-universal ב-4756, ולכן הוספה ל-Domain Admins שהיא קבוצה global נראית ב-4728
    add["הוספת חבר לקבוצה"] --> kind{"מה סוג הקבוצה?"}
    kind -->|מקומית| lg["נרשם ב-4732"]
    kind -->|global| gg["נרשם ב-4728"]
    kind -->|universal| ug["נרשם ב-4756"]
    gg -.-> da["הוספה ל-Domain Admins כאן"]
    lg -.-> miss["ניטור 4732 בלבד מחמיץ"]

איור 10: Event ID של הוספת חבר מתפצל לפי סוג הקבוצה. הוספה ל-Domain Admins היא 4728.

4.5. 4688 —‏ process creation. רישום command line הוא מתג נפרד

4688, “A new process has been created”, רושם את החשבון היוצר, את נתיב קובץ ההרצה של ה-process החדש, את parent process, ואת סוג הגבהת ה-token בכל פעם ש-process נוצר.¹¹ זה Event בעל ערך חקירתי גבוה שיכול לענות על “מי הרץ מה בשרת הזה”.

כברירת מחדל, עם זאת, command-line arguments אינם נרשמים. רק אחרי שמפעילים בנפרד את הגדרת Group Policy “Include command line in process creation events” (Administrative Templates > System > Audit Process Creation) השדה Process Command Line ב-4688 מתמלא ב-arguments.¹¹¹² זה למעשה חיוני למעקב אחרי הרצות חשודות כמו powershell -EncodedCommand ..., אבל מפעילים רק אחרי שמבינים את סיכון חשיפת הסודות שמתואר בפרק 7.

flowchart TB
    accTitle: הקשר בין 4688 לרישום command line
    accDescr: הפעלת audit של process creation רושמת ב-4688 חשבון, נתיב קובץ הרצה ו-parent process, אבל command-line arguments נרשמים רק אחרי הפעלת Group Policy נפרדת, עם סיכון שסודות ייכנסו בטקסט גלוי
    audit["הפעלת audit של process creation"] --> ev["4688 נרשם"]
    ev -.-> base["חשבון, נתיב, parent process"]
    ev --> args{"רוצים גם arguments?"}
    args -->|ברירת מחדל| none["command line ריקה"]
    args -->|הפעלת GPO נוספת| cmd["ה-arguments נרשמים"]
    cmd -.-> risk["סיכון שסודות בטקסט גלוי"]

איור 11: רישום command line של 4688 הוא מתג נפרד. לפני הפעלה בודקים סיכון של סודות.

4.6. 4698 — יצירת scheduled task

4698, “A scheduled task was created”, רושם את שם ה-task ואת XML המלא של הגדרת ה-task (כולל הפקודה שהיא מריצה). משום שרישום scheduled task הוא טכניקה נפוצה ש-malware משתמשת בה כדי לשרוד restart, Microsoft ממליצה לנטר Events של יצירת tasks.¹⁵ גם בסביבות שמשתמשות ב-scheduled tasks בכבדות לצרכים עסקיים, היצירה עצמה אינה דבר שקורה כל יום, ולכן רמת הרעש נשארת נמוכה יחסית.

flowchart TB
    accTitle: persistence ברישום task ו-4698
    accDescr: Malware נוהגת לרשום scheduled task כדי לשרוד restart, ולכן ניטור 4698 שנרשם ביצירת task מאפשר לעקוב עד הגדרת ה-task כולל פקודת ההרצה
    mal["persistence של malware"] --> task["נרשמת task כדי לשרוד"]
    task --> ev["4698 נרשם"]
    ev -.-> xml["XML מלא כולל פקודת הרצה"]
    ev --> watch["זיהוי בניטור יצירת tasks"]
    watch -.-> low["יצירה אינה יומיומית, רעש נמוך"]

איור 12: רישום task, אמצעי ה-persistence הנפוץ, נשאר ב-4698. אפשר לעקוב עד פקודת ההרצה ב-XML המלא.

עוד אחד שכדאי לזכור הוא 1102, “The audit log was cleared.” ניקוי Security log תמיד משאיר את ה-Event הזה מאחור, כך שאם מוצאים ש”היומן ריק”, אפשר להבחין בין אירוע לבין פעולה שגרתית.¹⁸

flowchart TB
    accTitle: הפרדה של מחיקת יומן לפי 1102
    accDescr: ניקוי Security log תמיד משאיר 1102, לכן כשהיומן ריק בודקים אם 1102 קיים כדי להפריד בין פעולת מחיקה לבין תקלה אפשרית
    empty["היומן ריק"] --> rule["ניקוי תמיד משאיר 1102"]
    rule --> check{"יש 1102?"}
    check -->|יש| op["הייתה פעולת מחיקה"]
    check -->|אין| acc["חושדים בתקלה"]

איור 13: ניקוי Security log תמיד משאיר 1102. יומן ריק מפרידים בין תקלה לפעולה לפי נוכחות 1102.

5. תכנון מיכל היומן — גודל מרבי ושמירה

לפני שמוסיפים עוד audit policy, בודקים את המיכל המקבל. ל-Security log יש גודל מרבי ומצב שמירה: במצב overwrite (התצורה הטיפוסית), ברגע שמגיעים לגודל המרבי, אירועים חדשים דורסים את הישנים ביותר. ולהפך, במצב שמירה (בלי overwrite), ברגע שהיומן מתמלא, האירועים החדשים הם אלה שמושלכים.¹⁰ כל אחת מההתנהגויות יכולה להשאיר אתכם עם “היומן שהייתי צריך פשוט אינו שם”, לכן הבנת המצב הנוכחי קודמת.

# בדיקת כלי הקיבול של Security log: מצב שמירה, גודל מרבי, מספר הרשומות כעת
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# כמה ימים באמת נשמרים עכשיו (חותמת הזמן של האירוע הישן ביותר)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog מחזיר יחד את תצורת היומן ואת מספר הרשומות.⁹ ההפרש בין “חותמת הזמן של האירוע הישן ביותר” לבין הזמן הנוכחי הוא טווח השמירה בפועל; אם זה נופל מהדרישה שלכם (כמה ימים אחורה רוצים להיות מסוגלים לחקור), מרחיבים את הגודל המרבי. אפשר להגדיר זאת ב-wevtutil sl Security /ms:<מספר בתים>, או לחלק דרך Group Policy.¹⁰

flowchart TB
    accTitle: תכנון קיבולת בחישוב לאחור מימי שמירה
    accDescr: בודקים תצורה ומספר ב-ListLog של Get-WinEvent, מחשבים את ימי השמירה בפועל מחותמת הזמן של האירוע הישן ביותר, ואם זה לא מספיק לימים שרוצים לחזור אחורה בחקירת אירוע מגדילים את הגודל המרבי
    check["אישור תצורה ומספר ב-ListLog"] --> oldest["בדיקת זמן האירוע הישן ביותר"]
    oldest --> days["חישוב ימי שמירה בפועל"]
    days --> enough{"מספיק לדרישה?"}
    enough -->|מספיק| keep["שומרים על הגודל הנוכחי"]
    enough -->|לא מספיק| grow["מגדילים את הגודל המרבי"]
    grow -.-> how["הגדרה ב-wevtutil sl או GPO"]

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

יש גם אפשרות אבטחה בשם “Audit: Shut down system immediately if unable to log security audits” (ידועה בכינוי CrashOnAuditFail). כשהיא מופעלת, אם המערכת אינה יכולה לרשום Event audit, היא נעצרת בשגיאת STOP C0000244. היא קיימת לדרישות אימות שלא יכולות להרשות לעצמן לאבד עקבות audit, וכבויה כברירת מחדל. Microsoft עצמה מזהירה שזה יכול להפוך ל-DoS, כשתוקף מייצר במכוון שיטפון אירועים כדי לעצור שרת — לכן זה אינו דבר שמפעילים בקלות בסביבה קטנה-עד-בינונית טיפוסית.¹⁹

flowchart TB
    accTitle: ההתנהגות כשהיומן מתמלא
    accDescr: תצורת השמירה היא מצב overwrite או מצב בלי overwrite, ובמצב בלי overwrite כשאי אפשר לרשום audit, אם CrashOnAuditFail שהוא הגדרה נפרדת מופעל המערכת נעצרת בשגיאת STOP C0000244
    full["Security log הגיע לגודל המרבי"] --> mode{"מה תצורת השמירה?"}
    mode -->|מצב overwrite| ow["האירוע הישן ביותר נדרס"]
    mode -->|בלי overwrite| drop["אירועים חדשים מושלכים"]
    ow -.-> lost["בשניהם הסיבה ל\"אין יומן\""]
    drop -.-> lost
    drop --> caf{"גם CrashOnAuditFail פעיל?"}
    caf -->|כן| crash["עצירה ב-STOP C0000244"]

איור 15: תצורת השמירה היא overwrite או השמדה. CrashOnAuditFail הוא הגדרה נפרדת שעוצרת כשאי אפשר לרשום.

6. חקירה מעשית — סינון, Get-WinEvent וייצוא

6.1. צמצום ב-Event Viewer

לחקירה חד-פעמית, Event Viewer מספיק. פותחים את Security log ומציינים Event ID (למשל 4625) וטווח זמן ב-“Filter Current Log”. תנאים שבודקים שוב ושוב שומרים כ-Custom View, כך שבפעם הבאה הם בלחיצה אחת. אם רוצים לצמצם לפי חשבון מסוים ולא רק לפי Event ID, אפשר לערוך את שאילתת ה-XPath ישירות בלשונית XML של תיבת הסינון.

6.2. חילוץ עם Get-WinEvent

לחקירות עם מספר רשומות גדול, כמה תנאים, או הרצות מתוזמנות, עוברים ל-Get-WinEvent של PowerShell. הנקודה המרכזית היא להשתמש ב--FilterHashtable, שמחיל את הסינון בצד השרת.⁹

flowchart TB
    accTitle: בחירת אמצעי החקירה
    accDescr: חקירה חד-פעמית מספיקה בסינון Event Viewer, תנאי שחוזרים אליו שומרים ב-Custom View, וחקירה עם הרבה רשומות או כמה תנאים או הרצה מחזורית עוברת ל-Get-WinEvent
    q{"איזה סוג חקירה?"}
    q -->|חד-פעמי| viewer["צמצום ב-Event Viewer"]
    q -->|תנאי שחוזרים אליו| view["שמירה ב-Custom View"]
    q -->|כמות / כמה תנאים / מחזורי| ps["מעבר ל-Get-WinEvent"]
    ps -.-> hash["צמצום ב-FilterHashtable"]

איור 16: חד-פעמי ב-Event Viewer, חוזר — ב-Custom View, הרבה רשומות — ב-Get-WinEvent.

# שליפת כשלונות logon (4625) מ-24 השעות האחרונות
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# לעצב "מי, מאיפה ולמה" לטבלה
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

ברגע שיש את התבנית הזאת של שליפת EventData מייצוג ה-XML של Event, אפשר לעשות בה שימוש חוזר כפי שהיא ל-4624 או ל-4688. תכנון הסינון של Get-WinEvent — מתי להשתמש ב-FilterHashtable מול XPath, ואיך לתקן שאילתה איטית — מכוסה בפירוט ב”חקירת Event Logs בפועל עם Get-WinEvent — מהירות הסינון קובעת את זמן החקירה”.

flowchart TB
    accTitle: תבנית העיצוב ששולפת EventData
    accDescr: ממירים Event שהתקבל ב-Get-WinEvent לייצוג XML, שולפים כל שדה מ-EventData ומעצבים לטבלה, ותבנית זו ניתנת לשימוש חוזר באותו אופן גם ב-4624 וגם ב-4688 ולא רק ב-4625
    get["שליפה ב-Get-WinEvent"] --> xml["המרה לייצוג XML"]
    xml --> pull["שליפת EventData"]
    pull --> shape["עיצוב לטבלה וסיכום"]
    shape -.-> reuse["אותו אופן גם ב-4624 ו-4688"]

איור 17: התבנית ששולפת EventData מה-XML ומעצבת טבלה ניתנת לשימוש חוזר גם כש-Event ID משתנה.

6.3. ייצוא עם wevtutil

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

rem שימור Security log כולו כ-evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem ייצוא אירועי 4625 בלבד, מצומצמים ב-XPath
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

קובץ .evtx שיוצא אפשר לנתח במכונה אחרת באותו אופן בדיוק, עם Get-WinEvent -Path C:\logs\security-20260801.evtx.⁹ ההרגל לשמר לפני שמנתחים הוא אותה גישה כמו “קודם מבטיחים את ה-dump” בחקירת קריסה (ראו “מבוא לאיסוף crash dump ב-Windows - WER/ProcDump/WinDbg”).

flowchart TB
    accTitle: הזרימה של שימור ואחר כך ניתוח
    accDescr: מייצאים את Security log של מכונת היעד לקובץ evtx ב-wevtutil epl כדי להבטיח אותו, ואז מנתחים באותו אופן במכונה אחרת עם Path של Get-WinEvent
    target["מכונת היעד לחקירה"] --> export["שימור ל-evtx ב-wevtutil epl"]
    export --> copy["הוצאה למכונה אחרת"]
    copy --> analyze["ניתוח ב-Get-WinEvent -Path"]
    export -.-> note["הבטחה לפני overwrite"]

איור 18: קודם משמרים, אחר כך מנתחים. אם הבטחתם ב-evtx אפשר לבדוק באותו אופן במכונה אחרת.

7. מלכודות — ארבע שקל לדרוך עליהן בשטח

(1) סודות נוחתים ב-command line של 4688. הפעלת רישום command line מכניסה את ה-arguments של כל process ל-Security log בטקסט גלוי. Microsoft קובעת במפורש ש”כל משתמש עם גישת קריאה ל-security events יוכל לקרוא את command-line arguments של כל process שנוצר בהצלחה. Command-line arguments עלולים להכיל מידע רגיש או פרטי כמו סיסמאות.” ¹² אם אפילו אפליקציה עסקית אחת או סקריפט אחד מריצים משהו כמו myapp.exe /user:admin /password:P@ssw0rd, זה סוד שנחשף לכל מי שיכול לצפות ביומן. לפני שמפעילים, ממפים מקומות שמעבירים סודות כ-command-line arguments ומתקנים אותם. גם המקום שאליו מייצאים או מעבירים את היומן צריך טיפול באותה רמת סודיות.

flowchart TB
    accTitle: הסדר שבו מפעילים רישום command line
    accDescr: לפני הפעלת רישום command line של 4688 ממפים אפליקציות עסקיות וסקריפטים שמעבירים סודות ב-arguments, מתקנים את המקומות האלה ואז מפעילים, ודורשים אותה רמת טיפול גם ביעד השימור וההעברה
    audit["מיפוי העברת סודות ב-arguments"] --> found{"יש התאמה?"}
    found -->|יש| fix["מתקנים את המקומות שמעבירים"]
    found -->|אין| on["הפעלת רישום command line"]
    fix --> on
    on -.-> dest["גם יעד השימור באותה רמת טיפול"]

איור 19: רישום command line הוא “למפות, לתקן, ואז להפעיל”. סדר הפוך הופך לסוד גלוי.

(2) מפעילים בלי לדעת מה קורה כשהיומן מתמלא. במצב overwrite ראיות ישנות נעלמות בשקט; במצב בלי overwrite אירועים חדשים מושלכים; ועם CrashOnAuditFail מופעל המערכת כולה נעצרת (פרק 5).¹⁰¹⁹ הגישה הנכונה היא לדעת איזו התנהגות בחרתם, ולשים מנגנון — ייצוא מתוזמן, או פלטפורמת איסוף יומנים — שאוסף את הנתונים לפני שהם נדרסים.

(3) Domain controllers ותחנות עבודה דורשים להסתכל ביומנים שונים. 4624/4625 נרשמים במכונה שאליה ניגשו.⁵⁶ Credential validation לחשבון domain (4776 של NTLM), לעומת זאת, נרשם במכונה שיש לה סמכות על ה-credential — לחשבון domain זה ה-DC⁷ — וכישלון Kerberos pre-authentication (4771) נרשם רק ב-DC.⁸ “אין 4625 ב-file server” אינו אומר “לא הייתה התקפה”; את התמונה המלאה מקבלים רק אחרי שמצליבים גם 4776/4771 ב-DC. ראו “NTLM ו-Kerberos בתרשימים — למה האימות נופל ל-NTLM” לאיך כל פרוטוקול אימות באמת זורם.

(4) סחיפת שעון שוברת הצלבה. סידור יומנים מכמה מכונות כדי לעקוב אחרי “באיזו תחנה יצא 4625 ממש לפני ה-4740 הזה” עובד רק אם השעון של כל מכונה מסכים. בסביבת domain, Kerberos עצמו מטיל חסם עליון על סחיפת שעון (5 דקות כברירת מחדל), ומעבר לו האימות עצמו מתחיל להיכשל.²⁰ מבחינה חקירתית, סטייה של אפילו כמה שניות — שלא לדבר על חמש דקות — יכולה לגרום לקרוא לא נכון את סדר האירועים, לכן בדיקת מצב הסנכרון של w32time צריכה להיות הצעד הראשון ממש בהליך החקירה. זכרו גם שחותמות זמן של Events נשמרות ב-UTC ומוצגות לפי אזור הזמן של מכונת הצפייה, לכן ממירים אזורי זמן כשקוראים evtx שהובא מאתר בחו״ל או משרת שמוגדר ל-UTC.

flowchart TB
    accTitle: ההנחה של סנכרון שעון והצלבת חקירה
    accDescr: חקירה שמצליבה יומנים מכמה מכונות לפי סדר הזמן מניחה שהשעונים תואמים, סטייה של שניות בודדות כבר מטעה בקריאת הסדר, וסטייה מעבר ל-5 דקות ברירת המחדל מפילה את אימות Kerberos עצמו, לכן מכניסים בדיקת w32time לתחילת ההליך
    merge["הצלבת יומנים מכמה מכונות"] --> pre["ההנחה שהשעונים תואמים"]
    pre --> skew{"מה סטיית השעון?"}
    skew -->|תואמים| ok["אפשר לעקוב לפי זמן"]
    skew -->|סטייה של שניות| misread["קריאת סדר שגויה"]
    skew -->|מעבר ל-5 דקות ברירת מחדל| kerb["אימות Kerberos נכשל"]
    pre -.-> first["בדיקת w32time בתחילת ההליך"]

איור 20: הצלבת כמה מכונות מניחה סנכרון שעון. סטייה של שניות בודדות כבר מטעה בקריאת הסדר.

8. סיכום

• ל-audit policy יש שתי מערכות, “basic” ו-“advanced”, וערבוב שלהן מייצר תוצאות בלתי צפויות. מאחדים לצד המתקדם, בודקים את המצב הנוכחי ב-auditpol /get /category:*, ומתכננים משם.
• “להפעיל הכול” הורג את החקירה ברעש ובניפוח. מתחילים מהמלצות הבסיס של Microsoft ועובדים דרך טבלת ההחלטה בפרק 3, שנבנתה סביב logon, Account Management ו-process creation.
• 4624 נקרא לפי Logon Type, 4625 לפי קוד Status/Sub Status, 4740 לפי Caller Computer Name, ו-4688 לפי parent process ו-command line — לכל Event יש שדה מסוים שצריך לבדוק.
• מיכל היומן (גודל מרבי ומצב שמירה) הוא חצי מתכנון ה-audit. בודקים כמה ימים באמת נשמרים, מתאימים גודל בחישוב לאחור מהדרישה, ומייצאים או אוספים לפני overwrite.
• בודקים את סיכון חשיפת הסודות לפני הפעלת רישום command line ל-4688. איפה כל Event נרשם, וסנכרון שעון, הם תנאים מוקדמים להצלבה בין מכונות.
• מתחילים חקירה בסינון של Event Viewer; עוברים ל-Get-WinEvent -FilterHashtable לכל דבר שחוזר; משמרים ב-wevtutil epl. לא שוברים את הסדר של “קודם משמרים, אחר כך מנתחים”.

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

• חקירת Event Logs בפועל עם Get-WinEvent — מהירות הסינון קובעת את זמן החקירה
• האם ביטול NTLM יעצור אפליקציות עסקיות? — איך לאסוף יומני audit וסדר ביטול התלויות
• NTLM ו-Kerberos בתרשימים — למה האימות “נופל” ל-NTLM
• SMB signing ו-LDAP Channel Binding — סגירת “החצי השני” של הגנת NTLM בפועל
• מבוא ל-Event Log של Windows ול-ETW — הנחת יומני האפליקציה העסקית על מנגנוני הסטנדרט של מערכת ההפעלה
• מבוא לאיסוף crash dump ב-Windows - WER, ProcDump, WinDbg

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בייעוץ על audit policy ותכנון יומנים בסביבת Windows, בחקירת “מתי, מי ומה” על בסיס Event Log, ובניתוח סיבות לתקלות שקשורות לאימות ול-audit באפליקציות עסקיות. בסדר להתחיל משלב “אמרו לי להסתכל ביומנים, ואני לא יודע מאיפה להתחיל”.

• חקירת תקלות ואיתור גורמים
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

מקורות

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

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

נושאים קשורים

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

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

לא הגדרנו שום audit policy, אז למה 4624 ו-4625 כבר מופיעים ב-Security log?

כי ב-Windows יש audit subcategories שמופעלות כברירת מחדל. תת-הקטגוריה Logon, למשל, מופעלת להצלחה ולכישלון יחד מאז Windows 10 גרסה 1809, ולכן 4624 (הצלחה) ו-4625 (כישלון) נרשמים גם בלי שהגדרתם דבר. עם ברירת המחדל כפי שהיא, עם זאת, רבים מהאירועים שבאמת רוצים בחקירה — Credential validation (4776) או process creation (4688), למשל — אינם נרשמים. אפשר לבדוק מה מופעל בסביבה שלכם ב-`auditpol /get /category:*`. משם, הפרקטיקה הסטנדרטית היא להפעיל במפורש את ה-subcategories החסרות בצד Advanced Audit Policy.

אני רוצה לחקור logon שנכשל, אבל איני מוצא את Event 4625 ב-Security log של שרת היעד. איפה להסתכל?

קודם מאשרים את העיקרון: 4625 נרשם ב"מחשב שבו ניסו לעשות logon". Logon שנכשל בתחנת המשתמש — זו התחנה; ניסיון גישה שנכשל מול file server — זה ה-file server. אחר כך בודקים ב-`auditpol /get /category:*` אם audit של כישלון מופעל לתת-הקטגוריה Logon. בחשבונות domain העקבות מופיעות לעיתים קרובות ב-Credential validation (4776) או בכישלון Kerberos pre-authentication (4771) ב-domain controller, וכשאי אפשר לנעוץ איזו תחנה מעורבת, לרוב מהיר יותר להתחיל מצד ה-DC. אם עדיין אין דבר, בודקים אם אירועים ישנים כבר נדרסו (משווים את הגודל המרבי של היומן לחותמת הזמן של האירוע הישן ביותר).

האם להפעיל רישום command line ל-process creation (4688)?

הערך החקירתי גבוה מאוד, אבל זו הגדרה שמפעילים רק אחרי שמבינים את הסיכון. ברגע שהיא מופעלת, command-line arguments של כל process נרשמים ב-Security log בטקסט גלוי. אם אפילו סקריפט אחד או אפליקציה עסקית אחת מעבירים סיסמה או מפתח API כ-argument, הסוד הזה נראה לכל מי שיכול לקרוא את ה-Security log. Microsoft עצמה מתעדת את האזהרה הזאת במפורש. הסדר המומלץ הוא קודם לבדוק אם הסקריפטים שלכם מעבירים סודות כ-arguments, לתקן כל מקום שכן, ורק אז להפעיל.

מה צריך להיות הגודל המרבי של Security log?

הגישה הנכונה היא לחשב לאחור מ"כמה ימים רוצים להשאיר בהישג יד", לא לבחור מספר אחד שמתאים לכולם. את ההגדרה הנוכחית ואת ההתנהגות בפועל בודקים ב-`Get-WinEvent -ListLog Security`; ההפרש בין חותמת הזמן של האירוע הישן ביותר לבין הזמן הנוכחי הוא "כמה ימים באמת נשמרים עכשיו". הוספת audit subcategories מגדילה את נפח האירועים, לכן תמיד בודקים מחדש את טווח השמירה בפועל אחרי שינוי הגדרות. בטיפול באירוע לא נדיר שצריך יומנים משבועות או חודשים אחורה, ולכן מרגיע לייצא את היומן באופן קבוע לפני שהוא נדרס, או לאסוף אותו למכונה נפרדת במנגנון איסוף יומנים.

איך חוקרים את סיבת נעילת חשבון (4740)?

הרמז הראשון הוא השדה Caller Computer Name ב-Event 4740. הוא רושם את המחשב שממנו יצא ניסיון ה-logon שנכשל והפעיל את הנעילה. שימו לב, עם זאת, שרשומת הכישלון עצמה (4625) נשארת בצד שקיבל את ניסיון ה-logon, לא במכונת המקור. אם המקור הוא network logon, עוקבים לפי סדר הזמן דרך 4625 בשרת היעד, או בחשבון domain דרך 4776/4771 ב-domain controller. אחרי שזיהיתם את מכונת המקור, בודקים בה כל דבר שעדיין מחזיק credentials ישנים מלפני החלפת הסיסמה — credentials שמורים, הפעלת Remote Desktop מנותקת שנשארה תלויה, או service ו-scheduled task שהוגדרו עם הסיסמה הישנה. אם הנעילות חוזרות, בודקים גם אם סנכרון השעון נסחף.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

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