The mechanics of digital forensics (and its related cousin, incident response) are fairly easy. A computer is a computer is a computer. Collecting data is collecting data. And an artifact is an artifact. As long as you follow the basic mechanical principles and concepts, you should be able to do the work without impossible obstacles.

A most basic example is imaging a hard drive on computer that is not running.

1. Protect the source
2. Image it

That’s about it. This example carries into all things DF/IR, as it is mechanical work coupled with decisions on overcoming obstacles in order to get the job done.

Here is where digital forensics is most easy!

DF/IR is easy to screw up. It is really really easy to screw up. Besides the mechanical ways to make an error, such as overwriting the original data, there ways to make things worse by thinking you know what you are doing, but actually don’t. Using the above example, there are a lot of little things that are needed for a complete job (like documenation, chain of custody, etc...).

Here are two personal examples.

Example 1:

I was hired for a civil case to examine a hard drive image. I received the image that was created by an employee from a nationally known computer repair company. The part of the case that matters is that after the computer was dropped off at this repair company, the computer was identified as being pivotal in a substantial and public civil case. An employee at the computer repair company talked his supervisor and attorney into believing that he could create a ‘forensic’ image of the hard drive.

The employee was first level IT in that I didn’t see much more experience than having an A+ certification and zero experience or education in digital forensics. The employee's only forensic work experience was creating this “forensic” image for the case using FTK Imager.

The process was not correct, as the employee believed that because FTK Imager (ie: “Forensic” Tool Kit Imager) was used, all was well in the world with the forensic image. Some of the issues: there was no chain of custody with the image or original source, the original source was subsequently lost, data was overwritten prior to and during imaging*, and barely any documentation existed. The only documents created were the receipt to drop off the computer and a text file created by FTK Imager.

I was hired to fix the ‘forensics’ in this case. The point of the story is that the employee thought he was doing forensics, but actually, he was screwing it all up by not having any basis of knowledge in the legal aspects of forensics or the technical aspects of creating an image (or much else).

End result: I couldn’t fix it because I didn’t have a time machine to go back in time to prevent the employee from touching the computer. Oh yeah. A new policy on not doing forensics was incorporated in the computer repair company.

Example 2:

On a civil case where I found child porn on a device, I immediately transferred the evidence to the local police department and wished the attorney-client luck (I don’t do those types of cases outside of law enforcement anymore). I also gave the PD the only image that I made of the original, along with an extensive report of what I saw that included verification of known CP hash comparisons. I’m stressing to you in this post that I made it extremely clear to the police department that without a doubt there was child porn on the hard drive, some of the worst that I have ever seen in my career. I even wrote my report as if it were an affidavit for a search warrant because what I saw certainly deserved police attention. 

Months later, the forensic detective told me in a phone call that he couldn’t image the drive and tried for months. He apparently gave up because he said that he was busy with more important cases (than child abuse), like rape and homicide...  He didn’t want any help, so that was it for me in the case. I offered that he could at least use my image that I gave...but nope.

Months later, I was re-hired to examine the drive, specifically for child porn, as the device owner was accused of also molesting his daughters. Then a weird thing happened. The wife (of the device owner) asked the PD to pick up the hard drive. She simply called and said it was her hard drive in evidence. They told her to come pick it up. Then they gave it (the original drive!) to her. Child porn and all. Nothing wiped, no court order for anyone to possess or examine.  Not only that, but the case was still open, and now included child molestation allegations.

The wife (client of my attorney-client) carried the original drive around, passed it on to her attorney, who days later wanted to give it to me. No one (including the police department) cared that child pornography on a hard drive in an active case of child abuse was being passed around without any a sliver of chain of custody or concern of what it legally means to possess that stuff. Or any care of how the data on the drive may refute or collaborate the real-time child abuse allegations.

PS: I refused custody of the drive until I was given a court order that said I could touch it.

The point of this story is that I wouldn’t expect the wife to know anything about chain of custody or possession of child pornography, but I would certainly expect (actually, demand) that the police detective and attorney exactly know. I further would expect that a police officer working in digital forensics could figure out how to image a hard drive in a day rather than never figure it out in months before giving up.

