The best get hacked; it happens.  It’s not about being unhackable, it’s about rolling with the punches and being resilient.  Learn the story of the most recent hack affecting CyberDominance.com.  It’s a story about how doing the simple things well can save you a lot of anguish – and how you can always achieve Cyber Dominance.

A day or so ago a colleague informed me that CyberDominance.com was redirecting him to a strange website.

Here we go again.

In the cyber domain, these things happen.  To make things worse, I had just taken some juicy, tender chicken off of the grill.  Roasted asparagus and everything… what a shame!

Spoiler, it turned out to be a problem with a WordPress plugin.  WordPress plugins are written by third parties, and this one had become compromised.  Spoiler part 2, I had secure backups so the crown jewels were never at risk.

The Symptoms

I confirmed the issue.  CyberDominance.com was being redirected to

bemylittleteddy.info

(it was a quick redirect, so I think this was the address.  I could have looked closer but I have other things to do in life.)

and then to:

adrequestnow.com

(Or something like that) Eventually landing at:

https://world.news-tap.com/?utm_source=dao_not_support

Which was a page full of click-bait articles, such as the new Game of Thrones paraphernalia.  No thanks, I don’t need to see how some amazing and weird new fruit can make me look like a Targaryen.

This was happening to all of the pages I could try.

The Investigation

My initial thought was that the problem/hack was with WordPress.  WordPress is a content management system used by some ridiculously large part of the internet.   WordPress is great, but it also means that I am running a lot of code that I haven’t written.  Although the WordPress system itself is open source and written by a very trustworthy group (truly, the WordPress development team is top notch), the third party content (Themes and Plugins, etc) are written by a much larger and less trustworthy group.  Rather, not so much that they are untrustworthy, but that there are hundreds of coders that a hacker could dupe – not just the WordPress development team.

Because CyberDominance.com uses a handful of third-party Plugins and Themes like any WordPress site does, this was my first suspicion.

Before doing any investigation – what did I do?  Backup!  Always do a backup.  That way if you screw something up or hit a booby trap of some sort, you have high assurance that you have saved the site as it was.

I AM PANICKING!!!

No, not at all.  No sweat.  I literally yawned.

At this point in the process, I know that I have been hacked or that I am being impacted by some sort of hack.  But I am not sweating.  I’m not worried.  Why?  Because I have tons and tons of backups.  I have backups remotely, locally, in hard media, and in other places that I don’t talk about!  These backups are periodic and automatic.

Also, consider my Desired End State Space (DESS).  With CyberDominance.com, my DESS is to be able to share content with readers, but also be a repository for the work of the CyberDominance.com team.  In other words, sharing the content is important, but having the content unadulterated is more important.  I can always scuttle the website – if the integrity of the content is intact, then I can easily pop it up somewhere else.  Knowing that this is part of my DESS, this is why I keep such diligent backups.  If the hackers do touch me, I simply restore the backups.  If this cyber war is hand-to-hand combat, then my approach is Aikido.

Calm, deliberate self-realization: a core part of Cyber Dominance Theory.

So at this point I am going to go hunting for the hack as a sport.  I don’t need to find the hack (I could just restore the backup and overwrite anything).  But it is interesting, and I suppose I should check to see if my credentials have been compromised.  Who knows, maybe it is easy to fix and I can get back to going to my voluntary click-bait sites so that I can try out that Targaryen fruit thing.  Backups can be slightly annoying, so its worth a look.

Popping the Hood

First I checked out the server.  I went into the server management tool, cPanel, and first looked at the last modified dates of all of the files.  Nothing interesting.

Then I checked the first place I think of when I see a redirect: the .htaccess file.  Is that what you were thinking, too?  It has been a while since I set up my own Apache servers, but I know how important these files are for a server running Apache.  The .htaccess file is responsible for a lot of convenient things for the user of a website (they can make your URLs look really pretty, for example) and I know that you can set up a redirect in this file.  I also know that some of my WordPress plugins manipulate this file.  And I know that I have myself done some manipulation of these files.  But upon inspection these look normal.

It was at this point that I discovered that I could log in to the WordPress admin panel (usually located at yoursite.com/wp-login and /wp-admin).  I hadn’t ruled out some sort of issue on the server administration side of the problem (I still thought it might be possible that my cPanel credentials had been compromised, even if such an intruder hadn’t locked me out).  But the initial look didn’t show anything obvious, so I went looking for lower fruit.

Investigating WordPress

My first thought was that someone must have finally brute-forced my WordPress admin console, but I was able to log in successfully.  So if they had compromised those credentials, they hadn’t taken the trouble to lock me out by changing the password.  Even though I use a ridiculously-hard-to-brute-force password scheme(article on that forthcoming), it’s possible.

Initial glance around WordPress, all seems quiet.  Everything seems to function.

