Websense Security Labs Blog

Websense Security Labs discovers, investigates and reports on advanced Internet threats that traditional security
research methods miss.

View all posts > 

Filtered by : Exploit

Over-indulgence in the Easter Eggsploit Kit

Posted: 06 Apr 2015 12:00 PM | Jose Barajas


Photography by User: MrX As Peter Cottontail went hippity-hoppin’ down the bunny trail this past Easter weekend, he found it strewn with a different kind of Easter egg: the Fiesta exploit kit, hidden in insidious fashion among the downloadable coloring pages at a popular freeware site for children and their parents. A Bad Egg Uniquecoloringpages[.]com offers exactly that – coloring pages for kids, many featuring themes from popular culture ranging from Despicable Me to Star Wars. Ironically, the downloadable coloring page offered by the "Easter Bunny Coloring Pages and Book" depicts a genteel, smiling bunny with an armload of Easter eggs. This ovoid bouquet, however, is definitely rotten, and it all starts off with an injected iFrame. At the time of publication of this blog, the website in question was still believed to be infected. Fiesta EK: Party Crasher The attack follows the typical seven stage kill chain as shown below: Compromised page hosting malicious iFrame RECON - Occurred before the website was compromised. LURE - An injected iFrame was used to redirect users to hxxp://yqbozasv[.]hopto[.]org/wordpress/?bf7N&utm_source=le. Exploit content delivery REDIRECTION - A "302 Moved Temporarily" redirection is used by the iFrame target. This points users to the Fiesta Exploit Kit located at hxxp://yqbozasv[.]hopto[.]org/8u5_cb06/?2. EXPLOIT KIT - The exploit kit uses JavaScript obfuscation to hide the software enumeration and available exploits. One interesting feature to note is the use of random paragraphs and sentences, which seem to be translator-generated-based or pure gibberish. De-obfuscation reveals the targeted and available exploits. The figure below shows a reference to flash object generation. Analysis revealed that it contains many different types of exploits including those targeting Java, Adobe Flash, Adobe Acrobat, and Silverlight. Java and Flash are passed an obfuscated parameter that was observed to be de-obfuscated in the Flash's ActionScript. EXPLOIT - In our use case, the file Flash file cdonwxy478.swf was deployed which leverages CVE-2014-8440 and initiated the download of a binary executable. Behavior of the dropped executable DROPPER - Websense® file sandboxing saw that the dropped executable established a communication channel with b14-mini[.]ru. CALL HOME - Based on C&C communication observed, we have determined that the malware family being dropped in this instance is Kovter. Previously distributed via other exploit kits, it appears that compromised websites injected with redirection to the Fiesta EK are now distributing this malware, which is a high severity threat. Mitigation Websense customers were protected at the time of compromise via real-time analytics targeting iFrame-injected compromised websites. Additional protection has now been added within ACE, the Websense Advanced Classification Engine , at the different stages of the attack detailed below: Stage 2 (Lure) – ACE has protection against websites injected with malicious content. Stage 4 (Exploit Kit) – ACE has protection against the Fiesta Exploit Kit and exploit delivery content via real-time analytics. Stage 5 (Dropper) – ACE file sandboxing identifies Kovter malware as malicious. Stage 6 (Call Home) – ACE has detection for command and control traffic known to be associated with Kovter. ’Tis the Season: Beware Freeware Attack vectors hidden among downloadable freebies provide an easy method to disseminate malware. The bad actor merely plants his flag and waits as potential victims actively seek out material. Seasonal holidays, in particular, offer malefactors a passive but target-rich opportunity. Supply and demand in this case are well served by a limited time frame: As the date of the event nears, interest surrounding associated paraphernalia grows. Targeted victims reward the malicious actor with a surge of interest and in the process, get infected. Websense customers should ensure that analytics are configured to auto-update in real time in Websense products. While browsing leisure sites is an acceptable practice at businesses, Websense customers must also ensure that systems are patched regularly, since we have seen older exploits being used in attacks time and again. In addition, end user education goes a long way in reducing the risk associated with attacks, while we at Websense Security Labs™ continue to keep an eye out for attacks on behalf of our customers. Contributors: Tamas Rudnai, Jose Barajas, Cristina Houle, Rajiv Motwani with input from Nicholas Griffin

