Lack of support for impersonation in linked server hops

[n3rada]

The current implementation of SQLRecon restricts the simultaneous use of the /iuser (impersonation) flag with the /link flag. This limitation prevents executing commands that require impersonation on the originating database before traversing a chain of linked servers.

For example, running the following command:

SQLRecon.exe /a:wintoken /i:webapp01 /h:SQL01 /l:SQL02 /m:info

fails with the error:

[X] The linked SQL server flag (/link, /l) and a user to impersonate (/iuser, /i) was supplied. SQLRecon only supports one or the other.

This is problematic because it is common to have linked server configurations that require impersonation on the originating database to access downstream linked servers. For example:

Linked Server	product	provider	data_source	Local Login	Is Self Mapping	Remote Login
SQL02	SQL Server	SQLNCLI	SQL02	webapp01	False	webappGroup

In such cases:

• Impersonation is necessary on the host (SQL01) to authenticate as webapp01.
• The impersonated user (webapp01) then uses the linked server (SQL02) to execute queries with the corresponding remote login (webappGroup).

The current implementation also does not support impersonation across each hop in a linked server chain, making it impossible to define impersonation credentials for each linked server in the chain.

[4b0d3]

I’m experiencing the same issue. I can confirm that impersonation doesn’t work across multiple hops on linked servers.

This is actually quite problematic. Thank you n3rada for pointing out this issue. Hope it gets fixed soon.

[skahwah]

@n3rada and @4b0d3 thank you for pointing out this limitation. I'm not sure if I would classify a linked SQL server which requires impersonation on the originating database to access downstream linked servers as "common", but nevertheless, it is a valid scenario that can occur.

If this limitation is problematic, and if you are interested in a feature which benefits you, I encourage you to consider extending SQLRecon and create a pull request.

[n3rada]

@skahwah I appreciate your acknowledgment of this issue. However, I must respectfully disagree with the notion that requiring impersonation on the originating database to access linked servers is uncommon.

In real-world scenarios, especially in enterprise-grade environments, this pattern is quite standard! You gain access to a database as user1. Then you need to impersonate user2 in order to connect to linked database SQL02. In SQL02, you need to impersonate user3 in order to go further and so on and so forth.

[4b0d3]

I like n3rada’s idea.
This way, we no longer need to use the /i option either.

Thank you both for helping the community and enhancing the tool.

Btw, I encountered this scenario multiple times during real-world engagements and certification labs.

Sometimes, I had to use another open-source tool just to complete this task.

It would be wonderful if you could plan to improve this tool to handle all tasks related to MSSQL attacks.

Thank you guys !