מדיניות ביקורת אבטחה ב-Windows וחקירת יומן אירועים בפועל — איך להפוך לצוות IT שיודע לקרוא את 4625

«חשבון ננעל שוב ושוב מאמש. תבררו למה.» «רוצה לבדוק אם מישהו ניסה להיכנס עם חשבון של עובד שעזב.» «אפשר לדעת מי עשה מה, ומתי, בשרת הזה?» — אלה הבקשות שאנשי מערכות מידע בעסקים קטנים ובינוניים, או מפתחים שמסרו מערכת ללקוח, מקבלים פתאום ביום אחד. והדבר שהם נשענים עליו הוא יומן האירועים Security של Windows.

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

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

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

המאמר מסדר את מנגנון מדיניות הביקורת (שתי המערכות — בסיסית ומתקדמת), את תת-הקטגוריות שכדאי להפעיל לפחות בסביבה קטנה-עד-בינונית, איך לקרוא את מזהי האירוע הסטנדרטיים — 4624/4625/4740/4688 ואחרים — תכנון קיבולת יומן Security, ואיך חוקרים ב-PowerShell, על בסיס מקורות ראשוניים נכון לאוגוסט 2026. אם מאמרי ביקורת NTLM, חתימת SMB, BitLocker וחומת האש באתר הזה הם כולם על «חיזוק ההגנות», המאמר הזה הוא על «לאפשר לאשר אחר כך מה קרה» — המשך שקושר אותם יחד.

1. השורה התחתונה קודם

• למדיניות ביקורת יש שתי מערכות — «בסיסית» ו«מתקדמת (Advanced Audit Policy)» — ואסור לערבב אותן. Microsoft קובעת במפורש ששימוש בשתיהן משאיר את תוצאות הביקורת במצב בלתי צפוי. מאחדים לצד המתקדם (יותר מ-40 תת-קטגוריות).¹
• את המצב הנוכחי בודקים ב-auditpol /get /category:*. זו רשימה של מה שבתוקף עכשיו בפועל, בלי קשר אם זה הגיע מ-GPO או מהגדרה מקומית.²
• «להפעיל הכול» זה דבר שאסור לעשות. הפעלת תת-קטגוריות שמייצרות נפח אירועים עצום קוברת את האירועים שחשובים באמת תחת רעש, ופוגעת גם בביצועים. מתחילים מהמלצות הבסיס של Microsoft ומוסיפים רק מה שצריך.³⁴
• כניסה מוצלחת היא 4624; כניסה שנכשלה היא 4625. ב-4624 קוראים «איזה סוג כניסה זו הייתה» מסוג הכניסה (2 = Interactive, 3 = Network, 10 = RemoteInteractive, וכן הלאה).⁵
• ב-4625, קוד Status/Sub Status אומר את סיבת הכישלון. הסטנדרטיים הם 0xC0000064 = שם משתמש שאינו קיים, 0xC000006A = סיסמה שגויה, 0xC0000072 = חשבון מושבת, ו-0xC0000234 = החשבון נעול.⁶
• איפה אירוע נרשם קבוע. 4624/4625 נרשמים במכונה שאליה ניגשו; אימות אישורים (4776) וכישלון קדם-אימות Kerberos (4771) נרשמים בבקר הדומיין. מסתכלים במכונה הלא נכונה ומסיקים בטעות «אין יומן».⁶⁷⁸
• חצי מתכנון יומן Security הוא המיכל עצמו — גודל מרבי ושמירה. אם השמירה מוגדרת לדריסה, אירועים ישנים נעלמים ראשונים. בודקים גודל מרבי ומספר רשומות ב-Get-WinEvent -ListLog Security, ומרחיבים בחישוב לאחור ממספר הימים שצריך באמת לשמור.⁹¹⁰
• רישום שורת פקודה ליצירת תהליך (4688) חזק, אבל המחיר הוא שסודות נוחתים ביומן בטקסט גלוי. בודקים את הסקריפטים לפני שמפעילים.¹¹¹²

2. יסודות מדיניות הביקורת — לא לערבב «בסיסית» ו«מתקדמת»

למדיניות הביקורת של Windows יש שתי מערכות.¹

