Spätestens seit dem SolarWinds Angriff 2020 rückt die Software Supply Chain aufgrund der von Ihr ausgehenden direkten Gefährdung von Softwareprojekten innerhalb von Unternehmen immer mehr in den Fokus der IT-Sicherheit. Innerhalb der letzten Wochen zeigte sich erneut, wie anfällig zentrale Distributionsplattformen für Open-Source-Komponenten sind: Die Paketquelle NPM wurde gleich drei Mal kompromittiert – jeweils mit dem Ziel, Schadcode über weit verbreitete Bibliotheken in Entwicklungsumgebungen einzuschleusen.

Diese Angriffe verdeutlichen eindrücklich, dass selbst weit verbreitete Paketquellen wie NPM keine absolute Sicherheit bieten und sich zunehmend zu einem attraktives Angriffsziel innerhalb der Software-Lieferkette entwickeln. Neben den bekannteren und größeren Angriffen der letzten Wochen, S1ingularity und Shai-Hulud, wurden auch in einem unbekannteren, weiteren Angriff 18 Pakete mit mehreren Milliarden Downloads pro Woche mit einem Crypto-Trojaner infiziert. In diesem Blogbeitrag wird der Chalk & Debug genannte Angriff aus technischer Sicht erläutert.

Über eine sorgfältig verfasste Phishing E-Mail wurden Zugangsdaten des Entwicklers und Paket-Maintainers qix kompromittiert. Der so erhaltene Zugang zum Account des Entwicklers wurde am 08. September 2025 dazu genutzt, 18 verschiedene NPM-Pakete zu kompromittieren – eine umfängliche Auflistung dieser ist am Ende des Blogartikels zu finden. Unter den Paketen befanden sich unter anderem die Pakete chalk in Version 5.6.1 ebenso wie debug in Version 4.4.2. Von diesen beiden kompromittierten Paketen stammt auch der Name des Angriffs: Chalk & Debug. Die mit einer Crypto-Stealer Malware versehene Veröffentlichung der NPM Pakete wurden nach ungefähr zwei Stunden als bösartig erkannt und im Anschluss entfernt. Trotz der kurzen Zeit, in der diese Versionen der Pakete veröffentlicht waren, wurden diese zusammengerechnet über 2,5 Millionen Mal heruntergeladen (laut Qix). Ziel des Crypto Stealers war es, im Browser des Opfers ausgeführt zu werden und Transaktionen mit verbundenen Wallets an Krypto-Wallets der Angreifer umzuleiten. Der monetäre Erfolg des Angriffes ist verglichen mit den beiden anderen Angriffen, S1ingularity und Shai-Hulud, gering.

Die Timeline des Angriffs:

1. 08. September 2025 (früh): Zugangsdaten des Maintainers Qix werden per Phishing gestohlen
2. 08. September 2025 (mittags): Kompromittierte Paketversionen werden veröffentlicht
3. 08. September 2025 (nachmittags): Qix beginnt mit der Entfernung der bösartigen Pakete
4. 08. September 2025 (abends): Weitere Pakete eines zweiten Maintainers mit selbem Schadcode werden identifiziert

Wie bereits erwähnt fand die initiale Kompromittierung des Entwicklers Qix über eine Phishing-E-Mail statt. Diese wurde von der Adresse support@npmjs.help versendet. Hier zum Vergleich: Üblicherweise versendet NPM-E-Mails ausgehend von der Domäne npmjs.com. Mit dem Tool crt.sh kann nachvollzogen werden, dass ein Zertifikat für diese Domäne erst kurz vor dem Angriff, nämlich am 05 September 2025, ausgestellt worden ist. Die eigentliche Phishing-Mail ist nachfolgend dargestellt:

Wie der Abbildung zu entnehmen ist handelt es sich um eine Phishing-E-Mail, die das Design valider E-Mails von NPM imitiert. Durch das Vortäuschen falscher Tatsachen – in diesem Fall die Notwendigkeit des Updatens der Multifaktorauthentifizierung aus Gründen der Sicherheit da dies zuletzt vor mehr als 12 Monaten geschah – wurde eine Dringlichkeit der Bearbeitung der E-Mail in Zusammenhang mit der sonstigen Einschränkung des Accounts vorgetäuscht.

