آکادمی آموزش روزبه 📚

11 July 2025 11:25

حمله 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

آکادمی آموزش روزبه 📚

10 July 2025 17:54

👆👆قسمت دوم از پست قبل




بهره‌برداری: در صورت موفقیت، تیم قرمز از این حساب کاربری “زامبی” برای نفوذ اولیه به شبکه استفاده می‌کند و به این ترتیب، ضعف در فرآیند Offboarding را نه به صورت تئوری، بلکه به صورت عملی اثبات می‌کند.


چگونه تیم قرمز آسیب‌پذیری‌های فرآیندی را آشکار می‌کند؟

مهندسی اجتماعی: یک عضو تیم قرمز با واحد پشتیبانی فنی (Help Desk) تماس می‌گیرد و با جعل هویت یک مدیر ارشد، درخواست بازنشانی رمز عبور می‌کند. اگر پشتیبانی فنی بدون احراز هویت دقیق این کار را انجام دهد، یک آسیب‌پذیری فرآیندی بزرگ در “فرآیند احراز هویت و پشتیبانی” آشکار شده است. این سناریو یک ضعف تکنولوژیک نیست، بلکه یک ضعف رویه‌ای است.

تست نفوذ فیزیکی: عضوی از تیم قرمز با پوشیدن لباس مبدل (مثلاً لباس پیک یا تکنسین) تلاش می‌کند وارد ساختمان شرکت شود. اگر نگهبانان یا کارمندان به او اجازه ورود بدهند بدون اینکه هویت او را بررسی کنند یا با کسی هماهنگ کنند، این نشان‌دهنده ضعف در “فرآیندهای امنیت فیزیکی و کنترل دسترسی” است.

حرکت جانبی در شبکه (Lateral Movement): پس از نفوذ اولیه، تیم قرمز تلاش می‌کند در شبکه حرکت کند. اگر بتواند به سادگی از یک سیستم کم‌اهمیت به یک سرور حیاتی دسترسی پیدا کند، این ممکن است نشان‌دهنده ضعف در “فرآیند بخش‌بندی شبکه (Network Segmentation)” و “سیاست‌های دیوار آتش داخلی” باشد.

خروجی یک عملیات تیم قرمز موفق:

خروجی نهایی، گزارشی است که نه تنها آسیب‌پذیری‌های فنی، بلکه یک جدول زمانی دقیق از اقدامات تیم قرمز، واکنش (یا عدم واکنش) تیم آبی و لیستی از آسیب‌پذیری‌های فرآیندی کشف‌شده را ارائه می‌دهد. این گزارش به مدیران ارشد کمک می‌کند تا بفهمند چگونه یک مهاجم توانست با دور زدن سیاست‌ها و رویه‌ها، به اهداف خود دست یابد.
نتیجه‌گیری

امنیت سایبری مدرن، یک مبارزه چندلایه است که صرفاً با خرید جدیدترین ابزارهای تکنولوژیک به پیروزی نمی‌رسد. آسیب‌پذیری‌های فرآیندی، شکاف‌های خاموش و خطرناکی در زره دفاعی یک سازمان هستند که اغلب از چشم ابزارهای خودکار پنهان می‌مانند.

تیم قرمز با رویکرد واقع‌گرایانه و خصمانه خود، به مثابه یک “آینه حقیقت” عمل می‌کند. این تیم نه تنها حفره‌های موجود در تکنولوژی، بلکه ضعف‌های ریشه‌دار در سیاست‌ها، رویه‌ها و فرهنگ امنیتی سازمان را آشکار می‌سازد. سرمایه‌گذاری بر روی عملیات تیم قرمز، یک گام حیاتی برای سازمان‌هایی است که می‌خواهند از یک رویکرد امنیتی واکنشی (Reactive) به یک رویکرد پیشگیرانه و هوشمند (Proactive) حرکت کرده و در برابر تهدیدات پیچیده امروزی، تاب‌آوری واقعی کسب کنند. در نهایت، قوی‌ترین دیوار آتش‌ها و پیچیده‌ترین سیستم‌های تشخیص نفوذ در برابر کارمندی که فریب یک ایمیل فیشینگ را می‌خورد یا فرآیندی که اجازه دسترسی بیش از حد می‌دهد، بی‌دفاع هستند.


#آکادمی_روزبه
مرکز تخصصی CISSP

آکادمی آموزش روزبه 📚

10 July 2025 10:19

مدیر امنیت زیر نظر کی باشه؟
شاید زمان تغییر نظر فرا رسیده

**روزبه نوروزی
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

آکادمی آموزش روزبه 📚

10 July 2025 07:53

متریک ها در امنیت سایبری
چیستی و اهمیت


روزبه نوروزی
Www.Roozbeh.academy


متریک: دقیقا چه میکنیم و آیا خوب عمل می‌کنیم؟


چرا متریک‌ها در امنیت سایبری حیاتی هستند؟

یک جمله معروف در مدیریت می‌گوید: “اگر نتوانی چیزی را اندازه‌گیری کنی، نمی‌توانی آن را بهبود ببخشی.” این جمله دقیقاً قلب اهمیت متریک‌ها در امنیت سایبری است. بدون اندازه‌گیری، تیم‌های امنیتی در تاریکی عمل می‌کنند و نمی‌دانند تلاش‌هایشان چقدر مؤثر است، کجا ضعف دارند و منابع خود را باید در کجا سرمایه‌گذاری کنند.

دلایل کلیدی اهمیت متریک‌ها عبارتند از:

1. ایجاد شفافیت و درک وضعیت فعلی (Visibility):

متریک‌ها وضعیت واقعی امنیت سازمان شما را به تصویر می‌کشند. به جای اینکه بگویید “فکر می‌کنم وضعیت امنیتی ما خوب است”، می‌توانید با داده صحبت کنید: “در ماه گذشته، تعداد آسیب‌پذیری‌های حیاتی ما 15% کاهش یافته است.” این شفافیت به شما کمک می‌کند تا نقاط قوت و ضعف واقعی خود را بشناسید.

2. تصمیم‌گیری مبتنی بر داده (Data-Driven Decision Making):

🎯 به جای خرید جدیدترین و گران‌ترین ابزار امنیتی چون مُد شده است، متریک‌ها به شما کمک می‌کنند تا سرمایه‌گذاری‌های خود را هوشمندانه انجام دهید. برای مثال، اگر متریک‌ها نشان دهند که 80% از حوادث امنیتی شما ناشی از حملات فیشینگ است، منطقی است که بودجه بیشتری را به آموزش آگاهی‌بخشی کاربران و تقویت امنیت ایمیل اختصاص دهید تا خرید یک فایروال جدید.

3. سنجش پیشرفت و بازگشت سرمایه (Measuring Progress & ROI):

📈 چگونه می‌فهمید که ابزار جدیدی که خریده‌اید یا کمپین آموزشی که برگزار کرده‌اید، مؤثر بوده است؟ با متریک‌ها؛ شما می‌توانید وضعیت را قبل و بعد از یک اقدام خاص مقایسه کنید. برای مثال، می‌توانید “نرخ کلیک روی لینک‌های فیشینگ شبیه‌سازی شده” را قبل و بعد از یک دوره آموزشی اندازه‌گیری کنید. این به شما کمک می‌کند تا بازگشت سرمایه (ROI) اقدامات امنیتی خود را به مدیران نشان دهید.

4. ارتباط مؤثر با مدیران و ذی‌نفعان (Communication):

