which is the best way to run a suspicious file?

Re: wich is the best way to run a suspicious file?

thanks
i will download them
thanks again

 

Re: wich is the best way to run a suspicious file?

You're welcome I just edited my last post, so please read it again.

P.S. I don't think I have the power to make sticky topics.

 

Re: wich is the best way to run a suspicious file?

Some posts have mentioned running the suspicious program inside a sandbox. This idea has merit, but also weaknesses, because the sandbox can deny functionality. For example, let's suppose the suspicious program attempts to load a driver. Sandboxie, in its default configuration, will simply block the driver load, so you have no idea what would have happened if the driver had loaded - perhaps it would have done legitimate actions only, or perhaps malicious behavior such as installation of a rootkit or altering of important system files. The point is, you just don't know what would have happened in a non-sandboxed installation because the sandbox restricted the behavior. If the suspicious program was something that shouldn't be loading a driver, then indeed the mere attempt to load a driver merits suspicion. However, some programs such as system utilities might legitimately need to load a driver. Therefore, I don't recommend using a sandbox or any other tool that restricts behavior without user alerts to test for the presence of malicious software. It's better, IMHO, to test within a virtual environment that does not restrict behavior, but also contains programs such as ThreatFire and antivirus that might warn about any bad behavior or code.

The idea of using rollback software is good, IMHO. I didn't mention it in my previous post because I haven't used any such software yet - I don't know of any free ones.

 

Re: wich is the best way to run a suspicious file?

Lists of Freeware Security Software

 

Re: wich is the best way to run a suspicious file?

I've rewritten my previous post here, with some new information added.

Here are the steps I recommend when you have a possibly suspicious program that you wish to install. I list the quicker or more definitive methods first. If, at a given step, you have determined that the suspicious program is malware, you don't necessarily have to do any of the steps that follow it. Before doing any of the following steps, make sure you have a recent system backup stored outside of your internal hard drive(s), perhaps burned onto DVD or on an external hard drive. DriveImage XML is a free program that can make system backups. For those who have UBCD for Windows, DriveImage XML is already on it. Few of these steps might be necessary if you're willing to run the program in a virtual machine only, or only in a sandboxed or restricted environment on your real machine; however, remember that it's possible that even a sandboxed program could do things such as send your personal documents to bad guys. All of the programs mentioned below are free.

a) Scan the suspicious program with up-to-date anti-malware scanning programs, such as anti-virus, anti-spyware, etc.

b) Upload the digital fingerprint of the suspicious file to Bit9 FileAdvisor. If the file is found in their database, you can maybe judge if the file is trustworthy by looking at the various websites that offer the exact same file. Also, according to the Bit9 website, you will be warned if the suspicious program is on their known malware list. Http://fileadvisor.bit9.com/services/help.aspx?topic=fileadvisor has a program that makes it easier to upload the digital fingerprint of a given file.

c) According to Panda, "79% of new malware is using some type of packing technique" - http://research.pandasecurity.com/archive/Mal_2800_ware_2900_formation-statistics.aspx. Malware programs use packing techniques to evade anti-malware signatures and also to make things harder for malware analysts. Some legitimate programs also use packing techniques to make their programs smaller. Since the use of packing techniques is so common in new malware, it is a good idea to see if the suspicious program is packed. You can use PeID to accomplish this. Choose the suspicious file in PeID and look at the textbox near the bottom of PeID's window. If it says 'not found', then PeID couldn't recognize what compiler or packer, if any, was used; this doesn't necessarily mean that the program is not packed, since new packers and variations of existing packers come out often. If the textbox near the bottom of the PeID window gives a specific description, then the compiler or packer used for the program is what's listed; if you're not sure whether the description is of a compiler or of a packer, then use Google to look up the description. If you got a description of 'not found', click on the chevron button in the lower right, and on the window that pops up, click the minus sign next to 'Entropy'; this gives a guess, which could be wrong, as to whether the program is packed by looking at how compressed it is. If you find that the suspicious program is packed, the likelihood of it being malicious can be considered greater, but it doesn't prove maliciousness. I recommend replacing the UserDB.txt file in the program's directory with a newer one that has signatures for newer compilers and packers; BobSoft has a replacement UserDB.txt file at http://www.peid.info/BobSoft/Downloads.html - make sure to unzip it in the program directory over the top of the existing UserDB.txt. Also, in PeID Options, you might want to uncheck 'Load Plugins' since some plugins will actually run parts of the suspicious program when used.

d) Let Mandiant Red Curtain inspect the suspicious file. This program can identify packers and give entropy information, similar to PeID, but the compiler and packer signature database is smaller than PeID's. Mandiant Red Curtain will also report other anomalies within the program's internal structure, and give an overall threat score based on multiple criteria. See the help file for threat score ranges.

e) If the suspicious file is under 10 MB, upload it to VirusTotal, which scans the file using a large number of anti-malware scanning engines. Http://www.virustotal.com/metodos.html has a program that makes is easier to upload files to VirusTotal. If nothing suspicious is found, and if you just got the suspicious program, you may wish to consider waiting a period of time, perhaps 30 days, in order for the anti-malware companies to update their signatures, and then upload the suspicious program again to VirusTotal. VirusTotal also lists packers detected.

f) Run the suspicious program in a virtual machine with ThreatFire and some anti-malware scanning engines installed. ThreatFire is a good choice because it alerts usually only when there really is a malware issue. I agree with a previous post, that if you're technically inclined, in the virtual machine also use a HIPS that detects single actions, such as Comodo Firewall 3, and always choose the 'allow' action for any HIPS prompts. Some other choices for technically inclined people include analyzing the program's actions with Process Monitor and Wireshark. Free virtual machine programs such as Virtual PC and VirtualBox exist. While the virtual machine is running, it's a good idea to turn on in the real machine a virtualization program such as Returnil or Windows SteadyState, or create an ISR (Instant System Recovery) program snapshot prior to running the suspicious program, in case the suspicious program in the virtual machine leaks out to your real machine. I don't know of any free ISR software.

g) Run the suspicious program in your real machine with ThreatFire installed. Also, if you're technically inclined, use a "single action" HIPS such as Comodo Firewall 3. Some other choices for technically inclined people include analyzing the program's actions with Process Monitor and Wireshark. Use a virtualization program such as Returnil or Windows SteadyState with protection turned on, or make an ISR (Instant System Recovery) program snapshot before running the suspicious program. Returnil can be used if the suspicious program doesn't require a reboot when installed, while Windows SteadyState can be used if the suspicious program needs a reboot when installed. Windows SteadyState uses a big permanent cache file to store changes. Returnil uses no cache file, since it uses existing disk free space and/or memory. Returnil protects only the partition on which the Windows system files are installed. The reason it is necessary to repeat tests similar to the previous step, but on your real machine, is that malicious programs can detect the presence of virtual machines and purposely alter their behavior while running in a virtual environment. The reason I recommended doing these tests in a virtual machine first (in the previous step) is that Returnil protects only the partition that has the Windows system files, and if the suspicious program steals your personal documents, hopefully there are few or no personal documents on your virtual machine. When done testing, you can turn off the virtualization program protection, or rollback to the ISR snapshot you created before running the suspicious program.

If you get past all of these steps with nothing suspicious noticed, then you can install the suspicious program in your real machine and use it. However, even passing all of these steps doesn't guarantee that the suspicious program can't be malicious.

 

Re: wich is the best way to run a suspicious file?

WOW
thank you so much
great
i think it should be sticky
it 's a great tutorial ! many user could learn by it

only thing is that all of these program need their drivers & service to work , and often they can give you some issue

 

Re: wich is the best way to run a suspicious file?

only 1 question about returnil

i installed it
and i should:
1) turn the protection OFF
2) click on SESSION LOCK
3) Run the suspicious file and see what it does
4) reboot ->return to the moment before i click to session lock
right?

 

Re: wich is the best way to run a suspicious file?

That's right. When you are using the session lock, the protection is actually on, but won't be on after you reboot. On the other hand, when protection mode is set to on, the protection is also on, and is also on when the machine is rebooted.

 

Re: wich is the best way to run a suspicious file?

You're welcome

 

Re: wich is the best way to run a suspicious file?

ThreatFire is really very cool!
and it's free

but i don't know how add to threat control trusty program
i tried to drag & drop and other way ,but I was not able to add program that i trust zone

it download preset , but does they work good?
in the custom rules i did not many many kind of rules , i found that i can make basic rules

and can i load threatfire when i want , or should it run only in auto mode , every time my xp start should start threatfire

 

Re: wich is the best way to run a suspicious file?

I believe you cannot exempt programs from ThreatFire's analysis, although you can for custom rules. However, if you get an alert for a program that you know is safe, you can choose to allow it always during the alert.

