Jki-facebook-light Jki-instagram-1-light Jki-linkedin-light
Gratis Beratung

+49 (0) 9491 / 742 988 50

Email Schemata

Oder: Warum ein Hacker Ihre Emailadresse kennt

Haben Sie je Phishingmail erhalten und sich gefragt woher der Absender Ihre Mailadresse kennt? Dafür gibt es verschiedene Möglichkeiten:

  • Möglicherweise wurde ein Kollege oder Geschäftspartner gehackt und der Angreifer hatte somit Zugriff auf das Emailadressbuch in dem Ihre Mailadresse aufgeführt ist
  • Möglicherweise hat der Angreifer die Adresse zusammen mit Millionen anderen im Dark Net gekauft
  • Möglicherweise stammt die Adresse aus einem frei verfügbaren Dump (wenn Sie sich beispielsweise bei XY registriert haben, XY später gehackt wurde und die Daten dann im Netz landen)
  • Möglicherweise hat der Angreifer Ihre Adresse auch mit einem Email Harvester einfach ausgelesen (je nach Firmenpolitik sind Emailadressen von Vertriebs- oder Personalmitarbeitern teilweise auf der Webseite angegeben und können dann ausgelesen werden)

 

Oder: Vielleicht hat der Angreifer die Adresse auch einfach mit Ihrem Namen und dem Emailschema Ihrer Firma selbst erzeugt. Wie simpel diese Möglichkeit ist, werden wir uns in diesem Blog Beitrag unserer „Emails als Waffe“ Serie näher ansehen.

Emailschema: geschäftlich

Emailadressen von Firmen folgen in der Regel einem ganz bestimmten Muster. Beispielsweise vorname.nachname@firmenname.tld damit ist gewährleistet, dass nach außen ein einheitlicher und seriöser Eindruck entsteht.

Gleichzeit wird es einem Angreifer dadurch aber auch sehr leicht gemacht, alle Emailadressen herauszufinden, die in der Firma verwendet werden. Alles was er dazu benötigt, ist das Email Schema und eine Liste mit Mitarbeiternamen.

Für das Emailschema kann die Webseite hunter.io genutzt werden. Hunter bietet direkt auf der Startseite die Möglichkeit eine Domain einzugeben:

Anschließend werden nicht nur Emailadressen mit dieser Domain angezeigt (in der Basis Version zensiert) sondern auch das Emailschema der Domain:

Im Falle von beispiel.de wird also das Schema [Vorname].[Nachname]@domain.tld verwendet. Wenn wir nun also wissen, dass Max Mustermann für unsere Beispiel Firma arbeitet, dann kennen wir auch seine geschäftliche Emailadresse: max.mustermann@beispiel.de

Sollte Hunter uns einmal nicht weiterhelfen können, so können wir uns immer noch selbst auf die Suche nach einer Emailadresse machen. Potenzielle Quellen dafür sind:

  • Stellenanzeigen (Angabe von Kontaktemails von Personalern/Recruitern)
  • Impressum (Angabe von Emails der Geschäftsleitung oder von Datenschutzbeauftragten)
  • Über Uns Seiten, auf denen Mitglieder der Geschäftsleitung vorgestellt werden
  • Produktseiten, auf denen Emailadressen von Ansprechpartnern, Vertriebsmitarbeitern o.ä. aufgeführt sind

 

Hat man eine Emailadresse gefunden, kann man mit hoher Wahrscheinlichkeit davon ausgehen, dass dasselbe Schema auch bei allen anderen Emailadressen verwendet wurde.

Falls man wirklich sichergehen möchte, kann man auch einfach verschiedene Emailschemata verwenden. Üblich sind:

  • [Vorname].[Nachname]@[domain].tld
  • [Initiale Vorname].[Nachname]@[domain].tld
  • [Initiale Vorname][Nachname]@[domain].tld
  • [Vorname]@[domain].tld
  • [Nachname]@[domain].tld
  • [Nachname].[Initiale Vorname]@[domain].tld
  • [Vorname][Nachname]@[domain].tld

 

Wer also wirklich sichergehen möchte, dass er alle Emailadressen einer Firma erwischt, erzeugt einfach nach diversen Schemata Emailadressen und verifiziert dann später, welche davon vergeben sind. Dazu werden wir im Verlauf des Beitrags noch verschiedene Möglichkeiten kennenlernen.

