تحليل رسالة تصيّد: من الرسالة إلى البنية التحتية

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

الحصول على الترويسة كاملة: ظرف الرسالة

ما يعرضه برنامج البريد (المرسِل، والموضوع، والنص) ليس سوى الرسالة نفسها. وحولها ظرف غير مرئي: الترويسة، أي عشرات الأسطر التقنية التي أُضيفت على طول الطريق. هناك تختبئ الأدلة. ولعرضها:

• Gmail: قائمة ⋮ الخاصة بالرسالة، ثم «عرض الرسالة الأصلية»؛
• Outlook: قائمة … الخاصة بالرسالة، ثم الخيار الذي يعرض تفاصيل الرسالة أو مصدرها؛
• Apple Mail: قائمة «عرض»، ثم «الرسالة» وخيار عرض كل الترويسات؛
• Thunderbird: الاختصار Ctrl+U (أو Cmd+U على Mac)، الذي يفتح مصدر الرسالة.

نصيحة: لا «نعيد توجيه» الرسالة لتحليلها. فإعادة التوجيه تُنشئ رسالة جديدة بترويسة جديدة، فتختفي الأدلة الأصلية. الأفضل نسخ المصدر الكامل، أو حفظ الرسالة كملف .eml.

أسطر Received: أختام البريد

من بين كل هذه الأسطر، أثمنها تلك التي تبدأ بـ Received:. فكل خادم يتسلّم الرسالة يضيف سطره الخاص في أعلى الكومة، مثل مكتب بريد يختم الظرف في كل مرة يمر به. أما رحلة الرسالة كاملة فيرويها دليل كيف تنتقل رسالة البريد الإلكتروني من المرسِل إلى المستلم.

هذه ترويسة مبسّطة، مثل تلك التي نجدها في رسائل تصيّد حقيقية:

Received: from mx1.provider.example (mx1.provider.example [192.0.2.10])
        by mailbox.provider.example; Tue, 15 Sep 2026 09:14:05 +0200
Received: from vps-4411.host.example (vps-4411.host.example [203.0.113.45])
        by mx1.provider.example with ESMTPS; Tue, 15 Sep 2026 09:14:03 +0200
Received: from mail.mybank.example (unknown [10.0.0.7])
        by vps-4411.host.example; Tue, 15 Sep 2026 07:13:58 +0000
Authentication-Results: mx1.provider.example;
        spf=pass smtp.mailfrom=parcel-mail.example; dkim=none;
        dmarc=fail header.from=mybank.example
Return-Path: <bounce@parcel-mail.example>
From: "My Bank" <security@mybank.example>
Reply-To: mybank.support@freemail.example
Subject: Your account will be suspended within 24 hours

يُقرأ كل سطر Received كجملة قصيرة: «استُلمت من (from) الجهاز الفلاني، بواسطة (by) الخادم الفلاني، في التاريخ الفلاني». وبعد from مباشرة يأتي الاسم الذي أعلنه الجهاز عن نفسه، دون أي تحقق. أما بين القوسين فيأتي ما لاحظه فعلًا الخادم المستلِم: عنوان IP للجهاز الذي كان أمامه، بين قوسين معقوفين.

نقرأ من الأسفل إلى الأعلى… لكننا نثق من الأعلى إلى الأسفل

بما أن كل خادم يضيف سطره فوق الأسطر السابقة، فالقصة تُقرأ من الأسفل إلى الأعلى: السطر السفلي يروي الانطلاق، والعلوي يروي الوصول إلى صندوقنا. في المثال، تنطلق الرسالة من جهاز يدّعي أنه «mail.mybank.example»، وتمر عبر vps-4411.host.example، ثم تدخل خدمة بريدنا.

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

المنهج إذن بسيط: نبدأ من الأعلى، وننزل ما دامت الأسطر مكتوبة بواسطة خدمة بريدنا. ونتوقف عند سطر الدخول، أي السطر الذي تستلم فيه خدمة بريدنا الرسالة من جهاز خارجي. عنوان IP الموجود بين القوسين المعقوفين في هذا السطر، وهو هنا 203.0.113.45، هو أمتن دليل في الترويسة كلها: إنه الجهاز الذي سلّم الرسالة فعلًا. وهذا بالضبط ما يبحث عنه Baitback.

