$query = "SELECT username FROM login WHERE username=?"; $stmt = $conn->prepare($query); $stmt->execute(array($username)); $username = $stmt->fetchColumn(); if($username == FALSE) { die(" !"); } 

1. دورة حياة طويلة جدًا. سنة كاملة هي الكثير. إذا تم اختطاف ملف تعريف الارتباط بنجاح ، فإن الوصول الطويل إلى حساب المستخدم من قبل المهاجم ممكن.
2. إشارة httpOnly مفقودة. إذا تم التعيين على TRUE ، فلن يمكن الوصول إلى ملفات تعريف الارتباط إلا من خلال بروتوكول HTTP. أي أن ملفات تعريف الارتباط في هذه الحالة لن تكون متاحة للغات البرمجة النصية مثل JavaScript.
3. لا تجزئة ملف تعريف الارتباط.
4. عدم وضع العلم الآمن. تشير العلامة الآمنة إلى ضرورة إرسال ملف تعريف ارتباط من العميل عبر اتصال HTTPS آمن. في حالة التعيين على TRUE ، سيتم إرسال ملف تعريف الارتباط من العميل إلى الخادم فقط إذا تم تأسيس اتصال آمن.

 $query = htmlentities($query, ENT_QUOTES, "UTF-8"); 

 header("Content-Type: text/html; charset=utf-8"); 

  $query = "SELECT sessions FROM login WHERE sessions=?"; $stmt = $conn->prepare($query); $stmt->execute(array($_COOKIE["user"])); $session = $stmt->fetchColumn(); if($session == TRUE) { do_login($_COOKIE["user"]); } 

السؤال الأول الذي التقى به الاستبيان مع المتدربين في المستقبل يتعلق بنقاط الضعف الرئيسية والمعروفة على نطاق واسع. الصعوبة الوحيدة هنا هي الحاجة إلى رؤيتهم في الكود المصدري في PHP. ومع ذلك ، لا أحد تعيين مهمة "إخفاء الأخطاء".

فيما يلي قائمة بالثغرات الأمنية التي يمكن اكتشافها في هذه القائمة بترتيب تكرار اكتشافها:

تمت ملاحظة تجزئة كلمة المرور باستخدام خوارزمية MD5 حتى من قبل المرشحين بعيدًا عن الويب. ومع ذلك ، كانت هناك أيضا فروق دقيقة مثيرة للاهتمام ، على سبيل المثال ، استخدم العديد من المرشحين مصطلحات غير صحيحة للغاية ، في محاولة لوصف المشاكل في كلماتهم. تضمنت المعركة "نقاط ضعف الخوارزمية" ، و "الوظائف أحادية الاتجاه" ، و "وجود تصادمات" وغيرها من المنعطفات الغريبة ، عند فحصها عن كثب ، تبين أنها ليست سوى مجموعة من الكلمات الكبيرة التي لا تكشف عن الجوهر. بالطبع ، ذهبنا هنا إلى اجتماع ولم نجد خطأً مع أولئك الأشخاص الذين يستعدون للتو للشروع في طريق تعلم حكمة أمن المعلومات. للحصول على "مقاصة" ، سيكون ذكر التهديد كافيًا ، في حالة تعرض قاعدة البيانات للخطر ، يمكن فرز علامات التجزئة md5 بواسطة مهاجم في وقت مقبول ويمكن الحصول على كلمات المرور (أو سلاسل مكافئة) بنص واضح. وبطبيعة الحال ، ذكر الكثيرون قلة الملح والقوة الغاشمة القائمة على استخدام طاولات قوس قزح. لقد أدركنا أيضًا هذه التعليقات بشكل إيجابي ، خاصةً إذا شرح المجيب سبب هذا التهديد.

حقن SQL المحتملة. من الصعب إضافة شيء ما ؛ عند إجراء مكالمة إلى قاعدة البيانات ، يتم إدخال إدخال المستخدم لتسجيل الدخول وكلمة المرور مباشرة مع الطلب. إذا كان من غير المحتمل أن تتمكن من معالجة قيمة كلمة المرور في هذه المرحلة (يتم أخذ علامة تجزئة منها) ، فلن يكون إدخال حقنة في اسم المستخدم أمرًا صعبًا بالنسبة للمهاجمين المحتملين.

إخراج معلومات التصحيح غير الضرورية التي تؤدي إلى هجوم XSS. من خلال قراءة القائمة بعناية ، يمكن للمرء الانتباه إلى مكالمة الصدى ، والتي تعرض الطلب الذي تم إنشاؤه على قاعدة البيانات في تعليقات HTML على الصفحة. بطبيعة الحال ، فإن مثل هذا الاستنتاج من المعلومات الإضافية إلى الصفحة اختياري تمامًا ، وعلى الأرجح ، ينسى المطور ببساطة بعد إجراء الاختبارات. هذه المعلومات الإضافية مفيدة جدًا للمهاجم وتسمح بفهم أفضل لكيفية عمل التطبيق. ومع ذلك ، لسوء الحظ ، هذه ليست سوى نصف المتاعب. الحقيقة هي أن المهاجم يمكنه معالجة محتويات متغير الاستعلام ، ولا يمكن تصفية محتوياته أو الهروب منها قبل عرضها للمستخدم - هناك هجوم XSS محتمل. ومع ذلك ، قد يتحول هذا الاستغلال إلى صداع بسبب ضعف وظيفة strtoupper. سيكون الموجه الذي تم حقنه بواسطة المهاجم كبيرًا ، وإذا لم تكن هذه مشكلة بالنسبة لعلامات HTML ، فسيتأثر Javascript بشدة بهذا الاستئناف. يمكن التحقق من ذلك بسهولة باستخدام وحدة تحكم المستعرض.



حسنًا ، على الأقل ، على ما يبدو ، سيتعين على المهاجم أن يتحول إلى ما يسمى "الهجمات غير النصية" أو التقنيات المعقدة لتجاوز التصفية (في هذه الحالة ، سوف يقوم JSFUCK بذلك) ، وبالتالي فإن خطر المخاطرة الأمنية لا يلغي هذا.

كان خطأ في منطق آلية إدارة الجلسة الجزء الأكثر إثارة للاهتمام من المهمة. لا يتطلب اكتشافه قراءة سطر المصدر بسطر فحسب ، بل أيضًا لفهم منطق القائمة بأكملها. يمكن للمرء أن يشعر بأن هناك خطأ ما من خلال ملاحظة إعداد ملف تعريف الارتباط الذي يحتوي على معرف المستخدم المشفر base64 في كتلة تذكرني. يقودنا المزيد من التحليل المنطقي لهذه الآلية إلى التفكير: "اتضح أن المهاجم الذي يعرف أو يمر عبر هوية يمكن أن يسجل الدخول إلى أي حساب دون إدخال اسم مستخدم وكلمة مرور؟!". نعم ، في الواقع ، يمكن للمهاجم إنشاء مستخدم ملف تعريف ارتباط بشكل مستقل من جانبه وتعيين أي قيمة معرف مشفرة بواسطة base64. إن إرسال طلب بملف تعريف الارتباط هذا دون اسم مستخدم وكلمة مرور من شأنه أن يؤدي إلى تشغيل وظيفة do_login وتسجيل الدخول إلى حساب شخص آخر.

أثرت نقاط الضعف الأربعة هذه في استجابة المرشحين بشكل مباشر على نتائجهم.

ومع ذلك ، يعتمد الكثير على نوعية الاستجابة. ذكر طرق تصحيح الموقف والملاحظات حول العوامل الإضافية التي تؤثر على جدوى الهجوم ، واستخدام المصطلحات الصحيحة والقدرة على هيكلة أفكارك ، والتعليقات على نقاط الضعف الإضافية أو التهديدات المحتملة - كل هذا استحوذ على قلوبنا وأدى إلى زيادة التصنيف النهائي.

في عمل المراجع غالباً ما يتوجب عليه التعامل مع التقنيات الجديدة ، والقدرة على فهمها مهمة للغاية. بما في ذلك هذا السؤال في الاستبيان ، افترضنا أن معظم المرشحين بالكاد سمعوا عن تقنية الرموز JWT باستثناء الاسم. لذلك ، كان هذا السؤال ، أولاً وقبل كل شيء ، يهدف إلى القدرة على البحث وتحليل المعلومات من المصادر العامة. ونتيجة لذلك ، يمكن لأي شخص فاتته إصدار Google بناء على طلب "JWT" ​​و "jwt الضعف" أن يتوصل إلى الاستنتاجات التالية:

1. لا يحتوي هذا الرمز المميز على خوارزمية توقيع ، لذلك يمكن للمهاجم تعديل أي حقول داخل الرمز المميز ، وهو ما لا يفترض بمفهوم الرموز المميزة لـ JWT.

2. تحتوي الحقول الموجودة داخل الرمز المميز على كلمة مرور المستخدم بنص واضح ؛ ويعد تخزين هذه المعلومات في الرمز المميز ممارسة سيئة على الأقل. في معظم الحالات ، يمكنك رفض مثل هذا القرار وبالتالي زيادة مستوى الأمان لديك.

3. تذكر عدم وجود توقيع وقدرتنا على تعديل الحقول داخل الرمز المميز ، فمن المنطقي افتراض أن تغيير قيمة isAdmin يمكن أن يزيد من امتيازاتنا لامتيازات المسؤول.

4. هناك فكرة أخرى مثيرة للاهتمام مفادها أن قلة من الأشخاص المذكورين في إجابتهم تتعلق بحقيقة القدرة على نقل مدخلات المستخدم في حقول رمز JWT. في الحالة العادية ، لا يمكن للمهاجم التأثير على البيانات الموجودة في الرمز المميز بأي طريقة ، مما يعني أنه يمكن للمطورين في كثير من الأحيان إهمال إدخال اختبارات إضافية في رمز المعالجين. هذا يطرح الفكرة البسيطة: ولكن دعونا نحاول شن هجمات كلاسيكية ليس من خلال معلمات GET / POST ، ولكن من خلال الحقول الرمزية. هذا يمكن أن يعطي نتيجة جيدة بشكل غير متوقع. مثل هذا النهج الإبداعي مع التبرير الصحيح لأعمالنا كان موضع تقدير كبير من قبلنا في تقييم كل من هذه وغيرها من القضايا.

رتب العديد من المرشحين في إجاباتهم رواية موجزة حول كيفية تنظيم الرمز المميز JWT وحيث يتم استخدامه ، كان من الممتع بالنسبة لنا أن نقرأ ، وقبل كل شيء ، قمنا بتقييم جوانب الإجابة المتعلقة بالأمان.

 <ifmodule mod_headers.c> Header always set Access-Control-Allow-Origin: "https://whitelist.domain.ru" Header always set Access-Control-Allow-Methods "PUT" </ifmodule> 

 <?php header('Access-Control-Allow-Origin: “https://whitelist.domain.ru”); header('Access-Control-Allow-Methods: PUT'); ?> 

دعنا نفكر ، بالترتيب ، ما هي المشاكل الرئيسية الظاهرة في الاستعلامات المقدمة:

1) في الواقع ، بما أن المعرف العددي للمستخدم "10012" قد لوحظ في الطلب ، فإن الخطوة الأولى هي التحقق مما إذا كان من الممكن تغيير كلمة المرور لمستخدم آخر؟ يمكن أن يكون كافيا لتحديد هوية شخص آخر ؟
نقاط الضعف في فئة IDOR سهلة الاستغلال إلى حد كبير وغالبًا ما تكون ذات خطورة عالية.

2) يحدث طلب تغيير كلمة المرور بواسطة طريقة POST ، ولا يتم ملاحظة الرمز المميز CSRF ، ونوع المحتوى هو "نص / عادي". هناك إمكانية تزوير مثل هذا الطلب.

وبالتالي ، من أجل تغيير كلمة مرور الضحية ، يكفي المهاجم أن يقنعهم بزيارة الرابط "الضار".

3) في رؤوس الاستجابة ، يكشف الخادم عن إصدار البرنامج المستخدم . يمكن أن يطلق على ذلك ثغرة أمنية كاملة ، ولكن من الأفضل إخفاء مثل هذه الشعارات - يمكن للمهاجمين العثور بسهولة على عمليات الاستغلال المعروفة ليوم واحد عليها ، بالإضافة إلى أن قيمة البرنامج المستخدم تُسهل إلى حد كبير التخطيط لمزيد من الهجمات.

4) سنكون سعداء للغاية لرؤية الجملة "ماذا سيحدث إذا قمنا بتغيير تنسيق البيانات من JSON إلى XML ؟"

والحقيقة هي أن الأطر الحديثة هي ذكية ، النهمة ، ويمكن معالجة البيانات في أشكال مختلفة. وعند تحليل XML ، غالبًا ما يُسمح بوجود ثغرة أمنية خطيرة في XXE. من خلال مساعدته ، يمكن للمتطفل "الانتقال" إلى الشبكة الداخلية ، ويمكن قراءة ملفات التكوين من الخادم ، وتنفيذ RCE من حين لآخر.

5) أردت أيضًا رؤية ملاحظة مثل "لماذا لا يتم التحقق من معرفة القديم عند تغيير كلمة المرور؟"

بالنسبة إلى "المتغير رقم 2" ، يوجد "فخ" فيه - يتم استخدام رؤوس CORS هنا ، وتم بالفعل تعيين نوع محتوى الطلب على "application / json".

الخطأ في أن الغالبية العظمى من المرشحين قدمت هو الجواب من النموذج "- وهذا هو النجمة في السماح المنشأ ، مما يعني أنه يمكنك إرسال طلبات من أي موقع!"

لا ، لا يمكنك ذلك. أولاً ، "بيانات اعتماد السماح": العنوان الحقيقي مفقود ، مما يعني أن المتصفح يجب أن ينفذ الطلب "مع ملفات تعريف الارتباط" ، لذلك سيكون الطلب مجهول الهوية ، بدون جلسة. وثانياً ، حتى لو كان مثل هذا الرأس موجودًا ، فإن المتصفح لا يزال يحظر إرسال ملفات تعريف الارتباط - فقط بسبب "العلامة النجمية". مزيجهم محظور ، ويتم تجاهل المتصفح.

كان الهدف من السؤال هو تحديد مدى معرفة المتدرب بالتقنيات الحديثة (وليس كذلك) للقيام بهجمات MitM. دعونا نلقي نظرة على السيناريوهات المحتملة بناءً على تفريغ حركة مرور موجود:

1) خداع ARP
ARP-spoofing هي الطريقة الأقدم والأسهل لتنفيذ هجمات MitM. تتكون من إرسال طلب ARP غير مبرر إلى المضيف A.

عنوان IP للمضيف B هو عنوان IP ، وعنوان MAC الخاص بنا هو عنوان MAC. يسمح لك هذا الطلب بتعديل جدول ARP على المضيف A ، مما يجبره على إرسال طلبات إلى الجهاز لدينا عند محاولة الوصول إلى المضيف B. المضيف B عادة ما يكون العبارة الافتراضية.

أدوات الموصى بها: bettercap ، arpspoof

2) LLMNR ، خداع NBNS
يعد تحليل اسم البث المتعدد للرابط المحلي وخدمة اسم NetBIOS بمثابة البروتوكولات المستخدمة لحل أسماء المضيفين على الشبكة المحلية. بخلاف بروتوكول DNS ، لا يوجد خادم مخصص يقوم بتخزين جميع المعلومات ؛ وبدلاً من ذلك ، يتم بث الطلب إلى جميع المضيفين على الشبكة ، إذا كان اسم المضيف في الطلب يطابق اسم المضيف للجهاز ، فسوف يرسل ردًا.

كما تمت الإشارة بشكل صحيح في الإجابة ، يمكن للمهاجم الاستجابة لمثل هذه الطلبات عن طريق إرسال عنوان IP الخاص به في الرد ، مما سيؤدي إلى حقيقة أن الضحية ستتصل في المستقبل بجهاز المهاجم ، بدلاً من الجهاز الذي ظهر اسم المضيف الخاص به في الطلب. بالإضافة إلى ذلك ، يمكن للمهاجم طلب مصادقة NTLM من الضحية ، مما يتسبب في إرسال الجهاز الضار تجزئة NTLM ، والتي يمكن استخدامها مرة أخرى للقوة الغاشمة.

أدوات الموصى بها: المستجيب

3) WPAD خداع
يمكن أن يعزى خداع WPAD إلى حالة خاصة من خداع LLMNR و NBNS. يتم استخدام بروتوكول Web Proxy Auto Discovery لتكوين خادم وكيل HTTP تلقائيًا.

