Change Management

A subject operates within an environment where artificial intelligence (AI) platforms or agents are integrated across multiple enterprise systems, providing centralized access to data, services, or functionality within the organization.

These platforms are typically deployed to support productivity, knowledge retrieval, automation, or decision-making. As part of their implementation, they may be connected to internal repositories, collaboration tools, identity systems, ticketing platforms, or other business-critical services. Integration is often achieved through APIs, service accounts, or enterprise-wide indexing capabilities.

As a result, the AI platform may provide:

• Access to data across multiple repositories through a unified interface.
• The ability to query, summarize, or retrieve information spanning different business functions.
• Integration with systems that enable interaction with internal services or workflows.
• Persistent access to organizational data or systems through configured permissions.

This form of integration creates a consolidated access layer within the environment that differs from standard user interaction patterns. Rather than accessing systems individually, the subject may interact with multiple data sources or services through the AI platform.

In some cases, the scope of access available through the platform may not align precisely with role-based access expectations, particularly where data is aggregated, summarized, or retrieved across systems. The platform may also operate with service account permissions or API-level access that are not directly accessible to the subject through traditional interfaces or individual user access controls, creating a divergence between user-level access and effective access via the platform.

This Section captures the availability of AI platforms that are integrated into the enterprise environment with broad access to data or systems. While deployed for legitimate operational purposes, such platforms may provide expanded capability that can be leveraged by a subject in the course of insider activity.

The subject modifies a system, application, or operating environment to preserve unauthorized access, execution, or control beyond the initial activity. The persistence mechanism is intended to remain available following events that would ordinarily interrupt the subject’s access, including system restart, user logoff, application termination, credential changes, or the subject’s departure from the organization.

System persistence may be established through the creation or modification of scheduled tasks, cron jobs, system services, startup items, Registry autorun locations, login scripts, systemd units, Windows Management Instrumentation event subscriptions, SSH authorized keys, web shells, application extensions, or other automatically executed components. The subject may create a new persistence mechanism or alter an existing legitimate component so that unauthorized code, commands, or remote-access functionality is invoked without requiring repeated manual action.

This behavior is preparatory where the subject establishes the mechanism before an intended infringement, allowing access or execution to continue at a later time or under conditions in which the subject’s normal account is unavailable. Persistence may support subsequent unauthorized access, data collection, sabotage, surveillance, or execution by another party.

A subject bypasses logical or physical network segmentation controls (such as VLANs, ACLs, security groups, or subnets) in order to obtain unauthorized access to systems, services, or data across trust boundaries. This preparation technique commonly manifests through deliberate configuration changes (e.g., modifying ACLs or VLAN assignments), covert tunneling (e.g., SSH, HTTPS reverse tunnels), rogue device introduction (e.g., unmanaged switches or dual-homed devices), or misuse of trusted services (e.g., remote access platforms or admin automation tools that bridge zones).

Such actions are often observable via first-time or anomalous cross-segment flows, management plane configuration logs, 802.1X/NAC anomalies, or long-lived encrypted outbound sessions. These techniques typically exploit privileged access, weak change control, or poor posture enforcement.

This behaviour may be motivated by a subject’s attempt to escalate access, stage data for exfiltration, evade oversight, or maintain persistence across environments. It is especially critical in environments with sensitive zoning, such as production-to-dev separations, cloud VPC peerings, or physically segmented OT/ICS networks.

Investigators should prioritize telemetry correlation across NetFlow/IP Flow Information Export (IPFIX), EDR, DHCP, and identity systems to attribute cross-zone traffic to known assets and subjects. Preserve infrastructure configuration snapshots and identify whether segmentation was circumvented by direct administrative action, covert bridging, or software-level tunnelling.

The subject deliberately interferes with operational systems in ways that degrade, interrupt, or misroute services relied upon by customers, without relying on file deletion or malware. This includes misconfigurations, service disabling, authentication interference, or intentional introduction of latency, instability, or incorrect outputs. The result is operational degradation that directly or indirectly affects service delivery, availability, or trust.

Unlike File or Data Deletion, this infringement does not depend on erasing data, and unlike Destructive Malware Deployment, it does not rely on malicious payloads or automated damage. The disruption instead stems from direct manipulation of infrastructure, configurations, service states, or user access.

