How to prevent the sethc.exe hack?











up vote
15
down vote

favorite
7












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?










share|improve this question




















  • 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















up vote
15
down vote

favorite
7












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?










share|improve this question




















  • 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













up vote
15
down vote

favorite
7









up vote
15
down vote

favorite
7






7





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?










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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














  • 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










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).






share|improve this answer






























    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.






    share|improve this answer

















    • 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


















    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.






    share|improve this 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


















    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:




    1. Start > type "change how your keyboard works"

    2. Click the first option

    3. Click set up sticky keys

    4. 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.






    share|improve this answer




















      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).






      share|improve this answer



























        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).






        share|improve this answer

























          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).






          share|improve this answer














          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).







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 19 at 17:05









          Santropedro

          256419




          256419










          answered Mar 23 '14 at 21:54









          eToThePiIPower

          48549




          48549
























              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.






              share|improve this answer

















              • 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















              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.






              share|improve this answer

















              • 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













              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.






              share|improve this answer












              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.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              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














              • 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










              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.






              share|improve this 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















              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.






              share|improve this 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













              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.






              share|improve this 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.







              share|improve this answer












              share|improve this answer



              share|improve this 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


















              • 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










              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:




              1. Start > type "change how your keyboard works"

              2. Click the first option

              3. Click set up sticky keys

              4. 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.






              share|improve this answer

























                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:




                1. Start > type "change how your keyboard works"

                2. Click the first option

                3. Click set up sticky keys

                4. 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.






                share|improve this answer























                  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:




                  1. Start > type "change how your keyboard works"

                  2. Click the first option

                  3. Click set up sticky keys

                  4. 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.






                  share|improve this 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:




                  1. Start > type "change how your keyboard works"

                  2. Click the first option

                  3. Click set up sticky keys

                  4. 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.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jun 26 '14 at 12:31









                  user322263

                  311




                  311

















                      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?



                      Popular posts from this blog

                      flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                      Mangá

                      Eduardo VII do Reino Unido