بحث 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

عدم رمزنگاری: خود دنباله “در زدن” به صورت متن ساده (Plaintext) در شبکه ارسال می‌شود و توسط مهاجمی که ترافیک شبکه را شنود می‌کند (Sniffing) قابل مشاهده است. اگر مهاجم الگو را کشف کند، می‌تواند از آن برای باز کردن پورت برای خودش استفاده کند.
راه حل: استفاده از تکنیک Single Packet Authorization (SPA) که در آن یک بسته رمزنگاری شده و امضا شده (با کلید متقارن یا نامتقارن) ارسال می‌شود. ابزارهایی مانند fwknop این کار را انجام می‌دهند.
آسیب‌پذیری در برابر حملات Replay: اگر مهاجم دنباله را ضبط کند، می‌تواند آن را دوباره ارسال (Replay) کرده و پورت را باز کند.
مشکلات در شبکه‌های پیچیده (مانند NAT): اگر کاربر پشت یک شبکه NAT با چندین کاربر دیگر باشد، باز شدن پورت برای IP عمومی آن شبکه، دسترسی را برای همه کاربران آن شبکه باز می‌کند.
وابستگی به ترتیب بسته‌ها: در شبکه‌های پرازدحام، ممکن است بسته‌های “در زدن” با ترتیب اشتباه به سرور برسند و الگو شناسایی نشود. (استفاده از TCP به جای UDP می‌تواند این مشکل را تا حدی حل کند).

#آکادمی_روزبه

مقوله 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 مناسب برای محیط‌هایی که هم امنیت بالا می‌خواهند و هم سرویس‌ها باید کاملاً مخفی بمانند


#آکادمی_روزبه

نرم‌افزار ایده‌آل برای بک‌دور در راستای DLL Sideloading باید این ویژگی‌ها را داشته باشد:

🔸️ماژولار : طبیعتاً برنامه باید چند فایل DLL داشته باشد که بتوانیم روی آنها بک‌دور قرار دهیم. منظور ما DLLهای اختصاصی خودِ نرم‌افزار است، نه DLLهای سیستمی.

🔸️قابل بارگذاری جانبی DLL (DLL Sideloadable) : برنامه باید زمانی که به مسیر دیگری منتقل می‌شود، در برابر تکنیک DLL sideloading آسیب‌پذیر باشد.

🔸️کوچک : فراموش نکنید که قرار است این را برای قربانی بفرستیم، پس حجم آن نباید 30 گیگابایت باشد.

🔸️محبوب :باید نرم‌افزاری رایج باشد، چیزی که سامانه EDR بارها و بارها در سراسر جهان دیده است. مثل ابزارهای فشرده‌سازی (۷zip، WinRAR)، ویرایشگرهای سبک (Notepad++)، نمایشگرهای PDF، یا نمایشگرهای تصویر.

🔸️دارای امضای دیجیتال (Digitally signed) : برنامه باید معتبر بوده و با گواهی دیجیتال معتبر امضا شده باشد.


#آکادمی_روزبه

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

روزبه نوروزی

مقدمه: نگاهی به یک سناریوی نگران‌کننده

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

شرح واقعه: شناسایی یک فعالیت غیرعادی

همه چیز از یک هشدار در سیستم نظارت بر لاگ‌ها (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):

پایان قسمت اول

قسمت دوم

مهم‌ترین درس آموخته، درک ارزش استراتژی Application Allowlisting بود. به جای تلاش برای شناسایی و مسدود کردن بی‌نهایت ابزار مخرب (Blacklisting)، ما باید به یک مدل "اعتماد صفر" (Zero Trust) روی بیاوریم. در این مدل، به طور پیش‌فرض اجرای تمام برنامه‌ها مسدود است، مگر آنکه صراحتاً در لیست برنامه‌های مجاز و ضروری کسب‌وکار قرار گرفته باشند. اگر چنین سیاستی در آن زمان پیاده‌سازی شده بود، مهاجم هرگز قادر به اجرای winpmem.exe یا vol.exe نبود و حمله در نطفه خفه می‌شد.

نتیجه‌گیری: از واکنش‌گرایی به پیشگیری

