🚨ابزار روز

KrbRelayEx is a tool designed for performing Man-in-the-Middle (MitM) attacks by relaying Kerberos AP-REQ tickets. It listens for incoming SMB connections and forwards the AP-REQ to the target host, enabling access to SMB shares or HTTP ADCS (Active Directory Certificate Services) endpoints on behalf of the targeted identity.

✅شرح مساله :

تیکت AP-REQ ‌که در ابزار نفوذ فوق بدان اشاره شده است ؛در پروتکل احراز هویت Kerberos بخشی از فرایند احراز هویت سرویس‌گیرنده به سرویس موردنظر است. این تیکت شامل اطلاعاتی است که به سرور مقصد اجازه می‌دهد هویت کلاینت را تأیید کند.
فرایند صدور و استفاده از AP-REQ

دریافت تیکت TGS (تیکت سرویس) از TGS
کلاینت پس از احراز هویت اولیه، از Ticket Granting Server (TGS) یک تیکت برای دسترسی به سرویس خاصی دریافت می‌کند.
این تیکت با کلید سرویس رمزگذاری شده است، بنابراین فقط سرور مقصد می‌تواند آن را باز کند.

ارسال AP-REQ به سرور سرویس
کلاینت هنگام درخواست دسترسی به یک سرویس (مانند SMB یا HTTP)، تیکت TGS را به همراه یک Authenticator به سرور مقصد ارسال می‌کند.
این مجموعه به عنوان AP-REQ (Authentication Protocol Request) شناخته می‌شود.

اعتبارسنجی توسط سرور سرویس
سرور سرویس تیکت TGS را رمزگشایی می‌کند و اعتبار کلاینت را بررسی می‌نماید.
در صورت معتبر بودن تیکت و زمان آن، کلاینت احراز هویت شده و به سرویس موردنظر دسترسی می‌یابد.

ساختار AP-REQ

توضیح Authenticator: شامل اطلاعات زمانی و کلید نشست است تا از حملات بازپخش جلوگیری شود.
توضیح Ticket: شامل اطلاعات رمزگذاری‌شده از جمله نام کاربری و مدت اعتبار است.

نقاط ضعف احتمالی

حمله Relay Attack: مهاجمان می‌توانند AP-REQ را رهگیری و به سرور دیگری رله کنند، که یکی از پایه‌های حملات Kerberos Relay مانند حمله KrbRelayEx است.
حمله Pass-the-Ticket (PtT): در این حمله، مهاجم می‌تواند تیکت را سرقت کرده و از آن برای دسترسی غیرمجاز استفاده کند.

به همین دلیل، پروتکل‌های امنیتی مانند SMB Signing و Channel Binding برای کاهش این تهدیدات پیشنهاد می‌شوند.

https://github.com/decoder-it/KrbRelayEx

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

بررسی استفاده از ابزار 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

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

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


بررسی ابزار  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

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

در 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، ارسال ایمیل یا اجرای اسکریپت برای بررسی سیستم را فعال کنید.

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

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

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

در ادامه روش‌های بررسی امضای بسته‌ها در 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

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


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

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

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

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

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

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

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

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

🚨کدام به‌روش ها برای پیاده سازی 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

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

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

اونو ارزیابی کنید
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

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

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

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

💫 مقایسه TLSH و ssdeep در تحلیل بدافزار و فیشینگ

در دنیای امنیت سایبری، شناسایی فایل‌های مخرب و حملات فیشینگ یکی از چالش‌های مهم است. روش‌های سنتی هشینگ مانند MD5 و SHA-256 برای شناسایی دقیق یک فایل خاص مفید هستند، اما در برابر تغییرات جزئی در فایل‌ها کارایی ندارند یعنی هکر با تغییر کوچکی در بدافزار ؛ امضا (هش)آنرا تغییر داده و ما را دور میزند. .
برای حل این مشکل، روش‌های هشینگ فازی مانند TLSH (Trend Locality Sensitive Hashing) و ssdeep توسعه یافته‌اند. این روش‌ها امکان شناسایی شباهت‌های ساختاری بین فایل‌ها را فراهم می‌کنند، حتی اگر تغییراتی در محتوا رخ داده باشد. در این اینجا ، به بررسی این دو روش و کاربردهای آن‌ها در امنیت سایبری می‌پردازم.

🟧معرفی ssdeep

این ssdeep یک ابزار هشینگ فازی است که از Context Triggered Piecewise Hashing (CTPH) استفاده می‌کند. این روش فایل را به بلوک‌های کوچکتر تقسیم کرده و برای هر بلوک یک مقدار هش تولید می‌کند. سپس این هش‌ها ترکیب شده و مقدار نهایی هشینگ فازی را تشکیل می‌دهند. تفاوت اصلی ssdeep با روش‌های هشینگ سنتی این است که امکان مقایسه درصدی دو فایل را فراهم می‌کند، به طوری که فایل‌هایی که تغییرات اندکی دارند، همچنان به عنوان فایل‌های مشابه شناخته می‌شوند.

