thb-ctf-02-trustpay-player.zip
28.3 KB
🔐 THB CTF Team Qualification : Challenge #02 - Race Against Trust
دسته: Web Pentesting / Business Logic
سطح سختی: Hard
پروژه: TCTQ مسیر پذیرش تیم CTF TryHackBox
📖 سناریو
اTrustPay یه پلتفرم پرداخت داخلیه که تو کل شرکت برای صدور Invoice و انتقال وجه بین بخشها استفاده میشه. کارمندها میتونن Invoiceهاشون رو ببینن، مرجع صورتحساب رو جستجو کنن، و موجودی حسابشون رو پیگیری کنن.
شما بهعنوان یه پنتستر خارجی استخدام شدید. یه اکانت کارمند عادی بسازید و ببینید یه کاربر معمولی تا کجا میتونه پیش بره.
🎯 هدف: دسترسی به پنل Treasury و گرفتن Flag.
هیچ آسیبپذیری به تنهایی شما رو به هدف نمیرسونه. این چالش نیاز به زنجیرهکردن چند تا ضعف داره، فهمیدن اینکه چرا هر مرحله بهتنهایی کافی نیست.
⚙️ نحوه اجرا
یا
اپلیکیشن روی آدرس زیر بالا میاد:
فرمت فلگ :
THB{ }
ارسال فلگ :
@Unique_exploitbot
قوانین و توضیحات تکمیلی
@TryHackBox
#CTF_THB
دسته: Web Pentesting / Business Logic
سطح سختی: Hard
پروژه: TCTQ مسیر پذیرش تیم CTF TryHackBox
📖 سناریو
اTrustPay یه پلتفرم پرداخت داخلیه که تو کل شرکت برای صدور Invoice و انتقال وجه بین بخشها استفاده میشه. کارمندها میتونن Invoiceهاشون رو ببینن، مرجع صورتحساب رو جستجو کنن، و موجودی حسابشون رو پیگیری کنن.
شما بهعنوان یه پنتستر خارجی استخدام شدید. یه اکانت کارمند عادی بسازید و ببینید یه کاربر معمولی تا کجا میتونه پیش بره.
🎯 هدف: دسترسی به پنل Treasury و گرفتن Flag.
هیچ آسیبپذیری به تنهایی شما رو به هدف نمیرسونه. این چالش نیاز به زنجیرهکردن چند تا ضعف داره، فهمیدن اینکه چرا هر مرحله بهتنهایی کافی نیست.
⚙️ نحوه اجرا
docker compose up --build
یا
./start.sh
اپلیکیشن روی آدرس زیر بالا میاد:
http://localhost:8002
فرمت فلگ :
THB{ }
ارسال فلگ :
@Unique_exploitbot
قوانین و توضیحات تکمیلی
@TryHackBox
#CTF_THB
👍3
Try Hack Box
🌐 Web Pentesting | Field Notes - #02 SQL Injection را با SQLmap شروع نکنید یکی از رایج ترین اشتباهها در تست نفوذ وب این است که پنتستر به یک پارامتر میرسد و بلافاصله ابزار را اجرا می کند؛ منتظر میماند تا SQLmap اعلام کند «Vulnerable». پیش از آنکه حتی…
🧨 WEB PENTESTING FIELD NOTES #03
یک اشتباه رایج در تست XSS
یه چیزی توی Search Box وارد میکنی.
بر میگرده توی صفحه.
بعد اولین فکری که میاد:
«خب، حالا یه Payload بزنیم ببینیم اجرا میشه یا نه.»
اینجا دقیقاً جاییه که خیلی از تست ها اشتباه شروع میشن.
قبل از Payload، من معمولاً یه سؤال سادهتر میپرسم:
این Input دقیقاً کجا قرار گرفته؟
داخل HTML؟
داخل یک Attribute؟
داخل JavaScript؟
توی URL؟
یا اصلاً JavaScript سمت Client داره این مقدار رو از جایی میخونه و وارد DOM میکنه؟
چون این:
<input>
به تنهایی چیزی بهت نمیگه.
مهم اینه که Application و Browser باهاش چه رفتاری میکنن.
یه سناریوی ساده:
تو Search میزنی:
THB
صفحه هم نشون میده:
Search results for: THB
خوبه.
حالا به جای اینکه سریع بری سراغ Payloadهای مختلف، مسیر مقدار رو دنبال کن.
Input → Source → Data Flow → Sink → Context → Execution
اگر بفهمی داده از کجا وارد شده و نهایتاً به کجا رسیده، تازه می فهمی باید دنبال چه چیزی بگردی.
حالا سه حالت اصلی XSS رو از هم جدا کن:
🔹 Reflected XSS
اInput از Request میاد و در Response برمیگرده.
🔹 Stored XSS
اInput ذخیره میشه و بعداً وقتی یک User دیگه صفحه رو میبینه، Render میشه.
🔹 DOM-Based XSS
این یکی جالب تره.
ممکنه Server اصلاً چیزی از Payload نبینه.
جاوااسکریپت سمت Client داده رو از یک Source میگیره و به یک Sink خطرناک میرسونه.
یعنی اگر فقط Responseهای Server رو نگاه کنی، ممکنه کل داستان رو از دست بدی.
حالا یه سؤال برای خودت:
فرض کن مقدار زیر رو وارد کردی:
THB123
و این مقدار داخل HTML صفحه ظاهر شد.
آیا همین به معنی XSS Vulnerability هست؟
@TryHackBox
#تست_نفوذ #امنیت_سایبری
یک اشتباه رایج در تست XSS
یه چیزی توی Search Box وارد میکنی.
بر میگرده توی صفحه.
بعد اولین فکری که میاد:
«خب، حالا یه Payload بزنیم ببینیم اجرا میشه یا نه.»
اینجا دقیقاً جاییه که خیلی از تست ها اشتباه شروع میشن.
قبل از Payload، من معمولاً یه سؤال سادهتر میپرسم:
این Input دقیقاً کجا قرار گرفته؟
داخل HTML؟
داخل یک Attribute؟
داخل JavaScript؟
توی URL؟
یا اصلاً JavaScript سمت Client داره این مقدار رو از جایی میخونه و وارد DOM میکنه؟
چون این:
<input>
به تنهایی چیزی بهت نمیگه.
مهم اینه که Application و Browser باهاش چه رفتاری میکنن.
یه سناریوی ساده:
تو Search میزنی:
THB
صفحه هم نشون میده:
Search results for: THB
خوبه.
حالا به جای اینکه سریع بری سراغ Payloadهای مختلف، مسیر مقدار رو دنبال کن.
Input → Source → Data Flow → Sink → Context → Execution
اگر بفهمی داده از کجا وارد شده و نهایتاً به کجا رسیده، تازه می فهمی باید دنبال چه چیزی بگردی.
حالا سه حالت اصلی XSS رو از هم جدا کن:
🔹 Reflected XSS
اInput از Request میاد و در Response برمیگرده.
🔹 Stored XSS
اInput ذخیره میشه و بعداً وقتی یک User دیگه صفحه رو میبینه، Render میشه.
🔹 DOM-Based XSS
این یکی جالب تره.
ممکنه Server اصلاً چیزی از Payload نبینه.
جاوااسکریپت سمت Client داده رو از یک Source میگیره و به یک Sink خطرناک میرسونه.
یعنی اگر فقط Responseهای Server رو نگاه کنی، ممکنه کل داستان رو از دست بدی.
حالا یه سؤال برای خودت:
فرض کن مقدار زیر رو وارد کردی:
THB123
و این مقدار داخل HTML صفحه ظاهر شد.
آیا همین به معنی XSS Vulnerability هست؟
اگر جوابت «بله» یا «نه» هست، دلیلش رو هم بنویس.
ببینیم چند نفر واقعاً Context رو بررسی میکنن، نه فقط دنبال Payload می گردن.
@TryHackBox
#تست_نفوذ #امنیت_سایبری
❤7
🧩 WINDOWS INTERNALS FIELD NOTES #01
اException Handling فقط برای Crash کردن برنامه نیست
وقتی یک برنامه در Windows با یک Exception مواجه می شود، اولین چیزی که معمولاً به ذهنمان میرسد این است:
«خب، برنامه خطا داد.»
اما از دید یک Reverse Engineer، سؤال مهمتر این است:
بعد از رخ دادن Exception، چه چیزی تصمیم میگیرد Execution کجا ادامه پیدا کند؟
اینجا Exception Handling وارد ماجرا میشود.
فرض کن برنامه این دستور را اجرا میکند:
int *ptr = NULL; *ptr = 1337;
طبیعتاً CPU نمیتواند این Memory Access را انجام دهد و یک Exception ایجاد میشود.
اما داستان همانجا تمام نمیشود.
اWindows Exception را دریافت میکند و وارد یک مسیر مشخص برای پیدا کردن Handler مناسب میشود.
به زبان ساده:
و همین مسیر ساده، یک نکته مهم دارد:
اException میتواند روی مسیر اجرای برنامه تأثیر بگذارد.
First-Chance و Second-Chance Exception
در Debugging با این دو مفهوم زیاد برخورد میکنید.
First-Chance Exception
اولین مرحلهای است که Exception به Debugger و سپس مکانیزم Exception Handling ارائه میشود.
اگر برنامه Handler مناسبی داشته باشد، ممکن است Exception مدیریت شود و Execution ادامه پیدا کند.
اگر نه، Exception دوباره در مسیر Handling بررسی میشود.
در نهایت اگر هیچ Handler مناسبی پیدا نشود:
Second-Chance Exception
یعنی دیگر جایی برای Handle کردن Exception باقی نمانده و معمولاً Process به پایان میرسد.
برای همین وقتی در x64dbg یا WinDbg با Exception مواجه میشوید، نباید فوراً فرض کنید:
«برنامه Crash کرد.»
باید بپرسید:
این Exception چرا ایجاد شد؟
چه کسی آن را Handle میکند؟
و Execution بعد از آن کجا ادامه پیدا میکند؟
اینجا موضوع برای Security جالب میشود
یک Exception Handler میتواند صرفاً برای مدیریت خطا استفاده شود.
اما اگر کسی عمداً Exception ایجاد کند و از Handler برای تغییر مسیر Execution استفاده کند چه؟
آن وقت Exception Handling دیگر فقط یک مکانیزم Error Handling نیست.
میتواند تبدیل شود به یک Control-Flow Primitive.
در Malware و بعضی تکنیک های Anti-Analysis، این رفتار میتواند برای سختتر کردن تحلیل برنامه استفاده شود.
اAnalyst ممکن است یک مسیر Execution را دنبال کند، اما بخشی از Control Flow از طریق Exception اتفاق بیفتد.
و این دقیقاً جایی است که باید نگاه Reverse Engineer از «چه خطایی رخ داده؟» به «این Exception چه نقشی در Control Flow دارد؟» تغییر کند.
🎯 چیزی که باید از این قسمت یاد بگیری
هر Exception را Crash در نظر نگیر.
وقتی در یک Binary رفتار غیرعادی دیدی، این چند سؤال را از خودت بپرس:
اException از کجا Trigger شد؟
اException Code چیست؟
چه Handlerای آن را دریافت میکند؟
اHandler چه تغییری در Execution ایجاد میکند؟
آیا Instruction Pointer بعد از Handler تغییر میکند؟
آیا Exception بخشی از Logic برنامه است یا صرفاً Error Handling؟
@TryHackBox
#WindowsInternals #ReverseEngineering #MalwareAnalysis #x64dbg #CyberSecurity
اException Handling فقط برای Crash کردن برنامه نیست
وقتی یک برنامه در Windows با یک Exception مواجه می شود، اولین چیزی که معمولاً به ذهنمان میرسد این است:
«خب، برنامه خطا داد.»
اما از دید یک Reverse Engineer، سؤال مهمتر این است:
بعد از رخ دادن Exception، چه چیزی تصمیم میگیرد Execution کجا ادامه پیدا کند؟
اینجا Exception Handling وارد ماجرا میشود.
فرض کن برنامه این دستور را اجرا میکند:
int *ptr = NULL; *ptr = 1337;
طبیعتاً CPU نمیتواند این Memory Access را انجام دهد و یک Exception ایجاد میشود.
اما داستان همانجا تمام نمیشود.
اWindows Exception را دریافت میکند و وارد یک مسیر مشخص برای پیدا کردن Handler مناسب میشود.
به زبان ساده:
Instruction
↓
Exception
↓
Windows Exception Dispatcher
↓
Exception Handler
↓
Handle / Continue / Terminate
و همین مسیر ساده، یک نکته مهم دارد:
اException میتواند روی مسیر اجرای برنامه تأثیر بگذارد.
First-Chance و Second-Chance Exception
در Debugging با این دو مفهوم زیاد برخورد میکنید.
First-Chance Exception
اولین مرحلهای است که Exception به Debugger و سپس مکانیزم Exception Handling ارائه میشود.
اگر برنامه Handler مناسبی داشته باشد، ممکن است Exception مدیریت شود و Execution ادامه پیدا کند.
اگر نه، Exception دوباره در مسیر Handling بررسی میشود.
در نهایت اگر هیچ Handler مناسبی پیدا نشود:
Second-Chance Exception
یعنی دیگر جایی برای Handle کردن Exception باقی نمانده و معمولاً Process به پایان میرسد.
برای همین وقتی در x64dbg یا WinDbg با Exception مواجه میشوید، نباید فوراً فرض کنید:
«برنامه Crash کرد.»
باید بپرسید:
این Exception چرا ایجاد شد؟
چه کسی آن را Handle میکند؟
و Execution بعد از آن کجا ادامه پیدا میکند؟
اینجا موضوع برای Security جالب میشود
یک Exception Handler میتواند صرفاً برای مدیریت خطا استفاده شود.
اما اگر کسی عمداً Exception ایجاد کند و از Handler برای تغییر مسیر Execution استفاده کند چه؟
آن وقت Exception Handling دیگر فقط یک مکانیزم Error Handling نیست.
میتواند تبدیل شود به یک Control-Flow Primitive.
در Malware و بعضی تکنیک های Anti-Analysis، این رفتار میتواند برای سختتر کردن تحلیل برنامه استفاده شود.
اAnalyst ممکن است یک مسیر Execution را دنبال کند، اما بخشی از Control Flow از طریق Exception اتفاق بیفتد.
Normal Flow
↓
Instruction
↓
Exception
↓
Handler
↓
Modified Context
↓
Different Execution Flow
و این دقیقاً جایی است که باید نگاه Reverse Engineer از «چه خطایی رخ داده؟» به «این Exception چه نقشی در Control Flow دارد؟» تغییر کند.
🎯 چیزی که باید از این قسمت یاد بگیری
هر Exception را Crash در نظر نگیر.
وقتی در یک Binary رفتار غیرعادی دیدی، این چند سؤال را از خودت بپرس:
اException از کجا Trigger شد؟
اException Code چیست؟
چه Handlerای آن را دریافت میکند؟
اHandler چه تغییری در Execution ایجاد میکند؟
آیا Instruction Pointer بعد از Handler تغییر میکند؟
آیا Exception بخشی از Logic برنامه است یا صرفاً Error Handling؟
@TryHackBox
#WindowsInternals #ReverseEngineering #MalwareAnalysis #x64dbg #CyberSecurity
👍3❤1
Media is too big
VIEW IN TELEGRAM
📌 معرفی دوره :
THB-WP101 : Web Penetration Testing Fundamentals
ورود به Web Penetration Testing با حفظ کردن چند Vulnerability شروع نمی شود.
اگر قرار است یک Web Pentester باشید، باید بتوانید یک Web Application را بشناسید، Attack Surface آن را پیدا کنید، نقاط ورودی را بررسی کنید، رفتار Authentication و Access Control را تحلیل کنید، Vulnerabilityها را تست و Validate کنید و در نهایت Impact و مسیر حمله را مستند کنید.
دوره ما برای ساختن همین مهارتها طراحی شده است.
⏳زمان یادگیری: حدود 40-50 ساعت
🛠 80 الی 90 درصد Practical
📌 کلاس : آنلاین
💠 مشاهده سرفصل ها
💢 ثبت نام اولیه شروع شد
⭕ تاریخ شروع کلاس : ۱۴۰۵/۰۶/۲۲
👤 مدرس : مهندس محمد طاهری
💠 لینکدین مدرس
📌 توضیحات تکمیلی
💰ارزش اصلی دوره: ۵،۹۰۰،۰۰۰ تومان
💰قیمت استاندارد : ۳,۹۸۹,۰۰۰ تومان
🔥 تخفیف ویژه برای ۵ نفر اول : ۲,۸۹۹,۰۰۰ تومان
این قیمت برای ثبتنام اولیه در نظر گرفته شده و پس از پایان این مرحله تغییر خواهد کرد.
اگر واقعاً میخوای Web Pentesting رو شروع کنی، از همینجا شروع کن.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
@TryHackBox
THB-WP101 : Web Penetration Testing Fundamentals
ورود به Web Penetration Testing با حفظ کردن چند Vulnerability شروع نمی شود.
اگر قرار است یک Web Pentester باشید، باید بتوانید یک Web Application را بشناسید، Attack Surface آن را پیدا کنید، نقاط ورودی را بررسی کنید، رفتار Authentication و Access Control را تحلیل کنید، Vulnerabilityها را تست و Validate کنید و در نهایت Impact و مسیر حمله را مستند کنید.
دوره ما برای ساختن همین مهارتها طراحی شده است.
⏳زمان یادگیری: حدود 40-50 ساعت
🛠 80 الی 90 درصد Practical
📌 کلاس : آنلاین
💠 مشاهده سرفصل ها
💢 ثبت نام اولیه شروع شد
⭕ تاریخ شروع کلاس : ۱۴۰۵/۰۶/۲۲
👤 مدرس : مهندس محمد طاهری
💠 لینکدین مدرس
📌 توضیحات تکمیلی
💰
💰
🔥 تخفیف ویژه برای ۵ نفر اول : ۲,۸۹۹,۰۰۰ تومان
این قیمت برای ثبتنام اولیه در نظر گرفته شده و پس از پایان این مرحله تغییر خواهد کرد.
اگر واقعاً میخوای Web Pentesting رو شروع کنی، از همینجا شروع کن.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
@TryHackBox
🔥4
Try Hack Box
🛡️ SAML SECURITY SERIES | PART 02 🎫 Signature Wrapping وقتی Signature معتبره، ولی Application چیز دیگهای رو میخونه! در قسمت قبل گفتیم یکی از اولین چیزهایی که در بررسی یک SAML Implementation باید بهش توجه کنیم، Signature Validation هست. حالا بریم سراغ یکی…
🛡️ SAML SECURITY SERIES | PART 03
ا💥 XML Attacks : وقتی خود Parser تبدیل به Attack Surface میشه
قسمت قبل رفتیم سراغ XSW (XML Signature Wrapping).
حالا یه سؤال که خیلی وقت ها ازش رد میشیم:
فرض کن Signature رو بررسی کردی.
درست هم Validate شد.
میتونی بگی:
«خب، پس SAML امنه.»
نه.
چون یه لایهی دیگه هنوز سر جاشه:
XML.
اSAML شدیداً به XML وابسته است.
یعنی حتی اگر منطق Authentication و Signature Validation درست پیادهسازی شده باشن، هنوز نحوهی پردازش XML میتونه خودش یک Attack Surface باشه.
اینجا اولین چیزی که ارزش بررسی داره:
DTD Processing
چرا؟
چون اگر XML Parser اجازهی پردازش DTD یا External Entityها رو بده، ممکنه وارد یک دستهی کاملاً متفاوت از حملات بشیم:
🔹 XXE — XML External Entity
🔹 XML DoS
🔹 Billion Laughs Attack
این مشکلات لزوماً به Signature مربوط نیستن.
حتی ممکنه Signature کاملاً معتبر باشه، ولی XML Parser رفتار ناامنی داشته باشه.
پس وقتی یک SAML Endpoint جلوی شماست، فقط نپرسید:
«Signature اوکیه؟»
یه قدم عقب تر برید.
بپرسید:
اXML چطور Parse میشه؟
اDTD چطور Handle میشه؟
اExternal Entityها اجازهی پردازش دارن؟
اParser با XMLهای غیرعادی یا Malformed چطور رفتار میکنه؟
اینجا دقیقاً همون جاییه که طرز فکر Security Tester مهم میشه.
چون هدف فقط پیدا کردن یک Payload نیست.
اول باید بفهمی:
اApplication دقیقاً چطور XML رو پردازش میکنه؟
یک SAML Implementation ممکنه از نظر Signature Validation کاملاً درست باشه...
ولی XML Parser اون همچنان میتونه یک Attack Surface مستقل داشته باشه.
و این دو موضوع رو نباید با هم قاطی کرد.
حالا نوبت شماست
فرض کن رسیدی به یک SAML Endpoint.
قبل از اینکه بری سراغ Authentication Logic، فقط اجازه داری یکی از این موارد رو بررسی کنی:
1️⃣ DTD Processing
2️⃣ External Entities
3️⃣ Entity Expansion
4️⃣ رفتار Parser در برابر XMLهای غیرعادی / Malformed
کدوم رو انتخاب میکنی؟
و مهم تر:
چرا همون یکی؟
میخوام ببینم انتخابت بر اساس Attack Surface و رفتار Applicationه...
یا فقط چون اسم یک Vulnerability رو شنیدی.
@TryHackBox
#امنیت_سایبری #تست_نفوذ
ا💥 XML Attacks : وقتی خود Parser تبدیل به Attack Surface میشه
قسمت قبل رفتیم سراغ XSW (XML Signature Wrapping).
حالا یه سؤال که خیلی وقت ها ازش رد میشیم:
فرض کن Signature رو بررسی کردی.
درست هم Validate شد.
میتونی بگی:
«خب، پس SAML امنه.»
نه.
چون یه لایهی دیگه هنوز سر جاشه:
XML.
اSAML شدیداً به XML وابسته است.
یعنی حتی اگر منطق Authentication و Signature Validation درست پیادهسازی شده باشن، هنوز نحوهی پردازش XML میتونه خودش یک Attack Surface باشه.
اینجا اولین چیزی که ارزش بررسی داره:
DTD Processing
چرا؟
چون اگر XML Parser اجازهی پردازش DTD یا External Entityها رو بده، ممکنه وارد یک دستهی کاملاً متفاوت از حملات بشیم:
🔹 XXE — XML External Entity
🔹 XML DoS
🔹 Billion Laughs Attack
این مشکلات لزوماً به Signature مربوط نیستن.
حتی ممکنه Signature کاملاً معتبر باشه، ولی XML Parser رفتار ناامنی داشته باشه.
پس وقتی یک SAML Endpoint جلوی شماست، فقط نپرسید:
«Signature اوکیه؟»
یه قدم عقب تر برید.
بپرسید:
اXML چطور Parse میشه؟
اDTD چطور Handle میشه؟
اExternal Entityها اجازهی پردازش دارن؟
اParser با XMLهای غیرعادی یا Malformed چطور رفتار میکنه؟
اینجا دقیقاً همون جاییه که طرز فکر Security Tester مهم میشه.
چون هدف فقط پیدا کردن یک Payload نیست.
اول باید بفهمی:
اApplication دقیقاً چطور XML رو پردازش میکنه؟
یک SAML Implementation ممکنه از نظر Signature Validation کاملاً درست باشه...
ولی XML Parser اون همچنان میتونه یک Attack Surface مستقل داشته باشه.
و این دو موضوع رو نباید با هم قاطی کرد.
حالا نوبت شماست
فرض کن رسیدی به یک SAML Endpoint.
قبل از اینکه بری سراغ Authentication Logic، فقط اجازه داری یکی از این موارد رو بررسی کنی:
1️⃣ DTD Processing
2️⃣ External Entities
3️⃣ Entity Expansion
4️⃣ رفتار Parser در برابر XMLهای غیرعادی / Malformed
کدوم رو انتخاب میکنی؟
و مهم تر:
چرا همون یکی؟
میخوام ببینم انتخابت بر اساس Attack Surface و رفتار Applicationه...
یا فقط چون اسم یک Vulnerability رو شنیدی.
@TryHackBox
#امنیت_سایبری #تست_نفوذ
Media is too big
VIEW IN TELEGRAM
حل چلنچ : The Broken Trust : THB CTF
حل چالش توسط اقا احمد عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
حل چالش توسط اقا احمد عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
❤3
📌 دوره THB-WP101 : Web Penetration Testing Fundamentals
ورود به Web Penetration Testing با حفظ کردن چند آسیب پذیری شروع نمی شود.
اگر قرار است یک Web Pentester باشید، باید بتوانید یک Web Application را بشناسید، Attack Surface آن را پیدا کنید، نقاط ورودی را بررسی کنید، رفتار Authentication و Access Control را تحلیل کنید، Vulnerabilityها را تست و Validate کنید و در نهایت Impact و مسیر حمله را مستند کنید.
دوره ما برای ساختن همین مهارتها طراحی شده است.
📌 ویدئو معرفی دوره
⏳زمان یادگیری: حدود 40-50 ساعت
🛠 80 الی 90 درصد عملی
📌 کلاس : آنلاین
💠 مشاهده سرفصل ها
💢 ثبت نام اولیه شروع شد
⭕ تاریخ شروع کلاس : ۱۴۰۵/۰۶/۲۲
👤 مدرس : مهندس محمد طاهری
💠 لینکدین مدرس
📌 توضیحات تکمیلی
💰 ارزش اصلی دوره: ۵،۹۰۰،۰۰۰ تومان
💰 قیمت استاندارد : ۳,۹۸۹,۰۰۰ تومان
🔥 تخفیف ویژه برای ۵ نفر اول : ۲,۸۹۹,۰۰۰ تومان
این قیمت برای ثبتنام اولیه در نظر گرفته شده و پس از پایان این مرحله تغییر خواهد کرد.
اگر واقعاً میخوای Web Pentesting رو شروع کنی، از همینجا شروع کن.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
@TryHackBox
ورود به Web Penetration Testing با حفظ کردن چند آسیب پذیری شروع نمی شود.
اگر قرار است یک Web Pentester باشید، باید بتوانید یک Web Application را بشناسید، Attack Surface آن را پیدا کنید، نقاط ورودی را بررسی کنید، رفتار Authentication و Access Control را تحلیل کنید، Vulnerabilityها را تست و Validate کنید و در نهایت Impact و مسیر حمله را مستند کنید.
دوره ما برای ساختن همین مهارتها طراحی شده است.
📌 ویدئو معرفی دوره
⏳زمان یادگیری: حدود 40-50 ساعت
🛠 80 الی 90 درصد عملی
📌 کلاس : آنلاین
💠 مشاهده سرفصل ها
💢 ثبت نام اولیه شروع شد
⭕ تاریخ شروع کلاس : ۱۴۰۵/۰۶/۲۲
👤 مدرس : مهندس محمد طاهری
💠 لینکدین مدرس
📌 توضیحات تکمیلی
💰 ارزش اصلی دوره: ۵،۹۰۰،۰۰۰ تومان
💰 قیمت استاندارد : ۳,۹۸۹,۰۰۰ تومان
🔥 تخفیف ویژه برای ۵ نفر اول : ۲,۸۹۹,۰۰۰ تومان
این قیمت برای ثبتنام اولیه در نظر گرفته شده و پس از پایان این مرحله تغییر خواهد کرد.
اگر واقعاً میخوای Web Pentesting رو شروع کنی، از همینجا شروع کن.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
@TryHackBox
❤4👎3🔥1
🔐 چک لیست تست نفوذ شبکه های بی سیم (Wi-Fi Pentest Checklist)
تیم TryHackbox یک متدولوژی کامل برای تست امنیت شبکه های Wi-Fi (شامل WEP، WPA/WPA2 و WPA2-Enterprise) تهیه کرده که میتونه برای کارشناسان امنیت و علاقه مندان این حوزه مفید باشه.
جزئیات کامل + دسترسی به این چک لیست رو در پست لینکدین ما ببینید 👇
🔗 https://lnkd.in/d47sHZTe
#امنیت_سایبری #تست_نفوذ #تست_نفوذ_وایرلس
@TryHackBox
تیم TryHackbox یک متدولوژی کامل برای تست امنیت شبکه های Wi-Fi (شامل WEP، WPA/WPA2 و WPA2-Enterprise) تهیه کرده که میتونه برای کارشناسان امنیت و علاقه مندان این حوزه مفید باشه.
جزئیات کامل + دسترسی به این چک لیست رو در پست لینکدین ما ببینید 👇
🔗 https://lnkd.in/d47sHZTe
#امنیت_سایبری #تست_نفوذ #تست_نفوذ_وایرلس
@TryHackBox
👏3❤1
ا🔎 IDOR را با عوض کردن ID اشتباه نگیرید
خیلی ها وقتی یک Endpoint مثل این میبینند:
اولین کاری که میکنند این است:
اگر جواب گرفتند، می گویند IDOR پیدا شد.
اما تست حرفه ای کمی متفاوت است.
اول باید بفهمی این Endpoint چه Objectی را کنترل میکند و Authorization دقیقاً کجا اعمال میشود.
یک روش ساده:
با Account A یک Object بساز.
همان Object را با Account B درخواست کن.
ببین Server فقط Authentication را بررسی میکند یا واقعاً Ownership را هم بررسی میکند.
بعد سراغ تغییر Identifier برو.
چون سؤال اصلی این نیست:
سؤال اصلی این است:
«آیا Server قبل از دسترسی به Object، بررسی میکند این Object واقعاً متعلق به من است؟»
اگر پاسخ دوم «نه» باشد، مشکل فقط یک ID قابلحدس نیست؛ یک Authorization Failure است.
@TryHackBox
#تست_نفوذ #امنیت_وب #امنیت_سایبری
خیلی ها وقتی یک Endpoint مثل این میبینند:
GET /api/users/123
اولین کاری که میکنند این است:
GET /api/users/124
اگر جواب گرفتند، می گویند IDOR پیدا شد.
اما تست حرفه ای کمی متفاوت است.
اول باید بفهمی این Endpoint چه Objectی را کنترل میکند و Authorization دقیقاً کجا اعمال میشود.
یک روش ساده:
با Account A یک Object بساز.
همان Object را با Account B درخواست کن.
ببین Server فقط Authentication را بررسی میکند یا واقعاً Ownership را هم بررسی میکند.
بعد سراغ تغییر Identifier برو.
چون سؤال اصلی این نیست:
«آیا میتوانم ID را تغییر بدهم؟»
سؤال اصلی این است:
«آیا Server قبل از دسترسی به Object، بررسی میکند این Object واقعاً متعلق به من است؟»
اگر پاسخ دوم «نه» باشد، مشکل فقط یک ID قابلحدس نیست؛ یک Authorization Failure است.
@TryHackBox
#تست_نفوذ #امنیت_وب #امنیت_سایبری
👍7❤6
Media is too big
VIEW IN TELEGRAM
حل چلنچ دوم :
Race Against Trust : THB CTF
حل CTF توسط اقا ایمان عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
Race Against Trust : THB CTF
حل CTF توسط اقا ایمان عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
❤8
This media is not supported in your browser
VIEW IN TELEGRAM
حل چلنچ دوم :
Race Against Trust : THB CTF
حل CTF توسط اقا احمد عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
Race Against Trust : THB CTF
حل CTF توسط اقا احمد عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
❤5
Try Hack Box
ا🔎 IDOR را با عوض کردن ID اشتباه نگیرید خیلی ها وقتی یک Endpoint مثل این میبینند: GET /api/users/123 اولین کاری که میکنند این است: GET /api/users/124 اگر جواب گرفتند، می گویند IDOR پیدا شد. اما تست حرفه ای کمی متفاوت است. اول باید بفهمی این Endpoint…
🚧 403 همیشه پایان تست نیست.
فرض کن به این Endpoint میرسی:
و Server جواب میدهد:
خیلی ها همینجا متوقف میشوند.اما یکی از چیزهایی که در تست Authorization باید بررسی شود، HTTP Method است.
مثلاً:
اما:
این رفتار می تواند نشان دهد Authorization بین Methodهای مختلف به درستی یکسان اعمال نشده است.
همین منطق را میتوان روی Endpointهایی که عملیات حساس انجام میدهند بررسی کرد:
نکته مهم:
قرار نیست کورکورانه همه Methodها را امتحان کنی.
اول مشخص کن Endpoint چه کاری انجام می دهد، Method مورد انتظار چیست و Responseها چه تفاوتی دارند.
پنتست خوب یعنی دنبال کردن رفتار Application، نه فقط دنبال کردن Status Code.
@TryHackBox
#تست_نفوذ #امنیت_وب #امنیت_سایبری
فرض کن به این Endpoint میرسی:
GET /users/delete/victim_id
و Server جواب میدهد:
403 Forbidden
خیلی ها همینجا متوقف میشوند.اما یکی از چیزهایی که در تست Authorization باید بررسی شود، HTTP Method است.
مثلاً:
GET /users/delete/victim_id → 403
اما:
POST /users/delete/victim_id → 200
این رفتار می تواند نشان دهد Authorization بین Methodهای مختلف به درستی یکسان اعمال نشده است.
همین منطق را میتوان روی Endpointهایی که عملیات حساس انجام میدهند بررسی کرد:
GET
POST
PUT
PATCH
DELETE
نکته مهم:
قرار نیست کورکورانه همه Methodها را امتحان کنی.
اول مشخص کن Endpoint چه کاری انجام می دهد، Method مورد انتظار چیست و Responseها چه تفاوتی دارند.
پنتست خوب یعنی دنبال کردن رفتار Application، نه فقط دنبال کردن Status Code.
@TryHackBox
#تست_نفوذ #امنیت_وب #امنیت_سایبری
🔥5❤1
thb-ctf-03-mirror-player.zip
17.3 KB
🔐 THB CTF Team Qualification : Challenge #03 : Mirror
دسته: Web Penetration Testing
سطح سختی: Hard
پروژه: TCTQ مسیر پذیرش تیم CTF TryHackBox
📖 سناریو
یا
اپلیکیشن روی آدرس زیر بالا میاد:
فرمت فلگ :
ارسال فلگ :
@Unique_exploitbot
قوانین و توضیحات تکمیلی
@TryHackBox
#CTF_THB
دسته: Web Penetration Testing
سطح سختی: Hard
پروژه: TCTQ مسیر پذیرش تیم CTF TryHackBox
📖 سناریو
اMirror یه Identity Gateway داخلیه که توکن های session رو برای چند تا سرویس پلتفرم صادر و verify میکنه. همچنین یه مستندات integration برای سرویس های partner منتشر کرده که بخوان توکن های Mirror رو مستقل verify کنن.⚙️ نحوه اجرا
شما بهعنوان یه پنتستر خارجی استخدام شدید. یه اکانت عادی بسازید و ببینید یه کاربر معمولی تا کجا میتونه پیش بره.
🎯 هدف: شناسایی و دسترسی به بالاترینسطح Resource قابل دسترس روی این پلتفرم، و گرفتن verification code ای که برمیگردونه.
docker compose up --build
یا
./start.sh
اپلیکیشن روی آدرس زیر بالا میاد:
http://localhost:8003
فرمت فلگ :
THB{ }
ارسال فلگ :
@Unique_exploitbot
قوانین و توضیحات تکمیلی
@TryHackBox
#CTF_THB
👍3❤1
برخی از دورک های Shodan که ممکن است در برنامههای باگ بانتی مفید باشند.
@TryHackBox
#باگ_بانتی #امنیت_سایبری
شما چه مواردی استفاده میکنید ؟
@TryHackBox
#باگ_بانتی #امنیت_سایبری
🔥4
📚 مجموعه کتابهای کاربردی در دنیای امنیت
📖 کتابچه "Mimikatz: تسلط عملی بر تکنیکهای پیشرفته حملات Active Directory" از مقدماتی تا پیشرفته.
📕 جزئیات بیشتر کتاب
💰 قیمت : ۲۵۰,۰۰۰ تومان
📖 وایرشارک برای ردتیمرها: از پایه تا پیشرفته
📕 جزئیات بیشتر کتاب
💰 قیمت : ۲۵۰,۰۰۰ تومان
📖 شکار عملی باگ بانتی : از Recon تا Bounty واقعی : متدولوژی و شناسایی و آسیب پذیری های دنیای واقعی
📕 جزئیات بیشتر کتاب
💰 قیمت : ۳۶۰,۰۰۰ تومان
📖 کتابچه Kerberos For Pentesters
📕 جزئیات بیشتر کتاب
💰 قیمت : ۲۶۹ تومان
ممکنه در آینده قیمت کتاب ها تغییر کنه و افزایش داشته باشه بنابراین اگر قصد خرید دارید، قیمت فعلی فرصت خوبی برای تهیه کتاب هاست.
📌 جهت خرید به ایدی زیر پیام دهید:
@THBxSupport
📖 کتابچه "Mimikatz: تسلط عملی بر تکنیکهای پیشرفته حملات Active Directory" از مقدماتی تا پیشرفته.
📕 جزئیات بیشتر کتاب
💰 قیمت : ۲۵۰,۰۰۰ تومان
📖 وایرشارک برای ردتیمرها: از پایه تا پیشرفته
📕 جزئیات بیشتر کتاب
💰 قیمت : ۲۵۰,۰۰۰ تومان
📖 شکار عملی باگ بانتی : از Recon تا Bounty واقعی : متدولوژی و شناسایی و آسیب پذیری های دنیای واقعی
📕 جزئیات بیشتر کتاب
💰 قیمت : ۳۶۰,۰۰۰ تومان
📖 کتابچه Kerberos For Pentesters
📕 جزئیات بیشتر کتاب
💰 قیمت : ۲۶۹ تومان
ممکنه در آینده قیمت کتاب ها تغییر کنه و افزایش داشته باشه بنابراین اگر قصد خرید دارید، قیمت فعلی فرصت خوبی برای تهیه کتاب هاست.
📌 جهت خرید به ایدی زیر پیام دهید:
@THBxSupport
❤3🔥2
Forwarded from Try Hack Box
Try Hack Box
📌 دوره THB-WP101 : Web Penetration Testing Fundamentals ورود به Web Penetration Testing با حفظ کردن چند آسیب پذیری شروع نمی شود. اگر قرار است یک Web Pentester باشید، باید بتوانید یک Web Application را بشناسید، Attack Surface آن را پیدا کنید، نقاط ورودی…
قبل از اینکه ثبت نام کنی، بذار رک بهت بگم قراره چی یاد بگیری.
خیلیها Web Pentesting رو با چندتا ویدئو، چندتا Payload آماده و کار با Burp Suite شروع میکنن تا اینجاش خوبه.
اما خیلی ها یه جایی گیر میکنن:
وقتی یه سایت یا Web Application جلوشونه، نمیدونن از کجا باید شروع کنن، چی رو بررسی کنن و قدم بعدی چیه.
دقیقاً روی همین بخش تمرکز کردیم.
THB Web Penetration Testing Fundamentals
یه دورهی آنلاینه که تمرکزش روی عمله، نه تئوری خشک.
هر مبحث رو اول توضیح میدیم، بعد همون موضوع رو باهم روی مثالهای عملی بررسی میکنیم و بعد از پایان هر ماژول، تمرین هایی داری که باید خودت حلشون کنی.
یعنی:
Concept → Demo → Practice → Challenge
مسیری که کل دوره روش میچرخه هم اینه:
Recon → Enumeration → Attack Surface → Testing → Exploitation → Chaining → Impact → Reporting
سرفصل هایی که پوشش میدیم.
اما چیزی که برام از خود سرفصلها مهم تره، طرز فکر کردن موقع تست کردنه.
مثلاً وقتی IDOR رو یاد میگیری، قرار نیست فقط بدونی IDOR چیه.
باید بفهمی توی یه اپلیکیشن واقعی چی رو باید بررسی کنی، کدوم Requestها مشکوکن، رفتار برنامه رو چطور تحلیل کنی، آسیبپذیری رو چطور Verify کنی و Impact واقعیش چیه.
همین نگاه رو توی تمرین های هر ماژول هم دنبال میکنیم؛ تا وقتی دوره تموم شد، فقط چندتا اصطلاح و تکنیک حفظ نکرده باشی، بلکه بدونی وقتی با یه Target جدید روبهرو شدی، چطور باید بهش نگاه کنی.
این دوره برای کسی نیست که فقط دنبال یه لیست بلند از ابزار و پیلود هست .
برای کسیه که میخواد از جایی که الان هست، به جایی برسه که بتونه یه Web Application رو با ذهنیت یه پنتستر بررسی کنه.
قبل از ثبتنام، سرفصلها و سطح دوره رو ببین.
اگر چیزی که دنبالشی همینه، بیا شروع کنیم.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
خیلیها Web Pentesting رو با چندتا ویدئو، چندتا Payload آماده و کار با Burp Suite شروع میکنن تا اینجاش خوبه.
اما خیلی ها یه جایی گیر میکنن:
وقتی یه سایت یا Web Application جلوشونه، نمیدونن از کجا باید شروع کنن، چی رو بررسی کنن و قدم بعدی چیه.
دقیقاً روی همین بخش تمرکز کردیم.
THB Web Penetration Testing Fundamentals
یه دورهی آنلاینه که تمرکزش روی عمله، نه تئوری خشک.
هر مبحث رو اول توضیح میدیم، بعد همون موضوع رو باهم روی مثالهای عملی بررسی میکنیم و بعد از پایان هر ماژول، تمرین هایی داری که باید خودت حلشون کنی.
یعنی:
Concept → Demo → Practice → Challenge
مسیری که کل دوره روش میچرخه هم اینه:
Recon → Enumeration → Attack Surface → Testing → Exploitation → Chaining → Impact → Reporting
سرفصل هایی که پوشش میدیم.
اما چیزی که برام از خود سرفصلها مهم تره، طرز فکر کردن موقع تست کردنه.
مثلاً وقتی IDOR رو یاد میگیری، قرار نیست فقط بدونی IDOR چیه.
باید بفهمی توی یه اپلیکیشن واقعی چی رو باید بررسی کنی، کدوم Requestها مشکوکن، رفتار برنامه رو چطور تحلیل کنی، آسیبپذیری رو چطور Verify کنی و Impact واقعیش چیه.
همین نگاه رو توی تمرین های هر ماژول هم دنبال میکنیم؛ تا وقتی دوره تموم شد، فقط چندتا اصطلاح و تکنیک حفظ نکرده باشی، بلکه بدونی وقتی با یه Target جدید روبهرو شدی، چطور باید بهش نگاه کنی.
این دوره برای کسی نیست که فقط دنبال یه لیست بلند از ابزار و پیلود هست .
برای کسیه که میخواد از جایی که الان هست، به جایی برسه که بتونه یه Web Application رو با ذهنیت یه پنتستر بررسی کنه.
قبل از ثبتنام، سرفصلها و سطح دوره رو ببین.
اگر چیزی که دنبالشی همینه، بیا شروع کنیم.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
Telegraph
سرفصلهای دوره تست نفوذ مقدماتی
THB-WP101 : Web Penetration Testing Fundamentals سطح: مقدماتی تمرکز: 80–90٪ عملی Module 01: Web Pentesting Fundamentals What Is a Web Application and How Does It Work? HTTP/HTTPS from a Pentester’s Perspective Requests, Responses, Headers, and Cookies Authentication…
❤4
📌 THB-WP101 | Web Penetration Testing Fundamentals
یادگیری چند آسیبپذیری و ابزار، به تنهایی برای تبدیل شدن به یک Web Pentester کافی نیست.
یک وب پنتستر باید بتواند یک Web Application را ساختاریافته بررسی کند؛ Attack Surface و نقاط ورودی را شناسایی کند، Authentication و Access Control را ارزیابی کند، Vulnerabilityها را Validate کرده و Impact و مسیر حمله را مستند کند.
دوره ما با تمرکز بر همین مهارتها طراحی شده است.
⏳ ۴۰–۵۰ ساعت | 🛠 ۸۰–۹۰٪ عملی | 💻 آنلاین | 🎓 مقدماتی
🎥 ویدئوی معرفی | 📚 سرفصلها | 📄 توضیحات تکمیلی
👤 مدرس: مهندس محمد طاهری
🗓شروع: ۱ مهر ۱۴۰۵
💰 ارزش اصلی دوره: ۵،۹۰۰،۰۰۰ تومان
💰 استاندارد: ۳,۹۸۹,۰۰۰ تومان
🔥 ۵ نفر اول: ۲,۸۹۹,۰۰۰ تومان
📌 دوره آفلاین در اختیارتون قرار میگیره + گروه پشتیبانی
پس از تکمیل ۵ ظرفیت اولیه، قیمت به نرخ استاندارد بازمیگردد.
⚠️ این دوره برای یادگیری صرف ابزار و Payloadهای آماده نیست.
هدف، توانایی تحلیل و اجرای مستقل فرآیند تست یک Web Application جدید است.
۵ ظرفیت ثبتنام اولیه محدود است.
🔥 شیوه یادگیری
📌 ثبت نام :
@ThbxSupport
@TryHackBox
یادگیری چند آسیبپذیری و ابزار، به تنهایی برای تبدیل شدن به یک Web Pentester کافی نیست.
یک وب پنتستر باید بتواند یک Web Application را ساختاریافته بررسی کند؛ Attack Surface و نقاط ورودی را شناسایی کند، Authentication و Access Control را ارزیابی کند، Vulnerabilityها را Validate کرده و Impact و مسیر حمله را مستند کند.
دوره ما با تمرکز بر همین مهارتها طراحی شده است.
⏳ ۴۰–۵۰ ساعت | 🛠 ۸۰–۹۰٪ عملی | 💻 آنلاین | 🎓 مقدماتی
🎥 ویدئوی معرفی | 📚 سرفصلها | 📄 توضیحات تکمیلی
👤 مدرس: مهندس محمد طاهری
🗓شروع: ۱ مهر ۱۴۰۵
💰 ارزش اصلی دوره: ۵،۹۰۰،۰۰۰ تومان
💰 استاندارد: ۳,۹۸۹,۰۰۰ تومان
🔥
📌 دوره آفلاین در اختیارتون قرار میگیره + گروه پشتیبانی
پس از تکمیل ۵ ظرفیت اولیه، قیمت به نرخ استاندارد بازمیگردد.
⚠️ این دوره برای یادگیری صرف ابزار و Payloadهای آماده نیست.
هدف، توانایی تحلیل و اجرای مستقل فرآیند تست یک Web Application جدید است.
۵ ظرفیت ثبتنام اولیه محدود است.
🔥 شیوه یادگیری
📌 ثبت نام :
@ThbxSupport
@TryHackBox