One password, every laptop: lateral movement and why you need Windows LAPS

The password everybody knows#

Somewhere in your estate there is probably a local administrator account with a password that is identical on every machine.

It started as a good idea. Someone needed a way into a laptop that had fallen off the domain, or off Entra, or could not reach the VPN. The password went into the build script, the golden image, the Autopilot provisioning script, the RMM, and a spreadsheet. It worked, it still works, and nobody has touched it since.

This is a post about why that single password is one of the cheapest lateral movement tools an attacker can be handed, why it keeps surviving, and how to get rid of it with Windows LAPS using Intune and Entra.

What lateral movement actually needs#

Attackers rarely land on the machine they want. They land on whatever a user clicked on, then they move. Lateral movement is the work of getting from that first foothold to the systems that matter: file servers, backup servers, domain controllers, the machine the finance team uses.

To move, an attacker needs three things: a way to authenticate, a path to the next machine, and a reason to believe it will work. Shared local admin credentials supply the first and third for free.

Here is the typical sequence.

1. The attacker gets code execution on one workstation, usually as a standard user.
2. They get local admin on it, through a privilege escalation, a misconfiguration, or because the user already had admin rights.
3. They dump local credentials. The SAM database holds the NTLM hash of every local account, and tools like Impacket's secretsdump do this without fuss.
4. They try that hash against other machines on the network over SMB, WinRM, or remote service creation.
5. If the password is shared, every attempt succeeds.

Step 4 is the important one. This is pass the hash. The attacker never needs to know the password, because Windows will accept the hash itself as proof. A long, complex shared password gives you no protection here. The hash of a 30 character random string is exactly as reusable as the hash of Summer2019!. What matters is not how strong the password is, but how many machines accept it.

This is also why the grey zone I wrote about in the post on living off the land is so hard to see. The logon is a valid account, to a valid machine, over a valid protocol. Nothing is malware. The Sophos Active Adversary Report found Impacket in 36% of observed tooling and attackers reaching Active Directory in roughly 3.4 hours. A shared local admin password is one of the things that makes that speed possible.

One machine becomes all machines#

The blast radius is the part people underestimate, so it is worth being concrete.

With unique local passwords, compromising one workstation gets the attacker one workstation. They still need to find another credential, and every extra step is another chance for something to notice.

With a shared password, compromising one workstation gets the attacker every machine that shares it. If the same password is used on servers, it includes them. If it is baked into your build process, it includes machines that do not exist yet. If a former contractor, an old MSP, or a departed engineer ever knew it, it includes them as well.

It also turns a contained incident into an unscoped one. When you investigate a single compromised laptop, the question "where else could they have gone?" has an answer: nowhere, as far as the credentials show. With a shared password the honest answer is "anywhere reachable on the network", and you cannot rule it out.

A note on the built-in Administrator#

The details of how Windows treats local accounts over the network matter here, and they explain why the built-in account is the favourite target.

By default, remote UAC filtering gives non-RID-500 local administrators a filtered, standard-user token when they connect over the network. That blocks a lot of pass the hash attempts against ordinary local admin accounts. The built-in Administrator account (RID 500) is not filtered by default, so a network logon with it gets a full administrative token.

That is why the built-in Administrator account is such a common target. It is disabled by default on Windows clients, but plenty of environments enable it for support and give it the same password everywhere. And it is why some teams quietly set LocalAccountTokenFilterPolicy to 1 to make their remote management tools work, which removes the filtering for every local admin. If you have done that, the exposure is wider than the built-in account.

Why shared local admin passwords still exist#

If this is so well known, why is it still everywhere? Because every reason for it is a convenience, and the cost is deferred.

