Bedrohungsanalyse

Rapid Risk Assessment

Threat-Informed Defense

KI-Security Assessment

SSDLC-Assessment (SAMMcentric)

Cloud-Security Assessment

IT-Security Workshop

Holistische IT-Security

Red Teaming

Open Source Intelligence (OSINT)

Phishing-Kampagnen

Webapplikation-Penetrationstest

IT-Infrastruktur-Penetrationstest

OT-Infrastruktur-Penetrationstest

Offensive IT-Security

Krisenmanagement

Incident Response

Digitale Beweismittelsicherung

Digitale Forensik

Wiederaufbau-Management

Notfall IT-Security

Blogartikel

Events

Wissen

Die Crew

Zertifikate

Netzwerke

Das sind wir

Zur codecentric AG

Alle Standorte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Principal IT-Security Consultant

HEISE ONLINE

IT-Security

Mit Threat-informed Defense gegen Sicherheitsbedrohungen

Timo Sablowski beleuchtet bei heise online, wie Threat-informed Defense effizient dabei hilft, sein Unternehmen gegen Sicherheitsbedrohungen zu verteidigen.

Im Rahmen eines Red-Team-Assessments bestand die Herausforderung darin, eigenen Code über eine DLL auszuführen. Der Grund für dieses Szenario lag im Einsatz einer „Application Allow Listing“-Software, die die Ausführung unbekannter Executables blockiert. Dabei wurden die üblichen Möglichkeiten zum Laden von DLLs, wie z.B. rundll32, vom Blue Team des Kunden stark überwacht, sodass wir uns nach anderen Optionen umsehen mussten.\nNach einigem Ausprobieren in unseren Labs und der Analyse des Verhaltens bestimmter Windows-Programme zur Laufzeit, stellte sich heraus, dass in einem aktuellen Windows 11 (Stand März 2025) einige Microsoft-eigene Programme eine Schwachstelle aufwiesen –  nämlich Relative Path DLL Hijacking.\nMithilfe eines kleinen Twists ermöglicht diese Schwachstelle es Angreifern, über vertrauenswürdige Anwendungen (Schad-)Code auszuführen und möglicherweise weitere Sicherheitsmechanismen wie Application Allow Listing oder gezieltes Monitoring zu umgehen.\nDieses Problem wurde am 21.02.2025 an Microsoft gemeldet und am 07.03.2025 als „keine Schwachstelle“ klassifiziert. Gerne zeigen wir euch dennoch in diesem Blogpost, wie ihr als Red Teamer Microsoft-Programme für das Nachladen von DLLs verwenden könnt.\nWas ist eigentlich Relative Path DLL Hijacking?\nRelative Path DLL Hijacking ist eine Schwachstelle, die auftritt, wenn eine Anwendung eine erforderliche DLL nicht über einen festen Pfad lädt, sondern die übliche Suchreihenfolge von Windows verwendet (siehe untenstehende Grafik). Bei dieser Reihenfolge kann ein Angreifer eine DLL mit dem gesuchten Namen in einem manipulierten, und für ihn beschreibbaren Verzeichnis platzieren. Wird die Anwendung gestartet, lädt sie die DLL und führt den darin enthaltenen Code mit den Rechten des betroffenen Programms aus. \nDie nachfolgende Grafik veranschaulicht die Suchreihenfolge für DLLs unter Windows. Dabei fällt auf, dass einige Suchpfade nicht nur von Administratoren, sondern auch von normalen Benutzern manipuliert werden können.\n\n\nBetroffene Windows-Komponenten\nEinige Komponenten aus dem System-Verzeichnis \nC:\Windows\System32\n sind für den beschriebenen Angriff anfällig, sofern ein kleiner Trick angewendet wird. Der Schlüssel dazu liegt in der DLL-Suchreihenfolge, speziell im Punkt „Pfad der Applikation“.  Dafür wird eine betroffene Komponente (z. B. calc.exe) aus dem System32-Ordner in einen anderen, für den Angreifer beschreibbaren Ordner kopiert:\ncopy C:\Windows\System32\calc.exe C:\Users\Public\\nMit dem Tool Process Monitor kann nun der Start des Prozesses im Detail analysiert werden. Die Filterung der Ereignisse hilft dabei, nur die wichtigen Informationen ausgeben zu lassen:\nPfade, die mit .dll enden, sollen in der Anzeige inkludiert werden\nErgebnisse von Ereignissen, bei denen eine Datei nicht gefunden wird, soll in der Anzeige inkludiert werden\nAlle Prozesse, die nicht calc.exe sind, sollen aus der Anzeige entfernt werden\n\n\nWie zu sehen ist, versucht die Anwendung calc.exe vergeblich, verschiedene DLLs aus dem Ordner zu laden, in dem sie ausgeführt
wurde.\n\n\nEin Angreifer könnte demnach eine DLL mit dem Namen Windows.Storage.dll erzeugen und im selben Verzeichnis ablegen, in dem calc.exe ausgeführt wird. Beim Start von calc.exe würde die manipulierte DLL geladen und der darin enthaltene Code ausgeführt. \nDer folgende Beispielcode öffnet beim Laden der DLL eine sog. Message Box mit dem Inhalt „Hijacked DLL …“:\n\n\nWird calc.exe nun gestartet und findet die DLL im selben Ordner, wird diese geladen und die Message Box geöffnet:\n\n\n\nWarum ist das Verhalten trotzdem ein Problem?\nIn diesem speziellen Fall müssen die betroffenen Programme zusammen mit der jeweils manipulierten DLL-Datei in einen Ordner platziert und ausgeführt werden. Das bedeutet, dass der Angreifer eine initiale Kontrolle über das System erlangt haben muss, oder eines der legitimen Programme zusammen mit seiner DLL über andere Wege verteilt. Für den Angreifer ist es von Vorteil, dass die betroffenen Applikationen durch Microsoft digital signiert sind und somit als vertrauenswürdig eingestuft werden. Das kann dazu führen, dass weitere Sicherheitsmechanismen umgangen werden. Einige Lösungen, wie Antivirus-Programme, EDR- und Allow-Listing-Tools, analysieren unter Umständen zunächst nur den ladenden Prozess. \nSomit bietet diese Schwachstelle Angreifern eine Alternative zu den sogenannten LOLBAS (Living Off The Land Binaries and Scripts). Hierbei handelt es sich um systemeigene Windows-Programme und Skripte, die von Angreifern in der Regel für versteckte Aktionen missbraucht werden. Da LOLBAS in der Regel intensiv durch Sicherheitslösungen überwacht werden und ein höheres Entdeckungsrisiko aufweisen, eröffnet das Relative Path DLL Hijacking in Windows-Programmen zusätzliche Möglichkeiten für Angreifer.\nZeitleiste der Responsible Disclosure\nDatum\nAktion\n20.02.2025\nEntdeckung der Schwachstelle in mehreren Programmen\n21.02.2025\nMeldung an Microsoft\n25.02.2025\nErstellung einer Case-Nummer durch Microsoft und interne Analyse\n07.03.2025\nKlassifikation als keine Schwachstelle\n12.03.2025\nBlog-Freigabe durch Microsoft\nWeiterführende Links\n\nhttps://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order\n\n\nhttps://learn.microsoft.com/en-us/sysinternals/downloads/procmon\n\n\nhttps://lolbas-project.github.io/\n\n


