Why, And How, Publetariat Was Hacked

Many people have asked me why Publetariat has been repeatedly targeted by hackers, if this could be some kind of publishing establishment attack on indie authors in general, or if I feel I am being personally attacked.

Let me reassure everyone: I have no reason to believe the recent problems were any kind of attack on indie authors, or myself in particular. Publetariat was targeted for three reasons, none of which have anything to do with me, the subject area of the site, or the site’s posted content.


First, Publetariat has become a very popular site, and it gets a lot of traffic. Hackers know they have a better chance of spreading their malware far and wide if they can sneak it onto a heavily-trafficked site.


Second, Publetariat was originally built on a software platform called “Drupal”, an open source content management system (CMS) .

“Open source” means available to the general public for free. Using Drupal makes it easy for a developer with a little know-how to get a full-featured website up and running quickly, but hackers can learn all they need to know about the latest version of Drupal simply by downloading a copy of the software and studying its files. So every time a new release comes out, interested hackers grab a copy and get to work, searching for possible security holes and methods for manipulating or commandeering the software. There’s been a HUGE surge in this type of hacker activity over the past six months or so, not only on Drupal sites but on WordPress sites as well—Wordpress is also an open source CMS.


Finally, the original Publetariat site had interactive features like member accounts, member blogs and commenting. The hackers got in by registering bogus user accounts and manipulating the user blogging and commenting functions so they posted hidden, malicious scripts instead of blog posts or comments. Any Drupal or WordPress site with registered user accounts and these types of interactive functions is an attractive target to hackers, which is why I won’t be offering those features here on the newly re-launched, WordPress site.


Hackers keep track of sites where their hacks have found vulnerabilities in the past, so once you’re on the hackers’ radar they keep coming back. This is why I’ve migrated the site off of Drupal and onto WordPress. WordPress has its vulnerabilities too, but turning off all interactive site features severely limits the possibility of attacks, and merely changing from Drupal to WordPress ensures the Drupal hacks of the past can’t come back.


Fortunately, no site visitors or registered members were impacted.

Publetariat’s hosting company places limits on server activity, and sudden, unacceptable spikes in activity will automatically trip a safeguard system that takes the site offline. Each time an attack was launched on Publetariat the safeguard was tripped in less than five minutes, before the malicious script even finished copying itself to all the server-side folders and files.

I don’t want to bore you with all the technical mumbo-jumbo here, but following each attack I carefully studied the server activity logs to see exactly what was done and when. No legitimate user accounts were ever compromised, and no site visitors were ever exposed to copies of the hacker scripts since the first, site-wide copying step was never completed.


IMPORTANT: Your site may already have been hacked, and you just don’t know about it yet.

As a web developer I have special tools turned on in my browser at all times to alert me to web page errors, to alert me to any problems on my sites and blogs right away. Since malicious scripts tend to result in certain specific, minor page errors, I can tell that MANY sites I visit have been hacked: not just small-potatoes author sites and blogs, but some of the majors, too.

If you don’t have these special error reporting tools turned on, you’d have no way of knowing you’ve been hacked until after the damage is done, and it’s typical for the malicious scripts to be installed and left lying in wait for optimal server conditions before they launch their attacks. It can be days, or even weeks, between the time the hacker first gains access and the time the trap is sprung. When I see such an error on a site that I know has decent tech support or a tech-savvy site owner I’ll alert them, but unfortunately I’m seeing a lot of this on the sites and blogs of non-tech-savvy indie authors, too.


The only advice I can give is this:

If you’re not tech-savvy, keep offline copies of all your site/blog content, just in case you need to re-create it online following a hacker attack. I usually author my blog posts offline in MS Word anyway, then copy them to my blog, and you might consider doing the same thing.

If you ARE tech-savvy, turn on your browser’s error reporting function and pay particular attention to any error pop-ups regarding Jscript (.js) files. These are a favorite hacker vehicle for injecting and spreading malicious scripts. Periodically check the date and time stamps on the server-side files, because if anything has been copied or injected at least some of the files will have date and time stamps that don’t match the rest of your install. Back up religiously, and keep the most recent TWO backups, at the minimum. This gives you a better chance of having a clean copy in case you need to recover from an attack. Remember, there may not be any apparent symptoms of a hack until after it’s too late, so even your most recent backup, created before you became aware of a hack, may have malicious content you don’t know about.


– April L. Hamilton
Publetariat Founder & Editor in Chief