T1505.001: SQL Stored Procedures

SQL stored procedures matter because they turn a database feature into a potential persistence point. If an attacker can create or modify database-side code, that code may survive restarts and be invoked later through normal database activity or events. For leaders, the risk is not just database compromise; it is durable access inside systems that often support critical applications and business processes.

Executive priority

Prioritize this where SQL database servers support high-value applications, regulated data, or operational technology dependencies. The key business question is whether database administrative privileges, stored procedure changes, CLR integration, and operating-system command execution features are governed, logged, and reviewable. This technique is also relevant to audit readiness because privileged database changes and server-side code execution should have accountable approval and monitoring evidence.

Technical view

This is a persistence sub-technique under Server Software Component for Windows and Linux environments. SOC, detection engineering, and IR teams should validate visibility into creation, modification, and execution of stored procedures, especially procedures configured to run on database startup or tied to defined events. For Microsoft SQL Server environments, validate monitoring around enabling or use of features referenced by ATT&CK such as xp_cmdshell and CLR integration, and review CLR assemblies linked to stored procedures. Because MITRE does not provide official detection text for this object, detection content should be validated against local database audit configuration and the related DET0181 detection strategy where available.

Likely telemetry

Database audit logs for stored procedure creation, alteration, deletion, and execution
Database server configuration changes, including enablement of command-execution or runtime integration features such as xp_cmdshell or CLR integration where applicable
Privileged database account activity and role membership changes
Startup or event-driven database procedure execution records
Operating system process creation events from database server processes where collected

Detection direction

Baseline legitimate stored procedures and alert on unexpected creation or modification, especially by privileged or rarely used accounts.
Correlate database-side procedure activity with operating system process execution from database service contexts when that telemetry is available.
Tune for administrative false positives from deployments, maintenance jobs, and application releases by integrating change windows and approved database code repositories.
Review database startup procedures or event-triggered execution paths because persistence may not look like interactive attacker activity.
Validate whether logging captures both successful and failed attempts to enable risky database functionality; absence of audit data is a major blind spot.

Mitigation priorities

Apply privileged account management: restrict who can create, alter, or execute high-risk stored procedures and enforce least privilege for database administrators and service accounts.
Require accountable change control and auditing for stored procedure and database extension changes, especially on production servers.
Where code signing is applicable to database extensions or assemblies, use it to help ensure only trusted code is allowed.
Review and limit optional database functionality that permits operating-system command execution or external runtime integration unless there is a justified business need.
Regularly audit stored procedures, CLR assemblies, startup procedures, and privileged database roles for unauthorized or unexplained changes.

Analyst notes and limits

The supplied ATT&CK relationships connect this behavior to persistence, the parent technique Server Software Component, mitigations for Privileged Account Management, Code Signing, and Audit, and references to Stuxnet and the 2016 Ukraine Electric Power Attack. Those relationships make the technique relevant to cyber-physical and critical infrastructure risk discussions, but local exposure depends on whether affected database platforms and features exist in the environment.

MITRE provides no official detection text for this object in the supplied fields. The description includes Microsoft SQL Server-specific examples such as xp_cmdshell and CLR integration, but the listed platforms are Windows and Linux; defenders should map guidance to their actual database products and audit capabilities. No claim is made here about active exploitation, customer exposure, or guaranteed detection coverage.

Official MITRE ATT&CK definition

SQL Stored Procedures

Adversaries may abuse SQL stored procedures to establish persistent access to systems. SQL Stored Procedures are code that can be saved and reused so that database users do not waste time rewriting frequently used SQL queries. Stored procedures can be invoked via SQL statements to the database using the procedure name or via defined events (e.g. when a SQL server application is started/restarted).

Adversaries may craft malicious stored procedures that can provide a persistence mechanism in SQL database servers.[1][2] To execute operating system commands through SQL syntax the adversary may have to enable additional functionality, such as xp_cmdshell for MSSQL Server.[1][2][3]

