Steve Romig October, 2011

Transcription

Forensic Timelines
Steve Romig
October, 2011
Sunday, October 23, 2011
Agenda
•
What is a Forensics Timeline? Why should you be interested
in them?
•
•
•
How do you make them?
Some examples.
A few important considerations.
What, Why is a
Forensics Timeline?
What/Why are they?
•
A forensics timeline is a portrayal of chronological activity
gleaned from evidence pertaining to a forensic computer
investigation.
•
Much of what we do in forensics investigations revolves
around reconstructing past sequences of events.
•
We could include any sort of evidence that can be linked to
a specific time or to a range of times.
•
It is *very* helpful to “cast a wide net” as we construct our
timelines - this gives us a broader view of what happened
and can give surprising insights.
•
In the last few years this technique of merging time-based
evidence from multiple sources has been given a name
(“super timelines”) and some useful tools have been written
to help create and manage them.
How do you make
them?
How do you make them?
•
•
Step one: gather some time-based evidence
•
•
Step three: visualization
Step two: convert it to some common format and mush it
together
Step four: pour through it, understand it, interpret it,
annotate it, draw conclusions, look for more evidence, goto
step two, three or four and repeat
Gather Evidence
Gather Evidence
•
Any time-based evidence is fair game. The usual suspects
include: file system timestamps (so-called MAC times), logs
with timestamped entries (such as Unix “wtmpx”, netflow
logs, syslog, event log, etc.), the “recycler” folder, timestamps
within archives.
•
Check with your network folks to see what they might have:
netflow, firewall, IDS, authentication, DHCP, router or cable
modem logs...
•
Logs from any external service providers that might be of
interest (email servers, web sites such as blogs, Facebook,
Twitter, the phone/cable company, your ISP...)
Gather Evidence
•
Not so obvious sources:
•
•
Registry folder modification times.
•
•
Some Unix shell history files (if so configured).
•
•
•
Email (logs as well as messages).
Process start times (from “ps” listing or process
accounting records), end times (from process accounting).
Scheduled tasks, Cron entries, etc: compare against the
logs of this activity (anything missing that ran but didn’t
get logged, or didn’t run?)
Browser artifacts - history, cookies, bookmarks...
Packet captures from Tcpdump, Wireshark or equiv.
Gather Evidence
•
More not so obvious sources:
•
Anti-virus, anti-spyware logs: from the local machine, from
central servers.
•
Logs from Dr. Watson, Malware Bytes, HiJack This!,
Windows Defender...
•
•
•
•
•
•
EXIF data from pictures.
PE headers from binaries carry the compile time.
Chat logs.
Restore points, especially from the registry snapshots.
Mobile phones: calls, SMS...
Calendars!
How to Get the Data?
•
Use EnCase (or some similar forensics application)
•
Export file system entries as CSV (all fields). I find it
useful to do this once for everything, then again for all
“malware”, then for registries (pick “view file structure”
and filter for registry keys and export those). This allows
you to tag each in different ways in your data (and to
colorize them if you so choose).
•
Search for Internet History, and then export the resulting
records as CSV (again, all fields). This can result in a
tremendous amount of data...
•
•
•
Search for email, export...
Parse Event Logs and export the associated bookmarks.
Find interesting log files, “copy/unerase” them.
How to Get the Data?
•
•
Use Sleuthkit (or something similar, like SIFT)
•
•
e.g. “fls -m ‘C:/’ -f ntfs -r foo.dd > bodyfile”
mactime -d -b bodyfile > csvfile
Use timescanner (part of Kristinn Gudjonsson’s log2timeline
project, more on this below)
Convert to a Common
Format and Merge
Perl/Python
•
If you know Perl, Python or some other language suitable for
string manipulation, its easy to cobble together scripts that
read data in different formats and convert it to a common
format.
•
I’ve being doing this with Perl for years, and have scripts that
read EnCase exports (file times, internet history, event log),
netflow, bro, McAfee EPO, McAfee OnAccess scan logs,
UNIX wtmp logs, and others.
•
If you go this route I suggest that you convert everything to
CSV or TSV format, and use a common schema for the first
few columns: date, time, host, type of entry (file, internet, ids
log...), type of access (access, write, browse, ids alert, info
msg...) Trying to convert *all fields* of *everything* into a
common schema is difficult.
log2timeline, timescanner
•
But my scripts are goofy, and why go to the trouble when
there’s a better alternative. Kristinn Gudjonsson wrote
log2timeline to convert dozens of time-based data to
common formats (plural).
•
Reads: data from web servers, browsers, mactime body files,
McAfee, generic Unix logs, EnCase and FTK directory
listings, eventlog, pcap, metadata from EXIF, PDF, etc...
•
Writes: CEF, CSV, Simile, TSV/TLN, etc.
TimeScanner
•
Timescanner is a front-end to log2timeline. It reads a
directory tree looking for files that log2timeline can parse,
parses them, and exports the results.
•
Typical use would be to mount your evidence image as a
read-only filesystem(s) and then run timescanner against
them.
Visualization
EnCase Timeline View
•
I have a love/hate relationship with EnCase. The timeline
viewer is one of the parts that I hate. In fact, I loath it.
•
I’m sure there are people who find it useful.
Simile Timeline
•
The SIMILE project at MIT has developed a tool for
visualizing time-based events called “Timeline”
•
I’ve used this a little for visualizing events relating to
computer security incidents.
•
See http://simile.mit.edu/timeline/
Zeitline
•
•
Cool visualization aid from Florian Buchholz of CERIAS.
•
Main claim to fame: ability to group events together.
Allows you to import data from one or more sources,
“collate” it, view it, filter...
Use Splunk!
•
Splunk is particularly well-suited to accepting time-based
“stuff” and making it easier for you to make sense out of it.
•
The fact that it does “normalization” at search time makes it
flexible in the face of unknown input formats.
•
You can define fields “on the fly” and apply them at search
time, and then use these for correlation, pivoting, etc.
•
Extremely powerful and extensible search mechanism. You
can add your own perl/python extensions, and/or conduct a
search through the CLI and pipe that into a script.
•
Splunk rocks...
Never Underestimate...
•
Unix command line tools (sed, awk, grep and friends), Perl/
Python/Ruby scripts, and emacs!
•
Spreadsheets!
Figure it Out
Insert Comments
•
I find it helpful to insert comments (annotated somehow for
filtering, possibly color-coded) as I figure things out.
•
When you are done you can pull out the comments and get
a nice chronological summary of events.
A Simple Example
(Comments are marked with +++++)
2006-12-11 08:28:35 host1 fsys access inetinfo.exe
2006-12-11 08:28:35 host1 fsys access mmsm.exe
2006-12-11 08:28:35 host1 fsys access netman.dll
...
2006-12-11 08:28:36 host1 registry Folder all\host1_ld0\C\WINDOWS\system32\config\system
\NTRegistry\$$$PROTO.HIV\ControlSet001\Enum\Root\LEGACY_SRV\0000
\NTRegistry\$$$PROTO.HIV\ControlSet001\Services\lanmanserver\parameters
\NTRegistry\$$$PROTO.HIV\ControlSet002\Enum\Root\LEGACY_SRV\0000
...
2006-12-11 08:28:37 host1 fsys access dcrs.exe
2006-12-11 08:28:37 host1 fsys access dssenh.dll
2006-12-11 08:28:37 host1 fsys modify DCRSSDRV.SYS - hacker-defender ----2006-12-11 08:28:37 host1 fsys write DCRSSDRV.SYS - hacker-defender ----2006-12-11 08:28:37 host1 ----- +++++ bad things happening here!
Just the Comments...
2006-12-10 05:36:37 host1 ----- +++++ install drftpd, done at 5:47, system.exe
2006-12-10 07:09:45 host1 ----- +++++ drftp config modified
2006-12-10 09:17:34 host1 ----- +++++ drftp connects to 1.2.3.4:64998?
2006-12-10 09:26:56 host1 ----- +++++ minwinagent exploit from 4.3.2.1
2006-12-11 08:28:37 host2 ----- +++++ bad stuff here
2006-12-11 09:25:03 host1 ----- +++++ drftpd people are shutting down?
2006-12-11 09:26:05 host1 ----- +++++ minwinagent exploit?
2006-12-11 09:26:06 host1 ----- +++++ ping run, h-d modified
2006-12-11 09:32:37 host1 ----- +++++ more h-d changes
2006-12-11 09:38:13 host1 ----- +++++ drftpd changes
2006-12-11 10:14:09 host1 ----- +++++ system.exe run, modified soon
2006-12-11 12:10:55 host2 ----- +++++ serv-u config modified
2006-12-11 14:21:48 host1 ----- +++++ winlogon.exe fault
2006-12-11 14:23:02 host1 ----- +++++ mcshield.exe fault
Thrashing, er, Searching...
•
Say you’re investigating a compromised system. You’re trying
to determine when and how the system was compromised,
and whether it contains sensitive data and if so, whether that
data shows signs of having been accessed.
•
You might mount the disk image and do a search for
malware with a variety of tools, or search for sensitive data
with Identity Finder or some other DLP product. You can
tag these in some way (e.g. export as a separate CSV so you
can add a text field, or import them into a spreadsheet and
color them someway).
Searching
•
Assemble your timeline, including the specially tagged items.
Search for these tagged items in your timeline. These might
be comment-worthy in their own right, but you should also
look at events that are chronologically “near” these - these
might be signs of related activity (such as file system activity
for files that weren’t detected by your anti-malware scans).
•
You’ll want to look at the timestamps for all of the “events of
interest” and see whether there’s nearby associated activity
(other files, registry entries, log entries that look interesting).
Searching...
•
Activity in your timeline can be fast and furious or spread
over time.
•
Some malware waits for minutes or even hours before
taking action.
•
This can make it hard to identify “interesting activity” in a sea
of events.
Spreadsheet Magic
•
•
•
Searching
Filtering - show me only X, don’t show me Y
•
You can also do magic with grep, awk, sed etc. on the data
before importing it into your spreadsheet...
Colorizing - based on content
•
I like to colorize based on the “type” of entry (file system
data, internet history, IDS logs...).
•
I use light colors for “normal” activity and bright colors
for “hey, look here” activity.
•
I try to be consistent across investigations: Internet
history events are yellow, IDS logs are red, comments are
blue (sounds like the start of a bad poem...).
Login Spreadsheet
•
In some investigations we have looked at login sessions from
different sources: netflow, sshd (via syslog), wtmp and so on.
•
Making sense out of this can be confusing. The linear
timeline doesn’t help - sessions are overlapping, and there’s
too much data.
•
Simile timeline could be very useful here (and we’ve used it
for this sort of thing, pity I don’t have an example handy... :-)
•
Spreadsheets to the rescue again!
Login Spreadsheet
•
So now we have a list of sessions. We can see that our data
sources aren’t as complete as we’d like them to be - some
netflow data is missing, some syslog data was dropped (UDP
transport isn’t reliable), and some of the wtmp log entries
were zero’d out. But correlating them together gives us a
reasonably complete picture of everything.
•
It would be nice to “filter” the event timeline be login
session to get just the events that occurred “within” each
session. Easy enough with the appropriate Perl script...
Time Period Filtering
•
So, you’ve got a ton of data with overlapping login sessions
for multiple people. How do you make sense of it all?
•
One answer:
•
•
Make a list of sessions (defined by a start and end time,
typically drawn from TCP sessions from netflow logs, login
sessions from authentication logs, etc.)
•
Write a script which reads these sessions and pulls out
the event activity that falls “within” each session and
writes these to a separate output files.
•
Read the output files one by one to get a clearer picture
of what *might* have been related to activity in that
session.
*NOTE* see “A Few Important Considerations”, next!!
A few important
considerations.
Considerations
•
There are a few important things to keep in mind when you
are assembling or interpreting timelines.
•
Take all your evidence with an appropriately large grain of
salt.
•
Evidence could have been altered to change or destroy
“history”. For example: malware that changes its
timestamps to match system files, intruders who modify
system logs to remove entries.
•
Some timestamps (such as file system timestamps) only
show the most recent activity: past activity has been
obscured.
•
Some timestamps (file system access times, especially) are
not always updated.
Considerations
•
If you are merging data from multiple sources, beware of
time synchronization issues.
•
It is prudent to ensure that all of your computers, logging
devices, firewalls, etc. synchronize their clocks to common
reference (e.g. using NTP) *before* you need to conduct
an investigation.
•
If possible, confirm that events gathered from different
systems appear to have “sane” timestamps. For instance,
compare the time that a router recorded the creation of
an “ssh” connection to the time that the server logged
the connection.
Considerations
•
•
To correctly interpret the events in your timeline, you need
to understand what the events mean. That probably seems
obvious.
•
A login session involving the ‘romig’ account means that
someone using that account logged in, *not* necessarily
that the account owner logged in.
•
A DHCP lease means that a client with MAC address
00:DE:AD:BE:EF:00 was assigned IP address 1.2.3.4, *not*
that it was the only computer that *could* have been
using that IP address.
Beware time zone issues.
•
Some logs are in local time, some are in UTC. If you are
gathering events from multiple systems, are they all in the
same timezone?
Considerations
•
Correlating events together can be tricky.
•
One problem is event lag. Consider a ssh login session:
our Cisco router will generate a netflow record that
shows the time the first packet in the TCP connection
was seen. The login record for the person who logged in
won’t be created until they correctly authenticate, which
could be seconds or even minutes later.
•
Events that happen at roughly the same time may or may
not have anything to do with each other. For instance, if
there are 10 people logged into a multi-user system, it
would be difficult to tie file system activity back to a
specific person based solely on timestamps. Network
activity stemming from the computer might have been
triggered by one of these people, or by something left
running on the system by a previous user.
References
References
•
log2timeline, timescanner (by Kristinn Gudjonsson,
[email protected]): http://log2timeline.net/
•
Zeitline (by Florian Buchholz, [email protected]):
http://projects.cerias.purdue.edu/forensics/timeline.php
•
•
•
Simile Timeline: http://www.simile-widgets.org/timeline/
SleuthKit: http://www.sleuthkit.org
SANS SIFT: http://computer-forensics.sans.org/community/
downloads

Steve Romig October, 2011

Transcription

Similar documents

LeThe Wilvy_7 - Camp Wilvaken

basic human needs

Sheyann Webb, Memories of Selma

Beadling Soccer Demo

Empowerment Temple

Sunday Paper $1

Help us build a Finnish Cordwood Sauna

St-Cuthberts-for-Dton-Review-February-2014

Week03

MOVIE DAY