Phishing-aanvallen blijven een enorme uitdaging voor organisaties in 2025. In feite, met aanvallers die op identiteit gebaseerde technieken in toenemende mate gebruiken over software-exploits, vormt phishing aantoonbaar een grotere bedreiging dan ooit tevoren.
Aanvallers gebruiken in toenemende mate op identiteit gebaseerde technieken over software-exploits, met phishing en gestolen referenties (een bijproduct van phishing) nu de primaire oorzaak van inbreuken. Bron: Verizon DBIR
Aanvallers wenden zich tot identiteitsaanvallen zoals phishing omdat ze alle dezelfde doelstellingen kunnen bereiken als in een traditioneel eindpunt of netwerkaanval, gewoon door in te loggen op het account van een slachtoffer. En met organisaties die nu honderden internet -apps gebruiken tijdens hun personeelsbestand, is de reikwijdte van accounts die kunnen worden gefilmd of gericht op gestolen referenties exponentieel gegroeid.
Met MFA-bypassing phishing-kits de nieuwe normale, in staat tot phishing-accounts beschermd door SMS, OTP en push-gebaseerde methoden, worden detectiecontroles onder constante druk gezet terwijl preventiecontroles tekortschieten.
Aanvallers omzeilen detectiecontroles
Het grootste deel van de handhaving van de phishing -detectie en controle is gericht op de e -mail- en netwerklaag – meestal bij de Secure Email Gateway (SEG), Secure Web Gateway (SWG)/proxy, of beide.
Maar aanvallers weten dit en nemen stappen om deze controles te voorkomen, door:
- Routinematig door IOC aangedreven blocklists ontwijken door algemeen ondertekende elementen zoals IP’s, domeinen en URL’s dynamisch te roteren en bij te werken.
- Het voorkomen van analyse van hun phishing -pagina’s door botbescherming zoals Captcha of CloudFlare Turnstile te implementeren naast andere methoden voor detectieontduiking.
- Visuele en DOM -elementen op de pagina wijzigen, zodat zelfs wanneer de pagina wordt geladen, detectiesignaturen mogelijk niet activeren.
En in feite, door het lanceren van multi- en cross-channel aanvallen, ontwijken aanvallers volledig e-mailgebaseerde controles. Zie dit recente voorbeeld, waarbij aanvallers zich voordoen als Onfido hun phishing -aanval afleverde via kwaadaardige Google -advertenties (aka Malvertising) – het e -mail helemaal omzeilen.
Het is de moeite waard om hier ook op de beperkingen van e-mailgebaseerde oplossingen te wijzen. E -mail heeft een aantal extra controles rond de reputatie van de afzender en dingen zoals DMARC/DKIM, maar deze identificeren niet echt kwaadaardig pagina’s. Evenzo doen sommige moderne e -mailoplossingen veel diepere analyse van de inhoud van een e -mail. Maar … dat helpt niet echt bij het identificeren van de phishing -sites zelf (geeft alleen aan dat men in de e -mail kan worden gekoppeld). Dit is veel geschikter voor BEC-stijl aanvallen waarbij het doel is om het slachtoffer sociaal te ingenieur, in tegenstelling tot het koppelen van hen aan een kwaadwillende pagina. En dit helpt nog steeds niet bij aanvallen die over verschillende media worden gelanceerd, zoals we hierboven hebben benadrukt.
Hoe op browser gebaseerde detectie en respons het speelveld kunnen nivelleren
De meeste phishing -aanvallen omvatten de levering van een kwaadaardige link naar een gebruiker. De gebruiker klikt op de link en laadt een kwaadaardige pagina. In de overgrote meerderheid van de gevallen is de kwaadaardige pagina een inlogportaal voor een specifieke website, waar het doel voor de aanvaller is om het account van het slachtoffer te stelen.
Deze aanvallen gebeuren vrijwel uitsluitend in de browser van het slachtoffer. Dus in plaats van meer e-mail- of netwerkgebaseerde bedieningselementen te bouwen die van de buitenkant in phishing-pagina’s worden bekeken die in de browser zijn toegankelijk, is er een enorme kans die wordt gepresenteerd door het bouwen van phishing-detectie- en responsmogelijkheden binnen de browser.
Als we kijken naar de geschiedenis van detectie en reactie, is dit heel logisch. Toen eindpuntaanvallen in de late jaren 2000 / begin 2010 omhoogschoten, profiteerden ze van het feit dat verdedigers malware probeerden te detecteren met voornamelijk netwerkgebaseerde detecties, op handtekeningen gebaseerde analyse van bestanden en het uitvoeren van bestanden in sandboxen (die betrouwbaar werden verslagen met sandbox-aware malware en dingen gebruiken als simpel zo eenvoudig als een uitvoering in de code). Maar dit maakte plaats voor EDR, die een betere manier presenteerde om kwaadaardige software te observeren en te onderscheppen realtime.
De sleutel hier was om in de gegevensstroom te komen om activiteit in realtime op het eindpunt te kunnen observeren.
We zijn vandaag in een vergelijkbare positie. Moderne phishing -aanvallen vinden plaats op webpagina’s die zijn toegankelijk via de browser, en de tools waarop we vertrouwen – e -mail, netwerk, zelfs eindpunt – hebben niet de vereiste zichtbaarheid. Ze kijken van de buitenkant.
Maar wat als we detectie en reactie zouden kunnen doen in de browser? Hier zijn drie redenen waarom de browser het beste is om phishing -aanvallen te stoppen:
#1: Pagina’s analyseren, geen links
Gemeenschappelijke phishing -detecties zijn gebaseerd op de analyse van links of statische HTML in tegenstelling tot kwaadaardige pagina’s. Moderne phishing -pagina’s zijn niet langer statische HTML – net als de meeste andere moderne webpagina’s zijn dit dynamische web -apps die in de browser worden weergegeven, waarbij JavaScript de pagina dynamisch herschrijft en de kwaadaardige inhoud lanceert. Dit betekent dat de meeste elementaire, statische controles niet de kwaadaardige inhoud op de pagina identificeren.
Zonder diepere analyse is u afhankelijk van het analyseren van dingen zoals domeinen, URL’s en IP-adressen tegen bekende BAD-blocklists. Maar deze zijn allemaal zeer wegwerpbaar. Aanvallers kopen ze in bulk, nemen constant legitieme domeinen over en plannen in het algemeen voor het feit dat ze er veel doorheen komen. De moderne phishing-architectuur is ook in staat om de links dynamisch te roteren en bij te werken aan bezoekers van een continu vernieuwde zwembad (dus elke persoon die op de link klikt, wordt een andere URL geserveerd) en zelfs zo ver gaande als het gebruik van dingen als eenmalige magische links (wat ook betekent dat alle beveiligingsteamleden die later proberen de pagina te onderzoeken, dit niet kunnen doen).
Uiteindelijk betekent dit dat blocklists gewoon niet zo effectief zijn – omdat het triviaal is voor aanvallers om de indicatoren te veranderen die worden gebruikt om detecties te creëren. Als je denkt aan de piramide van pijn, staan deze indicatoren recht onderaan – het soort dingen waar we al jaren van weg zijn in de eindpuntbeveiligingswereld.
Maar in de browser kunt u de gerenderde webpagina in al zijn glorie observeren. Met veel diepere zichtbaarheid van de pagina (en de kwaadaardige elementen) kun je …
#2: Detecteer TTPS, geen IOC’s
Zelfs wanneer op TTP gebaseerde detecties in het spel zijn, zijn ze meestal afhankelijk van het samenvoegen van netwerkverzoeken of het laden van de pagina in een sandbox.
Aanvallers worden echter behoorlijk goed in het ontwijken van Sandbox -analyse – gewoon door BOT -bescherming te implementeren door gebruikersinteractie te vereisen met een Captcha of CloudFlare Turnstile.
Zelfs als u voorbij tourniquet kunt komen, moet u de juiste URL -parameters en headers leveren en JavaScript uitvoeren, om de kwaadaardige pagina te krijgen. Dit betekent dat een verdediger die de domeinnaam kent, het kwaadaardige gedrag niet kan ontdekken door een eenvoudig HTTP (s) -verzoek aan het domein te doen.
En als dit alles niet genoeg was, verdoezelen ze ook zowel visuele als DOM-elementen om te voorkomen dat op kenmerken gebaseerde detecties ze ophalen-dus zelfs als je op de pagina kunt landen, is er een grote kans dat je detecties niet zullen activeren.
Wanneer u een proxy gebruikt, hebt u enige zichtbaarheid van het netwerkverkeer dat wordt gegenereerd door een gebruiker die toegang heeft en met een pagina met een pagina. U zult echter moeite hebben om belangrijke acties te correleren, zoals of de gebruiker zijn wachtwoord heeft ingevoerd met het specifieke tabblad bij het omgaan met het enorme aantal ongeorganiseerde netwerkverkeergegevens.
Maar je krijgt veel betere zichtbaarheid van dit alles in de browser, met toegang tot:
- Volledig gedecodeerd HTTP -verkeer – niet alleen DNS en TCP/IP metadata
- Volledige gebruikersinteractie traceren – Elke klik, toetsaanslag of DOM -wijziging kan worden getraceerd
- Volledige inspectie bij elke uitvoeringslaag, niet alleen initiële HTML geserveerd
- Volledige toegang tot browser -API’s, om te correleren met browsergeschiedenis, lokale opslag, bijgevoegde cookies, enz.
Dit geeft je alles wat je nodig hebt om high-fidelity detecties te bouwen die gericht zijn op paginagedrag en gebruikersinteractie-dat is veel moeilijker voor aanvallers om rond te komen in vergelijking met op IOC gebaseerde detecties.
En met deze nieuwe zichtbaarheid, omdat je in de browser zit en de pagina tegelijkertijd ziet als de gebruiker ermee omgaat, kun je …
#3: Intercept in realtime, niet post mortem
Voor niet-browseroplossingen, Real-time phishing-detectie is in principe niet bestaand.
In het beste geval kan uw proxy-gebaseerde oplossing mogelijk kwaadaardig gedrag detecteren via het netwerkverkeer dat wordt gegenereerd door uw gebruiker die met de pagina interageert. Maar vanwege de complexiteit van het reconstrueren van netwerkaanvragen na TLS-Encryption, gebeurt dit meestal op een vertraging en is dit niet volledig betrouwbaar.
Als een pagina wordt gemarkeerd, vereist deze meestal verder onderzoek door een beveiligingsteam om valse positieven uit te sluiten en een onderzoek af te starten. Dit kan aannemen uren op zijn best waarschijnlijk dagen. Zodra een pagina is geïdentificeerd als kwaadaardig en IOC’s zijn gemaakt, kan deze duren dagen of zelfs weken Voordat de informatie wordt gedistribueerd, worden TI -feeds bijgewerkt en in blocklists ingenomen.
Maar in de browser observeert u de pagina in realtime, zoals de gebruiker deze ziet, vanuit de browser. Dit is een game -wisselaar als het gaat om niet alleen detecteren, maar het onderscheppen en afsluiten van aanvallen voordat een gebruiker wordt gefilmd en de schade wordt aangericht. Dit verandert de focus van post-mortem insluiting en opruiming tot pre-compromisonderschrijving in realtime.
De toekomst van phishing-detectie en respons is gebaseerd op browsers
Push Security biedt een browsergebaseerde identiteitsbeveiligingsoplossing die phishing-aanvallen onderschept terwijl ze plaatsvinden-in werknemersbrowsers. In de browser zijn levert veel voordelen op als het gaat om het detecteren en onderscheppen van phishing -aanvallen. Je ziet de live -webpagina die de gebruiker ziet, zoals ze het zien, wat betekent dat je veel betere zichtbaarheid hebt van kwaadaardige elementen die op de pagina draaien. Het betekent ook dat u realtime bedieningselementen kunt implementeren die in werking komen wanneer een kwaadaardig element wordt gedetecteerd.
Wanneer een phishing -aanval een gebruiker met push raakt, ongeacht het leveringskanaal, inspecteert onze browserverlenging de webpagina die wordt uitgevoerd in de browser van de gebruiker. Push merkt op dat de webpagina een inlogpagina is en dat de gebruiker zijn wachtwoord in de pagina invoert, die dat detecteert:
- Het wachtwoord dat de gebruiker de phishing -site binnengaat, is eerder gebruikt om in te loggen op een andere site. Dit betekent dat het wachtwoord wordt hergebruikt (slecht) of dat de gebruiker wordt gephist (nog erger).
- De webpagina wordt gekloond op een legitieme inlogpagina die door push vingerafdrukt is.
- Een phishing toolkit draait op de webpagina.
Als gevolg hiervan wordt de gebruiker geblokkeerd om met de phishing -site te communiceren en verhinderde het niet door te gaan.
Dit zijn goede voorbeelden van detecties die moeilijk (of onmogelijk) zijn voor een aanvaller om te ontwijken – je kunt een slachtoffer niet phish als ze hun referenties niet in je phishing -site kunnen betreden! Lees hier meer over hoe PUSH hier phishing -aanvallen detecteert en blokkeert.
Leer meer
Het stopt daar niet – PUSH biedt uitgebreide detectie van identiteitsaanval en responsmogelijkheden tegen technieken zoals referentievulling, wachtwoordspuiten en sessiekaping met behulp van gestolen sessietokens. U kunt ook PUSH gebruiken om identiteitskwetsbaarheden te vinden en op te lossen in elke app die uw werknemers gebruiken, zoals: Ghost Logins; SSO dekking hiaten; MFA -openingen; zwakke, overtreden en hergebruikte wachtwoorden; risicovolle oauth -integraties; en meer.
Als je meer wilt weten over hoe PUSH je helpt om veel voorkomende technieken voor identiteitsaanval te detecteren en te verslaan, boek dan wat tijd met een van ons team voor een live demo – of registreer een account om het gratis te proberen. Bekijk hier onze snelstartgids.
