Microsoft is seeing a big spike in Web shell use

Microsoft is seeing a big spike in Web shell use
Getty Images

Security personnel at Microsoft are seeing a big increase in the use of Web shells, the light-weight programs that hackers install so they can burrow further into compromised websites.

The average number of Web shells installed from August, 2020 to January of this year was 144,000, almost twice that for the same months in 2019 and 2020. The spike represents an acceleration in growth that the same Microsoft researchers saw throughout last year.

A Swiss Army knife for hackers

The growth is a sign of just how useful and hard to detect these simple programs can be. A Web shell is an interface that allows hackers to execute standard commands on Web servers once the servers have been compromised. Web shells are built using Web-based programming languages such as PHP, JSP, or ASP. The command interfaces work much the way browsers do.

Once installed successfully, Web shells allow remote hackers to do most of the same things legitimate administrators can do. Hackers can use them to run commands that steal data, execute malicious code, and provide system information that allows lateral movement further into a compromised network. The programs can also provide a persistent means of backdoor access that despite their effectiveness remain surprisingly hard to detect.

In a blog post published on Thursday, members of Microsoft’s Detection and Response Team and the Microsoft 365 Defender Research Team wrote:

Once installed on a server, web shells serve as one of the most effective means of persistence in an enterprise. We frequently see cases where web shells are used solely as a persistence mechanism. Web shells guarantee that a backdoor exists in a compromised network, because an attacker leaves a malicious implant after establishing an initial foothold on a server. If left undetected, web shells provide a way for attackers to continue to gather data from and monetize the networks that they have access to.

Compromise recovery cannot be successful and enduring without locating and removing attacker persistence mechanisms. And while rebuilding a single compromised system is a great solution, restoring existing assets is the only feasible option for many. So, finding and removing all backdoors is a critical aspect of compromise recovery.

Case studies

Early last July, the Metasploit hacking framework added a module that exploited a critical vulnerability in the Big-IP advanced delivery controller, a device made by F5 that’s typically placed between a perimeter firewall and a Web application to handle load balancing and other tasks. One day later, Microsoft researchers started seeing hackers using the exploit to install Web shells on vulnerable servers.

Initially, hackers used the Web shells to install malware that leveraged the servers’ computing power to mine cryptocurrency. Less than a week later, researchers saw hackers exploiting the Big-IP vulnerability to install Web shells for a much wider assortment of uses on servers belonging to both the US government and private industry.

In another case from last year, Microsoft said it conducted an incident response after an organization in the public sector discovered that hackers had installed a Web shell on one of its Internet-facing servers. The hackers had “uploaded a Web shell in multiple folders on the Web server, leading to the subsequent compromise of service accounts and domain admin accounts,” Microsoft researchers wrote. “This allowed the attackers to perform reconnaissance using net.exe, scan for additional target systems using nbtstat.exe, and eventually move laterally using PsExec.”

The hackers went on to install a backdoor on an Outlook server that intercepted all incoming and outgoing emails, performed additional reconnaissance, and downloaded other malicious payloads. Among other things, the hack allowed the hackers to send special emails that the backdoor interpreted as commands.

Needle in a haystack

Because they use standard Web development languages, Web shells can be hard to detect. Adding to the difficulty, Web shells have multiple means of executing commands. Attackers can also hide commands inside of user agent strings and parameters that get passed during an exchange between an attacker and the compromised website. As if that wasn’t enough, Web shells can be stashed inside of media files or other non-executable file formats.

“When this file is loaded and analyzed on a workstation, the photo is harmless,” Microsoft researchers wrote. “But when a Web browser asks a server for this file, malicious code executes server side. These challenges in detecting Web shells contribute to their increasing popularity as an attack tool.”

Thursday’s post lists a variety of steps administrators can take to prevent Web shells from making their way onto a server. They include:

  • Identify and remediate vulnerabilities or misconfigurations in web applications and web servers. Use Threat and Vulnerability Management to discover and fix these weaknesses. Deploy the latest security updates as soon as they become available.
  • Implement proper segmentation of your perimeter network, such that a compromised web server does not lead to the compromise of the enterprise network.
  • Enable antivirus protection on web servers. Turn on cloud-delivered protection to get the latest defenses against new and emerging threats. Users should only be able to upload files in directories that can be scanned by antivirus and configured to not allow server-side scripting or execution.
  • Audit and review logs from web servers frequently. Be aware of all systems you expose directly to the internet.
  • Utilize the Windows Defender Firewall, intrusion prevention devices, and your network firewall to prevent command-and-control server communication among endpoints whenever possible, limiting lateral movement, as well as other attack activities.
  • Check your perimeter firewall and proxy to restrict unnecessary access to services, including access to services through non-standard ports.
  • Practice good credential hygiene. Limit the use of accounts with local or domain admin level privileges.

The National Security Agency has published tools here that help admins detect and remove Web shells on their networks.