Security Ripcord

The success of Into The Boxes Issue 0×0 was only possible because of the collaboration provided by members of the Digital Forensics and Incident Response community.  In order for this publication to continue we need more people to step up and provide their input.  As you can see from the first issue we are looking for input that can be implemented by people in the DF/IR fields.  This input can be in the form of detailed articles or quick tips.  All input will be given serious consideration.  The ITB editors will provide authors with recommendations to strengthen their write-ups to ensure the best value to the community and help the authors develop as DF/IR professionals and writers.

Please help ITB by providing your submissions or letting us know about your intent to submit via the ITB Call Box.  We are also looking for article recommendations which we will place in the ITB Research Box so that others have good ideas as to what will help the DF/IR Community.  Obviously, if you would like to contribute but do not know what to write about, check out the ITB Research Box for recommendations.

Go forth and do good things,

Don C. Weber

Most of the time the initial infection vector associated with APT-style attacks incorporate the client-side exploitation of vulnerabilities in any number of software.  Actually, when dealing with APT-style events I prefer “initial compromise vector” (ICV) as APT backdoors should not be considered or even referred to as malware because it provides an incorrect understanding to the whole incident response.  User and system activity coupled with the fact that many organizations do not detect a compromise for several months means that the ICV can be elusive.  It is much more likely that the actions following the initial compromise are going to persist over time.

The following timeline information was pulled from a system.  A complete timeline was generated using system artifacts parsed using System Combo Timeline and several TLN-based Enscripts.  Each line is in the order display within the timeline.  no lines have been removed.  This was a fairly lucky situation as many times unrelated activity needs to be purged from the timeline to see this type of detail and understand specific activities.  Specific comments will follow the lines I want to highlight.

2009 11 04 08:59:42|SysEvent.Evt – EVT|COMP-SYS|S-1-5-18|Service Control Manager/7035;Info;LiveUpdate,start
2009 11 04 08:59:42|SysEvent.Evt – EVT|COMP-SYS|N/A|Service Control Manager/7036;Info;LiveUpdate,running
2009 11 04 09:00:06|AppEvent.Evt – EVT|COMP-SYS|N/A|Symantec AntiVirus/16;Info;Virus definitions are current.
2009 11 04 09:00:12|SysEvent.Evt – EVT|COMP-SYS|N/A|Service Control Manager/7036;Info;LiveUpdate,stopped

Very interesting that many of these events seem to occur during some type of AV updating or scanning activity.  Although really just an interesting side note, this does show that AV can only prevent what it is programmed to understand.  The following events do not fall into that category.

2009 11 04 09:19:09|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18|Change Time (ctime)
2009 11 04 09:19:09|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18|Modified Time (mtime)
2009 11 04 09:19:09|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18\d42cc0c3858a58db2db37658219e6400_dbcab107-5342-4908-9e95-0aba2546f18b|Accessed Time (atime)
2009 11 04 09:19:09|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18\d42cc0c3858a58db2db37658219e6400_dbcab107-5342-4908-9e95-0aba2546f18b|Change Time (ctime)
2009 11 04 09:19:09|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18\d42cc0c3858a58db2db37658219e6400_dbcab107-5342-4908-9e95-0aba2546f18b|Created Time (crtime)

These files appear to be associated with Microsoft Cryptographic Service Providers.  I am still researching what this actually implies.  Please post a comment if you can provide some insight.

2009 11 04 09:21:00|SysEvent.Evt – EVT|COMP-SYS|S-1-5-18|Service Control Manager/7035;Info;UpsGSx,start
2009 11 04 09:21:00|SysEvent.Evt – EVT|COMP-SYS|N/A|Service Control Manager/7036;Info;UpsGSx,running
2009 11 04 09:21:00|SysEvent.Evt – EVT|COMP-SYS|S-1-5-18|Service Control Manager/7035;Info;UpsGSx,stop

This service is a malicious backdoor that has been related to Hydraq. Notice that new services do get logged to Windows Event Logs but only if your systems are configured to log.  But why did this service start?

