Subscribe to the Non-Human & AI Identity Journal

Plain-text payload malware

Malicious code delivered as scripts or interpreted source rather than compiled binaries. It can evade conventional endpoint detection because it blends into normal development activity, yet still read files, tokens, and workspace data needed for credential theft.

Expanded Definition

Plain-text payload malware is malicious logic delivered as readable scripts, configuration fragments, or interpreted source code instead of compiled binaries. In NHI environments, that distinction matters because the payload can live inside repositories, build steps, dependency installers, notebook cells, or automation tasks that already look normal to developers. It often depends on native interpreters such as JavaScript, Python, PowerShell, Bash, or Ruby, which lets it execute without the friction that binary-based malware may encounter.

Definitions vary across vendors on whether the term should include any script-based implant or only payloads that are both human-readable and directly executed by an interpreter. NHI Management Group uses the broader operational view: if the attacker can read, modify, or stage the code as text and use it to reach files, tokens, certificates, or workspace data, the risk profile is the same. The control concern is not file format alone, but how easily the payload blends into software delivery and agentic automation paths. The most common misapplication is treating plain-text payload malware as “just a script,” which occurs when teams assume repository presence implies legitimacy.

For a standards lens on execution and containment, see CIS Controls v8, especially software inventory and secure configuration disciplines.

Examples and Use Cases

Implementing detection rigorously often introduces more inspection of source, which can slow builds and require tighter developer exception handling, so organisations must weigh visibility against workflow friction.

  • A malicious npm postinstall script is added to a dependency and executes during package installation, exfiltrating tokens from the developer workstation, as seen in the Shai Hulud npm malware campaign.
  • A PowerShell payload is copied into a CI job step and reads cloud credentials from environment variables before opening an outbound channel.
  • A Python notebook cell contains hidden file-access logic that harvests API keys from mounted volumes during model testing.
  • A shell script embedded in a deployment pipeline modifies a workspace and steals signing material used for release automation.
  • A text-based implant is checked into a public repo, where reviewers miss the malicious logic because it resembles routine DevOps automation.

These cases align with the broader abuse patterns documented in the CircleCI Breach and with guidance from the CIS Controls v8 on secure software handling.

Why It Matters in NHI Security

Plain-text payload malware is especially dangerous in NHI security because service accounts, tokens, and automation credentials are frequently exposed to code paths that humans can inspect and modify. Once the payload is text, it can be smuggled through reviews, dependency updates, build hooks, or agent prompts with far less friction than binary malware. That makes it a practical bridge between software compromise and NHI compromise.

NHIMG research shows how quickly exposure becomes exploitation: in the LLMjacking analysis, attackers attempted access to publicly exposed AWS credentials in an average of 17 minutes. In parallel, The State of Secrets in AppSec found that only 44% of developers follow secrets-management best practices, which helps explain why plain-text malware can reliably harvest usable credentials from ordinary workflows. The operational lesson is that text-based payloads are not low sophistication, they are high reach.

Organisations typically encounter the blast radius only after a repo, pipeline, or workstation has already been abused, at which point plain-text payload malware becomes operationally unavoidable to address.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-02 Covers improper secret handling and script abuse that exposes NHI credentials.
OWASP Agentic AI Top 10 Agentic workflows can execute text payloads that manipulate tools and data.
NIST CSF 2.0 PR.AC-4 Least-privilege access limits what script payloads can read or modify.
NIST Zero Trust (SP 800-207) SC-7 Zero trust segmentation helps contain malicious script execution paths.
NIST AI RMF AI risk management addresses prompt and code injection behaviors from text payloads.

Scan text-based code paths for embedded secrets and block execution that can exfiltrate NHI credentials.