Read more > 

Filed under: , , , , ,

no comments

Flash 0-day being distributed by Angler Exploit Kit

Posted: 22 Jan 2015 04:41 AM | ngriffin


Websense is aware of a new zero-day vulnerability in Adobe Flash Player, which has been seen exploited in-the-wild by the Angler Exploit Kit. The exploit, as reported by security researcher Kafeine , is known to affect the latest 16.0.0.287 version of Flash Player and has been seen dropping a trojan downloader called Bedep. Websense customers were already protected against this threat with ACE, our Advanced Classification Engine , at the different stages of the attack detailed below: Stage 3 (Redirect) – ACE has detection for the redirect to the exploit kit landing page. Stage 4 (Exploit Kit) – ACE has detection for the exploit kit landing pages, as well as the Flash Player exploit itself. Stage 6 (Call Home) – ACE detects the communication to the C&C points associated with the Bedep trojan downloader. [ UPDATE ] 23 January 2015 Adobe released an update to Flash Player on 22 January 2015 although it does not patch the issue discussed in this blog. In a further announcement Adobe are hoping to patch CVE-2015-0311 (the vulnerability discussed in this blog and by Adobe here ) on 26 January 2015. Vulnerability The Adobe Flash Player samples that exploit this vulnerability have been shared with Websense, and protection for these malicious files are in place. Adobe have been made aware of this issue and are currently investigating . At the present time, it is not possible to disclose further information regarding specific details of this threat. Exposure Currently, it is known that Angler Exploit Kit is exploiting this Flash Player vulnerability. As we have mentioned previously, it is becoming a growing trend for exploit kits to drop Java, Internet Explorer, and PDF exploits in favor of the more successful Flash and Silverlight exploits. Utilizing vulnerabilities in these popular applications provides attackers with a large surface area of vulnerable clients. Due to the nature of exploit kits, Websense technology is able to target the threat at multiple stages and ensure that protection remains in place independent of the exploits used. Mitigation At the present time, Adobe have yet to release a patch for Adobe Flash Player. One persistent solution, for the time being, is to disable Flash Player in your browser until such time as a patch becomes available. Websense Security Labs will continue to investigate this issue as more information becomes available.

Read more > 

Filed under: , , , , , , ,

no comments

Happy Nucl(y)ear - Evolution of an Exploit Kit

Posted: 15 Jan 2015 05:50 AM | AToro


