Analysis Help to find a file

Content Authoring
1

I am new to bigfix. My management has given me a directive to search several hundred computers for a specific file (malware) that may have infected some of our desktops. The AV product we use is not capable of this so I must do this using bigfix.

Our security group has provided me with the name of the file and the MD5 hash. Something like

286A9EDB379DC3423A528B0864A0F111
system.ini

So my question is how do I go write an analysis to find a file based on MD5 hash and file name. Couple of things to caveat this with: I don’t know where the file is, I have to search the whole computer. I know this is CPU and Disk I/O intensive and this is not recommended to do.

I appreciate any help that you can provide.

2

To search the whole system, you must use an action, not relevance directly.

This will be very slow and take a long time. You could have it run detached with a bigfix action so it doesn’t prevent other bigfix actions from running during that time, which could take quite a while.

I’m not completely certain of the best way to do this. You need to identify some software that will allow you to check the MD5 hashes of files that can run on the command line and save the results to a log. Alternatively you could write some code and run it using bigfix that would do this for you.

In the short term, I would recommend looking at the fixlet I made to run the HitmanPro on-demand virus scanner and the analysis to check the results:

http://bigfix.me/fixlet/details/3967

http://bigfix.me/analysis/details/2994641

The fixlet to run HitmanPro may need updated if a new version has been released since I last updated the fixlet on BigFixMe.

This will not install another virus scanner, it will just run it on demand, log the results, and then get deleted. The analysis will read the logged results and tell you what potentially malicious software it has identified.

You should be able to do the same sort of thing using other AntiVirus scanners that can run on the command line.

1 Like
3

Unfortunately, due to the security of our environment, I cannot use something like HitmanPro but I appreciate the response.

For anyone else who may have an idea, I found the following.

When I look under inspectors, there is a md5 property that looks like it will return a string of md5 could this be used to do the MD5 hash?

4

The issue that jgstew is eluding to is that the file system doesn’t store hash data in the filesystem metadata.

This means that for every file big fix checks the MD5 hash of it has to read the file from disk compare the hash against your search string and then move on to the next file. This will take a very very long time and have a significant impact on system performance.

Do you have an idea of where the file might be stored? Does the malware have a running process? Does the malware have a running service?

1 Like
5

We do not know where the file is stored (and there are actually several I have to scan for). It is not running as a service or at least neither my security group, nor myself have discovered it running as a service. A process is kicked off when it runs, but it is not always running, so I can reliable look for a process either.

At a minimum, I need to see if I can scan for the file(s) alone without the MD5 hash.

6

As already suggested, this will be a resource (and likely time) intensive process, but it can be done via an action/property combination. At a high level, you might do the following:

  • have an action that leverages standard OS scripts/methods to search the machine for the given file first by name to identify all the potential files/paths in scope. The resulting paths can be output to a file for the next step.
  • leverage relevance substitution within the actionscript to check the MD5 hash of the found files by name. this can then either output the found hashes to be pulled via property, or better yet, it could be used to compare against the known hash to return another value to facilitate reporting

Leveraging an action/property approach also allows you to schedule this ‘scan’ off hours, and stagger it as well to reduce impact to the environment.

1 Like
7

I’m not sure if this is the security issue that you are referring to, but you can run HitmanPro in an offline only mode. It will give you less data, but it will still identify potential malware.

Are there tools similar to HitmanPro you could use, or are all potential offline scanners problematic?

If you have specific folders and file types to check, that could be done in an analysis using relevance directly.

It is possible to use relevance through relevance substitution in a Fixlet/Task to actually do file searching and MD5 hashing and output the results, but this would be much slower and more resource intensive than using an actual utility that you would run on the command line using actionscript.

Also, I would strongly recommend using the following actionscript line before running any scanners:

action launch preference low-priority

This will cause the scan to impact users less.

Also, you haven’t said so, but I assume these are windows systems.

Some potential hashing utilities:

Also, check the run keys for suspicious items: http://bigfix.me/analysis/details/2994785

SigCheck will help you find all unsigned executables, which malware is highly unlikely to be signed:

SigCheck can also look for file signatures based upon a catalog. Not sure what the catalog format is, but it seems like you could put a bunch of hashes you want to find in the catalog, and it would scan for those in particular.

8

@MaxAdmin The other respondents are correct, this is not an efficient use of IEM/BigFix, but it can be done with minimal pain. What follows is basically what @aram suggested. I’m assuming there won’t be too many instances of “system.ini” on each endpoint and they won’t be very large, so generating the Hash won’t take much computational effort, just some disk I/O.

You’re going to need to use a combination of a Task and an Analysis and an external utility to perform this. If you could use the SHA1 hash, you wouldn’t need the external utility.

You need a utility to generate the MD5 hash values. If you don’t already have one I recommend the FCIV.exe utility. It should fit the bill nicely. You can extract the .EXE file from the file available from the URL below and place it where you can download it during the Task (I have an IIS server where I host internal utilities that I might need, but your environment is different).

