ASEC hat Ende Juli 2026 eine neue Kampagne namens Larva-26009 dokumentiert: Fernsteuerungstools, ein VPN-Tunnel zur Tarnung, Web-Shells als Hintertür und am Ende ein Krypto-Miner, der die Server-Hardware für sich arbeiten lässt. Der Artikel selbst nennt keinen initialen Angriffsvektor. Muss er auch nicht – bei praktisch jeder Kampagne dieser Nummernserie (26002, jetzt 26009) ist es dasselbe Muster: kein Exploit, keine CVE, sondern stumpfe Brute-Force- und Dictionary-Angriffe gegen SQL-Server-Instanzen mit schwachem sa-Passwort, die offen im Internet hängen.
Das eigentliche Problem sitzt selten im Code
In vielen norddeutschen KMU läuft ein SQL Server als Backend für eine gewachsene Access-Anwendung oder ein Branchenprogramm seit zehn, fünfzehn Jahren fast unbeaufsichtigt. Die Grundinstallation stammt von einem Dienstleister, der längst nicht mehr im Boot ist. Der sa-Account existiert noch, oft mit einem Passwort, das nie geändert wurde. Ob Port 1433 nach außen offen ist, weil mal ein Außendienstmitarbeiter Zugriff brauchte, weiß im Zweifel niemand mehr genau.
Genau das ist die Zielgruppe von Larva-26009 und Verwandten. Nicht die gut gepflegte Enterprise-Umgebung mit SOC, sondern der Server, der seit Jahren „einfach läuft“.
Wie diese Kampagnen typischerweise reinkommen
ASEC beschreibt für die Schwesterkampagne Larva-26002 den Ablauf im Detail, und er passt zum Muster, das jetzt bei 26009 wieder sichtbar wird: Scan nach offenem Port 1433, Brute-Force oder Dictionary-Attacke gegen den sa-Account, danach System-Recon (hostname, whoami, netstat -an), anschließend Nachladen von Tools über den BCP-Befehl oder direkt per curl/PowerShell. Erst danach kommen Fernsteuerung, Persistenz und – bei Larva-26009 – der Miner.
Für die Abwehr heißt das: Der Hebel liegt nicht bei Patches. Er liegt bei Netzwerkzugriff, Zugangsdaten und Rechten.
Netzwerk zuerst: Angriffsfläche verkleinern
Bevor überhaupt ein Login-Versuch stattfinden kann, muss der Angreifer den Server erreichen. Die schnellste und wirksamste Maßnahme ist daher meistens nicht T-SQL, sondern die Firewall: Port 1433 nur für bekannte IP-Adressen oder ausschließlich über VPN erreichbar machen. Wo kein Zugriffspfad existiert, läuft auch kein Brute-Force-Versuch ins Leere – er findet gar nicht erst statt.
Ist das aus betrieblichen Gründen nicht möglich (Außendienst, mehrere Standorte ohne Site-to-Site-VPN), wird das Innenleben umso wichtiger.
sa abschalten, Logins und Rechte aufräumen
Der sa-Account ist das bevorzugte Ziel jeder Dictionary-Attacke, weil sein Name feststeht und er per Definition Systemadministrator-Rechte hat. Deaktivieren, statt löschen – das Login bleibt für Notfälle erhalten, kann sich aber nicht mehr anmelden:
-- sa-Konto deaktivieren (Login bleibt bestehen, Anmeldung wird aber verweigert)
ALTER LOGIN sa DISABLE;
-- Zusätzlich umbenennen, damit automatisierte Angriffe den Namen nicht mehr treffen
ALTER LOGIN sa WITH NAME = sa_disabled_20260804;
Wichtig danach: Alle Anwendungen, die intern noch mit sa arbeiten (bei gewachsenen Access-Backends keine Seltenheit), auf einen dedizierten Service-Account mit den tatsächlich benötigten Rechten umstellen – nicht auf einen zweiten sa-Ersatz mit Sysadmin-Rolle.
Danach lohnt eine Bestandsaufnahme: Wer hat aktuell überhaupt Sysadmin-Rechte?
-- Alle Logins mit Sysadmin-Rolle auflisten
SELECT sp.name AS LoginName,
sp.type_desc,
sp.is_disabled,
sp.create_date,
sp.modify_date
FROM sys.server_principals sp
JOIN sys.server_role_members rm ON sp.principal_id = rm.member_principal_id
JOIN sys.server_principals r ON rm.role_principal_id = r.principal_id
WHERE r.name = 'sysadmin'
ORDER BY sp.name;
Aus meiner Praxis im norddeutschen Mittelstand zeigt sich: Diese Abfrage fördert regelmäßig Logins zutage, die niemand mehr zuordnen kann – Reste von Dienstleistern, Testkonten, Accounts von Mitarbeitern, die längst nicht mehr im Unternehmen sind. Jeder davon ist ein potenzieller zweiter Weg für einen Angreifer, der sa nicht mehr findet.
Login-Auditing aktivieren
Ohne Auditing gibt es schlicht keine Datengrundlage, um einen Angriff überhaupt zu bemerken. Die Einstellung sitzt in der Registry und lässt sich per SSMS-Dialog ändern – oder per T-SQL, was sich sauber dokumentieren und auf mehrere Server ausrollen lässt:
-- Auditing auf "beide" umstellen (erfolgreiche und fehlgeschlagene Logins protokollieren)
EXEC xp_instance_regwrite
N'HKEY_LOCAL_MACHINE',
N'Software\Microsoft\MSSQLServer\MSSQLServer',
N'AuditLevel',
N'REG_DWORD',
3;
Ein Neustart des SQL-Server-Dienstes ist danach nötig, damit die Einstellung greift. Ab dann landen fehlgeschlagene Logins als Fehler 18456 im SQL Server Error Log und im Windows-Anwendungsereignisprotokoll – die Grundlage für jeden weiteren Schritt.
Alerts per E-Mail: SQL Server Agent + Database Mail
Reines Loggen bringt wenig, wenn niemand regelmäßig hineinschaut. In der Standard Edition lässt sich das sauber automatisieren, sobald Database Mail eingerichtet ist (Profil und Operator einmalig per SSMS-Assistent anlegen):
-- Alert auf Fehler 18456 (fehlgeschlagener Login) definieren
EXEC msdb.dbo.sp_add_alert
@name = N'Fehlgeschlagene SQL-Server-Logins',
@message_id = 18456,
@severity = 0,
@notification_message = N'Fehlgeschlagener Login-Versuch erkannt.';
-- Benachrichtigung per E-Mail an einen definierten Operator
EXEC msdb.dbo.sp_add_notification
@alert_name = N'Fehlgeschlagene SQL-Server-Logins',
@operator_name = N'IT-Verantwortlicher',
@notification_method = 1; -- 1 = E-Mail
Damit landet jeder fehlgeschlagene Login-Versuch als E-Mail beim zuständigen Operator, statt unbemerkt im Log zu verschwinden. Ein einzelner Fehlversuch ist noch kein Vorfall – eine Häufung binnen Minuten schon. Wer das feiner steuern will, filtert serverseitig oder bündelt Alerts über die SQL-Server-Agent-Eigenschaften, statt bei jedem einzelnen Versuch eine Mail zu verschicken.
SQL Server Express: Was geht, was nicht
Ein nicht kleiner Teil der Access-Backends bei KMU läuft auf SQL Server Express, meist unbewusst, weil es kostenlos mit der Anwendung mitkam. Die zentrale Einschränkung für dieses Thema: Express enthält keinen SQL Server Agent. Damit fallen sp_add_alert und sp_add_notification komplett weg – Automatisierung über Agent-Jobs ist in Express schlicht nicht vorgesehen.
Database Mail selbst ist dagegen ein Feature der Datenbank-Engine, nicht des Agents, und funktioniert auch in Express – sp_send_dbmail lässt sich manuell oder aus einem Trigger heraus aufrufen. Für automatisierte Alerts bei fehlgeschlagenen Logins bleibt in Express nur der Umweg über den Windows-Taskplaner: ein per sqlcmd gestartetes Skript, das regelmäßig das SQL-Server-Errorlog per xp_readerrorlog nach Fehler 18456 durchsucht und bei Treffern sp_send_dbmail aufruft. Umständlicher als mit Agent, aber machbar. Wer öfter an diese Grenze stößt, sollte grundsätzlich prüfen, ob ein Umstieg auf Standard Edition nicht ohnehin fällig ist – die 10-GB-Datenbankgrenze und die Beschränkung auf einen Prozessorsockel treffen wachsende Access-Backends ohnehin früher oder später.
Wo dieser Ansatz an Grenzen stößt
Alles hier beschriebene wehrt Brute-Force gegen SQL-Logins ab. Es schützt nicht vor kompromittierten Windows-Konten, wenn der Server per Windows-Authentifizierung angebunden ist und ein Active-Directory-Konto anderswo abgegriffen wurde. Es schützt auch nicht vor Phishing, das direkt an einen Mitarbeiter mit Zugriffsrechten geht, und es ist reaktiv: Ein Alert kommt, nachdem der erste Versuch bereits stattgefunden hat, nicht vorher. Wer das ernsthaft dicht machen will, kombiniert diese Maßnahmen mit einer restriktiven Firewall-Regel – die bleibt der wirksamste einzelne Schritt.
Für alle, die selbst keinen Handgriff daran anlegen
Wer das nicht selbst umsetzen will oder kann: Der komplette Block – sa deaktivieren, Rechte aufräumen, Auditing aktivieren, Alerts einrichten – lässt sich an einem Nachmittag pro Server erledigen, wenn jemand weiß, wo er hinschauen muss. Bei mehreren Standorten mit unterschiedlichen Access- oder Branchensoftware-Backends multipliziert sich der Aufwand entsprechend, ist aber planbar.
Wenn dich weniger der Code interessiert als die Frage, was ein solcher Vorfall dein Unternehmen tatsächlich kosten würde und wie man solche Altsysteme grundsätzlich sauber hält statt von einem Sicherheitsvorfall zum nächsten zu pflegen – das ist ein Gespräch, kein Blogpost. Erreichbar über sesoft.de/kontakt.
Quellen
- Börse Express: Larva-26009: Neue Schadsoftware-Kampagne zielt auf SQL-Server (29.07.2026)
- ASEC / hendryadrian.com: Attack Targeting MS-SQL Servers to Deploy the ICE Cloud Scanner (Larva-26002)
- Cryptika: Threat Actors Continuously Attacking MS-SQL Servers to Deploy ICE Cloud Scanner
- Microsoft Learn: Dokumentation zu SQL Server Editions und Features (Vergleich Express/Standard)
Sönke Schäfer
Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU rund um Microsoft Access, VBA und SQL Server. Sein Schwerpunkt liegt auf pragmatischen Lösungen um gewachsene Altsysteme herum – dazu gehört auch, sie sauber und sicher zu halten, statt sie zu ersetzen. Mehr unter sesoft.de/datenschaefer-soenke-schaefer.
