-
نویسنده:
خلاصه اجرایی
این پژوهش تکنیکهای پس از بهرهبرداری را نشان میدهد که میتواند به مهاجمی با دسترسی ریشه روی یک گره Kubernetes که به خطر افتاده است اجازه دهد از یک استاندارد باز و پیادهسازی مرجع برای هویت ماشین با نام SPIFFE/SPIRE سوءاستفاده کند تا هویت بارهای کاری هممکان را جعل کند و SVIDهای SPIFFE را گردآوری کند. نشان میدهیم که فرض اعتماد در هسته هر سامانه هویت ماشین — اینکه گره مورد اعتماد است — زمانی که مهاجم روی آن گره به دسترسی ریشه دست یابد فرو میریزد. گروه Unit 42 تاکنون مشاهده نکرده است که از این تکنیک در حملات واقعی سوءاستفاده شده باشد.
چارچوب Secure Production Identity Framework for Everyone (SPIFFE)/محیط اجرایی SPIFFE با نام SPIRE بهطور گسترده در Kubernetes و محیطهای cloud-native بهکار گرفته شده است تا رازهای بلندعمر را با هویتهای بار کاری کوتاهعمر که بهصورت رمزنگاریشده قابل اعتبارسنجی هستند جایگزین کند.
پژوهش ما نشان میدهد چگونه مهاجمی با دسترسی ریشه میتواند اطلاعات گروه کنترل Linux (cgroup) را که ایجنت SPIRE در جریان تصدیق بار کاری از آن استفاده میکند جعل کند. این کار ایجنت را فریب میدهد تا SVID یک بار کاری هممکان را برای فرایندی که در کنترل مهاجم است صادر کند.
بهعنوان بخشی از این پژوهش، ابزار Spooffe را توسعه دادیم؛ یک ابزار منبعباز که مدافعان میتوانند با آن بیازمایند آیا مهاجمی با دسترسی مدیریتی میتواند فرادادههای cgroup را دستکاری کند تا هویتهای بارهای کاری هممکان را بازیابی کند و دامنه تأثیر هویتی حاصل را ارزیابی کند.
هنگام طراحی مدلهای تهدید برای SPIFFE/SPIRE، سازمانها باید فرض کنند که دسترسی در سطح ریشه به یک گره، دسترسی به تمام هویتهای رمزنگاریشدهای را که در حوزه همان گره قرار دارند فراهم میکند. توصیه میکنیم برای کاهش میزان در معرض بودن، اقدامات زیر را انجام دهید:
- گرهها را سختسازی کنید.
- دسترسی ریشه را محدود کنید.
- از اجرای کانتینرهای privileged و دسترسی به میزبان جلوگیری کنید.
- اتکا به selectorهای ضعیف را به حداقل برسانید.
مشتریان شرکت Palo Alto Networks از طریق محصولات و خدمات زیر در برابر تهدیدهای توصیفشده در اینجا بهتر محافظت میشوند:
اگر فکر میکنید احتمالاً به خطر افتادهاید یا موضوعی فوری دارید، با Unit 42 Incident Response team تماس بگیرید.
مقدمه
SPIFFE یک استاندارد باز برای هویت ماشین است که برای حل مسئله «Secret Zero» — چالش معرفی امن راز اولیه موردنیاز برای راهاندازی اولیه اعتماد — طراحی شده است و این کار را با جایگزینی رازهای بلندمدت با هویتهای بارکاری کوتاهعمر انجام میدهد. در صورت استقرار صحیح، SPIFFE مرزهای هویتیِ محکمی میان بارکاریها اعمال میکند.
با این حال، این تضمینها بر یک فرض اصلی که میان همه سامانههای هویت مشترک است تکیه دارند و آن اینکه نودِ زیرساخت مورد اعتماد باشد. اگر مهاجم به دسترسی روتِ یک نود برسد، میتواند با سازوکارهای هویت تعامل کند و همه هویتهایی را که برای آن نودِ بهخطرافتاده مجاز شدهاند بازیابی کند.
پژوهش ما بررسی میکند که مهاجمان چگونه میتوانند از دسترسی روت سوءاستفاده کنند تا هویتهای بارکاری را از یک نودِ بهخطرافتاده برداشت کنند. در این نوشته، ابتدا با توضیح هویت ماشین و اینکه SPIFFE چگونه در محیطهای کلاد نیتیو اعتماد را برقرار و راستیآزمایی میکند، مبنا را فراهم میکنیم. سپس جعل هویت بارکاری از طریق جعل selector را نشان میدهیم. در نهایت، Spooffe را معرفی میکنیم؛ ابزاری که برای خودکارسازی استخراج این هویتهای بارکاری (SVIDs) ساختهایم.
یادداشت برای خوانندگان: اگر از پیش با مفاهیم و معماری SPIFFE/SPIRE آشنا هستید، میتوانید مستقیماً به بخشهای تصدیق بارکاری و Agent چگونه بارکاری را تصدیق میکند بروید.
مروری بر SPIFFE
سناریویی را در نظر بگیرید که در آن دو برنامه، یک فرانتاند و یک بکاند، باید بهصورت ایمن با یکدیگر ارتباط برقرار کنند.
میتوان جفتکلید تولید کرد و کلیدهای عمومی را مبادله نمود تا از طریق Mutual Transport Layer Security (mTLS) ارتباط برقرار شود، اما این گزینه چند پرسش اساسی ایجاد میکند:
- چه کسی آن کلیدها را بهصورت دورهای تعویض میکند؟
- اگر برنامه به خطر بیفتد، چه کسی آنها را ابطال میکند؟
- آیا میتوانیم راستیآزمایی کنیم چه کسی یا چه چیزی کلیدها را ارائه میکند؟
SPIFFE این مسائل را با استانداردسازی نحوه نامگذاری ماشینها و نحوه صدور اعتبارنامههای کوتاهعمر برطرف میکند.
اصطلاح «ماشینها» به دو دسته کلی اشاره دارد:
- بارکاریها: کانتینرها، فرایندها و سرویسهایی که منطق برنامه را اجرا میکنند.
- دستگاهها: اندپوینتهایی مانند رایانههای رومیزی، دستگاههای همراه و سامانههای اینترنت اشیا (IoT) یا فناوری عملیاتی (OT).
- (توجه: هویت دستگاه بخشی از مشخصات هسته SPIFFE نیست.)
مؤلفههای هویتی SPIFFE
به هر بارکاری سه مؤلفه هویتی تخصیص داده میشود:
- شناسه SPIFFE: اینکه چه کسی هستید (نام شما).
- هویت قابلاعتبارسنجی SPIFFE (SVID): اثبات اینکه همان هستید که ادعا میکنید (اعتبارنامههای شما).
- بسته اعتماد: روشی که دیگران بهوسیله آن راستیآزمایی میکنند که یک مرجع مورداعتماد اعتبارنامه شما را صادر کرده است.
اکنون کمی با جزئیات بیشتر به هر یک از اینها میپردازیم.
شناسه SPIFFE یک نام قراردادی برای هویت یک بارکاری است که از قالب شبیه URI به شکل spiffe://<trust-domain>/<path> پیروی میکند (شکل 1).
بخش میانی (example[.]com) در شکل 1 دامنه اعتماد است؛ صادرکننده هویت که بهعنوان یک مرز امنیتی عمل میکند.
در این شیوه، بارکاریها میتوانند دارای هویت باشند و بدانند با چه کسی باید ارتباط برقرار کنند.
با این حال، هویت بهتنهایی تضمینکننده اعتماد یا امنیت نیست؛ بنابراین «سند هویت قابلاعتبارسنجی SPIFFE» (SVID) را میافزاییم. این یک اعتبارنامه کوتاهعمر است که یک بارکاری برای اثبات هویت خود ارائه میکند. این سند بهصورت رمزنگاریشده توسط سرور مرجع گواهی (CA) امضا میشود و همواره شناسه SPIFFE مربوط به بارکاری را دربر میگیرد.
دو قالب اصلی برای SVID وجود دارد:
- نوع X.509 در SVID: گواهیای با کلید عمومی تعبیهشده که معمولاً برای mTLS بهکار میرود.
- نوع JSON Web Token (JWT) در SVID: یک توکن JWT امضاشده که بهعنوان bearer token برای مجوزدهی در سطح برنامه استفاده میشود.
در نهایت، بسته اعتماد را داریم که مجموعهای از ریشههای اعتماد — گواهیهای ریشه CA یا JSON Web Key Setها (JWKS) — است. اینها برای راستیآزمایی اینکه یک مرجع مورداعتماد یک SVID را در یک دامنه اعتماد صادر کرده است بهکار میروند.
برای درک اینکه این مؤلفههای هویتی در عمل چگونه صادر و اعتبارسنجی میشوند، ابتدا باید به معماری SPIRE و مؤلفههای اصلی زماناجرای آن نگاه کنیم.
معماری SPIRE
نرمافزار SPIRE یک پیادهسازی آماده بهرهبرداری از مشخصه SPIFFE است. با وجود چندین پیادهسازی، ما برای این پژوهش SPIRE را برگزیدیم؛ زیرا بهصورت گسترده در محیطهای Kubernetes استقرار یافته است و استاندارد SPIFFE را بهطور کامل پیادهسازی میکند. علاوه بر این، چون SPIRE متنباز است، میتوانیم درونیات آن را بررسی کنیم تا دریابیم این مشخصه در عمل چگونه کار میکند.
ساختار SPIRE از چند جزء ساده تشکیل شده است (مطابق شکل 2 در زیر):
- بارکاری: یک جزء نرمافزاری منفرد که برای انجام کاری مشخص استقرار یافته است (برای نمونه، یک process، یک container، یا یک pod).
- سرور SPIRE (control plane): این CA ورودیهای ثبت را ذخیره میکند. همچنین SVIDها را صادر و بهصورت رمزنگاریشده امضا میکند. افزون بر این، بسته اعتماد را برای دامنه اعتماد منتشر میکند.
- ایجنت SPIRE: این مؤلفه روی هر گره محاسباتی اجرا میشود (برای نمونه، یک گره Kubernetes، یک VM یا یک میزبان bare-metal). فعالیتهای زیر را انجام میدهد:
- درخواستها را از بارکاریها بهصورت محلی از طریق Workload API (UNIX socket) میپذیرد.
- از طریق Node API با سرور ارتباط برقرار میکند.
- تصدیق را انجام میدهد.
- در حافظه نهان، SVIDها را ذخیره میکند.
- چرخش را مدیریت میکند.
با در نظر داشتن معماری SPIRE، اکنون میتوانیم گامبهگام مرور کنیم که تأیید هویت بارکاری-به-بارکاری از ابتدا تا انتها چگونه کار میکند.
جریان تأیید هویت بارکاری-به-بارکاری
هنگامی که بارکاری A نیاز دارد از طریق mTLS با بارکاری B ارتباط برقرار کند، یک اعتبارنامه کوتاهعمر از ایجنت محلی SPIRE درخواست میکند. ایجنت بارکاری را تصدیق میکند و دادههای تصدیق را به سرور SPIFFE ارسال میکند. بر اساس خطمشیهای ثبت ازپیشتعریفشده، سرور شناسه SPIFFE مناسب را برای بارکاری انتخاب میکند و یک SVID از نوع X.509 با عمر کوتاه صادر میکند.
سرور همچنین کلیدهای عمومی متناظر را بهعنوان بخشی از بسته اعتماد منتشر میکند.
وقتی بارکاری A یک اتصال را آغاز میکند، SVID خود را در جریان دستدهی mTLS ارائه میکند. بارکاری B با اعتبارسنجی امضا در برابر بسته اعتماد، بررسی انقضای گواهی، و اطمینان از انطباق شناسه SPIFFE با هویت مورد انتظار، SVID را راستیآزمایی میکند.
اگر این بررسیها موفق باشند، بارکاری B میتواند بهصورت رمزنگاریشده بارکاری A را احراز هویت کند و یک اتصال امن برقرار کند. این امر ارتباط بارکاری-به-بارکاری مبتنی بر هویت را بهجای تکیه بر اسرار بلندمدت ممکن میسازد (شکل 3).
جریان هویتی که در بالا توصیف شد به تصدیق وابسته است؛ فرایندی که طی آن SPIRE تعیین میکند آیا یک بارکاری مجاز است هویت دریافت کند یا خیر. SPIRE در دو سطح تصدیق انجام میدهد:
- تصدیق گره، اعتماد به ایجنتی را که روی یک گره اجرا میشود برقرار میکند.
- تصدیق بارکاری، هویت بارکاریهای منفرد را تعیین میکند.
در این مطلب، بر اعتبارسنجی بارکاری تمرکز میکنیم، زیرا این سازوکار مستقیماً در ارزیابی selectorها و حملاتی که بعداً بررسی میشوند نقش دارد.
اعتبارسنجی بارکاری
پیش از آنکه agent workloadها را اعتبارسنجی کند، مدیر SPIRE server باید selectorهای workload را در SPIRE server ثبت کند تا بعداً بتوان آنها را با selectorهای موجود در agent مقایسه کرد.
در این نمونه Kubernetes، مدخل ثبتشده هر podای را که در namespace default اجرا میشود و از service account default استفاده میکند، مجاز میکند تا هویت مشخصشده SPIFFE (spiffeID) را دریافت کند.
رکورد حاصل بهصورت زیر در SPIRE server ذخیره میشود:
SPIRE agent بهصورت دورهای این مدخلهای ثبت را با سرور همگامسازی و در cache نگهداری میکند و هنگام اعتبارسنجی بارکاری، برای تعیین اینکه کدام هویت قابل اعمال است، آنها را بهصورت محلی بهکار میگیرد. این agent برای هر مدخل ثبت، یک جفتکلید تولید میکند، درخواستهای امضای گواهی (CSR) را به سرور میفرستد و SVIDهای حاصل را در cache ذخیره میکند.
هنگامی که یک workload قصد احراز هویت دارد، از طریق Workload API از agent یک هویت درخواست میکند (شکل 4، گام 1). این agent با گردآوری selectorها از فرایند workload و تطبیق آنها با مدخلهای ثبت cacheشده، اعتبارسنجی بارکاری را انجام میدهد (شکل 4، گام 2).
در صورت تطبیق موفق (شکل 4، گام 3)، ایجنت موارد زیر را بازمیگرداند:
- شناسه SVID مبتنی بر X.509
- کلید خصوصی
- بسته اعتماد
توجه: این مثال بر پایه یک درخواست X.509 SVID است. برای درخواستهای JWT SVID، ایجنت تنها یک توکن JWT امضاشده بازمیگرداند.
با در نظر داشتن جریان سطحبالا، اکنون میتوان بررسی کرد که اعتبارسنجی در عمل چگونه کار میکند.
چگونه ایجنت ورکلود را اعتبارسنجی میکند
هرگاه یک ورکلود یک SVID درخواست میکند (از طریق FetchJWTSVID یا FetchX509SVID)، به Workload API ایجنت متصل میشود که معمولاً از طریق یک Unix domain socket است (مانند /run/spire/sockets/agent.sock). سپس ایجنت PID فرایند فراخوان را استخراج میکند.
پس از دریافت PID، ایجنت آن را به افزونههای اعتبارسنجی ورکلودِ پیکربندیشده میدهد؛ این افزونهها بر اساس فرادادههای فرایند و کانتینر، selectorها را گردآوری میکنند. ایجنتهای SPIRE از چندین افزونه اعتبارسنجی ورکلود پشتیبانی میکنند. افزونههای رایج شامل docker، k8s، systemd، Unix و Windows هستند. در کلاستر ما، ایجنت از افزونههای k8s و Unix استفاده میکند.
افزونه Kubernetes (k8s)
افزونه k8s با استفاده از PID ورکلود به /proc/<pid>/mountinfo یا /proc/<pid>/cgroups دسترسی پیدا میکند. این افزونه برای استخراج pod UID و container ID تابع GetPodUIDAndContainerID را فراخوانی میکند. در محیط ما این فرایند به شکل زیر است:
پس از استخراج container ID و pod UID، افزونه k8s برای بازیابی فرادادههای پاد، kubelet را پرسوجو میکند. برای این کار از توکن حساب سرویس ایجنت SPIRE که در /var/run/secrets/kubernetes.io/serviceaccount/token ذخیره شده است استفاده میکند.
حساب سرویس ایجنت دارای مجوزهای زیر است که امکان فهرستکردن پادها و دسترسی به اطلاعات نود را فراهم میکند:
با استفاده از این توکن، افزونه تابع getPodList را فراخوانی میکند تا همهٔ پادهای روی گره را بازیابی کند. سپس پادی را شناسایی میکند که UID و شناسهٔ کانتینر آن با مقادیری که از دایرکتوری /proc استخراج شدهاند مطابقت داشته باشد. پس از یافتن تطابق، از فرادادهٔ پاد انتخابگرها را گردآوری میکند:
افزونه Unix
افزونه Unix اطلاعات را از /proc گردآوری میکند تا انتخابگرهایی مانند شناسهٔ کاربر (UID) و شناسهٔ گروه (GID) تولید کند. این انتخابگرها در جریان اثبات اصالت بارکاری بهکار میروند تا هویت یک بارکاری را به ویژگیهای سطح سیستمعاملِ فرایند فراخواننده پیوند دهند و به SPIRE کمک کنند بارکاریهای متفاوتی را که روی یک گره واحد اجرا میشوند از یکدیگر متمایز کند.
در ادامه نمونهای از انتخابگرهایی که گردآوری میکند آمده است:
ایجنت این سلکتورها را از هر دو پلاگین k8s و Unix تجمیع میکند. سپس این مجموعه سلکتور را با ورودیهای ثبتنامی که بهصورت محلی کش شدهاند تطبیق میدهد. اگر سلکتورهای یک ورودی زیرمجموعهای از سلکتورهای ورکلود باشد، ایجنت SVID متناظرِ کششده را به همان ورکلود بازمیگرداند.
جعل هویت ورکلود: جعل سلکتور از طریق cgroup
این حمله به دسترسی سطح ریشه روی نود نیاز دارد. تحلیل ما نشان داد که اعتبارسنجی ورکلود بهشدت به مسیر cgroup مربوط به همان ورکلود متکی است. یک مهاجم که روی نود دسترسی ریشه دارد میتواند این مسیر cgroup را دستکاری کند و احتمالاً ایجنت را فریب دهد تا باور کند ادعاهای اعتبارسنجی متعلق به ورکلود دیگری است و هویت آن ورکلود را بهدست آورد. این امر میتواند به مهاجم اجازه دهد ورکلود قربانی را جعل هویت کند و به هر خدمت یا منبعی که تحت آن هویت مورد اعتماد است دسترسی یابد.
در گام نخست، یک ورودی ثبتنام برای پادی با نام workload-a در سرور ایجاد کردیم و راستیآزمایی کردیم که میتوانیم هویت آن را از داخل همان پاد دریافت کنیم:
راستیآزمایی کردیم که با درخواست یک JWT SVID از میزبان، نمیتوانیم این هویت را بازیابی کنیم:
برای جعل cgroup مربوط به workload-a، ابتدا PID آن را بازیابی میکنیم:
مسیر cgroup آن را بر اساس PID فوق بررسی کردیم.
این مسیر را به یک مسیر cgroup شبیهسازیشده کپی کردیم و PID فعلی پوسته خودمان ($$) را در فایل cgroup.procs همان cgroup شبیهسازیشده نوشتیم.
شایان توجه است که نوشتن مستقیم PID در مسیر cgroup اصلی نیز کارساز بود. ما صرفاً برای پرهیز از تغییر وضعیت زمان اجرای بارکاری اصلی از یک cgroup جداگانه استفاده کردیم.
اجرای دوباره دستور fetch هویت مرتبط با PID 9072 را با موفقیت بازیابی کرد:
همچنین میتوان شناسه SPIFFE مربوط به workload-a را درون توکن JWT مشاهده کرد:
نمایش جعل دستی نشان میدهد که مدل امنیتی کاملاً بر یک فرض واحد و آسیبپذیرِ یکپارچگی نود تکیه دارد. هرگاه دسترسی root داشته باشیم، میتوانیم هویت هر ورکلودی را که روی نود وجود دارد بهدست آوریم.
این نمایش جعلِ دستی یک فرض اعتمادِ حیاتی در تأیید هویت ورکلود را برجسته میکند. هنگامی که مهاجم به سطح دسترسی root روی یک نود دست یابد، میتواند اطلاعات cgroup را دستکاری کند تا عامل SPIRE هویتهای ورکلود را بهاشتباه منتسب کند. در این شرایط، مهاجم میتواند خود را بهجای سایر ورکلودهایی که روی همان نود در حال اجرا هستند جا بزند و هویت آنها را بهدست آورد.
ابزار Spooffe
این یافتهها ما را بر آن داشت تا Spooffe را توسعه دهیم؛ ابزاری که به مدافعان امکان میدهد جعل selector را خودکار کنند و همه هویتهای ورکلود را از نود بازیابی کنند.
ابزار Spooffe نود را برای ورکلودهای در حال اجرا اسکن میکند، مسیرهای cgroup آنها را مییابد و آنها را بهصورت یک cgroup ساختگی برای فرایند خودش بازتولید میکند. سپس از عامل محلی SPIRE درباره هویتهای حاصل (SVIDها) پرسوجو میکند و به ما امکان میدهد همه هویتهای ورکلود موجود روی میزبان را جمعآوری کنیم (شکل 5).
علاوه بر جعل selector، ابزار Spooffe قابلیتهای بیشتری نیز دارد. با این حال، در این نوشتار تنها بر ویژگیهای مرتبط با این پژوهش تمرکز میکنیم.
یکی از این قابلیتها جعل عامل است که بررسی میکند آیا مهاجم میتواند خود را بهجای عامل SPIRE جا بزند و برای استخراج هویتهای ورکلود بهطور مستقیم با سرور ارتباط برقرار کند یا خیر.
نتیجهگیری
در این مقاله نشان دادیم چگونه مهاجمی که روی یک نودِ بهخطرافتاده دسترسی root دارد میتواند از تأیید هویت ورکلود در SPIFFE/SPIRE سوءاستفاده کند، خود را بهجای ورکلودهای هممکان جا بزند و هویت آنها را بازیابی کند. با دستکاری فراداده cgroup نشان دادیم چگونه مهاجمان میتوانند عامل SPIRE را فریب دهند تا SVIDهای معتبر برای یک فرایندِ تحت کنترلِ مهاجم صادر کند. همچنین Spooffe را معرفی کردیم؛ ابزاری که این تکنیک را خودکار میکند تا هویتهای ورکلود را از یک نود شناسایی و استخراج کند.
این یافتهها یک فرض بنیادین در سامانههای هویت ورکلود را برجسته میکنند: اعتماد به نود زیربنایی. هرچند SPIFFE/SPIRE تضمینهای قوی هویتیِ مبتنی بر رمزنگاری را میان ورکلودها اعمال میکند، همین تضمینها به یکپارچگی محیطی وابستهاند که در آن گواهیدهی انجام میشود. بهمحض آنکه این مرز اعتماد شکسته شود، انزوای هویت میان ورکلودها فرو میریزد و مهاجمان میتوانند بهجای اسرار سرقتشده، با استفاده از اعتبارنامههای معتبر حرکت جانبی انجام دهند.
سازمانهایی که هویت ورکلود را بهکار میگیرند باید نفوذ در سطح نود را معادل نفوذ به تمام هویتهایی بدانند که به آن نود محدود شدهاند. برای کاهش ریسک، کانتینرهای دارای امتیاز را محدود کنید، دسترسی مستقیم بههاست را کاهش دهید و اتکا به selectorهای ضعیف یا بهآسانی قابل جعل را به حداقل برسانید.
شرکت Palo Alto Networks یافتههای ما را با اعضای همپیمان ما در Cyber Threat Alliance (CTA) بهاشتراک گذاشته است. اعضای CTA از این اطلاعات برای استقرار سریع حفاظتها برای مشتریان خود و اخلال نظاممند در فعالیت بازیگران مخرب سایبری استفاده میکنند. درباره Cyber Threat Alliance بیشتر بدانید.
محافظتهای محصولی شرکت Palo Alto Networks
مشتریان شرکت Palo Alto Networks از طریق محصولات زیر در برابر تهدیدهای یادشده در بالا بهتر محافظت میشوند:
- Cortex XDR و XSIAM میتوانند با بهرهگیری از رویکرد حفاظتی چندلایه در برابر فعالیتهای پس از بهرهبرداری محافظت کنند. این رویکرد چندین لایه حفاظتی را ترکیب میکند که شامل Advanced WildFire، Behavioral Threat Protection و Endpoint Protection Modules (EPM) است.
- Cortex Cloud Identity Threat Detection میتواند با ایجاد خطپایه بر الگوهای دسترسیِ بلادرنگ، دید سرتاسری را در میان ارائهدهندگان ابر و IdPها فراهم کند. با پایش مستمر این رفتارها، ITDR سوءاستفاده از هویت و اعتبارنامههای بهخطرافتادهای را که منابع حیاتی ابری و ورکلودهای Kubernetes را هدف میگیرند شناسایی کرده و برای دور نگهداشتن مهاجمان، بهصورت خودکار اقدامهای مهار را فعال میکند.
اگر تصور میکنید ممکن است بهخطر افتاده باشید یا موضوعی فوری دارید، با Unit 42 Incident Response team تماس بگیرید یا با شمارههای زیر تماس بگیرید:
- آمریکای شمالی: شماره رایگان: +1 (866) 486-4842 (866.4.UNIT42)
- بریتانیا: +44.20.3743.3660
- اروپا و خاورمیانه: +31.20.299.3130
- آسیا: +65.6983.8730
- ژاپن: +81.50.1790.0200
- استرالیا: +61.2.4062.7950
- هند: 000 800 050 45107
- کره جنوبی: +82.080.467.8774
منابع تکمیلی
- Spooffe — GitHub
برچسبها
-
تکامل باتنت Kimwolf: Kimwolf v7 -
تهدید پایدار: تحلیل عملیات و ارتباطات C2 مبتنی بر بلاکچین Aeternum -
تاکتیکهای تکاملیافته Gremlin Stealer: پنهان شدن در دیدرس با فایلهای Resource
منابع مرتبط با بدافزار
اخبار
حمله PuzzleMask با نثر ساده، فیلترهای سریع LLM را دور میزند
یک روش موسوم به PuzzleMask با لفاف نثریِ ساده، پیلودهای ناقض سیاست را از «بررسی سریع» LLM عبور میدهد. در آزمون 23 پرامپت، نگهبانها آن را safe دانستند و مدل هدف gpt-5-thinking-high در >90% موارد پیلود را استخراج کرد.
۱۴۰۵/۰۶/۲۱
