Windows system32 ntdll.dll being reported as Trojan.FakeMS.ED

[itlifesaver]

users are quarantining and it either locks up Windows 7 or renders the PC unbootable.

[Thecolorchanges]

We're having the same issue over here, added c:\windows\System32\ntdll.dll to ignore list. Check out the other topic we started: https://forums.malwarebytes.org/index.php?/topic/170828-malwarebytes-removing-system-file-ntdlldll/

[itlifesaver]

We're locked out of our admin console because we added a bunch more PC licenses and apparently the licenses key changed and we can't get any response from Malwarebytes sales or support. Sigh.

[Thecolorchanges]

Ouch! I opened a ticket up with them as we're licensed enterprise. Hopefully someone responds, I'll post up here when they do respond. 

 

Mods! You awake? We're drowning over here!! 

[itlifesaver]

Active 160 seat enterprise license here too. Just paid renewal last month.

[germanr007]

Hello! I have the same problem here!

 

C:/windows/system32/ntdll.dll    detected as 

Trojan.FakeMS.ED

 

Please help!!

[blender]

NTDLL.Dll detection issue has been fixed with database version 2015.07.23.03

Please make sure to update to that version or higher.

It was a false positive that was in the DB for a short time.

 

For those using the premium with the Protection Module, once you update MBAM, you will need to shut MBAM down & restart it for new defs to kick in.

[RubbeR DuckY]

Hi guys, this appears to be an isolated incident. If you're having issues contacting sales or support, go immediately to me and I'll get you routed; mkleczynski@malwarebytes.org.

[PaulHartley]

Hi Guys

 

For all of you with machines that are blue screening I have a quick and dirty fix.

get into advanced recovery mode where you have a command prompt and delete the latest mbam-log xml file in the directory \ProgramData\Malwarebytes\Malwarebytes Anti-Malware\Logs.

you can now reboot the machine and it should boot without blue screening but in the event that it just reboots, go into advanced recovery once more and bring up command prompt and go to the quarantine folder here:

\ProgramData\Malwarebytes\Malwarebytes Anti-Malware\Quarantine

Look for the latest quarantined files and there should be several that are all about 1.2mb in size and were created with todays date. These are renamed copies of the Ntdll.dll file. rename one of these files and then copy it back to windows\system32\ and reboot and the machine will reboot to the login screen and you can log in to the desktop 

 

[Alina]

Hello! I have the same problem!

 

C:/windows/system32/ntdll.dll    detected as Trojan.FakeMS.ED

 

Data base version 2015.07.23.04

 

Since I started the computer every few minutes notifications pop up with message. Please help! Thanks!

[blender]

All:
Sorry for my abrupt reply earlier. As you can imagine, although this false positive has affected a fairly small number of users, it was still pretty busy.

We fully understand the frustrations & are working as quickly as possible to resolve the resulting issues.

 

Alina:
Right click MBAM icon by the clock & choose to exit MBAM.

You will be asked if you are sure (because the protection modules will be shut down)

Answer yes - you are sure.
Restart MBAM. (this will re-enable the protection modules with fresh definitions)

This *should* help clear it up & MBAM should no longer be detecting the file.

Let us know if this is not the case.

 

PaulHartley:
When MBAM quarantines a file, it encrypts it. This is to protect the user from possibly being able to launch malicious files. The only way to restore a file from quarantine is through MBAM itself.

If one tries to rename the quarantine file to the ntdll.dll the machine will not reboot either because the code in the file itself is encrypted.

 

All:

If you already have machines that will not boot, (Windows7), in some cases we are seeing so far (including my own machine) allowing startup recovery to repair the machine has been working.

In a few cases where this has not worked, you may have to get to the Advanced Boot Options & from there, choose system restore to before this incident.

 

If needed, this page describes how to get into the Windows Recovery Environment:

http://www.sevenforums.com/tutorials/668-system-recovery-options.html

 

For those having a large number of machines affected, please contact support or as "Rubber Ducky" said above, if you are having trouble reaching support to contact him.

 

Hope that helps some of you!

[PaulHartley]

Hi Blender,

 

