Red Team Archive

🚧 403 همیشه پایان تست نیست. فرض کن به این 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 #تست_نفوذ #امنیت_وب #امنیت_سایبری

حل چلنچ دوم : Race Against Trust : THB CTF حل CTF توسط اقا احمد عزیز از اعضای کانال . @TryHackBox #CTF_THB

حل چلنچ دوم : Race Against Trust : THB CTF حل CTF توسط اقا ایمان عزیز از اعضای کانال . @TryHackBox #CTF_THB

حل چلنچ : The Broken Trust : THB CTF سناریوی حل چالش توسط اقا آرمین عزیز از اعضای کانال . @TryHackBox #CTF_THB

ا📌 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

📌 استفاده از ماشین‌های مجازی برای بایپس کردن ابزارهای امنیتی 📌 مهاجمان همچنان به آزمایش با پلتفرم‌ های مختلف مدیریت از راه دور 📌 مینی دوره #رایگان نصب و راه‌اندازی لابراتورهای تست نفوذ وب قسمت اول 📌 فکر می‌کنید، 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+

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

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

🌐 Web Pentesting | Field Notes - #02 SQL Injection را با SQLmap شروع نکنید یکی از رایج‌ ترین اشتباه‌ها در تست نفوذ وب این است که پنتستر به یک پارامتر میرسد و بلافاصله ابزار را اجرا می‌ کند؛ منتظر میماند تا SQLmap اعلام کند «Vulnerable». پیش از آن‌که حتی یک ابزار را اجرا کنید، باید دقیقاً بدانید به دنبال چه چیزی هستید. فرض کنید به این درخواست رسیده‌اید:

GET /products?id=42

اول دست نزنید. رفتار عادی برنامه را مشاهده کنید: کد پاسخ چیست؟ طول پاسخ چقدر است؟ چه محتوایی برمی‌ گردد؟ خطایی دیده می‌ شود؟ آیا پاسخ تغییر می‌ کند؟ تفاوتی در زمان پاسخ‌ دهی وجود دارد؟ سپس ورودی را تغییر دهید و رفتار برنامه را با حالت عادی مقایسه کنید. اگر با تغییر مقدار id، پاسخ به شکل قابل‌ توجهی دگرگون شود، این دیگر یک تغییر ساده نیست؛ یک سیگنال است. در این نقطه باید فرضیه بسازید: «ممکن است این پارامتر در یک کوئری پایگاه‌داده استفاده شود.» حالا تست واقعی آغاز می‌شود. و اینجا یک نکتهٔ حیاتی وجود دارد: اSQL Injection لزوماً قرار نیست خطای زیبا و واضحی روی صفحه نشان دهد. در Blind SQL Injection ممکن است: هیچ خطای پایگاه‌داده‌ای نبینید. هیچ داده‌ای مستقیماً برنگردد. و حتی پاسخ ظاهراً کاملاً عادی به نظر برسد. اما اگر برنامه بین شرایط مختلف رفتار متفاوتی از خود نشان دهد، همین تفاوت می‌ تواند سیگنال مهمی باشد. پس وقتی خروجی واضحی ندارید، سؤال درست این نیست که: «چه پیلود دیگری بزنم؟» سؤال درست این است: «چه چیزی را میتوانم اندازه‌گیری و مقایسه کنم؟» پاسخ؟ رفتار بولین؟ طول پاسخ؟ زمان پاسخ‌دهی؟ محتوا؟ اینجاست که مرز میان یک جمع‌ کنندهٔ پیلود و یک پنتستر وب واقعی مشخص میشود. اSQLmap ابزار فوق‌العاده‌ای است. اما قرار نیست به‌جای شما برنامه را بفهمد. شما باید فرضیه بسازید؛ ابزار فقط باید فرآیند تحقیق را سریع‌تر کند. اگر از ابتدا ابزار تصمیم بگیرد که به دنبال چه چیزی بگردد، ممکن است آسیب‌پذیری را پیدا کنید بدون آنکه واقعاً بفهمید چرا وجود دارد. و این برای یک پنتستر حرفه‌ای کافی نیست. @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 #تست_نفوذ #امنیت_سایبری

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

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

📌 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 #امنیت_سایبری #تست_نفوذ

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

وقتی یک 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 #باگ_بانتی #امنیت_سایبری #نکات_باگ_بانتی #امنیت_وب #امنیت_اپلیکیشن #تست_نفوذ #امنیت_اطلاعات