Digital Forensics Blog

DNS Digging

Posted by :admin On : February 18, 2013

Category: Digital Forensics, Incident Response

I thought I’d do a bit of a refresher on DNS and Dig in light of recent DNS based attacks such as the Facebook 0-dayer reported over the weekend.

So I started off by typing ‘Dig’ into my Linux box to get a listing of root servers:

I then typed ‘dig @d.root-server.net. foobar.co.uk’ to query the root server for the authoritative server for foobar.co.uk:

DNS2

The authoritative servers are ns1.thekerb.com and ns2.thekerb.com. So next I queried ns2.thekerb.com with Dig by typing ‘dig @ns2.thekerb.com’:

So we now know that the recorded IP address is 77.92.82.205. So now you can compare this with any other DNS output if you suspect you have a compromised server.

Reference:

Check this post out for more informations: http://resources.infosecinstitute.com/ghost-domain-names/.

Metasploit DLLs

Posted by :admin On : February 17, 2013

Category: Incident Response, RAM, Volatility

I’ve jus been watching this excellent video.

http://www.youtube.com/watch?feature=player_embedded&v=8HsZLge0wWc

It was posted in 2011 so things may have moved on for later versions of Metasploit but the poster mentions that prior to version 3.2 of Meterpreter you should watch out for the DLL NETSRV.DLL being present in non-standard Windows processes and after IPHLPAPI.DLL and SHLWAPI.DLL (the latter two are shown in \Windows\System32) and can be called legitimately by processes such as LSASS and IEXPLORE).

Kernel Memory (Quickie)

Posted by :admin On : February 17, 2013

Category: Incident Response, RAM, Volatility

Like PSScan/PSList and LDR_Modules/DLLList it is possible to search for Kernel Modules that bypass the doubly linked lists that record their presence. To ascertain any Kernel Modules recorded in linked lists one uses Volatility’s ‘Modules’ command whereas to establish ‘hidden’ Kernel Modules the ‘Modscan’ command can be used. The linked lists are contained within the LDR_DATA_TABLE_ENTRY structures that are pointed to by the PsLoadedModuleList.

For this post I used the memory dump for Laqma which can be found on the Volatility website.

Firstly, here’s the output using the ‘Modules’ command:

The listing was abridged for brevity. As were all screenshots in this post.

Notice that the penultimate entry could be of interest. If you managed to locate the computer before a reboot was instigated, there’s a good chance that some of the latter entries may relate to the compromise.

And to show the results of ‘Modscan’:

Conducting a comparison of these listings may reveal suspicious Kernel Modules – or….

You could dump all Modules using ‘Moddump’:

And scan with a virus scanner:

Which in this case confirmed that our problematic Module was ‘lanmandrv.sys’.

SQL collection and analysis part 2 – Analysis

Posted by :admin On : January 21, 2013

Category: Uncategorized

In this post I will talk about logging. It will be assumed that you have read the first part of this post and have therefore preserved volatile data that can contain vital evidence concerning recent database activity and use – allowing you to better investigate an attack.

By default SQL Server (based on a 2005 setup although I believe there is much crossover across versions) logs to the following locations:

SQL Server ERRORLOG
Windows application log
Default Trace
Transaction log

Note that the database itself is usually the file with the name of the database plue the MDF extension.

Based on a review of SQL Server 2005, it appears that the Windows logs and SQL Server ERRORLOGS duplicate a lot of information. They store chronological details of events that may consist of failed and successful login attempts, backups, restores, error messages and more.

The default location as of SQL Server 2005 was ‘\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG’. Note that a new ERRORLOG was generated every time the service was restarted. The most recent log file was named ERRORLOG with each older version incrementing by one value. For instance, the next oldest was ERRORLOG.1. The SQL Server can be queried with the command ‘EXEC master.dbo.xp_enumerrorlogs’ to get the path of the ERRORLOG.

The Default Trace log, is stored in the subfolder ‘\MSSQL\LOG’ too (this is verified for SQL Server 2012). These files can be viewed with SQL Server Profiler. They are the files with the TRC extension. A new log file is created upon service start or when a file exceeds 20MB. To determine if the log is enabled you can query the server ‘exec sp_configure ‘default trace enabled’.

The Default Trace logs the following:

Failed logins
Login deletion, creation and modification
Server options being changed
Backups and restores
Object creation

Transaction Logs….

More to follow…

SQL collection and analysis part 1 – Preparation and collection

Posted by :admin On : January 20, 2013

Category: Incident Response, SQL

Having trawled Google for SQL Server analysis tips, it seems that there is limited expertise on the subject. Three excellent references that I found for this article are listed below but some are a little old:

Data collection is not as simple as shutting down your server (if the admin will even allow that!), inserting your boot disc of choice and imaging if you want to retain evidence concerning database misuse. If you do this, then you will lose potentially valuable evidence volatile evidence – including important connection and session data. I’ll cover the potential evidence sources on SQL servers in more depth in the next post. This post will cover triaging a system and ensuring that you preserve volatile data.

