صيد التهديدات على الشبكة: لماذا تبدأ من حركة البيانات؟ (الجزء الأول)

لوحة الـ EDR خضراء، ومنصة الـ SIEM لا تُظهر أي تنبيه خطير، ثم يصلك اتصال من جهة خارجية: بياناتكم منشورة على موقع تسريبات، أو أحد عناوين الـ IP لديكم يتواصل مع بنية تحتية معروفة للمهاجمين. هذه الفجوة بين “لا يوجد تنبيه” و“نحن مخترَقون” هي المساحة التي يعمل فيها صيد التهديدات (Threat Hunting).

هذا هو الجزء الأول من سلسلة موجهة لمحللي مركز عمليات الأمن السيبراني (SOC) وفرق الاستجابة للحوادث، ويركز على العقلية والمنهجية قبل الدخول في التحليل التقني.

لماذا يبقى المهاجم أياماً دون أن يكتشفه أحد؟

لأن أدوات الحماية تكشف ما كُتبت له قواعد مسبقاً فقط. ووفق تقرير M-Trends 2026 من Mandiant:

• متوسط بقاء المهاجم داخل الشبكة قبل اكتشافه (Dwell Time) وصل إلى 14 يوماً عالمياً، بعد أن كان 11 يوماً.
• في حملات التجسس السيبراني ارتفع المتوسط إلى 122 يوماً.
• إحدى الحملات (BRICKSTORM) بقيت قرابة 400 يوم على أجهزة شبكية لا يعمل عليها أي EDR أصلاً.
• قرابة نصف الاختراقات (48%) اكتشفتها جهة من خارج المؤسسة الضحية.

ما هو صيد التهديدات (Threat Hunting)؟

صيد التهديدات (Threat Hunting) هو بحث استباقي يقوده الإنسان عن نشاط مهاجم لم تكتشفه أدوات الحماية الحالية. أنت لا تنتظر التنبيه، بل تنطلق من فرضية أن هناك من دخل فعلاً، ثم تبحث عن دليل يثبت ذلك أو ينفيه.

والنتيجة الصحيحة لعملية الصيد ليست “لم نجد شيئاً”، بل: “فحصنا هذه الأجهزة مقابل هذه السلوكيات، وهذا حكمنا على كل جهاز منها”. أي أن الصيد الجيد ينتهي بتقييم واضح لحالة كل جهاز ضمن النطاق.

ما الفرق بين صيد التهديدات والمراقبة والاستجابة للحوادث؟

الفرق في نقطة البداية:

• مراقبة مركز عمليات الأمن السيبراني (SOC): عمل تفاعلي آلي، قاعدة تُطلق تنبيهاً ومحلل يفرزه، ولا يكشف إلا ما كُتبت له قاعدة.
• الاستجابة للحوادث: تبدأ بعد التأكد من وجود حادثة، ونطاقها يحدده التنبيه أو البلاغ.
• صيد التهديدات (Threat Hunting): يبدأ بسؤال لا بتنبيه، ومخرجاته تغذي الطرفين؛ ما يتأكد منه يذهب لفريق الاستجابة، وما يتكرر يتحول إلى قاعدة كشف جديدة.

إذا كان “الصيد” لديك هو إعادة تشغيل استعلامات الأمس وإغلاق التذاكر، فهذه مراقبة وليست صيداً. وللتعرف أكثر على بنية الفريق راجع كيف تبني فريق SOC قوي.

لماذا نبدأ الصيد من الشبكة وليس من الجهاز؟

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

على الجهاز المصاب، المهاجم يلعب على أرضه: يستطيع تعطيل الـ EDR أو تعميته عبر تعريفات (Drivers) مصابة بثغرات، ومسح السجلات، والعمل من الذاكرة فقط، أو التمركز على جهاز لا يحمل أي وكيل حماية مثل جدار الحماية، أو بوابة الـ VPN، أو الطابعة، أو متحكمات الـ OT. السجلات على جهاز مخترَق هي أدلة يتحكم بها المهاجم نفسه.

