Protecting the Windows Infrastructure
Domain accounts of administrators and user support staff are the primary target for attackers. Having compromised such an account, an attacker gains the ability to spread quickly, penetrating deeper and deeper until control over critical infrastructure components is obtained: the Active Directory service, the virtualization platform, backup systems, and so on.
Access via the web portal
Access via the mobile app
Built-in TOTP provider
Mapping AD groups to OUs
Common weaknesses and threats of privileged access in MS Windows
An attacker can steal the account's password hash and use it to authenticate on other computers
By tricking a user into running malware via phishing, or by exploiting vulnerabilities in application software (office applications, browsers), an attacker obtains maximum privileges on the system, allowing the use of various defense-evasion techniques and low-level extraction of authentication data for further lateral movement
There are many techniques for stealing authentication data (passwords, password hashes, Kerberos tickets, certificate private keys). Having compromised a single domain account, an attacker immediately gains privileged access to all other hosts where that account is in groups allowing local or network logon. Combined with lateral movement and privilege escalation techniques, the attacker quickly expands their footprint in the infrastructure, progressively approaching critical components
According to Microsoft recommendations, privileged accounts of Tier-0 (domain administration), Tier-1 (server administration) and Tier-2 (workstation administration) must only be used from dedicated secure workstations (PAW). Every logon of a privileged account from a more critical tier to a lower-tier infrastructure component — for example, a Tier-0 domain administrator logging on to a Tier-2 workstation — must be treated as a compromise, because if that workstation is infected, the attacker has various ways to steal authentication data.
Smart cards and 2FA systems are a reliable way to protect access; however, after a successful logon to a host, the administrator's subsequent authentications to network resources use the Kerberos/NTLM protocols. So if an attacker already controls the host, they can use various techniques to compromise authentication artifacts and spawn new processes using the privileged user's tokens for lateral movement. Windows infrastructure protocols other than RDP, such as SMB, WinRM and RPC, fundamentally do not support embedding 2FA, because under the hood authentication uses the same Kerberos or NTLM.
- LAPS-managed passwords are stored in Active Directory. An attacker who gains access to an account with read rights on the password attribute can dump the passwords of all devices with a single query.
- There is no way to limit the GUI console session time for LAPS password access. If an attacker gains access to a workstation with a GUI console left open, they can retrieve passwords without the administrator present.
- Access to LAPS-managed passwords must be performed exclusively from dedicated secure workstations. When using MMC snap-ins or PowerShell scripts to access LAPS passwords from a "dirty" workstation, all passwords are at risk.
- There is no way to rate-limit password retrieval.
- There is no way to log the IP address from which a password was requested.
- In distributed infrastructures with several domain controllers, synchronization delays of LAPS-managed passwords of up to 40 minutes may occur. As a result, support staff connected to one domain controller may see stale passwords of workstations connected to another controller, where rotation has already happened but replication has not yet completed
Approach to protecting the Windows infrastructure
To hinder lateral movement and privilege escalation in the Windows infrastructure, the number of domain accounts with local administrator rights must be reduced as much as possible.
When local administrator rights on a host are required, passwords managed by MS/Windows LAPS should be used to the maximum extent, as they are unique and rotated automatically.
This approach eliminates one of the root causes of successful compromises — the ability to steal a privileged user's authentication data on a compromised host and reuse it elsewhere. It works especially well for the following scenarios:
- Workstation support by the help desk. The support engineer's domain account is no longer added to the local administrators group on the organization's workstations; when a privileged operation is needed, the engineer retrieves the local administrator password managed by MS/Windows LAPS
- Support of applications running on a group of Windows servers by the teams responsible for those applications.
- Granting rights to employees who need them for their duties, for example developers. The employee's domain account is not added to the local administrators group, which reduces the risk of compromise through exploitation of applications such as browsers, archivers or office software.
Protecting MS/Windows LAPS
WebLAPS is a web portal that eliminates the main threats and weaknesses inherent in standard ways of working with MS/Windows LAPS, through the following capabilities:
- WebLAPS can run on a Linux machine or a non-domain Windows machine to make compromise harder
- The ability to retrieve the local administrator password is granted only after two-factor authentication, or login plus OTP authentication, to reduce the risk of compromising the entered password
- Automatic session logout on inactivity, and also when a remote connection to the computer with an open WebLAPS session is detected
- Request count limits to hinder automated data export via the API
- Binding of authenticated sessions to the IP address
- Logging of password requests, including the IP address
- SIEM integration via syslog (CEF format)
- Automatic, configurable password expiration change immediately after a request
- Querying several domain controllers when searching for a password; if differing passwords are found, the portal displays all of them. When the password expiration date is changed, the new date is updated on all configured controllers
Password access control capabilities
WebLAPS implements a flexible role model that enables fine-grained access management in the following ways:
- binding an AD group to the OU containing the computers; all members of that group then get access to the local administrator passwords of computers in that OU and its nested OUs
- defining a computer object attribute, such as managedBy, and setting it to an account or a group; that account or all members of that group then get access to the local administrator password of only that computer. This is convenient for granting employees access to their own computers
LAPS Mobile app
To make working with WebLAPS more convenient, the LAPS Mobile app for iOS and Android has been developed, enabling secure remote access to local administrator passwords
Additional functions
WebLAPS provides the following useful functions:
- API for access to MS/Windows LAPS-managed passwords, with the ability to bind API keys to the source IP address and allowed OUs
- Agent for non-domain Windows machines. The agent automatically creates an account, changes its password on a schedule, adds it to the required groups and removes other accounts when necessary, according to configured policies
- Retrieval and access control of BitLocker recovery keys
- Just-in-Time Administration mode, allowing you to define a logical role, an AD group granting access to that role at the WebLAPS level, and a set of groups that WebLAPS will add the user to upon role activation and automatically remove when the time expires. The user's account is thus not permanently present in privileged groups; the portal adds the user to those groups only on request, for a limited time