• It is how the estate was built. Older images, old deployment scripts, and old Autopilot profiles carry the password forward. Nobody chose it, it was inherited.
• Rotating it is scary. A password baked into services, scheduled tasks, backup jobs, and RMM profiles is a dependency nobody mapped. Changing it might break something at 2am, so nobody changes it.
• The recovery story feels solved. "If the device falls off the network, we log in with the admin password." That is a real need. It is the need LAPS exists to meet, and the shared password is just a worse way of meeting it.
• Offboarding does not touch it. When an engineer leaves, their account is disabled. The shared password they knew is not rotated, because rotating it means touching every device. So it never changes, and the number of people who know it only grows.
• It lives in the wrong places. Spreadsheets, a SharePoint library, a wiki page, a documentation platform, and sometimes a PowerShell script in Intune with the password in plain text. Anyone with the right Intune role can read that script, and a copy is downloaded to every device that runs it.

None of this is negligence. It is the normal result of a convenient shortcut that never got a deadline. But the people it hurts are real: the helpdesk engineer who inherits the risk without being told, the small team who is now explaining an estate-wide compromise, and the users whose data was on the machine the attacker pivoted to.

What Windows LAPS gives you#

Windows LAPS (Local Administrator Password Solution) takes the shared password out of the picture. Each device manages the password of a local administrator account, sets it to a random value, stores it centrally, and rotates it on a schedule.

Some details worth knowing before you plan the rollout:

• It is built in. Windows LAPS ships with Windows 11 and Windows 10, and with Windows Server 2019 and later, as part of the cumulative updates from 11 April 2023 onward. There is nothing to install. It is separate from the old legacy Microsoft LAPS MSI, and the two can run side by side during a migration as long as they manage different accounts.
• It backs up to Entra ID or Active Directory. Entra-joined devices escrow to Entra. Hybrid-joined devices can escrow to either, but not both. This post covers Entra, because that is where Intune lives.
• Entra-joined and hybrid-joined only. Devices that are only Entra registered, as is typical for BYOD, are not covered.
• Every device gets its own password. Length and complexity are policy settings, and each rotation produces a new random value.
• Retrieval is audited. Reading a password is an action in the Entra audit log, so you can see who looked and when.
• Passwords can rotate after use. A post-authentication action can reset the password, and optionally sign out the account, a set time after someone retrieves and uses it. A password that has been shown to a person does not stay valid forever.
• Automatic account management. Windows LAPS can create and manage a dedicated local admin account for you, with an optional randomised name. This is the cleanest way to stop depending on the built-in Administrator.

What it does not do is manage domain accounts, fix users who run as local admin, or replace proper privileged access management. It solves one specific, high-value problem: the same local credential on many machines.

Migrating off the shared password#

The mistake to avoid is turning LAPS on and immediately deleting the old account. The shared account probably has dependencies you have not found yet. Work in phases.

1. Check the prerequisites#

• Devices are on a Windows build with the April 2023 or later cumulative update, which in practice means keeping Windows 10 and 11 current.
• Devices are Entra joined or hybrid joined, not just registered.
• Who needs to read passwords? Cloud Device Administrator, Intune Administrator and Global Administrator can by default. Decide now whether you want a custom role scoped to just password recovery instead.

2. Enable LAPS in Entra#

In the Entra admin centre, go to Devices > Device settings and set Enable Microsoft Entra Local Administrator Password Solution (LAPS) to Yes. This is a tenant-wide switch and it does nothing on its own. No password is escrowed until a device receives a LAPS policy.

3. Inventory the old account and its dependencies#

This is the step that makes the rest safe. Before you change anything, find out:

• Which accounts are in the local Administrators group on your devices. A script or remediation that reports Get-LocalGroupMember -Group Administrators across the fleet is enough. Check licensing for Intune Remediations if you plan to use them, otherwise a platform script that writes the results somewhere you can collect them works.
• Where the password is stored. Build scripts, Autopilot provisioning, images, RMM profiles, documentation.
• What uses the account. Services, scheduled tasks, backup jobs, monitoring agents, and third party management tools that log in with it. These are the things that break.

Write down the answer for each. Anything that depends on the shared account needs a replacement before you retire it.

