How to detect the modular RAT CSHARP-STREAMER

Summary

The malware known as CSHARP-STREAMER is a Remote Access Trojan (RAT) developed in .NET. It has been deployed in numerous attacks over the past few years. Reports have mentioned its deployment during attacks orchestrated by REvil. However, during our casework we were able to observe the threat actor behind the ransomware Metaencryptor using CSHARP-STREAMER. Based on our visibility we assume, that Metaencryptor shows a special interest in IT service providers.

Key Takeaways

  • HiSolutions successfully identified distinctive patterns within the CSHARP-STREAMER malware, aiding in the identification of specific malware samples.
  • We confirmed the modular structure of CSHARP-STREAMER. This customization could be driven by their business model, which might involve payment for specific features, or as a strategy to minimize the chances of detection and analysis.
  • The usage of the RAT has massively increased in Q3 2023.
  • HiSolutions is able to share extra detection rules to support the detection of components of the deployment kit.

Prevalence and Initial Analysis

Our investigation into the CSHARP-STREAMER malware was triggered by a ransomware incident that also included the deployment of „Metaencryptor“ ransomware. Throughout the forensic examination, HiSolutions identified a Powershell loader responsible for loading, decrypting, and executing the RAT. There is public documentation linking CSHARP-STREAMER with other campaigns beyond Metaencryptor.

  • Fortgale attributes the usage to REvil
  • Arista mentions usage in Operation White Stork
  • GDATA ADAN provided a public report, even though in their case, no further malware was deployed.
  • The DFIR-Report identified the RAT during an deployment of ALPHV-Ransomware.

The identified Powershell loader itself, especially the AMSI-Memory-Bypass and the XOR-decryption component, consists of publicly available proof-of-concepts, shared by several security researchers. The AMSI-Memory-Bypass is a perfect copy of a script posted on Github in August 2022. The security researcher “GetRektBoy724” originally published the XOR-decryption part in 2021.

As mentioned above, GDATA ADAN had already published a report regarding the CSHARP-STREAMER toolchain, also mentioning the re-use of code, available in the public domain. The feature-set of the CSHARP-STREAMER malware in our case differs from the sample GDATA ADAN was able to analyze. „Their“ sample came with a MegaUpload client and with ICMP for C2-Communication, whereas the sample analyzed by us came without a MegaUpload client and without ICMP for C2-Communication.

We can confirm the usage of the RAT’s TCP relay functionality. Using this feature, the threat actors were able to move from one network to another more carefully protected network.

The usage of the TCP function leaves some traces, providing opportunities for forensic investigation: This leads to visible traces in Windows Eventlogs in the form of EventID 2004 and the creation of a distinct firewall rule by "C:\\Windows\System32\netsh.exe": "Inbound TCP Port 6667". This behaviour (creation of firewall rule via netsh) is already covered by a publicly available SIGMA-rule, written by Michel de Crevoisier. The threat actors used the feature not on a large scale, but only in situations, where they had to close a gap between different parts of the affected organizations network.

In total, we were able to identify the following modules in the sample initially identified by us:

  • ADUtils
  • ExecuteAssembly
  • Filetree
  • HttpServer
  • Keylogger
  • LineParser
  • PsExec
  • Relay
  • RunAs
  • Sendfile
  • Sget
  • SmbLogin
  • Wget
  • Spawn

During the attack, Metaencryptor immediately used the Relay-Feature on specific machines and enumerated the users of the domain with Windows Powershell scripts instead of using CSHARP-STREAMER’s comprehensive toolset. The reconstructed process-tree confirmed that the attacker used the RAT mainly for running a diverse set of Powershell scripts.


Evolution of Malware

The fact, that our sample differed from the one GDATA ADAN analyzed, led us the the assumption, that CSHARP-STREAMER is modularized and assemblied for a specific use case. The reasoning behind that is unclear, but two explanations come to mind: CSHARP-STREAMER might be a malware-as-a-service, where customers have to pay per feature. Another possible explanation is, that the malware authors wanted to reduce the possibility of analysis and detection, by reducing the detection and analysis possibilities. We were not able to rule out either of the options. Since we wanted to gain a more complete overview of the overall capability of CSHARP-STREAMER we tried to find further samples, to get a more comprehensive overview.

To our knowledge, first in the wild samples of the malware surfaced in the second half of 2020. From our point of view, these are propably early development version of CSHARP-STREAMER. Some of these samples contain pdb-paths. The „csharp_streamer.Relay“-Library differs codewise from the main „csharp_streamer“-Library by incorporating Chinese strings. While earlier samples from 2019 contain a PDB-Path and are declared as Version 1.0.0.0, actual samples contain ascending Version-Numbers (2.10.8515.16637 – 2.10.8700.7258).

The analysis of samples shows that there are two main different configurations of CSHARP-STREAMER used in the wild, one with the MegaUpload-Client and one without. While we couldn’t identify samples from the year 2022, we are confident that CSHARP-STREAMER was also in active use during this timeperiod.

The observed uptick of the RATs usage in August 2023 also marks the beginning of Metaencryptor‘s publishing of victims (12 in August, 1 in September, 2 in November, 1 in December) and LostTrusts trove of 53 victims in August.

As mentioned by Fortgale the RAT has also been used in 2021 by REvil/GoldSouthfield and by an unknown Threat-Actor in Summer 2022 accordingly to Arista. While we can see an overlap in TTPs with Arista‘s report in our case (similar staging-directories and tooling) we are not confident in attributing both attacks to the same threat actor. The switch in TTPs in the incident handled by us suggests the work of an inital access-broker which gave MetaEncryptor access to the environment. The compilation timestamp of GData‘s samples also correlates with the occurence of new C2-Infrastructure in early 2023. In combination with the utilization of the RAT by multiple actors and in at least three (Mega, Mega + ICMP, Basic) different configurations, we expect that the malware is provided as a service to ransomware groups. The recent publishing of „The DFIR-Report“ identifies the RAT during an attack of ALPHV.


Detection and Response

Early development-samples contain the PDB-path „D:\Devel\csharp-streamer\csharp-streamer\obj\Release\csharp-streamer.pdb“. Additionally, the malware contains some specific strings with typos, like „ListRalays“ which can aid in detection.

Thus, we can provide a Yara-Rule, helping with the identification of known samples. Please note, that in cases known to us, the sample was loaded only in memory, not on disk.

Additionally detection mechanisms involve:

  • PowershellScriptBlock-Logging
  • The creation of firewall-rules by netsh.exe
  • Multiple static strings which can be found in memory
  • The use of CSHARP-STREAMER‘s user agentwebsocket-sharp/1.0
  • Specific Web-Requests (see headers below)

TTP and Detection Rules

The following rules are shared as TLP:CLEAR.

Yara Rule

rule CSHARP_STREAMER {
   meta:
      description = "Detects decrypted csharp_streamer"
      author = "HiSolutions AG"
      reference = "https://malpedia.caad.fkie.fraunhofer.de/details/win.csharpstreamer"
      sharing = "TLP:CLEAR"
      date = "2023-12-18"
      score = 100
   strings:
              $y1 = "csharp_streamer.Properties"
              $y2 = "csharp_streamer.Utils"
              $y3 = "csharp_streamer.ms17_10"
              $y4 = "csharp-streamer"
              $z1 = "iphlpapi.dll" ascii wide
              $z2 = "\\<title\\b[^>]*\\>\\s*(?<Title>[\\s\\S]*?)\\</title\\>" ascii wide
              $z3 = "MagicConstants.kSessionTerminate = ByteString.CopyFrom" ascii wide
              $z4 = "StartRalay"
              $d1 = "csharp-streamer.pdb"
   condition:
              uint16(0) == 0x5a4d and (3 of ($y*) or all of ($z*) or $d1)
}

SIGMA Rule

title: Potential csharp_streamer Powershell-Loader
id: 77bdea07-634c-49ad-96d3-03736882b914
status: test
description: Detects Powershell-Loader as seen with csharp_streamer.
references:
    - none
author: HiSolutions AG
date: 2023/12/18
tags:
    - tlp.white
    - attack.t1562.001
    - attack.t1059.001
logsource:
    product: windows
    category: ps_script
    definition: 'Requirements: Script Block Logging must be enabled'
detection:
    ps_script:
        EventID: 4104
        Channel:
            - Microsoft-Windows-PowerShell/Operational
            - PowerShellCore/Operational
    selection:
        ScriptBlockText|contains:
            - '[WinApi]::VirtualProtect($funcAddr, [uint32]$patch.Length, 0x40, [ref] $out)'
            - '$wc = New-Object System.Net.WebClient; $wc.Proxy = [System.Net.GlobalProxySelection]::GetEmptyWebProxy();'
            - '$string = xor "$rawData" "decrypt" "'
            - 'if($metInfo.GetParameters().Length -eq 0) # If Assembly - VB, update params'
            - '-UseBasicParsing -UserAgent "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 (.NET CLR 3.5.30729)" ).Content'
            - '$amsiDll = [WinApi]::LoadLibrary("ams"+"i.dll")'
            - '$funcAddr = [WinApi]::GetProcAddress($amsiDll, "Ams"+"iScanB"+"uffer")'
    condition: ps_script and selection
falsepositives:
    - Unknown
level: high
ruletype: Sigma

Malware related MITRE ATT&CK Techniques