2009 11 04 09:21:00|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\Tasks|Change Time (ctime)
2009 11 04 09:21:00|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\Tasks|Modified Time (mtime)

Ah, a modification to the Scheduled Tasks folder.  This could be an indication that a job was scheduled to run.

2009 11 04 09:21:00|Registry Hive: software|COMP-SYS|0|$$$PROTO.HIV/Microsoft/SchedulingAgent
2009 11 04 09:21:00|Registry Hive: system|COMP-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_UPSGSX/0000
2009 11 04 09:21:00|Registry Hive: system|COMP-SYS|0|$$$PROTO.HIV/ControlSet002/Enum/Root/LEGACY_UPSGSX/0000

More activity associated with the UPSxxx backdoor service starting.

2009 11 04 09:21:00|Task Log|COMP-SYS|”At1.job” (a.exe)    Started 11/4/2009 5:21:00 PM|0
2009 11 04 09:21:00|Task Log|COMP-SYS|”At1.job” (a.exe)    Finished 11/4/2009 5:21:00 PM    Result: The task completed with an exit code of (0).|0

Well, now, what do we have here?  A scheduled task running a strange executable.  And, at the exact same time that the UPSxxx backdoor service started.  Nobody said that timeline information will be presented down to the millisecond.  Obviously this action occurred before some of the other events.  Had the conversion from local time to UTC been off this data might have been lost and not associated with these events.

2009 11 04 09:31:58|SysEvent.Evt – EVT|COMP-SYS|N/A|Tcpip/4226;Warn;

Once, Harlan Carvey recommended that I get a subscription to EventID.net.  Here is where that subscription pays off.  The description for Event ID 4226 reads “TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts.”  Well, now, it seems that there is a large number of outgoing connection attempts.  Additional comments from other users of EventID.net provide indications that this type of activity can be linked to malware.  And to think, this was alerted in the Windows Event Logs no less.  Did I mention that these should be turned on?  Starting to seem very useful right about now.

2009 11 04 09:35:30|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\snmpapi.dll|Accessed Time (atime)
2009 11 04 09:35:30|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\inetmib1.dll|Accessed Time (atime)
2009 11 04 09:35:30|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\netstat.exe|Accessed Time (atime)
2009 11 04 09:36:53|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\wbem\wbemperf.dll|Accessed Time (atime)
2009 11 04 09:36:53|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\systeminfo.exe|Accessed Time (atime)
2009 11 04 09:36:55|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\wbem\stdprov.dll|Accessed Time (atime)
2009 11 04 09:41:17|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\tasklist.exe|Accessed Time (atime)
2009 11 04 09:43:27|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\nbtstat.exe|Accessed Time (atime)
2009 11 04 09:46:58|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\RECYCLER|Change Time (ctime)
2009 11 04 09:46:58|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\RECYCLER|Modified Time (mtime)

Okay, here is the hot and juicy stuff.  Wow, look at those Access times.  Access times on executables are indicative of the execution of these programs.  “Netstat”, “Systeminfo”, “tasklist”, and “nbtstat”.  All one after another? Very interesting.  The accessed DLLs also show us that other programs might have been run around this time.  SNMP?  Simple Network Management Protocol – a little network management anyone? WBEM? Web-Based Enterprise Management.  Definitely more reconnaissance behavior.

I would also like to point out that this activity appears to have occurred approximately ten minutes after the backdoor was placed on this system using the scheduled task.  So, following logic, this system was compromised from another system within the network.  The attacker completed the working on that first system (possibly similar reconnaissance efforts) and then connected to this system via the backdoor.  Why the backdoor?  Well, logging is turned on.  There is no network logon event.  This could very well mean that the user’s actual credentials have not been compromised, YET.  Or, this could mean the attacker did not want to generate a logon event, or it could mean that he required some functionality provided by the backdoor.  We are starting to read into this a little too much at this point.  But our initial thoughts, compromised from another system on the internal network and performing reconnaissance steps, are still sound.

