🛡️ PERSISTENCE SERIES | PART 1
خب Persistence یعنی چی؟

فرض کنید مهاجم بعد از Initial Access تونسته وارد یک سیستم بشه.

خب، حالا اگر سیستم Reboot بشه چی؟

اگر Session بسته بشه؟

اگر Process مربوط به دسترسی از بین بره؟

اینجاست که Persistence اهمیت پیدا میکنه.

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

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

مثل:

🔹 Registry Run Keys
🔹 Scheduled Tasks
🔹 Windows Services
🔹 WMI Event Subscriptions

اما یک نکته مهم وجود داره:

ا Persistence همیشه یک فایل عجیب‌وغریب یا یک رفتار کاملاً مشخص نیست.

گاهی یک Configuration، یک Task یا حتی یک Service میتونه کاملاً عادی به نظر برسه.

چیزی که اون رو مشکوک میکنه، معمولاً Context و رفتاریه که در اطرافش اتفاق می‌ افته.

⚠️ این مطالب صرفاً برای آموزش و Authorized Security Assessments است.
1/2
@TryHackBox
#TryHackBox #CyberSecurity #Persistence #RedTeam #WindowsSecurity

❗️ تخفیف ویژه ❗️

📚 کتابچه "Mimikatz: تسلط عملی بر تکنیک‌های پیشرفته حملات Active Directory" از مقدماتی تا پیشرفته.

📕 جزئیات بیشتر کتاب


💰 قیمت : ۲۵۰,۰۰۰ تومان
💰 تخفیف : ۱۹۰,۰۰۰ تومان


📖 وایرشارک برای ردتیمرها: از پایه تا پیشرفته

📕 جزئیات بیشتر کتاب

💰 قیمت : ۲۵۰,۰۰۰ تومان
💰 تخفیف : ۱۸۰,۰۰۰ تومان

📖 شکار عملی باگ بانتی : از Recon تا Bounty واقعی : متدولوژی و شناسایی و آسیب پذیری های دنیای واقعی

📕 جزئیات بیشتر کتاب

💰 قیمت : ۳۶۰,۰۰۰ تومان
💰تخفیف : ۲۸۰,۰۰۰ تومان


‼️ مهلت تخفیف کتابها : 3 روز

📌 دوره: راهنمای جامع ابزار Mimikatz
توضیحات
◽️مدرس : مهندس سجاد تیموری
◽️مدت زمان دوره : ۵ ساعت ۲۰ دقیقه
◻️ دوره : آفلاین
⭕️ دوره دارای گروه پشتیبانی می باشد.

💰 قیمت :     ۲,۰۰۰,۰۰۰  تومان
💰 با تخفیف ویژه : ۱,۲۵۰,۰۰۰ تومان

📌 جهت خرید،به ایدی زیر پیام دهید:
@ThbxSupport

📌 PERSISTENCE SERIES | PART 2


🛡️ Registry Run Keys

یکی از مسیرهای Persistence در ویندوز
فرض کنید در یک Security Assessment متوجه میشید بعد از Login، یک برنامه خاص به‌صورت خودکار اجرا میشه.
یکی از جاهایی که ارزش بررسی داره، Registry Run Keys هست.
بعضی از Registry Keyها میتونن باعث اجرای خودکار یک برنامه هنگام ورود کاربر به ویندوز بشن. به همین دلیل، اگر یک Entry ناشناس یا غیرمنتظره ببینیم، نمیتونیم به‌سادگی از کنارش رد بشیم.

اما یک نکته مهم:

هر Entry ناشناسی لزوماً Malicious نیست.
برای اینکه بفهمیم واقعاً با یک رفتار مشکوک طرف هستیم یا نه، باید چند سرنخ رو کنار هم بذاریم:

🔹 چه برنامه‌ای اجرا میشه؟
🔹 فایل دقیقاً کجا قرار داره؟
🔹 چه Userای اون رو ایجاد کرده؟
🔹 چه زمانی ایجاد شده؟
🔹 فایل Digital Signature داره؟
🔹 رفتارش با فعالیت عادی سیستم همخوانی داره؟

یک Defender معمولاً فقط خود Registry Entry رو نگاه نمیکنه؛ بلکه اون رو در کنار Processها، Eventها و سایر شواهد Endpoint بررسی میکنه.


1/2
@TryHackBox
#CyberSecurity #Persistence #Windows #Registry #RedTeam

🔖 دوره : تسلط بر نگارش گزارش های تست نفوذ و ردتیم

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

آنچه خواهید آموخت

