I’ve been taking the layered “defense in depth” approach on my home systems for some time.
Including using (concurrently)…
Last night something started to go wrong with the process and the wheels came off the wagon.
Here’s how I got them back on.
I am running the Premium (lifetime subscription) version of Malwarebytes. Some time ago they came out with a new 3.0 version release. I’ve been reading the reviews throughout the rollout and have waited to do the upgrade. Once nice feature is it now includes the full version of their awesome Anti-Exploit program at no cost to Premium subscribers; something I was using the limited/free version for but couldn’t protect my Chromium-based Vivaldi browser sessions with as the free version didn’t allow setting of custom protections.
As I said, all the bits had been running fine together although – to be fair – Malwarebytes does warn users of EMET during installation that it has compatibility issues and recommends removal of EMET. If disregarded, the installation will continue fine.
Thursday night, my Malwarebytes 2.0 version final got auto-triggered to offer me the eligible upgrade to the 3.0 version.
I said OK and let it install. Installation seemed to go fine. No errors.
However last night, I went to launch Microsoft Excel and EMET went crazy and blocked it from running due to a perceived exploit. That hasn’t ever happened before and I was very confident my system hadn’t been actually exploited. I tried both Excel 2007 and 2010 versions that I have and both got the same reaction by EMET. I then tried Word and it also caused EMET alerts and binary blockage. Hmm.
Well, maybe something in the new Malwarebytes 3.0 was causing a compatibility issue with EMET finally.
So I went to uninstall EMET. Only I had two versions.
Not sure how that happened. EMET 5.52 was supposed to allow for in-place upgrade of EMET over a prior version. Didn’t recall getting an error before.
So I went to uninstall EMET 5.5 and got this:
Same result trying to uninstall EMET 5.52
I tried repairs, changes, etc. to both EMET applications. I still had the original MSI installers for them both but even re-downloaded them from Microsoft. None seemed successful. Note the dates in the “Installed On” column were yesterday’s so something in the processes I did worked, but it wouldn’t let me uninstall them; continuing to present that same “error code is 2738” message.
Since using Excel/Word were critical last night, I worked around the problem up removing all the EMET setting protections for the Microsoft Office suite application binaries. That let me run them without being blocked.
I figured that would be enough, but this afternoon I went to open a PDF with Adobe Reader – and EMET blocked it too from launching due to some kind of perceived exploit.
EMET had to finally go and I had to punch through that error code.
I ended up in a Microsoft forum where others with previous versions of EMET had encountered the same error but it seemed on installations – not uninstall activity.
Technet forums – Security (EMET forum search for “2738”)
Looking through them many seemed to share a common thread with a previous anti-virus product taking over, corrupting, or locking down a VBScript dll process.
Well, perhaps my Malwarebytes and/or CrytoPrevent protections were keeping the vbscript.dll service from being accessed or running?
So I removed my CryptoPrevent protections and disabled my MalwareBytes application.
Nope. Same error.
I did some more digging on a wider net and the more I read about other non-security applications having a
“2738” error on installation, I became convinced it was all related.
So after reading multiple posts I was confident to do the deeper work needed to try to fix this issue.
Using Registry Finder (under an elevated Administrator session) I searched my registry for the string {B54F3741-5B07-11cf-A4B0-00AA004A55E8}.
It came up 12 times, all in the expected locations, except I did have a single odd-string out under the HKEY_CURRENT_USER location. I was pretty sure that was my problem.
[HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}]
All the rest were under HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, or HKEY_USERS.
I exported the registry key first (just in case) then I deleted it.
I then opened up CMD (under an elevated Administrator session) and ran the following commands (note my system is a Windows 7 Home x64 OS):
- cd %windir%\syswow64<enter>
- regsvr32 vbscript.dll <enter>
I then went back and attempted to remove EMET 5.5 and it uninstalled with no more error 2738 codes.
I then followed by removing EMET 5.52 and it came off just fine as well with no errors.
I wrapped things up by re-applying my default CryptoPrevent and MalwareBytes protections states again.
Done.
Again, the trick was to remove the Registry entry just under the HKCU location where it was found present, then re-register the vbscript.dll component properly.
Later while preparing for this post I did find this EMET-related forum post that basically walks one through the same steps for an earlier version of EMET on a x32 bit based version of Windows 7. If you try to follow that and have an x64 bit version of Windows, you will need to adjust accordingly.
EMET 3.0.0 Installation fails on Win7 Pro 32Bit - Error Code 2738 – Microsoft TechNet
Additional resources and guides for addressing the Error Code 2738 problem:
The key to understanding why this works (and where the problem lies is explained nicely in Heath’s above post:
As some people have found, re-registering the runtime libraries vbscript.dll and jscript.dll will fix the errors, but that isn’t always the solution.
As a security measure, Windows Installer will not load script engines registered in HKEY_CURRENT_USER. As a user-writable store, a normal user could get an elevated install to run their library masking as a script engine if the custom action was not explicitly attributed with msidbCustomActionTypeNoImpersonate (0x0800). This is an elevation of privileges attack; thus, Windows Installer returns error message 2738 or 2739 for custom actions type 6 and type 5, respectively, and returns Windows error 1603, ERROR_INSTALL_FAILURE.
Because – somehow – vbscript.dll did get itself registered under my HKEY_CURRENT_USER location, the EMET MSI uninstaller script could not execute. Only by pulling it out, then re-registering it in the correct location automatically, would the removal process complete.
Final thoughts.
I only removed EMET from this particular system as it exhibited the crazy mitigation interceptions for Microsoft Office immediately after upgrading to MalwareBytes 3.0 Premium.
On my other Windows 7 Ultimate system, I am still running EMET (5.52 only) along with the protections noted in the top of this post. The only difference is that I’m using the free version of Malwarebytes 2.0 on it (without real-time protections). So until an issue appears, I’m keeping EMET on that system.
Lavie still is running Windows 8.1 on her laptop with a similar configuration. Lesson learned is that I will first remove EMET before upgrading her MBAM Premium version from 2.0 to 3.0.
Cheers!
--Claus Valca
