octoberfest7/dns_tunnelingأداة أنفاق DNS باستخدام PowerShell وNslookup لاستخراج البيانات وتوصيل الأحمال عبر سجلات DNS TXT/MX، متجاوزة وضع اللغة المقيدة (Constrained Language Mode) ودفاعات نقاط النهاية.
مستلهمًا من العمل الذي قمت به مؤخرًا والذي تضمن إشارات DNS الخاصة بـ Cobalt Strike، بالإضافة إلى بيان مهمة لمحاولة تجاوز Microsoft Defender for Endpoint، أمضيت بعض الوقت في البحث في كيفية استخدام DNS لنقل حمولة إلى جهاز مستهدف. كما أردت تحدي نفسي بمحاولة القيام بذلك بطريقة ممكنة حتى عند تشغيل PowerShell في وضع Constrained Language Mode. كان هذا البحث موجهًا نحو إصدارات Windows الأحدث (أي Win10+، Server 2019+) ولكن كما سترى لاحقًا قد يكون ممكنًا في إصدارات أقل.
DNS tunneling هي تقنية موجودة منذ فترة طويلة ويستخدمها مجموعة متنوعة من المهاجمين. على المستوى الأساسي، تتضمن استخدام بروتوكول DNS كوسيلة لتسرب البيانات أو كقناة اتصال C2. هناك العديد من منشورات المدونات التي يمكنك الرجوع إليها لمزيد من المعلومات حول هذا الموضوع.
نظرًا لأن هذه تقنية قديمة ومعروفة، فإن العديد من المؤسسات لديها طرق كشف لمنعها.
نوع سجل DNS المفضل لتقنية DNS tunneling تاريخيًا هو TXT. وذلك لأن سجلات TXT يمكنها تخزين بيانات أكثر من السجلات الأخرى كما أنها حساسة لحالة الأحرف، وهو شيء لا تفعله السجلات الأخرى مما قد يؤثر عندما نبدأ الحديث عن الترميز.
Constrained Language Mode (CLM) هو وضع لغة مقيد لـ PowerShell يقلل بشكل كبير من القدرات والوظائف المسموح بها لـ PowerShell. بشكل مختصر، فإن .NET، وكائنات COM، والأدوات المفضلة للمهاجمين مثل (new-object net.webclient).downloadstring... غير متاحة. هذا الرابط يوفر مزيدًا من المعلومات. ستقوم المؤسسات بفرض هذه السياسة للمستخدمين العاديين كجزء من قواعد تقليل سطح الهجوم. وهذا في الواقع يجعل حياتنا أصعب كمهاجمين.
يجب أن يكون معظم الأشخاص على الأقل على دراية سطحية بـ DNS من استخدام أدوات مثل Nslookup. ولكن على المستوى الأساسي، يرسل العميل استعلامًا ويعيد خادم DNS إجابة على ذلك الاستعلام. هناك عدة أنواع مختلفة من سجلات DNS: CNAME، A، AAAA، TXT، MX، وNS على سبيل المثال لا الحصر. يمكن لكل من هذه السجلات تخزين وإرجاع معلومات مختلفة. يتم تكوين هذه السجلات في ملف Zonefile، يتم تقديمه بواسطة خادم DNS.
يظهر مثال على ملف zonefile هنا:``` $ORIGIN example.com. @ 3600 SOA ns1.p30.dynect.net. ( zone-admin.dyndns.com. ; address of responsible party 2016072701 ; serial number 3600 ; refresh period 600 ; retry period 604800 ; expire time 1800 ) ; minimum ttl 86400 NS ns1.p30.dynect.net. 86400 NS ns2.p30.dynect.net. 86400 NS ns3.p30.dynect.net. 86400 NS ns4.p30.dynect.net. 3600 MX 10 mail.example.com. 3600 MX 20 vpn.example.com. 3600 MX 30 mail.example.com. 60 A 204.13.248.106 3600 TXT "v=spf1 includespf.dynect.net ~all" mail 14400 A 204.13.248.106 vpn 60 A 216.146.45.240 webapp 60 A 216.146.46.10 webapp 60 A 216.146.46.11 www 43200 CNAME example.com.
إذا قام شخص ما بالاستعلام عن سجلات NS الخاصة بـ example.com، فسيعيد الاستعلام ns1.p30.dynect.net و ns2.p30.dynect.net و ns3.p30.dynect.net و ns4.p30.dynect.net.
# البحث
## تسجيل اسم النطاق
قبل أن نبدأ، يجب أن نتحدث بإيجاز عن إعداد سجلات DNS للإشارة إلى عنوان IP نتحكم به وسنشغل خادم DNS عليه. كما هو موضح أدناه، اشتريت نطاقًا وقمت بإعداد سجلات DNS تشير إلى النطاق الفرعي "dns" في النطاق الفرعي "ns1" الذي تم تعيين عنوان IP العام للخادم له.
هذا يعني أن أي استعلامات تُجرى لـ "dns.edu....com" سيتم توجيهها إلى "ns1.edu....com" الذي تم تعيين عنوان IP 3..86 له. على عنوان IP هذا سنقوم بإعداد خادم DNS لخدمة سجلاتنا. سنعود إلى هذا لاحقًا.
## البحث عن أداة من جانب العميل
بدأت رحلتي ببحث بسيط في جوجل عن "powershell dns module" والذي أعاد [هذا](https://docs.microsoft.com/en-us/powershell/module/dnsclient/?view=windowsserver2022-ps) الرابط. كان الأمر Resolve-DnsName ذا أهمية خاصة. يبدو أنه بشكل أساسي تطبيق PowerShell للثنائي المعروف Nslookup.exe. لاحظ أنه يمكن طلب أنواع محددة من السجلات:
حسنًا، لدينا وحدة PowerShell قادرة على إجراء استعلامات DNS واسترجاع الإجابة. هل تعمل في وضع اللغة المقيدة (Constrained Language Mode)؟ الإجابة هي نوعًا ما.
كما ترى هنا، إذا فتحت نافذة PowerShell جديدة، وقمت بتشغيل Resolve-DnsName، ووضعت PowerShell في وضع CLM (واختبرت باستدعاء ::WriteLine البسيط)، ثم قمت بتشغيل Resolve-DnsName مرة أخرى، فإنه يعمل دون مشكلة:
ومع ذلك، إذا فتحت نافذة PowerShell جديدة ووضعتها فورًا في CLM ثم حاولت تشغيل Resolve-DnsName، فإنها تفشل:
يبدو أنه إذا تم تحميل وحدة مسبقًا، فإنها تكون قادرة على العمل بعد تطبيق CLM، لكن CLM سيمنع تحميلها إذا لم تكن قد حملت بالفعل. وبالنظر إلى بيئة مستهدفة حيث يتم تطبيق CLM للمستخدمين افتراضيًا (وبدون معرفة ما إذا كانت هناك وحدات معينة محملة مسبقًا أو إذا كان DnsClient واحدًا منها)، اخترت في هذه المرحلة ترك Resolve-DnsName والعودة إلى Nslookup.exe القديم الجيد.
Nslookup.exe هو عنصر أساسي في مجموعة أدوات تكنولوجيا المعلومات وثنائي معروف جدًا يستخدم لأغراض مشروعة. الاحتمالات في صالحنا أنه سيُسمح بتنفيذه حتى في البيئات التي تشكل فيها القائمة البيضاء للتطبيقات مصدر قلق.
سيعيد Nslookup نفس المعلومات تقريبًا مثل استعلام Resolve-DnsName الخاص بنا، وسنضطر فقط إلى التلاعب بها بشكل مختلف قليلاً عندما يحين الوقت.
## تحويل ملف تنفيذي إلى سجلات DNS؟
حسنًا، لدينا وسيلة لإجراء استعلامات DNS على جهاز الضحية. كيف يمكننا توفير الحمولة بتنسيق يمكن لـ Nslookup استرجاعه؟
الملفات التنفيذية هي بالطبع ملفات ثنائية مما يعني أنها غير قابلة للقراءة البشرية. نتيجة لذلك، يجب تحويل البيانات إلى شيء يمكننا وضعه في سجلات DNS ويمكن لأداة مثل Nslookup استرداده. هناك خيارات تشفير عديدة متاحة لنا، لكن الاعتبار الرئيسي هو ما الذي يمكن لجهاز الضحية فك تشفيره باستخدام أدوات Windows الأصلية والإمكانيات المتاحة في CLM فقط؟ Base64 هو الإجابة الواضحة والمتوصل إليها غالبًا.
باستخدام Base64، نحول ملفنا التنفيذي إلى سلسلة نصية كبيرة قابلة للقراءة البشرية يمكن بعد ذلك تقسيمها إلى العديد من سجلات DNS واستعادتها باستخدام Nslookup. على جانب العميل، يمكن استخدام الأداة المعروفة certutil.exe من LOLBAS لفك تشفير Base64 لسجلات DNS المجمعة إلى تنسيق ثنائي.
هذا يتطلب منا التحدث قليلاً عن أنواع سجلات DNS. كل نوع سجل يخزن معلومات معينة بتنسيق معين. على سبيل المثال، تخزن سجلات A وتعيد عنوان IPV4 (111.111.111.111). سجلات AAAA تعيد عنوان IPV6، وسجلات MX و NS تعيد أسماء النطاقات، وسجلات TXT يمكنها إعادة سلاسل نصية بطول 255 حرفًا. كما ذكر سابقًا، نظرًا لطول السجل وحساسية حالة الأحرف، كانت سجلات TXT هي الخيار الواضح للمهاجمين حيث ستكون هناك حاجة لعدد أقل منها وهي متوافقة مع تشفير مثل Base64.
دعنا نرى كيف يبدو هذا.
على جهاز Kali VM الخاص بنا، يمكننا أخذ ملفنا التنفيذي وتشفيره بـ Base64. لاحظ استخدام المفتاح -w 0 الذي سيزيل جميع الأسطر الجديدة بحيث يتبقى لدينا سطر واحد من نص Base64:
النظر إلى الملف يظهر Base64: