فریم ورک SABSA چیه و چرا باید بهش توجه کنیم؟
✍️روزبه نوروزی
هدف SABSA:
این فریم ورک کمک می‌کند امنیت را راهبردی، برنامه‌ریزی‌شده و با توجه به نیاز واقعی کسب‌وکار طراحی کنیم ، نه همین طوری و فقط فنی.
خروجی: یک نقشه کامل، با تعریف نقش‌ها، فرایندها، قوانین و فناوری‌ها که موقع اجرا، امنیت واقعاً پاسخگوی نیاز هست و نه صرفاً یکسری کنترل تئوریک!
فریم ورک SABSA عملاً چطور کار می‌کند؟ (با مثال)
فرض کنید شما در یک شرکت تلکام کار می‌کنید که باید هم سرویس پیام‌رسان بدهد، هم پنل مدیریت به مشتری.
مشکل: امنیت فقط یک آنتی‌ویروس یا فایروال نیست؛ باید امنیت را بر پایه نیاز و ریسک واقعی کسب‌وکار معماری کنیم.
فریم ورک SABSA لایه‌ها دارد:
1. لایه کسب‌وکار (Business View)
اینجا سؤال کلیدی:«برای کسب‌وکار ما، دقیقاً چه چیزی ارزش دارد و چه چیزی باید امن بماند؟»
مثلا: حریم خصوصی اطلاعات کاربران، عدم اختلال سرویس پیام‌رسانی، امنیت پنل مدیریت.
2. لایه مفهومی (Conceptual View)
تعریف می‌کنید دقیقاً “چه سیاست‌هایی” باید باشد.
مثلاً: تمام تراکنش‌ها باید احراز هویت دو عاملی داشته باشند، اطلاعات کاربران فقط توسط پرسنل معتمد قابل مشاهده است.
3. لایه منطقی (Logical View)
نقشه منطقی از ساختار سیستم
مثلاً: چه نوع سیستم‌های احراز هویت باید وجود داشته باشد؟ چه کنترل‌ها و مدیریت دسترسی‌هایی باید طراحی شوند؟
4. لایه فیزیکی (Physical View)
الان دقیقاً روی چه سخت‌افزار/نرم‌افزاری قرار است کنترل‌ها را پیاده کنیم؟
مثلاً: روی سرور X، دیتابیس Y، ابزار WAF یا SIEMمرکز عملیات امنیت.
5. لایه جزئیات اجرایی (Component View)
دقیقاً هر کنترل، با کدام محصول یا نسخه و چطور مستقر میشود.
مثلاً: سرور لینوکس روی هسته 5، احراز هویت به کمک ماژول PAM، لوگین از طریق Duo Security، قفل خودکار پس از 5 تلاش.
6. لایه مدیریت اجرا (Operational View)
چه کسانی مسئول چه کنترل یا مانیتورینگی هستند؟ چه فرایندهایی باید مدام اجرا شود؟ مثلاً تیم SOC هر 24 ساعت همه لاگ‌ها را بررسی کند، اتوماسیون ایونت مانیتور کند لاگین مشکوک را هشدار دهد و غیره.
مثال خیلی عملی (خلاصه)
مثلاً شما می‌خواهید دسترسی به سیستم‌های Core تلکام را طوری انجام دهید که هک نشود:
در لایه کسب‌وکار: می‌گویید: «دسترسی غیرمجاز به هسته شبکه قطعاً باید صفر باشد».
در لایه مفهومی: سیاست: «دسترسی فقط با MFA و مجوز مدیر».
در لایه منطقی: نوع احراز هویت، مدیریت اکانت، تقسیم دسترسی‌ها و ثبت لاگ.
در لایه فیزیکی: دستگاه‌ها و نرم‌افزارهای احراز هویت و ثبت لاگ را انتخاب می‌کنید.
در لایه جزئیات اجرایی: مثلاً Active Directory با ماژول MFA، سرور Syslog برای لاگ‌ها.
در لایه عملیات: تعریف کنید چه کسی ادمین شود، چه کسی لاگ‌ها بررسی کند و چه کسی Incident را مدیریت کند.
پس SABSA یعنی…
امنیت بر اساس ارزش‌های کسب‌وکار و نه صرفاً تکنولوژی
مثل نقشه ساختمانی است که می‌گوید چه چیزی را کجا و برای چه کسی بسازی!
مسیر SABSA میگه:
۱. نیاز کسب‌وکار و ریسک را شفاف کن
۲. سیاست و هدف امنیت را بنویس
۳. کنترل‌ها و مدل منطقی را ترسیم کن
۴. فناوری و ابزار تعیین کن
۵. مسئولیت‌ها و فرآیندهای اجرایی را مشخص کن
اینطور معماری امنیت شما نه دیمی و وصله‌پینه‌ای، بلکه منظم، قابل دفاع و متناسب با نیازها خواهد بود
پی نوشت : در مستندات اصلی لایه ششم وجود ندارد . در کلاس CISSP و یک وبینار در آینده بحث میکنم چرا اینطور نوشتم .
#آکادمی_روزبه
مرکز تخصصی CISSP
✍️روزبه نوروزی
هدف SABSA:
این فریم ورک کمک می‌کند امنیت را راهبردی، برنامه‌ریزی‌شده و با توجه به نیاز واقعی کسب‌وکار طراحی کنیم ، نه همین طوری و فقط فنی.
خروجی: یک نقشه کامل، با تعریف نقش‌ها، فرایندها، قوانین و فناوری‌ها که موقع اجرا، امنیت واقعاً پاسخگوی نیاز هست و نه صرفاً یکسری کنترل تئوریک!
فریم ورک SABSA عملاً چطور کار می‌کند؟ (با مثال)
فرض کنید شما در یک شرکت تلکام کار می‌کنید که باید هم سرویس پیام‌رسان بدهد، هم پنل مدیریت به مشتری.
مشکل: امنیت فقط یک آنتی‌ویروس یا فایروال نیست؛ باید امنیت را بر پایه نیاز و ریسک واقعی کسب‌وکار معماری کنیم.
فریم ورک SABSA لایه‌ها دارد:
1. لایه کسب‌وکار (Business View)
اینجا سؤال کلیدی:«برای کسب‌وکار ما، دقیقاً چه چیزی ارزش دارد و چه چیزی باید امن بماند؟»
مثلا: حریم خصوصی اطلاعات کاربران، عدم اختلال سرویس پیام‌رسانی، امنیت پنل مدیریت.
2. لایه مفهومی (Conceptual View)
تعریف می‌کنید دقیقاً “چه سیاست‌هایی” باید باشد.
مثلاً: تمام تراکنش‌ها باید احراز هویت دو عاملی داشته باشند، اطلاعات کاربران فقط توسط پرسنل معتمد قابل مشاهده است.
3. لایه منطقی (Logical View)
نقشه منطقی از ساختار سیستم
مثلاً: چه نوع سیستم‌های احراز هویت باید وجود داشته باشد؟ چه کنترل‌ها و مدیریت دسترسی‌هایی باید طراحی شوند؟
4. لایه فیزیکی (Physical View)
الان دقیقاً روی چه سخت‌افزار/نرم‌افزاری قرار است کنترل‌ها را پیاده کنیم؟
مثلاً: روی سرور X، دیتابیس Y، ابزار WAF یا SIEMمرکز عملیات امنیت.
5. لایه جزئیات اجرایی (Component View)
دقیقاً هر کنترل، با کدام محصول یا نسخه و چطور مستقر میشود.
مثلاً: سرور لینوکس روی هسته 5، احراز هویت به کمک ماژول PAM، لوگین از طریق Duo Security، قفل خودکار پس از 5 تلاش.
6. لایه مدیریت اجرا (Operational View)
چه کسانی مسئول چه کنترل یا مانیتورینگی هستند؟ چه فرایندهایی باید مدام اجرا شود؟ مثلاً تیم SOC هر 24 ساعت همه لاگ‌ها را بررسی کند، اتوماسیون ایونت مانیتور کند لاگین مشکوک را هشدار دهد و غیره.
مثال خیلی عملی (خلاصه)
مثلاً شما می‌خواهید دسترسی به سیستم‌های Core تلکام را طوری انجام دهید که هک نشود:
در لایه کسب‌وکار: می‌گویید: «دسترسی غیرمجاز به هسته شبکه قطعاً باید صفر باشد».
در لایه مفهومی: سیاست: «دسترسی فقط با MFA و مجوز مدیر».
در لایه منطقی: نوع احراز هویت، مدیریت اکانت، تقسیم دسترسی‌ها و ثبت لاگ.
در لایه فیزیکی: دستگاه‌ها و نرم‌افزارهای احراز هویت و ثبت لاگ را انتخاب می‌کنید.
در لایه جزئیات اجرایی: مثلاً Active Directory با ماژول MFA، سرور Syslog برای لاگ‌ها.
در لایه عملیات: تعریف کنید چه کسی ادمین شود، چه کسی لاگ‌ها بررسی کند و چه کسی Incident را مدیریت کند.
پس SABSA یعنی…
امنیت بر اساس ارزش‌های کسب‌وکار و نه صرفاً تکنولوژی
مثل نقشه ساختمانی است که می‌گوید چه چیزی را کجا و برای چه کسی بسازی!
مسیر SABSA میگه:
۱. نیاز کسب‌وکار و ریسک را شفاف کن
۲. سیاست و هدف امنیت را بنویس
۳. کنترل‌ها و مدل منطقی را ترسیم کن
۴. فناوری و ابزار تعیین کن
۵. مسئولیت‌ها و فرآیندهای اجرایی را مشخص کن
اینطور معماری امنیت شما نه دیمی و وصله‌پینه‌ای، بلکه منظم، قابل دفاع و متناسب با نیازها خواهد بود
پی نوشت : در مستندات اصلی لایه ششم وجود ندارد . در کلاس CISSP و یک وبینار در آینده بحث میکنم چرا اینطور نوشتم .
#آکادمی_روزبه
مرکز تخصصی CISSP
👍4❤2🙏1
در عمرم شاید ۱۰ سال طول کشید تا این دو اصل به عمق جان بنشیند :
✅️موفقیت یک شبه نیست
✳️انجام هر کاری ، با تقسیم کردن آن به اجزا و مرحله ها قابل انجام میشود
لذا همیشه بین اینکه پندی را بشنوید و قبول داشته باشید تا آنکه آنرا اجرا کنید؛ ممکن است خیلی راه و زمان باشد.
#آکادمی_روزبه
مرکز تخصصی CISSP
✅️موفقیت یک شبه نیست
✳️انجام هر کاری ، با تقسیم کردن آن به اجزا و مرحله ها قابل انجام میشود
لذا همیشه بین اینکه پندی را بشنوید و قبول داشته باشید تا آنکه آنرا اجرا کنید؛ ممکن است خیلی راه و زمان باشد.
#آکادمی_روزبه
مرکز تخصصی CISSP
👏7
سناریو
پس از مشاهده آلودگی اولیه و ارتباط با C2 ، یکی از دوگانگی‌های کلاسیک در شکار تهدید و IR پیش رو هست:
"Contain یا Observe"
(جلوگیری فوری از انتشار یا صبر برای دیدن رفتار کامل؟)
خیلی اینجا نیاز به تجربه داره
ولی نکاتی میگم که بتونه بهتون کمک کنه راهکارهایی رو در پی بگیرید( اما این وسط نکات بسیاره که در همراهی با کانال اونها رو میبینید )
ترکیبی از ایزولاسیون پنهان و نظارت پنهان
۱.انجام Redirect / Sinkhole DNS
به جای قطع کامل ارتباط، ترافیک DNS و HTTP رو به سرور داخلی می‌فرستید تا رفتار رو تقلید کنه (decoy).
۲. انجامPacket Capture
با ابزارهایی مثل Zeek یا Wireshark ترافیک به روی اون endpoint یا سوییچ، رو ذخیره میکنیم.
۳. انجام EDR Isolation در Silent Mode (اگه ساپورت بشه)
بعضی EDRها مثل CrowdStrike, Defender ATP، حالت stealth isolation دارند: کاربر چیزی نمی‌فهمه ولی ارتباط به C2 قطع می‌شه.
۴. انجام Live Memory Dump
قبل از هر واکنشی، RAM رو dump بگیرید. چون در حافظه ممکنه توکن‌ها، keylogger، shellcode، یا حتی decryptorها باشن.
**اینطوری چند قدم در راه نظارت فعال و واکنش واقع بینانه همراه با پنهان کاری قدم برداشتی . هم میدونی چه خبره هم هکر نمیدونه تو هستی و کار خطرناکی نمیکنه
#آکادمی_روزبه
مرکز تخصصی CISSP
#تجربه #درس_آموخته
پس از مشاهده آلودگی اولیه و ارتباط با C2 ، یکی از دوگانگی‌های کلاسیک در شکار تهدید و IR پیش رو هست:
"Contain یا Observe"
(جلوگیری فوری از انتشار یا صبر برای دیدن رفتار کامل؟)
خیلی اینجا نیاز به تجربه داره
ولی نکاتی میگم که بتونه بهتون کمک کنه راهکارهایی رو در پی بگیرید( اما این وسط نکات بسیاره که در همراهی با کانال اونها رو میبینید )
ترکیبی از ایزولاسیون پنهان و نظارت پنهان
۱.انجام Redirect / Sinkhole DNS
به جای قطع کامل ارتباط، ترافیک DNS و HTTP رو به سرور داخلی می‌فرستید تا رفتار رو تقلید کنه (decoy).
۲. انجامPacket Capture
با ابزارهایی مثل Zeek یا Wireshark ترافیک به روی اون endpoint یا سوییچ، رو ذخیره میکنیم.
۳. انجام EDR Isolation در Silent Mode (اگه ساپورت بشه)
بعضی EDRها مثل CrowdStrike, Defender ATP، حالت stealth isolation دارند: کاربر چیزی نمی‌فهمه ولی ارتباط به C2 قطع می‌شه.
۴. انجام Live Memory Dump
قبل از هر واکنشی، RAM رو dump بگیرید. چون در حافظه ممکنه توکن‌ها، keylogger، shellcode، یا حتی decryptorها باشن.
**اینطوری چند قدم در راه نظارت فعال و واکنش واقع بینانه همراه با پنهان کاری قدم برداشتی . هم میدونی چه خبره هم هکر نمیدونه تو هستی و کار خطرناکی نمیکنه
#آکادمی_روزبه
مرکز تخصصی CISSP
#تجربه #درس_آموخته
👍5💯3❤1
حمله به EDRها: Fuzzing موتور اسکن و شبیه‌ساز Defender (mpengine.dll)
مقدمه
موتور شناسایی بدافزار مایکروسافت دیفندر (Microsoft Defender) که با نام mpengine.dll شناخته میشود، هسته اصلی سیستم دفاعEndpoint Detection and Response یا همان EDR مایکروسافت است. این ابزار به طور پیش‌فرض روی سیستم‌های ویندوز نصب است، با بالاترین سطح دسترسی اجرا میشود و مسئول اسکن فایل‌ها و شبیه‌سازی اجرای آن‌ها برای یافتن بدافزار است. باتوجه به حجم بالای کد، گستردگی فرمت‌های قابل پردازش و قابلیت اجرای مستقیم در ویندوز، این موتور به یک هدف بسیار جذاب برای پژوهش آسیب‌پذیری و حمله تبدیل شده است.
با وجود اهمیت بالای این سرویس، مطالعات و افشاهای عمومی توانمندسازی حمله علیه آن کمتر از حد انتظار بوده است. همین موضوع انگیزه‌ای شد تا نویسنده این مقاله، به بررسی عمیق‌تر سطوح حمله این محصول بپردازد تا بتواند نقاط ضعف بالقوه را شناسایی و تحلیل کند.
خلاصه‌ای از یافته‌ها
در این تحلیل، موتو اسکن Defender با بهره‌گیری از روش Fuzzing و ابزار WTF و سایر ابزارهای مرتبط مانند kAFL/NYX و Jackalope مورد بررسی قرار گرفت. با استفاده از تکنیک Snapshot Fuzzing موفق به کشف نه باگ مختلف از نوع OOB-Read (خواندن خارج از محدوده حافظه) و Null Dereference (ارائه نشانی پوچ) شدند.
این آسیب‌پذیری‌ها منجر به کرش‌کردن فرآیند اصلی دیفندر (MsMpEng.exe) هنگام اسکن برخی فایل‌های مخرب میشود، به‌گونه‌ای که با طراحی یک فایل ویژه، می‌توان موتور دفاعی مایکروسافت را از کار انداخت. لازم به ذکر است براساس تحلیل نویسنده، هیچ یک از این آسیب‌پذیری‌ها قابلیت اجرای کد مخرب (RCE) ندارند، اما سبب می‌شوند فرآیند محافظتی دیفندر متوقف گردد و راه برای حملات بعدی هموار شود.
یکی از کاربردهای عملی این آسیب‌پذیری‌ها آن است که مهاجم بتواند پیش از اجرای Payload اصلی (مثلاً بدافزار نهایی) با انتقال یک فایل مخرب علاوه بر بی‌اثر کردن آنتی‌ویروس، مسیر اجرای کد مخرب را هموار نماید. این تهدید به ویژه در حملات سازمان‌یافته و نفوذهای هدفمند، می‌تواند ابزار ارزشمندی برای مهاجمین تلقی شود.
تاریخچه تحقیقات روی موتور mpengine.dll
نخستین مطالعات جدی روی این ماژول توسط Tavis Ormandy از تیم Project Zero گوگل انجام شد. وی با شناسایی آسیب‌پذیری CVE-2017-8558 و همچنین توسعه یک لودر DLL روی لینوکس برای اجرای Fuzzing ابتدایی mpengine.dll، توجه پژوهشگران آسیب‌پذیری را جلب کرد.
در سال‌های بعدی آسیب‌پذیری شاخص دیگری با کد CVE-2021-34522 نیز کشف گردید، اما در مجموع موتور دیفندر به نسبت دیگر آنتی‌ویروس‌ها کمتر مورد توجه پژوهشگران آسیب‌پذیری بوده است. این خلاء مطالعاتی انگیزه‌ای برای نویسنده شد تا با امکانات جدید فازینگ مانند WTF و ابزارهای متن‌باز جدید، بار دیگر امنیت این هسته کلیدی را به چالش بکشد.
روش اجرای Fuzzing روی mpengine.dll
اجرای فرآیند Fuzzing روی mpengine.dll، به دلیل وابستگی به محیط ویندوز و پیچیدگی ماژول، نیازمند ابزارها و تکنیک‌های خاص است. در ابتدا، پژوهشگران Project Zero، با استفاده از loadlibrary روی لینوکس و یک فرآیند Harness سفارشی (mpclient.c)، مقدمات Fuzzing را فراهم کردند. با گذشت زمان و تغییر نسخه‌های mpengine این ابزار نیاز به به‌روزرسانی پیدا کرد.
در این پژوهش، مرکز ثقل تست‌ها روی ویندوز و ابزار WTF قرار گرفت. این ابزار به کمک Snapshot Fuzzing می‌تواند حالت اجرایی ماشین را ذخیره و به سرعت به وضعیت اولیه برگرداند، لذا تست‌های تکرارشونده بدون سربار بالا انجام میشود. همچنین ابزارهای kAFL/NYX و Jackalope برای تطبیق با فرآیندهای قبلی (همانند آنچه در تحلیل فازینگ Sophos Intercept X استفاده شد) نیز تست شدند.
نتایج نهایی نشان داد WTF با فاصله قابل توجهی بهترین نتیجه را روی این هدف ارائه می‌دهد و موفق به کشف باگ‌های جدید شد.
اهمیت آسیب‌پذیری‌های کشف شده
اگرچه باگ‌های شناسایی شده تا لحظه نگارش مقاله تایید نشده‌اند که قابل بهره‌برداری برای اجرای کد باشند، اما توانایی مهاجم برای ایجاد کرش در فراِیند MsMpEng.exe اهمیت زیادی دارد. در فضای عملی، مهاجم می‌تواند با انتقال یک فایل آلوده به سرور یا سیستم هدف و اسکن شدن آن توسط دیفندر، آنتی‌ویروس را از کار بیندازد. این وضعیت در بسیاری از سناریوهای حمله پیشرفته مانند credential dumping یا lateral movement اهمیت دارد.
پاسخ مایکروسافت به گزارشات پژوهشگر، چندان جدی نبوده است. در نمایه رسمی، مایکروسافت اعلام می‌کند این موارد از منظر سطح تهدید، متوسط ارزیابی شده و مشمول سرویس‌رسانی فوری نمی‌گردد! با این‌حال حداقل یکی از باگ‌ها در فاصله کوتاهی بی‌سروصدا وصله شده است.
جایگاه این پژوهش در امنیت EDR
ادامه در پست بعدی
#آکادمی_روزبه
مرکز تخصصی CISSP
مقدمه
موتور شناسایی بدافزار مایکروسافت دیفندر (Microsoft Defender) که با نام mpengine.dll شناخته میشود، هسته اصلی سیستم دفاعEndpoint Detection and Response یا همان EDR مایکروسافت است. این ابزار به طور پیش‌فرض روی سیستم‌های ویندوز نصب است، با بالاترین سطح دسترسی اجرا میشود و مسئول اسکن فایل‌ها و شبیه‌سازی اجرای آن‌ها برای یافتن بدافزار است. باتوجه به حجم بالای کد، گستردگی فرمت‌های قابل پردازش و قابلیت اجرای مستقیم در ویندوز، این موتور به یک هدف بسیار جذاب برای پژوهش آسیب‌پذیری و حمله تبدیل شده است.
با وجود اهمیت بالای این سرویس، مطالعات و افشاهای عمومی توانمندسازی حمله علیه آن کمتر از حد انتظار بوده است. همین موضوع انگیزه‌ای شد تا نویسنده این مقاله، به بررسی عمیق‌تر سطوح حمله این محصول بپردازد تا بتواند نقاط ضعف بالقوه را شناسایی و تحلیل کند.
خلاصه‌ای از یافته‌ها
در این تحلیل، موتو اسکن Defender با بهره‌گیری از روش Fuzzing و ابزار WTF و سایر ابزارهای مرتبط مانند kAFL/NYX و Jackalope مورد بررسی قرار گرفت. با استفاده از تکنیک Snapshot Fuzzing موفق به کشف نه باگ مختلف از نوع OOB-Read (خواندن خارج از محدوده حافظه) و Null Dereference (ارائه نشانی پوچ) شدند.
این آسیب‌پذیری‌ها منجر به کرش‌کردن فرآیند اصلی دیفندر (MsMpEng.exe) هنگام اسکن برخی فایل‌های مخرب میشود، به‌گونه‌ای که با طراحی یک فایل ویژه، می‌توان موتور دفاعی مایکروسافت را از کار انداخت. لازم به ذکر است براساس تحلیل نویسنده، هیچ یک از این آسیب‌پذیری‌ها قابلیت اجرای کد مخرب (RCE) ندارند، اما سبب می‌شوند فرآیند محافظتی دیفندر متوقف گردد و راه برای حملات بعدی هموار شود.
یکی از کاربردهای عملی این آسیب‌پذیری‌ها آن است که مهاجم بتواند پیش از اجرای Payload اصلی (مثلاً بدافزار نهایی) با انتقال یک فایل مخرب علاوه بر بی‌اثر کردن آنتی‌ویروس، مسیر اجرای کد مخرب را هموار نماید. این تهدید به ویژه در حملات سازمان‌یافته و نفوذهای هدفمند، می‌تواند ابزار ارزشمندی برای مهاجمین تلقی شود.
تاریخچه تحقیقات روی موتور mpengine.dll
نخستین مطالعات جدی روی این ماژول توسط Tavis Ormandy از تیم Project Zero گوگل انجام شد. وی با شناسایی آسیب‌پذیری CVE-2017-8558 و همچنین توسعه یک لودر DLL روی لینوکس برای اجرای Fuzzing ابتدایی mpengine.dll، توجه پژوهشگران آسیب‌پذیری را جلب کرد.
در سال‌های بعدی آسیب‌پذیری شاخص دیگری با کد CVE-2021-34522 نیز کشف گردید، اما در مجموع موتور دیفندر به نسبت دیگر آنتی‌ویروس‌ها کمتر مورد توجه پژوهشگران آسیب‌پذیری بوده است. این خلاء مطالعاتی انگیزه‌ای برای نویسنده شد تا با امکانات جدید فازینگ مانند WTF و ابزارهای متن‌باز جدید، بار دیگر امنیت این هسته کلیدی را به چالش بکشد.
روش اجرای Fuzzing روی mpengine.dll
اجرای فرآیند Fuzzing روی mpengine.dll، به دلیل وابستگی به محیط ویندوز و پیچیدگی ماژول، نیازمند ابزارها و تکنیک‌های خاص است. در ابتدا، پژوهشگران Project Zero، با استفاده از loadlibrary روی لینوکس و یک فرآیند Harness سفارشی (mpclient.c)، مقدمات Fuzzing را فراهم کردند. با گذشت زمان و تغییر نسخه‌های mpengine این ابزار نیاز به به‌روزرسانی پیدا کرد.
در این پژوهش، مرکز ثقل تست‌ها روی ویندوز و ابزار WTF قرار گرفت. این ابزار به کمک Snapshot Fuzzing می‌تواند حالت اجرایی ماشین را ذخیره و به سرعت به وضعیت اولیه برگرداند، لذا تست‌های تکرارشونده بدون سربار بالا انجام میشود. همچنین ابزارهای kAFL/NYX و Jackalope برای تطبیق با فرآیندهای قبلی (همانند آنچه در تحلیل فازینگ Sophos Intercept X استفاده شد) نیز تست شدند.
نتایج نهایی نشان داد WTF با فاصله قابل توجهی بهترین نتیجه را روی این هدف ارائه می‌دهد و موفق به کشف باگ‌های جدید شد.
اهمیت آسیب‌پذیری‌های کشف شده
اگرچه باگ‌های شناسایی شده تا لحظه نگارش مقاله تایید نشده‌اند که قابل بهره‌برداری برای اجرای کد باشند، اما توانایی مهاجم برای ایجاد کرش در فراِیند MsMpEng.exe اهمیت زیادی دارد. در فضای عملی، مهاجم می‌تواند با انتقال یک فایل آلوده به سرور یا سیستم هدف و اسکن شدن آن توسط دیفندر، آنتی‌ویروس را از کار بیندازد. این وضعیت در بسیاری از سناریوهای حمله پیشرفته مانند credential dumping یا lateral movement اهمیت دارد.
پاسخ مایکروسافت به گزارشات پژوهشگر، چندان جدی نبوده است. در نمایه رسمی، مایکروسافت اعلام می‌کند این موارد از منظر سطح تهدید، متوسط ارزیابی شده و مشمول سرویس‌رسانی فوری نمی‌گردد! با این‌حال حداقل یکی از باگ‌ها در فاصله کوتاهی بی‌سروصدا وصله شده است.
جایگاه این پژوهش در امنیت EDR
ادامه در پست بعدی
#آکادمی_روزبه
مرکز تخصصی CISSP
👍3❤2
ادامه از پست قبل
این مطالعه بخشی از یک سری گسترده‌تر است که نویسنده آن تاکنون چندین آسیب‌پذیری شاخص بر محصولات EDR کشف و معرفی کرده است. در بخش‌های قبل به حمله به مینی‌فیلترها، باگ ران‌تایم و حتی دور زدن مکانیزم‌های محافظتی سطح کرنل پرداخته شده بود.
تحقیقات از این جنس ضعف‌های بنیادی در محصولات امنیتی سازمانی را آشکار می‌کند ــ نقاط ضعفی که میتوانند «خط دفاع آخر» سازمان را به زانو درآورند. نکته مهم اینجاست که محصولات امنیتی باید خود بیشترین مقاومت را مقابل تکنیک‌های حمله و بهره‌کشی داشته باشند اما متاسفانه شتاب شرکت‌ها برای انتشار قابلیت و عدم بازبینی عمیق امنیتی، فرصت حمله را فراهم می‌کند.
#آکادمی_روزبه
مرکز تخصصی CISSP
https://labs.infoguard.ch/posts/attacking_edr_part4_fuzzing_defender_scanning_and_emulation_engine/
این مطالعه بخشی از یک سری گسترده‌تر است که نویسنده آن تاکنون چندین آسیب‌پذیری شاخص بر محصولات EDR کشف و معرفی کرده است. در بخش‌های قبل به حمله به مینی‌فیلترها، باگ ران‌تایم و حتی دور زدن مکانیزم‌های محافظتی سطح کرنل پرداخته شده بود.
تحقیقات از این جنس ضعف‌های بنیادی در محصولات امنیتی سازمانی را آشکار می‌کند ــ نقاط ضعفی که میتوانند «خط دفاع آخر» سازمان را به زانو درآورند. نکته مهم اینجاست که محصولات امنیتی باید خود بیشترین مقاومت را مقابل تکنیک‌های حمله و بهره‌کشی داشته باشند اما متاسفانه شتاب شرکت‌ها برای انتشار قابلیت و عدم بازبینی عمیق امنیتی، فرصت حمله را فراهم می‌کند.
#آکادمی_روزبه
مرکز تخصصی CISSP
https://labs.infoguard.ch/posts/attacking_edr_part4_fuzzing_defender_scanning_and_emulation_engine/
InfoGuard Labs
Attacking EDRs Part 4: Fuzzing Defender's Scanning and Emulation Engine (mpengine.dll) - InfoGuard Labs
Multiple out-of-bounds read and null dereference bugs were identified in Microsoft Defender by using Snapshot Fuzzing with WTF and kAFL/NYX. The bugs can be used to crash the main Defender process as soon as the file is scanned. Most are unpatched, but none…
👍4
جنگ روسیه و اکراین
در سه قسمت
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/three-years-of-cyber-warfare-how-digital-attacks-have-shaped-the-russia-ukraine-war/
https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/attacks-against-government-entities-defense-sector-and-human-targets/
https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/the-russia-ukraine-cyber-war-part-3-attacks-on-telecom-and-critical-infrastructure/
در سه قسمت
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/three-years-of-cyber-warfare-how-digital-attacks-have-shaped-the-russia-ukraine-war/
https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/attacks-against-government-entities-defense-sector-and-human-targets/
https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/the-russia-ukraine-cyber-war-part-3-attacks-on-telecom-and-critical-infrastructure/
Levelblue
The Russia-Ukraine Cyber War Part 1: Three Years of Cyber Warfare
Trustwave SpiderLabs created a series of blogs to explain how the Russia-Ukraine war is being fought not just on the ground, but also in the realm of cyber.
👍3❤2
مقاله LOLBins: نسخه به روز از huntress
#آکادمی_روزبه
مرکز تخصصی CISSP
www.roozbeh.academy
https://www.huntress.com/blog/detecting-malicious-use-of-lolbins
#آکادمی_روزبه
مرکز تخصصی CISSP
www.roozbeh.academy
https://www.huntress.com/blog/detecting-malicious-use-of-lolbins
Huntress
LOLBin Attacks: Definition, Examples & Detection | Huntress
Learn what LOLBins are, why they're hard to detect, and how to spot malicious use of native tools like PowerShell, net.exe, and cmd.exe before attackers strike.
❤3👍2
یک PoC برای حمله در اکتیو دایرکتوری
ابزار SharpSuccessor یک POC بر پایه دات‌نت است که حمله‌ای به نام BadSuccessor را پیاده‌سازی می‌کند. این حمله توسط یووال گوردون (@YuG0rd) از شرکت Akamai معرفی شده است. هدف این ابزار نمایش عملی نحوه سوءاستفاده از آسیب‌پذیری‌های اکتیو دایرکتوری برای افزایش سطح دسترسی (Privilege Escalation) کاربران است.
جزییات بیشتر:
این آسیب‌پذیری بر مبنای دسترسی CreateChild در یک Organizational Unit (OU) اکتیو دایرکتوری کار می‌کند؛ یعنی اگر کاربری دسترسی لازم برای ایجاد اشیای جدید در یک OU داشته باشد، ممکن است بتواند از این طریق مجوزهای بالاتری به دست بیاورد.
کد پروژه به طور کامل در دات‌نت نوشته شده و صرفاً با هدف آموزشی و برای بررسی و درک آسیب‌پذیری منتشر شده است.
این پروژه نه برای به‌کارگیری در محیط‌های عملیاتی، بلکه برای فهم بهتر جزییات فنی حمله BadSuccessor و راه‌حل‌های مقابله با آن طراحی شده است.
خلاصه کاربرد:
پژوهشگران و متخصصان امنیت میتوانند با بررسی این پروژه نحوه سوءاستفاده احتمالی کاربران با سطح دسترسی پایین را بفهمند و اقدامات لازم جهت ایمن‌سازی اکتیودایرکتوری (مثل چک کردن مجوزهای CreateChild) را اجرا کنند.
#آکادمی_روزبه
مرکز تخصصی CISSP
www.roozbeh.academy
https://github.com/logangoins/SharpSuccessor/
ابزار SharpSuccessor یک POC بر پایه دات‌نت است که حمله‌ای به نام BadSuccessor را پیاده‌سازی می‌کند. این حمله توسط یووال گوردون (@YuG0rd) از شرکت Akamai معرفی شده است. هدف این ابزار نمایش عملی نحوه سوءاستفاده از آسیب‌پذیری‌های اکتیو دایرکتوری برای افزایش سطح دسترسی (Privilege Escalation) کاربران است.
جزییات بیشتر:
این آسیب‌پذیری بر مبنای دسترسی CreateChild در یک Organizational Unit (OU) اکتیو دایرکتوری کار می‌کند؛ یعنی اگر کاربری دسترسی لازم برای ایجاد اشیای جدید در یک OU داشته باشد، ممکن است بتواند از این طریق مجوزهای بالاتری به دست بیاورد.
کد پروژه به طور کامل در دات‌نت نوشته شده و صرفاً با هدف آموزشی و برای بررسی و درک آسیب‌پذیری منتشر شده است.
این پروژه نه برای به‌کارگیری در محیط‌های عملیاتی، بلکه برای فهم بهتر جزییات فنی حمله BadSuccessor و راه‌حل‌های مقابله با آن طراحی شده است.
خلاصه کاربرد:
پژوهشگران و متخصصان امنیت میتوانند با بررسی این پروژه نحوه سوءاستفاده احتمالی کاربران با سطح دسترسی پایین را بفهمند و اقدامات لازم جهت ایمن‌سازی اکتیودایرکتوری (مثل چک کردن مجوزهای CreateChild) را اجرا کنند.
#آکادمی_روزبه
مرکز تخصصی CISSP
www.roozbeh.academy
https://github.com/logangoins/SharpSuccessor/
GitHub
GitHub - logangoins/SharpSuccessor: SharpSuccessor is a .NET Proof of Concept (POC) for fully weaponizing Yuval Gordon’s (@YuG0rd)…
SharpSuccessor is a .NET Proof of Concept (POC) for fully weaponizing Yuval Gordon’s (@YuG0rd) BadSuccessor attack from Akamai. - logangoins/SharpSuccessor
🔥4👍2❤1
اکانت DMSA: نسل جدید اکانت‌های سرویس در اکتیودایرکتوری و تفاوت آن با gMSA
مقدمه
مدیریت امن سرویس اکانت‌ها همیشه یکی از دغدغه‌های اصلی مدیران اکتیودایرکتوری بوده است. سرویس اکانت‌ها معمولاً با سطح دسترسی بالا در سیستم‌ها اجرا می‌شوند و آسیب‌پذیری یا افشای پسورد این اکانت‌ها می‌تواند منجر به نفوذ گسترده در سازمان شود. برای رفع این مشکل، مایکروسافت پیش‌تر Group Managed Service Account یا gMSA را ایجاد کرد تا پسورد سرویس اکانت‌ها به طور خودکار و دوره‌ای تغییر کند و فقط سرورهای مجاز به آن دسترسی داشته باشند.
اما با پیشرفت نیازهای امنیتی و پیچیده‌تر شدن تهدیدات، مایکروسافت نوع جدیدی از این حساب‌ها را معرفی کرده است که تحت عنوان Delegated Managed Service Account یا DMSA شناخته میشود. در این مقاله به بررسی مفهوم DMSA، تفاوت‌های آن با gMSA و مزیت ویژه DMSA یعنی تخصیص آن به یک ماشین خاص می‌پردازیم.
Managed Service Accounts: مروری کوتاه
قبل از ورود به بحث DMSA، نیاز است به طور خلاصه با مفهوم Managed Service Accounts (MSA) آشنا شویم. MSAs اکانت‌هایی هستند که جهت اجرای سرویس‌ها و برنامه‌ها روی ویندوز سرورها تعریف می‌شوند. هدف اصلی MSA ساده‌سازی مدیریت پسورد و کاهش ریسک‌های افشای آن در محیط‌های بزرگ است.
اماgMSA چیست؟
این gMSA مخفف Group Managed Service Account بوده و این امکان را فراهم می‌کند که یک حساب سرویس، توسط چندین سرور یا سیستم به اشتراک گذاشته شود. به عبارت ساده‌تر اگر یک گروه سرور (مثلاً چندین سرور SQL) نیاز به اجرای یک سرویس با یک حساب مشخص دارند، gMSA بهترین انتخاب خواهد بود. پسورد این حساب‌ها توسط اکتیودایرکتوری به صورت خودکار در فواصل زمانی مشخص تولید و مدیریت میشود و فقط سرورهایی که مشخص شده‌اند، میتوانند این پسورد را دریافت و از آن استفاده کنند.
و DMSA چیست؟
این DMSA یا Delegated Managed Service Account نسل جدید حساب‌های سرویس مدیریت‌شده است که در ویندوز سرورهای جدیدتر معرفی شده است. تفاوت اصلی DMSA با gMSA در موارد زیر است:
۱. تخصیص به یک ماشین (Single Machine Binding)
مهم‌ترین و برجسته‌ترین ویژگی DMSA این است که اکانت فقط به یک ماشین خاص تعلق می‌گیرد. به این معنی که حتی اگر یک مهاجم موفق به بدست آوردن پسورد یا دسترسی DMSA شود، نمی‌تواند از آن روی ماشین‌ها یا سرورهای دیگر سوءاستفاده کند؛ زیرا DMSA فقط روی همان ماشین تعریف‌شده معتبر است. این ویژگی ریسک lateral movement را (حرکت جانبی مهاجم بین سرورها) به شدت کاهش می‌دهد.
۲. مدل مدیریتی متفاوت با gMSA
در gMSA، مدیریت پسورد به طور کامل توسط اکتیودایرکتوری انجام میشود و ادمین صرفاً سرورهای مجاز را تعیین می‌کند. اما در DMSA، مدیریت حساب تا حدی به مدیر local آن ماشین یا یک مدیر delegated محول میشود. این یعنی ادمین‌ها انعطاف بیشتری دارند، اما نیاز به توجه بیشتر به مسائل امنیتی و مدیریتی نیز دارند.
۳. تطبیق با نیازهای امنیتی امروزی
با توجه به پیچیده‌تر شدن تهدیدات و حملات هدفمند به اکتیودایرکتوری، مدل single machine DMSA پاسخی به نیازهای امنیتی جدید است. این مدل می‌تواند امنیت سرویس‌هایی که روی سرورهای حیاتی یا حساس اجرا می‌شوند را افزایش چشمگیری دهد.
مزیت Single Machine بودن DMSA
ویژگی تخصیص تک‌ماشینی (Single Machine) در DMSA یک تغییر بنیادی در فلسفه مدیریت سرویس اکانت‌ها است. در مدل سنتی یا حتی gMSA، در صورت نفوذ به یک سرور و افشای پسورد سرویس اکانت، مهاجم می‌تواند از همین حساب روی سایر سرورها نیز بهره‌برداری کند، که اصطلاحاً به آن lateral movement می‌گویند؛ یعنی حرکت جانبی بین سرورها در شبکه. اما DMSA با اختصاص اکانت برای فقط یک سرور خاص، این ریسک را تا حد زیادی حذف می‌کند.
برای مثال فرض کنید سازمانی سرویس‌های مالی حساس یا اپلیکیشن‌هایی با دسترسی بالا به دیتابیس دارد. اگر این سرویس‌ها با DMSA راه‌اندازی شوند حتی در صورت compromise شدن یک سرور، مهاجم به هیچ‌وجه نمی‌تواند با همان اکانت وارد سایر بخش‌های شبکه شود. همین مزیت باعث افزایش چشمگیر امنیت در زیرساخت‌های سازمانی میشود.
چالش‌ها و نکات مهم در استفاده از DMSA
البته پیاده‌سازی DMSA نیز مانند هر فناوری جدید، چالش‌های خودش را دارد که آگاهی از آن‌ها ضروری است:
مدیریت لوکال: چون بخشی از مدیریت حساب به عهده لوکال ادمین هر ماشین گذاشته شده، باید کنترل‌های امنیتی لازم وجود داشته باشد تا از سوءاستفاده یا اشتباهات جلوگیری شود.
ریکاوری یا انتقال: در صورت نیاز به انتقال سرویس به ماشین دیگر (مثلاً هنگام failover یا upgrade)، لازم است مراحل خاصی برای ریجستر و انتقال DMSA انجام شود.
ادامه در پست بعدی....👇👇
#آکادمی_روزبه
مرکز تخصصی CISSP
www.roozbeh.academy
مقدمه
مدیریت امن سرویس اکانت‌ها همیشه یکی از دغدغه‌های اصلی مدیران اکتیودایرکتوری بوده است. سرویس اکانت‌ها معمولاً با سطح دسترسی بالا در سیستم‌ها اجرا می‌شوند و آسیب‌پذیری یا افشای پسورد این اکانت‌ها می‌تواند منجر به نفوذ گسترده در سازمان شود. برای رفع این مشکل، مایکروسافت پیش‌تر Group Managed Service Account یا gMSA را ایجاد کرد تا پسورد سرویس اکانت‌ها به طور خودکار و دوره‌ای تغییر کند و فقط سرورهای مجاز به آن دسترسی داشته باشند.
اما با پیشرفت نیازهای امنیتی و پیچیده‌تر شدن تهدیدات، مایکروسافت نوع جدیدی از این حساب‌ها را معرفی کرده است که تحت عنوان Delegated Managed Service Account یا DMSA شناخته میشود. در این مقاله به بررسی مفهوم DMSA، تفاوت‌های آن با gMSA و مزیت ویژه DMSA یعنی تخصیص آن به یک ماشین خاص می‌پردازیم.
Managed Service Accounts: مروری کوتاه
قبل از ورود به بحث DMSA، نیاز است به طور خلاصه با مفهوم Managed Service Accounts (MSA) آشنا شویم. MSAs اکانت‌هایی هستند که جهت اجرای سرویس‌ها و برنامه‌ها روی ویندوز سرورها تعریف می‌شوند. هدف اصلی MSA ساده‌سازی مدیریت پسورد و کاهش ریسک‌های افشای آن در محیط‌های بزرگ است.
اماgMSA چیست؟
این gMSA مخفف Group Managed Service Account بوده و این امکان را فراهم می‌کند که یک حساب سرویس، توسط چندین سرور یا سیستم به اشتراک گذاشته شود. به عبارت ساده‌تر اگر یک گروه سرور (مثلاً چندین سرور SQL) نیاز به اجرای یک سرویس با یک حساب مشخص دارند، gMSA بهترین انتخاب خواهد بود. پسورد این حساب‌ها توسط اکتیودایرکتوری به صورت خودکار در فواصل زمانی مشخص تولید و مدیریت میشود و فقط سرورهایی که مشخص شده‌اند، میتوانند این پسورد را دریافت و از آن استفاده کنند.
و DMSA چیست؟
این DMSA یا Delegated Managed Service Account نسل جدید حساب‌های سرویس مدیریت‌شده است که در ویندوز سرورهای جدیدتر معرفی شده است. تفاوت اصلی DMSA با gMSA در موارد زیر است:
۱. تخصیص به یک ماشین (Single Machine Binding)
مهم‌ترین و برجسته‌ترین ویژگی DMSA این است که اکانت فقط به یک ماشین خاص تعلق می‌گیرد. به این معنی که حتی اگر یک مهاجم موفق به بدست آوردن پسورد یا دسترسی DMSA شود، نمی‌تواند از آن روی ماشین‌ها یا سرورهای دیگر سوءاستفاده کند؛ زیرا DMSA فقط روی همان ماشین تعریف‌شده معتبر است. این ویژگی ریسک lateral movement را (حرکت جانبی مهاجم بین سرورها) به شدت کاهش می‌دهد.
۲. مدل مدیریتی متفاوت با gMSA
در gMSA، مدیریت پسورد به طور کامل توسط اکتیودایرکتوری انجام میشود و ادمین صرفاً سرورهای مجاز را تعیین می‌کند. اما در DMSA، مدیریت حساب تا حدی به مدیر local آن ماشین یا یک مدیر delegated محول میشود. این یعنی ادمین‌ها انعطاف بیشتری دارند، اما نیاز به توجه بیشتر به مسائل امنیتی و مدیریتی نیز دارند.
۳. تطبیق با نیازهای امنیتی امروزی
با توجه به پیچیده‌تر شدن تهدیدات و حملات هدفمند به اکتیودایرکتوری، مدل single machine DMSA پاسخی به نیازهای امنیتی جدید است. این مدل می‌تواند امنیت سرویس‌هایی که روی سرورهای حیاتی یا حساس اجرا می‌شوند را افزایش چشمگیری دهد.
مزیت Single Machine بودن DMSA
ویژگی تخصیص تک‌ماشینی (Single Machine) در DMSA یک تغییر بنیادی در فلسفه مدیریت سرویس اکانت‌ها است. در مدل سنتی یا حتی gMSA، در صورت نفوذ به یک سرور و افشای پسورد سرویس اکانت، مهاجم می‌تواند از همین حساب روی سایر سرورها نیز بهره‌برداری کند، که اصطلاحاً به آن lateral movement می‌گویند؛ یعنی حرکت جانبی بین سرورها در شبکه. اما DMSA با اختصاص اکانت برای فقط یک سرور خاص، این ریسک را تا حد زیادی حذف می‌کند.
برای مثال فرض کنید سازمانی سرویس‌های مالی حساس یا اپلیکیشن‌هایی با دسترسی بالا به دیتابیس دارد. اگر این سرویس‌ها با DMSA راه‌اندازی شوند حتی در صورت compromise شدن یک سرور، مهاجم به هیچ‌وجه نمی‌تواند با همان اکانت وارد سایر بخش‌های شبکه شود. همین مزیت باعث افزایش چشمگیر امنیت در زیرساخت‌های سازمانی میشود.
چالش‌ها و نکات مهم در استفاده از DMSA
البته پیاده‌سازی DMSA نیز مانند هر فناوری جدید، چالش‌های خودش را دارد که آگاهی از آن‌ها ضروری است:
مدیریت لوکال: چون بخشی از مدیریت حساب به عهده لوکال ادمین هر ماشین گذاشته شده، باید کنترل‌های امنیتی لازم وجود داشته باشد تا از سوءاستفاده یا اشتباهات جلوگیری شود.
ریکاوری یا انتقال: در صورت نیاز به انتقال سرویس به ماشین دیگر (مثلاً هنگام failover یا upgrade)، لازم است مراحل خاصی برای ریجستر و انتقال DMSA انجام شود.
ادامه در پست بعدی....👇👇
#آکادمی_روزبه
مرکز تخصصی CISSP
www.roozbeh.academy
👍3❤2
ادامه از پست قبل 👆👆
سازگاری نرم‌افزارها: همه سرویس‌ها و اپلیکیشن‌ها ممکن است بلافاصله از DMSA پشتیبانی نکنند و لازم است بررسی شود که نرم‌افزار مورد نظر امکان استفاده از این نوع اکانت را دارد یا نه.
آموزش به ادمین‌ها: مدیران شبکه باید با نحوه ایجاد، مدیریت و حذف DMSA کامل آشنا شوند تا بهره‌وری مناسب از این قابلیت فراهم گردد.
جمع‌بندی
اکانت DMSA به عنوان نسل جدید حساب‌های سرویس، پاسخگوی یکی از نیازهای اساسی مدیران شبکه و امنیت، یعنی کاهش ریسک lateral movement و ایزوله کردن دسترسی‌های حیاتی در لایه عملیاتی ویندوز سرور است. مزیت اختصاصی بودن DMSA به هر ماشین، امنیت سرویس‌های حساس را تا حد قابل توجهی بالا برده و مهاجمان را در نفوذ به سایر بخش‌های شبکه دچار مشکل می‌کند.
انتظار می‌رود با فراگیری بیشتر این قابلیت و بهبود پشتیبانی نرم‌افزاری، DMSA به زودی جایگزین پیش‌فرض برای سرویس اکانت‌های حیاتی در سازمان‌ها باشد و مدیران امنیتی باید از همین امروز آشنایی و اعمال آن را در استراتژی‌های خود قرار دهند.
#آکادمی_روزبه
مرکز تخصصی CISSP
www.roozbeh.academy
سازگاری نرم‌افزارها: همه سرویس‌ها و اپلیکیشن‌ها ممکن است بلافاصله از DMSA پشتیبانی نکنند و لازم است بررسی شود که نرم‌افزار مورد نظر امکان استفاده از این نوع اکانت را دارد یا نه.
آموزش به ادمین‌ها: مدیران شبکه باید با نحوه ایجاد، مدیریت و حذف DMSA کامل آشنا شوند تا بهره‌وری مناسب از این قابلیت فراهم گردد.
جمع‌بندی
اکانت DMSA به عنوان نسل جدید حساب‌های سرویس، پاسخگوی یکی از نیازهای اساسی مدیران شبکه و امنیت، یعنی کاهش ریسک lateral movement و ایزوله کردن دسترسی‌های حیاتی در لایه عملیاتی ویندوز سرور است. مزیت اختصاصی بودن DMSA به هر ماشین، امنیت سرویس‌های حساس را تا حد قابل توجهی بالا برده و مهاجمان را در نفوذ به سایر بخش‌های شبکه دچار مشکل می‌کند.
انتظار می‌رود با فراگیری بیشتر این قابلیت و بهبود پشتیبانی نرم‌افزاری، DMSA به زودی جایگزین پیش‌فرض برای سرویس اکانت‌های حیاتی در سازمان‌ها باشد و مدیران امنیتی باید از همین امروز آشنایی و اعمال آن را در استراتژی‌های خود قرار دهند.
#آکادمی_روزبه
مرکز تخصصی CISSP
www.roozbeh.academy
👍3❤2
از اسلاید های جلسه سوم CISSP
همین پنج شنبه
دو مفهوم Scoping و Tailoring نقش مهمی در شخصی‌سازی کنترل‌های امنیتی متناسب با سازمان دارند. این مفاهیم به‌ویژه در زمینه‌های استانداردهایی مانند NIST SP 800-53 و ISO/IEC 27001 نیز به‌کار می‌روند.
مفهوم Scoping (دامنه‌بندی):
مفهوم Scoping یعنی تعیین محدوده و بُرد کنترل‌های امنیتی که باید پیاده‌سازی شوند. در این مرحله بررسی میشود:
کدام بخش‌های سازمان در دامنه امنیت اطلاعات قرار می‌گیرند؟
چه نوع سیستم‌ها، فرآیندها، کاربران و داده‌هایی باید تحت پوشش باشند؟
آیا همه سیستم‌ها نیاز به کنترل‌های یکسان دارند؟
مثال:
اگر یک شرکت فقط یک دیتاسنتر دارد که داده حساس پردازش می‌کند، ممکن است دامنه پیاده‌سازی کنترل‌ها به آن دیتاسنتر محدود شود و دیگر سیستم‌های غیرحساس خارج از دامنه قرار گیرند.
مفهوم Tailoring (سفارشی‌سازی):
مفهوم Tailoring یعنی تطبیق و تنظیم کنترل‌ها پس از تعیین دامنه، به‌گونه‌ای که متناسب با شرایط خاص سازمان باشد. در این مرحله ممکن است:
برخی کنترل‌ها اضافه یا حذف شوند.
کنترل‌هایی سبک‌تر یا شدیدتر اعمال شوند.
پیاده‌سازی کنترل‌ها بر اساس ریسک، بودجه، الزامات قانونی یا فرهنگی تنظیم شود.
مثال:
در NIST SP 800-53 اگر کنترل "دسترسی چندعاملی" برای همه کاربران توصیه شده، سازمان می‌تواند آن را فقط برای کاربران دارای دسترسی به داده حساس اعمال کند.
#آکادمی_روزبه
مرکز تخصصی CISSP
همین پنج شنبه
دو مفهوم Scoping و Tailoring نقش مهمی در شخصی‌سازی کنترل‌های امنیتی متناسب با سازمان دارند. این مفاهیم به‌ویژه در زمینه‌های استانداردهایی مانند NIST SP 800-53 و ISO/IEC 27001 نیز به‌کار می‌روند.
مفهوم Scoping (دامنه‌بندی):
مفهوم Scoping یعنی تعیین محدوده و بُرد کنترل‌های امنیتی که باید پیاده‌سازی شوند. در این مرحله بررسی میشود:
کدام بخش‌های سازمان در دامنه امنیت اطلاعات قرار می‌گیرند؟
چه نوع سیستم‌ها، فرآیندها، کاربران و داده‌هایی باید تحت پوشش باشند؟
آیا همه سیستم‌ها نیاز به کنترل‌های یکسان دارند؟
مثال:
اگر یک شرکت فقط یک دیتاسنتر دارد که داده حساس پردازش می‌کند، ممکن است دامنه پیاده‌سازی کنترل‌ها به آن دیتاسنتر محدود شود و دیگر سیستم‌های غیرحساس خارج از دامنه قرار گیرند.
مفهوم Tailoring (سفارشی‌سازی):
مفهوم Tailoring یعنی تطبیق و تنظیم کنترل‌ها پس از تعیین دامنه، به‌گونه‌ای که متناسب با شرایط خاص سازمان باشد. در این مرحله ممکن است:
برخی کنترل‌ها اضافه یا حذف شوند.
کنترل‌هایی سبک‌تر یا شدیدتر اعمال شوند.
پیاده‌سازی کنترل‌ها بر اساس ریسک، بودجه، الزامات قانونی یا فرهنگی تنظیم شود.
مثال:
در NIST SP 800-53 اگر کنترل "دسترسی چندعاملی" برای همه کاربران توصیه شده، سازمان می‌تواند آن را فقط برای کاربران دارای دسترسی به داده حساس اعمال کند.
#آکادمی_روزبه
مرکز تخصصی CISSP
👍4❤1💯1
داده ها برای پردازش میتوانند رمز شده باشند!!
✍روزبه نوروزی
همیشه خوانده ایم داده ها برای پردازش لازم است از حالت رمز دربیایند امااااا
پردازش روی داده رمزنگاری‌شده قابل انجام است:
برخی روش‌های پیشرفته رمزنگاری مثل
Homomorphic Encryption (رمزنگاری همومورفیک)
اجازه می‌دهد محاسبات خاصی مستقیماً روی داده رمزنگاری‌شده انجام بشود بدون اینکه اول لازم باشد دیتای خام decrypt بشود.
فرض کنید دیتابیس مالی شرکت رمزنگاری‌شده است و شما لازم دارید مثلاً جمع مبالغ پرداختی یک شخص را بدانید. با این روش میشود مجموع مقادیر را به‌دست آورد، بدون اینکه دیتابیس را “کلاً” رمزگشایی کنید.
مزیت:
امنیت بالاتر، چون حتی سیستم اجرایی یا مدیر سیستم هم دیتای اصلی را هرگز نمی‌بیند.
جمع‌بندی:
بله، به طور سنتی برای استفاده و پردازش داده، باید رمزگشایی انجام شود.
اما تکنولوژی‌های جدید مثل رمزنگاری همومورفیک یا Secure Enclaves تا حدودی این قاعده را تغییر داده‌اند.
اما این تکنولوژی‌ها هنوز کاملاً رایج نشده‌اند و اکثریت سیستم‌عامل‌ها همین رفتار کلاسیک را دارند.
#آکادمی_روزبه
مرکز تخصصی CISSP
Www.Roozbeh.academy
✍روزبه نوروزی
همیشه خوانده ایم داده ها برای پردازش لازم است از حالت رمز دربیایند امااااا
پردازش روی داده رمزنگاری‌شده قابل انجام است:
برخی روش‌های پیشرفته رمزنگاری مثل
Homomorphic Encryption (رمزنگاری همومورفیک)
اجازه می‌دهد محاسبات خاصی مستقیماً روی داده رمزنگاری‌شده انجام بشود بدون اینکه اول لازم باشد دیتای خام decrypt بشود.
فرض کنید دیتابیس مالی شرکت رمزنگاری‌شده است و شما لازم دارید مثلاً جمع مبالغ پرداختی یک شخص را بدانید. با این روش میشود مجموع مقادیر را به‌دست آورد، بدون اینکه دیتابیس را “کلاً” رمزگشایی کنید.
مزیت:
امنیت بالاتر، چون حتی سیستم اجرایی یا مدیر سیستم هم دیتای اصلی را هرگز نمی‌بیند.
جمع‌بندی:
بله، به طور سنتی برای استفاده و پردازش داده، باید رمزگشایی انجام شود.
اما تکنولوژی‌های جدید مثل رمزنگاری همومورفیک یا Secure Enclaves تا حدودی این قاعده را تغییر داده‌اند.
اما این تکنولوژی‌ها هنوز کاملاً رایج نشده‌اند و اکثریت سیستم‌عامل‌ها همین رفتار کلاسیک را دارند.
#آکادمی_روزبه
مرکز تخصصی CISSP
Www.Roozbeh.academy
👍3💯2❤1
حرکتی قابل تقدیر
مرکز مدیریت راهبردی افتا، ماه گذشته، با درخواست صدور و یا تمدید 199 مجوز شرکت‌های متقاضی فعالیت در زیرساخت‌های حیاتی کشور موافقت کرد که رشدی 4 و نیم برابری نسبت به اردیبهشت سال قبل و قریب به سه برابری فروردین امسال داشته است.
#آکادمی_روزبه
مرکز تخصصی CISSP
مشروح این خبر در سایت مرکز افتا به نشانی زیر قابل مشاهده است:
https://afta.gov.ir/fa-IR/Portal/1/news/view/14594/2223/Staging/
مرکز مدیریت راهبردی افتا، ماه گذشته، با درخواست صدور و یا تمدید 199 مجوز شرکت‌های متقاضی فعالیت در زیرساخت‌های حیاتی کشور موافقت کرد که رشدی 4 و نیم برابری نسبت به اردیبهشت سال قبل و قریب به سه برابری فروردین امسال داشته است.
#آکادمی_روزبه
مرکز تخصصی CISSP
مشروح این خبر در سایت مرکز افتا به نشانی زیر قابل مشاهده است:
https://afta.gov.ir/fa-IR/Portal/1/news/view/14594/2223/Staging/
👏3👍2
به روزرسانی رولهای سیگما
#آکادمی_روزبه
مرکز تخصصی CISSP
https://github.com/SigmaHQ/sigma/releases/tag/r2025-05-21
#آکادمی_روزبه
مرکز تخصصی CISSP
https://github.com/SigmaHQ/sigma/releases/tag/r2025-05-21
GitHub
Release Release r2025-05-21 · SigmaHQ/sigma
New Rules
new: Clfs.SYS Loaded By Process Located In a Potential Suspicious Location
new: Crash Dump Created By Operating System
new: HTTP Request to Low Reputation TLD or Suspicious File Extensio...
new: Clfs.SYS Loaded By Process Located In a Potential Suspicious Location
new: Crash Dump Created By Operating System
new: HTTP Request to Low Reputation TLD or Suspicious File Extensio...
⚡3👍2
آژانس‌های اطلاعاتی آمریکا (مثل NSA، CIA، FBI و غیره) دارن یک پورتال مرکزی به اسم Intelligence Community Data Consortium (ICDC) می‌سازن که بهشون اجازه می‌ده خیلی راحت‌تر و متمرکز به اطلاعات شخصی حساس که از شرکت‌ها و فروشنده‌های داده می‌خرن دسترسی داشته باشن. این اطلاعات شامل مواردی مثل موقعیت مکانی موبایل‌ها، رکوردهای املاک، داده‌های زیستی (biometric)، محتوای رسانه‌های اجتماعی و … می‌شه—یعنی چیزهایی که سابقاً گرفتنش نیازمند اجازه قاضی و مراحل قضایی بود.
حالا همه این اطلاعات، راحت و سریع، توی یه پورتال و بازار داده‌ای (data marketplace) جمع می‌شه و آژانس‌ها می‌تونن با استفاده از ابزارهای هوش مصنوعی اونها رو تحلیل کنن، در حالی‌که قبلاً هرکدوم جدا جدا باید خریداری می‌کردن.
منتقدها می‌گن این پلتفرم راهی برای دور زدن قوانین مربوط به حریم خصوصی و متمم چهارم قانون اساسی آمریکاست. یعنی دولت با خرید داده از شرکت‌ها داره اطلاعات مردم رو جمع می‌کنه، بدون اینکه نیاز به دستور قضایی داشته باشه.
دولت میگه می‌خواد با این پلتفرم کارها رو بهینه، هزینه‌ها رو کم و خرید تکراری داده رو حذف کنه، اما جواب نداده که دقیقاً چطور با حفظ حقوق شهروندی قرار داده‌ها رو مدیریت کنه یا از چه داده‌هایی استفاده می‌شه.
https://theintercept.com/2025/05/22/intel-agencies-buying-data-portal-privacy/
حالا همه این اطلاعات، راحت و سریع، توی یه پورتال و بازار داده‌ای (data marketplace) جمع می‌شه و آژانس‌ها می‌تونن با استفاده از ابزارهای هوش مصنوعی اونها رو تحلیل کنن، در حالی‌که قبلاً هرکدوم جدا جدا باید خریداری می‌کردن.
منتقدها می‌گن این پلتفرم راهی برای دور زدن قوانین مربوط به حریم خصوصی و متمم چهارم قانون اساسی آمریکاست. یعنی دولت با خرید داده از شرکت‌ها داره اطلاعات مردم رو جمع می‌کنه، بدون اینکه نیاز به دستور قضایی داشته باشه.
دولت میگه می‌خواد با این پلتفرم کارها رو بهینه، هزینه‌ها رو کم و خرید تکراری داده رو حذف کنه، اما جواب نداده که دقیقاً چطور با حفظ حقوق شهروندی قرار داده‌ها رو مدیریت کنه یا از چه داده‌هایی استفاده می‌شه.
https://theintercept.com/2025/05/22/intel-agencies-buying-data-portal-privacy/
The Intercept
U.S. Spy Agencies Are Getting a One-Stop Shop to Buy Your Most Sensitive Personal Data
The government wants to build a centralized platform where spy agencies can more easily buy private info about millions of people.
👍3🙏1
تحلیل و مقابله با حمله BadSuccessor: آسیب‌پذیری جدید در Microsoft Active Directory Certificate Services
✍️روزبه نوروزی
مقدمه
در سال‌های اخیر، حملات به زیرساخت‌های هویتی مانند Active Directory (AD) و Active Directory Certificate Services (ADCS) به شدت افزایش یافته است. این حملات معمولاً با سوءاستفاده از پیکربندی‌های نادرست، آسیب‌پذیری‌های نرم‌افزاری یا اِشکال در فرآیندهای صدور گواهی اتفاق می‌افتد. در ماه می ۲۰۲۵، تیم تحقیقاتی SpecterOps حمله جدیدی با نام BadSuccessor معرفی کرد که نقطه ضعف جدیدی را در سازوکار CA (Certificate Authority) مایکروسافت افشا می‌کند. این آسیب‌پذیری به مهاجمان امکان می‌دهد که حتی پس از جابه‌جایی یا بازنشست کردن یک CA قدیمی، همچنان گواهی‌های مخرب صادر کنند و زنجیره اعتماد را تضعیف نمایند.
ساختار Active Directory و اهمیت ADCS
سرویس Active Directory Certificate Services (ADCS) یکی از سرویس‌های کلیدی در مایکروسافت اکوسیستم است که امکان صدور، مدیریت و اعتبارسنجی گواهی‌های دیجیتال را برای شبکه‌های داخلی فراهم می‌کند. با صدور گواهی‌های SSL/TLS، گواهی‌های ورود دستگاه و کاربر و حتی انجام فرآیندهای رمزگذاری ایمیل، ADCS هسته امنیتی بسیاری از شبکه‌های سازمانی به حساب می‌آید. هرگونه آسیب‌پذیری در این سرویس می‌تواند موجب دسترسی غیرمجاز، جعل هویت یا حملات پیشرفته (مانند Golden Ticket) گردد.
حمله BadSuccessor دقیقا چیست؟
حمله BadSuccessor یک آسیب‌پذیری منطقی است که فرآیند مدیریت چرخه عمر کلیدهای CA را هدف قرار می‌دهد؛ به‌خصوص درحالتی که یک CA بازنشسته (Retired CA) با CA دیگری جایگزین میشود (در اصطلاح، Successor CA). شبکه‌ها معمولاً پس از بازنشسته کردن CA قدیمی (مثلا به خاطر انقضای کلید یا آپگرید به الگوریتم‌های مدرن‌تر)، CA جدیدی به عنوان Successor معرفی می‌کنند و انتظار دارند زنجیره اعتبار همچنان برقرار اما امن‌تر باشد.
اینجاست که مشکل پیش می‌آید:
این CA Successor (جدید) می‌تواند همچنان به عنوان صادرکننده تایید شده توسط زنجیره اصلی معرفی شود، اما مکانیزم بررسی revocation یا لغو اعتبار CA قدیمی معمولا ناکافی است.
مهاجم می‌تواند گواهی‌ای تقلبی صادرشده توسط CA بازنشسته وارد کند و شبکه یا کلاینت تصور می‌کند چون Successor معرفی شده و زنجیره معتبر است، این گواهی باید قابل اعتماد باشد.
این آسیب‌پذیری ناشی از نحوه ذخیره‌سازی و بررسی فیلد CA Successor در ADCS است.
عملکرد فنی BadSuccessor
برای درک تاثیر این حمله، باید بدانیم پس از بازنشست شدن CA، زنجیره گواهی‌ها از طریق اکستنشن CA Version و رکورد successor در AD به‌هم متصل می‌شوند. در سناریوی واقعی:
سازمان CA قدیمی را بازنشسته می‌کند و CA جدید را به عنوان successor ثبت می‌کند.
این CA قدیمی می‌تواند یا باید غیر فعال و کلیدش حذف شود؛ اما اغلب بنا به اشتباه نگهداری یا پیکربندی ناقص، این کلید و دسترسی‌ها باقی می‌ماند.
مهاجم، اگر کنترل یا دسترسی به کلید خصوصی CA قدیمی یا سیستم مرتبط را داشته باشد، می‌تواند همچنان گواهی مطابق با زنجیره موردقبول صادر کند و آن را توسط Successor به شبکه تحمیل کند.
نکته مهم: بیشتر نرم‌افزارها و کلاینت‌ها، بررسی جدی روی زنجیره Successor انجام نمی‌دهند و صرفاً به زنجیره اعتماد (Chain of Trust) نگاه می‌کنند. همین باعث میشود گواهی جعلی با امضای CA بازنشسته اما متصل به Successor معتبر تلقی شود.
سناریوی حمله BadSuccessor
در سناریوی کلاسیک:
مهاجم دسترسی ادمینی به سیستم یا کلید خصوصی CA بازنشسته را کسب می‌کند (مثلاً از طریق هک قدیمی، باگ یا غفلت امنیتی).
یک گواهی مخرب ایجاد می‌کند (مثلاً برای برداشتن محدودیت‌های احراز هویت Kerberos یا جعل نام کاربر).
این گواهی، به خاطر زنجیره successor به راحتی به عنوان معتبر توسط کلاینت‌ها/سرویس‌ها شناخته میشود.
اثر: مسیر نفوذ تا سطح Domain Admin و حتی بالاتر (Persistence و Evasion پیشرفته).
چرا شناسایی این حمله دشوار است؟
بسیاری از ابزارهای امنیتی تمرکز خود را صرفاً بر گواهی‌های جاری دارند و کمتر به زنجیره successor و وضعیت CA بازنشسته توجه می‌کنند.
لاگینگ ناکافی بر روی فرآیند بازنشسته‌سازی CA و فعالیت‌های مرتبط.
فرض رایج (ولی غلط) مبنی بر اینکه بازنشسته کردن CA و غیر فعال‌سازی آن، به طور پیش‌فرض امنیت کافی ایجاد می‌کند.
روش‌های مقابله و Mitigation
روش‌هایی برای کاهش ریسک حمله BadSuccessor پیشنهاد شده که در اینجا جمع‌بندی شده‌اند:
ادامه در پست بعدی...👇👇
#آکادمی_روزبه
مرکز تخصصی CISSP
Www.Roozbeh.academy
✍️روزبه نوروزی
مقدمه
در سال‌های اخیر، حملات به زیرساخت‌های هویتی مانند Active Directory (AD) و Active Directory Certificate Services (ADCS) به شدت افزایش یافته است. این حملات معمولاً با سوءاستفاده از پیکربندی‌های نادرست، آسیب‌پذیری‌های نرم‌افزاری یا اِشکال در فرآیندهای صدور گواهی اتفاق می‌افتد. در ماه می ۲۰۲۵، تیم تحقیقاتی SpecterOps حمله جدیدی با نام BadSuccessor معرفی کرد که نقطه ضعف جدیدی را در سازوکار CA (Certificate Authority) مایکروسافت افشا می‌کند. این آسیب‌پذیری به مهاجمان امکان می‌دهد که حتی پس از جابه‌جایی یا بازنشست کردن یک CA قدیمی، همچنان گواهی‌های مخرب صادر کنند و زنجیره اعتماد را تضعیف نمایند.
ساختار Active Directory و اهمیت ADCS
سرویس Active Directory Certificate Services (ADCS) یکی از سرویس‌های کلیدی در مایکروسافت اکوسیستم است که امکان صدور، مدیریت و اعتبارسنجی گواهی‌های دیجیتال را برای شبکه‌های داخلی فراهم می‌کند. با صدور گواهی‌های SSL/TLS، گواهی‌های ورود دستگاه و کاربر و حتی انجام فرآیندهای رمزگذاری ایمیل، ADCS هسته امنیتی بسیاری از شبکه‌های سازمانی به حساب می‌آید. هرگونه آسیب‌پذیری در این سرویس می‌تواند موجب دسترسی غیرمجاز، جعل هویت یا حملات پیشرفته (مانند Golden Ticket) گردد.
حمله BadSuccessor دقیقا چیست؟
حمله BadSuccessor یک آسیب‌پذیری منطقی است که فرآیند مدیریت چرخه عمر کلیدهای CA را هدف قرار می‌دهد؛ به‌خصوص درحالتی که یک CA بازنشسته (Retired CA) با CA دیگری جایگزین میشود (در اصطلاح، Successor CA). شبکه‌ها معمولاً پس از بازنشسته کردن CA قدیمی (مثلا به خاطر انقضای کلید یا آپگرید به الگوریتم‌های مدرن‌تر)، CA جدیدی به عنوان Successor معرفی می‌کنند و انتظار دارند زنجیره اعتبار همچنان برقرار اما امن‌تر باشد.
اینجاست که مشکل پیش می‌آید:
این CA Successor (جدید) می‌تواند همچنان به عنوان صادرکننده تایید شده توسط زنجیره اصلی معرفی شود، اما مکانیزم بررسی revocation یا لغو اعتبار CA قدیمی معمولا ناکافی است.
مهاجم می‌تواند گواهی‌ای تقلبی صادرشده توسط CA بازنشسته وارد کند و شبکه یا کلاینت تصور می‌کند چون Successor معرفی شده و زنجیره معتبر است، این گواهی باید قابل اعتماد باشد.
این آسیب‌پذیری ناشی از نحوه ذخیره‌سازی و بررسی فیلد CA Successor در ADCS است.
عملکرد فنی BadSuccessor
برای درک تاثیر این حمله، باید بدانیم پس از بازنشست شدن CA، زنجیره گواهی‌ها از طریق اکستنشن CA Version و رکورد successor در AD به‌هم متصل می‌شوند. در سناریوی واقعی:
سازمان CA قدیمی را بازنشسته می‌کند و CA جدید را به عنوان successor ثبت می‌کند.
این CA قدیمی می‌تواند یا باید غیر فعال و کلیدش حذف شود؛ اما اغلب بنا به اشتباه نگهداری یا پیکربندی ناقص، این کلید و دسترسی‌ها باقی می‌ماند.
مهاجم، اگر کنترل یا دسترسی به کلید خصوصی CA قدیمی یا سیستم مرتبط را داشته باشد، می‌تواند همچنان گواهی مطابق با زنجیره موردقبول صادر کند و آن را توسط Successor به شبکه تحمیل کند.
نکته مهم: بیشتر نرم‌افزارها و کلاینت‌ها، بررسی جدی روی زنجیره Successor انجام نمی‌دهند و صرفاً به زنجیره اعتماد (Chain of Trust) نگاه می‌کنند. همین باعث میشود گواهی جعلی با امضای CA بازنشسته اما متصل به Successor معتبر تلقی شود.
سناریوی حمله BadSuccessor
در سناریوی کلاسیک:
مهاجم دسترسی ادمینی به سیستم یا کلید خصوصی CA بازنشسته را کسب می‌کند (مثلاً از طریق هک قدیمی، باگ یا غفلت امنیتی).
یک گواهی مخرب ایجاد می‌کند (مثلاً برای برداشتن محدودیت‌های احراز هویت Kerberos یا جعل نام کاربر).
این گواهی، به خاطر زنجیره successor به راحتی به عنوان معتبر توسط کلاینت‌ها/سرویس‌ها شناخته میشود.
اثر: مسیر نفوذ تا سطح Domain Admin و حتی بالاتر (Persistence و Evasion پیشرفته).
چرا شناسایی این حمله دشوار است؟
بسیاری از ابزارهای امنیتی تمرکز خود را صرفاً بر گواهی‌های جاری دارند و کمتر به زنجیره successor و وضعیت CA بازنشسته توجه می‌کنند.
لاگینگ ناکافی بر روی فرآیند بازنشسته‌سازی CA و فعالیت‌های مرتبط.
فرض رایج (ولی غلط) مبنی بر اینکه بازنشسته کردن CA و غیر فعال‌سازی آن، به طور پیش‌فرض امنیت کافی ایجاد می‌کند.
روش‌های مقابله و Mitigation
روش‌هایی برای کاهش ریسک حمله BadSuccessor پیشنهاد شده که در اینجا جمع‌بندی شده‌اند:
ادامه در پست بعدی...👇👇
#آکادمی_روزبه
مرکز تخصصی CISSP
Www.Roozbeh.academy
👍3❤1👏1