#Note

چرا نوع درایور یا بهتر بگم فریمورکش برای امنیت وحملات BYOVD مهم هست ؟

وقتی یک مهاجم میخواد از تکنیک BYOVD (استفاده از درایورهای قانونی ولی آسیب‌پذیر برای نفوذ به هسته) استفاده کنه:

اگر درایور هدف با روش قدیمی (WDM) نوشته شده باشه، احتمال وجود باگ‌های ساده و خامی که بشه ازشون سوءاستفاده کرد خیلی بیشتره و مهندسی معکوس کردنش هم راحت تر هست.

اگر درایور هدف با روش جدید (KMDF) نوشته شده باشه، چون فریم‌ورک خیلی از خطاهای برنامه‌نویسی رو خودش فیلتر میکنه، پیدا کردن باگ سخت‌تره و ساختار کدهای توی حافظه شکل متفاوتی داره.

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

یعنی چی ؟ این سناریو ها وجود دارند :

در مدل فریمورک قدیمی (WDM) برنامه به صورت مستقیم با کد درایور ارتباط برقرار میکند. درایور باید صف را مدیریت کند، بررسی اندازه داده و سنجش دسترسی را کلا خودش به شکل دستی انجام دهد. اگر برنامه نویس یک بررسی امنیتی را فراموش کند، نفوذگر با فرستادن یک داده دستکاری شده (IOCTL) مستقیما به کنترل هسته (Ring 0) میرسد.

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


🦅 کانال بایت امن | گروه بایت امن
_

#Security #PHP #IonCube

یکی از روش‌های رایج برای تحلیل و استخراج محتوای فایل‌های PHP که با IonCube محافظت شده‌اند، هوک کردن Loader در زمان اجرا است.

در این روش باید یک محیط PHP واقعی در اختیار داشته باشید تا زمانی که Opcode، Loader ها را در حافظه بازسازی می‌کند، بتوان آن‌ها را استخراج (Dump) کرد.

با این حال، این روش محدودیت‌هایی دارد، از جمله نیاز به سازگاری نسخه PHP محیط تحلیل با نسخه‌ای که فایل برای آن تولید شده است. علاوه بر این، Loader نیز ممکن است وجود Hook یا دستکاری در فرآیند اجرا را تشخیص دهد.

به همین دلیل، مقاله IonCube PHP 8.1–8.4 : Static Opcode Extraction Without Execution به بررسی روشی برای استخراج Opcodeها بدون اجرای فایل می‌پردازد، زوشی که امکان تحلیل استاتیک فایل‌های محافظت‌شده با IonCube را فراهم می‌کند.


🦅 کانال بایت امن | گروه بایت امن
_

بریم برای جواب چالش ها :

امروز داشتم ویدیو جدید بچه های آفنسیو رو رکورد میکردم که در رابطه با مفاهیم و اینترنال Heap بود برای همین سئوالات رو مطرح کردم و البته نتیجه برام مشخص بود چون معمولا مفاهیم Virtual Memory - Heap و Stack تا حدودی نیاز به مطالعه بیشتری داره :

جواب سئوال اول : Heap
در Heap به سمت آدرس های بالا رشد میکنه و Stack به سمت آدرس های پایین.

جواب سئوال دوم : Heap
به این دلیل که شما وقتی با HeapAlloc درخواست فضا میکنید Heap Manager به دنبال فضای خالی بین Heap Block ها میگرده و ممکنه فضاهای درخواست شده پشت سر هم و دنباله دار نباشند بنابر این External Fragmentation به وجود میاد و اگر فضای خالی وجود نداشته باشه پای Page به وسط میاد.

جواب سئوال سوم : HeapAlloc
به این دلیل که HeapAlloc به صورت پیشفرض به دنبال Heap Block در Heap Segment میگرده تا فضا مورد نیاز رو در اختیار شما قرار بده یعنی 32 بایت درخواست میکنید نهایت 40 بایت به شما اختصاص میده ولی همینکار با VirtualAlloc تا زیر 4KB همون 4KB رو ایجاد میکنه ( به اندازه یک Page ) و سربار زیادی به وجود میاد.

🦅 کانال بایت امن | گروه بایت امن
_

و اما چالش،

بله، اکثریت گزینه‌ی درست را انتخاب کردند و پاسخ Stack است.

در Virtual Memory و Heap نیاز به آزاد سازی حافظه دارید.

در Virtual Memory با استفاده از VirtualFree یا VirtualFreeEx

در Heap اگر Allocate شده باشه HeapFree اگر Private Heap باشه HeapDestroy

🦅 کانال بایت امن | گروه بایت امن
_

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

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

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

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

خوشحال شدم که بالاخره یک نفر خیلی خوب و شفاف بیانش کرده.

عزیزان، جلوی تکنولوژی مقاومت نکنید، ازش استفاده کنید. منظورم هم صرفا پرامپت‌نویسی نیست. بعد از دیدن ویدیو متوجه می‌شید دقیقاً منظورم چیه.

