بررسی استفاده از ابزار Performance Monitor (PerfMon) در تشخیص حملات مرتبط با Active Directory

نویسنده با تأکید بر اهمیت نظارت بر رویدادهای Active Directory، نشان می‌دهد که چگونه می‌توان با استفاده از PerfMon، حملاتی مانند Kerberoasting و AS-REP Roasting را شناسایی کرد.
در این مقاله، با استفاده از مجموعهٔ پیش‌فرض داده‌های تشخیصی Active Directory در PerfMon، رویدادهای مربوط به درخواست‌های Ticket Granting Service (TGS) که نشان‌دهندهٔ حملات Kerberoasting هستند، مورد بررسی قرار می‌گیرند. نویسنده با ارائهٔ تصاویری از نتایج به‌دست‌آمده، نشان می‌دهد که چگونه می‌توان با مشاهدهٔ تعداد زیاد درخواست‌های TGS توسط یک حساب کاربری، به وجود چنین حملاتی پی برد.

همچنین، مقاله به منابعی مانند «Kerberosity Killed the Domain: An Offensive Kerberos Overview» اشاره می‌کند که برای درک بهتر مفاهیم مرتبط با این نوع حملات مفید هستند.
در مجموع، این مقاله نشان می‌دهد که چگونه می‌توان از PerfMon برای نظارت بر رویدادهای Active Directory و شناسایی فعالیت‌های مشکوک مرتبط با حملات Kerberos استفاده کرد.

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

https://www.huntress.com/blog/perfmon-what-is-it-good-for

توضیحی بر مقاله ی فوق
و تمرین

✍️روزبه نوروزی

بررسی ابزار PerfMon برای کشف حمله کربروستینگ
فرای رویداد های 4768 و 4769

تکنیک Kerberoasting یکی از تکنیک‌های محبوب حمله در محیط‌های Active Directory (AD) است که مهاجمان از آن برای سرقت هش بلیط‌های سرویس (TGS) و کرک کردن رمزهای عبور حساب‌های سرویس استفاده می‌کنند. شناسایی این نوع حمله با ابزار Performance Monitor می‌تواند در کشف و جلوگیری از تهدیدات کمک کند.

1. مروری بر حمله Kerberoasting

مهاجم از یک حساب کاربری دامنه احراز هویت‌شده استفاده کرده و درخواست بلیط سرویس (TGS) را برای یک حساب سرویس که از رمز عبور ضعیف استفاده می‌کند، ارسال می‌کند. این بلیط سپس از حافظه استخراج و برای کرک شدن به ابزارهایی مانند Hashcat یا John the Ripper داده می‌شود.

2. چرا PerfMon برای شناسایی مفید است؟

این ابزار یک ابزار داخلی ویندوز است که داده‌های عملکردی سیستم را جمع‌آوری و نمایش می‌دهد. با استفاده از PerfMon می‌توان شاخص‌های غیرعادی مربوط به درخواست‌های TGS را نظارت کرده و فعالیت‌های مشکوک را شناسایی کرد.

3. پیکربندی PerfMon برای شناسایی Kerberoasting

3.1. اجرای Performance Monitor

3.2. ایجاد یک Data Collector Set سفارشی

در بخش Data Collector Sets، روی User Defined کلیک راست کرده و New > Data Collector Set را انتخاب کنید.

یک نام مانند Kerberoasting Detection وارد کنید و گزینه Create manually (Advanced) را انتخاب کنید.

روی Performance Counter کلیک کرده و گزینه Add را بزنید.

3.3. افزودن کانترهای مرتبط

افزودن کانترهای زیر به تشخیص رفتار مشکوک کمک می‌کند:

Security System-Wide Statistics > Ticket Granting Service Requests

Security System-Wide Statistics > Kerberos Authentications

3.4. تنظیم Alert برای فعالیت غیرعادی

در Performance Monitor، به Alerts بروید

مقدار آستانه را برای TGS Requests روی مقدار غیرمعمول بالا تنظیم کنید (مثلاً بیش از 100 در یک دقیقه).

یک Action تعریف کنید که در صورت عبور از این مقدار، هشدار ارسال شود.

4. تحلیل نتایج و تشخیص فعالیت‌های مشکوک

بعد از اجرای PerfMon، تیم امنیتی می‌تواند گزارش‌های ذخیره‌شده را تجزیه‌وتحلیل کند:

افزایش درخواست‌های TGS: اگر تعداد درخواست‌ها افزایش پیدا کند، ممکن است نشانه‌ای از حمله باشد.

درخواست‌های زیاد از یک حساب کاربری خاص: اگر یک حساب معمولی (نه حساب سرویس) تعداد زیادی درخواست TGS ارسال کند، احتمال حمله افزایش می‌یابد.

درخواست‌های متعدد برای بلیط‌های حساب‌های حساس: مهاجمان اغلب به دنبال حساب‌های سطح بالا یا سرویس‌های حیاتی هستند.

5. اقدامات اصلاحی در برابر این حمله

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

