OSINT 101: 7 أشياء يكتشفها مهاجم عن شركتكم في 30 دقيقة

OSINT 101: 7 أشياء يكتشفها مهاجم عن شركتكم في 30 دقيقة

هناك سبب يجعل OSINT (الاستخبارات مفتوحة المصدر) أرخص أداة في صندوق العتاد الهجومي. فهي ليست جديدة، وليست خفيّة، ولا تتطلب أي وصول. كل ما تتطلبه هو أن يعرف المراقب أين ينظر. وهذه الحقيقة نفسها تجعل العمل الدفاعي بـ OSINT رخيصاً من جانبنا. والغرض من هذا المقال أن نقدّم لكم، دون تزويق، الأشياء السبعة التي نُظهرها عادةً عن شركة أوروبية متوسطة في أول ثلاثين دقيقة من الفرز الأولي بـ OSINT. لا يتطلب أيٌّ منها أداة مدفوعة. وكلها يمكن أن تتحول إلى نقلة افتتاحية في هجوم حقيقي.

نرتبها حسب التواتر. أولها يظهر دائماً تقريباً. وآخرها يظهر في نحو ثُلث الحالات، وعندما يظهر فإنه غالباً يغيّر مجرى الحديث مع العميل.

1 · خريطة شبه كاملة للكادر الوظيفي (10 دقائق)

نبدأ من LinkedIn. لا نحتاج إلى اتصال بأحد. فالبحث المجاني المُصفّى حسب الشركة والموقع والوظيفة الحالية يمنحنا، في الشركة الأوروبية المتوسطة النموذجية التي تضم من 80 إلى 400 موظف، ما بين 50% و80% من الكادر. نقرأ المسميات الوظيفية، وأصحاب العمل السابقين، واللغات، وكثيراً ما نقرأ الحزمة التقنية المُعلَنة في قسم المهارات.

ماذا يفعل المهاجم بذلك: قائمة أهداف للتصيّد الموجَّه (spear phishing) بذرائع مكيَّفة حسب الدور. لقد رأينا رسائل مكتوبة بالمسمّى الداخلي الدقيق وبالمشروع الذي أعلنه المُستلِم قبل أسبوعين على LinkedIn. ومعدل فتح تلك الرسائل لا يلعب في الدوري نفسه الذي يلعب فيه تصيّد عام.

ماذا يمكنكم فعله حيال ذلك: اطلبوا من فريقكم إبقاء صاحب العمل محدَّثاً، لكن أن يكونوا أكثر تروّياً عند الإعلان عن المشاريع والأدوات الداخلية. وجلسة قصيرة لنظافة LinkedIn للكوادر العليا هي من أرخص الانتصارات في مجال التوعية.

2 · الحزمة التقنية من إعلانات التوظيف (3 دقائق)

الوظائف الشاغرة منجم لـ OSINT. فوظيفة backend تطلب "PostgreSQL 14 وKafka وVault وTerraform على AWS eu-west-1" تخبر المهاجم بمحرك قاعدة البيانات، وناقل الرسائل، ومدير الأسرار، ومنطقة النشر، وأداة التنسيق. ووظيفة في عمليات الأمن تطلب "Splunk Cloud وCrowdStrike Falcon وTines لأتمتة الأمن (SOAR)" تخبره بنظام إدارة الأحداث الأمنية (SIEM)، وحماية النقاط الطرفية (EDR)، ومنصة التنسيق.

ماذا يفعل المهاجم بذلك: يتخطى مرحلة الاكتشاف. فالاستطلاع يدخل مباشرةً للبحث عن ثغرات CVE معروفة للإصدارات المُسمّاة.

ماذا يمكنكم فعله حيال ذلك: لا تتوقفوا عن نشر الوظائف. احذفوا أرقام الإصدارات. تحدثوا بالقدرات ("SIEM حديث"، "EDR مُدار") بدلاً من أسماء المورِّدين كلما سمحت الوظيفة بذلك. واستعينوا بوسيط توظيف للوظائف الشديدة التخصص.

3 · بنية البريد التحتية ووضع DMARC لديها (دقيقتان)

ثلاثة استعلامات DNS تمنحنا سجلات MX وSPF وDMARC لأي نطاق مؤسسي. وفي الشركة الأوروبية المتوسطة النموذجية، ما زلنا نجد أن أكثر من نصفها بلا DMARC، أو على p=none، أو على p=quarantine دون pct=100. وتلك الشركات نفسها عادةً ما يكون لديها SPF بـ ~all بدلاً من -all، ومن ثلاثة إلى خمسة نطاقات IP قديمة مُصرَّح بها لا يستطيع أحد في الفريق الحالي شرحها.

ماذا يفعل المهاجم بذلك: يسجّل نطاقاً مشابهاً، أو ببساطة ينتحل النطاق الشرعي، تبعاً لوضع DMARC. وقد كان انتحال المرسِلين الشرعيين هو متجه الدخول لعدة حالات اختراق البريد التجاري (BEC) شديدة الأثر التي رأيناها في 2025.

ماذا يمكنكم فعله حيال ذلك: انقلوا DMARC إلى p=reject وSPF إلى -all بجدول زمني موثَّق. ولدينا مقال منفصل عن نسخة الـ 24 ساعة من هذا العمل.

4 · المحيط العام كما تراه Shodan وCensys (5 دقائق)

نبحث عن اسم الشركة ورقم النظام الذاتي (ASN) الخاص بها. وفي شركة نموذجية نجد: ما بين ثلاث واثنتي عشرة خدمة مكشوفة على الإنترنت لم يتوقع أحد أن تكون مكشوفة. أكثرها تواتراً: مُجمّعات شبكة افتراضية خاصة (VPN) موروثة تُركت "للطوارئ"، وواجهات إدارة بُعدية لمعدات الشبكة (Mikrotik وCisco SMB وUbiquiti)، وحاويات تخزين S3 منسية مُعلَّمة كعامة من أجل اختبار سريع، وبوّابات داخلية على :8443 ظُن أنها مخفية لعدم الارتباط بها، وواجهة IPMI لخادم كان ينبغي سحبه من الخدمة في 2022.

ماذا يفعل المهاجم بذلك: يبدأ بسبر الخدمات المكتشفة بحثاً عن ثغرات معروفة. وفي شركة متوسطة، قِسنا الزمن بين الظهور العام على Shodan وأول سبر موجَّه بأقل من 24 ساعة.

ماذا يمكنكم فعله حيال ذلك: روتين لإدارة سطح الهجوم الخارجي، ولو كان فصلياً ويدوياً، يزيل 80% من هذه الفئة. والاستثمار هو يوما عمل لمحلِّل كل فصل لشركة متوسطة نموذجية.

5 · مستودعات الشيفرة والأسرار التي يسرّبها الناس فيها (4 دقائق)

عمليات البحث في GitHub من نوع org:<empresa> و"@empresa.com" path:.env تكشف أكثر مما ينبغي. أكثر الاكتشافات شيوعاً: مستودع اختبار منسي يحتوي على سلسلة اتصال حقيقية بقاعدة بيانات، وحساب GitHub الشخصي لموظف سابق يحتوي على ملف إعداد فيه مفتاح API لم تُدوِّره الشركة قط، وملف gist عام يحتوي على رابط webhook لا يزال يعمل.

ماذا يفعل المهاجم بذلك: يجرّب بيانات الاعتماد. ونحو واحدة من كل ثلاث بيانات اعتماد نُظهرها في هذه الفئة لا تزال صالحة أول مرة نجربها مع العميل أثناء التشخيص.

ماذا يمكنكم فعله حيال ذلك: فعّلوا فحص الأسرار في GitHub (secret scanning) على مستوى المؤسسة، وأجروا مسحاً للتزامات (commits) التاريخية في المستودعات الخاصة، وفعّلوا تدوير المفاتيح تشغيلياً عند مغادرة موظف. لا شيء من هذا يتطلب شراء منتج جديد في معظم الشركات المتوسطة.

6 · سلسلة التوريد التي لم ترسموها في أي مخطَّط (4 دقائق)

ننظر إلى JavaScript المُحمَّل في موقعكم العام، والنطاقات الفرعية لـ SaaS التي تُحلَّل تحت نطاقكم (status.، support.، helpdesk.، learn.، tracking.)، وسجلات شفافية الشهادات (certificate transparency)، وبصمات favicon للبوّابات الداخلية. وفي شركة أوروبية متوسطة نموذجية، نحدد ما بين 15 و40 طرفاً ثالثاً يلمسون بياناتكم أو عملاءكم أو سطح علامتكم التجارية، منهم 5 إلى 10 لا يردون عادةً في قائمة المشتريات.

ماذا يفعل المهاجم بذلك: يختار الطرف الثالث الأضعف كنقطة ارتكاز (pivote). ولم يكن نمط الاختراقات عبر طرف ثالث من 2023 إلى 2025 مصادفة؛ بل كان أسهل طريق ضد شركات صلّبت محيطها الخاص.

ماذا يمكنكم فعله حيال ذلك: جرد للأطراف الثالثة مدفوع بـ OSINT، يُحدَّث فصلياً، ويُقابَل بقائمة المشتريات الرسمية. الفروقات (deltas) هي العمل.

7 · الهشاشة التي لا يتحدث عنها أحد: الاعتماد على شخص واحد (دقيقتان)

هذا هو اكتشاف OSINT الذي يتفاعل معه العملاء بأقوى ما يكون. فبدمج LinkedIn، والمحاضرات العامة، ومساهمات GitHub، والمنشورات التقنية، وتاريخ WHOIS، كثيراً ما نحدد أن شخصاً واحداً بعينه هو الوجه العام الوحيد لمجال تقني بأكمله. وإذا كان ذلك الشخص غير متاح لمدة 72 ساعة، فإن عدة أنظمة يصونها لا تملك خلَفاً موثَّقاً.

ماذا يفعل المهاجم بذلك: يحوّل ذلك الشخص إلى هدف تصيّد موجَّه عالي القيمة. وفي حالة عامة موثَّقة جيداً (ليست عميلاً لنا)، تسبّب التصيّد الناجح لمهندس موثوقية مواقع (SRE) واحد في سقوط منصة SaaS 48 ساعة لأن لا عضو آخر في الفريق كان يملك بيانات اعتماد الاستعادة.

ماذا يمكنكم فعله حيال ذلك: مراجعة داخلية لـ "عامل الحافلة" (factor-bus). ليس هذا تمريناً للأمن السيبراني بالمعنى الدقيق؛ بل تمرين استمرارية بعواقب سيبرانية.

كيف تستخدمون هذه القائمة داخل شركتكم

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

الغرض من تمرين OSINT الدفاعي ليس الانبهار بما يستطيع مراقب خارجي رؤيته. الغرض هو تحويل الاكتشافات إلى قائمة معالجة بمسؤولين وتواريخ. والاكتشافات بلا مسؤول هي ضجيج.

> "لم نقدّم قط تقرير OSINT دفاعي لشركة متوسطة وجدنا فيها صفر تعرّض ذي صلة. لكننا قدّمنا عدة تقارير كان أغلى اكتشاف فيها داخلياً: مجال حرج يصونه شخص واحد لم يطلب منه أحد أن يكون له بديل." — مراجعة داخلية لتدقيقات OSINT في IBL، 2025-2026

ماذا نفعل في IBL

مهمتنا في OSINT الدفاعي تمرين ثابت من خمسة أيام. والمُسلَّم تقرير مكتوب، موقَّع ومؤرَّخ، باكتشافات مرتَّبة حسب صعوبة المعالجة وشدة التعرّض. ولا نُدرج أي بيانات لم نحصل عليها من مصادر عامة. وندرج الرابط (URL) وتاريخ كل اكتشاف ليتمكن فريقكم من إعادة إنتاجه.

إذا أردتم الحديث عن بصمتكم تحديداً، فاكتبوا إلى [email protected]. نرد خلال يوم عمل.

---

OCIRIA شركة استشارية متخصصة (boutique) في الأمن السيبراني، مقرها في مالقة وفريقها التشغيلي في رومانيا. نعمل مع شركات أوروبية متوسطة تفضّل الصدق التقني على التغليف التجاري. تأسسنا في 2026؛ لا نختلق تاريخاً أطول.

قراءات ذات صلة

• تدقيق OSINT: ماذا نُسلِّم وكم يستغرق فعلاً (cluster pillar Q4)
• شرح DMARC: لماذا بريدكم عرضة للخطر وكيف تصلحونه في 24 ساعة (cluster pillar Q3)
• سلسلة توريد OSINT: ماذا يحدث عندما لا يرقّع مورِّدكم الحرج منذ 2024 (cluster Q4)

الوسوم: osint, exposición, perímetro, cadena-suministro, seguridad-correo, empresa-mediana, informe-campo