• מדיניות ביקורת בסיסית: תשע הגדרות הקטגוריה תחת «מדיניות מקומית > מדיניות ביקורת». זו המערכת הישנה, מלפני Windows Vista.
• תצורת מדיניות ביקורת מתקדמת (Advanced Audit Policy Configuration): יותר מ-40 הגדרות תת-קטגוריה תחת «הגדרות אבטחה > תצורת מדיניות ביקורת מתקדמת». היא מפרקת כל קטגוריה בסיסית לכמה תת-קטגוריות — למשל, הקטגוריה הבסיסית היחידה «ביקורת אירועי כניסה לחשבון» מקבילה לארבע תת-קטגוריות בצד המתקדם. הפעלת קטגוריה בסיסית אחת שקולה להפעלת כל תת-הקטגוריות המתאימות, וזה רושם נפח גדול של אירועים שאולי כלל לא מעניינים אתכם.¹

הנקודה החשובה היא ששתי המערכות האלה אינן תואמות זו לזו. Microsoft אומרת בפשטות: «אל תשתמשו גם במדיניות ביקורת בסיסית וגם במתקדמת — זה יכול להוביל לתוצאות ביקורת בלתי צפויות.» כשמדיניות ביקורת מתקדמת מוחלת דרך Group Policy, הגדרות הביקורת הקיימות במחשב מנוקות תחילה ואז מוחלות ההגדרות המתקדמות; משם והלאה רק הצד המתקדם יכול לשלוט בביקורת באופן אמין. בסביבות שמשתמשות בצד המתקדם, מפעילים את אפשרות האבטחה «ביקורת: אכיפת הגדרות תת-קטגוריית מדיניות ביקורת כדי לדרוס הגדרות קטגוריית מדיניות ביקורת» כדי שההגדרות הבסיסיות לא יוכלו לדרוס אותה (במכונות עצמאיות זה מופעל כברירת מחדל).¹⁴

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

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

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

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

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

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

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

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

3. טבלת החלטה לתת-הקטגוריות המינימליות להפעלה

ברור למה «פשוט נפעיל הכול, ליתר ביטחון» הוא מהלך גרוע. למשל, Microsoft מזהירה שביקורת הצלחה לתת-קטגוריות של שימוש בהרשאות מייצרת נפח אירועים כה עצום עד שקשה למצוא ערכים אחרים ביומן האבטחה, ושיש גם השפעה משמעותית על הביצועים.⁴ מיכל היומן (פרק 5) סופי, ולכן ככל שרושמים יותר רעש, כך נאכל יותר מטווח השמירה של האירועים שבאמת צריך. תכנון ביקורת הוא בעצם להחליט מה לא לרשום.

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

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

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

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

flowchart TB
    accTitle: איך מטפלים בתת-קטגוריות עתירות אירועים
    accDescr: ביקורת גישה לאובייקטים של מערכת קבצים או רישום, שימוש בהרשאות ומסנן מנות אוכלים את היומן אם משאירים אותם פתוחים תמיד, ולכן הם מועילים רק ב-SACL מצומצם או בתקופת חיתוך מוגבלת
    heavy["תת-קטגוריות עתירות אירועים"] --> use{"איך מפעילים?"}
    heavy -.-> ex1["ביקורת גישה לאובייקטים"]
    heavy -.-> ex2["שימוש בהרשאות ומסנן מנות"]
    use -->|פתוח תמיד| eat["היומן נאכל"]
    use -->|SACL מצומצם| ok1["מועיל"]
    use -->|רק לתקופת חיתוך| ok2["מועיל"]

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

4. איך לקרוא את מזהי האירוע הסטנדרטיים

4.1. 4624 — כניסות מוצלחות ממוינות לפי סוג כניסה

4624, «חשבון נכנס בהצלחה», נרשם במכונה שבה נוצרה הפעלת הכניסה (המכונה שאליה ניגשו).⁵ משום שזה אירוע בנפח גבוה, הצעד הראשון בקריאה הוא למיין לפי סוג כניסה (Logon Type).⁵

