You are here:  Home  >  Evasion


Malware and Behavior Analysis

Malware and Behavior Analysis

When an event occurs most people / companies usually catch the effects of the event at the tail end. The point of discovery now becomes forensics because the damage is done. Our corpse that was riddled with disease is mutilated, violated, and ready to be incinerated. Not only does this apply to malware where most only discover the effects when the damage is done, but it also applies to behavioral analysis, a person is only aware of data theft when the consequences of the deed have become apparent to the organization.

The act of evasion is meant to cause those who are watching the system to believe that the “norm” is going on. Anomalies that exist outside of normal behavior tend to draw unwanted attention. Therefore, in both categories subterfuge is the order of the day. There is no one panacea to detect evasion. A one shop solution betrays the uniqueness of the situation.
In the dark land of subterfuge, it is the human condition that reigns. Keeping oneself undetectable is a combination of technique which is largely influenced by the nontechnical skill of personality. With that in mind, lets start of with some basic malware evasion techniques that are used to evade detection.

As a security researcher, one usually will test in a controlled environment, while I must confess it is possible to have a very good time testing on a live network, but this is not very conducive and could lead to unintended consequences of a grievous nature. Most testing for any type environment is done in a controlled environment.
Such a controlled environment can consist of a sandbox or a virtual machine where the network access is strictly controlled. Malware writers are clued into these environments and in order to stymie those in the field to attempt to reverse engineer their work, they develop countermeasures so that when the malware is running in the test environment or when the malware detects certain processes running.

As an example, lets look at Panda Banker. This is a banking Trojan which uses a variant of the Zeus source code. Many Trojans that are used to steal financial data bear their origins with Zeus, some of these variants that come to mind are Cridex and Dridex. Panda much like the other two has variants of the Zeus source code in it, this provides a common thread in helping understand what the malware does as well as how we can go about mitigating it.
Clever malware writers or data thieves (the ones that use scripting tools) code strings into their arsenal that check for countermeasures. If the countermeasures are there, the malware shuts down. The below are strings that the Panda Banker malware checks for:

Figure One:



Open File



















Figure Two:


Load Library


Create Mutex




Find Process Name





















Figure Three:


Open Registry




Call GetProcAddress



Figure two can be particularly vexing as some of the programs detected by this trojan are popular tools used in identifying what how the trojan goes about its dirty business in real time. Process Explorer (procexp.exe) and Process Monitor (procmon.exe) are Microsoft tools that allow one to track the progression of the malware after its launched.

Evasion techniques for malware are tricky. The only way to fight such a clever adversary is to make your test machine as close as possible to the real thing. With that being said there are two options we use, either or will do just fine.

Option A)               QEMU / KVM under Linux is a wonderful hypervisor to suit the purposes of a test environment. If you use the virtio drivers, you will notice a speed boost in hard drive activity. The hard drive any virtual environment will make or break it. There is nothing worse than a virtual environment where you open an application and you can feel your body age as you wait for the application to load or complete a process. If your environment is setup correctly then there is only one thing for you to do.

  1. Dump the virtual machine’s XML configuration

virsh dumpxml virtualmachinename > /tmp/virtualmachinename.xml


  1. Edit the dumped configuration. Our preference is always with nano as an editor.

nano /tmp/virtualmachinename.xml


By default, kvm passes a feature flag, viewable in ECX as the 31st bit after executing the CPUID instruction with EAX set to 1. Some malware likes to use this unprivileged instruction to detect if its running in a virtual machine. We avoid this by modifying the VM definition as follows:


Locate the line in the xml file below:


<domain type=’kvm’>

                       Change it to:

                      <domain type=’kvm’ xmlns:qemu=’http://libvirt.org/schemas/domain/qemu/1.0’>


                      Within the domain element, add the following:


qemu:arg value='-cpu'/>

                                <qemu:arg value='host,-hypervisor'/>



     Instead of using “host” choose from the list of CPU models displayed with the “qemu-    

     system-i386-cpu help” command


                     Save the XML file, and then import it:


                      virsh define /tmp/virtualmachinename.xml


At this point we now can fool the malware into seeing the CPU model we want.



Option A1)             If you use virt-manager to administer your kvm machines then the easier route would be to adjust the CPU type in the virt-manager interface. Follow the below:




Selecting the machine, we then hit Edit -> Virtual Machine Details

virtual-machine details

Hit the View pull-down menu, select Details

virtual-machine view-details

Under Configuration below the CPU features you will see Model. Select from the list below and you have now aided in deceiving the malware.


virtual-manager cpu list

Option B)               Use a real machine with a shadow copy of a clean operating system so you can recover quickly.


Now that we have defined a way to beat malware with countermeasures. Let’s take a deeper look at Panda Banker and what really happens when it paves its road.


Section One:


Overview –


Note: Our lab runs an internet simulator. It provides just enough for the malware to beacon once and our simulator drives traffic to itself to establish fake connections.


File Details –


The above basically details the file name with various fingerprints. The most important thing here for the casual operator is we have a Windows executable.


Section Two:


Road Traveled –


Note: I am going to bypass certain operations that most malware perform in favor of events where we pull details from the actual logs.


Part One:


Reads data out of its own binary image:

self_read: process: tdbanksetup.exe, pid: 6544, offset: 0x00000000, length: 0x00023000


Drops a binary and executes it:

binary: C:\Users\Administrator\AppData\Roaming\Adobe\Flash Player\f01b4d95cf55d32a.exe


This is in itself is bad. The binary has now dropped another and attempts to execute itself.



Part Two:


http_version_old: HTTP traffic uses version 1.0

ip_hostname: HTTP connection was made to an IP address rather than domain name

suspicious_request: http://config.edge.skype.com:8080/config.edge.skype.com:443

suspicious_request: http://client-office365-tas.msedge.net:8080/client-office365-tas.msedge.net:443

suspicious_request: http://settings.data.microsoft.com:8080/settings.data.microsoft.com:443

suspicious_request: http://sincirewdo.ru:443/sincirewdo.ru:443

suspicious_request: http://www.bing.com:8080/www.bing.com:443

suspicious_request: http://www.msftncsi.com/ncsi.txt

suspicious_request: http://g.live.com:8080/http://g.live.com/1rewlive5skydrive/ODSUProduction

suspicious_request: http://therepmeat.ru:443/therepmeat.ru:443

suspicious_request: http://fs.microsoft.com:443/fs.microsoft.com:443

suspicious_request: http://inference.location.live.net:443/inference.location.live.net:443

suspicious_request: http://cdn.content.prod.cms.msn.com:8080/http://cdn.content.prod.cms.msn.com/singletile/summary/alias/experiencebyname/today?market=en-US&source=appxmanifest&tenant=amp&vertical=sports

suspicious_request: http://cdn.content.prod.cms.msn.com:8080/http://cdn.content.prod.cms.msn.com/singletile/summary/alias/experiencebyname/today?market=en-US&source=appxmanifest&tenant=amp&vertical=news

suspicious_request: http://cdn.content.prod.cms.msn.com:8080/http://cdn.content.prod.cms.msn.com/singletile/summary/alias/experiencebyname/today?market=en-US&source=appxmanifest&tenant=amp&vertical=finance

suspicious_request: http://maps.windows.com:443/maps.windows.com:443

suspicious_request: http://nobotanri.ru:443/nobotanri.ru:443


The above notes traffic marked as suspicious. The majority of what is there is your typical noisy traffic generated by various Microsoft services. What stands out are the two requests to nobotanri.ru.


Part Three:


We see an alert noting the following:


The binary likely contains encrypted or compressed data


Part Four:


Installs itself for autorun at Windows startup


key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\f01b4d95cf55d32a.exe

data: "C:\Users\Administrator\AppData\Roaming\Adobe\Flash Player\f01b4d95cf55d32a.exe"


The malware is now installing itself in the startup folder of the operating system to establish persistence of presence.


Part Five:


Attempts to identify installed analysis tools by a known file location


file: C:\popupkiller.exe

file: C:\TOOLS\execute.exe


If you recall what you read earlier, to evade analysis, the malware will check for these tools to prevent the researcher from doing any type of analysis. Our report shows:


  1. Checks the presence of known devices from debuggers and forensic tools
  2. Detects the presence of Wine emulator via registry key
  3. Detects Sandboxie using a known mutex

Part Six:


Executed Commands –


"C:\Users\Administrator\AppData\Roaming\Adobe\Flash Player\f01b4d95cf55d32a.exe"

"C:\WINDOWS\system32\cmd.exe" /c "C:\Users\ADMINI~1\AppData\Local\Temp\updefeb9707.bat"


The commands extracted from the logs are simple yet potent in what they say. If you know nothing of how malware works on a granular level, if the behavior eludes you – the most import thing that we see here is:


  1. An executable in a Flash Player directory
  2. A batch file being processed launched by cmd.exe
  3. svchost.exe (A windows operating system file being launched)


Nothing here is good – it falls out of the norm.


Part Seven:


I have attached the behavioral analysis for the binary. It makes for good reading as you see what the malware does at the file system level. Column of prime interest are “Time” and “Arguments”. This data is good for plotting visualizations as well as understanding the road paved. (Appendix A)






Evasion is becoming common place in most malware. So, to analyze and dissect the attacker it is necessary to think proactively. Therefore, we must put ourselves out of the box of the malware developer. The lesson here is if your going to analyze malware you must literally establish your foundation. This structure must exist outside of the mind of the malware developer because you must be able to outthink and exist outside of their frame of thought as to what they are trying to achieve and why. Take care to stay away from common place tools, there is a place for them in analyzing malware but like the human condition – never use a one size fits all – otherwise you will always be surprised.


Data Theft


