Windows security audit policy और event log जाँच का व्यवहार — 4625 पढ़ सकने वाली IT टीम बनना

“कल रात से एक account बार-बार lockout हो रहा है। कारण पता करें।” “क्या किसी ने निकले कर्मचारी के account से sign-in का प्रयास किया?” “इस server पर कब, किसने, क्या चलाया?” — छोटे और मध्यम businesses के IT staff, या ग्राहक को system सौंपने वाले developer, एक दिन अचानक ऐसे अनुरोध पाते हैं। और जिस पर वे टिकते हैं वह Windows का Security event log है।

पर वास्तव में Event Viewer खोलें तो दो वास्तविकताएँ इंतज़ार करती हैं। जो event देखना चाहते हैं वह दर्ज ही नहीं (audit policy enable नहीं), या events के ढेर में दबकर पढ़े नहीं जाते (शोर से फूलकर बढ़े)। Security audit “enable करें तो दर्ज होता है”, पर क्या और कितना दर्ज करें design न करें तो जरूरत के समय काम नहीं आता।

flowchart TB
    accTitle: Event Viewer में इंतज़ार कर रही दो वास्तविकताएँ
    accDescr: Event Viewer खोलने पर दो वास्तविकताएँ मिलती हैं, audit policy enable न होने से वांछित event दर्ज नहीं, या शोर से फूलकर events के ढेर में दब जाना, इसलिए क्या और कितना दर्ज करें का design ज़रूरी है
    open["Event Viewer खोलें"] --> real{"इंतज़ार कर रही वास्तविकता?"}
    real -->|दर्ज नहीं| none["वांछित event दर्ज नहीं"]
    real -->|दबे हुए| noise["events के ढेर में पढ़े नहीं जाते"]
    none -.-> cause1["Audit policy disabled"]
    noise -.-> cause2["शोर से फूलकर बढ़ना"]
    none --> design["क्या और कितना दर्ज करें, design करें"]
    noise --> design

चित्र 1: “दर्ज नहीं” या “दबकर पढ़े नहीं जाते”। दोनों का कारण दर्ज करने की सीमा design न करना है।

यह लेख audit policy की बनावट (basic और Advanced, दो प्रणालियाँ), छोटे-मध्यम environment में minimum enable subcategories, 4624/4625/4740/4688 जैसे standard event IDs पढ़ना, Security log की capacity design, और PowerShell से जाँच — August 2026 तक के primary sources पर — व्यवस्थित करता है। इस साइट के NTLM audit, SMB signing, BitLocker और firewall लेख “रक्षा मज़बूत करने” की बात हैं; यह लेख “बाद में पुष्टि कर सकें कि क्या हुआ” की बात है, और उन्हें बाँधने वाला अगला अध्याय है।

1. निष्कर्ष पहले

• Audit policy की दो प्रणालियाँ हैं — “basic” और “Advanced Audit Policy” — और उन्हें मिलाना मना है। Microsoft स्पष्ट लिखता है कि दोनों इस्तेमाल करने से audit परिणाम unexpected हो जाते हैं। Advanced पक्ष (40 से अधिक subcategories) पर एकरूप रहें।¹
• वर्तमान स्थिति auditpol /get /category:* से देखें। GPO से आई हो या local setting से, अभी effective audit settings की सूची मिलती है।²
• “सब enable करें” कभी न करें। बड़ी event मात्रा पैदा करने वाली subcategories चालू करें तो जरूरी events शोर में दबते हैं, और performance भी प्रभावित होता है। Microsoft की baseline recommendation से शुरू करें, जरूरत की चीज़ें ही जोड़ें।³⁴
• Sign-in success 4624 है, failure 4625। 4624 को logon type से पढ़ें (2 = Interactive, 3 = Network, 10 = RemoteInteractive, आदि) — “किस तरह का sign-in था”।⁵
• 4625 में Status/Sub Status codes failure का कारण बताते हैं। Standard हैं 0xC0000064 = अस्तित्वहीन user name, 0xC000006A = गलत password, 0xC0000072 = disabled account, 0xC0000234 = lockout।⁶
• Event कहाँ दर्ज होता है, तय है। 4624/4625 उस machine पर दर्ज होते हैं जिस तक पहुँचा गया; क्रेडेंशियल वैलिडेशन (4776) और Kerberos pre-authentication failure (4771) domain controller पर। गलत machine देखें तो “log नहीं है” का गलत diagnostics होता है।⁶⁷⁸
• Security log का आधा design पात्र स्वयं है — maximum size और retention। Retention overwrite mode हो तो पुराने events पहले मिटते हैं। Get-WinEvent -ListLog Security से maximum size और संख्या देखें, जितने दिन रखने हैं उससे उलटा हिसाब लगाकर बढ़ाएँ।⁹¹⁰
• Process creation (4688) की command-line recording शक्तिशाली है, पर secrets log में plain text में बैठने के जोखिम के बदले। Enable करने से पहले scripts जाँचें।¹¹¹²

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 34, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

2. Audit policy की नींव — “basic” और “Advanced” न मिलाएँ

Windows audit policy की दो प्रणालियाँ हैं।¹

• Basic audit policy: “Local Policies > Audit Policy” के अंतर्गत नौ category settings। Windows Vista से पहले की पुरानी प्रणाली।
• Advanced Audit Policy Configuration: “Security Settings > Advanced Audit Policy Configuration” के अंतर्गत 40 से अधिक subcategory settings। Basic की एक category को कई subcategories में तोड़ती है — उदाहरण के लिए basic की एक category “Audit account logon events” के सामने Advanced पक्ष पर चार subcategories हैं। Basic पक्ष पर एक category enable करना matching सभी subcategories enable करने के बराबर है, इसलिए जिनमें आपकी रुचि नहीं वे भी बड़ी मात्रा में दर्ज होते हैं।¹

महत्वपूर्ण बात यह है कि ये दो प्रणालियाँ परस्पर compatible नहीं। Microsoft साफ़ लिखता है: “Basic और Advanced दोनों इस्तेमाल न करें। Audit परिणाम unexpected हो सकते हैं।” Group Policy से Advanced Audit Policy apply होने पर उस computer की मौजूदा audit settings पहले साफ़ होती हैं, फिर Advanced settings लगती हैं; उसके बाद केवल Advanced पक्ष विश्वसनीय नियंत्रण देता है। Advanced पक्ष इस्तेमाल करने वाले environment में security option “Audit: Force audit policy subcategory settings to override audit policy category settings” enable रखें ताकि basic settings उसे overwrite न करे (standalone machines पर यह default से enabled है)।¹⁴

flowchart TB
    accTitle: Basic और Advanced Audit Policy का संबंध
    accDescr: Basic audit policy और Advanced Audit Policy compatible नहीं हैं, दोनों इस्तेमाल करने से audit परिणाम unexpected होते हैं, इसलिए Advanced पक्ष पर एकरूप रहें और subcategory settings force कर basic पक्ष की overwrite रोकें
    basic["Basic audit policy（9 categories）"] --> both{"दोनों इस्तेमाल?"}
    adv["Advanced Audit Policy（40+ subcategories）"] --> both
    both -->|हाँ| bad["Audit परिणाम unexpected"]
    both -->|नहीं| unify["Advanced पक्ष पर एकरूप"]
    unify --> force["Force subcategory settings enable"]
    force -.-> guard["Basic पक्ष की overwrite रोकें"]

चित्र 2: दो प्रणालियाँ compatible नहीं। Advanced पक्ष पर एकरूप रहें, और “force” setting से basic पक्ष की overwrite रोकें।

वर्तमान स्थिति एक command से दिखती है। Admin command prompt से चलाएँ।²

rem अभी effective audit settings subcategory के अनुसार list करें
auditpol /get /category:*

rem बदलाव से पहले backup (CSV) और restore
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

auditpol का output GPO से आई हो या local setting से, “परिणामतः effective policy” है। GPO से बाँटी setting न लगी लगे तो matching के लिए भी काम आता है। ध्यान दें कि audit settings स्वयं बदलने पर event 4719 दर्ज होता है, इसलिए “पता न चला audit बंद हो गया” बाद में भी खोजा जा सकता है।¹²

flowchart TB
    accTitle: auditpol में दिखती है परिणाम की policy
    accDescr: auditpol का output GPO से आई हो या local setting से परिणामतः effective audit policy है, GPO न लगने पर matching में काम आता है, और audit settings स्वयं बदलने पर event 4719 से बाद में पता चलता है
    gpo["GPO से distributed settings"] --> eff["परिणामतः effective policy"]
    local["Local settings"] --> eff
    eff --> get["auditpol /get से सूची"]
    get -.-> diff["GPO न लगने पर matching"]
    change["Audit settings स्वयं बदली"] -.-> e4719["4719 दर्ज, बाद में पता चलता है"]

चित्र 3: auditpol उद्गम पूछे बिना “effective settings” लौटाता है। Audit settings का बदलाव स्वयं 4719 में रहता है।

3. Minimum enable subcategories की decision table

“फिलहाल सब enable कर दें” खराब चाल क्यों है, साफ़ है। उदाहरण के लिए privilege-use subcategories तक success audit करें तो events इतने बढ़ते हैं कि अन्य entries खोजना कठिन हो जाता है, और performance भी प्रभावित होता है — Microsoft चेतावनी देता है।⁴ Log का पात्र (अध्याय 5) सीमित है, इसलिए जितना शोर दर्ज करेंगे उतने दिन जरूरी events के retention कटते हैं। Audit design वास्तव में यह तय करना है कि क्या न दर्ज करें।

flowchart TB
    accTitle: सब enable करना खराब चाल क्यों है
    accDescr: सभी subcategories enable करने से बड़ी मात्रा में events पैदा होते हैं, जरूरी events शोर में दबते हैं, performance प्रभावित होता है, और सीमित log पात्र में जरूरी events के retention days कटते हैं
    all["सभी subcategories enable करें"] --> flood["बड़ी मात्रा में events"]
    flood --> noise["जरूरी events दब जाते हैं"]
    flood --> perf["Performance पर असर"]
    flood --> keep["Retention days कटते हैं"]
    noise --> lesson["क्या न दर्ज करें, यही audit design है"]
    perf --> lesson
    keep --> lesson

चित्र 4: “सब enable” जरूरी events दबा देता है। न दर्ज करने वाली चीज़ तय करना ही audit design है।

Microsoft workstation और server के अनुसार baseline तथा मज़बूत recommendations प्रकाशित करता है, और वही शुरुआती बिंदु है।³ उसके बाद छोटे-मध्यम environment के दृष्टिकोण — “incident पर minimum क्या पढ़ना है” — से व्यवस्थित तालिका यह है।

उलटा, file system या registry की object-access audit, privilege use, और packet-filter subcategories (5152 आदि) default से न छूना सुरक्षित है। ये targeted SACL settings या सीमित जाँच अवधि में ही काम आती हैं; हमेशा पूरा खुला छोड़ें तो log निगल जाती हैं।⁴

