How to Deal with Malware
From UIC
How to Deal with Malware
Contents |
| How to Deal with Malware | |
|---|---|
| Author: | Evilcry |
| Email: | |
| Website: | |
| Date: | 19/11/2010 (dd/mm/yyyy) |
| Level: |
|
| Language: | English |
| Comments: | A brief introduction to malware analysis |
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
Code Analysis Tools
Debugger(s)
Disassembler
PE Editor
Identification
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.
KickStart
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.
Disclaimer
I documenti qui pubblicati sono da considerarsi pubblici e liberamente distribuibili, a patto che se ne citi la fonte di provenienza. Tutti i documenti presenti su queste pagine sono stati scritti esclusivamente a scopo di ricerca, nessuna di queste analisi è stata fatta per fini commerciali, o dietro alcun tipo di compenso. I documenti pubblicati presentano delle analisi puramente teoriche della struttura di un programma, in nessun caso il software è stato realmente disassemblato o modificato; ogni corrispondenza presente tra i documenti pubblicati e le istruzioni del software oggetto dell'analisi, è da ritenersi puramente casuale. Tutti i documenti vengono inviati in forma anonima ed automaticamente pubblicati, i diritti di tali opere appartengono esclusivamente al firmatario del documento (se presente), in nessun caso il gestore di questo sito, o del server su cui risiede, può essere ritenuto responsabile dei contenuti qui presenti, oltretutto il gestore del sito non è in grado di risalire all'identità del mittente dei documenti. Tutti i documenti ed i file di questo sito non presentano alcun tipo di garanzia, pertanto ne è sconsigliata a tutti la lettura o l'esecuzione, lo staff non si assume alcuna responsabilità per quanto riguarda l'uso improprio di tali documenti e/o file, è doveroso aggiungere che ogni riferimento a fatti cose o persone è da considerarsi PURAMENTE casuale. Tutti coloro che potrebbero ritenersi moralmente offesi dai contenuti di queste pagine, sono tenuti ad uscire immediatamente da questo sito.
Vogliamo inoltre ricordare che il Reverse Engineering è uno strumento tecnologico di grande potenza ed importanza, senza di esso non sarebbe possibile creare antivirus, scoprire funzioni malevole e non dichiarate all'interno di un programma di pubblico utilizzo. Non sarebbe possibile scoprire, in assenza di un sistema sicuro per il controllo dell'integrità, se il "tal" programma è realmente quello che l'utente ha scelto di installare ed eseguire, né sarebbe possibile continuare lo sviluppo di quei programmi (o l'utilizzo di quelle periferiche) ritenuti obsoleti e non più supportati dalle fonti ufficiali.