image

Valse e-mail Bol.com verspreidt ransomware

vrijdag 21 november 2014, 19:33 door Redactie, 24 reacties

Vandaag is er een valse e-mail onder Nederlandse internetgebruikers verspreid die zogenaamd van Bol.com afkomstig leek, maar in werkelijkheid ransomware bevatte, zo heeft Bol.com laten weten. De e-mail ging over een vermeende bestelling bij de webwinkel. Ontvangers van het bericht zouden meer informatie in de meegestuurde zip-bijlage kunnen vinden.

De bijlage bevat ransomware die bestanden op de computer versleutelt, zo blijkt uit berichtgeving door XGN.nl en het ANP. Verschillende mensen die de e-mail ontvingen openden die ook en raakten zo besmet. De e-mails werden verstuurd vanaf het adres klantenservice@bol.com. "Wij sturen nooit mails vanuit dat adres, mensen kunnen het daaraan herkennen. Bovendien is de bijlage een zip-bestand. Zulke bestanden versturen wij nooit", aldus een woordvoerster.

Reacties (24)
21-11-2014, 20:24 door [Account Verwijderd]
[Verwijderd]
21-11-2014, 21:25 door Anoniem
Heeft bol geen SPF?
Hadden ze dit kunnen voorkomen?
21-11-2014, 22:49 door Anoniem
Klopt ik kreeg ook een mail van Bol en in de bijlage zou vermeld staan waar het om ging.
Aangezien ik outlook 2007 gebruik is dit te lezen zonder dat ik de mail moet openen en ook nog eens een keer bestel ik nooit wat bij Bol omdat ze veel te duur zijn.
Nieuwsgierig was ik wel maar heb hem toch resoluut verwijderd ben daarna op de site van Bol wezen kijken maar niets over valse mail.
Nu ik dit zo lees ook op het AD en de Telegraaf ben ik de dans ontsprongen.
Kees.
21-11-2014, 23:48 door W. Spu
https://malwr.com/analysis/MDg4NTY1MzNhYmNiNDFlNWE5YjljMzAxMGVhYWUyZTg/
22-11-2014, 06:39 door Sledge Hammer
Door Anoniem: Heeft bol geen SPF?
Hadden ze dit kunnen voorkomen?

Ze hebben wel SPF, vraag is dus of (het spamfilter van) de ontvangende partij zijn SCL aanpast.

Probleem met SPF is dat het nooit heel breed gedragen is, idem dito hetzelfde met Sender ID. De effectiviteit staat of valt met het aantal mensen dat het correct gebruikt.
22-11-2014, 10:42 door [Account Verwijderd] - Bijgewerkt: 22-11-2014, 11:35
[Verwijderd]
22-11-2014, 11:06 door Anoniem
Ik heb even onze barracuda gescand op klantenservice@bol.com , en zij sturen wel degelijk mail vanuit dat adres als je contact opgenomen hebt met de klantenservice en is gewoon een reguliere mail echt afkomstig van Bol.com:

Received: from pro-mail-smtp-001.bol.com (pro-mail-smtp-001.bol.com [185.14.168.222]) by spam.xxxxxx.nl with ESMTP id uyyDzNz5K9BsbExT for <xxxxxxx@xxxxxx.nl>; Tue, 04 Nov 2014 16:13:50 +0100 (CET)
X-Barracuda-Envelope-From: klantenservice@bol.com
X-Barracuda-Apparent-Source-IP: 185.14.168.222
Received: from pro-mail-smtp-001.bol.com (localhost [127.0.0.1])
by pro-mail-smtp-001.bol.com (Postfix) with ESMTP id 4537A4079A
for <xxxxxxx@xxxxxx.nl>; Tue, 4 Nov 2014 16:13:50 +0100 (CET)
Received: from pro-eph-app-002.bolcom.net (pro-eph-app-002.bolcom.net [10.98.129.36])
by pro-mail-smtp-001.bol.com (Postfix) with ESMTP id 44A074076B
for <xxxxxxxxxx@xxxxxx.nl>; Tue, 4 Nov 2014 16:13:50 +0100 (CET)
Received: from pro-eph-app-002.bolcom.net (localhost.localdomain [127.0.0.1])
by pro-eph-app-002.bolcom.net (Postfix) with ESMTP id 4331E100299
for <xxxxxxxxxx@xxxxxx.nl>; Tue, 4 Nov 2014 16:13:50 +0100 (CET)
From: klantenservice@bol.com
22-11-2014, 12:03 door Anoniem
Door Sledge Hammer:
Door Anoniem: Heeft bol geen SPF?
Hadden ze dit kunnen voorkomen?

Ze hebben wel SPF, vraag is dus of (het spamfilter van) de ontvangende partij zijn SCL aanpast.

Probleem met SPF is dat het nooit heel breed gedragen is, idem dito hetzelfde met Sender ID. De effectiviteit staat of valt met het aantal mensen dat het correct gebruikt.

Tja met een ~all aan het eind gaat em dat nie worden.
Eerst maar eens die SPF ombouwen naar -all, DKIM aanzetten, en een DMARC entry maken.

Tijd voor bol.com om wakker te worden en te doen wat degenen die goed opletten al gedaan hebben!
22-11-2014, 12:36 door Erik van Straten
2014-11-21 21:25 door Anoniem: Heeft bol geen SPF?
Ah, dat doet me denken aan het jaar 2005 (het is even geleden ;) dat Microsoft claimde dat ze spam binnenkort zouden uitroeien met een technisch middel...

Inderdaad kan SPF je wel helpen om "Joe Jobs" (fake afzender) te helpen voorkomen, zie mijn artikel uit eerdergenoemd jaar https://www.security.nl/posting/10403/Waarom+SPF+en+FairUCE+op+termijn+geen+spam+bestrijden.

2014-11-21 21:25 door Anoniem: Hadden ze dit kunnen voorkomen?
Niet bol.com in hun eentje. We hebben DRINGEND, voor iedereen bruikbare, authenticated en encrypted e-mail nodig.