I would advise not making many or perhaps any custom rules in ThreatFire. The presets work fine. Currently in an alert, you are given only 2 options - allow or quarantine - there is no Deny option, although that is planned for a future release. A nice review of ThreatFire is at http://www.pcmag.com/article2/0,2817,2191336,00.asp.

ThreatFire always starts when Windows loads. Leave the protection level at 3.

 

Re: wich is the best way to run a suspicious file?

thanks it's very cool

can i change it ?
make threatfire starts when i want and not every time windows load?

 

Re: wich is the best way to run a suspicious file?

I believe you cannot do that.

 

Re: wich is the best way to run a suspicious file?

thanks
my last question in there a firewall "light" that download ruleset? rules pre made?

 

Re: wich is the best way to run a suspicious file?

Comodo Firewall 2.4 is a good general choice for a free firewall. Comodo Firewall 3.0 in antileak mode is intended to offer similar protection to Comodo Firewall 2.4, but I don't have personal experience with 3.0 antileak mode because I use its full protection. Comodo Firewall 2.4 has some premade rules, but I don't recall if you can download rulesets from others. In Comodo Firewall 3 you can import rulesets from others, but that might not be a good idea because your program locations might be different than the program locations on the machine of the person who made the ruleset.

 

Re: wich is the best way to run a suspicious file?

Light is in the eye of the beholder but outpost firewall does download rules.

Thanks,

Chris

 

Re: wich is the best way to run a suspicious file?

I found two free programs to help in identifying malware through behavior. SysAnalyzer, from http://labs.idefense.com/software/malcode.php, lets you do before and after snapshots, and then tells you what changed. From the program's website:

"SysAnalyzer can automatically monitor and compare:
Running Processes
Open Ports
Loaded Drivers
Injected Libraries
Key Registry Changes
APIs called by a target process
File Modifications
HTTP, IRC, and DNS traffic"

"SysAnalyzer also comes with a ProcessAnalyzer tool which can perform the following tasks:
Create a memory dump of target process
parse memory dump for strings
parse strings output for exe, reg, and url references
scan memory dump for known exploit signatures"

Another program I found is RAPIER, found at http://code.google.com/p/rapier/downloads/list. RAPIER is a branch of Intel's RPIER project. RAPIER automates the collection of various types of system information. Some of the tools RAPIER uses come from 3rd parties, and some of these need to be downloaded separately. The information collected can be used to look for signs of malware. The user chooses which of many modules to run.

 

I'd like to point out that the server part of RAPIER doesn't need to be installed in order for RAPIER to run.

Here are 3 screenshots of RAPIER's modules. The items marked with 'MISSING REQUIRED FILES' are those for which you need to obtain the needed tools separately.

 

For those of you who like to test malware in virtual machines, you might wish to look at the article 'On the Cutting Edge: Thwarting Virtual Machine Detection', found at http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf. Among other things, it contains some undocumented VMware settings that can limit the ability of any program to detect that it's running inside a VMware virtual machine. Malware sometimes changes its behavior when it detects it's running inside a virtual machine.

 

Re: wich is the best way to run a suspicious file?

It is good to backup your MBR before you try the Rollback. It will replace your MBR with it's special one.

 

I would like to help but need more specific information.

What is this file? You say run so I'm assuming it is an executable file?

Where did it come from? Is the source a trustworthy one?

Why do you say it is questionable ? Why does your work place force you to run a questionable file?

Is it tagged by an AV product?

If it is tagged, don't run it in your open system ever it could wipe you out!

Isolate it, quaranteen it and find out if it is safe or not before using it.

 

I research malware a lot and thats exactly why i don't use them. Instead i set up a virgin (used hard drive) and let them rip, thay way they can perform their anthics in reality and in real time on a real system not some artifical one that they can in many way easily evade.

 

Hi Easter:

Yes! FWIW agree 101%.

Those who test with these baddies in a system where they depend on SW to isolate the behavior are assuming tooooo much. If that system is also where real data lives well what more can we say?

 

Renowned antivirus researchers use VMs and I wouldn't dare to call them naive

 

Hi Lucas:

Wasn't thinking of the professional testers like that. You are right they wouldn't likely be "naive" to use your word.

My concern is and has been ordinary tester's excessive (my word) dependance on these SW products to "shield" and "isolate". No SW is 100% bug free, so IMO physical isolation of my user data or at least strong image backup is wise.

How would you proceed yourself? Would you test on these exe's on the same PC where you keep the family photos?