IDTechniqueUsage
T1016System Network Configuration DiscoveryThe malware enumerates the network configuration of infected hosts.
T1018Remote System DiscoveryThe malware queries LDAP to discover additional systems.
T1021.002Remote Services: SMB/Windows Admin SharesThe malware uses an PsExec-implementation to support lateral movement.
T1046Network Service DiscoveryThe malware implements port-scanning-capabilities and contains descriptions for multiple ports.
T1056.001Input Capture: KeyloggingThe malware offers keylogging functionality
T1083File and Directory DiscoveryThe malware can create filetrees on infected systems. It also contains an extensivedictionary of strings to classify found files (e.g. network architecture, finance, passwords).
T1090.001Proxy: Internal ProxyThe malware has dedicated port-relaying capabilities
T1095Non-Application Layer ProtocolThe malware supports C2-communication via ICMP.
T1110.001Brute Force: Password GuessingThe malware has an integrated function that supports bruteforcing credentials for smb-access.
T1113Screen CaptureThe malware can capture screenshots.
T1134.001Access Token Manipulation: Token Impersonation/TheftThe malware supports token impersonation.
T1134.002Access Token Manipulation: Create Process with TokenThe malware offers the ability to launch processes in different contexts.
T1562.001Impair Defenses: Disable or Modify ToolsThe malware patches the in-memory amsi.dll before executiong PowerShell-Commands
T1567Exfiltration Over Web ServiceThe malware allows data exfiltration via https.
T1567.002Exfiltration Over Web Service: Exfiltration to Cloud StorageThe malware allows direct file exfiltration to Mega.io.
T1620Reflective Code LoadingThe malware allows to execute Code from URLs, remote and local files directly in memory.
TTP related to CSHARP-Streamer Malware

Threat Actor (TA) related MITRE ATT&CK Techniques

IDTechniqueUsage
T1018Remote System DiscoveryThe TA queries the AD-Environment for computers via a Powershell-Script using „adsisearcher[1].
T1021.002Remote Service (SMB/Windows Admin Shares)The TA uses „PSExec[2] to execute commands on remote systems via a Powershell-Script.
T1033System Owner / User DiscoveryThe TA queries the AD-Environment and uses LDAP for User-Discovery via a Powershell-Script using „adsisearcher“.
T1046Network Service DiscoveryThe TA queries the AD-Environment for SPNs via a Powershell-Script.
T1082System Information DiscoveryThe TA queries the AD-Environment for the operating system and system version via a Powershell-Script.
T1083File and Directory DiscoveryThe TA lists files in multiple directories and searches actively for KeePass-Configuration-Files.
T1087.001Account Discovery (Local)The TA uses „net user“ to enumerate local users on each computer via a Powershell-Script.
T1087.002Account Discovery (Domain)The TA uses „net user“ and „adsisearcher“ to enumerate domain users on each computer via a Powershell-Script.
T1087.003Account Discovery (Mail)The TA uses „adsisearcher“ to enumerate mail users on each computer via a Powershell-Script.
T1217Browser Information DiscoveryThe TA uses NirSoft’s „Browser History View“[3] to view the History of Internet Explorer, Firefox, Chrome and Safari via a Powershell-Script.
T1482Domain Trust DiscoveryThe TA queries the AD-Environment for all trust-relationships via a Powershell-Script.
T1485Data DestructionThe TA uses „format“ to format secondary partitions via „PSExec“.
T1486Data Encrypt for ImpactThe TA encrypts virtual machines on the hypervisor-level. Local files are encrypted through the use of ransomware deployed via „PSExec“.
T1497.001Virtualization/Sandbox Evasion (Systemchecks)The TA checks the host environment via the bios serialnumber and manufacturer of the computer via a Powershell-Script.
T1518Software DiscoveryThe TA lists all .lnk files in the Windows\Start Menu Folder and analyzes the Windows\Prefetch Folder for executed and installed Applications via a Powershell-Script.
T1558.003Steal or Forge Kerberos-Tickets (Kerberoasting)The TA uses „PowerView“[4] from the „PowerSploit“-Framework to aquire Tickets and converts them for later usage via a Powershell-Script.
T1569.002System Services (Service Execution)The TA uses „PSExec“ to execute commands on remote systems via a Powershell-Script.
T1614System Location DiscoveryThe TA queries the AD-Environment for department and physical delivery location of computers via a Powershell-Script.
T1619Cloud Storage Object DiscoveryThe TA lists all Files in the main folderpath of „OneDrive“ and „Dropbox“ and their first subdirectory-level via a Powershell-Script.
TTP related to MetaEncryptor threat actor using CSHARP-Streamer

Wie ITSM die NIS2 Compliance unterstützt 

Mit der Einführung der NIS2-Richtlinie, die eine Umsetzung in nationales Recht bis zum 18.10.2024 vorsieht, werden Unternehmen dazu verpflichtet, angemessene Maßnahmen zur Gewährleistung der Cybersicherheit zu ergreifen. Im Rahmen des IT Service Managements (ITSM) sind verschiedene Aspekte von NIS2 von Bedeutung, um die Compliance sicherzustellen und die Cybersicherheit zu stärken. 

Die Umsetzung der EU-Richtlinie in deutsches Recht wird aktuell immer weiter verschoben. Im aktuell öffentlichen Entwurf des deutschen NIS2-Umsetzungsgesetzes steht zwar weiterhin der 01.10.2024 als Beginn der Umsetzungspflicht, aber aktuelle Gerüchte weisen darauf hin, dass die Verabschiedung des Gesetzes sich auch über dieses Datum hinaus verzögern könnte.  

