آکادمی آموزش روزبه 📚
الذهاب إلى القناة على Telegram
🍎آموزش و ترویج علمی فناوری اطلاعات ، امنیت و مدیریت پروژه های مرتبط 🍁 و کمی هم اخلاق و انسانیت Training of Information Technology, Cyber Security, Project Management, Ethics and Humanitarian ارتباط با مدیر کانال: @roozbehadm
إظهار المزيدلم يتم تحديد البلدالفئة غير محددة
3 982
المشتركون
+224 ساعات
+47 أيام
+3530 أيام
أرشيف المشاركات
3 982
#نکته_روز
اونقدر در یک گرایش غرق نشین که یهو سر بالا کنین ببینین از روزگار حذف شدین !!
واسه همینه هر از چند گاهی یه دوری به سایر گرایش های امنیت هم میزنیم
3 982
مهندسی کشف
پنهانسازی DLL؛ تفاوت میان فهرست ماژولها و واقعیت حافظه
مقاله پاول یوسیفوویچ توضیح میدهد چگونه میتوان یک DLL بارگذاریشده در فرایندی دیگر را از فهرست ماژولهای آن پنهان کرد؛ بدون اینکه DLL از حافظه خارج شود. مبنای روش، دستکاری فهرستهای پیوندی متعلق به Loader در ساختار PEB است. با حذف ارتباط ورودی ماژول از فهرست، ابزارهای متکی بر آن دیگر DLL را گزارش نمیکنند.
چالش اصلی، عبور از مرز فضای آدرس فرایندهاست. اشارهگری که در فرایند هدف معتبر است، در فرایند اجراکننده الزاماً معنایی ندارد؛ بنابراین ساختارها باید با ReadProcessMemory به حافظه محلی خوانده شوند و تغییرات با WriteProcessMemory اعمال شوند. آدرس PEB هدف نیز از طریق NtQueryInformationProcess دریافت میشود.
نویسنده بر کنترل تعداد واقعی بایتهای منتقلشده، خواندن جداگانه محتوای رشتههای UNICODE_STRING و بررسی آدرسها با ابزار متصل به فرایند هدف تأکید میکند. در آزمایش، DLL از خروجی EnumProcessModules و پیمایش مستقیم PEB ناپدید میشود.
پیام دفاعی مهم این است که ناپدیدشدن از فهرست، به معنای نبودن در حافظه نیست. در نتیجه، اتکای انحصاری به فهرست Loader نقطه کور ایجاد میکند. مقایسه این فهرست با نگاشت واقعی حافظه، مانند بررسی مبتنی بر VirtualQueryEx، میتواند ناسازگاری را آشکار کند. این روش، فراداده مشاهدهپذیری را تغییر میدهد و بهخودیخود DLL را تزریق، تخلیه یا اجرای آن را متوقف نمیکند.
منبع: مقاله TrainSec
دوره مهندسی کشف آکادمی روزبه با تیم MSSP شرکت هامون با پوشش صد در صدی مفاهیم
دیماه 09902857290 واتس اپ
https://trainsec.net/library/malware-analysis/hiding-a-dll-in-another-process-cross-process-peb-unlinking-explained/
3 982
هشدارهای متعدد، همیشه به معنی رخدادهای متعدد نیستند!
یکی از قابلیتهایی که در Splunk ES 8.8 توجه را جلب کرد، Investigation Aggregation است؛ قابلیتی برای کنار هم قرار دادن یافتههای مرتبط در یک پرونده تحقیق.
فرض کنید برای یک کاربر، ورود مشکوک ثبت شده، روی لپتاپش PowerShell مشکوک اجرا شده و همان دستگاه با یک دامنه مخرب ارتباط گرفته است. بررسی جداگانه این هشدارها، بخشی از وقت تحلیلگر را صرف پیدا کردن ارتباط میان شواهد میکند.
اینجاست که نحوه تنظیم این قابلیت اهمیت پیدا میکند.
در مسیر زیر، ابتدا قابلیت را فعال میکنیم؛ چون بهصورت پیشفرض خاموش است:
Configure → Findings and investigations → Investigation aggregation
سپس مشخص میکنیم تجمیع داخل یک صف تیمی انجام شود یا میان چند صف. قواعد آمادهای مثل Entity مشترک، Threat Object مشترک و فرستنده مشترک ایمیل فیشینگ وجود دارند؛ امکان تعریف قواعد اختصاصی و تغییر اولویت آنها هم فراهم است.
پس از فعالسازی، یافتههای جدید بر اساس این قواعد به پروندهها هدایت میشوند. یافتههای قبلی خودکار تجمیع نمیشوند.
نکته مهم این است: تعداد هشدارها لزوماً کمتر نمیشود؛ اما بررسیهای پراکنده و تکراری میتواند کاهش پیدا کند.
البته کیفیت نتیجه به قواعد بستگی دارد؛ کنار هم گذاشتن هشدارهای نامرتبط، فقط پروندهای شلوغتر میسازد!
3 982
راه حلی از موسسه استاندارد آمریکا برای جهان کوانتومی و خطرات آن
آیا ما آشنا هستیم ؟
https://www.nist.gov/news-events/news/2026/10/nist-report-provides-guidelines-transition-post-quantum-cryptography
3 982
Edit, Sign and Share PDF files on the go. Download the Acrobat Reader app: https://adobeacrobat.app.link/Mhhs4GmNsxb
3 982
نصب و تیونینگ اسپلانک ( نه تحلیلگری ) شده ساعتی ۴ م تومان
نمیخواین در این حوزه شاغل شوید ؟
هیچ پیش نیاز امنیتی هم نمیخواد
3 982
وقتی Splunk ES سالم است، اما حمله را نمیبیند
در سناریوی بازسازیشده از عیبیابی ES، لاگهای ورود ناموفق ویندوز دریافت میشدند، تعدادشان از آستانه تشخیص عبور میکرد و Correlation Search نیز موفق اجرا میشد؛ اما هشداری تولید نمیشد. عجیبتر اینکه همان جستوجو، کمی دیرتر و بهصورت دستی، نتیجه میداد.
این تناقض، سؤال اصلی را تغییر داد: آیا مشکل در SPL بود، یا داده هنگام اجرای تشخیص هنوز آماده نبود؟
ابتدا استخراج فیلدها، انطباق با CIM، قیود Data Model، دسترسی کاربر اجراکننده و محدوده زمانی بررسی شدند. سرنخ اصلی در tstats و تنظیم summariesonly=true بود: جستوجو فقط خلاصههای شتابدهیشده را میخواند. بنابراین وجود لاگ در ایندکس، دیدهشدن آن در مسیر تشخیص را تضمین نمیکرد.
مقایسه خروجی جستوجو با summariesonly=true و summariesonly=false روی بازهای ثابت، اختلاف نشان داد. سپس سه زمان کنار هم قرار گرفتند: وقوع رویداد، ایندکسشدن و قابلجستوجوشدن در خلاصهها.
رویدادی ساعت ۱۰:۰۲ رخ داده، ۱۰:۰۸ ایندکس شده و بعدتر وارد خلاصهها شده بود؛ اما قاعده هر پنج دقیقه، فقط پنج دقیقه گذشته را بررسی میکرد. هنگام اجرای اول، داده نرسیده بود؛ هنگام اجرای بعدی، زمان وقوعش از پنجره خارج شده بود.
بررسی scheduler.log نیز رقابت منابع و اجرای Skipشده بعضی جستوجوهای شتابدهی را آشکار کرد.
راهحل، صرفاً تغییر کوئری نبود: تأخیر منابع اندازهگیری شد، زمانبندی جستوجوهای سنگین توزیع شد و پنجره تشخیص با تأخیر واقعی داده تطبیق یافت. برای پنجرههای همپوشان نیز کنترل تکرار هشدار تعریف شد، بدون آنکه فعالیت مستقل بعدی پنهان شود.
پذیرش نهایی با بازاجرای سناریو و سنجش زمان رسیدن هشدار انجام شد؛ نه صرفاً مشاهده اجرای موفق Search.
درس مهم: نتیجه نداریم ، الزاماً یعنی صفر تهدید نیست؛ گاهی داده و منطق درست، در زمان مناسب به هم نمیرسند.
#Splunk #SplunkES #SOC #DetectionEngineering #Troubleshooting #CIM #SIEM
3 982
حمله با آسیب پذیری جدید PHP را کنترل کنید
متریال Splunk ES در لینک زیر فراهم است
https://splunkbase.splunk.com/app/3449
3 982
Edit, Sign and Share PDF files on the go. Download the Acrobat Reader app: https://adobeacrobat.app.link/Mhhs4GmNsxb
3 982
پیرو این پست ، تعدادی از دوستان جویای کلاس اسپلانک شدند
امکان برگزاری هست با استخدام تضمینی و اگر هم تا حدودی بلد باشید امکان جذب با حقوق خوب
اما برای تشکیل کلاس باید به حد نصاب برسد
در واتس اپ زیر رزرو کنید تاخبر کنیم 09902857290
3 982
👆👆ترجمه :
در طول مسیر حرفهایام، افتخار آشنایی با معدود متخصصانی را داشتهام که نهتنها دانش و تجربه خود را با اشتیاق به اشتراک میگذارند، بلکه نگاه مرا نیز شکل دادهاند. روزبه نوروزی، دارنده مدارک CISSP و PMP، یکی از همین افراد است؛ متخصصی متعهد و آیندهنگر در حوزه امنیت سایبری در ایران که ۱۵ سال است مدرک CISSP دارد و عضو ISC2 است! بله، درست خواندید؛ ۱۵ سال. او یکی از نخستین دارنده مدرک CISSP در کشور من بود.
من نخستین بار از طریق او با ISC2 و CISSP آشنا شدم؛ اما آنچه بیش از همه در ذهنم ماند، رویکرد او به امنیت بود.
زمانی که بیشتر افراد بر اصطلاحات پرطرفداری مانند فایروال نسل جدید و سامانههای تشخیص و جلوگیری از نفوذ تمرکز داشتند، او بر اهمیت چرخه عمر توسعه نرمافزار، SDLC، تأکید میکرد.
پیش از شرکت در آزمون، دورهای را با او گذراندم. در آن دوره، درسی را بهخوبی در ذهنم جا انداخت که همچنان همراه من است: به هر سؤال از دریچه ریسک و با ذهنیت یک مشاور سیاستگذاری نگاه کنید. همین نگاه، راهگشا شد.
روزبه، سپاسگزارم که مرا نهفقط با ISC2 و CISSP، بلکه با شیوهای از تفکر درباره امنیت آشنا کردی که در سراسر مسیر حرفهایام همراه من بوده است.
همچنین مفتخرم اعلام کنم که اکنون رسماً به جمع جامعه دارندگان CISSP در ISC2 پیوستهام.
#Cybersecurity #CISSP #ISC2 #RiskBasedSecurity
3 982
از دانشجویان آکادمی روزبه که در آزمون رسمی CISSP قبول شده اند
با تبریک به ایشان و آرزوی موفقیت .
این آزمون را میتوان سخت ترین آزمون دنیای فناوری دانست که قبولی در آن به مطالعه فراوان، تجربه عملیاتی و ممارست نیاز است.
دوره بعدی CISSP دیماه
قبول شوید
3 982
#امنیت_به_زبان_ساده
سرویس WinRM (Windows Remote Management) سرویس مدیریت از راه دور ویندوز است؛ به ادمین اجازه میدهد از طریق شبکه، روی سیستمهای دیگر فرمان اجرا کند، اطلاعات بگیرد و تنظیمات را مدیریت کند. PowerShell Remoting معمولاً از WinRM استفاده میکند.
پورتهای پیشفرض آن عبارتاند از:
- TCP 5985: ارتباط HTTP
- TCP 5986: ارتباط HTTPS
هکر با آن چه میکند؟ اگر مهاجم اعتبارنامه معتبر و مجوز لازم برای اتصال داشته باشد، میتواند از WinRM برای این کارها استفاده کند:
- حرکت جانبی: از سیستم اولیه به سرورها و سیستمهای دیگر متصل شود.
- اجرای فرمان از راه دور: فرمانها و اسکریپتهای خود را روی مقصد اجرا کند.
- شناسایی محیط: کاربران، سرویسها، پردازشها و تنظیمات سیستم را بررسی کند.
- اجرای ابزار یا بدافزار: با سطح دسترسی حسابی که در اختیار دارد.
- استفاده از ابزارهای بومی ویندوز: فعالیت مخرب را میان عملیات عادی مدیریت سیستم پنهان کند؛ نمونهای از رویکرد Living off the Land.
مثال: مهاجم حساب یک ادمین را سرقت میکند. اگر سرور مقصد WinRM فعال داشته باشد و اتصال آن حساب مجاز باشد، مهاجم میتواند بدون باز کردن دسکتاپ RDP، روی سرور فرمان اجرا کند.
نکته برای SOC: در بسیاری از اجرایهای PowerShell Remoting، پردازش wsmprovhost.exe در مقصد دیده میشود. بررسی فرمانها و پردازشهای مرتبط با آن، همراه با مبدأ اتصال و حساب استفادهشده، ارزشمند است؛ وجود این پردازش بهتنهایی نشانه حمله نیست.
فعال بودن WinRM بهخودیخود یعنی هک شدن سیستم نیست؛ خطر اصلی، دسترسی شبکهای گسترده و سوءاستفاده از حسابهای مجاز است.
#WinRM #PowerShell #WindowsSecurity #CyberSecurity #SOC #ThreatHunting #LateralMovement #LivingOffTheLand #BlueTeam #امنیت_سایبری #امنیت_ویندوز #مرکز_عملیات_امنیت #شکار_تهدید #آکادمی_روزبه
