D3-LAM Local Account Monitoring: Detecting Rogue Local Accounts and Proving Coverage

Local accounts live outside the directory, so an account created, enabled or used on a single host can go unseen by every control that watches Active Directory or Entra ID. MITRE D3FEND names the countermeasure Local Account Monitoring (D3-LAM) and defines it as "Analyzing local user accounts to detect unauthorized activity." It sits under the Detect tactic as a child of User Behavior Analysis (D3-UBA), and its digital artefact is the Local User Account, which D3FEND defines as an account that exists on one specific host. This card covers what D3-LAM watches, which ATT&CK techniques D3FEND relates it to, the Windows, Linux and macOS data sources that implement it, and how to prove the detections fire. It is written for detection engineers and endpoint teams; the domain counterpart is D3-DAM Domain Account Monitoring.

Key takeaways

• Three behaviours matter most. D3FEND relates D3-LAM to local account creation (T1136.001), local account enumeration (T1087.001) and the use of local accounts as valid accounts (T1078.003), all inferred through the Local User Account artefact.
• Events are written on the host, not the DC. Local account changes and local logons are recorded in the Security log of the server or workstation that owns the account, so coverage depends on endpoint log collection, not directory logs.
• Audit policy is the first dependency. Without the Audit User Account Management and Audit Security Group Management subcategories enabled, Windows writes no 4720, 4722, 4738 or 4732 events at all.
• Baseline the expected accounts. Most estates should have one managed local administrator per Windows host and a short, known list of local service accounts; anything else is the detection.
• Test with a real account change. MITRE CAR's own unit test for its local logon analytic creates a local user and logs on with it; a scheduled version of that test proves the pipeline end to end.

D3-LAM at a glance

What it detects

D3FEND gives D3-LAM a one-line definition and no knowledge base article, so the practical scope comes from its references and its artefact relations. Three questions cover it.

• Lifecycle changes: was a local account created, enabled, renamed, given a new password, added to a privileged local group or deleted, and was that change expected? Unauthorised creation is the persistence path ATT&CK describes in T1136.001.
• Use: did a local account log on, from where and how? The MITRE CAR analytic D3FEND cites, CAR-2016-04-004, looks for successful logons (event 4624) that use NTLM and are not the ANONYMOUS LOGON account, describing the target pattern as a network logon (type 3) with NTLM to a non-domain account. CAR maps it to Pass the Hash (T1550.002), with moderate coverage.
• Enumeration: did a process list the host's local users or groups? Windows records local group membership enumeration as event 4798, which supports detection of T1087.001.

Where identity fits

Many local accounts are non-human: built-in Administrator accounts, local service accounts that run scheduled tasks or vendor agents, and break-glass accounts on appliances. They are rarely owned, often share passwords across hosts and are exactly the accounts an attacker reuses for lateral movement. D3-LAM is the detection side of managing them; the preventive side, unique rotated local administrator passwords, is in the Local Administrator Password Solution (LAPS) Guide.

ATT&CK techniques D3FEND relates to D3-LAM

Relationship type: inferred only. D3FEND marks every row below as an inferred and experimental relationship derived through the shared Local User Account artefact: D3-LAM analyzes a Local User Account, and each ATT&CK technique uses, enumerates or creates one (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.

Outside D3FEND's artefact inference, MITRE CAR lists D3-LAM against its analytic for Pass the Hash (T1550.002). Defensive detail for each technique is in the MITRE ATT&CK T1078 Valid Accounts Guide, the MITRE ATT&CK T1136 Create Account Guide and the T1087 and T1069 Account and Permission Group Discovery Defensive Guide.

Where it is implemented

Windows event reference

Microsoft's Audit User Account Management subcategory generates the account lifecycle events, and recommends Success and Failure auditing on domain controllers, member servers and workstations; for member servers and workstations its stated focus is all changes to local user accounts, especially the built-in Administrator. Local group changes come from a separate subcategory, Audit Security Group Management.

Two field details make the rules work. In 4624, a local account shows the computer's own name in Account Domain, which is how a rule separates local from domain logons; logon type 3 is a network logon, 10 is Remote Desktop. In 4732 for a local group, the member Account Name is usually shown as "-", so key rules on the member Security ID instead. Forwarding is covered in the Windows Event Forwarding Guide and event interpretation in the Windows Event Log Guide.

Implementation classes

The inventory approach is covered in the osquery Guide; Sysmon adds process context on Windows (Sysmon Guide).

Implementation steps

1. Write the baseline. For each host class, list the local accounts that should exist: the managed administrator, named local service accounts, vendor accounts on appliances. Record the owner and the process that is allowed to change each one.
2. Enable audit policy. On Windows, enable Success and Failure for User Account Management and Success for Security Group Management and Logon through Group Policy or Intune, then confirm with auditpol /get /category:* on a sample of hosts. On Linux, add path watch rules with a key for the account files.
3. Collect from every host class. Forward the events to the SIEM. Check that workstations, not only servers, are included, since local account abuse often starts on a workstation.
4. Write rules in audit mode. Start with: any 4720 outside the build window; any 4732 into Administrators or Remote Desktop Users not made by the approved tooling; 4624 type 3 or 10 where Account Domain equals the computer name and the account is the built-in Administrator; 4722 on an account the baseline says is disabled; diffs from the daily inventory snapshot.
5. Tune for two to four weeks. Expect noise from imaging, software installers that create service accounts and helpdesk tools. Fix each source by documenting it in the baseline, not by widening the rule.
6. Promote and assign response. Move tuned rules to alerting with a runbook: confirm the change ticket, check the creating process, disable the account if unexplained and scope for the same account name on other hosts.
7. Roll back safely. If a rule floods the queue, return it to audit mode rather than deleting it, and keep the inventory diff running so coverage is not lost while it is fixed.

How to verify it works

• Synthetic account test: on an approved test host per host class, create a local user, add it to the local Administrators group, log on with it and delete it. This mirrors the unit test MITRE CAR publishes for CAR-2016-04-004. Confirm 4720, 4732, 4624 and 4726 all reach the SIEM and each rule fires.
• Audit policy drift check: sample hosts monthly for the audit subcategory settings; a Group Policy change that disables them silently removes the control.
• Collection gap report: compare the list of hosts sending Security events with the asset inventory each week.
• Emulation: include local account creation and discovery in authorised adversary emulation and record whether each step alerted.

Limits, bypasses and failure patterns

• Endpoint logs not collected: teams that collect only domain controller logs have no D3-LAM at all, because local events never reach a DC.
• Log tampering by a local administrator: an attacker with SYSTEM or root can stop logging or clear logs before acting. Alert on the loss of a host's event stream and on log clearing; see the MITRE ATT&CK T1685.001 Disable or Modify Tools guide.
• Using an existing account instead of creating one: an attacker who reuses a shared local administrator password creates no 4720. Logon rules and unique passwords per host matter more than creation rules here.
• Baseline never written: without an expected list, every installer that creates a service account looks malicious and the rule is switched off.
• Linux and macOS left out: Windows coverage is common; equivalent watches on Linux account files and macOS account changes are often missing.
• Keying on account names: renamed accounts (4781) and the "-" member name in local 4732 events defeat name-based rules; use SIDs and UIDs.

Framework mapping

Practitioner checklist

• Write an expected local account baseline per host class, with owners.
• Enable User Account Management (Success and Failure) and Security Group Management auditing on every Windows host.
• Collect Security logs from workstations as well as servers.
• Add Linux audit watches with keys for the account and sudoers files.
• Alert on 4720, 4732 to privileged local groups and 4722 on baseline-disabled accounts outside approved processes.
• Alert on network and Remote Desktop logons by built-in local administrator accounts.
• Run a daily inventory diff of local accounts as a backstop to event rules.
• Key rules on SIDs and UIDs, not names.
• Run the create, add, log on, delete synthetic test monthly per host class.

Standards and references

• MITRE D3FEND: Local Account Monitoring (D3-LAM)
• MITRE CAR: CAR-2016-04-004 Successful Local Account Login
• Microsoft Learn: Audit User Account Management
• Microsoft Learn: Event 4732, a member was added to a security-enabled local group
• Microsoft Learn: Event 4624, an account was successfully logged on
• osquery: users table specification
• Linux man-pages: audit.rules
• Microsoft Learn: Windows LAPS overview

Related NHI Mgmt Group resources: MITRE D3FEND Guide · UEBA Guide · Local Administrator Password Solution (LAPS) Guide · MITRE ATT&CK T1136 Create Account Guide