Der Mensch ist Schicht 8 des ISO-OSI-Modells, das mit dem Application Layer endet. Keine Firewall schützt ihn. Kein Patch schließt seine Schwachstellen. Und genau deshalb ist er das bevorzugte Einfallstor für professionelle Angreifer:innen.

Laut dem Verizon Data Breach Investigations Report ist menschliches Verhalten in rund 68 Prozent aller erfolgreichen Sicherheitsvorfälle ein entscheidender Faktor. Der Mensch wird nicht angegriffen, weil Technik fehlt. Er wird angegriffen, weil er reagiert. Weil er hilft. Weil er Autorität respektiert. Weil er unter Zeitdruck entscheidet. All das sind keine Fehler, das sind menschliche Eigenschaften, die Angreifer:innen gezielt ausnutzen.

Eine Sicherheitsstrategie, die auf technische Maßnahmen reduziert bleibt, baut auf einem Fundament mit einer bekannten, unbehobenen Lücke.

Wie Social Engineering funktioniert und warum es so effektiv ist

Social Engineering bezeichnet die gezielte Manipulation von Menschen, um sie zu Handlungen zu bewegen, die sie andernfalls nicht ausführen würden. Das Prinzip ist so alt wie Betrug selbst. Die Umsetzung hat sich professionalisiert.

Angreifer:innen nutzen eine Handvoll psychologischer Mechanismen, die in der Verhaltenspsychologie gut dokumentiert sind. Autorität: Eine E-Mail im Namen der Geschäftsführung löst andere Reaktionen aus als eine von einem Unbekannten. Dringlichkeit: Wer in 10 Minuten handeln muss, prüft nicht mehr kritisch. Vertrauen durch Kontext: Eine Nachricht, die auf ein laufendes Projekt Bezug nimmt, wirkt legitim. Reziprozität: Wer etwas bekommt, gibt leichter.

Ein konkretes Beispiel zeigt die Wirkung: Der Automobilzulieferer Leoni AG verlor 2016 über 40 Millionen Euro, weil eine Mitarbeiterin auf eine CEO-Fraud-E-Mail hereinfiel, also eine gefälschte Anfrage der Geschäftsführung. Kein Schadcode, kein Exploit. Nur eine gut formulierte E-Mail und ein Vorgang, der ungeprüft ausgeführt wurde.

KI hat diese Angriffsmethodik in den letzten zwei Jahren qualitativ verändert. Sprachmodelle generieren fehlerfreie, kontextsensitive Phishing-Mails in Sekunden, personalisiert auf Basis öffentlich verfügbarer Informationen über Zielpersonen. Deepfake-Sprachnachrichten imitieren Vorgesetzte. Die Hürde für überzeugend gemachte Social-Engineering-Angriffe ist gesunken.

Warum einmalige Schulungen nicht wirken

Einmal im Jahr ein Pflichttraining absolvieren und anschließend eine E-Mail-Bestätigung versenden: Dieses Modell ist in vielen Unternehmen noch Standard. Es erfüllt formal eine Anforderung. Es verändert kein Verhalten. Das Problem liegt in der Lernpsychologie. Wissen, das nicht aktiviert wird, verblasst. Handlungssicherheit entsteht durch Wiederholung, durch das Erleben von Situationen, und durch unmittelbares Feedback. Ein einmaliges Webinar über Phishing-Erkennung schafft das nicht.

Hinzu kommt: Angriffe werden nicht seltener, sondern häufiger. Wer seine Mitarbeitenden einmal im Jahr sensibilisiert, schickt sie elf Monate unvorbereitet ins Feld.

Studien zeigen, dass Klickraten bei simulierten Phishing-Mails mit kontinuierlichem Training von rund 34 Prozent auf etwa 5 Prozent sinken können. Der Effekt entsteht nicht durch Information, sondern durch das wiederholte Erleben, Erkennen und Melden von Angriffen in einer sicheren Trainingsumgebung.

Was wirksame Security Awareness ausmacht

Drei Eigenschaften unterscheiden Awareness-Programme, die Verhalten verändern, von solchen, die Compliance-Boxen abhaken.

Security Awareness als regulatorische Pflicht

NIS2 und ISO 27001 sind keine optionalen Rahmenbedingungen mehr für die meisten Unternehmen im DACH-Raum.

ISO 27001 verlangt in Annex A, Kontrolle 6.3, ausdrücklich ein Awareness-Programm für alle Mitarbeitenden, das relevante Bedrohungen und Verhaltenserwartungen adressiert. Kein zertifizierter ISMS-Betrieb ohne nachgewiesene Schulungsmaßnahmen.

