AN1561: Analytic 1561
Registry access to system language keys (e.g., HKLM\SYSTEM\CurrentControlSet\Control\Nls\Language) or suspicious processes invoking locale-related APIs (e.g., GetUserDefaultUILanguage, GetSystemDefaultUILanguage, GetKeyboardLayoutList). Defender visibility focuses on anomalous or non-standard processes issuing these queries, especially when run by unknown binaries or scripts.
Analyst context for executives and security teams
Analytic 1561 is a Windows-focused detection analytic for spotting unusual checks of system language and locale settings, such as registry reads of language keys or calls to locale-related APIs. This matters because language discovery can help suspicious software decide how to behave in a specific environment. For leaders, the value is not the language query itself, but whether the SOC can distinguish normal application localization behavior from unknown binaries or scripts performing environment checks.
Executive priority
Treat this as a validation point for endpoint visibility and investigation readiness, not as a standalone high-confidence incident signal. Security leaders should ask whether managed detection, EDR, and logging programs can show which Windows processes access locale registry paths or invoke language APIs, and whether analysts have enough process context to separate routine software behavior from non-standard or unknown executables. This supports incident triage quality, compliance evidence around monitoring coverage, and control prioritization for Windows endpoint telemetry.
Technical view
The supplied analytic targets Windows registry access to system language keys, including HKLM\SYSTEM\CurrentControlSet\Control\Nls\Language, and suspicious processes invoking locale-related APIs such as GetUserDefaultUILanguage, GetSystemDefaultUILanguage, and GetKeyboardLayoutList. Since no tactic mapping or official detection logic is supplied, SOC teams should use this as a behavior to validate within endpoint telemetry: identify non-standard, unsigned, newly observed, script-launched, or unknown processes performing these queries, then enrich with parent process, command line, file path, user context, and surrounding activity.
Likely telemetry
- Windows endpoint process creation telemetry
- Process parent-child lineage and command-line context
- Registry access telemetry for system language and NLS language keys
- Endpoint API monitoring or EDR behavioral telemetry for locale-related API calls
- File reputation, signer, hash, and path metadata for querying processes
Detection direction
- Baseline common Windows and application localization behavior before alerting on language or locale queries alone.
- Prioritize anomalous or non-standard processes, unknown binaries, and scripts that query locale settings, consistent with the official analytic description.
- Correlate registry or API activity with process lineage, execution path, signer status, recent file creation, and adjacent suspicious behavior to reduce false positives.
- Confirm whether endpoint tooling records registry reads and API-level locale queries; many environments may only have partial visibility.
- Avoid treating language discovery as conclusive malicious activity without additional evidence, because legitimate software often checks locale settings.
Mitigation priorities
- Ensure Windows endpoint telemetry includes process creation, parent-child relationships, command lines, and relevant registry access where feasible.
- Harden execution controls for unknown binaries and scripts so suspicious locale queries can be evaluated in a broader control context.
- Maintain asset and software baselines to help distinguish approved localized applications from unusual process behavior.
- Document monitoring coverage and known blind spots for registry/API visibility as part of SOC readiness and audit evidence.
- Use incident response enrichment workflows to quickly assess unknown processes performing language or locale checks.
Analyst notes and limits
No ATT&CK relationships were supplied, and tactics are not specified for this analytic. The safest use is as a detection engineering and telemetry coverage check for Windows endpoints. The most important analytic question is whether the process performing the language query is expected in that environment.
Official detection logic is not provided, and the object contains no relationship context, no attribution, and no active exploitation claims. Local baselines are required because language and locale checks are common in legitimate software. Coverage depends heavily on endpoint tooling visibility into registry access and API behavior.
Analytic 1561
Registry access to system language keys (e.g., HKLM\SYSTEM\CurrentControlSet\Control\Nls\Language) or suspicious processes invoking locale-related APIs (e.g., GetUserDefaultUILanguage, GetSystemDefaultUILanguage, GetKeyboardLayoutList). Defender visibility focuses on anomalous or non-standard processes issuing these queries, especially when run by unknown binaries or scripts.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 69eeb8426b34… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1561Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.