Whitelisting für Phishing-Tests und Phishing-Simulationen

So kommen Ihre Phishing-Test-E-Mails auch an

Hürden beim Versand von Phishing-Test-E-Mails

Grundsätzlich ist der Versand einer gefälschten E-Mail für einen professionellen Angreifer nach wie vor relativ einfach möglich. Ihm reichen in einer gezielten Attacke 2 – 3 Opfer, die auf die Phishing-E-Mail reinfallen. Mit einer vernünftig aufbereiteten E-Mail fliegt er bei dieser geringen Anzahl weit unter dem Radar typischer Schutzmechanismen. Zur Sensibilisierung wollen wir aber bei Phishing Simulationen möglichst viele Personen erreichen. Deshalb verschicken wir oft hunderte dieser gefälschten E-Mails in kurzer Zeit. Und genau das ist die Herausforderung.

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 rechnen Sie damit, dass bei den ersten Simulationen trotz sorgfältiger Vorarbeit von Ihnen nicht alle E-Mails zugestellt werden.

Whitelisting, damit die E-Mail zugestellt wird

Durch Whitelisting entsteht immer ein potenzielles Sicherheitsrisiko. Ein Angreifer könnte von der IP-Adresse echte Phishing-E-Mails senden und somit eine Prüfung umgehen. Das Risiko ist aber begrenzt, solange die IP-Adresse wirklich dem Phishing-Server zugeordnet ist. Ein Angreifer müsste erst einmal diese IP-Adresse in Erfahrung bringen und dann den Server kompromittieren. Sie sollten aber trotzdem regelmäßig überprüfen, welche Whitelistings nach einer Simulation noch erforderlich sind und nicht mehr benötigte Einstellungen auf allen Systemen wieder entfernen.

Wenn Sie Ihre E-Mail-Infrastruktur selbst betreiben, 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.

Sprechen Sie mit dem jeweiligen Systemadministrator über das Szenario und lassen Sie 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 September 2021 wider.

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

1. Öffnen Sie das Microsoft Security Center.

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

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

Wenn Sie 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 finden Sie unter https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/configure-advanced-delivery?view=o365-worldwide

Bitte versuchen Sie zuerst den "normalen Weg" oben. In 85% aller Tentants funktioniert dieser. In einigen Tenants ist der "normale Weg" allerdings nicht ausreichend. Warum das so ist, weiß wahrscheinlich nicht einmal Bill Gates. 🤷‍♀️

Unsere Vermutung ist, dass alte Security-Einstellungen das neue "All-in-One" Whitelisting des "normalen Wegs" überlagern. Wie auch immer: sollten Ihre E-Mails trotz Whitelisting über den "normalen Weg" immer noch in Quarantäne landen, ist es Zeit für die Brechstange.

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

1. Öffnen Sie das Microsoft Security Center.

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

3. Bleiben Sie bei den Anti-spam policies und wechseln Sie zur Anti-spam inbound policy. Fügen Sie 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. Öffnen Sie das Exchange Online Admin Center und wechseln Sie dort in die Rules.

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

3. Tragen Sie die IP-Adresse Ihres Phishing-Servers ein. 

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

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

Mit diesen Einstellungen haben Sie jetzt den "ultimativen Durchzug" aktiviert. Bitte denken Sie 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. Sie können 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 finden Sie 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. 😉

Whitelisting, damit die Phishing-Seite erreichbar bleibt

Die Zustellung der E-Mail ist die eine Sache. Der Aufruf der Phishing-Seite eine andere. Wenn Sie mit "Standard-Szenarien" der typischen Phishing-Tool-Anbieter arbeiten, ist das in der Regel halbwegs unproblematisch, das diese oftmals fest belegte (aber unrealistische) URLs verwenden und somit Google Safe Browsing und Kollegen nicht auf den Plan rufen werden. Erfolgreiche Angreifer verwenden aber leider meist keine Standard-Szenarien (das wissen wir aus unserer Incident-Resonse-Tätigkeit und unseren Social Engineering Assessments). Sie müssen ja auch nur 2 - 3 E-Mails durchbringen (siehe oberen Abschnitt "Die Masse macht's"). Wir phishen daher gerne mit möglichst realistischen Business-Szenarien. Und solche Landing Pages erregen (Gott sei Dank) aber ab einer bestimmten Klickrate die Aufmerksamkeit von Sicherheitstools. 

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.

Sprechen Sie mit dem jeweiligen Systemadministrator über das Szenario und lassen Sie 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. 

Sollten Sie im Unternehmen diese Browser als Standardbrowser verwenden, ist Ihre 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.

Sie können aber in Ihren 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.

Sollten Sie 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 finden Sie unter https://chromeenterprise.google/policies/#SafeBrowsingAllowlistDomains

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

2. Hinterlegen Sie die GPO-Vorlagen auf dem Windows Domain Controller und weisen Sie die Policy den entsprechenden Nutzergruppen zu.

3. Konfigurieren Sie die Policy.

4. Fügen Sie die Domain der Phishing-Seite hinzu.

5. Aktivieren sie die Policy.

Bitte denken Sie 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 Sie das Risiko dennoch eingehen möchten:

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

2. Hinterlegen Sie die GPO-Vorlagen auf dem Windows Domain Controller und weisen Sie die Policy den entsprechenden Nutzergruppen zu.

3. Deaktivieren Sie die Policy.

Aktivieren Sie 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 Sie 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. Laden Sie das entsprechende Policy Template herunter:
https://docs.microsoft.com/en-us/deployedge/configure-microsoft-edge

2. Hinterlegen Sie die GPO-Vorlagen auf dem Windows Domain Controller und weisen Sie die Policy den entsprechenden Nutzergruppen zu.

3. Konfigurieren Sie die Policy.

4. Fügen Sie die Domain der Phishing Seite hinzu.

5. Aktivieren sie die Policy.

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

Wenn Sie gemäß "Whitelisting in Exchange Online" die Domain und IP-Adresse whitelisten, 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 Ihrem Lizenzstatus bei Microsoft) eine Überprüfung von potenziell gefährlichen Links in E-Mails an. Sollten Sie 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. Öffnen Sie das Microsoft Security Portal und gehen Sie unter Threat Policies in die Safe Links Einstellungen.

2. In der Policy, die E-Mails auf "unknown potentially malicious URLs" prüft, können Sie Ausnahmen definieren. Fügen sie dort die Domain des Phishing Servers hinzu.

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