Nach Klick auf den hinter Update 2FA Now verborgenen Link wurde auf die durch die Angreifer registrierte Domäne npmjs.help weitergeleitet. Die hier gehostete Webseite ist mittlerweile offline, kann aber unter der Wayback-Maschine noch eingesehen werden. Die Login-Seite ist hier verfügbar: https://web.archive.org/web/20250908125333/https://www.npmjs.help/login

Es handelt sich dabei um einen Klon der npmjs.com Seite – diese ist hier abrufbar. Um nun den durch Multifaktorauthentifizierung geschützten Login umgehen zu können, wurde in etwa folgende Taktik (auch als Adversary-in-the-Middle bekannt) eingesetzt:

1. Qix wurde durch die Phishing-E-Mail auf die vom Angreifer kontrollierte Phishing-Seite gelockt
2. Qix gab auf der Login-Seite seine Zugangsdaten ein
3. Die Zugangsdaten wurden durch den Angreifer an die valide NPM-Authentifizierungsseite weitergeleitet
4. Nach erfolgreicher Eingabe der Zugangsdaten ist die nun dargestellte MFA Eingabe-Seite abgefangen und an Qix auf der Phishingseite weitergeleitet worden
5. Qix gab seinen 2FA Verifizierungscode aus der Authentifizierungsapp auf der Seite ein – dieser wurde erneut durch den Angreifer an die eigentlich Login-Seite weitergeleitet

Der nun ausgestellte valide Session-Cookie wurde vom Angreifer abgefangen – damit hatte dieser Vollzugriff auf den Account von Qix

Da diese Art des Phishings mit Ziel der Umgehung der Multifaktorauthentifizierung häufig bei Angriffen auf Unternehmen Anwendung findet, sollte der Umgang und die Erkennung regelmäßig trainiert werden. Kommen Sie bei Fragen hierzu ebenso wie dem Wunsch der Nachstellung von Teilen oder wahlweise der vollständigen Angriffskette beispielsweise in einem Red-Team gerne auf die NSIDE (info@nsideattacklogic.de) zu!

Nach der erfolgreich durchgeführten Phishing-Attacke und dem Erhalt des Zugriffs auf die durch den Maintainer unterhaltenen Pakete wurden neue Versionen dieser mit eingebetteter Malware veröffentlicht. Wie aber erfolgte nun die tatsächliche Kompromittierung von Entwicklern? Hierfür gab es hauptsächlich die folgenden drei Möglichkeiten:

• Eines der Kompromittierten Pakete wurde durch Entwickler neu in ein Projekt eingebunden und dafür heruntergeladen.
• Ein bestehendes Projekt wurde neu gebaut. Bei diesem Prozess wird durch NPM automatisch die Version eingebundener Softwarepakete überprüft – stehen neue Versionen zur Verfügung, werden diese, insofern kein Versionspinning genutzt wird, heruntergeladen.
• Das Ausführen des Befehls npm update ersetzt ältere Paketversionen durch die neuste zur Verfügung stehende. Auch über diesen Vektor kann ein Entwickler kompromittiert werden.

Die Malware wird ausgeführt, nachdem ein kompromittiertes Paket heruntergeladen und der Schadcode in zum Beispiel browserseitige Skripte eingebunden wurde. Werden die kompromittierten Pakete nur auf Seiten des Web-Servers eingesetzt, besteht hier ein geringeres Risiko für Nutzer der Anwendung. Bei Nutzen der Pakete für das Front-End (browserseitig) wird der Schadcode allerdings im Browser des Seitennutzers ausgeführt und kann entsprechend große Wirkung entfalten. Die genaue Auswirkung wird nachfolgend anhand von Codebeispielen aus der hier verfügbaren Malware aufgezeigt.

Disclaimer: Unter obigem Link ist der tatsächliche Code der Malware auffindbar – diese sollte unter keinen Umständen ausgeführt werden. Das Verlinken des Quellcodes der Malware soll Sicherheitsteams die Detailanalyse dieser ermöglichen.

Die eigentliche Malware – der Crypto Hijacker – wurde obfuskiert innerhalb von einer Codezeile in die am Ende des Artikels genannten Paketversionen eingeschleust. Die Obfuskation dient dem Zweck, die (automatisierte) Erkennung schwerer zu gestalten und ein Nachvollziehen der Funktionalität der Malware hinauszuzögern da kein einfach verständlicher Code vorliegt.