Nachdem das Emailschema bekannt ist, wird nun noch eine Liste der Mitarbeiter benötigt, um anschließend Emailadressen erstellen zu können. Dies klingt im ersten Moment vielleicht nach einer sensiblen Information (schließlich würde vermutlich kaum ein Unternehmen auf seiner Webseite eine Excel Liste mit allen Mitarbeitern zum Download bereitstellen). Karriereportale wie Xing oder LinkedIn machen es aber sehr einfach an die entsprechenden Informationen zu gelangen:

Im Screenshot sind die Mitarbeiter von Microsoft zu sehen. Namen und Bilder wurden von uns zensiert, sind aber grundsätzlich öffentlich zugänglich.

Fairerweise muss man natürlich sagen, dass nicht jeder Mitarbeiter ein Xing oder LinkedIn Profil haben wird. Aber in der Regel bekommt man auf diese Weise schon eine ordentliche Liste an Namen zusammen und kann somit einige Emailadressen erzeugen.

Alternativ bietet sich auch noch Social Media an: Teilweise stellen Firmen ihre Mitarbeiter explizit mit Namen und Bild vor, ansonsten sind die Likes bzw. Follower ebenfalls potenzielle Mitarbeiter Kandidaten.

Emailschema: privat

Möchte man die private Emailadresse einer Zielperson in Erfahrung bringen, dann ist die Sache leider nicht ganz so einfach. Private Mailadressen kann jeder nach eigenem Gutdünken anlegen, ein festes Schema existiert nicht (abgesehen davon, dass bestimmte Zeichen nicht Teil der Emailadresse sein können).

Da die Anzahl der Freemail Anbieter zudem beschränkt ist und Emailadressen nicht mehrfach vergeben werden können, müssen, wenn die präferierte Adresse bereits vergeben ist, zusätzliche Identifikationsmerkmale hinzugefügt werden.

Hierfür wird von den meisten Menschen vor allem der Geburtstag verwendet. Beispielsweise:

  • Die Jahreszahl wird an den Namen angehängt
    • mustermann89
    • mustermann1989
  • Tag und Monat des Geburtstages werden an den Namen angehängt
    • max_mustermann1203
    • max_mustermann0911

 

Grundsätzlich sind der Fantasie hier wenig Grenzen gesetzt, bei einem seltenen Namen reicht möglicherweise schon das Anhängen der Jahreszahl aus, bei einem häufigen Namen müssen unter Umständen sowohl vorne als auch hinten zusätzliche Identifikationsmerkmale an die Adresse angehängt werden.

Der Geburtstag der Zielperson kann in vielen Fällen in sozialen Netzwerken gefunden werden. Wenn ein Profil auf einer Karriereseite vorhanden ist, kann, über die angegebenen Stationen, zudem zumindest das Geburtsjahr mit einer gewissen Wahrscheinlichkeit eingegrenzt werden.

Auf diese Weise kann man also mögliche Emailadressen erzeugen, die der Zielperson gehören könnten. Eine eindeutige Zuordnung ist damit zwar noch nicht möglich, wir werden im nächsten Abschnitt aber sehen, wie man verifizieren kann, ob eine Mailadresse überhaupt funktioniert. Damit kann man die Liste der möglichen Emailadressen in der Regel schon deutlich verkleinern, da nicht alle vergeben sein werden.

Auch damit ist zwar noch keine exakte Zuordnung von Emailadresse X zu Zielperson Y möglich, für die meisten Angriffe ist es aber nicht weiter schlimm, wenn beispielsweise eine Phishing Nachricht nicht nur die eigentliche Zielperson erreicht, sondern noch ein weiteres unbeteiligtes Opfer.

Emails verifizieren

An dieser Stelle haben wir nun eine Liste mit möglichen Emailadressen. Wenn wir das Emailschema und den Namen eines aktuellen (!) Mitarbeiters kennen, können wir uns sehr sicher sein, dass die entsprechende Emailadresse auch vergeben ist.

Anders sieht es bei privaten Emailadressen aus. Wir haben nach der obigen Methode zwar ein paar mögliche Emailadressen für unsere Zielperson Max Mustermann erstellt, wissen aber nicht, welche davon tatsächlich verwendet wird. Um herauszufinden, ob eine Emailadresse vergeben ist, gibt es verschiedene Möglichkeiten mit spezifischen Vor- und Nachteilen.

Emails verifizieren (Webservices)

Es existieren diverse Webservices, die uns anbieten, Emailadressen zu verifizieren. Hauptsächlich gedacht ist das für Emailmarketing, damit keine Mails an nicht existente Adressen versandt werden. Aber natürlich kann auch ein Hacker den entsprechenden Service nutzen.

Den Angeboten ist gemein, dass sie sich in gewissem Umfang kostenlos nutzen lassen, für größere Abfragemengen dann aber kostenpflichtige Accounts nötig werden.

Zu Testzwecken verwenden wir den Service von Emailhippo.

Wie bei anderen Services auch, wird hier die zu analysierende Mail eingegeben:

Für die oben eingegebene Adresse erhalten wir dann das folgende Ergebnis:

Gibt man dagegen eine existierende Emailadresse zur Überprüfung ein, wird folgendes ausgegeben:

Andere Webservices zur Email Verifizierung:

 

Diese Liste stellt keinen Anspruch an Vollständigkeit, wer ein wenig googelt wird noch diverse andere Seiten finden, die ebenfalls anbieten, Emailadressen zu verifizieren. Wichtig ist allerdings, dass der Service tatsächlich die Existenz der eingegebenen Emailadresse untersucht und nicht nur die syntaktische Korrektheit.

Nachteil dieser Methode ist, dass wir nur vergleichsweise wenig Gratisversuche pro Service zur Verfügung haben. Wer Emaillisten mit Millionen von Adressen testen möchte, muss also entweder Geld ausgeben, oder sich überlegen, wie die Beschränkungen der Anbieter umgangen werden können.

Vorteil dieser Methode ist, dass wir nicht direkt mit unseren Opfern in Kontakt kommen, sondern den Verifizierungsanbieter als Mittelsmann zwischen uns haben. Vereinfach gesagt, fragt der Anbieter beim Zielserver an, ob dieser die Mailadresse kennt. Es wird also nicht wirklich eine Mail verschickt. Das hat einerseits den Vorteil, dass der Eigentümer der Mailadresse von der Verifizierung nichts mitbekommt. Andererseits liegt ein Nachteil der Methode darin, dass das Ergebnis nicht immer zu 100% verlässlich ist, da der Mailserver auch so konfiguriert werden kann, dass er erst einmal jede Mail annimmt (die Email wird dann als existent gemeldet) und sie erst im Nachhinein verwirft.

Alles in allem eher eine Lösung wenn man mal schnell ein, zwei Adressen von Hand verifizieren möchte.

Emails verifizieren (Python)

Wer sich die Preisgestaltungen der obigen Services anschaut, wird feststellen, dass eine Verifizierung größerer Emaillisten (mehrere Millionen Einträge) sehr schnell recht teuer wird bzw. individuelle Angebote oder Corporate Accounts erfordert und somit kaum unbemerkt möglich sein dürfte.

Als Angreifer benötigen wir also noch eine alternative Methode, um zu verifizieren, ob eine Emailadresse existiert. Wie es der Zufall will, ist es nicht weiter schwer, die Funktionalität der Webservices in einem eigenen Programm selbst zu implementieren:

Die Logik zur Email Verifizierung ist zu diesem Zweck in einer Funktion verpackt. Diese Funktion wird für jede Emailadresse unserer Liste aufgerufen und die entsprechenden Ausgaben werden auf der Kommandozeile ausgegeben.

Die verify() Funktion macht dann für jede übergebene Mailadresse folgendes:

  • Es wird geprüft ob der Domain Name aufgelöst werden kann
    • Falls nicht existiert die Domain nicht
  • Falls die Domain aufgelöst werden kann, wird der Name des Mailservers angefragt
  • Anschließend wird eine Verbindung mit dem Mailserver aufgebaut und der Status der übergebenen Mail abgefragt
    • Ein Status von 250 (Requested mail action okay, completed) bedeutet, dass die angefragte Mailadresse auf dem Server existiert
    • In allen anderen Fällen kann davon ausgegangen werden, dass die Mailadresse entweder nicht vergeben ist oder der Server so konfiguriert ist, dass er die Abfrage nicht eindeutig beantwortet. In diesen Fällen wird der Statuscode und die Nachricht des Servers auf der Kommandozeile ausgegeben (hier könnte dann gegebenenfalls noch eine weitere Fehlerbehandlung basierend auf dem erhaltenen Statuscode stattfinden, das ist für unser Testprogramm aber nicht notwendig).

 

