Guest Blogger: Kevin Schell

No matter what your line of work, you’ve sat across from someone and thought you could read them, something in their eyes, the way they moved. It’s a gut thing. You can’t say whether it’s right, and when researchers have tested it, as in the Bond and DePaulo meta-analysis, people land barely better than a coin flip. Digital evidence has the same problem. A timeline can pass every technical check and still not fit the person it describes. The hashes verify, the timestamps hold across two tools, the artifacts are exactly where they should be. Yet something about the story is still… off.

That feeling isn’t proof, but it shouldn’t be dismissed either. It’s a signal, and it can be worked like any other signal if you have something to measure it against. A baseline.

Artifacts Tell You What Happened. They Don’t Tell You Whether It Fits.

DFIR does its job well when it answers all the technical questions. What was accessed? When? From which device? Was the data altered? Those answers are the foundation, and nothing in this article replaces them. But artifacts are only a part of the picture. They describe actions on a device. They don’t describe whether those actions are consistent with the human being attributed to them.

If you work with threat intelligence, you already know this distinction. Indicators of compromise are useful but short-lived. Tactics, techniques, and procedures are more stable because they describe how an actor behaves. People work the same way. A single artifact is an indicator. A person’s established patterns of communication, routine, and decision-making are their baseline, and the baseline is what tells you whether the artifact belongs.

Building a Behavioral Baseline From Open Sources

Open-Source Intelligence (OSINT) is how you build that baseline without touching the evidence. Publicly available material can show:

• Routine and rhythm: when a person is typically active, and when they typically are not.
• Communication style: length, formality, vocabulary, punctuation habits, and how that changes by audience.
• Social patterns: who they engage with, how often, and in what tone.
• Stability over time: whether a pattern holds for months or shifts repeatedly.

The goal is not a profile, it’s a reference point. You are documenting what normal looks like for this person so that you can recognize when the evidence departs from it.

Reading Deviation: A Composite Example

This is a constructed scenario, not a real case. A device image shows a burst of outgoing messages at 2:10 a.m. from an account tied to the subject. The extraction is clean, timestamps are validated across two different tools. Technically, nothing is wrong.

The open-source baseline says something different. For the past year, the subject’s public activity clusters in the early morning and early evening, with nothing late at night. Their messages are short, informal, and loosely punctuated. The 2 a.m. messages are long, carefully structured, and written in a formal register the subject doesn’t use anywhere else.

That doesn’t prove someone else used the device. It doesn’t prove anything for that matter. What it does is hand the examiner a short list of specific questions. Was the device shared? Was the account accessed from somewhere else? Was the subject in an unusual state that night? Each question points back to a technical check, such as login sources, device state, and session data, that can confirm or eliminate it.

An examiner without the behavioral read would have shipped a clean timeline and never asked any questions.

Limits and Cautions

This method can go wrong, and the failure modes are predictable.

• Confirmation bias is the biggest risk. If you go looking for deviation, you will find it. Define what counts as a deviation before you review the evidence, not after.
• A thin baseline is worse than none. A few posts don’t establish a pattern. If the open-source record is sparse, say so and stop.
• People change. Stress, illness, and life events shift behavior. A deviation is a reason to ask a question, not an answer.
• Stay in your lane. A behavioral observation is not a technical finding and shouldn’t be presented as one.
• Scope and authority matter. Baseline work needs the same legal and organizational footing as any other part of the investigation.

Recommendations

1. Complete and validate the technical analysis first. The behavioral read comes second, never instead.
2. Build the baseline before interpreting the timeline, and document every source and date.
3. Define in advance what counts as a meaningful deviation.
4. Corroborate any behavioral inference with an independent source before it appears in a report, the same way you would not rely on a single tool.
5. Report observations as observations. “Inconsistent with the established baseline” is defensible. “Someone else did this” is not.

Conclusion

Digital forensics asks whether the evidence is valid. A behavioral read asks a second question: does the evidence fit the human attached to it? The first question protects the integrity of the data. The second protects the integrity of the conclusion.

Neither one works alone. A technically perfect timeline that doesn’t fit the person is a lead you haven’t followed yet. Treated as a structured, documented, repeatable step, the behavioral read gives examiners a way to follow it.

About the Author: Kevin Schell is an intelligence analyst focused on behavioral threat assessment, OSINT, and protective intelligence. He holds an M.S. in Forensic Psychology and a B.S. in Criminal Justice and Homeland Security, and is certified in Digital Forensics and Social Media Investigation. He writes the Dead Reckoning series on Medium. www.linkedin.com/in/kevin-schell6674