Exploit for CVE-2026-29923

## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-ATHENASEC16-CVE-2026-29923
# CVE-2026-29923 - pstrip64.sys के माध्यम से स्थानीय विशेषाधिकार वृद्धि हमला

**अस्वीकरण:** यह कोड केवल शैक्षिक और रक्षात्मक अनुसंधान उद्देश्यों के लिए प्रदान किया गया है। इसे कर्नेल शोषण की समझ को बढ़ाने और रक्षकों को समान कमजोरियों से बचाने में मदद करने के लिए लिखा गया था। इस परियोजना का कोई भी अनधिकृत, अवैध या दुर्भावनापूर्ण उपयोग सख्त वर्जित है।

* * *

### विवरण

**हैश:** ab01485bb7c8bc1a9c86096eeea6d31d8fad557bf4d44072b46373d2203faa6e

**ड्राइवर नाम:** pstrip64.sys

**CVE:** CVE-2026-29923

"अपना स्वयं का कमजोर ड्राइवर लाएं" (BYOVD) हमला एक पुराना लेकिन बेहद प्रभावी तरीका है जिसके द्वारा हमलावर एक विरासत ड्राइवर का उपयोग करके आधुनिक विंडोज सुरक्षा सुरक्षा को बायपास कर सकते हैं जिसे ऑपरेटिंग सिस्टम अभी भी आधिकारिक रूप से विश्वसनीय मानता है। एक बार ड्राइवर लोड हो जाने के बाद, हमलावर इसकी खामियों का उपयोग करके एक मानक, अनप्रिविलेज्ड प्रक्रिया और पूर्ण सिस्टम-स्तरीय नियंत्रण के बीच की खाई को पाटता है।

इस सप्ताह की शुरुआत में, `pstrip64.sys` ड्राइवर में एक नई कमजोरी का खुलासा हुआ, जिसे `CVE-2026-29923` के रूप में ट्रैक किया गया है। यह ब्लॉग पोस्ट एक्सप्लॉइट के पूरे जीवनचक्र को विस्तार से बताता है: मेरे प्रारंभिक कमजोरी अनुसंधान और प्रूफ ऑफ कॉन्सेप्ट (PoC) के विकास से लेकर अपने वातावरण को सुरक्षित करने वाले रक्षकों के लिए कार्रवाई योग्य शमन रणनीतियों तक।

`pstrip64.sys` ड्राइवर EnTech Taiwan PowerStrip (संस्करण 3.90.736 तक) से जुड़ा एक विरासत कर्नेल-मोड घटक है। जबकि इसका वैध उद्देश्य उन्नत ग्राफिक्स कार्ड डिस्प्ले ट्वीकिंग को सक्षम करना है, इसके गहरे सिस्टम विशेषाधिकार इसे हमलावरों के लिए एक अत्यधिक आकर्षक लक्ष्य बनाते हैं।

* * *

### कमजोरी

जब कमजोरी का पहली बार खुलासा हुआ, तो मैंने इसके `DriverEntry` फ़ंक्शन का विश्लेषण करके शुरू किया। यह कर्नेल ड्राइवर के लिए मुख्य प्रारंभिक रूटीन के रूप में कार्य करता है, `\Device\PSTRIP64` डिवाइस ऑब्जेक्ट बनाता है और इसे `\DosDevices\PSTRIP64` सिम्बोलिक लिंक के माध्यम से उपयोगकर्ता-मोड अनुप्रयोगों के लिए एक्सपोज़ करता है। इससे भी महत्वपूर्ण बात, यह ड्राइवर की डिस्पैच टेबल को कॉन्फ़िगर करता है। वह प्रविष्टि जिसने तुरंत मेरा ध्यान खींचा, वह इंडेक्स 14 (`IRP_MJ_DEVICE_CONTROL`) पर थी, जो उपयोगकर्ता द्वारा प्रदान किए गए सभी IOCTL अनुरोधों को सीधे `sub_11340` हैंडलर फ़ंक्शन में रूट करती है, जो हमारा प्राथमिक रुचि क्षेत्र है।

