ليوم أشارك ايجنت بسيط كنت استخدمه وهو اتمتة عملية اصطياد الثغرات bug bounty مع ذكاء اصطناعي يحلل النتائج بشكل بسيط. - الهدف من الايجنت: تقليل الوقت الضائع بين الأدوات، وتقليل النتائج غير المفيدة. - الفكرة بسيطة: تشغل أمر واحد، وتحصل على تقرير جاهز. كيف تمشي العملية 1) Recon تجميع الـ subdomains من: subfinder، assetfinder، crt.sh، C99 ثم استخراج URLs وملفات JS وparameters عبر waybackurls وkatana 2) Scanning (بالتوازي) تشغيل الأدوات الأساسية دفعة واحدة: httpx → تحديد الـ live hosts nuclei → CVEs، misconfigs، takeovers CORS engine → مدمج ffuf → مسارات مخفية و admin panels dalfox → XSS PoC arjun → parameters مخفية nmap → open ports SQLi engine → مدمج 2.5) JavaScript Analysis تحليل ملفات JS باستخدام Regex AI لاستخراج: API keys (AWS / GitHub / Stripe) JWT tokens endpoints داخلية DOM XSS hardcoded secrets 3) AI Validation كل نتيجة يتم تقييمها: هل هي حقيقية أو false positive تحديد مستوى الخطورة توليد PoC كتابة impact remediation 4) Report تقرير Markdown جاهز يحتوي على: Executive Summary Risk Score تفاصيل كل ثغرة مع الدليل والـ PoC - مميزات تقنية مبنية بـ Go (سرعة وتنفيذ متوازي) تدعم: DeepSeek، Claude، OpenAI، OpenRouter تقليل فعلي للـ false positives مرونة في التشغيل: --js-only --skip-recon --skip-scan الفكرة قابلة للتطوير .. المشروع مفتوح المصدر على GitHub للاستخدام في البيئات المصرح بها فقط github.com/Btr4k/bugbounty-a…

الربع الاول من 2026 كشف لنا باحثيين متميزين جدد في @BugBountySA ، جميل ان نرا متميزين سعوديين نفخر بهم .

Hello, the agent found multiple XSS on an open source project on GitHub i deployed it locally on Docker and set up one account. After the agent found the XSS, I told him to write the steps he followed to be shared with everyone. It was an interesting one how he navigated the website step by step and linked the pieces together to achieve an exploit Whenever I find any interesting results, I'll make sure to share them. Finding Stored XSS in a CMS — An Automated Agent's Approach TLDR - Target: a modern CMS using Vue.js frontend - Found 2 stored XSS in 22 minutes (157 tool calls) - Root cause: asset title rendered via v-html without escaping - Impact: session hijacking (no HttpOnly cookie), admin takeover How It Went 1. Logged in, checked headers — no CSP, no HttpOnly on session cookie. Vue.js frontend means auto-escaping by default, so I needed to find where the app opts out. 2. Downloaded all JS files and grepped for dangerous sinks: innerHTML, v-html, insertAdjacentHTML. Most were sanitized or safe. One file stood out — the asset field renderer built raw HTML with template literals and fed it into v-html. 3. Tested many surfaces that did NOT work: model names, content fields, WYSIWYG editor, login redirects, API errors, color/tag fields — all escaped or stripped. 4. Found the gap: asset titles go into the render function unsanitized. Uploaded a text file, set the title to `<img src=x onerror=alert(2)>` (29 chars, fits the 30-char truncation limit). Linked it to a content item. Visited the items list — alert fired. 5. Confirmed impact: document.cookie is readable (no HttpOnly), no CSP blocking inline scripts. Any user with asset permissions can plant the payload, and it fires when any admin views the page. Key Takeaways 1. Source code analysis beats blind fuzzing — reading JS files and finding the exact sink saved hours. 2. v-html is the Vue XSS keyword — every v-html that touches user data is a potential bug. 3. Template literals are just string concatenation — they do not escape HTML. 4. Asset metadata is an overlooked input surface — most testers focus on content fields and URL params. 5. Truncation is not sanitization — 29 characters is plenty for an XSS payload. #BugBounty #AgenticAI #InfoSec

