Malware adds entries to hosts file

Hi,

I found an malware (fake antivirus), which could able to modify the hosts file successfully despite the following entry in “my protected files/folders list” -

%windir%*|

Please find the attached screenshots.
Comodo successfully blocked the malware in writing the entries to hosts file only after adding hosts file to my protected list explicitly. Isn’t it should prevent by default?

One more thing, when i ran the malware for the second time, it did not modify hosts file as expected, but it did created some ini files in my app data folder, look at the attached 3rd screenshot.

Test Environment -

  1. Comodo Firewall v5.8 (Proactive Profile, Sandbox set to untrusted)
  2. Eset NOD32 AV v5.0
  3. Tested in sandboxie on a W7 64bit machine
  4. CIMA - http://cima.security.comodo.com/report/8aeafe797d348ed840b7d50c4367373c2717775c.htm

Thanks,
Harsha

[attachment deleted by admin]

I’d guess it’s the sandboxing that is causing this. D+ appears to see the physical path, not the virtual one.

(Is this a change of behavior?)

So you’d possibly need to protect %Sandboxpath%%windir%*|

Assuming you’d defined %sandboxpath% as an environment variable.

Whether this is a security risk maybe depends on what copy of the hosts file the OS uses, original or modified virtual.

Best wishes

Mouse

So you'd possibly need to protect %Sandboxpath%\%windir%\*|

Thanks for the above suggestion.
I have removed hosts file explicit entry and added above virtual path to my protected files/folder list. But malware sample still able to modify the hosts file entry. Ofcourse virtual path only as its run inside the sandboxie.

Whether this is a security risk maybe depends on what copy of the hosts file the OS uses, original or modified virtual.
It did not bypass sandboxie, the hosts on physical path remains intact.

Thanks,
Harsha

Interesting. I wonder if the | applies only to the current directory, not its subdirectories. The * should make the protection apply to subdirectories, but maybe not the |. (The consequence of an alteration of a physical file is the deposit of a virtual file of course, so the virtual path would need the | I guess).

Also possible that Eset is involved.

What happens if you protect the physical and virtual path at once I wonder?

Best wishes

Mouse

I tried with *. But it does not work. I even tried protecting only physical path and both virtual and physical path together but of no use.

And also i think, D+ does not have any problem in seeing virtual path. Because, as i earlier said, it blocks succesfully if i add the host file complete path explicitly.

Thanks,
Harsha.

Hmm, so you are suggesting its the use off the environment variable, maybe inconbination with the sandbox? Well I wonder what %windir% expands to on your machine?

Type set at a command window, what’s the exact sequence of characters?

Best wishes

Mouse

Could you give the explicit path please, the one that worked?

Best wishes

MOuse

Hi mouse,

Below are the paths i have defined -

%sandboxpath% - C:\Sandbox\Harsha\DefaultBox\drive\C\Windows
%windir% - C:\Windows

explicit path that worked is C:\Windows\System32\drivers\etc\hosts

Thanks,
Harsha.

Thanks. Please note you have to close and open cfp.exe for a new environment variable to take effect.

OK what I think is happening here is:

  1. The asterisk means that the hosts file on the physical path is protected from modification
  2. But you are using a sandbox, so the first attempt to modify the physical file turns into a create of a virtual file on a different physical path
  3. This is not impeded, for a number of possible reasons
  • maybe CIS works at the physical level, and needs the restriction to be on the physical path of the virtual file. Maybe you did not restart cfp before testing this
  • maybe the * does not extend the scope of the | to subdirectories. If this is the case CIS would not impede itthe fisrt time, but would the second and subsequent times, as the virtualfile creation (no inhibited) would be followed by virtual file modifications (inhibited)
  • else possible sandboxie is really getting in the way of CIS!

If you want to know maybe test the above - testing scenarios will need to be very careful and carefully documented to find out what is happening :slight_smile:

Subtle stuff, but not an immediate security risk I think?

Best wishes & good luck

Mouse

Either the asterisk does not extend the scope of the | to sub-directories of the

Ok yesterday when i created the env. variable, i did not restarted cfp.exe. But today when i tested again, malware could successfully adds entries to hosts file and creates an exe to syswow64 folder.

I would be rather happy to give the sample if you have some time to test it in your VM. (as i don’t have a VM to test it and probably i’m doing sth wrong here).

Attaching the screenshots for protected list and sandboxie window…
Note: I did remove the “important files/folder” group in order to test “*” entry for windir…

Thanks,
Harsha.

[attachment deleted by admin]

OK then, subject to confirmation by careful testing scenarios, then it’s either a specific Sandboxie interaction or the environment variables are not being correctly interpreted. The latter work OK on XP, as I tested them recently.

However I don’t think there’s really a security risk here, unless you know differently. Indeed you could say CIS is co-operating with Sandboxie as if it was CIS’s internal sandbox. So it could be by design.

Further investigation would take some time - sorry but, although interested, I don’t have the time to do this - we mods are volunteers :). Please do post the results if you decide to do it yourself.

Best wishes

Mouse

i’ve been busy over the week. So, could not test at the time.
Today, i’ve tested in two scenarios and found comodo blocks it successfully by blocking any attempt to modify/create files into my sandbox folder by the mawlare

Scenario 1

  1. Created following entries to my protected files/folders group…

C:\Users*\AppData\local*.exe|
C:\Users*\AppData\local*.sys|
C:\Users*\AppData\Roaming*.exe|
C:\Users*\AppData\Roaming*.sys|

  1. Restarted system
  2. Ran malware (fake AV). no host file entries were created. It just opened its interface. Thats it.
  3. Attached D+ log for reference.

Scenario 2

  1. Removed the newly created protected group as done in the above sceanrio.
  2. Restarted system
  3. And still the same result.

I’m not sure why initially on Day 1 it did not block. But since it is working fine, i request mods to kindly close the thread.

Note: I did remove sandbox path for both the scenarios initially.

Thanks,
Harsha.

[attachment deleted by admin]

OK looks like probably this is not a problem then, so locking thread.

It can be unlocked by PMing any mod if anyone thinks they see this problem occurring

Thanks for your further feedback which is much appreciated.

Best wishes

Mouse