Diese Ausgabe dreht sich um die Verwaltungswerkzeuge der MSPs selbst. N-able hat N-central nach der Veröffentlichung von mehr als 30 Zero-Days offline genommen, Angreifer nutzen zwei Lücken im AhsayCBS-Backupserver für Webshells und Cryptominer, und die OpenSSH-Lücke SSHole wird inzwischen aktiv ausgenutzt. Außerdem schließt Google eine aktiv ausgenutzte Zero-Day-Lücke in Chrome, und Angreifer missbrauchen eine Qubole-Anbindung, um AWS-Umgebungen von Kunden leerzuräumen.
- N-able nimmt N-central nach Veröffentlichung von mehr als 30 Zero-Days in der RMM-Software offline
- AhsayCBS-Backupserver über zwei Lücken gehackt: Webshells, Cryptominer und Jagd auf Veeam-Credentials
- SSHole: Bereits gemeldete OpenSSH-Lücke auf musl-Linux wird jetzt aktiv ausgenutzt und von CISA gelistet
- Chrome-Update schließt aktiv ausgenutzte Zero-Day-Lücke in der XML-Komponente, die achte in diesem Jahr
- Angreifer missbrauchen Qubole-Anbindung an AWS-Umgebungen von Kunden, um Secrets und S3-Daten zu stehlen
N-able nimmt N-central nach Veröffentlichung von mehr als 30 Zero-Days in der RMM-Software offline
| Schwachstelle | 33 mutmaßliche kritische Schwachstellen in N-able N-central (hosted und On-Premises), die sich zu vier Exploit-Ketten unter dem Namen „Able2Shell“ verknüpfen lassen: Authentifizierungsumgehung, Credential Disclosure, beliebiges Schreiben von Dateien, XXE, RCE und Privilege Escalation. Getestet mit N-central Appliance 2026.4.0.31, ältere Versionen sind wahrscheinlich ebenfalls betroffen |
| CVE-Nummer | Keine CVE vergeben |
| Aktiv ausgenutzt | Nein, N-able hat am 9. November (15:15 UTC) keine Ausnutzung festgestellt. Die Proof-of-Concept-Exploits sind jedoch öffentlich auf GitHub verfügbar |
| Patch verfügbar | Nein, N-able arbeitet an einem Hotfix, ein Termin steht noch nicht fest. N-able hat die gehosteten Umgebungen offline genommen und empfiehlt, On-Premises-Server bis auf Weiteres abzuschalten |
Was ist passiert?
Der Forscher Sean Bales veröffentlichte am Sonntagabend, 8. November, auf GitHub das Repository „Able2Shell“ mit Proof-of-Concept-Exploits, die er nach eigenen Angaben teilweise mithilfe von KI gefunden hat. Laut BleepingComputer ist die gefährlichste Kette eine nicht authentifizierte XXE-Schwachstelle, die in Codeausführung und die Anlage eines zusätzlichen Administratorkontos mündet. N-able meldete einen „critical security incident“, nahm das gehostete N-central in Amerika, Europa und im asiatisch-pazifischen Raum offline und verspricht alle vier Stunden ein Update.
Was können die Folgen sein?
N-central ist eine RMM-Plattform, mit der MSPs die Systeme all ihrer Kunden verwalten. Wer die Verwaltungsplattform kontrolliert, kann Skripte und Tools an alle angebundenen Umgebungen verteilen. Das ist bei früheren Angriffen auf N-central in diesem Jahr bereits geschehen, wie Huntress anmerkt. Solange der Hotfix fehlt, fallen zudem Ihr eigenes Monitoring und Ihr Patchmanagement aus, wenn Sie den Server offline nehmen.
Was müssen IT-Administratoren jetzt tun?
Nehmen Sie On-Premises-N-central-Server vom Netz und lassen Sie sie offline, bis N-able meldet, dass eine Wiederinbetriebnahme sicher ist. Beim gehosteten Dienst sollten Sie mit einem Ausfall rechnen und die Statusseite von N-able verfolgen. Prüfen Sie die Authentifizierungsprotokolle ab dem 8. November auf unerwartete Zugriffe und suchen Sie in den Audit-Logs nach auffälligen Remote-Sitzungen, neu ausgerollten Skripten und unbekannten Administratorkonten. Spielen Sie den Hotfix erst ein, wenn N-able dies empfiehlt; die Versionsnummer kann von 2026.4.0.31 abweichen. Bereiten Sie außerdem die Kommunikation mit Ihren Kunden vor, denn Sie können vorübergehend keine Fernwartung leisten.
AhsayCBS-Backupserver über zwei Lücken gehackt: Webshells, Cryptominer und Jagd auf Veeam-Credentials
| Schwachstelle | Authentifizierungsumgehung und nicht authentifizierte Remote Code Execution als SYSTEM (über /rps/api/json/UpdateReceivers.do) in Ahsay AhsayCBS, dem Backupserver von Ahsay (v10 sowie v7 bis v9) |
| CVE-Nummer | CVE-2026-105133 (Authentifizierungsumgehung) und CVE-2026-105134 (Remote Code Execution) |
| Aktiv ausgenutzt | Ja, seit Anfang Oktober 2026. Huntress beobachtete zwischen dem 8. und 11. Oktober drei kompromittierte Server in einer Umgebung; die erste Meldung stammt vom 8. Oktober, die Folgeuntersuchung erschien am 9. November |
| Patch verfügbar | Ja, AhsayCBS 10.3.4.45 (v10) und 9.15.2.70 (v7 bis v9). Huntress hat nur 10.3.4.45 verifiziert. Das Patchen entfernt bereits platzierte Dateien nicht |
Wie wurde die Lücke ausgenutzt?
Die Angreifer drangen über aus dem Internet erreichbare AhsayCBS-Server ein. Laut der Untersuchung von Huntress platzierten sie fünf Familien von JSP-Webshells, installierten einen XMRig-Cryptominer mit einer SYSTEM-Aufgabe, die jede Minute ausgeführt wird, und richteten ein Python-Implantat ein, das über HTTPS und DNS-over-HTTPS mit einem C2-Server kommuniziert. Außerdem tauchten Tunneling-Tools (gost, chisel), AnyDesk, Atera und Splashtop, ein lokales Konto „wdguest“, Mimikatz und weitreichende Defender-Ausnahmen auf. Eine Webshell versteckte Payloads in PNG-Pixeldaten.
Was können die Folgen sein?
Die Angreifer suchten gezielt nach Backup-Infrastruktur. Auf einem zugehörigen Veeam-Server versuchten sie, gespeicherte Credentials aus der Datenbank auszulesen. Ein gehackter Backupserver verschafft Zugriff auf Kundendaten, gespeicherte Passwörter und die Wiederherstellungsfähigkeit selbst. Ob tatsächlich Daten gestohlen wurden, ist unbekannt. Eine Webshell mit Downloadfunktion kann als Exfiltrationskanal dienen.
Was müssen IT-Administratoren jetzt tun?
Aktualisieren Sie auf die genannten Versionen und suchen Sie anschließend auf jedem Server nach unbekannten .jsp-Dateien, Ordnern wie ahsay_*, unbekannten geplanten Aufgaben, Defender-Ausnahmen und einer Python-Installation im SYSTEM-Profil. Durchsuchen Sie die AhsayCBS-Logs nach Anfragen an UpdateReceivers.do. Bei einer bestätigten Kompromittierung empfiehlt Huntress eine vollständige Neuinstallation aus einem vertrauenswürdigen Backup sowie die Rotation aller Credentials, die über den Server erreichbar waren, einschließlich derer anderer Backup-Software im Netzwerk.
SSHole: Bereits gemeldete OpenSSH-Lücke auf musl-Linux wird jetzt aktiv ausgenutzt und von CISA gelistet
| Schwachstelle | Authentifizierungsumgehung in OpenSSH auf musl-basierten Linux-Systemen wie Alpine: Ein zu langes Passwort führt dazu, dass die Hashfunktion von musl ein „*“ zurückgibt, das OpenSSH bei Konten mit einem „*“ in /etc/shadow als gültige Übereinstimmung wertet |
| CVE-Nummer | CVE-2026-123158 |
| CVSS-Score | 8,1 (laut The Hacker News) |
| Aktiv ausgenutzt | Ja, erste Versuche am 5. November, erste erfolgreiche Angriffe am 6. und 7. November. CISA nahm die Lücke am 9. November in den KEV-Katalog auf |
| Patch verfügbar | Ja, OpenSSH 10.6p2 (veröffentlicht am 5. November). Alternativ: Passwortauthentifizierung für SSH deaktivieren |
Wie wurde die Lücke ausgenutzt?
Diese Lücke war bereits Thema im Patchwork vom Freitag, 6. November. Neu ist die bestätigte Ausnutzung. Laut BleepingComputer erschien vier Stunden nach dem Patch ein Proof-of-Concept, und GreyNoise beobachtete etwa 40 Stunden nach dem Fix den ersten erfolgreichen Angriff, mit 16 Angriffsketten von sechs IP-Adressen. Previdian zählte Versuche von 13 IP-Adressen in neun Ländern, watchTowr beobachtete Botnet- und Cryptominer-Aktivitäten. Nach der Anmeldung erkunden die Angreifer das System und den Container, fragen Cloud-Metadaten ab, versuchen Passwort-Hashes und Root-SSH-Schlüssel auszulesen und passen authorized_keys an, um sich dauerhaft festzusetzen. In einem Fall wurde das Python-Implantat „TAC Agent“ installiert.
Was können die Folgen sein?
Konten mit einem „*“ im Passwortfeld, etwa Service-Accounts, sind ohne gültiges Passwort zugänglich. Bei Konten mit passwortlosen Adminrechten führt das zu Root-Zugriff. Laut The Hacker News steht die Lücke zusammen mit drei weiteren Schwachstellen im KEV-Katalog, mit dem 12. November als Frist für US-Bundesbehörden. Die Ausnutzung ist laut Defused Cyber noch nicht weit verbreitet.
Was müssen IT-Administratoren jetzt tun?
Aktualisieren Sie OpenSSH auf 10.6p2 oder neuer oder deaktivieren Sie die SSH-Passwortauthentifizierung. Suchen Sie nach unerwarteten Passwort-Logins bei Konten mit einem „*“ in /etc/shadow, prüfen Sie authorized_keys auf unbekannte Schlüssel und suchen Sie nach TAC-Agent-Dateien und zugehörigen Startup-Diensten. Achten Sie besonders auf Alpine-Container und andere musl-basierte Images.
Chrome-Update schließt aktiv ausgenutzte Zero-Day-Lücke in der XML-Komponente, die achte in diesem Jahr
| Schwachstelle | Use-after-free in der XML-Komponente von Google Chrome, Teil eines Updates, das neun Schwachstellen schließt |
| CVE-Nummer | CVE-2026-125350 |
| Aktiv ausgenutzt | Ja, laut Google. Details zu den Angriffen wurden nicht veröffentlicht, und CISA hatte die Lücke am 10. November noch nicht in den KEV-Katalog aufgenommen |
| Patch verfügbar | Ja, Chrome 157.0.8103.50 oder neuer (Linux), 157.0.8103.50/.51 (Windows und Mac) |
Was ist passiert?
Ein anonymer Forscher meldete die Lücke am 6. November. Google veröffentlichte den Fix am Montag, 9. November, und meldet, dass sie bereits ausgenutzt wird, so SecurityWeek. Es ist die achte Chrome-Zero-Day-Lücke im Jahr 2026. Das Update schließt außerdem sechs Bugs mit hohem Schweregrad, unter anderem in WebGL, FileSystem, Compositing, GPU und V8, sowie zwei Bugs mit mittlerem Schweregrad.
Was können die Folgen sein?
Chrome ist auf nahezu jedem verwalteten Arbeitsplatz installiert. Ein Use-after-free im Browser ist häufig der erste Schritt eines Angriffs, der über eine bösartige Seite beginnt. Da Google noch keine Details nennt, ist unklar, wer die Lücke ausnutzt und gegen wen.
Was müssen IT-Administratoren jetzt tun?
Verteilen Sie Chrome 157.0.8103.50 oder neuer so schnell wie möglich über Ihr Patchmanagement und prüfen Sie, ob der Browser nach dem Update tatsächlich neu gestartet wurde.
Angreifer missbrauchen Qubole-Anbindung an AWS-Umgebungen von Kunden, um Secrets und S3-Daten zu stehlen
| Schwachstelle | Missbrauch kontoübergreifender IAM-Rollen (Cross-Account), die Kunden für den Datenplattform-Anbieter Qubole in AWS angelegt hatten. Die Angreifer nutzten IAM-Credentials eines mit Qubole verknüpften AWS-Kontos und übernahmen die Rollen mithilfe der ExternalId. Wie diese Credentials erbeutet wurden, wurde nicht bekanntgegeben |
| CVE-Nummer | Keine CVE vergeben |
| Aktiv ausgenutzt | Ja, vom 14. bis 26. Oktober 2026 in mehreren Kundenumgebungen. Wiz, Sentra und Mandiant veröffentlichten die Erkenntnisse am 9. November |
| Patch verfügbar | Nein, es handelt sich nicht um eine Softwarelücke. Administratoren müssen Rollen verschärfen, Secrets rotieren und CloudTrail durchsuchen |
Wie wurde die Lücke ausgenutzt?
Laut der Untersuchung von Wiz erhalten Anbieter Zugriff über eine Rolle im Konto des Kunden, deren Trust Policy es dem Anbieterkonto erlaubt, diese Rolle anzunehmen – meist abgesichert mit einer ExternalId. Der Angreifer rief sts:AssumeRole mit dieser ExternalId auf, und alle Versuche waren erfolgreich. Wiz weist darauf hin, dass die ExternalId kein Geheimnis ist: Sie steht in CloudTrail und in Infrastructure-as-Code. Eine Einschränkung auf Quell-IP-Adressen hätte alle beobachteten Angriffe blockiert. Der Angreifer inventarisierte S3, EC2, RDS, IAM und KMS, las Lambda-Umgebungsvariablen, Secrets Manager und SSM Parameter Store aus, testete gefundene Schlüssel mit TruffleHog (auch für Entra ID und Okta) und las teilweise komplette S3-Buckets aus.
Was können die Folgen sein?
Das Muster passt zu früheren Angriffen über vertrauenswürdige Anbieteridentitäten: Ein Einbruch bei einem einzigen Anbieter öffnet die Umgebungen all seiner Kunden. Gefundene Secrets verschaffen Zugang zu weiteren Systemen, und das Widerrufen von Sitzungen beendet bestehende temporäre Credentials nicht.
Was müssen IT-Administratoren jetzt tun?
Inventarisieren Sie alle IAM-Rollen, die externen Konten vertrauen, und entfernen Sie, was nicht mehr benötigt wird. Beschränken Sie den vertrauenswürdigen Principal auf den spezifischen IAM-Principal des Anbieters und ergänzen Sie aws:SourceIp oder aws:SourceVpce. Verwenden Sie die ExternalId nicht als einzige Kontrolle. Suchen Sie in CloudTrail ab dem 1. Oktober nach AssumeRole-Aufrufen aus dem Konto 805246085872 mit einer Quell-IP außerhalb von AWS, nach Sitzungen mit dem Namen „quiam-“ und nach GetCallerIdentity-Aufrufen mit einem TruffleHog-User-Agent. Rotieren Sie bei einem Treffer alle Secrets, Parameter und Lambda-Variablen, die die Rolle lesen konnte.
Dieser Artikel ist ursprünglich auf Niederländisch bei MSP Business erschienen. Zum Originalartikel →
