Try Hack Box

📌 THB-WP101 | Web Penetration Testing Fundamentals بسیاری از افرادی که وارد حوزه‌ی Web Penetration Testing میشوند، مسیر خود را با تماشای چند ویدئوی آموزشی و استفاده از Payloadهای آماده آغاز می‌کنند. این نقطه‌ی شروع به‌ خودی‌ خود ایرادی ندارد؛ چالش اصلی زمانی بروز میکند که فرد با یک Web Application واقعی مواجه میشود و نمی‌ داند فرآیند بررسی را از کجا آغاز کند، چه مواردی را باید ارزیابی کند، و گام بعدی چیست. دوره‌ی THB-WP101 دقیقاً با هدف پوشش همین شکاف طراحی شده است. روش آموزش آموزش هر مبحث در سه مرحله انجام می‌شود: ارائه‌ی مفهوم، بررسی آن در قالب مثال عملی، و در نهایت تمرینی که دانشجو باید به‌طور مستقل حل کند. Concept → Demo → Practice → Challenge مسیر کلی دوره نیز بر اساس فرآیند واقعی تست نفوذ تعریف شده است: Recon → Enumeration → Attack Surface → Testing → Exploitation → Chaining → Impact → Reporting ۱۰ ماژول | ۴۰ تا ۵۰ ساعت | ۸۰ تا ۹۰ درصد عملی 1️⃣ Web Pentesting Fundamentals (HTTP، Session، Methodology، Scope) 2️⃣ Reconnaissance & Attack Surface Mapping 3️⃣ Web Enumeration & Burp Suite (Proxy، Repeater، Intruder، Decoder) 4️⃣ Authentication & Session Attacks 5️⃣ Access Control & IDOR 6️⃣ Input Validation & Injection (SQLi، Command Injection، SSTI) 7️⃣ XSS & Client-Side Attacks 8️⃣ File, Path & Server-Side Attacks (LFI/RFI، XXE، SSRF) 9️⃣ API & Modern Web Testing (JWT، GraphQL، BOLA) 🔟 Chaining, Exploitation & Reporting مخاطب این دوره این دوره برای افرادی طراحی شده است که قصد دارند وارد حوزه‌ی Web Penetration Testing به‌صورت اصولی شوند، علاقه‌مندان به Bug Bounty، دانشجویان حوزه‌ی Cybersecurity، و افرادی که با مفاهیم پایه‌ی Linux و Networking آشنایی دارند. ⚠️ لازم به ذکر است این دوره برای افرادی که صرفاً به‌ دنبال فهرستی از ابزارها و Payloadهای آماده هستند مناسب نیست. هدف دوره، توانمندسازی دانشجو در تحلیل مستقل یک Web Application جدید با رویکرد یک متخصص تست نفوذ است. 🎓 مدرس: مهندس محمد طاهری 🗓 تاریخ شروع: ۱ مهر ۱۴۰۵ 💻 نحوه‌ی برگزاری: آنلاین 🎓 سطح: مقدماتی 💰 ارزش دوره: ۵,۹۰۰,۰۰۰ تومان 💰 قیمت استاندارد: ۳,۹۸۹,۰۰۰ تومان 📦 این دوره شامل نسخه‌ی آفلاین کامل

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

🔥 با Lynis، امنیت Linux Server رو در چند دقیقه Audit کن. اLynis یک ابزار Open Source برای Security Auditing در Linux و Unix است. بیش از ۲۰۰ بررسی انجام میدهد، از جمله: • تنظیمات SSH ا• Permissionها و SUID • وضعیت Firewall ا Kernel Parameters پکیج‌ ها و سرویس‌ ها • تنظیمات امنیتی سیستم نصب: apt install lynis یا: dnf install lynis اجرای Audit: lynis audit system برای اجرای سریع‌ تر: lynis audit system --quick اگر فقط میخواهی SSH را بررسی کنی: lynis audit system --tests-from-group ssh گزارش‌ ها هم معمولاً اینجا قرار می‌گیرند: /var/log/lynis.log /var/log/lynis-report.dat برای دیدن Hardening Index: grep hardening_index /var/log/lynis-report.dat نکته مهم: اLynis چیزی را خودش Fix نمی‌ کند. سیستم را بررسی میکند، Weaknessها را پیدا میکند و برای Hardening پیشنهاد میدهد. برای یک VPS یا Linux Server، یک Audit ساده با Lynis می‌ تواند مواردی را نشان دهد که در بررسی دستی از قلم افتاده‌ اند. 💬 آخرین بار که Linux Server خودت را Security Audit کردی، چه موردی پیدا شد که انتظارش را نداشتی؟ تجربه‌ ات را کامنت کن. @TryHackBox

