👆👆ادامه از پست قبل
اپلیکیشن‌های هوش مصنوعی دائم به‌روز و بدون نیاز به تغییرات اساسی (Flexible Upgrades)
ویندوز به بستری برای اجرای مدل‌های متنوع از شرکت‌های مختلف تبدیل میشود
آسان‌تر شدن دسترسی توسعه‌دهندگان، پژوهشگران و حتی کاربران عادی به قابلیت‌های برتر هر مدل
امکان ترکیب مدل‌ها برای اپلیکیشن‌های تخصصی (مثلاً ترجمه همزمان صوتی، پردازش تصویر/زبان و…)
تاثیر بر رقابت و اکوسیستم مدل‌های زبانی
مایکروسافت با این حرکت نه‌تنها کاربران ویندوز بلکه شرکت‌های رقیب مانند گوگل، اپل، آمازون، OpenAI، Anthropic و غیره را هم به این استاندارد دعوت می‌کند.
مهم‌ترین پیامدهای این حرکت:
کاهش انحصارگرایی مدل‌های بزرگ
ترغیب به استانداردسازی و همکاری بین‌المللی
جلوگیری از قفل شدن کاربرها در اکوسیستم یک شرکت خاص (Vendor Lock-in)
الزام‌های امنیتی و چالش‌های احتمالی
استانداردی شدن اتصال مدل‌های AI مثل هر تکنولوژی محبوب (نظیر USB) چالش‌های امنیتی مخصوص به خود را دارد:
نیاز به تایید اصالت و اعتبار مدل‌های اضافه شده (Model Authentication)
حفاظت از داده‌ی شخصی در هنگام ارتباط اپلیکیشن و مدل (Data Privacy)
مدیریت سطوح دسترسی و کنترل بر نحوه استفاده از مدل‌ها توسط کاربران یا سازمان‌ها
پوشش‌دهی ریسک افزونه‌های مخرب یا مدل‌های جعلی در اکوسیستم MCP
توسعه‌دهندگان و تیم‌های امنیت نیاز دارند سیاست‌های ویژه‌ای حول اجازه دادن به مدل‌ها، لاگ‌گیری، رمزنگاری بین‌برنامه‌ای و غیره تدوین کنند.
نتیجه‌گیری: دنیای هوش مصنوعی بازتر و آزادتر برای ویندوز
پروتکل MCP همزمان با پیشرفت‌های سخت‌افزار (AI-PCها) و نرم‌افزار، اجزای دنیای هوش مصنوعی را مثل قطعه‌های یک پازل کنار هم می‌گذارد. برندگان اصلی، اکوسیستمی باز، تنوع بالا، سرعت نوآوری، و کاربران و شرکت‌هایی خواهند بود که دیگر محدود به یک سرویس یا مدل خاص نیستند.
مایکروسافت با شجاعت و پیشگامی در استانداردسازی اتصال AI گامی بزرگ برداشت و چشم‌انداز آینده‌ی ویندوز، بستری کاملاً داینامیک و دوست‌دار توسعه‌دهندگان و کاربران حرفه‌ای خواهد بود.
#آکادمی_روزبه
مرکز تخصصی CISSP
اپلیکیشن‌های هوش مصنوعی دائم به‌روز و بدون نیاز به تغییرات اساسی (Flexible Upgrades)
ویندوز به بستری برای اجرای مدل‌های متنوع از شرکت‌های مختلف تبدیل میشود
آسان‌تر شدن دسترسی توسعه‌دهندگان، پژوهشگران و حتی کاربران عادی به قابلیت‌های برتر هر مدل
امکان ترکیب مدل‌ها برای اپلیکیشن‌های تخصصی (مثلاً ترجمه همزمان صوتی، پردازش تصویر/زبان و…)
تاثیر بر رقابت و اکوسیستم مدل‌های زبانی
مایکروسافت با این حرکت نه‌تنها کاربران ویندوز بلکه شرکت‌های رقیب مانند گوگل، اپل، آمازون، OpenAI، Anthropic و غیره را هم به این استاندارد دعوت می‌کند.
مهم‌ترین پیامدهای این حرکت:
کاهش انحصارگرایی مدل‌های بزرگ
ترغیب به استانداردسازی و همکاری بین‌المللی
جلوگیری از قفل شدن کاربرها در اکوسیستم یک شرکت خاص (Vendor Lock-in)
الزام‌های امنیتی و چالش‌های احتمالی
استانداردی شدن اتصال مدل‌های AI مثل هر تکنولوژی محبوب (نظیر USB) چالش‌های امنیتی مخصوص به خود را دارد:
نیاز به تایید اصالت و اعتبار مدل‌های اضافه شده (Model Authentication)
حفاظت از داده‌ی شخصی در هنگام ارتباط اپلیکیشن و مدل (Data Privacy)
مدیریت سطوح دسترسی و کنترل بر نحوه استفاده از مدل‌ها توسط کاربران یا سازمان‌ها
پوشش‌دهی ریسک افزونه‌های مخرب یا مدل‌های جعلی در اکوسیستم MCP
توسعه‌دهندگان و تیم‌های امنیت نیاز دارند سیاست‌های ویژه‌ای حول اجازه دادن به مدل‌ها، لاگ‌گیری، رمزنگاری بین‌برنامه‌ای و غیره تدوین کنند.
نتیجه‌گیری: دنیای هوش مصنوعی بازتر و آزادتر برای ویندوز
پروتکل MCP همزمان با پیشرفت‌های سخت‌افزار (AI-PCها) و نرم‌افزار، اجزای دنیای هوش مصنوعی را مثل قطعه‌های یک پازل کنار هم می‌گذارد. برندگان اصلی، اکوسیستمی باز، تنوع بالا، سرعت نوآوری، و کاربران و شرکت‌هایی خواهند بود که دیگر محدود به یک سرویس یا مدل خاص نیستند.
مایکروسافت با شجاعت و پیشگامی در استانداردسازی اتصال AI گامی بزرگ برداشت و چشم‌انداز آینده‌ی ویندوز، بستری کاملاً داینامیک و دوست‌دار توسعه‌دهندگان و کاربران حرفه‌ای خواهد بود.
#آکادمی_روزبه
مرکز تخصصی CISSP
👍4🙏3
اگر گفتید اشکال این مقاله چیه ؟
تا جمعه براتون میگم
#آکادمی_روزبه
مرکز تخصصی CISSP
https://medium.com/@nesrinecherrabi/hunting-scheduled-tasks-6a3ffd0d6c14
تا جمعه براتون میگم
#آکادمی_روزبه
مرکز تخصصی CISSP
https://medium.com/@nesrinecherrabi/hunting-scheduled-tasks-6a3ffd0d6c14
Medium
Hunting Scheduled Tasks
Scheduled tasks are a normal part of system operations, they help with updates, backups, and maintenance jobs. But attackers love them…
👍4⚡1
یک دوره SOC مقدماتی از مایکروسافت
#آکادمی_روزبه
مرکز تخصصی CISSP
https://microsoft.github.io/SOC/source/content/#/
#آکادمی_روزبه
مرکز تخصصی CISSP
https://microsoft.github.io/SOC/source/content/#/
🙏3👍2
تحلیل هفته
باج افزار به زبان اسپلانک
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.splunk.com/en_us/blog/security/termite-ransomware-analysis.html
باج افزار به زبان اسپلانک
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.splunk.com/en_us/blog/security/termite-ransomware-analysis.html
Splunk
Breaking Down Termite Ransomware: Infection Methods and Detections | Splunk
Deep dive into Termite ransomware: Discover its infection methods, targeted vulnerabilities (like Cleo's CVE-2024-50623), and Splunk security detections.
❤3👍3
فریم ورک 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