Unser Test File enthält drei Emailadressen:

Bei den Adressen handelt es sich um:

  • Eine nicht existierende Adresse einer nicht existierenden Domain (sollte zu einem Fehler führen)
  • Eine nicht existierende Adresse einer existierenden Domain (sollte zu einem Fehler führen, allerdings mit anderer Fehlermeldung)
  • Eine existierende Adresse einer existierenden Domain (diese Email sollte als korrekt identifiziert werden)

 

Das Programm erzeugt folgende Ausgabe:

Unser kleines Programm erzeugt damit grundsätzlich dieselbe Ausgabe wie die kostenpflichtigen Webservices:

  • Die nicht existierende Domain wird als solche erkannt (DNS Fehler)
  • Für die nicht existierende Mailadresse einer existierenden Domain wird ausgegeben, dass der User nicht vorhanden ist (vgl. Fehlermeldung der Webservices)
    • Der Statuscode 550 bedeutet: Requested action not taken: mailbox unavailable
    • Die Nachricht des Servers in der nächsten Zeile spezifiziert diese Meldung dann noch weiter und stellt klar, dass der User nicht vorhanden ist
  • Die korrekte Emailadresse wird als solche erkannt und ist damit verifiziert

 

Ohne kostenpflichtigen Account können wir unsere Emaillisten nun also auch selbst überprüfen. Vorteil dieser Methode ist, dass unser Opfer von der Verifizierung seiner Mailadresse nichts mitbekommt. Wir stellen ja nicht wirklich eine Mail zu, sondern fragen beim Server nur an, ob die Emailadresse bekannt ist. Anschließend brechen wir die Verbindung ab.

Emails verifizieren (Email)

Die beiden vorherigen Methoden kann man sich wie einen Paketboten vorstellen, der an einer Tür klingelt und fragt, ob hier ein Max Mustermann wohnt (allerdings ohne tatsächlich ein Paket zuzustellen, wenn Max Mustermann dort wirklich wohnen sollte). Wie gut das funktioniert, hängt stark davon ab, wer die Tür aufmacht (= wie der Server konfiguriert ist). Folgende Möglichkeiten bestehen dabei:

  • Die auskunftsfreudige Mutter von Max öffnet die Tür und bestätigt, dass ihr Sohn hier wohnt (= Der Server bestätigt, dass die Adresse vergeben bzw. nicht vergeben ist)
  • Der paranoide Bruder von Max öffnet die Tür und gibt an, dass er noch nie etwas von irgendeinem Max gehört hat (= Der Server lehnt alle Verifizierungsanfragen pauschal ab und reagiert nur auf tatsächlich zugestellte Mails)
  • Die Nachbarin öffnet die Tür, sie weiß nicht ob es im Haus einen Max Mustermann gibt, bietet sich aber an, etwaige Pakete für ihn entgegen zu nehmen (= Der Server beantwortet alle Verifizierungsanfragen positiv und prüft erst danach ob die Mailadresse tatsächlich vorhanden ist)

 

Während die erste Konfiguration für uns als Angreifer positiv ist, können wir mit den beiden anderen nicht wirklich etwas anfangen. Eine weitere Möglichkeit zur Emailverifizierung ist also nötig, wobei wir dieses Mal unsere Deckung ein wenig verlassen und tatsächlich eine Email verschicken werden.

Dabei machen wir es uns zunutze, dass nicht zustellbare Emails zu Fehlern in unserem Mailprogramm führen. Um das zu demonstrieren, wird zunächst eine Mail an eine nicht existierende Adresse einer nicht vergebenen Domain verschickt:

Wie im Screenshot zu sehen, werden wir durch eine Fehlermeldung darüber informiert, dass die Domain nicht existiert. Im nächsten Schritt versuchen wir nun eine Mail an eine existierende Domain zu versenden (beispiel.de) allerdings an eine nicht existierende Adresse:

Wie zu sehen, werden wir nun darüber informiert, dass der User nicht bekannt ist, wir können die entsprechende Adresse also von unserer Liste entfernen.

Diese Meldungen erscheinen recht schnell nach dem Versand der Email. Im Gegensatz dazu erscheint keine Fehlermeldung, wenn sowohl Adresse als auch Domain existieren. Ein Angreifer kann deshalb einfach eine Testmail an alle potenziellen Emailadressen verschicken und anschließend diejenigen Emails streichen, bei denen es zu einer Fehlermeldung kam.

