عندما تصبح رسالة Docusign الموثوقة بوابة لسرقة جلسات Microsoft 365

قد تبدأ الحادثة برسالة تبدو طبيعية تماماً.

إشعار حقيقي صادر من Docusign، رابط يبدو مألوفاً، صفحة تسجيل دخول تشبه Microsoft 365 إلى حد يصعب معه ملاحظة الفرق، ثم يطلب النظام كلمة المرور ورمز MFA كالمعتاد.

لكن في الخلفية، لا يجري المستخدم عملية تسجيل دخول طبيعية.

بل يمر عبر خادم وسيط يتحكم به المهاجم، يراقب عملية المصادقة لحظة بلحظة، يمرر بيانات الاعتماد إلى Microsoft، ثم يستولي على الجلسة المصادق عليها بعد نجاح تسجيل الدخول.

هذه هي الفكرة التي تقف خلف منصة التصيد الجديدة NovaCookies، وهي خدمة Phishing-as-a-Service (PhaaS) تعتمد على هجمات Adversary-in-the-Middle (AitM) لسرقة جلسات Microsoft 365 حتى عندما يكون المستخدم محمياً بالمصادقة متعددة العوامل.

والأخطر أن المهاجم لا يحتاج دائماً إلى إرسال رسالة مشبوهة من نطاق عشوائي.

بل يستطيع بناء سلسلة هجوم تتكون بالكامل تقريباً من خدمات موثوقة في كل مرحلة: Docusign في البريد، وMicrosoft أو Google في إعادة التوجيه، وصفحة تسجيل دخول شبيهة بالخدمة الأصلية، ثم بنية تحتية خبيثة لا تظهر للمستخدم إلا في اللحظة الأخيرة.

#ما هي NovaCookies؟

NovaCookies هي منصة تصيد تجارية تُباع كنموذج اشتراك شهري مقابل نحو:

$320 / month

وتعمل كخدمة مُدارة بالكامل من نوع:

Phishing-as-a-Service (PhaaS)

بدلاً من أن يبني المهاجم خوادمه وأدواته وصفحات التصيد الخاصة به، يحصل على منصة جاهزة تشمل البنية التحتية، وإدارة الضحايا، وصفحات تسجيل الدخول، وآليات إعادة التوجيه، وخصائص تجاوز أنظمة التحليل والحماية.

وفقاً للباحثين، استُخدمت المنصة لاستهداف مئات المؤسسات في عدة دول، من بينها الولايات المتحدة والمملكة المتحدة وكندا وألمانيا وإسرائيل والإمارات.

كما تشير تحليلات أمنية إلى أن NovaCookies ترتبط من ناحية التطور التقني بعائلة:

Sneaky 2FA

إلا أن NovaCookies توسع النموذج إلى خدمة مُدارة مركزياً يمكن للمشتركين استخدامها دون الحاجة إلى تشغيل بنيتهم التحتية بأنفسهم.

#لماذا يمثل هذا النوع من التصيد مشكلة مختلفة؟

في التصيد التقليدي، يحاول المهاجم غالباً سرقة:

Username
Password
OTP

لكن بمجرد تفعيل MFA، يصبح امتلاك كلمة المرور وحدها غير كافٍ في كثير من الحالات.

هنا تظهر قيمة هجوم:

Adversary-in-the-Middle (AitM)

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

يمكن تصور التدفق بالشكل التالي:

Victim
   |
   v
Attacker-controlled AitM Proxy
   |
   v
Microsoft 365

عندما يكتب المستخدم بياناته، يمررها خادم المهاجم إلى Microsoft.

وعندما تطلب Microsoft رمز المصادقة متعددة العوامل:

MFA

يظهر الطلب نفسه للمستخدم.

بعد إدخال الرمز بنجاح، ترسل Microsoft جلسة مصادق عليها إلى المتصفح.

وهنا تكمن النقطة الجوهرية: خادم الـ AitM يستطيع التقاط معلومات الجلسة مثل:

Session Cookie
Authentication Token
Session Token

وبهذا لا يحتاج المهاجم إلى كسر MFA أو تخمين الرمز.

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