Relative Path DLL Hijacking in Windows-Programmen

Im März haben wir bereits einen Blogartikel über [Relative Path Hijacking in Windows](https://www.codecentric.de/wissens-hub/blog/relative-path-dll-hijacking-in-windows-programmen) veröffentlicht. Darin zeigen wir eine offene Schwachstelle in aktuellen Windows-Versionen auf, die es Angreifern ermöglicht, eigenen Code in DLL-Dateien über vertrauenswürdige Windows-Anwendungen auszuführen.

In diesem Blogartikel widmen wir uns dementsprechend fortführend mit potentiellen Erkennungsmöglichkeiten dieser Schwachstelle. 

Disclaimer: Als “Proof of Concept” wurde die Windows-Anwendung calc.exe verwendet, um maliziöse DLLs nachzuladen. Wir können hier von einer Kombination aus “Relative Path Hijacking” und “DLL Side-Loading” sprechen.

### Erkennung von DLL Hijacking unter Windows

Um einen solchen Angriff zu erkennen, gibt es mehrere Möglichkeiten:

1. Sysmon-Logs mithilfe eines SIEM  auswerten: Sysmon kann das Laden von DLLs überwachen und verdächtige Aktivitäten aufzeigen.
2. Prefetch-Dateien untersuchen: Windows speichert Informationen zu 
ausgeführten Programmen und deren geladenen DLLs in Prefetch-Dateien.

### Überprüfung mithilfe eines SIEM in Kombination mit Sysmon

Wir haben in unserem Lab eine Splunk-Instanz aufgesetzt und Sysmon für zusätzliche Sichtbarkeit installiert. Sysmon bietet den Vorteil, dass es bereits Erkennungen mitbringt und diese nur durch Splunk Searches dargestellt werden müssen.

Um [Sysmon](https://learn.microsoft.com/de-de/sysinternals/downloads/sysmon) zu installieren, wird die Anwendung von Microsoft aus den Sysinternals Suite heruntergeladen. Wichtig für die Installation ist eine Konfigurationsdatei. Eine Beispieldatei findet sich ebenfalls auf der [offiziellen Microsoft-Seite](https://learn.microsoft.com/de-de/sysinternals/downloads/sysmon).

Klar zu sehen ist, dass hier DLL Side-Loading erkannt wurde. Beim DLL Sideloading legen Angreifer eine manipulierte DLL in das Verzeichnis einer legitimen, vertrauenswürdigen Anwendung ab und starten diese gezielt (siehe eingangs erwähnten Blogpost). Die Anwendung lädt dann automatisch die schädliche DLL, weil sie diese erwartet. Der Angreifer muss also nicht auf den Start der Anwendung durch das Opfer warten, sondern kann die Payload direkt einbringen. Genau das ist zu Testzwecken passiert.

Sysmon erkennt diesen Ansatz und loggt das entsprechende Event. Zusätzlich wird auch das entsprechende TTP aus dem [MITRE ATT&CK Framework](https://attack.mitre.org/) referenziert. Mit einer simplen Splunk-Suche lässt sich gezielt nach solchen Events suchen und eine Alarmierung auslösen.

![splunk_dllhijacking.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma23ueda43tq07um1yd1vxbh)

![splunksearch_dllhijacking.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma23y3hm48s007umi4bmfikt)

### Überprüfung mittels Prefetch-Dateien

Liegt ein forensisches Image vor, kann DLL Hijacking ebenfalls durch Prefetch Dateien nachgewiesen werden. Prefetch-Dateien enthalten Informationen zu ausgeführten Programmen und deren geladenen DLLs. Diese befinden sich unter C:\Windows\Prefetch und lassen sich entweder mithilfe eines Textprogramms manuell analysieren oder durch für solche Fälle spezialisierte Tools. Für den hier vorliegenden Fall wurde [PECmd](https://github.com/EricZimmerman/PECmd) von Eric Zimmermann genutzt.

![Prefetch_Dllhijacking.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma23yp4r43f508ul35wblg78)

Voraussetzung hierzu ist, dass die entsprechend benutzte Windows-Anwendung bekannt ist.

### Verhinderung des Angriffspfads durch Application Allow Listing

Idealerweise sollte ein solcher Angriff nicht nur erkannt oder im Rahmen forensischer Analysen nachvollzogen, sondern bereits im Vorfeld zuverlässig blockiert werden. Auch wenn es sich wie in diesem Beispiel um eine vertrauenswürdige und signierte Microsoft-Applikationen handelt, kann ein konsequent umgesetztes Application Allow Listing solche Angriffswege effektiv unterbinden. Voraussetzung dafür ist, dass die eingesetzte Sicherheitslösung so konfiguriert ist, dass nicht nur ausführbare Dateien, sondern auch referenzierte DLLs ausschließlich dann geladen werden dürfen, wenn sie aus vertrauenswürdiger Quelle stammen und entsprechend signiert sind.
Eine praxistaugliche Möglichkeit zur Umsetzung dieser Schutzmaßnahme unter Windows bietet das kostenlose Tool Windows Defender Application Control (WDAC). Mit dem [App Control Policy Wizard](https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/wdac-wizard) lassen sich entsprechende Richtlinien schnell und benutzerfreundlich konfigurieren.

![Wizard.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma23z8xb49ym07um6hue3wen)

### Fazit

Die Erkennung von Relative Path DLL Hijacking erfordert eine Kombination aus Log-Analyse, Speicherprüfung und Dateiüberwachung. Mit Tools wie Sysmon, Splunk und Prefetch-Analyse lassen sich verdächtige Aktivitäten effizient aufspüren. Ein regelmäßiges Monitoring, das Absichern der Suchpfade, sowie Application Allow Listing, können helfen, Angriffe zu verhindern.

DLL Hijacking erkennen und verhindern

Ransomware kann für Unternehmen zum Stresstest werden: Daten und Systeme, mit denen man täglich arbeitet, sind nicht mehr verfügbar und werden nur gegen die Bezahlung hoher Summen wieder freigegeben. Umso schlimmer ist es, wenn die Backups ebenfalls von der Verschlüsselung betroffen sind oder gar für bestimmte Bereiche der IT-Infrastruktur gar nicht erst angefertigt wurden.\nSo kommt es immer wieder vor, dass nicht nur die Dateien auf Arbeitsplatz-Rechnern, Servern und Fileshares verschlüsselt, sondern auch die Hypervisoren wie Hyper-V oder ESX-Server übernommen werden. Dabei werden die dort vorliegenden virtuellen Festplatten (z. B. in Form von vhdx- oder vmdk-Dateien) ebenfalls verschlüsselt, sodass die Server-Systeme gar nicht erst gestartet werden können.\nDiese Dateien sind mitunter sehr groß und eine Vollverschlüsselung der virtuellen Festplatten kann sehr viel Zeit in Anspruch nehmen. Je länger die Verschlüsselung dauert, desto eher kann das Opfer diese erkennen und Gegenmaßnahmen treffen. Deshalb wird bei großen Dateien nicht immer alles, sondern nur der Dateianfang und das Dateiende verschlüsselt. Das reicht in den meisten Fällen aus, um die Datei unbrauchbar zu machen: Virtuelle Maschinen lassen sich so nicht mehr starten oder in anderen Systemen mounten. Für klassische Recovery-Strategien sieht es dann düster aus, wenn die Backups auch nicht mehr funktionieren.\nUnd genau so einen Fall hatten wir bei einem Kunden im Rahmen eines DFIR-Einsatzes!\nWir müssen an die unternehmenskritischen Daten\nUm den Betrieb wieder aufnehmen zu können, mussten zwingend unternehmenskritische Daten eines dedizierten Systems wiederhergestellt werden. Doch diese befanden sich auf einem System, was über den Zugriff der Angreifer auf den Hypervisor verschlüsselt wurde. Ein Mounten der virtuellen Festplatte war leider unmöglich, doch wir konnten nach einer kurzen Analyse erkennen, dass nicht die gesamte Festplatte, sondern nur ein Teil (Anfang und Ende) der Festplatte verschlüsselt war. Zwar ist das Dateisystem mit Informationen wie Dateinamen, Dateigrößen, oder Struktur nicht mehr nutzbar, aber mit ein bisschen Glück kann man über sogenanntes File Carving an die Rohdaten der Festplatte.\nFile Carving\nFile Carving ist eine forensische Methode zur Wiederherstellung von Dateien, bei der ein intaktes Dateisystem nicht zwingend notwendig ist. Stattdessen werden dabei die Rohdaten auf einem Speichermedium auf bekannte Dateistrukturen anhand definierter Muster - wie Header (Dateianfang) und Footer (Dateiende) - analysiert. Wenn der Anfang von einer Festplatte betroffen ist, sind meist auch die Partitionstabellen und die Dateisystem-Metadaten nicht mehr lesbar. Das führt dazu, dass Betriebssysteme oder klassische Wiederherstellungssoftware keine Informationen mehr darüber haben, welche Dateien vorhanden waren, wo sie gespeichert wurden oder wie groß diese waren. File Carving kann Fragmente von Dateien extrahieren, indem es direkt in den Rohdaten nach Dateisignaturen sucht. Beim klassischen File Carving werden die sogenannten Header und Footer gesuchter Dateitypen identifiziert. Anschließend wird manuell oder vorwiegend automatisiert eine Suche nach dem Header dieses Dateityps gestartet. Wird dieser gefunden, findet eine Prüfung statt, ob in den nachfolgenden Fragmenten der Footer des Dateityps identifiziert werden kann. Fragmente, die sich zwischen Header und Footer befinden, werden als Dateiinhalte klassifiziert und inklusive Header/Footer exportiert.\n\nDiese Methode hat allerdings auch ihre Grenzen. Insbesondere dann, wenn die gesuchten Dateien kein eindeutiges Ende haben.\nWährend viele Formate klar definierte Header und Footer verfügen, die Anfang und Ende der Datei markieren, fehlt diese Struktur bei anderen, wie z. B. bei Datenbanken, Rohdaten oder proprietären Formaten. In solchen Fällen ist es sehr schwierig bis unmöglich, exakt zu bestimmen, wo eine Datei aufhört. Das kann dazu führen, dass beim Carving entweder nur unvollständige Datenfragmente extrahiert oder dass versehentlich benachbarte Datenbereiche mitgelesen werden, die zu anderen Dateien gehören. Das Resultat sind beschädigte oder vermischte Dateien, deren inhaltliche Integrität nicht mehr gewährleistet werden kann. Die Interpretation der wiederhergestellten Inhalte erfordert dann Erfahrung im Umgang mit den spezifischen Dateiformaten, um relevante Informationen korrekt zu identifizieren und voneinander abzugrenzen.\nFile Carving lässt sich mit diversen Werkzeugen - von professionellen kommerziellen Tools bis hin zu kostenfreien und dennoch gut funktionieren Open-Source-Programmen - umsetzen.\nEine Variante ist die Verwendung des Open-Source-Tools foremost.\nBenutzung von foremost\nMöchte man Dateien aus einem defekten oder verschlüsselten Image extrahieren, ist es am einfachsten, wenn man sowohl den Datei-Header als auch den Footer kennt. Im folgenden Beispiel wird versucht, aus einem Image verloren gegangene xcf-Dateien des Open-Source-Bildbearbeitungsprogramms GIMP wiederherzustellen. Leider bietet foremost per Standardkonfiguration keine Möglichkeit der Extraktion von xcf-Dateien an. Daher ist es empfehlenswert, sich vorher Referenzdateien anzusehen. Hierbei wird überprüft, ob die Anfänge von fünf Referenzdateien dasselbe Muster aufweisen:\n\nEs scheint, dass alle Dateien mit derselben Zeichenfolge beginnen. Daher wird in diesem Beispiel der folgende Header (”gimp xcf”) definiert:\n\x67\x69\x6d\x70\x20\x78\x63\x66\nDasselbe Verfahren wird nun für das Dateiende genutzt. Nicht alle Dateitypen haben ein fest definiertes Ende. Anhand der Referenzdateien kann überprüft werden, ob dies hier der Fall sein könnte:\n\nDie Dateienden sind nicht unbedingt eindeutig, scheinen aber grundsätzlich mit vier Nullbytes abzuschließen:\n\x00\x00\x00\x00\nMit diesen Informationen kann nun eine neue Zeile in der Konfigurationsdatei von foremost (\n/etc/foremost.conf\n) eingetragen werden:\n\nDabei wird Folgendes definiert:\nDateiendung, mit der die wiederhergestellten Dateien benannt werden sollen\nBeachtung der Groß- und Kleinschreibung von gesuchten Dateiinhalten (in diesem Fall nein)\nMaximale Dateigröße (hier 5 MB)\nDatei-Header\nDatei-Footer\nAnschließend kann foremost mit den Parametern -o (Ablageort für wiederhergestellte Dateien) und -i (zu nutzendes Image) gestartet werden:\nforemost -o recovered -i image.img\nDer Test zeigt, dass foremost mit der gesetzten Konfiguration in der Lage war, mehrere xcf-Dateien wiederherzustellen.\n\n\n\nFile Carving im konkreten Ransomware-Fall\nWas im Beispiel für die xcf-Dateien so einfach aussah, hat sich im konkreten Fall beim Kunden als wesentlich schwieriger herausgestellt. Die dringend benötigten Daten hatten keinen eindeutigen Datei-Footer und sowohl die Header als auch die Dateiinhalte der unterschiedlichen Dateitypen wiesen sehr starke Ähnlichkeiten auf. Dadurch ergaben sich folgende Probleme:\nBeim File Carving würden zwangsläufig unsaubere Dateien entstehen\nDie Dateien lassen sich nicht während des Carvings eindeutig voneinander unterscheiden\nUm die Probleme anzugehen, haben wir uns vom Kunden mehrere Referenzdateien der unterschiedlichen Dateitypen zur Analyse geben lassen. Dadurch konnten wir zumindest schon einmal eine maximale Dateigröße mit ein wenig Puffer definieren. Um die Dateien zu carven, konnten wir uns nur am Datei-Header orientieren. Dieser war bei allen Dateitypen sehr ähnlich, weshalb wir in der Konfiguration unseres Carving-Tools nur einen Bruchteil des Headers genommen haben, um “möglichst grob” erst einmal alles aus dem Dateisystem herauszuholen.\nAls Ergebnis hatten wir hunderte Dateien mit mehreren Gigabytes an Gesamtgröße. Um die Dateien nun voneinander zu unterscheiden, mussten wir vermehrt auf den Inhalt der Dateien achten. Aufgrund der Datenmenge wäre eine manuelle Überprüfung nicht effizient gewesen. Daher haben wir uns dazu entschlossen, für die unterschiedlichen Dateitypen YARA-Regeln zu schreiben, mit denen wir automatisiert die Inhalte durchsuchen und die Dateien nach Typ sortieren konnten.\nJedoch gab es das Problem, dass diese Dateien aufgrund ihrer unsauberen Wiederherstellung nicht ohne weiteres in die neu aufgesetzten Systeme importiert werden konnten. Nach einiger Recherche konnten wir ein Programm finden, was genau dieses Problem für uns gelöst hat. Der Kunde konnte die unsauberen Dateien in dieses Programm importieren, das Tool hat alles, was nichts mit den für das System wichtigen Daten zu tun hatte, ignoriert und konnte per Knopfdruck die relevanten Dateiinhalte sauber exportieren.\nDadurch war es möglich, unternehmenskritische Systeme trotz Ransomware wieder in den Betrieb zu nehmen und eine vorerst als notwendig erscheinende Zahlung der Erpressersumme abzuwenden.\nFazit\nIn diesem konkreten Fall hatten wir und der Kunde das Glück, dass große Teile der virtuellen Maschinen trotz Ransomware-Verschlüsselung noch intakte Daten enthielten. Durch das File Carving und zusätzliche freie Werkzeuge konnte ein unternehmenskritisches System wieder in Betrieb genommen und dem Kunden zumindest ein Teil seiner Arbeitsfähigkeit zurückgegeben werden.\nDennoch ist es wichtig, folgendes zu betonen: Solche Erfolge sind Ausnahmen und keine Garantie, mit dieser Methode immer erfolgreich sein zu können.\nEs ist für Unternehmen absolut wichtig, alle relevanten Systeme regelmäßig zu sichern und diese von der IT-Infrastruktur zu trennen. Hilfe für sichere Backup-Konzepte finden sich unter anderem beim BSI.\nWeiterführende Links\n\nhttps://foremost.sourceforge.net/\n\n\nhttps://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_3_Datensicherungskonzept_Edition_2023.pdf\n\n\nhttps://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Umsetzungshinweise/Umsetzungshinweise_2022/Umsetzungshinweis_zum_Baustein_CON_3_Datensicherungskonzept.pdf\n\n

Daten trotz Ransomware retten

Noch schnell patchen, bevor die Sommerpause kommt.\nWas ist der Patch Tuesday?\nDer Begriff bezeichnet den zweiten Dienstag im Monat, an dem Microsoft wichtige Patches für seine Systeme veröffentlicht. Durch den festen Rhythmus wird die Arbeit von Systemadministratoren und Nutzern erleichtert, da somit ein klarer Planungszeitpunkt zum Einspielen von Updates gegeben ist.\nDer Patch Tuesday bringt im Juni 2025 unter anderem wichtige Sicherheitsupdates von Microsoft und schließt damit mehrere Sicherheitslücken.\nSo wurden bei Microsoft fast 80 Sicherheitslücken geschlossen. Zu diesen zählen 13 Schwachstellen zur Erweiterung von Privilegien und 25 Optionen der sog. “Remote Code Execution” in mehreren Produkten wie Office oder SharePoint. Zwei geschlossene Schwachstellen (\nCVE-2025-33053\n, \nCVE-2025-33073\n) werden bereits aktiv von Angreifern ausgenutzt.\nAuch in Google Chrome, wurde in den letzten Tagen eine neue Version veröffentlicht, die die bereits von Angreifern ausgenutzte Sicherheitslücke \nCVE-2025-5419\n schließt.\nWeitere Hersteller, die Sicherheitsupdates herausgebracht haben, sind nachfolgend aufgelistet:\n\nCisco\n: Sicherheitsupdates für mehrere Produkte mit Schwachstellen, darunter eine “Remote Code Execution” und die Möglichkeit, Zugangsdaten aus Cisco ISE Cloud-Installationen zu extrahieren.\n\nIvanti\n: Sicherheitsupdates für mehrere Produkte.\n\nFortinet\n: Sicherheitsupdates für mehrere Produkte, einschließlich einem Fix für einen “Authentication Bypass”, sowie für eine “OS Command Injection”-Schwachstelle\n\nSAP\n: Behebung von 14 Schwachstellen, darunter eine kritische Lücke zur Erweiterung der Privilegien.

Patch Tuesday Juni 2025

As part of a Red Team assessment, a challenge arose to execute our own code via a DLL. The reason for this scenario was the use of Application Allow Listing software, which blocks the execution of unknown executables. The usual options for loading DLLs, such as rundll32, were heavily monitored by the customer's blue team, so we had to look for other options.\nAfter some trial and error in our labs and analyzing the behavior of certain Windows programs at runtime, it turned out that in a recent Windows 11 (as of March 2025),  some of Microsoft's own programs had a vulnerability - namely Relative Path DLL Hijacking.\nWith a little twist, this vulnerability allows attackers to run (malicious) code through trusted applications although security mechanism like application allow listing or monitoring might be in place.\nThis problem was reported to Microsoft on 21.02.2025 and categorized as "not a security vulnerability" on 07.03.2025. Nevertheless, we are happy to show you in this blog post how you, as a Red Teamer, can use Microsoft programs to load DLLs.\nWhat is Relative Path DLL Hijacking?\nRelative Path DLL Hijacking is a vulnerability that occurs when an application does not load a required DLL using a fixed path but instead uses the standard Windows search order (see graphic below). With this order, an attacker can place a DLL with the searched name in a manipulated directory that the attacker can write to. When the application starts, it loads the DLL and runs the code it contains with the rights of the affected program. \nThe following figure illustrates the search order for DLLs on Windows. Note that some search paths can be manipulated not only by administrators, but also by normal users.\n\n\nAffected Windows Components\nSome components from the system directory C:\Windows\System32 are vulnerable to the described attack if a little trick is used. The secret lies in the DLL search order, specifically in the "Application Path" entry.  To exploit the behavior, an affected component (e.g. calc.exe) is copied from the System32 folder to another folder that can be written to by the attacker:\ncopy C:\Windows\System32\calc.exe C:\Users\Public\\nThe Process Monitor tool can now be used to analyze the start of the process in detail. Filtering the events helps to show only the important information:\nPaths ending with .dll should be included in the output\nResults of events where a file is not found should be included in the output\nAll processes that are not calc.exe should be removed from the output\n\n\nAs you can see, calc.exe tries to load different DLLs from the folder in which it was executed.\n\n\nFor example, an adversary could create a DLL named Windows.Storage.dll and place it in the same directory where calc.exe is run. When calc.exe is started, the hijacked DLL would be loaded and the code it contains would be run. \nThe following sample code opens a message box that says "Hijacked DLL ..." when the DLL is loaded:\n\n\nIf calc.exe is now started and finds the DLL in the same folder, it is loaded and the message box is opened:\n\n\n\nWhy is this behavior still a problem?\nIn this particular case, the affected programs must be placed in a folder together with the malicious DLL and run. This means that the attacker must have taken initial control of the system or otherwise distributed one of the legitimate programs along with its DLL. To the attacker's advantage, the affected applications are digitally signed by Microsoft and are therefore considered trustworthy. This can lead to other security mechanisms being bypassed. Some solutions, such as antivirus software, EDR, and allow listing tools, may initially analyze only the loading process. \nThis vulnerability therefore offers attackers an alternative to the so-called LOLBAS (Living Off The Land Binaries and Scripts). These are native Windows programs and scripts that are usually misused by attackers for hidden actions. Since LOLBAS are usually intensively monitored by security solutions and have a higher risk of detection, relative path DLL hijacking in Windows programs opens up additional opportunities for attackers.\nTimeline of Responsible Disclosure\nDate\nAction\n20.02.2025\nVulnerability discovered in multiple programs\n21.02.2025\nNotification to Microsoft\n25.02.2025\nMicrosoft creates case number and conducts internal analysis\n07.03.2025\nClassified as not a security vulnerability\n12.03.2025\nApproval of blog post by Microsoft\nLinks to further information\n\nhttps://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order\n\n\nhttps://learn.microsoft.com/en-us/sysinternals/downloads/procmon\n\n\nhttps://lolbas-project.github.io/\n\n


Relative path DLL hijacking in Windows programs

Mit Threat-informed Defense gegen Sicherheitsbedrohungen verteidigen

Du hast Fragen oder möchtest dich zu deinen Herausforderungen austauschen? Gern – trag einfach deine Kontaktdaten ein.

Kontaktanfrage | Sales (IT-Security)

Sprich mich an

Möchtest du dich über Threat-Informed Defense austauschen?

Eine Peron mit Laptop, aus dem ein Dreieck mit drei Icons zum Thema Threat-Informed Defense kommt

LEISTUNGEN

Threat-Informed Defense: gezielte Sicherheitsstrategie

Holistic IT-Security

BLOG

codecentric Blog

Hier gibt's noch mehr spannende Infos von uns für euch

Security: Mit Threat-informed Defense gegen Sicherheitsbedrohungen verteidigen

Über uns

Aktuelles

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Mit Threat-informed Defense gegen Sicherheitsbedrohungen verteidigen

Aus dem Inhalt:

Hier gibt's noch mehr spannende Infos von uns für euch

Threat-Informed Defense: gezielte Sicherheitsstrategie

Holistic IT-Security

codecentric Blog