Building a custom SSL pinning bypass for Android no Frida, no LSPosed, no Xposed pure native approach loaded via Zygisk works on banking apps Some RASP solutions still detect the module working on fixing that Happy to share once it's polished #arm64 #android #bugbounty

كيف قدرت اكتشف ثغرات حرجة في اكبر شركة توصيل للطعام؟ فوق ال 20,000$ 1- اختراق فوق ال380K الف مطعم 2- GraphQL Path Traversal Led to Modify Menu Price 3- سحب ارباح اي سائق في الشركه حياكم الله ان شاء الله تستفيدون. عند التعامل مع تارقت ضخم، اكبر خطأ هو انك تبدا مباشرة بالfuzzing او الريكون الغير مفهوم بدون فهم المنظومة. أول ما ركزت عليه هو اني افهم الـ Business Logic، لأن كثير من الثغرات الحرجة في المنتجات الكبيرة تكون منطقية اكثر. الشركة عندها اكثر من نوع مستخدم: عميل يطلب (Customer)، سائق يوصل (Couriers)، مطعم يستقبل (Restaurant). كل طرف له موقع وتطبيق خاص وAPIs مختلفه. عادة هذا يعني ان النظام معقد، ومع التعقيد تزيد الثغرات, وهذي افضل فرصة بالنسبة لك كبق هنتر انك تستعملهم كلهم عشان تطلع ثغره وهذا اللي صار. -1 Stealing Money Allowing Withdrawal Of Couriers To Attacker. $3,000 زي ماهو واضح بالعنوان قدرت اني استغل الثغرة هذي بحيث ان فلوس سواق الشركه تتحول للبطاقتي. بالبدايه بيجيكم تساؤل كيف قدرت القاها, للسواقين الشركه لهم تطبيق كامل قدرت اني ادخل على حسابي الي سويته وانا اتصفح التطبيق شفت شي غريب! لفت انتباهي وجود ميزة مالية حساسة: “Fast Cash”. الفكرة بسيطة السائق يقدر يسحب أرباحه مباشرة على بطاقته بدل ما ينتظر التحويل المعتاد. في اول ريكويست حاولت اسوي setup للمعلومات بطاقه بعدين جاني API غريب مربوط مع Stripe عشان توضح الصوره Stripe يسوي Tokenize للبطايق للشركه هذي ويحفظها بسيرفر خاص ويعطي بطاقتك unique ID بحيث انها تكون محميه وهذا دايقرام بسيط يشرح الي يصير زي ماهو موضح بالريسبونس عطانا توكن ايدي بناء على البطاقه طيب لو مشينا على الفلو حق التطبيق بنلاحظ الريكويست الثاني غريب جدا.

كيف قدرنا نكتشف ثغرة؟ 🔴Chaining Fortinet WAF Bypass and Microservice Architecture Exploitation to Compromise 6 Internal Domains With @Mohnad @stuipds مساكم الله بالخير جميعا , مقالة اليوم عن استغلال عدة ثغرات وصلنا من خلاله بتحكم كامل على احد اكبر الشركات - بيانات 40 ألف موظف وشركات متعاقدة (بكامل التفاصيل) - فصل أي موظف وإغلاق بصمة الوجه وبطاقات الدخول للفروع - Fortinet WAF bypass through path Confusion - Microservice Compromise Lateral Movement to 10 Internal Domains # البداية في بداية فحصنا طلعنا عدة ثغرات، وبعد وقت من الفحص صادفنا Error والواضح من الخطأ إنه قاعد يستقبل الـ username كبراميتر ويحطه بالـ URL path الى Internal domain فالي قاعد يصير إنه يستقبل المدخل من المستخدم، والـ front-end API يرسل طلب والـ back-end API يأخذ القيمة ويحطه بالمسار، ومن خلاله يرجّع معلومات المستخدم. وبديهي أول سؤال بيجي ببالك هل ممكن نشوف معلومات شخص آخر؟ والإجابة ايه بمجرد ما نسوي path traversal راح نتخطى عملية التحقق الي تكون من ال front-end API ونجيب معلومات أي مستخدم بشكل كامل لكن هذا ما يهمنا، كان هدفنا الأساسي إننا نوصل إلى Internal domain وبعد عدة محاولات، توصلنا إلى إننا نوصل إلى مسار داخلي ويحتوي على Swagger Documentation تحتوي على مسارات لأكثر من عملية. ومن خلال المسارات اللي وصلنا لها، قدرنا نطلع ثغرات حرجة وكثيرة جدًا، مثل ما راح نستعرض لكم الحين (;

في #كاتشفاي نؤمن أن الأمن السيبراني يبدأ بالوضوح والتحكم. نقدّم خدمات اختبار الاختراق بجودة عالية وذلك عبر منصة متكاملة تتيح لك إدارة الاختبارات بسلاسة، ومتابعة التقدم بوضوح، والتحقق من المعالجات بكل سهولة لضمان أمان أنظمتك واستمرارية أعمالك بكل ثقة At #Catchify, we believe security starts with clarity and control. We deliver high-quality penetration testing through an integrated platform that simplifies pentest management, provides clear visibility, prioritizes risks intel, and validates fixes, helping organizations protect their systems with confidence #CatchifyPlatform #CyberSecurity #PenetrationTesting #OffensiveSecurity #SecurityPlatform #BusinessSecurity #ThreatIntelligence #SaudiTech

Finally, with @hw16, we managed to bypass the @Cloudflare mTLS protection after around 5 days of work. I'd like to share a few golden tips for bug bounty hunters who might face something similar in the future. But first, here's a quick summary: The target was a banking app with multiple security layers: • Heavy Frida detection mechanisms • Strong root detection • Google SafetyNet/Play Integrity checks • Runtime hooking detection • APK tampering protection (crashed immediately if repackaged/modified) At first, @fridadotre was detected and crashed the app on my device but strangely worked on another device even though both had the same Android version, root method, Frida server version, and architecture. After investigation, we discovered the app had anti-hooking detection that triggered when using aggressive Frida hooks on sensitive KeyStore operations. The Solution: We wrote a minimal Frida script that: 1. Passively monitored certificate operations without modifying behavior 2. Intercepted KeyManagerFactory.init() - the exact moment when mTLS certificates are loaded 3. Extracted the X.509 client certificate and RSA private key (4096-bit) 4. Encoded them using Android's Base64 encoder 5. Formatted as PEM files ready for use Found the mTLS certificate with a unique UUID-based alias in the Android KeyStore. The certificate was being dynamically loaded during the SSL handshake initialization Extracted Files: • client_cert.pem → Client certificate (valid for 2 years) • client_key.pem → RSA private key (PKCS#8 format) We then created a PKCS#12 bundle using OpenSSL to combine the certificate and key into a single file, which could be imported into various tools and browsers for testing or @Burp_Suite Key Takeaway: When facing anti-tampering mechanisms, be surgical hook only what you need, when you need it. Aggressive hooking triggers detection; passive monitoring flies under the radar. This was an awesome challenge and my first time encountering such strong ssl Pinning defenses Attached some image from the mobile api and frida output the certificates #bugbountytips #frida #Magisk #mtls

