🔖 پیدا کردن اطلاعات حساس با 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

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

🌐 Web Pentesting | Field Notes - #02

SQL Injection را با SQLmap شروع نکنید

یکی از رایج‌ ترین اشتباه‌ها در تست نفوذ وب این است که پنتستر به یک پارامتر میرسد و بلافاصله ابزار را اجرا می‌ کند؛ منتظر میماند تا SQLmap اعلام کند «Vulnerable».

پیش از آن‌که حتی یک ابزار را اجرا کنید، باید دقیقاً بدانید به دنبال چه چیزی هستید.
فرض کنید به این درخواست رسیده‌اید:

GET /products?id=42

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

سپس ورودی را تغییر دهید و رفتار برنامه را با حالت عادی مقایسه کنید.

اگر با تغییر مقدار id، پاسخ به شکل قابل‌ توجهی دگرگون شود، این دیگر یک تغییر ساده نیست؛ یک سیگنال است.

در این نقطه باید فرضیه بسازید:
«ممکن است این پارامتر در یک کوئری پایگاه‌داده استفاده شود.»

حالا تست واقعی آغاز می‌شود.
و اینجا یک نکتهٔ حیاتی وجود دارد:
اSQL Injection لزوماً قرار نیست خطای زیبا و واضحی روی صفحه نشان دهد.

در Blind SQL Injection ممکن است:
هیچ خطای پایگاه‌داده‌ای نبینید.
هیچ داده‌ای مستقیماً برنگردد.
و حتی پاسخ ظاهراً کاملاً عادی به نظر برسد.

اما اگر برنامه بین شرایط مختلف رفتار متفاوتی از خود نشان دهد، همین تفاوت می‌ تواند سیگنال مهمی باشد.

پس وقتی خروجی واضحی ندارید، سؤال درست این نیست که:

«چه پیلود دیگری بزنم؟»

سؤال درست این است:
«چه چیزی را میتوانم اندازه‌گیری و مقایسه کنم؟»

پاسخ؟
رفتار بولین؟
طول پاسخ؟
زمان پاسخ‌دهی؟
محتوا؟

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

اSQLmap ابزار فوق‌العاده‌ای است.
اما قرار نیست به‌جای شما برنامه را بفهمد.
شما باید فرضیه بسازید؛ ابزار فقط باید فرآیند تحقیق را سریع‌تر کند.

اگر از ابتدا ابزار تصمیم بگیرد که به دنبال چه چیزی بگردد، ممکن است آسیب‌پذیری را پیدا کنید بدون آنکه واقعاً بفهمید چرا وجود دارد.
و این برای یک پنتستر حرفه‌ای کافی نیست.


@TryHackBox

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

⭕ یک خط برای پیدا کردن فایل‌ ها

subfinder -d domain.com -silent | \
while read host; do \
 for path in /config.js /config.json /app/config.js /settings.json /database.json /firebase.json /.env /.env.production /api_keys.json /credentials.json /secrets.json /google-services.json /package.json /package-lock.json /composer.json /pom.xml /docker-compose.yml /manifest.json /service-worker.js; do \
  echo "$host$path"; \
 done; \
done | httpx -mc 200

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

📌 استفاده از ماشین‌های مجازی برای بایپس کردن ابزارهای امنیتی

📌 مهاجمان همچنان به آزمایش با پلتفرم‌ های مختلف مدیریت از راه دور

📌 مینی دوره #رایگان نصب و راه‌اندازی لابراتورهای تست نفوذ وب قسمت اول

📌 فکر می‌کنید، xss نمی‌ تواند در اندپوینت .html فعال شود؟

📌 کجا می‌ توان به صورت قانونی LLM را هک کرد؟

📌 درک معماری های سندباکس

📌 بررسی تهدیدها : OWASP Top 10  برای LLM  

📌 بازنشانی رمز عبور منقضی شده حساب دامنه از طریق null-session و SAMR

📌 جستجو برای فایل‌های رمزگذاری شده

📌 نشت اطلاعات حساس و عدم وجود مجوز از طریق اندپوینت API