NIS2, umgesetzt im deutschen NIS2UmsuCG, fordert in Artikel 21 Maßnahmen zur Sensibilisierung der Mitarbeitenden als expliziten Bestandteil des Risikokonzepts. Betreiber wesentlicher und wichtiger Einrichtungen, und das sind nach NIS2 deutlich mehr Organisationen als nach der Vorgängerrichtlinie, müssen Awareness-Maßnahmen nachweislich umsetzen und dokumentieren.

Wer Security Awareness nur als Nice-to-Have behandelt, riskiert damit nicht nur Sicherheitsvorfälle, sondern auch Compliance-Lücken mit regulatorischen Konsequenzen.

Fazit

Kein Unternehmen ist zu klein, um Ziel von Social Engineering zu sein. Und kein technisches Schutzkonzept ist vollständig, solange der menschliche Faktor unbehandelt bleibt. Wer Security Awareness kontinuierlich, verhaltenspsychologisch fundiert und messbar umsetzt, reduziert seine Klickrate nachweislich, erfüllt NIS2- und ISO-27001-Anforderungen mit auditfähiger Evidenz, und macht aus dem schwächsten Glied der Sicherheitskette eine aktive Verteidigungslinie.

Schicht 8 lässt sich nicht patchen. Sie lässt sich trainieren.

friends of carmasec

Ein Abend, bei dem der offene Austausch im Mittelpunkt steht. Einmal im Quartal treffen sich im Mediapark Köln Menschen aus der IT-Security mit unterschiedlichen Hintergründen. Was sie verbindet: die geteilte Überzeugung, voneinander zu lernen, Themen offen zu besprechen und persönliche Kontakte zu vertiefen.

Drei Praxis-Talks à 10 Minuten, echter Branchen-Dialog und Zeit zum Netzwerken – in einer offenen und persönlichen Atmosphäre. Für alle, die Cybersicherheit und ISMS wirklich ernst nehmen.

Werde Teil einer wachsenden Community und melde dich gleich an. Wir freuen uns auf dich.

Ein global tätiger Elektronikhersteller muss seinen gesamten Entwicklungsprozess auf den Cyber Resilience Act ausrichten. Keine kritischen Produkte, aber komplexe Strukturen, historisch gewachsene Prozesse und Kompetenzlücken in mehreren Abteilungen. Was folgt, ist kein Compliance-Projekt. Es ist ein Neustart der Produktsicherheit.

Ausgangssituation: Viel Unsicherheit, wenig Zeit

Durch das Inkrafttreten des Cyber Resilience Acts (CRA) muss ein global tätiger Hersteller smarter Haushaltsgeräte mit Sitz in Deutschland die Cybersicherheit seiner Produkte mit digitalen Elementen/Komponenten auch für die gesamte Produktlebensdauer sicherstellen. Es herrschte zunächst große Unsicherheit, welche Bedeutung genau der CRA für ein digitales Produkt hat und wie sich das mit bestehenden Produkt- & Softwareentwicklungsprozessen vereinbaren lässt. Unklar war ebenfalls, welche Produkte (nicht) vom CRA betroffen und welche Anforderungen des CRA bereits (teilweise) umgesetzt sind.

Der Hersteller beauftragte unser fachübergreifendes Expertenteam, eine holistische Strategie zur Erreichung der CRA-Compliance zu entwickeln, um fortan ein hohes Niveau an Cybersicherheit entlang des gesamten Lebenszyklus der digitalen Produkte zu erreichen.

Herausforderungen

Historisch gewachsene Prozesse

Die bisherigen Prozesse des Herstellers zur Produkt- und Softwareentwicklung haben sich teilweise über einen langen Zeitraum hinweg sowie uneinheitlich entwickelt. Außerdem wurden Aspekte der Cybersecurity bisher nicht sonderlich stark oder nur vereinzelt bedacht.

Komplexe Unternehmensstruktur

Die Komplexität der Unternehmensstruktur unseres global tätigen Kunden stellt eine weitere Herausforderung dar. So besteht das Unternehmen aus zahlreichen autarken Abteilungen mit teils geringen Kommunikationsschnittstellen zueinander. Cybersecurity wurde bisher nur in wenigen Abteilungen, und dort jeweils sehr unterschiedlich, berücksichtigt.

Ressourcen und Kompetenzen

Die für die Umsetzung des Cyber Resilience Act (CRA) erforderlichen personellen und finanziellen Ressourcen sowie das notwendige Fachwissen waren sehr unterschiedlich in den Abteilungen vorhanden und fehlten an einigen Stellen ganz. Infolgedessen herrschte große Unsicherheit über die erforderlichen Maßnahmen, um den Anforderungen des CRA zu entsprechen.