📊 مدیران ارشد و اعضای هیئت مدیره زبان فنی امنیت را متوجه نمی‌شوند، اما زبان اعداد، نمودارها و روندها را به خوبی درک می‌کنند. متریک‌ها به شما این امکان را می‌دهند که ریسک‌های امنیتی و نیازهای خود را به زبانی قابل فهم برای آنها ترجمه کنید. به جای گفتن “ما به یک سیستم SIEM نیاز داریم”، می‌توانید بگویید: “در حال حاضر، میانگین زمان شناسایی یک نفوذ در شبکه ما 90 روز است. با پیاده‌سازی این سیستم، می‌توانیم این زمان را به کمتر از 2424 ساعت کاهش دهیم و ریسک مالی ناشی از نشت اطلاعات راX% کم کنیم.”

5. انطباق با قوانین و استانداردها (Compliance):

بسیاری از مقررات و استانداردها (مانند GDPR، HIPAA یا PCI-DSS) سازمان‌ها را ملزم می‌کنند تا نشان دهند که اقدامات امنیتی لازم را انجام داده‌اند. متریک‌ها بهترین مدرک برای اثبات این انطباق هستند. به عنوان مثال، می‌توانید با ارائه متریک “پوشش اسکن آسیب‌پذیری” نشان دهید که 99% از دارایی‌های شبکه به طور منظم اسکن می‌شوند.

6. حرکت از رویکرد واکنشی به پیشگیرانه (Proactive vs. Reactive):

متریک‌ها به شما کمک می‌کنند تا روندها را قبل از اینکه به یک بحران تبدیل شوند، شناسایی کنید. اگر می‌بینید که “تعداد تلاش‌های ناموفق برای ورود به سیستم” به طور ناگهانی در حال افزایش است، می‌توانید قبل از وقوع یک حمله موفق، اقدامات پیشگیرانه انجام دهید.


برخی از مهم‌ترین متریک‌های امنیت سایبری

متریک‌ها باید هوشمندانه انتخاب شوند. جمع‌آوری صدها متریک بی‌فایده است. بهتر است روی تعداد کمی متریک کلیدی که مستقیماً با اهداف کسب‌وکار شما مرتبط هستند، تمرکز کنید. در اینجا برخی از مهم‌ترین متریک‌ها در دسته‌بندی‌های مختلف آورده شده‌اند:
🛡️ دسته ۱: مدیریت آسیب‌پذیری (Vulnerability Management)

این متریک‌ها نشان می‌دهند که سازمان شما با چه سرعتی آسیب‌پذیری‌ها را شناسایی و رفع می‌کند.

میانگین زمان رفع آسیب‌پذیری (Mean Time to Remediate - MTTR):

چه چیزی را اندازه می‌گیرد؟ میانگین زمان از لحظه شناسایی یک آسیب‌پذیری تا لحظه‌ای که به طور کامل رفع (مثلاً با نصب پچ) می‌شود.

چرا مهم است؟ این یکی از حیاتی‌ترین متریک‌هاست. هرچه این زمان کوتاه‌تر باشد، فرصت کمتری در اختیار مهاجمان برای سوءاستفاده از آن ضعف قرار می‌گیرد. معمولاً این متریک بر اساس شدت آسیب‌پذیری (حیاتی، بالا، متوسط) تفکیک می‌شود.

پوشش اسکن آسیب‌پذیری (Vulnerability Scan Coverage):

چه چیزی را اندازه می‌گیرد؟ چه درصدی از کل دارایی‌های شناخته‌شده (سرورها، لپ‌تاپ‌ها، …) در سازمان به طور منظم توسط اسکنرهای آسیب‌پذیری بررسی می‌شوند.

پایان بخش اول

#آکادمی_روزبه
مرکز تخصصی CISSP

بخش دوم در پست بعد👇👇

آکادمی آموزش روزبه 📚

09 July 2025 07:45

مستندی که در جلسه اول دوره مدیریت بحران سایبری بررسی شد

✅ثبت نام دوره بعدی
از طریق واتس اپ و بله 09902857290
برگزاری دوره با تسهیلات ویژه شرکت هامون

#آکادمی_روزبه
مرکز تخصصی CISSP

جلسه دوم بحث عملیات فنی فارنزیک رو داریم

آکادمی آموزش روزبه 📚

08 July 2025 18:24

نقدی بر انتقاد به نقد من به رسمیو

در یک نگاه کلی، استدلال «چون اطلاعات پراکنده در وب هست، پس ایراد گرفتن از جمع‌کننده‌ (رسمیو) بی‌معناست» یک مغالطه‌ی رایج به نام «طبیعی‌سازی» (Appeal to Nature) یا «چون فلان چیز وجود دارد پس استفاده از آن ایرادی ندارد» است. در عمل اما چند نکته کلیدی هست که همچنان نقد من را معتبر و حتی ضروری می‌کند:

تجمیع (Aggregation) ریسک را چند برابر می‌کند
هر تکه داده به‌تنهایی شاید کم‌خطر باشد، اما وقتی با سایر داده‌ها ترکیب شود، پروفایلی جامع و بسیار حساس ساخته می‌شود.
این همان «aggregation vulnerability» است: چیزی که در حالت پراکنده به سادگی قابل سوءاستفاده نیست، پس از جمع‌آوری هوشمندانه به یک بردار حمله قدرتمند بدل می‌شود.

«دسترسی عمومی» ≠ «استفاده بی‌حد و مرز»
صرفِ اینکه یک سند یا داده‌ای در سایت‌های مختلف پیدا می‌شود، به معنای مجوز نشر دوباره و بی‌قید و شرط آن نیست.
اصول GDPR و قوانین داخلی مشابه می‌گویند حتی برای داده‌هایی که «عمومی» تلقی می‌شوند، باید مبنای قانونی (مثل رضایت موضوع داده یا ملاحظات موجه عمومی) وجود داشته باشد.

مسئولیت‌های اخلاقی و OPSEC
روزنامه رسمی با حذف یا عدم انتشار برخی فیلدها (مکان، آدرس منزل، روابط نزدیک با افراد پرخطر و …)، عمداً یک لایه حداقلی حفاظتی برای VIP‌ها و قضات و … ایجاد می‌کند.
وقتی استارتاپی مثل رسمیو آن لایه را خنثی می‌کند، مجدداً افراد را در معرض مهندسی اجتماعی، سرقت هویت یا حتی تهدید‌های فیزیکی قرار می‌دهد.

پروژه‌های aggregator وظیفه دارند مکانیزم‌های کاهش مخاطره را پیاده کنند
امکان «درخواست حذف» (Right to be Forgotten)
فیلتر کردن خودکار اطلاعات حساس (آدرس منزل، شماره‌ی موبایل شخصی، سابقه پزشکی، و….)
اخطار به کاربر نهایی در مورد ریسک‌های احتمالیِ داده‌های حساس

شفافیت اقتصادی یا منافع کسب‌وکاری، اولویت را نباید بر حریم خصوصی و امنیت افراد بگذارد
حتی اگر شفافیت اقتصادی دستاورد خوبی باشد، باید بین «شفافیت برای عموم» و «افشای اطلاعات شخصی» تعادل برقرار شود.
بسیاری کشورها، از جمله اعضای اتحادیه اروپا، برای همین تعادل چارچوب‌های قانونی و نظارتی تعریف کرده‌اند.

جمع‌بندی

استدلال «چون داده‌ها قبلاً آزاد بودند پس اشکالی ندارد» در سطح فلسفی یا منافع بیزینسی ممکن است قانع‌کننده باشد، اما در عمل نسبت به ریسک aggregation، مسئولیت قانونی/اخلاقی و نیاز به حفظ OPSEC افراد بسیار آسیب‌زننده است.
بنابراین نقد من کاملاً به‌جا است: هر پروژه‌ای که داده‌های پراکنده را جمع می‌کند، باید سازوکارهای حذف اطلاعات حساس، اخذ رضایت و کنترل ریسک را حتماً در طراحی خود بگنجاند.

