(Spear-)Phishing ist nach wie vor die meistgenutzte Methode, um erfolgreich in ein Unternehmensnetzwerk einzudringen und einen „Initial Access“ zwischen Angreifer und Ziel herzustellen. Dieser Fakt wird immer wieder auf’s Neue von Incident Responders, Threat Analysten und IT-Forensikern bestätigt. Deshalb hält die Agentur der Europäischen Union für Cybersicherheit (ENISA) diesen Trend mit ihrem aktuellsten Threat Landscape Report vom November 2022 wiederholt fest.
www.enisa.europa.eu/publications/enisa-threat-landscape-2022/@@download/fullReport
Einen Schutz gegen breit ausgelegte Phishing-Kampagnen ist heute für viele Unternehmen der Standard und somit unabdingbar. Oftmals werden bereits folgende Massnahmen umgesetzt:
-
- Regelmässige basic Awareness/Phishing Trainings werden durchgeführt
- Email Security Gateways filtern verdächtige Mails und Absender aus dem Mailverkehr
- Web Proxies blockieren verdächtige URLs und Inhalte innerhalb des Netzwerkverkehrs
- Multifaktor Authentisierung ist Standard
- Endpoint Security
- …
Doch gibt es in der D/A/CH Region auch zahlreiche Unternehmen, die einen höheren Schutzbedarf und ein deutlich detaillierteres Risikomanagement leben, weil diese sensitive Informationen besitzen, archivieren, produzieren oder bearbeiten. Denn dann sind sie entweder wirtschaftlich daran interessiert oder gesetzlich dazu verpflichtet, sich verstärkt vor Cyber-Bedrohungen zu schützen, um einen unautorisierten Zugriff auf ihre Daten zu vermeiden.
Genau diesen Organisationen, kritischen Infrastrukturen, Instituten, Gesellschaften, Produzenten, Konzernen und Departementen widmet sich dieser Blogpost.
Wie funktioniert Spear-Phishing?
Spear-Phishing richtet sich gegen ein einzelnes Unternehmen bzw. ein- oder wenige Mitarbeitende/Abteilungen, enthält massgeschneiderten Content und einen durchdachten Ausführungsplan.
Erfolgreiche Spear-Phishing-Angriffe setzen sich aus folgenden Teilen zusammen:
- Task: Reconnaissance Ziel: Informationsgewinnung Mittel: OSINT, Interaktion mit dem Ziel
- Task: Delivery Ziel: Confirmed Reception Mittel: Nachrichten (Mail, Messenger, SMS …)
- Task: User Exploitation Ziel: User Action Mittel: Vertrauen, kontextbasierter Inhalt
- Task: Payload Execution Ziel: Initial Access & Persistence (vgl. „Actions on Objectives“) Mittel: TTPs à la Mitre Attack
Massnahmen gegen Spear-Phishing Attacken
Der nachfolgende Massnahmenkatalog gegen Spear-Phishing soll als Framework und nicht als fertige Checkliste verstanden werden.
Prevention
Öffentliche Angriffsfläche reduzieren
Die sich schützende Organisation sollte sich ein klares Bild machen, welche Informationen öffentlich einsehbar sind. Prozesse und Vorschriften sollten unterbinden, dass Mitarbeiter scheinbar unwichtige Informationen nach Aussen tragen. Das OSINT Framework kann hier unterstützend sein, bei der Überprüfung der öffentlich verfügbaren Informationen über das Unternehmen: osintframework.com
a) Ein Beispiel hierzu ist das LinkedIn Profil des IT-Security Mitarbeiters, welches der Öffentlichkeit einsehbar macht, welche Hersteller im Unternehmen eingesetzt werden und somit welche potenziellen Schwachstellen existieren. Auch wenn es nur um URL Kategorisierung geht. Die URL Kategorie „Finance“ wird in der Regel DPI-Bypassed. Wenn nun jeder vorab auf sitereview.symantec.com prüfen kann, ob der installierte Bluecoat Proxy meinen Payload der vorher organisierten URL www.expireddomains.net direkt auf den Client durchlässt oder nicht, dann profitiert ein ausgefeilter Angreifer.
b) Auch scheinbar zensierte, verpixelte Bilder, die öffentlich gepostet wurden, können je nachdem wieder lesbar gemacht werden und wertvolle Inhalte preisgeben: github.com/bishopfox/unredacter
c) Exponierte Benutzeraccounts sollten erfasst werden, die entsprechenden Mitarbeiter darauf aufmerksam gemacht werden und strengere technische Unternehmensrichtlinien appliziert werden. Bspw. bietet das Mail Defense System „Activeguard“ von xorlab die Möglichkeit, exponierte Mailadressen gesondert zu behandeln, was durchaus empfohlen ist einzusetzen.
d) Die externe Erreichbarkeit des Unternehmens sollte bewusst kanalisiert werden. Bspw. sollte neben dem eigentlichen Business Mail gut überlegt werden, ob externe Kontaktaufnahmen via Microsoft Teams, Cisco Webex usw. erlaubt sein sollen. So wie auch Whatsapp Web, Telegram Web usw. Diese “Kurznachrichten” gelangen oftmals durch einen DPI-Bypass direkt auf den Client-PC. Auch wenn Microsoft und Co. darauf verweisen, den Nachrichten-Content nach Schadsoftware zu scannen. Passwortgeschützte .zip Dateien können solche Standard-Security Funktionen einfach umgehen.
Verwundbare Prozesse eliminieren
Verwundbare Prozesse sind in jeder Organisation anzutreffen und oftmals die Achillesferse jeder Cyber Defense Strategie. Solche von den Organisationen abgesegneten Prozessen führen immer wieder zu unbedachten Kundgebungen von Credentials oder sensitiven Informationen.
a) Per Mail aufgeforderte Passwortwechsel von as-a-Service Clouddiensten aber auch internen Webservices sollten nicht an Admins oder Mitarbeiter versandt werden. Der Passwort Change sollte nicht angekündigt, sondern nach Eingabe der abgelaufenen Credentials direkt und automatisiert in der Applikation erfolgen. Auch Rechnungen von bspw. Microsoft Azure oder Amazon AWS sollten nicht per Mail versandt werden.
b) Benutzer und Admins sollten darauf aufmerksam gemacht werden, dass Passwörter aus dem Passwortmanager Browser Plugin nur auf Webseiten eingefügt werden sollten, wenn diese das entsprechende Passwort vorschlägt. Ansonsten muss die Webseite kritisch hinterfragt werden und nicht aus dem Affekt die Credentials in das Clipboard übernommen werden.
c) Privileged Remote Access kann bspw. zum Schutz der IT-Infrastruktur genutzt werden, sodass Passwörter gar nicht erst den Mitarbeitern bekannt sind. Was man nicht kennt, kann man auch nicht aus Versehen weitergeben. www.avantec.ch/loesungen/beyondtrust/privileged-remote-access/
Erweiterte Technische Massnahmen
Subdomain Takeover
Die Gefahr einem potenziellen Subdomain Takeover zum Opfer zu fallen, steigt stetig an. Vor allem weil immer mehr Unternehmen auf „as-a-Service“ Dienstleistungen zählen, vorher aber eine umfangreiche Evaluation vieler Anbieter durchgeführt haben und vergessen haben, ihre alten CNAME DNS Records zu entfernen. Die grösste Gefahr hierbei ist, dass der angezeigte Content von der bekannten Domain als vertrauenswürdig angeschaut wird. Bspw. existieren oftmals Proxy und Firewall Bypasses für “selbst” gehostete IT-Services.
Tolles Projekt:
github.com/EdOverflow/can-i-take-over-xyz
Typosquatting & Confusables
Die hier erwähnten Techniken sollen Mitarbeiter davor schützen, auf Domains zu gelangen, welche mit der eigenen Domain einfach zu verwechseln sind. Hilfsmittel hierzu können sein:
“Confusables” Character-Set: (www.unicode.org/reports/tr39 bzw. util.unicode.org/UnicodeJsps/confusables.jsp) und die Levenshtein Distance: www.unicode.org/reports/tr39
a) Defensive Domain Registrationen
Es kann sich als sinnvoll erweisen, die naheliegendsten, verfügbaren Domains selber zu registrieren und so präventiv das Unternehmen zu schützen, indem verwechselbare Domains einfach besetzt werden. Hierfür können einfache Suchfunktionen der Domainregistrare verwendet werden. Bspw. Namecheap: www.namecheap.com/domains/registration/results/?domain=&type=beast
b) Typosquatting Block Rule
Es ist jedem klar, dass man nicht jede ähnlich aussehende Domain präventiv kaufen kann. Aber was nicht fehlen darf, ist eine Typosquatting Blacklist auf dem Web Proxy. Es sollte auch nicht vergessen werden, dass bei einem Hit auf eine solche Rule, das SOC alerted werden kann. Hier kann ich folgendes Framework zur Konsultation empfehlen: dnstwister.report/
Detection
Die Zeit gehört immer wieder zu den kritischsten Faktoren gegen Cyberkriminalität. Kernproblem des Spear-Phishings (und allen anderen zielgerichteten Angriffen) ist, dass das eigene Unternehmen der “Patient-0” weltweit ist. Deshalb ist es auch hier ratsam, die Detektionsfähigkeit eines geplanten oder laufenden Angriffs frühzeitig zu erhöhen, damit noch rechtzeitig der Spear-Phishing Angriff neutralisiert und schlimmeres verhindert werden kann.
a) Reporting und Fehlerkultur
Es sollte in jedem Fall eine Fehlerakzeptanz-Kultur gelebt werden. Jeden User kann es treffen, wenn dieser auf einen „falschen“ Link klickt und versehentlich etwas Verdächtiges herunterlädt. Er muss in der Lage sein, dies offen kundgeben zu können und die Möglichkeit haben, dies an die richtige Abteilung mitzuteilen. Nur so kann Schlimmeres noch rechtzeitig verhindert werden. Bspw. ein Mail-Reporting Plugin oder Kontakt zur IT-Hotline sollte gewährleistet sein.
b) Darknet Monitoring
Sollten doch einmal „Initial Access Broker“ unternehmenseigene Credentials oder Zugänge ins Netzwerk im Darknet anbieten, kann ein Darknet Monitoring durch einen spezialisierten Dienstleister den blinden Fleck etwas aufhellen. Auch geplante Angriffe können über Darknet-Foren vorzeitig detektiert und abgewendet werden, weil Cyberkriminelle sich nicht selten über Darknet Foren anonym austauschen. Siehe hierfür auch: www.tec-bite.ch/is-any-of-your-companies-data-in-dark-web/
c) TLS Certificate Monitoring.
Was tun, wenn ein Angreifer über eine Public CA an ein signiertes TLS Zertifikat für meine Domain gelangt? Bspw. weil die CA einen Fehler macht und ihn nicht genau überprüft oder der Angreifer an Identitätsmaterial gekommen ist und so die rechtmässigkeit vortäuschen kann? Wie lange würde es dauern bis ein solcher Identitätsmissbrauch oder Fehler auffliegt?
Dank dem Certificate Transparency Log: certificate.transparency.dev/ werden alle neuausgestellten TLS Zertifikate von Public CAs öffentlich zugänglich und damit überprüfbar gemacht.
Entweder man abonniert einen entsprechenden Service bei einem Dienstleister wie:
blog.cloudflare.com/introducing-certificate-transparency-monitoring/
report-uri.com/products/certificate_transparency_monitoring
Oder man adaptiert dieses frei verfügbare Skript und passt es mit seinen eigenen Search Patterns an, sodass selbstständig ein Monitoring gebaut werden kann: github.com/x0rz/phishing_catcher
Response
Welche Optionen hat man, wenn man merkt, dass eine (Spear-)Phishing-Kampagne das eigene Unternehmen trifft? (Gehen wir davon aus, dass Hack-backs und DDos’ing keine Optionen sind…)
a) Zu allererst sollte der interne Incident Response (IR) Prozess getriggert werden. Sollte externe Hilfe benötigt werden, kann die AVANTEC oder ein FIRST Team kontaktiert werden: https://www.avantec.ch/services/incident-response/ https://www.first.org/members/teams/
Checklisten und Empfehlungen bei einem Cyber-Vorfall für CISOs und Führungspersonen: https://www.ncsc.admin.ch/ncsc/de/home/infos-fuer/infos-unternehmen/vorfall-was-nun.html
b) Je nach Vorfall sollte eine Meldung an die zuständige Behörde wie bspw. dem NCSC oder Datenschutzbeauftragten gemacht werden, sofern abgeflossene Daten nicht ausgeschlossen werden können. Oftmals sind Unternehmen mit erhöhtem Schutzbedarf bereits an eine zentrale “Malware Information Sharing Platform“ angebunden und können so innerhalb der Community ihren Vorfall kundgeben und dadurch Unterstützung einholen.
c) Es ist auch möglich, den eigenen IR-Prozess mit einem automatisierten Takedown Request zu erweitern.
Bspw. mit einem solchen Tool: phish.report/docs/thehive-integration
Add-ons
Hass-Liebe Wildcard TLS Zertifikat
Das einfach zu administrierende Wildcard TLS Zertifikat, welches sich auf fast jedem Server – unterschiedlichster Sicherheitsstufen – einer Organisation befindet, ist Gefahr, aber auch Segen zugleich. Einerseits muss der Admin nur einen einzelnen privaten Schlüssel (be)schützen, andererseits wandert der private Schlüssel bei grösseren Organisationen gerne alljährlich durch viele Abteilungen und trägt so zu einer einfacheren Kompromittierung bei. Es soll mit Bedacht für oder gegen Wildcard TLS Zertifikate entschieden werden.
Browser bzw. Website Isolation
Entweder kann der gesamte Browser in einer Micro VM betrieben werden wie bspw. HP Sure Click dies umsetzt: www.avantec.ch/loesungen/hp-wolf-security/ oder fragwürdige Destinations können automatisiert durch den Web Proxy via einem Pixel Stream auf den Client Browser übertragen werden. Dies kann bspw. eine Erweiterung des Bluecoat Proxys (ehemals Fireglass) oder Zscaler tun: www.avantec.ch/loesungen/symantec/symantec-web-gateway/#features , www.avantec.ch/loesungen/zscaler/zscaler-cloud-browser-isolation/
Der Beitrag Spear-Phishing – Prevention, Detection & Response erschien zuerst auf Tec-Bite.