🦅 کانال بایت امن | گروه بایت امن
_

#Security #IncidentResponse

سناریو :

در این تحلیل، یک سناریوی واقعی از کشف و بررسی بدافزار ValleyRAT در یک شبکه سازمانی صنعتی مورد بررسی قرار گرفته است. ماجرا از جایی آغاز شد که یک هشدار در کنسول Endpoint Detection ثبت شد.

یک ورک‌استیشن ویندوزی در شبکه تولید، تغییر مشکوکی را در کلیدهای استاندارد Run رجیستری نشان می‌داد.

این سناریو مربوط به یک تیم Incident Response است که پس از هشدار EDR و تایید SIEM مبنی بر تغییر مشکوک در کلیدهای Startup رجیستری، وارد فاز تحلیل عمیق بدافزار می‌شود.

هدف اصلی، درک کامل رفتار ValleyRAT، شناسایی قابلیت‌های مخرب آن و استخراج زیرساخت فرماندهی و کنترل (C2) برای اقدامات دفاعی بعدی است.

🔹 بررسی مکانیزم‌های ماندگاری (Persistence) در سیستم و نحوه تثبیت بدافزار
🔹 تحلیل تغییرات مشکوک در Run Key رجیستری و ارتباط آن با اجرای خودکار
🔹 استخراج و رمزگشایی Payloadهای رمزگذاری‌شده درون فایل
🔹 بررسی نحوه اجرای Shellcode و تزریق آن در حافظه
🔹 تحلیل تکنیک‌های دور زدن مکانیزم‌های امنیتی و کاهش احتمال شناسایی
🔹 استخراج تنظیمات داخلی، ساختار ارتباطی و آدرس‌های سرورهای C2


🦅 کانال بایت امن | گروه بایت امن
_

#ReverseEngineering

مهندسی معکوس یک Rootkit امضاشده توسط مایکروسافت، درایور Netfilter

اخیرا به مقاله‌ای برخوردم که یکی از اتفاقات جالب دنیای امنیت ویندوز را بررسی می‌کند و اون ماجرای درایور مخربی به نام Netfilter که در سال ۲۰۲۱ توانست با امضای معتبر مایکروسافت منتشر شود.

نویسنده مقاله در حین بررسی روش‌های دور زدن Driver Signing Enforcement (DSE) سراغ این نمونه رفته و نشان می‌دهد مهاجمان چگونه توانستند از فرآیند امضای درایورها عبور کنند و یک Rootkit را با ظاهری کاملا معتبر روی سیستم‌های ویندوز اجرا کنند.

برخی از موضوعات مطرح‌شده در این تحلیل:

🔹 نحوه عملکرد درایور Netfilter
🔹 فرآیند امضای درایورها در ویندوز
🔹 تکنیک‌های مورد استفاده در Rootkitهای سطح Kernel
🔹 دلایل موفقیت این نمونه در دریافت امضای معتبر
🔹 تغییراتی که مایکروسافت پس از این حادثه در فرآیند تأیید و امضای درایورها اعمال کرد

🦅 کانال بایت امن | گروه بایت امن
_

#AI #EDR

پروژه Project Onyx یک پروژه تحقیقاتی Red Team است که به جای استفاده از روش های سنتی مخفی سازی فایل و کد، روی پنهان کردن رفتار و اجرای چند لایه تمرکز دارد.

در این معماری چند تکنیک مختلف با هم ترکیب شده اند از جمله جعل تله متری مبتنی بر هوش مصنوعی، وابسته کردن اجرا به سخت افزار هدف، مخفی سازی داده ها داخل مدل های ONNX، اجرای کد در محیط WebAssembly و استفاده از به روزرسانی مدل ها برای ارتباط با سرور کنترل.

نویسنده تاکید می کند که این پروژه یک بای پس عملی برای EDR های تجاری نیست و بیشتر به عنوان یک نمونه تحقیقاتی و نقطه شروع برای بررسی ایده های جدید در حوزه EDR Evasion طراحی شده است.

همچنین Payload نهایی عمدا بسیار محدود است و فقط یک Beacon ساده ارسال می کند تا بتوان کل زنجیره اجرا را بدون انجام فعالیت های مخرب یا Post Exploitation بررسی کرد.

🦅 کانال بایت امن | گروه بایت امن
_

#EDR #DLLHIJACKING

با وجود پیشرفت ابزارهای امنیتی و EDR ها در سال های اخیر، DLL Hijacking همچنان یکی از تکنیک های پرکاربرد در حملات ویندوزی محسوب می شود.

در این مطلب، نویسنده به بررسی این تکنیک، نحوه سوء استفاده از فرآیند بارگذاری DLL ها و دلایلی می پردازد که باعث شده DLL Hijacking همچنان برای اجرای کد، ماندگاری و افزایش سطح دسترسی مورد توجه مهاجمان قرار بگیرد.

تقریبا تمامی روش ها در این مقاله پوشش داده شده.

🦅 کانال بایت امن | گروه بایت امن
_