أما على الشبكة فالمهاجم مضطر للتواصل كي يستفيد من اختراقه:

• يحتاج قناة قيادة وتحكم (C2) لإرسال الأوامر واستلام النتائج.
• يحتاج للتنقل الجانبي (Lateral Movement) للوصول إلى البيانات أو متحكم النطاق.
• يحتاج غالباً لإخراج البيانات (Data Exfiltration).

الحساس الموضوع على منفذ SPAN أو جهاز TAP يسجل هذا الأثر بشكل مستقل عن الجهاز المصاب. قد يشفّر المهاجم المحتوى، لكنه لا يستطيع بسهولة إخفاء أن الاتصال حدث، ومدته، وتكراره، وحجم البيانات المنقولة، والنطاق الذي تم الاستعلام عنه أولاً.

لماذا لا نبدأ من سجلات Syslog؟

لأنها لم تُصمم كمصدر أمني، وصيغها تختلف من مصنّع لآخر، وتحليلها ينتهي غالباً إلى مطابقة بصمات كما كان يعمل مضاد الفيروسات قديماً. أما بيانات الشبكة الوصفية فموحدة: لكل اتصال مصدر ووجهة ومنفذ وبروتوكول ومدة وحجم، أياً كان النظام أو التطبيق.

من أين يبدأ الصائد عملياً؟

ابدأ بأقوى مؤشر على الاختراق: الاتصال الصادر المستمر. فالبرمجية الخبيثة تحافظ على تواصلها مع المشغّل بإحدى طريقتين:

1. الاتصالات الطويلة (Long Connections): جلسة واحدة مفتوحة لساعات أو أيام تُمرَّر عبرها الأوامر.
2. الاتصالات المتكررة (Beacons): جلسات قصيرة على فترات منتظمة، تكفي فقط للسؤال “هل لديك مهام لي؟” ثم تنقطع.

في الحالتين النمط مستمر، والاستمرارية يمكن قياسها من بيانات الاتصال وحدها. وعليها تُبنى منهجية من خمس خطوات:

1. تحديد قنوات الاتصال المستمرة الخارجة من الشبكة.
2. تحليل البروتوكول المستخدم.
3. تقييم الجهاز الداخلي الذي يولّد الاتصال.
4. فحص سمعة الوجهة.
5. إصدار الحكم: إضافة الاتصال إلى قائمة السماح (Allow-list) كاتصال سليم، أو تصعيده لفريق الاستجابة.

ما هي طرق بدء عملية الصيد؟

هناك أربع طرق رئيسية، والصيد الجيد يمزج بينها:

الطريقة	نقطة البداية	مثال على الشبكة
المبنية على فرضية (Hypothesis-driven)	جملة قابلة للاختبار	جلسات TLS منتظمة من شبكة السيرفرات نحو وجهة لا يتصل بها أي سيرفر آخر
المبنية على استخبارات التهديدات (Intelligence-driven)	تقرير خارجي أو نشرة CERT	حملة تستخدم سجلات DNS TXT ونطاقات مسجلة خلال الأسبوع الأخير
المبنية على الخط المرجعي (Baseline-driven)	معرفة السلوك الطبيعي	جهاز يتصل بدولة جديدة، أو سيرفر رفع فجأة 20 GB
المدعومة بالنماذج (Model-assisted)	تقييم إحصائي للسلوك	ترتيب الاتصالات حسب احتمال أن تكون Beacons كما تفعل أداة RITA

تقرير استخباراتي يعطيك الفرضية، والخط المرجعي يحدد غير الطبيعي، والنموذج يرتّب المرشحين للتحقيق.

