I was recently contacted by a friend to take a look at a compromised machine. One of the things that struck me immediately was that he said this was the second time the machine has been compromised which leads me to believe that the machine wasn’t formatted and rebuilt from scratch after the original compromise and/or lessons weren’t learned. While the first might be unavoidable there’s no excuse for the second and I really have no sympathy in that case.

Not being able to take a machine offline for extended periods of time happens frequently, especially in a shop that can’t afford the downtime of rebuilding the machine, as is typically the case when the server provides a mission-critical service. In this case I recommend a hot-spare. Have a server on standby that you can restore data to and bring online so you can take the compromised server offline for forensics.

More importantly, before you ever place a machine on the public Internet you need to harden the system as much as possible. It doesn’t take mad-security-skills to effectively harden a system against most attacks. It just takes some time and diligence. What you are trying to accomplish with the hardening process is:

1. Reduce the number of attack vectors available. Simply put; enable a host-based firewall that permits only the ports necessary to provide the services needed. For example, a web server only needs ports 80 and 443 open to the public.
2. Reduce the number of known vulnerabilities on the host. This one is easy; patch the OS and all installed applications and only install the applications that are needed to provide the service. Also, make damn sure you’re patching and maintaining the applications that listen on the ports open to the public. Nine times out of ten, machines are compromised by known vulnerabilities.
3. Maintain least privilege. For example, if an FTP user only needs to download files, don’t permit write access and vice versa; if an FTP user only uploads, prevent reading and writing. This way if one of the service accounts is compromised, the hacker then has to figure out how to escalate privileges in order to further compromise the system.
4. Use strong passwords on all user accounts.
5. Routinely audit and maintain the machine.

There are many hardening guides out there that you can use to do the job right. I routinely reference the guides published by the NSA as well as by NIST. These guides go into much more detail than I have above and of course any templates downloaded should be fully tested before used in production. Good security always removes functionality.

UPDATE

My friend got back to me and was able to get control of the machine by enforcing strict firewall rules on the host. He also said that the FTP account used by a one-off application used a password that was the same as FTP user account and since it was IIS FTP, the user accounts were also system accounts.

He found HScan on the machine and I suspect it was used to compromise the host, then it was uploaded to the host to be used to compromise additional hosts. HScan uses an extremely small default dictionary file, which includes the variable %username% as the first password, which in this case would have worked right off the bat.

In this situation, the basic hardening suggestions above would likely have prevented this compromise…

Lock your host down before you put it on the public Internet. Otherwise you have no one to blame but yourself when it gets owned. Even worse, that compromised host is now a threat to my systems and I don’t want that.

For more information about this topic

• No Related Post