Trojaner Ryuk verbreitet sich rasant

Trojaner Ryuk verbreitet sich rasant

Trojaner Ryuk verbreitet sich rasant

Eine neue Variante des Erpressungstrojaners Ryuk-Ransomware, der zur sogenannten Ransomeware-as-a-Service (RaaS)-Gruppe gehört, verbreitet sich aktuell rasant und selbstständig in den Netzwerken. Laut MITRE ATT&CK steckt hinter Ryuk möglicherweise eine wirtschaftlich motivierte und kriminelle Hackergruppe namens Wizard Spider. Hierbei handelt es sich um einen osteuropäischen Bedrohungsakteur, der insbesondere für einige Angriffe im Gesundheitswesen verantwortlich ist. Der Erpressungstrojaner stellt eine sehr ernstzunehmende Gefahr dar. Daher möchten wir Ihnen im folgenden Beitrag gerne Hintergrundinformationen dazu geben.

Cyberkriminelle haben Ryuk mit wurmähnlichen Fähigkeiten erweitert, wie es bereits in der Vergangenheit im Kontext des Trojaners „Emotet“ geschehen ist. Mit dieser Eigenschaft ausgestattet, erlangt Ryuk die Fähigkeit, sich auf andere Systeme im lokalen Netzwerk des Opfers auszubreiten.

Wir haben aktuell einen ähnlichen Fall bei einem unserer Kunden untersucht, ihn jedoch glücklicherweise rechtzeitig informieren und damit die Verbreitung im Kunden-Netzwerk verhindert können. Anlass zur Untersuchung gaben uns die in der CSOC-Leitstelle detektierten Meldungen „Local Scheduled Task Commands“ und „RPC (Remote Procedure Call) to the Internet“.

Die Untersuchung der Meldungen im SIEM ergab folgendes: Es wurde der Versuch unternommen, über die Hilfsfunktion von Windows „schtasks.exe“ eine Verbindung zu verschleiern und die Malware durch die Verwendung von geplanten Tasks in Windows innerhalb einer Windows-Domäne zu verbreiten. Besonders kritisch dabei ist, dass sich die Schadsoftware unmittelbar nach Ausführung von Ryuk auf jedes erreichbare Gerät ausbreitet, auf das Window RPC-Zugriffe (Rem ote Procedure Call) möglich sind. Für die Verbreitung über das lokale Netzwerk listet Ryuk alle IP-Adressen im lokalen ARP-Cache (Adress Resolution Protocol) auf und sendet ein LAN-Paket (Wake-on-LAN) an die detektierten Geräte. Im nächsten Schritt werden die identifizierten Freigabe-Ressourcen für die Systeme gestartet und der Verschlüsselungsprozess der Inhalte in die Wege geleitet. Anschließend folgt die Lösegeldforderung zur Entschlüsselung der Daten.

Unsere Handlungsempfehlungen:

  • Stellen Sie sicher, dass Betriebssystem-, Software- und Firmware-Patches installiert sind.
  • Verwenden Sie eine mehrstufige Authentifizierung mit einem starken zweiten Faktor.
  • Konten, Zugriffe, Protokolle und andere Komponenten sollten regelmäßig auditiert werden, um die Einstellungen und Aktivitäten zu überprüfen.
  • Führen Sie regelmäßig Datensicherungen durch, insbesondere von kritischen Systemen und speichern Sie diese offline.

Sind Sie bereits von Ryuk betroffen, empfehlen wir folgende Maßnahmen:

  • Sensibilisieren Sie Ihre Mitarbeiter im Umgang mit Phishing-E-Mails, indem Sie ihnen Awareness-Schulungen anbieten.
  • Es sollten die Kennwörter der betroffenen Benutzer geändert oder die Benutzerkonten deaktiviert werden, um die Ausbreitung unmittelbar einzudämmen.
  • Führen Sie eine doppelte KRBTGT-Domänenpasswortänderung durch.

 

 

 