Integration mit anderen Regularien und unternehmensinternen Vorgaben

Da auch andere nationale, europäische und internationale Regularien auf das Unternehmen einwirken, sind Überschneidungen und Dopplungen zwischen diesen nicht bekannt und einbezogen. Außerdem decken unternehmensinterne Vorgaben diese Regularien teilweise bereits ab oder behindern deren Erfüllung. Eine Harmonisierung dieser Regularien und Vorgaben fand noch nicht statt.

Um diesen Herausforderungen zu begegnen und Lösungen zu entwickeln, wurden unser CRA Cybersecurity Expertenteam beauftragt.

Vorgehen: Strukturiert, Schritt für Schritt

Betroffene Produkte und Regularien identifizieren

Der erste Schritt für eine erfolgreiche Einführung des CRA bestand darin, die betroffenen Produkte zu identifizieren. Dafür musste das gesamte Portfolio sowie die komplexe Struktur des Unternehmens analysiert und die Produkte die unter den CRA fallen identifiziert werden. Bei der Überprüfung erfolgte außerdem eine Analyse, ob der Kunde oder das Produkt gegebenenfalls auch unter andere relevante Regularien (NIS-2 oder RED – Radio Equipment Directive) fällt.

Diese Einordnung diente als Basis für die weiteren Schritte.

Verantwortlichkeiten und Budget klären

Nach der Identifikation der betroffenene Produkte wurde gemeinsam eine klare Zuweisung von Verantwortlichkeiten erarbeitet. Dabei wurden Rollen für die Umsetzung des CRA innerhalb des Unternehmens definiert und auf der Managementebene Sichtbarkeit für das Thema erzielt. Gleichzeitig wurde das benötigte Budget für die Umsetzung der Anforderungen des CRA abgeschätzt und so berechnet, dass genug Ressourcen und Kompetenzen für die Umsetzung zur Verfügung stehen. Bei der Budgetplanung wurden sowohl die einmaligen als auch die laufenden Kosten berücksichtigt. Ein klar definiertes Budget ermöglichte eine realistische und effiziente Umsetzung der Sicherheitsmaßnahmen.

Zum Abschluss der Planung wurde der weitere zeitliche Ablauf definiert, um die wichtigen Fristen der EU einzuhalten und Verzögerungen bei den Releases neuer Produkte zu vermeiden. Da sich das Unternehmen rechtzeitig mit dem CRA auseinandersetzte, entstanden keine größeren Verzögerungen.

Soll/Ist Analyse der Anforderungen des CRA

Nun wurden bei einer Soll-Ist-Analyse die bestehenden Sicherheitsmaßnahmen des Unternehmens und der Produkte mit den Anforderungen des CRA verglichen und Lücken identifiziert. Durch eine Dokumentenprüfung, fachliche Interviews mit Ansprechpartnern sowie Sichtung von Auditberichten kamen wir zu folgenden Ergebnissen:

Die Produkte des Unternehmens verfügten schon über die grundlegenden Sicherheitsmechanismen, jedoch waren die Strukturen und Prozesse im Unternehmen nicht auf die neuen Anforderungen des CRA ausgerichtet. Es existierten zwar Maßnahmen wie Software-Updates und Zugriffskontrollen, doch dem Produktlebenszyklus fehlte ein systematisches Sicherheitskonzept nach dem Prinzip Security by Design. Die Sicherheitsaspekte wurden nicht bereits in der Entwurfsphase beachtet, sondern erst kurz vor oder sogar erst nach dem Release der Produkte. Außerdem fehlte manchen Produkten das Prinzip Security by Default, da sie mit einem Standardpasswort ausgeliefert wurden. Die Software-Updates wurden aufgrund von mangelnden technischen Möglichkeiten nicht über den kompletten Lebenszyklus der Geräte verfügbar gemacht, sondern wurden oft bereits nach 3 Jahren eingestellt. Zudem wurde festgestellt, dass dem Unternehmen die Prozesse und die Infrastruktur für das geforderte Incident Response Management und Security Monitoring fehlten. Die Mitarbeitenden waren nur teilweise im Bereich Cybersicherheit geschult. Die Dokumentationen (allgemeine Produktbeschreibung, Risikobewertungen und angewandte Normen) des Unternehmens waren teilweise vorhanden, es fehlte jedoch die geforderte SBOM (Software Bill of Materials).