Regardless of whether renaming the file does the job or whether the presence of the encrypted file prompts windows to see it as a corrupted file and automatically replace it, the method I detailed has allowed me to get several machines to boot to a desktop today.

 

I'm sure that you guys may come up with a more elegant way of reviving those machines presently going around in circles rebooting into a bluescreen but for now, in the absence of any other solution, it's a starting point.

Folks could instead use command prompt from the advanced recovery console and copy the file found at x:\windows\system32\ntdll.dll into place at c:\windows\system32 instead or even type SFC /scannow at the command prompt to force windows to fix the issue.
 

[RubbeR DuckY]

Paul, wonder if just the presence of the file (in encrypted form!) caused Windows to trigger a recovery.

 

We do suggest decrypting the quarantined item using a clean machine and restoring it to Desktop and then copying over to affected machines and rebooting.

[tdhaslett]

Just wanted to throw this into the mix...

 

We are also getting FPs on the ntdll.dll file, but not in C:\Windows\System32. Ours, in every case so far (71 clients out of 150), has been detected in these two locations:

C:\Windows\winsxs\x86_microsoft-windows-ntdll_31bf3856ad364e35_6.1.7601.17514_none_5ade482d5a6fc521\

C:\Windows\winsxs\x86_microsoft-windows-ntdll_31bf3856ad364e35_6.1.7601.17725_none_5ad47c575a76f4b7\

 

No BSODs so far. I have pulled down the DB update and pushed it out, so I am hoping we will be good.

[blender]

Hi tdhaslett,

 

The machines that just had files quarantined from the winsxs folder should be OK.

Winsxs explained:

http://www.thewindowsclub.com/winsxs-folder-windows-7-8

 

After you are sure everyone has been upgraded to at least the DB you pushed out, should be able to restore those files.

[PaulHartley]

Paul, wonder if just the presence of the file (in encrypted form!) caused Windows to trigger a recovery.

 

We do suggest decrypting the quarantined item using a clean machine and restoring it to Desktop and then copying over to affected machines and rebooting.

Hi Rubber Ducky

I suspect that the bluescreen is caused by Malwarebytes attempting to delete Ntdll.dll on reboot as this file is a protected system file and previously when things went wrong with it in Vista it was easier to remove the hard drive and mount it in a usb caddy and work on it as a slave drive. Once I had removed the mbam-log xml files from the logs folder the bluescreens stopped but it still kept repeatedly rebooting, just without the bluescreens.

When I went into the recovery console in advanced mode, doing a simple startup repair failed and the repair report told me the file was missing but the repair didn't put it back. Initially when I was trying to figure it out the report stated that the file was missing even though the file was clearly still there and it did not matter what version of Ntdll.dll I used, the repair would still not see the file was present!.

When I copied the quarantined file into place and renamed it and rebooted it did boot through to desktop so I suspect that you may be correct and that the presence of an unreadable file rather than simply an absent file may have triggered a self repair pulling a recovered file from somewhere else.

My problem was that I had a number of users with this issue at remote locations all over the UK and the only usable user interface they had to work with was the command prompt in recovery console as they could not boot into windows fully and recovery console would not find any removable USB drives to copy a clean copy onto the failed machine or copy the encrypted files off to recover on a clean machine. these users also had no ability to remove their hard drives and caddy them up on a second machine so they could only go with what they had on their local drive. I figured that renaming the original file and then copying the quarantined file into the gap left by this action or if the file was missing was probably not going to do any further damage given that startup repair wasn't seeing the file anyway.

I may be wrong but I suspect that trying to restore the ntdll.dll file from quarantine once the machine has been recovered to a desktop may just trigger another bluescreen loop as malware bytes attempts to overwrite a protected file so I didn't attempt that course of action in case it got me into further bother.

I've offered this solution here simply as a quick and dirty work-around and nothing more. I leave it to you guys to come up with a more elegant and lasting fix.

 

I'm just happy to help

 

:0) 

 

[Averum]

I started manually copying a replacement DLL to many PCs this evening and in each case this fixed it. What I noticed was the DLL was present on each system, but it was damaged/corrupt. It appears that Malwarebytes tried to restore it as I requested, but the restored copy is not good.

 

Going to have to fix all of these the hard way. Hands on.