ريادة وطنية في الأمن السيبراني تعمل Catchify اليوم على تمكين منشآت المملكة من حماية أصولها الرقمية عبر نموذج عمل وطني مبتكر هو الأول من نوعه في الشرق الأوسط، قائم على الدفع عند تحقق النتائج (PayOnCatch)، لضمان عدالة وشفافية وكفاءة استثنائية. منصة موحدة، تجربة سلسة، وكفاءات وطنية تدعم استمرارية أعمالكم، وتمنحكم رؤية واضحة لاتخاذ قرارات استراتيجية آمنة بثقة. نحرص على تمكينكم بما يتوافق مع رؤية المملكة 2030 في تحقيق السيادة الرقمية وتعزيز اقتصاد المعرفة. لا خيار أمامكم سوى المستقبل الآمن. تواصلوا معنا اليوم لتكونوا شركاءنا في هذه الرحلة نحو حماية وطنية مستدامة. catchify.sa

كيف قدرت اخترق واتحكم سيرفر جهة حساسة بشكل كامل. مسيتم بالخير اليوم بتطرق لأحد الثغرات الي اكتشتفه والي كانت عبارة عن خطأ في nginx والي من خلاله وصلت الى RCE او تحكم كامل على سيرفر الجهة طبعا حرصا على هوية الجهة عدلت على السناريو بعض الشيء نسمي بالله ونتطرق للثغرة بشكل مختصر اثناء فحصي للجهة لاحظت شيء غريب والي هو انه بعض المسارات ترجع بيانات بالرغم ان المسار غير صحيح على سبيل المثال أحد المسارات الموجودة GET /static/main.js لكن اذا حذفت السلاش "/" مثل كذا GET /staticmain.js الي راح يصير بيرجع نفس الرد من السيرفر الأمر كان غريب والي بسببه فكرت وبحثت عن سبب التصرف الغريب هذا وبعد بحث واستنتاج عن السبب هذا اتضح لي انه عبارة عن خطأ في اعدادت Nginx, وعمر كيف الخطأ قاعد يصير؟ والسبب يرجع لغلطة في اعدادت nginx.conf ، (ملف اعدادات) وهذا يخلي السيرفر يستقبل المسار بشكل خاطئ وعشان تكون الصورة اوضح السيرفر كان يعامل staticmain.js/ كأنه static/main.js/ لأنه أول ما يشوف static/ يضيف / بعده بشكل مباشر وتصير /static/ بسبب alias operation الي قاعدة تصير بمجرد ماتكتب static/ راح يضيف / بعده بشكل مباشر وتصير /static/ فتصير كأنك كتبت static/main.js/ # استغلال الخطأ الى ثغرة حرجة وهذا الشي يفتح لنا باب لثغرة تسمى ب off-by-slash اللي تقدر من خلالها ممكن توصل لملفات حساسة. مافهمت عمر كيف ممكن الخطأ هذا يسببب بثغرة توصل الى ملفات حساسة؟ ممكن ماوضحت الفكرة للبعض لكن الحين بنعرف كيف الخطأ البسيط هذا يسبب بثغرة بحرجة وعشان تكون الصورة اوضح هذا مثال على الأعدادات المصابة الى nginx والصورة توضح إعدادات Nginx كانت معرفه alias على static/ بدون سلاش "/" بنهاية المسار ولكن بعملية ال alias او عملية تحويل المسار يتم تحويلة الى /static/ (يتم أضافة / بالنهاية وتصير القيمة /static/) فصار السيرفر أول ما يشوف أي مسار يبدأ بـ static/ يضيف بعده / بشكل تلقائي، فـ اذا ارسلنا /staticmain.js/ اعتبره كأنه داخل مجلد static ويفسّره على أنه static/main.js/. وهنا تصير ثغرة off-by-slash وهنا يصير الخطأ الفادح انه السيرفر يستقبل المسار بدون / بالنهاية لكن يتم اضافة / بعملية ال alias (عملية تحويل المسار) # استغلالي للثغرة والوصل الى RCE وتحكم كامل بالجهة بعد مافهمت وش قاعد يصير وكيف قاعد تتم العملية هذي بال server-side عرفت انه كان بأمكاني اطلع برا السياق المحدد بالمسار واوصل الى ملفات داخلية مافهمت عمر شلون تصير الطريقة؟ بما ان ال / يتم اضافته بعد static/ بشكل مباشر معناته يمدي نضيف /.. ونطلع من المسار المحدد ولأن عملية ال normalization تتم بعد URI rewriting via alias في nginx بالتالي من الممكن نوصل لملفات داخلية بأستغلال الخلل هذا ومالكم بالطويلة بعد مافهمت الي قاعد يصير اول شيء جاء ببالي اني اسوي fuzzing او تخمين مسارات بالشكل هذا static../FUZZ/ وسبب اني بسوي fuzzing بالشكل هذا static../FUZZ/ وليس كذا static/../FUZZ/ لأنه مثل ماشرحت فوق انه يتم اضافة / بشكل مباشر بعد static/ لذلك سويت fuzz بالطريقة هذي وفعلا بعد ماسويت fuzzing وصلت لعدة نتائج وأغلبه كان ملفات لأعدادات مافيها شيء حساس ولكن احد الملفات رجعت بيانات ولكن مب اي بيانات (; والي كانت تسرب الباسورد للأدمن مع اسم المستخدم ك clear-text! باللحظة هذي كانت فرحة قوية الى ان جربت أستعمل المعلومات بموقع الجهة ولكن للأسف ماكانت مسجلة. بعد العديد من المحاولات البائسة, فكرت انه ممكن يكون الحساب لخدمة داخلية فقط ولا أقدر استفيد منه لكن ماوقفت وحاولت اجيب اي login portal تخص الجهة بكل الطرق واجرب فيها المعلومات الي وصلت له. وفعلا بعد بحث ورا بحث, لقيت احد ال login portals من خلال google dorking وجربت ال Admin credentials والنتيجة؟ بالفعل قدرت ادخل ال Portal, والفرحة كانت بعد ما شفت ال Control Panel كان فيها Command shell غير الصلاحيات الحساسة الأخرى الي وصلت له يكفي Shell page as PoC (; والي من خلالة كنت قادر اتحكم بسيرفر الجهة بشكل كامل (;

Race Condition Led to Admin Takeover خطأ مبرمج سمح لنا نخترق حساب الادمن ! بالبدايه رجعت لكم بمقالة جديدة انا و @0xAbady قبل مانبدا اغلبكم اكيد عارف وش هو الrace condition بس الي اغلبه مايعرف انه فيه نوع اسمه time-of-check to time-of-use طيب بسم الله خلونا بالبدايه نشرحها تخيل إنك مبرمج كسلان او مستعجل، وجاك شغل لازم تتحقق فيه من صلاحيه المستخدم بدل ما تحط نظام تحقق (authorization) مضبوط، تسوي شي بسيط وسهل اسمه “time-of-check” وش تسوي؟ تروح للباك اند وتقول: “اوكي، اذا جاني طلب من ايميل اسمه victim@mail.com، خلني اشوف هل فعلاً هذا المستخدم سوى تسجيل دخول قبل شوي من خلال الوقت مابين ريكويست تسجيل الدخول وريكويست الOTP validation يتحقق بالtimestamp؟”. فاذا سجل دخوله فعلا، تقول: "تمام، خلني اسمح له" ممتاز طيب اغلبكم الحين يقول وين المشكله ياعبدالعزيز؟ المشكلة كلها هنا انك تحققت من الشرط، لكنك ما ربطتها بسيشن او توكن، فصار فيه وقت فاصل بين التحقق والاستخدام كذا صار ال"time of use" بكل اختصار السيرفر يسوي التحقق من شرط (زي ان المستخدم بدا تسجيل دخول)، لكنه ما يربط او يثبت ان نفس الشخص هو اللي يكمل العملية ف اي احد يلحق بسرعة ويكمل قبل المستخدم، يقدر ياخذ النتيجة كانها له وبرضو في حالتنا راح اشرح كيف استغليناها لصالحنا وهذا هو “Time Of Check To Time Of Use”