رصد الويب المظلم واستخبارات التهديدات للمؤسسات: دليل عملي للتطبيق

شَهد الأمنُ السيبراني المؤسسي في تركيا تحوّلًا جوهريًا خلال السنوات الثلاث الأخيرة. لم تَعد الهجماتُ تُرصَد عند وصولها، بل قبل وصولها بساعات — تَتفاوض مجموعاتُ الفدية على مواقع التسريب لأسابيع قبل الإعلانات، يَبيع وسطاءُ الوصول الأوّلي وصولَ VPN، وتَتداول أسواقُ بيانات الاعتماد 50 مليون سجلَّ مستخدمٍ تركي. لم يَعد الدفاعُ التفاعلي كافيًا؛ صارت استخباراتُ التهديدات الاستباقية العمودَ الفقري للأمن المؤسسي. الالتزامُ بإخطار خرق KVKK خلال 72 ساعة، وشرطُ رصد التهديدات في لائحة نظم معلومات BDDK، ومتطلَّبُ TI في وثائق التأمين السيبراني — كلُّها تَجعل هذا التحوّل إلزاميًا.

في إطار خدماتنا استخبارات التهديدات وبحث OSINT وData Fusion أنشأنا أو شَغّلنا برامجَ رصد ويبٍ مظلم + TI لأربعة عشر عميلًا مؤسسيًا خلال الأربع والعشرين شهرًا الأخيرة — في قطاعات المالية والصحة والطاقة والتجارة الإلكترونية والقطاع العام. في هذا المقال نَستعرض بالترتيب سبع خطواتٍ عملية لبرنامج رصد ويبٍ مظلم + TI مؤسسي: تعريف النطاق، خريطةُ المصادر، معماريّةُ التجميع، تطبيعُ IoC وتقييمه، تدفّقُ الاستجابة لحالة التسريب، المعالجةُ المتوافقة مع KVKK، النضجُ المستمر.

1. تعريفُ النطاق — ما الذي نَرصده، وما الذي لا نَرصده

السؤالُ الأول ليس اختيار الأداة، بل ما الذي نَرصده؟. نطاقٌ خاطئ يُنتج إما تلوّثَ إشارة (5.000 تنبيه في الأسبوع، تَضيع التهديداتُ الحقيقية) أو بقعةً عمياء (تَعرف تسريبًا حرجًا بعد ستّة أشهر من الأخبار).

خمسةُ مجالات رصد رئيسة:

المجال	استعلامات المفتاح	أولويةُ المصدر
تسريبُ بيانات الاعتماد	نطاقُ المؤسسة + بريدُ الموظفين	قوائمُ Combo، Breach dumps، COMB v2/v3
إساءةُ علامة	اسمُ العلامة، اسمُ المنتج، الشعار، متغيّراتُ النطاق	أسواقُ phishing kit، نطاقات typo-squat
إعلانُ IAB	اسمُ المؤسسة، القطاع، "VPN access"، "domain admin"	Exploit.in، XSS، RAMP، BreachForums
تسريبُ الفدية	اسمُ المؤسسة، أسماءُ العملاء/الموردين	مواقعُ تسريب LockBit، Cl0p، BlackBasta، ALPHV
تسريبُ كودٍ مصدري/IP	عنوانُ المستودع، GitHub org، أسماءُ host داخلية	مواقعُ paste، تسريباتُ GitHub، رفعٌ في منتديات الويب المظلم

مجالاتٌ ثانوية (توسّع): أسماءُ التنفيذيين (doxxing CEO/CTO)، قوائمُ العملاء، معلوماتُ الموردين، التوثيقُ الداخلي، تسريبُ API key/cert.

انضباطُ الكلمات المفتاحية: مصطلحٌ عام كـeCloud يُنتج آلافًا من الإيجابيات الكاذبة؛ المصطلحاتُ الخاصّة بالمؤسسة كـeCloud Tech وe-cloud.web.tr و*@e-cloud.web.tr* تُعطي إشارةً حقيقية. قائمةُ الكلمات المفتاحية السلبية أيضًا إلزامية (مثلًا استثنِ eCloud Computing العام).

التوصيةُ العملية: ابدأ التجريبَ الأول بـ5 مجالات × 30-50 كلمة مفتاحية. بعد 8-12 أسبوعًا أَجرِ تحليلَ نسبة التنبيهات وعايِر. مستوى النضج المؤسسي حوالي 80-150 كلمة مفتاحية.