Diese Ergebnisse wurden dann in einem Bericht zusammengefasst, um dem Kunden einen transparenten Überblick über seinen aktuellen Stand zu geben. Das Ergebnis zeigte auf, welche Maßnahmen bereits konform waren und welche Maßnahmen im weiteren Verlauf noch eingeführt werden müssten. Auf der Basis des Berichts wurden konkrete Handlungsempfehlungen formuliert.

Risiken innerhalb der betroffenen Produkte analysieren

Nach der Soll-Ist-Analyse wurde eine detaillierte Risikoanalyse durchgeführt. Es wurden potenzielle Sicherheitsrisiken für die Produkte evaluiert. Dabei wurden klassische Schwachstellenanalysen mit Threat-Informed Defense (TID) kombiniert, um eine fundierte Priorisierung der erforderlichen Sicherheitsmaßnahmen vorzunehmen.

Außerdem wurden bei einigen Produkten Penetrationstests durchgeführt mit dem Ziel, die kritischen Schwachstellen der Produkte zu identifizieren. Wir vervollständigten auf diese Weise unser Bild vom Unternehmen. Auf Grundlage der gewonnenen Erkenntnissen nahmen wir eine Priorisierung der erforderlichen Sicherheitsmaßnahmen vor und sie flossen in unsere Handlungsempfehlungen ein.

Umsetzung identifizierter Maßnahmen (prozessual & technisch)

Die erste durchgeführte Maßnahme war die Schulung des relevanten Personals. Neben dem vermittelten Wissen hatte dies den Nebeneffekt, dass wir die Mitarbeitenden besser in die Umsetzung der Maßnahmen einbeziehen konnten.

Eine besondere Herausforderung stellten die historisch gewachsenen Produkt- und Softwareentwicklungsprozesse dar, die über Jahre hinweg ohne einheitliche Sicherheitsstrategie entstanden waren. Diese haben wir angepasst, indem wir strukturierte Security by Design Prinzipien eingeführt und somit einen sicheren Produktentwicklungsprozess und Lebenszyklus eingeführt haben. Die Produktsicherheit wird im Unternehmen nun schon ab der Designphase in allen Phasen des Produktslebenszyklus berücksichtigt. Dabei wurde auch miteinbezogen, dass die Sicherheitsupdates für Produkte nun der Lebensdauer der Produkte entsprechen müssen. Die Technik wird so gewählt, dass sie auch nach 5 Jahren noch Sicherheitsupdates erhalten kann.

Darüber hinaus führte das Unternehmen mit unserer Unterstützung eine neue Continuous Integration und Continuous Delivery (CI/CD) Pipeline mit automatisierten Sicherheitsprüfungen ein. Dazu wurde eine Application Security Platform eingeführt, die den Code der Entwickler automatisch überprüft und schon während der Programmierung Schwachstellen im Code und in Bibliotheken meldet. Außerdem kann dieses Programm die vom CRA geforderte SBOM für die gesamte entwickelte Software des Unternehmens erstellen.

Zeitgleich wurde ein Incident Response Team im Unternehmen eingerichtet und die Infrastruktur für Incident Response Management und Security Monitoring geschaffen. Das Unternehmen ist jetzt in der Lage, innerhalb von maximal 24 Stunden Schwachstellen und Sicherheitsvorfälle zu melden. Es kann schnell auf interne, sowie externe Meldungen reagiert werden und den Nutzern Sicherheitsupdates für ihre Produkte zur Verfügung gestellt werden.

Aufgrund der neuen Prozesse und des neuen Sicherheitsdenkens erfüllen die Produkte jetzt die Prinzipien Security by Design & Default.

Durchführung der Konformitätsbewertung

Das Unternehmen hatte keine kritischen Produkte, somit konnte die Konformitätsbewertung vom Unternehmen selbst durchgeführt werden, es brauchte keine Evaluation durch einen Dritten. Bei der Selbstevaluation unterstützten wir das Unternehmen und konnten die CE Kennzeichnung für die neuen Produkte erlangen, sodass diese ohne Verzögerung nach Dezember 2027 auf den EU-Markt kommen können.

Mehrwert

Dank des tiefgehenden Fachwissens unseres CRA Cybersecurity Expertenteams sowie unserer langjährigen Erfahrung im Bereich der Product Security und der sicheren Softwareentwicklung waren wir in der Lage, die spezifischen Herausforderungen unseres Kunden sowie der einzelnen Organisationseinheiten genau zu erfassen und passgenaue Lösungen zu erarbeiten.

