Monthly Archives: February 2015

Static Malware Analysis – Find Malicious Intent

Any tool that you execute that analyzes a binary without running, it performs some kind of static analysis. Basic static analysis consist on producing information about a particular binary without running the code. On Win32 PE files there are a few steps that one can perform in order to find information about the malicious intent of a file in a very short amount of time.

First step, profile the file. Essentially this can be done by calculating the cryptographic hash of the file. This will compute a fingerprint that uniquely identifies the file. This unique digest can be used easily across different online tools like Virus Total, Malwr or Metascan-online to confirm malicious intent. Also, a file similarity index should be calculated using a process called fuzzy hashing or Context Triggered Piecewise Hashing (CTPH) – the original paper about this technique was written by Jesse Kornblum here -.   This fuzzy hashing technique is helpful to identify malicious files from the same family.

Second step is to run the strings command against the malicious binary.  The strings command will display printable ASCII and UNICODE strings that are embedded within the file. This can disclose information about the binary functionality.

Third step is to use some tool to analyze the Win32 PE headers. Extracting information from the PE headers can reveal information about API calls that are imported and exported by the program. It can also disclose date and time of the compilation and other embedded data of interest. Common Windows PE files extensions are .exe, .dll, .sys, .drv,.cpl, .ocx. When you compile a binary you can perform static linking or dynamic linking. Static linking means all the helper functions needed to execute the binary are inside the binary. On the other hand, dynamic linking is when the executable runs and resolve pointers to the helper functions at run time. In other words the binary contain library dependencies and these dependencies can be looked at in order to infer functionality trough static analysis. These dependencies are included in the Import Address Table (IAT) section of the PE structure so the Windows loader (ntdll.dll) can know which dll’s and functions are needed for the binary to properly run.

Let’s see how we can perform these steps in REMnux v5 using the PE file analysis toolkit.  The toolbox was created by the Brazilian security researcher Fernando Mercês and others. Is a very feature rich and usefully set of tools to analysis windows binaries. The toolkit runs on Windows, Linux and Mac. Some of the tools include:


To perform the first step, start by hashing the malicious binary in order to uniquely identify it. Pehash is a small tool that will produce the hashing of the file using different hashing algorithms including CTPH using ssdeep.

remnux@remnux:~/Desktop$ pehash torrentlocker.exe
file:             torrentlocker.exe
md5:              4cbeb9cd18604fd16d1fa4c4350d8ab0
sha1:             eaa4b62ef92e9413477728325be004a5a43d4c83
ssdeep:           6144:NZ3RRJKEj8Emqh9ijN9MMd30zW73KQgpc837NBH:LhRzwEm7jEjz+/g2o7fH

Then we can run Pestr to search for strings in the entire file.

remnux@remnux:~/Desktop$ pestr torrentlocker.exe

Another example would be to run the command “strings -a torrentlocker.exe”. The -a suffix will force the strings commands to scan the entire file and not only the data section.


From the output we can see the string MSVCRT.dll. This is meaningful because its the name of a Windows library i.e., the Microsoft Visual C Run-Time Library. We can conclude the program has been written with Visual C++. Another interesting string that corroborates this conclusion is the program database (PDB) file which holds debugging and project state information for Visual Studio projects. This could be used to attribution to some extent. Other information that we can see is the _controlfp or _oneexit strings which are names of Windows functions exported from the MSVCRT.dll. In this case the strings output doesn’t produce any more meaningful results because the malware is obfuscated or encrypted or packed. This means we might want to run the strings command after the malware has been unpacked – this will produce much more interesting results such as name of functions that interact with network, registry, I/O, etc.

The final step is to use Readpe tool to identify the dll and functions the binary needs to perform its function. The functions used can be shown in the form of both import by ordinal and import by name as you can see in the below picture. Normally the binaries contain a large number of imported functions. If the number is low we can conclude the binary is somehow packed, obfuscated or encrypted.


In this case the malicious file does not show much dependencies but, for example, it invokes GetProcAddress and LoadLibrary windows functions from the Kernel32.dll library. These two functions are very popular among packed malware because they allow the binary to load and get access to other Windows functions. In addition it invokes Windows functions from the MFC42.dll using its ordinal number. This can slow down the analyst but you can use tools like Dependency Walker to find out what the ordinal number corresponds to.

For Microsoft Windows enthusiasts, the same steps can be performed in order to achieve the same results. The first step on Windows can be performed using the Microsoft File Checksum Integrity Verifier. The tool can be downloaded here and below a sample usage


The second step can be performed on a Windows machine using the strings.exe utility that comes with SysInternals Suite.


