دعوت به همکاری | UI/UX Designer

برای توسعه و تکمیل یک پروژه واقعی و در حال رشد در حوزه امنیت سایبری (Cyber Security)، به یک نیروی UI/UX Designer خلاق، مسئولیت‌ پذیر و علاقه‌مند به کار تیمی دعوت به همکاری میکنیم.

اگر در زمینه طراحی UI/UX فعالیت دارید و علاقه‌مند هستید روی یک محصول واقعی و قابل ارائه در رزومه و Portfolio کار کنید، خوشحال میشویم با شما آشنا شویم.

مزایای همکاری

🔹 فعالیت روی یک پروژه واقعی و قابل ارائه در رزومه
🔹 امکان ثبت تجربه همکاری در Portfolio
🔹 فرصت ارائه ایده و مشارکت در تصمیم‌ های طراحی محصول
🔹 تجربه همکاری با اعضای تیم در حوزه‌های Cyber Security و Software Development
🔹 فرصت یادگیری و توسعه مهارت‌ های تخصصی در یک محیط فنی
🔹 امکان ادامه همکاری و ایجاد فرصت‌ های بیشتر در صورت موفقیت همکاری
🔹 فضای کاری دوستانه، حرفه‌ای و تیم‌محور

شرایط موردنظر

آشنایی با Figma و اصول طراحی UI/UX، طراحی Responsive، User Flow و طراحی محصول از مهارت‌های موردنظر ماست.

تسلط کامل بر تمام موارد الزامی نیست؛ انگیزه، مسئولیت‌پذیری، خلاقیت و علاقه به یادگیری برای ما اهمیت زیادی دارد.

📩 اگر علاقه‌مند به همکاری هستید، از آیدی زیر با ما در ارتباط باشید:
@ThbxSupport

در صورت امکان، نمونه‌کارها یا Portfolio خود را نیز ارسال کنید.

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

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

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

ا🎫 Silver Ticket تفاوتش با Golden Ticket چیه؟

خیلی وقت‌ ها اسم Golden Ticket و Silver Ticket رو کنار هم میشنویم.
ولی این دوتا دقیقاً یک چیز نیستن ، تفاوت اصلیشون توی اینه که مهاجم با چه Keyای Ticket رو جعل میکنه و در نهایت قراره به کجا دسترسی بگیره.

در Golden Ticket:
KRBTGT Key
⬇️
Forged TGT
⬇️
Service Tickets

یعنی مهاجم به Key مربوط به KRBTGT دسترسی داره و میتونه یک TGT جعلی بسازه.


اما در Silver Ticket داستان فرق میکنه:

Service / Computer Account Key
⬇️
Forged TGS
⬇️
Target Service

اینجا مهاجم TGT رو جعل نمیکنه.
مستقیماً یک Service Ticket یا همون TGS جعلی برای یک سرویس مشخص میسازه.
مثلاً سرویس‌هایی مثل:
🔹 CIFS
🔹 HTTP
🔹 HOST
🔹 MSSQLSvc

بعد Ticket برای همون Target Service استفاده میشه.

حالا از دید Detection یک نکته جالب داریم.
فرض کن روی یک Server یک Kerberos Logon در Event ID 4624 میبینیم.

ولی وقتی میریم سراغ Domain Controller، برای همون User، Source و Service یک 4769 منطقی پیدا نمیکنیم ،این میتونه مشکوک باشه.

ولی هنوز نمیتونیم بگیم:
«خب، پس حتماً Silver Ticket داریم.»
چرا؟
چون ممکنه Ticket قبلاً صادر شده باشه و از Cache استفاده شده باشه ، یا اصلاً Logها کامل نباشن.

پس بهتره فقط روی یک Event تمرکز نکنیم.
باید ببینیم بعد از Authentication چه اتفاقی افتاده.

مثلاً:

4624
⬇️
4672
⬇️
5140 / 5145
⬇️
4688
⬇️
WinRM / RDP / WMI / SQL / Service Activity

حالا یک قدم هم برگردیم عقب ، خود Service Account رو بررسی کنیم.