2009 11 04 10:12:46|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034337.properties|Accessed Time (atime)
2009 11 04 10:12:46|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034337.properties|Change Time (ctime)
2009 11 04 10:12:46|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034337.properties|Modified Time (mtime)
2009 11 04 10:13:10|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\Administrator\Local Settings\Temp\vmware-user\vmware-3856-mks-user-476.log|Accessed Time (atime)
2009 11 04 10:13:10|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\Administrator\Local Settings\Temp\vmware-user\vmware-3856-mks-user-476.log|Change Time (ctime)
2009 11 04 10:13:35|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\D\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP33|Created Time (crtime)
2009 11 04 10:13:35|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\D\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP33\change.log.1|Created Time (crtime)
2009 11 04 10:13:37|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\D\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034288.dll|Change Time (ctime)
2009 11 04 10:13:37|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\D\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034288.dll|Created Time (crtime)
2009 11 04 10:13:37|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\D\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034287.dll|Change Time (ctime)

Ah, the System Restore Point.  This simple occurrence could be very helpful indeed.  It is quite possible that the Upsxxx backdoor was captured and stored in this System Restore Point.  This is very useful information especially if the malware has rolled over to a new version.  If your security team is looking for a different version of the backdoor, systems compromised with the version captured in this restore point may still be beaconing or allowing access to your environment.  Time to dive into these System Restore Points and see what they yield.

Hopefully you have found this helpful.

Go forth and do good things,

Don C. Weber

The other day I was handed a system that was known to be compromised with Hydraq.  The goals were to determine when, how, and what happened after the compromise.  Locating the malicious process during memory analysis was easy with so many known system artifacts.  Not really very useful although it did determine that the rasmon.dll program did contain a domain name unique to the rest of the intelligence from the Internet.

I follow a very specific initial process when appoaching compromises on Microsoft Windows systems.  Keyword searches, timeline generation, and registry analysis top my list unless inidcators point me in a different direction.  Keyword searches on unallocated space and the systems pagefile did not provide any positive information related to the goals.   So I moved onto identifying the backdoor’s service to have a little more information to use during timeline analysis.  Easy enough with a quick review of the Service Registry keys.

System\ControlSet001\Services\RaSuPoo – Date Modified: 1/12/2010 11:05:40 AM
Description – ** NONE PROVIDED **
DisplayName – ** NONE PROVIDED **
ImagePath – %SystemRoot%\System32\svchost.exe -k netsvcs
Parameters – Date Modified: 1/12/2010 11:05:40 AM
ServiceDll – c:\windows\system32\rasmon.dll
Security – Date Modified: 1/12/2010 11:05:40 AM

Right off the bat I noticed a few things that were interesting.  Neither the “Description” nor the “DisplayName” key values were present.  Although they are listed here it is only to note that they were missing completely.  Now these things might be unique to this system but they are definitely indicators that can be used to identify other compromised systems with in the environment, possibly even if the backdoor is rolled over to a different version by the attackers.

Something else that is important to note is the matching “Last Write” for the primary registry key and the subkeys “Parameters” and “Security”.  When these times do not match I rely on the times provided by the “Security” key to determine the likely date and time that the system was compromised.  As these times matched for this service I was initially inclined to utilize these times as indications of the initial compromise.

Additional review of the services using intelligence from the Internet located other malicious services.  The following Registry information represents one of these malicious services.

System\ControlSet001\Services\AppMgmt – Date Modified: 1/12/2010 11:05:40 AM
Description – Provides software installation services such as Assign, Publish, and Remove.
DisplayName – Application Management
ImagePath – %SystemRoot%\System32\svchost.exe -k netsvcs
Parameters – Date Modified: 10/14/2009 01:25:37 AM
ServiceDll – C:\Documents and Settings\Administrator\AppMgmt.dll
ServiceDllUnloadOnStop – 00000001
Security – Date Modified: 4/4/2005 12:24:16 PM