يرسل الجهاز طلب LLMNR / NBNS مع اسم مضيف wpad ، ويتلقى عنوان IP المقابل ، ويحاول الوصول إلى ملف wpad.dat عبر HTTP ، الذي يخزن معلومات حول إعدادات الخادم الوكيل.

كنتيجة لذلك ، يمكن للمهاجم القيام بالتحايل على LLMNR / NBNS وتزويد الضحية بملف wpad.dat الخاص به ، ونتيجة لذلك ، فإن كل حركة مرور HTTP و HTTPS سوف تمر عبر المهاجم.

أدوات الموصى بها: المستجيب ، mitm6

4) راوتر الإعلان
كما ترون من التفريغ ، هناك أجهزة مع تمكين IPv6 على الشبكة. أثناء تواجدك على الشبكة ، يمكنك محاولة إرسال رسائل إلى إعلان IPv6 Router الضحية من أجل تغيير العبّارة الافتراضية أو خادم DNS.

تعد رسائل إعلان الموجه (RA) جزءًا من آلية SLAAC (التكوين التلقائي لعناوين العنوان) ، وهي ضرورية للحصول على عناوين IPv6 تلقائيًا على شبكة ، دون استخدام خادم DHCPv6 ، أو بالتزامن معها. يتم تحقيق ذلك عن طريق إرسال رسائل RA للإرسال المتعدد إلى جهاز التوجيه بشكل دوري ، والتي تحتوي على عنوان العبّارة الافتراضية وبادئة الشبكة وعنوان خادم DNS وبادئة المجال.

أدوات الموصى بها: الحزمة الخام

5) خداع DHCP
أيضًا ، في التفريغ ، يتم تكرار طلبات اكتشاف DHCP من نفس الجهاز في بعض الفواصل الزمنية. يمكنك استخلاص استنتاجات حول عدم وجود خادم DHCP في هذه الشبكة والرد على طلب Discover التالي عن طريق تحديد الضحية كبوابة افتراضية للجهاز.

أدوات الموصى بها: Yersinia

6) خداع HSRP
بالإضافة إلى ذلك ، يمكن رؤية حزم HSRP في التفريغ. يمكن أن يعمل بروتوكول توجيه الاستعداد السريع على زيادة توفر أجهزة التوجيه التي تعمل بمثابة العبارة الافتراضية. IP-, -. Hello - , . HSRP, , , HSRP .

: Yersinia

7) STP-
Spanning Tree Protocol L2- . BPDU-, , . BPDU-, , , , , , , , STP, , .

: Yersinia

, . nginx , web-, nginx web- /. nginx , , , .

, , , . , . , , .

gixy .

Gixy 4 :

1) Alias travesal:

80 :

 location /static { alias /prod_static/; } 

- , . : //host/static../etc/passwd. - alias: , /static, /prod_static/, : /prod_static/../etc/passwd, /etc/passwd. alias traversal

2) Http Splitting (CRLF injection)
nginx , , . HTTP-.
: github.com/yandex/gixy/blob/master/docs/ru/plugins/httpsplitting.md

3) -
75 «rigin» . , - , , production.host.evil.com .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/origins.md

4) add_header
nginx : add_header, , , , . CSP .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/addheaderredefinition.md

---

, gixy, . :

1) 17 default_type text/html. : , , nginx Content-Type, default_type. , Content-Type: text/html. HTML- , , , XSS- .

2) POST-
29-30 , . , “” POST-. . ولكن! SSRF , , , , .

3) php-fpm
48 , FastCGI- unix , 9000. , , . , PHP-.

4) “” CSP
production.host Content-Security-Policy, Javascript, .

5) “” CORS
76-77 CORS, , cookie .

6) , 86 . secured /managed.

7) , , , -. , , , /user/{userid} IDOR.

, , , .

, :

• ACL
• capabilities

, , :
“ , root” .

, Linux/Unix .
, “ ” — .
, , funky_test.txt

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

, Linux/Unix :

• - — “rwx” alice
• — “rw” interns
• — “rx” others

read, write, execute .

, — , :

• , read
• , read
• read

, read . , execute .

, .

, , . :

1. , ls.

2. — POSIX Access Control Lists .

c .

1

, alice interns . funny_test.txt :

 $ whoami alice $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied $ 

2

