Interviewfragen zu CompTIA Security+

Praktisch nein. AES-128 erfordert bereits etwa 2^128 Aufwand für Brute Force — völlig undurchführbar — daher macht AES-256 dich gegen Brute Force nicht spürbar sicherer; es gibt vor allem Reserve (post-quanten Spielraum, Compliance). Beide sind standardisiert und ungebrochen. Dein Modus (GCM), Nonce-Handhabung und Schlüsselverwaltung zählen weit mehr als 128 gegen 256. „AES-256 ist doppelt so sicher“ ist der Irrtum.

Nein. Antivirus ist ein Signal, kein Beweis. Es übersieht dateilose und im Speicher laufende Angriffe, brandneue oder verschleierte Proben, den Missbrauch legitimer Werkzeuge (Living-off-the-Land) und Rootkits, die sich davor verstecken. Fehlende Beweise sind kein Beweis für Abwesenheit — echte Sicherheit kommt aus EDR-Telemetrie, Speicherforensik, Verhaltensanalyse und IOC-Jagd. Einen sauberen Virenscan als Beweis für ein sauberes System zu behandeln, ist ein klassischer Incident-Response-Fehler.

Nein. Die drei Kategorien von Authentifizierungsfaktoren sind etwas, das man weiß (Passwort/PIN), etwas, das man hat (Token/Telefon) und etwas, das man ist (Biometrie). Ein Fingerabdruck oder Gesichtsscan gehört zu „etwas, das man ist“, einem gemessenen physischen Merkmal. Der Haken: Biometrie ist kein Geheimnis und lässt sich nicht erneuern — leckt die Vorlage deines Fingerabdrucks, kannst du deinen Fingerabdruck nicht ändern. Deshalb funktioniert Biometrie am besten als ein Faktor, der oft einen lokalen Schlüssel entsperrt, statt als eigenständiger Passwortersatz.

Gar nicht — kryptografische Hashes sind Einwegfunktionen ohne Inverse. Einen Hash zu „cracken“ heißt, Kandidaten-Eingaben zu raten, jede zu hashen und zu vergleichen (Wörterbuch, Brute Force, Rainbow Tables), und genau deshalb nutzt man langsame, gesalzene Hashes für Passwörter. Es gibt keinen Schlüssel, der einen Hash „entschlüsselt“. Wenn sich etwas entschlüsseln lässt, wurde es verschlüsselt, nicht gehasht — und Base64 ist umkehrbare Kodierung, kein Hashing.

Nein. Die EICAR-Testdatei ist eine bewusst harmlose 68-Byte-ASCII-Zeichenkette, die jeder Antivirus-Hersteller zu erkennen vereinbart, damit man Erkennung und Alarmierung sicher prüfen kann, ohne echte Malware anzufassen. Ein Treffer bedeutet, dass dein Antivirus funktioniert — nicht, dass du infiziert bist. Es ist kein Virus und tut nichts, wenn es ausgeführt wird. Eine EICAR-Testerkennung mit einer echten Infektion zu verwechseln, ist ein verbreiteter Anfänger-Fallstrick.

Größtenteils nein. Der Ziel-Hostname wird im Klartext in der SNI-Erweiterung des TLS-ClientHello gesendet, und Ihre DNS-Abfrage verrät ihn meist ebenfalls, sodass ein Provider oder Netzwerk sehen kann, WELCHE Seite Sie besuchen — selbst über HTTPS. Sie können nur den Pfad und Inhalt nicht lesen. Encrypted ClientHello (ECH) und DNS-over-HTTPS können diese Lücke schließen, sind aber nicht universell. „HTTPS verbirgt alles“ ist der Irrtum.

Nein. TLS/HTTPS sichert Daten bei der Übertragung zwischen Client und Server; nach dem Empfang werden sie von der App entschlüsselt und im Klartext verarbeitet und dann je nach Datenbankkonfiguration gespeichert. Daten im Ruhezustand zu schützen ist ein eigenes Thema — Datenträger-/Spaltenverschlüsselung, ein KMS und Zugriffskontrolle. „Wir nutzen HTTPS“ mit „unsere gespeicherten Daten sind verschlüsselt“ zu verwechseln ist ein verbreiteter und gefährlicher Irrtum.

Nein. HTTPS verschlüsselt den Kanal, sodass Angreifer den Verkehr unterwegs nicht lesen oder manipulieren können, aber die bösartige Eingabe kommt an, wird entschlüsselt und von deiner App genau wie zuvor verarbeitet. SQL-Injection und XSS sind Fehler der Anwendungsschicht, die durch parametrisierte Abfragen und Output-Encoding behoben werden, nicht durch Transportverschlüsselung. Der Irrtum unterstellt, Verschlüsselung bereinige Inhalte — tut sie nicht; der Angreifer sendet die Payload einfach über die HTTPS-Verbindung.

Nein. Eine MAC wird vom Hersteller vergeben (OUI plus Geräte-ID) und ist „eingebrannt“, aber praktisch jedes Betriebssystem erlaubt es, sie per Software zu überschreiben (macchanger, ip link set address). MAC-Adressen sind also fälschbar und dürfen nicht zur Authentifizierung dienen — MAC-Filterung ist schwach, und Smartphones randomisieren die MAC inzwischen aus Datenschutzgründen. „Dauerhaft und eindeutig“ ist der Irrtum.

Nein. MFA hebt die Hürde stark, aber OTP- und Push-Faktoren sind phishbar: Adversary-in-the-Middle-Kits (z. B. Evilginx) leiten Login und Code in Echtzeit weiter, und MFA-Müdigkeit/Push-Bombing bringt Nutzer zum Bestätigen. Abgefangene Codes sind innerhalb ihres kurzen Fensters wiederverwendbar. Der Irrtum ist „MFA = nicht phishbar”; entscheidend ist der Faktortyp. Phishing-resistente MFA — FIDO2/WebAuthn-Passkeys, an den Origin der Seite gebunden — ist das, was dies tatsächlich vereitelt.

Nein. NAT (und PAT) bildet private Adressen auf eine öffentliche IP ab und verwirft als Nebeneffekt unaufgeforderte eingehende Verbindungen, weil für sie keine Zuordnung existiert. Das ist keine Sicherheitsrichtlinie — keine Inspektion, keine Regeln, kein Logging — und NAT-Traversal, Hole Punching sowie ausgehend initiiertes C2 passieren ungehindert. NAT ist ein Adressierungswerkzeug; Sie brauchen trotzdem eine echte Firewall. „NAT = Firewall“ ist der Irrtum.

Nicht allein. Viele Systeme halten bestehende Sitzungen und bereits ausgestellte Tokens nach einem Passwortwechsel gültig — OAuth-Refresh-Tokens, „App-Passwörter“, API-Schlüssel und persistente Cookies — sodass ein Angreifer mit einer aktiven Sitzung drinbleiben kann. Die richtige Reaktion ist, das Passwort zu ändern UND alle Sitzungen und Tokens zu invalidieren, App-Anmeldedaten zu widerrufen und MFA-Geräte sowie Wiederherstellungseinstellungen zu prüfen. Anzunehmen, ein Reset allein werfe den Angreifer hinaus, ist ein klassischer Incident-Response-Fehler.

Nein. POST trägt die Parameter einfach im Anfrage-Body statt in der URL; dieser Body ist Klartext und für jeden, der den Verkehr sieht, voll sichtbar, sofern kein HTTPS genutzt wird. POST ist vorzuziehen für zustandsändernde Aktionen und hält Parameter aus URLs, Logs und Verlauf heraus, bietet aber für sich keine Vertraulichkeit. Der Irrtum verwechselt „nicht in der URL” mit „verschlüsselt” — nur TLS verschlüsselt die Daten beider Methoden bei der Übertragung.

Nein. Die meisten echten Eindringversuche richten Persistenz ein (Dienste, geplante Aufgaben, Run-Schlüssel, Implantate), die einen Neustart überlebt, sodass der Angreifer einfach zurückkehrt. Schlimmer noch, das Ausschalten löscht flüchtige Beweise — laufende Prozesse, Netzwerkverbindungen, Malware im Speicher und Verschlüsselungsschlüssel —, die du zum Eingrenzen des Vorfalls brauchst. Richtig ist, einzudämmen, indem du den Host isolierst und dabei den Speicher bewahrst, und dann zu untersuchen. Neustart oder Herunterfahren als „Lösung“ ist ein schädlicher Instinkt.

Nein. Ein Salt ist ein eindeutiger Zufallswert, der direkt neben dem Hash gespeichert wird; seine Aufgabe ist es, identische Passwörter unterschiedlich hashen zu lassen und vorberechnete Rainbow Tables zu vereiteln — nicht geheim zu bleiben. Es ist unproblematisch, wenn ein Angreifer, der die Datenbank stiehlt, auch die Salts erhält. Was Passwörter wirklich schützt, ist ein langsamer, gesalzener Hash (bcrypt, scrypt, Argon2). Ein separater, optionaler geheimer „Pepper“ ist ein anderes Konzept.

Fangfrage — es gibt keinen einzelnen traceroute-Port. Das klassische Unix-traceroute sendet UDP-Datagramme an hohe, unwahrscheinliche Ports ab etwa 33434 mit steigendem TTL; Windows tracert nutzt stattdessen ICMP Echo. Es funktioniert, indem es die ICMP-Time-Exceeded-Nachrichten liest, die Router beim Ablauf des TTL zurücksenden, nicht durch das Anvisieren eines reservierten Ports. Und ICMP selbst hat überhaupt keine Ports.

Passwortspeicherung braucht einen absichtlich langsamen, gesalzenen, speicherharten Hash — bcrypt, scrypt oder Argon2 — damit das Knacken gestohlener Hashes teuer ist und Rainbow Tables nicht greifen. Ein schneller Hash wie SHA-256 lässt sich im großen Maßstab trivial per Brute Force knacken; reversible Verschlüsselung bedeutet, dass eine einzige Schlüsselkompromittierung alle Passwörter auf einmal offenlegt; und Klartext ist unhaltbar, egal wie abgeriegelt die Datenbank ist. Wählen Sie Argon2id (oder bcrypt) mit einem abgestimmten Kostenfaktor und einem einzigartigen Salt pro Benutzer.