#كلمة المرور لم تعد الهدف الأساسي

في كثير من حملات التصيد الحديثة، لم تعد كلمة المرور هي الجائزة الأكثر قيمة.

الجائزة الحقيقية أصبحت:

Authenticated Session

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

هذا يغير طبيعة المخاطر بشكل جوهري.

فالمؤسسة قد تطبق:

Strong Password Policy
MFA
Conditional Access
Email Security

ومع ذلك يستطيع المهاجم تجاوز جزء مهم من الحماية إذا نجح في اعتراض الجلسة بعد إتمام المصادقة الشرعية.

#كيف تبدأ سلسلة الهجوم؟

إحدى أكثر حملات NovaCookies إثارة للاهتمام بدأت من خدمة موثوقة:

Docusign

بدلاً من انتحال عنوان مرسل مزيف، استخدم المهاجمون إشعارات Docusign حقيقية.

وهذا يعني أن البريد قد يجتاز العديد من اختبارات الثقة المعتادة لأنه صادر فعلياً من خدمة شرعية.

قد يرى المستخدم رسالة تحمل فكرة مشابهة لـ:

A document has been shared with you.

أو إشعاراً يدّعي أن قسم المحاسبة أرسل ملفاً متعلقاً بالدفعات أو التحويلات المالية.

المشكلة ليست في رسالة Docusign نفسها.

المشكلة تكمن في المستند أو الرابط الموجود داخل سير العمل الشرعي.

#إساءة استخدام الثقة بدلاً من كسرها

تعتمد كثير من أنظمة أمن البريد على مجموعة مؤشرات، مثل:

SPF
DKIM
DMARC
Sender Reputation
Domain Reputation
URL Reputation
Attachment Scanning

عندما يكون الإشعار صادراً من Docusign الحقيقي، يصبح جزء كبير من هذه المؤشرات سليماً من الناحية التقنية.

وهنا يظهر نموذج هجوم مهم جداً:

المهاجم لا يحتاج دائماً إلى انتحال الخدمة الموثوقة، بل قد يستخدم الخدمة الموثوقة نفسها لتوصيل المحتوى الخبيث.

وهذا يخلق فجوة بين مفهومين:

Trusted Sender

و:

Trusted Content

فالمرسل قد يكون شرعياً، بينما المحتوى الذي تم تمريره عبر الخدمة الشرعية خبيث.

#سلسلة الهجوم خطوة بخطوة

يمكن تبسيط إحدى سلاسل NovaCookies بالشكل التالي:

1. Genuine Docusign Notification
          |
          v
2. Fake Document-Sharing Lure
          |
          v
3. Legitimate Microsoft / Google Redirect
          |
          v
4. Attacker-Controlled Domain
          |
          v
5. NovaCookies AitM Proxy
          |
          v
6. Microsoft 365 Authentication
          |
          v
7. MFA Completed by Victim
          |
          v
8. Session Captured
          |
          v
9. Account Takeover

كل مرحلة من هذه المراحل قد تبدو طبيعية عند فحصها منفردة.

وهذه تحديداً إحدى نقاط قوة الهجوم.

#لماذا يصعب اكتشاف السلسلة؟

تصف الأبحاث هذه المشكلة بوضوح: كل خطوة قد تظهر داخل أداة أمنية مختلفة.

إشعار البريد يظهر في:

Email Security Gateway

عملية التصفح تظهر في:

Secure Web Gateway
Proxy
DNS Logs

المصادقة تظهر في:

Microsoft Entra ID
Identity Provider Logs

تسجيل الدخول إلى Microsoft 365 يظهر في:

Microsoft 365 Audit Logs

أما سلوك المتصفح الكامل فقد لا يظهر في أي من هذه الأدوات كحدث واحد مترابط.

وهنا يصبح التحدي دفاعياً وليس تقنياً فقط.

فالمؤسسة قد تمتلك جميع السجلات المطلوبة، لكنها لا تربط بينها زمنياً وسياقياً.

#خدعة إعادة التوجيه عبر OAuth

تستخدم بعض حملات NovaCookies أسلوباً يعتمد على إساءة استخدام عمليات إعادة التوجيه المرتبطة بـ:

