The Three Main Indicators of Compromised Web Servers


Web servers are a popular target for attackers, and the sheer number of web servers, frameworks, and applications can make it difficult to detect threats. Here are some common indicators.

By Lonnie Benavides

You slowly push open your unusually unlocked door only to find that your house is ransacked. A broken window, missing money, all signs that someone has broken in and you have been robbed.

In the physical world, it is very easy to understand what an indicator of compromise would mean for a theft. It would simply be all the things that tell you about the occurrence of the event. In the digital world however, things are a different story.

My area of ​​expertise is breakthrough in web applications. I spent many years as a penetration tester trying to gain access to internal networks through internet-connected web applications. I developed this expertise due to the prevalence of exploitable vulnerabilities that made it easier to achieve my goal. In a world of phishing and unwanted downloads, the web layer is often a complicated and overlooked area of ​​compromise.

A perimeter web server is a gem of a host for any potential attacker to control. It often enjoys full internet connectivity with minimal downtime while providing an internal connection to the target network. These servers are regularly expected to experience attacks, heavy user traffic, bad login attempts, and many other characteristics that allow true compromise to blend into “normal” behavior. The nature of many web applications running on these servers is such that encoding, obfuscation, file write operations, and even interaction with the underlying operating system are all taken care of. natively, providing much of the functionality an attacker needs to do their bidding. Perimeter web servers can also be used after a compromise has occurred elsewhere in the network to retain remote access to avoid pesky two-factor VPNs.

With all the reasons why an attacker should attack a web server, it’s amazing that there isn’t a wealth of information available to detect a server compromise through the application layer. Perhaps the sheer number of web servers, frameworks, components, and web applications results in a situation that is difficult for any analyst to address with a common set of metrics. While certainly not an easy task, there are a few common areas that can be assessed for compromise with a high degree of success.

#1 Web Shells

Often the product of vulnerable image downloaders and other poorly controlled file-writing operations, a web shell is simply a file that has been written to the web server’s file system for the purpose of executing commands. Web shells are most often text files with the appropriate extension to allow execution by the underlying application framework, an obvious example being commandshell.php or cmd.aspx. Viewing the text file typically reveals code that allows an attacker to interact with the underlying operating system through built-in calls such as the ProcessStartInfo() constructor in .net or the system() call in php . The presence of a web shell on any web server is a clear indicator of compromise in virtually any situation.

Web Shell IOC (Indicators of Compromise)

  • Scan all web root files for operating system calls, considering installed application frameworks
  • Check for existence of executable files or web application code in download directories or non-standard locations
  • Analyze web server logs to detect commands issued as successive GET requests or POST requests to suspicious web scripts
  • Mark new processes created by web server process because when should it really run cmd.exe

#2 Administrative Interfaces

Many web application frameworks and custom web applications have some form of administration interface. These interfaces often suffer from password issues and other vulnerabilities that allow an attacker to access this component. Once inside, an attacker can use all the built-in features to further compromise the host or its users. Although each application has its own unique logging and features available, there are common IOCs that should be investigated.

Admin Interface IOC

  • Unplanned deployment events such as the release of a .war file in a Java-based application
  • Editing user accounts
  • Creating or modifying scheduled tasks or maintenance events
  • Unscheduled configuration updates or backup operations
  • Failed or non-standard login events

#3 General attack activity

The typical web hacker won’t activate their favorite commercial security scanner to try and find ways to gain access to your web application, as they tend to prefer a more manual approach. The ability for an attacker to discreetly test your web application for exploitable vulnerabilities makes this a high return, low risk activity. During this investigation, the intruder will focus on the exploits that led to their goal of gaining access. A keen eye can detect some of this activity and isolate it to a source.

General attack of the CIOs

  • Analyze the web server logs for errors (500) or errors handled in the application itself. Database errors for SQL injection, path errors for file write or read operations, and permission errors are some of the prime candidates to indicate a problem.
  • Access to known sensitive files through the web server process. Check if web configuration files like WEB-INF/web.xml, sensitive OS files like /etc/passwd, or static location OS files like C:WINDOWS system.ini were accessed through the web server process.
  • Advanced search engine operators in referral headers. It’s not common for a web visitor to come to your site directly from a Google search inurl:foo ext:bar
  • Large amounts of 404 page not found errors with suspicious filenames may indicate an attempt to access unrelated areas of an application

Web application IOCs still suffer from the same issues as their more traditional counterparts in that an attacker’s behavior must be highly predictable to detect their activity. If we’re honest with ourselves, an attacker’s ability to avoid detection is only limited by their creativity and skill. An advanced attacker could easily avoid creating most, if not all, of the indicators in this article. That said, many attackers aren’t as advanced as the media makes them out to be; even better, some of them are just plain lazy. Armed with the web-specific IOCs above, the next time you approach the unlocked front door of your ransacked web server, you might be able to see who’s got their hands on your cookie jar.

Lonnie Benavides is Senior Technical Director of Information Security at DocuSign with 16 years of industry experience. In 2007, he was part of a hand-picked Air Force team that took over the White House network in two hours. Lonnie led the application security team at Washington Mutual and created the red team at Boeing. Lonnie is an expert in web application security and enterprise assessment strategy.


Comments are closed.