ويقسّم إطار PEAK من Splunk أي عملية صيد إلى ثلاث مراحل: التحضير (اختيار الموضوع والتأكد من توفر البيانات)، ثم التنفيذ (التحليل والتنقل بين الأدلة)، ثم التصرف (التوثيق، وأتمتة الكشف، وإبلاغ المعنيين).

لماذا يرفع صيد الشبكة مستوى نضج فريقك بسرعة؟

لأن تحليلاته بسيطة وقابلة للأتمتة. يقسّم نموذج نضج الصيد (Hunting Maturity Model) لـ David Bianco الفرق من المستوى HMM0 (الاعتماد على التنبيهات الآلية فقط) إلى HMM4 (تحويل معظم عمليات الصيد الناجحة إلى قواعد كشف آلية). أغلب الفرق تقف بين HMM1 and HMM2: تجمع البيانات وتبحث عن مؤشرات الاختراق (IOCs)، لكنها نادراً ما تبني تحليلات جديدة.

صيد الشبكة يعتمد على المدة والتكرار والحجم والندرة، وهي مقاييس سهلة الصياغة والأتمتة.

ويكمل الصورة هرم الألم (Pyramid of Pain) لنفس الباحث: حظر IP أو Hash لا يكلّف المهاجم شيئاً تقريباً، أما كشف سلوكه، كتوقيت الاتصالات المتكررة أو أنماط النطاقات الفرعية في هجمات DNS Tunneling، فيقع في قمة الهرم ويكلّفه كثيراً. تبديل البنية التحتية لا يُخفي السلوك.

ما هي مصادر البيانات التي يحتاجها الصائد؟

تحتاج إلى حركة البيانات، وإلى السياق الذي يربط عنوان الـ IP بجهاز ومستخدم وعملية:

• الالتقاط الكامل للحزم (PCAP) عبر tcpdump أو Arkime: أعلى دقة وتتيح استخراج الملفات وإعادة بناء البروتوكولات، لكنها ثقيلة على التخزين وتُحفظ لأيام فقط، فهي للتحقق العميق لا للبحث في أشهر من البيانات.
• سجلات Zeek: تحوّل الحزم إلى سجلات منظمة مثل conn.log, dns.log, http.log, ssl.log, x509.log and files.log، وحجمها نحو 1–2% من حجم الـ PCAP، فيمكن الاحتفاظ بها لأشهر.
• بيانات التدفق مثل NetFlow, IPFIX and VPC Flow Logs: رخيصة ومتوفرة، لكنها بلا طبقة تطبيقات وغالباً مأخوذة بالعينة، فهي ممتازة لتحليل الحجم والندرة والحركة الداخلية ومحدودة في تحليل الاتصالات المتكررة وDNS.
• سجلات جدار الحماية والـ Proxy: مفيدة لتحليل الاتصالات الصادرة والروابط والـ User-Agent، وجودتها تختلف حسب المصنّع.
• سجلات DNS: أساسية لكشف C2 عبر DNS، وخوارزميات توليد النطاقات (DGA)، والنطاقات حديثة التسجيل.
• سياق الهوية والأصول: سجلات DHCP وجلسات VPN والمصادقة وقوائم الأصول. بدونها يبقى العنوان 10.1.4.37 مجرد رقم.
• بيانات الأجهزة الطرفية: أحداث الشبكة في الـ EDR أو Sysmon Event ID 3 تربط الاتصال بالعملية التي أنشأته، وهي وجهتك التالية بعد أن يكشف صيد الشبكة شيئاً.

أين تضع حساس الشبكة؟

موضع الحساس أهم من الأداة، وأفضل التحليلات تفشل إذا كان الحساس في المكان الخطأ:

1. التقط من داخل جدار الحماية الخارجي قبل عملية NAT، وإلا ستظهر كل الاتصالات وكأنها صادرة من العنوان العام للجدار وتفقد الجهاز الداخلي الحقيقي.
2. التقط قبل أن يمرر سيرفر DNS الداخلي الاستعلامات، أو فعّل السجلات عليه مباشرة، وإلا ستظهر كل الاستعلامات قادمة منه.
3. لا تهمل الحركة الداخلية (East-West). الحساس على الحدود يرى الـ C2 وإخراج البيانات، لكنه لا يرى التنقل الجانبي. منافذ SPAN على المبدل الرئيسي أو TAP افتراضي في البيئات الافتراضية والسحابية تسد هذه الفجوة.
4. تأكد من مدى رؤيتك قبل البدء: هل يرى الحساس كل مخارج الإنترنت، بما فيها شبكة الضيوف، وروابط الـ OT، والمخارج السحابية، والفروع التي تتصل بالإنترنت مباشرة؟

ويرتبط ذلك مباشرة بطريقة تقسيم الشبكة، وهو ما شرحناه في تصميم الشبكات الآمنة: كيف تقسم شبكة المؤسسة إلى مناطق؟.

ما هي حدود صيد الشبكة؟

صيد الشبكة قوي لكنه ليس سحراً، وهذه أبرز نقاط ضعفه:

• التشفير: بروتوكولات TLS 1.3, ECH and DoH تخفي المحتوى، وبشكل متزايد أسماء الوجهات أيضاً. ستعتمد أكثر على البيانات الوصفية: التوقيت، والحجم، والشهادات، وبصمات مثل JA4+.
• الحجم: البحث المفتوح في تيرابايتات من البيانات يُغرق المحللين، لذلك حدد نطاق كل عملية صيد.
• غموض الهوية: تغيّر عناوين DHCP، والـ NAT، والـ Proxy المشتركة، وعناوين السحابة المتبدلة تصعّب ربط النشاط بجهاز محدد.
• الضجيج: برامج التحديث، ووكلاء القياس، وتطبيقات المحادثة، وأدوات المراقبة كلها ترسل اتصالات متكررة. توقّع نتائج إيجابية خاطئة، وابنِ قائمة السماح تدريجياً.

ماذا يجب أن تنتج عملية الصيد؟

الصيد الذي “لم يجد شيئاً” ناجح طالما أنتج مخرجات واضحة:

1. حكم على كل جهاز ضمن النطاق: سليم، أو مشبوه يحتاج بيانات إضافية، أو مخترَق وتم تصعيده.
2. قائمة سماح محدّثة بالاتصالات الطويلة والمتكررة السليمة مع سبب عملي لكل منها.
3. قواعد كشف جديدة أو محسّنة لكل ما يمكن أتمتته.
4. قائمة بالفجوات في الرؤية: سجلات ناقصة أو أجزاء من الشبكة غير مراقبة.
5. توثيق للنطاق والبيانات والاستعلامات والنتائج كي يمكن تكرار العملية.

وقِس برنامج الصيد بهذه المخرجات: سرعة الوصول إلى الحكم، وعدد قواعد الكشف الجديدة، والفجوات التي أُغلقت، لا بعدد عمليات الصيد المنفذة.

ماذا في الجزء الثاني؟

ننتقل إلى التطبيق: كشف الاتصالات الطويلة والاتصالات المتكررة (Beacons) في سجل conn.log من Zeek، وكشف هجمات DNS Tunneling عبر عدّ النطاقات الفرعية الفريدة، وملاحقة النشاط الشاذ (Anomalies) في الأحجام والـ User-Agent والشهادات، ثم تقييم كل نتيجة للوصول إلى حكم قابل للدفاع عنه.

كيف تتعلم هذه المهارات عملياً؟

صيد التهديدات وتحليل حركة البيانات من أهم مهارات الفريق الأزرق. إذا أردت أن تتعلمها عملياً، انضم إلينا في معسكر الأمن السيبراني – الدفعة العاشرة، المعسكر الاحترافي الأقوى على مستوى الوطن العربي في مجال الأمن السيبراني.

سجّل الآن في معسكر الأمن السيبراني – الدفعة العاشرة