Über drei Jahrzehnte Erfahrung von HiSolutions in der IT-Management- und Informationssicherheitsberatung zeigen, dass die in NIS2 geforderten Maßnahmen und deren wirksame Umsetzung sehr zeitaufwändig sein können. Unsere Empfehlung bleibt deshalb, sofort auf Basis der bereits jetzt verfügbaren Informationen wie den jetzigen EU-Vorgaben, dem aktuellen Entwurf des deutschen Umsetzungsgesetzes sowie gängigen Standards und BSI-Vorgaben zu handeln. 


Mit diesem Übersichtsartikel bauen wir einen Leitfaden auf. Dieser soll auch Unternehmen, die zum ersten Mal regulatorisch erfasst werden, eine Einführung in die Best Practices im IT Service Management bieten. Zukünftige Artikel zur Vertiefung behandeln folgende NIS2-relevante Handlungsfelder: 

  1. Behandlung von Sicherheitsvorfällen 

Unternehmen müssen Prozesse zur Erkennung, Meldung und Behandlung von Sicherheitsvorfällen implementieren. NIS2 legt fest, dass Organisationen Sicherheitsvorfälle innerhalb bestimmter Fristen melden und angemessene Maßnahmen zur Eindämmung und Behebung ergreifen müssen. Daher müssen Unternehmen entsprechende Incident Management Prozesse etablieren, um Sicherheitsvorfälle effektiv zu bearbeiten und die Auswirkungen auf ihre IT-Dienste zu minimieren.  

Aus Sicht des IT-Service Managements sind hier der Service Desk, bei dem Endanwender mit Meldungen zu Sicherheitsvorfällen ankommen, der Incident Management Prozess, der eng mit dem Security Incident Prozess verzahnt sein sollte sowie die Maßnahmen rund um das Logging und Monitoring von Systemen involviert. 

  1. Business Continuity 

NIS2 fordert von Unternehmen die Entwicklung von Business-Continuity-Plänen, um die Verfügbarkeit kritischer Dienste auch während und nach Sicherheitsvorfällen sicherzustellen. Im IT Service Management werden aus dem Business Continuity Management (BCM) die entsprechenden IT Service Continuity Management (ITSCM) Maßnahmen abgeleitet. Das ITSCM ist wiederum eng mit dem Availability und dem Capacity Management verbunden. Um ein ITSCM effektiv zu gestalten, sind Grundlagen aus dem Service Configuration Management notwendig. 

  1. Auslagerungsmanagement 

Unternehmen, die kritische Dienste an externe Dienstleister auslagern, müssen sicherstellen, dass diese Dienstleister angemessene Sicherheitsmaßnahmen implementieren. NIS2 legt fest, dass Unternehmen die Verantwortung für die Sicherheit ihrer ausgelagerten Dienste nicht delegieren können. Im ITSM bedeutet dies, dass Unternehmen geeignete Mechanismen für das Auslagerungsmanagement etablieren müssen, um sicherzustellen, dass externe Dienstleister die Anforderungen an die Cybersicherheit erfüllen. Die entsprechenden Maßnahmen werden im Supplier sowie im Service Level Management definiert. 

  1. Security Awareness 

Die Sensibilisierung der Mitarbeiter für Cybersicherheit ist ein zentraler Bestandteil der NIS2-Compliance. Unternehmen müssen Schulungsprogramme zur Sicherheitsaufklärung durchführen, um das Bewusstsein und Verständnis für Sicherheitsrisiken zu fördern. Im ITSM ist es wichtig, Security Awareness Trainings in die laufenden Schulungsaktivitäten zu integrieren, um sicherzustellen, dass Mitarbeiter die Bedeutung von Cybersicherheit verstehen und entsprechend handeln. Dabei hat der Service Desk eine Nähe zu den Anwendern und das Relationship Management zu den Kunden, was für die Etablierung und Durchführung von Security Awareness Maßnahmen genutzt werden kann. 

  1. Risikoanalyse 

Eine kontinuierliche Risikoanalyse ist entscheidend für die Identifizierung und Bewertung von Sicherheitsrisiken gemäß den NIS2-Anforderungen. Unternehmen müssen Risikomanagementprozesse implementieren, um potenzielle Bedrohungen zu erkennen und geeignete Gegenmaßnahmen zu ergreifen. Im ITSM sollten Unternehmen regelmäßige Risikobewertungen durchführen und angemessene Sicherheitskontrollen implementieren, um Risiken zu minimieren und die Compliance sicherzustellen. Dies geschieht im Bereich Risk Management

  1. Übergreifende Practices 

NIS2 hat weitreichende Auswirkungen auf verschiedene Aspekte des ITSM und erfordert eine integrierte Herangehensweise an die Cybersicherheit. Dies geschieht durch die Best Practices im Information Security Management und wird durch das Infrastructure and Plattform Management gestützt. Unternehmen müssen sicherstellen, dass ihre ITSM-Prozesse und -Praktiken die Anforderungen von NIS2 erfüllen und eng mit anderen Compliance-Richtlinien und -Standards wie z. B. ISO 27001 abgestimmt sind. Durch eine ganzheitliche Herangehensweise können Unternehmen die Cybersicherheit stärken und die Einhaltung der Vorschriften im IT Asset/Deployment Management sicherstellen. Das dafür notwendige Change Management wiederum bezieht sich auf bewährte Prozesse und Methoden zur systematischen Planung, Steuerung und Umsetzung von Veränderungen in IT Systemen und Services. Ziel ist es, Änderungen kontrolliert und effektiv zu verwalten, um Risiken zu reduzieren und die Zuverlässigkeit der IT Services zu erhöhen. 