V.w.b. dit specifieke incident en bijbehorende malware, zie ook https://www.security.nl/posting/409347/Nu+toch+een+zip+bestand+geopend.
22-11-2014, 14:07 door Anoniem
Door Erik van Straten:
Niet bol.com in hun eentje. We hebben DRINGEND, voor iedereen bruikbare, authenticated en encrypted e-mail nodig.
Ja dat zei ik 10 jaar geleden ook al. Maar dan werd ik meteen neergesabeld met kreten over hoe goed het toch was
dat je ontraceerbaar kon mailen en dat de wereld daar zoveel beter van werd.
(vergelijkbare argumenten als je ziet rond Tor: de imaginaire verzetsstrijders die zich daardoor verborgen zouden kunnen
houden tegenover vijandige regimes enzo)

Toen ook al hadden we 1000% meer last van de misbruikers dan er profijt was van de marginale use-case, en nu niemand
meer e-mail gebruikt voor dat soort dingen zitten we nog steeds met de ellende.

Maar het e-mail systeem overzetten naar een betere opvolger van SMTP zal net zo moeilijk worden als het internet
omzetten naar IPv6. 10 jaar wachten heeft daar zeker niet bij geholpen.
22-11-2014, 14:13 door [Account Verwijderd] - Bijgewerkt: 22-11-2014, 14:17
[Verwijderd]
22-11-2014, 14:46 door Erik van Straten
2014-11-22 14:14 door Picasa3:
20141-11-22 11:06 door Anoniem: Ik heb even onze barracuda gescand op klantenservice@bol.com , en zij sturen wel degelijk mail vanuit dat adres als je contact opgenomen hebt met de klantenservice en is gewoon een reguliere mail echt afkomstig van Bol.com:

Received: from pro-mail-smtp-001.bol.com (pro-mail-smtp-001.bol.com [185.14.168.222]) by spam.xxxxxx.nl with ESMTP id uyyDzNz5K9BsbExT for <xxxxxxx@xxxxxx.nl>; Tue, 04 Nov 2014 16:13:50 +0100 (CET)
X-Barracuda-Envelope-From: klantenservice@bol.com
X-Barracuda-Apparent-Source-IP: 185.14.168.222
From: klantenservice@bol.com
Wow...misschien is er gehackt of gespoofd? Wie weet het antwoord? Erik?
Als Anoniem niet jokt is deze mail absoluut verzonden door een bol.com mailserver.

Argumentatie: het enige dat je in een e-mail kunt vertrouwen zijn IP-adressen van "afzenders" (kan een PC zijn, maar meestal gaat het om tussenliggende mailservers) in de -meestal onzichtbare- "Received: " headers die zijn toegevoegd door de mailserver(s) die jij kunt vertrouwen.

Die headers moet je van boven naar onder lezen, totdat je een een regel "Received: from <source> by <destination> tegenkomt waarbij jij <destination> nog vertrouwt maar <source> buiten jouw domein ligt. Van die regel kun je feitelijk alleen het afzender IP-adres van <source> vertrouwen (spammers manipuleren de rest van <source> meestal zoveel mogelijk om verwarring te zaaien).

Je moet niet op <source> hostnames vertouwen: een daarvan "roept" de afzendende server zelf, en niet zelden is dat iets stompzinnigs als localhost.localdomain. De andere hostname is afkomstig van een reverse DNS lookup van 185.14.168.222, uitgevoerd door de ontvangende mailserver (Barracuda in dit geval). Reverse DNS is vaak niet geïmplementeerd. En indien wel, vaak verouderd, nietszeggend of verwarrend. Niet op vertrouwen dus.

In dit geval is de Barracuda-based mail server van Anoniem (door haar/hem hernoemd in "spam.xxxxxx.nl") de enige vertrouwde (ervan uitgaande dat Anomiem te vertrouwen is). Alle overige headers, en de inhoud van de mail zelf, kunnen door een spammer zijn toegevoegd en/of volledig zijn gemanipuleerd.

Als je zeker weet dat die mailserver altijd X-Barracuda-Envelope-From en X-Barracuda-Apparent-Source-IP: headers toevoegt, en altijd eventueel door een afzender toegevoegde identieke headers (met mogelijk vervalste gegevens) overschrijft, kun je ook die headers vertrouwen.

Aangezien een "whois" van 185.14.168.222 daarwerkelijk oplevert dat dit IP adres aan bol.com toebehoort, weet je zo goed als zeker dat bol.com deze mail wel verzonden moet hebben.

Echter, ik vermoed dat het hier niet om de headers van een ransomware mail gaat, maar dat het gaat om de headers van een reguliere en legitieme (niet gespoofte) mail van de Bol.com klantenservice. Vermoedelijk wilde Anoniem aangeven hoe die eruit zien.

Mocht het hier toch om de headers van een ransomware mail gaan, dan heeft Bol.com wel wat uit te leggen...
22-11-2014, 17:24 door Anoniem
Door Erik van Straten:
2014-11-22 14:14 door Picasa3:
20141-11-22 11:06 door Anoniem: Ik heb even onze barracuda gescand op klantenservice@bol.com , en zij sturen wel degelijk mail vanuit dat adres als je contact opgenomen hebt met de klantenservice en is gewoon een reguliere mail echt afkomstig van Bol.com:

Received: from pro-mail-smtp-001.bol.com (pro-mail-smtp-001.bol.com [185.14.168.222]) by spam.xxxxxx.nl with ESMTP id uyyDzNz5K9BsbExT for <xxxxxxx@xxxxxx.nl>; Tue, 04 Nov 2014 16:13:50 +0100 (CET)
X-Barracuda-Envelope-From: klantenservice@bol.com
X-Barracuda-Apparent-Source-IP: 185.14.168.222
From: klantenservice@bol.com
Wow...misschien is er gehackt of gespoofd? Wie weet het antwoord? Erik?

Als Anoniem niet jokt

<knip>

Vermoedelijk wilde Anoniem aangeven hoe die eruit zien.