שדות נוספים שכדאי לבדוק לצד זה הם שם החשבון תחת «כניסה חדשה», כתובת המקור תחת «מידע רשת», «חבילת האימות» (NTLM או Kerberos), ו«אסימון מוגבה» (האם להפעלה יש הרשאות מנהל). אם רוצים לעקוב רק אחרי כניסות עם הרשאות מנהל, גם אירוע 4672 (הרשאות מיוחדות הוקצו לכניסה חדשה), שנרשם תחת אותו Logon ID, שימושי.⁵

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

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

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

4625, «חשבון נכשל בכניסה», נרשם במכונה שבה ניסו להיכנס.⁶ במקום לסמוך על ניסוח השדה «סיבת הכישלון», הדרך האמינה לקרוא היא לפי קוד Status/Sub Status ההקסדצימלי. הסטנדרטיים הם כדלקמן.⁶

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

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

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

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

4.3. 4740 — מקור הנעילה הוא «שם מחשב הקורא»

4740, «חשבון משתמש ננעל» (תת-קטגוריה: ניהול חשבונות משתמש). השדה המרכזי באירוע הזה הוא «שם מחשב הקורא (Caller Computer Name)», שרושם את המחשב שממנו יצא ניסיון הכניסה שהפעיל את הנעילה.¹⁶ ההליך הסטנדרטי הוא לזהות את מכונת המקור מהשדה הזה, ואז לחפש אישורים ישנים שעדיין שמורים באותה מכונה. ברוב המקרים הסיבה היא משהו שממשיך להשתמש באישורים ישנים אחרי החלפת סיסמה — אישורים שמורים, הפעלת RDP מנותקת שנשארה תלויה, או שירות ומשימה מתוזמנת שהוגדרו עם הסיסמה הישנה.

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

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

יש דבר אחד להיזהר ממנו. 4625 נרשם במחשב שקיבל את ניסיון הכניסה. אם הסיבה היא כניסת רשת ממכונת המקור אל, למשל, שרת קבצים, אין 4625 ביומן Security של מכונת המקור עצמה; במקום זה העקבות נשארות ב-4625 בשרת היעד, או בחשבון דומיין ב-4776 (NTLM) או 4771 (כישלון קדם-אימות Kerberos) ב-DC.⁷⁸ כש«אין דבר ביומן במכונת המקור», הולכים להסתכל בצד המקבל.

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

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

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

אירועי ניהול החשבונות יוצרים רצף של מספרים סמוכים: 4720 (חשבון משתמש נוצר)¹⁷, 4726 (נמחק), 4738 (שונה), ובצד הקבוצה, חבר נוסף/הוסר. שימו לב שאיזה מזהה אירוע נורה לשינוי חברות בקבוצה תלוי בסוג הקבוצה. זה 4732/4733 לקבוצות מקומיות, 4728/4729 לקבוצות גלובליות, ו-4756/4757 לקבוצות אוניברסליות.¹⁴ Domain Admins היא קבוצה גלובלית, ולכן הוספה אליה מופיעה כ-4728 — אם מתריעים רק על 4732, מחמיצים בדיוק את האירוע שרוצים לתפוס ביותר. ביום-יום זה בעיקר תיעוד של עבודת תמיכה, אבל «משתמש רגיל נוסף פתאום לקבוצת מנהלים» או «נוצר חשבון שאף אחד לא מכיר» מצדיקים חקירה גם כמופע בודד. Microsoft עצמה נותנת הוספות בלתי צפויות של חברים לקבוצות מורשות כדוגמה לאירוע שכדאי להתריע עליו בנפרד.³

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

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

4.5. 4688 — יצירת תהליך. רישום שורת פקודה הוא מתג נפרד

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

כברירת מחדל, עם זאת, ארגומנטי שורת הפקודה אינם נרשמים. רק אחרי שמפעילים בנפרד את הגדרת Group Policy «כלול שורת פקודה באירועי יצירת תהליך» (תבניות ניהול > מערכת > ביקורת יצירת תהליך) השדה «שורת הפקודה של התהליך» ב-4688 מתמלא בארגומנטים.¹¹¹² זה למעשה חיוני למעקב אחרי הרצות חשודות כמו powershell -EncodedCommand ..., אבל מפעילים רק אחרי שמבינים את סיכון חשיפת הסודות שמתואר בפרק 7.

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

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

