I'm working on a mechanism to better handle group policy passwords in response to MS14-025. We formerly used this mechanism for setting the local admin account passwords on our workstations (primarily Windows 7)

To this end (see the method I've outlined below for specifics) my thought is to have these changed client side via a scheduled task and save the resulting password to a restricted access network drive. What kind of exposure am I creating by allowing these changes to occur locally, instead of pushing out from a central location?

The only thing I've come up with are memory scrapers and the ability to manipulate the random number generator.. Both of which should require admin rights already.



  1. Avoid storing plain text passwords in a GPP item.
  2. Rotation on these passwords
  3. Set unique password per device (avoid pass the hash attacks)

Proposed Method

  1. Set up a scheduled task (deployed by group policy preference, using the system account)
    1. Schedule monthly / quarterly / whatever
    2. Run on local Admin login, after 30 minutes
  2. Task runs executable / script which will
    1. Set the admin password to a random string
    2. Save password to a network directory, using computer name for reference
  3. Enable auditing / restricted access rights / etc on this folder.

Combined with a secondary trigger - say 30 minutes after the local admin account is logged in to - and we'd have a pretty decent method for controlling these accounts with the additional benefit of knowing whomever is using the local Administrator account.

  • Why are you not using the PowerShell script that Microsoft recommends?
    – longneck
    Commented Jun 6, 2014 at 16:41
  • @longneck - it doesn't meet all my requirements. Commented Jun 6, 2014 at 16:44

1 Answer 1


I did come up with a couple potential additional attack vectors.

  • A lot of languages use a date / time stamp for setting up their random number generators. This results in getting the same 'random' password for all tasks executed in parallel. A potential fix is here.
  • On the interface / on the wire capture of account / password details. This can be mitigated with IPsec.

Depending on implementation either of these could allow either lateral or vertical privilege escalation.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .