DNS Zone Transfer
چیست و چطور می‌توان آن را تشخیص داد؟

قبل از هر چیز یک توضیح کوتاه درباره DNS بدم :
DNS یا Domain Name System
سرویس اصلی اینترنت برای تبدیل نام دامنه به IP هستش. وقتی شما می‌خواهید وارد مثلاً example.com شوید، کامپیوتر شما نمی‌تواند مستقیم نام دامنه را بفهمد و به آن متصل شود، چون پروتکل اینترنت فقط با IP کار می‌کند. DNS مثل یک دفترچه تلفن اینترنتی عمل می‌کنه که IP متناظر با هر دامنه رو برمیگردونه

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

Zone Transfer
چیست؟

Zone Transfer یا AXFR
یک فرایند در DNS است که برای کپی کردن تمام اطلاعات یک دامنه از یک DNS سرور استفاده می‌شود

به زبان ساده بخام بگم

یک مهاجم می‌توانه از طریق Zone Transfer کل دایره‌المعارف DNS یک دامنه شامل تمام ساب‌دامین‌هاش رکوردهای MX، A، TXT و غیره رو بدست بیاره
اما یه نکته این فرایند اکثراً موفق نیست چون اکثر DNS سرورها با پالیسی‌های امنیتی درست تنظیم شده‌اند و Zone Transfer به درخواستهای ناشناس پاسخ نمیده
اما با این حال  برخی DNS سرورهای ضعیف یا بد پیکربندی شده  به اشتباه اطلاعات را در اختیار مهاجم قرار میدن

یه مثال عملی بخام بگم

فرض کنید می‌خوایم برای دامنه zonetransfer.me
سرورهای DNS رو پیدا کنیم و Zone Transfer رو تست کنیم

1 ابتدا لیست سرورهای معتبر رو پیدا می‌کنیم:

dig +short NS zonetransfer.me
این دستور نام DNS سرورهای دامنه را برمیگردونه مثال بزنم

nsztm1.dnsowl.com
nsztm2.dnsowl.com
سپس تلاش می‌کنیم Zone Transfer انجام بدیم

dig @nsztm1.dnsowl.com zonetransfer.me AXFR
اگر سرور به درستی پیکربندی شده باشد، معمولاً خطای دسترسی دریافت می‌کنیم و عملیات ناموفق است. اما اگر سرور ضعیف باشد، تمام رکوردهای دامنه نمایش داده می‌شود.

نکات مهم برای SOC

برای SOC (Security Operations Center)
Zone Transfer
می‌تواند هم تهدید باشد و هم منبع اطلاعات مفید برای کشف مشکلات امنیتی:

شناسایی فعالیت مشکوک:

   درخواست‌های AXFR از منابع خارجی میتواند نشانه تلاش مهاجم برای جمع‌آوری اطلاعات باشن
ثبت لاگ‌های DNS برای تحلیل چنین فعالیت‌هایی ضروریه

پالیسی‌ها :

اطمینان از اینکه Zone Transfer فقط بین DNSهای داخلی انجام میشه و برای عموم مسدود هستش
بررسی و محدود کردن دسترسی به سرویس‌های DNS در فایروال و ACL

تست‌های امنیتی داخلی:

تست‌های دوره‌ای Zone Transfer روی سرورهای داخلی برای شناسایی مشکلات پیکربندی قبل از نفوذ مهاجم
   استفاده از ابزارهایی مثل dig یا اسکریپت‌های خودکار برای کشف رکوردهای غیرمجاز

هشدار و واکنش:

   هرگونه تلاش برای Zone Transfer از منابع غیرمجاز باید به سرعت به تیم SOC اطلاع داده بشه
میتوان سیستم هشدار خودکار برای ترافیک DNS غیرمعمول راه‌اندازی بکنیم

https://news.1rj.ru/str/ViperNull

برای دیدن یه نمونه باحال از XSS با عکس و متادیتا (EXIF) این مقاله رو حتما بخونین :
https://shahjerry33.medium.com/xss-via-exif-data-the-p2-elevator-d09e7b7fe9b9



https://news.1rj.ru/str/ViperNull

سلام و درود
شب بخیر
امروز سر کار بحث فنی بسیار جالبی و آموزنده ای داشتیم در خصوص شکار تهدیدات، حیفم آمد به اشتراک نذارم:

ما شکار تهدیدات رو به دو بخش تقسیم کردیم:
structured و unstructured!

شکار ساختار یافته (structured) مبتنی بر evidence هست. حالا این evidence میتونه یک ioa باشه، یه گزارش ti باشه، خروجی فعالیت purple teaming باشه.