While we would never minimize the importance of good cybersecurity regarding malware, there exists another area that is just as nefarious and it is hiding in plain sight. Most small businesses are more likely to suffer from some level of data theft as opposed to a mass attack from external sources. The chances of that data theft occurring internally is even higher. Small businesses are more likely to fall victim to both internal and external theft due to their lack of cyber security. Most small business owners think such service is out of their reach. Theft by employee due to lack of monitoring, no behavior analytics, as a small business you have been made to believe that this is out of your reach.  What is more nefarious about data theft is that for the most part it happens in plain sight. Here we must wage combat from a different perspective. As mentioned above, like malware data theft is particular to the entity involved, so there is no “one size fits all approach. For this scenario we will deal with the employee sitting at the desk who uses the innocuous USB drive to take something that he/she has no business taking.

For detection, two areas are important. First your logs are essential, there is no way to detect or even find the information without making sure you are logging the appropriate data. Secondly alerts are necessary because if you are not alerted then it becomes an issue of forensics. Let’s see than what is displayed and available to the security monitor to prevent your data from leaving the building.



Part One:


The first thing we note is distressing. At this point if this is not the norm in your organization you should investigate immediately. For the most part your employees should not be bringing anything external to connect to your computer.

We are presented with Event ID: 6416 which is “a new external device was recognized by the system”.


Figure One:

event id 6416

There is nothing good about this. An external drive has been attached to a computer in your organization, which means unless this is the norm someone is doing something they shouldn’t be. I liken this to identifying patient zero. Get to that first and you most likely will contain the malady

Figure 1a:

alert 6416

The above is how the event looks in our Alert system. It is the full message of the event which is noted in our system via the Event ID: 6416


As we trek further down the path that is laid on the dirt road we see via the same Event ID that a volume has been assigned. After this event a driver letter usually follows.

Figure Two:


Figure 2a:


There also exists another Event ID which indicates that drivers are being loaded for a storage device. Event ID: 2003 falls under the DriverFrameworks area and gives us a good window into Power Management Operation.

Figure Three:

Event id 2003

This is an interesting event as the Task Category says it all “Loading drivers to control a newly discovered device


Figure 3a:


Two fields in our alert system bear importance




The UMDF Host Process ({f92c91d9-ca7a-4f14-ad43-bc0f1d1399a4}) has been asked to load drivers for device SWD\WPDBUSENUM\_??_USBSTOR#DISK&VEN_GENERIC&PROD_STORAGE_DEVICE&REV_1404#6&93879B5&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}.




Loading drivers to control a newly discovered device.

Part Two:


At 2:41:54 A handle to an object was requested, this would be the file “sd-sports-discovery.pdf” The process ID that initiated this was explorer.exe. So, let’s look at this carefully –


  1.  At 2:41:43 an external USB drive is inserted into the computer named caprica
  2. At 2:41:54 a handle to an object which is a file that must be some sort of legal discovery is accessed with permissions
event id 4656



Why am I stopping here? There is an obvious reason, this is not meant to trace the file nor is this a discussion on forensics. There is a place for that and we do quite a bit of it. The point here is to show the first event followed by the second in the time span shown in which you must act.  The Event ID before this one would have been “An attempt was made to access an object”. What we have bared witness to is the Alert System telling us, an external drive has been established on a computer, then on that very computer a file is accessed. By the time you are alerted to the file being copied, the USB drive is removed, and the damage is done.


The point we are getting across here is that we need to promote a new mindset. If your operator gets an alert that an external drive has been connected, and this is not the norm in your organization, anything that comes up after this notification is going to end up being forensics because if you wait there to sit and watch, for the most part you will not make it to the computer before that data leaves the building. This may not be the case if you are watching this person and want to catch them in some elaborate confrontation at the elevator or front door, however for the most part in order to contain the situation, much like malware, it should be addressed immediately without hesitation


That is the whole point of this soliloquy. Don’t sit back and let it happen while you record – Act. You get a notification, run to the computer, you see an alert that someone is running something that they shouldn’t, Act. All the tools in the world mean nothing unless the operator is vigilant. Evasion can happen in plain sight for the following reasons:


1.The person executing the malware in your environment is aware of what is being used on the desktop. You can infer at this point that either he is internal to your organization or is an entity that has committed some level of reconnaissance on your company. The techniques in the malware may even just apply to the industry that you are in, either or – the individual using the malware has some degree of knowledge and can operate in the open as no is watching.


2. The disgruntled employee who works for you and is removing data via external drive is not a malware developer but knows your environment as they work for you. There is no science to be found here, no subterfuge, or clever scripting to avoid tools on your desktop. All it is, a person sticking in a USB drive into the computer they use everyday and removing data that belongs to you.


Evasion takes many forms and for the most part occurs in plain sight. A combination of the correct mindset and the right tools is necessary to combat this behavior. A man can sell you a wonderful set of tools, beautiful graphs, signatures that are updated every third quarter moon, but that means nothing because if you do not understand the human mindset than you truly can never protect your data. We will be exploring different types of behaviors that involve subterfuge and evasion in trying to infect the corporate infrastructure and steal your data.