Welcome to My Blog

First thanks for visiting my blog and I hope you find this information useful and informative. For those of you that followed my old blog (markmorgan47@wordpress.com) thanks for coming over to my new blog. I decided to change the name to something else and get my name out of the title. For those of you who know me then you are probably aware that I switched jobs and moved back to the Washington DC area. Yes I made the move to Guidance Software after considering all my options available to me. Yes I will talk a little about Encase as well as other forensic tools. Even though I do work for one of the well known forensic software vendors, I am still of the opinion there is no one tool that does everything. The forensic investigator must have a multitude of tools to get the job done. If anyone has any questions that want to ask me about encase feel free but remember I am not a help desk but I will help anyone on general questions if I can. I will write my first post this weekend which will be about a new feature that guidance software just developed. So register on my blog or follow me so you do not miss any of these posts.

How to identify Malware Behavior

First, many times we may be looking for malware for different reasons. One reason would be that we suspect that a system may be infected with malware, while another may be that by looking for malware, we’re attempting to nail down an intrusion or compromise (like following the trail of artifacts back to the original compromise vector), with the malware being a byproduct of the intrusion.

Another thing to keep in mind is that malware, in general, has four main characteristics:

1. An initial infection vector – how it got on the system in the first place; this can be through browser download (even on a secondary or tertiary level), email attachment, etc. Conficker, for example, can infect a system when the user opens Explorer on drive (USB thumb drive, mapped share, etc.) that has been infected. In some SQL injection compromises, I’ve seen malware placed on a system by the intruder sending tftp commands or creating and launching an FTP script, all via SQL injection. I’ve also seen the bad guy load the malware into a database table in 512 byte chunks, and then have the database reassemble the file in the file system so they could launch it.

2. Artifacts – what actions does the malware take upon infection and what footprints does it leave? Many time, we can determine these ourselves through dynamic malware analysis, but often its sufficient (and quicker) to use what’s available from AV sites. Sometimes these “footprints” can be unique to a malware family (Conficker, for example). Also, these artifacts do not have to be restricted to a host; are there any network-based artifacts that you can use when analyzing logs?

3. Propogation Mechanism – How does the malware get about? Is it a worm that exploits a known (or unknown) vulnerability? Or is it like Conficker, infecting files at the root of drives and adding autorun.inf files? Understanding the propogation mechanism can help you fight the tide, as it were, or develop a mechanism to block or detect further infections.

4. Persistence Mechanism – As Jesse Kornblum points out in his “Rootkit Paradox” paper, malware likes to remain persistent, and the simple fact is that there are a finite number of ways to do that on a Windows system. The persistence mechanism can relate back to Artifacts; however, this would be an artifact specifically intended to allow the malware to survive reboots.

These characteristics act as a framework to help us visualize, understand, and categorize malware. Over the years, I have used these four characteristics to track down malware and help others do the same. In one instance in particular, after a customer had battled with a persistent (albeit fairly harmless) worm for over a month, I was told that they would delete certain files, reboot the system, and the files would be back. It occurred to me that they hadn’t adequately tracked down the persistence mechanism, and once we found it, they were able to clean their systems!

Okay, so how can we go about tracking down malware, detecting its presence? I’m going to start with the idea that we have an acquired image, and we need to determine if there’s malware on the system. I’m going to list several mechanisms for doing so, and these are not listed in order of priority. It will be incumbent upon you, the reader, to determine which steps work best for you, and in which order…that said, away we go!

Targeted Artifact Analysis

A lot of times, we may not know exactly what we’re looking for, but if we know the persistence mechanism or other artifacts of malware, we can do a quick, surgical scan that malware. Tools such as RegRipper can make this a fast and extremely easy process (remember, for live systems, you can use RegRipper in combination with F-Response!). Take Conficker…while there are changes in artifacts based on the variant, the set of unique artifacts is pretty limited. As the variants have changed so as to obviate both AV scans and hash comparisons (at this point, everyone should be aware that hash comparisons for malware are marginally less effective than AV scanning with a single engine), artifacts have remained fairly static (Registry modifications) with some new ones (Scheduled Task) being added. The addition of unique artifacts helps narrow down the false positives.

Log Analysis

There are a number of logs on Windows systems that may provide some insight into malware detection. For example, maybe the installed AV product detected and quaratined a tertiary download…depending on the product, this may appear in the AV product logs as well as the Event Log. Or perhaps the AV scanner’s real-time protection mechanism was disabled and the user ran a scan at a later time that detected the malware. Either way, check for an installed AV or anti-spyware product, and check the logs. Also, examine the Event Logs. And don’t forget mrt.log!