Neben unserer transparenten und ganzheitlichen Herangehensweise trugen auch eine enge kundenorientierte Kommunikation und Flexibilität maßgeblich zum Erfolg bei. Durch eine gründliche Bewertung des bestehenden Reifegrads in den Abteilungen sowie eine umfassende Aufklärung über gesetzliche Vorgaben verschafften wir dem Kunden einen klaren Überblick und förderten sein Sicherheitsbewusstsein.

Bei carmasec legen wir großen Wert auf eine enge Zusammenarbeit mit unseren Kunden. Durch ausführliche zielgerichtete Interviews und die Einbindung aller relevanten Stakeholder konnten wir in diesem Projekt ein tiefgehendes Verständnis für die spezifischen Herausforderungen erzeugen. So war es uns möglich, maßgeschneiderte Empfehlungen zu erarbeiten, um die Erfüllung des CRA und weiterer kundenspezifischen Anforderungen sicherzustellen. Dabei setzten wir auf einen integrativen Ansatz mit unseren Open Source Security Experten, der sowohl in der Strategieentwicklung als auch bei der Definition konkreter Maßnahmen berücksichtigt wurde. Neben der Analyse und Bewertung unterstützten wir auch die praktische Umsetzung, indem wir den Kunden befähigten, nachhaltige und praxisnahe Product Security-Strukturen aufzubauen. Gemeinsam definierten wir Rollen und Verantwortlichkeiten und entwickelten eine Roadmap für die Implementierung von Sicherheitsmaßnahmen, wie die Integration von Security-Schritten in den Entwicklungsprozess, die Definition von Secure Coding Standards und die Einführung eines Prozesses für Vulnerability- und Incident-Management. Zusätzlich standen wir als Experten bei der Erstellung erforderlicher Dokumentationen und Prozesse beratend zur Seite.

Binnen eines Jahres haben wir die Rahmenbedingungen für CRA festgelegt und sowohl einen sicheren Entwicklungsprozess als auch ein umfassendes Vulnerability Management mitsamt der CRA-Meldepflichten implementiert.

Dies ersparte dem Kunden die Herausforderung, schwer verfügbare Expert:innen zu rekrutieren, und ermöglichte ihm stattdessen, internes Wissen gezielt aufzubauen. Dadurch konnte er Product Security effektiv implementieren und die Weichen für sichere Produkte von morgen stellen.

Fazit

Compliance mit dem Cyber Resilience Act ist kein einmaliges Projekt. Sie ist eine Strukturfrage. Unternehmen, die Sicherheit spät im Entwicklungsprozess einbauen, zahlen zweimal: einmal für die Nachrüstung, einmal für den Zeitverlust.

Dieses Projekt zeigt, was möglich ist, wenn früh angefangen wird. Security by Design als Prinzip. Eine SBOM als Grundlage. Incident Response als Infrastruktur. Und ein Team, das die Anforderungen nicht von außen aufgedrückt bekommt, sondern versteht, warum sie sinnvoll sind.

Das Ergebnis ist kein abgehaktes Compliance-Dokument. Es ist ein Produktentwicklungsprozess, der ab sofort sicher startet.

FAQ zur CRA-Umsetzung in der Praxis

Dein Team steht vor ähnlichen Fragen?

Unser Team unterstützt dich von der ersten Bestandsaufnahme bis zur CE-Kennzeichnung. Kompetent, direkt und ohne Umwege.

Erstgespräch vereinbaren

Über das Whitepaper

Lade dir dein Whitepaper herunter um dein Unternehmen rechtssicher aufzustellen und sensible Geschäftsgeheimnisse zu schützen

So gelangst du zu deinem kostenlosen Whitepaper:

1. Fülle das Formular aus und klicke auf „senden“.
2. Schaue in deine Mail und bestätige deine E-Mail-Adresse.
3. Du bekommst von uns eine E-Mail mit dem Download-Link.

Lade dir dein Whitepaper herunter und entgehe der Betrugsmasche

So gelangst du zu deinem kostenlosen Whitepaper:

1. Fülle das Formular aus und klicke auf „senden“.
2. Schaue in deine Mail und bestätige deine E-Mail-Adresse.
3. Du bekommst von uns eine E-Mail mit dem Download-Link.

Lade dir deine Checkliste herunter und erhalte Klarheit über dein Risikomanagement

So gelangst du zu deiner kostenlosen Checkliste:

1. Fülle das Formular aus und klicke auf „senden“.
2. Schaue in deine Mail und bestätige deine E-Mail-Adresse.
3. Du bekommst von uns eine E-Mail mit dem Download-Link.