Examples include:

• Intentionally disabling authentication or API endpoints
• Modifying DNS, firewall, or routing rules to block legitimate traffic
• Tampering with load balancers or HA/failover logic
• Altering service configurations to break dependency chains (e.g. pointing production systems to empty dev databases)
• Injecting false flags into monitoring or orchestration tools to trigger auto-scaling failures or mis-alerts
• Enabling excessive logging or computation to induce service latency or memory exhaustion
• Locking critical service accounts, API keys, or secrets in vault systems

These actions may be motivated by retaliation, concealment, sabotage, or insider coercion, and often occur in environments where the subject has legitimate system access but uses it to destabilize service delivery covertly.

The subject intentionally weakens or bypasses network security controls for a third party, such as providing credentials or disabling security controls.

A subject provisions cloud-based resources without prior authorization or a documented business justification. This unauthorized activity may circumvent established governance, security, or cost-management controls, potentially exposing the organization to operational, financial, or regulatory risk.

A subject deliberately or negligently deletes cloud-based resources, leading to the disruption, degradation, or complete interruption of organizational operations. Deletion of critical resources may result in the permanent loss of data, service outages, impaired system performance, or the failure of customer-facing applications. Such actions often violate organizational policies governing change management, data retention, disaster recovery, and access control, and may expose the firm to significant operational, financial, legal, and reputational risks.

• 
  Characteristics:
  May involve deletion of compute instances, storage buckets, databases, networking components, IAM configurations, or application services.
  Can be motivated by malice (e.g., retaliation, sabotage) or negligence (e.g., misunderstanding scope of permissions, error during unsanctioned activities).
  Deletions may occur directly via administrative consoles, APIs, or CLI tools, often outside of approved change management processes.
  Recovery may be delayed or impossible if backup, replication, or retention mechanisms are improperly configured or bypassed.
  Associated activity often correlates with other early indicators, such as privilege escalation, unauthorized access attempts, or policy circumvention behaviors.

Example Scenario:
A subject with elevated cloud access privileges, dissatisfied with an impending termination, manually deletes production virtual machines and storage buckets without authorization. This leads to an extended outage of the organization’s primary customer platform, resulting in contractual penalties, regulatory reporting obligations, and long-term reputational damage. Post-incident investigation reveals inadequate enforcement of least privilege policies and incomplete backup coverage for critical resources.

The subject deletes IT resources resulting in harm to the organization. Examples include virtual machines, virtual disk images, user accounts, and DNS records.

The subject makes unauthorized changes to access controls resulting in harm. Examples include resetting/changing passwords, locking accounts, deleting accounts, or modifying file permissions.

The subject creates, deletes, or edits DNS records resulting in harm. Examples include altering MX records to affect the availability of email communication, removing A records to affect the availability of web resources, or altering A records to redirect traffic to an unintended location.

A subject makes an unauthorized change to the rule table of a network-based firewall, resulting in impaired security, impacted availability or to bypass network segmentation.

A subject has access to an artificial intelligence (AI) platform that aggregates data from multiple internal systems and presents it through a unified interface, where access controls are insufficiently enforced or misaligned with underlying role-based access restrictions.

These platforms are typically configured to index, query, or retrieve information from enterprise repositories such as file storage systems, collaboration platforms, knowledge bases, and internal documentation systems. Data from these sources may be combined, summarized, or surfaced in response to a single query.

In some implementations, the platform aggregates data across repositories without consistently applying the access controls of the underlying systems. As a result, information may be surfaced through the AI interface that the subject would not ordinarily access through direct interaction with those systems.

The AI platform may provide:

• Cross-repository search and retrieval spanning multiple data sources.
• Summarized or consolidated outputs derived from restricted or segmented repositories.
• Correlation of information across business functions or sensitivity domains.
• Visibility into data that is not directly accessible through standard user interfaces.

This access model creates a divergence between the subject’s direct access permissions and the information available to them through the AI platform. Data that is distributed, restricted, or contextually separated within underlying systems may be surfaced together through aggregated queries.

