Whitelisting für Phishing-Tests und Phishing-Simulationen

Nahezu alle E-Mail-Security-Lösungen haben bestimmte Grenzwerte, ab denen sie einen Absender blockieren. Typische E-Mail-Server verweigern beispielsweise ab ca. 50 E-Mails innerhalb kurzer Zeit vom gleichen Absender die Annahme. Manche Anti-Spam-Systeme können schon nach 10 E-Mails anspringen und die IP-Adresse oder die Domain des E-Mail-Servers auf eine Blocklist setzen.

Für eine möglichst breite Sensibilisierung im Rahmen einer Security-Awareness-Kampagne möchten wir aber möglichst viele Benutzer erreichen. Und das in einer angemessenen Zeit. Würde der Versand zu sehr in die Länge gezogen, würden sich die Benutzer untereinander warnen und das Ergebnis wäre stark verwässert.

Die Herausforderung liegt also nicht darin, eine gefälschte E-Mail zu senden, sondern 100 oder 1.000 in einer Minute. Und diese Masse lässt sich vorab nicht wirklich sauber testen.

Wir haben bereits viele Kundensituationen vorgefunden, bei denen unterschiedliche E-Mail-Domains (z.B. E-Mail-Adressen in verschiedenen Ländern oder bei Tochterfirmen) über verschiedene E-Mail-Systeme mit ganz unterschiedlichen Schutzmaßnahmen empfangen werden.

Zusätzlich bieten viele Internet- und Cloud-Provider heute technische Schutzmaßnahmen an, die manchen Kunden (und selbst manchen Anbietern 😁) nicht bewusst sind. Die Überschrift „Echt? So was haben wir?“ ist die Originalaussage eines System Engineers auf unseren Hinweis, dass wir durch deren Cloud-Security-Lösung trotz Whitelisting auf einer Blocklist gelandet sind.

Die Herausforderung liegt also, vor allem bei größeren Unternehmen (> 2.000 Mitarbeiter) darin,

• möglichst alle relevanten Wege zu überprüfen,
• die Phishing Absender E-Mail-Adresse in den vorgeschalteten E-Mail-Security-Lösungen freizuschalten
• die IP-Adresse und Sender Domain des Phishing-Server auf den E-Mail-Systemen zur Liste der sicheren Sender hinzuzufügen
• die Phishing-Seite in allen Proxies, Cloud-Systemen und Browsern freizuschalten, und
• möglichst alle relevanten Mitarbeiter in Security Operation Centers oder Helpdesks zu informieren.

Nach ein paar Versuchen finden sich immer die richtigen Einstellungen, aber rechne damit, dass bei den ersten Simulationen trotz sorgfältiger Vorarbeit von Ihnen nicht alle E-Mails zugestellt werden.

Wenn du deine E-Mail-Infrastruktur selbst betreibst, liegt diese in der Regel hinter Security-Systemen wie SPAM Filter oder Firewalls (Sophos, Ironport, etc.). Diese Systeme springen oftmals nicht bei den einzelnen Test-E-Mails an, aber beim Versand von hunderten E-Mails während der eigentlichen Angriffssimulation.

Sprich mit dem jeweiligen Systemadministrator über das Szenario und lasse ihn die richtigen Einstellungen treffen. Oftmals müssen Absenderadresse und IP-Adresse whitelisted werden, damit der Massenansturm nicht blockiert wird.

Exchange Online / Microsoft Azure wird von Microsoft ständig weiterentwickelt und Funktionen wandern in andere Portale, verschwinden oder es kommen neue hinzu. Diese Anleitung spiegelt den Stand 2025 wider.

Whitelisting der IP-Adresse und Domain über "Advanced Delivery Role"

1. Öffne das Microsoft Security Center

2. Gehe im Security Center zu Policies & Rules, dort Threat Policies und dort unter Rules zur Advanced Delivery Regel. Dort klicke auf den Reiter Phishing Simulation.

3. Trage über Add bei Sending Domain die Absende-Domain der E-Mail ein, unter Sending IP die IP-Adresse deines Phishing-Servers, der die E-Mail versendet.

