مایکروسافت توی ویندوز ۱۱ یه سیستم گذاشته که وقتی می‌خوای کاری با دسترسی ادمین انجام بدی، یه حساب مخصوص ادمین مخفی استفاده می‌کنه تا امنیت بره بالا. این باعث می‌شه بدافزارها سخت‌تر بتونن کنترل سیستم رو بگیرن.



قبلاً در ویندوز، وقتی یه کاربر معمولی می‌خواست کاری مثل نصب برنامه انجام بده، ویندوز ازش می‌پرسید:
«آیا می‌خوای این کار رو با دسترسی ادمین انجام بدی؟» (همون پنجره UAC که Yes/No داره)

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

راه‌حل جدید ویندوز چیه؟

ویندوز ۱۱ یه کار جالب کرده:

به‌جای اینکه به همون کاربر اجازه‌ی ادمین بده، میاد یه حساب جداگانه به اسم admin_اسم‌کاربر درست می‌کنه.

مثلاً اگر اسم کاربر milad باشه، یه حساب مخفی به اسم admin_milad ساخته می‌شه که فقط مخصوص کارهای ادمینه.

وقتی کاربر لازم داره کاری با دسترسی ادمین انجام بده:

ویندوز از اون حساب admin_milad استفاده می‌کنه تا کار انجام بشه، نه از همون حساب کاربر.

این چه فایده‌ای داره؟

برنامه‌های بدخواه(مثل ویروس‌ها) دیگه نمی‌تونن راحت از UAC رد بشن و خودشونو ادمین کنن.

چون الان باید از یه حساب جداگانه استفاده بشه که شرایط خاصی داره.

آیا هنوز هم راه دور زدن هست؟

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

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

https://specterops.io/blog/2025/06/18/administrator-protection/

ابزار Forensic Timeliner

این ابزار که در این پست معرفی میکنم ، یک ابزار تایم‌لاین‌ساز سریع مخصوص تحلیل‌های دیجیتال (Digital Forensics) هست، مخصوص کسانی که توی حوزه‌ی DFIR (Digital Forensics and Incident Response) کار می‌کنن.

💡 کار اصلی این ابزار چیه؟


اطلاعات جمع‌آوری‌شده از سیستم (مثل لاگ‌ها، آرتیفکت‌ها و فایل‌ها) رو می‌گیره، اون‌ها رو مرتب می‌کنه و به صورت یک تایم‌لاین (خط زمانی) منظم در میاره.

یعنی چی؟
یعنی شما می‌تونید ببینید:

چه اتفاقی در چه زمانی افتاده؟

کِی یه فایل خاص ساخته یا حذف شده؟

چه زمانی یوزری لاگین کرده؟

و خیلی اطلاعات دقیق زمانی دیگه...

✨ ویژگی‌های جدید نسخه 2.2:

پیش‌نمایش تعاملی فیلترهای YAML برای لاگ‌های MFT و Event Logs

پیشنهاد تگ‌گذاری با کلمات کلیدی (TLE tagging) برای تولید session با پسوند .tle_sess

پشتیبانی از علامت [] در فیلترها برای پوشش همه Event IDها


✅ از چی پشتیبانی می‌کنه؟

با ابزارهای مطرح تحلیل دیجیتال کار می‌کنه، مثل:

EZ Tools/KAPE

Chainsaw

Hayabusa

Axiom


🔍 مناسب برای چه کسانیه؟

تحلیلگران فورنزیک دیجیتال

تیم‌های Incident Response

تیم SOC Analystهایی که دنبال کشف زمان وقوع و ترتیب رویدادها هستن


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

https://github.com/acquiredsecurity/forensic-timeliner

پایداری سایبری در زیرساخت‌های حیاتی
مستندی از ISACA

نگاهی به NIS2 و DORA

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

برای دانشجویان به زبان ساده

شنود سیستم کال

سیستم کال و نه API اپلیکیشن تحت وب، شنود تماس‌های API بین اجزای سیستم‌عامل، سرویس‌ها، یا حتی بین برنامه و کرنل هست؛ مثلاً:

شنود System Call API در لینوکس یا ویندوز (مثلاً NtCreateFile, ReadFile, socket, execve)

تحلیل رفتار بدافزار یا برنامه از طریق API Monitoring

استفاده از ابزارهایی مثل strace, sysdig, procmon, یا API Monitor


🎯 هدف: آموزش شنود APIهای سیستم به دانشجویان
🔹 ۱. تعریف ساده و کاربردی

«در سیستم‌عامل‌ها، وقتی برنامه‌ای می‌خواد کاری انجام بده مثل خوندن یک فایل، باز کردن اینترنت، یا اختصاص دادن حافظه، درخواستش رو از طریق یک API یا System Call به سیستم‌عامل می‌فرسته. شنود این APIها یعنی بررسی اینکه چه برنامه‌ای چه دستوری به سیستم‌عامل داده.»

🟣 مثال ساده:

وقتی Notepad رو باز می‌کنی و یک فایل رو ذخیره می‌کنی، پشت صحنه سیستم از CreateFile, WriteFile, CloseHandle استفاده می‌کنه. ما می‌تونیم این APIها رو ببینیم.

🔹 ۲. چرا لازمه API Callهای سیستم شنود بشن؟

تحلیل رفتار برنامه‌ها:
آیا برنامه بدون اجازه شما به فایل یا شبکه دسترسی داره؟

کشف بدافزارها:
بدافزارها با APIها رفتار خودشون رو نشون می‌دن، مثلاً VirtualAlloc برای رزرو حافظه جهت shellcode
مهندسی معکوس:
این API Callها قدم به قدم به شما می‌گن برنامه داره چه‌کار می‌کنه
شناسایی رفتار مشکوک:
اگر برنامه‌ای پشت صحنه keylogger اجرا کنه، APIهای GetAsyncKeyState یا SetWindowsHookEx ظاهر می‌شن
تست امنیتی:
فهمیدن اینکه یه برنامه از چه System Callهایی استفاده می‌کنه، می‌تونه به تست نفوذ کمک کنه

🔹 ۳. ابزارهای پیشنهادی (بسته به سیستم‌عامل):
✅ ویندوز:

ابزار Process Monitor (Procmon) – از Sysinternals. برای دیدن File, Registry, Network, و API Calls.

ابزار API Monitor – برای رصد کردن دقیق APIهای ویندوز (user-mode و kernel-mode).

ابزار WinDbg + Sysinternals – برای سطح پایین‌تر، مخصوص دانشجویان پیشرفته‌تر.

✅ لینوکس:

ابزار strace – برای دیدن System Callهای سطح پایین مثل open, read, write

ابزار lsof, dstat, iotop – برای مشاهده منابع درگیر

ابزار sysdig – تحلیل و شنود عمیق‌تر از kernel space

ابزار auditd – برای مانیتور کردن دقیق سیاست‌محور از system callها

این API Callها مثل گفت‌وگوی مخفی بین نرم‌افزار و سیستم‌عامل هستند. شنیدن این مکالمه‌ها یعنی اینکه بفهمیم برنامه‌ها واقعاً چی کار می‌کنند، نه فقط اون چیزی که در ظاهر نشون می‌دن. این یک سلاح کلیدی برای شکار تهدید، مهندسی معکوس، و تحلیل امنیتی هست.

🔆🔆مثال تمرینی در پستهای آتی


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

تمرین



بخش اول: برنامه ساده 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