2. خريطةُ المصادر — أين يَعيش الويب المظلم فعلًا

الويبُ المظلم ليس متجانسًا؛ بل منظومةُ شبكات + منتديات + أسواق مختلفة.

الشبكاتُ الرئيسة:

• Tor hidden services (.onion): أكبر منظومة ويب مظلم. حوالي 85% من مواقع تسريب الفدية والمنتديات والأسواق هنا. الوصول: متصفّحُ Tor أو برمجيًا (Stem library، Python).
• I2P: بديلٌ لـTor، أصغر لكنه مجهول. بعضُ المنتديات والأسواق الروسية.
• Freenet: متخصّص، أكاديمي + ناشط، أولويةٌ منخفضة للرصد المؤسسي.
• منتدياتُ الويب المظلم في clear web: BreachForums، RaidForums (مغلق)، nulled.to، إلخ. ليست في Tor لكنها تَحمل ثقافة الويب المظلم.
• قنواتُ Telegram: في 2022-2024 حدثت هجرةٌ كبيرة لفاعلي الويب المظلم إلى Telegram. ALPHV/BlackCat، LockBit، بائعو بيانات الاعتماد، الـIAB ناشطون على Telegram. في الرصد الحديث، Telegram لا يَقلّ أهميةً عن Tor.
• Discord / Matrix: اتصالاتٌ ثانوية، خوادمُ بدعوة فقط.

المنظوماتُ الرئيسة:

المنظومة	النوع	الوصول	نوعُ المحتوى
Exploit.in	منتدى	Tor + عضوية	IAB، malware، exploit
XSS.is	منتدى	Tor + عضوية	روسي، IAB، exploit
BreachForums (v3)	منتدى	Clear/Tor	تسريباتُ بيانات، قوائمُ combo
RAMP	منتدى	Tor + سُمعة	متعلّقٌ بالفدية
موقعُ تسريب LockBit	تسريب	Tor	قائمةُ الضحايا + عيّنات
موقعُ تسريب Cl0p	تسريب	Tor	قائمةُ الضحايا + countdown
Genesis Market (مغلق) → خلَفاؤه	سوق	Tor	وصولُ bot، browser fingerprints
Russian Market	سوق	Clear/Tor	بيانات اعتماد، كوكيز، RDP
Telegram: ALPHV / LockBit / Conti rebirth	قناة	Telegram	إعلاناتُ ما قبل التسريب، التجنيد

توزيعُ اللغات: روسي 45-55%، إنجليزي 30-35%، صيني 5-8%، تركي حوالي 2-4% (يَنمو). تَنسيقُ الهجمات ضد المؤسسات التركية يَجري في الغالب بالروسية أو الإنجليزية؛ المجتمعُ التركي يَجلس أكثر في قطاع احتيال البطاقات وأسواق الهويات.

حداثةُ المصادر: تُغلق المنتدياتُ كلَّ 6-18 شهرًا وتُولَد من جديد (نمطُ BreachForums v1 → v2 → v3 → v4). قائمةُ الرصد يجب أن تَبقى حيّة؛ اجتماعٌ شهري لتدقيق المصادر هو المعيار.

3. معماريّةُ التجميع — SaaS، self-hosted، هجين

ثلاثةُ خيارات معمارية:

A — مَعتمد على SaaS (أسرعُ بداية)

المزوّد	القوّة	الترخيصُ المؤسسي (سنويًا)
Recorded Future	تغطيةٌ واسعة، IoC آلي، خلاصاتٌ متقدّمة	60-300 ألف دولار
Flashpoint	تهديدٌ من الداخل + متطرّف + احتيال	50-200 ألف دولار
Intel 471	متخصّصٌ في IAB + الفدية	40-180 ألف دولار
KELA	مقرّها إسرائيل، IAB + تسريب	30-150 ألف دولار
Searchlight Cyber	المملكة المتحدة، متخصّصٌ في الويب المظلم	35-150 ألف دولار
DarkOwl	حجمُ البيانات + الفهرسة	25-100 ألف دولار
Flare	UX حديثة، صديقٌ للشركات الصغيرة والمتوسطة	15-80 ألف دولار

مزايا: تشغيليٌّ في 1-2 أسبوع، تدريبٌ أدنى للفريق، المزوّدُ يُضيف مصادر باستمرار. عيوب: بياناتُ المؤسسة تَتدفّق إلى المزوّد (DPA + مراجعةُ KVKK إلزامية)، النطاقُ محصورٌ بما يُقدّمه المزوّد، الأسعارُ تَتصاعد عدوانيًا.

B — Self-hosted (أقصى تحكّم)

الـStack:

• Tor proxy (privoxy، torsocks) + مكتبةُ Python Stem
• Crawler: Scrapy، Selenium (لتسجيل دخول المنتدى)، مخصّص
• Storage: Elasticsearch + S3 Backup
• تصوير: Kibana، Grafana
• تنبيهات: ElastAlert، Watchman، Lambda مخصّص

مزايا: تحكّمٌ كامل بالبيانات، مثاليٌّ لـKVKK، قائمةُ مصادر قابلةٌ للتخصيص كاملًا، لا vendor lock-in. عيوب: الإنشاء 3-5 أشهر، التشغيل 1-2 FTE، التغطيةُ تَتراجع باستمرار (مصادرُ جديدة تُضاف يدويًا)، إدارةُ حساب المنتدى معقّدة (CAPTCHA، سُمعة، OPSEC).

C — هجين (النمطُ الموصى به للمؤسسات)

SaaS للتغطية الواسعة (Recorded Future أو مماثل)، crawler مخصّص self-hosted للمصادر الحرجة، مُوحَّد على MISP. 11 من 14 مشروعًا أنشأناها في الـ24 شهرًا الأخيرة اختارت هذا النمط.

الطوبولوجيا:

[SaaS provider API] ──┐
                      ├──> [MISP] ──> [SIEM] ──> [SOC + SOAR]
[Self-hosted Tor crawler] ──┘                       │
                                                    ▼
                                            [لوحةُ التنبيهات + مراجعةُ المحلّل]

MISP (Malware Information Sharing Platform، مفتوحُ المصدر) يُطبّع كلَّ الـIoCs، يُزيل المكرّرات، يُطبّق scoring، يَتبادل مع مجموعات المشاركة القطاعية (MISP المغلق لبنوك BDDK الأعضاء، تَنسيقُ TÜBİTAK BİLGEM-USOM). العضويةُ مجانية + تسجيلٌ مؤسسي.

OPSEC حرج: يجب أن يَعمل crawler الويب المظلم من VPN/proxy منفصل + VM مُكرَّس، لا من كتلة IP المؤسسة. حسابُ المنتدى لا يَستخدم اسم/بريد موظف، بل هويةً منفصلة (persona). إن أُهمل هذا التفصيل صارت المؤسسةُ نفسُها هدفًا.

4. تطبيعُ IoC، scoring، lifecycle

البياناتُ الخام مجرّد بيانات؛ IoCs غير مُعالَجة تُحوّل SIEM إلى قمامة (آلافٌ من الإيجابيات الكاذبة). ثلاثُ طبقات:

الطبقةُ 1 — تطبيع: تَحويلُ صيغ IoC (IP، نطاق، URL، hash MD5/SHA1/SHA256، بريد، عنوانُ BTC، إلخ) إلى معيار STIX 2.1. يَقوم MISP بهذا التحويل افتراضيًا.

الطبقةُ 2 — Scoring: كلُّ IoC يَحصل على درجة ثقةُ المصدر + العمر + السياق:

العامل	عالٍ	متوسط	منخفض
ثقةُ المصدر	TI متقدّمة (Recorded Future، Mandiant)	خلاصةٌ مفتوحة (OTX، Abuse.ch)	كَشطُ منتدى، غيرُ مُتحقَّق
العمر	<7 أيام	7-30 يومًا	>30 يومًا (expire)
السياق	عيّنةُ malware موقَّعة + reverse engineered	إشارةُ منشور في منتدى	إشارةُ اسم فقط
Confidence	90-100	60-90	<60

IoCs منخفضةُ الـscoring لا تَذهب إلى SIEM (تَظهر في لوحة القيادة فقط)؛ المرتفعةُ تُطلق block/quarantine + تنبيه آليًا.

الطبقةُ 3 — Lifecycle (TTL):

• IP عالي الثقة: حظرٌ لمدة 30 يومًا
• ثقةٌ متوسطة: 14 يومًا
• نطاقُ phishing: 7 أيام (قصيرُ العمر)
• hash malware: دائم (الـhash لا يَتغيّر)
• بدون آليّةِ auto-expire يَمتلئ SIEM بـIoCs قديمة في 6 أشهر.

حلقةُ feedback للإيجابيات الكاذبة: حين يُؤشّر محلّلُ SOC على IoC كـإيجابية كاذبة، تَنخفض درجتُه في MISP، فلا يُنبّه مستقبلًا. بدون هذا الانضباط يَدخل الفريقُ في غضون 3 أشهر في وضع "تجاهل كل التنبيهات" (alert fatigue) — وتَضيع التهديداتُ الحقيقية.

مقالُنا عمليات SOC يَتعمّق في تكامل IoC-SOC هذا.

5. تدفّقُ الاستجابة لحالة التسريب — ماذا تَفعل حين تَجد

القيمةُ الحقيقية للرصد في الاستجابة للتسريب الذي وَجدته. إن لم تَفعل شيئًا بعد العثور، فالقيمةُ صفر. خمسةُ سيناريوهات نموذجية + تدفّقاتُ استجابة:

السيناريو 1: بياناتُ اعتماد موظف في قائمة Combo

1. تحقّق: هل زوجُ بريد + كلمة سر حقيقي؟ Have I Been Pwned API + فحصُ AD داخلي.
2. تحديدُ المستخدمين المتأثرين: كم موظف، أيُّ أنظمة.
3. إجراء: force password reset، MFA إلزامي، session invalidation، رصدُ تسجيل دخول صارمٌ لمدة 30 يومًا.
4. إخطارُ KVKK: إعلامُ الموظف (المادة 10)، عند الحاجة إخطارٌ لمجلس KVKK في 72 ساعة (المادة 12).
5. الوقتُ المستهدف: تنبيه → إجراءٌ كامل في 4 ساعات.

السيناريو 2: اسمُ المؤسسة في إعلان IAB

1. تحليلُ منشور المنتدى: نوعُ الوصول (VPN، RDP، domain admin، web shell)، السعر، سُمعةُ البائع.
2. تدقيقٌ داخلي: سجلّاتُ VPN + تدقيقُ AD + سجلّاتُ الوصول البعيد للأيام الـ30-90 الأخيرة.
3. التحقّق من الفرضية: تَسوية حقيقية أم خداع؟
4. إجراء: تَدويرُ كل بيانات اعتماد الوصول البعيد، فرضُ MFA، إعادةُ تعيين الجدار الناري، تَجييشُ فريق IR.
5. الوقتُ المستهدف: تنبيه → إجراءٌ كامل في 24 ساعة (المتوسطُ من IAB إلى الفدية 7-21 يومًا، لكن السرعة مهمّة).

السيناريو 3: اسمُ المؤسسة في موقع تسريب فدية (العيّنةُ لم تُنشر بعد)

1. تحقّق: هل هناك countdown، أيُّ مجموعة (LockBit/Cl0p/BlackBasta).
2. جنائياتٌ داخلية: هل ثمّة breach نشط؟
3. فريقُ الأزمة: اجتماعُ CEO + CISO + قانوني + PR + IR vendor.
4. قرارُ التفاوض: التواصلُ مع vendor (Coveware، Mandiant، إلخ) أم لا.
5. تَحضيرُ إخطار KVKK: نصُّ إعلام العميل/الموظف، إخطارُ المجلس.
6. تَحضير PR: إن كان البيانُ العام لازمًا.
7. الوقتُ المستهدف: تنبيه → اجتماعُ أزمة في ساعتين.

السيناريو 4: إساءةُ علامة (نطاقُ phishing)

1. إنزالُ النطاق: تقريرُ إساءةٍ إلى الـregistrar، مزوّدُ الاستضافة، تَنسيقٌ مع USOM في تركيا.
2. قائمةُ حظر المتصفّح: تقديمٌ إلى Google Safe Browsing، Microsoft SmartScreen.
3. إعلامُ العميل: تحذيرٌ عبر القناة المعنية.
4. الوقتُ المستهدف: تنبيه → طلبُ إنزال في 8 ساعات، الإزالةُ الفعلية 1-7 أيام.

السيناريو 5: تسريبُ كودٍ مصدري / مفتاح API

1. تحقّق: هل المفتاحُ نشط؟
2. إلغاءٌ فوري (في غضون ثوانٍ).
3. تدقيق: سجلُّ استخدامِ المفتاح لـ90 يومًا، هل هناك شذوذ.
4. تَنظيفُ مستودع الكود: BFG Repo-Cleaner أو مماثل لتنظيف تاريخ الـcommit.
5. الوقتُ المستهدف: تنبيه → إلغاء في 15 دقيقة.