چندتا SPN داره؟
چه Privilegeهایی داره؟
اPassword یا Credential اون چقدر امنه؟
آیا همین Account برای چند Service استفاده شده؟

📌 این قسمت مهمه

چون یک Service Account ضعیف، مخصوصاً اگر Privilege بالایی هم داشته باشه، میتونه تبدیل به یک نقطه خیلی جدی برای ادامه Attack Chain بشه.

اگر بخوام خیلی خلاصه تفاوت این دوتا رو بگم:

🎫 Golden Ticket
KRBTGT Key → TGT → Domain-wide potential

🎫 Silver Ticket
Service Key → TGS → Specific Service

و از سمت دفاع هم داستان فقط Detection نیست.

اService Accountها باید تا جای ممکن Passwordهای طولانی و تصادفی داشته باشن.
استفاده از gMSA میتونه کمک بزرگی باشه.

اPrivilegeهای اضافه هم باید از این Accountها گرفته بشه.

و روی Target Serverها هم باید Telemetry مناسبی داشته باشیم تا بتونیم رفتار مشکوک بعد از Authentication رو ببینیم.

در Active Directory خیلی وقتها خود Ticket مشکل اصلی نیست.

مشکل اینه که پشت اون Ticket چه Keyای قرار داره و اون Key به چه سرویس‌ هایی دسترسی میده.

@KavehOffSec
#ActiveDirectory #SilverTicket #Kerberos #RedTeam

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

🛡️ SAML SECURITY SERIES | PART 02

🎫 Signature Wrapping
وقتی Signature معتبره، ولی Application چیز دیگه‌ای رو میخونه!

در قسمت قبل گفتیم یکی از اولین چیزهایی که در بررسی یک SAML Implementation باید بهش توجه کنیم، Signature Validation هست.

حالا بریم سراغ یکی از معروف‌ ترین مشکلات امنیتی SAML:

XML Signature Wrapping یا XSW

اسمش شاید کمی پیچیده به نظر برسه، ولی ایده‌ی اصلیش خیلی ساده‌ تره.
فرض کنید یک SAML Response داریم.
داخل این Response یک Assertion وجود داره.
روی این Assertion هم یک Digital Signature قرار گرفته.

اپلیکشن باید مطمئن بشه که:
ا🔐 Signature واقعاً معتبره.
📄 داده‌ای که Signature روی اون قرار گرفته، همون داده‌ایه که باید بررسی بشه.

📌 در نهایت، همون Assertion وارد فرآیند Authentication میشه.

حالا مشکل کجاست؟
وقتی بین چیزی که Signature شده و چیزی که Application پردازش میکنه ارتباط درستی وجود نداشته باشه.

در بعضی پیاده‌سازی‌ های آسیب‌پذیر، مهاجم میتونه ساختار XML رو طوری تغییر بده که Signature همچنان معتبر باقی بمونه.
اما Application در ادامه، Node یا Assertion دیگری رو پردازش کنه.

یعنی:
اSignature معتبره.

اما چیزی که Application بهش اعتماد میکنه، لزوماً همون چیزی نیست که Signature شده.
به زبان ساده تر هم که :

Signed Data ≠ Processed Data

و دقیقاً همینجا مشکل امنیتی شکل میگیره.
بسته به Implementation و شرایط موجود، این مسئله میتونه به موارد زیر منجر بشه:

🔹 Authentication Abuse
🔹 Privilege Escalation
🔹 Identity Validation Bypass

اما یک نکته مهم دیگه هم وجود داره.

اXSW فقط یک تکنیک واحد نیست.
برای این حمله Variantهای مختلفی وجود داره که معمولاً با نام‌ های XSW1 تا XSW8 شناخته میشن.

تفاوت این Variantها عمدتاً به نحوه‌ی قرار گرفتن و پردازش Nodeهای XML مربوط میشه.

🎯 حالا سؤال:

اگر یک SAML Response داشته باشیم و Signature اون کاملاً معتبر باشه، آیا میتونیم با اطمینان بگیم Authentication امنه؟