http://download.microsoft.com/download/c/f/4/cf454ae0-a4bb-4123-8333-a1b6737712f7/Windows-KB841290-x86-ENU.exe

Let’s look at the Task first. The first priority is to minimize the number of files that you will be generating the Hash value for. You have the file name you are looking for (system.ini), just not a file path, so let’s create a list of all the files on the system with that file name … (I am assuming C:\TEMP exists, adjust it as needed, or you can keep this all inside the BES Client folder). Once we have the list of system.ini locations, we need to hash them, then make the hash values available to an Analysis.

The Relevance for this task should be something similar to …

(Windows of Operating System)

The Action script would be …

// We need to get the FCIV.exe utility, I’m leaving that code out but assuming it is placed in the C:\TEMP
// folder to keep this simple.

// We’re going to create a .cmd to generate what we need.
delete __createfile
delete C:\TEMP\FileList.txt
// If we don’t delete the Hash database, FCIV will put duplicate entries in it on the second scan.
delete C:\TEMP\Hash.xml
delete C:\TEMP\HashList.txt
createfile until END
@ECHO OFF
REM I’m assuming C:\TEMP exists, adjust to your environment, or it can be tweaked to use the
REM BES Client folder paths, the resulting hashfile.txt needs to persist for the Analysis to evaluate
REM later.
REM Step 1 - To minimize the number of files we need to generate a Hash for. This might be possible
REM with FCIV directly using different command line switches, but I couldn’t get it to only hash the target
REM file, just by file extension types.
C:
CD
DIR /B /S system.ini > C:\TEMP\FileList.txt

REM Step 2 - Generate the hash values by iterating through the resulting list of found files.
for /F “tokens=*” %%A in (C:\TEMP\filelist.txt) do C:\TEMP\FCIV.EXE -add “%%A” -md5 -xml c:\temp\hash.xml

REM Step 3 - Export the Hash values to a text file where an Analysis can evaluate them.
C:\TEMP\FCIV.EXE -list -xml c:\temp\hash.xml > c:\temp\HashList.txt> END
move __createfile FindStuff.cmd

// Run the cmd file
waithidden FindStuff.cmd

= Overview =

  1. This script will result in a file that contains one line per instance of a any file named SYSTEM.INI on the C: drive. It may take a few moments to run, but no longer than most software installs. A 2-3 minutes, max in testing on my desktop. If you need to scan multiple drives, include multiple DIR lines and use the >> redirection option for each DIR command after the first. We want a single file “FileList.txt” with all the resulting entries.
  2. FCIV is used to build an XML database of the Hash values for all the instances of System.ini we found on the system.
  3. We can then extract the Hash values into a format that the BES Client process can read (FCIV stores them in a base64 encoded format in the XML file).
  4. After testing your Task on a system or two, target all of your suspected systems (I assume something like “All Computers”)

Now you simply need an Analysis to check for the Hash values you are looking for. You can use relevance for the Analysis similar to the following …

(Windows of Operating System) AND (exists file “HashList.txt” of folder “C:\Temp”)

with a property named …

Bad SYSTEM.INI

with a relevance of …

if (exists file “HashList.txt” whose (content of it contains “”) of folder “c:\temp”) THEN (substrings after " " of lines whose (it contains “”) of file “HashList.txt” of folder “c:\temp”) ELSE (NOTHING)

You can create a property for each file you are looking for as long as the files have been hashed by the initial Task. The relevance above should return the full path to every System.ini file that matches your “Bad” hash value. You can then enumerate the results using Web Reports, expanding the value of the “Bad SYSTEM.INI” property for all computers where “Bad SYSTEM.INI” contains “system.ini”.

3 Likes
9

You are a job saver. This is exactly what I needed. Thanks

10

A few minor tweaks I would suggest, @MaxAdmin from what @TimRice suggests.

I do not recommend using “C:\Temp”, instead use:

{pathname of folders "Temp" of windows folders}

Or use the BES Client Download folder for the EXEs and the BES Client Log folder for the logging. I typically use something like “install_NameOfSoftware.log” for installer logs and “results_NameOfScanner.log” for things like this.

The relevance for the task/fixlet should be pluralized: (relevance tweaks, and substituting my above suggestion)

(Windows of Operating System) AND (not exists files "results_HashList.log" of folders "Temp" of windows folders)

And for the analysis:

(Windows of Operating System) AND (exists files "results_HashList.log" of folders "Temp" of windows folders)

In the actual actionscript of the Fixlet/Task, you should use a parameter for the temp folder, like this:

parameter "tempFolder" = "{pathname of folders "Temp" of windows folders}"

And then use {parameter “tempFolder”} or similar in the actionscript so that you don’t have to repeat it over and over again, and so you can change it as needed.

See this example: http://bigfix.me/fixlet/details/6090 ( I needed to change the temp folder location many times in this example while debugging some issues, so this approach saved me tons of time )

Also, be sure to add the following to the actionscript: (after the prefetch / download statements)

action launch preference low-priority
1 Like