It’s the nightmare scenario – you come into work to discover that your Mac or server have been hacked, or appears to be under the control of an intruder. What do you do next, before the wave of panic takes charge?

Few of us have not experienced that growing feeling of alarm as you discover what appears to be evidence of an intrusion, virus, or other invasion of our Mac. Thankfully in most cases it turns out to be more innocent than we fear: an innocuous if irritating popup web advert, or the benign actions of a colleague.

But every day many hundreds of servers – a few of them Macs – suffer defacement of their websites, and every so often intruders successfully break into Mac servers or their local networks. With the irresistible rise of portable devices such as iPhones and iPads, routes and types of intrusion have increased, and your vigilance should have been raised.

Intrusions occur because of vulnerabilities, of which the greatest is inevitably human. One of your users could have persisted in using an easily-guessed password, when leaving their SSH access enabled. Your web server could have been running a PHP script that has recently been discovered to be vulnerable to attack. Someone could have naively downloaded what seemed to be pre-release software, but turned out to be a Trojan.

Immediate action: isolate and contain

Unless you are a security wizard and signed-up online detective, the first and most immediate action when you suspect that any networked system has been compromised, is to isolate all those systems that are likely to have been affected from the rest of the network, and from the Internet. This initial step is a matter of simple firefighting, to limit damage as quickly as possible. Defaced websites in particular should be removed from view as quickly as possible. Any system that could – either through subversion or inadvertently – result in the propagation of compromise or damage to other systems must be placed in isolation before it can do so.

Rarely you may read of expert system administrators who monitor an intrusion in progress and gather information about the intruder. Whilst this makes for gripping reading, it is playing with fire and should never be attempted by lesser mortals. Unless you are very lucky, your intruder will be more of an expert than you, and is likely to become aware that they are being watched; their behaviour will then become unpredictable, and anger could lead to greater malicious damage.

Call for help

Once affected systems have been isolated, you should call for assistance. You then have three separate threads that should run concurrently: restoring services, investigating the compromise, and reporting it to those who need to know.

Restoring services

Activate your contingency plan to restore the services that you need. If this is an outward-facing server that runs a trading site, you need to get a substitute up and running as quickly as possible, or you will lose customers and revenue. Even if a full-blown trading site cannot be restored immediately, you should at the very least be able to field something in basic HTML, but whatever you do, avoid using an identical site as this could well be open to the same vulnerability: intruders have been known to call back to see if replacement or restored sites can be entered or defaced using the same techniques as the original.

Internal servers and SAN/NAS systems may also need rapid replacement if work is to carry on as normal. Mail may need to be stored in your fallback MX server until you can get a replacement internal mail server up and running. If removing compromised systems has significant impact on your business, then you need to rethink your contingency plan as a matter of urgency.

Investigate

Whenever possible, investigations should be performed on perfect duplicates of each of the hard disks in the compromised systems, with the originals kept as evidence. Commercial forensic rigs to do this are expensive, and you will probably need to call in external services that work with these tools daily. Mature systems include MacForensicsLab and BlackBag. If iPods, iPhones or iPads are involved, separate suites are required.

Report

Forensic analysis aims to discover how the intruder got in, and what they were able to access or perpetrate. When the latter includes personal or sensitive data, the exact extent needs to be established, as that will need to be reported to those overseeing its safe custody. For example, personal data without financial information will come under the Data Protection Act 1998, whilst credit card or banking details will also involve financial authorities if not the police. Log files are an invaluable resource, and whoever undertakes this analysis needs to be thoroughly familiar with the structure of those for both OS X client and Server editions.

Reporting compromises is not as clearly defined as it should be. If you work for a large organisation, you may be able to devolve responsibility by informing whoever is responsible for IT security, but if you cannot pass the buck you will need to make the decisions yourself. If there is evidence of a criminal act or activity (beyond the intrusion itself) then you should inform the police, in the first instance (in the UK at least) your own local police. They may decide to pass this on to the National Cyber Crime Unit within the National Crime Agency (NCA) if it is deemed serious enough.

If you process purchases or store financial details of customers, you will need to refer to the instructions provided by your merchant services provider, and follow those carefully. Any damage may be covered by your business insurance, so in most cases of loss (to your business or third parties such as customers) you will need to inform your insurers. If any of your services are hosted in full or in part by another organisation such as your ISP, they also need to be informed quickly, as they may have evidence that is significant to the investigation.

You, and everyone involved, must keep detailed notes, preferably on paper or using a system that is independent of any that may have been compromised. Record everything that might later be of significance, including exactly what you do and when, who you inform, with accurate timed records of all phone calls. If you have involved an outside agency, these may form crucial evidence.

Follow-up actions

Once those immediate actions are complete, you should check all other systems to ensure that they have not been compromised or damaged in any way.

In slower time still, you can plan how to cleanse and re-deploy those systems that were compromised. Cleansing requires thorough low-level reformatting of all connected drives, even if there was no obvious damage. Avoid restoring from recent backups, which could contain rootkits, trojans, or the other instruments of intrusion.

As the details of the breach become clear, you should reconsider your security measures so that systems will not be vulnerable to similar attacks; in doing so, your recent problem should be kept in proportion and not allowed to drive the whole policy.

Tools: Detecting Intruders

It can be surprisingly difficult to spot an intrusion unless the hacker leaves overt evidence such as defaced web pages. Network Intrusion Detection Systems (NIDS) ae available to monitor systems, including Suricata and Snort.

Their installation and use is non-trivial, and I will be taking a more detailed look at these shortly.

Generic OS X monitoring tools can be helpful at detecting unusual disk or other activity, but cannot normally be relied on in the same way that a dedicated NIDS can.

Generic network monitoring systems such as Nagios or Zenoss are strong contenders for watching sizeable networks. However if you have no more than a single server and a dozen or so clients, the effort and overhead of these tools is unlikely to prove worthwhile, leaving those with smaller networks in need of a good tool to watch for attacks and compromises.

Technique: Reading Logs

One of the great advantages of Unix-based operating systems like Mac OS X is that they record so much information in their logs. However this may prove a double-edged sword, as the wealth and detail in log files can readily overwhelm and confound.

The first place that most intrusions should be recorded is in your firewall log, generally accessed through its web admin interface. Many are prefaced by a port scan or sessions of SSH probing, possibly a day or two before the intrusion succeeds. If you have NIDS running, the next log in which an intruder is likely to have left evidence is in the NIDS log.

OS X Server maintains its own logs, additional to those normally browsed in Console, and you should make yourself familiar with them if you use it. Further information about using Console is here.

Updated from the original, which was first published in MacUser volume 26 issue 15, 2010.