Running head: M57-JEAN CASE 1

Forensic Tools

G. Logan Gombar

University of San Diego

M57-JEAN CASE 2

Forensic Tools

Sensitive M57Biz material appeared on a competitor’s website, to include personally

identifiable information concerning employees. This information included salaries and Social

Security Numbers tied to specific people. The only employee who had all this information was

the Chief Financial Officer, Jean, and she stands accused of sending this information to the

competitors. Jean claims innocence, that her computer must have been hacked. This report will

review the process and tools used in this investigation, the evidence, and the logical conclusion.

Collection

Data collection is a crucial part of a computer forensic investigation. Ensuring data is

copied exactly as it is present on the original is critical to the success of any attempted legal

actions. Between the use of two key technologies, the integrity of the evidence can be

maintained. First is a hash function, a one-way mathematical function that are computationally

infeasible to reverse-engineer a way to change the input to receive the same output (Larsen,

2019). This is used as a ground-truth summary snapshot of what the data looked like at the time

of gathering (Larsen, 2019). Additionally, the use of a write-blocker prevents changes to the data

being copied, while providing all the requisite read capabilities needed (Gungor, 2011).

Given these tactics are standard actions and procedures, the assumption is that these were

observed in the collection of the data used for this investigation. Given I was not handed any

explanation on collection methodologies employed, this assumption must be made as such. On

creation of the forensic clone, a Chain of Custody document was created, with the initial baseline

MD5 hash noted. Then I, as the expert investigator, signed the data out on the Chain of Custody

document for analysis and investigation.

M57-JEAN CASE 3

Legal Considerations

As part of a process that could eventually lead to legal action, the forensic analysis

process must be very meticulous, and follow the left and right bounds of the law quite closely.

One of the important considerations with regards to court proceedings is the Chain of Custody

documentation noted above. Additionally, attention to the privacy of data is critical when

investigating a person’s hard drive. There are several conflicting considerations at play in this

case, but the culmination is that the investigation into the drive is without issue due to the fact

that the data brought into a legal proceeding. Items such as whether the device was provided by

the company, if the company has a policy stating the company owns all data on the devices,

among other reflections must be considered when defining the legality of an investigation.

Analysis

Tools

There was only one tool used in this investigation, from an analysis perspective. I used

the SleuthKit Autopsy forensic imager to explore the drive while maintaining the desired

inability to alter data on the drive. This tool also verified that the data presented matched the

MD5 hash provided with the Chain of Custody, as shown in Appendix A. Additionally, I was the

only investigator, as shown by the second screenshot shown in Appendix A.

Evidence to Search For

Given data was exfiltrated from the network, there were a number of locations to search

for evidence. Email and Web traffic are obvious first contenders, but a location that later proved

mildly fruitful was USB connection events (screenshot in Appendix B). Additionally, Autopsy

will parse out common file types, to include spreadsheets, so I also would be looking there for

the data (screenshot in Appendix B). These vectors are viable locations that need examination.
M57-JEAN CASE 4

Exploring the Drive

Overall, the drive was relatively plain, with nothing exceptional in most places at first

glance. The web traffic was clean of signs of sending the document over the Internet. The USB

events seemed uneventful. However, a search of the emails on the system yielded a series of

convoluted communications that proved useful. In looking through said emails, it became clear

that Jean did, in fact, send the file in question. Additionally, a USB event became pertinent to the

search, when a Flash Disk attached to the system at the same time as the attachment file creation

time, seen in Appendix B. Furthermore, I found a series of very carefully engineered email

headers intended to trick Jean into divulging the data in question.

The timeline below has UTC time stamps starting on 20 July 2008. The APA guidelines

suggest a specific chart type, but the complexity of the data requires row banding, so I will use a

colored, row-banded table to make reading the events easier.

UTC Event Notes

1 23:31:00 Jean emailed Alison asking which email (Alison,
Alex) Alison will be using
2 23:33:51 Alison (as Alex@m57.biz) replied to Event #1 Alison proper; verified by headers Message-ID
with “This one, obviously”
3 23:39:57 Alison@m57.biz sent an email asking Jean to Initial phishing email
gather sensitive employee data, but not to tell Return-path & From not aligned
anyone about it, and to not include the current Message-ID is a different domain (dreamhostps)
email in her reply.
4 23:43:48 Alison (as alex:alison@m57.biz) sent out that her Alison proper; verified by headers Message-ID
email was misconfigured, she would use
alison@m57, not alex@m57
5 23:44:00 Jean responds to Event #3 with “sure thing”, Response to phishing email
sans email body
6 23:50:20 Alison responds to Event #5 confused, “What’s Alison proper got Jean’s response to the phishing
a sure thing?” -- Question shows Alison was not the original sender
7 01:22:45 “Alison” emailed Jean, demanding an immediate Second phishing email
update to the data gathering. It was intended to Return-path misaligned, Message-ID is still the wrong
put stress on Jean due to fear of losing a domain
Venture Capitalist funding source From is “tuckgeorge@gmail.com”
8 01:26:18 USB Attached Event on Jean’s computer Set the “Created” time of the file on Jean’s computer
-- Alison technically created the file a month prior
9 01:28:00 Jean responds to Event #7 with requested info – Data leaked here
the info later leaked to the competitor’s site Email never made it to Alison as the From was set to
“tuckgeorge@gmail.com” so the reply went there
M57-JEAN CASE 5

