Errant Security

If you have ever cursed at your keyboard after setting your elbow on the shift key for time you can blame the “sethc.exe” executible. Its an ease of use feature built into windows for those who might be physically challenged and cant press cntrl-alt-delete at the same time. It allows them to hit shift 5 times to enable sticky keys, then click cntrl then alt then delete to achieve the same result.

What it also allows is a clever persitence mechanicsm.

Windows 10 until the OCT KB4462919 update and windows 7 are affected.

If you have physical access to the box or existing system level access you can replace the file:

C:\> copy /y c:\windows\system32\cmd.exe c:\windows\system32\sethc.exe

or from *nix:

root@ubuntu# cp /mnt/sda3/Windows/System32/cmd.exe /mnt/sda3/Windows/System32/sethc.exe

Now that the file is replaced, when you go to execute the sticky key feature, windows will call the new sethc executible which is a copy of a command shell. Viola. You now have a system level shell.

Mitigation: There are a coulple ways to mitigate this if you are concerned about this. One: the most common use of this “feature” is not malicous actors, its sysadmins. Instead of running around with a huge password book, they replace this in the default image for the company. Whenever they are running around trying to help people with their computers, they dont need to use tokens or renmber domain level credentials. They just hit shift 5 times.

So good education on best practices and written rules for the company are a first step. Foot stomp: Security through obsurity is not a viable option.

Disk encryption: One of the common ways for a box to be comprmisied is to reboot the box and make these changes from another OS. Pizza delivery, janitor, random visitor walks into an area where they have 5 minutes bythem self. Boom. They have system reliably on the box and can then set up other implants for remote exploitation.

Disk encryption can help prevent people from modifying the System32 folder from another OS. Also disabling booting from external drives in bios will help if you set a bios password. Another thing your helpdesk guys will curse at you for.

If someone has remote access to the system this exploit can be triggered via RDP once its been set. Instead of living on a box where all the fancy AV and NSM tools can catch C2 out to the internet, people are dropping embedded linux devices (think rasp pi) with long range RF communications (XBEE for example can reach 2 miles LOS). So if you dont have proper port security and asset managment, they will hook up another device to the network and anytime they need to do anything, RDP from the jump box and have system again.

If you have RDP accessible from the publicaly routable internet and dont have a legitamate buisness need and proper custom configuations. Tweet at us on Twitter asking us about this and watch the fireworks. Or dont, but your on shodan anyways soo… cheers

Also the last easy one for mitigation. Update your system. The newest windows defender on patched systems check to see if sethc has been replaced.