Internet Exposed SQL Servers Vulnerable to New Malware Attack

Earlier last month, a new malware threat was detected which has been infecting Microsoft SQL Servers which are exposed to the internet. In this blog, we'll cover how you can check if your servers are at risk and how to take action.

What happened?


encent Security, the cybersecurity division of the Chinese technology company Tencent, published a report showing they had identified thousands of SQL Servers infected with the malware (click here to view). The threat has been attributed to malware gang MrbMiner and identifies vulnerable SQL Servers from scanning the internet and using brute-force attacks to gain access to administrator accounts that are configured with weak passwords. Once access has been gained on a system, an application is installed which adds a new account to the SQL Server for further attacks should the initial access be revoked. Finally, the malware downloads an app from its central command server which then mines the Monero (XMR) cryptocurrency on the server and deposits any generated XMR coins to the attackers’ accounts.

How do I know if my servers are at risk?

To identify if your servers have been attacked, look for a new login called “Default” which has a password set to ‘@fg125kjnhn987’.

What can I do to minimise risk?

Most organisations do not expose their database servers to the internet, choosing to place critical servers behind firewalls, and other layers of security to restrict the attack surface. But what about systems which need to be internet facing or what if you are using services such as Azure SQL Database, which by its design is available via the internet?

The malware attack highlighted by Tencent, shows that one of the most basic options is to not use weak passwords and restrict the number of administration accounts. The inbuilt SQL server Sysadmin account “SA” is disabled by default and it is recommended to not use this account for administration or application access due to its familiar name. Dedicated administrator accounts should be created and, where possible, use domain level accounts for user and service access and ideally domain groups to control user access.

Monitoring of when new logins are created or altered on your SQL Server instances is also something which can be configured very quickly and easily without the need to purchase third party tools. As an example, the below T-SQL code can be used to create a server-side trigger which is fired when a new SQL Server login is created or altered and sends an email alert with the login name, what was changed, the user who changed it and when. This code works on SQL Server 2008 to 2019. This information can then be sent automatically to administration staff and can support an audit trail for security incidents.


This code is an example of a simple way to gain visibility to security incidents on your on-premises SQL Servers, but there are multiple security options, design practices, auditing tools and alerting functions which can be deployed to help mitigate data breaches, easily and cheaply.

For Azure SQL Databases which by default allow access via the public facing internet, the primary restriction for unwanted client access is through the server and database firewalls which are set to deny all by default. These should be configured and regularly assessed to remove unused historic access and role-based access controls deployed to restrict who can administer the firewalls of an SQL database. It should also be noted that if the Azure SQL Server has been configured to ‘Allow Access for Azure Services’ to support features such as allowing data access to PowerBI, then this exposes the SQL Server to all organisation tenants in Azure and the firewalls are not used for any connections originating from within the Azure boundary.

This is something many organisations do not realise and, with a flick of an innocuous looking option in the Azure portal, means anyone with a server or service deployed in Azure has the potential to attempt connections directly to your Azure SQL Database without any network restrictions. Only user authorisation configuration denies access to the underlying data, which brings us back to the number one security rule, making sure passwords are strong and regularly changed.

Azure does provide tools to help audit user access easily as well as providing services such as Azure SQL Database Threat Detection to identify and alert on possible vulnerabilities. If you wish to remove the public facing access of your Azure SQL databases, then Service Endpoints can be configured which provide a private IP address for the SQL Servers to VNets and services within your own Azure tenancy.

Next Steps

If you are looking to assess the security configuration and identify any best practice failings with your on-premises or Azure hosted Microsoft SQL Servers, Ultima can help. Ultima provides SQL Server Health Checks and SQL Server Security Assessment engagements that evaluate and report on multiple areas of your SQL estate to identify common security issues and provides the capabilities to recommend and rectify any failings.

If you would like further information, please get in contact with your Ultima Account Manager or contact us below.

Full Name