Rootkit ermöglicht Remotezugriff per TCP-Verbindung

Rootkit ermöglicht Remotezugriff per TCP-Verbindung

Rootkit ermöglicht Remotezugriff per TCP-Verbindung

Im Certified Security Operations Center (CSOC) wurde kürzlich ein Angriffsversuch mit der Meldung ‚ET MALWARE Hacker Defender Root Kit Remote Connection Attempt Detected‘ identifiziert und untersucht. Über die gesetzten TCP-Flags war ersichtlich, dass eine Verbindung aufgebaut wurde und eine Datenübertragung stattgefunden hatte. Die Nachverfolgung der IP-Adresse des Quellsystems ergab, dass ein Angreifer versucht hatte, mithilfe eines Hacker Defender Rootkits auf ein internes System unseres Kunden zuzugreifen.

Das Hacker Defender Rootkit versetzt Cyberkriminelle in die Lage, jeden offenen TCP-Socket auf ein System zu verwenden, um einen Remotezugriff zu erzielen. Dafür hackt sich das Rootkit in Socket Operationen ein. Wenn in der Folge ein spezifisches TCP-Paket empfangen wird, arrangiert das Hacker Defender Root Kit einen Zugriff mit dem Remote-User. Somit können unsichtbare Hintertüren zu einem System erstellt werden, um ein Gerät fernzusteuern. Das Gefährliche hierbei ist, dass das kompromittierte System die aufgebaute TCP-Verbindung nicht erfasst. Da es sich effektiv vor allen Antivirenprogrammen verbergen kann und leicht zu modifizieren ist, ist es sehr schwierig ein Rootkit zu erkennen

Unser Kunde hatte Glück im Unglück: Er wurde durch unser Blue-Team informiert, sodass die IP des Angreifers in der Firewall rechtzeitig gesperrt werden konnte.

Unsere Handlungsempfehlungen:

  • Vermeiden Sie verdächtige Seiten und öffnen Sie keine unsicheren Links und Anhänge von E-Mails unbekannter Absender.
  • Führen Sie regelmäßig Systemupdates durch.
  • Verwenden Sie einen Rootkit-Scanner.
  • Führen Sie in kleinen Abständen Penetrationstests und Sicherheitstests durch.
  • Versuchen Sie, duale Authentifizierungssysteme zu verwenden.
  • Nutzen Sie IPSec für die Verschlüsselung und die Integrität.
  • Schränken Sie die Reichweite des Remotedesktop-TCP-Ports ein.
  • Unterbinden Sie administrative Anmeldungen per Remotedesktop mittels RDP-ACLs.

 

Datenlecks durch öffentliche SSH-Keys

Datenlecks durch öffentliche SSH-Keys

Datenlecks durch öffentliche SSH-Keys

SSH wird häufig von Systemadministratoren zur Fernsteuerung von Systemen über die Shell-Befehlszeile verwendet. Doch SSH birgt auch Gefahren und unbekannte Schwachstellen. Im folgenden Beitrag möchten wir Ihnen diese gerne vorstellen:

Unsere Leitstelle wurde jüngst durch die ausgelöste Regel "SSH aus dem Internet (Secure Shell)" auf eine Sicherheitslücke aufmerksam. Die Regel "SSH aus dem Internet (Secure Shell)" erkennt Netzwerkereignisse, die auf die Verwendung von SSH-Verkehr aus dem Internet hinweisen. Diese im Vergleich kleinere Schwachstelle im SSH-Authentifizierungsprotokoll erscheint zwar zunächst harmlos, kann aber zu Offenlegungen der Infrastruktur eines Unternehmens führen. Im Folgenden möchten wir Ihnen erläutern warum:

Um eine ständige Eingabe von Passwörtern für den Zugang zu SSH-Servern zu vermeiden, nutzen Administratoren in der Regel sogenannte SSH-Keys. Die Verwendung dieser Schlüssel ist die gängigste Methode zur Identifizierung und Authentifizierung von Benutzern. Als Schutzmaßnahme werden stets ein öffentlicher und ein privater Schlüssel als Paar verwendet. Der öffentliche Schlüssel kann dabei jederzeit aus dem privaten Schlüssel wiederhergestellt werden, jedoch nicht umgekehrt. Öffentliche Schlüssel sind - wie der Begriff besagt - öffentlich und teilweise weit verbreitet. Private Schlüssel sind nur dem jeweiligen Besitzer zugeordnet und dürfen im Gegensatz zu öffentlichen Schlüsseln nicht weitergegeben werden.

Authorisierung von GitHub- oder Gitlab-Repositorys

Eine Besonderheit besteht bei der Authorisierung von GitHub- oder Gitlab-Repositorys. Hier werden genutzte öffentliche SSH-Schlüssel automatisch der Öffentlichkeit zugänglich gemacht. Um öffentliche Schlüssel eines bestimmten Benutzers zu erhalten, müssen Sie lediglich .keys an das Ende eines Benutzernamens anhängen (z. B. https://github.com/{username}.keys). Dies ist eine recht unbekannte Funktion von GitHub und Gitlab, die theoretisch jeden in die Lage versetzt, auf Millionen von öffentlichen Schlüsseln zuzugreifen. Grundsätzlich birgt dies noch keine Gefahr. Doch eine kritische Schwachstelle ermöglicht es, mithilfe des öffentlichen Schlüssels auf sensible Informationen zuzugreifen:

Private On-Premise-Gitlab-CE-Instanzen lassen es zu, einige gängige Benutzernamen durch Anwendung der Brute-Force-Methode zu ermitteln und die öffentlichen Schlüssel der vorhandenen Benutzer zu erhalten. Darüber hinaus können zusätzliche Informationen über Mitarbeiter einer bestimmten Entität eingesehen werden. Wenn der entsprechende SSH-Client eine Authentifizierungsanfrage an einen Server sendet, zählt er grundsätzlich alle seine öffentlichen Schlüssel auf, für die private Schlüssel existieren. Interessantes Detail: Man benötigt keinen privaten Schlüssel, um zu überprüfen, ob ein Server den Zugriff von einer bestimmten öffentlichen/privaten Schlüsselkombination zulässt. Sobald man also Zugriff auf einen öffentlichen Schlüssel hat, kann man überprüfen, ob ein Server den Zugriff für den angegebenen öffentlichen Schlüssel und ein Benutzernamenpaar zulässt.

Ein Angreifer kann auf diese Weise eine große Menge an öffentlichen Schlüsseln von GitHub abrufen und einen internetweiten Scan von SSH-Servern auf allen IPv4-Adressen der Infrastruktur eines Unternehmens durchführen. Cyberkriminelle können damit alle IP‘s innerhalb weniger Tage scannen.

Wenn Ihre Infrastruktur auf Standard-SSH-Ports läuft und Standard-SSH-Benutzernamen verwendet, kann dies folglich ein zusätzliches Ziel für gezielte Angriffe darstellen. Es droht der unberechtigte Zugriff auf Kunden- sowie personenbezogene Daten.

Unsere Handlungsempfehlungen:

  • SSH-Server sollten nur mit starken Sicherheitskontrollen dem Internet ausgesetzt sein, da diese Server häufig als Erstzugang oder Hintertürvektor für Angriffe ins Visier genommen werden.
  • Ziehen Sie den Einsatz einer Multi-Faktor-Authentifizierung in Erwägung.
  • Nutzen Sie stets aktuelle Systeme.
  • Schalten Sie Remote Root-Login aus.
  • Grundsätzlich sind die Daten auf einem eigenen Server, der getrennt vom Internet im eigenen lokalen Netz steht, besser aufgehoben als auf den Servern eines externen Anbieters wie GitHub. In Deutschland gehostete und vom eigenen Admin verwaltete Server sind zu favorisieren.