Data/Locales/checks/hi/ADTradecraftChecks.json
|
{ "_family": "ADTradecraftChecks.json", "ADTRADE-001": { "name": { "value": "SYSVOL में Group Policy Preferences cpassword अवशेष", "status": "machine-draft" }, "description": { "value": "2008 से मई 2014 तक, Group Policy Preferences ने प्रशासकों को 'cpassword' फ़ील्ड का उपयोग करके अनुसूचित कार्य, स्थानीय उपयोगकर्ता पासवर्ड, मैप की गई ड्राइव, और सेवाएं पुश करने दीं, जो Microsoft द्वारा सार्वजनिक रूप से प्रलेखित AES-256 कुंजी से एन्क्रिप्ट किए गए थे। MS14-025 में सुधार ने नई preferences में cpassword फ़ील्ड को अक्षम किया परंतु SYSVOL में मौजूदा को अछूता छोड़ दिया। हर red-team सगाई अब भी इन्हें ढूंढती है। कोई भी प्रमाणित डोमेन उपयोगकर्ता SYSVOL पढ़ सकता है, cpassword ले सकता है, और उसे ऑफ़लाइन डिक्रिप्ट कर सकता है। यदि आपको यहां कुछ मिलता है, तो उजागर प्रत्येक क्रेडेंशियल को समझौता किया गया मानें और उसे घुमाएं।", "status": "machine-draft" }, "recommendedValue": { "value": "\\\\domain\\SYSVOL\\domain\\Policies\\**\\*.xml के अंतर्गत कहीं भी शून्य cpassword विशेषताएं।", "status": "machine-draft" }, "remediationSteps": { "value": "SYSVOL स्कैन करें: Get-ChildItem -Path \\\\<domain>\\SYSVOL\\<domain>\\Policies -Recurse -Include *.xml | Select-String 'cpassword'। प्रत्येक मिलान के लिए: (1) उस खाते का पासवर्ड घुमाएं जिसका क्रेडेंशियल उजागर है (उपयोगकर्ता नाम उसी XML में है), (2) preference बनाए जाने के बाद से उस क्रेडेंशियल के उपयोग हेतु लॉग की लेखापरीक्षा करें, (3) नया क्रेडेंशियल स्थापित होने के बाद GPP preference हटाएं। Microsoft के KB2962486 में सफ़ाई मार्गदर्शन है।", "status": "machine-draft" } }, "ADTRADE-002": { "name": { "value": "DCShadow संकेतक (दुष्ट Configuration-Partition सर्वर)", "status": "machine-draft" }, "description": { "value": "DCShadow (Vincent LE TOUX / Benjamin Delpy, BlueHat IL 2018) CN=Sites,CN=Configuration के अंतर्गत nTDSDSA + server ऑब्जेक्ट लिखकर किसी हमलावर-नियंत्रित होस्ट को डोमेन नियंत्रक के रूप में पंजीकृत करता है। फिर उस नकली DC का उपयोग वास्तविक DC हुए बिना दुर्भावनापूर्ण प्रतिकृति डेटा (SID history, पासवर्ड हैश) इंजेक्ट करने के लिए किया जाता है। नोट: दीर्घकालिक डोमेन पर एक बेमेल server ऑब्जेक्ट किसी वास्तविक DCShadow हमले की तुलना में अक्सर LINGERING DC METADATA ('ntdsutil metadata cleanup' के बिना हटाया गया DC) होता है, इसलिए इसे Critical के बजाय High रेट किया गया है: हाल ही में बनाए गए (संदिग्ध) ऑब्जेक्ट को पुराने stale metadata से अलग करने के लिए whenCreated टाइमस्टैम्प की जांच करें।", "status": "machine-draft" }, "recommendedValue": { "value": "CN=Sites,CN=Configuration के अंतर्गत सभी server ऑब्जेक्ट वास्तविक, सूचीबद्ध डोमेन नियंत्रकों के अनुरूप हों। कोई हाल ही में बनाए गए server ऑब्जेक्ट न हों जो किसी ज्ञात DC से मेल न खाते हों।", "status": "machine-draft" }, "remediationSteps": { "value": "सूचीबद्ध करें: Get-ADObject -Filter {objectClass -eq 'server'} -SearchBase \"CN=Sites,$((Get-ADRootDSE).configurationNamingContext)\" -Properties whenCreated, dNSHostName | Sort whenCreated। अपनी DC सूची (Get-ADDomainController -Filter *) से क्रॉस-रेफ़रेंस करें। किसी वास्तविक DC से मेल न खाने वाला कोई भी server ऑब्जेक्ट, विशेषकर हाल ही में बनाया गया, तत्काल IR की मांग करता है: DCShadow एक डोमेन-अधिग्रहण-स्तरीय प्रिमिटिव है। पता लगाने-समय संकेत के रूप में schema container पर 5137 / 5141 events की निगरानी करें।", "status": "machine-draft" } }, "ADTRADE-003": { "name": { "value": "पुरानी BitLocker पुनर्प्राप्ति कुंजियां", "status": "machine-draft" }, "description": { "value": "BitLocker पुनर्प्राप्ति कुंजियां उस कंप्यूटर के msFVE-RecoveryInformation चाइल्ड ऑब्जेक्ट के रूप में AD में संग्रहीत होती हैं जिसने उन्हें बैकअप किया। जब कोई कंप्यूटर सेवामुक्त हो जाता है परंतु AD ऑब्जेक्ट लटका छोड़ दिया जाता है, तो पुनर्प्राप्ति कुंजियां BitLocker पुनर्प्राप्ति अधिकार वाले किसी भी व्यक्ति द्वारा क्वेरी योग्य रहती हैं, जो आमतौर पर 'Tier-0' से व्यापक समूह होता है। पुरानी कुंजियों का अर्थ है कि निपटाई गई ड्राइव, यदि किसी रीफर्बिशर या कूड़ेदान से पुनर्प्राप्त हो जाएं, तो डिक्रिप्ट की जा सकती हैं।", "status": "machine-draft" }, "recommendedValue": { "value": "सभी msFVE-RecoveryInformation ऑब्जेक्ट पिछले 90 दिनों में सक्रिय कंप्यूटरों के हों। अक्षम या हाल ही में संशोधित-फिर-पुराने कंप्यूटर खातों की कोई अनाथ कुंजी न हो।", "status": "machine-draft" }, "remediationSteps": { "value": "पुनर्प्राप्ति सूचना सूचीबद्ध करें: Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} -Properties whenCreated। प्रत्येक के लिए, पैरेंट कंप्यूटर ऑब्जेक्ट तक जाएं और उसका lastLogonTimestamp / Enabled जांचें। 90 दिनों से अधिक निष्क्रिय कंप्यूटरों के लिए: पुष्टि करें कि ड्राइव मिटा या नष्ट कर दी गई है, फिर AD कंप्यूटर ऑब्जेक्ट हटाएं (जो पुनर्प्राप्ति सूचना को कैस्केड करता है)। सक्रिय रूप से उपयोग में परंतु बहुत पुरानी पुनर्प्राप्ति कुंजियों वाले कंप्यूटरों के लिए: Backup-BitLockerKeyProtector के माध्यम से घुमाएं। सत्यापित करें कि BitLocker पुनर्प्राप्ति समूह की सदस्यता कड़ी है।", "status": "machine-draft" } }, "ADTRADE-004": { "name": { "value": "RODC Password Replication Policy स्वच्छता", "status": "machine-draft" }, "description": { "value": "Read-Only Domain Controllers अपनी Password Replication Policy (PRP) में सूचीबद्ध प्रिंसिपलों के लिए पासवर्ड कैश करते हैं। यदि कोई Tier-0 खाता (Domain Admin, Enterprise Admin, krbtgt) किसी RODC की PRP द्वारा पहुंच योग्य है, प्रत्यक्ष रूप से या समूह नेस्टिंग के माध्यम से, तो RODC से समझौता उन खातों से समझौता कर देता है। डिफ़ॉल्ट 'Denied RODC Password Replication Group' में स्पष्ट रूप से DA / EA / SA / Schema Admins / krbtgt होने चाहिए; कुछ परिवेश नीति को कस्टमाइज़ करते हैं और अनजाने में उन इनकारों को हटा देते हैं।", "status": "machine-draft" }, "recommendedValue": { "value": "डोमेन में सभी RODC की Password Replication Policy ऐसी हो जहां Domain Admins, Enterprise Admins, Schema Admins, krbtgt, और Account Operators Deny पक्ष के सदस्य हों। कोई उच्च-विशेषाधिकृत खाता Allow पक्ष का सदस्य न हो।", "status": "machine-draft" }, "remediationSteps": { "value": "प्रत्येक RODC के लिए: Get-ADDomainController -Filter {IsReadOnly -eq $true} | ForEach-Object { Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Allowed; Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Denied }। सत्यापित करें कि Denied सूची में अंतर्निहित 'Denied RODC Password Replication Group' शामिल है। यदि आपके परिवेश में कोई RODC नहीं है तो यह जांच N/A है: PASS। Microsoft के RODC योजना मार्गदर्शन में विहित PRP टेम्पलेट है।", "status": "machine-draft" } }, "ADTRADE-005": { "name": { "value": "Entra Seamless SSO कंप्यूटर खाता (AZUREADSSOACC$) कुंजी रोटेशन", "status": "machine-draft" }, "description": { "value": "जब हाइब्रिड पहचान के लिए Entra (Azure AD) Seamless Single Sign-On सक्षम होता है, तो AD AZUREADSSOACC$ नामक कंप्यूटर खाता बनाता है। इसका पासवर्ड वह साझा Kerberos कुंजी है जिसका उपयोग Entra SSO टिकट सत्यापित करने के लिए करता है। Microsoft प्रलेखित करता है कि यह कुंजी स्वचालित रूप से घुमाई नहीं जाती: प्रशासकों को इसे घुमाना पड़ता है। यदि कोई हमलावर AZUREADSSOACC$ कुंजी निकाल लेता है (यह एक सामान्य NT हैश है जो DCSync के माध्यम से या किसी DC से पठनीय है), तो वह Azure AD सेवा के लिए Kerberos Silver Tickets बना सकता है और किसी भी सिंक्रनाइज़ हाइब्रिड उपयोगकर्ता के रूप में, बिना किसी और अंतःक्रिया के, तब तक प्रमाणित हो सकता है जब तक कुंजी वैध रहती है। 90 दिनों से अधिक न घुमाई गई कुंजी उस खिड़की को नाटकीय रूप से चौड़ा कर देती है।", "status": "machine-draft" }, "recommendedValue": { "value": "AZUREADSSOACC$ Kerberos कुंजी कम से कम हर 90 दिनों में घुमाई गई हो (पिछली कुंजी को अमान्य करने के लिए प्रति रोटेशन इसे दो बार घुमाएं)।", "status": "machine-draft" }, "remediationSteps": { "value": "Entra Connect / Azure AD मॉड्यूल वाली मशीन पर Seamless SSO कुंजी घुमाएं: Import-Module 'C:\\Program Files\\Microsoft Azure Active Directory Connect\\AzureADSSO.psd1'; New-AzureADSSOAuthenticationContext; Update-AzureADSSOForest। रोटेशन दो बार करें (खाता वर्तमान + पिछली कुंजी संग्रहीत करता है) और इसे आवर्ती आधार पर अनुसूचित करें। यदि Seamless SSO का अब उपयोग नहीं है, तो इसे अक्षम करें और AZUREADSSOACC$ ऑब्जेक्ट हटाएं।", "status": "machine-draft" } }, "ADTRADE-006": { "name": { "value": "विशेषाधिकृत प्रिंसिपलों पर Shadow Credentials (msDS-KeyCredentialLink)", "status": "machine-draft" }, "description": { "value": "msDS-KeyCredentialLink विशेषता Windows Hello for Business / पासवर्डरहित PKINIT लॉगिन के लिए उपयोग की जाने वाली सार्वजनिक कुंजियां रखती है। इस विशेषता पर किसी लक्ष्य पर लेखन पहुंच रखने वाला हमलावर अपनी स्वयं की कुंजी जोड़ी जोड़ सकता है (Whisker / pyWhisker) और फिर मिलान करने वाली निजी कुंजी का उपयोग करके उस खाते के रूप में Kerberos TGT का अनुरोध कर सकता है, जो 'shadow credentials' नामक एक गुप्त दृढ़ता और प्रतिरूपण तकनीक है। किसी Tier-0 ऑब्जेक्ट (एक domain admin, एक डोमेन नियंत्रक, या कोई adminCount=1 खाता) पर किसी अप्रत्याशित कुंजी क्रेडेंशियल को तब तक संभावित बैकडोर माना जाना चाहिए जब तक कि यह वैध WHfB नामांकन सिद्ध न हो जाए।", "status": "machine-draft" }, "recommendedValue": { "value": "विशेषाधिकृत/Tier-0 प्रिंसिपलों पर कोई अपरिचित msDS-KeyCredentialLink मान न हो; प्रत्येक कुंजी किसी ज्ञात WHfB/पासवर्डरहित नामांकन से मैप हो।", "status": "machine-draft" }, "remediationSteps": { "value": "प्रत्येक चिह्नित प्रिंसिपल के लिए, कुंजी क्रेडेंशियल की जांच करें (Get-ADObject -Properties msDS-KeyCredentialLink, या DSInternals Get-ADKeyCredential cmdlet) और प्रत्येक उपकरण कुंजी को किसी वैध Windows Hello for Business नामांकन से सहसंबद्ध करें। किसी भी ऐसी प्रविष्टि को हटाएं जिसे आप किसी अनुमोदित नामांकन के लिए जिम्मेदार नहीं ठहरा सकते। सीमित करें कि कौन msDS-KeyCredentialLink लिख सकता है (Key Admins / Enterprise Key Admins और उस लेखन को प्रदान करने वाले OU/object DACL की लेखापरीक्षा करें)। यदि समझौते का संदेह हो तो प्रभावित खाते रीसेट करें।", "status": "machine-draft" } }, "ADTRADE-007": { "name": { "value": "BadSuccessor dMSA स्थानांतरण वृद्धि सतह", "status": "machine-draft" }, "description": { "value": "Windows Server 2025 ने एक स्थानांतरण सुविधा के साथ delegated Managed Service Accounts (dMSA, ऑब्जेक्ट वर्ग msDS-DelegatedManagedServiceAccount) पेश किए: किसी dMSA को किसी मौजूदा खाते को अधिक्रमित करने के रूप में चिह्नित किया जा सकता है, जिसके बाद वह उस खाते के विशेषाधिकार और Kerberos कुंजियां प्राप्त कर लेता है। 2024 में प्रकट 'BadSuccessor' तकनीक इसका दुरुपयोग करती है: कोई प्रिंसिपल जो किसी OU में केवल एक dMSA बना सकता है (dMSA वर्ग पर CreateChild, या OU पर व्यापक write/GenericAll), एक बना सकता है, उसे किसी विशेषाधिकृत खाते की ओर इंगित कर सकता है, और उसकी कुंजियां प्राप्त कर सकता है, उस खाते पर सीधे अधिकार धारण किए बिना उस तक वृद्धि कर सकता है। यह जांच उन OU की सूची बनाती है जहां कोई गैर-Tier-0 प्रिंसिपल यह क्षमता रखता है।", "status": "machine-draft" }, "recommendedValue": { "value": "कोई गैर-Tier-0 प्रिंसिपल किसी भी OU में delegated MSA (msDS-DelegatedManagedServiceAccount) न बना सके और न ही लिख सके।", "status": "machine-draft" }, "remediationSteps": { "value": "प्रत्येक चिह्नित OU पर, गैर-प्रशासनिक प्रिंसिपलों से CreateChild (msDS-DelegatedManagedServiceAccount वर्ग के लिए), GenericAll, WriteDacl, और WriteOwner हटाएं। प्रत्यायोजित OU अनुमतियों की व्यापक रूप से लेखापरीक्षा करें: वही ACE जो BadSuccessor को सक्षम करते हैं, अन्य ऑब्जेक्ट-निर्माण दुरुपयोगों को भी सक्षम करते हैं। पैच/शमन होने तक, msDS-DelegatedManagedServiceAccount ऑब्जेक्ट के निर्माण की निगरानी करें (4662/5137 events)। यह जांच उन फ़ॉरेस्ट पर SKIP करती है जिनका schema Server 2025 से पूर्व का है।", "status": "machine-draft" } }, "ADTRADE-008": { "name": { "value": "Key Admins / Enterprise Key Admins समूह सदस्यता", "status": "machine-draft" }, "description": { "value": "Key Admins (डोमेन RID 526) और Enterprise Key Admins (RID 527) समूहों को डोमेन/फ़ॉरेस्ट भर में msDS-KeyCredentialLink विशेषता लिखने का अधिकार प्रदान किया जाता है। इससे कोई भी सदस्य एक डोमेन-व्यापी shadow-credential प्रिमिटिव बन जाता है: एक सदस्य किसी भी खाते पर कुंजी क्रेडेंशियल लगा सकता है और PKINIT के माध्यम से उसके रूप में प्रमाणित हो सकता है। ये समूह खाली शिप होते हैं और तब तक खाली रहने चाहिए जब तक कि किसी विशिष्ट Windows Hello for Business कुंजी-प्रावधान वर्कफ़्लो को स्पष्ट रूप से इनकी आवश्यकता न हो। कोई भी सदस्य एक वृद्धि पथ है जिसे उचित ठहराया जाना चाहिए।", "status": "machine-draft" }, "recommendedValue": { "value": "Key Admins और Enterprise Key Admins समूह खाली हों (कोई स्थायी सदस्य न हो)।", "status": "machine-draft" }, "remediationSteps": { "value": "Key Admins और Enterprise Key Admins के प्रत्येक सदस्य की समीक्षा करें। किसी भी ऐसे खाते को हटाएं जिसकी Windows Hello for Business कुंजियां प्रावधानित करने की कोई प्रलेखित, सतत आवश्यकता न हो। यदि WHfB कुंजी प्रावधान के लिए प्रत्यायोजित अधिकार आवश्यक हैं, तो इन डोमेन-व्यापी समूहों में सदस्यता के बजाय उन्हें न्यूनतम संभव अनुमतियों वाले एक समर्पित सेवा खाते तक सीमित करें। अप्रत्याशित सदस्यों को एक संभावित दृढ़ता तंत्र मानें।", "status": "machine-draft" } }, "ADTRADE-009": { "name": { "value": "Cert Publishers समूह सदस्यता", "status": "machine-draft" }, "description": { "value": "Cert Publishers समूह (डोमेन RID 517) के सदस्यों को NTAuth स्टोर और उपयोगकर्ता/कंप्यूटर ऑब्जेक्ट पर प्रमाणपत्र प्रकाशित करने की अनुमति है। डिफ़ॉल्ट रूप से समूह में केवल Enterprise CA कंप्यूटर खाता(खाते) होते हैं। इस समूह में रखा गया कोई उपयोगकर्ता या सेवा खाता यह प्रभावित करने की क्षमता प्राप्त कर लेता है कि प्रमाणीकरण के लिए कौन से प्रमाणपत्रों पर भरोसा किया जाता है, जो कई AD CS वृद्धि पथों (ESC-श्रेणी हमले) में एक सीढ़ी है और प्रमाणपत्र-आधारित प्रतिरूपण सक्षम कर सकता है। कंप्यूटर-खाता सदस्यता (CA होस्ट स्वयं) अपेक्षित है; कोई भी गैर-कंप्यूटर सदस्य एक निष्कर्ष है।", "status": "machine-draft" }, "recommendedValue": { "value": "Cert Publishers में केवल Enterprise CA कंप्यूटर खाता(खाते) हों: कोई उपयोगकर्ता या सेवा खाता नहीं।", "status": "machine-draft" }, "remediationSteps": { "value": "Cert Publishers समूह से किसी भी उपयोगकर्ता या सेवा खाते को हटाएं; वहां केवल Enterprise CA कंप्यूटर खाते ही होने चाहिए। अप्रत्याशित CA प्रमाणपत्रों के लिए NTAuth स्टोर सामग्री (certutil -viewstore -enterprise NTAuth) की समीक्षा करें। AD CS को व्यापक रूप से हार्डन करें: प्रमाणपत्र टेम्पलेट नामांकन अनुमतियों और ESC1-ESC8 गलत-कॉन्फ़िगरेशन सतह की लेखापरीक्षा करें।", "status": "machine-draft" } }, "ADTRADE-010": { "name": { "value": "group Managed Service Account (gMSA) मुद्रा और पासवर्ड उजागरता", "status": "machine-draft" }, "description": { "value": "group Managed Service Accounts (gMSA) 240-बिट पासवर्ड रखते हैं जिन्हें AD स्वचालित रूप से उत्पन्न और घुमाता है, जो कमज़ोर सेवा-खाता पासवर्ड के Kerberoasting और मैनुअल रोटेशन के परिश्रम को समाप्त करता है। दो मुद्रा चिंताएं: (1) क्या सेवा पहचानों के लिए gMSA का उपयोग किया जाता है, और (2) प्रबंधित पासवर्ड पुनर्प्राप्त करने के लिए कौन अधिकृत है, जो msDS-GroupMSAMembership सुरक्षा विवरणक (PrincipalsAllowedToRetrieveManagedPassword) द्वारा नियंत्रित है। यदि वह विवरणक किसी व्यापक प्रिंसिपल (Everyone, Authenticated Users, Domain Users) या किसी गैर-विशेषाधिकृत प्रिंसिपल को प्रदान करता है, तो वह प्रिंसिपल सादे-पाठ gMSA पासवर्ड पुनर्प्राप्त कर सकता है (जैसे GMSAPasswordReader) और सेवा का पूर्ण प्रतिरूपण कर सकता है।", "status": "machine-draft" }, "recommendedValue": { "value": "सेवा पहचानें gMSA के रूप में चलें; msDS-GroupMSAMembership केवल उन विशिष्ट होस्ट तक सीमित हो जिन्हें सेवा चलानी है (कोई व्यापक या गैर-विशेषाधिकृत प्रिंसिपल नहीं)।", "status": "machine-draft" }, "remediationSteps": { "value": "प्रत्येक gMSA के लिए, PrincipalsAllowedToRetrieveManagedPassword को उन सटीक कंप्यूटर खातों (या एक कड़ाई से सीमित समूह) पर सेट करें जो सेवा चलाते हैं: Set-ADServiceAccount -Identity <gmsa> -PrincipalsAllowedToRetrieveManagedPassword <hosts>। उस सूची से Everyone / Authenticated Users / Domain Users हटाएं। जहां सेवा खाते अभी भी स्थैतिक उपयोगकर्ता-खाता पासवर्ड का उपयोग करते हैं, स्वचालित रोटेशन और Kerberoasting प्रतिरोध प्राप्त करने के लिए उन्हें gMSA में स्थानांतरित करें।", "status": "machine-draft" } } } |