▫️نوشتن گزارش‌ های حرفه‌ای تست نفوذ که باعث بهبود امنیت شوند
◾️تدوین خلاصه‌ های اجرایی جذاب که با مخاطبان C-level (مدیران ارشد) همخوانی داشته باشد
▫️مستندسازی عملیات ردتیم با گزارش‌نویسی مبتنی بر روایت
◾️بهره‌گیری از مدل‌های زبانی بزرگ (مانند Claude، ChatGPT و غیره) برای تسریع و ارتقای کیفیت گزارش‌نویسی
▫️ساخت گزارش‌ نویسی خودکار که ساعت‌ ها زمان در هر پروژه صرفه‌ جویی کند
▪️ ایجاد قالب‌ های قابل استفاده مجدد، پایگاه داده یافته‌ها و جریان‌ های کاری تیمی

@TryHackBox

وقتی Windows Event Log تبدیل به منبع Recon میشه

معمولاً وقتی اسم Windows Event Log میاد، یاد Detection و Incident Response می‌ افتیم.

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

مثلاً بعضی Eventها اطلاعاتی درباره User، IP و زمان Login در اختیار میذارن.

یکی از Logهایی که ارزش بررسی داره:

Microsoft-Windows-TerminalServices-LocalSessionManager/Operational

برای مثال می‌شه Event ID 21 رو بررسی کرد:

Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational' | Where-Object {$_.Id -eq 21} 

چیزی که مهاجم ممکنه از این اطلاعات بسازه:

User → IP → Login Time

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

🔎 از دید Detection

اجرای PowerShell برای خواندن Event Logهای مرتبط با Terminal Services میتونه ارزش بررسی داشته باشه.

مثلاً:

powershell.exe + Get-WinEvent + TerminalServices-LocalSessionMaager

البته این الگو به‌ تنهایی به معنی حمله نیست.
ا Context همیشه مهمه.

🎯 ذهنیت ردتیمر

مهاجم همیشه دنبال Exploit جدید نیست.
گاهی بهترین اطلاعات، جاییه که همه فکر میکنن فقط برای Logging ساخته شده.

Logs → Information → Context → Intelligence

پس یک سؤال ساده از خودت بپرس:

اگر من مهاجم بودم، از همین Logهای موجود چه چیزی میتوانستم بفهمم؟


@TryHackBox
#امنیت_سایبری #ردتیم #بلو_تیم #پاورشل #ویندوز #ThreatHunting #DFIR #SIEM #EDR #ThreatDetection

وقتی یک Chrome Extension روی سیستم نصب میشه، فایل‌ ها و منابع اون به‌صورت Local در دسترس قرار میگیرن. همین موضوع باعث میشه در یک Authorized Security Assessment امکان بررسی ساختار، Source Code و رفتار Extension وجود داشته باشه.

گاهی داخل همین فایل‌ ها میشه چیزهای جالبی پیدا کرد؛ مثلاً:

🔹 API Key
🔹 Token
🔹 Endpointهای داخلی
🔹 اطلاعات حساس
🔹 Permissionهای غیرضروری
🔹 ضعف‌ های موجود در منطق Extension


اما نکته مهم اینجاست:

صرفاً پیدا کردن یک API Key یا Token به معنی وجود آسیب پذیری نیست.

باید ببینیم این اطلاعات دقیقاً چه سطحی از دسترسی ایجاد میکنن و آیا واقعاً قابل سوءاستفاده هستن یا نه.

🔎 حتی برای پیدا کردن Extensionهای مرتبط با یک شرکت مشخص، میشه از Google Dork استفاده کرد.

مثلاً:

site:chromewebstore.google.com "nasa.gov"

کافیه nasa.gov رو با Domain موردنظر جایگزین کنید.

بعد از پیدا کردن Extension، مرحله جالب‌تر شروع میشه:

Source Code → Permissions → Endpoints → Secrets → Impac

t

🎯 ذهنیت باگ هانتر

به‌ جای اینکه فقط بپرسیم:
«چه چیزی پیدا کردم؟»
باید بپرسیم:

واقعاً با این چیزی که پیدا کردم، چه کاری میتونم انجام بدم

همین تغییر نگاه، یک Recon ساده رو به مسیر واقعی Vulnerability Discovery تبدیل می‌کنه.

💬 حالا سؤال:

اگر در Source Code یک Chrome Extension به یک API Key یا Token برخورد کنید، اولین چیزی که بررسی میکنید چیه؟

🔹 API Key
🔹 Endpoint
🔹 Permissions
🔹 Token Usage

انتخابتون رو بنویسید و بگید چرا. 👇

@TryHackBox

#باگ_بانتی #امنیت_سایبری #نکات_باگ_بانتی #امنیت_وب #امنیت_اپلیکیشن #تست_نفوذ #امنیت_اطلاعات