There are several interesting things to note about this process.  First of all is the location of the AppMgmt.dll.  This location should flag this service as malicious during a manual review of running services as well as when this service is running in memory.  The “Last Write” time of the “Parameter” key is a good indication of the date and time the system was compromised by this backdoor.  After additional review this seems to be the earliest indication of compromise.

Continuing with timeline analysis produced an interesting finding from the event logs.

2010 01 12 11:05:40|SysEvent.Evt – EVT|INF-SYS|S-1-5-18|Service Control Manager/7035;Info;RaShniI,stop

As you can see, the backdoor service with a different random key name than the current registry setting has stopped.  Now, this could be typical behavior associated with the functionality of the backdoor or it could be indications of another malware rollover to a new version.  However, now we have additional indicators for the timeline analysis.  A little fancy searching produced sixteen other instances of randomly named services that stopped and produced an Event Log entry.  Timeline analysis also produced several instances of systems restarting as represented by the “Task Scheduler Service” starting.

2010 01 11 11:40:09|Task Log|INF-SYS|”Task Scheduler Service”   Started at 1/11/2010 9:40:09 AM|0

Continued review provided an even more interesting finding.  Instances of a LEGACY registry key for each “stopped” service associated with the backdoor.

2009 10 29 05:48:46|Registry Hive: system|INF-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_RAS0HWK/0000

Additional investigation of the System Registry Hive produced the following information.

System\ControlSet001\Enum\Root\LEGACY_RAS0HWK – Date Modified: 10/27/2009 5:18:46 AM
0000 – Date Modified: 10/27/2009 5:18:46 AM
DeviceDesc – RaS0HWk
Service – RaS0HWk

Then, after trimming the fat from timeline entries the following details emerged.  I have trimmed these a bit for brevity.

2009 10 27 05:18:59|Task Log|INF-SYS|”Task Scheduler Service”   Started at 10/27/2009 13:18:59 PM|0
2009 10 27 05:18:46|Registry Hive: system|INF-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_RAS0HWK/0000
2009 10 27 05:19:17|SysEvent.Evt – EVT|INF-SYS|S-1-5-18|Service Control Manager/7035;Info;RaS0HWk,stop
2009 10 30 09:10:55|Task Log|INF-SYS|”Task Scheduler Service”   Started at 10/30/2009 17:10:55 PM|0
2009 10 30 09:10:43|Registry Hive: system|INF-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_RAS1DBH/0000
2009 10 30 09:11:19|SysEvent.Evt – EVT|INF-SYS|S-1-5-18|Service Control Manager/7035;Info;RaS1DbH,stop
[snip]
2010 01 11 01:10:49|Task Log|INF-SYS|”Task Scheduler Service”   Started at 1/11/2010 9:10:09 AM|0
2010 01 11 01:10:44|Registry Hive: system|INF-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_RASX4NS/0000
2010 01 11 01:10:01|SysEvent.Evt – EVT|INF-SYS|S-1-5-18|Service Control Manager/7035;Info;RaSX4nS,stop
2010 01 12 01:55:02|Registry Hive: system|INF-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_RASHNII/0000
2010 01 12 01:55:18|SysEvent.Evt – EVT|INF-SYS|S-1-5-18|Service Control Manager/7035;Info;RaShniI,stop

Now, this backdoor behavior is significant because I have not found any reference to this restart behavior in any of the Hydraq malware analysis reports.  It also means that the Last Write times for the “RaSuPoo” service registry key is not indicative of the time that the AppMgmt rolled over to the new backdoor.  Whether the restart behavior was intentional or not this behavior has successfully obfuscated some critical system information that may not have been apparent had it not been for timeline analysis.

Additional analysis of timeline data using the LEGACY data also revealed another significant finding.  Malware reports related to Hydraq provide mention of a backdoor service with the name “Upsxxx” where [xxx] are random.  Timeline review revealed a LEGACY key for this service.

System\ControlSet001\Enum\Root\LEGACY_UPSYVM – Date Modified: 10/27/2009 4:07:09 AM
0000 – Date Modified: 10/27/2009 4:07:09 AM
DeviceDesc – UpsyVm
Service – UpsyVm

