Don’t Marry the Suspect

Bad investigators look for proof they were right. Good ones look for where they are wrong.

The fastest way to damage an investigation is to fall in love

with the first answer that feels right or you want to be right or you are just too impatient to wait for the right answer.

The wrong answer might be a person or a theory. It might be an outside attacker, an inside employee, malware, a bad tool result, a disgruntled user, or whatever story makes you feel better or closes the case faster.

That is what I mean by don’t marry the suspect.

Once you marry it, everything changes. Every fact gets pulled toward it, the weak points get rationalized away, and every contradiction becomes “probably nothing” or “unrelated.”  Confirmation bias as its best.

Quick gut check: Ask yourself, “What if I am wrong?” and consider the consequences if you are. Who will be hurt by your decision?

If wrong, you build a weak case, you hurt the wrong person, you miss the real actor, and you destroy your credibility.

Good investigators start with facts, build possible explanations, test them, and eliminate the weak theories. They don’t start with an answer and then hunt for facts to prove it.

That sounds simple but it’s not common. Most bad investigative thinking does not feel bad while it is happening. It feels efficient and easy, and the bigger the ego, the easier it happens.

I’ve done all of these things before. I’ve found an artifact and went down rabbit holes trying to prove what I thought happened. I’ve seen better people than me do the same. It is a constant, every case, every matter, every breach fight.

If the evidence has to be bent to fit your suspect, you picked the wrong suspect

Sometimes your instinct is right. The problem starts when you stop testing it.

I saw this happen in an internal matter not long ago. The internal team was pushing hard toward an outsider threat. To me, the facts looked more like an insider. I was the outsider (consultant) looking at an insider angle, and I could have been wrong. That’s the point tho. No one knew yet. But I also did not discount either path just because one answer was more palatable for the organization.

The internal team did not want to seriously consider that someone on their own team could be responsible. That one assumption narrowed their thinking. Once they rejected the insider theory emotionally, they started evaluating the evidence through the outsider theory.

It turned out the insider theory was right. The wrong takeaway is that I was right, which is not always the case! The lesson is that both theories needed to stay tested until the evidence killed one of them. That is mental discipline.

If you need the suspect to be guilty, you are already compromised.

For those examiners, they find the login that fits their theory and ignore the access problem. They find the timeline that supports the story and ignore the timestamp issue. They find the artifact that points to the user and ignore the fact that the device was shared. They find the outside IP and ignore the employee behavior.

Bias does not always come from ego. Sometimes it comes from pressure. The boss wants an answer. The client wants a name. The agency wants movement. Legal wants a position. The incident response team wants containment. The company wants the problem to be external because of so many things they don’t want to deal with internally.

Authority bias can make it worse. When the senior person says, “This is obviously malware,” the room starts looking for malware. When legal says, “This employee is the issue,” people start reading the facts through that employee. When leadership says, “This was an outside attack,” the insider path gets put on the back burner.

That is dangerous, and not because leadership is always wrong or the senior people are useless. The danger is that a theory with authority behind it can stop being treated like a theory.

Once the story becomes protected, the investigation stops being an investigation and is closer to a witch hunt.

The fix is not to distrust everything or everyone forever. That is not investigation either. The fix is to keep competing explanations alive long enough to test them fairly. This is the basic “eliminate what the evidence does not support.”

Ask simple questions. What else could explain this? What fact would prove my theory wrong? What am I ignoring because it is inconvenient? What am I accepting because it supports what I already believe? 

Those questions matter because evidence is not there to make you feel right. Evidence is there to be tested.

This is especially true in DFIR because artifacts often look more certain than they are. A login looks like a person, and a device looks like an owner. Subconsciously, we look at it that way. But those things still need interpretation.

If the suspect did it, the evidence should survive the testing. If the insider did it, the evidence should survive the testing. If the outsider did it, the evidence should survive the testing. If your timeline is right, it should survive the testing.

And if it does not survive, let it go. Divorce yourself from it. That is the part people hate. Letting go of a theory feels like losing ground or a sunk cost, but it is progress. You are removing a bad answer before it damages the case and moving forward.

Date the theory. Test it. Argue with it. Try to break it. Compare it against other explanations. Keep the parts that survive and throw away the parts that do not.