🎯 Bug Bounty Lab
یک Workspace جامع برای باگ بانتی

اگر در حوزه باگ بانتی فعالیت میکنید، مدیریت Scope، Recon، ابزارها، یافته‌ ها و گزارش‌ ها میتواند به‌ مرور زمان پیچیده و پراکنده شود.

باگ بانتی Lab یک پروژه متن‌ باز است که با هدف ایجاد یک Workspace یکپارچه برای مدیریت فرآیند باگ بانتی توسعه داده شده و بخش‌ های مختلف این فرآیند را در یک محیط واحد ترکیب میکند.

🔍 برخی از قابلیت‌ های پروژه:

• مدیریت و بررسی Scope

ا• Workflow از Recon تا Vulnerability Discovery و Reporting

• 🤖 قابلیت‌های AI-assisted برای فرآیند تحقیق

• 🧰 دسترسی به بیش از ۴۰۰ ابزار امنیتی و Recon

ا• 📝 Templateهای گزارش‌ نویسی با ساختار مشابه HackerOne

• 🖥️ لابراتوار محلی برای تمرین و یادگیری
• ⚡ ابزارهای Automated Recon و Enumeration

• 📚 منابع آموزشی و راهنماهای Methodology

🔗 GitHub:

https://github.com/DevCop95/bugbounty-lab101

اگر در زمینه باگ بانتی، امنیت وب یا Security Research فعالیت میکنید، بررسی این پروژه میتواند جالب باشد.

@TryHackBox
#باگ_بانتی

📌 SAML SECURITY SERIES | PART 01

اSAML؛ وقتی یک Login ساده، پای XML وسط می آید!

اگر تا حالا با SSO کار کرده باشید، احتمالاً اسم SAML به گوشتون خورده.

اSAML یا Security Assertion Markup Language یکی از فناوری‌ هایی هست که برای Authentication و پیاده‌ سازی SSO استفاده میشه.

اما یک نکته جالب وجود داره:

اSAML به‌شدت به XML وابسته است؛ و همین XML میتونه بخشی از سطح حمله رو تشکیل بده.

در یک SAML Implementation، مشکلات مختلفی ممکنه به وجود بیان؛ از اشتباه در بررسی Signature گرفته تا Replay شدن Assertion یا حتی مشکلات مربوط به XML Processing.

چند مورد مهمی که باید بشناسیم:

🔹 Signature Wrapping (XSW)
🔹 XML Attacks
🔹 SAML Message Integrity Abuse
🔹 Missing / Invalid Signature
🔹 SAML Message Replay
🔹 CSRF
🔹 XML Comment Handling
🔹 XSLT
🔹 Token Recipient Confusion

اما قرار نیست همه اینها رو یکجا بررسی کنیم.

در این سری، یکی‌ یکی سراغشون میریم و از دید یک Security Tester بررسی میکنیم که هرکدوم چه مفهومی دارن و چرا باید موقع بررسی SAML بهشون توجه کرد.

🎯 یک سؤال برای شروع:

اگر بخواید یک SAML Implementation رو بررسی کنید، حدس می‌ زنید اولین چیزی که ارزش بررسی داره کدومه؟

Signature؟
XML Processing؟
Replay؟
یا ‌....؟

دلیل انتخابتون رو هم بنویسید. 👇



@TRYHACKBOX
#امنیت_سایبری #تست_نفوذ

🔍 Enum Subdomain از Wayback با Bash

می‌خوای subdomainهای پنهان archived در طول زمان رو کشف کنی؟ این function bash مفید subdomainها رو از Wayback Machine میکشه و به recon عمیق کمک میکنه.

➕ این رو به ~/.bashrcت اضافه کن:

function wayback() {
  curl -sk "http://web.archive.org/cdx/search/cdx?url=*.$1&output=txt&fl=original&collapse=urlkey&page=" | awk -F/ '{gsub(/:.*/, "", $3); print $3}' | sort -u
}

🧪 استفاده:

wayback target.com

این subdomainها رو از URLهای archived فیلتر میکنه و unique سورت میکنه.

کدوم subdomain قدیمی رو با wayback function شکار کردی که vuln جدیدی باز کرد؟ تجربت رو کامنت کن،

@TryHackBox
#باگ_بانتی

🔖 پیدا کردن اطلاعات حساس با gf

# Search for testing point with gau and fff
gau target -subs | cut -d"?" -f1 | grep -E "\.js+(?:on|)$" | tee urls.txt
sort -u urls.txt | fff -s 200 -o out/

# After we save responses from known URLs, it's time to dig for secrets
for i in gf -list; do [[ ${i} =~ "_secrets"* ]] && gf ${i}; done