یا باید بررسی کنیم که:
اپلیکشن دقیقاً کدوم Node رو بعد از Validation پردازش میکنه؟

اگر جای یک پنتستر بودید، چطور مطمئن می‌شدید:

اSigned Data همون Processed Data هست؟

نظرتون رو بنویسید 👇

@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

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

🌐 Web Pentesting | Field Notes - #02

SQL Injection را با SQLmap شروع نکنید

یکی از رایج‌ ترین اشتباه‌ها در تست نفوذ وب این است که پنتستر به یک پارامتر میرسد و بلافاصله ابزار را اجرا می‌ کند؛ منتظر میماند تا SQLmap اعلام کند «Vulnerable».

پیش از آن‌که حتی یک ابزار را اجرا کنید، باید دقیقاً بدانید به دنبال چه چیزی هستید.
فرض کنید به این درخواست رسیده‌اید:

GET /products?id=42

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

سپس ورودی را تغییر دهید و رفتار برنامه را با حالت عادی مقایسه کنید.

اگر با تغییر مقدار id، پاسخ به شکل قابل‌ توجهی دگرگون شود، این دیگر یک تغییر ساده نیست؛ یک سیگنال است.

در این نقطه باید فرضیه بسازید:
«ممکن است این پارامتر در یک کوئری پایگاه‌داده استفاده شود.»

حالا تست واقعی آغاز می‌شود.
و اینجا یک نکتهٔ حیاتی وجود دارد:
اSQL Injection لزوماً قرار نیست خطای زیبا و واضحی روی صفحه نشان دهد.

در Blind SQL Injection ممکن است:
هیچ خطای پایگاه‌داده‌ای نبینید.
هیچ داده‌ای مستقیماً برنگردد.
و حتی پاسخ ظاهراً کاملاً عادی به نظر برسد.

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

پس وقتی خروجی واضحی ندارید، سؤال درست این نیست که:

«چه پیلود دیگری بزنم؟»

سؤال درست این است:
«چه چیزی را میتوانم اندازه‌گیری و مقایسه کنم؟»

پاسخ؟
رفتار بولین؟
طول پاسخ؟
زمان پاسخ‌دهی؟
محتوا؟

اینجاست که مرز میان یک جمع‌ کنندهٔ پیلود و یک پنتستر وب واقعی مشخص میشود.

اSQLmap ابزار فوق‌العاده‌ای است.
اما قرار نیست به‌جای شما برنامه را بفهمد.
شما باید فرضیه بسازید؛ ابزار فقط باید فرآیند تحقیق را سریع‌تر کند.

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


@TryHackBox

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

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

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

📌 استفاده از ماشین‌های مجازی برای بایپس کردن ابزارهای امنیتی

📌 مهاجمان همچنان به آزمایش با پلتفرم‌ های مختلف مدیریت از راه دور

📌 مینی دوره #رایگان نصب و راه‌اندازی لابراتورهای تست نفوذ وب قسمت اول

📌 فکر می‌کنید، 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+

🔥 #باگ_بانتی فکر کنم این یکی برای بیشتر باگ‌ هانترها آشنا باشه

چند ساعت روی یه مورد وقت میذاری، مطمئنی یه آسیب پذیری پیدا کردی، حتی سناریوی Exploit رو هم تو ذهنت کامل کردی بعد آخرش میفهمی یا Out of Scope بوده، یا اصلاً آسیب پذیری محسوب نمیشده.

برای خیلیا False Positive بیشتر از چیزی که انتظار داشتن اتفاق افتاده.

برای شما چطور؟ بیشتر با Duplicate مواجه میشید، Out of Scope، False Positive یا باگی که در نهایت Impact قابل‌ توجهی نداره؟

اگه تجربه جالبی داشتید، بدون اشاره به اسم تارگت برامون بنویسید.

لینک گروه جهت مشارکت :

https://t.me/+XPV3S0tygl1lZGE0

TryHackBox | Ai Sec | Radio | RoadMap

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