When Attackers Use Approved Software, a Green Signer Is Not a Clean Bill of Health

Security teams often ask whether a program is signed, approved or familiar. Those checks answer who produced a file and whether it belongs on a system; they do not answer whether a legitimate tool is being used by the right person for the right task. Elastic’s latest threat report puts that gap at the center: attackers are borrowing trust already granted to remote-management products, AI applications and identity flows.

A legitimate program can still be part of an intrusion

Elastic Security Threat Command says its November report draws on confirmed customer intrusions and first-party research between April and September 2026. Its researchers describe attackers using signed remote monitoring and management tools, AI coding assistants and first-party clients to maintain interactive access or run commands. Elastic also reports cases where attackers used adversary-in-the-middle phishing and legacy authentication paths to bypass MFA and access cloud services. These are observations from Elastic’s investigated cases, not a count of all intrusions. ^{[1] [2]}

This is a familiar “living off the land” problem with a newer toolset. Attackers can use software that administrators already deploy or a user is already allowed to run. A file signature or allowlist can confirm that a tool is expected, while the tool’s use—who launched it, what it accessed, which process it spawned and where it connected—may still be abnormal. CISA’s joint guidance emphasizes behavioral analytics and baselining for this reason: defenders need context about activity, not just a list of known-bad files. ^[3]

Elastic’s report includes several striking timing and activity examples, including a reconstructed AI-agent-assisted intrusion and rapid use of stolen credentials. Such cases can help teams think through speed and visibility, but they should not be generalized into a forecast that every organization faces the same tools or timelines. Elastic explicitly says the report focuses on notable tradecraft rather than raw telemetry counts; it does not supply a representative denominator for the whole industry. ^{[1] [2]}

Build detections around the action chain

A practical way to respond is to connect events that are usually reviewed in separate systems. Start with the identity: was the sign-in expected for this person, service account or application? Then examine the session: did MFA complete normally, was a legacy path involved, and did the session reach a new tenant or resource? On the endpoint, connect the approved tool to its parent process, child processes, command line, file access and network destinations. The sequence can matter more than any single event.

MITRE ATT&CK’s Valid Accounts technique describes how adversaries may use compromised credentials without malware or custom tools, making their activity harder to distinguish from legitimate access. CISA’s living-off-the-land guidance likewise recommends behavior analysis, correlation and proactive hunting. These references do not provide a universal detection rule; they support a monitoring model that asks whether observed behavior fits the user, device, time and purpose. ^{[3] [4]}

For example, a remote support agent launched by an administrator during a scheduled service window may be routine. The same signed binary started from a document viewer, followed by access to a new identity provider tenant or an unusual network destination, deserves investigation. Likewise, an AI coding tool can be normal on a developer’s workstation but unusual on a finance server. These are illustrative patterns, not evidence that any particular product is malicious.

The data needed to investigate may not be enabled by default. Review endpoint process telemetry, identity-provider audit records, SaaS application consent events and network logs. Align timestamps and stable identifiers so an analyst can follow a session across host and cloud. Protect the logging pipeline itself, set retention to match incident response needs, and alert on missing sources as well as suspicious activity. If teams cannot see parent-child process relationships or application consent changes, a signer-only allowlist will leave the central question unanswered.

Keep trust controls, add behavior checks

The answer is not to block every signed management utility or AI assistant. Those tools can be essential to operations, and broad denial can disrupt support. Instead, inventory the approved software and identities, restrict who may install or authorize them, and compare actual behavior with the intended use. For high-impact tools, require just-in-time elevation, scoped permissions and a documented owner. Review application grants and session lifetime in addition to enforcing MFA; an authenticated session can still be abused after a user is tricked into approving it.

Detection teams can start with a small set of sensitive behaviors: new administrative consent, unexpected process chains from trusted remote tools, unusual use of AI applications on production systems, and network access that does not match an approved maintenance workflow. Tune each rule against legitimate IT and development activity. Measure whether the alert contains enough context for a responder to decide what happened without asking the same systems to be queried again.

Elastic’s report is vendor-produced research, and its recommendations intersect with the vendor’s security products. The underlying operational point is broader than any one platform: trusted software expands what an attacker can do with access, so trust should be conditional on behavior. A green signature tells a defender which tool is running. The harder and more useful question is what that tool is doing now.

Related coverage: why identity and session behavior matter after MFA and how DLP detection differs from prevention.