🕒 Reading Time: 3 minutes Welcome to the CARI.net Blog! This post is the first in a series about compromised sites. We believe that information and awareness is the precursor to a successful defense strategy. Happy Reading! My first experience dealing with forward facing asset security was when my friend’s website was compromised in 2009 and heavily defaced. We were able to clean up, but the damage had already been done to his business. Let us fast forward a few years to 2012. At that time, I was working at a shared hosting company when everything from Suzy’s Photography Blog to some of the largest businesses in the world were infected by the now defunct Blackhole Exploit Pack. Now it is 2014, and not a single day that passes that I do not discover another site that is freshly compromised. Website security is probably the largest aspect of external asset cyber-security, and one of the hardest to lock down. However, the majority of compromises are not done on the websites of major corporations; they are done on sites owned by people like you and me. The majority of victim sites (and the aggregate prime of my experience) are based upon a Content Management System (CMS) such as WordPress, Joomla, etc. So, now that you have some background, let’s get started. There are a few basic guidelines that needed to be followed when working on a potentially compromised site:

1. Malicious files are like mice. If you find one in your site, it’s not alone. This is especially true when dealing with phishing pages.
2. When attempting to locate a malicious file, don’t assume any file is not the one you are looking for, even if you created it. In 2013, there was a massive outbreak of infections on WordPress sites where two very malicious files were named “wp-apps.php” and “wp-count.php”. For those of you who are not familiar with the WordPress naming schema, WordPress prepends it’s default configuration files with “wp-“. In fact, there is a file called “wp-app.php” that actually belongs there.
3. Timestamps are your best friend. One of the simplest ways to locate files is by the timestamps. Most CMS software configuration files are created, edited once and then left alone for the rest of their existence. In the case of WordPress, the majority of “wp-includes/” should never change.

There is one more very important observation I would like to express to you in this post. While it is your site that is compromised, you are not the intended victim; you are just a means to an end. Consider the following situation:

For many years, you have been running a standard CMS-based blog site where you discuss trends in animatronic ducks. You do not sell any products, take donations or do anything where storing potentially sensitive data is involved. All your content is purely about current events regarding robotic waterfowl. One day, you try to visit your site and notice a bunch of weird links in your page. Pretty soon, your anti-malware software pops up saying it has blocked malware from your website. You take look at the files on the site and discover several that were not there before, and several more that were modified. Upon further investigation it becomes apparent that the scripts are aimed to exploit well-known vulnerabilities in older versions of common web browsers.

As you can see, the website is not the intended victim, it’s user base is. This is just one example of how attackers can use websites to facilitate more complicated attacks, which we will touch on with the next post! Regards, Zachary Wikholm Senior Security Engineer Security Incident Response Team (CARISIRT) CARI.net sirt@cari.net