This blog post discusses how Nuclear Pack, one of the most popular exploit kits, has evolved, and highlights the constant, ongoing arms race between attackers and defenders. While Nuclear Pack is not the most sophisticated exploit kit--that dubious distinction going to Angler, which we will write about in an upcoming post--it is highly effective. It has been used in such high-impact campaigns as the AskMen compromise , and used by the APT group behind Operation Windigo. Nuclear Pack has a wide range of attacks in its repertoire, including Flash, Silverlight, PDF, and Internet Explorer exploits, and it is capable of dropping any malware. Furthermore, Nuclear Pack is constantly being improved by its creators to avoid detection and achieve higher infection rates. Exploit kits are a main source of compromises today; they are one of the primary vehicles for both 0-day and widely effective, known vulnerabilities, offering a free pass to drop active malicious content (such as the banking trojan, Zeus ) that embeds on the system giving cyberciminals a way into internal networks and ultimately leads to data exfiltration. Last year Websense has detected and blocked more than 66 million threats specifically with exploit kits, plus over 1 billion catches of later-stages, such as dropper file, C&C traffic (Call Home stage) that are commonly attributable to new exploit kit activity. In essence, exploit kits are complete, off-the-shelf solutions that cybercriminals can buy to compromise systems by exploiting various software vulnerabilities on the victim's system. In addition, these kits are equipped to defeat IDS and Anti-Virus solutions in order to avoid detection, the main technique they use to achieve this is through using code obfuscation, which is used to hide the true nature of the malicious code. Exploit kits constantly change and improve in order to keep up with various security solutions and the new version of NuclearPack is the next stage of exploit kit evolution. Telemetry Nuclear Pack affects virtually all industries, as it is very often used in high-volume compromises. In addition, the number of exploit attempts varies highly based on the traffic volume of the compromised website, as shown in the charts below. Affected Industries: Nuclear Pack trend activity over time: High Level Overview of Nuclear Pack infections Nuclear Pack follows the traditional kill chain and maps directly to the 7 Stages of Advanced Threats . Websense customers are protected from this threat with ACE, our Advanced Classification Engine, at the following stages: Stage 2 (Lure) - ACE has detection for the compromised websites. Stage 3 (Redirect) - ACE has detection for the injected code that redirects the user to the exploit page. Stage 4 (Exploit Kit) - ACE has detection for the malicious code that attempts to execute this cyber attack. Stage 5 (Dropper Files) - ACE has detection for the binary files associated with this attack. The picture below shows all stages, from the first HTTP transaction with the compromised website. It is worth noting that the original version of Nuclear Pack was seen to use predictable URL patterns. In the new version of Nuclear Pack, the redirect URLs and methods are highly random, making the redirect stage much more difficult to detect. Nuclear Pack infection chain: Obfuscation As with other exploit kits, Nuclear Pack uses various obfuscation techniques to avoid detection by IDS and anti-virus solutions. In order to detect and protect against this threat, it is crucial to understand and identify the obfuscation techniques that are unique to this exploit kit. After cleaning up the landing page so that it is properly structured, we are still left with highly obfuscated JavaScript code. Cleaned up Landing Page (part I): Cleaned up Landing Page (part II): Investigating the structure of the obfuscated code reveals that it actually consists of only a few parts: Some helper routines for deobfuscation Obfuscated content (uses decimal format to store the plugin detect and actual exploit part of the exploit kit) Deobfuscation routines The actual deobfuscation Running the deobfuscated JavaScript How Nuclear Pack deobfuscation works In essence the landing page just takes the obfuscated content, deobfuscates it, and then runs it. One of the most unique Nuclear Pack obfuscation techniques is the use of the background color as means to obfuscate and deobfuscate certain functionality. The original version of Nuclear Pack always sets the background color of the page to an arbitrary color. Later, the variable document.bgcolor is used to deobfuscate a number of functions, which were obfuscated with hexadecimal HTML color values. Unique obfuscation method: <body bgcolor= "#333399" > is used in the example below Deobfuscated Content Once the exploit kit is deobfuscated, the true functionality of the exploit kit is revealed. The deobfuscated code has four parts, and they are executed in the following order: Plugin Detect XMLDOM Information Disclosure exploit to determine whether anti-virus is running on the system Checking whether victim has vulnerable plugin version Launching appropriate exploit(s) Nuclear Pack uses the popular PluginDetect library to fingerprint the victim. As you can see, the creators were using the latest version. PluginDetect: Nuclear Pack uses CVE-2013-7331 XMLDOM ActiveX control vulnerability to enumerate anti-virus software on the target system. Note that the vulnerability only affects Internet Explorer users. The use of this exploit to fingerprint the victim’s machine for anti-virus software is not unique to Nuclear Pack. It is increasingly being adopted by more and more exploit kits (including Angler and RIG). If a specific (hardcoded) anti-virus solution is detected, the infection attempt is aborted in order to avoid possible detection. Anti-Virus Detection: Before launching the actual exploits, Nuclear Pack runs a check to see whether the victim has vulnerable...

Read more > 

Filed under: , ,

no comments

IE Zero-Day Patch on the Way

Posted: 01 May 2014 07:01 PM | Charles Renert


A quick note on CVE-2014-1776 — Microsoft will have a patch out tonight. Especially noteworthy is the decision to patch Windows XP. Good call. Beyond the proactive security provided at all other stages of the threat lifecycle, we've added protection for known variants of the vulnerability and are closely monitoring developments for new variants or indicators of compromise. We can confirm that real-world exploits of this vulnerability continue to appear, and we will be sharing more details of these attacks as they emerge.