Autopsy Timeline Event Viewer enabled the untangling of the above timeline. This

enabled me to not only investigate email details in great detail, but also do so in chronological

order, providing me insight into the events at the time the leak occurred. This was crucial in

unwinding the events in a logically consistent way given the confusing nature of what happened.

Final Recap of Events

Jean was the victim of a social engineering attack performed via very well-crafted emails

that manipulated email headers to show Jean the email was from Alison. Considering the

specificity of the emails, the knowledge of the personnel involved, the attacker had done the

requisite research, moving this from a mere phishing attempt up to spear phishing.

The events technically could have been prevented, but the level of knowledge and

expertise Jean would have to possess far exceeds that of the average user. The average email user

likely has no idea email headers exist, much less how or when to check them. Moreover, Jean

would have to have more than a passing familiarity with the structure and functionality of email

headers to understand where they differed in important ways.

The email that Jean received only differed from a real email from Alison by two fields in

the email headers, shown in Appendix C. The second phishing email had more problems in the

headers, with a very unclear issue of Alison’s email followed by a random Gmail in the displayed

From field, also shown in Appendix C. What occurred here was Alison’s email was a display

alias used to trick Jean into responding with the requested data, despite it being the wrong email.

Alison never received Jean’s second response, the one that contained the sensitive data, due to

the attacker changing the From field, meaning any response would go to that email instead.

The interviews of Alison and Jean seemed at perfect odds with each other, but this chain

of events shows that both women are telling their perspective of the truth. Alison has no
M57-JEAN CASE 6

recollection of asking Jean for those documents because she never did. However, Jean did

receive an email, from what looked clearly like Alison, asking for the data. Jean sent the email,

but Alison never received it because the attacker altered the email headers so that the response

would go to them (shown in Appendix C). Each line of their testimonies is true.

Conclusion

From the given evidence, there was no clear malicious intent to leak the sensitive

information. What shows is a very sophisticated and directed social engineering attack was

successful due to a perfect storm of circumstances and very well-crafted emails. There were no

other employees involved, and the attacker was an external actor that posted the data to the

competitor’s site. Therefore, Jean did not intentionally leak the data, and is innocent of the

charges that she intentionally sent the data to competitors.

M57-JEAN CASE 7

References

Gungor, A. (2011, January 20). Using a write blocker to view a hard drive without modification.

Retrieved from https://www.meridiandiscovery.com/articles/how-to-take-a-quick-look-

at-a-hard-drive-without-modifying-its-contents/

Larsen, K. L. (2019, February 12). Understanding forensic copies & hash functions. Retrieved

from https://www.datanarro.com/understanding-forensic-copies-hash-functions/
M57-JEAN CASE 8

Appendix A

Chain of Custody MD5 Hash

M57-JEAN CASE 9

Appendix B

Exploring the Drive

This is how Autopsy show files by filetype, with Office documents having a section. Shown here
is two identical instances of spreadsheet in question (same MD5 hash), with one instance being
on the Desktop, and the other under the folder Outlook uses to store email attachments.

This is the USB Device Attached events viewer. Shown here is the USB Attached event that
coincides with the email being sent containing the leaked data.
M57-JEAN CASE 10

Appendix C

Email Header Comparisons

A legitimate email from Alison, with key indicators highlighted in blue

The initial phishing email. The highlights here show that almost everything made it seem like it
was Alison, except the Return-Path and the Message-id in the email header.
M57-JEAN CASE 11

The second phishing email. The crucial differences between this email and the previous phishing
email are that the From field in the header now has a Gmail (tuckgeorge@gmail.com), and that
the From field displayed on the email starts with Alison, but ends with the same Gmail.

The response Jean sent to the second phishing email. This contained the spreadsheet with the
sensitive information. It is clear that the email looked like it was being sent to Alison, but it was
not due to the From being the tuckgeorge Gmail. This is also why Alison never saw the
spreadsheet in response.