📌  دستورات کاربردی و سریع برای Host & Network Discovery و Service Enumeration و Web Enumeration

📌 بایپس احراز هویت از طریق Forged Session Cookie

📌  هک سیستم ‌های  SCADA    : پیداکردن سیستم ‌های SCADA با استفاده از  Censys

ا📌 AMSI Bypass و چالش‌های اجرای PowerShell در محیط‌های ویندوزی

📌 نکته‌ای برای باگ بانتی: بایپس احراز هویت

📌 دورک های مفید برای باگ هانترها

📌 جمع‌ آوری اطلاعات سریع‌ تر

📌 100 آسیب پذیری وب

📌 یه Google Dork ساده، ولی با ...

📌 شروع دوره #رایگان Network+

🔥 #باگ_بانتی فکر کنم این یکی برای بیشتر باگ‌ هانترها آشنا باشه

چند ساعت روی یه مورد وقت میذاری، مطمئنی یه آسیب پذیری پیدا کردی، حتی سناریوی Exploit رو هم تو ذهنت کامل کردی بعد آخرش میفهمی یا Out of Scope بوده، یا اصلاً آسیب پذیری محسوب نمیشده.

برای خیلیا False Positive بیشتر از چیزی که انتظار داشتن اتفاق افتاده.

برای شما چطور؟ بیشتر با Duplicate مواجه میشید، Out of Scope، False Positive یا باگی که در نهایت Impact قابل‌ توجهی نداره؟

اگه تجربه جالبی داشتید، بدون اشاره به اسم تارگت برامون بنویسید.

لینک گروه جهت مشارکت :

https://t.me/+XPV3S0tygl1lZGE0

TryHackBox | Ai Sec | Radio | RoadMap

ا📌 Source Code رو از نگاه یک Pentester چطور بررسی کنیم؟

وقتی توی تست نفوذ به Repository دسترسی داری، قرار نیست فقط بشینی کد رو خط‌ به‌ خط بخونی.

چیزی که برای من مهم‌ تره اینه که بفهمم کجاهایی از Attack Surface از بیرون دیده نمیشن.

مثلاً یک Endpoint که از بیرون پیدا نکردیم، یک Background Job، یک File Handler یا جایی که Authorization فقط توی بعضی مسیرها انجام شده.

معمولاً کار رو اینطوری جلو میبرم:

اول یک SAST نسبتاً گسترده اجرا میکنم و چیزهایی مثل Dependencyها، Generated Code و Testها رو تا حد ممکن از نتایج کنار میذارم.

بعد دیگه قرار نیست تک‌تک Alertها رو باور کنیم.

برای هر مورد باید برگردیم به Code و مسیر رو دنبال کنیم:

Entry Point → Data Flow → Validation → Dangerous Sink

مثلاً اگر یک Input کاربر به یک SQL Query میرسه، باید ببینیم واقعاً همین مسیر در Application قابل دسترسیه؟ داده Sanitize یا Parameterize شده؟ و در نهایت واقعاً چه اثری برای مهاجم داره؟

همین موضوع برای File Operation، Deserialization، Secrets، Access Control و Business Logic هم صدق میکنه.

یکی از اشتباهات رایج اینه که:

SAST Alert = Vulnerability

نه.
ممکنه کد مربوط به Test باشه، مسیر اصلاً Reachable نباشه یا قبل از رسیدن به Sink یک Security Control درست وجود داشته باشه.

برای همین Finding خوب باید یک Chain قابل اثبات داشته باشه.

از کجا شروع شد؟
کجا رفت؟
کجا به نقطه خطرناک رسید؟
مهاجم دقیقاً چه کاری میتونه انجام بده؟

و مهم‌ تر از همه چی باید Fix بشه؟
به‌نظرم ارزش Code Analysis این نیست که ۲۰۰ تا Alert تحویل بدیم.

ارزشش اینه که از بین اون ۲۰۰ مورد، چند Finding واقعی و قابل اثبات پیدا کنیم.

@TryHackBox
@TryHackBoxOfficial
@AiTHB
@RadioZeroPod

🔐 THB CTF Team Qualification :  Challenge #02 - Race Against Trust

دسته: 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