4 ms·

> If you were able to drop that file, you're either that user, or an administrator on the computer. If you're that user, you could also achieve "single file cod

by wolrah 7y ago

> If you were able to drop that file, you're either that user, or an administrator on the computer. If you're that user, you could also achieve "single file code execution" by dropping a file to the startup folder, or creating an autorun registry key. If you are an administrator, you already own the machine. As I see it the biggest practical issue with this is that it provides a method for persistence that no user will ever find and even most Windows administrators will have no idea to look for.

gruez 7y ago
>As I see it the biggest practical issue with this is that it provides a method for persistence that no user will ever find This isn't relevant because if you're logged in as the affected user, nothing you see can be trusted because you're already pwned. For instance, the attacker could have replaced the regedit icon with a patched regedit, or attached a debugger to every process and patched any system calls. The only safe course of action would be to create a new profile. > and even most Windows administrators will have no idea to look for. AFAIK user hives aren't loaded until they're logged in, in which case they're subject to the caveats of the previous paragraph. Also, are administrators really going around and loading each user's registry hive to check for infections? The only real threat I can think of is antivirus vendors not knowing about this feature and not scanning the file as a registry hive.
- throwanem 7y ago
  As the article mentions, the threat model here is primarily an insider one, with a "rogue" user leveraging this method to obtain capabilities the domain administrator intends to deny. There are certainly more effective exploits for an outside attacker to use, but that's beside the point.
  - gruez 7y ago
    >As the article mentions, the threat model here is primarily an insider one, with a "rogue" user leveraging this method to obtain capabilities the domain administrator intends to deny What would be those capabilities? They'd have to be user-level policies, which already limits what you could do.
  - dfox 7y ago
    User Group Policy isn't exactly a security mechanism, it exists to prevent users from unintentionally breaking their profile. There is multitude of ways how the user in question can inject arbitrary code into processes that are affected by user group policy as these processes are owned by that user.

by wolrah 7y ago

gruez 7y ago

>As I see it the biggest practical issue with this is that it provides a method for persistence that no user will ever find This isn't relevant because if you're logged in as the affected user, nothing you see can be trusted because you're already pwned. For instance, the attacker could have replaced the regedit icon with a patched regedit, or attached a debugger to every process and patched any system calls. The only safe course of action would be to create a new profile. > and even most Windows administrators will have no idea to look for. AFAIK user hives aren't loaded until they're logged in, in which case they're subject to the caveats of the previous paragraph. Also, are administrators really going around and loading each user's registry hive to check for infections? The only real threat I can think of is antivirus vendors not knowing about this feature and not scanning the file as a registry hive.

throwanem 7y ago
As the article mentions, the threat model here is primarily an insider one, with a "rogue" user leveraging this method to obtain capabilities the domain administrator intends to deny. There are certainly more effective exploits for an outside attacker to use, but that's beside the point.
- gruez 7y ago
  >As the article mentions, the threat model here is primarily an insider one, with a "rogue" user leveraging this method to obtain capabilities the domain administrator intends to deny What would be those capabilities? They'd have to be user-level policies, which already limits what you could do.
- dfox 7y ago
  User Group Policy isn't exactly a security mechanism, it exists to prevent users from unintentionally breaking their profile. There is multitude of ways how the user in question can inject arbitrary code into processes that are affected by user group policy as these processes are owned by that user.