AI-assisted LOLBin discovery changes the binary analysis workflow

At a glance

What this is: Pentera examines how AI-assisted binary analysis can uncover undocumented Linux LOLBins by tracing command-execution paths and input flow.

Why it matters: For IAM and security teams, the important shift is that trusted system utilities can become stealth execution paths, so detection and hardening need to account for legitimate tools being abused at runtime.

Context

Living Off the Land Binaries are legitimate system executables that can be abused to run commands, move laterally, and persist while blending into normal administration. That makes them hard to distinguish from expected operations, especially in Linux, Windows, and macOS environments where built-in utilities are everywhere. The article’s core problem is not a new exploit class, but the governance gap between trusted software and trusted behaviour.

The article’s identity relevance is indirect but real: LOLBin abuse often turns legitimate local tools into execution paths that bypass ordinary trust assumptions, much like over-trusted service accounts or unmanaged non-human identities do in identity programmes. Once defenders treat native binaries as potential abuse surfaces, the question becomes one of execution governance, not just malware detection.

Key questions

Q: What breaks when native binaries can execute attacker-controlled commands?

A: The control failure is assuming a trusted executable is safe because it is expected to exist. Once a native binary can accept attacker-influenced arguments, it becomes a command execution path that can blend into administration, bypass simplistic allowlists, and support stealthy persistence. The defensive focus has to move from file reputation to runtime behaviour and input provenance.

Q: Why do Living Off the Land Binaries make detection so difficult?

A: They evade detection because they are legitimate, signed, and already present on the host, so their use does not look anomalous by default. Traditional controls often watch for unknown binaries or dropped payloads, but LOLBins let attackers reuse trusted system utilities to run commands, move laterally, and hide inside normal operational noise.

Q: How can security teams validate whether a binary is a real abuse path?

A: They should trace the execution path backward from the command-spawning function to determine whether the arguments come from user input, a dispatcher, or a hardcoded safe path. If the command string or argv values are controllable by the caller, the binary deserves defensive treatment as a potential abuse primitive rather than a harmless utility.

Q: Should organisations rely on AI to replace manual reverse engineering?

A: No. AI is useful for prioritising candidate functions, surfacing likely command-execution paths, and scaling analysis across large binary sets, but it cannot replace validation. A trusted workflow still needs manual confirmation of control flow, argument provenance, and privilege context before a finding is used to drive detections or hardening.

Technical breakdown

How AI-assisted binary analysis finds LOLBin behaviour

The workflow starts with reverse engineering, then uses AI as a triage and reasoning aid rather than a replacement for analysis. Radare2 is used to identify execution primitives such as execvp, then cross-references and data flow are traced backward to see where command arguments originate. AI helps sort candidate functions and infer which code paths deserve attention first. That matters because LOLBin behaviour is often hidden inside ordinary helper functions, not obvious wrappers. The technical value is in combining static analysis, call-graph tracing, and argument provenance to separate benign execution from user-influenced command invocation.

Practical implication: analysts should use AI to prioritise candidate execution paths, but keep deterministic reverse-engineering steps as the verification layer.

Why trusted system utilities evade conventional detection

LOLBins are effective because they are already signed, installed, and expected to exist on the host. Traditional detections often key off unknown binaries, unusual parent-child process chains, or suspicious file drops, but a native utility can run attacker-controlled commands without introducing any foreign executable. That makes behaviour, not presence, the real signal. In practice, a binary’s legitimacy can obscure command execution, lateral movement, or persistence when those actions ride on ordinary administrative tooling. The control challenge is therefore to understand which built-in tools can spawn external commands and what inputs control them.

Practical implication: detection engineering should enumerate command-capable native tools and watch for abnormal argument provenance, not just unknown filenames.

AI changes the reverse-engineering workflow, not the trust model

The article’s deeper point is that AI makes binary analysis more scalable by automating repetitive reasoning, such as locating execution calls, ranking functions, and tracing arguments back to command-line input. That does not change the underlying trust model of the operating system. A binary still executes because it has legitimate local authority, and that authority can still be abused even when the analysis process is faster. The architectural lesson is that AI can expand coverage, but it does not remove the need for rigorous validation, input tracing, and command-path review.

Practical implication: use AI to scale discovery across large binary sets, then validate any suspected abuse path with manual reverse engineering.

Threat narrative

Attacker objective: The attacker’s objective is to execute commands and maintain footholds through trusted system tools while avoiding the noise associated with custom malware.

1. Entry occurs through a legitimate native binary that already exists on the system and accepts attacker-influenced input.
2. Credential or privilege boundaries are bypassed when the binary is used to execute commands under trusted local context rather than as a dropped payload.
3. Persistence and stealth follow when the same trusted tool is reused for repeated command execution, making malicious activity resemble normal administration.

Breaches seen in the wild