SSLv3, TLS 1.0 und RC4 sind gebrochen oder veraltet und ermöglichen Downgrade- und Entschlüsselungsangriffe; deaktivieren Sie sie daher und verlangen Sie TLS 1.2 oder 1.3 mit starken, forward-secret Cipher-Suiten, wobei der seltene Verlust sehr alter Clients in Kauf genommen wird. Sie aus Kompatibilitätsgründen aktiviert zu lassen, hält die Schwäche ausnutzbar. Ein zweites Zertifikat hinzuzufügen oder auf ein selbstsigniertes zu wechseln, entfernt die schwachen Protokolle nicht, und das selbstsignierte schadet dem Vertrauen, ohne die Kryptografie zu beheben.

Dringlichkeit, Autorität und das Überspringen der Prüfung sind lehrbuchhafter Social-Engineering-Druck, der auf ein hochwertiges Konto zielt. Der Mitarbeiter muss den definierten Identitätsprüfungsprozess befolgen, bevor er irgendetwas zurücksetzt, und eskalieren, falls er nicht erfüllt werden kann. Auf Verlangen zurückzusetzen, eine erratbare „Sicherheitsfrage“ wie die Lieblingsfarbe zu nutzen oder das neue Passwort per E-Mail an den Anrufer zu senden, übergibt einem Angreifer die Kontrolle über das Konto der Führungskraft.

Da Firewalls Regeln von oben nach unten auswerten, kurzschließt eine breite any/any-Erlauben-Regel nahe dem Anfang alle darunterliegenden Regeln und lässt allen Verkehr durch — die Firewall hört praktisch auf, irgendetwas durchzusetzen. Ersetzen Sie sie durch explizite Least-Privilege-Regeln für die tatsächlich benötigten Flüsse, so geordnet, dass spezifische Erlaubnisse und Verweigerungen wirken, abschließend mit einer Standardverweigerung. Sie effizient zu nennen ist falsch, sie ans Ende zu verschieben kann die Standardverweigerung weiterhin verdecken, und ein Umbenennen ändert nichts daran, was sie erlaubt.

LSASS speichert zwischengespeicherte Anmeldedaten und Geheimnisse, daher ist ein unerwarteter Prozess, der seinen Speicher liest, ein Kennzeichen für Anmeldedatendiebstahl (z. B. ein Dump im Mimikatz-Stil). Triagieren Sie den auffälligen Prozess und dessen übergeordneten Prozess, isolieren Sie den Host, um laterale Bewegung zu stoppen, und rotieren Sie die Anmeldedaten, die erfasst worden sein könnten — einschließlich privilegierter und Dienstkonten. Es hat nichts mit Grafik-Rendering oder Speicherplatz zu tun, und es als normal abzutun, kann zur Kompromittierung der gesamten Domäne führen. Die harmlos klingenden Ablenker sind genau die Art, wie Analysten einen aktiven Einbruch übersehen.

Word, das direkt nach dem Aktivieren von Makros einen Kindprozess erzeugt, ist ein klassisches Muster für Erstzugriff per Schaddokument. Isolieren Sie den Host, um die Ausbreitung zu begrenzen, erfassen Sie flüchtige Beweise und untersuchen Sie den erzeugten Prozess, seine Netzwerkaktivität und jegliche Persistenz. Den Benutzer zu bitten, die Datei zu schließen, oder Office zu reparieren, behandelt keine ausführende Nutzlast, die möglicherweise bereits gelaufen ist. Nichts zu tun, weil die Datei per E-Mail kam, ist verkehrt herum — E-Mail ist genau der Lieferweg dieses Angriffs. Erst eindämmen, dann untersuchen.

Legitime Software führt PowerShell nur selten über eine frisch erstellte geplante Aufgabe aus %TEMP% aus — das ist eine verbreitete Persistenz- und Ausführungstechnik. Untersuchen Sie die Aufgabendefinition, das aufgerufene Skript, den erstellenden Prozess und die Zeitachse, dämmen Sie den Host ein und durchsuchen Sie die Umgebung nach demselben Muster. Updates sehen nicht so aus, blindes Vertrauen in geplante Aufgaben ignoriert eine bekannte TTP, und das Löschen von System32 zerstört das Betriebssystem, ohne etwas gegen die Bedrohung zu tun. Die ersten drei Optionen spiegeln allesamt gefährlich schwaches Urteilsvermögen wider.

Management-Ports, die für das gesamte Internet offen sind, werden innerhalb von Minuten gescannt und per Brute Force angegriffen, daher besteht die Lösung darin, die Angriffsfläche zu verkleinern: Beschränke den Security-Group-Ingress auf bekannte Admin-CIDRs oder VPN, oder entferne den eingehenden Verkehr ganz mittels Bastion oder SSM Session Manager. SSH auf einen Nicht-Standard-Port zu verschieben ist Security by Obscurity, die Scanner trivial aushebeln. Ein stärkeres Passwort verkleinert die exponierte Fläche nicht und stoppt kein Credential Stuffing. Auf eine Host-Firewall zu vertrauen ignoriert die Angriffsfläche, die die Security Group offen ins Internet bewirbt.

Eine nicht authentifizierte RCE auf einem internetexponierten Server ist Notfall-Niveau: verkleinere das Expositionsfenster mit einem getesteten, gestaffelten oder rollierenden Deployment und ergänze in der Zwischenzeit kompensierende Kontrollen (Zugriff beschränken, WAF-Regeln). Auf das Quartalsfenster zu warten lässt ein wurmfähiges Loch wochenlang offen. Blind in der Produktion zur Geschäftszeit ohne Tests zu patchen riskiert einen Ausfall und einen verpfuschten Rollback. Sich auf die Perimeter-Firewall zu verlassen bringt nichts — der Dienst ist bereits exponiert und der Exploit braucht keine Anmeldedaten.

Behandle jedes gepushte Geheimnis als verbrannt: widerrufe und rotiere es zuerst, denn Bots scrapen öffentliche Commits innerhalb von Sekunden, prüfe dann CloudTrail auf Missbrauch und entferne es aus der Historie. Den Commit zu löschen hilft nicht — der Schlüssel ist bereits geklont, geforkt und von Dritten gecacht. Das Repo privat zu machen lässt einen bereits geleakten, aktiven Schlüssel in den Händen von Angreifern. Die Datei in die .gitignore aufzunehmen ändert nichts an einem bereits committeten Geheimnis.

Sensible Daten sollten niemals in Logs gelangen: redigiere oder maskiere zuerst an der Quelle, um die Blutung zu stoppen, behebe dann die historischen Logs und verschärfe die Zugriffe. PCI DSS verbietet, vollständige PANs und CVVs so zu speichern, und Passwörter sollten überhaupt nie protokolliert werden. „Interne" Logs sind weiterhin ein erstrangiges Angriffsziel. Den Speicher zu verschlüsseln oder mit ACLs zu versehen lässt trotzdem Klartext-Geheimnisse in den Logs liegen, lesbar für jeden mit Lesezugriff — Backups, SIEM-Pipelines und Administratoren sehen sie alle.

Validieren Sie vor dem Eskalieren. Unternehmens-VPNs, Cloud-Proxys (CASB oder M365-Dienst-IPs) und Mobilfunkanbieter erzeugen routinemäßig falsche „unmögliche Reisen“; prüfen Sie daher die Egress-IPs, das MFA-Ergebnis und das Gerät/den User-Agent, bevor Sie handeln. Bei jedem Treffer automatisch zu sperren verursacht Alarmmüdigkeit und untergräbt das Vertrauen der Nutzer in das SOC. Anzunehmen, es sei immer ein Fehlalarm, übersieht eine echte Kontoübernahme. Den Vorgesetzten anzuschreiben ist langsam und keine Kontrolle — die Protokolle antworten schneller und zuverlässiger.

Gehen Sie davon aus, dass das Passwort bereits kompromittiert ist: Erzwingen Sie ein Zurücksetzen UND machen Sie die aktiven Sitzungen und Token des Kontos ungültig, denn ein Reset allein vertreibt keinen Angreifer, der bereits eine aktive Sitzung oder ein Refresh-Token besitzt. Jagen Sie dann anomale Anmeldungen, MFA-Aufforderungen, Postfachregeln und OAuth-Berechtigungen aus dem Expositionsfenster. Die E-Mail zu löschen oder dem Benutzer zu sagen, er solle sein Passwort „beim nächsten Mal“ ändern, lässt das Konto weit offen. Ein Virenscan adressiert Malware auf dem Endgerät, nicht gestohlene Anmeldedaten in der Cloud.

Triagieren Sie nach Wirkung und Erreichbarkeit: Credential Dumping (eine mimikatz-Signatur) auf einem Domänencontroller ist ein Kronjuwelen-Ereignis, das zur vollständigen Domänenkompromittierung führen kann; bearbeiten Sie es zuerst. Der externe Portscan wurde bereits vom IDS blockiert, die nicht genehmigte Browser-Erweiterung ist von geringer Schwere, und ein abgelaufenes TLS-Zertifikat auf einer internen Testmaschine ist informativ. Die zentrale SOC-Fähigkeit ist die Priorisierung nach Wirkungsradius und Eskalationswahrscheinlichkeit, nicht nach Alarmalter oder Lautstärke.

KI hilft dem SOC, indem sie Alerts triagiert und dedupliziert, Vorfälle zusammenfasst, Kontext anreichert, Detections entwirft und das Onboarding von Analysten beschleunigt — was Ermüdung und Verweildauer reduziert. Die Risiken: halluzinierte oder selbstbewusst falsche Schlüsse, Automation Bias, bei dem Analysten aufhören zu prüfen, Prompt Injection über vom Angreifer kontrollierte Log- oder Alert-Daten, das Abfließen sensibler Daten an Drittmodelle, und Angreifer, die dieselben Tools nutzen. Halte einen Menschen in der Schleife, prüfe die Ausgaben und isoliere nicht vertrauenswürdige Eingaben.