Der Obfuskierte Codeder geteilten Malware kann beispielsweise in den Online-Deobfuskator deobfuscate.io kopiert werden. Als Ausgabe erhält man die tatsächliche Java-Script Malware – allerdings noch mit kryptischen Variablen und Funktions- / Methodennamen:

Zur Verdeutlichung der Funktionsweise der Malware wird diese nachfolgend grob anhand von Codeauszügen aufgezeigt.

Zuerst werden einige Variablen definiert, die benötigt werden, um den Status der Ausführung des Skriptes zur Laufzeit auswerten zu können:

Nachfolgend ist die Hauptfunktion checkethereumw definiert. Diese versucht, über die window-API geöffnete oder angebundene Crypto-Wallets zu identifizieren. Ist dies erfolgreich wird die Funktion runmask ebenso wie anschließend die Funktion newdlocal aufgerufen. Konnte keine Crypto-Wallet identifiziert wird nur newdlocal ausgeführt.

Bevor nun die soeben angesprochene Funktion aufgerufen wird, überprüft die Malware zuerst, ob sie im Kontext eines Browsers ausgeführt wird. Ist dies nicht der Fall überspringt die Malware den Aufruf der Funktion runmask und ruft die Funktion newdlocal auf.

Um zuerst den gedachten Codefluss der Malware nachzuvollziehen, wird nachfolgend der Ablauf der Funktion runmask aufgezeigt – nach erfolgreicher Validierung der Ausführung der Malware im Browser und anschließendem Aufruf von checkethereumw. Wurde also eine angebundene Crypto-Wallet identifiziert, so wird zu Beginn der Funktion runmask eine weitere eingebettete Funktion 0x1089ae – im Folgenden modify_transaction_object genannt -aufgerufen. Diese benötigt zur Ausführung zwei Parameter:

1. Ein Objekt, das eine abgefangene Crypto-Transaktion enthält.
2. Ein Boolescher Wert, um anzuzeigen, ob es sich bei der Transaktion um eine Solana-artige oder Ethereum-artige Transaktion handelt

Der Funktionsrumpf ist nachfolgend dargestellt:

Innerhalb der Funktion wird das übergebene Transaktions-Objekt dupliziert und anschließend modifiziert, sodass beispielsweise bei Ethereum-Transaktionen größer dem Wert 0 der Empfänger der Transaktion auf die feste Wallet-Adresse 0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976 gesetzt wird:

Ist bei der Transaktionsobjekt ebenfalls ein Datenfeld vorhanden, so wird im nächsten Schritt überprüft, um welche Art von Transaktion es sich handelt. Dies kann mithilfe der Signatur (dem kryptographischen Hash der Funktion) der Transaktion erfolgen. Durch die Malware werden die folgenden Transaktionsarten unterschieden:

Die sich hinter den Transaktionssignaturen verbergenden Transaktionsarten (kann mit dem hier verfügbaren Signaturscanner überprüft werden) sind in nachfolgender Tabelle dargestellt:

Eine Unterscheidung anhand der Signaturen findet hier aus dem Grund statt, dass die einzelnen Transaktionstypen unterschiedliche Parameter benötigen. Bei dem Transaktionstype Transfer wird beispielsweise die Empfängeradresse auf die hardcodierte Wallet-Adresse:

abgeändert. Der dafür eingesetzte Code ist der folgende (nachfolgend exemplarisch nur ein Mal anstelle für jede Transaktion aufgezeigt):

Wenn keiner der Transaktionscodes gefunden wird, aber ein Eingabeobjekt vorhanden ist, wird versucht, die Empfängeradresse auf die genannte Wallet-Adresse abzuändern.

Handelt es sich bei der Transaktion um eine Solana-Transaktion wird ähnlich vorgegangen – die Empfängeradresse wird in diesem Fall allerdings einfach auf die nachfolgende hartkodierte Wallet-Adresse abgeändert:

Im Anschluss daran wird eine weitere Funktion innerhalb von runmask definiert – hierbei handelt es sich um eine der beiden Funktionen, die die eigentliche Proxy-Funktionalität (Name 0x485f9d) des Crypto-Stealers realisieren. Die Proxy-Funktionalität ist dafür verantwortlich, dass bei Crypto-Transaktionen aufgerufene API-Funktionen z.B. zum Absenden einer Transaktion abgefangen und vorab mit den Angreifer-Adressen modifiziert werden können.