flowchart TB
    accTitle: High-volume subcategories का व्यवहार
    accDescr: File system या registry की object-access audit, privilege use, packet-filter हमेशा पूरा खुला छोड़ने पर logs निगल जाते हैं, इसलिए targeted SACL settings या जाँच अवधि तक सीमित करने पर ही काम आते हैं
    heavy["High-volume subcategories"] --> use{"कैसे enable करें?"}
    heavy -.-> ex1["Object-access audit"]
    heavy -.-> ex2["Privilege use और packet-filter"]
    use -->|हमेशा पूरा खुला| eat["Logs निगल जाते हैं"]
    use -->|Targeted SACL| ok1["काम आता है"]
    use -->|जाँच अवधि तक सीमित| ok2["काम आता है"]

चित्र 5: Object access और privilege use हमेशा पूरा खुला न छोड़ें। Target और अवधि बाँधने पर ही काम आते हैं।

4. Standard event IDs कैसे पढ़ें

4.1. 4624 — Sign-in success logon type से छाँटें

4624, “An account was successfully logged on”, उस machine पर दर्ज होता है जहाँ logon session बना (जिस तक पहुँचा गया)।⁵ मात्रा बहुत होती है, इसलिए पढ़ते समय पहले logon type से छाँटें।⁵

साथ देखने वाले fields: “New Logon” का account नाम, “Network Information” का source address, “Authentication Package” (NTLM या Kerberos), और “Elevated Token” (admin privilege session है या नहीं)। केवल admin privilege वाले sign-in trace करना हो तो उसी logon ID पर दर्ज 4672 (Special privileges assigned to new logon) भी काम आता है।⁵

flowchart TB
    accTitle: 4624 पढ़ने का क्रम
    accDescr: बड़ी मात्रा में दर्ज 4624 पहले logon type से छाँटें, account नाम और source, authentication package, Elevated Token देखें, admin privilege sign-in उसी logon ID के 4672 से मिलाएँ
    ev["4624 sign-in success"] --> type["Logon type से छाँटें"]
    type --> fields["मुख्य fields देखें"]
    fields -.-> f1["Account नाम और source"]
    fields -.-> f2["Authentication package"]
    fields -.-> f3["Elevated Token"]
    fields --> admin["Admin privilege का पता"]
    admin -.-> e4672["उसी logon ID का 4672"]

चित्र 6: 4624 को logon type से छाँटकर fields पढ़ें। Privileged logon 4672 से correlate करें।

4.2. 4625 — Failure का कारण Status/Sub Status codes से पक्का करें

4625, “An account failed to log on”, उस machine पर दर्ज होता है जहाँ logon का प्रयास हुआ।⁶ “Failure Reason” के शब्दों से अधिक भरोसेमंद Status/Sub Status का hexadecimal code है। Standard ये हैं।⁶

• 0xC0000064: अस्तित्वहीन user name। थोड़े समय में लगातार आए तो account-enumeration attack का संकेत
• 0xC000006A: गलत password। किसी खास account पर लगातार आए तो password-guessing attack का संकेत
• 0xC000006D: User name या authentication जानकारी invalid
• 0xC000006F: Allowed time के बाहर
• 0xC0000070: Allowed न workstation से
• 0xC0000072: Administrator द्वारा disabled account (निकले कर्मचारी के account पर प्रयास यहीं दिखते हैं)
• 0xC000015B: इस machine पर requested logon type allowed नहीं
• 0xC0000193: Expired account
• 0xC0000234: Lockout

“किसने, कहाँ से, क्यों failed” target account + source (workstation name/IP address) + इस code के तीन-बिंदु set से पक्का होता है। अध्याय 6 में ये तीन एक साथ निकालने वाला PowerShell है।

flowchart TB
    accTitle: 4625 की failure का कारण पक्का करने का flow
    accDescr: 4625 की failure Status/Sub Status के hex codes से पक्की होती है, code की प्रवृत्ति से attack का संकेत पढ़कर target account और source के तीन-बिंदु set से पहचानें
    ev["4625 sign-in failure"] --> code["Sub Status code देखें"]
    code --> sign{"Code की प्रवृत्ति?"}
    sign -->|0xC0000064 की कड़ी| enum["Account-enumeration का संकेत"]
    sign -->|0xC000006A की कड़ी| guess["Password-guessing का संकेत"]
    sign -->|0xC0000072| disabled["निकले कर्मचारी के account का प्रयास"]
    enum --> triple["तीन-बिंदु set से पक्का"]
    guess --> triple
    disabled --> triple
    triple -.-> t1["Target account+source+code"]

चित्र 7: Failure का कारण code से पक्का करें, target account और source के साथ तीन-बिंदु set से पढ़ें।

4.3. 4740 — Lockout का उद्गम “Caller Computer Name”

4740, “A user account was locked out” है (subcategory User Account Management)। इस event का मुख्य field “Caller Computer Name” है, जिसमें lockout का trigger बना logon attempt किस computer से आया दर्ज होता है।¹⁶ यहाँ से source machine पहचानें, उस machine पर बची पुरानी credentials खंगालें — यही standard विधि है। कारण लगभग हमेशा password बदलने के बाद भी पुरानी credentials इस्तेमाल करती कोई चीज़ होती है (saved credentials, कटा अधूरा RDP session, पुराने password की service या task)।

