Weak public-facing web servers are a prime target for hackers and criminal groups. There are rising concerns about the use of web shells as an exploitation vector against vulnerable and inadequately protected web servers. With a web shell exploit it’s possible to compromise and obtain unauthorized server access and potentially, access to the wider corporate network.
What is a Web Shell?
A WebShell script is a trojan application that is maliciously uploaded to a web server and enables the unauthorized remote control of the infected server stack. Web shells are available in various guises, sometimes known as a C99 shell, C-Shell, web shell, web shell by Orb, and many others.
A web shell is a definitive example of a backdoor trojan because it can provide hostile access to the infected system. The web shell provides a remote access terminal (RAT) and if the internal infrastructure is weak, it may be possible for hackers to traverse the internal network anonymously. It’s easy for a hacker to mask their location via a proxy and a VPN, making detection very difficult.
Hackers can also bind the RAT to specific ports and encrypt the transfer of data, making it hugely challenging to detect. Once the web shell is successfully installed it can be used in a range of malicious activities such as exfiltrating data and credential files from the front-end. It’s possible to delete website assets and deface pages or upload additional malware such as ransomware.
In a worst-case scenario, hackers can hijack the remote host and access further resources on the internal network. The host can be set up as a command and control center and enlisted into a botnet farm to be used in coordinated DDOS attacks, ransomware attacks, and dictionary attacks against weak public-facing RDP and SSH connections.
Hackers search for weak servers using network reconnaissance tools that scan for known vulnerabilities. Web server application software such as Apache, Nginx, and IIS and any associated plugin could contain a vulnerability. However, it’s content management systems (CMS) such as WordPress, Joomla, Drupal, and Shopify that are the prime targets because they are so popular and widely used.
WordPress Vulnerabilities Lead to Web Shells
Threat actors inject web shells using various attack vectors, which range from the theft of user credentials and uploading a payload via FTP, exploiting a host using SQL injection (SQLi), local file inclusion (LFI), cross-site scripting (XSS), and remote file inclusion (RFI). Web shells are quite a sophisticated attack method; however hackers will always target businesses with weak security controls.
WordPress has always been a common target for hackers, but a recent trend has been via compromising WordPress plugins, typically popular and publicly available plug-ins. It is estimated that WordPress powers around 37% of all Internet websites (that’s about 455 million sites) so it’s not surprising cybercriminals target WordPress installations.
Finding vulnerabilities in WordPress plugins is not uncommon, but a recent security bug has proven hugely challenging to identify and resolve. One example is an AdSanity plugin vulnerability, a paid plugin for WordPress that allows for the creation and automated management of ad campaigns on a WordPress server.
AdSanity’s major vulnerability was a 9.9 rated CVE (out of 10) that allowed low privileged users to upload files and run remote code execution against the target. The exploit targeted a genuine feature where authorized users could directly upload ad campaigns to the server. The exploit resulted in any contributor being able to upload files directly, circumventing web server security.
Another significant breach was identified in the AccessThemes plugin, a tool that provided 64 themes and 109 plugins bundled into one handy pack. The risk was so severe that WordPress temporarily pulled the plugin from the official WordPress.org site. There have been other reports of Cookie-Based web shells being injected directly into the initial.php file of WordPress installations.
The bottom line is that web shells are not only hard to detect but also particularly nasty once unauthorized access has been achieved. The good news is that there are plenty of preventative actions that can be completed to protect your systems to the highest of standards.
Protecting Against Web Shells
File Integrity Monitoring (FIM) is a clever technology that looks for unexpected changes in the server directory structure. Web Servers have an underlying filesystem structure just like any other server and FIM can detect and alert against any changes detected.
Investing in an Intrusion Prevention System (IPS) greatly enhances internal security. The IPS inspects network packets as they traverse the internal network looking for deviations from a ‘normal baseline’. An IPS constantly outputs detailed logging that can be ingested by a SIEM platform that alerts on actionable events to either a human or to an automated response. The IPS can work hand in hand with file integrity monitoring to secure the front end.
Now consider adding a Web Application Firewall (WAF) into the mix, another protection layer that can shield against web shells by inspecting and filtering the HTTP traffic flow. A WAF has the capability of patching zero-day exploits which is highly desirable when responding to cybersecurity threats.
It might seem an obvious recommendation but it is essential to patch, patch, patch! Patching is one of the very best ways to defend against web shells because they will only work when an exploit is available – keeping everything patched reduces the risk dramatically. Combine patching with regular malware scanning because only a scan will detect evidence if you’ve already been breached.
Consider adopting the principle of zero-trust network segregation, a methodology of trust no-one, and always authenticate. Securing the network to zero-trust standards eliminates all elements of trust on the network and an organization’s infrastructure, thus promoting a least privilege access model. This model assumes that everything presents a threat. Adopting a zero-trust security policy ensures that all access is verified on an individual basis, incorporating authorization, authentication, and encryption measures as standard.
In all circumstances, the art of detecting web shells is hard, which is why it’s essential to take all the necessary steps to protect your system. It is likely that the use of web shells is accelerating because they can be adapted to work with almost any web programming language such as PHP, JSP, and ASP. The good news is that web shells have to hide in plain sight, so detection and resolution is not impossible.
