Bedrohungen, Angriffsvektoren & Schadsoftware

Primär verletzt ist die Integrität. Die Daten wurden unbefugt verändert und sind damit nicht mehr korrekt und vollständig.

Abgrenzung: Die Vertraulichkeit ist nicht verletzt, weil der Lesezugriff autorisiert war. Die Verfügbarkeit ist nicht verletzt, weil die Datei weiterhin nutzbar ist. Dass die Änderung unbemerkt blieb, betrifft zusätzlich die Nachvollziehbarkeit — das ist aber kein CIA-Ziel.

Fachlich wichtig: Die gefährlichere Folge liegt darin, dass mit falschen Kundendaten weitergearbeitet wird, ohne dass jemand den Fehler kennt.

Gewählter Dienst: SSH auf 22/tcp von APP01.

Angriffsfläche: Dass der SSH-Dienst überhaupt aus dem Netz erreichbar ist, ist ein Kontaktpunkt für Angreifer und damit Teil der Angriffsfläche. Sie besteht auch dann, wenn der Dienst fehlerfrei und aktuell ist.

Schwachstelle: Eine konkrete Schwäche an diesem Punkt — etwa eine veraltete Version mit bekannter Sicherheitslücke, erlaubter Root-Login mit Passwort oder ein schwaches Kennwort.

Kernsatz: Die Angriffsfläche beschreibt wo ein Angreifer ansetzen kann, die Schwachstelle warum es dort gelingen könnte. Angriffsfläche verkleinern heißt Dienste abschalten oder einschränken; Schwachstellen beseitigen heißt patchen und konfigurieren.

Nein. Mit gültigen Zugangsdaten läuft eine technisch völlig normale, erfolgreiche Authentifizierung ab. Es wird keine technische Schwachstelle ausgenutzt, also ist kein Exploit erforderlich.

Begründung über die Kette: Angriffsvektor ist der legitime RDP-Zugang, die ausgenutzte Schwäche liegt vor dem System — beim Diebstahl der Zugangsdaten, etwa durch Phishing oder Keylogger. Der Angriff ist die Anmeldung selbst.

Merksatz: Exploit ≠ Angriff. Missbrauch legitimer Zugänge ist besonders schwer zu erkennen, weil er sich im Log nicht von normaler Arbeit unterscheidet; Hinweise liefern nur Kontextmerkmale wie Uhrzeit, Quell-IP und Gerät.

Es handelt sich um einen Trojaner mit Dropper-Funktion. Erkennbar sind:

• Tarnung: Die Datei gibt sich als Rechnung aus — Täuschung des Benutzers.
• Eintritt und Ausführung: Über Social Engineering, der Benutzer startet sie selbst.
• Keine Selbstverbreitung: Kein Wurm, kein Virus, weil weder eine Wirtsdatei infiziert noch das Netz selbsttätig genutzt wird.
• Nachladen/Installieren: Dropper- bzw. Loader-Eigenschaft, die eine zweite Stufe einrichtet.
• Persistenz und Fernzugriff: Die Backdoor hält den Zugang dauerhaft offen, typischerweise mit Anbindung an ein C2 (bei interaktiver Steuerung: RAT).

Schutzziele: Vertraulichkeit und Integrität des Systems; je nach weiterer Nutzung auch Verfügbarkeit.

Password Spraying. Kennzeichnend ist das Verhältnis: wenige Versuche pro Konto, dafür sehr viele Konten. Der Angreifer probiert häufige Passwörter breit durch und bleibt pro Konto unter der Sperrschwelle, sodass keine Kontosperre und kein Alarm ausgelöst wird.

Abgrenzung: Brute Force wäre das umgekehrte Muster — viele Passwörter gegen ein Konto. Credential Stuffing würde bereits bekannte Kombinationen aus Benutzername und Passwort aus einem Leak verwenden und hätte typischerweise eine höhere Trefferquote bei wenigen Versuchen.

Grenze der Aussage: Das Muster ist ein starker Hinweis, aber die Technik ist aus dem Log allein nicht bewiesen — dazu müsste man die verwendeten Passwörter kennen.