And finally, the third step. One of the tools to perform this step is the Microsoft DUMPBIN utility that comes with the 32-bit version of Microsoft Visual C++. It is a command line tool to dump the different properties of a Win32 PE file for early evaluation of the file intentions. Below shows the DUMPBIN output of running the /dependents followed by the /Imports section.


The result is the same as the Readpe utility. The previous output show all dependencies from the malicious file and its Import Address Table.

Another alternative is to run the powerful and feature rich PEStudio tool created by Marc Ochsenmeie. The tool is free for non-commercial use and can perform static analysis on 32-bit and 64 bit binaries. The tool is actively maintained and contains great functionality that is worth to look. For example it can lookup Virustotal and query the different Anti-Virus engines using the file MD5. Other great feature is the Indicators. The Indicators show anomalies of the application being analysed e.g., the file not being digitally signed,


We have showed the three basic steps that are used to perform an initial assessment in order to find the program malicious intentions without running its code. In this case the malware is packed and obfuscated so we will need to dig deeper but I will leave that for another blog post.

Other tools and techniques exist and a great summary of the available tools for Windows is written by Lenny Zeltser here. Besides this, for the brave who want to go deeper, one of the best resources available to learn about Windows PE internals is the course “The Life of Binaries” created by Xeno Kovah and available on Other material of interest is the Microsoft Windows PE and COFF specification – available here . The PE Reference diagram created by Ero Carrera Ventura and the Black Hat 09 presentation “Undocumented PECOFF” from Mario Vuksan and Tomislav Pericin are also great material. Microsoft also maintains the Windows API reference site that can be helpful when looking at the Import Address Table.


Tagged , , , , , , ,

Security Hands-On-Training – Part 6 – Final

The previous blog post illustrated how someone with malicious intent could pull off a way to compromise a system. It starts by gaining access to the system using a SQL injection. After the initial access a foothold is established. Then the position is strengthen by uploading the tools of choice. Next the privileges are escalated and a shell with full systems privileges is gained.

However, this attack method might seem complex it would probably happen in case there is a motive or incentive for the attacker do it. An incentive to do such activity could be to steal trade secrets, intellectual property, credit cards or any other information that the attacker could monetize. Nonetheless, there are other motives that serve as an incentive for an attacker to compromise a system. Brian Krebs, a former Washington Post reporter, has putted together a great chart listing the various ways the bad guys can monetize hacked systems (Krebs, 2012).  One of the attack methods that tend to gain popularity is to use SQL injection for malware distribution. Basically, by introducing malicious code in the web server an attacker can turn the web server in a mechanism to deliver malicious code to browsers by taking advantaged of client-side vulnerabilities against unpatched browsers. This mechanism was used by the Asprox botnet (Borgaonkar, 2010) (Pelaez, 2008).  More recently this attack gained the connotation of watering hole or strategic web compromise when it targets a trustworthy web site (Kindlund, Caselden & Chen, 2014). Steven Adair and Ned Moran explain it perfectly in his article about trusted websites delivering dangerous results (Adair & Moran, 2012).

How does an attacker performs this? What are the mechanics behind such method? As the reader noticed in the previous attack scenario there were some key aspects that would be important for the attacker to be successful. One item is the xp_cmdshell stored procedure being enable or the ability to have an out-of-band channel to accelerate the speed of the time based SQL injection technique. But, in the watering hole attack scenario there is no need of any of those factors. The attacker will only need a SQL injection point and from there it can inject malicious script that will be appended trough out the database. As consequence, when a user browses to the web page, the data is retrieved from the database and rendered in the browser. Then the malicious code is executed putting him at mercy of all kind of client-side exploits.

Figure below illustrate these steps using a SQL statement that is famous due to the Asprox Trojan (Analysis, 2008) (Shin, Myers & Gupta, 2009). It  uses a special table in the SQL server sysobjects and syscolumns in an attempt to get access to the “user” defined tables and fields in the website’s database. Through a loop it goes through every table columns and appends a string containing the malicious <script> tag.

This SQL statement is encoded in a hex format and inserted into another SQL statement in order to evade defenses.  The reader can practice this technique and use SQLmap to invoke a SQL shell that allows to execute SQL statements.  Then this prepared statement is executed which will result in infecting the database data. For reference a picture of what DBA will see if he looks into is affected database is also shown.


From this moment onwards the web server is infected. When a user goes in and browses trough the infected web pages it will download and execute the evil Java Script within the <> tags (Stuck, 2009) (Mendrez, 2009). This evil script can do, among other things, scan the visitor machine for client side vulnerabilities and deliver the appropriate exploit payload. Similar to using guided missiles this attack can be very effective and is worth to mention James Lee presentation “Using Guided Missiles in Drive­bys  at Defcon 17“.

