Wednesday, December 19, 2007

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

1 comments:

H. Carvey said...

I've used this sort of example several times, referring to Locard's Exchange Principle (and to some degree, Heisenberg) in my book, presentations, etc.

Let's look at a hackerdefender attack that's been in process for a while.

I'm not sure I follow, or understand...HackerDefender isn't an "attack"...it's a rootkit left behind by an intruder after a successful compromise of a system. In addition, nothing in the rest of the paragraph shows anything that has to do specifically with HxDef. You later say:

The tool used to gain entry to patient zero will have left tool markings on the system and the network.

But you don't go into how that would look to either the admin, or a forensic analyst.

Hacker defender has a definitive stria.

Agreed...there are specific artifacts that are associated with HxDef. However, none of the ones you've listed are the result of an attack.

SMBscan would be an example of a multi stroke tool.

How so? What is the "repetitive motion" this tool uses? Repeated password attempts? Where would we see those "tool marks" on a system?

Finally, how would you recommend that someone go about developing a "tool mark library"? Wouldn't it be a better idea to tie explicit artifacts to an incident rather than using "assumptive hypotheses"? For example, if I open up a port on a system I've compromised and put a hxdef.ini file the system, according to your post, the "assumptive hypotheses" would be that I've used HackerDefender in some way...but one also needs to look at:

- .ini file contents
- .ini file MAC times
- are there any associated .exe/.dll files?
- what is the LastWrite time on the hxdef Registry key that gets created? Does it even exist?
- etc.