Dealing with malware that creates .exe’s on file shares

So lately we keep seeing variants of malware that modifies content on file servers in an environment in hopes of spreading to other users.  My guess is that it is just using mapped drive letters thinking they are USB keys but the effects is the same regardless.  The actions they take are usually something as follows.  Hide your actual .doc/.xls etc create a new file with the same exact name as the .doc except that it is a .exe and they typically modify the icon to be a folder icon.

At first these seemed to only create havoc at the root of the file share so you could work around this by ACL’ing the root of the file share to stop creation of new files there and force your users to instead create files just in subdirectories assigned to their various workgroups etc.  However later variants seem to be working their way down through subfolders and carrying out their black magic throughout the folder structure.

So what do you do when this happens to you or how you can prevent it?


You could look at utilizing something like FSRM from 2003 R2 and 2008 and file screen filters to block .exe’s from being created on your file shares.  FSRM has a built in template called “Block Executable Files”  This has a large list of various executables including .exe which you can in turn easily apply to any folder/file share on your system to block creation of these files.  You can also configure email notifications via SMTP to let you know when someone does try to create one of these files and it will log the event to the applog as well with the file it attempted to create and the user that tried to create it.

You could also a commenter proposed add a folder named autorun.inf to your file share and hide this so that malware could not create a new autorun.inf to start up malware.

Reactively you should probably do the following:

First and foremost get a copy of the .exe being created on the file share and get that off to your AV vendor.  Open a ticket say X is being created and you are not detecting it I need signatures for this threat asap.  Signatures on your file server should be able to handle this however you will still be left with AV constantly deleting the new .exe’s so realistically you should track down the offender.

Block the Read and Execute rights to the .exe’s that have been created.  You can do this through the use of icacls by running the following at the root of your file share. Keep in mind if you have legitimate .exe’s in the share it will stop users from executing them/reading them.

icacls *.exe /T /deny Everyone:(RX)

Tracking down who/what/where is doing the creation of these files is more difficult. One approach is to turn on auditing but this can be complex and often doesn’t yield the IP address of the offending machine.  So for this exercise we are going to go with Wireshark or Netmon and Process Monitor.

Wireshark or Netmon will yield the offending IP address and Process Monitor can tell us the User account it was created under if we are interested in that however normally we just want the machine IP so we can go find the malware on it.

So download a copy of Wireshark or Netmon and start it up.  Make sure to go into your Capture Options and up your Buffer size to something larger say 50 Mb or so.  In the display filter box we are going to put the following filters

For Wireshark

smb.create.action == 2 and smb.file contains “exe”

For Netmon

Property.SMBFileName.contains(“.exe”) and SMB.RNTCreateAndX.CreateAction == 0x2

This will basically filter down to creation of a new file that did not exist as well as filtering on a file that contains exe.  Yes this could throw us a few false positives but we should be able to clearly identify the offending IP addresses.

My first try at this shows the following



The source IP in this case is the file server where I am running the trace and this is the response packet back to the workstation creating the .exe file stating the file did not exist but it was created.  Note on Wireshark that you have to expand SMB>NT Create AndX Response to see the File ID ## which contains the name, the parser is basically filling in the file name from the previous packet which we do not see.  The file name in this case is “tracelog.exe”  So I would send my tech off (if I was that privileged) to the Destination IP and have them clean the malware off that system.

If I just wanted to find the user creating the files I could use Process Monitor for this. Download a copy and start running it and modify your filter to look like this


PID = 4 is for your System Process as this is the process that creates files that are created via a file share

CreateFile to try to limit this down to just creation of the files

Patch contains .exe to look for just .exe’s being created in this scenario

Since the System technically creates these files if you add the “User” column in Process Monitor all you will see is “NT AUTHORITY\SYSTEM” which doesn’t help so instead we need to look at the “Detail” column”.  Within this text look for Impersonating and right after that it will show you the user that is being impersonated by the System to create the file so that it has the proper ACL’s etc.  In the case shown below the user DCEXCHFSS\Administrator is the user account that is being utilized to create files on the file server.


Hopefully this helps someone if you have any improvements on filtering for either Wireshark or Process Monitor that would help here please let me know.

Edit 7-24-09  Added comments from Cd-Man regarding autoruns and acling files, Added netmon filtering usage based on comments both internally and externally 🙂

Comments (5)

  1. Anonymous says:

    anyway I was just having fun with you!

  2. Anonymous says:


    I like the folder idea that’s probably a good idea in general to create across your file servers as a preventative measure. Preferably you would have autoruns disabled via GPO in the environment but this is a good extra layer 🙂 .

    The ACL’ing of exe’s is good as well for an example for readers you could do the following

    "icacls *.exe /T /deny Everyone:(RX)" run that at the root of your file share.

  3. Anonymous says:

    I know wireshark better 🙂  If someone wants to provide the netmon filter for this go ahead and I’ll post it or if I get free time I’ll try to figure it out.

  4. Anonymous says:

    "wireshare" wtheck why not netmon

  5. Cd-MaN says:

    Some ideas: usually these worms make use of the "autorun.inf" file to get themselves executed as soon as someone clicks on the share (when it is mounted as a drive).

    To prevent this (until you clean up all your system), create a folder named autorun.inf and protect it via permissions such that nobody can delete it. Since you can’t have a folder and a file with the same name, this nullifies the attack.

    An other alternative would be to let the malware create the executable, but after it has been created, remove read/execute rights from everyone via ACL’s. Many variants of these worms use a predefined executable name, and don’t do anything if the given executable already exists.