أشهر الهجمات للمبتدئين: التصيد Phishing والفدية وسرقة الحسابات

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

وهذه ليست حالة نادرة، وإنما هي الشكل الأكثر شيوعاً لما يصيب الشركات الصغيرة. ففي التقرير السنوي لمركز شكاوى جرائم الإنترنت IC3 التابع للـ FBI لعام 2025، كان التصيد والانتحال Phishing/Spoofing أكثر أنواع الجرائم عدداً بـ 191,561 شكوى، وبلغ إجمالي الخسائر المبلغ عنها في السنة 20.877 مليار دولار بزيادة 26% عن 2024، وجاء احتيال البريد التجاري BEC وحده بخسائر تجاوزت 3 مليارات دولار. والمهم في هذه الأرقام أن أغلب هذه الهجمات لا تحتاج مهاجماً عبقرياً، وإنما تحتاج ضحية لا تعرف العلامات. وهذا المقال يعلمك هذه العلامات، ويريك بتجارب تعمل على جهازك كيف يفكر المدافع.

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

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

خريطة: من أين تدخل الهجمات؟

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

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

والسبب في أن المهاجم يفضل الإنسان على الآلة بسيط: الآلة لا تتعب ولا تستعجل ولا تخجل من سؤال مديرها، أما الإنسان فيمر عليه في اليوم عشرات الرسائل، ويعمل تحت ضغط الوقت، ويميل إلى إطاعة من يبدو صاحب سلطة، ويخاف من العواقب إذا تأخر. وعلم النفس وراء الهندسة الاجتماعية Social Engineering معروف: الاستعجال يعطل التفكير، والسلطة تفرض الطاعة، والخوف من الخسارة أقوى من الرغبة في الربح، والندرة («العرض ينتهي اليوم») تدفع للتسرع. ولهذا تبدأ كل رسالة تصيد ناجحة باستثارة واحد من هذه المشاعر، ثم تعطيك فعلاً واحداً سهلاً تفعله لتريح نفسك من القلق الذي زرعته. ومن يعرف هذا النمط يصبح أول سؤال يسأله أمام أي رسالة تستعجله: لماذا تريد مني هذه الرسالة أن أتصرف بسرعة قبل أن أفكر؟

الهجوم الأول: التصيد Phishing

التصيد في تصنيف MITRE ATT&CK رقم T1566 هو إرسال رسائل احتيالية للوصول إلى أنظمة الضحية، وكل أشكاله هندسة اجتماعية Social Engineering تصل إلكترونياً. والفكرة أن المهاجم لا يكسر القفل، وإنما يقنعك أن تفتحه بيدك: يرسل رسالة تبدو من جهة تثق بها (البنك، شركة الشحن، مزود الخدمة، أو مديرك)، فيها سبب يستعجلك، ورابط يأخذك إلى صفحة تشبه صفحة الدخول الحقيقية، فإذا كتبت كلمة مرورك ذهبت إليه مباشرة. وأخطر أنواعه التصيد الموجه Spearphishing الذي يستهدف شخصاً بعينه برسالة مكتوبة خصيصاً له، باسمه واسم مشروعه، فيصعب الشك فيها.

وكي تفهم لماذا ينجح التصيد تقنياً، تذكر أن البريد الإلكتروني صمم في زمن كان المرسلون فيه موثوقين، فبروتوكول SMTP الأصلي يسمح لأي خادم أن يكتب في حقل المرسل From أي عنوان يريد، تماماً كما تكتب أنت على ظرف ورقي أي اسم مرسل. ولهذا السبب جاءت لاحقاً سجلات SPF وDKIM وDMARC لتثبت أن الرسالة أرسلت فعلاً من خادم يملك النطاق، وهي ما يقرؤه حقل Authentication-Results في الرسالة. لكن حتى هذه السجلات لا تمنع المهاجم من شراء نطاق جديد يشبه نطاقك، وإعداد SPF وDKIM صحيحين له، فيمر فحص المصادقة بنجاح على نطاق مزيف. ولذلك لا تكفي علامة واحدة، ويبقى الحكم النهائي لمجموع العلامات، لا لواحدة منها.

