👆👆قسمت دوم از پست قبل
چرا مهم است؟ اگر شما تنها 60% از دارایی‌های خود را اسکن کنید، 40% باقی‌مانده یک نقطه کور بزرگ و خطرناک است. هدف باید نزدیک به 100% باشد.
تعداد آسیب‌پذیری‌های باز بر اساس شدت (Open Vulnerabilities by Severity):
چه چیزی را اندازه می‌گیرد؟ تعداد کل آسیب‌پذیری‌های شناسایی شده که هنوز رفع نشده‌اند، به تفکیک شدت
چرا مهم است؟ این متریک یک دید کلی از “بدهی امنیتی” سازمان به شما می‌دهد. هدف اصلی، به صفر رساندن تعداد آسیب‌پذیری‌های حیاتی است.
🚨 دسته ۲: پاسخ به حوادث (Incident Response)
این متریک‌ها کارایی تیم شما در شناسایی و مهار حملات را می‌سنجند.
میانگین زمان شناسایی (Mean Time to Detect - MTTD):
چه چیزی را اندازه می‌گیرد؟ میانگین زمان از لحظه وقوع یک نفوذ یا فعالیت مخرب تا لحظه‌ای که توسط تیم امنیتی شناسایی می‌شود.
چرا مهم است؟ مهاجمان هرچه زمان بیشتری به صورت شناسایی نشده در شبکه شما باقی بمانند، خسارت بیشتری وارد می‌کنند. کاهش این زمان یک اولویت اصلی برای هر تیم امنیتی است.
میانگین زمان پاسخ/مهار (Mean Time to Respond/Contain - MTTR):
چه چیزی را اندازه می‌گیرد؟ میانگین زمان از لحظه شناسایی یک حادثه تا لحظه‌ای که مهار شده و از گسترش آن جلوگیری می‌شود.
چرا مهم است؟ سرعت عمل در این مرحله می‌تواند تفاوت بین یک حادثه کوچک و یک فاجعه تمام‌عیار باشد.
تعداد حوادث امنیتی (Number of Security Incidents):
چه چیزی را اندازه می‌گیرد؟ تعداد کل حوادث امنیتی در یک دوره زمانی مشخص (مثلاً ماهانه یا فصلی)، که معمولاً بر اساس نوع یا شدت دسته‌بندی می‌شوند.
چرا مهم است؟ رصد روند این متریک به شما نشان می‌دهد که آیا اقدامات پیشگیرانه شما در حال کاهش تعداد حملات موفق هستند یا خیر.
🧑🏫 دسته ۳: آگاهی‌بخشی و کاربران (User Awareness)
کاربران اغلب ضعیف‌ترین حلقه در زنجیره امنیت هستند. این متریک‌ها میزان آگاهی آنها را می‌سنجند.
نرخ کلیک در کمپین‌های فیشینگ شبیه‌سازی شده (Phishing Simulation Click Rate):
چه چیزی را اندازه می‌گیرد؟ درصدی از کارمندان که روی لینک‌ها یا پیوست‌های ایمیل‌های فیشینگ شبیه‌سازی شده کلیک می‌کنند.
چرا مهم است؟ این متریک یک شاخص مستقیم از میزان آگاهی کاربران و تأثیرگذاری برنامه‌های آموزشی است. هدف، کاهش مداوم این درصد است.
نرخ گزارش ایمیل‌های مشکوک توسط کاربران (User-Reported Phishing Rate):
چه چیزی را اندازه می‌گیرد؟ تعداد ایمیل‌های مشکوکی که کاربران به تیم امنیتی گزارش می‌دهند.
چرا مهم است؟ برخلاف تصور، افزایش این متریک یک نشانه مثبت است! این یعنی کاربران شما هوشیار شده‌اند و به جای قربانی شدن، به عنوان یک “سنسور انسانی” برای تیم امنیتی عمل می‌کنند.
⚙️ دسته ۴: سلامت عملیات امنیتی (Security Operations Health)
این متریک‌ها نشان می‌دهند که آیا ابزارها و فرآیندهای امنیتی شما به درستی کار می‌کنند یا خیر.
درصد سیستم‌های منطبق با سیاست‌ها (Policy Compliance):
چه چیزی را اندازه می‌گیرد؟ چه درصدی از سیستم‌ها (مانند سرورها و لپ‌تاپ‌ها) با استانداردهای امنیتی سازمان (مثلاً داشتن آنتی‌ویروس به‌روز، رمزگذاری دیسک، و …) مطابقت دارند.
چرا مهم است؟ این متریک به شما کمک می‌کند تا شکاف‌های ناشی از پیکربندی‌های نادرست را شناسایی و رفع کنید.
آپ‌تایم ابزارهای امنیتی (Security Tool Uptime):
چه چیزی را اندازه می‌گیرد؟ درصدی از زمان که ابزارهای حیاتی امنیتی شما (مانند فایروال، SIEM، EDR) فعال و در حال کار هستند.
چرا مهم است؟ یک ابزار امنیتی که خاموش است، هیچ ارزشی ندارد. هدف باید نزدیک به 100% باشد.
نتیجه‌گیری
متریک‌ها ستون فقرات یک برنامه امنیت سایبری مدرن و بالغ هستند. آنها به سازمان‌ها کمک می‌کنند تا:
از وضعیت واقعی خود آگاه شوند.
منابع خود را به صورت هوشمندانه تخصیص دهند.
ارزش سرمایه‌گذاری‌های امنیتی را به مدیران نشان دهند.
به طور مداوم بهبود یابند و از رقبا و مهاجمان یک قدم جلوتر باشند.
مهم‌ترین نکته این است که با چند متریک کلیدی و قابل اجرا شروع کنید، فرآیند جمع‌آوری داده را تا حد امکان خودکار کنید و به طور منظم این متریک‌ها را بازبینی کرده و بر اساس آنها اقدام کنید.
#آکادمی_روزبه
مرکز تخصصی CISSP
Www.Roozbeh.academy
چرا مهم است؟ اگر شما تنها 60% از دارایی‌های خود را اسکن کنید، 40% باقی‌مانده یک نقطه کور بزرگ و خطرناک است. هدف باید نزدیک به 100% باشد.
تعداد آسیب‌پذیری‌های باز بر اساس شدت (Open Vulnerabilities by Severity):
چه چیزی را اندازه می‌گیرد؟ تعداد کل آسیب‌پذیری‌های شناسایی شده که هنوز رفع نشده‌اند، به تفکیک شدت
چرا مهم است؟ این متریک یک دید کلی از “بدهی امنیتی” سازمان به شما می‌دهد. هدف اصلی، به صفر رساندن تعداد آسیب‌پذیری‌های حیاتی است.
🚨 دسته ۲: پاسخ به حوادث (Incident Response)
این متریک‌ها کارایی تیم شما در شناسایی و مهار حملات را می‌سنجند.
میانگین زمان شناسایی (Mean Time to Detect - MTTD):
چه چیزی را اندازه می‌گیرد؟ میانگین زمان از لحظه وقوع یک نفوذ یا فعالیت مخرب تا لحظه‌ای که توسط تیم امنیتی شناسایی می‌شود.
چرا مهم است؟ مهاجمان هرچه زمان بیشتری به صورت شناسایی نشده در شبکه شما باقی بمانند، خسارت بیشتری وارد می‌کنند. کاهش این زمان یک اولویت اصلی برای هر تیم امنیتی است.
میانگین زمان پاسخ/مهار (Mean Time to Respond/Contain - MTTR):
چه چیزی را اندازه می‌گیرد؟ میانگین زمان از لحظه شناسایی یک حادثه تا لحظه‌ای که مهار شده و از گسترش آن جلوگیری می‌شود.
چرا مهم است؟ سرعت عمل در این مرحله می‌تواند تفاوت بین یک حادثه کوچک و یک فاجعه تمام‌عیار باشد.
تعداد حوادث امنیتی (Number of Security Incidents):
چه چیزی را اندازه می‌گیرد؟ تعداد کل حوادث امنیتی در یک دوره زمانی مشخص (مثلاً ماهانه یا فصلی)، که معمولاً بر اساس نوع یا شدت دسته‌بندی می‌شوند.
چرا مهم است؟ رصد روند این متریک به شما نشان می‌دهد که آیا اقدامات پیشگیرانه شما در حال کاهش تعداد حملات موفق هستند یا خیر.
🧑🏫 دسته ۳: آگاهی‌بخشی و کاربران (User Awareness)
کاربران اغلب ضعیف‌ترین حلقه در زنجیره امنیت هستند. این متریک‌ها میزان آگاهی آنها را می‌سنجند.
نرخ کلیک در کمپین‌های فیشینگ شبیه‌سازی شده (Phishing Simulation Click Rate):
چه چیزی را اندازه می‌گیرد؟ درصدی از کارمندان که روی لینک‌ها یا پیوست‌های ایمیل‌های فیشینگ شبیه‌سازی شده کلیک می‌کنند.
چرا مهم است؟ این متریک یک شاخص مستقیم از میزان آگاهی کاربران و تأثیرگذاری برنامه‌های آموزشی است. هدف، کاهش مداوم این درصد است.
نرخ گزارش ایمیل‌های مشکوک توسط کاربران (User-Reported Phishing Rate):
چه چیزی را اندازه می‌گیرد؟ تعداد ایمیل‌های مشکوکی که کاربران به تیم امنیتی گزارش می‌دهند.
چرا مهم است؟ برخلاف تصور، افزایش این متریک یک نشانه مثبت است! این یعنی کاربران شما هوشیار شده‌اند و به جای قربانی شدن، به عنوان یک “سنسور انسانی” برای تیم امنیتی عمل می‌کنند.
⚙️ دسته ۴: سلامت عملیات امنیتی (Security Operations Health)
این متریک‌ها نشان می‌دهند که آیا ابزارها و فرآیندهای امنیتی شما به درستی کار می‌کنند یا خیر.
درصد سیستم‌های منطبق با سیاست‌ها (Policy Compliance):
چه چیزی را اندازه می‌گیرد؟ چه درصدی از سیستم‌ها (مانند سرورها و لپ‌تاپ‌ها) با استانداردهای امنیتی سازمان (مثلاً داشتن آنتی‌ویروس به‌روز، رمزگذاری دیسک، و …) مطابقت دارند.
چرا مهم است؟ این متریک به شما کمک می‌کند تا شکاف‌های ناشی از پیکربندی‌های نادرست را شناسایی و رفع کنید.
آپ‌تایم ابزارهای امنیتی (Security Tool Uptime):
چه چیزی را اندازه می‌گیرد؟ درصدی از زمان که ابزارهای حیاتی امنیتی شما (مانند فایروال، SIEM، EDR) فعال و در حال کار هستند.
چرا مهم است؟ یک ابزار امنیتی که خاموش است، هیچ ارزشی ندارد. هدف باید نزدیک به 100% باشد.
نتیجه‌گیری
متریک‌ها ستون فقرات یک برنامه امنیت سایبری مدرن و بالغ هستند. آنها به سازمان‌ها کمک می‌کنند تا:
از وضعیت واقعی خود آگاه شوند.
منابع خود را به صورت هوشمندانه تخصیص دهند.
ارزش سرمایه‌گذاری‌های امنیتی را به مدیران نشان دهند.
به طور مداوم بهبود یابند و از رقبا و مهاجمان یک قدم جلوتر باشند.
مهم‌ترین نکته این است که با چند متریک کلیدی و قابل اجرا شروع کنید، فرآیند جمع‌آوری داده را تا حد امکان خودکار کنید و به طور منظم این متریک‌ها را بازبینی کرده و بر اساس آنها اقدام کنید.
#آکادمی_روزبه
مرکز تخصصی CISSP
Www.Roozbeh.academy
❤4🤝2
مدیر امنیت زیر نظر کی باشه؟
شاید زمان تغییر نظر فرا رسیده
**روزبه نوروزی
Www.Roozbeh.academy
مشکل سنتی: درگیری و تعارض منافع مدیر امنیت و مدیر IT
مدیر IT (مثلاً CTO یا IT Manager) وظیفه‌اش «کارایی، دسترس‌پذیری و ارائه خدمات سریع» است.
تیم امنیت معمولاً دنبال «کاهش ریسک، حفاظت، و کنترل قوی» است.
اگر CISO یا سرپرست امنیت زیرمجموعه IT باشد، معمولاً تصمیمات امنیتی تحت فشار نیازهای عملیاتی ضعیف می‌شود.
اگر امنیت مستقیماً زیر نظر CEO باشد، قدرت و استقلال دارد، اما اینجا ریسک تعامل ضعیف و اصطکاک با IT زیاد می‌شود.
و اما راهکار SecOps: اتحاد بجای جدایی کامل یا ادغام کامل
در SecOps به معنی حذف کامل مرز نیست، بلکه ایجاد یک فرهنگ و ساختار همکاری عمیق بین IT و امنیت است.
مدیریت چند-تخصصی: به جای اینکه مدیر امنیت و مدیر IT مستقیماً زیر نظر CEO یا CTO باشند، هر دو زیر نظر یک مدیر عملیاتی ارشد (مثلاً COO یا Chief Digital Officer) قرار می‌گیرند که مسئول «امنیت + کارایی + تحول دیجیتال» است.
تیم‌ها عملاً جدا هستند، اما مجبور به هم‌افزایی و پاسخگویی به یک هدف مشترک می‌شوند:
پروژه‌ها، تغییرات، پیکربندی‌ها و حتی رخدادها با مشارکت همزمان تخصص IT و امنیت پیش می‌رود.
تیم‌های خرد (Squads) تشکیل می‌شود که هردو توان IT و Security را دارند (مثلاً یک Cloud Admin و یک Cloud Security Engineer در یک تیم محصول یا عملیات).
3. ویژگی‌های این ساختار (به سبک SecOps):
همه فرآیندها (از طراحی تا عملیات) هم زمان هم امنیت و هم IT را پوشش می‌دهد.
گزارش‌دهی و پاسخگویی شفاف است: هم IT و هم Security به یک مدیر مشترک پاسخ می‌دهند که تعادل را برقرار می‌کند.
جلوگیری از فرافکنی: زمانی که رخداد یا اختلالی پیش می‌آید، مسیر حل مشکل ترکیب تخصصی دارد و همه مسئولند.
افزایش سرعت و امنیت: تیم پروژه از همان اول، هم رشد و هم ریسک را می‌بیند.
کاهش تعارضات و مقاومت‌ها چون همه اهداف کلان سازمان (Agility + Security + Availability) همزمان دنبال می‌شود.
این SecOps پیشنهادش «زدودن مرز سفت و سخت» بین IT و امنیت نیست بلکه ایجاد یک هویت مشترک عملیاتی است که هر دو تیم، با مسئولیت‌پذیری مشترک، به یک مدیر ارشد (به جای CEO یا CTO صرفاً) متصل باشند و فرهنگ همکاری عمیق و روزانه داشته باشند. این ساختار هم استقلال نسبی به امنیت می‌دهد، هم IT را از سختگیری‌های بی‌منطق دور نگه می‌دارد، و هم به چابکی کسب‌وکار کمک می‌کند.
به نظرتون این ساختار ممکنه چه نکات و شاید اشکالاتی داشته باشه که لازم هست بررسی بشه؟
** ۷ سال پیش در یکی از بانک‌ها CISO رو بردیم زیر نظر CEO ولی بعدش مشکلاتش رو دیدم . الان دارم واسه یه پتروشیمی این ساختار جدید رو پیاده میکنم.
#آکادمی_روزبه
مرکز تخصصی CISSP
شاید زمان تغییر نظر فرا رسیده
**روزبه نوروزی
Www.Roozbeh.academy
مشکل سنتی: درگیری و تعارض منافع مدیر امنیت و مدیر IT
مدیر IT (مثلاً CTO یا IT Manager) وظیفه‌اش «کارایی، دسترس‌پذیری و ارائه خدمات سریع» است.
تیم امنیت معمولاً دنبال «کاهش ریسک، حفاظت، و کنترل قوی» است.
اگر CISO یا سرپرست امنیت زیرمجموعه IT باشد، معمولاً تصمیمات امنیتی تحت فشار نیازهای عملیاتی ضعیف می‌شود.
اگر امنیت مستقیماً زیر نظر CEO باشد، قدرت و استقلال دارد، اما اینجا ریسک تعامل ضعیف و اصطکاک با IT زیاد می‌شود.
و اما راهکار SecOps: اتحاد بجای جدایی کامل یا ادغام کامل
در SecOps به معنی حذف کامل مرز نیست، بلکه ایجاد یک فرهنگ و ساختار همکاری عمیق بین IT و امنیت است.
مدیریت چند-تخصصی: به جای اینکه مدیر امنیت و مدیر IT مستقیماً زیر نظر CEO یا CTO باشند، هر دو زیر نظر یک مدیر عملیاتی ارشد (مثلاً COO یا Chief Digital Officer) قرار می‌گیرند که مسئول «امنیت + کارایی + تحول دیجیتال» است.
تیم‌ها عملاً جدا هستند، اما مجبور به هم‌افزایی و پاسخگویی به یک هدف مشترک می‌شوند:
پروژه‌ها، تغییرات، پیکربندی‌ها و حتی رخدادها با مشارکت همزمان تخصص IT و امنیت پیش می‌رود.
تیم‌های خرد (Squads) تشکیل می‌شود که هردو توان IT و Security را دارند (مثلاً یک Cloud Admin و یک Cloud Security Engineer در یک تیم محصول یا عملیات).
3. ویژگی‌های این ساختار (به سبک SecOps):
همه فرآیندها (از طراحی تا عملیات) هم زمان هم امنیت و هم IT را پوشش می‌دهد.
گزارش‌دهی و پاسخگویی شفاف است: هم IT و هم Security به یک مدیر مشترک پاسخ می‌دهند که تعادل را برقرار می‌کند.
جلوگیری از فرافکنی: زمانی که رخداد یا اختلالی پیش می‌آید، مسیر حل مشکل ترکیب تخصصی دارد و همه مسئولند.
افزایش سرعت و امنیت: تیم پروژه از همان اول، هم رشد و هم ریسک را می‌بیند.
کاهش تعارضات و مقاومت‌ها چون همه اهداف کلان سازمان (Agility + Security + Availability) همزمان دنبال می‌شود.
این SecOps پیشنهادش «زدودن مرز سفت و سخت» بین IT و امنیت نیست بلکه ایجاد یک هویت مشترک عملیاتی است که هر دو تیم، با مسئولیت‌پذیری مشترک، به یک مدیر ارشد (به جای CEO یا CTO صرفاً) متصل باشند و فرهنگ همکاری عمیق و روزانه داشته باشند. این ساختار هم استقلال نسبی به امنیت می‌دهد، هم IT را از سختگیری‌های بی‌منطق دور نگه می‌دارد، و هم به چابکی کسب‌وکار کمک می‌کند.
به نظرتون این ساختار ممکنه چه نکات و شاید اشکالاتی داشته باشه که لازم هست بررسی بشه؟
** ۷ سال پیش در یکی از بانک‌ها CISO رو بردیم زیر نظر CEO ولی بعدش مشکلاتش رو دیدم . الان دارم واسه یه پتروشیمی این ساختار جدید رو پیاده میکنم.
#آکادمی_روزبه
مرکز تخصصی CISSP
👍6🙏3
آسیب پذیری های فرآیند ها
چالشی قابل رفع با Red teaming
بخش اول: آسیب‌پذیری‌های فرآیندی (Process Vulnerabilities) چیستند؟
آسیب‌پذیری فرآیندی، نقصی در یک رویه یا سیاست سازمانی است که می‌تواند توسط یک مهاجم برای به خطر انداختن امنیت، دسترسی به اطلاعات حساس، یا ایجاد اختلال در عملیات تجاری مورد سوءاستفاده قرار گیرد. این آسیب‌پذیری‌ها معمولاً توسط اسکنرهای امنیتی خودکار قابل شناسایی نیستند، زیرا در منطق و عملکرد انسانی سازمان نهفته‌اند.
مثال‌های رایج از آسیب‌پذیری‌های فرآیندی:
فرآیندهای ضعیف مدیریت هویت و دسترسی (Identity and Access Management - IAM):
عملیات Onboarding/Offboarding کارکنان: فرآیند اعطای دسترسی به کارمندان جدید ممکن است بیش از حد لازم باشد (اصل حداقل دسترسی یا Principle of Least Privilege نقض شود). خطرناک‌تر از آن، فرآیند لغو دسترسی کارمندی که سازمان را ترک کرده، ممکن است ناقص یا با تأخیر انجام شود و یک حساب کاربری فعال با دسترسی‌های بالا باقی بماند.
تغییر نقش: وقتی کارمندی از یک بخش به بخش دیگر منتقل می‌شود، دسترسی‌های قبلی او لغو نمیشود و به مرور زمان، فرد مجموعه‌ای از دسترسی‌های غیرضروری را انباشته می‌کند (Privilege Creep).
فرآیندهای ضعیف مدیریت تغییر (Change Management):
تغییرات اعمال‌شده بر روی سیستم‌های حیاتی (مانند دیوار آتش یا سرورهای اصلی) بدون بررسی امنیتی کافی یا مستندسازی مناسب. یک مهاجم می‌تواند از یک تغییر ناامن برای نفوذ به شبکه بهره‌برداری کند.
نبود یا ضعف در فرآیندهای پاسخ به حوادث (Incident Response):
سازمان طرح مشخصی برای شناسایی، مهار و ریشه‌کن کردن یک حمله سایبری ندارد. در نتیجه، هنگام وقوع یک حادثه واقعی، سردرگمی، تأخیر و تصمیمات نادرست منجر به افزایش خسارت می‌شود.
ضعف در آگاهی‌رسانی امنیتی و آموزش کارکنان:
کارمندان در مورد حملات فیشینگ، مهندسی اجتماعی یا نحوه مدیریت داده‌های حساس به درستی آموزش ندیده‌اند. این آسیب‌پذیری انسانی، دروازه اصلی بسیاری از حملات موفق است.
سیاست‌های ضعیف مدیریت رمز عبور:
اجبار نکردن استفاده از رمزهای عبور پیچیده، عدم وجود سیاست انقضای رمز عبور، یا اجازه استفاده مجدد از رمزهای قدیمی.
فرآیندهای فیزیکی ناامن:
عدم وجود کنترل دسترسی مناسب به اتاق سرور، اجازه ورود افراد ناشناس به ساختمان بدون احراز هویت، یا روش‌های ناامن برای از بین بردن اسناد فیزیکی حاوی اطلاعات حساس.
بخش دوم: تیم قرمز (Red Teaming)؛ شبیه‌ساز حملات واقعی
تیم قرمز یک گروه متخصص امنیت است که وظیفه آن، به چالش کشیدن امنیت یک سازمان از طریق شبیه‌سازی حملات یک مهاجم واقعی، با انگیزه و با منابع کافی است. هدف اصلی تیم قرمز، صرفاً پیدا کردن یک لیست از آسیب‌پذیری‌ها نیست (مانند کاری که در تست نفوذ سنتی انجام می‌شود)، بلکه ارزیابی جامع توانایی‌های دفاعی سازمان (شامل افراد، فرآیندها و تکنولوژی) در برابر یک تهدید واقعی و مستمر است.
ویژگی‌های کلیدی یک عملیات تیم قرمز:
هدف‌محور (Objective-Driven): عملیات با یک هدف مشخص شروع می‌شود، مانند “دسترسی به پایگاه داده مشتریان” یا “ایجاد اختلال در خط تولید”.
شبیه‌سازی تهدید (Threat Emulation): تیم قرمز از تاکتیک‌ها، تکنیک‌ها و رویه‌های (TTPs) گروه‌های مهاجم واقعی (APTها) استفاده می‌کند.
چندوجهی (Multi-faceted): حمله تنها به یک لایه محدود نمیشود و می‌تواند شامل جنبه‌های فنی (هک شبکه)، فیزیکی (ورود به ساختمان) و انسانی (مهندسی اجتماعی) باشد.
مخفیانه (Stealthy): تیم قرمز تلاش می‌کند تا حد امکان توسط تیم دفاعی سازمان (تیم آبی یا Blue Team) شناسایی نشود تا بتواند توانایی‌های شناسایی و پاسخ آنها را به طور واقعی ارزیابی کند.
تمرکز بر زنجیره حمله (Kill Chain): تیم قرمز کل مراحل یک حمله را از شناسایی اولیه تا رسیدن به هدف نهایی شبیه‌سازی می‌کند.
بخش سوم: هم‌افزایی تیم قرمز و کشف آسیب‌پذیری‌های فرآیندی
ارتباط بین تیم قرمز و آسیب‌پذیری‌های فرآیندی در اینجا مشخص می‌شود: تیم قرمز بهترین ابزار برای کشف و اثبات وجود آسیب‌پذیری‌های فرآیندی است.
یک اسکنر نمی‌تواند تشخیص دهد که فرآیند Offboarding شما ضعیف است، اما تیم قرمز می‌تواند:
شناسایی: تیم قرمز لیستی از کارمندان سابق را از منابع عمومی مانند LinkedIn پیدا می‌کند.
آزمون: سعی می‌کند با استفاده از اطلاعات کاربری آنها (مثلاً firstname.lastname@company.com) به سیستم‌های خارجی مانند VPN یا ایمیل متصل شود.
ادامه در پست بعد ....
#آکادمی_روزبه
مرکز تخصصی CISSP
چالشی قابل رفع با Red teaming
بخش اول: آسیب‌پذیری‌های فرآیندی (Process Vulnerabilities) چیستند؟
آسیب‌پذیری فرآیندی، نقصی در یک رویه یا سیاست سازمانی است که می‌تواند توسط یک مهاجم برای به خطر انداختن امنیت، دسترسی به اطلاعات حساس، یا ایجاد اختلال در عملیات تجاری مورد سوءاستفاده قرار گیرد. این آسیب‌پذیری‌ها معمولاً توسط اسکنرهای امنیتی خودکار قابل شناسایی نیستند، زیرا در منطق و عملکرد انسانی سازمان نهفته‌اند.
مثال‌های رایج از آسیب‌پذیری‌های فرآیندی:
فرآیندهای ضعیف مدیریت هویت و دسترسی (Identity and Access Management - IAM):
عملیات Onboarding/Offboarding کارکنان: فرآیند اعطای دسترسی به کارمندان جدید ممکن است بیش از حد لازم باشد (اصل حداقل دسترسی یا Principle of Least Privilege نقض شود). خطرناک‌تر از آن، فرآیند لغو دسترسی کارمندی که سازمان را ترک کرده، ممکن است ناقص یا با تأخیر انجام شود و یک حساب کاربری فعال با دسترسی‌های بالا باقی بماند.
تغییر نقش: وقتی کارمندی از یک بخش به بخش دیگر منتقل می‌شود، دسترسی‌های قبلی او لغو نمیشود و به مرور زمان، فرد مجموعه‌ای از دسترسی‌های غیرضروری را انباشته می‌کند (Privilege Creep).
فرآیندهای ضعیف مدیریت تغییر (Change Management):
تغییرات اعمال‌شده بر روی سیستم‌های حیاتی (مانند دیوار آتش یا سرورهای اصلی) بدون بررسی امنیتی کافی یا مستندسازی مناسب. یک مهاجم می‌تواند از یک تغییر ناامن برای نفوذ به شبکه بهره‌برداری کند.
نبود یا ضعف در فرآیندهای پاسخ به حوادث (Incident Response):
سازمان طرح مشخصی برای شناسایی، مهار و ریشه‌کن کردن یک حمله سایبری ندارد. در نتیجه، هنگام وقوع یک حادثه واقعی، سردرگمی، تأخیر و تصمیمات نادرست منجر به افزایش خسارت می‌شود.
ضعف در آگاهی‌رسانی امنیتی و آموزش کارکنان:
کارمندان در مورد حملات فیشینگ، مهندسی اجتماعی یا نحوه مدیریت داده‌های حساس به درستی آموزش ندیده‌اند. این آسیب‌پذیری انسانی، دروازه اصلی بسیاری از حملات موفق است.
سیاست‌های ضعیف مدیریت رمز عبور:
اجبار نکردن استفاده از رمزهای عبور پیچیده، عدم وجود سیاست انقضای رمز عبور، یا اجازه استفاده مجدد از رمزهای قدیمی.
فرآیندهای فیزیکی ناامن:
عدم وجود کنترل دسترسی مناسب به اتاق سرور، اجازه ورود افراد ناشناس به ساختمان بدون احراز هویت، یا روش‌های ناامن برای از بین بردن اسناد فیزیکی حاوی اطلاعات حساس.
بخش دوم: تیم قرمز (Red Teaming)؛ شبیه‌ساز حملات واقعی
تیم قرمز یک گروه متخصص امنیت است که وظیفه آن، به چالش کشیدن امنیت یک سازمان از طریق شبیه‌سازی حملات یک مهاجم واقعی، با انگیزه و با منابع کافی است. هدف اصلی تیم قرمز، صرفاً پیدا کردن یک لیست از آسیب‌پذیری‌ها نیست (مانند کاری که در تست نفوذ سنتی انجام می‌شود)، بلکه ارزیابی جامع توانایی‌های دفاعی سازمان (شامل افراد، فرآیندها و تکنولوژی) در برابر یک تهدید واقعی و مستمر است.
ویژگی‌های کلیدی یک عملیات تیم قرمز:
هدف‌محور (Objective-Driven): عملیات با یک هدف مشخص شروع می‌شود، مانند “دسترسی به پایگاه داده مشتریان” یا “ایجاد اختلال در خط تولید”.
شبیه‌سازی تهدید (Threat Emulation): تیم قرمز از تاکتیک‌ها، تکنیک‌ها و رویه‌های (TTPs) گروه‌های مهاجم واقعی (APTها) استفاده می‌کند.
چندوجهی (Multi-faceted): حمله تنها به یک لایه محدود نمیشود و می‌تواند شامل جنبه‌های فنی (هک شبکه)، فیزیکی (ورود به ساختمان) و انسانی (مهندسی اجتماعی) باشد.
مخفیانه (Stealthy): تیم قرمز تلاش می‌کند تا حد امکان توسط تیم دفاعی سازمان (تیم آبی یا Blue Team) شناسایی نشود تا بتواند توانایی‌های شناسایی و پاسخ آنها را به طور واقعی ارزیابی کند.
تمرکز بر زنجیره حمله (Kill Chain): تیم قرمز کل مراحل یک حمله را از شناسایی اولیه تا رسیدن به هدف نهایی شبیه‌سازی می‌کند.
بخش سوم: هم‌افزایی تیم قرمز و کشف آسیب‌پذیری‌های فرآیندی
ارتباط بین تیم قرمز و آسیب‌پذیری‌های فرآیندی در اینجا مشخص می‌شود: تیم قرمز بهترین ابزار برای کشف و اثبات وجود آسیب‌پذیری‌های فرآیندی است.
یک اسکنر نمی‌تواند تشخیص دهد که فرآیند Offboarding شما ضعیف است، اما تیم قرمز می‌تواند:
شناسایی: تیم قرمز لیستی از کارمندان سابق را از منابع عمومی مانند LinkedIn پیدا می‌کند.
آزمون: سعی می‌کند با استفاده از اطلاعات کاربری آنها (مثلاً firstname.lastname@company.com) به سیستم‌های خارجی مانند VPN یا ایمیل متصل شود.
ادامه در پست بعد ....
#آکادمی_روزبه
مرکز تخصصی CISSP
❤9
👆👆قسمت دوم از پست قبل
بهره‌برداری: در صورت موفقیت، تیم قرمز از این حساب کاربری “زامبی” برای نفوذ اولیه به شبکه استفاده می‌کند و به این ترتیب، ضعف در فرآیند Offboarding را نه به صورت تئوری، بلکه به صورت عملی اثبات می‌کند.
چگونه تیم قرمز آسیب‌پذیری‌های فرآیندی را آشکار می‌کند؟
مهندسی اجتماعی: یک عضو تیم قرمز با واحد پشتیبانی فنی (Help Desk) تماس می‌گیرد و با جعل هویت یک مدیر ارشد، درخواست بازنشانی رمز عبور می‌کند. اگر پشتیبانی فنی بدون احراز هویت دقیق این کار را انجام دهد، یک آسیب‌پذیری فرآیندی بزرگ در “فرآیند احراز هویت و پشتیبانی” آشکار شده است. این سناریو یک ضعف تکنولوژیک نیست، بلکه یک ضعف رویه‌ای است.
تست نفوذ فیزیکی: عضوی از تیم قرمز با پوشیدن لباس مبدل (مثلاً لباس پیک یا تکنسین) تلاش می‌کند وارد ساختمان شرکت شود. اگر نگهبانان یا کارمندان به او اجازه ورود بدهند بدون اینکه هویت او را بررسی کنند یا با کسی هماهنگ کنند، این نشان‌دهنده ضعف در “فرآیندهای امنیت فیزیکی و کنترل دسترسی” است.
حرکت جانبی در شبکه (Lateral Movement): پس از نفوذ اولیه، تیم قرمز تلاش می‌کند در شبکه حرکت کند. اگر بتواند به سادگی از یک سیستم کم‌اهمیت به یک سرور حیاتی دسترسی پیدا کند، این ممکن است نشان‌دهنده ضعف در “فرآیند بخش‌بندی شبکه (Network Segmentation)” و “سیاست‌های دیوار آتش داخلی” باشد.
خروجی یک عملیات تیم قرمز موفق:
خروجی نهایی، گزارشی است که نه تنها آسیب‌پذیری‌های فنی، بلکه یک جدول زمانی دقیق از اقدامات تیم قرمز، واکنش (یا عدم واکنش) تیم آبی و لیستی از آسیب‌پذیری‌های فرآیندی کشف‌شده را ارائه می‌دهد. این گزارش به مدیران ارشد کمک می‌کند تا بفهمند چگونه یک مهاجم توانست با دور زدن سیاست‌ها و رویه‌ها، به اهداف خود دست یابد.
نتیجه‌گیری
امنیت سایبری مدرن، یک مبارزه چندلایه است که صرفاً با خرید جدیدترین ابزارهای تکنولوژیک به پیروزی نمی‌رسد. آسیب‌پذیری‌های فرآیندی، شکاف‌های خاموش و خطرناکی در زره دفاعی یک سازمان هستند که اغلب از چشم ابزارهای خودکار پنهان می‌مانند.
تیم قرمز با رویکرد واقع‌گرایانه و خصمانه خود، به مثابه یک “آینه حقیقت” عمل می‌کند. این تیم نه تنها حفره‌های موجود در تکنولوژی، بلکه ضعف‌های ریشه‌دار در سیاست‌ها، رویه‌ها و فرهنگ امنیتی سازمان را آشکار می‌سازد. سرمایه‌گذاری بر روی عملیات تیم قرمز، یک گام حیاتی برای سازمان‌هایی است که می‌خواهند از یک رویکرد امنیتی واکنشی (Reactive) به یک رویکرد پیشگیرانه و هوشمند (Proactive) حرکت کرده و در برابر تهدیدات پیچیده امروزی، تاب‌آوری واقعی کسب کنند. در نهایت، قوی‌ترین دیوار آتش‌ها و پیچیده‌ترین سیستم‌های تشخیص نفوذ در برابر کارمندی که فریب یک ایمیل فیشینگ را میخورد یا فرآیندی که اجازه دسترسی بیش از حد می‌دهد، بی‌دفاع هستند.
#آکادمی_روزبه
مرکز تخصصی CISSP
بهره‌برداری: در صورت موفقیت، تیم قرمز از این حساب کاربری “زامبی” برای نفوذ اولیه به شبکه استفاده می‌کند و به این ترتیب، ضعف در فرآیند Offboarding را نه به صورت تئوری، بلکه به صورت عملی اثبات می‌کند.
چگونه تیم قرمز آسیب‌پذیری‌های فرآیندی را آشکار می‌کند؟
مهندسی اجتماعی: یک عضو تیم قرمز با واحد پشتیبانی فنی (Help Desk) تماس می‌گیرد و با جعل هویت یک مدیر ارشد، درخواست بازنشانی رمز عبور می‌کند. اگر پشتیبانی فنی بدون احراز هویت دقیق این کار را انجام دهد، یک آسیب‌پذیری فرآیندی بزرگ در “فرآیند احراز هویت و پشتیبانی” آشکار شده است. این سناریو یک ضعف تکنولوژیک نیست، بلکه یک ضعف رویه‌ای است.
تست نفوذ فیزیکی: عضوی از تیم قرمز با پوشیدن لباس مبدل (مثلاً لباس پیک یا تکنسین) تلاش می‌کند وارد ساختمان شرکت شود. اگر نگهبانان یا کارمندان به او اجازه ورود بدهند بدون اینکه هویت او را بررسی کنند یا با کسی هماهنگ کنند، این نشان‌دهنده ضعف در “فرآیندهای امنیت فیزیکی و کنترل دسترسی” است.
حرکت جانبی در شبکه (Lateral Movement): پس از نفوذ اولیه، تیم قرمز تلاش می‌کند در شبکه حرکت کند. اگر بتواند به سادگی از یک سیستم کم‌اهمیت به یک سرور حیاتی دسترسی پیدا کند، این ممکن است نشان‌دهنده ضعف در “فرآیند بخش‌بندی شبکه (Network Segmentation)” و “سیاست‌های دیوار آتش داخلی” باشد.
خروجی یک عملیات تیم قرمز موفق:
خروجی نهایی، گزارشی است که نه تنها آسیب‌پذیری‌های فنی، بلکه یک جدول زمانی دقیق از اقدامات تیم قرمز، واکنش (یا عدم واکنش) تیم آبی و لیستی از آسیب‌پذیری‌های فرآیندی کشف‌شده را ارائه می‌دهد. این گزارش به مدیران ارشد کمک می‌کند تا بفهمند چگونه یک مهاجم توانست با دور زدن سیاست‌ها و رویه‌ها، به اهداف خود دست یابد.
نتیجه‌گیری
امنیت سایبری مدرن، یک مبارزه چندلایه است که صرفاً با خرید جدیدترین ابزارهای تکنولوژیک به پیروزی نمی‌رسد. آسیب‌پذیری‌های فرآیندی، شکاف‌های خاموش و خطرناکی در زره دفاعی یک سازمان هستند که اغلب از چشم ابزارهای خودکار پنهان می‌مانند.
تیم قرمز با رویکرد واقع‌گرایانه و خصمانه خود، به مثابه یک “آینه حقیقت” عمل می‌کند. این تیم نه تنها حفره‌های موجود در تکنولوژی، بلکه ضعف‌های ریشه‌دار در سیاست‌ها، رویه‌ها و فرهنگ امنیتی سازمان را آشکار می‌سازد. سرمایه‌گذاری بر روی عملیات تیم قرمز، یک گام حیاتی برای سازمان‌هایی است که می‌خواهند از یک رویکرد امنیتی واکنشی (Reactive) به یک رویکرد پیشگیرانه و هوشمند (Proactive) حرکت کرده و در برابر تهدیدات پیچیده امروزی، تاب‌آوری واقعی کسب کنند. در نهایت، قوی‌ترین دیوار آتش‌ها و پیچیده‌ترین سیستم‌های تشخیص نفوذ در برابر کارمندی که فریب یک ایمیل فیشینگ را میخورد یا فرآیندی که اجازه دسترسی بیش از حد می‌دهد، بی‌دفاع هستند.
#آکادمی_روزبه
مرکز تخصصی CISSP
❤7
🔴مهم و جدید: وقتی EDRو XDR شما دور میخورد
جایی کهSOC شما باید وارد عمل شود
در بسیاری از سازمان‌ها، ابزارهای EDR و SIEM معمولاً دستورات خط فرمان مرتبط با Volume Shadow Copy (VSS) را برای جلوگیری از استخراج غیرمجاز داده‌ها مانیتور می‌کنند؛ اما روشی وجود دارد که می‌تواند این مکانیزم‌های دفاعی را دور بزند. با استفاده از قابلیت Previous Versions در Windows Explorer، مهاجم می‌تواند بدون اجرای هیچ دستور خط فرمان یا ابزار خاص، مستقیماً به Snapshotهای قبلی فایل‌ها یا پوشه‌ها دسترسی پیدا کند. کافی است مسیر UNC شبیه به
\\localhost\C$\@GMT-تاریخ‌خاص\Windows\NTDS\ntds.dit
را در Windows Explorer وارد کند تا بتواند فایل حساس مثل ntds.dit یک Domain Controller را از داخل یک Snapshot استخراج کند.
این روش عموماً در هیچ راهکار مانیتورینگ مبتنی بر فرمان‌های VSS قابل شناسایی نیست، چراکه هیچ رخداد یا لاگ خاصی از اجرای دستور ثبت نمیشود؛ به همین دلیل، این یک گپ امنیتی مهم است که اغلب توسط تیم‌های Blue Team و SOC نادیده گرفته می‌شود.
برای کاهش این ریسک باید دسترسی به مسیرهای دارای نشانه@GMT- در فایل سرورها و سرورهای دامین مانیتور شود و همچنین تیم تحلیلگر به این تکنیک‌ها آگاه گردد تا اقدامات متقابل مناسب طراحی و پیاده‌سازی گردد.
#آکادمی_روزبه
مرکز تخصصی CISSP
جایی کهSOC شما باید وارد عمل شود
در بسیاری از سازمان‌ها، ابزارهای EDR و SIEM معمولاً دستورات خط فرمان مرتبط با Volume Shadow Copy (VSS) را برای جلوگیری از استخراج غیرمجاز داده‌ها مانیتور می‌کنند؛ اما روشی وجود دارد که می‌تواند این مکانیزم‌های دفاعی را دور بزند. با استفاده از قابلیت Previous Versions در Windows Explorer، مهاجم می‌تواند بدون اجرای هیچ دستور خط فرمان یا ابزار خاص، مستقیماً به Snapshotهای قبلی فایل‌ها یا پوشه‌ها دسترسی پیدا کند. کافی است مسیر UNC شبیه به
\\localhost\C$\@GMT-تاریخ‌خاص\Windows\NTDS\ntds.dit
را در Windows Explorer وارد کند تا بتواند فایل حساس مثل ntds.dit یک Domain Controller را از داخل یک Snapshot استخراج کند.
این روش عموماً در هیچ راهکار مانیتورینگ مبتنی بر فرمان‌های VSS قابل شناسایی نیست، چراکه هیچ رخداد یا لاگ خاصی از اجرای دستور ثبت نمیشود؛ به همین دلیل، این یک گپ امنیتی مهم است که اغلب توسط تیم‌های Blue Team و SOC نادیده گرفته می‌شود.
برای کاهش این ریسک باید دسترسی به مسیرهای دارای نشانه@GMT- در فایل سرورها و سرورهای دامین مانیتور شود و همچنین تیم تحلیلگر به این تکنیک‌ها آگاه گردد تا اقدامات متقابل مناسب طراحی و پیاده‌سازی گردد.
#آکادمی_روزبه
مرکز تخصصی CISSP
❤8💯4👍3
حمله ADCS در اکتیو دایرکتوری
بسطی بر این نوع حملات پس از ۴ سال از ابداع
در حملات ADCS، مهاجم به واسطه ضعف‌های پیکربندی در سرویس صدور گواهینامه (مثل اعطای بیش از حد دسترسی به Enroll یا گزینه ENROLLEE_SUPPLIES_SUBJECT) می‌تواند گواهینامه معتبری اخذ کند که اعتبار Kerberos TGT یا حساب با امتیاز بالا (مثلاً Domain Admin) را شبیه‌سازی می‌کند؛ این یعنی مهاجم با استفاده از ابزارهایی همچون Certify، بدون نیاز به استخراج یا هش‌کردن پسورد، هویت معتبر در کل دامنه به دست می‌آورد. این گواهینامه‌ها عمدتاً کاملاً قانونی به نظر می‌رسند، چون در بستر رسمی AD صادر می‌شوند و اِکسپلویت آن معمولاً هیچ ردپایی از حملات کلاسیک چون mimikatz (dump LSASS) یا Golden Ticket در مموری باقی نمی‌گذارد.
در نتیجه تشخیص چنین حملاتی بسیار دشوارتر است، چون لاگ‌های صدور گواهینامه و عملکردهای PKI به سادگی و توسط بسیاری از SIEMها جمع‌آوری و تحلیل نمیشود. این حمله کاملاً زیر رادار بسیاری از مکانیزم‌های مانیتورینگ قرار می‌گیرد، بر خلاف حملات Pass-the-Hash، Pass-the-Ticket یا حتی DCSync که عمدتاً ردپای قابل شناسایی در لاگ‌های AD و Event Log دارند.
https://dfir.ch/posts/tear_down_castle_part_one/#1-adcs-active-directory-certificate-services
#آکادمی_روزبه
مرکز تخصصی CISSP
بسطی بر این نوع حملات پس از ۴ سال از ابداع
در حملات ADCS، مهاجم به واسطه ضعف‌های پیکربندی در سرویس صدور گواهینامه (مثل اعطای بیش از حد دسترسی به Enroll یا گزینه ENROLLEE_SUPPLIES_SUBJECT) می‌تواند گواهینامه معتبری اخذ کند که اعتبار Kerberos TGT یا حساب با امتیاز بالا (مثلاً Domain Admin) را شبیه‌سازی می‌کند؛ این یعنی مهاجم با استفاده از ابزارهایی همچون Certify، بدون نیاز به استخراج یا هش‌کردن پسورد، هویت معتبر در کل دامنه به دست می‌آورد. این گواهینامه‌ها عمدتاً کاملاً قانونی به نظر می‌رسند، چون در بستر رسمی AD صادر می‌شوند و اِکسپلویت آن معمولاً هیچ ردپایی از حملات کلاسیک چون mimikatz (dump LSASS) یا Golden Ticket در مموری باقی نمی‌گذارد.
در نتیجه تشخیص چنین حملاتی بسیار دشوارتر است، چون لاگ‌های صدور گواهینامه و عملکردهای PKI به سادگی و توسط بسیاری از SIEMها جمع‌آوری و تحلیل نمیشود. این حمله کاملاً زیر رادار بسیاری از مکانیزم‌های مانیتورینگ قرار می‌گیرد، بر خلاف حملات Pass-the-Hash، Pass-the-Ticket یا حتی DCSync که عمدتاً ردپای قابل شناسایی در لاگ‌های AD و Event Log دارند.
https://dfir.ch/posts/tear_down_castle_part_one/#1-adcs-active-directory-certificate-services
#آکادمی_روزبه
مرکز تخصصی CISSP
❤6👍5
آکادمی آموزش روزبه 📚
حمله ADCS در اکتیو دایرکتوری بسطی بر این نوع حملات پس از ۴ سال از ابداع در حملات ADCS، مهاجم به واسطه ضعف‌های پیکربندی در سرویس صدور گواهینامه (مثل اعطای بیش از حد دسترسی به Enroll یا گزینه ENROLLEE_SUPPLIES_SUBJECT) می‌تواند گواهینامه معتبری اخذ کند که…
چه لاگ‌هایی برای کشف حمله مندرج در لینک زیر لازم است :
جمع‌آوری لاگ‌های صدور گواهینامه (Certificate Enrollment) و هم مانیتورینگ رخدادهای مربوط به PKI (سرورهای CA) پایه‌ی Hunting و Detection در سناریوهای ADCS abuse به حساب می‌آید.
۱. لاگ‌های مورد نیاز در Windows CA:
این Event Log: سرورهای CA لاگ‌های مرتبط را در Event Viewer ثبت می‌کنند. مسیر:
✅️ Application and Services Logs > Microsoft > Windows > CertificateServicesClient-CertEnroll
✅️ Application and Services Logs > Microsoft > Windows > CertificateAuthority
فایل Database CA:
مسیر پیش‌فرض: C:\Windows\System32\CertLog\*.edb
برای جست‌وجوی درخواست‌ها به ابزار اختصاصی مثل “certutil” نیاز دارید.
۲. مهم‌ترین Eventهای مرتبط با صدور گواهی:
Event ID 4886: Certificate request submitted
Event ID 4887: Certificate issued
Event ID 4898: Certificate request approved
Event ID 4899: Certificate request denied
Event ID 1003: (CA Operation Audit)
#آکادمی_روزبه
مرکز تخصصی CISSP
https://dfir.ch/posts/tear_down_castle_part_one/#1-adcs-active-directory-certificate-services
جمع‌آوری لاگ‌های صدور گواهینامه (Certificate Enrollment) و هم مانیتورینگ رخدادهای مربوط به PKI (سرورهای CA) پایه‌ی Hunting و Detection در سناریوهای ADCS abuse به حساب می‌آید.
۱. لاگ‌های مورد نیاز در Windows CA:
این Event Log: سرورهای CA لاگ‌های مرتبط را در Event Viewer ثبت می‌کنند. مسیر:
✅️ Application and Services Logs > Microsoft > Windows > CertificateServicesClient-CertEnroll
✅️ Application and Services Logs > Microsoft > Windows > CertificateAuthority
فایل Database CA:
مسیر پیش‌فرض: C:\Windows\System32\CertLog\*.edb
برای جست‌وجوی درخواست‌ها به ابزار اختصاصی مثل “certutil” نیاز دارید.
۲. مهم‌ترین Eventهای مرتبط با صدور گواهی:
Event ID 4886: Certificate request submitted
Event ID 4887: Certificate issued
Event ID 4898: Certificate request approved
Event ID 4899: Certificate request denied
Event ID 1003: (CA Operation Audit)
#آکادمی_روزبه
مرکز تخصصی CISSP
https://dfir.ch/posts/tear_down_castle_part_one/#1-adcs-active-directory-certificate-services
dfir.ch
Tear Down The Castle - Part 1 | dfir.ch
Technical blog by Stephan Berger (@malmoeb)
❤7👍4
آکادمی آموزش روزبه 📚 pinned «🔴مهم و جدید: وقتی EDRو XDR شما دور میخورد جایی کهSOC شما باید وارد عمل شود در بسیاری از سازمان‌ها، ابزارهای EDR و SIEM معمولاً دستورات خط فرمان مرتبط با Volume Shadow Copy (VSS) را برای جلوگیری از استخراج غیرمجاز داده‌ها مانیتور می‌کنند؛ اما روشی وجود دارد…»
دوستی میگفت:
چرا اینقدر مطلب مینویسی و تند تند پست میکنی؟
گفتم دنیای امنیت رحم نداره
نخونی ؛ حذف میشی
و قبل از حذف مجبور میشی به شغل های پایین تر تن بدی!!
چرا اینقدر مطلب مینویسی و تند تند پست میکنی؟
گفتم دنیای امنیت رحم نداره
نخونی ؛ حذف میشی
و قبل از حذف مجبور میشی به شغل های پایین تر تن بدی!!
👏14👍6💯5❤2
حمله Mix-Up Attack یکی از حملاتی است که بسیاری از توسعه‌دهندگان و حتی مدیران امنیتی نسبت به آن آگاه نیستند، اما در معماری‌هایی با احراز هویت چندگانه (Multi-Provider OAuth/OIDC) می‌تواند تهدید جدی ایجاد کند.
📌حمله Mix-Up Attack به زبان ساده:
سناریو چیست؟
فرض کنید اپلیکیشن یا سایت شما به چند OAuth Provider وصل می‌شود (مثلاً هم Facebook، هم Google، هم Microsoft برای ورود کاربران). وقتی کاربر روی “ورود با گوگل” کلیک می‌کند، و همزمان Provider دیگری هم در سیستم هست، اگر validation سمت backend درست انجام نشود، امکان دارد یک توکن از Provider A (مثلاً گوگل) را به provider B (مثلاً فیس‌بوک) بدهند—یا عمداً به سرور بیاورند—و سرور شما فقط به وجود یک توکن اکتفا کند و نفهمد این توکن متعلق به Provider درست نیست.
مسیر حمله:
کاربر انتخاب می‌کند وارد سایت شود (مثلاً با Provider A).
مهاجم یا کاربر malicious، جریان OAuth را با Provider B (مورد نظر خودش) انجام می‌دهد اما در Callback پارامتر Redirect را طوری دستکاری می‌کند که توکن Provider B به جای Provider A به سرور شما ارائه شود.
اگر validate سمت سرور بر اساس Issuer (iss claim) و Audience (aud claim) به درستی انجام نشود، سرور Auth شما شاید این توکن را معتبر بپذیرد، در حالی که اصلاً از Provider مورد انتظار‌تر نیامده!
نتیجه چیست؟
ممکن است attacker بتواند با توکن خودش از Provider دیگر وارد اکانت کاربر در سیستم شود (user impersonation).
🔒 چطور جلویش را بگیریم؟
۱. اعتبارسنجی Issuer (iss claim)
در تمام JWTهایی که دریافت می‌کنید، باید مقدار iss (issuer) را چک کنید که دقیقا مال همانی است که کاربر انتخاب کرده (مثلاً https://accounts.google.com، نه چیز دیگر).
۲. بررسی Audience (aud claim)
حتماً مطمئن شوید aud همان Client IDای است که واقعاً مال سرویس شما است و متعلق به Provider صحیح است.
۳. انجامBind کردن state به provider
در پارامتر state (که هنگام ساخت request OAuth استفاده می‌شود) حتماً identifierی از Provider هم قرار بدهید و در callback بررسی کنید که state مربوطه با Provider که callback زده مطابقت دارد.
#آکادمی_روزبه
مرکز تخصصی CISSP
📌حمله Mix-Up Attack به زبان ساده:
سناریو چیست؟
فرض کنید اپلیکیشن یا سایت شما به چند OAuth Provider وصل می‌شود (مثلاً هم Facebook، هم Google، هم Microsoft برای ورود کاربران). وقتی کاربر روی “ورود با گوگل” کلیک می‌کند، و همزمان Provider دیگری هم در سیستم هست، اگر validation سمت backend درست انجام نشود، امکان دارد یک توکن از Provider A (مثلاً گوگل) را به provider B (مثلاً فیس‌بوک) بدهند—یا عمداً به سرور بیاورند—و سرور شما فقط به وجود یک توکن اکتفا کند و نفهمد این توکن متعلق به Provider درست نیست.
مسیر حمله:
کاربر انتخاب می‌کند وارد سایت شود (مثلاً با Provider A).
مهاجم یا کاربر malicious، جریان OAuth را با Provider B (مورد نظر خودش) انجام می‌دهد اما در Callback پارامتر Redirect را طوری دستکاری می‌کند که توکن Provider B به جای Provider A به سرور شما ارائه شود.
اگر validate سمت سرور بر اساس Issuer (iss claim) و Audience (aud claim) به درستی انجام نشود، سرور Auth شما شاید این توکن را معتبر بپذیرد، در حالی که اصلاً از Provider مورد انتظار‌تر نیامده!
نتیجه چیست؟
ممکن است attacker بتواند با توکن خودش از Provider دیگر وارد اکانت کاربر در سیستم شود (user impersonation).
🔒 چطور جلویش را بگیریم؟
۱. اعتبارسنجی Issuer (iss claim)
در تمام JWTهایی که دریافت می‌کنید، باید مقدار iss (issuer) را چک کنید که دقیقا مال همانی است که کاربر انتخاب کرده (مثلاً https://accounts.google.com، نه چیز دیگر).
۲. بررسی Audience (aud claim)
حتماً مطمئن شوید aud همان Client IDای است که واقعاً مال سرویس شما است و متعلق به Provider صحیح است.
۳. انجامBind کردن state به provider
در پارامتر state (که هنگام ساخت request OAuth استفاده می‌شود) حتماً identifierی از Provider هم قرار بدهید و در callback بررسی کنید که state مربوطه با Provider که callback زده مطابقت دارد.
#آکادمی_روزبه
مرکز تخصصی CISSP
👌7❤3
یه تنظیم گر XDR میخوایم.
حوصله تنظیم کردن و تیون داشته باشه
بتونه تحلیل کنه چه ماژولی کجا باید فعال بشه و چرا ؟
پس باید حملات امنیتی رو بشناسه اونم خوب
مثلا پراسس هالویینگ در ذهنش نفوذ کرده باشه پس بتونه تنظیمی واسه کشف و جلوگیریش انجام بده .
لازم نیست به XDR مسلط باشه همین که به یه EDR مسلط باشه و بفهمه چطور کار میکنه کافیه
و عاشق SOC نباشه چون کار فقط XDR هست.
لازم نیست بگم که دانش سیستم عاملش باید خوب باشه
برای این کار خالص ۶۰ تومن درنظر گرفته شده +مزایای مناسبتی +بیمه تکمیلی و پاداش بهره وری
اگر بلدین بسم الله
بنویسین کارشناس XDR و بفرستین رزومه رو hr@haumoun.com
هیچ زیاد سابقه هم نمیخواد
کار رو بلدی میای مصاحبه کتبی و عملی
✅️لطفا فوروارد کنید تا دیده بشه
حوصله تنظیم کردن و تیون داشته باشه
بتونه تحلیل کنه چه ماژولی کجا باید فعال بشه و چرا ؟
پس باید حملات امنیتی رو بشناسه اونم خوب
مثلا پراسس هالویینگ در ذهنش نفوذ کرده باشه پس بتونه تنظیمی واسه کشف و جلوگیریش انجام بده .
لازم نیست به XDR مسلط باشه همین که به یه EDR مسلط باشه و بفهمه چطور کار میکنه کافیه
و عاشق SOC نباشه چون کار فقط XDR هست.
لازم نیست بگم که دانش سیستم عاملش باید خوب باشه
برای این کار خالص ۶۰ تومن درنظر گرفته شده +مزایای مناسبتی +بیمه تکمیلی و پاداش بهره وری
اگر بلدین بسم الله
بنویسین کارشناس XDR و بفرستین رزومه رو hr@haumoun.com
هیچ زیاد سابقه هم نمیخواد
کار رو بلدی میای مصاحبه کتبی و عملی
✅️لطفا فوروارد کنید تا دیده بشه
👍5❤4🔥3
شکار بد افزار از طریق کانال‌های جانبی (Side-Channel Analysis): وقتی بدافزار سکوت می‌کند
روزبه نوروزی
هوشمندانه‌ترین بدافزارها می‌دانند که هرگونه فعالیت شبکه‌ای یا تغییر در فایل سیستم، ردپایی از خود به جای می‌گذارد. بنابراین، ممکن است برای مدتی طولانی کاملاً غیرفعال بمانند تا زمانی که یک شرط بسیار خاص (مثلاً اتصال یک USB با شماره سریال مشخص) محقق شود. چطور می‌توان چنین بدافزار خفته‌ای را تحلیل کرد؟
رویکرد من: ما به آنچه بدافزار “انجام می‌دهد” نگاه نمی‌کنیم، بلکه به “اثرات جانبی وجودش” نگاه می‌کنیم.
تحلیل حافظه نهان پردازنده (CPU Cache Analysis): تکنیک‌هایی مانند Flush+Reload به ما اجازه می‌دهند بفهمیم که آیا یک بخش خاص از کد (مثلاً یک تابع در یک DLL سیستمی) توسط یک پروسه دیگر اجرا شده است یا خیر، بدون اینکه نیازی به دیباگ کردن آن پروسه داشته باشیم.
سناریو: ما به یک تابع رمزنگاری در crypt32.dll مشکوک هستیم. ابتدا خطوط کش مربوط به آن تابع را از حافظه نهان CPU پاک می‌کنیم (Flush). سپس منتظر می‌مانیم. بعد از مدتی، دوباره زمان دسترسی به آن خطوط را اندازه‌گیری می‌کنیم (Reload). اگر زمان دسترسی بسیار کم باشد، یعنی پروسه دیگری (بدافزار ما) آن تابع را فراخوانی کرده و آن را دوباره به کش آورده است! ما بدون هیچ API hooking یا دیباگینگ، متوجه فعالیت پنهانی بدافزار شدیم.
#آکادمی_روزبه
مرکز تخصصی CISSP
روزبه نوروزی
هوشمندانه‌ترین بدافزارها می‌دانند که هرگونه فعالیت شبکه‌ای یا تغییر در فایل سیستم، ردپایی از خود به جای می‌گذارد. بنابراین، ممکن است برای مدتی طولانی کاملاً غیرفعال بمانند تا زمانی که یک شرط بسیار خاص (مثلاً اتصال یک USB با شماره سریال مشخص) محقق شود. چطور می‌توان چنین بدافزار خفته‌ای را تحلیل کرد؟
رویکرد من: ما به آنچه بدافزار “انجام می‌دهد” نگاه نمی‌کنیم، بلکه به “اثرات جانبی وجودش” نگاه می‌کنیم.
تحلیل حافظه نهان پردازنده (CPU Cache Analysis): تکنیک‌هایی مانند Flush+Reload به ما اجازه می‌دهند بفهمیم که آیا یک بخش خاص از کد (مثلاً یک تابع در یک DLL سیستمی) توسط یک پروسه دیگر اجرا شده است یا خیر، بدون اینکه نیازی به دیباگ کردن آن پروسه داشته باشیم.
سناریو: ما به یک تابع رمزنگاری در crypt32.dll مشکوک هستیم. ابتدا خطوط کش مربوط به آن تابع را از حافظه نهان CPU پاک می‌کنیم (Flush). سپس منتظر می‌مانیم. بعد از مدتی، دوباره زمان دسترسی به آن خطوط را اندازه‌گیری می‌کنیم (Reload). اگر زمان دسترسی بسیار کم باشد، یعنی پروسه دیگری (بدافزار ما) آن تابع را فراخوانی کرده و آن را دوباره به کش آورده است! ما بدون هیچ API hooking یا دیباگینگ، متوجه فعالیت پنهانی بدافزار شدیم.
#آکادمی_روزبه
مرکز تخصصی CISSP
👍5❤3
از جمله ابزار کلاسهایم
یک اسکریپت PowerShell که برای تست و ارزیابی قابلیت‌های شناسایی و پاسخ (Detection & Response) در محیط‌های Active Directory طراحی شده است. این ابزار به طور خاص دو تکنیک رایج و پرخطر از چارچوب MITRE ATT&CK را به صورت خودکار شبیه‌سازی می‌کند: Kerberoasting (T1558.003) و AS-REP Roasting (T1558.004).
#آکادمی_روزبه
مرکز تخصصی CISSP
https://github.com/MHaggis/notes/blob/master/utilities/ForrestBlizz.ps1
یک اسکریپت PowerShell که برای تست و ارزیابی قابلیت‌های شناسایی و پاسخ (Detection & Response) در محیط‌های Active Directory طراحی شده است. این ابزار به طور خاص دو تکنیک رایج و پرخطر از چارچوب MITRE ATT&CK را به صورت خودکار شبیه‌سازی می‌کند: Kerberoasting (T1558.003) و AS-REP Roasting (T1558.004).
#آکادمی_روزبه
مرکز تخصصی CISSP
https://github.com/MHaggis/notes/blob/master/utilities/ForrestBlizz.ps1
GitHub
notes/utilities/ForrestBlizz.ps1 at master · MHaggis/notes
Full of public notes and Utilities. Contribute to MHaggis/notes development by creating an account on GitHub.
🔥5👍2
دوستانی که فرصت حضور در کلاسهایم را ندارند این منبع را برای خودآموزی داشته باشند
#آکادمی_روزبه
مرکز تخصصی CISSP
https://github.com/S3N4T0R-0X0/APT-Attack-Simulation
#آکادمی_روزبه
مرکز تخصصی CISSP
https://github.com/S3N4T0R-0X0/APT-Attack-Simulation
GitHub
GitHub - S3N4T0R-0X0/APTs-Adversary-Simulation: This repository contains detailed adversary simulation APT campaigns targeting…
This repository contains detailed adversary simulation APT campaigns targeting various critical sectors. Each simulation includes custom tools, C2 servers, backdoors, exploitation techniques, stage...
🔥6❤2
یک گزارشی برای تصمیم سازی در کنار گارتنر
گزارش GigaOm Radar یک گزارش تحلیلی و تصویری است که توسط شرکت تحقیقاتی و تحلیل فناوری GigaOm منتشر می‌شود. این گزارش‌ها برای کمک به رهبران و تصمیم‌گیرندگان حوزه فناوری اطلاعات (IT) طراحی شده‌اند تا بتوانند به سرعت و با دیدی جامع، فروشندگان و راهکارهای موجود در یک بازار فناوری خاص را ارزیابی و مقایسه کنند.
به زبان ساده، GigaOm Radar یک نقشه راهنمای بازار است که به شما نشان می‌دهد کدام شرکت‌ها در یک حوزه مشخص (مثلاً امنیت ابری، مدیریت پایگاه داده، هوش مصنوعی و…) پیشرو هستند، کدام‌ها بازیگران جدید و نوآورند و هر کدام چه نقاط قوت و ضعفی دارند.
گارتنر هنوز وزن و نفوذ بسیار بیشتری در سطح مدیران ارشد اجرایی (C-level) و تصمیم‌گیری‌های کلان سازمانی دارد، اما GigaOm به سرعت در حال کسب اعتبار به عنوان یک منبع تحلیلی معتبر، مدرن و فنی‌تر است، به ویژه در میان مخاطبان فنی و بازارهای نوظهور.
#آکادمی_روزبه
مرکز تخصصی CISSP
نمونه
CrowdStrike Named a Leader in the 2025 GigaOm SIEM Radar Report
https://www.crowdstrike.com/en-us/blog/crowdstrike-named-leader-in-2025-gigaom-siem-radar-report/?blog=&utm_medium=soc&utm_source=lnkd&utm_term=spklr&utm_content=17603898827&utm_campaign=platform%2Fproduct&utm_activation=content%3A+crowdstrike+blog%2Canalyst%3A+other
گزارش GigaOm Radar یک گزارش تحلیلی و تصویری است که توسط شرکت تحقیقاتی و تحلیل فناوری GigaOm منتشر می‌شود. این گزارش‌ها برای کمک به رهبران و تصمیم‌گیرندگان حوزه فناوری اطلاعات (IT) طراحی شده‌اند تا بتوانند به سرعت و با دیدی جامع، فروشندگان و راهکارهای موجود در یک بازار فناوری خاص را ارزیابی و مقایسه کنند.
به زبان ساده، GigaOm Radar یک نقشه راهنمای بازار است که به شما نشان می‌دهد کدام شرکت‌ها در یک حوزه مشخص (مثلاً امنیت ابری، مدیریت پایگاه داده، هوش مصنوعی و…) پیشرو هستند، کدام‌ها بازیگران جدید و نوآورند و هر کدام چه نقاط قوت و ضعفی دارند.
گارتنر هنوز وزن و نفوذ بسیار بیشتری در سطح مدیران ارشد اجرایی (C-level) و تصمیم‌گیری‌های کلان سازمانی دارد، اما GigaOm به سرعت در حال کسب اعتبار به عنوان یک منبع تحلیلی معتبر، مدرن و فنی‌تر است، به ویژه در میان مخاطبان فنی و بازارهای نوظهور.
#آکادمی_روزبه
مرکز تخصصی CISSP
نمونه
CrowdStrike Named a Leader in the 2025 GigaOm SIEM Radar Report
https://www.crowdstrike.com/en-us/blog/crowdstrike-named-leader-in-2025-gigaom-siem-radar-report/?blog=&utm_medium=soc&utm_source=lnkd&utm_term=spklr&utm_content=17603898827&utm_campaign=platform%2Fproduct&utm_activation=content%3A+crowdstrike+blog%2Canalyst%3A+other
CrowdStrike.com
CrowdStrike Named a Leader in the 2025 GigaOm SIEM Radar Report
CrowdStrike has been named a Leader and Fast Mover in the 2025 GigaOm SIEM Radar Report. Learn more!
👍4❤2
یک تغییر نگرش ضروری در مهندسی کشف: چرا باید استراتژی شناسایی خود را هوشمندتر کنیم؟
همه‌ی ما که در دنیای امنیت سایبری فعالیت می‌کنیم، با چارچوب MITRE ATT&CK زندگی می‌کنیم. این ماتریس به زبان مشترک ما برای توصیف رفتار مهاجمان تبدیل شده است. اما اغلب، در تلاش برای «پوشش دادن ماتریس»، در انبوهی از تکنیک‌ها و زیرتکنیک‌ها غرق می‌شویم. رویکرد رایج این است: یک تکنیک را انتخاب کن، برایش یک قانون شناسایی بنویس، و به سراغ بعدی برو. این روش، اگرچه ارزشمند است، اما همیشه کارآمد و پایدار نیست.
اخیراً مقاله‌ای از خود تیم MITRE ATT&CK با عنوان «استراتژی‌های شناسایی هوشمندتر» منتشر شد که به نظرم یک تلنگر اساسی به این رویکرد سنتی می‌زند. نکته‌ی اصلی و جدید این مقاله، نه معرفی یک ابزار یا تکنیک جدید، بلکه ارائه یک مدل ذهنی متفاوت برای ساختن دفاع‌هایمان است؛ مدلی که از پایین به بالا ساخته می‌شود و تمرکز را از «تکنیک‌های خاص» به سمت «فرصت‌های مشاهده‌پذیری» شیفت می‌دهد.
مشکل رویکرد سنتی: دویدن دنبال جزئیات
ادامه و متن کامل مقاله را می‌توانید در پست های بعدی بخوانید
#آکادمی_روزبه
مرکز تخصصی CISSP
https://medium.com/mitre-attack/smarter-detection-strategies-in-attack-7e6738fec31f
همه‌ی ما که در دنیای امنیت سایبری فعالیت می‌کنیم، با چارچوب MITRE ATT&CK زندگی می‌کنیم. این ماتریس به زبان مشترک ما برای توصیف رفتار مهاجمان تبدیل شده است. اما اغلب، در تلاش برای «پوشش دادن ماتریس»، در انبوهی از تکنیک‌ها و زیرتکنیک‌ها غرق می‌شویم. رویکرد رایج این است: یک تکنیک را انتخاب کن، برایش یک قانون شناسایی بنویس، و به سراغ بعدی برو. این روش، اگرچه ارزشمند است، اما همیشه کارآمد و پایدار نیست.
اخیراً مقاله‌ای از خود تیم MITRE ATT&CK با عنوان «استراتژی‌های شناسایی هوشمندتر» منتشر شد که به نظرم یک تلنگر اساسی به این رویکرد سنتی می‌زند. نکته‌ی اصلی و جدید این مقاله، نه معرفی یک ابزار یا تکنیک جدید، بلکه ارائه یک مدل ذهنی متفاوت برای ساختن دفاع‌هایمان است؛ مدلی که از پایین به بالا ساخته می‌شود و تمرکز را از «تکنیک‌های خاص» به سمت «فرصت‌های مشاهده‌پذیری» شیفت می‌دهد.
مشکل رویکرد سنتی: دویدن دنبال جزئیات
ادامه و متن کامل مقاله را می‌توانید در پست های بعدی بخوانید
#آکادمی_روزبه
مرکز تخصصی CISSP
https://medium.com/mitre-attack/smarter-detection-strategies-in-attack-7e6738fec31f
Medium
What Comes After Detection Rules? Smarter Detection Strategies in ATT&CK
ATT&CK’s new model links strategies, analytics, and log sources into reusable blueprints tailored to real-world telemetry.
❤4👏2
نکته روز :
حتی اگر هکر با Clear-History تاریخچه پاورشل را پاک کند ، دستورات او در فایل PSReadLine باقی می‌ماند و تیم کشف می‌تواند به آنها دسترسی داشته باشد.
**فقط تایم استمپ ندارد!
#آکادمی_روزبه
مرکز تخصصی CISSP
Www.Roozbeh.academy
حتی اگر هکر با Clear-History تاریخچه پاورشل را پاک کند ، دستورات او در فایل PSReadLine باقی می‌ماند و تیم کشف می‌تواند به آنها دسترسی داشته باشد.
**فقط تایم استمپ ندارد!
#آکادمی_روزبه
مرکز تخصصی CISSP
Www.Roozbeh.academy
🔥5❤3⚡1
امکان تسخیر شبکه شما از طریق اسپلانک
✍روزبه نوروزی
نفوذ از Splunk Deployment Server به Endpointها امکان‌پذیر است، زیرا مهاجم از قابلیت‌های اصلی و طراحی‌شده‌ی خود سیستم علیه آن استفاده می‌کند، نه لزوماً از یک آسیب‌پذیری نرم‌افزاری.
این حمله بر چهار اصل استوار است:
۱. مدیریت متمرکز: Deployment Server به عنوان یک “نقطه کنترل واحد” عمل می‌کند. تسلط بر آن به معنای تسلط بر تمام کلاینت‌های متصل (Forwarderها) است.
۲. مدل اعتماد: کلاینت‌ها به صورت کورکورانه به دستورات و اپلیکیشن‌هایی که از Deployment Server دریافت می‌کنند، اعتماد و آنها را اجرا می‌کنند.
۳. قابلیت اجرای اسکریپت: Splunk به مدیران اجازه می‌دهد تا اسکریپت‌هایی را روی Endpointها اجرا کنند (قابلیت Scripted Inputs). مهاجم از همین ویژگی قانونی برای اجرای کدهای مخرب خود بهره می‌برد.
۴. دسترسی بالا: از آنجا که Forwarderها معمولاً با دسترسی بالا (root در لینوکس یا SYSTEM در ویندوز) اجرا می‌شوند، اسکریپت مخرب نیز با همین سطح دسترسی اجرا شده و کنترل کامل Endpoint را به مهاجم می‌دهد.
در واقع، این حمله یک سوءاستفاده هوشمندانه از یک ابزار مدیریتی قدرتمند است که در آن، اعتماد و کارایی سیستم به یک ضعف امنیتی تبدیل می‌شود.
راهکار مقابله : حفاظت مؤثر از Deployment server با روش دفاع در عمق
**این روش مختص اسپلانک نیست و هر برنامه ای از این روش در معماری خود استفاده کند شامل این مساله میگردد .
**این روش از تسخیر نیاز به پیش زمینه هایی دارد پس دلیل نمیشود بخواهیم اسپلانک را دارای مشکل بدانیم و اقدام به حذف آن کنیم.
بهتر است همیشه نقطه ضعف و اندازه آنرا بدانیم و برایش راهکار داشته باشیم.
#آکادمی_روزبه
Www.Roozbeh.academy
✍روزبه نوروزی
نفوذ از Splunk Deployment Server به Endpointها امکان‌پذیر است، زیرا مهاجم از قابلیت‌های اصلی و طراحی‌شده‌ی خود سیستم علیه آن استفاده می‌کند، نه لزوماً از یک آسیب‌پذیری نرم‌افزاری.
این حمله بر چهار اصل استوار است:
۱. مدیریت متمرکز: Deployment Server به عنوان یک “نقطه کنترل واحد” عمل می‌کند. تسلط بر آن به معنای تسلط بر تمام کلاینت‌های متصل (Forwarderها) است.
۲. مدل اعتماد: کلاینت‌ها به صورت کورکورانه به دستورات و اپلیکیشن‌هایی که از Deployment Server دریافت می‌کنند، اعتماد و آنها را اجرا می‌کنند.
۳. قابلیت اجرای اسکریپت: Splunk به مدیران اجازه می‌دهد تا اسکریپت‌هایی را روی Endpointها اجرا کنند (قابلیت Scripted Inputs). مهاجم از همین ویژگی قانونی برای اجرای کدهای مخرب خود بهره می‌برد.
۴. دسترسی بالا: از آنجا که Forwarderها معمولاً با دسترسی بالا (root در لینوکس یا SYSTEM در ویندوز) اجرا می‌شوند، اسکریپت مخرب نیز با همین سطح دسترسی اجرا شده و کنترل کامل Endpoint را به مهاجم می‌دهد.
در واقع، این حمله یک سوءاستفاده هوشمندانه از یک ابزار مدیریتی قدرتمند است که در آن، اعتماد و کارایی سیستم به یک ضعف امنیتی تبدیل می‌شود.
راهکار مقابله : حفاظت مؤثر از Deployment server با روش دفاع در عمق
**این روش مختص اسپلانک نیست و هر برنامه ای از این روش در معماری خود استفاده کند شامل این مساله میگردد .
**این روش از تسخیر نیاز به پیش زمینه هایی دارد پس دلیل نمیشود بخواهیم اسپلانک را دارای مشکل بدانیم و اقدام به حذف آن کنیم.
بهتر است همیشه نقطه ضعف و اندازه آنرا بدانیم و برایش راهکار داشته باشیم.
#آکادمی_روزبه
Www.Roozbeh.academy
👌7❤3👍3🤝3
شبیه‌سازی و تست Scheduled Taskهای پنهان: ابزاری نوین برای تحلیلگران امنیتی
در دنیای امنیت سایبری، Scheduled Taskها یکی از روش‌های رایج مهاجمان برای اجرای نامحسوس کد مخرب در سیستم‌های ویندوز هستند. بسیاری از این Taskها چنان ماهرانه تنظیم می‌شوند که به راحتی از چشم ابزارهای تشخیص یا تحلیلگران شبکه پنهان می‌مانند. به همین دلیل، شبیه‌سازی رفتار این گونه Taskها می‌تواند به بهبود دتکشن و افزایش آگاهی تیم‌های دفاعی کمک شایانی کند.
معرفی ابزار Defender Utility Drop
ابزار جدیدی که اخیراً توسط یکی از پژوهشگران امنیتی منتشر شده، یک اسکریپت PowerShell است که با الهام از تحقیقات Binary Defense توسعه یافته است. این ابزار امکان شبیه‌سازی انواع سناریوهای پیچیده و دستکاری‌شده مربوط به Scheduled Taskها را فراهم می‌کند تا مدافعان بتوانند کیفیت قوانین و ابزارهای تشخیصی خود را آزمون کرده و نقاط ضعف را شناسایی نمایند.
چه قابلیت‌هایی دارد؟
این اسکریپت شامل تست‌های اتمیک مانند موارد زیر است:
- حذف یا جعل SD Value: شبیه‌سازی حذف یا دستکاری مقادیر Security Descriptor برای ردگیری رفتار ابزارهای امنیتی.
- سوءاستفاده از SDDL: بررسی مقاومت سیستم مقابل Deny-Access یا Abuse Policyها.
- تسک بدون لاگ: اجرای Taskهایی که عملاً ردی در Event Log ایجاد نمی‌کنند و شناسایی آنها دشوار است.
- دستکاری رجیستری و کلیپ‌بورد: ایجاد تغییرات مشکوک در مقادیر رجیستری یا کلیپ‌بورد برای تحلیل تاثیر این رفتارها روی ابزارهای EDR.
- تست‌های Sysmon: ارزیابی کارایی Ruleهای Sysmon در شناسایی سناریوهای فوق.
- نمایش خروجی ASCII برای تعامل بهتر و جذاب‌تر بودن تست‌ها.
کاربردها
این ابزار برای افراد زیر کاربرد ویژه دارد:
- تحلیلگران تهدید و محققان امنیتی که روی کشف و تحلیل رفتاری کار می‌کنند.
- ادمین‌ها و تیم‌های SOC که می‌خواهند کیفیت Ruleهای Sysmon یا سایر ابزارهای مانیتورینگ را بهبود دهند.
- افرادی که به دنبال شبیه‌سازی حملات در محیطی کنترل‌شده به سبک Atomic Red Team هستند.
#آکادمی_روزبه
ازجمله ابزارهای دوره های استاد روزبه
https://github.com/MHaggis/notes/blob/master/utilities/HiddenScheduledTasks.ps1
در دنیای امنیت سایبری، Scheduled Taskها یکی از روش‌های رایج مهاجمان برای اجرای نامحسوس کد مخرب در سیستم‌های ویندوز هستند. بسیاری از این Taskها چنان ماهرانه تنظیم می‌شوند که به راحتی از چشم ابزارهای تشخیص یا تحلیلگران شبکه پنهان می‌مانند. به همین دلیل، شبیه‌سازی رفتار این گونه Taskها می‌تواند به بهبود دتکشن و افزایش آگاهی تیم‌های دفاعی کمک شایانی کند.
معرفی ابزار Defender Utility Drop
ابزار جدیدی که اخیراً توسط یکی از پژوهشگران امنیتی منتشر شده، یک اسکریپت PowerShell است که با الهام از تحقیقات Binary Defense توسعه یافته است. این ابزار امکان شبیه‌سازی انواع سناریوهای پیچیده و دستکاری‌شده مربوط به Scheduled Taskها را فراهم می‌کند تا مدافعان بتوانند کیفیت قوانین و ابزارهای تشخیصی خود را آزمون کرده و نقاط ضعف را شناسایی نمایند.
چه قابلیت‌هایی دارد؟
این اسکریپت شامل تست‌های اتمیک مانند موارد زیر است:
- حذف یا جعل SD Value: شبیه‌سازی حذف یا دستکاری مقادیر Security Descriptor برای ردگیری رفتار ابزارهای امنیتی.
- سوءاستفاده از SDDL: بررسی مقاومت سیستم مقابل Deny-Access یا Abuse Policyها.
- تسک بدون لاگ: اجرای Taskهایی که عملاً ردی در Event Log ایجاد نمی‌کنند و شناسایی آنها دشوار است.
- دستکاری رجیستری و کلیپ‌بورد: ایجاد تغییرات مشکوک در مقادیر رجیستری یا کلیپ‌بورد برای تحلیل تاثیر این رفتارها روی ابزارهای EDR.
- تست‌های Sysmon: ارزیابی کارایی Ruleهای Sysmon در شناسایی سناریوهای فوق.
- نمایش خروجی ASCII برای تعامل بهتر و جذاب‌تر بودن تست‌ها.
کاربردها
این ابزار برای افراد زیر کاربرد ویژه دارد:
- تحلیلگران تهدید و محققان امنیتی که روی کشف و تحلیل رفتاری کار می‌کنند.
- ادمین‌ها و تیم‌های SOC که می‌خواهند کیفیت Ruleهای Sysmon یا سایر ابزارهای مانیتورینگ را بهبود دهند.
- افرادی که به دنبال شبیه‌سازی حملات در محیطی کنترل‌شده به سبک Atomic Red Team هستند.
#آکادمی_روزبه
ازجمله ابزارهای دوره های استاد روزبه
https://github.com/MHaggis/notes/blob/master/utilities/HiddenScheduledTasks.ps1
GitHub
notes/utilities/HiddenScheduledTasks.ps1 at master · MHaggis/notes
Full of public notes and Utilities. Contribute to MHaggis/notes development by creating an account on GitHub.
❤8🙏2
بررسی Privacy Impact Rating در طراحی نرم‌افزار ( دوره CISSP) و وضعیت آن در ایران
در دوره CISSP و اصول امنیت اطلاعات، Privacy Impact Rating (PIR) یا «درجه تأثیر بر حریم خصوصی» شاخصی است که مشخص می‌کند یک نرم‌افزار یا سیستم تا چه اندازه ممکن است حریم خصوصی کاربران را تحت تأثیر قرار دهد.
این مساله یکی از مقولاتی از که در ایران بدان توجه نمیشود.
مراحل PIR در طراحی نرم‌افزار:
شناسایی داده‌های حساس:
بررسی اینکه چه داده‌هایی جمع‌آوری و پردازش می‌شود (مثلاً نام، شماره ملی، ایمیل، اطلاعات پزشکی و…).
ارزیابی ریسک:
تحلیل اینکه هر نوع داده چقدر حساس است و اگر به بیرون نشت کند یا سوءاستفاده شود، چه پیامدهایی خواهد داشت.
تعیین درجه تاثیر:
بسته به نوع داده و کاربرد نرم‌افزار، یک رتبه (معمولاً کم، متوسط، بالا یا بالغ‌تر با عدد) برای تأثیر روی حریم خصوصی تعیین می‌شود.
تدوین کنترل‌ها:
بر اساس این ارزیابی، باید کنترل‌های فنی و اجرایی مانند رمزنگاری، دسترسی محدود و لاگ‌گیری را مشخص و اعمال کرد.
هدف PIR کمک به تصمیم‌گیری شفاف درباره طراحی، توسعه و پیاده‌سازی نرم‌افزار با رعایت حقوق خصوصی کاربران است. همچنین لازم است که PIR به روزرسانی شود و در هر تغییر اساسی، مجدداً بررسی شود.
پیامدهای نبود PIR و رعایت‌نکردن حریم خصوصی در ایران
در ایران، به دلایل مختلف (نبود مقررات جدی، ضعف فرهنگ سازمانی، مشکلات تکنیکی، …) معمولاً PIR رعایت نمیشود. این موضوع چند پیامد جدی دارد:
افزایش رخدادهای نقض داده:
داده‌های حساس کاربران مرتباً به بیرون نشت می‌کنند (نمونه: لو رفتن اطلاعات سامانه‌ها یا فروش اطلاعات در اینترنت).
کاهش اعتماد کاربران:
مردم اعتماد خود را به اپلیکیشن‌ها و سرویس‌های ایرانی از دست می‌دهند و ترجیح می‌دهند از نرم‌افزارهای خارجی یا روش‌های آفلاین استفاده کنند.
سوءاستفاده و کلاهبرداری:
شناسایی افراد، جعل هویت، و مقاصد مجرمانه به راحتی اتفاق می‌افتد چون داده‌ها به خوبی حفاظت نشده‌اند.
مشکلات حقوقی و اعتباری برای شرکت‌ها:
شرکت‌ها و سازمان‌ها ممکن است در سطح بین‌المللی اعتبار خود را از دست بدهند یا با تحریم و محرومیت از خدمات روبه‌رو شوند.
عدم تطابق با استانداردهای جهانی:
سازمان‌ها امکان همکاری با بخش بین‌الملل یا ورود به بازارهای جدید را از دست می‌دهند چون نمی‌توانند الزامات بین‌المللی حریم خصوصی (مثل GDPR) را پوشش دهند.
#آکادمی_روزبه
در دوره CISSP و اصول امنیت اطلاعات، Privacy Impact Rating (PIR) یا «درجه تأثیر بر حریم خصوصی» شاخصی است که مشخص می‌کند یک نرم‌افزار یا سیستم تا چه اندازه ممکن است حریم خصوصی کاربران را تحت تأثیر قرار دهد.
این مساله یکی از مقولاتی از که در ایران بدان توجه نمیشود.
مراحل PIR در طراحی نرم‌افزار:
شناسایی داده‌های حساس:
بررسی اینکه چه داده‌هایی جمع‌آوری و پردازش می‌شود (مثلاً نام، شماره ملی، ایمیل، اطلاعات پزشکی و…).
ارزیابی ریسک:
تحلیل اینکه هر نوع داده چقدر حساس است و اگر به بیرون نشت کند یا سوءاستفاده شود، چه پیامدهایی خواهد داشت.
تعیین درجه تاثیر:
بسته به نوع داده و کاربرد نرم‌افزار، یک رتبه (معمولاً کم، متوسط، بالا یا بالغ‌تر با عدد) برای تأثیر روی حریم خصوصی تعیین می‌شود.
تدوین کنترل‌ها:
بر اساس این ارزیابی، باید کنترل‌های فنی و اجرایی مانند رمزنگاری، دسترسی محدود و لاگ‌گیری را مشخص و اعمال کرد.
هدف PIR کمک به تصمیم‌گیری شفاف درباره طراحی، توسعه و پیاده‌سازی نرم‌افزار با رعایت حقوق خصوصی کاربران است. همچنین لازم است که PIR به روزرسانی شود و در هر تغییر اساسی، مجدداً بررسی شود.
پیامدهای نبود PIR و رعایت‌نکردن حریم خصوصی در ایران
در ایران، به دلایل مختلف (نبود مقررات جدی، ضعف فرهنگ سازمانی، مشکلات تکنیکی، …) معمولاً PIR رعایت نمیشود. این موضوع چند پیامد جدی دارد:
افزایش رخدادهای نقض داده:
داده‌های حساس کاربران مرتباً به بیرون نشت می‌کنند (نمونه: لو رفتن اطلاعات سامانه‌ها یا فروش اطلاعات در اینترنت).
کاهش اعتماد کاربران:
مردم اعتماد خود را به اپلیکیشن‌ها و سرویس‌های ایرانی از دست می‌دهند و ترجیح می‌دهند از نرم‌افزارهای خارجی یا روش‌های آفلاین استفاده کنند.
سوءاستفاده و کلاهبرداری:
شناسایی افراد، جعل هویت، و مقاصد مجرمانه به راحتی اتفاق می‌افتد چون داده‌ها به خوبی حفاظت نشده‌اند.
مشکلات حقوقی و اعتباری برای شرکت‌ها:
شرکت‌ها و سازمان‌ها ممکن است در سطح بین‌المللی اعتبار خود را از دست بدهند یا با تحریم و محرومیت از خدمات روبه‌رو شوند.
عدم تطابق با استانداردهای جهانی:
سازمان‌ها امکان همکاری با بخش بین‌الملل یا ورود به بازارهای جدید را از دست می‌دهند چون نمی‌توانند الزامات بین‌المللی حریم خصوصی (مثل GDPR) را پوشش دهند.
#آکادمی_روزبه
❤3👍2🙏1