Red Teaming Assessments werden eingesetzt, um die Abwehrmechanismen eines Unternehmens gegen gezielte Angriffe zu überprüfen und zu verbessern. Sie simulieren reale Bedrohungsszenarien, um Schwachstellen zu identifizieren und die tatsächliche Effektivität von Sicherheitsmaßnahmen sowie Reaktionsprozessen zu bewerten.
In dieser Case Study stellen wir die Ergebnisse eines Red Teaming Assessments bei einem unserer Kunden vor. Dieses wurde von unseren Kollegen Timo Sablowski, Senior Security Consultant und Pascal Waffenschmidt, Security Consultant, durchgeführt.

Zusätzlich sollten die Incident Response Prozesse des Kunden getestet werden, sobald unser Angriff entdeckt würde. Die Mitarbeitenden der Security-Abteilung wurden deshalb nicht eingeweiht, um ein realistisches Szenario zu simulieren. Als Testobjekt diente ein regulär konfigurierter Arbeitslaptop mit einem normal eingerichteten E-Mail-Konto. Für unser Assessment wählten wir zusammen mit dem Kunden einen „assumed breach“-Ansatz. Hierbei wird davon ausgegangen, dass Social Engineering-Angriffe zu einem bestimmten Zeitpunkt immer erfolgreich sind und Angreifer mit ausreichendem Aufwand immer ein System infiltrieren können.

Vorbereitung der Angriffssimulation

Die Vorbereitung der Angriffssimulation erfolgte in drei sorgfältig geplanten Schritten.

1. Abstimmung der TTPs gemäß dem Mitre ATT@CK Framework

Zu Beginn stimmten wir gemeinsam mit unserem Kunden die zu testenden Taktiken, Techniken und Prozeduren (TTPs) des Mitre ATT@CK Frameworks ab. Der Fokus unserer Tests lag explizit auf dem Bereich Command & Control. Die zu testenden TTPs waren konkret:

• Initial Access über Phishing-Attacken wie Spearphishing-Attachments (T1556.001) und -Links (T1556.002) sowie die Verbreitung über Wechseldatenträger wie USB-Sticks (T1091).
• User Execution über eine schädliche Datei (T1204.002).
• Im Bereich Command & Control konzentrierten wir uns auf verschlüsselte Kommunikationskanäle (T1573.001) und die Nutzung von Non-Standard Ports (T1571).

Über das Mitre ATT@CK Framework
Die umfangreiche Wissensdatenbank enthält gegnerische Taktiken und Techniken, die auf realen Beobachtungen von Cyberangriffen basieren. Das Mitre ATT&CK Framework wird weltweit von Sicherheitsexperten eingesetzt, um Bedrohungen zu identifizieren, abzuwehren und zu analysieren.

2. Entwicklung eines maßgeschneiderten C2-Kanals

Im zweiten Schritt programmierten wir eine speziell auf dieses Assessment zugeschnittene Serversoftware und einen Agenten, der auf dem Arbeitslaptop des Kunden eingeschleust werden sollte.
Damit unser C2-Kanal nicht direkt entdeckt werden konnte, bauten wir einige Features ein:

• Unser Agent meldete sich in unregelmäßigen Abständen beim Server (Beaconing & Jitter), um die Regelmäßigkeit der Kommunikation zu verschleiern.
• Wir haben die Kommunikation mit AES (Advanced Encryption Standard) verschlüsselt, damit sie trotz SSL-Inspektion durch die Firewall nicht als verdächtig erkannt wird.
• Wir hatten vorab für den Server eine unauffällige Domain registriert. So fällt der Server in der Kommunikation kaum auf.

3. Erstellung eines ausführlichen Testplans

Schließlich erstellten wir einen umfassenden Testplan, der verschiedene Szenarien abdeckte. Zentrale Fragestellungen waren:

• Über welche Wege kann der Agent in das Zielsystem eingeschleust werden?
• Welcher Kommunikationskanal wird für die Verbindung zwischen Agent und Server verwendet (z.B. HTTPS,
• Kommunikation über Non-Standard Ports)?
• Können Kommandos über den C2-Kanal auf dem Zielsystem ausgeführt werden?
• Ist eine Local Privilege Escalation möglich, um Administrationsrechte auf dem Gerät zu erlangen?

Durchführung des Assessments

Um die Sicherheitsmaßnahmen des Kunden umfassend zu prüfen, gliederten wir das Assessment in mehrere wesentliche Schritte.

1. Infiltration des Zielsystems