#آکادمی_روزبه
مرکز تخصصی CISSP

آکادمی آموزش روزبه 📚

07 July 2025 08:10

👆👆🛑نقد عملکرد استارتاپ رسمیو

یکی از چالشی‌ترین تقاطع‌های امنیت اطلاعات، حریم خصوصی و دسترسی آزاد به داده‌ها در خصوص عملکرد شرکت رسمیو میتواند موضوع بحث باشد، که اتفاقاً مشابه همین مباحث در بسیاری از کشورها (مانند عدالتِ داده‌ها و توازن امنیت-شفافیت) مطرح شده است.
بیایید موضوع را از دو بخش بررسی کنیم: تحلیل انتقادی پروژه رسمیو و مفهوم آن در امنیت اطلاعات.


⚖️ ۱) تحلیل انتقادی عملکرد رسمیو

الف) مزایا و انگیزه‌ها

رسمیو با جمع‌آوری داده‌ها (کراول، ترکیب منابع پراکنده، بازیابی داده‌های حذف‌شده یا ناقص) شفافیت بالاتری برای کسب‌وکارها ایجاد کرده است، مثلاً دسترسی به سوابق شرکت‌ها، مدیران، و… که به شفافیت اقتصادی و اعتبارسنجی کمک می‌کند.
داده‌های ثانویه‌ای که روزنامه رسمی عمداً پنهان/حذف می‌کند را بازتولید یا ترکیب کرده است؛ این برای برخی گردش‌های مالی و تصمیم‌گیری تجاری یک مزیت است.

ب) نقاط منفی و نقدهای امنیتی

حریم خصوصی افراد: علت اصلی حذف بخشی از داده‌ها توسط روزنامه رسمی، محافظت از اشخاص مهم بوده است: جلوگیری از شناسایی آسان مدیران ارشد، قضات، و… (به‌ویژه در مورد پرونده‌های ویژه یا پرخطر).
رسمیو با بازسازی و انتشار این داده‌ها، عملاً اقدامات روزنامه رسمی برای پنهان‌سازی یا حداقل‌سازی ریسک هدف قرار گرفتن افراد مهم را خنثی کرده است.
این موضوع می‌تواند تهدیدهایی مثل حملات مهندسی اجتماعی، سوءاستفاده دزدان هویت، اختلال خدمات، یا حتی سناریو‌های ترور یا اخاذی (بخصوص برای مدیران سطح بالا و پرخطر) و حتی ترور را افزایش دهد.
مسئله‌ی مطابقت با قوانین حمایت از داده‌ها (مثلاً GDPR معادل داخلی آن)، شفافیت در اعلام منبع داده، رضایت افراد و حذف پروفایل در صورت اعتراض، هم مطرح است.

🔐 ۲) دسته‌بندی این بحث در حوزه امنیت اطلاعات

در طبقه‌بندی کلاسیک امنیت اطلاعات، این موضوع در قالب مفاهیم زیر قابل تحلیل است:
۱. Privacy vs. Security

جمع‌آوری و انتشار اطلاعات افراد (خصوصاً افراد پرخطر) بدون رعایت حداقل الزامات حفاظت از حریم خصوصی یا رضایت، در “بازی با مرز امنیت و شفافیت” قرار می‌گیرد.

۲. Threat Intelligence Exposure

فراهم‌سازی اطلاعات شناسایی‌شده در سطح وسیع برای افراد خاص (VIP Exposure) عملاً به مخاطره انداختن OPSEC آن‌ها (Operations Security: امنیت عملیات) است.
در مدل VIP Threat Modeling، هرگونه data aggregation که موقعیت، آدرس یا روابط قدرت را آشکارتر کند، یک تهدید محسوب می‌شود.

۳. Data Aggregation Risks

رویکرد رسمیو با کنار هم گذاشتن داده‌های پراکنده و ساختن پروفایل جامع، یک نمونه مشخص از aggregation threat است؛ یعنی خطری که در تئوری امنیت اطلاعات با عنوان “aggregation vulnerability” شناخته می‌شود.

۴. Legal & Ethical Considerations

در جمع‌آوری، نگهداری و افشای داده‌ها، بحث‌های قانونی (data protection law) و اخلاقی (سود عامه در مقابل آسیب به فرد) هم مطرح است که فراتر از حوزه فنی صرف است.

📋 جمع‌بندی و توصیه

قابل نقد بودن: عملکرد رسمیو از منظر امنیت اطلاعات، به خصوص در حوزه حفاظت از شخصیت‌های حساس (VIP Protection) و حداقل‌سازی حملات هدفمند و ترور قابل نقد جدی است. هر پروژه Aggregator باید مکانیزم‌های حذف داده‌های حساس، امکان opt-out برای اشخاص و ارزیابی ریسک داشته باشد.
موضوع امنیتی: این بحث در دسته‌ی OPSEC (امنیت عملیات)، Aggregation Risk و VIP Threat Modeling قرار می‌گیرد.
توصیه: لازم است رسمیو و پروژه‌هایی از این جنس، علاوه بر رعایت قانون و دسته بندی اطلاعات ، یک چارچوب ethical و حداقل یک مکانیزم درخواست حذف (Right to be Forgotten) برای داده‌های حساس پیاده‌سازی کنند؛ و همچنین با نهادهای مسئول هماهنگ باشند.

#آکادمی_روزبه
مرکز تخصصی CISSP

✴️این مطلب پیرو تصویر پست قبل به نگارش در آمده است

آکادمی آموزش روزبه 📚

06 July 2025 19:33

آشنایی با ابزارهای تجاری تیم قرمز

ابزار SHELLTER چگونه امنیت را دور می‌زند؟

۱. تزریق پویای بدافزار (Dynamic Shellcode Injection)
ابزار Shellter فایل اجرایی (exe) سالم و معتبری را برمی‌دارد و کد مخرب را به صورت داینامیک داخل آن تزریق می‌کند.
نقاط ورود (Entry point) را طوری تغییر می‌دهد که ابتدا کد خودش اجرا شود بعد برنامه اصلی.
این روش باعث می‌شود فایل نهایی از نظر ظاهری سالم و مثل فایل واقعی به نظر بیاید، حتی امضا (signature) و متادیتا هم حفظ می‌شود❗

۲. کد مخفی و تغییرشونده (Polymorphic Obfuscation)
کد مخرب دائماً خودش را تغییر می‌دهد (Polymorphic/Junk code) تا هیچ Signature ثابتی برای تشخیص وجود نداشته باشد.
ترکیبی از دستورات بی‌معنی (NOPها، دستورات بی‌اثر) و تغییر ساختار shellcode باعث گیج شدن ابزارهای تحلیل و AV می‌شود.
۳. بارگذاری مرحله‌ای و رمزنگاری شده (Staged & Encrypted Payload)
کد مرحله‌ای (Staged): مرحله اول فقط loader است، اصل بدافزار بعداً و با شرایط خاص decrypt و اجرا می‌شود.
محتوا اکثراً Encode یا Encrypt شده. تا موقع اجرا شدن، چیزی از بدافزار به چشم AV نمی‌آید.
۴. استفاده از APIهای معمولی و رفتار عادی سیستم (Living off the Land)
برای اختصاص حافظه و اجرای shellcode، دقیقاً مثل نرم‌افزارهای معمول از APIهای ویندوز مثل VirtualAlloc و CreateFileMapping استفاده می‌کند.
در نتیجه، رفتار آن خیلی به برنامه‌های قانونی شبیه است و hunting مبتنی بر رفتار (behavioral detection) نیز چالش دارد.
۵. فرار از تحلیل استاتیک و دینامیک (Static & Dynamic Evasion)
با افزودن لایه‌های junk code و rerouting execution، ابزارهای تحلیل مثل IDA Pro یا Sandbox را گمراه می‌کند.
حتی بعضی نسخه‌ها محیط اجرا را چک می‌کنند (Anti-VM)، اگر Sandbox یا VM باشد، اجرا نمی‌شوند یا رفتار جعلی نشان می‌دهند.