Read more > 

Filed under: , , ,

no comments

Microsoft Internet Explorer Zero-day - CVE-2014-1776

Posted: 28 Apr 2014 09:00 AM | AToro


A new vulnerability found in Microsoft Internet Explorer affects Internet Explorer versions 6 through 11. However, current reported attacks are targeting only Internet Explorer 9 through 11. The vulnerability allows attackers to remotely execute arbitrary code on the target machine by having the user visit a malicious website. This vulnerability has been assigned reference CVE-2014-1776 . The vulnerability lies in the way Internet Explorer handles Vector Markup Language and vector graphics rendering when Internet Explorer accesses a related object in memory which has been deleted or improperly allocated. This allows the attacker to execute arbitrary code in the context of the current user. The Websense Approach As with any vulnerability it is always best to apply vendor patches to ensure complete protection from exploit attempts. In this instance no patch or Fix It is available from Microsoft. So, what now? The next best thing to do is to protect from the apparatus and delivery mechanisms used by the attackers. When reports of low volume targeted attacks surface it is often not long before the attacks become more widespread after code targeting the vulnerability is incorporated into exploit kits. At the time of writing attack samples are sparse so we are exploring the telemetry within our ThreatSeeker® Intelligence Cloud looking for exemplars and Indicators of Compromise. We shall update this blog with additional insights as more become available, but for now it does not look like use of this vulnerability is widespread. Websense offers protection throughout the attack life cycle using the 7 Stages of Advanced Attacks model. Typically we see the following scenario in such instances: a user will visit a website (most likely a compromised legitimate website, rather than one specifically registered by an attacker), thus initiating a Flash file download which sets the scene for a further call to a JavaScript payload. This in turn triggers the vulnerability in Internet Explorer. Attackers may use the opportunity of remote code execution to launch additional components within a reconnaissance or data theft attack. In the absence of a patch or Fix It from Microsoft various mitigation techniques are available, including: Most importantly do not use Administrative account for general tasks such as web-browsing. As the attacker inherits the rights of the current user, using a non-privileged account is highly advisable. Consider deploying Microsoft's Enhanced Mitigation Experience Toolkit (EMET v4.1) which is designed to make exploitation more difficult for attackers. Turn on Enhanced Protected Mode (EPM) in Internet Explorer. It is available for IE 10 and 11. Disabling Internet Explorer's Flash plugin will render the exploit non-functional. Disabling VML (unregistering vgx.dll) will turn off the vulnerable library. You should certainly consider this if you are using Windows XP (see note below). For organisation's that are flexible on browser choice you should consider adopting an alternative browser to Internet Explorer, at least prior to applying a patch from Microsoft. More information about the vulnerability, and how to implement the aforementioned mitigation factors, can be found at Microsoft Security Advisory 2963983 . Further, now Windows XP is no longer supported by Microsoft this discovery leads prompts a timely reminder to consider alternatives to this still popular operating system, to better protect from vulnerabilities affecting Windows XP users. Websense Security Labs will continue monitoring the situation and update this blog accordingly.

Read more > 

Filed under: , ,

no comments

Broken Hearted? A Practical Look at the Heartbleed Vulnerability

Posted: 11 Apr 2014 03:15 PM | Carl Leonard