Im ersten Schritt testeten wir verschiedene Methoden, um den Agenten auf das Zielsystem zu bringen.
Per USB-Stick:
Diese häufig übersehene, aber sehr effektive Methode nutzt physische Zugangsmöglichkeiten aus. Wir hatten Erfolg und konnten unseren Agenten mit Hilfe eines USBs-Sticks schlussendlich auf den Testrechner laden.
Phishing:
Auch per E-Mail verschickte Links und Anhänge konnten auf dem Testrechner geöffnet und so unser Agent eingeschleust werden.

2. Ausführung der Schadsoftware

Als nächstes prüften wir, ob wir den C2-Kanal aufbauen und darüber Kommandos auf dem Testrechner ausführen konnten.
C2-Kommunikation über HTTPS:
Diese Methode erwies sich als effektiv. Der C2-Kanal konnte aufgebaut und Kommandos erfolgreich ausgeführt werden.
Weitere getestete Methoden:
Wir haben zudem verschiedene andere Kommunikationsmethoden getestet:

Bad USB (Flipper Zero): Der Flipper Zero ist ein tragbares Gerät, das verschiedene drahtlose Protokolle und physische Zugangstechniken testen und analysieren kann, einschließlich RFID, NFC, Bluetooth, Infrarot und GPIO-Interaktionen. Mit Hilfe dieses kleinen Multitools konnten wir Tatstaureingaben simulieren und so erfolgreich Schadcode auf dem Testrechner ausführen.

• Word-Makro als E-Mail-Anhang: Der Empfang von E-Mails, die Word-Dokumente mit Makros im Anhang enthielten, wurde durch die Sicherheitslösung zumindest teilweise blockiert. Diese Sicherheitsmaßnahme konnte jedoch mit einfachen Techniken umgangen und die Word-Dokumente schließlich per E-Mail auf das Testsystem gebracht werden. Die Ausführung der Word-Makros auf dem Testrechner war jedoch ohne weiteres möglich, so dass auf diesem Weg Schadcode ausgeführt werden konnte.
• Zip-Dateien als Download: Mit Hilfe einer Zip-Datei konnten wir die Security-Lösung umgehen und die Schadsoftware auf dem Testrechner ausführen.
• Virtuelles Laufwerk mit Schadsoftware in PDF: Wir prüften auch, ob wir Schadsoftware über ein PDF einschleusen und mit Hilfe eines virtuellen Laufwerks ausführen konnten. Dieser Ansatz scheiterte allerdings an fehlenden Administrationsrechten zum Einbinden des Laufwerks.

Insgesamt ist es uns gelungen, über mehrere Wege unseren Agenten auszuführen, den C2-Kanal aufzubauen und auf dem Testsystem Kommandos auszuführen. Diese wurden von der Sicherheitslösung zumindest eine Zeit lang nicht erkannt.

3. Testen weiterer C2-Kommunikationsmöglichkeiten

Nachdem wir das Hauptziel, unentdeckt einen C2-Kanal aufzubauen und Kommandos auszuführen, erreicht hatten, konzentrierten wir uns im weiteren Assessment darauf, die Flexibilität und Robustheit des C2-Kanals zu testen. Dazu überprüften wir verschiedene Protokolle und Ports. Allerdings mussten wir schnell feststellen, dass lediglich HTTPS zuverlässig funktionierte. Andere Ports konnten aus dem internen Netzwerk heraus nicht erreicht werden.

4. Versuch einer Local Privilege Escalation

Zusätzlich führten wir eine grundlegende Überprüfung des Rechtemanagements auf dem Testrechner durch. Dazu verwendeten wir gängige Methoden zur Erlangung von Administratorrechten, einschließlich der Nutzung von Exploits für bekannte Schwachstellen oder der Ausnutzung von Schwächen in der Benutzerkontensteuerung (User Account Control, UAC). Diese Versuche blieben jedoch erfolglos, das System war angemessen gehärtet.

5. Entdeckung und Incident Response

Wir blieben lange Zeit unentdeckt und konnten den C2-Kanal für einige Kommandos nutzen. Erst als wir dem Testplan weiter folgten und weitere Wege zur Ausführung von Schadsoftware prüften, reagierte die EDR-Lösung aufgrund der abnehmenden Verschleierung unserer Aktionen, blockierte schlussendlich einen unserer Versuche und alarmierte den Kunden.
Nach der Entdeckung des Angriffs durch das Security Operations Center (SOC) griffen effiziente Incident Response Prozesse. Unsere vorherige Angriffe konnten im SIEM nachvollzogen werden und die Meldewege wurden eingehalten.

6. Erstellung des Testprotokolls und Reports