flowchart TB
    accTitle: Account lockout जाँच की standard विधि
    accDescr: 4740 के Caller Computer Name से source machine पहचानें, वहाँ बची saved credentials, कटे अधूरे RDP sessions, पुराने password की service या task खंगालें
    ev["4740 lockout हुआ"] --> caller["Caller Computer Name देखें"]
    caller --> src["Source machine पहचानें"]
    src --> sweep["पुरानी credentials खंगालें"]
    sweep -.-> c1["Saved credentials"]
    sweep -.-> c2["कटा अधूरा RDP session"]
    sweep -.-> c3["पुराने password की service या task"]

चित्र 8: 4740 के “Caller Computer Name” से उद्गम पहचानें, उस terminal की पुरानी credentials खंगालें।

एक सावधानी है। 4625 logon attempt स्वीकार करने वाले computer पर दर्ज होता है। Source machine से file server आदि पर network logon कारण हो तो source machine के अपने Security log में 4625 नहीं रहता; निशान destination server के 4625 पर, या domain account पर DC के 4776 (NTLM)/4771 (Kerberos pre-authentication failure) पर रहता है।⁷⁸ “Source machine के log में कुछ नहीं” हो तो स्वीकार करने वाले पक्ष पर जाएँ।

flowchart TB
    accTitle: Failure का निशान किस machine पर रहता है
    accDescr: Network logon की failure source machine पर नहीं रहती, logon attempt स्वीकार करने वाले destination server के 4625 पर दर्ज होती है, domain account पर DC के 4776 या 4771 पर भी निशान रहता है
    src["Source machine（स्वयं पर 4625 नहीं）"] -->|Network logon| target["Destination server"]
    target -.-> e4625["4625 दर्ज होता है"]
    src -->|Domain account का authentication| dc["Domain controller"]
    dc -.-> e4776["4776（NTLM）/4771（Kerberos）"]

चित्र 9: 4625 स्वीकार करने वाले पक्ष पर रहता है। Source machine पर कुछ न हो तो destination server और DC देखें।

4.4. 4720 परिवार — Account create, बदलाव, group में जोड़ना

Account-management events क्रमांक से सटे हैं। 4720 (user account बना)¹⁷, 4726 (हटाया), 4738 (बदला), और group पक्ष पर member जोड़ना/हटाना। ध्यान दें कि group membership बदलने का event ID group के प्रकार से बँटता है। Local group 4732/4733, global group 4728/4729, universal group 4756/4757।¹⁴ Domain Admins global group है, इसलिए उसमें जोड़ना 4728 पर दर्ज होता है — केवल 4732 पर alert लगाएँ तो सबसे देखना-चाहिए घटना छूट जाती है। रोज़ यह helpdesk के काम का record है, पर “सामान्य user अचानक Administrators group में जुड़ गया” या “कोई न पहचाने account बन गया” एक बार भी तुरंत जाँच का विषय है। Microsoft स्वयं privileged group में unexpected member जोड़ को एकल alert के उदाहरण में रखता है।³

flowchart TB
    accTitle: Group प्रकार और member-add events
    accDescr: Group में member जोड़ना group प्रकार से event ID बाँटता है, local 4732, global 4728, universal 4756 पर दर्ज होता है, इसलिए global group Domain Admins में जोड़ना 4728 देखें
    add["Group में member जोड़ना"] --> kind{"Group का प्रकार?"}
    kind -->|Local| lg["4732 पर दर्ज"]
    kind -->|Global| gg["4728 पर दर्ज"]
    kind -->|Universal| ug["4756 पर दर्ज"]
    gg -.-> da["Domain Admins में जोड़ना यहीं"]
    lg -.-> miss["केवल 4732 monitoring चूकती है"]

चित्र 10: Member जोड़ का event ID group प्रकार से बँटता है। Domain Admins में जोड़ना 4728 है।

4.5. 4688 — Process creation। Command-line recording अलग switch है

4688, “A new process has been created”, हर process creation पर बनाने वाला account, नए process का executable-file path, parent process, और token elevation प्रकार दर्ज करता है।¹¹ “इस server पर किसने क्या चलाया” का उत्तर दे सकने वाला, ऊँचे जाँच मूल्य वाला event है।

पर default में command-line arguments दर्ज नहीं होते। Group Policy setting “Include command line in process creation events” (Administrative Templates > System > Audit Process Creation) अलग से enable करने पर ही 4688 के “Process Command Line” field में arguments आते हैं।¹¹¹² powershell -EncodedCommand ... जैसे संदेहास्पद start trace करने के लिए व्यवहार में आवश्यक setting है, पर अध्याय 7 में बताए secret-मिश्रण के जोखिम समझकर enable करें।

flowchart TB
    accTitle: 4688 और command-line recording का संबंध
    accDescr: Process creation audit enable करने पर 4688 में account, executable-file path, parent process दर्ज होते हैं, पर command-line arguments अलग Group Policy enable करने पर ही दर्ज होते हैं, और secrets plain text में बैठने का जोखिम है
    audit["Process creation audit enable करें"] --> ev["4688 दर्ज होता है"]
    ev -.-> base["Account, path, parent process"]
    ev --> args{"Command-line arguments भी देखने हैं?"}
    args -->|Default जैसा| none["Command line खाली"]
    args -->|Extra GPO enable| cmd["Arguments दर्ज होते हैं"]
    cmd -.-> risk["Secrets plain text में बैठने का जोखिम"]

चित्र 11: 4688 की command-line recording अलग switch है। Enable करने से पहले secret-मिश्रण जोखिम जाँचें।

