Incident response: identifying a compromise

According to the book Computer Incident Response and Forensics Team Management: Conducting a Successful Incident Response [L Johnson 16/12/2013] there are 7 stages to incident response. Today we'll focus on stage 2 – identification. How do you know if your website has been compromised? We'll also look at some options to help with each stage of that process.

The steps of identification can be outlined as [L Johnson 16/12/2013]:

Suspicious Entries in System or Network Accounting
Excessive Unsuccessful Login Attempts (>3 per user)
Unexplained New User Accounts -Unexplained New Files
Unfamiliar File Names
Modifications to file names and/or dates
Intrusion Detection System (IDS) Alerts or Alarms
External notifications (either outside users, customers, or emergency personnel)
E-mail flood from unsuspecting helper
Looking at the above list we can put systems in place to help you detect suspicious activity at the earliest stages which, in turn, will help you get your website back to normal as quickly as possible – the ultimate end goal.

Suspicious Entries in System or Network Accounting

Nobody likes looking through system log files, it's boring as hell, but it can be a really effective way of spotting abnormal activity. Your website host can help point you to access logs and error logs which you can look through to spot potential problems. For example searching your access logs for URLs that the public shouldn't be accessing such as admin panels, hidden pages or files that shouldn't exist like "backdoor.php" (ok it probably wouldn't be called that but you get the point) can all be done in a few minutes over a brew. Error logs are good because backdoors and web shells are often poorly coded and can easily trigger system errors which may get logged in these files.

So yes, checking logs is boring but it is effective. In fact it's that effective that malicious users will often disable error reporting as their first step once they gain access so with that in mind let's move on to the next steps.

Depending on what platform your website is built upon you may be able to install a plugin that will help monitor login attempts and automatically block users who exceed that number for a given time period. This is an effective way to stop people from "brute forcing" passwords on your login pages. Just do a search for "firewall plugin" and you should get some good results. A good choice for WordPress is a plugin called WordFence but there are plenty to choose from.

Hackers have access to tools that can try many many passwords per second using specific "wordlists" – they're automated and very fast. Blocking failed attempts is an effective way to help combat this. You can also talk to your web host and have them configure a firewall to stop these attempts. Speak to them and you might find that they already have such a system in place if they are a good host.

Unexplained New User Accounts

This one's common sense but it's easily overlooked. I can recall many times when I've asked a client if they know all of the user accounts on their website and had them reply with an astounding "no". Check your user accounts regularly, it takes a few seconds. If you don't recognise it then delete it and change all of your passwords. It's simple and there's literally no excuse. You wouldn't allow a random stranger to sit in your living room would you?

Unexplained New Files, Unfamiliar File Names, Modifications to file names and/or dates and Intrusion Detection System (IDS) Alerts or Alarms

We can tackle this one using the same approach as the unsuccessful login attempts step. Many of those same plugins offer the ability to automatically monitor for changes in the filesystem such as new or changed files. This is very effective because malicious users will often login using a compromised password and then they will upload a backdoor file which means that they can still access your filesystem even if you change your password. It's their way of making sure that they can keep access once they've gained it. By monitoring for file changes you can spot these files when they are uploaded and take action by changing your passwords and removing the file(s). There are free plugins that are very effective. Get one installed and set it up using their user guides. There are also commercial options available which go into more detail but even the basic ones work very well in most cases.

A slightly more complex step is to configure your web server to block access to certain types of files. For example some compromises may involve adding a file to your website which then loads external files from another server. These can be blocked with a little bit of technical know-how. Contact your web developer and talk to them about Content Security Policy (CSP).

External notifications (either outside users, customers, or emergency personnel) Your customers can be your ally here so make it really easy for them to get in touch with you if they spot something odd on your website. Perhaps even set up bug bounties by rewarding customers who spot something odd that turns out to be a real issue. Essentially, make it easy for your customers to contact you if they spot something that's out of place.

E-mail flood from unsuspecting helper

Compromised systems are often used to send out spam email. You can combat this by using a dedicated mail system such as MailGun or SparkMail and disabling email on your web server. This one can be a bit tricky to set up but believe me, it's worth it.

By following those steps above, along with some good basic security, you can really help keep your website more secure. If it's too much trouble for malicious users to bother with then maybe they'll just move on. If they don't then at least you will get to know about it a little sooner. In my experience once systems become compromised they tend to stay compromised for a very long time – sometimes even years – because they aren't actively monitored so the hack remains undetected. Be proactive.

References

Computer Incident Response and Forensics Team Management: Conducting a Successful Incident Response, Leighton Johnson, 16/12/2013.

Originally published on steveperrycreative.com