OAuth

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

قد تصبح السلسلة مثلاً:

Docusign
   |
   v
Microsoft
   |
   v
Attacker Infrastructure

وجود نطاق Microsoft أو Google في منتصف السلسلة يرفع مستوى الثقة لدى المستخدم، وقد يربك بعض آليات التحليل الآلي التي تفحص كل عنوان بشكل منفصل.

#نطاقات تبدو مألوفة لكنها ليست Microsoft

لاحظ الباحثون أن عدداً من نطاقات NovaCookies استضاف صفحاتها تحت النطاق:

.vu

كما ظهرت تسميات داخل الروابط بأحرف متناوبة بين الكبيرة والصغيرة مثل:

PwPt-sHaRe
Ms36-AcCeSs
ClOd-ViEw

هذه الصياغات تحاول تقليد أسماء خدمات Microsoft بصرياً دون الحاجة إلى استخدام الاسم الحقيقي.

المستخدم الذي ينظر سريعاً إلى الرابط قد يلتقط كلمات مثل:

Share
Access
Cloud
Microsoft
365

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

#كيف يعمل الـ AitM تقنياً؟

الهجوم ليس مجرد صفحة HTML مزيفة.

الخادم الخبيث يعمل كوسيط حي بين المستخدم وخدمة Microsoft.

التدفق يكون تقريباً:

Victim Browser
      |
      | Credentials
      v
AitM Server
      |
      | Relayed Credentials
      v
Microsoft Login

ثم:

Microsoft MFA Challenge
      |
      v
AitM Server
      |
      v
Victim

وبعد نجاح المصادقة:

Microsoft
      |
      | Authenticated Session
      v
AitM Server
      |
      +--> Captured Session
      |
      v
Victim Browser

من منظور المستخدم، عملية تسجيل الدخول نجحت.

ومن منظور Microsoft، المستخدم أدخل بيانات صحيحة وأكمل MFA.

لكن من منظور المهاجم، أصبحت الجلسة نفسها تحت سيطرته.

#لماذا لا يكفي MFA التقليدي؟

من المهم التفريق بين مفهومين.

الأول:

MFA Bypass

والثاني:

MFA Session Theft

في حالة NovaCookies لا يحتاج المهاجم بالضرورة إلى كسر آلية المصادقة متعددة العوامل.

المستخدم نفسه ينفذ المصادقة.

لكن المهاجم يعترض الجلسة بعد نجاحها.

يمكن تلخيص الفرق:

ولهذا أصبحت ضوابط المصادقة المقاومة للتصيد أكثر أهمية من مجرد تفعيل MFA بأي طريقة.

#مقاومة التصيد ليست مساوية لتفعيل MFA

هناك فرق كبير بين:

MFA Enabled

و:

Phishing-Resistant MFA

آليات مثل رموز OTP يمكن للمستخدم إدخالها داخل صفحة وسيطة يسيطر عليها المهاجم.

أما الآليات المرتبطة بالمجال أو الجهاز والمصممة لمقاومة التصيد فتقلل فرص نجاح هذا النموذج.

من الأمثلة:

FIDO2
Passkeys
Windows Hello for Business
Certificate-Based Authentication

هذه التقنيات لا تعتمد فقط على سر يستطيع المستخدم كتابته في أي صفحة.

#Cloudflare كطبقة مضادة للتحليل

تتضمن NovaCookies خصائص مخصصة لتفادي أدوات الحماية والتحليل.

من بينها استخدام بوابات مرتبطة بـ:

Cloudflare

إضافة إلى آليات تستطيع اكتشاف بعض مؤشرات التشغيل المرتبطة بأدوات:

Debugging
Sandboxing
Automated Analysis
Security Scanners

الهدف واضح: عدم عرض صفحة التصيد الحقيقية لكل زائر.

قد يحصل المستخدم الحقيقي على صفحة تسجيل دخول Microsoft مزيفة، بينما يحصل محرك الفحص الآلي على صفحة مختلفة أو محتوى غير ضار.

ويُعرف هذا النوع من الأساليب غالباً بمفاهيم مثل:

Cloaking
Anti-Bot
Anti-Analysis
Traffic Filtering

#PhaaS: التصيد أصبح صناعة اشتراكات

NovaCookies ليست حالة معزولة.

النموذج الأوسع هو تحول التصيد من حملات فردية إلى صناعة خدمات.

المهاجم الذي لا يمتلك خبرة عميقة يستطيع الاشتراك في منصة توفر له:

Phishing Templates
AitM Infrastructure
Redirectors
Anti-Bot Controls
Credential Panels
Telegram Notifications
Victim Management
Session Capture

وهذا يخفض حاجز الدخول إلى الهجمات المعقدة.

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

اليوم يمكن شراء جزء كبير من هذه القدرات كخدمة شهرية.

#مقارنة بين بعض منصات التصيد الحديثة

المشهد هنا لا يتعلق بأداة واحدة.

بل بسوق متكامل من الخدمات الهجومية.

#من التصيد إلى الاستيلاء الكامل على الحساب

سرقة جلسة Microsoft 365 ليست نهاية الهجوم.

بل قد تكون بدايته.

بعد الحصول على جلسة صالحة، يستطيع المهاجم ـ بحسب الصلاحيات والضوابط المطبقة ـ محاولة الوصول إلى:

Outlook
Teams
SharePoint
OneDrive
Entra ID
Internal Applications
SaaS Platforms

ومن هناك قد تبدأ مراحل أخرى مثل:

Mailbox Search
Internal Reconnaissance
Business Email Compromise
Data Exfiltration
OAuth Abuse
Persistence
Privilege Escalation

ولهذا يجب التعامل مع سرقة الجلسة كحادثة هوية كاملة، وليس كمجرد حادثة تصيد بريد إلكتروني.

#أين تظهر مؤشرات الهجوم داخل بيئة Microsoft؟

بالنسبة لفريق SOC، لا يكفي البحث عن رسالة Docusign مشبوهة.

هناك مجموعة من المؤشرات السلوكية التي يجب ربطها، مثل:

New Sign-In Location
Unexpected ASN
Impossible Travel
Unusual User Agent
New Device
Token Replay
Session Reuse
Suspicious OAuth Activity
Mailbox Rule Creation
Unusual SharePoint Access
Abnormal OneDrive Download

كما أن تزامن تسجيلات الدخول من سياقات مختلفة خلال فترة قصيرة قد يكون أكثر أهمية من أي مؤشر منفرد.

مثلاً:

User Location: Riyadh
Successful MFA: 10:02
New Session: 10:03
Access Source: European VPS
Mailbox Search: 10:05
New Inbox Rule: 10:07

كل حدث منفرد قد يمتلك تفسيراً مشروعاً.

لكن اجتماعها كسلسلة زمنية يغيّر مستوى الخطورة بالكامل.

#الفرق بين Credential Theft وSession Theft

هذه المقارنة توضح لماذا لا ينبغي أن تتوقف الاستجابة عند إعادة تعيين كلمة المرور فقط.

#منظور GRC: أين تقع المشكلة الحقيقية؟

من زاوية Governance, Risk, and Compliance (GRC)، حادثة مثل NovaCookies تكشف أن وجود الضابط لا يعني بالضرورة فعاليته.

قد تذكر المؤسسة في سياساتها أنها تطبق:

MFA
Email Filtering
Secure Web Gateway
Identity Monitoring
Security Awareness

لكن السؤال الأكثر أهمية يصبح:

هل الضابط قادر فعلياً على مواجهة AitM وSession Theft؟

هذا ينقل النقاش من:

Control Exists

إلى:

Control Is Effective

وهو فرق جوهري في تقييم النضج الأمني.

#المخاطر المرتبطة بالهوية

يمكن تصنيف المخاطر التي تكشفها هذه الحملات ضمن عدة محاور:

#المشكلة ليست في Docusign وحدها

من الخطأ تفسير الحملة باعتبارها مشكلة مرتبطة بـ Docusign فقط.

نفس النموذج يمكن تطبيقه على خدمات شرعية كثيرة مثل:

Microsoft SharePoint
OneDrive
Google Drive
Dropbox
Notion
Adobe
DocuSign
Slack
Teams
GitHub

أي منصة تسمح بمشاركة محتوى أو إرسال إشعارات نيابة عن المستخدم قد تتحول إلى قناة توزيع إذا تمكن المهاجم من إساءة استخدامها.

#DOUBLOON DREDGER: إساءة استخدام Notion للغرض نفسه

في حملات أخرى، استُخدمت حسابات Notion لدعوة الضحية إلى مشاهدة ملف PDF.

الرسالة تصل عبر بنية تحتية موثوقة، والملف نفسه يحتوي رابطاً يقود إلى صفحة لجمع رموز المصادقة أو تنفيذ Device Code Phishing.

مرة أخرى يتكرر النمط نفسه:

Trusted Platform
        |
        v
Trusted Notification
        |
        v
Malicious Embedded Content
        |
        v
Token / Session Theft

الأداة تتغير.

لكن نموذج الثقة الذي يتم استغلاله ثابت.

#EvilTokens وتغير السوق بعد سرقة الرمز

تذهب بعض المنصات أبعد من مرحلة سرقة بيانات الاعتماد أو الجلسة.

منصات مثل:

EvilTokens

تحاول تحويل الوصول المسروق إلى عملية احتيال شبه مؤتمتة.

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

Inbox Analysis
Stakeholder Mapping
Fraud Target Identification
AI-Generated Messages
Business Email Compromise

وهذا يمثل تحولاً خطيراً في اقتصاد الجريمة الإلكترونية.

لم تعد الخدمة تبيع "صفحة تصيد".

بل أصبحت تبيع مراحل متتابعة من دورة الاختراق.

#من Credential Phishing إلى Compromise-as-a-Service

يمكن النظر إلى تطور هذه المنصات عبر مراحل:

Phase 1
Fake Login Page

ثم:

Phase 2
Credential Harvesting

ثم:

Phase 3
MFA / OTP Capture

ثم:

Phase 4
AitM Session Theft

ثم:

Phase 5
Token Abuse

ثم:

Phase 6
Automated Post-Compromise Operations

النتيجة هي أن السوق الإجرامي يتحول تدريجياً إلى مفهوم قريب من:

Compromise-as-a-Service

حيث تُباع سلسلة الاختراق كخدمة متكاملة.

#ما الذي يجب أن يبحث عنه فريق SOC؟

الاكتشاف الفعال يحتاج إلى دمج ثلاثة سياقات رئيسية:

Email
Identity
Browser / Network

الاعتماد على أحدها فقط قد يترك فجوات كبيرة.

#طبقة البريد

يُبحث عن:

Unexpected Docusign Notifications
Unusual Shared Documents
Embedded External Links
Redirect Chains
Newly Seen Domains
Suspicious TLDs

#طبقة الهوية

يُبحث عن:

Risky Sign-Ins
Impossible Travel
New ASN
New Device
Unfamiliar Browser
Token Replay
Abnormal Session Activity

#طبقة ما بعد الاختراق

يُبحث عن:

Mailbox Rule Creation
Mass Mail Search
Mass Download
OAuth Consent
New MFA Method
New Passkey
Forwarding Rule
External Share

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

#مثال على سيناريو كشف مترابط

يمكن أن يظهر السيناريو بالشكل التالي:

09:41 - User receives legitimate Docusign notification
09:44 - User clicks shared document
09:45 - Browser follows Microsoft redirect
09:45 - Connection to newly observed .vu domain
09:46 - Successful Microsoft 365 authentication
09:46 - MFA completed
09:48 - Same session observed from unfamiliar infrastructure
09:51 - Outlook mailbox search
09:54 - Inbox forwarding rule created
10:02 - OneDrive documents downloaded

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

#أثر الحملة على تصميم الضوابط

الحملات الحديثة مثل NovaCookies تفرض إعادة التفكير في بعض الافتراضات التقليدية.

الافتراض الأول:

Trusted Email Sender = Trusted Message

لم يعد صحيحاً دائماً.

الافتراض الثاني:

MFA Enabled = Account Protected

ليس كافياً أمام AitM.