Another way to go about detecting the presence of malware on systems is to scan for it using AV products. Yes, there are commercial AV products available, but as many have seen over the past couple of months, particularly with Conficker and Virut, sometimes using just one commercial AV product isn’t enough. The key to running scans is to know what the scan is looking for so that you can better interpret the results.

For example, look at tools such as sigcheck and missidentify; both are extremely useful, but each tool looks for certain things. Another scanning tool that can be extremely useful is Yara, and anyone looking at using Yara should consider using the Yara-Scout Sniper release from the illustrious Don Weber! Yara can use packer rules (from the public PeID signatures) to detect packed files, and Don has added fuzzy hashing to Scout Sniper.

As a side note, while fuzzy hashing is obviously predicated on having a sample of the malware to hash, it is still a much preferable technique over “normal” hashing using MD5 or SHA-1 hashes. In one instance, I had two examinations about 8 months apart where I found files of the same name on both. Traditional (MD5) hashes didn’t match, but using ssdeep, I was able to determine that the files were 99% similar.

So, other than scanning for not-normal files (with “normal” being somewhat amorphous), there are other ways to scan for possible malware infections. With the amount of malware that subverts Windows File Protection (WFP) in some manner, tools like wfpcheck can be used to determine if something on the system modified any of the “protected” files.

But again, keep in mind that scanning in general is a broad-brush approach and scans don’t find everything. The idea is to have some idea of what you’re looking for, and then selecting the proper tool (or tools) to build a comprehensive process. As part of that process, you’ll need to document what you did, what you looked for, and what tools you used…because without that documentation, how to describe what you did in a repeatable manner, and how do you go about improving your process in the future?


I have been teaching myself how to analyze memory dumps from various window machines.  Memory analysis has come a long way in a very short period of time and there are tools out there that do a very good job of parsing through these memory dumps.  So I thought I would provide a little information to the community on what tools are out there and some basic uses of these tools. 


Acquistion of Memory


win32dd-This is the easiest of the command line tools and probably one of the most used “open source” tools out there.  The basic syntax is as follows:


win32dd (output file)


That’s it, all you need to do is provide the name of the output file and where you want it saved.


There are also some “commercial” products out there like (Encase and FTK) but I will only be discussing “open source” tools in this blog.


Analysis of Memory

The following tools are the ones that I have used in the past and I realize there are probably more out there.


Memparser-This is a python script and can be found in the SANS Sift Workstation and is only used against Windows 2000 machines.

Memoryze-This tool was created by Kevin Mandia’s company “Mandiant” and is a free dowload.  This tool will only work on Windows XP SP2 and SP3, Windows Vista and Windows 2003 SP2.  There is a very good paper out there on how to use this tool at http://www.issa.org/Library/Journals/2009/February/McRee-toolsmith.pdf.

Volatility 1.3-This is a command line tool and is open source and contains “plugins” written by the community to parse through Windows XP SP2 and SP3 memory dump only.  This tool can be downloaded using SVN and the url is http://volatiltiy.googlecode.com.

Volatility 1.4_RC1-This is the latest version of volatility and has not been officially released yet but it can still be downloaded and used against Window 7 memory dumps only.  There is no documentation as of yet but should be available this summer.


Basic Use of Volatility


Once you have it downloaded the tool you will need to also download all the 3rd party plugins.  A bash script is available that will download all the plugins and place them in the appropriate folder.  It will also download the most current released version of volatility and install all perl modules needed to ensure the tool works properly.  This script can be dowloaded HERE.  Once all that is done then you can execute the following syntax to get a listing of available plugins:


python volatility –help


Plugin Description Primary Maintainer Core Vote
apihooks Find API hooks MHL .
bioskbd Reads the keyboard buffer from Real Mode memory MA Yes
connections Print list of open connections . Yes
connscan2 Scan Physical memory for TCPT_OBJECT objects (tcp connections) . Yes
crashdump Dumps the crashdump file to a raw file . Yes
crashinfo Dump crash-dump information . Yes
csrpslist Find hidden processes with csrss handles and CsrRootProcess MHL .
datetime Get date/time information for image MA Yes
dlllist Print list of loaded dlls for each process . Yes
dlldump Dump a DLL from a process address space MHL Yes (in contrib folder)
driverirp Driver IRP hook detection MHL .
driverscan Scan for driver objects DRIVER_OBJECT . .
files Print list of open files for each process . Yes
filescan Scan Physical memory for FILE_OBJECT pool allocations . .
getsids Print the SIDs owning each process moyix Yes
hashdump Dumps passwords hashes (LM/NTLM) from memory moyix Yes
hibdump Dumps the hibernation file to a raw file . Yes
hibinfo Dump hibernation file information . Yes
hivedump Prints out a hive moyix Yes
hivelist Print list of registry hives. moyix Yes
hivescan Scan Physical memory for CMHIVE objects (registry hives) moyix Yes
idt Display Interrupt Descriptor Table MHL .
imageinfo Identify information for the image MA Yes
impscan Scan a module for imports (API calls) MHL .
ldrmodules Detect unlinked DLLs MHL .
kpcrscan Search for and dump potential KPCR values scudette Yes
lsadump Dump (decrypted) LSA secrets from the registry moyix Yes
malfind Find hidden and injected code MHL .
memdump Dump the addressable memory for a process . Yes
memmap Print the memory map . Yes
moddump Dump out a kernel module (aka driver) . Yes (in contrib folder)
modscan2 Scan Physical memory for LDR_DATA_TABLE_ENTRY objects . Yes
modules Print list of loaded modules MA .
mutantscan Scan for mutant objects KMUTANT . .
mutantscandb mutantscan extension for highlighting suspicious mutexes MHL .
notifyroutines Print system-wide notification routines MHL .
orphanthread Locate hidden threads MHL .
patcher Patches memory based on page scans MA Yes
printkey Print a registry key, and its subkeys and values moyix Yes
procexedump Dump a process to an executable file sample . Yes
procmemdump Dump a process to an executable memory sample . Yes
pslist print all running processes by following the EPROCESS lists . Yes
psscan Scan Physical memory for EPROCESS objects . Yes
pstree Print process list as a tree scudette Yes
regobjkeys Print list of open regkeys for each process MA .
sockets Print list of open sockets . Yes
sockscan Scan Physical memory for ADDRESS_OBJECT objects (tcp sockets) . Yes
ssdt Display SSDT entries moyix Yes
ssdt_by_threads SSDT hooks by thread MHL .
ssdt_ex SSDT Hook Explorer for IDA Pro (and SSDT by thread) MHL .
strings Match physical offsets to virtual addresses (may take a while, VERY verbose) . .
svcscan Scan for Windows services MHL .
thrdscan Scan Physical memory for ETHREAD objects . Yes
thrdscan2 Scan physical memory for ETHREAD objects . Yes
vaddump Dumps out the vad sections to a file . .
vadinfo Dump the VAD info . .
vadtree Walk the VAD tree and display in tree format . .
vadwalk Walk the VAD tree . .


The above table shows all the current plugins for Volatility 1.4.


Plugin Author URL Description Status Supported OSes Core Vote
bioskbd AB & MA url Reads the keyboard buffer from Real Mode memory . . Yes
cryptoscan JesseK url Finds Truecrypt passphrases . . No
DriverIRP MHL url Prints driver IRP function addresses . . Yes
driverscan Andreas Schuster url Scan for kernel _DRIVER_OBJECTs. (Note: If running the SVN version of Volatility, just install the plugin file from this archive.) . . Yes
dmp2raw . . Convert a crash dump to a raw dump . . .
fileobjscan AKA filescan (1.4 branch) Andreas Schuster url File object -> process linkage, including hidden files. (Note: If running the SVN version of Volatility, just install the plugin file from this archive.) . . Yes
getsids Moyix url Get information about what user (SID) started a process. . . Yes
IDT MHL url Prints the Interrupt Descriptor Table (IDT) addresses for one processor . . Yes
kernel_hooks MHL url Detects IAT, EAT, and in-line hooks in kernel drivers instead of usermode modules . . Yes
keyboardbuffer Andreas Schuster url Extracts keyboard buffer used by the BIOS, which may contain BIOS or disk encryption passwords. . . (Above)
kpcrscan Bradley Schatz url Finds potential KPCR addresses . . .
malfind2 MHL url Automates the process of finding and extracting (usually malicious) code injected into another process . . Yes
moddump Moyix url Dump out a kernel module (aka driver) . . Yes
mutantscan Andreas Schuster url Extracts mutexes from the Windows kernel.(Note: If running the SVN version of Volatility, just install the plugin file from this archive.) . . No
objtypescan Andreas Schuster url Enumerates Windows kernel object types. (Note: If running the SVN version of Volatility, just install the plugin file from this archive) . . Yes
orphan_threads MHL url Detects hidden system/kernel threads . . No
patcher MA url Patches memory based on page scans . . Yes
psscan3 Moyix url Scans the physical address space looking for memory resident data structures associated with processes. . . Yes
pstree Scudette url Produces a tree-style listing of processes . . Yes
raw2dmp . . Convert a raw dump to a crash dump . . .
Registry Tools Moyix url A suite of plugins for accessing data from the registry, including password hashes, LSA secrets, and arbitrary registry keys . . Yes
Modified Regripper & Glue Code Moyix url Code to run a modified RegRipper against the registry hives embedded in a memory dump. Note that due to a dependency on Inline::Python, this only works on Linux. . . No
sqlite3 Gleeda url Allows one to place Volatility output into a SQLite3 Database . . As example
ssdt Moyix url List entries in the system call table. Can be used to detect certain rootkits that hook system calls by replacing entries in this table . . Yes
suspicious JesseK url Identify suspicious processes. This version counts any command line running Truecrypt or any command line that starts with a lower case drive letter as suspicious . . No
symlinkobjscan Andreas Schuster url Extracts symbolic link objects from the Windows kernel.(Note: If running the SVN version of Volatility, just install the plugin file from this archive.) . . Yes
threadqueues Moyix url Enumerates window messages pending for each thread on the system. Window messages are the mechanism used to send things like button presses, mouse clicks, and other events to GUI programs. . . No
usermode_hooks MHL url Detect IAT/EAT/Inline rootkit hooks . . Yes
verinfo MA url Prints out the version information from PE images . . NO
Volatility Analyst Pack 0.1 MHL url A pack which contains updates to many of the listed modules . . (included above)
volshell Moyix url Creates a python shell can be used with the framework . . No


