تحلیل‌های جدید نشان می‌دهد که مهاجمان می‌توانند با فریب کاربران برای تأیید یک عامل هوش مصنوعی (AI Agent) جعلی، بخش‌هایی از محیط Microsoft 365 را تصاحب کنند. در این روش که BluePhishing نامیده شده است، هیچ رمز عبوری سرقت نمی‌شود و هیچ صفحه ورود (Login) جعلی برای فریب کاربر ساخته نمی‌شود. این تکنیک به‌طور مستقیم سیستم Microsoft Entra Agent ID را هدف قرار می‌دهد؛ سیستمی که به عامل‌های هوش مصنوعی اجازه می‌دهد در داخل Tenant ابری یک سازمان، هویت مستقل داشته باشند.
مکانیسم حمله BluePhishing
این روش بر پایه مفهوم شناخته‌شده OAuth consent phishing بنا شده است، اما آن را به دنیای عامل‌های هوش مصنوعی منتقل می‌کند. در حالی که در حملات سنتی، کاربر یک اپلیکیشن مخرب را تأیید می‌کند، در BluePhishing هدف، هویت‌های AI هستند که هنوز کنترل‌های امنیتی محدودی برای آن‌ها تعریف شده است.
مراحل اجرای این حمله به شرح زیر است:
- ایجاد Blueprint: مهاجم ابتدا یک Blueprint (الگوی عامل) در Tenant تحت کنترل خود می‌سازد و یک Client Secret به آن اضافه می‌کند.
- تنظیم دسترسی‌ها: با استفاده از PowerShell یا Microsoft Graph، تنظیمات signInAudience را به‌گونه‌ای تغییر می‌دهد که سازمان‌های دیگر نیز بتوانند آن را تأیید کنند. همچنین دسترسی‌های گسترده‌ای را به این الگو اختصاص می‌دهد.
- ارسال لینک تأیید: مهاجم لینک تأیید (Consent Link) را برای قربانی ارسال می‌کند. پس از کلیک و تأیید کاربر، یک Blueprint Principal در Tenant قربانی ایجاد می‌شود.
- دسترسی دائمی: این الگو به‌طور خودکار مجوز AgentIdentity.CreateAsManager را دریافت می‌کند که طبق تحلیل‌ها، قابل ابطال نیست. با این مجوز، مهاجم می‌تواند توکن‌های Graph را درخواست کرده و هویت‌های عامل (Agent Identities) متعددی را در محیط قربانی ایجاد کند.
چالش‌های شناسایی و دامنه اثر
شناسایی این نوع حملات برای تیم‌های SOC دشوار است زیرا:
- رفتار طبیعی: عامل‌های هوش مصنوعی ذاتاً به‌گونه‌ای طراحی شده‌اند که به‌طور مستقل عمل کنند، بنابراین فعالیت‌های آن‌ها در ابتدا عادی به نظر می‌رسد.
- عدم دیدرس (Visibility): مجوزهای ارث‌بری شده (Inherited Permissions) در پورتال Entra یا Microsoft Graph نمایش داده نمی‌شوند و تنها در زمان اجرا (Runtime) درون توکن‌ها قابل مشاهده هستند.
- مقیاس‌پذیری: در حالی که یک ثبت اپلیکیشن (App Registration) به یک Service Principal متصل است، یک Blueprint می‌تواند تا 250 هویت عامل ایجاد کند که دامنه اثر (Blast Radius) حمله را به‌شدت افزایش می‌دهد.
راهکارهای مقابله و پیشگیری
برای کاهش ریسک این تکنیک، اقدامات زیر توصیه می‌شود:
- آموزش کاربران: کارکنان باید در مورد خطرات تأیید مجوزهای عامل‌های شخص ثالث (Third-party Agents) آگاه شوند.
- محدود کردن Consent: اعمال محدودیت‌های سخت‌گیرانه برای تأیید مجوزهای Blueprintها و هویت‌های عامل.
- به‌کارگیری Least Privilege: استفاده از سیاست‌های Conditional Access و Entra ID Protection برای مدیریت عامل‌ها.
- پایش دقیق Logها: بررسی Audit Log برای شناسایی رویدادهای Add application (ایجاد Blueprint) و Add service principal (ایجاد هویت عامل).
شاخص‌های شناسایی (IoCs)
- مجوز مشکوک: وجود مجوز
AgentIdentity.CreateAsManagerروی Blueprint Principal. - تنظیمات خاص: مقدار
signInAudience = AzureADMultipleOrgsدر تنظیمات Blueprint. - رویدادهای Audit: ثبت رویدادهای ایجاد اپلیکیشن و Service Principal در بازه‌های زمانی مشکوک.
- دسترسی‌های مشاهده شده: درخواست مجوزهایی مانند
User.Read.AllوGroup.Read.Allتوسط عامل‌های جدید.