NIS kommt: Wir unterstützen Sie bei der Umsetzung. 
Der neue NIS2-Kompass von HiSolutions zeigt Ihnen in einer schnellen Selbstauskunft, ob Ihre Organisation von NIS2 betroffen ist und was Sie tun müssen.

Eine 10 von 10 – Ivanti CVE-2023‑35078 – Hilfe zur Selbsthilfe


Update vom 10.08.2023:

Für Ivanti Endpoint Manager Mobile (EPMM) wurde am 03.08.2023 eine weitere Schwachstelle (CVE‑2023-35082) mit einer CVSS-Bewertung von 10.0 veröffentlicht. Die Schwachstelle ist ähnlich zu der initial veröffentlichen CVE-2023-35078. Am 07.08.2023 hat Invanti veröffentlicht, dass diese Schwachstelle alle Versionen von EPMM betrifft. Die Maßnahmen zum Schließen der Schwachstelle und einer Identifizierung eines Angriffs wurden in dem Dokument „Hilfe zur Selbsthilfe – CVE‑2023‑35078“ ergänzt.


Update vom 01.08.2023:

Auf Basis der bereits veröffentlichten Expoits konnte der String zur Identifizierung eines Angriffs genauer bestimmt werden. Diese finden Sie in dem Dokument „Hilfe zur Selbsthilfe – CVE-2023 35078“ unter dem Punkt 2.


Update vom 31.07.2023:

Seit dem Wochenende gibt es die ersten öffentlichen Proof of Concept Exploits auf GitHub. Die teilweise in Python geschriebenen Programme ermöglichen eine automatische Ausnutzung der Ivanti Schwachstelle CVE-2023-35078.

Zusätzlich wurde am 28.07.2023 von Ivanti eine weitere Sicherheitslücke (CVE-2023-35081) publiziert. Hierbei handelt es sich um eine Schwachstelle welche es dem Angreifer erlaubt als authentifizierten Administrator beliebige Schreibvorgänge auf dem EPMM-Server durchzuführen.


Am 24. Juli 2023 hat der Hersteller Ivanti Informationen zu der Sicherheitslücke CVE-2023‑35078  veröffentlicht. Die Schwachstelle betrifft die Software „Ivanti Endpoint Manager Mobile“ (EPMM), auch bekannt als MobileIron Core. Um unseren Kunden eine Möglichkeit zu geben, erste Maßnahmen zu ergreifen und ihre Systeme zu prüfen, haben wir einen Leitfaden „Hilfe zur Selbsthilfe – CVE-2023‑35078“ erstellt. Der Leitfaden kombiniert die öffentlichen Informationen der staatlichen Sicherheitsbehörden, Fach-Blogs und die Angaben des Herstellers mit der Expertise der HiSolutions.

Sollten Sie Ivanti bzw. MobileIron Core nutzen, prüfen Sie bitte anhand des Dokuments, ob Sie alle relevanten Maßnahmen ergriffen haben.

HINWEIS: Das Dokument wird laufend aktualisiert. Bitte achten Sie daher auch auf weitere Veröffentlichungen auf unserem Research-Blog. Weitere Informationen und Cybersicherheitswarnungen erhalten Sie auch beim Bundesamt für Sicherheit in der Informationstechnik (BSI) unter https://www.bsi.bund.de/SiteGlobals/Forms/Suche/BSI/Sicherheitswarnungen/Sicherheitswarnungen_Formular.html


Log4Shell-Schwachstelle in Log4j: Überblick

Hilfe zur Selbsthilfe

Unsere aktuelle HiSolutions „Hilfe zur Selbsthilfe Log4Shell“ (v1.11 vom 05.01.2022 07:00) gibt es hier zum Download:

(Danke an das Team für die schnelle Arbeit – Inés Atug, Markus Drenger, Enno Ewers, Daniel Jedecke, Lisa Lobmeyer, Lena Morgenroth, Folker Schmidt, Volker Tanger, Manuel Atug.)

Go to English version

Changelog 

V1.11 (05.01.2022 07:00): CVE-2021-44832 (Arbitrary Code Execution) und Updatehinweis auf Version 2.17.1 ergänzt. Hinweis auf Ausnutzung ohne Nachladen von Schadcode entfernt. Scantools von AV-, Endpoint-Protection-, IDS- und Schwachstellenscanner-Herstellern ergänzt. Bekannte Angriffe ergänzt.

V1.10 (22.12.2021 09:00): Abgleich mit dem erweiterten BSI-Dokument (Stand 20.12.2021). Ergänzen der Gefährdungslage. Überarbeitung der Dokumentenstruktur. Löschung von Dopplungen. Ergänzen von Maßnahmenempfehlungen. Ergänzen bisher bekannter Angriffe (zum Ableiten möglicher IOCs).

