تخيّل أن فريق Red Team ينفّذ تقريبًا نفس الأساليب ضد جهتين من قطاعات البنية التحتية الحرجة.

نفس نوع الهجوم، نفس العقلية الهجومية، ونفس الهدف تقريبًا.

لكن النتيجة كانت مختلفة بشكل حاد.

في الجهة الأولى، وصل المهاجمون إلى مستوى السيطرة على الـDomain، ووصلوا إلى أنظمة أعمال حساسة وموارد Cloud، ولم يلاحظ مركز العمليات الأمنية شيئًا تقريبًا.

أما في الجهة الثانية، فقد تم اكتشاف النشاط منذ بدايته وعزل الأجهزة المصابة خلال دقائق.

المثير هنا أن الفرق لم يكن في امتلاك منتج أمني سحري أو منصة أكثر تطورًا.

الفرق الحقيقي كان في الأشخاص، العمليات، الصلاحيات، وطريقة التعامل مع التنبيهات.

وهذه بالضبط هي الرسالة التي أرادت CISA توضيحها في تقريرها AA26-237A بعنوان:

A Tale of Two SOCs

#ما الذي فعلته CISA؟

نشرت وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية CISA نتائج عمليتي Red Team Assessment تم تنفيذهما بالتزامن ضد جهتين تعملان ضمن قطاعات البنية التحتية الحرجة.

الجهة الأولى، المشار إليها باسم Organization A، تعمل في قطاع Government Services and Facilities.

أما الجهة الثانية، Organization B، فتعمل في قطاع Water and Wastewater Systems.

في كلتا الحالتين، تمكن فريق الـRed Team من الوصول إلى مستوى اختراق كامل للـDomain، كما تمكن من الوصول إلى أنظمة أعمال حساسة وموارد Cloud.

لكن طريقة استجابة كل SOC كانت مختلفة جذريًا.

#Organization A: اختراق كامل وسط آلاف التنبيهات

بدأت السلسلة الهجومية من نقطة تبدو بسيطة جدًا.

عثر فريق الـRed Team على Web Application تحتوي على حسابات مدمجة ما زالت تستخدم Default Credentials.

هذا الخطأ منح الفريق موطئ قدم داخليًا، ثم استخدمه لإرسال رسائل Phishing من عنوان داخلي موثوق.

النتيجة كانت وصول الـRed Team إلى أربع Workstations.

ومن هنا بدأت مرحلة أخطر.

#من User عادي إلى السيطرة على الـDomain

استغل الفريق إعدادًا افتراضيًا في Active Directory يسمى:

MachineAccountQuota

الإعداد يسمح افتراضيًا لأي مستخدم Domain بإنشاء عدد من حسابات الأجهزة داخل الـDomain.

بالتوازي مع ذلك، كانت هناك مشكلة في أحد قوالب Active Directory Certificate Services (AD CS).

القالب كان Misconfigured بطريقة تسمح بتنفيذ سيناريو من فئة:

ESC1

وهو من أشهر سيناريوهات إساءة استخدام AD CS.

عمليًا، يمكن لمستخدم منخفض الصلاحيات طلب Certificate بخصائص تسمح له بانتحال هوية مستخدم آخر إذا كانت شروط القالب غير محكمة.

وعند دمج هذه الثغرة مع صلاحيات أخرى داخل بيئة Active Directory، يمكن أن تتحول نقطة وصول محدودة إلى سيطرة واسعة على الـDomain.

#لماذا AD CS خطير عندما تتم إدارته بشكل سيئ؟

الكثير من البيئات تتعامل مع AD CS على أنه مجرد مكوّن لتوزيع Certificates.

لكن في بيئات Enterprise، الـCertificates يمكن أن تصبح وسيلة Authentication قوية للغاية.

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

ولهذا تعتبر أخطاء تصميم الـCertificate Templates خطرة جدًا.

المشكلة ليست فقط في وجود خدمة AD CS، بل في كيفية تكوين:

  • Certificate Templates
  • Enrollment Permissions
  • Subject Alternative Name
  • Extended Key Usage
  • Authentication EKUs
  • صلاحيات الحسابات التي يسمح لها بطلب Certificates

#الوصول إلى Sensitive Business Systems

بعد الوصول إلى صلاحيات أعلى، لم يحتج فريق الـRed Team إلى استغلال ثغرات معقدة للوصول إلى بعض الأنظمة الحساسة.

كانت Credentials موجودة أصلًا داخل الأنظمة.

بعضها كان مخزنًا بصيغة Cleartext.

من بين البيانات التي تمكن الفريق من الوصول إليها:

  • Credentials خاصة بخدمات وقواعد بيانات.
  • Database Configuration Files تحتوي على بيانات اعتماد قابلة للاستخدام.
  • Static AWS Access Keys.
  • مفاتيح Cloud مضبوطة بحيث لا تنتهي صلاحيتها.

