Malware Lab Setup for Static Analysis

[Deque]

Malware Lab Setup for Static Analysis

Most of the time you will want to do both static and dynamic analysis. So it is probably the most comfortable way to analyse every sample in a Virtual Machine (VM) with a Windows operating system installed. Nevertheless I want to discuss the possibilities that you have with static analysis while not using a VM.

Static analysis is often seen as safe, because it does not require to run the samples that you analyse. A lot of people perform static analysis on their working machine. However, there is still a risk of infection via

• accidental execution of the sample
• exploitation of static analysis tools, explorer or any other program that is used to view the file

If you use a different operating system for analysis than the malware's target system, you are pretty safe from infections. You will only have to be careful with multipartite and platform independend samples (e.g. executable .jar files).
So if you have a Unix based system to analyse Windows targeting malware, you are good to go for static analysis.

Note: In the following I will only discuss Windows targeting malware, because it is much more common.

If you are only comfortable with Windows, prefer to set up a dedicated analysis machine that won't destroy your life work if it gets infected, e.g. an old computer that you don't use otherwise. I also recommend this approach for dynamic analysis in a VM with a Windows based host system.

With a Windows system there is no 100% safe way to avoid possible exploitation of static analysis tools, unpacking tools or Windows explorer. If you use a Windows system for static analysis, you will always have a slight risk for infection.

Accidental execution is a big problem with static analysis on Windows. It may happen by:

• double-clicking the sample accidentally
• dragging the sample into the command prompt window to execute an analysis tool on it; then pressing enter. Because the focus will still be on the explorer window you will execute the sample
• reading code of the sample and accidentally clicking on malicious URL while trying to copy it for further analysis

Although I do not recommend to use a Windows system outside of a VM for static analysis, there are sometimes reasons you might still want to do that.

In any case, take the following precautions to minimise the risk.

• Follow general guidelines for a secure system (see 1.1.)
• Make sure that all file extension are shown (see 1.2.).
• Save the sample in a folder with permissions that disallow running the file (see 1.3.).
• Rename all samples with executable file extensions (e.g. .exe, .bat, .cmd) immediately to nonexecutable extensions (e.g. .ba1, .cm1, .vir) or remove the extension entirely (see1.4.).
• Use the command prompt instead of Windows Explorer (see 1.5.)

I put instructions below for each point on the list.

1.1. Secure your System

• Update your operating system, Antivirus, all internet facing programs, and document viewers regularly.
• Don't use Windows XP, it is not supported anymore
• Disable autostart.
• Don't give global admin rights do your regular user account.
• Use an Antivirus. Tip: Make a rule to exclude your malware sample folder from real-time scanning.
• Don't leave your computer unlocked if there are other people around, they might execute the samples accidentally.
• If you save malicious samples on your USB stick or other media, clearly mark the device that it contains malware.

1.2. Show All File Extensions

• Press the Windows Key and r on your keyboard at the same time. Type Control Folders and click OK.
  
• Click View. Under Hidden files and folders:
  
• Remove the checkmark next to Hide extensions for known file types.
  
• Click Apply followed by OK.

1.3. Remove Execution Permissions from Sample Folder

Create a folder to put all your samples in. Give the folder name that makes it clear that there is malware in it, e.g. "malware", "virus samples". Then follow the steps below to set the ACL.

• Right-click on the folder. Select properties.
  
• In the security tab click on the Advanced button.
  
• Click Change Permissions.
  
• Uncheck Include inheritable permissions from this object's parent
  
• In the new dialog click Remove
  
• Click Add, a new dialog opens, type Everyone
  
• In the Allow column check the Full Control checkbox
  
• Check Traverse folder/execute file in the Deny column
  
• Click Ok, click Apply
  
• A warning will appear, click Ok.

Now test the settings. Copy a harmless executable into your folder, e.g. cmd.exe, then try to run it. It should not open.

1.4. Disarm File Extensions

Copy the following Batch script into Notepad and save the script as disarm.bat.

Code: (batch) [Select]

@echo off
:: disarm directory args1
for /F "delims=" %%f in ('dir /b /s %1') do (
        :: skip folders
        if not exist "%%~f\" (
                :: skip .vir extension
                if not ".vir" == "%%~xf" (
                        move "%%~f" "%%~f.vir"
                        echo "%%~f" renamed to "%%~f.vir"
                )
        )
)

This script will append .vir to all files in a given directory. If you get a bunch of samples, running this script should be the first thing to do. It is better than trying to rename the extensions manually as you will have to right-click each file and might accidentally execute it while doing so.

You call the script from the command prompt as follows:

Code: [Select]

disarm.bat <folder>
In case you executed the script on the wrong folder, you can revert the changes with the following script:

Code: (batch) [Select]

@echo off
:: revert disarm
for /F "delims=" %%f in ('dir /b /s %1') do (
        :: skip folders
        if not exist "%%~f\" (
                :: remove .vir extension
                if ".vir" == "%%~xf" (
                        move "%%~f" "%%~df%%~pf%%~nf"
                        echo "%%~f" renamed to "%%~df%%~pf%%~nf"
                )
        )
)

1.5. Prefer the Command Prompt over Windows Explorer

The reason for this is simple. The Windows Explorer is prone to being exploited. E.g. there has been malware that was able to execute its code by merely navigating files in Windows Explorer, because the process of loading the icons was vulnerable. So you should prefer to use the command prompt to navigate, unpack and investigate samples.

If you have any choice between using a GUI or a CLI version, prefer the latter.
For example if you use the GUI version of WinRar, you can be tricked into executing malware with it, if a malicious file has a folder icon and you happen to click on that.

Note: Before you use any tools for unpacking make sure that these are static unpackers. A lot of unpackers work dynamically, thus, will execute the file and dump the memory. You must use dynamic unpackers only in a VM!

[TheWormKill]

I really like your article (as always). I'd just add a bit to the note on unpackers: There is also an option of
using an emulator (PyEmu comes to mind) to let a malicious program unpack itself and dump the memory
afterwards, without infecting the system. Yet, your point about exploits targeted at the software you use
for analysis still remains. I'll just leave this here and let you (and others) judge, please correct me in case I
am mistaken.

[Deque]

I really like your article (as always). I'd just add a bit to the note on unpackers: There is also an option of
using an emulator (PyEmu comes to mind) to let a malicious program unpack itself and dump the memory
afterwards, without infecting the system. Yet, your point about exploits targeted at the software you use
for analysis still remains. I'll just leave this here and let you (and others) judge, please correct me in case I
am mistaken.

Thanks for your feedback.
Of course emulators work too. But I would not place them in the category of static analysis.
I will mention them in the counterpart article about a dynamic analysis lab setup.

[unedone]

Ty for this article !

What do you about recent Cuckoo SBoxing evasion (refer to Hacking Team exploit)  ?

[Deque]

Ty for this article !

What do you about recent Cuckoo SBoxing evasion (refer to Hacking Team exploit)  ?

You are welcome.
The verb in your question is missing, so what exactly is your question?

[kowalski007]

Hi everybody!

I want to start with Malware Analysis on windows os, I guess I'm gonna start with dynamic and then pass to static, anyway, my question is, which operating system is recommended for this?, I am thinking in using a virtual machine with windows server 2008r2 and isolated network, but not sure if in this case it would be better to try with windows 7 or windows 8.1, what do u think?

[Deque]

Hi everybody!

I want to start with Malware Analysis on windows os, I guess I'm gonna start with dynamic and then pass to static, anyway, my question is, which operating system is recommended for this?, I am thinking in using a virtual machine with windows server 2008r2 and isolated network, but not sure if in this case it would be better to try with windows 7 or windows 8.1, what do u think?

This should answer your question: https://evilzone.org/tutorials/malware-lab-setup-for-dynamic-analysis/

I would not start with dynamic analysis. Static analysis will give you an idea what to look for, it is the first thing that most analysts do.

[kowalski007]

Thanks Deque... but, if I will start with static analysis, should I learn first assembly programming or reverse engineering in general and then go to static malware analysis, or I can start with some tutorials and books for malware analysis and learn in the way about RE and Prog?

I was looking at this book http://beginners.re and not sure if I should start in that way.

[Trevor]

Thanks for the nice and informative article.

I would like to ask, what are your view of static vs dynamic analysis. Which you generally tend to prefer ?

My views are that today thousands of samples are generated each day. So static analysis is not always a viable option for mass analysis. We can use dynamic analysis to get a high level overview of the malware. On this information we can base our static analysis. For controlling execution, we can use PIN tool. Even running the sample in modifed Wine can be helpful.

Apologies if my question offend you in any way.

[Deque]

Thanks Deque... but, if I will start with static analysis, should I learn first assembly programming or reverse engineering in general and then go to static malware analysis, or I can start with some tutorials and books for malware analysis and learn in the way about RE and Prog?

I was looking at this book http://beginners.re and not sure if I should start in that way.

Does not matter. All roads lead to Rome.
See, malware analysis is a very broad field. You can analyse a lot of samples without any assembly knowledge, even PE samples (because a whole lot are .NET assemblies or wrappers for AutoIt, Batch, INNO scripts, NSIS, Jar files, etc etc, in my estimation these exist in higher numbers than native samples).