بررسی لاگ‌های امنیتی در Event Viewer: به مسیر Windows Logs > Security رفته و Event ID 4769 را بررسی کنید.

فعال کردن حسابرسی Kerberos در Group Policy: مسیر Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration را باز کنید و گزینه Audit Kerberos Authentication Service را فعال کنید.

استفاده از رمزهای عبور قوی برای سرویسها: از حساب‌های مدیریت‌شده (gMSA) استفاده کنید تا رمزهای عبور به‌طور خودکار تغییر کنند.

محدود کردن استفاده از حساب‌های دارای SPN: آنها که نیازی به SPN ندارند را بررسی کرده و حذف کنید.

نصب ابزارهای امنیتی مکمل: SIEM و EDR


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

در SOC استفاده کنید: Measured Boot
کشف نفوذ در عمق🔴


این Measured Boot چیست و چگونه جلوی نفوذ را می‌گیرد؟
این موضوع یکی از قابلیت‌های امنیتی در TPM 2.0 است که به سیستم‌عامل و ابزارهای امنیتی مانند EDR/XDR یا SIEM (مثل Splunk) کمک می‌کند تا تغییرات در فرآیند بوت را شناسایی کنند.

✅ عملکرد Measured Boot:

هر مرحله از بوت توسط TPM هش شده و در PCR (Platform Configuration Registers) ذخیره می‌شود.
این مقادیر هش در SIEM یا EDR/XDR ارسال می‌شوند و بررسی می‌شود که آیا تغییری رخ داده است یا خیر.
اگر مقدار هش با مقدار مورد انتظار تطابق نداشته باشد، یعنی یک Bootkit، Rootkit، یا تغییر غیرمجاز در Bootloader یا کرنل رخ داده است.

🔹 نکته مهم:Measured Boot نمی‌تواند جلوی نفوذ را بگیرد، اما آن را شناسایی کرده و به SIEM/EDR هشدار می‌دهد.
🔹 در ترکیب با Secure Boot و TPM Attestation، می‌تواند جلوی اجرای بوت‌لودرهای غیرمجاز را هم بگیرد.


❇️استفاده از Measured Boot در Splunk برای کشف نفوذ

هدف: بررسی لاگ‌های Measured Boot در Splunk و تشخیص Bootkits یا Rootkits.

1. فعال‌سازی لاگ‌های Measured Boot در ویندوز

✅ مطمئن شوید که TPM و Secure Boot فعال هستند.
✅ این Windows Event Logging را برای Measured Boot فعال کنید:

Group Policy Editor را باز کنید:

Computer Configuration -> Administrative Templates -> System -> Trusted Platform Module Services

گزینه Turn on TPM Services Logging را فعال کنید.
و Reboot کنید تا تنظیمات اعمال شوند.

2. ارسال لاگ‌های Measured Boot به Splunk

این Splunk می‌تواند لاگ‌های مربوط به TPM و Measured Boot را جمع‌آوری کند.

✅ منبع لاگ‌ها در ویندوز:

Windows Logs -> Security -> Event ID 4912 (Measured Boot Logs)

✅ منبع لاگ‌ها در لینوکس:

/sys/kernel/security/tpm0/binary_bios_measurements

💡 اضافه کردن این لاگ‌ها به Splunk:

پیکربندی Universal Forwarder در Splunk:

splunk add monitor "C:\Windows\System32\winevt\Logs\Security.evtx" -sourcetype winlog

استفاده از Windows Event Collector (WEC) برای دریافت لاگ‌های Measured Boot:

wevtutil qe Security /q:"*[System[(EventID=4912)]]" /f:text

پیکربندی Input در Splunk (inputs.conf):

[WinEventLog://Security]
disabled = 0
index = security
sourcetype = WinEventLog:Security

3. تحلیل لاگ‌های Measured Boot در Splunk

✅ جستجوی تغییرات غیرمجاز در PCR (Platform Configuration Registers)

index=security sourcetype=WinEventLog:Security EventID=4912
| eval PCR_Values = mvjoin(PCR_Values, ",")
| table _time host PCR_Values

📌 اگر مقدار PCR در بوت‌های مختلف تغییر کند، یعنی تغییری در Bootloader یا کرنل رخ داده است.

✅ شناسایی سیستم‌هایی که Measured Boot آن‌ها ناموفق بوده است:

index=security sourcetype=WinEventLog:Security EventID=4912 Status!="Success"
| table _time host Status

📌 اگر مقدار Status چیزی غیر از "Success" باشد، احتمال دارد که سیستم مورد حمله قرار گرفته باشد.

✅ مقایسه مقادیر Measured Boot بین بوت‌های مختلف:

index=security sourcetype=WinEventLog:Security EventID=4912
| stats values(PCR_Values) by host

📌 اگر مقدار PCR_Values بین بوت‌های مختلف تغییر کرده باشد، احتمالا یک Bootkit فعال شده است.
4. تنظیم هشدار (Alert) در Splunk

اگر تغییری در PCR Values شناسایی شود، باید یک هشدار در Splunk تنظیم کنیم:

✅ ساختن هشدار در Splunk برای تغییر در PCR Values

به Splunk Alert Manager بروید.
جستجوی زیر را به عنوان شرط هشدار تنظیم کنید:

index=security sourcetype=WinEventLog:Security EventID=4912
| stats count by PCR_Values
| where count > 1

در Trigger Actions، ارسال ایمیل یا اجرای اسکریپت برای بررسی سیستم را فعال کنید.

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

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

✍️روزبه نوروزی

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

در ادامه روش‌های بررسی امضای بسته‌ها در APT (Debian/Ubuntu)، YUM و DNF (RHEL/CentOS)، و Snap آورده شده است.
1. بررسی امضای دیجیتال در APT (Debian/Ubuntu)

در APT از GPG keys برای امضای بسته‌ها استفاده می‌شود
الف) بررسی کلیدهای مخزن

