Port 1433 is the door many website databases still leave on the public internet. A campaign described by FortiGuard Labs this week is about something more basic than stopping injection in the application: a Microsoft SQL Server left reachable from outside, with a weak administrator password.
In research published on 12 November 2026, FortiGuard researcher Xiaopeng Zhang says the lab found the campaign in early October. The malware scans for SQL Servers open on the SQL Server default port, 1433, then tries to log in. After a successful login it uses built-in SQL Server features to run commands on the Windows server, and installs a Monero miner and a remote-access trojan. Infosecurity Magazine notes that the report does not say how many servers were compromised or who is behind the campaign.
If your site or app sits on SQL Server, the useful question is not whether you are in the unnamed victim list. It is whether that SQL Server port is reachable from the internet, and whether the sa or admin password would survive a long password list.
What Fortinet reported
FortiGuard says the initial payload is a Go-based program that embeds the open-source Naabu port scanner. It retrieves a target address range from an attacker-controlled server, then looks for hosts with TCP port 1433 open. A companion brute-force tool then tries usernames such as sa and admin against a list of more than 2,700 passwords. CSO Online, reporting on the same research, uses the same figures.
After a login, the malware runs Transact-SQL (T-SQL) commands on the server. Those commands enable xp_cmdshell, a SQL Server feature that runs operating-system commands, then download or unpack a loader. Fortinet and Infosecurity both describe the loader pulling further malware from the attackers' infrastructure.
One payload, named to look like a Microsoft Edge update, is an XMRig-based Monero miner that uses the compromised server's CPU. Another, named after a Windows system process, was identified as a Gh0st RAT variant. Fortinet says its features include keylogging and data theft, with more than 30 control commands, and plugins for screen capture and remote desktop. The C2 server had already shut down before Fortinet's analysis, so that part of the work was static.
The malware also tries to stay. Fortinet says the first payload creates a scheduled task that runs every 30 minutes, with a name that imitates a Microsoft Edge update. The downloader sets another task; the Gh0st RAT uses a registry Run key, a Windows service and a further scheduled task. Infosecurity also reports a copy placed in the Startup folder so it ran at boot, and says each compromised server was registered with the attackers' backend.
Why an exposed port 1433 matters to site owners
Many websites and web apps sit on SQL Server databases. Some of those databases end up on a host or a cloud virtual machine with port 1433 open to the world, often because of a leftover firewall rule, a development shortcut or a "temporary" remote-admin path that was never closed. A weak or reused sa password then turns that exposure into a full server compromise. That is a database security failure as much as a firewall one. CSO quotes Sectigo's Jason Soroko on the same point: remove direct internet access to SQL Server, restrict connections to approved systems, and enforce strong, unique credentials.
This is the same class of failure as an open login form that never rate-limits guesses, only the target is the database instead of the site. Our brute-force login protection guide is about closing that pattern on a website. If you later find a miner or a remote-access tool on the box, telling a brute-force technique from an infection helps you decide what to rebuild and what to rotate. And if the database lives with a host, be clear about what your host handles and what you still need to check, including which ports are public.
What to check this week
- Keep port 1433 off the public internet. SQL Server should accept connections from the application server or a private network, not from every address on the internet. Ask your host or cloud provider which public ports are open, and close 1433 if it is among them.
- Lock down or disable the
saaccount. Do not leave a default or shared administrator password in place. If you do not needsa, disable it and use named accounts with only the rights they need. - Use strong, unique passwords. The password list in this campaign had more than 2,700 entries. A reused or obvious admin password is enough.
- Leave
xp_cmdshelldisabled. Fortinet says the attackers turned it on after they logged in so they could run operating-system commands. Unless you have a documented reason to use it, keep it off, and watch for attempts to enable it. - Look for leftover persistence if the server was ever exposed. Unexpected scheduled tasks that imitate a Microsoft Edge update, unfamiliar programs in the Startup folder, or a new Windows service deserve a closer look, and usually a restore from a clean backup.
A public look from an outside-in website security scanner can show what your website exposes from the outside, on a domain you own or have permission to test. It is not a substitute for a database-port and credential review, and it should not be used as a brute-force test against anyone else's server. We build HackerMe.
FAQ
How do I know if SQL Server is reachable from the internet?
Ask your host or cloud firewall which public ports are open. Port 1433 is the SQL Server default port. If that port is reachable from addresses you do not trust, close it and allow only the application servers that need it.
Should I disable the sa account?
If you do not need it, yes. If you do, give it a strong unique password, restrict where it can log in from, and do not use it as the application's everyday account.
What is xp_cmdshell, and why does it matter?
It is a built-in SQL Server feature that runs operating-system commands. Fortinet says this campaign enabled it after a successful login, then used it to drop a miner and a remote-access trojan. Keep it disabled unless you have a clear, temporary reason to turn it on.
Originally published on the HackerMe security blog.