شکار بدون ساختار (unstructured) مبتنی بر دیتا هست. حالا این دیتا میتونه از گزارشات امنیتی، از ti که هنوز تبدیل به Detection rule نشده، گزارشات red team، از حتی اخبار امنیتی باشه.

جفت این مدل‌ها، مارو هدايت میکنه سمت ایجاد فرضیه!

حالا این فرضیه میتونه بصورت ساختار یافته تو شبکه جستجو شه با اسکوپ مشخص (معمولا mitre att&ck رو به عنوان چارچوب کار انتخاب می‌کنند و متمرکز روی post exploitation)!
یا
فرضیه بدون ساختار خاصی و مبتنی بر discovery انجام شده پای مثلا یک سیستم ادامه پیدا کنه!

حالا این وسط soc میگه منم دارم فرایند Purple teaming رو میبرم جلو! ضعف هام رو شناسایی میکنم و براشون Detection rule مینویسم! از طرفی اگر هم visibility gap داشته باشم، اونم از گزارشات red team که purple teaming پردازش میکنه agent روش نصب میکنم و پوشش میدم! این وسط یه سوال ایجاد میشه که: چرا باید Hunting داشته باشیم؟ احیانا overlap نداره کارها؟ تو نگاه اول، claim بسیار منطقی هست! من خودم عمیق به فکر فرو رفتم! واقعا چرا hunting میخواهیم؟ نکنه overlap داریم واقعا؟!

برای پاسخ به این سوال، اول باید بفهمیم رویکرد hunting چیه؟ اون چیزی که من متوجه شدم از hunting، این هست که فعالیتی‌ست proactive جهت یافتن شواهد یا دیتایی از تهدیدات با پیش‌فرض دور خوردن مکانیزم‌های امنیتی!
از نگاه threat hunting، تمامی Detection rule ها، قابلیت دور خوردن دارند! حتی اونایی که با * نوشته شدن😁!

شکار هست که این گپ‌هارو کاور کنه و در نهایت کمک کنه به detection بهتر به عنوان یک لایه دیگه!

چرا یه لایه دیگه میخواهیم؟ بخاطر defense in depth؟
شاید اگر ‌کتاب Time-Based Security رو میخوندیم یا خلاصه ای که مهندس مولایی عزیز برای تنبل‌هایی مثل من گذاشته یه نگاهی بندازیم: معماری امن میگه شما باید معادله‌ی p>d+r رو برقرار کنی برای سیستم! وگرنه امنیت شما زیر سوال خواهد بود!
مثال بزنم:
اگر p که نشان از protection داره ۲ ساعت بتونه جلوی حملات سایبری دووم بیاره، یا اینطوری نگاهش کنیم که ۲ ساعت طول میکشه که دورش بزنن، سرعت detection و response ما باید الزاما زیر ۱ ساعت و ۵۹ دقیقه باشه که بتونیم ادعا کنیم سیستم امن مونده!

حالا سوال: چقدر طول میکشه قوانین detection ما دور بخوره؟
کی قراره این تیکه رو کاور کنه و proactice بگرده تو شبکه دنبال همین شواهد؟
کجا بهتر از soc میتونه از خروجی شکار نفع ببره؟
شکار تهدیدات به عنوان یک بازوی عملیاتی proactive برای soc میتونه تو کاهش سرعت detection تاثیر بسزایی در بهبود عملکرد soc داشته باشه!

برای شکار، visibility حرف اول رو میزنه! جایی که visibility نباشه، صِرف نصب کردن agent شما به detection نمیرسی! اگر اینطوری بود که همه agent نصب می‌کردند و امن می‌شدند و detection برقرار میشد براشون! برای تمام‌ حملات میشه detection نوشت؟ اگر اوکیه که من تمام detection ruleهای دنیا رو میدم بهتون بزنید تو سامانه‌هاتون و برید خونه بخوابید راحت!
این نگاه رو شما هم بهش فکر کنید نظر بدید!

یادمون نره نگاه شکار تهدیدات بر این مبنا بود که Detection های ما توسط مهاجم همین الان bypass شده!

این نتیجه‌ای بود که ما بعد از ۲ ساعت جلسه فنی سنگین با همکارامون گرفتیم!
حالا منتظر نظرات و ایده‌هاتون هستم ببینم کجای راه رو سمت شکار تهدیدات اشتباه رفتیم، اصلاحش کنیم!

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

