[CVE] VMware Spring AI Remote Code Execution via Prompt Injection (CVE-2026-22738)

Report Type
Threat Intelligence Assessment

Threat Category
Application-Layer Remote Code Execution via AI Prompt Injection

Assessment Date
March 28, 2026

Primary Impact Domain
Enterprise Application Security, Identity and Credential Exposure, Sensitive Data Protection, and AI-Driven Service Integrity

BLUF

 CVE-2026-22738 introduces a high-impact risk to organizations deploying VMware Spring AI by enabling adversaries to drive unintended backend execution through prompt-controlled inputs, creating a direct path from external user interaction to internal system execution. The vulnerability is caused by the absence of strict separation between user-controlled prompt content and trusted execution context, allowing model-generated output to influence backend tool invocation without sufficient validation or restriction. While not currently listed in the CISA Known Exploited Vulnerabilities catalog, the exposure model aligns closely with attacker-preferred remote code execution pathways and carries a high exploitation exposure probability. Organizations should immediately restrict prompt-to-execution pathways, enforce validation and allowlisting of tool invocation logic, and monitor for abnormal execution behavior within AI-enabled application services.

Executive Risk Translation
Prompt-driven execution bypasses traditional security controls, allowing attackers to operate inside trusted application workflows with high likelihood of rapid weaponization once exploitation techniques mature.

S3 Why This Matters Now

·        VMware Spring AI is being integrated into enterprise Java and Spring-based microservices, embedding AI-driven execution logic directly into production application workflows

·        The framework links user-controlled input, model processing, and backend execution, creating a trust boundary where externally supplied data can shape internal system behavior

·        Traditional controls such as web application firewalls and API gateways are not designed to detect or constrain model-mediated execution chains

·        CVE-2026-22738 represents a new class of application-layer vulnerability where natural language input can directly influence backend execution pathways

S4 Key Judgments

·        CVE-2026-22738 enables a direct execution pathway from user-controlled input to backend application logic via model-mediated tool invocation

·        Exploitation requires only access to an exposed prompt ingestion interface and does not depend on authentication in externally accessible deployments

·        The vulnerability aligns with remote code execution tradecraft and is highly likely to be adopted rapidly by attackers once exploitation patterns are operationalized

·        Detection is dependent on behavioral monitoring of execution and identity activity rather than traditional signature-based approaches

·        Organizations deploying AI-enabled application frameworks without execution boundary controls face elevated risk of undetected compromise

S5 Executive Risk Summary

CVE-2026-22738 introduces a high-risk execution pathway within AI-enabled application environments, enabling adversaries to influence backend system behavior through prompt-controlled input. Although not currently listed in the KEV catalog, the vulnerability exhibits characteristics consistent with high-priority exploitation candidates, including low attacker complexity, high scalability across enterprise environments, and direct alignment with remote code execution objectives. The primary risk is the breakdown of trust boundaries within application logic, allowing attacker-controlled instructions to execute within trusted service contexts. Organizations with exposed Spring AI deployments should treat this vulnerability as high priority despite the absence of confirmed exploitation.

S6 Executive Cost Summary

This cost analysis was developed by the CyberDax team using expert judgment and assisted analytical tools to support clarity and consistency.

·        Low Impact: $200,000–$800,000 — Limited compromise of isolated AI-enabled application components with constrained backend execution exposure and minimal sensitive data interaction

·        Moderate Impact: $800,000–$4 million — Unauthorized execution within application services enabling access to internal APIs, service-to-service interactions, or moderate data exposure requiring investigation and partial system rebuild

·        High Impact: $4 million–$15 million — Widespread exploitation of AI-integrated application environments enabling persistent execution pathways, data exfiltration, and disruption of critical business services

S6A Key Cost Drivers

·        Extent of VMware Spring AI deployment across production environments

·        Sensitivity of data accessible through AI-enabled application workflows

·        Time to detection of abnormal execution within trusted application contexts

·        Complexity of isolating and rebuilding compromised AI-integrated services

·        Dependency on backend tools and APIs exposed to model-mediated execution

S6B Compliance and Risk Context

Compliance Exposure Indicator
High

Risk Register Entry
CVE-2026-22738 introduces a prompt-driven execution vulnerability within VMware Spring AI that enables user-controlled input to influence backend application behavior, bypassing traditional input validation controls and exposing enterprise systems to unauthorized execution and data access risk.

Annualized Risk Exposure

Estimated $3.0M–$10.5M annually based on:

·        High exploitation exposure probability (EEP: 94/100)

·        Likelihood of attacker adoption following disclosure of prompt-injection execution techniques

·        Expanding enterprise deployment of AI-enabled application frameworks

·        Moderate-to-high impact cost scenarios driven by application-layer compromise and backend execution exposure

S7 Executive Risk Scoring

Overall Risk Rating
High

Exploitability Rating
High

Impact Rating
High

Exposure Rating
High

Exploitation Exposure Probability (EEP)
94/100

EEP is a forward-looking analytic measure of operational exploitation potential, not a statement of confirmed exploitation, KEV inclusion, or incident activity.

KEV Alignment Status
Not currently listed in the CISA Known Exploited Vulnerabilities Catalog

KEV Likelihood Assessment
High

Risk Prioritization Tier
Tier 1 — Immediate Action Required

Operational Priority
Immediate — organizations should prioritize mitigation of prompt-to-execution pathways and enforce strict validation of model-driven actions within application services

S8 Bottom Line for Executives

CVE-2026-22738 represents a high-risk vulnerability in AI-enabled application frameworks that allows attacker-controlled input to influence backend execution behavior, effectively bypassing traditional security controls. Organizations deploying VMware Spring AI should assume elevated risk and implement immediate controls to restrict execution pathways, validate model-driven actions, and monitor for anomalous behavior within application services.

S9 Board-Level Takeaway

The emergence of CVE-2026-22738 highlights a structural shift in application risk where natural language input can directly influence system execution, bypassing conventional security controls. This vulnerability reflects a broader governance challenge associated with AI integration into enterprise systems, requiring oversight of how AI-driven functionality interacts with backend execution logic and critical business processes.

S10 Vulnerability Overview

Vulnerability Type
Prompt Injection leading to Remote Code Execution

Affected Component
VMware Spring AI prompt handling and tool execution pipeline

Description
CVE-2026-22738 is a prompt injection vulnerability in VMware Spring AI that allows adversaries to embed malicious instructions within user-controlled input, causing the large language model to generate unauthorized tool invocation commands. Because the framework does not enforce strict separation between user input and execution context, these instructions can be interpreted as trusted system actions, resulting in remote code execution within the application environment.

S11 Technical Vulnerability Details

Technical Failure Condition
User-controlled prompt content is not adequately isolated from system-level instruction handling and downstream execution logic.

Execution Path Exposure

·        User-controlled input is incorporated into LLM prompts

·        Model output is permitted to influence backend tool invocation

·        Application logic interprets model-mediated output as actionable execution context

·        Backend tools, APIs, or service workflows may execute without sufficient validation or allowlisting

Root Cause Components

·        Failure to enforce strict separation between user-controlled prompt content and system-level instructions

·        Implicit trust of LLM-generated output as executable or actionable logic

·        Absence of validation or allowlisting for tool invocation requests generated by the model

·        Lack of contextual integrity controls to prevent prompt injection from influencing execution pathways

·        Design assumption that LLM responses are non-adversarial, enabling attacker-controlled instruction flow into backend operations

S12 Exploitability Assessment

Exploitability
High — exploitation requires injection of crafted prompt content through chat interfaces, API input fields, or user-supplied data ingestion paths where model output can influence backend execution behavior.

Attack Requirements

·        Externally reachable or otherwise attacker-accessible input path into Spring AI workflow

·        LLM output permitted to influence backend tool invocation, service actions, or execution logic

·        Insufficient validation, allowlisting, or isolation between model output and execution layer

Attack Complexity
Low to Moderate — complexity decreases materially once a reachable prompt injection path and executable downstream function path are identified.

Exposure Conditions

·        Applications exposing LLM interfaces to untrusted users

·        Systems where LLM output can trigger API calls, shell execution, or backend service workflows

·        Environments lacking prompt sanitization, output validation, or tool execution allowlisting

S13 KEV Status and Patch Availability

KEV Status
Not present in the CISA Known Exploited Vulnerabilities Catalog at time of analysis.

KEV Likelihood Assessment

High likelihood of future KEV inclusion based on:

·        Strong alignment with remote code execution exposure patterns

·        Exploitation path requiring only prompt injection into externally accessible interfaces

·        Increasing attacker focus on AI-enabled application execution pathways

·        Broad applicability across enterprise Spring AI deployments

Exploitation Exposure Probability (EEP)
High (94/100)

EEP is a forward-looking analytic measure of operational exploitation potential, not a statement of confirmed exploitation, KEV inclusion, or incident activity.

KEV Prioritization Implication

Although not currently KEV-listed, this vulnerability should be treated with KEV-equivalent prioritization due to high exploitation likelihood and low barrier to attacker adoption once exploitation techniques are operationalized.

Patch Availability

No authoritative public vendor advisory or confirmed patch guidance identified at time of analysis.

Patch / Remediation Status

·        Vendor advisory confirmation required

·        If no patch is available, mitigation must focus on:

o   prompt isolation

o   tool invocation validation

o   execution boundary enforcement

o   restriction of backend function exposure to AI workflows

Exposure Management Priority

High — organizations should identify Spring AI deployments, restrict prompt-to-execution pathways, validate model-mediated tool invocation logic, and monitor for abnormal execution behavior within AI-enabled application services.

S14 Sectors / Countries Affected

Sectors Affected

·        Technology and SaaS providers deploying Spring-based microservices with embedded AI functionality

·        Financial services platforms using AI-driven customer interaction, automation, or decision workflows

·        Healthcare organizations integrating AI into data processing, summarization, or operational decision-support systems

Countries Affected

·        United States

·        United Kingdom

·        European Union member states

·        Asia-Pacific regions with high SaaS and cloud adoption

S15 Adversary Capability Profiling

Skill Level
Moderate — exploitation relies on manipulation of AI workflows and input shaping rather than advanced exploit development

Infrastructure Requirements
Minimal — standard HTTP or API interaction is sufficient where AI-enabled endpoints are externally reachable

Scalability
High — prompt-based and API-driven interaction can be automated across multiple exposed applications

Operational Objectives

·        Achieve application-layer execution through AI-mediated backend invocation paths

·        Access sensitive data processed within AI-enabled workflows and connected systems

·        Establish footholds within trusted application service contexts

·        Enable broader enterprise compromise through application-layer entry points

S16 Targeting Probability Assessment

High Probability Targets

·        Public-facing AI-enabled applications exposing prompt-driven interaction, assistant features, search, or workflow automation

·        SaaS platforms embedding Spring AI where a single execution pattern can be reused across multiple tenants or customer environments

Medium Probability Targets

·        Enterprise systems with externally accessible APIs that route user-controlled data into AI orchestration workflows

Lower Probability Targets

·        Isolated systems without external input paths into AI processing or without backend execution linked to model-influenced output

Assessment Basis
Attackers prioritize environments where Spring AI increases execution reach, concentrates high-value business data, and enables scalable exploitation through internet-facing workflows with low interaction cost

S17 MITRE ATT&CK Chain Flow Mapping

Initial Access

T1190 – Exploit Public-Facing Application

Attackers deliver crafted prompt or API input to externally exposed Spring AI endpoints, allowing untrusted input to enter orchestration workflows.
Execution

T1059 – Command and Scripting Interpreter
Model-mediated output influences backend logic, resulting in execution of commands, scripts, or function calls within JVM-based services.

Credential Access (Follow-on)

T1552 – Unsecured Credentials
Execution within application context may expose environment variables, API keys, or service tokens accessible to the compromised process.

Command and Control (Follow-on)

T1071 – Application Layer Protocol
Compromised application services may communicate externally over HTTP or HTTPS as part of attacker-influenced execution.

Exfiltration (Follow-on)

T1041 – Exfiltration Over C2 Channel
Data may be exfiltrated through application-initiated outbound communication controlled by attacker-influenced execution.

Defense Evasion (Execution Layer)

T1027 – Obfuscated/Compressed Files and Information
Malicious logic is embedded within prompt manipulation and model-driven execution, blending with legitimate application behavior.

Conditional Post-Exploitation Behaviors

·        T1505 – Server Software Component
Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment.

·        T1021 – Remote Services
Not observed in currently available reporting; may occur if compromised services enable lateral connectivity.

·        T1082 – System Information Discovery
Not observed in currently available reporting; may occur if backend execution enables system or environment inspection.

·        T1068 – Exploitation for Privilege Escalation
Not observed in currently available reporting; may occur if execution context allows elevation beyond initial service privileges.

S18 Attack Path Narrative (Signal-Aligned Execution Flow)

An attacker initiates activity by submitting crafted prompt or API input to an externally accessible AI-enabled application endpoint, producing observable inbound requests at the application layer, including anomalous prompt structures, unexpected parameter combinations, or irregular request frequency within API and AI workflow logs.

The request is processed by the Spring AI orchestration layer, where model inference occurs. At this stage, direct network-level visibility is limited, but deviations may be observable in application telemetry, prompt handling logs, or inconsistencies in request-response behavior compared to normal workflow patterns.

As model-influenced output is generated, it drives downstream application decision logic, resulting in backend function invocation or execution-path selection. This transition produces observable signals such as unexpected service-to-service calls, abnormal function usage patterns, or deviations in execution flow within JVM-based service telemetry and application tracing systems.

Execution occurs within a legitimate application process, causing malicious activity to blend into normal operations. Detection signals become most visible when correlating endpoint process activity, application execution logs, and outbound network communication, where anomalies such as unexpected command execution behavior, irregular data access, or non-standard outbound connections may appear.

Once execution is achieved, attacker influence over application behavior produces follow-on observable activity, including unauthorized data retrieval patterns, abnormal service interactions, and outbound communication inconsistent with baseline application behavior, indicating potential compromise of the AI-enabled service context.

S19 Attack Chain Risk Amplification Summary

Spring AI orchestration consolidates user input handling, model inference, and backend execution into a single trust boundary, increasing the likelihood that attacker-controlled input can influence sensitive operations before validation or control mechanisms are applied.

Model-mediated execution introduces an abstraction layer between input and action, where the decision point driving backend behavior resides within model output rather than explicit application logic, reducing transparency and complicating detection and forensic attribution.

Malicious activity executes within legitimate JVM service processes and application workflows, allowing attacker behavior to align with expected operational patterns and reducing the effectiveness of traditional signature-based or rule-based detection approaches.

Detection is further degraded when organizations lack consistent correlation between prompt input, model output, and backend execution events, particularly in environments where logging does not preserve end-to-end linkage across AI workflows and application execution paths.

S20 Tactics, Techniques, and Procedures

T1190 – Exploit Public-Facing Application
Attackers exploit externally accessible Spring AI interfaces by injecting crafted prompt content or API inputs that are processed by the application without sufficient isolation or validation.

T1059 – Command and Scripting Interpreter
Model-generated output is interpreted as actionable instructions within the application, triggering backend execution through tool invocation, script execution, or API-driven workflows.

T1552 – Unsecured Credentials
Execution within application context enables access to environment variables, configuration files, or service tokens accessible to the running process.

T1071 – Application Layer Protocol
Application services initiate outbound communication over HTTP or HTTPS as part of attacker-influenced execution flows.

T1041 – Exfiltration Over C2 Channel
Data may be transmitted externally through application-initiated network communication driven by model-mediated execution.

T1027 – Obfuscated/Compressed Files and Information
Malicious logic is embedded within prompt content and model output, blending with legitimate application behavior and avoiding traditional detection mechanisms.

Conditional Post-Exploitation Techniques

·        T1505 – Server Software Component
Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment.

·        T1021 – Remote Services
Not observed in currently available reporting; may occur if compromised services enable lateral movement.

·        T1082 – System Information Discovery
Not observed in currently available reporting; may occur if execution enables access to system or environment data.

·        T1068 – Exploitation for Privilege Escalation
Not observed in currently available reporting; may occur if execution context allows privilege elevation beyond the application scope.

S20A Adversary Tradecraft Summary

Adversaries exploit prompt-driven execution pathways within VMware Spring AI by manipulating natural language inputs to influence backend application behavior. Rather than relying on traditional software vulnerabilities, attackers leverage the implicit trust placed in model-generated output to trigger execution of backend tools, APIs, or workflows within the application context.

Tradecraft is focused on achieving execution within trusted application environments, enabling access to credentials, data, and service functionality without requiring direct exploitation of underlying infrastructure. Expansion beyond the application layer, including persistence or lateral movement, is dependent on target environment configuration and attacker objectives and is not inherent to the initial exploitation pathway.

S21 Detection Strategy Overview

Detection strategy focuses on identifying abnormal execution behavior within AI-enabled application services, where model-mediated output influences backend operations.

Primary detection objectives include:

·        Identification of unexpected execution triggered by application-layer inputs

·        Detection of anomalous service account or application identity behavior

·        Monitoring of unusual data access patterns within application context

·        Identification of abnormal outbound communication initiated by application services

Detection does not rely on signature-based indicators and instead requires behavioral correlation across application execution, identity activity, and network communication.

S22 Primary Detection Signals

·        Execution of backend commands, scripts, or tool invocations triggered by user-facing application inputs

·        Unusual service account or application identity behavior, including abnormal API usage or token access

·        Access to sensitive data sources such as secrets, configuration stores, or environment variables

·        Outbound network communication from application services to unapproved destinations

·        Correlation of execution activity followed by data access and external communication

S23 Telemetry Requirements

Detection requires visibility across:

·        Application execution logs capturing tool invocation, script execution, and API calls

·        Identity and access logs reflecting service account or application identity usage

·        Data access logs for secrets, storage systems, and configuration sources

·        Network telemetry capturing outbound communication patterns

Effective detection requires correlation across these telemetry sources to identify multi-stage execution behavior.

S24 Detection Opportunities and Gaps

Detection Opportunities

·        Correlation of prompt-driven execution with backend command or API activity

·        Identification of abnormal identity behavior within application context

·        Detection of data access followed by outbound communication patterns

Detection Gaps

·        Limited visibility into prompt content and model decision-making processes

·        Lack of direct telemetry linking user input to backend execution

·        Difficulty distinguishing malicious model-generated behavior from legitimate application activity

S25 Ultra-Tuned Detection Engineering Rules

Suricata

Suricata Coverage Scope

Suricata provides network-observable coverage only for this threat. It can support detection of:

·        suspicious inbound prompt or API delivery patterns

·        suspicious outbound callback or exfiltration behavior

·        short-window correlation between suspicious ingress and egress from the same Spring AI service

Suricata does not directly detect:

·        Spring AI orchestration decisions

·        JVM runtime behavior

·        backend function invocation

·        model-to-function execution logic

Accordingly, Suricata should be treated as an ingress and egress corroboration layer, not a standalone execution detector.

Rule Name

Spring AI Endpoint Repeated Prompt Override Delivery Pattern

Purpose
Detect repeated inbound HTTP requests to Spring AI-enabled endpoints containing instruction-override language associated with prompt manipulation. This rule is intended to identify network-observable adversary behavior consistent with iterative prompt abuse against externally reachable Spring AI services.

ATT&CK Technique
T1190 – Exploit Public-Facing Application
T1027 – Obfuscated/Compressed Files and Information

Telemetry Dependency

·        HTTP request-body visibility for inbound traffic to Spring AI-enabled endpoints

·        TLS termination before the inspection point, or cleartext inspection behind a reverse proxy

·        Accurate scoping of Spring AI application hosts, paths, or API routes

·        Local exclusions for legitimate testing, red-team activity, or administrative prompt-engineering workflows

Tuning Explanation
Restrict this rule to known Spring AI application paths that accept prompt or API input. Treat the phrase set as a behavioral proxy for prompt override attempts, not a complete list of malicious input language. Apply suppressions for known safe testing workflows.

Detection Logic
Alert when repeated inbound requests to Spring AI-enabled endpoints contain strong instruction-override or system-context manipulation language, and set a short-lived correlation marker on the destination host.

Operational Context
This rule targets the ingress stage of the attack chain. It is highest value when correlated with:

·        outbound HTTP POST activity from the same service

·        large outbound transfer behavior

·        suspicious DNS activity from the same service

Logical Notes
This rule does not prove successful exploitation. It identifies repeated adversary-like prompt delivery behavior at the application boundary.