Following on from our previous Heartbleed post , there have been countless reports on the far-reaching scale of this critical security flaw along with numerous discussions as to what 'exactly' an attacker can gain from exploiting the vulnerability. Given the online and 'connected' nature of modern society, security and trust are the fundamental requirements of any online transaction in which personal or confidential data is transmitted. All of us, both technical and non-technical, have come to rely on the 'padlock in the address bar' - an indication that the website is handling our data securely, be that credentials, emails, financial records or status updates, with protection handled by the SSL or TLS protocols. It comes as no surprise that when the very thing that should be protecting us is compromised, in this case a feature within OpenSSL, that the implications can be far and wide. Contributors: Abel Toro, Jason Hill, Alex Watson What does this all mean? As with any organized attack and as described by our 7 Stages of Advanced Threats , target reconnaissance precedes all other stages and, in this case will commence with determining which sites are (still) vulnerable to this OpenSSL vulnerability. As expected, given the widespread media exposure and severity of this flaw, numerous 'proof-of-concept' (PoC) scripts have been developed and are widely available thus allowing anyone with a command-line and an internet connection to start probing web-servers. Once a vulnerable site has been located, a threat actor can attempt to exploit the vulnerability, in this case by sending a specially crafted heartbeat packet which, rather than the original intended use, requests a larger than expected response which subsequently reveals up-to an additional 64k of memory. Once received, the threat actor can then attempt to sift through the returned data looking for 'interesting' items that can be further leveraged, for example, credentials or session IDs which would allow them to gain unauthorized access to the site in question or even, as widely suggested, private cryptography keys which could be used to compromise or impersonate the identity of a trusted site or person. In practice - Obtaining Alice's credentials? Targeting a specific user may prove impractical for a threat actor, especially on larger 'well-used' sites. For example, if our threat actor wanted to steal Alice’s login credentials for a specific site they wouldn't be able to specifically target 'Alice' and would have to keep running the exploit over a protracted period in the hope of harvest credentials which may or may not contain 'Alice's'. On the other hand, if the target site was smaller, less frequented or if it was known when Alice was likely to authenticate, the threat actor may have a higher chance of success although they would still need to be in the right place at the right time. Given this, if you're thinking of changing your credentials it may be pertinent to ensure that the site is not vulnerable to the exploit. Grabbing user names and passwords are relatively easy, private keys are more difficult. Our research has shown that getting usernames, passwords and session IDs is quite feasible for an attacker in a real life scenario. The credentials can be stolen very quickly, without a trace and without much technical expertise. However, while it is theoretically possible to retrieve the server’s private key using the Heartbleed vulnerability, in the real-world this is much more difficult than the aforementioned compromise of user names and passwords. At the time of writing, we have only seen one known successful PoC which can fully or partially extract the private key which required somewhat perfect conditions (for the threat actor): The exploit must account for the specific OS being targeted, in the case of the most widely available PoC: FreeBSD The threat actor must be the first one to communicate with the server after it is restarted in order for the private key to be in memory (If the server has been running for a while the attack is not feasible and therefore a threat actor make seek to 'cause' the server to restart) In a many cases the private key can only be partially extracted, given this, it may be necessary for the attack to be replayed numerous times in order to attempt to obtain all of the parts It is suggested that some fairly standard server configurations will make it much more difficult to get the private key - further reducing the chances of success As detailed in our previous post , Websense strongly recommends mitigation actions such as regenerating private keys and revoking/reissuing certificates. Demonstration In order to demonstrate this vulnerability in a real-life scenario, Websense Security Labs conducted a brief practical analysis of the vulnerability by exploiting a test web-server in our lab environment. Having scanned our test server and determined that it was vulnerable, it was trivial to start reviewing the returned memory results and arguably took under a minute to harvest credentials and gain access to that user’s account. However, as previously stated we needed to be in the right place at the right time and therefore required our victim to authenticate/interact with the website in order for their credentials to actually be 'in memory'. Furthermore, confirming our earlier statement, so long as the server remained un-patched, it was possible to monitor password changes. This clearly highlights the need to exercise caution when interacting with vulnerable hosts such as in this example: User changes an existing password to ‘secret1234’: Which is subsequently exposed when exploited: Through the use of session cookies, it is also practical for a threat actor to steal credentials even if the user is never prompted to login. Browsing to a site from an already established session...

Read more > 

Filed under: , , , ,

no comments

"Heartbleed" Vulnerability in OpenSSL (CVE-2014-0160) Could Lead To Data Theft

Posted: 09 Apr 2014 05:56 PM | Carl Leonard