وأشهر أنواع التصيد اليوم هو تصيد سرقة بيانات الدخول Credential Phishing: صفحة دخول مزيفة تطابق الأصلية في كل شيء، فإذا كتبت كلمة مرورك أرسلها الموقع المزيف إلى المهاجم مباشرة، وأحياناً يمررها فوراً إلى الموقع الحقيقي ليسجل دخولك فعلاً فلا تشك. والأخطر منه التصيد الذي يلتقط رمز المصادقة الثنائية أيضاً في اللحظة نفسها عبر وسيط Adversary-in-the-Middle، ولهذا السبب لا تحميك كل أنواع MFA بالدرجة نفسها، فمفاتيح المرور Passkeys ومفاتيح الأمان المبنية على FIDO2 ترتبط بالنطاق الحقيقي فلا تعمل على الصفحة المزيفة أصلاً، بينما رمز SMS يمكن التقاطه. والسؤال العملي: كيف تعرف رسالة التصيد قبل أن تضغط؟ الرسالة تحمل في العادة أكثر من علامة، وكل علامة وحدها قد تكون بريئة، لكن اجتماعها يكشفها. وسوف نكتب سكربتاً صغيراً يقرأ رسالة ويطبع علاماتها، لنرى بالضبط ما الذي يجب أن تنظر إليه.

تجربة عملية: سكربت يكشف علامات التصيد

سوف نصنع رسالتين بصيغة .eml، واحدة سليمة وواحدة تصيد، كلتاهما مصطنعة بنطاقات example فقط لا تخص أي جهة حقيقية، ثم نكتب سكربت Python يقرأ كل رسالة ويطبع العلامات المريبة. والهدف ليس بناء مرشح بريد كامل، وإنما أن ترى العلامات التي تبحث عنها عينك مكتوبة صراحة. أنشئ أولاً ملف make_mails.py الذي يكتب الرسالتين:

# رسالتان مصطنعتان بنطاقات example فقط: واحدة سليمة وواحدة تصيد
legit = """From: "Example Pay" <[email protected]>
To: [email protected]
Subject: Invoice INV-2026-1042 for October
Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
Content-Type: text/html; charset=utf-8

<p>Your invoice is available in the portal:
<a href="https://portal.example.com/invoices/1042">portal.example.com/invoices/1042</a></p>
"""
phish = """From: "Example Pay Support" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: URGENT: your account will be suspended today
Authentication-Results: mx.example.org; spf=fail smtp.mailfrom=examp1e-pay.net; dkim=none; dmarc=fail header.from=examp1e-pay.net
Content-Type: text/html; charset=utf-8

<p>We detected unusual activity. Verify your password within 2 hours or your account will be suspended:
<a href="https://xn--exmple-4nf.com/login">https://portal.example.com/login</a></p>
"""
open("/work/legit.eml", "w").write(legit)
open("/work/phish.eml", "w").write(phish)

ولاحظ في رسالة التصيد خمسة أشياء مزروعة عمداً: النطاق examp1e-pay.net فيه الرقم 1 مكان الحرف l، والرد يذهب إلى بريد مجاني مختلف، وفحوص المصادقة فشلت، ونص الرابط يظهر portal.example.com بينما وجهته xn--exmple-4nf.com، وهذا الأخير اسم نطاق مرمز بصيغة Punycode يعرضه المتصفح على شكل exаmple.com بحرف سيريلي а يشبه اللاتيني تماماً، وهو ما يسمى هجوم التشابه الحرفي Homograph. الآن نكتب السكربت الذي يكشف هذا كله، check_mail.py:

import sys, re, email, unicodedata
from email import policy
from html.parser import HTMLParser
URGENT = re.compile(r"urgent|suspend|within \d+ hours|verify your password|immediately", re.I)
class Links(HTMLParser):
    def __init__(s): super().__init__(); s.links = []; s.cur = None
    def handle_starttag(s, t, a):
        if t == "a": s.cur = [dict(a).get("href", ""), ""]
    def handle_data(s, d):
        if s.cur is not None: s.cur[1] += d
    def handle_endtag(s, t):
        if t == "a" and s.cur: s.links.append(tuple(s.cur)); s.cur = None
def host(u):
    m = re.match(r"https?://([^/]+)", u.strip()); return m.group(1).lower() if m else u.strip().split("/")[0].lower()
def show(h):                                    # يحول Punycode إلى شكله المعروض
    try: return h.encode().decode("idna") if "xn--" in h else h
    except Exception: return h