خلاصه ای بود از مقاله الستیک در لینک زیر

#آکادمی_روزبه
مرکز تخصصی CISSP

https://www.elastic.co/security-labs/taking-shellter?linkId=836491490

آکادمی آموزش روزبه 📚

06 July 2025 11:23

هند بوک دیجیتال فارنزیک

#آکادمی_روزبه
مرکز تخصصی CISSP

آکادمی آموزش روزبه 📚

05 July 2025 18:58

وقتی فرآیند صدور مجوز امنیتی برای کسب و کار ها ضعیف اجرا بشه ؛ هرکسی میتونه اطلاعاتی داشته باشه که نباید.
اطلاعات این سایت شاید در برخی ترور ها مؤثر بوده .

فعلا که سایت رسمیو که اطلاعات شرکتها رو ریخته بود کف اینترنت از دسترس خارج شده که این خوبه

امید که من بعد مجوز به چنین کسب و کارهایی با دقت بیشتری انجام بشه

آکادمی آموزش روزبه 📚

05 July 2025 17:24

راهنمای لاگ گیری در لینوکس

از CrowdStrike


#آکادمی_روزبه
مرکز تخصصی CISSP

https://www.crowdstrike.com/en-us/guides/linux-logging/

آکادمی آموزش روزبه 📚

05 July 2025 11:53

دور خوردن EDR های مهم

نویسنده نشان می‌دهد که چگونه با io_uring (که مثل یک تونل خاص و کم‌سروصدا برای کار با فایل/شبکه به لینوکس اضافه شده)، می‌شود داده‌ها را خواند/نوشت/ارسال کرد بدون آنکه EDRهای مهم (مثل CrowdStrike Falcon, SentinelOne, یا حتی بعضی نمونه‌های Open Source مثل Wazuh اگر به syscall tracing تکیه کنند) متوجه شوند.
کد ارائه‌شده، یک backdoor عملی است که داده و ران‌فرمان از C2 می‌گیرد و همه عملیاتش را بدون syscall کلاسیک انجام می‌دهد.
اگر در تیم آبی کار می‌کنید، باید حواستان باشد که سیستم فقط با بررسی classic syscallها امن نیست.

راه‌حل: باید روی بحث kernel tracing، eBPF مخصوص io_uring، و شبکه تمرکز کنید.


این مقاله یک آگاهی مهم برای عملیات SOC/LINUX EDR است:

روش‌های مبتنی بر syscall hooking کافی نیست!
باید ابزارهای جدید و مانیتورینگ مبتنی‌بر eBPF/Kernel-level را جدی‌تر بگیرید.
برای Red Teamها، io_uring یک راه جذاب برای فرار از بسیاری از محصولات EDR-Linux است (تا زمانی که detection rule به آن نخورده).


#آکادمی_روزبه
مرکز تخصصی CISSP

https://matheuzsecurity.github.io/hacking/evading-linux-edrs-with-io-uring/

آکادمی آموزش روزبه 📚

04 July 2025 19:54

در دنیای پیچیده امنیت اکتیو دایرکتوری، مدیریت دسترسی‌ها و مکانیزم‌های Delegation نقشی حیاتی در حفظ امنیت زیرساخت ایفا می‌کنند.
یکی از حوزه‌هایی که گهگاه کمتر مورد توجه قرار می‌گیرد اما ظرفیت بالایی برای ایجاد تهدیدات جدی دارد، بحث Delegation به ویژه در قالب Unconstrained Delegation است.
در این مدل، حساب‌ها مجاز هستند بدون محدودیت اعتبارنامه کاربران را به سرویس‌های دیگر منتقل کنند؛ موضوعی که اگر به‌درستی مدیریت نشود، می‌تواند به مهاجمان امکان دسترسی گسترده و حتی تصرف کامل Domain را بدهد.

مساله Group Managed Service Account یا gMSA یکی از انواع حساب‌هایی است که برای مدیریت سرویس‌ها و برنامه‌ها در محیط‌های بزرگ استفاده می‌شود. هرچند طراحی gMSA با هدف بهبود امنیت انجام شده، اما در صورت استفاده نادرست یا پیکربندی اشتباه، به نقطه ضعف تبدیل خواهد ‌شد؛ به ویژه زمانی که با Unconstrained Delegation ترکیب شود.

این مقاله به بررسی چرایی اهمیت این تهدید، روش‌های شناسایی و بهره‌برداری مهاجمان، و راهکارهای کاهش ریسک و بهبود امنیت gMSA و Delegation می‌پردازد


این مقاله حمله به حساب‌های gMSA با Unconstrained Delegation را توضیح می‌دهد. مهاجم با شناسایی gMSAهای دارای این ویژگی، بررسی سرورهای هدف و استخراج پسورد (از طریق دسترسی پرمیشن یا حمله NTLM Relay)، می‌تواند کنترل کامل دامنه را به دست آورد. ابزارهایی مثل Impacket و gMSADumper این پروسه را تسهیل می‌کنند. اشیاء غیرفعال هم خطرناک هستند و باید حذف یا هاردن شوند. این مسیر حمله اغلب نادیده گرفته می‌شود و برای حفاظت باید Unconstrained Delegation در سطح دامنه محدود شده و دسترسی‌ها به دقت بررسی و محدود شوند.

#آکادمی_روزبه
مرکز تخصصی CISSP
https://nothingspecialforu.github.io/UCgMSAExploitation/

آکادمی آموزش روزبه 📚

04 July 2025 13:59

مروری بر روش‌های ترند در هانت


در دنیای فعلی امنیت سایبری، بیش از هر زمان دیگری مهاجمان به جای استفاده از بدافزارهای کلاسیک، به سراغ حملاتی رفته‌اند که با ابزارها و قابلیت‌های داخلی سیستم‌عامل اجرا می‌شوند. این حملات با نام LOTL (Living Off The Land) مشهورند و چالش اصلی آن‌ها برای تهدیدیابی این است که غالباً هیچ ردپای مشکوک یا فایل اجرایی خاصی بر جای نمی‌گذارند.

در این مقاله، به بررسی یک دیدگاه و سبک نوین در Threat Hunting می‌پردازم که تمرکز آن شکار این حملات در لایه‌ای بالاتر از IOCها و Signature است ـ با اتکا بر رفتار، فرضیه‌سازی، و تحلیل توالی رخدادها.

تعریف و اهمیت حملات LOTL

مقوله LOTL به معنای سوءاستفاده مهاجم از ابزارهای استاندارد، اسکریپت‌ها و سرویس‌های سیستم‌عامل (مثل PowerShell، WMI، RDP و…) است تا فعالیت مخرب خود را در پوشش رفتار مشروع انجام دهد. این رویکرد، شناسایی توسط AV، EDR و حتی SIEMهای مبتنی بر signature را بسیار سخت می‌کند و مهاجم می‌تواند تا هفته‌ها یا حتی ماه‌ها در سایه باقی بماند.

تهدیدیابی سنتی: چرا کافی نیست؟

