LAPS, Lateral Movement, and the Password You Forgot About
This one is going to be a little different from the last few posts I have written.
Most of my recent articles have been more programming-focused, with demos, code, and simulations. This one comes more from day-to-day operations in my role as an IT Sys Admin. Recently, while working on a domain controller upgrade, I found myself revisiting some of the points from my ransomware article, and it felt like the right time to write a follow-up. Not from theory, but from what we actually see in real environments.
Let me paint you a scenario.
You’ve got a fairly standard Active Directory environment. Nothing fancy, nothing broken, at least on the surface. Domain controllers are healthy, GPOs are in place, users are doing their thing, endpoints are patched most of the time, and you’ve got EDR running, maybe even something solid. On paper, everything looks right.
And to be fair, in many environments, especially across the hospitality sector here in the Maldives, this is exactly the case. Over the past 2 to 3 years, a number of ransomware incidents have hit properties that were not poorly built environments. These were setups that came from corporate standards, deployed properly, maintained with care, and aligned with what you would expect from any structured organization.
They had proper Active Directory structures, standard GPOs in place, corporate-driven deployments, and decent endpoint protection. There was nothing obviously broken.
And yet, somewhere in that same environment, quietly, there exists a local administrator account on every workstation.
Same name? Probably.
Same password? Yeah… most likely.
Now here’s the uncomfortable part. That one decision, usually made years ago for operational convenience, is one of the cleanest paths from a single compromised endpoint to full domain compromise.
And this is where things start to connect.
Because in many of these environments, the pattern is not negligence, it is practicality. It is easier for support, faster during operations, and it “just works,” especially in island environments where speed matters and delays are not an option.
In resorts especially, where IT teams are lean, response time is critical, and operations cannot afford delays, these kinds of decisions tend to stick. Not because they are correct, but because they are convenient. Until one day, they are not.
And when that single endpoint gets compromised, what looked like a well-structured and well-managed environment starts to behave very differently. Not because Active Directory failed, and not because EDR was not running, but because one small shared secret, repeated across every machine, was trusted a little too much.
And that is all an attacker really needs.
Table of Contents
- A Quick Callback (Not Another Ransomware Lecture)
- Let’s Walk Through a Real Attack Path
- The Critical Mistake: Local Admin Reuse
- Lateral Movement: The Actual Mechanics
- Why This Eventually Leads to Domain Compromise
- Where Microsoft LAPS Changes the Entire Equation
- Deployment: The Part That Actually Matters
- So Where Does That Leave Us
A Quick Callback (Not Another Ransomware Lecture)
If you have not read my earlier post, Ransomware: A Programmer’s Perspective on Prevention and AI Defense, I would strongly recommend starting there first, as this article builds directly on that foundation.
In that post, I broke ransomware down from a practical operations and defense perspective, covering what it is, how it evolved through major attacks, and more importantly the defensive layers that actually matter in the real world. Things like immutable and offsite backups, shadow copies, EDR/XDR, AI-driven protection, the role of MSSPs, and even a Python-based simulation to demonstrate how these attacks behave in practice.
This post picks up from where that one leaves off.
Because while the last article focused more on how ransomware gets in and how we defend against it, what we did not spend enough time on is what happens after the first machine is compromised.
And that part matters just as much.
Because ransomware operators today do not break in and start encrypting immediately. They get in, stay quiet, observe the environment, escalate privileges, and most importantly, reuse whatever the environment has already made available to them.
And in a lot of Windows environments, one of the easiest things we hand over to them is the same local administrator credential, repeated across every workstation like some kind of unspoken tradition.
That is where this post really begins.
Let’s Walk Through a Real Attack Path
No buzzwords. No dramatic hacker movie version. Just the sort of path that actually plays out in a Windows domain when one endpoint goes bad.
1. Initial Access
It usually starts with something ordinary. A malicious attachment, a browser-based exploit, or a user credential that should not have been exposed. A fake invoice, a booking document, a payroll sheet, pick your poison.
The attacker lands on one machine.
PC-023 (User: finance.exec)
At this stage, they are not powerful. They do not own the domain, and they do not necessarily have administrative rights yet. They are simply inside one endpoint, trying to understand whether that foothold can be expanded into something more.
In a resort or hospitality environment, that first machine is rarely a hardened jump server. It is usually a normal workstation in Reservations, Finance, HR, Front Office, or Back Office, sometimes even a shared operations machine that sees constant activity and trust.
That matters, because the more normal the machine looks, the less suspicious the attacker’s activity appears during those first few minutes.
2. Local Enumeration
The first question the attacker asks is simple: what do I have here, and what can I use?
They begin with basic enumeration.
whoami /all
net localgroup administrators
hostname
ipconfig /all
From here, they start building context. They check whether the current user has administrative rights, whether another privileged user has logged into the machine, whether there are mapped drives worth exploring, and whether there are any saved credentials, cached tokens, or management tools that can be leveraged.
This stage often looks harmless, but it is where the attacker decides whether they are stuck on one machine or standing at the entry point to the rest of the network.
3. Credential Extraction
If privilege escalation is possible, and in many cases it is, the next step is credential access.
At this point, the attacker shifts focus from the system itself to the identities that have interacted with it. They begin extracting data from LSASS memory, the local SAM database, the SECURITY hive, cached logon material, service accounts, and tokens left behind by administrative activity.
The specific tools used are less important than the outcome. The goal is simple: obtain something that can authenticate somewhere else.
What often comes out of this process looks like:
Local Administrator → NTLM hash
Cached domain credentials
Service account material
And this is where environment design starts to matter more than the malware itself.
The Critical Mistake: Local Admin Reuse
If your environment has the same local administrator password across machines, then what the attacker just extracted is not limited to that one endpoint.
Administrator (local)
Password: same on every machine
That credential effectively becomes administrative access across your entire workstation fleet.
The local account may seem insignificant. It may not be domain-based, it may not be used daily, and it may not be tightly controlled. But if it exists everywhere with the same password, it becomes a shared authentication key across the entire environment.
NTLM does not care about intent. If the credential works, it works.
To an attacker, that is not a local admin password anymore. It is a movement mechanism.
Lateral Movement: The Actual Mechanics
Lateral movement is often misunderstood as something advanced. In reality, it is simply authentication.
If an attacker can authenticate to another machine with sufficient privileges, they can execute code remotely and move there. If that works once, it will likely work again.
They begin testing access across the network.
wmic /node:PC-045 process call create "cmd.exe"
or
psexec \\PC-045 -u Administrator -hashes <NTLM>
If the environment is consistent, movement becomes predictable.
PC-023 -> PC-045 -> PC-011 -> PC-078
This spreads quickly, not because the attacker is sophisticated, but because the environment is.
Consistency is excellent for administration, but it also makes lateral movement trivial if credentials are reused.
Why This Eventually Leads to Domain Compromise
Initially, lateral movement is about reach. The attacker wants more machines, more visibility, and more opportunities.
Eventually, it becomes about privilege.
At some point, they land on a machine where an administrator has logged in, where a service account is active, or where higher-value credentials are available. They repeat the process, extract more data, and escalate further.
Once that happens, the environment is no longer protected by its perimeter. It is protected by how well internal access is segmented.
If credentials are shared, escalation is inevitable.
And at that point, ransomware is not the attack. It is just the final step.
Where Microsoft LAPS Changes the Entire Equation
Now replay the exact same scenario, but remove one assumption.
The local administrator password is no longer the same everywhere.
Each machine has its own unique password, centrally managed, rotated automatically, and stored securely in Active Directory with controlled access.
That single change breaks the chain.
A credential extracted from one machine is no longer valid anywhere else. Lateral movement is no longer trivial. The attacker is forced to slow down, reassess, and find alternative paths.
That is what LAPS actually solves.
What Actually Changes Internally
When LAPS is in place, the computer object in Active Directory becomes part of the password management flow.
Depending on whether you are using the current Windows LAPS model or the older legacy implementation, the relevant attributes will differ, but in the newer Microsoft LAPS implementation you will typically deal with attributes such as:
msLAPS-PasswordmsLAPS-PasswordExpirationTime
The endpoint itself generates the password locally, updates the managed local administrator account, and writes the value and expiration metadata back into Active Directory according to policy.
That means a few important things:
- The password is unique per device
- Rotation is policy-driven
- Retrieval is controlled by ACLs on the computer object
- Password access is no longer based on who “just knows the standard admin password”
The biggest win is not the storage location.
The biggest win is that a credential stolen from one endpoint stops being useful on the next one.
Replay the Attack
Let us go back to the same compromised machine:
PC-023
The attacker extracts the local administrator material from that endpoint:
Administrator -> NTLM hash
But this time, that credential belongs only to PC-023.
They try the same move as before:
psexec \\PC-045 -hashes <NTLM>
And this time it fails.
ACCESS DENIED
Not because the attacker suddenly got clumsy. Not because the EDR decided to save the day. But because the credential is valid for one machine and one machine only. That is the whole game. LAPS does not stop the initial compromise. It does not stop credential dumping. It does not magically clean up every privilege problem in the domain. What it does is far more practical. It stops a stolen local administrator credential from becoming a reusable pass into the rest of the environment.
And in real incidents, that can be the difference between one bad endpoint and a property-wide outage.
Deployment: The Part That Actually Matters
A lot of LAPS guides stop at “enable the policy and you’re done.”
That is how people end up with half-working deployments, over-permissioned AD objects, and no idea whether the rollout is actually secure.
So let us focus on the parts that matter in the real world.
Schema: Know What You Are Extending
When you run:
Update-LapsADSchema
you are modifying the Active Directory schema partition.
That matters because schema updates are forest-wide. This is not just another workstation policy setting you can casually roll back after lunch. It needs to be planned, understood, and verified.
Once the schema is updated, verify it properly:
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
-Filter 'Name -like "ms-LAPS-*"'
You should see the expected LAPS-related attributes present in the schema.
If you skip validation and move straight into GPO work, you are not deploying. You are guessing.
Permissions: This Is the Real Security Boundary
This is the part that matters most.
LAPS security is not just about generating a random password. It is about who can write it, who can read it, and how those rights are delegated.
When you run:
Set-LapsADComputerSelfPermission -Identity "OU=Workstations"
you are allowing computer objects in that OU to update their own managed password information in Active Directory.
Then when you run:
Set-LapsADReadPasswordPermission -Identity "OU=Workstations" -AllowedPrincipals "IT-Support"
you are defining who is allowed to retrieve those passwords.
That permission is not some nice extra detail.
That permission is the security model.
And because it is applied through ACL inheritance at the OU level, your OU structure suddenly matters a lot more than people think.
If your workstation objects are scattered badly, delegated badly, or inherited badly, LAPS will still work technically, but your control boundary becomes messy.
And messy boundaries are how sensitive rights end up wider than intended.
Common Mistake: Turning LAPS Into a Password Leak
This one deserves to be said plainly.
Some environments struggle during testing because the password is not readable when expected. Then somebody gets impatient, opens delegation too far, and effectively solves the wrong problem.
The result ends up looking like this:
Authenticated Users -> Read msLAPS-Password
At that point, congratulations, the local admin password is now centrally stored in Active Directory and broadly readable to the very people it was meant to be protected from.
That is not a managed password solution anymore.
That is a password distribution system.
If you are going to deploy LAPS, access to password retrieval should be deliberate, minimal, reviewed, and ideally tiered according to role.
ADMX: More Than Just Copying Files
Start by getting the right templates.
At the time of writing this, I recommend downloading the latest LAPS package directly from Microsoft here:
https://www.microsoft.com/en-us/download/details.aspx?id=105667
This gives you the ADMX and ADML files required for Group Policy.
Yes, technically the next step is simple. You take those files and place them into your Central Store:
\\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions
That part is straightforward.
What actually matters is everything around it.
- All domain controllers must be aligned on the same policy definitions
- SYSVOL replication needs to be healthy
- Group Policy Management must be loading the correct templates
- You should not be troubleshooting Central Store issues and assuming it is a LAPS problem
If the LAPS settings do not show up in Group Policy, the answer is almost never that Windows is “being strange”.
In most cases, it comes down to the Central Store not being clean, not being current, or not being replicated properly across domain controllers.
And if that foundation is off, everything that follows will look broken even when it is not.
Client Behavior: What Actually Happens on the Endpoint
Another important detail people often miss is this.
The domain controller does not rotate the local administrator password for the client.
The client does.
When policy applies, the endpoint checks whether the managed password has expired. If it has, the endpoint generates a new password, updates the local account, and writes the new value along with the expiration metadata back to Active Directory.
So the flow is roughly:
- Policy is applie
- Client checks expiration stat
- Client generates a new assword if required
- Local account is update
- AD attributes are updated
That means if a workstation is offline for an extended period, rotation does not happen in the background. The password lifecycle depends on the endpoint actually processing policy and being able to write back to Active Directory.
Now, in my environment, I take this one step further.
Instead of relying purely on time-based rotation, I enforce password reset on user logon. The moment a machine becomes active and a user logs in, the local administrator password is rotated again.
This effectively shortens the window of exposure.
Even if a credential was retrieved earlier, once that machine is used again, the password becomes invalid and a new one is generated.
From a security perspective, this adds another layer:
- Reduces the usable lifetime of a stolen credential
- Limits the attacker’s ability to come back later and reuse it
- Forces re-validation of access every time the endpoint becomes active
That said, this approach is not without trade-offs.
- It increases write activity to Active Directory
- It depends heavily on healthy SYSVOL and replication
- It can introduce confusion if support teams are not aware of the behavior
- Passwords can change more frequently than expected during troubleshooting
So this is not something I would blindly recommend for every environment.
But in environments where you understand the operational impact and can control access properly, it becomes a very effective way to tighten the window between compromise and reuse.
Retrieval Path
When an authorized administrator runs:
Get-LapsADPassword -Identity "PC-023"
they are reading the password from Active Directory.
They are not connecting live to the workstation.
They are not asking the machine to reveal anything in real time.
They are querying the directory and relying on the ACLs already in place.
That is why the directory permissions matter so much.
In practical terms, AD security becomes LAPS security.
Operational Realities
The docs tell you how to enable LAPS.
Production teaches you where it gets awkward.
Replication Matters
If you have more than one domain controller, replication timing matters.
A client may write the latest password to one DC, while an admin happens to query another before replication has caught up. The result looks like the password is missing or outdated when in reality the directory is simply not converged yet.
In those moments, targeting a specific DC can save time:
Get-LapsADPassword -Identity "PC-023" -Server DC1
This is not a LAPS problem so much as a normal AD reality, but you will absolutely run into it during testing if you forget it exists.
Imaging and Cloning
If workstation builds are sloppy, LAPS will expose it.
Cloning systems without proper sysprep, duplicating identities, or carrying forward bad imaging practices can create unpredictable behavior when multiple machines are expected to manage their own password state cleanly.
LAPS assumes the machine identity is real, unique, and correctly joined.
If your build process is weak, fix that first or you will spend time blaming the wrong thing.
Backup Strategy
One more thing people conveniently forget.
If your LAPS-managed passwords are stored in Active Directory, then they are also present in AD backups.
That means backup security now matters even more.
- Protect backup access
- Limit who can restore or browse them
- Encrypt where appropriate
- Treat directory backups as sensitive credential-bearing assets
Otherwise, all you did was move the secret from every workstation into a different place and fail to secure that place properly.
So Where Does That Leave Us
At the end of all this, the conversation is not really about LAPS as a feature or a checkbox in Group Policy. It is about something much simpler, and honestly, something much more uncomfortable to admit.
Do you want one compromised machine to stay one compromised machine, or are you okay with it quietly turning into ten, then fifty, and eventually your entire environment?
Because that outcome is not decided by how good your firewall is, or how clean your OU structure looks, or even how expensive your EDR solution is. It often comes down to something much smaller and much easier to overlook. A single local administrator credential, repeated across every endpoint, trusted for years because it made operations easier.
And attackers are not guessing this exists. They expect it. In many environments, they rely on it. It is one of the most predictable patterns they encounter, especially in environments that are otherwise well built and maintained.
What Microsoft LAPS does is not flashy. It does not stop the initial compromise. It does not prevent credential dumping. It does not magically make your environment secure overnight. What it does is far more practical than that.
It removes the easiest path forward for an attacker who is already inside.
Once that path is gone, everything else changes. Lateral movement slows down. Privilege escalation becomes harder. The attacker has to work more, take more risks, and spend more time trying to figure out where to go next. And in real incidents, time is one of the few advantages defenders still have.
So if you are still running the same local administrator password across your environment, it is worth being honest about what that really means. It is not just an operational shortcut. It is a design decision that directly affects how far an attacker can go once they get in.
And if you have already implemented LAPS properly, tightened your permissions, understood how the client behaves, and maybe even taken it a step further with more aggressive rotation strategies, then you are already in a much better position than most. Not perfect, but definitely not easy to move through.
And in this space, not being easy is a very good place to be.
So go take a look at your environment. Not the dashboards, not the reports, just the simple question.
Are your local admin credentials still the same everywhere?
Be honest.
Because attackers usually already know the answer. That said until next time, ciao!
