Jump to content

MB3 Ransomware Protection corrupts ownership of deleted executed files

Recommended Posts

MB3 Ransomware Protection corrupts ownership of deleted executed files



With Ransomware Protection enabled in Malwarebytes 3, if

    (1)  an ".exe" file is copied,
    (2)  the copy is executed,
    (3)  the copy is deleted,

then the deletion attempt sometimes fails to delete the file and
leaves it with its ownership undisplayable.  Any further
attempts to access the file (read, execute, or delete it) result
in an "Access is denied." message.


Typical "dir /Q" output for one such file (which always shows
the owner as "...") is as follows:

   Volume in drive R is LYNX_R_RAM
   Volume Serial Number is D81B-10E0
   Directory of R:\TEMP
  2017-05-29 08:39 <DIR>        LYNX\RoyUser  .
  2017-05-29 08:39 <DIR>        LYNX\RoyUser ..
  2017-05-22 10:54       41,486 ...          argout_018.exe
                   1 File(s)         41,486 bytes
                   2 Dir(s)      34,803,712 bytes free

Investigating the sick NTSF files via {File Explorer,
Properties, Security, Advanced} (even as the magic
"Administrator" user) shows "Unable to display current owner"
and complains that the user does not have the permissions needed
to change the owner or look at the effective permissions.

BUT the (data intact) files revert to their normal ownership and
permissions after a reboot or a "chkdsk /F /V /X" on the drive.

I first noticed the problem with batch files which were aborting
with the "Access is denied." message.  Some frequently-used
".exe" files had been copied to a RAM disk directory placed
early in the Windows execution path.  Occasionally a batch file
would clear that directory (without checking for errors).  When
the clearing failure occurred all subsequent attempts to invoke
the copied program would get "Access is denied." from the
partially-deleted copy on the RAM disk (rather than execute the
original from the hard disk directory later in the execution

I wrote a set of batch files to automate the process of making
copies of a program (e.g., argout.exe) in a specified directory
(e.g., argout_001.exe, argout_002.exe, ... argout_020.exe),
executing all the copies multiple times, deleting all the copies
(without checking for errors), and then checking the directory
to make sure it was really empty.  

With Ransomware Protection enabled I would get a few (sometimes
none, sometimes up to 4) partially-deleted files in each set of
20 files copied.  (I had to reboot after each failure, of
course).  It did not matter whether the copies were in the RAM
disk or on one of the hard drives.  Both 32-bit and 64-bit
".exe" files failed.  Both Windows ".exe" files (e.g.,
timeout.exe) and programs I had compiled myself (such as
argout.exe) failed.

The same tests run without the copies actually being executed
before they were deleted never failed.  The tests never failed
if Ransomware Protection was disabled (regardless of other MB3
options) and always failed eventually if Ransomware Protection
was enabled (regardles of other MB3 options).  

Windows Defender was off.  I repeated the tests with the
internet disconnected and my anti-virus protection (ESET
Internet Security) uninstalled , but that made no difference.  I
have done many installations of various versions of MB3 on two
different computers, running mb-clean twice before each

The relevant installation and checking files I used were


The LYNX computer is an ASUS UL80Jt Notebook running the
10.0.14393.1198 version of Windows 10 Professional.  In order
to simplify the environment I used the following procedure (with
appropriate reboots adjusting Windows Defender on or off after
each reboot) for the last test cycle:

    Updated Windows Defender
    Disconnected internet
    Uninstalled ESET Internet Security
    Disabled Windows Defender
    Uninstalled MB3
    Ran mb-clean
    Installed MB3
    Enabled Windows Defender
    Connected internet
    Activate MB3
    Updated MB3
    Turned on MB3 options
        Ransomware protection
        Signature-less anomaly detection,
        Start with Windows
        Self-protection with early start
    Ran an MB3 Hyper Scan
    Disconnected internet
    Verified the Windows Defender was off
    Waited for MB3 and other activity to die out
    Turned on MB3 Event Log Data
    Ran my diagnostic batch files to the RAM disk
        with no failure
    Ran my diagnostic batch files to the RAM disk
        with the failure shown above
    Turned off MB3 Event Log Data
    Ran mb-check
    Ran FRST64
    Reinstalled ESET

I have attached the requested files as follows:

    MB3_bug.txt             [plain ASCII copy of this text]


As a workaround I have turned off the environment variable which
tells my batch files that they may use the RAM disk to improve
speed.  This slows things down (despite the normal caching of
the hard disk), but I really want the Ransomware Protection.

Yes, this is an obscure issue, but the underlying cause may be
showing up in other problems which you are trying to solve.

Thanks for providing a good product!

Roy Earle






Link to post
Share on other sites

Hello @RoyEarle and :welcome:

An escalation request has been made to the Malwarebytes ARW/MBARW Developer, Program Manager, and others.  Please supplement your exceptional data gathering effort with data logged for MB3's Anti-Ransomware (ARW) module.  A few of those folders/files gleaned may duplicate your data, but additional data, not already captured, will be rendered.

  1. Please download the trusted, Malwarebytes authored arwlogs.exe utility/tool and save only to a system Administrator's desktop of the system in question.
  2. arwlogs.exe is an information gathering tool that neither installs nor does it make system/registry hive changes.
  3. Single right-click the j1Bynr2.png&key=c55e643d4ec26aa771880d2d arwlogs.exe icon and select RunAsAdmin.jpg Run as administrator from the Windows context menu.
  4. If a Windows User Account Control (UAC) alert/prompt for arwlogs.exe appears, select the "Yes" button to continue.
  5. If a Windows SmartScreen warning alert/prompt for arwlogs.exe appears, select "More info" then select the "Run anyway" button to continue.
  6. A Command window will appear and its contents may be mostly ignored.
  7. When "Press any key to continue . . . " appears at the bottom of the Command window, type an Enter key to close the window.
  8. A zipped archive (yyyy-mm-dd-{COMPUTERNAME}.zip) should have been generated to the system Administrator's desktop.
  9. Delete arwlogs.exe from the Administrator desktop.
  10. Attach the above zipped archive to your next reply in this topic.

Thank you for your outstanding documentation efforts.

Edited by 1PW
Escalation initiated.
Link to post
Share on other sites

Reply to request to submit "arwlogs.exe" data:

Before running arwlogs.exe I ran my test batch files again so
you would have a known approximate timestamp for the file
ownership corruptions.

This time the computer was in normal full operating mode with
the internet connected and ESET Internet Security and MB3 both
running.  The MB3 options (which are mostly irrelevant and which
you probably have in the logs) included

    Event Log Data                              off
    Usage and Threat Statistics                 on
    Ransomware Protection                       on
    Scan for rootkits                           on
    Scan within archives                        on
    Use signature-less anomaly ...              on
    Start Malwarebytes as Windows startup       on
    Enable self-protection module               on
    Enable self-protection module early start   on

I logged in as the normal user and ran the diagnostic on the
hard disk and got the failure

    2017-05-31T15:00:15  57904.83351616  CopiedTest begins on LYNX
     Volume in drive C is LYNX_C
     Volume Serial Number is 50E6-2581
     Directory of C:\WORK\CPDT\dst
    2017-05-31  15:01    <DIR>          LYNX\RoyUser           .
    2017-05-31  15:01    <DIR>          LYNX\RoyUser           ..
    2017-05-22  10:54            41,486 ...                    argout_004.exe
                   1 File(s)         41,486 bytes
                   2 Dir(s)  33,344,544,768 bytes free

I then ran the diagnostic with the RAM disk as the destination
directory and received the results

    2017-05-31T15:01:46  57904.83456355  CopiedTest begins on LYNX
     Volume in drive R is LYNX_R_RAM
     Volume Serial Number is D81B-10E0
     Directory of R:\TEMP
    2017-05-31  15:02    <DIR>          LYNX\RoyUser           .
    2017-05-31  15:02    <DIR>          LYNX\RoyUser           ..
    2017-05-22  10:54            41,486 ...                    argout_016.exe
                   1 File(s)         41,486 bytes
                   2 Dir(s)      34,803,712 bytes free

I then logged out and back in as my administrative user.  
I copied arwlogs.exe to the administrative user's desktop
and executed it in "Run as administrator" mode.  It choked
on two busy files but happily compressed the rest.

I have attached

        MB3_bug2.txt            ASCII copy of this text
        2017-05-31-LYNX.zip     arwlogs.exe output

I wish you luck tracking this one down.  Intermittent problems
are just SO much fun to debug ...

Roy Earle




Link to post
Share on other sites

  • Staff

@RoyEarle thanks for the detailed information. Would you be willing to send me (through PM) the batch files/executables that you're using? I'm unable to replicate this internally using the following steps:

  1. Use RAMDISK to create a ramdrive with a temp folder
  2. Set my %TEMP% variable to the ramdrive temp folder
  3. Create 20 copies of an unsigned executable on my desktop
  4. Use a batch file to copy all 20 files to %TEMP% and then delete the file

I've also done the reverse of step 4 (going from %TEMP% to my desktop).

Link to post
Share on other sites

Mr. Collins:


Attached is the mb3ob.zip archive containing the simplified
mb3ob.bat diagnostic for detecting the MB3 deleted copied
executable problem.  Instructions appear as comments in the
batch file.

Stripped of the verbiage and options it is about a dozen lines
of code.

In this form I sometimes have to run mb3ob.bat ten or twenty
times to get a failure.

If you can run mb3ob.bat in your machines without encountering
failures, then there must be something peculiar to my system
settings or operating environment causing the problem.  In that
case MB3 might be working perfectly but just making somebody
else's problem visible.  (And I don't feel like wiping one of my
computers and reinstalling my applications one by one to find
out who.)

Thanks for your efforts.

Roy Earle



Link to post
Share on other sites

As I mentioned in the original post, it does not matter whether the destination directory is in the RAM drive or on the hard disk.  The symptoms are identical.  They seem to occur with the same frequency on either destination.  (When I first started investigating the problem, I got hung up on the RAM drive.  I even updated the Dataram RAMDisk software.  I was reluctant to possibly compromise my hard disk.  But then I finally tried using a hard disk destination and got the same failure.  Fortunately the files are back to normal after a reboot.)

What I find interesting is that with the simplified mb3ob.bat diagnostic LYNX (2011 ASUS UL80Jt Notebook) may require 50 executions of the batch file while MANX (2016 HP Envy 750-150 Desktop) always seems to fail on the first execution.  (The full diagnostic with all the extra checks for file integrity, etc., took several passes to find the errors with about the same frequency on both machines.)  The two machines have essentially the same running environment and software installed.

I can't think of anyone besides MB3, ESET, and Windows Defender who would be mucking around with accesses to executables on a regular basis.  Yet  the problem occurred with ESET uninstalled and Windows Defender disabled.  Is there any other class of program likely to be setting hooks?  I tried killing a few of the other programs which should have been irrelevant:  Bonjour, CrystalDiskInfo, DOSBox, HWiNFO64, OneDrive, Speccy, SSDlife, YTD Video Downloader.  Removing them and rebooting changed nothing.


Last night I saw upon the stair,
A little man who wasn't there,
He wasn't there again today
Oh, how I wish he'd go away...

Roy Earle

Link to post
Share on other sites

  • 5 months later...

FYI:  My original problem has gone away.  One of your updates (or one of
Microsoft's) has corrected the persistent failure.

With ransomware protection on, if ".exe" files were copied to another
location and excuted there and then deleted, once in a while some of the
".exe" files would acquire unchangeable "..." ownership and cause access
failures for read, write, execute, or delete.  This condition of the
files was persistent, lasting until the next chkdsk or reboot.

The persistant failure was present for the MB3 version (as
originally installed 2017-09-21).  The persistent failure was present in
neither an updated version nor the newer version.  
So somewhere in there something fixed the original problem.

Enabling ransomware protection does still create a minor problem:  it
sometimes causes delayed deletion of the ".exe" files.  If you test for
file existence ("if exist ...") immediately after the "erase" command
you will occasionally see ".exe" files still present.  But a few batch
file lines later the ".exe" files will be gone.  (This has evidently
been a problem in Windows under some conditions for many years according
to my internet research.)

The persistent failures were disruptive, but the transient delayed
erasure problem is noticed only by the diagnostic.  I do not know if the
transient failure has been present all along; I had to modify the
diagnostic to detect it.  It may have been hidden by the persistent
failures.  The persistent failure could be seen in tens of iterations;
the transient failures now occur only a few times in a thousand iterations
(16 minutes).

Both the old persistent and the (possibly) new transient failures appear
only when MB3 ransomware protection has been on since boot time.  
Failures can be seen until you turn off ransomware protection.  If you
then turn it back on again without rebooting there will still be no
failures until after the next computer restart.

The bottom line is that I can now leave ransomware protection turned on
almost all of the time.  That makes me feel much safer.

Roy Earle


Link to post
Share on other sites

  • Staff

Thanks for following up @RoyEarle. I'm not aware of any specific defects attached to this that we resolved, especially since we had such trouble reproducing in house. But I'm glad it's working for you now.

As for the diagnostic error, this is somewhat expected behavior as it's a race condition with something else trying to access a file we're monitoring. Unless it's impacting actual usage, I would say it's not an issue.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

Back to top
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.