— funky_test.txt 604. bob , interns :

 $ whoami bob $ id uid=1002(bob) gid=1003(bob) groups=1003(bob),1002(interns) $ ls -la funky_test.txt -rw----r-- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied 

alice , . , permission_denied :

 $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ chmod 777 funky_test.txt $ ls -la funky_test.txt -rwxrwxrwx 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt secret_pass 

bob .

, « », :

• ID effective UID —
• GID effective GID —
• others.

, — , “” , , , :

• , , others
• , , others

.

POSIX Access Control Lists

— /. , ACL, , “ + ”

POSIX ACLs, — , . ACL, .

مثال

. alice funky_test.txt ,

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

ACL. getfacl , , ACL, , ls .

 $ getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx group::rw- other::rx 

, ACL . , bob :

 setfacl -mu:bob:rwx funky_test.txt 

“ + ”

 ls -l funky_test.txt -rwxrwxr-x+ 1 alice interns 12  4 13:00 funky_test.txt 

:

 getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx user:bob:rwx group::rw- mask::rwx other::rx 

ACL . :

1. . effective UID effective GID — . , ACL, . , , , , , .
2. ACL mask , ACL owner, group, others

, , , — .

, ACL, , :

• ACL, ;
• , ACL, .

 1)User - 1 Account: IEUser Domain: WIN7 Host: WIN7 hex dump session key - 49 0c 38 3e f8 eb 63 88 79 0f 62 84 09 84 d2 dc 2) User - 2 Account: winwin Domain: WIN7 Host: WIN7 hex dump session key - 8d f6 1b 35 79 a3 78 d3 2e 81 09 f1 95 4f 71 0a 3) User - 3 Account: 192.192.192.29 Domain: WIN7 Host: WIN7 hex dump session key - c3 19 e0 21 1b e2 63 c6 03 9e e7 38 1b 56 f0 d1 

, , :

1. ( )
2. — /
3. ,

, :

Wireshark, Protocol Hierarchy Statistics Conversations .

Protocol Hierarchy Statistics — .



Conversations — , .





:

1. (60%) — TCP, , , SMB. Protocol hierarchy SMB 40%, TCP, , 20% SMB.
2. 192.192.192.128 192.192.192.129. SMB .

.

— SMB.

, — wireshark — ExportObject .
tcp stream . , , tcp stream , . , .

, , , , . , .

.
SMB .

NTLM- “ntlmssp”. info , 3 :



, .







Net-NTLMv2-, :

• challenge
• response

Net-NTLMv2 hashcat .

, WIN7\winwin WIN7\192.192.192.129 — , . WIN7\IEUser — , , , , , SMB.

Net-NTLM , , Wireshark. , PCredz (https://github.com/lgandx/PCredz)



IEUser ( ) hashcat.



, .

6, , SMB/NTLM , DNS .

, , NT LM NTLMv1 (Net-NTLMv1) , NTLMv2 (Net-NTLMv2) ( ).

- NT LM NTLM , NTLM NTLMv1 NTLMv2 . , . .

, NTLMv1/NTLMv2 — challenge-response . , .

NT LM — “ ” — .

:

• PassTheHash — , , . ولكن. , NT . PassTheHash NTLMv2 — . , “” , , .
• NTLM Relay — , , NTLM. , .
• Spoofing, Windows: LLMNR, NetBios
• : MS17-010, / , .

:

• ( )
• ,
• eternalBlue
• NTLM relay
• NTLM relay — SMB
• , (ARP-spoofing, DNS )

, , , Pivoting. , , , , , .

, ping , ARP- (arp -a), (route). , netcat (nc -h), , (nc -vnz 10.0.20.3 0-1000). , , , , , , - bash, python .

— SSH-, SOCKS- SSH, .
ssh -D 1337 user@10.0.20.5 -f -N

. nmap SOCKS- proxychains .

proxychains nmap 10.0.20.0/24
nmap 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

nmap - SOCKS-. SYN- ( nmap ) SOCKS-, SOCKS- TCP- , SYN- , SYN, SYN ACK. CONNECT- (-sT), nmap SOCKS-.

nmap -sT 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

, - , , . , Linux-, nmap -sT , , , , , , .

, MITM HTTPS .

, Proxy WiFi. ProxyDroid, iptables .

, Root , , ?

SSL-Pinning, , , “Frida+Objection”. , :)