وماذا عن السطر السفلي؟ إنه يدّعي أن الرسالة أتت من «mail.mybank.example»، من العنوان 10.0.0.7، وهو عنوان خاص لا وجود له على الإنترنت. وقد كتبه vps-4411 نفسه: إنه خيط مضلّل وُضع عمدًا.

ما هو موثوق، وما يمكن تزويره

في المثال، يكشف Authentication-Results الكثير. فـspf=pass يعني أن الخادم كان مسموحًا له فعلًا بالإرسال… باسم parcel-mail.example، نطاق الظرف، لا باسم البنك. وdmarc=fail يعني أن العنوان المعروض mybank.example لا يطابق أي شيء تم التحقق منه: خانة «من» مزيّفة. فلماذا وصلت الرسالة رغم ذلك؟ هذا هو موضوع دليل قد تكذب رسالة البريد… حتى عندما تقول الفحوص «سليم».

من عنوان IP إلى المشغّل: لمن هذا العنوان؟

عنوان IP هو العنوان البريدي لجهاز على الإنترنت. ومثل العناوين البريدية، تُوزَّع هذه العناوين في كتل كبيرة. تتولى ذلك خمسة سجلات إقليمية: RIPE NCC (أوروبا والشرق الأوسط)، وARIN (أمريكا الشمالية)، وAPNIC (آسيا والمحيط الهادئ)، وLACNIC (أمريكا اللاتينية)، وAFRINIC (أفريقيا). وهي تسلّم هذه الكتل إلى مشغّلين يؤجّرونها بدورهم لعملائهم.

تُجمَّع هذه الكتل في شبكات، ولكل شبكة رقم يعرّفها: ASN، مثل AS64500. فإذا كان عنوان IP هو عنوان المنزل، فإن ASN هو الحي، وهو يدل على المشغّل الذي يديره ويمرّر حركة الإنترنت عبره.

لمعرفة من يقف خلف عنوان IP، نستعلم دليل هذه السجلات عبر بحث WHOIS، أو عبر نسخته الحديثة RDAP. وكثير من المواقع المجانية تفعل ذلك بنقرة واحدة. وفي سطر الأوامر، تبدو النتيجة هكذا (مقتطف مبسّط):

$ whois 203.0.113.45
inetnum:        203.0.113.0 - 203.0.113.255
netname:        HOST-EXAMPLE-VPS
org-name:       Host Example SAS
country:        FR
abuse-mailbox:  abuse@host.example
origin:         AS64500

ثلاث معلومات تهمّنا: مَن (اسم الجهة)، وأين (البلد، وهو مفيد لمعرفة القوانين المطبّقة)، وقبل كل شيء عنوان abuse، أي الصندوق الرسمي الذي يستقبل بلاغات إساءة الاستخدام. والاسم العكسي لعنوان IP، وهو هنا vps-4411.host.example، يعطي غالبًا دليلًا إضافيًا: كلمة «vps» تشير إلى خادم افتراضي مستأجَر.

فخّ شائع: مشغّل الشبكة ليس دائمًا المستضيف النهائي. فقد يؤجّر مشغّل كبير كتلة عناوين لمعيد بيع، يؤجّر هو بدوره خوادم لعملائه. عندها يعرض WHOIS كتلة صغيرة باسم معيد البيع، مع عنوان abuse خاص به. وهو من نتواصل معه أولًا: فهو الأقرب إلى الجهاز.

تتبّع الخيوط الأخرى: المرسِل، والرابط، وDNS

عنوان IP المرسِل ليس سوى خيط واحد. فالتصيّد يترك خيوطًا أخرى، وكل منها يقود إلى طرف مختلف.

خيط المرسِل

ننظر إلى النطاقات التي تظهر في From وReturn-Path وReply-To:

• بريد مجاني (مثل Gmail أو Outlook.com): الطرف هنا هو مزوّد الخدمة، الذي يستطيع إغلاق الحساب. وهذا مفيد خصوصًا مع Reply-To، أي الصندوق الذي تصل إليه ردود الضحايا؛
• نطاق أُنشئ خصيصًا: نبحث عن المسجِّل، أي الشركة التي باعته، عبر استعلام RDAP أو WHOIS عن النطاق، مثلًا على lookup.icann.org. وهناك نجد أيضًا تاريخ الإنشاء: نطاق «مصرفي» وُلد قبل ثلاثة أيام علامة سيئة جدًا؛
• النطاق الحقيقي لعلامة تجارية منتحَلة: العلامة لا ذنب لها، فهي لم ترسل الرسالة. ويمكن إبلاغها إن كانت توفّر عنوانًا للإبلاغ عن التصيّد.

خيط الرابط

يقود رابط الرسالة إلى صفحة الفخ، التي لا بد أنها مستضافة في مكان ما. لا ننقر عليه: بل ننسخ العنوان (نقرة يمنى، «نسخ الرابط»). الاسم المهم هو النطاق، قبل أول «/» مباشرة بعد https://؛ وكل ما على يساره يختاره المحتال بحرية. وكثيرًا ما تمر الروابط عبر عدة عمليات إعادة توجيه: يتتبّعها Baitback نيابةً عنا ويعرض السلسلة كاملة. وعن الروابط المخبّأة داخل صورة، راجع دليل التصيّد برموز QR: حين يختبئ الاحتيال خلف رمز QR.

خيط DNS

نظام DNS، دليل هاتف الإنترنت، يخبرنا أين يوجد كل جزء من النطاق. تكفي ثلاثة أسئلة:

$ dig +short A  secure-login.example    # IP of the website (sometimes a CDN)
$ dig +short MX secure-login.example    # servers that receive its email
$ dig +short NS secure-login.example    # who runs its DNS

السؤال الأول يعطي عنوان IP للموقع (وقد يكون شبكة CDN)، والثاني الخوادم التي تستقبل بريده، والثالث الجهة التي تدير دليل DNS الخاص به. ثم يمر عنوان IP للموقع بالمسار نفسه الذي مر به عنوان IP المرسِل: WHOIS، وASN، والمشغّل، وعنوان abuse. أما النطاق الذي لا يملك أي خادم بريد ومع ذلك يدّعي أنه يراسلنا، فيستحق نظرة: راجع سجل MX في نظام DNS: علامة ثقة؟

لماذا نجد دائمًا عدة مزوّدين

في نهاية التحقيق، نادرًا ما نخرج باسم واحد. وهذا طبيعي: فحملة التصيّد تشبه انتقالًا إلى منزل جديد يتم كله بأشياء مستأجَرة. يُشترى اسم النطاق من مسجِّل، ويدير DNS الخاص به طرف آخر، وتوضع الصفحة على خادم مستأجَر في مكان آخر ومخفي خلف شبكة CDN، وتنطلق الرسائل من خادم ثالث (راجع التصيّد الاحتيالي: كيف يوصل المحتالون رسائلهم إلى بريدك)، وتصل الردود إلى صندوق بريد مجاني.

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

عنوان IP ليس مذنبًا

إغراء شائع: نجد عنوان IP، ونقرأ اسم شركة أو بلد، فنستنتج «إنهم هم». وهذا خطأ في أغلب الأحيان. فعنوان IP يدل على آخر جهاز سلّم الرسالة، لا على الشخص الجالس خلف لوحة المفاتيح. وقد يكون هذا الجهاز:

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

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

النطاق أم الخادم: اللافتة والمبنى

لفهم من يفعل ماذا، تساعد الصورة كثيرًا. لنتخيّل فرعًا مصرفيًا مزيّفًا في أحد الشوارع:

• اسم النطاق هو اللافتة فوق الباب، والمسجِّل هو الجهة التي أجّرت هذا الاسم: يستطيع إنزال اللافتة؛
• الخادم هو المبنى الذي يقع فيه الفرع المزيّف، والمستضيف هو مالكه: يستطيع طرد المستأجر؛
• عنوان IP هو العنوان المكتوب على لوحة الواجهة؛
• شبكة CDN هي مكتب استقبال أمام المدخل: يتحدث الزوار إلى الاستقبال، الذي ينقل طلباتهم إلى المبنى. ومن الشارع، لا يُرى سواه.