It may be actually that you’ve been called in to ascertain whether there is something to investigate. This is why the following step-by-step methodology has been proposed:

Preparation
Incident Verification
Artifact Collection
Artifact Analysis

Preparation, verification and collection

You’ll first need to prepare a toolkit. This toolkit should comprise known good files only. Kevvie Fowler provides these SQL Incident Response Scripts. You’ll also need your own copy of Command Prompt, SqlCmd.exe SqlCmd.rll and BatchParser.dll. You may choose to incorporate these into Windows Forensic Toolchest.

These are the SQL Incident Response Scripts:

It should be noted that some of the scripts contain this code:

– Verify if server is running SQL Server 2005 or 2008
IF ((CONVERT(char(20), SERVERPROPERTY(‘productversion’)) LIKE ’9.00%’) OR (CONVERT(char(20), SERVERPROPERTY(‘productversion’)) LIKE ’10.0%’))

I have not yet configured a VM with SQL Server 2012 but suggest amending the code to read as below (and doing some testing):

With the SQL Incident Response Scripts you can triage a system for any evidence of database compromise and you can preserve the essential volatile data that exists on an SQL Server. You can for instance review recent commands, userlists, sessions and changes to configuration (such as enabling the command shell).

If you’re conducting a triage then you may wish to also review the SQL ERRORLOGs (this could be done through a forensic utility such as FTK Imager) for any evidence pertinent to your enquiry. The ERRORLOGs are stored in the at ‘\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG’ in SQL Server 2005.

If you wish, you can manually garner some information using SqlCmd.exe.

The trusted SqlCmd.exe should be launched from the secure Cmd.exe. Type ‘sqlcmd -S servername -e -s “,” ‘
To create a log of activity ‘:out f:\mylogfile.txt’
Select the database of interest by typing ‘use DatabaseName’ then ‘go’
To verify authentication mechanism and logging details type ‘xp_loginconfig’
If you’re concerned about the permissions that a particular user has on the database type ‘Select * from sys.database principals where type=’S’ or type =’U’ order by create date, modify date’
To verify whether the command shell was enabled type ‘Select * from sys.configurations’

The triage will ensure that you can make an informed decision on whether to progress to taking a full image of the server and it will have you prepared with a wealth of evidence if you do decide to progress further.

See part 2 for further information on SQL Server forensics.

DLL hell

Posted by :admin On : January 20, 2013

Category: Digital Forensics, RAM

I like to keep refreshing my memory on areas that I don’t necessarily touch on every day because it can be easy to forget some of the basics and core concepts that will help you out when you’re called upon to conduct an investigation ‘in anger’. I wanted, therefore, to record and refresh my memory on DLL injection, a method used by malware creators to force their programs into legitimate processes. I’ll be cribbing from this excellent book:

In Volatility we can parse the PEB (Process Environment Block) from each EProcess structure. Remember, that each process has its own EProcess structure. Each EProcess structure contains a PEB. The PEB contains the path to the process executable, the command line used to launch this executable, the working directory and three doubly linked lists that detail the DLLs for the process. So, each of these linked lists should match up – although they’re ordered differently.

In a previous post, I listed some basic Volatility commands. One of them allowed us to lists DLLs for a process, as shown below:

NOTE: DLLList will only parse out information on ‘live processes’ and DLLs featuring in the doubly linked lists. Malware can hide itself by unlinking entries within the PEB.

You should review the output of DLLList for any unusual DLLs, perhaps that you’ve not seen before, or that have intriguing names (though let’s remember that the malware creator was probably trying to keep the malware hidden!), or DLLs that have been loaded from unusual paths.

The Virtual Address Descriptor (VAD) can help you to determine if malware has unlinked itself because it keeps track of memory ranges allocated to processes; the VAD can help you to determine where each file is mapped to in memory. Even when malware unlinks itself, its mapping details remain in the VAD.

The LDR_Modules plugin for Volatility enables you to view the address and path of executables for a process. It also allows you to compare the VAD and PEB entries. You are therefore able to ascertain whether malware has been trying to cover its tracks by unlinking PEB entries. Unfortunately, some of these clever malware engineers have developed methods of overwriting the VAD and bypassing the VAD and PEB entry creation process (for example, by not using the Windows LoadLibrary call – called Reflective DLL Injection). That’s all to be covered in a later post however.

Memory forensic cheat sheet

Posted by :admin On : January 20, 2013

Category: Digital Forensics, Incident Response, RAM

I stumbled across this very useful PDF whilst doing some reading the other day. It was produced by Chad Tilbury for SANs and provides a concise overview of the core Volatility commands. You can find it here.

Volatility basics

Posted by :admin On : January 14, 2013

Category: Incident Response, RAM, Software, Volatility