تجربه‌ی مواجهه با سوءاستفاده از ابزارهای DFIR، یک زنگ بیدارباش برای تیم ما بود. این حادثه نشان داد که مهاجمان مدرن، هوشمندانه عمل کرده و از نقاط کور امنیتی ما بهره‌برداری می‌کنند. ما آموختیم که دفاع مؤثر دیگر تنها به معنای مسدود کردن بدافزارها نیست، بلکه نیازمند درک عمیق "رفتار نرمال" در شبکه و ایجاد هشدار برای هرگونه انحراف از آن است. حرکت به سمت استراتژی‌های پیشگیرانه‌ای مانند Application Allowlisting و نظارت رفتاری، گام بعدی و ضروری برای تقویت وضعیت امنیتی هر سازمانی در برابر تهدیدات امروزی است.


#آکادمی_روزبه
ارائه درس سنر ۶۰۸ به همراه درس آموخته ها برای انتقال تجربیات به تمام کارشناسان سازمانها

سناریوی حمله: ربودن 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 قابلیت اجرا ندارد.


#آکادمی_روزبه

📝 تجربه من با USN Journal در فارنزیک دیجیتال

در یکی از پروژه‌های تحلیل حادثه، به نقطه‌ای رسیدیم که لاگ‌های سنتی سیستم تقریباً پاک یا دستکاری شده بودند. برای یافتن رد مهاجم، سراغ USN Journal رفتیم؛ ژورنال سیستم NTFS که همه تغییرات فایل‌ها را حتی پس از حذف آنها؛ثبت می‌کند.

این کشف برایم شبیه ورق زدن دفترچه مخفی سیستم بود: هر ورودی، یک سرنخ از زمانی که فایلی ایجاد، ویرایش یا حذف شده است. با استفاده از ابزارهای متن‌باز مانند MFTECmd، توانستیم خط زمانی دقیقی از فعالیت مهاجم بسازیم؛ حتی لحظه نصب ابزارهای مخرب و پاک‌سازی آثار را بازیابی کردیم.

مهم‌ترین درس:

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

در دنیای امنیت، همان‌طور که در اقتصاد یا روانشناسی هم می‌بینیم، ردپاها معمولاً در جایی ماندگار می‌شوند که کمتر به چشم می‌آیند.

#آکادمی_روزبه

ابزار، منتها را نشان نمیدهد؛ این «سؤال‌های درست پرسیدن» است که تحلیلگر واقعی می‌سازد.

چرا بعضی متخصصان امنیت با وجود دانش فنی، در تحلیل‌های امنیتی ضعف دارند؟




بر اساس مشاهداتم در دنیای SOC، DFIR و Threat Hunting، دلایل اصلی را می‌توان اینطور دسته‌بندی کرد:

۱. نگاه ابزاری به جای نگاه تحلیلی

بعضی‌ها یاد گرفته‌اند که با SIEM، EDR یا ابزارهای DFIR کار کنند، اما تحلیل را مساوی با خروجی ابزار می‌دانند. در واقع، ابزار فقط «چراغ‌قوه» است؛ مسیر و روایت را باید خود تحلیلگر بسازد.

۲. ضعف در مدل‌سازی ذهنی تهدید

بدون یک طرح ذهنی از مهاجم، تاکتیک‌ها و زنجیره حمله (Kill Chain / ATT&CK)، داده‌ها مثل تکه‌های پازل بی‌معنی به نظر می‌رسند. در نتیجه تحلیل‌ها سطحی می‌مانند.

۳. انتظار دیدن نشانه‌های واضح

حمله‌های مدرن معمولاً در لایه «تقریباً عادی» حرکت می‌کنند — مثل اجرای یک باینری مایکروسافت اما با تغییر جزئی. کسانی که فقط به دنبال «علامت خطر قرمز» هستند، اقدامات مخفی را نمی‌بینند.

۴. کمبود تجربه بین‌دامنه‌ای

تحلیل امنیتی فقط دانش سایبری نیست؛ باید کمی روانشناسی مهاجم، اقتصاد حملات (ROI)، و حتی الگوهای رفتاری کاربر را هم فهمید. این لایه‌ی شناخت، مهارت شناسایی الگو را چند برابر می‌کند.

۵. نبود تمرین حل مسئلهٔ خام

مثل عضلات بدن، ذهن تحلیلی هم با تمرین قوی می‌شود — مثلاً تحلیل لاگ خام، بررسی PCAP بدون فیلتر، یا شبیه‌سازی سناریوهای مبهم. بسیاری به خاطر عدم تمرین، در مواجهه با داده‌های بی‌ساختار قفل می‌کنند.

با آمدن مثلا اسپلانک ES یا UBA و همچنین مخازن سیگما ؛ عملا ذهن یوزکیس نویسان رو به تنبلی می‌گذارد.


#آکادمی_روزبه

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