در گذشته، hunting بیشتر مبتنی بر جستجو بر اساس IOC یا signature بود؛ آی‌پی مشکوک، هش فایل، یا وقوع یک رخداد شناسایی‌شده. این مدل hunting اغلب واکنشی است، وابسته به شواهد ملموس یا هشدارهای آماده.

اما حملات LOTL دقیقاً این مدل دفاع را دور می‌زنند؛ زیرا رفتارشان شبیه کارکرد عادی سیستم است، تنها تفاوت در توالی اجرا، بافتار (Context) و ترکیب رفتارهاست.

سبک جدید شکار تهدید: از Hypothesis-driven تا Behavior-based

اخیراً در یکی از مقالات مطرح ۲۰۲۵ به این نکته پرداخته شده که برای آشکارسازی حملات LOTL باید threat hunting را به سطحی فراتر از واکنش به هشدارها و Signatureها ببریم و رویکرد فعال و فرضیه‌محور را جایگزین کنیم.

کلیدواژه‌ها و رویکردها:

🔹️ فرضیه‌سازی پیش‌دستانه:

بجای انتظار برای هشدار، فرضیه‌هایی مثل «چه می‌شود اگر PowerShell بعد از ریموت RDP اجرا شود؟» یا «آیا افزایش ناگهانی ارتباطات WMI نشانه lateral movement نیست؟» طرح‌ریزی و براساس آن شکار آغاز گردد.

🔹️ مبنای رفتاری و تحلیلی:

تمرکز روی رفتار ابزارهای داخلی و Sequence رخدادها: اجرای cmd و powershell در ترکیب با هم، استفاده غیرمعمول از Task Scheduler یا ارتباطات مشکوک بعد از اجرای اسکریپت.

🔹️ کار با Telemetry عمیق و گسترده:

داده‌های EDR، Sysmon یا Memory Forensics باید لایه به لایه بررسی شوند تا ارتباط رخدادهای ظاهراً معمول در کنار هم، تصویر حمله را آشکار کند.

تحول عملیاتی در تیم‌ها؛ نکات کاربردی

و SOC و مهندسان کشف باید علاوه‌بر IOC به دنبال نشانه‌های رفتاری و تغییرات subtle در زنجیره عملیات مهاجم باشند.
فرضیه‌سازی و آزمون آن تبدیل به چرخه دائمی hunting و یادگیری می‌شود؛ با هر شکار موفق یا اشتباه، الگوریتم و ruleهای تشخیصی باید اصلاح و غنی‌تر گردند.
ابزارهایی چون Sysmon، UEBA، و EDRهایی با قابلیت correlation، محور hunting مدرن خواهند بود.


#آکادمی_روزبه
مرکز تخصصی CISSP

آکادمی آموزش روزبه 📚

04 July 2025 08:32

#تجربه
سورپرایزی در تحلیل رجیستری

روزبه نوروزی


در این مقاله، تجربیات و یافته‌های خودم درباره نکات طلایی و کمتر موردتوجه قرارگرفته‌ی Forensics رجیستری در ویندوز به اشتراک می‌گذارم. نکاتی که بارها در دنیای واقعی، سبب موفقیت در کشف دقیق نفوذ یا Persistence مهاجمین بوده‌اند.

اول ببینیم چرا رجیستری ویندوز یک Artifact ویژه‌ست؟

رجیستری محل ذخیره تنظیمات سیستم، برنامه‌ها، کاربر، تاریخچه فعالیت و حتی گاهی ردپای بدافزار و حملات است.
اما برخلاف ظاهر ساده‌اش، لایه‌های پنهان و پیچیده‌ای دارد که بسیاری از تحلیلگران به آن بی‌توجه‌اند.

سورپرایز کلیدی: هنر بازسازی کامل رجیستری

یکی از نکات حیاتی و کمتر آموزش‌داده‌شده، لزوم ترکیب سه منبع برای بازسازی دقیق رجیستری است:

فایل ثبت‌شده روی دیسک (مانند SOFTWARE)
فایل‌های Transaction Log (مانند SOFTWARE.LOG1)
و Hiveهای لودشده در حافظه (RAM)

چرا مهم است؟

بسیاری از تحلیلگران، فقط به فایل اصلی رجیستری نگاه می‌کنند. اما:

تغییرات اخیر یا حملات سریع معمولاً ابتدا در RAM و Transaction Log ثبت می‌شوند و شاید هرگز روی فایل دیسک نوشته نشوند.
بنابراین اگر فقط دیسک را بررسی کنیم، ممکن است یک حمله کاملاً از چشم ما دور بماند، مخصوصاً در سناریوهایی مثل Persistenceهای memory-only یا هنگام crash و خاموش شدن ناگهانی سیستم.

مثال واقعی از Gap عملیاتی

فرض کنید هکری، حمله‌ای برمبنای تغییر مقدار Autostart رجیستری اجرا کرده، اما سیستم قبل از Write شدن تغییرات، کرش می‌کند یا عمداً ریست می‌شود.

در این شرایط، فقط Hive رجیستری در RAM یا Transaction Log، شواهد تغییر را نگه‌داشته است — و فایل اصلی دیسک همچنان “پاک” به‌نظر می‌رسد.
راهکار ارزیابی کامل:

برای تحلیل کامل و اصولی، لازم است همیشه این مراحل را رعایت کنید:

استخراج کامل فایل‌های Registry و Logها از هارد دیسک (اگر سیستم روشن نبود)
استخراج و dump کردن حافظه (Memory) اگر سیستم زنده بود
تحلیل همزمان با ابزارهایی نظیر Cyber Triage، Registry Explorer، Rekall، Velociraptor و…
مقایسه Memory و Disk – تغییری فقط در مموری هست و روی دیسک نوشته نشده؟
تحلیل دقیق Last Write Time و بررسی همبستگی زمانی و رفتاری برای تایم‌لاین‌سازی حملات و Persistence

نکات تکمیلی برای متخصصین

این LastWriteTime فقط نشانه یک Change است، اما چه چیزی باعث Change شده؟ اضافه کردن Value؟ تغییر Subkey؟ حذف مقدار قبلی؟
ترکیب داده‌های Transaction Log می‌تواند بعضی اوقات تغییرات موقتی و نیمه‌کاره (Partial) را هم مشخص کند.
برخلاف باور عمومی، بعضی هک‌ها در RAM باقی می‌مانند و مهاجم‌ها می‌توانند با حملات Fileless اثرشان را فقط در RAM و Transaction Log نگه دارند (و نه روی Main Registry File).


#آکادمی_روزبه
مرکز تخصصی CISSP

آکادمی آموزش روزبه 📚

10 July 2025 23:16

🔴مهم و جدید: وقتی 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

آکادمی آموزش روزبه 📚

10 July 2025 17:54

آسیب پذیری های فرآیند ها
چالشی قابل رفع با 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

آکادمی آموزش روزبه 📚

10 July 2025 07:53

👆👆قسمت دوم از پست قبل

چرا مهم است؟ اگر شما تنها 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

آکادمی آموزش روزبه 📚

09 July 2025 11:10

جلسه دوم استوریج
نفوذ، کشف و فارنزیک

با حملات روز در ایران به روز باشیم

آکادمی آموزش روزبه 📚

09 July 2025 07:36

وقتی می‌گویم در SOC دقیق باشیم یعنی چه؟

** از مجموعه مقالات : آنچه SOC های ایران بدان گرفتارند!!