![IDA DriverEntry](https://assets.kitploit.com/production/public/readmes/13419/2519eb07dbd5d7259ca408a3b00fed3d0fbd8a9a31952a3d69056edb48106650.png)

`sub_11340` फ़ंक्शन प्राथमिक IOCTL डिस्पैचर के रूप में कार्य करता है, जो उपयोगकर्ता-मोड से अनुरोधों की व्याख्या करता है।

सभी एक्सपोज़्ड IOCTL में से, `0x80002008` निस्संदेह सबसे दिलचस्प है। जबकि डिफ़ॉल्ट मामले छोटे I/O पोर्ट इंटरैक्शन को संभालते हैं, `0x80002008` `sub_11000` के लिए एक गेटवे के रूप में कार्य करता है, `SystemBuffer` को सीधे इस फ़ंक्शन में पास करके।

![IDA ioctl](https://assets.kitploit.com/production/public/readmes/13419/b05ae288ea7623366864cdb9196d9de129907ad22aaa214a4bac15774668c628.png)

यह `sub_11000` रूटीन सबूत का मुख्य टुकड़ा है। पहले, यह हमारे उपयोगकर्ता द्वारा प्रदान किए गए पते को लेने और इसे एक वैध सिस्टम भौतिक पते में अनुवाद करने के लिए `HalTranslateBusAddress` का उपयोग करता है। फिर, यह `\Device\PhysicalMemory` खोलता है और `ZwMapViewOfSection` का उपयोग करके इसे मैप करता है। लक्ष्य प्रक्रिया हैंडल को `(HANDLE)0xFFFFFFFFFFFFFFFFLL` (जो `ZwCurrentProcess()` का प्रतिनिधित्व करता है) पर हार्डकोड करके, ड्राइवर इस भौतिक मेमोरी को सीधे हमारी कॉलिंग प्रक्रिया के वर्चुअल एड्रेस स्पेस में मैप करता है। महत्वपूर्ण रूप से, यह फिर इस नए मैप किए गए वर्चुअल पते को `SystemBuffer` में वापस लिखता है ताकि उपयोगकर्ता को वापस किया जा सके, और आधिकारिक तौर पर हमारे एप्लिकेशन को भौतिक मेमोरी को पढ़ने और लिखने के लिए एक सीधा पॉइंटर सौंपता है।

![IDA MapViewofSection](https://assets.kitploit.com/production/public/readmes/13419/0a0c08ec29cb8ea442e1abfd53a73844ed1428dd8d8314d4d5b1207042b403db.png)

कमजोरी को पूरी तरह से समझ लेने और एक भौतिक रीड/राइट प्रिमिटिव स्थापित करने के बाद, मेरे पास सभी आवश्यक पहेली के टुकड़े हैं। अब, प्रूफ ऑफ कॉन्सेप्ट लिखना शुरू करने का समय है।

* * *

### प्रूफ ऑफ कॉन्सेप्ट (PoC)

**नोट:** यह PoC विशेष रूप से `Windows 10 22H2` वातावरण पर विकसित और परीक्षण किया गया था। चूंकि एक्सप्लॉइट कच्चे भौतिक मेमोरी हेरफेर पर निर्भर करता है, कर्नेल संरचना ऑफसेट और भौतिक मेमोरी सीमाएं वर्तमान में मेरे सेटअप के लिए हार्डकोडेड हैं। इसे अपनी मशीन पर परीक्षण करने के लिए, आपको विंडोज कर्नेल ऑफसेट को अपडेट करना होगा और भौतिक पता स्कैनिंग रेंज को अपने विशिष्ट OS बिल्ड और RAM कॉन्फ़िगरेशन से मिलाने के लिए समायोजित करना होगा।

मेरे एक्सप्लॉइट में पहला कदम ड्राइवर के साथ संचार स्थापित करना है। मैंने ड्राइवर के सिम्बोलिक लिंक (`\\.\PSTRIP64`) पर `CreateFileA` को कॉल करके ऐसा किया। एक बार जब मेरे पास एक वैध हैंडल था, तो मुझे पहले विश्लेषित `0x80002008` IOCTL का दुरुपयोग करने का एक साफ तरीका चाहिए था। मैंने `MapPhysicalMemory()` नामक एक रैपर फ़ंक्शन बनाया। यह फ़ंक्शन मेरे कस्टम `PSTRIP_MAP_REQUEST` स्ट्रक्ट को लक्ष्य भौतिक पते और मैं जिस मेमोरी चंक को पढ़ना चाहता हूं उसकी लंबाई से भरता है।

फिर मैं इस स्ट्रक्ट को सीधे `DeviceIoControl` के माध्यम से ड्राइवर को भेजता हूं। यदि सफल होता है, तो ड्राइवर उस भौतिक मेमोरी को सीधे मेरे उपयोगकर्ता-मोड एप्लिकेशन में मैप करता है और `OutputResult` फ़ील्ड में वर्चुअल बेस पता लौटाता है। अब मैं इस लौटाए गए पते को एक मानक C++ पॉइंटर में बदल सकता हूं, जिससे मुझे सिस्टम की भौतिक RAM तक कच्ची, अनप्रिविलेज्ड पहुंच मिलती है।

मेरे भौतिक रीड/राइट प्रिमिटिव के पूरी तरह से संचालन में आने के बाद, मेरा लक्ष्य कर्नेल डेटा संरचनाओं को ढूंढना था जिनमें प्रक्रिया विशेषाधिकार होते हैं। विंडोज में, प्रत्येक चल रही प्रक्रिया को एक `EPROCESS` संरचना द्वारा दर्शाया जाता है।

विंडोज कर्नेल पूल में `EPROCESS` संरचनाओं को पूल टैग नामक एक विशिष्ट 4-बाइट पहचानकर्ता का उपयोग करके आवंटित करता है। प्रक्रियाओं के लिए, यह टैग स्ट्रिंग `Proc` है (जो हेक्स में `0x636F7250` में अनुवादित होता है)। सिस्टम की भौतिक RAM को स्कैन करके, मैं इस सटीक स्ट्रिंग की खोज कर सकता था।

मेरा एक्सप्लॉइट `0x10000000` से `0x140000000` तक भौतिक मेमोरी स्पेस के माध्यम से लूप करता है, मेमोरी को 2MB चंक (`STEP_SIZE = 0x200000`) में मैप करता है। मैं प्रत्येक मैप किए गए चंक को एक कच्चे बाइट सरणी में कास्ट करता हूं और इसे 16-बाइट चंक (`sizeof(_POOL_HEADER)`) में स्कैन करता हूं।

हालांकि, भौतिक मेमोरी में केवल `Proc` टैग ढूंढना पर्याप्त नहीं है। मेमोरी गड़बड़ है, वह टैग समाप्त प्रक्रिया का अवशेष हो सकता है, या केवल यादृच्छिक डेटा जो हेक्स मान से मेल खाता है। यदि मैं आंख मूंदकर मान लेता कि प्रत्येक `Proc` टैग एक वैध `EPROCESS` संरचना है और मेमोरी को संशोधित करना शुरू कर देता, तो मैं तुरंत BSOD का कारण बनता।

स्थिरता सुनिश्चित करने के लिए, मुझे ह्यूरिस्टिक्स का उपयोग करके संरचना को मान्य करना पड़ा। पहले, मैं `EPROCESS` संरचना की शुरुआत की गणना करता हूं (जो पूल टैग से थोड़ा ऑफसेट बैठता है)। वहां से, मैं एक चल रही प्रक्रिया के लिए कुछ ज्ञात स्थिरांकों की जांच करता हूं:

  * **PriorityClass:** मैं सत्यापित करता हूं कि यह मान `0x2` (सामान्य प्राथमिकता) है।
  * **ProcessLock:** मैं सुनिश्चित करता हूं कि यह मान `0x0` है।
  * **ImageFileName:** मैं जांचता हूं कि प्रक्रिया नाम का पहला वर्ण एक वैध, मुद्रण योग्य ASCII वर्ण है।



यदि ये सभी ह्यूरिस्टिक्स पास हो जाते हैं, तो मैं काफी आश्वस्त हो सकता हूं कि मैं एक वैध, सक्रिय प्रक्रिया देख रहा हूं। फिर मैं इसका अद्वितीय प्रक्रिया आईडी (PID) पढ़ता हूं। यदि PID मेरी अपनी एक्सप्लॉइट प्रक्रिया से मेल खाता है, तो मैं इसके टोकन पॉइंटर का भौतिक पता सहेजता हूं। यदि PID `4` है (विंडोज `System` प्रक्रिया), तो मैं इसके अत्यधिक विशेषाधिकार प्राप्त टोकन का वास्तविक मान निकालता और सहेजता हूं।

अंत में, मैं अपनी प्रक्रिया के टोकन पॉइंटर के सहेजे गए भौतिक पते को निकटतम 4KB सीमा पर संरेखित करता हूं और केवल उस विशिष्ट पेज को मैप करने के लिए आखिरी बार `MapPhysicalMemory()` का उपयोग करता हूं।

इसके बाद, मैं सटीक ऑफसेट पर नेविगेट करता हूं और अपने टोकन को सिस्टम टोकन मान से ओवरराइट करता हूं। तुरंत, विंडोज कर्नेल मेरी एक्सप्लॉइट प्रक्रिया को `NT AUTHORITY\SYSTEM` के रूप में मानता है।

सिस्टम स्थिरता सुनिश्चित करने के लिए पेज को अनमैप करने के बाद, मैं `cmd.exe` को चलाने के लिए बस `CreateProcessA` को कॉल करता हूं। चूंकि मेरी वर्तमान प्रक्रिया उन्नत है, नई कमांड प्रॉम्प्ट इन शीर्ष-स्तरीय विशेषाधिकारों को प्राप्त कर लेती है, जिससे हमला सफलतापूर्वक पूरा हो जाता है!

* * *

### नोट्स

**नोट:** अपने प्रारंभिक डिबगिंग चरण के दौरान मैंने जो एक महत्वपूर्ण विवरण खोजा, वह यह है कि ड्राइवर मैप किए गए पॉइंटर को कैसे संभालता है। `SystemBuffer->LowPart = (unsigned int)BaseAddress;` निष्पादित करके, ड्राइवर 64-बिट वर्चुअल बेस पते को वापस लौटाने से पहले इसे 32-बिट मान में डाल देता है। यह ट्रंकेशन पते के उच्च बिट्स को खो देता है, जिसके परिणामस्वरूप जब मैंने इसे अपने 64-बिट एक्सप्लॉइट में डीरेफरेंस करने का प्रयास किया तो तत्काल एक्सेस उल्लंघन हुआ। इस समस्या को सफाई से बायपास करने के लिए, मैंने बस अपने उपयोगकर्ता-मोड PoC को 32-बिट एप्लिकेशन के रूप में संकलित किया, जिससे यह सुनिश्चित हुआ कि लौटाया गया पॉइंटर पूरी तरह से वैध बना रहे।

![IDA MapViewofSection - Copy](https://assets.kitploit.com/production/public/readmes/13419/573d472717b7c7ba50c1ed927135a97b1717d06142c40df212ff43793817dd1a.png)

**नोट:** अपने प्रारंभिक परीक्षण के दौरान, मुझे एक दिलचस्प किनारे का मामला मिला: मेरा PoC मेमोरी में मेरी एक्सप्लॉइट प्रक्रिया को सफलतापूर्वक ढूंढने में सक्षम था, लेकिन यह `System` प्रक्रिया (`PID 4`) को खोजने में विफल रहा।

कारण समझने के लिए, मुझे सीधे भौतिक मेमोरी का निरीक्षण करने की आवश्यकता थी। मैंने एक कर्नेल डीबगर (WinDbg) संलग्न किया और `System` प्रक्रिया का वर्चुअल पता और डायरेक्टरी बेस प्राप्त करने के लिए कमांड का उपयोग किया। फिर मैंने उस वर्चुअल पते को RAM में उसके सटीक भौतिक पते में अनुवाद करने के लिए `!vtop` का उपयोग किया।

![windbg kernel debbuger system physical address](https://assets.kitploit.com/production/public/readmes/13419/b211425816115a3f2e30b7e6f3d7cc2df589ce783f3daea99cd848f590b1a182.png) ![windbg kernel debbuger db system address](https://assets.kitploit.com/production/public/readmes/13419/9e7d5fb1a2374a7370e9f898dd8d675bf0bf79447086961fa5a1fd398d21e855.png)

मैं अपने PoC से जुड़े अपने उपयोगकर्ता-मोड डीबगर पर वापस आ गया। मैंने अपने मेमोरी स्कैनिंग लूप पर एक सशर्त ब्रेकपॉइंट सेट किया, इसे उस समय निष्पादन को रोकने का निर्देश दिया जब मेरा `MapPhysicalMemory()` फ़ंक्शन `System` प्रक्रिया के भौतिक पते वाले 2MB चंक को पकड़ ले।

![windbg breakpoint](https://assets.kitploit.com/production/public/readmes/13419/4b7d52faa64d673e9732e37f50ee72bfefe4f7538fb7311cdd61c2f4b13c2cb1.png)

एक बार ब्रेकपॉइंट हिट होने के बाद, मैंने मैप की गई मेमोरी के कच्चे बाइट्स का मैन्युअल रूप से निरीक्षण करना शुरू किया। यहीं पर मैंने विंडोज कर्नेल पूल आवंटन के बारे में एक महत्वपूर्ण विवरण खोजा।

![windbg eprocessBase offset 88000](https://assets.kitploit.com/production/public/readmes/13419/8552f0f15014e97e9764fec9312b1b185a1b3ccea7074a3684a458feebfc8103.png)

जब विंडोज किसी प्रक्रिया के लिए मेमोरी आवंटित करता है, तो यह एक `_POOL_HEADER` (जिसमें हमारा `Proc` टैग होता है) से शुरू होता है, उसके बाद एक `_OBJECT_HEADER`, और अंत में `EPROCESS` संरचना ही होती है। मानक उपयोगकर्ता-मोड अनुप्रयोगों के लिए, इन हेडर में अतिरिक्त ट्रैकिंग डेटा होता है, जिसका अर्थ है कि वास्तविक `EPROCESS` संरचना पूल टैग के `0x80` बाइट बाद शुरू होती है।

![offest for use mode process](https://assets.kitploit.com/production/public/readmes/13419/d39f332e951239aa292b259c1cca46add554fa7f24af8033b708024885475591.png)

हालांकि, `System` प्रक्रिया की मेमोरी का निरीक्षण करने पर एक अलग लेआउट का पता चला। `System` प्रक्रिया में इनमें से कुछ मानक ट्रैकिंग हेडर का अभाव है। `Proc` टैग से `EPROCESS` संरचना की शुरुआत का ऑफसेट केवल `0x40` बाइट था!

![windbg db 88000 offset](https://assets.kitploit.com/production/public/readmes/13419/38caadd58c8fbb2279f05acb6f17197de31dd258a7628518695dabbcf6253726.png) ![windbg db 88000 - 0x40 offset](https://assets.kitploit.com/production/public/readmes/13419/b28e7884ae1b877d5c863f7393c113946f910d32e5b98fb480331236f100f74a.png) ![offset for system process](https://assets.kitploit.com/production/public/readmes/13419/107c97d2f506856a2d8e06fd44cec15955b3dc0c80ea3ade92a1320f349b39b6.png)

समाधान सीधा था। मैंने अपने PoC को दोनों पूल हेडर आकारों को संभालने के लिए अपडेट किया, जब भी उसे `Proc` टैग मिलता है तो संभावित ऑफसेट (`0x40` और `0x80`) की एक सरणी के माध्यम से लूप करके।

![posibileoffset](https://assets.kitploit.com/production/public/readmes/13419/8287e37adf6fc1e100ace1ab1c04693099fab9b718b9ffc19608683ebf7baaaa.png)

* * *

### शमन और पहचान

साइबर सुरक्षा हमलावरों और रक्षकों के बीच बिल्ली-चूहे का एक अंतहीन खेल है। जहां हमलावर लगातार कमजोर ड्राइवरों की तलाश करते हैं, वहीं आधुनिक सुरक्षा उत्पादों और ब्लू टीमों के पास इस सटीक ऑपरेशन का पता लगाने और इसे ब्लॉक करने के कई मजबूत तरीके हैं।

BYOVD (अपना स्वयं का कमजोर ड्राइवर लाएं) हमले को रोकने का सबसे प्रभावी तरीका ड्राइवर को पहले स्थान पर लोड होने से रोकना है।

  * रक्षकों को सुनिश्चित करना चाहिए कि pstrip64.sys का हैश उनकी ब्लॉकलिस्ट में जोड़ा गया है।
  * इसके अलावा, संगठनों को विंडोज डिफेंडर एप्लिकेशन कंट्रोल (WDAC) के माध्यम से माइक्रोसॉफ्ट की कमजोर ड्राइवर ब्लॉकलिस्ट को लागू करना चाहिए और यह सख्ती से सीमित करने के लिए हाइपरवाइजर-प्रोटेक्टेड कोड इंटीग्रिटी (HVCI) को सक्षम करना चाहिए कि कौन से कर्नेल घटक लोड किए जा सकते हैं।
  * नई सेवा निर्माण घटनाओं की निगरानी करें, अप्रत्याशित कर्नेल-मोड ड्राइवर स्थापनाओं की तलाश करें।



यदि ड्राइवर पहले से ही लोड है, तो सुरक्षा उत्पाद टोकन हेरफेर चरण के दौरान एक्सप्लॉइट का पता लगा सकते हैं।

  * प्रक्रिया टोकन में विसंगतियों के लिए उन्नत निगरानी। एक मानक उपयोगकर्ता-मोड प्रक्रिया का अपने प्रारंभिक प्राथमिक टोकन को बिना किसी वैध प्रमाणीकरण श्रृंखला के `NT AUTHORITY\SYSTEM` तक बढ़ाना एक बहुत बड़ा लाल झंडा है।
  * इसके अतिरिक्त, सुरक्षा टीमें यह पता लगाने के लिए नियम बना सकती हैं कि जब कोई कम या मध्यम-अखंडता प्रक्रिया एक उच्च विशेषाधिकार प्राप्त चाइल्ड प्रक्रिया (जैसे `cmd.exe`) उत्पन्न करती है, खासकर जब मूल प्रक्रिया को `SYSTEM` के रूप में चलाने का कोई कारण नहीं है।



* * *

### डेमो

![poc_demo](https://assets.kitploit.com/production/public/readmes/13419/3a7a34220034759a1465e105ca78c6a12df372c535acfdcc805fad34174ab837.gif)