End result: I ended up in court. So did the detective. Some people got yelled at by the judge. I wasn’t one of the people getting yelled at. One positive out of this case is that there were so many problems, that I can use a hundred examples from it for a decade of how not to do digital forensics or police work.

These two examples, out of more than a few that I have personally seen, reinforce a largely ignored aspect of digital forensics work: a basic foundation.

A basic foundation is just that.  Basic. Foundation.

I am not talking about the basics of a specific job in DF/IR, but rather the basics that cut across all the jobs in DF/IR. This includes law enforcement! No one is perfect or exempt from being expected to have a basic foundation.

The DF/IR field typically focuses away from the legal aspects because many in the field wrongly assume that they are not working within the legal arena. For the most part, many are correct, until they aren’t. It is because that not only do we work with data, we also have a high risk of interacting with data that constitutes evidence in a legal case (civil or criminal). We should know what evidence is, how to know it when we see it, and what to do with it if and when we come across it.

Never complain about a problem without following up with a proposed solution

We need to know the foundational basics of both DF and IR.  When you focus on one small aspect of the entire field, you are working with a hammer. All your decisions will be based upon that small part of the field that you work with.  By “small part”, I do not mean insignificant. I mean that if we, in DF, come across an obstacle or issue that clearly fits the other side of the house, that we can identify it as such, and be able to refer or delegate it to more appropriate specialists. Same thing if we, in IR, come across a legal issue, that we handle it appropriately by knowing who best should handle it.

We cannot expect those who do not work in either DF or IR to know how to forensically image a hard drive, or have any of idea of the legalities of passing around a hard drive with child pornography (albeit, at the request of an attorney…after receiving it from law enforcement….). But we can require that us in the field have some basic foundation of both the common legal and technical aspects that cut across the disciplines.

A simple solution is requiring that those who work in either DF or IR, have this foundational knowledge. You don’t need to be an attorney to know chain of custody for evidence. You don’t need to be a police officer to know what evidence looks like. You don’t need to know how to reverse engineer malware if its not your job, but you should be able to know when it needs to be done. You don’t need to know how to do a chip off of a mobile device if you don't work with mobile devices, but you should know that it can be done if needed when you come across it.

What does a basic foundation look like?

1. What you need to know legally (only those things that everyone in DF and IR should both know)
2. What you need to know technically (only those things that everyone in DF and IR should both know)

Anything else is job specific and from which core competencies are built upon,  therefore not part of what I am talking about. Just the basics, like the very basics.  Because without it, digital forensics is really easy..to screw up.

For engagements where my clients ask for help in preparing for a ransomware attack, the most asked question is, “Do you recommend we pay if it happens to us?”

The decision to pay (or not) is based on the specific and unique situation. Are there unaffected backups? Is the encrypted data valuable or can it be re-created? Is the entire network held hostage? Can the ransomware be decrypted with available tools or keys? Basically, can we fix it or not? If not, then there is the decision to make on paying a ransom.

I know that clients want a definitive “YES” or “NO”, but it doesn’t work that way. If you advise to definitively pay, maybe they won’t get their files back and then what? Your advice was bad in that it didn’t work. And if you advise to absolutely not pay, then the client surely doesn’t get the files back. You’re between a rock and a hard place.

Here’s been my recommendation. Recommend that the client buy some bitcoin and hold it. How much to buy depends on how much you think a ransom will be based on the amounts of current ransomware attacks.  Then, if it happens, the client has saved at least a day of panicking in figuring out how to buy bitcoin and getting the money out of the budget to buy it, and potentially missing the window to pay the ransom anyway.

As far as will Bitcoin increase or decrease in value, that doesn’t matter. It matters to have some on hand. It matters just as much to have someone know how to access/send it when and if needed.

Then if a ransomware attack happens, the client can spend time on deciding to pay or not without having to have a team figuring out “what is this Bitcoin thing?” and distracting from the problem at hand (to pay or not).  

Probably the best advise I can give, is that if the client pays the ransom, there is a chance of getting the data back, or more accurately, getting back access to the encrypted data. But if you don’t pay, you have about a zero percent chance of getting access to your encrypted data. I’ve seen someone state that it’s about a 50/50 chance that an attacker will give decryption keys upon payment.  I’m not a gambler, but I say paying to get 50/50 odds is a lot better than not paying for 0/100.