"De e-mails werden verstuurd vanaf het adres klantenservice@bol.com. "Wij sturen nooit mails vanuit dat adres, mensen kunnen het daaraan herkennen."
22-11-2014, 22:04 door Anoniem
Het bericht met de headers wat getoond werd is een bericht van 4 November, de ransomware is van 21 november => het waren voorbeeld headers.
Als iemand eens de headers van een bericht zou posten met de ransomware van gisteren met deze headers dan is het een ander verhaal.
Tot die tijd is het helemaal niet bewezen dat er een systeem of mailserver open is bij Bol.com..
23-11-2014, 04:26 door Erik van Straten - Bijgewerkt: 23-11-2014, 05:29
2014-11-22 22:04 door Anoniem: Het bericht met de headers wat getoond werd is een bericht van 4 November, de ransomware is van 21 november => het waren voorbeeld headers.
Zo, val ik even door de mand... Zwak excuus natuurlijk, ik had een afspraak en wilde de vraag van Picasa3 nog even snel beantwoorden. In mijn enthousiasme om uit te leggen dat slechts één header relevante informatie bevat over de (mogelijke) bron van een e-mail, ben ik eraan voorbij gegaan dat die header, naast een <source> IP-adres, een tweede heel belangrijk item bevat: de datum en tijd van ontvangst. D.w.z. waarop die laatste mailserver (d.w.z. headers in "chronologische" volgorde, van onder naar boven) de mail vanaf dat IP-adres ontvangen heeft. Sterker, in dit geval heb ik geheel niet opgemerkt dat deze mail al op 4 nov. verzonden was. Slordig van mij, sorry daarvoor! Haastige spoed...

2014-11-22 22:04 door Anoniem: Als iemand eens de headers van een bericht zou posten met de ransomware van gisteren met deze headers dan is het een ander verhaal.
Die zou ik ook wel eens willen zien. De volgende zaken zijn interessant:

(1) Hebben uitsluitend bol.com klanten deze ransomware mails ontvangen? Zo ja dan zou dat een sterke aanwijzing zijn dat de aanvallers toegang hebben gehad tot de klantendatabase van bol.com;

(2) Volgens Sledge Hammer (2014-11-22 06:39) heeft bol.com SPF informatie opgenomen in DNS. Interessant is wat Anoniem (2014-11-22 12:03) opmerkt: "Tja met een ~all aan het eind gaat em dat nie worden.".