Rule Regret Check

Deployment caution

·        Restrict to Spring AI-enabled endpoints only

·        Do not deploy across generic web applications

·        Exclude known internal testing and authorized evaluation traffic

Confidence caution

·        Confidence depends on decrypted HTTP visibility and accurate endpoint scoping

·        Stealthier prompt manipulation may avoid obvious override language

Coverage value

·        High for repeated obvious prompt override attempts

·        Partial for subtle prompt abuse

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Confirm support for xbits in the deployed Suricata version

·        Confirm $SPRING_AI_NET is defined and scoped correctly

·        Adjust URI matching to real application routes

·        Validate request-body inspection is actually available

·        Tune threshold and phrase set against local baseline traffic

System-Ready Code

alert http $EXTERNAL_NET any -> $SPRING_AI_NET $HTTP_PORTS (
    msg:"CYBERDAX Spring AI repeated prompt override delivery pattern";
    flow:established,to_server;
    http.uri;
    pcre:"/\/(ai|chat|prompt|generate|assist|completion|completions|messages)/Ui";
    http.request_body;
    pcre:"/(ignore\s+previous\s+instructions|ignore\s+all\s+prior\s+instructions|reveal\s+the\s+system\s+prompt|show\s+developer\s+instructions|disregard\s+safety|call\s+the\s+tool|invoke\s+the\s+function)/Ri";
    xbits:set,springai.suspect_prompt,track ip_dst,expire 600;
    threshold:type both, track by_dst, count 3, seconds 120;
    classtype:web-application-attack;
    sid:2500101;
    rev:1;
)

Rule Name

Spring AI Endpoint Suspicious Encoded Prompt Delivery

Purpose
Detect inbound HTTP requests to Spring AI-enabled endpoints containing unusually long encoded-looking payload segments within prompt-bearing request bodies, indicating possible hidden control content, staged instruction injection, or obfuscated adversary input.

ATT&CK Technique
T1190 – Exploit Public-Facing Application
T1027 – Obfuscated/Compressed Files and Information

Telemetry Dependency

·        HTTP request-body inspection for Spring AI prompt submission traffic

·        Decrypted HTTP visibility or cleartext inspection after TLS termination

·        Knowledge of normal prompt payload structure for the protected application

·        Local exclusions for legitimate encoded content, signed blobs, or serialized objects

Tuning Explanation
This is a corroborating ingress rule, not a standalone high-confidence alert. It is appropriate where user prompts are normally natural-language dominant and long encoded strings are unusual.

Detection Logic
Alert when Spring AI prompt-bearing requests include long encoded-looking strings suggestive of obfuscated instruction content, and set a short-lived correlation marker on the destination host.

Operational Context
Use with:

·        repeated prompt override delivery

·        outbound POST behavior from the same host

·        suspicious DNS or transfer anomalies after inbound prompt delivery

Logical Notes
This rule identifies suspicious payload characteristics, not confirmed malicious intent.

Rule Regret Check

Deployment caution

·        Use only where prompt content is reasonably predictable

·        Exclude application flows that legitimately transmit long encoded content

Confidence caution

·        High-entropy matching can be noisy without endpoint scoping and baseline knowledge

Coverage value

·        Medium as a corroborating ingress indicator for obfuscated prompt abuse

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Confirm body visibility exists in the deployed inspection path

·        Tune encoded-length threshold to local traffic

·        Exclude legitimate application payload patterns

·        Validate xbits behavior in target engine version

System-Ready Code

alert http $EXTERNAL_NET any -> $SPRING_AI_NET $HTTP_PORTS (
    msg:"CYBERDAX Spring AI suspicious encoded prompt delivery";
    flow:established,to_server;
    http.uri;
    pcre:"/\/(ai|chat|prompt|generate|assist|completion|completions|messages)/Ui";
    http.request_body;
    pcre:"/([A-Za-z0-9+\/]{220,}={0,2})/R";
    xbits:set,springai.suspect_prompt,track ip_dst,expire 600;
    threshold:type both, track by_dst, count 2, seconds 300;
    classtype:web-application-attack;
    sid:2500102;
    rev:1;
)

Rule Name

Spring AI Service Outbound HTTP POST Following Suspicious Prompt Activity

Purpose
Detect outbound HTTP POST requests from Spring AI-enabled application services to non-approved external destinations shortly after suspicious inbound prompt-delivery behavior has been observed against the same service.

ATT&CK Technique
T1071.001 – Application Layer Protocol: Web Protocols

Telemetry Dependency

·        HTTP visibility for outbound traffic from Spring AI application services

·        Decrypted egress visibility, cleartext proxy inspection, or internal inspection before encryption

·        Accurate host or subnet scoping for Spring AI service infrastructure

·        Destination allowlisting or upstream suppression for approved external dependencies

Tuning Explanation
This is a correlation-based rule. It should only be considered high value when the service has first been marked by suspicious ingress behavior.

Detection Logic
Alert on outbound HTTP POST traffic from a Spring AI service when the source host has been tagged by recent suspicious prompt-delivery activity.

Operational Context
This is a primary egress-correlation rule. It is strongest when used with:

·        repeated prompt override delivery

·        encoded prompt delivery

·        downstream application or endpoint telemetry showing abnormal execution

Logical Notes
This rule does not claim Suricata observed execution directly. It identifies suspicious network follow-on behavior from a host recently targeted with likely prompt-manipulation traffic.

Rule Regret Check

Deployment caution

·        Restrict to Spring AI service hosts only

·        Maintain allowlisting for approved external APIs, identity providers, telemetry services, and required business egress paths

Confidence caution

·        Confidence drops where outbound HTTPS visibility is absent

·        A hit indicates suspicious egress correlation, not proven successful exfiltration

Coverage value

·        High for likely callback or follow-on web traffic after suspicious ingress activity

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Confirm ingress and egress sensor visibility preserve consistent host identity for xbits tracking

·        Validate local destination allowlisting process outside the rule

·        Confirm egress HTTP method visibility exists

·        Tune correlation window to local service behavior

System-Ready Code

alert http $SPRING_AI_NET any -> $EXTERNAL_NET any (
    msg:"CYBERDAX Spring AI outbound HTTP POST following suspicious prompt activity";
    flow:established,to_server;
    xbits:isset,springai.suspect_prompt,track ip_src;
    http.method;
    content:"POST";
    classtype:policy-violation;
    sid:2500103;
    rev:1;
)

Rule Name

Spring AI Service Large Outbound Transfer Following Suspicious Prompt Activity

Purpose
Detect materially sized outbound HTTP POST transfers from Spring AI-enabled services after suspicious ingress prompt activity, indicating possible data staging or exfiltration from a prompt-mediated compromise path.

ATT&CK Technique
T1041 – Exfiltration Over C2 Channel
T1071.001 – Application Layer Protocol: Web Protocols

Telemetry Dependency

·        HTTP inspection with outbound payload-size visibility

·        Accurate scoping of Spring AI service hosts or subnets

·        Destination allowlisting to exclude legitimate upload or API-transfer workflows

·        Best results where egress HTTP is visible before encryption or via a trusted proxy

Tuning Explanation
This rule is narrower than the prior outbound POST rule. Its purpose is probable outbound transfer behavior, not general suspicious communication detection. Thresholds must be tuned to the application baseline.

Detection Logic
Alert on large outbound HTTP POST payloads from a Spring AI service when the source host has recently been tagged by suspicious prompt-delivery behavior.

Operational Context
This rule represents the probable transfer or exfiltration stage and should be treated separately from generic outbound callback detection.

Logical Notes
This rule has distinct value because it focuses on volume-consistent outbound transfer following a prompt-abuse window.

Rule Regret Check

Deployment caution

·        Exclude legitimate document transfer, API upload, and business integration paths

·        Tune payload threshold to the actual application profile

Confidence caution

·        Large transfer volume suggests suspicious outbound movement, not content sensitivity or confirmed theft

Coverage value

·        High for detecting probable outbound data movement correlated to suspicious prompt activity

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Tune dsize threshold to service baseline

·        Exclude normal large outbound traffic paths

·        Confirm correlation marker propagation works as intended

·        Validate egress HTTP visibility exists before deployment

System-Ready Code

alert http $SPRING_AI_NET any -> $EXTERNAL_NET any (
    msg:"CYBERDAX Spring AI large outbound transfer following suspicious prompt activity";
    flow:established,to_server;
    xbits:isset,springai.suspect_prompt,track ip_src;
    http.method;
    content:"POST";
    dsize:>1500;
    classtype:exfiltration;
    sid:2500104;
    rev:1;
)

Rule Name

Spring AI Service Suspicious DNS After Prompt Abuse Window

Purpose
Detect suspicious DNS behavior from Spring AI-enabled application services shortly after suspicious prompt-delivery activity, providing a corroborating signal for callback infrastructure resolution or exfiltration support traffic.

ATT&CK Technique
T1071.004 – Application Layer Protocol: DNS

Telemetry Dependency

·        DNS visibility from Spring AI service infrastructure

·        Accurate host or subnet identification for Spring AI-enabled services

·        DNS inspection sufficient to evaluate query strings

·        Aggressive suppression for known CDNs, observability providers, service meshes, and approved external dependencies

Tuning Explanation
This is a corroborating correlation rule, not a primary alert. It should fire only after recent suspicious ingress targeting and should be used to strengthen investigations involving outbound web traffic or abnormal application behavior.

Detection Logic
Alert on high-entropy or unusually structured DNS queries from a Spring AI service when that host has recently been tagged by suspicious prompt-delivery behavior.

Operational Context
This rule helps identify network-side follow-on behavior that may not rise to high confidence by itself but becomes valuable when temporally linked to suspicious ingress activity against the same service.

Logical Notes
This rule should not be escalated alone. Its purpose is to support higher-confidence multi-signal investigations.

Rule Regret Check

Deployment caution

·        Restrict to Spring AI service infrastructure only

·        Maintain aggressive allowlisting for expected service dependencies

Confidence caution

·        Standalone confidence is low

·        Use only as corroborating evidence with prompt-delivery or outbound communication anomalies

Coverage value

·        Medium as a supporting signal for callback or exfiltration support behavior after suspicious ingress targeting

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Confirm DNS visibility and query parsing in the deployed environment

·        Tune entropy-style matching to local dependency patterns

·        Validate xbits source tracking works for the same service host identity

·        Use only with strong suppressions and corroboration workflow

System-Ready Code

alert dns $SPRING_AI_NET any -> any any (
    msg:"CYBERDAX Spring AI suspicious DNS after prompt abuse window";
    xbits:isset,springai.suspect_prompt,track ip_src;
    dns.query;
    pcre:"/([a-z0-9]{20,})/i";
    classtype:bad-unknown;
    sid:2500105;
    rev:1;
)

Suricata Final Caveat Statement

These rules are deployment-ready with local adaptation required. They are not represented as fully execution-validated because final operational success depends on:

·        Suricata version compatibility

·        local variable definitions

·        TLS inspection placement

·        host identity consistency for xbits

·        destination allowlisting

·        threshold tuning against real traffic

Suricata Coverage Summary

Strongest Coverage Areas

·        suspicious prompt-delivery activity at ingress

·        correlated outbound POST behavior

·        probable outbound transfer behavior

·        supporting DNS anomalies after suspicious ingress

Coverage Boundaries

·        does not directly observe Spring AI orchestration decisions

·        does not directly observe JVM execution

·        should be used as part of a broader cross-telemetry detection model, not as a standalone proof of exploitation

SentinelOne

SentinelOne Coverage Scope

SentinelOne is the primary endpoint execution-detection layer for this threat. It is used to detect:

·        abnormal child-process creation from Spring AI-enabled JVM service contexts

·        suspicious interpreter execution following attacker-influenced application behavior

·        credential-material access from suspicious service-linked execution

·        suspicious process-to-network behavior indicating callback or exfiltration

·        post-execution utility chaining consistent with discovery or staging

SentinelOne does not directly observe:

·        prompt text as entered by the user

·        internal model reasoning

·        Spring AI orchestration decisions without supporting application telemetry

Accordingly, SentinelOne should be used to detect the host-level consequences of model-mediated backend execution, not the prompt content itself.

Tenant Adaptation Model

The following placeholders must be replaced during deployment:

·        <SPRING_AI_HOST_SCOPE>
Hosts, sites, groups, tags, or saved filters identifying Spring AI-enabled systems

·        <APPROVED_PARENT_PROCESSES>
JVMs, service wrappers, container runtimes, or launchers expected to host Spring AI services

·        <APPROVED_CHILD_PROCESSES>
Legitimate child processes expected from protected service contexts

·        <APPROVED_HELPER_PROCESSES>
Support, observability, deployment, and maintenance processes that should not alert

·        <APPROVED_SECRET_HANDLERS>
Vault clients, bootstrap routines, or service agents allowed to access secret material

·        <APPROVED_EXTERNAL_DESTINATIONS>
Sanctioned external endpoints used by the protected application

Where field names differ by tenant export or query mode, map the logic to the local SentinelOne schema before deployment.

Rule Name

Spring AI Service Unexpected Child Process Spawn

Purpose
Detect unexpected child-process execution from JVM-based Spring AI application services, where attacker-influenced backend execution results in process creation behavior not aligned with normal application operation.

ATT&CK Technique
T1059 – Command and Scripting Interpreter

Telemetry Dependency

·        SentinelOne Deep Visibility process creation telemetry

·        Reliable scoping of Spring AI-enabled application hosts

·        Parent-child process lineage showing JVM or service-hosted execution contexts

·        Baseline knowledge of legitimate child-process behavior for protected services

Tuning Explanation
This rule must be scoped to Spring AI-enabled service hosts only. It is intended for environments where application services normally remain bounded and do not spawn shells, interpreters, transfer tools, or administrative utilities during routine operation. Exclude approved maintenance, deployment, and platform-support workflows.

Detection Logic
Detect child processes spawned from protected JVM or service contexts when the child belongs to a high-risk execution class and is not part of the approved runtime baseline.

Operational Context
This is one of the strongest endpoint detections for this threat because it captures the most direct host-level expression of model-mediated backend execution. It is strongest when correlated with:

·        suspicious application-layer input telemetry

·        orchestration anomalies

·        outbound network behavior from the same process or host

Logical Notes
This rule detects abnormal process creation from the service context. It does not require visibility into the exact prompt content.

Rule Regret Check

Deployment caution

·        Scope to Spring AI-enabled systems only

·        Exclude approved deployment, observability, and maintenance workflows

·        Maintain an accurate approved-child-process baseline

Confidence caution

·        Confidence decreases in dynamic environments where services legitimately spawn helper processes

Coverage value

·        Very High for detecting prompt-mediated backend execution that creates host-level process artifacts

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <SPRING_AI_HOST_SCOPE> with real tenant scoping

·        Replace <APPROVED_PARENT_PROCESSES> and <APPROVED_CHILD_PROCESSES> with tenant-approved values

·        Map field names to the local SentinelOne schema

Tenant-Adaptable Query Skeleton

event.type = "Process Creation"
AND <SPRING_AI_HOST_SCOPE>
AND parent_process IN <APPROVED_PARENT_PROCESSES>
AND child_process IN ("bash","sh","python","python3","perl","ruby","pwsh","powershell","curl","wget","nc")
AND child_process NOT IN <APPROVED_CHILD_PROCESSES>
AND child_process NOT IN <APPROVED_HELPER_PROCESSES>

Rule Name

Spring AI Service Suspicious Interpreter Execution from Protected Service Context

Purpose
Detect shell or interpreter execution launched from a Spring AI-enabled JVM application context where the resulting process behavior is inconsistent with the application’s approved runtime profile.

ATT&CK Technique
T1059 – Command and Scripting Interpreter

Telemetry Dependency

·        SentinelOne Deep Visibility process creation telemetry

·        Command-line visibility

·        Parent-child lineage

·        Reliable scoping of Spring AI-enabled systems

Tuning Explanation
This rule is narrower than the generic child-process rule and is focused specifically on interpreter-driven execution. It is appropriate where protected services are not expected to invoke shells or scripting engines as part of normal business function.

Detection Logic
Detect interpreter execution from protected service lineage when the resulting command-line behavior is not part of the approved runtime baseline.

Operational Context
Use this as a primary command-execution analytic for service contexts that should remain in-process and should not pivot into shell or scripting interpreters.

Logical Notes
This rule is useful when attacker-controlled application behavior causes execution to leave the intended service control boundary.

Rule Regret Check

Deployment caution

·        Exclude approved support scripts and controlled operational workflows

·        Restrict to protected service hosts

Confidence caution

·        Confidence drops where support tooling regularly invokes interpreters from service contexts

Coverage value

·        High for execution behaviors likely to follow successful model-mediated abuse

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Tune command-line exclusions to the local environment

·        Validate actual service-lineage process names in the tenant

·        Replace scoping placeholders with real host or group selectors

Tenant-Adaptable Query Skeleton

event.type = "Process Creation"
AND <SPRING_AI_HOST_SCOPE>
AND child_process IN ("bash","sh","python","python3","pwsh","powershell","node")
AND parent_process IN <APPROVED_PARENT_PROCESSES>
AND command_line NOT CONTAINS ANY <APPROVED_HELPER_PROCESSES>

Rule Name

Spring AI Service Credential Material Access from Suspicious Service Lineage

Purpose
Detect command execution patterns consistent with credential discovery or secret access from a Spring AI-enabled service context after attacker-influenced execution.

ATT&CK Technique
T1552 – Unsecured Credentials

Telemetry Dependency

·        SentinelOne Deep Visibility process creation telemetry

·        Command-line visibility

·        Parent-child process telemetry

·        Local knowledge of legitimate secret access tooling in the protected application stack

Tuning Explanation
Restrict this rule to protected service hosts and suspicious execution lineage. Focus on processes accessing:

·        environment variables

·        credential-bearing files

·        token stores

·        cloud credential references

Exclude approved vault clients, bootstrap routines, and service agents.

Detection Logic
Detect suspicious commands or utilities accessing credential-bearing material from protected service execution lineage.

Operational Context
This rule maps directly to a likely attacker objective after successful application-side execution: harvesting usable secrets from the service environment.

Logical Notes
This rule is strongest when paired with suspicious child-process or interpreter execution from the same service context.

Rule Regret Check

Deployment caution

·        Requires exclusions for approved secret bootstrap and vault access behavior

·        Do not use as a broad enterprise secret-access analytic

Confidence caution

·        Debugging and diagnostics may resemble credential discovery if exclusions are incomplete

Coverage value

·        Very High for identifying likely post-execution credential access from compromised Spring AI services

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <APPROVED_SECRET_HANDLERS> with approved local secret-access tooling

·        Tune credential-material indicators to the actual environment

·        Validate parent lineage assumptions in the tenant

Tenant-Adaptable Query Skeleton

event.type = "Process Creation"
AND <SPRING_AI_HOST_SCOPE>
AND child_process IN ("bash","sh","cat","grep","find","env","printenv","python","python3")
AND command_line CONTAINS ANY ("/proc/self/environ","/proc/*/environ",".env",".docker/config.json",".npmrc","GITHUB_TOKEN","AWS_ACCESS_KEY_ID","AZURE_CLIENT_SECRET","GOOGLE_APPLICATION_CREDENTIALS","printenv","env")
AND parent_process IN <APPROVED_PARENT_PROCESSES>
AND child_process NOT IN <APPROVED_SECRET_HANDLERS>
AND child_process NOT IN <APPROVED_HELPER_PROCESSES>

Rule Name

Spring AI Service Suspicious Process Followed by External Network Connection

Purpose
Detect suspicious process execution from a Spring AI-enabled application context followed by outbound external network communication consistent with callback or exfiltration behavior.

ATT&CK Technique
T1071.001 – Application Layer Protocol: Web Protocols
T1041 – Exfiltration Over C2 Channel

Telemetry Dependency

·        SentinelOne process telemetry

·        SentinelOne network connection telemetry where available

·        Correlation between process activity and outbound connections on the same host

·        Destination baseline knowledge for protected services

Tuning Explanation
This rule should begin from suspicious execution classes rather than generic network activity. Focus on interpreters, transfer tools, and unexpected child processes originating from protected service lineage, then correlate with outbound external communication. Exclude approved destinations.

Detection Logic
Detect outbound external network connections initiated by suspicious processes spawned from protected application service contexts.

