Tool Marks

I was reading a paper on tool marks and trace evidence and started thinking of how that translates to digital forensics. The connection is actually obvious.

From the paper: "The use and application of a variety of tools is commonplace during the commission of various criminal acts. By their very nature, the use of tools typically involves the application of relatively large amounts of force to gain a mechanical advantage in performing a work related task."

As we are well aware this is where Locard's name gets thrown in and everyone says "Ahh, transfer evidence".

In the digital realm we experience much the same thing. When an intrusion occurs, a variety of tools are used to exert a rather large amount of force (exploit, brute force, other means of gaining access) in attempt to gain access to the victim. We commonly recover these tools on investigation, but in order to reconstruct the incident we need to be able to determine how they were used during the attack, Their purpose and that the attacker did in fact use them. This is where tool marks come in to play.

The execution of a tool will leave a mark on a system, just as using a tool to gain entry will leave striations or other markings. With luck we might have a cross transfer - that is when the tool leaves a mark and parts of the object are transferred to the tool.

Here's an example:

Let's look at a hackerdefender attack that's been in process for a while. The attacker gained access to an exposed system by exploiting a vulnerability. The attacker downloads a toolkit on to the system consisting of smbscan, pwdump, and a few other tools. The attacker proceeds to offload the SAM, crack the admin password, then smbscans the network and installs rootkits all over the place.

As a tool leaves a mark on the surface it touches, the digital tool will hopefully provide us with tool marks and other transfer.

There are 4 major tool mark categories:

Striated - This is when two objects effectively scrape each other and the tool leaves a mark on the opposing object or vice versa. This is typically seen as lines from the marks - think pliers... The harder object will leave the mark on the softer object.

Impressed - The harder tool will leave an impression of itself on the softer object.

Crush or cut marks - When a tool exerts force on both sides of the object and crushes or cuts it. Imagine bolt cutters...

multi stroke - a tool used in a repetitive movement will leave multi stroke marks.

Time to bring this in to the digital realm...

Striated tool markings obviously can't exist or do they? Just as a tool has a "signature" it leaves on a softer material, a digital tool will leave markings on the victim. Refer back to the HXDEF example. The tool used to gain entry to patient zero will have left tool markings on the system and the network. Polymorphic code aside, the tool as used by the attacker will leave trace & transfer on the network. On the system you can expect to find a wealth of trace & transfer. A digital tool mark isn't about hardness however, it's about the effect it has on the system. Hacker defender has a definitive stria. It has an ini file, and many customizations can be made by the tool "manufacturer". Consider this tool striation and just as it happens in the real world the striations are unique because of tool usage and "manufacturing". You can see many of these unique striations on the network as well as the host.

Tool impressions - A physical tool will leave an impression if it's pressed in to a softer material. The digital tool will leave impressions of itself on a victim as it's buried in the system. The files in the toolkit that was downloaded by the attacker leaves an impression of themselves on the filesystem. These can be collected and analyzed.

Crush or cut marks are a bit tougher to identify in a digital realm.

Multi-stroke tools would be a saw, or any tool that it used in a repetitive motion to gain entry. Let's use the example above. SMBscan would be an example of a multi stroke tool. It uses a repetitive motion to gain entry to systems. It will leave marks of a definitive pattern.


So what's the big deal? Well if we start to look at tool marks we can begin to classify things a bit better and respond more efficiently. Tool marks are important to reconstruction and investigation. Tool marks can be broken in to class characteristics and individual characteristics. These start to become important as does the predictive nature of any assumptive hypothesis we can derive. Many of us do this already. When you see a hxdef.ini on a system, and there's an odd port open, you may inherently assume "uhoh weve got a hacker defender intrusion". This can be right or wrong. If you've developed a tool mark library you can refer to it during your investigations. Developing a tool mark library consisting of class and individual characteristics can assist any investigation by adding predictive power to your assumptive hypotheses.


EDIT 12/20/07 - The paper was: The Synergistic Nature of Trace Evidence and Tool Mark Examinations by Vincent J. Desiderio and George W. Chin

Digital Criminalistics

Once upon a time a forensics investigator would arrive on a scene and seize a computer. The scene would be photographed, evidence would be collected, bagged & tagged and so on. A few floppies would be collected, maybe a CD but not much more.

Fast forward about 10 years....

A forensics investigator arrives on scene to discover a wireless linksys router with a 4 port switch on the back. 3 wires connect to a triplex data drop in the wall. One room with a computer became a house with a computer in each room. A 3.5" floppy is now obselete, and data is every where. Did you remember the cell phone? The PDA? The camera, and the media cards? The DVR or media center computer? It just keeps going...

Even a few years ago as Incident Responders we knew what to look for. Botnets were rampant. They were easily detected and a vast majority of them followed the same standard. These attacks adapted and became more complex. Fast Flux networks are in full swing.


Digital Forensics is quickly becoming as complex as real world criminalistics. In the sea of agile data, we must be as agile. Our methods need to be fluid and adaptable. Simply pulling the plug is no longer the best practice. Digital Forensics doesn't begin and end on the disk. It begins at point A and ends at Point Z. There are many data points in between. We need to know what these points are, and how to collect relevant data from them. We must also understand the forces at work and how they influence the data to be collected.

After a scene has been contained..note I said contained. Let me digress....Containment is: the action of keeping something harmful under control or within limits. While pulling the plug is a method of keeping something harmful under control, we must understand that it is the most extreme method in use today. Pulling the plug is what I consider to be a knee-jerk reaction used due to lack of understanding of data, the forces at play, and the influences those forces have.

Getting back on track..after a scene has been contained, the evidence preserved and collected the reconstruction begins. This is where things can get difficult, because we as an industry don't have a scientific background for our field. Consider if you will that the source code of Windows is closed. This leads us to seeking empirical truth, or that which we can observe. This is actually converse to what we are seeking to accomplish. Simply because we can observe something, doesn't mean it's the only explanation. We can only ever hope to be obtain a level of certainty in our conclusions.

In search of science we begin with induction: "The timestamp was modified". After finding a binary capable of modifying timestamps we move quickly to say "This binary is responsible for modifying timestamps on the system". Is this correct? Maybe. It requires additional work to be a more complete conclusion.

Next we have deductive reasoning: "The timestamp was modified by this binary". After experimenting we deduce that "The timestamps could have been modified by this binary". This is better. We are not absolute in our conclusion.

Neither of these is wrong, and neither is right, however both are incomplete. Why? We're only looking at one source, and we can't make a dogmatic statement based on a sole source of evidence. As digital criminalists, we must be able to say that given all data points, and after careful evaluation the most likely explanation for the modification of the timestamps is this binary. There are many potential methods of timestamp modification, but given the data I am reasonably certain that any other explanation would be less believable and unlikely.

We must understand that our conclusion is not simply the correct one. It is the correct one, because other possible explanations have been ruled out as being plausible given the dataset. To truly achieve this we must have corroboration. Multiple sources of data must be in support of one another to have an accurate conclusion.

As the complexity increases, we must become more certain of our conclusions. We must truly understand what is the cause, and what is the effect. If we understand causality we can move towards science.