Microsoft SQL Server can enable common language runtime (CLR) integration. With CLR integration enabled, application developers can write stored procedures using any .NET framework language (e.g. VB .NET, C#, etc.).[4] Adversaries may craft or modify CLR assemblies that are linked to stored procedures since these CLR assemblies can be made to execute arbitrary commands.[5]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques 1 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1505	Server Software Component	This object subtechnique of Server Software Component.

Associated objects

Groups, software, and campaigns

S0603: Stuxnet

Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]

Windows

C0025: 2016 Ukraine Electric Power Attack

2016 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used Industroyer malware to target and disrupt distribution substations within the Ukrainian power grid. This campaign was the second major public attack conducted against Ukraine by Sandworm Team.[1][2]

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1047: Audit Enterprise uses · Campaign C0025: 2016 Ukraine Electric Power Attack Enterprise mitigates · Mitigation M1045: Code Signing Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise subtechnique of · Technique T1505: Server Software Component Enterprise detects · Detection Strategy DET0181: Detection Strategy for SQL Stored Procedures Abuse via T1505.001 Enterprise uses · Malware S0603: Stuxnet Enterprise

Mitigations

Mitigation direction

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

M1045: Code Signing

Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks. This mitigation can be implemented through the following measures:

Enforce Signed Code Execution:

- Implementation: Configure operating systems (e.g., Windows with AppLocker or Linux with Secure Boot) to allow only signed code to execute. - Use Case: Prevent the execution of malicious PowerShell scripts by requiring all scripts to be signed with a trusted certificate.

Vendor-Signed Driver Enforcement:

- Implementation: Enable kernel-mode code signing to ensure that only drivers signed by trusted vendors can be loaded. - Use Case: A malicious driver attempting to modify system memory fails to load because it lacks a valid signature.

Certificate Revocation Management:

- Implementation: Use Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to block certificates associated with compromised or deprecated code. - Use Case: A compromised certificate used to sign a malicious update is revoked, preventing further execution of the software.

Third-Party Software Verification:

- Implementation: Require software from external vendors to be signed with valid certificates before deployment. - Use Case: An organization only deploys signed and verified third-party software to prevent supply chain attacks.

Script Integrity in CI/CD Pipelines:

- Implementation: Integrate code signing into CI/CD pipelines to sign and verify code artifacts before production release. - Use Case: A software company ensures that all production builds are signed, preventing tampered builds from reaching customers.

**Key Components of Code Signing**

- Digital Signature Verification: Verifies the authenticity of code by ensuring it was signed by a trusted entity. - Certificate Management: Uses Public Key Infrastructure (PKI) to manage signing certificates and revocation lists. - Enforced Policy for Unsigned Code: Prevents the execution of unsigned or untrusted binaries and scripts. - Hash Integrity Check: Confirms that code has not been altered since signing by comparing cryptographic hashes.

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release: 19.1
Object version: 1.1
Created: Dec 12, 2019, 14:59 UTC (UTC+00:00)
Modified: Oct 24, 2025, 17:49 UTC (UTC+00:00)
Raw hash: 1ffea9e2194d959f...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.1	Oct 24, 2025, 17:49 UTC (UTC+00:00)	Current bundle	`1ffea9e2194d…`

Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
NetSPI Startup Stored Procedures

Sutherland, S. (2016, March 7). Maintaining Persistence via SQL Server – Part 1: Startup Stored Procedures. Retrieved September 12, 2024.
Open source URL
[2]
Kaspersky MSSQL Aug 2019

Plakhov, A., Sitchikhin, D. (2019, August 22). Agent 1433: remote attack on Microsoft SQL Server. Retrieved September 4, 2019.
Open source URL
[3]
Microsoft xp_cmdshell 2017

Microsoft. (2017, March 15). xp_cmdshell (Transact-SQL). Retrieved September 9, 2019.
Open source URL
[4]
Microsoft CLR Integration 2017

Microsoft. (2017, June 19). Common Language Runtime Integration. Retrieved July 8, 2019.
Open source URL
[5]
NetSPI SQL Server CLR

Sutherland, S. (2017, July 13). Attacking SQL Server CLR Assemblies. Retrieved September 12, 2024.
Open source URL
[6]
mitre-attack T1505.001
Open source URL

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use

Analyst context for executives and security teams