آخرین اخبار
همهٔ اخبار
گزارش‌ها و تحلیل‌ها گزارش بحرانیت ۴/۱۰

تبدیل Claude Code به یک Implant کنترل‌پذیر از راه دور از طریق سرقت کلیدهای API

تبدیل Claude Code به یک Implant کنترل‌پذیر از راه دور از طریق سرقت کلیدهای API

در یک محیط آزمایشگاهی، امکان تبدیل Claude Code به یک Implant کنترل‌پذیر از راه دور (Remote-Controlled Implant) به اثبات رسید. این متد با بهره‌برداری از قابلیت Memory Stores در پلتفرم Claude، اجازه می‌دهد تا عامل کدنویسی (Coding Agent) هدایت شده و حجم زیادی از داده‌ها (به عنوان مثال یک فایل 1 گیگابایتی) از طریق Claude Files API استخراج شود.

مکانیزم حمله و بهره‌برداری

از آنجایی که تمامی دستورات و نتایج از طریق endpoint رسمی api.anthropic.com منتقل می‌شوند، ترافیک مهاجم کاملاً مشابه فعالیت‌های عادی یک عامل کدنویسی به نظر می‌رسد. این تکنیک برای اجرا به یک پیش‌نیاز دارد: مهاجم ابتدا باید به سیستم توسعه‌دهنده نفوذ کرده و کلیدهای API یا اعتبارنامه‌های کاربر را که معمولاً در فایل‌های تنظیمات یا تاریخچه Shell ذخیره شده‌اند، سرقت کند.

قابلیت Memory Stores مجموعه‌ای از فایل‌های متنی است که به فضای کاری (Workspace) متصل شده و به عامل‌های هوش مصنوعی اجازه می‌دهد اطلاعات را بین جلسات مختلف به خاطر بسپارند. این تحلیل نشان می‌دهد که می‌توان از طریق API، یک Store به فضای کاری اضافه کرد، حتی اگر سازمان از سرویس Managed Agents استفاده نکند.

شبیه‌سازی سناریوی حمله

در یک شبکه شبیه‌سازی شده Active Directory، مراحل زیر اجرا شد:

  • یک Payload کوچک، Claude Code را روی یک ماشین Linux شناسایی و اعتبارنامه‌ها را جمع‌آوری کرد.
  • یک سرویس systemd ایجاد شد تا فرآیندهای Claude Code را با فلگ --dangerously-skip-permissions اجرا کند؛ این فلگ باعث غیرفعال شدن درخواست‌های تأیید برای استفاده از ابزارها (Tool-use confirmation) می‌شود.
  • مهاجم از طریق Memory Store، دستوراتی را ارسال کرد تا شبکه محلی نقشه‌برداری شود، نام کارکنان و رمز عبور از یک FTP Share استخراج گردد و در نهایت با روش Password Spraying، یک حساب کاربری در Domain Controller شناسایی شود.
  • در نهایت، یک فایل 1 گیگابایتی از طریق SMB Share دانلود شده، به سه بخش تقسیم و از طریق Files API به سرورهای خارجی منتقل شد.

تحلیل ریسک و توصیه‌های امنیتی

این روش ناشی از یک آسیب‌پذیری (Vulnerability) در پلتفرم نیست، بلکه نتیجه توازن بین «قابلیت‌ها» و «سطح مواجهه» (Exposure) است. نکته کلیدی این است که کلیدهای API استاندارد دسترسی گسترده‌ای به Memory Stores دارند، در حالی که اعتبارنامه‌های OAuth محدودتر هستند.

برای کاهش این ریسک، توصیه‌های زیر ارائه می‌شود:

  • استفاده از OAuth: در هر کجا که پلتفرم اجازه می‌دهد، از OAuth یا Identity Federation استفاده کنید.
  • مدیریت کلیدها: کلیدهای API را کوتاه‌مدت (Short-lived) نگه دارید، دامنه دسترسی (Scope) آن‌ها را محدود کنید و از ذخیره آن‌ها در Environment Variables یا Dotfiles بپرهیزید.
  • مانیتورینگ رفتاری: SOCها باید فرآیندهای Agent را با ترافیک شبکه تولیدی آن‌ها تطبیق دهند. اجرای دستورات با آرگومان‌های غیرعادی یا تغییر ناگهانی در نسبت داده‌های ارسالی و دریافتی به API، نشانه‌های احتمالی نفوذ است.