یکی از methodologyهای مخفیم رو دراپ میکنم 🌀 Takeover AWS S3 Bucket 🔥 مثل حرفه‌ای‌ ها فوق‌ العاده ساده اما خیلی موثر ✨ قبل از هرچیزی بیایم کل سناریو رو بفهمیم... 👀 ۱. کدوم bucketها آسیب‌پذیر برای takeover هستن؟  👀 ۲. تاثیر واقعی takeover یه S3 bucket چیه؟  👀 ۳. چطور S3 bucketهای potentially vulnerable رو پیدا کنیم؟  👀 ۴. چطور validate کنیم که bucket واقعاً توسط تارگت استفاده شده؟ ⚡ ۱. Bucket های آسیب‌پذیر:  اگه تارگت قبلاً از یه S3 bucket استفاده کرده و deleteش کرده اما subdomain (CNAME) هنوز به amazonaws.com اشاره میکنه این فرصت عالی takeoverه. ⚡ ۲. تاثیر:  اگه bucket هنوز در backend یا services reference شده باشه، و تارگت فراموش کرده removeش کنه، ممکنه حتی RCE به دست بیاری. در بعضی موارد، میتونه به full system compromise منجر بشه. ⚡ ۳. پیدا کردن Bucketها (با استفاده از FOFA):  اینجا چطور با FOFA شکارشون میکنم: 🧠 FOFA Dork: body="specified bucket does not exist" && (host="target.com" || host="target_domain_name_only") && port="443" 🔍 این dork subdomainهایی رو میده که به bucketهای missing یا deleted اشاره میکنن. FOFA fingerprints رو در سراسر وب index می‌کنه حتی برای منابع deleted پس goldmine برای پیدا کردن assetهای exposedی که تارگت فراموش کرده. ⚡ ۴. Validate کردن Ownership: 🔎 روش ۱: GitHub Recon  از GitHub dorkها مثل این استفاده کن: org:target_org "target.s3.amazonaws.com" یا ساده جستجو کن: "target.s3.amazonaws.com" ممکنه hardcoded linkها، past commitها یا config fileهایی پیدا کنی که اثبات کنه تارگت از این bucket استفاده میکرده. 🌐 روش ۲: DNS History (همیشه موثر نیست، اما ارزش امتحان داره)  چک کن اگه bucket برای static website hosting configure شده بوده. از این ابزارها برای چک historical DNS records استفاده کن: https://securitytrails.com  https://dnsdumpster.com  https://viewdns.info  https://www.robtex.com  اگه DNS leak یا CNAME recordهایی پیدا شد، analyzeشون کن تا proof of ownership بسازی. 🎯 پس بچه‌ها، امیدوارم از خوندن این قطعه کوچیک متدولوژی لذت برده باشین.  کدوم FOFA dork رو برای S3 takeover تست کردی که subdomain dangling شکار

🚨 الان همه اطلاعات حساس و لو رفته‌ تون رو از اینترنت پاک کنید. ۲۰ ساله که پروفایل میسازید، سایت میرید و رد پای دیجیتال به جا میذارید. همه‌ ش رو تو ۲ دقیقه پاک کنید: ↓↓ https://x.com/KavehxNet/status/2104090338293846369

CVE یعنی چی؟ احتمالاً وقتی درباره یک آسیب‌ پذیری میخونی، اولین چیزی که میبینی یک شماره شبیه اینه: CVE-2020-XXXX اما یک اشتباه رایج وجود داره: اCVE داشتن یک مشکل، لزوماً به این معنی نیست که با یک Vulnerability واقعی طرفیم. اCVE مخفف Common Vulnerabilities and Exposures هست. در عمل، CVE یک شناسه یکتا برای یک مشکل امنیتی گزارش‌ شده است. این سیستم توسط یک ساختار فدرال از سازمانها و Vendorهای مختلف مدیریت میشه و برای هماهنگ‌ کردن ارجاع به آسیب‌پذیری‌ ها استفاده میشه. اما اینجا یک نکته مهم وجود داره. هر چیزی که CVE بگیره، الزاماً از نظر فنی یک آسیب‌ پذیری قابل‌استفاده نیست. دو مثال جالب بررسی شده: CVE-2020-19909 در curl و CVE-2020-21469 در PostgreSQL در این موارد، درباره اینکه آیا واقعاً یک Security Vulnerability محسوب می‌ شن یا نه، اختلاف نظر وجود داشته. دلیلش اینه که صرفاً وجود یک رفتار غیرمنتظره یا حتی یک مشکل نرم‌افزاری کافی نیست. باید ببینیم آیا این مشکل واقعاً میتونه باعث یک Security Impact بشه یا نه. اینجاست که بحث پست قبلی دوباره مهم می‌ شه: Bug ≠ Vulnerability پس وقتی یک CVE میبینی، فقط به Severity یا عدد CVSS نگاه نکن. اول بفهم: چه چیزی آسیب‌ پذیره؟ اتکر چه دسترسی‌ ای داره؟ چه چیزی میتونه Trigger بشه؟ و در نهایت چه Security Impactی ایجاد می‌ شه؟ یک شماره CVE به‌ تنهایی تحلیل امنیتی انجام نمیده. کار Researcher اینه که پشت اون شماره رو بفهمه. 📌 نکته این قسمت: اCVE یک Reference است، نه جایگزین تحلیل فنی. در Vulnerability Research باید از خود مشکل شروع کنی، نه از عدد CVE. @PfkSecurity #از_روز_صفر_تا_زیرو_دی #VulnerabilityResearch #CVE #ZeroDay #CyberSecurity #RedTeam