✔️از جمله کاربردهای ssdeep می‌توان به موارد زیر اشاره کرد:

تحلیل بدافزارها: شناسایی نمونه‌های مشابه از بدافزارها، حتی اگر تغییرات جزئی در آن‌ها ایجاد شده باشد.
تشخیص فیشینگ: مقایسه محتوای HTML سایت‌های فیشینگ برای یافتن الگوهای مشابه.
مدیریت داده‌های بزرگ: شناسایی فایل‌های مشابه در حجم‌های عظیم داده.

با این حال، ssdeep دارای محدودیت‌هایی نیز هست. برای مثال، اگر تغییرات در فایل به صورت پراکنده باشد، دقت شناسایی کاهش می‌یابد.

🔴معرفی TLSH

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

❇️مزایای TLSH عبارتند از:

دقت بالاتر در مقایسه فایل‌ها: برخلاف ssdeep، این روش به تغییرات جزئی حساسیت کمتری دارد.
کارایی بالا در تحلیل بدافزار: قابلیت تشخیص نمونه‌های تغییر یافته از یک بدافزار با دقت بیشتر.
عدم نیاز به اندازه ثابت فایل‌ها: برخلاف ssdeep که به فایل‌های بزرگ وابسته است، TLSH روی فایل‌های کوچک‌تر نیز موثر عمل می‌کند.

یکی از نقاط ضعف TLSH این است که به اندازه ssdeep در تشخیص تغییرات محلی حساس نیست، زیرا تمرکز آن بر ساختار کلی فایل است.


👌به طور کلی، اگر نیاز به تشخیص تغییرات جزئی در یک فایل باشد، ssdeep انتخاب بهتری است. اما اگر هدف، تحلیل ساختاری کلی فایل باشد، TLSH عملکرد بهتری دارد.


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

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

جلوگیری از شناسایی VM هنگام تحلیل بدافزار

بدافزار ها را معمولا در یک vm اجرا می‌کنیم تا رفتار آنرا ببینیم. بدافزارها هم تلاش دارند محیط vm را شناسایی کنند و اقدامات لازم را انجام دهند.
حال ما چه میکنیم ؟
🔆بطور خلاصه یکسری ایده :

✔️استفاده از دیباگر (x64dbg) و تغییر مقدار APIها در حافظه.
✔️ویرایش رجیستری برای حذف نام‌های مربوط به VMware و VirtualBox.
✔️انجام Hook کردن APIها در سطح کد (DLL Injection) برای تغییر مقدار برگشتی.
✔️استفاده از ابزارهای آماده مثل ScyllaHide برای مخفی کردن محیط مجازی.

🔴شرح موضوع

برای جلوگیری از شناسایی محیط مجازی، می‌توانیم APIهایی که بدافزار برای تشخیص VM استفاده می‌کند را Patch کنیم یا مقادیر جعلی برگردانیم. این کار را می‌توان از طریق Hook کردن APIها، ویرایش کد اسمبلی، یا استفاده از ابزارهای آماده انجام داد.
روش ۱: Hook کردن APIها در دیباگر (x64dbg / OllyDbg)
مثال: Patch کردن NtQuerySystemInformation

یکی از رایج‌ترین روش‌های تشخیص VM، استفاده از NtQuerySystemInformation است. این API مقدار SystemFirmwareTableInformation یا SystemManufacturer را بررسی می‌کند. اگر مقادیر مربوط به VMware یا VirtualBox باشند، بدافزار متوجه محیط مجازی خواهد شد.
مراحل Patch کردن در دیباگر (x64dbg)

بدافزار را در x64dbg اجرا کنید.
به منوی Symbols بروید و ntdll.dll را انتخاب کنید.
تابع NtQuerySystemInformation را پیدا کنید.
روی آن Breakpoint (BP) بگذارید تا ببینید چه مقدار برمی‌گرداند.
مقدار برگشتی را با مقدار یک سیستم فیزیکی جایگزین کنید. (مثلاً "DELL" یا "HP" برای سازنده‌ی سیستم)
در اسمبلی، مقدار EAX را به عدد 0 تغییر دهید (که یعنی تابع موفق اجرا شده ولی مقدار VM را برنمی‌گرداند).

mov eax, 0
ret

روش ۲: تغییر مقادیر رجیستری برای جلوگیری از تشخیص VM

اگر بدافزار مستقیماً از رجیستری ویندوز مقدار را می‌خواند، می‌توانیم آن را تغییر دهیم. برخی کلیدهای مهم:
ویرایش مقدار SystemBiosVersion در رجیستری

regedit را باز کنید.
به مسیر زیر بروید:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System