Operational Context
This is a high-value endpoint-plus-network correlation rule. It is strongest when the process already matches suspicious JVM-child or interpreter execution patterns.

Logical Notes
This rule identifies likely follow-on communication from suspicious process execution. It does not prove the content of any transfer.

Rule Regret Check

Deployment caution

·        Requires destination tuning and host scoping

·        Exclude expected external integrations, telemetry, and business APIs

Confidence caution

·        Confidence rises materially when paired with suspicious child-process or credential-access behavior

Coverage value

·        High for detecting likely callback or exfiltration follow-on after suspicious application-side execution

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <APPROVED_EXTERNAL_DESTINATIONS> with tenant-approved destinations

·        Validate network telemetry availability in the tenant

·        Confirm host/process/network correlation fidelity locally

Tenant-Adaptable Query Skeleton

event.type = "Network Connection"
AND <SPRING_AI_HOST_SCOPE>
AND network_direction = "OUTGOING"
AND destination_is_private = false
AND source_process IN ("bash","sh","python","python3","curl","wget","nc","pwsh","powershell")
AND parent_process IN <APPROVED_PARENT_PROCESSES>
AND destination NOT IN <APPROVED_EXTERNAL_DESTINATIONS>

Rule Name

Spring AI Service Unapproved Utility Execution Chain

Purpose
Detect execution of administrative, transfer, or system-enumeration utilities from Spring AI-enabled services where the tool chain is not part of the approved application runtime model.

ATT&CK Technique
T1082 – System Information Discovery
T1059 – Command and Scripting Interpreter

Telemetry Dependency

·        SentinelOne Deep Visibility process creation telemetry

·        Parent-child process telemetry

·        Command-line visibility

·        Baseline knowledge of approved utility execution on protected service hosts

Tuning Explanation
This rule is intended to catch tool-use expansion after prompt-mediated execution. Focus on utilities commonly used for environment inspection, file access, transfer, or staging. Scope tightly and suppress support tooling.

Detection Logic
Detect unapproved execution of utility chains from protected JVM-linked service contexts where the utilities are not part of the approved runtime baseline.

Operational Context
Use this to identify attacker attempts to move from initial execution into environment discovery, collection, or transfer preparation.

Logical Notes
This is a strong supporting analytic when tied to suspicious service lineage.

Rule Regret Check

Deployment caution

·        Requires strong baseline knowledge for service-host utilities

·        Suppress maintenance, support, and observability helper tooling

Confidence caution

·        Utility execution can be noisy in poorly segmented or manually administered environments

Coverage value

·        High as a post-execution expansion detector for suspicious service-host behavior

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <APPROVED_CHILD_PROCESSES> and <APPROVED_HELPER_PROCESSES> with tenant-approved values

·        Validate that utility execution from service lineage is genuinely unusual locally

·        Tune utility set to the actual environment

Tenant-Adaptable Query Skeleton

event.type = "Process Creation"
AND <SPRING_AI_HOST_SCOPE>
AND parent_process IN <APPROVED_PARENT_PROCESSES>
AND child_process IN ("whoami","id","uname","hostname","ps","netstat","ss","curl","wget","nc","tar","gzip","base64")
AND child_process NOT IN <APPROVED_CHILD_PROCESSES>
AND child_process NOT IN <APPROVED_HELPER_PROCESSES>

SentinelOne Final Caveat Statement

These rules are tenant-adaptable and production-grade in detection design, but they are not represented as universally system-ready until the following are completed locally:

·        field mapping to the actual SentinelOne schema

·        protected-host scoping

·        approved parent/child/helper baselines

·        approved destination baselines

·        local exclusion tuning

·        live validation in the tenant

SentinelOne Coverage Summary

Strongest Coverage Areas

·        suspicious child-process creation from JVM service contexts

·        interpreter execution inconsistent with protected service runtime

·        credential-material access after suspicious execution

·        suspicious process-to-network follow-on behavior

·        post-execution utility chaining from protected application services

Coverage Boundaries

·        does not directly observe prompt content unless reflected in host artifacts

·        does not directly observe internal model reasoning

·        should be correlated with application and orchestration telemetry for highest confidence

Splunk

Splunk Coverage Scope

Splunk serves as the cross-telemetry correlation layer for this threat. Its highest value is in linking:

·        suspicious targeting of Spring AI-enabled application routes

·        abnormal execution lineage from JVM-hosted application services

·        credential-material access from suspicious service-linked execution

·        process-to-network sequences consistent with callback or exfiltration

·        post-execution utility expansion from protected service contexts

Splunk does not directly prove model reasoning or prompt abuse without supporting:

·        application request logs

·        Spring AI orchestration logs

·        tracing linking prompt input to downstream function invocation

Accordingly, Splunk’s strongest role is sequence-based detection across application, endpoint, and network telemetry, not single-event determination.

Tenant Adaptation Model

Replace these placeholders during deployment:

·        <SPRING_AI_HOST_SCOPE>

·        <APPROVED_APP_ENDPOINTS>

·        <APPROVED_PARENT_PROCESSES>

·        <APPROVED_CHILD_PROCESSES>

·        <APPROVED_SECRET_HANDLERS>

·        <APPROVED_EXTERNAL_DESTINATIONS>

·        <APP_LOG_INDEXES>

·        <EDR_INDEXES>

·        <NETWORK_INDEXES>

Where field names differ locally, map the logic to the actual Splunk data model before deployment.

Rule Name

Spring AI Endpoint Iterative Targeting and Abuse Window

Purpose
Detect repeated targeting of Spring AI-enabled routes consistent with probing, prompt-refinement attempts, or repeated adversary interaction intended to drive abnormal downstream execution behavior.

ATT&CK Technique
T1190 – Exploit Public-Facing Application

Telemetry Dependency

·        Application or API logs containing route, method, response status, source identity, and timing

·        Reliable identification of Spring AI-enabled endpoints

·        Baseline knowledge of ordinary request frequency and sequencing for protected AI features

Tuning Explanation
This rule must be restricted to Spring AI-enabled routes only. It should detect short-window targeting behavior that exceeds normal user or application interaction patterns, especially where the same source repeatedly accesses protected AI endpoints. Exclude internal testing, load generation, approved automation, and health-check traffic.

Detection Logic
Identify repeated access to Spring AI-enabled routes from the same source, session, or client context within a short interval where targeting behavior exceeds established baseline expectations.

Operational Context
This is an ingress-stage analytic. It is strongest when followed by:

·        suspicious JVM-child process creation on the destination host

·        irregular orchestration or tracing artifacts

·        outbound network anomalies after the targeting window

Logical Notes
This rule identifies suspicious targeting behavior against protected AI routes. It does not prove prompt-content abuse by itself.

Rule Regret Check

Deployment caution

·        Restrict to Spring AI-enabled routes only

·        Exclude approved automation, testing, and health checks

Confidence caution

·        Confidence depends on route fidelity and source attribution quality

·        High-volume legitimate clients may require role-based suppression

Coverage value

·        High for detecting repeated probing or abuse-window formation against protected AI endpoints

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <APP_LOG_INDEXES> and <APPROVED_APP_ENDPOINTS> with tenant values

·        Tune request thresholds to actual application behavior

·        Map source identity fields such as src_ip, client_id, session_id, or equivalent

Tenant-Adaptable Query Skeleton

index=<APP_LOG_INDEXES>
(route IN <APPROVED_APP_ENDPOINTS> OR uri_path IN <APPROVED_APP_ENDPOINTS>)
| bin time span=2m
| stats count as requestcount values(method) as methods values(status) as statuses by time host srcip client_id session_id route uri_path
| where request_count >= 10
| table time host srcip client_id session_id route uri_path request_count methods statuses

Rule Name

Spring AI Service Suspicious Child Process from JVM Lineage

Purpose
Detect suspicious child-process execution from Spring AI-enabled JVM service contexts where model-mediated backend execution results in host-level process creation outside the approved runtime profile.

ATT&CK Technique
T1059 – Command and Scripting Interpreter

Telemetry Dependency

·        Endpoint or EDR process telemetry with parent-child visibility

·        Accurate scoping of Spring AI-enabled systems

·        Baseline knowledge of legitimate JVM-child process behavior

Tuning Explanation
Focus on child processes launched from JVM, service wrappers, or approved hosting contexts where such behavior is unusual. This rule is strongest where the service should remain in-process and should not spawn shells, interpreters, or transfer utilities.

Detection Logic
Detect child-process creation from protected JVM or service parent lineage where the child belongs to a high-risk execution class and is not part of the approved runtime baseline.

Operational Context
This is one of the strongest Splunk execution analytics for this threat because it captures the host-level expression of attacker-influenced backend execution.

Logical Notes
This rule does not require prompt visibility. It is intended to identify execution drift from the protected service context.

Rule Regret Check

Deployment caution

·        Requires reliable parent-child normalization

·        Scope to Spring AI-enabled systems only

·        Exclude approved maintenance, deployment, and platform-support workflows

Confidence caution

·        Precision drops where service hosting layers are highly dynamic or poorly normalized

Coverage value

·        Very High for detecting application-context execution drift

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <EDR_INDEXES> and <SPRING_AI_HOST_SCOPE> with tenant values

·        Tune <APPROVED_PARENT_PROCESSES> and <APPROVED_CHILD_PROCESSES> to the local runtime model

·        Map process fields to the local EDR or Sysmon schema

Tenant-Adaptable Query Skeleton

index=<EDR_INDEXES> <SPRING_AI_HOST_SCOPE>
event_type="process_creation"
parent_process IN <APPROVED_PARENT_PROCESSES>
process_name IN ("bash","sh","python","python3","pwsh","powershell","curl","wget","nc","perl","ruby")
| lookup approved_child_processes parent_process process_name OUTPUT process_name as approved_child
| where isnull(approved_child)
| stats count min(_time) as first_seen max(_time) as last_seen by host user parent_process parent_cmdline process_name process_cmdline
| convert ctime(first_seen) ctime(last_seen)

Rule Name

Spring AI Service Credential Material Access from Suspicious Service Lineage

Purpose
Detect likely credential-material access from a Spring AI-enabled service context after suspicious execution, consistent with post-execution secret or token harvesting.

ATT&CK Technique
T1552 – Unsecured Credentials

Telemetry Dependency

·        Endpoint process telemetry with command-line visibility

·        Optional cloud audit logs for secret-access enrichment

·        Baseline knowledge of approved secret-access tooling and workflows

Tuning Explanation
Restrict this rule to protected service hosts and suspicious execution lineage. Focus on access to environment material, token-bearing files, cloud credential references, and local secret stores. Exclude approved vault clients, bootstrap routines, and service agents.

Detection Logic
Detect suspicious credential-material access commands executed from protected service lineage, especially when preceded by suspicious child-process or interpreter execution.

Operational Context
This analytic maps directly to a likely attacker objective after successful application-side execution.

Logical Notes
This rule is strongest when sequenced with suspicious child-process creation from the same service host.

Rule Regret Check

Deployment caution

·        Exclude approved bootstrap, vault, and secret-broker processes

·        Restrict to Spring AI service contexts only

Confidence caution

·        Diagnostics or troubleshooting may resemble credential discovery if exclusions are incomplete

Coverage value

·        Very High for identifying likely post-execution credential access from compromised services

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <APPROVED_SECRET_HANDLERS> with tenant-approved tooling

·        Tune credential-material indicators to the actual environment

·        Map process and cloud-audit fields to the local schema

Tenant-Adaptable Query Skeleton

index=<EDR_INDEXES> <SPRING_AI_HOST_SCOPE>
event_type="process_creation"
process_name IN ("bash","sh","cat","grep","find","env","printenv","python","python3")
(process_cmdline="*/proc/*/environ*" OR process_cmdline="*printenv*" OR process_cmdline="* env " OR process_cmdline="GITHUB_TOKEN*" OR process_cmdline="*AWS_ACCESS_KEY_ID*" OR process_cmdline="*AZURE_CLIENT_SECRET*" OR process_cmdline="*GOOGLE_APPLICATION_CREDENTIALS*" OR process_cmdline="*.docker/config.json*" OR process_cmdline="*.npmrc*" OR process_cmdline="*.env*")
parent_process IN <APPROVED_PARENT_PROCESSES>
| lookup approved_secret_handlers process_name parent_process OUTPUT process_name as approved_handler
| where isnull(approved_handler)
| stats count min(_time) as first_seen max(_time) as last_seen by host user parent_process process_name process_cmdline
| convert ctime(first_seen) ctime(last_seen)

Rule Name

Spring AI Suspicious Execution Followed by External Network Activity

Purpose
Detect suspicious process execution from a Spring AI-enabled service context followed within a short time window by outbound external network activity consistent with callback or exfiltration behavior.

ATT&CK Technique
T1071.001 – Application Layer Protocol: Web Protocols
T1041 – Exfiltration Over C2 Channel

Telemetry Dependency

·        Endpoint process telemetry

·        Network telemetry with stable host identity

·        Time-synchronized logs across endpoint and network sources

·        Destination baseline knowledge for protected services

Tuning Explanation
This rule must begin from suspicious execution, not from network traffic alone. It is intended to correlate suspicious process creation from a protected service with outbound external communication that is not part of the approved dependency or business network model.

Detection Logic
Detect suspicious process execution from protected service lineage followed within a short time window by outbound communication to non-approved external destinations.

Operational Context
This is a high-value host-plus-network sequence analytic. It is most effective where endpoint and network telemetry can be joined cleanly on host identity and time.

Logical Notes
This rule does not prove the content of any transfer. It materially raises confidence when tied to suspicious service-side process creation.

Rule Regret Check

Deployment caution

·        Requires host identity consistency across endpoint and network logs

·        Exclude approved external destinations and routine service integrations

Confidence caution

·        Confidence depends on host-correlation quality and destination allowlisting maturity

Coverage value

·        Very High where endpoint and network telemetry correlation is mature

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <NETWORK_INDEXES> and <APPROVED_EXTERNAL_DESTINATIONS> with tenant values

·        Validate host identity normalization across sources

·        Tune the correlation window to actual service behavior

System ready code

(
search index=<EDR_INDEXES> <SPRING_AI_HOST_SCOPE>
event_type="process_creation"
parent_process IN <APPROVED_PARENT_PROCESSES>
process_name IN ("bash","sh","python","python3","pwsh","powershell","curl","wget","nc")
| eval stage="suspicious_exec"
| table time host processname process_cmdline parent_process stage
)
| append [
search index=<NETWORK_INDEXES> <SPRING_AI_HOST_SCOPE>
direction="outbound"
| where destination NOT IN <APPROVED_EXTERNAL_DESTINATIONS>
| eval stage="outbound_net"
| table time host destination destip bytes_out stage
]
| transaction host maxspan=5m
| search stage="suspicious_exec" stage="outbound_net"
| table time host duration eventcount processname process_cmdline parent_process destination dest_ip bytes_out

Rule Name

Spring AI Utility Chain Expansion from Protected Service Context

Purpose
Detect execution of administrative, transfer, or system-enumeration utilities from Spring AI-enabled services where the tool chain is not part of the approved runtime model.

ATT&CK Technique
T1082 – System Information Discovery
T1059 – Command and Scripting Interpreter

Telemetry Dependency

·        Endpoint process telemetry with parent-child lineage

·        Command-line visibility

·        Baseline knowledge of approved utility execution from protected services

Tuning Explanation
This analytic is intended to identify post-execution expansion into environment discovery, collection staging, or transfer preparation. It should be tightly scoped and tuned against the approved service runtime baseline.

Detection Logic
Detect execution of inspection, transfer, or staging utilities from protected JVM or service lineage where those utilities are not part of the approved runtime model.

Operational Context
Use this as a post-execution expansion analytic, not as primary proof of compromise.

Logical Notes
This rule is especially valuable when it follows suspicious child-process or interpreter execution from the same host.

Rule Regret Check

Deployment caution

·        Requires strong baseline knowledge for approved utility execution

·        Exclude known support and observability tooling

Confidence caution

·        Utility execution can be noisy in loosely governed environments

Coverage value

·        High as a post-execution expansion detector

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace placeholder scopes and approved lists with tenant values

·        Tune the utility set to the actual environment

·        Validate parent-lineage assumptions in the local data model

Tenant-Adaptable Query Skeleton

index=<EDR_INDEXES> <SPRING_AI_HOST_SCOPE>
event_type="process_creation"
parent_process IN <APPROVED_PARENT_PROCESSES>
process_name IN ("whoami","id","uname","hostname","ps","netstat","ss","curl","wget","nc","tar","gzip","base64")
| lookup approved_child_processes parent_process process_name OUTPUT process_name as approved_child
| where isnull(approved_child)
| stats count min(_time) as first_seen max(_time) as last_seen by host user parent_process process_name process_cmdline
| convert ctime(first_seen) ctime(last_seen)

Splunk Final Caveat Statement

These rules are tenant-adaptable and production-grade in detection design, but they are not universally system-ready until the following are completed locally:

·        field mapping to the actual Splunk data model

·        protected-host and protected-route scoping

·        approved parent, child, and helper baseline population

·        approved external destination baseline population

·        exclusion tuning

·        live validation across application, endpoint, and network telemetry

Splunk Coverage Summary

Strongest Coverage Areas

·        repeated suspicious targeting of Spring AI routes

·        suspicious child-process creation from JVM service contexts

·        credential-material access after suspicious execution

·        process-plus-network correlation for callback or exfiltration

·        post-execution utility expansion from protected service hosts

Coverage Boundaries

·        does not directly prove prompt-content abuse without application payload logging

·        does not directly observe model reasoning

·        is strongest when correlated with application and orchestration telemetry

Elastic

Elastic Coverage Scope

Elastic functions as a cross-source detection and correlation layer for this threat when application, endpoint, and network telemetry are available in the same environment. For this Spring AI execution-path abuse model, Elastic is best used to detect:

·        repeated targeting of Spring AI-enabled routes consistent with iterative abuse attempts

·        suspicious child-process execution from JVM-hosted application services

·        suspicious interpreter execution from protected service lineage

·        credential-material access from suspicious service-linked execution

·        execution followed by external network communication

·        post-execution utility expansion from protected application services

Elastic does not directly prove prompt-content abuse or model reasoning unless the environment ingests:

·        application/API request logs

·        Spring AI orchestration telemetry

·        tracing data linking request handling to downstream function invocation

Elastic is therefore strongest when used as a sequence and correlation platform across application, endpoint, and network signals, not as a standalone source of exploit proof.

Tenant Adaptation Model

Replace these placeholders during deployment:

·        <SPRING_AI_HOST_SCOPE>

·        <APPROVED_APP_ENDPOINTS>

·        <APPROVED_PARENT_PROCESSES>

·        <APPROVED_ANCESTOR_PROCESSES>

·        <APPROVED_CHILD_PROCESSES>

·        <APPROVED_SECRET_HANDLERS>

·        <APPROVED_EXTERNAL_DESTINATIONS>

·        <APP_LOG_DATASETS>

·        <ENDPOINT_DATASETS>

·        <NETWORK_DATASETS>

Where fields differ locally, map the logic to the actual ECS-aligned or custom Elastic schema before deployment. In particular, validate local equivalents for fields such as:

·        process.name

·        process.parent.name

·        process.command_line

·        host.name

·        network.direction

·        destination.address

Do not assume ECS-perfect normalization without verification.

Rule Name

Spring AI Endpoint Iterative Targeting and Abuse Window

Purpose
Detect repeated short-window targeting of Spring AI-enabled routes consistent with probing, refinement, or repeated adversary interaction intended to create conditions for abnormal downstream execution.

ATT&CK Technique
T1190 – Exploit Public-Facing Application

Telemetry Dependency

·        Application or API logs containing route, method, response status, source identity, and timing

·        Reliable identification of Spring AI-enabled endpoints

·        Baseline knowledge of ordinary request cadence for protected AI features

Tuning Explanation
This rule must be restricted to Spring AI-enabled routes only. It should identify repeated or burst-style targeting inconsistent with ordinary use of AI-facing application features. Exclude internal health checks, approved automation, load tests, and development traffic. This detection requires a threshold-capable rule type, ES|QL aggregation, or equivalent counting layer. It should not be deployed as a raw single-event analytic.

Detection Logic
Detect repeated access to Spring AI-enabled routes from the same source, session, or client context within a short interval where targeting behavior exceeds local baseline expectations.

Operational Context
This is an ingress-stage analytic. It is strongest when correlated with:

·        suspicious JVM-child execution on the destination host

·        unusual orchestration or tracing artifacts

·        outbound communication following the same access window

Logical Notes
This rule identifies suspicious targeting of protected AI routes. It does not prove malicious prompt content by itself.

Rule Regret Check

Deployment caution

·        Restrict to Spring AI-enabled routes only

·        Exclude testing, health checks, and approved automation

·        Implement thresholding in the local Elastic rule type best suited to aggregation

Confidence caution

·        Confidence depends on route fidelity and source attribution quality

·        High-volume legitimate clients may require suppression or identity-aware tuning

Coverage value

·        High for detecting repeated probing or abuse-window formation against protected AI endpoints

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <APP_LOG_DATASETS> and <APPROVED_APP_ENDPOINTS> with tenant values

·        Tune thresholds to actual traffic patterns

·        Map source identity fields such as source.ip, user.id, session.id, client.id, or local equivalents

·        Implement the counting layer in threshold rule logic, ES|QL, or equivalent aggregation workflow

Tenant-Adaptable Query Skeleton

any where
  event.dataset in <APP_LOG_DATASETS> and
  url.path in <APPROVED_APP_ENDPOINTS>

Threshold Implementation Pattern

FROM <APP_LOG_DATASETS>
| WHERE url.path IN (<APPROVED_APP_ENDPOINTS>)
| STATS request_count = COUNT() BY host.name, source.ip, user.id, session.id, url.path, DATE_TRUNC(2 minutes, @timestamp)
| WHERE request_count >= 10

Rule Name

Spring AI Service Suspicious Child Process from JVM or Service-Host Lineage

Purpose
Detect suspicious child-process execution from Spring AI-enabled JVM or service-hosted contexts where model-mediated backend execution creates process lineage outside the approved runtime profile.

ATT&CK Technique
T1059 – Command and Scripting Interpreter

Telemetry Dependency

·        Elastic Defend, Sysmon, or equivalent endpoint telemetry

·        Accurate scoping of Spring AI-enabled systems

·        Baseline knowledge of legitimate JVM-child and service-host-child process behavior

Tuning Explanation
Focus on child processes launched from JVMs, service wrappers, container runtimes, or approved hosting contexts where such behavior is unusual. This rule is strongest where the service should remain in-process and should not spawn shells, interpreters, or transfer utilities. Exclude approved maintenance, deployment, and runtime-support workflows.

Detection Logic
Detect child-process creation from protected JVM, service-wrapper, or service-host lineage where the child belongs to a high-risk execution class and is not part of the approved runtime baseline.

Operational Context
This is one of the strongest Elastic execution analytics for this threat because it captures the host-level consequence of attacker-influenced backend execution.

Logical Notes
This rule does not require prompt visibility. It identifies execution drift from the protected service context. In containerized or orchestrated environments, ancestor or service-host lineage may be more reliable than immediate parent process alone.

Rule Regret Check

Deployment caution

·        Requires reliable parent-child or ancestor-process normalization

·        Scope to Spring AI-enabled systems only

·        Exclude approved maintenance, deployment, and platform-support workflows

Confidence caution

·        Precision drops where service hosting layers are highly dynamic or poorly normalized

Coverage value

·        Very High for detecting application-context execution drift

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <SPRING_AI_HOST_SCOPE>, <APPROVED_PARENT_PROCESSES>, and <APPROVED_ANCESTOR_PROCESSES> with tenant values

·        Exclude locally approved child and helper processes

·        Map fields to local ECS or custom endpoint schema

·        Use ancestor-process or lineage fields where immediate parent fidelity is weak

Tenant-Adaptable Query Skeleton

process where
  <SPRING_AI_HOST_SCOPE> and
  (
process.parent.name in <APPROVED_PARENT_PROCESSES> or
    process.Ext.ancestry in <APPROVED_ANCESTOR_PROCESSES>
  ) and
process.name in ("bash","sh","python","python3","pwsh","powershell","curl","wget","nc","perl","ruby") and
  not process.name in <APPROVED_CHILD_PROCESSES>

Rule Name

Spring AI Service Suspicious Interpreter Execution Refinement

Purpose
Refine detection of suspicious execution from protected service contexts by focusing specifically on shell or interpreter execution launched from Spring AI-enabled JVM or service-hosted lineage.

ATT&CK Technique
T1059 – Command and Scripting Interpreter

Telemetry Dependency

·        Elastic endpoint process telemetry

·        Command-line visibility

·        Parent, ancestor, or lineage telemetry

·        Reliable scoping of Spring AI-enabled systems

Tuning Explanation
This rule is a refinement layer on top of the broader child-process execution analytic. It is focused specifically on interpreter-driven execution where protected services are not expected to invoke shells or scripting engines during normal operation. Suppress approved support scripts, controlled operational workflows, and known-good maintenance jobs.

Detection Logic
Detect interpreter execution from protected service lineage when the command line or execution context is not part of the approved runtime baseline.

Operational Context
Use this as a refinement analytic for service contexts that should remain in-process and should not pivot into shell or scripting interpreters.

Logical Notes
This rule intentionally overlaps in telemetry source with the broader child-process rule, but narrows the focus to interpreter-class executions to improve triage clarity and execution-specific confidence.

Rule Regret Check

Deployment caution

·        Exclude approved support scripts and controlled operational workflows

·        Restrict to protected service hosts

Confidence caution

·        Confidence drops where support tooling regularly invokes interpreters from service contexts

Coverage value

·        High for execution behaviors likely to follow successful model-mediated abuse

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Tune command-line exclusions to the local environment

·        Validate actual service-lineage process names

·        Replace host-scoping placeholders with real asset selectors

·        Use ancestor or lineage fields where immediate parent fidelity is weak

Tenant-Adaptable Query Skeleton

process where
  <SPRING_AI_HOST_SCOPE> and
  (
process.parent.name in <APPROVED_PARENT_PROCESSES> or
    process.Ext.ancestry in <APPROVED_ANCESTOR_PROCESSES>
  ) and
process.name in ("bash","sh","python","python3","pwsh","powershell","node") and
  not process.command_line like~ ("*approved-script*","*approved-bootstrap*","*known-good-maintenance*")

Rule Name

Spring AI Service Credential Material Access from Suspicious Service Lineage

Purpose
Detect likely credential-material access from a Spring AI-enabled service context after suspicious execution, consistent with post-execution secret or token harvesting.

ATT&CK Technique
T1552 – Unsecured Credentials

Telemetry Dependency

·        Endpoint process telemetry with command-line visibility

·        Optional cloud-audit enrichment for secret access

·        Baseline knowledge of approved secret-access tooling and workflows

Tuning Explanation
Restrict this rule to protected service hosts and suspicious execution lineage. Focus on access to environment material, token-bearing files, cloud credential references, and local secret stores. Exclude approved vault clients, bootstrap routines, and service agents. This rule should not be used as a generic enterprise secret-access detector.

Detection Logic
Detect suspicious credential-material access commands executed from protected service lineage.

Operational Context
This analytic maps directly to a likely attacker objective after successful application-side execution.

Logical Notes
This rule is strongest when sequenced with suspicious child-process or interpreter execution.

Rule Regret Check

Deployment caution

·        Exclude approved bootstrap, vault, and secret-broker processes

·        Restrict to Spring AI service contexts only

Confidence caution

·        Diagnostics or troubleshooting may resemble credential discovery if exclusions are incomplete

Coverage value

·        Very High for identifying likely post-execution credential access from compromised services

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <APPROVED_SECRET_HANDLERS> with tenant-approved tooling

·        Tune credential-material indicators to the actual environment

·        Map process and cloud-audit fields to the local schema

Tenant-Adaptable Query Skeleton

process where
  <SPRING_AI_HOST_SCOPE> and
  (
process.parent.name in <APPROVED_PARENT_PROCESSES> or
    process.Ext.ancestry in <APPROVED_ANCESTOR_PROCESSES>
  ) and
process.name in ("bash","sh","cat","grep","find","env","printenv","python","python3") and
  (
    process.command_line like~ ("*/proc/*/environ*") or
    process.command_line like~ ("*printenv*") or
    process.command_line like~ ("*GITHUB_TOKEN*") or
    process.command_line like~ ("*AWS_ACCESS_KEY_ID*") or
    process.command_line like~ ("*AZURE_CLIENT_SECRET*") or
    process.command_line like~ ("*GOOGLE_APPLICATION_CREDENTIALS*") or
    process.command_line like~ ("*.docker/config.json*") or
    process.command_line like~ ("*.npmrc*") or
    process.command_line like~ ("*.env*")
  ) and
  not process.parent.name in <APPROVED_SECRET_HANDLERS>

Rule Name

Spring AI Suspicious Execution Followed by External Network Activity

Purpose
Detect suspicious process execution from a Spring AI-enabled service context followed within a short time window by outbound external network activity consistent with callback or exfiltration behavior.

ATT&CK Technique
T1071.001 – Application Layer Protocol: Web Protocols
T1041 – Exfiltration Over C2 Channel

Telemetry Dependency

·        Endpoint process telemetry

·        Network telemetry with stable host identity

·        Time-synchronized data across endpoint and network sources

·        Destination baseline knowledge for protected services

Tuning Explanation
This rule must begin from suspicious execution, not from network traffic alone. It is intended to correlate suspicious process creation from a protected service with outbound external communication not aligned to the approved dependency or business network model. Exclude approved service integrations and sanctioned external destinations. Host identity normalization across endpoint and network data is mandatory.

Detection Logic
Detect suspicious process execution from protected service lineage followed within a short interval by outbound communication to non-approved external destinations.

Operational Context
This is a high-value host-plus-network sequence analytic. It is most effective where endpoint and network telemetry can be joined cleanly on host identity and time.

Logical Notes
This rule does not prove the content of any transfer. It materially raises confidence when tied to suspicious service-side process creation.

Rule Regret Check

Deployment caution

·        Requires host identity consistency across endpoint and network logs

·        Exclude approved external destinations and routine service integrations

·        Do not deploy as production logic until host identity normalization is validated

Confidence caution

·        Confidence depends on host-correlation quality and destination allowlisting maturity

Coverage value

·        Very High where endpoint and network telemetry correlation is mature

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace <NETWORK_DATASETS> and <APPROVED_EXTERNAL_DESTINATIONS> with tenant values

·        Validate host identity normalization across sources as a mandatory prerequisite

·        Implement the sequence in EQL, ES|QL, or a rule builder that supports temporal correlation

Tenant-Adaptable Query Skeleton

sequence by host.name with maxspan=5m
  [process where
      <SPRING_AI_HOST_SCOPE> and
      (
process.parent.name in <APPROVED_PARENT_PROCESSES> or
        process.Ext.ancestry in <APPROVED_ANCESTOR_PROCESSES>
      ) and
process.name in ("bash","sh","python","python3","pwsh","powershell","curl","wget","nc")
  ]
  [network where
      event.dataset in <NETWORK_DATASETS> and
      <SPRING_AI_HOST_SCOPE> and
      network.direction == "outgoing" and
      destination.address != null and
      not destination.address in <APPROVED_EXTERNAL_DESTINATIONS>
  ]

Rule Name

Spring AI Utility Chain Expansion from Protected Service Context

Purpose
Detect execution of administrative, transfer, or system-enumeration utilities from Spring AI-enabled services where the tool chain is not part of the approved runtime model.

ATT&CK Technique
T1082 – System Information Discovery
T1059 – Command and Scripting Interpreter

Telemetry Dependency

·        Endpoint process telemetry with parent-child or ancestor lineage

·        Command-line visibility

·        Baseline knowledge of approved utility execution from protected services

Tuning Explanation
This analytic is intended to identify post-execution expansion into environment discovery, collection staging, or transfer preparation. It should be tightly scoped and tuned against the approved service runtime baseline. Exclude known support and observability tooling.

Detection Logic
Detect execution of inspection, transfer, or staging utilities from protected JVM or service lineage where those utilities are not part of the approved runtime model.

Operational Context
Use this as a post-execution expansion analytic, not as primary proof of compromise.

Logical Notes
This rule is especially valuable when it follows suspicious child-process or interpreter execution from the same host.

Rule Regret Check

Deployment caution

·        Requires strong baseline knowledge for approved utility execution

·        Exclude known support and observability tooling

Confidence caution

·        Utility execution can be noisy in loosely governed environments

Coverage value

·        High as a post-execution expansion detector

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Replace placeholder scopes and approved lists with tenant values

·        Tune the utility set to the actual environment

·        Validate parent or ancestor lineage assumptions in the local data model

Tenant-Adaptable Query Skeleton

process where
  <SPRING_AI_HOST_SCOPE> and
  (
process.parent.name in <APPROVED_PARENT_PROCESSES> or
    process.Ext.ancestry in <APPROVED_ANCESTOR_PROCESSES>
  ) and
process.name in ("whoami","id","uname","hostname","ps","netstat","ss","curl","wget","nc","tar","gzip","base64") and
  not process.name in <APPROVED_CHILD_PROCESSES>

Elastic Final Caveat Statement

These rules are tenant-adaptable and production-grade in detection design, but they are not universally system-ready until the following are completed locally:

·        field mapping to the actual Elastic or ECS-aligned data model

·        protected-host and protected-route scoping

·        approved parent, ancestor, child, helper, and destination baseline population

·        local exclusion tuning

·        live validation across application, endpoint, and network telemetry

Elastic Coverage Summary

Strongest Coverage Areas

·        repeated suspicious targeting of Spring AI routes

·        suspicious child-process creation from JVM or service-host lineage

·        interpreter execution inconsistent with service runtime

·        credential-material access after suspicious execution

·        process-plus-network correlation for callback or exfiltration

·        post-execution utility expansion from protected service hosts

Coverage Boundaries

·        does not directly prove prompt-content abuse without application payload logging

·        does not directly observe model reasoning

·        is strongest when correlated with application and orchestration telemetry

QRadar

QRadar Coverage Scope

QRadar functions as a correlation and offense-generation platform for this threat when application, endpoint, and network telemetry are normalized into usable DSM fields and categories. For this Spring AI execution-path abuse model, QRadar is best used to detect:

·        iterative targeting of Spring AI-enabled routes

·        suspicious JVM-linked execution from endpoint telemetry

·        credential-material access behavior from service-linked execution

·        suspicious execution followed by outbound network activity

·        post-execution utility expansion from protected service contexts

QRadar does not directly observe:

·        prompt content unless application logs include it

·        model reasoning

·        internal Spring AI orchestration decisions without supporting application telemetry

Its strongest role is multi-event correlation through CRE, Building Blocks, and Reference Sets.

Tenant Adaptation Model

Replace these placeholders during deployment:

·        <SPRING_AI_HOST_SCOPE>

·        <APPROVED_APP_ENDPOINTS>

·        <APPROVED_PARENT_PROCESSES>

·        <APPROVED_ANCESTOR_PROCESSES>

·        <APPROVED_CHILD_PROCESSES>

·        <APPROVED_SECRET_HANDLERS>

·        <APPROVED_EXTERNAL_DESTINATIONS>

·        <APP_LOG_LOGSOURCES>

·        <EDR_LOGSOURCES>

·        <NETWORK_LOGSOURCES>

Validate DSM normalization and local equivalents for:

·        URL / URI / Request Path

·        Process Name

·        Parent Process / Process Path / Lineage surrogate

·        Command Line

·        Source IP / Username / Session

·        Destination IP / Domain

·        Event Category / QID

Use Reference Sets for approved destinations, approved processes, and protected endpoints. Use Building Blocks where repeated logic should be shared across rules.

Rule Name

Spring AI Endpoint Iterative Targeting and Abuse Window

Purpose
Detect repeated targeting of Spring AI-enabled endpoints consistent with probing, refinement, or repeated adversary interaction intended to create conditions for abnormal downstream execution.

ATT&CK Technique
T1190 – Exploit Public-Facing Application

Telemetry Dependency

·        Application/API logs parsed into QRadar

·        URL, URI, or endpoint fields normalized

·        Source identity fields such as IP, user, or session

·        CRE threshold logic support

Tuning Explanation
This rule must be implemented as a threshold-based CRE rule against application logs scoped to Spring AI routes. Exclude:

·        health checks

·        monitoring traffic

·        approved automation

·        load testing

Use a Reference Set for <APPROVED_APP_ENDPOINTS> or a Building Block matching protected AI routes.

Detection Logic
Generate an event match when requests target protected Spring AI routes. Trigger an offense only when repeated events from the same source exceed a defined threshold within a short time window.

Operational Context
Ingress-stage detection. Highest value when correlated with:

·        suspicious JVM-linked execution

·        downstream child-process creation

·        outbound network behavior from the same host

Logical Notes
This identifies abuse-window formation, not confirmed prompt-content exploitation.

Coverage Classification
Correlation-required

Rule Regret Check

Deployment caution

·        Requires CRE threshold logic and endpoint scoping

·        Do not deploy without excluding known automation and health-check traffic

Confidence caution

·        High-volume legitimate API consumers require tuning

Coverage value

·        High for identifying iterative targeting of protected AI endpoints

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Normalize route fields and source identity fields

·        Populate Reference Set for protected Spring AI endpoints

·        Tune threshold, for example 10 events within 2 minutes grouped by source

QRadar CRE-Ready Logic Pattern

·        Apply to Event Category: HTTP/API request events from <APP_LOG_LOGSOURCES>

·        Test: URL or URI matches Reference Set <APPROVED_APP_ENDPOINTS>

·        Grouped by: Source IP or session identifier

·        Condition: event count greater than or equal to 10 within 2 minutes

·        Response: create or contribute to offense

Rule Name

Spring AI Service Suspicious Child Process from JVM or Service-Host Lineage

Purpose
Detect suspicious child-process execution from Spring AI-enabled JVM or service-hosted contexts.

ATT&CK Technique
T1059 – Command and Scripting Interpreter

Telemetry Dependency

·        EDR or Sysmon-style process logs ingested into QRadar

·        Parent-child process mapping or lineage surrogate fields

·        Host scoping for Spring AI systems

Tuning Explanation
Focus on process-creation events where the originating process is a JVM, service wrapper, or service-host lineage associated with Spring AI workloads. Use a Reference Set or Building Block for approved parent processes and approved child processes. Where deep lineage is unavailable, fall back to service-host scoping plus process-path and command-line heuristics.

Detection Logic
Trigger when a high-risk process is launched from protected JVM or service-host lineage and is not part of the approved child-process baseline.

Operational Context
Primary execution-stage detection for this threat.

Logical Notes
If QRadar lacks reliable multi-level ancestry, use immediate parent plus protected-host scoping as the fallback model.

Coverage Classification
Standalone-capable

Rule Regret Check

Deployment caution

·        Requires process normalization through DSM or custom properties

·        Must scope to Spring AI systems only

Confidence caution

·        Reduced precision in container-heavy or wrapper-heavy environments without lineage enrichment

Coverage value

·        Very High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Normalize process-creation events into usable custom properties or QIDs

·        Define approved parent and child process Reference Sets

·        Tune lineage fallback where ancestor visibility is weak

QRadar CRE-Ready Logic Pattern

·        Apply to Event Category: Process Creation from <EDR_LOGSOURCES>

·        Test 1: Host matches <SPRING_AI_HOST_SCOPE>

·        Test 2: Parent Process in Reference Set <APPROVED_PARENT_PROCESSES> OR process lineage surrogate indicates approved service-host ancestry

·        Test 3: Process Name in high-risk execution set

·        Test 4: Process Name NOT in Reference Set <APPROVED_CHILD_PROCESSES>

·        Response: create offense or add to offense

Rule Name

Spring AI Service Suspicious Interpreter Execution Refinement

Purpose
Refine execution detection by isolating interpreter-class execution from protected service lineage.

ATT&CK Technique
T1059 – Command and Scripting Interpreter

Telemetry Dependency

·        Endpoint process telemetry

·        Command-line visibility

·        Parent or lineage fields

Tuning Explanation
This rule is a refinement layer over the broader suspicious child-process rule. It should only target interpreter-class executions such as shell, Python, Node, or PowerShell when launched from protected service lineage outside approved patterns.

Detection Logic
Trigger when interpreter-class execution occurs from protected service lineage and the command line is not part of the approved operational baseline.

Operational Context
Refinement analytic for execution-stage behavior.

Logical Notes
Use this rule to improve triage clarity and execution-specific confidence, not as a replacement for the broader child-process rule.

Coverage Classification
Standalone-capable, refinement-layer