وقتی یک هشدار اجرای مشکوک PowerShell را در سامانه‌ی اسپلانک مشاهده می‌کنید، اگر به آن فقط به عنوان یک Event جداگانه نگاه کنید، میزان واقعی تهدید را درک نخواهید کرد. اما با تحلیل هوشمند و ردیابی زنجیره حمله، می‌توانید سناریوهای چندمرحله‌ای و پیچیده را شناسایی کنید—که این دقیقاً همان نقطه تمایز یک SOC حرفه‌ای مبتنی بر Threat Hunting نسبت به SOCهای صرفاً قاعده‌محور است.

مثال :

فرض کنید مهاجم ابتدا با یک آسیب‌پذیری در Exchange Server کد PowerShell را اجرا می‌کند (Initial Access و Execution). فقط این هشدار ثبت می‌شود:

powershell.exe -EncodedCommand <base64>

در نگاه اول، شاید این فقط اجرای یک اسکریپت باشد. اما با بررسی دقیق‌تر متوجه می‌شوید که:

ساعتی بعد، یک Scheduled Task جدید روی همان سرور ساخته شده (schtasks.exe /create ...)، که به PowerShell اشاره دارد (Persistence)
همزمان یک ارتباط Reverse Shell به سمت IP ناشناس در اینترنت برقرار شده (Command & Control)
فایل‌های لاگ در آن سرور توسط یک اسکریپت پاک‌سازی یا تغییر یافته‌اند (Defense Evasion)
نهایتاً چهار روز بعد، روی یکی از سرورهای Domain Controller همان نشانه‌های رفتاری (PowerShell، Task scheduling، ارتباط به خارج) دیده می‌شود (Lateral Movement & Privilege Escalation)

در این وضعیت، صرفاً داشتن یک rule ساده که بگوید «هر اجرای مشکوک PowerShell را هشدار بده» راهگشا نیست. یک هانتر (Threat Hunter) واقعی، این سیگنال‌های پراکنده را به هم متصل می‌کند و می‌تواند زنجیره حمله (Kill Chain) را شناسایی و جلوی گسترش آن را در مراحل ابتدایی بگیرد.

در عمل، این شیوه تحلیل، SOC شما را از یک مرکز هشداردهی منفعل، به یک تیم شکار تهدید فعال و هوشمند ارتقا می‌دهد—جایی که شناسایی اجرای اولیه، دور زدن مکانیزم‌های دفاعی و ایجاد ماندگاری مهاجم، هم‌زمان کشف و مهار می‌شود. این همان تفاوت کار SOC حرفه‌ای با رویکرد threat hunting و توسعه‌یافته نسبت به rule-based analysis است

#آکادمی_روزبه
مرکز تخصصی CISSP

آکادمی آموزش روزبه 📚

07 July 2025 14:03

امروز ؛ جلسه اول دوره مدیریت بحران سایبری
مدرس: استاد روزبه

واتس اپ و بله برای رزرو دوره مرداد ماه :09902857290

برگزاری با تسهیلات و تخفیف ویژه شرکت پیشگامان فناوری اطلاعات هامون
www.haumoun.com

آکادمی آموزش روزبه 📚

06 July 2025 21:52

جناب ملک نژاد ؛ امنیت یا شفافیت ؟

خروجی اگر ترور باشد دیگر شفافیت معنا ندارد

برادر من؛ با جان مردم بازی میکردی و امنیت کشور دست شما بوده

آکادمی آموزش روزبه 📚

06 July 2025 19:03

نگاهی به تاریخچه نشت ابزارهای تجاری هک
(از Red Team تا سلاح واقعی نزد مهاجمان)


مقدمه
در سال‌های اخیر، موجی از نشت و افشای ابزارهای حرفه‌ای و تجاری هک و Red Team به دست هکرها و مهاجمان واقعی افتاده است. ابزارهایی که اساساً با هدف تست نفوذ قانونی، ارزیابی امنیت سازمان‌ها و آموزش نیروهای امنیتی توسعه یافته‌اند، پس از نشت، به سلاح‌های مورد علاقه مهاجمان برای طراحی حملات واقعی تبدیل شده‌اند. این وقایع، چالش‌های تازه‌ای برای تیم‌های SOC و عملیات دفاعی به همراه آورده است.

موارد مشهور نشت ابزارهای هک (Timeline)

1. Hacking Team Leak (2015)
توضیح: شرکت ایتالیایی Hacking Team تولیدکننده نرم‌افزار نظارتی RCS Galileo بود. در سال ۲۰۱۵، نزدیک به ۴۰۰ گیگابایت داده شامل سورس‌کد و exploit به صورت عمومی نشت یافت.
پیامد: آسیب‌پذیری‌های zero-day، ابزارهای C2 و exploitها به صورت گسترده مورد سوءاستفاده مهاجمان از جمله APTها قرار گرفت.
2. Equation Group / Shadow Brokers Leak (2016-2017)
توضیح: گروه Shadow Brokers مجموعه ابزارهای هک متعلق به Equation Group (منسوب به NSA) را افشا کرد. ابزارهای مانند EternalBlue، DoublePulsar و غیره.
پیامد: رخدادهایی مانند حمله WannaCry، NotPetya و ظهور exploitation گسترده SMB.
3. Cobalt Strike Leaks
توضیح: ابزار Cobalt Strike یکی از محبوب‌ترین فریم ورک‌های C2 Red Team است که بارها نسخه کرک‌شده یا لو رفته آن در دارک‌وب و فروم‌ها پخش شده است.
پیامد: حضور گسترده مهاجمان حرفه‌ای، باج‌افزارها و گروه‌های APT در حملات واقعی با استفاده از نسخه‌های afk و obfuscated.
4. Brute Ratel Leak (2022)
توضیح: Brute Ratel یک ابزار C2 بسیار پیشرفته و ضد‌شناسایی است که پس از مدت کوتاهی از عرضه رسمی، نسخه‌ای از آن نشت پیدا کرد و در اختیار مهاجمان (حتی باج‌افزار) قرار گرفت.
پیامد: بالا رفتن قابلیت فرار از EDR/AV، حملات بسیار پیشرفته و دشواری کشف.
5. Mythic & Other C2 Frameworks
توضیح: ابزار Mythic (اپن‌سورس اما غیرتجاری)، همچنین فریم‌ورک‌های C2 جدید نیز بارها قربانی نشت یا سواستفاده توسط مهاجمان شده‌اند؛ گاهی حتی با «باینری‌های شخصی‌سازی‌شده» (custom build) در حملات واقعی کشف شده‌اند.
6. Shellter Elite Leak (2025)
توضیح: نشت نسخه تجاری Shellter Elite به دست مهاجمان و استفاده برای infostealer و bypass کردن EDRها.

دلایل و بسترهای نشت ابزارهای هک

۱. رخنه از سوی مشتریان نهایی (Buyers/Customers)
عدم رعایت OPSEC مشتری، سوءاستفاده عمدی، فروش مجدد در دارک‌وب
۲. هک شدن خود سازنده‌ها (developer breach)
رخدادهایی مانند HackingTeam و ابزارهای NSA
۳. افزایش جذابیت مالی برای مجرمان
فروش نسخه‌های کرک‌شده یا منتقل شده در بدافزار-as-a-service
۴. جنگ سرد سایبری و اسپانسرهای ملی
بازیگران دولتی ابزارها را به صورت عمدی یا اتفاقی نشت می‌دهند
۵-عدم پیگیری قضایی کافی در برخی کشورها


تأثیر و پیامدهای عملیاتی نشت ابزارهای تجاری هک

