Sorting Out The Trash

Sorting out the malware trash Michael St. Neitzel, Mike@f-prot.com Out of Section IAT striped Invalid Opcode Corrupted Header Compiler Source Non-malicious Reference Non-Viral Commented Out

Why to sort out the trash

To archive more accurate testing results

To prevent exchanging trash with other testers

To prevent unneeded additional work for vendors

To prevent confusion regarding important sample detection

To improve your ability and to extend your knowledge

To keep your own test-sets “clean”

You collect trash at home, you remove it, so do it here too!

Essential tools

Disassembler / Debugger ( for example IDA )

Hex-Editor/Viewer ( for example UltraEdit )

Comfortable Filemanagement-Tool ( for example TC )

Virtual Machine for quick “Try & Error” purposes

Real Machine for Non-VM-Malware

Checksummer

Own developed tools (eg. Win32 Broken Filechecker)

If available professional Replication System

Database-driven trash system

Testing Network / Email / Internet Environment

Essential knowledge

Deep understanding of Operating System Architecture

Deep understanding of File-Formats (eg. Win32 PE)

Deep understanding of Assembly language

Deep understanding of Scripting languages

Classification and Determination of malicious software

Typical Malware “Variant-behavior” knowledge

The Rules

#1: Respect the Rules

#2: You must be able to Defend your decisions

#3: You must be able to sort the trash out yourself

#4: You promise to take this task serious

#5: Consider in difficult cases other opinions

#6: Spend extra attention to important samples

#7: Inform yourself about problems with specific malware

#8: Don’t relay only on automatic-sort-out

#9: Know the scan engine technologies

#10: Put questionable files into a specific set

Let’s get started: Bring it on

We have 4 different cases:

Non-Malicious at all

Clean Files

Malicious

Malware

Malicious only in combination with other files

So called “Helper Files”

“ Supposed to be malicious” files

Virus and Malicious Simulators

The Trial & Error Approach

Choosing the correct test environment

CPU Type (Example: Machine ID after PE Sign)

OS Version (Example: Some RTPS only work on 9X)

Real Machine vs. Virtual Machine

Configuring the correct test environment

Reverting Files / Registry

Setting Hooks / Logger

Activating Error Handling Hooks (eg. DLL not found)

Activating Virtual Network / Internet

Problems with Trial & Error

Date/Time Dependency (eg. Timed Downloaders)

Network Dependency ( eg. no real internet IP )

Randomized Dependency (eg. ExitProcess randomly)

File Dependency (eg. Wrong Service Pack Files )

Speed Dependency (eg. Virtual Environments)

Specific Action Dependency (eg. IE HTML Keylogger)

Event Dependency (eg. At least 5 open applications)

Registry Dependency (Won’t run if spec. Regkeys found)

Timed Duration Dependency (runs after spec. time)

Remote File Dependency (Tries to access remote files)

Missing Components (eg. Backdoor DLL not found)

The Disassembling Approach

PROS:

Reveals more hidden Secrets if done in a proper way

You can step with a debugger through the file

You don’t need a particular System Setup

CONS:

Not enough assembly knowledge leads to wrong results

You need to know deeply all system tricks

Time consuming task

Doesn’t work without unpacking / decrypting first

Conclusion: Disassembling should be used for files which activity is unclear on a “Trial & Error” System or gives errors on such a system. Priority of samples always over-rides the trial & error system. Important samples (including parasitic viruses) should be *ALWAYS* checked in a disassembler for the reason why they are not infecting or doing nothing.

The Live Example

Let’s see what happens

What should be sorted out?