4.6. 4698 — Scheduled task का create

4698, “A scheduled task was created”, task नाम और task definition का पूरा XML (चलाए जाने वाले command सहित) दर्ज करता है। Malware reboot के बाद भी जीवित रहने के लिए task registration आम विधि मानता है, इसलिए Microsoft task-creation events की monitoring सुझाता है।¹⁵ Business काम में task बहुत इस्तेमाल करने वाले environment में भी create रोज़ की घटना नहीं, इसलिए शोर अपेक्षाकृत कम रहता है।

flowchart TB
    accTitle: Task registration से persistence और 4698
    accDescr: Malware reboot के बाद जीवित रहने के लिए scheduled task registration आम विधि मानता है, इसलिए task create पर दर्ज 4698 monitoring से चलाए जाने वाले command सहित task definition तक पहुँच सकते हैं
    mal["Malware की persistence"] --> task["Task register कर जीवित रहना"]
    task --> ev["4698 दर्ज होता है"]
    ev -.-> xml["Command सहित पूरा XML"]
    ev --> watch["Task create की monitoring से पता"]
    watch -.-> low["Create रोज़ नहीं, शोर कम"]

चित्र 12: Persistence की आम विधि task registration 4698 में रहती है। Definition XML से चलाए जाने वाले command तक पहुँच सकते हैं।

एक और याद रखने योग्य 1102, “The audit log was cleared” है। Security log साफ़ करना हमेशा यह event छोड़ता है, इसलिए “log खाली है” पर दुर्घटना है या operations, बाँटा जा सकता है।¹⁸

flowchart TB
    accTitle: 1102 से log मिटाने का भेद
    accDescr: Security log साफ़ करना हमेशा 1102 छोड़ता है, इसलिए log खाली हो तो 1102 है या नहीं देखकर मिटाने का operations था या दुर्घटना, बाँटा जा सकता है
    empty["Log खाली है"] --> rule["साफ़ करना हमेशा 1102 छोड़ता है"]
    rule --> check{"1102 है?"}
    check -->|है| op["मिटाने का operations हुआ"]
    check -->|नहीं| acc["दुर्घटना की संभावना"]

चित्र 13: Security log साफ़ करना हमेशा 1102 छोड़ता है। खाली log 1102 की उपस्थिति से दुर्घटना या operations बाँटें।

5. Log के पात्र का design — maximum size और retention

Audit policy बढ़ाने से पहले पात्र जाँचें। Security log का maximum size और retention mode होता है: Overwrite mode (आम configuration) में maximum size पहुँचने पर नए events सबसे पुराने को overwrite करते हैं। उलटा, retention mode (overwrite न करें) में log भरने पर नए events ही त्यागे जाते हैं।¹⁰ दोनों व्यवहार “ध्यान गया तो log नहीं” का कारण बनते हैं, इसलिए वर्तमान स्थिति पहले जानें।

# Security log का पात्र देखें: retention mode, maximum size, वर्तमान संख्या
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# अभी वास्तव में कितने दिन बचे हैं (सबसे पुराने event का समय)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog log का configuration और संख्या एक साथ लौटाता है।⁹ “सबसे पुराने event का समय” और वर्तमान का अंतर actual retention days हैं; यह आपकी आवश्यकता (incident जाँच में कितने दिन पीछे जाना है) से कम हो तो maximum size बढ़ाएँ। Setting wevtutil sl Security /ms:<byte संख्या> या Group Policy से बाँटी जा सकती है।¹⁰

flowchart TB
    accTitle: Retention days से उलटा हिसाब लगा capacity design
    accDescr: Get-WinEvent के ListLog से configuration और संख्या देखें, सबसे पुराने event के समय से actual retention days निकालें, incident जाँच में जितने दिन पीछे जाना है उससे कम हों तो maximum size बढ़ाएँ
    check["ListLog से configuration और संख्या"] --> oldest["सबसे पुराने event का समय"]
    oldest --> days["Actual retention days निकालें"]
    days --> enough{"आवश्यकता पूरी?"}
    enough -->|पर्याप्त| keep["वर्तमान size रखें"]
    enough -->|अपर्याप्त| grow["Maximum size बढ़ाएँ"]
    grow -.-> how["wevtutil sl या GPO से set"]

चित्र 14: वास्तव में बचे दिन देखें, जितने दिन पीछे जाना है उससे उलटा हिसाब लगा maximum size तय करें।

साथ ही security option “Audit: Shut down system immediately if unable to log security audits” (तथाकथित CrashOnAuditFail) है। Enable हो और audit दर्ज न हो सके तो STOP error C0000244 से system रुकती है। Audit trail बिलकुल न खोने देने वाली authentication आवश्यकताओं के लिए setting है, default disabled है। Microsoft स्वयं चेतावनी देता है कि attacker बड़ी मात्रा में events पैदा कर server जानबूझकर रोकने वाले DoS में बदल सकता है — सामान्य छोटे-मध्यम environment में इसे हल्के में enable न करें।¹⁹

flowchart TB
    accTitle: Log भरने पर व्यवहार
    accDescr: Retention configuration overwrite mode और overwrite न करने वाले mode दो हैं, overwrite न करने पर audit दर्ज न हो सके और अलग setting CrashOnAuditFail enable हो तो STOP error C0000244 से system रुकती है
    full["Security log maximum size पर"] --> mode{"Retention configuration?"}
    mode -->|Overwrite mode| ow["सबसे पुराने events overwrite"]
    mode -->|Overwrite न करें| drop["नए events त्यागे जाते हैं"]
    ow -.-> lost["दोनों ध्यान गया तो log नहीं का कारण"]
    drop -.-> lost
    drop --> caf{"CrashOnAuditFail भी enable?"}
    caf -->|हाँ| crash["STOP error C0000244 से रुकना"]