The above table shows all the plugins available for Volatiltiy 1.3.  There are also plenty of documentation on how to use this product, in fact, I wrote the manual on the use of this product which is located in the document library on this forum.  To view this manual click HERE.


One of the questions I always get from someone that is just starting out using this tool is “Which plugins do I use first and in what order.”  There is no right and wrong answer here but here is a list of some basic plugins I use just to see what is going on.


Date/TIme-This will give you the date and time of when the memory image was taken.

Ident-This will tell you about what operating system it came from.

Connscan-This will list the connections.

pstree and pslist-This will list all the processes in use at the time of the memory dump.  This is where you need to pay attention to the PID numbers and what service spawned what.  Once you find a suspected file or malware being spawned by for example “services.exe” then you would move on to the next plugin.

procdump-This will dump the process (exe) of the PID that you provide, so you need to make sure you give it the right PID number.


As with anything this tool requires the user to practice and become familiar with the plugins and what they can do.  Please take a look at some of the external links on the Training wiki to forensic challenges.


The last thing I want to discuss is the hiberfil.sys file.  This file will be found on a laptop computer that has gone into “hibernation mode” at some point.  The contents of the memory is dumped into the file in a compressed state.  So you need a tool to uncompress the memory so you can run these tools against it.  And it so happens that Volatility has a plugin that will do that for you.  That plugin is Hibinfo and the syntax is as follows: 


Python volatility hibinfo -f (path to image) -d (path and name of the output file ie memory.dd)


Once that is done then you can use volatility or whatever tool you like against the dump file.

Rebuilding Executable Images From Memory

One of the questions I initially had when I started analyzing memory images with Volatility was how do I extract the malicious executable from memory that the RE guys will be able to analyze. I kept running into the problem of not getting all the API functions with the executable and the RE guys kept telling me they could not do a complete analysis since they did not have all the functions.

So I picked up the book “Malware Analyst’s Cookbook and DVD” because there are 4 chapters dedicated to Volatility and one of those chapters (Chapter 16, Recipe 16-7) specifically deals with extracting the executable along with the API functions. So the following is a summarized excerpt of that recipe for those of you who do not have the above referenced book. This discussion will assume the reader has installed the latest version of Volatility from http://volatility.googlecode.com and installed all the available plugins and dependencies required. There are excellent walk-thru’s on the volatility website for that.

In general, to rebuild an executable from memory, you need to parse the PE section headers to learn the addresses and sizes of the PE sections. Then, you can carve out the appropriate amount of data from memory and re-combine the sections into a file on disk according to their original positions. There are references that provide a much deeper understanding of this process and are listed as follows:

http://computer.forensikblog.de/en/2006/04/reconstructing_a_binary.html (Andreas Schuster)

http://windowsir.blogspot.com/2006/07/automatic-binary-reassembly-from-ram.html (Harlan Carvey)

http://jessekornblum.com/presentation/dodcc07.html (Jesse Kornblum)