Direkte Prompt Injection liegt vor, wenn ein Nutzer gegnerische Anweisungen direkt in den Prompt tippt, um den System-Prompt oder Sicherheitsregeln zu überschreiben. Indirekte Prompt Injection verbirgt bösartige Anweisungen in externen Inhalten, die das Modell später einliest — eine Webseite, eine E-Mail, ein PDF oder ein RAG-Dokument —, sodass der Angriff auslöst, ohne dass das Opfer ihn je tippt. Indirekte Injection ist das größere Risiko, weil Angreifer und Opfer verschiedene Personen sind und die Payload in Daten mitreist, denen die App implizit vertraut.

Unsichere Ausgabeverarbeitung bedeutet, dem zu vertrauen, was das Modell zurückgibt, und es ohne Validierung oder Codierung an ein nachgelagertes System weiterzureichen. Weil die Modellausgabe von Angreifern beeinflussbar ist, führt das Rendern als rohes HTML zu XSS, das Einspeisen in einen URL-Fetcher zu SSRF und das Übergeben an eine Shell oder SQL-Abfrage zu Command- oder SQL-Injection. Die Lösung ist, die Modellausgabe genauso wie nicht vertrauenswürdige Benutzereingaben zu behandeln: kontextbewusste Ausgabecodierung, Allowlisting, Sanitization und Parametrisierung, bevor sie einen Sink erreicht.

Ein Jailbreak zielt auf das Sicherheits-Alignment des Modells: Er bringt das Modell dazu, Inhalte zu erzeugen, die der Anbieter zu verbieten versuchte, etwa schädliche Anleitungen. Prompt Injection zielt auf die Anweisungshierarchie der Anwendung: Sie überschreibt den System-Prompt des Entwicklers oder kapert das Verhalten des Modells innerhalb einer App, oft über nicht vertrauenswürdige Daten. Jailbreaks greifen das Modell an; Prompt Injection greift das umgebende System an. Sie überschneiden sich, aber das Ziel und die überschrittene Vertrauensgrenze unterscheiden sich.

LLM-Apps geben Daten auf mehrere Arten preis: Das Modell memoriert und gibt sensible Trainings- oder Fine-Tuning-Daten wieder, der System-Prompt (der Geheimnisse oder Logik enthalten kann) wird extrahiert, abgerufene RAG-Dokumente legen Daten offen, die der Benutzer nicht sehen sollte, und Kontext aus einer Benutzer- oder Sitzung blutet in eine andere über. Vorbeugung bedeutet Datenminimierung vor dem Training, niemals Geheimnisse in Prompts, das Erzwingen benutzerbezogener Autorisierung beim Retrieval, Ausgabefilterung und PII-Redaktion sowie Mandantenisolierung.

Credential Stuffing spielt bekannte Benutzername:Passwort-Paare aus fremden Datenlecks ab und setzt auf Passwort-Wiederverwendung – hohe Erfolgsrate pro Versuch, oft über viele IPs und Geräte verteilt, um menschlich zu wirken. Password Spraying probiert ein oder zwei gängige Passwörter (wie Winter2026!) über viele Konten, um unter den Sperrschwellen zu bleiben. Stuffing nutzt Wiederverwendung aus; Spraying nutzt schwache gemeinsame Passwörter aus. MFA schlägt beide.

Die Cyber Kill Chain modelliert einen Einbruch als sieben aufeinanderfolgende Stufen: Aufklärung, Bewaffnung, Auslieferung, Ausnutzung, Installation, Command and Control (C2) und Actions on Objectives. Verteidiger ordnen jeder Stufe Erkennungen und Maßnahmen zu; da die Stufen sequenziell sind, stört das Brechen eines einzelnen Glieds – die Phishing-Mail blockieren, das C2 abschalten – den gesamten Angriff. Sie drängt dazu, früh zu erkennen statt erst beim finalen Einbruch.

DNS-Exfiltration kodiert gestohlene Daten in DNS-Anfragen (z. B. lange Subdomain-Labels an einen vom Angreifer kontrollierten autoritativen Server) und nutzt aus, dass DNS fast immer ausgehend erlaubt und oft unüberwacht ist. Erkenne sie über Anomalien: ungewöhnlich hohes Anfragevolumen zu einer Domain, lange Subdomains mit hoher Entropie, viele eindeutige Subdomains je Eltern-Domain, Missbrauch von TXT/NULL-Records und Anfragen an neu registrierte oder seltene Domains.

Herkömmliches Antivirus gleicht Dateien mit Signaturen bekannter Malware ab und blockiert oder isoliert sie – gut gegen bekannte Bedrohungen, schwach gegen neuartige oder dateilose Angriffe. EDR zeichnet kontinuierlich das Endpunktverhalten auf (Prozesse, Netzwerk, Registry, Speicher), nutzt Verhaltensanalytik zur Erkennung verdächtiger Aktivität und ermöglicht Respondern, aus der Ferne zu untersuchen, zu jagen und einzudämmen oder zurückzurollen. AV ist Prävention per Signatur; EDR ergänzt Sichtbarkeit, Erkennung und Reaktion.

Das klassische Modell ist PICERL: Vorbereitung, Identifikation (Erkennung), Eindämmung, Beseitigung, Wiederherstellung und Lessons Learned. NIST gruppiert es als Vorbereitung; Erkennung und Analyse; Eindämmung, Beseitigung und Wiederherstellung; sowie Aktivität nach dem Vorfall. Die Reihenfolge zählt, weil man den Umfang erfassen und eindämmen muss, bevor man beseitigt, und erst wiederherstellt, wenn die Bedrohung entfernt ist – sonst infiziert man erneut. Es ist eine Schleife, keine Linie: Lessons Learned fließen in die Vorbereitung zurück.

Ein IOC ist ein forensisches Artefakt dafür, dass bereits etwas Bösartiges passiert ist: ein bösartiger Datei-Hash, eine C2-IP oder -Domain, ein bekannter schädlicher Registry-Schlüssel. Ein IOA ist ein Verhaltenssignal eines laufenden Angriffs, unabhängig von den konkreten Werkzeugen, z. B. ein Word-Dokument, das PowerShell startet und dann ins Internet greift. IOCs sind reaktiv und durch Ändern eines Hashes leicht zu umgehen; IOAs erfassen die Absicht und überstehen Werkzeugwechsel.

Persistenz ist, wie Malware Neustarts und Abmeldungen übersteht. Die typischen unter Windows sind Registry-Run/RunOnce-Schlüssel (HKLM und HKCU), geplante Aufgaben und Windows-Dienste, dazu Autostart-Ordner, WMI-Ereignisabonnements und DLL-Hijacks. Du jagst sie mit autoruns/Sysinternals, Sysmon und Ereignisprotokollen – auf der Suche nach unsignierten Binaries, seltsamen Pfaden wie %AppData% und Einträgen, die direkt nach der Erstkompromittierung erstellt wurden.

Die Reihenfolge der Flüchtigkeit ordnet Beweise danach, wie schnell sie verschwinden, sodass man das Fragilste zuerst sichert. Grob: CPU-Register/Cache, dann RAM und Laufzeitzustand (Prozesse, Netzwerkverbindungen, ARP), dann temporäre Dateien/Swap, dann Disk, dann Remote-Logging und Überwachungsdaten, und zuletzt Archivmedien und Backups. Außerdem arbeitet man auf forensischen Kopien, hasht sie und führt eine Beweiskette, damit Beweise zulässig bleiben.

Unter Windows liegen die Hashes lokaler Konten (NTLM) in der SAM-Hive unter C:\Windows\System32\config\SAM, geschützt solange das OS läuft; lebende Anmeldedaten sitzen im LSASS-Speicher, und Domänen-Hashes liegen in NTDS.dit auf einem Domänencontroller. Unter Linux liegen Hashes in /etc/shadow (nur für root lesbar), während /etc/passwd Kontometadaten enthält. Angreifer stehlen diese, um Passwörter offline zu knacken oder Pass-the-Hash zu betreiben.

Process Injection führt Angreifercode im Speicherbereich eines legitimen Prozesses aus, sodass die Aktivität sich einfügt und das Vertrauen dieses Prozesses erbt. Klassische Techniken sind DLL-Injection (CreateRemoteThread + LoadLibrary), Process Hollowing (einen harmlosen Prozess suspendiert starten, ihn entladen, bösartigen Code schreiben) und APC-Injection. Verteidiger erkennen sie über EDR-API-Hooks, anomale Eltern/Kind-Beziehungen oder Speicherbereiche (RWX, nicht dateigestützter ausführbarer Speicher) und Sysmon-CreateRemoteThread-Ereignisse.

Ransomware ist Malware, die Daten verschlüsselt (und zunehmend exfiltriert) und dann Zahlung fordert. Im aktiven Fall: betroffene Hosts vom Netzwerk isolieren, ohne sie auszuschalten, wenn du den Speicher bewahren kannst, Umfang, Patient Zero und die Variante bestimmen, Beweise sichern, das Standbein und etwaige Backdoors finden und vertreiben, dann aus bekannt sauberen Offline-Backups wiederherstellen. Zahlen ist ein letztes Mittel und garantiert nie die Wiederherstellung.

SPF veröffentlicht, welche IPs für eine Domain Mail senden dürfen. DKIM fügt eine kryptografische Signatur hinzu, damit der Empfänger prüfen kann, dass die Nachricht nicht verändert wurde und von der Domain stammt. DMARC bindet die SPF/DKIM-Ergebnisse über das Alignment an den sichtbaren From:-Header, sagt Empfängern, was bei Fehlschlag zu tun ist (none/quarantine/reject), und sendet Berichte. SPF und DKIM allein schützen das vom Nutzer gesehene From nicht – DMARC erzwingt das.

Statische Analyse untersucht ein Sample, ohne es auszuführen – Hashes, Strings, Imports, Header und Disassemblierung –, ist also sicher und vollständig in der Abdeckung, aber durch Packing und Obfuskation besiegbar. Dynamische Analyse zündet das Sample in einer isolierten Sandbox und beobachtet echtes Verhalten – Dateien, Registry, Prozesse, Netzwerk –, was Obfuskation durchschneidet, aber nur zeigt, was in dieser Sitzung läuft, und von sandbox-bewusster Malware umgangen werden kann. Analysten kombinieren beide.

