How can security teams detect LoJax?

What detection looks for in a LoJax investigation

LoJax is hard to catch with ordinary endpoint telemetry because it can persist below the operating system. Detection starts with the assumption that a clean reinstall or malware removal may not be enough if firmware or boot components were altered. Teams should focus on evidence of boot-level tampering, unexpected changes in firmware state, and devices that keep re-infecting after cleanup.

A useful first pass is to compare current firmware and boot measurements against trusted baselines. That can include BIOS or UEFI configuration drift, altered Secure Boot state, unexpected boot order changes, and anomalies in measured boot or TPM-backed integrity signals. The key question is whether the device still presents the same trusted boot chain you expect, not whether the operating system looks healthy.

Boot persistence also changes how analysts interpret repeated reinfection. If the same endpoint restores the malware after imaging, credential resets, or AV removal, treat that as a signal to widen the scope beyond the host OS and examine whether the firmware itself, or another pre-OS component, is acting as the recovery point. Firmware and Boot Security Guide is useful here because it covers the boot integrity and firmware verification concepts that matter most in this class of case.

How to confirm exposure without trusting the installed operating system

Exposure checks should be designed so they do not rely on the possibly compromised machine as the only source of truth. Use trusted media or a known-good management path to inspect firmware settings, boot records, and integrity data from outside the running OS wherever possible. Compare those findings with your approved hardware baseline, golden image expectations, and any documented firmware version history for the fleet.

Pay close attention to endpoints with unusual remediation history. A host that repeatedly fails to stay clean after reimaging, especially if the symptoms survive full disk replacement or reinstallation, deserves firmware-focused triage. The same is true for systems with unexplained boot anomalies, altered firmware variables, or security features that appear disabled without a change request. Those are often the earliest practical clues that the compromise is anchored below the OS.

If you have fleet-scale telemetry, look for consistency. One-off firmware drift can be an administrative error, but repeated anomalies across a model, site, or build line may indicate a broader exposure pattern, such as a vulnerable firmware configuration or an operational gap in firmware governance. Detection is strongest when baseline comparison, boot integrity evidence, and remediation history are reviewed together rather than as separate signals.

What to do when firmware tampering is suspected

Once suspicion is credible, the response objective is containment and trustworthy validation, not in-place cleanup. Isolate the host from the network, preserve evidence, and validate the firmware from trusted media or an out-of-band administrative channel. If the device must remain in service, treat it as untrusted until the firmware state has been verified and any required updates or recovery actions have been completed.

In practical terms, the response sequence should separate containment from restoration. First stop the device from participating in normal operations. Then verify the firmware image, boot configuration, and secure boot chain against the baseline you trust. Only after that should you decide whether a firmware reflash, replacement, or deeper hardware investigation is required. The important judgment is that operating-system-level remediation alone may not remove the persistence mechanism.

Because boot-level tampering can expose long-lived access paths, also review whether the endpoint held credentials, tokens, management secrets, or remote administration access during the suspected compromise window. If it did, rotate or revoke anything that could have been used from that system, especially if the same host had privileged access to internal services or management planes.

Practitioner Guidance

What to verify: Build your triage around trusted comparisons, not local trust in the host. Confirm firmware state, boot measurements, and secure boot configuration from a source you can trust independently of the suspect endpoint.

Decision rule: If the machine keeps showing reinfection after cleanup, escalate immediately to firmware validation and host isolation. Do not spend excess time on repeated OS-only remediation when the persistence pattern already points below the operating system.

Common mistake: Treating a successful reinstall as proof of removal. For this class of threat, the reinstall may only reset the visible layer while leaving the persistence point intact.

Practitioner takeaway: The highest-value signal is not a single alert, but a mismatch between expected and observed boot trust. Once that mismatch appears, the response should shift from malware cleanup to firmware assurance and evidence preservation.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?