The methods described in the above publications rely on information in the PE header and do not attempt to reconstruct the Import Address Table (IAT). Malware samples that erase the entire PE header, relocate the IAT, or that use run-time dynamic linking cause significant problems. You still will be able to dump the binary using the base address and size information from the PE header (if it exists) or the base address and size information from the VAD; however, you will not be able to tell which API functions the malware calls. The following excerpt will explain methods to work around these anti-analysis techniques based on scanning the process address space for API calls, without relying on data in the IAT.

The first step is to use pslist or psscan to generate list of processes. Once you know the PID or _EPROCESS offset for the process that you want to dump, then you can pass it to procexedump or simply the leave off the -p parameter to dump all the processes. The syntax would be as follows:

python volatility.py pslist -f laqma.vmem (whatever the name of your memory image is) -p PID number

I would suggest at this point you download your favorite PE viewer and if you do not have one then I would suggest downloading CFF Explorer. Once you have dumped your process out then open it up using CFF Explorer and see if the IAT contains the right information. If it is a legitimate file it probably will but if not it will probably be missing the imported function names. At this point, you cold load the dumped file in IDA Pro and try your best to determine its capabilities without IAT information. Or you could scan the file with multiple anti-virus engines to see if they detect anything in the unpacked process image. However, what you typically want to do is perform a more thorough reverse-engineering tasks, which requires information about the imported functions.

Scanning For Imported Functions with IMPSCAN

The reason you should be concerned with an incomplete IAT is that it will hinder your ability to perform a thorough code analysis. If you try to examine the instructions in the dumped file using IDA Pro, then you will see placeholders instead of API calls. Since IDA does not have access to the entire process’s memory, it cannot determine what APIs exist at those addresses in order to label them. The impscan plug-in for Volatility aims to solve the problem of incomplete import tables. It is very unlikely that the dumped program will match the original or even execute on another machine. That is fine because all you really need to complete a thorough analysis of the malware’s capabilities is to be able to see which API functions it is calling in the disassembly. Therefore, impscan does not attempt to produce a patched version of the dumped file as Import REConstructor does for live systems. Instead, it simply provides labels that you can import into IDA Pro. Below is the syntax for impscan to scan a process for imported functions:

python volatility.py impscan -p 920 -f laqma.vmem –dump-dir=outdir

impscan works by determining the base address and size of all DLLs in a process. Using pefile, it parses the Export Address Table (EAT) of the DLLs to determine the offsets and names of exported functions. Then, using pydasm, it scans the process executable (or any memory range in the process address space as specified with the -a and -s flags) looking for call or jmp instructions. If the destination of one of the call or jmp instructions leads to an API, them impscan records the address of the instruction and the corresponding API function name. Impscan produces MakeName statements, which you can transfer into IDA Pro. These statements contain the missing information that IDA needs to link the placeholders presented earlier with the name of the API function stored at that address.

To apply the labels, click File → IDC Command, paste in the MakeName statements, and click OK. Once you have clicked OK, you will immediately see changes applied throughout the program. You can get even more information out of IDA by choosing to re-analyze the program. Now that IDA can tell which API functions the program is calling, IDA can label arguments accordingly. To do this, Click Options → General → Analysis → Reanalyze Program. Once this is complete then you can save your work through IDA Pro and then give that file to your RE guys for a detailed analysis. This will make their life a little easier and they will be much more receptive in handling executables from memory.

This process will create two files (bin file and a bin.idc) so if you are not an RE guy then you can take these two files along with the executable and give those to your RE guys who will know how to import them into IDA.

The impscan is not part of the volatility install but is a python script found on the DVD of the above referenced book.  I have uploaded this script to the library for everyone’s use.  The file is called “malware.py” and contains numerous scripts in one and the impscan script is part of that.  

Using RegRipper inside Encase Enterprise

