New
#11
Did you install Security Tool before or after installing and configuring EMET?
Did you install Security Tool before or after installing and configuring EMET?
Then I would have only one further question which I ask only because I find this very strange and that is, Have you tried running MalwareBytes over your computer before installing EMET, adding programs, and then adding your virus-infecting program?
If this also shows problems, then I'm sure these chaps would be interested in your feedback:
7. Support
EMET 2.0.0 is not currently an officially supported Microsoft product. We are working hard to establish
the appropriate agreements to enable that. In the mean time, EMET is being released as an “AS-IS”
product. That said, you can send your support questions to switech@microsoft.com and we will do our
best to help you.
Installing a Rogue whose sole purpose is to provide scam results to trick people into purchasing the program to test EMET makes no sense whatsoever.
EMET is an acronym for Enhanced Mitigation Experience Toolkit. It is not an antivirus or antimalware tool. In other words, when there is a security vulnerability that has yet to be patched, EMET will help prevent the vulnerability from being exploited.
Ed Bott has a good article about EMET at The one security tool every Windows user should know about.
An example of EMET in use is shown in the Microsoft Security Advisory 2488013 Microsoft Security Advisory (2488013): Vulnerability in Internet Explorer Could Allow Remote Code Execution, Vulnerability in Internet Explorer Could Allow Remote Code Execution:
The advisory was subsequently updated to provide a Microsoft Fix it: Microsoft Knowledge Base Article 2488013.Enhanced Mitigation Experience Toolkit (EMET) is a utility that helps prevent vulnerabilities in software from successfully being exploited by applying in-box mitigations such as DEP to applications configured in EMET.
At this time, EMET is provided with limited support and is only available in the English language. For more information, see Microsoft Knowledge Base Article 2458544.
Configure EMET for Internet Explorer from the EMET user interface
To add iexplore.exe to the list of applications using EMET, perform the following steps:
1. Click Start, All Programs, Enhanced Mitigation Experience Toolkit, and EMET 2.0.
2. Click Yes on the UAC prompt, click Configure Apps, then select Add. Browse to the application to be configured in EMET.
For 32-bit installations of Internet Explorer the location is:
C:\Program Files (x86)\Internet Explorer\iexplore.exe
Note For 32-bit systems, the path is c:\program files\Internet Explorer\iexplore.exe
For 64-bit installations of Internet Explorer the location is:
C:\Program Files\Internet Explorer\iexplore.exe
3. Click OK and exit EMET.
I didn't test emet as a security tool against the rogue AV.
I did test emet's application protection capabilities by placing Task Manager, Regedit and Notepad in it's protection which is not the proper way to test I suppose?
Ed provided a good explanation in his article. Rather than re-invent the wheel, see what he said, with a couple lines I think important in bold. In particular, note the sections quoted by Ed from the EMET documentation.
EMET gives you more granular control over Data Execution Prevention (DEP), a security feature that has been a part of Windows since XP Service Pack 2. Hardware-enforced DEP blocks the execution of code in memory locations that should contain only data, such as the stack or the heap, preventing a common form of exploit. Using EMET, you can turn on DEP for applications that were not originally compiled to be compatible with the feature. (For more on how DEP works, see the two-part “Understanding DEP as a mitigation technology series on the Microsoft Security Research & Defense blog: Part 1, Part 2).
You can also use EMET to overcome a limitation of Address Space Layout Randomization (ASLR). This feature is designed to prevent attackers from jumping to predictable memory addresses to exploit vulnerabilities in code. The problem with ASLR is that it works on a per-process basis; dynamic-link libraries (DLLs) associated with that process can still be located at predictable addresses, where vulnerabilities can be exploited. That’s the attack vector used in the unpatched zero-day vulnerability I mention at the beginning of this post. EMET supports mandatory ASLR, which forces the relocation of DLLs associated with a process and thus blocks this entire class of exploits.
Other features in EMET mitigate against common tricks that hackers use to exploit flaws in code, by blocking common “heap spraying” techniques and validating exceptions before calling an exception handler.
The EMET documentation acknowledges that these are stopgap fixes:Please note this is a pseudo mitigation designed to break current exploit techniques. It is not designed to break future exploits as well. As exploit techniques continue to evolve, so will EMET.In fact, that’s one of the promises of EMET. It exists outside the Windows code base, so it can be updated more aggressively. As the official user’s guide explains:EMET is a living tool designed to be updated as new mitigation technologies become available. This provides a chance for users to try out and benefit from cutting edge mitigations. The release cycle for EMET is also not tied to any product. EMET updates can be made dynamically as soon as new mitigations are ready.