Craving for time? Carve some timestamps out… – TimeCraver v0.1

Analysis of binary data is always challenging. Data can be encrypted, encoded, and stored in a number of proprietary formats. Understanding of what data represents and how it is stored is non-trivial. It typically involves either analysis of the code that writes stuff to a file, or trying our luck by guessing what is a possible structure of the actual data. The typical approach is to simply look at it and its properties.

This can involve checking its entropy and how it changes over the file, looking for patterns typically associated with popular compression algorithms, attempting to brute-force various trivial encryption algos, checking if any data is recognized as a string, Unicode string, localized string, a potential absolute or relative offset to other data, or maybe a byte-, word-, dword- long length preceding data etc.

One of the most popular tools that is used to analyze unknown data is binwalk and it helped me on many occasions by providing hints on what is possibly ‘in the file’. Sometimes, even if it didn’t recognize anything interesting was also a good hint – typically meaning encryption, or something really unusual/proprietary.

Existing tools are always handy, but I can’t count how many quick & dirty (and often completely stupid) scripts I wrote to get some data to look more ‘reasonable’ and ‘normal’.

In today’s post I am showing a simple example of such ‘unknown data analysis script’.

When we see a binary file, we typically run ‘strings’ on them and we gather a nice readable ‘printable’ data for analysis.The ‘non-printable’ is also interesting though, so another tool I often run is a strings-like script that carves timestamps out. This comes handy for smaller files, especially for these that look like a config, a quarantine, and anything really that looks like may have  a potential timestamps embedded in it.

Carving works following a simple rule – read 4/8 bytes, convert it to an epoch using various conversion algos (based on assumed timestamp format), see if epoch converts to a date between years 2000-2015, and if it does – just print it out, together with the offset and some extra metadata.

Example:

     00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F   0123456789ABCDEF
---------------------------------------------------------------------------
00 : 80 86 F6 34 00 C0 5D CE 56 CF CD 01 00 40 FA 13   ...4..].V....@.. 00
10 : 0F 00 CE 01 00 40 8B B7 0F 16 CE 01 00 80 59 DA   .....@........Y. 16
20 : 6B 2E CE 01 00 00 BE D2 FE 45 CE 01 00 A4 03 01   k........E...... 32
30 : 85 95 C2 01                                       ....             36

Looking at such binary data doesn’t give us much useful information.

Running timecraver over it, gives us the following:

===========================================
 TimeCraver v0.1, Hexacorn.com, 2015-08-23
===========================================
00000000,DOSTIME ,44C257B0,2006-07-22 16:52:00,8086F634
00000004,FILETIME,50B94880,2012-12-01 00:00:00,00C05DCE56CFCD01
0000000A,EPOCH   ,400001CD,2004-01-10 13:44:45,CD010040
0000000C,FILETIME,510B0580,2013-02-01 00:00:00,0040FA130F00CE01
00000012,EPOCH   ,400001CE,2004-01-10 13:44:46,CE010040
00000014,FILETIME,512FEF7F,2013-02-28 23:59:59,00408BB70F16CE01
0000001C,FILETIME,5158CDFF,2013-03-31 23:59:59,008059DA6B2ECE01
00000024,FILETIME,51805B00,2013-05-01 00:00:00,0000BED2FE45CE01
00000026,EPOCH   ,45FED2BE,2007-03-19 18:13:18,BED2FE45
0000002C,FILETIME,3DE3D068,2002-11-26 19:50:00,00A403018595C201

The first column is an offset, followed by the timestamp type, then hexadecimal EPOCH calculated from the data, then its YYYY-MM-DD hh:mm:ss representation and finally the actual bytes from the file that are converted to EPOCH.

The data is immediately more readable and certain conclusions can be drawn. If you look at the offsets, distance between them and type of timestamps you may actually ‘see through’ the data and potentially ‘define’ a reasonable structure.

In this particular case, we can see that FILETIME is

00000004, 0000000C
00000014, 0000001C
00000024, 0000002C

– looks like a sequence of FILETIME records. Following this logic, we can guess that structure of the file is potentially like this:

00000000,DOSTIME ,44C257B0,2006-07-22 16:52:00,8086F634
00000004,FILETIME,50B94880,2012-12-01 00:00:00,00C05DCE56CFCD01
0000000C,FILETIME,510B0580,2013-02-01 00:00:00,0040FA130F00CE01
00000014,FILETIME,512FEF7F,2013-02-28 23:59:59,00408BB70F16CE01
0000001C,FILETIME,5158CDFF,2013-03-31 23:59:59,008059DA6B2ECE01
00000024,FILETIME,51805B00,2013-05-01 00:00:00,0000BED2FE45CE01
0000002C,FILETIME,3DE3D068,2002-11-26 19:50:00,00A403018595C201

I can confirm it since it is one of the test files I created 🙂

The script can be found here.

Happy craving & carving !

Bonus: if you look at the data in Registry, you will find more timestamps than you thought are actually there. This is a subject for another post 🙂

Update

Bonus will be here faster than expected – turns out Andrew Case, Jerry Stormo, Joseph Sylve, and Vico Marziale wrote an awesome python script for timestamp carving in Registry

Are you a Canon or Nikon?

In a world of photographers there is a very common question exchanged between the peers which goes something along the lines of:

Are you a Canon or a Nikon user?

Sometimes it goes beyond that and includes other brands: Fuji, Sony, Leica, etc., but the strong association with brand is err… a canon itself, at least in a photographic world.

The ability to love, or at least stick to one brand has benefits – you get really familiar with the brand, things fit, loyal customers can leverage the long-term relationship in many ways and sometimes it simply makes sense to be really good at one thing.

The world of security adapted this principle and applies it one by one to various security controls.

There are just a few of antivirus companies that matter and everyone can quickly associate themselves with one of them.

The very same goes for firewalls.

And DLP solutions.

And old-school forensics tools.

Even sandboxes seem to be there already.

Etc.

IR solutions are IMHO still not there.

The differences between a good IR solution and a less-good IR solution are slowly emerging though.

These are for example:

  • Ability to deploy and rapidly gain the best coverage within any organization, no matter what network topology they use
    • Whoever can deploy faster and cover more quicker, wins
  • Ability to fetch host’s volatile data is crucial
    • Whoever does it in real-time does it better than sweepers
  • Ability to fetch / monitor data from both kernel and userland
    • Whoever can do it for both lands, is a winner
  • Ability to sweep is still a very valuable add-on (they may detect campaigns AV doesn’t detect, web shells, etc.)
    • Whoever offers both sweeps and real-time analysis, wins
  • Ability to fetch data in the most forensically sound manner
    • Whoever does it and ends up with the least contaminated host wins
  • Ability to interact with the host’s volatile data (more precisely: with the actual object f.ex. processes)
    • Malware removal is often as easy as killing the process and removing the file – whoever allows analysts to do it on the spot, wins (old school IR relies on psexec, help from a dedicated desktop/server team or even user to remove these and not uncommon is a full system rebuild)
  • Ability to easily update
    • Whoever does it in a way that is ‘invisible’ to everyone involved, wins

Many of these are well-known and faced – for many years – by AV companies. Theirs are ones of the most prominent solutions deployed on endpoints today. It often boggles my mind that they have overslept the whole DFIR revolution that happened over last 5-10 years. It’s such a corporately-speaking “low-hanging-fruit”.

Adding IR capability to AV product is such a no-brainer. Someone, please explain 🙂

This is still a time of experiments in IR world and there is no pool of shortlisted winners yet.

It is NOT wise to change IR vendors often now.

Let these that are fighting for the market battle with each other, and winners will emerge.

If you have already purchased something from one vendor, do not rush on buying stuff from a new one.

The corporate world is currently divided into 4 IR buckets:

  • these who don’t know what they don’t know – these are destined to fail a.k.a. being epically pwned
  • these who know that they don’t know something – these are destined to fail, but at least are not surprised
  • these who know what they know – they may fail gracefully
  • these who know what they know, and potentially try to learn about the unknowns – a few lucky ones that have a (relatively) mature IR program implemented; they may still fail, but it will be a really graceful fail a.k.a. IR mission accomplished

If you see similarities with four stages of competence – this is not accidental.

Ignorance in this industry is omnipresent and mind you – it includes yours truly. We are all firefighting a lot. The complexity of the IT Security is beyond a reach of a single individual, single vendor, single brand. Full stop. I think this is the world where the dry, theoretical certificates like CISSP/CISM meet the juicy, technical SANS exams. You use knowledge from CISSP/CISM (security controls & their management) and apply your technical knowledge (choose the best security controls & proper IR/forensics) from SANS courses to defensively ‘pwn’ your company internally.

I guess it’s time to reveal the real purpose of this post.

You need many security controls. Choose one for each area that requires coverage, and stick to it. Do not flip them like burgers every 1/2/3 years. You want to invest once, deploy once, know it inside out and gain maximum coverage. The time to realistically deploy and fully understand each security control (to the level of ‘defensive pwnage’) is – in my personal opinion – 2-5 years. (there are many reasons for this taking so long: complicated network topology, legacy infrastructure, collisions/overlaps with other projects, ensuring business is affected in a minimal way, gradual deployment, staff changes, and then bugs, configuration issues, of the products themselves, etc. The other reason, especially for IR solutions is their immaturity. Many IR solutions are built in the garage, the only real field test they go through is when some company allows the IR vendor to put a foot in a door and give them access to the environment to test the waters. This is a real QA phase. If you are company doing the QA you will spend a lot of time troubleshooting. It’s ironic, because instead of being a customer, you are actually performing QA for the vendor. So, overall, it costs a lot of time and money to deploy ONE solution.

This is why I think the IR vendor change should be based not on budget or even merit, but on the coverage of the existing IR vendor (of course, if they suck, you need to change).

Only when you cover let’s say 98% of your endpoints – look at alternatives*.

*In case you are wondering why – think of it this way: imagine you have a coverage of 98% with your current vendor (in a large corporate 98% coverage means there are still a lot of endpoints not covered- close to a few thousands, actually, but it’s a risk management, after all). Assuming the IR vendor you use is not some snake-oil company by the time you see this 98% coverage you may be quite sure that most of your endpoints are clean. Only then you should have a confidence to look for gains on the financial or even usability side, let alone whistles and fireworks that other vendors offer, because you know that you are going to deploy the new guy to the environment that is already 98% IR-managed.

At least, this is what I believe is true.