4. Decide which account LAPS manages#

You have two realistic choices:

Manage the built-in Administrator. This is the simple option, because the account already exists everywhere. The catches are that it is the RID 500 account attackers aim for, and that it is disabled by default on clients, so you have to enable it.

Let LAPS create a dedicated account (automatic account management). You get a clean account that exists only for this purpose, optionally with a randomised name, and you can leave the built-in account disabled. The catch is that tools or scripts that hard-code the old account name will not find the new one.

My preference is the dedicated account, with the built-in Administrator left disabled. It shrinks what an attacker can predict, and it forces you to find the dependencies, which you needed to do anyway.

5. Create the Intune policy#

In the Intune admin centre, go to Endpoint security > Account protection and create a Local admin password solution (Windows LAPS) policy. The settings that matter most:

• Backup directory: Backup the password to Microsoft Entra ID.
• Administrator account name: the account to manage. Leave it unset for the built-in account, or set the name or prefix when using automatic account management.
• Password complexity and length: the default of 14 characters with all four character classes is a reasonable floor, and there is no cost to raising it. Newer Windows builds also add passphrase options, which are easier to read out over the phone.
• Password age: 30 days is the default, and shorter is fine. Entra allows between 7 and 365.
• Post-authentication actions and reset delay: reset the password, and sign out the managed account, after retrieval. A delay of a few hours is enough for a technician to finish the job. The default is 24.

Assign the policy to device groups, not users. LAPS is a per-device setting, and a user-targeted assignment will not behave the way you expect.

Do not also configure LAPS through Group Policy for the same devices unless you mean to. Policy precedence means a GPO can override what Intune sends, and conflicting configuration is the commonest reason a policy shows as applied while nothing happens.

6. Pilot, then verify properly#

Assign the policy to a pilot group, ideally a mix of device types that includes at least one machine that moves between networks. Then check, rather than assume:

• On the device: the Microsoft > Windows > LAPS > Operational event log shows whether policy was processed and whether the password was escrowed. Get-LapsDiagnostics gathers the details, and Invoke-LapsPolicyProcessing forces a run instead of waiting for the next cycle.
• In Intune: the device's Local admin password blade shows the password and when it was last rotated.
• From PowerShell: Get-LapsAADPassword -DeviceIds <name> -IncludePasswords -AsPlainText returns the same value, which is what your helpdesk may use.
• In the audit log: confirm the retrieval you just did was recorded.
• Rotation: test the on-demand Rotate local admin password device action in Intune, and test the post-authentication reset by retrieving and using a password.
• Actually log in with it. Sign in locally with the LAPS password on a pilot device. The test that matters is whether the recovery path works when you need it.

A LAPS password only exists in Entra after the device has processed the policy and escrowed it. A device that has been off, or cannot reach Entra, keeps its old password until it does. Plan for that during the transition.

7. Roll out in rings#

Move through your normal deployment rings. Watch the Intune policy report for errors, and watch the helpdesk queue for anything that broke. Every failure at this stage is a dependency you missed in step 3, and finding it now is the point.

8. Retire the shared account#

Once a device has a LAPS-managed password and you are satisfied nothing depends on the old one:

• Disable or remove the old shared account. Do not just change its password, because a different shared password is still a shared password.
• Remove the password from build scripts, images, Autopilot profiles, RMM profiles, and documentation. This is the step people skip, and it leaves an old credential that looks valid in a document to everyone who finds it.
• Treat the old password as compromised. If it has been in a spreadsheet or a script for years, assume somebody has seen it.

Protecting what LAPS creates#

LAPS does not eliminate privileged credentials. It moves them into Entra, and makes them unique. That makes the retrieval path the new thing worth defending.

