التصيد الاحتيالي Phishing هو أسلوب خداع يحاول دفعك إلى تنفيذ إجراء يخدم المهاجم: إدخال كلمة مرور في صفحة مزيفة، مشاركة رمز تحقق، فتح ملف ضار، منح تطبيق صلاحيات إلى حسابك، تحويل أموال، أو الكشف عن معلومات حساسة.
ولا يقتصر التصيد على البريد الإلكتروني. فقد يصل عبر SMS، تطبيقات المراسلة، المكالمات الهاتفية، رموز QR، الشبكات الاجتماعية أو صفحات تظهر أثناء البحث على الويب. كما أن الرسالة لا تحتاج إلى أخطاء إملائية أو تصميم سيئ حتى تكون احتيالية؛ إذ تشير إرشادات NIST حول التصيد إلى أن الرسائل الحديثة قد تكون مقنعة جدًا، وأن الذكاء الاصطناعي يزيد سهولة إنتاج محتوى لغوي أكثر إقناعًا.
كيف يعمل التصيد الاحتيالي؟
تختلف التفاصيل بين حملة وأخرى، لكن الهجوم يعتمد عادة على ثلاث حلقات أساسية: الثقة، ثم الإجراء، ثم الاستفادة من النتيجة.
- ينتحل المهاجم صفة جهة يعرفها المستخدم أو يتوقع التعامل معها، مثل بنك أو متجر أو خدمة سحابية أو زميل عمل.
- يقدم سببًا مقنعًا للتصرف، مثل تسجيل دخول غير معتاد، فاتورة، طرد، ملف مشترك أو مشكلة في الحساب.
- يحاول دفع الضحية إلى فتح رابط أو ملف أو إجراء مكالمة أو تنفيذ طلب معين.
- يصل المستخدم إلى صفحة أو تفاعل يهدف إلى سرقة بيانات أو الحصول على صلاحية أو تشغيل محتوى ضار.
- يستغل المهاجم النتيجة للوصول إلى حساب، سرقة أموال، اختطاف جلسة، نشر برمجية خبيثة أو تنفيذ مرحلة أخرى من الهجوم.
لهذا لا يعني التصيد دائمًا «سرقة كلمة المرور». الهدف الحقيقي هو إقناع المستخدم بفعل شيء لم يكن ليفعله لو عرف هوية الطرف الآخر والغرض الفعلي من الطلب.
ما الفرق بين Phishing والهندسة الاجتماعية وMalware؟
التصيد أحد أشكال الهندسة الاجتماعية Social Engineering، لأن نجاحه يعتمد بدرجة كبيرة على التلاعب بالثقة والسياق واتخاذ القرار.
أما Malware أو البرمجيات الخبيثة فهي برمجيات أو شيفرات تنفذ نشاطًا ضارًا أو غير مصرح به. قد يستخدم المهاجم التصيد لتوصيل Malware، لكن التصيد يستطيع النجاح دون تثبيت أي برنامج؛ فقد تكفي صفحة مزيفة لسرقة بيانات الدخول.
كذلك لا يعني Spoofing الشيء نفسه. الانتحال قد يكون تقنية داخل هجوم تصيد، مثل جعل اسم المرسل يبدو تابعًا لشركة معروفة، بينما التصيد يصف عملية الخداع الأوسع التي تحاول دفع الضحية إلى إجراء معين.
أهم أنواع التصيد
| النوع | كيف يظهر عادة؟ | ما الذي يميزه؟ |
|---|---|---|
| Phishing | رسائل أو صفحات موجهة إلى عدد كبير من المستخدمين | يعتمد على طُعم يصلح لعدد واسع من الضحايا |
| Spear Phishing | رسالة مخصصة لشخص أو فريق معين | تستخدم معلومات عن الهدف لزيادة المصداقية |
| Smishing | SMS أو تطبيقات المراسلة | قد ينتحل شركة توصيل أو بنكًا أو خدمة رقمية |
| Vishing | مكالمة هاتفية أو صوتية | يعتمد على المحادثة والضغط المباشر على الضحية |
| QR Phishing | رمز QR في رسالة أو مستند أو مكان فعلي | يخفي الوجهة حتى يفتحها المستخدم على جهازه |
| OAuth Consent Phishing | طلب منح تطبيق صلاحيات إلى حساب | قد يستخدم صفحة تفويض شرعية بدل سرقة كلمة المرور |
Phishing وSpear Phishing
في التصيد التقليدي قد تُرسل الرسالة نفسها إلى عدد كبير من الأشخاص. أما Spear Phishing فيستهدف شخصًا أو مؤسسة بعينها ويستخدم تفاصيل تجعل الطلب أكثر ارتباطًا بالسياق، مثل اسم موظف أو مشروع أو مورد تتعامل معه الشركة.
وعندما يستهدف الهجوم مديرًا تنفيذيًا أو شخصًا يملك صلاحيات أو قدرة على الموافقة على تحويلات كبيرة، يُستخدم أحيانًا مصطلح Whaling، لكنه يظل شكلًا متخصصًا من التصيد الموجّه.
Smishing
يحدث عبر الرسائل النصية أو تطبيقات المراسلة. قد تدعي الرسالة وجود مشكلة في طرد أو عملية دفع أو حساب، ثم تطلب فتح رابط أو الاتصال برقم معين.
وجود الرسالة على الهاتف لا يجعلها أكثر موثوقية من البريد الإلكتروني. المعيار المهم هو هوية الطرف، والطلب الذي يحاول دفعك إليه، والوجهة التي ستفتحها.
Vishing
يعتمد Vishing على الاتصال الصوتي. قد يدعي المتصل أنه من البنك أو الدعم التقني أو مؤسسة تتعامل معها، ثم يطلب بيانات أو رمز تحقق أو إجراءً ماليًا.
أفضل وسيلة للتحقق من مكالمة حساسة هي إنهاؤها والاتصال بالجهة عبر رقم معروف لديك أو منشور في موقعها الرسمي، بدل استخدام رقم يقدمه المتصل نفسه.
QR Phishing
رمز QR ليس خبيثًا بحد ذاته؛ فهو مجرد وسيلة لنقل عنوان أو بيانات. الخطر هو الوجهة التي يقود إليها والسياق المستخدم لإقناعك بفتحها.
يمكن لرمز في بريد إلكتروني أو مستند أو ملصق أن يقود إلى صفحة تسجيل دخول مزيفة. لذلك لا تجعل استخدام QR سببًا لتجاوز عمليات التحقق التي كنت ستطبقها على رابط عادي.
OAuth Consent Phishing
لا تحتاج بعض الهجمات إلى معرفة كلمة المرور أصلًا. قد يحاول المهاجم إقناع المستخدم بالموافقة على تطبيق يطلب الوصول إلى البريد أو الملفات أو بيانات الحساب من خلال شاشة OAuth حقيقية.
في هذه الحالة تكون صفحة تسجيل الدخول نفسها شرعية، بينما المشكلة في التطبيق والصلاحيات التي يُطلب منحها له. راجع اسم التطبيق والناشر والصلاحيات والسبب الذي يجعله يحتاج إليها، ولا تعتبر وجودك داخل نطاق صحيح دليلًا كافيًا على أن الطلب آمن.
لماذا أصبحت رسائل التصيد أصعب في الاكتشاف؟
النصيحة القديمة التي تختزل اكتشاف التصيد في البحث عن الأخطاء الإملائية لم تعد كافية. يمكن للمهاجم إنشاء رسالة سليمة لغويًا، استخدام تصميم مشابه للخدمة الحقيقية، أو إرسال رسالة من حساب شرعي تعرّض للاختراق.
وتستطيع أدوات الذكاء الاصطناعي أيضًا مساعدة المهاجم على تحسين الأسلوب والترجمة والتخصيص. لذلك يجب أن ينتقل التركيز من سؤال «هل تبدو الرسالة احترافية؟» إلى أسئلة أكثر أهمية: من يطلب مني ماذا؟ ولماذا؟ وإلى أين يقود هذا الإجراء؟
كما توضح بعض الحملات الواقعية أن الهندسة الاجتماعية لا تقتصر على صفحات تسجيل الدخول. فقد استُخدمت أساليب مثل ClickFix في حملات مرتبطة ببرمجيات BeaverTail لإقناع المستخدم بتنفيذ إجراء على جهازه تحت غطاء إصلاح مشكلة مزعومة.
كيف تكتشف رسالة أو صفحة تصيد؟
لا توجد علامة منفردة تثبت أن الرسالة احتيالية. الأفضل هو تقييم مجموعة من المؤشرات والسياق المحيط بها.
- طلب غير متوقع: هل كنت تنتظر هذه الفاتورة أو الملف أو عملية إعادة تعيين كلمة المرور؟
- استعجال غير طبيعي: مثل التهديد بإغلاق الحساب فورًا أو المطالبة بتحويل مالي دون اتباع الإجراءات المعتادة.
- اختلاف النطاق: قد يبدو اسم الشركة صحيحًا بينما عنوان البريد أو نطاق الموقع مختلف.
- طلب معلومات حساسة: خصوصًا كلمة مرور أو رمز OTP أو بيانات بطاقة أو عبارة استرداد لمحفظة رقمية.
- تغيير تعليمات الدفع: مثل وصول رسالة مفاجئة تطلب إرسال الفاتورة إلى حساب بنكي مختلف.
- مرفق غير متوقع: خصوصًا عندما يستخدم المرسل سببًا غامضًا لدفعك إلى فتحه.
- طلب تجاوز إجراء معروف: كأن يطلب شخص يدعي أنه مدير تنفيذ تحويل دون الموافقات المعتادة.
- صلاحيات مبالغ فيها: تطبيق بسيط يطلب الوصول إلى البريد والملفات أو إدارة الحساب بالكامل.
افحص النطاق وليس شكل الصفحة فقط
يمكن نسخ الشعارات والخطوط والألوان بسهولة، لذلك قد تكون الصفحة المزيفة متقنة بصريًا.
تحقق من اسم النطاق نفسه قبل إدخال بيانات حساسة. ووجود HTTPS أو رمز القفل لا يثبت أن الشركة التي أمامك هي الجهة التي تدعيها الصفحة؛ HTTPS يؤمّن الاتصال بالنطاق الذي فتحته، لكنه لا يحول نطاقًا احتياليًا إلى موقع رسمي.
لا تستخدم الرابط نفسه للتحقق من الرسالة
إذا ادعت رسالة أن هناك مشكلة في حسابك المصرفي أو بريدك أو متجر تستخدمه، افتح التطبيق الرسمي أو اكتب عنوان الخدمة المعروف بنفسك بدل الاعتماد على الرابط الموجود في الرسالة.
وعند وجود طلب مالي أو إداري غير معتاد داخل مؤسسة، تحقق عبر قناة مستقلة مع الشخص أو الجهة المعنية.
هل يمكن للتصيد تجاوز المصادقة متعددة العوامل MFA؟
نعم، بعض أنواع MFA أقوى من غيرها. إذا أدخل المستخدم كلمة المرور ثم رمز OTP في موقع احتيالي في الوقت الحقيقي، فقد يحاول المهاجم تمرير هذه البيانات إلى الخدمة الأصلية قبل انتهاء صلاحية الرمز.
ولهذا تنص إرشادات NIST SP 800-63B-4 للمصادقة على أن طرق OTP التي تتطلب من المستخدم إدخال الرمز يدويًا لا تعد مقاومة للتصيد.
أما WebAuthn/FIDO2 فيستخدم مصادقة تشفيرية مرتبطة بالخدمة التي يسجل المستخدم الدخول إليها. وتوضح FIDO Alliance أن Passkeys المبنية على FIDO Authentication مصممة لتوفير مقاومة للتصيد لأنها تربط بيانات المصادقة بالخدمة أو النطاق الصحيح بدل تقديم سر يمكن إدخاله في موقع آخر.
هذا لا يعني أن Passkeys تحل كل مشكلات الأمان؛ فقد يبقى المستخدم معرضًا لخداع يتعلق باسترداد الحساب أو منح الصلاحيات أو الموافقة على معاملة. لكنها تقلل بصورة كبيرة خطر سرقة كلمة مرور ورمز يمكن إعادة استخدامهما على صفحة أخرى.
هل تحمي SPF وDKIM وDMARC من التصيد؟
تساعد SPF وDKIM وDMARC المؤسسات على التحقق من جوانب مرتبطة بهوية نطاق البريد ومنع بعض أشكال انتحال النطاقات.
- SPF: يساعد النطاق على تحديد مصادر البريد المسموح لها بالإرسال نيابة عنه.
- DKIM: يضيف توقيعًا تشفيريًا يمكن لخادم الاستقبال التحقق منه.
- DMARC: يربط نتائج المصادقة بالنطاق الظاهر للمستخدم ويتيح لصاحب النطاق نشر سياسة للتعامل مع الرسائل التي لا تحقق المتطلبات.
وتشرح وثائق Microsoft الخاصة بمصادقة البريد كيفية عمل هذه الآليات معًا للحد من انتحال المرسل.
لكن نجاح SPF أوDKIM أوDMARC لا يعني تلقائيًا أن مضمون الرسالة آمن. يستطيع المهاجم تسجيل نطاق يملكه وضبط المصادقة عليه بطريقة صحيحة ثم استخدامه في التصيد، كما قد تصل رسالة ضارة من حساب حقيقي تعرض للاختراق.
لذلك يجب اعتبار مصادقة البريد طبقة دفاع ضد أنواع محددة من الانتحال، لا شهادة تثبت حسن نية كل رسالة تصل إلى صندوق البريد.
كيف تحمي نفسك من التصيد؟
- استخدم كلمة مرور مختلفة لكل خدمة مع Password Manager موثوق.
- فعّل MFA للحسابات المهمة بدل الاعتماد على كلمة المرور وحدها.
- استخدم Passkeys أوFIDO/WebAuthn عندما توفرها الخدمة، خصوصًا للحسابات الحساسة.
- لا تدخل إلى الخدمات المالية أو الإدارية من روابط غير متوقعة في الرسائل.
- تحقق من الطلبات المالية وتغييرات الحسابات البنكية عبر قناة مستقلة.
- راجع التطبيقات المرتبطة بحساباتك واحذف ما لم تعد تحتاج إليه.
- راجع الأجهزة والجلسات المسجلة دوريًا، خصوصًا بعد أي نشاط مشبوه.
- حدّث المتصفح ونظام التشغيل والتطبيقات لتستفيد من أحدث طبقات الحماية.
- اترك ميزات الحماية من المواقع الخطرة مفعلة في المتصفح؛ فخدمات مثل Google Safe Browsing تحذر من عدد من مواقع التصيد والمحتوى الضار المعروف.
وليس المطلوب أن تتعلم حفظ شكل كل موقع احتيالي. الأفضل هو بناء عادة ثابتة: كل طلب حساس وغير متوقع يحتاج إلى تحقق مستقل قبل تنفيذه.
ماذا تفعل إذا فتحت رابط تصيد؟
فتح الصفحة وحده لا يعني بالضرورة أن الحساب أصبح مخترقًا. ما يجب فعله يعتمد على ما حدث بعد الفتح.
إذا فتحت الرابط ولم تدخل أي بيانات
- أغلق الصفحة.
- لا توافق على أي إشعار أو تنزيل أو صلاحية ظهرت منها.
- إذا تم تنزيل ملف، لا تشغله واحذفه بعد التحقق من مصدره.
- حدّث المتصفح والجهاز إذا كانا متأخرين عن التحديثات الأمنية.
إذا لم تدخل بيانات ولم تمنح صلاحية ولم تشغّل ملفًا، فالموقف يختلف جذريًا عن حالة تسريب كلمة مرور أو تنفيذ Malware.
إذا أدخلت كلمة المرور
- استخدم جهازًا موثوقًا وافتح الموقع الرسمي مباشرة.
- غيّر كلمة المرور المتأثرة.
- إذا استخدمت كلمة المرور نفسها في خدمات أخرى، غيّرها هناك أيضًا إلى كلمات مختلفة.
- راجع الأجهزة والجلسات المسجلة وألغِ أي جلسة لا تعرفها.
- راجع وسائل MFA وخيارات استرداد الحساب للتأكد من عدم تعديلها.
- في حساب العمل، أبلغ فريق الأمن أو تقنية المعلومات سريعًا.
إذا شاركت رمز OTP أيضًا
تعامل مع الحادث باعتباره أكثر خطورة من تسريب كلمة المرور وحدها. غيّر بيانات الدخول، وألغِ الجلسات المشبوهة، وراجع نشاط الحساب ووسائل المصادقة المسجلة.
إذا كانت الخدمة توفر خيار إبطال جميع الجلسات أو تسجيل الخروج من الأجهزة الأخرى، فقد يكون استخدامه ضروريًا لأن تغيير كلمة المرور وحده لا يضمن دائمًا إنهاء جلسة تم إنشاؤها بالفعل.
إذا وافقت على تطبيق OAuth مشبوه
ابحث في إعدادات الحساب عن التطبيقات أو الخدمات المتصلة، واسحب الصلاحيات من التطبيق المشبوه. بعد ذلك راجع النشاط والجلسات وسجلات الدخول المتاحة.
تغيير كلمة المرور وحده قد لا يعالج المشكلة إذا كان التطبيق ما يزال يملك Authorization Grant أوToken صالحًا.
إذا فتحت أو شغّلت ملفًا
هنا قد لا يعود الحادث مجرد تصيد، بل احتمال إصابة الجهاز ببرمجية خبيثة. افصل بين معالجة الحساب ومعالجة الجهاز، واتبع خطوات الكشف والاستجابة عند الاشتباه بوجود Malware بدل الاكتفاء بتغيير كلمة المرور.
إذا شاركت معلومات بنكية أو أرسلت أموالًا
تواصل مع البنك أو الجهة المالية عبر قنواتها الرسمية بأسرع ما يمكن، وراجع المعاملات والبطاقات والحسابات المتأثرة. وإذا ظهرت معاملات لا تعرفها، تعامل معها كحادث مالي مستقل، ويمكنك مراجعة العلامات والخطوات الموضحة في دليل اكتشاف اختراق الحساب البنكي والتصرف بعده.
كيف تحمي المؤسسات نفسها من التصيد؟
تدريب الموظفين مهم، لكنه لا ينبغي أن يكون خط الدفاع الوحيد. التصميم الأمني الجيد يفترض أن بعض الرسائل الاحتيالية ستصل وأن بعض المستخدمين قد يخطئون.
- استخدام أنظمة تصفية البريد والروابط والمرفقات.
- ضبط SPF وDKIM وDMARC بصورة صحيحة للنطاقات التي ترسل البريد.
- تطبيق مصادقة مقاومة للتصيد للحسابات ذات الحساسية العالية عندما يكون ذلك ممكنًا.
- تقليل الصلاحيات وفق مبدأ Least Privilege.
- فرض إجراءات مستقلة للتحقق من تحويل الأموال وتغيير بيانات الدفع.
- مراقبة عمليات تسجيل الدخول والجلسات وتغييرات وسائل المصادقة.
- مراجعة تطبيقات OAuth والصلاحيات الممنوحة لها.
- توفير Endpoint Protection وEDR للأجهزة المناسبة.
- إنشاء زر أو قناة واضحة وسريعة للإبلاغ عن رسائل التصيد.
- ربط التدريب بالأساليب التي تستهدف المؤسسة فعلًا بدل الاكتفاء بأمثلة قديمة وسهلة الاكتشاف.
وينبغي أن تتعامل المؤسسة مع نجاح عملية تصيد باعتباره حادث هوية محتملًا، لا مجرد رسالة بريد سيئة. السؤال المهم ليس فقط «هل تغيرت كلمة المرور؟»، بل أيضًا: هل أُنشئت جلسات؟ هل مُنحت صلاحيات؟ هل تغيرت وسائل الاسترداد؟ وهل استُخدم الحساب للوصول إلى مستخدمين أو أنظمة أخرى؟
مثال واقعي: لماذا لا يكفي أن يكون البريد من مصدر يبدو شرعيًا؟
توضح حملة PoisonSeed للتصيد كيف يمكن إساءة استخدام حسابات ومنصات بريد موثوقة بعد اختراقها للوصول إلى ضحايا جدد. الدرس الأهم ليس تفاصيل الحملة نفسها، بل أن عنوان المرسل أو الشكل الاحترافي للرسالة لا يمكن أن يكونا وحدهما أساس قرار أمني.
الطلب نفسه هو ما يجب فحصه: هل من الطبيعي أن تطلب هذه الجهة منك نقل أموال أو إدخال بيانات اعتماد أو استخدام عبارة استرداد أو اتخاذ إجراء حساس بالطريقة الموجودة في الرسالة؟
الخلاصة
التصيد الاحتيالي ليس مجرد بريد يحتوي على رابط مزيف، بل هجوم على الثقة وطريقة اتخاذ القرار. قد يستهدف كلمة المرور، أو رمز MFA، أو جلسة، أو صلاحيات OAuth، أو الأموال، أو يحاول دفع المستخدم إلى تشغيل Malware.
أفضل دفاع لا يعتمد على قدرة المستخدم على اكتشاف كل رسالة مزيفة من شكلها. استخدم مصادقة قوية ومقاومة للتصيد عندما تتوفر، كلمات مرور فريدة، ضوابط البريد والهوية، حماية الجهاز، وإجراءات تحقق مستقلة للطلبات الحساسة.
وعندما تصل رسالة مفاجئة تطلب منك إجراءً مهمًا، لا تجعل جودة التصميم أو اسم المرسل أو الشعور بالاستعجال يحدد قرارك. افتح الخدمة من مصدر تعرفه، تحقق من الطلب بصورة مستقلة، ثم تصرف.