📌دوره : THB OSINT Fundamentals

اوسینت (OSINT) صرفاً جست‌وجو در Google نیست؛ بلکه فرآیندی برای جمع‌ آوری، تحلیل و اعتبارسنجی اطلاعات عمومی و تبدیل آنها به شواهد قابل اتکاست.

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

🎯 تمرکز دوره بر روش تحقیق، تفکر تحلیلی و Workflow واقعی OSINT است؛ نه صرفاً معرفی مجموعه‌ای از ابزارها.

تمام مباحث و تمرین‌ ها در چارچوب قانونی و اخلاقی ارائه میشوند و دوره وارد هک، فیشینگ، سرقت حساب، استخراج اطلاعات خصوصی یا Doxxing نمیشود.

📌 در این ویدئو، مدرس دوره مسیر آموزشی و محتوای THB OSINT Fundamentals را معرفی می‌کند.

👤 مدرس : مهدی حسینی
📄 سرفصلهای دوره
⭕️ نحوه برگزاری دوه : آفلاین
🔥 دارای گروه پشتیبانی در تلگرام
⏳ مدت زمان دوره : 30 ساعت
💰 قیمت : ۱,۴۹۰,۰۰۰ تومان
💢 خرید برای 5 نفر اول به قیمت : ۹۹۰,۰۰۰ تومان

📌 جهت خرید،به ایدی زیر پیام دهید:
@ThbxSupport

@TryHackBox

مهارت‌های Claude Code برای پشتیبانی از مهندسی معکوس برنامه‌های اندروید.

https://github.com/SimoneAvogadro/android-reverse-engineering-skill

@AiTHB

📚 بازخورد یکی از خواننده‌های «Kerberos For Pentesters»

ممنون از اعتمادتون ❤️

هدف TryHackBox اینه که محتوا واقعاً در مسیر یادگیری و کار عملی به دردتون بخوره.

📌 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 جدید با رویکرد یک متخصص تست نفوذ است.

🎓 مدرس: مهندس محمد طاهری
🗓 تاریخ شروع: ۱ مهر ۱۴۰۵
💻 نحوه‌ی برگزاری: آنلاین
🎓 سطح: مقدماتی
💰 ارزش دوره: ۵,۹۰۰,۰۰۰ تومان
💰 قیمت استاندارد: ۳,۹۸۹,۰۰۰ تومان
📦 این دوره شامل نسخه‌ی آفلاین کامل و عضویت در گروه پشتیبانی است.

🎥 ویدئوی معرفی

📚 سرفصل‌ ها

📄 توضیحات تکمیلی

🔥 شیوه‌ ی یادگیری

👤 لینکدین مدرس

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

بخش اول | بخش دوم | اطلاعات بیشتر

📌 جهت ثبت‌نام یا کسب اطلاعات بیشتر:
@ThbxSupport

@TryHackBox

تابستون هم تموم شد...

این تابستون واقعاً چی یاد گرفتید که قبلش بلد نبودید؟

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

Android 1-Day Exploit با کمک LLM

یک سؤال جالب اینجا مطرح می‌شود:
آیا یک LLM می‌تواند فقط با داشتن Patch Diff و توضیح عمومی یک CVE، خودش را به یک 1-day exploit واقعی برساند؟

یک پژوهشگر این موضوع را روی Pixel 6a امتحان کرده و نتیجه، حداقل جالب است.
کار از مقایسه دو نسخه از Google Factory Images شروع شد. مدل binaryها را با هم مقایسه کرد، componentهایی که احتمالاً patch شده بودند را جدا کرد و بعد سراغ reverse engineering رفت.
در ادامه تغییرات function-level با CVEهای منتشرشده تطبیق داده شدند.

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

CVE-2026-56942
Component: BigWave
Function: ReadTileInfo
Source: vp9hwd_headers.cc

توضیح عمومی CVE به یک Out-of-Bounds Write ناشی از نبودن bounds check اشاره می‌کند.
با بررسی patch، یک تغییر مشخص در کد پیدا شد که احتمالاً همان fix مربوط به آسیب‌پذیری بود.
اینجا کار وارد مرحله جالب‌تری شد.
LLM اول از نوشتن exploit خودداری کرد. اما researcher یافته‌ها و فرضیه‌های به‌دست‌آمده از reverse engineering را به GLM-5.3 منتقل کرد.

نتیجه؟

