Sign in

Stuff n Things
Content from a CSS Security Engineer usually covering FCS and Incident Response

TechNet Blogs > Stuff n Things > Dealing with malware that creates .exe’s on file shares
Options
Dealing with malware that creates .exe’s on file shares Blog Home
Email Blog Author
Kurt Falde 23 Jul 2009 7:43 PM 5 Send to friend
RSS for Posts
Atom
So lately we keep seeing variants of malware that modifies content on file servers in an environment in RSS for Comments
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. Search Blogs
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
Search this blog Search all blogs
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 Tags
structure.

So what do you do when this happens to you or how you can prevent it?
FCS FCS ADM FCS Client FCS Database

Proactively
FCS Definitions FCS Polic y Forefront

You could look at utilizing something like FSRM from 2003 R2 and 2008 and file screen filters to block Client Security Incident
.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
Response SCE Scheduled Scans
share on your system to block creation of these files. You can also configure email notifications via SMTP System Center Essentials WSUS
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.
Archive
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. April 2010 (1)
March 2010 (1)
Reactively you should probably do the following:
January 2010 (1)
First and foremost get a copy of the .exe being created on the file share and get that off to your AV vendor. December 2009 (2)
Open a ticket say X is being created and you are not detecting it I need signatures for this threat asap. October 2009 (1)
Signatures on your file server should be able to handle this however you will still be left with AV constantly July 2009 (1)
deleting the new .exe’s so realistically you should track down the offender.
May 2009 (2)
Block the Read and Execute rights to the .exe’s that have been created. You can do this through the use of April 2009 (1)
icacls by running the following at the root of your file share. Keep in mind if you have legitimate .exe’s in the March 2009 (2)
share it will stop users from executing them/reading them. February 2009 (2)
January 2009 (4)
icacls *.exe /T /deny Everyone:(RX)
November 2008 (2)
Tracking down who/what/where is doing the creation of these files is more difficult. One approach is to turn October 2008 (3)
on auditing but this can be complex and often doesn’t yield the IP address of the offending machine. So for September 2008 (1)
this exercise we are going to go with Wireshark or Netmon and Process Monitor.
August 2008 (2)
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 :)

Incident Response
Comments
COMMENTS

Cd-MaN 24 Jul 2009 2:29 AM #

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.

Kurt Falde 24 Jul 2009 10:09 AM #

@Cd-Man

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.

troth 24 Jul 2009 10:44 AM #

"wireshare" wtheck why not netmon

Kurt Falde 24 Jul 2009 12:18 PM #

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.

troth 27 Jul 2009 12:59 PM #

anyway I was just having fun with you!

Leave a Comment
Name

Comment

Post

© 2011 Microsoft Corporation. Terms of Use Trademarks Privacy Statement Report Abuse