الافتراض الثالث:

Known Microsoft URL in Redirect Chain = Safe

قد يكون مضللاً إذا كان الرابط جزءاً من سلسلة إعادة توجيه تنتهي لدى المهاجم.

الافتراض الرابع:

No Malware = Low Risk

خاطئ تماماً.

هذا النوع من الهجمات قد ينجح دون تشغيل ملف تنفيذي واحد على الجهاز.

#لماذا تمثل الهوية اليوم حدود الشبكة الجديدة؟

في البيئات التقليدية، كان التركيز الأكبر على:

Firewall
Network Segmentation
Endpoint Protection

أما في البيئات السحابية الحديثة، فقد يستطيع المهاجم الوصول إلى كمية ضخمة من البيانات من خلال حساب Microsoft 365 واحد فقط.

لذلك أصبحت الهوية نفسها بمثابة:

Security Perimeter

والجلسة المصادق عليها أصبحت أصلاً أمنياً حساساً يوازي كلمة المرور وربما يتجاوزها أهمية.

#من منظور إدارة المخاطر

ينبغي النظر إلى الخطر هنا باعتباره تراكباً بين عدة عوامل:

Likelihood
x
Identity Exposure
x
Cloud Privilege
x
Detection Gap
x
Session Lifetime

الحساب الذي لا يمتلك صلاحيات إدارية قد يظل شديد الخطورة إذا كان يمتلك وصولاً إلى:

Financial Email
Executive Communications
Sensitive SharePoint Sites
HR Records
Contracts
Procurement Data

لذلك تقييم الخطورة يجب ألا يعتمد فقط على كون المستخدم:

Admin

أو:

Standard User

بل على القيمة الفعلية للبيانات والعمليات التي يستطيع الوصول إليها.

#الضوابط الأكثر ارتباطاً بهذا النوع من الهجمات

#الاستجابة لحادثة Session Theft تختلف عن إعادة تعيين كلمة مرور

عند الاشتباه في سرقة جلسة Microsoft 365، فإن تغيير كلمة المرور وحده قد لا يكون الإجراء الكافي.

الاستجابة يجب أن تنظر إلى عناصر مثل:

Revoke Active Sessions
Revoke Refresh Tokens
Reset Password
Review MFA Methods
Review Passkeys
Review OAuth Grants
Review Mailbox Rules
Review Forwarding
Review Sign-In Logs
Review Audit Logs
Review SharePoint / OneDrive Activity

الهدف ليس فقط منع تسجيل دخول جديد.

بل قطع أي وصول نشط تم إنشاؤه بالفعل.

#ما الذي يجعل NovaCookies مهمة؟

أهمية NovaCookies لا تأتي من كونها أول أداة AitM.

هذا النوع من الأدوات موجود منذ سنوات.

لكنها تعكس ثلاثة تحولات واضحة في مشهد التهديدات.

الأول:

AitM is becoming commoditized.

الثاني:

Trusted SaaS platforms are becoming attack delivery infrastructure.

الثالث:

Post-compromise operations are becoming automated services.

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

#الخلاصة

NovaCookies ليست مجرد منصة تصيد جديدة تستهدف Microsoft 365.

هي مثال واضح على تغير طبيعة هجمات الهوية الحديثة.

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

يكفي أن يبني سلسلة تبدو موثوقة في كل خطوة:

Docusign
Microsoft Redirect
Microsoft 365 Login
MFA

ثم يضع نفسه بين المستخدم والخدمة في اللحظة المناسبة.

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

المشكلة إذن لم تعد:

هل لدينا MFA؟

بل أصبحت:

هل المصادقة لدينا مقاومة للتصيد؟

ولم تعد:

هل الرسالة قادمة من نطاق موثوق؟

بل:

هل نستطيع تتبع سلسلة الثقة كاملة من البريد إلى المتصفح إلى الهوية؟

وفي بيئة تعتمد بصورة متزايدة على Microsoft 365 وSaaS والهوية السحابية، قد تصبح الإجابة عن هذين السؤالين هي الفارق بين محاولة تصيد فاشلة، واستيلاء كامل على حساب المؤسسة.