But analysis via a debugger like OllyDbg or IDA is like the surpreme discipline. It is what most people associate with malware analysis and what people expect a malware analyst to be skilled with.

You should start with the thing that interests you the most.
RE and assembly is great, because being able to do almost everything with a native file, seeing the inner workings, patching it to your needs, is an empowering feeling. Especially if you like to crack hard nuts, because often you need patience and stubbornness to find the solution.

Basic static analysis is something that I consider a great time-saver. E.g. if you analyse a PE in OllyDbg without realizing that it is an SFX file, you will waste your time.
Same is true for any wrappers.
You need to be able to determine first, what sample you have there and what tool is the best for analysis. That's why I think you should start with the basics in static analysis or you will get lost with unknown samples.

I read a bit through beginners.re. It is a good book, but maybe a bit too hard without assembly knowledge.
Lena's Tutorials are a great source in my opinion: https://tuts4you.com/download.php?list.17

-------------------------------

Thanks for the nice and informative article.

I would like to ask, what are your view of static vs dynamic analysis. Which you generally tend to prefer ?

My views are that today thousands of samples are generated each day. So static analysis is not always a viable option for mass analysis. We can use dynamic analysis to get a high level overview of the malware. On this information we can base our static analysis. For controlling execution, we can use PIN tool. Even running the sample in modifed Wine can be helpful.

Apologies if my question offend you in any way.

You mix up mass analysis by automated systems and analysis of individual samples by malware analysts.
Both are entirely different questions. Let me answer that related to individual sample analysis.
When I get a sample, I have often no information about it. A lot of them are sent to us without any comment.
I already addressed this in my previous post, but I need to find out what that sample is, I need to get an overview to answer the following questions:

What file format is it?
How was it compiled?
Is it packed? Can it be unpacked?
Is it signed?
Is it already detected by AV vendors?
Does it have info about the author or application name?

All of these are answered with static analysis, so static analysis is what I do first. Always.
And sometimes I can stop right there.

For certain samples I rarely use dynamic analysis. These are e.g. samples that are  decompilable or wrappers I can unpack statically, samples that are already in a readable programming language (JavaScript, PHP, ...) or that have easily extractable code (Macro malware). For these cases I will not go through the struggle of transferring the sample to the dynamic analysis machine and waiting for the VM to start up. I just look at the code and decide.
I would estimate that about 50 percent of all samples don't need dynamic analysis.

An exception are PUPs, which I almost always analyse dynamically (unless I know them already). Often I need to check the look and feel of installation programs, whether they try to trick the user into accepting offers, see if some of their buttons or check-boxes are greyed out, if offers are opt-in or opt-out, and whether it is possible to decline third-party offers at all. PUPs are usually a PITA.

[Trevor]

Thanks Deque, for your reply.

So static analysis is the way to go and preferred.

However if the malware comes heavily multi stage encrypted, and the decrypting logic is complex, would static analysis be still viable. We can run the malware until the decryption is done, take a memory snapshot, and static analyze it further. Yes, sometimes decryption can be emulated, but emulators are not perfect.

Malware can also be obfuscated with opaque predicates, cfg flattening, embedded vm, etc.. which can make an analyst's task nightmare and time consuming. I think in such cases dynamic analysis holds the edge.

[Deque]

So static analysis is the way to go and preferred.

No. I only said that I start with it and that it can often be enough.
You should use both if necessary. This is no competition of methods. You just need to know when it is appropriate to use which.

However if the malware comes heavily multi stage encrypted, and the decrypting logic is complex ...

I would find out first if it is packed and if that is a known packer via static analysis.
Then I would dynamically analyse.

[ducksauce88]

Static analyzing seems like there is more risk involved, I don't understand the benefit of performing the analysis statically when it could be done dynamically in a safer environment.

[TheWormKill]

Static analyzing seems like there is more risk involved, I don't understand the benefit of performing the analysis statically when it could be done dynamically in a safer environment.

Quite the contrary, if you don't run anything malicious, your risk is much lower. That's common sense, if you ask me. That's also the main advantage about that approach. A "safe" environment with no risks for dynamic analysis is pretty hard to achieve.

[ducksauce88]

Quite the contrary, if you don't run anything malicious, your risk is much lower. That's common sense, if you ask me. That's also the main advantage about that approach. A "safe" environment with no risks for dynamic analysis is pretty hard to achieve.

Gotcha. Thanks for the clarification.

Sent from my Nexus 6P using Tapatalk