Websense® Security Labs™ has been tracking news of a vulnerability in the implementation of OpenSSL which has far-reaching implications for it's users and those impacted by it's use. The vulnerability, CVE-2014-0160 , allows a remote attacker to read the memory of systems protected by vulnerable versions of OpenSSL. Data that may be stolen includes certificates, private keys, Personally Identifiable Information (PII) and any other sensitive data. For those not familiar with OpenSSL it is an Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. It is deployed in many scenarios such as within email servers and VPN systems, and can be embedded within operating systems. Any such system using the vulnerable version of OpenSSL is thus vulnerable to exploitation. The vulnerability exists in OpenSSL v1.0.1 through v1.0.1f (also v1.0.2-beta1). Please refer to http://www.openssl.org/news/vulnerabilities.html for detailed information. Please note: an updated (fixed) version of OpenSSL is now available in v1.0.1g Confirmation of this can be found on https://www.openssl.org/news/secadv_20140407.txt (in anticipation of the openssl website being under heavy load, we have provided a screenshot of their advice below): We strongly recommend that you establish whether vulnerable instances of OpenSSL are used in your environment, and if so, you should upgrade OpenSSL, or the software that uses OpenSSL, immediately. Codenomicon, recognised as one of the discovering parties, have provided detail on this vulnerability as well as other mitigation actions that you should consider, which include: Recompile your existing OpenSSL version with -DOPENSSL_NO_HEARTBEATS option (to disable the vulnerable component). Revoke and reissue all certificates from the past 2 years (since the bug has been in existence). Generate new private keys. Invalidate all session keys and cookies. Any end users who suspect that they may have interacted with a web server that is, or was, vulnerable to this flaw should consider resetting their passwords. It is understood that web server logs will not show whether the vulnerability has been used, thus making an attack difficult to detect from that perspective. Our ThreatSeeker® Intelligence Cloud has identified that numerous Proof Of Concept tools have been launched online that can be used to show whether a particular website is vulnerable to CVE-2014-0160. We have seen reports to suggest that upwards of 600 of the Top 10,000 websites (as ranked by Alexa) are still vulnerable. Websense Security Labs will continue to monitor the impact of this vulnerability.

Read more > 

Filed under: , , , ,

no comments

MSIE 0-day Exploit CVE-2014-0322 - Possibly Targeting French Aerospace Association

Posted: 13 Feb 2014 11:32 AM | AlexWatson