चित्र 15: Retention configuration overwrite या त्याग, दो रास्ते। CrashOnAuditFail अलग setting है, दर्ज न हो सके तो रोकती है।

6. जाँच का व्यवहार — Filter, Get-WinEvent, export

6.1. Event Viewer में संकीर्ण करना

एकमुश्त जाँच के लिए Event Viewer काफी है। Security log खोलें, “Filter Current Log” से event ID (उदाहरण 4625) और अवधि तय करें। बार-बार देखी शर्तें “Custom View” में सहेजें तो अगली बार एक क्लिक। Event ID के अलावा किसी account से संकीर्ण करना हो तो filter dialog के XML tab पर XPath query सीधे edit कर सकते हैं।

6.2. Get-WinEvent से extraction

बड़ी संख्या, कई शर्तें, या regular चलान वाली जाँच PowerShell के Get-WinEvent पर ले जाएँ। मुख्य बात server पक्ष पर filter चलाने वाला -FilterHashtable इस्तेमाल करना है।⁹

flowchart TB
    accTitle: जाँच साधनों का चुनाव
    accDescr: एकमुश्त जाँच Event Viewer के filter से काफी है, बार-बार देखी शर्तें custom view में सहेजें, बड़ी संख्या या कई शर्तें या regular चलान Get-WinEvent पर ले जाएँ
    q{"कैसी जाँच?"}
    q -->|एकमुश्त| viewer["Event Viewer से संकीर्ण करें"]
    q -->|बार-बार देखी शर्तें| view["Custom view में सहेजें"]
    q -->|बड़ी संख्या, कई शर्तें, regular| ps["Get-WinEvent पर जाएँ"]
    ps -.-> hash["FilterHashtable से संकीर्ण"]

चित्र 16: एकमुश्त Event Viewer, दोहराएँ तो custom view, संख्या अधिक हो तो Get-WinEvent।

# पिछले 24 घंटे की sign-in failures (4625)
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

Event के XML रूप से EventData निकालने का यह साँचा एक बार रख लें तो 4624 हो या 4688, वही तरीका काम आता है। Get-WinEvent की संकीर्णता design (FilterHashtable बनाम XPath, धीमी query सुधार) “Get-WinEvent से event log practical जाँच — संकीर्णता की गति जाँच का समय तय करती है” में विस्तार से है।

flowchart TB
    accTitle: EventData निकालकर तालिका बनाने का साँचा
    accDescr: Get-WinEvent से मिले events XML रूप में बदलें, EventData के fields निकालकर तालिका में ढालें, यह साँचा 4625 तक सीमित नहीं, 4624 और 4688 पर भी वही तरीका चलता है
    get["Get-WinEvent से प्राप्त"] --> xml["Event को XML रूप में बदलें"]
    xml --> pull["EventData निकालें"]
    pull --> shape["तालिका में ढालकर जोड़ें"]
    shape -.-> reuse["4624 या 4688 पर भी वही तरीका"]

चित्र 17: XML रूप से EventData निकालकर तालिका बनाने का साँचा event ID बदलने पर भी दोहराया जा सकता है।

6.3. wevtutil से export

जाँच target machine के logs पहले export कर सुरक्षित करें, overwrite से मिटने से पहले।¹⁰

rem पूरा Security log evtx में सुरक्षित करें
wevtutil epl Security C:\logs\security-20260801.evtx

rem केवल 4625 XPath से संकीर्ण कर export
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

Export किया .evtx दूसरी machine पर Get-WinEvent -Path C:\logs\security-20260801.evtx से उसी तरह analyse होता है।⁹ सुरक्षित करके फिर analysis की आदत crash जाँच में “पहले dump सुरक्षित करें” जैसी ही है (“Windows crash dump संग्रह का परिचय - WER/ProcDump/WinDbg” देखें)।

flowchart TB
    accTitle: सुरक्षित करके फिर analysis का flow
    accDescr: जाँच target machine के Security log wevtutil epl से evtx file में export कर सुरक्षित करें, दूसरी machine पर Get-WinEvent के Path से उसी तरह analysis करें
    target["जाँच target machine"] --> export["wevtutil epl से evtx में सुरक्षित"]
    export --> copy["दूसरी machine पर ले जाएँ"]
    copy --> analyze["Get-WinEvent -Path से analysis"]
    export -.-> note["Overwrite से मिटने से पहले सुरक्षित"]

चित्र 18: पहले सुरक्षित करें, फिर analysis। evtx में रखें तो दूसरी machine पर उसी तरह जाँच सकते हैं।

7. Pitfalls — मैदान में आसानी से पड़ने वाले चार

(1) 4688 की command line पर secrets बैठते हैं। Command-line recording enable करने पर हर process के arguments Security log में plain text में आते हैं। Microsoft स्पष्ट लिखता है कि “security events पढ़ने की पहुँच वाले सभी users हर successfully बने process के command-line arguments पढ़ सकते हैं। Arguments में passwords जैसी संवेदनशील जानकारी हो सकती है।” ¹² myapp.exe /user:admin /password:P@ssw0rd जैसा start करने वाला कोई business app या script हो तो वह log देखने वाले सभी के लिए secrets खोल देता है। Enable करने से पहले secrets arguments के रूप में देने वाली जगहें निकालकर सुधारें। Logs सुरक्षित रखने या forward करने वाले destination पर भी वही confidentiality level चाहिए।

