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.
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?
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.
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.
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.
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.
Forms of vulnerability
- Classic SQLIA
- Inference SQL Injection
- DBMS specific SQLIA
- Compounded SQLIA
- 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
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
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
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);
Conducting the Forensic Analysis of a SQL Injection Attack
Like this:
- HKLM\Software\Microsoft\Window\CurrentVersion\Run
- HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce
- HKLM\Software\Microsoft\Windows\CurrentVersion\RunonceEx
- “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.”
- Process Explorer – GUI tool at www.microsoft.com/technet/sysinternals
- TaskMan+ — GUI tool at http://www.diamondcs.com.au
- “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