As demonstrated using this environment the reader could get a practical understanding of how a typical watering hole attack is executed. The next step might be to explore the client side vulnerabilities and exploits by taking advantage of the evil script that is inserted into the database.  The reader is encouraged to further learn, practice and explore this vector of attack with tools such as the Browser Exploitation Framework (BeEF) developed by Wade Alcorn and others, or  the Social Engineering Toolkit (SET) from David Kennedy.

Continuing the Journey

Even though the tools used are extremely functional and almost no knowledge is needed to run an exploit against a vulnerable server using SQLmap or Metasploit this is the first step in building hands-on information security skills. Some techniques used are low hanging fruit. Nonetheless, the reader should start with them in order to advance to more complex methods and techniques using incremental approach.  A proposed next step would be to further expand this environment to model business networks with end point and boundary defenses such as a Proxy, an IDS/IPS, a HIDS, etc. Also introduce Linux based systems such as an e-commerce and test other techniques and exploits (Rocha, 2012). As well, the reader could create scenario based challenges and simulations like Ed Skoudis promotes on his presentation “Using InfoSec Challenges to build your skills and career” that can emphasize the development of critical thinking (Skoudis, 2012).

Further practice reconnaissance, scanning, exploitation, keeping access and covering tracks will be doable. In addition to offensive skills the reader might want to practice defensive skills. When the attacker launches a specific technique  how does it look like? Which opportunities does it bring from a defender to identify and detect it from the network or database level? How does it look at the operating system level. How would the reader be able to better prepare, identify, contain, eradicate and recover from each one of these and other attack scenarios. Could the correlation between the logs from the DNS server and Database server be used to detect such incident? Which IDS signatures would be needed to detect this kind of traffic? This and other suggestions have been also encouraged throughout the previous chapters.

It’s this never ending cat and mice game which makes our industry a very interesting place to be at. Like when playing a game, It involves defenders trying to build a secure system, then how to innovate, progress and take it to the next level by circumvent those measures using different tools and techniques. Then the defender improves the system and so on. This healthy competition between the attacker and the defender will make us smarter and better at security. As Jon Erickson mention on his book “The net result of this interaction is positive, as it produces smarter people, improved security, more stable software, inventive problem-solving techniques, and even a new economy”.


Although there are plenty of books and open source information that describe the methods and techniques demonstrated, the environment was built from scratch.  The tools and tactics used are not new. However, they are relevant and used in today’s attacks. Likewise, the reader can learn, practice and look behind the scenes to better know them and the impact they have.

The main goal was to demonstrate that hand’s on training is a very valuable and cost efficient training delivery method that allows a better practical understanding on security. This method has advantages to build up your skills – not only from an incident handling and hacking techniques perspective but also from a forensics perspective.  One can practice and improve their ability to determine past actions which have taken place and understand all kinds of artifacts which occur within the outlined scenarios. For instance, one could simulate an actual forensic investigation!  On the other hand, from an Intrusion Analyst’s perspective the reader can capture the full contents of the network packets during the exercises and work on mastering his TCP/IP and intrusion detection techniques. In addition to that, the data set can be also feed to intrusion detection devices in order to measure how effective will they be in detecting the attacks.

Practice these kind of skills, share your experiences, get feedback, repeat the practice, grow to be proficient,  improve your performance and become fluent.




Krebs, B. (2012, 10 15). The scrap value of a hacked pc, revisited. Retrieved from
Borgaonkar, R. (2010). An analysis of the asprox botnet. Manuscript submitted for publication, .
Pelaez, M. (2008, 8 15). Obfuscated sql injection attacks. Retrieved from SQL Injection attacks/9397
Kindlund, D., Caselden, D., & Chen, X. (2014, 02). [Web log message]. Retrieved from
Adair, S., & Moran, N. (2012, 05 12). [Web log message]. Retrieved from
Analysis, X. (2008). Asprox trojan and . Retrieved from
Shin, Y., Myers, S., & Gupta, M. (2009). A case study on asprox infection dynamics. Manuscript submitted for publication, Computer Science Department, Indiana University, .
Stuck, F. (2009). An overview of a sql injection attack. Retrieved from
Mendrez, R. (2009). Another round of asprox sql injection attacks. Retrieved from
Rocha, L. (2012, Nov 23). Hands-on lab – ecommerce – part 1. Retrieved from
Skoudis, E. (2012, March). [Web log message]. Retrieved from

Tagged , , , , , , , , , ,