How to prevent the sethc.exe hack?
In order to prevent an attacker from booting from a repair disk and using that to gain access to your system, there are several steps you should take. In order of importance:
- Use your BIOS/UEFI settings to prevent booting from removable media, or require a password to boot from external media. The procedure for this varies from motherboard to motherboard.
- Lock up your tower. There is usually a way to reset BIOS/UEFI settings (including passwords) if an attacker gains physical access to the motherboard, so you'll want to prevent this. How far you go depends on factors such as the importance of the data you're protecting, how dedicated your attackers are, the sort of physical security leading up to your workstation (e.g. is it in an office that only co-workers can access or is it in an isolated area open to the public), and how much time a typical attacker will have to break your physical security without being seen.
- Use some sort of disk encryption such as BitLocker or TrueCrypt. While this won't stop a dedicated attacker from reformatting your system if they can get physical access and reset your BIOS password, it will stop nearly anyone from gaining access to your system (assuming you guard your keys well and your attacker doesn't have access to any backdoors).
The issue here is physical access to the machine. Disable the ability to boot from CD/USB and lock the BIOS with a password. However, this will not prevent someone with enough time alone with the machine from breaking into it with numerous different methods.
SETHC.exe can also be replaced with a copy of explorer.exe (or any other .exe) giving full system level access from the logon screen as well. Not to repeat others, but if you are talking about server security, I would think that a certain amount of physical security is already in place. How much, depends on acceptable risk outlined by your organization.
I'm posting this to perhaps go a different route. If you are concerned that the user community in your organization can or will do this to the Windows 7 workstations (as you described in the question) the only way to circumvent these types of attacks is to "move" the compute into the datacenter. This can be accomplished with any number of technologies. I'll pick Citrix products to briefly overview the process, although many other vendors provide similar offerings. Using either XenApp, XenDesktop, Machine Creation Services, or Provisioning Services you can "move" the workstation into the datacenter. At this point (as long as your datacenter is secure) you have physical security over the workstation. You can either use thin clients, or fully capable workstations to access the desktop hosted from the datacenter. In any of these scenarios you would need some hypvervisor as the workhorse. The idea is that the security state of the physical machine the user is on is of minuscule risk regardless of whether it is compromised or not. Basically, the physical workstations only have access to a very limited number of resources (AD, DHCP, DNS, etc.). With this scenario, all data, and all access is granted only to the virtual resources in the DC, and even if the workstation or thin client is compromised, no gain can be had from that endpoint. This type of setup is more for large enterprises, or high security environments. Just thought I would throw this out as a possible answer.
Just disable the sticky keys prompt from running when you press shift 5 times. Then when CMD is renamed to SETHC, it won't pop up. Solved.
Win7:
- Start > type "change how your keyboard works"
- Click the first option
- Click set up sticky keys
- Uncheck turn on sticky keys when shift is pressed 5 times.
You really don't need to have a Windows disc or image on a USB either to make the exploit work. I'm trying to say that disabling the PC from starting from a different drive than the internal system drive won't prevent the exploit from being performed. This workaround is done by resetting the computer when it's starting up and using a startup repair to get access to the file system to rename CMD to SETHC. Sure, it's hard on the disk drive, but if you're breaking into somebody else's machine, you don't really care.