• Limit who can read passwords. Use the custom role for password recovery rather than handing out broad admin roles, and make that role eligible through Privileged Identity Management instead of permanently assigned. This fits the same logic as in my post on PowerShell guardrails for admins: time-bound elevation beats standing access.
• Alert on retrieval. Send the Recover device local administrator password audit event to your SIEM or detection platform. A technician reading a password during a ticket is normal. Someone reading fifty in ten minutes is not.
• Protect the admins who can retrieve. Anyone who can read the passwords is now as sensitive as the passwords. They need phishing-resistant MFA and compliant devices, as I covered in conditional access patterns that survive real users.
• Block network logon for local accounts. Add Deny access to this computer from the network for the well known group Local account and member of Administrators group (S-1-5-114). It is a standard pass the hash mitigation, and you can deploy it from the Intune settings catalog. It means a local credential can still be used at the keyboard, but cannot be used across the network, even if stolen.
• Reduce workstation to workstation traffic. Most endpoints have no reason to accept inbound SMB, WinRM, or RDP from other endpoints. Host firewall rules that block this remove the path lateral movement needs, whatever credential the attacker holds.
• Keep the break-glass story honest. LAPS passwords rely on a working Entra and Intune path. Keep documented, tested recovery for the case where those are the thing that is broken.

What LAPS will not fix#

It is worth being clear about the limits, because LAPS can feel like a finish line when it is a first step.

• Users with standing local admin rights. If the person using the laptop is an administrator, the attacker already has what they need on that machine, and may not need the LAPS account at all.
• Domain credentials left behind. Cached or live domain admin and service account credentials on a workstation are a bigger prize than a local account. Tier your admin accounts so privileged credentials never touch ordinary endpoints.
• Reused service account passwords. The same pattern, one secret and many systems, exists for service accounts. Look for it next.
• Unmonitored movement. LAPS makes the attack harder. It does not tell you it happened. You still need detection that notices an account authenticating somewhere it never has, which is the job of the monitoring I covered in Identity risk is rising: why ITDR belongs in every security programme.

A short checklist#

1. Confirm Windows builds are April 2023 or later, and devices are Entra or hybrid joined.
2. Enable Windows LAPS in Entra device settings.
3. Inventory local admins and everything that depends on the old shared account.
4. Choose the managed account, preferably a dedicated one created by LAPS.
5. Create the Intune LAPS policy and assign it to device groups.
6. Pilot, then verify escrow, retrieval, rotation, audit, and an actual local logon.
7. Roll out in rings and fix every dependency you find.
8. Disable the shared account and remove its password from every script, image, and document.
9. Restrict and alert on password retrieval, and deny network logon for local accounts.

Closing#

A shared local admin password is a quiet kind of risk. It does not alert, it does not age badly in any way you can see, and it does not cause trouble until the day it becomes the reason one compromised laptop turns into a compromised estate.

Windows LAPS is free, built into the operating system, and manageable from the Intune console you probably already use. The migration is mostly an inventory exercise, and the inventory is the part that makes the rest safe. The result is that when the next workstation is compromised, the attacker gets one workstation, and your investigation has a boundary.

References#

Sources and further reading for the claims above.

• Microsoft Learn, Windows LAPS overview
• Microsoft Learn, Windows LAPS policy settings
• Microsoft Learn, Windows LAPS CSP
• Microsoft Learn, Microsoft Entra: manage local administrator passwords with Windows LAPS
• Microsoft Learn, Windows LAPS with Intune
• Microsoft Learn, User Account Control and remote restrictions
• Microsoft Learn, Local Accounts
• Microsoft Learn, Privileged Identity Management
• Sophos X-Ops, 2026 Active Adversary Report
• MITRE ATT&CK TA0008, Lateral Movement
• MITRE ATT&CK T1550.002, Use Alternate Authentication Material: Pass the Hash
• MITRE ATT&CK T1003.002, OS Credential Dumping: Security Account Manager
• MITRE ATT&CK T1021.002, Remote Services: SMB/Windows Admin Shares
• MITRE ATT&CK T1078.003, Valid Accounts: Local Accounts