My next thought was that something had been changed in my active WordPress theme, based on some things I experienced with it over the past year.  The Theme is responsible for taking your content (which is stored in a database) and packaging it all pretty and serving it as a webpage.  If a hacker had manipulated the code here and snuck a redirect instruction, that could be the culprit.  To quickly check this, I switched themes (code written by a different developer).  No joy – site still broken.  To be doubly sure, I downloaded a new theme (in case all of the themes that were currently installed on my server had been compromised – a new theme would presumably come down “fresh”).  No joy.  So this led me away from the Theme theory.

My Plugins are numerous.  I didn’t want to check every one – again I was looking for low hanging fruit; my dinner was literally getting cold and I really wanted to eat that chicken I had carefully grilled.  I skipped this for now.

Back Under the Hood

I went back to check out a few more things, double check some modification dates. You know, like when a car isn’t working and everybody is staring under the hood at the same time.  I also did a few google searches – attempting to rule out some “Hey everybody – all of WordPress was hacked last night!” possibilities.  (You have to Perceive Reality to be Dominant.  Try out the CyberDominance.com Cyber Perception Center!)

A little help from Tech Support

[Flashback!]

So way back in the beginning of all of this when I was doing backups before starting the investigation, I went ahead and put in a trouble ticket with my web hosting provider (they are admins for the server).  This is a good step, because not only do they have a lot more permissions and clients that could be having similar issues, but it is important for them to know if their clients are experiencing issues.  They do a lot of security monitoring on their end, so I want to help them help me.  And like I said, my chicken was getting cold – I’m not trying to reenact the movie Hackers here and go on some epic jaunt through cyberspace.  My Desired End State Space ain’t got no time for that.  So if they can figure it out before I can, great.

[Back to the present]

Around this point, I got a note back from tech support. He did something that I was putting off doing, he checked out the Plugins.  His approach was simple and quick: he broke all of the plugins by putting a typo into the server file path to the plugins.  This meant that any code that was being run on ANY of my plugins wouldn’t execute.  He reported that after trying that, he was able to get CyberDominance.com to load.  He gave me a cyber high-five and let me know to check out all of my plugins.

Plug-in, Plug-out

So I started down the list and one-by-one enabled and disabled my plugins.  When you disable the plugin, the code won’t execute.  All I had to do was see which plugin had to be un-plugged for the site to load normally.

Caught Red Handed

Eventually I found the plugin responsible.  It is a small plugin developed by what appears to be a hobbyist.  The plugin is called “yuzo-related-post”.  It creates some handy links at the end of an article that can help the reader find more of your articles that are related based on keywords.

I also checked out the yuzo-related-post plugin site and discovered that it had been “closed” (i.e. disabled, abandoned, stopped, shut down, etc) a couple of weeks ago.  Come to think of it, I had been focusing on other projects and I hadn’t been to CyberDominance.com in about that many weeks.  The developer also posted a warning to users.  Good on him for recognizing that he had lost control and warning others.

Admiring the Culprit

What is great about this “attack” (from the perspective of the bad guy) is that it doesn’t trip any of the automatic monitors that I have up.  The attack didn’t destroy the website.  It wasn’t dead, it was just misbehaving.  It would send the user to another website, like many, many other legitimate sites do.

Also, the exploit worked without requiring access to my server or my code.  I hadn’t run any update or anything.  They got a hold of someone else’s code that “called back” to another server as a matter of normal function. They changed this “call back” behavior to retrieve the address of a click-bait clearing house, and then used the good code within the plugin itself to do the dirty work.  Blah blah blah technobabble and leetspeak – it was sneaky and clever and subtle.

If I had not been prepared with backups, this could have been devastating.  The bad guy could potentially have all of my data held for ransom.

All’s Well That Ends Well

None of these really bad things happened:

• Server password compromise
• Server compromise (i.e. my web hosting provider)
• WordPress password compromised (admin account)
• WordPress password compromised (normal accounts)
• WordPress core code manipulated
• Brute Force entry (or any other kind of entry)
• Data (content) manipulation
• Backups destroyed
• Logs manipulated

It was just some poor guy that lost control of his code.  Because I was using his code to do some things, I was impacted by this.

This wasn’t some amazing story about me doing something l33t.  In fact, that is the point.  If you are having to call for cyber Batman every time there is a problem, then you are doing it wrong.  When you know your DESS and you do the simple things right – the things that are required to keep your DESS – then you don’t have to go into crisis mode.  You simply get back up on the horse, nice and calm.

This was never a real “problem” from the start because I had decent security in place (out of the box, some basic tweaks to default configurations), I had tons of backups, and I knew my Desired End State Space.  The site was interrupted for what must have been at most 4 days.  Had I a larger readership I probably would have caught it sooner (because I would be looking more often).  Down for a day?  No problem for me.  45 minutes of sleuthing (for fun) and everything was back to normal.

I will definitely be chalking one up for the good guys today.  And the best part?  My chicken dinner was still warm.  I don’t know about you, but I call that Dominance.