Ein Honeypot ist ein Ködersystem oder -dienst ohne legitimen geschäftlichen Zweck, das bewusst exponiert wird, um Angreifer anzulocken. Da nichts Gutartiges ihn je berühren sollte, ist jede Interaktion ein hochsicherer Alarm. Honeypots mit niedriger Interaktion emulieren Dienste günstig; solche mit hoher Interaktion sind echte Systeme, die reichere Intel liefern, aber mehr Risiko bergen. Honeytokens sind dieselbe Idee, angewandt auf gefälschte Anmeldedaten, Dateien oder Datensätze. Wert: frühe Erkennung, wenige Fehlalarme und Threat Intelligence.

Das Security-Protokoll ist primär: 4624 erfolgreiche Anmeldung (mit Anmeldetyp), 4625 fehlgeschlagene Anmeldung, 4634/4647 Abmeldung, 4672 spezielle Rechte zugewiesen, 4720 Konto erstellt, 4688 Prozesserstellung (mit Befehlszeile, falls aktiviert) und 4768/4769 Kerberos. Ergänze 7045 Dienstinstallation (System-Protokoll), 4698 geplante Aufgabe erstellt und PowerShell-Skriptblock-Protokollierung (4104). Anmeldetyp und Befehlszeilen-Auditing machen diese Protokolle nützlich.

Verschlüsselung während der Übertragung (TLS) schützt Daten, die über das Netz wandern, vor Abhören und Manipulation; erzwinge TLS überall und lehne Klartext ab. Verschlüsselung im Ruhezustand schützt gespeicherte Daten auf Festplatten und Backups, typischerweise über KMS-verwaltete Schlüssel mit Umschlagverschlüsselung. Beide sind Basiskontrollen, aber keine stoppt eine autorisierte, aber bösartige Anfrage — der Dienst entschlüsselt transparent für gültige Aufrufer — daher bleibt Zugriffskontrolle am wichtigsten.

Ein Benutzer ist eine langlebige Identität mit permanenten Anmeldedaten; eine Rolle ist eine Identität ohne permanente Anmeldedaten, die jeder vertrauenswürdige Principal annehmen kann, um kurzlebige Tokens zu erhalten; eine Richtlinie ist das JSON-Dokument, das Berechtigungen gewährt und an beide angehängt wird. Geringste Rechte bedeutet, Rollen Benutzern vorzuziehen, Richtlinien auf konkrete Aktionen und Ressourcen einzugrenzen und nur das zu gewähren, was eine Aufgabe braucht — und im Lauf der Zeit zu überprüfen und auszumisten.

Security Groups sind zustandsbehaftete Firewalls, die an Instanzen/ENIs angehängt sind: Sie haben nur Allow-Regeln, und der Rückverkehr eines erlaubten Flusses wird automatisch zugelassen. Network ACLs sind zustandslose Filter an der Subnetzgrenze: Sie haben geordnete Allow- und Deny-Regeln, und du musst den Rückverkehr auf ephemeren Ports explizit erlauben. Security Groups sind die primäre Kontrolle; NACLs ergänzen grobe Leitplanken auf Subnetzebene wie das Blockieren eines IP-Bereichs.

Der Anbieter sichert die Cloud selbst ab — physische Rechenzentren, Hardware, den Hypervisor und die von ihm betriebenen verwalteten Dienste. Du sicherst ab, was du in die Cloud stellst — deine Daten, Identitäten, Konfigurationen, das OS-Patching wo zutreffend und die Zugriffskontrollen. Die genaue Grenze verschiebt sich: Bei IaaS besitzt du das OS aufwärts, bei SaaS besitzt du vor allem Daten und Zugriff.

RSA ist ein asymmetrischer Algorithmus, der Daten verschlüsselt oder digitale Signaturen mit einem Schlüsselpaar erstellt. Diffie-Hellman ist ein Schlüsselaustauschprotokoll, mit dem zwei Parteien über einen öffentlichen Kanal ein gemeinsames Geheimnis ableiten, ohne es je zu übertragen. Sie lösen verschiedene Probleme: RSA beweist Identität und kann Schlüssel einpacken; DH handelt einen Sitzungsschlüssel aus, und seine flüchtige Variante bietet Forward Secrecy.

Eine digitale Signatur ist der mit dem privaten Schlüssel des Unterzeichners umgewandelte Hash einer Nachricht. Der Prüfer berechnet den Hash neu, wendet den öffentlichen Schlüssel des Unterzeichners an und prüft auf Übereinstimmung. Da nur der Unterzeichner den privaten Schlüssel besitzt, beweist eine gültige Signatur, dass die Nachricht von ihm stammt (Authentizität), nicht verändert wurde (Integrität) und dass er es nicht glaubhaft abstreiten kann (Nichtabstreitbarkeit).

Ein HMAC ist ein schlüsselbasierter Nachrichtenauthentifizierungscode: Er hasht die Nachricht zusammen mit einem geheimen Schlüssel über eine verschachtelte Konstruktion (innerer und äußerer Hash mit schlüsselabgeleiteten Pads). Er beweist sowohl Integrität (die Nachricht wurde nicht verändert) als auch Authentizität (sie stammt von jemandem mit dem Schlüssel). Ein einfacher Hash beweist keines von beiden, da ihn jeder neu berechnen kann; HMAC widersteht zudem Length-Extension-Angriffen.

Ein JWT besteht aus drei base64url-Teilen – Header, Payload (Claims) und Signatur – durch Punkte verbunden. Der Server signiert Header und Payload mit einem Geheimnis oder privaten Schlüssel und verifiziert diese Signatur bei jeder Anfrage, um den Claims ohne serverseitigen Sitzungszustand zu vertrauen. Fallstricke: alg=none akzeptieren, RS256-zu-HS256-Schlüsselverwechslung, Ablauf/Aussteller/Zielgruppe nicht zu validieren, Geheimnisse in die lesbare Payload zu legen und keinen Widerrufsweg zu haben.

Kerberos stützt sich auf ein vertrauenswürdiges Key Distribution Center (KDC). Der Client authentifiziert sich einmal beim Authentication Server und erhält ein mit dem Schlüssel des KDC verschlüsseltes Ticket-Granting-Ticket (TGT). Um einen Dienst zu erreichen, legt er das TGT dem Ticket-Granting-Service vor und erhält ein mit dem Schlüssel dieses Dienstes verschlüsseltes Service-Ticket. Der Dienst entschlüsselt es und vertraut ihm. Passwörter durchqueren nie das Netz, und Tickets sind zeitlich begrenzt.

Die App leitet den Benutzer zum Autorisierungsserver weiter, um sich anzumelden und einzuwilligen. Der Server leitet mit einem kurzlebigen Autorisierungscode zurück. Das Backend der App tauscht diesen Code (plus sein Client-Geheimnis) dann am Token-Endpunkt über einen Server-zu-Server-Back-Channel gegen ein Access-Token. Das hält Tokens aus Browser/URL fern. Öffentliche Clients ergänzen PKCE, um den Code an den ursprünglichen Anforderer zu binden.

Speichere Passwörter mit einer bewusst langsamen, gesalzenen, adaptiven Passwort-Hashfunktion – bcrypt, scrypt oder Argon2 – nie mit einem schnellen Allzweck-Hash wie SHA-256 oder MD5. Schnelle Hashes sind auf Geschwindigkeit ausgelegt, sodass Angreifer mit GPUs Milliarden Versuche pro Sekunde gegen eine geleakte Datenbank testen können. Langsame Hashes haben einen einstellbaren Arbeitsfaktor (und Speicherkosten), der jeden Versuch teuer macht und Brute Force selbst nach einem Leak unpraktikabel hält.

Perfect Forward Secrecy (PFS) bedeutet, dass jede Sitzung einen einzigartigen Schlüssel aus einem flüchtigen Schlüsselaustausch ableitet, der danach verworfen wird. Stiehlt ein Angreifer später den langlebigen privaten Schlüssel des Servers, kann er zuvor erfassten Verkehr dennoch nicht entschlüsseln, weil dieser Schlüssel nie zur Ableitung der Sitzungsschlüssel diente. Erreicht wird das mit flüchtigem Diffie-Hellman (DHE/ECDHE).

Ein Salt ist ein einzigartiger Zufallswert, der pro Benutzer erzeugt und vor dem Hashing mit dem Passwort kombiniert wird. Er sorgt dafür, dass identische Passwörter unterschiedliche Hashes ergeben, und macht vorberechnete Angriffe wie Rainbow Tables nutzlos, da der Angreifer pro Salt eine eigene Tabelle bräuchte. Salts werden neben dem Hash gespeichert. Ein Pepper ist ein zusätzlicher geheimer Wert, für alle Benutzer gleich, getrennt aufbewahrt (z. B. in der App-Konfiguration oder einem HSM), sodass ein Datenbankleck allein nicht genügt.

SSO zentralisiert die Authentifizierung bei einem Identity Provider (IdP). Besucht ein Benutzer einen Service Provider (die App), leitet die App zum IdP weiter; der Benutzer meldet sich einmal an, und der IdP gibt eine signierte Assertion oder ein Token zurück, das seine Identität bürgt. SAML trägt dies als signierte XML-Assertion; OIDC trägt es als signiertes JSON-ID-Token auf OAuth 2.0. Die App vertraut der Signatur des IdP, statt Passwörter selbst zu handhaben.

TOTP (Time-based One-Time Password) kombiniert ein bei der Einrichtung festgelegtes gemeinsames Geheimnis mit der aktuellen, in feste Fenster (meist 30 Sekunden) unterteilten Zeit. Es führt HMAC über den Zeitschritt-Zähler mit dem Geheimnis aus und kürzt das Ergebnis dann auf einen 6-stelligen Code. Sowohl App als auch Server halten dasselbe Geheimnis und dieselbe Uhr, sodass sie unabhängig denselben Code berechnen – ohne Netzwerkaufruf. Der Code wechselt mit jedem Fenster.