Rule Regret Check

Deployment caution

·        Requires command-line visibility and exclusion tuning

·        Must exclude known-good interpreter usage

Confidence caution

·        Confidence drops in automation-heavy environments where interpreters are normal

Coverage value

·        High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Tune command-line exclusions

·        Define approved interpreter use cases and known-good scripts

QRadar CRE-Ready Logic Pattern

·        Apply to Event Category: Process Creation from <EDR_LOGSOURCES>

·        Test 1: Host matches <SPRING_AI_HOST_SCOPE>

·        Test 2: Parent Process in Reference Set <APPROVED_PARENT_PROCESSES> OR lineage surrogate indicates service-host ancestry

·        Test 3: Process Name in interpreter set

·        Test 4: Command Line NOT matches approved script patterns

·        Response: add to offense or increase magnitude on existing suspicious execution offense

Rule Name

Spring AI Service Credential Material Access from Suspicious Service Lineage

Purpose
Detect credential-material access following suspicious service-linked execution.

ATT&CK Technique
T1552 – Unsecured Credentials

Telemetry Dependency

·        Endpoint process logs

·        Command-line visibility

·        Optional cloud audit enrichment

Tuning Explanation
Focus on command lines and process activity indicating access to:

·        environment variables

·        credential files

·        token-bearing paths

·        cloud credential identifiers

Use a Reference Set or Building Block for approved secret handlers and vault tooling.

Detection Logic
Trigger when credential-access indicators occur from protected service lineage and are not associated with approved secret-handling processes.

Operational Context
Post-execution objective detection.

Logical Notes
Strongest when correlated with prior suspicious child-process or interpreter execution.

Coverage Classification
Standalone-capable, higher-confidence when correlated

Rule Regret Check

Deployment caution

·        Requires exclusion tuning for legitimate secret-handling workflows

·        Must scope to Spring AI service context

Confidence caution

·        Debugging or diagnostics can overlap if exclusions are incomplete

Coverage value

·        Very High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Define approved secret handlers

·        Tune credential-material indicators to the local environment

·        Normalize command-line fields

QRadar CRE-Ready Logic Pattern

·        Apply to Event Category: Process Creation from <EDR_LOGSOURCES>

·        Test 1: Host matches <SPRING_AI_HOST_SCOPE>

·        Test 2: Parent Process in <APPROVED_PARENT_PROCESSES> OR lineage surrogate indicates service-host ancestry

·        Test 3: Command Line contains credential-access indicators

·        Test 4: Parent or process NOT in Reference Set <APPROVED_SECRET_HANDLERS>

·        Response: create or add to offense

Rule Name

Spring AI Suspicious Execution Followed by External Network Activity

Purpose
Detect suspicious execution followed by outbound communication to non-approved destinations.

ATT&CK Technique
T1071.001 – Application Layer Protocol: Web Protocols
T1041 – Exfiltration Over C2 Channel

Telemetry Dependency

·        Endpoint telemetry

·        Network flow, proxy, or firewall logs

·        Host identity normalization across log sources

Tuning Explanation
This rule must be implemented as a multi-event CRE correlation rule or through a Building Block plus Reference Set workflow. Host identity normalization is mandatory. Approved external destinations must be maintained in a Reference Set.

Detection Logic
Trigger when suspicious execution from a protected service host is followed within a defined time window by outbound communication to a non-approved destination from the same host.

Operational Context
High-confidence multi-stage detection.

Logical Notes
Does not prove data content, but strongly indicates malicious progression when host identity and timing are reliable.

Coverage Classification
Correlation-required

Rule Regret Check

Deployment caution

·        Requires cross-log correlation and host identity normalization

·        Do not deploy until approved destination Reference Sets are populated

Confidence caution

·        Dependent on destination baselining and normalization quality

Coverage value

·        Very High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Normalize host identity across process and network logs

·        Define approved external destination Reference Sets

·        Configure CRE sequence timing, for example 5 minutes

QRadar CRE-Ready Logic Pattern

·        Building Block A: suspicious execution event from protected service host

·        Event B: outbound network event from same host where destination NOT IN <APPROVED_EXTERNAL_DESTINATIONS>

·        CRE correlation: Event B follows Building Block A within 5 minutes on same host

·        Response: create offense or increase offense magnitude

Rule Name

Spring AI Utility Chain Expansion from Protected Service Context

Purpose
Detect post-execution expansion into discovery, staging, or transfer preparation.

ATT&CK Technique
T1082 – System Information Discovery
T1059 – Command and Scripting Interpreter

Telemetry Dependency

·        Endpoint process logs

·        Parent or lineage fields

·        Command-line visibility

Tuning Explanation
Focus on utility execution such as:

·        system discovery

·        network inspection

·        transfer preparation

·        encoding or staging activity

Exclude approved support and observability tooling. Use Reference Sets for approved utilities where possible.

Detection Logic
Trigger when utility execution occurs from protected service lineage outside approved baseline.

Operational Context
Post-execution expansion detection.

Logical Notes
Supports detection of attacker progression after initial execution.

Coverage Classification
Standalone-capable

Rule Regret Check

Deployment caution

·        Requires baseline knowledge of approved service-host utility usage

·        Must exclude support tooling

Confidence caution

·        Can be noisy in loosely governed environments

Coverage value

·        High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Define approved utility Reference Sets

·        Tune utility indicators and exclusions

·        Validate lineage fallback if parent fields are weak

QRadar CRE-Ready Logic Pattern

·        Apply to Event Category: Process Creation from <EDR_LOGSOURCES>

·        Test 1: Host matches <SPRING_AI_HOST_SCOPE>

·        Test 2: Parent Process in <APPROVED_PARENT_PROCESSES> OR lineage surrogate indicates service-host ancestry

·        Test 3: Process Name in utility execution set

·        Test 4: Process Name NOT in Reference Set <APPROVED_CHILD_PROCESSES> or approved utilities

·        Response: create or add to offense

Final QRadar Caveat Statement

These rules are tenant-adaptable and production-grade in detection design, but they are not universally system-ready until the following are completed locally:

·        DSM normalization validation

·        custom property mapping for process, URL, command-line, and destination fields

·        protected-host and protected-endpoint scoping

·        approved parent, child, secret-handler, and destination Reference Set population

·        CRE threshold and sequence testing

·        live validation across application, endpoint, and network telemetry

Sigma

Sigma Coverage Scope

Sigma is the portable detection specification layer for this threat. For the Spring AI execution-path abuse model, Sigma is used to define:

·        suspicious execution behavior from Spring AI service contexts

·        interpreter-based execution anomalies

·        credential-material access indicators

·        post-execution utility expansion

·        backend-dependent ingress targeting analytics

·        backend-dependent execution-to-network correlation requirements

Sigma does not inherently support:

·        full multi-event correlation without backend support

·        native thresholding without backend aggregation

·        guaranteed field normalization across environments

·        portable asset scoping without backend-specific field mapping

Accordingly, Sigma rules here are:

Portable detection specifications that require backend implementation support, host scoping, and local field mapping.

Tenant Adaptation Model

Before deployment, map the following outside the Sigma rule body or during backend conversion:

·        protected Spring AI host scope

·        approved parent or service-host process lineage

·        approved child processes

·        approved secret handlers

·        approved AI endpoints

·        approved external destinations

Map fields depending on backend:

·        Image / process.executable / process.name

·        ParentImage / process.parent.executable / process.parent.name

·        CommandLine / process.command_line

·        Computer / host.name

·        DestinationIp / destination.ip

·        cs-uri-stem / url.path

Do not assume backend field normalization is complete without validation.

Rule Name

Suspicious Child Process from Spring AI Service Context

Purpose
Detect abnormal process execution from JVM or service-hosted Spring AI environments.

ATT&CK Technique
T1059 – Command and Scripting Interpreter

Coverage Classification
Standalone-capable

title: Suspicious Child Process from Spring AI Service Context
id: sigma-springai-child-process
status: experimental
logsource:
  category: process_creation
  product: any
detection:
  selection_parent:
    ParentImage|endswith:
      - '\java.exe'
      - '/java'
      - '\javaw.exe'
      - '\jsvc.exe'
      - '\tomcat.exe'
      - '\catalina.exe'
      - '\docker.exe'
      - '\containerd-shim.exe'
      - '\podman.exe'
  selection_child:
    Image|endswith:
      - '\bash.exe'
      - '/bash'
      - '\sh.exe'
      - '/sh'
      - '\python.exe'
      - '\python3.exe'
      - '\pwsh.exe'
      - '\powershell.exe'
      - '\curl.exe'
      - '\wget.exe'
      - '\nc.exe'
      - '\perl.exe'
      - '\ruby.exe'
  condition: selection_parent and selection_child
fields:
  - Image
  - ParentImage
  - CommandLine
falsepositives:
  - Approved deployment tooling
  - Approved service maintenance workflows
level: high

Deployment mapping requirement
Scope this rule to protected Spring AI systems in the backend. Implement approved-child filtering during backend conversion or SIEM filtering.

Rule Name

Interpreter Execution Refinement from Spring AI Service Context

Purpose
Refine detection by isolating interpreter-driven execution from protected service lineage.

ATT&CK Technique
T1059 – Command and Scripting Interpreter

Coverage Classification
Standalone-capable, refinement-layer

title: Interpreter Execution Refinement from Spring AI Service Context
id: sigma-springai-interpreter
status: experimental
logsource:
  category: process_creation
  product: any
detection:
  selection_parent:
    ParentImage|endswith:
      - '\java.exe'
      - '/java'
      - '\javaw.exe'
      - '\jsvc.exe'
      - '\tomcat.exe'
      - '\catalina.exe'
      - '\docker.exe'
      - '\containerd-shim.exe'
      - '\podman.exe'
  selection_interpreter:
    Image|endswith:
      - '\bash.exe'
      - '/bash'
      - '\sh.exe'
      - '/sh'
      - '\python.exe'
      - '\python3.exe'
      - '\pwsh.exe'
      - '\powershell.exe'
      - '\node.exe'
      - '/node'
  condition: selection_parent and selection_interpreter
fields:
  - Image
  - ParentImage
  - CommandLine
falsepositives:
  - Approved support scripts
  - Controlled maintenance jobs
level: high

Deployment mapping requirement
Use this as a refinement rule layered over the broader child-process analytic. Apply host scoping and approved-script filtering in the backend.

Rule Name

Credential Material Access from Spring AI Service Lineage

Purpose
Detect credential-access attempts from suspicious service-linked execution contexts.

ATT&CK Technique
T1552 – Unsecured Credentials

Coverage Classification
Standalone-capable

title: Credential Material Access from Spring AI Service Lineage
id: sigma-springai-credential-access
status: experimental
logsource:
  category: process_creation
  product: any
detection:
  selection_proc:
    Image|endswith:
      - '\bash.exe'
      - '/bash'
      - '\sh.exe'
      - '/sh'
      - '\python.exe'
      - '\python3.exe'
      - '\cat.exe'
      - '/cat'
      - '\grep.exe'
      - '/grep'
      - '\find.exe'
      - '/find'
      - '\env.exe'
      - '/env'
      - '\printenv.exe'
  selection_cmd:
    CommandLine|contains:
      - '/proc/self/environ'
      - 'AWS_ACCESS_KEY_ID'
      - 'AZURE_CLIENT_SECRET'
      - 'GOOGLE_APPLICATION_CREDENTIALS'
      - 'GITHUB_TOKEN'
      - 'printenv'
      - '.env'
      - '.docker/config.json'
      - '.npmrc'
  condition: selection_proc and selection_cmd
fields:
  - Image
  - ParentImage
  - CommandLine
falsepositives:
  - Approved secret bootstrap routines
  - Debugging activity
level: high

Deployment mapping requirement
Apply protected-host scoping and approved-secret-handler exclusions in the backend or conversion pipeline.

Rule Name

Utility Expansion from Spring AI Service Context

Purpose
Detect post-execution expansion behavior from protected service contexts.

ATT&CK Technique
T1082 – System Information Discovery

Coverage Classification
Standalone-capable

title: Utility Expansion from Spring AI Service Context
id: sigma-springai-utility-chain
status: experimental
logsource:
  category: process_creation
  product: any
detection:
  selection_parent:
    ParentImage|endswith:
      - '\java.exe'
      - '/java'
      - '\javaw.exe'
      - '\jsvc.exe'
      - '\tomcat.exe'
      - '\catalina.exe'
      - '\docker.exe'
      - '\containerd-shim.exe'
      - '\podman.exe'
  selection_tools:
    Image|endswith:
      - '\whoami.exe'
      - '/whoami'
      - '\id.exe'
      - '/id'
      - '\uname.exe'
      - '/uname'
      - '\hostname.exe'
      - '/hostname'
      - '\ps.exe'
      - '/ps'
      - '\netstat.exe'
      - '/netstat'
      - '\ss.exe'
      - '/ss'
      - '\curl.exe'
      - '\wget.exe'
      - '\tar.exe'
      - '\base64.exe'
  condition: selection_parent and selection_tools
fields:
  - Image
  - ParentImage
  - CommandLine
falsepositives:
  - Approved admin or support tooling
level: medium

Deployment mapping requirement
Apply protected-host scoping and approved-utility exclusions in the backend.

Rule Name

Repeated Targeting of Spring AI Endpoints Event Selector

Purpose
Define the event selector for repeated targeting behavior against Spring AI endpoints.

ATT&CK Technique
T1190 – Exploit Public-Facing Application

Coverage Classification
Correlation-required

title: Repeated Targeting of Spring AI Endpoints Event Selector
id: sigma-springai-endpoint-targeting
status: experimental
logsource:
  category: webserver
  product: any
detection:
  selection_path:
    cs-uri-stem|contains:
      - '/ai/'
      - '/prompt/'
      - '/completion'
      - '/chat'
  condition: selection_path
fields:
  - cs-uri-stem
  - src_ip
  - cs-method
falsepositives:
  - Approved health checks
  - Load testing
level: medium

Backend implementation requirement
This is an event selector, not a complete detection by itself. Actual detection requires backend aggregation such as:

·        count by source over a short window

·        threshold tuned to local application behavior

·        host or route scoping to protected Spring AI services

Rule Name

Suspicious Execution Event Selector for Network Correlation

Purpose
Define the execution-side selector needed for backend correlation with outbound network activity.

ATT&CK Technique
T1071.001 – Application Layer Protocol: Web Protocols
T1041 – Exfiltration Over C2 Channel

Coverage Classification
Correlation-required

title: Suspicious Execution Event Selector for Network Correlation
id: sigma-springai-exec-network-selector
status: experimental
logsource:
  category: process_creation
  product: any
detection:
  selection_exec:
    Image|endswith:
      - '\bash.exe'
      - '/bash'
      - '\python.exe'
      - '\python3.exe'
      - '\powershell.exe'
      - '\curl.exe'
      - '\wget.exe'
  condition: selection_exec
fields:
  - Computer
  - Image
  - ParentImage
  - CommandLine
falsepositives:
  - Legitimate scripting from protected services
level: medium

Backend implementation requirement
This is not a full standalone Sigma correlation rule. Pair it in the backend with:

·        outbound network telemetry

·        host identity normalization

·        destination allowlisting

·        temporal correlation logic

Final Sigma Caveat Statement

These rules are:

·        true Sigma rules or true Sigma event selectors

·        portable detection specifications

·        backend-dependent for thresholding, correlation, scoping, and allowlisting

They are not directly deployable detections until:

·        protected-host scoping is mapped

·        field mappings are validated

·        backend aggregation logic is implemented

·        allowlists and filters are populated

·        backend sequence logic is configured where required

YARA

YARA Coverage Scope

YARA serves as a file and content artifact detection layer for this threat. In the Spring AI execution-path abuse model, YARA is best used to identify:

·        dropped shell or Python helper scripts written by abused application contexts

·        suspicious credential-harvesting scripts or environment-dumping artifacts

·        post-execution utility bundles or staging content

·        suspicious script content written into temporary, working, or service-accessible directories

YARA does not directly detect:

·        prompt abuse in transit

·        model reasoning

·        Spring AI orchestration decisions

·        process execution without a file or memory artifact

·        execution-to-network correlation

Accordingly, YARA’s role is post-execution artifact detection, not primary runtime detection.

Tenant Adaptation Model

Replace or tune these elements during deployment:

·        <SPRING_AI_FILE_SCOPE>

·        <APPROVED_SCRIPT_PATHS>

·        <APPROVED_TMP_PATHS>

·        <APPROVED_TOOLING_MARKERS>

·        <APPROVED_ADMIN_SCRIPT_MARKERS>

Deployment must validate:

·        which service paths are writable by the protected application

·        whether the environment scans files only, memory only, or both

·        whether temporary files, generated scripts, or staged content are retained long enough to scan

·        which approved automation scripts could overlap with these detections

Do not deploy these rules globally without path scoping and allowlist review.

Rule Name

Spring AI Dropped Script with Credential Harvesting Indicators

Purpose
Detect dropped or staged script artifacts containing credential-access behavior consistent with post-execution harvesting from a compromised Spring AI service context.

ATT&CK Technique
T1552 – Unsecured Credentials

Coverage Classification
Standalone-capable

Tuning Explanation
This rule is intended for files written into temporary, working, upload, or service-controlled paths after suspicious execution. It is not intended for broad workstation or enterprise-wide content scanning. Suppress approved administration and bootstrap scripts that legitimately reference environment variables or secret locations.

Detection Logic
Match script content that combines:

·        scripting language structure

·        environment or credential access terms

·        command or file access behavior consistent with secret harvesting

Operational Context
This is a post-execution artifact rule. It is strongest when correlated with:

·        suspicious child-process execution

·        interpreter execution

·        credential-access process telemetry

Logical Notes
This rule detects suspicious script content written to disk. It does not prove that the script executed.

Rule Regret Check

Deployment caution

·        Restrict scanning to service-writable or temporary paths tied to Spring AI workloads

·        Exclude known-good administration, bootstrap, and observability scripts

Confidence caution

·        Standalone hits can overlap with legitimate operational scripts if path scoping is weak

Coverage value

·        High for identifying post-execution credential-harvesting artifacts

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Scope scanning to protected service file paths

·        Exclude approved automation and bootstrap content

·        Tune markers to local scripting languages and operating systems

System-Ready Code

rule springai_dropped_script_credential_harvest
{
meta:
description = "Detect dropped script artifacts with credential harvesting indicators linked to Spring AI service abuse"
author = "CyberDax"
confidence = "high"
scope = "service-path-scoped"

strings:
$py1 = "import os" ascii
$py2 = "os.environ" ascii
$sh1 = "printenv" ascii
$sh2 = "/proc/self/environ" ascii
$cred1 = "AWS_ACCESS_KEY_ID" ascii
$cred2 = "AZURE_CLIENT_SECRET" ascii
$cred3 = "GOOGLE_APPLICATION_CREDENTIALS" ascii
$cred4 = "GITHUB_TOKEN" ascii
$file1 = ".docker/config.json" ascii
$file2 = ".npmrc" ascii
$file3 = ".env" ascii

condition:
(1 of ($py*) or 1 of ($sh*)) and 2 of ($cred*,$file*)
}

Rule Name

Spring AI Dropped Interpreter Helper or Execution Wrapper

Purpose
Detect helper scripts or lightweight execution wrappers likely written to disk to extend command execution from a compromised Spring AI service context.

ATT&CK Technique
T1059 – Command and Scripting Interpreter

Coverage Classification
Standalone-capable

Tuning Explanation
This rule is intended to identify small shell, Python, or PowerShell helper content that performs execution, download, encoding, or command dispatch functions. It should be scoped to service-writable paths and exclude approved operational tooling.

Detection Logic
Match files containing:

·        interpreter or wrapper structure

·        execution or subprocess behavior

·        transfer, encoding, or command-launching indicators

Operational Context
Use this rule to detect execution-enablement artifacts created after initial service-side abuse.

Logical Notes
This rule is a file-content detector for execution wrappers, not a runtime execution detector.

Rule Regret Check

Deployment caution

·        Restrict to service-owned writable paths and temporary execution directories

·        Exclude approved helper scripts used by deployment or support tooling

Confidence caution

·        Lightweight helper scripts can resemble legitimate operational automation without path scoping

Coverage value

·        High for identifying attacker-authored or attacker-staged execution wrappers

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Tune path scope and approved helper exclusions

·        Validate overlap with legitimate script-generation workflows

System-Ready Code