The significance of this registry key is not the fact that it appears to have been created before the earliest RaSxxxx service keys.  Rather it is the fact that there are no Registry entries pertaining to the initial Upsyvm service keys.  This means that the original service keys were deleted once this backdoor was rolled over to the new backdoor.  Another significant finding revealed during timeline analysis.

Now, none of these indicators provide details about the “smoking gun” – manual activity – that has taken place on this system.  However, understanding all of these activities provides a complete understanding of the series of events that could lead up to manual malicious activity on other systems.  Details of system artifacts and backdoor activity times will help identify other compromised systems and other activities.  This information also provides new methods that are being used to obfuscate data and hide critical details about events following a compromise.  Hopefully the information provided here helps you overcome some of these techniques.

Go forth and do good things,

Don C. Weber

System Combo Timeline has been updated.  If you use syscombotln you will want to get this new version as there is an important bug fix.  I have also updated regtln.pl and evtparse.pl to handle double-byte and non-printable characters better.  This helps when analyzing log and registry files from Windows systems with various language packages.  Of course I do so my just stripping out the unwanted characters from the data entries.  You do not loose this information as you always have the original files.  But if you want/need to review the original entries you will need to review the original files.  These two tools are also available individually on the Scripts and Tools page.

PrefetchFolderAnalysis2.EnScript is a new addition to the Scripts and Tools page.  This EnScript was originally developed by Kelcey Tietjen.  I have updated it so that it outputs in TLN format and writes a file to the Export directory configured in EnCase.  It uses the last run time to place the entry in the timeline at the last time the file was executed.  If you integrate the results of this EnScript with the system’s File Directory listing you will have this included with MAC times.  Special attention, however, should be paid to the data entry.  The data will contain the original path of the executed command and the number of times that it was executed.  Extremely helpful during analysis.

If you would like to integrate the output from PrefetchFolderAnalysis2.EnScript into your timelines generated from syscombotln just place the resulting file into the “output” directory with any other TLN formated files you have created.  Running the syscombotln script will concatenate them all together.

Go forth and do good things,

Don C. Weber

One of the keys to incident response is to reduce the gap between compromise and when an organization starts taking action.  There are a number of tricks to identify compromised hosts.  Most organizations retain all types of logs for any number of reasons.  Unfortunately, auditing and never really using logs for anything except for records retention can cause organizations to treat them as merely objects to move around and not necessarily utilize for any action.  Even organizations who perform monitoring and effective records retention have a tendency to store and forget about older logs.

Access to old logs becomes painfully necessary during an incident response.  Without a well thought out and tested access plan, review of older logs can be a tedious and time consuming effort.  This can be further complicated by resources such as server load caused by searching and network connectivity caused by transfer.  I have experienced a few of these problems recently and I thought I would share them so that you can use them to prepare to reduce the response gap within your organization.

Firewall logs get large quickly.   The size of the organization is usually going to determine the length of time logs will/can be retained.  How long does it take you to search all of your firewalls back six months?  This becomes very important when firewall management and log storage have been outsourced to another organization.  What are your service level agreements for request response times?  Have you tested this response time?

Firewall log review will help you identifying internal IP addresses that connection to external IP addresses.  Now what do you do?  Well, if your environment is made up of static IP addresses this works just fine.  What happens if your organization utilizes DHCP for connectivity?  How long do you retain logging information for your DHCP leases?  How fast does it take to correlate firewall search results with the DHCP leases?  If you cannot answer these questions then additional testing will be necessary.

Monitoring for specific IP addresses is one thing, but often the information you have may be related to specific domains.  This means that DNS request logs become very important.  All of the same review questions apply.  Concerns about outsourced DNS apply.  Testing applies.