IaC-Scanning analysiert Terraform-, CloudFormation-, Kubernetes- und ähnliche Definitionen statisch gegen eine Richtlinie, um Fehlkonfigurationen zu finden — öffentliche S3-Buckets, offene Security Groups, fehlende Verschlüsselung — bevor sie überhaupt bereitgestellt werden. Da dieselbe Vorlage viele Ressourcen bereitstellt, verhindert eine einmalige Korrektur wiederkehrende Drift, und das Erkennen vor dem Anwenden ist weitaus günstiger als das Beheben aktiver Cloud-Ressourcen. Zu den Tools gehören Checkov, tfsec und KICS, idealerweise als Policy-as-Code-Gates durchgesetzt.

SAST liest den Quellcode, ohne ihn auszuführen, und findet Fehler wie Injection-Sinks früh, aber mit vielen Fehlalarmen. DAST greift die laufende Anwendung von außen ohne Code-Einblick an und findet echte ausnutzbare Probleme, aber spät und mit oberflächlicher Abdeckung. IAST instrumentiert die laufende Anwendung, um Laufzeitverhalten mit dem Code zu korrelieren, und liefert präzise Ergebnisse mit Code-Kontext, benötigt aber eine ausgeübte Anwendung und Agent-Unterstützung.

Ein SBOM ist ein maschinenlesbares Inventar jeder Komponente, Bibliothek und Abhängigkeit in einer Software, mit Versionen und idealerweise Hashes. Es ist wichtig, weil man bei einer neuen Schwachstelle seine SBOMs abfragen kann, um sofort zu beantworten «Sind wir betroffen und wo?», statt in Hektik zu verfallen. Die beiden dominierenden Standards sind SPDX und CycloneDX, und SBOMs werden zunehmend durch Regulierung und Beschaffung gefordert.

Client und Server einigen sich in einem einzigen Roundtrip mittels ephemerem Diffie-Hellman (ECDHE) auf ein gemeinsames Geheimnis. Das ClientHello trägt die unterstützten Gruppen und einen Key Share; der Server antwortet mit seinem Key Share und Zertifikat, beide Seiten leiten dieselben Schlüssel ab, und Anwendungsdaten fließen sofort, mit Forward Secrecy als Standard.

Die CIA-Triade umfasst die drei Kernziele der Informationssicherheit: Vertraulichkeit (nur autorisierte Parteien können Daten lesen), Integrität (Daten werden nicht unbefugt verändert) und Verfügbarkeit (autorisierte Nutzer können bei Bedarf auf Systeme zugreifen). Nahezu jede Maßnahme lässt sich einem oder mehreren dieser Ziele zuordnen.

Defense in Depth bedeutet, mehrere unabhängige Sicherheitsmaßnahmen zu schichten, sodass bei Ausfall einer Maßnahme die anderen das Asset weiterhin schützen. Sie geht davon aus, dass keine einzelne Maßnahme perfekt ist — etwa durch die Kombination von Firewall, Netzwerksegmentierung, Endpunktschutz, MFA, Least Privilege und Verschlüsselung, statt sich allein auf den Perimeter zu verlassen.

Kodierung (wie Base64) ist eine reversible Formatänderung ohne Geheimnis — keine Sicherheit. Verschlüsselung ist mit einem Schlüssel reversibel und schützt die Vertraulichkeit. Hashing ist eine Einwegfunktion, die einen Digest fester Länge erzeugt, für Integritätsprüfungen und Passwortspeicherung verwendet wird und nicht zur Eingabe zurückgerechnet werden kann.

Ein IDS (Intrusion Detection System) überwacht den Datenverkehr und löst Alarme aus, blockiert aber nicht — es liegt typischerweise außerhalb des Datenpfads. Ein IPS (Intrusion Prevention System) sitzt inline im Datenpfad und kann bösartigen Verkehr aktiv verwerfen oder blockieren. Das IPS verhindert, aber ein Fehlalarm kann legitimen Verkehr unterbrechen.

Least Privilege bedeutet, dass jeder Nutzer, Prozess und Dienst nur den für seine Aufgabe minimal erforderlichen Zugriff erhält und nicht mehr. Es begrenzt den Wirkungsradius eines kompromittierten Kontos, senkt das Insider-Bedrohungsrisiko und verkleinert die Angriffsfläche. Man wendet es über rollenbasierten Zugriff, regelmäßige Zugriffsüberprüfungen und Just-in-Time-Erhöhung an.

MFA erfordert zwei oder mehr Authentifizierungsfaktoren aus unterschiedlichen Kategorien — etwas, das man weiß (Passwort), etwas, das man hat (Telefon/Token), etwas, das man ist (Biometrie). Sie hilft, weil ein Angreifer, der einen Faktor wie ein Passwort stiehlt, sich ohne die anderen trotzdem nicht anmelden kann. Phishing-resistente MFA wie FIDO2 ist am stärksten.

Phishing ist Social Engineering, das Menschen dazu verleitet, Anmeldedaten preiszugeben, Geld zu überweisen oder Malware auszuführen, meist über gefälschte E-Mails oder Websites. Die Abwehr ist geschichtet: E-Mail-Filterung und -Authentifizierung (SPF/DKIM/DMARC), MFA zur Begrenzung des Schadens gestohlener Anmeldedaten, Awareness-Schulungen und eine einfache Möglichkeit, verdächtige Nachrichten zu melden.

Symmetrische Verschlüsselung nutzt einen einzigen gemeinsamen geheimen Schlüssel zum Ver- und Entschlüsseln und ist schnell, doch beide Parteien müssen den Schlüssel bereits teilen. Asymmetrische nutzt ein öffentlich/privates Schlüsselpaar und löst das Problem der Schlüsselverteilung, aber langsamer. Echte Protokolle wie TLS nutzen asymmetrische Kryptografie, um einen symmetrischen Schlüssel auszutauschen, und wechseln dann für die Massendaten zu symmetrischer.

TCP ist verbindungsorientiert und zuverlässig: Es nutzt einen Drei-Wege-Handshake, garantiert geordnete Zustellung und überträgt verlorene Pakete erneut. UDP ist verbindungslos und schnell, ohne Garantien für Zustellung, Reihenfolge oder Überlastkontrolle. Nutzen Sie TCP für Genauigkeit (Web, E-Mail, Dateiübertragung) und UDP für geschwindigkeitssensiblen Verkehr (DNS, VoIP, Streaming, Gaming).

Eine Schwachstelle ist eine Schwäche (ungepatchte Software). Eine Bedrohung ist ein Akteur oder Ereignis, das sie ausnutzen könnte (eine Ransomware-Gruppe). Risiko ist die Kombination aus der Wahrscheinlichkeit, dass eine Bedrohung eine Schwachstelle ausnutzt, und der Auswirkung, falls dies geschieht. Risiko = Bedrohung x Schwachstelle x Auswirkung, und das ist es, was man tatsächlich priorisiert.

Eine Firewall steuert den Verkehr zwischen Netzwerkzonen, indem sie ihn anhand von Regeln zulässt oder verweigert. Eine zustandslose Firewall bewertet jedes Paket isoliert gegen die Regeln; eine zustandsbehaftete Firewall verfolgt den Zustand von Verbindungen, um Rückverkehr für von ihr erlaubte Sitzungen zuzulassen. Next-Gen-Firewalls ergänzen das Bewusstsein für die Anwendungsschicht.

Ein Zero-Day ist eine Schwachstelle, die der Hersteller noch nicht kennt (oder nicht gepatcht hat), sodass die Verteidiger „null Tage“ hatten, um sie zu beheben. Da kein Patch existiert, stützt sich die Abwehr auf geschichtete Maßnahmen, verhaltensbasierte Erkennung, Segmentierung, Least Privilege und schnelle Incident Response statt auf eine Signatur.

Weder noch. ARP ist ein Layer-2-Protokoll (Sicherungsschicht), das direkt in einem Ethernet-Frame gekapselt wird und nicht in einem IP-Paket. Da es niemals über IP läuft, kann es weder TCP noch UDP verwenden — das sind Layer-4-Transporte, die IP darunter benötigen. Die Aufgabe von ARP besteht darin, eine bekannte IP-Adresse zur passenden MAC-Adresse im selben lokalen Netzsegment aufzulösen.

Zuerst komprimieren, dann verschlüsseln. Gute Verschlüsselung erzeugt eine Ausgabe, die statistisch nicht von Zufall zu unterscheiden ist, sodass im Chiffretext keine Muster mehr zum Komprimieren übrig bleiben — danach zu komprimieren ist sinnlos. Der wichtige Vorbehalt: geheime und vom Angreifer kontrollierte Daten vor der Verschlüsselung gemeinsam zu komprimieren kann über die Chiffretext-Länge Informationen verraten, genau das sind die Angriffe CRIME und BREACH.

Weil „löschen“ die Daten normalerweise nicht beseitigt. Es entfernt die Dateisystem-Metadaten — den Zeiger/den Verzeichniseintrag — und markiert die Blöcke als frei, aber die ursprünglichen Bytes bleiben auf der Platte, bis das Betriebssystem diese Blöcke für neue Daten wiederverwendet. Bis dieses Überschreiben geschieht, können forensische Werkzeuge den Inhalt direkt herausziehen.

Kodierung wandelt Daten zur Kompatibilität in ein anderes Format um und ist von jedem ohne Schlüssel vollständig umkehrbar (z. B. Base64, URL-Kodierung) — sie bietet keine Vertraulichkeit. Verschlüsselung ist nur mit einem Schlüssel umkehrbar und sorgt für Vertraulichkeit. Hashing ist eine Einwegfunktion: Man kann die Eingabe nicht aus der Ausgabe wiederherstellen, weshalb es sich für Integritätsprüfungen und die Passwortspeicherung eignet (mit Salt und einer langsamen KDF).