4.6. 4698 — יצירת משימה מתוזמנת

4698, «משימה מתוזמנת נוצרה», רושם את שם המשימה ואת XML המלא של הגדרת המשימה (כולל הפקודה שהיא מריצה). משום שרישום משימה מתוזמנת הוא טכניקה נפוצה שנוזקה משתמשת בה כדי לשרוד הפעלה מחדש, Microsoft ממליצה לנטר אירועי יצירת משימות.¹⁵ גם בסביבות שמשתמשות במשימות מתוזמנות בכבדות לצרכים עסקיים, היצירה עצמה אינה דבר שקורה כל יום, ולכן רמת הרעש נשארת נמוכה יחסית.

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

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

עוד אחד שכדאי לזכור הוא 1102, «יומן הביקורת נוקה.» ניקוי יומן Security תמיד משאיר את האירוע הזה מאחור, כך שאם מוצאים ש«היומן ריק», אפשר להבחין בין אירוע לבין פעולה שגרתית.¹⁸

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

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

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

לפני שמוסיפים עוד מדיניות ביקורת, בודקים את המיכל המקבל. ליומן Security יש גודל מרבי ומצב שמירה: במצב דריסה (התצורה הטיפוסית), ברגע שמגיעים לגודל המרבי, אירועים חדשים דורסים את הישנים ביותר. ולהפך, במצב שמירה (בלי דריסה), ברגע שהיומן מתמלא, האירועים החדשים הם אלה שמושלכים.¹⁰ כל אחת מההתנהגויות יכולה להשאיר אתכם עם «היומן שהייתי צריך פשוט אינו שם», לכן הבנת המצב הנוכחי קודמת.

# בדיקת כלי הקיבול של יומן Security: מצב שמירה, גודל מרבי, מספר הרשומות כעת
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: מאשרים כמה ימים באמת נשארים, ומחשבים לאחור את הגודל המרבי לפי מספר הימים שרוצים לחזור אחורה.

יש גם אפשרות אבטחה בשם «ביקורת: כבה את המערכת מיד אם לא ניתן לרשום ביקורות אבטחה» (ידועה בכינוי CrashOnAuditFail). כשהיא מופעלת, אם המערכת אינה יכולה לרשום אירוע ביקורת, היא נעצרת בשגיאת STOP C0000244. היא קיימת לדרישות אימות שלא יכולות להרשות לעצמן לאבד עקבות ביקורת, וכבויה כברירת מחדל. Microsoft עצמה מזהירה שזה יכול להפוך ל-DoS, כשתוקף מייצר במכוון שיטפון אירועים כדי לעצור שרת — לכן זה אינו דבר שמפעילים בקלות בסביבה קטנה-עד-בינונית טיפוסית.¹⁹

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

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

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

6.1. צמצום במציג האירועים

לחקירה חד-פעמית, מציג האירועים מספיק. פותחים את יומן Security ומציינים מזהה אירוע (למשל 4625) וטווח זמן ב«סנן יומן נוכחי». תנאים שבודקים שוב ושוב שומרים כ«תצוגה מותאמת», כך שבפעם הבאה הם בלחיצה אחת. אם רוצים לצמצם לפי חשבון מסוים ולא רק לפי מזהה אירוע, אפשר לערוך את שאילתת ה-XPath ישירות בלשונית XML של תיבת הסינון.

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

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

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

איור 16: חד-פעמי במציג האירועים, חוזר — בתצוגה מותאמת, הרבה רשומות — ב-Get-WinEvent.

# שליפת כשלונות כניסה (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 של אירוע, אפשר לעשות בה שימוש חוזר כפי שהיא ל-4624 או ל-4688. תכנון הסינון של Get-WinEvent — מתי להשתמש ב-FilterHashtable מול XPath, ואיך לתקן שאילתה איטית — מכוסה בפירוט ב«חקירת יומני אירועים בפועל עם Get-WinEvent — מהירות הסינון קובעת את זמן החקירה».

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

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

6.3. ייצוא עם wevtutil

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