V1.9 (20.12.2021 21:00): Expliziter Hinweis, dass generell alle Versionen vor 2.17.0 anfällig sind. Hinweis auf neue Schwachstelle in Version 2.16.0. Hinweis auf Prüfung in ICS-Umgebungen. Einbeziehung von Produkt-Herstellern und Dienstleistern konkretisiert.

V1.8 (15.12.2021 20:00): Verbesserung und Hinweise zu Überprüfung von Linux-Systemen per Kommandozeile.

V1.7 (15.12.2021 18:00): Verweis auf Angriffe mittels Ransomware hinzugefügt. Klarstellung zur Zielgruppe des Dokumentes eingefügt. Sprachliche Verbesserungen. Hinweis auf besseres Logging eingebaut. Hinweis auf CI/CD und Wiederherstellung von Backups eingefügt.

V1.6 (15.12.2021 12:00): CISA-Liste betroffener Produkte hinzugefügt. Hervorhebung der neuen Log4j 2.15.0 CVE-2021-45046 und des Defizits im ersten Patch. Prüfung via Konsole auf Linux-Systemen. Strukturiertes Vorgehen, um zu erkennen, ob Angreifer sich eingenistet und im Anschluss selber das System gepatcht haben. Verifikation der Behebung der Verwundbarkeit nach Patch. Datenschutzrelevantes Dokument vom BayLDA aufgenommen. BSI-Dokumente referenziert. Hinweis auf Feedbackmöglichkeit.

V1.5 (14.12.2021 15:00): Priorisierung und Liste aller Produkte. Wir haben eine Empfehlung zur Priorisierung hinzugeführt sowie eine Vorgehensweise der strukturierten Erfassung aller Produkte, die betroffen sind, und wie diese abgearbeitet werden kann.

V1.4 (14.12.2021 13:00): log4j v1.x mit CVE-2021-4104 adressiert. Ausnutzung der Schwachstellen seit 1.12.2021. Cloud Dienste hinzugefügt. Potentiell betroffene Systeme mit drei Merkmalen beschrieben. Intranet erläutert. Egress-Filter (ausgehender Datenverkehr) hinzugefügt. Hinweis auf Logfile-Sicherungen aufgrund der Angriffe seit 1.12.2021. Hinweis auf Aussage Hessischer Beauftragter für Datenschutz und Informationsfreiheit (HBDI), dass wegen Art. 33 DSGVO auf erfolgreiche Angriffe zu prüfen ist. 

V1.3 (13.12.2021 17:00): Erste veröffentlichte Version 

Beiträge zu Log4Shell/Log4j

  • Log4Shell: HiSolutions Self-Help Guide Log4j
    The following self-help guide contains HiSolutions‘ expert assessment, recommendations, IT procedures, and measures to cope with the ongoing Log4Shell cybersecurity incident and attack wave caused by a critical vulnerability in the Apache Log4j logging library. Special thanks to Lisa Lobmeyer for the English version.
  • Log4Shell-Schwachstelle in Log4j: Überblick
    Hilfe zur Selbsthilfe Unsere aktuelle HiSolutions „Hilfe zur Selbsthilfe Log4Shell“ (v1.11 vom 05.01.2022 07:00) gibt es hier zum Download: (Danke an das Team für die schnelle Arbeit – Inés Atug, Markus Drenger, Enno Ewers, Daniel Jedecke, Lisa Lobmeyer, Lena Morgenroth, Folker Schmidt, Volker Tanger, Manuel Atug.) Go to English version Changelog  V1.11 (05.01.2022 07:00): CVE-2021-44832 (Arbitrary Code Execution) und Updatehinweis auf Version 2.17.1 ergänzt. Hinweis auf Ausnutzung ohne Nachladen von Schadcode entfernt. Scantools von AV-, Endpoint-Protection-, IDS- und Schwachstellenscanner-Herstellern ergänzt. […]
  • Log4Shell: Massive Bedrohung durch Schwachstelle in Bibliothek Log4j
    Aktuell besteht eine IT-Sicherheitsbedrohung der höchsten Warnstufe: Durch eine Schwachstelle in der weitverbreiteten Java-Protokollierungsbibliothek Log4 sind sehr viele Systeme, Anwendungen und Applikationen (unvollständige, ständig wachsende Liste hier) anfällig für einen sehr einfach durchzuführende Remote Code Execution Angriff (RCE). Ein Vielzahl von Akteuren scannt bereits das Internet nach vulnerablen Instanzen, und erste Angreifer haben bereits begonnen, Backdoors auf Systemen zu installieren. Diese könnten später etwa für Ransomware-Angriffe missbraucht werden. Die Bibliothek ist dringend zu patchen – eine Herausforderung durch die vielen […]

Log4Shell: Massive Bedrohung durch Schwachstelle in Bibliothek Log4j

Aktuell besteht eine IT-Sicherheitsbedrohung der höchsten Warnstufe: Durch eine Schwachstelle in der weitverbreiteten Java-Protokollierungsbibliothek Log4 sind sehr viele Systeme, Anwendungen und Applikationen (unvollständige, ständig wachsende Liste hier) anfällig für einen sehr einfach durchzuführende Remote Code Execution Angriff (RCE).

