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. एक प्रिमिटिव से दो चेन

चेन	गैजेट	प्रभाव	आउटपुट चैनल
OOB RCE	TypeConfuseDelegate → -EncodedCommand PowerShell	पूल पहचान के रूप में कोड निष्पादन	आउट-ऑफ-बैंड (HTTP/DNS बीकन)
मशीन-कुंजी प्रकटीकरण	ActivitySurrogateDisableTypeCheck → ActivitySurrogateSelectorFromFile (इन-प्रोक KeyDump.cs संकलित करता है)	ValidationKey/DecryptionKey डंप करता है	HTTP प्रतिक्रिया में इनलाइन

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/ में हैं।

इनवोकेशन	प्रोसेस ट्री (LAB\sp_pool के रूप में, High)	Defender	OOB बीकन	प्राथमिक आर्टिफैक्ट
OOB RCE, डिफ़ॉल्ट	w3wp.exe → cmd.exe → powershell.exe → conhost.exe	Behavior:Win32/WebshellLauncher.A (EID 1116 डिटेक्ट / 1117 Remove)	पहुँचा (रेस)	4688 ट्री; Defender 1116/1117; /_trust POST
OOB RCE, -RawCmd	w3wp.exe → powershell.exe → conhost.exe (कोई cmd नहीं)	कोई नहीं	पहुँचा (DNS+HTTP)	4688 ट्री; /_trust POST; बीकन
OOB RCE, -DropFile	w3wp.exe → powershell.exe	कोई नहीं	पहुँचा	…\TEMPLATE\LAYOUTS\ में फ़ाइल लेखन (ऑब्जेक्ट-एक्सेस-ऑडिटेड लॉग में नहीं)
OOB RCE, -Diag	w3wp.exe → powershell.exe → whoami.exe	कोई नहीं	पहुँचा	एनवायरनमेंट प्रकटीकरण एक्सफिल: {host, whoami, PSver, LanguageMode}
मशीन-कुंजी डंप	(कोई नहीं, इन-प्रोसेस)	कोई नहीं	(कोई नहीं)	केवल /_trust POST + कुंजियाँ ले जाने वाली असामान्य प्रतिक्रिया

ये परिणाम डिफ़ॉल्ट 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 पर आधारित डिटेक्शन इसे पूरी तरह से चूक जाती है।

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