🙍🏼 😄 🧓🏼 استخدام البرامج الضارة في Azure للوصول إلى مستأجري Microsoft 365 🔡 🛀🏽 👴🏽

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

الآن بعد أن انتقلت المؤسسات إلى Microsoft 365 بوتيرة سريعة ، نشهد ناقل هجوم جديد - تطبيقات Azure .

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

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

ما هي تطبيقات Azure؟

أنشأت Microsoft خدمة تطبيق Azure لتمكين المستخدمين من إنشاء تطبيقاتهم المستندة إلى مجموعة النظراء والتي يمكنها الاتصال بواجهة برمجة التطبيقات (API) والموارد الخاصة بـ Azure واستخدامها. يسهّل هذا إنشاء برامج مخصصة فعالة تتكامل مع نظام Microsoft 365 البيئي.

إحدى واجهات برمجة التطبيقات الأكثر شيوعًا في Azure هي MS Graph API . تسمح واجهة برمجة التطبيقات هذه للتطبيقات بالتفاعل مع بيئة المستخدم ، وهي: المستخدمون ، والمجموعات ، ومستندات OneDrive ، وصناديق بريد Exchange Online والدردشات.

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

كيف الهجوم

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

الرابط في البريد الإلكتروني يوجه المستخدم إلى موقع ويب يسيطر عليه المهاجمون (على سبيل المثال ، myapp.malicious.com ) ، والذي بدوره يعيد توجيه الضحية إلى صفحة تسجيل الدخول إلى Microsoft . تتم معالجة عملية المصادقة بالكامل بواسطة Microsoft ، لذا فإن استخدام المصادقة متعددة العوامل ليس حلاً.

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

إليك أذونات MS Graph API التي يطلبها المهاجم في رمز تطبيقنا:

كما ترى ، يتحكم المهاجم في اسم التطبيق ("MicrosoftOffice" ) والاختصار (استخدمنا اختصار OneNote). عنوان URL هو عنوان URL صالح لـ Microsoft ، كما أن الشهادة صالحة أيضًا.

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

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

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

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

تلقت الفرص

هذا الهجوم مثالي للأنشطة التالية:

الذكاء (الحصول على قائمة بالحسابات والمجموعات والأشياء في المستأجر المستخدم) ؛
التصيد الداخلي
سرقة البيانات من موارد الملف والبريد الإلكتروني.

لتوضيح قوة تطبيق Azure الخاص بنا ، أنشأنا وحدة تحكم مضحكة لعرض الموارد التي وصلنا إليها كجزء من اختبار PoC (إثبات المفهوم): يعرض

قسم "أنا" تفاصيل الضحية: سيعرض لنا

قسم "المستخدمون" البيانات الوصفية أعلاه لكل مستخدم فردي في مؤسسة ، بما في ذلك عنوان بريد إلكتروني ورقم هاتف جوّال والمسمى الوظيفي والمزيد ، اعتمادًا على سمات Active Directory للمؤسسة. يمكن أن تتسبب دعوة API وحدها في حدوث انتهاك كبير لسياسات حماية البيانات الشخصية ، خاصة في إطار اللائحة العامة لحماية البيانات و CCPA.

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

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

هام: عندما نصل إلى الملف من خلال واجهة برمجة التطبيقات هذه ، يقوم Azure بإنشاء ارتباط فريد. يمكن لأي شخص الوصول إلى هذا الرابط من أي مكان ، حتى إذا كانت المؤسسة لا تسمح بتبادل مجهول للروابط لمستخدمي 365 العاديين.
روابط API خاصة. بصراحة ، لسنا متأكدين من سبب عدم حظرهم بواسطة سياسة المؤسسة الخاصة بتبادل الروابط ؛ ربما لا تريد Microsoft كسر تطبيقات المستخدم الحالية إذا تغيرت السياسة. قد يطلب التطبيق رابط تنزيل أو رابط لتعديل الملف - في PoC لدينا طلبنا كليهما. يمنحنا

قسم "Outlook" حق الوصول الكامل إلى البريد الإلكتروني للضحية. يمكننا رؤية مستلمي أي رسالة ، وتصفيتهم حسب الأولوية ، وإرسال رسائل البريد الإلكتروني (التصيد الداخلي) وأكثر من ذلك بكثير.

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

علاوة على ذلك ، لدى Microsoft واجهة برمجة تطبيقات توفر معلومات حول دائرة الاتصال الحالية للضحية:

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

أحد الخيارات هو تحويل تطبيق Azure الضار إلى برنامج الفدية الذي يقوم بتشفير الملفات التي يمكن للضحية الوصول إليها لتعديلها على SharePoint و OneDrive:

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

مصادر أخرى:

قدم Kevin Mitnik طريقة تشفير قائمة على السحابة مماثلة تنطبق على صناديق البريد ؛
كتب Krebs On Security أيضًا منشورًا جيدًا حول مثل هذا الهجوم على مدونته.

إلحاح المشكلة

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

ماذا عن تعطيل جميع تطبيقات الطرف الثالث؟

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

كيف يمكنني اكتشاف إساءة استخدام تطبيقات Azure؟

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

اسأل نفسك دائمًا أسئلة:

هل أعرف هذا التطبيق؟
هل تنتمي إلى منظمة أعرفها؟

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

كيفية إزالة التطبيقات الضارة؟

في بوابة Azure ، انتقل إلى قسم "تطبيقات المؤسسة" في علامة التبويب "Azure Active Directory" وقم بإلغاء تثبيت التطبيقات. يمكن للمستخدم العادي حذف الأذونات الممنوحة سابقًا بالانتقال إلى myapps.microsoft.com ، والتحقق من التطبيقات المدرجة هناك وإلغاء الأذونات حسب الضرورة.

راجع إرشادات Microsoft الرسمية للحصول على تعليمات مفصلة .

استخدام البرامج الضارة في Azure للوصول إلى مستأجري Microsoft 365