rule springai_dropped_execution_wrapper
{
    meta:
        description = "Detect dropped helper scripts or wrappers that support post-execution activity from Spring AI service contexts"
        author = "CyberDax"
        confidence = "medium-high"
        scope = "service-path-scoped"

    strings:
        $py1 = "subprocess" ascii
        $py2 = "os.system(" ascii
        $py3 = "Popen(" ascii
        $sh1 = "curl " ascii
        $sh2 = "wget " ascii
        $sh3 = "chmod +x" ascii
        $ps1 = "Start-Process" ascii
        $ps2 = "Invoke-Expression" ascii
        $enc1 = "base64" ascii
        $enc2 = "tar " ascii

    condition:
        2 of ($py*,$sh*,$ps*,$enc*)
}

Rule Name

Spring AI Post-Execution Utility and Staging Artifact

Purpose
Detect file artifacts consistent with post-execution discovery, staging, or transfer preparation following service-context abuse.

ATT&CK Technique
T1082 – System Information Discovery
T1041 – Exfiltration Over C2 Channel

Coverage Classification
Standalone-capable

Tuning Explanation
This rule is intended for staged scripts or command bundles written to disk that include combinations of host discovery, packaging, transfer, or encoding logic. It should not be used as a broad scan of all scripts across the enterprise.

Detection Logic
Match content combining:

·        host or environment discovery terms

·        packaging or encoding terms

·        transfer-related commands or utilities

Operational Context
This rule helps identify attacker progression after initial execution.

Logical Notes
This rule detects staged content, not network transmission itself.

Rule Regret Check

Deployment caution

·        Scope to protected application paths and temporary directories

·        Exclude approved admin and diagnostics bundles

Confidence caution

·        Some support bundles may overlap if environment scoping is not tight

Coverage value

·        Medium to High for post-execution staging artifacts

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Restrict scanning to protected service file locations

·        Exclude known diagnostic, packaging, and admin artifacts

System-Ready Code

rule springai_post_execution_staging_artifact
{
    meta:
        description = "Detect staged discovery and transfer preparation artifacts associated with Spring AI service abuse"
        author = "CyberDax"
        confidence = "medium"
        scope = "service-path-scoped"

    strings:
        $disc1 = "whoami" ascii
        $disc2 = "uname" ascii
        $disc3 = "hostname" ascii
        $disc4 = "netstat" ascii
        $disc5 = "ps " ascii
        $stage1 = "tar " ascii
        $stage2 = "gzip" ascii
        $stage3 = "base64" ascii
        $xfer1 = "curl " ascii
        $xfer2 = "wget " ascii
        $xfer3 = "nc " ascii

    condition:
        2 of ($disc*) and 1 of ($stage*,$xfer*)
}

Rule Name

Spring AI Temporary Script with Environment Dumping Pattern

Purpose
Detect temporary script content written to disk that appears designed to dump environment variables or enumerate application runtime context.

ATT&CK Technique
T1552 – Unsecured Credentials
T1082 – System Information Discovery

Coverage Classification
Standalone-capable

Tuning Explanation
This rule is specifically intended for temporary directories or service-generated script locations where attacker-authored content may briefly appear. It should be paired with file path restrictions and retention-aware scanning.

Detection Logic
Match small scripts or text artifacts that combine environment dumping with host or runtime enumeration.

Operational Context
Useful where protected services can write temporary files before or during command execution.

Logical Notes
This rule is valuable in environments where dropped artifacts are short-lived but still scanned by host or file-monitoring workflows.

Rule Regret Check

Deployment caution

·        Requires temporary path visibility and timely scanning

·        Exclude legitimate diagnostic bundles and support scripts

Confidence caution

·        Temporary diagnostic scripts can overlap if exclusions are weak

Coverage value

·        High for ephemeral post-execution script artifacts when scanning coverage is good

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        Tune to temporary path coverage and scan timing

·        Exclude approved support and diagnostics content

System-Ready Code

rule springai_temp_env_dump_script
{
    meta:
        description = "Detect temporary environment-dumping script artifacts linked to Spring AI service abuse"
        author = "CyberDax"
        confidence = "high"
        scope = "temporary-path-scoped"

    strings:
        $a1 = "printenv" ascii
        $a2 = "/proc/self/environ" ascii
        $a3 = "os.environ" ascii
        $b1 = "whoami" ascii
        $b2 = "hostname" ascii
        $b3 = "uname" ascii
        $b4 = "pwd" ascii

    condition:
        1 of ($a*) and 2 of ($b*)
}

YARA Backend Dependency Requirement

Not a standalone YARA rule

Purpose
Define how YARA should be operationalized for this threat.

Coverage Classification
Correlation-required

Implementation Requirement
YARA detections in this threat model should be paired in the backend with:

·        protected Spring AI host or container scope

·        suspicious process execution from JVM or service-host lineage

·        file write events into service-writable or temporary paths

·        optional outbound network behavior following artifact creation

Operational Note
Without file path scoping, process correlation, or backend enrichment, YARA hits may be too broad or too slow to provide high-confidence detection.

AWS

AWS Coverage Scope

AWS provides identity, control-plane, data-plane, and network-layer visibility for this threat. In the Spring AI execution-path abuse model, AWS detections focus on:

·        secret and parameter access from protected workloads

·        IAM role misuse and anomalous role chaining

·        abnormal S3 access from protected application identities

·        abnormal outbound communication from protected workloads

·        native GuardDuty findings tied to protected workloads

AWS does not directly detect:

·        prompt input

·        model reasoning

·        Spring AI orchestration decisions

·        JVM child-process execution without endpoint telemetry

Accordingly, AWS is a post-execution cloud behavior and identity-abuse detection layer, not an initial exploit detector.

Tenant Adaptation Model

Replace during deployment:

·        <SPRING_AI_WORKLOAD_ROLES>

·        <SPRING_AI_WORKLOAD_SCOPE>

·        <APPROVED_SECRET_RESOURCES>

·        <APPROVED_PARAMETER_PATHS>

·        <APPROVED_S3_BUCKETS>

·        <APPROVED_EXTERNAL_DESTINATIONS>

·        <APPROVED_GUARDDUTY_RESOURCES>

Required telemetry should include, where applicable:

·        CloudTrail management events

·        CloudTrail data events for S3

·        Secrets Manager access logs through CloudTrail

·        SSM Parameter Store access through CloudTrail

·        VPC Flow Logs

·        Route 53 Resolver query logs where available

·        GuardDuty findings

Do not deploy these detections without:

·        workload scoping

·        IAM baseline mapping

·        resource classification

·        destination allowlisting

Rule Name

Secrets Manager Access Anomaly from Protected Workload

Purpose
Detect abnormal Secrets Manager retrieval behavior from protected Spring AI workloads indicating credential harvesting or secret discovery following post-execution abuse.

ATT&CK Technique
T1552 – Unsecured Credentials

Coverage Classification
Standalone-capable, baseline-dependent

Telemetry Dependency

·        CloudTrail

·        Secrets Manager API activity

·        role-to-workload mapping

·        secret inventory or protected resource classification

Tuning Explanation
This rule should not alert on every GetSecretValue call. It should be tuned to detect:

·        burst secret retrieval

·        access to multiple secrets in a short interval

·        access from workload roles outside expected secret-access patterns

·        access to secrets not normally used by the protected workload

Detection Logic
Detect protected workload roles retrieving secrets at a volume or diversity inconsistent with baseline behavior.

Operational Context
This is one of the highest-value AWS detections for this threat because successful service-side compromise commonly leads to secret retrieval under the workload’s existing permissions.

Logical Notes
This is a baseline-deviation detector, not a generic secret-access alert.

Rule Regret Check

Deployment caution

·        Requires workload-to-role mapping

·        Requires protected secret inventory or classification

·        Must exclude expected deployment, rotation, and bootstrap workflows

Confidence caution

·        Moderate without mature secret-access baselines

·        Some scaling or rollout workflows may legitimately spike secret access

Coverage value

·        Very High for post-execution credential harvesting

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected workload roles

·        define approved secret resources

·        baseline normal secret retrieval volume and diversity

System-Ready Code (CloudWatch Logs Insights)

fields @timestamp, eventSource, eventName,
       userIdentity.sessionContext.sessionIssuer.arn as role,
       requestParameters.secretId as secret_id,
       sourceIPAddress
| filter eventSource = "secretsmanager.amazonaws.com"
| filter eventName = "GetSecretValue"
| filter ispresent(role)
| stats count() as access_count,
        count_distinct(secret_id) as unique_secrets
        by role, bin(5m)
| filter access_count > 5 or unique_secrets > 2

Rule Name

SSM Parameter Store Sensitive Access Anomaly

Purpose
Detect abnormal retrieval of sensitive Parameter Store values from protected workloads.

ATT&CK Technique
T1552 – Unsecured Credentials

Coverage Classification
Standalone-capable, baseline-dependent

Telemetry Dependency

·        CloudTrail

·        SSM API activity

·        workload-role mapping

·        sensitive parameter path classification

Tuning Explanation
This rule should focus on:

·        sensitive parameter paths

·        unusual retrieval bursts

·        parameter access from roles not normally associated with those paths

·        retrieval outside expected service behavior

Examples of sensitive paths include:

·        /prod/

·        /secret/

·        /credential/

·        application-specific auth or database paths

Detection Logic
Detect protected workload roles retrieving sensitive parameters at a frequency or path diversity inconsistent with baseline.

Operational Context
This complements the Secrets Manager rule for environments storing sensitive values in Parameter Store instead of Secrets Manager.

Logical Notes
Keep this separate from the Secrets Manager analytic to preserve service-specific tuning.

Rule Regret Check

Deployment caution

·        Requires sensitive parameter path classification

·        Must exclude approved service startup and configuration bootstrap behavior

Confidence caution

·        Moderate without path-level baselines

·        Automation pipelines may legitimately access parameter paths in bursts

Coverage value

·        High for post-execution credential or configuration access

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define approved parameter paths

·        baseline expected role-to-path access

·        exclude approved bootstrap and deployment behavior

System-Ready Code (CloudWatch Logs Insights)

fields @timestamp, eventSource, eventName,
       userIdentity.sessionContext.sessionIssuer.arn as role,
requestParameters.name as parameter_name
| filter eventSource = "ssm.amazonaws.com"
| filter eventName in ["GetParameter","GetParameters"]
| filter parameter_name like /\/prod\/|\/secret|\/credential/
| filter ispresent(role)
| stats count() as access_count by role, parameter_name, bin(5m)
| filter access_count > 5

Rule Name

IAM Role Chaining and Anomalous AssumeRole Behavior

Purpose
Detect suspicious STS role assumption patterns from protected workload roles, including unusual role chaining, unexpected target roles, or anomalous frequency.

ATT&CK Technique
T1078 – Valid Accounts

Coverage Classification
Standalone-capable, baseline-dependent

Telemetry Dependency

·        CloudTrail

·        STS AssumeRole and AssumeRoleWithWebIdentity

·        source-role to target-role baseline

·        cross-account trust relationship inventory where applicable

Tuning Explanation
This rule should detect:

·        repeated AssumeRole activity in a short period

·        unexpected source-to-target role relationships

·        unexpected web identity role assumption

·        unusual cross-account assumption from protected workload roles

Detection Logic
Detect protected workload roles assuming roles at an abnormal rate or in anomalous source-to-target combinations.

Operational Context
This is a critical AWS-native identity-abuse rule for post-execution cloud pivoting.

Logical Notes
This should be correlated with secrets access, S3 access, or outbound network anomalies for high-confidence escalation.

Rule Regret Check

Deployment caution

·        Requires accurate source-role and target-role baseline modeling

·        Must account for expected microservice-to-microservice role transitions

Confidence caution

·        Moderate in complex service meshes or multi-account environments without mature baselines

Coverage value

·        Very High for workload identity abuse and privilege expansion

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        baseline source-role to target-role relationships

·        classify cross-account trust paths

·        classify expected web identity usage

System-Ready Code (Athena / CloudTrail)

SELECT
  useridentity.sessioncontext.sessionissuer.arn AS source_role,
  requestparameters.rolearn AS target_role,
  eventname,
  COUNT(*) AS assume_count
FROM cloudtrail_logs
WHERE eventsource = 'sts.amazonaws.com'
  AND eventname IN ('AssumeRole','AssumeRoleWithWebIdentity')
GROUP BY source_role, target_role, eventname, date_trunc('minute', eventtime)
HAVING COUNT(*) > 3

Rule Name

S3 Access Anomaly from Application Role

Purpose
Detect abnormal S3 access from protected application roles consistent with collection, staging, or sensitive data retrieval.

ATT&CK Technique
T1537 – Transfer Data to Cloud Account
T1552 – Unsecured Credentials

Coverage Classification
Standalone-capable, baseline-dependent

Telemetry Dependency

·        CloudTrail S3 data events

·        role-to-bucket baseline

·        protected bucket inventory and sensitive prefix classification

Tuning Explanation
This rule should detect:

·        burst object retrieval

·        high object diversity

·        unusual bucket access by protected roles

·        unusual use of ListBucket followed by object retrieval

·        access to sensitive prefixes such as configs, exports, backups, or archives

Detection Logic
Detect protected workload roles accessing S3 buckets or objects at a volume or diversity inconsistent with baseline.

Operational Context
This is a strong post-execution collection and staging rule for workloads that retain S3 access.

Logical Notes
Requires S3 data events. Without them, visibility is materially reduced.

Rule Regret Check

Deployment caution

·        Requires S3 data event logging

·        Requires bucket and prefix classification

·        Must exclude expected batch access patterns

Confidence caution

·        Moderate in data-heavy workloads without strong access baselines

Coverage value

·        High for collection or staging activity

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected buckets and sensitive prefixes

·        baseline role-to-bucket and object access

·        tune access-count and object-diversity thresholds

System-Ready Code (CloudWatch Logs Insights)

fields @timestamp,
       userIdentity.sessionContext.sessionIssuer.arn as role,
       requestParameters.bucketName as bucket,
       requestParameters.key as object_key,
       eventName
| filter eventSource = "s3.amazonaws.com"
| filter eventName in ["GetObject","ListBucket"]
| filter ispresent(role)
| stats count() as access_count,
        count_distinct(object_key) as unique_objects
        by role, bucket, bin(5m)
| filter access_count > 20 or unique_objects > 10

Rule Name

Outbound Network Anomaly from Protected Workload

Purpose
Detect abnormal outbound communication from protected AWS workloads to destinations outside the approved service dependency model.

ATT&CK Technique
T1071.001 – Web Protocols
T1041 – Exfiltration

Coverage Classification
Standalone-capable, baseline-dependent, correlation-enhanced

Telemetry Dependency

·        VPC Flow Logs

·        workload IP-to-identity mapping

·        destination baseline

·        optionally Route 53 Resolver query logs for domain-aware tuning

Tuning Explanation
This rule should not rely only on raw IP lists. It should be tuned with:

·        approved destination IPs or prefixes

·        known AWS service endpoints

·        known SaaS dependencies

·        optional DNS/domain baselines if available

It should detect:

·        burst outbound connections

·        high transfer volume

·        unusual destination spread

·        egress from protected workloads inconsistent with baseline

Detection Logic
Detect protected workload source addresses communicating with unusual destination patterns or transfer volumes.

Operational Context
This is the primary AWS-native network layer for callback or exfiltration-like post-execution behavior.

Logical Notes
Very strong when correlated with identity anomalies or secret retrieval.

Rule Regret Check

Deployment caution

·        Requires protected workload source scoping

·        Requires destination allowlisting or baseline modeling

·        Must account for normal cloud dependencies and NAT behavior

Confidence caution

·        Moderate without destination baselines

·        CDN-backed or dynamic SaaS dependencies can create noise

Coverage value

·        Very High when tuned and correlated

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected workload source ranges

·        define approved destinations or service classes

·        baseline normal egress destinations and volume

System-Ready Code (Athena / VPC Flow Logs)

SELECT
  srcaddr,
  dstaddr,
  date_trunc('minute', from_unixtime(start)) AS minute_window,
  COUNT(*) AS connections,
  SUM(bytes) AS total_bytes
FROM vpc_flow_logs
WHERE action = 'ACCEPT'
GROUP BY srcaddr, dstaddr, minute_window
HAVING COUNT(*) > 50 OR SUM(bytes) > 50000000

Rule Name

GuardDuty High-Severity Threat Detection (Workload Scoped)

Purpose
Leverage GuardDuty as a high-signal cloud-native anomaly layer for protected workloads.

ATT&CK Technique
Multiple

Coverage Classification
Standalone-capable, correlation-enhanced

Telemetry Dependency

·        GuardDuty findings

·        protected workload mapping

·        finding-type filtering relevant to identity abuse, outbound communication, and credential misuse

Tuning Explanation
Do not alert on every GuardDuty finding. Restrict to:

·        high-severity findings

·        relevant finding families

·        protected workloads only

Examples include:

·        Backdoor:EC2/C&CActivity

·        Trojan:EC2/BlackholeTraffic

·        UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration

·        Recon:IAMUser/NetworkPermissions

Detection Logic
Escalate relevant high-severity GuardDuty findings affecting protected workloads.

Operational Context
This acts as a cloud-native anomaly amplifier and triage accelerator, not the sole detection source.

Logical Notes
GuardDuty quality depends on enabled data sources and workload mapping fidelity.

Rule Regret Check

Deployment caution

·        Requires GuardDuty enabled and integrated

·        Must map findings to protected workloads

·        Must suppress findings outside protected scope

Confidence caution

·        High for relevant protected findings, but dependent on GuardDuty coverage depth

Coverage value

·        High as a native anomaly confirmation layer

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        enable and ingest GuardDuty

·        define protected workload resources

·        define relevant finding families

System-Ready Code (CloudWatch Logs Insights / EventBridge)

fields @timestamp,
       detail.type as finding_type,
       detail.severity as severity,
       detail.resource.instanceDetails.instanceId as instance_id,
       detail.resource.accessKeyDetails.userName as principal
| filter source = "aws.guardduty"
| filter detail.severity >= 7
| filter detail.type in [
  "Backdoor:EC2/C&CActivity",
  "Trojan:EC2/BlackholeTraffic",
  "UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration",
  "Recon:IAMUser/NetworkPermissions"
]
| filter ispresent(instance_id) or ispresent(principal)

Execution-to-Cloud Correlation Requirement (AWS)

This is not a standalone AWS rule.

Correlate:

·        endpoint execution anomaly

·        with one or more AWS behaviors:

o   Secrets Manager anomaly

o   Parameter Store anomaly

o   IAM role anomaly

o   S3 anomaly

o   outbound network anomaly

o   GuardDuty finding

Join on:

·        instance ID

·        workload tag

·        IAM role

·        private IP

·        subnet

·        container / node mapping where relevant

This belongs in SIEM / XDR / centralized detection logic, not AWS-only rule logic.

Azure

Azure Coverage Scope

Azure is a post-execution identity, resource-access, and network-behavior layer for this threat. It is strongest for detecting:

·        managed identity abuse

·        service principal abuse

·        Key Vault access anomalies

·        Storage access anomalies

·        outbound network anomalies

·        Defender alerts tied to protected workloads

Azure does not directly detect prompt abuse or JVM child-process execution. That still belongs to endpoint and SIEM layers. This aligns with the threat model in your working report, which treats cloud telemetry as downstream behavior, not initial exploit evidence.

Tenant Adaptation Model

Replace during deployment:

·        <SPRING_AI_MANAGED_IDENTITIES>

·        <SPRING_AI_SERVICE_PRINCIPALS>

·        <SPRING_AI_KEYVAULTS>

·        <SPRING_AI_STORAGE_ACCOUNTS>

·        <SPRING_AI_SUBNETS_OR_IPS>

·        <APPROVED_EGRESS_DESTINATIONS>

·        <APPROVED_DEFENDER_ENTITIES>

If a table is unavailable in your tenant, use the fallback rule noted under that section instead of pretending the primary rule works.

Rule Name

Key Vault Secret, Key, or Certificate Access Anomaly from Protected Workload

Purpose
Detect suspicious access to Key Vault objects from protected Azure workloads.

ATT&CK Technique
T1552 – Unsecured Credentials

Coverage Classification
Standalone-capable, baseline-dependent

Telemetry Dependency

·        AZKVAuditLogs preferred

·        AzureDiagnostics only as fallback where Key Vault diagnostics still land there