در این بروزرسانی یک آسیب پذیری زیرودی با شناسه ی CVE-2025-43300 هم اصلاح شده که قبلا اپل برای دستگاههای دارای iOS 18.6.2 و iPadOS 18.6.2، همچنین iPadOS 17.7.10 و نسخه ‌های مک (Sequoia 15.6.1، Sonoma 14.7.8 و Ventura 13.7.8) پچ کرده بود.

این آسیب پذیری از نوع Out-of-Bounds Write و در فریمورک Image I/O بود، فریمورکی که امکان خواندن و نوشتن فرمتهای مختلف فایلهای تصویری رو به اپ ‌ها میده. طبق اعلام اپل، این آسیب پذیری در حملات بسیار پیچیده مورد سوء استفاده قرار گرفته بود.

در حملات Out-of-Bounds Write، مهاجم ورودی مخربی به برنامه میده که باعث میشه داده ‌ها خارج از محدوده‌ی بافر تخصیص داده ‌شده، نوشته بشن. این موضوع میتونه به کرش برنامه، خرابی داده ‌ها، یا حتی اجرای کد از راه دور منجر بشه. بنابراین در این آسیب پذیری، پردازش یک فایل تصویری مخرب میتونه منجر به خرابی حافظه بشه.

اپل در بروزرسانی جدیدش این آسیب پذیری زیرودی رو در نسخه های زیر اصلاح کرده:

- iOS 15.8.5 / 16.7.12
- iPadOS 15.8.5 / 16.7.12

از جمله دستگاههای آسیب پذیر:

- iPhone 6s (all models), iPhone 7 (all models), iPhone SE (1st generation), iPhone 8, iPhone 8 Plus, and iPhone X,
- iPad Air 2, iPad mini (4th generation), iPad 5th generation, iPad Pro 9.7-inch, iPad Pro 12.9-inch 1st generation, and iPod touch (7th generation)

اگر از این دستگاهها استفاده میکنید، حتما بروزرسانی رو اعمال کنید./منبع

#زیرودی #اپل #آسیب_پذیری_امنیتی
#Apple #0day #Zero_click

🆔 @onhex_ir
➡️ ALL Link

مایکروسافت فقط ۴ روز دیگر ویندوز ۱۰ را پشتیبانی میکند

https://news.1rj.ru/str/ViperNull

https://news.1rj.ru/str/ViperNull 🕸

سلام، امروز می‌خوام راجع به Enumeration پروتکل SNMP صحبت کنم و مراحل انجامش رو با هم بررسی کنیم.
خب مشخصاً SNMP یه پروتکل برای مانیتورینگ شبکه‌ست — Simple Network Management Protocol — یعنی من با فعال کردن این پروتکل روی دیوایس‌های شبکه‌، اطلاعات خیلی جامعی از وضعیت دستگاه میگیرم و میتونم با استفاده از نرم‌افزارهای مانیتورینگ مثل Zabbix، SolarWinds یا ManageEngine از این پروتکل برای مانیتورینگ شبکه استفاده کنم.

بعضی دستگاه‌ها به‌صورت پیش‌فرض وقتی SNMP روشون فعال می‌شه، برای دسترسی read-only یا read-write یه community string دارن که معمولاً کلمات «public» یا «private» انتخاب میشه و خب با حدس زدن این رشته (community string) میتونیم اطلاعات رو بیرون بکشیم.
در ویندوزهای خیلی قدیمی مثل XP و Server 2008، پروتکل SNMP به‌صورت پیش‌فرض فعال بود و مایکروسافت بعداً به دلایل امنیتی و کاهش وابستگی، این تنظیمات پیش‌فرض رو حذف کرد.

SNMP v1 و v2
رمزنگاری ندارن و اگر بسته‌ها رو sniff کنیم به‌راحتی community string مشخص می‌شه، پس بهتره از SNMPv3 استفاده کنید که احراز هویت و رمزنگاری رو اضافه میکنه.

پورت‌های مربوط به SNMP:
پورت 161/UDP برای query/polling هست و پورت 162/UDP برای SNMP Trapها.

برای دیدن فعال بودن سرویس SNMP روی ویندوز می‌تونیم Win + R بزنیم = services.msc و به دنبال SNMP Service بگردیم.

ما یه چیزی به نام SNMP Trap هم داریم که درواقع پیام‌های هشدار هست — مثلاً سیستم منتظر میمونه تا پیغام هشدار (مثلاً دان شدن یه لینک) از طرف دستگاه بیاد. SNMP Trap میتونه به‌صورت آنی هشدار رو به سرور مانیتورینگ برسونه. درباره حمله‌ای که می‌شه با این زد در پست‌های آینده مفصل‌تر میگم، ولی یه نمونه‌اش SNMP Trap‌های جعلی برای گیج کردن سرور مانیتورینگ هست.

