What’s the issue?
SQL Server allows stored procedures in the master database to be marked to run automatically every time the SQL Server service starts. This is configured by setting the startup option on a procedure using sp_procoption, and the procedures execute under the sa security context as part of the service startup sequence.This finding identifies instances where one or more stored procedures are configured to run at startup. The feature has legitimate uses for instance level initialization tasks, but it is also a known persistence and privilege escalation mechanism that warrants review whenever startup procedures exist.
Common legitimate uses include performing routine warmup activity or initializing application specific state. Less legitimate uses include attacker installed code that ensures malicious activity resumes after every restart.
Why is this a problem?
Startup procedures execute with full sysadmin privileges as sa, regardless of who created them or what permissions the original creator had. Any code in a startup procedure can read, modify, or drop any object on the instance, change configuration, create logins, and execute operating system commands through features such as xp_cmdshell if enabled.Because startup procedures run automatically and under elevated privilege, they are an attractive persistence mechanism for attackers who have gained sysadmin access at any point in the past. A malicious startup procedure can reestablish backdoor accounts, disable audit configuration, or fetch and execute additional code on every service restart, even if the original compromise has otherwise been remediated.
The feature is also easy to overlook during security reviews. Startup procedures are not visible in the normal job and schedule views that administrators check regularly, and they require a specific query against sys.procedures and OBJECTPROPERTY to enumerate. An attacker who knows about the feature can rely on it remaining undetected longer than other persistence mechanisms.
Even when startup procedures are legitimate, they introduce a startup dependency that can affect service availability. A procedure that errors, blocks, or hangs at startup can delay or prevent SQL Server from coming online, turning what should be a routine restart into an extended outage that requires manual intervention to resolve.
What should you do about this?
Identify configured startup procedures by querying the master database with SELECT name FROM sys.procedures WHERE OBJECTPROPERTY(object_id, ‘ExecIsStartup’) = 1;. Capture the full definition of each procedure using OBJECT_DEFINITION and review the code carefully for what it actually does.Confirm with the team that each procedure was created intentionally and is still required. Treat any procedure that cannot be explained or attributed to a known process as suspicious until proven otherwise, since startup procedures are a documented persistence mechanism for SQL Server compromise.
Remove unneeded or unrecognized procedures by first disabling the startup option with EXEC sp_procoption N’ProcedureName’, ‘startup’, ‘off’;, then dropping the procedure if it is no longer needed. Engage incident response if any procedure appears to be malicious, since the existence of attacker installed startup code suggests a broader compromise that warrants investigation.