-افزایش حملات سطح بالا و پیچیده
-گیج شدن تیم‌های دفاعی و SOC(بدافزارها با امضای Red Team ساخته می‌شوند، خطاهای False negative و hunting سخت‌تر می‌شود)
-شتاب رشد ضد‌شناسایی (evasion techniques)
-ضرورت همکاری بیشتر بین تیم‌های توسعه ابزار و تیم‌های تحلیل تهدید
-ظهور بازارهای جدید برای بدافزارهای ناشی از این ابزارها


رویکردهای دفاعی برای SOC و مدیران امنیت

1-به‌روز نگه‌داشتن TI و IOC
توجه ویژه به تحلیل‌های فنی در مورد نسخه‌های afk یا لو رفته ابزارها
2-برقراری تماس مستقیم با سازندگان ابزارها برای هشدار‌دهی و رفع تهدید
3-توسعه Playbookهای Incident Response مخصوص ابزارهای مشهور نشت یافته
4-بهره‌گیری از Telemetry و رفتارشناسی (Behavioral Analytics به جای صرف امضا)
5-آموزش تیم‌های Blue Team با سناریوهای واقعی حمله Red Tool لو رفته
6-شناساگرهای memory-based و شبکه محور، به جای شناسایی صرف باینری


#آکادمی_روزبه
مرکز تخصصی CISSP

آکادمی آموزش روزبه 📚

05 July 2025 20:22

مساله دیگری که درخصوص اطلاعات درج شده در این سایت هست که آدم متاسف میشه ازش ، رانت هست. خیلی ها که در ایران در حوزه امنیت کار میکنند حتی نمیتونن لینکدین داشته باشند یا محل کارشون رو در لینکدین بنویسند حتی اگر یک بانک باشه.

اما از اون طرف دانشمندان هسته ای ما در شرکت های مختلف عضو بودن و اسمشون به راحتی هرجایی بوده. لذا خیلی هم تقصیر سایت رسمیو نیست . تقصیر خود اون دانشمند و حراست واحد های مربوطه هم هست.
درسته رسمیو طبقه بندی اطلاعاتی نداشته و از این بابت مقصره ولی خود اون افراد هم نباید اینقدر تابلو اطلاعاتشون رو اینور و اونور می‌دادند.


✅انشالله از دوشنبه مباحث OPSEC و SECOPS رو در دوره مدیریت بحران سایبری بررسی و تدریس خواهم کرد.

آکادمی آموزش روزبه 📚

05 July 2025 18:03

امکان سوءاستفاده سخت‌افزاری از طریق رابط‌های پنهان دیباگ (مطالعه موردی: EUD/JTAG در چیپست‌های Qualcomm)

✅️بخشی از دوره مدیریت بحران سایبری آکادمی روزبه

مقدمه

در عصر اینترنت اشیاء، موبایل و تجهیزات متصل، امنیت سخت‌افزاری کمتر از لایه نرم‌افزاری مورد توجه قرار گرفته است. در حالی که تمرکز اکثر تیم‌های امنیت بر آسیب‌پذیری‌های نرم‌افزاری و شبکه‌ای است، وجود رابط‌های دیباگ پنهان نظیر JTAG و EUD (Embedded USB Debug) در بسیاری از سخت‌افزارهای مدرن، به یک خطر بالقوه تبدیل شده است. این منافذ به مهاجم امکان می‌دهد فارغ از محدودیت‌های سیستم‌عامل یا حتی Secure Boot، کنترل سطح پایین دستگاه را در اختیار بگیرد.

ماهیت تهدید

رابط‌هایی مانند JTAG و SWD (Serial Wire Debug)، طراحی شده‌اند تا توسعه‌دهندگان و تعمیرکاران بتوانند سخت‌افزار را دیباگ و تحلیل کنند. در بسیاری از پردازنده‌های موبایلی نظیر Qualcomm Snapdragon، این رابط‌ها به شکل پنهان، در پورت USB ادغام یا از طریق فریم‌ویر فعال می‌شوند (مانند EUD). به تازگی کد منبع تعامل با EUD به صورت عمومی منتشر شده و امکان بهره‌برداری از این دسترسی بدون نیاز به باز کردن دستگاه و ابزارآلات خاص فراهم گردیده است.

سناریوهای سوءاستفاده عملی

۱. کسب دسترسی کامل سخت‌افزاری:

اگر EUD یا JTAG فعال باشد، مهاجم می‌تواند با اتصال به پورت USB، به رجیسترهای داخلی، حافظه و کنترل کامل پردازنده برسد. این دسترسی در خارج از کنترل سیستم‌عامل است و عملاً تمام لایه‌های امنیتی نرم‌افزاری را دور می‌زند.

تزریق بدافزار پایدار یا روت‌کیت:

مهاجم می‌تواند فریم‌ویر را تغییر داده، implant دائمی نصب کند یا حتی کل image دستگاه را dump و بررسی کند.

تهدید Supply Chain:

اگر تجهیزات سازمانی یا تجهیزات IoT با Debug Interface فعال وارد چرخه مصرف شوند، همان ابتدای زنجیره تامین ریسک implant فیزیکی و زدودن شفافیت امنیتی را ایجاد می‌کند.

پیشنهاد به تیم‌های امنیت

تجهیزات خود را ممیزی و وضعیت Debug Interfaceها را بررسی کنید.
در صورت عدم نیاز، اینترفیس‌های دیباگ را غیرفعال و فیوزهای امنیتی را فعال کنید.
به‌روزرسانی منظم فریم‌ویر را جدی بگیرید و تامین‌کنندگان سخت‌افزار را اعتبارسنجی نمایید.
امنیت سخت‌افزاری را جزو چک‌لیست‌های ارزیابی فنی و تست نفوذ قرار دهید.

نتیجه‌گیری

امنیت سخت‌افزاری سنگ‌بنای امنیت دیجیتال است و غفلت از پتانسیل سوءاستفاده از منافذ سخت‌افزاری می‌تواند تمامی لایه‌های منطقی دفاع را بی‌اثر کند. توجه مداوم به این لایه، رکن حیاتی امنیت سازمان‌های امروزی است.

#آکادمی_روزبه
مرکز تخصصی CISSP

آکادمی آموزش روزبه 📚

05 July 2025 12:47

“درب‌ پشتی” و “آسیب‌پذیری” در دستگاه‌های ذخیره‌سازی (Storage Devices)