وهذه نقطة مهمة جدًا.

في كثير من الحوادث، لا يحتاج المهاجم إلى اختراق نظام التشفير نفسه.

يكفي أن يعثر على Credentials مخزنة في Configuration File أو Script أو Shared Folder أو Deployment Package.

#Static AWS Keys لا تنتهي

أحد أخطر ما ظهر في Organization A كان وجود AWS Access Keys ثابتة ومضبوطة بحيث لا تنتهي.

المشكلة في المفاتيح طويلة العمر أنها تتحول إلى Credential دائم تقريبًا.

إذا تسرب المفتاح ولم تكن هناك آليات قوية للـRotation أو Revocation، فقد يستطيع المهاجم الاحتفاظ بالوصول لفترة طويلة دون الحاجة إلى إعادة اختراق المستخدم.

وهنا يظهر الفرق بين:

Long-Lived Credentials

و:

Short-Lived Tokens

الـShort-Lived Tokens تقلل نافذة الاستغلال، بينما المفاتيح الثابتة قد تبقى صالحة شهورًا أو سنوات إذا لم تتم إدارتها بشكل صحيح.

#الانتقال إلى Cloud وسرقة Primary Refresh Token

لم يتوقف الهجوم عند Active Directory التقليدي.

انتقل الفريق أيضًا إلى بيئة Cloud.

هناك تمكن من سرقة:

Primary Refresh Token (PRT)

الـPRT عنصر مهم في منظومة Authentication الخاصة بأجهزة Windows المرتبطة بـMicrosoft Entra ID.

وجوده قد يسمح للمهاجم بالحصول على Access Tokens لخدمات Microsoft المختلفة ضمن سياق المستخدم.

أي أن Credential Theft هنا لا يتعلق فقط باسم مستخدم وكلمة مرور.

في البيئات الحديثة، الـTokens نفسها أصبحت هدفًا رئيسيًا.

#Entra ID Applications بصلاحيات أكثر من اللازم

وجد الفريق أيضًا Applications في Microsoft Entra ID تمتلك صلاحيات مرتفعة.

هذه الصلاحيات كانت كافية لقراءة Email لعدد واسع من المستخدمين.

وهنا قام فريق الـRed Team بشيء ملفت.

استخدم هذه الصلاحيات لقراءة رسائل فريق الأمن نفسه.

الهدف لم يكن فقط الوصول إلى البريد.

الهدف كان معرفة ما إذا كان الـSOC قد لاحظ الهجوم.

بمعنى آخر، المهاجم لم يعد يراقب الأنظمة فقط.

بل أصبح يراقب المدافعين.

#والمفاجأة: Organization A لم تكتشف شيئًا

رغم كل ما حدث، لم تتمكن Organization A من اكتشاف النشاط بصورة فعالة.

السبب لم يكن غياب الـSecurity Tools.

بحسب CISA، كانت البيئة تولّد آلاف False Positive Alerts نتيجة العمليات الطبيعية للأعمال.

والأسوأ أن بعض هذه التنبيهات كانت مصنفة بدرجات Severity أعلى من التنبيهات التي أنشأها نشاط الـRed Team.

النتيجة كانت ما يعرف غالبًا باسم:

Alert Fatigue

عندما يرى المحلل مئات أو آلاف التنبيهات يوميًا، تصبح المشكلة ليست في نقص الرؤية، بل في وجود ضوضاء أكثر من قدرة الفريق على التحليل.

#أكثر من SOC، لكن بدون رؤية موحدة

الجهة كانت تدير عدة مراكز SOC وأدوات Endpoint Security مختلفة.

ظاهريًا، هذا قد يبدو كطبقات دفاع إضافية.

لكن لم تكن هناك Shared Visibility فعالة بينها.

بالتالي أصبحت البيانات الأمنية موزعة بين فرق وأدوات متعددة.

قد يشاهد فريق جزءًا من الهجوم، بينما يشاهد فريق آخر نشاطًا مختلفًا دون أن يتم الربط بين الحدثين.

وهنا يتحول تعدد الأدوات من ميزة إلى مشكلة تشغيلية.

وجود عشرة أنظمة Security لا يعني وجود رؤية موحدة.

#التنبيه الصحيح ظهر فعلًا، لكنه تم تجاهله

أحد أكثر أجزاء القصة أهمية أن Alert حقيقيًا مرتبطًا بنشاط الـRed Team ظهر على خادم System Center Configuration Manager (SCCM).

لكن تم التعامل معه على أنه False Positive.

السبب؟

المحللون لم يتمكنوا من تحديد مالك النظام.

عدم معرفة الـSystem Owner جعل التحقق من النشاط أصعب، وانتهى الأمر بإغلاق التنبيه.

وهذه حالة توضح أن الـAsset Management ليس مجرد متطلب إداري.

معرفة:

  • من يملك النظام؟
  • من المسؤول عنه؟
  • ما وظيفته؟
  • ما درجة أهميته؟
  • من يستطيع اتخاذ قرار عزله؟

قد تكون هي الفارق بين احتواء حادث وبين تجاهله.

#ما الذي مكّن الاختراق في Organization A؟

حددت CISA مجموعة من المشكلات الرئيسية التي ساعدت على نجاح الهجوم.

الضعفالتأثير الأمني
MachineAccountQuota بقي على القيمة الافتراضيةسمح لمستخدمي Domain بإنشاء Machine Accounts
Misconfigured AD CS Templateمكّن من استغلال سيناريو ESC1
Cleartext Credentialsسهّل الوصول إلى حسابات Service وDatabase
Static Cloud Keysمنح وصولًا طويل الأمد إلى Cloud
غياب Token Revocation فعالزاد من صعوبة إنهاء Sessions المسروقة
Over-Permissioned Entra Applicationsسمح بالوصول إلى Email على نطاق واسع
كثرة False Positivesأخفت التنبيهات ذات القيمة الحقيقية
غياب Shared Visibilityمنع الربط بين الأحداث عبر أدوات وفرق متعددة
ضعف Escalation Proceduresحدّ من قدرة Analysts على اتخاذ قرارات سريعة
غياب وضوح System Ownershipتسبب في تجاهل Alert حقيقي

Organization B: نفس الهجوم تقريبًا، لكن الـSOC كان مستعدًا

الجهة الثانية واجهت أسلوب هجوم مشابه.

لكن هذه المرة، الـSOC اكتشف Payloads الخاصة بالـPhishing أثناء تنفيذها.

الأجهزة المتأثرة تم عزلها خلال فترة تراوحت تقريبًا بين:

2 إلى 20 دقيقة

هذا العزل قطع قناة:

Command and Control (C2)

قبل أن يتمكن الـRed Team من التوسع داخل الشبكة بالطريقة الطبيعية.

وهنا يظهر الفرق بين Detection وحده وبين Detection يتبعه Response سريع.

التنبيه بدون استجابة لا يوقف المهاجم.

#التحول إلى Assume Breach

بما أن الـSOC قطع نقطة الوصول الأولية بسرعة، لم يتمكن فريق الـRed Team من متابعة السلسلة الهجومية من نفس الـFoothold.

لذلك نفذت CISA سيناريو:

Assume Breach

تم تشغيل Red Team Payload على جهاز محدد منخفض الصلاحيات بهدف محاكاة حالة افتراضية تفترض أن المهاجم حصل بالفعل على نقطة وصول داخلية.

الهدف هنا لم يعد اختبار بوابة الدخول فقط.

بل اختبار قدرة المؤسسة على مقاومة مهاجم موجود أصلًا داخل الشبكة.

#المفارقة: Organization B كانت تحتوي أيضًا على أخطاء خطيرة

رغم أن الـSOC كان أفضل بكثير في الكشف والاستجابة، فإن البيئة نفسها لم تكن مثالية.

وجد فريق الـRed Team Cleartext Credentials لحساب Domain Service داخل Configuration File خاص بـSCCM.

والأخطر أن هذا الحساب كان يمتلك صلاحيات مؤثرة على Domain Controller.

بعد ذلك تم استخدامه لتنفيذ:

DCSync

#ما هو DCSync؟

هجوم DCSync يستغل صلاحيات Active Directory Replication.

بدل أن يهاجم المهاجم قاعدة بيانات Active Directory مباشرة، يتصرف كما لو كان Domain Controller آخر ويطلب مزامنة بيانات الحسابات.

إذا امتلك الحساب الصلاحيات المطلوبة، يستطيع طلب Password Hashes وSecrets من الـDomain.

في هذه الحالة تمكن فريق CISA من الوصول إلى Secret الخاص بحساب:

krbtgt

وهذا الحساب من أهم الحسابات داخل بيئة Kerberos.

الـkrbtgt يستخدم لتوقيع وإدارة Ticket Granting Tickets (TGTs).

الحصول على Secret الخاص به قد يمكّن مهاجمًا في سيناريوهات هجومية معينة من إنشاء Kerberos Tickets مزيفة والمحافظة على Persistence على مستوى الـDomain.

#الوصول إلى Bastion Host داخل OT DMZ

وصل الفريق أيضًا إلى Bastion Host موجود داخل منطقة عزل مرتبطة ببيئة:

Operational Technology (OT)

وتحديدًا ضمن:

OT DMZ

لكن هنا واجه الفريق طبقة دفاع مهمة.

الخادم لم يكن يسمح بالاتصال الصادر إلى الإنترنت.

بالتالي لم يتمكن الـRed Team من إنشاء قناة C2 خارجية.

ولم ينتقل الهجوم إلى أنظمة OT نفسها.

هذه نقطة مهمة جدًا من ناحية Architecture.

حتى بعد حدوث اختراق، يمكن لضوابط Network Segmentation وEgress Filtering أن تحد من قدرة المهاجم على تحويل الوصول إلى سيطرة تشغيلية.

إذًا لماذا نجحت Organization B في الرصد بينما فشلت Organization A؟

بحسب CISA، الفارق لم يكن ببساطة في شراء أدوات أفضل.

الوكالة لخّصت الرسالة بوضوح:

Detection tools are only as effective as the people, processes, and procedures supporting them.

الـEDR يمكن أن يولّد Alert.

الـSIEM يمكن أن يجمع Logs.

الـSOAR يمكن أن ينفذ Workflow.

لكن إذا لم تكن هناك عملية Escalation واضحة، أو صلاحيات لاتخاذ القرار، أو Ownership معروف للأنظمة، أو Prioritization جيد للتنبيهات، فقد تتحول هذه الأدوات إلى مجرد مصدر إضافي للضوضاء.

من زاوية GRC: أين كانت المشكلة الحقيقية؟

من منظور Governance, Risk and Compliance (GRC)، الحادثة لا تتعلق فقط بأخطاء تقنية منفصلة.

هي تكشف عن ضعف في ربط التقنية بالحوكمة.

وجود Cleartext Credentials مثلًا ليس مجرد Misconfiguration.

هو مؤشر على ضعف في:

  • Credential Management
  • Secrets Management
  • Configuration Governance
  • Secure Baseline Enforcement

وجود Applications داخل Entra ID بصلاحيات مرتفعة ليس مجرد خطأ Identity.

هو أيضًا مؤشر على ضعف في:

  • Access Governance
  • Privileged Access Review
  • Application Permission Review
  • Least Privilege Enforcement

أما تجاهل Alert بسبب عدم معرفة مالك النظام، فهو يعكس مشكلة في:

  • Asset Ownership
  • Accountability
  • Incident Escalation
  • Operational Governance

الأمن ليس عدد الأدوات

من السهل تقييم نضج الأمن السيبراني بعدد التقنيات الموجودة.

عدد الـEDR Agents.

عدد الـSIEM Use Cases.

عدد الـSOC Teams.

عدد الـDashboards.

لكن هذه التجربة توضح أن النضج الحقيقي يظهر عند لحظة القرار.

هل يستطيع Analyst معرفة ما إذا كان النشاط خطيرًا؟

هل يعرف من يملك النظام؟

هل يملك صلاحية عزل الجهاز؟

هل يوجد Runbook واضح؟

هل يمكن الربط بين Alert في Endpoint وEvent في Identity وActivity في Cloud؟

هل يمكن التمييز بين High Severity Alert مزعج وLow Volume Alert يمثل فعليًا بداية Domain Compromise؟

هذه الأسئلة أهم من مجرد وجود المنتج الأمني نفسه.

الفرق بين Detection وSecurity Operations

Detection يعني أن النظام رأى شيئًا.

أما Security Operations فتعني أن المؤسسة فهمت ما رأته وتصرفت بناءً عليه.

Organization A كان لديها Tools وAlerts.

لكن الـOperational Model لم يحول تلك الإشارات إلى قرارات فعالة.

Organization B، رغم وجود ثغرات داخلية خطيرة لديها، تمكنت من كشف الـInitial Access وعزل الأنظمة بسرعة.

وهذا لم يمنع CISA من العثور على مشاكل عميقة لاحقًا.

لكنه أثبت أن قدرة المؤسسة على الاكتشاف والاستجابة تقلل مساحة الحركة المتاحة للمهاجم.

الدرس الأهم من "A Tale of Two SOCs"

القصة ليست عن SOC جيد وSOC سيئ فقط.

وليست عن منتج أمني نجح ومنتج آخر فشل.

القصة عن مؤسستين تعرضتا لأساليب هجومية متشابهة، لكن طريقة تشغيل الأمن داخلهما صنعت فارقًا واضحًا.

في واحدة، غرق التنبيه الحقيقي وسط آلاف التنبيهات.

وفي الأخرى، تحول التنبيه إلى استجابة خلال دقائق.

وفي الحالتين، كشفت CISA أن هناك ثغرات تقنية عميقة يمكن استغلالها داخل Active Directory وCloud وSCCM وIdentity Infrastructure.

وهنا تظهر الرسالة الأهم:

الأمن لا يفشل دائمًا لأن الأدوات لم ترَ الهجوم.

أحيانًا تكون الأدوات قد رأته بالفعل.

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

وهذا هو الفارق بين امتلاك Security Tools وامتلاك Security Capability حقيقية.