In the earlier discussion I talked about the Registry Parser Tool “RegRipper” that uses plugins to parse through pre-determined registry paths to pull out relevant information.  In that post I was providing information on how to use Regripper against a mounted drive, but doing that takes some additional steps that are not necessary.  Normally to use RegRipper you must locate your registry hives, blue-check within Encase Enterprise and then copy them out to an export folder.  Then launch regripper and browse over to the hive files and run the tool then open the resulting report.  There is another way of using this tool inside of Encase without having to copy anything out of Encase and it is not necessary to mount the image as a mounted drive.  In order to do this you need to use the 3rd party viewer inside of Encase.  I have created a batch file for each current plugin that RegRipper uses and placed those in the RegRipper folder on my hard drive.  I then created a command line inside of Encase telling Encase I want the command prompt to open to “C:\RegRipper” and execute a particular plugin against the highlighted hive file that I have highlighted and creat a report based upon that plugin and place the report in the “C:\Temp\[plugin_name.txt.”

In other words the application path would show “C:\Windows\System32\cmd.exe” and the command lline shows: ” /S /D /K c:\\regripper\\bat_files\\aim.bat [file]

This opens the command prompt  and runs the aim plugin.  The corresponding batch file looks like this:

cd c:\regripper\

rip.exe -r %1 -p aim >> c:|temp\aim.txt

What this allows an examiner to do is run one particular plugin aganist a give hive file without having to copy anything out and without having to run all the plugins for that particular hive file and then dig through a text report for the information you are looking for.  If you feel this is something you would like to try out then please do so and provide some feedback on your thoughts.

I have uploaded a zip file containing all the batch files and the .ini viewer configuration file from Encase to the Document Library at the CSIRT Forum.  Just unzip the file and place the “bat” directory into your regripper folder and viewer.ini file into the “Program Files\Encase\Config\.”  This is setup with the assumption that your regripper folder is in the root of your “C:\” drive and that you have temp directory in the root of your “C:\” drive as well.  If you have those folders someplace else then you will need to update the ini file and the batch file for each plugin.

I am sure there are easier ways of doing this and maybe the scripting can be better but either way leave your comments here.  Also remember if you come up with additional plugins that would be beneficial to the rest of us please pass them along to everyone.

If you would like the batch files and ini files mentioned you can contact me through my email address: of mark.morgan47@gmail.com.   Please put in SUBJECT “Evernote” so I know where it came from.

What is an SQL Injection Attack?


SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. 

So, what specifically is SQL injection? It is the susceptability that results when you offer an hacker the power to control the Structured Query Language (SQL) queries that an application gives to a back-end database. When you are capable to influence what’s transferred to the database, the attacker can take advantage of the format and features of SQL itself, along with the ability and versatility of assisting storage system operation and OS functionality accessible to the storage system. SQL injection isn’t a susceptability that specifically influences Web products; any code that takes input via an untrusted origin thereafter uses that input to make dynamic SQL statements is usually vulnerable (e. g., “fat client” programs in a client/server architecture).  SQL injection seems to have quite possibly been around ever since SQL repository were being very first related to Web products.  SQL injection is undoubtedly an attack by which SQL program code is put or appended in to application/ user input variables that can be subsequently transferred to a back-end SQL server for parsing and execution. Any procedure that constructs SQL statements could very well perhaps become sensitive and vulnerable, as the varied nature of SQL and the techniques available for building it supply a wealth of coding possibilities. The primary way of SQL injection involves direct insertion of program code in parameters which can be concatenated with SQL codes and executed. A significantly less direct attack injects malevolent program code within strings that can be meant just for backup in a table or as meta-data. After the stored strings are eventually concatenated into a dynamic SQL request, the harmful program code is completed.  When a Web software ceases to suitably clean the parameters which might be transferred towards dynamically generated SQL statements (even though applying parameterization techniques) it is also possible for any attacker to enhance the engineering of back-end SQL transactions. When an attacker is capable of modify an SQL declaration, typically the declaration will probably carryout with the identical rights as the program end user; while using the SQL server to execute instructions which interact with the operating-system, the process definitely will work with the same permissions for the reason that element that carried out the command (e. g., database server, application server, or Web server), which happens to be quite often extremely privileged.

Forms of vulnerability

The Attacking vector splits in four main sub-classes, considering the technical aspects of the attack’s deployment, as follows:
  • Classic SQLIA 
  • Inference SQL Injection
  • DBMS specific SQLIA
  • Compounded SQLIA
Some security researches propose that, Classic SQLIA is outdated, though there are many Web Applications, which are still not hardened against these simple implementations of SQL Injection.

Inference SQLIA is still a threat, because of its dynamic and flexible deployment as an attacking scenario.

The DBMS specific SQLIA should be considered as supportive no matter there is an attempt of utilization of Classic or Inference SQLIA.

Compounded SQLIA is a new term derived from the research on SQL Injection Attacking Vector in combination with other different Web Application attacks as:
  • SQL Injection + Insufficient authentication
  • SQL Injection + DDos attacks
  • SQL Injection + DNS Hijacking
  • SQL Injection + XSS

Incorrectly filtered escape characters

This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into an SQL statement. This results in the potential manipulation of the statements performed on the database by the end-user of the application.

The following line of code illustrates this vulnerability

statement = "SELECT * FROM `users` WHERE `name` = '" + userName + "';"

This SQL code is designed to pull up the records of the specified username from its table of users. However, if the “userName” variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the “userName” variable as

' or '1'='1 

Or using comments to even block the rest of the query (there are three types of SQL comments):

' or '1'='1' -- '' or '1'='1' ({ '' or '1'='1' /* ' 

renders one of the following SQL statements by the parent language:

SELECT * FROM `users` WHERE `name` = '' OR '1'='1'; 
SELECT * FROM `users` WHERE `name` = '' OR '1'='1' -- ';

If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of ‘1’=’1′ is always true.

The following value of “userName” in the statement below would cause the deletion of the “users” table as well as the selection of all data from the “userinfo” table (in essence revealing the information of every user), using an API that allows multiple statements:

a';DROP TABLE `users`; SELECT * FROM `userinfo` WHERE 't' = 't 

This input renders the final SQL statement as follows:

SELECT * FROM `users` WHERE `name` = 'a';DROP TABLE `users`; SELECT * FROM `userinfo` WHERE 't' = 't'; 

While most SQL server implementations allow multiple statements to be executed with one call in this way, some SQL APIs such as PHP‘s mysql_query(); function do not allow this for security reasons. This prevents attackers from injecting entirely separate queries, but doesn’t stop them from modifying queries.

Incorrect type handling

This form of SQL injection occurs when a user supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric. For example:
statement := "SELECT * FROM `userinfo` WHERE `id` = " + a_variable + ";"

It is clear from this statement that the author intended a_variable to be a number correlating to the “id” field. However, if it is in fact a string then the end-user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to

1;DROP TABLE `users` 

will drop (delete) the “users” table from the database, since the SQL would be rendered as follows:

SELECT * FROM `userinfo` WHERE `id`=1;DROP TABLE `users`; 

Blind SQL injection

Blind SQL Injection is used when a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page. This type of attack can become time-intensive because a new statement must be crafted for each bit recovered. There are several tools that can automate these attacks once the location of the vulnerability and the target information has been established.

Conditional responses

One type of blind SQL injection forces the database to evaluate a logical statement on an ordinary application screen.

SELECT `booktitle` FROM `booklist` WHERE `bookId` = 'OOk14cd' AND '1'='1';

will result in a normal page while

SELECT `booktitle` FROM `booklist` WHERE `bookId` = 'OOk14cd' AND '1'='2'; 

will likely give a different result if the page is vulnerable to a SQL injection. An injection like this may suggest to the attacker that a blind SQL injection is possible, leaving the attacker to devise statements that evaluate to true or false depending on the contents of another column or table outside of the SELECT statement’s column list.

SELECT 1/0 FROM `users` WHERE `username`='ooo'; 

How to Stop SQL Injection

Parameterized statementsWith most development platforms, parameterized statements can be used that work with parameters (sometimes called placeholders or bind variables) instead of embedding user input in the statement. In many cases, the SQL statement is fixed, and each parameter is a scalar, not a table. The user input is then assigned (bound) to a parameter. This is an example using Java and the JDBC API:

java.sql.PreparedStatement prep = connection.prepareStatement( 
prep.setString(1, username);
prep.setString(2, password);

Enforcement at the Database Level

The H2 Database Engine supports the ability to enforce query parameterization.  However, one drawback is that query by example may not be possible or practical because it is difficult to implement query by example using parameterized queries.

Enforcement at the Coding Level

Using object-relational mapping libraries avoids the need to write SQL code. The ORM library in effect will generate parameterized SQL statements from object-oriented code.


A straightforward, though error-prone, way to gsprevent injections is to escape characters that have a special meaning in SQL. This technique is called HTML sanitization The manual for an SQL DBMS explains which characters have a special meaning, which allows creating a comprehensive blacklist of characters that need translation. For instance, every occurrence of a single quote (') in a parameter must be replaced by two single quotes ('') to form a valid SQL string literal. For example, in PHP it is usual to escape parameters using the function mysql_real_escape_string(); before sending the SQL query:

$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'", mysql_real_escape_string($Username), mysql_real_escape_string($Password));mysql_query($query); 

Routinely passing escaped strings to SQL is error prone because it is easy to forget to escape a given string. Creating a transparent layer to secure the input can reduce this error-proneness, if not entirely eliminate it.

Conducting the Forensic Analysis of  a SQL Injection Attack

I read several blogs, white papers and articles on this subject and they all come to the same conclusion that the best way to start the analysis is through viewing the database cache.  So the question becomes how do you get to that data?  There are probably several ways but based on my research there is a tool they can assist you in this called “Hypnosis.”  

An SQL Server maintains several database caches that record previously executed statements.  These caches can contain evidence of successfully executed database attacks including those launched from SQL injection attack tools, worms or even by interactively logged on users.  Hypnosis is the first cache-based incident response utility that interrogates the “always-on” caching feature of SQL Server to help confirm or discount a successful database attack.

According to the website; Hypnosis uses a RegEX based rule file named “CacheRules.txt” which can be populated with attack signatures for use during cache interrogation.  The default CacheRules file contains attack signatures for Pangolin a widely used SQL injection tool within the industry.  The CacheRules file can be extended to include signatures from any other tools or generic attacks for use during interrogation.  The file extension format is captured in the header of the CacheRules file. Hypnosis can also be used to add ad-hoc signatures that match generated IDS\IPS\WAF devices for verification if an attack was successfully tunneled to and executed by the database server.

I am sure there are other ways to conduct the analysis of this type of attack as I am not an expert in databases.  I would love to hear comments on other ways to approach this.


Intrusion Discovery Cheat Sheet 2.0 (Windows XP Pro/2003 Server/Vista

Unusual Processes and Services

Using the GUI, run Task Manager
Using the command prompt:
     c:/wmic process list full
Also look for unusual Services.
Using the GUI
Using the Command Prompt:
     c:/ net start
     c:/ sc query
For a list of services associated with each process:
     c:/ tasklist /svc
Unusual Files and Registry Keys

Check the file space usage to look for sudden major decreases in free space, using the GUI (right-click on partition), or type:
     c:/ dir c:\
Look for unusually big files: Start->Search->For Files of Folders…Search Options->Size->at least 10000KB
Look for storage programs referred to in registry keys associated with system start up:
  • HKLM\Software\Microsoft\Window\CurrentVersion\Run
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce
  • HKLM\Software\Microsoft\Windows\CurrentVersion\RunonceEx
Note you should also check the HKCU counterparts (replace HKLM with HKCU above).

Using the GUI:
     c:/ regedit

Using the command prompt:
     c:\ reg query <reg key>

Unusual Network Usage

Look at file shares, and make sure each has a defined business purpose:

     c:\ net view \\
Look at who has an open session with the machine:
     c:\ net session
Look at which sessions this machine has opened with other systems:
     c:\ net use
Look at NetBIOS over TCP/IP activity:
     c:\ nbtstat -S
Look for unusual listening TCP and UDP ports:
     c:\ netstat -na
For continuously updated and scrolling output of this comm and every 5 seconds:
     c:\ netstat -na 5
The -o flag shows the owning process id:
     c:\ netstat -nao 5
The -b flag shows the executable name and the DLLs loaded for the network connection:
     c:\ netstat -naob 5
Note the -b flag uses excessive CPU resources.
Again, you need to understand normal port usage for the system and look for deviations.
Also check Windows Firewall configuration:
     c:\ netsh firewall show config

Look for unusual scheduled tasks, especially those that run as a user in the Administrators group, as SYSTEM, or with a blank user name.
Using the GUI, run Task Scheduler:
Start->Programs->Accessories->System->Tools->Scheduled Tasks
Using the command prompt:
     c:\ schtasks
Check other autostart items as well for unexpected entries, remembering to check user autostart directories and registry keys.
Using the GUI, run msconfig and look at the Startup tab:
     Start->Run, msconfig.exe
Using the command prompt:
     c:\ wmic startup list full
Unusual Accounts

Look for new, unexpected accounts in the Administrators group:
     c:\ lusrmgr.msc
Click on Groups, Double Click on Administrators, then check members of the group.
This can also be done at the command prompt:
     c:\ net user
     c:\ net localgroup administrators
Unusual Log Entries

Check you logs for suspicious events, such as:
  • Event log service was stopped.”
  • Windows File Protection is not active on this system”
  • “The protected System file [file name] was not restored to its original, valid version because  the Windows File Protection ….”
  • “The MS Telnet Service has started successfully.”
To do this using the GUI, run the Windows event viewer:

     c:\ eventvwr.msc

Using the Command Prompt:

     c:\eventquery.vbs | more

Or, to focus on a particular event log:

     c:\ eventquery.vbs /L security

Other Unusual Items

Look for unusually sluggish performance and a single unusual process hogging the CPU: Task Manager->Process and Performance tabs

Look for unusual system crashes, beyond the normal level for the given system.

Additional Supporting Tools

The following tools are not built into Windows operating system but can be used to analyze security issues in more detail.  Each is available for free download at the listed web site.

Tools for mapping listening TCP/UDP ports to the program listening on those ports:

     Fport – command-line tool at www.foundstone.com
     TCPView – GUI tool at www.microsoft.com/technet/sysinternals
Additional Process Analysis Tools:
The Center for Internet Security has released various Windows security templates and security scoring tools for free at www.cisecurity.org.