Time for a little math.  Let’s say you have an IP address of a known malicious server on the Internet.  If it takes you two days to search your firewall logs for connections and then it takes you an additional two days to correlate that information with DHCP logs, your incident response gap is four days.  That is four days before you can even begin applying your incident response process.  Four days before you can start requesting legal permission to adhere to law and regulations where the system resides.  Does it take two days for legal approval?  Now you are up to six days.  Do you have data analysis personnel that can respond to all of your locations?  Add two more days to mail systems and data analysis doesn’t begin for eight days.

Hopefully this helps.  Please test your computer incident response plan.  When you do, think outside of the box.  Ask additional questions.  Request information and time how long it takes.  Conduct lessons learned followed up with specific and managed goals.

Go forth and do good things,

Don C. Weber

System Combo Timeline:

The syscombotln tool has been updated to fix several bugs and time/date issues.  I have also decided to stop being lazy and updated all of the internal modules and external scripts/tools associated with this tool to properly handle the TLN format as Harlan outlined. This includes the TLN.EnScript which is NOT included in the syscombotln tool.

New functionality includes parsing the Windows XP setupapi.log file.  I have included this functionality due to a little analysis trick pointed out to me by Jason Luttgens and Jon Gross of Mandiant.  Basically any time a Windows Help (chm) file is executed the information is logged in the user’s HTML Help (hh.dat) file.  This information can be used to specify some Initial Infection Vector information.  This information, in turn, may be augmented by driver-based information which, in Windows XP, is logged in the setupapi.log file.  I cannot provide specifics at this time, but I can tell you that you will know suspicious entries when you see them.  (If anybody has specific examples, please provide them in the comments.)  Although I have not had time to parse the hh.dat file, I have had time to parse the setupapi.log file.  The syscombotln module for this file is very basic but it should handle all files well (please let me know if you experience cases where it does not).  An added benefit of parsing this log file is that external USB storage device installation information will also be added to your timelines.  And if there are anti-forensic efforts recommending deleting this log, you know we want to review it’s information and add it to our timelines.

IronGeek Resource:

Just a quick note.  When researching the information in the last post I ran across this great resource by IronGeek.  Once again he has posted some amazing content.  Take a look at his “Forensically interesting spots in the Windows 7, Vista and XP file system and registry” resource.  You might have known about this, but it is new to me, so just in case you missed it as well.

Scripts and Tools:

I have decided to start uploading my scripts and tools when I generate an update.  To this end I have created the Scripts and Tools page which includes some Window Registry tools (including some older RegRipper plugins) and a few Enscripts.  Check this page often for updates and new scripts/tools.  Leave comments with comments, updates, requests.  To help with consistency, I have also started using Subversion to help me track development of all my projects.  Basically because I have been brow-beating (unsuccessfully) Harlan to do the same with his tools.  I have started keeping all my projects on an external USB drive (which I backup often).  To keep each project separate I use the following steps.

1. Copy folder to Projects directory.
2. Type “svnadmin create /media/<usb drive>/Dev/Projects/Repo/<project name>”
3. Type “svn import <project name> file:///media/<usb drive>/Dev/Projects/Repo/<project name> -m “Initial Import”
4. Move original project directory “mv <project name> <project name>_bk”
5. Check out repository “svn checkout file:///media/<usb drive>/Dev/Projects/Repo/<project name> <project name>”
6. Double check files are there and work with it a little while.
7. Delete _bk

This works across Linux systems and should work on Windows systems using something like tortoisesvn.  Hopefully you find that useful for your script and tool development.

Tired of doing a lot of work by hand I have started a project to quickly generate a timeline file from system artifacts recovered from systems running a Windows operating system.  The goal is to quickly generate information that can be used to determine actionable intelligence during an incident response.  System Combo Timeline is a set of scripts that will internally generate or use external tools (thank you, Harlan) to generate TLN-based timeline files from specific system artifacts.  These files are combined into one TLN-based file with can be reviewed with the hope of understanding some of the actions that occurred on the system.  Information taken from this TLN combo file can be used to direct the rest of the analysis or even provide information to help guide future incident response activities.

Hopefully you find this tool useful. There is still a lot of work to do to pull in additional capabilities and make the tool more flexible.  As always feedback and requests for features are always welcome.  Leave a comment and let everyone know what you think about the tool.