در خصوص ذخیره سازها مثل SAN، NAS، اکسترنال هارد، و حتی درایوهای SSD و HDD آسیب پذیری از نگاه امنیت سایبری چند بُعد دارد. در ادامه به نکات عملی، تجربیات واقعی و تهدیدات شناخته‌شده می‌پردازم که برای یک SOC یا تیم امنیت می‌تواند ارزشمند باشد:
۱. درب‌ پشتی (Backdoor) در دستگاه‌های ذخیره‌سازی
الف. بک‌دورها در فریم‌ویر (Firmware Backdoors)
واقعیت: سازندگان، یا کمپانی‌های با سیاست ساخت ODM، گاهی عمداً یا سهواً دسترسی مخفی برای مدیریت، پشتیبانی یا مقاصد بدافزار (مانند Neutrality یا Cloud backend) باقی می‌گذارند.
نمونه واقعی:در سال ۲۰۱۴، شرکت Western Digital فریم‌ویری در برخی NAS ها داشت که درب‌پشتی آن، به ادمین اجازه Telnet دسترسی مخفی بدون لاگ را می‌داد.
ب. دستکاری‌ و آسیب‌پذیری در میکروکنترلر SSD/HDD
در BadUSB و ابزارهایی مثل HIDD (Hacker’s HDD backdoor): مهاجم فریم‌ویر SSD/HDD را با یک بیلد آلوده جایگزین کرده و مثلاً کانال ارتباطی C2 پنهان یا حافظه رمزنگاری‌شده جاسازی می‌کند.
یادداشت: کشف این نوع بک‌دورها با ابزارهای متداول بسیار دشوار است و فقط با تحلیل کم‌لایه و ابزارهای Forensics مخصوص قابل انجام است.
۲. آسیب‌پذیری‌های رایج (Vulnerabilities)
الف. Remote Code Execution و Web-based Backdoor
اکثر Storageهای تحت شبکه (مثل QNAP، Synology، WD My Cloud) وب‌سرور یا SMB دارند، اغلب آسیب‌پذیر به RCE یا login bypass بوده‌اند.
نمونه واقعی:در اوایل ۲۰۲۴ چند آسیب‌پذیری بحرانی QNAP و Synology (CVE-2024-21899 و CVE-2024-2879) به هکر اجازه می‌داد بدون اعتبارسنجی، دستورات سیستمی اجرا و حتی فایل‌ها را پاک یا رمزگذاری کند.
ب. آسیب‌پذیری‌هایی مثل SMB Ghost، EternalBlue یا WebDAV
بسیاری از NASها از ماژول‌های قدیمی Samba استفاده می‌کنند و به‌شدت در معرض آسیب‌پذیری‌های اساسی‌اند که حملات wormable را فعال می‌کنند.
ج. ضعف در احراز هویت و مدیریت دسترسی
ذخیره‌سازی پیش‌فرض با پسورد ساده/تکراری (admin/admin یا guest/guest)
فعال بودن FTP/Telnet بدون رمزنگاری
۳. تجربیات شکار و تحلیل در SOC
لاگ‌های Storage اغلب از لاگ مرکزی سرور جداست و به همین دلیل بک‌دور در شبکه کمتر آشکار می‌شود مگر با Network Threat Hunting روی پورت‌ها و پروتکل‌های معمول دستگاه‌های ذخیره‌سازی (مانند SMB، NFS، iSCSI).
سناریوی واقعی: در یک حمله باج‌افزاری به شبکه سازمانی، یک NAS قدیمی به سر پل انتقال اولیه باج‌افزار تبدیل شده بود چون تنها این دستگاه به‌علت firmware قدیمی و تنظیمات پیش‌فرض قربانی RCE شده بود.
تیم Hunting با تحلیل پکت‌های مشکوک روی پورت‌های ۴۴۵ و ۸۰ و مقایسه رفتار ترافیکی با الگوهای عادی، فعالیت بدافزار و حتی ایجاد کانال ارتباطی پنهان (C2) از طریق آن دستگاه را کشف کرد.
۴. اقدامات عملی و راهکارها
به‌روزرسانی مداوم فریم‌ویر و نظارت بر advisories شرکت سازنده
غیرفعال کردن سرویس‌های غیرضروری (FTP، Telnet، UPnP)
اجباری کردن MFA یا حداقل پسورد قوی، خصوصاً برای دسترسی مدیریت
یکپارچه‌سازی لاگ Storageها در SIEM
بررسی دوره‌ای دستگاه‌ها با ابزارهایی مثل Binwalk و firmware scanner برای شناسایی شِل یا بک‌دورهای مخفی


#آکادمی_روزبه
مرکز تخصصی CISSP


در دوره مدیریت بحران سایبری به این مقولات حاصل از تجربیات می‌پردازم
تماس با واتس اپ و بله 09902857290

آکادمی آموزش روزبه 📚

05 July 2025 07:10

نمونه ای از پلی بوک حملات

#آکادمی_روزبه
مرکز تخصصی CISSP

آکادمی آموزش روزبه 📚

04 July 2025 14:43

#تجربه
#بهسازی_SOC

اگر سیسمون رو بر اساس تنظیمات swiftonsecurity یا olafhartong انجام می‌دهید تا دقت خوب و کاهش حجم لاگ داشته باشید بدانید چه ریسک هایی رو ندید میگیرید!!

در این مقاله به اونها می‌پردازم

روزبه نوروزی


لیست حملاتی که با config مینیمال Sysmon ممکن است قابل کشف نباشند
۱. حملهLOTL (Living Off The Land) با ابزارهای بومی کمتر رایج

اجرای ابزارهایی مانند certutil.exe، mshta.exe، یا forfiles.exe اگر فقط روی powershell و cmd حساسیت باشد، معمولاً در مینیمال config اصلاً Log نمی‌شوند.

۲. برخی تکنیک‌های Fileless Malware

حملاتی که کد مخرب را مستقیماً در حافظه تزریق می‌کنند (مانند process hollowing یا reflectively loaded DLL)، اگر Log مربوط به Memory/Process creation دقیق شناسایی نشود (Event ID 8: CreateRemoteThread، Event ID 10: ProcessAccess).

۳. تغییرات مخفی در Registry

تغییر کلیدهای خاص (مثل Run، Image File Execution Options، یا کلیدهای less-known مانند AppInit_DLLs، UserInit) اغلب Log نمی‌شوند اگر فقط کلیدهای خاصی مانیتور شوند.

۴. انجام Network Lateral Movement

اگر فقط ترافیک غیر لوکال یا پورت‌های مشهور log شود، ترافیک غیرمعمول در داخل شبکه (مثلاً روی پورت 4444 یا WMI) از دست می‌رود (Event ID 3: Network Connection معمولاً حسابی فیلتر می‌شود).

۵. تغییرات پیشرفته در Scheduled Tasks

اگر config فقط schtasks.exe را log کند و نه فایل‌های XML یا عملیات از طریق API ویندوز، ساخت task با ابزارهای بومی در EventID 1 دیده نمی‌شود.

۶. تهدیدات مبتنی بر Named Pipe/IPC

همزادسازی دسترسی بین پردازش‌ها (Event ID 17/18: Pipe Created/Connected) در اکثر configها خاموش است، در نتیجه حملات IPC-Based قابل کشف نیستند.

۷. دور زدن با Parent-Child Spoofing

اگر ParentImage logging صرفاً محدود به پروسس‌های کلاسیک باشد، حملاتی با process injection یا hollowing که Parent غیرعادی‌ دارند، تشخیص داده نمی‌شوند.

۸. وجودPersistenceهای نامتعارف (WMI Event Consumer/Filter)

ایجاد WMI Permanent Event Subscription (Event ID 19, 20, 21) اغلب در configهای سبک logging نمی‌شوند.

۹. وExecution از طریق کمندهای جستجوگر ویندوز

اجرای مخرب از طریق Search-ms protocol، searchui.exe یا حتی explorer با argumentهای دقیق؛ اگر فقط روی powershell و cmd حساسیت باشد نادیده گرفته می‌شود.

۱۰. وDLL Sideloading و اجرای DLLهای نامعلوم

اگر FileCreate مربوط به فولدرهای مشکوک (مانند ProgramData یا TEMP) log نشود، این تکنیک‌ها مخفی می‌مانند.


#تجربه
#آکادمی_روزبه
مرکز تخصصی CISSP

آکادمی آموزش روزبه 📚

04 July 2025 09:27

در لینک زیر بدافزاری تحلیل شده است که آماده است که اگر با هوش مصنوعی و مدل‌های زبانی مورد تحلیل قرار گرفت با تکنیک prompt injection اونها رو دور بزند و برنامه تحلیل کننده آنها را سالم اعلام کند

#آکادمی_روزبه
مرکز تخصصی CISSP

https://research.checkpoint.com/2025/ai-evasion-prompt-injection/

آکادمی آموزش روزبه 📚

04 July 2025 07:10

https://www.cybertriage.com/blog/windows-registry-forensics-2025/