Wenn du also eine Phishing-Simulation vom Absender alert@microsoft-security.com versenden wollen, lautet die einzutragende Domain microsoft-security.com.

Gemäß Microsoft-Dokumentation werden mit diesen Settings quasi alle Security-Prüfungen ausgeschaltet, außer die E-Mail enthält echte Malware.

• Filter in Exchange Online Protection (EOP) und Microsoft Defender für Office 365 unternehmen nichts.
• Zero-hour Auto Purge für SPAM und Phishing (ZAP, als bösartig erkannte E-Mails können automatisch aus den Postfächern der Benutzer entfernt werden) unternimmt nichts.
• Automated investigation and response (AIR) in Microsoft Defender unternimmt nichts.
• Safe Links in Defender für Office 365 blockt die identifizierten URLs und Attachments nicht.
• Es werden keine System Alerts ausgelöst.
• Sollte die E-Mail über den Microsoft Report-Phishing-Button gemeldet werden, erhalten Admins im Azure Security Portal unter Submissions eine Meldung, dass die Nachricht Teil einer Phishing-Simulation und keine echte Bedrohung ist.

Weiterführende Informationen zu Security-Einstellungen in Exchange Online findest du unter https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/configure-advanced-delivery?view=o365-worldwide

Zudem sind folgende Whitelisting-Einstellungen vorzunehmen.

Whitelisting der IP-Adresse in der "Anti-spam policy"

1. Öffne das Microsoft Security Center.

2. Gehe im Security Center zu Policies & Rules, dort Threat Policies und dort unter Policies zur Anti-Spam Policy. Dort fügst du in der Connection filter policy die IP-Adresse deines Phishing-Servers hinzu.

3. Bleibe bei den Anti-spam policies und wechsle zur Anti-spam inbound policy. Füge dort die Absender-Adresse der Phishing-Simulation hinzu.

Erstellen einer Mail Flow Rule im Exchange Online Admin Center

Achtung: das Exchange Online Admin Center benötigt wahrscheinlich andere Zugangsrechte als das Microsoft Security Center.

1. Öffne das Exchange Online Admin Center und wechsle dort in die Rules.

2. Füge über das Plus-Symbol eine neue Regel hinzu.

3. Trage die IP-Adresse deines Phishing-Servers ein.

4. Wähle unter dem Punkt "specify URL" die Option "Bypass spam filtering" aus.

5. Bezeichne die neue Regel bspw. als "Bypass phishing mail" und wähle die auszufüllenden Felder entsprechend dem nachstehenden Screenshot aus.

Mit diesen Einstellungen hast du jetzt den "ultimativen Durchzug" aktiviert. Bitte denke daran, die Einstellungen nach der Phishing-Simulation wieder rückgängig zu machen.

Phishing-Simulationssoftware bietet oftmals an, einen Wert für das "Öffnen der E-Mail" auszugeben. Dafür wird in der E-Mail ein "Tracking Image" implementiert. Das Bild (engl. "Image") wird beim Öffnen der E-Mail vom Server nachgeladen, wodurch der Wert für "E-Mail wurde geöffnet" ermittelt werden kann. Die Auswertung wird dadurch noch etwas realistischer, weil bei der reinen Anzahl gesendeter E-Mails auch alle Mitarbeiter gezählt werden, die beispielsweise im Urlaub, krank, in Altersteilzeit, in Mutterschutz, etc. sind und die E-Mail daher gar nicht öffnen können.

So weit, so schön. Outlook blockt allerdings den Download von Bildern von "untrusted" Sendern. Dadurch wird ein "E-Mail wurde geöffnet" nur gezählt, wenn ein User bewusst zusätzlich zum Öffnen der E-Mail auch noch "Download Picture" anklickt.

Die einzige Lösung zum automatischen Laden der Tracking-Bilder ist, die Absender-Adressen der "SafeSenderList" (Liste sicherer Absender) der User hinzufügen. Dann werden die Bilder automatisch geladen, sobald die E-Mail geöffnet wird. Nur damit liefert der Wert "E-Mail wurde geöffnet" ein realistisches Bild.

Das ist allerdings keine zentrale Einstellung, sondern muss bei jedem Empfänger einzeln in seinem Postfach gemacht werden. Du kannst dafür in Exchange (On Premise und Cloud) Powershell Skripte verwenden:

