هذه الـ 3 رؤوس في رسائل الإيميل تكشف الرسائل المزيفة – إليك كيف تتحقق

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

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

حقل “من” لا يثبت من أرسل البريد الإلكتروني

المصادقة تتحقق من صحة النطاق، وليس العلامة التجارية

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

إن تلقي بريد إلكتروني يقول بوضوح “PayPal Security” لا يعني أن PayPal أرسله. قد يكون المرسل الفعلي [email protected]، مع استبدال حرف “L” الصغير في PayPal بالرقم “1”. يمكن أن يخدعك هذا إذا كنت في عجلة من أمرك. لرؤية المرسل الحقيقي، تحقق من رأس From للبريد الإلكتروني للمرسل بين قوسين زاويين. ومع ذلك، لا يمكن لهذا وحده أن يعطي تأكيدًا نهائيًا للأصالة. يجب عليك فحص مصدر البريد. في Gmail، افتح البريد الإلكتروني، وانقر على النقاط الثلاث بجوار رمز الرد، وانقر على Show original؛ في Outlook لسطح المكتب، انتقل إلى File -> Properties -> Internet Headers؛ في Apple Mail، انتقل إلى View –> Message –> All Headers. في صفحة الرسالة الأصلية، البيانات الثلاث التي تهم هي From و Return-Path و Authentication-Results (نتائج SPF و DKIM و DMARC).

يجب أن تكون قيم SPF و DKIM و DMARC هي PASS. ومع ذلك، هذا وحده لا يثبت الأصالة. ولكنه على الأقل يخبرك بأنه تم التحقق من صحة البريد الإلكتروني المرسل بشكل صحيح، مما يعني أن من أرسل البريد الإلكتروني لديه تحكم فني في النطاق. تذكر، يمكن للمجرم تسجيل paypa1-secure.com، وإذا قاموا بتكوين SPF، وتوقيع الرسائل باستخدام DKIM، ونشر سياسة DMARC، فسوف ينجحون في إثبات التحكم الفني.

في هذه الطبقة، العلامة الأساسية للبريد الإلكتروني المزيف هي عدم التوافق بين الرؤوس (From، Return-Path، نتائج SPF/DKIM). تأكد من أن عنوان From المرئي يطابق النطاق في Return-Path، وتأكد من أن SPF IP يمر لنطاق العلامة التجارية الفعلي. إذا تم التحقق من كل هذا، فهناك احتمال كبير ألا يكون البريد الإلكتروني مزيفًا.

تُظهر سلسلة “Received” من أين أتى البريد الإلكتروني فعليًا

يترك كل خادم بريد بصمة يكافح المهاجمون للسيطرة عليها

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

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

Received: from a74-66.smtp-out.amazonses.com (a74-66.smtp-out.amazonses.com. [54.240.74.66]) 
by mx.google.com

هذا المثال هو السطر الذي تكتبه Google، وليس السطر الذي أضافه المرسل. إنه ببساطة يخبرني أن Google استلم البريد الإلكتروني من IP 54.240.74.66 في smtp-out.amazonses.com. الآن، لكي أرى ما إذا كان هذا منطقيًا، يجب علي التحقق منه مقابل الرؤوس المرئية الأخرى في الرسالة.

بالنسبة لهذه الرسالة بالتحديد، فإن المرسل المرئي في الرأس هو [email protected]. و Return-Path هو نطاق Amazon: amazonses.com. من المعلومات الأخرى التي تحققت منها سابقًا، يمكنني أن أرى أن SPF قد اجتاز هذا Amazon SES IP، 54.240.74.66، وأن DKIM قد اجتاز makeuseof.com. كل شيء متسق. من الشائع جدًا أن ترسل الشركات إشعارات باستخدام البنية التحتية لـ Amazon SES، لذلك تتوافق الصورة بأكملها.

عندما يكون البريد الإلكتروني شرعيًا، فإنه يتبع مسار توجيه يتضمن:

1. خدمة بريد معترف بها
2. مصادقة تطابق الخادم المرسل
3. لا يوجد مزود استضافة عشوائي في السلسلة (يجب أن يكون منصة خدمة بريد إلكتروني معترف بها)

عادةً ما تترك رسائل البريد الإلكتروني المزيفة أثرًا حيث يتلقى مزود الخدمة رسالة من VPS غير ذي صلة، أو نطاق غريب، أو عنوان IP غير مرتبط بالمرسل المعلن.

تشوهات Message-ID والمغلف تكشف عن التصيد الاحتيالي الكسول أو الجماعي

نادراً ما تتطابق تفاصيل البنية التحتية مع العلامة التجارية التي يتم انتحالها

حقل Message-ID هو عنوان مهم آخر لا ينبغي تجاهله. إنه العنصر الأول الذي تراه في صفحة عرض المصدر. هذا هو معرف فريد عالميًا يقوم خادم مرسل الرسالة بإنشائه. عادةً، يأتي في شكل سلسلة طويلة تنتهي بمكون @domain. يجب أن تنتبه إلى هذا النطاق.

يجب أن تتوقع أن الرسالة الواردة من amazon.com يجب أن يكون لها Message-ID ينتهي بنطاق Amazon. بدلاً من Amazon، تعتبر علامة حمراء إذا حصلت على شيء مثل @cheapmailer.hosting123.net؛ لا تتغاضى عن ذلك.

ومع ذلك، هناك بعض الأدلة الأخرى في Message-ID التي تظهر أن الرسالة ليست أصلية:

1. Message-ID مفقود تمامًا.
2. تنسيقات Message-ID متطابقة عبر رسائل البريد الإلكتروني التصيدية غير ذات الصلة.
3. رؤوس X-Mailer قديمة أو غريبة.
4. X-Originating-IP مكشوف يشير إلى نطاق استضافة سكني أو منخفض التكلفة.

السبب وراء كون Message-ID أداة قوية لاكتشاف رسائل البريد الإلكتروني الاحتيالية هو أنه في حين أن المهاجمين المتطورين قد يقومون بتنظيفها، غالبًا ما تعطي عمليات التصيد الجماعي الأولوية للحجم على حساب الإتقان.

توحيد العناوين الثلاثة

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

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