En hoe werkt dit dan? waar gaat het fout in de security?
Ik neem aan dat de gebruiker meer moet openen dan een .msg, bijvoorbeeld de bijlage in dit .msg bestand?

Wat ik uit het (m.i. zeer interessante [1]) artikel [2] haal:
1) De bijlage is een tweede e-mail;
2) De tweede e-mail bevat zelf ook een bijlage, die lijkt op een PDF file;
3) Als de gebruiker die PDF file opent wordt (ik heb geen idee of daarbij sprake is van een waarschuwing) Javascript gestart die een malware executable downloadt en start.

Enkele zaken die mij zo te binnen schieten:
1) Als mailservers al op bestandsextensies checken is er meestal sprake van een blacklist;
2) De kans dat .msg op blacklists staat is klein, want het komt vaak voor dat e-mails van anderen als bijlage worden meegestuurd. Ik vraag dat bijv. altijd als iemand een verdachte e-mail ontvangen heeft, want dan krijg ik meestal ook alle headers van die verdachte e-mail mee;
3) Virusscanners zijn kansloos bij verse malware;
4) Gebruikers hebben geen idee wat al die bestandsextensies betekenen, en dat kun je hen ook niet verwijten. Bovendien verstopt Windows bestandsextensies en leert mensen te vertrouwen op het icoontje, en dat is in dit voorbeeld vervalst (de bijlage is helemaal geen PDF file);
5) We hebben geen wijdverspreid en betrouwbaar systeem om de identiteit van de afzender en de authenticiteit van de e-mail te bevestigen of juist te ontkennen (SPF, DKIM en DMARC helpen bevestigen maar helpen geen zier bij vervalste afzenders - d.w.z. ze kunnen niet ontkennen).

[1] Superhandig is het dat 7-Zip .msg files kan openen. Briljant! En weer wat geleerd vandaag dankzij security.nl :-)
[2] https://www.trustwave.com/Resources/SpiderLabs-Blog/Down-the-Rabbit-Hole--Extracting-Maliciousness-from-MSG-Files-Without-Outlook/

Ik wil hierbij toch even reageren om misinformatie te voorkomen:
3) Virusscanners zijn al lange tijd niet meer de achterlopende scanners die enkel op basis van signatures werken. De meeste virusscanners (eigenlijk hernoemd naar anti-malware tegenwoordig) werken bijna volledig op basis van real-time scanning en passen geavanceerde technieken toe zoals Intrusion Prevention, in-memory scanning van de machine-code, heuristische gedragsherkenning en cloud netwerken die alle systemen op aarde snel op de hoogte brengen zonder dat er een virus-definitie update voor nodig.

4) De extensie is niet vervalst. Wanneer je bijvoorbeeld een .pdf bestand wilt openen wat geen pdf is maar een javascript bestand dan begint het bestand niet met de volgende bytes: 25 50 44 46. Door de koppeling van de extensie .pdf aan een pdf-reader programma wordt het bestand in dat programma geopend, maar deze zegt vervolgens dat het bestand niet geopend kan worden omdat de eerste bytes niet aangeven dat het een pdf is. Wat met de malware-infectie pdf bestanden gebeurd is dat het een echt pdf bestand is, vaak met een echte factuur of iets dergelijks om argwaan te voorkomen. Vervolgens wordt op een bepaalde manier, zoals het pdf formaat ondersteund (vergelijkbaar met macro in Word) code uitgevoerd om de gebruiker te infecteren.

5) SPF, DKIM en DMARC helpen juist tegen het vervalsen van email adressen. Als iemand een mail probeert te sturen vanaf pietje@gmail.com via zijn eigen server mail.hackert.nl zal de ontvangende partij dit proberen te controleren. Aangezien de partij mail ontvangt van gmail.com wordt hiervan het DNS record opgevraagd, dit record bevat ook de SPF gegevens. Dit SPF record geeft bijvoorbeeld aan dat mail vanaf gmail.com alleen verzonden mag worden vanaf IP adres 172.217.17.37. Indien mail.hackert.nl niet resolved naar dat IP adres is dus ontkent dat de mail afkomstig is van Gmail. Hoe de ontvangende mailservers het bericht vervolgens afhandelt is afhankelijk van de beheerder, maar volgens best practices komt de mail ten minste in de spamfolder terecht.

Helaas is het niet waar wat je schrijft (zie verderop waarom niet):

A) "Intrusion Prevention" is een reclamefolderkreet. Voorwaarde daarvoor is namelijk detectie voordat code (dropper, exploit of doelcode van een aanvaller), of een interactieve aanvaller, welke schade dan ook aan kan richten;

B) "in-memory scanning van de machine-code" idem. Om dat efectief te doen zou het computers veel te traag maken, en linksom of rechtsom zit je met het dilemma dat er geen "kwaadaardige machine-code instructies" bestaan; je moet naar een combinatie van acties kijken om te besluiten of iets kwaadaardig is of niet. Aanvallers hebben oneindig veel mogelijkheden om complexiteit toe te voegen. Dat ga je nooit winnen;