It’s quite a while since I did any real in-depth incident response forensics. I’ve kept my hand in with the odd job and a bit of reading every now and then but I will be involved in a lot of incident response work for my new job (I’ll be working in Africa). As with all of these posts, primarily intend to refresh my memory or document new ‘bits and pieces’ that I have picked up. My memory’s like a sieve so I’d be lost without some form of reference point.

My memory

Equivalent to this

Today I’ll be documenting some of the basics commands available in Volatility. This is by no means an exhaustive RAM analysis tutorial. It’s just here as a reminder of some of the commands that are available.

In the words of the project team: ‘The Volatility Framework is a completely open collection of tools, implemented in Python under the GNU General Public License, for the extraction of digital artifacts from volatile memory (RAM) samples.’

The first thing you’ll need to do is create an image of the RAM of your target computer. For a while I’ve been looking for a stable 32 and 64 bit software utility to enable this. Moonsol’s DumpIt seems to be the answer. DumpIt can be put onto a removable media device and although I haven’t tested it on Vista and Windows 7 machines (unsure about Windows 8 just now), I believe it’s compatible.

I’ve cribbed from a variety of website and books to produce the examples below. They’re all listed in the reference section. The RAM image is of the Zeus sample taken from Volatility’s website.

If you don’t know the details of the operating system that your RAM image was taken then you can run the Volatility ‘imageinfo’ command as shown below:

Next, it is prudent to discover the processes running on your system when the RAM image was taken. Two useful commands are PSScan and PSList. PSList is, however, susceptible to DKOM (Direct Kernel Object Manipulation). This means that doubly linked lists that point to the EProcess structures in which process details are stored can be overwritten which enables the hiding of processes. PSScan, however, works by looking for these EProcess structures and hence hidden processes can be discovered.

So, first the PSScan command was executed (the screenshots aren’t great – I’d not setup my VM too well):

Nothing super-interesting here – so we try looking at PSScan and comparing the results:

Spend time examining the processes. For instance, if you find two instances of lsass.exe running on a system, you should investigate further. You should find that a legitimate version lsass.exe of is launched by winlogon.exe so you should find that the parent process for it is winlogon.exe. If it isn’t then you’ve found a problem. You will need to become familiar with the system processes and their parents to help you. You should also compare PSList and PSScan results to see if you can find hidden processes. There are plugins for Volatility called PSScan3 and PSDiff that will automate this comparison process for you.

Another method of hidden process discovery is to use the CSRPSLIST plugin. This tool compares an EProcess scan with the data stored by the csrss process. Csrss holds information on all processes other than itself and those that started before it which are usually (system idle, system and sms.exe). I mention this because it is good to know and certainly true for systems with XP SP1 and SP2 installed.

You can examine network connections with connscan, as below:

Process 856 is connecting to 172.16.176.143. Process 856, according to PSList, is svchost.

You can use the malfind plugin to search for PE headers within process listings (abridged screenshot):

So an executable file (note the MZ signature) of interest was found within process 856. It is also worth noting that malfind has a useful ‘-Y’ flag that can be used in conjunction with its Yara rules to find characteristics associated with malware.

A scan of this file, which we have extracted, shows that malwarefind has indeed found malware!

And just to show you DLLList – which is covered more indepth here :

References:

Malware Analyst’s Cookbook and DVD: Tools and Techniques for Fighting Malicious Code by Michael Ligh (Author), Steven Adair (Author), Blake Hartstein (Author), Matthew Richard (Author)

https://www.volatilesystems.com/default/volatility

http://www.evild3ad.com/956/volatility-memory-forensics-basic-usage-for-malware-analysis/

Malware Forensics Field Guide for Windows Systems: Digital Forensics Field for Windows Systems
By Cameron H. Malin, Eoghan Casey and James M. Aquilina

Webmail download software

Posted by :admin On : January 14, 2013

Category: IP Theft, Software

This webmail forensic tool looks interesting. On a number of occasions I have been asked to download the webmail account of an IMAP or POP3 based account. It’s not rocket science, but it would be nice to have a log of everything that had been collected. This software appears to collect from AIM, iCloud, Zoho, GMX, Yahoo, and Gmail based IMAP accounts (no Hotmail/Live accounts then) but it does copy message headers and create an audit log. At $19.99, it’s worth considering.

Searching for evidence of files accessed

Posted by :admin On : January 14, 2013

Category: Digital Forensics, IP Theft

This is a tip rather than an exhaustive guide on how to determine files accessed by a user. In a recent case I was finding very little evidence of any suspect/dodgy files being accessed by a user from a removable media device. I therefore performed this grep:

g:\\[a-z|#]{3,99}\.

This allowed me to search for traces of files on the system emanating from the drive ‘g’ followed by a ‘:\’ and having a letter or number in the file name (you could add other legal characters such as ‘-’ and ‘_’ by placing ‘|_|-’ after the ‘#’) followed by a full stop (the file extension).

Just remember that just because you can see a potentially interesting file name doesn’t mean that this file ever existed on the system you’re examining! There are plenty of refinements that you can make to this grep. I know it’s not perfect but it’s a starting point!…