Niets anders dan dezelfde bekende dreiging? Phishing campagnes lijken altijd volgens hetzelfde principe te verlopen: Een link of bijlage die in een e-mail wordt geplaatst, verwijst naar een phishing-website om specifieke gegevens over de ontvanger te achterhalen. Echter, sommige gebruikers volgen inmiddels bepaalde processen waardoor traditionele phishing-tactieken vaker worden herkend. Nu heeft het Hornetsecurity Security Lab een phishing manier ontdekt dat is ontworpen om deze methode te omzeilen.

 

Het Proces

In het geval van de gedetecteerde phishing tactiek wordt de hele phishing-website als HTML-bijlage naar het slachtoffer gestuurd en vervolgens lokaal in de browser uitgevoerd. Tijdens het onderzoek naar een dergelijke phishing activiteit ontdekte het Security Lab een interessante tactiek in een van de gebruikte phishing-webformulieren. In één formulier wordt het eerste door de gebruiker ingevoerde wachtwoord altijd als foutief afgewezen en wordt alleen het tweede wachtwoord geaccepteerd.

Dit is waarschijnlijk een workaround om een methode die sommige gebruikers hebben bedacht ter voorkomen van phishing. Sommige gebruikers zijn van mening dat phishing-websites altijd elk wachtwoord accepteren. Daarom kunt u een phishing-website herkennen door een verkeerd wachtwoord in te voeren. Een phishing-website accepteert het verkeerde wachtwoord, terwijl de legitieme site het als onjuist afwijst. Deze veronderstelling is echter onjuist en het Security Lab zal in dit artikel uitleggen waarom.

 

Achtergrond

Phishing door slachtoffers de volledige HTML-bron van de phishing-webpagina als e-mailbijlage te sturen, is niet nieuw [1]. In het algemene is het zo dat het slachtoffer een e-mail ontvangt met een bijgevoegd HTML-document. 

Hier zien we een recent voorbeeld van zo’n phishing-poging gericht aan een bank:

In de e-mail wordt de gebruiker verteld dat het gebruikersprofiel moet worden bijgewerkt, anders kunnen de diensten van de bank niet meer worden gebruikt. Wanneer de gebruiker de bijlage opent, vraagt een formulier om de gegevens van de gebruiker of in dit geval een hele reeks persoonlijke en vertrouwelijke informatie:

Het document is zelfs zo behulpzaam dat het controleert (lokaal via HTML5-functies) op, of de informatie die de gebruiker heeft ingevoerd een geldig formaat heeft, het e-mailadres bijvoorbeeld een @ -symbool bevat, enz.: 

Nadat de invoer van de gebruiker lokaal was gevalideerd, wordt een HTTP POST-verzoek verzonden die de ingevoerde informatie naar een externe server stuurt:

Deze tactiek is een geweldige manier om te voorkomen dat uw phishing-website op de zwarte lijst komt te staan, aangezien er geen zichtbare phishing-webpagina online is die een hostingprovider kan verwijderen. Het blokkeren van een website omdat deze HTTP POST-verzoeken ontvangt, is moeilijk uit te leggen aan een hostingprovider of eigenaar van een gecompromitteerde website.

Onlangs vond het Security Lab een interessante nieuwe wending aan de tactiek van een langlopend manier van dergelijke HTML-phishing-bijlagen die doen alsof ze afkomstig zijn van een grote logistiek en supply-chain containerbedrijf.

 

Analyse

De phishing-activiteit waar deze interessante tactiek deel van uitmaakt, is ononderbroken maandenlang gaande – en in een andere vorm waarschijnlijk al jarenlang:

 

Het feit dat er tijdens werkdagen meer e-mails worden verzonden, zou erop wijzen dat deze activiteit op bedrijven is gericht:

Hoewel de taal van de phishing-e-mails uitsluitend Engels is, worden de e-mails voornamelijk verzonden naar Duitse, Amerikaanse en Britse bedrijven:

Toegegeven, de weergave per land is enigszins vertekend door het klantenbestand van Hornetsecurity, aangezien Hornetsecurity marktleider is in de DACH-regio.

