🛡️ Internal Network Penetration Testing – Demonstration Report

Student: Abhishek Kushwaha

University: Lovely Professional University
Task: Internal Penetration Testing Demonstration
Target IP: 210.89.61.59
Date: July 2025

🔍 Objective

To simulate and demonstrate an internal penetration testing process that identifies potential vulnerabilities
within an organization's internal network. This activity imitates an attacker who already has access to the
internal network (such as a disgruntled employee or someone who bypassed perimeter defenses).

Why it's important: - Internal pentesting helps identify weaknesses from the perspective of an insider. -
Tests network segmentation, internal authentication, unpatched services, and access control mechanisms. -
Helps the organization comply with security standards like ISO 27001, PCI-DSS, etc.

What it does: - Simulates real-world attack scenarios inside the corporate LAN. - Evaluates network
resilience from the inside-out. - Assesses organizational response capability against insider threats.

How it's done: - Using professional tools and manual testing. - Mapping internal hosts and identifying
services. - Exploiting vulnerabilities such as SQLi, weak auth, etc.

The goal is to: - Discover active hosts and services. - Probe for insecure configurations and unpatched
services. - Exploit vulnerabilities (like SQL Injection or SMB weaknesses). - Provide remediation steps to
strengthen the network's internal security.

🛠️ Tools Utilized

• Nmap – Port and service scanner

• Enum4linux – SMB enumeration
• Rpcclient – Windows RPC info gathering
• SQLMap – Automated SQL injection testing
• Hydra – Login brute-force tool
• Curl – Manual HTTP requests
• Gobuster – Web directory brute-forcing
• Nikto – Web vulnerability scanner
• Netcat – Banner grabbing
• Whois/Dig – Domain info
• Burp Suite (Community) – Web request interception
• Wfuzz – HTTP parameter fuzzing
• TestSSL.sh – SSL/TLS misconfiguration scanner

1
📡 Attack Demonstration

1. Network Discovery

Why: Identify internal live systems to scope the attack surface.

What: A ping sweep is used to discover all hosts that are online.
How: Performed a ping sweep using Nmap.

Command: nmap -sn 192.168.0.0/24

Result: Host 210.89.61.59 was found active.

2. Port & Service Scanning

Why: To understand what services are exposed by the discovered host. This information is crucial for
determining attack vectors.
What: Scans every port on the machine and detects service versions.
How: Full TCP scan with version detection.

Command: nmap -sC -sV -p- 210.89.61.59

Result: - HTTP (80)

- SMB (445)
- SNMP (161/UDP)

3. SMB Enumeration Attempt

Why: Misconfigured SMB services may reveal sensitive data like usernames, groups, shared files, or even
allow anonymous access.
What: Attempts to gather SMB information and accessible resources.
How: Used enum4linux and rpcclient to probe for null sessions.

Commands: enum4linux -a 210.89.61.59

rpcclient -U "" 210.89.61.59

Result: SMB rejected null sessions. No shares or usernames leaked.

Fix Recommendation: - Disable guest access - Require authentication - Use SMBv3 with signing enabled

2
4. SNMP Information Leakage

Why: SNMP is often left exposed and can provide device configurations and network layout data.
What: Attempts to extract SNMP banner or config data.
How: Used Nmap SNMP script.

Command: nmap -sU -p 161 --script=snmp-info 210.89.61.59

Result: SNMP was open/filtered. Confirmed potential info disclosure.

Fix: Disable SNMP or switch to SNMPv3 with strong authentication.

5. SQL Injection Testing

Why: SQL Injection (SQLi) is one of the most critical web vulnerabilities, enabling attackers to bypass
authentication or extract sensitive database content.
What: The login page parameter was suspected of being injectable.
How: Tested manually and via SQLMap.

Commands: curl "http://210.89.61.59/login.aspx?user=abc'"

sqlmap -u "http://210.89.61.59/login.aspx?user=abc'" --dbs

Result: SQLMap detected potential SQLi on the 'user' parameter.

Fix: - Use parameterized queries - Filter and sanitize input - Disable verbose SQL errors

6. Brute Force Login Page

Why: To detect weak or default credentials that might allow unauthorized access.
What: Used credential brute-forcing with Hydra.
How: Attempted brute force with sample wordlists.

Command: hydra -L users.txt -P passwords.txt http-get://210.89.61.59/login.aspx

Result: Login page accessible but brute-force failed due to wordlist error.

Fix: - Implement account lockout - Add CAPTCHA & rate limiting - Use multi-factor authentication (MFA)

7. Directory Brute Forcing

Why: Admin panels or backup files often hide in unlinked directories.

What: Attempted to discover these directories using web scraping and enumeration.
How: Manual analysis and intended Gobuster usage.

3
Commands: curl http://210.89.61.59 > index.html
grep -iE "admin|login|api" index.html

gobuster dir -u http://210.89.61.59 -w /usr/share/wordlists/dirb/common.txt -x aspx,php,txt

Fix: - Remove unused files/folders - Apply access controls - Use security through obscurity (not as primary
protection)

8. Nikto Web Scan

Why: Nikto helps detect web server misconfigurations and common vulnerabilities.
What: Scans for outdated software, unsafe headers, and test scripts.
How: Ran Nikto scan.

Command: nikto -h http://210.89.61.59

Result: - Server headers exposed - Possible sensitive directories

Fix: Patch the server, remove default/test directories, and configure secure HTTP headers.

9. HTTP Header Analysis

Why: Headers like CSP and X-Frame-Options protect against clickjacking, MIME sniffing, etc.
What: Manual inspection of HTTP response headers.
How: Intercepted using curl and browser DevTools.

Findings: - Missing X-Content-Type-Options - No Content-Security-Policy - X-Frame-Options absent

Fix: Add security headers via web server configs.

10. SSL/TLS Misconfigurations

Why: Weak encryption or deprecated protocols allow man-in-the-middle attacks.

What: Checks SSL/TLS settings for deprecated ciphers.
How: Used testssl.sh tool.

Command: testssl.sh 210.89.61.59

Result: Weak ciphers supported.

Fix: Enable strong TLS 1.2+ only and disable deprecated ciphers.

4
11. Fuzzing Input Fields

Why: Hidden or unvalidated input parameters can expose backend logic flaws or trigger unexpected
behavior.
What: Fuzzed login parameter for unhandled values.
How: Used Wfuzz.

Command: wfuzz -c -z file,/usr/share/wordlists/dirb/common.txt --hc 404 http://210.89.61.59/login.aspx?

FUZZ=test

Result: Found unhandled parameters.

Fix: Validate all inputs server-side. Disable unused GET/POST variables.

🧪 Additional Issues Identified

• Verbose SQL Errors: Pages revealed detailed SQL exceptions, helping attackers refine injections.
• Flat Network: All internal systems appear on same subnet.
• Lack of Detection: No IDS/IPS flagged the scanning attempts.

✅ Vulnerability Summary

Vulnerability Severity Fix Recommendation

SQL Injection Critical Use ORM frameworks, input validation

SNMP Info Leak High Disable or secure SNMP

Missing HTTP Headers Medium Apply best-practice headers

Weak Auth Mechanism High Lockouts, MFA, CAPTCHA

Verbose Error Msgs Medium Generic error pages

Flat Network Design Critical Network segmentation, VLANs

Directory Exposure Medium File cleanup, use robots.txt where applicable

💡 Organizational Recommendations

🔐 Secure Coding Practices

• Adopt frameworks with built-in SQL injection prevention.

• Conduct static code analysis and secure code review.

5
🌐 Network Infrastructure Improvements

• Apply firewall rules to limit lateral movement.

• Use subnetting/VLANs to segregate sensitive zones.
• Deploy Intrusion Detection Systems (IDS).

🛠️ Hardening Internal Services

• Disable SMBv1, configure SMBv3 with auth.

• Use strong SNMPv3 credentials.
• Remove unnecessary ports and services.

📋 Patch & Monitor Continuously

• Establish vulnerability management lifecycle.

• Log all failed login attempts and scan anomalies.
• Conduct regular automated vulnerability scans.

🧠 Human Factor & Awareness

• Train developers on OWASP Top 10.

• Encourage red team/blue team exercises.
• Review security policies periodically.

📄 Conclusion
The internal network assessment revealed several high-impact issues that, if exploited, could compromise
sensitive systems and data. From SQL injection vulnerabilities in the login form to outdated software
exposing services like SNMP and SMB, these weaknesses illustrate the importance of rigorous internal
assessments.

Each technique used in this assessment mimics a real attacker’s workflow — starting from simple discovery
to service enumeration and finally exploitation attempts.

Immediate remediation steps like applying security headers, sanitizing inputs, and locking down unused
services can significantly reduce risk. Long-term efforts like secure SDLC adoption, network segmentation,
and employee awareness will ensure a robust internal network security posture.

Prepared by:
Abhishek Kushwaha
B.Tech CSE, LPU