rem שימור יומן Security כולו כ-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 של מכונת היעד לקובץ evtx ב-wevtutil epl כדי להבטיח אותו, ואז מנתחים באותו אופן במכונה אחרת עם Path של Get-WinEvent
    target["מכונת היעד לחקירה"] --> export["שימור ל-evtx ב-wevtutil epl"]
    export --> copy["הוצאה למכונה אחרת"]
    copy --> analyze["ניתוח ב-Get-WinEvent -Path"]
    export -.-> note["הבטחה לפני דריסה"]

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

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

(1) סודות נוחתים בשורת הפקודה של 4688. הפעלת רישום שורת פקודה מכניסה את הארגומנטים של כל תהליך ליומן Security בטקסט גלוי. Microsoft קובעת במפורש ש«כל משתמש עם גישת קריאה לאירועי אבטחה יוכל לקרוא את ארגומנטי שורת הפקודה של כל תהליך שנוצר בהצלחה. ארגומנטי שורת פקודה עלולים להכיל מידע רגיש או פרטי כמו סיסמאות.» ¹² אם אפילו אפליקציה עסקית אחת או סקריפט אחד מריצים משהו כמו myapp.exe /user:admin /password:P@ssw0rd, זה סוד שנחשף לכל מי שיכול לצפות ביומן. לפני שמפעילים, ממפים מקומות שמעבירים סודות כארגומנטי שורת פקודה ומתקנים אותם. גם המקום שאליו מייצאים או מעבירים את היומן צריך טיפול באותה רמת סודיות.

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

איור 19: רישום שורת פקודה הוא «למפות, לתקן, ואז להפעיל». סדר הפוך הופך לסוד גלוי.

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

(3) בקרי דומיין ותחנות עבודה דורשים להסתכל ביומנים שונים. 4624/4625 נרשמים במכונה שאליה ניגשו.⁵⁶ אימות אישורים לחשבון דומיין (4776 של NTLM), לעומת זאת, נרשם במכונה שיש לה סמכות על האישור — לחשבון דומיין זה ה-DC⁷ — וכישלון קדם-אימות Kerberos (4771) נרשם רק ב-DC.⁸ «אין 4625 בשרת הקבצים» אינו אומר «לא הייתה התקפה»; את התמונה המלאה מקבלים רק אחרי שמצליבים גם 4776/4771 ב-DC. ראו «NTLM ו-Kerberos בתרשימים — למה האימות נופל ל-NTLM» לאיך כל פרוטוקול אימות באמת זורם.

(4) סחיפת שעון שוברת הצלבה. סידור יומנים מכמה מכונות כדי לעקוב אחרי «באיזו תחנה יצא 4625 ממש לפני ה-4740 הזה» עובד רק אם השעון של כל מכונה מסכים. בסביבת דומיין, Kerberos עצמו מטיל חסם עליון על סחיפת שעון (5 דקות כברירת מחדל), ומעבר לו האימות עצמו מתחיל להיכשל.²⁰ מבחינה חקירתית, סטייה של אפילו כמה שניות — שלא לדבר על חמש דקות — יכולה לגרום לקרוא לא נכון את סדר האירועים, לכן בדיקת מצב הסנכרון של w32time צריכה להיות הצעד הראשון ממש בהליך החקירה. זכרו גם שחותמות זמן של אירועים נשמרות ב-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. סיכום

• למדיניות ביקורת יש שתי מערכות, «בסיסית» ו«מתקדמת», וערבוב שלהן מייצר תוצאות בלתי צפויות. מאחדים לצד המתקדם, בודקים את המצב הנוכחי ב-auditpol /get /category:*, ומתכננים משם.
• «להפעיל הכול» הורג את החקירה ברעש ובניפוח. מתחילים מהמלצות הבסיס של Microsoft ועובדים דרך טבלת ההחלטה בפרק 3, שנבנתה סביב כניסה, ניהול חשבונות ויצירת תהליך.
• 4624 נקרא לפי סוג כניסה, 4625 לפי קוד Status/Sub Status, 4740 לפי Caller Computer Name, ו-4688 לפי תהליך אב ושורת פקודה — לכל אירוע יש שדה מסוים שצריך לבדוק.
• מיכל היומן (גודל מרבי ומצב שמירה) הוא חצי מתכנון הביקורת. בודקים כמה ימים באמת נשמרים, מתאימים גודל בחישוב לאחור מהדרישה, ומייצאים או אוספים לפני דריסה.
• בודקים את סיכון חשיפת הסודות לפני הפעלת רישום שורת פקודה ל-4688. איפה כל אירוע נרשם, וסנכרון שעון, הם תנאים מוקדמים להצלבה בין מכונות.
• מתחילים חקירה בסינון של מציג האירועים; עוברים ל-Get-WinEvent -FilterHashtable לכל דבר שחוזר; משמרים ב-wevtutil epl. לא שוברים את הסדר של «קודם משמרים, אחר כך מנתחים».

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

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

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

