چگونه EDRها در لینوکس کار می‌کنند: تمرکز بر Kernel Probes و نظارت بر Syscallها
در دنیای امنیت سایبری امروز، ابزارهای Endpoint Detection and Response (EDR) نقش حیاتی در حفاظت از سیستم‌ها ایفا می‌کنند. EDRها سیستم‌هایی پیشرفته هستند که فراتر از آنتی‌ویروس‌های سنتی عمل کرده و بر تشخیص real-time تهدیدات، جمع‌آوری داده‌ها و پاسخ خودکار تمرکز دارند. این ابزارها، مانند CrowdStrike Falcon، Microsoft Defender for Endpoint یا SentinelOne، با نظارت مداوم بر فعالیت‌های endpoint (مانند سرورها و دسکتاپ‌ها) کار می‌کنند تا نشانه‌های نفوذ (Indicators of Compromise یا IOC) را شناسایی کنند. اما چگونه این نظارت عمیق انجام می‌شود؟
یکی از کلیدی‌ترین مکانیسم‌ها، استفاده از kernel probes است که اجازه میدهد EDRها مستقیماً به لایه‌های پایین سیستم‌عامل نفوذ کنند.
مقولهKernel probes، مانند kprobes یا eBPF (extended Berkeley Packet Filter) در لینوکس، ابزاری قدرتمند برای تزریق کدهای نظارتی به نقاط خاصی از کرنل هستند. این probes بدون تغییر کد اصلی کرنل، رویدادها را رهگیری می‌کنند.
برای مثال، EDRها می‌توانند probes را روی syscallهایی مانند keyctl_add_key قرار دهند. این syscall بخشی از زیرسیستم keyring در کرنل لینوکس است که برای افزودن کلیدها یا داده‌های حساس به ساختارهای حافظه‌ای volatile استفاده می‌شود. مهاجمان اغلب از keyring برای مخفی‌کردن payloadهای مخرب (مانند backdoorها) بهره می‌برند، زیرا این داده‌ها روی دیسک ذخیره نمی‌شوند و با ریبوت سیستم پاک می‌شوند.
وقتی EDR یک probe روی keyctl_add_key تنظیم میکند، هر بار که این syscall فراخوانی شود، EDR می‌تواند پارامترها (مانند نوع کلید، محتوای آن و فرآیند فراخواننده) را ضبط کند. این داده‌ها به سرور مرکزی EDR ارسال شده و با الگوریتم‌های یادگیری ماشین یا قوانین رفتاری تحلیل می‌شوند. مثلاً اگر یک فرآیند مشکوک (مانند یک shell script مخرب) سعی کند داده‌ای رمزنگاری‌شده را به keyring اضافه کند، EDR می‌تواند آن را به‌عنوان فعالیت غیرعادی تشخیص دهد و هشدار دهد یا حتی فرآیند را قرنطینه کند. این رویکرد مشابه “rootkitهای قانونی” است، زیرا EDRها با hooking syscallها و نظارت بر حافظه کرنل، عملاً رفتار مهاجمان را تقلید می‌کنند اما برای اهداف دفاعی.
علاوه بر probes، EDRها از تکنیک‌های دیگری مانند user-space hooking، log aggregation و behavioral analytics استفاده می‌کنند. برای نمونه، در سناریوی حمله به keyring، EDR می‌تواند با ترکیب داده‌های syscall با لاگ‌های شبکه یا فایل‌ها، یک زنجیره حمله کامل را بازسازی کند. این قابلیت‌ها EDRها را برای محیط‌های پیچیده مانند سرورهای ابری یا سیستم‌های IoT ایده‌آل می‌سازد.
با این حال، چالش‌هایی وجود دارد: تنظیم نادرست probes می‌تواند عملکرد سیستم را کاهش دهد یا حتی با به‌روزرسانی‌های کرنل تداخل ایجاد کند. علاوه بر این، مهاجمان پیشرفته ممکن است تکنیک‌هایی برای دورزدن probes (مانند استفاده از syscallهای جایگزین) به‌کار گیرند. در نهایت، EDRها مرز بین تشخیص و پاسخ را کم‌رنگ کرده و شکارچی‌های تهدید را توانمند می‌سازند تا نفوذهای نامرئی را کشف کنند. با پیشرفت فناوری‌هایی مانند eBPF، آینده EDRها روشن‌تر از همیشه است.
#آکادمی_روزبه
در دنیای امنیت سایبری امروز، ابزارهای Endpoint Detection and Response (EDR) نقش حیاتی در حفاظت از سیستم‌ها ایفا می‌کنند. EDRها سیستم‌هایی پیشرفته هستند که فراتر از آنتی‌ویروس‌های سنتی عمل کرده و بر تشخیص real-time تهدیدات، جمع‌آوری داده‌ها و پاسخ خودکار تمرکز دارند. این ابزارها، مانند CrowdStrike Falcon، Microsoft Defender for Endpoint یا SentinelOne، با نظارت مداوم بر فعالیت‌های endpoint (مانند سرورها و دسکتاپ‌ها) کار می‌کنند تا نشانه‌های نفوذ (Indicators of Compromise یا IOC) را شناسایی کنند. اما چگونه این نظارت عمیق انجام می‌شود؟
یکی از کلیدی‌ترین مکانیسم‌ها، استفاده از kernel probes است که اجازه میدهد EDRها مستقیماً به لایه‌های پایین سیستم‌عامل نفوذ کنند.
مقولهKernel probes، مانند kprobes یا eBPF (extended Berkeley Packet Filter) در لینوکس، ابزاری قدرتمند برای تزریق کدهای نظارتی به نقاط خاصی از کرنل هستند. این probes بدون تغییر کد اصلی کرنل، رویدادها را رهگیری می‌کنند.
برای مثال، EDRها می‌توانند probes را روی syscallهایی مانند keyctl_add_key قرار دهند. این syscall بخشی از زیرسیستم keyring در کرنل لینوکس است که برای افزودن کلیدها یا داده‌های حساس به ساختارهای حافظه‌ای volatile استفاده می‌شود. مهاجمان اغلب از keyring برای مخفی‌کردن payloadهای مخرب (مانند backdoorها) بهره می‌برند، زیرا این داده‌ها روی دیسک ذخیره نمی‌شوند و با ریبوت سیستم پاک می‌شوند.
وقتی EDR یک probe روی keyctl_add_key تنظیم میکند، هر بار که این syscall فراخوانی شود، EDR می‌تواند پارامترها (مانند نوع کلید، محتوای آن و فرآیند فراخواننده) را ضبط کند. این داده‌ها به سرور مرکزی EDR ارسال شده و با الگوریتم‌های یادگیری ماشین یا قوانین رفتاری تحلیل می‌شوند. مثلاً اگر یک فرآیند مشکوک (مانند یک shell script مخرب) سعی کند داده‌ای رمزنگاری‌شده را به keyring اضافه کند، EDR می‌تواند آن را به‌عنوان فعالیت غیرعادی تشخیص دهد و هشدار دهد یا حتی فرآیند را قرنطینه کند. این رویکرد مشابه “rootkitهای قانونی” است، زیرا EDRها با hooking syscallها و نظارت بر حافظه کرنل، عملاً رفتار مهاجمان را تقلید می‌کنند اما برای اهداف دفاعی.
علاوه بر probes، EDRها از تکنیک‌های دیگری مانند user-space hooking، log aggregation و behavioral analytics استفاده می‌کنند. برای نمونه، در سناریوی حمله به keyring، EDR می‌تواند با ترکیب داده‌های syscall با لاگ‌های شبکه یا فایل‌ها، یک زنجیره حمله کامل را بازسازی کند. این قابلیت‌ها EDRها را برای محیط‌های پیچیده مانند سرورهای ابری یا سیستم‌های IoT ایده‌آل می‌سازد.
با این حال، چالش‌هایی وجود دارد: تنظیم نادرست probes می‌تواند عملکرد سیستم را کاهش دهد یا حتی با به‌روزرسانی‌های کرنل تداخل ایجاد کند. علاوه بر این، مهاجمان پیشرفته ممکن است تکنیک‌هایی برای دورزدن probes (مانند استفاده از syscallهای جایگزین) به‌کار گیرند. در نهایت، EDRها مرز بین تشخیص و پاسخ را کم‌رنگ کرده و شکارچی‌های تهدید را توانمند می‌سازند تا نفوذهای نامرئی را کشف کنند. با پیشرفت فناوری‌هایی مانند eBPF، آینده EDRها روشن‌تر از همیشه است.
#آکادمی_روزبه
❤4🔥2💯2
اینو به یکی گفتن که EDR بای پس کرده
تبریک بابت اینکه یک‌بار با تکنیک تازه‌ات تونستی از EDR عبور کنی. اما واقعیت اینه که سیستم رو دور نزدی؛ فقط باعث شدی پروفایل (شناخت) سیستم ازت بالاتر بره.
حالا فعالیت‌هات مثل انگشت زخمی وسط بقیه دست‌ها معلومه. داده‌های تله‌متری داره جمع میشه، ارتباط‌ها و الگوها در حال شکل‌گیریه، و هر حرکت بعدی فقط پرونده‌ت رو قوی‌تر می‌کنه. EDR کور نیست، فقط تو پرچم‌ها (هشدارها) رو نمی‌بینی
تبریک بابت اینکه یک‌بار با تکنیک تازه‌ات تونستی از EDR عبور کنی. اما واقعیت اینه که سیستم رو دور نزدی؛ فقط باعث شدی پروفایل (شناخت) سیستم ازت بالاتر بره.
حالا فعالیت‌هات مثل انگشت زخمی وسط بقیه دست‌ها معلومه. داده‌های تله‌متری داره جمع میشه، ارتباط‌ها و الگوها در حال شکل‌گیریه، و هر حرکت بعدی فقط پرونده‌ت رو قوی‌تر می‌کنه. EDR کور نیست، فقط تو پرچم‌ها (هشدارها) رو نمی‌بینی
🔥5❤4👍2
تجربه شخصی
سوءاستفاده از Velociraptor برای دسترسی از راه دور
این یکی از آن پرونده‌هایی بود که از همان لحظه اول به من حس خوبی نمی‌داد. هشدار اولیه، یک Storyline عجیب بود که از تونلینگ در Visual Studio Code خبر می‌داد. VSCode؟ آن هم روی یک سرور حیاتی؟ عجیب بود.
لحظه‌ای که به سیستم وارد شدم، دیدم ماجرا از یک msiexec ساده شروع شده؛ نصب‌کننده‌ای از دامنه‌ی ..... که «اتفاقاً» Velociraptor را نصب کرده بود. ابزار قانونی و محبوب تیم‌های DFIR، اما این‌بار برای من حکم یک پیک نفوذچی را داشت.
پیکربندی طوری انجام شده بود که Velociraptor مستقیماً به یک C2 مرتبط شود. بعد با یک PowerShell رمزگذاری‌شده، VSCode دانلود و با گزینه‌ی tunnel اجرا شده بود. این تونل عملاً یک خط مستقیم از سیستم به دست مهاجم باز می‌کرد. حتی code.exe را به عنوان یک سرویس نصب کرده بودند تا ماندگار شود.
اثری از بدافزار سنتی نبود. فقط ابزارهای قانونی، ولی در دستان اشتباه. این همان نقطه‌ای است که تجربه به من می‌گوید: «کمترین اثر مخرب = بیشترین نیاز به هوشیاری».
ما سریع سیستم را ایزوله کردیم. بررسى‌ها نشان داد اگر چند ساعت دیرتر عمل می‌کردیم، این تونل به مسیر مستقیم برای باج‌افزار ختم می‌شد.
این حادثه برایم یادآور شد که تهدید امروز لزوماً یک فایل exe ناشناس نیست. گاهی همان ابزاری که دیروز با آن جرم‌یابی می‌کردی، فردا می‌تواند جرم‌ساز باشد
#آکادمی_روزبه
سوءاستفاده از Velociraptor برای دسترسی از راه دور
این یکی از آن پرونده‌هایی بود که از همان لحظه اول به من حس خوبی نمی‌داد. هشدار اولیه، یک Storyline عجیب بود که از تونلینگ در Visual Studio Code خبر می‌داد. VSCode؟ آن هم روی یک سرور حیاتی؟ عجیب بود.
لحظه‌ای که به سیستم وارد شدم، دیدم ماجرا از یک msiexec ساده شروع شده؛ نصب‌کننده‌ای از دامنه‌ی ..... که «اتفاقاً» Velociraptor را نصب کرده بود. ابزار قانونی و محبوب تیم‌های DFIR، اما این‌بار برای من حکم یک پیک نفوذچی را داشت.
پیکربندی طوری انجام شده بود که Velociraptor مستقیماً به یک C2 مرتبط شود. بعد با یک PowerShell رمزگذاری‌شده، VSCode دانلود و با گزینه‌ی tunnel اجرا شده بود. این تونل عملاً یک خط مستقیم از سیستم به دست مهاجم باز می‌کرد. حتی code.exe را به عنوان یک سرویس نصب کرده بودند تا ماندگار شود.
اثری از بدافزار سنتی نبود. فقط ابزارهای قانونی، ولی در دستان اشتباه. این همان نقطه‌ای است که تجربه به من می‌گوید: «کمترین اثر مخرب = بیشترین نیاز به هوشیاری».
ما سریع سیستم را ایزوله کردیم. بررسى‌ها نشان داد اگر چند ساعت دیرتر عمل می‌کردیم، این تونل به مسیر مستقیم برای باج‌افزار ختم می‌شد.
این حادثه برایم یادآور شد که تهدید امروز لزوماً یک فایل exe ناشناس نیست. گاهی همان ابزاری که دیروز با آن جرم‌یابی می‌کردی، فردا می‌تواند جرم‌ساز باشد
#آکادمی_روزبه
🔥5👏4👍3💯3❤1
شکار تهدید: کشف سوءاستفاده از werfault.exe
عزیزان بسیاری در SOC های کشور درحال انجام وظایف خطیر هستند که بعضا منجر به کشف های بدیع و جالب میگردد.
اما نکته مهم آن است که اشتراک تجربیات به میزان کمی صورت می‌پذیرد. دلیل آن را نمی‌خواهم بشکافم ولی ترجیح میدهم هم به همکاران هم به مدیران آنها توصیه به اشتراک دانش داشته باشم.
خودم درحد توان که باشه ، تجربیاتی که مشکل امنیتی نداشته داشته باشه رو برای انتقال تجربیات اینجا میگذارم .
در یکی از پروژه‌های شکار تهدید اخیر، متوجه یک الگوی غیرعادی در لاگ‌های EDR شدم. یک پروسس سیستم مایکروسافت به‌نام werfault.exe --که در حالت عادی مسئول گزارش خطاها و ارسال آن به مایکروسافت است -- در حال برقراری ارتباط شبکه‌ای با یک دامنه ناشناس بود.
در نگاه اول، این رفتار می‌توانست یک خطای سیستمی عادی تلقی شود، اما بررسی دقیق‌تر مسیر اجرای پروسس نشان داد که فایل werfault.exe از مسیر پیش‌فرض ویندوز (C:\Windows\System32\) اجرا نشده، بلکه در یک مسیر مشکوک مانند C:\ProgramData\ قرار داشته است. این موضوع احتمال جعل یا سوءاستفاده عمدی را به‌شدت تقویت کرد.
با بازسازی زنجیره رویداد (Event Chain) مشخص شد که مهاجم از تکنیک DLL Sideloading بهره برده و werfault.exe را به‌عنوان یک LOLBAS برای اجرای لودر بدافزار استفاده کرده است. به دلیل اعتماد ذاتی بسیاری از راهکارهای امنیتی به این پروسس، فعالیت‌های مخرب آن از دید مکانیزم‌های پیشگیری عبور کرده بود.
در گام پایانی، با قرنطینه کردن فایل جعلی و مسدود کردن ارتباطات شبکه‌ای مرتبط، مسیر نفوذ مهاجم مسدود شد و IoCهای به‌دست‌آمده به تیم‌های Blue و Red جهت بهبود Playbookها و سناریوهای شبیه‌سازی ارسال گردید.
این تجربه بار دیگر ثابت کرد که در شکار تهدید، حتی «پروسس‌های آشنا» نیز می‌توانند میزبان فعالیت‌های بسیار مخرب باشند و تحلیل مبتنی بر ناهنجاری رفتاری یکی از کلیدهای اصلی موفقیت است.
#آکادمی_روزبه
هاب انتقال تجربیات عملیاتی
عزیزان بسیاری در SOC های کشور درحال انجام وظایف خطیر هستند که بعضا منجر به کشف های بدیع و جالب میگردد.
اما نکته مهم آن است که اشتراک تجربیات به میزان کمی صورت می‌پذیرد. دلیل آن را نمی‌خواهم بشکافم ولی ترجیح میدهم هم به همکاران هم به مدیران آنها توصیه به اشتراک دانش داشته باشم.
خودم درحد توان که باشه ، تجربیاتی که مشکل امنیتی نداشته داشته باشه رو برای انتقال تجربیات اینجا میگذارم .
در یکی از پروژه‌های شکار تهدید اخیر، متوجه یک الگوی غیرعادی در لاگ‌های EDR شدم. یک پروسس سیستم مایکروسافت به‌نام werfault.exe --که در حالت عادی مسئول گزارش خطاها و ارسال آن به مایکروسافت است -- در حال برقراری ارتباط شبکه‌ای با یک دامنه ناشناس بود.
در نگاه اول، این رفتار می‌توانست یک خطای سیستمی عادی تلقی شود، اما بررسی دقیق‌تر مسیر اجرای پروسس نشان داد که فایل werfault.exe از مسیر پیش‌فرض ویندوز (C:\Windows\System32\) اجرا نشده، بلکه در یک مسیر مشکوک مانند C:\ProgramData\ قرار داشته است. این موضوع احتمال جعل یا سوءاستفاده عمدی را به‌شدت تقویت کرد.
با بازسازی زنجیره رویداد (Event Chain) مشخص شد که مهاجم از تکنیک DLL Sideloading بهره برده و werfault.exe را به‌عنوان یک LOLBAS برای اجرای لودر بدافزار استفاده کرده است. به دلیل اعتماد ذاتی بسیاری از راهکارهای امنیتی به این پروسس، فعالیت‌های مخرب آن از دید مکانیزم‌های پیشگیری عبور کرده بود.
در گام پایانی، با قرنطینه کردن فایل جعلی و مسدود کردن ارتباطات شبکه‌ای مرتبط، مسیر نفوذ مهاجم مسدود شد و IoCهای به‌دست‌آمده به تیم‌های Blue و Red جهت بهبود Playbookها و سناریوهای شبیه‌سازی ارسال گردید.
این تجربه بار دیگر ثابت کرد که در شکار تهدید، حتی «پروسس‌های آشنا» نیز می‌توانند میزبان فعالیت‌های بسیار مخرب باشند و تحلیل مبتنی بر ناهنجاری رفتاری یکی از کلیدهای اصلی موفقیت است.
#آکادمی_روزبه
هاب انتقال تجربیات عملیاتی
💯8👍4🙏2❤1🔥1
یاد آموخته ای برای دوستانم
آرام باشیم و سرعت زندگی را کاهش دهیم .
سرعت زندگی را افکار ما تعیین میکند . ممکن است فردی از لحاظ جسمی زندگی آرامی داشته باشد اما از لحاظ عاطفی زندگی پرشتابی داشته باشد. وقتی ذهن ما با آشفتگی از یک نگرش به نگرش دیگر میپرد ، تب آلود می‌شود، در نتیجه شخص بداخلاق و کم حوصله میگردد.
اگر می‌خواهید از تاثیر مخرب تحریکات و هیجانات زندگی امروزی دائما در عذاب نباشید باید شتاب زندگی تان را کاهش دهید.
تحریک پذیری بیش از حد در بدن ما سم تولید میکند و موجب بیماری روحی و عاطفی می‌شود.این می‌شود که ما از مسائل شخصی تا موارد کشوری وجهانی عصبانی میشویم .
پس آرام یاشید .
حتی در SOC که در ظاهر نشدنی است اما برای جلوگیری از بریدن افراد یا Burnout باید آرامش را حکمفرما کنید.
دهم شهریور ماه ۱۴۰۴ تهران
منبع:
The Power of Positive Thinking
نویسنده: Norman Vincent Peale
آرام باشیم و سرعت زندگی را کاهش دهیم .
سرعت زندگی را افکار ما تعیین میکند . ممکن است فردی از لحاظ جسمی زندگی آرامی داشته باشد اما از لحاظ عاطفی زندگی پرشتابی داشته باشد. وقتی ذهن ما با آشفتگی از یک نگرش به نگرش دیگر میپرد ، تب آلود می‌شود، در نتیجه شخص بداخلاق و کم حوصله میگردد.
اگر می‌خواهید از تاثیر مخرب تحریکات و هیجانات زندگی امروزی دائما در عذاب نباشید باید شتاب زندگی تان را کاهش دهید.
تحریک پذیری بیش از حد در بدن ما سم تولید میکند و موجب بیماری روحی و عاطفی می‌شود.این می‌شود که ما از مسائل شخصی تا موارد کشوری وجهانی عصبانی میشویم .
پس آرام یاشید .
حتی در SOC که در ظاهر نشدنی است اما برای جلوگیری از بریدن افراد یا Burnout باید آرامش را حکمفرما کنید.
دهم شهریور ماه ۱۴۰۴ تهران
منبع:
The Power of Positive Thinking
نویسنده: Norman Vincent Peale
❤9👏3
بحث Port Knocking چیست؟
مقوله Port Knocking (به فارسی: در زدن به پورت) یک تکنیک امنیتی برای کنترل دسترسی به سرویس‌های شبکه است. در این روش، پورت‌های یک سرویس (مانند SSH روی پورت 22) به طور پیش‌فرض روی فایروال کاملاً بسته و غیرقابل دسترس هستند. برای باز شدن یک پورت خاص، کاربر باید یک “رمز عبور مخفی” را ارسال کند. این رمز عبور، یک دنباله از پیش تعریف‌شده از تلاش برای اتصال به پورت‌های مختلف است.
به زبان ساده، شما به جای اینکه مستقیماً به در اصلی (مثلاً پورت 22) بروید و آن را باز کنید (که همیشه بسته است)، ابتدا یک سری “تق تق” خاص به درهای دیگر می‌زنید (مثلاً یک بار به پورت 1000، سپس دو بار به پورت 2000 و در آخر یک بار به پورت 3000). اگر این الگوی “در زدن” صحیح باشد، فایروال به طور موقت در اصلی (پورت 22) را فقط برای شما (آدرس IP شما) باز میکند.
این کار باعث می‌شود که سرویس‌های شما از دید اسکنرهای پورت (Port Scanners) و مهاجمان کاملاً نامرئی باشند، زیرا هیچ پورت بازی برای شناسایی وجود ندارد.
مبحث Port Knocking چگونه کار میکند؟
این فرآیند معمولاً توسط یک سرویس کوچک (Daemon) روی سرور مدیریت می‌شود (مانند knockd در لینوکس) که لاگ‌های فایروال را برای پیدا کردن الگوی صحیح زیر نظر دارد.
وضعیت اولیه (State 0 - همه چیز بسته):
فایروال سرور طوری تنظیم شده است که تمام ترافیک ورودی به پورت‌های حساس (مثلاً پورت 22 برای SSH) را مسدود (DROP یا REJECT) کند.
در این حالت، اگر کسی تلاش کند پورت 22 را اسکن کند، هیچ پاسخی دریافت نمی‌کند و تصور میکند این پورت بسته است.
ارسال دنباله “در زدن” (The Knock Sequence):
کاربر مجاز (Client) که قصد اتصال به سرویس SSH را دارد، از یک ابزار ساده (مانند netcat, nmap یا یک اسکریپت اختصاصی) استفاده میکند تا بسته‌های TCP یا UDP را به ترتیب به پورت‌های از پیش توافق شده ارسال کند.
مثال دنباله:
یک بسته TCP SYN به پورت 7000
یک بسته TCP SYN به پورت 8000
یک بسته TCP SYN به پورت 9000
مهم نیست که این پورت‌ها واقعاً باز باشند یا نه. خودِ “تلاش برای اتصال” به عنوان یک سیگنال عمل میکند.
تشخیص الگو توسط سرور (Server-side Detection):
سرویس knockd روی سرور به طور مداوم لاگ‌های فایروال (iptables, nftables) را مشاهده میکند.
وقتی بسته‌ای به یک پورت بسته می‌رسد، فایروال آن را لاگ میکند. سرویس knockd این لاگ‌ها را می‌خواند و به دنبال دنباله صحیح از آدرس IP مشخصی میگردد (مثلاً: تلاش برای اتصال به پورت 7000، سپس 8000، سپس 9000 از IP Address 1.2.3.4).
باز کردن موقت پورت (Opening the Port):
اگر knockd الگوی صحیح را از یک IP مشخص تشخیص دهد، یک دستور به فایروال ارسال میکند تا پورت اصلی (مثلاً 22) را فقط برای آن IP خاص باز کند
#آکادمی_روزبه
مقوله Port Knocking (به فارسی: در زدن به پورت) یک تکنیک امنیتی برای کنترل دسترسی به سرویس‌های شبکه است. در این روش، پورت‌های یک سرویس (مانند SSH روی پورت 22) به طور پیش‌فرض روی فایروال کاملاً بسته و غیرقابل دسترس هستند. برای باز شدن یک پورت خاص، کاربر باید یک “رمز عبور مخفی” را ارسال کند. این رمز عبور، یک دنباله از پیش تعریف‌شده از تلاش برای اتصال به پورت‌های مختلف است.
به زبان ساده، شما به جای اینکه مستقیماً به در اصلی (مثلاً پورت 22) بروید و آن را باز کنید (که همیشه بسته است)، ابتدا یک سری “تق تق” خاص به درهای دیگر می‌زنید (مثلاً یک بار به پورت 1000، سپس دو بار به پورت 2000 و در آخر یک بار به پورت 3000). اگر این الگوی “در زدن” صحیح باشد، فایروال به طور موقت در اصلی (پورت 22) را فقط برای شما (آدرس IP شما) باز میکند.
این کار باعث می‌شود که سرویس‌های شما از دید اسکنرهای پورت (Port Scanners) و مهاجمان کاملاً نامرئی باشند، زیرا هیچ پورت بازی برای شناسایی وجود ندارد.
مبحث Port Knocking چگونه کار میکند؟
این فرآیند معمولاً توسط یک سرویس کوچک (Daemon) روی سرور مدیریت می‌شود (مانند knockd در لینوکس) که لاگ‌های فایروال را برای پیدا کردن الگوی صحیح زیر نظر دارد.
وضعیت اولیه (State 0 - همه چیز بسته):
فایروال سرور طوری تنظیم شده است که تمام ترافیک ورودی به پورت‌های حساس (مثلاً پورت 22 برای SSH) را مسدود (DROP یا REJECT) کند.
در این حالت، اگر کسی تلاش کند پورت 22 را اسکن کند، هیچ پاسخی دریافت نمی‌کند و تصور میکند این پورت بسته است.
ارسال دنباله “در زدن” (The Knock Sequence):
کاربر مجاز (Client) که قصد اتصال به سرویس SSH را دارد، از یک ابزار ساده (مانند netcat, nmap یا یک اسکریپت اختصاصی) استفاده میکند تا بسته‌های TCP یا UDP را به ترتیب به پورت‌های از پیش توافق شده ارسال کند.
مثال دنباله:
یک بسته TCP SYN به پورت 7000
یک بسته TCP SYN به پورت 8000
یک بسته TCP SYN به پورت 9000
مهم نیست که این پورت‌ها واقعاً باز باشند یا نه. خودِ “تلاش برای اتصال” به عنوان یک سیگنال عمل میکند.
تشخیص الگو توسط سرور (Server-side Detection):
سرویس knockd روی سرور به طور مداوم لاگ‌های فایروال (iptables, nftables) را مشاهده میکند.
وقتی بسته‌ای به یک پورت بسته می‌رسد، فایروال آن را لاگ میکند. سرویس knockd این لاگ‌ها را می‌خواند و به دنبال دنباله صحیح از آدرس IP مشخصی میگردد (مثلاً: تلاش برای اتصال به پورت 7000، سپس 8000، سپس 9000 از IP Address 1.2.3.4).
باز کردن موقت پورت (Opening the Port):
اگر knockd الگوی صحیح را از یک IP مشخص تشخیص دهد، یک دستور به فایروال ارسال میکند تا پورت اصلی (مثلاً 22) را فقط برای آن IP خاص باز کند
#آکادمی_روزبه
👍9💯4❤2🙏2
آکادمی آموزش روزبه 📚
بحث Port Knocking چیست؟ مقوله Port Knocking (به فارسی: در زدن به پورت) یک تکنیک امنیتی برای کنترل دسترسی به سرویس‌های شبکه است. در این روش، پورت‌های یک سرویس (مانند SSH روی پورت 22) به طور پیش‌فرض روی فایروال کاملاً بسته و غیرقابل دسترس هستند. برای باز شدن…
معایب و محدودیت‌های Port Knocking
عدم رمزنگاری: خود دنباله “در زدن” به صورت متن ساده (Plaintext) در شبکه ارسال می‌شود و توسط مهاجمی که ترافیک شبکه را شنود میکند (Sniffing) قابل مشاهده است. اگر مهاجم الگو را کشف کند، می‌تواند از آن برای باز کردن پورت برای خودش استفاده کند.
راه حل: استفاده از تکنیک Single Packet Authorization (SPA) که در آن یک بسته رمزنگاری شده و امضا شده (با کلید متقارن یا نامتقارن) ارسال می‌شود. ابزارهایی مانند fwknop این کار را انجام می‌دهند.
آسیب‌پذیری در برابر حملات Replay: اگر مهاجم دنباله را ضبط کند، می‌تواند آن را دوباره ارسال (Replay) کرده و پورت را باز کند.
مشکلات در شبکه‌های پیچیده (مانند NAT): اگر کاربر پشت یک شبکه NAT با چندین کاربر دیگر باشد، باز شدن پورت برای IP عمومی آن شبکه، دسترسی را برای همه کاربران آن شبکه باز میکند.
وابستگی به ترتیب بسته‌ها: در شبکه‌های پرازدحام، ممکن است بسته‌های “در زدن” با ترتیب اشتباه به سرور برسند و الگو شناسایی نشود. (استفاده از TCP به جای UDP می‌تواند این مشکل را تا حدی حل کند).
#آکادمی_روزبه
عدم رمزنگاری: خود دنباله “در زدن” به صورت متن ساده (Plaintext) در شبکه ارسال می‌شود و توسط مهاجمی که ترافیک شبکه را شنود میکند (Sniffing) قابل مشاهده است. اگر مهاجم الگو را کشف کند، می‌تواند از آن برای باز کردن پورت برای خودش استفاده کند.
راه حل: استفاده از تکنیک Single Packet Authorization (SPA) که در آن یک بسته رمزنگاری شده و امضا شده (با کلید متقارن یا نامتقارن) ارسال می‌شود. ابزارهایی مانند fwknop این کار را انجام می‌دهند.
آسیب‌پذیری در برابر حملات Replay: اگر مهاجم دنباله را ضبط کند، می‌تواند آن را دوباره ارسال (Replay) کرده و پورت را باز کند.
مشکلات در شبکه‌های پیچیده (مانند NAT): اگر کاربر پشت یک شبکه NAT با چندین کاربر دیگر باشد، باز شدن پورت برای IP عمومی آن شبکه، دسترسی را برای همه کاربران آن شبکه باز میکند.
وابستگی به ترتیب بسته‌ها: در شبکه‌های پرازدحام، ممکن است بسته‌های “در زدن” با ترتیب اشتباه به سرور برسند و الگو شناسایی نشود. (استفاده از TCP به جای UDP می‌تواند این مشکل را تا حدی حل کند).
#آکادمی_روزبه
❤6💯5👍2🙏1
مقوله Single Packet Authorization (SPA) چیست؟
بحث Port Knocking در فوق که مورد توجه دوستان قرار گرفت گفتم در ادامه اش ؛ این مطلب زیر رو هم بگذارم
مقوله Single Packet Authorization یا احراز هویت با بسته منفرد؛ یک تکنیک امنیتی پیشرفته برای مخفی‌کردن سرویس‌ها و کنترل دسترسی به آنهاست.
در این روش، درست مثل Port Knocking، همه پورت‌های حساس (مثل SSH روی پورت 22) به‌طور پیش‌فرض بسته‌اند. اما فرق اصلی اینجاست: به جای اینکه کاربر چند “تق‌تق” بزند و یک دنباله بسازد، همه چیز در یک‌بار و فقط با یک بسته رمزنگاری‌شده انجام می‌شود.
داستان چطور است؟
فرض کنید خانه‌ای دارید با یک در نامرئی. فقط با گفتن یک کلمه‌عبور رمزنگاری‌شده، که آن را در یک یادداشت قفل‌شده داخل پاکت به نگهبان در می‌دهید، در برای شما باز می‌شود و برای بقیه همچنان نامرئی باقی می‌ماند.
در شبکه هم همین اتفاق می‌افتد:
وضعیت اولیه (همه چیز بسته): فایروال سرور هیچ پاسخی به هیچ اتصال روی پورت حساس نمیدهد (Stealth Mode کامل).
ارسال بسته جادویی: کاربر مجاز ؛ با استفاده از ابزاری مثل fwknop یا یک کلاینت اختصاصی، یک بسته UDP یا TCP حاوی اطلاعات احراز هویت را رمزنگاری و امضا شده به سرور می‌فرستد.
تشخیص روی سرور: سرویس SPA روی سرور (مثلاً fwknopd) بسته را باز میکند، امضا را بررسی میکند و در صورتی که معتبر بود، پورت مورد نظر را فقط برای همان IP باز میکند.
اعتبار موقت: این باز شدن فقط برای مدت کوتاهی فعال است و سپس به حالت “کاملاً نامرئی” برمی‌گردد.
چرا این روش بهتر از Port Knocking است؟
یک شلیک، یک ضربه: به جای چند پورت و دنباله پیچیده، همه چیز در یک بسته انجام می‌شود.
رمزنگاری: حتی اگر مهاجم ترافیک را شنود کند، الگو و محتوای Knock را نمی‌بیند.
امنیت در برابر Replay Attack: چون دارای زمان‌بندی و شماره‌یکتای احراز است، بازپخش آن بی‌فایده می‌ماند.
سازگاری با NAT و IPv6: برخلاف Port Knocking سنتی، اینجا مشکل آدرس‌های پویای پشت NAT کمتر است.
به زبان ساده، SPA مناسب برای محیط‌هایی که هم امنیت بالا می‌خواهند و هم سرویس‌ها باید کاملاً مخفی بمانند
#آکادمی_روزبه
بحث Port Knocking در فوق که مورد توجه دوستان قرار گرفت گفتم در ادامه اش ؛ این مطلب زیر رو هم بگذارم
مقوله Single Packet Authorization یا احراز هویت با بسته منفرد؛ یک تکنیک امنیتی پیشرفته برای مخفی‌کردن سرویس‌ها و کنترل دسترسی به آنهاست.
در این روش، درست مثل Port Knocking، همه پورت‌های حساس (مثل SSH روی پورت 22) به‌طور پیش‌فرض بسته‌اند. اما فرق اصلی اینجاست: به جای اینکه کاربر چند “تق‌تق” بزند و یک دنباله بسازد، همه چیز در یک‌بار و فقط با یک بسته رمزنگاری‌شده انجام می‌شود.
داستان چطور است؟
فرض کنید خانه‌ای دارید با یک در نامرئی. فقط با گفتن یک کلمه‌عبور رمزنگاری‌شده، که آن را در یک یادداشت قفل‌شده داخل پاکت به نگهبان در می‌دهید، در برای شما باز می‌شود و برای بقیه همچنان نامرئی باقی می‌ماند.
در شبکه هم همین اتفاق می‌افتد:
وضعیت اولیه (همه چیز بسته): فایروال سرور هیچ پاسخی به هیچ اتصال روی پورت حساس نمیدهد (Stealth Mode کامل).
ارسال بسته جادویی: کاربر مجاز ؛ با استفاده از ابزاری مثل fwknop یا یک کلاینت اختصاصی، یک بسته UDP یا TCP حاوی اطلاعات احراز هویت را رمزنگاری و امضا شده به سرور می‌فرستد.
تشخیص روی سرور: سرویس SPA روی سرور (مثلاً fwknopd) بسته را باز میکند، امضا را بررسی میکند و در صورتی که معتبر بود، پورت مورد نظر را فقط برای همان IP باز میکند.
اعتبار موقت: این باز شدن فقط برای مدت کوتاهی فعال است و سپس به حالت “کاملاً نامرئی” برمی‌گردد.
چرا این روش بهتر از Port Knocking است؟
یک شلیک، یک ضربه: به جای چند پورت و دنباله پیچیده، همه چیز در یک بسته انجام می‌شود.
رمزنگاری: حتی اگر مهاجم ترافیک را شنود کند، الگو و محتوای Knock را نمی‌بیند.
امنیت در برابر Replay Attack: چون دارای زمان‌بندی و شماره‌یکتای احراز است، بازپخش آن بی‌فایده می‌ماند.
سازگاری با NAT و IPv6: برخلاف Port Knocking سنتی، اینجا مشکل آدرس‌های پویای پشت NAT کمتر است.
به زبان ساده، SPA مناسب برای محیط‌هایی که هم امنیت بالا می‌خواهند و هم سرویس‌ها باید کاملاً مخفی بمانند
#آکادمی_روزبه
Linkedin
#آکادمی_روزبه | Roozbeh Noroozi
بحث Port Knocking چیست؟
مقوله Port Knocking (به فارسی: در زدن به پورت) یک تکنیک امنیتی برای کنترل دسترسی به سرویس‌های شبکه است. در این روش، پورت‌های یک سرویس (مانند SSH روی پورت 22) به طور پیش‌فرض روی فایروال کاملاً بسته و غیرقابل دسترس هستند. برای باز شدن…
مقوله Port Knocking (به فارسی: در زدن به پورت) یک تکنیک امنیتی برای کنترل دسترسی به سرویس‌های شبکه است. در این روش، پورت‌های یک سرویس (مانند SSH روی پورت 22) به طور پیش‌فرض روی فایروال کاملاً بسته و غیرقابل دسترس هستند. برای باز شدن…
👍9👏2❤1
نرم‌افزار ایده‌آل برای بک‌دور در راستای DLL Sideloading باید این ویژگی‌ها را داشته باشد:
🔸️ماژولار : طبیعتاً برنامه باید چند فایل DLL داشته باشد که بتوانیم روی آنها بک‌دور قرار دهیم. منظور ما DLLهای اختصاصی خودِ نرم‌افزار است، نه DLLهای سیستمی.
🔸️قابل بارگذاری جانبی DLL (DLL Sideloadable) : برنامه باید زمانی که به مسیر دیگری منتقل می‌شود، در برابر تکنیک DLL sideloading آسیب‌پذیر باشد.
🔸️کوچک : فراموش نکنید که قرار است این را برای قربانی بفرستیم، پس حجم آن نباید 30 گیگابایت باشد.
🔸️محبوب :باید نرم‌افزاری رایج باشد، چیزی که سامانه EDR بارها و بارها در سراسر جهان دیده است. مثل ابزارهای فشرده‌سازی (۷zip، WinRAR)، ویرایشگرهای سبک (Notepad++)، نمایشگرهای PDF، یا نمایشگرهای تصویر.
🔸️دارای امضای دیجیتال (Digitally signed) : برنامه باید معتبر بوده و با گواهی دیجیتال معتبر امضا شده باشد.
#آکادمی_روزبه
🔸️ماژولار : طبیعتاً برنامه باید چند فایل DLL داشته باشد که بتوانیم روی آنها بک‌دور قرار دهیم. منظور ما DLLهای اختصاصی خودِ نرم‌افزار است، نه DLLهای سیستمی.
🔸️قابل بارگذاری جانبی DLL (DLL Sideloadable) : برنامه باید زمانی که به مسیر دیگری منتقل می‌شود، در برابر تکنیک DLL sideloading آسیب‌پذیر باشد.
🔸️کوچک : فراموش نکنید که قرار است این را برای قربانی بفرستیم، پس حجم آن نباید 30 گیگابایت باشد.
🔸️محبوب :باید نرم‌افزاری رایج باشد، چیزی که سامانه EDR بارها و بارها در سراسر جهان دیده است. مثل ابزارهای فشرده‌سازی (۷zip، WinRAR)، ویرایشگرهای سبک (Notepad++)، نمایشگرهای PDF، یا نمایشگرهای تصویر.
🔸️دارای امضای دیجیتال (Digitally signed) : برنامه باید معتبر بوده و با گواهی دیجیتال معتبر امضا شده باشد.
#آکادمی_روزبه
❤5🙏3
درس آموخته از یک حادثه امنیتی خاموش: وقتی ابزارهای قانونی به سلاح تبدیل می‌شوند
روزبه نوروزی
مقدمه: نگاهی به یک سناریوی نگران‌کننده
حدود شش ماه پیش، زمانی که در سازمان ..... مشغول به کار بودم، با یک سناریوی امنیتی مواجه شدیم که درک ما را از ماهیت تهدیدات داخلی و خارجی عمیقاً تغییر داد. این تجربه، که حول محور سوءاستفاده از ابزارهای معتبر و قانونی در حوزه فارنزیک دیجیتال می‌چرخید، به یک درس آموخته حیاتی برای تیم ما تبدیل شد. این مقاله به بازبینی آن حادثه و نتایج کلیدی آن می‌پردازد تا اهمیت نظارت پیشگیرانه و استراتژی‌های دفاعی مدرن را روشن سازد.
شرح واقعه: شناسایی یک فعالیت غیرعادی
همه چیز از یک هشدار در سیستم نظارت بر لاگ‌ها (SIEM) شروع شد. هشداری که در ابتدا ممکن بود به سادگی نادیده گرفته شود، اجرای چند دستور خاص در خط فرمان یکی از سرورهای کلیدی ما را نشان می‌داد:
# دستورات مشاهده شده در لاگ‌ها
winpmem_mini_x64_rc2.exe mem.raw
vol.exe -f .\mem.raw windows.cachedump.Cachedump
vol.exe -f .\mem.raw windows.Hashdump.Hashdump
برای یک فرد ناآشنا، این دستورات ممکن است بی‌خطر به نظر برسند. Winpmem و Volatility ابزارهای استاندارد و مورد احترام در جعبه‌ابزار هر متخصص پاسخ به رخداد و فارنزیک دیجیتال (DFIR) هستند. اما سوال کلیدی که ما از خود پرسیدیم این بود: "آیا در حال حاضر تیم امنیت در حال انجام تحلیل فارنزیک روی این سرور است؟"
پاسخ سریع و نگران‌کننده بود: "خیر."
هیچ‌کدام از اعضای تیم امنیت یا مدیران سیستم مجوزی برای چنین عملیاتی صادر نکرده بودند. این لحظه‌ای بود که فهمیدیم با یک تهدید جدی روبرو هستیم. یک عامل ناشناس (خواه یک مهاجم خارجی که به سیستم دسترسی پیدا کرده بود یا یک عامل داخلی مخرب) در حال استفاده از ابزارهای ما علیه خودمان بود.
تحلیل فنی تهدید: سرقت اعتبارنامه با ابزارهای قانونی (Living Off The Land)
تحقیقات ما نشان داد که مهاجم یک سناریوی کلاسیک سرقت اعتبارنامه (Credential Theft) را با استفاده از تکنیک "Living Off The Land" (LotL) پیاده‌سازی کرده بود. این رویکرد به مهاجمان اجازه میدهد تا با استفاده از ابزارهای قانونی و موجود در سیستم، از دید سیستم‌های امنیتی سنتی مانند آنتی‌ویروس‌ها پنهان بمانند.
1. winpmem ... mem.raw: در گام اول، مهاجم با استفاده ازWinpmem، یک کپی کامل از حافظه RAM سرور تهیه کرده بود. حافظه RAM گنجینه‌ای از اطلاعات حساس شامل کلیدهای رمزنگاری، داده‌های پردازش‌شده و از همه مهم‌تر، اعتبارنامه‌های کاربری (Username/Password Hashes) است.
2. vol.exe ... cachedump: سپس، با استفاده از فریم‌ورک قدرتمند Volatility، مهاجم پلاگین cachedump را روی فایل حافظه اجرا کرده بود تا هشِ پسوردهای کاربرانی که اخیراً به سیستم لاگین کرده بودند را استخراج کند.
3. vol.exe ... Hashdump: برای تکمیل کار، مهاجم با پلاگین Hashdump، هش پسوردهای تمام کاربران محلی را از پایگاه داده SAM که در حافظه بارگذاری شده بود، استخراج کرد.
هدف نهایی کاملاً مشخص بود: به دست آوردن هش‌های پسورد برای اجرای حملات Pass-the-Hash و حرکت جانبی (Lateral Movement) در شبکه، یا کرک کردن آنها به صورت آفلاین برای دستیابی به پسوردهای واقعی.
درس‌های آموخته کلیدی
این حادثه، که خوشبختانه به دلیل شناسایی به موقع مهار شد، سه درس حیاتی برای ما به همراه داشت:
۱. نظارت بر خط فرمان، یک ضرورت است نه یک گزینه:
بسیاری از سازمانها تنها فایل‌های اجرایی یا ترافیک شبکه را نظارت می‌کنند. این حادثه به ما آموخت که نظارت دقیق بر دستورات اجرا شده در
,Mimikatz و موارد مشابه، خارج از چارچوب یک تیکت پشتیبانی رسمی، تنظیم کردیم.
۲. آنتی‌ویروس به تنهایی کافی نیست:
خطر اصلی این حمله در "قانونی" بودن ابزارهای مورد استفاده نهفته بود. هیچ آنتی‌ویروسیWinpmem یا Volatility را به عنوان بدافزار شناسایی نمی‌کند، زیرا آنها ابزارهای قانونی هستند. این تجربه، محدودیت‌های رویکردهای مبتنی بر امضا (Signature-based) را به وضوح نشان داد و ما را به سمت راهکارهای دفاعی پیشرفته‌تر سوق داد.
۳. قدرت انکارناپذیر لیست سفید برنامه‌ها (Application Allowlisting):
پایان قسمت اول
روزبه نوروزی
مقدمه: نگاهی به یک سناریوی نگران‌کننده
حدود شش ماه پیش، زمانی که در سازمان ..... مشغول به کار بودم، با یک سناریوی امنیتی مواجه شدیم که درک ما را از ماهیت تهدیدات داخلی و خارجی عمیقاً تغییر داد. این تجربه، که حول محور سوءاستفاده از ابزارهای معتبر و قانونی در حوزه فارنزیک دیجیتال می‌چرخید، به یک درس آموخته حیاتی برای تیم ما تبدیل شد. این مقاله به بازبینی آن حادثه و نتایج کلیدی آن می‌پردازد تا اهمیت نظارت پیشگیرانه و استراتژی‌های دفاعی مدرن را روشن سازد.
شرح واقعه: شناسایی یک فعالیت غیرعادی
همه چیز از یک هشدار در سیستم نظارت بر لاگ‌ها (SIEM) شروع شد. هشداری که در ابتدا ممکن بود به سادگی نادیده گرفته شود، اجرای چند دستور خاص در خط فرمان یکی از سرورهای کلیدی ما را نشان می‌داد:
# دستورات مشاهده شده در لاگ‌ها
winpmem_mini_x64_rc2.exe mem.raw
vol.exe -f .\mem.raw windows.cachedump.Cachedump
vol.exe -f .\mem.raw windows.Hashdump.Hashdump
برای یک فرد ناآشنا، این دستورات ممکن است بی‌خطر به نظر برسند. Winpmem و Volatility ابزارهای استاندارد و مورد احترام در جعبه‌ابزار هر متخصص پاسخ به رخداد و فارنزیک دیجیتال (DFIR) هستند. اما سوال کلیدی که ما از خود پرسیدیم این بود: "آیا در حال حاضر تیم امنیت در حال انجام تحلیل فارنزیک روی این سرور است؟"
پاسخ سریع و نگران‌کننده بود: "خیر."
هیچ‌کدام از اعضای تیم امنیت یا مدیران سیستم مجوزی برای چنین عملیاتی صادر نکرده بودند. این لحظه‌ای بود که فهمیدیم با یک تهدید جدی روبرو هستیم. یک عامل ناشناس (خواه یک مهاجم خارجی که به سیستم دسترسی پیدا کرده بود یا یک عامل داخلی مخرب) در حال استفاده از ابزارهای ما علیه خودمان بود.
تحلیل فنی تهدید: سرقت اعتبارنامه با ابزارهای قانونی (Living Off The Land)
تحقیقات ما نشان داد که مهاجم یک سناریوی کلاسیک سرقت اعتبارنامه (Credential Theft) را با استفاده از تکنیک "Living Off The Land" (LotL) پیاده‌سازی کرده بود. این رویکرد به مهاجمان اجازه میدهد تا با استفاده از ابزارهای قانونی و موجود در سیستم، از دید سیستم‌های امنیتی سنتی مانند آنتی‌ویروس‌ها پنهان بمانند.
1. winpmem ... mem.raw: در گام اول، مهاجم با استفاده ازWinpmem، یک کپی کامل از حافظه RAM سرور تهیه کرده بود. حافظه RAM گنجینه‌ای از اطلاعات حساس شامل کلیدهای رمزنگاری، داده‌های پردازش‌شده و از همه مهم‌تر، اعتبارنامه‌های کاربری (Username/Password Hashes) است.
2. vol.exe ... cachedump: سپس، با استفاده از فریم‌ورک قدرتمند Volatility، مهاجم پلاگین cachedump را روی فایل حافظه اجرا کرده بود تا هشِ پسوردهای کاربرانی که اخیراً به سیستم لاگین کرده بودند را استخراج کند.
3. vol.exe ... Hashdump: برای تکمیل کار، مهاجم با پلاگین Hashdump، هش پسوردهای تمام کاربران محلی را از پایگاه داده SAM که در حافظه بارگذاری شده بود، استخراج کرد.
هدف نهایی کاملاً مشخص بود: به دست آوردن هش‌های پسورد برای اجرای حملات Pass-the-Hash و حرکت جانبی (Lateral Movement) در شبکه، یا کرک کردن آنها به صورت آفلاین برای دستیابی به پسوردهای واقعی.
درس‌های آموخته کلیدی
این حادثه، که خوشبختانه به دلیل شناسایی به موقع مهار شد، سه درس حیاتی برای ما به همراه داشت:
۱. نظارت بر خط فرمان، یک ضرورت است نه یک گزینه:
بسیاری از سازمانها تنها فایل‌های اجرایی یا ترافیک شبکه را نظارت می‌کنند. این حادثه به ما آموخت که نظارت دقیق بر دستورات اجرا شده در
Command Prompt، PowerShell و سایر Shell-ها یک لایه دفاعی حیاتی است. ابزارهایEDR (Endpoint Detection and Response) در این زمینه نقش کلیدی ایفا می‌کنند. ما بلافاصله قوانینی برای ایجاد هشدار فوری (Alert) هنگام اجرای ابزارهایی مانندWinpmem,Volatility,Mimikatz و موارد مشابه، خارج از چارچوب یک تیکت پشتیبانی رسمی، تنظیم کردیم.
۲. آنتی‌ویروس به تنهایی کافی نیست:
خطر اصلی این حمله در "قانونی" بودن ابزارهای مورد استفاده نهفته بود. هیچ آنتی‌ویروسیWinpmem یا Volatility را به عنوان بدافزار شناسایی نمی‌کند، زیرا آنها ابزارهای قانونی هستند. این تجربه، محدودیت‌های رویکردهای مبتنی بر امضا (Signature-based) را به وضوح نشان داد و ما را به سمت راهکارهای دفاعی پیشرفته‌تر سوق داد.
۳. قدرت انکارناپذیر لیست سفید برنامه‌ها (Application Allowlisting):
پایان قسمت اول
❤4👍4🔥3
قسمت دوم
مهم‌ترین درس آموخته، درک ارزش استراتژی Application Allowlisting بود. به جای تلاش برای شناسایی و مسدود کردن بی‌نهایت ابزار مخرب (Blacklisting)، ما باید به یک مدل "اعتماد صفر" (Zero Trust) روی بیاوریم. در این مدل، به طور پیش‌فرض اجرای تمام برنامه‌ها مسدود است، مگر آنکه صراحتاً در لیست برنامه‌های مجاز و ضروری کسب‌وکار قرار گرفته باشند. اگر چنین سیاستی در آن زمان پیاده‌سازی شده بود، مهاجم هرگز قادر به اجرای winpmem.exe یا vol.exe نبود و حمله در نطفه خفه می‌شد.
نتیجه‌گیری: از واکنش‌گرایی به پیشگیری
تجربه‌ی مواجهه با سوءاستفاده از ابزارهای DFIR، یک زنگ بیدارباش برای تیم ما بود. این حادثه نشان داد که مهاجمان مدرن، هوشمندانه عمل کرده و از نقاط کور امنیتی ما بهره‌برداری می‌کنند. ما آموختیم که دفاع مؤثر دیگر تنها به معنای مسدود کردن بدافزارها نیست، بلکه نیازمند درک عمیق "رفتار نرمال" در شبکه و ایجاد هشدار برای هرگونه انحراف از آن است. حرکت به سمت استراتژی‌های پیشگیرانه‌ای مانند Application Allowlisting و نظارت رفتاری، گام بعدی و ضروری برای تقویت وضعیت امنیتی هر سازمانی در برابر تهدیدات امروزی است.
#آکادمی_روزبه
ارائه درس سنر ۶۰۸ به همراه درس آموخته ها برای انتقال تجربیات به تمام کارشناسان سازمانها
مهم‌ترین درس آموخته، درک ارزش استراتژی Application Allowlisting بود. به جای تلاش برای شناسایی و مسدود کردن بی‌نهایت ابزار مخرب (Blacklisting)، ما باید به یک مدل "اعتماد صفر" (Zero Trust) روی بیاوریم. در این مدل، به طور پیش‌فرض اجرای تمام برنامه‌ها مسدود است، مگر آنکه صراحتاً در لیست برنامه‌های مجاز و ضروری کسب‌وکار قرار گرفته باشند. اگر چنین سیاستی در آن زمان پیاده‌سازی شده بود، مهاجم هرگز قادر به اجرای winpmem.exe یا vol.exe نبود و حمله در نطفه خفه می‌شد.
نتیجه‌گیری: از واکنش‌گرایی به پیشگیری
تجربه‌ی مواجهه با سوءاستفاده از ابزارهای DFIR، یک زنگ بیدارباش برای تیم ما بود. این حادثه نشان داد که مهاجمان مدرن، هوشمندانه عمل کرده و از نقاط کور امنیتی ما بهره‌برداری می‌کنند. ما آموختیم که دفاع مؤثر دیگر تنها به معنای مسدود کردن بدافزارها نیست، بلکه نیازمند درک عمیق "رفتار نرمال" در شبکه و ایجاد هشدار برای هرگونه انحراف از آن است. حرکت به سمت استراتژی‌های پیشگیرانه‌ای مانند Application Allowlisting و نظارت رفتاری، گام بعدی و ضروری برای تقویت وضعیت امنیتی هر سازمانی در برابر تهدیدات امروزی است.
#آکادمی_روزبه
ارائه درس سنر ۶۰۸ به همراه درس آموخته ها برای انتقال تجربیات به تمام کارشناسان سازمانها
❤7👏1
سناریوی حمله: ربودن syscall برای نامرئی شدن
یک ایده برای PoC
روزبه نوروزی
یک مهاجم حرفه‌ای می‌داند که مدیران سیستم از ابزارهایی مانند auditd برای نظارت بر فعالیت‌ها استفاده می‌کنند. auditd با نظارت بر فراخوان‌های سیستمی (syscalls) کار میکند. بنابراین، یک راه هوشمندانه برای دور زدن auditd، دستکاری خود فراخوان‌های سیستمی قبل از رسیدن به کرنل است. اینجاست که ptrace وارد بازی می‌شود.
هدف مهاجم: اجرای دستورات مخرب (مانند حذف یک فایل مهم) بدون اینکه auditd آن را ثبت کند.
مراحل حمله:
اجرای یک حامل (Carrier Process): مهاجم یک برنامه ساده را اجرا میکند. این برنامه قرار است به عنوان “ردیاب” عمل کند و فرآیند شل (مثلاً bash) را کنترل نماید.
کنترل شل با ptrace: برنامه حامل، فرآیند bash را با استفاده از ptrace(PTRACE_SYSCALL, ...) تحت کنترل خود در می‌آورد. این دستور به ردیاب اجازه میدهد تا درست قبل از اجرای یک فراخوان سیستمی و درست بعد از اتمام آن، اجرای فرآیند هدف (شل) را متوقف و آن را بازرسی کند.
رهگیری و تغییر فراخوان سیستمی:
مهاجم در شل کنترل‌شده‌ی خود، دستور rm /var/www/html/backup.zip را تایپ میکند.
شل bash تلاش میکند فراخوان سیستمی unlink یا unlinkat را برای حذف فایل فراخوانی کند.
قبل از اینکه این فراخوان به کرنل برسد، برنامه حامل (که با ptrace شل را کنترل میکند) اجرا را متوقف میکند.
برنامه حامل محتوای رجیسترها را بررسی میکند و می‌بیند که یک فراخوان unlinkat با آرگومان /var/www/html/backup.zip در حال اجرا است.
اینجا نقطه کلیدی است: برنامه حامل، شماره فراخوان سیستمی را در رجیستر مربوطه (مثلاً rax در x86-64) از شماره unlinkat به شماره یک فراخوان بی‌خطر مانند getpid تغییر میدهد!
سپس به فرآیند شل اجازه ادامه کار میدهد.
نتیجه چه می‌شود؟
از دید کرنل و auditd، فرآیند bash فقط فراخوان getpid را اجرا کرده است. بنابراین، auditd یک رویداد بی‌اهمیت را ثبت میکند (یا اصلاً ثبت نمی‌کند، بستگی به قوانین دارد).
اما در واقعیت، برنامه حامل که کنترل کامل روی حافظه bash دارد، مستقیماً و بدون استفاده از syscall، کد لازم برای حذف فایل را اجرا میکند یا از تکنیک دیگری برای پاک کردن آن بهره می‌برد.
پایان قسمت اول
حالا این ایده بنده هست اگر نقدی براون وارد هست پذیرا هستم.
**این ایده در سیستم های هاردن شده و دارای EDR قابلیت اجرا ندارد.
#آکادمی_روزبه
یک ایده برای PoC
روزبه نوروزی
یک مهاجم حرفه‌ای می‌داند که مدیران سیستم از ابزارهایی مانند auditd برای نظارت بر فعالیت‌ها استفاده می‌کنند. auditd با نظارت بر فراخوان‌های سیستمی (syscalls) کار میکند. بنابراین، یک راه هوشمندانه برای دور زدن auditd، دستکاری خود فراخوان‌های سیستمی قبل از رسیدن به کرنل است. اینجاست که ptrace وارد بازی می‌شود.
هدف مهاجم: اجرای دستورات مخرب (مانند حذف یک فایل مهم) بدون اینکه auditd آن را ثبت کند.
مراحل حمله:
اجرای یک حامل (Carrier Process): مهاجم یک برنامه ساده را اجرا میکند. این برنامه قرار است به عنوان “ردیاب” عمل کند و فرآیند شل (مثلاً bash) را کنترل نماید.
کنترل شل با ptrace: برنامه حامل، فرآیند bash را با استفاده از ptrace(PTRACE_SYSCALL, ...) تحت کنترل خود در می‌آورد. این دستور به ردیاب اجازه میدهد تا درست قبل از اجرای یک فراخوان سیستمی و درست بعد از اتمام آن، اجرای فرآیند هدف (شل) را متوقف و آن را بازرسی کند.
رهگیری و تغییر فراخوان سیستمی:
مهاجم در شل کنترل‌شده‌ی خود، دستور rm /var/www/html/backup.zip را تایپ میکند.
شل bash تلاش میکند فراخوان سیستمی unlink یا unlinkat را برای حذف فایل فراخوانی کند.
قبل از اینکه این فراخوان به کرنل برسد، برنامه حامل (که با ptrace شل را کنترل میکند) اجرا را متوقف میکند.
برنامه حامل محتوای رجیسترها را بررسی میکند و می‌بیند که یک فراخوان unlinkat با آرگومان /var/www/html/backup.zip در حال اجرا است.
اینجا نقطه کلیدی است: برنامه حامل، شماره فراخوان سیستمی را در رجیستر مربوطه (مثلاً rax در x86-64) از شماره unlinkat به شماره یک فراخوان بی‌خطر مانند getpid تغییر میدهد!
سپس به فرآیند شل اجازه ادامه کار میدهد.
نتیجه چه می‌شود؟
از دید کرنل و auditd، فرآیند bash فقط فراخوان getpid را اجرا کرده است. بنابراین، auditd یک رویداد بی‌اهمیت را ثبت میکند (یا اصلاً ثبت نمی‌کند، بستگی به قوانین دارد).
اما در واقعیت، برنامه حامل که کنترل کامل روی حافظه bash دارد، مستقیماً و بدون استفاده از syscall، کد لازم برای حذف فایل را اجرا میکند یا از تکنیک دیگری برای پاک کردن آن بهره می‌برد.
پایان قسمت اول
حالا این ایده بنده هست اگر نقدی براون وارد هست پذیرا هستم.
**این ایده در سیستم های هاردن شده و دارای EDR قابلیت اجرا ندارد.
#آکادمی_روزبه
👍9❤1👏1
📝 تجربه من با USN Journal در فارنزیک دیجیتال
در یکی از پروژه‌های تحلیل حادثه، به نقطه‌ای رسیدیم که لاگ‌های سنتی سیستم تقریباً پاک یا دستکاری شده بودند. برای یافتن رد مهاجم، سراغ USN Journal رفتیم؛ ژورنال سیستم NTFS که همه تغییرات فایل‌ها را حتی پس از حذف آنها؛ثبت میکند.
این کشف برایم شبیه ورق زدن دفترچه مخفی سیستم بود: هر ورودی، یک سرنخ از زمانی که فایلی ایجاد، ویرایش یا حذف شده است. با استفاده از ابزارهای متن‌باز مانند MFTECmd، توانستیم خط زمانی دقیقی از فعالیت مهاجم بسازیم؛ حتی لحظه نصب ابزارهای مخرب و پاک‌سازی آثار را بازیابی کردیم.
مهم‌ترین درس:
در فارنزیک، همیشه یک لایه عمیق‌تر وجود دارد. مهاجم ممکن است لاگ‌های رویداد را پاک کند، اما زیرساخت‌هایی مثل USN Journal را فراموش کند. از آن زمان، بررسی USN جزو چک‌لیست استاندارد من در تحلیل دیسک شد.
در دنیای امنیت، همان‌طور که در اقتصاد یا روانشناسی هم می‌بینیم، ردپاها معمولاً در جایی ماندگار می‌شوند که کمتر به چشم می‌آیند.
#آکادمی_روزبه
در یکی از پروژه‌های تحلیل حادثه، به نقطه‌ای رسیدیم که لاگ‌های سنتی سیستم تقریباً پاک یا دستکاری شده بودند. برای یافتن رد مهاجم، سراغ USN Journal رفتیم؛ ژورنال سیستم NTFS که همه تغییرات فایل‌ها را حتی پس از حذف آنها؛ثبت میکند.
این کشف برایم شبیه ورق زدن دفترچه مخفی سیستم بود: هر ورودی، یک سرنخ از زمانی که فایلی ایجاد، ویرایش یا حذف شده است. با استفاده از ابزارهای متن‌باز مانند MFTECmd، توانستیم خط زمانی دقیقی از فعالیت مهاجم بسازیم؛ حتی لحظه نصب ابزارهای مخرب و پاک‌سازی آثار را بازیابی کردیم.
مهم‌ترین درس:
در فارنزیک، همیشه یک لایه عمیق‌تر وجود دارد. مهاجم ممکن است لاگ‌های رویداد را پاک کند، اما زیرساخت‌هایی مثل USN Journal را فراموش کند. از آن زمان، بررسی USN جزو چک‌لیست استاندارد من در تحلیل دیسک شد.
در دنیای امنیت، همان‌طور که در اقتصاد یا روانشناسی هم می‌بینیم، ردپاها معمولاً در جایی ماندگار می‌شوند که کمتر به چشم می‌آیند.
#آکادمی_روزبه
❤10
ابزار، منتها را نشان نمیدهد؛ این «سؤال‌های درست پرسیدن» است که تحلیلگر واقعی می‌سازد.
چرا بعضی متخصصان امنیت با وجود دانش فنی، در تحلیل‌های امنیتی ضعف دارند؟
بر اساس مشاهداتم در دنیای SOC، DFIR و Threat Hunting، دلایل اصلی را می‌توان اینطور دسته‌بندی کرد:
۱. نگاه ابزاری به جای نگاه تحلیلی
بعضی‌ها یاد گرفته‌اند که با SIEM، EDR یا ابزارهای DFIR کار کنند، اما تحلیل را مساوی با خروجی ابزار می‌دانند. در واقع، ابزار فقط «چراغ‌قوه» است؛ مسیر و روایت را باید خود تحلیلگر بسازد.
۲. ضعف در مدل‌سازی ذهنی تهدید
بدون یک طرح ذهنی از مهاجم، تاکتیک‌ها و زنجیره حمله (Kill Chain / ATT&CK)، داده‌ها مثل تکه‌های پازل بی‌معنی به نظر می‌رسند. در نتیجه تحلیل‌ها سطحی می‌مانند.
۳. انتظار دیدن نشانه‌های واضح
حمله‌های مدرن معمولاً در لایه «تقریباً عادی» حرکت می‌کنند — مثل اجرای یک باینری مایکروسافت اما با تغییر جزئی. کسانی که فقط به دنبال «علامت خطر قرمز» هستند، اقدامات مخفی را نمی‌بینند.
۴. کمبود تجربه بین‌دامنه‌ای
تحلیل امنیتی فقط دانش سایبری نیست؛ باید کمی روانشناسی مهاجم، اقتصاد حملات (ROI)، و حتی الگوهای رفتاری کاربر را هم فهمید. این لایه‌ی شناخت، مهارت شناسایی الگو را چند برابر میکند.
۵. نبود تمرین حل مسئلهٔ خام
مثل عضلات بدن، ذهن تحلیلی هم با تمرین قوی می‌شود — مثلاً تحلیل لاگ خام، بررسی PCAP بدون فیلتر، یا شبیه‌سازی سناریوهای مبهم. بسیاری به خاطر عدم تمرین، در مواجهه با داده‌های بی‌ساختار قفل می‌کنند.
با آمدن مثلا اسپلانک ES یا UBA و همچنین مخازن سیگما ؛ عملا ذهن یوزکیس نویسان رو به تنبلی می‌گذارد.
#آکادمی_روزبه
چرا بعضی متخصصان امنیت با وجود دانش فنی، در تحلیل‌های امنیتی ضعف دارند؟
بر اساس مشاهداتم در دنیای SOC، DFIR و Threat Hunting، دلایل اصلی را می‌توان اینطور دسته‌بندی کرد:
۱. نگاه ابزاری به جای نگاه تحلیلی
بعضی‌ها یاد گرفته‌اند که با SIEM، EDR یا ابزارهای DFIR کار کنند، اما تحلیل را مساوی با خروجی ابزار می‌دانند. در واقع، ابزار فقط «چراغ‌قوه» است؛ مسیر و روایت را باید خود تحلیلگر بسازد.
۲. ضعف در مدل‌سازی ذهنی تهدید
بدون یک طرح ذهنی از مهاجم، تاکتیک‌ها و زنجیره حمله (Kill Chain / ATT&CK)، داده‌ها مثل تکه‌های پازل بی‌معنی به نظر می‌رسند. در نتیجه تحلیل‌ها سطحی می‌مانند.
۳. انتظار دیدن نشانه‌های واضح
حمله‌های مدرن معمولاً در لایه «تقریباً عادی» حرکت می‌کنند — مثل اجرای یک باینری مایکروسافت اما با تغییر جزئی. کسانی که فقط به دنبال «علامت خطر قرمز» هستند، اقدامات مخفی را نمی‌بینند.
۴. کمبود تجربه بین‌دامنه‌ای
تحلیل امنیتی فقط دانش سایبری نیست؛ باید کمی روانشناسی مهاجم، اقتصاد حملات (ROI)، و حتی الگوهای رفتاری کاربر را هم فهمید. این لایه‌ی شناخت، مهارت شناسایی الگو را چند برابر میکند.
۵. نبود تمرین حل مسئلهٔ خام
مثل عضلات بدن، ذهن تحلیلی هم با تمرین قوی می‌شود — مثلاً تحلیل لاگ خام، بررسی PCAP بدون فیلتر، یا شبیه‌سازی سناریوهای مبهم. بسیاری به خاطر عدم تمرین، در مواجهه با داده‌های بی‌ساختار قفل می‌کنند.
با آمدن مثلا اسپلانک ES یا UBA و همچنین مخازن سیگما ؛ عملا ذهن یوزکیس نویسان رو به تنبلی می‌گذارد.
#آکادمی_روزبه
❤5👍4
دیده شده که کلی پکیج آلوده هستند. من با THOR اسکن کردم فعلا چیزی پیدا نکردم ولی بهوش باشید
لینک خبر
https://lnkd.in/dJSmhCxt
کیا مواظب باشند ؟
توسعه‌دهندگان یا تیم‌هایی که از Node.js و npm برای ساخت سایت، سرویس یا ابزار استفاده می‌کنند.
کسانی که CI/CD (خط خودکار build و deploy) دارند و به‌صورت خودکار آخرین نسخه پکیج‌ها را می‌گیرند، چون آلودگی خیلی سریع وارد فرآیند عملیاتی می‌شود.
حتی اگر مستقیم از این پکیج‌ها استفاده نکنید، ممکن است به‌صورت غیرمستقیم (dependency) داخل پکیج‌های دیگر باشند.
#آکادمی_روزبه
لینک خبر
https://lnkd.in/dJSmhCxt
کیا مواظب باشند ؟
توسعه‌دهندگان یا تیم‌هایی که از Node.js و npm برای ساخت سایت، سرویس یا ابزار استفاده می‌کنند.
کسانی که CI/CD (خط خودکار build و deploy) دارند و به‌صورت خودکار آخرین نسخه پکیج‌ها را می‌گیرند، چون آلودگی خیلی سریع وارد فرآیند عملیاتی می‌شود.
حتی اگر مستقیم از این پکیج‌ها استفاده نکنید، ممکن است به‌صورت غیرمستقیم (dependency) داخل پکیج‌های دیگر باشند.
#آکادمی_روزبه
LinkedIn
#malware #npm #supplychain #infosec #appsec #applicationsecurity | Mackenzie Jackson | 198 comments
🚨 URGENT: I can't write much..... but... the largest supply chain compromise in npm, Inc. history just happened, packages with a total of 2 billion weekly downloads just got turned malicious.....
Packages were compromised 1 hour ago. Please share urgently…
Packages were compromised 1 hour ago. Please share urgently…
⚡7
Evaluation of LLM Agents for the SOC Tier 1 Analyst Triage.pdf
1.6 MB
موضوع تحقیق:
مدلهای زبانی در SOC لایه ۱
۵ مدل LLM (مثل GPT‑4o، LLaMA 3، Mixtral، و چند مدل دیگر) را تست کرده‌اند.
وظیفه: تشخیص اینکه هشدارهای امنیتی شبیه‌سازی‌شده «جالب» (یعنی نیازمند پیگیری) هستند یا «بی‌اهمیت».
محیط تست: SOC شبیه‌سازی‌شده با Wazuh و CALDERA.
نتایج کلیدی:
این LLMها می‌توانند triage اولیه را سریع‌تر کنند و فشار فکری روی آنالیست را کاهش دهند.
با زبان طبیعی، توضیح می‌دهند چرا تصمیمی گرفته‌اند — این برای تصمیم‌گیری کمک میکند.
هنوز چالش‌ها وجود دارد:
مسأله Hallucination (پاسخ اشتباه ولی با اطمینان)،
پیچیدگی ادغام در سیستم‌های موجود،
ریسک حریم خصوصی.
نتیجه‌گیری:
این مدل‌ها جایگزین آنالیست انسانی نمی‌شوند.
ولی به عنوان دستیار (copilot) می‌توانند کار SOC را سریع‌تر، کارآمدتر و مقاوم‌تر کنند
#آکادمی_روزبه
مدلهای زبانی در SOC لایه ۱
۵ مدل LLM (مثل GPT‑4o، LLaMA 3، Mixtral، و چند مدل دیگر) را تست کرده‌اند.
وظیفه: تشخیص اینکه هشدارهای امنیتی شبیه‌سازی‌شده «جالب» (یعنی نیازمند پیگیری) هستند یا «بی‌اهمیت».
محیط تست: SOC شبیه‌سازی‌شده با Wazuh و CALDERA.
نتایج کلیدی:
این LLMها می‌توانند triage اولیه را سریع‌تر کنند و فشار فکری روی آنالیست را کاهش دهند.
با زبان طبیعی، توضیح می‌دهند چرا تصمیمی گرفته‌اند — این برای تصمیم‌گیری کمک میکند.
هنوز چالش‌ها وجود دارد:
مسأله Hallucination (پاسخ اشتباه ولی با اطمینان)،
پیچیدگی ادغام در سیستم‌های موجود،
ریسک حریم خصوصی.
نتیجه‌گیری:
این مدل‌ها جایگزین آنالیست انسانی نمی‌شوند.
ولی به عنوان دستیار (copilot) می‌توانند کار SOC را سریع‌تر، کارآمدتر و مقاوم‌تر کنند
#آکادمی_روزبه
👍6⚡2
بلوغ شناسایی تهدید با کمک AI در XDR
استفاده طولانی‌مدت از پلتفرم‌هایی مانند Trend Micro Vision One که با آنها کار کرده ام ، تنها به معنی داشتن ابزار بهتر نیست؛ بلکه فرصتی برای ساخت یک «ماشین شناسایی دقیق» فراهم میکند.
در ماه‌های ابتدایی، سیستم AI سعی میکند از میان داده‌های لایه‌های مختلف (ایستگاه کاری، سرور، ایمیل، شبکه و غیره) الگو بسازد. این مرحله پر از نویز است، اما تدریجاً یک Baseline از رفتار عادی سازمان شکل می‌گیرد.
با گذشت زمان و بازخورد مداوم تیم SOC، مدلهای هوش مصنوعی نه‌تنها رفتارهای عمومی تهدیدات، بلکه نشانه‌های خاص حمله‌گر به سازمان شما را نیز یاد می‌گیرند. هم‌زمان، همبستگی رویدادها (Event Correlation) عمیق‌تر می‌شود و داده‌های بین لایه‌ای تصویر کامل‌تری از زنجیره حمله ارائه می‌دهند.
نتیجه این بلوغ تدریجی؟
وجود True Positive بالاتر و کاهش آلارم‌های اشتباه.
و MTTD کوتاه‌تر و واکنش سریع‌تر.
شناسایی تهدیدات پیچیده‌ای که در شروع کار از چشم پنهان می‌ماندند.
این روند را می‌توان در «منحنی بلوغ شناسایی» دید؛ جایی که از یادگیری اولیه تا شناسایی هوشمند، فاصله‌ای پر از داده، تجربه و تعامل انسان و AI پیموده می‌شود
#آکادمی_روزبه
استفاده طولانی‌مدت از پلتفرم‌هایی مانند Trend Micro Vision One که با آنها کار کرده ام ، تنها به معنی داشتن ابزار بهتر نیست؛ بلکه فرصتی برای ساخت یک «ماشین شناسایی دقیق» فراهم میکند.
در ماه‌های ابتدایی، سیستم AI سعی میکند از میان داده‌های لایه‌های مختلف (ایستگاه کاری، سرور، ایمیل، شبکه و غیره) الگو بسازد. این مرحله پر از نویز است، اما تدریجاً یک Baseline از رفتار عادی سازمان شکل می‌گیرد.
با گذشت زمان و بازخورد مداوم تیم SOC، مدلهای هوش مصنوعی نه‌تنها رفتارهای عمومی تهدیدات، بلکه نشانه‌های خاص حمله‌گر به سازمان شما را نیز یاد می‌گیرند. هم‌زمان، همبستگی رویدادها (Event Correlation) عمیق‌تر می‌شود و داده‌های بین لایه‌ای تصویر کامل‌تری از زنجیره حمله ارائه می‌دهند.
نتیجه این بلوغ تدریجی؟
وجود True Positive بالاتر و کاهش آلارم‌های اشتباه.
و MTTD کوتاه‌تر و واکنش سریع‌تر.
شناسایی تهدیدات پیچیده‌ای که در شروع کار از چشم پنهان می‌ماندند.
این روند را می‌توان در «منحنی بلوغ شناسایی» دید؛ جایی که از یادگیری اولیه تا شناسایی هوشمند، فاصله‌ای پر از داده، تجربه و تعامل انسان و AI پیموده می‌شود
#آکادمی_روزبه
❤7
روشهای من برای منتورینگ یکساله دوره آمادگی آزمون CISSP
قسمت اول
مدل انگیزه‌سازی CISSP بر اساس Hyperbolic Discounting
الهام از اقتصاد + روانشناسی
1. تقسیم هدف بزرگ به “کمپین‌های کوچک با پاداش سریع”
به جای گفتن «۶ ماه بخونیم تا مدرک رو بگیرید»، مسیر رو به ۶ ماژول ۳–۴ هفته‌ای تقسیم میکنیم
هر ماژول با یک مینی‌پروژه یا کوییز سخت جمع‌بندی میشه و در پایان، یک جایزه کوچک (گواهی داخلی، یادگاری، یا حتی یک افتخارنامه گروهی در چت کلاس).
2. اثر Snowball پیشرفت
یک «برد پیشرفت فیزیکی» یا آنلاین درست میکنم که دانشجو هر هفته آن را به‌روزرسانی میکند.
دیدن درصد پیشرفت روی نمودار حس رضایت آنی میدهد (پاداش سریع)، حتی اگر آزمون اصلی ماه‌ها بعد باشد.
3. پاداش هم‌زمانی و رقابت سالم
بین کلاسهای هرسال، گروه‌های مطالعه ۳–۴ نفره ایجاد میکنم که عملکردشان مقایسه شود.
رقابت سالم، مغز را مجبور میکند لذت کوتاه‌مدت «پیشی گرفتن» را بالاتر از لذت تنبلی ببیند.
4. استفاده از اصل Loss Aversion
سیستم تعهد مالی یا امتیازی: دانشجو مبلغ یا اعتبار امتیازی می‌گذارد و اگر هفته‌ای حداقل مطالعه را انجام ندهد، آن را از دست میدهد.
این بهره‌گیری از ترسِ از دست دادن (نه فقط امید به کسب) انگیزه‌ی پایدارتری ایجاد میکند.
5. نمایش “پاداش نهایی” به صورت واقعی و زنده
هر ترم یک مهمان (CISSP دار) را دعوت میکنم تا داستان شغل و درآمدش را تعریف کند.
این کار پاداش نهایی را از یک تصویر مبهم به یک انگیزه ملموس و فوری تبدیل میکند.
6. مینی‌پیش‌بینی آزمون (Micro-Exam Forecasting)
هر سه ماه یک شبیه‌سازی کوتاه آزمون میدهم و رشد امتیاز را نمایش میدهم .
مغز وقتی نمودار نمره‌اش رو به بالا می‌بیند، حس «پاداش همین الان» را تجربه میکند.
**این روش بخشی از روش منتوینگ من است که برای دوستانی اجرا می‌شود که تعهد برای آزمون دارند .
واتس اپ و بله برای رزرو دوره زمستان : 09902857290
Www.haumoun.com
Www.Roozbeh.academy
قسمت اول
مدل انگیزه‌سازی CISSP بر اساس Hyperbolic Discounting
الهام از اقتصاد + روانشناسی
1. تقسیم هدف بزرگ به “کمپین‌های کوچک با پاداش سریع”
به جای گفتن «۶ ماه بخونیم تا مدرک رو بگیرید»، مسیر رو به ۶ ماژول ۳–۴ هفته‌ای تقسیم میکنیم
هر ماژول با یک مینی‌پروژه یا کوییز سخت جمع‌بندی میشه و در پایان، یک جایزه کوچک (گواهی داخلی، یادگاری، یا حتی یک افتخارنامه گروهی در چت کلاس).
2. اثر Snowball پیشرفت
یک «برد پیشرفت فیزیکی» یا آنلاین درست میکنم که دانشجو هر هفته آن را به‌روزرسانی میکند.
دیدن درصد پیشرفت روی نمودار حس رضایت آنی میدهد (پاداش سریع)، حتی اگر آزمون اصلی ماه‌ها بعد باشد.
3. پاداش هم‌زمانی و رقابت سالم
بین کلاسهای هرسال، گروه‌های مطالعه ۳–۴ نفره ایجاد میکنم که عملکردشان مقایسه شود.
رقابت سالم، مغز را مجبور میکند لذت کوتاه‌مدت «پیشی گرفتن» را بالاتر از لذت تنبلی ببیند.
4. استفاده از اصل Loss Aversion
سیستم تعهد مالی یا امتیازی: دانشجو مبلغ یا اعتبار امتیازی می‌گذارد و اگر هفته‌ای حداقل مطالعه را انجام ندهد، آن را از دست میدهد.
این بهره‌گیری از ترسِ از دست دادن (نه فقط امید به کسب) انگیزه‌ی پایدارتری ایجاد میکند.
5. نمایش “پاداش نهایی” به صورت واقعی و زنده
هر ترم یک مهمان (CISSP دار) را دعوت میکنم تا داستان شغل و درآمدش را تعریف کند.
این کار پاداش نهایی را از یک تصویر مبهم به یک انگیزه ملموس و فوری تبدیل میکند.
6. مینی‌پیش‌بینی آزمون (Micro-Exam Forecasting)
هر سه ماه یک شبیه‌سازی کوتاه آزمون میدهم و رشد امتیاز را نمایش میدهم .
مغز وقتی نمودار نمره‌اش رو به بالا می‌بیند، حس «پاداش همین الان» را تجربه میکند.
**این روش بخشی از روش منتوینگ من است که برای دوستانی اجرا می‌شود که تعهد برای آزمون دارند .
واتس اپ و بله برای رزرو دوره زمستان : 09902857290
Www.haumoun.com
Www.Roozbeh.academy
❤4👍4🔥2👏1
مقاله «Practical .NET Malware Analysis – First-Stage Loader (Part 1)» نوشته Ab Hussain، یک مطالعه عملی روی تحلیل بدافزارهای نوشته‌شده با .NET است که نقش لودر مرحله اول را دارند. لودر مرحله اول اولین کد مخربی است که پس از اجرای فایل آلوده عمل میکند و وظیفه‌اش دریافت یا بارگذاری مرحله‌های بعدی حمله، پنهان‌سازی ردپا و آماده‌سازی محیط برای اجرای Payload اصلی است.
نویسنده فایل را در محیط ایزوله بررسی کرده و با ابزارهایی مانند dnSpy و ILSpy کد .NET را دی‌کامپایل کرده است. این لودر با obfuscation سنگین و رشته‌های رمزنگاری‌شده سعی در گمراه‌کردن تحلیلگر دارد. با رفع رمز رشته‌ها، آدرس دامنه C2 و جزئیات ارتباطات کشف شده است. لودر از APIهای Win32 مثل VirtualAlloc و CreateThread استفاده میکند تا payload مرحله دوم را مستقیماً در حافظه تزریق و اجرا کند، بدون ایجاد فایل روی دیسک؛ روشی که شناسایی توسط آنتی‌ویروس سنتی را دشوار میکند.
نتیجه اصلی مقاله این است که بدافزارهای .NET می‌توانند با ترکیب کد Managed و API سطح پایین، لودری بسیار خطرناک بسازند. شناسایی این نوع تهدیدها نیازمند مانیتورینگ رفتار حافظه، تحلیل تماس‌های شبکه، و شکار تهدید مبتنی بر EDR با قوانین YARA یا IOC هدفمند است.
#آکادمی_روزبه
https://medium.com/@Ab_Hussain/practical-net-malware-analysis-first-stage-loader-part-1-f2e670861678
نویسنده فایل را در محیط ایزوله بررسی کرده و با ابزارهایی مانند dnSpy و ILSpy کد .NET را دی‌کامپایل کرده است. این لودر با obfuscation سنگین و رشته‌های رمزنگاری‌شده سعی در گمراه‌کردن تحلیلگر دارد. با رفع رمز رشته‌ها، آدرس دامنه C2 و جزئیات ارتباطات کشف شده است. لودر از APIهای Win32 مثل VirtualAlloc و CreateThread استفاده میکند تا payload مرحله دوم را مستقیماً در حافظه تزریق و اجرا کند، بدون ایجاد فایل روی دیسک؛ روشی که شناسایی توسط آنتی‌ویروس سنتی را دشوار میکند.
نتیجه اصلی مقاله این است که بدافزارهای .NET می‌توانند با ترکیب کد Managed و API سطح پایین، لودری بسیار خطرناک بسازند. شناسایی این نوع تهدیدها نیازمند مانیتورینگ رفتار حافظه، تحلیل تماس‌های شبکه، و شکار تهدید مبتنی بر EDR با قوانین YARA یا IOC هدفمند است.
#آکادمی_روزبه
https://medium.com/@Ab_Hussain/practical-net-malware-analysis-first-stage-loader-part-1-f2e670861678
Medium
Practical .NET Malware Analysis — First Stage Loader(Part 1)
Disclaimer: This blog post involves analysis of real malware sample for educational purposes only. The malware discussed is highly…
❤4
ما برنامه ریزی کرده‌ایم که در ذیل مجوز افتا ؛ درشرکت هامون ارائه خدمات SOC را تحت نظر اینجانب داشته باشیم .
نکات مهمی که ما در پیاده سازی بدانها توجه میکنیم را در ذیل می‌آورم
الف:
اگر مشکلی در Compliance نباشد ، به جای جمع‌آوری هر نوع لاگی (verbose logging)، ابتدا میپرسیم : “برای شناسایی تکنیک‌های خاص حمله (مثلاً تکنیک‌های چارچوب MITRE ATT&CK)، دقیقاً به چه داده‌هایی نیاز داریم؟” این سوال، رویکرد ما را از جمع‌آوری کورکورانه به جمع‌آوری هدفمند تغییر میدهد .
مثلاً برای شناسایی حرکت جانبی (Lateral Movement) با استفاده از PsExec، به لاگ‌های ایجاد سرویس (Event ID 7045) و لاگ‌های دسترسی به admin$ share روی سیستم مقصد نیاز داریم. بدون این‌ها، هزاران گیگابایت لاگ دیگر بی‌فایده خواهد بود.
Www.haumoun.com
ادامه دارد ....
نکات مهمی که ما در پیاده سازی بدانها توجه میکنیم را در ذیل می‌آورم
الف:
اگر مشکلی در Compliance نباشد ، به جای جمع‌آوری هر نوع لاگی (verbose logging)، ابتدا میپرسیم : “برای شناسایی تکنیک‌های خاص حمله (مثلاً تکنیک‌های چارچوب MITRE ATT&CK)، دقیقاً به چه داده‌هایی نیاز داریم؟” این سوال، رویکرد ما را از جمع‌آوری کورکورانه به جمع‌آوری هدفمند تغییر میدهد .
مثلاً برای شناسایی حرکت جانبی (Lateral Movement) با استفاده از PsExec، به لاگ‌های ایجاد سرویس (Event ID 7045) و لاگ‌های دسترسی به admin$ share روی سیستم مقصد نیاز داریم. بدون این‌ها، هزاران گیگابایت لاگ دیگر بی‌فایده خواهد بود.
Www.haumoun.com
ادامه دارد ....
❤9