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!

Scans


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?

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( 
 "SELECT * FROM `users` WHERE USERNAME = ? AND PASSWORD = ?");
prep.setString(1, username);
prep.setString(2, password);
prep.executeQuery();

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.

Escaping

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:/tasklist
     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 \\127.0.0.1
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.

 

Intrusion Discovery Cheat Sheet (Linux)


Unusual Processes and Services

Look at all running processes:

     # ps -aux

Get familiar with “normal” processes for the machine.  Look for unusual processes.  Focus on processes with root (UID 0) privileges.

If you spot a process that is unfamiliar, investigate in more detail using:

     # lsof -p [pid]

This command shows all files and ports used by the running process.

If your machine has it installed, run chkconfig to see which services are enabled at various runlevels:

     # chkconfig –list

Unusual Files


Look for unusual SUID root files:

     # find / -uid 0 -perm -4000 – print
This requires knowledge of normal SUID files.

Look for unusual large files  (greater than 10MB):

     # find / -size +10000k -print

This requires knowledge of normal large files.

Look for files named with dots and spaces (“…”,”..”,”.”, and “”) used to camouflage files:

     # find / -name ” ” -print
     # find / -name “..” -print
     # find / -name “. ” -print
     # find / -name ” ” -print

Look for processes running of of or accessing files that have been unlinked (ie., link count is zero).  An attacker may be hiding data in or running a backdoor from such files:

     # lsof +L1
On a Linux machine with RPM installed (RedHat, Mandrake, etc.,), run the RPM tool to verify packages:

     # rpm -Va | sort

This checks size, MD5 sum, permissions, type, owner, and group of each file with information from RPM database to look for changes.  Output includes:

     S-File size differs
     M-Mode differs (permissions)
     5-MD5 sum differs
     D-Device number mismatch
     L-readlink path mismatch
     U-user ownership differs
     G-group ownership differs
     T-modification time differs

Pay special attention to changes associated with items in /sbin, /bin, /usr/sbin, and /usr/bin.

In some versions of Linux, this analysis is automated by the built-in check-packages script.

Unusual Network Usage

Look for promiscuous mode, which might indicate a sniffer:

     # ip link | grep PROMISC

Note that the ifconfig doesn’t work reliably for detecting promiscuous mode on Linux kernel 2.4, so please use “ip link” for detecting it.

Look for unusual port listeners:

     # netstat -nap

Get more details about running processes listening on ports:

     # lsof -i

These commands require knowledge of which TCP and UDP ports are normally listening on your system.  Look for deviations from the norm.

Look for unusual ARP entries, mapping IP addresses to MAC addresses that aren’t correct for the LAN;

     # arp -a

This analysis requires detailed knowledge of which addresses are supposed to be on the LAN (such as a DMZ), look for unexpected IP addresses.

Unusual Scheduled Tasks

Look for cron jobs scheduled by root and any other UID 0 accounts:

     # crontab -u root -l

Look for unusual system-wide cron jobs:

     # cat /etc/crontab
     # ls /etc/cron.*

Unusual Accounts

Look in /etc/passwd for new accounts in sorted list by UID:

     # sort -nk3 -t: /etc/passwd | less

Normal accounts will be there, but look for new, unexpected accounts, especially with UID < 500.

Also, look for unexpected UID 0 accounts:

     # egrep `:0+` /etc/passwd

On systems that use multiple authentication methods:

     # getent passwd | egrep `:0+:`

Look for orphaned files, which could be a sign of an attacker’s temporary account that has been deleted.
     
     # find / -nouser -print

Unusual Log Entries

Look through your system log files for suspicious events, including:

  • “entered promiscuous mode”
  • Large number of authentication or logn failures from either local or remote access tools (e.g., telnetd, sshd, etc.)
  • Remote Procedure Call (rpc) programs with a log entry that includes a large number ( > 20) strange characters (such as ^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM)
  • For systems running web servers: Larger than normal number of Apache logs saying “error”
  • Reboots and/or application restarts
Other Unusual Items

Sluggish system performance:

     # uptime -Look at “load average”

Excessive memory use: $ free
Sudden decreases in available disk space: $ df

Additional Supporting Tools

The following tools are often not built into the Linux operating system, but can be used to analyze its security status in more detail.  Each is available for free download at the listed website.

Chkrootkit looks for anomalies on systems introduced by user-mode and kernel-mode:
RootKits –www.chkrootkit.org

Tripwire looks for changes to critical system files –www.tripwire.org–free for Linux for non-commercial use.

AIDE looks for changes to critical system files http://www.cs.tut.fi/~rammer/aide.html

The Center for Internet Security has released a Linux hardening guide for free at www.disecurity.org

The free Bastille Script provides automated security hardening for Linux systems, available at www.bastille-linux.org.