إيقاف الخادم يزيل الصفحة، لكن المحتال يستطيع توجيه نطاقه إلى خادم آخر في دقائق. أما تعليق النطاق، فيجعل كل الروابط المرسَلة سابقًا عديمة الفائدة، حتى لو ظل الخادم يعمل. والإجراءان يكمّل أحدهما الآخر.

حالة شبكة CDN

إذا أظهر WHOIS لعنوان IP الموقع اسمًا مثل Cloudflare أو Akamai أو Fastly، فهو في الغالب ليس المستضيف: إنه الاستقبال. تقبل شبكة CDN البلاغات، ويمكنها عرض صفحة تحذير للزوار، وتنقل الشكوى إلى المستضيف الحقيقي الذي تعرف عنوانه. فمثلًا توفّر Cloudflare نموذجًا مخصّصًا على abuse.cloudflare.com. ونبلّغ أيضًا مسجِّل النطاق، الذي لا تخفيه شبكة CDN.

حالة الخادم المخترَق

عنوان من نوع https://bakery-ahmad.example/wp-content/uploads/x/login.php يكشف غالبًا موقعًا مخترَقًا. فالنطاق موجود منذ سنوات ويعود إلى متجر حقيقي؛ وقد دُسّت صفحة الفخ في زاوية منه. هنا، طلب تعليق النطاق سيكون ظالمًا وعديم الجدوى: نبلّغ المستضيف، وصاحب الموقع إن وجدنا وسيلة للتواصل معه، مع ذكر العنوان الدقيق للصفحة. والمنطق نفسه ينطبق على رسالة أُرسلت من صندوق بريد حقيقي مخترَق: نبلّغ المزوّد، الذي يستطيع إيقاف الحساب وإعادته إلى صاحبه.

بمن نتصل حسب الحالة

توجد أيضًا منصات رسمية. ففي فرنسا مثلًا، يمكن إعادة توجيه الرسالة إلى Signal Spam والإبلاغ عن الاحتيال على منصة PHAROS؛ ولكل بلد ما يقابلها. تخدم هذه المنصات أساسًا الإحصاءات والتحقيقات: فهي لا توقف خادمًا خلال ساعة، لكنها تحفظ أثرًا رسميًا.

بناء سلسلة البلاغات

الإبلاغ عن كل شيء دفعة واحدة، ولكل الناس، لا ينجح كثيرًا. الأفضل أن نمضي بالترتيب، من الأكثر إلحاحًا إلى الأطول أثرًا:

1. وقف الضرر: صفحة الفخ (المستضيف أو شبكة CDN) وقوائم الحظر في المتصفحات. كل ساعة مهمة: فالحملة توقع معظم ضحاياها في ساعاتها الأولى.
2. قطع الاسم: مسجِّل النطاق، لجعل الروابط المرسَلة سابقًا عديمة الفائدة.
3. قطع الإرسال: مستضيف عنوان IP المرسِل، ومزوّد صندوق Reply-To.
4. ترك أثر: المنصات الرسمية، لأجل التحقيقات.

البلاغ الجيد قصير وقابل للتحقق. ويتضمن:

• الترويسة الكاملة للرسالة، لا مجرد لقطة شاشة؛
• العنصر المحدد الذي يعني هذا المستلم: عنوان IP للمستضيف، والنطاق للمسجِّل، والعنوان الدقيق للصفحة لمستضيف الموقع؛
• التاريخ والوقت، مع المنطقة الزمنية؛
• روابط معطَّلة، مكتوبة مثلًا hxxps://secure-login[.]example، حتى لا ينقر عليها أحد عن طريق الخطأ.

وهذا بالضبط ما يقوم به Baitback: نلصق مصدر الرسالة، فتقرأ الأداة أسطر Received، وتعثر على خادم الإرسال ومستضيفه وعنوان البلاغ لديه، وتتحقق من SPF وDKIM وDMARC، وتتبّع الروابط وعمليات إعادة التوجيه، ثم تُعدّ رسائل البلاغ جاهزة للإرسال. تحقيق هذا الدليل كله، في بضع ثوانٍ.