این اولین قسمت از مجموعهای از مقالات در مورد رایجترین نوع حملات زنجیره تأمین نرمافزار است: حملاتی که (از) یک رجیستری عمومی از اجزای نرمافزاری استفاده میکنند که برای پروژه های منبع باز برای آپلود مصنوعاتی که میتوانند با سایر کاربران به اشتراک گذاشته شوند. وقتی افراد بدخواه نرمافزارهای مخرب را در آنجا منتشر میکنند و از رجیستری به عنوان وسیلهای برای توزیع بدافزار استفاده میکنند، وقتی سازمانهای قربانی مؤلفه نرمافزاری آلوده را نصب یا اجرا میکنند، ما یک حمله زنجیره تأمین داریم.
برای سادهسازی بحث، در ادامه به آن خواهیم پرداخت بسته های نرم افزاری:، کامپوننتهایی به صورت بستهبندیشده که توسط اشخاص ثالث تولید شدهاند. این نه تنها شامل کامپوننتهایی میشود که توسط مدیران بسته مانند NPM یا Poetry استفاده میشوند، بلکه اجزای سیستم عامل شامل کتابخانهها و فایلهای باینری قابل اجرا، تصاویر کانتینر، و ماشینهای مجازی، یا افزونههای ابزار برای ابزارهای توسعه، ساخت و استقرار. ما همه جا بستههای مخرب را دیدهایم. مجرمان سایبری اهمیتی نمیدهند: آنها از جایگزینهای ارائه شده توسط زیرساختهای نرمافزاری مدرن لذت میبرند و از رجیستری و ابزاری که به بهترین وجه با هدف آنها مطابقت دارد استفاده میکنند. بنابراین لطفاً به یاد داشته باشید که بستههای نرمافزاری، اختصاری برای تصاویر کانتینر، بستههای باینری، مخازن متنباز و انواع افزونهها یا پلاگینها (IDEها) هستند. CI/CD سیستمها، ابزارها را بسازید). همه آنها به طور معمول مورد حمله قرار میگیرند.
این سریال ۵ قسمت خواهد داشت:
- مشکل بستههای متنباز چیست؟ موضوع این پست همین است. چرا انواع و اقسام مجرمان، بستههای مخرب منتشر میکنند؟ چرا باید نگران باشم؟
- آناتومی بستههای مخرب: روندها چیستند؟ در این قسمت، ما بر تهدیدی که روز به روز با سیستم MEW خود رصد میکنیم، تمرکز میکنیم. با توجه به نویز پسزمینه زیاد به دلیل تعداد زیاد بستههای مخرب که از typosquatting یا سردرگمی وابستگی استفاده میکنند، درصد کمتری از حملات بسیار موذیانهتر هستند و خطر بیشتری را ایجاد میکنند. رفتار بازیگران بد در مورد سیستم عامل در گذشته اخیر چگونه تغییر کرده است؟ اعداد چقدر است؟ تاکتیکها، تکنیکها و رویههای مورد استفاده و اقدامات مضر مشاهده شده چیست؟
- محافظت در برابر بستههای مخرب متنباز: چه چیزهایی کار میکنند (چه چیزهایی کار نمیکنند)اکثر متخصصان آگاه به مسائل امنیتی، ایدههایی در مورد چگونگی برخورد با این تهدید دارند. ما شنیدهایم که مدیران امنیتی بدون هیچ تردیدی میگویند که SCA ابزارها از قبل به شما میگویند که چه زمانی یک نسخه از بسته نرمافزاری، بدافزار است. یا اینکه به اجزای نرمافزاری شناختهشده و بسیار بررسیشده وابسته هستند، که در آن هرگونه بدافزاری به سرعت شناسایی و حذف میشود. اینکه آنها از نسخههای جزئی/پچ باز برای دریافت خودکار رفع آسیبپذیریها استفاده میکنند، و این روش مناسب و توصیهشده برای کاهش خطر در وابستگیهای متنباز است، با پیروی از اصل «پچ زودهنگام، پچ مکرر». در این قسمت، بررسی خواهیم کرد که چرا این ایدهها اشتباه هستند و چگونه چنین تصورات غلطی به محبوبیت این مکانیسم حمله و خطر بزرگی که سازمانها با آن مواجه هستند، کمک میکند. در پایان، به آنچه که مؤثر است و تلاش و منابع درگیر در آن میپردازیم.
- بستههای مخرب متنباز: رویکرد Xygeniدر این قسمت، ما استراتژیای را که در Xygeni برای سیستم هشدار زودهنگام بدافزار (MEW) خود دنبال میکنیم، ارائه میدهیم. این سیستم چند مرحلهای چگونه در زمان انتشار نسخه جدید بسته به صورت بلادرنگ کار میکند، چگونه شواهد از منابع مختلف جمعآوری میشود، چگونه اولویتبندی انجام میشود، چه معیارهای طبقهبندی را دنبال میکنیم و چرا هنوز برای تأیید ماهیت یک نامزد بسته مخرب به تجزیه و تحلیل دستی نیاز است؟ چگونه بازخورد تیمهای داخلی و رجیستری ما به سیستم کمک میکند تا از شواهد جمعآوریشده گذشته درس بگیرد تا موارد مثبت کاذب را به حداقل برساند. ما توضیح خواهیم داد که چگونه به NPM، GitHub، PyPI و سایر زیرساختهای کلیدی در اکوسیستمهای متنباز کمک میکنیم تا زمان ماندگاری را کاهش دهند..
- سوءاستفاده از متنباز: چه انتظاری از افراد شرور میتوان داشتاین مجموعه با تمرکز بر جدیدترین اقداماتی که دشمنان برای مخفیانهتر کردن حملات، دشوارتر کردن شناسایی آنها، هدفمندتر کردن آنها علیه صنایع خاص و بهرهبرداری بیشتر از این نوع حملات انجام میدهند، به پایان میرسد. آیا حملات باجافزاری با استفاده از این ابزار انجام خواهد شد؟ افراد شرور چگونه از ابزارهای هوش مصنوعی برای ارائه بستههای مخرب پیچیدهتر استفاده میکنند؟ آیا پروژههای محبوب برتر در معرض خطر هستند؟ این مطلب برای این است که خوانندگان در مورد این مسابقه تسلیحاتی و آنچه در کوتاهمدت (نیمه دوم سال 2024) و میانمدت (2025) انتظار میرود، اطلاعاتی کسب کنند. ما یاد خواهیم گرفت که چگونه حملاتی مانند حملات اخیر درِ پشتی XZ-Utilsیا حملهی موجودات زندهی خارج از خشکی به الکترون ساز در مارس 2024، وقایع نشان میدهند که ما باید نسبت به چگونگی تکامل دشمنان هوشیار باشیم.
بیایید با قسمت اول صحنه را باز کنیم: چه اتفاقی برای بستههای نرمافزاری متنباز مخرب میافتد؟
مشکل بستههای متنباز چیست؟
در سالهای اخیر، انواع و اقسام مجرمان از رجیستریهای نرمافزارهای متنباز برای ارائه رفتارهای مخرب استفاده کردهاند. این فعالیتها به قدمت خود متنباز هستند، اما فراوانی آنها در سه سال گذشته به شدت افزایش یافته است.
انتشار اجزای مخرب در رجیستریهای عمومی (حملات مبتنی بر وابستگی) یک جنگ چریکی نامتقارن است که بازیگران تهدید از آن برای توزیع بدافزار استفاده میکنند و از اعتمادی که سازمانها به اجزای متنبازِ توسعهدهندگان ناشناس دارند، سوءاستفاده میکنند (به یاد داشته باشید که کمیک وابستگی xkcd؟). از آنجا که شما به بستهها اعتماد دارید و از بررسی دستی محتوای بسته و وابستگیهای آن ابایی ندارید، این حملات فوقالعاده مؤثر هستند. و عدم تقارن به این دلیل ایجاد میشود که میتوانند تا حد زیادی خودکار باشند و افراد بد نیازی به تعامل مستقیم با قربانی ندارند. آنها به سادگی بسته را در رجیستری عمومی بارگذاری میکنند و آن را رها میکنند.
بستههای مخرب در سال ۲۰۲۲، ۶ برابر افزایش یافتو در سال ۲۰۲۳ با ضریب ۲.۵ برابر به رشد خود ادامه داد. سال گذشته تعداد قابل توجه ۲۴۵۰۰۰ بسته مخرب مشاهده شد، رقمی که بیش از دو برابر تعداد کل سالهای گذشته است. این یک رشد نمایی است! از حذف بستهها به عنوان بدافزار تایید شده در صدها مورد در طول سال ۲۰۲۱ و هزاران مورد در طول سال ۲۰۲۲، در طول سال ۲۰۲۳ شاهد «سر و صدای» پسزمینه بسیار بیشتری بودیم، با سرعتی مشابه برای امسال. و در آن پسزمینه ناشی از مجرمان سایبری سادهلوح که «مسیر کمترین مقاومت» را دنبال میکنند، تعداد کمی از حملات پر سر و صدا حتی در رسانههای عمومی نیز به تیتر اول رسیدند.
چرا این مشکل با این بزرگی مطرح است؟ اعتماد بیش از حد در سراسر زنجیره. نرمافزار متنباز با کد منبع خود توزیع میشود و تحت یک مجوز مشخص منتشر میشود. بله، هر کسی میتواند کد منبع را بررسی کند؛ اما چه کسی بهطور کلی این کار را انجام میدهد؟ چه کسی، پس از بررسی اینکه نرمافزار هیچ بدافزاری ندارد، نرمافزار را از روی منابع میسازد؟ چه کسی، قبل از ارسال مؤلفه بستهبندیشده (که به عنوان ... نیز شناخته میشود) بسته) در پاییندستِ مدیر بسته یا ابزار ساخت، اطمینان حاصل میکند که بسته آلوده به بدافزار نیست و با کد منبع فرضی که باید از آن آمده باشد، مطابقت دارد؟
چرا زیرساختها اجازه چنین حملات آسانی را میدهند؟
رجیستریهای بسته باز هستند و اغلب نیاز به حداقل تأیید هویت ناشر دارند. «هر کسی میتواند نرمافزار خود را اینجا منتشر کند!» سطح انتظارات برای مهاجمان پایین است: آنها از آدرسهای ایمیل یکبار مصرف و حسابهای کاربری GitHubgithub یکبار مصرف برای ایجاد صدها بسته مخرب در کمپینهای کوتاه مدت و شبیه فیشینگ استفاده میکنند. فقط برای موارد هدفمند، به پیچیدگی بالاتری نیاز است: ما حتی شاهد ایجاد یک مخزن منبع معتبر GitHub با ستارههای زیاد و commitاز چندین مشارکتکنندهی جعلی و سایر معیارهای محبوبیت و نگهداری. گرفتن منجمان و شهرت ناشی از کمکهای مالی جعلی خودکارسازی آن دشوار نیست. ما شاهد سوءاستفادههایی در زیرساختهای نرمافزاری باز از همه نوع، نه تنها بدافزارها، مانند حادثه پروتکل چای.
مدیران بسته برای سهولت استفاده طراحی شدهاند و نه برای امنیت.آنها میتوانند اسکریپتهای قبل و بعد از نصب را اجرا کنند (گاهی اوقات کامپایل کد بومی برای یک کتابخانه ضروری است). همچنین، مدیران بسته بستهها را از منابع متعدد نصب میکنند، و گاهی اوقات پیشفرض استفاده از رجیستریهای عمومی است. آنها عدم تطابق بین فراداده در درخواست انتشار و فراداده موجود در خود بسته را بررسی نکردند.
وابستگیها تو در تو هستند و یک گراف را تشکیل میدهند. در اکوسیستمهای خاصی مانند Node (جاوااسکریپت)، وابستگیهای دانهریز در صدها یا هزاران مورد جمع میشوند. یک چیز این است که کنترل دقیقی بر وابستگیهای مستقیم اعلام شده توسط پروژههای نرمافزاری خود داشته باشم، اما وابستگیهای انتقالی کنترل آنها دشوارتر است. متنباز از «دوستان دوستان من، دوستان من هستند» پیروی میکرد. برادری در خاور دورِ وحشی، امری عادی است! عاملان تهدید این را میدانند و رفتار مخرب خود را عمیقاً در وابستگیهای مبهمی که اغلب ناشناخته هستند، پنهان میکنند. این مورد در مورد ... نیز صدق میکرد. جریان رویداد حادثهای که هدف آن کیف پول کوپی.
نرمافزارهای متنباز از زمان پیدایش خود اینگونه کار میکردند. این رویه تغییر زیادی نخواهد کرد. برخی از ثبتهای بسته، در بهترین حالت، احراز هویت دو مرحلهای را الزامی میکنند، و اغلب فقط برای محبوبترین بستهها. برخی از ثبتها، دامنهها (scope) ارائه میدهند، یک فضای نام متعلق به یک سازمان تأیید شده، اما غم انگیز برخی دیگر از آن پشتیبانی نمیکنند (PyPI) یا آن را اختیاری میکنند (NPM). جالب است بدانید که حتی یک طرح غربالگری ساده (بر اساس کنترل مخزن/سازمان DNS یا GitHub که با شناسه گروه مطابقت دارد) و ایجاد امضاهای PGP اجباری است برای همه مصنوعات به جز چکسامها، بیشتر «نویز»ها، بستههای مخرب شبیه به غلط املایی را حذف میکند و بسیاری از موارد را محدود میکند سردرگمی وابستگیحملات پیچیده امکانپذیر است اما بسیار دشوارتر، و تنها تعداد کمی از آنها مانند ... com.github.codingandcoding:maven-compiler-plugin به خاطر Maven Central شناخته شده است. و همه ثبتهای Maven از رویههای یکسانی پیروی نمیکنند!
کنترلهای امنیتی روی مدیران بسته ممکن است حملات وابستگی را سنگین کنند اما مانع آنها نمیشوند. مشکل احراز هویت چند عاملی این است که برای اتوماسیون، اعتبارنامههای مشتق شده مانند توکنهای دسترسی یا کلیدهای APIapi برای حسابهایی که در فراخوانیهای APIapi ساخته شده از اسکریپتهای اتوماسیون استفاده میشوند، تولید میشوند و هیچ کاربر تعاملی پشتیبان، عامل دوم را ارائه نمیدهد. احراز هویت چند عاملی برای محافظت از حسابهای کاربری در برابر نشت رمز عبور خوب است، اما توکنهای دسترسی یا کلیدهای APIapi تولید شده باید در حین فعال بودن محافظت شوند، در غیر این صورت مالک آنها توسط دشمنان جعل هویت میشود. بخش بزرگی از کمپینهای زنجیره تأمین مبتنی بر بسته با یک کلید/توکن نشت یافته شروع میشوند. فقط حوادثی مانند دفتر کل, 3CXو بسیاری موارد دیگر، که در آنها اعتبارنامههای غیرتعاملی ابتدا در یک نفوذ اولیه برای راهاندازی حمله زنجیره تأمین استخراج شدند.
پاسخی که به این تهدید داده شد به اندازه کافی قوی نبود. در قسمت سوم، ما بر روی آنچه که مؤثر بود و آنچه که به طرز فجیعی شکست خورد، تمرکز خواهیم کرد. این صنعت باید به صورت جمعی روی ... کار کند. standardها، فرآیندها، آموزش و ابزار برای کاهش خطرات زنجیرههای تأمین جهانی. این مشکلی نیست که یک سازمان به تنهایی بتواند آن را حل کند.
برای پایان دادن به این بخش، سوءتفاهم اساسی: ما در مورد ... صحبت میکنیم مخرب بستهها، نه اسیب پذیر آسیبپذیریها ناشی از خطاهای طراحی یا کدنویسی هستند که به طور تصادفی و بدون نیت بد ایجاد میشوند. این آسیبپذیریها ممکن است مورد سوءاستفاده قرار گیرند، اما بسیاری از آنها اینطور نیستند. بستههای مخرب همیشه عمدی هستند و در صورت اجرا، ۱۰۰٪ احتمال سوءاستفاده وجود دارد. هیچ خطر قابل مقایسهای وجود ندارد! از این رو دیدن اینکه چه تلاشهای زیادی برای شناسایی و کاهش آسیبپذیریها انجام میشود و فقدان اقدامات معادل برای اجزای مخرب، متناقض است..
«ما امنیت را جدی میگیریم»
بیایید عرف را تصور کنیم شرکت Acme. Acme، یکی از ارائهدهندگان اصلی WileCoyote.com، بیشتر نرمافزارهای خود را از اشخاص ثالث تهیه میکند که بیش از ۸۰٪ آنها از پروژههای منبع باز هستند. آنها نرمافزارهایی را برای استفاده داخلی تولید میکنند، اما همچنین نرمافزارهایی را برای شرکا، ارائهدهندگان و مشتریان/کاربران نهایی خود ارائه میدهند. Acme نرمافزارهایی دارد که با Go، JavaScript، Java، C# و Python نوشته شدهاند و بیشتر نرمافزارهای خود را روی ابر، تحت خوشههای Kuberneteskubernetes اجرا میکند. Acme تصاویر سفارشی خود را از تصاویر پایه گرفته شده از Docker Hub و سایر رجیستریها میسازد. و آنها چند کتابخانه، بسته و تصاویر کانتینر را نیز در رجیستریهای عمومی به اشتراک میگذارند.
شرکت Acme امنیت را جدی میگیرد. آنها کاملاً از مشکل ... آگاه هستند. open source securityو ریسکی که به همراه دارد. همه توسعهدهندگان، مدیران سیستم و مهندسان DevOps از آن کلیدهای رمزنگاری کوچک و بامزه به عنوان احراز هویت مرحله دوم استفاده میکنند. همه commitمخازن کد امضا شدهاند، حفاظت از شاخهها با بررسیهای اجباری کد فعال شده است، CI/CD قفل شده، اسرار ذخیره شده در یک گاوصندوق مخفی، و با یک رجیستری داخلی که تا حدی از رجیستریهای خارجی تقلید میکند که در آن فقط اجزای مجاز و دارای لیست سفید ذخیره میشوند. لازم است نرمافزار ساخته شده توسط Acme وابستگیهای شخص ثالث را از این رجیستری دریافت کند.
احتمالاً بیشتر سازمانها در این دسته قرار میگیرند. خواننده عزیز، اگر هنوز اینجا هستید، مطمئناً مورد شما هم قرار میگیرد، اینطور نیست؟
سپس یک روز شوم، یک توسعهدهندهی مهم فرانتاند در Acme زد نصب کتابخانه acme-cute با npmو فراموش میکنند که @acme/cute-lib وابستگی دامنهدار مناسبی بوده است. اشتباه اصلی مهم نیست، حتی وقتی کسی کنترل کامل چرخه حیات نرمافزار را در دست میگیرد، ممکن است بسیاری از چیزها اشتباه پیش بروند. توسعهدهنده ما نمیدانست که یک گروه APT، Acme را هدف قرار داده و یک مؤلفه مخرب را با آن نام منتشر کرد، به روشی زیرکانه، به طوری که رفتار مخرب فقط زمانی فعال میشود که نرمافزار روی رایانههای Acme نصب شود. این بسته تا هفتهها پس از انتشارش شناسایی نشد.
یک اسکریپت نصب اجرا میشود که به دنبال اعتبارنامهها میگردد (توکنهای دسترسی مفید زیادی در لپتاپ توسعهدهنده ما وجود داشت)، و امکان دسترسی به مخازن نرمافزار داخلی و مخزن داخلی فوقالذکر را فراهم میکند، که البته فقط از طریق VPN قابل دسترسی است. کد مخرب موفق شد از اتصال VPN موجود استفاده کند و یک مؤلفه مخرب مرحله دوم را در رجیستری داخلی منتشر کند و بر یک کتابخانه utils مشترک که توسط اکثر نرمافزارهای ارائه شده توسط Acme به اشتراک گذاشته شده است، تأثیر بگذارد.
چند هفته بعد، سازمانهای دیگری که از ابزارهای منتشر شده توسط Acme استفاده میکردند، شاهد ترافیک عجیبی در شبکههای خود بودند. این ترافیک از پروتکل Acme استفاده میکرد اما به میزبانهایی شبیه به دامنه Acme هدایت میشد. ترافیک رمزگذاری شده بود، اما ابزارهای نظارت بر سیستم، دسترسی به فایلهای غیرمنتظره و اجرای فرآیندهایی را که شبیه دستورات سیستمی بودند اما در نهایت فایلهای اجرایی دانلود شده را اجرا میکردند، پیدا کردند.
بقیه ماجرا دیگر تاریخ است: Acme ابتدا انکار کرد که چنین رفتاری به آنها نسبت داده میشود و تمام اقدامات امنیتی در حال انجام است. تنها پس از آنکه رسانههای امنیت سایبری شروع به پرسیدن این سوال کردند که چرا منبع رفتار شناسایی شده از اجزای Acme سرچشمه گرفته است و تحلیلهای امنیتی نشان داد که این اجزا چقدر آلوده به بدافزارهای مخفی بودهاند، Acme مجبور شد این حادثه را تشخیص دهد و با یک شرکت واکنش به حوادث تماس بگیرد. یک کمپین بازاریابی منفی که اعتماد به نفس به سختی به دست آمده را در یک لحظه تضعیف کرد.Acme فقط یک نصب npm با di فاصله داشتsaster« » تیتر رایجی بود. سپس دعاوی حقوقی و قراردادهای لغو شده به دنبال آن آمدند.
آیا شباهتی با حوادث شناختهشده گذشته میبینید؟ Acme در دو مرحله و با استفاده از ترکیبی از موارد زیر، دچار حادثه زنجیره تأمین شد. سردرگمی وابستگی/تایپ کردن نامنظم حملاتی که از یک ایستگاه کاری توسعهدهنده به عنوان پایگاهی برای آلوده کردن اجزایی که در نهایت در نرمافزارهای مورد استفاده اشخاص ثالث قرار میگیرند، استفاده میکنند. چگونه میتوان از این امر جلوگیری کرد یا آن را کاهش داد؟
چرا بستههای مسموم اینقدر محبوب هستند؟
این حادثه فرضی نشان میدهد که حتی با یک رویکرد معقول به امنیت متنباز، سازمانها برای جلوگیری از افتادن در دام بدافزارهای موجود در اجزای متنباز، به اقدامات خاصی نیاز دارند. به طور شماتیک، عامل تهدید میتواند:
- یک بسته جدید ایجاد کنید (با پیروی از مسیرهای شناختهشدهی typosquatting یا dependency confusion، این مسیر بیشترین مسیری است که توسط افراد خرابکار طی میشود)؛
- سعی کنید یک مورد موجود را آلوده کنید، یا با تزریق آن به کد منبع، یا تلاش برای پنهان کردن آن به عنوان یک مشارکتکننده از طریق ... pull requestیا استفاده از مهندسی اجتماعی برای تبدیل شدن به یک نگهدارنده (همانطور که "جائو تان" در XZ Backdoor انجام داد یا right9ctrl کاربر GitHub در جریان رویداد حادثه در پاییز ۲۰۱۸)، یا با به دست آوردن اعتبارنامههای مخزن متنباز و جعل هویت نگهدارنده؛
- تزریق بدافزار در حین ساخت بسته، یا با اجرای یک اسکریپت ساخت مخربیا تداخل در دانلود بستهها با رهگیریهای مرد میانی (خوشبختانه، TLS اکنون همیشه در اکثر رجیستریها الزامی است).
- تزریق مستقیم مؤلفهی بستهبندیشده به رجیستری، معمولاً با گرفتن اطلاعات احراز هویت رجیستری (جایگزین ترجیحی برای بسیاری از حملات پیچیده مانند حملات Acme که در آن ایستگاه کاری آسیبدیده در مرحلهی اول دارای توکن دسترسی به رجیستری داخلی بود، مثلاً در حالت معمول) .NS or ~/.m2/settings.xmlهکرها میدانند کجا دنبال اطلاعات محرمانه بگردند. آسیبپذیریهای موجود در رجیستریها نیز مورد سوءاستفاده قرار گرفتند.
آلوده کردن رجیستریها با بدافزار، اساس حملات وابستگی است. چیز جدیدی نیست: شیوع آن به طرز چشمگیری افزایش یافته است، اما همان تکنیکهایی که پنج سال پیش کار میکردند، اکنون نیز کار میکنند.
منبع: مجموعه چاقوهای Backstabber.
بستهی مخرب میتواند در هنگام نصب، در طول ساخت نرمافزار یا در زمان اجرا عمل کند. و این رفتار از استخراج اطلاعات، مثلاً استخراج اطلاعات محرمانه برای تلاش در مرحلهی دوم، تا استخراج کد منبع و انتشار بدافزارهای اضافی، متغیر است. در قسمت بعدی، بستههای مخرب و نحوهی انتشار آنها را بررسی خواهیم کرد.
مطالعه بیشتر
قسمت بعدی آناتومی بستههای مخرب: روندها چیستند؟ تمرکز ما بر موارد واقعی خواهد بود که روز به روز با سیستم هشدار زودهنگام بدافزار خود رصد میکنیم. بررسی خواهیم کرد که کدام نوع بدافزار مشاهده شده است و کدام تاکتیکها، تکنیکها و رویهها محبوبتر هستند. مبهمسازی و نحوه تلاش آنها برای پنهان شدن از دید بررسیکنندگان بالقوه، تکنیکهای فرار برای جلوگیری از شناسایی و نحوه تکامل آنها با تلهمتری و حرکت جانبی را بررسی خواهیم کرد. لطفاً با ما همراه باشید!
منابع
- مجموعه چاقوی Backstabber: مروری بر حملات زنجیره تأمین نرمافزار متنبازام. اهم و همکاران، مه ۲۰۲۰.
- محافظت در برابر بدافزارهای متنباز. گزارش رسمی از Xygeni.
- Software Supply Chain Security نگاهی به گذشته: شکلدهی به یک سال امنتر ۲۰۲۴گزارش از خیگنی.