کدوم secret با gf در JS فایل‌ها شکار کردین که bounty داد؟ تجربتون رو کامنت کنی

@TryHackBox
#باگ_بانتی

🛡️ SAML SECURITY SERIES | PART 02

🎫 Signature Wrapping
وقتی Signature معتبره، ولی Application چیز دیگه‌ای رو میخونه!

در قسمت قبل گفتیم یکی از اولین چیزهایی که در بررسی یک SAML Implementation باید بهش توجه کنیم، Signature Validation هست.

حالا بریم سراغ یکی از معروف‌ ترین مشکلات امنیتی SAML:

XML Signature Wrapping یا XSW

اسمش شاید کمی پیچیده به نظر برسه، ولی ایده‌ی اصلیش خیلی ساده‌ تره.
فرض کنید یک SAML Response داریم.
داخل این Response یک Assertion وجود داره.
روی این Assertion هم یک Digital Signature قرار گرفته.

اپلیکشن باید مطمئن بشه که:
ا🔐 Signature واقعاً معتبره.
📄 داده‌ای که Signature روی اون قرار گرفته، همون داده‌ایه که باید بررسی بشه.

📌 در نهایت، همون Assertion وارد فرآیند Authentication میشه.

حالا مشکل کجاست؟
وقتی بین چیزی که Signature شده و چیزی که Application پردازش میکنه ارتباط درستی وجود نداشته باشه.

در بعضی پیاده‌سازی‌ های آسیب‌پذیر، مهاجم میتونه ساختار XML رو طوری تغییر بده که Signature همچنان معتبر باقی بمونه.
اما Application در ادامه، Node یا Assertion دیگری رو پردازش کنه.

یعنی:
اSignature معتبره.

اما چیزی که Application بهش اعتماد میکنه، لزوماً همون چیزی نیست که Signature شده.
به زبان ساده تر هم که :

Signed Data ≠ Processed Data

و دقیقاً همینجا مشکل امنیتی شکل میگیره.
بسته به Implementation و شرایط موجود، این مسئله میتونه به موارد زیر منجر بشه:

🔹 Authentication Abuse
🔹 Privilege Escalation
🔹 Identity Validation Bypass

اما یک نکته مهم دیگه هم وجود داره.

اXSW فقط یک تکنیک واحد نیست.
برای این حمله Variantهای مختلفی وجود داره که معمولاً با نام‌ های XSW1 تا XSW8 شناخته میشن.

تفاوت این Variantها عمدتاً به نحوه‌ی قرار گرفتن و پردازش Nodeهای XML مربوط میشه.

🎯 حالا سؤال:

اگر یک SAML Response داشته باشیم و Signature اون کاملاً معتبر باشه، آیا میتونیم با اطمینان بگیم Authentication امنه؟

یا باید بررسی کنیم که:
اپلیکشن دقیقاً کدوم Node رو بعد از Validation پردازش میکنه؟

اگر جای یک پنتستر بودید، چطور مطمئن می‌شدید:

اSigned Data همون Processed Data هست؟

نظرتون رو بنویسید 👇

@TryHackBox
#تست_نفوذ #امنیت_سایبری

🌐 Web Pentesting | Field Notes - #01

قبل از اینکه Payload بفرستی، اول ببین اصلاً کجا باید بفرستی.

یکی از رایج‌ ترین اشتباهات پنتسترهای تازه‌کار اینه که خیلی زود میپرن سراغ SQLi، XSS، یا اجرای یک Automated Scanner. اما یک پنتستر باتجربه، قبل از هر چیز، یک سؤال ساده‌تر از خودش میپرسه:

"این اپلیکیشن کجا به من اجازه میده روی رفتار سرور اثر بذارم؟"

در یک Assessment واقعی، صرفاً به فرم لاگین بسنده نکن. دنبال این‌ها بگرد:

URL / Query Parameters
JSON Body
Headers و Cookies
File Upload
Search و Filters
Export / Download
Password Reset
API Endpoints
Admin Functions
Redirect Parameters

یک مثال ساده:

Code
GET /profile?id=123

برای یک پنتستر، این فقط یک URL نیست. id=123 یعنی احتمالاً یک Object در سمت سرور وجود داره که براساس یک Identifier پیدا میشه.

حالا سؤال اصلی اینه: سرور فقط میپرسه "چه Objectی درخواست شده؟"، یا واقعا چک میکنه "آیا این کاربر مجاز به دیدن این Object هست؟"

همین تفاوت ظریف، میتونه یک تست ساده رو به کشف یک IDOR واقعی تبدیل کنه.

🎯 طرز فکر یک پنتستر:

Input → Processing → Authorization → Output → Impact

@TryHackBox

#تست_نفوذ #امنیت_سایبری