Stealthy, persistent threats that open back doors to targeted systems can be just as dangerous as cyberattacks that pose more immediate risks. These slow-acting hacks rely on malicious scripts uploaded to a web server that permit an attacker to administer or control the server remotely. Web shells are scripts or programs for legitimate web-based system management or administration, but bad actors can use them maliciously to gain persistent access to web servers.
The Cybersecurity and Infrastructure Security Agency, along with the FBI and international cybersecurity partners, issued an advisory in February warning that malicious actors were exploiting these hidden vulnerabilities. The group had already ordered civilian federal agencies to disconnect affected products until they could be cleared of threats.
A zero-trust environment can deter web shell attacks, but CISA advises agencies to be on the lookout nonetheless while starting on the path to zero trust. Common targets include edge devices or other internet-facing technologies. (The attack behind the CISA directive targeted a VPN product.)
Malicious web shells are delivered by exploiting server or web app vulnerabilities or configuration weaknesses, and their popularity with black-hat hackers is rising: Microsoft reported tracking an average of 140,000 active web shells every month in 2021.
Click the banner below to begin developing a comprehensive cyber resilience strategy.
When Are Web Shells Dangerous?
Malicious web shells are dangerous not only because they establish back doors into systems, allowing remote attackers to bypass security restrictions and gain unauthorized system access, but also because of how difficult they can be to detect.
They may be as small as a single line of code, hidden in encrypted HTTPS or encoded plaintext, and can rotate among protocols and ports to obscure their intent.
Attackers can execute web shell payloads hidden in cloud management applications on widely used cloud providers. In a case recently cited by CISA, attackers compromised a product’s internal integrity checker, ensuring it would fail to alert security teams to the breach.
To protect against scripts containing malicious web shells, agencies need strong security processes and tools. Ensure software and patches are kept up to date to reduce exposure to vulnerabilities that could be exploited to inject web shells. The Exploit Prediction Scoring System helps teams prioritize remediation efforts.
Use web application firewalls to filter and monitor HTTP traffic to detect and block common web shell patterns. Also, check content security policies to specify and control which resources can be loaded to web pages, and which users can access system utilities and directories.
Monitor server logs for suspicious activities, such as unexpected file modifications or unusual access patterns, and disable unnecessary services and ports. Perform regular security audits of the website’s codebase, configuration and server settings.
Follow These Instructions to Detect and Remove Malicious Web Shells
Detect unwanted web shells as quickly as possible by using file integrity monitoring to identify unexpected changes, such as unusual time stamps. Tools such as Tripwire Anomaly Detection can help establish a baseline of normal website behavior and traffic to easily identify anomalous actions.
Review web server logs for suspicious activities, such as requests for nonexistent files or repeated access to specific files. Do the same for website files and other internet-accessible locations, looking for suspicious names or extensions that do not match the content type.
48 hours
The window within which hackers exploit nearly half of disclosed vulnerabilities
Source: Carnegie Mellon University, “Historical Analysis of Exploit Availability Timelines,” August 2020
Security solutions from Trellix (formerly McAfee and FireEye) or Symantec will maintain a signature database of known web shells.
Removing scripts containing web shells from a compromised server involves a careful approach to ensure compete eradication. The hacker will have not only left behind a web shell with a back door but also probably exported configurations and private certificates that were on the server.
CISA recommends following the vendor’s mitigation instructions until a patch is released; then, it’s critical to implement those patches within 48 hours. Hackers exploit 50 percent of known vulnerabilities within two days of disclosure, according to a Carnegie Mellon University study, so time is of the essence.
RELATED: CIRCIA is a turning point in CISA’s watchdog role.
Mitigation steps for compromised systems may include backing up the configuration of the appliance, restoring it to factory settings and then upgrading it to the version that was running prior to factory reset.
In addition, agencies should restore appliance configurations from backup, and revoke and reissue any certificates stored on the affected appliance.
Changing passwords and access permissions is critical. Reset the admin password and application programming interface keys stored on the appliance, passwords for local users defined on the gateway and license server credentials.
SvetaZi, USO, Totajla, Alessandro De Maddalena/Getty Images