Naheliegend ist ARP Spoofing (ARP Cache Poisoning). ARP arbeitet ohne Authentifizierung: Ein Host übernimmt eingehende ARP-Replies ungeprüft in seinen Cache, auch unaufgefordert gesendete. Der Angreifer behauptet, die Gateway-IP gehöre zu seiner MAC-Adresse.

Folge: PC-A sendet alle Pakete, die ins andere Netz oder ins Internet gehen sollen, an den Angreifer. Dieser wird damit zum Man-in-the-Middle / On-Path-Angreifer und kann den Verkehr mitlesen (Vertraulichkeit), verändern (Integrität) oder verwerfen (Verfügbarkeit).

Einordnung: TLS schützt weiterhin die Inhalte, aber Metadaten bleiben sichtbar, und unverschlüsselte Protokolle sowie Downgrade-Versuche sind angreifbar. Alternative Erklärungen wie ein Gerätetausch oder eine neue Firewall mit gleicher IP müssen zuerst ausgeschlossen werden.

DoS: Ein Dienst wird von einer Quelle überlastet oder gezielt zum Fehlverhalten gebracht, sodass berechtigte Nutzer ihn nicht mehr erreichen.

DDoS: Derselbe Effekt, aber verteilt von vielen Systemen gleichzeitig, meist einem Botnet.

Warum das praktisch wichtig ist: Die erreichbare Last ist deutlich höher, die Herkunft verteilt sich über viele legitime Adressen, und das Sperren einzelner IP-Adressen hilft nicht mehr. Verteidigung braucht Upstream-Filterung, Rate Limiting oder einen Scrubbing-Dienst. Betroffenes Schutzziel ist in beiden Fällen die Verfügbarkeit.

SYN Flood, eine Form des DoS/DDoS.

Ausgenutzter Mechanismus — der TCP-Three-Way-Handshake: Der Angreifer sendet ein SYN. Der Server antwortet mit SYN-ACK und reserviert dabei Ressourcen für eine halboffene Verbindung in seinem Backlog, weil er auf das abschließende ACK wartet. Dieses ACK kommt nie — oft mit gefälschter Absender-IP, damit die Antwort ins Leere läuft.

Wirkung: Die Warteschlange der halboffenen Verbindungen füllt sich und neue, echte Verbindungsanfragen werden abgewiesen. Der Angriff braucht beim Angreifer wenig Bandbreite, weil der Aufwand asymmetrisch beim Server liegt.

Schutzziel: Verfügbarkeit. Gegenmaßnahmen sind unter anderem SYN Cookies, kürzere Timeouts und größere Backlogs.

Zulässig: Auf TCP-Port 443 des Hosts nimmt zum Zeitpunkt des Scans ein Dienst Verbindungen an und ist von der Position des Scanners aus erreichbar.

Nicht zulässig (eine genügt, mehrere sichern Punkte ab):

• Dass der Dienst eine Schwachstelle hat oder angreifbar ist — ein offener Port ist keine Schwachstelle.
• Dass dort tatsächlich HTTPS läuft: ohne Version Detection ist „https“ nur die Standardzuordnung zur Portnummer.
• Dass die Software aktuell oder sicher konfiguriert ist.
• Dass der Zugriff für den Scanner erlaubt oder beabsichtigt ist.

filtered heißt: Nmap erhält keine verwertbare Antwort. Die Pakete werden offenbar auf dem Weg verworfen oder mit einer ICMP-Fehlermeldung abgewiesen — typischerweise durch eine Firewall, einen Paketfilter oder eine Router-ACL.

Entscheidend: Der Scanner kann nicht unterscheiden, ob dahinter ein RDP-Dienst lauscht oder nicht. Der Zustand beschreibt den Weg, nicht den Dienst.

Abgrenzung zu closed: Bei closed antwortet der Host aktiv mit RST — der Port ist also erreichbar, aber ohne Dienst. Bei filtered fehlt die Antwort ganz.

Sicherheitsbewertung: Für einen Fernzugriffsdienst wie RDP ist filtered aus einem nicht berechtigten Netz der gewünschte Zustand.