ادمین‌ها باید ابتدا کلیدهای مورداعتماد را تأیید کنند:

apt-key list

یا برای سیستم‌های جدیدتر:

gpg --list-keys --keyring /etc/apt/trusted.gpg

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

برای بررسی امضای یک بسته قبل از نصب:

apt-cache policy <package-name>

مثال:

apt-cache policy openssh-server

اگر در خروجی "500" یا "100" مشاهده شد، یعنی از یک مخزن رسمی دریافت می‌شود.
ج) بررسی صحت بسته‌های دانلود شده

پس از دانلود:

dpkg-sig --verify package.deb

همچنین، می‌توان از debsig-verify استفاده کرد:

debsig-verify package.deb

2. بررسی امضای دیجیتال در YUM و DNF (RHEL/CentOS)

YUM و DNF از GPG keys برای اعتبارسنجی استفاده می‌کنند.
الف) بررسی کلیدهای GPG

لیست کلیدهای نصب‌شده را بررسی کنید:

rpm -q gpg-pubkey --qf "%{NAME}-%{VERSION}-%{RELEASE}\n"

ب) بررسی امضای بسته‌ها قبل از نصب

yum list <package-name>
dnf repoquery --info <package-name>

اگر Signature : RSA/SHA256, Key ID نمایش داده شود، یعنی بسته معتبر است.
ج) بررسی امضای یک بسته RPM

پس از دانلود بسته:

rpm --checksig -v package.rpm

مثال:

rpm --checksig -v httpd-2.4.6-97.el7.centos.x86_64.rpm

اگر نتیجه gpg OK باشد، یعنی امضا معتبر است.
3. بررسی امضای دیجیتال در Snap

Snap از امضای دیجیتال Canonical برای تضمین امنیت بسته‌ها استفاده می‌کند.
الف) بررسی امضای بسته Snap

قبل از نصب:

snap info <package-name>

مثال:

snap info vlc

اطمینان حاصل کنید که نام Publisher همان ناشر رسمی بسته است.
ب) بررسی تأییدیه GPG برای Snap

برای بررسی صحت امضای مخزن:

snap known account-key

این دستور کلیدهای عمومی امضاکننده را نشان می‌دهد.


**هشدار : همانطور که مسبوق به سابقه است امضا ها هم جعل شده اند. پس مسوولان امنیت کشور و تیم امنیت سازمان باید فکری کند.
راهکار اول اطلاعات هوش تهدید

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

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

من خودم قصد دارم کتاب زیر رو شروع کنم تا خرده خوانده ها که تا حالا داشته ام و تجربه ای که در این حوزه اندوخته ام در یک جا از پایه تجمیع بشن و در ذهنم قوام پیدا کنند.
چون معتقدم کتاب خوب میتونه یه بنيان خوب برای درک و فهم کامل باشه.

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

کتاب در زمینه راهکارهایی است که نفوذگران پیشرفته درپی می‌گیرند تا ما را دور بزنند . راهنمایی برای کشف؛ تحلیل و مقابله برای تهدیدات پیشرفته.
سطح کتاب :بین متوسط و بالا

بسم الله

لینک اصل کتاب سال ۲۰۲۴ در آمازون
https://www.amazon.com/Evasive-Malware-Understanding-Deceptive-Self-Defending/dp/1718503261

لینک سرفصل کتاب:
https://www.oreilly.com/library/view/evasive-malware/9781098182236/

لینک گروه همخوانی کتاب نوروز برای عضویت :

https://t.me/+iv8QJhCC4W4xZjJk

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

فکر میکنم این کار جالبیه

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

https://docs.google.com/spreadsheets/u/0/d/1E5SDC5cwXWz36rPP_TXhhAvTvqz2RGnMYXieu4ZHx64/htmlview?pli=1#gid=0

من بعد واسه آسیب پذیری ها این سایت رو هم چک کنید

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

https://center-for-threat-informed-defense.github.io/mappings-explorer/external/kev/attack-15.1/domain-enterprise/kev-02.13.2025/CVE-2024-37085/

ریسک رو چطور انجام دادید ؟

اونو ارزیابی کنید

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

