On the detection of malicious web shells and compromised websites

For my first blog post on the Cyber Investigator, I would like to show an example of academia research on a cybercrime related topic with elements of security measurements. It does not require enormous resources and collaborations but just understanding the technology and connecting dots. Hopefully, it will encourage young security researches to brainstorm other ways of investigating and preventing cybercrimes.

Closer to the point, today we are going to search for compromised websites and servers around the globe, by detecting malicious web shells on them that are uploaded and used by attackers. Web shells are special scripts that hackers usually use to maintain access to victim machines after successful exploits. Those pieces of software run on compromised servers, providing adversaries with ability to execute remote commands, browse file systems, upload files, elevate privileges, send spam emails, etc. More precisely, our goal is to monitor victim websites and ongoing attacks as shown on the map below. The discussed method gives ability to provide early warning of compromised websites, all the way to remotely disarming a shell and evicting the attacker.

victim_attacker_pairs_main
Top 10 compromised websites (black points) by the number of unique remote IP addresses, from which attackers access the detected malicious web shells (shown with arrows)

For the technical part, we need to understand the risks of inclusions from stale domains, so I will start with explaining it…

Suppose the following situation. A legitimate website A.com uses a JavaScript library for analytics from another domain B.com by including <script src=”http://B.com/analytics.js”/> on its pages. A year later, B.com goes out of the business and lets its domain to expire. The A.com does not update its website on time… Obviously, it is hard to underestimate the risks here. Any attacker may register B.com and push malicious code to A.com, compromising the website and hurting its users! This phenomenon was pointed out and called as stale domain-based inclusions in the 2012 paper “You Are What You Include: Large-scale Evaluation of Remote JavaScript Inclusions“, by Nikiforakis et al., who noticed that web pages of popular websites were occasionally referencing remote scripts of non-existing domains.

Wait a minute, malicious web shells are basically web pages too, and thus can also be vulnerable to stale domain-based inclusions!

For example, web shells that provide attackers with extensive GUI and additional tools (like on the figure below), are likely to request different third-party content like supporting images, JavaScript libraries and widgets. As we measured in our recent large-scale study of PHP shells, more then 30% of web shells call third-party domains, mostly on the client side (e.g., via JavaScript) but also on the server side (e.g., via PHP). Moreover, those calls are often intended to reveal a shell’s location to another attacker, maybe its original creator or distributor, who desires to take over new shell instances, which are already uploaded to compromised websites by another attackers. Taking advantage of this homephoning, such meta-attacker can abuse web shells around the globe by sending inclusions with modified JavaScript code or just by additionally knowing an intentionally left authentication bypass mechanism.

webshell

Do web shells call expired domains? Appears, they do. Which is not that surprising, given their usual copy-and-paste reuse and distribution via hacker forums. And indeed we can use the same approach as meta-attackers, meaning register expired domains first to detect locations of web shells. Out of more than 150 unique third-party domains, we found at least 8 domains being expired and available to be registered easily. We registered those domains (one being called from shells on the server side, others from the client side) and started to analyze our server logs. If we see the same libraries or resources being requested as we know shells do, e.g. /logz/yaz.js in the log example below, we can infer that it is a call from a web shell. At the same time, for the seven client-side domains we additionally see IP address of the attacker’s browser (e.g., 187.XX.XXX.117), when for the server-side domain such IP denotes a victim’s server. Moreover, in those seven cases we also receive HTTP Referer, which usually denotes the URL of a shell, and hence the compromised website (e.g., http://www.XXXXXX.ua).

187.XX.XXX.117 - - [01/Jan/2016:00:19:04 +0000] "GET /logz/yaz.js HTTP/1.1" 404 507 "http://www.XXXXXX.ua/files/XXXX_ca6a45d1cHN.php" "Mozilla/5.0 (Windows NT 6.1; rv:43.0) Gecko/20100101 Firefox/43.0"

After around three months of collecting logs, we received thousands of requests from web shells, which sum up to more than 300 compromised websites and servers. Mostly, those victim websites are local businesses and organizations, but we also detected more critical cases like a hospital website, a legal consultation office or a security services company. With the goal to visualize the attacks, we draw locations of victims and attackers on the world map, performing the following steps:

  • Retrieve geo-locations of victim websites based on their server IPs
  • Take into account TLDs of websites to improve regional accuracy, meaning, for example, a website with .ir is more meaningful to map in Iran, even if it is hosted in another country
  • Add on the map victims for which we know only the servers, but don’t know exact websites
  • Finally, map all the attacker IPs that were detected in logs

In the result, we obtained the following four maps:

The final fifth map, which is shown in the beginning of this post, shows the most popular targets and directions of attacks. Those victim websites were attacked by many different attackers or by a single attacker, who frequently accessed web shells uploaded to them, each time from a different IP address. I will let the readers to decide about the nature of these visualized attacks, but in general, over all maps, we see most of the globe covered both by victims and attackers.

Another thing that was not plotted on the maps is that with our method we could detect in logs the Referer headers from “localhost” or “127.0.0.1“. What does it mean? An attacker’s browser could send such Referer if a web shell is located on the same machine. We can imagine researchers, InfoSec professionals, CTF participants, and others trying out web shells on their own laptops. It is a dangerous situation, at least in case when shells run outside of a VM, as adversaries, who have control of appropriate stale domains, may compromise these machines (e.g., by sending malicious JavaScript), which are otherwise even inaccessible from the public Internet.

The silver lining is that security companies may register stale domains before hackers. It can provide up-to-date warnings and countermeasures! And finally, I hope that this case of cybercrime research was interesting and motivational.

More details about web shells, their visible and invisible features, surrounding ecosystem, can be found in our WWW 2016 paper “No Honor Among Thieves: A Large-Scale Analysis of Malicious Web Shells” Reading it, you will also find more evidences to the statement that often there is no honor among thieves 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *