دوره مدیریت بحران سایبری
با تاکید بر Cyber Resilience
مدرس : مهندس روزبه نوروزی داری مدرک رسمی CISSP,PMP,ECSA,CEH,ISO27001 LA,Cobit,MCSA,Arcsight
www.roozbeh.academy آشنایی با مدرس دوره
1- مبانی امنیت
2- آنچه از زیرساخت IT لازم است بدانیم
3-مدیریت ریسک عملیاتی / کاربردی
4- برنامه ریزی تداوم کسب و کار
5- آمادگی سیستم های IT و امنیت برای بحران
6-بررسی کنترل های ویژه امنیت و بهروش ها
7-تهیه نقشه راه اجرایی کوتاه مدت برای Cyber resilience
8-هاردنینگ و تنظیمات امن
9-مروری بر تکنیک های کشف نفوذ
10-انجام SECOPS و مدیریت عملیات اختفای امنیتی
11-جمع آوری و تحلیل لاگ
12-فرآیند مدیریت حادثه امنیتی
13- عملیات فارنزیک
14-مدیریت عملیات بحران
15-مدیریت پیمانکار و افشای اطلاعات در زمان بحران
16-ریکاوری امن
17-بررسی درس آموخته ها از حوادث گذشته
18- آزمایشگاه
19- کارگاه عملی در مورد مدیریت بحران
20- آزمون
گروه اول : 3 دو شنبه از 8 تا 17
گروه دوم: 5 پنج شنبه از 9تا 13 - این گروه حضوری و آنلاین است .
هزیته : 8 م تومان
برگزار کننده : شرکت پیشگامان فناوری اطلاعات هامون و آکادمی روزبه
واتس آپ و بله جهت رزو 09902857290
ثابت : 88105008 داخلی 122
با تاکید بر Cyber Resilience
مدرس : مهندس روزبه نوروزی داری مدرک رسمی CISSP,PMP,ECSA,CEH,ISO27001 LA,Cobit,MCSA,Arcsight
www.roozbeh.academy آشنایی با مدرس دوره
1- مبانی امنیت
2- آنچه از زیرساخت IT لازم است بدانیم
3-مدیریت ریسک عملیاتی / کاربردی
4- برنامه ریزی تداوم کسب و کار
5- آمادگی سیستم های IT و امنیت برای بحران
6-بررسی کنترل های ویژه امنیت و بهروش ها
7-تهیه نقشه راه اجرایی کوتاه مدت برای Cyber resilience
8-هاردنینگ و تنظیمات امن
9-مروری بر تکنیک های کشف نفوذ
10-انجام SECOPS و مدیریت عملیات اختفای امنیتی
11-جمع آوری و تحلیل لاگ
12-فرآیند مدیریت حادثه امنیتی
13- عملیات فارنزیک
14-مدیریت عملیات بحران
15-مدیریت پیمانکار و افشای اطلاعات در زمان بحران
16-ریکاوری امن
17-بررسی درس آموخته ها از حوادث گذشته
18- آزمایشگاه
19- کارگاه عملی در مورد مدیریت بحران
20- آزمون
گروه اول : 3 دو شنبه از 8 تا 17
گروه دوم: 5 پنج شنبه از 9تا 13 - این گروه حضوری و آنلاین است .
هزیته : 8 م تومان
برگزار کننده : شرکت پیشگامان فناوری اطلاعات هامون و آکادمی روزبه
واتس آپ و بله جهت رزو 09902857290
ثابت : 88105008 داخلی 122
👍5🤝1
از سال ۲۰۱۷ توسط NIST استفاده از SMS بعنوان فاکتور دوم در 2FA منسوخ شده است
ولی هنوز استفاده میشود .!!
#آکادمی_روزبه
مرکز تخصصی CISSP
ولی هنوز استفاده میشود .!!
#آکادمی_روزبه
مرکز تخصصی CISSP
👍6⚡2
الان زمان آموزش‌های خاص هست که با کمک #هامون عملی کردیم
دوره مدیریت بحران سایبری
www.haumoun.com
#استاندارد #کاربردی #بموقع
دوره مدیریت بحران سایبری
www.haumoun.com
#استاندارد #کاربردی #بموقع
👍5❤1🙏1
امروز جلسه ششم از دوره CISSP برگزار میشود
عدالت آموزشی برترین مهارت‌های امنیت
آنلاین در سراسر ایران
عدالت آموزشی برترین مهارت‌های امنیت
آنلاین در سراسر ایران
❤5
#تجربه
سورپرایزی در تحلیل رجیستری
روزبه نوروزی
در این مقاله، تجربیات و یافته‌های خودم درباره نکات طلایی و کمتر موردتوجه قرارگرفته‌ی Forensics رجیستری در ویندوز به اشتراک می‌گذارم. نکاتی که بارها در دنیای واقعی، سبب موفقیت در کشف دقیق نفوذ یا Persistence مهاجمین بوده‌اند.
اول ببینیم چرا رجیستری ویندوز یک Artifact ویژه‌ست؟
رجیستری محل ذخیره تنظیمات سیستم، برنامه‌ها، کاربر، تاریخچه فعالیت و حتی گاهی ردپای بدافزار و حملات است.
اما برخلاف ظاهر ساده‌اش، لایه‌های پنهان و پیچیده‌ای دارد که بسیاری از تحلیلگران به آن بی‌توجه‌اند.
سورپرایز کلیدی: هنر بازسازی کامل رجیستری
یکی از نکات حیاتی و کمتر آموزش‌داده‌شده، لزوم ترکیب سه منبع برای بازسازی دقیق رجیستری است:
فایل ثبت‌شده روی دیسک (مانند SOFTWARE)
فایل‌های Transaction Log (مانند SOFTWARE.LOG1)
و Hiveهای لودشده در حافظه (RAM)
چرا مهم است؟
بسیاری از تحلیلگران، فقط به فایل اصلی رجیستری نگاه میکنند. اما:
تغییرات اخیر یا حملات سریع معمولاً ابتدا در RAM و Transaction Log ثبت می‌شوند و شاید هرگز روی فایل دیسک نوشته نشوند.
بنابراین اگر فقط دیسک را بررسی کنیم، ممکن است یک حمله کاملاً از چشم ما دور بماند، مخصوصاً در سناریوهایی مثل Persistenceهای memory-only یا هنگام crash و خاموش شدن ناگهانی سیستم.
مثال واقعی از Gap عملیاتی
فرض کنید هکری، حمله‌ای برمبنای تغییر مقدار Autostart رجیستری اجرا کرده، اما سیستم قبل از Write شدن تغییرات، کرش می‌کند یا عمداً ریست میشود.
در این شرایط، فقط Hive رجیستری در RAM یا Transaction Log، شواهد تغییر را نگه‌داشته است — و فایل اصلی دیسک همچنان “پاک” به‌نظر می‌رسد.
راهکار ارزیابی کامل:
برای تحلیل کامل و اصولی، لازم است همیشه این مراحل را رعایت کنید:
استخراج کامل فایل‌های Registry و Logها از هارد دیسک (اگر سیستم روشن نبود)
استخراج و dump کردن حافظه (Memory) اگر سیستم زنده بود
تحلیل همزمان با ابزارهایی نظیر Cyber Triage، Registry Explorer، Rekall، Velociraptor و…
مقایسه Memory و Disk – تغییری فقط در مموری هست و روی دیسک نوشته نشده؟
تحلیل دقیق Last Write Time و بررسی همبستگی زمانی و رفتاری برای تایم‌لاین‌سازی حملات و Persistence
نکات تکمیلی برای متخصصین
این LastWriteTime فقط نشانه یک Change است، اما چه چیزی باعث Change شده؟ اضافه کردن Value؟ تغییر Subkey؟ حذف مقدار قبلی؟
ترکیب داده‌های Transaction Log می‌تواند بعضی اوقات تغییرات موقتی و نیمه‌کاره (Partial) را هم مشخص کند.
برخلاف باور عمومی، بعضی هک‌ها در RAM باقی می‌مانند و مهاجم‌ها می‌توانند با حملات Fileless اثرشان را فقط در RAM و Transaction Log نگه دارند (و نه روی Main Registry File).
#آکادمی_روزبه
مرکز تخصصی CISSP
سورپرایزی در تحلیل رجیستری
روزبه نوروزی
در این مقاله، تجربیات و یافته‌های خودم درباره نکات طلایی و کمتر موردتوجه قرارگرفته‌ی Forensics رجیستری در ویندوز به اشتراک می‌گذارم. نکاتی که بارها در دنیای واقعی، سبب موفقیت در کشف دقیق نفوذ یا Persistence مهاجمین بوده‌اند.
اول ببینیم چرا رجیستری ویندوز یک Artifact ویژه‌ست؟
رجیستری محل ذخیره تنظیمات سیستم، برنامه‌ها، کاربر، تاریخچه فعالیت و حتی گاهی ردپای بدافزار و حملات است.
اما برخلاف ظاهر ساده‌اش، لایه‌های پنهان و پیچیده‌ای دارد که بسیاری از تحلیلگران به آن بی‌توجه‌اند.
سورپرایز کلیدی: هنر بازسازی کامل رجیستری
یکی از نکات حیاتی و کمتر آموزش‌داده‌شده، لزوم ترکیب سه منبع برای بازسازی دقیق رجیستری است:
فایل ثبت‌شده روی دیسک (مانند SOFTWARE)
فایل‌های Transaction Log (مانند SOFTWARE.LOG1)
و Hiveهای لودشده در حافظه (RAM)
چرا مهم است؟
بسیاری از تحلیلگران، فقط به فایل اصلی رجیستری نگاه میکنند. اما:
تغییرات اخیر یا حملات سریع معمولاً ابتدا در RAM و Transaction Log ثبت می‌شوند و شاید هرگز روی فایل دیسک نوشته نشوند.
بنابراین اگر فقط دیسک را بررسی کنیم، ممکن است یک حمله کاملاً از چشم ما دور بماند، مخصوصاً در سناریوهایی مثل Persistenceهای memory-only یا هنگام crash و خاموش شدن ناگهانی سیستم.
مثال واقعی از Gap عملیاتی
فرض کنید هکری، حمله‌ای برمبنای تغییر مقدار Autostart رجیستری اجرا کرده، اما سیستم قبل از Write شدن تغییرات، کرش می‌کند یا عمداً ریست میشود.
در این شرایط، فقط Hive رجیستری در RAM یا Transaction Log، شواهد تغییر را نگه‌داشته است — و فایل اصلی دیسک همچنان “پاک” به‌نظر می‌رسد.
راهکار ارزیابی کامل:
برای تحلیل کامل و اصولی، لازم است همیشه این مراحل را رعایت کنید:
استخراج کامل فایل‌های Registry و Logها از هارد دیسک (اگر سیستم روشن نبود)
استخراج و dump کردن حافظه (Memory) اگر سیستم زنده بود
تحلیل همزمان با ابزارهایی نظیر Cyber Triage، Registry Explorer، Rekall، Velociraptor و…
مقایسه Memory و Disk – تغییری فقط در مموری هست و روی دیسک نوشته نشده؟
تحلیل دقیق Last Write Time و بررسی همبستگی زمانی و رفتاری برای تایم‌لاین‌سازی حملات و Persistence
نکات تکمیلی برای متخصصین
این LastWriteTime فقط نشانه یک Change است، اما چه چیزی باعث Change شده؟ اضافه کردن Value؟ تغییر Subkey؟ حذف مقدار قبلی؟
ترکیب داده‌های Transaction Log می‌تواند بعضی اوقات تغییرات موقتی و نیمه‌کاره (Partial) را هم مشخص کند.
برخلاف باور عمومی، بعضی هک‌ها در RAM باقی می‌مانند و مهاجم‌ها می‌توانند با حملات Fileless اثرشان را فقط در RAM و Transaction Log نگه دارند (و نه روی Main Registry File).
#آکادمی_روزبه
مرکز تخصصی CISSP
👍4❤2
در لینک زیر بدافزاری تحلیل شده است که آماده است که اگر با هوش مصنوعی و مدل‌های زبانی مورد تحلیل قرار گرفت با تکنیک prompt injection اونها رو دور بزند و برنامه تحلیل کننده آنها را سالم اعلام کند
#آکادمی_روزبه
مرکز تخصصی CISSP
https://research.checkpoint.com/2025/ai-evasion-prompt-injection/
#آکادمی_روزبه
مرکز تخصصی CISSP
https://research.checkpoint.com/2025/ai-evasion-prompt-injection/
Check Point Research
New Malware Embeds Prompt Injection to Evade AI Detection - Check Point Research
Detected for the first time, malware attempts AI evasion by injecting a prompt to tell the LLM to label the file as benign
❤6👏3
مروری بر روش‌های ترند در هانت
در دنیای فعلی امنیت سایبری، بیش از هر زمان دیگری مهاجمان به جای استفاده از بدافزارهای کلاسیک، به سراغ حملاتی رفته‌اند که با ابزارها و قابلیت‌های داخلی سیستم‌عامل اجرا می‌شوند. این حملات با نام LOTL (Living Off The Land) مشهورند و چالش اصلی آنها برای تهدیدیابی این است که غالباً هیچ ردپای مشکوک یا فایل اجرایی خاصی بر جای نمی‌گذارند.
در این مقاله، به بررسی یک دیدگاه و سبک نوین در Threat Hunting می‌پردازم که تمرکز آن شکار این حملات در لایه‌ای بالاتر از IOCها و Signature است ـ با اتکا بر رفتار، فرضیه‌سازی، و تحلیل توالی رخدادها.
تعریف و اهمیت حملات LOTL
مقوله LOTL به معنای سوءاستفاده مهاجم از ابزارهای استاندارد، اسکریپت‌ها و سرویس‌های سیستم‌عامل (مثل PowerShell، WMI، RDP و…) است تا فعالیت مخرب خود را در پوشش رفتار مشروع انجام دهد. این رویکرد، شناسایی توسط AV، EDR و حتی SIEMهای مبتنی بر signature را بسیار سخت می‌کند و مهاجم می‌تواند تا هفته‌ها یا حتی ماه‌ها در سایه باقی بماند.
تهدیدیابی سنتی: چرا کافی نیست؟
در گذشته، hunting بیشتر مبتنی بر جستجو بر اساس IOC یا signature بود؛ آی‌پی مشکوک، هش فایل، یا وقوع یک رخداد شناسایی‌شده. این مدل hunting اغلب واکنشی است، وابسته به شواهد ملموس یا هشدارهای آماده.
اما حملات LOTL دقیقاً این مدل دفاع را دور می‌زنند؛ زیرا رفتارشان شبیه کارکرد عادی سیستم است، تنها تفاوت در توالی اجرا، بافتار (Context) و ترکیب رفتارهاست.
سبک جدید شکار تهدید: از Hypothesis-driven تا Behavior-based
اخیراً در یکی از مقالات مطرح ۲۰۲۵ به این نکته پرداخته شده که برای آشکارسازی حملات LOTL باید threat hunting را به سطحی فراتر از واکنش به هشدارها و Signatureها ببریم و رویکرد فعال و فرضیه‌محور را جایگزین کنیم.
کلیدواژه‌ها و رویکردها:
🔹️ فرضیه‌سازی پیش‌دستانه:
بجای انتظار برای هشدار، فرضیه‌هایی مثل «چه میشود اگر PowerShell بعد از ریموت RDP اجرا شود؟» یا «آیا افزایش ناگهانی ارتباطات WMI نشانه lateral movement نیست؟» طرح‌ریزی و براساس آن شکار آغاز گردد.
🔹️ مبنای رفتاری و تحلیلی:
تمرکز روی رفتار ابزارهای داخلی و Sequence رخدادها: اجرای cmd و powershell در ترکیب با هم، استفاده غیرمعمول از Task Scheduler یا ارتباطات مشکوک بعد از اجرای اسکریپت.
🔹️ کار با Telemetry عمیق و گسترده:
داده‌های EDR، Sysmon یا Memory Forensics باید لایه به لایه بررسی شوند تا ارتباط رخدادهای ظاهراً معمول در کنار هم، تصویر حمله را آشکار کند.
تحول عملیاتی در تیم‌ها؛ نکات کاربردی
و SOC و مهندسان کشف باید علاوه‌بر IOC به دنبال نشانه‌های رفتاری و تغییرات subtle در زنجیره عملیات مهاجم باشند.
فرضیه‌سازی و آزمون آن تبدیل به چرخه دائمی hunting و یادگیری میشود؛ با هر شکار موفق یا اشتباه، الگوریتم و ruleهای تشخیصی باید اصلاح و غنی‌تر گردند.
ابزارهایی چون Sysmon، UEBA، و EDRهایی با قابلیت correlation، محور hunting مدرن خواهند بود.
#آکادمی_روزبه
مرکز تخصصی CISSP
در دنیای فعلی امنیت سایبری، بیش از هر زمان دیگری مهاجمان به جای استفاده از بدافزارهای کلاسیک، به سراغ حملاتی رفته‌اند که با ابزارها و قابلیت‌های داخلی سیستم‌عامل اجرا می‌شوند. این حملات با نام LOTL (Living Off The Land) مشهورند و چالش اصلی آنها برای تهدیدیابی این است که غالباً هیچ ردپای مشکوک یا فایل اجرایی خاصی بر جای نمی‌گذارند.
در این مقاله، به بررسی یک دیدگاه و سبک نوین در Threat Hunting می‌پردازم که تمرکز آن شکار این حملات در لایه‌ای بالاتر از IOCها و Signature است ـ با اتکا بر رفتار، فرضیه‌سازی، و تحلیل توالی رخدادها.
تعریف و اهمیت حملات LOTL
مقوله LOTL به معنای سوءاستفاده مهاجم از ابزارهای استاندارد، اسکریپت‌ها و سرویس‌های سیستم‌عامل (مثل PowerShell، WMI، RDP و…) است تا فعالیت مخرب خود را در پوشش رفتار مشروع انجام دهد. این رویکرد، شناسایی توسط AV، EDR و حتی SIEMهای مبتنی بر signature را بسیار سخت می‌کند و مهاجم می‌تواند تا هفته‌ها یا حتی ماه‌ها در سایه باقی بماند.
تهدیدیابی سنتی: چرا کافی نیست؟
در گذشته، hunting بیشتر مبتنی بر جستجو بر اساس IOC یا signature بود؛ آی‌پی مشکوک، هش فایل، یا وقوع یک رخداد شناسایی‌شده. این مدل hunting اغلب واکنشی است، وابسته به شواهد ملموس یا هشدارهای آماده.
اما حملات LOTL دقیقاً این مدل دفاع را دور می‌زنند؛ زیرا رفتارشان شبیه کارکرد عادی سیستم است، تنها تفاوت در توالی اجرا، بافتار (Context) و ترکیب رفتارهاست.
سبک جدید شکار تهدید: از Hypothesis-driven تا Behavior-based
اخیراً در یکی از مقالات مطرح ۲۰۲۵ به این نکته پرداخته شده که برای آشکارسازی حملات LOTL باید threat hunting را به سطحی فراتر از واکنش به هشدارها و Signatureها ببریم و رویکرد فعال و فرضیه‌محور را جایگزین کنیم.
کلیدواژه‌ها و رویکردها:
🔹️ فرضیه‌سازی پیش‌دستانه:
بجای انتظار برای هشدار، فرضیه‌هایی مثل «چه میشود اگر PowerShell بعد از ریموت RDP اجرا شود؟» یا «آیا افزایش ناگهانی ارتباطات WMI نشانه lateral movement نیست؟» طرح‌ریزی و براساس آن شکار آغاز گردد.
🔹️ مبنای رفتاری و تحلیلی:
تمرکز روی رفتار ابزارهای داخلی و Sequence رخدادها: اجرای cmd و powershell در ترکیب با هم، استفاده غیرمعمول از Task Scheduler یا ارتباطات مشکوک بعد از اجرای اسکریپت.
🔹️ کار با Telemetry عمیق و گسترده:
داده‌های EDR، Sysmon یا Memory Forensics باید لایه به لایه بررسی شوند تا ارتباط رخدادهای ظاهراً معمول در کنار هم، تصویر حمله را آشکار کند.
تحول عملیاتی در تیم‌ها؛ نکات کاربردی
و SOC و مهندسان کشف باید علاوه‌بر IOC به دنبال نشانه‌های رفتاری و تغییرات subtle در زنجیره عملیات مهاجم باشند.
فرضیه‌سازی و آزمون آن تبدیل به چرخه دائمی hunting و یادگیری میشود؛ با هر شکار موفق یا اشتباه، الگوریتم و ruleهای تشخیصی باید اصلاح و غنی‌تر گردند.
ابزارهایی چون Sysmon، UEBA، و EDRهایی با قابلیت correlation، محور hunting مدرن خواهند بود.
#آکادمی_روزبه
مرکز تخصصی CISSP
❤5💯2
#تجربه
#بهسازی_SOC
اگر سیسمون رو بر اساس تنظیمات swiftonsecurity یا olafhartong انجام می‌دهید تا دقت خوب و کاهش حجم لاگ داشته باشید بدانید چه ریسک هایی رو ندید میگیرید!!
در این مقاله به اونها می‌پردازم
روزبه نوروزی
لیست حملاتی که با config مینیمال Sysmon ممکن است قابل کشف نباشند
۱. حملهLOTL (Living Off The Land) با ابزارهای بومی کمتر رایج
اجرای ابزارهایی مانند certutil.exe، mshta.exe، یا forfiles.exe اگر فقط روی powershell و cmd حساسیت باشد، معمولاً در مینیمال config اصلاً Log نمی‌شوند.
۲. برخی تکنیک‌های Fileless Malware
حملاتی که کد مخرب را مستقیماً در حافظه تزریق میکنند (مانند process hollowing یا reflectively loaded DLL)، اگر Log مربوط به Memory/Process creation دقیق شناسایی نشود (Event ID 8: CreateRemoteThread، Event ID 10: ProcessAccess).
۳. تغییرات مخفی در Registry
تغییر کلیدهای خاص (مثل Run، Image File Execution Options، یا کلیدهای less-known مانند AppInit_DLLs، UserInit) اغلب Log نمی‌شوند اگر فقط کلیدهای خاصی مانیتور شوند.
۴. انجام Network Lateral Movement
اگر فقط ترافیک غیر لوکال یا پورت‌های مشهور log شود، ترافیک غیرمعمول در داخل شبکه (مثلاً روی پورت 4444 یا WMI) از دست می‌رود (Event ID 3: Network Connection معمولاً حسابی فیلتر میشود).
۵. تغییرات پیشرفته در Scheduled Tasks
اگر config فقط schtasks.exe را log کند و نه فایل‌های XML یا عملیات از طریق API ویندوز، ساخت task با ابزارهای بومی در EventID 1 دیده نمی‌شود.
۶. تهدیدات مبتنی بر Named Pipe/IPC
همزادسازی دسترسی بین پردازش‌ها (Event ID 17/18: Pipe Created/Connected) در اکثر configها خاموش است، در نتیجه حملات IPC-Based قابل کشف نیستند.
۷. دور زدن با Parent-Child Spoofing
اگر ParentImage logging صرفاً محدود به پروسس‌های کلاسیک باشد، حملاتی با process injection یا hollowing که Parent غیرعادی دارند، تشخیص داده نمی‌شوند.
۸. وجودPersistenceهای نامتعارف (WMI Event Consumer/Filter)
ایجاد WMI Permanent Event Subscription (Event ID 19, 20, 21) اغلب در configهای سبک logging نمی‌شوند.
۹. وExecution از طریق کمندهای جستجوگر ویندوز
اجرای مخرب از طریق Search-ms protocol، searchui.exe یا حتی explorer با argumentهای دقیق؛ اگر فقط روی powershell و cmd حساسیت باشد نادیده گرفته میشود.
۱۰. وDLL Sideloading و اجرای DLLهای نامعلوم
اگر FileCreate مربوط به فولدرهای مشکوک (مانند ProgramData یا TEMP) log نشود، این تکنیک‌ها مخفی می‌مانند.
#تجربه
#آکادمی_روزبه
مرکز تخصصی CISSP
#بهسازی_SOC
اگر سیسمون رو بر اساس تنظیمات swiftonsecurity یا olafhartong انجام می‌دهید تا دقت خوب و کاهش حجم لاگ داشته باشید بدانید چه ریسک هایی رو ندید میگیرید!!
در این مقاله به اونها می‌پردازم
روزبه نوروزی
لیست حملاتی که با config مینیمال Sysmon ممکن است قابل کشف نباشند
۱. حملهLOTL (Living Off The Land) با ابزارهای بومی کمتر رایج
اجرای ابزارهایی مانند certutil.exe، mshta.exe، یا forfiles.exe اگر فقط روی powershell و cmd حساسیت باشد، معمولاً در مینیمال config اصلاً Log نمی‌شوند.
۲. برخی تکنیک‌های Fileless Malware
حملاتی که کد مخرب را مستقیماً در حافظه تزریق میکنند (مانند process hollowing یا reflectively loaded DLL)، اگر Log مربوط به Memory/Process creation دقیق شناسایی نشود (Event ID 8: CreateRemoteThread، Event ID 10: ProcessAccess).
۳. تغییرات مخفی در Registry
تغییر کلیدهای خاص (مثل Run، Image File Execution Options، یا کلیدهای less-known مانند AppInit_DLLs، UserInit) اغلب Log نمی‌شوند اگر فقط کلیدهای خاصی مانیتور شوند.
۴. انجام Network Lateral Movement
اگر فقط ترافیک غیر لوکال یا پورت‌های مشهور log شود، ترافیک غیرمعمول در داخل شبکه (مثلاً روی پورت 4444 یا WMI) از دست می‌رود (Event ID 3: Network Connection معمولاً حسابی فیلتر میشود).
۵. تغییرات پیشرفته در Scheduled Tasks
اگر config فقط schtasks.exe را log کند و نه فایل‌های XML یا عملیات از طریق API ویندوز، ساخت task با ابزارهای بومی در EventID 1 دیده نمی‌شود.
۶. تهدیدات مبتنی بر Named Pipe/IPC
همزادسازی دسترسی بین پردازش‌ها (Event ID 17/18: Pipe Created/Connected) در اکثر configها خاموش است، در نتیجه حملات IPC-Based قابل کشف نیستند.
۷. دور زدن با Parent-Child Spoofing
اگر ParentImage logging صرفاً محدود به پروسس‌های کلاسیک باشد، حملاتی با process injection یا hollowing که Parent غیرعادی دارند، تشخیص داده نمی‌شوند.
۸. وجودPersistenceهای نامتعارف (WMI Event Consumer/Filter)
ایجاد WMI Permanent Event Subscription (Event ID 19, 20, 21) اغلب در configهای سبک logging نمی‌شوند.
۹. وExecution از طریق کمندهای جستجوگر ویندوز
اجرای مخرب از طریق Search-ms protocol، searchui.exe یا حتی explorer با argumentهای دقیق؛ اگر فقط روی powershell و cmd حساسیت باشد نادیده گرفته میشود.
۱۰. وDLL Sideloading و اجرای DLLهای نامعلوم
اگر FileCreate مربوط به فولدرهای مشکوک (مانند ProgramData یا TEMP) log نشود، این تکنیک‌ها مخفی می‌مانند.
#تجربه
#آکادمی_روزبه
مرکز تخصصی CISSP
❤8💯2
در دنیای پیچیده امنیت اکتیو دایرکتوری، مدیریت دسترسی‌ها و مکانیزم‌های Delegation نقشی حیاتی در حفظ امنیت زیرساخت ایفا میکنند.
یکی از حوزه‌هایی که گهگاه کمتر مورد توجه قرار می‌گیرد اما ظرفیت بالایی برای ایجاد تهدیدات جدی دارد، بحث Delegation به ویژه در قالب Unconstrained Delegation است.
در این مدل، حساب‌ها مجاز هستند بدون محدودیت اعتبارنامه کاربران را به سرویس‌های دیگر منتقل کنند؛ موضوعی که اگر به‌درستی مدیریت نشود، می‌تواند به مهاجمان امکان دسترسی گسترده و حتی تصرف کامل Domain را بدهد.
مساله Group Managed Service Account یا gMSA یکی از انواع حساب‌هایی است که برای مدیریت سرویس‌ها و برنامه‌ها در محیط‌های بزرگ استفاده میشود. هرچند طراحی gMSA با هدف بهبود امنیت انجام شده، اما در صورت استفاده نادرست یا پیکربندی اشتباه، به نقطه ضعف تبدیل خواهد شد؛ به ویژه زمانی که با Unconstrained Delegation ترکیب شود.
این مقاله به بررسی چرایی اهمیت این تهدید، روش‌های شناسایی و بهره‌برداری مهاجمان، و راهکارهای کاهش ریسک و بهبود امنیت gMSA و Delegation می‌پردازد
این مقاله حمله به حساب‌های gMSA با Unconstrained Delegation را توضیح می‌دهد. مهاجم با شناسایی gMSAهای دارای این ویژگی، بررسی سرورهای هدف و استخراج پسورد (از طریق دسترسی پرمیشن یا حمله NTLM Relay)، می‌تواند کنترل کامل دامنه را به دست آورد. ابزارهایی مثل Impacket و gMSADumper این پروسه را تسهیل میکنند. اشیاء غیرفعال هم خطرناک هستند و باید حذف یا هاردن شوند. این مسیر حمله اغلب نادیده گرفته میشود و برای حفاظت باید Unconstrained Delegation در سطح دامنه محدود شده و دسترسی‌ها به دقت بررسی و محدود شوند.
#آکادمی_روزبه
مرکز تخصصی CISSP
https://nothingspecialforu.github.io/UCgMSAExploitation/
یکی از حوزه‌هایی که گهگاه کمتر مورد توجه قرار می‌گیرد اما ظرفیت بالایی برای ایجاد تهدیدات جدی دارد، بحث Delegation به ویژه در قالب Unconstrained Delegation است.
در این مدل، حساب‌ها مجاز هستند بدون محدودیت اعتبارنامه کاربران را به سرویس‌های دیگر منتقل کنند؛ موضوعی که اگر به‌درستی مدیریت نشود، می‌تواند به مهاجمان امکان دسترسی گسترده و حتی تصرف کامل Domain را بدهد.
مساله Group Managed Service Account یا gMSA یکی از انواع حساب‌هایی است که برای مدیریت سرویس‌ها و برنامه‌ها در محیط‌های بزرگ استفاده میشود. هرچند طراحی gMSA با هدف بهبود امنیت انجام شده، اما در صورت استفاده نادرست یا پیکربندی اشتباه، به نقطه ضعف تبدیل خواهد شد؛ به ویژه زمانی که با Unconstrained Delegation ترکیب شود.
این مقاله به بررسی چرایی اهمیت این تهدید، روش‌های شناسایی و بهره‌برداری مهاجمان، و راهکارهای کاهش ریسک و بهبود امنیت gMSA و Delegation می‌پردازد
این مقاله حمله به حساب‌های gMSA با Unconstrained Delegation را توضیح می‌دهد. مهاجم با شناسایی gMSAهای دارای این ویژگی، بررسی سرورهای هدف و استخراج پسورد (از طریق دسترسی پرمیشن یا حمله NTLM Relay)، می‌تواند کنترل کامل دامنه را به دست آورد. ابزارهایی مثل Impacket و gMSADumper این پروسه را تسهیل میکنند. اشیاء غیرفعال هم خطرناک هستند و باید حذف یا هاردن شوند. این مسیر حمله اغلب نادیده گرفته میشود و برای حفاظت باید Unconstrained Delegation در سطح دامنه محدود شده و دسترسی‌ها به دقت بررسی و محدود شوند.
#آکادمی_روزبه
مرکز تخصصی CISSP
https://nothingspecialforu.github.io/UCgMSAExploitation/
❤4
دور خوردن EDR های مهم
نویسنده نشان می‌دهد که چگونه با io_uring (که مثل یک تونل خاص و کم‌سروصدا برای کار با فایل/شبکه به لینوکس اضافه شده)، میشود داده‌ها را خواند/نوشت/ارسال کرد بدون آنکه EDRهای مهم (مثل CrowdStrike Falcon, SentinelOne, یا حتی بعضی نمونه‌های Open Source مثل Wazuh اگر به syscall tracing تکیه کنند) متوجه شوند.
کد ارائه‌شده، یک backdoor عملی است که داده و ران‌فرمان از C2 می‌گیرد و همه عملیاتش را بدون syscall کلاسیک انجام می‌دهد.
اگر در تیم آبی کار می‌کنید، باید حواستان باشد که سیستم فقط با بررسی classic syscallها امن نیست.
راه‌حل: باید روی بحث kernel tracing، eBPF مخصوص io_uring، و شبکه تمرکز کنید.
این مقاله یک آگاهی مهم برای عملیات SOC/LINUX EDR است:
روش‌های مبتنی بر syscall hooking کافی نیست!
باید ابزارهای جدید و مانیتورینگ مبتنی‌بر eBPF/Kernel-level را جدی‌تر بگیرید.
برای Red Teamها، io_uring یک راه جذاب برای فرار از بسیاری از محصولات EDR-Linux است (تا زمانی که detection rule به آن نخورده).
#آکادمی_روزبه
مرکز تخصصی CISSP
https://matheuzsecurity.github.io/hacking/evading-linux-edrs-with-io-uring/
نویسنده نشان می‌دهد که چگونه با io_uring (که مثل یک تونل خاص و کم‌سروصدا برای کار با فایل/شبکه به لینوکس اضافه شده)، میشود داده‌ها را خواند/نوشت/ارسال کرد بدون آنکه EDRهای مهم (مثل CrowdStrike Falcon, SentinelOne, یا حتی بعضی نمونه‌های Open Source مثل Wazuh اگر به syscall tracing تکیه کنند) متوجه شوند.
کد ارائه‌شده، یک backdoor عملی است که داده و ران‌فرمان از C2 می‌گیرد و همه عملیاتش را بدون syscall کلاسیک انجام می‌دهد.
اگر در تیم آبی کار می‌کنید، باید حواستان باشد که سیستم فقط با بررسی classic syscallها امن نیست.
راه‌حل: باید روی بحث kernel tracing، eBPF مخصوص io_uring، و شبکه تمرکز کنید.
این مقاله یک آگاهی مهم برای عملیات SOC/LINUX EDR است:
روش‌های مبتنی بر syscall hooking کافی نیست!
باید ابزارهای جدید و مانیتورینگ مبتنی‌بر eBPF/Kernel-level را جدی‌تر بگیرید.
برای Red Teamها، io_uring یک راه جذاب برای فرار از بسیاری از محصولات EDR-Linux است (تا زمانی که detection rule به آن نخورده).
#آکادمی_روزبه
مرکز تخصصی CISSP
https://matheuzsecurity.github.io/hacking/evading-linux-edrs-with-io-uring/
matheuzsecurity.github.io
Red Team Tactics: Evading EDR on Linux with io_uring · 0xMatheuZ
Learn how to bypass modern defenses with io_uring
👍5
“درب پشتی” و “آسیب‌پذیری” در دستگاه‌های ذخیره‌سازی (Storage Devices)
در خصوص ذخیره سازها مثل SAN، NAS، اکسترنال هارد، و حتی درایوهای SSD و HDD آسیب پذیری از نگاه امنیت سایبری چند بُعد دارد. در ادامه به نکات عملی، تجربیات واقعی و تهدیدات شناخته‌شده می‌پردازم که برای یک SOC یا تیم امنیت می‌تواند ارزشمند باشد:
۱. درب پشتی (Backdoor) در دستگاه‌های ذخیره‌سازی
الف. بک‌دورها در فریم‌ویر (Firmware Backdoors)
واقعیت: سازندگان، یا کمپانی‌های با سیاست ساخت ODM، گاهی عمداً یا سهواً دسترسی مخفی برای مدیریت، پشتیبانی یا مقاصد بدافزار (مانند Neutrality یا Cloud backend) باقی می‌گذارند.
نمونه واقعی:در سال ۲۰۱۴، شرکت Western Digital فریم‌ویری در برخی NAS ها داشت که درب‌پشتی آن، به ادمین اجازه Telnet دسترسی مخفی بدون لاگ را می‌داد.
ب. دستکاری و آسیب‌پذیری در میکروکنترلر SSD/HDD
در BadUSB و ابزارهایی مثل HIDD (Hacker’s HDD backdoor): مهاجم فریم‌ویر SSD/HDD را با یک بیلد آلوده جایگزین کرده و مثلاً کانال ارتباطی C2 پنهان یا حافظه رمزنگاری‌شده جاسازی می‌کند.
یادداشت: کشف این نوع بک‌دورها با ابزارهای متداول بسیار دشوار است و فقط با تحلیل کم‌لایه و ابزارهای Forensics مخصوص قابل انجام است.
۲. آسیب‌پذیری‌های رایج (Vulnerabilities)
الف. Remote Code Execution و Web-based Backdoor
اکثر Storageهای تحت شبکه (مثل QNAP، Synology، WD My Cloud) وب‌سرور یا SMB دارند، اغلب آسیب‌پذیر به RCE یا login bypass بوده‌اند.
نمونه واقعی:در اوایل ۲۰۲۴ چند آسیب‌پذیری بحرانی QNAP و Synology (CVE-2024-21899 و CVE-2024-2879) به هکر اجازه می‌داد بدون اعتبارسنجی، دستورات سیستمی اجرا و حتی فایل‌ها را پاک یا رمزگذاری کند.
ب. آسیب‌پذیری‌هایی مثل SMB Ghost، EternalBlue یا WebDAV
بسیاری از NASها از ماژول‌های قدیمی Samba استفاده میکنند و به‌شدت در معرض آسیب‌پذیری‌های اساسی‌اند که حملات wormable را فعال میکنند.
ج. ضعف در احراز هویت و مدیریت دسترسی
ذخیره‌سازی پیش‌فرض با پسورد ساده/تکراری (admin/admin یا guest/guest)
فعال بودن FTP/Telnet بدون رمزنگاری
۳. تجربیات شکار و تحلیل در SOC
لاگ‌های Storage اغلب از لاگ مرکزی سرور جداست و به همین دلیل بک‌دور در شبکه کمتر آشکار میشود مگر با Network Threat Hunting روی پورت‌ها و پروتکل‌های معمول دستگاه‌های ذخیره‌سازی (مانند SMB، NFS، iSCSI).
سناریوی واقعی: در یک حمله باج‌افزاری به شبکه سازمانی، یک NAS قدیمی به سر پل انتقال اولیه باج‌افزار تبدیل شده بود چون تنها این دستگاه به‌علت firmware قدیمی و تنظیمات پیش‌فرض قربانی RCE شده بود.
تیم Hunting با تحلیل پکت‌های مشکوک روی پورت‌های ۴۴۵ و ۸۰ و مقایسه رفتار ترافیکی با الگوهای عادی، فعالیت بدافزار و حتی ایجاد کانال ارتباطی پنهان (C2) از طریق آن دستگاه را کشف کرد.
۴. اقدامات عملی و راهکارها
به‌روزرسانی مداوم فریم‌ویر و نظارت بر advisories شرکت سازنده
غیرفعال کردن سرویس‌های غیرضروری (FTP، Telnet، UPnP)
اجباری کردن MFA یا حداقل پسورد قوی، خصوصاً برای دسترسی مدیریت
یکپارچه‌سازی لاگ Storageها در SIEM
بررسی دوره‌ای دستگاه‌ها با ابزارهایی مثل Binwalk و firmware scanner برای شناسایی شِل یا بک‌دورهای مخفی
#آکادمی_روزبه
مرکز تخصصی CISSP
در دوره مدیریت بحران سایبری به این مقولات حاصل از تجربیات می‌پردازم
تماس با واتس اپ و بله 09902857290
در خصوص ذخیره سازها مثل SAN، NAS، اکسترنال هارد، و حتی درایوهای SSD و HDD آسیب پذیری از نگاه امنیت سایبری چند بُعد دارد. در ادامه به نکات عملی، تجربیات واقعی و تهدیدات شناخته‌شده می‌پردازم که برای یک SOC یا تیم امنیت می‌تواند ارزشمند باشد:
۱. درب پشتی (Backdoor) در دستگاه‌های ذخیره‌سازی
الف. بک‌دورها در فریم‌ویر (Firmware Backdoors)
واقعیت: سازندگان، یا کمپانی‌های با سیاست ساخت ODM، گاهی عمداً یا سهواً دسترسی مخفی برای مدیریت، پشتیبانی یا مقاصد بدافزار (مانند Neutrality یا Cloud backend) باقی می‌گذارند.
نمونه واقعی:در سال ۲۰۱۴، شرکت Western Digital فریم‌ویری در برخی NAS ها داشت که درب‌پشتی آن، به ادمین اجازه Telnet دسترسی مخفی بدون لاگ را می‌داد.
ب. دستکاری و آسیب‌پذیری در میکروکنترلر SSD/HDD
در BadUSB و ابزارهایی مثل HIDD (Hacker’s HDD backdoor): مهاجم فریم‌ویر SSD/HDD را با یک بیلد آلوده جایگزین کرده و مثلاً کانال ارتباطی C2 پنهان یا حافظه رمزنگاری‌شده جاسازی می‌کند.
یادداشت: کشف این نوع بک‌دورها با ابزارهای متداول بسیار دشوار است و فقط با تحلیل کم‌لایه و ابزارهای Forensics مخصوص قابل انجام است.
۲. آسیب‌پذیری‌های رایج (Vulnerabilities)
الف. Remote Code Execution و Web-based Backdoor
اکثر Storageهای تحت شبکه (مثل QNAP، Synology، WD My Cloud) وب‌سرور یا SMB دارند، اغلب آسیب‌پذیر به RCE یا login bypass بوده‌اند.
نمونه واقعی:در اوایل ۲۰۲۴ چند آسیب‌پذیری بحرانی QNAP و Synology (CVE-2024-21899 و CVE-2024-2879) به هکر اجازه می‌داد بدون اعتبارسنجی، دستورات سیستمی اجرا و حتی فایل‌ها را پاک یا رمزگذاری کند.
ب. آسیب‌پذیری‌هایی مثل SMB Ghost، EternalBlue یا WebDAV
بسیاری از NASها از ماژول‌های قدیمی Samba استفاده میکنند و به‌شدت در معرض آسیب‌پذیری‌های اساسی‌اند که حملات wormable را فعال میکنند.
ج. ضعف در احراز هویت و مدیریت دسترسی
ذخیره‌سازی پیش‌فرض با پسورد ساده/تکراری (admin/admin یا guest/guest)
فعال بودن FTP/Telnet بدون رمزنگاری
۳. تجربیات شکار و تحلیل در SOC
لاگ‌های Storage اغلب از لاگ مرکزی سرور جداست و به همین دلیل بک‌دور در شبکه کمتر آشکار میشود مگر با Network Threat Hunting روی پورت‌ها و پروتکل‌های معمول دستگاه‌های ذخیره‌سازی (مانند SMB، NFS، iSCSI).
سناریوی واقعی: در یک حمله باج‌افزاری به شبکه سازمانی، یک NAS قدیمی به سر پل انتقال اولیه باج‌افزار تبدیل شده بود چون تنها این دستگاه به‌علت firmware قدیمی و تنظیمات پیش‌فرض قربانی RCE شده بود.
تیم Hunting با تحلیل پکت‌های مشکوک روی پورت‌های ۴۴۵ و ۸۰ و مقایسه رفتار ترافیکی با الگوهای عادی، فعالیت بدافزار و حتی ایجاد کانال ارتباطی پنهان (C2) از طریق آن دستگاه را کشف کرد.
۴. اقدامات عملی و راهکارها
به‌روزرسانی مداوم فریم‌ویر و نظارت بر advisories شرکت سازنده
غیرفعال کردن سرویس‌های غیرضروری (FTP، Telnet، UPnP)
اجباری کردن MFA یا حداقل پسورد قوی، خصوصاً برای دسترسی مدیریت
یکپارچه‌سازی لاگ Storageها در SIEM
بررسی دوره‌ای دستگاه‌ها با ابزارهایی مثل Binwalk و firmware scanner برای شناسایی شِل یا بک‌دورهای مخفی
#آکادمی_روزبه
مرکز تخصصی CISSP
در دوره مدیریت بحران سایبری به این مقولات حاصل از تجربیات می‌پردازم
تماس با واتس اپ و بله 09902857290
👍5👏2
راهنمای لاگ گیری در لینوکس
از CrowdStrike
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.crowdstrike.com/en-us/guides/linux-logging/
از CrowdStrike
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.crowdstrike.com/en-us/guides/linux-logging/
CrowdStrike.com
<strong>Linux Logging Guide</strong>:
The Basics
The Basics
In part one of a series on Linux logging, we will go over the common Linux logging framework, locations of these log files, and the different types of logging daemons and protocols
⚡5
امکان سوءاستفاده سخت‌افزاری از طریق رابط‌های پنهان دیباگ (مطالعه موردی: EUD/JTAG در چیپست‌های Qualcomm)
✅️بخشی از دوره مدیریت بحران سایبری آکادمی روزبه
مقدمه
در عصر اینترنت اشیاء، موبایل و تجهیزات متصل، امنیت سخت‌افزاری کمتر از لایه نرم‌افزاری مورد توجه قرار گرفته است. در حالی که تمرکز اکثر تیم‌های امنیت بر آسیب‌پذیری‌های نرم‌افزاری و شبکه‌ای است، وجود رابط‌های دیباگ پنهان نظیر JTAG و EUD (Embedded USB Debug) در بسیاری از سخت‌افزارهای مدرن، به یک خطر بالقوه تبدیل شده است. این منافذ به مهاجم امکان می‌دهد فارغ از محدودیت‌های سیستم‌عامل یا حتی Secure Boot، کنترل سطح پایین دستگاه را در اختیار بگیرد.
ماهیت تهدید
رابط‌هایی مانند JTAG و SWD (Serial Wire Debug)، طراحی شده‌اند تا توسعه‌دهندگان و تعمیرکاران بتوانند سخت‌افزار را دیباگ و تحلیل کنند. در بسیاری از پردازنده‌های موبایلی نظیر Qualcomm Snapdragon، این رابط‌ها به شکل پنهان، در پورت USB ادغام یا از طریق فریم‌ویر فعال می‌شوند (مانند EUD). به تازگی کد منبع تعامل با EUD به صورت عمومی منتشر شده و امکان بهره‌برداری از این دسترسی بدون نیاز به باز کردن دستگاه و ابزارآلات خاص فراهم گردیده است.
سناریوهای سوءاستفاده عملی
۱. کسب دسترسی کامل سخت‌افزاری:
اگر EUD یا JTAG فعال باشد، مهاجم می‌تواند با اتصال به پورت USB، به رجیسترهای داخلی، حافظه و کنترل کامل پردازنده برسد. این دسترسی در خارج از کنترل سیستم‌عامل است و عملاً تمام لایه‌های امنیتی نرم‌افزاری را دور می‌زند.
تزریق بدافزار پایدار یا روت‌کیت:
مهاجم می‌تواند فریم‌ویر را تغییر داده، implant دائمی نصب کند یا حتی کل image دستگاه را dump و بررسی کند.
تهدید Supply Chain:
اگر تجهیزات سازمانی یا تجهیزات IoT با Debug Interface فعال وارد چرخه مصرف شوند، همان ابتدای زنجیره تامین ریسک implant فیزیکی و زدودن شفافیت امنیتی را ایجاد می‌کند.
پیشنهاد به تیم‌های امنیت
تجهیزات خود را ممیزی و وضعیت Debug Interfaceها را بررسی کنید.
در صورت عدم نیاز، اینترفیس‌های دیباگ را غیرفعال و فیوزهای امنیتی را فعال کنید.
به‌روزرسانی منظم فریم‌ویر را جدی بگیرید و تامین‌کنندگان سخت‌افزار را اعتبارسنجی نمایید.
امنیت سخت‌افزاری را جزو چک‌لیست‌های ارزیابی فنی و تست نفوذ قرار دهید.
نتیجه‌گیری
امنیت سخت‌افزاری سنگ‌بنای امنیت دیجیتال است و غفلت از پتانسیل سوءاستفاده از منافذ سخت‌افزاری می‌تواند تمامی لایه‌های منطقی دفاع را بی‌اثر کند. توجه مداوم به این لایه، رکن حیاتی امنیت سازمان‌های امروزی است.
#آکادمی_روزبه
مرکز تخصصی CISSP
✅️بخشی از دوره مدیریت بحران سایبری آکادمی روزبه
مقدمه
در عصر اینترنت اشیاء، موبایل و تجهیزات متصل، امنیت سخت‌افزاری کمتر از لایه نرم‌افزاری مورد توجه قرار گرفته است. در حالی که تمرکز اکثر تیم‌های امنیت بر آسیب‌پذیری‌های نرم‌افزاری و شبکه‌ای است، وجود رابط‌های دیباگ پنهان نظیر JTAG و EUD (Embedded USB Debug) در بسیاری از سخت‌افزارهای مدرن، به یک خطر بالقوه تبدیل شده است. این منافذ به مهاجم امکان می‌دهد فارغ از محدودیت‌های سیستم‌عامل یا حتی Secure Boot، کنترل سطح پایین دستگاه را در اختیار بگیرد.
ماهیت تهدید
رابط‌هایی مانند JTAG و SWD (Serial Wire Debug)، طراحی شده‌اند تا توسعه‌دهندگان و تعمیرکاران بتوانند سخت‌افزار را دیباگ و تحلیل کنند. در بسیاری از پردازنده‌های موبایلی نظیر Qualcomm Snapdragon، این رابط‌ها به شکل پنهان، در پورت USB ادغام یا از طریق فریم‌ویر فعال می‌شوند (مانند EUD). به تازگی کد منبع تعامل با EUD به صورت عمومی منتشر شده و امکان بهره‌برداری از این دسترسی بدون نیاز به باز کردن دستگاه و ابزارآلات خاص فراهم گردیده است.
سناریوهای سوءاستفاده عملی
۱. کسب دسترسی کامل سخت‌افزاری:
اگر EUD یا JTAG فعال باشد، مهاجم می‌تواند با اتصال به پورت USB، به رجیسترهای داخلی، حافظه و کنترل کامل پردازنده برسد. این دسترسی در خارج از کنترل سیستم‌عامل است و عملاً تمام لایه‌های امنیتی نرم‌افزاری را دور می‌زند.
تزریق بدافزار پایدار یا روت‌کیت:
مهاجم می‌تواند فریم‌ویر را تغییر داده، implant دائمی نصب کند یا حتی کل image دستگاه را dump و بررسی کند.
تهدید Supply Chain:
اگر تجهیزات سازمانی یا تجهیزات IoT با Debug Interface فعال وارد چرخه مصرف شوند، همان ابتدای زنجیره تامین ریسک implant فیزیکی و زدودن شفافیت امنیتی را ایجاد می‌کند.
پیشنهاد به تیم‌های امنیت
تجهیزات خود را ممیزی و وضعیت Debug Interfaceها را بررسی کنید.
در صورت عدم نیاز، اینترفیس‌های دیباگ را غیرفعال و فیوزهای امنیتی را فعال کنید.
به‌روزرسانی منظم فریم‌ویر را جدی بگیرید و تامین‌کنندگان سخت‌افزار را اعتبارسنجی نمایید.
امنیت سخت‌افزاری را جزو چک‌لیست‌های ارزیابی فنی و تست نفوذ قرار دهید.
نتیجه‌گیری
امنیت سخت‌افزاری سنگ‌بنای امنیت دیجیتال است و غفلت از پتانسیل سوءاستفاده از منافذ سخت‌افزاری می‌تواند تمامی لایه‌های منطقی دفاع را بی‌اثر کند. توجه مداوم به این لایه، رکن حیاتی امنیت سازمان‌های امروزی است.
#آکادمی_روزبه
مرکز تخصصی CISSP
❤4
وقتی فرآیند صدور مجوز امنیتی برای کسب و کار ها ضعیف اجرا بشه ؛ هرکسی میتونه اطلاعاتی داشته باشه که نباید.
اطلاعات این سایت شاید در برخی ترور ها مؤثر بوده .
فعلا که سایت رسمیو که اطلاعات شرکتها رو ریخته بود کف اینترنت از دسترس خارج شده که این خوبه
امید که من بعد مجوز به چنین کسب و کارهایی با دقت بیشتری انجام بشه
اطلاعات این سایت شاید در برخی ترور ها مؤثر بوده .
فعلا که سایت رسمیو که اطلاعات شرکتها رو ریخته بود کف اینترنت از دسترس خارج شده که این خوبه
امید که من بعد مجوز به چنین کسب و کارهایی با دقت بیشتری انجام بشه
👍6💯4
آکادمی آموزش روزبه 📚
وقتی فرآیند صدور مجوز امنیتی برای کسب و کار ها ضعیف اجرا بشه ؛ هرکسی میتونه اطلاعاتی داشته باشه که نباید. اطلاعات این سایت شاید در برخی ترور ها مؤثر بوده . فعلا که سایت رسمیو که اطلاعات شرکتها رو ریخته بود کف اینترنت از دسترس خارج شده که این خوبه امید که…
مساله دیگری که درخصوص اطلاعات درج شده در این سایت هست که آدم متاسف میشه ازش ، رانت هست. خیلی ها که در ایران در حوزه امنیت کار میکنند حتی نمیتونن لینکدین داشته باشند یا محل کارشون رو در لینکدین بنویسند حتی اگر یک بانک باشه.
اما از اون طرف دانشمندان هسته ای ما در شرکت های مختلف عضو بودن و اسمشون به راحتی هرجایی بوده. لذا خیلی هم تقصیر سایت رسمیو نیست . تقصیر خود اون دانشمند و حراست واحد های مربوطه هم هست.
درسته رسمیو طبقه بندی اطلاعاتی نداشته و از این بابت مقصره ولی خود اون افراد هم نباید اینقدر تابلو اطلاعاتشون رو اینور و اونور می‌دادند.
✅انشالله از دوشنبه مباحث OPSEC و SECOPS رو در دوره مدیریت بحران سایبری بررسی و تدریس خواهم کرد.
اما از اون طرف دانشمندان هسته ای ما در شرکت های مختلف عضو بودن و اسمشون به راحتی هرجایی بوده. لذا خیلی هم تقصیر سایت رسمیو نیست . تقصیر خود اون دانشمند و حراست واحد های مربوطه هم هست.
درسته رسمیو طبقه بندی اطلاعاتی نداشته و از این بابت مقصره ولی خود اون افراد هم نباید اینقدر تابلو اطلاعاتشون رو اینور و اونور می‌دادند.
✅انشالله از دوشنبه مباحث OPSEC و SECOPS رو در دوره مدیریت بحران سایبری بررسی و تدریس خواهم کرد.
👍4💯2
نگاهی به تاریخچه نشت ابزارهای تجاری هک
(از Red Team تا سلاح واقعی نزد مهاجمان)
مقدمه
در سال‌های اخیر، موجی از نشت و افشای ابزارهای حرفه‌ای و تجاری هک و Red Team به دست هکرها و مهاجمان واقعی افتاده است. ابزارهایی که اساساً با هدف تست نفوذ قانونی، ارزیابی امنیت سازمان‌ها و آموزش نیروهای امنیتی توسعه یافته‌اند، پس از نشت، به سلاح‌های مورد علاقه مهاجمان برای طراحی حملات واقعی تبدیل شده‌اند. این وقایع، چالش‌های تازه‌ای برای تیم‌های SOC و عملیات دفاعی به همراه آورده است.
موارد مشهور نشت ابزارهای هک (Timeline)
1. Hacking Team Leak (2015)
توضیح: شرکت ایتالیایی Hacking Team تولیدکننده نرم‌افزار نظارتی RCS Galileo بود. در سال ۲۰۱۵، نزدیک به ۴۰۰ گیگابایت داده شامل سورس‌کد و exploit به صورت عمومی نشت یافت.
پیامد: آسیب‌پذیری‌های zero-day، ابزارهای C2 و exploitها به صورت گسترده مورد سوءاستفاده مهاجمان از جمله APTها قرار گرفت.
2. Equation Group / Shadow Brokers Leak (2016-2017)
توضیح: گروه Shadow Brokers مجموعه ابزارهای هک متعلق به Equation Group (منسوب به NSA) را افشا کرد. ابزارهای مانند EternalBlue، DoublePulsar و غیره.
پیامد: رخدادهایی مانند حمله WannaCry، NotPetya و ظهور exploitation گسترده SMB.
3. Cobalt Strike Leaks
توضیح: ابزار Cobalt Strike یکی از محبوب‌ترین فریم ورک‌های C2 Red Team است که بارها نسخه کرک‌شده یا لو رفته آن در دارک‌وب و فروم‌ها پخش شده است.
پیامد: حضور گسترده مهاجمان حرفه‌ای، باج‌افزارها و گروه‌های APT در حملات واقعی با استفاده از نسخه‌های afk و obfuscated.
4. Brute Ratel Leak (2022)
توضیح: Brute Ratel یک ابزار C2 بسیار پیشرفته و ضد‌شناسایی است که پس از مدت کوتاهی از عرضه رسمی، نسخه‌ای از آن نشت پیدا کرد و در اختیار مهاجمان (حتی باج‌افزار) قرار گرفت.
پیامد: بالا رفتن قابلیت فرار از EDR/AV، حملات بسیار پیشرفته و دشواری کشف.
5. Mythic & Other C2 Frameworks
توضیح: ابزار Mythic (اپن‌سورس اما غیرتجاری)، همچنین فریم‌ورک‌های C2 جدید نیز بارها قربانی نشت یا سواستفاده توسط مهاجمان شده‌اند؛ گاهی حتی با «باینری‌های شخصی‌سازی‌شده» (custom build) در حملات واقعی کشف شده‌اند.
6. Shellter Elite Leak (2025)
توضیح: نشت نسخه تجاری Shellter Elite به دست مهاجمان و استفاده برای infostealer و bypass کردن EDRها.
دلایل و بسترهای نشت ابزارهای هک
۱. رخنه از سوی مشتریان نهایی (Buyers/Customers)
عدم رعایت OPSEC مشتری، سوءاستفاده عمدی، فروش مجدد در دارک‌وب
۲. هک شدن خود سازنده‌ها (developer breach)
رخدادهایی مانند HackingTeam و ابزارهای NSA
۳. افزایش جذابیت مالی برای مجرمان
فروش نسخه‌های کرک‌شده یا منتقل شده در بدافزار-as-a-service
۴. جنگ سرد سایبری و اسپانسرهای ملی
بازیگران دولتی ابزارها را به صورت عمدی یا اتفاقی نشت می‌دهند
۵-عدم پیگیری قضایی کافی در برخی کشورها
تأثیر و پیامدهای عملیاتی نشت ابزارهای تجاری هک
-افزایش حملات سطح بالا و پیچیده
-گیج شدن تیم‌های دفاعی و SOC(بدافزارها با امضای Red Team ساخته می‌شوند، خطاهای False negative و hunting سخت‌تر میشود)
-شتاب رشد ضد‌شناسایی (evasion techniques)
-ضرورت همکاری بیشتر بین تیم‌های توسعه ابزار و تیم‌های تحلیل تهدید
-ظهور بازارهای جدید برای بدافزارهای ناشی از این ابزارها
رویکردهای دفاعی برای SOC و مدیران امنیت
1-به‌روز نگه‌داشتن TI و IOC
توجه ویژه به تحلیل‌های فنی در مورد نسخه‌های afk یا لو رفته ابزارها
2-برقراری تماس مستقیم با سازندگان ابزارها برای هشدار‌دهی و رفع تهدید
3-توسعه Playbookهای Incident Response مخصوص ابزارهای مشهور نشت یافته
4-بهره‌گیری از Telemetry و رفتارشناسی (Behavioral Analytics به جای صرف امضا)
5-آموزش تیم‌های Blue Team با سناریوهای واقعی حمله Red Tool لو رفته
6-شناساگرهای memory-based و شبکه محور، به جای شناسایی صرف باینری
#آکادمی_روزبه
مرکز تخصصی CISSP
(از Red Team تا سلاح واقعی نزد مهاجمان)
مقدمه
در سال‌های اخیر، موجی از نشت و افشای ابزارهای حرفه‌ای و تجاری هک و Red Team به دست هکرها و مهاجمان واقعی افتاده است. ابزارهایی که اساساً با هدف تست نفوذ قانونی، ارزیابی امنیت سازمان‌ها و آموزش نیروهای امنیتی توسعه یافته‌اند، پس از نشت، به سلاح‌های مورد علاقه مهاجمان برای طراحی حملات واقعی تبدیل شده‌اند. این وقایع، چالش‌های تازه‌ای برای تیم‌های SOC و عملیات دفاعی به همراه آورده است.
موارد مشهور نشت ابزارهای هک (Timeline)
1. Hacking Team Leak (2015)
توضیح: شرکت ایتالیایی Hacking Team تولیدکننده نرم‌افزار نظارتی RCS Galileo بود. در سال ۲۰۱۵، نزدیک به ۴۰۰ گیگابایت داده شامل سورس‌کد و exploit به صورت عمومی نشت یافت.
پیامد: آسیب‌پذیری‌های zero-day، ابزارهای C2 و exploitها به صورت گسترده مورد سوءاستفاده مهاجمان از جمله APTها قرار گرفت.
2. Equation Group / Shadow Brokers Leak (2016-2017)
توضیح: گروه Shadow Brokers مجموعه ابزارهای هک متعلق به Equation Group (منسوب به NSA) را افشا کرد. ابزارهای مانند EternalBlue، DoublePulsar و غیره.
پیامد: رخدادهایی مانند حمله WannaCry، NotPetya و ظهور exploitation گسترده SMB.
3. Cobalt Strike Leaks
توضیح: ابزار Cobalt Strike یکی از محبوب‌ترین فریم ورک‌های C2 Red Team است که بارها نسخه کرک‌شده یا لو رفته آن در دارک‌وب و فروم‌ها پخش شده است.
پیامد: حضور گسترده مهاجمان حرفه‌ای، باج‌افزارها و گروه‌های APT در حملات واقعی با استفاده از نسخه‌های afk و obfuscated.
4. Brute Ratel Leak (2022)
توضیح: Brute Ratel یک ابزار C2 بسیار پیشرفته و ضد‌شناسایی است که پس از مدت کوتاهی از عرضه رسمی، نسخه‌ای از آن نشت پیدا کرد و در اختیار مهاجمان (حتی باج‌افزار) قرار گرفت.
پیامد: بالا رفتن قابلیت فرار از EDR/AV، حملات بسیار پیشرفته و دشواری کشف.
5. Mythic & Other C2 Frameworks
توضیح: ابزار Mythic (اپن‌سورس اما غیرتجاری)، همچنین فریم‌ورک‌های C2 جدید نیز بارها قربانی نشت یا سواستفاده توسط مهاجمان شده‌اند؛ گاهی حتی با «باینری‌های شخصی‌سازی‌شده» (custom build) در حملات واقعی کشف شده‌اند.
6. Shellter Elite Leak (2025)
توضیح: نشت نسخه تجاری Shellter Elite به دست مهاجمان و استفاده برای infostealer و bypass کردن EDRها.
دلایل و بسترهای نشت ابزارهای هک
۱. رخنه از سوی مشتریان نهایی (Buyers/Customers)
عدم رعایت OPSEC مشتری، سوءاستفاده عمدی، فروش مجدد در دارک‌وب
۲. هک شدن خود سازنده‌ها (developer breach)
رخدادهایی مانند HackingTeam و ابزارهای NSA
۳. افزایش جذابیت مالی برای مجرمان
فروش نسخه‌های کرک‌شده یا منتقل شده در بدافزار-as-a-service
۴. جنگ سرد سایبری و اسپانسرهای ملی
بازیگران دولتی ابزارها را به صورت عمدی یا اتفاقی نشت می‌دهند
۵-عدم پیگیری قضایی کافی در برخی کشورها
تأثیر و پیامدهای عملیاتی نشت ابزارهای تجاری هک
-افزایش حملات سطح بالا و پیچیده
-گیج شدن تیم‌های دفاعی و SOC(بدافزارها با امضای Red Team ساخته می‌شوند، خطاهای False negative و hunting سخت‌تر میشود)
-شتاب رشد ضد‌شناسایی (evasion techniques)
-ضرورت همکاری بیشتر بین تیم‌های توسعه ابزار و تیم‌های تحلیل تهدید
-ظهور بازارهای جدید برای بدافزارهای ناشی از این ابزارها
رویکردهای دفاعی برای SOC و مدیران امنیت
1-به‌روز نگه‌داشتن TI و IOC
توجه ویژه به تحلیل‌های فنی در مورد نسخه‌های afk یا لو رفته ابزارها
2-برقراری تماس مستقیم با سازندگان ابزارها برای هشدار‌دهی و رفع تهدید
3-توسعه Playbookهای Incident Response مخصوص ابزارهای مشهور نشت یافته
4-بهره‌گیری از Telemetry و رفتارشناسی (Behavioral Analytics به جای صرف امضا)
5-آموزش تیم‌های Blue Team با سناریوهای واقعی حمله Red Tool لو رفته
6-شناساگرهای memory-based و شبکه محور، به جای شناسایی صرف باینری
#آکادمی_روزبه
مرکز تخصصی CISSP
❤6
آشنایی با ابزارهای تجاری تیم قرمز
ابزار SHELLTER چگونه امنیت را دور می‌زند؟
۱. تزریق پویای بدافزار (Dynamic Shellcode Injection)
ابزار Shellter فایل اجرایی (exe) سالم و معتبری را برمی‌دارد و کد مخرب را به صورت داینامیک داخل آن تزریق می‌کند.
نقاط ورود (Entry point) را طوری تغییر می‌دهد که ابتدا کد خودش اجرا شود بعد برنامه اصلی.
این روش باعث میشود فایل نهایی از نظر ظاهری سالم و مثل فایل واقعی به نظر بیاید، حتی امضا (signature) و متادیتا هم حفظ میشود❗
۲. کد مخفی و تغییرشونده (Polymorphic Obfuscation)
کد مخرب دائماً خودش را تغییر می‌دهد (Polymorphic/Junk code) تا هیچ Signature ثابتی برای تشخیص وجود نداشته باشد.
ترکیبی از دستورات بی‌معنی (NOPها، دستورات بی‌اثر) و تغییر ساختار shellcode باعث گیج شدن ابزارهای تحلیل و AV میشود.
۳. بارگذاری مرحله‌ای و رمزنگاری شده (Staged & Encrypted Payload)
کد مرحله‌ای (Staged): مرحله اول فقط loader است، اصل بدافزار بعداً و با شرایط خاص decrypt و اجرا میشود.
محتوا اکثراً Encode یا Encrypt شده. تا موقع اجرا شدن، چیزی از بدافزار به چشم AV نمی‌آید.
۴. استفاده از APIهای معمولی و رفتار عادی سیستم (Living off the Land)
برای اختصاص حافظه و اجرای shellcode، دقیقاً مثل نرم‌افزارهای معمول از APIهای ویندوز مثل VirtualAlloc و CreateFileMapping استفاده می‌کند.
در نتیجه، رفتار آن خیلی به برنامه‌های قانونی شبیه است و hunting مبتنی بر رفتار (behavioral detection) نیز چالش دارد.
۵. فرار از تحلیل استاتیک و دینامیک (Static & Dynamic Evasion)
با افزودن لایه‌های junk code و rerouting execution، ابزارهای تحلیل مثل IDA Pro یا Sandbox را گمراه می‌کند.
حتی بعضی نسخه‌ها محیط اجرا را چک میکنند (Anti-VM)، اگر Sandbox یا VM باشد، اجرا نمی‌شوند یا رفتار جعلی نشان می‌دهند.
خلاصه ای بود از مقاله الستیک در لینک زیر
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.elastic.co/security-labs/taking-shellter?linkId=836491490
ابزار SHELLTER چگونه امنیت را دور می‌زند؟
۱. تزریق پویای بدافزار (Dynamic Shellcode Injection)
ابزار Shellter فایل اجرایی (exe) سالم و معتبری را برمی‌دارد و کد مخرب را به صورت داینامیک داخل آن تزریق می‌کند.
نقاط ورود (Entry point) را طوری تغییر می‌دهد که ابتدا کد خودش اجرا شود بعد برنامه اصلی.
این روش باعث میشود فایل نهایی از نظر ظاهری سالم و مثل فایل واقعی به نظر بیاید، حتی امضا (signature) و متادیتا هم حفظ میشود❗
۲. کد مخفی و تغییرشونده (Polymorphic Obfuscation)
کد مخرب دائماً خودش را تغییر می‌دهد (Polymorphic/Junk code) تا هیچ Signature ثابتی برای تشخیص وجود نداشته باشد.
ترکیبی از دستورات بی‌معنی (NOPها، دستورات بی‌اثر) و تغییر ساختار shellcode باعث گیج شدن ابزارهای تحلیل و AV میشود.
۳. بارگذاری مرحله‌ای و رمزنگاری شده (Staged & Encrypted Payload)
کد مرحله‌ای (Staged): مرحله اول فقط loader است، اصل بدافزار بعداً و با شرایط خاص decrypt و اجرا میشود.
محتوا اکثراً Encode یا Encrypt شده. تا موقع اجرا شدن، چیزی از بدافزار به چشم AV نمی‌آید.
۴. استفاده از APIهای معمولی و رفتار عادی سیستم (Living off the Land)
برای اختصاص حافظه و اجرای shellcode، دقیقاً مثل نرم‌افزارهای معمول از APIهای ویندوز مثل VirtualAlloc و CreateFileMapping استفاده می‌کند.
در نتیجه، رفتار آن خیلی به برنامه‌های قانونی شبیه است و hunting مبتنی بر رفتار (behavioral detection) نیز چالش دارد.
۵. فرار از تحلیل استاتیک و دینامیک (Static & Dynamic Evasion)
با افزودن لایه‌های junk code و rerouting execution، ابزارهای تحلیل مثل IDA Pro یا Sandbox را گمراه می‌کند.
حتی بعضی نسخه‌ها محیط اجرا را چک میکنند (Anti-VM)، اگر Sandbox یا VM باشد، اجرا نمی‌شوند یا رفتار جعلی نشان می‌دهند.
خلاصه ای بود از مقاله الستیک در لینک زیر
#آکادمی_روزبه
مرکز تخصصی CISSP
https://www.elastic.co/security-labs/taking-shellter?linkId=836491490
www.elastic.co
Taking SHELLTER: a commercial evasion framework abused in-the-wild
Elastic Security Labs detected the recent emergence of infostealers using an illicitly acquired version of the commercial evasion framework, SHELLTER, to deploy post-exploitation payloads.
❤5