Even zelf checken (achter > staan steeds de commando's die ik invoerde en ik heb een deel van de output weggelaten). Eerst de "authoritative name server" van bol.com vaststellen:

C:\>nslookup -debug
[...]
> bol.com
[...]
     primary name server = pro-dns-auth-001.bol.com
[...]
> exit

Dan, zonder al die debug output, SPF records opzoeken (met een aantal te lange regels handmatig "omgeklapt"):

C:\>nslookup -querytpe=txt bol.com pro-dns-auth-001.bol.com
Server: pro-dns-auth-001.bol.com
Address: 185.14.168.221

bol.com text = "v=spf1 mx a:mail.bol.com a:pro-mail-smtp-001.bol.com
  a:pro-mail-smtp-002.bol.com  a:phoenix.kiala.com include:outlook.com
  ip4:62.197.141.0/24 ip4:171.33.133.57/29 ip4:185.14.168.192/27
  ip4:185.14.169.192/27 ~all"
bol.com text = "MS=ms69858635"
bol.com text = "yI4CjFremeRILZz0hq69qQ+Peif++nUh+rUcU+2rI5whLjvSEB
  wa0uVrIXHve5DaiZNR4IJCmg9HoOaL8G7vEQ=="
bol.com nameserver = pro-dns-auth-002.bol.com
bol.com nameserver = pro-dns-auth-001.bol.com
pro-dns-auth-001.bol.com        internet address = 185.14.168.221
pro-dns-auth-002.bol.com        internet address = 185.14.169.221
> exit

Inderdaad eindigt de eerste "bol.com text = " regel op ~all. Goede uitleg daarover, maar een m.i. verkeerd advies, lees je in https://wordtothewise.com/2014/06/authenticating-spf/. In het kort: "~all" betekent "softfail". Met andere woorden: deze SPF records zijn redelijk zinloos. Een spamfilter op een ontvangende mailserver zou bij een "softfail" (d.w.z. mail is verzonden vanaf een niet door bol.com geautoriseerd IP-adres) strafpunten kunnen geven, maar of je daar een substantieel deel van deze scams mee tegenhoudt, is de vraag.

(3) Ik heb geen idee welk percentage Nederlanders mail ontvangt via een mailserver die grondig checkt op SPF, dus ook al had bol.com SPF effectief geïmplementeerd, is het de vraag welk percentage ontvangers die scams niet had ontvangen als die vanaf zombie-PC's (opgenomen in een botnet) waren verzonden. Stel dat dit percentage groot is, en dat de scammers dit weten. Dan zou het kunnen dat de scammers toegang hebben gezocht en gevonden tot een van de IP-adressen uit de reeksen genoemd in het DNS SPF record, dus 62.197.141.0/24, 171.33.133.57/29, 185.14.168.192/27 en 185.14.169.192/27 (waarbij 171.33.133.57/29 duidelijk een typfout bevat, ik heb geen idee van het effect daarvan).

2014-11-22 22:04 door Anoniem: Tot die tijd is het helemaal niet bewezen dat er een systeem of mailserver open is bij Bol.com..
Inderdaad. Ik gok dat de scammers geen toegang hebben gehad tot een, via SPF geautoriseerde, zendende "bol.com" mailserver. Maar ik kan ook niet uitsluiten dat ICT infrastructuur van bol.com gecompromitteerd is, de scammers de klantendatabase hebben kunnen benaderen, en deze scams vanuit het bol.com domein zelf hebben verzonden.

2014-11-22 17:24 door Anoniem: "De e-mails werden verstuurd vanaf het adres klantenservice@bol.com. "Wij sturen nooit mails vanuit dat adres, mensen kunnen het daaraan herkennen."
Daarbij quote Anoniem het artikel:
vrijdag 21 november 2014, 19:33 door Redactie: De e-mails werden verstuurd vanaf het adres klantenservice@bol.com. "Wij sturen nooit mails vanuit dat adres [...] aldus een woordvoerster.
Als de headers gepost door Anoniem op 2014-11-22 11:06 kloppen, is die woordvoerster op zijn minst "onjuist geïnformeerd". Stom, maar kan gebeuren. Dit zal ertoe leiden dat de paar mensen die dit onthouden, legitieme mails ongelezen in de ronde archiefkast opslaan.

Aan de andere kant, Google: "Wij sturen nooit mails vanuit dat adres, mensen kunnen het daaraan herkennen." (inclusief die dubbele aanhalingstekens) levert nogal wat hits op, dus heel wat mensen zullen dit gelezen hebben...

vrijdag 21 november 2014, 19:33 door Redactie: De e-mails werden verstuurd vanaf het adres klantenservice@bol.com. "Wij sturen nooit mails vanuit dat adres, mensen kunnen het daaraan herkennen [...] aldus een woordvoerster.
En dat is een Postenelletje (zie tweede helft van https://www.security.nl/posting/405715/PostNL+waarschuwt+klanten+voor+besmette+e-mails#posting405821): "als onze e-mail eruit ziet als A hebben wij hem wel verzonden, maar als hij eruit ziet als B dan is het nep"! En dat is nou precies een opmerking waar scammers een lekker warm gevoel bij krijgen...
23-11-2014, 16:47 door [Account Verwijderd] - Bijgewerkt: 23-11-2014, 16:53
[Verwijderd]
23-11-2014, 19:31 door Anoniem
Door Picasa3: Wat ik wel opvallend vind, is het feit dat een scanner zoals Comodo Antivirus (gratis pakket) - en zoals het er nu uitziet - pas na 2 dagen de detectie op orde had. Dit is duidelijk geen aanrader voor wie Windows gebruikt. Dan kan je beter Avira of een andere scanner gebruiken die veel sneller deze malware konden ontdekken.

+1 voor avira.
heb betaalde bitdefender en die vond ook bepaalde malware niet zo snel als avira, maar goed => andere discussie wellicht.
Voor de persoon die iemand weet te traceren met een ransomware mail en de headers weet te vinden kan ons vertellen waarvan deze verstuurd is en of er inbraak is geweest of niet.
Daarnaast kunnen bol.com email adressen ook rond slingeren dmv geharveste email adressen en hoeft een doel bewuste mail actie er niet op te wijzen dat Bol.com gehackt is...
Meten is weten ofwel: onderzoek doen en dan pas conclusies trekken ;)
23-11-2014, 20:08 door Erik van Straten - Bijgewerkt: 23-11-2014, 20:11
Door Picasa3: Wat ik wel opvallend vind, is het feit dat een scanner zoals Comodo Antivirus (gratis pakket) - en zoals het er nu uitziet - pas na 2 dagen de detectie op orde had. Dit is duidelijk geen aanrader voor wie Windows gebruikt. Dan kan je beter Avira of een andere scanner gebruiken die veel sneller deze malware konden ontdekken.
@Picasa3: dat kan bij het eerstvolgende malware incident weer helemaal anders zijn. Sowieso moet je rekening houden met de klantendoelgroep van de AV-boeren: commerciële klanten werken zelf ook niet zoveel in het weekend (de bezetting van malware analisten is dan vaak ook lager) en bovendien maken commerciële klanten zelden gebruik van bol.com.

Ook is het goed je te realiseren dat er niet zoiets bestaat als een "gratis virusscanner". Het hebben van 24x7 team(s) die malware analyseren, de voortdurende kan-en-muis ontwikkeling van bijbehorende tools, het zo klein mogelijk houden van defintie-updates, het voortdurende testen om false-positives zoveel mogelijk te voorkomen (dat gaat niet altijd goed, zie bijv. http://tweakers.net/nieuws/99833/windows-81-update-zorgt-voor-problemen-als-avast-is-geinstalleerd.html), en -last but not least- het beschikken over een distributienetwerk om definities en engine-updates ASAP op eindcomputers beschikbaar te hebben, kan natuurlijk niet gratis.

Aangezien AV-boeren geen stichtingen zijn, maar zelf commerciële bedrijven zijn, moet daar een business case achter zitten. Voor de hand ligt het om jouw computer als sensor en beta-test-device te gebruiken. Het zou kunnen dat elk verdacht, of zelfs "onbekend" (hash nooit eerder geregistreerd) bestand, wordt geüpload naar de AV-boer. Zonder dat je dit weet. En vaak niet via https, maar via http (om de kosten te drukken). En, voordat engine- en gloednieuwe definitie-updates naar de goed betalende klanten worden gepushed, mag jij ze eerst uittesten. Geheel gratis!

Commerciële klanten houden daar niet zo van. Via een SLA (Service Level Agreement) met de AV-boer kunnen zij dergelijk geneus uitsluiten (vanwege de bijbehorende risico's). Om toch over een wijd-verspreid test- en sensornetwerk te beschikken hoef jij niet te betalen voor sommige antivirus pakketten.

Nb. ik heb https://www.security.nl/posting/409347/Nu+toch+een+zip+bestand+geopend#posting409446 geüpdated n.a.v. de laatste update van de Virustotal pagina. Opvallend is dat een aantal scanners al enkele dagen geen updates heeft ontvangen (Bkav en Zoner draaien nog met definities van 20141120). Logisch dat zij deze malware niet detecteren.

Het beoordelen van virusscanners op basis van Virustotal resultaten is discutabel; met name AV-boeren roepen dit om het hardst, maar m.i. zegt VT toch wel iets over de kwaliteit. Het is absoluut zo dat "runtime" detectie je kan redden, iets wat de commandline scanners op VT niet voor je doen. Maar die runtime detectie is wel net zoiets als in de spits de A4 overwandelen en hopen dat Rijkswaterstaat bijtijds de rode kruizen aanzet (en chauffeurs dat zien terwijl ze zitten appen). Anderzijds testen de commandline-scanners vaak veel grondiger dan "on-access" scanners, die vaak flinke beperkingen kennen qua scantijd (anders klagen gebruikers dat bestanden openen veel te lang duurt). Om die reden denk ik dat het beeld dat VT geeft, zo gek nog niet is - als je maar niet op 1 malware exemplaar focust.

De updates die ik geef in https://www.security.nl/posting/409347/Nu+toch+een+zip+bestand+geopend#posting409446 moet je dan ook niet gebruiken om de keuze voor een virusscanner op te baseren, hooguit kun je er enkele uitsluiten. Zo kun je, als privégebruiker, m.i. beter geen virusscanner kiezen die in het weekend nooit updates ontvangt. En denk ook na of je een lekkend proefkonijn wilt zijn door gebruik te maken van een gratis virusscanners (nog even los van de stroom advertenties die je soms om je oren geslingerd krijgt).
23-11-2014, 21:45 door W. Spu - Bijgewerkt: 23-11-2014, 22:14
Hierbij de header en de body van een mail die we afgelopen vrijdag hebben ontvangen. Ik heb de informatie in de header van de mail vervangen voor bekende servers. In de body van de mail heb ik 'http' vervangen door 'hxxp' en 'script' door 'scribt'. Ben trouwens wel benieuwd wat die javascript code doet onderaan de mailbody.


--------------------------------------------------HEADER--------------------------------------------------

Received: from x.x.nl (xxx.xxx.xxx.xxx) by x.x.nl
(xxx.xxx.xxx.xxx) with Microsoft SMTP Server (TLS) id xx.x.xxx.x; Fri, 21 Nov
2014 12:26:16 +0100
Received: from x.x.nl (xxx.xxx.xxx.xxx) by x.x.nl
(xxx.xxx.xxx.xxx) with Microsoft SMTP Server (TLS) id xx.x.xxx.xx; Fri, 21 Nov
2014 12:26:15 +0100
Received: from x.x.nl (xxx.xxx.xxx.xxx) by x.x.nl
(xxx.xxx.xxx.xxx) with Microsoft SMTP Server (TLS) id xx.x.xxx.x via Frontend
Transport; Fri, 21 Nov 2014 12:26:15 +0100
Received: from x.x.x.x.com (xxx.xxx.xxx.xxx)
by x.x.nl (xxx.xxx.xxx.xxx) with Microsoft SMTP Server (TLS) id
xx.x.xxx.x; Fri, 21 Nov 2014 12:26:06 +0100
Received: from x.x.gbl (xxx.xxx.xxx.xxx) by
x.x.gbl (xxx.xxx.xxx.xxx) with Microsoft SMTP Server
(TLS) id xx.x.x.xx; Fri, 21 Nov 2014 11:26:04 +0000
Received: from vded-gi-001.servers.wirehive.net (134.0.20.98) by
x.x.x.x.com (xxx.xxx.xxx.xxx) with Microsoft SMTP
Server id xx.x.x.xx via Frontend Transport; Fri, 21 Nov 2014 11:26:04 +0000
Received: by vded-gi-001.servers.wirehive.net (Postfix, from userid 1001) id
CEB9D211A6; Fri, 21 Nov 2014 11:26:02 +0000 (GMT)
Date: Fri, 21 Nov 2014 11:26:02 +0000
To: <anynymous@org.nl>
From: =?UTF-8?Q?Erik_Jonkers?= <klantenservice@bol.com>
Subject: =?UTF-8?Q?Uw_bestelling_met_bestelnummer_=31=34=35=32=34=33=35=32=32=37=36=30_wordt_verzonden?=
Message-ID: <18cdb7c15546eb9655dd1e18b23d2747@gigibrooks.com>
X-Priority: 3
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="b1_18cdb7c15546eb9655dd1e18b23d2747"
Return-Path: gigi@vded-gi-001.servers.wirehive.net
X-EOPAttributedMessage: 0
Received-SPF: None (x.x.com: vded-gi-001.servers.wirehive.net
does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is 134.0.20.98)
smtp.mailfrom=gigi@vded-gi-001.servers.wirehive.net;
X-Forefront-Antispam-Report: CIP:134.0.20.98;CTRY:GB;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(6039001)(428002)(189002)(199003)(15975445006)(46386002)(110136001)(120916001)(19617315012)(92566001)(180100001)(36756003)(86372001)(4396001)(84326002)(31966008)(45336002)(512954002)(44976005)(568964001)(19580395003)(104016003)(107886001)(87836001)(52956003)(33646002)(71186001)(2351001)(107046002)(229853001)(18206015028)(21056001)(587044001)(108616004)(15188445003)(16601075003)(8558605004)(99396003)(15202345003)(980100001)(46102003)(95666004)(105586002)(101416001)(81686999)(62966003)(54356999)(64706001)(106466001)(20776003)(103686003)(50986999)(77156002)(549064007)(102836001)(450100001)(42186005)(77096003)(15519875005)(7059030)(24736002)(14776006)(90966001)(587134003);DIR:INB;SFP:;SCL:1;SRVR:DB3FFO11HUB088;H:vded-gi-001.servers.wirehive.net;FPR:;MLV:nov;PTR:vded-gi-001.servers.wirehive.net;MX:1;A:1;LANG:nl;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3FFO11HUB088;
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(1)(2);SRVR:DB3FFO11HUB088;
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3FFO11HUB088;
X-MS-Exchange-Organization-AuthSource: x.x.nl
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 10
X-MS-Exchange-Organization-Antispam-Report: MessageSecurityAntispamBypass
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0
X-MS-Exchange-Organization-Antispam-Report: MessageSecurityAntispamBypass

--------------------------------------------------HEADER--------------------------------------------------

----------------------------------------------------BODY-----------------------------------------------------

<!DOCTYPE html><html>
<head>
</head>
<body>

<font face="verdana">
<img src="hxxp://i.imgur.com/hSnKd66.jpg" border="0" width="750" height="185">
<p>Goedemiddag,</p>
Bedankt voor uw bestelling bij bol.com. Hierbij ontvangt u per bijlage de orderbevestiging van uw<br>
bestelling met ordernummer <b>145243522760.</b> <br>
<br>
Uw bestelling zal na verwerking in ons magazijn, worden aangeboden bij PostNL. Hierbij de<br>
Track &amp; Trace gegevens zodat u inzicht heeft in de status van uw zending.<br>
<br>
<b>N.B.: De link wordt doorgaans pas actief, vanaf 08:00u de volgende ochtend!</b>
<br>
<a href="hxxps://mijnpakket.postnl.nl/Claim?Barcode=3SXYZM1531286&amp;Postalcode=1033SE">hxxps://mijnpakket.postnl.nl/Claim?Barcode=3SXYZM1531286&amp;Postalcode=1033SE<a>
<br>
<br>
Heeft u nog vragen of opmerkingen? Stuur ons dan een bericht via bol.com<br>
<a href="hxxps://www.bol.com/nl/klantenservice/index.html">Klantenservice</a>
<br>
<br>
Met vriendelijke groet,<br>
<br>
bol.com<br>
<a href="hxxp://www.bol.com/nl/index.html">hxxp://www.bol.com</a>
<br>
<br>
<br>


<p align="left">
<img src="hxxps://www.chatbots.org/images/c/100/virtual_agent_billie_live_presence____3692.gif" align="left" style=""><b>Heeft u een vraag? </b><br>
Bekijk de <a href="hxxps://www.bol.com/nl/klantenservice/index.html">klantenservicepagina</a>. Hier vindt u veel informatie en kunt u<br>
hulp vragen aan Billie, onze virtuele assistent.<br>
</p>

<td align="center">
<img src="hxxp://i.imgur.com/4XkzkA9.gif" border="0" width="415">


<tr>
<td align="center">
<table cellspacing="0" cellpadding="2" width="600" border="0">

<tr>
<td align="center"><strong><font size="2">Kom naar bol.com voor:</font></strong></td>
</tr>


<td align="center">
<font size="2">
<a href="hxxp://www.bol.com/nl/boeken/nederlandse-boeken/index.html">Boeken</a>
<a href="hxxp://www.bol.com/nl/muziek/index.html">Muziek</a>
<a href="hxxp://www.bol.com/nl/dvd/index.html">DVD</a>
<a href="hxxp://www.bol.com/nl/games/index.html">Games</a>
<a href="hxxp://www.bol.com/nl/speelgoed/index.html">Speelgoed</a>
<a href="hxxp://www.bol.com/nl/baby/index.html">Baby</a>
<a href="hxxp://www.bol.com/nl/wonen/index.html">Wonen</a>
<a href="hxxp://www.bol.com/nl/koken-tafelen/index.html">Koken &amp; tafelen</a>
<a href="hxxp://www.bol.com/nl/m/elektronica/persoonlijke-verzorging/N/10823/index.html">Mooi &amp; gezond</a>
<a href="hxxp://www.bol.com/nl/m/horloges/dameshorloges-horlogeaccessoires/N/16784&#43;17257/index.html?promo=dames-sieraden_306_navblok-dames-sieraden_B2_horloges_1&amp;alwaysShowPageTitle=1">Sieraden &amp; Horloges</a>
<a href="hxxp://www.bol.com/nl/m/sport-vrije-tijd/sportkleding-heren/index.html">Sport &amp; Vrije tijd</a>
<a href="hxxp://www.bol.com/nl/computer/index.html">Elektronica</a>
<a href="hxxp://www.bol.com/nl/m/computer/laptops/N/4770/index.html">Computer</a>
<a href="hxxp://www.bol.com/nl/m/tuin/tuingereedschap/N/13061/index.html">Tuin</a>
<a href="hxxp://www.bol.com/nl/klussen/index.html?promo=Klussen_307__B1_Homepage_1_">Klussen</a>
<a href="hxxp://www.bol.com/nl/m/dier/honden/N/12749/index.html?promo=Honden_307__B1_Hondenhomepagina_1_">Dier</a>
<a href="hxxp://www.bol.com/nl/m/elektronica/digitale-fotografie/N/4006/index.html">Fotoservice</a>
</font>
<br>
<br>


<font size="2">
<font color="#666666">
Disclaimer<br>
Dit is een automatisch gegenereerde e-mail. Wij kunnen een reply op deze e-mail niet beantwoorden.
</font>
</font>


<scribt type="text/javascribt">window.NREUM||(NREUM={});NREUM.info={"beacon":"beacon-6.newrelic.com","licenseKey":"52a5d7cf3b","applicationID":"3296388","transactionName":"MgFTZ0cEXEBZVEwNDAtLZEFcSkVcSlNIFgYWFx5ERUhRXFZDXQoXShBZVlgAQRwSGEgMEwgFWF9QFwAdSF9I","queueTime":0,"applicationTime":11,"ttGuid":"","agentToken":"","atts":"HkZQEQ8eT04=","errorBeacon":"bam.nr-data.net","agent":"js-agent.newrelic.com/nr-476.min.js"}</scribt><scribt type="text/javascribt">window.NREUM||(NREUM={});NREUM.info={"beacon":"beacon-6.newrelic.com","licenseKey":"52a5d7cf3b","applicationID":"3296388","transactionName":"MgFTZ0cEXEBZVEwNDAtLZEFcSkVcSlNIFgYWFx5ERUhRXFZDXQoXShBZVlgAQRwSGEgMEwgFWF9QFwAdSF9I","queueTime":0,"applicationTime":5,"ttGuid":"","agentToken":"","atts":"HkZQEQ8eT04=","errorBeacon":"bam.nr-data.net","agent":"js-agent.newrelic.com/nr-476.min.js"}</scribt><scribt type="text/javascribt">window.NREUM||(NREUM={});NREUM.info={"beacon":"beacon-6.newrelic.com","licenseKey":"52a5d7cf3b","applicationID":"3296388","transactionName":"MgFTZ0cEXEBZVEwNDAtLZEFcSkVcSlNIFgYWFx5ERUhRXFZDXQoXShBZVlgAQRwSGEgMEwgFWF9QFwAdSF9I","queueTime":0,"applicationTime":5,"ttGuid":"","agentToken":"","atts":"HkZQEQ8eT04=","errorBeacon":"bam.nr-data.net","agent":"js-agent.newrelic.com/nr-476.min.js"}</scribt><scribt type="text/javascribt">window.NREUM||(NREUM={});NREUM.info={"beacon":"beacon-6.newrelic.com","licenseKey":"52a5d7cf3b","applicationID":"3296388","transactionName":"MgFTZ0cEXEBZVEwNDAtLZEFcSkVcSlNIFgYWFx5ERUhRXFZDXQoXShBZVlgAQRwSGEgMEwgFWF9QFwAdSF9I","queueTime":0,"applicationTime":5,"ttGuid":"","agentToken":"","atts":"HkZQEQ8eT04=","errorBeacon":"bam.nr-data.net","agent":"js-agent.newrelic.com/nr-476.min.js"}</scribt><scribt type="text/javascribt">window.NREUM||(NREUM={});NREUM.info={"beacon":"beacon-6.newrelic.com","licenseKey":"52a5d7cf3b","applicationID":"3296388","transactionName":"MgFTZ0cEXEBZVEwNDAtLZEFcSkVcSlNIFgYWFx5ERUhRXFZDXQoXShBZVlgAQRwSGEgMEwgFWF9QFwAdSF9I","queueTime":0,"applicationTime":6,"ttGuid":"","agentToken":"","atts":"HkZQEQ8eT04=","errorBeacon":"bam.nr-data.net","agent":"js-agent.newrelic.com/nr-476.min.js"}</scribt><scribt type="text/javascribt">window.NREUM||(NREUM={});NREUM.info={"beacon":"beacon-6.newrelic.com","licenseKey":"52a5d7cf3b","applicationID":"3296388","transactionName":"MgFTZ0cEXEBZVEwNDAtLZEFcSkVcSlNIFgYWFx5ERUhRXFZDXQoXShBZVlgAQRwSGEgMEwgFWF9QFwAdSF9I","queueTime":0,"applicationTime":84,"ttGuid":"","agentToken":"","atts":"HkZQEQ8eT04=","errorBeacon":"bam.nr-data.net","agent":"js-agent.newrelic.com/nr-476.min.js"}</scribt></body>
</html>
----------------------------------------------------BODY-----------------------------------------------------

24-11-2014, 00:51 door Erik van Straten
2014-11-23 21:45 door W. Spu: Hierbij de header en de body van een mail die we afgelopen vrijdag hebben ontvangen.

Hartelijk dank! Hier valt veel uit te halen.

Links in de e-mail

Ik zie, op het eerste gezicht, geen echt kwaadaardige links in de e-mail:

http://i.imgur.com/hSnKd66.jpg en http://i.imgur.com/4XkzkA9.gif zijn kopiën van een "bol.com" plaatjes, dit om de mail legitiem over te laten komen.

De PostNL pagina is absoluut niet kwaadaardig: https://mijnpakket.postnl.nl/Claim?Barcode=3SXYZM1531286&Postalcode=1033SE.

Vermoedelijk enigszins kwaadaardig is hxxps://www.chatbots.org/images/c/100/virtual_agent_billie_live_presence____nnnn.gif: dat nummer zou wel eens uniek kunnen zijn per verzonden mail, en dus gekoppeld aan het e-mail adres van de ontvanger. Als de mail client (ook wel MUA, mail User Agent), dat plaatje laadt, weet die site dat de spam gelezen wordt door het bijbehorende e-mail adres.

De Javascript onderaan de mail: de meeste MUA's voeren geen Javascript uit. Mocht dat toch gebeuren (sommige webmail clients zouden dat kunnen doen): de 5 regels lijken op het eerste gezicht identiek maar zijn dat niet, de verschillen zijn:
"applicationTime":11
"applicationTime":5
"applicationTime":5
"applicationTime":5
"applicationTime":6

http://js-agent.newrelic.com/nr-476.min.js bevat flink wat Javascript (niet obfuscated) dat ik zo snel niet kan analyseren, maar het ziet er niet erg bedreigend uit. In https://discuss.newrelic.com/t/js-agent-404-not-found/9113 zie je dezelfde URL genoemd worden. Newrelic.com kan, middels "NREUM", kennelijk webbrowser performance meten (zie https://docs.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/new-relic-cookies). Als de scammers zo'n licentie hebben, kunnen ze daarmee mogelijk ook monitoren wie hun spams leest (en met welke browser/MUA etcetera). Dat zou dan ook een spoor naar de scammers kunnen bevatten.

Wat ook heel goed kan is dat de scammers een legitieme mail van bol.com hebben gebruikt waar deze Javascript al in zat.

In mijn onderzoek naar de postnl scams zag ik dat, notabene in een redirect pagina van postnl.nl zelf, Javascipt zit die begint met (ik heb de regels omgeklapt en wat ingesprongen voor de leesbaarheid):
<html><head>
<script type="text/javascript">
  window.NREUM||(NREUM={});
  NREUM.info = {
    "beacon":"beacon-2.newrelic.com",
    "errorBeacon":"bam.nr-data.net",
    "licenseKey":"b877c8dd2e",
    "applicationID":"3535314",
    "transactionName":"bgBWMhZUWhZUVkMPWFdKcAkQe1ERdlpZEkVWCVgDFhpkBFJQGDZWXgA=",
    "queueTime":0,
    "applicationTime":2,
    "ttGuid":"A202EC6917CD663B",
    "agent":"js-agent.newrelic.com/nr-476.min.js"
 }
</script>
Kortom, dit lijkt mij niet kwaadaardig in de zin van malware, wel kan er sprake zijn van monitoring.

Verzendende mail-server

Dan de afzende mailserver, "sender IP is 134.0.20.98": dat is een server bij ISP "WireHive" in GB. De scammers hebben of daar een server gehuurd, of een server gehacked. Ik sluit niet uit dat de scammers toegang hadden tot een andere server dan 134.0.20.98. Er zijn echter geen aanvullende mailheaders te zien, maar deze zouden kunnen worden onderdrukt door de mailserver met adres 134.0.20.98 (om interne machines bij die ISP te beschermen). Maar ik sluit ook niet uit dat de scammers directe toegang hadden tot die server (134.0.20.98) zelf.

Duidelijk is in elk geval dat deze spam niet via de servers van bol.com is verzonden!

SPF had niet kunnen helpen

Overigens, uit:

  Return-Path: gigi@vded-gi-001.servers.wirehive.net

  Received-SPF: None (x.x.com: vded-gi-001.servers.wirehive.net
    does not designate permitted sender hosts)
  Authentication-Results: spf=none (sender IP is 134.0.20.98)
    smtp.mailfrom=gigi@vded-gi-001.servers.wirehive.net;

blijkt wel waarom SPF niet helpt tegen spam (zoals ik 9 jaar geleden al schreef): de scammers hebben als "Envelope-From" opgegeven: gigi@vded-gi-001.servers.wirehive.net

Het enige dat je (als bol.com zijnde) met SPF kunt bereiken (als ze het goed zouden configureren), is dat scammers, die in Envelope-From een bol.com email adres gebruiken, tegen de lamp lopen als de ontvangende mailserver op SPF records checkt. Maar dat hoeven de scammers duidelijk niet te doen.

Concreet, aangezien er totaal geen relatie hoeft te zijn tussen het -niet in mail clients getoonde- Envelope-From (ook bekend als return-adres) en het -wel in mail clients getoonde- Message-From: veld hoeft te bestaan, kan SPF je niet tegen dit soort scams beschermen.
25-11-2014, 12:25 door Briolet
Erik: Mooie analyse die je daar maakt. Mij valt op dat in de PostNL link, de postcode zichtbaar voor de gebruiker is. Als dat niet je eigen postcode is, wordt het geheel ook iets verdacht. Dan ga ik me afvragen of daar niet de echte postcode van de ontvanger van de mail stond. Zo ja, moet dat betekenen dat ze niet alleen zijn e-mail adres hadden, maar waarschijnlijk zijn gehele adresgegevens. Maar dat kan alleen de ontvanger van die mail beantwoorden.

Betreffende het SFP record: De term was nieuw voor mij, maar ik kreeg vandaag een mailtje van Vitens in mijn spambox. Vitens stuurt het naar mijn 80-jarige vader op zijn Ziggo account en dat account is ingesteld om alle zijn mail naar mijn postbus te forwarden. (Omdat hij niets met e-mail doet)
In de header geeft zowel Ziggo als dataweb de mail een lage spamscore, maar dan volgt op het einde:

Received-Spf: fail (dataweb.nl: domain of noreply@vitens.nl does not designate 212.54.42.165 as permitted sender)

Mijn mailprovider controleert dus wel het SPF record en ziet dat Ziggo geen geldige afzender van de Vitens.nl mail is. Zie ik dat goed?
Maar omdat dit een regulier geforwarde mail is, keert hier de SFP controle zich tegen je.
25-11-2014, 17:40 door Erik van Straten - Bijgewerkt: 25-11-2014, 17:45
2014-11-25 12:25 door Briolet: Erik: Mooie analyse die je daar maakt. Mij valt op dat in de PostNL link, de postcode zichtbaar voor de gebruiker is. Als dat niet je eigen postcode is, wordt het geheel ook iets verdacht. Dan ga ik me afvragen of daar niet de echte postcode van de ontvanger van de mail stond.
Dat verwacht ik niet. Zelf zou ik hier ook best in kunnen trappen; ik ben begin dit jaar verhuisd en heb al 2x post bestemd voor de vorige bewoners (en 1x voor de buren) per ongeluk opengemaakt (een ezel...).

En iemand die de PostNL URL bekijkt (of webpagina opent) en de postcode ziet, denkt misschien: potverdikkie, pakje voor een ander, wordt elders afgeleverd, maar de rekening sturen ze naar mij!? Des te meer reden om de bijlage te openen...

2014-11-25 12:25 door Briolet: Betreffende het SFP record: De term was nieuw voor mij, maar ik kreeg vandaag een mailtje van Vitens in mijn spambox. Vitens stuurt het naar mijn 80-jarige vader op zijn Ziggo account en dat account is ingesteld om alle zijn mail naar mijn postbus te forwarden. (Omdat hij niets met e-mail doet)
In de header geeft zowel Ziggo als dataweb de mail een lage spamscore, maar dan volgt op het einde:

Received-Spf: fail (dataweb.nl: domain of noreply@vitens.nl does not designate 212.54.42.165 as permitted sender)

Mijn mailprovider controleert dus wel het SPF record en ziet dat Ziggo geen geldige afzender van de Vitens.nl mail is. Zie ik dat goed?
Maar omdat dit een regulier geforwarde mail is, keert hier de SFP controle zich tegen je.
Exact. Het IP-adres 212.54.42.165 valt niet onder de door Vitens geautoriseerde IP-reeksen die in Envelope-From: gebruik mogen maken van een @vitens.nl e-mail adres als afzender.

Uit mijn artikel uit 2005 (ik was het zelf bijna vergeten), https://www.security.nl/posting/10403/Waarom+SPF+en+FairUCE+op+termijn+geen+spam+bestrijden, m.b.t. SPF en FairUCE (onbekend gebleven):
Beide mechanismes maken forwarding nagenoeg onmogelijk. Als je bijv. van provider wisselt, en je nieuwe provider checkt SPF records, zal een email die afkomstig is vanaf een domain dat SPF records publiceert en door je oude provider wordt doorgestuurd, door je nieuwe provider worden geweigerd.

Als ik me niet vergis geldt voor Microsoft's CallerID (kort na mijn artikel geïntroduceerd) hetzelfde, maar helemaal zeker weten doe ik dat niet meer.
11-12-2014, 09:21 door ropaja
Allemaal mooi "kundige" reacties hier maar weet iemand ook hoe je die versleutelde bestanden weer kan herstellen want een kennis van mij kan geen MS-WORD of EXCEL bestand meer openen.
Hij is helaas zo dom geweest om het zip bestand te openen op zn PC. Als zn databestanden zijn versleuteld en er is een nieuwe lange extensie achter gekomen. Die extensie er achter weghalen helpt niet want dan lukt het nog niet. Er zal iets in de header van het bestand gewijzigd zijn. Is daar misschien al een oplossing voor?
28-12-2014, 23:09 door GvH
In deze periode rond 21-11 heb ik na eerst nog gecheckt te hebben, deze zip.file toch geopend.
Hierdoor zijn veel bestanden op mijn pc niet meer te openenen, waaronder Excel, Word, PDF en JPG bestanden.
Bij al deze bestanden is bij mij de extensie .lehdwpa toegevoegd, en krijg , zoals de vorige poster ook meldt,deze met geen mogelijkheid meer geopend. Ook niet na het renamen.
Heeft hier inmiddels iemand al een oplossing voor om dit te kunnen herstellen?
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.