1-byte user file flagged Malware.Trace but only if administrator scans

[FrackyMacky]

The following file is flagged as Malware.Trace when a MalwareBytes scan is run as sdministrator:

c:\documents and settings\USER\application data\apple computer\syncservices\Local\conflicts\unresolvedcount (Malware.Trace) -> No action taken. [b6bf5bbbd52b0cf454bc17c49f617987]

I launched MalwareBytes as developer, scanned, and attached the log file.

Note that the file in question is 1-byte long. A text editor (vim) shows that it contains a single character "0" (no end-of-line). This file is created whenever I synchronize my iPod Touch with Outlook. Therefore, even if I get MalwareBytes to remove it, it comes back.

What puzzles me is that a MalwareBytes scan run as USER does not yield any hits. Furthermore, I'm not sure how the administrator's scan can even pinpoint the offending file when it doesn't have permission to descend into "c:\documents and settings\USER".

I assumed it is a false positive and had MalwareBytes ignore that file. I'd appreciate comments from more experienced malware people. Thanks.

mbam-log-2011-02-12 (21-40-14).zip

[shadowwar]

Can you please attach that 1 byte file please.

Thanks.

[shadowwar]

This will be fixed in the next db update. I was able to duplicate it.

[shadowwar]

Please let me know if this is fixed now.

[FrackyMacky]

I just did an update and launched a scan. It will take just over an hour. However, if it doesn't happen in the first 15 minutes (maybe 20), then the fix likely worked.

I am using the free version of MalwareBytes. Rather than specifying the entire C-drive for scanning, I don't suppose there is a way to specify a subtree in my hierarchical folders? That way, it can take much less than an hour to test.

As well, based on the fact that administrator scans seem more sensitive than user scans, I presume that MalwareBytes should always be launched with an administrator account?

Finally, since you were able to duplicate the problem, I assume you no longer have a need for the 1-byte file. If I am wrong, please let me know.

[shadowwar]

we haven't released the update yet so it still should show up. The update should be out in a few hours. It should be in 5752 db or later.

To quicken up the scan you can try right clicking the parent folder and hit scan with malwarebytes.

c:\documents and settings\USER\application data\apple computer\syncservices\Local\conflicts

I appreciate you getting back to me. Please let me know if it is resolved.

I shouldnt need the 1 byte file at the moment. if it still hits with the above db or later then i might.

[FrackyMacky]

Will do. I got a link to this thread in my email box, so it'll be on my radar.

About quickening the scan by right-clicking the specific folder, I was under the impression that mbam had to be launched with a text command in order to specify the developer qualifier. Since I am no longer at the point of generating a developer log file, I guess I don't have to worry about that.

However, (1) I still cannot access the specific USER folder of interest when logged in with a local administrator account and (2) scanning under the USER account does not yield a Malware.Trace hit (even though the offending file is a USER file).

Based on the above I have three questions (thanks for whichever ones you can answer).

1. Is it normal for an admin scan to generate hits on USER files, even though the admin account cannot access said user files?
   
2. As well, does this imply that scans should be run as administrator?
   
3. How else can I specify the exact folder to scan?
   

Thanks!

[exile360]

1. Is it normal for an admin scan to generate hits on USER files, even though the admin account cannot access said user files?
   
2. As well, does this imply that scans should be run as administrator?
   
3. How else can I specify the exact folder to scan?
   

Thanks!