🟢تجربه ۸ ماهه من در کار با DLP


🚨کدام به‌روش ها برای پیاده سازی DLP مناسب هستند چون برخی پروژه ها به شکست می‌خورند

✍️روزبه نوروزی

پیاده‌سازی موفق DLP به یک رویکرد جامع نیاز دارد، زیرا بسیاری از پروژه‌های Data Loss Prevention (DLP) به دلیل عدم برنامه‌ریزی مناسب، پیچیدگی فنی، و مقاومت کاربران شکست می‌خورند. در ادامه، بهترین روش‌ها (Best Practices) برای پیاده‌سازی موفق Symantec DLP آورده شده است:
1. تعریف اهداف و استراتژی DLP

قبل از پیاده‌سازی باید به سؤالات زیر پاسخ دهید:
✅ چه داده‌هایی باید محافظت شوند؟ (اطلاعات مالی، مشتریان، داده‌های محرمانه)
✅ چه تهدیداتی وجود دارند؟ (نشت داده از طریق ایمیل، USB، کپی در Cloud و غیره)
✅ کدام بخش‌ها بیشترین خطر را دارند؟ (مالی، منابع انسانی، IT)

🔹 راهکار: استفاده از Data Classification برای اولویت‌بندی داده‌های حساس.
2. شناخت و طبقه‌بندی داده‌ها

✅ راهکار: ابتدا یک Discovery Scan اجرا کنید تا بدانید داده‌های حساس کجا ذخیره شده‌اند و سپس Policyهای مناسب را تنظیم کنید.

💡 اشتباه رایج: تنظیم سیاست‌های خیلی سختگیرانه بدون شناخت صحیح داده‌ها، که باعث هشدارهای کاذب (False Positive) و نارضایتی کاربران می‌شود.
3. شروع با مانیتورینگ (Monitor Mode) و نه بلاک کردن

✅ راهکار: ابتدا سیاست‌ها را در حالت Monitor تنظیم کنید تا تأثیر آن‌ها روی سیستم بررسی شود.
💡 دلیل: اگر سیاست‌ها مستقیماً در حالت Block باشند، ممکن است عملیات تجاری دچار اختلال شود و مقاومت کاربران افزایش یابد.
4. اجرای سیاست‌ها به‌صورت مرحله‌ای (Phased Approach)

✅ راهکار: سیاست‌های DLP را مرحله‌به‌مرحله اجرا کنید، نه به‌صورت یکجا.
🔹 مثال:

فاز ۱: نظارت بر ایمیل‌های خروجی
فاز ۲: نظارت بر داده‌های USB و Cloud
فاز ۳: اجرای سیاست‌های بلاکینگ

💡 چرا؟ اجرای ناگهانی تمام سیاست‌ها باعث نارضایتی کارمندان و مشکلات عملکردی می‌شود.
5. ایجاد فرآیندهای پاسخگویی (Incident Response Plan)

✅ راهکار: قبل از اجرای سیاست‌های DLP، مشخص کنید که در صورت نقض قوانین، چه اقدامی انجام خواهد شد.
🔹 مثال:

ارسال هشدار به کاربر و تیم امنیت
بررسی دستی و تأیید تخلفات
مسدود کردن خودکار انتقال داده

💡 اشتباه رایج: نداشتن برنامه مشخص، که باعث تأخیر در واکنش به تهدیدها می‌شود.
6. تعامل با کاربران و آموزش آن‌ها

✅ راهکار: کارمندان باید بدانند که DLP برای کمک به امنیت سازمان است، نه صرفاً برای کنترل آن‌ها.
🔹 اقدامات:

برگزاری جلسات آموزشی درباره سیاست‌های DLP
اطلاع‌رسانی درباره دلایل مسدود شدن برخی فعالیت‌ها
ارائه راهکارهای جایگزین (مانند استفاده از VPN یا Secure File Transfer برای ارسال داده‌های حساس)

💡 دلیل شکست: مقاومت کاربران به دلیل اطلاع نداشتن از هدف پروژه DLP.
7. استفاده از Context-Aware Policies

✅ راهکار: به جای مسدود کردن تمام فعالیت‌ها، از سیاست‌های هوشمند و مبتنی بر محتوا (Content-Aware) استفاده کنید.
🔹 مثال:

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

💡 دلیل شکست: تنظیم قوانین سفت‌وسخت که عملکرد کسب‌وکار را مختل می‌کند.
8. نظارت و بهینه‌سازی مداوم (Continuous Tuning & Optimization)

✅ راهکار: تنظیمات و سیاست‌های DLP را به‌صورت دوره‌ای بازبینی کنید و بر اساس گزارش‌ها و وقایع امنیتی بهینه‌سازی کنید.
🔹 ابزارها:

تحلیل False Positive و تنظیم قوانین برای کاهش آن
بررسی عملکرد سیستم و بهینه‌سازی سیاست‌ها برای جلوگیری از کاهش کارایی

💡 اشتباه رایج: تنظیم یک‌باره‌ی DLP و عدم بررسی مداوم، که باعث هشدارهای زیاد و ناکارآمدی سیاست‌ها می‌شود.
9. استفاده از یک تیم متخصص و همکاری با مدیران سازمان

✅ راهکار:

تیمی متشکل از امنیت اطلاعات، شبکه، حقوقی و منابع انسانی تشکیل دهید.
مدیران سازمان را در جریان بگذارید تا از اجرای سیاست‌های DLP حمایت کنند.

💡 دلیل شکست: عدم حمایت مدیران و نادیده گرفتن نیازهای بخش‌های مختلف سازمان.
جمع‌بندی: چرا پروژه‌های DLP شکست می‌خورند؟

❌ سیاست‌های خیلی سختگیرانه بدون شناخت دقیق داده‌ها
❌ عدم تعامل و آموزش کاربران
❌ اجرای ناگهانی و بدون برنامه‌ریزی
❌ تنظیم نکردن فرآیندهای پاسخگویی
❌ عدم بررسی و بهینه‌سازی مداوم

✅ راهکارهای موفقیت:
1️⃣ اجرای اسکن‌های اولیه برای شناخت داده‌ها
2️⃣ شروع با مانیتورینگ و اجرای سیاست‌ها به‌صورت تدریجی
3️⃣ تعامل و آموزش کاربران برای کاهش مقاومت
4️⃣ تنظیم سیاست‌های هوشمند و انعطاف‌پذیر
5️⃣ بررسی مداوم و بهینه‌سازی سیاست‌های DLP

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

👆💡 با این روش‌ها، DLP نه‌تنها باعث بهبود امنیت سازمان می‌شود، بلکه از ایجاد مشکلات عملیاتی جلوگیری می‌کند.

انتقال تجربه در SOC و IR


✍️روزبه نوروزی

دوستان در لینکدین و اینجا از انتقال تجربه استقبال کردند. من هم دیدم چون از یک سناریویی که درگیر بودم چند وقتی گذشته؛ میتونم اونو بیان کنم.

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

✴️ تحلیل و حذف یک Rootkit کرنل در ویندوز

📌 پس از مشاهدات اعلان رولها ( فایر شدن ) و ارتباطات مشکوک و پراسس های غیر مرتبط روی یک سرور در داشبورد اسپلانک ، آن سرور از بقیه جدا شد و تحت تحلیل قرار گرفت .
مشاهدات که پی در پی کم کم پدیدار شدند عبارتند از :

پردازش‌هایی که در Task Manager دیده نمی‌شوند.
اتصال‌های شبکه‌ای که در netstat ظاهر نمی‌شوند.
فایل‌هایی که در Explorer و CMD دیده نمی‌شوند.
کاربرانی که به سیستم لاگین می‌کنند اما در لاگ‌ها ثبت نمی‌شوند.

اینها نشان بزرگی برای وجود روت کیت بودند .

🔹 هدف: با توجه به اهمیت up بودن سرور و کمبود زمان Down time؛ شناسایی، تحلیل، و حذف Rootkit بدون آسیب به سیستم در دستور کار قرار گرفت .
1️⃣ کشف اولیه – بررسی نشانه‌های Rootkit
الف) بررسی پردازش‌های پنهان‌شده

در ویندوز، Rootkit ممکن است با Hook کردن APIهای کاربری یا Patch کردن کرنل پردازش‌های مخرب را مخفی کند.
راه بررسی این است که از WMIC یا Process Explorer استفاده کنیم:

wmic process list full | findstr /i "SuspiciousProcess"

اگر پردازش در Task Manager نباشد ولی در wmic ظاهر شود، Rootkit در حال پنهان‌سازی است.

🔹 ابزار Sysinternals Process Explorer را اجرا می‌کنیم و در قسمت Verify Signatures، پردازش‌های مشکوک را بررسی می‌کنیم.
ب) بررسی ارتباطات شبکه‌ای مخفی

بد افزار Rootkit ممکن است برخی از اتصالات مخرب را پنهان کند. برای بررسی دقیق، از Wireshark یا TCPView (Sysinternals) استفاده می‌کنیم.
اما یک روش سریع‌تر این است که از PowerShell استفاده کنیم:

Get-NetTCPConnection | Where-Object { $_.State -eq "Established" }

سپس این خروجی را با netstat -ano مقایسه می‌کنیم. اگر تفاوتی وجود داشت، نشان‌دهنده Hook شدن APIها توسط Rootkit است.

البته نکته مهم اینه که در اون مجموعه ZEEK هم کمک مهمی داشت تونستیم بفهمیم که چه کانکشن هایی واقعی وجود داره که روی سرور نمیبینم.

ج) بررسی فایل‌های مخفی‌شده

برخی Rootkitها با استفاده از NTFS Alternate Data Streams (ADS) فایل‌های خود را پنهان می‌کنند.
برای شناسایی، از دستور زیر استفاده می‌کنیم:

dir /r C:\Windows\System32

