Client-Side Kill Chain

The Client-Side Kill Chain is a way to describe how browser-based attacks progress from reconnaissance through delivery and exploitation. It helps teams map defensive controls to each stage, so they can reduce exposure before malicious code executes and limit the impact after compromise begins.

Expanded Definition

The Client-Side Kill Chain describes the sequence of attacker activity that begins before code runs in the browser and continues through delivery, exploitation, command execution, and post-exploitation actions. In NHI and agentic AI environments, it is especially useful because many attacks now target the browser, developer tooling, extensions, and web-delivered workflows that handle credentials, tokens, and authenticated sessions. The model helps security teams think stage by stage instead of treating all browser compromise as a single event.

Usage in the industry is still evolving, and there is no single standard that governs this term yet. Some teams apply it narrowly to browser-based malware or script injection, while others use it more broadly to cover phishing, malicious extensions, drive-by downloads, session theft, and workflow hijacking. That broader interpretation is often the most operationally useful when NHI secrets or AI agent access are exposed through the browser. The MITRE ATT&CK Enterprise Matrix provides a useful reference for mapping those techniques to known attacker behaviors, even though the client-side kill chain itself is a descriptive model rather than a formal control framework.

The most common misapplication is treating browser compromise as only a delivery problem, which occurs when teams ignore pre-exploitation reconnaissance and post-exploitation session abuse.

Examples and Use Cases

Implementing client-side kill chain thinking rigorously often introduces monitoring and response overhead, requiring organisations to weigh earlier detection against added telemetry, review effort, and browser hardening costs.

• A malicious browser extension harvests API keys from developer tabs, then exfiltrates them after the user authenticates into a cloud console. The pattern resembles the supply-chain style exposure seen in the Hard-Coded Secrets in VSCode Extensions research, where client-side trust becomes the attack path.
• A phishing page imitates a login portal, captures session data, and then pivots into internal tools once the victim browser is authenticated. ATT&CK mappings from the MITRE ATT&CK Enterprise Matrix help teams break that sequence into observable techniques.
• A compromised web app injects script that reads tokens from local storage and sends them to an external endpoint before the user notices any change in behavior.
• A malicious plugin requests browser permissions that later let it access prompts, secrets, or agent instructions inside a developer workflow, similar to the campaign described in JetBrains Marketplace AI Plugin Campaign.
• A security team builds detections for script injection, token theft, and suspicious outbound calls, then validates those controls against browser and endpoint telemetry guided by NIST SP 800-53 Rev 5 Security and Privacy Controls.

In practice, this model is also useful when investigating why a benign user action turned into a compromise chain after the browser, extension, or embedded agent became the true execution environment.

Why It Matters in NHI Security

Client-side attacks matter in NHI security because the browser is often where secrets, temporary credentials, and authenticated sessions intersect with human users and autonomous tools. If defenders only protect backend systems, attackers can still abuse the front end to capture tokens, hijack sessions, or influence agentic workflows before stronger controls are reached. That makes browser compromise a direct threat to service accounts, delegated access, and other NHI assets that depend on short-lived trust.

The operational risk grows when secrets are copied into browser-visible workflows, developer portals, or AI-assisted interfaces. NHIMG research shows that organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, which increases the chance that a browser-based compromise reaches multiple credential stores before it is contained. Findings in The State of Secrets in AppSec reinforce that fragmented secret handling and delayed remediation can prolong exposure long after initial compromise. Browser-side abuse also aligns with how adversaries move once they obtain a foothold, as reflected in LLMjacking: How Attackers Hijack AI Using Compromised NHIs, where stolen credentials are used quickly after exposure.

Organisations typically encounter the practical impact only after a token leak, unauthorized plugin activity, or session hijack, at which point the client-side kill chain becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Client-Side Supply Chain
• What is the Identity Kill Chain?
• Who is accountable when an AI-orchestrated attack uses a model provider as part of the kill chain?
• Why do AI agents change the traditional kill chain?