Ethical Hacking
Exploiting Misconfigurations
Most breaches do not start with a zero-day. They start with a default password that was never changed, a permission that was set too broadly, or an admin panel left open to the internet. This lesson covers the misconfigurations pen testers find most — and how to demonstrate them clearly in a report.
Misconfiguration is not an accident — it is the default state
Every piece of software ships with a default configuration built for getting things running quickly — not for security. Default credentials, open admin interfaces, permissive firewall rules, directory listings enabled. These defaults exist because vendors prioritise ease of setup over security posture.
The hardening step — changing defaults, restricting access, reviewing permissions — gets skipped or deferred under time pressure. Months later, a pen tester or a real attacker finds the same default configuration that shipped with the product on day one.
The most impactful misconfiguration categories
Default credentials
Admin interfaces, databases, network devices, and IoT systems shipped with known default usernames and passwords. admin:admin, admin:password, root:root, cisco:cisco. Databases of default credentials exist for thousands of specific products. Checking for them takes seconds and finds access surprisingly often.
Excessive file and directory permissions
Files and directories set world-readable or world-writable when they should be restricted. /etc/shadow readable by non-root users. Web directories writable by the web server process. Backup files left in publicly accessible locations. Each one is a path to something more sensitive.
Exposed administrative interfaces
Admin panels, management consoles, and database web interfaces exposed to the internet or internal networks without authentication restrictions. phpMyAdmin at /phpmyadmin, Tomcat Manager at /manager/html, Jenkins dashboards, network device web consoles — all legitimate tools that become attack surfaces when left exposed.
Unnecessary services running
Services installed and running that are not needed for the system's intended purpose. Telnet on a server that should only run a web application. FTP on a database server. The r-services (rlogin, rsh, rexec) on any modern system. Every unnecessary service is an attack surface that does not need to exist.
Anonymous FTP access — reading files without credentials
FTP servers can be configured to allow anonymous access — anyone can connect using "anonymous" as the username and any string as the password. This was once a legitimate feature for distributing public files. It still appears in production environments with surprising frequency, often on servers where FTP was configured once and never reviewed again.
The scenario: Port scanning confirmed FTP on port 21 running vsftpd 2.3.4. The backdoor was already noted as a critical finding. But before exploiting it, you want to check whether anonymous access is enabled — a separate misconfiguration that might expose files without needing the backdoor at all.
# Test for anonymous FTP access — connecting without real credentials
# Active testing — packets reach the target — run within authorised scope only
# The ftp command opens an interactive FTP session
# When prompted for username, type: anonymous
# When prompted for password, type anything — a fake email address is conventional
ftp 192.168.56.101
# Alternatively — check anonymously via Nmap script (less interactive)
# ftp-anon script tests whether the server allows anonymous login automatically
# and lists the directory contents if it does
nmap --script=ftp-anon -p 21 192.168.56.101Breaking it down:
Anyone on the network can connect to this FTP server without credentials. This is a confirmed misconfiguration — not a vulnerability in vsftpd itself, but a configuration choice that removes authentication entirely. The finding is separate from the backdoor: two different paths to the same service, both documented individually in the report.
The directory permissions are 777 — read, write, and execute for everyone. Combined with anonymous access, this means anyone can upload files to this directory without any authentication at all. Uploading a malicious file to a world-writable directory on a web server — if that directory is within the web root — is one route to placing a web shell on the system.
Tomcat Manager — default credentials on an admin panel
Apache Tomcat's Manager application — accessible at /manager/html — allows remote deployment of Java web applications. It requires authentication, but the default credentials (tomcat:tomcat, admin:admin, both blank) are so well-known that checking them is always worth doing before attempting anything more technical.
Metasploitable has Tomcat running on port 8180. The manager interface was confirmed during service enumeration. The scenario here is straightforward — check the default credentials before reaching for more complex techniques. Successful access to Tomcat Manager allows deployment of a malicious WAR file, which is a path to remote code execution.
# Test Tomcat Manager for default credentials using curl
# The Tomcat Manager page requires HTTP Basic Authentication
# curl can send credentials in the URL with the -u flag
# Test tomcat:tomcat first — the most common default
# -u username:password sends HTTP Basic Auth credentials with the request
# -s silent — suppress progress output
# -o /dev/null discard the response body — we only care about the status code
# -w "%{http_code}" print just the HTTP response code
# 200 means authenticated successfully 401 means wrong credentials
curl -s -o /dev/null -w "%{http_code}" \
-u tomcat:tomcat \
http://192.168.56.101:8180/manager/html
# Test additional common default credential pairs
curl -s -o /dev/null -w "%{http_code}" \
-u admin:admin \
http://192.168.56.101:8180/manager/html
curl -s -o /dev/null -w "%{http_code}" \
-u admin:password \
http://192.168.56.101:8180/manager/htmlBreaking it down:
Default credentials confirmed. Access to the Tomcat Manager interface allows deploying arbitrary Java web applications — which is effectively remote code execution on the server. This is a critical finding. In the report it sits alongside the vsftpd backdoor and the Samba RCE as a third independent path to full system access, all from misconfigurations rather than novel exploitation.
Using curl with -w "%{http_code}" to extract just the status code is a clean way to check credentials programmatically without parsing full response bodies. 200 = success, 401 = wrong credentials, 403 = forbidden regardless of credentials, 404 = path does not exist. Five characters of output per test makes it fast to scan through a list of credential pairs.
World-readable /etc/passwd and weak sudo configuration
Two Linux-specific misconfigurations that appear constantly in pen tests: /etc/passwd being readable (which it is by design on Linux — the real issue is /etc/shadow), and sudo rules that grant too much access to regular users. Both are configuration issues, not software vulnerabilities.
Sudo misconfigurations deserve particular attention. A user who can run a specific command as root through sudo — especially a command that can spawn a shell — effectively has root access. The GTFOBins project documents exactly which commands can be abused this way and how. It is the first reference point when you find an unusual sudo rule.
# Check file permissions on sensitive system files
# ls -la shows permissions, owner, and group for each file
ls -la /etc/passwd /etc/shadow /etc/sudoers
# Check what sudo privileges the current user has
# -l list the sudo rules that apply to the current user
# This shows which commands can be run as root via sudo
# No password prompt — lists them without needing to authenticate first
sudo -l
# If sudo reveals access to a command that can escape to a shell — use it
# Example: if the output shows the user can run /bin/vi as root
# vi can escape to a shell from within the editor with :!bash
# Check GTFOBins (gtfobins.github.io) for the specific command found
# Check for SUID binaries — executables that run as their owner regardless
# of who executes them. SUID root binaries run as root for any user.
# -perm /4000 finds files with the SUID bit set
# -type f only files, not directories
find / -perm /4000 -type f 2>/dev/nullBreaking it down:
msfadmin can run any command as any user without a password. This is not privilege escalation — this is already root-equivalent access. The msfadmin account has effectively unlimited permissions on the entire system. In a real engagement, finding this in sudo -l would mean the account was already as powerful as root. Document it as a critical misconfiguration: unrestricted passwordless sudo.
Nmap and find with the SUID bit set run as root for any user who executes them. Both are documented on GTFOBins as binaries that can escape to a root shell. An older version of Nmap includes an interactive mode that can execute shell commands. Find can execute commands during its search with -exec. These would be privilege escalation paths on a system where sudo was properly restricted.
Unlike /etc/passwd which is world-readable by design, /etc/shadow is restricted to root and the shadow group. This is the correct configuration. Contrast this with the earlier lesson scenario where /etc/shadow was readable — that was a misconfiguration. Here it is properly secured, showing what correct permissions look like for comparison.
Three misconfiguration checks. Anonymous FTP with a world-writable directory. Default Tomcat credentials granting manager access. Unrestricted passwordless sudo on a user account. All three represent paths to significant access that required no exploitation of software vulnerabilities — just finding and demonstrating that the configuration was never hardened from its default state.
Teacher's Note: The GTFOBins website (gtfobins.github.io) is one of the most practically useful references in pen testing. It catalogues Unix binaries that can be used to escalate privileges, bypass restrictions, or execute arbitrary code — organised by the binary name. When sudo -l reveals an unexpected binary, check it there first before spending time researching manually.
Practice questions
Scenario:
Scenario:
Scenario:
Quiz
Scenario:
Scenario:
Scenario:
Up Next · Lesson 25
Linux System Attacks
SUID abuse, cron job exploitation, weak file permissions, and the techniques that turn low-privilege shell access into root on a Linux system.