اگر فایل‌هایی با نام‌های عجیب همراه با :Zone.Identifier یا :hidden ببینیم، ممکن است Rootkit باشد.
2️⃣ بررسی سطح پایین‌تر – تحلیل کرنل
الف) بررسی Hook های SSDT و IRP

این Rootkitهای پیشرفته معمولاً System Service Descriptor Table (SSDT) را دستکاری می‌کنند.
برای بررسی، از ابزار GMER یا WinDbg استفاده می‌کنیم.

🔹 روش با GMER:

این GMER را اجرا می‌کنیم. اگر Rootkit SSDT را Hook کرده باشد، در تب "Rootkit/Malware" نمایش داده می‌شود.

🔹 روش با WinDbg:

کامپیوتر هدف را به سیستم تحلیلگر متصل می‌کنیم.
در WinDbg دستور زیر را اجرا می‌کنیم:

!chkimg -lo 50 -d nt

این دستور بررسی می‌کند که آیا کرنل ویندوز Patch شده است یا خیر.
ب) بررسی درایورهای کرنل مخرب

این Rootkit کرنلی معمولاً یک Driver مخرب (sys.) را بارگذاری می‌کند.
برای لیست کردن تمام درایورهای کرنل در حال اجرا:

Get-WmiObject Win32_SystemDriver | Select-Object Name,PathName,State

یا با استفاده از sigcheck (از Sysinternals) می‌توان درایورهای فاقد امضای دیجیتال را یافت:

sigcheck -u -v

اگر درایوری بدون امضای دیجیتال مایکروسافت مشاهده کردیم، باید بیشتر بررسی شود.
3️⃣ استخراج و تحلیل Rootkit
الف) Dump گرفتن از درایور مشکوک

اگر یک درایور مشکوک پیدا کردیم، می‌توانیم آن را استخراج کنیم:

copy C:\Windows\System32\drivers\suspicious.sys C:\Investigate\suspicious.sys

سپس با IDA Pro, Ghidra یا WinDbg تحلیل مهندسی معکوس انجام می‌دهیم.
ب) بررسی ارتباطات C2

برخی Rootkitها به سرور کنترل و فرماندهی (C2) متصل می‌شوند.
برای بررسی این ارتباطات از Wireshark یا Fiddler استفاده می‌کنیم.
در Wireshark می‌توانیم با فیلتر DNS یا HTTP ترافیک مشکوک را پیدا کنیم:

dns.qry.name contains "suspicious.com"

4️⃣ حذف و پاک‌سازی Rootkit
الف) حذف درایور مخرب

🔹 اگر Rootkit از یک درایور کرنل استفاده می‌کند، نباید آن را مستقیماً حذف کنیم، بلکه باید Disable کنیم:

sc stop suspicious
sc delete suspicious

ب) ریست تنظیمات کرنل




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

ادامه در پست بعد

ادامه از پست قبل

🔹 برای بازگردانی Hookهای کرنل و SSDT، باید از Safe Mode بوت کنیم و سپس دستور زیر را اجرا کنیم:

sfc /scannow

این کار فایل‌های سیستمی تغییر داده‌شده را بازیابی می‌کند.
ج) بلاک ماندگاری Rootkit

🔹 برخی Rootkitها در Registry خود را دوباره فعال می‌کنند.
با این دستور می‌توان کلیدهای مشکوک را پیدا کرد:

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

اگر مقدار مشکوکی پیدا کردیم، حذفش می‌کنیم:

reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v malicious /f

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

🔆آشنایی با مشاغل امنیت سایبری :vCISO

این vCISO (Virtual Chief Information Security Officer) یک متخصص ارشد و ماهر امنیت اطلاعات است که به‌صورت قراردادی یا پاره‌وقت با سازمان‌ها همکاری می‌کند تا راهبری امنیت سایبری آن‌ها را انجام دهد. این نقش برای شرکت‌هایی که نیاز به راهبری امنیتی دارند اما نمی‌خواهند یا نمی‌توانند یک CISO تمام‌وقت استخدام کنند، ایده‌آل است.

🟣وظایف vCISO

✔️تدوین و اجرای استراتژی امنیتی: طراحی و پیاده‌سازی برنامه‌های امنیتی مطابق با نیازهای سازمان.
✔️ارزیابی و مدیریت ریسک: شناسایی تهدیدات و ارائه راهکارهای کاهش ریسک.
✔️انطباق با قوانین و مقررات: اطمینان از رعایت استانداردها و الزامات قانونی مانند شاپرک ؛ NIST, ISO 27001, GDPR, PCI-DSS.
✔️نظارت بر عملیات امنیتی: تحلیل گزارشات امنیتی، بررسی رخدادها و همکاری با تیم SOC.
✔️آموزش و آگاهی‌بخشی: ارتقای فرهنگ امنیت سایبری در سازمان.
✔️مدیریت کشف نفوذ و پاسخ به حادثه: تدوین و اجرای برنامه‌های واکنش به رخدادهای امنیتی و نظارت بر آن
✔️نظارت بر تامین‌کنندگان و شرکای امنیتی: ارزیابی امنیتی پیمانکاران و زنجیره تأمین.
✔️ مشاوره به مدیریت ارشد: ارائه گزارش‌ها و پیشنهادات راهبردی به مدیران سازمان.