Hinzufügen zur SafeSenderList
Set-MailboxJunkEmailConfiguration -Identity "user1@company.com" -TrustedSendersAndDomains @{Add="phishingdomain.com"}

Entfernen von der SafeSenderList
Set-MailboxJunkEmailConfiguration -Identity "user1@company.com" -TrustedSendersAndDomains @{Remove="phishingdomain.com"}

Das geht leider nur pro Mailbox, es ist also eine Schleife mit allen Mail-Adressen notwendig.

Weitere Informationen findest du unter
https://docs.microsoft.com/en-us/powershell/module/exchange/set-mailboxjunkemailconfiguration

Da die Klickraten bei Phishing-Simulationen immer von vielen verschiedenen Faktoren beeinflusst werden (Schweregrad der Simulation, Anzahl der Adressaten, Warnungen in Großraumbüros, Warnungen durch E-Mails innerhalb eines Teams, Blockierung durch einen eifrigen Administrator, etc., ist der Aufwand für das Tracking von "E-Mail wurde geöffnet" schon eher etwas für Enthusiasten. Wir empfehlen in der Regel, den Aufwand zu sparen und die Klickraten allgemein nicht allzu ernst zu nehmen. 😉

Die Internetzugang wird durch Security-Systeme wie Proxy oder Web Application Firewalls geschützt. In der Regel schlagen diese Systeme bei einer Phishing-Simulation nicht an. Es gibt aber Kundensituationen, bei denen die Phishing-Webseite explizit auf eine Whitelist muss, da die Systeme automatisch Adressen mit Listen wie Google Safe Browsing abgleichen.

Sprich mit dem jeweiligen Systemadministrator über das Szenario und lasse ihn die richtigen Einstellungen treffen.
 

Ohne Whitelisting auf Google Safe Browsing werden Phishing-Simulationen, die "echte" Anmeldeseiten mit realistischen URLs simulieren (z. B. Microsoft 365 oder PayPal) innerhalb weniger Minuten von Google geblockt.

Google Chrome und Firefox nutzen ein zentrales Google Security Feature, die "Safe Browse" Liste. Im Prinzip funktioniert Google Safe Browsing ähnlich wie Microsoft Safe Link: Potenziell gefährliche Links werden automatisiert auf Phishing untersucht.

Da bei Chrome und Firefox jeder Klick auf einen Link zentral bei Google Safe Browsing geprüft wird und bei Phishing-Simulationen viele Benutzer in kurzer Zeit den gleichen Link aufrufen, landen Phishing-Simulationen, die bekannte Anmeldeseiten simulieren, bei Google Safe Browsing sehr schnell (innerhalb von 1 – 2 Stunden, Rekord liegt bei 12 Minuten) auf der Blocklist von Google Safe Browsing. Bei Klick auf den Phishing-Link sehen Benutzer mit Chrome oder Firefox Browser dann eine sehr prominente Warnung.

Solltest du im Unternehmen diese Browser als Standardbrowser verwenden, ist deine Phishing-Simulation ab jetzt tot.

Der Besitzer der Domain (in unserem Fall wir, HvS) hat zwar die Möglichkeit, die Domain über ein Google Online Tool wieder von dieser Blockliste entfernen zu lassen, das dauert aber i. d. R. 3 – 24 Stunden und ist somit quasi nutzlos, denn in dieser Zeit hat sich der Phishing-Angriff in der Belegschaft bereits herumgesprochen. Zudem kann die Seite nach der erneuten Freischaltung sehr schnell wieder auf der Blockliste landen, da Google Safe Browsing mit automatisierten Regeln arbeitet. Google bietet keine Möglichkeit, eine Webseite zentral weltweit zu whitelisten, und das ist auch gut so.

Du kannst aber in deinen Chrome oder Firefox Browsern über Gruppenrichtlinien sogenannte SafeBrowsingAllowlistDomains definieren. Domains in dieser Liste werden nicht von Google Safe Browsing überprüft, somit erscheint auch das obige Warnfenster nicht, selbst wenn die Domain bereits auf der Blockliste gelandet ist.

Solltest du im Unternehmen vermehrt Chrome als Browser benutzen und realitätsnahe Business-Szenarien simulieren wollen, ist ein client-seitiges Whitelisting über SafeBrowsingAllowlistDomains aus unserer Sicht zwingend erforderlich, da sonst die Phishing-Simulation sehr schnell enden wird.

Weitere Informationen findest du unter https://chromeenterprise.google/policies/#SafeBrowsingAllowlistDomains

1. Lade das entsprechende Policy Template herunter:
https://www.chromium.org/administrators/policy-templates

2. Hinterlege die GPO-Vorlagen auf dem Windows Domain Controller und weise die Policy den entsprechenden Nutzergruppen zu.

3. Konfiguriere die Policy.

4. Füge die Domain der Phishing-Seite hinzu.

5. Aktiviere die Policy.

Bitte denke daran, die Domain nach der Simulation wieder aus der Policy zu entfernen.

Firefox kann nur Google Safe Browsing an/aus, nicht für spezifische Domains. Die Deaktivierung von Google Safe Browsing erhöht somit signifikant das Risiko bei echten Angriffen und ist daher nicht zu empfehlen.

Falls du das Risiko dennoch eingehen möchtest:

1. Lade das entsprechende Policy Template herunter:
https://support.mozilla.org/en-US/kb/customizing-firefox-using-group-policy-windows

2. Hinterlege die GPO-Vorlagen auf dem Windows Domain Controller und weise die Policy den entsprechenden Nutzergruppen zu.

3. Deaktiviere die Policy.

Aktiviere nach der Simulation unbedingt wieder die Policy, da die Deaktivierung einen erheblich verminderten Schutz gegen Phishing bedeutet.

Microsoft Defender SmartScreen ist das Pendant zu Google Safe Browsing für Microsoft Edge. Wenn du gemäß "Whitelisting in Exchange Online" die Domain und IP-Adresse whitelisten, sollte Microsoft Defender SmartScreen laut Microsoft den Aufruf der Seite ignorieren. Es sollten dann keine weiteren Einstellungen in Defender SmartScreen erforderlich sein. Die nachfolgende Anleitung ist also nur für den Fall, dass das "sollte" mal nicht funktioniert.

Whitelisting aus Microsoft Defender SmartScreen über Gruppenrichtlinien für Microsoft Edge

1. Lade das entsprechende Policy Template herunter:
https://docs.microsoft.com/en-us/deployedge/configure-microsoft-edge

2. Hinterlege die GPO-Vorlagen auf dem Windows Domain Controller und weise die Policy den entsprechenden Nutzergruppen zu.

3. Konfiguriere die Policy.

4. Füge die Domain der Phishing Seite hinzu.

5. Aktiviere die Policy.

Bitte denke daran, die Domain nach der Simulation wieder aus der Policy zu entfernen.

Wenn du gemäß "Whitelisting in Exchange Online" die Domain und IP-Adresse whitelistest, sollte laut Microsoft Dokumentation Safe Links automatisch Links und Anhänge in dieser E-Mail ignorieren. Es sollten dann eigentlich keine weiteren Einstellungen in Safe Links erforderlich sein. Uneigentlich ist das einigen Azure Tenants immer noch egal. Deshalb hier zur Sicherheit der Vorgang.

Microsoft 365 Defender bietet (je nach deinem Lizenzstatus bei Microsoft) eine Überprüfung von potenziell gefährlichen Links in E-Mails an. Solltest du diese Funktion nutzen, kann es durchaus sein (insbesondere bei Phishing-Szenarien, die eine Microsoft-Anmeldeseite simulieren), dass die Phishing-Seite auf die Safe Link Blocklist kommt.

1. Öffne das Microsoft Security Portal und navigiere zu Threat Policies → Safe Links.

2. Wähle die Safe Links Policy deines Unternehmens aus.

3. Klicke auf Edit Protection Settings

4. Wechsle zu Manage URLs

5. Füge die gewünschte Domain über Add URLs hinzu – verwende dabei Wildcards nur am Ende der Domain (z. B. https://phishingdomain.de/*).

Bitte denke daran, die Ausnahme nach der Simulation wieder zu entfernen.