During a security audit, I found a critical vulnerability in the file upload mechanism of an application designed to receive user-submitted requests. This vulnerability enables attackers to upload and subsequently execute malicious files on the server with administrative privileges. Furthermore, it allows a maliciously crafted PDF file to steal the NTLM hash of the user who opens it, potentially enabling lateral movement and privilege escalation within the infrastructure. This write-up provides technical details, a proof of concept (PoC), and recommended remediation strategies.
Background and context
The audited application is a web-based platform that allows users to submit various requests (referred to as “applications”). It includes functionality for attaching relevant files to these requests, to provide additional documentation. The specific module, named “Documents for applications” was found to accept any file format without comprehensive scanning or validation.
Upon initial reconnaissance, I found that:
- The application permitted the upload of every file type, from PDFs to executables (lack of file type restrictions).
- Uploaded files would eventually run on the server with administrative privileges after a short waiting period of a few minutes (delayed file execution).
- There was no antivirus or antimalware solution deployed to scan for malicious content in uploaded files.
- By uploading a crafted PDF, the auditor was able to cause NTLM hash disclosure from users who opened the file.
This set of conditions created a perfect condition for attackers: not only could they execute arbitrary payloads with the highest privileges on the server, but they could also harvest user credentials in the form of NTLM hashes.
TECHNICAL DETAILS AND EXPLOIT PROOF OF CONCEPT
Requirements for exploitation
Exploiting this vulnerability requires basic user access to the system along with a valid request number. Because the application’s workflow requires user login before attaching documentation to a specific request, the attacker needs to be an authenticated user (even at a low privilege level) and must have knowledge of a specific request number.
Unrestricted File Upload process
Once logged in, the user navigates to the “Documents for applications” section. Here, users can attach files. The vulnerable HTTP request looks like below (some parameters have been redacted for confidentiality):
The server saves the file and queues it for processing. The logs revealed that the file is then executed with administrative privileges two to three minutes later - likely due to a scheduled background process that handles or processes uploaded documentation.
NTLM Hash theft via crafted PDF
One of the most interesting aspects of the vulnerability is the potential to steal NTLM hashes from users. By embedding a link or object within a specially crafted PDF, an attacker could cause the user’s operating system to attempt a resource fetch from a remote SMB share. This automatic handshake discloses the victim’s NTLM hash to the remote share controlled by the attacker. A typical toolchain for receiving NTLM hashes in this manner includes Responder or similar traffic interception software. In the audit, the sequence was as follows:
Attacker created a tampered PDF that forced a hidden request to an SMB server hosted on the auditor’s machine.
User (with legitimate credentials) opened the PDF.
The user’s machine automatically attempted an SMB connection to the malicious server, thus transmitting the NTLM hash.
The Responder tool captured the hash, which could then be cracked offline or relayed in real-time for potential lateral movement.
Below is a simplified log excerpt from Responder showing the hash capture event (anonymized for privacy):
Execution of arbitrary code on the server
Finally, a more advanced payload was developed to demonstrate full system compromise. Using a reverse shell approach (commonly facilitated by tools like netcat or Meterpreter), the auditor successfully established an interactive shell on the target server. The shell granted command execution as a local administrator account on the host machine, named johns-pc, confirming the severity of the issue:
Root cause analysis
From a security architecture perspective, several factors combined to enable this vulnerability:
- The application did not enforce file type restrictions nor validate MIME types, leaving the door open for arbitrary files.
- There was no robust mechanism to check file contents or structure, allowing malicious payloads to slip through.
- Without an antivirus or malware scanner, even obviously malicious files were not flagged or quarantined.
- The file handling process executed uploaded files under a high-privilege account, drastically escalating the impact of any compromise.
- The application did not sanitize or limit the file’s capabilities upon user access, enabling embedded resources to trigger NTLM handshakes.
RECOMMENDATIONS AND MITIGATIONS
Whitelisting and file validation
Implement a robust allowlist (whitelist) that permits only safe file formats. Each uploaded file should be thoroughly validated by checking:
a) Restrict files to specific extensions (e.g., .pdf, .doc, .txt) that are truly necessary for business functionality.
b) Ensure the provided file type matches its advertised MIME type in the HTTP header.
c) Inspect the initial bytes of the file to verify it aligns with the allowed format’s typical signature.
d) Impose strict file size limitations to reduce the risk of denial-of-service attacks and further limit potential malicious payloads.
Antivirus/Anti-Malware scanning
Deploy and maintain updated antivirus or EDR (Endpoint Detection and Response) tools that scan every uploaded file before storage or execution. This helps detect known malware signatures and blocks suspicious or abnormal content from reaching the server’s processing pipeline.
Principle of least privilege
Review the permissions assigned to the process handling uploaded files. Any file scanning or document processing function should be executed under a low-privileged service account. This design ensures that, in the event of a breach, the damage is minimized and does not automatically escalate to full administrative control.
Additional server hardening
Disable or isolate services that are not strictly necessary to the file processing workflow. Regularly update and patch the operating system and all relevant software to fix known vulnerabilities that could be chained with this file upload flaw.
Investigate potential data exposure
During the audit, it was also discovered that two suspicious files, Credit_card_numbers.xls and Credit_card_numbers_Discover.txt, reside on the target system (johns-pc). These may contain sensitive credit card data. The presence of these files in unencrypted form is a separate but equally serious violation of security best practices. It is imperative to:
- Remove or securely archive these files.
- Implement data-at-rest encryption to protect any sensitive information stored on the server or local computers.
- Introduce strict data handling policies, ensuring no unencrypted credit card data is ever stored on endpoints or servers.
CONCLUSION
The discovered vulnerability represents a significant risk for any organization relying on file uploads to conduct critical business processes. Allowing unrestricted uploads with administrative-level execution of the submitted files exposes the entire infrastructure to a range of cyberattacks, from credential harvesting (through NTLM hash theft) to full system compromise. The addition of no antivirus or endpoint security solution which could analyze the issue, leaving the organization vulnerable to known threats.