❇️حوزه فعالیت vCISO

استارتاپ‌هایی که قصد دارند در بازارهای تنظیم‌شده فعالیت کنند.
شرکت‌های کوچک و متوسط (SMB) که نیروی متخصص داخلی ندارند.
سازمان‌های در حال رشد که به راهبری امنیتی نیاز دارند.
شرکت‌های در صنایع حساس مانند بانکداری، سلامت، فناوری و دولتی.


🔴اختیارات vCISO

تصمیم‌گیری در مورد سیاست‌های امنیتی.
هدایت تیم امنیتی و تعیین نقش‌ها و وظایف.
پیشنهاد خرید ابزارها و راهکارهای امنیتی.
تعامل مستقیم با مدیرعامل (CEO)، مدیر فناوری (CTO) و هیئت‌مدیره.
همکاری با تیم حقوقی و انطباق برای مدیریت ریسک‌های قانونی.

به دلیل ماهیت قراردادی این نقش، اختیارات vCISO معمولاً محدودتر از یک CISO تمام‌وقت است و نیاز به همکاری نزدیک با مدیران سازمان دارد.

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

مقاله‌ای با عنوان «حالت مخفی: دامپ LSASS بدون ردپا»

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

در این مقاله، نویسنده با استفاده از PowerShell و تکنیک‌های خاصی مانند بازتاب حافظه (Memory Reflection)، دسترسی حداقلی به فرآیندها و رمزنگاری داده‌ها، روشی را برای استخراج حافظه LSASS معرفی می‌کند. این روش شامل مراحل زیر است:

شناسایی پراسس LSASS:
با استفاده از دستورات PowerShell، فرآیند LSASS به‌طور مخفیانه شناسایی می‌شود.

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

دامپ حافظه با استفاده از بازتاب درون‌حافظه‌ای:
با تعریف پویا و درون‌حافظه‌ای توابع API مورد نیاز، از شناسایی توسط ابزارهای امنیتی جلوگیری می‌شود.

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

فشرده‌سازی، انتقال و حذف آثار:
فایل رمزنگاری‌شده فشرده شده و پس از انتقال، تمامی ردپاها از سیستم حذف می‌شوند.

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

برای مطالعه دقیق‌تر و مشاهده جزئیات فنی، می‌توانید به مقاله اصلی در لینک زیر مراجعه کنید:



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

https://mrvar0x.com/2025/02/16/stealth-mode-dumping-lsass-without-a-trace/

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

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

https://medium.com/@iramjack8/hunting-for-processes-53c541d8cfc2

یه شرح خوب از حملات در حوزه کربروس و روش‌های مقابله

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

https://medium.com/@noah_h/offensive-kerberos-techniques-for-detection-engineering-16a81483f676

🔴 کشف در ترافیک رمز شده

✍️روزبه نوروزی

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



این JA3 چیست و چگونه محاسبه می‌شود؟

عامل JA3 یک تکنیک fingerprinting برای شناسایی کلاینت‌های TLS است که توسط John Althouse توسعه داده شده است. این روش برای شناسایی کلاینت‌های مختلف بر اساس پارامترهای TLS در Client Hello مورد استفاده قرار می‌گیرد.
نحوه محاسبه JA3 Hash

این JA3 با استفاده از ترکیب مقادیر مشخصی از بسته Client Hello در TLS یک رشته متنی تولید کرده و سپس از آن یک MD5 Hash ایجاد می‌کند. این پارامترها عبارتند از:

Version → نسخه‌ی TLS
Accepted Cipher Suites → لیست الگوریتم‌های رمزنگاری
List of Extensions → لیست افزونه‌های TLS
Elliptic Curves → منحنی‌های بیضوی قابل قبول
Elliptic Curve Point Formats → فرمت‌های نقطه‌ای منحنی بیضوی

پس از استخراج این مقادیر، آن‌ها به صورت عددی (بدون فاصله) در قالب یک رشته به هم متصل شده و از آن MD5 Hash گرفته می‌شود.
مثال رشته‌ی JA3:

771,49200-49199-49192-49191-52393,23-65281-10-35,29-23-24,0

MD5 Hash → 4d7a28e74224b2e9b22c206f2d7cbbeb
مزایای JA3

شناسایی بدافزارها و ابزارهای مخرب
تشخیص ترافیک رمزگذاری‌شده حتی بدون رمزگشایی
مانیتورینگ ارتباطات مشکوک در شبکه

حالا JA4 چیست و چه تفاوتی با JA3 دارد؟

اینJA4 نسخه‌ی بهبود‌یافته‌ی JA3 است که نه‌تنها Client Hello بلکه Server Hello را نیز بررسی می‌کند.



مزایای JA4 نسبت به JA3:

دقت بیشتر در شناسایی کلاینت‌های واقعی و بدافزارها
توانایی fingerprinting سرورها
امکان شناسایی TLS Encrypted Client Hello (ECH)


اگر به تحلیل ترافیک رمزگذاری‌شده و امنیت شبکه علاقه دارید، بهتر است در کنار JA3، از JA4 نیز استفاده کنید.


کاربرد JA3 و JA4 در کشف نفوذ و حملات سایبری

این JA3 و JA4 به‌عنوان TLS Fingerprinting به شناسایی الگوهای خاص در ترافیک رمزگذاری‌شده کمک می‌کنند. این روش‌ها بدون نیاز به رمزگشایی (TLS Decryption)، کلاینت‌ها و سرورها را بر اساس ویژگی‌های ارتباطی شناسایی کرده و در کشف انواع تهدیدات مؤثر هستند.
حملات و نفوذهایی که JA3 و JA4 قادر به شناسایی آن‌ها هستند
1. بدافزارهایی که از TLS برای ارتباط با C2 استفاده می‌کنند

JA3 می‌تواند برای شناسایی بدافزارهایی که از ارتباطات رمزگذاری‌شده استفاده می‌کنند، مفید باشد. برخی از مهم‌ترین بدافزارهایی که با JA3 شناسایی شده‌اند عبارت‌اند از:

✅ TrickBot
✅ Emotet
✅ Ursnif (Gozi)
✅ Cobalt Strike
✅ Metasploit Meterpreter

روش کشف:

هر بدافزار معمولاً هنگام برقراری ارتباط با سرور C2، یک JA3 Hash ثابت دارد.
این مقدار می‌تواند با Threat Intelligence Feeds مقایسه شود تا ارتباطات مشکوک شناسایی شوند.

2. حملات MITM (Man-in-the-Middle)

✅ JA4S می‌تواند سرورهای مخرب را که در حملات MITM استفاده می‌شوند، شناسایی کند.

حملاتی که در آن‌ها SSL Proxy‌های مخرب برای رهگیری ترافیک رمزگذاری‌شده استفاده می‌شوند.
ابزارهایی مانند Bettercap، mitmproxy و Burp Suite که در تحلیل و دستکاری TLS مورد استفاده قرار می‌گیرند، JA3/JA4 خاصی دارند که قابل شناسایی است.

3. دور زدن مکانیزم‌های امنیتی (Evasion Techniques)

✅ شناسایی ابزارهایی که برای دور زدن IDS/IPS یا فایروال استفاده می‌شوند، مانند:

Tor Browser
Proxies و VPNهای خاص
Malicious TLS Libraries (مانند OpenSSL‌های تغییر یافته در بدافزارها)

JA3 می‌تواند تشخیص دهد که یک ارتباط واقعاً از یک مرورگر عادی مانند Chrome یا Firefox آمده است یا اینکه از طریق ابزارهای تغییر مسیر مثل Proxies و VPN‌های ناشناس‌کننده هدایت شده است.
4. Exploits و حملات RCE در سرورهای TLS

✅ JA4S می‌تواند رفتار سرورهای آسیب‌پذیر را شناسایی کند.

برخی سرورهای مخرب یا آلوده به بک‌دور، JA4 مشخصی دارند که می‌تواند آن‌ها را از سرورهای عادی متمایز کند.
در حملاتی مانند Heartbleed یا RCEهای جدید در OpenSSL، سرور آلوده معمولاً یک پاسخ خاص در Server Hello دارد که با JA4 قابل شناسایی است.

5. حملات با استفاده از ابزارهای تست نفوذ

✅ بسیاری از ابزارهای تست نفوذ (Red Team و هکرها) دارای JA3 ثابت هستند، از جمله:

Cobalt Strike
Metasploit Framework
Empire
Meterpreter

✅ برخی سرورهای مخرب مانند Cobalt Strike Team Server نیز JA4S ثابت دارند که توسط تیم‌های امنیتی شناسایی می‌شود.
محدودیت‌های JA3 و JA4

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

ادامه از پست قبل

⛔ در حملات TLS 1.3 با Encrypted Client Hello (ECH) → JA3 نمی‌تواند fingerprinting انجام دهد.
⛔ بدافزارهای جدید می‌توانند JA3 خود را تغییر دهند (JA3 Evasion).
⛔ اگر سرورها JA3 را تغییر دهند، روش شناسایی آن سخت‌تر می‌شود.

✅ راهکار: استفاده از JA4 (شناسایی همزمان Client و Server) و ترکیب آن با تحلیل‌های دیگر مانند رفتارشناسی و Threat Intelligence Feeds.

بنابراین JA3 برای شناسایی کلاینت‌های مخرب و JA4 برای بررسی کلاینت و سرور به‌صورت همزمان کاربرد دارد.






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

این مقاله امروزه که براتون انتخاب کردم

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

https://hunt.io/blog/golang-beacons-vs-code-tunnels-tracking-cobalt-strike

مکانیسم های حضور دائمی هکر در لینوکس
فارسی از جناب ملکی

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