Ein Vielzahl von Akteuren scannt bereits das Internet nach vulnerablen Instanzen, und erste Angreifer haben bereits begonnen, Backdoors auf Systemen zu installieren. Diese könnten später etwa für Ransomware-Angriffe missbraucht werden.

Die Bibliothek ist dringend zu patchen – eine Herausforderung durch die vielen Stellen, an denen Log4j zum Einsatz kommt. Häufig sind Anwender auch auf die Zuarbeit der Hersteller angewiesen. Dabei sind beileibe nicht nur direkt aus dem Internet erreichbare Systeme betroffen.

Der IT-Sicherheitsforscher Kevin Beaumont (@gossithedog) pflegt einen Twitter-Thread mit den neusten Entwicklungen und Tipps:

Hafnium Reloaded – Wieder kritische Schwachstellen in Microsoft Exchange

Und täglich grüßt das Murmeltier? Nicht ganz. Trotzdem erleben wir aktuell ein Déjà-vu mit Microsoft Exchange: Am 13.04.2021 19 Uhr MESZ wurden vier neue hochkritische Schwachstellen samt dazugehörigem Patch veröffentlicht.

Das BSI warnt bereits vor der Schwachstelle und fordert dazu auf, sehr zeitnah die eigenen Systeme zu patchen. Die Cybersecurity and Infrastructure Security Agency (CISA) des US Department of Homeland Security (DHS) geht sogar noch einen Schritt weiter und wird am Freitag, den 16.04.2021 alle nicht gepatchten Systeme aus dem eigenen Netzwerk ausschließen.

Bei den von der NSA an Microsoft gemeldeten Schwachstelle handelt es sich u. a. wieder um Remote-Code-Execution-Lücken mit einem sehr hohen CVSS Score von 9.8 (auf einer 10er-Skala). Hierbei kann, ähnlich wie bei Hafnium, ein entfernter Angreifer Code auf die Systeme einschleusen und diese ggf. übernehmen. Bei den Schwachstellen handelt es sich um die folgenden CVEs:

  • CVE-2021-28480 Microsoft Server Remote Code Execution Vulnerability
  • CVE-2021-28481 Microsoft Server Remote Code Execution Vulnerability
  • CVE-2021-28482 Microsoft Server Remote Code Execution Vulnerability
  • CVE-2021-28483 Microsoft Server Remote Code Execution Vulnerability

Patches stehen bereits für die folgenden Systeme zur Verfügung:

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU19 und CU20
  • Exchange Server 2019 CU8 und CU9

Das nicht mehr unterstützte Exchange Server 2010 soll diesmal nicht betroffen sein.

Die Schwachstellen werden aktuell anscheinend noch nicht ausgenutzt. Es dürfte aber nur eine Frage der Zeit sein, bis entsprechende Exploits zur Verfügung stehen . Daher sollten betroffene Exchange-Systeme noch heute gepatcht werden.

Wir empfehlen darüber hinaus weiterhin, Exchange-Umgebungen engmaschig zu kontrollieren.

Blitze-Wolke

HAFNIUM-Schwachstellen: Office 365/Microsoft 365/AD FS indirekt auch bedroht

[GTranslate]

Von Inés Atug, Markus Drenger und Daniel Jedecke.

Nach der Veröffentlichung des Out-of-Band-Patches für die als HAFNIUM bekannt gewordenen Schwachstellen in Exchange Servern haben viele Admins, die zuvor eine Migration nach Office 365 (jetzt Microsoft 365) durchgeführt hatten, aufgeatmet. Denn Microsoft zufolge ist Exchange Online von Hafnium nicht betroffen. Hiermit meint der Hersteller jedoch das Produkt an sich: Exchange Online ist weiterhin nicht direkt angreifbar. Aber Vorsicht: Es kann je nach Aufbau dennoch möglich sein, dass Angreifer auf den Cloud-Dienst durchgreifen können. 

In vielen Fällen ist in Unternehmen ein hybrider Aufbau etabliert, bei dem ein Exchange-Server weiterhin lokal betrieben wird. Sollte dieser Exchange-Server die HAFNIUM-Schwachstellen aufweisen, könnten Angreifer hierüber Zugriff auf das lokale Netzwerk erhalten (siehe Abbildung Schritt (1)) und sich dann über Lateral Movement im Netz weiterbewegen (Schritt (2)). Mittelbares Ziel des Angriffs ist in der Regel der Zugriff auf ein hochwertiges System wie beispielsweise das Active Directory oder die Active Directory Federation Services (AD FS) zu. Bei Zugriff auf letzteren können die Angreifer unter Umständen den geheimen Schlüssel entwenden (Schritt (3)), sich damit als jeder beliebige legitime Nutzer in der Cloud ausgeben (Schritt (4)) und somit Zugriff (lesen, verändern, löschen) auf alle in der Cloud gespeicherten Daten bekommen (Schritt (5)).