اGLM-5.3 توانست یک 1-day exploit توسعه دهد که روی یک Pixel 6a واقعی با نسخه آسیب‌پذیر اجرا شد.
هزینه این کار هم کم نبود:

• حدود 12 میلیون
token
• 4492 tool call

• حدود 6 ساعت پردازش
• حدود 38 دلار هزینه
• یک MCP اختصاصی برای reverse engineering

این آزمایش لزوماً به این معنی نیست که LLMها جای exploit developerها را گرفته‌اند.
اما یک چیز را خیلی واضح نشان می‌دهد:

اگر مدل به binary diff، reverse engineering، patch analysis و ابزارهای مناسب دسترسی داشته باشد، می‌تواند بخش قابل‌توجهی از مسیر vulnerability research را خودش جلو ببرد.
شاید سؤال مهم دیگر این نباشد که:
«آیا AI می‌تواند exploit بنویسد؟»
بلکه این باشد:
وقتی مدل‌ها بهتر شوند، تبدیل یک CVE عمومی به یک 1-day واقعی چقدر سریع‌تر و ارزان ‌تر می‌شود؟

@AiTHB

📌 راهنمای کامل SAML Vulnerabilities

از Signature Wrapping (XSW) تا XSLT و Token Recipient Confusion؛ ۹ تکنیک حمله روی SAML، هرکدوم با توضیح فنی، تأثیر امنیتی و یه Lab تمرین عملی برای اجرا توی محیط خودت.

اگه با SSO و Identity Provider سروکار داری، این آموزش رو از دست نده.

دانلود کن و شروع کن به تمرین

🆔 @TryHackBox
Github | Linkedin | YouTube | Instagram | Other

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

🔥 چک‌ لیست امنیت هوش مصنوعی

@TryHackBox
#چک_لیست #هوش_مصنوعی

یه آپدیت درباره Reconner
نسخه v3.2.0 منتشر شد (آخرین نسخه پایدار).
تمرکز اصلی این سری از نسخه‌ها (از v3.0 به بعد) روی پایداری واقعی، درستی نتایج و کیفیت فایندینگ‌ها بوده، نه فقط اضافه کردن فیچرهای سطحی.
مهم‌ترین تغییرات و بهبودها:
رویکرد Verification-first کامل‌تر شده؛ کاندیداها از فایندینگ‌های تأییدشده جدا نگه داشته می‌شن و فقط سیگنال‌های قوی با مدرک (مثل browser proof و differential) به confirmed می‌رسن
پوشش و کیفیت XSS خیلی قوی‌تر شده (browser-proven XSS coverage + بهبودهای موتور XSS در v3.2.0)
بهبود کیفیت اسکنر و pipeline کلی (از v3.1.0 به بعد)
تمام ماژول‌های اسکجولر قرارداد مشخص دارند؛ فازها دیگه تمیز دروغین گزارش نمی‌شن (blocked / failed / timed_out و ...)
پایداری سرویس، مدیریت دیتا، آپدیت بدون قطع اسکن فعال و تجربه کاربری (از جمله موبایل) بهتر شده
همچنان همه چیز داخل ماشین خودت می‌مونه و toolchain کامل داخل یک ایمیج داکر هست
لینک ریپو:
https://github.com/rootdr-backup/Reconner
اگر از ابزار استفاده می‌کنید و براتون مفید بوده، با Star دادن حمایت معنوی کنید. این کار واقعاً انرژی می‌ده برای ادامه توسعه.
برای حمایت مالی هم که کمک مستقیم به سرعت توسعه و نگهداری پروژه‌ست:
https://daramet.com/RootDR
هر ایده‌ای داشتید، مشکلی پیدا کردید، فالس‌پازیتیو / میس‌فایندینگ / دابلیکیت دیدید یا اصلاحی مدنظرتون بود، همین زیر یا با ایشیو در گیتهاب بگید. همه فیدبک‌ها خونده می‌شه و روی مسیر توسعه تأثیر داره.
مخلص.

🔥 با 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

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

@ThbxSupport

پورت 23 Telnet :

کاملاً بدون رمزنگاری. نام کاربری، پسورد و تمام دستورات به صورت متن ساده ارسال میشن ..

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

#ردتیم

📌 وقتی یک Vulnerability پیدا کردی، باید بدونی چه چیزی در خطره

فرض کنیم یک ضعف امنیتی پیدا کردی.
اینکه بگی: «این یک Vulnerability هست»