The presence of aggregated data access with insufficiently constrained access controls provides the subject with a means to obtain information beyond their intended role-based scope, particularly where enterprise-wide indexing or broad query capabilities are implemented.

A subject has access to an artificial intelligence (AI) platform that is integrated with internal systems and capable of interacting with those systems through APIs, service accounts, automation frameworks, or agent interaction protocols (e.g., Model Context Protocol (MCP)), where the platform operates with permissions or capabilities that exceed typical user-level access controls.

These platforms are connected to enterprise systems such as identity services, ticketing platforms, communication tools, file storage systems, and other operational applications. Integration enables the platform to execute actions, retrieve data, or interact with system functionality on behalf of the user.

In some implementations, the platform is granted broad or persistent permissions to support automation and cross-system functionality. These permissions may not align precisely with the subject’s role-based access and may allow the platform to perform actions or retrieve data beyond what the subject could achieve through direct interaction with the underlying systems.

The AI platform may:

• Execute actions against internal systems through API integrations.
• Operate using service accounts with elevated or persistent privileges.
• Trigger workflows or automation processes across multiple systems.
• Interact with system functionality outside standard user interfaces.
• Perform actions or retrieve data using permissions not directly available to the subject.

This interaction model creates a divergence between the subject’s direct capabilities and the effective capabilities available through the AI platform. Actions that would normally require elevated access, multi-system coordination, or additional authorization may be performed through the platform’s integrated functionality.

The presence of AI platforms with system interaction capability and insufficiently constrained permissions provides the subject with a means to interact with internal systems and services beyond their intended role-based authority.

The subject creates or modifies a scheduled task, cron job, system timer, or equivalent mechanism to execute unauthorized commands or code automatically at a future time or recurring interval.

The subject creates or modifies a system service, daemon, launch agent, or equivalent background component to execute unauthorized functionality automatically or continuously.

The subject modifies startup folders, Registry autorun locations, XDG autostart entries, login items, shortcuts, or equivalent configurations so that unauthorized code executes during system startup or account logon.

The subject creates or modifies an event subscription, event handler, system hook, or equivalent trigger that executes unauthorized commands or code when specified conditions are met.

The subject adds, replaces, or modifies a Secure Shell (SSH) authorized key or related trust configuration to preserve unauthorized remote access to a system, virtual machine, hypervisor, or network device.

The subject places or modifies a server-side script, application file, or web component that permits unauthorized remote command execution through a web server or hosted application.

The subject installs, sideloads, replaces, or modifies a software extension so that unauthorized functionality executes through a browser, integrated development environment, or other supported host application.

The subject installs or modifies an extensible server component, stored procedure, transport agent, server module, service library, or virtualization package to preserve unauthorized execution or access.

This Sub-section excludes web shells, which are represented separately under PR046.006 – Web Shell Deployment.

The subject modifies a bootloader, boot image, boot partition, firmware component, Unified Extensible Firmware Interface configuration, or network-device boot mechanism to preserve unauthorized execution or control.

The subject uses a cloud control plane, software deployment system, endpoint-management platform, configuration-management service, or orchestration tool to access, manage, or execute actions on additional organizational systems outside an approved operational requirement.

The subject bypasses, manipulates, or abuses a technical control intended to regulate elevated execution or access to protected capabilities. This may include abuse of set-user-ID or set-group-ID permissions, bypass of Windows User Account Control, manipulation of sudoers or cached sudo authorization, or alteration of platform consent and privacy controls.

This Sub-section concerns defeating or misusing the elevation control itself.

The subject creates or modifies an identity, directory, group, role, token, or authorization attribute so that an account or process receives permissions beyond its normal access context. This may include introducing privileged Security Identifier History values, modifying group or role assignments, or altering identity attributes that are evaluated during authorization.

The change may be made through an approved administrative interface or through unauthorized technical manipulation.

The subject exploits a vulnerability in an operating system, application, kernel component, service, driver, hypervisor, container runtime, or other privileged software to obtain permissions beyond their existing execution context.

This Sub-section applies as Preparation where exploitation increases the subject’s capability before a later infringement. Where the exploitation itself causes the principal harm, unauthorized modification, or operational disruption, investigators should also apply the relevant Infringement.