Aus rein sicherheitstechnischer Sicht ist ein False Negative meist schlimmer: Es bedeutet, dass ein echter Angriff unentdeckt blieb, also gibt es keine Reaktion, keine Eindämmung, und der Vorfall kann unentdeckt schwelen. Aber False Positives sind nicht harmlos — in großer Zahl verursachen sie Alert-Fatigue, bei der Analysten beginnen, Alarme zu ignorieren und den echten zu verpassen. Die richtige Antwort nennt den Kompromiss, nicht nur einen Gewinner.

Gefiltert. Ein gefilterter Port verwirft das Paket still, sodass der Scanner keine Antwort erhält und auf ein Timeout warten muss — er erfährt nichts darüber, ob der Host überhaupt existiert, und der Scan wird drastisch verlangsamt. Ein geschlossener Port sendet ein TCP-RST zurück, das bestätigt, dass der Host lebt und antwortet, und liefert dem Angreifer so gratis Aufklärungswert.

Nein. Das Schloss bedeutet, dass der Transport verschlüsselt und das Zertifikat für diese Domain gültig ist — es sagt nichts darüber aus, ob der Betreiber ehrlich oder der Inhalt bösartig ist. Kostenlose, automatisierte Zertifikate führen dazu, dass Phishing- und Malware-Seiten fast immer ebenfalls ein einwandfrei gültiges Schloss haben. HTTPS schützt den Kanal, nicht das Ziel.

Nicht von allein. HTTPS verhindert MITM nur, wenn die Zertifikatsvalidierung strikt erzwungen wird und der Client die Website von Anfang an über HTTPS erreicht. Wenn einer Rogue-CA vertraut wird (Unternehmens-Proxy, von Malware installierte Root), wenn der Nutzer Zertifikatswarnungen wegklickt oder wenn SSL-Stripping die Verbindung auf HTTP herabstuft, bevor TLS startet, kann ein Angreifer sich weiterhin dazwischensetzen.

HTTPS ist kein eigenes Protokoll — es ist ganz normales HTTP, das innerhalb eines verschlüsselten TLS-Tunnels läuft. SSL ist der alte Name: SSL 2.0/3.0 sind die veralteten, unsicheren Vorgänger von TLS, das sie abgelöst hat (TLS 1.0 bis 1.3). Wenn Leute „SSL-Zertifikat“ oder „SSL“ sagen, meinen sie fast immer eigentlich TLS.

Weil sie schnell sind. MD5 und SHA-256 sind auf Geschwindigkeit ausgelegt, was für Passwörter genau falsch ist: Ein Angreifer, der die Hashes stiehlt, kann auf einer GPU Milliarden von Versuchen pro Sekunde berechnen. Die Lösung ist eine bewusst langsame, speicherharte Schlüsselableitungsfunktion — bcrypt, scrypt oder Argon2 — kombiniert mit einem Salt pro Nutzer und einem einstellbaren Arbeitsfaktor.

Fangfrage — ping verwendet keinen Port. Es läuft über ICMP, ein Layer-3-Protokoll, das direkt auf IP aufsitzt. Ports existieren nur in Layer-4-Protokollen wie TCP und UDP, daher hat ICMP (und somit ping) keinen. ICMP verwendet stattdessen Typ- und Code-Felder, z. B. Echo Request Typ 8 und Echo Reply Typ 0.

Drei. Der Client sendet ein SYN, der Server antwortet mit einem kombinierten SYN-ACK (ein Paket, das sowohl das SYN des Clients bestätigt als auch das eigene SYN des Servers sendet), und der Client schließt mit einem ACK ab. Der Trick ist, dass SYN-ACK ein einzelnes Paket ist, nicht zwei, sodass die Summe drei beträgt — genau das, was „Drei-Wege“ benennt.

Behandeln Sie Bewusstseinsbildung als Verhaltensänderung, nicht als jährliches Häkchen. Machen Sie sie rollenbasiert (eine Entwicklerin braucht andere Inhalte als die Finanzabteilung), kontinuierlich statt einer Folienpräsentation einmal im Jahr und verankert in realen Risiken wie Phishing, Social Engineering und Datenhandhabung. Verstärken Sie sie mit Phishing-Simulationen, zeitnahen Hinweisen und klaren Meldewegen. Messen Sie Ergebnisse — Phishing-Melderate, Klickrate, Zeit bis zur Meldung — nicht nur Abschlussquoten. Bauen Sie eine Kultur auf, in der Menschen Fehler ohne Angst melden, denn Angst unterdrückt das Melden.

Das moderne NIST SP 800-63B stellt Länge über Komplexität: lange Passphrasen erlauben (mindestens 8, 64+ unterstützen), alle Zeichen einschließlich Leerzeichen akzeptieren und keine Zusammensetzungsregeln wie «ein Großbuchstabe, ein Symbol» vorschreiben. Neue Passwörter gegen Listen geleakter Passwörter prüfen, den verpflichtenden periodischen Ablauf streichen (nur bei Hinweis auf Kompromittierung wechseln) und wissensbasierte «Sicherheitsfragen» verwerfen. Ziel sind Regeln, die echten Angriffen standhalten, statt Benutzer in vorhersehbare Muster zu drängen.

PAM kontrolliert und überwacht die Konten, die den größten Schaden anrichten können — Domänenadministratoren, root, Dienstkonten. Es tresoriert und rotiert ihre Anmeldedaten, damit keine Geheimnisse geteilt oder hartkodiert werden, vermittelt Sitzungen, sodass Administratoren das rohe Passwort nie sehen, zeichnet auf, was privilegierte Benutzer tun, und gewährt die Erhöhung idealerweise just-in-time statt als dauerhaften Zugriff. Ziel ist es, den Schadensradius der Konten zu verkleinern, die Angreifer am meisten begehren.

Man klassifiziert danach, wofür das Sample gebaut ist, beobachtet aus seinem Verhalten und seinen Fähigkeiten. Ein Dropper trägt eine Payload und schreibt sie auf die Festplatte; ein Loader holt oder injiziert die nächste Stufe, oft nur im Speicher; ein RAT gibt einem Operator interaktive Fernsteuerung; ein Wiper zerstört Daten oder Boot-Records ohne Wiederherstellungsabsicht; Ransomware verschlüsselt Dateien und fordert Zahlung. Echte Samples kombinieren oft Rollen — ein Loader, der ein RAT ausliefert — daher beschreibt man die Fähigkeitskette, statt ein einziges Etikett zu erzwingen, und ordnet jedes Verhalten ATT&CK-Techniken zu.

Command-and-Control-Beaconing ist der Implant, der periodisch nach Hause ruft, um Anweisungen zu erhalten. Man erkennt es an regelmäßigen, volumenarmen ausgehenden Rückrufen in etwa festem Intervall — oft mit Jitter, um nicht mechanisch zu wirken — zu einer kleinen Menge von Zielen, häufig über HTTP/HTTPS oder DNS mit kodierten oder verschlüsselten Payloads und einem unverwechselbaren User-Agent- oder URI-Muster. Indikatoren extrahiert man statisch, indem man Domains, IPs, URIs und Schlüssel aus Strings und Konfigurationsblöcken zieht, und dynamisch, indem man das Sample gegen ein gefälschtes Netzwerk detoniert und die tatsächlichen Rückrufe erfasst, dann ordnet man das Verhalten ATT&CK zu und speist die IOCs in die Erkennung ein.

Packen komprimiert oder verschlüsselt die eigentliche Payload und stellt ihr einen Stub voran, der sie zur Laufzeit in den Speicher entpackt; Obfuskation transformiert Code oder Daten, um dem Lesen und Signaturen zu widerstehen. Packen erkennt man an hoher Sektionsentropie nahe 8,0, einer winzigen oder nur aus dem Stub bestehenden Importtabelle, ungewöhnlichen oder schreib-ausführbaren Sektionsnamen wie UPX0, einem Einsprungpunkt außerhalb von .text, einer großen virtuellen Größe gegenüber einer kleinen Rohgröße sowie Detektoren wie Detect It Easy oder PEiD. Keines davon ist allein schlüssig, daher wägen Analysten mehrere Signale zusammen ab und bestätigen, indem sie das Entpacken zur Laufzeit beobachten.

Eine PE-Datei beginnt mit dem DOS-Header und seinem e_lfanew-Zeiger auf die PE/NT-Header, die den File Header und den Optional Header enthalten (Einsprungpunkt, Image Base, Subsystem). Sie ist in Sektionen unterteilt — .text für Code, .data, .rdata, .rsrc für Ressourcen — jede mit virtueller Adresse und Rohgröße. Beim Triage liest man die Importtabelle nach verdächtigen APIs, die Sektionstabelle nach seltsamen Namen und hoher Entropie, die auf Packen hindeuten, den Timestamp und den Rich Header, eingebettete Ressourcen und jede digitale Signatur. Diskrepanzen zwischen diesen verraten viel, noch bevor man die Datei ausführt.

Ein sicheres Labor isoliert die Malware von allem, das sie schädigen könnte. Du führst Samples in wegwerfbaren VMs auf einem Hypervisor aus, erstellst saubere Snapshots, sodass du nach jeder Detonation zurücksetzen kannst, und kappst echten Netzwerkzugang über ein Host-Only-Netzwerk mit simuliertem Internet (INetSim oder FakeNet) oder ein air-gapped Segment. Du trennst die Analyse-Maschine von einem kontrollierten Gateway, analysierst nie auf deinem Alltags-Host, härtest gegen VM-Escape, behandelst Samples als passwortgeschützte ZIPs und hältst Werkzeuge und Indikatoren von der Detonations-VM fern. Das Ziel ist, echtes Verhalten zu beobachten und zugleich zu garantieren, dass das Sample weder die Produktion noch das Internet erreichen kann.

Statische Werkzeuge lesen das Sample im Ruhezustand: PEStudio, CFF Explorer und pefile für Header und Imports, FLOSS und strings für eingebetteten Text, capa für das Mapping von Fähigkeiten und Ghidra oder IDA für Disassembly. Dynamische Werkzeuge beobachten es bei der Ausführung in einer isolierten VM: Procmon und Process Hacker für Host-Aktivität, Wireshark und INetSim oder FakeNet für ein gefälschtes Netzwerk, Regshot für Vorher/Nachher-Diffs und x64dbg für kontrolliertes Stepping. Der Workflow ist: statisch triagieren, dynamisch detonieren und dann zum Disassembler zurückkehren, um Verhaltenslücken zu füllen.

Eine YARA-Regel besteht aus einem meta-Block, einem strings-Abschnitt (Text-, Hex- oder Regex-Muster mit Wildcards und Sprüngen) und einer Bedingung, die diese Treffer mit boolescher und Zähllogik kombiniert. Eine wirksame Regel stützt sich auf etwas Dauerhaftes und Unverwechselbares — einen einzigartigen Code-Stub, einen Mutex-Namen, einen Konfigurationsmarker oder eine ungewöhnliche Import-Kombination — statt auf Werte, die ein Angreifer trivial ändert wie einen einzelnen Hash oder einen generischen String. Man wägt Spezifität gegen Fehlalarme ab, testet gegen einen sauberen Korpus und dokumentiert die Regel, damit andere ihr vertrauen und sie pflegen.

Coordinated Vulnerability Disclosure ist ein Prozess, bei dem ein Forscher eine Schwachstelle privat an den Hersteller meldet, beide Seiten sich auf Behebung und Zeitplan einigen und Details erst veröffentlicht werden, sobald ein Fix verfügbar ist (oder eine vereinbarte Frist abläuft). Sie wägt die Zeit zum Patchen für Verteidiger gegen das Recht der Öffentlichkeit auf Information ab. Eine security.txt-Datei und eine klare Richtlinie machen das Melden reibungslos; Bug-Bounty-Programme fügen darauf strukturierte Belohnungen hinzu.

DFIR folgt einem disziplinierten Prozess: Identifikation (Vorfall bestätigen und eingrenzen), Sicherung (Beweise nach Order of Volatility bewahren, mit forensischen Images und Hashes), Analyse (Zeitachse, Grundursache, Umfang der Kompromittierung) und Reporting (Befunde für technische und juristische Zielgruppen). Die Chain of Custody dokumentiert, wer jedes Artefakt wann angefasst hat, damit die Beweise standhalten, falls sie je vor Gericht landen. Bewahren vor Beheben.

ATT&CK ist eine Wissensbasis realer Angreifer-Taktiken (das Warum), Techniken (das Wie) und Prozeduren. Sie nutzen es, um Ihre bestehenden Detektionen auf die Matrix zu mappen, Abdeckungslücken zu finden und die Techniken zu priorisieren, die von Akteuren genutzt werden, die tatsächlich Ihre Branche angreifen. Es bietet eine gemeinsame Sprache zwischen CTI, Detection Engineering und IR und verwandelt die Frage nach der Sicherheit in eine konkrete, messbare Abdeckungskarte, getrieben vom realen Angreiferverhalten.

Purple Teaming ist kollaborativ statt gegnerisch: Die rote Seite führt konkrete, vereinbarte TTPs aus (oft an MITRE ATT&CK ausgerichtet), während die blaue Seite ihre Telemetrie in Echtzeit beobachtet, um zu bestätigen, ob jede Technik geloggt, alarmiert und erkennbar ist. Sie messen die Detektionsabdeckung Technik für Technik, justieren Detektionen und schließen Lücken sofort, dann testen Sie erneut. Das Deliverable ist eine verbesserte, messbare Detektion — keine Liste, wer gewonnen hat.

Schwachstellenmanagement ist eine fortlaufende Schleife: Assets und Schwachstellen entdecken (Scanning, Asset-Inventar), nach echtem Risiko priorisieren (CVSS plus Ausnutzbarkeit, Exposition und Asset-Kritikalität — Frameworks wie EPSS und SSVC helfen), beheben oder mindern, den Fix verifizieren und über Trends und SLAs berichten. Der Scan ist der leichte Teil; die Disziplin liegt darin, zu priorisieren und die Schleife zu schließen, damit das Risiko mit der Zeit tatsächlich sinkt.

SSH nutzt TCP 22, HTTP TCP 80, HTTPS TCP 443, DNS den 53 (UDP und TCP), RDP TCP 3389 und SMB TCP 445. Die Well-Known-Ports zu kennen, erlaubt es, Scan-Ausgaben zu lesen, Firewall-Regeln zu schreiben und Alarme schnell zu triagieren — ein Dienst auf seinem erwarteten Port statt auf einem unerwarteten ist ein sofortiges Signal.

Ein Stub-Resolver fragt einen rekursiven Resolver nach einem Namen. Ist er nicht im Cache, durchläuft der rekursive Resolver die Hierarchie: Er fragt einen Root-Server (der auf die TLD verweist), den TLD-Server (der auf die autoritativen Server der Domain verweist) und schließlich den autoritativen Server, der den eigentlichen Eintrag hält. Die Antwort wird unterwegs gemäß ihrer TTL gecacht. DNS nutzt Port 53 — UDP für die meisten Anfragen, TCP für große.

Ein Forward-Proxy steht vor den Clients und stellt ausgehende Anfragen in deren Namen — für Egress-Kontrolle, Filterung, Caching und Anonymität. Ein Reverse-Proxy steht vor den Servern und empfängt eingehende Anfragen in deren Namen — für Lastausgleich, TLS-Terminierung, Caching und als Sicherheitsfassade für eine WAF. Die Richtung, in die er zeigt, clientseitig oder serverseitig, ist die entscheidende Unterscheidung.

Traceroute entdeckt die Router zwischen Ihnen und einem Ziel, indem es das TTL-Feld ausnutzt. Es sendet Pakete mit TTL=1, dann 2, dann 3 und so weiter. Jeder Router verringert die TTL; erreicht die TTL null, verwirft dieser Router das Paket und gibt eine ICMP-Time-Exceeded-Nachricht zurück, die seine Adresse offenbart. Durch das schrittweise Erhöhen der TTL bildet traceroute jeden Hop der Reihe nach ab, bis das Ziel erreicht ist.

NAT (Network Address Translation) schreibt die Quell- und/oder Ziel-IP um, während Pakete eine Grenze überqueren, und bildet typischerweise private interne Adressen auf öffentliche ab. PAT (Port Address Translation oder NAT Overload) erweitert dies, indem es auch Ports übersetzt, sodass viele interne Hosts sich eine einzige öffentliche IP teilen — jeder Fluss durch seinen Port unterschieden. PAT ist das, was Heim- und Büro-Router nutzen, um ein ganzes LAN hinter eine Adresse zu setzen.

Das OSI-Modell teilt Netzwerke in sieben Schichten, von denen jede eine Verantwortung hinzufügt: Bitübertragung (Bits auf dem Kabel), Sicherung (Frames und MAC-Adressierung), Vermittlung (IP-Routing), Transport (TCP/UDP, Ports, Zuverlässigkeit), Sitzung (Verwaltung von Verbindungen), Darstellung (Kodierung, Verschlüsselung, Kompression) und Anwendung (Protokolle wie HTTP). Jede Schicht kapselt die darüberliegende, während die Daten den Stapel hinabwandern.

Ein Subnetz ist eine logische Unterteilung eines IP-Netzes. Die Subnetzmaske markiert, welche Bits einer IP-Adresse der Netz-Anteil und welche der Host-Anteil sind — zum Beispiel bedeutet /24 (255.255.255.0), dass die ersten 24 Bit das Netz und die letzten 8 die Hosts kennzeichnen. Subnetting steuert, wie Verkehr geroutet wird, und erlaubt es, ein Netz in kleinere Broadcast-Domänen zu segmentieren.

TCP öffnet eine Verbindung in drei Schritten. Der Client sendet ein SYN mit einer initialen Sequenznummer, der Server antwortet mit SYN-ACK (bestätigt die Nummer des Clients und sendet seine eigene), und der Client gibt ein ACK zurück. Nach diesem Austausch haben sich beide Seiten auf die Start-Sequenznummern geeinigt, und die Verbindung ist für eine zuverlässige, geordnete Byte-Zustellung aufgebaut.

TCP ist verbindungsorientiert: es macht einen Handshake, nummeriert Bytes, überträgt Verluste neu und steuert die Überlastung, was eine zuverlässige geordnete Zustellung auf Kosten von Latenz und Overhead bietet. UDP ist verbindungslos und nach dem Prinzip senden-und-vergessen — kein Handshake, keine Neuübertragung, keine Ordnung. Nutzen Sie TCP, wenn Korrektheit zählt (Web, E-Mail, Dateiübertragung), und UDP, wenn Geschwindigkeit mehr zählt als Perfektion (DNS, VoIP, Gaming, Video).

Das TCP/IP-Modell hat vier Schichten — Netzzugang, Internet, Transport und Anwendung — und beschreibt, wie das reale Internet funktioniert. OSI hat sieben. Sie bilden eng aufeinander ab: Die Anwendungsschicht von TCP/IP nimmt die Anwendungs-, Darstellungs- und Sitzungsschicht von OSI auf; seine Netzzugangsschicht vereint die Bitübertragungs- und Sicherungsschicht von OSI. OSI ist die bessere Referenz zum Lehren und zur Fehlersuche; TCP/IP ist die tatsächlich umgesetzte Protokollsuite.

Ein VLAN (Virtual LAN) partitioniert einen physischen Switch logisch in getrennte Layer-2-Broadcast-Domänen, sodass Geräte in unterschiedlichen VLANs sich selbst auf derselben Hardware nicht direkt erreichen können. Es wird auf Trunk-Verbindungen mit einem 802.1Q-Tag gekennzeichnet. Der Sicherheitswert ist die Segmentierung: das Isolieren von Benutzer-, Server-, Gast- und IoT-Verkehr begrenzt die Broadcast-Reichweite und die laterale Bewegung, wobei VLAN-übergreifender Verkehr durch einen Router oder eine Firewall geleitet wird, wo Richtlinien angewendet werden.

Ein VPN erstellt einen verschlüsselten Tunnel auf Netz-/Betriebssystemebene, sodass der gesamte Verkehr eines Geräts hindurchgeleitet und Ende-zu-Ende geschützt wird — genutzt für sicheren Fernzugriff. Ein Proxy arbeitet auf Anwendungsebene, leitet den Verkehr bestimmter Anwendungen oder Protokolle weiter und verschlüsselt ihn nicht zwingend. Die großen Unterschiede sind der Geltungsbereich (ganzes Gerät vs. pro Anwendung) und dass ein VPN per Design verschlüsselt, während viele Proxys das nicht tun.