flowchart TB
    accTitle: Command-line recording enable करने का क्रम
    accDescr: 4688 की command-line recording enable करने से पहले secrets arguments में देने वाले business apps और scripts निकालें, संबंधित जगहें सुधारकर enable करें, logs सुरक्षित रखने और forward करने वाले destination पर भी वही level माँगें
    audit["Secrets arguments में देने वाली जगहें निकालें"] --> found{"कोई है?"}
    found -->|है| fix["देने वाली जगहें सुधारें"]
    found -->|नहीं| on["Command-line recording enable करें"]
    fix --> on
    on -.-> dest["सुरक्षित रखना और forwarding भी वही level"]

चित्र 19: Command-line recording “निकालकर सुधारकर फिर enable”। क्रम उलटा करें तो secrets सार्वजनिक हो जाते हैं।

(2) Log भरने पर क्या होता है जाने बिना चलाना। Overwrite mode में पुराने निशान चुपचाप मिटते हैं; overwrite न करें setting में नए events त्यागे जाते हैं; CrashOnAuditFail enable हो तो पूरी system रुकती है (अध्याय 5)।¹⁰¹⁹ कौन सा व्यवहार चुना है जानें, और “मिटने से पहले एकत्र करें” mechanism (regular export या log-collection platform) रखें — यही मूल है।

(3) Domain controller और terminal पर देखने वाले logs अलग हैं। 4624/4625 पहुँची गई machine पर दर्ज होते हैं।⁵⁶ दूसरी ओर domain account की क्रेडेंशियल वैलिडेशन (NTLM का 4776) credentials पर authority रखने वाली machine पर दर्ज होता है — domain account पर वह DC है⁷ — और Kerberos pre-authentication failure (4771) केवल DC पर दर्ज होती है।⁸ “File server पर 4625 नहीं = attack नहीं था” नहीं; DC के 4776/4771 मिलाकर ही पूरी तस्वीर बनती है। प्रत्येक authentication protocol कैसे बहता है, “आरेखों से NTLM और Kerberos — authentication NTLM पर क्यों गिरता है” देखें।

(4) Clock sync बिगड़े तो correlation नहीं बनता। कई machines के logs सजाकर “इस 4740 से ठीक पहले किस terminal पर 4625 निकला” trace करना तभी चलता है जब हर machine की घड़ी मेल खाए। Domain environment में Kerberos स्वयं clock अंतर की ऊपरी सीमा (default 5 मिनट) रखता है, उसे पार करें तो authentication स्वयं fail होने लगता है।²⁰ जाँच की दृष्टि से पाँच मिनट नहीं, कुछ सेकंड का अंतर भी क्रम गलत पढ़वा सकता है, इसलिए w32time की sync स्थिति जाँच प्रक्रिया का पहला कदम बनाएँ। साथ ही event का समय UTC में stored होता है और display देखने वाली machine के time zone के अनुसार होता है, इसलिए विदेशी स्थल या UTC setting वाले server से लाए .evtx पढ़ते समय time zone बदलना न भूलें।

flowchart TB
    accTitle: Clock sync और correlation जाँच की पूर्वापेक्षा
    accDescr: कई machines के logs time-क्रम से मिलाने की जाँच हर machine की घड़ी मेल खाने पर टिकती है, कुछ सेकंड का अंतर भी क्रम गलत पढ़वाता है, default 5 मिनट पार करने पर Kerberos authentication स्वयं fail होता है, इसलिए w32time की पुष्टि जाँच प्रक्रिया के पहले रखें
    merge["कई machines के logs मिलाएँ"] --> pre["घड़ियाँ मेल खाना पूर्वापेक्षा"]
    pre --> skew{"घड़ी का अंतर?"}
    skew -->|मेल खाती हैं| ok["Time-क्रम से trace कर सकते हैं"]
    skew -->|कुछ सेकंड का अंतर| misread["क्रम गलत पढ़ना"]
    skew -->|Default 5 मिनट से अधिक| kerb["Kerberos authentication fail"]
    pre -.-> first["w32time की पुष्टि प्रक्रिया के पहले"]

चित्र 20: कई machines का correlation घड़ी मिलाने पर टिकता है। कुछ सेकंड का अंतर भी क्रम गलत पढ़वाता है।

8. सारांश

• Audit policy की दो प्रणालियाँ हैं, “basic” और “Advanced”; मिलाने से unexpected परिणाम आते हैं। Advanced पक्ष पर एकरूप रहें, auditpol /get /category:* से वर्तमान स्थिति देखकर design करें।
• “सब enable” शोर और फूलने से जाँच मार देता है। Microsoft की baseline recommendation से शुरू करें, logon, account management और process creation धुरी वाली अध्याय 3 की decision table से बढ़ें।
• 4624 logon type से, 4625 Status/Sub Status codes से, 4740 Caller Computer Name से, 4688 parent process और command line से — प्रत्येक event का “यहाँ देखें” बिंदु है।
• Log का पात्र (maximum size और retention mode) audit design का आधा है। वास्तव में बचे दिन देखें, आवश्यकता से उलटा हिसाब लगा size तय करें, मिटने से पहले export या एकत्र करें।
• 4688 की command-line recording secret-मिश्रण जोखिम जाँचकर ही। Machine के अनुसार दर्ज स्थान का अंतर और clock sync correlation जाँच की पूर्वापेक्षाएँ हैं।
• जाँच Event Viewer के filter से शुरू करें; दोहराएँ तो Get-WinEvent -FilterHashtable; सुरक्षित रखना wevtutil epl। “पहले सुरक्षित, फिर analysis” का क्रम न तोड़ें।