مقدار SystemBiosVersion را تغییر دهید و مثلاً "DELL BIOS" را جایگزین کنید.

حذف اطلاعات مربوط به VMware از رجیستری

به مسیرهای زیر بروید و مقدار آن‌ها را پاک کنید:

HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VBoxGuest

روش ۳: Hook کردن APIها در سطح کد (با DLL Injection)

✴️می‌توان با نوشتن یک DLL و تزریق آن در پروسه‌ی بدافزار، مقدار خروجی API را تغییر داد.
مثال: Hook کردن CPUID برای جلوگیری از شناسایی VMware
۱. کد C++ برای تغییر خروجی CPUID

#include <windows.h>
#include <detours.h>
#include <intrin.h>

typedef void (WINAPI* CPUID_t)(int[4], int);
CPUID_t Real_CPUID = (CPUID_t)__cpuid;

void WINAPI Fake_CPUID(int CPUInfo[4], int InfoType) {
Real_CPUID(CPUInfo, InfoType);

if (InfoType == 0) {
// تغییر مقدار برگشتی برای جلوگیری از شناسایی VM
CPUInfo[1] = 'Genu'; // تغییر به پردازنده Intel
CPUInfo[2] = 'ineI';
CPUInfo[3] = 'ntel';
}
}


void HookAPI() {
DetourTransactionBegin();
DetourUpdateThread(GetCurrentThread());
DetourAttach(&(PVOID&)Real_CPUID, Fake_CPUID);
DetourTransactionCommit();
}

۲. کامپایل کد و تزریق آن در بدافزار

این کد مقدار CPUID را تغییر می‌دهد تا سیستم به‌عنوان Intel واقعی شناسایی شود و نه ماشین مجازی.
برای اجرای آن، باید از DLL Injection استفاده کنید.

روش ۴: استفاده از ابزارهای آماده برای مخفی کردن VM
ScyllaHide (برای دور زدن Anti-Debug و VM Detection)

این ScyllaHide یک پلاگین برای x64dbg است که به‌صورت خودکار مقدار APIها را تغییر می‌دهد تا سیستم، فیزیکی به نظر برسد.
مراحل استفاده از ScyllaHide

پلاگین ScyllaHide را در x64dbg نصب کنید.
به مسیر Plugins > ScyllaHide بروید.
گزینه‌های VM Detection Bypass و Anti-Debug Protection را فعال کنید.
اجرای بدافزار را تست کنید تا ببینید آیا همچنان محیط را به عنوان VM تشخیص می‌دهد یا نه.

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

تکنیک Patch کردن API یعنی چی و چطور انجام می‌شود؟

تکنیکPatch کردن API ؛ یعنی تغییر رفتار یک تابع در حافظه یا کد اجرایی به‌طوری که هنگام اجرای برنامه، تابع مقدار متفاوتی برگرداند یا اصلاً اجرا نشود.
این تکنیک در مهندسی معکوس، تحلیل بدافزار، و دور زدن محدودیت‌های نرم‌افزاری استفاده می‌شود.

روش‌های مختلف Patch کردن API

برای Patch کردن API می‌توان از چندین روش مختلف استفاده کرد:

ویرایش باینری (Binary Patching) در فایل اجرایی

تکنیک Patch کردن در حافظه (Runtime Patching) با دیباگر

انجام Hook کردن API با DLL Injection یا Inline Hooking

۱. ویرایش باینری (Binary Patching) در فایل اجرایی

در این روش، مستقیماً فایل اجرایی (EXE / DLL) را ویرایش می‌کنیم و کد تابع را تغییر می‌دهیم.
مثال: حذف یک شرط در Assembly

فرض کنید یک برنامه این شرط را دارد:

cmp eax, 1 ;
مقدار EAX را با 1 مقایسه می‌کند
jne Exit ;
اگر برابر نبود، به Exit می‌رود

اگر بخواهیم این شرط را حذف کنیم تا برنامه همیشه مقدار موردنظر ما را بپذیرد، می‌توانیم این دو دستور را NOP (No Operation) کنیم:

nop ; هیچ عملی انجام نده
nop ; هیچ عملی انجام نده

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

Hiew → برای ویرایش فایل‌های باینری
IDA Pro / Ghidra → برای مشاهده و تغییر کد اسمبلی
x64dbg / OllyDbg → برای دیباگ و Patch کردن در حافظه

۲. انجامPatch کردن در حافظه (Runtime Patching) با دیباگر

در این روش، برنامه را اجرا می‌کنیم و در لحظه (runtime) کد آن را تغییر می‌دهیم.
مثال: Patch کردن NtQuerySystemInformation در x64dbg

فرض کنید یک بدافزار از این API استفاده می‌کند تا ببیند سیستم داخل VM است یا نه:

call NtQuerySystemInformation
cmp eax, 0x1 ;
اگر مقدار برگشتی ۱ باشد، یعنی سیستم مجازی است
je Exit ;
اگر مقدار ۱ بود، خروج

مراحل انجام کار در x64dbg:

برنامه را در x64dbg اجرا کنید.
به تابع NtQuerySystemInformation بروید.
روی دستور cmp eax, 0x1 Breakpoint بگذارید.
مقدار eax را به ۰ تغییر دهید تا برنامه فکر کند در سیستم واقعی اجرا می‌شود.

mov eax, 0

اجرای برنامه را ادامه دهید.

🔹 نتیجه: بدافزار نمی‌تواند تشخیص دهد که در VM اجرا شده است!
۳. انجام Hook کردن API با DLL Injection یا Inline Hooking

در این روش، یک DLL جدید می‌نویسیم و آن را به برنامه تزریق می‌کنیم تا رفتار یک API را تغییر دهد.
مثال: Hook کردن NtQuerySystemInformation با DLL Injection

کد زیر باعث می‌شود که مقدار برگشتی NtQuerySystemInformation همیشه مقدار جعلی (مثلاً ۰) باشد، بنابراین بدافزار فکر می‌کند در یک سیستم واقعی اجرا شده است.

#include <windows.h>
#include <detours.h>
#include <winternl.h>

typedef NTSTATUS (WINAPI* NtQuerySystemInformation_t)(SYSTEM_INFORMATION_CLASS, PVOID, ULONG, PULONG);
NtQuerySystemInformation_t OriginalNtQuerySystemInformation;

NTSTATUS WINAPI HookedNtQuerySystemInformation(SYSTEM_INFORMATION_CLASS SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength) {
if (SystemInformationClass == SystemManufacturer) {
strcpy((char*)SystemInformation, "DELL");
مقدار جعلی برای سیستم فیزیکی
return 0;
}
return OriginalNtQuerySystemInformation(SystemInformationClass, SystemInformation, SystemInformationLength, ReturnLength);
}

void HookAPI() {
OriginalNtQuerySystemInformation = (NtQuerySystemInformation_t)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtQuerySystemInformation");
DetourTransactionBegin();
DetourUpdateThread(GetCurrentThread());
DetourAttach(&(PVOID&)OriginalNtQuerySystemInformation, HookedNtQuerySystemInformation);
DetourTransactionCommit();
}

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
if (ul_reason_for_call == DLL_PROCESS_ATTACH) {
HookAPI();
}
return TRUE;
}

مراحل اجرای Hook

این کد را کامپایل کنید و یک DLL بسازید.
این DLL را به بدافزار Inject کنید (مثلاً با Process Hacker یا DLL Injector).
حالا API NtQuerySystemInformation مقدار دلخواه شما را برمی‌گرداند.

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

دستگرمی با یادگیری ماشینی
و اسپلانک Machine Learning and splunk

☘️تشخیص حمله با Splunk MLTK

یک بانک متوجه شده است که برخی از سیستم‌های داخلی در حال برقراری ارتباط با یک سرور خارجی مشکوک هستند. رفتار غیرعادی این سیستم‌ها نشان‌دهنده‌ی یک حمله است. تیم امنیتی قصد دارد با استفاده از Splunk Machine Learning Toolkit (MLTK) و SOAR، این نوع حملات را بهتر شناسایی و کنترل کند.

از مدل PCA (Principal Component Analysis) برای تحلیل رفتار نرمال و تشخیص انحرافات استفاده می‌کنیم:
اول
index=network_traffic sourcetype=firewall_logs
| stats count dc(dest_ip) as unique_destinations by src_ip
| where unique_destinations > 50

سیستم‌هایی که با بیش از ۵۰ دامنه‌ی مختلف در مدت کوتاه ارتباط دارند، ممکن است به سرورهای C2 متصل باشند.
این داده‌ها برای یادگیری ماشین آماده می‌شوند.
دوم

| fit PCA unique_destinations into anomaly_model
| where anomaly_model_score > 2.5

مدل PCA داده‌های پرت (Outliers) را که از الگوی عادی انحراف دارند، شناسایی می‌کند.
سیستم‌هایی که امتیاز anomaly_model_score > 2.5 دارند، به‌عنوان ارتباطات مشکوک شناخته می‌شوند.

☘️تطبیق با IOCها و ایجاد هشدار امنیتی

اگر IP مقصد در Indicator of Compromise (IOC) ها موجود باشد، باید به آن وزن بیشتری داده شود:

| lookup ioc_list.csv dest_ip AS suspicious_ip
| eval risk_score = case(anomaly_model_score > 2.5 AND isnotnull(suspicious_ip), 100, anomaly_model_score > 2.5, 80)
| table src_ip, dest_ip, risk_score
| sendalert "notable"

اگر IP مقصد در IOC لیست سیاه باشد، امتیاز ریسک به ۱۰۰ افزایش پیدا می‌کند.
اگر ارتباط فقط از مدل یادگیری ماشین مشکوک باشد، امتیاز ۸۰ دریافت می‌کند.

☘️پاسخ خودکار با Splunk SOAR (Phantom)

با استفاده از Splunk SOAR، اقداماتی خودکار اجرا می‌شود:

مسدود کردن IP مشکوک در فایروال:

phantom.act("block ip", parameters={"ip": suspicious_ip, "device": "firewall"})


🌷نقش یادگیری ماشین در این سناریو و چرایی استفاده از آن

در این سناریو، هدف ما شناسایی ارتباطات مشکوک بین سیستم‌های داخلی بانک و سرورهای خارجی (که احتمالاً سرورهای C2 هستند) است. اما چرا از یادگیری ماشین استفاده کردیم؟
۱. مشکل اصلی: تشخیص ارتباطات غیرعادی در میان حجم بالای ترافیک

در یک سازمان بزرگ، روزانه میلیون‌ها ارتباط شبکه‌ای ثبت می‌شود. تشخیص حملات APT از طریق روش‌های سنتی مانند Signature-based Detection (مبتنی بر قوانین و فیلترها) دشوار است، زیرا:

مهاجمان از IPهای جدید و ناشناخته استفاده می‌کنند که در لیست‌های IOC نیستند.
رفتار C2 ممکن است آهسته و پنهانی باشد (ارتباطات مداوم اما کم‌حجم).
قوانین ثابت (مثل "اگر بیش از ۵۰ ارتباط داشت، هشدار بده") ممکن است False Positive زیادی تولید کند.

یادگیری ماشین کمک می‌کند که رفتار عادی کاربران و سرورها را یاد بگیرد و فقط موارد غیرعادی را علامت‌گذاری کند.
۲. نقش PCA (Principal Component Analysis) در تشخیص ناهنجاری‌ها

ما از PCA (تحلیل مؤلفه‌های اصلی) استفاده کردیم که یک روش یادگیری ماشین برای کاهش ابعاد داده‌ها و کشف نقاط پرت است.
چطور کار می‌کند؟

مدل PCA الگوهای عادی را در ارتباطات کاربران یاد می‌گیرد (مثلاً کاربران معمولاً با چند سرور مشخص کار می‌کنند).
وقتی سیستمی رفتار جدید و غیرعادی از خود نشان دهد (مثلاً تعداد زیادی ارتباط به دامنه‌های ناشناخته)، امتیاز ناهنجاری بالایی می‌گیرد.
سیستم‌هایی که امتیازشان از یک حد خاص عبور کند (anomaly_model_score > 2.5)، به عنوان مشکوک علامت‌گذاری می‌شوند.

🔆 یادگیری ماشین به ما کمک کرد که فقط روی سیستم‌هایی تمرکز کنیم که رفتارشان واقعاً متفاوت از رفتار نرمال است، بدون اینکه هزاران هشدار غلط تولید شود.
۳. ترکیب یادگیری ماشین با IOCها برای دقت بالاتر

برخی ارتباطات ناهنجار ممکن است بی‌خطر باشند (مثلاً یک مهندس شبکه که به سرورهای زیادی متصل می‌شود).
اما اگر یک سیستم هم رفتار غیرعادی داشته باشد و هم به یک IP مشکوک متصل شود، احتمال حمله بسیار زیاد است.
ترکیب این دو (امتیاز PCA + تطبیق با IOCها) باعث شد که فقط موارد مهم با امتیاز ریسک بالا (مثلاً 100) به تیم امنیتی گزارش شود.

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

✅با توجه به پست قبل که در لینکدین منتشر شد دانشجویان از من درمورد مدل‌های یادگیری ماشین در اسپلانک سوال داشتند

۱. مدل‌های تشخیص ناهنجاری (Anomaly Detection)
🔹 Density Function

از توزیع داده‌ها برای شناسایی نقاط پرت (Outliers) استفاده می‌کند.
کاربرد: تشخیص رفتار غیرعادی در ورود کاربران، تشخیص حجم غیرعادی ترافیک شبکه.
مثال: تشخیص افزایش ناگهانی ورود ناموفق به سیستم (Brute Force).
دستور:

| fit DensityFunction count into anomaly_model

🔹 Local Outlier Factor (LOF)

ارتباط هر نقطه داده را با همسایگانش مقایسه می‌کند.
کاربرد: تشخیص حملات سایبری با الگوهای جدید، مثل APT.
دستور:

| fit LOF network_activity into lof_model

🔹 Isolation Forest

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

| fit IsolationForest dest_ip into if_model

۲. مدل‌های پیش‌بینی (Prediction Models)
🔹 Linear Regression

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

| fit LinearRegression count from time into prediction_model

🔹 Random Forest Regressor