The point of this post

A very adamant advocate of not paying off ransomware strongly suggested that I not recommend to my client that they should consider paying off ransomware. His point is that if everyone keeps paying ransoms, this will keep happening. I totally agree. If these attacks keep getting paid off, they will keep happening. The problem is that this is easy to say if you are not the victim. If the existance of your company rests solely on getting your data back, the 'common good' of not paying takes a back seat.

Or, the victim could pay a few bitcoin and better prepare in the event this were to happen again. Yes, the criminals make money. But also, the business survives (people keep their jobs!) and the business prepares to prevent this from happening again. 

I know that depending upon who a business calls for ransomware advice, one person will be advising to never pay and another person will be advising to look at the entire picture and keep all options open. The real answer to pay or not rests solely on the client. We can only give recommendations and a shoulder to lean on (or cry on....).

I’m big on attribution in crimes. It is my personality and attitude, which you can probably tell from the things I write and say (and have done).  With that, I completely understand that the “IR” in “DFIR” is not primarily about attribution, if it ever is. The IR (Incident Response) is a different job than the DF (Digital Forensics), but still related, like cousins.

In a pure digital forensics (ie. legal) matter, attribution is key. Attribution is the goal. Attribution is what you are working towards. Otherwise, it is not literally forensics, but only mechanically forensics, in that you may be performing the same mechanics as with forensic processes and methods, but if you aren’t looking to pin a crime on the suspect in a legal matter, it is not really forensics by definition.

With IR, pinning the crime/breach on the criminal or nation-state isn’t the primary mission unless you work at one of the alphabet-soup government agencies. But, IR is no less important than DF, even as the goals are generally different. With DF, the work is targeted to give justice to a victim through a legal process. With IR, the goal is usually to quell the panic of data spewing from the network like a busted fire hydrant in the middle of summer. Attribution is maybe an afterthought, at best. Stopping the pain is the priority.

But here I go splitting a hair with attribution in IR work….

When you do IR work (outside of the alphabet-soup government agencies), sometimes you should think about attribution in what you are doing. In fact, sometimes you must think about it because you might not be working a pure IR job. You might be deep into the legal arena! 

Fairly recently, I was asked to “look at” an employee’s email account for "hacking". Sure enough, someone other than the account holder had been in the account. Emails had been sent out from the employee’s account and some emails posted online by way of screenshots. Without getting into the weeds of what was happening, it clearly looked like internal drama in the organization.

The client/CEO wanted it stopped, but did not care about who did it because, “Nothing you can do about it if China is doing it.”  This was the advice from IT to the CEO. Hackers can’t get caught, so don’t waste money on it when you can just prevent it from happening again. However, just by looking at the content of the emails that were being sent out and posted online, it was clearly an insider job or someone related to the employee in some manner. Seriously. It was so blatantly obvious that the employee was targeted and that most likely, it was probably another employee just by a quick glance of how it was happening. I gave an estimate of a day to be able to find out who it was, and still, the solution was to stop it from happening and not worry about catching the culprit.

Good grief.

My point is that sometimes you can catch the person because maybe the suspect is not in Iran or China or Russia or Timbuktu. Maybe s/he is in the next cubicle. In this example, the suspect was in IT, which took me a half day to figure out, without even having to skip lunch. End result was that everyone happy (the in-house attorney, the employee and the CEO). Except the IT person. He was not happy. But everyone else was.

Most anyone working in IR can fairly accurately tell where the hacks* come from. Maybe not to a specific person or nation-state, but at least be able to gauge whether or not the suspect is in the same building or down the street or related to the organization (generally!). There is nothing wrong with advising a client that although you can certainly stop the pain of a hack* (see the below definition..),  you may also be able to solve a problem that is just as important which may actually have a positive ROI beyond dollars spent.

This is just an example of when a pure IR engagement can turn into pure DF gig, simply because IR can see typically be able to determine that not only can you identify the suspect, but that you should because in a case like this, the victim will keep being victimized by someone that can be caught and brought to justice.

*hacks, as in whatever you want to call unauthorized computer access.