تمرین



بخش اول: برنامه ساده C شارپ که چند System Call صدا می‌زنه

این برنامه یک فایل متنی ایجاد می‌کنه، داخلش می‌نویسه، از شبکه استفاده می‌کنه، و سپس می‌خوابه.

using System;
using System.IO;
using System.Net;
using System.Threading;

class Program
{
static void Main(string[] args)
{
Console.WriteLine(" شروع برنامه...");

// 1. ایجاد و نوشتن در فایل
string path = "test_log.txt";
File.WriteAllText(path, "این یک تست است.\n");

// 2. ارسال یک درخواست ساده HTTP
using (var client = new WebClient())
{
string result = client.DownloadString("http://example.com");
Console.WriteLine(" داده از example.com دریافت شد.");
}

// 3. وقفه
Thread.Sleep(3000);

Console.WriteLine(" پایان برنامه.");
}
}


بخش دوم: چطور System Callها رو ببینیم؟
🔹 برای ویندوز (با استفاده از Procmon)

ابزار: Process Monitor (Procmon)
📌 مراحل:

Procmon را اجرا کنید.

فیلتر زیر را تنظیم کنید:

Process Name is Program.exe (یا اسم اجرایی برنامه C# خودتون)

حالا برنامه C# رو اجرا کنید (مثلاً dotnet run یا .exe تولید شده رو مستقیم اجرا کنید).

در Procmon، خواهید دید:

CreateFile

WriteFile

ReadFile

RegOpenKey

TCP Connect

Sleep (به شکل وقفه بین درخواست‌ها)

می‌تونید روی هر آیتم دابل‌کلیک کنید و جزئیات رو ببینید: مسیر فایل، نتیجه API، رجیستری‌ها و حتی IP مقصد.


سوالات برای بحث :

آیا مسیر فایل نوشته شده در System Call‌ها با چیزی که انتظار داشتید، هم‌خوانی داشت؟

آیا برنامه به دامنه‌ای متصل شد که انتظارش رو نداشتید؟

چه اطلاعاتی از رفتار برنامه فقط از طریق شنود API متوجه شدید؟


#آکادمی_روزبه
مرکز تخصصی CISSP

تئوری و تمرین ضروری برای یادگیری

خلاصه دو پست قبل برای مرور


دنبال این بودیم که بفهمیم وقتی یک برنامه با سیستم‌عامل کار می‌کنه (مثل خوندن یا نوشتن فایل، یا وصل شدن به اینترنت)، در پشت‌صحنه چه اتفاقی می‌افته و چطور می‌تونیم اون دستورات یا "درخواست‌ها" رو که به سیستم داده می‌شه ببینیم.

به این درخواست‌ها می‌گیم:
👉 System Call (یا API Call به سیستم‌عامل)

🧪 آزمایشی که انجام دادیم:

یه برنامه ساده با زبان C شارپ نوشتیم که:

یه فایل می‌سازه و داخلش می‌نویسه.

به یه سایت وصل می‌شه و اطلاعاتی می‌گیره.

چند ثانیه صبر می‌کنه.

بعد با استفاده از ابزار Procmon (برای ویندوز) اومدیم:

ببینیم برنامه دقیقاً چه کارهایی انجام داده.

مثلاً چه فایلی باز کرده؟ آیا واقعاً به اینترنت وصل شده؟ چقدر طول کشید؟

✅ نتیجه:

ما تونستیم درخواست‌های پنهان بین برنامه و سیستم‌عامل رو ببینیم. این کار در تحلیل بدافزار، بررسی امنیت، یا حتی رفع باگ خیلی مهمه.



#آکادمی_روزبه
مرکز تخصصی CISSP
آموزش تئوری و عملی

سناریو کارگاه: تحلیل ایمیج دیسک “مرده” ویندوز با Velociraptor

#آکادمی_روزبه
مرکز تخصصی CISSP


https://kyjonin.blogspot.com/2025/05/velociraptor-dead-disk-forensics.html?m=1

اشک شوق برای تلاش و پشتکار و شب نخوابی ها برای علم آموزی و پیشرفت 🥹🥹👏👏👏

ترجمه



امروز، چیزی کوچک از طریق پست رسید — اما وزنی دارد که فقط دارندگان CISSP واقعاً آن را درک می‌کنند.
این سنجاق کت (lapel pin) چیزی فراتر از یک مدرک را نشان می‌دهد. این یک یادآور بی‌صدای شب‌های طولانی، جلسات مطالعه بی‌وقفه، تمرین‌های بی‌پایان و تعهد به رعایت بالاترین استانداردها در حوزه امنیت سایبری است.

پوشیدن آن ( زدن به سینه )فقط مربوط به حروف نیست — بلکه مربوط به مسیر، رشد، و مسئولیتی است که با آن همراه است.

برای همه کسانی که هنوز در این مسیر هستند: ادامه بدهید. ارزشش را دارد، در هر قدم.

#CISSP #ISC2

(در تصویر پایین نیز سنجاق رسمی CISSP را روی کارت خوش‌آمدگویی ISC2 می‌بینیم که نوشته:
"Your journey begins here." یعنی: "سفر شما از اینجا آغاز می‌شود.")


#آکادمی_روزبه
مرکز تخصصی CISSP

اتمام خوانش کتاب Evasive Malware بدافزار های پیشرفته ( شناخت ، بررسی و روش کشف) با ۲۶۰ نفر در گروه کانال تلگرام آکادمی روزبه

امیدوارم موثر واقع شده باشه

و ادای دینی هم به مردم و دانشجوهای کشور و توسعه علم باشه

روزبه نوروزی

من که گفتم مشاوران امنیت شبکه بانکی و برخی مسوولین امنیت اون رو باید یه جاروی درست حسابی کرد... ولی کسی گوش نکرد !!

این مشاوران و مسوولین سالهاست دربین بانک‌ها درحال چرخش هستند و حالا داره مشخص میشه اثراتش

منکر تلاش عزیزانی که دل در گرو کار دارند و عزیزانی که اگر بلد نیستند کنار می‌کشند نیستم
همین که شبکه بانکی الان درحال خدمت رسانی به مردم هست نشان از وجود تعدادی افرادی لایق و باسواد است ؛ ولی خوب که نگاه کنید از ۱۰ سال پیش بانک ها و مراکز درحال هک شدن هستند و مشاوران تقریبا همان و مسوولین هم اگر ارتقاء نگرفته و پست بهتری نگرفته باشند از بانکی به بانک دیگر جابجا شده اند و کسی نپرسیده درجای قبلی که نفوذ رخ داد چقدر مسوولیت داشتی و چه شد که هک شدید ؟ ( شاید هم بوده و من نمیدانم )

درضمن اگر با من آشنا باشید میدانید همینطوری صحبت نمیکنم و برای صحبت هایم دلایل و مصادیق دارم و اصولا همیشه علم مبنای بیانهایم است. و چون نمی‌شود الان به جزئیات بیان کرد نظر کلی و کارشناسی خودم رو فقط مینویسم.

چرا Live Forensics اهمیت دارد؟

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

مهاجم ممکن است مکانیزم‌هایی طراحی کرده باشد که با خاموش شدن سیستم، آثار حمله حذف شوند.

برخی شواهد مانند اطلاعات RAM فقط در زمان اجرا قابل دسترسی هستند.

خاموش کردن سرورهای حیاتی می‌تواند آسیب‌های جدی به کسب‌وکار وارد کند.

بنابراین تحلیل زنده بهترین گزینه برای حفظ یکپارچگی داده‌ها و انجام بررسی سریع است. یعنی شکافتن بدن رایانه درحالت زنده!!

چالش‌ها و ملاحظات

اگرچه Live Forensics ابزار قدرتمندی است، اما نیازمند رعایت دقت بالاست. هرگونه اقدام نادرست می‌تواند موجب تغییر در وضعیت سیستم شده یا اعتبار شواهد را زیر سؤال ببرد. به همین دلیل، کارشناسان باید از ابزارهای Read-Only استفاده کرده و هر قدم را مستند کنند.


#آکادمی_روزبه
مرکز تخصصی CISSP

بازم یه نکته علمی اما این بار از جنگ


اگر در این ساعت، یعنی ۸ صبح مورخ ۳ تیرماه ۱۴۰۴ خبر برقراری آتش بس صحیح باشه و پایدار ؛زمان خوبیه برای شروع یه کار مهم : تدوین درس آموخته !!

درس آموخته یا Lesson learned یا همون تجربه خودمون ، امروزه در بسیاری از استاندارد ها منجمله PMBOK و... خودش منبع دانش است که بعنوان ارجاع به حل مشکلات و موانع مورد استفاده قرار میگیره .

لذا من پیشنهاد میکنم در هر سطح و لایه و هر عمقی شروع به جمع آوری و ثبت درس آموخته ها بشه .

اینها یک منبع دانش غنی برای ما و نسل آینده است


#آکادمی_روزبه
مرکز تخصصی CISSP
Www.Roozbeh.academy

هرچی فکر میکنم میبینم جای یه تبریک به مردم ایران بابت آتش بس و رسیدن به آرامش خالیه 💐🌹

انشالله روال زندگی عادی براتون جاری بشه

این تبریک رو خصوصا برای اقشار جامعه که در لبه های خطرناک اقتصادی قراردارند تقدیم میکنم؛
امیدوارم زندگیشون به حالت عادی برگرده و مثلا اگر بیکار شدن برگردن سر کار یا حقوق عقب مانده پرداخت بشه و کالای مورد نیازشون رو داشته باشند .

روزبه نوروزی
سوم تیرماه ۱۴۰۴
Www.Roozbeh.academy
#آکادمی_روزبه
مرکز تخصصی CISSP

این حمله از یک ضعف منطقی در لینک‌های دعوت Discord سوءاستفاده می‌کند. مهاجم لینک معتبر یک سرور معروف را کپی می‌کند و پس از منقضی شدن آن، همان کد را روی سرور مخرب خودش ثبت می‌کند. کاربران با کلیک روی لینک، به سرور جعلی منتقل می‌شوند و برای تأیید هویت، یک اسکریپت مخرب PowerShell به آن‌ها داده می‌شود که پس از اجرا، سیستم قربانی را آلوده می‌کند. این روش به دلیل اعتماد کاربران به لینک قبلی و نبود کنترل روی کدهای منقضی شده مؤثر است و نشان می‌دهد صرفاً اسکن امنیتی کافی نیست.

#آکادمی_روزبه
مرکز تخصصی CISSP


https://rohittamma.substack.com/p/how-attackers-weaponized-an-expired

بررسی تکنیک فراخوانی توابع DLL با Ordinal: تهدیدی پنهان در حملات مبتنی بر LOLBIN

در فضای امنیت سایبری، یکی از روش‌های زیرکانه که مهاجمان و بدافزارها برای پنهان‌کاری استفاده می‌کنند، فراخوانی توابع یک DLL با استفاده از شماره ترتیبی (Ordinal) به‌جای نام تابع است. این تکنیک عمدتاً در سوءاستفاده از LOLBINها (ابزارهای بومی سیستم‌عامل که برای اهداف مخرب به کار گرفته می‌شوند) دیده می‌شود.

برای مثال، در دستور زیر:

rundll32.exe comsvcs.dll,#24

تابع شماره ۲۴ از فایل comsvcs.dll اجرا می‌شود. اگر تحلیل‌گر نداند این شماره به چه تابعی اشاره دارد، عملاً درک دقیقی از عملکرد این دستور نخواهد داشت. در این مثال، شماره ۲۴ معمولاً به تابع MiniDumpW مربوط است که برای استخراج حافظه فرآیندهایی مانند LSASS به‌کار می‌رود و می‌تواند منجر به سرقت رمزهای عبور شود.

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

توابع مخرب را با ظاهری بی‌خطر فراخوانی کنند.

وDLLهای جعلی ایجاد کنند که ظاهر و نام مشابه دارند اما رفتار داخلی کاملاً متفاوت است.

از این طریق ابزارهای دفاعی مبتنی بر تشخیص مبتنی بر نام تابع را دور بزنند.

برای مقابله با این روش، اسکریپت‌های تحلیلی مانند PowerShell معرفی‌شده در این زمینه، جدول صادرات (Export Address Table) DLL را استخراج می‌کنند و با نگاشت اعداد Ordinal به نام توابع واقعی، امکان تحلیل دقیق را فراهم می‌کنند.

جمع‌بندی:
این تکنیک یک روش کلاسیک برای استتار اقدامات مخرب است که در ترکیب با LOLBINها یا DLLهای جعلی، می‌تواند امنیت سازمان‌ها را تهدید کند. بنابراین، تحلیل عمیق فراخوانی‌های DLL و داشتن ابزارهای مناسب برای ترجمه Ordinal به نام تابع، برای تیم‌های شکار تهدید و تحلیل بدافزار ضروری است.


#آکادمی_روزبه
مرکز تخصصی CISSP



نمونه کد


# مسیر DLL هدف را مشخص کنید
$dllPath = "C:\Windows\System32\comsvcs.dll"

# بارگذاری DLL با استفاده از Reflection
Add-Type @"
using System;
using System.Runtime.InteropServices;

public class NativeMethods {
[DllImport("kernel32.dll", CharSet = CharSet.Auto)]
public static extern IntPtr LoadLibrary(string lpFileName);

[DllImport("kernel32.dll", CharSet = CharSet.Auto)]
public static extern IntPtr GetProcAddress(IntPtr hModule, IntPtr ordinal);
}
"@

# بارگذاری DLL
$dllHandle = [NativeMethods]::LoadLibrary($dllPath)

if ($dllHandle -eq 0) {
Write-Host "خطا در بارگذاری DLL"
exit
}

# حلقه برای بررسی تعدادی Ordinal (مثلاً 1 تا 50)
1..50 | ForEach-Object {
$ordinal = $_
$ordinalPtr = [IntPtr]::op_Explicit($ordinal)

$procAddress = [NativeMethods]::GetProcAddress($dll

بررسی آسیب‌پذیری Heap Overflow و اجرای کد از راه دور در Llama.cpp


در سال‌های اخیر، ابزارهای اجرای مدل‌های زبانی به‌شدت فراگیر شده‌اند و پروژه‌های متن‌باز مانند llama.cpp به کاربران اجازه می‌دهند مدل‌های پیشرفته را به‌صورت محلی و بدون نیاز به سخت‌افزار قدرتمند اجرا کنند. اما محبوبیت این ابزارها باعث شده است که سطح حمله (Attack Surface) نیز گسترش یابد.
در یک پژوهش عمیق، Patrick Peng موفق شد آسیب‌پذیری خطرناکی را در بخش RPC Server کتابخانه llama.cpp کشف کند که می‌تواند منجر به اجرای کد از راه دور (RCE) شود. این آسیب‌پذیری در تابع ggml_backend_cpu_buffer_cpy_tensor() نهفته است که برای کپی داده‌های Tensor در حافظه استفاده می‌شود.
هرچند کد پروژه شامل بررسی‌های مرزی، assertهای متعددی و مکانیزم‌های دفاعی سطح بالا است، اما نویسنده موفق شد با دستکاری هوشمندانه پارامترهای ne[] و nb[] که ابعاد و اندازه داده‌های Tensor را کنترل می‌کنند، یک Heap Overflow ایجاد کند. این نوع از overflow برخلاف buffer overflow کلاسیک، حافظه Heap را هدف قرار می‌دهد و می‌تواند ساختارهای مجاور حافظه را تغییر دهد.
اما بهره‌برداری از این نقص آسان نبود. به گفته نویسنده، طبیعت پیچیده ساختار حافظه و حفاظت‌های موجود، نیازمند یک رویکرد ترکیبی بود. در نهایت او موفق شد با استفاده از تکنیکی موسوم به NullPointerNoException، اشاره‌گرهای داخلی را به گونه‌ای تغییر دهد که بدون ایجاد crash، به لیک آدرس‌های حیاتی مانند libggml-base.so منجر شود. این لیک آدرس‌ها گام اول در کنار زدن ASLR و آماده‌سازی Memory Layout برای اجرای کد مخرب است.
یکی دیگر از چالش‌های این حمله، نیاز به نوشتن جزئی (Partial-Write) روی بخش‌های خاصی از حافظه و هماهنگی دقیق ساختارهای Heap بود که نشان‌دهنده سطح بالای تخصص موردنیاز برای چنین Exploit پیچیده‌ای است.
نتیجه‌گیری:
این آسیب‌پذیری بار دیگر اهمیت ایمن‌سازی ابزارهای متن‌باز و ماژول‌های مربوط به شبکه را نشان می‌دهد. فعال بودن RPC Server بدون احراز هویت و محدودیت، می‌تواند در صورت وجود ضعف‌هایی نظیر Heap Overflow، به سادگی کنترل کامل سیستم را در اختیار مهاجم قرار دهد. به‌ویژه در حوزه هوش مصنوعی که مدل‌ها معمولاً روی سرورهای قدرتمند اجرا می‌شوند، چنین ضعف‌هایی می‌توانند تبعات سنگینی داشته باشند.


#آکادمی_روزبه
مرکز تخصصی CISSP

https://retr0.blog/blog/llama-rpc-rce

#موقت

خوبه این وسطه هم یادی کنیم از روسیه و چین که نه در هنگام حملات کمکی کردند نه در آتش بس نقشی داشتند و ضمنا جزایر ایرانی رو هم واسه ما نمیدونن!!

پس به عزیزان فنی بگم :
لطفا به سمت این دوتا غش نکنیم و ببینیم صلاح مملکت چیه

چگونه با یک باینری امضا‌شده‌ی مایکروسافت از AMSI، ETW و CLM عبور میکنند

مقدمه

در چند سال اخیر، ابزارهای امنیتی ویندوز مثل ضدبدافزار و EDRها اتکا زیادی به AMSI (رابط اسکن ضدبدافزاری) پیدا کرده‌اند. این قابلیت تقریباً هر اسکریپت Powershell، Jscript، VBScript، VBA یا .NET رو زمان اجرا می‌گیره و به آنتی‌ویروس ارسال می‌کنه تا بررسی بشه

حالا، یه روش جالب پیدا شده که با استفاده از یک ابزار امضا شده توسط مایکروسافت – یعنی CDB یا NTSD – بدون نیاز به نوشتن کد مخرب یا پچ کردن مستقیم DLL، نه فقط AMSI رو دور می‌زنه، بلکه قابلیت کنترل زبان (CLM) و ETW هم دورش زدنیه.
گام اول: فهمیدن ایراد AMSI

تو دنیای امنیت، رایج‌ترین بای‌پس‌ها روی تابع AmsiScanBuffer انجام می‌شد؛ اغلب توجه به مقدار بازگشتی داشتند. اگر تابع همیشه 0x80070057 (مقدار E_INVALIDARG) برگردونه، اسکن انجام‌نشده به‌حساب میاد

قبلاً می‌تونستیم این مقدار رو با چند خط PowerShell یا پچ ساده دستی اعمال کنیم، ولی حالا EDRها نسبت بهش حساس شدن و اون روش‌ها دیگه اثربخش نیستند.
گام دوم: رسیدگی با CDB/NTSD

اینجا وارد بازی می‌شیم: CDB و NTSD ابزارهای دیباگر کنسولی مایکروسافت هستن که توسط خود مایکروسافت امضا و به‌صورت پیش‌فرض امن و معتبرند

ما می‌تونیم با نوشتن اسکریپت خاص، PowerShell رو با CDB اجرا کنیم، breakpoint بذاریم روی AmsiScanBuffer، وقتی اجرا شد مقدار برگردونده رو دستکاری کنیم و ادامه بدیم—بدون دست زدن مستقیم به DLL مغشوش.

مثلاً اسکریپتی می‌نویسیم که به‌صورت زیر اجرا بشه:

cdb -cf bypass.txt "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"

اسکریپت bypass.txt اجرای PowerShell رو نظارت می‌کنه، موقعی که تابع AMSI فراخوانی شد سریع مقدار بازگشتی رو تغییر می‌ده و ادامه اجرا رو بدون اسکن امن می‌کنه

گام سوم: کنترل محدودیت زبان (CLM)

حالا که AMSIبا روش CDB قابل دورزدن بود، سراغ بخشی جذاب‌تر می‌ریم: کنترل کردن زبان PowerShell. تابع SystemPolicy.GetSystemLockdownPolicyمسئول وضعیت محدودیت زبانه. با استفاده از ویژگی‌های دیباگر CDB و بارگذاری sos.dll، می‌تونیم breakpoint بذاریم روی این تابع و به‌صورت مستقیم مقدار بازگشتی رو تغییر بدیم — و مثلاً مقدار 0 (بدون محدودیت) یا 2 (ConstrainedLanguage) رو برگردونیم


این کار تو محیط x86/x64 امتحان شده و واقعا جواب داده: امکان تغییر وضعیت زبان PowerShell پیش از اینکه حتی ماژول‌ها بارگذاری بشن فراهم میشه

گام چهارم: خاموش‌کردن ETW

نکته جالب دیگه اینه که با پچ مشابه می‌شه ETW (Event Tracing for Windows) رو هم دور زد، بدون اینکه در سطح هسته تغییر محسوسی بدیم . آزمون شده که رویدادهایی مثل EventID 4103 (اجرای pipeline) ثبت نمیشن—یعنی بار کاملاً پنهان‌کارانه‌ای اجرا شده

نتیجه‌گیری

این روش ابزار خیلی قدرتمندی به ما میده:

دور زدن AMSI

تنظیم وضعیت محدودیت زبان (CLM)

خاموش کردن یا محدود کردن ETW

و مهمتر اینکه همه با استفاده از ابزارهای امضا‌شده مایکروسافت انجام می‌گیره—بدون نیاز به فایل‌های DLL غیرمعتبر یا باینری‌های ناشناس.



#آکادمی_روزبه
مرکز تخصصی CISSP

تحلیل آکادمیک آسیب‌پذیری‌های موتور اسکن و شبیه‌سازی Microsoft Defender با استفاده از Snapshot Fuzzing
مطالعه موردی بر اساس گزارش InfoGuard Labs

مقدمه

ابزارهای ضد بدافزار و سیستم‌های EDR (Endpoint Detection and Response) مدت‌هاست به‌عنوان اجزای اصلی امنیت سایبری سازمان‌ها شناخته می‌شوند. با این حال، پیچیدگی ذاتی این ابزارها و تعامل مستقیم آن‌ها با داده‌های غیرقابل اعتماد، سبب می‌شود که خود به هدف بالقوه‌ای برای حملات تبدیل شوند.

در این زمینه، پژوهش اخیر منتشر شده در وب‌سایت InfoGuard Labs تحت عنوان Attacking EDR - Part 4: Fuzzing Defender Scanning and Emulation Engine، نمونه‌ای ارزشمند از بررسی امنیتی دقیق یکی از پرکاربردترین آنتی‌ویروس‌های جهان یعنی Microsoft Defender است. این تحقیق نشان می‌دهد که چگونه می‌توان با استفاده از تکنیک‌های Fuzzing پیشرفته، آسیب‌پذیری‌های حیاتی در موتور اسکن و شبیه‌ساز Defender کشف و بهره‌برداری کرد.

این مقاله با رویکردی تحلیلی و آکادمیک به بررسی ساختار، روش‌ها و یافته‌های این پژوهش می‌پردازد و در نهایت، ابعاد امنیتی و راهکارهای پیشنهادی را واکاوی می‌کند.

⏮️یافته‌های فنی و آسیب‌پذیری‌های کشف‌شده

در مجموع، این تحقیق منجر به کشف ۹ آسیب‌پذیری حافظه در Microsoft Defender شد. دسته‌بندی کلی این باگ‌ها:

Out-of-Bounds Read (خواندن داده خارج از محدوده مجاز حافظه)

Null Pointer Dereference (ارجاع به اشاره‌گر تهی)

Crashهای کنترل‌شده در تعامل با فرمت‌های خاص فایل

↩️ تحلیل امنیتی: پیامدهای عملی و تهدیدات بالقوه

اگرچه اکثر آسیب‌پذیری‌های کشف‌شده در این پروژه منجر به اجرای مستقیم کد مخرب (RCE) نمی‌شوند، اما اثرگذاری آن‌ها در سناریوهای زیر مشهود است:

حملات DoS علیه Defender: ارسال فایل‌های خاص باعث کرش موتور شده و در این بازه زمانی سیستم بدون محافظ باقی می‌ماند.

دور زدن EDR در حملات زنجیره‌ای: مهاجمان ابتدا Defender را غیرفعال و سپس ابزارهای پیچیده‌تر را اجرا می‌کنند.

سوءاستفاده در محیط‌های ایزوله (Sandbox): برخی باگ‌ها می‌توانند باعث اختلال در تحلیل رفتاری بدافزار در محیط‌های مجازی شوند.

این موضوع یادآور اصل «Defensive Depth» است که نشان می‌دهد تکیه صرف بر یک ابزار امنیتی کافی نیست و باید چندین لایه حفاظتی هم‌پوشانی داشته باشند.

#آکادمی_روزبه
مرکز تخصصی CISSP

https://labs.infoguard.ch/posts/attacking_edr_part4_fuzzing_defender_scanning_and_emulation_engine/

و نسخه جدید MISP منتشر شد


https://www.misp-project.org/2025/06/24/misp.2.5.15.and.2.4.113.html/

اسکریپت های ارتقای دسترسی

#آکادمی_روزبه
مرکز تخصصی CISSP

مهاجمان سایبری اخیراً از QEMU، که معمولاً برای شبیه‌سازی سیستم‌عامل‌های مجازی به‌کار می‌رود، برای ایجاد تونل‌های شبکه‌ای و عبور مخفیانه از فایروال‌ها و محدودیت‌های شبکه استفاده کرده‌اند. این روش نوعی Network Tunneling محسوب می‌شود که به مهاجم اجازه می‌دهد از طریق سیستم‌های قربانی، دسترسی غیرمجاز به شبکه‌های داخلی پیدا کند.
در این تکنیک، مهاجم روی یک سیستم به نام PivotHost، که دسترسی به اینترنت دارد، QEMU را بدون راه‌اندازی کامل ماشین مجازی اجرا می‌کند. این QEMU با تنظیمات خاص مانند -netdev socket و -netdev user، یک تونل شبکه‌ای ایجاد می‌کند که ترافیک را به یک سرور دیگر مهاجم منتقل می‌کند. این سرور می‌تواند در اینترنت یا زیرساخت ابری باشد و یک QEMU دیگر روی آن اجرا شده تا ارتباط دوسویه برقرار شود.
این تونل به مهاجم اجازه می‌دهد ترافیک پروتکل‌هایی مانند RDP را که در حالت عادی فقط در شبکه داخلی مجاز است، از طریق اینترنت عبور دهد، بدون آنکه فایروال یا تجهیزات امنیتی به‌راحتی متوجه شوند.
تشخیص این نوع فعالیت دشوار است، اما چند سرنخ مهم وجود دارد:
اجرای QEMU با مقادیر غیرمعمول حافظه مانند -m 1M یا بدون دیسک و سیستم‌عامل، مشکوک است.
مشاهده فرآیندهای QEMU با پارامترهای شبکه نظیر -netdev socket باید به‌عنوان هشدار امنیتی بررسی شود.
تحلیل ترافیک شبکه برای یافتن بسته‌های TCP غیرمنتظره یا ترافیک غیرمعمول روی پورت‌هایی مانند 443 یا 4444 که حاوی encapsulated Ethernet هستند.
استفاده از EDR، NDR و قوانین Sigma برای شناسایی رفتار غیرطبیعی QEMU در شبکه و سیستم‌ها.
این تکنیک نمونه‌ای پیشرفته از سواستفاده از ابزارهای قانونی برای اهداف مخرب است و نیازمند نظارت دقیق و تحلیل عمیق در شبکه‌های سازمانی می‌باشد.



#آکادمی_روزبه
مرکز تخصصی CISSP


https://securelist.com/network-tunneling-with-qemu/111803/