از چندین درخت تصمیم (Decision Trees) برای پیش‌بینی استفاده می‌کند.
کاربرد: پیش‌بینی تعداد حملات DDoS در روزهای آینده.
دستور:

| fit RandomForestRegressor error_rate from time into rf_model

۳. مدل‌های دسته‌بندی (Classification Models)
🔹 Decision Tree Classifier

داده‌ها را به گروه‌های مختلف طبقه‌بندی می‌کند.
کاربرد: شناسایی حملات بر اساس نوع (مثلاً Phishing، DDoS، Malware).
دستور:

| fit DecisionTreeClassifier attack_type from features into dt_model

🔹 Support Vector Machine (SVM)

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

| fit SVM email_content into svm_model

🔹 Naïve Bayes Classifier

از احتمالات برای دسته‌بندی داده‌ها استفاده می‌کند.
کاربرد: طبقه‌بندی رویدادهای امنیتی (مثلاً تمایز بین خطای کاربری و حمله).
دستور:

| fit NaiveBayes attack_type from event_logs into nb_model

۴. مدل‌های خوشه‌بندی (Clustering Models)
🔹 K-Means Clustering

داده‌ها را به چند گروه مشابه تقسیم می‌کند.
کاربرد: تشخیص رفتار مشابه بین کاربران مشکوک.
دستور:

| fit KMeans number_of_logins into cluster_model k=3

🔹 DBSCAN (Density-Based Clustering)

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

| fit DBSCAN network_activity into dbscan_model

۵. مدل‌های کاهش ابعاد (Dimensionality Reduction)
🔹 PCA (Principal Component Analysis)

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

| fit PCA network_features into pca_model

جمع‌بندی

✅ اگر دنبال تشخیص ناهنجاری هستیم: Density Function، Isolation Forest، LOF
✅ اگر نیاز به پیش‌بینی روند داریم: Linear Regression، Random Forest
✅ اگر باید داده‌ها را دسته‌بندی کنیم: Decision Tree، SVM، Naïve Bayes
✅ اگر می‌خواهیم خوشه‌های مشکوک را پیدا کنیم: K-Means، DBSCAN

پی نوشت : این مدلها از حوزه یادگیری ماشین زیر مجموعه هوش مصنوعی هستند
درصورت علاقه به یادگیری خود مدل ؛ باید به کتاب‌های هوش مصنوعی مراجعه کرد

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

شناسایی حمله باج‌افزاری (Ransomware) با Splunk و یادگیری ماشین (AI)

حمله باج‌افزاری معمولاً در چند مرحله اجرا می‌شود و یادگیری ماشین و هوش مصنوعی می‌تواند در شناسایی آن از طریق تحلیل رفتار فایل‌ها، پردازش‌ها و ارتباطات شبکه‌ای کمک کند.
در اینجا یک سناریو از کشف باج‌افزار با استفاده از Splunk Machine Learning Toolkit (MLTK) ارائه شده است.

🔹 مراحل اجرای یک حمله باج‌افزاری

۱. دسترسی اولیه (Initial Access)

مهاجم از یکی از روش‌های زیر استفاده می‌کند:

فیشینگ (Phishing)
اکسپلویت آسیب‌پذیری‌ها (مثلاً RDP یا SMB باز)
حمله بروت فورس برای ورود به سیستم

✅ منبع داده‌ای: SIEM Logs، Email Logs، Authentication Logs
✅ مدل تشخیصی: Naïve Bayes (برای شناسایی ایمیل فیشینگ)
۲. اجرای بدافزار (Execution)

باج‌افزار معمولاً یک پردازش جدید و غیرمعمول روی سیستم اجرا می‌کند. این پردازش ممکن است دارای مشخصات زیر باشد:

اجرای پردازش جدید از پوشه Temp یا AppData
اجرای اسکریپت‌های PowerShell مشکوک
ایجاد پردازش‌های فرزند (مثلاً parent process = powershell.exe)

✅ منبع داده‌ای: Sysmon Logs، EDR Logs
✅ مدل تشخیصی: Decision Tree (برای شناسایی فرآیندهای مشکوک)

🔹 جستجوی پیشنهادی در Splunk برای پردازش‌های مشکوک:

index=endpoint_logs sourcetype=sysmon
| stats count by process_name, parent_process
| where parent_process="powershell.exe" AND count > 3
| fit DecisionTreeClassifier malware_flag from process_name into ransomware_exec_model

۳. رمزگذاری فایل‌ها (Encryption Phase)

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

افزایش ناگهانی تغییرات در فایل‌ها
تغییر پسوند فایل‌ها به مقدار غیرعادی (مثلاً .lock، .encrypted)
حذف فایل‌های بکاپ (Volume Shadow Copies)

✅ منبع داده‌ای: File System Logs (Windows Security Logs, Sysmon Event ID 4663)
✅ مدل تشخیصی: Density Function (برای تشخیص رفتار غیرعادی فایل‌ها)

🔹 جستجوی پیشنهادی در Splunk برای شناسایی تغییرات غیرعادی فایل‌ها:

index=file_logs sourcetype=sysmon event_id=4663
| stats count by file_path, action
| where action="write" AND count > 100
| fit DensityFunction count into ransomware_file_model

۴. برقراری ارتباط با سرور فرماندهی و کنترل (C2 Communication)

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

ارتباط با دامنه‌های تازه ثبت‌شده (Newly Registered Domains)
استفاده از پروتکل‌های غیرمعمول (مثلاً DNS tunneling)
ارتباط با IPهای شناخته‌شده در تهدیدات سایبری

✅ منبع داده‌ای: Firewall Logs، DNS Logs، Threat Intelligence Feeds
✅ مدل تشخیصی: Isolation Forest (برای تشخیص ارتباطات غیرعادی)

🔹 جستجوی پیشنهادی در Splunk برای شناسایی ارتباط با C2:

index=network_traffic sourcetype=firewall_logs
| stats count by dest_ip, protocol
| where protocol IN ("dns", "http", "https")
| fit IsolationForest count into ransomware_c2_model
| where ransomware_c2_model_score > 2.5

۵. درخواست باج (Ransom Demand)

ایجاد یک فایل متنی روی دسکتاپ کاربر (README.txt)
نمایش یک پیام در صفحه (Popup یا Wallpaper تغییر یافته)

✅ منبع داده‌ای: Endpoint Logs، Windows Event Logs
✅ مدل تشخیصی: K-Means Clustering (برای تحلیل الگوهای مشترک باج‌افزارها)

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

🥇سناریوی امشب : کشف نفوذ آرام با ماندگاری طولانی

✅یک سناریوی پیچیده و جذاب برای کشف نفوذ با کمک از Splunk براتون آماده کردم که ترکیبی از تکنیک‌های فرار از شناسایی (Evasion)، حرکت جانبی (Lateral Movement) و دسترسی مداوم (Persistence) است.

🟧یک مهاجم موفق شده است از طریق یک حمله فیشینگ هوشمند و اجرای ماکرو مخرب در Excel، کنترل اولیه را روی یک سیستم کاربر در شبکه به دست بگیرد. سپس با استفاده از Cobalt Strike و تکنیک‌های Living off the Land (LOLBins)، در شبکه حرکت جانبی انجام داده و یک حساب کاربری جعلی در اکتیو دایرکتوری ایجاد می‌کند تا دسترسی دائمی داشته باشد.

🔰جزئیات حمله:

✔️ دریافت شل اولیه:
حمله فیشینگ با ارسال یک فایل Excel حاوی ماکروی مخرب به کاربر.
اجرای ماکرو باعث دانلود و اجرای یک PowerShell reverse shell می‌شود که به یک C2 Server متصل است.
ارتباط به‌صورت Encoded PowerShell ارسال می‌شود تا از SIEM و آنتی‌ویروس فرار کند.

✔️ حرکت جانبی و افزایش دسترسی:
مهاجم از Mimikatz برای استخراج کردنشیال‌های ذخیره‌شده استفاده می‌کند.
از طریق Pass-the-Hash (PtH) به یک سرور داخلی متصل می‌شود.
با استفاده از PsExec یا WMI روی یک سیستم دیگر کد اجرا می‌کند.

استفاده از ابزارهای ذاتی ویندوز (LOLBins) برای فرار از شناسایی:
اجرای کدهای مخرب با MSBuild.exe و CertUtil.exe برای دور زدن ابزارهای امنیتی.
استفاده از Rundll32.exe برای اجرای فایل DLL مخرب بدون ایجاد پروسس جدید مشکوک.

✔️ ماندگاری و دسترسی مداوم:
ایجاد یک حساب جعلی در Active Directory با نامی شبیه به ادمین‌های واقعی.
تنظیم یک Scheduled Task که در هر ریبوت، یک ریکانکت به C2 برقرار می‌کند.
ذخیره Web Shell در IIS روی یک سرور حساس برای دسترسی آینده.



🔮 بررسی کامل و انجام تحلیل در Splunk:

بحث کامل تحلیل و حل مساله را در پست های آینده بخوانید

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

مکانیسم های حضور دائمی هکر در لینوکس
فارسی از جناب ملکی
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

بررسی فعالیت های مخرب روی لینوکس
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

تحلیل سناریوی فوق در Splunk:

۱. کشف ارتباط اولیه (PowerShell Reverse Shell)

جستجوی دستورات مشکوک در لاگ‌های PowerShell که ممکن است ارتباط C2 برقرار کند:

index=windows EventCode=4104 ScriptBlockText="*IEX*(New-Object Net.WebClient).DownloadString*" 

یا استفاده از Base64 encoded PowerShell:

index=windows EventCode=4104 ScriptBlockText="*FromBase64String*" 

۲. کشف حرکت جانبی (Mimikatz و Pass-the-Hash)

index=windows EventCode=4624 LogonType=9 OR LogonType=3 Account_Name!=”Administrator” Account_Name!=”Service” 

    Logon Type 9: نشان‌دهنده استفاده از مکانیزم‌های احراز هویت غیرمعمول است.
    Logon Type 3: اتصال از راه دور، اما بدون نام کاربری ادمین، که مشکوک است.

۳. کشف اجرای ابزارهای LOLBins (مانند MSBuild و CertUtil)

index=windows EventCode=4688 New_Process_Name="*MSBuild.exe" OR New_Process_Name="*CertUtil.exe" 

این پردازش‌ها معمولاً در شبکه سازمانی استفاده نمی‌شوند، مگر در شرایط خاص.
۴. کشف ماندگاری (Scheduled Task و Web Shell در IIS)

index=windows EventCode=4698 OR EventCode=4700 Task_Name="*Update*" 

    بسیاری از مهاجمان برای فرار از شناسایی، نام‌های مشابه آپدیت‌های ویندوز برای Scheduled Task می‌گذارند.

و برای کشف Web Shell در IIS:

index=webserver sourcetype="iis" cs_uri_stem="*.asp" OR cs_uri_stem="*.aspx" cs_method="POST" 

    درخواست‌های POST غیرعادی به صفحات ASPX ممکن است نشان‌دهنده یک Web Shell باشد.

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer

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

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

🤡پرچم ترپ (Trap Flag) چیست؟

این Trap Flag (TF) یک پرچم خاص در رجیستر EFLAGS در معماری پردازنده‌های x86 است که برای فعال کردن Single-Stepping یا گام‌به‌گام اجرا کردن دستورات برنامه به کار می‌رود. هنگامی که دیباگر به‌طور گام به گام یک برنامه را تحلیل می‌کند، این پرچم در رجیستر EFLAGS تنظیم می‌شود تا پس از اجرای هر دستور، پردازنده یک Interrupt 1 (خطای دیباگ) ایجاد کند و کنترل را به دیباگر بازگرداند.

این ویژگی به دیباگر اجازه می‌دهد تا بتواند پس از اجرای هر دستور، وضعیت حافظه و مقادیر رجیسترها را بررسی کرده و تغییرات آن‌ها را نظارت کند. بنابراین، Trap Flag یک ابزار بسیار مفید برای تحلیل و بررسی دقیق عملکرد برنامه‌ها در سطح اسمبلی است.

👻چالش‌های شناسایی Trap Flag:

هرچند استفاده از Trap Flag برای گام به گام اجرا کردن برنامه بسیار مفید است، اما شناسایی و تشخیص آن از بیرون (یعنی توسط خود برنامه یا ابزارهای شناسایی بدافزار) کار دشواری است. دلایل این مشکل عبارتند از:

✔️این EFLAGS به‌طور مستقیم قابل خواندن نیست:
این EFLAGS که شامل Trap Flag می‌باشد، به‌طور مستقیم از طریق دستوراتی مانند mov قابل خواندن نیست. برای خواندن وضعیت این رجیستر باید از دستور pushf استفاده کرد، که وضعیت EFLAGS را در استک ذخیره می‌کند.

✔️پرچم Trap Flag به‌طور خودکار غیرفعال می‌شود:
پس از هر بار برگشت از دیباگر، Trap Flag به‌طور خودکار به حالت False (غیرفعال) تغییر می‌کند. این ویژگی باعث می‌شود که بررسی وضعیت این پرچم برای شناسایی نقاط توقف در برنامه سخت باشد.

👽روش‌های شناسایی رفتار دیباگینگ با استفاده از Trap Flag:

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

✔️ بررسی استک با استفاده از دستور pushf:
همانطور که اشاره شد، تنها راه دسترسی به وضعیت EFLAGS استفاده از دستور pushf است که وضعیت EFLAGS را در استک ذخیره می‌کند. بدافزار می‌تواند به‌طور پیوسته وضعیت استک را بررسی کرده و در صورتی که تغییرات غیرمنتظره‌ای در آن مشاهده شود، به وجود یک دیباگر مشکوک شود.

✔️ تحلیل زمان‌بندی دستورات:
اجرای گام به گام دستورات توسط دیباگر باعث تغییرات در زمان‌بندی اجرای دستورات می‌شود. این زمان‌بندی ممکن است برای برنامه قابل شناسایی باشد. به‌عنوان مثال، اگر برنامه بین هر دستور وقفه‌های کوچکی داشته باشد (که ناشی از فعال بودن Trap Flag است)، این تفاوت‌ها می‌توانند به‌عنوان علائم رفتاری دیباگر شناسایی شوند.

🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer