Click on the banner to learn about and purchase my database training on Azure

SQL Server – Beware of server role securityadmin! Using privilege elevation to become sysadmin

Views: 670 views
This post is the 17 part of 20 in the series. Security and Audit
Reading Time: 6 minutes

Speak guys!

In this post I would like to share with you an extremely dangerous situation that can end up going unnoticed by most SQL Server DBA's, which is the use of the securityadmin role or the ALTER ANY LOGIN and IMPERSONATE ANY LOGIN permissions without understanding exactly what they are for and what that someone with these permissions can do.

If you are interested in security, buy my training Security in SQL Server and learn how to identify and protect yourself against the most varied attacks on SQL Server databases.


According to Microsoft documentation, which can be accessed by clicking here, the members of the role securityadmin manage logins and their properties. They have GRANT, REVOKE, and DENY server-level permissions and can have those same database-level permissions as well, if they have access to the database. Also, they can reset passwords for SQL Server logins.

IMPORTANT: The ability to grant access to the Database Engine and configure user permissions allows a member of the securityadmin role to assign most server permissions. The securityadmin role should be treated as equivalent to the sysadmin role.

Although I have already demonstrated this demo in several lectures around Brazil since 2018 and I have also demonstrated it in my SQL Server Security, this content was not yet available here on the blog and so I would like to share it with you.

securityadmin is the same as sysadmin?

If you are a DBA who has already added a user in the securityadmin role after some request and didn't even ask why you need this role and didn't research more about what this role can do, you should be worried now.. lol

In theory, these two server roles are quite different. The securityadmin is a role that allows you to manage logins and login properties. The sysadmin role, on the other hand, is a role that allows you to do anything, with unrestricted privileges and no limitation of anything.

So how are these two server roles considered equivalent, according to Microsoft documentation?

To demonstrate how this works, I'll create a user called teste_security_admin and associate that user with the server role securityadmin:

Now I will connect to the instance using the newly created user:

Now I will check my permissions and the logged in user:


Just checking the teste_security_admin user permissions:


Everything is fine and as expected so far. I will try to increase my access levels:

Okay, it didn't work. I'll try to impersonate a sysadmin(sa) user to do what I want later.

It didn't work either… I'll then try to give myself IMPERSONATE ANY LOGIN access and impersonate a sysadmin (sa) user to do whatever I want later.

The message was very clear: I cannot modify my own accesses.

Well, as a member of the securityadmin role, I have the ALTER ANY LOGIN permission, which allows me to manage the permissions of any login and also create/delete logins. What if I create another login then?


I will now give IMPERSONATE ANY LOGIN access to this new user. With this, I will be able to impersonate the user “sa”.


Looks like it worked. We will test connecting to the instance with this new user!

Let's check the current permissions:


With just this “IMPERSONATE ANY LOGIN” permission (being equally dangerous) that I granted to a new login I just created, that's where the damage comes. With this permission, I can impersonate ANY user on the instance and run commands as if I were him (and inheriting the same permission levels he has).

To learn more about user impersonation and the EXECUTE AS command, I suggest reading the article SQL Server - How to use EXECUTE AS to execute commands as another user (Impersonate login and user).

We'll see if that's true and I'll impersonate the “sa” user:


Jeez! Now I'm running commands as if I were the “sa” user!! Look there because this user must always be deactivated and renamed to a non-default name, as I explain in the article SQL Server - How to disable “sa” login minimizing impacts.

Still don't believe me? Let's make my old user a sysadmin then:


And finally, I'm going to connect again with the teste_security_admin user just to leave no doubt and run the permissions validation again.

Elevation of privilege attack successfully performed and sysadmin access gained. Now I have full control of the instance.

After reading this article, the risk of releasing the ALTER ANY LOGIN, IMPERSONATE ANY LOGIN permissions or adding the user in the securityadmin role is very clear. All these permissions are equivalent to adding the user to the sysadmin role, since he gets to be part of the sysadmin role indirectly by elevating privileges.

Want to know which users have ALTER ANY LOGIN or IMPERSONATE ANY LOGIN permissions?


Want to know who are the logins that belong to the server role securityadmin or sysadmin?


I hope you enjoyed this security tip and that it can help you keep your data more secure.
A big hug and see you in the next article.