Diese Methode hat den Vorteil, dass sie nur schwer zu unterbinden ist. Selbst ein Einsortieren der Mail als Spam ist für den Angreifer unproblematisch, da es nicht zu einer Fehlermeldung kommt und somit die Existenz der Adresse bewiesen ist. Schützen könnte man sich in diesem Fall nur dadurch, dass Mails von unbekannten Absendern (z.B. alle die nicht auf einer Whitelist stehen) vom Server grundsätzlich geblockt werden. Damit dürften sich, je nach Anwender, aber auch erhebliche Probleme ergeben, da dann auch Mails verworfen werden, die benötigt werden (oder die Whitelist müsste sehr umfangreich sein, was ihren Zweck aber ebenfalls konterkariert).

Nachteil dieser Methode ist allerdings, dass der Angreifer a) eine größere Anzahl an Emails versenden muss und b) die Zielperson potenziell auf sich aufmerksam macht. Beides lässt sich allerdings leicht in den Griff bekommen, da die Emails an sich nicht relevant sind, können sie von einem beliebigen Freemail Accounts verschickt und als normale Spam, Newsletter etc. Mails getarnt werden. Die Zielperson dürfte somit kaum auf den Gedanken kommen, dass eine erhaltene Mail der Verifizierung ihrer Emailadresse dient.

Eails verifizieren (Trackingpixel)

Die obigen Methoden sind geeignet, um die Existenz einer Emailadresse zu verifizieren bzw. zu falsifizieren. Ob die Zielperson die Email aber auch tatsächlich öffnet, lässt sich damit noch nicht sagen. Um das herauszufinden, können wir ein Trackingpixel verwenden.

Dabei handelt es sich um ein winziges Bild (oder eine andere Art von Inhalt), das nicht in der Mail selbst enthalten ist, sondern von einem anderen Anbieter geladen wird. Öffnet der User die Mail, baut das Mailprogramm die Verbindung zu diesem Anbieter auf, um die Grafik korrekt darzustellen. Damit ist bewiesen, dass der User die Mail geöffnet hat.

Da diese Funktion natürlich für diverse Firmen interessant ist, um die Wirksamkeit ihrer Emailmarketingmaßnahmen oder Newsletter zu evaluieren, wird auch entsprechend viel Geld investiert, um entsprechende Tracking Pixel und die dahinterstehende Infrastruktur möglichst effizient und ausgereift zu machen. Grundsätzlich lässt sich der Ablauf aber auch mit einem selbstgemachten Paint Bild gut nachvollziehen:

Der obige Screenshot zeigt ein 1×1 Pixel großes weißes Bild. Aufgrund der Größe und der Farbe fällt die Darstellung in einer Email nicht auf, sodass der User gar nicht mitbekommt, dass sein Klick gerade getrackt wurde. Dieses Bild fungiert nun als unser Tracking Pixel. Wir verschieben es in eine virtuelle Maschine (Kali Linux) und stellen es über einen Webserver zum Download bereit.

In unserer Email die wir versenden wollen, klicken wir dann auf Grafik einfügen und geben die Adresse unseres Webservers an:

Wie zu sehen, stellt unser Webserver das Bild unter dem Namen „tracking_pixel.png“ auf Port 8000 zum Download bereit.

Eingefügt sieht das Ganze dann wie folgt aus:

Wie man sieht, sieht man nichts. Das 1×1 Pixel große Bild ist nicht zu erkennen. Diese Email wird nun an unsere Test Adresse verschickt. Sobald sie dann geöffnet wird, sollten wir den Zugriff in unseren Webserver Logs sehen können.

Das klappt mit Protonmail zunächst nicht, das Laden des Bildes wird blockiert:

Das externe Bild wird also nicht automatisch geladen. Einerseits ist dies aber nicht bei jedem Emailprovider so und andererseits gibt es auch genügend User, die auf „Load anyway“ klicken werden, um die Grafik korrekt darzustellen. Sobald wird das machen, sehen wir in unserem Webserver Log den Zugriff und wissen damit als Angreifer, dass die Mail geöffnet wurde:

Zwei Zugriffe sind zu sehen: Einmal als das Bild beim Absender eingebunden wurde und einmal das Öffnen der Email beim Empfänger. Wir sehen darüber hinaus auch ganz links noch die IP-Adressen von denen die Zugriffe erfolgt sind (in diesem Fall natürlich zensiert). Wenn wir also eine Spear Phishing Mail an den CEO verschicken und diese zuerst von IP-Adresse A und einige Zeit später von IP-Adresse B geöffnet wird, dann hat unser Opfer die Mail weitergeleitet, möglicherweise an einen IT Mitarbeiter, weil ihm irgendetwas komisch vorkam.

Erfolgt dagegen kein Zugriff auf den Tracking Pixel, den unser Server bereitstellt, dann wissen wir, dass die Mail nicht gelesen wurde.

Um zu verhindern, dass Trackingpixel geladen werden, können von außen stammende Inhalte in einer Email blockiert werden. Thunderbird macht dies beispielsweise standardmäßig:

Das geht zwar mit dem Nachteil einher, dass auch legitime Inhalte wie Grafiken oder Firmenlogos nicht geladen werden, der Nutzen überwiegt hier aber bei weitem:

Der obige Screenshot zeigt ein nicht korrekt geladenes Booking.com Logo, da Thunderbird den Zugriff auf externe Inhalte blockiert hat. Die Darstellung von Mails leidet darunter zwar ein wenig, dafür kann der Absender der Email aber auch nicht mittels Trackingpixel herausfinden, ob die Mail geöffnet wurde oder nicht.

Falls Ihr Emailprovider Grafiken in Emails dagegen immer in allen farbenprächtigen Varianten darstellt, dann können Sie sich sicher sein, dass Ihre Klicks getrackt werden. Vermutlich nur durch diverse Firmen, unter Umständen aber auch durch einen Hacker.

Was kann man damit machen?

Legitime Emailadressen von Mitarbeitern herauszufinden oder auch private Emailadressen von besonders interessanten Zielpersonen in Erfahrung zu bringen, ist die Voraussetzung für eine Vielzahl weiterer Angriffe:

 

Wenn die Emailadresse also erst einmal bekannt ist (was nur schwer zu verhindern ist) dann muss damit gerechnet werden, dass die obigen Angriffe grundsätzlich möglich sind.

Wie schon angesprochen, sind die oben beschriebenen Konzepte (Email Verifizierung, Tracking Pixel) natürlich auch „gutartig“ nutzbar. Und im Vergleich zu dem was die internationale Werbeindustrie so umsetzt, sieht der kleine Hacker mit seiner Ransomware wie ein Waisenknabe aus.

Gegenmaßnahmen

Grundsätzlich kann man nur relativ wenig dagegen unternehmen, dass Angreifer versuchen, die eigene Emailadresse zu verifizieren.

Das Tracking des Klicks auf die Email lässt sich zumindest dadurch erschweren, dass man kein Laden von externen Inhalten erlaubt. Wobei damit dann auch der Nachteil einhergeht, dass die Darstellung der Emails nicht mehr wirklich schön anzusehen ist.

Fazit

Dass die eigene Emailadresse einem Angreifer bekannt ist, lässt sich im geschäftlichen Umfeld kaum vermeiden (theoretisch könnte man für interne Kommunikation ein anderes Emailschema verwenden als für externe, mit einer zunehmenden Anzahl an Mitarbeitern wird das aber mit Sicherheit früher oder später für Verwirrung und Probleme sorgen).

Im privaten Umfeld lässt sich die Emailadresse einfacher verbergen, indem man eine Adresse wählt, die nicht die üblichen Bestandteile wie Vor- und Nachname und Geburtsdaten enthält.

Um zu verhindern, dass Angreifer die Existenz von Emailadressen verifizieren können, sollte der Emailserver so konfiguriert werden, dass jegliche Verifizierungsanfragen abgelehnt werden. Der Verifizierung durch Tracking Pixel kann man sich zudem dadurch entziehen, dass Inhalte von anderen Seiten standardmäßig nicht geladen werden, sondern gegebenenfalls extra erlaubt werden müssen. Dass die eigene Emailadresse einem Angreifer bekannt ist, ist für sich selbst genommen noch nicht übermäßig dramatisch. Allerdings wird damit die Basis für diverse andere Angriffe wie Phishing oder den Versand von Malware gelegt, was wir uns in den weiteren Beiträgen unserer „Emails als Waffe“ Serie noch näher ansehen werden.