How can security teams detect system language discovery?

What system language discovery looks like in telemetry

system language discovery is usually a short, early-stage check rather than a noisy scan. Look for a process that starts by reading locale, keyboard layout, regional format, or language preference settings, then uses that result to decide whether to continue, alter behaviour, or exit. The signal is strongest when the process had no obvious reason to localise content or adapt to the user interface.

In practice, detection works best when you treat these queries as part of a sequence, not as a single event. A lone language check may be normal for installers, accessibility software, or internationalised applications. A check that appears soon after execution, before the process performs its main function, is more interesting when it is followed by sandbox probing, geofencing logic, or region-dependent branching.

For defenders, the key question is whether the host-language lookup is supporting a legitimate user experience or serving as an environment test. The second pattern often shows up alongside other discovery behaviours, such as checking time zone, system name, domain membership, input language, or UI culture. Correlating those signals gives you a better view of intent than any one API call by itself.

How to distinguish benign localisation from suspicious discovery

Benign software often queries language settings because it needs to render messages, choose keyboard shortcuts, or format dates correctly. Suspicious discovery tends to be operational rather than user-facing: it happens immediately after launch, is not followed by any visible localisation work, and is clustered with checks that help the process decide whether the environment is worth targeting.

One useful test is expected behaviour. If the application is not supposed to localise content, yet it queries locale and regional settings at startup, that mismatch deserves review. Another is conditional behaviour. If the process changes code paths, delays execution, suppresses payloads, or terminates after reading the host language, the lookup is no longer just configuration awareness, it is part of a decision rule.

Detection improves when you also watch for parent-child process context and execution timing. A language query from a signed productivity app may be routine, while the same query from a newly dropped script, macro, or loader can be an indicator of staging. The surrounding process tree, command-line context, and follow-on network or file activity usually determine whether the event is harmless or adversarial.

Building detections that catch language checks early

Good detections focus on the mechanism, not the exact API name. Alert on processes that access locale, keyboard, region, or language configuration data soon after start, especially when those processes are uncommon on the endpoint or originate from paths associated with temporary execution. Pair that with detection logic for sandbox awareness and geography-based branching so you can see the full intent chain rather than isolated lookups.

The most useful hunting logic groups language discovery with adjacent pre-execution checks. For example, a process that reads the host language and then immediately checks screen resolution, computer name, domain membership, or virtualisation artefacts is showing a broader assessment pattern. Those combinations are stronger than a single lookup and are more likely to justify triage.

For defenders who already use behavioural analytics, this is a good case for sequence-based correlation. The event on its own is low fidelity; the sequence of discovery, environment testing, and altered execution is what raises confidence. That is why threat-informed detection content such as the MITRE ATT&CK Guide for Defenders and the MITRE ATT&CK Enterprise Matrix are useful references for mapping discovery behaviour to a repeatable hunt or alert strategy. For operational enrichment, the SANS Security Resources can help teams compare detection ideas and response patterns.

Practitioner Guidance

What to prioritise: Triage language discovery only when it appears early in execution and is paired with other environment checks or conditional branching. That combination is much more meaningful than a lone locale query.

What to verify: Confirm whether the process actually needs localisation. If it is not a known internationalised application, validate the parent process, launch path, and any immediate follow-on actions before dismissing the event.

Decision rule: If the host-language lookup is followed by sandbox checks, geofencing behaviour, or a change in payload delivery, treat the language query as part of the detection chain, not as a benign configuration read.

Practitioner takeaway: The best detections do not alert on “language” alone, they alert on language discovery as an early decision point in a broader suspicious execution sequence.

Related resources from NHI Mgmt Group

• How can security teams detect System Network Configuration Discovery?
• How can security teams detect System Network Connections Discovery?
• How can security teams detect System Owner/User Discovery?
• How can security teams detect system service discovery by attackers?