برای یک گزارش خوب کافی نیست.
باید بتونی توضیح بدی این ضعف چه اثری روی سیستم میذاره.
اینجا سه مفهوم خیلی مهم وارد ماجرا میشن:

Confidentiality
Integrity
Availability

همون چیزی که معمولاً بهش میگیم:

CIA Triad

🔹 Confidentiality
یعنی مهاجم بتونه به اطلاعاتی دسترسی پیدا کنه که نباید بهش دسترسی داشته باشه.

مثلاً:

یک Vulnerability باعث بشه کاربری که فقط باید اطلاعات خودش رو ببینه، بتونه اطلاعات کاربران دیگه رو هم بخونه.
اینجا مشکل اصلی Confidentiality هست.

🔹 Integrity
یعنی مهاجم بتونه چیزی رو تغییر بده که نباید قادر به تغییرش باشه.
مثلاً یک ضعف باعث بشه کاربر معمولی بتونه فایل‌ های حساس سیستم رو تغییر بده.
اینجا بحث Integrity مطرحه.

🔹 Availability
یعنی مهاجم بتونه دسترسی به سیستم یا سرویس رو مختل کنه.
مثلاً یک ورودی خاص باعث بشه سرویس Crash کنه و کاربران دیگه نتونن ازش استفاده کنن.
اینجا Impact روی Availability قرار می‌گیره.

🔥 یک نکته مهم

این سه مورد فقط اصطلاحات تئوری برای حفظ کردن نیستن.
وقتی یک Vulnerability پیدا میکنی، باید بتونی بگی:

«این ضعف دقیقاً چه چیزی رو تحت تأثیر قرار میده؟»

مثلاً اگر یک Vulnerability به مهاجم اجازه بده یک فایل دلخواه روی سیستم بنویسه، اولین چیزی که تحت تأثیر قرار گرفته Integrity هست.

اما نباید صرفاً بر اساس اسم Vulnerability درباره Impact تصمیم بگیری.

باید ببینی در Target واقعی چه اتفاقی می‌ افته.

این طرز فکر بعداً موقع نوشتن PoC، Vulnerability Report و Impact Assessment خیلی به کارت میاد.

@PfkSecurity

#از_روز_صفر_تا_زیرو_دی #VulnerabilityResearch #ZeroDay #CyberSecurity

🔖 دورک‌ های باگ بانتی

https://dorkking.blindf.com/

شما چه دورک هایی استفاده میکنید ، کامنت کنید

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

📚 بازخورد یکی از خواننده‌های «شکار عملی باگ بانتی»

ممنون از اعتمادتون ❤️

هدف 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 شکار کرد؟ تجربت رو کامنت کن.

@TryHackBox
#دورک #باگ_بانتی

⭕ سری چالش های SE : هک انسان 2/20

📌 چالش: «مدیر در جلسه است»

سناریو:

شما در حال انجام یک Social Engineering Assessment برای شرکت فرضی Datanova هستید.
هدف شما «آقای رضایی»، کارمند واحد مالی است.

شما از قبل می‌ دانید:

◾ مدیر واحد مالی، «اقای فریدونی»، امروز جلسه دارد.
◾ واحد مالی برای ارسال گزارش ماهانه از یک سامانه داخلی استفاده می‌ کند.
◾ ساعت ۱۰:۳۰ معمولاً زمان شلوغی واحد مالی است.
◾ چند نفر از کارکنان واحد IT را از صفحه LinkedIn شرکت شناسایی کرده‌اید.

شما با یک Pretext مشخص با اقا رضایی تماس می‌ گیرید و خودتان را به‌ عنوان یکی از کارکنان IT معرفی میکنید.

اما این بار هدف مستقیماً گرفتن Password نیست.


🎯 هدف: متقاعد کردن کارمند برای انجام یک اقدام حساس در سامانه، بدون اینکه هویت شما را به‌صورت مستقل Verify کند.

❓ سؤال چالش:

اگر شما Social Engineer بودید:
۱. از چه Pretextی استفاده میکردید؟
۲. چطور از Authority و Urgency استفاده میکردید؟
۳. چه اطلاعاتی را قبل از تماس جمع‌ آوری میکردید؟
۴. چه نشانه‌ هایی باعث میشد کارمند متوجه حمله شود؟
۵. اگر شما مدافع Datanova بودید، چه Controlهایی برای جلوگیری از این حمله طراحی میکردید؟



@TryHackBox
#مهندسی_اجتماعی

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

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