Eine DMZ (demilitarisierte Zone) ist ein Netzsegment, das zwischen dem nicht vertrauenswürdigen Internet und dem vertrauenswürdigen internen Netz sitzt und öffentlich erreichbare Dienste wie Web-, Mail- und DNS-Server beherbergt. Firewall-Regeln lassen das Internet die DMZ erreichen, beschränken aber den Zugriff der DMZ auf das interne Netz streng. Das Ziel ist Eindämmung: wird ein öffentlicher Server kompromittiert, steckt der Angreifer in der Pufferzone fest, statt im LAN zu landen.

Ein Schwachstellenscan ist eine automatisierte, in die Breite gehende Bestandsaufnahme potenzieller Schwächen, oft mit Fehlalarmen. Ein Penetrationstest ist menschengeführt: Er validiert Funde, verkettet sie und demonstriert durch tatsächliche Ausnutzung echte geschäftliche Auswirkungen.

Defense in Depth bedeutet, mehrere unabhängige Sicherheitskontrollen zu staffeln, sodass bei Versagen einer Kontrolle die anderen das Asset weiterhin schützen. Keine Kontrolle gilt als perfekt, daher stapelt man präventive, detektierende und reagierende Maßnahmen über die Schichten Netzwerk, Host, Anwendung und Daten.

Angriffsfläche reduzieren (ungenutzte Pakete/Dienste entfernen), SSH nur per Schlüssel und ohne Root-Login erzwingen, das System gepatcht halten, eine Default-Deny-Firewall betreiben, die nur nötige Ports freigibt, geringste Rechte über sudo und Dateirechte durchsetzen, auditd und zentrales Logging aktivieren sowie Integritätsüberwachung plus ein MAC wie SELinux oder AppArmor ergänzen.

Verschlüsselung ist umkehrbar – mit dem Schlüssel erhältst du den Klartext zurück; sie schützt die Vertraulichkeit. Hashing ist eine Einwegfunktion, die einen Digest fester Größe erzeugt, den man nicht umkehren kann; es verifiziert Integrität und Identität. Passwörter sollten mit einem langsamen, gesalzenen Algorithmus wie bcrypt oder Argon2 gehasht, niemals verschlüsselt werden.

Geringste Rechte bedeutet, dass jeder Benutzer, Prozess oder Dienst nur den minimal für seine Aufgabe nötigen Zugriff erhält, und nicht mehr. Das verkleinert den Wirkungsradius jeder Kompromittierung oder jedes Fehlers. Man setzt es mit rollenbasiertem Zugriff, Just-in-Time-Erhöhung, regelmäßigen Zugriffsüberprüfungen und der Abschaffung dauerhafter Adminrechte durch.

Secrets niemals fest im Quellcode codieren oder in Git committen. In einem dedizierten Secrets Manager oder Vault speichern, zur Laufzeit injizieren, den Zugriff mit geringsten Rechten begrenzen, regelmäßig rotieren und kurzlebige dynamische Anmeldeinformationen langlebigen statischen vorziehen. Jeden Zugriff auditieren.

Überall TLS erzwingen, jede Anfrage authentifizieren (z. B. OAuth2/OIDC-Tokens) und pro Objekt autorisieren, sodass Benutzer nur ihre eigenen Daten erreichen. Eingabevalidierung, Rate Limiting und Kontingente, Schemavalidierung sowie gründliches Logging ergänzen. Der häufigste API-Fehler ist gebrochene objektbezogene Autorisierung, also prüfe bei jedem Ressourcenzugriff die Eigentümerschaft.

Symmetrische Verschlüsselung nutzt einen gemeinsamen Schlüssel zum Ver- und Entschlüsseln – schnell, aber der Schlüssel muss sicher geteilt werden. Asymmetrische Verschlüsselung nutzt ein Schlüsselpaar aus öffentlich/privat, was die Schlüsselverteilung löst, aber langsam ist. Reale Systeme nutzen asymmetrische Kryptografie, um einen symmetrischen Sitzungsschlüssel auszutauschen, und dann die schnelle symmetrische Chiffre für die Massendaten.

Eine PKI ist das System aus CAs, Zertifikaten und Richtlinien, das öffentliche Schlüssel an Identitäten bindet. Um ein Serverzertifikat zu validieren, baut ein Client eine Kette zu einer vertrauenswürdigen Wurzel auf, prüft jede Signatur, kontrolliert Gültigkeitsdaten und Hostname, bestätigt die Schlüsselverwendung und prüft die Sperrung über CRL oder OCSP.

Alert-Fatigue ist die Abstumpfung, die einsetzt, wenn Analysten mit zu vielen wertarmen Alerts oder Fehlalarmen konfrontiert sind, sodass sie echte Alerts übersehen oder überhastet bearbeiten. Man bekämpft sie, indem man laute Regeln tunt, nach Risiko priorisiert, zusammenhängende Alerts dedupliziert und gruppiert, repetitive Anreicherung mit einem SOAR automatisiert und die Qualität der Alerts misst, nicht nur die Menge.

Brute Force zielt auf ein einzelnes Konto mit vielen Passwortversuchen, daher sieht man viele Fehlschläge auf einen Benutzernamen konzentriert. Password Spray dreht das um: ein oder wenige gängige Passwörter über viele Konten probiert, langsam und unauffällig, sodass jedes Konto nur ein paar Fehlschläge sieht. Das Erkennungssignal ist das Verhältnis von Konten zu Fehlschlägen und das Timing, nicht die reine Anzahl der Fehlschläge.

Fast alles berührt DNS, daher offenbaren DNS-Logs Bedrohungen, die andere Quellen verpassen: Command-and-Control-Beaconing (regelmäßige Callbacks zu einer Domain), DNS-Tunneling und -Exfiltration (hohes Volumen langer, kodierter Subdomains) sowie algorithmisch generierte (DGA) Domains. Man erkennt sie über Muster wie Abfrageregelmäßigkeit, Entropie, Record-Typen und Volumen statt über eine einzelne verdächtige Abfrage.

EDR ist endpointfokussiert: Es zeichnet Prozess-, Datei- und Netzwerkaktivität auf Hosts auf und reagiert darauf. XDR erweitert diese Korrelation über mehrere Domänen — Endpoint, Netzwerk, Identität, E-Mail, Cloud — als eine herstellerintegrierte Stack. SIEM ist die breite Log-Aggregationsschicht, die Daten aus allem aufnimmt, auch aus sicherheitsfremden Quellen, für Detektion, Suche und Compliance.

Verstehen Sie zuerst, warum die Regel so oft auslöst — finden Sie das gemeinsame harmlose Muster hinter dem Rauschen. Schreiben Sie dann die engstmögliche Ausnahme (bestimmter Host, Konto oder Verhalten), dokumentieren Sie die Begründung und prüfen Sie, dass ein echter Treffer weiterhin auslösen würde. Vermeiden Sie breite Unterdrückungen, die still blinde Flecken schaffen.

Lateral Movement bedeutet, dass ein Angreifer einen Fußabdruck nutzt, um andere Systeme zu erreichen. Anzeichen sind unerwartete Netzwerk-Logons (Typ 3) und RDP (Typ 10), Zugriff auf Admin-Shares wie C$ und ADMIN$, Remote-Ausführungstools wie PsExec, WMI und WinRM, Pass-the-Hash-Muster und ein normalerweise lokales Konto, das sich plötzlich an vielen Hosts authentifiziert.

ATT&CK ist eine Wissensbasis realer gegnerischer Taktiken und Techniken. In einem SOC bildet man jede Detektionsregel auf die Techniken ab, die sie abdeckt, baut eine Abdeckungskarte (oft mit dem ATT&CK Navigator) und priorisiert dann das Schließen von Lücken danach, welche Techniken für das eigene Bedrohungsmodell am relevantesten sind und auf welche man keinerlei Sichtbarkeit hat.

Prüfen Sie die E-Mail sicher ohne zu klicken: Header und Absender-Authentifizierung (SPF/DKIM/DMARC) checken, URLs und Anhänge in einer Sandbox oder mit Reputations-Tools inspizieren, dann den Umfang bestimmen — wer sie sonst erhielt, ob jemand klickte oder Zugangsdaten eingab. Je nach Befund remediieren: E-Mail purgen, Indikatoren blockieren und kompromittierte Zugangsdaten zurücksetzen.

Ein SIEM nimmt Logs aus dem gesamten Bestand auf und korreliert sie, um Alerts zu erzeugen — es ist Ihre Detektions- und Suchschicht. Ein SOAR sitzt nachgelagert und automatisiert die Reaktion: Es führt Playbooks aus, reichert Alerts über Integrationen an und übernimmt das Case-Management, damit Analysten weniger Zeit für repetitive Schritte aufwenden.

Bestätigen Sie vor dem Handeln, dass der Alert echt ist: Lesen Sie, was ausgelöst wurde und warum, dann reichern Sie an — wer ist der Benutzer, sind Quell-IP/Geo/Gerät erwartbar, ist es Impossible Travel, gab es zuvor Fehlschläge? Klassifizieren Sie als echten oder falschen Treffer, eskalieren oder dämmen Sie ein, wenn echt (Sitzung deaktivieren, MFA-Reset erzwingen), und dokumentieren Sie alles, damit der nächste Analyst Ihrer Argumentation folgen kann.

4624 ist ein erfolgreicher Logon, 4625 ein fehlgeschlagener Logon und 4688 eine Prozesserstellung. In einer Untersuchung nutzen Sie 4625, um Credential-Angriffe aufzuspüren, 4624 (mit seinem Logon-Typ und der Quelle), um einen erfolgreichen Zugriff und dessen Zustandekommen zu bestätigen, und 4688, um zu sehen, was tatsächlich ausgeführt wurde, idealerweise mit aktiviertem Kommandozeilen-Auditing.