How to Deal with Malware

With this brief tutorial, here at UIC we are going to open a new Reversing Chapter that follows the new challenge promptly emerged in the last years: Malware Reverse Engineering.

This field is quite interesting and important for every serious RCE Community mostly because we are now facing an impressive boost of Malicious Executables and Malicious File Formats.
Major challenges in MWA (MalWare Analysis) are given by the fact that we are going to handle:

  • Hostile Code (commercial packers, custom packers, polymorphism, etc.).
  • Anti-Debugging Countermeasures.
  • Anti-Emulation Countermeasures.
  • Complex Interactions with Operating System components.
  • Exploit Technology.
  • Complex Network Structures like Botnets.

It’s now clear that we are facing a challenge that must be viewed in all its complexity, due to the global nature of Malicious Code. In other words, we have an entity specifically written to capture information, or turn victim’s systems into an attacking machine: a zombie remotely controlled. This mean that we need to gain a full understanding of the sample we are analyzing.

For this reason, we have a pretty important deflection respect to classical harmless software, which is given by the Security Risk of Dealing with Malware.

An example should well clarify this point; just imagine that you have an InfoStealer Trojan: this malicious application steals your sensitive data (Bank Credentials, Passwords, Sensitive Documents, etc.). Obviously during the debugging session you are really running this application, and if you need to take all the possible countermeasures when dealing with such high risk targets. If for some reason (human error or unexpected malware behavior) malware is executed, you are no longer a fighter and you become a victim.


How to Avoid this and other Risks?

The Virtual Machine

First Fundamental rule is to Deal with Malware into a Controlled Environment.

For no reason you should ever try to handle malware outside a Virtual Machine, from Sample Reception stage to Conclusive Analysis.

Your Virtual Machine needs to be Virgin, without any trace of Personal Information.

Never Check your Mail, store Personal Stuff in the Analysis Virtual Machine.

It should never to have the need of a Shared Folder between the Virtual Machine and Host Computer. Always drop your tools into the Virtual Machine before starting the infection.

Before starting analysis, close any shared folder, to avoid Malware Spread.

Samples Management

It’s clear that there are big differences between Harmless Files or Malicious ones.

  • Always keep your malware archive zip protected.
  • Modify file extension
  • exe → ese or ex_
  • pdf → pd_
  • doc → do_ , ppt → pp_ , xls → xl_

These simple precautions will avoid any accidental execution issue on your host machine.

Industrial Standard for Malware Archives is the password: infected.

All samples from UIC will follow this standard.

During Analysis

There are some good practices to keep in mind during analysis.

Often Malware makes use of TLS (Thread Local Storage) to Protect from Debugging Approach Analysis.

In Malware field, TLS are used to execute Malicious Code Before the EntryPoint Debugger Break, as you should imagine this uncontrolled behaviour could cause several problems.

How TLS Defence can be bypassed:

Into OllyDbg 1.10 By Setting “Debugging Options” -> “Events” the option System Breakpoint instead of “WinMain (if known location)”

Into OllyDbg 2.* By Setting Options -> “Debugging” -> “Startup and Exit” the Option TLS Callback

More Infos Here:

CodeInjection and RemoteThread Creation are widely used in most Common Malware.

Be aware of Probable MultiThread Nature of your Sample, keep track of Thread Creation, by setting up the Proper Debugging Events.

Do not put breakpoints and let run application if you don’t have a clear understanding of the whole structure, a missing breakpoint could lead to complete execution of malicious code.

Building Our Malware Lab

Now that we know how to deal with malicious files, we can build our Malware Lab.

Usually a Malware Analysis Station is equipped with:

  • Behavioral Analysis Tools
  • Code Analysis Tools

Entire lab is placed into a Virtual Environment.

Virtual Machine(s):

Behavioral Analysis Tools

Live Analysis

SysAnalyzer: is an automated malcode run time analysis application that monitors various aspects of system and process states. SysAnalyzer was designed to enable analists to quickly build a comprehensive report as to the actions a binary takes on a system.

Process Monitoring


Network Inspection


Snapshot Differentiation

Regshot: is an open-source (GPL) registry compare utility that allows you to quickly take a snapshot of your registry and then compare it with a second one – done after doing system changes or installing a new software product.

IPs, Domains, Network Structure Analysis

Robtex Online Service

Code Analysis Tools




PE Editor

Explorer Suite


We need to know what malware we are going to Reverse.

but… Keep in mind that in the worst cases your malware is FUD (Fully UnDetectable) VirusTotal analysis will show you a clean result.


Malware Lab is now complete; we need some easy piece of malware to start on.

Win32/Rbot.gen → is a generic detection for a family of backdoor trojans that allows attackers to control infected computers. After a computer is infected, the trojan connects to a specific IRC server and joins a specific channel to receive commands from attackers. Commands can instruct the trojan to spread to other computers by scanning for network shares with weak passwords, exploiting Windows vulnerabilities, and spreading through backdoor ports opened by other families of malicious software. The trojan can also allow attackers to perform other backdoor functions, such as launching denial of service (DoS) attacks and retrieving system information from infected computers.

  • Win32/Ambler → This type of trojan secretly installs spy programs and/or keylogger programs.
  • Win32/Tracur.B → This trojan component downloads and executes arbitrary files.

The KickStart package can be downloaded here.

How to Conduct a Malware Intelligence Plan

Malware world is often really complex, especially when viewed in its entirety.

Once you have finished the analysis of a sample, you have an amount of informations that need a well structured order.

In most cases, a single malware is only a child of a major structure driven by Cyber Crime. Complete profiling of structure is a pretty challenging task of Intelligence, that starts from the analysis of the single executable.

Let’s consider what are the most important questions to be answered.

  • How many variants of the same Malware?
  • The attacker used the same algorithm to pack the core executable?
  • If it changes, what does it change to, how often does it change ?
  • Could this tell us anything about how skilled the people behind it are?
  • Where does this connect out to?
  • Which Protocol Encryption uses? -> Build a Protocol Decoder

Answering to these question will tell us: what are the involved servers, involved people and what kind of criminal activity is.

Obviously the criminal activity is money-driven.

Structure knowledge will tell us:

  • Where does the money go.
  • Where money come from.
  • How much money circulates.