for path in sys.argv[1:]:
    m = email.message_from_file(open(path), policy=policy.default)
    frm = m["From"].addresses[0]; dom = frm.domain.lower(); flags = []
    if m["Reply-To"] and m["Reply-To"].addresses[0].domain.lower() != dom:
        flags.append(f"Reply-To goes to another domain: {m['Reply-To'].addresses[0].domain}")
    ar = str(m.get("Authentication-Results", ""))
    for k in ("spf", "dkim", "dmarc"):
        r = re.search(k + r"=(\w+)", ar)
        if r and r.group(1) != "pass": flags.append(f"{k}={r.group(1)}")
    if re.search(r"[0-9]", dom.split(".")[0]): flags.append(f"sender domain has digits that look like letters: {dom}")
    if URGENT.search(str(m["Subject"]) + m.get_body().get_content()): flags.append("pressure words")
    p = Links(); p.feed(m.get_body(("html", "plain")).get_content())
    for href, text in p.links:
        h, t = host(href), host(text)
        if t and "." in t and h != t: flags.append(f"link text shows {t} but goes to {h} ({show(h)})")
        if "xn--" in h:
            odd = [f"{c}={unicodedata.name(c)}" for c in show(h) if ord(c) > 127]
            flags.append(f"punycode domain {h} shown as {show(h)}; non-Latin letters: {odd}")
    print(f"== {path}: From {frm.display_name!r} <{frm.username}@{dom}>")
    print("   no warning signs" if not flags else "\n".join("   ! " + f for f in flags))

نشغلهما معاً في Container (وفي Git Bash على Windows أضف MSYS_NO_PATHCONV=1 واستخدم "$(pwd -W)"):

docker run --rm -v "$PWD":/work -w /work python:3.13.17-slim sh -c 'python3 make_mails.py && python3 check_mail.py legit.eml phish.eml'

والمخرج سوف يكون كما يلي:

== legit.eml: From 'Example Pay' <[email protected]>
   no warning signs
== phish.eml: From 'Example Pay Support' <[email protected]>
   ! Reply-To goes to another domain: freemail.example.net
   ! spf=fail
   ! dkim=none
   ! dmarc=fail
   ! sender domain has digits that look like letters: examp1e-pay.net
   ! pressure words
   ! link text shows portal.example.com but goes to xn--exmple-4nf.com (exаmple.com)
   ! punycode domain xn--exmple-4nf.com shown as exаmple.com; non-Latin letters: ['а=CYRILLIC SMALL LETTER A']

والصورة التالية تجمع العلامات السبع على الرسالة نفسها:

في المخرج أعلاه لاحظ التالي:

• الرسالة السليمة لم تحمل أي علامة، وهذا مهم: المرشح الذي ينبه على كل رسالة لا فائدة منه، فالمهم أن يميز.
• الحرف а في exаmple.com ليس الحرف اللاتيني a، وإنما حرف سيريلي اسمه CYRILLIC SMALL LETTER A، كشفه السكربت بفك ترميز Punycode ثم فحص كل حرف فوق النطاق اللاتيني. وهذا ما لا تراه عينك أبداً، ولذلك تعتمد المتصفحات والمعايير على قواعد مثل تقرير Unicode للأمان TR39 لرصد الأسماء المخادعة.
• فشل SPF وDKIM وDMARC علامة قوية، وقد شرحنا هذه السجلات الثلاثة في مقال شرح SPF وDKIM وDMARC، وهي ما يجعل انتحال نطاقك أصعب على المهاجم.
• السكربت قرأ الرسالة فقط ولم يتصل بأي رابط، وهذه قاعدة مهمة: لا تفتح رابطاً مشبوهاً لتفحصه، اقرأ وجهته دون أن تزورها.

وهناك خدعة شائعة لم نضعها في المثال لكن يجب أن تعرفها: الاسم المعروض Display Name. فالمهاجم يستطيع أن يجعل اسم المرسل الظاهر «الإدارة المالية» أو اسم مديرك الحقيقي، بينما العنوان الفعلي خلفه عنوان غريب تماماً. وكثير من تطبيقات البريد على الهاتف تعرض الاسم فقط وتخفي العنوان، فتثق بالاسم. ولذلك القاعدة: لا تثق بالاسم الظاهر أبداً، واضغط عليه لترى العنوان الحقيقي، فهو ما يفحصه السكربت حين يستخرج frm.username@dom من الحقل From لا من الاسم المعروض. والأمر نفسه ينطبق على الرابط: النص الذي تراه في الرسالة قد يكون أي شيء، والمهم وجهته الحقيقية التي يحملها الوسم href، وهي ما قارنه السكربت بالنص فكشف الاختلاف.

