{ "id": "79ceea7b-fbeb-404d-a2b4-9e8f23781fe3", "created_at": "2026-04-06T03:36:37.875229Z", "updated_at": "2026-04-10T03:21:28.689226Z", "deleted_at": null, "sha1_hash": "5f51cf236bdd2748b592274aca3c82696bce3994", "title": "Remote Use of Local Accounts: LAPS Changes Everything", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 62674, "plain_text": "Remote Use of Local Accounts: LAPS Changes Everything\r\nBy kexugit\r\nArchived: 2026-04-06 03:21:20 UTC\r\nLong overdue post revisiting the question about whether and when to block the use of local accounts, particularly\r\nfor remote administration.\r\nBeginning in 2014 with our baselines for Windows 8.1 and Windows Server 2012R2, our security baselines have\r\nbeen blocking remote use of local accounts. Back then, Windows had yet to offer anything resembling secure\r\nmanagement of administrative local account credentials. It was typical for an entire organization to have an\r\nadministrative local user account with the same username and password on every Windows computer. One\r\nproblem with that is that the common password often becomes a well-known secret over time with no way to\r\nrevoke access from anyone who ever received it. But by far the biggest problem is that an attacker with\r\nadministrative rights on one machine can easily obtain the account’s password hash from the local Security\r\nAccounts Manager (SAM) database and use it to gain administrative rights over the other machines using “pass\r\nthe hash” techniques.\r\nIn May 2015, Microsoft released the Local Administrator Password Solution (LAPS). LAPS is an elegant and\r\nlightweight mechanism for Active Directory domain-joined systems that periodically sets each computer’s admin\r\naccount password to a new random and unique value, storing the password in a secured confidential attribute on\r\nthe corresponding computer object in Active Directory where only specifically-authorized users can retrieve it.\r\nLAPS changes everything.\r\nNot only does LAPS neutralize both the pass-the-hash and well-known-secret problems, it creates new\r\nopportunities for remote management. With LAPS – or in fact, with any solution that makes local account\r\npasswords unique and not guessable – using local accounts for remote computer management actually offers some\r\nadvantages over using domain accounts. They can, that is, provided that their use isn’t blocked by security policy\r\n– which our baselines do today.\r\nIt’s all about credential hygiene. Good credential hygiene means not exposing credentials on a potentially-compromised system when those credentials can be used to compromise another system. Credentials can be a\r\nplaintext password, an account’s NTLM hash, or a Kerberos TGT. Microsoft’s Pass the Hash whitepapers go into\r\ndetail about which remote logon types and tools expose credentials and which ones don’t.\r\nLet’s say your helpdesk technicians each have a domain account that is granted administrative rights on all\r\nworkstations in the domain. User Umberto reports computer issues, so Helen helpdesk technician logs on remotely\r\nto the workstation using her privileged domain account, not realizing that the workstation has been compromised\r\nwith credential theft malware. Depending on how Helen logged on, her account credentials could be stolen and the\r\nthief can now gain administrative control over all workstations. All the technicians might follow the whitepapers’\r\nrecommendations, but they must do it the right way every single time. One technician with a privileged account\r\nmaking one mistake just one time can lead to a domain-wide compromise.\r\nhttps://blogs.technet.microsoft.com/secguide/2018/12/10/remote-use-of-local-accounts-laps-changes-everything/\r\nPage 1 of 3\n\nLet’s say instead of using a privileged domain account, Helen helpdesk technician retrieves the LAPS password\r\nfor the workstation and uses the LAPS-managed administrative local account to log on. Credential theft is not a\r\nproblem. If the thief gets the hash or even the plaintext password, it’s useful only on the computer that the thief\r\nalready controls. So Helen can use whichever logon type or remote tool is most convenient for the work being\r\nperformed.\r\nNote: One caveat about using remote desktop: do not enable drive redirection for your local volumes when\r\nconnecting to a potentially-compromised system. And avoid clipboard redirection as well. This caveat applies\r\nwhether you’re using a LAPS-managed account, /restrictedAdmin, or anything else.\r\nIf you have deployed LAPS or another local account password management solution and you want to use local\r\naccounts for the remote administration of Windows computers, you need to change three of the Computer\r\nConfiguration settings that we recommend in the baselines for Windows client and Windows Server in the\r\nMember Server role. We recommend these changes only if you plan to use LAPS-managed local accounts for\r\nremote administration. Note also that the local-policy scripts included with the Windows 1803 and 1809 baseline\r\npackages include “Non-Domain” options that implement these same changes.\r\nPolicy path Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment\r\nPolicy name Deny access to this computer from the network\r\nBaseline setting\r\nWin client: NT AUTHORITY\\Local Account\r\nWin Server: NT AUTHORITY\\Local account and member of Administrators group\r\nUpdated setting [empty]\r\nPolicy path Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment\r\nPolicy name Deny log on through Remote Desktop Services\r\nBaseline setting NT AUTHORITY\\Local Account\r\nUpdated setting [empty]\r\nhttps://blogs.technet.microsoft.com/secguide/2018/12/10/remote-use-of-local-accounts-laps-changes-everything/\r\nPage 2 of 3\n\nPolicy path Administrative Templates\\MS Security Guide (*)\r\nPolicy name Apply UAC restrictions to local accounts on network logon\r\nBaseline setting Enabled\r\nUpdated setting Disabled\r\n(*) “MS Security Guide” is a collection of custom settings that comes with the security baselines and is\r\nrepresented in SecGuide.admx. You can configure the updated setting directly by configuring the registry value\r\nLocalAccountTokenFilterPolicy to REG_DWORD value 1 in\r\nHKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System.\r\nAnonymous\r\nDecember 11, 2018\r\nHi Aaron,a benefit of a 'no remote logon' policy is it's definitive; no matter what local accounts get setup,\r\nwhether by the end-user or a helpful desktop admin, you're guaranteed they can't be used remotely. LAPS\r\nonly targets the (500) local admin and doesn't give any management of other local accounts.LAPS is a\r\ngood solution, but it needs a bit more to provide that same definitive protection, something like a new SID\r\n\"Local Accounts Not in LAPS\", or \"Local accounts in admin group but not the administrator\" which could\r\nbe used in the \"Deny*\" security policy GPOs.[Aaron Margosis] A clarification: LAPS manages one\r\nadministrative local account, which doesn't necessarily have to be the -500 built-in admin.More: there's no\r\ngood reason to have multiple administrative local accounts on an enterprise system. They would each have\r\nfull control over the other. You have no reliable auditability, so you might as well have just one such\r\naccount.More: users need admin rights to create local accounts, and if they're doing things like that on\r\nyour systems, you've got bigger security issues. They can open all kinds of unaudited mechanisms for\r\nremote control. Enterprise users shouldn't have admin rights.\r\nAnonymous\r\nJanuary 18, 2019\r\nUsing the Administrator account can be a good choice for desktops and laptops.However, the drawback of\r\neverybody using the same local account is that it's more difficult to know who did what...Furthermore, this\r\nis an all or nothing approach: you are either a user or an administrator.On servers, I would rather apply the\r\nprinciple of least privilege with JEA.Anyway, thanks for this interesting reminder about LAPS!\r\nSource: https://blogs.technet.microsoft.com/secguide/2018/12/10/remote-use-of-local-accounts-laps-changes-everything/\r\nhttps://blogs.technet.microsoft.com/secguide/2018/12/10/remote-use-of-local-accounts-laps-changes-everything/\r\nPage 3 of 3", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://blogs.technet.microsoft.com/secguide/2018/12/10/remote-use-of-local-accounts-laps-changes-everything/" ], "report_names": [ "remote-use-of-local-accounts-laps-changes-everything" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775446597, "ts_updated_at": 1775791288, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/5f51cf236bdd2748b592274aca3c82696bce3994.pdf", "text": "https://archive.orkl.eu/5f51cf236bdd2748b592274aca3c82696bce3994.txt", "img": "https://archive.orkl.eu/5f51cf236bdd2748b592274aca3c82696bce3994.jpg" } }