C) "heuristische gedragsherkenning" idem. Veel te simpel te omzeilen;

D) "cloud netwerken" - dit is het enige uit jouw lijstje dat enigszins werkt. Voorwaarde is dat jouw AV boer eerder een uniek sample heeft geanalyseerd en een herkenningspatroon in de cloud heeft gezet voordat jij de betreffende malware activeert. Ook dit is een lost race, veel mensen zijn tegenwoordig 24x7 bereikbaar.

Grootste probleem: malwaremakers prutsen net zo lang aan hun malware tot geen enkele (grote) virusscanner ze meer herkent, en dan laten zij ze "los". Geen enkele van de door jou genoemde technieken kan daar tegenop.

Bovendien worden virusscanners steeds logger en groter. Kaspersky op mijn PC heeft op dit moment een "signature count" van 7,556,818. Zet dat af tegen de 572,000,000 malware-exemplaren die AV-test heeft geregistreerd [1]. En van dat getal vermoed ik dat het om het topje van de ijsberg gaat.

Aanvallers zijn gewoon zeer succesvol in het bypassen van anti-malware oplossingen, zoals de vele op internet gepubliceerde analyses bevestigen (zie bijv. [2]). Tegen de tijd dat anti-malware detectie voor een exemplaar heeft gerealiseerd hebben de aanvallers allang weer een nieuw exemplaar in omloop gebracht.

[1] https://www.security.nl/posting/486915/572+miljoen+malware-exemplaren+sinds+1984+geregistreerd
[2] https://isc.sans.edu/forums/diary/Rig+Exploit+Kit+from+the+Afraidgate+Campaign/21531/

Dat schreef ik dan ook niet.

Ja en nee. Als alles meezit (de zendende partij ze correct heeft geconfigureerd en de ontvangende mailserver er überhaupt iets mee doet) bevestigen ze dat een e-mail daadwerkelijk afkomstig is uit (of rechtmatig namens) het domein gekoppeld aan de domainname van het SMTP adres in het From: veld.

SPF, DKIM en DMARC zijn kansloos als een spammer een iets afwijkende domainname gebruikt (voorbeeld: [3]). En sowieso tonen de meeste mailclients (zeker op smartphones) niet het SMTP adres waardoor ik echt-lijkende mails ontvang met bijvoorbeeld:

Bovendien kun je die protocollen vermoedelijk in de war brengen met formeel onjuiste SMTP adressen, want de volgende heb ik ook al een paar keer voorbij zien komen:
Uit [4]:
Oftewel: succes ermee!

En nu we het toch over partijen hebben die beter zouden moeten weten, zie ik bij e-mails echt afkomstig van KPN bovenin de headers het volgende:

En last but not least worden policies vaak niet afgedwongen omdat de afzenders bang zijn dat hun mail niet aankomt (vooral niet als de kans bestaat dat deze wordt doorgestuurd).

Kortom, SPF+DKIM+DMARC zijn een bende waar je in de praktijk nauwelijks wat aan hebt: als je pech hebt komt je mail niet aan en belangrijker: je voorkomt er niet mee dat ontvangers denken dat jij een mail gestuurd hebt die jij niet gestuurd hebt.

[3] https://www.security.nl/posting/471357/ICS+Phishing+spamrun
[4] https://tools.ietf.org/html/rfc7489

[/quote]A) Intrusion prevention heeft geen detectie nodig, dit werkt namelijk gebaseerd op rules of triggers. "Wordt er een .ws bestand geopend vanuit %appdata%" rule triggert en ofwel de executable wordt geblokkeerd of wordt extra in de gaten gehouden/verstuurd naar de cloud. Om maar even een simpel voorbeeld te geven. Uiteraard zijn de echte rulesets veel complexer en meer met elkaar geintegreerd, dit is ook de voornaamste reden dat er gigantische fouten voor kunnen komen waarbij bijvoorbeeld alle sites die javascript draaien worden geblokkeerd. [1]

B) Juist omdat aanvallers oneindig mogelijkheden hebben om complexiteit in high-level talen toe te voegen is een in-memory scanner zo belangrijk. Jij stelt dat dit veel te veel resources zou kosten om echt te doen, maar er zijn tegenwoordig ook meerdere producten die niet alleen het programma in-memory scannen van begin tot eind van de uitvoer maar zelfs real-time controleren of de code niet mutate op een stuk die al uitgevoerd is. Met betrekking tot de snelheid: computers zijn de laatste jaren ontzettend hard vooruit gegaan waar de benodigdheden van de software maar matig bij trekken. Er zijn dus veel meer resources beschikbaar op een snellere processor/geheugen dan vroeger. Hierdoor is de vertraging die vroeger al merkbaar was bij het uitvoeren van signature scans nu niet meer merkbaar.

C) De gedragsherkenning, samen met bovenstaande modules, ontvangt ongeveer elke 2-4uur samen met de signaturedatabase updates. Deze zorgen er voor dat in de tijd dat een malware maker zijn virus klaar denkt te hebben er alweer nieuwe obstakels zijn. Daarnaast worden al maandelijks tienduizenden nieuwe samples aangetroffen waarvan een veelvoud simpelweg gekopieerd/afgeleid is van bestaande code met simpele aanpassing voor een quick buck. Er zijn maar weinig samples die écht hun best doen om 0 detectie te hebben. En dan zul je eerder bij de exploit kits uitkomen dan bij de malware zelf. De kracht van bijvoorbeeld ransomware is net de simpelheid, omdat er geen exploits of andere kwaadaardige dingen worden gedaan bleven deze lang onder de radar van anti-virus producten. Gedragsherkenning biedt hier een oplossing in en stelt anti-malware producten in staat om bijvoorbeeld na het starten van ransomware binnen een paar bestanden het proces te kunnen stoppen. Natuurlijk is de gebruiker dan die paar bestanden kwijt, maar zonder detectie was alles encrypted.

D) Het nadeel van de cloud netwerken is inderdaad dat er nog altijd infecties plaats moeten vinden, omdat men het nou eenmaal niet accepteert dat ze een bestand willen openen maar deze eerst nog door de sandbox volledig moet worden geanalyseerd in het virus lab. Maar deze relatief kleine groep gebruikers bouwt weer aan een sterkere protectie wereldwijd en dit wordt binnen enkele minuten gesynchroniseerd. Daarnaast worden hieruit ook weer de regels voor bovenstaande modules uitgebreid en verbeterd waardoor nieuwe varianten makkelijker te ontdekken zijn.

Als je de gelekte emails van een professionele partij als Hacking Team leest zie je dat zij al moeite hebben met het omzeilen van alle virusscanners [2]. Laat staan dat malwaremakers dit allemaal doen, kunnen en tijd voor maken. Op een bepaald moment is het de extra investering gewoon niet meer waard als je niet achter zeer high-profile targets aan gaat. Dan neem je genoegen met 60% van de bevolking die de "makkelijke" of geen antimalware producten gebruikt.


In het Gartner Magic Quadrant report lees je onder "Strengths" bij de producten dat deze features echt zijn, en niet zomaar marketing-praat. [3] Een aantal quotes:

[1] https://forum.eset.com/topic/7567-jsscrinjectb-and-htmlrefreshbc-false-positive/
[2] https://wikileaks.org/hackingteam/emails/?q=detected&mfrom=&mto=&title=&notitle=&date=&nofrom=&noto=&count=50&sort=0#searchresult
[3] http://innetworktech.com/wp-content/uploads/2016/02/Magic-Quadrant-for-Endpoint-Protection-Platforms.pdf

Ik heb je eerste post nog eens nagelezen en je benoemd inderdaad . De verwarring is ontstaan omdat je in de rest van je post verder gaat met het benoemen als "de PDF file".

Duidelijk verhaal, hierin gaat jouw kennis verder dan het mijne. De uitzonderingssituaties die jij beschrijft maken het inderdaad moeilijk om te stellen dat het rijtje SPF+DKIM+DMARC dé oplossingen zijn, maar in de dagelijkse praktijk zien wij dat een groot gedeelte van het probleem toch al aangepakt wordt door de implementatie er van. Het maakt het leven voor een kwaadwillende in ieder geval een stukje moeilijker. Bijvoorbeeld met het invullen van krijg je in een anti-spam oplossing mogelijk al weer extra punten.

Het MSG formaat is door MS vrijgegeven onder een eigen OSS benadering https://msdn.microsoft.com/en-us/library/cc463912(v=EXCHG.80).aspx Ergo:
- Elk willekeurig product dat msg files afhandelt zal/kan kwetsbaar zijn.
- er zijn meerdere momenten om actie te ondernemen.
a/ Zorgen dat dit soort bestanden niet binnenkomen (eg filteren uit email verkeer)
b/ bij het bekijken van het msg bestand niet automatisch andere acties laten starten (beperkte viewer)
c/ De technische omgeving up-level houden/brengen zodat het niet meer kwetsbaar voor dat soort aanvallen is.
d/ awereness bij de gebruiker- niet overal op klikken dan wel openen.

Als je als security officer druk moet gaan maken over gebrek aan technische afscherming dan doe je iets goed fout.
De systeembeheerder en gebruikers hebben kennelijk andere inzichten over hoe er gewerkt moet worden.
Je faalt in of overtuigingskracht of in business-alignment (het risico kennend wordt het geaccepteerd)
Dat gedoe met extensies als probleem zien is technisch prima oplosbaar, wat houd je tegen om er iets aan te doen?