• Salt Typhoon telecom intrusions 2025: Salt Typhoon breached US telecoms mainly with stolen logins, then harvested SNMP strings and TACACS/RADIUS keys to spread and persist for years.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trusted-tool abuse is an identity governance problem as much as a malware problem. When a native binary can execute attacker-controlled commands, the environment is not failing because of a missing signature check alone. It is failing because trust is being granted to tool presence instead of tool behaviour. For identity teams, that is the same structural issue seen when long-lived service access is assumed safe simply because it is familiar.

AI-assisted discovery changes the defender workflow from reactive cataloguing to proactive abuse-path discovery. The real value is not that AI finds threats by itself, but that it helps scale the identification of command-capable binaries before they appear in threat intel. That expands the defender’s search space across Linux and other operating systems where native utilities are abundant. Practitioners should treat binary analysis coverage as a governance metric, not a one-off research exercise.

Cloak-of-legitimacy attacks exploit the gap between allowed software and allowed behaviour. The article’s example shows why static allowlists are weak when the same executable can serve both legitimate administration and malicious command execution. That pattern also mirrors NHI risk, where a trusted identity can be overused beyond its intended scope. The practical conclusion is that controls must be tied to observable execution paths and input provenance, not just approved tooling.

Binary abuse discovery should be folded into broader detection engineering and platform governance. If defenders already manage workload identities, service accounts, and privileged automation, native binaries belong in the same control conversation. The issue is not whether a tool is approved, but whether its runtime behaviour is constrained enough to prevent misuse. Security teams should therefore align reverse-engineering findings with detection logic, hardening baselines, and privileged execution review.

AI will keep widening the gap between what defenders can inspect and what attackers can hide inside normality. That does not mean AI becomes the control plane. It means the control plane must become more precise about trust boundaries, command provenance, and execution intent. The practitioner takeaway is clear: scale the search, but keep the decision on whether behaviour is safe grounded in human-reviewed evidence.

What this signals

Binary abuse is the new trusted-tool problem. When native utilities can execute attacker-controlled commands, defenders are no longer dealing only with malware prevention. They are dealing with runtime behaviour that looks legitimate until command provenance is inspected, which means control design has to start with execution paths and privilege context rather than file identity.

AI changes coverage, not confidence. The immediate value is scale: more binaries can be triaged, more execution chains can be inspected, and more suspicious paths can be surfaced before they are widely documented. But the assurance question remains the same, because only human-reviewed reverse engineering can tell you whether the path is truly attacker-influenced.

Living Off the Land discovery should be treated as part of detection engineering. If an environment depends on built-in tools for administration, the security programme needs explicit visibility into which utilities can spawn commands and how those utilities are monitored. That is a governance problem, not just a research exercise.

For practitioners

• Map command-capable native utilities Inventory built-in binaries that can spawn external commands, then classify them by the inputs that influence execution paths and privilege context.
• Trace argument provenance in binary reviews For any suspicious executable, trace command arguments back to their origin so you can distinguish hardcoded behaviour from user-controlled input.
• Add LOLBin abuse paths to detections Create detections around unusual parent-child process combinations, suspicious command-line parameters, and repeated use of native utilities for command execution.
• Use AI as a triage layer, not a verdict Let AI rank candidate execution paths and highlight likely abuse points, then validate each finding with reverse engineering before operationalising it.
• Review privileged automation that invokes local tools Treat automation that shells out to native binaries as a separate control surface and review whether the invoked tools can accept attacker-influenced arguments.

Key takeaways

• Living Off the Land Binaries create a trust problem because legitimate tools can be repurposed for command execution, stealth, and persistence.
• AI-assisted reverse engineering can scale discovery of undocumented abuse paths, but it still depends on deterministic validation of control flow and argument provenance.
• Security teams should treat command-capable native utilities as a governed attack surface and align detections to runtime behaviour rather than file reputation.

Key terms

• Living Off The Land Binary: A Living Off The Land Binary is a legitimate operating system or application executable that attackers abuse to carry out malicious actions. These binaries already exist on the target system, so security tools may trust them by default. They can be used for execution, persistence, defense evasion, credential access, or lateral movement.
• Control Provenance: The traceable origin of the evidence used to prove a control is operating. In practice, provenance matters when auditors need to know whether reports were generated independently, whether data was altered, and whether the proof can be reproduced later.
• Runtime behaviour: Runtime behaviour is what an agent actually does after access has been granted, including tool use, data access, sequencing, and response to untrusted inputs. In agentic systems it is often the real security signal, because harm can occur without any authorization failure.
• Reverse Engineering: Reverse engineering is the analysis of compiled software to understand how it works without access to source code. In mobile security, it usually means examining a published binary to recover logic, data flows, and implementation details. Attackers use it to extract secrets, identify weaknesses, and modify application behavior.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect identity control to the broader security programme they run every day.