#موقت
🌀مداخلات روانشناسانه
برای افزایش بهره وری در SOC
شرکت هامون
✍تدوین: روزبه نوروزی با همیاری مشاور منابع انسانی شرکت هامون
فرسودگی شغلی (Burnout) در تیم‌های مرکز عملیات امنیت (SOC): یک بررسی روان‌شناختی
چکیده
فرسودگی شغلی (Burnout) یکی از پدیده‌های روان‌شناختی شایع در مشاغل پرتنش است که می‌تواند سلامت روانی و عملکرد حرفه‌ای افراد را تهدید کند. متخصصان مرکز عملیات امنیت (Security Operations Center - SOC)، که وظیفه پایش، تحلیل و پاسخ به تهدیدات سایبری را دارند، به دلیل ماهیت حساس، استرس‌زا و دائمی کار خود، در معرض سطوح بالایی از فرسودگی شغلی قرار می‌گیرند. این مقاله به بررسی عوامل روان‌شناختی مؤثر بر بروز Burnout در تیم‌های SOC، پیامدهای آن بر سلامت روان و بهره‌وری سازمانی، و راهکارهای مداخله‌ای می‌پردازد.
مقدمه
فرسودگی شغلی، مفهومی که نخستین‌بار توسط فرویدنبرگر (1974) مطرح شد، به‌عنوان یک واکنش روان‌شناختی به استرس مزمن شغلی تعریف می‌شود و شامل سه بعد اصلی است: خستگی هیجانی (Emotional Exhaustion)، مسخ شخصیت (Depersonalization) و کاهش احساس موفقیت فردی (Reduced Personal Accomplishment) (Maslach & Jackson, 1981).
در سال‌های اخیر، با افزایش حملات سایبری و پیچیدگی تهدیدات، فشار روانی بر متخصصان امنیت سایبری، به‌ویژه کارکنان SOC، افزایش یافته است. این تیم‌ها غالباً به‌صورت 24/7 در محیط‌هایی با ریسک بالا، حجم کاری سنگین و الزامات پاسخ سریع فعالیت می‌کنند که زمینه‌ساز فرسودگی شغلی است.
عوامل روان‌شناختی مؤثر بر Burnout در تیم‌های SOC
1. استرس شغلی مزمن:
کارکنان SOC به‌طور مداوم با حجم زیادی از هشدارهای امنیتی، تصمیم‌گیری‌های سریع و موقعیت‌های بحرانی مواجه‌اند. این شرایط، استرس شغلی را به‌صورت مزمن افزایش می‌دهد که مطابق با نظریه استرس لازاروس و فولکمن (1984)، اگر منابع مقابله‌ای ناکافی باشد، منجر به آسیب روانی می‌شود.
2. خستگی تصمیم‌گیری (Decision Fatigue):
موقعیت‌های پیچیده و مبهم در SOC، مستلزم تصمیم‌گیری‌های پی‌درپی است. خستگی تصمیم‌گیری به‌عنوان عامل فرسودگی روان‌شناختی و کاهش بهره‌وری در این محیط‌ها شناخته می‌شود.
3. کار شیفتی و اختلالات خواب:
مطالعات نشان داده‌اند که کار در شیفت‌های شبانه یا نامنظم با افزایش اختلالات خواب، کاهش کیفیت زندگی و افزایش ریسک افسردگی و اضطراب مرتبط است (Åkerstedt, 2003). این موضوع در تیم‌های SOC بسیار رایج است.
4. اثر تونل دید (Tunnel Vision) و تکرارپذیری بالا:
ماهیت کار تکراری، بررسی رویدادهای مشابه و نگاه محدود به تهدیدات می‌تواند باعث کاهش انگیزش درونی و احساس یکنواختی شود که از عوامل روان‌شناختی مهم در ایجاد Burnout است.
5. نبود بازخورد مثبت و قدردانی:
مطابق نظریه خودتعیینی (Deci & Ryan, 1985)، نیاز به شایستگی و قدردانی در محیط کار، نقش مهمی در سلامت روان ایفا می‌کند. در بسیاری از موارد، عملکرد تیم‌های SOC زمانی دیده می‌شود که شکست رخ دهد، نه زمانی که موفقیت در پیشگیری حاصل شده است.
پیامدهای روان‌شناختی و سازمانی Burnout در SOC
افزایش اضطراب، افسردگی و اختلالات روان‌تنی
افت کیفیت تصمیم‌گیری و افزایش خطاهای انسانی
کاهش رضایت شغلی و افزایش نرخ ترک خدمت (Turnover)
تضعیف کار تیمی و افزایش تعارضات بین‌فردی
تهدید مستقیم برای امنیت سایبری سازمان به‌دلیل کاهش بهره‌وری
رویکردهای روان‌شناختی برای پیشگیری و مداخله
1. مداخلات شناختی-رفتاری (CBT):
برگزاری کارگاه‌های CBT برای مدیریت استرس، افزایش تاب‌آوری روانی و اصلاح سبک‌های شناختی منفی در کارکنان.
2. بهینه‌سازی نظام شیفت‌بندی:
استفاده از اصول روان‌شناسی خواب برای طراحی شیفت‌های کاری که کمترین آسیب را به سلامت جسم و روان وارد کند.
3. ایجاد فرهنگ قدردانی و بازخورد مثبت:
پیاده‌سازی سیستم‌های انگیزشی بر اساس رویکردهای روان‌شناسی سازمانی برای افزایش احساس ارزشمندی و تعلق سازمانی.
4. آموزش مهارت‌های خودمراقبتی:
تقویت آگاهی کارکنان نسبت به اهمیت خواب، تغذیه سالم، فعالیت بدنی و مراقبت روانی فردی.
5. غربالگری و پایش سلامت روان:
استفاده از ابزارهای روان‌سنجی معتبر مانند پرسشنامه Maslach Burnout Inventory (MBI) برای شناسایی زودهنگام نشانه‌های فرسودگی و ارجاع به مداخلات تخصصی.
نتیجه‌گیری
فرسودگی شغلی در تیم‌های SOC یک پدیده چندعاملی با ابعاد روان‌شناختی عمیق است که پیامدهای فردی و سازمانی گسترده‌ای دارد. رویکردهای پیشگیرانه و مداخله‌ای مبتنی بر روان‌شناسی می‌توانند نقش مهمی در ارتقاء سلامت روان، افزایش بهره‌وری و کاهش ریسک‌های امنیتی ایفا کنند. توجه به این ابعاد برای سازمان‌های مدرن با زیرساخت‌های حیاتی، امری ضروری است.
💫شرکت پیشگامان فناوری اطلاعات هامون
Www.haumoun.com
🌀مداخلات روانشناسانه
برای افزایش بهره وری در SOC
شرکت هامون
✍تدوین: روزبه نوروزی با همیاری مشاور منابع انسانی شرکت هامون
فرسودگی شغلی (Burnout) در تیم‌های مرکز عملیات امنیت (SOC): یک بررسی روان‌شناختی
چکیده
فرسودگی شغلی (Burnout) یکی از پدیده‌های روان‌شناختی شایع در مشاغل پرتنش است که می‌تواند سلامت روانی و عملکرد حرفه‌ای افراد را تهدید کند. متخصصان مرکز عملیات امنیت (Security Operations Center - SOC)، که وظیفه پایش، تحلیل و پاسخ به تهدیدات سایبری را دارند، به دلیل ماهیت حساس، استرس‌زا و دائمی کار خود، در معرض سطوح بالایی از فرسودگی شغلی قرار می‌گیرند. این مقاله به بررسی عوامل روان‌شناختی مؤثر بر بروز Burnout در تیم‌های SOC، پیامدهای آن بر سلامت روان و بهره‌وری سازمانی، و راهکارهای مداخله‌ای می‌پردازد.
مقدمه
فرسودگی شغلی، مفهومی که نخستین‌بار توسط فرویدنبرگر (1974) مطرح شد، به‌عنوان یک واکنش روان‌شناختی به استرس مزمن شغلی تعریف می‌شود و شامل سه بعد اصلی است: خستگی هیجانی (Emotional Exhaustion)، مسخ شخصیت (Depersonalization) و کاهش احساس موفقیت فردی (Reduced Personal Accomplishment) (Maslach & Jackson, 1981).
در سال‌های اخیر، با افزایش حملات سایبری و پیچیدگی تهدیدات، فشار روانی بر متخصصان امنیت سایبری، به‌ویژه کارکنان SOC، افزایش یافته است. این تیم‌ها غالباً به‌صورت 24/7 در محیط‌هایی با ریسک بالا، حجم کاری سنگین و الزامات پاسخ سریع فعالیت می‌کنند که زمینه‌ساز فرسودگی شغلی است.
عوامل روان‌شناختی مؤثر بر Burnout در تیم‌های SOC
1. استرس شغلی مزمن:
کارکنان SOC به‌طور مداوم با حجم زیادی از هشدارهای امنیتی، تصمیم‌گیری‌های سریع و موقعیت‌های بحرانی مواجه‌اند. این شرایط، استرس شغلی را به‌صورت مزمن افزایش می‌دهد که مطابق با نظریه استرس لازاروس و فولکمن (1984)، اگر منابع مقابله‌ای ناکافی باشد، منجر به آسیب روانی می‌شود.
2. خستگی تصمیم‌گیری (Decision Fatigue):
موقعیت‌های پیچیده و مبهم در SOC، مستلزم تصمیم‌گیری‌های پی‌درپی است. خستگی تصمیم‌گیری به‌عنوان عامل فرسودگی روان‌شناختی و کاهش بهره‌وری در این محیط‌ها شناخته می‌شود.
3. کار شیفتی و اختلالات خواب:
مطالعات نشان داده‌اند که کار در شیفت‌های شبانه یا نامنظم با افزایش اختلالات خواب، کاهش کیفیت زندگی و افزایش ریسک افسردگی و اضطراب مرتبط است (Åkerstedt, 2003). این موضوع در تیم‌های SOC بسیار رایج است.
4. اثر تونل دید (Tunnel Vision) و تکرارپذیری بالا:
ماهیت کار تکراری، بررسی رویدادهای مشابه و نگاه محدود به تهدیدات می‌تواند باعث کاهش انگیزش درونی و احساس یکنواختی شود که از عوامل روان‌شناختی مهم در ایجاد Burnout است.
5. نبود بازخورد مثبت و قدردانی:
مطابق نظریه خودتعیینی (Deci & Ryan, 1985)، نیاز به شایستگی و قدردانی در محیط کار، نقش مهمی در سلامت روان ایفا می‌کند. در بسیاری از موارد، عملکرد تیم‌های SOC زمانی دیده می‌شود که شکست رخ دهد، نه زمانی که موفقیت در پیشگیری حاصل شده است.
پیامدهای روان‌شناختی و سازمانی Burnout در SOC
افزایش اضطراب، افسردگی و اختلالات روان‌تنی
افت کیفیت تصمیم‌گیری و افزایش خطاهای انسانی
کاهش رضایت شغلی و افزایش نرخ ترک خدمت (Turnover)
تضعیف کار تیمی و افزایش تعارضات بین‌فردی
تهدید مستقیم برای امنیت سایبری سازمان به‌دلیل کاهش بهره‌وری
رویکردهای روان‌شناختی برای پیشگیری و مداخله
1. مداخلات شناختی-رفتاری (CBT):
برگزاری کارگاه‌های CBT برای مدیریت استرس، افزایش تاب‌آوری روانی و اصلاح سبک‌های شناختی منفی در کارکنان.
2. بهینه‌سازی نظام شیفت‌بندی:
استفاده از اصول روان‌شناسی خواب برای طراحی شیفت‌های کاری که کمترین آسیب را به سلامت جسم و روان وارد کند.
3. ایجاد فرهنگ قدردانی و بازخورد مثبت:
پیاده‌سازی سیستم‌های انگیزشی بر اساس رویکردهای روان‌شناسی سازمانی برای افزایش احساس ارزشمندی و تعلق سازمانی.
4. آموزش مهارت‌های خودمراقبتی:
تقویت آگاهی کارکنان نسبت به اهمیت خواب، تغذیه سالم، فعالیت بدنی و مراقبت روانی فردی.
5. غربالگری و پایش سلامت روان:
استفاده از ابزارهای روان‌سنجی معتبر مانند پرسشنامه Maslach Burnout Inventory (MBI) برای شناسایی زودهنگام نشانه‌های فرسودگی و ارجاع به مداخلات تخصصی.
نتیجه‌گیری
فرسودگی شغلی در تیم‌های SOC یک پدیده چندعاملی با ابعاد روان‌شناختی عمیق است که پیامدهای فردی و سازمانی گسترده‌ای دارد. رویکردهای پیشگیرانه و مداخله‌ای مبتنی بر روان‌شناسی می‌توانند نقش مهمی در ارتقاء سلامت روان، افزایش بهره‌وری و کاهش ریسک‌های امنیتی ایفا کنند. توجه به این ابعاد برای سازمان‌های مدرن با زیرساخت‌های حیاتی، امری ضروری است.
💫شرکت پیشگامان فناوری اطلاعات هامون
Www.haumoun.com
❤10
اهمیت لاگ‌های کمتر شناخته‌شده ویندوز در کشف تهدید و تحلیل Forensic
روزبه نوروزی
بخش اول
مقدمه
یکی از مهم‌ترین مهارت‌های تحلیلگران امنیتی و تیم‌های SOC، توانایی به “درست دیدن” و “درست پرسیدن” سوال‌های جست‌وجو در داده‌های عظیم است. بخش عمده‌ای از این داده‌ها در اکوسیستم ویندوزی، مربوط به رویدادها و لاگ‌هایی است که سیستم‌عامل به طور مستمر در پس‌زمینه جمع‌آوری می‌کند. معمولاً قضاوت درباره ارزش این لاگ‌ها به سه دسته اصلی System، Application و Security خلاصه می‌شود؛ اما ویندوز فراتر از این سه، ده‌ها کانال و منبع دیگر برای لاگ‌نویسی دارد که عمدتاً دست‌نخورده و ناشناخته باقی می‌مانند—درحالی‌که همین لاگ‌های “کمتر شناخته‌شده” می‌توانند سرنوشت یک تحقیقات Forensic یا فرآیند شکار تهدید (Threat Hunting) را دگرگون کنند.
ساختار و تنوع لاگ‌های ویندوز
هر سیستم ویندوزی به‌طور متوسط شامل ده‌ها لاگ فعال است که در مسیرهای مختلف Event Viewer طبقه‌بندی شده‌اند. علاوه بر “سه گانه کلاسیک” (System, Application, Security)، انواع Operational و Diagnostic نیز وجود دارند که عموماً برای عیب‌یابی، توسعه نرم‌افزار، تحلیل عملکرد یا بررسی رویدادهای سیستمی خاص نوشته می‌شوند.
این لاگ‌ها دارای سطح دسترسی و پراکندگی متفاوتی‌اند؛ برخی فقط با سطح Administrator قابل مشاهده‌اند و برخی صرفاً در قالب لاگ ماشین (Machine-level) ذخیره می‌شوند. نکته کلیدی اینجاست که در بسیاری از سازمان‌ها به علت عدم آگاهی یا کم‌اهمیت فرض کردن این منابع، بررسی آنها نادیده گرفته شده و ریسک “دیدن تنها نوک کوه یخ فعالیت مهاجم” وجود دارد.
کمبود لاگ، طلای پنهان: چرا باید سراغ منابع غیراستاندارد رفت؟
در بسیاری از حملات، مهاجمین آگاهانه تلاش می‌کنند ردپای خود را در لاگ‌های اصلی پاک کنند، یا برای مدت کوتاهی حضور خود را مخفی نگه‌دارند. همچنین در محیط‌های عملیاتی و سیستم‌هایی که لاگ‌گیری کامل یا ابزارهای EDR پیشرفته ندارند—مثلاً شبکه‌های صنعتی قدیمی یا بخش‌هایی از نیم‌سازمان‌های دولتی—اتکا به منابع پیش‌فرض و افزونه نشده، اجتناب‌ناپذیر است.
در اینجاست که مرور و تحلیل Event Logهای فرعی مانند Shell-Core، AppModel-Runtime، TaskScheduler، VHDMP و غیره به عنوان «طلای پنهان» قابلیت استناد و اعتماد بالقوه را پیدا می‌کند.
پایان بخش اول
#آکادمی_روزبه
مرکز تخصصی CISSP
این مقاله ادامه دارد ....
روزبه نوروزی
بخش اول
مقدمه
یکی از مهم‌ترین مهارت‌های تحلیلگران امنیتی و تیم‌های SOC، توانایی به “درست دیدن” و “درست پرسیدن” سوال‌های جست‌وجو در داده‌های عظیم است. بخش عمده‌ای از این داده‌ها در اکوسیستم ویندوزی، مربوط به رویدادها و لاگ‌هایی است که سیستم‌عامل به طور مستمر در پس‌زمینه جمع‌آوری می‌کند. معمولاً قضاوت درباره ارزش این لاگ‌ها به سه دسته اصلی System، Application و Security خلاصه می‌شود؛ اما ویندوز فراتر از این سه، ده‌ها کانال و منبع دیگر برای لاگ‌نویسی دارد که عمدتاً دست‌نخورده و ناشناخته باقی می‌مانند—درحالی‌که همین لاگ‌های “کمتر شناخته‌شده” می‌توانند سرنوشت یک تحقیقات Forensic یا فرآیند شکار تهدید (Threat Hunting) را دگرگون کنند.
ساختار و تنوع لاگ‌های ویندوز
هر سیستم ویندوزی به‌طور متوسط شامل ده‌ها لاگ فعال است که در مسیرهای مختلف Event Viewer طبقه‌بندی شده‌اند. علاوه بر “سه گانه کلاسیک” (System, Application, Security)، انواع Operational و Diagnostic نیز وجود دارند که عموماً برای عیب‌یابی، توسعه نرم‌افزار، تحلیل عملکرد یا بررسی رویدادهای سیستمی خاص نوشته می‌شوند.
این لاگ‌ها دارای سطح دسترسی و پراکندگی متفاوتی‌اند؛ برخی فقط با سطح Administrator قابل مشاهده‌اند و برخی صرفاً در قالب لاگ ماشین (Machine-level) ذخیره می‌شوند. نکته کلیدی اینجاست که در بسیاری از سازمان‌ها به علت عدم آگاهی یا کم‌اهمیت فرض کردن این منابع، بررسی آنها نادیده گرفته شده و ریسک “دیدن تنها نوک کوه یخ فعالیت مهاجم” وجود دارد.
کمبود لاگ، طلای پنهان: چرا باید سراغ منابع غیراستاندارد رفت؟
در بسیاری از حملات، مهاجمین آگاهانه تلاش می‌کنند ردپای خود را در لاگ‌های اصلی پاک کنند، یا برای مدت کوتاهی حضور خود را مخفی نگه‌دارند. همچنین در محیط‌های عملیاتی و سیستم‌هایی که لاگ‌گیری کامل یا ابزارهای EDR پیشرفته ندارند—مثلاً شبکه‌های صنعتی قدیمی یا بخش‌هایی از نیم‌سازمان‌های دولتی—اتکا به منابع پیش‌فرض و افزونه نشده، اجتناب‌ناپذیر است.
در اینجاست که مرور و تحلیل Event Logهای فرعی مانند Shell-Core، AppModel-Runtime، TaskScheduler، VHDMP و غیره به عنوان «طلای پنهان» قابلیت استناد و اعتماد بالقوه را پیدا می‌کند.
پایان بخش اول
#آکادمی_روزبه
مرکز تخصصی CISSP
این مقاله ادامه دارد ....
❤4👏3⚡1
آکادمی آموزش روزبه 📚
اهمیت لاگ‌های کمتر شناخته‌شده ویندوز در کشف تهدید و تحلیل Forensic روزبه نوروزی بخش اول مقدمه یکی از مهم‌ترین مهارت‌های تحلیلگران امنیتی و تیم‌های SOC، توانایی به “درست دیدن” و “درست پرسیدن” سوال‌های جست‌وجو در داده‌های عظیم است. بخش عمده‌ای از این…
قسمت دوم از پست قبل
مثال‌های عملی: کاربرد لاگ‌های خاص در کشف تهدید
۱. Microsoft-Windows-Shell-Core/Operational
این کانال، به طور خاص رفتار پروسه‌هایی را جمع‌آوری می‌کند که با پایداری شروع به کار یا اجرا از مسیرهای حساس رجیستری (مانند Run یا RunOnce) دارند.
EID 9707:
این رویداد زمانی لاگ می‌شود که برنامه‌ای با استفاده از کلیدهای مذکور استارت می‌شود. در این لاگ، CommandLine کامل و اطلاعات اجرایی ثبت می‌شود؛ یک منبع بی‌نظیر برای شناسایی پایایی‌های ساده و رایج مانند Run Keys که مهاجمان برای باقی‌ماندن پس از ریبوت استفاده می‌کنند.
نمونه‌ی واقعی: مهاجمی که بدافزار خود را به CommandLine Run اضافه کند، حتی با پاکسازی سایر لاگ‌ها، این ایونت را در دیفالت‌ترین حالت خواهد داشت.
EID 9708:
خاتمه اجرای همان پروسه را با PID مربوط لاگ می‌کند. قابلیت “Correlation” با EID 9707 نه‌تنها طول عمر پروسه، بلکه بررسی آثار آن پس از اجرا را هم ممکن می‌کند.
EID 28115:
هر افزوده شدن شورتکات به App Resolver Cache را ارجاع می‌دهد—که معمولاً در نتیجه نصب برنامه‌ی جدید یا تکنیک‌های نصب سایلنت رخ می‌دهد. این event زمانی به‌کار می‌آید که رفتار غیرمنتظره نصب برنامه جدید را بدون دخالت کاربر می‌خواهیم کشف کنیم.
۲. Microsoft-Windows-WinINet-Config/ProxyConfigChanged
این منبع برای تمامی تغییرات در تنظیمات Proxy (سیستم یا مرورگر) دارای EID 5600 است.
اهمیت آن چیست؟
مهاجم برای پنهان‌کاری فعالیت، عبور ترافیک به سرور فرماندهی یا دور زدن فیلترینگ داخلی ممکن است پروکسی را تغییر دهد. چنین رویدادی، که معمولاً در لاگ‌گیری سنتی فایروال یا آنتی‌ویروس منعکس نمی‌شود، می‌تواند نقطه شروع تحلیل تفصیلی باشد.
استفاده عملی:
در پیگیری حمله، مشاهده چندین تغییر ProxyConfig بدون دلیل موجه یا همراه شدن با اجرای سیستم‌های ناشناس، قرینه بارزی از فعالیت C2 یا Exfiltration است.
۳. سایر منابع کارآمد برای SOC و Forensic
Microsoft-Windows-TaskScheduler/Operational
هرنوع اصلاح، حذف، فعال/غیرفعال کردن یا اجرای زمان‌بندی‌شده jobs را ثبت می‌کند. بسیار کاربردی برای کشف Techniques like Scheduled Task Persistence/T1053.
Microsoft-Windows-VHDMP-Operational
تمامی نصب (Mount) یا جداسازی (Unmount) دیسک‌های مجازی (VHD/VHDX) را با جزییات ثبت می‌کند. برخی بدافزارها یا مهاجمان برای مخفی کردن داده یا اجرای ابزار محافظت‌شده از این تکنیک بهره می‌برند.
Microsoft-Windows-AppModel-Runtime/Operational
رویدادهای مرتبط با اجرا، نصب، و به‌روزرسانی پکیج‌های برنامه‌های مدرن ویندوز (UWP/Store apps) را نگهداری می‌کند که در حملات مبتنی بر App Sideloading یا برنامه‌های خاص اهمیت دارد.
#آکادمی_روزبه
مرکز تخصصی CISSP
ادامه دارد ....
مثال‌های عملی: کاربرد لاگ‌های خاص در کشف تهدید
۱. Microsoft-Windows-Shell-Core/Operational
این کانال، به طور خاص رفتار پروسه‌هایی را جمع‌آوری می‌کند که با پایداری شروع به کار یا اجرا از مسیرهای حساس رجیستری (مانند Run یا RunOnce) دارند.
EID 9707:
این رویداد زمانی لاگ می‌شود که برنامه‌ای با استفاده از کلیدهای مذکور استارت می‌شود. در این لاگ، CommandLine کامل و اطلاعات اجرایی ثبت می‌شود؛ یک منبع بی‌نظیر برای شناسایی پایایی‌های ساده و رایج مانند Run Keys که مهاجمان برای باقی‌ماندن پس از ریبوت استفاده می‌کنند.
نمونه‌ی واقعی: مهاجمی که بدافزار خود را به CommandLine Run اضافه کند، حتی با پاکسازی سایر لاگ‌ها، این ایونت را در دیفالت‌ترین حالت خواهد داشت.
EID 9708:
خاتمه اجرای همان پروسه را با PID مربوط لاگ می‌کند. قابلیت “Correlation” با EID 9707 نه‌تنها طول عمر پروسه، بلکه بررسی آثار آن پس از اجرا را هم ممکن می‌کند.
EID 28115:
هر افزوده شدن شورتکات به App Resolver Cache را ارجاع می‌دهد—که معمولاً در نتیجه نصب برنامه‌ی جدید یا تکنیک‌های نصب سایلنت رخ می‌دهد. این event زمانی به‌کار می‌آید که رفتار غیرمنتظره نصب برنامه جدید را بدون دخالت کاربر می‌خواهیم کشف کنیم.
۲. Microsoft-Windows-WinINet-Config/ProxyConfigChanged
این منبع برای تمامی تغییرات در تنظیمات Proxy (سیستم یا مرورگر) دارای EID 5600 است.
اهمیت آن چیست؟
مهاجم برای پنهان‌کاری فعالیت، عبور ترافیک به سرور فرماندهی یا دور زدن فیلترینگ داخلی ممکن است پروکسی را تغییر دهد. چنین رویدادی، که معمولاً در لاگ‌گیری سنتی فایروال یا آنتی‌ویروس منعکس نمی‌شود، می‌تواند نقطه شروع تحلیل تفصیلی باشد.
استفاده عملی:
در پیگیری حمله، مشاهده چندین تغییر ProxyConfig بدون دلیل موجه یا همراه شدن با اجرای سیستم‌های ناشناس، قرینه بارزی از فعالیت C2 یا Exfiltration است.
۳. سایر منابع کارآمد برای SOC و Forensic
Microsoft-Windows-TaskScheduler/Operational
هرنوع اصلاح، حذف، فعال/غیرفعال کردن یا اجرای زمان‌بندی‌شده jobs را ثبت می‌کند. بسیار کاربردی برای کشف Techniques like Scheduled Task Persistence/T1053.
Microsoft-Windows-VHDMP-Operational
تمامی نصب (Mount) یا جداسازی (Unmount) دیسک‌های مجازی (VHD/VHDX) را با جزییات ثبت می‌کند. برخی بدافزارها یا مهاجمان برای مخفی کردن داده یا اجرای ابزار محافظت‌شده از این تکنیک بهره می‌برند.
Microsoft-Windows-AppModel-Runtime/Operational
رویدادهای مرتبط با اجرا، نصب، و به‌روزرسانی پکیج‌های برنامه‌های مدرن ویندوز (UWP/Store apps) را نگهداری می‌کند که در حملات مبتنی بر App Sideloading یا برنامه‌های خاص اهمیت دارد.
#آکادمی_روزبه
مرکز تخصصی CISSP
ادامه دارد ....
❤3🙏2
آکادمی آموزش روزبه 📚
قسمت دوم از پست قبل مثال‌های عملی: کاربرد لاگ‌های خاص در کشف تهدید ۱. Microsoft-Windows-Shell-Core/Operational این کانال، به طور خاص رفتار پروسه‌هایی را جمع‌آوری می‌کند که با پایداری شروع به کار یا اجرا از مسیرهای حساس رجیستری (مانند Run یا RunOnce) دارند.…
قسمت سوم از مقاله فوق
چالش‌ها و فرصت‌ها در تحلیل لاگ‌های فرعی
۱. حجم و پیچیدگی:
برخلاف System/Security که تقریباً همه با فرمت و ساختارشان آشنا هستند، لاگ‌های Operational دارای رویدادهای خاص و بعضاً مستندسازی ناقص‌اند. این مسأله فرآیند Query نویسی و Hunting را دشوار می‌کند و نیاز به دانش پیش‌زمینه یا تمرین عملی دارد.
۲. نبود ابزار تخصصی:
ابزارهایی مانند SIEMها یا EDRهای آماده عموماً Query و Detection پیش‌ساخته برای این منابع ندارند، پس تحلیلگر باید خود الگو و KQL/Splunk Query اختصاصی بنویسد.
۳. ارزش عملیاتی:
وقتی سیستم هدف تحت لاگ‌گیری مینیمال یا کانفیگ پیش‌فرض است، داشتن حتی یک سرنخ در این لاگ‌ها می‌تواند بازی را عوض کند. فضای فکری مهم: “دنبال چی بگردیم”، و “این لاگ خاص، سرنخ کدام رفتار مهاجم است؟”
توصیه‌های عملی برای بهره‌برداری بهتر در SOC/DFIR
۱. مطالعه، مستندسازی و جمع آوری لیست Event IDهای مهم هر لاگ فرعی. این داده را با فعال‌سازی lab یا ساخت سناریوهای Red Team/Blue Team توسعه بدهید.
۲. ایجاد Query و تقاطع زمانی میان این لاگ‌ها با لاگ‌های اصلی. مثلاً تطبیق WinINet Proxy Change با اجرای مشکوک، یا محاسبه gap بین EID 9707 و 9708 برای کشف اجرای بدافزار زمانبر.
۳. تهیه Alert Template سفارشی بر اساس Use Case سازمان؛ مثلاً لاگ Run/RunOnce فقط در سرور خاص اصلاً نباید رخ دهد، پس آن‌را Alert کنید.
۴. مطالعه لاگ‌های ناشناخته، تمرین تحلیل Event Raw و ساخت نمودار Correlation در کلاس، بدیهی است دانشجویان علاوه بر Detection Engineering، ذهنیت Forensic تفکیکی و کاربردی پیدا کنند.
۵. ساخت سناریو برای Incident Response که در آن فقط به این لاگ‌ها دسترسی دارند (Fail-Safe Labs) تا قدرت تحلیل عمیق در شرایط کمبود داده افزایش یابد.
#آکادمی_روزبه
مرکز تخصصی CISSP
چالش‌ها و فرصت‌ها در تحلیل لاگ‌های فرعی
۱. حجم و پیچیدگی:
برخلاف System/Security که تقریباً همه با فرمت و ساختارشان آشنا هستند، لاگ‌های Operational دارای رویدادهای خاص و بعضاً مستندسازی ناقص‌اند. این مسأله فرآیند Query نویسی و Hunting را دشوار می‌کند و نیاز به دانش پیش‌زمینه یا تمرین عملی دارد.
۲. نبود ابزار تخصصی:
ابزارهایی مانند SIEMها یا EDRهای آماده عموماً Query و Detection پیش‌ساخته برای این منابع ندارند، پس تحلیلگر باید خود الگو و KQL/Splunk Query اختصاصی بنویسد.
۳. ارزش عملیاتی:
وقتی سیستم هدف تحت لاگ‌گیری مینیمال یا کانفیگ پیش‌فرض است، داشتن حتی یک سرنخ در این لاگ‌ها می‌تواند بازی را عوض کند. فضای فکری مهم: “دنبال چی بگردیم”، و “این لاگ خاص، سرنخ کدام رفتار مهاجم است؟”
توصیه‌های عملی برای بهره‌برداری بهتر در SOC/DFIR
۱. مطالعه، مستندسازی و جمع آوری لیست Event IDهای مهم هر لاگ فرعی. این داده را با فعال‌سازی lab یا ساخت سناریوهای Red Team/Blue Team توسعه بدهید.
۲. ایجاد Query و تقاطع زمانی میان این لاگ‌ها با لاگ‌های اصلی. مثلاً تطبیق WinINet Proxy Change با اجرای مشکوک، یا محاسبه gap بین EID 9707 و 9708 برای کشف اجرای بدافزار زمانبر.
۳. تهیه Alert Template سفارشی بر اساس Use Case سازمان؛ مثلاً لاگ Run/RunOnce فقط در سرور خاص اصلاً نباید رخ دهد، پس آن‌را Alert کنید.
۴. مطالعه لاگ‌های ناشناخته، تمرین تحلیل Event Raw و ساخت نمودار Correlation در کلاس، بدیهی است دانشجویان علاوه بر Detection Engineering، ذهنیت Forensic تفکیکی و کاربردی پیدا کنند.
۵. ساخت سناریو برای Incident Response که در آن فقط به این لاگ‌ها دسترسی دارند (Fail-Safe Labs) تا قدرت تحلیل عمیق در شرایط کمبود داده افزایش یابد.
#آکادمی_روزبه
مرکز تخصصی CISSP
⚡3❤3
آکادمی آموزش روزبه 📚
قسمت سوم از مقاله فوق چالش‌ها و فرصت‌ها در تحلیل لاگ‌های فرعی ۱. حجم و پیچیدگی: برخلاف System/Security که تقریباً همه با فرمت و ساختارشان آشنا هستند، لاگ‌های Operational دارای رویدادهای خاص و بعضاً مستندسازی ناقص‌اند. این مسأله فرآیند Query نویسی و Hunting…
علاقمندان به SOC و هانت
میتونید برای رزرو دوره به واتس اپ زیر پیام بدین و پس از دوره سریع مشغول به کار شوید
واتس اپ 09902857290
میتونید برای رزرو دوره به واتس اپ زیر پیام بدین و پس از دوره سریع مشغول به کار شوید
واتس اپ 09902857290
❤4
آکادمی آموزش روزبه 📚
Cybersecurity roles and skills for NIS2.pdf
#موقت
فکر می‌کنید استاندارد ها برای گذاشتن در کتابخانه ها هستند ؟
استاندارد ها ؛ چراغ راهِ پیاده سازی آمال و آرزوهای ما در تحقق امنیت است .
نمی‌توان آرزویی داشت ولی طبق استاندارد عمل نکرد .
یکی از بزرگترین ریشه شکست های حفاظتی و نفوذ ، کارهای هر دمبیل !! (Ad hoc) و بدون نگاه به استاندارد است
فکر می‌کنید استاندارد ها برای گذاشتن در کتابخانه ها هستند ؟
استاندارد ها ؛ چراغ راهِ پیاده سازی آمال و آرزوهای ما در تحقق امنیت است .
نمی‌توان آرزویی داشت ولی طبق استاندارد عمل نکرد .
یکی از بزرگترین ریشه شکست های حفاظتی و نفوذ ، کارهای هر دمبیل !! (Ad hoc) و بدون نگاه به استاندارد است
❤3👍3👏2
تحول مدیریت امنیت با Policy/Change as Code
در عصر تحول دیجیتال و رشد سریع معماری‌های ابری و زیرساخت‌های نرم‌افزارمحور (SDN/SD-WAN)، اتکا به روش‌های سنتی مدیریت پالیسی و تغییر (Policy/Change Management) باعث افزایش ریسک خطاهای انسانی و حملات داخلی می‌شود. دو مفهوم کلیدی Policy as Code و Change as Code، مسیر مدیریت امنیت شبکه و اطلاعات را به‌طور بنیادین تغییر داده‌اند.
مساله Policy as Code (PaC) به معنای تعریف سیاست‌های دسترسی، امنیتی و اعتبارسنجی در قالب کد (مانند YAML, JSON یا DSL) است.
برخلاف گذشته که پالیسی‌ها در فایل‌های متنی یا Word ذخیره می‌شدند یا بر روی تجهیزات بصورت دستی تنظیم می‌گشتند، در این رویکرد سیاست‌ها بخشی از چرخه DevOps و GitOps می‌شوند: قابل نسخه‌بندی (version control)، تست خودکار (Automatic Validation) و مجاز بودن (Approval) پیش از اعمال در محیط اجرایی. ابزارهایی مانند Open Policy Agent (OPA)، HashiCorp Sentinel و Terraform بستری انعطاف‌پذیر جهت تعریف، بررسی و پیاده‌سازی این سیاست‌ها فراهم می‌کنند.
بحثChange as Code حتی یک قدم جلوتر است: هر گونه تغییر زیرساختی یا امنیتی – از تعویض یک قانون فایروال تا تغییر دسترسی کاربران – تنها از طریق commit به مخزن کد (Git) و طی مسیر بررسی، تست و approval انجام می‌شود (Pipeline-driven Change). این مدل، شفافیت (Audit)، ردیابی همه تغییرات (Traceability)، کاهش حملات داخلی و ساده‌سازی عملیات Rollback را به همراه دارد.
در مجموع، مهاجرت به PaC و Change as Code نه تنها امنیت را ارتقا می‌بخشد، بلکه توسعه پایدار، دسترس‌پذیر، و قابل مانیتورینگ زیرساخت را نیز تضمین می‌کند ـ یک الزام برای SOCهای مدرن و تیم‌های امنیتی آینده‌نگر
#آکادمی_روزبه
مرکز تخصصی CISSP
همیشه بخوان
در عصر تحول دیجیتال و رشد سریع معماری‌های ابری و زیرساخت‌های نرم‌افزارمحور (SDN/SD-WAN)، اتکا به روش‌های سنتی مدیریت پالیسی و تغییر (Policy/Change Management) باعث افزایش ریسک خطاهای انسانی و حملات داخلی می‌شود. دو مفهوم کلیدی Policy as Code و Change as Code، مسیر مدیریت امنیت شبکه و اطلاعات را به‌طور بنیادین تغییر داده‌اند.
مساله Policy as Code (PaC) به معنای تعریف سیاست‌های دسترسی، امنیتی و اعتبارسنجی در قالب کد (مانند YAML, JSON یا DSL) است.
برخلاف گذشته که پالیسی‌ها در فایل‌های متنی یا Word ذخیره می‌شدند یا بر روی تجهیزات بصورت دستی تنظیم می‌گشتند، در این رویکرد سیاست‌ها بخشی از چرخه DevOps و GitOps می‌شوند: قابل نسخه‌بندی (version control)، تست خودکار (Automatic Validation) و مجاز بودن (Approval) پیش از اعمال در محیط اجرایی. ابزارهایی مانند Open Policy Agent (OPA)، HashiCorp Sentinel و Terraform بستری انعطاف‌پذیر جهت تعریف، بررسی و پیاده‌سازی این سیاست‌ها فراهم می‌کنند.
بحثChange as Code حتی یک قدم جلوتر است: هر گونه تغییر زیرساختی یا امنیتی – از تعویض یک قانون فایروال تا تغییر دسترسی کاربران – تنها از طریق commit به مخزن کد (Git) و طی مسیر بررسی، تست و approval انجام می‌شود (Pipeline-driven Change). این مدل، شفافیت (Audit)، ردیابی همه تغییرات (Traceability)، کاهش حملات داخلی و ساده‌سازی عملیات Rollback را به همراه دارد.
در مجموع، مهاجرت به PaC و Change as Code نه تنها امنیت را ارتقا می‌بخشد، بلکه توسعه پایدار، دسترس‌پذیر، و قابل مانیتورینگ زیرساخت را نیز تضمین می‌کند ـ یک الزام برای SOCهای مدرن و تیم‌های امنیتی آینده‌نگر
#آکادمی_روزبه
مرکز تخصصی CISSP
همیشه بخوان
❤4🙏1
لاگ‌های SASL: سپر دفاعی SOC در برابر حملات Credential-based و BEC
در دنیای امروز که تهدیدات سایبری علیه زیرساخت‌های حیاتی و سرویس‌های ایمیل سازمانی رشد فزاینده‌ای داشته‌اند، اتکا به لاگ‌های authentication، به‌ویژه لاگ‌های SASL (Simple Authentication and Security Layer)، به یک ضرورت امنیتی بدل شده است. حملات مبتنی بر اعتبارنامه (Credential-based) شامل password spraying، credential stuffing و نهایتاً Business Email Compromise (BEC) در سال‌های اخیر موجب سرقت اطلاعات، نفوذ به ایمیل و خسارت‌های مالی چشمگیر شده‌اند.
این SASL به عنوان چارچوب احراز هویت استاندارد در پروتکل‌هایی مانند SMTP، IMAP و LDAP این قابلیت را ایجاد می‌کند که تمامی تلاش‌های موفق و ناموفق برای لاگین، همراه با مشخصاتی نظیر مکانیزم احراز هویت (PLAIN, LOGIN, NTLM…)، زمان، نام کاربری و IP در لاگ ثبت شوند. این لاگ‌ها با جمع‌آوری توسط پلتفرم‌هایی چون Splunk، قابلیت تحلیلی بی‌نظیری برای SOC فراهم می‌کنند؛ به‌گونه‌ای که می‌توان به آسانی سناریوهای حمله‌ای مانند:
تکرار تلاش‌های ناموفق بر روی یک حساب،
تلاش برای ورود با مکانیزم‌های ضعیف یا مشکوک،
تغییر ناگهانی الگوی احراز هویت کاربر،
تهاجم از یک IP مشکوک
را به سرعت شناسایی و با آستانه‌بندی (thresholding) مناسب، هشدار لحظه‌ای صادر کرد.
نکته مهم : در تعداد قابل توجهی از حملات موفق password spraying یا BEC روی سرویس‌هایی مانند O365، تحقیقات Incident Response نشان داده که سازمان‌هایی که SASL/SMTP logs نداشتند، اغلب ماه‌ها بعد و در زمانی که کاربر هدف به طور کامل compromise شده بود متوجه حادثه شدند، در حالی که آن دسته که SASL logging فعال داشته‌اند، حمله را در همان روز اول آشکار کرده‌اند.
در نتیجه، فعال‌سازی و مانیتورینگ هوشمند لاگ‌های SASL/SMTP نه‌فقط یک پیشنهاد فنی، که یک الزام حیاتی برای هر SOC مدرن محسوب می‌شود.
پی نوشت :مساله BEC نوعی حمله پیچیده و هدفمند است که مهاجم با نفوذ به حساب ایمیل سازمانی (یا جعل آن)، سعی می‌کند از طریق مهندسی اجتماعی، جعل مکاتبات یا ارسال دستور پرداخت، منابع مالی یا اطلاعات حساسی را سرقت کند.
#آکادمی_روزبه
مرکز تخصصی CISSP
در دنیای امروز که تهدیدات سایبری علیه زیرساخت‌های حیاتی و سرویس‌های ایمیل سازمانی رشد فزاینده‌ای داشته‌اند، اتکا به لاگ‌های authentication، به‌ویژه لاگ‌های SASL (Simple Authentication and Security Layer)، به یک ضرورت امنیتی بدل شده است. حملات مبتنی بر اعتبارنامه (Credential-based) شامل password spraying، credential stuffing و نهایتاً Business Email Compromise (BEC) در سال‌های اخیر موجب سرقت اطلاعات، نفوذ به ایمیل و خسارت‌های مالی چشمگیر شده‌اند.
این SASL به عنوان چارچوب احراز هویت استاندارد در پروتکل‌هایی مانند SMTP، IMAP و LDAP این قابلیت را ایجاد می‌کند که تمامی تلاش‌های موفق و ناموفق برای لاگین، همراه با مشخصاتی نظیر مکانیزم احراز هویت (PLAIN, LOGIN, NTLM…)، زمان، نام کاربری و IP در لاگ ثبت شوند. این لاگ‌ها با جمع‌آوری توسط پلتفرم‌هایی چون Splunk، قابلیت تحلیلی بی‌نظیری برای SOC فراهم می‌کنند؛ به‌گونه‌ای که می‌توان به آسانی سناریوهای حمله‌ای مانند:
تکرار تلاش‌های ناموفق بر روی یک حساب،
تلاش برای ورود با مکانیزم‌های ضعیف یا مشکوک،
تغییر ناگهانی الگوی احراز هویت کاربر،
تهاجم از یک IP مشکوک
را به سرعت شناسایی و با آستانه‌بندی (thresholding) مناسب، هشدار لحظه‌ای صادر کرد.
نکته مهم : در تعداد قابل توجهی از حملات موفق password spraying یا BEC روی سرویس‌هایی مانند O365، تحقیقات Incident Response نشان داده که سازمان‌هایی که SASL/SMTP logs نداشتند، اغلب ماه‌ها بعد و در زمانی که کاربر هدف به طور کامل compromise شده بود متوجه حادثه شدند، در حالی که آن دسته که SASL logging فعال داشته‌اند، حمله را در همان روز اول آشکار کرده‌اند.
در نتیجه، فعال‌سازی و مانیتورینگ هوشمند لاگ‌های SASL/SMTP نه‌فقط یک پیشنهاد فنی، که یک الزام حیاتی برای هر SOC مدرن محسوب می‌شود.
پی نوشت :مساله BEC نوعی حمله پیچیده و هدفمند است که مهاجم با نفوذ به حساب ایمیل سازمانی (یا جعل آن)، سعی می‌کند از طریق مهندسی اجتماعی، جعل مکاتبات یا ارسال دستور پرداخت، منابع مالی یا اطلاعات حساسی را سرقت کند.
#آکادمی_روزبه
مرکز تخصصی CISSP
👏3❤2
نقش DMARC در مدیریت بحران و روابط عمومی سازمان
(سند راهبردی برای SOC، IR و PR)
مقدمه
در دنیای امروز، حملات جعل ایمیل (Email Spoofing) و فیشینگ (Phishing) جزو تهدیدات اصلی برای اعتبار برند، اعتماد مشتریان و امنیت اطلاعات سازمانی به شمار می‌روند. در این میان، DMARC یکی از موثرترین ابزارهایی است که سازمان را قادر می‌سازد علاوه بر کاهش ریسک حملات، مدیریت بحران‌های رسانه‌ای و ارتباطی را نیز ارتقاء دهد.
چرا DMARC کلید طلایی مدیریت بحران است؟
۱. پیشگیری بهتر از درمان:
استقرار سیاست سختگیرانه DMARC (مانند quarantine یا reject)، باعث می‌شود مهاجمان نتوانند از دامین رسمی سازمان برای ارسال ایمیل‌های فیشینگ یا باج‌گیری علیه مشتریان یا پرسنل استفاده کنند. این موضوع، حجم بحران‌های ارتباطی ناشی از انتشار اخبار حمله یا نقض داده را به شدت کاهش می‌دهد.
۲. هشدار و شناسایی سریع حمله:
گزارش‌های Aggregated و Forensic DMARC به تیم امنیتی کمک می‌کند در لحظات آغازین وقوع حمله متوجه شوند چه کسی، از کجا و در چه حجمی در تلاش برای سوءاستفاده از دامنه بوده است—حتی قبل از وقوع آسیب جدی.
۳. اطلاع‌رسانی دقیق و هدفمند به ذینفعان:
در صورت وقوع حمله، با اتکا به داده‌های DMARC، می‌توان لیست دقیقی از سازمان‌ها یا کاربران هدف را استخراج و فرایند اطلاع‌رسانی (Notification) را به طور متمرکز، سریع و مطمئن انجام داد. این امر باعث می‌شود PR (روابط عمومی )بتواند روایت بحران را کنترل کند و از انتشار اخبار “غافل‌گیرانه” در رسانه‌ها پیشگیری شود.
۴. شفاف‌سازی و حفظ اعتماد پس از حادثه:
حتی اگر حمله‌ای موفق به جعل هویت شود، سازمان می‌تواند با استناد به سیاست و لاگ‌های DMARC، به صورت مستند به رسانه‌ها، قوانین یا مراجع پاسخ دهد و نشان دهد موضوع را کنترل و پیگیری کرده است. این شفافیت در روابط عمومی “اعتماد” مخاطبان را پس از بحران تقویت می‌کند.
سناریو:
تصور کنید در یک بانک، مهاجمان با جعل دامنه اقدام به ارسال ایمیل فیشینگ برای مشتریان می‌کنند و برخی رسانه‌ها خبر آن را منتشر می‌کنند:
اگر DMARC به صورت reject پیاده‌سازی شده باشد:اکثر ایمیل‌های فیشینگ هرگز به اینباکس مشتریان نمی‌رسد.
تیم امنیت از طریق گزارش‌های روزانه، بلافاصله متوجه موج حملات می‌شود و اطلاعات کلیدی (IP مهاجم، حجم ارسال، هدف‌ها) را برای مدیریت PR آماده می‌کند.
روابط عمومی سازمان می‌تواند بیانیه رسمی منتشر کند و ادله فنی ارائه دهد که عملاً ایمیل تقلبی به دست مشتری نرسیده است یا فقط معدود موارد با خطای پیکربندی گیرنده تحویل شده‌اند.
در صورت مطالبه قانون یا رسانه، مستندات تحلیلی DMARC آماده و شفاف‌سازی بدون تاخیر انجام می‌شود.
#آکادمی_روزبه
مرکز تخصصی CISSP
(سند راهبردی برای SOC، IR و PR)
مقدمه
در دنیای امروز، حملات جعل ایمیل (Email Spoofing) و فیشینگ (Phishing) جزو تهدیدات اصلی برای اعتبار برند، اعتماد مشتریان و امنیت اطلاعات سازمانی به شمار می‌روند. در این میان، DMARC یکی از موثرترین ابزارهایی است که سازمان را قادر می‌سازد علاوه بر کاهش ریسک حملات، مدیریت بحران‌های رسانه‌ای و ارتباطی را نیز ارتقاء دهد.
چرا DMARC کلید طلایی مدیریت بحران است؟
۱. پیشگیری بهتر از درمان:
استقرار سیاست سختگیرانه DMARC (مانند quarantine یا reject)، باعث می‌شود مهاجمان نتوانند از دامین رسمی سازمان برای ارسال ایمیل‌های فیشینگ یا باج‌گیری علیه مشتریان یا پرسنل استفاده کنند. این موضوع، حجم بحران‌های ارتباطی ناشی از انتشار اخبار حمله یا نقض داده را به شدت کاهش می‌دهد.
۲. هشدار و شناسایی سریع حمله:
گزارش‌های Aggregated و Forensic DMARC به تیم امنیتی کمک می‌کند در لحظات آغازین وقوع حمله متوجه شوند چه کسی، از کجا و در چه حجمی در تلاش برای سوءاستفاده از دامنه بوده است—حتی قبل از وقوع آسیب جدی.
۳. اطلاع‌رسانی دقیق و هدفمند به ذینفعان:
در صورت وقوع حمله، با اتکا به داده‌های DMARC، می‌توان لیست دقیقی از سازمان‌ها یا کاربران هدف را استخراج و فرایند اطلاع‌رسانی (Notification) را به طور متمرکز، سریع و مطمئن انجام داد. این امر باعث می‌شود PR (روابط عمومی )بتواند روایت بحران را کنترل کند و از انتشار اخبار “غافل‌گیرانه” در رسانه‌ها پیشگیری شود.
۴. شفاف‌سازی و حفظ اعتماد پس از حادثه:
حتی اگر حمله‌ای موفق به جعل هویت شود، سازمان می‌تواند با استناد به سیاست و لاگ‌های DMARC، به صورت مستند به رسانه‌ها، قوانین یا مراجع پاسخ دهد و نشان دهد موضوع را کنترل و پیگیری کرده است. این شفافیت در روابط عمومی “اعتماد” مخاطبان را پس از بحران تقویت می‌کند.
سناریو:
تصور کنید در یک بانک، مهاجمان با جعل دامنه اقدام به ارسال ایمیل فیشینگ برای مشتریان می‌کنند و برخی رسانه‌ها خبر آن را منتشر می‌کنند:
اگر DMARC به صورت reject پیاده‌سازی شده باشد:اکثر ایمیل‌های فیشینگ هرگز به اینباکس مشتریان نمی‌رسد.
تیم امنیت از طریق گزارش‌های روزانه، بلافاصله متوجه موج حملات می‌شود و اطلاعات کلیدی (IP مهاجم، حجم ارسال، هدف‌ها) را برای مدیریت PR آماده می‌کند.
روابط عمومی سازمان می‌تواند بیانیه رسمی منتشر کند و ادله فنی ارائه دهد که عملاً ایمیل تقلبی به دست مشتری نرسیده است یا فقط معدود موارد با خطای پیکربندی گیرنده تحویل شده‌اند.
در صورت مطالبه قانون یا رسانه، مستندات تحلیلی DMARC آماده و شفاف‌سازی بدون تاخیر انجام می‌شود.
#آکادمی_روزبه
مرکز تخصصی CISSP
👏4💯3
فورتی نت هم که باشی ....بازم ممکنه اصول امنیت رو رعایت نکنی :
هاردکد کردن کردنشیال !!
#آکادمی_روزبه
مرکز تخصصی CISSP
https://cybersecuritynews.com/fortinet-fortios-hard-coded-credentials-vulnerability/
هاردکد کردن کردنشیال !!
#آکادمی_روزبه
مرکز تخصصی CISSP
https://cybersecuritynews.com/fortinet-fortios-hard-coded-credentials-vulnerability/
Cyber Security News
CISA Warns of FortiOS Hard-Coded Credentials Vulnerability Exploited in Attacks
CISA added CVE-2019-6693 to its Known Exploited Vulnerabilities (KEV) catalog, indicating that this hard-coded credentials flaw is being actively exploited in real-world attacks.
❤2
تفاوت‌های فارنزیکی بین ویندوز 10 و ویندوز
بخش اول
ویندوز، توسط مایکروسافت توسعه یافته، از زمان اولین ارائه خود در سال 1985، ستون فقرات رایانش شخصی و حرفه‌ای بوده است.
تا مارس 2022، ویندوز با سهم بازار جهانی 75.7 درصد، پراستفاده‌ترین سیستم‌عامل جهان است. از بین این نصب‌ها، 74.82 درصد روی ویندوز 10 و 8.45 درصد به ویندوز 11 مهاجرت کرده‌اند. مایکروسافت گزارش می‌دهد که بیش از 1.4 میلیارد دستگاه در جهان از ویندوز 10 یا 11 استفاده می‌کنند (Microsoft, 2022a).
مایکروسافت قصد دارد حداقل یک نسخه از ویندوز 10 را تا 14 اکتبر 2025 پشتیبانی کند. با نزدیک شدن به پایان پشتیبانی از ویندوز 10، انتظار می‌رود استفاده از ویندوز 11 به شکل قابل توجهی رشد کند. این تغییر، اهمیت درک تفاوت‌ها و شباهت‌های این دو سیستم‌عامل را برای کارشناسان فارنزیک دیجیتال، به ویژه از نظر آرتیفکت‌ها و قابلیت‌های امنیتی، افزایش می‌دهد.
مطلب خوبی از Andrew Rathbun نوشته شده است که می‌توانید آن را هم مطالعه کنید:
https://www.sans.org/white-papers/windows-10-vs-windows-11-what-has-changed/
آرتیفکت‌های فارنزیکی
این بخش بررسی می‌کند که آیا آرتیفکت‌های کلیدی ویندوز 10 در ویندوز 11 نیز حضور دارند و تفاوت‌های فارنزیکی احتمالی چیست. تحلیلی از آرتیفکت‌های برجسته را در ادامه می‌بینید:
فایل های LNK و Jump Lists
فرمت فایل باینری Shell Link (.LNK) در ژوئن 2021 بازنگری شد، اما هیچ تغییر قابل توجه فارنزیکی شناسایی نشده است. به همین صورت، Jump Listها، که مجموعه‌ای از فایل‌های .LNK مرتبط با برنامه‌ها هستند، میان ویندوز 10 و 11 تغییری نکرده‌اند.
فایل‌های متادیتای $Recycle_Bin
فایل‌های متادیتا در Recycle Bin ($I30) هیچ تفاوت چشمگیری میان ویندوز 10 و 11 نشان نمی‌دهند.
Amcache
آرتیفکت Amcache در هر دو ویندوز 10 و 11 یکسان است.
رجیستری هیوها (Registry Hives)
رجیستری هیوها در ویندوز 11 تغییرات قابل توجهی دارند؛ بیش از 35 هزار کلید جدید یا تغییر یافته وجود دارد. این تغییرات عمدتاً مربوط به قابلیت‌های امنیتی جدید و پشتیبانی از سخت‌افزار و تنظیمات رابط کاربری است.
برای کارشناسان فارنزیک و تحلیلگران امنیتی، بررسی این تغییرات ضروری است، چرا که ممکن است ردپای پایداری (Persistence)، اجرای مخرب، یا تنظیمات مخفی در این موقعیت‌ها شکل گیرد.
Prefetch
فرمت و مکان Prefetch مشابه ویندوز 10 باقی مانده، اما با توجه به فعال بودن ماژول‌های امنیتی مانند TPM و Secure Boot، در برخی دستگاه‌ها Prefetch به طور پیش فرض غیرفعال است.
#آکادمی_روزبه
مرکز تخصصی CISSP
ادامه دارد ...
بخش اول
ویندوز، توسط مایکروسافت توسعه یافته، از زمان اولین ارائه خود در سال 1985، ستون فقرات رایانش شخصی و حرفه‌ای بوده است.
تا مارس 2022، ویندوز با سهم بازار جهانی 75.7 درصد، پراستفاده‌ترین سیستم‌عامل جهان است. از بین این نصب‌ها، 74.82 درصد روی ویندوز 10 و 8.45 درصد به ویندوز 11 مهاجرت کرده‌اند. مایکروسافت گزارش می‌دهد که بیش از 1.4 میلیارد دستگاه در جهان از ویندوز 10 یا 11 استفاده می‌کنند (Microsoft, 2022a).
مایکروسافت قصد دارد حداقل یک نسخه از ویندوز 10 را تا 14 اکتبر 2025 پشتیبانی کند. با نزدیک شدن به پایان پشتیبانی از ویندوز 10، انتظار می‌رود استفاده از ویندوز 11 به شکل قابل توجهی رشد کند. این تغییر، اهمیت درک تفاوت‌ها و شباهت‌های این دو سیستم‌عامل را برای کارشناسان فارنزیک دیجیتال، به ویژه از نظر آرتیفکت‌ها و قابلیت‌های امنیتی، افزایش می‌دهد.
مطلب خوبی از Andrew Rathbun نوشته شده است که می‌توانید آن را هم مطالعه کنید:
https://www.sans.org/white-papers/windows-10-vs-windows-11-what-has-changed/
آرتیفکت‌های فارنزیکی
این بخش بررسی می‌کند که آیا آرتیفکت‌های کلیدی ویندوز 10 در ویندوز 11 نیز حضور دارند و تفاوت‌های فارنزیکی احتمالی چیست. تحلیلی از آرتیفکت‌های برجسته را در ادامه می‌بینید:
فایل های LNK و Jump Lists
فرمت فایل باینری Shell Link (.LNK) در ژوئن 2021 بازنگری شد، اما هیچ تغییر قابل توجه فارنزیکی شناسایی نشده است. به همین صورت، Jump Listها، که مجموعه‌ای از فایل‌های .LNK مرتبط با برنامه‌ها هستند، میان ویندوز 10 و 11 تغییری نکرده‌اند.
فایل‌های متادیتای $Recycle_Bin
فایل‌های متادیتا در Recycle Bin ($I30) هیچ تفاوت چشمگیری میان ویندوز 10 و 11 نشان نمی‌دهند.
Amcache
آرتیفکت Amcache در هر دو ویندوز 10 و 11 یکسان است.
رجیستری هیوها (Registry Hives)
رجیستری هیوها در ویندوز 11 تغییرات قابل توجهی دارند؛ بیش از 35 هزار کلید جدید یا تغییر یافته وجود دارد. این تغییرات عمدتاً مربوط به قابلیت‌های امنیتی جدید و پشتیبانی از سخت‌افزار و تنظیمات رابط کاربری است.
برای کارشناسان فارنزیک و تحلیلگران امنیتی، بررسی این تغییرات ضروری است، چرا که ممکن است ردپای پایداری (Persistence)، اجرای مخرب، یا تنظیمات مخفی در این موقعیت‌ها شکل گیرد.
Prefetch
فرمت و مکان Prefetch مشابه ویندوز 10 باقی مانده، اما با توجه به فعال بودن ماژول‌های امنیتی مانند TPM و Secure Boot، در برخی دستگاه‌ها Prefetch به طور پیش فرض غیرفعال است.
#آکادمی_روزبه
مرکز تخصصی CISSP
ادامه دارد ...
www.sans.org
Windows 10 vs. Windows 11, What Has Changed? | SANS Institute
Windows 10 was released on July 29, 2015. It has since become the most installed desktop operating system. More recently, Windows 11 was released to the general public on October 5, 2021, which served as an evolution of Windows 10. At the time of publication…
❤5
آکادمی آموزش روزبه 📚
تفاوت‌های فارنزیکی بین ویندوز 10 و ویندوز بخش اول ویندوز، توسط مایکروسافت توسعه یافته، از زمان اولین ارائه خود در سال 1985، ستون فقرات رایانش شخصی و حرفه‌ای بوده است. تا مارس 2022، ویندوز با سهم بازار جهانی 75.7 درصد، پراستفاده‌ترین سیستم‌عامل جهان است.…
بخش دوم
Windows Timeline
آرتیفکت‌های Timeline در ویندوز 11 (مثل ActivitiesCache.db) حذف یا غیرفعال شده‌اند، که بازیابی تاریخچه فعالیت کاربر را دشوارتر می‌کند.
Event Logs
ساختار کلی Event Logها حفظ شده، اما EventIDها و کانال‌های جدیدی که مرتبط با امنیت، مدیریت و ویژگی‌های جدید ویندوز هستند، اضافه شده‌اند—به ویژه برای پشتیبانی از TPM، Secure Boot و Virtualization-Based Security (VBS).
ردیابی فرایندها (Process Tracking - Sysmon و ETW)
ابزارها و سرویس‌هایی مانند Sysmon و ETW همچنان برای مانیتورینگ دقیق رفتار فرآیندها مورد استفاده قرار می‌گیرند. در ویندوز 11، سیستم لاگ‌دهی بهبود یافته است و برخی کانال‌های جدید را نمی‌توان غیر فعال کرد.
حافظه (Memory) و Pagefile/SWAP
در ویندوز 11 به دلیل پیش‌فرض شدن برخی قابلیت‌های امنیتی مبتنی بر مجازی‌سازی (VBS)، بخش‌هایی از حافظه ممکن است رمزگذاری یا غیرقابل دسترس شود که استخراج برخی آرتیفکت‌های معمول حافظه را محدود می‌کند.
قابلیت‌های جدید امنیتی
و TPM 2.0 و Secure Boot:در بسیاری از دستگاه‌ها، برای نصب ویندوز 11 اجرا الزامی است.
و VBS و HVCI:امنیت مبتنی بر مجازی‌سازی و بررسی صحت در سطح کرنل، امکان بسیاری از حملات کلاسیک و بعضاً استخراج فارنزیک قدیمی را کاهش داده یا غیرممکن می‌سازد.
جمع‌بندی
بیشتر آرتیفکت‌های کلیدی میان نسخه‌های 10 و 11 یکسان باقی مانده‌اند؛ اما رجیستری و قابلیت‌های امنیت سخت‌افزاری تغییر چشمگیر داشته و نیازمند به‌روزرسانی دانش و ابزارهای تخصصی است.
مرور مستندات رسمی، تست ابزارها روی نسخه‌های جدید و مطالعه مراجع تخصصی مثل SANS Whitepaper و سایت‌های فارنزیک توصیه می‌شود.
#آکادمی_روزبه
مرکز تخصصی CISSP
Windows Timeline
آرتیفکت‌های Timeline در ویندوز 11 (مثل ActivitiesCache.db) حذف یا غیرفعال شده‌اند، که بازیابی تاریخچه فعالیت کاربر را دشوارتر می‌کند.
Event Logs
ساختار کلی Event Logها حفظ شده، اما EventIDها و کانال‌های جدیدی که مرتبط با امنیت، مدیریت و ویژگی‌های جدید ویندوز هستند، اضافه شده‌اند—به ویژه برای پشتیبانی از TPM، Secure Boot و Virtualization-Based Security (VBS).
ردیابی فرایندها (Process Tracking - Sysmon و ETW)
ابزارها و سرویس‌هایی مانند Sysmon و ETW همچنان برای مانیتورینگ دقیق رفتار فرآیندها مورد استفاده قرار می‌گیرند. در ویندوز 11، سیستم لاگ‌دهی بهبود یافته است و برخی کانال‌های جدید را نمی‌توان غیر فعال کرد.
حافظه (Memory) و Pagefile/SWAP
در ویندوز 11 به دلیل پیش‌فرض شدن برخی قابلیت‌های امنیتی مبتنی بر مجازی‌سازی (VBS)، بخش‌هایی از حافظه ممکن است رمزگذاری یا غیرقابل دسترس شود که استخراج برخی آرتیفکت‌های معمول حافظه را محدود می‌کند.
قابلیت‌های جدید امنیتی
و TPM 2.0 و Secure Boot:در بسیاری از دستگاه‌ها، برای نصب ویندوز 11 اجرا الزامی است.
و VBS و HVCI:امنیت مبتنی بر مجازی‌سازی و بررسی صحت در سطح کرنل، امکان بسیاری از حملات کلاسیک و بعضاً استخراج فارنزیک قدیمی را کاهش داده یا غیرممکن می‌سازد.
جمع‌بندی
بیشتر آرتیفکت‌های کلیدی میان نسخه‌های 10 و 11 یکسان باقی مانده‌اند؛ اما رجیستری و قابلیت‌های امنیت سخت‌افزاری تغییر چشمگیر داشته و نیازمند به‌روزرسانی دانش و ابزارهای تخصصی است.
مرور مستندات رسمی، تست ابزارها روی نسخه‌های جدید و مطالعه مراجع تخصصی مثل SANS Whitepaper و سایت‌های فارنزیک توصیه می‌شود.
#آکادمی_روزبه
مرکز تخصصی CISSP
👏4❤3
تأثیر Virtualization-Based Security (VBS) ویندوز ۱۱ بر فارنزیک حافظه: چالش‌ها و راهکارها
مقدمه
با مهاجرت تدریجی سازمان‌ها و کاربران نهایی به ویندوز ۱۱، شاهد دگرگونی جدی در لایه‌های امنیتی این سیستم‌عامل، به‌ویژه در حوزه حفاظت از حافظه RAM هستیم. مهم‌ترین عامل این تغییر، فناوری امنیتی مبتنی بر مجازی‌سازی (Virtualization-Based Security – VBS) است؛ قابلیتی که به‌صورت پیش‌فرض در بسیاری از سیستم‌های جدید ویندوز ۱۱ فعال است و رفتار جرم‌شناسانه با حافظه را به‌کلی مختل می‌کند. در این مقاله، مروری تحلیلی بر این تغییر و راهکارهای عملیاتی برای مقابله با محدودیت‌های فارنزیک حافظه در ویندوز ۱۱ خواهیم داشت.
مقوله VBS و HVCI چیست و چگونه عمل می‌کنند؟
Virtualization-Based Security (VBS)
با VBS با بهره‌گیری از سخت‌افزار مجازی‌سازی (مثلاً Hyper-V یا AMD-V/Intel VT-x)، فضایی ایزوله به نام Virtual Trust Level (VTL1) در حافظه ایجاد می‌کند که کاملاً از فضای حافظه اصلی (VTL0) جداست. داده‌های حیاتی امنیتی (مانند رمزها، هویت‌ها، برخی ساختارهای کرنل) به این بخش منتقل شده و دسترسی پردازه‌های عادی یا حتی بسیاری ابزارهای تخصصی فارنزیک به این قسمت مسدود می‌شود.
Hypervisor-Protected Code Integrity (HVCI)
اینHVCI زیرمجموعه VBS است و صحت یکپارچگی کدهای کرنل را تضمین کرده و مانع اجرای کد مخرب در حافظه کرنل می‌شود.
مشکل جدید: محدودیت شدید فارنزیک حافظه در ویندوز ۱۱
چالش‌های اصلی
غیرقابل دسترس‌شدن یا رمزنگاری بخش‌های کلیدی حافظه RAM
عدم امکان استخراج رمزهای عبور، هش‌ها، Kerberos TGT، و بسیاری داده‌های زنده مرتبط با سشن‌های امنیتی.
حافظه پردازه‌هایی نظیر LSASS، Credential Guard و برخی بخش‌های کرنل به Hypervisor ایزوله شده و دیگر ابزارهایی مانند Mimikatz، Procdump یا حتی بسیاری Memory Imagerها نمی‌توانند آنها را به‌طور کامل Dump یا تحلیل کنند.
ابزارهای کلاسیک Memory Forensics ناکارآمد می‌شوند
حتی با دسترسی SYSTEM یا سطح کرنل، برداشتن رم یا Analyzing Dump، عملاً Artifactها یا غایب هستند یا رمز شده‌اند.
این امر بررسی سناریوهایی همچون استخراج داده‌های سرقتی، تحلیل Rootkit، بررسی حملات Fileless Malware یا احراز صحت امنیتی سیستم را با مشکل روبرو می‌کند.
اثرات در تیم‌های Incident Response و SOC
کاهش توانایی شناسایی نفوذگر، Root Cause، کشف تکنیک‌های Living-off-the-Land و حتی بازسازی وقایع امنیتی بر اساس حافظه.
افزایش اتکا به Artifactهای دیسک، رجیستری و رویداد‌لاگ‌ها (در حالی که بسیاری شواهد حساس فقط در حافظه زنده نگهداری می‌شوند).
راهکارها و توصیه‌های عملیاتی
۱. شناسایی تنظیمات امنیتی پیش از Memory Acquisition
قبل از هرگونه عملیات Memory Dump یا Incident Handling روی سیستم‌های ویندوز ۱۱، تنظیمات VBS/HVCI و Credential Guard را بررسی و ثبت کنید.
بهترین روش:
اجرای
msinfo32.exe
در بخش “Device Security” نگاه کنید آیا Virtualization-based Security فعال است یا خیر.
۲. استفاده از ابزارهای به‌روز و سازگار با Windows 11
ابزارهایی مانند Magnet RAM Capture v2.x، Belkasoft RAM Capturer نسخه‌های جدید و Volatility نسخه ۳ به بعد، برخی سطوح تعامل با ساختارهای جدید حافظه را دارند ولی هنوز کاملاً Bulletproof نیستند.
برای محیط‌های مجازی، Snapshot گرفتن در سطح Hypervisor (مثلاً VMware, Hyper-V) راهکاری است که می‌تواند بعضی دسترسی‌ها را ممکن سازد.
۳. تغییر رویکرد: تمرکز بر Artifactهای غیر حافظه (Disk/Registry/Logs)
تحلیل رجیستری (NTUSER.DAT/SAM/SECURITY/SYSTEM)، رکوردهای لاگ‌ها (Event Log, ETW, Sysmon)، و جدول‌های دیتابیس (مانند Amcache, SRUM, LNK, JumpList, Shellbags و …) اهمیت بیشتری پیدا کرده است.
تحلیل شبکه، بررسی اثرات عملیات مشکوک و آثار جانبی مهاجمان در هارد (Persistence, گیاوه‌های باقی‌مانده، آثار تغییر فایل‌ها و…) را جایگزین تحلیل مستقیم RAM کنید.
۴. آموزش تیم‌ها و به‌روزرسانی دانش
انتقال دانش به تیم‌های SOC و IR درباره محدودیت‌های Memory Forensics روی سیستم‌های VBS/HVCI-enabled و آموزاندن تکنیک‌های جایگزین استخراج شواهد.
استفاده از تمرین‌های عملی با Sampleهایی که این حالت فعال است—تا بتوان ضعف‌های قدیمی و نقاط قوت رویکردهای جدید را لمس کرد.
۵. تماس با تامین‌کنندگان ابزار و رصد مستمر آپدیت‌های تخصصی
توصیه می‌شود تیم‌های امنیتی عضو mailing listها، خبرنامه‌ها و مستندات بازار (مثلاً SANS، Magnet Forensics Blog، CrowdStrike و غیره) باشند تا با هر آپدیت ابزارها و تاکتیک‌های جدید آشنا بمانند
#آکادمی_روزبه
مرکز تخصصی CISSP
مقدمه
با مهاجرت تدریجی سازمان‌ها و کاربران نهایی به ویندوز ۱۱، شاهد دگرگونی جدی در لایه‌های امنیتی این سیستم‌عامل، به‌ویژه در حوزه حفاظت از حافظه RAM هستیم. مهم‌ترین عامل این تغییر، فناوری امنیتی مبتنی بر مجازی‌سازی (Virtualization-Based Security – VBS) است؛ قابلیتی که به‌صورت پیش‌فرض در بسیاری از سیستم‌های جدید ویندوز ۱۱ فعال است و رفتار جرم‌شناسانه با حافظه را به‌کلی مختل می‌کند. در این مقاله، مروری تحلیلی بر این تغییر و راهکارهای عملیاتی برای مقابله با محدودیت‌های فارنزیک حافظه در ویندوز ۱۱ خواهیم داشت.
مقوله VBS و HVCI چیست و چگونه عمل می‌کنند؟
Virtualization-Based Security (VBS)
با VBS با بهره‌گیری از سخت‌افزار مجازی‌سازی (مثلاً Hyper-V یا AMD-V/Intel VT-x)، فضایی ایزوله به نام Virtual Trust Level (VTL1) در حافظه ایجاد می‌کند که کاملاً از فضای حافظه اصلی (VTL0) جداست. داده‌های حیاتی امنیتی (مانند رمزها، هویت‌ها، برخی ساختارهای کرنل) به این بخش منتقل شده و دسترسی پردازه‌های عادی یا حتی بسیاری ابزارهای تخصصی فارنزیک به این قسمت مسدود می‌شود.
Hypervisor-Protected Code Integrity (HVCI)
اینHVCI زیرمجموعه VBS است و صحت یکپارچگی کدهای کرنل را تضمین کرده و مانع اجرای کد مخرب در حافظه کرنل می‌شود.
مشکل جدید: محدودیت شدید فارنزیک حافظه در ویندوز ۱۱
چالش‌های اصلی
غیرقابل دسترس‌شدن یا رمزنگاری بخش‌های کلیدی حافظه RAM
عدم امکان استخراج رمزهای عبور، هش‌ها، Kerberos TGT، و بسیاری داده‌های زنده مرتبط با سشن‌های امنیتی.
حافظه پردازه‌هایی نظیر LSASS، Credential Guard و برخی بخش‌های کرنل به Hypervisor ایزوله شده و دیگر ابزارهایی مانند Mimikatz، Procdump یا حتی بسیاری Memory Imagerها نمی‌توانند آنها را به‌طور کامل Dump یا تحلیل کنند.
ابزارهای کلاسیک Memory Forensics ناکارآمد می‌شوند
حتی با دسترسی SYSTEM یا سطح کرنل، برداشتن رم یا Analyzing Dump، عملاً Artifactها یا غایب هستند یا رمز شده‌اند.
این امر بررسی سناریوهایی همچون استخراج داده‌های سرقتی، تحلیل Rootkit، بررسی حملات Fileless Malware یا احراز صحت امنیتی سیستم را با مشکل روبرو می‌کند.
اثرات در تیم‌های Incident Response و SOC
کاهش توانایی شناسایی نفوذگر، Root Cause، کشف تکنیک‌های Living-off-the-Land و حتی بازسازی وقایع امنیتی بر اساس حافظه.
افزایش اتکا به Artifactهای دیسک، رجیستری و رویداد‌لاگ‌ها (در حالی که بسیاری شواهد حساس فقط در حافظه زنده نگهداری می‌شوند).
راهکارها و توصیه‌های عملیاتی
۱. شناسایی تنظیمات امنیتی پیش از Memory Acquisition
قبل از هرگونه عملیات Memory Dump یا Incident Handling روی سیستم‌های ویندوز ۱۱، تنظیمات VBS/HVCI و Credential Guard را بررسی و ثبت کنید.
بهترین روش:
اجرای
msinfo32.exe
در بخش “Device Security” نگاه کنید آیا Virtualization-based Security فعال است یا خیر.
۲. استفاده از ابزارهای به‌روز و سازگار با Windows 11
ابزارهایی مانند Magnet RAM Capture v2.x، Belkasoft RAM Capturer نسخه‌های جدید و Volatility نسخه ۳ به بعد، برخی سطوح تعامل با ساختارهای جدید حافظه را دارند ولی هنوز کاملاً Bulletproof نیستند.
برای محیط‌های مجازی، Snapshot گرفتن در سطح Hypervisor (مثلاً VMware, Hyper-V) راهکاری است که می‌تواند بعضی دسترسی‌ها را ممکن سازد.
۳. تغییر رویکرد: تمرکز بر Artifactهای غیر حافظه (Disk/Registry/Logs)
تحلیل رجیستری (NTUSER.DAT/SAM/SECURITY/SYSTEM)، رکوردهای لاگ‌ها (Event Log, ETW, Sysmon)، و جدول‌های دیتابیس (مانند Amcache, SRUM, LNK, JumpList, Shellbags و …) اهمیت بیشتری پیدا کرده است.
تحلیل شبکه، بررسی اثرات عملیات مشکوک و آثار جانبی مهاجمان در هارد (Persistence, گیاوه‌های باقی‌مانده، آثار تغییر فایل‌ها و…) را جایگزین تحلیل مستقیم RAM کنید.
۴. آموزش تیم‌ها و به‌روزرسانی دانش
انتقال دانش به تیم‌های SOC و IR درباره محدودیت‌های Memory Forensics روی سیستم‌های VBS/HVCI-enabled و آموزاندن تکنیک‌های جایگزین استخراج شواهد.
استفاده از تمرین‌های عملی با Sampleهایی که این حالت فعال است—تا بتوان ضعف‌های قدیمی و نقاط قوت رویکردهای جدید را لمس کرد.
۵. تماس با تامین‌کنندگان ابزار و رصد مستمر آپدیت‌های تخصصی
توصیه می‌شود تیم‌های امنیتی عضو mailing listها، خبرنامه‌ها و مستندات بازار (مثلاً SANS، Magnet Forensics Blog، CrowdStrike و غیره) باشند تا با هر آپدیت ابزارها و تاکتیک‌های جدید آشنا بمانند
#آکادمی_روزبه
مرکز تخصصی CISSP
❤6
آکادمی آموزش روزبه 📚
تأثیر Virtualization-Based Security (VBS) ویندوز ۱۱ بر فارنزیک حافظه: چالش‌ها و راهکارها مقدمه با مهاجرت تدریجی سازمان‌ها و کاربران نهایی به ویندوز ۱۱، شاهد دگرگونی جدی در لایه‌های امنیتی این سیستم‌عامل، به‌ویژه در حوزه حفاظت از حافظه RAM هستیم. مهم‌ترین…
پس همانطور که می‌بینیم یا باید دائم مطالعه کنیم یا هر چند وقت یکبار با آموزش و کلاس ؛ دانش خود را به روز کنیم
این دنیای امنیت سایبری است
مواظب باشید چون ممکن است زود قدیمی !!شوید
این دنیای امنیت سایبری است
مواظب باشید چون ممکن است زود قدیمی !!شوید
👏6❤2⚡1🤝1
شناسایی افراد مهم که حتی موبایل هوشمند ندارند
ردپای اوسینت ؛ مساله ای قابل تذکر
سناریوی واقعی با تاکید بر OSINT بدون ردپای مستقیم دیجیتال فرد هدف:
فرض کنید یک شخصیت دولتی بسیار مهم که:
هرگز گوشی هوشمند با سیستم‌عامل نداشته،
هیچ حساب در شبکه‌های اجتماعی شخصی ندارد،
هیچ موقعیت مکانی از خودش منتشر نکرده است.
چطور OSINT می‌تواند او را لو بدهد؟
۱. ردپای غیرمستقیم (Social Graph Leakage):
خانواده، دوستان، راننده، تیم حفاظتی یا حتی کارمندان (مثلاً منشی یا خدمتکار) این شخص، ممکن است موقعیت یا عکسی از محل (هتل، دفتر، جلسه) منتشر کنند. با بررسی عکس‌ها و چک-این‌های آنها در شبکه‌های اجتماعی یا حتی اپلیکیشن‌های ورزشی ، هر بار نزدیک فرد موردنظر هستند، موقعیت مکانی تقریباً لو می‌رود.
مثال واقعی: در سال ۲۰۱۸ پایگاه‌های نظامی آمریکا به‌واسطه داده‌های Strava از سربازانی که دویدن می‌کردند، روی نقشه جهانی لو رفت.
۲. افشای تصادفی در رسانه‌ها و رویدادها:
خبرگزاری‌ها، خبرنگاران یا مشارکت‌کنندگان دیگر (مثلاً یک مهمان در جلسه خصوصی) ممکن است حتی ناخواسته حضور فرد را ذکر یا عکسی از او منتشر کنند و با ذکر ساعت و مکان، حضورش در نقطه خاص را آشکار کنند.
داده‌های مکانی از منابع جانبی (Venue OSINT):
بررسی سامانه‌های رزرواسیون پرواز/هتل، اسناد افشاشده حوادث، ایمیل‌های فیشینگ هدفمند یا دعوت‌نامه‌های رسمی (که گاهی لو می‌روند یا در سایت یک اداره یا کنفرانس درج می‌شوند).
وOSINT بر اساس نقشه‌های شهری و تغییرات محیطی:
اگر تیم اسکورت یا خودروی او دائماً در منطقه خاصی رفت‌وآمد دارد (شناسه پلاک یا حتی الگوی حرکت)، از تصاویر Google Street View، داده‌های ترافیکی شهری، یا ویدئوهای افراد دیگر می‌توان مسیر تردد معمول را بازسازی کرد.
نتیجه:
فرد حتی بدون “نماد حضور دیجیتال”، قربانی افشای غیرمستقیم بقیه، اشتباهات اطرافیان یا داده‌های عمومی می‌شود. این همان خطری است که ضرورت آموزش OPSEC برای خانواده، تیم حفاظت و حتی مهمانان و اخبار را دوچندان نشان می‌دهد.
تذکر : در این سناریو به تعداد معدودی از اقلام اطلاعاتی مرجع اشاره شد. طبیعتا با انباشت اطلاعات ، استخراج های دقیق تری انجام می‌شود
مرجع برای مطالعه : دوره
SANS SEC497: Practical Open-Source Intelligence (OSINT)™
#آکادمی_روزبه
مرکز تخصصی CISSP
ردپای اوسینت ؛ مساله ای قابل تذکر
سناریوی واقعی با تاکید بر OSINT بدون ردپای مستقیم دیجیتال فرد هدف:
فرض کنید یک شخصیت دولتی بسیار مهم که:
هرگز گوشی هوشمند با سیستم‌عامل نداشته،
هیچ حساب در شبکه‌های اجتماعی شخصی ندارد،
هیچ موقعیت مکانی از خودش منتشر نکرده است.
چطور OSINT می‌تواند او را لو بدهد؟
۱. ردپای غیرمستقیم (Social Graph Leakage):
خانواده، دوستان، راننده، تیم حفاظتی یا حتی کارمندان (مثلاً منشی یا خدمتکار) این شخص، ممکن است موقعیت یا عکسی از محل (هتل، دفتر، جلسه) منتشر کنند. با بررسی عکس‌ها و چک-این‌های آنها در شبکه‌های اجتماعی یا حتی اپلیکیشن‌های ورزشی ، هر بار نزدیک فرد موردنظر هستند، موقعیت مکانی تقریباً لو می‌رود.
مثال واقعی: در سال ۲۰۱۸ پایگاه‌های نظامی آمریکا به‌واسطه داده‌های Strava از سربازانی که دویدن می‌کردند، روی نقشه جهانی لو رفت.
۲. افشای تصادفی در رسانه‌ها و رویدادها:
خبرگزاری‌ها، خبرنگاران یا مشارکت‌کنندگان دیگر (مثلاً یک مهمان در جلسه خصوصی) ممکن است حتی ناخواسته حضور فرد را ذکر یا عکسی از او منتشر کنند و با ذکر ساعت و مکان، حضورش در نقطه خاص را آشکار کنند.
داده‌های مکانی از منابع جانبی (Venue OSINT):
بررسی سامانه‌های رزرواسیون پرواز/هتل، اسناد افشاشده حوادث، ایمیل‌های فیشینگ هدفمند یا دعوت‌نامه‌های رسمی (که گاهی لو می‌روند یا در سایت یک اداره یا کنفرانس درج می‌شوند).
وOSINT بر اساس نقشه‌های شهری و تغییرات محیطی:
اگر تیم اسکورت یا خودروی او دائماً در منطقه خاصی رفت‌وآمد دارد (شناسه پلاک یا حتی الگوی حرکت)، از تصاویر Google Street View، داده‌های ترافیکی شهری، یا ویدئوهای افراد دیگر می‌توان مسیر تردد معمول را بازسازی کرد.
نتیجه:
فرد حتی بدون “نماد حضور دیجیتال”، قربانی افشای غیرمستقیم بقیه، اشتباهات اطرافیان یا داده‌های عمومی می‌شود. این همان خطری است که ضرورت آموزش OPSEC برای خانواده، تیم حفاظت و حتی مهمانان و اخبار را دوچندان نشان می‌دهد.
تذکر : در این سناریو به تعداد معدودی از اقلام اطلاعاتی مرجع اشاره شد. طبیعتا با انباشت اطلاعات ، استخراج های دقیق تری انجام می‌شود
مرجع برای مطالعه : دوره
SANS SEC497: Practical Open-Source Intelligence (OSINT)™
#آکادمی_روزبه
مرکز تخصصی CISSP
❤3💯3🙏2⚡1🔥1
❌️❌❌❌️👆👆❌️❌️❌️❌️
بی سوادی موج میزنه
والله متخصص نیستین حداقل بروید یک کلاس تحلیل نقادانه بگذرانید بعد دست به قلم بشین
عیبه اینطوری چی رو به چی ربط میدین !!
یه نوشته حداقل گزاره های خودش باید دیگری رو تایید کنه.
چون در تصویر فوق؛ چی چیو تایید میکنه ؟
**نمیگم اصلا امکان نداره . میگم این طرز استنتاج و نوشتن ضایعه!!
ضمنا اگر میخوای تبلیغ کنی هم تابلو هست
بی سوادی موج میزنه
والله متخصص نیستین حداقل بروید یک کلاس تحلیل نقادانه بگذرانید بعد دست به قلم بشین
عیبه اینطوری چی رو به چی ربط میدین !!
یه نوشته حداقل گزاره های خودش باید دیگری رو تایید کنه.
چون در تصویر فوق؛ چی چیو تایید میکنه ؟
**نمیگم اصلا امکان نداره . میگم این طرز استنتاج و نوشتن ضایعه!!
ضمنا اگر میخوای تبلیغ کنی هم تابلو هست
❤6👏5
دوره های رایگان
https://redteamleaders.coursestack.com/courses/4cc576dd-934b-4289-a100-8a233fe07ef2
https://redteamleaders.coursestack.com/courses/1390aba4-3ad7-4ae2-8e2a-4575a821b0f7
https://redteamleaders.coursestack.com/courses/4cc576dd-934b-4289-a100-8a233fe07ef2
https://redteamleaders.coursestack.com/courses/1390aba4-3ad7-4ae2-8e2a-4575a821b0f7
Redteamleaders
Introduction to Offensive Security with Artificial Intelligence
Learn how Artificial Intelligence can empower Red Team operations through automation, reconnaissance, and offensive simulation
❤7