Abschließend haben wir alle Ergebnisse ausführlich dokumentiert und einen detaillierten Report erstellt. Dieser zeigt alle gefundenen Schwachstellen auf und bietet unserem Kunden eine fundierte Grundlage für weitere Sicherheitsmaßnahmen.

Empfehlungen für unseren Kunden

• Optimierung der Endpoint Detection & Response (EDR)-Lösung notwendig
  Unsere Analyse zeigte, dass die Endpoint Detection & Response (EDR)-Lösung des Kunden nicht ausreichend alarmiert. Gründe dafür können Konfigurationsprobleme oder mangelndes Fachwissen sein. Unser Kunde sollte daher die Konfiguration der Endpoint Protection überprüfen und anpassen, um Angriffe wie in unserem Test zukünftig früher zu erkennen.
• Einführung eines Application Allow Listings
  Um die Sicherheitsmaßnahmen zu verbessern, empfehlen wir die Einführung eines Application Allow Listing. Dieses blockiert alle unbekannten Anwendungen und verhindert somit auch die Ausführung von Schadsoftware.
• Office-Makros standardmäßig blockieren
  Die Ausführung von Office-Makros sollte jederzeit blockiert werden, um das Risiko durch Makro-basierte Malware zu minimieren.
• Unbekannte USB-Geräte blockieren
  Unbekannte USB-Geräte sollten immer blockiert werden, um das Risiko von Bad USB-Angriffen zu minimieren. In unseren Tests war das nicht der Fall und wir konnten über eine USB-Schnittstelle Schadcode auf den Testrechner spielen.
• Regelmäßige Sensibilisierung der Benutzer
  Regelmäßige Schulungen und Sensibilisierungsmaßnahmen sind unerlässlich, um das Bewusstsein der Mitarbeitenden für mögliche Bedrohungen zu schärfen und die Sicherheitskultur im Unternehmen zu stärken.

Fazit

Im Rahmen des Assessments konnten wir ungehindert Schadsoftware auf das Testsystem spielen, diese ausführen und Command-and-Control-Kanäle aufbauen, ohne dass die Endpoint Protection wirksam eingreifen konnte.
Dies bedeutet, dass unser Kunde nicht ausreichend gegen die im Scope definierten Szenarien geschützt ist. Die Eintrittswahrscheinlichkeit einer erfolgreichen gezielten Kompromittierung von Benutzern und deren Endgeräten stufen wir aufgrund der Größe des Kundens und seines Geschäftsmodells als sehr hoch ein, wenn die anvisierten Benutzer unaufmerksam sind.

Regelmäßige Assessments durchführen!
Regelmäßige Tests wie das von uns durchgeführte Red Teaming-Assement sind für Unternehmen unerlässlich. Solchen Tests zeigen nicht nur technische Schwachstellen, sondern auch Lücken in den Sicherheitsprozessen und Verantwortlichkeiten auf. So haben Unternehmen die Chance zu reagieren und ihre Sicherheit zu verbessern, bevor Schwachstellen von Cyberkriminellen ausgenutzt werden können.
Wir empfehlen daher, regelmäßige Assessments durchzuführen und auch neue Systeme direkt mit der Einführung testen zu lassen, um die Effektivität der Incident Response und Prozesse sicherzustellen.

Suchst du Informationen über Angriffssimulationen zur Erkennung von Schwachstellen in deinem Unternehmen?

Hier findest du eine Übersicht über unsere Leistungen im Bereich Offensive Security

Bestelle dir jetzt das Whitepaper um Risiken in deinem Unternehmen zu bewältigen und Vertrauen aufzubauen

So gelangst du zu deinem kostenlosen Whitepaper:

1. Fülle das Formular aus und klicke auf „senden“.
2. Schaue in deine Mail und bestätige deine E-Mail-Adresse.
3. Du bekommst von uns eine E-Mail mit dem Download-Link.

Über das Whitepaper

Lade dir dein Whitepaper herunter und optimiere deine Unternehmen-Internen Prozesse

So gelangst du zu deinem kostenlosen Whitepaper:

1. Fülle das Formular aus und klicke auf „senden“.
2. Schaue in deine Mail und bestätige deine E-Mail-Adresse.
3. Du bekommst von uns eine E-Mail mit dem Download-Link.

Bestelle dir jetzt das Dossier für deine Krisenbewältigung

So gelangst du zu deiner kostenlosen Bestellung :

1. Fülle das Formular aus und klicke auf „senden“.
2. Schaue in deine Mail und bestätige deine E-Mail-Adresse.
3. Du bekommst von uns eine E-Mail mit dem Download-Link.