Angriff auf die Cloud/ADFS via HAFNIUM/ProxyLogon

Ob und wie leicht dies möglich ist, hängt stark davon ab, wie der lokale Aufbau umgesetzt ist. Wir erleben im Bereich der Forensik und Beratung hier gute wie auch ungünstige Umsetzungen. Prinzipiell sollte das Ziel immer sein, Lateral Movement in der On-Premise-Umgebung wie auch in der Cloud zu minimieren. Hierfür gibt es bewährte Verfahren, welche sich bei geeigneter Konfiguration dazu eignen, die Bewegungen der Angreifer im Netz zu erschweren:

  • Frühzeitiges Patchen von Sicherheitslücken: Die wichtigste Maßnahme, die auch bei Hafnium eine Kompromittierung mit hoher Wahrscheinlichkeit unterbunden hätte, ist das schnelle Patchen der Systeme. Hier herrscht bisweilen noch der Irrglaube, dass kritische Sicherheitslücken innerhalb von 30 Tagen zu patchen seien. Dies wurde und wird teilweise sogar noch von IT-Sicherheitsstandards vorgeschlagen. Sicherheitslücken, die mittels Fernzugriff automatisiert und unauthentifiziert ausgenutzt werden können, so wie dies bei Hafnium der Fall ist, zeigen jedoch deutlich, dass hier möglichst innerhalb von Stunden anstatt Tagen gepatcht werden sollte.
  • Administrative Trennung von Active Directory und Exchange Server: Eine weitere Maßnahme, die lokal umgesetzt werden sollte, ist die administrative Trennung zwischen Active Directory und Exchange. Oft sind die Systeme über Jahre gewachsen und eng miteinander verbunden. So trennt die Angreifer nach erfolgreicher Kompromittierung oft nur ein Powershell Kommando von der AD-Übernahme. Hier ist es wichtig, die 2017 von Microsoft im Rahmen der Konferenzen Blue Hat und Black Hat vorgestellten Probleme zu mitigieren. Hierfür eignet sich Split-Permissions (https://docs.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help und https://docs.microsoft.com/de-de/exchange/permissions/split-permissions/configure-exchange-for-split-permissions?view=exchserver-2019). Eine weitere Maßnahme ist die Verwendung der Local Administrator Password Solution (LAPS) von Microsoft. Hierbei wird auf jedem Host ein separates Admin-Passwort gesetzt, um so das Springen nach einem erfolgreichen Angriff (beispielsweise mittels Pass-the-Hash-Angriffsarten) zu erschweren.
  • Umsetzen des Konzepts administrativer Zonen: Da AD FS das Sprungbrett in die Cloud Welt ist, sollte dieser Zugang besonders gesichert werden. Hierzu empfiehlt Microsoft seit längeren einen Aufbau, in dem verschiedene administrative Sicherheitszonen (engl. tiers) voneinander getrennt werden sollten. Ein entsprechend gesicherter Exchange Server würde hier in Zone 1 stehen und ein Active Directory in Zone 0. Ein Sprung zwischen diesen Zonen soll mit den umzusetzenden Maßnahmen stark erschwert werden. Für den AD FS empfiehlt Microsoft ebenfalls den Aufbau in der Zone 0 (https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/design/best-practices-for-secure-planning-and-deployment-of-ad-fs).
  • Multifaktorauthentifizierung: Sowohl in der Cloud als auch in der lokalen IT-Umgebung sollten administrative Zugriffe mittels starker Multifaktorauthentifizierung abgesichert werden.
  • Protokollierung und Monitoring: Damit ein unberechtigter Zugriff möglichst schnell bemerkt wird, sollte ein feinmaschiges Monitoring- und Protokollierungskonzept etabliert sein. Insbesondere in der Cloud-Umgebung gehört das Monitoring neben der Zugriffssteuerung zu den wichtigsten Sicherheitsmaßnahmen. 
  • Datenklassifizierung: Sollte es doch zu einem Einbruch gekommen sein und die Angreifer möchten Daten exportieren, dann sollte mittels der Datenklassifizierung Sicherheitsmaßnahmen greifen, die zumindest die als vertraulich oder streng vertraulich klassifizierten Daten außerhalb der Cloud und des Kundennetzwerks unlesbar darstellen. 
  • Datensicherung: Sollte es zu einem Einbruch gekommen sein und es werden die Daten mittels Ransomware verschlüsselt, dann sollte man auf eine unveränderbare extern gespeicherte Datensicherung zurückgreifen können.

Die obigen Ausführungen zeigen, dass ein ganzheitliches und aktuelles Sicherheitskonzept notwendig ist, um möglichen Sicherheitslücken umfassend entgegenzuwirken. Überprüfen Sie daher regelmäßig Ihre Sicherheitsmaßnahmen und passen Sie diese ggfs. an geänderte Anforderungen an. Insbesondere, wenn Sie lokale Dienste von außen erreichbar konfigurieren oder Cloud-Dienste mit der lokalen IT-Umgebung koppeln, sollten das Sicherheitskonzept überprüft und nachgeschärft werden. Sprechen Sie uns gerne dazu an!