لینک خبر
https://lnkd.in/dJSmhCxt

کیا مواظب باشند ؟
توسعه‌دهندگان یا تیم‌هایی که از Node.js و npm برای ساخت سایت، سرویس یا ابزار استفاده می‌کنند.
کسانی که CI/CD (خط خودکار build و deploy) دارند و به‌صورت خودکار آخرین نسخه پکیج‌ها را می‌گیرند، چون آلودگی خیلی سریع وارد فرآیند عملیاتی می‌شود.
حتی اگر مستقیم از این پکیج‌ها استفاده نکنید، ممکن است به‌صورت غیرمستقیم (dependency) داخل پکیج‌های دیگر باشند.

#آکادمی_روزبه

موضوع تحقیق:
مدلهای زبانی در SOC لایه ۱

۵ مدل LLM (مثل GPT‑4o، LLaMA 3، Mixtral، و چند مدل دیگر) را تست کرده‌اند.
وظیفه: تشخیص اینکه هشدارهای امنیتی شبیه‌سازی‌شده «جالب» (یعنی نیازمند پیگیری) هستند یا «بی‌اهمیت».
محیط تست: SOC شبیه‌سازی‌شده با Wazuh و CALDERA.

نتایج کلیدی:

این LLMها می‌توانند triage اولیه را سریع‌تر کنند و فشار فکری روی آنالیست را کاهش دهند.
با زبان طبیعی، توضیح می‌دهند چرا تصمیمی گرفته‌اند — این برای تصمیم‌گیری کمک می‌کند.
هنوز چالش‌ها وجود دارد:
مسأله Hallucination (پاسخ اشتباه ولی با اطمینان)،
پیچیدگی ادغام در سیستم‌های موجود،
ریسک حریم خصوصی.

نتیجه‌گیری:

این مدل‌ها جایگزین آنالیست انسانی نمی‌شوند.
ولی به عنوان دستیار (copilot) می‌توانند کار SOC را سریع‌تر، کارآمدتر و مقاوم‌تر کنند

#آکادمی_روزبه

و تمپلیت های جالب

#آکادمی_روزبه

https://github.com/chocolatecoat/DFIR-Templates

بلوغ شناسایی تهدید با کمک AI در XDR

استفاده طولانی‌مدت از پلتفرم‌هایی مانند Trend Micro Vision One که با آنها کار کرده ام ، تنها به معنی داشتن ابزار بهتر نیست؛ بلکه فرصتی برای ساخت یک «ماشین شناسایی دقیق» فراهم می‌کند.

در ماه‌های ابتدایی، سیستم AI سعی می‌کند از میان داده‌های لایه‌های مختلف (ایستگاه کاری، سرور، ایمیل، شبکه و غیره) الگو بسازد. این مرحله پر از نویز است، اما تدریجاً یک Baseline از رفتار عادی سازمان شکل می‌گیرد.

با گذشت زمان و بازخورد مداوم تیم SOC، مدل‌های هوش مصنوعی نه‌تنها رفتارهای عمومی تهدیدات، بلکه نشانه‌های خاص حمله‌گر به سازمان شما را نیز یاد می‌گیرند. هم‌زمان، همبستگی رویدادها (Event Correlation) عمیق‌تر می‌شود و داده‌های بین لایه‌ای تصویر کامل‌تری از زنجیره حمله ارائه می‌دهند.

نتیجه این بلوغ تدریجی؟

وجود True Positive بالاتر و کاهش آلارم‌های اشتباه.
و MTTD کوتاه‌تر و واکنش سریع‌تر.
شناسایی تهدیدات پیچیده‌ای که در شروع کار از چشم پنهان می‌ماندند.

این روند را می‌توان در «منحنی بلوغ شناسایی» دید؛ جایی که از یادگیری اولیه تا شناسایی هوشمند، فاصله‌ای پر از داده، تجربه و تعامل انسان و AI پیموده می‌شود

#آکادمی_روزبه

روشهای من برای منتورینگ یکساله دوره آمادگی آزمون CISSP
قسمت اول

مدل انگیزه‌سازی CISSP بر اساس Hyperbolic Discounting

الهام از اقتصاد + روان‌شناسی

1. تقسیم هدف بزرگ به “کمپین‌های کوچک با پاداش سریع”
به جای گفتن «۶ ماه بخونیم تا مدرک رو بگیرید»، مسیر رو به ۶ ماژول ۳–۴ هفته‌ای تقسیم میکنیم
هر ماژول با یک مینی‌پروژه یا کوییز سخت جمع‌بندی میشه و در پایان، یک جایزه کوچک (گواهی داخلی، یادگاری، یا حتی یک افتخارنامه گروهی در چت کلاس).

2. اثر Snowball پیشرفت

یک «برد پیشرفت فیزیکی» یا آنلاین درست میکنم که دانشجو هر هفته آن را به‌روزرسانی میکند.
دیدن درصد پیشرفت روی نمودار حس رضایت آنی می‌دهد (پاداش سریع)، حتی اگر آزمون اصلی ماه‌ها بعد باشد.

3. پاداش هم‌زمانی و رقابت سالم

بین کلاسهای هرسال، گروه‌های مطالعه ۳–۴ نفره ایجاد میکنم که عملکردشان مقایسه شود.
رقابت سالم، مغز را مجبور می‌کند لذت کوتاه‌مدت «پیشی گرفتن» را بالاتر از لذت تنبلی ببیند.

4. استفاده از اصل Loss Aversion

سیستم تعهد مالی یا امتیازی: دانشجو مبلغ یا اعتبار امتیازی می‌گذارد و اگر هفته‌ای حداقل مطالعه را انجام ندهد، آن را از دست می‌دهد.
این بهره‌گیری از ترسِ از دست دادن (نه فقط امید به کسب) انگیزه‌ی پایدارتری ایجاد می‌کند.

5. نمایش “پاداش نهایی” به صورت واقعی و زنده

هر ترم یک مهمان (CISSP دار) را دعوت میکنم تا داستان شغل و درآمدش را تعریف کند.
این کار پاداش نهایی را از یک تصویر مبهم به یک انگیزه ملموس و فوری تبدیل می‌کند.

6. مینی‌پیش‌بینی آزمون (Micro-Exam Forecasting)

هر سه ماه یک شبیه‌سازی کوتاه آزمون میدهم و رشد امتیاز را نمایش میدهم .
مغز وقتی نمودار نمره‌اش رو به بالا می‌بیند، حس «پاداش همین الان» را تجربه می‌کند.


**این روش بخشی از روش منتوینگ من است که برای دوستانی اجرا می‌شود که تعهد برای آزمون دارند .


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

Www.haumoun.com
Www.Roozbeh.academy

مقاله «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

ما برنامه ریزی کرده‌ایم که در ذیل مجوز افتا ؛ درشرکت هامون ارائه خدمات SOC را تحت نظر اینجانب داشته باشیم .

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

الف:
اگر مشکلی در Compliance نباشد ، به جای جمع‌آوری هر نوع لاگی (verbose logging)، ابتدا میپرسیم : “برای شناسایی تکنیک‌های خاص حمله (مثلاً تکنیک‌های چارچوب MITRE ATT&CK)، دقیقاً به چه داده‌هایی نیاز داریم؟” این سوال، رویکرد ما را از جمع‌آوری کورکورانه به جمع‌آوری هدفمند تغییر میدهد .

مثلاً برای شناسایی حرکت جانبی (Lateral Movement) با استفاده از PsExec، به لاگ‌های ایجاد سرویس (Event ID 7045) و لاگ‌های دسترسی به admin$ share روی سیستم مقصد نیاز داریم. بدون این‌ها، هزاران گیگابایت لاگ دیگر بی‌فایده خواهد بود.

Www.haumoun.com

ادامه دارد ....

#تجربه

شکار Mimikatz فراتر از لاگ‌های ویندوز با Splunk Stream

چهارشنبه گذشته، در حین پایش آلرت ها در SOC ، به رویدادی غیرمعمول برخوردیم.

مهاجم توانسته بود با استفاده از Mimikatz، اطلاعات Credential را از حافظه استخراج کند و بلافاصله لاگ‌های ویندوز را پاک کند، به طوری که تحلیل مبتنی بر Event Log تقریباً غیرممکن شده بود.

خوشبختانه، پیرو متدولوژی که من در تدریس هایم هم میگویم-- یعنی اخذ لاگ از منابع چند وجهی-- ؛ ما از مدتی قبل یک رویکرد لایه‌ای در معماری امنیتی خود پیاده کرده بودیم: مانیتورینگ هم‌زمان لاگ‌ها، داده‌های Endpoint، و ترافیک شبکه با Splunk Stream. به همین دلیل، حتی وقتی لاگ محلی حذف شد، جریان ترافیک شبکه همچنان در Splunk ضبط شده بود.