1. Yes, because MBAM itself runs with administrative privileges from an admin account (this is why you'll get a User Account Control prompt when launching it from an admin user account on Vista/7).
   
2. To be able to detect/remove items not accessible under other accounts, yes, though registry traces for locations under HKCU for other user accounts may only be detected under those user accounts since MBAM can't load the offline registry hives for other user accounts, though such items would generally be only dormant traces as the core infection (the files) will generally be detected from any admin user account.
   
3. You can set the path using the command line. For example, if I want to scan my desktop in developer mode, I would use the following line in a batch file or command window:

   "%programfiles%\Malwarebytes' Anti-Malware\mbam.exe" /developer "%userprofile%\desktop"

   Note: If on an x64 operating system you would specify %programfiles(x86)%.
   The above command would have MBAM scan my entire desktop folder in developer mode.
   

[shadowwar]

Yes at this point a dev log is not necessary.

Thanks.

[FrackyMacky]

1. Yes, because MBAM itself runs with administrative privileges from an admin account (this is why you'll get a User Account Control prompt when launching it from an admin user account on Vista/7).
   
2. To be able to detect/remove items not accessible under other accounts, yes, though registry traces for locations under HKCU for other user accounts may only be detected under those user accounts since MBAM can't load the offline registry hives for other user accounts, though such items would generally be only dormant traces as the core infection (the files) will generally be detected from any admin user account.
   
3. You can set the path using the command line. For example, if I want to scan my desktop in developer mode, I would use the following line in a batch file or command window:

   "%programfiles%\Malwarebytes' Anti-Malware\mbam.exe" /developer "%userprofile%\desktop"

   Note: If on an x64 operating system you would specify %programfiles(x86)%.
   The above command would have MBAM scan my entire desktop folder in developer mode.
   

Thanks for that, exile360. I understand point#2, and point#3 works.

I was wondering if you could elaborate a bit more on point#1? I said that the admin account doesn't seem to have access to the user account (at least not from a command line or from windows explorer), so how did the admin scan pinpoint the location of the potential malware in the user folder hierarchy? I know that it does because point#3 works, but I'm not sure how to reconcile this with the fact that you can't browse to the user files.

On a separate note, I noticed a potentially undesirable error handling by mbam (not sure how easy it is to fix). If you specify a path to a nonexistent folder for scanning, mbam reports no malware. It doesn't complain about the nonexistence of the folder.

[exile360]

I was wondering if you could elaborate a bit more on point#1? I said that the admin account doesn't seem to have access to the user account (at least not from a command line or from windows explorer), so how did the admin scan pinpoint the location of the potential malware in the user folder hierarchy? I know that it does because point#3 works, but I'm not sure how to reconcile this with the fact that you can't browse to the user files.

On a separate note, I noticed a potentially undesirable error handling by mbam (not sure how easy it is to fix). If you specify a path to a nonexistent folder for scanning, mbam reports no malware. It doesn't complain about the nonexistence of the folder.

Yes, I can. Even in an admin account (at least in Vista/7) Windows Explorer and other normal apps (even command prompts) do not run with administrative privileges by default, but MBAM does, so it is allowed read/write access to the files and folders of other users. An administrative command prompt would be as well but to get one, you'd need to execute CMD.exe as admin.

With regard to the issue you discovered, technically speaking the method I gave you for scanning an individual file/folder is not an officially documented feature, it just happens to work so I doubt the developers will be altering/enhancing its capabilities in that regard any time soon. The reason it works is because that's technically how the right-click context menu scan works for files and folders.

[shadowwar]

Is this detected any longer?

Thanks.

[FrackyMacky]

Is this detected any longer?

Thanks.

Sorry for the late reply, sometimes the weekend is the only time I can get for personal stuff.

The problem seems to be solved. I no longer get the malware warning. Thanks.

[FrackyMacky]

Yes, I can. Even in an admin account (at least in Vista/7) Windows Explorer and other normal apps (even command prompts) do not run with administrative privileges by default, but MBAM does, so it is allowed read/write access to the files and folders of other users. An administrative command prompt would be as well but to get one, you'd need to execute CMD.exe as admin.

With regard to the issue you discovered, technically speaking the method I gave you for scanning an individual file/folder is not an officially documented feature, it just happens to work so I doubt the developers will be altering/enhancing its capabilities in that regard any time soon. The reason it works is because that's technically how the right-click context menu scan works for files and folders.

Hi, Samuel,

I'm not 100% sure, but I think that apps launched from an administrative account run with less-than-admin privileges in Vista and Windows 7. I'm pretty sure that's the case with Windows 7 because my replacement laptop has it. However, I believe that this does not apply to Windows XP or Windows 2000. I've never had issues with underprivilege instances of apps or commands initiated from an administrator account in those OSs.

With some sleuthing, I think I have a bit more insight into the riddle (if not an answer) of why the admin account can't browse the nonadmin user's file system, but MalwareBytes can scan it. There are actually two riddles: (1) why the admin account can't access the nonadmin user's file system, and (2) why Avast *can* access the nonadmin users's file system.

About question #1, I used Cygwin (a unix layer running in the windows environment) to list the account directories in "c:\Documents and Settings". Of all the account folders, only the nonadmin user of interest showed up with different access permissions than the rest. In unix parlance, the user account showed up with read/write/execute access only for the group, not for the user or the world. So I must have messed around with the permissions. The above permissions would suggest that the user him/herself wouldn't be able to access his/her own account, much less the administrator. However, I find the cygwin listing of Windows folders quite confusing, and possibly not always entirely correct. Since I have a rather old installation of Cygwin, it is possible that the mapping scheme between Windows file/folder security settings and unix permissions representation is immature and not quite stable. For that reason, I did not consider it sensible to pursue this line of sleuthing further without upgrading cygwin and becoming more knowledgable about the windows/unix permissions mappings. Because of the age of my cygwin installation, upgrading will likely involve much chasing down of loose ends and broken functionality, so I've relegated it to a long term to-do. Become familiar with the windows permissions schemes and the mapping to cygwin's unix permissions is also nontrivial to me, so it's also on the longer-term to-do's list.

Even though I can't follow up on the answer to #1 right away, there is a riddle arising from the above which is somewhat separate from that answer. Even if I messed around with nonadministrative users's file/folder permissions, it surprises me that the administrator account cannot override this. After all, the permission changes are only done by a "mere" user account. Perhaps that's just the way Windows works?

About question #2, I asked a related question on another forum about another antimalware app (Avast AV). The explanation given there was that scanning is done under the Avast! service, which runs under a Service account and has access to all user accounts. However, when I view mbam.exe in the Task Manager, it is running with the administrator account's user name, not under the SYSTEM user name like the Avast! service. So while scanning with SYSTEM privileges explains why Avast can access all accounts, it does not explain why mbam can.

Thanks for any further insight.