Interessante aanvulling, de netwerken van waaruit deze e-mails worden verzonden zijn als volgt:

Met de eigenaren van de 7 AS met het hoogste aantal verzonden e-mails zijn:

VolumeASNASN owner
5450199653ARUBAFR-AS, FR
54256697BELPAK-AS BELPAK, BY
3300266772TRIMOTION S.R.L., AR
14508374PLUSNET Plus network operator in Poland, PL
137515704XTRA TELECOM S.A., ES
127554290HOSTWINDS, US
12251221ASN-TELSTRA Telstra Corporation Ltd, AU

 

Vraag de gebruiker tweemal

Hoewel de meeste van de waargenomen phishing documenten de eerder beschreven tactiek volgen – behalve dat de gebruiker alleen om een wachtwoord wordt gevraagd en het e-mailadres van de gebruiker al in het document is ingevuld – geven enkele andere phishing documenten in deze serie er een andere draai aan.

Bij het openen van het phishing document wordt de gebruiker gevraagd het wachtwoord in te voeren om zodoende een aantal verzendbewijzen te kunnen bekijken:

Ongeacht het wachtwoord dat wordt ingevoerd, krijgt de gebruiker onmiddellijk een ander wachtwoord pop-up formulier te zien waarin wordt beweerd dat het ingevoerde wachtwoord onjuist is:

Dit is waarschijnlijk gedaan om te voorkomen dat slimme gebruikers eerst een verzonnen wachtwoord proberen – om phishing te voorkomen – en ze het juiste wachtwoord pas invoeren als een vals wachtwoord ze geen toegang geeft.

Maar alleen dat laatst ingevoerde wachtwoord wordt naar de externe server gestuurd:

Last but not least wordt de gebruiker doorgestuurd naar de imagehostingservice Imgur en krijgt hij een afbeelding van verzendbewijzen te zien:

Het is duidelijk dat die afgebeelde documenten net zo nep zijn als de phishing-e-mail zelf.

 

Conclusie en Oplossing

Dit voorbeeld laat zien dat de truc die door sommige gebruikers wordt voorgesteld om bescherming te bieden tegen phishing door altijd eerst een vals wachtwoord in te voeren en pas nadat dat wachtwoord is geweigerd het juiste wachtwoord in te voeren, niet werkt. De logica achter deze truc lijkt te zijn dat de meeste phishing-formulieren elk wachtwoord accepteren. Dus als een systeem een ​​verkeerd wachtwoord weigert, moet het legitiem zijn, hoe kan het anders weten dat het wachtwoord verkeerd is. Maar zoals in dit geval is gebleken, kan een phishing-formulier ook eenvoudig uw wachtwoord weigeren. In feite kan het alle wachtwoorden weigeren en alle pogingen naar de aanvaller sturen in de hoop dat het slachtoffer alle wachtwoorden zal overhandigen terwijl hij probeert in te loggen op het nep-wachtwoordformulier.

Oplossen is niet zo eenvoudig. Omdat de phishing-webpagina lokaal in de browser van het slachtoffer wordt geladen, zullen blacklists zoals Googles Safebrowsing de gebruiker niet waarschuwen dat een phishing-webpagina wordt geopend. Een ander ding is het exfiltration mechanisme. Het enkele HTTP POST-verzoek wordt naar een waarschijnlijk gehackte WordPress-website gestuurd, waardoor het moeilijk te vinden is in een druk netwerk en omdat er geen zichtbare phishing-website online is, ook moeilijk te onderzoeken door een netwerkanalist.

De veiligste manier om u te beschermen tegen deze HTML phishing-webpagina-bijlagen is op de eerst plaats door ze niet toe te laten ​​in de mailbox van de gebruiker. Als voorbeeld, de precieze analyse mechanismen van Hornetsecurity’s Spam and Malware Protection detecteren dergelijke e-mails in de eerste filter ronde en blokkeren deze phishing-e-mails voordat ze in een mailbox kunnen worden afgeleverd.

 

Referenties