yamato-security/enablewindowslogsettingsविंडोज इवेंट लॉग्स को ठीक से सक्षम करने के लिए दस्तावेज़ और स्क्रिप्ट्स।
यह विंडोज़ इवेंट लॉग को उचित रूप से कॉन्फ़िगर और मॉनिटर करने के लिए एक और गाइड है, जिसमें sigma नियमों के लिए लॉगिंग पर विशेष जोर दिया गया है।
यह एक कार्य प्रगति पर है, इसलिए कृपया अपडेट के लिए समय-समय पर वापस आते रहें।
Zach Mathis (@yamatosecurity)। जैसे-जैसे मैं और अधिक शोध और परीक्षण करता हूँ, मैं समय-समय पर इसे अपडेट करने की योजना बनाता हूँ क्योंकि सुधार की बहुत गुंजाइश है (दस्तावेज़ीकरण के साथ-साथ अधिक डिटेक्शन नियम बनाने में भी।) PR का स्वागत है और मैं ख़ुशी से आपको योगदानकर्ता के रूप में जोड़ूँगा। यदि आपको इस दस्तावेज़ीकरण में कोई त्रुटि मिलती है, तो कृपया मुझे बताएं और मैं जल्द से जल्द उन्हें ठीक कर दूँगा।
यदि आपको इसमें से कुछ भी उपयोगी लगे, तो कृपया GitHub पर एक स्टार दें, क्योंकि यह संभवतः मुझे इसे अपडेट करते रहने के लिए प्रेरित करने में मदद करेगा।
अधिकांश जानकारी Microsoft के Advanced security auditing FAQ, sigma नियमों, ACSC Event Logging Guide और मेरे अपने शोध/परीक्षण से आती है। मैं विशेष रूप से sigma समुदाय को धन्यवाद देना चाहता हूँ, जिन्होंने थ्रेट डिटेक्शन को ओपन सोर्स और सभी डिफेंडरों के लाभ के लिए मुफ्त बनाया है।
डिफ़ॉल्ट रूप से, विंडोज़ दुर्भावनापूर्ण गतिविधि का पता लगाने और फोरेंसिक जाँच करने के लिए आवश्यक कई इवेंट लॉग नहीं करेगा।
साथ ही, इवेंट फ़ाइलों के लिए डिफ़ॉल्ट अधिकतम आकार क्लासिक इवेंट लॉग (Security, System, Application) के लिए केवल 20 MB, PowrShell के लिए 15 MB और लगभग सभी अन्य लॉग के लिए मात्र 1 MB है, इसलिए इस बात की अच्छी संभावना है कि साक्ष्य समय के साथ अधिलेखित हो जाएँ।
इस रिपॉजिटरी में एक सरल बैच स्क्रिप्ट प्रदान की गई है ताकि सिस्टम एडमिनिस्ट्रेटर अपनी विंडोज़ मशीनों को आसानी से कॉन्फ़िगर कर सकें, जिससे किसी घटना होने पर उनके पास आवश्यक लॉग उपलब्ध हों। बड़े नेटवर्क के लिए, आप शायद इस दस्तावेज़ को संदर्भ के रूप में उपयोग करना चाहेंगे और अपने एंडपॉइंट्स को Group Policy और/या InTune के साथ कॉन्फ़िगर करना चाहेंगे।
मैं डिफ़ॉल्ट विंडोज़ इवेंट लॉगिंग सेटिंग्स को बेहतर बनाने की अत्यधिक अनुशंसा करता हूँ और सबसे सटीक जानकारी प्रदान करने की पूरी कोशिश करता हूँ। हालाँकि, मैं अत्यधिक लॉगिंग सक्षम करने के किसी भी प्रतिकूल प्रभाव या इस रिपॉजिटरी में किसी भी चीज़ की सटीकता की कोई ज़िम्मेदारी नहीं लेता हूँ। यह आपकी ज़िम्मेदारी है कि आप प्रोडक्शन में रोल आउट करने से पहले अपने सिस्टम में किए गए किसी भी बदलाव को टेस्ट मशीनों पर समझें और परखें। मैं अनुशंसा करता हूँ कि आप अपने वातावरण की नकल करने वाली टेस्ट मशीनों पर कम से कम एक सप्ताह तक जितना संभव हो उतनी लॉगिंग चालू करें और फिर जाँच करें कि क्या कोई ऐसे इवेंट हैं जो बहुत अधिक शोर उत्पन्न कर रहे हैं या ऐसे इवेंट हैं जिन्हें आप चाहते हैं लेकिन उत्पन्न नहीं हो रहे हैं।
आप Hayabusa के इवेंट ID मेट्रिक्स कमांड के साथ एक evtx फ़ाइल में इवेंट ID की कुल संख्या और प्रतिशत देख सकते हैं।
उदाहरण: hayabusa.exe eid-metrics -f path/to/Security.evtx
Process Creation है, जो यह ट्रैक करता है कि सिस्टम पर कौन-कौन से प्रोसेस चलाए जाते हैं।
वर्तमान में, Sigma के लगभग आधे डिटेक्शन नियम इस इवेंट पर निर्भर करते हैं।
यह Sysmon (Event ID 1) इंस्टॉल करके या बिल्ट-इन Security लॉग Event ID 4688 को सक्षम करके पूरा किया जा सकता है।
Sysmon 1 हैश और एक्सेक्यूटेबल के मेटाडेटा जैसी विस्तृत जानकारी प्रदान करेगा, इसलिए यह आदर्श है, लेकिन यदि Sysmon इंस्टॉल नहीं किया जा सकता है, तो बिल्ट-इन Security 4688 लॉग का उपयोग करना संभव है। हालाँकि, यह महत्वपूर्ण है कि कमांड लाइन लॉगिंग भी सक्षम हो क्योंकि कई डिटेक्शन नियम इस पर निर्भर करते हैं। दुर्भाग्य से, Security 4688 Sysmon प्रोसेस क्रिएशन लॉग जितनी विस्तृत जानकारी प्रदान नहीं करता है, इसलिए सभी Process Creation नियम Security 4688 के साथ काम नहीं करते हैं।
डिफ़ॉल्ट विंडोज़ ऑडिट सेटिंग्स के साथ केवल लगभग 10~20% sigma नियमों का उपयोग किया जा सकता है!
यह बड़े पैमाने पर करना व्यावहारिक नहीं है, लेकिन लॉग को सक्षम/अक्षम करने और उनके अधिकतम फ़ाइल आकार की जाँच और/या कॉन्फ़िगर करने का सबसे आसान तरीका Event Viewer में लॉग पर राइट-क्लिक करके Properties खोलना है।
आप बिल्ट-इन wevtutil कमांड का उपयोग कर सकते हैं।
उदाहरण: wevtutil sl Security /ms:1073741824 Security लॉग के लिए अधिकतम फ़ाइल आकार 1 GB तक बढ़ाने के लिए।
उदाहरण:```powershell $sysmon = Get-WinEvent -ListLog Microsoft-Windows-Sysmon/Operational $sysmon.MaximumSizeInBytes = 2048000000 #2GB $sysmon.SaveChanges()
## विकल्प 4: समूह नीति
क्लासिक इवेंट लॉग जैसे `Security`, `System`, और `Application` के लिए अधिकतम फ़ाइल आकार बढ़ाना सीधा है, हालाँकि, दुर्भाग्यवश अन्य लॉग के लिए अधिकतम फ़ाइल आकार बदलने हेतु आपको प्रशासनिक टेम्पलेट (Administrative Templates) इंस्टॉल करने और/या रजिस्ट्री को सीधे संशोधित करने की आवश्यकता होती है। स्टार्टअप पर बैच या PowerShell स्क्रिप्ट के माध्यम से फ़ाइल आकार बढ़ाना शायद आसान हो सकता है।
# कॉन्फ़िगरेशन स्क्रिप्ट
अधिकतम फ़ाइल आकार बढ़ाने और उचित लॉग सक्षम करने के लिए एक स्क्रिप्ट यहाँ प्रदान की गई है: [YamatoSecurityConfigureWinEventLogs.bat](https://github.com/yamato-security/enablewindowslogsettings/blob/HEAD/YamatoSecurityConfigureWinEventLogs.bat)
# लॉग सेटिंग्स कॉन्फ़िगर करना
## Sysmon लॉग (1382 सिग्मा नियम)
फ़ाइल: `Microsoft-Windows-Sysmon%4Operational.evtx`
डिफ़ॉल्ट सेटिंग्स: `इंस्टॉल नहीं`
Sysmon को इंस्टॉल और कॉन्फ़िगर करना सबसे अच्छा काम है जो आप Windows एंडपॉइंट्स पर अपनी दृश्यता बढ़ाने के लिए कर सकते हैं, लेकिन इसके लिए योजना, परीक्षण और रखरखाव की आवश्यकता होगी।
यह अपने आप में एक बड़ा विषय है इसलिए यह फिलहाल इस दस्तावेज़ के दायरे से बाहर है।
कृपया निम्नलिखित संसाधन देखें:
* [TrustedSec Sysmon Community Guide](https://github.com/trustedsec/SysmonCommunityGuide)
* [Sysmon Modular](https://github.com/olafhartong/sysmon-modular)
* [Florian Roth का Swift On Security के sysmon कॉन्फ़िग फ़ाइल का अद्यतन फ़ोर्क](https://github.com/Neo23x0/sysmon-config)
* [Ion-storm का Swift On Security के sysmon कॉन्फ़िग फ़ाइल का अद्यतन फ़ोर्क](https://github.com/ion-storm/sysmon-config)
* [Cyb3rWard0g की sysmon कॉन्फ़िग फ़ाइल](https://github.com/OTRF/Blacksmith/blob/master/resources/configs/sysmon/sysmon.xml)
## सुरक्षा लॉग (1045 सिग्मा नियम (903 प्रोसेस क्रिएशन नियम + 142 अन्य नियम))
फ़ाइल: `Security.evtx`
डिफ़ॉल्ट सेटिंग्स: `आंशिक रूप से सक्षम`
Security लॉग कॉन्फ़िगर करने के लिए सबसे जटिल है इसलिए मैंने इसके लिए एक अलग दस्तावेज़ बनाया है: [ConfiguringSecurityLogAuditPolicies.md](https://github.com/yamato-security/enablewindowslogsettings/blob/HEAD/ConfiguringSecurityLogAuditPolicies.md)
## PowerShell लॉग्स (175 सिग्मा नियम)
फ़ाइल: `Microsoft-Windows-PowerShell%4Operational.evtx`
### मॉड्यूल लॉगिंग (30 सिग्मा नियम)
मॉड्यूल लॉगिंग चालू करने से इवेंट ID `4103` सक्षम होगा।
मॉड्यूल लॉगिंग का लाभ यह है कि यह पुराने OS और PowerShell संस्करणों पर चल सकती है: PowerShell 3.0 (Win 7+)।
एक और लाभ यह है कि यह निष्पादित PowerShell कमांड और परिणाम दोनों को लॉग करती है।
नुकसान यह है कि यह अत्यधिक उच्च संख्या में इवेंट उत्पन्न करेगी।
उदाहरण के लिए, यदि कोई हमलावर Mimikatz चलाता है, तो यह 2000 से अधिक इवेंट के साथ 7 MB के लॉग उत्पन्न करेगा!
#### मॉड्यूल लॉगिंग सक्षम करना
डिफ़ॉल्ट सेटिंग्स: `कोई ऑडिटिंग नहीं`
##### विकल्प 1: समूह नीति के माध्यम से सक्षम करना
समूह नीति संपादक (`gpedit.msc`) में, `Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell` खोलें और `Turn on Module Logging` सक्षम करें।
`Options` फलक में, यह कॉन्फ़िगर करने के लिए कि कौन से मॉड्यूल लॉग हों, `Show...` बटन पर क्लिक करें।
सभी मॉड्यूल रिकॉर्ड करने के लिए `Value` टेक्स्टबॉक्स में `*` दर्ज करें।
##### विकल्प 2: रजिस्ट्री के माध्यम से सक्षम करना```
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames → * = *
डिफ़ॉल्ट सेटिंग्स: On Win 10/2016+, if a PowerShell script is flagged as suspicious by AMSI, it will be logged with a level of Warning.
Script Block logging चालू करने से इवेंट ID 4104 सक्षम हो जाएगा। यदि आप Log script block invocation start / stop events सक्षम करते हैं, तो EID 4105 और 4106 भी सक्षम होंगे, हालाँकि, इसकी अनुशंसा नहीं की जाती है क्योंकि यह केवल शोर (noise) पैदा करेगा।
Script Block logging PowerShell 5.0+ (Win 10+) में डिफ़ॉल्ट रूप से समर्थित है, हालाँकि यदि आप .NET 4.5 और WMF 4.0+ स्थापित करते हैं तो आप इसे पुराने OS (Win 7+) पर सक्षम कर सकते हैं।
दुर्भाग्य से, एकल Windows इवेंट लॉग का अधिकतम आकार 32 KB है, इसलिए इससे बड़े किसी भी PowerShell स्क्रिप्ट को 32 KB आकार के ब्लॉकों में विभाजित किया जाएगा।
यदि आपके पास मूल PowerShell Operational.evtx फ़ाइल है, तो आप इन लॉग्स को एक आसानी से पढ़ने योग्य टेक्स्ट फ़ाइल में विभाजन-मुक्त करने के लिए block-parser टूल का उपयोग कर सकते हैं।
Script Block logging के बारे में एक अच्छी बात यह है कि भले ही कोई दुर्भावनापूर्ण स्क्रिप्ट XOR, Base 64, ROT13, आदि के साथ अस्पष्ट (obfuscated) हो, फिर भी डिकोड की गई स्क्रिप्ट लॉग हो जाएगी, जिससे विश्लेषण बहुत आसान हो जाता है।
ये लॉग मॉड्यूल logging की तुलना में काम करने के लिए अधिक उचित हैं, क्योंकि यदि कोई हमलावर Mimikatz चलाता है, तो 7 MB और 2000 से अधिक इवेंट्स की तुलना में केवल 5 MB और 100 इवेंट्स उत्पन्न होंगे।
हालाँकि, Script Block logging के साथ कमांड के आउटपुट दर्ज नहीं किए जाते हैं।
Group Policy संपादक में, Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell खोलें और Turn on PowerShell Script Block Logging सक्षम करें।
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1
डिफ़ॉल्ट सेटिंग्स: No Auditing
Transcription logs के साथ PowerShell लॉग्स को स्थानीय कंप्यूटर पर टेक्स्ट फ़ाइलों में सहेजना भी संभव है। जबकि एक हमलावर आमतौर पर एंटी-फोरेंसिक के लिए transcription logs को आसानी से हटा सकता है, ऐसे परिदृश्य हो सकते हैं जहां हमलावर सभी इवेंट लॉग्स को साफ़ कर देता है लेकिन हटाने के लिए transcription logs की खोज नहीं करता है। इसलिए, यदि संभव हो तो transcription logs को भी सक्षम करने की अनुशंसा की जाती है। डिफ़ॉल्ट रूप से, उन्हें उपयोगकर्ता के Documents फ़ोल्डर में सहेजा जाता है। आदर्श रूप से transcript logs को केवल-लेखन (write-only) नेटवर्क फ़ाइल शेयर में सहेजा जाना चाहिए, हालाँकि, व्यवहार में इसे लागू करना कठिन हो सकता है। Transcription logs का एक लाभ यह है कि उनमें प्रत्येक कमांड के लिए टाइमस्टैम्प और मेटाडेटा शामिल होता है और वे बहुत स्टोरेज कुशल होते हैं, Mimikatz निष्पादन के लिए 6 KB से कम। नकारात्मक पक्ष यह है कि transcription logs केवल वही रिकॉर्ड करते हैं जो PowerShell टर्मिनल में दिखाई देता है।
Group Policy संपादक में, Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell खोलें और Turn on PowerShell Transcription सक्षम करें।
फिर, आउटपुट निर्देशिका निर्दिष्ट करें।
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)
### संदर्भ
* [Mandiant ब्लॉग: PowerShell लॉगिंग के माध्यम से अधिक दृश्यता](https://www.mandiant.com/resources/blog/greater-visibilityt)
## सिस्टम लॉग (55 सिग्मा नियम)
File: `System.evtx`
Default settings: `Enabled. 20 MB`
Recommended settings: `Enabled. 128 MB+`
मैलवेयर अक्सर पर्सिस्टेंस, लोकल प्रिविलेज एस्केलेशन, आदि के लिए सेवाएँ इंस्टॉल करता है... जो इस लॉग में पाया जा सकता है। यहाँ विभिन्न कमजोरियों का शोषण किए जाने का पता लगाना भी संभव है।
> **नोट: सिस्टम लॉग के लिए विशेष रूप से ध्यान देने वाली बात यह है कि फ़ील्ड्स में पैरामीटर कभी-कभी स्थानीय भाषा में अनुवादित हो जाते हैं, इसलिए केवल अंग्रेज़ी का उपयोग करने वाले सिग्नेचर गैर-अंग्रेज़ी सिस्टम पर पता नहीं लगा सकते। उदाहरण के लिए, EID 7045 के पैरामीटर में एक अंग्रेज़ी सिस्टम पर `Enabled` दर्ज होगा जबकि जापानी में `有効` दर्ज हो सकता है।**
> **नोट: `Application` लॉग की तरह ही, कई प्रोवाइडर एक ही इवेंट ID पर लॉग करते हैं, इसलिए आपको चैनल के साथ-साथ प्रोवाइडर नाम पर भी फ़िल्टर करने की आवश्यकता हो सकती है। उदाहरण के लिए इवेंट ID `1` का उपयोग विभिन्न प्रोवाइडर अलग-अलग इवेंट के लिए करते हैं।**
महत्वपूर्ण इवेंट ID:
| इवेंट ID | विवरण | सिग्मा नियम | Hayabusa नियम | स्तर | नोट्स |
| :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | सिस्टम स्लीप/हाइबरनेशन | 0 | अभी नहीं। | सूचना | प्रोवाइडर: `Power-Troubleshooter` |
| 1 | सिस्टम समय बदला गया | 0 | अभी नहीं। | सूचना | प्रोवाइडर: `Kernel-General` |
| 12 | OS स्टार्टअप | 0 | अभी नहीं। | सूचना | |
| 13 | OS शटडाउन | 0 | अभी नहीं। | सूचना | |
| 16 | रेजिस्ट्री हाइव एक्सेस इतिहास साफ़ किया गया | 2 | अभी नहीं। | उच्च~गंभीर | पासवर्ड डंपर्स SAM रेजिस्ट्री कुंजी से पासवर्ड हैश डंप करने के बाद एक्सेस इतिहास साफ़ कर सकते हैं। हालांकि यह सामान्य रूप से भी होता है, इसलिए FP को फ़िल्टर करने की आवश्यकता है। |
| 55 | NTFS फाइलसिस्टम दूषित हुआ | 1 | नहीं | उच्च | NTFS कमजोरियों के विरुद्ध हमलों का पता लगा सकता है। |
| 104 | सिस्टम इवेंट लॉग साफ़ किया गया | 1 | हाँ | मध्यम | |
| 6005 | इवेंट लॉग सेवा प्रारंभ हुई | 0 | हाँ | सूचना | |
| 6006 | इवेंट लॉग सेवा रोकी गई | 0 | हाँ | सूचना | |
| 6008 | अप्रत्याशित शटडाउन | 0 | हाँ | सूचना | |
| 6038 | NTLMv1 का उपयोग किया गया | 1 | नहीं | निम्न | |
| 7031 | सेवा क्रैश हुई | 0 | हाँ | निम्न | |
| 7034 | सेवा क्रैश हुई | 0 | हाँ | निम्न | |
| 7036 | सेवा प्रारंभ/रोकी गई | 2 | हाँ | सूचना~उच्च | किसी के द्वारा Defender को रोकने आदि का पता लगाने के लिए इस्तेमाल किया जा सकता है... |
| 7040 | सेवा स्टार्टअप प्रकार बदला गया | 0 | हाँ | सूचना | यह संकेत दे सकता है कि किसी हमलावर ने सेवा अक्षम की है। |
| 7045 | सेवा स्थापना | 37 | हाँ | सूचना~गंभीर | यह सबसे महत्वपूर्ण सिस्टम इवेंट ID है क्योंकि मैलवेयर अक्सर स्वयं को सेवा के रूप में स्थापित करता है या सेवाओं का दुरुपयोग करता है। |
| 20001 | नया PNP डिवाइस | 0 | हाँ | सूचना~? | स्तर इस पर निर्भर करेगा कि USB डिवाइस की अनुमति है या नहीं। केवल पहली बार डिवाइस प्लग होने पर लॉग करता है। गैर-USB PNP डिवाइस इवेंट बहुत शोर वाले होते हैं, इसलिए संभवतः उन्हें फ़िल्टर कर दिया जाना चाहिए। |
## एप्लिकेशन लॉग (16 सिग्मा नियम)
यह लॉग अधिकतर शोर है, लेकिन आपको यहाँ कुछ महत्वपूर्ण सबूत मिल सकते हैं। कुछ तृतीय-पक्ष एंटी-वायरस सॉफ़्टवेयर यहाँ लॉग करते हैं। एप्लिकेशन लॉग के साथ सावधान रहने वाली बात यह है कि विभिन्न विक्रेता एक ही इवेंट ID का उपयोग विभिन्न इवेंट के लिए करते हैं, इसलिए आपको केवल इवेंट ID पर ही नहीं, बल्कि प्रोवाइडर नामों पर भी फ़िल्टर करना चाहिए।
File: `Application.evtx`
Default settings: `Enabled. 20 MB`
Recommended settings: `Enabled. 128 MB+`
महत्वपूर्ण इवेंट ID:
| इवेंट ID | प्रोवाइडर | विवरण | सिग्मा नियम | Hayabusa नियम | स्तर | नोट्स |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | `Audit-CVE`, `Microsoft-Windows-Audit-CVE` | ज्ञात कमजोरी (CVE) शोषण प्रयास | 1 | नहीं | गंभीर | यह उन इवेंट का पता लगाता है जो यूज़र-मोड एप्लिकेशन तब उत्पन्न करते हैं जब वे CveEventWrite API को कॉल करते हैं जब किसी ज्ञात कमजोरी का शोषण करने का प्रयास किया जा रहा हो। MS ने 2020/01 में CVE-2020-0601 (एक Windows CryptoAPI कमजोरी) के साथ इस लॉग का उपयोग शुरू किया। दुर्भाग्य से, CVEs के इस लॉग में लिखे जाने का लगभग यही एकमात्र उदाहरण है। |
| 325 | `ESENT` | ESE DB बनाया गया | 2 | नहीं | सूचना~गंभीर | यह पता लगाता है कि कोई प्रोसेस ESE डेटाबेस कब बनाता है। इसका उपयोग विभिन्न चीजों के लिए किया जाता है जैसे Exchange, AD, सर्टिफिकेट सेवाएँ, SRUM, आदि। सुरक्षा के लिए सबसे महत्वपूर्ण ESE DB NTDS.dit है, जो डोमेन कंट्रोलर पर स्थित सभी डोमेन उपयोगकर्ताओं के पासवर्ड हैश की फ़ाइल है। NTDS.dit के डंपिंग का पता लगाने के लिए दो सिग्मा नियम हैं, हालांकि यदि कोई व्यवस्थापक बैकअप के लिए ntdsutil का उपयोग करता है या शैडो कॉपी बनाई जाती है तो यह गलत सकारात्मक हो सकता है। |
| 326 | `ESENT` | ESE DB जोड़ा गया | 1 | नहीं | सूचना~गंभीर | NTDS.dit तक पहुँच का पता लगाने में सक्षम हो सकता है। |
| 1000, 1001 | `Application Error`, `Windows Error Reporting` | एप्लिकेशन त्रुटि | 1 | नहीं | सूचना~उच्च | |
| 1034, 11724 | `MsiInstaller` | एप्लिकेशन अनइंस्टॉल किया गया | 1 | नहीं | सूचना~निम्न | |
| 1040 | `MsiInstaller` | एप्लिकेशन इंस्टॉलेशन | 1 | नहीं | सूचना~मध्यम | |
| 33205 | `MSSQLSERVER` | SQL ऑडिट इवेंट | 6 | नहीं | सूचना~उच्च | MSSQL बैकडोर, SQL/कमांड इंजेक्शन आदि का पता लगा सकता है... |
## Windows Defender ऑपरेशनल लॉग (10 सिग्मा नियम)
File: `Microsoft-Windows-Windows Defender%4Operational.evtx`
Default settings: `Enabled. 1 MB`
Recommended settings: `Enabled. 128 MB+`
आप न केवल Windows Defender अलर्ट (जिनकी निगरानी करना महत्वपूर्ण है) का पता लगा सकते हैं, बल्कि जोड़े गए बहिष्करण, अक्षम किया गया टैम्पर प्रोटेक्शन, हटाया गया इतिहास, आदि का भी पता लगा सकते हैं...
## Bits-Client ऑपरेशनल लॉग (6 सिग्मा नियम)
File: `Microsoft-Windows-Bits-Client%4Operational.evtx`
Default settings: `Enabled. 1 MB`
Recommended settings: `Enabled. 128 MB+`
Bitsadmin.exe एक लोकप्रिय [lolbin](https://lolbas-project.github.io/lolbas/Binaries/Bitsadmin/) है जिसका हमलावर मैलवेयर डाउनलोड करने और निष्पादित करने के लिए दुरुपयोग करते हैं। आपको इस लॉग में इसके सबूत मिल सकते हैं, हालांकि ध्यान देने योग्य कई गलत सकारात्मक होंगे।
## फ़ायरवॉल लॉग (6 सिग्मा नियम)
File: `Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx`
Default settings: `Enabled? 1 MB`
Recommended settings: `Enabled. 256 MB+`
यहाँ फ़ायरवॉल नियम जोड़े/संशोधित/हटाए जाने के सबूत मिल सकते हैं। मैलवेयर अक्सर यह सुनिश्चित करने के लिए फ़ायरवॉल नियम जोड़ता है कि वे अपने C2 सर्वर के साथ संवाद कर सकें, लेटरल मूवमेंट के लिए प्रॉक्सी नियम जोड़ता है, आदि...
## NTLM ऑपरेशनल लॉग (3 सिग्मा नियम)
File: `Microsoft-Windows-NTLM%4Operational.evtx`
Default settings: `Enabled but Auditing is disabled. 1 MB`
यदि आप NTLM प्रमाणीकरण अक्षम करना चाहते हैं तो यह लॉग सक्षम करने की अनुशंसा की जाती है। NTLM को अक्षम करने से संभवतः कुछ संचार टूट जाएगा, इसलिए आप DCs और अन्य सर्वरों पर इस लॉग की निगरानी कर सकते हैं ताकि यह देख सकें कि अभी भी NTLM का उपयोग कौन कर रहा है और वैश्विक रूप से अक्षम करने से पहले उन उपयोगकर्ताओं से शुरू करके NTLM को धीरे-धीरे अक्षम करें। 4624 जैसे लॉगऑन इवेंट में आने वाले कनेक्शनों के लिए NTLM के उपयोग का पता लगाना संभव है, लेकिन यदि आप निगरानी करना चाहते हैं कि बाहर जाने वाले NTLM कनेक्शन कौन बना रहा है तो आपको यह लॉग सक्षम करना होगा।
ऑडिटिंग सक्षम करने के लिए, ग्रुप पॉलिसी में `Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options` खोलें और उचित विभिन्न `Network security: Restrict NTLM:` सेटिंग्स कॉन्फ़िगर करें।
संदर्भ: [Farewell NTLM](https://www.scip.ch/en/?labs.20210909)
## Security-Mitigations KernelMode और UserMode लॉग (2 सिग्मा नियम)
Files: `Microsoft-Windows-Security-Mitigations%4KernelMode.evtx`, `Microsoft-Windows-Security-Mitigations%4UserMode.evtx`
Default settings: `Enabled. 1 MB`
Recommended settings: `Enabled. 128 MB+`
इस समय इन लॉग्स के लिए केवल 2 सिग्मा नियम हैं, लेकिन आपको संभवतः सभी Exploit Protection, Network Protection, Controlled Folder Access और Attack Surface Reduction लॉग (लगभग 40+ इवेंट ID) एकत्र और मॉनिटर करने चाहिए।
दुर्भाग्य से, Attack Surface Reduction लॉग (पहले WDEG(Windows Defender Exploit Guard) और EMET) कई लॉग्स में फैले हुए हैं और उन्हें खोजने के लिए जटिल XML क्वेरी की आवश्यकता होती है।
विवरण: [attack surface reduction क्षमताओं को समझें और उपयोग करें](https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/overview-attack-surface-reduction?view=o365-worldwide)
## PrintService लॉग (2 सिग्मा नियम)
प्रिंट स्पूलर हमलावरों का पता लगाने के लिए Operational लॉग को भी सक्षम करने की अनुशंसा की जाती है। (उदा: PrintNightmare, आदि...)
### Admin (1 सिग्मा नियम)
File: `Microsoft-Windows-PrintService%4Admin.evtx`
Default settings: `Enabled. 1 MB`
Recommended settings: `Enabled. 128 MB+`
### Operational (1 सिग्मा नियम)
File: `Microsoft-Windows-PrintService%4Operational.evtx`
Default settings: `Disabled. 1 MB`
Recommended settings: `Enabled. 128 MB+`
## SMBClient सुरक्षा लॉग (2 सिग्मा नियम)
File: `Microsoft-Windows-SmbClient%4Security.evtx`
Default settings: `Enabled. 8 MB`
Recommended settings: `Enabled. 128 MB+`
PrintNightmare (IP से संदिग्ध अस्वीकृत SMB अतिथि लॉगऑन) और उपयोगकर्ताओं द्वारा छिपे हुए शेयर माउंट करने का पता लगाने के प्रयास के लिए उपयोग किया जाता है।
## AppLocker लॉग (1 सिग्मा नियम)
Files: `Microsoft-Windows-AppLocker%4MSI and Script.evtx`, `Microsoft-Windows-AppLocker%4EXE and DLL.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Deployment.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Execution.evtx`
Default settings: `Enabled if AppLocker is enabled? 1 MB`
Recommended settings: `Enabled. 256 MB+`
यह सुनिश्चित करना महत्वपूर्ण है कि यदि आप AppLocker का उपयोग कर रहे हैं तो यह सक्षम और मॉनिटर किया गया है।
## CodeIntegrity ऑपरेशनल लॉग (1 सिग्मा नियम)
File: `Microsoft-Windows-CodeIntegrity%4Operational.evtx`
Default settings: `Enabled. 1 MB`
Recommended settings: `Enabled. 128 MB+`
विंडोज कोड इंटीग्रिटी जाँच द्वारा अवरुद्ध किए जाने वाले ड्राइवर लोड इवेंट का पता लगाने के लिए इस लॉग की जाँच करें, जो एक दुर्भावनापूर्ण ड्राइवर का संकेत दे सकता है जो लोड होने में विफल रहा।
## Diagnosis-Scripted ऑपरेशनल लॉग (1 सिग्मा नियम)
File: `Microsoft-Windows-Diagnosis-Scripted%4Operational.evtx`
Default settings: `Enabled. 1 MB`
Recommended settings: `Enabled. 128 MB+`
शोषण के लिए diagcab पैकेजों के उपयोग के सबूत यहाँ मिल सकते हैं।
## DriverFrameworks-UserMode ऑपरेशनल लॉग (1 सिग्मा नियम)
Files: `Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx`
Default settings: `No Auditing. 1 MB`
Recommended settings: `Enabled. 128 MB+`
प्लग किए गए USB डिवाइसों का पता लगाता है।
## WMI-Activity ऑपरेशनल लॉग (1 सिग्मा नियम)
File: `Microsoft-Windows-WMI-Activity%4Operational.evtx`
Default settings: `Enabled on Win10/2016+. 1 MB`
Recommended settings: `Enabled. 128 MB+`
यह निगरानी के लिए महत्वपूर्ण है क्योंकि हमलावर अक्सर पर्सिस्टेंस और लेटरल मूवमेंट के लिए WMI का शोषण करते हैं।
## TerminalServices-LocalSessionManager ऑपरेशनल लॉग (1 सिग्मा नियम)
File: `Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx`
Default settings: `Enabled. 1 MB`
Recommended settings: `Enabled. 128 MB+`
यह पता लगाता है कि ngrok, एक रिवर्स प्रॉक्सी टूल, फ़ायरवॉल को बायपास करने के लिए ट्रैफ़िक को स्थानीय RDP पोर्ट पर फॉरवर्ड करता है।
लिंक: [RDP टनलिंग के माध्यम से नेटवर्क प्रतिबंधों को बायपास करना](https://www.mandiant.com/resources/blog/bypassing-network-restrictions-through-rdp-tunneling)
## TaskScheduler ऑपरेशनल लॉग (1 सिग्मा नियम)
File: `Microsoft-Windows-TaskScheduler%4Operational.evtx`
Default settings: `Disabled. 1 MB`
Recommended settings: `Enabled. 128 MB+`
हमलावर अक्सर पर्सिस्टेंस और लेटरल मूवमेंट के लिए कार्यों का दुरुपयोग करते हैं, इसलिए इसे सक्षम किया जाना चाहिए।