The SQL Server attack pattern is consistent: attackers do not always need a spectacular vulnerability. They often succeed by chaining normal features that were granted too broadly, trusted too much, or monitored too narrowly.
In this article, I’ll focus on operational blind spots in SQL Server. These are the features DBAs use every day to keep SQL Server healthy: linked servers, traces, Dynamic Management Views, Extended Events, and session-management commands such as KILL.
These tools, while necessary, also create visibility, automation, and trust paths that attackers can abuse after compromising a low-privileged application account or a local database owner.
Because of this, a SQL Server DBA should know the answer to the following questions at all times: where am I exposed, what should I monitor, and what should I change first? In this article, you’ll learn the answers to all three.
This article is part of Fabiano Amorim’s complete guide to SQL Server security on Simple Talk.
Why it’s so important to cover any operational blind spots in SQL Server
Operational features are attractive targets because they already run inside the trusted perimeter. It could be a nightly index rebuild, a replication cleanup process, or a cross-server reporting query, for example. It could even be a monitoring job running with far more privilege than the user database being touched.
Put simply: if a lower-privileged SQL Server user can influence the object, data, or metadata that a privileged process later consumes, the attacker does not need to directly hold the privileged credential. They just need to leave a trap for the trusted process.
This is why DBA monitoring must always stretch beyond simple perimeter controls and patch status. It should also include who can create or touch user-controlled objects, how linked servers authenticate remote queries, who can see query text and diagnostic metadata, and who can terminate sessions.
Linked servers and cross-instance trust in SQL Server
Linked servers are often introduced for legitimate reasons such as reporting, migrations, data warehouse loads, vendor integrations, or legacy applications. From a security perspective, a linked server expands the security boundary of the local SQL Server instance to include the remote data source and the credential mapping used to reach it.
The most common linked server exposure is a permissive login mapping. If all local logins are mapped to a single remote credential, a low-privileged local account may inherit far more privilege on the remote server than it has locally. If RPC OUT is enabled, the exposure can move from data access to remote procedure execution.
A practical example of this
A front-end application database has a linked server to a reporting or finance instance. To simplify deployment, the linked server is configured so any local login not explicitly mapped connects to the remote server using one shared remote account.
A compromised application login can now query the linked server and operate on the remote system using that shared credential. The attacker did not compromise the remote login directly; the linked server handed it to them through a trust mapping.
What are the signs a DBA should look for?
- Linked servers with a fallback mapping that uses a shared remote account for all undefined local logins.
- Remote login mappings that use highly privileged accounts such as
sysadmin,db_owner, deployment accounts, or vendor admin accounts.
RPC OUTis enabled when the business requirement is read-only reporting or simple distributedSELECTqueries.
- Loopback linked servers (especially when they are used to bypass context, transaction, or permission assumptions.)
- Linked servers with no known owner, no documented business purpose, or no recent telemetry showing authorized use.
- Linked servers reachable from databases exposed to web applications, ETL (extract-transform-load) users, report users, or broad support groups.
What to monitor – and how
Review all linked servers, options, and security mappings regularly. The following queries highlight the most important properties for a DBA to review:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
/* Linked server options */ SELECT name AS LinkedServerName, product, provider, data_source, is_linked, is_data_access_enabled, is_rpc_out_enabled, is_remote_login_enabled, is_remote_proc_transaction_promotion_enabled FROM sys.servers WHERE is_linked = 1 ORDER BY name; /* Linked server login mappings */ SELECT s.name AS LinkedServerName, COALESCE(sp.name, '<all local logins / fallback>') AS LocalPrincipal, ll.uses_self_credential, ll.remote_name FROM sys.linked_logins AS ll JOIN sys.servers AS s ON ll.server_id = s.server_id LEFT JOIN sys.server_principals AS sp ON ll.local_principal_id = sp.principal_id WHERE s.is_linked = 1 ORDER BY s.name, LocalPrincipal; |
Look for local principals that can alter linked servers or server objects. These permissions should be limited to DBAs or controlled deployment automation.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
SELECT pr.name AS PrincipalName, pr.type_desc AS PrincipalType, pe.state_desc, pe.permission_name, pe.class_desc FROM sys.server_permissions AS pe JOIN sys.server_principals AS pr ON pe.grantee_principal_id = pr.principal_id WHERE pe.permission_name IN ('ALTER ANY LINKED SERVER', 'ALTER ANY LOGIN', 'ALTER ANY CREDENTIAL', 'ALTER SETTINGS', 'CONTROL SERVER') ORDER BY pr.name, pe.permission_name; |
Audit linked server configuration changes using server-level audit groups. Also monitor for distributed-query usage from unexpected logins or applications.
|
1 2 3 4 5 6 7 8 |
/* Example audit specification for server object and permission changes */ CREATE SERVER AUDIT SPECIFICATION [Audit_LinkedServer_Config] FOR SERVER AUDIT [Your_Server_Audit] ADD (SERVER_OBJECT_CHANGE_GROUP), ADD (SERVER_PERMISSION_CHANGE_GROUP), ADD (SERVER_PRINCIPAL_CHANGE_GROUP) WITH (STATE = ON); GO |
For runtime monitoring, use Extended Events or your existing monitoring platform to watch for distributed query patterns. Keep filters tight; capturing every statement on a busy system can be expensive.
|
1 2 3 4 5 6 7 8 9 10 11 |
CREATE EVENT SESSION [Monitor_LinkedServer_Usage] ON SERVER ADD EVENT sqlserver.sql_statement_completed( ACTION(sqlserver.client_app_name, sqlserver.database_name, sqlserver.server_principal_name, sqlserver.sql_text) WHERE (sqlserver.like_i_sql_unicode_string(sqlserver.sql_text, N'%OPENQUERY%') OR sqlserver.like_i_sql_unicode_string(sqlserver.sql_text, N'%OPENROWSET%') OR sqlserver.like_i_sql_unicode_string(sqlserver.sql_text, N'%EXEC% AT %'))) ADD TARGET package0.event_file (SET filename = N'D:\XEvents\Monitor_LinkedServer_Usage.xel', max_file_size = 50, max_rollover_files = 5) WITH (STARTUP_STATE = OFF); GO |
Recommended fixes and mitigations
- Avoid fallback mappings that allow all local logins to connect using one shared remote credential. Configure the fallback behavior so connections are not made unless explicitly mapped.
- Use explicit local-to-remote mappings with least privilege. For reporting, the remote login should usually be read-only and restricted to the required database, schema, or views.
- Disable
RPC OUTunless there’s a documented requirement to execute remote stored procedures. If only distributedSELECTis required,RPC OUTshould be off.
- Remove unused linked servers. Legacy links are high-risk because they often retain old credentials, broad mappings, and don’t have an active owner.
- Separate application-facing instances from administrative linked-server paths. A compromised web or report login should never have a bridge into finance, payroll, or operational administration servers.
- Review delegation and Kerberos double-hop settings carefully. Delegation problems often lead teams to hardcode shared credentials, which increases risk.
- Test linked server access with low-privileged accounts. Do not validate only with
sysadminsessions.
Future-proof database monitoring with Redgate Monitor
SQL Server Traces, DMVs, Extended Events, and the KILL command
Observability is essential for SQL Server performance tuning, troubleshooting, auditing, and incident response. It’s also a reconnaissance surface.
Traces, Extended Events, DMVs, query text, execution plans, error messages, session metadata, file paths, and Agent activity can reveal how the environment is built, and how security controls are implemented.
Operational metadata can be very useful for an attacker. For example, query text from monitoring jobs may reveal which accounts are whitelisted, which procedures perform administrative work, which jobs run with elevated context, which linked servers exist, and which object names matter.
A user who can see too much may not yet be privileged – but they may already have enough information to plan a targeted privilege escalation.
A practical example of this
A monitoring job checks for unexpected sysadmin members by comparing current role membership against an approved list. If a low-privileged user can see the running query text through DMVs, traces, or Extended Events output, that user learns exactly which privileged names the monitoring process treats as normal.
That information is dangerous – it can help them choose a stealthier target, abuse an existing trusted account, or understand where detection rules are weak.
Similarly, broad permission to terminate sessions is often underestimated. In SQL Server, KILL requires ALTER ANY CONNECTION, which is included in powerful roles such as sysadmin and processadmin. Granting this ability to general support or application accounts can create denial-of-service (DoS) and incident-response interference risks.
What are the signs a DBA should look for?
- Non-administrative logins with
VIEW SERVER STATE,VIEW SERVER PERFORMANCE STATE,VIEW SERVER SECURITY STATE,VIEW ANY DEFINITION,ALTER ANY EVENT SESSION,ALTER TRACE, orALTER ANY CONNECTION.
- Application accounts, vendor accounts, or reporting users that query
sys.dm_exec_requests,sys.dm_exec_sessions,sys.dm_exec_sql_text,sys.dm_exec_query_stats,sys.traces, orfn_trace_gettable.
- Users who can read trace or Extended Events files from the file system or from a shared monitoring repository.
- Monitoring jobs whose SQL text exposes detection allow-lists, privileged account names, internal procedure names, secrets, file paths, or operational assumptions.
- Repeated conversion errors, metadata permission errors, invalid object errors, or access-denied errors against system views from low-privileged sessions.
- Support tools that require
KILLprivileges to manage blocking rather than using a controlled DBA process.
What to monitor – and how
Start by reviewing broad server-level permissions. SQL Server 2022 introduced more granular VIEW SERVER PERFORMANCE STATE and VIEW SERVER SECURITY STATE permissions for some DMV scenarios, so review the exact version and minimum permission needed.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
SELECT pr.name AS PrincipalName, pr.type_desc AS PrincipalType, pe.state_desc, pe.permission_name, pe.class_desc FROM sys.server_permissions AS pe JOIN sys.server_principals AS pr ON pe.grantee_principal_id = pr.principal_id WHERE pe.permission_name IN ('VIEW SERVER STATE', 'VIEW SERVER PERFORMANCE STATE', 'VIEW SERVER SECURITY STATE', 'VIEW ANY DEFINITION', 'ALTER TRACE', 'ALTER ANY EVENT SESSION', 'ALTER ANY CONNECTION') ORDER BY pr.name, pe.permission_name; |
Also review membership in server-level roles that imply visibility or session-control capabilities:
|
1 2 3 4 5 6 7 8 9 10 11 |
SELECT role_principal.name AS ServerRole, member_principal.name AS MemberName, member_principal.type_desc AS MemberType FROM sys.server_role_members AS rm JOIN sys.server_principals AS role_principal ON rm.role_principal_id = role_principal.principal_id JOIN sys.server_principals AS member_principal ON rm.member_principal_id = member_principal.principal_id WHERE role_principal.name IN ('sysadmin', 'securityadmin', 'serveradmin', 'processadmin') ORDER BY role_principal.name, member_principal.name; |
If the default trace is enabled, review who can access trace output – and whether the trace files are exposed through file shares, backup tooling, or diagnostic exports:
|
1 2 3 4 5 6 |
SELECT name, value_in_use FROM sys.configurations WHERE name = 'default trace enabled'; SELECT * FROM sys.traces; |
Use Extended Events to detect metadata probing patterns. Conversion failures, invalid object names, permission errors, and database-access errors are normal in small quantities, but repeated attempts by the same low-privileged login can indicate enumeration.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
CREATE EVENT SESSION [Monitor_Metadata_Probing] ON SERVER ADD EVENT sqlserver.error_reported( ACTION(sqlserver.client_app_name, sqlserver.database_name, sqlserver.server_principal_name, sqlserver.sql_text, sqlserver.username) WHERE ([severity] >= 11 AND [error_number] IN (207, 208, 229, 245, 257, 297, 916, 15151))) ADD TARGET package0.event_file (SET filename = N'D:\XEvents\Monitor_Metadata_Probing.xel', max_file_size = 50, max_rollover_files = 5) WITH (STARTUP_STATE = ON); GO ALTER EVENT SESSION [Monitor_Metadata_Probing] ON SERVER STATE = START; GO |
Monitor KILL usage. SQL Audit and Extended Events can both help, but many teams implement a simple statement-capture rule for KILL statements and correlate it with ticket numbers, blocking alerts, or DBA incident channels:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
CREATE EVENT SESSION [Monitor_KILL_Commands] ON SERVER ADD EVENT sqlserver.sql_batch_completed( ACTION(sqlserver.client_app_name, sqlserver.database_name, sqlserver.server_principal_name, sqlserver.sql_text) WHERE (sqlserver.like_i_sql_unicode_string(sqlserver.sql_text, N'KILL %'))), ADD EVENT sqlserver.sql_statement_completed( ACTION(sqlserver.client_app_name, sqlserver.database_name, sqlserver.server_principal_name, sqlserver.sql_text) WHERE (sqlserver.like_i_sql_unicode_string(sqlserver.sql_text, N'KILL %'))) ADD TARGET package0.event_file (SET filename = N'D:\XEvents\Monitor_KILL_Commands.xel', max_file_size = 25, max_rollover_files = 5); GO |
Recommended fixes and mitigations
- Never broadly grant
VIEW SERVER STATEjust because a user needs one performance metric. Expose only the required information through a signed stored procedure, a controlled monitoring database, or a purpose-built view.
- For SQL Server 2022 and later, evaluate whether
VIEW SERVER PERFORMANCE STATEorVIEW SERVER SECURITY STATEbetter matches the requirement instead of granting fullVIEW SERVER STATE.
- Restrict
ALTER ANY EVENT SESSIONandALTER TRACEto trusted DBA automation and senior administrators. Event sessions can capture sensitive text and should be treated as privileged telemetry.
- Treat
ALTER ANY CONNECTIONas a high-privilege operational permission. If support teams need to resolve blocking, route termination through a controlled process rather than grantingKILLmore broadly.
- Reduce sensitive text in monitoring jobs. Avoid hardcoded secrets, full allow-lists, or internal security assumptions in query text that broad monitoring users can observe.
- Protect trace and Extended Events files at the file-system level. SQL permissions are not enough if users can read the files from disk, backups, or shared diagnostic folders.
- Review whether default trace is still required. In modern environments, replace broad trace use with purpose-built Extended Events sessions that capture only the required fields and have clear retention rules.
An operational checklist for DBAs
| Area | Check | Action |
| Linked servers | Inventory linked servers, login mappings, fallback mappings, and RPC OUT. | Remove unused links, disable RPC OUT wherever possible, and replace shared mappings with explicit least-privilege mappings. |
| Observability | Review VIEW SERVER STATE, ALTER TRACE, ALTER ANY EVENT SESSION, and file access to trace/Extended Events outputs. | Expose only required diagnostics through controlled interfaces. |
KILL/session control | Review ALTER ANY CONNECTION and processadmin membership. | Restrict session termination to DBAs or approved automation with logging. |
| Error probing | Monitor repeated metadata and conversion errors from low-privileged accounts. | Investigate patterns rather than isolated errors. |
Conclusion
Linked servers, traces, DMVs, Extended Events, and KILL are just part of normal operations in many SQL Server environments – and that’s exactly why they deserve a security review. Attackers prefer paths that look like normal administration because those paths are trusted, scheduled and often under-monitored.
The practical, defensive approach is to reduce hidden trust. Who can create triggers? Which jobs touch untrusted databases? How do linked servers authenticate? Who can see query text and diagnostic metadata – and who can terminate sessions? You need to know the answer to all of these.
Then – once these relationships are visible – DBAs can apply least privilege, targeted auditing, and safe maintenance patterns without breaking the operational workflows the business depends on.
Instead of simply just disabling ‘dangerous’ features, you should be validating the features you keep enabled – and proving that their trust boundaries are intentional.
References and further reading
Protect your data. Demonstrate compliance.
FAQs: How to close SQL Server operational blind spots (linked servers, DMVs, and KILL command security risks & fixes)
1. What is a SQL Server operational blind spot?
It’s a legitimate, necessary feature – like a linked server or a monitoring job – that’s configured too permissively or watched too loosely, letting a low-privileged attacker use it as a stepping stone to more privileged systems or data.
2. How can a linked server become a security risk?
If a linked server maps all undefined local logins to one shared remote credential, a compromised low-privileged account can inherit much greater privilege on the remote server. The risk grows further if RPC OUT is enabled, since that allows remote procedure execution rather than just data access.
3. Why are DMVs and Extended Events considered a reconnaissance risk?
DMVs, traces, and Extended Events can expose query text, privileged account names, internal procedure names, and monitoring logic. A user who can view this metadata may not be privileged yet, but they gain the information needed to plan a targeted escalation.
4. What permission does the KILL command require, and why does that matter?
KILL requires ALTER ANY CONNECTION, which is bundled into powerful roles like sysadmin and processadmin. Granting this broadly to support or application accounts creates denial-of-service risk and can interfere with incident response.
5. What's the fastest first step to reduce these risks?
Review all linked servers and their login mappings, disable RPC OUT unless explicitly required, remove unused linked servers, and restrict VIEW SERVER STATE, ALTER TRACE, and ALTER ANY CONNECTION to trusted DBA accounts only.
This document contains proprietary information and is protected by copyright law.
Copyright © 2026 Red Gate Software Limited. All rights reserved
Load comments