ولمن يريد التعمق، فإن ترويسات الرسالة Headers تحمل أكثر من ذلك: مسار الرسالة عبر الخوادم في حقول Received، وهوية الخادم الذي سلمها، وزمن كل خطوة. ومحلل الحوادث يقرأ هذه الترويسات ليعرف من أين أرسلت الرسالة فعلاً، لا من أين تدعي أنها أرسلت، وهذا تحقيق يبدأ من المكتبة القياسية نفسها email في Python التي استخدمناها، كما يشرح توثيقها الرسمي. ونحن اكتفينا هنا بالعلامات التي يراها المستخدم العادي، لأن الهدف أن تحمي نفسك لا أن تصبح محققاً، لكن معرفة أن هذه المعلومات موجودة تساعدك حين تحتاج أن تبلغ فريق الأمن برسالة مشبوهة: أرسلها كمرفق كامل بترويساتها، لا صورة لها، حتى يستطيع التحقيق.

والدفاع ضد التصيد ثلاث طبقات: طبقة تقنية تصعب الوصول (فحص البريد، وSPF وDKIM وDMARC على نطاقك، والمصادقة الثنائية التي تجعل كلمة المرور المسروقة غير كافية)، وطبقة بشرية (توعية مستمرة لا محاضرة سنوية، وزر إبلاغ سهل)، وطبقة تحد من الضرر (مدير كلمات مرور لا يملأ بياناتك إلا في النطاق الصحيح، فلا يعمل أصلاً على الصفحة المزيفة). ومحاكاة التصيد المصرح بها داخل مؤسستك لقياس الوعي موضوع مقال مستقل في المرحلة نفسها.

ولاحظ ميزة خفية في مدير كلمات المرور كطبقة دفاع: هو لا يتعب ولا يخدع بالمظهر، فهو يربط كل كلمة مرور بنطاقها الذي حفظت عليه، فإذا وصلتك رسالة تأخذك إلى exаmple.com بحرف سيريلي، فلن يعرض عليك المدير كلمة مرور example.com الحقيقية، لأنه يرى النطاقين مختلفين وإن تشابها لعينك. فحين يصمت مدير كلمات المرور ولا يعرض عليك الدخول في صفحة تعرفها، فتلك إشارة قوية أنك لست على الموقع الحقيقي. وهذه نقطة يغفل عنها كثيرون: المدير ليس أداة راحة فقط، بل أداة دفاع ضد التصيد تعمل حيث تخونك عينك. وقد شرحنا أنواع مديري كلمات المرور وكيف تختار لفريقك في مقالات مرحلة كلمات المرور.

الهجوم الثاني: سرقة الحسابات Account Takeover

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

• حشو بيانات الاعتماد Credential Stuffing (MITRE T1110.004): يأخذ المهاجم ملايين أزواج البريد وكلمة المرور المسربة من اختراق موقع آخر، ويجربها على موقعك. وبما أن كثيرين يستخدمون كلمة المرور نفسها في كل مكان، فإن نسبة صغيرة منها تنجح، وهي كافية. ومنظمة OWASP تصنفه من أكثر أسباب اختراق الحسابات اليوم.
• رش كلمات المرور Password Spraying (MITRE T1110.003): العكس، يجرب كلمة مرور شائعة واحدة مثل Password01 على آلاف الحسابات، فيتجنب قفل الحساب الذي يقع عند تكرار المحاولة على حساب واحد.

وحجم هذه القوائم يفسر لماذا ينجح الهجوم: حين تكون لديك مليارات كلمات المرور المسربة، فأنت لا تحتاج أن تخمن، وإنما تجرب ما سرق فعلاً. وتقدير أن نسبة 1% إلى 3% فقط من المحاولات تنجح يبدو صغيراً، لكن مع مليون محاولة يعني آلاف الحسابات المخترقة، وكل حساب منها قد يكون بوابة إلى غيره، أو إلى بريد يبدأ منه احتيال البريد التجاري، أو إلى خدمة يبدأ منها هجوم فدية. ولهذا تكون سرقة الحساب غالباً الخطوة الأولى لا الأخيرة.

ولاحظ الفرق بين الطريقتين في الدفاع: حشو بيانات الاعتماد يقطعه أمران، ألا تعيد استخدام كلمة المرور نفسها في موقعين (فكلمة المرور المسربة من موقع لا تفتح موقعاً آخر)، والمصادقة الثنائية (فكلمة المرور الصحيحة لا تكفي). أما رش كلمات المرور فيقطعه أن تمنع كلمات المرور الشائعة أصلاً، وأن تراقب محاولات الدخول الفاشلة الموزعة على حسابات كثيرة، لا على حساب واحد. وتنصح منظمة OWASP بمنع كلمات المرور المعروفة أنها مسربة بمقارنتها بقوائم التسريب، وهذا ما تفعله خدمات مثل التحقق من «هل تسربت كلمة مروري»، وهو ضابط يمنع المستخدم من اختيار كلمة مرور ظهرت في تسريب سابق.