Vertraulichkeit. m.keller hat um 07:37 Zugangsdaten auf der Fremddomain microsoft-login-security.example eingegeben und die MFA-Anfrage bestätigt; um 07:41 ist von 203.0.113.77 eine erfolgreiche Anmeldung protokolliert. Ein Unbefugter konnte damit auf Postfach und Daten des Kontos zugreifen. Zusätzlich könnte der ARP-Befund von 08:02 Dritten erlauben, Datenverkehr von CLIENT17 mitzulesen.

Integrität. Mit einem übernommenen Konto können Daten, Mails und Weiterleitungsregeln unbemerkt verändert werden. Beim ARP-Befund kommt hinzu, dass ein On-Path-Angreifer Datenverkehr nicht nur lesen, sondern auch manipulieren könnte.

Zur Verfügbarkeit: Dafür gibt es im Material keinen Befund. Erwähne sie nur als Möglichkeit bei fortgesetztem Zugriff — eine unbelegte Behauptung kostet Punkte.

Technik gegen m.keller: Credential Phishing mit anschließender Umgehung der Mehrfaktor-Authentifizierung.

Angriffsweg Schritt für Schritt:

• 07:31 Köder: Mail mit erzeugter Dringlichkeit („Sitzung abgelaufen“, „jetzt bestätigen“) im Namen eines vertrauten Dienstes.
• 07:34 Täuschung: Das Linkziel liegt auf microsoft-login-security.example — eine Fremddomain, die den Markennamen nur im Hostnamen trägt. Entscheidend ist die registrierte Domain, nicht der vorangestellte Text.
• 07:37 Eingabe: Zugangsdaten landen beim Angreifer.
• MFA-Umgehung: Die kurz darauf bestätigte MFA-Anfrage wurde durch den Anmeldeversuch des Angreifers ausgelöst. m.keller ordnet sie der eigenen Aktion zu und bestätigt — MFA Fatigue bzw. Push-Bestätigung durch Täuschung. Alternativ kann ein Echtzeit-Phishing-Proxy die Eingaben weitergereicht und das Sitzungstoken abgegriffen haben.
• 07:41 Erfolg: Anmeldung mit korrektem Passwort und erfolgreicher MFA von 203.0.113.77. MFA wurde nicht technisch gebrochen, sondern über den Menschen umgangen.

Fehlversuche 07:43–07:45: Drei verschiedene Konten (a.schulz, t.wagner, s.yilmaz) von derselben Quell-IP, je ein falsches Passwort. Das Muster „wenige Versuche, viele Konten“ passt zu Password Spraying; die geringe Zahl pro Konto vermeidet Kontosperren.

Abgrenzung: Kein Brute Force (das wäre ein Konto mit vielen Passwörtern) und kein belegtes Credential Stuffing (dafür bräuchte man bekannte Benutzer-Passwort-Paare, was hier nicht erkennbar ist). Fachlich ist das ein Versuch, den Zugriff nach dem Erstzugang auf weitere Konten auszuweiten.

Technische Grundlage: ARP löst im lokalen Netz eine IPv4-Adresse in die zugehörige MAC-Adresse auf. Der Host fragt per Broadcast, wer 10.2.208.1 ist, und speichert die Antwort in seinem ARP-Cache. ARP kennt keine Authentifizierung: Jede Antwort wird übernommen, auch unaufgefordert gesendete.

Befund: Auf CLIENT17 steht um 08:02 für die Gateway-IP eine andere MAC-Adresse als dokumentiert. Die Zuordnung IP → MAC wurde also verändert.

Naheliegender Angriff: ARP Spoofing / ARP Cache Poisoning. Der Angreifer sendet gefälschte ARP-Replies mit der Behauptung, die Gateway-IP gehöre zu seiner MAC.

Mögliche Folge: CLIENT17 sendet den gesamten Verkehr, der eigentlich über das Gateway laufen soll, an das Gerät des Angreifers. Dieser wird Man-in-the-Middle (On-Path) und kann

• mitlesen — Verletzung der Vertraulichkeit,
• verändern oder einspeisen — Verletzung der Integrität,
• verwerfen und damit die Verbindung unterbrechen — Verletzung der Verfügbarkeit.