·        protected workload identity mapping

·        protected vault inventory

Tuning Explanation
This rule should be scoped to:

·        approved Spring AI workload identities

·        approved Key Vault resources

·        expected workload-to-vault relationships

It should detect:

·        burst retrieval

·        first-seen object access

·        new vault access by a protected identity

Operational Context
High-value post-execution credential access signal.

Logical Notes
Microsoft documents AZKVAuditLogs as the Key Vault audit table. Use it first where available.

Rule Regret Check

Deployment caution

·        Requires workload identity scoping

·        Requires protected vault scoping

·        Requires at least a minimal baseline

Confidence caution

·        Legitimate startup, scale-out, or secret rotation workflows can spike retrievals

Coverage value

·        Very High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        populate protected identities

·        populate protected vault names

·        establish normal access volume by 5-minute window

System-Ready Code — Primary

let ProtectedIds = dynamic(["<SPRING_AI_MANAGED_IDENTITIES>", "<SPRING_AI_SERVICE_PRINCIPALS>"]);
let ProtectedVaults = dynamic(["<SPRING_AI_KEYVAULTS>"]);
AZKVAuditLogs
| where TimeGenerated > ago(15m)
| where OperationName has_any ("SecretGet", "KeyGet", "CertificateGet")
| extend CallerIdentity = tostring(Identity)
| where CallerIdentity in (ProtectedIds)
| where ResourceId hasany (ProtectedVaults)
| summarize access_count=count(), unique_targets=dcount(Id) by CallerIdentity, ResourceId, bin(TimeGenerated, 5m)
| where accesscount > 5 or unique_targets > 2

System-Ready Code — Fallback

let ProtectedVaults = dynamic(["<SPRING_AI_KEYVAULTS>"]);
AzureDiagnostics
| where TimeGenerated > ago(15m)
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName has_any ("SecretGet", "KeyGet", "CertificateGet")
| where Resource has_any (ProtectedVaults)
| extend CallerIdentity = coalesce(identity_claim_appid_g, identity_claim_oid_g, CallerIPAddress)
| summarize access_count=count(), unique_targets=dcount(ResourceId) by CallerIdentity, Resource, bin(TimeGenerated, 5m)
| where access_count > 5 or unique_targets > 2

Rule Name

Managed Identity Abuse Anomaly from Protected Workload

Purpose
Detect suspicious managed identity usage from protected workloads.

ATT&CK Technique
T1078 – Valid Accounts

Coverage Classification
Standalone-capable, baseline-dependent

Telemetry Dependency

·        AADManagedIdentitySignInLogs

·        managed identity inventory

·        expected resource access baseline

Microsoft’s table includes ServicePrincipalId, Identity, IPAddress, and ResourceDisplayName, which makes this a good fit for workload identity anomaly detection.

Tuning Explanation
Detect:

·        first-seen resource access

·        first-seen IPs

·        burst sign-ins

·        failure spikes

Operational Context
Strong signal for workload identity misuse, especially in AKS, App Service, Functions, and VM-managed identity patterns.

Logical Notes
Keep this separate from service principal logic. Microsoft exposes them in different tables for a reason.

Rule Regret Check

Deployment caution

·        Requires managed identity inventory

·        Requires resource baseline

·        Must exclude noisy non-protected identities

Confidence caution

·        Dynamic platform identities can be noisy without scoping

Coverage value

·        High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected managed identity object IDs

·        baseline normal resource access and IP diversity

System-Ready Code

let ProtectedMIs = dynamic(["<SPRING_AI_MANAGED_IDENTITIES>"]);
let Baseline =
    AADManagedIdentitySignInLogs
    | where TimeGenerated between (ago(14d) .. ago(1d))
    | where ServicePrincipalId in (ProtectedMIs)
    | summarize BaselineIPs=make_set(IPAddress, 256),
                BaselineResources=make_set(ResourceDisplayName, 256),
                BaselineCount=count()
      by ServicePrincipalId;
AADManagedIdentitySignInLogs
| where TimeGenerated > ago(15m)
| where ServicePrincipalId in (ProtectedMIs)
| summarize Signins=count(),
            Failures=countif(ResultType != "Success" and ResultType != "0"),
            WindowIPs=make_set(IPAddress, 256),
            WindowResources=make_set(ResourceDisplayName, 256)
  by ServicePrincipalId, Identity, bin(TimeGenerated, 5m)
| join kind=leftouter Baseline on ServicePrincipalId
| extend NewIPs = array_length(set_difference(WindowIPs, coalesce(BaselineIPs, dynamic([]))))
| extend NewResources = array_length(set_difference(WindowResources, coalesce(BaselineResources, dynamic([]))))
| where Signins > 10 or Failures >= 3 or NewIPs > 0 or NewResources > 0 or isempty(BaselineCount)

Rule Name

Service Principal Abuse Anomaly from Protected Application Context

Purpose
Detect suspicious service principal activity from protected Spring AI application contexts.

ATT&CK Technique
T1078 – Valid Accounts

Coverage Classification
Standalone-capable, baseline-dependent

Telemetry Dependency

·        AADServicePrincipalSignInLogs

·        service principal inventory

·        baseline application/resource usage

AADServicePrincipalSignInLogs includes ServicePrincipalId, AppId, IPAddress, and ResourceDisplayName, which is sufficient for meaningful anomaly detection if scoped properly.

Tuning Explanation
Detect:

·        first-seen target resources

·        first-seen IPs

·        burst sign-ins

·        failure spikes

Operational Context
Useful for App Service, Functions, automation identities, and app registrations used by protected workloads.

Logical Notes
Do not mix this with managed identity logic. Separate rule, separate baseline.

Rule Regret Check

Deployment caution

·        Requires service principal scoping

·        Requires baseline of normal target resources

Confidence caution

·        Shared automation principals can be noisy

Coverage value

·        High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected service principal object IDs

·        baseline resource and IP usage

System-Ready Code

let ProtectedSPs = dynamic(["<SPRING_AI_SERVICE_PRINCIPALS>"]);
let Baseline =
    AADServicePrincipalSignInLogs
    | where TimeGenerated between (ago(14d) .. ago(1d))
    | where ServicePrincipalId in (ProtectedSPs)
    | summarize BaselineIPs=make_set(IPAddress, 256),
                BaselineResources=make_set(ResourceDisplayName, 256),
                BaselineCount=count()
      by ServicePrincipalId;
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(15m)
| where ServicePrincipalId in (ProtectedSPs)
| summarize Signins=count(),
            Failures=countif(ResultType != "Success" and ResultType != "0"),
            WindowIPs=make_set(IPAddress, 256),
            WindowResources=make_set(ResourceDisplayName, 256)
  by ServicePrincipalId, AppId, bin(TimeGenerated, 5m)
| join kind=leftouter Baseline on ServicePrincipalId
| extend NewIPs = array_length(set_difference(WindowIPs, coalesce(BaselineIPs, dynamic([]))))
| extend NewResources = array_length(set_difference(WindowResources, coalesce(BaselineResources, dynamic([]))))
| where Signins > 10 or Failures >= 3 or NewIPs > 0 or NewResources > 0 or isempty(BaselineCount)

Rule Name

Azure Role Assignment or Privileged Access Change Affecting Protected Scope

Purpose
Detect suspicious role assignment changes affecting protected Azure resources.

ATT&CK Technique
T1098 – Account Manipulation

Coverage Classification
Standalone-capable

Telemetry Dependency

·        AzureActivity

·        protected resource scope

·        approved automation exclusions

Tuning Explanation
Focus on:

·        role assignment writes and deletes

·        changes to protected subscriptions, resource groups, or workload resources

·        repeated changes in short windows

Operational Context
Critical escalation signal if an attacker moves from workload compromise to privilege change.

Logical Notes
This is a real rule only if protected resource scope is defined.

Rule Regret Check

Deployment caution

·        Must exclude approved IaC / DevOps identities

·        Must scope to protected resource groups or resource IDs

Confidence caution

·        Change windows can generate legitimate hits

Coverage value

·        Very High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected resource groups and resource IDs

·        define approved automation callers

System-Ready Code

let ProtectedScopes = dynamic(["<SPRING_AI_RESOURCE_SCOPE>"]);
AzureActivity
| where TimeGenerated > ago(1d)
| where OperationNameValue has "Microsoft.Authorization/roleAssignments/write"
   or OperationNameValue has "Microsoft.Authorization/roleAssignments/delete"
| where ResourceId has_any (ProtectedScopes) or ResourceGroup has_any (ProtectedScopes)
| summarize change_count=count() by Caller, ResourceGroup, ResourceId, ActivityStatusValue, bin(TimeGenerated, 5m)
| where ActivityStatusValue == "Success" and change_count >= 1

Rule Name

Azure Storage Access Anomaly from Protected Application Context

Purpose
Detect unusual Azure Storage access from protected workloads consistent with collection or staging.

ATT&CK Technique
T1537 – Transfer Data to Cloud Account
T1552 – Unsecured Credentials

Coverage Classification
Standalone-capable, baseline-dependent

Telemetry Dependency

·        StorageBlobLogs

·        storage account classification

·        workload-to-storage baseline

Tuning Explanation
Detect:

·        high-volume reads

·        high unique-object access

·        first-seen storage account use

·        first-seen caller IP patterns

Operational Context
Strong data-access layer for post-execution cloud behavior.

Logical Notes
Tune separately for batch-heavy applications.

Rule Regret Check

Deployment caution

·        Requires protected storage account inventory

·        Requires baseline by caller IP or workload identity proxy

Confidence caution

·        Data-heavy services can be noisy

Coverage value

·        High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected storage accounts

·        baseline normal object access and caller IP patterns

System-Ready Code

let ProtectedStorage = dynamic(["<SPRING_AI_STORAGE_ACCOUNTS>"]);
let Baseline =
    StorageBlobLogs
    | where TimeGenerated between (ago(14d) .. ago(1d))
    | where AccountName in (ProtectedStorage)
    | summarize BaselineObjects=make_set(Uri, 512),
                BaselineCount=count()
      by AccountName, CallerIpAddress;
StorageBlobLogs
| where TimeGenerated > ago(15m)
| where AccountName in (ProtectedStorage)
| summarize access_count=count(),
            unique_objects=dcount(Uri),
            WindowObjects=make_set(Uri, 512)
  by AccountName, CallerIpAddress, AuthenticationType, bin(TimeGenerated, 5m)
| join kind=leftouter Baseline on AccountName, CallerIpAddress
| extend NewObjects = array_length(set_difference(WindowObjects, coalesce(BaselineObjects, dynamic([]))))
| where access_count > 20 or unique_objects > 10 or NewObjects > 5 or isempty(BaselineCount)

Rule Name

Outbound Network Destination Anomaly from Protected Azure Workload

Purpose
Detect abnormal outbound communication from protected Azure workloads.

ATT&CK Technique
T1071.001 – Web Protocols
T1041 – Exfiltration

Coverage Classification
Standalone-capable, baseline-dependent, correlation-enhanced

Telemetry Dependency

·        AZFWApplicationRule and AZFWNetworkRule preferred

·        NSGFlowLogs as fallback

·        protected workload subnet/IP mapping

·        destination baseline

Azure Firewall network and application rule tables are real Azure Monitor tables.

Tuning Explanation
Do not rely on IP-only allowlists. Prefer:

·        approved FQDNs

·        approved service classes

·        approved external domains

·        protected source subnet or IP scoping

Operational Context
Very strong when correlated with identity or secret-access anomalies.

Logical Notes
Use Azure Firewall path if available; fall back to NSG-only volume logic if not.

Rule Regret Check

Deployment caution

·        Requires source scoping

·        Requires destination baseline

·        Must account for Microsoft service endpoints and approved SaaS

Confidence caution

·        Dynamic cloud dependencies and CDN-backed services can be noisy

Coverage value

·        Very High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected source IPs/subnets

·        define approved destination FQDNs/domains

·        choose Azure Firewall or NSG implementation based on actual telemetry

System-Ready Code — Primary

let ProtectedSources = dynamic(["<SPRING_AI_SUBNETS_OR_IPS>"]);
union isfuzzy=true AZFWApplicationRule, AZFWNetworkRule
| where TimeGenerated > ago(15m)
| extend Src = coalesce(SourceIp, SourceIP_s)
| extend DstIP = coalesce(DestinationIp, DestinationIP_s)
| extend DstFqdn = coalesce(Fqdn, TargetUrl, FQDN_s)
| where Src in (ProtectedSources)
| summarize Connections=count(),
TotalBytes=sum(toint(coalesce(SentBytes, BytesSent_s, 0))),
DistinctFqdns=dcount(DstFqdn),
DistinctIPs=dcount(DstIP)
by Src, bin(TimeGenerated, 5m)
| where Connections > 50 or TotalBytes > 50000000 or DistinctFqdns > 10 or DistinctIPs > 10

System-Ready Code — Fallback

NSGFlowLogs
| where TimeGenerated > ago(15m)
| summarize Connections=count(), TotalBytes=sum(Bytes)
  by SrcIp_s, DestIp_s, bin(TimeGenerated, 5m)
| where Connections > 50 or TotalBytes > 50000000

Rule Name

Defender High-Signal Alert Correlated to Protected Workload

Purpose
Use Defender as a high-signal confirmation layer for protected workloads.

ATT&CK Technique
Multiple

Coverage Classification
Standalone-capable, correlation-enhanced

Telemetry Dependency

·        SecurityAlert

·        protected workload scope

·        relevant provider filtering

Tuning Explanation
Do not alert on every high-severity alert. Restrict to:

·        protected workloads

·        relevant providers

·        relevant alert themes such as credential abuse, suspicious execution side effects, cloud misuse, or exfil-like behavior

Operational Context
Use as a confirmation and triage accelerator, not as a primary rule family.

Logical Notes
This is only as good as Defender coverage in the tenant.

Rule Regret Check

Deployment caution

·        Must scope to protected entities

·        Must filter relevant providers and alert names

Confidence caution

·        Depends on Defender deployment depth

Coverage value

·        Medium to High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected entities

·        tune relevant provider set

·        tune relevant alert themes

System-Ready Code

let ProtectedEntities = dynamic(["<APPROVED_DEFENDER_ENTITIES>"]);
SecurityAlert
| where TimeGenerated > ago(1d)
| where AlertSeverity =~ "High"
| where ProviderName in ("Azure Defender","MDATP","MCAS","Microsoft Defender for Cloud")
| where AlertName has_any ("Credential","C2","Command","Suspicious","Exfil","Token","Identity","Key Vault","Storage")
      or Techniques has_any ("T1078","T1552","T1041","T1071")
| where CompromisedEntity has_any (ProtectedEntities) or ResourceId has_any (ProtectedEntities)
| project TimeGenerated, AlertName, AlertSeverity, ProviderName, CompromisedEntity, ResourceId, Techniques, Description

Execution-to-Cloud Correlation Requirement (Azure)

This is not a standalone Azure rule.

Correlate:

·        endpoint execution anomaly

·        with one or more Azure behaviors:

o   Key Vault anomaly

o   managed identity anomaly

o   service principal anomaly

o   storage anomaly

o   outbound network anomaly

o   Defender alert

Join on:

·        VM name

·        resource ID

·        managed identity

·        service principal

·        private IP

·        subnet

·        AKS node / namespace mapping

This belongs in Sentinel / SIEM / XDR, not Azure-only logic.

GCP

GCP Coverage Scope

GCP provides identity, control-plane, data-plane, and network telemetry for post-execution detection.

Focus:

·        Service account misuse

·        Secret access

·        Storage access

·        IAM escalation

·        Network egress

·        SCC high-signal confirmation

This is a post-execution behavioral detection layer only.

Tenant Adaptation Model

·        <SPRING_AI_SERVICE_ACCOUNTS>

·        <SPRING_AI_PROJECTS>

·        <SPRING_AI_SUBNETS>

·        <APPROVED_SECRET_PATTERNS>

·        <APPROVED_BUCKETS>

·        <APPROVED_DESTINATIONS>

Rule Name

GCP Secret Manager Access Anomaly (First-Seen + Burst + Diversity)

Purpose
Detect abnormal Secret Manager access patterns from protected workloads indicating credential harvesting or unauthorized secret discovery.

ATT&CK Technique
T1552 – Unsecured Credentials

Coverage Classification
Baseline-dependent, standalone-capable

Telemetry Dependency

·        Secret Manager Data Access logs

·        protoPayload.methodName

·        protoPayload.resourceName

·        principalEmail

Tuning Explanation

Detect:

·        burst secret retrieval

·        access to multiple secrets in short windows

·        first-seen secret access by a service account

·        cross-project secret access patterns

Detection Logic

·        protected service account accesses secrets

·        AND access volume or diversity exceeds normal behavior

Operational Context

High-value signal for post-execution credential access following workload compromise.

Logical Notes

Requires Data Access audit logging; without it, visibility is incomplete.

Rule Regret Check

Deployment caution

·        Requires service account scoping

·        Requires secret inventory or pattern classification

Confidence caution

·        Moderate during deployments or rotation events

Coverage value

·        Very High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected service accounts

·        define approved secret patterns

·        baseline access volume

System-Ready Code

resource.type="secret_manager_secret"
protoPayload.methodName="google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion"
protoPayload.authenticationInfo.principalEmail=("<SPRING_AI_SERVICE_ACCOUNTS>")
| stats
count(*) as access_count,
count_distinct(protoPayload.resourceName) as unique_secrets,
values(protoPayload.resourceName) as secret_names
by protoPayload.authenticationInfo.principalEmail, window(5m)
| filter access_count > 5 OR unique_secrets > 2

Rule Name

Service Account Abuse (First-Seen Service + Burst)

Purpose
Detect abnormal API usage by protected service accounts indicating identity misuse or workload pivoting.

ATT&CK Technique
T1078 – Valid Accounts

Coverage Classification
Baseline-dependent, standalone-capable

Telemetry Dependency

·        Cloud Audit Logs

·        principalEmail

·        serviceName

·        methodName

Tuning Explanation

Detect:

·        unusual API call volume

·        first-seen service usage

·        abnormal diversity of APIs in short intervals

Detection Logic

·        service account performs abnormal number or diversity of API calls

Operational Context

Primary identity misuse detection for compromised workloads.

Logical Notes

Must exclude shared automation accounts where applicable.

Rule Regret Check

Deployment caution

·        Requires service account scoping

Confidence caution

·        Moderate in dynamic microservice environments

Coverage value

·        High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected service accounts

·        baseline normal API behavior

System-Ready Code

protoPayload.authenticationInfo.principalEmail=("<SPRING_AI_SERVICE_ACCOUNTS>")
| stats
count(*) as api_calls,
count_distinct(protoPayload.serviceName) as services,
count_distinct(protoPayload.methodName) as methods
by protoPayload.authenticationInfo.principalEmail, resource.labels.project_id, window(5m)
| filter api_calls > 25 OR services > 3 OR methods > 5

Rule Name

IAM Privilege Escalation / Policy Change (Scoped + Burst)

Purpose
Detect unauthorized IAM policy modifications indicating privilege escalation.

ATT&CK Technique
T1098 – Account Manipulation

Coverage Classification
Standalone-capable

Telemetry Dependency

·        Cloud Audit Logs

·        SetIamPolicy events

·        project scoping

Tuning Explanation

Detect:

·        IAM policy changes

·        multiple resource modifications

·        repeated changes in short windows

Detection Logic

·        protected service account modifies IAM policy

·        AND change frequency or scope is abnormal

Operational Context

Critical escalation indicator following initial compromise.

Logical Notes

Exclude approved automation pipelines.

Rule Regret Check

Deployment caution

·        Requires project scoping

·        requires automation exclusion

Confidence caution

·        High

Coverage value

·        Very High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected projects

·        define approved IAM changes

System-Ready Code

protoPayload.methodName="SetIamPolicy"
resource.labels.project_id=("<SPRING_AI_PROJECTS>")
protoPayload.authenticationInfo.principalEmail=("<SPRING_AI_SERVICE_ACCOUNTS>")
| stats
    count(*) as changes,
    count_distinct(protoPayload.resourceName) as resources
    by protoPayload.authenticationInfo.principalEmail, window(5m)
| filter changes > 1 OR resources > 1

Rule Name

Cloud Storage Access Anomaly (Burst + Enumeration + New Bucket)

Purpose
Detect abnormal Cloud Storage access indicating data collection or staging.