Executive Overview Websense researchers have discovered the use of CVE-2014-0322 as early as January 20, 2014 - nearly 3 weeks before the previously known first date of the attacks The attack may be targeting organizations associated with the French aerospace association, GIFAS The CVE-2014-0322 exploit in this attack is hosted on a US server We observed the malicious Shockwave Flash (Tope.swf SHA: 910de05e0113c167ba3878f73c64d55e5a2aff9a ) being uploaded to VirusTotal on January 20. This was presumably done by the attackers to confirm if antivirus had protection for the exploit. At the time there was zero detection The exploit may use an in-memory attack with no file writes to avoid detection from antivirus products Early analysis indicates correlations between this attack and the DeputyDog and EphemeralHydra groups CVE-2014-0322 Attack Analysis Contributors: Alex Watson, Victor Chin - Websense Security Labs Websense Security Labs ThreatSeeker telemetry has confirmed the existence of the Microsoft Internet Explorer 10 0-day exploit CVE-2014-0322 beginning as early as January 20 2014, predating the previously believed first use by nearly three weeks. The CVE-2014-0322 exploit has been seen hosted and delivered from the following URL, which was first seen by Websense on January 20, 2014: hxxp://gifas.assso.net hxxp://gifas.assso.net is presumably a fake site meant to look like hxxp://gifas.asso.fr, which is a French aerospace association: GIFAS, the French aerospace industries association, has more than 300 members, from major prime contractors and system suppliers to small specialist companies. Activities extend from civil and military aircraft and helicopters to engines, missiles and armament, satellites and launch vehicles, plus aerospace, defence and security major systems, equipment, subassemblies and associated software. The use of the very similar domain name may indicate that the French aerospace association is the target, but this domain does not appear to be a campaign with active lures, yet. Domain History for assso.net An anonymous DNS registration service was originally used to register the domain "assso.net" which was updated to direct users to the malicious site on January 20, 2014. Name Servers: NS05.DOMAINCONTROL.COM|NS06.DOMAINCONTROL.COM Registrar Name: GODADDY.COM, LLC Admin Contact: info com hepinglui buxhidao, pinghing 512326 8613590978619 215027763@qq.com Registrant Contactinfo com hepinglui buxhidao, pinghing 512326 8613590978619 215027763@qq.com As of January 28, 2014 gifts.assso.net resolved to 173.252.252.204. This IP address is geolocated to Santa Clara, Calif. We noticed the SHA1 for Tope.swf being uploaded to VirusTotal on January 20 (the same day as the fake gifas.assso.net site was set up), with no detection at the time by AV vendors. Presumably this was done by the attackers to check AV coverage for their malware before starting their attacks, further indicating that January 20 was the initial rollout of this campaign of attacks using this 0-day. Similarity with other observations of CVE-2014-0322 As is in the HTTP stream shown below, visitors going to hxxp://gifts.assso.net are linked to include.html, which sets up the ROP exploit and "Tope.swf" Shockwave Flash file (SHA1: 910de05e0113c167ba3878f73c64d55e5a2aff9a) which is utilized after the CVE-2014-0322 use after free vulnerability to access memory through ActionScript in the SWF file. Checking for Microsoft's Exploit Mitigation Toolkit Additional similarities to the attacks on the US Veterans of Foreign Wars website include the Javascript-based check for Microsoft's EMET (exploit mitigation toolkit) which is attempted to be loaded as an XML to determine whether the DLL is present. If the DLL is verified as existing, the attack JavaScript aborts the attack. var steeple ="<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'res://C:\\windows\\AppPatch\\EMET.DLL'>"; Malicious Content in Tope.swf Shockwave Flash File Below is code located in the Tope.SWF that leads to a second stage dropper called "Erido.jpg". Code snippet below : The code above shows the Shockwave Flash ActionScript downloading content but not actually storing it to a file. The follow-on code below shows a buffer being written and read as "little endian" to denote the order for the byte array to be executed . The _local(x) variables look to be calculations in memory which makes us believe this is an "in memory" only attack, presumably to make antivirus detection more difficult. Analysis of the Malicious ActionScript (AS3) Code Below is the use after free type vulnerability that is triggered when the Vector class is allocated / freed In the code above, the string: appears to be the culprit responsible for causing the vulnerability to return to malicious memory space allocated. Links to DeputyDog and EphemeralHydra Campaigns The similarities in the exploit, delivery and search for the EMET.DLL indicate that the same group of threat actors is most likely behind the malicious URL above and the attacks that have been covered by FireEye . More detailed analysis coming soon. [UPDATE] If you are concerned about your exposure to this vulnerability due to the use of Microsoft Internet Explorer 10 we would recommend that you consider upgrading to Internet Explorer 11. You can find out more information at Microsoft's IE page here . This attack is known to check for the presence of Microsoft's Enhanced Mitigation Experience Toolkit (EMET). If it is found then the exploit attempt terminates. You can find out more about how to deploy EMET in Microsoft's overview here and the EMET knowledge base article .

Read more > 

Filed under: , , , , , ,

1 comment(s)

Dotkachef Exploit Kit Comeback

Posted: 03 Feb 2014 09:30 AM | Sindyan


Websense® Security Labs™ researchers, using our Websense ThreatSeeker® Intelligence Cloud, discovered an interesting new malvertizing campaign that uses legitimate ad systems. The infection starts with a compromised advertisement URL hosted on a legitimate website and ultimately lures victims to the Dotkachef exploit kit. Dotkachef is a new underdog exploit kit that first emerged in early 2013. Unlike the Magnitude and Neutrino exploit kits, which emerged in the same time period, Dotkachef did not get the attention or the coverage these other exploit kits got when they first surfaced. Dotkachef has come back with a very sneaky yet very effective scheme. It infects known advertising systems such as OpenX. The use of advertising systems has proven to be an extremely effective method of spreading malware through trusted legitimate ad chains. Websense Security Labs has encountered and covered similar attacks before with different types of exploit kits : http://community.websense.com/blogs/securitylabs/archive/2012/06/29/cleartrip-com-compromised-malicious-ad-tactics-uncovered.aspx In this blog, we will analyze this new malicious campaign. The infection begins with: 1-A legitimate compromised site hosting a malicious advertisement URL 2-The infected URL is usually hosted on legitimate sites 3-The compromised advertisement URL contains obfuscated malicious code that lures victims eventually to the exploit kit page. 4-Deobfuscation of the code leads to a known Dotkachef redirector URL, such as hxxp://brins.biz. 5- This URL then redirects victims once more to another obfuscated URL hosted on a compromised site. 6-The deobfuscation results will finally lead victims to the exploit kit. In conclusion, the Dotkachef exploit kit has found a new method to come back and compete with well-known exploit kits through the use of advertising systems and has managed to stay hidden and hard to spot by security vendors. Websense security solutions help guard against these kinds of exploit kits.