با تحلیل عمیق بسته‌ها (DPI)، متوجه الگویی شدیم که به تعاملات RPC/SAMR مشکوک مربوط بود؛ رفتاری که معمولاً در سناریوی Remote SAM Dump توسط Mimikatz دیده می‌شود. Rule تشخیصی که از قبل روی Stream تعریف کرده بودیم، دقیقاً در همان لحظه فعال شد و هشدار زنده داد.

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


#تجربه ای از تیم SOC شرکت هامون
Www.haumoun.com

#بیاموزیم
#به_اشتراک_بگذاریم
#تجربه

چرا به SOC و CERT خوب نیاز داریم ؟
بررسی تحلیلی ماهیت مهندسی کشف با مثال

🔆در مجموعه پست هایی من قصد دارم شما رو با چرایی نیاز به مرکز عملیات امنیت به شکل کاربردی آشنا کنم از زاویه ای که شاید جذاب باشه

🟣عنوان کلی :
چگونه SOC میتواند حملات روز صفر را قبل از تولدشان شکار کند؟ (درس‌هایی از Zerologon)

1️⃣قسمت اول
آسیب پذیری Zerologon: روزی که یک “صفر”، امپراتوری مایکروسافت را به لرزه درآورد!

آیا می‌دانستید یک اشتباه برنامه‌نویسی ساده در پروتکلی ۳۰ ساله، می‌توانست در ۳ ثانیه کنترل کامل شبکه شما را به دست یک مهاجم بدهد؟ این داستان خطرناک اما واقعیِ Zerologon (CVE-2020-1472) است.

این آسیب‌پذیری به مهاجمان اجازه می‌داد با ارسال بسته‌هایی پر از “صفر”، رمز عبور قلب شبکه (Domain Controller) را خالی کرده و به بالاترین سطح دسترسی برسند. Zerologon یک زنگ بیدارباش بود: تکیه بر دیوارهای دفاعی و پچ‌های امنیتی به تنهایی کافی نیست.

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

هدف من این است که فراتر از هیاهوی آسیب‌پذیری‌ها برویم و درک کنیم که با داشتن دید کامل، تحلیل رفتار و رویکرد شکار تهدید (Threat Hunting)، می‌توانیم امیدوار باشیم که ناشناخته‌ها را شکار کنیم و یک قدم از مهاجمان جلوتر باشیم.

همراه من باشید تا مرحله به مرحله ببینید چگونه یک SOC خوب، کتابخانه تهدیدات نیست، بلکه یک موتور پیش‌بینی و شکار ناهنجاری است.

ادامه در پستهای بعد...

💫درسهایی از دوره SOC شرکت هامون
Www.haumoun.com

#CyberSecurity #Zerologon #ThreatHunting #SOC #CERT #BlueTeam #ZeroDay #InfoSec #Microsoft #LateralMovement

این مطلب در مدیوم یک معرفی عملیاتی و قابل‌فهم از سه ابزار کلیدی برای تهدیدیابی است: YARA، Loki و Valhalla. نویسنده ابتدا با YARA شروع می‌کند؛ ابزاری متن‌باز که با استفاده از الگوهای متنی یا باینری، بدافزارها را شناسایی و طبقه‌بندی می‌کند. او به‌طور گام‌به‌گام نحوه نوشتن یک قانون YARA، تست آن روی فایل‌های نمونه، و استفاده از عملگرهای منطقی را توضیح می‌دهد. اهمیت این ابزار در Threat Hunting این است که می‌توان قوانینش را بر اساس ویژگی‌های خاص یک خانواده بدافزاری سفارشی‌سازی کرد. گرچه بخش‌های مربوط به Loki و Valhalla در ادامه مقاله است، اما با همین شروع، ارزش آموزشی مطلب مشخص است: کمک به تحلیلگران برای ساخت یک پایه فنی قوی در شناسایی الگوها و ترکیب این قابلیت با سایر ابزارهای شکار تهدید. این دانش، به‌ویژه برای کشف تهدیدات ناشناخته یا Zero-Day، ضروری است و پایه‌ای برای اتوماسیون در تحقیقات امنیتی فراهم می‌کند.

#آکادمی_روزبه و
مرکز ارائه خدمات SOC هامون

https://medium.com/@avfaulkner/intoduction-to-yara-loki-and-valhalla-for-threat-hunting-63038a0873e0

واتس اپ09902857290

مطالعه امشب من

خاص
https://assets-eu.researchsquare.com/files/rs-4341401/v2_covered_339cc0d0-2c38-4942-a53c-ae9f3f6a6f69.pdf?c=1740733329