ATT&CK Technique
T1537 – Transfer Data to Cloud Account

Coverage Classification
Baseline-dependent, standalone-capable

Telemetry Dependency

·        Cloud Storage Data Access logs

·        object access logs

Tuning Explanation

Detect:

·        object enumeration

·        burst reads

·        access to multiple buckets

·        new bucket access

Detection Logic

·        abnormal object access volume or diversity

Operational Context

Strong indicator of staging or collection activity.

Logical Notes

Requires Data Access logs enabled.

Rule Regret Check

Deployment caution

·        Requires bucket classification

Confidence caution

·        Moderate

Coverage value

·        High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected buckets

·        baseline access

System-Ready Code

resource.type="gcs_bucket"
protoPayload.authenticationInfo.principalEmail=("<SPRING_AI_SERVICE_ACCOUNTS>")
(protoPayload.methodName="storage.objects.get" OR protoPayload.methodName="storage.objects.list")
| stats
    count(*) as access_count,
    count_distinct(protoPayload.resourceName) as objects,
    count_distinct(resource.labels.bucket_name) as buckets
    by protoPayload.authenticationInfo.principalEmail, window(5m)
| filter access_count > 20 OR objects > 10 OR buckets > 1

Rule Name

Outbound Network Anomaly (Burst + Spread + Volume)

Purpose
Detect abnormal outbound communication patterns indicating potential command-and-control or data exfiltration.

ATT&CK Technique
T1071.001 – Web Protocols
T1041 – Exfiltration

Coverage Classification
Baseline-dependent, correlation-enhanced

Telemetry Dependency

·        VPC Flow Logs

·        subnet or workload mapping

Tuning Explanation

Detect:

·        connection bursts

·        large data transfers

·        unusual destination spread

Detection Logic

·        protected workload communicates with abnormal volume or diversity

Operational Context

Strong when correlated with identity or data-access anomalies.

Logical Notes

Requires NAT and subnet awareness.

Rule Regret Check

Deployment caution

·        requires subnet scoping

Confidence caution

·        moderate without destination baseline

Coverage value

·        Very High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected subnets

·        define approved destinations

System-Ready Code

resource.type="gce_subnetwork"
resource.labels.project_id=("<SPRING_AI_PROJECTS>")
jsonPayload.connection.src_ip=("<SPRING_AI_SUBNETS>")
| stats
count(*) as connections,
sum(jsonPayload.bytes_sent) as bytes,
count_distinct(jsonPayload.connection.dest_ip) as unique_dests
by jsonPayload.connection.src_ip, window(5m)
| filter connections > 50 OR bytes > 50000000 OR unique_dests > 10

Rule Name

Security Command Center High-Signal Finding (Tightened)

Purpose
Identify high-confidence SCC findings aligned to attacker behavior affecting protected workloads.

ATT&CK Technique
Multiple

Coverage Classification
Correlation-enhanced

Telemetry Dependency

·        SCC findings

·        project scoping

Tuning Explanation

Restrict to:

·        high or critical severity

·        attack-relevant categories

·        protected workloads

Detection Logic

·        SCC finding

·        AND high severity

·        AND relevant category

·        AND protected scope

Operational Context

Confirmation and prioritization layer.

Logical Notes

Not a primary detection rule.

Rule Regret Check

Deployment caution

·        requires SCC enabled

Confidence caution

·        dependent on SCC quality

Coverage value

·        Medium to High

Execution Validity Status
Deployment-ready with local adaptation required

Local Adaptation Required

·        define protected projects

·        tune categories

System-Ready Code

resource.type="security_center_finding"
resource.labels.project_id=("<SPRING_AI_PROJECTS>")
severity=("HIGH" OR "CRITICAL")
(
category:"Execution" OR
category:"PrivilegeEscalation" OR
category:"CredentialAccess" OR
category:"CommandAndControl" OR
category:"Exfiltration"
)
| fields
category,
severity,
finding_class,
resourceName,
sourceProperties,
eventTime

S26 Threat-to-Rule Traceability Matrix

Traceability Model

Each entry maps:

Threat Behavior → MITRE Technique → Detection Rules → Telemetry → Coverage Disposition

Coverage classifications:

·        Detected — Reliable detection when required telemetry is enabled and scoped

·        Partially Detected — Detection depends on baseline, correlation, or incomplete telemetry

·        Not Covered — No reliable detection via available telemetry

Detected Behaviors

Behavior: Prompt-Driven Initial Access and Execution

MITRE Techniques
T1190 – Exploit Public-Facing Application
T1059 – Command and Scripting Interpreter

Threat Behavior
Adversary injects crafted prompt or API input into Spring AI interfaces, resulting in model-mediated execution of backend functions or commands within the application context.

Detection Rules

·        SentinelOne — Spring AI Execution via Untrusted Parent Process

·        SentinelOne — Suspicious Child Process Spawn from Spring AI

·        Splunk — Suspicious Process Spawn from Spring AI JVM

·        Elastic — Suspicious Process Spawn from Spring AI Parent

Telemetry Dependency

·        Endpoint process telemetry (EDR)

·        Application process lineage visibility

Coverage Disposition
Detected

Behavior: Credential Access from Application Context

MITRE Technique
T1552 – Unsecured Credentials

Threat Behavior
Execution within application context exposes environment variables, secrets, API keys, or service tokens accessible to the compromised process.

Detection Rules

·        SentinelOne — Spring AI Service Credential Material Access

·        Splunk — Access to Credential Stores from Application Process

·        Elastic — Credential Access from Application Context

·        AWS — Secrets Manager Access Anomaly

·        Azure — Key Vault Access Anomaly

·        GCP — Secret Manager Access Anomaly

Telemetry Dependency

·        Endpoint process telemetry

·        Cloud data access logs (Secrets Manager, Key Vault, GCP Secret Manager)

Coverage Disposition
Detected (conditional on Data Access logging)

Behavior: Application-Initiated Command and Control Communication

MITRE Technique
T1071 – Application Layer Protocol

Threat Behavior
Compromised application initiates outbound HTTP or HTTPS communication under attacker influence.

Detection Rules

·        Suricata — Suspicious Outbound HTTP/HTTPS from Application

·        Splunk — Application Process Followed by External Network Activity

·        AWS — VPC Flow Logs Network Anomaly

·        Azure — Firewall/NSG Network Anomaly

·        GCP — VPC Flow Logs Network Anomaly

Telemetry Dependency

·        Network telemetry (Suricata, flow logs)

·        Endpoint-network correlation

Coverage Disposition
Partially Detected

Behavior: Data Exfiltration via Application Execution

MITRE Technique
T1041 – Exfiltration Over C2 Channel

Threat Behavior
Data accessed within application context is transmitted externally through application-driven communication.

Detection Rules

·        Splunk — Data Access Followed by Outbound Transfer

·        AWS — Network Anomaly

·        Azure — Network Anomaly

·        GCP — Network Anomaly

Telemetry Dependency

·        Network telemetry

·        Data access correlation

Coverage Disposition
Partially Detected

Behavior: Defense Evasion via Prompt-Based Obfuscation

MITRE Technique
T1027 – Obfuscated/Compressed Files and Information

Threat Behavior
Malicious instructions embedded within prompt content and model output blend with legitimate application behavior.

Detection Rules

·        Sigma — Suspicious Execution from AI Application Context

·        YARA — Spring AI Credential Harvest Script Patterns

Telemetry Dependency

·        Endpoint process telemetry

·        File and script inspection

Coverage Disposition
Partially Detected

Conditional Post-Exploitation Behaviors

Behavior: Persistence via Application or Service Modification

MITRE Technique
T1505 – Server Software Component

Coverage Disposition
Partially Detected

Validation Notes

Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment.

Behavior: Lateral Movement Across Services

MITRE Technique
T1021 – Remote Services

Coverage Disposition
Partially Detected

Validation Notes

Not observed in currently available reporting; may occur if compromised services enable lateral connectivity.

Behavior: System and Environment Discovery

MITRE Technique
T1082 – System Information Discovery

Coverage Disposition
Partially Detected

Validation Notes

Not observed in currently available reporting; may occur if execution enables access to system or environment data.

Behavior: Privilege Escalation Beyond Application Context

MITRE Technique
T1068 – Exploitation for Privilege Escalation

Coverage Disposition
Partially Detected

Validation Notes

Not observed in currently available reporting; may occur if execution context allows elevation beyond initial service privileges.

Not Covered Behaviors

Behavior: Prompt-Level Manipulation Visibility

Coverage Disposition
Not Covered

Validation Notes

·        Prompt content and model reasoning are not directly observable in standard telemetry

·        Requires application-layer instrumentation or AI-specific logging

Behavior: Direct Mapping of Prompt to Execution

Coverage Disposition
Not Covered

Validation Notes

·        No native telemetry linking user prompt input directly to backend execution decisions

·        Detection relies on indirect behavioral correlation

S27 Behavior and Log Artifacts

Behavioral Indicators

·        Iterative prompt manipulation patterns targeting AI-enabled endpoints

·        Deviations in Spring AI orchestration flow and model-driven execution behavior

·        Backend function invocation outside defined application logic

·        Process execution anomalies within JVM-based services

·        Outbound communication following AI-driven execution sequences

Log Artifacts

·        Application and API logs capturing anomalous prompt input and request structure

·        Spring AI orchestration logs showing workflow transitions and function invocation anomalies

·        Endpoint telemetry showing process execution and command activity within application services

·        Network telemetry capturing DNS queries, outbound connections, and data transfer anomalies

·        Correlated event chains linking input, model processing, execution, and communication

S28 Detection Strategy and SOC Implementation Guidance

SOC implementation must detect exploitation by correlating prompt input anomalies with downstream execution and communication behavior within Spring AI-enabled services. Detection workflows must explicitly link application-layer input events to model-driven function invocation and resulting process activity.

Operational deployment requires enrichment of application telemetry with execution context from JVM services and network telemetry capturing outbound communication. SOC correlation logic must identify sequences where anomalous prompt input is followed by unexpected function invocation and subsequent communication, rather than relying on isolated indicators.

SOC processes must include retrospective analysis of application, orchestration, and execution logs to identify prior exploitation attempts and refine behavioral baselines specific to Spring AI workflows.

S29 Detection Coverage Summary

Detected Behaviors

·        Structured or iterative prompt manipulation targeting AI-enabled endpoints

·        Deviations in Spring AI orchestration and model-driven execution behavior

·        Unauthorized backend execution within application services

·        Outbound communication anomalies following execution events

Conditional Post-Exploitation Behaviors
Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment

S30 Intelligence Maturity Assessment

Current Detection Maturity
Moderate in environments with application telemetry capturing prompt input, endpoint visibility into JVM-based execution, and network monitoring for outbound communication

Low in environments lacking visibility into Spring AI orchestration, execution-path selection, or correlation between input, inference, and execution

Maturity Gaps

·        Limited visibility into how model output drives backend function selection and execution

·        Lack of end-to-end correlation between prompt input, model inference, and execution behavior

·        Insufficient instrumentation of Spring AI orchestration layers and function invocation pathways

Improvement Priorities

·        Expand application telemetry to capture prompt input and Spring AI workflow activity

·        Increase endpoint visibility into execution behavior within JVM-based services

·        Integrate network telemetry to detect outbound communication initiated by application processes

Establish correlation pipelines linking prompt input, model output, execution, and communication stages

S31 Mitigation and Remediation

Mitigation must immediately interrupt the path between untrusted prompt input, Spring AI orchestration, and backend execution. Remediation actions should focus on stopping model-mediated action triggering, containing affected services, and restoring control over execution pathways.

Immediate actions

·        Identify all Spring AI-enabled applications that accept externally supplied prompt or API input

·        Disable, restrict, or temporarily remove model-accessible function invocation paths that can trigger backend actions

·        Insert explicit validation checks between Spring AI model output and backend function execution

·        Isolate affected application services from sensitive internal systems until execution-path integrity is confirmed

·        Review application, orchestration, and runtime execution logs for structured prompt manipulation, abnormal function invocation, and unexpected outbound communication

·        Revoke and rotate credentials, tokens, and secrets accessible to impacted application services where execution may have occurred

·        Validate application behavior before returning services to production, ensuring model output can no longer directly trigger sensitive backend actions without policy enforcement

These actions are required to terminate active exposure, restore execution control, and reduce the likelihood of immediate re-exploitation through the same application surfaces.

S32 Security Control Recommendations

Application and Orchestration Controls

·        Validate prompt input before it enters Spring AI workflows, including enforcement of expected structure, scope, and allowable request patterns

·        Require explicit policy validation before model output can invoke backend functions, tools, or service actions

·        Restrict model-accessible functions to a defined allowlist aligned to approved business workflows

·        Block model output from triggering backend actions outside approved request context

Execution Controls

·        Apply least-privilege controls to JVM-based application services so successful execution cannot access unnecessary systems, credentials, or data

·        Prevent application services from invoking high-risk commands, scripts, or administrative actions unless explicitly required and controlled

·        Separate AI-enabled services from sensitive downstream systems to reduce the impact of unauthorized backend action execution

Credential and Identity Controls

·        Remove unnecessary credentials and secrets from AI-enabled service contexts

·        Use short-lived, scoped credentials for backend service interaction

·        Restrict sensitive token and secret access to explicitly approved service operations only

Network Controls

·        Restrict outbound communication from Spring AI-enabled services to approved destinations

·        Enforce DNS and egress controls to prevent arbitrary external communication from compromised application contexts

·        Monitor for outbound communication inconsistent with approved service dependencies

S33 Strategic Defensive Improvements

·        Redesign Spring AI-enabled workflows so model inference cannot directly control privileged backend execution

·        Establish independent validation layers between model output and backend action selection

·        Govern model-accessible functions through formal approval, periodic review, and removal of unnecessary action pathways

·        Expand tracing across Spring AI orchestration layers so organizations can determine how prompt input influences model output and execution decisions

·        Integrate application, endpoint, and network observability into a unified operating model for prevention, detection, and containment of model-mediated abuse

·        Align AI-enabled service design to explicit execution-boundary controls rather than implicit trust in application-layer orchestration

S34 Defensive Architecture Overview

The defensive architecture must enforce control boundaries at four points: input handling, orchestration control, execution validation, and runtime communication. The objective is to prevent attacker-controlled prompt input from moving through Spring AI workflows and reaching backend execution without inspection, restriction, and visibility.

Input Control Layer

·        Validates and constrains prompt or API input before it enters Spring AI processing

Orchestration Control Layer

·        Captures model interaction and applies policy to how model output may influence application decision logic

Execution Validation Layer

·        Verifies whether model-influenced function selection is permitted before backend action occurs

Runtime and Communication Control Layer

·        Restricts execution scope within JVM-based services and limits outbound communication to approved destinations

This architecture prevents Spring AI orchestration from operating as an implicit trusted execution path and reduces the ability of attacker-controlled input to drive unintended backend behavior.

S35 Security Hardening Guidance

·        Harden Spring AI-enabled services by minimizing the number of backend actions that model output can influence. Where dynamic function invocation is required, constrain it to narrowly defined, auditable, business-necessary operations with explicit policy enforcement.

·        Harden application runtime environments by limiting command execution capability, removing unnecessary interpreters or high-risk utilities from service contexts where feasible, and reducing access to credentials, secrets, and internal systems from AI-enabled services.

·        Harden observability by preserving end-to-end linkage between prompt input, Spring AI model interaction, backend function invocation, and runtime execution. Logging and tracing should make it possible to reconstruct how an external request influenced downstream application behavior.

S36 Security Program Maturity Assessment

Current Maturity State

·        Low maturity environments allow Spring AI-enabled services to process untrusted input and influence backend execution without strong validation, orchestration visibility, or execution-boundary controls

·        Moderate maturity environments capture application and runtime telemetry but do not consistently enforce model-output validation or restrict backend action selection

·        High maturity environments validate model-influenced action selection, constrain execution paths, and correlate application, endpoint, and network telemetry to identify model-mediated abuse

Maturity Gaps

·        Limited visibility into how Spring AI model output influences backend function selection

·        Lack of end-to-end correlation between prompt input, orchestration behavior, execution, and communication

·        Insufficient control enforcement at the boundary between model decision-making and backend action execution

·        Maturity Improvement Priorities

·        Enforce validation boundaries between Spring AI model output and backend execution

·        Expand instrumentation of orchestration-layer decision points and function invocation paths

·        Reduce service privilege and credential exposure within AI-enabled application contexts

·        Build cross-telemetry correlation linking prompt input, orchestration behavior, execution, and communication

S37 Residual Risk and Forward Outlook

·        Residual risk remains where Spring AI-enabled services continue to permit model output to influence backend actions within trusted application contexts. Even after mitigation, dynamic application behavior, incomplete orchestration visibility, and imperfect behavioral baselines may allow sophisticated prompt manipulation to remain difficult to distinguish from legitimate use.

·        Forward risk will increase as organizations expose more model-accessible functions, integrate orchestration layers more deeply into business workflows, and expand AI-enabled application functionality. Attackers are likely to continue refining prompt manipulation and workflow abuse techniques because they provide a scalable means of converting legitimate application interaction into backend control.

·        Organizations must treat Spring AI orchestration as a persistent control boundary requiring continuous validation, architectural constraint, and telemetry-driven oversight. Without those controls, AI-enabled application logic will remain a durable avenue for externally influenced execution and downstream compromise.

S38 Intelligence Confidence Assessment

Overall Confidence Level
Moderate (vulnerability confirmation) / High (exploitation model)

Source Reliability
Moderate

Confidence in the existence of a confirmed, publicly documented vulnerability (CVE-2026-22738) remains moderate due to the absence of a verified vendor advisory or authoritative vulnerability record in currently available sources. However, confidence in the exploitation model and risk posture is high based on the architectural analysis of Spring AI orchestration and its ability to translate externally supplied input into backend execution.

Analytical Confidence Drivers

·        Strong architectural alignment between prompt input, Spring AI orchestration, and backend execution pathways

·        Consistent modeling of model-mediated decision logic influencing application behavior

·        Coherent linkage between attacker-controlled input, function invocation, and execution risk within JVM-based services

·        High internal consistency across attack chain, detection strategy, and defensive architecture

Confidence Limitations

·        No confirmed vendor advisory, CVE record, or authoritative disclosure identified for CVE-2026-22738 at the time of this analysis

·        Variability in how Spring AI is implemented across environments may affect exploitability

·        Lack of confirmed real-world exploitation telemetry specific to this scenario

Intelligence Gaps

·        Whether exploitation requires specific Spring AI configurations, function-calling features, or orchestration patterns

·        The extent to which production deployments expose externally reachable prompt pathways tied to backend execution

·        The exact observable artifacts across different implementations and logging configurations

S39 Analytical Notes and Limitations

This analysis evaluates a modeled exploitation pathway in which untrusted prompt or API input influences Spring AI model output, resulting in backend execution within trusted application services. The assessment focuses on architectural exposure, control failure, and realistic abuse scenarios derived from AI orchestration behavior.

This report does not assume that all Spring AI deployments are vulnerable. Exposure depends on implementation decisions, including whether model output can trigger backend actions, whether validation exists between inference and execution, and whether execution environments are constrained.

Because no authoritative public disclosure was identified for the specific CVE-2026-22738 scenario, this report should be interpreted as an architectural risk and exploitation feasibility assessment, not confirmation of a publicly disclosed vulnerability or active exploitation campaign.

Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment, including persistence, lateral movement, or downstream service abuse following application-layer execution.

S40 References

Vendor Advisory

·        Spring Security Advisory — SpEL Injection via Unescaped Filter Key in SimpleVectorStore Leads to Remote Code Execution (CVE-2026-22738)

·        hxxps://spring[.]io/security/cve-2026-22738

Vulnerability Records

·        National Vulnerability Database (NVD) — CVE-2026-22738 vulnerability record

·        hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-22738

·        Tenable CVE Coverage — Detection and plugin intelligence for CVE-2026-22738

·        hxxps://www[.]tenable[.]com/cve/CVE-2026-22738/plugins

Known Exploited Vulnerabilities (KEV)

·        CISA Known Exploited Vulnerabilities Catalog

·        hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

Security Vendor Analysis

·        Not applicable — no independent third-party original research identified beyond vendor advisory and vulnerability records

Analytical Framework

·        MITRE ATT&CK Framework

·        hxxps://attack[.]mitre[.]org

·        CyberDax Threat Intelligence Data Model