How to prevent the sethc.exe hack?
up vote
15
down vote
favorite
There is an exploit that allows users to reset the Administrator password on Windows. It is done by booting from a repair disk, starting command prompt, and replacing C:WindowsSystem32sethc.exe with C:WindowsSystem32cmd.exe.
When the sticky key combination is pressed at the logon screen, users get access to a command prompt with Administrator privileges.
This is a huge security hole, makes the OS vulnerable to anyone with even the slightest IT knowledge. It almost makes you want to switch to Mac or Linux. How can it be prevented?
windows-7 windows security system-repair-disc
add a comment |
up vote
15
down vote
favorite
There is an exploit that allows users to reset the Administrator password on Windows. It is done by booting from a repair disk, starting command prompt, and replacing C:WindowsSystem32sethc.exe with C:WindowsSystem32cmd.exe.
When the sticky key combination is pressed at the logon screen, users get access to a command prompt with Administrator privileges.
This is a huge security hole, makes the OS vulnerable to anyone with even the slightest IT knowledge. It almost makes you want to switch to Mac or Linux. How can it be prevented?
windows-7 windows security system-repair-disc
3
I really don't get what's the fuzz about it. It's not like there aren't utilities out there that can reset admin passwords (like the ones on Hiren's BCD or Win7Live). If the attacker can change the sethc file then he can use some reset utility...
– EliadTech
Mar 24 '14 at 8:35
25
If someone has physical access to your computer, you can kiss security goodbye.
– Bert
Jun 26 '14 at 12:35
2
It almost makes you want to switch to linux, where if you boot a repair disk you can just change the administrator password without the need of all the hack...
– pqnet
Mar 25 at 7:17
add a comment |
up vote
15
down vote
favorite
up vote
15
down vote
favorite
There is an exploit that allows users to reset the Administrator password on Windows. It is done by booting from a repair disk, starting command prompt, and replacing C:WindowsSystem32sethc.exe with C:WindowsSystem32cmd.exe.
When the sticky key combination is pressed at the logon screen, users get access to a command prompt with Administrator privileges.
This is a huge security hole, makes the OS vulnerable to anyone with even the slightest IT knowledge. It almost makes you want to switch to Mac or Linux. How can it be prevented?
windows-7 windows security system-repair-disc
There is an exploit that allows users to reset the Administrator password on Windows. It is done by booting from a repair disk, starting command prompt, and replacing C:WindowsSystem32sethc.exe with C:WindowsSystem32cmd.exe.
When the sticky key combination is pressed at the logon screen, users get access to a command prompt with Administrator privileges.
This is a huge security hole, makes the OS vulnerable to anyone with even the slightest IT knowledge. It almost makes you want to switch to Mac or Linux. How can it be prevented?
windows-7 windows security system-repair-disc
windows-7 windows security system-repair-disc
edited Mar 23 '14 at 21:36
asked Mar 23 '14 at 21:26
Jesus Pedro
81114
81114
3
I really don't get what's the fuzz about it. It's not like there aren't utilities out there that can reset admin passwords (like the ones on Hiren's BCD or Win7Live). If the attacker can change the sethc file then he can use some reset utility...
– EliadTech
Mar 24 '14 at 8:35
25
If someone has physical access to your computer, you can kiss security goodbye.
– Bert
Jun 26 '14 at 12:35
2
It almost makes you want to switch to linux, where if you boot a repair disk you can just change the administrator password without the need of all the hack...
– pqnet
Mar 25 at 7:17
add a comment |
3
I really don't get what's the fuzz about it. It's not like there aren't utilities out there that can reset admin passwords (like the ones on Hiren's BCD or Win7Live). If the attacker can change the sethc file then he can use some reset utility...
– EliadTech
Mar 24 '14 at 8:35
25
If someone has physical access to your computer, you can kiss security goodbye.
– Bert
Jun 26 '14 at 12:35
2
It almost makes you want to switch to linux, where if you boot a repair disk you can just change the administrator password without the need of all the hack...
– pqnet
Mar 25 at 7:17
3
3
I really don't get what's the fuzz about it. It's not like there aren't utilities out there that can reset admin passwords (like the ones on Hiren's BCD or Win7Live). If the attacker can change the sethc file then he can use some reset utility...
– EliadTech
Mar 24 '14 at 8:35
I really don't get what's the fuzz about it. It's not like there aren't utilities out there that can reset admin passwords (like the ones on Hiren's BCD or Win7Live). If the attacker can change the sethc file then he can use some reset utility...
– EliadTech
Mar 24 '14 at 8:35
25
25
If someone has physical access to your computer, you can kiss security goodbye.
– Bert
Jun 26 '14 at 12:35
If someone has physical access to your computer, you can kiss security goodbye.
– Bert
Jun 26 '14 at 12:35
2
2
It almost makes you want to switch to linux, where if you boot a repair disk you can just change the administrator password without the need of all the hack...
– pqnet
Mar 25 at 7:17
It almost makes you want to switch to linux, where if you boot a repair disk you can just change the administrator password without the need of all the hack...
– pqnet
Mar 25 at 7:17
add a comment |
4 Answers
4
active
oldest
votes
up vote
15
down vote
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).
add a comment |
up vote
7
down vote
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.
2
+1 One of many... You drove a fencepost, the attacker walks around it.
– Fiasco Labs
Mar 23 '14 at 22:00
If you have physical access, one can usually reset BIOS/UEFI settings to factory default.
– Scolytus
Jul 31 '16 at 10:43
add a comment |
up vote
4
down vote
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.
I setup just such an environment and got screwed. 2 problems i wasnt able to solve: the user cracks the Local admin password on the thin client and since the TC is under Active Directory on the server,the local admin shares a folder and maps it in his VM and transfers it out. Second problem : the user uses a simple screen recorder to take the data out while initiating a RDP.
– Akshay Immanuel D
Jul 4 '16 at 17:17
why do folders shared by a Local admin(not server admin) on a xp/win 7 machine in a server domain ,able to share folders that can be mapped on a VM on the server in Hyper-V
– Akshay Immanuel D
Jul 4 '16 at 17:24
add a comment |
up vote
3
down vote
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.
add a comment |
protected by Community♦ Apr 14 '16 at 0:22
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
15
down vote
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).
add a comment |
up vote
15
down vote
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).
add a comment |
up vote
15
down vote
up vote
15
down vote
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).
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).
edited Nov 19 at 17:05
Santropedro
256419
256419
answered Mar 23 '14 at 21:54
eToThePiIPower
48549
48549
add a comment |
add a comment |
up vote
7
down vote
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.
2
+1 One of many... You drove a fencepost, the attacker walks around it.
– Fiasco Labs
Mar 23 '14 at 22:00
If you have physical access, one can usually reset BIOS/UEFI settings to factory default.
– Scolytus
Jul 31 '16 at 10:43
add a comment |
up vote
7
down vote
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.
2
+1 One of many... You drove a fencepost, the attacker walks around it.
– Fiasco Labs
Mar 23 '14 at 22:00
If you have physical access, one can usually reset BIOS/UEFI settings to factory default.
– Scolytus
Jul 31 '16 at 10:43
add a comment |
up vote
7
down vote
up vote
7
down vote
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.
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.
answered Mar 23 '14 at 21:55
Michael Frank
5,96412642
5,96412642
2
+1 One of many... You drove a fencepost, the attacker walks around it.
– Fiasco Labs
Mar 23 '14 at 22:00
If you have physical access, one can usually reset BIOS/UEFI settings to factory default.
– Scolytus
Jul 31 '16 at 10:43
add a comment |
2
+1 One of many... You drove a fencepost, the attacker walks around it.
– Fiasco Labs
Mar 23 '14 at 22:00
If you have physical access, one can usually reset BIOS/UEFI settings to factory default.
– Scolytus
Jul 31 '16 at 10:43
2
2
+1 One of many... You drove a fencepost, the attacker walks around it.
– Fiasco Labs
Mar 23 '14 at 22:00
+1 One of many... You drove a fencepost, the attacker walks around it.
– Fiasco Labs
Mar 23 '14 at 22:00
If you have physical access, one can usually reset BIOS/UEFI settings to factory default.
– Scolytus
Jul 31 '16 at 10:43
If you have physical access, one can usually reset BIOS/UEFI settings to factory default.
– Scolytus
Jul 31 '16 at 10:43
add a comment |
up vote
4
down vote
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.
I setup just such an environment and got screwed. 2 problems i wasnt able to solve: the user cracks the Local admin password on the thin client and since the TC is under Active Directory on the server,the local admin shares a folder and maps it in his VM and transfers it out. Second problem : the user uses a simple screen recorder to take the data out while initiating a RDP.
– Akshay Immanuel D
Jul 4 '16 at 17:17
why do folders shared by a Local admin(not server admin) on a xp/win 7 machine in a server domain ,able to share folders that can be mapped on a VM on the server in Hyper-V
– Akshay Immanuel D
Jul 4 '16 at 17:24
add a comment |
up vote
4
down vote
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.
I setup just such an environment and got screwed. 2 problems i wasnt able to solve: the user cracks the Local admin password on the thin client and since the TC is under Active Directory on the server,the local admin shares a folder and maps it in his VM and transfers it out. Second problem : the user uses a simple screen recorder to take the data out while initiating a RDP.
– Akshay Immanuel D
Jul 4 '16 at 17:17
why do folders shared by a Local admin(not server admin) on a xp/win 7 machine in a server domain ,able to share folders that can be mapped on a VM on the server in Hyper-V
– Akshay Immanuel D
Jul 4 '16 at 17:24
add a comment |
up vote
4
down vote
up vote
4
down vote
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.
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.
answered Sep 8 '14 at 17:38
MiTePython
511
511
I setup just such an environment and got screwed. 2 problems i wasnt able to solve: the user cracks the Local admin password on the thin client and since the TC is under Active Directory on the server,the local admin shares a folder and maps it in his VM and transfers it out. Second problem : the user uses a simple screen recorder to take the data out while initiating a RDP.
– Akshay Immanuel D
Jul 4 '16 at 17:17
why do folders shared by a Local admin(not server admin) on a xp/win 7 machine in a server domain ,able to share folders that can be mapped on a VM on the server in Hyper-V
– Akshay Immanuel D
Jul 4 '16 at 17:24
add a comment |
I setup just such an environment and got screwed. 2 problems i wasnt able to solve: the user cracks the Local admin password on the thin client and since the TC is under Active Directory on the server,the local admin shares a folder and maps it in his VM and transfers it out. Second problem : the user uses a simple screen recorder to take the data out while initiating a RDP.
– Akshay Immanuel D
Jul 4 '16 at 17:17
why do folders shared by a Local admin(not server admin) on a xp/win 7 machine in a server domain ,able to share folders that can be mapped on a VM on the server in Hyper-V
– Akshay Immanuel D
Jul 4 '16 at 17:24
I setup just such an environment and got screwed. 2 problems i wasnt able to solve: the user cracks the Local admin password on the thin client and since the TC is under Active Directory on the server,the local admin shares a folder and maps it in his VM and transfers it out. Second problem : the user uses a simple screen recorder to take the data out while initiating a RDP.
– Akshay Immanuel D
Jul 4 '16 at 17:17
I setup just such an environment and got screwed. 2 problems i wasnt able to solve: the user cracks the Local admin password on the thin client and since the TC is under Active Directory on the server,the local admin shares a folder and maps it in his VM and transfers it out. Second problem : the user uses a simple screen recorder to take the data out while initiating a RDP.
– Akshay Immanuel D
Jul 4 '16 at 17:17
why do folders shared by a Local admin(not server admin) on a xp/win 7 machine in a server domain ,able to share folders that can be mapped on a VM on the server in Hyper-V
– Akshay Immanuel D
Jul 4 '16 at 17:24
why do folders shared by a Local admin(not server admin) on a xp/win 7 machine in a server domain ,able to share folders that can be mapped on a VM on the server in Hyper-V
– Akshay Immanuel D
Jul 4 '16 at 17:24
add a comment |
up vote
3
down vote
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.
add a comment |
up vote
3
down vote
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.
add a comment |
up vote
3
down vote
up vote
3
down vote
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.
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.
answered Jun 26 '14 at 12:31
user322263
311
311
add a comment |
add a comment |
protected by Community♦ Apr 14 '16 at 0:22
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
3
I really don't get what's the fuzz about it. It's not like there aren't utilities out there that can reset admin passwords (like the ones on Hiren's BCD or Win7Live). If the attacker can change the sethc file then he can use some reset utility...
– EliadTech
Mar 24 '14 at 8:35
25
If someone has physical access to your computer, you can kiss security goodbye.
– Bert
Jun 26 '14 at 12:35
2
It almost makes you want to switch to linux, where if you boot a repair disk you can just change the administrator password without the need of all the hack...
– pqnet
Mar 25 at 7:17