وهذا يعيدنا إلى سؤالين يحددان مدى سهولة اختراق حساب: كم كلمة المرور قوية؟ وكيف يخزنها الموقع؟ والسؤالان مترابطان، فحتى لو اخترت كلمة مرور قوية، قد يخزنها الموقع بطريقة سيئة فتصبح سهلة التخمين لو سرقت قاعدته. ولنرى الفرق بأرقام حقيقية، سوف نقيسه بأنفسنا في مختبرنا، دون أن نمس أي حساب أو نظام حقيقي.

تجربة عملية: كم يصعب تخمين كلمة المرور؟

عندما يسرق المهاجم قاعدة بيانات موقع، لا يحصل على كلمات المرور نصاً عادياً في المواقع الجيدة، وإنما يحصل على بصماتها المخزنة Hashes، ثم يحاول أن يخمنها دون اتصال بالموقع Offline، فلا يوقفه قفل الحساب ولا حد المحاولات. وسرعة التخمين تعتمد على شيئين: قوة كلمة المرور (حجم المجال الذي يجب أن يجربه)، وطريقة التخزين (كم يكلفه حساب كل تخمين). وسوف نقيس تكلفة التخمين الواحد لثلاث طرق تخزين على كلمة مرور اختبارية نصنعها نحن. احفظ guess_cost.py:

import hashlib, os, time
SECRET = b"lab-only-test-password-2026"   # كلمة مرور اختبارية مخترعة
SALT = os.urandom(16)
def per_guess(label, fn, n):
    fn()                                   # تسخين
    t = time.perf_counter()
    for _ in range(n): fn()
    sec = (time.perf_counter() - t) / n
    print(f"{label:32} {sec*1e6:12,.2f} us/guess   {1/sec:14,.0f} guesses/sec/core")
    return sec
s_sha = per_guess("SHA-256 (fast hash, no salt)", lambda: hashlib.sha256(SECRET).digest(), 200_000)
s_pb  = per_guess("PBKDF2-HMAC-SHA256 x600000", lambda: hashlib.pbkdf2_hmac("sha256", SECRET, SALT, 600_000), 30)
s_scr = per_guess("scrypt N=2^14 r=8 p=1", lambda: hashlib.scrypt(SECRET, salt=SALT, n=2**14, r=8, p=1, maxmem=64*1024*1024), 30)
print(f"\nPBKDF2 is {s_pb/s_sha:,.0f}x slower per guess than raw SHA-256")
print(f"scrypt is {s_scr/s_sha:,.0f}x slower per guess than raw SHA-256")

نشغله بالأمر docker run --rm -v "$PWD":/work python:3.13.17-slim python3 /work/guess_cost.py، والمخرج:

SHA-256 (fast hash, no salt)             3.68 us/guess          271,626 guesses/sec/core
PBKDF2-HMAC-SHA256 x600000         986,846.31 us/guess                1 guesses/sec/core
scrypt N=2^14 r=8 p=1              140,924.27 us/guess                7 guesses/sec/core

PBKDF2 is 268,053x slower per guess than raw SHA-256
scrypt is 38,279x slower per guess than raw SHA-256

في المخرج أعلاه لاحظ التالي:

• البصمة السريعة SHA-256 تسمح بنحو 272 ألف تخمين في الثانية على نواة واحدة بلغة Python، وبأجهزة الرسوميات GPU يصل الرقم إلى مليارات في الثانية. ولهذا السبب تخزين كلمة المرور بـ SHA-256 وحدها خطأ: فهي سريعة لمن يخزن وسريعة لمن يخمن.
• الدالة PBKDF2 بـ 600 ألف تكرار، وهو الرقم الذي توصي به منظمة OWASP، جعلت كل تخمين أبطأ بنحو 268 ألف مرة. هذا هو معنى «تمديد المفتاح» Key Stretching: تدفع أنت جزءاً من الثانية مرة واحدة عند تسجيل الدخول، ويدفع المهاجم 268 ألف ضعف هذا الوقت في كل تخمين من مليارات.
• الدالة scrypt أبطأ بنحو 38 ألف مرة، وميزتها الإضافية أنها تستهلك ذاكرة كثيرة في كل تخمين Memory-Hard، وهذا بالضبط ما تصعب الرسوميات التي تجيد الحساب السريع لكن ذاكرتها محدودة، فرقم 38 ألف على المعالج يقلل من ميزة الرسوميات أكثر مما يبدو.