نحوه بهره‌برداری از این پروتکل برای enumeration:

ما با ابزار Metasploit می‌تونیم سیستم‌هایی که SNMP روشون فعاله رو شناسایی کنیم و یه تست دیکشنری‌اتک روی پسورد این پروتکل بزنیم. روند در متاسپلویت به‌طور خلاصه:
وارد مسیر
use auxiliary/scanner/snmp/snmp_login
می‌شیم و با ست کردن لیست پسورد و رنج آیپی مقصد، run می‌کنیم (Metasploit یه لیست پیش‌فرض برای این کار داره و می‌تونید از اون یا لیست‌های خودتون استفاده کنید).

حالا وقتی community string سیستم‌هایی که SNMP روشون فعاله رو متوجه شدیم، با وارد شدن به مسیر
use auxiliary/scanner/snmp/snmp_enum
میتونیم درخواست دریافت اطلاعات سیستم رو بدیم — مثل وضعیت پروسس‌ها، اطلاعات کارت شبکه، CPU/RAM، سرویس‌های فعال، مشخصات سیستم، مشخصات هارد و ... اطلاعات خیلی ارزشمندی که می‌تونه توی فاز scanning یا فاز بعدی حمله مفید باشه.

ما می‌تونیم از ابزارهای مثل SolarWinds toolset این اطلاعات رو به‌صورت گرافیکی ببینیم و خیلی راحت از ابزارها و فایل‌های مربوطه روی ویندوز استفاده کنیم.


https://news.1rj.ru/str/ViperNull 🕸

🔴 اکتبر 2025؛ اعلام رسمی پایان پشتیبانی از چندین محصول مایکروسافت
مایکروسافت طبق تقویم اعلامی، در این ماه رسما پشتیبانی از محصولات زیر را متوقف کرده است:

⚫️Windows 10 Enterprise & Education
⚫️Windows 10 Home & Pro
⚫️Office 2016 & 2019
⚫️Exchange Server 2016 & 2019
⚫️Skype for Business Server 2015 & 2019
⚫️Visio / Project 2016 & 2019
⚫️Visual Studio 2015
⚫️Windows Server 2012 / R2
⚫️SQL Server 2014

⚠️ اگر شرکت یا سازمان شما هنوز از یکی از این نسخه‌ها استفاده می‌کند، لازم است نسبت به ارتقا و یا جایگزینی محصول اقدام کنید. این محصولات از امروز طعمه های جذاب تری برای هکرها هستند ... !!! :)


https://news.1rj.ru/str/ViperNull

حتما ببینید

گزارش حملات به زیرساخت های ایران از سال 2023 تا 2025

اگر میخواید پرزنتی انجام بدید برای آنتی ویروس فایروال یا Endpoint هاتون میتونید از یک ویروس شبیه سازی شده برای اینکار استفاده کنید

اینکار برای پرزنت در جلسه مفیده که نحوه تشخیص ویروس و قرنطینه شدنش رو نشون بدید (برای مدیران جذابه)

ویروس شبیه سازی شده رو میتونید از سایت زیر بردارید

نکته ای که هست اینه که نگران نباشید این ویروس جوری program شده که آسیبی به شبکه یا سازمانتون نمیزنه و صرفا جهت تست طراحی شده

https://support.kaspersky.com/common/diagnostics/7399

@VMware_ESXI

