Report Type: EXP

Threat Category: AI Coding Assistant Exploitation / Developer Workstation Execution Risk / Software-Delivery Trust Exposure

Assessment Date: May 18, 2026

Primary Impact Domain: Developer Workstation Integrity and Software-Delivery Trust

Secondary Impact Domains: Source-Code Integrity, Local Secrets Exposure, Repository Trust, CI/CD Credential Exposure, Cloud Session Exposure, Package-Registry Assurance, Release Workflow Integrity, Executive Governance

Affected Asset Class: Developer Workstations, AI Coding Assistant Installations, Local Configuration Files, Source-Code Repositories, Developer Credentials, CI/CD Systems, Cloud Sessions, Package Registries, Release Workflows

Threat Objective Classification: Unauthorized Local Execution, Configuration Manipulation, Credential Access, Repository Trust Abuse, Engineering-System Follow-On Access, Software-Supply-Chain Exposure

BLUF

‍ Claude Code deeplink settings-injection RCE creates enterprise exposure when a trusted AI coding assistant or developer workflow can be influenced to support unauthorized local execution, configuration manipulation, credential exposure, or downstream software-delivery risk. The business concern is broader than the vulnerable tool behavior itself: whether developer endpoints, local secrets, source-code access, repository workflows, CI/CD credentials, cloud sessions, and package-publishing paths can still be trusted after suspicious Claude Code activity. Risk is highest when suspicious deeplink or settings activity is paired with endpoint execution artifacts, unexpected configuration changes, credential access, abnormal outbound communication, repository manipulation, or follow-on use of developer privileges.

Executive Risk Translation

Claude Code deeplink settings-injection RCE shifts business risk from a narrow AI-tool vulnerability concern to a developer-workstation, source-code, secrets, and software-delivery trust issue. The primary executive concern is not only whether Claude Code is patched, but whether developer endpoints, local repositories, shell histories, API credentials, git credentials, package-manager tokens, cloud credentials, SSH keys, source-code access, build workflows, and CI/CD handoff paths can still be trusted after suspicious Claude Code activity. If abuse occurred, response may expand into developer endpoint forensics, AI-tool configuration review, token rotation, repository integrity validation, package and dependency review, privileged developer account review, cloud-access scoping, CI/CD secret assessment, code-signing assurance, legal review, and executive reporting.

S3 — Why This Matters Now

· AI coding assistants now operate inside trusted developer workflows where local configuration, repository metadata, terminal execution, MCP servers, hooks, and IDE or CLI integrations can influence what runs on a developer workstation.

· Deeplink handling can create a risky trust boundary because activity may begin through a browser, chat, documentation page, issue tracker, repository instruction, or other external path while the resulting effect occurs inside a local development environment.

· Public reporting indicates the specific deeplink settings-injection issue has been addressed in a fixed Claude Code version, making fleet-level version validation and update enforcement an immediate governance requirement.

· Related Claude Code security research shows that project configuration, hook behavior, MCP-related settings, and local startup behavior can become execution-relevant in certain conditions. These related findings should be treated as supporting context, not proof that every Claude Code deployment is compromised.

· Developer workstations are high-value assets because they often contain source-code access, local secrets, SSH keys, API tokens, package-publishing credentials, cloud access, privileged git access, internal documentation, build artifacts, and access to production-adjacent systems.

· A successful execution path on a developer workstation may create downstream software-supply-chain exposure if the affected user has access to source code, secrets, CI/CD systems, package registries, signing workflows, or cloud environments.

· The risk may not initially resemble conventional malware compromise because activity can appear as developer tooling, shell execution, AI assistant behavior, repository setup, configuration loading, dependency installation, or approved local automation.

· Investigation confidence depends on whether the organization can reconstruct Claude Code version state, deeplink invocation activity, settings modification, hook creation, shell execution, repository context, endpoint telemetry, identity activity, token use, and downstream CI/CD or cloud access.

S4 — Key Judgments

· Claude Code deeplink settings-injection RCE creates a high-priority developer-workstation execution risk when deeplink-driven behavior or settings manipulation can influence local Claude Code configuration or execution in a trusted development context.

· The primary business risk is loss of confidence that developer endpoints, local repositories, AI-tool configuration, shell execution history, secrets, source-code access, and software-delivery workflows remain trustworthy.

· The strongest enterprise risk signal is suspicious Claude Code deeplink or configuration activity followed by settings modification, hook creation, unexpected shell execution, new child processes, outbound network activity, credential access, repository manipulation, package-manager activity, git operations, or cloud or CI/CD authentication.

· A vulnerable Claude Code version, unmanaged deeplink handler, or suspicious settings condition should not be treated as confirmed compromise by itself, but it requires urgent review when paired with suspicious endpoint, configuration, shell, network, credential, repository, identity, cloud, or CI/CD activity.

· High-value developer involvement materially increases risk, especially when affected users have access to production code, security tooling, cloud environments, CI/CD administration, release signing, package publishing, customer data, model or agent infrastructure, privileged repositories, or incident-response systems.

· Host compromise should not be assumed unless independent evidence supports escalation beyond configuration manipulation, attempted execution, or suspicious tool behavior.

· Executive risk reduction depends on version validation, update enforcement, deeplink exposure review, endpoint telemetry readiness, developer secrets governance, repository trust controls, local configuration monitoring, EDR visibility, CI/CD credential scoping, and clear classification of suspicious Claude Code activity.

S5 — Executive Risk Summary

Business Risk

Claude Code deeplink settings-injection RCE can create material developer-workstation, source-code, secrets, software-supply-chain, operational, legal, compliance, and governance risk when suspicious deeplink or settings activity leads to local command execution, unauthorized configuration changes, credential access, repository manipulation, outbound communication, tool-configuration persistence, or downstream abuse of developer privileges. Risk increases when affected developers have access to production repositories, CI/CD systems, cloud environments, package registries, signing keys, deployment credentials, security tooling, customer-impacting code, or privileged engineering systems.

Technical Cause

The risk is driven by abuse or misuse of Claude Code deeplink handling, settings behavior, local configuration trust boundaries, tool startup behavior, hook-capable configuration, shell execution pathways, and developer workstation permissions. Suspicious activity may include unexpected Claude Code invocation through a deeplink, modification of Claude Code settings files, creation or alteration of hook definitions, execution of child processes from Claude Code, new shell activity tied to Claude Code, outbound connections from unexpected developer processes, credential file access, unusual git activity, repository configuration changes, package-manager activity, or cloud and CI/CD authentication following suspicious Claude Code behavior. These artifacts should be evaluated in correlation and should not be treated as standalone proof of compromise without supporting context.

Threat Posture

The threat posture is elevated because AI coding assistants operate in environments where configuration, repository metadata, local automation, shell access, and user-approved tooling may already have operational authority. Related Claude Code vulnerability research demonstrates that configuration and project files can become execution-relevant under certain conditions, especially when trust decisions occur after local configuration or project content has already influenced tool behavior. The risk is amplified when Claude Code versions are unmanaged, developer endpoints have broad privileges, local secrets are persistent, EDR coverage is incomplete, deeplink handlers are not governed, repository trust practices are informal, and CI/CD or cloud credentials are available from developer machines.

Executive Decision Requirement

Executives must require validation of Claude Code version state, update enforcement, deeplink handler exposure, developer workstation telemetry, Claude Code settings integrity, hook and configuration review, repository trust controls, local secrets management, API token rotation readiness, cloud and CI/CD credential scoping, and investigation evidence retention. Response leadership should also confirm that suspicious Claude Code activity is reviewed historically rather than closed solely because there is no confirmed malware family, no production outage, or no immediately visible source-code change.

S6 — Executive Cost Summary

Claude Code deeplink settings-injection RCE creates financial exposure based on the number and privilege level of affected developer workstations, Claude Code deployment scale, vulnerable-version footprint, deeplink handler exposure, repository access scope, local secrets exposure, source-code sensitivity, CI/CD credential reach, cloud identity reach, package-publishing privileges, endpoint telemetry quality, and the organization’s ability to reconstruct suspicious execution, configuration, identity, and repository activity. The largest cost drivers are not generic vulnerability-management costs. They are developer workstation forensics, credential rotation, repository integrity validation, CI/CD access scoping, cloud-session review, package-registry assurance, and software-delivery trust restoration.

Low Impact Scenario

Rapid assessment confirms Claude Code is updated to a fixed version across managed developer endpoints; deeplink handler exposure is understood; suspicious deeplink activity is not observed; Claude Code settings and hook-capable configuration are clean; endpoint records are available; no suspicious child-process execution, outbound communication, credential access, repository manipulation, package-manager abuse, git activity, cloud authentication, or CI/CD activity is tied to Claude Code; and high-privilege developer workstations show no unauthorized activity. Response remains limited to version validation, endpoint sampling, configuration review, developer communications, targeted hunting, policy adjustment, and executive tracking; estimated impact $300K to $1.25M.

Moderate Impact Scenario

One or more developer endpoints show suspicious Claude Code deeplink invocation, unexpected settings modification, hook-capable configuration changes, abnormal child-process execution, unfamiliar outbound communication, credential-access concerns, repository activity, package-manager behavior, or identity activity without confirmed source-code tampering, production impact, package compromise, cloud environment misuse, or broad secret exfiltration. Response requires endpoint containment, developer workstation forensics, Claude Code configuration review, token and SSH key rotation for affected users, repository integrity validation, CI/CD access review, cloud session review, EDR and log preservation, legal assessment, engineering coordination, and executive reporting; estimated impact $1.25M to $9M.

High Impact Scenario

Confirmed or strongly suspected Claude Code abuse affects developers with access to production repositories, privileged engineering systems, CI/CD administration, cloud infrastructure, package publishing, release signing, security tooling, customer-impacting services, or sensitive intellectual property. Evidence may include successful local execution, credential theft, unauthorized git operations, suspicious repository modification, package or dependency manipulation, cloud authentication misuse, CI/CD secret access, persistence through developer tooling, outbound exfiltration, or downstream software-delivery risk. Response may require expanded workstation forensics, enterprise token rotation, SSH key replacement, package-registry review, source-code integrity validation, build-pipeline reconstruction, release-signing assurance, cloud access investigation, customer or partner communications readiness, legal and regulatory review, cyber insurance coordination where applicable, and board-level incident governance; estimated impact $9M to $45M or higher.

S6A — Key Cost Drivers

· Number of developer workstations running vulnerable or unverified Claude Code versions.

· Number of users with Claude Code installed through unmanaged local package managers, direct downloads, homebrew workflows, npm-based installation paths, or non-standard developer images.

· Presence of externally reachable or user-triggerable deeplink handlers that can influence Claude Code behavior.

· Evidence of unexpected Claude Code settings modification, hook creation, configuration drift, child-process execution, shell activity, or outbound communication.

· Access level of affected developers, including production repositories, privileged source-code groups, cloud consoles, CI/CD systems, release tooling, package registries, signing infrastructure, incident-response tooling, and security repositories.

· Presence of local secrets, API keys, SSH keys, git credentials, cloud tokens, package-publishing tokens, CI/CD credentials, customer-support credentials, or internal service tokens on affected workstations.

· Sensitivity of repositories accessible from affected machines, including production service code, customer-facing application code, infrastructure-as-code, deployment automation, authentication logic, detection content, incident-response tooling, and proprietary engineering assets.

· Ability to reconstruct deeplink invocation, Claude Code version state, settings changes, shell execution, process trees, network activity, file access, git activity, and identity use.

· Breadth of required token rotation, SSH key replacement, cloud session revocation, package-registry validation, repository integrity review, and build-pipeline assurance.

· Need for legal review, customer assurance, partner notification readiness, cyber insurance coordination, software-supply-chain investigation, engineering freeze decisions, or board reporting.

Most Likely Scenario Justification

Moderate scenario is most likely when suspicious Claude Code deeplink or settings activity requires developer endpoint scoping, configuration validation, token review, repository integrity checks, identity-session analysis, and CI/CD access assessment, but available evidence does not confirm broad source-code tampering, package compromise, production deployment impact, cloud-environment misuse, or large-scale secret exfiltration. The estimate moves toward the lower end when affected endpoints are few, Claude Code is confirmed updated, configuration changes are explainable, endpoint telemetry is complete, no secrets were accessed, no suspicious git activity occurred, and no downstream CI/CD or cloud activity is observed. The estimate moves toward the upper end when affected developers are highly privileged, local secrets are persistent, endpoint telemetry is incomplete, settings or hooks cannot be confidently explained, suspicious outbound communication exists, repository activity is abnormal, or secret exposure cannot be ruled out.

S6B — Compliance and Risk Context

Compliance Exposure Indicator

Moderate to High depending on whether suspicious Claude Code activity, workstation execution, credential access, source-code exposure, repository manipulation, cloud access, CI/CD access, package-registry activity, or evidence gaps affected systems connected to regulated data, customer-impacting software, financial systems, authentication infrastructure, production deployment workflows, security tooling, contractual commitments, confidential intellectual property, or material software-supply-chain controls. Compliance pressure increases when affected developer access includes customer data pathways, regulated-service code, production secrets, audit-sensitive deployment systems, or evidence gaps that prevent confident scoping.

Risk Register Entry

Risk Title

Claude Code Deeplink Settings-Injection Developer Workstation Execution Risk

Risk Description

Adversaries may abuse Claude Code deeplink handling, settings injection, local configuration behavior, hook-capable settings, shell execution pathways, or developer workstation trust boundaries to attempt command execution, modify tool configuration, access local secrets, manipulate repositories, initiate outbound communication, persist through development tooling, or enable downstream abuse of source-code, cloud, CI/CD, package-registry, or software-delivery workflows. The risk is significant because AI coding assistants operate inside trusted engineering environments where local configuration and repository context can influence execution, networking, and permissions.

Likelihood

Medium to High.

Impact

Severe.

Risk Rating

Critical.

Annualized Risk Exposure

Estimated $2M to $18M or higher based on Claude Code deployment scale, vulnerable-version footprint, developer privilege level, deeplink exposure, endpoint telemetry quality, local secrets posture, repository sensitivity, CI/CD and cloud credential reach, package-registry access, source-code integrity requirements, token rotation burden, forensic complexity, software-supply-chain assurance requirements, legal obligations, and customer or partner exposure.

S7 — Risk Drivers

· Claude Code operates in a trusted developer context where local execution, repository interaction, configuration loading, shell access, and workflow automation are expected behaviors.

· Deeplink handling can move risk from a browser or external application interaction into a local development tool context.

· Settings and hook-capable configuration can become execution-relevant control surfaces rather than passive preferences.

· Developer workstations frequently hold high-value credentials, including API keys, SSH keys, git credentials, package tokens, cloud credentials, and CI/CD access material.

· Repository access increases downstream risk because source-code changes, dependency manipulation, build-script changes, and infrastructure-as-code modifications may not immediately look like endpoint compromise.

· Privileged engineering users can create a bridge between workstation compromise and production-impacting systems.

· Legitimate developer activity, AI assistant execution, package installation, repository setup, local tests, build scripts, and shell commands can resemble suspicious behavior without strong endpoint and repository context.

· Incomplete EDR, process telemetry, shell logging, file monitoring, network telemetry, and identity-session evidence can materially delay scoping.

· Short retention windows can prevent correlation between initial deeplink activity and later credential use, repository changes, cloud authentication, or CI/CD activity.

· Network-only visibility is insufficient because the core risk may be local configuration manipulation, trusted tool execution, repository-context abuse, credential access, or developer identity misuse.

S8 — Bottom Line for Executives

Claude Code deeplink settings-injection RCE should be treated as a high-priority developer-workstation and software-delivery trust risk. The key executive concern is not only whether Claude Code is patched, but whether developer endpoints, AI-tool configuration, local secrets, repository access, shell execution, CI/CD credentials, cloud sessions, and package-publishing workflows remain trustworthy after suspicious activity. Risk reduction depends on fixed-version enforcement, deeplink handler governance, Claude Code settings review, developer endpoint telemetry, local secrets reduction, repository trust controls, credential rotation readiness, CI/CD access scoping, cloud-session review, evidence preservation, and clear incident classification. Organizations should prioritize this report because compromise of an AI coding assistant on a developer workstation can create source-code, secrets, build-pipeline, cloud, software-supply-chain, and governance exposure without always producing an obvious production outage or conventional malware pattern.

S9 — Board-Level Takeaway

Claude Code deeplink settings-injection RCE can turn a trusted AI coding assistant into a developer-workstation execution and software-delivery trust failure point. The board-level concern is that development environments may appear operationally normal while settings manipulation, hook-capable configuration, local shell execution, credential access, repository changes, or developer identity misuse create downstream exposure to source-code integrity, secrets protection, cloud access, CI/CD trust, package publishing, and customer-impacting software assurance. Leadership should require evidence that Claude Code is updated, deeplink exposure is understood, developer endpoints are observable, Claude Code settings are governed, local secrets are controlled, suspicious execution can be reconstructed, high-privilege engineering users are prioritized, CI/CD and cloud credentials can be scoped, and suspicious activity can be classified with sufficient evidence. This report supports governance decisions around AI coding assistant risk, developer workstation trust, secure engineering controls, secrets management, software-supply-chain assurance, and enterprise confidence in AI-enabled development workflows.

Figure 2

S10 — Threat Overview

Claude Code deeplink settings-injection RCE and developer workstation execution risk refers to abuse of a trusted AI coding assistant, local configuration behavior, deeplink handling, and developer workstation context in a way that may weaken confidence in endpoint integrity, source-code access, local secrets, repository workflows, cloud credentials, and software-delivery controls. The activity is not best understood as a conventional malware family, standalone network intrusion pattern, or automatic production-compromise event. It is a developer-workstation and software-delivery trust risk centered on whether Claude Code activity, local settings, execution behavior, and downstream engineering access remained authorized.

The core risk is that an attacker may attempt to influence Claude Code behavior through deeplink-driven activity, settings manipulation, project or workspace configuration, hook-capable behavior, or developer-facing content that causes local execution or creates a path to credential exposure. The most important business question is whether the organization can prove that developer endpoints, local secrets, repositories, CI/CD pathways, cloud sessions, package-registry access, and software-delivery workflows remained protected during and after suspicious Claude Code activity.

This activity is difficult to assess through single-event evidence because normal AI coding assistant use, repository setup, local testing, package installation, shell execution, build automation, and developer troubleshooting can produce similar artifacts. High-confidence assessment depends on correlation across Claude Code invocation, version state, settings changes, hook-capable configuration, process execution, shell activity, file access, credential access, repository activity, identity sessions, cloud access, CI/CD use, and approved developer context.

Claude Code deeplink settings-injection RCE should therefore be treated as a developer-workstation and software-delivery trust-boundary risk. The response objective is not only to identify suspicious tool behavior, but to determine whether endpoint trust, local secret protection, repository integrity, privileged developer access, and software-delivery assurance can be validated for affected engineering environments.

S11 — Threat Classification and Type

Threat Type

Developer workstation execution and software-delivery trust risk.

Threat Sub-Type

AI coding assistant deeplink abuse, local settings manipulation, hook-capable configuration abuse, developer credential exposure, repository trust abuse, and CI/CD-adjacent risk.

Operational Classification

Trusted development tool abuse, local configuration abuse, user-execution-adjacent activity, credential-access-adjacent activity, repository-adjacent activity, and software-supply-chain trust exposure.

Primary Function

The primary function is to weaken the trustworthiness of a developer workstation or software-delivery workflow by abusing Claude Code interaction, deeplink behavior, local settings, hook-capable configuration, or developer execution context. The activity may support unauthorized local execution, credential exposure, repository manipulation, package-workflow risk, CI/CD access review, cloud-session concern, or downstream legal, operational, software-integrity, and governance exposure.

S12 — Campaign or Activity Overview

Claude Code deeplink settings-injection RCE does not require a single fixed campaign pattern. The activity can appear as opportunistic abuse of affected Claude Code versions, targeted developer-workstation activity, repository-lure activity, malicious documentation or issue content, configuration manipulation, credential-access preparation, or a broader attempt to compromise trusted software-delivery workflows. The most important activity pattern is not a single payload name, repository artifact, URL format, or command string, but the relationship between suspicious Claude Code activity and surrounding endpoint, identity, repository, credential, and engineering context.

Relevant activity may begin with a developer-facing link, repository instruction, issue tracker entry, documentation page, chat message, pull request, or other workflow that influences Claude Code behavior. In some cases, activity may remain limited to attempted invocation, settings modification, or suspicious configuration. In other cases, it may justify review of local execution, credential access, repository activity, outbound communication, cloud authentication, package-registry interaction, or CI/CD access.

The strongest enterprise concern arises when suspicious Claude Code invocation, settings modification, hook-capable configuration, unexpected child-process execution, credential access, repository changes, outbound network activity, package-manager activity, cloud authentication, or CI/CD activity appear together. The concern increases further when the affected user has access to production repositories, deployment workflows, cloud environments, package registries, release-signing systems, security tooling, customer-impacting code, or sensitive intellectual property.

This activity should be assessed through a behavior-led model. Static strings, isolated deeplink activity, one-off settings changes, normal Claude Code use, routine shell execution, standard package-manager activity, or ordinary repository work should not drive the primary risk judgment. The more durable question is whether Claude Code and developer-workstation controls were used in a way that falls outside approved identity, endpoint, repository, credential, software-delivery, and business context.

S13 — Targets and Exposure Surface

Claude Code deeplink settings-injection RCE is most relevant to developer environments where Claude Code is installed, local settings influence tool behavior, deeplink handling is available, and developers have access to source code, secrets, build workflows, cloud environments, package registries, or CI/CD systems. The exposure surface is not limited to Claude Code alone. It spans developer workstations, local configuration files, shell environments, repository workflows, package managers, credential stores, source-code platforms, cloud sessions, CI/CD systems, and software-delivery governance.

High-priority targets include developer users and engineering workflows where unauthorized execution or credential exposure would create disproportionate business impact. This includes production engineers, platform engineers, DevOps users, SRE teams, security engineers, internal tooling teams, release engineers, package maintainers, cloud administrators, and developers with access to customer-impacting code or regulated-service repositories. These targets create elevated risk because misuse may lead to source-code exposure, credential theft, repository manipulation, build-pipeline concern, cloud access, package-delivery risk, or downstream software-integrity questions.

The exposure surface also includes developer endpoint management, Claude Code version control, local settings governance, hook review, repository trust practices, branch protection, package-registry permissions, cloud identity controls, CI/CD credential scope, EDR coverage, process telemetry, shell logging, file monitoring, and evidence retention. Weakness in any of these areas can reduce confidence that Claude Code activity and developer-workstation behavior remained authorized, traceable, and business-justified.

S14 — Sectors / Countries Affected

Sectors Affected

· Software development, technology services, SaaS, cloud services, and platform engineering organizations.

· Financial services, fintech, payment-processing, banking, insurance, accounting, and business-services organizations with internal engineering teams.

· Healthcare technology, life sciences, medical research, hospitals, regulated care environments, and health-data platforms with software-development functions.

· Government contractors, defense technology providers, public-sector technology teams, municipal technology organizations, and public-administration software environments.

· Managed service providers, managed security service providers, outsourcing providers, IT services firms, and organizations operating shared engineering or support functions.

· Energy, utilities, manufacturing, transportation, logistics, telecommunications, and critical infrastructure operators with internal software, automation, or cloud engineering functions.

· AI, data, automation, DevOps, platform, security engineering, and internal tooling organizations.

· Organizations with production repositories, cloud administration, CI/CD systems, package registries, signing workflows, customer-impacting applications, regulated-service code, or sensitive intellectual property reachable from developer workstations.

· Organizations relying on Claude Code, AI coding assistants, local developer tooling, repository-based automation, package-manager workflows, and engineering workstations for business-critical software delivery.

Countries Affected

· Global.

· Exposure is not limited to a single country or region because Claude Code, AI coding assistants, developer workstations, source-code platforms, cloud services, CI/CD systems, and package registries are used globally.

· Countries with large software-development sectors, cloud engineering workforces, outsourcing ecosystems, financial technology industries, public-sector technology programs, critical infrastructure engineering teams, or technology-heavy enterprises may face elevated operational exposure.

Overall Targeting Probability

Medium to High.

Claude Code deeplink settings-injection RCE becomes materially plausible where affected Claude Code versions, unmanaged developer tooling, permissive deeplink handling, persistent local secrets, weak endpoint telemetry, privileged developer access, high-value repositories, cloud access, package-registry permissions, or CI/CD dependencies create an exploitable business surface. The risk is strongest for organizations that rely heavily on AI-enabled development workflows but cannot quickly prove that Claude Code activity, local settings changes, process execution, credential access, repository activity, identity sessions, and software-delivery actions are authorized, traceable, and business-justified.

Targeting Drivers

· Broad Claude Code or AI coding assistant adoption across engineering teams.

· Developer workstations with persistent local credentials, SSH keys, git access, cloud sessions, package-registry tokens, or CI/CD access material.

· Privileged developers with production repository access, cloud administration privileges, CI/CD permissions, package-publishing rights, or release-signing responsibilities.

· Unmanaged or inconsistently managed Claude Code installation and update paths.

· Limited governance over deeplink handling, local settings, workspace configuration, project configuration, and hook-capable behavior.

· Weak linkage between developer activity, endpoint telemetry, repository actions, change tickets, pull requests, build activity, and business justification.

· Incomplete process telemetry, shell logging, file monitoring, network records, credential-access evidence, source-code platform logs, cloud logs, or CI/CD audit records.

· Organizations where software delivery, customer-facing applications, regulated-service code, cloud operations, or package distribution are central to business operations.

Most Likely Targets

· Developers with production source-code access.

· Platform engineering, DevOps, SRE, and release engineering teams.

· Security engineering, incident-response, and internal tooling teams.

· Cloud administrators and infrastructure-as-code maintainers.

· CI/CD administrators and build-system maintainers.

· Package maintainers and release-signing users.

· Developers working on authentication, authorization, payment, customer-data, regulated-service, or security-sensitive code.

· Contractors, distributed engineering users, and temporary staff operating outside tightly managed endpoint baselines.

· Organizations with persistent local secrets, weak developer endpoint controls, broad repository access, package-registry exposure, or cloud and CI/CD access reachable from developer workstations.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Developer-Facing Invocation Opportunity

A developer interacts with a link or developer-facing artifact that can influence local Claude Code behavior.

· ATT&CK mapping: User Execution: Malicious Link T1204.001.

· Confidence: Conditional. Applies when a link, documentation page, issue, pull request, chat message, or similar user-facing artifact is part of observed activity.

Stage 2 — Local Command or Script Execution

Claude Code behavior, settings manipulation, or local configuration leads to command or script execution on the developer workstation.

· ATT&CK mapping: Command and Scripting Interpreter T1059.

· Confidence: Conditional to likely. Applies when endpoint telemetry shows shell, script, interpreter, or command execution tied to Claude Code or its child processes.

Stage 3 — Hook-Capable or Event-Triggered Execution

Claude Code settings, hooks, or configuration trigger execution during a tool action, project event, or local workflow.

· ATT&CK mapping: Event Triggered Execution T1546.

· Confidence: Conditional. Applies only when configuration or hook behavior creates repeatable execution tied to a tool or workflow event.

Stage 4 — Developer Credential Exposure

Activity accesses local secrets, environment variables, credential files, SSH keys, API tokens, package tokens, cloud credentials, or CI/CD credentials.

· ATT&CK mapping: Unsecured Credentials T1552.

· Confidence: Conditional. Applies when endpoint, file, process, or shell evidence supports access to local secret material.

Stage 5 — Source-Code or Repository Access

Activity accesses source-code repositories, local working directories, package manifests, build scripts, infrastructure-as-code, or deployment automation.

· ATT&CK mapping: Data from Information Repositories: Code Repositories T1213.003.

· Confidence: Conditional. Applies when repository, endpoint, git, file, or identity evidence supports suspicious repository access or collection.

Stage 6 — Follow-On Use of Developer Accounts

Developer credentials, sessions, or tokens are used for source-code, cloud, package-registry, or CI/CD access after suspicious Claude Code activity.

· ATT&CK mapping: Valid Accounts T1078.

Claude Code deeplink settings-injection RCE becomes materially more severe when suspicious tool interaction intersects with developer credentials, local secrets, source-code repositories, privileged engineering systems, release workflows, or incomplete evidence. The core risk is not simply that Claude Code is affected or a developer workstation is exposed. The larger risk is reduced confidence in endpoint integrity, repository trust, credential protection, build-system assurance, and software-delivery governance.

Primary Risk Amplifiers

· Suspicious Claude Code activity involves developers with production repository access, cloud privileges, CI/CD permissions, package-publishing access, release-signing duties, security tooling access, or customer-impacting code responsibilities.

· Claude Code invocation follows a developer-facing link, repository artifact, documentation page, issue, pull request, chat message, or workflow that lacks clear business justification.

· Settings modification, workspace configuration changes, project configuration changes, or hook-capable behavior follows suspicious invocation or repository interaction.

· Claude Code spawns shell, script, interpreter, package-manager, git, cloud CLI, or other child processes outside expected developer workflow context.

· Activity accesses local secrets, credential files, environment variables, SSH keys, API tokens, package tokens, cloud credentials, or CI/CD credentials.

· Repository access, file changes, branch activity, package-manifest changes, build-script changes, infrastructure-as-code changes, or deployment configuration activity follows suspicious tool behavior.

· Engineering-system activity occurs from unusual devices, sources, sessions, locations, or timing patterns.

· Outbound transfer, archive creation, upload activity, or external communication involves source code, secrets, build artifacts, configuration files, logs, or engineering data.

· Developer activity cannot be explained by a ticket, pull request, approved change, release task, build workflow, incident-response action, or documented business need.

· Evidence is incomplete because endpoint telemetry, process data, shell logs, file events, network records, source-code platform logs, cloud logs, CI/CD records, package-registry logs, or identity records are unavailable or retained for too short a period.

Risk Interpretation

The risk should be escalated when Claude Code-centered activity moves from isolated invocation, normal tool use, or explainable configuration behavior into correlated execution, credential, repository, engineering-system, or outbound communication signals. Single events may justify review, but high-confidence risk emerges when multiple independent sources point to unauthorized local execution, credential exposure, suspicious repository activity, unexplained developer identity use, external data movement, or software-delivery workflow impact.

Operational Impact

The operational impact is highest when the organization cannot prove that developer endpoints, local secrets, repositories, privileged engineering systems, and release workflows remained trustworthy. In those cases, response may require endpoint preservation, Claude Code configuration review, token and SSH key rotation, source-code integrity review, package-registry review, cloud-session review, CI/CD audit review, build-pipeline assurance, release validation, legal assessment, customer or partner communications readiness, and executive assurance reporting.

S20 — Tactics, Techniques, and Procedures

Figure 3

Developer-Facing Invocation

· Use a link, documentation page, issue, pull request, chat message, repository instruction, or developer workflow to trigger interaction with Claude Code or a related local invocation path.

· Present activity as ordinary engineering collaboration, onboarding guidance, repository setup, bug reproduction, proof-of-concept review, or tool configuration.

Deeplink and Tool-Context Abuse

· Use Claude Code deeplink behavior or local invocation context to influence tool behavior on the developer workstation.

· Pair deeplink activity with settings manipulation, hook-capable behavior, or local execution context.

Settings and Configuration Manipulation

· Create or modify Claude Code settings, workspace settings, project configuration, hook-capable configuration, or related local files.

· Blend configuration changes into normal repository setup, project onboarding, testing, troubleshooting, or development activity.

Hook-Capable Execution Behavior

· Use hook-capable settings or event-triggered behavior to execute commands during a tool action, project event, or local workflow.

· Trigger execution through behavior that appears tied to normal Claude Code, repository, or developer activity.

Local Command Execution

· Execute shell commands, scripts, interpreters, package managers, git commands, cloud CLIs, or other child processes from Claude Code or related local context.

· Use familiar developer utilities to make execution resemble normal development, testing, build, or troubleshooting activity.

Credential and Secret Access

· Access environment variables, shell profiles, credential files, SSH keys, API tokens, git credentials, package-manager tokens, cloud CLI configuration, or CI/CD-related secrets.

· Use local credential access to enable source-code platform, cloud, package-registry, or CI/CD follow-on activity.

Repository and Source-Code Interaction

· Access local repositories, source-code directories, package manifests, build scripts, infrastructure-as-code, deployment automation, or security-sensitive engineering content.

· Modify files, review sensitive code paths, enumerate repositories, inspect branch context, alter package configuration, or interact with remote repositories.

Engineering System Follow-On

· Use developer credentials, sessions, or tokens to access source-code platforms, cloud resources, CI/CD systems, package registries, build artifacts, deployment workflows, or release tooling.

· Blend follow-on activity into normal build, test, release, deployment, troubleshooting, or incident-response workflows.

Outbound Communication and Data Movement

· Create archives, stage files, encode content, upload data, or initiate outbound connections involving source code, secrets, configuration files, logs, or build artifacts.

· Use external storage, web services, repositories, paste services, package endpoints, or unfamiliar domains for transfer.

Operational Blending

· Blend suspicious activity with AI-assisted development, package installation, local testing, build execution, repository troubleshooting, cloud CLI usage, and automation.

· Exploit gaps in endpoint telemetry, shell logging, file monitoring, repository audit logs, cloud records, CI/CD records, and package-registry visibility.

S20A — Adversary Tradecraft Summary

Core Tradecraft Characteristics

· Abuse of trusted Claude Code interaction, deeplink behavior, local settings, workspace configuration, project configuration, hook-capable behavior, and developer execution context.

· Use of developer-facing artifacts such as links, documentation pages, issues, pull requests, chat messages, repository instructions, and workflow guidance to create plausible interaction.

· Blending of suspicious activity with normal AI-assisted coding, repository setup, package installation, local testing, build execution, troubleshooting, and developer automation.

· Reliance on legitimate developer utilities, including shell interpreters, package managers, git, scripting languages, cloud CLIs, source-code platforms, package registries, and CI/CD workflows.

· Targeting of developers and engineering workflows that provide access to source code, local secrets, cloud environments, CI/CD systems, package publishing, release signing, security tooling, or customer-impacting code.

· Preference for credential access, repository interaction, engineering-system follow-on activity, and software-delivery trust abuse over obvious malware deployment as the default activity model.

· Use of identity-session ambiguity, repository-context uncertainty, local-configuration complexity, developer-tool trust, and evidence gaps to delay confident scoping.

Tradecraft Assessment

Claude Code deeplink settings-injection RCE should be assessed as a developer-workstation execution and software-delivery assurance risk. The strongest cases are those where suspicious Claude Code-centered activity aligns with unexpected settings changes, hook-capable configuration, local execution, credential access, repository activity, outbound communication, engineering-system follow-on activity, privileged developer involvement, or incomplete evidence. Static strings, isolated deeplink activity, one-off configuration changes, normal Claude Code use, routine shell commands, package-manager events, or ordinary repository activity should not drive the primary judgment without corroborating endpoint, identity, repository, credential, engineering-system, business, or escalation context.

S21 — Detection Strategy Overview

Detection Philosophy

This report treats the Claude Code deeplink settings-injection flaw as an observed instance of a broader developer-workstation execution pattern, not as a single payload-specific vulnerability. The durable detection objective is to identify when a trusted AI-assisted development workflow receives externally influenced input, interprets that input as configuration or execution logic, and causes local command execution on a developer endpoint.

Detection must focus on behavior that remains relevant after the specific Claude Code issue is patched: abnormal AI coding-assistant invocation, settings or hook evaluation, unexpected shell or scripting-engine execution, suspicious local configuration activity, and post-execution indicators of credential, repository, network, or identity exposure.

The detection model must not depend on matching a single exploit string, proof-of-concept payload, deeplink format, or vulnerable version. Payload-specific detections may support enrichment and retrospective hunting, but they should not define production coverage. The primary control is behavior-led correlation across process lineage, command execution, configuration activity, user-interaction context, and downstream developer-workstation activity.

Primary Detection Anchors

The primary detection anchors are the behaviors that define the execution chain and remain defensible across variants.

· A browser, chat client, email client, documentation platform, collaboration tool, or other user-facing application invokes a local AI coding-assistant workflow.

· Claude Code or a comparable AI coding assistant starts from an unusual parent process, user-interaction path, deeplink context, or externally influenced workflow.

· Settings, hooks, project configuration, workspace-local configuration, or startup automation is evaluated near session start.

· Claude Code or a comparable AI coding assistant spawns a shell, scripting interpreter, package manager, network utility, credential utility, or other execution-capable child process outside expected developer baselines.

· Suspicious command execution is followed by indicators of outbound communication, credential access, repository access, CI/CD interaction, or identity-token use.

Detection Prioritization Model

Detection priority must be based on behavioral convergence rather than single-event matching. The highest-confidence alerts require multiple independent signals that collectively show externally influenced input leading to trusted local execution.

Priority 1

AI coding-assistant execution from an abnormal invocation context followed by shell, scripting-engine, package-manager, credential-utility, or network-utility child-process creation.

Priority 2

Settings, hook, project-configuration, or workspace-configuration activity followed by command execution or suspicious local file, network, credential, repository, or identity behavior.

Priority 3

Deeplink or URI-handler invocation followed by unexpected configuration parsing, workspace trust activity, or startup automation.

Priority 4

Suspicious settings or hook artifacts without confirmed execution, especially in newly opened repositories, externally sourced projects, or developer workspaces with elevated access.

Priority 5

Known vulnerable-version exposure, suspicious deeplink fragments, or payload indicators without execution evidence.

The most important detection event is not the presence of a deeplink by itself. The enterprise-risk event is the transition from externally influenced input into trusted local execution on a developer workstation.

Correlation Strategy

Correlation must enforce a strict relationship across user interaction, AI coding-assistant invocation, configuration interpretation, command execution, and post-execution behavior. The source case involves Claude Code deeplink handling and settings interpretation, but the defensive model generalizes that chain into observable telemetry relationships.

Required Correlation Pattern

· External or user-facing application activity occurs first.

· Claude Code or a comparable AI coding-assistant process starts from that context or shortly after it.

· Settings, hooks, project configuration, workspace-local configuration, or startup automation is accessed, modified, or evaluated.

· The AI coding-assistant process launches a shell, scripting interpreter, package manager, network utility, credential utility, or other execution-capable process.

· Additional activity confirms or increases confidence, including outbound communication, credential access, repository interaction, CI/CD activity, persistence behavior, or unusual developer identity activity.

Correlation Timing

The primary detection window should cover the first several minutes after deeplink, URI-handler, or externally influenced workflow invocation. A secondary window should capture delayed hook execution, project-open behavior, trusted-workspace reuse, or post-execution staging.

The model must not assume immediate execution in every case. Developer tools may defer execution until a workspace, session, hook, plugin, or project lifecycle event begins.

Correlation Confidence

· High confidence requires abnormal AI coding-assistant invocation plus suspicious child-process creation.

· Medium confidence requires suspicious settings, hook, or configuration activity plus contextual risk.

· Low confidence covers isolated URI-handler activity, version exposure, or suspicious strings without execution evidence.

Telemetry Prioritization

Endpoint telemetry is the primary source of truth because the execution occurs on the developer workstation. SIEM correlation should enrich endpoint events with identity, repository, network, and application context.

Highest Priority Telemetry

· Endpoint process creation telemetry with parent-child lineage.

· Command-line telemetry for Claude Code, comparable AI coding assistants, shells, scripting engines, package managers, and network utilities.

· File telemetry for settings, hooks, project-local configuration, workspace-local configuration, and trusted-workspace artifacts.

· EDR behavioral telemetry for suspicious child-process execution from AI coding-assistant processes.

· User-interaction context preceding AI coding-assistant invocation.

· Network, identity, repository, and CI/CD telemetry for post-execution enrichment.

Detection Design Constraints

Claude Code and similar AI coding assistants legitimately execute commands during normal development activity. Detection must therefore distinguish expected developer automation from externally influenced, configuration-triggered, or trust-boundary-crossing execution.

The model must avoid brittle payload dependence. Known exploit strings, fixed payload fragments, and exact proof-of-concept structures may support threat hunting, but they are not reliable production anchors. Production detection must prioritize suspicious process ancestry, unexpected settings or hook evaluation, abnormal child-process execution, and downstream activity that indicates developer-workstation exposure.

The model must also account for trusted-workspace reuse. A user may already trust a local repository or project path before attacker-controlled input is introduced. Detection must therefore cover execution that occurs inside previously trusted developer contexts, not only obviously untrusted new repositories.

Baseline and Deployment Requirements

Organizations should baseline normal AI coding-assistant behavior before production deployment.

Baseline Requirements

· Normal parent processes and launch paths.

· Expected shell, interpreter, package-manager, and build-tool child processes.

· Approved hook, settings, plugin, and project-configuration usage.

· Normal settings and hook modification frequency.

· Expected repository, CI/CD, network, and cloud-authentication patterns for developers.

· Known administrative scripts, developer automations, and sanctioned productivity tools.

Deployment Requirements

· Endpoint telemetry must preserve process lineage, command line, user identity, host identity, working directory, and timestamp.

· File telemetry must capture relevant settings, hook, project-configuration, and workspace-configuration activity.

· SIEM correlation must join endpoint events with identity, repository, network, and CI/CD context.

· Known-good suppression must be narrow, reviewed, and tied to specific repositories, users, hosts, or automation patterns.

· Tuning must be performed by developer role and workstation class to avoid broad allowlisting that suppresses high-risk activity.

Variant Resilience Requirements

The detection model must remain useful if the specific deeplink parser flaw is patched, renamed, or replaced by another configuration-injection path. Variant resilience is achieved by monitoring the behavioral class rather than the original payload.

Variant-Resilient Behaviors

· AI coding assistant receives externally influenced input.

· Local settings, hooks, plugins, project configuration, workspace trust state, or startup automation are evaluated.

· AI coding assistant spawns shell, scripting, package-management, credential, or network utilities.

· Developer workstation accesses sensitive repositories, credentials, cloud resources, CI/CD systems, or identity tokens after suspicious local execution.

· Outbound communication occurs shortly after abnormal coding-assistant execution.

The model should extend to comparable AI-assisted development tools where project settings, hooks, plugins, local servers, workspace trust, or startup automation can trigger local execution.

Operational Detection Model

The operational model uses layered analytics to move from low-confidence context to high-confidence execution evidence.

Layer 1

Detect suspicious invocation context.

· AI coding assistant starts from browser, chat, email, documentation, collaboration-tool, deeplink, or URI-handler lineage.

· AI coding assistant starts shortly after externally delivered link interaction.

· AI coding assistant starts in a repository or workspace not normally associated with the user or host.

Layer 2

Detect configuration and hook activity.

· Settings, hooks, project configuration, or workspace configuration are created, modified, or evaluated near session start.

· Project-local or user-level configuration introduces command-capable automation.

· Hook or startup automation runs outside normal repository, user, or host baseline.

Layer 3

Detect suspicious process behavior.

· AI coding assistant spawns shell interpreters, scripting engines, package managers, network utilities, credential utilities, or persistence-capable commands.

· Child process execution shows encoded content, remote retrieval, credential access, unusual environment-variable access, or system-modification behavior.

· Process execution occurs in a working directory tied to a newly opened, externally sourced, or unusual repository.

Layer 4

Detect post-execution activity.

· New outbound connections or DNS activity occur shortly after suspicious AI coding-assistant child-process execution.

· Credential stores, SSH keys, cloud tokens, environment files, or repository secrets are accessed.

· Repository, CI/CD, package-registry, or cloud-control-plane activity changes after the endpoint event.

· Persistence, staging, or lateral-movement behavior appears on the developer workstation.

Layer 5

Escalate based on business impact.

· The developer has access to production repositories, CI/CD systems, signing keys, cloud credentials, sensitive customer data, or privileged infrastructure.

· The workstation is used for release engineering, security engineering, infrastructure automation, or privileged build operations.

· Suspicious execution occurs in a repository tied to high-value product, customer, authentication, deployment, or security-control code.

S22 — Primary Detection Signals

Primary Detection Signals

Primary detection signals identify the transition from externally influenced AI coding-assistant activity into local execution on a developer workstation. The highest-value signals are not the deeplink string or vulnerable version alone. The highest-value signals are process, configuration, and execution behaviors that show a trusted development tool being used as an execution pathway.

The source case involves Claude Code deeplink handling, settings interpretation, and hook-enabled execution. The broader CyberDax detection model treats that as one expression of a larger behavior class: AI-assisted development tooling receiving externally influenced input and crossing into local command execution.

· Claude Code or a comparable AI coding assistant starts from a browser, chat client, email client, documentation platform, collaboration tool, URI handler, or other user-facing application.

· Claude Code or a comparable AI coding assistant starts shortly after a user interacts with an externally delivered link, repository reference, documentation page, issue, pull request, message, or README.

· A deeplink, local URI-handler invocation, or externally influenced launch path precedes Claude Code execution.

· Claude Code or a comparable AI coding assistant evaluates settings, hooks, project configuration, workspace-local configuration, or startup automation near session start.

· Settings or hook configuration is created, modified, or accessed immediately before AI coding-assistant execution.

· Claude Code or a comparable AI coding assistant spawns a shell, scripting interpreter, package manager, network utility, credential utility, or other execution-capable child process.

· The child process executes outside the expected developer baseline for the user, repository, host, role, or working directory.

· Suspicious process execution is followed by indicators of outbound communication, credential access, repository access, CI/CD interaction, identity-token use, staging, persistence, or lateral movement.

Supporting Detection Signals

Supporting signals provide context that increases confidence but should not be used as standalone compromise indicators. These signals help distinguish normal developer activity from suspicious externally influenced execution.

· The process parentage differs from normal Claude Code launch behavior for the host or user.

· Claude Code starts from a working directory tied to a newly opened, recently cloned, externally sourced, or unusual repository.

· Claude Code starts in a previously trusted repository shortly after the user interacts with an external link or message referencing that repository.

· Project-local settings, user-level settings, hook files, or workspace-local configuration are modified near session start.

· Hook or startup automation executes for a repository where such behavior is not normally observed.

· Command execution occurs under a developer account with access to sensitive repositories, production infrastructure, CI/CD systems, signing keys, cloud credentials, or privileged deployment workflows.

· Claude Code child-process activity includes encoded content, inline shell execution, remote retrieval, environment-variable access, credential-store access, SSH material access, package installation, or file permission changes.

· New or unusual outbound destinations appear shortly after Claude Code child-process execution.

· Repository, CI/CD, package-registry, cloud, or identity activity changes after the endpoint event.

· The endpoint shows follow-on staging, persistence, discovery, credential access, or lateral-movement behavior.

Exploit Attempt and Instability Signals

Exploit-attempt signals may indicate probing, failed exploitation, or partial execution. These signals should be correlated with execution, configuration activity, and user-interaction context before escalation.

· Claude Code is launched through a deeplink, local URI handler, or externally influenced path with unusual parameters.

· Claude Code invocation includes abnormal settings, configuration, prefill, prompt, workspace, path, or startup-related argument patterns.

· The same user or host opens multiple deeplinks or externally supplied Claude Code references in a short period.

· Claude Code opens, parses, or rejects unexpected settings or hook content near session start.

· Claude Code generates errors, warnings, abnormal exits, or session-start failures after link interaction or repository-open activity.

· The endpoint records rapid create, modify, delete, or rollback activity involving Claude Code settings, hooks, or workspace configuration.

· Security tooling records blocked child-process creation, blocked script execution, blocked network retrieval, or blocked credential access from a Claude Code process tree.

· A vulnerable or outdated Claude Code version is present on a developer workstation that also shows suspicious invocation or configuration activity.

Outbound Communication Signals

Outbound communication signals are most useful after abnormal invocation, hook activity, or child-process creation has already been observed. Network activity alone is insufficient because developer tooling commonly connects to repositories, package registries, SaaS services, documentation sites, and cloud platforms.

· Claude Code or a child process initiates outbound communication shortly after deeplink, URI-handler, or externally influenced invocation.

· A shell, scripting interpreter, package manager, or network utility launched by Claude Code connects to a newly observed or low-reputation destination.

· DNS, proxy, firewall, or EDR telemetry shows new outbound activity from a developer workstation after suspicious AI coding-assistant execution.

· Outbound traffic uses command-line retrieval utilities, encoded parameters, paste sites, file-sharing services, temporary hosting, tunneling services, or unusual cloud endpoints.

· Network activity is followed by file creation, script execution, credential access, repository interaction, or CI/CD activity.

· The destination, user agent, process lineage, or timing differs from normal developer workflow baselines.

· The endpoint initiates outbound communication while operating inside a repository, workspace, or directory associated with the suspicious AI coding-assistant session.

Persistence and Post-Exploitation Signals

Persistence and post-exploitation signals are conditional escalation indicators. They are not required for initial detection, but they materially increase severity when observed after suspicious AI coding-assistant execution.

· New or modified shell profiles, login items, launch agents, scheduled tasks, cron jobs, services, startup folders, or persistence-capable scripts appear after suspicious Claude Code activity.

· Claude Code settings, hook configuration, project-local configuration, or workspace files are modified to preserve command-capable automation.

· New scripts, binaries, temporary files, staging directories, or hidden files appear in the repository, user profile, developer tooling directory, or temporary directory.

· Credential stores, SSH keys, cloud credential files, environment files, package-registry tokens, or repository secrets are accessed after suspicious execution.

· The workstation performs host discovery, network discovery, account discovery, repository enumeration, or cloud-resource discovery after suspicious execution.

· Developer identity activity changes, including unusual repository access, CI/CD job access, package publishing, cloud login, token refresh, or privileged API use.

· EDR detects suspicious persistence, credential access, defense evasion, privilege escalation, or lateral-movement behavior under the Claude Code process tree or shortly after it.

Lateral Movement and Expansion Signals

Lateral movement and expansion signals indicate that the developer-workstation compromise may have progressed beyond local execution. These signals should drive escalation to incident response, identity review, and repository or CI/CD containment.

· The developer account accesses repositories, CI/CD systems, cloud consoles, package registries, secrets managers, or deployment systems outside normal patterns after suspicious execution.

· New SSH, Git, cloud CLI, package-manager, or CI/CD authentication activity occurs from the affected workstation.

· The workstation initiates connections to internal hosts, build systems, source-control infrastructure, artifact repositories, secrets stores, or administrative endpoints after suspicious execution.

· Repository clones, branch access, secret reads, token usage, pipeline triggers, package publication, or deployment-related actions increase after the endpoint event.

· Authentication events show unusual geolocation, device context, token reuse, session creation, service-principal use, or privilege path after the suspicious workstation activity.

· The affected user or host attempts access to systems not normally associated with the developer’s role.

· Similar suspicious Claude Code or AI coding-assistant behavior appears across multiple developer workstations, suggesting campaign activity, shared repository exposure, or repeated malicious-link delivery.

Signal Usage Constraints

Detection signals must be applied through correlation, not isolated matching. Normal developer workflows frequently involve shells, package managers, repositories, hooks, scripts, cloud CLIs, and network access. Overly broad detection will create noise and encourage dangerous suppression.

· Do not treat Claude Code execution as suspicious by itself.

· Do not treat shell execution by a developer tool as malicious without context.

· Do not rely on vulnerable-version presence as compromise evidence.

· Do not treat deeplink or URI-handler activity as compromise evidence without configuration, process, or post-execution corroboration.

· Do not use payload strings, proof-of-concept fragments, or exact exploit syntax as the primary detection logic.

· Do not broadly suppress Claude Code child-process activity across all developer systems.

· Do not broadly allowlist trusted repositories, because trusted-workspace reuse is part of the modeled risk.

· Do not assume patched versions eliminate the broader behavior class.

· Do not escalate network activity alone unless it is tied to suspicious AI coding-assistant execution or abnormal developer identity activity.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

Endpoint and process execution telemetry is the primary requirement for detecting this behavior class. The modeled risk occurs when externally influenced AI coding-assistant activity crosses into local command execution on a developer workstation. Without reliable process lineage, command-line capture, and execution context, the organization cannot distinguish normal developer automation from suspicious execution triggered through settings, hooks, deeplinks, or workspace-local configuration.

Required telemetry must capture the relationship between user-facing applications, Claude Code or comparable AI coding assistants, configuration evaluation, and child-process creation.

· Process creation events for Claude Code and comparable AI coding assistants.

· Parent-child process lineage showing whether Claude Code was launched from a browser, chat client, email client, documentation platform, collaboration tool, terminal, IDE, URI handler, or other user-facing application.

· Full command-line capture for Claude Code, shells, scripting interpreters, package managers, network utilities, credential utilities, Git clients, cloud CLIs, and build tools.

· Working directory, process hash, executable path, user identity, host identity, timestamp, and session context for relevant process events.

· Child-process creation from Claude Code or comparable AI coding-assistant processes.

· Process events involving shell interpreters, scripting engines, inline execution, encoded execution, remote retrieval, package installation, credential access, environment-variable access, or file-permission modification.

· Process termination, crash, blocked execution, and policy-enforcement events associated with Claude Code process trees.

· EDR behavioral alerts tied to suspicious process lineage, child-process creation, script execution, credential access, persistence, or lateral movement.

Memory and Execution Telemetry

Memory and execution telemetry strengthens detection when command-line logging does not fully expose execution behavior. This telemetry is most valuable when attackers use inline scripts, encoded content, interpreter abuse, or living-off-the-land execution after the AI coding assistant initiates child-process activity.

Memory telemetry is not required for every deployment, but it materially improves detection confidence when available through EDR, endpoint protection, operating-system security controls, or script-control tooling.

· Script-block, command interpreter, and shell execution telemetry where available.

· Interpreter telemetry for PowerShell, Bash, Zsh, Python, Node.js, Ruby, Perl, JavaScript runtimes, and other scripting engines used in developer environments.

· Suspicious in-memory execution, encoded command use, reflective loading, interpreter child-process behavior, or unusual execution chains.

· EDR detections for credential access, defense evasion, process injection, suspicious module loading, unusual environment-variable access, or token access.

· Operating-system security events showing blocked script execution, constrained-language enforcement, application-control enforcement, or exploit-prevention activity.

· Security events showing suspicious use of developer tooling to launch secondary interpreters, local servers, package scripts, or command-execution frameworks.

Crash and Fault Telemetry

Crash and fault telemetry supports detection of failed exploitation, unstable invocation attempts, parser errors, blocked execution, or malformed configuration handling. These events should not be treated as standalone compromise evidence, but they can provide useful context when correlated with externally delivered links, deeplink activity, settings evaluation, or failed child-process creation.

· Claude Code crashes, abnormal exits, session-start failures, parser errors, or unexpected application termination near link interaction or repository-open activity.

· Operating-system fault reports involving Claude Code or comparable AI coding assistants.

· EDR, application-control, or endpoint-protection events showing blocked command execution, blocked script execution, blocked network retrieval, or blocked credential access from a Claude Code process tree.

· Repeated launch failures involving unusual arguments, settings references, workspace paths, hook configuration, or startup automation.

· Error logs showing rejected settings, malformed configuration, failed hook evaluation, or invalid workspace state.

· Helpdesk, endpoint-health, or application telemetry showing repeated Claude Code instability across multiple developer workstations after similar link or repository activity.

File and Configuration Telemetry

File and configuration telemetry is required to identify suspicious settings activity, hook creation, workspace-local changes, and command-capable automation. This behavior class depends on the boundary between trusted developer tooling and local configuration. File telemetry must therefore cover both user-level and project-local configuration surfaces.

· Creation, modification, access, or deletion of Claude Code settings, hooks, project-local configuration, workspace-local configuration, trusted-workspace artifacts, and startup automation files.

· File events involving repositories, recently cloned projects, externally sourced workspaces, temporary directories, developer-tooling directories, and user profile paths.

· Creation or modification of shell profiles, login items, launch agents, scheduled tasks, cron jobs, services, startup folders, or persistence-capable scripts after suspicious Claude Code execution.

· Creation of scripts, binaries, temporary files, staging directories, hidden files, encoded files, or downloaded tools after AI coding-assistant child-process activity.

· Access to credential stores, SSH keys, cloud credential files, environment files, repository secrets, package-registry tokens, signing material, and CI/CD configuration.

· File events showing rapid create, modify, delete, rollback, or cleanup activity involving settings, hooks, scripts, or workspace configuration.

· Repository-local changes that introduce command-capable automation, hook execution, suspicious install scripts, startup behavior, or unexpected developer-tool configuration.

Network and Outbound Communication Telemetry

Network telemetry is required to identify post-execution communication, payload retrieval, command-and-control staging, credential exfiltration, and downstream expansion. Network activity must be correlated with endpoint process lineage because developer workstations routinely connect to repositories, package registries, documentation services, SaaS platforms, cloud services, and build infrastructure.

· DNS, proxy, firewall, EDR network, and endpoint socket telemetry for the developer workstation.

· Process-aware network telemetry linking outbound connections to Claude Code, shells, scripting interpreters, package managers, network utilities, Git clients, cloud CLIs, and build tools.

· Destination domain, IP address, port, protocol, user agent, TLS metadata where available, timestamp, host identity, user identity, and process lineage.

· New, rare, low-reputation, temporary-hosting, paste-site, file-sharing, tunneling, or unusual cloud destinations contacted after suspicious AI coding-assistant execution.

· Outbound communication from child processes launched by Claude Code or comparable AI coding assistants.

· Network retrieval followed by file creation, script execution, credential access, repository activity, package activity, or CI/CD activity.

· Large, unusual, or compressed outbound transfers from developer workstations after suspicious execution.

· Internal network connections to build systems, source-control systems, artifact repositories, secrets managers, administrative endpoints, cloud services, or CI/CD infrastructure after suspicious endpoint activity.

Web and Application Telemetry

Web and application telemetry is conditionally available but high value. It helps identify the external influence point that preceded local execution. This telemetry is especially useful when the suspicious workflow starts from a browser, chat message, documentation page, email, issue tracker, pull request, README, or collaboration platform.

· Browser history, URL telemetry, web-proxy logs, email-security logs, chat logs, documentation access logs, and collaboration-platform activity showing link interaction before Claude Code execution.

· Local URI-handler or deeplink invocation telemetry where available.

· Email, chat, issue, pull-request, documentation, or repository references that delivered the link or project path.

· Web downloads, repository previews, file opens, or documentation-page visits occurring shortly before AI coding-assistant invocation.

· User interaction with externally supplied repository references, setup instructions, README content, issue comments, pull requests, or pasted commands.

· Application logs showing Claude Code launch context, session start, workspace open, settings evaluation, or hook execution where available.

· Browser-to-local-application handoff telemetry that links external content to local Claude Code execution.

Identity, Repository, and CI/CD Telemetry

Identity, repository, and CI/CD telemetry is required to assess downstream exposure after suspicious developer-workstation execution. This report models the risk as more than local code execution. The higher enterprise impact occurs when the compromised workstation or developer identity can reach source code, secrets, build systems, cloud accounts, package registries, or deployment workflows.

· Identity-provider logs showing authentication events, session creation, token refresh, device posture, MFA results, conditional-access decisions, geolocation, ASN, and sign-in risk.

· Source-control logs showing clone, fetch, branch access, repository access, secret access, pull-request activity, commit activity, deploy-key use, SSH key use, token use, and unusual repository enumeration.

· CI/CD logs showing job access, workflow execution, pipeline trigger, runner interaction, artifact access, secret access, deployment activity, and build-configuration changes.

· Package-registry logs showing package reads, package publishing, token use, scope changes, ownership changes, or unusual automation activity.

· Secrets-manager and cloud-control-plane logs showing secret reads, credential use, role assumption, access-key creation, token exchange, or unusual privileged API activity.

· Device and identity correlation showing whether post-execution access originated from the affected workstation, a new device, a new session, or a reused token.

· Privilege and asset context identifying whether the developer has access to production repositories, signing keys, deployment systems, security tooling, sensitive customer systems, or privileged infrastructure.

Telemetry Availability Requirements

Minimum viable detection requires endpoint process telemetry, command-line capture, and enough file telemetry to observe settings, hooks, project configuration, and workspace-local changes. Without those sources, detection becomes dependent on weak indicators such as vulnerable-version exposure, isolated deeplink activity, or downstream network anomalies.

Minimum Required Telemetry

· Endpoint process creation with parent-child lineage.

· Full command-line capture for Claude Code, comparable AI coding assistants, shells, scripting interpreters, package managers, network utilities, Git clients, cloud CLIs, and build tools.

· File telemetry for settings, hooks, project-local configuration, workspace-local configuration, and persistence-capable paths.

· EDR behavioral telemetry for suspicious child-process creation, script execution, credential access, persistence, and lateral movement.

· Network telemetry that can identify outbound activity from the affected host.

· Identity and repository telemetry sufficient to evaluate post-execution exposure.

Preferred Telemetry

· Process-aware network telemetry.

· Browser, email, chat, documentation, and collaboration-platform link-interaction telemetry.

· Local URI-handler or deeplink invocation telemetry.

· CI/CD, package-registry, secrets-manager, and cloud-control-plane telemetry.

· Application-control, script-control, and exploit-prevention events.

· Asset, role, and privilege context for developer workstations and identities.

Telemetry Limitations and Gaps

Telemetry gaps directly reduce detection confidence. The most significant limitation is the lack of full endpoint process lineage or command-line capture. Without those records, defenders may see downstream artifacts without knowing whether Claude Code or another AI coding assistant initiated the execution chain.

· If parent-child process lineage is missing, the organization may not be able to connect suspicious shell or scripting activity to Claude Code execution.

· If command-line capture is incomplete, encoded execution, settings references, interpreter abuse, and remote retrieval may not be visible.

· If file telemetry is missing, suspicious settings, hooks, workspace configuration, and persistence changes may go undetected.

· If URI-handler or browser-to-local-application telemetry is unavailable, the initial external influence point may be difficult to prove.

· If network telemetry is not process-aware, outbound activity may be visible but difficult to attribute to the Claude Code process tree.

· If identity, repository, and CI/CD telemetry is incomplete, downstream exposure may be underestimated.

· If developer baselines are not established, normal automation may generate excessive noise or suspicious behavior may be suppressed too broadly.

· If vulnerability-management data is stale, defenders may overstate or understate exposure to the specific Claude Code version while missing the broader behavior class.

· If telemetry retention is short, delayed discovery may prevent reconstruction of the link interaction, configuration change, execution chain, and downstream access sequence.

S24 — Detection Opportunities and Gaps

Figure 4

Detection Opportunities

The strongest detection opportunity is the transition from externally influenced AI coding-assistant activity into local command execution on a developer workstation. The source case involves Claude Code deeplink handling, settings interpretation, and hook-enabled execution, but the durable detection opportunity is broader: a trusted development tool crossing from user-controlled or externally influenced input into command-capable local execution.

Detection should prioritize behavior that remains observable across variants, patched versions, and adjacent AI-assisted development tools.

· Abnormal Claude Code or comparable AI coding-assistant launch context.

· Browser, chat, email, documentation, collaboration-tool, deeplink, or URI-handler lineage preceding AI coding-assistant execution.

· Settings, hooks, project configuration, workspace-local configuration, or startup automation evaluated near session start.

· AI coding-assistant process spawning a shell, scripting interpreter, package manager, network utility, credential utility, Git client, cloud CLI, or build tool outside expected developer baseline.

· Configuration activity followed by local execution, network activity, credential access, repository access, CI/CD interaction, or identity-token use.

· Post-execution behavior involving outbound communication, staging, persistence, discovery, credential access, repository enumeration, cloud access, or CI/CD activity.

High-Confidence Detection Opportunities

High-confidence detection requires behavioral convergence. A single suspicious event may be noisy in a developer environment, but multiple linked events create a defensible detection path.

· AI coding assistant starts from a user-facing application, deeplink, or URI-handler context and spawns a shell or scripting interpreter.

· AI coding assistant evaluates settings or hooks immediately before child-process creation.

· Hook or startup automation executes in a repository, workspace, user context, or host where that behavior is not normally observed.

· Suspicious child-process execution is followed by outbound communication or remote retrieval.

· Suspicious child-process execution is followed by credential-store access, SSH material access, environment-file access, package-registry token access, or cloud credential access.

· Suspicious endpoint behavior is followed by unusual repository, CI/CD, package-registry, cloud, or identity-provider activity.

· Security controls block command execution, script execution, network retrieval, or credential access from the Claude Code process tree.

Medium-Confidence Detection Opportunities

Medium-confidence opportunities require enrichment before escalation. These signals may indicate suspicious activity, but they can also occur during normal development work.

· Claude Code starts shortly after a user interacts with an external link, issue, pull request, README, documentation page, or repository reference.

· A deeplink or URI-handler invocation occurs shortly before Claude Code execution.

· Settings, hook files, project-local configuration, or workspace-local configuration are created, modified, accessed, or removed near session start.

· Claude Code starts in a newly cloned, externally sourced, unusual, or previously trusted repository shortly after external interaction.

· Claude Code launches build tools, package managers, Git clients, cloud CLIs, or local development servers outside normal repository or user baseline.

· The endpoint contacts new or unusual destinations after AI coding-assistant execution.

· Vulnerable or outdated Claude Code versions are present on developer systems that also show suspicious invocation or configuration activity.

Low-Confidence Detection Opportunities

Low-confidence opportunities are useful for exposure management, hunting, and enrichment, but they should not be treated as compromise evidence by themselves.

· Vulnerable-version exposure without suspicious execution.

· Isolated deeplink or URI-handler activity without configuration or process evidence.

· Claude Code execution without abnormal parentage, configuration activity, or child-process behavior.

· Shell or package-manager execution from a developer workstation without Claude Code lineage or suspicious timing.

· Network activity from developer tooling without process lineage, suspicious destination context, or post-execution correlation.

· Suspicious strings, payload-like fragments, or proof-of-concept indicators without execution evidence.

· Repository or workspace activity without local execution or identity-risk context.

Detection Gaps

The primary detection gap is visibility across the complete execution chain. This behavior class crosses several control planes: user interaction, local application invocation, developer tooling, configuration evaluation, endpoint execution, network communication, repository access, CI/CD access, and identity usage. Missing telemetry at any layer can reduce confidence or prevent reconstruction of the event.

· Lack of parent-child process lineage can prevent attribution of suspicious shell or scripting activity to Claude Code.

· Lack of command-line capture can hide settings references, interpreter abuse, encoded execution, remote retrieval, and credential-access behavior.

· Lack of file telemetry can obscure settings, hooks, workspace configuration, startup automation, and persistence changes.

· Lack of URI-handler or browser-to-local-application telemetry can make the initial external influence point difficult to prove.

· Lack of process-aware network telemetry can make outbound communication difficult to attribute to the AI coding-assistant process tree.

· Lack of repository, CI/CD, identity, cloud, or package-registry telemetry can cause downstream exposure to be underestimated.

· Lack of developer workstation baselines can increase false positives or cause risky behavior to be suppressed as expected developer activity.

· Lack of telemetry retention can prevent delayed investigation of link interaction, configuration change, execution, and downstream access.

Developer Environment Noise Gaps

Developer workstations are high-noise environments. Normal engineering workflows often include shells, interpreters, package managers, build tools, Git clients, cloud CLIs, local servers, temporary files, repository changes, package downloads, and frequent outbound connections. This makes isolated signal matching unreliable.

· Shell execution is common during normal development.

· Package-manager execution is common during dependency installation and build workflows.

· Git, cloud CLI, and CI/CD interaction may be routine for developers.

· Local development servers and network listeners may be expected.

· Repository-local scripts and hooks may be legitimate in some teams.

· External documentation, issue trackers, pull requests, and README files may legitimately precede development activity.

· Developer workflows vary significantly by role, repository, language, operating system, and workstation class.

The detection opportunity is not to alert on these behaviors individually. The opportunity is to identify when they occur in suspicious sequence after externally influenced AI coding-assistant invocation or configuration evaluation.

Tooling and Platform Coverage Gaps

Coverage varies across endpoint platforms, EDR products, SIEM pipelines, developer-tool configurations, and identity or repository integrations. Detection quality depends on whether the organization can observe local process behavior and connect it to downstream developer activity.

· Some environments may not log local URI-handler invocation.

· Some endpoint tools may not capture full command lines by default.

· Some macOS and Linux developer environments may have weaker file-monitoring coverage than managed Windows endpoints.

· Some EDR tools may record child processes but not enough working-directory, configuration-file, or repository context.

· Some network tools may not provide process attribution.

· Some source-control and CI/CD logs may not retain enough detail to connect workstation events to downstream developer activity.

· Some organizations may not maintain accurate software inventory for Claude Code or comparable AI coding assistants.

· Some organizations may allow unsanctioned AI coding tools, reducing visibility and policy consistency.

Variant and Evasion Gaps

The specific Claude Code deeplink settings-injection flaw can be patched, but the broader behavior class can reappear through other input, configuration, trust, hook, startup, or automation paths. Detection must therefore account for variant behavior and likely attacker adaptation.

· Attackers may avoid known proof-of-concept strings.

· Attackers may trigger execution through configuration, hooks, startup automation, project-local files, or trusted-workspace behavior rather than an obvious deeplink.

· Attackers may delay execution until session start, project open, dependency installation, build, test, or other developer lifecycle events.

· Attackers may use common developer tools to blend into normal activity.

· Attackers may use trusted repositories, previously cloned projects, or familiar documentation paths to reduce suspicion.

· Attackers may stage activity through package managers, Git operations, cloud CLIs, local scripts, or shell profiles.

· Attackers may use legitimate outbound services, temporary infrastructure, or common cloud endpoints to reduce network anomaly visibility.

· Attackers may shift from direct command execution to credential access, token reuse, repository access, or CI/CD abuse.

Operational Gaps

Operational gaps can prevent effective response even when detection telemetry exists. This report’s modeled risk crosses security operations, endpoint engineering, developer experience, identity, source control, CI/CD, and cloud security. If ownership is unclear, investigations may stall or become fragmented.

· SOC teams may not have routine context for normal Claude Code or AI coding-assistant behavior.

· Endpoint teams may not monitor settings, hooks, or workspace-local configuration paths.

· Developer platform teams may not maintain centralized visibility into AI coding-tool usage.

· Identity teams may not correlate developer workstation compromise with token, repository, or CI/CD activity.

· Repository and CI/CD owners may not have rapid containment procedures for potentially compromised developer identities.

· Security teams may not have preapproved steps for disabling tokens, rotating secrets, revoking sessions, or quarantining developer workstations.

· Detection owners may tune out noisy developer activity without understanding downstream repository and CI/CD risk.

· Incident responders may not know whether suspicious local execution exposed source code, secrets, build systems, signing material, or deployment workflows.

Detection Gap Mitigation Priorities

The most important gap mitigations are those that restore visibility needed to correlate AI coding-assistant invocation, configuration evaluation, local execution, and downstream access. These priorities should be addressed before broad production alerting whenever possible.

· Establish reliable endpoint process lineage, command-line capture, working-directory context, user identity, host identity, and timestamp collection.

· Monitor Claude Code and comparable AI coding-assistant child-process creation.

· Add file monitoring for settings, hooks, project-local configuration, workspace-local configuration, and persistence-capable paths.

· Integrate endpoint execution events with network, identity, repository, CI/CD, package-registry, and cloud-control-plane telemetry.

· Build developer workstation baselines by user role, repository, operating system, language ecosystem, and workstation class.

· Maintain accurate inventory of Claude Code and comparable AI coding-assistant installations and versions.

· Extend telemetry retention long enough to reconstruct link interaction, configuration evaluation, command execution, and downstream access.

· Define incident-response ownership for developer workstation compromise involving source code, secrets, CI/CD systems, cloud credentials, signing keys, or privileged deployment workflows.

Detection Coverage Summary

Detection coverage is strongest when endpoint process telemetry, command-line capture, file telemetry, process-aware network telemetry, and identity or repository enrichment are available. In that state, the organization can detect the most important behavior: externally influenced AI coding-assistant activity leading to local execution and downstream developer-workstation exposure.

Detection coverage is moderate when endpoint process telemetry exists but file, URI-handler, identity, repository, or CI/CD context is incomplete. In that state, suspicious execution can still be detected, but the initial influence point and downstream exposure may be harder to prove.

Detection coverage is weak when the organization lacks parent-child process lineage, command-line capture, and file telemetry for developer endpoints. In that state, detection may be limited to downstream anomalies, vulnerable-version exposure, or low-confidence hunting indicators.

‍ ‍

S25 — Ultra-Tuned Detection Engineering Rules

‍ ‍

NDR / Network Behavioral Analytics

‍ ‍

Detection Viability Assessment

‍ ‍

NDR / Network Behavioral Analytics has two rules for this EXP report.

‍ ‍

· NDR / Network Behavioral Analytics is viable for detecting suspicious network behavior after externally influenced AI coding-assistant activity results in local developer-workstation execution.

‍ ‍

· NDR / Network Behavioral Analytics is strongest where network-flow telemetry, firewall telemetry, DNS telemetry, proxy telemetry, process-aware endpoint enrichment, developer workstation asset tagging, approved-destination baselines, repository-access context, CI/CD context, identity telemetry, and cloud or hybrid SIEM enrichment can be correlated.

‍ ‍

· NDR / Network Behavioral Analytics can identify suspicious sequencing between AI coding-assistant execution context, unusual developer-workstation egress, rare or newly observed destinations, command-line retrieval behavior, and expansion toward source-control, CI/CD, artifact, package-registry, secrets-management, administrative, or cloud-control infrastructure.

‍ ‍

· NDR / Network Behavioral Analytics is not a standalone source for confirming successful Claude Code deeplink settings-injection exploitation because local deeplink handling, settings interpretation, hook execution, command-line process ancestry, and workspace-local configuration evaluation may not be directly visible in network telemetry.

‍ ‍

· NDR / Network Behavioral Analytics rules should be correlated with endpoint process telemetry, EDR telemetry, file and configuration telemetry, identity-provider records, source-control logs, CI/CD logs, package-registry logs, cloud-control-plane logs, proxy logs, DNS telemetry, and change-management context before classifying activity as confirmed compromise.

‍ ‍

· Identify outbound communication from developer workstations associated with Claude Code or comparable AI coding-assistant usage.

‍ ‍

· Prioritize outbound communication that occurs shortly after suspicious AI coding-assistant activity, deeplink or URI-handler context, externally delivered link interaction, repository-open activity, settings or hook modification, child-process execution, blocked execution, or endpoint alert context.

‍ ‍

· Prioritize destinations that are rare for the organization, newly observed, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unusual cloud, unknown external, or inconsistent with approved developer workflow baselines.

‍ ‍

· Increase confidence when outbound communication is linked through process-aware telemetry to Claude Code, a shell, scripting interpreter, package manager, network utility, Git client, cloud CLI, build tool, or other child process associated with AI coding-assistant activity.

‍ ‍

· Increase confidence when outbound communication follows settings, hook, project-local configuration, workspace-local configuration, startup automation, trusted-workspace activity, or blocked local execution.

‍ ‍

· Increase confidence when outbound communication is followed by credential-store access, SSH material access, repository access, package-registry activity, CI/CD interaction, cloud-control-plane activity, or identity-provider anomalies.

‍ ‍

· Increase confidence when the same destination, domain, ASN, hosting provider, tunnel provider, or infrastructure cluster is contacted by multiple developer workstations after similar AI coding-assistant, repository, documentation, issue, pull-request, README, or link interaction.

‍ ‍

· Increase confidence when outbound activity includes command-line retrieval, encoded parameters, unusual user agent, abnormal TLS SNI, unusual protocol, high byte count, repeated beacon-like timing, or data transfer inconsistent with normal developer tooling.

‍ ‍

· Reduce severity for approved package registries, source-control providers, CI/CD services, cloud services, documentation platforms, internal build systems, corporate proxies, approved developer SaaS, and sanctioned security tooling when behavior is consistent with the user, host, repository, and time window.

‍ ‍

· Do not classify developer-workstation egress as confirmed exploitation without corroborating endpoint process lineage, file and configuration telemetry, identity telemetry, repository telemetry, CI/CD telemetry, cloud telemetry, or validated data-flow evidence.

‍ ‍

· Do not treat vulnerable-version exposure, destination novelty, AI coding-assistant usage, or Claude Code installation as compromise evidence by itself.

‍ ‍

Required Telemetry

‍ ‍

· Network-flow telemetry.

‍ ‍

· Firewall logs.

‍ ‍

· DNS logs.

‍ ‍

· Proxy logs where available.

‍ ‍

· EDR network telemetry where available.

‍ ‍

· NDR session metadata.

‍ ‍

· Source IP.

‍ ‍

· Source asset identity.

‍ ‍

· Source hostname.

‍ ‍

· Source user identity where available.

‍ ‍

· Destination IP.

‍ ‍

· Destination domain.

‍ ‍

· Destination port.

‍ ‍

· Protocol.

‍ ‍

· Timestamp.

‍ ‍

· Session duration.

‍ ‍

· Byte count.

‍ ‍

· Connection count.

‍ ‍

· Directionality.

‍ ‍

· Destination reputation.

‍ ‍

· Destination category.

‍ ‍

· TLS SNI where available.

‍ ‍

· HTTP host where available.

‍ ‍

· User agent where available.

‍ ‍

· Developer workstation asset inventory.

‍ ‍

· Developer role and host classification.

‍ ‍

· Claude Code or comparable AI coding-assistant software inventory where available.

‍ ‍

· Endpoint enrichment showing AI coding-assistant process activity where available.

‍ ‍

· Process-aware network telemetry where available.

‍ ‍

· Approved developer egress baselines.

‍ ‍

· Approved package-registry, source-control, CI/CD, cloud, documentation, internal-build, proxy, SaaS, and security-tool destinations.

‍ ‍

· GeoIP, ASN, cloud-provider, hosting-provider, VPN-provider, domain-age, and first-seen enrichment.

‍ ‍

· Endpoint process correlation where available.

‍ ‍

· File and configuration telemetry correlation where available.

‍ ‍

· Identity-provider correlation where available.

‍ ‍

· Repository and CI/CD correlation where available.

‍ ‍

· Cloud-control-plane correlation where available.

‍ ‍

· Maintenance-window, testing, incident-response, and change-management context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Build asset groups for developer workstations, privileged developer workstations, release-engineering workstations, security-engineering workstations, infrastructure-engineering workstations, and workstations with Claude Code or comparable AI coding-assistant installations.

‍ ‍

· Validate how the organization identifies Claude Code and comparable AI coding-assistant usage through software inventory, endpoint process telemetry, EDR enrichment, proxy user context, asset tags, or SIEM correlation.

‍ ‍

· Build approved egress baselines for developer workstations, including package registries, source-control providers, CI/CD services, artifact repositories, documentation sites, cloud services, developer SaaS, internal build systems, corporate proxies, and sanctioned security tooling.

‍ ‍

· Add enrichment for destination reputation, destination category, destination first-seen timestamp, domain age, ASN, hosting provider, VPN provider, cloud provider, tunnel provider, sanctioned-service status, user role, host role, and repository sensitivity.

‍ ‍

· Correlate suspicious outbound communication with endpoint events involving Claude Code execution, AI coding-assistant child-process creation, settings or hook activity, script execution, blocked command execution, blocked network retrieval, credential-access behavior, repository-open activity, and file or configuration changes.

‍ ‍

· Use shorter correlation windows for AI coding-assistant execution followed by immediate outbound communication, DNS activity, command-line retrieval, blocked network retrieval, or rare destination contact.

‍ ‍

· Use moderate correlation windows for settings or hook activity followed by outbound communication, credential access, repository activity, or package-registry activity.

‍ ‍

· Use longer correlation windows for delayed staging, trusted-workspace reuse, repeated destination contact, repeated infrastructure reuse, or repeated activity across multiple developer workstations.

‍ ‍

· Tune severity based on destination novelty, destination reputation, destination category, process attribution, user role, host sensitivity, repository sensitivity, workstation privilege level, data volume, protocol, timing, and correlated downstream identity or repository activity.

‍ ‍

· Avoid broad suppression for cloud providers, package registries, content-delivery networks, developer SaaS, tunneling services, or hosting providers without validation because attacker infrastructure and legitimate developer workflows may overlap.

‍ ‍

· Use change-management records, approved testing records, incident-response records, sanctioned security-tool activity, and known developer automation as triage evidence before classifying activity as suspicious or probable compromise.

‍ ‍

· Validate all environment variables, asset groups, approved-destination lists, enrichment fields, identity joins, endpoint joins, and timing windows before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

· The rule is behaviorally anchored to suspicious developer-workstation egress following AI coding-assistant execution context rather than static exploit strings, vulnerable-version exposure, or proof-of-concept payloads.

‍ ‍

· The rule remains useful if the specific Claude Code deeplink settings-injection flaw is patched but related AI-assisted development workflows still produce abnormal local execution followed by outbound communication.

‍ ‍

· The score is supported by the durability of developer workstation identity, destination novelty, destination reputation, egress baseline deviation, timing, process-aware enrichment, and correlation with endpoint, file, identity, repository, CI/CD, or cloud signals.

‍ ‍

· The score is constrained by normal developer egress complexity, legitimate package and repository activity, common cloud-service use, tunneling-service overlap, process-attribution gaps, and the inability of NDR alone to observe local settings interpretation or hook execution.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

· Operational confidence depends on NDR sensor placement, network-flow fidelity, DNS visibility, proxy visibility, developer asset tagging, approved-destination baselines, AI coding-assistant context enrichment, and destination-enrichment quality.

‍ ‍

· Operational confidence is reduced where developer workstations routinely contact broad package registries, cloud platforms, SaaS services, public repositories, content-delivery networks, or ad hoc external infrastructure.

‍ ‍

· Operational confidence is reduced where network telemetry lacks process attribution or where endpoint-to-network correlation is delayed, incomplete, or unavailable.

‍ ‍

· Full-telemetry confidence improves when suspicious egress is enriched with endpoint process lineage, command-line capture, file and configuration telemetry, EDR detections, identity-provider records, source-control logs, CI/CD logs, package-registry logs, cloud-control-plane logs, and change-management context.

‍ ‍

· Even under full telemetry conditions, this rule should support escalation and investigation rather than standalone confirmation of successful Claude Code exploitation or developer-workstation compromise.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious developer-workstation egress after AI coding-assistant execution context, not successful exploitation by itself.

‍ ‍

· Legitimate developer workflows may include outbound traffic to package registries, source-control providers, CI/CD services, documentation platforms, cloud services, SaaS platforms, test infrastructure, and internal build systems.

‍ ‍

· Missing process-aware network telemetry may prevent attribution of outbound communication to Claude Code or a related child process.

‍ ‍

· Missing endpoint telemetry may prevent confirmation that outbound activity followed settings evaluation, hook execution, child-process creation, or suspicious local execution.

‍ ‍

· Destination reputation may be incomplete or misleading for newly created, compromised, shared, or legitimate cloud-hosted infrastructure.

‍ ‍

· Encrypted traffic may limit content visibility and prevent confirmation of command-and-control, retrieval, staging, or exfiltration content.

‍ ‍

· The rule may miss attacks that remain local, use approved services, abuse existing authenticated sessions, or communicate only with common developer infrastructure.

‍ ‍

· Confirmation requires correlation with endpoint process lineage, file and configuration telemetry, identity anomalies, repository activity, CI/CD activity, cloud telemetry, or validated data movement.

‍ ‍

Detection Query Pattern

‍ ‍

NDR behavioral query pattern requiring platform syntax validation, developer workstation asset tagging, AI coding-assistant context validation, approved-egress validation, destination-enrichment validation, endpoint-to-network correlation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

· Identify developer workstations associated with suspicious Claude Code or comparable AI coding-assistant context.

‍ ‍

· Identify new, unusual, elevated, or high-risk network communication from those workstations to source-control systems, CI/CD platforms, artifact repositories, package registries, secrets managers, cloud-control-plane endpoints, build systems, deployment infrastructure, security tooling, administrative interfaces, or internal engineering services.

‍ ‍

· Prioritize access that occurs shortly after suspicious AI coding-assistant execution, child-process creation, settings or hook activity, deeplink or URI-handler context, externally delivered link interaction, repository-open activity, blocked execution, or related SIEM alert context.

‍ ‍

· Increase confidence when the destination system is not normally accessed by the user, host, role, repository, or workstation class.

‍ ‍

· Increase confidence when network activity is followed by unusual authentication, repository enumeration, clone activity, branch access, secret access, CI/CD job access, pipeline trigger, artifact access, package publication, cloud API use, role assumption, or deployment-related behavior.

‍ ‍

· Increase confidence when the workstation accesses multiple sensitive engineering-control systems in a short period.

‍ ‍

· Increase confidence when traffic patterns suggest enumeration, scripted access, automation, data staging, credential use, or token reuse.

‍ ‍

· Increase confidence when the affected developer account has access to production repositories, signing material, deployment workflows, cloud infrastructure, sensitive source code, privileged build systems, or security tooling.

‍ ‍

· Increase confidence when similar expansion behavior appears across multiple developer workstations after shared repository, documentation, issue, pull-request, README, or link interaction.

‍ ‍

· Reduce severity when the communication matches an approved build, deployment, source-control, package, secret-management, cloud, security, or administrative workflow for the specific user, host, repository, role, and time window.

‍ ‍

· Do not classify engineering-control-plane access as confirmed compromise without corroborating endpoint process lineage, identity telemetry, repository telemetry, CI/CD telemetry, cloud telemetry, or validated data-flow evidence.

‍ ‍

· Do not treat access to source-control, CI/CD, package-registry, secrets-management, or cloud destinations as malicious by itself because those systems are routine developer dependencies.

‍ ‍

Required Telemetry

‍ ‍

· Network-flow telemetry.

‍ ‍

· Firewall logs.

‍ ‍

· DNS logs.

‍ ‍

· Proxy logs where available.

‍ ‍

· EDR network telemetry where available.

‍ ‍

· NDR session metadata.

‍ ‍

· Source IP.

‍ ‍

· Source asset identity.

‍ ‍

· Source hostname.

‍ ‍

· Source user identity where available.

‍ ‍

· Destination IP.

‍ ‍

· Destination hostname.

‍ ‍

· Destination domain.

‍ ‍

· Destination port.

‍ ‍

· Protocol.

‍ ‍

· Timestamp.

‍ ‍

· Session duration.

‍ ‍

· Byte count.

‍ ‍

· Connection count.

‍ ‍

· Directionality.

‍ ‍

· TLS SNI where available.

‍ ‍

· HTTP host where available.

‍ ‍

· Developer workstation asset inventory.

‍ ‍

· Privileged developer workstation asset inventory.

‍ ‍

· Sensitive engineering-control destination mapping.

‍ ‍

· Source-control system asset mapping.

‍ ‍

· CI/CD platform asset mapping.

‍ ‍

· Artifact repository asset mapping.

‍ ‍

· Package-registry destination mapping.

‍ ‍

· Secrets-management destination mapping.

‍ ‍

· Cloud-control-plane destination mapping.

‍ ‍

· Build-system and deployment-system destination mapping.

‍ ‍

· Administrative-interface destination mapping.

‍ ‍

· Security-tooling destination mapping.

‍ ‍

· User, host, repository, and role access baselines.

‍ ‍

· Endpoint or SIEM context identifying suspicious Claude Code or comparable AI coding-assistant activity.

‍ ‍

· Identity-provider telemetry where available.

‍ ‍

· Source-control telemetry where available.

‍ ‍

· CI/CD telemetry where available.

‍ ‍

· Package-registry telemetry where available.

‍ ‍

· Secrets-manager telemetry where available.

‍ ‍

· Cloud-control-plane telemetry where available.

‍ ‍

· Change-management, deployment, testing, and incident-response context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Build asset groups for developer workstations, privileged developer workstations, release-engineering workstations, security-engineering workstations, infrastructure-engineering workstations, and AI coding-assistant installed workstations.

‍ ‍

· Build destination groups for source-control systems, CI/CD platforms, artifact repositories, package registries, secrets managers, cloud-control-plane endpoints, build systems, deployment infrastructure, signing infrastructure, administrative interfaces, and security tooling.

‍ ‍

· Establish user-to-repository, user-to-CI/CD, user-to-cloud, host-to-build-system, host-to-source-control, role-to-cloud-access, role-to-secret-access, and workstation-to-engineering-system baselines.

‍ ‍

· Correlate sensitive engineering-system access with endpoint events involving Claude Code execution, suspicious AI coding-assistant process lineage, child-process creation, settings or hook activity, script execution, blocked command execution, credential-access behavior, repository-open activity, and file or configuration changes.

‍ ‍

· Add enrichment for destination sensitivity, repository criticality, CI/CD privilege level, cloud account sensitivity, secrets-management access, package-registry scope, signing-key exposure, user privilege level, host sensitivity, and production deployment access.

‍ ‍

· Use shorter correlation windows for suspicious AI coding-assistant execution followed by immediate access to secrets, CI/CD, source control, or cloud-control-plane endpoints.

‍ ‍

· Use moderate correlation windows for suspicious settings or hook activity followed by repository, package-registry, artifact, or build-system access.

‍ ‍

· Use longer correlation windows for delayed expansion, token reuse, repeated engineering-system contact, or repeated access across multiple high-value systems.

‍ ‍

· Tune severity based on destination sensitivity, user privilege, host sensitivity, repository sensitivity, access novelty, access volume, protocol, timing, authentication context, and correlated downstream activity.

‍ ‍

· Avoid broad suppression for source-control providers, CI/CD platforms, cloud providers, package registries, secrets-management systems, or internal engineering systems because legitimate developer dependency and attacker expansion paths may overlap.

‍ ‍

· Use deployment records, build records, change-management records, approved testing records, approved incident-response records, and known automation context as triage evidence before classifying activity as suspicious or probable compromise.

‍ ‍

· Validate all environment variables, asset groups, sensitive-destination mappings, identity joins, repository joins, CI/CD joins, cloud joins, access baselines, and timing windows before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to downstream engineering-control-plane expansion after suspicious AI coding-assistant activity rather than static exploit indicators or proof-of-concept strings.

‍ ‍

· The rule remains useful if the initial execution vector changes but the activity still produces developer-workstation expansion toward source-control, CI/CD, artifact, secrets, package-registry, cloud-control, build, deployment, administrative, or security infrastructure.

‍ ‍

· The score is supported by the durability of sensitive destination identity, developer workstation identity, access novelty, timing, user role, host sensitivity, repository sensitivity, and correlation with endpoint, identity, repository, CI/CD, cloud, or package-registry signals.

‍ ‍

· The score is constrained by normal developer access to engineering infrastructure, broad SaaS and cloud usage, incomplete destination classification, incomplete access baselines, token reuse ambiguity, and reliance on endpoint or SIEM enrichment for strong confidence.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on developer workstation asset tagging, sensitive engineering destination mapping, access-baseline quality, endpoint-to-network correlation, source-control visibility, CI/CD visibility, cloud visibility, and identity-provider enrichment.

‍ ‍

· Operational confidence is reduced where developers routinely access broad source-control, CI/CD, cloud, package-registry, build, secrets-management, and administrative infrastructure without stable baselines.

‍ ‍

· Operational confidence is reduced where SaaS destinations, cloud endpoints, or internal engineering systems are too broadly categorized to distinguish routine work from expansion behavior.

‍ ‍

· Full-telemetry confidence improves when NDR events are enriched with endpoint process lineage, command-line capture, file and configuration telemetry, EDR detections, identity-provider events, source-control logs, CI/CD logs, package-registry logs, secrets-manager logs, cloud-control-plane logs, and change-management context.

‍ ‍

· Under full telemetry conditions, this rule provides strong escalation evidence for developer-workstation compromise impact assessment, but confirmed compromise still requires corroborating endpoint, identity, repository, CI/CD, cloud, or data-flow evidence.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious expansion from a developer workstation toward sensitive engineering-control infrastructure, not successful exploitation by itself.

‍ ‍

· Legitimate developer workflows often involve source-control systems, CI/CD platforms, artifact repositories, package registries, cloud services, build systems, deployment tools, secrets managers, and administrative interfaces.

‍ ‍

· The rule requires accurate developer workstation asset tagging and sensitive engineering destination mapping to remain reliable.

‍ ‍

· Missing endpoint or SIEM enrichment may prevent confirmation that engineering-system access followed suspicious AI coding-assistant execution.

‍ ‍

· Missing identity, repository, CI/CD, package-registry, secrets-manager, or cloud telemetry may reduce confidence in downstream exposure assessment.

‍ ‍

· Existing authenticated sessions, token reuse, and approved automation may make suspicious access appear routine without strong baselines.

‍ ‍

· The rule may miss attacks that remain local, use already common systems, avoid sensitive destinations, or operate entirely through approved workflows.

‍ ‍

· Confirmation requires correlation with endpoint process lineage, identity anomalies, repository activity, CI/CD activity, package-registry activity, cloud-control-plane activity, secrets access, or validated data movement.

‍ ‍

Detection Query Pattern

‍ ‍

NDR behavioral expansion query pattern requiring platform syntax validation, developer workstation asset tagging, sensitive engineering destination mapping, AI coding-assistant context validation, access-baseline validation, endpoint-to-network correlation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

NetworkEvent AS ExpansionEvent
WHERE ExpansionEvent.SourceAsset IN ASSET_GROUP(
"Developer Workstations",
"Privileged Developer Workstations",
"Release Engineering Workstations",
"Security Engineering Workstations",
"Infrastructure Engineering Workstations",
"AI Coding Assistant Installed Workstations"
)
AND ExpansionEvent.Direction IN ANY (
"Outbound",
"Internal"
)
AND ExpansionEvent.DestinationAsset IN ASSET_GROUP(
"Source Control Systems",
"CI CD Platforms",
"Artifact Repositories",
"Package Registries",
"Secrets Managers",
"Cloud Control Plane Endpoints",
"Build Systems",
"Deployment Systems",
"Signing Infrastructure",
"Administrative Interfaces",
"Security Tooling",
"Internal Engineering Services"
)
AND (
ExpansionEvent.AccessPattern IN ANY (
    "new_for_user",
    "new_for_host",
    "rare_for_user",
    "rare_for_host",
    "elevated_for_role",
    "unusual_time_window",
    "unusual_connection_volume",
    "unusual_destination_sequence"
)
OR ExpansionEvent.ConnectionCount >= ENV_ENGINEERING_SYSTEM_ACCESS_VOLUME_THRESHOLD
OR ExpansionEvent.ByteCount >= ENV_ENGINEERING_SYSTEM_DATA_VOLUME_THRESHOLD
OR ExpansionEvent.DestinationSensitivity IN ANY (
    "production",
    "privileged",
    "high_value_repository",
    "secrets",
    "deployment",
    "signing",
    "security_control"
)
)
AND EVENT_NEAR WITHIN ENV_AI_CODING_ASSISTANT_EXPANSION_WINDOW (
EndpointEvent.EventType IN ANY (
    "AI Coding Assistant Process Started",
    "Claude Code Process Started",
    "AI Coding Assistant Child Process Created",
    "Shell Spawned By AI Coding Assistant",
    "Script Interpreter Spawned By AI Coding Assistant",
    "Network Utility Spawned By AI Coding Assistant",
    "Credential Utility Spawned By AI Coding Assistant",
    "Suspicious AI Coding Assistant Process Lineage",
    "Blocked Command Execution From AI Coding Assistant",
    "Credential Access Behavior From AI Coding Assistant Process Tree"
)
OR FileEvent.EventType IN ANY (
    "Claude Code Settings Modified",
    "AI Coding Assistant Settings Modified",
    "Hook Configuration Modified",
    "Project Local Configuration Modified",
    "Workspace Local Configuration Modified",
    "Startup Automation Modified"
)
OR InteractionEvent.EventType IN ANY (
    "Deeplink Invoked",
    "URI Handler Invoked",
    "External Link Interaction",
    "Repository Reference Opened",
    "Documentation Link Opened"
)
)
AND EVENT_NEAR WITHIN ENV_ENGINEERING_CONTROL_CORRELATION_WINDOW (
IdentityEvent.EventType IN ANY (
    "Unfamiliar Session Created",
    "New Device Context",
    "Token Refresh Anomaly",
    "Suspicious Conditional Access Result",
    "Privileged Session Created"
)
OR RepositoryEvent.EventType IN ANY (
    "Unusual Repository Access",
    "Repository Enumeration",
    "Sensitive Repository Clone",
    "Deploy Key Used",
    "SSH Key Used",
    "Token Used",
    "Secret Accessed"
)
OR CICDEvent.EventType IN ANY (
    "Pipeline Triggered",
    "Workflow Accessed",
    "Runner Interaction",
    "Build Secret Accessed",
    "Deployment Job Accessed",
    "Artifact Accessed"
)
OR CloudEvent.EventType IN ANY (
    "Role Assumed",
    "Secret Read",
    "Access Key Created",
    "Privileged API Invoked",
    "Cloud Token Used"
)
)
AND NOT ChangeContext IN ANY (
"approved_build_or_release_activity",
"approved_deployment_activity",
"approved_security_testing",
"approved_incident_response_activity",
"approved_developer_workflow",
"approved_ci_cd_automation",
"approved_cloud_administration"
)

‍ ‍

SentinelOne

‍ ‍

Detection Viability Assessment

‍ ‍

SentinelOne has three rules for this EXP report.

‍ ‍

· SentinelOne is strongly viable as a primary detection-rule system for this report because the core detection problem occurs on the developer workstation and depends on endpoint process lineage, child-process execution, file and configuration activity, script behavior, credential-access behavior, and post-execution endpoint activity.

‍ ‍

· SentinelOne is strongest where process creation telemetry, command-line telemetry, parent-child process lineage, file telemetry, EDR behavioral detections, network telemetry, user identity, host identity, working-directory context, and developer workstation asset tagging can be correlated.

‍ ‍

· SentinelOne can identify suspicious sequencing between Claude Code or comparable AI coding-assistant execution, abnormal launch context, settings or hook activity, shell or interpreter child-process creation, command-line retrieval, credential access, persistence behavior, and outbound activity.

‍ ‍

· SentinelOne is suitable for detecting behavior associated with the modeled Claude Code source case because the local execution chain depends on endpoint-observable events rather than only network, cloud, or static-file indicators.

‍ ‍

· SentinelOne rules should remain behavior-led and should not depend on public proof-of-concept payloads, exploit strings, deeplink fragments, vulnerable-version exposure alone, or Claude Code installation alone.

‍ ‍

· SentinelOne detection content should be treated as primary endpoint coverage for suspicious AI coding-assistant execution behavior, with SIEM, identity, repository, CI/CD, cloud, and NDR enrichment used to determine downstream exposure and business impact.

‍ ‍

Rule

‍ ‍

AI Coding Assistant Spawning Shell, Script, Network, Credential, or Package-Management Utilities

‍ ‍

Rule Format

‍ ‍

SentinelOne Deep Visibility behavioral rule suitable for endpoint process creation, command-line, parent-child process lineage, file, network, identity, and EDR-behavior correlation after developer workstation tagging, Claude Code executable validation, AI coding-assistant process mapping, child-process baseline validation, operating-system normalization, and environment-specific tuning.

‍ ‍

Detection Purpose

‍ ‍

Detect Claude Code or comparable AI coding assistants spawning execution-capable child processes outside expected developer baselines.

‍ ‍

· Identify suspicious local command execution that may follow deeplink handling, settings interpretation, hook execution, startup automation, externally delivered link interaction, or trusted-workspace reuse.

‍ ‍

· Prioritize child processes involving shells, scripting interpreters, network retrieval utilities, credential utilities, package managers, Git clients, cloud CLIs, local servers, build tools, or persistence-capable commands.

‍ ‍

· Support detection of the behavior class without relying on proof-of-concept syntax, static payload strings, vulnerable-version exposure alone, or direct inspection of deeplink content.

‍ ‍

· This rule does not prove successful exploitation by itself; confirmation requires correlation with launch context, settings or hook activity, command behavior, file activity, network activity, credential access, or downstream repository, CI/CD, identity, or cloud evidence.

‍ ‍

Detection Logic

‍ ‍

Identify Claude Code or comparable AI coding-assistant processes on developer workstations.

‍ ‍

· Detect child-process creation from Claude Code or comparable AI coding-assistant parent processes.

‍ ‍

· Prioritize child processes involving shell interpreters, scripting engines, package managers, network utilities, credential utilities, Git clients, cloud CLIs, build tools, local servers, persistence utilities, or administrative utilities.

‍ ‍

· Increase confidence when child-process execution occurs shortly after deeplink invocation, URI-handler activity, external link interaction, repository-open activity, documentation-link interaction, issue or pull-request interaction, README interaction, or other externally influenced workflow.

‍ ‍

· Increase confidence when child-process execution occurs near settings, hooks, project-local configuration, workspace-local configuration, startup automation, or trusted-workspace activity.

‍ ‍

· Increase confidence when command-line arguments show encoded content, inline execution, remote retrieval, environment-variable access, credential-store access, SSH material access, token access, package installation, file-permission modification, or system modification.

‍ ‍

· Increase confidence when the child process initiates outbound network communication to a rare, newly observed, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unusual cloud, or previously unseen destination.

‍ ‍

· Increase confidence when the child process accesses credential material, repository secrets, package-registry tokens, cloud credential files, environment files, SSH keys, signing material, CI/CD configuration, or sensitive developer tooling paths.

‍ ‍

· Increase confidence when similar process behavior appears across multiple developer workstations after shared repository, documentation, issue, pull-request, README, or link interaction.

‍ ‍

· Reduce severity for known approved developer automation, sanctioned hooks, approved build scripts, expected package-manager workflows, documented repository automation, approved security testing, and known incident-response activity.

‍ ‍

· Do not classify child-process execution as confirmed compromise without corroborating suspicious launch context, configuration activity, credential access, network activity, blocked control events, or downstream identity, repository, CI/CD, or cloud activity.

‍ ‍

· Do not broadly suppress AI coding-assistant child-process activity because normal developer execution and attacker execution may share the same toolchain.

‍ ‍

Required Telemetry

‍ ‍

SentinelOne endpoint process telemetry.

‍ ‍

· Deep Visibility process creation events.

‍ ‍

· Parent process name.

‍ ‍

· Parent process path.

‍ ‍

· Child process name.

‍ ‍

· Child process path.

‍ ‍

· Full command line.

‍ ‍

· Process hash.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· Process start time.

‍ ‍

· Process termination time where available.

‍ ‍

· Process tree or causal process lineage.

‍ ‍

· File telemetry where available.

‍ ‍

· Network telemetry where available.

‍ ‍

· EDR behavioral detections.

‍ ‍

· Script execution telemetry where available.

‍ ‍

· Cloud CLI, Git client, package-manager, shell, and interpreter process visibility.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Claude Code or comparable AI coding-assistant executable mapping.

‍ ‍

· Known-good developer automation allowlist.

‍ ‍

· Repository, user-role, host-role, and workstation-class context where available.

‍ ‍

· Identity, repository, CI/CD, package-registry, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Build process identity mappings for Claude Code and comparable AI coding-assistant executables across Windows, macOS, and Linux developer workstations.

‍ ‍

· Build developer workstation asset groups, privileged developer workstation groups, release-engineering workstation groups, security-engineering workstation groups, infrastructure-engineering workstation groups, and AI coding-assistant installed workstation groups.

‍ ‍

· Build child-process baselines for normal Claude Code and AI coding-assistant behavior by operating system, user role, repository type, language ecosystem, host class, and workstation class.

‍ ‍

· Treat shells, scripting engines, package managers, network utilities, credential utilities, Git clients, cloud CLIs, build tools, local servers, and persistence-capable utilities as high-value child-process categories when spawned by AI coding assistants.

‍ ‍

· Correlate suspicious child-process creation with settings, hook, project-local configuration, workspace-local configuration, startup automation, repository-open activity, deeplink or URI-handler context, and external link interaction where available.

‍ ‍

· Use shorter correlation windows for AI coding-assistant launch followed by immediate shell, interpreter, network utility, credential utility, or package-manager execution.

‍ ‍

· Use moderate correlation windows for settings or hook activity followed by child-process creation, outbound communication, credential access, or blocked execution.

‍ ‍

· Use longer correlation windows for delayed hook execution, trusted-workspace reuse, repeated child-process execution, or similar activity across multiple developer workstations.

‍ ‍

· Tune severity based on child-process category, command-line risk, process lineage, working directory, user role, host sensitivity, repository sensitivity, network activity, credential access, and downstream identity or repository activity.

‍ ‍

· Avoid broad allowlisting for shells, interpreters, package managers, Git clients, cloud CLIs, or build tools because these tools are both legitimate developer dependencies and common attacker execution paths.

‍ ‍

· Use approved automation records, build records, repository ownership, testing records, incident-response records, and change-management records as triage evidence before suppressing or downgrading alerts.

‍ ‍

· Validate SentinelOne field availability, process naming, operating-system normalization, command-line capture, causal process lineage, and endpoint-to-SIEM joins before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

9.0 / 10

‍ ‍

· The rule is behaviorally anchored to AI coding-assistant child-process creation, which is a durable detection point for this report’s execution model.

‍ ‍

· The rule remains useful if the specific Claude Code deeplink settings-injection path changes but the attacker still causes an AI coding assistant to launch execution-capable utilities.

‍ ‍

· The score is supported by endpoint process lineage, command-line visibility, child-process category, working-directory context, file activity, network activity, credential-access behavior, and EDR behavioral detections.

‍ ‍

· The score is constrained by legitimate developer automation, expected build activity, approved hooks, package-manager workflows, command-line capture gaps, and environment-specific AI coding-assistant usage patterns.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

8.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.5 / 10

‍ ‍

· Operational confidence depends on SentinelOne endpoint coverage, process lineage fidelity, command-line capture, developer workstation tagging, Claude Code process mapping, and child-process baseline quality.

‍ ‍

· Operational confidence is reduced where developers routinely use AI coding assistants to invoke shells, package managers, build tools, local servers, Git clients, or cloud CLIs as part of sanctioned workflows.

‍ ‍

· Operational confidence is reduced where command-line capture is incomplete or where approved automation is not well documented.

‍ ‍

· Full-telemetry confidence improves when child-process activity is correlated with settings or hook changes, file telemetry, network telemetry, credential-access behavior, blocked control events, identity-provider records, repository activity, CI/CD activity, cloud activity, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of suspicious local execution but should still be correlated before classifying activity as confirmed exploitation.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious AI coding-assistant child-process behavior, not successful Claude Code exploitation by itself.

‍ ‍

· AI coding assistants may legitimately spawn shells, interpreters, package managers, build tools, Git clients, local servers, and cloud CLIs during normal development.

‍ ‍

· The rule requires tuning by operating system, user role, repository, language ecosystem, and workstation class.

‍ ‍

· Missing command-line capture may reduce confidence in command-risk assessment.

‍ ‍

· Missing file or network telemetry may reduce confidence in whether execution followed settings or hook activity.

‍ ‍

· The rule may miss attacks that avoid obvious child processes, use approved automation, abuse already running processes, or operate through common developer tools.

‍ ‍

· Confirmation requires correlation with launch context, configuration activity, credential access, network behavior, repository activity, CI/CD activity, cloud activity, or other endpoint evidence.

‍ ‍

· Prioritize configuration activity involving command-capable automation, startup hooks, shell invocation, interpreter invocation, network retrieval, credential access, or persistence-capable behavior.

‍ ‍

· Support detection of trusted-workspace reuse and externally influenced configuration paths without relying on a single deeplink payload or proof-of-concept string.

‍ ‍

· This rule does not prove exploitation by itself; confirmation requires correlation with child-process creation, command-line behavior, blocked execution, network activity, credential access, or downstream repository, CI/CD, identity, or cloud activity.

‍ ‍

Detection Logic

‍ ‍

Identify creation, modification, access, deletion, or rollback activity involving Claude Code settings, AI coding-assistant settings, hook files, project-local configuration, workspace-local configuration, startup automation, or trusted-workspace artifacts.

‍ ‍

· Prioritize file and configuration activity that occurs shortly before or during Claude Code or comparable AI coding-assistant session start.

‍ ‍

· Prioritize configuration content or path activity associated with shell execution, script execution, network retrieval, package-manager invocation, credential access, environment-variable access, startup automation, or persistence-capable behavior.

‍ ‍

· Increase confidence when configuration activity is followed by child-process creation from Claude Code or comparable AI coding assistants.

‍ ‍

· Increase confidence when configuration activity occurs in a newly cloned, externally sourced, unusual, or previously trusted repository shortly after external link interaction, repository-reference interaction, documentation interaction, issue interaction, pull-request interaction, or README interaction.

‍ ‍

· Increase confidence when the child process launched after configuration activity performs encoded execution, inline execution, remote retrieval, credential-store access, SSH material access, environment-file access, package-registry token access, or cloud credential access.

‍ ‍

· Increase confidence when configuration activity is followed by outbound communication, blocked command execution, blocked script execution, blocked network retrieval, or EDR behavioral detection.

‍ ‍

· Increase confidence when similar settings or hook activity appears across multiple developer workstations, repositories, or users.

‍ ‍

· Reduce severity for known approved hooks, approved project automation, documented repository bootstrap scripts, expected build scripts, approved security testing, incident-response activity, and sanctioned developer workflows.

‍ ‍

· Do not treat settings or hook changes as compromise evidence by themselves.

‍ ‍

· Do not use static proof-of-concept strings as the primary detection condition.

‍ ‍

Required Telemetry

‍ ‍

SentinelOne file telemetry.

‍ ‍

· SentinelOne process telemetry.

‍ ‍

· Deep Visibility file creation events.

‍ ‍

· Deep Visibility file modification events.

‍ ‍

· Deep Visibility file deletion events where available.

‍ ‍

· Parent-child process lineage.

‍ ‍

· Full command-line capture.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· File path.

‍ ‍

· File name.

‍ ‍

· File hash where available.

‍ ‍

· File operation type.

‍ ‍

· Repository or workspace path context where available.

‍ ‍

· Claude Code settings-path mapping.

‍ ‍

· Claude Code hook-path mapping.

‍ ‍

· AI coding-assistant configuration-path mapping.

‍ ‍

· Project-local configuration-path mapping.

‍ ‍

· Workspace-local configuration-path mapping.

‍ ‍

· Startup automation and persistence-path mapping.

‍ ‍

· EDR behavioral detections.

‍ ‍

· Network telemetry where available.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Approved hook and automation inventory where available.

‍ ‍

· Identity, repository, CI/CD, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Identify Claude Code settings locations, hook locations, project-local configuration locations, workspace-local configuration locations, and trusted-workspace artifacts across Windows, macOS, and Linux environments.

‍ ‍

· Build file path groups for AI coding-assistant settings, hooks, workspace configuration, project-local configuration, startup automation, and persistence-capable paths.

‍ ‍

· Build approved automation inventories for sanctioned hooks, repository bootstrap scripts, build scripts, local developer tooling, security automation, and incident-response tooling.

‍ ‍

· Correlate configuration file activity with Claude Code or comparable AI coding-assistant process start, session start, child-process creation, command execution, network communication, blocked execution, and credential-access behavior.

‍ ‍

· Use shorter correlation windows for settings or hook modification followed by immediate child-process creation or blocked execution.

‍ ‍

· Use moderate correlation windows for repository-open activity followed by configuration evaluation and command execution.

‍ ‍

· Use longer correlation windows for delayed hook execution, trusted-workspace reuse, repository switching, or repeated configuration activity across multiple developer workstations.

‍ ‍

· Tune severity based on file path sensitivity, operation type, command-capable content, child-process category, user role, repository sensitivity, host sensitivity, and downstream network or credential behavior.

‍ ‍

· Avoid broad suppression for repository-local configuration because attacker-controlled and legitimate project automation may use similar paths.

‍ ‍

· Use repository ownership, approved automation documentation, change-management records, testing records, and incident-response records as triage evidence before suppressing alerts.

‍ ‍

· Validate field availability, file path normalization, operating-system path differences, approved automation lists, and endpoint-to-SIEM joins before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to settings, hook, and workspace-configuration activity followed by AI coding-assistant execution.

‍ ‍

· The rule remains useful if the specific deeplink settings-injection flaw changes but attackers continue to abuse configuration, hooks, startup automation, or trusted-workspace behavior.

‍ ‍

· The score is supported by file activity, process lineage, command-line telemetry, child-process execution, working-directory context, EDR behavioral detections, and correlation with network or credential activity.

‍ ‍

· The score is constrained by legitimate project automation, approved hooks, repository bootstrap scripts, build tooling, file-path variation across platforms, and incomplete approved-automation inventories.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on accurate settings-path mapping, hook-path mapping, file telemetry coverage, process lineage fidelity, command-line capture, developer workstation tagging, and approved automation baselines.

‍ ‍

· Operational confidence is reduced where repositories routinely use hooks, bootstrap scripts, local automation, or workspace-specific configuration without centralized documentation.

‍ ‍

· Operational confidence is reduced where file telemetry does not capture enough path, operation, user, working-directory, or repository context.

‍ ‍

· Full-telemetry confidence improves when configuration activity is correlated with child-process execution, command-line content, network telemetry, blocked control events, credential-access behavior, identity-provider telemetry, repository activity, CI/CD activity, cloud telemetry, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of configuration-triggered execution risk, but confirmed compromise still requires execution and impact corroboration.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious configuration and hook activity followed by execution, not successful exploitation by itself.

‍ ‍

· Legitimate repositories may use settings, hooks, bootstrap scripts, package scripts, local configuration, and startup automation.

‍ ‍

· File path variation across operating systems and developer-tool versions may affect coverage.

‍ ‍

· Missing file telemetry may prevent visibility into settings or hook changes.

‍ ‍

· Missing command-line capture may reduce confidence in whether the resulting execution was suspicious.

‍ ‍

· Approved automation inventories may be incomplete or stale.

‍ ‍

· The rule may miss attacks that do not modify files, operate through pre-existing trusted configuration, or abuse already approved automation.

‍ ‍

· Confirmation requires correlation with child-process execution, command behavior, blocked controls, network activity, credential access, identity anomalies, repository activity, CI/CD activity, or cloud telemetry.

‍ ‍

· Prioritize behavior involving credential stores, SSH material, cloud credential files, environment files, package-registry tokens, repository secrets, shell profiles, launch agents, scheduled tasks, services, cron jobs, network retrieval, or suspicious outbound communication.

‍ ‍

· Support escalation from suspicious local execution to higher-confidence developer-workstation compromise assessment.

‍ ‍

· This rule does not prove exploitation by itself; confirmation requires correlation with initial AI coding-assistant execution context, command behavior, credential activity, persistence activity, network activity, identity events, repository access, CI/CD activity, or cloud activity.

‍ ‍

Detection Logic

‍ ‍

Identify Claude Code or comparable AI coding-assistant process trees on developer workstations.

‍ ‍

· Detect credential-access, persistence, outbound communication, staging, discovery, or lateral-movement behavior under the AI coding-assistant process tree or shortly after it.

‍ ‍

· Prioritize access to SSH keys, cloud credential files, environment files, package-registry tokens, repository secrets, signing material, local credential stores, CI/CD configuration, or secrets-management configuration.

‍ ‍

· Prioritize creation or modification of shell profiles, login items, launch agents, scheduled tasks, cron jobs, services, startup folders, persistence-capable scripts, hidden files, staging directories, or downloaded tools.

‍ ‍

· Prioritize outbound communication to rare, newly observed, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unusual cloud, or previously unseen destinations.

‍ ‍

· Increase confidence when the behavior follows suspicious AI coding-assistant child-process execution, settings or hook activity, deeplink or URI-handler context, externally delivered link interaction, repository-open activity, or blocked execution.

‍ ‍

· Increase confidence when behavior occurs from a developer workstation with access to sensitive repositories, CI/CD systems, package registries, signing keys, cloud credentials, secrets, production infrastructure, or security tooling.

‍ ‍

· Increase confidence when identity, repository, CI/CD, package-registry, cloud, or NDR telemetry shows unusual downstream activity after the endpoint event.

‍ ‍

· Reduce severity for approved developer tooling, documented build scripts, sanctioned credential helpers, approved cloud workflows, approved security testing, approved incident-response activity, and known endpoint-management activity.

‍ ‍

· Do not classify credential, persistence, or outbound behavior as confirmed Claude Code exploitation without corroborating AI coding-assistant execution context.

‍ ‍

· Do not suppress credential or persistence behavior broadly because developer environments may contain both legitimate automation and high-value attacker targets.

‍ ‍

Required Telemetry

‍ ‍

SentinelOne endpoint process telemetry.

‍ ‍

· Deep Visibility process tree telemetry.

‍ ‍

· Parent-child process lineage.

‍ ‍

· Full command-line capture.

‍ ‍

· File telemetry.

‍ ‍

· Credential-access behavior telemetry.

‍ ‍

· Persistence behavior telemetry.

‍ ‍

· Network telemetry.

‍ ‍

· EDR behavioral detections.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· Process hash.

‍ ‍

· File path.

‍ ‍

· File operation type.

‍ ‍

· Destination domain.

‍ ‍

· Destination IP.

‍ ‍

· Destination reputation.

‍ ‍

· Destination category.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Credential-path mapping.

‍ ‍

· Persistence-path mapping.

‍ ‍

· SSH key path mapping.

‍ ‍

· Cloud credential path mapping.

‍ ‍

· Environment-file path mapping.

‍ ‍

· Package-registry token path mapping.

‍ ‍

· Repository secret path mapping.

‍ ‍

· CI/CD configuration path mapping.

‍ ‍

· Approved automation and credential-helper inventory.

‍ ‍

· Identity, repository, CI/CD, package-registry, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Build process tree mappings for Claude Code and comparable AI coding-assistant processes across Windows, macOS, and Linux developer workstations.

‍ ‍

· Build monitored path groups for credential stores, SSH material, cloud credentials, environment files, package-registry tokens, repository secrets, signing material, CI/CD configuration, and secrets-management configuration.

‍ ‍

· Build monitored path groups for shell profiles, launch agents, login items, scheduled tasks, cron jobs, services, startup folders, persistence-capable scripts, temporary directories, hidden files, downloaded tools, and staging directories.

‍ ‍

· Correlate AI coding-assistant process trees with credential access, persistence activity, outbound communication, staging, discovery, blocked controls, and EDR behavioral detections.

‍ ‍

· Use shorter correlation windows for AI coding-assistant execution followed by credential access, persistence creation, outbound communication, or blocked control activity.

‍ ‍

· Use moderate correlation windows for settings or hook activity followed by credential access, file staging, network retrieval, or identity activity.

‍ ‍

· Use longer correlation windows for delayed persistence, token reuse, repository access, CI/CD activity, cloud access, or repeated endpoint behavior.

‍ ‍

· Tune severity based on credential type, file path sensitivity, persistence mechanism, destination reputation, user role, host sensitivity, repository sensitivity, workstation privilege level, and downstream identity or repository activity.

‍ ‍

· Avoid broad suppression for credential helpers, package managers, cloud CLIs, endpoint-management tools, or developer automation because attacker activity may use the same tools.

‍ ‍

· Use approved credential-helper inventories, repository automation records, cloud workflow records, testing records, incident-response records, and endpoint-management records as triage evidence before suppressing alerts.

‍ ‍

· Validate SentinelOne visibility for credential behavior, persistence paths, process tree lineage, network events, operating-system path differences, and endpoint-to-SIEM joins before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

9.0 / 10

‍ ‍

· The rule is behaviorally anchored to post-execution credential, persistence, and outbound behavior after AI coding-assistant process activity.

‍ ‍

· The rule remains useful if the initial trigger changes but the attacker still uses the developer workstation to access credentials, establish persistence, stage files, or communicate outbound.

‍ ‍

· The score is supported by process tree lineage, credential path access, persistence path modification, outbound network behavior, EDR behavioral detections, working-directory context, and downstream identity or repository enrichment.

‍ ‍

· The score is constrained by legitimate developer credential helpers, cloud CLIs, package managers, build scripts, endpoint-management tooling, and security tools that may access similar resources.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

8.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.5 / 10

‍ ‍

· Operational confidence depends on process tree fidelity, credential-path mapping, persistence-path mapping, file telemetry, network telemetry, developer asset tagging, and approved automation baselines.

‍ ‍

· Operational confidence is reduced where developer environments routinely access cloud credentials, SSH keys, package tokens, environment files, build secrets, or local credential stores through approved tooling.

‍ ‍

· Operational confidence is reduced where persistence or credential behavior is generated by endpoint-management, security tooling, backup tools, or sanctioned developer automation.

‍ ‍

· Full-telemetry confidence improves when endpoint behavior is correlated with settings or hook activity, child-process execution, blocked control events, identity-provider records, repository logs, CI/CD logs, package-registry logs, cloud-control-plane logs, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong escalation evidence for developer-workstation compromise assessment, especially when credential access or persistence follows suspicious AI coding-assistant execution.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious post-execution behavior after AI coding-assistant process activity, not successful exploitation by itself.

‍ ‍

· Developer tools may legitimately access credentials, environment files, SSH keys, package tokens, cloud credentials, or CI/CD configuration.

‍ ‍

· Endpoint-management, backup, security, and administrative tools may legitimately modify persistence-capable paths.

‍ ‍

· The rule requires accurate process tree lineage and path mapping to avoid noisy results.

‍ ‍

· Missing file, network, or credential behavior telemetry may reduce confidence.

‍ ‍

· The rule may miss attacks that avoid credential files, avoid persistence, use memory-only access, use existing sessions, or remain within approved developer workflows.

‍ ‍

· Confirmation requires correlation with suspicious AI coding-assistant context, command behavior, settings or hook activity, network activity, identity anomalies, repository activity, CI/CD activity, cloud telemetry, or forensic evidence.

‍ ‍

· Splunk is strongly viable as a primary detection-rule system for this report because the core behavior can be correlated across endpoint process telemetry, command-line telemetry, file and configuration telemetry, network telemetry, identity-provider logs, source-control logs, CI/CD logs, package-registry logs, cloud-control-plane logs, and EDR detections.

‍ ‍

· Splunk is strongest where endpoint process lineage, full command-line capture, file activity, developer workstation asset tagging, user identity, working-directory context, network telemetry, repository activity, CI/CD activity, package-registry activity, and cloud activity are normalized into consistent fields.

‍ ‍

· Splunk can identify suspicious sequencing between user-facing application activity, deeplink or URI-handler invocation, Claude Code or comparable AI coding-assistant execution, settings or hook activity, child-process creation, outbound communication, credential access, repository access, CI/CD interaction, and cloud or identity activity.

‍ ‍

· Splunk is suitable for this behavior model because the strongest detection path depends on multi-source correlation rather than a single endpoint signal, static artifact, exploit string, or vulnerable-version match.

‍ ‍

· Splunk rules should remain behavior-led and should not depend on public proof-of-concept payloads, deeplink fragments, exploit labels, vulnerable-version exposure alone, or Claude Code installation alone.

‍ ‍

Identify Claude Code or comparable AI coding-assistant execution on developer workstations.

‍ ‍

· Identify cases where the parent process, launch context, or preceding user interaction suggests browser, chat, email, documentation, collaboration-tool, deeplink, URI-handler, repository-reference, issue, pull-request, README, or externally influenced workflow activity.

‍ ‍

· Detect child-process creation from Claude Code or comparable AI coding-assistant processes.

‍ ‍

· Prioritize child processes involving shell interpreters, scripting engines, package managers, network utilities, credential utilities, Git clients, cloud CLIs, build tools, local servers, persistence utilities, or administrative utilities.

‍ ‍

· Increase confidence when child-process execution occurs shortly after deeplink invocation, URI-handler activity, external link interaction, repository-open activity, documentation-link interaction, issue or pull-request interaction, README interaction, or unusual workspace activity.

‍ ‍

· Increase confidence when child-process execution occurs near settings, hooks, project-local configuration, workspace-local configuration, startup automation, or trusted-workspace activity.

‍ ‍

· Increase confidence when command-line arguments show encoded content, inline execution, remote retrieval, environment-variable access, credential-store access, SSH material access, token access, package installation, file-permission modification, or system modification.

‍ ‍

· Increase confidence when the child process initiates outbound network communication to a rare, newly observed, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unusual cloud, or previously unseen destination.

‍ ‍

· Increase confidence when the child process accesses credential material, repository secrets, package-registry tokens, cloud credential files, environment files, SSH keys, signing material, CI/CD configuration, or sensitive developer tooling paths.

‍ ‍

· Increase confidence when similar behavior appears across multiple developer workstations after shared repository, documentation, issue, pull-request, README, or link interaction.

‍ ‍

· Reduce severity for documented build workflows, approved repository automation, sanctioned hooks, expected package-manager activity, approved security testing, approved incident-response activity, and known developer automation.

‍ ‍

· Do not classify child-process execution as confirmed compromise without corroborating suspicious launch context, settings or hook activity, credential access, network activity, blocked control events, repository activity, CI/CD activity, identity events, or cloud activity.

‍ ‍

· Do not broadly suppress AI coding-assistant child-process activity because normal developer execution and attacker execution may use the same tools.

‍ ‍

Required Telemetry

‍ ‍

Endpoint process telemetry.

‍ ‍

· EDR telemetry.

‍ ‍

· Parent process name.

‍ ‍

· Parent process path.

‍ ‍

· Child process name.

‍ ‍

· Child process path.

‍ ‍

· Full command line.

‍ ‍

· Process hash.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· Process start time.

‍ ‍

· Process termination time where available.

‍ ‍

· Process tree or causal process lineage.

‍ ‍

· File telemetry where available.

‍ ‍

· Network telemetry where available.

‍ ‍

· Web, browser, proxy, email, chat, documentation, or collaboration-platform telemetry where available.

‍ ‍

· Deeplink or URI-handler telemetry where available.

‍ ‍

· Script execution telemetry where available.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Claude Code or comparable AI coding-assistant executable mapping.

‍ ‍

· Known-good developer automation allowlist.

‍ ‍

· Repository, user-role, host-role, and workstation-class context where available.

‍ ‍

· Identity, repository, CI/CD, package-registry, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Normalize process telemetry across Windows, macOS, and Linux developer workstations.

‍ ‍

· Build process identity mappings for Claude Code and comparable AI coding-assistant executables.

‍ ‍

· Build developer workstation asset groups, privileged developer workstation groups, release-engineering workstation groups, security-engineering workstation groups, infrastructure-engineering workstation groups, and AI coding-assistant installed workstation groups.

‍ ‍

· Build high-risk child-process categories for shells, scripting engines, package managers, network utilities, credential utilities, Git clients, cloud CLIs, build tools, local servers, persistence utilities, and administrative utilities.

‍ ‍

· Correlate AI coding-assistant execution with preceding browser, email, chat, documentation, collaboration-tool, deeplink, URI-handler, repository-reference, issue, pull-request, README, or external-link activity where available.

‍ ‍

· Correlate child-process creation with settings, hook, project-local configuration, workspace-local configuration, startup automation, repository-open activity, and trusted-workspace context where available.

‍ ‍

· Use shorter correlation windows for AI coding-assistant launch followed by immediate shell, interpreter, network utility, credential utility, or package-manager execution.

‍ ‍

· Use moderate correlation windows for settings or hook activity followed by child-process creation, outbound communication, credential access, or blocked execution.

‍ ‍

· Use longer correlation windows for delayed hook execution, trusted-workspace reuse, repeated child-process execution, or similar activity across multiple developer workstations.

‍ ‍

· Tune severity based on launch context, child-process category, command-line risk, process lineage, working directory, user role, host sensitivity, repository sensitivity, network activity, credential access, and downstream identity or repository activity.

‍ ‍

· Avoid broad allowlisting for shells, interpreters, package managers, Git clients, cloud CLIs, or build tools because these tools are both legitimate developer dependencies and common attacker execution paths.

‍ ‍

· Use approved automation records, build records, repository ownership, testing records, incident-response records, and change-management records as triage evidence before suppressing or downgrading alerts.

‍ ‍

· Validate Splunk index availability, source-type mapping, CIM normalization, endpoint field names, process lineage fields, command-line capture, operating-system normalization, and endpoint-to-identity joins before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

9.0 / 10

‍ ‍

· The rule is behaviorally anchored to AI coding-assistant invocation followed by suspicious child-process execution.

‍ ‍

· The rule remains useful if the specific Claude Code deeplink settings-injection path changes but the attacker still causes an AI coding assistant to launch execution-capable utilities.

‍ ‍

· The score is supported by endpoint process lineage, command-line visibility, suspicious parent or launch context, child-process category, working-directory context, file activity, network activity, credential-access behavior, and correlation with identity, repository, CI/CD, or cloud telemetry.

‍ ‍

· The score is constrained by legitimate developer automation, expected build activity, approved hooks, package-manager workflows, command-line capture gaps, incomplete launch-context telemetry, and environment-specific AI coding-assistant usage patterns.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

8.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.5 / 10

‍ ‍

· Operational confidence depends on endpoint telemetry coverage, process lineage fidelity, command-line capture, developer workstation tagging, Claude Code process mapping, child-process baseline quality, and Splunk normalization.

‍ ‍

· Operational confidence is reduced where developers routinely use AI coding assistants to invoke shells, package managers, build tools, local servers, Git clients, or cloud CLIs as part of sanctioned workflows.

‍ ‍

· Operational confidence is reduced where launch-context telemetry, URI-handler telemetry, command-line capture, or approved automation records are incomplete.

‍ ‍

· Full-telemetry confidence improves when child-process activity is correlated with settings or hook changes, file telemetry, network telemetry, blocked control events, credential-access behavior, identity-provider records, repository activity, CI/CD activity, cloud activity, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of suspicious local execution but should still be correlated before classifying activity as confirmed exploitation.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious AI coding-assistant invocation followed by child-process execution, not successful Claude Code exploitation by itself.

‍ ‍

· AI coding assistants may legitimately spawn shells, interpreters, package managers, build tools, Git clients, local servers, and cloud CLIs during normal development.

‍ ‍

· The rule requires tuning by operating system, user role, repository, language ecosystem, and workstation class.

‍ ‍

· Missing command-line capture may reduce confidence in command-risk assessment.

‍ ‍

· Missing URI-handler, browser, email, chat, documentation, or collaboration-platform telemetry may reduce confidence in the initial external influence point.

‍ ‍

· Missing file or network telemetry may reduce confidence in whether execution followed settings or hook activity.

‍ ‍

· The rule may miss attacks that avoid obvious child processes, use approved automation, abuse already running processes, or operate through common developer tools.

‍ ‍

· Confirmation requires correlation with launch context, configuration activity, credential access, network behavior, repository activity, CI/CD activity, cloud activity, or other endpoint evidence.

‍ ‍

Detection Query Pattern

‍ ‍

Splunk behavioral correlation query pattern requiring platform syntax validation, index validation, CIM field validation, Claude Code process mapping, AI coding-assistant executable validation, child-process category validation, developer workstation tagging, operating-system normalization, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

Identify creation, modification, access, deletion, or rollback activity involving Claude Code settings, AI coding-assistant settings, hook files, project-local configuration, workspace-local configuration, startup automation, or trusted-workspace artifacts.

‍ ‍

· Prioritize file and configuration activity that occurs shortly before or during Claude Code or comparable AI coding-assistant session start.

‍ ‍

· Prioritize configuration content, file path, or operation activity associated with shell execution, script execution, network retrieval, package-manager invocation, credential access, environment-variable access, startup automation, or persistence-capable behavior.

‍ ‍

· Increase confidence when configuration activity is followed by child-process creation from Claude Code or comparable AI coding assistants.

‍ ‍

· Increase confidence when configuration activity occurs in a newly cloned, externally sourced, unusual, or previously trusted repository shortly after external link interaction, repository-reference interaction, documentation interaction, issue interaction, pull-request interaction, or README interaction.

‍ ‍

· Increase confidence when the child process launched after configuration activity performs encoded execution, inline execution, remote retrieval, credential-store access, SSH material access, environment-file access, package-registry token access, or cloud credential access.

‍ ‍

· Increase confidence when configuration activity is followed by outbound communication, blocked command execution, blocked script execution, blocked network retrieval, or EDR behavioral detection.

‍ ‍

· Increase confidence when similar settings or hook activity appears across multiple developer workstations, repositories, or users.

‍ ‍

· Reduce severity for known approved hooks, approved project automation, documented repository bootstrap scripts, expected build scripts, approved security testing, incident-response activity, and sanctioned developer workflows.

‍ ‍

· Do not treat settings or hook changes as compromise evidence by themselves.

‍ ‍

· Do not use static proof-of-concept strings as the primary detection condition.

‍ ‍

Required Telemetry

‍ ‍

Endpoint file telemetry.

‍ ‍

· Endpoint process telemetry.

‍ ‍

· EDR telemetry.

‍ ‍

· File creation events.

‍ ‍

· File modification events.

‍ ‍

· File deletion events where available.

‍ ‍

· File access events where available.

‍ ‍

· Parent-child process lineage.

‍ ‍

· Full command-line capture.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· File path.

‍ ‍

· File name.

‍ ‍

· File hash where available.

‍ ‍

· File operation type.

‍ ‍

· Repository or workspace path context where available.

‍ ‍

· Claude Code settings-path mapping.

‍ ‍

· Claude Code hook-path mapping.

‍ ‍

· AI coding-assistant configuration-path mapping.

‍ ‍

· Project-local configuration-path mapping.

‍ ‍

· Workspace-local configuration-path mapping.

‍ ‍

· Startup automation and persistence-path mapping.

‍ ‍

· File-content-risk enrichment where available.

‍ ‍

· Network telemetry where available.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Approved hook and automation inventory where available.

‍ ‍

· Identity, repository, CI/CD, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Normalize endpoint file telemetry across Windows, macOS, and Linux developer workstations.

‍ ‍

· Identify Claude Code settings locations, hook locations, project-local configuration locations, workspace-local configuration locations, and trusted-workspace artifacts.

‍ ‍

· Build path groups for AI coding-assistant settings, hooks, workspace configuration, project-local configuration, startup automation, and persistence-capable paths.

‍ ‍

· Build approved automation inventories for sanctioned hooks, repository bootstrap scripts, build scripts, local developer tooling, security automation, and incident-response tooling.

‍ ‍

· Correlate configuration file activity with Claude Code or comparable AI coding-assistant process start, session start, child-process creation, command execution, network communication, blocked execution, and credential-access behavior.

‍ ‍

· Use shorter correlation windows for settings or hook modification followed by immediate child-process creation or blocked execution.

‍ ‍

· Use moderate correlation windows for repository-open activity followed by configuration evaluation and command execution.

‍ ‍

· Use longer correlation windows for delayed hook execution, trusted-workspace reuse, repository switching, or repeated configuration activity across multiple developer workstations.

‍ ‍

· Tune severity based on file path sensitivity, operation type, command-capable content, child-process category, user role, repository sensitivity, host sensitivity, and downstream network or credential behavior.

‍ ‍

· Avoid broad suppression for repository-local configuration because attacker-controlled and legitimate project automation may use similar paths.

‍ ‍

· Use repository ownership, approved automation documentation, change-management records, testing records, and incident-response records as triage evidence before suppressing alerts.

‍ ‍

· Validate Splunk index availability, source-type mapping, CIM normalization, file-path normalization, operating-system path differences, approved automation lists, and endpoint-to-SIEM joins before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to settings, hook, and workspace-configuration activity followed by AI coding-assistant execution.

‍ ‍

· The rule remains useful if the specific deeplink settings-injection flaw changes but attackers continue to abuse configuration, hooks, startup automation, or trusted-workspace behavior.

‍ ‍

· The score is supported by file activity, process lineage, command-line telemetry, child-process execution, working-directory context, EDR behavioral detections, file-content-risk enrichment, and correlation with network or credential activity.

‍ ‍

· The score is constrained by legitimate project automation, approved hooks, repository bootstrap scripts, build tooling, file-path variation across platforms, incomplete file-content-risk enrichment, and incomplete approved-automation inventories.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on accurate settings-path mapping, hook-path mapping, file telemetry coverage, process lineage fidelity, command-line capture, developer workstation tagging, source-type normalization, and approved automation baselines.

‍ ‍

· Operational confidence is reduced where repositories routinely use hooks, bootstrap scripts, local automation, or workspace-specific configuration without centralized documentation.

‍ ‍

· Operational confidence is reduced where file telemetry does not capture enough path, operation, user, working-directory, repository context, or file-content risk.

‍ ‍

· Full-telemetry confidence improves when configuration activity is correlated with child-process execution, command-line content, network telemetry, blocked control events, credential-access behavior, identity-provider telemetry, repository activity, CI/CD activity, cloud telemetry, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of configuration-triggered execution risk, but confirmed compromise still requires execution and impact corroboration.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious configuration and hook activity followed by execution, not successful exploitation by itself.

‍ ‍

· Legitimate repositories may use settings, hooks, bootstrap scripts, package scripts, local configuration, and startup automation.

‍ ‍

· File path variation across operating systems and developer-tool versions may affect coverage.

‍ ‍

· Missing file telemetry may prevent visibility into settings or hook changes.

‍ ‍

· Missing command-line capture may reduce confidence in whether the resulting execution was suspicious.

‍ ‍

· Missing file-content-risk enrichment may require more reliance on process and timing correlation.

‍ ‍

· Approved automation inventories may be incomplete or stale.

‍ ‍

· The rule may miss attacks that do not modify files, operate through pre-existing trusted configuration, or abuse already approved automation.

‍ ‍

· Confirmation requires correlation with child-process execution, command behavior, blocked controls, network activity, credential access, identity anomalies, repository activity, CI/CD activity, or cloud telemetry.

‍ ‍

Detection Query Pattern

‍ ‍

Splunk behavioral correlation query pattern requiring platform syntax validation, index validation, source-type validation, settings-path mapping, hook-path mapping, workspace-configuration validation, developer workstation tagging, operating-system normalization, approved-automation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

Identify Claude Code or comparable AI coding-assistant process trees on developer workstations.

‍ ‍

· Detect credential-access, persistence, outbound communication, staging, discovery, or lateral-movement behavior under the AI coding-assistant process tree or shortly after it.

‍ ‍

· Prioritize access to SSH keys, cloud credential files, environment files, package-registry tokens, repository secrets, signing material, local credential stores, CI/CD configuration, or secrets-management configuration.

‍ ‍

· Prioritize creation or modification of shell profiles, login items, launch agents, scheduled tasks, cron jobs, services, startup folders, persistence-capable scripts, hidden files, staging directories, or downloaded tools.

‍ ‍

· Prioritize outbound communication to rare, newly observed, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unusual cloud, or previously unseen destinations.

‍ ‍

· Increase confidence when the behavior follows suspicious AI coding-assistant child-process execution, settings or hook activity, deeplink or URI-handler context, externally delivered link interaction, repository-open activity, or blocked execution.

‍ ‍

· Increase confidence when behavior occurs from a developer workstation with access to sensitive repositories, CI/CD systems, package registries, signing keys, cloud credentials, secrets, production infrastructure, or security tooling.

‍ ‍

· Increase confidence when identity, repository, CI/CD, package-registry, cloud, or NDR telemetry shows unusual downstream activity after the endpoint event.

‍ ‍

· Reduce severity for approved developer tooling, documented build scripts, sanctioned credential helpers, approved cloud workflows, approved security testing, approved incident-response activity, and known endpoint-management activity.

‍ ‍

· Do not classify credential, persistence, or outbound behavior as confirmed Claude Code exploitation without corroborating AI coding-assistant execution context.

‍ ‍

· Do not suppress credential or persistence behavior broadly because developer environments may contain both legitimate automation and high-value attacker targets.

‍ ‍

Required Telemetry

‍ ‍

Endpoint process telemetry.

‍ ‍

· Process tree telemetry.

‍ ‍

· Parent-child process lineage.

‍ ‍

· Full command-line capture.

‍ ‍

· File telemetry.

‍ ‍

· Credential-access behavior telemetry.

‍ ‍

· Persistence behavior telemetry.

‍ ‍

· Network telemetry.

‍ ‍

· EDR behavioral detections.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· Process hash.

‍ ‍

· File path.

‍ ‍

· File operation type.

‍ ‍

· Destination domain.

‍ ‍

· Destination IP.

‍ ‍

· Destination reputation.

‍ ‍

· Destination category.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Credential-path mapping.

‍ ‍

· Persistence-path mapping.

‍ ‍

· SSH key path mapping.

‍ ‍

· Cloud credential path mapping.

‍ ‍

· Environment-file path mapping.

‍ ‍

· Package-registry token path mapping.

‍ ‍

· Repository secret path mapping.

‍ ‍

· CI/CD configuration path mapping.

‍ ‍

· Approved automation and credential-helper inventory.

‍ ‍

· Identity, repository, CI/CD, package-registry, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Normalize process-tree telemetry across Windows, macOS, and Linux developer workstations.

‍ ‍

· Build process tree mappings for Claude Code and comparable AI coding-assistant processes.

‍ ‍

· Build monitored path groups for credential stores, SSH material, cloud credentials, environment files, package-registry tokens, repository secrets, signing material, CI/CD configuration, and secrets-management configuration.

‍ ‍

· Build monitored path groups for shell profiles, launch agents, login items, scheduled tasks, cron jobs, services, startup folders, persistence-capable scripts, temporary directories, hidden files, downloaded tools, and staging directories.

‍ ‍

· Correlate AI coding-assistant process trees with credential access, persistence activity, outbound communication, staging, discovery, blocked controls, and EDR behavioral detections.

‍ ‍

· Use shorter correlation windows for AI coding-assistant execution followed by credential access, persistence creation, outbound communication, or blocked control activity.

‍ ‍

· Use moderate correlation windows for settings or hook activity followed by credential access, file staging, network retrieval, or identity activity.

‍ ‍

· Use longer correlation windows for delayed persistence, token reuse, repository access, CI/CD activity, cloud access, or repeated endpoint behavior.

‍ ‍

· Tune severity based on credential type, file path sensitivity, persistence mechanism, destination reputation, user role, host sensitivity, repository sensitivity, workstation privilege level, and downstream identity or repository activity.

‍ ‍

· Avoid broad suppression for credential helpers, package managers, cloud CLIs, endpoint-management tools, or developer automation because attacker activity may use the same tools.

‍ ‍

· Use approved credential-helper inventories, repository automation records, cloud workflow records, testing records, incident-response records, and endpoint-management records as triage evidence before suppressing alerts.

‍ ‍

· Validate Splunk index availability, source-type mapping, process tree fidelity, credential-path mapping, persistence-path mapping, operating-system path differences, and endpoint-to-identity joins before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

9.0 / 10

‍ ‍

· The rule is behaviorally anchored to post-execution credential, persistence, and outbound behavior after AI coding-assistant process activity.

‍ ‍

· The rule remains useful if the initial trigger changes but the attacker still uses the developer workstation to access credentials, establish persistence, stage files, or communicate outbound.

‍ ‍

· The score is supported by process tree lineage, credential path access, persistence path modification, outbound network behavior, EDR behavioral detections, working-directory context, and downstream identity or repository enrichment.

‍ ‍

· The score is constrained by legitimate developer credential helpers, cloud CLIs, package managers, build scripts, endpoint-management tooling, and security tools that may access similar resources.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

8.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.5 / 10

‍ ‍

· Operational confidence depends on process tree fidelity, credential-path mapping, persistence-path mapping, file telemetry, network telemetry, developer asset tagging, approved automation baselines, and Splunk normalization.

‍ ‍

· Operational confidence is reduced where developer environments routinely access cloud credentials, SSH keys, package tokens, environment files, build secrets, or local credential stores through approved tooling.

‍ ‍

· Operational confidence is reduced where persistence or credential behavior is generated by endpoint-management, security tooling, backup tools, or sanctioned developer automation.

‍ ‍

· Full-telemetry confidence improves when endpoint behavior is correlated with settings or hook activity, child-process execution, blocked control events, identity-provider records, repository logs, CI/CD logs, package-registry logs, cloud-control-plane logs, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong escalation evidence for developer-workstation compromise assessment, especially when credential access or persistence follows suspicious AI coding-assistant execution.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious post-execution behavior after AI coding-assistant process activity, not successful exploitation by itself.

‍ ‍

· Developer tools may legitimately access credentials, environment files, SSH keys, package tokens, cloud credentials, or CI/CD configuration.

‍ ‍

· Endpoint-management, backup, security, and administrative tools may legitimately modify persistence-capable paths.

‍ ‍

· The rule requires accurate process tree lineage and path mapping to avoid noisy results.

‍ ‍

· Missing file, network, or credential behavior telemetry may reduce confidence.

‍ ‍

· The rule may miss attacks that avoid credential files, avoid persistence, use memory-only access, use existing sessions, or remain within approved developer workflows.

‍ ‍

· Confirmation requires correlation with suspicious AI coding-assistant context, command behavior, settings or hook activity, network activity, identity anomalies, repository activity, CI/CD activity, cloud telemetry, or forensic evidence.

‍ ‍

Detection Query Pattern

‍ ‍

Splunk behavioral escalation query pattern requiring platform syntax validation, index validation, source-type validation, AI coding-assistant process tree mapping, credential-path validation, persistence-path validation, developer workstation tagging, operating-system normalization, approved automation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

index=$ENV_ENDPOINT_INDEX$
dest_category IN (
"developer_workstation",
"privileged_developer_workstation",
"release_engineering_workstation",
"security_engineering_workstation",
"infrastructure_engineering_workstation",
"ai_coding_assistant_installed_workstation"
)
AND (
event_type IN (
    "Credential Access Behavior",
    "Persistence Behavior",
    "Discovery Behavior",
    "Suspicious File Staging",
    "Suspicious Network Retrieval",
    "Lateral Movement Behavior"
)
OR file_path IN (
    "$PATH_CREDENTIAL_STORES$",
    "$PATH_SSH_KEYS$",
    "$PATH_CLOUD_CREDENTIALS$",
    "$PATH_ENVIRONMENT_FILES$",
    "$PATH_PACKAGE_REGISTRY_TOKENS$",
    "$PATH_REPOSITORY_SECRETS$",
    "$PATH_SIGNING_MATERIAL$",
    "$PATH_CI_CD_CONFIGURATION$",
    "$PATH_SECRETS_MANAGEMENT_CONFIGURATION$",
    "$PATH_SHELL_PROFILES$",
    "$PATH_LAUNCH_AGENTS$",
    "$PATH_LOGIN_ITEMS$",
    "$PATH_SCHEDULED_TASKS$",
    "$PATH_CRON$",
    "$PATH_SERVICE_CONFIGURATION$",
    "$PATH_STARTUP_FOLDERS$",
    "$PATH_TEMPORARY_STAGING$"
)
OR dest_reputation IN (
    "high_risk",
    "suspicious",
    "rare",
    "newly_observed",
    "unknown"
)
)
| eval post_execution_time=_time
| join type=inner dest user [
search index=$ENV_ENDPOINT_PROCESS_INDEX$
earliest=-$ENV_AI_CODING_ASSISTANT_POST_EXECUTION_WINDOW$
event_type IN (
    "Claude Code Process Started",
    "AI Coding Assistant Process Started",
    "AI Coding Assistant Child Process Created",
    "Shell Spawned By AI Coding Assistant",
    "Script Interpreter Spawned By AI Coding Assistant",
    "Network Utility Spawned By AI Coding Assistant",
    "Credential Utility Spawned By AI Coding Assistant",
    "Suspicious AI Coding Assistant Process Lineage",
    "Blocked Command Execution From AI Coding Assistant"
)
| fields _time dest user event_type process_name parent_process_name process command_line process_guid parent_process_guid
]
| join type=left dest user [
search index=$ENV_ENDPOINT_FILE_INDEX$
earliest=-$ENV_AI_CODING_ASSISTANT_POST_EXECUTION_WINDOW$
event_type IN (
    "Claude Code Settings Modified",
    "Hook Configuration Modified",
    "Project Local Configuration Modified",
    "Workspace Local Configuration Modified"
)
| fields _time dest user event_type file_path file_action
]
| search NOT change_context IN (
"approved_developer_workflow",
"approved_build_or_release_activity",
"approved_security_testing",
"approved_incident_response_activity",
"approved_endpoint_management_activity",
"approved_credential_helper_activity"
)

‍ ‍

Elastic

‍ ‍

Detection Viability Assessment

‍ ‍

Elastic has three rules for this EXP report.

‍ ‍

· Elastic is strongly viable as a primary detection-rule system for this report when Elastic Defend, endpoint process telemetry, file telemetry, network telemetry, user identity, host identity, working-directory context, and SIEM correlation are available.

‍ ‍

· Elastic is strongest where endpoint process creation, parent-child process lineage, full command-line capture, file and configuration activity, endpoint network events, EDR behavioral signals, developer workstation asset tagging, and identity or repository enrichment can be correlated.

‍ ‍

· Elastic can identify suspicious sequencing between Claude Code or comparable AI coding-assistant execution, abnormal parentage, settings or hook activity, child-process creation, outbound communication, credential access, persistence behavior, and downstream repository, CI/CD, or cloud activity.

‍ ‍

· Elastic is suitable for this behavior model because the highest-value detection path is endpoint-led, correlation-driven, and behavior-based rather than dependent on static exploit strings, vulnerable-version matching, or proof-of-concept artifacts.

‍ ‍

· Elastic rules should not depend on public proof-of-concept payloads, exact deeplink fragments, exploit labels, vulnerable-version exposure alone, or Claude Code installation alone.

‍ ‍

Identify Claude Code or comparable AI coding-assistant execution on developer workstations.

‍ ‍

· Identify cases where the parent process, grandparent process, launch context, or preceding event suggests browser, chat, email, documentation, collaboration-tool, deeplink, URI-handler, repository-reference, issue, pull-request, README, or external-link activity.

‍ ‍

· Detect shell, scripting interpreter, package-manager, network utility, credential utility, Git client, cloud CLI, build tool, local server, persistence utility, or administrative utility execution from the AI coding-assistant process tree.

‍ ‍

· Increase confidence when child-process execution occurs shortly after deeplink invocation, URI-handler activity, external link interaction, repository-open activity, documentation-link interaction, issue or pull-request interaction, README interaction, or unusual workspace activity.

‍ ‍

· Increase confidence when child-process execution occurs near settings, hooks, project-local configuration, workspace-local configuration, startup automation, or trusted-workspace activity.

‍ ‍

· Increase confidence when command-line arguments show encoded content, inline execution, remote retrieval, environment-variable access, credential-store access, SSH material access, token access, package installation, file-permission modification, or system modification.

‍ ‍

· Increase confidence when the child process initiates outbound network communication to a rare, newly observed, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unusual cloud, or previously unseen destination.

‍ ‍

· Increase confidence when the child process accesses credential material, repository secrets, package-registry tokens, cloud credential files, environment files, SSH keys, signing material, CI/CD configuration, or sensitive developer tooling paths.

‍ ‍

· Increase confidence when similar behavior appears across multiple developer workstations after shared repository, documentation, issue, pull-request, README, or link interaction.

‍ ‍

· Reduce severity for documented build workflows, approved repository automation, sanctioned hooks, expected package-manager activity, approved security testing, approved incident-response activity, and known developer automation.

‍ ‍

· Do not classify child-process execution as confirmed compromise without corroborating suspicious launch context, settings or hook activity, credential access, network activity, blocked control events, repository activity, CI/CD activity, identity events, or cloud activity.

‍ ‍

· Do not broadly suppress AI coding-assistant child-process activity because normal developer execution and attacker execution may use the same tools.

‍ ‍

Required Telemetry

‍ ‍

Elastic Defend endpoint process telemetry.

‍ ‍

· Process creation events.

‍ ‍

· Parent process name.

‍ ‍

· Parent process executable.

‍ ‍

· Child process name.

‍ ‍

· Child process executable.

‍ ‍

· Full command line.

‍ ‍

· Process hash.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· Process start time.

‍ ‍

· Process end time where available.

‍ ‍

· Process entity ID or process tree linkage.

‍ ‍

· File telemetry where available.

‍ ‍

· Network telemetry where available.

‍ ‍

· Web, browser, proxy, email, chat, documentation, or collaboration-platform telemetry where available.

‍ ‍

· Deeplink or URI-handler telemetry where available.

‍ ‍

· Script execution telemetry where available.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Claude Code or comparable AI coding-assistant executable mapping.

‍ ‍

· Known-good developer automation allowlist.

‍ ‍

· Repository, user-role, host-role, and workstation-class context where available.

‍ ‍

· Identity, repository, CI/CD, package-registry, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Normalize Elastic endpoint telemetry across Windows, macOS, and Linux developer workstations.

‍ ‍

· Build process identity mappings for Claude Code and comparable AI coding-assistant executables.

‍ ‍

· Build developer workstation asset groups, privileged developer workstation groups, release-engineering workstation groups, security-engineering workstation groups, infrastructure-engineering workstation groups, and AI coding-assistant installed workstation groups.

‍ ‍

· Build high-risk child-process categories for shells, scripting engines, package managers, network utilities, credential utilities, Git clients, cloud CLIs, build tools, local servers, persistence utilities, and administrative utilities.

‍ ‍

· Correlate AI coding-assistant execution with preceding browser, email, chat, documentation, collaboration-tool, deeplink, URI-handler, repository-reference, issue, pull-request, README, or external-link activity where available.

‍ ‍

· Correlate child-process creation with settings, hook, project-local configuration, workspace-local configuration, startup automation, repository-open activity, and trusted-workspace context where available.

‍ ‍

· Use shorter correlation windows for AI coding-assistant launch followed by immediate shell, interpreter, network utility, credential utility, or package-manager execution.

‍ ‍

· Use moderate correlation windows for settings or hook activity followed by child-process creation, outbound communication, credential access, or blocked execution.

‍ ‍

· Use longer correlation windows for delayed hook execution, trusted-workspace reuse, repeated child-process execution, or similar activity across multiple developer workstations.

‍ ‍

· Tune severity based on launch context, child-process category, command-line risk, process lineage, working directory, user role, host sensitivity, repository sensitivity, network activity, credential access, and downstream identity or repository activity.

‍ ‍

· Avoid broad allowlisting for shells, interpreters, package managers, Git clients, cloud CLIs, or build tools because these tools are both legitimate developer dependencies and common attacker execution paths.

‍ ‍

· Use approved automation records, build records, repository ownership, testing records, incident-response records, and change-management records as triage evidence before suppressing or downgrading alerts.

‍ ‍

· Validate Elastic index availability, ECS field mapping, endpoint field names, process lineage fields, command-line capture, operating-system normalization, process entity ID availability, and endpoint-to-identity joins before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

9.0 / 10

‍ ‍

· The rule is behaviorally anchored to AI coding-assistant launch context followed by suspicious child-process execution.

‍ ‍

· The rule remains useful if the specific Claude Code deeplink settings-injection path changes but the attacker still causes an AI coding assistant to launch execution-capable utilities.

‍ ‍

· The score is supported by endpoint process lineage, command-line visibility, suspicious parent or launch context, child-process category, working-directory context, file activity, network activity, credential-access behavior, and correlation with identity, repository, CI/CD, or cloud telemetry.

‍ ‍

· The score is constrained by legitimate developer automation, expected build activity, approved hooks, package-manager workflows, command-line capture gaps, incomplete launch-context telemetry, and environment-specific AI coding-assistant usage patterns.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

8.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.5 / 10

‍ ‍

· Operational confidence depends on Elastic endpoint coverage, process lineage fidelity, command-line capture, developer workstation tagging, Claude Code process mapping, child-process baseline quality, and ECS normalization.

‍ ‍

· Operational confidence is reduced where developers routinely use AI coding assistants to invoke shells, package managers, build tools, local servers, Git clients, or cloud CLIs as part of sanctioned workflows.

‍ ‍

· Operational confidence is reduced where launch-context telemetry, URI-handler telemetry, command-line capture, or approved automation records are incomplete.

‍ ‍

· Full-telemetry confidence improves when child-process activity is correlated with settings or hook changes, file telemetry, network telemetry, blocked control events, credential-access behavior, identity-provider records, repository activity, CI/CD activity, cloud activity, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of suspicious local execution but should still be correlated before classifying activity as confirmed exploitation.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious AI coding-assistant launch and child-process behavior, not successful Claude Code exploitation by itself.

‍ ‍

· AI coding assistants may legitimately spawn shells, interpreters, package managers, build tools, Git clients, local servers, and cloud CLIs during normal development.

‍ ‍

· The rule requires tuning by operating system, user role, repository, language ecosystem, and workstation class.

‍ ‍

· Missing command-line capture may reduce confidence in command-risk assessment.

‍ ‍

· Missing URI-handler, browser, email, chat, documentation, or collaboration-platform telemetry may reduce confidence in the initial external influence point.

‍ ‍

· Missing file or network telemetry may reduce confidence in whether execution followed settings or hook activity.

‍ ‍

· The rule may miss attacks that avoid obvious child processes, use approved automation, abuse already running processes, or operate through common developer tools.

‍ ‍

· Confirmation requires correlation with launch context, configuration activity, credential access, network behavior, repository activity, CI/CD activity, cloud activity, or other endpoint evidence.

‍ ‍

Detection Query Pattern

‍ ‍

Elastic EQL behavioral correlation query pattern requiring platform syntax validation, index validation, ECS field validation, Claude Code process mapping, AI coding-assistant executable validation, child-process category validation, developer workstation tagging, operating-system normalization, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

Identify creation, modification, access, deletion, or rollback activity involving Claude Code settings, AI coding-assistant settings, hook files, project-local configuration, workspace-local configuration, startup automation, or trusted-workspace artifacts.

‍ ‍

· Prioritize file and configuration activity that occurs shortly before or during Claude Code or comparable AI coding-assistant session start.

‍ ‍

· Prioritize configuration content, file path, or operation activity associated with shell execution, script execution, network retrieval, package-manager invocation, credential access, environment-variable access, startup automation, or persistence-capable behavior.

‍ ‍

· Increase confidence when configuration activity is followed by child-process creation from Claude Code or comparable AI coding assistants.

‍ ‍

· Increase confidence when configuration activity occurs in a newly cloned, externally sourced, unusual, or previously trusted repository shortly after external link interaction, repository-reference interaction, documentation interaction, issue interaction, pull-request interaction, or README interaction.

‍ ‍

· Increase confidence when the child process launched after configuration activity performs encoded execution, inline execution, remote retrieval, credential-store access, SSH material access, environment-file access, package-registry token access, or cloud credential access.

‍ ‍

· Increase confidence when configuration activity is followed by outbound communication, blocked command execution, blocked script execution, blocked network retrieval, or EDR behavioral detection.

‍ ‍

· Increase confidence when similar settings or hook activity appears across multiple developer workstations, repositories, or users.

‍ ‍

· Reduce severity for known approved hooks, approved project automation, documented repository bootstrap scripts, expected build scripts, approved security testing, incident-response activity, and sanctioned developer workflows.

‍ ‍

· Do not treat settings or hook changes as compromise evidence by themselves.

‍ ‍

· Do not use static proof-of-concept strings as the primary detection condition.

‍ ‍

Required Telemetry

‍ ‍

Elastic Defend endpoint file telemetry.

‍ ‍

· Elastic Defend endpoint process telemetry.

‍ ‍

· File creation events.

‍ ‍

· File modification events.

‍ ‍

· File deletion events where available.

‍ ‍

· File access events where available.

‍ ‍

· Parent-child process lineage.

‍ ‍

· Full command-line capture.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· File path.

‍ ‍

· File name.

‍ ‍

· File hash where available.

‍ ‍

· File operation type.

‍ ‍

· Repository or workspace path context where available.

‍ ‍

· Claude Code settings-path mapping.

‍ ‍

· Claude Code hook-path mapping.

‍ ‍

· AI coding-assistant configuration-path mapping.

‍ ‍

· Project-local configuration-path mapping.

‍ ‍

· Workspace-local configuration-path mapping.

‍ ‍

· Startup automation and persistence-path mapping.

‍ ‍

· File-content-risk enrichment where available.

‍ ‍

· Network telemetry where available.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Approved hook and automation inventory where available.

‍ ‍

· Identity, repository, CI/CD, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Normalize endpoint file telemetry across Windows, macOS, and Linux developer workstations.

‍ ‍

· Identify Claude Code settings locations, hook locations, project-local configuration locations, workspace-local configuration locations, and trusted-workspace artifacts.

‍ ‍

· Build path groups for AI coding-assistant settings, hooks, workspace configuration, project-local configuration, startup automation, and persistence-capable paths.

‍ ‍

· Build approved automation inventories for sanctioned hooks, repository bootstrap scripts, build scripts, local developer tooling, security automation, and incident-response tooling.

‍ ‍

· Correlate configuration file activity with Claude Code or comparable AI coding-assistant process start, session start, child-process creation, command execution, network communication, blocked execution, and credential-access behavior.

‍ ‍

· Use shorter correlation windows for settings or hook modification followed by immediate child-process creation or blocked execution.

‍ ‍

· Use moderate correlation windows for repository-open activity followed by configuration evaluation and command execution.

‍ ‍

· Use longer correlation windows for delayed hook execution, trusted-workspace reuse, repository switching, or repeated configuration activity across multiple developer workstations.

‍ ‍

· Tune severity based on file path sensitivity, operation type, command-capable content, child-process category, user role, repository sensitivity, host sensitivity, and downstream network or credential behavior.

‍ ‍

· Avoid broad suppression for repository-local configuration because attacker-controlled and legitimate project automation may use similar paths.

‍ ‍

· Use repository ownership, approved automation documentation, change-management records, testing records, and incident-response records as triage evidence before suppressing alerts.

‍ ‍

· Validate Elastic index availability, ECS field mapping, file-path normalization, operating-system path differences, approved automation lists, process entity ID availability, and endpoint-to-SIEM joins before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to settings, hook, and workspace-configuration activity followed by AI coding-assistant execution.

‍ ‍

· The rule remains useful if the specific deeplink settings-injection flaw changes but attackers continue to abuse configuration, hooks, startup automation, or trusted-workspace behavior.

‍ ‍

· The score is supported by file activity, process lineage, command-line telemetry, child-process execution, working-directory context, EDR behavioral detections, file-content-risk enrichment, and correlation with network or credential activity.

‍ ‍

· The score is constrained by legitimate project automation, approved hooks, repository bootstrap scripts, build tooling, file-path variation across platforms, incomplete file-content-risk enrichment, and incomplete approved-automation inventories.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on accurate settings-path mapping, hook-path mapping, file telemetry coverage, process lineage fidelity, command-line capture, developer workstation tagging, ECS normalization, and approved automation baselines.

‍ ‍

· Operational confidence is reduced where repositories routinely use hooks, bootstrap scripts, local automation, or workspace-specific configuration without centralized documentation.

‍ ‍

· Operational confidence is reduced where file telemetry does not capture enough path, operation, user, working-directory, repository context, or file-content risk.

‍ ‍

· Full-telemetry confidence improves when configuration activity is correlated with child-process execution, command-line content, network telemetry, blocked control events, credential-access behavior, identity-provider telemetry, repository activity, CI/CD activity, cloud telemetry, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of configuration-triggered execution risk, but confirmed compromise still requires execution and impact corroboration.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious configuration and hook activity followed by execution, not successful exploitation by itself.

‍ ‍

· Legitimate repositories may use settings, hooks, bootstrap scripts, package scripts, local configuration, and startup automation.

‍ ‍

· File path variation across operating systems and developer-tool versions may affect coverage.

‍ ‍

· Missing file telemetry may prevent visibility into settings or hook changes.

‍ ‍

· Missing command-line capture may reduce confidence in whether the resulting execution was suspicious.

‍ ‍

· Missing file-content-risk enrichment may require more reliance on process and timing correlation.

‍ ‍

· Approved automation inventories may be incomplete or stale.

‍ ‍

· The rule may miss attacks that do not modify files, operate through pre-existing trusted configuration, or abuse already approved automation.

‍ ‍

· Confirmation requires correlation with child-process execution, command behavior, blocked controls, network activity, credential access, identity anomalies, repository activity, CI/CD activity, or cloud telemetry.

‍ ‍

Detection Query Pattern

‍ ‍

Elastic EQL behavioral correlation query pattern requiring platform syntax validation, index validation, ECS field validation, settings-path mapping, hook-path mapping, workspace-configuration validation, developer workstation tagging, operating-system normalization, approved-automation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

Identify Claude Code or comparable AI coding-assistant process trees on developer workstations.

‍ ‍

· Detect credential-access, persistence, outbound communication, staging, discovery, or lateral-movement behavior under the AI coding-assistant process tree or shortly after it.

‍ ‍

· Prioritize access to SSH keys, cloud credential files, environment files, package-registry tokens, repository secrets, signing material, local credential stores, CI/CD configuration, or secrets-management configuration.

‍ ‍

· Prioritize creation or modification of shell profiles, login items, launch agents, scheduled tasks, cron jobs, services, startup folders, persistence-capable scripts, hidden files, staging directories, or downloaded tools.

‍ ‍

· Prioritize outbound communication to rare, newly observed, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unusual cloud, or previously unseen destinations.

‍ ‍

· Increase confidence when the behavior follows suspicious AI coding-assistant child-process execution, settings or hook activity, deeplink or URI-handler context, externally delivered link interaction, repository-open activity, or blocked execution.

‍ ‍

· Increase confidence when behavior occurs from a developer workstation with access to sensitive repositories, CI/CD systems, package registries, signing keys, cloud credentials, secrets, production infrastructure, or security tooling.

‍ ‍

· Increase confidence when identity, repository, CI/CD, package-registry, cloud, or NDR telemetry shows unusual downstream activity after the endpoint event.

‍ ‍

· Reduce severity for approved developer tooling, documented build scripts, sanctioned credential helpers, approved cloud workflows, approved security testing, approved incident-response activity, and known endpoint-management activity.

‍ ‍

· Do not classify credential, persistence, or outbound behavior as confirmed Claude Code exploitation without corroborating AI coding-assistant execution context.

‍ ‍

· Do not suppress credential or persistence behavior broadly because developer environments may contain both legitimate automation and high-value attacker targets.

‍ ‍

Required Telemetry

‍ ‍

Elastic Defend endpoint process telemetry.

‍ ‍

· Process tree telemetry.

‍ ‍

· Parent-child process lineage.

‍ ‍

· Full command-line capture.

‍ ‍

· File telemetry.

‍ ‍

· Credential-access behavior telemetry.

‍ ‍

· Persistence behavior telemetry.

‍ ‍

· Network telemetry.

‍ ‍

· EDR behavioral detections.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· Process hash.

‍ ‍

· File path.

‍ ‍

· File operation type.

‍ ‍

· Destination domain.

‍ ‍

· Destination IP.

‍ ‍

· Destination reputation.

‍ ‍

· Destination category.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Credential-path mapping.

‍ ‍

· Persistence-path mapping.

‍ ‍

· SSH key path mapping.

‍ ‍

· Cloud credential path mapping.

‍ ‍

· Environment-file path mapping.

‍ ‍

· Package-registry token path mapping.

‍ ‍

· Repository secret path mapping.

‍ ‍

· CI/CD configuration path mapping.

‍ ‍

· Approved automation and credential-helper inventory.

‍ ‍

· Identity, repository, CI/CD, package-registry, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Normalize process-tree telemetry across Windows, macOS, and Linux developer workstations.

‍ ‍

· Build process tree mappings for Claude Code and comparable AI coding-assistant processes.

‍ ‍

· Build monitored path groups for credential stores, SSH material, cloud credentials, environment files, package-registry tokens, repository secrets, signing material, CI/CD configuration, and secrets-management configuration.

‍ ‍

· Build monitored path groups for shell profiles, launch agents, login items, scheduled tasks, cron jobs, services, startup folders, persistence-capable scripts, temporary directories, hidden files, downloaded tools, and staging directories.

‍ ‍

· Correlate AI coding-assistant process trees with credential access, persistence activity, outbound communication, staging, discovery, blocked controls, and EDR behavioral detections.

‍ ‍

· Use shorter correlation windows for AI coding-assistant execution followed by credential access, persistence creation, outbound communication, or blocked control activity.

‍ ‍

· Use moderate correlation windows for settings or hook activity followed by credential access, file staging, network retrieval, or identity activity.

‍ ‍

· Use longer correlation windows for delayed persistence, token reuse, repository access, CI/CD activity, cloud access, or repeated endpoint behavior.

‍ ‍

· Tune severity based on credential type, file path sensitivity, persistence mechanism, destination reputation, user role, host sensitivity, repository sensitivity, workstation privilege level, and downstream identity or repository activity.

‍ ‍

· Avoid broad suppression for credential helpers, package managers, cloud CLIs, endpoint-management tools, or developer automation because attacker activity may use the same tools.

‍ ‍

· Use approved credential-helper inventories, repository automation records, cloud workflow records, testing records, incident-response records, and endpoint-management records as triage evidence before suppressing alerts.

‍ ‍

· Validate Elastic index availability, ECS field mapping, process tree fidelity, credential-path mapping, persistence-path mapping, operating-system path differences, process entity ID availability, and endpoint-to-identity joins before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

9.0 / 10

‍ ‍

· The rule is behaviorally anchored to post-execution credential, persistence, and outbound behavior after AI coding-assistant process activity.

‍ ‍

· The rule remains useful if the initial trigger changes but the attacker still uses the developer workstation to access credentials, establish persistence, stage files, or communicate outbound.

‍ ‍

· The score is supported by process tree lineage, credential path access, persistence path modification, outbound network behavior, EDR behavioral detections, working-directory context, and downstream identity or repository enrichment.

‍ ‍

· The score is constrained by legitimate developer credential helpers, cloud CLIs, package managers, build scripts, endpoint-management tooling, and security tools that may access similar resources.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

8.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.5 / 10

‍ ‍

· Operational confidence depends on process tree fidelity, credential-path mapping, persistence-path mapping, file telemetry, network telemetry, developer asset tagging, approved automation baselines, and ECS normalization.

‍ ‍

· Operational confidence is reduced where developer environments routinely access cloud credentials, SSH keys, package tokens, environment files, build secrets, or local credential stores through approved tooling.

‍ ‍

· Operational confidence is reduced where persistence or credential behavior is generated by endpoint-management, security tooling, backup tools, or sanctioned developer automation.

‍ ‍

· Full-telemetry confidence improves when endpoint behavior is correlated with settings or hook activity, child-process execution, blocked control events, identity-provider records, repository logs, CI/CD logs, package-registry logs, cloud-control-plane logs, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong escalation evidence for developer-workstation compromise assessment, especially when credential access or persistence follows suspicious AI coding-assistant execution.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious post-execution behavior after AI coding-assistant process activity, not successful exploitation by itself.

‍ ‍

· Developer tools may legitimately access credentials, environment files, SSH keys, package tokens, cloud credentials, or CI/CD configuration.

‍ ‍

· Endpoint-management, backup, security, and administrative tools may legitimately modify persistence-capable paths.

‍ ‍

· The rule requires accurate process tree lineage and path mapping to avoid noisy results.

‍ ‍

· Missing file, network, or credential behavior telemetry may reduce confidence.

‍ ‍

· The rule may miss attacks that avoid credential files, avoid persistence, use memory-only access, use existing sessions, or remain within approved developer workflows.

‍ ‍

· Confirmation requires correlation with suspicious AI coding-assistant context, command behavior, settings or hook activity, network activity, identity anomalies, repository activity, CI/CD activity, cloud telemetry, or forensic evidence.

‍ ‍

Detection Query Pattern

‍ ‍

Elastic EQL behavioral escalation query pattern requiring platform syntax validation, index validation, ECS field validation, AI coding-assistant process tree mapping, credential-path validation, persistence-path validation, developer workstation tagging, operating-system normalization, approved automation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

sequence by host.id, user.id with maxspan=30m
[process where
    event.category == "process"
    and event.type in ("start", "process_started")
    and host.category in (
      "developer_workstation",
      "privileged_developer_workstation",
      "release_engineering_workstation",
      "security_engineering_workstation",
      "infrastructure_engineering_workstation",
      "ai_coding_assistant_installed_workstation"
    )
    and (
      process.name in (
        "claude",
        "claude-code",
        "Claude Code"
      )
      or process.parent.name in (
        "claude",
        "claude-code",
        "Claude Code"
      )
    )
]
[any where
    (
      file.path in (
        "$PATH_CREDENTIAL_STORES$",
        "$PATH_SSH_KEYS$",
        "$PATH_CLOUD_CREDENTIALS$",
        "$PATH_ENVIRONMENT_FILES$",
        "$PATH_PACKAGE_REGISTRY_TOKENS$",
        "$PATH_REPOSITORY_SECRETS$",
        "$PATH_SIGNING_MATERIAL$",
        "$PATH_CI_CD_CONFIGURATION$",
        "$PATH_SECRETS_MANAGEMENT_CONFIGURATION$",
        "$PATH_SHELL_PROFILES$",
        "$PATH_LAUNCH_AGENTS$",
        "$PATH_LOGIN_ITEMS$",
        "$PATH_SCHEDULED_TASKS$",
        "$PATH_CRON$",
        "$PATH_SERVICE_CONFIGURATION$",
        "$PATH_STARTUP_FOLDERS$",
        "$PATH_TEMPORARY_STAGING$"
      )
      or event.action in (
        "credential_access_behavior",
        "persistence_behavior",
        "discovery_behavior",
        "suspicious_file_staging",
        "suspicious_network_retrieval",
        "lateral_movement_behavior"
      )
      or destination.reputation in (
        "high_risk",
        "suspicious",
        "rare",
        "newly_observed",
        "unknown"
      )
    )
]
until [any where event.action in (
"approved_developer_workflow",
"approved_build_or_release_activity",
"approved_security_testing",
"approved_incident_response_activity",
"approved_endpoint_management_activity",
"approved_credential_helper_activity"
)]

‍ ‍

QRadar

‍ ‍

Detection Viability Assessment

‍ ‍

QRadar has three rules for this EXP report.

‍ ‍

· QRadar is viable as a primary SIEM correlation system for this report when endpoint process events, file and configuration events, network events, authentication events, repository logs, CI/CD logs, package-registry logs, cloud-control-plane logs, and EDR detections are ingested with consistent normalization.

‍ ‍

· QRadar is strongest where endpoint telemetry can be correlated with network, identity, repository, CI/CD, cloud, asset, and change-management context to identify suspicious sequencing after Claude Code or comparable AI coding-assistant activity.

‍ ‍

· QRadar can identify suspicious relationships between AI coding-assistant execution, abnormal parent or launch context, settings or hook activity, child-process creation, blocked execution, outbound communication, credential access, repository activity, CI/CD interaction, cloud activity, and identity anomalies.

‍ ‍

· QRadar is suitable for this behavior model because the highest-value detection path requires offense-style correlation across multiple event classes rather than a single static indicator, file signature, exploit string, or vulnerable-version match.

‍ ‍

· QRadar rules should remain behavior-led and should not depend on public proof-of-concept payloads, exact deeplink fragments, exploit labels, vulnerable-version exposure alone, or Claude Code installation alone.

‍ ‍

· Identify Claude Code or comparable AI coding-assistant process activity on developer workstations.

‍ ‍

· Identify cases where the parent process, launch context, related interaction event, or preceding event suggests browser, chat, email, documentation, collaboration-tool, deeplink, URI-handler, repository-reference, issue, pull-request, README, or externally influenced workflow activity.

‍ ‍

· Detect child-process creation from Claude Code or comparable AI coding-assistant parent processes.

‍ ‍

· Prioritize child processes involving shell interpreters, scripting engines, package managers, network utilities, credential utilities, Git clients, cloud CLIs, build tools, local servers, persistence utilities, or administrative utilities.

‍ ‍

· Increase confidence when child-process execution occurs shortly after deeplink invocation, URI-handler activity, external link interaction, repository-open activity, documentation-link interaction, issue or pull-request interaction, README interaction, or unusual workspace activity.

‍ ‍

· Increase confidence when child-process execution occurs near settings, hooks, project-local configuration, workspace-local configuration, startup automation, or trusted-workspace activity.

‍ ‍

· Increase confidence when command-line arguments show encoded content, inline execution, remote retrieval, environment-variable access, credential-store access, SSH material access, token access, package installation, file-permission modification, or system modification.

‍ ‍

· Increase confidence when the child process initiates outbound network communication to a rare, newly observed, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unusual cloud, or previously unseen destination.

‍ ‍

· Increase confidence when the child process accesses credential material, repository secrets, package-registry tokens, cloud credential files, environment files, SSH keys, signing material, CI/CD configuration, or sensitive developer tooling paths.

‍ ‍

· Increase confidence when QRadar offense context links the same user, host, destination, repository, or source interaction across multiple related events in the same operational window.

‍ ‍

· Reduce severity for documented build workflows, approved repository automation, sanctioned hooks, expected package-manager activity, approved security testing, approved incident-response activity, known developer automation, and approved endpoint-management activity.

‍ ‍

· Do not classify child-process execution as confirmed compromise without corroborating suspicious launch context, settings or hook activity, credential access, network activity, blocked control events, repository activity, CI/CD activity, identity events, or cloud activity.

‍ ‍

· Do not broadly suppress AI coding-assistant child-process activity because normal developer execution and attacker execution may use the same tools.

‍ ‍

Required Telemetry

‍ ‍

· Endpoint process events.

‍ ‍

· EDR events.

‍ ‍

· Parent process name.

‍ ‍

· Parent process path.

‍ ‍

· Child process name.

‍ ‍

· Child process path.

‍ ‍

· Full command line.

‍ ‍

· Process hash.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· Process start time.

‍ ‍

· Process termination time where available.

‍ ‍

· Process tree or causal process lineage.

‍ ‍

· File events where available.

‍ ‍

· Network events where available.

‍ ‍

· Web, browser, proxy, email, chat, documentation, or collaboration-platform events where available.

‍ ‍

· Deeplink or URI-handler events where available.

‍ ‍

· Script execution events where available.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Claude Code or comparable AI coding-assistant executable mapping.

‍ ‍

· QRadar asset profiles for developer workstations.

‍ ‍

· QRadar reference sets for AI coding-assistant processes and high-risk child processes.

‍ ‍

· QRadar custom properties for parent process, child process, command line, working directory, file path, repository path, and interaction context.

‍ ‍

· Known-good developer automation reference sets.

‍ ‍

· Repository, user-role, host-role, and workstation-class context where available.

‍ ‍

· Identity, repository, CI/CD, package-registry, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Normalize endpoint process telemetry across Windows, macOS, and Linux developer workstations before enabling production offense generation.

‍ ‍

· Build QRadar reference sets for Claude Code processes, comparable AI coding-assistant processes, high-risk child-process categories, developer workstation assets, privileged developer workstations, release-engineering workstations, security-engineering workstations, infrastructure-engineering workstations, and AI coding-assistant installed workstations.

‍ ‍

· Build high-risk child-process categories for shells, scripting engines, package managers, network utilities, credential utilities, Git clients, cloud CLIs, build tools, local servers, persistence utilities, and administrative utilities.

‍ ‍

· Extract custom properties for parent process, child process, command line, working directory, file path, file action, repository path, user identity, host identity, and related interaction event.

‍ ‍

· Correlate AI coding-assistant execution with preceding browser, email, chat, documentation, collaboration-tool, deeplink, URI-handler, repository-reference, issue, pull-request, README, or external-link activity where available.

‍ ‍

· Correlate child-process creation with settings, hook, project-local configuration, workspace-local configuration, startup automation, repository-open activity, and trusted-workspace context where available.

‍ ‍

· Use shorter rule tests for AI coding-assistant launch followed by immediate shell, interpreter, network utility, credential utility, or package-manager execution.

‍ ‍

· Use moderate rule tests for settings or hook activity followed by child-process creation, outbound communication, credential access, or blocked execution.

‍ ‍

· Use longer rule tests for delayed hook execution, trusted-workspace reuse, repeated child-process execution, repeated destination contact, or similar activity across multiple developer workstations.

‍ ‍

· Tune offense severity based on launch context, child-process category, command-line risk, process lineage, working directory, user role, host sensitivity, repository sensitivity, network activity, credential access, and downstream identity or repository activity.

‍ ‍

· Avoid broad allowlisting for shells, interpreters, package managers, Git clients, cloud CLIs, or build tools because these tools are both legitimate developer dependencies and common attacker execution paths.

‍ ‍

· Use approved automation records, build records, repository ownership, testing records, incident-response records, and change-management records as triage evidence before suppressing or downgrading offenses.

‍ ‍

· Validate QRadar log-source parsing, DSM mappings, custom properties, reference sets, offense rules, event-name normalization, command-line capture, and endpoint-to-identity correlation before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to AI coding-assistant child-process execution from abnormal launch or user-interaction context.

‍ ‍

· The rule remains useful if the specific Claude Code deeplink settings-injection path changes but the attacker still causes an AI coding assistant to launch execution-capable utilities.

‍ ‍

· The score is supported by endpoint process lineage, command-line visibility, launch context, child-process category, working-directory context, file activity, network activity, credential-access behavior, and correlation with identity, repository, CI/CD, or cloud telemetry.

‍ ‍

· The score is constrained by QRadar log-source normalization quality, custom-property extraction, command-line capture gaps, legitimate developer automation, expected build activity, approved hooks, package-manager workflows, incomplete launch-context telemetry, and environment-specific AI coding-assistant usage patterns.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on endpoint telemetry ingestion, process lineage fidelity, command-line capture, QRadar DSM parsing, custom-property extraction, developer workstation tagging, Claude Code process mapping, and child-process baseline quality.

‍ ‍

· Operational confidence is reduced where developers routinely use AI coding assistants to invoke shells, package managers, build tools, local servers, Git clients, or cloud CLIs as part of sanctioned workflows.

‍ ‍

· Operational confidence is reduced where launch-context telemetry, URI-handler telemetry, command-line capture, custom properties, or approved automation records are incomplete.

‍ ‍

· Full-telemetry confidence improves when child-process activity is correlated with settings or hook changes, file events, network events, blocked control events, credential-access behavior, identity-provider records, repository activity, CI/CD activity, cloud activity, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong SIEM-level evidence of suspicious local execution but should still be correlated before classifying activity as confirmed exploitation.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious AI coding-assistant child-process execution, not successful Claude Code exploitation by itself.

‍ ‍

· AI coding assistants may legitimately spawn shells, interpreters, package managers, build tools, Git clients, local servers, and cloud CLIs during normal development.

‍ ‍

· The rule requires tuning by operating system, user role, repository, language ecosystem, and workstation class.

‍ ‍

· Missing command-line capture may reduce confidence in command-risk assessment.

‍ ‍

· Missing URI-handler, browser, email, chat, documentation, or collaboration-platform telemetry may reduce confidence in the initial external influence point.

‍ ‍

· Missing file or network telemetry may reduce confidence in whether execution followed settings or hook activity.

‍ ‍

· Missing QRadar custom-property extraction may prevent reliable offense correlation.

‍ ‍

· The rule may miss attacks that avoid obvious child processes, use approved automation, abuse already running processes, or operate through common developer tools.

‍ ‍

· Confirmation requires correlation with launch context, configuration activity, credential access, network behavior, repository activity, CI/CD activity, cloud activity, or other endpoint evidence.

‍ ‍

Detection Query Pattern

‍ ‍

QRadar behavioral correlation query pattern requiring platform syntax validation, log-source validation, DSM validation, custom-property extraction, reference-set population, Claude Code process mapping, AI coding-assistant executable validation, child-process category validation, developer workstation tagging, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

· Identify creation, modification, access, deletion, or rollback activity involving Claude Code settings, AI coding-assistant settings, hook files, project-local configuration, workspace-local configuration, startup automation, or trusted-workspace artifacts.

‍ ‍

· Prioritize file and configuration activity that occurs shortly before or during Claude Code or comparable AI coding-assistant session start.

‍ ‍

· Prioritize configuration content, file path, operation type, or file-content risk associated with shell execution, script execution, network retrieval, package-manager invocation, credential access, environment-variable access, startup automation, or persistence-capable behavior.

‍ ‍

· Increase confidence when configuration activity is followed by child-process creation from Claude Code or comparable AI coding assistants.

‍ ‍

· Increase confidence when configuration activity occurs in a newly cloned, externally sourced, unusual, or previously trusted repository shortly after external link interaction, repository-reference interaction, documentation interaction, issue interaction, pull-request interaction, or README interaction.

‍ ‍

· Increase confidence when the child process launched after configuration activity performs encoded execution, inline execution, remote retrieval, credential-store access, SSH material access, environment-file access, package-registry token access, or cloud credential access.

‍ ‍

· Increase confidence when configuration activity is followed by outbound communication, blocked command execution, blocked script execution, blocked network retrieval, or EDR behavioral detection.

‍ ‍

· Increase confidence when similar settings or hook activity appears across multiple developer workstations, repositories, or users.

‍ ‍

· Reduce severity for known approved hooks, approved project automation, documented repository bootstrap scripts, expected build scripts, approved security testing, incident-response activity, and sanctioned developer workflows.

‍ ‍

· Do not treat settings or hook changes as compromise evidence by themselves.

‍ ‍

· Do not use static proof-of-concept strings as the primary detection condition.

‍ ‍

Required Telemetry

‍ ‍

· Endpoint file events.

‍ ‍

· Endpoint process events.

‍ ‍

· EDR events.

‍ ‍

· File creation events.

‍ ‍

· File modification events.

‍ ‍

· File deletion events where available.

‍ ‍

· File access events where available.

‍ ‍

· Parent-child process lineage.

‍ ‍

· Full command-line capture.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· File path.

‍ ‍

· File name.

‍ ‍

· File hash where available.

‍ ‍

· File operation type.

‍ ‍

· Repository or workspace path context where available.

‍ ‍

· Claude Code settings-path mapping.

‍ ‍

· Claude Code hook-path mapping.

‍ ‍

· AI coding-assistant configuration-path mapping.

‍ ‍

· Project-local configuration-path mapping.

‍ ‍

· Workspace-local configuration-path mapping.

‍ ‍

· Startup automation and persistence-path mapping.

‍ ‍

· File-content-risk enrichment where available.

‍ ‍

· Network events where available.

‍ ‍

· QRadar asset profiles for developer workstations.

‍ ‍

· QRadar reference sets for settings paths, hook paths, configuration paths, AI coding-assistant processes, and approved automation.

‍ ‍

· QRadar custom properties for file path, file action, file content risk, parent process, command line, working directory, and repository path.

‍ ‍

· Identity, repository, CI/CD, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Normalize endpoint file telemetry across Windows, macOS, and Linux developer workstations before enabling production offense generation.

‍ ‍

· Identify Claude Code settings locations, hook locations, project-local configuration locations, workspace-local configuration locations, and trusted-workspace artifacts.

‍ ‍

· Build QRadar reference sets for AI coding-assistant settings paths, hook paths, workspace configuration paths, project-local configuration paths, startup automation paths, persistence-capable paths, developer workstations, and approved automation.

‍ ‍

· Build approved automation inventories for sanctioned hooks, repository bootstrap scripts, build scripts, local developer tooling, security automation, and incident-response tooling.

‍ ‍

· Extract custom properties for file path, file action, file content risk, parent process, process name, command line, working directory, repository path, user identity, and host identity.

‍ ‍

· Correlate configuration file activity with Claude Code or comparable AI coding-assistant process start, session start, child-process creation, command execution, network communication, blocked execution, and credential-access behavior.

‍ ‍

· Use shorter rule tests for settings or hook modification followed by immediate child-process creation or blocked execution.

‍ ‍

· Use moderate rule tests for repository-open activity followed by configuration evaluation and command execution.

‍ ‍

· Use longer rule tests for delayed hook execution, trusted-workspace reuse, repository switching, or repeated configuration activity across multiple developer workstations.

‍ ‍

· Tune offense severity based on file path sensitivity, operation type, command-capable content, child-process category, user role, repository sensitivity, host sensitivity, and downstream network or credential behavior.

‍ ‍

· Avoid broad suppression for repository-local configuration because attacker-controlled and legitimate project automation may use similar paths.

‍ ‍

· Use repository ownership, approved automation documentation, change-management records, testing records, and incident-response records as triage evidence before suppressing alerts.

‍ ‍

· Validate QRadar log-source parsing, DSM mappings, custom properties, file-path normalization, operating-system path differences, approved automation lists, reference sets, and endpoint-to-SIEM joins before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

· The rule is behaviorally anchored to settings, hook, and workspace-configuration activity followed by AI coding-assistant execution.

‍ ‍

· The rule remains useful if the specific deeplink settings-injection flaw changes but attackers continue to abuse configuration, hooks, startup automation, or trusted-workspace behavior.

‍ ‍

· The score is supported by file activity, process lineage, command-line telemetry, child-process execution, working-directory context, EDR behavioral detections, file-content-risk enrichment, and correlation with network or credential activity.

‍ ‍

· The score is constrained by file-path normalization challenges, QRadar custom-property extraction, legitimate project automation, approved hooks, repository bootstrap scripts, build tooling, file-path variation across platforms, incomplete file-content-risk enrichment, and incomplete approved-automation inventories.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

· Operational confidence depends on accurate settings-path mapping, hook-path mapping, file telemetry ingestion, process lineage fidelity, command-line capture, developer workstation tagging, QRadar custom properties, and approved automation baselines.

‍ ‍

· Operational confidence is reduced where repositories routinely use hooks, bootstrap scripts, local automation, or workspace-specific configuration without centralized documentation.

‍ ‍

· Operational confidence is reduced where file telemetry does not capture enough path, operation, user, working-directory, repository context, or file-content risk.

‍ ‍

· Full-telemetry confidence improves when configuration activity is correlated with child-process execution, command-line content, network telemetry, blocked control events, credential-access behavior, identity-provider telemetry, repository activity, CI/CD activity, cloud telemetry, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of configuration-triggered execution risk, but confirmed compromise still requires execution and impact corroboration.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious configuration and hook activity followed by execution, not successful exploitation by itself.

‍ ‍

· Legitimate repositories may use settings, hooks, bootstrap scripts, package scripts, local configuration, and startup automation.

‍ ‍

· File path variation across operating systems and developer-tool versions may affect coverage.

‍ ‍

· Missing file telemetry may prevent visibility into settings or hook changes.

‍ ‍

· Missing command-line capture may reduce confidence in whether the resulting execution was suspicious.

‍ ‍

· Missing file-content-risk enrichment may require more reliance on process and timing correlation.

‍ ‍

· Missing QRadar custom-property extraction may prevent reliable file-to-process correlation.

‍ ‍

· Approved automation inventories may be incomplete or stale.

‍ ‍

· The rule may miss attacks that do not modify files, operate through pre-existing trusted configuration, or abuse already approved automation.

‍ ‍

· Confirmation requires correlation with child-process execution, command behavior, blocked controls, network activity, credential access, identity anomalies, repository activity, CI/CD activity, or cloud telemetry.

‍ ‍

Detection Query Pattern

‍ ‍

QRadar behavioral correlation query pattern requiring platform syntax validation, log-source validation, DSM validation, custom-property extraction, file-path normalization, reference-set population, settings-path mapping, hook-path mapping, workspace-configuration validation, developer workstation tagging, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

· Identify Claude Code or comparable AI coding-assistant process trees on developer workstations.

‍ ‍

· Detect credential-access, persistence, outbound communication, staging, discovery, or lateral-movement behavior under the AI coding-assistant process tree or shortly after it.

‍ ‍

· Prioritize access to SSH keys, cloud credential files, environment files, package-registry tokens, repository secrets, signing material, local credential stores, CI/CD configuration, or secrets-management configuration.

‍ ‍

· Prioritize creation or modification of shell profiles, login items, launch agents, scheduled tasks, cron jobs, services, startup folders, persistence-capable scripts, hidden files, staging directories, or downloaded tools.

‍ ‍

· Prioritize outbound communication to rare, newly observed, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unusual cloud, or previously unseen destinations.

‍ ‍

· Increase confidence when the behavior follows suspicious AI coding-assistant child-process execution, settings or hook activity, deeplink or URI-handler context, externally delivered link interaction, repository-open activity, or blocked execution.

‍ ‍

· Increase confidence when behavior occurs from a developer workstation with access to sensitive repositories, CI/CD systems, package registries, signing keys, cloud credentials, secrets, production infrastructure, or security tooling.

‍ ‍

· Increase confidence when identity, repository, CI/CD, package-registry, cloud, or NDR telemetry shows unusual downstream activity after the endpoint event.

‍ ‍

· Reduce severity for approved developer tooling, documented build scripts, sanctioned credential helpers, approved cloud workflows, approved security testing, approved incident-response activity, and known endpoint-management activity.

‍ ‍

· Do not classify credential, persistence, or outbound behavior as confirmed Claude Code exploitation without corroborating AI coding-assistant execution context.

‍ ‍

· Do not suppress credential or persistence behavior broadly because developer environments may contain both legitimate automation and high-value attacker targets.

‍ ‍

Required Telemetry

‍ ‍

· Endpoint process events.

‍ ‍

· Process tree telemetry.

‍ ‍

· Parent-child process lineage.

‍ ‍

· Full command-line capture.

‍ ‍

· File events.

‍ ‍

· Credential-access behavior events.

‍ ‍

· Persistence behavior events.

‍ ‍

· Network events.

‍ ‍

· EDR behavioral detections.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· Process hash.

‍ ‍

· File path.

‍ ‍

· File operation type.

‍ ‍

· Destination domain.

‍ ‍

· Destination IP.

‍ ‍

· Destination reputation.

‍ ‍

· Destination category.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Credential-path mapping.

‍ ‍

· Persistence-path mapping.

‍ ‍

· SSH key path mapping.

‍ ‍

· Cloud credential path mapping.

‍ ‍

· Environment-file path mapping.

‍ ‍

· Package-registry token path mapping.

‍ ‍

· Repository secret path mapping.

‍ ‍

· CI/CD configuration path mapping.

‍ ‍

· Approved automation and credential-helper inventory.

‍ ‍

· QRadar asset profiles for developer workstations.

‍ ‍

· QRadar reference sets for AI coding-assistant processes, credential paths, persistence paths, approved automation, and approved credential-helper activity.

‍ ‍

· QRadar custom properties for process tree, parent process, child process, command line, file path, file action, destination reputation, credential path, and persistence path.

‍ ‍

· Identity, repository, CI/CD, package-registry, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Normalize process-tree telemetry across Windows, macOS, and Linux developer workstations before enabling production offense generation.

‍ ‍

· Build process tree mappings for Claude Code and comparable AI coding-assistant processes.

‍ ‍

· Build QRadar reference sets for credential stores, SSH material, cloud credentials, environment files, package-registry tokens, repository secrets, signing material, CI/CD configuration, secrets-management configuration, persistence paths, developer workstations, and approved automation.

‍ ‍

· Build monitored path groups for shell profiles, launch agents, login items, scheduled tasks, cron jobs, services, startup folders, persistence-capable scripts, temporary directories, hidden files, downloaded tools, and staging directories.

‍ ‍

· Extract custom properties for process tree, parent process, child process, command line, file path, file action, credential path, persistence path, destination reputation, user identity, and host identity.

‍ ‍

· Correlate AI coding-assistant process trees with credential access, persistence activity, outbound communication, staging, discovery, blocked controls, and EDR behavioral detections.

‍ ‍

· Use shorter rule tests for AI coding-assistant execution followed by credential access, persistence creation, outbound communication, or blocked control activity.

‍ ‍

· Use moderate rule tests for settings or hook activity followed by credential access, file staging, network retrieval, or identity activity.

‍ ‍

· Use longer rule tests for delayed persistence, token reuse, repository access, CI/CD activity, cloud access, or repeated endpoint behavior.

‍ ‍

· Tune offense severity based on credential type, file path sensitivity, persistence mechanism, destination reputation, user role, host sensitivity, repository sensitivity, workstation privilege level, and downstream identity or repository activity.

‍ ‍

· Avoid broad suppression for credential helpers, package managers, cloud CLIs, endpoint-management tools, or developer automation because attacker activity may use the same tools.

‍ ‍

· Use approved credential-helper inventories, repository automation records, cloud workflow records, testing records, incident-response records, and endpoint-management records as triage evidence before suppressing alerts.

‍ ‍

· Validate QRadar log-source parsing, DSM mappings, process-tree fidelity, credential-path mapping, persistence-path mapping, operating-system path differences, reference sets, custom properties, and endpoint-to-identity joins before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to post-execution credential, persistence, and outbound behavior after AI coding-assistant process activity.

‍ ‍

· The rule remains useful if the initial trigger changes but the attacker still uses the developer workstation to access credentials, establish persistence, stage files, or communicate outbound.

‍ ‍

· The score is supported by process tree lineage, credential path access, persistence path modification, outbound network behavior, EDR behavioral detections, working-directory context, and downstream identity or repository enrichment.

‍ ‍

· The score is constrained by QRadar log-source normalization quality, custom-property extraction, legitimate developer credential helpers, cloud CLIs, package managers, build scripts, endpoint-management tooling, and security tools that may access similar resources.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on process tree fidelity, credential-path mapping, persistence-path mapping, file telemetry, network telemetry, developer asset tagging, approved automation baselines, QRadar DSM parsing, and QRadar custom-property extraction.

‍ ‍

· Operational confidence is reduced where developer environments routinely access cloud credentials, SSH keys, package tokens, environment files, build secrets, or local credential stores through approved tooling.

‍ ‍

· Operational confidence is reduced where persistence or credential behavior is generated by endpoint-management, security tooling, backup tools, or sanctioned developer automation.

‍ ‍

· Full-telemetry confidence improves when endpoint behavior is correlated with settings or hook activity, child-process execution, blocked control events, identity-provider records, repository logs, CI/CD logs, package-registry logs, cloud-control-plane logs, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong escalation evidence for developer-workstation compromise assessment, especially when credential access or persistence follows suspicious AI coding-assistant execution.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious post-execution behavior after AI coding-assistant process activity, not successful exploitation by itself.

‍ ‍

· Developer tools may legitimately access credentials, environment files, SSH keys, package tokens, cloud credentials, or CI/CD configuration.

‍ ‍

· Endpoint-management, backup, security, and administrative tools may legitimately modify persistence-capable paths.

‍ ‍

· The rule requires accurate process tree lineage, path mapping, and QRadar custom-property extraction to avoid noisy results.

‍ ‍

· Missing file, network, or credential behavior telemetry may reduce confidence.

‍ ‍

· Missing QRadar custom-property extraction may reduce correlation reliability across process, file, credential, persistence, and network events.

‍ ‍

· The rule may miss attacks that avoid credential files, avoid persistence, use memory-only access, use existing sessions, or remain within approved developer workflows.

‍ ‍

· Confirmation requires correlation with suspicious AI coding-assistant context, command behavior, settings or hook activity, network activity, identity anomalies, repository activity, CI/CD activity, cloud telemetry, or forensic evidence.

‍ ‍

Detection Query Pattern

‍ ‍

QRadar behavioral escalation query pattern requiring platform syntax validation, log-source validation, DSM validation, custom-property extraction, process-tree mapping, AI coding-assistant process mapping, credential-path validation, persistence-path validation, reference-set population, developer workstation tagging, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

WHEN events are detected by one or more of these log sources:
Endpoint EDR
Endpoint Process Telemetry
Endpoint File Telemetry
Operating System Security Logs
AND when the source asset is contained in:
REFERENCE_SET("Developer Workstations")
AND when a related event occurred within ENV_AI_CODING_ASSISTANT_POST_EXECUTION_WINDOW where:
EventName IN (
    "Claude Code Process Started",
    "AI Coding Assistant Process Started",
    "AI Coding Assistant Child Process Created",
    "Shell Spawned By AI Coding Assistant",
    "Script Interpreter Spawned By AI Coding Assistant",
    "Network Utility Spawned By AI Coding Assistant",
    "Credential Utility Spawned By AI Coding Assistant",
    "Suspicious AI Coding Assistant Process Lineage",
    "Blocked Command Execution From AI Coding Assistant",
    "Claude Code Settings Modified",
    "Hook Configuration Modified",
    "Project Local Configuration Modified",
    "Workspace Local Configuration Modified"
)
AND when one or more of the following are true:
FilePath IN REFERENCE_SET("Developer Credential And Persistence Paths")
EventName IN (
    "Credential Access Behavior",
    "Persistence Behavior",
    "Discovery Behavior",
    "Suspicious File Staging",
    "Suspicious Network Retrieval",
    "Lateral Movement Behavior"
)
DestinationReputation IN (
    "high_risk",
    "suspicious",
    "rare",
    "newly_observed",
    "unknown"
)
AND when the event is not associated with:
REFERENCE_SET("Approved Developer Workflow")
REFERENCE_SET("Approved Build Or Release Activity")
REFERENCE_SET("Approved Security Testing")
REFERENCE_SET("Approved Incident Response Activity")
REFERENCE_SET("Approved Endpoint Management Activity")
REFERENCE_SET("Approved Credential Helper Activity")
CREATE offense indexed by:
SourceIP
DestinationHost
Username
ParentProcessName
ProcessName
FilePath

‍ ‍

SIGMA

‍ ‍

Detection Viability Assessment

‍ ‍

SIGMA has three rules for this EXP report.

‍ ‍

· SIGMA is viable as a portable detection-rule format for this report because the core behavior can be expressed through endpoint process creation, parent-child process lineage, command-line telemetry, file activity, and correlated endpoint context.

‍ ‍

· SIGMA is strongest where process creation telemetry, full command-line capture, file telemetry, host identity, user identity, working-directory context, and endpoint-to-SIEM normalization are available across Windows, macOS, and Linux developer workstations.

‍ ‍

· SIGMA can provide portable behavioral patterns for suspicious AI coding-assistant child-process execution, settings or hook activity followed by execution, and post-execution credential, persistence, or outbound behavior.

‍ ‍

· SIGMA is suitable for this behavior model because the strongest detection logic is behavior-led and can be translated across SIEM and EDR platforms after environment-specific field mapping.

‍ ‍

· SIGMA rules should not depend on public proof-of-concept payloads, exact deeplink fragments, exploit labels, vulnerable-version exposure alone, or Claude Code installation alone.

‍ ‍

· SIGMA detection content should be treated as portable detection logic that requires backend-specific conversion, field mapping, path validation, correlation support validation, and environment tuning before production deployment.

‍ ‍

Identify process creation where Claude Code or a comparable AI coding assistant is the parent process.

‍ ‍

· Detect child processes involving shell interpreters, scripting engines, package managers, network utilities, credential utilities, Git clients, cloud CLIs, build tools, local servers, persistence utilities, or administrative utilities.

‍ ‍

· Increase confidence when command-line arguments show encoded content, inline execution, remote retrieval, environment-variable access, credential-store access, SSH material access, token access, package installation, file-permission modification, or system modification.

‍ ‍

· Increase confidence when execution occurs in a newly opened, externally sourced, unusual, or temporary developer workspace.

‍ ‍

· Increase confidence when the process event occurs shortly after settings, hooks, project-local configuration, workspace-local configuration, startup automation, deeplink, URI-handler, external link, repository-reference, documentation, issue, pull-request, or README activity.

‍ ‍

· Increase confidence when the child process initiates outbound network communication or accesses credential material, repository secrets, package-registry tokens, cloud credential files, environment files, SSH keys, signing material, or CI/CD configuration.

‍ ‍

· Increase confidence when similar behavior appears across multiple developer workstations after shared repository, documentation, issue, pull-request, README, or link interaction.

‍ ‍

· Reduce severity for documented build workflows, approved repository automation, sanctioned hooks, expected package-manager activity, approved security testing, approved incident-response activity, and known developer automation.

‍ ‍

· Do not classify child-process execution as confirmed compromise without corroborating suspicious launch context, settings or hook activity, credential access, network activity, blocked control events, repository activity, CI/CD activity, identity events, or cloud activity.

‍ ‍

· Do not broadly suppress AI coding-assistant child-process activity because normal developer execution and attacker execution may use the same tools.

‍ ‍

Required Telemetry

‍ ‍

Endpoint process creation telemetry.

‍ ‍

· Parent process name.

‍ ‍

· Parent process path.

‍ ‍

· Child process name.

‍ ‍

· Child process path.

‍ ‍

· Full command line.

‍ ‍

· Process hash.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· Process start time.

‍ ‍

· Process tree or causal process lineage.

‍ ‍

· File telemetry where available.

‍ ‍

· Network telemetry where available.

‍ ‍

· Script execution telemetry where available.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Claude Code or comparable AI coding-assistant executable mapping.

‍ ‍

· Known-good developer automation allowlist.

‍ ‍

· Repository, user-role, host-role, and workstation-class context where available.

‍ ‍

· SIEM or EDR field normalization for parent process, child process, command line, working directory, user, host, and timestamp.

‍ ‍

· Identity, repository, CI/CD, package-registry, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Convert the SIGMA rule into the target SIEM or EDR query language only after validating supported fields and log-source mappings.

‍ ‍

· Normalize process telemetry across Windows, macOS, and Linux developer workstations.

‍ ‍

· Build process identity mappings for Claude Code and comparable AI coding-assistant executables.

‍ ‍

· Build high-risk child-process categories for shells, scripting engines, package managers, network utilities, credential utilities, Git clients, cloud CLIs, build tools, local servers, persistence utilities, and administrative utilities.

‍ ‍

· Build developer workstation asset groups and AI coding-assistant installed workstation groups in the target SIEM or EDR platform.

‍ ‍

· Tune child-process logic by operating system, user role, repository type, language ecosystem, host class, and workstation class.

‍ ‍

· Correlate SIGMA-derived alerts with settings, hook, project-local configuration, workspace-local configuration, startup automation, repository-open activity, deeplink or URI-handler context, and external link interaction where available.

‍ ‍

· Use shorter correlation windows for AI coding-assistant launch followed by immediate shell, interpreter, network utility, credential utility, or package-manager execution.

‍ ‍

· Use moderate correlation windows for settings or hook activity followed by child-process creation, outbound communication, credential access, or blocked execution.

‍ ‍

· Use longer correlation windows for delayed hook execution, trusted-workspace reuse, repeated child-process execution, or similar activity across multiple developer workstations.

‍ ‍

· Avoid broad allowlisting for shells, interpreters, package managers, Git clients, cloud CLIs, or build tools because these tools are both legitimate developer dependencies and common attacker execution paths.

‍ ‍

· Validate converted query syntax, field mappings, case sensitivity, platform path differences, process naming differences, and environment-specific allowlists before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to AI coding-assistant child-process creation, which is a durable detection point for this report’s execution model.

‍ ‍

· The rule remains useful if the specific Claude Code deeplink settings-injection path changes but the attacker still causes an AI coding assistant to launch execution-capable utilities.

‍ ‍

· The score is supported by portable process-lineage logic, command-line visibility, child-process category, working-directory context, file activity, network activity, and credential-access behavior.

‍ ‍

· The score is constrained by SIGMA conversion quality, SIEM-specific field availability, endpoint log-source differences, command-line capture gaps, path normalization differences, and legitimate developer automation.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on successful SIGMA conversion, process lineage fidelity, command-line capture, developer workstation tagging, Claude Code process mapping, child-process baseline quality, and SIEM normalization.

‍ ‍

· Operational confidence is reduced where the target platform does not preserve parent-child process lineage, command-line data, working directory, or reliable process naming.

‍ ‍

· Operational confidence is reduced where developers routinely use AI coding assistants to invoke shells, package managers, build tools, local servers, Git clients, or cloud CLIs as part of sanctioned workflows.

‍ ‍

· Full-telemetry confidence improves when SIGMA-derived process alerts are correlated with settings or hook changes, file telemetry, network telemetry, blocked control events, credential-access behavior, identity-provider records, repository activity, CI/CD activity, cloud activity, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong portable evidence of suspicious local execution but should still be correlated before classifying activity as confirmed exploitation.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious AI coding-assistant child-process behavior, not successful Claude Code exploitation by itself.

‍ ‍

· SIGMA conversion quality varies by SIEM, EDR, schema, log source, and backend query language.

‍ ‍

· AI coding assistants may legitimately spawn shells, interpreters, package managers, build tools, Git clients, local servers, and cloud CLIs during normal development.

‍ ‍

· Missing parent-child process lineage may prevent reliable attribution to Claude Code or comparable AI coding assistants.

‍ ‍

· Missing command-line capture may reduce confidence in command-risk assessment.

‍ ‍

· Missing file or network telemetry may reduce confidence in whether execution followed settings or hook activity.

‍ ‍

· The rule may miss attacks that avoid obvious child processes, use approved automation, abuse already running processes, or operate through common developer tools.

‍ ‍

· Confirmation requires correlation with launch context, configuration activity, credential access, network behavior, repository activity, CI/CD activity, cloud activity, or other endpoint evidence.

‍ ‍

Detection Query Pattern

‍ ‍

SIGMA behavioral process-creation pattern requiring backend conversion, field mapping validation, platform syntax validation, Claude Code process mapping, AI coding-assistant executable validation, child-process category validation, developer workstation tagging, operating-system normalization, and environment-specific allowlisting before production deployment.

‍ ‍

Identify file creation, modification, deletion, access, rename, or rollback activity involving Claude Code settings, AI coding-assistant settings, hook files, project-local configuration, workspace-local configuration, startup automation, or trusted-workspace artifacts.

‍ ‍

· Identify related child-process creation from Claude Code or comparable AI coding assistants within the defined correlation window.

‍ ‍

· Prioritize configuration activity associated with shell execution, script execution, network retrieval, package-manager invocation, credential access, environment-variable access, startup automation, or persistence-capable behavior.

‍ ‍

· Increase confidence when configuration activity occurs in a newly cloned, externally sourced, unusual, or previously trusted repository shortly after external link interaction, repository-reference interaction, documentation interaction, issue interaction, pull-request interaction, or README interaction.

‍ ‍

· Increase confidence when the child process launched after configuration activity performs encoded execution, inline execution, remote retrieval, credential-store access, SSH material access, environment-file access, package-registry token access, or cloud credential access.

‍ ‍

· Increase confidence when configuration activity is followed by outbound communication, blocked command execution, blocked script execution, blocked network retrieval, or EDR behavioral detection.

‍ ‍

· Increase confidence when similar settings or hook activity appears across multiple developer workstations, repositories, or users.

‍ ‍

· Reduce severity for known approved hooks, approved project automation, documented repository bootstrap scripts, expected build scripts, approved security testing, incident-response activity, and sanctioned developer workflows.

‍ ‍

· Do not treat settings or hook changes as compromise evidence by themselves.

‍ ‍

· Do not use static proof-of-concept strings as the primary detection condition.

‍ ‍

Required Telemetry

‍ ‍

Endpoint file telemetry.

‍ ‍

· Endpoint process telemetry.

‍ ‍

· File creation events.

‍ ‍

· File modification events.

‍ ‍

· File deletion events where available.

‍ ‍

· File access events where available.

‍ ‍

· Parent-child process lineage.

‍ ‍

· Full command-line capture.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· File path.

‍ ‍

· File name.

‍ ‍

· File hash where available.

‍ ‍

· File operation type.

‍ ‍

· Repository or workspace path context where available.

‍ ‍

· Claude Code settings-path mapping.

‍ ‍

· Claude Code hook-path mapping.

‍ ‍

· AI coding-assistant configuration-path mapping.

‍ ‍

· Project-local configuration-path mapping.

‍ ‍

· Workspace-local configuration-path mapping.

‍ ‍

· Startup automation and persistence-path mapping.

‍ ‍

· File-content-risk enrichment where available.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Approved hook and automation inventory where available.

‍ ‍

· SIEM or EDR field normalization for file path, file operation, parent process, child process, command line, user, host, and timestamp.

‍ ‍

· Identity, repository, CI/CD, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Treat this detection as a portable correlation pattern, not as a guaranteed single-rule SIGMA deployment.

‍ ‍

· If the target backend supports multi-event correlation, convert the pattern into a correlation rule joining file activity and later process execution by host, user, process tree, working directory, repository path, or time window.

‍ ‍

· If the target backend does not support multi-event correlation, deploy paired rules for configuration activity and AI coding-assistant child-process execution, then correlate those alerts in the SIEM or case-management workflow.

‍ ‍

· Normalize endpoint file telemetry across Windows, macOS, and Linux developer workstations.

‍ ‍

· Identify Claude Code settings locations, hook locations, project-local configuration locations, workspace-local configuration locations, and trusted-workspace artifacts.

‍ ‍

· Build path groups for AI coding-assistant settings, hooks, workspace configuration, project-local configuration, startup automation, and persistence-capable paths.

‍ ‍

· Build approved automation inventories for sanctioned hooks, repository bootstrap scripts, build scripts, local developer tooling, security automation, and incident-response tooling.

‍ ‍

· Correlate configuration file activity with Claude Code or comparable AI coding-assistant process start, session start, child-process creation, command execution, network communication, blocked execution, and credential-access behavior.

‍ ‍

· Use shorter correlation windows for settings or hook modification followed by immediate child-process creation or blocked execution.

‍ ‍

· Use moderate correlation windows for repository-open activity followed by configuration evaluation and command execution.

‍ ‍

· Use longer correlation windows for delayed hook execution, trusted-workspace reuse, repository switching, or repeated configuration activity across multiple developer workstations.

‍ ‍

· Avoid broad suppression for repository-local configuration because attacker-controlled and legitimate project automation may use similar paths.

‍ ‍

· Validate converted query syntax, file path normalization, field mappings, case sensitivity, platform path differences, process naming differences, approved automation lists, timing-window behavior, and environment-specific allowlists before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

7.5 / 10

‍ ‍

· The rule is behaviorally anchored to settings, hook, and workspace-configuration activity followed by AI coding-assistant execution.

‍ ‍

· The rule remains useful if the specific deeplink settings-injection flaw changes but attackers continue to abuse configuration, hooks, startup automation, or trusted-workspace behavior.

‍ ‍

· The score is supported by portable file-and-process correlation logic, file activity, process lineage, command-line telemetry, child-process execution, and working-directory context.

‍ ‍

· The score is constrained by SIGMA’s limited native multi-event correlation support, backend-specific conversion differences, legitimate project automation, file-path variation across platforms, incomplete file-content-risk enrichment, incomplete approved-automation inventories, and the need for SIEM-level correlation in many environments.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

6.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.0 / 10

‍ ‍

· Operational confidence depends on successful SIGMA conversion, settings-path mapping, hook-path mapping, file telemetry coverage, process lineage fidelity, command-line capture, developer workstation tagging, timing-window support, and approved automation baselines.

‍ ‍

· Operational confidence is reduced where the target backend cannot support reliable file-to-process correlation or timing-window logic.

‍ ‍

· Operational confidence is reduced where repositories routinely use hooks, bootstrap scripts, local automation, or workspace-specific configuration without centralized documentation.

‍ ‍

· Full-telemetry confidence improves when configuration activity is correlated with child-process execution, command-line content, network telemetry, blocked control events, credential-access behavior, identity-provider telemetry, repository activity, CI/CD activity, cloud telemetry, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this pattern provides useful portable evidence of configuration-triggered execution risk, but confirmed compromise still requires execution and impact corroboration.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious configuration and hook activity followed by execution, not successful exploitation by itself.

‍ ‍

· SIGMA correlation support varies by backend, and some platforms may require separate rules plus SIEM correlation searches.

‍ ‍

· Legitimate repositories may use settings, hooks, bootstrap scripts, package scripts, local configuration, and startup automation.

‍ ‍

· File path variation across operating systems and developer-tool versions may affect coverage.

‍ ‍

· Missing file telemetry may prevent visibility into settings or hook changes.

‍ ‍

· Missing command-line capture may reduce confidence in whether the resulting execution was suspicious.

‍ ‍

· Approved automation inventories may be incomplete or stale.

‍ ‍

· The rule may miss attacks that do not modify files, operate through pre-existing trusted configuration, or abuse already approved automation.

‍ ‍

· Confirmation requires correlation with child-process execution, command behavior, blocked controls, network activity, credential access, identity anomalies, repository activity, CI/CD activity, or cloud telemetry.

‍ ‍

Detection Query Pattern

‍ ‍

SIGMA portable file-and-process correlation pattern requiring backend conversion, field mapping validation, platform syntax validation, settings-path mapping, hook-path mapping, workspace-configuration validation, developer workstation tagging, operating-system normalization, timing-window support, and environment-specific allowlisting before production deployment.

‍ ‍

Identify Claude Code or comparable AI coding-assistant process trees on developer workstations.

‍ ‍

· Detect credential-access, persistence, outbound communication, staging, discovery, or lateral-movement behavior under the AI coding-assistant process tree or shortly after it.

‍ ‍

· Prioritize access to SSH keys, cloud credential files, environment files, package-registry tokens, repository secrets, signing material, local credential stores, CI/CD configuration, or secrets-management configuration.

‍ ‍

· Prioritize creation or modification of shell profiles, login items, launch agents, scheduled tasks, cron jobs, services, startup folders, persistence-capable scripts, hidden files, staging directories, or downloaded tools.

‍ ‍

· Prioritize outbound communication to rare, newly observed, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unusual cloud, or previously unseen destinations.

‍ ‍

· Increase confidence when the behavior follows suspicious AI coding-assistant child-process execution, settings or hook activity, deeplink or URI-handler context, externally delivered link interaction, repository-open activity, or blocked execution.

‍ ‍

· Increase confidence when behavior occurs from a developer workstation with access to sensitive repositories, CI/CD systems, package registries, signing keys, cloud credentials, secrets, production infrastructure, or security tooling.

‍ ‍

· Reduce severity for approved developer tooling, documented build scripts, sanctioned credential helpers, approved cloud workflows, approved security testing, approved incident-response activity, and known endpoint-management activity.

‍ ‍

· Do not classify credential, persistence, or outbound behavior as confirmed Claude Code exploitation without corroborating AI coding-assistant execution context.

‍ ‍

· Do not suppress credential or persistence behavior broadly because developer environments may contain both legitimate automation and high-value attacker targets.

‍ ‍

Required Telemetry

‍ ‍

Endpoint process telemetry.

‍ ‍

· Parent-child process lineage.

‍ ‍

· Full command-line capture.

‍ ‍

· File telemetry.

‍ ‍

· Credential-access behavior telemetry.

‍ ‍

· Persistence behavior telemetry.

‍ ‍

· Network telemetry where available.

‍ ‍

· EDR behavioral detections where available.

‍ ‍

· User identity.

‍ ‍

· Host identity.

‍ ‍

· Working directory.

‍ ‍

· Timestamp.

‍ ‍

· Process hash.

‍ ‍

· File path.

‍ ‍

· File operation type.

‍ ‍

· Destination domain where available.

‍ ‍

· Destination IP where available.

‍ ‍

· Destination reputation where available.

‍ ‍

· Developer workstation asset tagging.

‍ ‍

· Credential-path mapping.

‍ ‍

· Persistence-path mapping.

‍ ‍

· SSH key path mapping.

‍ ‍

· Cloud credential path mapping.

‍ ‍

· Environment-file path mapping.

‍ ‍

· Package-registry token path mapping.

‍ ‍

· Repository secret path mapping.

‍ ‍

· CI/CD configuration path mapping.

‍ ‍

· Approved automation and credential-helper inventory.

‍ ‍

· SIEM or EDR field normalization for process tree, file path, credential path, persistence path, user, host, and timestamp.

‍ ‍

· Identity, repository, CI/CD, package-registry, cloud, and NDR enrichment where available.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Treat this detection as a portable escalation pattern, not as a guaranteed single-rule SIGMA deployment.

‍ ‍

· If the target backend supports multi-event correlation, convert the pattern into a correlation rule joining AI coding-assistant process activity with credential access, persistence activity, suspicious outbound communication, or EDR behavioral detections by host, user, process tree, working directory, repository path, or time window.

‍ ‍

· If the target backend does not support multi-event correlation, deploy paired rules for AI coding-assistant process activity and credential, persistence, or outbound behavior, then correlate those alerts in the SIEM or case-management workflow.

‍ ‍

· Build process tree mappings for Claude Code and comparable AI coding-assistant processes across Windows, macOS, and Linux developer workstations.

‍ ‍

· Build monitored path groups for credential stores, SSH material, cloud credentials, environment files, package-registry tokens, repository secrets, signing material, CI/CD configuration, and secrets-management configuration.

‍ ‍

· Build monitored path groups for shell profiles, launch agents, login items, scheduled tasks, cron jobs, services, startup folders, persistence-capable scripts, temporary directories, hidden files, downloaded tools, and staging directories.

‍ ‍

· Correlate AI coding-assistant process trees with credential access, persistence activity, outbound communication, staging, discovery, blocked controls, and EDR behavioral detections.

‍ ‍

· Use shorter correlation windows for AI coding-assistant execution followed by credential access, persistence creation, outbound communication, or blocked control activity.

‍ ‍

· Use moderate correlation windows for settings or hook activity followed by credential access, file staging, network retrieval, or identity activity.

‍ ‍

· Use longer correlation windows for delayed persistence, token reuse, repository access, CI/CD activity, cloud access, or repeated endpoint behavior.

‍ ‍

· Avoid broad suppression for credential helpers, package managers, cloud CLIs, endpoint-management tools, or developer automation because attacker activity may use the same tools.

‍ ‍

· Validate converted query syntax, process tree fidelity, field mappings, credential-path mapping, persistence-path mapping, operating-system path differences, approved automation lists, timing-window behavior, and environment-specific allowlists before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

7.5 / 10

‍ ‍

· The rule is behaviorally anchored to post-execution credential, persistence, and outbound behavior after AI coding-assistant process activity.

‍ ‍

· The rule remains useful if the initial trigger changes but the attacker still uses the developer workstation to access credentials, establish persistence, stage files, or communicate outbound.

‍ ‍

· The score is supported by portable process tree logic, credential path access, persistence path modification, outbound network behavior, EDR behavioral detections, working-directory context, and downstream enrichment where available.

‍ ‍

· The score is constrained by SIGMA conversion quality, SIEM-specific field availability, limited native multi-event correlation, legitimate developer credential helpers, cloud CLIs, package managers, build scripts, endpoint-management tooling, and security tools that may access similar resources.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

6.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.0 / 10

‍ ‍

· Operational confidence depends on successful SIGMA conversion, process tree fidelity, credential-path mapping, persistence-path mapping, file telemetry, network telemetry, developer asset tagging, timing-window support, and approved automation baselines.

‍ ‍

· Operational confidence is reduced where the target backend cannot support reliable process-tree correlation, file-path monitoring, or timing-window logic.

‍ ‍

· Operational confidence is reduced where developer environments routinely access cloud credentials, SSH keys, package tokens, environment files, build secrets, or local credential stores through approved tooling.

‍ ‍

· Full-telemetry confidence improves when endpoint behavior is correlated with settings or hook activity, child-process execution, blocked control events, identity-provider records, repository logs, CI/CD logs, package-registry logs, cloud-control-plane logs, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this pattern provides useful portable escalation evidence for developer-workstation compromise assessment, especially when credential access or persistence follows suspicious AI coding-assistant execution.

‍ ‍

Limitations

‍ ‍

This rule detects suspicious post-execution behavior after AI coding-assistant process activity, not successful exploitation by itself.

‍ ‍

· SIGMA conversion quality varies by SIEM, EDR, schema, log source, and backend query language.

‍ ‍

· Some target platforms may not support process-tree, credential-path, persistence-path, or multi-event correlation without custom correlation searches.

‍ ‍

· Developer tools may legitimately access credentials, environment files, SSH keys, package tokens, cloud credentials, or CI/CD configuration.

‍ ‍

· Endpoint-management, backup, security, and administrative tools may legitimately modify persistence-capable paths.

‍ ‍

· Missing file, network, or credential behavior telemetry may reduce confidence.

‍ ‍

· The rule may miss attacks that avoid credential files, avoid persistence, use memory-only access, use existing sessions, or remain within approved developer workflows.

‍ ‍

· Confirmation requires correlation with suspicious AI coding-assistant context, command behavior, settings or hook activity, network activity, identity anomalies, repository activity, CI/CD activity, cloud telemetry, or forensic evidence.

‍ ‍

Detection Query Pattern

‍ ‍

SIGMA portable escalation pattern requiring backend conversion, field mapping validation, platform syntax validation, process-tree support, AI coding-assistant process mapping, credential-path validation, persistence-path validation, developer workstation tagging, operating-system normalization, timing-window support, and environment-specific allowlisting before production deployment.

‍ ‍

title: AI Coding Assistant Process Tree Followed By Credential Persistence Or Outbound Behavior
id: ENV-SIGMA-AI-CODING-ASSISTANT-POST-EXECUTION
status: experimental
description: Portable escalation pattern for credential access, persistence, staging, suspicious network retrieval, or related post-execution behavior after Claude Code or comparable AI coding-assistant process activity.
correlation: required
logsource:
category: process_creation
detection:
selection_ai_assistant_context:
    ParentImage|contains:
      - claude
      - claude-code
      - Claude Code
selection_post_execution_process:
    Image|endswith:
      - /ssh
      - /scp
      - /curl
      - /wget
      - /openssl
      - /security
      - /launchctl
      - /crontab
      - /bash
      - /zsh
      - /sh
      - /python
      - /node
      - \powershell.exe
      - \cmd.exe
selection_credential_or_persistence_paths:
    CommandLine|contains:
      - .ssh
      - credentials
      - token
      - secret
      - AWS_
      - GITHUB_TOKEN
      - NPM_TOKEN
      - id_rsa
      - known_hosts
      - launchctl
      - crontab
      - Startup
      - LaunchAgents
      - authorized_keys
filter_approved_context:
    ChangeContext|contains:
      - approved_developer_workflow
      - approved_build_or_release_activity
      - approved_security_testing
      - approved_incident_response_activity
      - approved_endpoint_management_activity
      - approved_credential_helper_activity
condition: selection_ai_assistant_context and selection_post_execution_process and selection_credential_or_persistence_paths and not filter_approved_context
fields:
- UtcTime
- Computer
- User
- ParentImage
- ParentCommandLine
- Image
- CommandLine
- CurrentDirectory
- Hashes
falsepositives:
- Approved credential helpers
- Approved cloud workflows
- Approved build or release activity
- Approved endpoint management activity
- Approved security testing
- Approved incident response activity
level: high

‍ ‍

YARA

‍ ‍

Detection Viability Assessment

‍ ‍

YARA has one supporting rule for this EXP report.

‍ ‍

· YARA is not viable as a primary detection-rule system for this report because the core detection problem is behavioral, endpoint-process based, configuration-sequence based, developer-workstation based, and downstream identity, repository, CI/CD, or cloud-exposure based rather than static-file or malware-signature based.

‍ ‍

· YARA cannot reliably detect local deeplink handling, URI-handler invocation, Claude Code settings interpretation, hook execution, child-process creation, process lineage, credential access, network activity, repository access, CI/CD activity, or cloud-control-plane exposure.

‍ ‍

· YARA is viable only as a supporting artifact-oriented hunting mechanism when suspicious Claude Code settings, hook files, workspace-local configuration, repository-local automation, staged scripts, or recovered artifacts are available for controlled scanning.

‍ ‍

· YARA should not be used to claim detection of successful Claude Code deeplink settings-injection exploitation, developer-workstation compromise, credential compromise, repository compromise, CI/CD compromise, or cloud compromise.

‍ ‍

· YARA should not rely on public proof-of-concept strings, exploit branding, CVE labels, deeplink fragments, researcher-specific examples, static payload fragments, or blog-language artifacts as the primary detection basis.

‍ ‍

· YARA may support controlled repository, workstation, or forensic artifact review when the rule is scoped to command-capable configuration patterns and correlated with endpoint, file, process, network, identity, repository, or CI/CD evidence.

‍ ‍

· Identify artifacts that appear to be Claude Code settings, Claude Code hook files, AI coding-assistant settings, AI coding-assistant hook files, workspace-local configuration, project-local configuration, startup automation, or related developer-workstation artifacts.

‍ ‍

· Prioritize artifacts containing command-capable automation patterns involving shell invocation, script interpreter invocation, network retrieval, package-manager execution, credential access, environment-variable access, SSH material access, token access, file-permission modification, or persistence-capable behavior.

‍ ‍

· Increase confidence when the artifact is found in a recently opened, externally sourced, unusual, newly cloned, or previously trusted repository associated with suspicious AI coding-assistant activity.

‍ ‍

· Increase confidence when the artifact was created, modified, accessed, or deleted near Claude Code execution, hook evaluation, child-process creation, blocked execution, or suspicious endpoint activity.

‍ ‍

· Increase confidence when similar artifacts appear across multiple developer workstations, repositories, users, or workspaces after shared documentation, issue, pull-request, README, repository, or link interaction.

‍ ‍

· Increase confidence when the artifact is associated with outbound communication, credential access, repository access, CI/CD interaction, cloud-control-plane activity, or suspicious identity events.

‍ ‍

· Reduce severity for documented repository bootstrap scripts, approved hooks, sanctioned developer automation, approved security testing, approved incident-response activity, and known build or release workflows.

‍ ‍

· Do not treat the presence of command-capable configuration as compromise evidence by itself.

‍ ‍

· Do not use public proof-of-concept payloads, exploit strings, deeplink fragments, researcher examples, exploit branding, or CVE labels as the primary detection logic.

‍ ‍

Required Telemetry

‍ ‍

· Collected file artifacts.

‍ ‍

· Repository file collections where authorized.

‍ ‍

· Developer workstation artifact collections where authorized.

‍ ‍

· Claude Code settings-path mapping.

‍ ‍

· Claude Code hook-path mapping.

‍ ‍

· AI coding-assistant settings-path mapping.

‍ ‍

· AI coding-assistant hook-path mapping.

‍ ‍

· Workspace-local configuration-path mapping.

‍ ‍

· Project-local configuration-path mapping.

‍ ‍

· Startup automation-path mapping.

‍ ‍

· File path.

‍ ‍

· File name.

‍ ‍

· File content.

‍ ‍

· File hash.

‍ ‍

· File creation time where available.

‍ ‍

· File modification time where available.

‍ ‍

· File owner or user context where available.

‍ ‍

· Repository or workspace context where available.

‍ ‍

· Endpoint file telemetry for correlation where available.

‍ ‍

· Endpoint process telemetry for correlation where available.

‍ ‍

· Network telemetry for correlation where available.

‍ ‍

· Identity, repository, CI/CD, package-registry, cloud, and NDR enrichment where available.

‍ ‍

· Approved hook and automation inventory.

‍ ‍

· Change-management, testing, incident-response, and approved automation context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Deploy this rule only for controlled hunting, forensic triage, repository review, or artifact-scanning workflows.

‍ ‍

· Do not deploy this rule as broad production scanning across all developer repositories, all home directories, all source trees, all package directories, or all temporary directories without tight scope and false-positive review.

‍ ‍

· Scope scanning to systems, repositories, workspaces, or artifact collections already associated with suspicious endpoint, SIEM, NDR, identity, repository, CI/CD, or cloud telemetry.

‍ ‍

· Validate Claude Code settings paths, hook paths, workspace paths, project-local configuration paths, startup automation paths, and artifact-collection sources before running scans.

‍ ‍

· Review approved repository automation, approved hooks, bootstrap scripts, build scripts, package scripts, security testing artifacts, incident-response tools, and endpoint-management tooling before classifying a match as suspicious.

‍ ‍

· Treat matches as triage leads requiring correlation with process lineage, command-line execution, file modification timing, network activity, credential access, repository activity, CI/CD activity, identity events, or cloud activity.

‍ ‍

· Tune string logic to reduce matches on generic development configuration, package scripts, test automation, build tooling, and legitimate hooks.

‍ ‍

· Avoid exact public proof-of-concept payloads, deeplink fragments, researcher-specific strings, exploit branding, or CVE labels as primary match conditions.

‍ ‍

· Validate YARA version compatibility, string behavior, regular-expression performance, path-scoping method, collection method, and scanning workflow before operational use.

‍ ‍

· Store reviewed matches with artifact hash, path, host, user, repository, timestamp, and correlated investigation context.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

6.0 / 10

‍ ‍

· The rule is aligned with command-capable Claude Code settings, hook, and workspace artifacts, but YARA can only inspect static artifact content.

‍ ‍

· The rule remains useful for controlled hunting if suspicious artifacts are recovered from a workstation, repository, workspace, or forensic collection.

‍ ‍

· The score is supported by artifact path context, command-capable configuration patterns, file hash, repository context, modification timing, and correlation with endpoint or SIEM evidence.

‍ ‍

· The score is constrained by YARA’s inability to observe process execution, deeplink invocation, settings interpretation, hook runtime behavior, network activity, credential access, identity events, repository activity, CI/CD activity, or cloud activity.

‍ ‍

· The score is also constrained by high false-positive potential in developer environments where legitimate hooks, package scripts, bootstrap scripts, and local automation may contain command-capable patterns.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

4.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

6.0 / 10

‍ ‍

· Operational confidence is limited because YARA provides artifact-level matching, not behavioral confirmation.

‍ ‍

· Operational confidence depends on tight scan scope, validated artifact paths, approved automation inventories, file collection quality, repository context, and analyst review.

‍ ‍

· Operational confidence is reduced when scanning broad developer directories, source repositories, package trees, build directories, temporary directories, or home directories without context.

‍ ‍

· Full-telemetry confidence improves when a YARA match is correlated with endpoint process lineage, settings or hook modification timing, child-process creation, network activity, credential access, identity-provider events, repository logs, CI/CD logs, cloud-control-plane logs, and NDR telemetry.

‍ ‍

· Even under full telemetry conditions, this rule should support triage and scoping rather than serve as standalone confirmation of exploitation or compromise.

‍ ‍

Limitations

‍ ‍

· This rule does not detect live deeplink handling, URI-handler invocation, Claude Code runtime behavior, hook execution, process lineage, child-process creation, credential access, network activity, identity activity, repository activity, CI/CD activity, or cloud activity.

‍ ‍

· Legitimate developer automation may contain shell commands, package-manager commands, network retrieval commands, environment-variable references, hook logic, and startup automation.

‍ ‍

· Broad scanning of repositories or developer workstations may create high false-positive volume.

‍ ‍

· Attackers may avoid static command patterns, split logic across files, use benign-looking wrappers, use encoded content, or rely on pre-existing approved automation.

‍ ‍

· Static strings may become brittle if based on public proof-of-concept artifacts, researcher examples, exploit branding, or CVE labels.

‍ ‍

· YARA matches require analyst review and correlation with endpoint, file, process, network, identity, repository, CI/CD, or cloud telemetry.

‍ ‍

· This rule should not be used as a primary S25 detection method for the report.

‍ ‍

· This rule should not be used to infer successful exploitation or compromise without independent behavioral evidence.

‍ ‍

Detection Query Pattern

‍ ‍

YARA artifact-oriented hunting pattern requiring path scoping, artifact validation, approved automation review, YARA-version validation, performance testing, repository context, workstation context, and correlation with endpoint or SIEM evidence before operational use.

‍ ‍

rule Suspicious_Claude_Code_Settings_Or_Hook_Command_Automation
{
    meta:
        description = "Supports controlled hunting for Claude Code or AI coding-assistant settings, hook, or workspace artifacts containing command-capable automation patterns."
        author = "CyberDax"
        status = "experimental"
        scope = "controlled artifact hunting only"
        confidence = "supporting triage indicator"
        limitation = "does not confirm exploitation or compromise"

    strings:
        $context_1 = "claude" nocase
        $context_2 = "claude-code" nocase
        $context_3 = "hook" nocase
        $context_4 = "settings" nocase
        $context_5 = "workspace" nocase

        $exec_1 = "bash" nocase
        $exec_2 = "zsh" nocase
        $exec_3 = "powershell" nocase
        $exec_4 = "pwsh" nocase
        $exec_5 = "cmd.exe" nocase
        $exec_6 = "python" nocase
        $exec_7 = "node" nocase

        $retrieval_1 = "curl" nocase
        $retrieval_2 = "wget" nocase
        $retrieval_3 = "Invoke-WebRequest" nocase
        $retrieval_4 = "fetch(" nocase

        $credential_1 = "GITHUB_TOKEN" nocase
        $credential_2 = "NPM_TOKEN" nocase
        $credential_3 = "AWS_ACCESS_KEY" nocase
        $credential_4 = "credentials" nocase
        $credential_5 = ".ssh" nocase
        $credential_6 = "id_rsa" nocase
        $credential_7 = "secret" nocase
        $credential_8 = "token" nocase

        $automation_1 = "command" nocase
        $automation_2 = "script" nocase
        $automation_3 = "startup" nocase
        $automation_4 = "hook" nocase

    condition:
        filesize < 2MB and
        (
            2 of ($context_*) or
            1 of ($context_*) and 1 of ($automation_*)
        ) and
        (
            2 of ($exec_*) or
            1 of ($exec_*) and 1 of ($retrieval_*) or
            1 of ($exec_*) and 1 of ($credential_*) or
            1 of ($retrieval_*) and 1 of ($credential_*)
        )
}

‍ ‍

AWS

‍ ‍

Detection Viability Assessment

‍ ‍

AWS has zero primary rules for this EXP report.

‍ ‍

· AWS is not viable as a primary detection-rule system for this report because the core detection problem occurs on the developer workstation before AWS telemetry would normally observe the activity.

‍ ‍

· AWS does not directly observe local Claude Code deeplink handling, URI-handler invocation, settings interpretation, hook execution, workspace-local configuration evaluation, endpoint process lineage, child-process creation, local credential access, or developer workstation command execution.

‍ ‍

· AWS telemetry becomes relevant only if suspicious local execution leads to downstream AWS activity, such as credential use, STS activity, role assumption, CloudTrail-recorded API calls, Secrets Manager access, Systems Manager Parameter Store access, S3 access, IAM modification, Lambda interaction, container-registry activity, build-system interaction, deployment activity, or cloud-control-plane abuse.

‍ ‍

· AWS should not be used to claim detection of successful Claude Code deeplink settings-injection exploitation unless endpoint, SIEM, identity, repository, CI/CD, or forensic evidence already establishes the developer-workstation execution chain.

‍ ‍

· AWS rules focused only on AWS API calls would miss the initial execution path and may overstate cloud detection coverage for a primarily endpoint-driven behavior.

‍ ‍

· AWS rules based only on Claude Code version exposure, public proof-of-concept strings, deeplink fragments, exploit labels, local workstation behavior, or developer endpoint activity are not viable because those indicators are not native AWS control-plane observations.

‍ ‍

· AWS detection content should be handled as conditional downstream cloud-exposure monitoring, not as primary S25 detection for the initial behavior.

‍ ‍

· AWS should not receive a primary S25 rule unless the report scope shifts from developer-workstation execution risk to confirmed or strongly suspected AWS credential misuse, AWS control-plane abuse, AWS-hosted CI/CD compromise, or AWS-hosted downstream impact.

‍ ‍

Limited Operational Use

‍ ‍

· AWS CloudTrail may help determine whether a potentially affected developer identity, access key, session token, assumed role, or federated session was used after suspicious local execution.

‍ ‍

· AWS IAM Access Analyzer, IAM credential reports, GuardDuty, CloudTrail Lake, Security Hub, Detective, and SIEM-ingested AWS logs may support downstream exposure assessment after endpoint or SIEM telemetry identifies suspicious AI coding-assistant activity.

‍ ‍

· AWS Secrets Manager, Systems Manager Parameter Store, KMS, S3, ECR, CodeBuild, CodePipeline, Lambda, STS, IAM, CloudFormation, and related service logs may help determine whether cloud resources were accessed, modified, enumerated, or abused after developer-workstation compromise.

‍ ‍

· AWS telemetry may support containment decisions involving access-key rotation, session revocation, IAM policy review, role trust review, secret rotation, build-system review, deployment review, and cloud-control-plane investigation.

‍ ‍

· AWS detections may be useful in later defensive-control, exposure-assessment, incident-response, or cloud-hardening sections when framed as downstream monitoring after endpoint compromise.

‍ ‍

· AWS should be correlated with endpoint process lineage, file and configuration telemetry, SIEM correlation, identity-provider logs, repository logs, CI/CD logs, package-registry logs, and NDR telemetry before assigning cloud activity to this behavior model.

‍ ‍

· AWS should not be used as a substitute for endpoint process telemetry, command-line capture, file telemetry, Claude Code settings or hook visibility, URI-handler telemetry, or AI coding-assistant process-tree monitoring.

‍ ‍

· AWS should not receive a report-ready S25 primary detection rule unless the report scope shifts to confirmed AWS credential misuse, AWS control-plane abuse, AWS CI/CD compromise, or AWS-hosted downstream impact.

‍ ‍

Final Outcome

‍ ‍

No AWS primary rules survive.

‍ ‍

Azure

‍ ‍

Detection Viability Assessment

‍ ‍

Azure has zero primary rules for this EXP report.

‍ ‍

· Azure is not viable as a primary detection-rule system for this report because the core detection problem occurs on the developer workstation before Azure telemetry would normally observe the activity.

‍ ‍

· Azure does not directly observe local Claude Code deeplink handling, URI-handler invocation, settings interpretation, hook execution, workspace-local configuration evaluation, endpoint process lineage, child-process creation, local credential access, or developer workstation command execution unless endpoint telemetry is separately collected through Microsoft Defender for Endpoint or another integrated endpoint source.

‍ ‍

· Azure telemetry becomes relevant only if suspicious local execution leads to downstream Azure or Microsoft cloud activity, such as identity misuse, token abuse, conditional-access anomalies, Entra ID activity, Azure Resource Manager activity, Key Vault access, storage access, container-registry activity, DevOps activity, deployment activity, or cloud-control-plane abuse.

‍ ‍

· Azure should not be used to claim detection of successful Claude Code deeplink settings-injection exploitation unless endpoint, SIEM, identity, repository, CI/CD, or forensic evidence already establishes the developer-workstation execution chain.

‍ ‍

· Azure rules focused only on cloud-control-plane, identity, or Azure API activity would miss the initial execution path and may overstate cloud detection coverage for a primarily endpoint-driven behavior.

‍ ‍

· Azure rules based only on Claude Code version exposure, public proof-of-concept strings, deeplink fragments, exploit labels, local workstation behavior, or developer endpoint activity are not viable because those indicators are not native Azure control-plane observations.

‍ ‍

· Microsoft Defender for Endpoint and Microsoft Sentinel may provide strong endpoint or SIEM coverage when integrated, but those capabilities should be treated as endpoint or SIEM telemetry coverage rather than Azure-native primary S25 detection of the local execution chain.

‍ ‍

· Azure detection content should be handled as conditional downstream identity, device, cloud, and developer-platform exposure monitoring, not as primary S25 detection for the initial behavior.

‍ ‍

· Azure should not receive a primary S25 rule unless the report scope shifts from developer-workstation execution risk to confirmed or strongly suspected Azure credential misuse, Entra ID token abuse, Azure control-plane abuse, Azure DevOps compromise, or Azure-hosted downstream impact.

‍ ‍

Limited Operational Use

‍ ‍

· Microsoft Entra ID sign-in logs, audit logs, risk events, conditional-access events, and token-related identity telemetry may help determine whether a potentially affected developer identity, session, device, access token, refresh token, or federated session was used after suspicious local execution.

‍ ‍

· Azure Activity Logs, Azure Resource Manager logs, Microsoft Defender for Cloud, Microsoft Sentinel, Defender XDR, Azure Monitor, and SIEM-ingested Azure logs may support downstream exposure assessment after endpoint or SIEM telemetry identifies suspicious AI coding-assistant activity.

‍ ‍

· Azure Key Vault, Azure Storage, Azure Container Registry, Azure DevOps, GitHub Enterprise integrations, Azure Functions, App Service, AKS, managed identities, service principals, and deployment-pipeline telemetry may help determine whether cloud resources were accessed, modified, enumerated, or abused after developer-workstation compromise.

‍ ‍

· Azure telemetry may support containment decisions involving session revocation, token invalidation, password reset, device quarantine, service-principal review, managed-identity review, Key Vault secret rotation, conditional-access review, deployment review, and cloud-control-plane investigation.

‍ ‍

· Azure detections may be useful in later defensive-control, exposure-assessment, incident-response, or cloud-hardening sections when framed as downstream monitoring after endpoint compromise.

‍ ‍

· Azure should be correlated with endpoint process lineage, file and configuration telemetry, SIEM correlation, identity-provider logs, repository logs, CI/CD logs, package-registry logs, and NDR telemetry before assigning cloud activity to this behavior model.

‍ ‍

· Azure should not be used as a substitute for endpoint process telemetry, command-line capture, file telemetry, Claude Code settings or hook visibility, URI-handler telemetry, or AI coding-assistant process-tree monitoring.

‍ ‍

· Azure should not receive a report-ready S25 primary detection rule unless the report scope shifts to confirmed Azure credential misuse, Entra ID identity abuse, Azure control-plane abuse, Azure DevOps compromise, or Azure-hosted downstream impact.

‍ ‍

Final Outcome

‍ ‍

No Azure primary rules survive.

‍ ‍

GCP

‍ ‍

Detection Viability Assessment

‍ ‍

GCP has zero primary rules for this EXP report.

‍ ‍

· GCP is not viable as a primary detection-rule system for this report because the core detection problem occurs on the developer workstation before GCP telemetry would normally observe the activity.

‍ ‍

· GCP does not directly observe local Claude Code deeplink handling, URI-handler invocation, settings interpretation, hook execution, workspace-local configuration evaluation, endpoint process lineage, child-process creation, local credential access, or developer workstation command execution.

‍ ‍

· GCP telemetry becomes relevant only if suspicious local execution leads to downstream Google Cloud activity, such as Google Cloud credential use, service-account abuse, IAM activity, Cloud Audit Logs activity, Secret Manager access, Cloud Storage access, Artifact Registry activity, Cloud Build interaction, Cloud Deploy interaction, Cloud Run interaction, Kubernetes Engine activity, deployment activity, or cloud-control-plane abuse.

‍ ‍

· GCP should not be used to claim detection of successful Claude Code deeplink settings-injection exploitation unless endpoint, SIEM, identity, repository, CI/CD, or forensic evidence already establishes the developer-workstation execution chain.

‍ ‍

· GCP rules focused only on Google Cloud API activity, service-account use, IAM activity, Cloud Audit Logs events, or cloud-control-plane activity would miss the initial execution path and may overstate cloud detection coverage for a primarily endpoint-driven behavior.

‍ ‍

· GCP rules based only on Claude Code version exposure, public proof-of-concept strings, deeplink fragments, exploit labels, local workstation behavior, or developer endpoint activity are not viable because those indicators are not native GCP control-plane observations.

‍ ‍

· GCP service-account activity, workload-identity activity, Cloud Build activity, Artifact Registry activity, Secret Manager access, and Cloud Storage access may be important downstream exposure signals, but they are not primary evidence of the initial Claude Code execution chain.

‍ ‍

· GCP detection content should be handled as conditional downstream cloud, identity, service-account, build, deployment, and developer-platform exposure monitoring, not as primary S25 detection for the initial behavior.

‍ ‍

· GCP should not receive a primary S25 rule unless the report scope shifts from developer-workstation execution risk to confirmed or strongly suspected Google Cloud credential misuse, service-account abuse, GCP control-plane abuse, Cloud Build compromise, Artifact Registry compromise, or GCP-hosted downstream impact.

‍ ‍

Limited Operational Use

‍ ‍

· Google Cloud Audit Logs may help determine whether a potentially affected developer identity, service account, access token, refresh token, workload identity, service-account key, or federated session was used after suspicious local execution.

‍ ‍

· Google Cloud IAM, Security Command Center, Cloud Logging, Cloud Monitoring, Cloud Asset Inventory, Chronicle or SIEM-ingested GCP logs, organization policy telemetry, and VPC Service Controls logs may support downstream exposure assessment after endpoint or SIEM telemetry identifies suspicious AI coding-assistant activity.

‍ ‍

· GCP Secret Manager, Cloud Storage, Artifact Registry, Container Registry, Cloud Build, Cloud Deploy, Cloud Run, Cloud Functions, Kubernetes Engine, Compute Engine, IAM, and service-account telemetry may help determine whether cloud resources were accessed, modified, enumerated, or abused after developer-workstation compromise.

‍ ‍

· GCP telemetry may support containment decisions involving token revocation, service-account key review, key rotation, IAM policy review, workload identity review, secret rotation, build-system review, deployment review, repository-to-build trust review, artifact review, and cloud-control-plane investigation.

‍ ‍

· GCP detections may be useful in later defensive-control, exposure-assessment, incident-response, or cloud-hardening sections when framed as downstream monitoring after endpoint compromise.

‍ ‍

· GCP should be correlated with endpoint process lineage, file and configuration telemetry, SIEM correlation, identity-provider logs, repository logs, CI/CD logs, package-registry logs, and NDR telemetry before assigning cloud activity to this behavior model.

‍ ‍

· GCP should not be used as a substitute for endpoint process telemetry, command-line capture, file telemetry, Claude Code settings or hook visibility, URI-handler telemetry, or AI coding-assistant process-tree monitoring.

‍ ‍

· GCP should not receive a report-ready S25 primary detection rule unless the report scope shifts to confirmed Google Cloud credential misuse, service-account abuse, GCP control-plane abuse, Cloud Build compromise, Artifact Registry compromise, or GCP-hosted downstream impact.

‍ ‍

Final Outcome

‍ ‍

No GCP primary rules survive.

‍ ‍

S26 — Threat-to-Rule Traceability Matrix

Section Purpose

This section maps the modeled threat behavior to the S25 detection-rule coverage. The purpose is to show how the deployed and supporting rule logic traces back to the behavioral execution chain without claiming universal exploit detection, single-vulnerability-only coverage, or coverage in systems that cannot observe the relevant behavior.

Traceability Summary

· SentinelOne provides local endpoint execution context that can anchor cloud follow-on investigations.

· NDR may detect cloud-control-plane, API, or service communication from developer workstations when network telemetry is available.

· SIGMA and YARA do not provide primary cloud-control-plane coverage.

Coverage Assessment

Conditional coverage only. Cloud telemetry is valuable for impact assessment, but it does not prove the local Claude Code execution chain without endpoint or SIEM evidence.

Modeled Threat Behavior

Artifact Discovery During Forensic, Repository, or Workstation Review

Mapped Detection Coverage

· YARA supports controlled artifact triage for suspicious command-capable Claude Code settings, hook, workspace-local configuration, project-local configuration, or staged artifacts.

· SentinelOne, Splunk, Elastic, and QRadar provide stronger runtime correlation if file, process, network, and endpoint telemetry are available.

· SIGMA may provide portable file and process patterns when converted into backend-specific detections.

· NDR, AWS, Azure, and GCP do not provide primary artifact-scanning coverage.

Coverage Assessment

Limited supporting coverage. Artifact discovery is useful for triage and scoping, but it should not be treated as proof of execution or compromise without behavioral correlation.

Coverage Gaps

The S25 rule set intentionally avoids claiming coverage where the relevant telemetry does not exist.

· NDR does not directly observe local deeplink handling, settings interpretation, hook execution, or process lineage.

· YARA does not detect runtime behavior, process execution, credential access, network activity, identity activity, repository activity, CI/CD activity, or cloud activity.

· AWS, Azure, and GCP do not provide primary detection of local developer-workstation execution behavior.

· SIGMA portability depends on backend conversion quality, field availability, and correlation support.

· Splunk, Elastic, and QRadar coverage depends on normalized endpoint, file, identity, repository, CI/CD, cloud, and network telemetry.

· SentinelOne coverage depends on endpoint deployment, process lineage fidelity, command-line capture, file telemetry, and developer-workstation tagging.

· All rule systems require tuning to avoid false positives from legitimate developer automation, package-management activity, build tooling, hooks, cloud CLIs, source-control workflows, endpoint-management tools, and security testing.

Traceability Conclusion

The S25 rule set traces cleanly to the modeled behavior chain. The strongest rule coverage is concentrated where the behavior is most observable: developer endpoint process lineage, command-line execution, settings and hook file activity, credential-path access, persistence behavior, outbound communication, and SIEM correlation. Supporting systems extend visibility into network expansion, artifact triage, and downstream cloud exposure. AWS, Azure, and GCP are correctly excluded from primary-rule coverage for the initial local execution chain and reserved for downstream exposure assessment.

S27 — Behavior & Log Artifacts

Behavioral Artifact Overview

This section identifies the behavioral and log artifacts most likely to appear when externally influenced Claude Code or comparable AI coding-assistant activity crosses into local developer-workstation execution. These artifacts should be interpreted through correlation, not isolated matching. Normal developer activity frequently includes shells, package managers, Git clients, cloud CLIs, build tools, local servers, repository access, and outbound communication.

Primary Behavioral Artifacts

· Claude Code or a comparable AI coding assistant starts from a browser, chat client, email client, documentation platform, collaboration tool, IDE, terminal, deeplink handler, URI handler, or externally influenced workflow.

· Claude Code or a comparable AI coding assistant starts shortly after interaction with an externally supplied link, repository reference, documentation page, issue, pull request, README, message, or setup instruction.

· Settings, hooks, project-local configuration, workspace-local configuration, trusted-workspace artifacts, or startup automation are created, modified, accessed, evaluated, or removed near AI coding-assistant session start.

· Claude Code or a comparable AI coding assistant spawns a shell, scripting interpreter, package manager, network utility, credential utility, Git client, cloud CLI, build tool, local server, persistence utility, or administrative tool.

· Child-process execution occurs in a newly opened, externally sourced, unusual, temporary, or previously trusted workspace associated with suspicious user interaction.

· Suspicious execution is followed by outbound communication, credential access, repository access, CI/CD interaction, package-registry activity, cloud-control-plane access, staging, persistence, discovery, or identity-token use.

Endpoint Process Artifacts

· Process creation event for Claude Code or a comparable AI coding assistant.

· Parent process showing browser, chat, email, documentation, collaboration-tool, IDE, terminal, deeplink-handler, URI-handler, or user-facing application lineage.

· Child process launched by the AI coding assistant.

· Full command line for the AI coding assistant and child process.

· Working directory associated with the AI coding-assistant session.

· Process hash, executable path, user identity, host identity, timestamp, session context, and process tree identifier where available.

· Shell or interpreter execution involving Bash, Zsh, Sh, PowerShell, Pwsh, Cmd, Python, Node.js, Ruby, Perl, JavaScript runtimes, or other developer scripting environments.

· Package-management execution involving npm, npx, pnpm, yarn, pip, pip3, cargo, go, package-installation workflows, dependency installation, or build tooling.

· Network utility execution involving curl, wget, Invoke-WebRequest, Git, SSH, SCP, cloud CLIs, or other command-line retrieval tools.

· Command-line indicators involving encoded execution, inline shell execution, remote retrieval, environment-variable access, token access, SSH material access, credential-file access, file-permission modification, or system modification.

File and Configuration Artifacts

· Claude Code settings files created, modified, accessed, deleted, renamed, or rolled back.

· Claude Code hook files created, modified, accessed, deleted, renamed, or rolled back.

· AI coding-assistant settings, hook files, project-local configuration, workspace-local configuration, trusted-workspace artifacts, or startup automation files modified near session start.

· Repository-local files introducing command-capable automation, hook execution, suspicious install scripts, startup behavior, or unexpected developer-tool configuration.

· Shell profiles, login items, launch agents, scheduled tasks, cron jobs, services, startup folders, persistence-capable scripts, hidden files, staging directories, temporary files, downloaded tools, or local-server artifacts created after suspicious execution.

· Credential stores, SSH keys, cloud credential files, environment files, repository secrets, package-registry tokens, signing material, secrets-management configuration, or CI/CD configuration accessed after suspicious execution.

· Rapid create, modify, delete, rollback, cleanup, or rename activity involving settings, hooks, scripts, workspace configuration, or suspicious automation files.

Network and Outbound Artifacts

· DNS, proxy, firewall, EDR-network, NDR, or endpoint socket telemetry showing outbound communication after suspicious AI coding-assistant execution.

· Outbound communication from Claude Code, a shell, scripting interpreter, package manager, network utility, Git client, cloud CLI, build tool, or related child process.

· Destination domains, IPs, ASNs, cloud providers, hosting providers, VPN providers, tunnel providers, dynamic-DNS providers, paste services, file-sharing services, temporary-hosting services, or newly observed destinations contacted shortly after suspicious execution.

· Network retrieval followed by file creation, script execution, credential access, repository activity, package activity, CI/CD activity, or cloud-control-plane activity.

· Large, unusual, compressed, repeated, or timing-anomalous outbound transfers from a developer workstation after suspicious execution.

· Internal communication toward source-control systems, CI/CD systems, artifact repositories, package registries, secrets managers, administrative endpoints, build systems, deployment systems, cloud services, or security tooling after suspicious endpoint activity.

Identity and Access Artifacts

· Identity-provider sign-in events after suspicious developer-workstation execution.

· New session creation, token refresh, conditional-access anomaly, MFA anomaly, device-context change, geolocation change, ASN change, or sign-in risk event after the endpoint event.

· Unusual access to repositories, CI/CD systems, package registries, secrets managers, cloud consoles, deployment systems, signing infrastructure, security tooling, or administrative interfaces.

· Token use, SSH key use, deploy-key use, service-principal use, managed-identity use, service-account use, access-key use, refresh-token use, or federated-session activity after suspicious local execution.

· Developer account activity inconsistent with normal role, host, repository, device, location, time window, or workstation baseline.

Repository and CI/CD Artifacts

· Repository clone, fetch, branch access, repository enumeration, pull-request activity, issue activity, secret access, deploy-key use, SSH-key use, token use, or unusual source-control interaction after suspicious endpoint activity.

· CI/CD workflow access, pipeline trigger, job execution, runner interaction, build-secret access, artifact access, deployment job access, build-configuration change, or release-workflow interaction after suspicious endpoint activity.

· Package-registry reads, package publishing, token use, scope changes, ownership changes, package metadata changes, or automation changes after suspicious local execution.

· Repository, CI/CD, package-registry, or artifact activity from a developer identity, host, token, or session not normally associated with that workflow.

Cloud and Secrets Artifacts

· AWS, Azure, or GCP control-plane activity after suspicious developer-workstation execution.

· Cloud secret reads, credential use, role assumption, access-key creation, token exchange, service-account use, managed-identity use, service-principal use, IAM policy changes, storage access, build-system interaction, or deployment activity.

· Secrets Manager, Key Vault, GCP Secret Manager, Systems Manager Parameter Store, cloud storage, container registry, artifact registry, build service, deployment service, serverless function, Kubernetes, or cloud-control-plane interaction after suspicious endpoint activity.

· Cloud activity should be treated as downstream exposure evidence, not primary evidence of the initial local execution chain.

EDR and Control Artifacts

· EDR alert involving suspicious AI coding-assistant process lineage.

· Blocked command execution from a Claude Code or comparable AI coding-assistant process tree.

· Blocked script execution, blocked network retrieval, blocked credential access, blocked persistence activity, blocked child-process creation, or blocked local execution from an AI coding-assistant process tree.

· Application-control, script-control, exploit-prevention, constrained-language, or endpoint-protection events near suspicious AI coding-assistant execution.

· Crash, abnormal exit, parser error, malformed configuration handling, session-start failure, or repeated launch failure near link interaction, repository-open activity, or configuration evaluation.

Artifact Interpretation Guidance

· Treat isolated Claude Code execution as low-confidence without suspicious launch context, configuration activity, child-process behavior, or downstream activity.

· Treat isolated deeplink or URI-handler activity as low-confidence without configuration, process, or post-execution corroboration.

· Treat child-process execution as higher-confidence when it follows externally influenced invocation, settings or hook activity, suspicious working-directory context, or blocked-control events.

· Treat outbound communication as higher-confidence when it is process-attributed to the AI coding-assistant process tree or follows suspicious child-process execution.

· Treat credential, repository, CI/CD, package-registry, cloud, or identity activity as escalation evidence when it occurs after suspicious local execution.

· Treat YARA artifact matches as triage leads only.

· Treat AWS, Azure, and GCP telemetry as downstream exposure evidence only unless the report scope shifts to confirmed cloud compromise.

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

Implementation Objective

The SOC implementation objective is to detect and triage externally influenced AI coding-assistant activity that crosses into trusted local execution on a developer workstation. The implementation should prioritize behavioral convergence across invocation context, configuration activity, child-process execution, outbound communication, credential access, repository activity, CI/CD activity, identity activity, and downstream cloud exposure.

SOC Detection Strategy

· Prioritize endpoint process lineage as the primary source of truth.

· Use SIEM correlation to connect endpoint behavior with identity, repository, network, CI/CD, package-registry, and cloud telemetry.

· Treat NDR as supporting coverage for suspicious outbound communication and developer-workstation expansion.

· Treat YARA as controlled artifact triage only.

· Treat AWS, Azure, and GCP as downstream exposure telemetry only.

· Avoid payload-specific, proof-of-concept-specific, or vulnerable-version-only alerting as the primary production strategy.

· Build detections around durable behavior: abnormal AI coding-assistant invocation, settings or hook activity, suspicious child-process creation, outbound communication, credential access, persistence, repository access, CI/CD interaction, and cloud-control-plane exposure.

SOC Triage Priorities

Priority 1

AI coding-assistant execution from abnormal invocation context followed by shell, scripting-engine, package-manager, network-utility, credential-utility, Git, cloud CLI, build-tool, or administrative child-process execution.

Priority 2

Settings, hook, project-local configuration, workspace-local configuration, trusted-workspace artifact, or startup automation activity followed by AI coding-assistant child-process execution, blocked execution, outbound communication, credential access, or repository activity.

Priority 3

AI coding-assistant process tree followed by credential access, SSH material access, environment-file access, package-registry token access, cloud credential access, persistence activity, staging, or suspicious outbound communication.

Priority 4

Developer workstation communication with source-control, CI/CD, artifact, secrets, package-registry, build, deployment, security-tooling, administrative, or cloud-control infrastructure after suspicious AI coding-assistant activity.

Priority 5

Suspicious settings, hook, or command-capable configuration artifacts without confirmed execution.

Alert Enrichment Requirements

· Developer workstation classification.

· User role and privilege level.

· Repository sensitivity.

· CI/CD privilege and deployment scope.

· Cloud account or project sensitivity.

· Package-registry scope.

· Signing-key or release-engineering access.

· Endpoint process tree.

· Full command line.

· Working directory.

· File modification timeline.

· Network destination reputation, category, first-seen status, ASN, hosting provider, and domain age.

· Identity-provider session context.

· Source-control, CI/CD, package-registry, secrets-manager, and cloud-control-plane activity.

· Change-management, release, deployment, testing, incident-response, and approved automation context.

Initial Triage Workflow

· Confirm whether Claude Code or a comparable AI coding assistant executed on the affected workstation.

· Confirm parent process, launch path, user-facing application context, deeplink or URI-handler context, and timing.

· Confirm whether settings, hooks, project-local configuration, workspace-local configuration, trusted-workspace artifacts, or startup automation were accessed or modified near session start.

· Confirm whether the AI coding assistant spawned shells, interpreters, package managers, network utilities, credential utilities, Git clients, cloud CLIs, build tools, local servers, persistence utilities, or administrative tools.

· Review command-line content for encoded execution, inline execution, remote retrieval, credential access, environment-variable access, package installation, SSH material access, token references, file-permission changes, or system modification.

· Review working directory, repository path, workspace origin, repository trust state, and whether the project was newly opened, externally sourced, unusual, or previously trusted.

· Review network activity after suspicious execution for rare, newly observed, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unusual cloud, or previously unseen destinations.

· Review credential, repository, CI/CD, package-registry, cloud, and identity activity after the endpoint event.

· Determine whether activity is explained by approved development workflow, approved build activity, approved automation, approved security testing, approved incident-response activity, or documented repository behavior.

Escalation Criteria

· AI coding assistant spawned a shell, script interpreter, credential utility, network utility, cloud CLI, Git client, package manager, or persistence-capable process after externally influenced invocation.

· Settings, hooks, project-local configuration, workspace-local configuration, or startup automation changed immediately before suspicious execution.

· Suspicious child-process execution performed remote retrieval, encoded execution, credential access, environment-variable access, package installation, SSH material access, token access, or system modification.

· Suspicious execution was followed by outbound communication to rare, newly observed, low-reputation, temporary-hosting, tunneling, paste-service, file-sharing, dynamic-DNS, unusual cloud, or unknown external destinations.

· Suspicious execution was followed by access to credentials, SSH keys, environment files, package-registry tokens, repository secrets, signing material, CI/CD configuration, secrets managers, or cloud credentials.

· Suspicious execution was followed by repository enumeration, CI/CD interaction, package-registry activity, cloud-control-plane activity, unusual identity activity, token refresh anomaly, or privileged session activity.

· Similar behavior appeared across multiple developer workstations after shared repository, documentation, issue, pull-request, README, or link interaction.

· The affected developer or workstation has access to production repositories, signing keys, deployment systems, privileged cloud credentials, sensitive customer data, security tooling, or release-engineering workflows.

Containment Guidance

· Quarantine or isolate the affected developer workstation when suspicious local execution is confirmed or strongly suspected.

· Preserve endpoint telemetry, process trees, command lines, file artifacts, memory-relevant evidence where available, and network records before destructive remediation.

· Revoke or rotate exposed credentials, access tokens, package-registry tokens, SSH keys, cloud credentials, deploy keys, service-account keys, or signing material when access is suspected.

· Revoke active sessions and refresh tokens for the affected identity when identity exposure is plausible.

· Review source-control access, CI/CD workflows, package-registry activity, cloud-control-plane activity, and secret access after the endpoint event.

· Disable or restrict suspicious hooks, settings, startup automation, workspace-local configuration, or repository-local automation until validated.

· Review recent commits, pull requests, repository changes, build changes, package changes, deployment changes, and automation changes tied to the affected user, host, token, or workstation.

· Validate whether the suspicious workflow originated from external documentation, message content, issue comments, pull requests, README content, repository references, or shared links.

Tuning Guidance

· Baseline normal AI coding-assistant launch paths by user, role, host, repository, operating system, IDE, and workstation class.

· Baseline normal child-process behavior from Claude Code and comparable AI coding assistants.

· Baseline approved hooks, settings, startup automation, repository bootstrap scripts, package scripts, build scripts, local development servers, cloud CLI usage, Git usage, and package-manager workflows.

· Build narrow allowlists tied to specific repositories, users, hosts, automation patterns, and time windows.

· Avoid broad allowlisting for shells, interpreters, package managers, Git clients, cloud CLIs, CI/CD tools, developer SaaS, or trusted repositories.

· Maintain destination baselines for package registries, source-control providers, CI/CD systems, artifact repositories, secrets managers, documentation platforms, cloud providers, internal build systems, corporate proxies, developer SaaS, and security tooling.

· Tune severity based on process lineage, command-line risk, file-path sensitivity, repository sensitivity, user privilege, host sensitivity, destination reputation, destination novelty, credential access, downstream identity behavior, and cloud-control-plane activity.

· Revalidate tuning after tool updates, developer workflow changes, onboarding of new AI coding assistants, repository policy changes, CI/CD changes, and cloud-access changes.

SOC Ownership Guidance

· SOC owns alert triage, incident escalation, evidence preservation, and correlation across telemetry sources.

· Endpoint security owns endpoint telemetry quality, EDR response actions, file and process collection, workstation isolation, and endpoint control validation.

· Developer platform owns AI coding-assistant inventory, approved developer-tool usage, repository automation policy, hook governance, and workspace-trust guidance.

· Identity security owns session revocation, token invalidation, MFA review, conditional-access review, sign-in analysis, and privileged identity containment.

· Source-control owners own repository access review, deploy-key review, SSH-key review, branch activity review, commit review, and repository containment.

· CI/CD owners own pipeline review, runner review, build-secret review, artifact review, deployment review, and workflow containment.

· Cloud security owns AWS, Azure, and GCP exposure review when downstream cloud activity is observed.

· Incident response owns cross-functional coordination when local execution may have exposed source code, credentials, build systems, signing material, deployment infrastructure, or cloud assets.

Implementation Guardrails

· Do not treat Claude Code execution as suspicious by itself.

· Do not treat shell execution from developer tooling as malicious without context.

· Do not treat vulnerable-version exposure as compromise evidence.

· Do not treat deeplink or URI-handler activity as compromise evidence without configuration, process, or post-execution corroboration.

· Do not use proof-of-concept fragments, exploit strings, or exact payload syntax as primary production detection logic.

· Do not broadly suppress AI coding-assistant child-process activity across developer systems.

· Do not broadly allowlist trusted repositories because trusted-workspace reuse is part of the modeled risk.

· Do not use AWS, Azure, or GCP telemetry as primary proof of local execution.

· Do not use YARA matches as proof of runtime execution or compromise.

· Do not close alerts without checking downstream identity, repository, CI/CD, package-registry, and cloud exposure when suspicious local execution is confirmed.

S29 — Detection Coverage Summary

Coverage Summary

Detection coverage for this report is strongest where developer endpoint telemetry can be correlated with SIEM, NDR, identity, repository, CI/CD, package-registry, secrets-management, and cloud-control-plane telemetry. The highest-value coverage detects the transition from externally influenced AI coding-assistant activity into local command execution, then evaluates whether that execution created downstream developer-workstation or engineering-control-plane exposure.

Strongest Coverage Areas

· Abnormal Claude Code or comparable AI coding-assistant invocation from browser, chat, email, documentation, collaboration-tool, deeplink, URI-handler, repository-reference, issue, pull-request, README, or external-link context.

· AI coding-assistant process spawning shells, scripting interpreters, package managers, network utilities, credential utilities, Git clients, cloud CLIs, build tools, local servers, persistence utilities, or administrative tools.

· Settings, hooks, project-local configuration, workspace-local configuration, trusted-workspace artifacts, or startup automation modified near AI coding-assistant execution.

· AI coding-assistant process tree followed by credential access, persistence activity, staging, outbound communication, or suspicious endpoint behavior.

· Developer workstation egress following suspicious AI coding-assistant activity.

· Developer workstation expansion toward source-control, CI/CD, artifact, secrets, package-registry, build, deployment, administrative, security-tooling, or cloud-control infrastructure.

· SIEM correlation across endpoint, file, network, identity, repository, CI/CD, package-registry, cloud, and NDR telemetry.

Moderate Coverage Areas

· Deeplink or URI-handler activity when endpoint process lineage is available but user-interaction telemetry is incomplete.

· Settings or hook activity when file telemetry exists but file-content risk, command-line capture, or process-tree correlation is incomplete.

· Outbound communication when NDR, DNS, firewall, or proxy telemetry exists but process attribution is missing.

· Credential-path access when endpoint file telemetry exists but downstream identity, repository, CI/CD, or cloud misuse is not visible.

· Repository, CI/CD, package-registry, or cloud activity after suspicious endpoint behavior when identity-to-device correlation is incomplete.

· SIGMA-derived rules where backend conversion and field mapping are reliable but native multi-event correlation is limited.

Limited Coverage Areas

· YARA artifact discovery in controlled workstation, repository, or forensic collections.

· Suspicious command-capable settings, hook, workspace, or project-local artifacts without runtime execution evidence.

· Vulnerable-version exposure without suspicious invocation, configuration activity, process execution, or downstream behavior.

· Isolated deeplink activity without process, configuration, file, or post-execution evidence.

· Cloud-control-plane activity without endpoint or SIEM evidence connecting it to suspicious local execution.

· Network activity from common developer services without endpoint process correlation or destination-risk context.

No Primary Coverage Areas

· AWS does not provide primary coverage for local developer-workstation execution behavior.

· Azure does not provide primary coverage for local developer-workstation execution behavior.

· GCP does not provide primary coverage for local developer-workstation execution behavior.

· YARA does not provide primary coverage for runtime process behavior, credential access, network activity, identity activity, repository activity, CI/CD activity, or cloud activity.

· NDR does not directly observe local deeplink handling, settings interpretation, hook execution, process lineage, or local file evaluation.

· SIGMA does not guarantee uniform production coverage without backend-specific conversion, field mapping, and correlation support.

· Vulnerability-management data does not provide compromise detection without behavioral evidence.

System-Level Coverage Summary

NDR / Network Behavioral Analytics

NDR / Network Behavioral Analytics provides supporting coverage for suspicious outbound communication and downstream expansion from developer workstations. It is strongest when endpoint enrichment, process attribution, destination reputation, approved-destination baselines, developer-workstation asset tagging, identity telemetry, repository telemetry, CI/CD telemetry, package-registry telemetry, and cloud telemetry are available. It is not primary coverage for local execution.

SentinelOne

SentinelOne provides strong primary endpoint coverage for AI coding-assistant child-process execution, configuration-triggered execution, and post-execution credential, persistence, or outbound behavior. It is strongest when process lineage, command-line capture, file telemetry, network telemetry, EDR behavioral detections, developer workstation tagging, and endpoint-to-SIEM enrichment are available.

Splunk

Splunk provides strong SIEM correlation coverage across endpoint process telemetry, file telemetry, network telemetry, identity-provider logs, source-control logs, CI/CD logs, package-registry logs, cloud-control-plane logs, and EDR detections. It is strongest when event normalization, CIM mapping, source-type mapping, endpoint-to-identity joins, and environment-specific field validation are complete.

Elastic

Elastic provides strong endpoint-led and SIEM-supported coverage when Elastic Defend, process lineage, command-line capture, file telemetry, network events, ECS normalization, process entity IDs, developer-workstation tagging, and downstream enrichment are available. It is well suited for endpoint process sequencing, settings or hook correlation, and post-execution behavior detection.

QRadar

QRadar provides strong SIEM offense-correlation coverage when endpoint process events, file events, EDR events, network events, identity events, repository logs, CI/CD logs, cloud logs, reference sets, custom properties, and DSM mappings are correctly normalized. It is strongest when offense logic can tie AI coding-assistant activity to file, network, credential, persistence, identity, repository, and cloud events.

SIGMA

SIGMA provides portable detection logic for endpoint process behavior and portable correlation patterns for settings or hook activity and post-execution escalation. Coverage depends on backend conversion quality, field availability, process-lineage fidelity, command-line capture, path normalization, timing-window support, and SIEM-level correlation.

YARA

YARA provides limited supporting artifact-triage coverage for suspicious command-capable Claude Code settings, hook, workspace-local configuration, project-local configuration, or staged artifacts. It should not be used as primary detection and should not be interpreted as confirmation of runtime execution or compromise.

AWS

AWS provides no primary S25 rule coverage for the local execution chain. AWS is useful only for downstream exposure assessment when suspicious local execution may have led to AWS credential use, IAM activity, STS activity, CloudTrail-recorded API calls, Secrets Manager access, S3 access, ECR access, CodeBuild or CodePipeline activity, Lambda activity, KMS interaction, or CloudFormation activity.

Azure

Azure provides no primary S25 rule coverage for the local execution chain. Azure is useful only for downstream exposure assessment when suspicious local execution may have led to Entra ID activity, identity misuse, token abuse, conditional-access anomalies, Key Vault access, Azure Storage access, Azure Container Registry access, Azure DevOps activity, Defender XDR correlation, Microsoft Sentinel correlation, or Azure control-plane activity.

GCP

GCP provides no primary S25 rule coverage for the local execution chain. GCP is useful only for downstream exposure assessment when suspicious local execution may have led to Google Cloud credential use, service-account abuse, IAM activity, Cloud Audit Logs activity, Secret Manager access, Cloud Storage access, Artifact Registry activity, Cloud Build activity, Cloud Deploy activity, Cloud Run activity, Kubernetes Engine activity, or GCP control-plane abuse.

Coverage Dependencies

· Endpoint process lineage.

· Full command-line capture.

· File telemetry for settings, hooks, project-local configuration, workspace-local configuration, trusted-workspace artifacts, and persistence-capable paths.

· Developer workstation asset tagging.

· AI coding-assistant process mapping.

· Approved automation inventory.

· Process-aware network telemetry.

· DNS, proxy, firewall, EDR-network, and NDR telemetry.

· Identity-provider telemetry.

· Source-control telemetry.

· CI/CD telemetry.

· Package-registry telemetry.

· Secrets-management telemetry.

· Cloud-control-plane telemetry.

· Repository, host, user, role, privilege, and workstation baselines.

· Change-management, testing, incident-response, and approved automation context.

Coverage Limitations

· Coverage is reduced when parent-child process lineage is unavailable.

· Coverage is reduced when command-line capture is incomplete.

· Coverage is reduced when file telemetry does not cover settings, hooks, workspace configuration, or persistence-capable paths.

· Coverage is reduced when URI-handler or browser-to-local-application telemetry is unavailable.

· Coverage is reduced when network telemetry is not process-aware.

· Coverage is reduced when identity, repository, CI/CD, package-registry, secrets-management, or cloud telemetry is incomplete.

· Coverage is reduced when developer workflows are not baselined.

· Coverage is reduced when broad allowlists suppress shells, interpreters, package managers, Git clients, cloud CLIs, trusted repositories, or developer SaaS.

· Coverage is reduced when telemetry retention is too short to reconstruct link interaction, configuration evaluation, command execution, and downstream access.

Coverage Conclusion

The detection model provides strong coverage for the most important observable behavior: externally influenced AI coding-assistant activity leading to local developer-workstation execution and downstream exposure risk. Endpoint and SIEM systems provide the strongest rule coverage. NDR extends visibility into network activity and engineering-system expansion. YARA supports artifact triage. AWS, Azure, and GCP remain correctly scoped to downstream exposure assessment and do not provide primary detection of the initial local execution chain.

S30 — Intelligence Maturity Assessment

Overall Intelligence Maturity

The intelligence maturity for this report is moderate to high. The modeled behavior is sufficiently defined to support durable behavioral detection, but full maturity depends on endpoint process visibility, command-line capture, file telemetry, developer-workstation baselines, SIEM correlation, and downstream identity, repository, CI/CD, package-registry, secrets-management, and cloud telemetry.

Maturity Assessment

Moderate to High

Maturity Rationale

· The source behavior is specific enough to define a clear execution chain involving externally influenced AI coding-assistant invocation, settings or hook evaluation, local command execution, and downstream developer-workstation exposure.

· The detection model is behavior-led and remains useful beyond the specific Claude Code issue.

· The strongest detection points are observable in mature endpoint and SIEM environments.

· The model avoids dependence on static payloads, proof-of-concept strings, vulnerable-version exposure, or exact deeplink content.

· The primary maturity constraint is not intelligence clarity. The primary constraint is telemetry availability and operational correlation across endpoint, developer, identity, repository, CI/CD, package-registry, secrets-management, cloud, and network systems.

Collection Maturity

Moderate

· Endpoint process telemetry and command-line capture are the most important collection requirements.

· File telemetry for settings, hooks, workspace-local configuration, project-local configuration, trusted-workspace artifacts, and persistence-capable paths is required for strong detection confidence.

· Network telemetry improves post-execution assessment but is insufficient without endpoint context.

· Identity, repository, CI/CD, package-registry, secrets-management, and cloud telemetry are required to evaluate business impact and downstream exposure.

· URI-handler, browser-to-local-application, chat, email, documentation, and collaboration-platform telemetry may be incomplete in many environments.

· Collection maturity is reduced when developer workstations are unmanaged, lightly monitored, inconsistently tagged, or excluded from full endpoint telemetry.

Analytic Maturity

High

· The behavior chain supports durable analytic logic across multiple systems.

· The model clearly separates low-confidence exposure indicators from high-confidence execution behavior.

· The S25 rule set maps cleanly to major behavior stages: invocation, configuration activity, child-process execution, outbound communication, credential access, persistence, downstream engineering-system expansion, artifact triage, and downstream cloud exposure.

· The model distinguishes direct detection, supporting detection, conditional downstream monitoring, and non-coverage.

· The model is resilient to variant behavior because it focuses on trust-boundary crossing, configuration-triggered execution, child-process behavior, and post-execution impact rather than single exploit strings.

· Analytic maturity remains constrained by legitimate developer noise, approved automation, repository-local scripts, package-management behavior, cloud CLI activity, and variability across developer workstations.

Operational Maturity

Moderate

· SOC teams can operationalize the model when endpoint process lineage, command-line capture, file telemetry, and SIEM correlation are available.

· Operational maturity depends on clearly defined ownership across SOC, endpoint security, developer platform, identity security, source-control owners, CI/CD owners, cloud security, and incident response.

· Operational maturity is reduced when security teams lack baseline knowledge of normal AI coding-assistant usage, developer automation, repository hooks, package scripts, cloud CLI workflows, and build-system interactions.

· Operational maturity is reduced when no preapproved containment workflow exists for developer workstations, source-control access, CI/CD systems, package registries, cloud credentials, signing material, or deployment workflows.

· Mature operations require alert playbooks that check local execution, credential exposure, repository exposure, CI/CD exposure, package-registry exposure, cloud exposure, and identity-token exposure in one coordinated workflow.

Telemetry Maturity

Moderate

· Minimum viable telemetry includes endpoint process creation with parent-child lineage, full command-line capture, file telemetry for configuration and persistence paths, EDR behavioral detections, network telemetry, identity logs, and repository telemetry.

· Preferred telemetry includes process-aware network telemetry, URI-handler telemetry, browser and collaboration-platform link-interaction telemetry, CI/CD logs, package-registry logs, secrets-management logs, cloud-control-plane logs, application-control events, script-control events, and developer asset context.

· Telemetry maturity is high only when endpoint, SIEM, NDR, identity, source-control, CI/CD, package-registry, secrets-management, and cloud logs can be correlated by user, host, process, repository, token, session, and time window.

· Telemetry maturity is low where developer endpoints lack full EDR coverage, command-line capture, file monitoring, or asset classification.

Detection Engineering Maturity

High

· SentinelOne, Splunk, Elastic, QRadar, and SIGMA provide strong detection-engineering paths for the core behavior.

· NDR provides meaningful supporting coverage for post-execution egress and downstream expansion.

· YARA is correctly scoped to artifact triage and does not overstate detection maturity.

· AWS, Azure, and GCP are correctly excluded from primary-rule coverage for local execution and reserved for downstream exposure assessment.

· Detection engineering maturity is strengthened by strict avoidance of payload-only logic, proof-of-concept-only logic, and vulnerable-version-only logic.

· Detection engineering maturity depends on careful tuning to avoid suppressing legitimate but high-risk developer workflows.

Threat Intelligence Maturity

Moderate to High

· The intelligence is mature enough to describe the behavior class beyond a single vulnerability.

· The source case provides a concrete example of AI-assisted development tooling crossing from externally influenced input into trusted local execution.

· The broader behavior class applies to adjacent tools where settings, hooks, plugins, workspace trust, startup automation, local servers, or project-local configuration can trigger local command execution.

· Threat intelligence maturity is reduced by uncertainty around future attacker tradecraft, tool-specific patch behavior, public proof-of-concept evolution, and how broadly similar patterns may appear across other AI coding assistants.

· The intelligence should be updated if additional tooling, proof-of-concept behavior, exploitation reports, or telemetry-confirmed intrusions show new configuration, hook, plugin, or trusted-workspace execution paths.

Response Maturity

Moderate

· Response maturity is strongest when suspicious local execution can be tied to identity, repository, CI/CD, package-registry, secrets-management, cloud, and signing-material exposure.

· Response maturity depends on rapid workstation isolation, evidence preservation, token revocation, session invalidation, credential rotation, repository review, CI/CD review, package-registry review, cloud review, and developer-tool configuration review.

· Response maturity is reduced when teams do not know who owns AI coding-assistant governance, developer workstation containment, repository access review, CI/CD containment, signing-key protection, package-registry response, or cloud credential rotation.

· Response maturity improves when organizations predefine containment steps for developer identities with access to production repositories, signing keys, deployment systems, cloud credentials, build systems, sensitive source code, security tooling, or privileged infrastructure.

Maturity Gaps

· Incomplete endpoint process lineage.

· Incomplete command-line capture.

· Incomplete file telemetry for settings, hooks, workspace configuration, and persistence paths.

· Limited URI-handler, browser, chat, email, documentation, and collaboration-platform telemetry.

· Weak developer workstation asset tagging.

· Weak AI coding-assistant inventory.

· Limited baselines for AI coding-assistant child-process behavior.

· Limited baselines for approved hooks, startup automation, repository bootstrap scripts, package scripts, build scripts, cloud CLI usage, and local developer automation.

· Incomplete identity, repository, CI/CD, package-registry, secrets-management, and cloud telemetry.

· Incomplete correlation between endpoint events and downstream developer-platform activity.

· Unclear response ownership across SOC, endpoint, developer platform, identity, source control, CI/CD, cloud, and incident-response teams.

Maturity Improvement Priorities

· Establish full endpoint process lineage and command-line capture on developer workstations.

· Monitor Claude Code and comparable AI coding-assistant child-process behavior.

· Monitor settings, hooks, project-local configuration, workspace-local configuration, trusted-workspace artifacts, startup automation, credential paths, and persistence-capable paths.

· Build and maintain AI coding-assistant inventory and version visibility.

· Build developer workstation baselines by user role, repository, operating system, language ecosystem, and workstation class.

· Integrate endpoint telemetry with SIEM, NDR, identity, source-control, CI/CD, package-registry, secrets-management, and cloud logs.

· Define downstream exposure review workflows for repositories, CI/CD systems, package registries, cloud accounts, secrets managers, signing keys, and deployment systems.

· Establish containment playbooks for developer-workstation compromise involving source code, credentials, tokens, build systems, deployment workflows, and cloud access.

· Reassess detection logic after tool patches, new public research, new proof-of-concept behavior, telemetry-confirmed incidents, and new AI coding-assistant capabilities.

Final Maturity Judgment

The detection and intelligence model is mature enough for production-oriented behavioral detection where endpoint and SIEM telemetry are available. The model should not be treated as complete in environments that lack developer endpoint visibility, command-line capture, file telemetry, or downstream identity and repository correlation. The recommended maturity path is to operationalize endpoint-led detection first, enrich with SIEM and NDR correlation, and use cloud telemetry only for downstream exposure assessment after suspicious local execution is established.

S31 — Telemetry Dependencies

Claude Code deeplink settings-injection RCE and developer workstation execution risk depends on telemetry that can connect user-facing interaction, local AI coding-assistant behavior, configuration activity, command execution, credential access, repository activity, privileged engineering-system access, and downstream identity use. The primary dependency is not broad vulnerability scanning alone. The primary dependency is the ability to reconstruct whether externally influenced Claude Code activity crossed into local execution and whether that execution affected secrets, repositories, engineering systems, or software-delivery workflows.

Endpoint and Process Telemetry

· Process creation telemetry for Claude Code and comparable AI coding assistants.

· Parent-child process lineage showing whether Claude Code was launched by a browser, chat client, email client, documentation platform, collaboration tool, terminal, IDE, URI handler, or other user-facing application.

· Full command-line capture for Claude Code, shells, scripting interpreters, package managers, network utilities, Git clients, cloud CLIs, build tools, and credential utilities.

· Working directory, executable path, process hash, user identity, host identity, session context, and timestamp.

· EDR behavioral detections for suspicious child-process creation, script execution, credential access, outbound communication, staging, persistence, or lateral movement.

· Blocked execution, blocked script, blocked network retrieval, blocked credential access, and application-control events tied to Claude Code or comparable AI coding-assistant process trees.

File and Configuration Telemetry

· Creation, modification, access, deletion, or rollback activity involving Claude Code settings, AI coding-assistant settings, hook definitions, project configuration, workspace configuration, trusted-workspace artifacts, and startup automation.

· File events involving repositories, recently cloned workspaces, externally sourced projects, temporary directories, developer-tooling directories, and user profile paths.

· Access to environment files, shell profiles, SSH directories, API tokens, git credentials, package-manager configuration, cloud CLI configuration, CI/CD configuration, signing material, and local secret stores.

· Repository-local changes that introduce command-capable automation, hooks, startup behavior, package scripts, or unexpected developer-tool configuration.

· File activity indicating archive creation, staging, compression, encoding, cleanup, hidden files, temporary tools, or downloaded scripts after suspicious Claude Code activity.

Web, URI, and User-Interaction Telemetry

· Browser history, web-proxy records, email-security logs, chat logs, documentation access logs, issue tracker records, and collaboration-platform activity showing link interaction before Claude Code execution.

· Deeplink or local URI-handler invocation telemetry where available.

· Browser-to-local-application handoff telemetry that links external content to Claude Code or comparable AI coding-assistant launch.

· Pull request, issue, README, documentation, or repository-reference activity preceding suspicious tool behavior.

· User interaction records that help distinguish approved developer workflow from suspicious externally influenced activity.

Network and Outbound Communication Telemetry

· DNS, proxy, firewall, EDR network, and endpoint socket telemetry for developer workstations.

· Process-aware network telemetry linking outbound connections to Claude Code, shells, interpreters, package managers, Git clients, network utilities, cloud CLIs, or build tools.

· Destination domain, IP address, port, protocol, TLS SNI where available, HTTP host where available, user agent where available, session duration, byte count, connection count, timestamp, host identity, user identity, and process lineage.

· New, rare, low-reputation, temporary-hosting, paste-service, file-sharing, tunneling, dynamic-DNS, unfamiliar cloud, or newly observed destinations contacted after suspicious local execution.

· Large, unusual, compressed, staged, or repeated outbound transfers from developer workstations after suspicious Claude Code activity.

Identity, Repository, and Engineering-System Telemetry

· Identity-provider logs showing authentication, session creation, token refresh, MFA result, conditional-access decision, device posture, geolocation, ASN, and sign-in risk.

· Source-code platform logs showing clone, fetch, branch access, repository access, pull request activity, commit activity, token use, SSH key use, deploy-key use, secret access, and unusual repository enumeration.

· Engineering-system logs showing workflow access, pipeline triggers, build secret access, artifact access, release activity, package operations, privileged API use, secret reads, role assumption, access-key creation, and unusual automation.

· Device and identity correlation showing whether post-execution access originated from the affected workstation, a new device, a reused token, or an unfamiliar session.

Asset, Role, and Business Context

· Inventory of Claude Code and comparable AI coding-assistant installations and versions.

· Developer workstation asset classification, including privileged developer workstations, release-engineering workstations, security-engineering workstations, infrastructure-engineering workstations, and AI coding-assistant installed systems.

· User role, repository ownership, repository sensitivity, package scope, CI/CD privilege, cloud access level, signing-key access, and production deployment access.

· Approved developer automation, sanctioned hooks, known build workflows, approved testing records, incident-response activity, and change-management context.

· Retention sufficient to reconstruct link interaction, tool invocation, configuration activity, local execution, credential access, repository activity, and downstream engineering-system access.

S32 — Detection Limitations

Detection of Claude Code deeplink settings-injection RCE and developer workstation execution risk is limited by the complexity of modern developer environments. Developer workstations routinely execute shells, package managers, Git clients, cloud CLIs, build scripts, hooks, local servers, and automation. These behaviors can be legitimate, suspicious, or malicious depending on sequence, context, user intent, and downstream activity. Detection must therefore rely on correlation rather than isolated indicators.

Primary Detection Limitations

· Claude Code execution is not suspicious by itself.

· Claude Code installation or vulnerable-version exposure is not compromise evidence by itself.

· Deeplink or URI-handler activity is not compromise evidence without configuration, execution, or downstream corroboration.

· Shell, package-manager, Git, cloud CLI, or build-tool execution may be normal developer behavior.

· Settings, hooks, workspace configuration, and project-local automation may be legitimate in approved repositories.

· Network connections to package registries, source-code platforms, cloud services, documentation sites, and SaaS tools are common in developer workflows.

· Repository activity, branch access, build activity, package access, and CI/CD interaction may be routine for privileged engineering users.

· Public proof-of-concept strings, payload fragments, deeplink formats, or static exploit artifacts should not define production detection coverage.

Endpoint Visibility Limitations

· Missing parent-child process lineage may prevent attribution of shell, interpreter, package-manager, or network utility execution to Claude Code.

· Missing command-line capture may hide encoded execution, inline scripts, settings references, remote retrieval, credential access, and file operations.

· Missing working-directory context may prevent defenders from tying execution to a repository, workspace, temporary directory, or developer project.

· Missing file telemetry may obscure settings changes, hook creation, workspace configuration, startup automation, staging files, or credential access.

· Missing process-aware network telemetry may prevent attribution of outbound traffic to Claude Code or its child processes.

· Incomplete EDR coverage on macOS or Linux developer systems may reduce visibility compared with managed Windows endpoints.

Developer Environment Noise Limitations

· Developer workflows vary significantly by team, language ecosystem, operating system, repository, role, and workstation class.

· Legitimate build scripts, package installation, local testing, repository setup, dependency resolution, cloud CLI usage, and troubleshooting can resemble suspicious activity.

· Broad allowlisting of developer tools can suppress the same utilities attackers may abuse.

· Repository-local hooks, scripts, and automation may be expected in some teams but unusual in others.

· Developer baseline gaps can cause either excessive false positives or missed suspicious behavior.

· Approved security testing, incident-response activity, or red-team work can resemble malicious activity if not tied to change context.

Downstream Exposure Limitations

· Identity logs may show token use or session activity without proving whether the token was exposed during Claude Code activity.

· Repository logs may show access or clone activity without proving malicious intent.

· Engineering-system records may show pipeline access, package activity, release activity, or privileged API use without linking the action to workstation compromise.

· Existing authenticated sessions and token reuse can make suspicious follow-on activity appear normal.

· Short telemetry retention may prevent reconstruction of delayed credential use, repository access, engineering-system access, or data movement.

Assessment Constraints

· Detection should not assume successful exploitation from vulnerable-version presence.

· Detection should not assume host compromise from settings modification alone.

· Detection should not assume data exfiltration from outbound communication alone.

· Detection should not assume repository compromise from repository access alone.

· Detection should not assume engineering-system compromise without supporting identity, endpoint, repository, or control-plane evidence.

· Detection should distinguish attempted invocation, suspicious configuration, confirmed local execution, credential exposure, repository interaction, downstream access, and validated data movement as separate escalation states.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on reducing the probability that Claude Code or comparable AI coding assistants can be influenced through external content, local settings, hooks, or developer workflows in a way that creates unauthorized execution or downstream software-delivery exposure. The control objective is not to block all AI-assisted development. The control objective is to govern AI coding assistant execution, reduce local secret exposure, strengthen developer endpoint visibility, and preserve confidence in software-delivery workflows.

AI Coding Assistant Governance

· Maintain centralized inventory of Claude Code and comparable AI coding-assistant installations.

· Enforce fixed or approved versions through managed deployment channels where possible.

· Restrict unmanaged installation paths, direct downloads, untracked package-manager installs, and local user-controlled updates for privileged developer systems.

· Review deeplink and URI-handler registrations associated with Claude Code and comparable tools.

· Disable or restrict unnecessary deeplink handlers where operationally feasible.

· Define approved AI coding assistant use cases, supported installation methods, and update expectations for engineering teams.

· Require security review for AI coding assistant features that evaluate local settings, hooks, project configuration, workspace configuration, or external content.

Developer Endpoint Hardening

· Ensure EDR coverage on developer workstations, including macOS, Linux, and Windows systems.

· Capture parent-child process lineage, full command line, working directory, user identity, host identity, and timestamp for developer endpoints.

· Monitor Claude Code and comparable AI coding-assistant child-process creation.

· Apply application-control, script-control, or policy enforcement for high-risk child-process patterns where feasible.

· Restrict execution from temporary directories, untrusted workspaces, or recently cloned repositories when supported by developer workflows.

· Monitor creation or modification of shell profiles, launch agents, scheduled tasks, cron jobs, startup folders, services, and persistence-capable scripts.

· Harden developer workstation baselines by role, repository sensitivity, operating system, and privilege level.

Settings, Hooks, and Configuration Controls

· Monitor Claude Code settings, hook definitions, workspace configuration, project configuration, trusted-workspace artifacts, and startup automation.

· Establish approved hook and automation inventories for high-value repositories.

· Require review for repository-local configuration that introduces command-capable automation.

· Avoid broad trust assumptions for previously trusted repositories because trusted-workspace reuse is part of the modeled risk.

· Validate whether project-local or workspace-local settings can cause execution before trust decisions are applied.

· Restrict or warn on command-capable hooks from untrusted, newly cloned, or externally sourced repositories.

· Tie configuration changes to pull requests, tickets, repository ownership, and approved developer workflows where feasible.

Credential and Secret Controls

· Reduce persistent local secrets on developer workstations.

· Prefer short-lived credentials, just-in-time access, scoped tokens, and device-bound sessions where feasible.

· Rotate API keys, SSH keys, package tokens, cloud credentials, CI/CD credentials, and repository tokens when suspicious Claude Code activity cannot be confidently bounded.

· Monitor access to environment files, shell profiles, SSH material, cloud CLI configuration, package-manager credentials, git credentials, and CI/CD configuration.

· Restrict broad-scoped tokens and long-lived credentials for developers with production repository, release, package-publishing, cloud, or CI/CD access.

· Enforce secrets scanning in repositories and developer workspaces.

· Require rapid session revocation and token invalidation procedures for developer workstation compromise scenarios.

Repository and Software-Delivery Controls

· Enforce branch protection, pull-request review, signed commits where appropriate, and protected release workflows for sensitive repositories.

· Monitor repository enumeration, unusual clone activity, branch access, remote configuration changes, package-manifest changes, build-script changes, infrastructure-as-code changes, and release configuration changes.

· Protect package-publishing workflows with strong authentication, scoped tokens, review gates, and audit logging.

· Require additional review for changes to build scripts, deployment files, CI/CD configuration, package manifests, dependency files, security tooling, authentication logic, and infrastructure-as-code.

· Correlate repository activity with endpoint events, identity sessions, engineering-system actions, and change records.

· Maintain incident playbooks for repository integrity validation after suspicious developer workstation activity.

Privileged Engineering-System Controls

· Enforce least privilege for developer access to build systems, deployment workflows, package registries, cloud resources, source-code platforms, and secrets managers.

· Require MFA, device posture, conditional access, and session controls for privileged engineering systems.

· Monitor unusual access to workflows, build artifacts, deployment paths, package operations, secrets, privileged APIs, and release tooling.

· Restrict production deployment workflows from unmanaged or weakly monitored developer workstations.

· Maintain clear ownership for disabling tokens, revoking sessions, pausing pipelines, quarantining developer endpoints, and validating releases.

· Preserve engineering-system logs long enough to support delayed discovery and investigation.

S34 — Defensive Control & Hardening Architecture

Figure 6

The defensive architecture for Claude Code deeplink settings-injection RCE should treat developer workstations as high-value software-delivery control points. The architecture must connect endpoint telemetry, local configuration monitoring, AI coding assistant governance, identity controls, repository controls, privileged engineering-system controls, and incident-response workflows into a single assurance model.

Architecture Objective

The architecture objective is to prevent, detect, and contain externally influenced AI coding-assistant activity before it can create unauthorized local execution, credential exposure, repository manipulation, engineering-system misuse, or software-delivery trust failure.

Control Layer 1 — AI Coding Assistant Governance

· Maintain authoritative inventory of Claude Code and comparable AI coding assistant installations.

· Enforce approved versions, managed update paths, and policy-defined installation methods.

· Review deeplink, URI-handler, local server, hook, settings, plugin, MCP, workspace, and project-configuration behavior.

· Define approved use cases and risk tiers for AI coding assistant deployment.

· Require security review for features that allow external content, project files, settings, hooks, or workspace state to influence local execution.

Control Layer 2 — Developer Workstation Security

· Deploy EDR across developer workstations with process lineage, command-line, file, and network visibility.

· Monitor AI coding assistant parent-child process behavior.

· Apply script-control, application-control, or policy-based restrictions for high-risk execution patterns where feasible.

· Enforce workstation hardening for privileged engineering users.

· Use asset tags for privileged developers, release engineers, security engineers, infrastructure engineers, and AI coding assistant installed systems.

· Preserve endpoint telemetry long enough to reconstruct delayed discovery scenarios.

Control Layer 3 — Configuration and Hook Monitoring

· Monitor user-level and project-level Claude Code settings.

· Monitor hook definitions, workspace configuration, project configuration, trusted-workspace artifacts, startup automation, and command-capable local files.

· Establish approved automation baselines for high-value repositories.

· Alert on configuration changes followed by suspicious child-process execution, credential access, outbound communication, repository activity, or engineering-system access.

· Prevent broad allowlisting of repository-local automation without ownership and change context.

Control Layer 4 — Secrets and Identity Protection

· Reduce long-lived local secrets on developer machines.

· Enforce least privilege, short-lived credentials, scoped tokens, MFA, device posture, and conditional access.

· Monitor access to SSH keys, API tokens, package tokens, cloud credentials, git credentials, environment files, shell profiles, and CI/CD secrets.

· Maintain rapid token rotation, SSH key replacement, session revocation, and privileged-access review procedures.

· Correlate developer endpoint events with identity-provider logs and downstream token use.

Control Layer 5 — Repository and Software-Delivery Assurance

· Enforce strong repository protections for sensitive code, build scripts, package manifests, deployment automation, CI/CD configuration, security tooling, and infrastructure-as-code.

· Monitor source-code platform, engineering-system, secrets-manager, and cloud-control-plane activity after suspicious endpoint events.

· Require review gates for changes that affect software delivery, release signing, package publishing, deployment automation, or production access.

· Maintain repository integrity validation procedures for suspected developer workstation compromise.

· Correlate endpoint, identity, repository, engineering-system, network, and change-management records.

Control Layer 6 — Incident Response and Governance

· Define a developer workstation compromise playbook specific to AI coding assistant abuse.

· Assign ownership across SOC, endpoint engineering, developer platform, identity, source-code platform, software-delivery platform, cloud security, legal, and executive stakeholders.

· Preserve affected endpoint, repository, identity, engineering-system, cloud, and network evidence.

· Establish decision criteria for token rotation, endpoint quarantine, repository freeze, pipeline pause, package-registry review, release validation, and customer or partner communications readiness.

· Review lessons learned and update AI coding assistant governance after each investigation.

High.

S36 — CyberDax Intelligence Maturity Assessment

Claude Code deeplink settings-injection RCE requires intelligence maturity that goes beyond vulnerability awareness. Mature organizations must understand how AI coding assistants are deployed, how developer endpoints behave, where local secrets exist, which developers have privileged engineering access, and how endpoint activity connects to source-code platforms, privileged engineering systems, and software-delivery workflows.

Current Intelligence Requirement

The organization must be able to determine whether suspicious Claude Code activity remained local and explainable, or whether it crossed into local execution, credential exposure, repository interaction, engineering-system access, data movement, or software-delivery trust impact.

Maturity Level 1 — Exposure Awareness

· The organization can identify whether Claude Code or comparable AI coding assistants are present.

· The organization can identify affected or outdated versions where inventory is available.

· The organization can communicate update expectations to developer users.

· The organization has limited ability to correlate Claude Code activity with local execution or downstream access.

· Risk remains high because exposure visibility does not prove whether suspicious activity occurred.

Maturity Level 2 — Endpoint Execution Visibility

· The organization has process telemetry for developer workstations.

· The organization can observe Claude Code process launch, parent process context, child-process creation, command lines, and working directories.

· The organization can identify suspicious shell, interpreter, package-manager, Git, network utility, or cloud CLI execution from Claude Code process trees.

· The organization has partial visibility into settings, hooks, and local configuration changes.

· Risk is reduced, but downstream exposure may remain unclear without identity, repository, engineering-system, and cloud correlation.

Maturity Level 3 — Correlated Developer Workflow Visibility

· The organization can correlate Claude Code invocation, user interaction, settings or hook activity, local execution, outbound communication, credential access, repository activity, and identity events.

· The organization has meaningful developer baselines by role, workstation class, repository, operating system, and language ecosystem.

· The organization can distinguish normal developer automation from suspicious tool-driven activity with moderate confidence.

· The organization can identify high-value affected users, repositories, secrets, and engineering systems.

· Risk is materially reduced because investigation can move from isolated telemetry to behavior-led scoping.

Maturity Level 4 — Software-Delivery Assurance Integration

· The organization integrates endpoint, identity, repository, engineering-system, cloud, secrets-manager, network, and change-management telemetry.

· The organization can determine whether suspicious developer workstation activity affected source code, build workflows, package publishing, release signing, deployment automation, privileged resources, or secrets.

· Token rotation, session revocation, repository integrity validation, engineering-system review, package-registry review, and release validation procedures are defined and tested.

· Security teams can rapidly classify attempted invocation, confirmed local execution, credential exposure, downstream access, and validated data movement.

· Risk is significantly reduced because the organization can preserve software-delivery trust during investigation.

Maturity Level 5 — Adaptive AI Development Security

· The organization governs AI coding assistants as security-sensitive execution environments.

· AI coding assistant behavior, settings, hooks, plugins, local servers, workspace trust, MCP-related paths, and project configuration are continuously assessed.

· Developer endpoints use least privilege, short-lived credentials, strong telemetry, policy enforcement, and tightly governed local automation.

· Detection content is variant-resilient and extends to comparable AI-assisted development tools.

· Engineering, security, identity, software-delivery, cloud, and legal teams operate from a shared playbook for AI coding assistant abuse.

· Risk is minimized because the organization can prevent, detect, contain, and govern the broader behavior class rather than only the known Claude Code issue.

Maturity Assessment Summary

Most organizations using AI coding assistants will initially fall between Level 1 and Level 3. The target maturity for organizations with privileged engineering workflows should be Level 4, with Level 5 reserved for organizations that treat AI-assisted development tooling as a governed software-delivery control plane. The practical goal is to move from version awareness to correlated developer-workflow assurance.

S37 — Strategic Defensive Improvements

Strategic defensive improvement should focus on reducing systemic exposure from AI coding assistants, not only remediating a single Claude Code issue. The long-term risk is that trusted development tools increasingly interpret external content, local configuration, project files, hooks, plugins, and workspace state in ways that may influence local execution. Organizations should therefore treat AI-assisted development as a security-sensitive workflow requiring governance, telemetry, least privilege, and software-delivery assurance.

Strategic Priority 1 — Govern AI Coding Assistants as Execution-Sensitive Tools

· Classify Claude Code and comparable AI coding assistants as security-sensitive developer tools.

· Require centralized inventory, approved installation methods, version enforcement, and update governance.

· Review features that allow settings, hooks, plugins, MCP-related behavior, workspace state, or project files to influence local execution.

· Define approved use cases for privileged developers, release engineers, security engineers, infrastructure engineers, and contractors.

· Establish a formal exception process for unmanaged AI coding assistant use.

Strategic Priority 2 — Build Developer Workstation Assurance

· Treat privileged developer workstations as software-delivery control points.

· Expand endpoint telemetry on macOS, Linux, and Windows developer systems.

· Require process lineage, command-line capture, file telemetry, network telemetry, and EDR behavioral coverage for high-risk developer groups.

· Create workstation classes for privileged developers, release engineering, security engineering, infrastructure engineering, and AI coding assistant users.

· Align developer endpoint hardening with the sensitivity of source-code, privileged engineering-system, and release access.

Strategic Priority 3 — Reduce Local Secret Exposure

· Replace persistent local secrets with short-lived, scoped, and revocable credentials where feasible.

· Reduce broad-scoped developer tokens, long-lived SSH keys, package tokens, cloud credentials, and CI/CD credentials.

· Enforce rapid token rotation and session revocation procedures for suspicious developer workstation activity.

· Monitor access to local credential paths and sensitive configuration files.

· Tie credential scope to role, device posture, repository sensitivity, and business need.

Strategic Priority 4 — Strengthen Repository and Build-System Integrity

· Require stronger review for changes to build scripts, package manifests, deployment automation, CI/CD configuration, infrastructure-as-code, authentication logic, security tooling, and release workflows.

· Monitor suspicious repository access or modification after developer workstation alerts.

· Maintain repository integrity validation procedures for suspected workstation compromise.

· Protect package publishing, release signing, and deployment workflows with least privilege, review gates, strong authentication, and audit logging.

· Correlate repository, software-delivery, endpoint, identity, cloud, and change-management events during investigations.

Strategic Priority 5 — Improve Detection Engineering for AI-Assisted Development

· Build behavior-led detection for AI coding assistant invocation, settings evaluation, hook activity, child-process creation, credential access, outbound communication, repository interaction, and engineering-system follow-on.

· Avoid production dependence on exact exploit strings, vulnerable-version exposure, proof-of-concept fragments, or static deeplink patterns.

· Tune detection by developer role, workstation class, repository sensitivity, operating system, and language ecosystem.

· Maintain variant-resilient detection that applies to comparable AI-assisted development tools.

· Review detection content after tool updates, new AI coding assistant features, and changes to developer workflows.

Strategic Priority 6 — Integrate Security and Developer Platform Response

· Establish a joint response playbook across SOC, endpoint engineering, developer platform, identity, cloud security, source-code platform owners, software-delivery platform owners, legal, and engineering leadership.

· Define triggers for endpoint isolation, Claude Code configuration review, token rotation, repository freeze, pipeline pause, package-registry review, cloud-session revocation, and release validation.

· Create decision criteria for when suspicious Claude Code activity becomes a security incident, software-delivery assurance issue, legal review item, or executive reporting matter.

· Conduct tabletop exercises for AI coding assistant abuse affecting privileged developers.

· Preserve evidence across endpoint, identity, repository, engineering-system, cloud, network, and change-management systems.

Strategic Priority 7 — Preserve Executive Confidence in AI-Enabled Development

· Communicate that AI coding assistant risk is manageable when governed as part of secure engineering.

· Avoid framing the control strategy as a blanket prohibition on AI-assisted development unless risk conditions require it.

· Emphasize that the objective is to preserve developer productivity while preventing uncontrolled local execution, credential exposure, repository manipulation, and software-delivery trust loss.

· Provide executives with clear assurance metrics covering tool inventory, version compliance, endpoint visibility, local secret reduction, repository integrity, software-delivery controls, and incident readiness.

· Reassess AI-assisted development risk as tools introduce new local execution, plugin, MCP, workspace, hook, or automation capabilities.

S38 — Attack Economics & Organizational Impact Model

Adversary Cost Advantage

Claude Code deeplink settings-injection RCE and developer workstation execution risk creates favorable attacker economics because the activity can target trusted AI-assisted development workflows rather than requiring immediate production-system exploitation. An attacker does not need to defeat every enterprise security control if developer-facing content, deeplink handling, local settings, hook-capable configuration, or trusted repository workflows create a practical path to local execution or credential exposure on a developer workstation.

The attacker advantage comes from the relationship between trusted developer tools, local configuration, source-code access, local secrets, repository workflows, and privileged engineering access. A single developer workstation may contain source-code access, API keys, SSH keys, package tokens, cloud credentials, CI/CD access material, internal documentation, build context, repository history, release workflow access, or security tooling context. This creates high leverage from limited local execution or credential access.

The highest leverage does not come from Claude Code usage alone. It comes from whether suspicious tool behavior connects to local command execution, credential access, repository interaction, engineering-system follow-on activity, software-delivery exposure, or evidence gaps that prevent confident scoping.

Defender Cost Disadvantage

Defenders face elevated cost because remediation is not limited to confirming that Claude Code is updated. Affected organizations must validate endpoint exposure, preserve developer workstation evidence, review Claude Code settings and hooks, inspect local configuration, assess process execution, review credential access, scope repository activity, inspect engineering-system access, evaluate downstream identity use, and determine whether software-delivery workflows remained trustworthy.

The defender burden increases when endpoint telemetry is incomplete, developer workstations are lightly managed, local secrets are persistent, Claude Code installations are unmanaged, settings and hooks are not monitored, repository baselines are weak, privileged developer access is broad, or engineering-system logs are fragmented. In those cases, the organization may need to rotate tokens, replace SSH keys, revoke sessions, validate repositories, inspect build and release workflows, review package-registry access, assess cloud access, and provide executive assurance even when direct production impact is not confirmed.

Operational Leverage for Attackers

Successful or strongly suspected Claude Code-centered abuse can create outsized organizational impact because developer workstations often sit at the intersection of source-code access, software build workflows, cloud administration, CI/CD systems, package publishing, release signing, security engineering, internal tooling, and production-adjacent operations.

Operational leverage increases when affected users have access to production repositories, authentication code, payment workflows, customer-impacting applications, regulated-service code, infrastructure-as-code, deployment automation, package registries, signing material, security tooling, or privileged engineering systems. The incident may remain technically local at first, but the business impact can expand quickly if credentials, repositories, or software-delivery workflows cannot be trusted.

Organizational Impact Model

Low impact occurs when Claude Code is confirmed updated or mitigated, affected developer endpoints are identified, deeplink exposure is understood, endpoint telemetry is available, settings and hook-capable configuration are clean, no suspicious child-process execution is observed, no credential access is detected, no suspicious repository activity occurs, and downstream engineering-system access remains explainable.

Moderate impact occurs when one or more developer endpoints show suspicious Claude Code invocation, unexpected settings modification, hook-capable configuration, child-process execution, outbound communication, credential-access concern, repository activity, engineering-system access, identity concern, or telemetry gaps without confirmed source-code tampering, package compromise, production deployment impact, broad secret exfiltration, or sustained adversary control.

High impact occurs when confirmed or strongly suspected Claude Code abuse affects developers with access to production repositories, privileged engineering systems, CI/CD administration, cloud infrastructure, package publishing, release signing, security tooling, customer-impacting services, regulated-service code, or sensitive intellectual property. High impact is most likely when suspicious activity aligns with local execution, credential theft, unauthorized repository activity, package or dependency manipulation, build-pipeline concern, cloud authentication misuse, CI/CD secret access, outbound exfiltration, or evidence gaps that prevent confident scoping.

Economic Pressure Points

· Number and criticality of developer workstations running affected or unverified Claude Code versions.

· Number of developers using unmanaged Claude Code installation paths, local package-manager installs, direct downloads, or non-standard developer images.

· Involvement of developers with production repository access, release responsibilities, package-publishing permissions, cloud access, CI/CD access, security tooling access, or sensitive engineering responsibilities.

· Presence of persistent local secrets, API keys, SSH keys, git credentials, package tokens, cloud credentials, CI/CD credentials, signing material, or internal service tokens on affected workstations.

· Evidence of suspicious Claude Code invocation, settings modification, hook creation, child-process execution, credential access, repository interaction, outbound communication, or engineering-system follow-on activity.

· Sensitivity of repositories accessible from affected machines, including production service code, authentication logic, payment workflows, deployment automation, infrastructure-as-code, security tooling, and customer-impacting applications.

· Ability to reconstruct deeplink interaction, tool invocation, settings changes, process lineage, command execution, file access, network activity, repository activity, identity activity, and downstream access.

· Scope of required token rotation, SSH key replacement, session revocation, endpoint preservation, repository integrity review, package-registry validation, build-pipeline assurance, and release validation.

· Need for legal review, customer or partner assurance, cyber insurance coordination, engineering freeze decisions, software-supply-chain investigation, executive reporting, or board-level oversight.

S39 — Economic Impact & Organizational Exposure

Figure 7

Estimated Economic Exposure

Estimated economic exposure should be modeled through three scenario bands.

Low Impact Scenario

Estimated impact $300K to $1.25M.

Low impact applies when Claude Code is confirmed updated or mitigated across managed developer endpoints; deeplink exposure is understood; endpoint process, file, and network telemetry are available; suspicious deeplink activity is not observed; Claude Code settings and hook-capable configuration are clean; no suspicious child-process execution, outbound communication, credential access, repository manipulation, package-manager abuse, cloud authentication, or CI/CD activity is tied to Claude Code; and high-privilege developer workstations show no unauthorized activity.

Moderate Impact Scenario

Estimated impact $1.25M to $9M.

Moderate impact applies when one or more developer endpoints show suspicious Claude Code deeplink invocation, unexpected settings modification, hook-capable configuration changes, abnormal child-process execution, unfamiliar outbound communication, credential-access concerns, repository activity, package-manager behavior, identity activity, or telemetry gaps without confirmed source-code tampering, production impact, package compromise, cloud environment misuse, broad secret exfiltration, or sustained adversary control.

High Impact Scenario

Estimated impact $9M to $45M or higher.

High impact applies when confirmed or strongly suspected Claude Code abuse affects developers with access to production repositories, privileged engineering systems, CI/CD administration, cloud infrastructure, package publishing, release signing, security tooling, customer-impacting services, regulated-service code, or sensitive intellectual property. High impact is most likely when evidence indicates successful local execution, credential theft, unauthorized git operations, suspicious repository modification, package or dependency manipulation, cloud authentication misuse, CI/CD secret access, persistence through developer tooling, outbound exfiltration, or downstream software-delivery risk.

Annualized Risk Exposure

Estimated annualized risk exposure is $2M to $18M or higher.

Annualized risk exposure is driven by Claude Code deployment scale, vulnerable-version footprint, developer privilege level, deeplink exposure, endpoint telemetry quality, local secrets posture, repository sensitivity, engineering-system access, package-registry access, source-code integrity requirements, token rotation burden, forensic complexity, software-supply-chain assurance requirements, legal obligations, and customer or partner exposure.

Operational Dependency

Economic exposure increases when affected developer endpoints support production source-code access, release engineering, package publishing, cloud administration, CI/CD operations, internal tooling, security engineering, infrastructure-as-code, deployment automation, regulated-service code, or customer-impacting software delivery.

Control Trust

Control trust is reduced when Claude Code versions are unmanaged, deeplink handlers are not governed, developer endpoints lack strong telemetry, local secrets are persistent, settings and hooks are not monitored, repository access is broad, privileged engineering systems are reachable from weakly managed workstations, or software-delivery actions are not tied to strong change-control evidence.

Visibility Confidence

Visibility confidence depends on endpoint process lineage, full command-line capture, file telemetry, settings and hook monitoring, URI-handler or browser-to-local-application telemetry, DNS logs, proxy records, firewall logs, process-aware network telemetry, identity-provider records, source-code platform logs, engineering-system logs, package-registry logs, cloud-control-plane logs, and change-management records.

Change-Control Confidence

Change-control confidence decreases when settings changes, hook changes, repository-local configuration, package-manifest changes, build-script changes, infrastructure-as-code changes, CI/CD configuration changes, deployment workflow changes, package-publishing actions, release activity, or incident-response actions are poorly documented, inconsistently approved, weakly logged, or difficult to separate from suspicious Claude Code-centered activity.

Downstream Dependency

Downstream exposure increases when affected developers or workstations support production repositories, authentication systems, payment workflows, customer-data systems, regulated-service applications, deployment automation, signing workflows, package distribution, cloud infrastructure, security tooling, internal developer platforms, or high-value engineering operations.

Customer and Regulatory Exposure

Customer and regulatory exposure increases when suspicious Claude Code activity involves repositories, credentials, cloud resources, build workflows, package-publishing paths, deployment automation, customer-impacting code, regulated-service code, contractual systems, confidential intellectual property, security tooling, or evidence gaps that prevent confident scoping of source-code access, secret exposure, downstream access, or software-delivery impact.

Residual Economic Risk

Version validation, patch deployment, deeplink governance, settings review, hook cleanup, endpoint containment, token rotation, SSH key replacement, session revocation, repository validation, package-registry review, cloud-session review, CI/CD review, and release validation can reduce future exposure, but they do not automatically prove that prior Claude Code-centered abuse did not occur. Historical review remains required when high-value developer endpoints show suspicious invocation, settings changes, local execution, credential access, repository activity, engineering-system follow-on activity, outbound communication, or incomplete evidence.

Proof-of-Concept Behavioral Coverage Assessment

Claude Code deeplink settings-injection RCE is the primary proof-of-concept behavior addressed by this report. The report remains behavior-led and should not be interpreted as limited to a single exploit string, payload, deeplink format, command line, repository artifact, or attacker workflow. The proof-of-concept is relevant because it reflects the same activity class addressed by the report: externally influenced AI coding-assistant activity, local configuration influence, settings or hook-capable execution behavior, developer workstation execution risk, credential exposure risk, repository trust exposure, and downstream software-delivery impact.

Detection Engineering Coverage Interpretation

The S25 detection content would provide coverage for Claude Code deeplink settings-injection RCE-style activity where observable behavior includes suspicious AI coding-assistant invocation, deeplink or URI-handler activity, settings modification, hook-capable configuration, local child-process execution, command-line retrieval, credential access, repository interaction, unusual developer workstation egress, source-code platform activity, package-registry access, cloud-control-plane activity, CI/CD interaction, or identity anomalies.

Coverage is strongest where Claude Code-centered activity produces observable artifacts already aligned to S25 logic, including abnormal AI coding-assistant launch context, settings or hook activity, child-process execution, suspicious outbound communication, credential access, repository activity, privileged engineering-system access, or endpoint-to-identity correlation.

Direct Coverage

Direct behavioral coverage applies where Claude Code deeplink settings-injection RCE-style activity produces telemetry matching existing S25 rule logic without material changes. This includes suspicious Claude Code launch context, deeplink or URI-handler activity, settings modification, hook-capable configuration, local command execution, suspicious child-process creation, credential access, outbound communication, repository access, and downstream engineering-system activity already represented in the report’s S25 detection model.

Relevant S25 coverage areas include:

· Suspicious developer workstation egress following AI coding-assistant execution context.

· Developer workstation expansion toward source-control, CI/CD, artifact, secrets, package-registry, or cloud-control infrastructure after suspicious AI coding-assistant activity.

· AI coding assistant spawning shell, script, network, credential, package-management, Git, or cloud CLI utilities.

· Settings, hook, or workspace configuration activity followed by suspicious AI coding-assistant execution.

· AI coding-assistant process tree followed by credential, persistence, outbound, repository, identity, or engineering-system behavior.

· SIEM correlation across externally influenced invocation, settings evaluation, local execution, outbound activity, credential access, repository activity, and downstream access.

· SIGMA-style endpoint logic for AI coding-assistant child-process creation and configuration-driven execution.

· Cloud and identity rules for suspicious developer credential use after endpoint execution context.

· YARA-style coverage only where artifact-based or configuration-content inspection is available and appropriate.

Coverage With Adaptation

Coverage with adaptation applies where related Claude Code, AI coding assistant, MCP, hook, plugin, workspace, project-configuration, or local automation activity aligns with the S25 model but requires local tuning for tool version, operating system, executable name, settings path, hook path, repository structure, endpoint platform, identity provider, source-code platform, CI/CD system, package registry, cloud environment, or telemetry schema.

Adaptation should focus on:

· Mapping Claude Code and comparable AI coding-assistant process names across Windows, macOS, and Linux.

· Mapping settings, hooks, workspace configuration, project-local configuration, trusted-workspace artifacts, MCP configuration, plugin paths, and startup automation.

· Tuning approved developer automation, sanctioned hooks, repository bootstrap scripts, build scripts, package-manager activity, cloud CLI use, CI/CD workflows, and incident-response activity.

· Prioritizing privileged developers, production repositories, release engineering, security engineering, infrastructure engineering, package maintainers, and cloud administrators.

· Integrating endpoint process lineage, file telemetry, process-aware network telemetry, identity-provider records, repository logs, engineering-system logs, package-registry logs, cloud-control-plane logs, and change-management context.

Non-Coverage Conditions

Non-coverage applies where activity produces no observable endpoint, configuration, process, file, network, identity, repository, engineering-system, package-registry, cloud, or data-flow telemetry. Non-coverage also applies where a related vulnerability depends on an unrelated exploitation mechanism, unrelated platform behavior, direct production-system compromise without developer-workstation relevance, or a separate detection model outside AI coding assistant and developer-workstation execution activity. In those cases, the correct report output is an exposure or assurance finding rather than a confirmed detection claim.

Current Coverage Count

Directly covered CVEs / proof-of-concept behavior patterns: 1 — Claude Code deeplink settings-injection RCE and developer workstation execution risk.

Covered with adaptation: 0 currently counted.

Not currently counted as separately covered: related Claude Code hook-driven execution behavior, MCP or configuration-driven tool execution behavior, and comparable AI coding assistant configuration-to-execution behavior. These remain adaptation candidates unless separately validated against a specific CVE, proof-of-concept, or vendor-disclosed issue.

Total CVE / proof-of-concept behavior patterns directly or largely covered by this report’s behavioral detection model: 1.

Coverage Qualification

This count should be treated as a living analytical note, not a universal-coverage claim. A related CVE, proof-of-concept, or vendor-disclosed issue should only be added when it shares enough observable behavior with the report’s detection model to support credible detection or detection-readiness coverage. A related issue should not be counted when it depends on an unrelated exploitation mechanism, lacks sufficient technical detail, produces no aligned telemetry, or requires a separate detection model.

S40 — References

Vendor / Platform Documentation

Anthropic — Claude Code Documentation.

hxxps://docs[.]anthropic[.]com/en/docs/claude-code

Anthropic — Claude Code Security.

hxxps://docs[.]anthropic[.]com/en/docs/claude-code/security

Threat Technique Framework

MITRE ATT&CK Framework — Enterprise Matrix.

hxxps://attack[.]mitre[.]org/matrices/enterprise/

Federal / KEV / Exploitation Catalog

CISA — Known Exploited Vulnerabilities Catalog.

hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

Security Vendor Analysis

0Day.click — Claude Code Deeplink Settings-Injection RCE Research.

hxxps://0day[.]click/

Check Point Research — Claude Code Project File RCE and API Token Exfiltration Research.

hxxps://research[.]checkpoint[.]com/

Threat Tradecraft and Intrusion Patterns

OWASP — Top 10 for Large Language Model Applications.

hxxps://owasp[.]org/www-project-top-10-for-large-language-model-applications/

NIST — Secure Software Development Framework.

hxxps://csrc[.]nist[.]gov/Projects/ssdf

Reference Usage Note

This reference set supports the report’s focus on Claude Code deeplink settings-injection RCE, AI coding assistant configuration risk, developer workstation execution risk, local secret exposure, repository trust, software-delivery assurance, and ATT&CK-aligned behavioral interpretation. Anthropic references provide vendor context for Claude Code behavior and security posture. MITRE ATT&CK provides the technique framework used for behavioral mapping. CISA KEV is included as a catalog reference for exploitation-priority context only and should not be interpreted as evidence that this Claude Code issue is KEV-listed unless separately confirmed. Security research references support the public technical basis for the Claude Code activity class. OWASP and NIST references support broader AI-application and secure-software-development risk framing.

[EXP] Claude Code Deeplink Settings-Injection RCE and Developer Workstation Execution Risk

BLUF

Executive Risk Translation

S3 — Why This Matters Now

S4 — Key Judgments

S5 — Executive Risk Summary

Business Risk

Technical Cause

Threat Posture

Executive Decision Requirement

S6 — Executive Cost Summary

Low Impact Scenario

Moderate Impact Scenario

High Impact Scenario

S6A — Key Cost Drivers

Most Likely Scenario Justification

S6B — Compliance and Risk Context

Compliance Exposure Indicator

Risk Register Entry

Risk Title

Risk Description

Likelihood

Impact

Risk Rating

Annualized Risk Exposure

S7 — Risk Drivers

S8 — Bottom Line for Executives

S9 — Board-Level Takeaway

S10 — Threat Overview

S11 — Threat Classification and Type

Threat Type

Threat Sub-Type

Operational Classification

Primary Function

S12 — Campaign or Activity Overview

S13 — Targets and Exposure Surface

S14 — Sectors / Countries Affected

Sectors Affected

Countries Affected

S15 — Adversary Capability Profiling

Capability Level

Technical Sophistication

Infrastructure Maturity

Operational Scale

Escalation Likelihood

S16 — Targeting Probability Assessment

Overall Targeting Probability

Targeting Drivers

Most Likely Targets

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Developer-Facing Invocation Opportunity

Stage 2 — Local Command or Script Execution

Stage 3 — Hook-Capable or Event-Triggered Execution

Stage 4 — Developer Credential Exposure

Stage 5 — Source-Code or Repository Access

Stage 6 — Follow-On Use of Developer Accounts

Stage 7 — Conditional Exfiltration or External Data Movement

S18 — Attack Path Narrative (Signal-Aligned Execution Flow)

Developer-Facing Invocation

Relevant Signals

Settings or Configuration Influence

Relevant Signals

Local Execution

Relevant Signals

Credential Exposure

Relevant Signals

Repository Interaction

Relevant Signals

Engineering System Follow-On

Relevant Signals

Data Movement

Relevant Signals

S19 — Attack Chain Risk Amplification Summary

Primary Risk Amplifiers

Risk Interpretation

Operational Impact

S20 — Tactics, Techniques, and Procedures

Developer-Facing Invocation

Deeplink and Tool-Context Abuse

Settings and Configuration Manipulation