• Cybersicherheit ist Chefsache: Warum NIS-2 die Geschäftsführung in die Pflicht nimmt

    VonJ. Benjamin Espagné

    Cybersicherheit ist längst kein reines IT-Thema mehr — sie ist Chefsache. Das wird spätestens mit NIS-2 und dem EU AI Act auch regulatorisch unmissverständlich. In einem aktuellen Beitrag für contentway bringt Dr. Andreas Herch, CEO der Business Unit accompio Enterprise, die zentrale Botschaft auf den Punkt: Wer Cyberresilienz will, braucht Führung — nicht nur Technik.

    NIS-2 macht Cybersicherheit zur Pflichtaufgabe der Geschäftsführung

    Die NIS-2-Richtlinie und der EU AI Act heben das Schutzniveau in Europa auf ein verbindlicheres Level. Was früher als freiwillige Kür galt — Risikomanagement, Incident Response, Business Continuity, Audits — wird jetzt Pflicht. Und die Verantwortung liegt nicht mehr bei der IT-Abteilung allein, sondern direkt bei der Geschäftsführung. Inklusive persönlicher Haftung.

    Dr. Herch formuliert es klar: Cybersicherheit ist eine strategische Führungsaufgabe geworden. Unternehmen müssen Prozesse, Governance und Verantwortlichkeiten strukturell verankern. NIS-2 zwingt dazu — und das ist im Kern keine Bedrohung, sondern eine Chance.

    Der blinde Fleck: Fokus auf Technik statt auf Menschen

    Ein zentraler Punkt des Artikels verdient besondere Aufmerksamkeit: Häufig liegt der Fokus von IT-Organisationen zu stark auf der Technik. Die Mitarbeitenden, deren Verhalten oft die Haupteinfallstore sind, werden dagegen häufig vergessen. Firewalls und Endpoint Protection sind notwendig — aber ohne Awareness-Programme, klare Governance-Strukturen und definierte Verantwortlichkeiten bleiben sie Lösungen für nur die Hälfte des Problems.

    Organisatorische Maßnahmen sind neben den technischen Schritten genauso wichtig: Governance-Strukturen aufbauen, Verantwortlichkeiten klar definieren, zentrale Aufgaben so verteilen, dass sie nicht in Zuständigkeitslücken fallen.

    Der richtige Startpunkt: Security-IST-Analyse

    Dr. Herch empfiehlt Unternehmen, zunächst einen erfahrenen Dienstleister mit einer Security-IST-Analyse zu beauftragen — Status quo und Benchmark ermitteln, bevor investiert wird. Das klingt selbstverständlich, wird aber in der Praxis oft übersprungen. Stattdessen wird in teure Software investiert, ohne zu wissen, wo die tatsächlichen Lücken liegen.

    Erst ein Audit, das die komplette Bandbreite einer möglichen Cyberstrategie durchspielt, deckt NIS-2-Lücken auf und lenkt den Fokus auf die relevanten Baustellen. Darauf aufbauend lässt sich ein passendes Sicherheitskonzept ableiten.

    Schlüsselführungsfragen für die Geschäftsführung

    Der Artikel nennt eine Reihe von Fragen, die jede Geschäftsführung beantworten können sollte — und die in der Praxis erschreckend oft unbeantwortet bleiben:

    Wie sind wir IT-technisch für einen Produktionsausfall vorbereitet? Wie aktuell ist unser Notfallkonzept? Wurden alle NIS-2-Vorgaben umgesetzt? Wo haben wir noch Lücken? Deckt unsere Cyber-Versicherung unser Geschäftsmodell ab?

    Wenn diese Fragen nicht spontan und substanziell beantwortet werden können, ist das ein klares Signal: Es besteht Handlungsbedarf — und zwar auf Führungsebene, nicht in der IT-Abteilung.

  • Cyberrisiken finanziell messbar machen: Warum Cybersicherheit in die Sprache des Vorstands übersetzt werden muss

    VonJ. Benjamin Espagné

    Was man nicht messen kann, kann man auch nicht steuern. Dieser Grundsatz gilt in der Betriebswirtschaft seit Jahrzehnten — nur in der Cybersicherheit wird er konsequent ignoriert. Unternehmen investieren jährlich erhebliche Mittel in Security-Maßnahmen, ohne ein echtes Verständnis dafür zu haben, welche Risiken sie damit tatsächlich adressieren — und welche nicht.

    In einem aktuellen Interview für contentway erläutert Asdrúbal Pichardo, Managing Director und CEO von Squalify, warum die finanzielle Quantifizierung von Cyberrisiken ein zentraler Hebel für bessere Sicherheitsentscheidungen ist.

    Cyberrisiken als betriebswirtschaftliche Größe

    Das Kernproblem: Cybersicherheit wird in den meisten Unternehmen weiterhin als Angelegenheit der IT-Abteilung behandelt. Investitionen orientieren sich an Checklisten oder subjektiven Einschätzungen statt an messbaren Auswirkungen auf das Geschäft. Die Folge: Vorstände und Geschäftsführer können nicht beurteilen, ob jeder investierte Euro dort wirkt, wo er das Unternehmen tatsächlich schützt.

    Squalify verfolgt einen anderen Ansatz: Das Unternehmen übersetzt Cyberrisiken in finanzielle Kennzahlen — ROI, EBIT, Cashflow. Damit sprechen IT und Vorstand endlich die gleiche Sprache. Das Cyberrisiko wird auf Unternehmensebene betrachtet: die Konsequenzen eines Cyber-Vorfalls auf das Unternehmen quantifiziert, mit direkter Relevanz für die Geschäftsführung.

    42 Datenpunkte für belastbare Risikoaussagen

    Bemerkenswert ist die Effizienz des Ansatzes: Anhand von nur 42 Datenpunkten berechnet die Squalify-Plattform bereits belastbare Zahlen mit Vorstandsrelevanz. Das Quantifizierungsmodell basiert auf historischen Daten zu tatsächlichen Cyber-Verlusten von mehr als 100.000 Unternehmen weltweit und der Expertise von Munich Re, einem der führenden Cyber-Rückversicherer.

    Die Ergebnisse werden auf Basis eines standardisierten, an Unternehmensdaten angepassten Modells in finanzielle Kennzahlen übersetzt. Das ermöglicht präzise Risikoaussagen mit minimalem Aufwand — ein entscheidender Vorteil gegenüber klassischen Risk-Assessments, die oft Monate dauern und trotzdem abstrakt bleiben.

    Typische Anwendungsfälle

    Unternehmen nutzen die Plattform laut Pichardo vor allem, um festzustellen, welche Investitionen in Cybersicherheit den größten Effekt haben und das Risiko am stärksten reduzieren. Gerade Großunternehmen setzen Squalify außerdem zur transparenten Steuerung von Tochtergesellschaften oder für objektive Benchmarks mit Wettbewerbern ein. Darüber hinaus unterstützt die Plattform bei der Auswahl geeigneter Cyberversicherungen.

    Warum das für die Geschäftsführung relevant ist

    Die finanzielle Quantifizierung von Cyberrisiken adressiert ein Problem, das mit NIS-2 akuter denn je ist: Geschäftsführer haften persönlich für die Angemessenheit ihrer Sicherheitsmaßnahmen. Doch wie weist man Angemessenheit nach, wenn man die Risiken nicht beziffern kann? Wer seine Cyberrisiken in Euro ausdrücken kann, trifft bessere Entscheidungen — und kann diese gegenüber Aufsichtsbehörden, Versicherern und Geschäftspartnern belegen.

    Der Ansatz zeigt, wohin sich die Branche entwickelt: Weg vom Bauchgefühl, hin zu datengetriebenen Sicherheitsentscheidungen auf Vorstandsebene.

  • ·

    Cyber Resilience Act: Was der CRA für Ihr Unternehmen bedeutet

    VonJ. Benjamin Espagné

    Der EU Cyber Resilience Act (CRA) ist seit Ende 2024 in Kraft und entfaltet ab dem 11. Juni 2026 erste Wirkung. Mit ihm schafft die EU erstmals einen einheitlichen Rechtsrahmen für die Cybersicherheit von Produkten mit digitalen Elementen — von der Firmware im Router bis zur Cloud-basierten Unternehmenssoftware. Für Hersteller, Importeure und Händler gelten weitreichende neue Pflichten. Aber auch für Unternehmen, die solche Produkte einsetzen, ändert sich mehr als auf den ersten Blick erkennbar.

    Worum geht es beim CRA?

    Der CRA verfolgt einen horizontalen Ansatz: Er reguliert nicht einzelne Branchen, sondern alle Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht werden. Das umfasst Hardware mit eingebetteter Software ebenso wie eigenständige Softwareprodukte. Betroffen sind unter anderem Firewalls, Router, Switches, industrielle Steuerungen, Smart-Home-Geräte, aber auch Business-Software, ERP-Systeme und Cloud-Dienste.

    Im Kern verlangt der CRA:

    • Security by Design: Cybersicherheit muss von der Konzeption bis zum Ende des Produktlebenszyklus mitgedacht werden
    • Schwachstellenmanagement: Hersteller müssen bekannt gewordene Schwachstellen aktiv managen und Sicherheitsupdates bereitstellen — kostenlos und über einen definierten Zeitraum
    • Meldepflichten: Aktiv ausgenutzte Schwachstellen müssen innerhalb von 24 Stunden an die ENISA gemeldet werden
    • Konformitätsbewertung: Produkte müssen vor dem Inverkehrbringen nachweislich die CRA-Anforderungen erfüllen — je nach Risikoklasse durch Selbstbewertung oder durch eine unabhängige Prüfstelle
    • Dokumentationspflichten: Technische Dokumentation, Software Bill of Materials (SBOM) und Konformitätserklärung werden Pflicht

    Zeitplan: Was gilt ab wann?

    Der CRA tritt stufenweise in Kraft:

    • Ab 11. Juni 2026: Pflichten für Konformitätsbewertungsstellen greifen
    • Ab 11. September 2026: Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle
    • Ab 11. Dezember 2027: Alle CRA-Anforderungen gelten vollständig — Produkte ohne CRA-Konformität dürfen nicht mehr in Verkehr gebracht werden

    Parallel dazu muss Deutschland ein nationales Durchführungsgesetz verabschieden. Der aktuelle Referentenentwurf des BMI sieht vor, dem BSI die zentrale Rolle als Marktüberwachungsbehörde, CSIRT und Beschwerdestelle zuzuweisen. TeleTrusT, der Bundesverband IT-Sicherheit, kritisiert in seiner aktuellen Stellungnahme vom 1. April 2026 allerdings, dass die personelle und finanzielle Ausstattung des BSI dafür nicht gesichert sei und die vorgesehenen Unterstützungsmaßnahmen für Unternehmen mit nur 1,28 Mio. Euro jährlich massiv unterfinanziert seien.

    Wen betrifft der CRA direkt?

    Hersteller

    Wer Produkte mit digitalen Elementen herstellt und in der EU in Verkehr bringt, ist Hauptadressat des CRA. Das betrifft nicht nur klassische Hardware-Hersteller, sondern ausdrücklich auch Softwareunternehmen. Selbst Open-Source-Projekte können unter bestimmten Voraussetzungen erfasst sein, wenn sie kommerziell genutzt werden.

    Importeure und Händler

    Wer Produkte aus Drittstaaten in die EU importiert oder weitervertreibt, muss sicherstellen, dass die CRA-Anforderungen erfüllt sind. Im Klartext: Wer IT-Produkte aus den USA, China oder anderen Nicht-EU-Staaten bezieht und im eigenen Geschäftsbetrieb einsetzt oder weiterverkauft, trägt Mitverantwortung.

    Anwender und Betreiber

    Unternehmen, die Produkte mit digitalen Elementen einsetzen, sind zwar nicht direkt Adressaten des CRA. Mittelbar betrifft sie der CRA aber erheblich — und genau hier wird es für die Kunden von NEOSEC relevant.

    Was der CRA für NEOSEC-Kunden konkret bedeutet

    1. Höhere Baseline-Sicherheit in der Lieferkette

    Der CRA wird dafür sorgen, dass Produkte, die in der EU verkauft werden, ein Mindestmaß an Cybersicherheit mitbringen. Für Betreiber kritischer Infrastrukturen und NIS2-pflichtige Unternehmen bedeutet das langfristig: Die Produkte, die Sie einkaufen, werden sicherer. Kurzfristig bedeutet es allerdings auch: Ihre bestehenden Beschaffungsprozesse müssen angepasst werden. Fragen Sie Ihre Lieferanten nach CRA-Konformität, SBOM und Schwachstellenmanagement-Prozessen.

    2. Wechselwirkung mit NIS2

    NIS2 verpflichtet Unternehmen zu Risikomanagementmaßnahmen — und dazu gehört ausdrücklich auch die Sicherheit in der Lieferkette (Art. 21 Abs. 2 lit. d NIS2-Richtlinie). Der CRA liefert hier das Pendant auf Produktseite. Wer als NIS2-pflichtige Einrichtung Produkte ohne CRA-Konformität einsetzt, könnte mittelfristig Schwierigkeiten bekommen, die eigenen Lieferkettensicherheitspflichten nachzuweisen. Umgekehrt wird die CRA-Konformität eines Produkts zu einem belastbaren Nachweis im Rahmen Ihres NIS2-Risikomanagements.

    3. Software Bill of Materials wird Standard

    Der CRA macht die SBOM — eine maschinenlesbare Aufstellung aller Softwarekomponenten eines Produkts — zur Pflicht. Für Ihr Schwachstellenmanagement ist das ein Gewinn: Wenn ein neues CVE veröffentlicht wird, können Sie anhand der SBOM Ihrer eingesetzten Produkte sofort prüfen, ob betroffene Komponenten in Ihrem Netz laufen. Voraussetzung dafür ist, dass Sie SBOMs Ihrer Lieferanten einfordern und systematisch auswerten — idealerweise automatisiert über Ihr SIEM.

    4. Meldepflichten ergänzen sich

    NIS2 verpflichtet Betreiber zur Meldung von Sicherheitsvorfällen. Der CRA verpflichtet Hersteller zur Meldung aktiv ausgenutzter Schwachstellen. Für Sie als Betreiber heißt das: Sie erfahren schneller von Schwachstellen in den Produkten, die Sie einsetzen. Gleichzeitig steigt die Anforderung, diese Informationen auch operativ zu verarbeiten — also zeitnah zu bewerten, zu priorisieren und zu patchen.

    5. Übergangszeit nutzen

    Bis Dezember 2027 gilt die volle Übergangsfrist. Diese Zeit sollten Unternehmen nutzen, um ihre Beschaffungsprozesse, Lieferantenanforderungen und das interne Schwachstellenmanagement auf den CRA vorzubereiten. Warten Sie nicht, bis Ihre Lieferanten von sich aus CRA-konforme Produkte liefern — setzen Sie die Anforderungen jetzt schon in Ihre Einkaufsbedingungen.

    Handlungsempfehlungen

    Für alle Unternehmen, die IT-Produkte einsetzen:

    • Inventar erstellen: Welche Produkte mit digitalen Elementen setzen Sie ein? Welche davon kommen von Herstellern außerhalb der EU?
    • Lieferantenanforderungen anpassen: Nehmen Sie CRA-Konformität, SBOM-Bereitstellung und definierte Supportzeiträume in Ihre Beschaffungsanforderungen auf
    • SBOM-Management aufbauen: Etablieren Sie Prozesse, um SBOMs Ihrer Lieferanten entgegenzunehmen, zu speichern und bei neuen CVEs automatisiert abzugleichen
    • Schwachstellenmanagement schärfen: Stellen Sie sicher, dass Ihr SOC oder SIEM die Herstellermeldungen zu Schwachstellen aufnehmen und priorisieren kann
    • NIS2-Dokumentation ergänzen: Die CRA-Konformität Ihrer eingesetzten Produkte wird ein wichtiger Baustein in Ihrer NIS2-Risikomanagement-Dokumentation

    Für Unternehmen, die selbst Produkte herstellen oder vertreiben:

    • CRA-Betroffenheit prüfen: Fallen Ihre Produkte unter den CRA? In welche Risikoklasse?
    • Security-by-Design verankern: Überprüfen Sie Ihre Entwicklungsprozesse — Cybersicherheit muss ab der Konzeptionsphase integriert sein
    • Schwachstellenmanagement-Prozess etablieren: 24-Stunden-Meldepflicht an die ENISA bei aktiv ausgenutzten Schwachstellen — das erfordert funktionierende interne Prozesse
    • SBOM generieren: Automatisieren Sie die Erstellung von Software Bills of Materials als Teil Ihrer CI/CD-Pipeline
    • Konformitätsbewertung vorbereiten: Klären Sie frühzeitig, ob eine Selbstbewertung ausreicht oder eine Prüfstelle hinzugezogen werden muss

    Was noch unklar ist

    Der CRA ist als EU-Verordnung unmittelbar anwendbar, benötigt aber nationale Durchführungsgesetze — und genau dort gibt es Nachholbedarf. Der aktuelle deutsche Referentenentwurf weist laut TeleTrusT erhebliche Lücken auf: Die Ausnahme von der Akkreditierungspflicht für Konformitätsbewertungsstellen ist zu weit gefasst, das geplante Reallabor für Cyberresilienz bleibt inhaltlich vage, und die finanzielle Ausstattung der Unterstützungsmaßnahmen für KMU ist unzureichend.

    Für Unternehmen bedeutet das: Planen Sie nicht mit dem Minimalstandard des Durchführungsgesetzes, sondern orientieren Sie sich direkt an den Anforderungen der EU-Verordnung selbst. Das nationale Gesetz wird nur den Vollzugsrahmen regeln — die materiellen Pflichten stehen bereits fest.

    Einordnung

    Der CRA ist neben NIS2 und der CER-Richtlinie der dritte große Baustein im EU-Cybersicherheitsrahmen. Während NIS2 die Betreiber adressiert und die CER-Richtlinie die physische Resilienz, schließt der CRA die Lücke auf Produktseite. Für Unternehmen, die bereits unter NIS2 fallen, ist der CRA keine zusätzliche Belastung, sondern eine sinnvolle Ergänzung: Er sorgt dafür, dass die Produkte, die Sie einsetzen, endlich den Sicherheitsstandards entsprechen müssen, die Sie selbst einhalten sollen.

    Ob der CRA in der Praxis funktioniert, wird maßgeblich davon abhängen, ob die Marktüberwachung durch das BSI tatsächlich wirksam wird — und ob Unternehmen die Übergangszeit nutzen, statt sie aussitzen.

    Sie möchten wissen, wie der CRA konkret auf Ihr Unternehmen wirkt und wie Sie Ihre NIS2-Compliance um die CRA-Dimension erweitern? NEOSEC unterstützt Sie bei der Gap-Analyse, der Bewertung Ihrer Lieferkette und der Integration in Ihr bestehendes Risikomanagement. Sprechen Sie uns an.

  • · ·

    Axios Supply-Chain-Angriff: Was Admins jetzt prüfen müssen

    VonJ. Benjamin Espagné

    Am 31. März 2026 wurde das npm-Paket Axios — mit rund 100 Millionen wöchentlichen Downloads eine der meistgenutzten JavaScript-Bibliotheken weltweit — durch einen Supply-Chain-Angriff kompromittiert. Die trojanisierten Versionen waren nur zwei bis drei Stunden online, bevor sie entfernt wurden. Trotzdem: Bei dieser Verbreitung reicht ein kurzes Zeitfenster, um tausende Entwicklungsumgebungen zu infizieren.

    Google Threat Intelligence hat den Angriff der nordkoreanischen Gruppe UNC1069 zugeordnet. Es handelt sich nicht um einen opportunistischen Angriff, sondern um eine sorgfältig vorbereitete Operation mit plattformübergreifender Malware, Anti-Forensik-Mechanismen und mehrstufiger Verschleierung.

    Was passiert ist

    Die Angreifer kompromittierten den npm-Account des Hauptmaintainers von Axios und veröffentlichten zwei trojanisierte Versionen:

    • axios@1.14.1
    • axios@0.30.4

    Beide Versionen enthielten eine neue Abhängigkeit namens plain-crypto-js@4.2.1 — ein sogenanntes Phantom-Dependency: im Manifest gelistet, aber nirgends im eigentlichen Code verwendet. Dieses Paket enthielt einen verschleierten postinstall-Hook, der beim Installieren automatisch ein Dropper-Skript ausführte.

    Das Skript lud plattformspezifische RAT-Payloads (Remote Access Trojaner) nach:

    • macOS: Binary in /Library/Caches/com.apple.act.mond, Gatekeeper-Bypass via codesign, C2-Callback alle 60 Sekunden
    • Windows: PowerShell-Payload als %PROGRAMDATA%\wt.exe, Persistenz via Registry-Key „MicrosoftUpdate”
    • Linux: Python-Skript als /tmp/ld.py, ausgeführt via nohup

    Nach der Infektion löschte die Malware ihre Spuren: Das kompromittierte package.json wurde durch eine saubere Kopie ersetzt, die Version 4.2.0 statt 4.2.1 meldet. Ein npm list zeigt dann fälschlicherweise eine unbedenkliche Version an.

    Wer betroffen ist

    Potenziell betroffen ist jedes Projekt, das Axios als direkte oder transitive Abhängigkeit nutzt. Laut Wiz betrifft das rund 80 % aller Cloud- und Code-Umgebungen. Fast 175.000 npm-Pakete listen Axios als Dependency.

    Konkret betroffen sind Umgebungen, in denen zwischen dem 31. März (ca. 00:00 UTC) und ca. 03:00 UTC ein npm install, npm update oder ein CI/CD-Build ohne fixiertes Lockfile lief und dabei eine der beiden Versionen gezogen wurde.

    Umgebungen mit einem intakten package-lock.json oder yarn.lock, in denen im Zeitraum kein ungelockerter Install stattfand, sind mit hoher Wahrscheinlichkeit nicht betroffen.

    Sofortmaßnahmen für Admins

    1. Lockfiles und node_modules prüfen

    In jedem Node.js-Projekt auf allen Entwicklungs-, Build- und Produktionsservern:

    # Nach der Phantom-Dependency suchen
grep -r "plain-crypto-js" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

# Installierte Axios-Version prüfen
npm list axios 2>/dev/null | head -20

# In node_modules direkt suchen
find . -path '*/plain-crypto-js' -type d 2>/dev/null

    Wenn plain-crypto-js auftaucht oder Axios in Version 1.14.1 bzw. 0.30.4 installiert ist: Umgebung als kompromittiert betrachten.

    2. Kompromittierte Systeme isolieren — nicht bereinigen

    Infizierte Entwicklungsrechner und Build-Server sofort vom Netz nehmen. Nicht versuchen, die Malware manuell zu entfernen. Der RAT hat möglicherweise bereits Credentials exfiltriert. Stattdessen:

    • System isolieren und forensisch sichern
    • Von einem bekannt sauberen Snapshot oder Image neu aufsetzen
    • Erst nach dem Rebuild wieder ans Netz nehmen

    3. Credentials rotieren — alle

    Auf betroffenen Systemen gespeicherte Zugangsdaten als kompromittiert betrachten:

    • npm-Tokens
    • SSH-Schlüssel
    • Cloud-Provider-Keys (AWS, Azure, GCP)
    • CI/CD-Secrets (GitHub Actions, GitLab CI, Jenkins)
    • API-Keys und Service-Accounts
    • Datenbank-Zugangsdaten

    Wichtig: Nicht in-place rotieren. Alte Credentials widerrufen, neue auf sauberen Systemen generieren.

    4. CI/CD-Pipelines absichern

    # postinstall-Hooks in CI/CD-Builds deaktivieren
npm ci --ignore-scripts

# Danach nur gezielt Scripts ausführen, die bekannt sicher sind

    Zusätzlich: minimumReleaseAge in der npm-Konfiguration aktivieren. Diese Funktion blockiert die Installation von Paketen, die jünger als ein definierter Zeitraum sind — hätte in diesem Fall den Angriff verhindert, da plain-crypto-js weniger als 24 Stunden existierte.

    5. IOCs prüfen

    Netzwerk-Logs und Endpoint-Monitoring auf folgende Indikatoren prüfen:

    • Outbound-Verbindungen zu unbekannten Domains, die am 30./31. März registriert wurden
    • Prozesse namens com.apple.act.mond (macOS), wt.exe (Windows), ld.py (Linux)
    • Registry-Key HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate
    • Dateien in /Library/Caches/com.apple.act.mond

    Präventivmaßnahmen

    Lockfiles konsequent einsetzen

    package-lock.json bzw. yarn.lock sind keine optionale Bequemlichkeit, sondern die wichtigste Verteidigungslinie gegen Supply-Chain-Angriffe dieser Art. In CI/CD immer npm ci statt npm install verwenden — ersteres installiert exakt die im Lockfile festgeschriebenen Versionen.

    Trusted Publishing nutzen

    Beim Axios-Angriff war zwar OIDC Trusted Publishing für die 1.x-Linie konfiguriert, aber ein langlebiger Legacy-Token hatte Vorrang. Prüfen Sie für Ihre eigenen Pakete: Verwenden Sie ausschließlich kurzlebige OIDC-Tokens? Sind Legacy-Tokens widerrufen?

    Dependency-Monitoring etablieren

    Tools wie npm audit, Snyk, Socket oder Dependabot erkennen kompromittierte Pakete oft innerhalb von Minuten. Wer kein automatisches Monitoring hat, erfährt erst durch Zufall oder Medienberichte davon.

    Entwicklungsumgebungen härten

    Entwicklerrechner sind hochwertige Ziele, weil sie typischerweise SSH-Keys, Cloud-Credentials und Repository-Zugang bündeln. Segmentierung, Least-Privilege-Prinzipien und separate Build-Umgebungen reduzieren den Blast Radius erheblich.

    Erweiterte Angriffsfläche: KI-Tools

    Ein oft übersehener Aspekt: KI-gestützte Entwicklungstools wie Claude Code oder OpenAI Codex nutzen ebenfalls npm-Pakete und installieren diese teils automatisiert. Damit erweitert sich die Angriffsfläche über klassische Entwicklerumgebungen hinaus auf alle Arbeitsplätze, an denen solche Tools zum Einsatz kommen — auch bei Nicht-Entwicklern.

    Einordnung

    Dieser Angriff zeigt, wie fragil das Vertrauensmodell im npm-Ökosystem nach wie vor ist. Ein einziger kompromittierter Account — in diesem Fall der des Hauptmaintainers — reicht aus, um Schadcode in hunderttausende nachgelagerte Projekte zu schleusen. Die Attribution zu einer nordkoreanischen APT-Gruppe unterstreicht: Supply-Chain-Angriffe sind kein theoretisches Risiko, sondern ein aktiv genutzter Angriffsvektor staatlicher Akteure.

    Für Unternehmen, die Node.js-basierte Anwendungen entwickeln oder betreiben, ist die konsequente Absicherung der Software-Lieferkette keine Kür mehr — sie ist Pflicht. Wer ein SIEM betreibt, sollte die genannten IOCs in seine Detektionsregeln aufnehmen. Wer keins betreibt, hat ein grundsätzlicheres Problem.

    Sie wollen sicherstellen, dass Ihre Entwicklungs- und Produktionsumgebungen sauber sind? NEOSEC unterstützt Sie bei der forensischen Analyse, dem Incident Response und der nachhaltigen Absicherung Ihrer Software-Lieferkette. Sprechen Sie uns an.

  • ·

    MFA wird nicht gebrochen — sie wird umgangen. Und Ihre Mitarbeiter merken es nicht.

    VonJ. Benjamin Espagné

    Die Illusion der Sicherheit

    Multi-Faktor-Authentifizierung galt jahrelang als Goldstandard. Passwort gestohlen? Kein Problem — der Angreifer braucht noch den zweiten Faktor. Diese Annahme ist überholt.

    Adversary-in-the-Middle (AiTM) Phishing hat die Spielregeln verändert. Diese Angriffe stehlen nicht Passwort und MFA-Code getrennt. Sie fangen die gesamte Authentifizierung in Echtzeit ab — einschließlich des Session-Tokens, der beweist, dass ein Benutzer angemeldet ist.

    Der Mitarbeiter macht alles richtig: prüft auf HTTPS, bestätigt die MFA-Anforderung, vermeidet verdächtige Anhänge. Und wird trotzdem kompromittiert.

    Wie Adversary-in-the-Middle funktioniert

    Klassisches Phishing bedeutete schlampige Fake-Login-Seiten mit Tippfehlern. Diese Seiten konnten MFA nicht umgehen, weil sie keine Verbindung zum echten Authentifizierungsdienst hatten.

    Moderne Phishing-Seiten sind keine Fälschungen — sie sind Proxies. Tools wie Evilginx sitzen zwischen dem Benutzer und dem legitimen Dienst (Microsoft 365, Google Workspace, Okta) und leiten alles in Echtzeit weiter:

    • Der Mitarbeiter gibt sein Passwort ein → Es geht an Microsoft
    • Microsoft sendet die MFA-Challenge → Sie fließt über den Proxy zurück
    • Der Mitarbeiter bestätigt die MFA → Der Session-Cookie wandert zurück durch den Proxy
    • Der Angreifer nimmt den Session-Cookie, öffnet einen Browser auf einem völlig anderen Rechner — und ist drin

    Kein fehlgeschlagener Login-Versuch. Kein MFA-Fatigue-Bombing. Kein Brute-Force-Alert. Alles sieht normal aus, weil es technisch gesehen normal war. Die Authentifizierung war echt — der Angreifer hat nur zugesehen.

    Phishing-as-a-Service macht es zur Massenware

    Das ist längst keine Nation-State-Technik mehr. Phishing-as-a-Service-Plattformen wie Tycoon 2FA, Sneaky2FA und FlowerStorm haben AiTM-Angriffe zur Massenware gemacht. Laut Barracuda werden bis Ende 2026 über 90 Prozent aller Credential-Compromise-Angriffe auf ausgefeilte Phishing-Kits setzen. Die Zahl bekannter Kits hat sich 2025 verdoppelt.

    Man braucht keine Kenntnisse über Reverse Proxies. Man braucht eine Kreditkarte und ein Abonnement.

    Drei Gründe, warum Unternehmen scheitern

    1. Training für die falsche Bedrohung

    Die meisten Security-Awareness-Programme lehren immer noch: Achte auf Tippfehler, prüfe die Absenderadresse, fahre mit der Maus über Links. Das war für Phishing von 2015. Bei AiTM gibt es keine Tippfehler, weil die Seite echt ist. Das SSL-Zertifikat ist gültig. Der Login-Flow verhält sich wie erwartet. Laut Push Security wird inzwischen jeder dritte Phishing-Angriff außerhalb von E-Mail ausgespielt — über LinkedIn-DMs, Google-Suche oder Teams-Nachrichten.

    2. Blindes Vertrauen in Session-Cookies

    Sobald MFA abgeschlossen ist, behandeln die meisten Organisationen die resultierende Session als heilig. Aber Session-Cookies sind Bearer Tokens — wer sie hat, ist der authentifizierte Benutzer. Es gibt keine Bindung zwischen dem Cookie und dem Gerät, das ihn erzeugt hat. Kein Fingerprint. Kein Anker. Forschung von Silverfort zeigt: Selbst nach erfolgreicher FIDO2-Authentifizierung bleiben viele Identity Provider anfällig für Session-Hijacking.

    3. Reaktion auf Credential-Diebstahl, nicht Session-Diebstahl

    Incident-Response-Playbooks sind auf kompromittierte Passwörter ausgelegt: Reset erzwingen, Tokens widerrufen, MFA neu einrichten. Aber bei AiTM ist das Passwort nicht das Problem — die Session ist es. Wer nicht alle aktiven Sessions widerruft und auf Session Replay monitort, behebt die Kompromittierung nicht wirklich.

    Was wirklich hilft: Technische Gegenmaßnahmen

    1. FIDO2 / Passkeys deployen

    FIDO2-Security-Keys und Passkeys binden die Authentifizierung kryptografisch an die spezifische Domain. Kommt die Login-Anforderung von einer Proxy-Domain statt vom echten Dienst, verweigert der Key die Signatur. Das ist der einzige MFA-Mechanismus, der AiTM-Phishing strukturell blockiert.

    Wichtig: Proofpoint hat gezeigt, dass ein Downgrade-Angriff gegen FIDO in Microsoft Entra ID möglich ist, indem ein nicht unterstützter Browser vorgetäuscht wird. Daher: Fallback-Authentifizierungsmethoden deaktivieren, wo immer möglich.

    2. Sessions an Geräte binden (Device Compliance)

    Conditional Access Policies, die verwaltete, konforme Geräte erfordern, schaffen einen Hardware-Anker, den Cookie Replay nicht umgehen kann. Stiehlt jemand einen Session-Cookie und versucht, ihn von einem nicht verwalteten Gerät abzuspielen, wird die Session beendet. Das ist eine der wirksamsten Änderungen, die Organisationen implementieren können.

    3. Geo-Blocking und Country-Based Conditional Access

    Die meisten AiTM-Infrastrukturen operieren aus Regionen, aus denen Ihre Mitarbeiter nie arbeiten. Geo-basierte Conditional Access Policies können Authentifizierungen aus nicht-genehmigten Ländern blockieren oder zusätzliche Verifizierung erzwingen.

    In Microsoft Entra ID lässt sich das über Named Locations und Conditional Access umsetzen: Alle Anmeldungen aus Ländern außerhalb einer definierten Whitelist (z.B. Deutschland, Österreich, Schweiz) werden geblockt oder erfordern ein konformes Gerät. In Kombination mit Device Compliance entsteht ein doppelter Anker: richtiges Land UND richtiges Gerät.

    Einschränkung: Geo-Blocking basiert auf IP-Geolokation, die umgangen werden kann. Angreifer nutzen zunehmend Residential Proxies im Zielland, um Geo-Blocking zu umgehen. Daher ist Geo-Blocking eine nützliche Schicht, aber niemals die alleinige Verteidigung.

    4. Proxy- und VPN-Detection

    Da AiTM-Angriffe über Proxy-Infrastrukturen laufen, ist die Erkennung von Proxy-, VPN- und Tor-Verbindungen eine effektive Abwehrschicht. Mehrere Ansätze:

    • Microsoft Entra ID: Conditional Access kann Anmeldungen von anonymen IP-Adressen (Tor, anonyme Proxies) blockieren. Entra ID Protection erkennt “atypische Anmeldestandorte” und “unmögliche Reisen”
    • IP-Reputation-Services: Dienste wie IPQualityScore, MaxMind, Spur.us oder IPinfo bewerten IP-Adressen nach Risiko — Datacenter-IPs, bekannte Proxy-Provider, Residential-Proxy-Netzwerke
    • Reverse-Proxy-Fingerprinting: AiTM-Proxies hinterlassen Spuren — zusätzliche HTTP-Header, TLS-Fingerprint-Abweichungen (JA3/JA4-Hashes), minimale Latenz-Anomalien. Spezialisierte Anti-Phishing-Lösungen erkennen diese Muster
    • SIEM-Korrelation: Wenn eine erfolgreiche Authentifizierung von einer IP kommt, die als Proxy/VPN/Datacenter klassifiziert ist, und gleichzeitig von einem nicht-konformen Gerät erfolgt — ist das ein hochprioritärer Alert

    5. Session-Anomalie-Monitoring

    AiTM-Angriffe erzeugen keine fehlgeschlagenen Logins. Sie erzeugen perfekt aussehende erfolgreiche. Die Signale liegen in dem, was nach der Authentifizierung passiert:

    • Impossible Travel: Authentifizierungs-IP in München, nächste Aktivität 5 Minuten später aus Moskau
    • Neue MFA-Geräteregistrierung innerhalb von Minuten nach dem Login
    • Inbox-Rule-Erstellung: Angreifer erstellen E-Mail-Weiterleitungsregeln, um Evidenz zu verstecken
    • Massen-Downloads: SharePoint/OneDrive-Zugriffe in ungewöhnlichem Umfang
    • Token-Replay von neuer IP: Dieselbe Session taucht plötzlich von einer anderen IP auf

    6. Continuous Access Evaluation (CAE)

    Microsoft Continuous Access Evaluation ist ein Game-Changer: Statt Sessions bis zum Token-Ablauf laufen zu lassen, werden Änderungen (IP-Wechsel, Risikoerhöhung, Admin-Aktion) in Echtzeit an den Resource Provider kommuniziert. Eine gestohlene Session wird beim ersten IP-Wechsel sofort invalidiert — nicht erst nach einer Stunde.

    CAE ist in Microsoft 365 verfügbar und sollte zusammen mit Token Protection (Preview) aktiviert werden, das Session-Tokens kryptografisch an das Gerät bindet.

    7. Security Awareness neu denken

    Hören Sie auf, Mitarbeitern beizubringen, Phishing-Seiten zu erkennen — gegen moderne Angriffe können sie das nicht. Stattdessen eine einfache Regel:

    Wenn Sie den Login nicht selbst initiiert haben, indem Sie die URL direkt eingegeben haben — vertrauen Sie ihm nicht. Keine Login-Links in E-Mails klicken, auch wenn sie legitim aussehen. Login-Seiten bookmarken. Direkt navigieren.

  • ·

    APIs sind die neue Angriffsfläche — und die meisten Unternehmen sind blind

    VonJ. Benjamin Espagné

    Die Front hat sich verschoben

    „Wir haben früher über Defense-in-Depth und Endpoint Protection gesprochen. Dann kam Identity. Jetzt ist die API das neue Perimeter.“ So beschreibt Sean Murphy, CISO bei BECU, einem der größten US-Kreditinstitute, die aktuelle Lage. Und er steht mit dieser Einschätzung nicht allein.

    In einer aktuellen Erhebung von CSO Online berichten mehrere CISOs übereinstimmend: APIs haben Endpoints als primäre Angriffsfläche abgelöst. Sie sind die Eingangstür zu Backend-Systemen, Partnerschnittstellen und Kundendaten — und in vielen Unternehmen weder inventarisiert noch ausreichend geschützt.

    Die Zahlen: Jede dritte Organisation betroffen

    Ein Salt Security Report von 2025 zeigt:

    • Jede dritte Organisation wurde in den letzten 12 Monaten über eine API kompromittiert
    • 95 % der API-Angriffe kommen von authentifizierten Quellen — über gestohlene API-Keys oder Credentials

    Laut einer Studie von Enterprise Management Associates haben rund 70 % der Unternehmen nur 30 % ihrer APIs dokumentiert. Der Rest? Shadow-APIs, die außerhalb jeder Sicherheits-Governance existieren.

    Konservative Schätzungen gehen davon aus, dass ein Großunternehmen zwischen 250 und 500 APIs betreibt. In der Realität sind es oft Tausende.

    Warum EDR und WAF versagen

    Das Kernproblem: Traditionelle Sicherheitswerkzeuge wie EDR, XDR und WAF sind für API-Angriffe schlicht nicht gebaut. Sie erkennen Malware auf Endpoints und einfache Web-Exploits — aber API-Missbrauch sieht für diese Systeme wie normaler, valider Traffic aus.

    Elliott Franklin, CISO bei Fortitude Re, bringt es auf den Punkt: EDR und WAFs wurden für die Probleme von gestern gebaut. Ohne ein tiefes Verständnis von Business Logic und Identity Context übersehen traditionelle Tools Credential Stuffing, Token-Diebstahl oder Data Scraping.

    API-Angriffe nutzen keine Payload-Patterns, die eine WAF erkennen würde. Sie missbrauchen Business Logic: gebrochene Authentifizierung, übermäßig permissive Autorisierung, exzessive Datenexposition. Einzeln betrachtet sind die Requests valide — erst in der Sequenz entsteht der Angriff.

    James Faxon, Principal Advisor bei der Risk & Insight Group, erklärt: Ein Angreifer braucht keinen Laptop zu kompromittieren und keine Malware zu deployen. Mit einem gestohlenen Token und einer fehlerhaften Autorisierungslogik kann er sich lateral bewegen und Daten extrahieren, ohne traditionelle Endpoint-Controls auszulösen.

    KI verschärft das Problem — auf beiden Seiten

    Chaim Mazal, Chief AI and Security Officer bei Gigamon, warnt: KI hat die Demokratisierung offensiver Tools ermöglicht. Jeder kann jetzt API-Schwachstellen ausnutzen, unabhängig vom Skill-Level — ohne eine einzige Zeile Code zu schreiben.

    Gleichzeitig vergrößert KI die Angriffsfläche von innen: Agentic AI, die autonom über APIs mit Systemen interagiert — einschließlich Model Context Protocol (MCP), Agent-to-Agent-Workflows und automatisierter Integrationen — schafft neue, schwer kontrollierbare Zugriffspfade.

    Eine Studie von Software Finder (2025) zeigt: 56 % der IT-Entscheider erwarten, dass ihr Software-Stack bis 2030 KI-gesteuert sein wird. Mehr KI bedeutet mehr API-Aufrufe, mehr nicht-menschliche Identitäten, mehr Angriffsfläche.

    Die Lieferkette als API-Risiko

    Laut Gartner nutzen 71 % der Unternehmen APIs von Drittanbietern — SaaS-Plattformen, Cloud-Dienste, Partner-Integrationen. Jede dieser Verbindungen ist ein potenzieller Angriffsvektor.

    Patrick Opet, CISO von JPMorganChase, veröffentlichte 2025 einen offenen Brief, in dem er warnte, dass das SaaS-Modell „stillschweigend Cyber-Angreifer ermöglicht“ und eine „substanzielle Schwachstelle schafft, die das globale Wirtschaftssystem schwächt“.

    In der Praxis heißt das: API-Keys und Tokens landen in Repositories, werden nicht rotiert, haben übermäßige Berechtigungen und sind teilweise offen im Web auffindbar. Escape entdeckte 2024 über 18.000 API-Secrets und Tokens im offenen Internet.

    Was CISOs empfehlen

    1. API-Inventar aufbauen

    „Was man nicht sieht, kann man nicht schützen“, sagt Andreas Gaetje, CISO bei Körber. Der erste Schritt ist ein vollständiges Inventar aller APIs — intern, extern, und von Drittanbietern. Jede API braucht einen Owner, eine Dokumentation und eine Threat-Model-Bewertung.

    2. API Governance einführen

    BECU implementierte eine einheitliche API-Policy für alle Entwickler — noch bevor die Technologie ausgerollt wurde. Jeder API-Builder unterliegt derselben internen Richtlinie. Das reduziert Fehlkonfigurationen, die laut OWASP Top 10 das größte API-Risiko darstellen.

    3. Identity-basierte Absicherung

    APIs als „nicht-menschliche Identitäten“ behandeln: Least-Privilege-Prinzip, zeitgebundene RBAC, regelmäßige Token-Rotation. Fortitude Re integriert API-Sicherheit direkt in die IAM-Strategie und trackt aktiv nicht-menschliche Identitäten.

    4. Security in die CI/CD-Pipeline

    API-Spezifikationen müssen automatisierte Sicherheitsvalidierung durchlaufen, bevor sie deployed werden. Infinite Computer Solutions hat Security-Checks direkt in die CI/CD-Pipeline eingebettet.

    5. Verhaltensbasiertes Runtime-Monitoring

    Wenn ein API-Consumer außerhalb seines erwarteten Musters agiert, ist das ein Security Event, keine technische Anomalie. Runtime-Erkennung ist die einzige Verteidigung, die bei Zero-Day-Exploitation funktioniert.

    6. Third-Party-APIs wie Risiken behandeln

    Credentials von Drittanbietern zentralisieren und verschlüsseln. Niemals rohe API-Keys an Entwicklungsteams verteilen. Regelmäßig rotieren und auf Behavioral Drift überwachen.

  • · ·

    Wenn Berechtigung zur Schwachstelle wird – Das Zeitalter des Authorization Sprawl

    VonDr. Anatolii Nazarko

    Die Ergebnisse des aktuellen SANS Whitepapers von Joshua Wright „Authorization Sprawl – The Vulnerability Reshaping Modern Attacks“ (Oktober 2025) zeigen eindrucksvoll, wie sich eine unscheinbare Sicherheitslücke zum größten Risiko moderner IT-Landschaften entwickelt hat.

    Unter Authorization Sprawl versteht man die unkontrollierte Ausbreitung von Zugriffsrechten über Systeme, Cloud-Dienste, SaaS-Anwendungen und Identitätsplattformen hinweg. Durch die zunehmende Integration von SSO, API-Tokens und föderierten Identitäten entstehen unzählige „Seitentüren“ ins Unternehmensnetz.

    Während Authentifizierung (Login, MFA, EDR) in den letzten Jahren stark verbessert wurde, hinkt die Kontrolle der Autorisierung weit hinterher. Angreifer nutzen diese Schwäche gezielt aus: Ein kompromittierter Account, ein offener Token, ein vergessenes Servicekonto – und schon ist der Weg frei für Datenexfiltration, lateral movement und Privilegienausweitung.

    Bekannte Gruppen wie Scattered Spider, LAPSUS$ oder ShinyHunters setzen diese Methode inzwischen systematisch ein. Sie kombinieren Social Engineering, gestohlene OAuth-Tokens und API-Schlüssel mit SaaS-Schwachstellen – und umgehen damit klassische Schutzsysteme völlig unbemerkt.

    Die Untersuchung von SANS zeigt:

    • Moderne EDR-Systeme erkennen diese Angriffe nicht, weil sie innerhalb legitimer Prozesse stattfinden (z. B. Browser, AWS- oder M365-Sessions).
    • VPNs und lokale Proxys verschleiern Geodaten und umgehen Impossible Travel Detection.
    • Viele SaaS-Anbieter bieten nur rudimentäres oder kostenpflichtiges Logging, was Incident Response massiv erschwert.

    Kurz gesagt: Wir haben gelernt, wer sich anmeldet – aber nicht, was er danach tut.

  • Ist der erste Februar ein guter Tag für die Cybersicherheit?

    VonJuliane Heinen

    Kürzlich ist ein interessanter Tag in Bezug auf die IT-Sicherheit verstrichen, auf dessen Symbolkraft ich näher eingehen möchte. Im Jahr 2012 wurde der 1. Februar zum Nationalen Tag der Passwortzurücksetzung erklärt. Dieser Tag soll die Menschen an die Bedeutung des Passwortschutzes erinnern. Ist dies noch sinnvoll?

    Dieser Tag soll die Menschen dazu ermutigen, alle ihre Passwörter zu ändern, was die Sicherheit erhöhen soll. Aber wenn man so viele Passwörter ändern muss, erstellen die Leute sie in der Regel nach bestimmten Mustern oder, was noch schlimmer ist, sie verwenden überall dasselbe Passwort. Passwörter sollten unterschiedlich und sicher sein und an einem sicheren Ort aufbewahrt werden!

    Da es unmöglich ist, sich alle Passwörter zu merken, geschweige denn solche, die sich ständig ändern, bewahren die Menschen sie an unsicheren Orten auf. Zum Beispiel auf einem Blatt Papier unter der Tastatur. Wenn dies auf Sie oder Ihre Kollegen zutrifft, ändern Sie das Passwort sofort und werfen Sie den Zettel weg!

    Aber wie bewahren Sie Ihre Passwörter sicher auf?

    Sie sollten einen Passwort-Manager wie Bitwarden verwenden und Ihre Passwörter nicht nach einem Kalender ändern. Ja, sie müssen gelegentlich aktualisiert werden, aber nicht unbedingt einmal im Jahr oder noch öfter. Es ist sehr wichtig, Ihr Passwort zu ändern, wenn es möglicherweise durch eine Sicherheitsverletzung kompromittiert wurde oder wenn seine Länge nicht mehr den modernen Standards entspricht. Außerdem sollten Sie nie zweimal dasselbe Passwort verwenden.

    Passwortmanager verfügen über gute Passwortgeneratoren, die lange und zufällige Passwörter erstellen, welche Angreifer nicht erraten können. Auch die Verwendung von Passwörtern ist einfach: Sie können das Passwort mit ein paar Klicks kopieren oder eine Browsererweiterung verwenden, die Sie zur Verwendung des Passworts auffordert.

    Das einzige Passwort, das Sie sich merken müssen, ist das Master-Passwort. Es sollte sicher aufbewahrt und separat gelagert werden. Mit diesem Passwort erhalten Sie Zugang zum Tresor.

    Ein komplexes und nicht kompromittiertes Passwort ist viel besser als ein ständiger Wechsel von einfachen und unsicheren Passwörtern. Verwenden Sie einen Passwort-Manager und bleiben Sie sicher! Für die Einrichtung eines Passwort-Tresors für Organisationen kontaktieren Sie uns.

  • ·

    Verwaltung der Zugänge der Mitarbeiter?

    VonJuliane Heinen

    Kürzlich veröffentlichte der Twitter-Account der New York Post mehrere feindselige Tweets. Sie wurden noch am selben Tag gelöscht und das Unternehmen behauptete, das Konto sei gehackt worden. Später stellte sich jedoch heraus, dass sie von einem Mitarbeiter eingestellt worden waren. Es wird behauptet, dass er bereits entlassen worden ist. Dieser Fall wirft jedoch die Frage auf, warum dieser Mitarbeiter Zugang zum Twitter-Konto der Zeitung hatte. Denn er war nicht für die Veröffentlichung von Inhalten in diesem Netz verantwortlich.

  • Phishing – Definition, Erklärung und Schutz

    VonJuliane Heinen

    Phishing ist eine betrügerische Nachricht, die darauf abzielt, Anmeldedaten zu stehlen, eine finanzielle Transaktion durchzuführen oder Zugang zu internen Systemen zu erhalten.

    Diese Art von Cyberangriffen ist die häufigste. Es gibt sie schon, seitdem es das Internet gibt und wird uns voraussichtlich auch in der Zukunft beschäftigen. Die Angriffsmethode des Phishing fällt unter das “Social Engineering”, d. h. sie beruht auf menschlichem Versagen. Und das passiert leider recht häufig.

    Die Hacker geben sich als bekanntes Unternehmen oder als eine andere Person, z. B. als Chef aus oder leiten ihre Opfer auf eine gefälschte Website. Einem Bericht von Check Point zufolge waren die am häufigsten für Phishing-Angriffe verwendeten Marken Microsoft, DHL und LinkedIn. Fast die Hälfte aller Phishing-Angreifer weltweit gaben sich als zugehörig zu diesen Unternehmen bzw. Netzwerken aus.

    Das ist auch nicht verwunderlich, denn diese Dienste gehören zu den beliebtesten der Welt, werden von vielen Menschen und Unternehmen genutzt und erscheinen vertrauenserweckend. Das bedeutet, dass eine E-Mail von einem solchen Unternehmen kaum Verdacht erregt, sodass die Angreifer mehr Möglichkeiten haben, die Opfer zu manipulieren.

    Es gibt verschiedene Anzeichen, an denen man Phishing-Nachrichten erkennen kann.

    Das erste Zeichen ist ein dringlicher Bedarf. Die Hacker wollen Sie davon überzeugen, dass Sie beispielweise so schnell wie möglich Ihr Passwort ändern, eine Transaktion durchführen, neue Datenschutzbestimmungen bestätigen müssen. Unter Zeitdruck entstehen weniger Zweifel an der Glaubwürdigkeit und Informationen werden weniger überprüft.

    Das zweite Anzeichen für Phishing können Fehler im Link oder Absender sein. Angreifer können Mails von einer Mailbox mit einem Namen aus einer Reihe von Zeichen oder mit einem Namen, der dem Firmennamen ähnelt, aber leicht verändert oder mit Fehlern versehen ist, versenden. Hacker wissen auch, dass dies alarmierend sein kann, und versuchen daher, dieses Vorgehen mit Linkverkürzern oder durch Ausnutzung anderer legitimer Funktionen zu verbergen.

    Das dritte Anzeichen sind Tippfehler im Text der Nachrichten, ein für dieses Unternehmen oder diese Person ungewöhnlicher Stil oder eine ungewöhnliche Anfrage. Ungewöhnliche E-Mails sollten Sie mit gesunder Skepsis betrachten und durch einen Anruf bei dem Unternehmen oder der Person überprüfen. Oder prüfen Sie, ob entsprechendes Schreiben über einen anderen zusätzlichen Kommunikationskanal versendet wird.

    Leider stehen auch die Angreifer nicht still und entwickeln ihre Werkzeuge weiter. Sie erstellen Anhänge und Links, die keinen Verdacht erregen, und erstellen immer überzeugendere E-Mails und vollständige Kopien von Websites. Das Hijacking (Übernahme von Kontrolle) von Konten trotz Zwei-Faktor-Authentifizierung und die Schaffung von Phishing-as-a-Service-Plattformen, über die wir bereits berichtet haben, können die Folge sein.

    Es ist notwendig, einen besseren Schutz zu verwenden

    Es besteht ein zunehmender Bedarf an komplexeren Sicherheitswerkzeugen als Reaktion auf die immer raffinierteren Angriffsmethoden. Zusätzlich zu den bereits üblichen Firewalls sollten die Mitarbeiter davor gewarnt werden, Anmeldeinformationen weiterzugeben oder Links und Anhänge zu öffnen. Die Systeme sollten so eingerichtet sein, dass sie E-Mails filtern und Anhänge und Links in einer sicheren, getrennten Umgebung öffnen. Ersteres schützt die Mitarbeiter vor dem Empfang der meisten Phishing-E-Mails, letzteres vor dem Hijacking und der Verschlüsselung aller Computerinhalte.

    Für Unternehmen wird es immer schwieriger, solche Maßnahmen aus eigener Kraft umzusetzen. Daher ist die Einbeziehung von Informationssicherheitsexperten unumgänglich.

    Wir bieten Schutz vor verschiedenen Arten von Angriffen, einschließlich Phishing. Der Schutz Ihres Unternehmens wird so schnell wie möglich nach den Bedürfnissen des Unternehmens konfiguriert. Und, was am wichtigsten ist, in Übereinstimmung mit neuen Herausforderungen aufrechterhalten. https://neosec.eu/angebot/index.html

    Wir bieten auch Schulungen für Ihre Mitarbeiter zur Erkennung von Phishing-E-Mails an, nicht nur theoretisches Wissen, sondern wir führen auch Simulationen von Phishing-Angriffen durch, um das Bewusstsein der Mitarbeiter des Unternehmens zu beurteilen. Falls Sie sich über die Sicherheit von Anhängen nicht sicher sind, aber keine wichtigen Informationen verpassen wollen, dann können sie diesen Anhang in unserem sogenannten “Giftschrank” hochladen, und wir werden diesen auf Malware überprüfen.

    Für einen wirksamen Schutz vor Phishing ist es heute also notwendig, verschiedene Tools einzusetzen. Diese Tools sind unterschiedlich komplex und zielen darauf ab, Phishing-Nachrichten auf unterschiedliche Weise zu erkennen, um den höchsten Sicherheitsstandard zu gewährleisten.

Keine weiteren News.

Keine weiteren News.

Sicherheitslücken schließen. Risiken senken. Jetzt handeln!

Unsere Experten zeigen Ihnen live, wie wir Angriffe erkennen, stoppen und Ihr Unternehmen schützen.

Blog

Aktuelle Sicherheitsereignisse