آموزش کشف ساختار دایرکتوری با LDAP Enumeration 🫆
سلام، قراره توی این مقاله به Enumeration پروتکل LDAP بپردازم و یکسری تکنیک‌ها، ابزارها و سناریوهای واقعی رو با هم بررسی کنیم — — — — — — — — — — — — — — — — — — — —
پروتکل LDAP چیه و چگونه کار میکنه؟
LDAP (Lightweight Directory Access Protocol)
پروتکلی برای دسترسی و مدیریت اطلاعات دایرکتوری سرویس هستش که معمولاً روی
port 389 TCP (یا 636 برای LDAPS )
کار میکنه و برای احراز هویت و اعمال پالیسی‌ها در سیستم‌های سازمانی استفاده میشه.
برای مثال؛ دایرکتوری سرویس‌ها مثل Microsoft Active Directory یا در لینوکس OpenLDAP هستن که از LDAP برای ذخیره و بازیابی اطلاعات (یوزرها، گروه‌ها، کامپیوترها، پالیسی‌ها و ...) استفاده میکنن.
وقتی کاربری می‌خواد به دایرکتوری دسترسی داشته باشه، یک جلسه (DSA session) باز میشه و کوئری‌های LDAP فرستاده میشه تا اطلاعات لازم خوانده یا تغییر کنه.
حالا ما به‌عنوان یه کاربر نرمال (جوین دامین) چه اطلاعاتی می‌تونیم از Domain Controller استخراج کنیم؟
سوال: ما به‌عنوان یه کاربر معمولی که جوین دامین هستیم و دسترسی نصب/اجرا با دسترسی بالا یا تغییر تنظیمات رو نداریم، چه اطلاعاتی می‌تونیم از دومین کنترلر بدست بیاریم؟
آیا میشه فهمید چه یوزرها و گروه‌ها هستن، چه زمانی لاگین کردن، چند بار پسورد اشتباه زدن، کی پسوردشون عوض شده و خیلی اطلاعات دیگه رو از طریق LDAP از دومین کنترلر استخراج کرد؟
پاسخ: بله — میشه.
دلیلش اینه که بسیاری از این عملیات (خواندن اطلاعات دایرکتوری) با یک لاگین ساده و کوئری‌های معمولی قابل انجامه و از دید سرور رفتاری «نرمال» محسوب میشه پس به‌راحتی میشه اطلاعات زیادی استخراج کرد.

ابزارها
ابزارهایی مانند:
ldapsearch -- LDAP Explorer -- JXplorer
AD Explorer
(ابزاری از مجموع Sysinternals  ، پورتیبل نیاز به نصب نداره)

این ابزارها با وارد کردن IP DC و یوزر/پسورد نرمال جوین‌شده، کوئری LDAP میزنن و اطلاعات زیادی از DC استخراج میکنه.
(«نمونه تصویر که گزاشتم»)
اگر exe و msi بسته باشه چطور؟
حتی اگه در سازمان اجرای فایل‌های exe و نصب از msi محدود شده باشه  باز هم میشه از طریق CMD و PowerShell همین فرایندها رو انجام داد. فریم‌ورک‌هایی مثل Nishang و BloodHound از طریق کامندهای پاورشل  استخراج اطلاعات از LDAP و AD رو ساده میکنن.
در نتیجه: بستن اجرای EXE/MSI به‌تنهایی کافی نیست.اتکر می‌تونه از ابزارهای خط فرمان یا اسکریپت‌ها استفاده کنه.

راهکار برای جلوگیری و شناسایی این حمله
جلوگیری از LDAP Enumeration کمی سخته چون فرایندی که صورت می‌گیره اغلب کاملاً نرماله — یعنی یک لاگین موفق ساده اتفاق میفته و رفتار کلاینت‌ها هم مشابه اینه. حتی با اپلیکیشن وایت‌لیستینگ هم ابزارها قابل بای‌پس شدن هستن. بستن exe و msi هم مشکل‌زاست چون نرم‌افزاها از کار میفتن؛ و در نهایت اتکر می‌تونه از طریق cmd و PowerShell عمل کنه.
با این حال می‌تونیم با ترکیب چند راهکار، کار اتکر رو سخت‌تر کنیم

بهترین راهکار :
امن سازی LDAP و دسترسی‌ها
از LDAPS یا StartTLS استفاده کنین (رمزگذاری ارتباط)
فرابند Anonymous binds رو غیرفعال کنید و
حداقل دسترسی (least privilege) رو رعایت کنین حساب‌هایی که فقط باید خواندن محدودی داشته باشن رو محدود کنین
از گروه‌ها و ACLهای مناسب برای دایرکتوری استفاده کنین تا اطلاعات غیرضروری در دسترس همه نباشه

پالیسی‌ها و احراز هویت قوی‌تر
استفاده از گذرواژه‌های قویMFA برای حساب‌های حساس و کنترل گذرواژه‌های سرویس‌ها
مانیتورینگ و لاگ‌گیری های که باید انجام بدیم Endpoints + DC
لاگ‌های PowerShell و Process Creation روی اندپوینت‌ها رو فعال کنین
(CommandLine در Sysmon/EDR)
لاگ‌های لاگین روی DC و لاگ‌های کوئری LDAP (در صورت امکان) رو جمع‌آوری کنین
روی اندپوینت‌ها هم لاگ‌گیری انجام بدین چون اجرای ابزار یا اسکریپت‌ها اونجا ثبت میشه سمت dc ما کامندی نمیبینیم همین‌جا تحلیل CommandLine می‌تونه ما رو به استخراج LDAP کمک کنه

https://news.1rj.ru/str/ViperNull🫆

#گزارش Eset از فعالیت APT ها در سه ماهه دوم سال