Auch diese muss mit zwei Parametern aufgerufen werden – erstens der original aufgerufenen Methode der window-API und dem Namen der Methode. Handelt es sich bei der Transaktion um eine Ethereum Transaktion, so wird die Funktion modify_transaction_object mit Parameter 2 gleich True aufgerufen – handelt es sich um eine Solana Transaktion so wird Parameter 2 als False gesetzt. Eine weitere Unterscheidung findet an dieser Stelle nicht statt. Im Anschluss an dieses Vorgehen wird die eigentliche window-API-Funktion mit den so modifizierten Transaktions-Objekten aufgerufen.

Eine verkürzte Version des Codes dieser Funktion ist nachfolgend dargestellt:

Die soeben beschriebene Funktion wird von einer weiteren Funktion mit der Signatur 0x41630a aufgerufen. Hierbei handelt es sich um die Funktion, in der die eigentlichen window-API Methoden überschrieben werden. Sie ruft obige Funktion als Hilfsfunktion auf. Bei den überschriebenen Methoden handelt es sich um die folgenden drei: request, send und sendAsync. Das Überschreiben der Funktionen erfolgt durch das Abspeichern der originalen Methode und die anschließende Neudefinition dieser durch den Aufruf von Object.defineProperty um sicherzustellen, dass die modifizierte Version in jedem Fall Anwendung findet. Ist der Versuch die veränderte Version der Methode als Proxy zu setzen erfolgreich, so wird dies durch eine gesetzte Variable zwischengespeichert. Der Code der die beschriebene Funktionalität umsetzt ist nachfolgend abgekürzt dargestellt:

Der Aufruf der genannten Funktionen und damit der Versuch des Hookens der window-API erfolgt bis zu 50 mal in Abständen von 100 Millisekunden – damit versucht der Crypto-Stealer bis zu 5 Sekunden nach dem initialen Laden die API zu infiltrieren. Ist dies nicht erfolgreich, so wird der Versuch abgebrochen. Zusätzlich wird zu Ende der Funktion runmask noch ein globales Objekt exponiert, damit externer Code mit dem soeben erläuterten Proxymechanismus interagieren kann:

Damit ist die Funktionalität der Funktion runmask, die bei perfekten Bedingungen für die Malware auf dem Opfersystem ausgeführt wird, dargestellt. Allerdings gibt es noch eine zweite große und bereits kurz angesprochene Funktion – nämlich newdlocal. Deren Funktionalität soll ebenfalls nachfolgend abgekürzt aufgezeigt werden.

Zu Beginn wird hier ein Objekt definiert, das hartkodierte Crypto-Wallet Adressen in sich hält.

Die große Anzahl an Wallet-Adressen wird von der Malware dazu genutzt, durch mathematische Berechnung immer die der eigentlichen Adresse am ähnlichsten aussehende Wallet-Adresse in die Transaktion einsetzen zu können. Damit steigt die Wahrscheinlichkeit, dass die Ersetzung der Adresse dem Opfer nicht auffällt. Die ähnlichste Wallet-Adresse wird durch eine Mathematische sogenannte Levenshtein-Distanz Funktion berechnet. Grob beschrieben kann durch die Funktion der Abstand zwischen zwei Strings – die sogenannte Levenshtein-Distanz – berechnet werden. Das bedeutet also, die kleinste Anzahl an benötigten Änderungen von Buchstaben oder Zahlen aus den Wallet-Adressen, um auf die tatsächlich verwendete Adresse zu kommen wird berechnet und diese bösartige Wallet-Adresse eingesetzt. Der dafür verantwortliche Quellcode aus der Malware ist nachfolgend aufgezeigt:

Nach den obigen Funktionen zum Ersetzen von Wallet-Adressen ist in der Malware zuletzt noch Code enthalten, um HTTP-Antworten auf Anfragen über die globale Funktion fetch abzufangen und auch hier die entsprechenden Crypto-Adressen in der Antwort ersetzen zu können. Der Inhalt von Antworten wird zunächst auf den Content-Type untersucht – unterschieden wird zwischen JSON-Objekten und Text. Nach Ändern der Daten des Response-Objektes wird dieses mit originalem Status und originalen Headern zurückgegeben. Dies bedeutet, dass Anfragen, die durch Webseiten oder beispielsweise sogenannte dApps gestellt werden, nach Ausführen des obigen Codes Angreifer-Adressen inkludieren. Der verantwortliche Code ist nachfolgend dargestellt:

Zusätzlich dazu werden auch die Funktionen open und send der API XMLHttpRequest abgefangen und die Funktion send modifiziert – ähnlich der obigen Modifikation. Dies findet wie nachfolgend erläutert statt.

Der Aufruf der API-Funktion Open wird einfach weitergeleitet:

Der Aufruf der Funktion send hingegen wird modifiziert – insofern der readystate gleich dem Wert 4 ist. Dies entspricht dem Abschluss der HTTP-Kommunikation wie diesem Artikel zu entnehmen ist. Hierbei werden erneut die Crypto-Adressen, der responseText und die response Eigenschaften durch Angreifer kontrollierte Adressen ersetzt. Durch das Abfangen und Modifizieren der XMLHTTPRequest API Funktionen versucht der Crypto-Stealer sicherzustellen, dass auch ältere Software von der Malware unterstützt wird. Im Folgenden sehen Sie den Code, der das eben Beschriebene umsetzt:

Die letzten beiden Funktionen des Crypto-Stealers setzen die tatsächliche Ersetzung von Crypto-Adressen um, indem sie soeben beschriebene Funktionen systematisch und basierend auf dem Übergabedatentyp, also Objekt oder String, aufrufen:

Zuletzt ist noch der Code der Funktion zum tatsächlichen Suchen und Ersetzten der Adressen angehangen:

Damit ist die Funktionalität des Crypto-Stealers ausgeschöpft. Kurz zusammengefasst ist also folgende Funktionalität enthalten:

1. Der Cypto-Stealer kann gezielt die Funktionen send und open der XMLHTTPRequest-API abfangen und editieren
2. Der Crypto-Stealer kann Kommunikation über die Funktion fetch abfangen und editieren
3. Ziel der Malware sind Crypto-Transaktionen – Die originalen Wallet-Adressen werden mithilfe einer Levenshtein-Distance Funktion durch ihre nächsten Verwandten aus der Liste der Angreifer kontrollierten Wallet-Adressen ersetzt
4. Die Malware implementiert kein Logging, keine Command and Control Infrastruktur und hat keine Mechanismen für Persistenz auf Zielgeräten implementiert
5. Die Malware kommuniziert nicht gezielt nach außen
6. Bei Nichtdetektion von angebundenen Wallets werden XMLHTTPRequest ebenso wie die window-API trotzdem gehookt

Da Transaktionen auf der Blockchain beispielsweise über den Blockchain-Explorer nachvollzogen werden können, ist es möglich, den Erfolg des Angriffes durch Monitoring aller hardkodierten Wallets aus der Malware nachzuvollziehen. Nach Analyse aller angebundenen Wallets kann schnell nachvollzogen werden, dass der finanzielle Erfolg der Malware für die Angreifer eher gering ausfällt. Einzig unter den (BTC) Adressen:

kann ein geringer Geldeingang im Rahmen von 389,61 $ nachvollzogen werden. Die in der Malware enthaltenen Solana-Adressen wurden hierfür allerdings nicht berücksichtigt.

Der tatsächlich entstandene Schaden liegt jedoch weit über der genannten Zahl: Durch den nicht unerheblichen Zeitaufwand, den die betroffenen Entwicklungsteams für die Analyse, Bereinigung und Absicherung der potenziell 2,5 Millionen Systeme die mit der Malware infiziert wurden aufbringen mussten, entstand ein Produktivitätsverlust. Hinzu kommt auch der Vertrauens- und Reputationsschaden gegenüber Nutzern des NPM-Paketmanagers. Auch dieser lässt sich nicht monetär darstellen. Der immaterielle Verlust übersteigt folglich den direkten finanziellen Schaden der Angreifer bei weitem und verdeutlicht, dass der wirtschaftliche Gesamtschaden in erster Linie durch den Unterbrechungs- und Wiederherstellungsaufwand der betroffenen Projekte entstanden sein dürfte.

Es gibt mehrere Maßnahmen um zu erkennen, ob das eigene Projekt durch den Angriff Chalk and Debug kompromittiert wurde. In einem ersten Schritt sollten die Projektdateien package-lock.json, pnpm-lock.yaml, yarn.lock von NPM Nutzenden Projekten und die Registry Artefakte nach den im Anhang genannten Versionen durchsucht werden. Ist eine der genannten Paketversionen vorhanden, kann von einer Kompromittierung ausgegangen werden. Zusätzlich hierzu können bereits gebaute Projekte nach Strings durchsucht werden, die auf den Obfuskierten Quellcode der Malware hinweisen. Hierfür bietet sich unter anderem der Beginn der Malware an:

Auch nach in der Malware vorkommenden Funktionsnamen kann gesucht werden:

1. runmask
2. newdlocal
3. checkethereumw
4. stealthProxyControl

Genannte Namen sind auch in der obfuskierten Version der Malware vorhanden. Da bereits alle verwundbaren Paketversionen in der NPM Advisory Database aufgenommen sind, kann auch der NPM-Befehl npm-audit aus dem Root-Verzeichnis der fraglichen Projekte ausgeführt werden. Detektiert NPM eine der kompromittierten Paketversionen, so wird dies angezeigt.

Auch kann in vergangenen Transaktionen nach der Ethereum Wallet Adresse des Angreifers gesucht werden:

Wurde über oben beschriebene Wege eine Kompromittierung festgestellt, so empfiehlt es sich für Entwickler eine Neuinstallation aller Abhängigkeiten durchzuführen. Hierzu muss im ersten Schritt das node_modules Verzeichnis ebenso wie der Lockfile des Projektes package-lock.json oder yarn.lock gelöscht werden. Anschließend sollte sichergestellt werden, dass innerhalb der package.json Datei keines der betroffenen Pakete auf eine vulnerable Version gepinnt ist – auch wenn diese zum Zeitpunkt der Veröffentlichung des Artikels nicht mehr verfügbar sind. Um sicherzustellen, dass keine kompromittierten Pakete im Cache gespeichert sind, sollte auch dieser bereinigt werden. Diese kann mit nachfolgendem Befehl umgesetzt werden:

Nun kann das Projekt mit:

neu aufgesetzt werden.

Um diesem oder ähnlichen Supply Chain Angriffen bestmöglich vorzubeugen, können unter anderem die folgenden Maßnahmen proaktiv umgesetzt werden:

1. Eine Updateverzögerung um 2 – 7 Tage nach Release von neuen Versionen.
2. Die Deaktivierung der automatischen Ausführung von Post-Install Skripten
3. Versionspinning in NPM in Verbindung mit einem Update-Managementprozess
4. Überprüfung der installierten NPM-Pakete auf gültige sogenannte Commit Hash References
5. Generell: Hinzufügen der bekannten, kompromittierten Versionen der Pakete zur Block-List

Die von der Malware verfolgte Strategie der Kompromittierung der Supply Chain wird in letzter Zeit immer häufiger durch sogenannte Advanced Persistant Threats (APTs) eingesetzt. Eine genaue Attribution des Angriffs ist zurzeit aber nicht möglich. Sollten hier neue Informationen veröffentlicht werden, so halten wir Sie auf dem Laufenden!

Der Chalk & Debug getaufte Angriff auf die Software-Supply-Chain verdeutlicht eindrücklich, wie effektiv diese Art des Angriffes in Zeiten der modernen Softwareentwicklung sein kann. Mit vergleichsweise kleinem Aufwand kann hier innerhalb kürzester Zeit immenser Schaden verursacht werden indem das Vertrauen innerhalb der Softwarelieferkette missbraucht wird.

Strategisch betrachtet liegt der Schlüssel zur Abwehr solcher und ähnlicher Angriffe wie beispielsweise die zuvor genannten Angriffe S1ngularity und Shai-Hulud in der Transparenz, der Überwachung und auch der Reaktionsfähigkeit entlang der gesamten Lieferkette. Um dies zu trainieren empfiehlt sich unter anderem auch die Simulation eines solchen Szenarios und das Testen vorhandener Detektions- und Response-Prozesse.

Benötigen Sie bei der Analyse, Bewertung oder Simulation solcher Szenarien Unterstützung? Dann kommen Sie gerne jederzeit auf uns zu (info@nsideattacklogic.de) – wir helfen dabei, Ihre Entwicklungs- und Lieferkettenprozesse nachhaltig abzusichern.