Lateral Movement Use Case - Local Administrator's Password Reuse

  • 6 January 2022
  • 3 replies
  • 854 views
Miri Adjiashvili
Rank
Userlevel 3
Badge +2

As part of the Professional-Services packages we offer our clients, Cymulate’s security experts ran Lateral Movement campaign together with the clients. The main security misconfigurations our team identified were associated with the usage of golden images to deploy new servers and workstations.

The usage of golden images can help IT managers to easily deploy new endpoints in the network. By preconfiguring once, the IT team can rest assured the new endpoint will include all the necessary settings and configurations, without the need to configure each new endpoint every time. The problem starts, when the deployment procedure lacks changing the password of the local users on the new endpoint following the deployment.

By reusing the token of the local users, especially the local administrator user, a potential threat actor could easily move laterally and reach high risk network areas and critical assets. In severe cases, the Domain Controller’s local administrator password is reused as well, meaning the same password is used for the Domain Administrator user – and can lead to complete domain takeover.

The Lateral Movement campaign succeeded in identifying the vulnerability for a number of our customers, by escalating privileges on the local machine and reusing the token of the local Administrator account against other discovered machines in the network.

 

the example was executed against a test environment

 

We can see the Cymulate Hopper (Cymulate’s Lateral movement campaign beacon) successfully breached the Domain Controller by reusing the Administrator token from the local machine, BUSTER01, gaining domain admin privileges. Important to note, this was done in a matter of a few minutes.

This technique, which is widely used by attackers in order to move laterally and escalate privileges in the corporate network, is one of the attack vectors the Cymulate Lateral Movement campaign uses in order to spread in the given scope.

In order to mitigate this security gap, it is necessary to give each endpoint’s accounts a different password. The password should be random and include symbols and numbers. It is recommended to deploy a password manager solution, such as Microsoft LAPS, to help manage the local accounts users’ passwords.

3 replies

J
Userlevel 1

This is an age old problem that exists in more than just Windows….

 

If you use LAPS, ensure you lock it down in AD (permission/ACL).

 

Options off the top of my head:

  1. Set a GPO to rename and disable all local accounts.  Is that a problem ?  Only if you are helpdesk and don’t want to boot in safe mode.
  2. Use something like Lieberman Associates’ password manager that has unique password on every computer’s administrator account.  To retrieve the passwords, you logon to the app, retrieve the password and it changes the password again so it will never be used again. It also logs who retrieved the password!
  3. Use a PowerShell script to create random passwords that logs the PW to an encrypted txt file in a central/restricted directory with auditing enabled.  You can even monitor the event log and automate changing the password after X amount of time.
Miri Adjiashvili
Rank
Userlevel 3
Badge +2

This is an age old problem that exists in more than just Windows….

 

If you use LAPS, ensure you lock it down in AD (permission/ACL).

 

Options off the top of my head:

  1. Set a GPO to rename and disable all local accounts.  Is that a problem ?  Only if you are helpdesk and don’t want to boot in safe mode.
  2. Use something like Lieberman Associates’ password manager that has unique password on every computer’s administrator account.  To retrieve the passwords, you logon to the app, retrieve the password and it changes the password again so it will never be used again. It also logs who retrieved the password!
  3. Use a PowerShell script to create random passwords that logs the PW to an encrypted txt file in a central/restricted directory with auditing enabled.  You can even monitor the event log and automate changing the password after X amount of time.

Hi John,

Thank you for your valuable inputs,

This is indeed an old but very common problem.

I’ll happily address the additional remarks you pointed out:

  1. Disabling local admins can be challenging especially for big organizations that do not have the manpower to execute the described process, and for a large amount of physical/virtual servers.
  2. Using a password manager is a great solution to this issue. There are numerous solutions on the market, like LAPS and the one you mentioned, that uses the same technique.
  3. Although this is a great solution, there is a lot of risk involved (encryption method, access to the recourse, etc.). We recommend relying on known, validated and secure solutions rather than creating new ones from scratch. 
N
Rank
Badge

This is an age old problem that exists in more than just Windows….

 

If you use LAPS, ensure you lock it down in AD (permission/ACL).

 

Options off the top of my head:

  1. Set a GPO to rename and disable all local accounts.  Is that a problem ?  Only if you are helpdesk and don’t want to boot in safe mode.
  2. Use something like Lieberman Associates’ password manager that has unique password on every computer’s administrator account.  To retrieve the passwords, you logon to the app, retrieve the password and it changes the password again so it will never be used again. It also logs who retrieved the password!
  3. Use a PowerShell script to create random passwords that logs the PW to an encrypted txt file in a central/restricted directory with auditing enabled.  You can even monitor the event log and automate changing the password after X amount of time.

I would strongly recommend to use Microsoft’ LAPS over a custom implementation. There are some pitfalls that could be easily missed. For example, how do you ensure the process was successful? Is the process leaking secrets (such as to PowerShell Script Block logging)? Is the secrets’ network transfer secure? Could it be manipulated? Is the secrets’ storage really secure? etc.
When possible, opt for the vendor’s solution.

In addition to setting a strong and unique password to the local administrator, it is also worthwhile to configure the following measures:
1. Deny network access to local accounts
2. Enable UAC to filter administrative privileges for network logons (LocalAccountTokenFilterPolicy).


*I’m reluctant to add “change the built-in administrators name” because it only gives a false-sense of security and adds little value in my opinion.

 

Disclaimer: Workstation hardening requires careful attention - this discussion is far from enough to cover all the many security controls required to protect an environment.

 

Stay safe y’all!

Reply


Terms & ConditionsCookie settings