In a recent investigation, Varonis analyzed a compromised Linuxweb server with a misconfigured PHP website that allowed unrestricted malicious uploads. This misconfiguration would have allowed a threat actor to upload and execute malicious payloads on the server.
While the misconfiguration allowed an upload, the threats uploaded were not publicly accessible, preventing them from fully exploiting the server. However, the customer left this misconfiguration unnoticed for several months.
Continue reading to learn more about how the malicious activity was discovered, Varonis’ role in the investigation, and defensive recommendations to limit this attack in your organization.
The investigation
The compromise came to light for the victim when a national cybersecurity agency contacted them and flagged suspicious activity linked to the server.
The notification catalyzed a deeper forensic investigation that revealed a pattern of abuse dating back several months, which led them to Varonis.
Webservers
During a call to scope the incident, Varonis identified that the webserver was on the corporate VLAN and had not been patched for some time, there was no EDR tool on the asset, and no logs were being collected from the server on a centralized logging platform.
Webservers should ideally be placed in a Demilitarized Zone (DMZ) with network configurations to restrict and monitor the network traffic between the DMZ servers and the assets within the corporate environment.
A webserver within the corporate network presents significant risks, such as increasing the risk of a single-hop compromise, where a threat actor can enumerate the environment and target the domain controller directly upon establishing a foothold on the webserver. Such network configurations can cause the organization to fail to comply with regulatory requirements.
Varonis was engaged in a forensic investigation around four months after this compromise was identified. During the call, the Forensics team collected forensic artefacts from the webserver for analysis.
Initial access
The threat actor gained initial access by discovering a publicly accessible, unrestricted upload functionality on the victim’s website. An example of the URL is hxxps://redacted> .tld>/en/upload [.] php. Anyone who accessed the URL could simply upload any file by clicking on the upload button on the page.
We discovered that the customer developed the unrestricted file upload functionality for testing purposes and was not meant to be exposed to the public internet. The upload page became exposed due to an unnoticed misconfiguration on the website.
Persistence
The threat actor uploaded an obfuscated PHP web shell to the server to maintain access and further the attack.
A web shell is malicious code that allows a threat to gain remote control of a server. It may be placed on a webserver by exploiting unpatched vulnerabilities or abusing misconfigurations such as an unrestricted upload functionality on a webserver, which was the case in this scenario.
.png?width=1050&height=741&name=Image_AttackersPlaybook_202408%20(1).png)
Analysis of the web shell:
The function of the web shell was intended to help the threat actor:
- Gain access to the underlying operating system of the server
- Obtain the capability to navigate to different directories
- Make new directories and files
- Establish a reverse shell
- Help establish persistence on the compromised device
The web shell presented itself as a base64 encoded blob. This is decoded into an obfuscated code with gibberish text. To identify the functionality of the web shell, Varonis looked through the code and found the function responsible for removing the gibberish part:
Upon removing the characters from the font and the end of the base64 blob, the remaining base64 encoded code was found to be compressed using the ‘Deflate’ algorithm. A reversed character-set code appearing in HTML was identified upon inflating the data. The final step was to reverse the character set, which led us to the deobfuscated code and functionality of the web shell.
This deobfuscated code contained sections of base64-encoded data that decode to various capabilities of the web shell. For instance, the following code pertains to establishing a reverse shell on the webserver.
By saving the deobfuscated code as an HTML file and loading it with a web browser in a sandbox environment, we can see the various functionalities built into the web shell.
The impact and other possible outcomes
During our analysis, we identified that the web shell could not penetrate the customer’s network further and cause further harm. We also identified that the threat actors could not communicate with the web shell over the Internet.
During the investigation, a file named mailer.php was also discovered on the server. This was later confirmed to be a PHP Leaf Mailer script. Attackers commonly use these tools to send large volumes of spam or phishing emails directly from a compromised host.
While the presence of this script didn’t indicate successful execution, its discovery on the server gives us an idea of the threat actor’s intentions.
It highlighted the server’s potential misuse as attacker infrastructure, which could be capable of supporting broader malicious campaigns such as credential phishing or malware delivery. If the script had been successfully leveraged, the organization could have unknowingly become a node in a spam or phishing operation, potentially damaging its reputation and trust.
What else could have happened?
Impact is greatly influenced by the threat actors' objectives and motivations.
The web server in question was found to have numerous unpatched high-severity CVE vulnerabilities. If the threat actors were more technically minded, persistent, had different goals, or had successfully accessed the web shell, they could have caused a lot of damage.
Some of those possibilities could include:
- The threat actor could have performed enumeration and attempted to escalate privileges and move laterally in the environment upon realizing that the server is on the corporate VLAN.
- Due to the absence of an EDR solution, the tooling the actors dropped was likely to execute successfully, and their actions would go unnoticed.
- The database hosted on the webserver had PII entries — the threat actor could have exfiltrated the data and held the customer to ransom.
- The information could have been sold to other threat actors on the underground forums.
The possibilities of what could have been are endless. We highlight these outcomes to emphasize how the situation could have deteriorated rapidly, potentially resulting in significant long-term consequences for the company's operations and reputation.
Defensive recommendations
The following defensive measures are recommended to prevent similar misconfigurations and to harden web-facing infrastructure more broadly:
Regularly audit websites to uncover misconfigurations and perform attack surface mapping to identify assets exposed to the public internet. These assessments help pinpoint vulnerabilities before they’re exploited.
File uploads should be tightly monitored and restricted to authorized personnel. Validate file types, enforce size limits, and block executable formats like
.php and .exe. Store uploaded files outside the web root to prevent direct access or execution.Enable application logging to capture critical actions such as uploads and configuration changes. Use a centralized log monitoring platform to detect anomalies in web traffic. Ingest detailed web server logs into a SIEM for pattern detection, and monitor for the creation or modification of
.php files in upload directories.Implement TLS traffic inspection at gateways to detect malicious payloads. A robust vulnerability management program is essential to identify and remediate exposed assets. Deploy endpoint protection across all systems to reduce risk.
Deprecate or refactor unsupported applications—especially those critical to business operations but lacking active maintainers. Harden servers by disabling unnecessary PHP functions, keeping operating systems and server software up to date, and applying the principle of least privilege to services and filesystem paths.
Conduct regular file integrity scans on web directories to detect rogue scripts. Threat hunting should be part of your baseline validation strategy to identify suspicious behavior proactively.
Maintain a well-tested incident response playbook to address cybersecurity incidents promptly. Regularly back up critical application data securely and validate restoration procedures to ensure business continuity.
Reduce your risk without taking any
This investigation brings the critical need for a multi-layered security approach to light.
Having detection measures in place would have enabled the organization to identify the misconfiguration early. Strategies such as regular OS and application patching, properly configured access controls, and perimeter security measures are crucial in preventing exploitation.
Organizations must prioritize these security best practices and strategies to minimize exposure and constantly evaluate their security controls to thwart a compromise attempt.Do you know if your environment is prone to similar threats?
Get started with a free Data Risk Assessment. In less than 24 hours, you’ll have a clear, risk-based view of the data that matters most and a clear path to automated remediation. These findings are yours to keep; no strings are attached.
If you need immediate assistance, please get in touch with our team.