الآن نجمع العاملين: نفترض أن المهاجم يملك مليون نواة بسرعة هذه النواة (رقم نضعه صراحة لنقارن، لا قياس)، ونحسب متوسط الوقت لتخمين كلمة مرور من كل نوع:

والدرس من هذا الجدول أن الحماية طرفان لا طرف واحد: كلمة المرور الضعيفة تسقط في ثوان مهما كان التخزين جيداً إن كان بـ SHA-256، وكلمة المرور القوية تصمد قروناً، والتخزين الجيد (PBKDF2 أو scrypt أو Argon2) يضيف ثلاث إلى خمس مراتب من الصعوبة فوق ذلك. وما تملكه أنت كمستخدم هو الطرف الأول: كلمة مرور طويلة وفريدة لكل موقع. وما يملكه الموقع هو الطرف الثاني. ولذلك ينصح دليل NIST للهوية الرقمية SP 800-63B اليوم بكلمات مرور طويلة بدل القواعد المعقدة القديمة، ويفضل أربع كلمات تحفظها على ثماني محارف ترمزها. وتفاصيل كلمات المرور والمصادقة الثنائية موضوع المقالين التاليين مباشرة في هذه المرحلة:

لماذا تظهر المصادقة الثنائية MFA في كل دفاع؟

لاحظت أن المصادقة الثنائية تكررت في التصيد وسرقة الحساب وحتى BEC، والسبب أنها تعالج نقطة ضعف مشتركة بينها كلها: أن كلمة المرور شيء واحد يمكن سرقته ونقله واستخدامه من أي مكان في العالم. وفكرة MFA أن تطلب عاملين مختلفين من أنواع لا تسرق بالطريقة نفسها: شيء تعرفه (كلمة المرور)، وشيء تملكه (هاتفك أو مفتاح أمان)، وشيء أنت (بصمة أو وجه). فمن يسرق كلمة مرورك لا يملك هاتفك، فلا يكمل الدخول. ولهذا السبب كانت حادثة Snowflake كلها حسابات بلا MFA: العامل الثاني وحده كان سيقطع الحملة.

لكن ليست كل أنواع MFA متساوية في الحماية. فرمز الرسائل القصيرة SMS هو الأضعف، لأنه يمكن اعتراضه، ويمكن للمهاجم أن ينقل رقمك إلى شريحة يملكها بهجوم تبديل الشريحة SIM Swapping. ورمز التطبيق TOTP الذي يتغير كل ثلاثين ثانية أقوى، لكنه ما زال قابلاً للالتقاط إن خدعك موقع مزيف يطلبه منك في اللحظة نفسها. وأقوى الأنواع مفاتيح المرور Passkeys ومفاتيح الأمان FIDO2، لأنها ترتبط بالنطاق الحقيقي تقنياً، فلا تنتج توقيعاً صحيحاً على الصفحة المزيفة أصلاً، وهذا يجعلها مقاومة للتصيد بتصميمها لا بيقظة المستخدم. وتفاصيل هذه الأنواع وأيها تختار موضوع المقال التالي مباشرة في مرحلة كلمات المرور، لكن القاعدة الآن: أي MFA خير من لا شيء، والمقاوم للتصيد خير من رمز يمكن التقاطه.

الهجوم الثالث: الفدية Ransomware

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

• الدخول Initial Access: من ثغرة غير محدثة في خدمة مكشوفة للإنترنت، أو كلمة مرور مسربة، أو رسالة تصيد، أي أن الهجمات السابقة كثيراً ما تكون باب الفدية. ولهذا السبب لا يوجد «دفاع ضد الفدية» منفصل عن بقية الدفاع: من يغلق باب التصيد وسرقة الحساب والثغرات غير المحدثة يغلق أبواب الفدية نفسها قبل أن تصل خطوة التشفير أصلاً.
• التمدد Lateral Movement: ينتقل من الجهاز الأول إلى بقية الأجهزة عبر الثقة بينها والحسابات المشتركة، تماماً كما فعلت دودة Morris قديماً.
• تعطيل الاستعادة Inhibit Recovery (MITRE T1490): يحذف أو يشفر النسخ الاحتياطية ونقاط الاستعادة أولاً، لأنه يعرف أن النسخة السليمة هي عدوه الأول.
• تشفير البيانات Data Encrypted: يشفر الملفات دفعة واحدة ويترك رسالة الفدية.
• الابتزاز المزدوج Double Extortion: لأن النسخ الاحتياطية الجيدة جعلت كثيرين يرفضون الدفع، صار المهاجم ينسخ البيانات قبل تشفيرها ويهدد بنشرها، فتدفع لا لتستعيدها بل لئلا تفضح.

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

دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.

تجربة عملية: كيف يظهر التشفير الجماعي؟

كيف تكتشف أدوات الحماية أن ملفاتك تشفر الآن؟ إحدى الإشارات أن الملف المشفر يبدو عشوائياً تماماً، ومقياس العشوائية يسمى الفوضى Entropy، وهو عدد بتات المعلومة في كل بايت، من صفر (رتيب تماماً) إلى 8 (عشوائي تماماً). النص والجداول فوضاها منخفضة لأن فيها تكراراً، والبيانات المشفرة فوضاها قريبة من 8. نقيس ذلك بأنفسنا: نصنع ملف CSV، ثم نضغطه، ثم نشفره، ونقارن فوضى الثلاثة. احفظ entropy.py:

import sys, math, collections
for p in sys.argv[1:]:
    d = open(p, "rb").read()
    c = collections.Counter(d)
    h = -sum(n/len(d) * math.log2(n/len(d)) for n in c.values())
    print(f"{p:28} {len(d):>8} bytes  entropy {h:.3f} bits/byte")

docker run --rm -v "$PWD":/work -w /tmp python:3.13.17-slim sh -c '
python3 -c "
import random; random.seed(7)
rows=[\"id,name,city_code,amount\"]+[f\"{i},customer-{i},C{i%13},{random.randint(10,9000)}\" for i in range(1,4001)]
open(\"report.csv\",\"w\").write(\"\n\".join(rows))"
cp report.csv report-copy.csv
gzip -k report.csv
openssl enc -aes-256-cbc -pbkdf2 -salt -in report-copy.csv -out report-copy.csv.enc -pass pass:lab-only
python3 /work/entropy.py report.csv report.csv.gz report-copy.csv.enc'

report.csv                     106226 bytes  entropy 4.378 bits/byte
report.csv.gz                   33048 bytes  entropy 7.933 bits/byte
report-copy.csv.enc            106256 bytes  entropy 7.998 bits/byte

في المخرج أعلاه لاحظ التالي:

• فوضى ملف CSV 4.378 فقط، لأن فيه حروفاً وأرقاماً متكررة، وهذا شكل بياناتك العادية.
• فوضى الملف المشفر 7.998، أي قريبة جداً من الحد الأقصى 8، فلا تكرار فيه يميزه. وهذا ما تبحث عنه أدوات الكشف: ملفات كثيرة ترتفع فوضاها فجأة في وقت قصير إشارة قوية على تشفير جماعي.
• لاحظ أن الملف المضغوط gzip فوضاه عالية أيضاً (7.933)، ولهذا السبب لا يكفي ارتفاع الفوضى وحده للكشف، لأن الملفات المضغوطة والصور والفيديو عالية الفوضى طبيعياً. ولذلك تجمع الأدوات بين ارتفاع الفوضى وسرعة التغيير على عدد كبير من الملفات ونمط الوصول، لا الفوضى وحدها.

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

ماذا تفعل إذا أصابتك الفدية؟ وهل تدفع؟

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

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

الهجوم الرابع: احتيال البريد التجاري BEC

احتيال البريد التجاري Business Email Compromise هو أخطر الهجمات مالياً وأقلها ضجيجاً، فهو في تقرير IC3 لعام 2025 ثاني أكبر أنواع الاحتيال خسارة بأكثر من 3 مليارات دولار. والفكرة أن المهاجم لا يزرع برمجية خبيثة، وإنما يرسل رسالة تبدو من مدير أو مورد أو شركة عقارية، تطلب تحويلاً مالياً إلى حساب جديد، أو تغير تعليمات التحويل في صفقة جارية. ويذكر تقرير IC3 حالة موثقة من مارس 2025 لضحية كان يستكمل شراء عقار، فتلقى بريداً مخترقاً يبدو من «شركة التوثيق» يحمل تعليمات تحويل لأكثر من 1.3 مليون دولار إلى حساب احتيالي.

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

• قاعدة لا يكسرها استعجال: أي تغيير في بيانات حساب بنكي، أو أي تحويل فوق مبلغ محدد، يؤكد بقناة ثانية (مكالمة على رقم معروف مسبقاً، لا الرقم المكتوب في الرسالة).
• الانتباه إلى النطاقات المتشابهة: رسالة من moredir.com بدل mordir.com، وهو ما يكشفه السكربت الأول عندما يختلف نطاق الرد عن نطاق المرسل.
• المصادقة الثنائية على البريد: لأن كثيراً من BEC يبدأ باختراق بريد موظف أولاً، ثم المراقبة الصامتة لصفقة جارية، فالـ MFA على البريد يقطع الخطوة الأولى.
• صلاحيات التحويل: ألا يملك شخص واحد تنفيذ تحويل كبير بمفرده، فالموافقة المزدوجة ضابط سلامة بشري.

لماذا تنجح هذه الهجمات رغم شهرتها؟

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

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

الجانب السعودي والإبلاغ

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

فالضوابط الأساسية للأمن السيبراني ECC تعالج هذه الهجمات في أكثر من مكون: حماية البريد (المكون 2-4) تطلب تحليل الرسائل وتصفية التصيد والبريد المزعج والمصادقة متعددة العوامل للدخول عن بعد، وإدارة الهوية والوصول (المكون 2-2) تطلب المصادقة متعددة العوامل ومبدأ الحد الأدنى من الصلاحيات، والنسخ الاحتياطي والاستعادة (المكون 2-9) هو خط الدفاع ضد الفدية، والتوعية (المكون 1-10) هي الدفاع ضد الهندسة الاجتماعية. وإذا تعرضت جهتك لحادثة، فالإبلاغ عنها للهيئة الوطنية للأمن السيبراني جزء من الاستجابة، ونظام حماية البيانات الشخصية يلزم بإشعار الجهة المختصة عند تسرب البيانات. وقد شرحنا طريقة قراءة الضوابط في مقال الضوابط الأساسية NCA ECC بلغة بسيطة.

أخطاء شائعة Common Mistakes

• الاعتماد على كلمة المرور وحدها: حادثة Snowflake كلها كانت حسابات بلا MFA. المصادقة الثنائية هي أرخص ضابط يوقف أكثر الهجمات شيوعاً.
• فتح الرابط المشبوه لفحصه: زيارة الصفحة قد تكفي لبعض الهجمات، والأدق قراءة وجهة الرابط دون زيارتها، كما فعل السكربت.
• الثقة بالمظهر: شعار صحيح واسم مدير حقيقي لا يثبتان شيئاً، فالانتحال يبدأ بالمظهر. تحقق من النطاق ومن القناة الثانية.
• نسخ احتياطية متصلة دائماً: النسخة التي يصل إليها السيرفر المصاب يحذفها المهاجم. اجعل نسخة معزولة وغير قابلة للتعديل.
• تخزين كلمات المرور بـ SHA-256 أو MD5: رأينا أنها سريعة للمخمن. استخدم Argon2 أو scrypt أو PBKDF2 بعدد تكرار كاف.
• ظن أن BEC مشكلة تقنية: لا يمسكه مرشح البريد غالباً، وإنما إجراء التحقق من التحويلات.
• تجاهل التوعية لأنها لا تقاس: ثلاث من الهجمات الأربع تستهدف الإنسان، ومن لا يدرب فريقه يترك أوسع باب مفتوحاً.

قائمة تحقق: الخطوات الثلاث التي تغطي الأكثر

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

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

الخلاصة

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

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

تدريب عملي Practice

• زد في سكربت التصيد علامة سابعة: نبه إذا كان نص الرابط نفسه نطاقاً مختلفاً عن نطاق المرسل، واختبره برسالة ثالثة تصنعها.
• عدل سكربت تكلفة التخمين ليجرب كلمة مرورك الحقيقية بطولها (دون كتابتها، بتمرير طولها ونوع محارفها فقط)، واحسب كم تصمد لو خزنت بـ SHA-256 ولو خزنت بـ PBKDF2.
• افتح آخر خمس رسائل في بريدك فيها رابط، وطبق العلامات السبع عليها يدوياً قبل أن تضغط أي رابط.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتشغيل تجارب التصيد وتكلفة التخمين والفوضى على python:3.13.17-slim، ومراجعة تقرير IC3 2025 وتقنيات MITRE ATT&CK وتوصيات OWASP وNIST.