Saubere Einordnung: TLS schützt die Inhalte weiterhin, aber Metadaten bleiben sichtbar und unverschlüsselte Protokolle sind offen. Und: Eine falsche MAC kann auch durch einen Hardwaretausch oder eine Umkonfiguration des Gateways entstehen — der Angriff ist naheliegend, aber noch nicht bewiesen. Zur Prüfung gehört der Blick auf die MAC-Herkunft am Switchport.

Interpretation der vier Zustände:

• 22/tcp open ssh — zum Scanzeitpunkt nimmt auf Port 22 ein Dienst Verbindungen an; die Portnummer legt SSH nahe. Fernzugriff ist also erreichbar.
• 80/tcp closed http — der Port ist erreichbar und nicht gefiltert, aber kein Dienst lauscht; der Host hat aktiv mit RST geantwortet.
• 443/tcp open https — ein Dienst nimmt Verbindungen an, vermutlich HTTPS.
• 3389/tcp filtered ms-wbt-server — keine verwertbare Antwort, ein Paketfilter verwirft die Pakete. Ob dahinter RDP läuft, ist von hier aus nicht feststellbar.

Nicht ableitbar:

• Dass die offenen Ports Schwachstellen sind oder APP01 angreifbar ist (Merksatz 2).
• Welche Software in welcher Version lauscht — ohne Service-/Version-Detection ist die Spalte SERVICE nur die Standardzuordnung zur Portnummer.
• Dass auf 3389/tcp kein RDP-Dienst läuft; filtered beschreibt den Weg, nicht den Dienst.
• Dass bereits ein Angriff auf APP01 stattgefunden hat oder der Server kompromittiert ist.
• Dass das Ergebnis allgemein gilt: Es ist eine Momentaufnahme von einer Position im Netz; aus einem anderen Segment kann es anders aussehen.

Zusatz, der oft Punkte bringt: Der Scan war eine autorisierte Bestandsaufnahme. Ohne Autorisierung wäre dieselbe Handlung unzulässig — das ist der Dual-Use-Charakter von Reconnaissance.

Tatsache 1: Um 07:41 ist für das Konto m.keller von der IP 203.0.113.77 eine Anmeldung mit korrektem Passwort und erfolgreicher MFA protokolliert.

Tatsache 2: Von derselben IP schlugen zwischen 07:43 und 07:45 Anmeldungen für die drei Konten a.schulz, t.wagner und s.yilmaz mit falschem Passwort fehl.

Interpretation: Drei Fehlversuche gegen verschiedene Konten von derselben Quelle innerhalb von drei Minuten passen zum Muster eines Password Sprayings durch denselben Akteur, der nach dem Erstzugriff weitere Konten erreichen will.

Hypothese: Ein externer Angreifer hat die Zugangsdaten von m.keller per Phishing erlangt, das Konto um 07:41 übernommen und anschließend versucht, seinen Zugriff auszuweiten; der ARP-Befund auf CLIENT17 um 08:02 gehört zum selben Vorgang.

Warum das noch kein Beweis ist:

• Die zeitliche Nähe der Ereignisse ist eine Korrelation, kein Kausalnachweis.
• Kein Befund verknüpft 203.0.113.77 mit dem Phishing-Server oder mit CLIENT17. Die IP ist ein Indikator und kann ein Proxy, ein VPN-Ausgang oder ein gekaperter Host sein (Merksatz 4).
• Die MAC-Adresse im ARP-Eintrag ist keinem Gerät zugeordnet; eine harmlose Ursache wie ein Gerätetausch oder eine Umkonfiguration ist nicht ausgeschlossen.
• Die Angaben von m.keller sind eine Aussage, kein technischer Befund. „Danach habe ich nichts weiter gemacht“ ist unbelegt und kann auf Irrtum beruhen.
• Ob der Angreifer nach 07:41 tatsächlich auf Daten zugegriffen hat, ist nicht protokolliert; auch die Fehlversuche könnten eine andere Ursache haben, etwa einen unabhängigen Scan.

Was zur Prüfung nötig wäre: Mail-Header und Proxy-/DNS-Logs zum Aufruf der Fremddomain, Sitzungs- und Token-Protokolle des Kontos, die weiteren Aktivitäten nach 07:41, die MAC-Herkunft am Switchport von CLIENT17 sowie eine forensische Untersuchung des Clients.