संबंधित लेख

• Get-WinEvent से event log practical जाँच — संकीर्णता की गति जाँच का समय तय करती है
• NTLM समाप्ति से business apps रुकेंगे? — Audit logs कैसे लें, dependency मिटाने का क्रम
• आरेखों से NTLM और Kerberos — authentication NTLM पर क्यों गिरता है
• SMB signing और LDAP channel binding — NTLM रक्षा का “बाकी आधा” व्यवहार में बंद करना
• Windows event log और ETW का परिचय — Business apps के logs OS के standard mechanism पर रखना
• Windows crash dump संग्रह का परिचय - WER/ProcDump/WinDbg

संबंधित परामर्श क्षेत्र

KomuraSoft LLC Windows audit policy और log design consulting, event log से “कब, किसने, क्या किया” की जाँच, और business apps के authentication-audit संबंधी failures का root-cause analysis संभालता है। “Log देखने को कहा गया, पर कहाँ से शुरू करें नहीं पता” चरण से शुरू करना ठीक है।

• बग और कारणों की जाँच
• Technical consulting और design review
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

हमने कोई audit policy set नहीं की, फिर भी Security log में 4624 और 4625 क्यों दिखते हैं?

क्योंकि Windows में कुछ audit subcategories default से enabled होती हैं। उदाहरण के लिए "Logon" subcategory में Windows 10 version 1809 से success और failure दोनों default से चालू हैं, इसलिए आप स्वयं कुछ set न करें तब भी 4624 (success) और 4625 (failure) दर्ज होते हैं। Default छोड़ देने पर, जाँच में वास्तव में चाहिए events — क्रेडेंशियल वैलिडेशन (4776) या process creation (4688) — अक्सर दर्ज ही नहीं होते। अपने environment में क्या enabled है, `auditpol /get /category:*` से देखें। उसके बाद जो subcategories कमी हों, उन्हें Advanced Audit Policy पक्ष पर explicitly enable करना व्यवहार की standard विधि है।

Sign-in failure जाँचनी है, पर target server के Security log में 4625 नहीं मिलता। कहाँ देखें?

पहले यह सिद्धांत पक्का करें: 4625 उस computer पर दर्ज होता है "जहाँ logon का प्रयास हुआ।" User workstation पर sign-in failure हो तो workstation; file server पर पहुँच failure हो तो file server। फिर `auditpol /get /category:*` से देखें कि "Logon" subcategory की failure audit enabled है या नहीं। Domain accounts पर निशान अक्सर domain controller की क्रेडेंशियल वैलिडेशन (4776) या Kerberos pre-authentication failure (4771) में बचता है, और workstation न पकड़ सकें तो DC पक्ष से शुरू करना अक्सर तेज़ होता है। फिर भी न मिले तो पुराने events overwrite हो चुके हों (log का maximum size बनाम सबसे पुराने event का समय) जाँचें।

Process creation (4688) की command-line recording enable करनी चाहिए?

जाँच मूल्य बहुत ऊँचा है, पर जोखिम समझकर ही enable करें। चालू करने पर हर process के command-line arguments Security log में plain text में दर्ज होते हैं। यदि कोई script या business app password या API key command-line arguments के रूप में देता है, वह secret Security log पढ़ सकने वाले सभी को दिख जाता है। Microsoft स्वयं यह सावधानी स्पष्ट लिखता है। Recommended क्रम: पहले देखें कि आपकी scripts secrets command-line arguments से तो नहीं देतीं, जो देती हैं उन्हें सुधारें, तब setting enable करें।

Security log का maximum size कितना होना चाहिए?

सही तरीका "कितने दिन हाथ में रखने हैं" से उलटा हिसाब लगाना है; कोई एक size सब पर नहीं बैठता। Current setting और वास्तविक व्यवहार `Get-WinEvent -ListLog Security` से देखें; सबसे पुराने event के समय और वर्तमान समय का अंतर "अभी वास्तव में कितने दिन बचे हैं" है। Audit subcategories बढ़ाने से event मात्रा बढ़ती है, इसलिए setting बदलने के बाद इस actual retention period को फिर जाँचें। Incident-response में हफ़्तों या महीनों पुराने logs अक्सर चाहिए होते हैं, इसलिए overwrite से पहले regular export करें, या log-collection mechanism से अलग machine पर एकत्रित रखें।

Account lockout (4740) का कारण कैसे जाँचें?

पहला सुराग 4740 event का "Caller Computer Name" field है। इसमें वह computer दर्ज होता है जहाँ से lockout का trigger बना failed logon आया। ध्यान दें कि failure का record स्वयं (4625) source machine पर नहीं, logon attempt स्वीकार करने वाले पक्ष पर रहता है। Network logon हो तो destination server के 4625, या domain account पर domain controller के 4776/4771, time-क्रम से जोड़ें। Source machine पहचानने के बाद वहाँ password बदलने के बाद भी पुरानी credentials पकड़े चीज़ें देखें — saved credentials, अधूरा Remote Desktop session, पुराने password से बनी service या scheduled task। Lockout दोहराए जाएँ तो clock sync भी जाँचें।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।