خدمتُنا الاستجابة للحوادث تُوفّر playbooks + تمارين tabletop لهذه السيناريوهات الخمسة.

6. المعالجةُ المتوافقة مع KVKK — حين تَحمل بياناتِ التسريب في يدك

رصدُ الويب المظلم يَحتوي بياناتٍ شخصية: بريدُ الموظفين، قوائمُ العملاء المُسرَّبة، الهواتف، أرقامُ الهوية، الـIBAN. تَنزيلُ هذه البيانات ومعالجتُها نشاطُ معالجةٍ وفق KVKK؛ الأساسُ القانوني + التدابيرُ الأمنية إلزامية.

سبعُ انضباطات:

1. الأساسُ القانوني مكتوب: المادة 5/2 المصلحةُ المشروعة (أمنُ المؤسسة) أو المعالجةُ لغرض إخطار المستخدمين. وثيقةُ سياسة + سجلّ مسؤول البيانات VERBİS.

2. تقليلُ البيانات: تُؤخَذ فقط الحقولُ الخاصة بالمؤسسة من التسريب؛ تُحذف السجلّاتُ العامة (بياناتُ موظفي منافس). لا تُحتفظ بـPII لا تَخصّ المؤسسة.

3. التحكّم بالوصول: يَصل إلى مَخزن بيانات الويب المظلم محلّلو الأمن المُخوَّلون فقط (3-5 أشخاص كحدٍّ أقصى) تحت RBAC + MFA + سجلّ تدقيق.

4. مدّةُ الاحتفاظ: 90 يومًا hot (تنبيه + تحقيق)، ثم مرجعٌ مُجزَّأ (hashed) + 12 شهرَ أرشيف (فقط بياناتٌ وصفية: "هذا المستخدم ظَهر في المصدر Y في التاريخ X"؛ تُحذف البياناتُ الخام).

5. تشفير: كلُّ التخزين (فهرس Elasticsearch، نسخُ S3 الاحتياطية، قاعدة بيانات MISP) AES-256 at-rest + TLS 1.3 in-transit.

6. نقلٌ عابر للحدود: مواقعُ بيانات مزوّدي SaaS تقع عادةً في الولايات المتحدة/الاتحاد الأوروبي. DPA + بنودُ تَعاقد قياسية في العقد، ترجمةٌ تركية.

7. تكاملُ إخطار الخرق: إن أَظهر التسريبُ الذي وَجدته خرقَ KVKK حقيقيًا (بيانات عملاء المؤسسة سُرّبت)، تُبلّغ المؤسسةُ المجلسَ في 72 ساعة + تُخطر المستخدمين المعنيين. تُؤتمَت العملية كـإخطار → تسجيل → سلسلة دليل.

تَدمج خدمتُنا بحث OSINT هذه الانضباطات السبع مع مُلحق العقد في السياسة المؤسسية.

7. النضجُ المستمر — مؤشّرات، صيدُ تهديدات، تَدريبُ الفريق

رصدُ الويب المظلم + TI ليس نظامًا يُنشَأ ويُنسى؛ بل انضباطٌ حيّ. يَبدأ العملُ الحقيقي بعد الأشهر الستّة الأولى.

لوحةُ KPI (أسبوعيًا):

المؤشّر	الهدف	المعنى
حجمُ التنبيهات	تتبّعُ الاتجاهات	الانفجاراتُ إشارةُ ضبط
MTTD (Mean Time To Detect)	<24 ساعة	تَسريبٌ نُشر → لُوحظ
MTTA (Mean Time To Action)	<4 ساعات (P1)	لُوحظ → إجراءٌ أول
معدّلُ الإيجابيات الكاذبة	<20%	عالٍ → ضبطُ keyword/scoring
عددُ التسريبات المُتحقَّق منها / شهر	خطُّ أساس قطاعي	مؤشّرُ تغطيةٍ فعّالة
المصادرُ المرصودة	تَنمو باستمرار	نموُّ التغطية
معدّلُ نجاح التنزيل	60%+	جودةُ عملية إساءة العلامة

صيدُ التهديدات (استباقي، لا مدفوعٌ بالتنبيهات):

• فرضيةٌ شهرية: "أيُّ قطاعٍ تَستهدفه مجموعة FIN7 في الأشهر الستّة الأخيرة، هل نحن قريبون؟" → MITRE ATT&CK Groups + بحثٌ في الويب المظلم → تَقييمُ مخاطر خاصٌّ بالمؤسسة.
• "أيُّ مورّدٍ لنا ظَهر في منتدى تسريب في الـ90 يومًا الأخيرة؟" → تَسطيحُ مخاطر طرفٍ ثالث.
• "أيُّ بيانات اعتماد الموظفين السابقين لا تَزال تَبدو نشطة؟" → تَدقيقُ AD + دورةُ إلغاء.

تَدريبُ الفريق:

• ملخّصٌ شهري لتحديثات الويب المظلم (منتدًى جديد، مجموعةٌ جديدة، TTP جديدة).
• هدفُ شهادةٍ كلَّ 6 أشهر: SANS FOR578 (Cyber Threat Intelligence)، GIAC GCTI، CREST CRTIA.
• مؤتمراتٌ سنوية: SANS CTI Summit، FIRST Conference، Black Hat، BSides İstanbul.
• تَمرينُ OPSEC: كلُّ محلّل يُجري تَدقيقَ OPSEC شخصي كلَّ 6 أشهر (بريد، وسائل تواصل، فصلُ persona).

مراجعةُ ما بعد الحادث: بعد كلِّ تسريب P1 retro بلا لومٍ — ما الذي أمسكنا، ما الذي رأينا متأخرًا، أيُّ مصدر كان ناقصًا، أيُّ keyword يجب إضافتُه. ملاحظاتُ الـretrospective تُكتَب في wiki مغلق.

ملخّصٌ عملي — قائمةُ بداية

الترتيبُ الصحيح لأوّل برنامج رصد ويبٍ مظلم + TI إنتاجي:

1. تعريفُ النطاق: 5 مجالات × 30-50 كلمة مفتاحية. الكلماتُ السلبية إلزامية.
2. خريطةُ المصادر: Tor + Telegram + منتدياتُ ويبٍ مظلم في clear web. لا تَتجاوز Telegram.
3. معماريّةُ التجميع: شركات صغيرة ومتوسطة → SaaS (Recorded Future / Flare / KELA)؛ مؤسسات → هجين (SaaS + self-hosted + MISP).
4. OPSEC: crawler الويب المظلم من IP + persona منفصل؛ لا IP/هوية مؤسسة.
5. Scoring + TTL لـIoC: ثقةُ المصدر + العمر + السياق. المنخفضةُ لا تَذهب إلى SIEM.
6. MISP: كلُّ IoCs في hub واحد؛ المشاركةُ القطاعية (BDDK، USOM) نشطة.
7. Playbooks الاستجابة: مكتوبةٌ للسيناريوهات الخمسة (credential / IAB / فدية / إساءةُ علامة / كودٌ مصدري).
8. سياسةُ KVKK: الأساسُ القانوني، الاحتفاظ، التشفير، التحكّم بالوصول، تكاملُ إخطار الخرق.
9. لوحةُ KPI: MTTD/MTTA/FP أسبوعيًا؛ مراجعةُ اتجاهات شهرية.
10. النضجُ المستمر: صيدُ التهديدات (أسبوعي)، تَدريب (شهادات)، مراجعةُ ما بعد الحادث (بعد كلِّ P1).

هذه القائمةُ هي الحدُّ الأدنى من الانضباط. تُضاف فوقها إضافاتٌ قطاعية (الامتثالُ للائحة BDDK لاستخبارات التهديدات للبنوك، حمايةُ بياناتٍ خاصّةٍ إضافية للصحة، تَعاملُ المعلومات المُصنَّفة للدفاع). قيمةُ رصد الويب المظلم ليست في امتلاك الأدوات، بل في تَحويل ما تَجده إلى إجراء بسرعةٍ وأمانةٍ وقانونيّة.

شَيّد فريقُنا في شانلي أورفا قرة كوبرو برامجَ رصد ويبٍ مظلم + TI في قطاعات المالية والصحة والطاقة والتجارة الإلكترونية والقطاع العام عبر خدمات استخبارات التهديدات وبحث OSINT وData Fusion ويُشغّلها. ولأجل تجربة رصد ويبٍ مظلم مؤسسي، أو تَقييم برنامج TI، أو تَدقيق نضج نظام رصدكم القائم، يَمكنكم التواصل عبر نموذج الاتصال؛ المكالمةُ الأولى للتقييم مجانية.

---

eCloud Tech — فريقٌ مقرّه شانلي أورفا في تركيا، يَعمل في البرمجيات المؤسسية والذكاء الاصطناعي والبلوكتشين والأمن السيبراني. Building Tomorrow.