Read more > 

Filed under: ,

no comments

New Java and Flash Research Shows a Dangerous Update Gap

Posted: 05 Sep 2013 05:51 PM | Matthew Mors


Today we're continuing our Java security research series by analyzing other plug-ins, browser extensions and rich internet applications that are commonly exploited. Our previous research indicated that the current state of Java affairs isn't pretty. At that time, ninety-three percent of enterprises were vulnerable to known Java exploits. Nearly 50 percent of enterprise traffic used a Java version that was more than two years out of date. Through Websense ThreatSeeker Intelligence Cloud analysis we now discover: Only 19 percent of enterprise Windows-based computers ran the latest version of Java (7u25) between August 1-29, 2013. More than 40 percent of enterprise Java requests are from browsers still using outdated Java 6. As a result, more than 80 percent of Java requests are susceptible to two popular new Java exploits: CVE-2013-2473 and CVE-2013-2463. 83.86 percent of enterprise browsers have Java enabled. Nearly 40 percent of users are not running the most up-to-date versions of Flash. In fact, nearly 25 percent of Flash installations are more than six months old, close to 20 percent are outdated by a year and nearly 11 percent are two years old. Our in-depth analysis ran for one month, across multiple verticals and industries. We surveyed millions of real-world web requests for Java usage through our global Websense ThreatSeeker Intelligence Cloud. New Java Exploits and the Neutrino Exploit Kit New Java exploits CVE-2013-2473 and CVE-2013-2463 are already making a big impact by targeting computers running outdated versions of Java. It's clear the cybercriminals know there is a Java update problem for many organizations. For example, Websense ThreatSeeker Intelligence Cloud noticed an uptick in new hosts running the Neutrino exploit kit in the first and second weeks of August 2013. This could be attributed to Neutrino's addition of Java-based code execution exploits including CVE-2013-2463 , which is based on AWT/2D vulnerabilities and affects all Java 6 users (tip of the hat to F-Secure ). Typically associated with ransomware payloads, Neutrino is best known for its easy-to-use control panel and features that evade AV and IPS systems. Forty percent of Java 6 users are vulnerable to these new exploits and there are no software patches in sight. Effective exploit kit delivery mechanisms, such as Neutrino, and unpatched vulnerabilities targeting Java 6 create a significant challenge for organizations that have not updated to Java 7. On the positive side, our updated numbers show that enterprise IT is pushing out more Java updates. Earlier this year, 70 percent of Java requests came from Java 6 users. That figure has decreased to 40 percent. Check out this previous blog post on how Java plays a part within the Seven Stages of Advanced Attacks and our advice on Java remediation steps at this post . Don't Forget About Flash Remember, just a few years ago, Flash was a primary attack vector. As our research above indicates, nearly 40 percent of users are not running the most up-to-date versions of Flash. In the last three months, five security patches have been released for Flash-and that number leaps to 26 over the course of the last year. This is exactly why real-time security models are absolutely essential. Even the best patch management and traditional security tools simply cannot keep up with the ongoing barrage of zero-day attacks and exploit kits being created. We'll keep you posted as we conduct ongoing and future research on these critical systems and programs. Stay tuned on the latest research and information on how to mitigate these threats in future posts.

Read more > 

Filed under: , , , , , , ,

no comments