KomuraSoft LLC מטפלת בייעוץ על מדיניות ביקורת ותכנון יומנים בסביבת Windows, בחקירת «מתי, מי ומה» על בסיס יומן האירועים, ובניתוח סיבות לתקלות שקשורות לאימות ולביקורת באפליקציות עסקיות. בסדר להתחיל משלב «אמרו לי להסתכל ביומנים, ואני לא יודע מאיפה להתחיל».

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

מקורות

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

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

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

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

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

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

שאלות נפוצות

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

לא הגדרנו שום מדיניות ביקורת, אז למה 4624 ו-4625 כבר מופיעים ביומן Security?

כי ב-Windows יש תת-קטגוריות ביקורת שמופעלות כברירת מחדל. תת-הקטגוריה «כניסה» (Logon), למשל, מופעלת להצלחה ולכישלון יחד מאז Windows 10 גרסה 1809, ולכן 4624 (הצלחה) ו-4625 (כישלון) נרשמים גם בלי שהגדרתם דבר. עם ברירת המחדל כפי שהיא, עם זאת, רבים מהאירועים שבאמת רוצים בחקירה — אימות אישורים (4776) או יצירת תהליך (4688), למשל — אינם נרשמים. אפשר לבדוק מה מופעל בסביבה שלכם ב-`auditpol /get /category:*`. משם, הפרקטיקה הסטנדרטית היא להפעיל במפורש את תת-הקטגוריות החסרות בצד מדיניות הביקורת המתקדמת.

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

קודם מאשרים את העיקרון: 4625 נרשם ב«מחשב שבו ניסו להיכנס». כניסה שנכשלה בתחנת המשתמש — זו התחנה; ניסיון גישה שנכשל מול שרת קבצים — זה שרת הקבצים. אחר כך בודקים ב-`auditpol /get /category:*` אם ביקורת כישלון מופעלת לתת-הקטגוריה «כניסה». בחשבונות דומיין העקבות מופיעות לעיתים קרובות באימות אישורים (4776) או בכישלון קדם-אימות Kerberos (4771) בבקר הדומיין, וכשאי אפשר לנעוץ איזו תחנה מעורבת, לרוב מהיר יותר להתחיל מצד ה-DC. אם עדיין אין דבר, בודקים אם אירועים ישנים כבר נדרסו (משווים את הגודל המרבי של היומן לחותמת הזמן של האירוע הישן ביותר).

האם להפעיל רישום שורת פקודה ליצירת תהליך (4688)?

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

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

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

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

הרמז הראשון הוא השדה «שם מחשב הקורא (Caller Computer Name)» באירוע 4740. הוא רושם את המחשב שממנו יצא ניסיון הכניסה שנכשל והפעיל את הנעילה. שימו לב, עם זאת, שרשומת הכישלון עצמה (4625) נשארת בצד שקיבל את ניסיון הכניסה, לא במכונת המקור. אם המקור הוא כניסת רשת, עוקבים לפי סדר הזמן דרך 4625 בשרת היעד, או בחשבון דומיין דרך 4776/4771 בבקר הדומיין. אחרי שזיהיתם את מכונת המקור, בודקים בה כל דבר שעדיין מחזיק אישורים ישנים מלפני החלפת הסיסמה — אישורים שמורים, הפעלת שולחן עבודה מרוחק מנותקת שנשארה תלויה, או שירות ומשימה מתוזמנת שהוגדרו עם הסיסמה הישנה. אם הנעילות חוזרות, בודקים גם אם סנכרון השעון נסחף.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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