Go forth and do good things,

Don C. Weber

Being able to utilize multiple tools is key for any digital forensic and incident response analyst.  However, moving back and forth between different operating systems or starting and stopping memory intensive tools can have an impact on quickly exporting critical information from a system.  The FLS utility provided in the Sleuth Kit tools produces an excellent bodyfile and is, in my mind, the default standard for generating timeline information.  However, if you are working in EnCase, it would be nice to have a method to quickly output a bodyfile text file that can be quickly integrated with other timeline information for a more in-depth and detailed analysis.

After a bit of trial and error working with EnScripts I decided to contact Lance Mueller to get over a few EnScript hurdles.  Lance quickly updated my initial code and helped me understand how to gather file information and output the information to a text file.   After a few more tweaks I now have a working BodyFile EnScript.  The only real difference between the bodyfile generated by this EnScript and the FLS bodyfile is that the EnScript file times are provided in a human-readable format whereas FLS outputs in Epoch time and needs to be converted prior to evaluation.

Although this was very useful when generating timelines from multiple sources, I often found myself modifying the bodyfile to match the Timeline (TLN) format outlined by Harlan Carvey from his blog post:  Timline Analysis, pt III.

Time - MS systems use 64-bit FILETIME objects in many cases; however, for the purposes of normalization, 32-bit Unix epoch times will work just fine

Source - fixed-length field for the source of the data (i.e., file system, Registry, EVT/EVTX file, AV or application log file, etc.) and may require a key or legend. For graphical representation, each source can be associated with a color.

Host - The host system, defined by IP or MAC address, NetBIOS or DNS name, etc. (may also require a key or legend)

User - User, defined by user name, SID, email address, IM screenname, etc. (may also require a key or legend)

Description - The description of what happened; this is where context comes in…

I have to admit that I don’t always follow this format to the letter for one reason or another.  I often use the last two fields as open fields for specific information about the artifact that I am documenting.  Where I can I provide “User” information, but remembering to be flexible allows me to include valuable information, although, it would also be just as easy to tack it on the end as well.

After a few times of converting the EnScript bodyfile to TLN format I decided it was just better to have an EnScript that output into TLN format.  Thus I now have the TLNFile EnScript which can easily be integrated with other TLN formatted files to create excellent timelines.

Go forth and do good things,

Don C. Weber

I have been a little busy of late.  Work, family, and a few side projects have taken up a lot of my time.  Good news, however, I am ready to make one of those side projects public.  That project is an e-magazine for digital forensics and incident response called Into The Boxes.

I don’t want to say too much about Into The Boxes here as everything that needs to be said is already on the sight.  Harlan Carvey, my partner in this project, has already created a post to welcome you all to the e-magazine.  We are hoping that you will find time to contribute to the first edition that will be released in the first week of January 2010.  This project is only going to be as successful as the people who are willing to share their knowledge and experiences.  Harlan and I will contribute as much as possible but we are hoping that the security community steps up to the plate, puts the word out, and starts providing technical and managerial input that security professionals working in the digital forensics and incident response field can implement.

I hope that you will visit the Into The Boxes website.  I also hope that you will help us make this a great resource for the security community.

Go forth and do good things,

Don C. Weber

Slow week, again.  My wife is loving it that I have been at home recently.  It’s good to be wanted.

Leadership

I have been plowing through the Enderverse over the past month.  My wife finds it weird how I get fixated on reading.  I am not surprised that it is new to her because I have not really read a non-technical book since completing my Master Degree in 2005.  The whole time she has known me the only thing she has really seen me get fixated on (other than task completion) is moving through a new video game.  I guess she should have seen the signs.

Reading the full Ender and Bean series has helped me understand Ender’s Game a lot better.  These books show the importance of understanding yourself, understanding the people you work with, understanding the people you work against, strategy, and many other leadership qualities.  Certainly you can get these from other books, but the Enderverse does a good job of showing enough of both sides of the story to understand motivation.  Which I am finding to be the biggesst take-away from this series.

Orson Scott Card demonstrates how effective it is when leaders understand an individual’s motivation.  Actually, it goes a little deeper that than.  He has his main and most successful characters leading by understanding what the people around them actually “need.”  They take those needs into consideration for their own plans and actions.  Whether it is a personal relationship or it is military strategy.  These characters are most successful when they step back, take a moment for consideration, and modify their plans and judgments (when necessary) to accommodate the needs of the people around them.  Doing so usually wins that character the professional respect, friendship, and sometimes devotion.

How can we use this in our professional and personal lives?  Well, I think the best away to do this is to take a few seconds before answering questions or providing opinions during conversations (live or digital).  A few extra seconds pause during a phone call is not as long as it actually seems on your end.  Pauses are natural in face-to-face conversations because it is easy to see when somebody is thinking.  If people on the other end of the line do get impatient, just ask for a second while you are thinking or formulating a response.  It will be a rare occasion when somebody gets offended and it will be more likely that they respect you for being considerate and thoughtful.  Email and IM is another great example for a pause.  Get up, walk around, and don’t answer until you have given a little thought to your position in combination with the other person’s needs.    You can even do these types of things in meetings and one-on-one conversations.  Taking a few moments to lean back and ingest the facts of the conversation is easy and common.  For heated conversations or times when you need more time to think about it, use the bio-break method to get some extra time.  Get up, go to the bathroom, get a glass of water, and think about your position, your stratagy, and weight that with the needs of others involved in the situation.  It doesn’t matter if others know you are just using it as an excuse, nobody is going to deny anybody a bio-break.

Quick Tip

I have been working on a bit of code for several months now.  I am getting into the fine-tuned debugging and I hit a snag.  One piece of advice that the mentor for my project gave me was “never be afraid to revisit and rewrite your code from scratch.”  Well, I am not there yet.  But I am to the point where I understand that I may have made a mistake with my implementation and I need to determine how much I need to change.  Of course, now that the code is at 1855 lines (with comments) it is a little harder to scroll back and forth to find all of the areas that need to be adjusted for the implementation change.

I have decided to fall back to printing and editing by pencil.  It should not be too hard but 1855 lines of code divided by 80 lines per page is 23 pages of code.  Ouch.  Of course there are easier ways to do this.  People have been writing and printing code for years and there are all types of tips and tricks.  *nix OSes are naturally full of different methods for converting text to printer and other document formats.  (Now that I think about it that sounds like the potential for vulnerable programs and scripts is huge….hmmm…but I digress).  Actually I knew this already and I use to have a nice little script that would print two pages per sheet, in landscape, and modify the font so that it was small but not too small to read and edit.  A quick look showed me that I had disposed of that code a long time ago (several OSes ago).  But, the Internet is rich with ideas and methods.  I ran through some instances of enscript (not to be confused with EnCase’s scripting language) which seems to be the defacto method nowadays.  But for some reason it just wasn’t working for me.  AND it was not the method I used before (we are all creatures of habit) so I continued my search until I found my one true-code-printing-love: a2ps. A quick review of the very helpful man page gave me the syntax I needed to convert the file I want to print to a postscript file  (my computer is not connected to a printer right now and I have to use a friend’s).  I ended up with the following command line (I will let you review the man page to understand the options):

a2ps -2rjC -Epython -o ptr-file.ps ptr-file.py

Easy, but what if my friend’s system cannot read Postscript files?  Doubtful but just to be certain I decided to quickly convert to PDF via command line.

ps2pdf ptr-file.ps ptr-file.pdf

Yes, yes.  It would have been much easier to combine these two commands.

a2ps -2rjC -Epython ptr-file.py | ps2pdf – ptr-file.pdf

Enjoy.

Personal Input

Read more non-technical books.  It is good for you and it is good for your kids (if you have them) to see you reading instead of watching TV, or cleaning the house, or doing yard work, or playing with them, or……dang it!!!! 

Go forth and do good things,

Don C. Weber