Forensics

Case Study An attached to a $20 million dollar lawsuit purported to be from the CEO of “Tech.com” to a venture capital broker. The message outlined guaranteed “warrants” on the next round of funding for the broker. “Tech.com filed counterclaim and claimed the was a forgery. Their law firm engaged us to determine the validity of the message. We imaged all of the CEO’s computers at his office and his home. Recalled the server backup tapes from off-site storage.

Case Study Searched all hard drives and server backups for “questioned” message. Search revealed no trace of the message on any of the hard drives or mail spools. When the timestamps and message ids were compared with the server logs it was found that the “questioned” message could not have gone through either “Tech.com’s” webmail or mail server at the time indicated by the date/time stamp on the message. Based on our analysis Defendants filed motion to image and examine broker’s computers.

Case Study Federal Judge issued subpoena and we arrived at broker’s business, but he refused to allow his system to imaged. Broker’s lawyer went into State Court, on a companion case, and got Judge to issue an order for a new Court appointed examiner. The examination revealed direct proof of the alteration of a valid message’s header to create the “questioned” . What follows are some of the tools and techniques used to document the activity.

Internet Standards (RFCs) RFC – (Request for Comment) Standards for Internet Protocols RFC 2821 Simple Mail Transfer Protocol (SMTP) – the objective of SMTP is to transfer mail reliability and efficiently. It is independent of the particular transmission subtype and requires only a reliable ordered data stream channel. A mail message may pass through a number of intermediate relay or gateway hosts on it’s path from sender to ultimate recipient. (Supplements RFC 821)

The SMTP Model Reference: RFC 2821 Section 2.1

Internet Standards (RFCs) RFC 2822 Internet Message Format – the purpose of the standard is to establish the format of the messages. (Supplements RFC 822) Identification Fields “Though optional, every message SHOULD have a ‘Message-ID:’ field.” The field “provides a unique message identifier that refers to a particular version of a particular message.” It is intended to be “machine readable and not necessarily meaningful to humans.”

Internet Standards (RFCs) Message-ID: The composition of the message-id is represented by the formula: Date/Time Integer Can be formatted to display human readable date/time, but is usually in a hexadecimal string. On Unix systems, the string represents the “number of microseconds since midnight, January 1, 1970, Greenwich Mean Time.” (Unix Time – epoch)

Internet Standards (RFCs) Authentic Message-ID String To convert to human readable change the hex to decimal and use one of the Unix time scripts or one of the websites with a converter. 3989F5A3 = hexadecimal = decimal Aug 3, :43 = Date & Time (+1 hour logs)

Internet Standards (RFCs) Unique id: This is a unique identification assigned in the SMTP process. The domain name of the company is also attached to help ensure global uniqueness. ESMTP id: This is also a unique identification assigned by each intermediate relay or gateway server. This id is also usually in a hexadecimal string that is reset each day. Resulting in an id that can be resolved to a time window on a particular server.

Internet Standards (RFCs) Suspect Message-ID String To convert to human readable change the hex to decimal and use one of the Unix time scripts or one of the websites with a converter. 3989E793 = hexadecimal = decimal Aug 3, :43 = Date & Time (matches log)

Trace Header

Server Logs Typical logs kept for a week or less and then new log spawned. syslog. = 7/30 – 8/4 (current period) syslog.0 = 7/23 – 7/30 syslog.1 = 7/16 – 7/23 syslog.2 = 7/09 – 7/16 syslog.3 = 7/02 – 7/09 syslog.4 = 6/25 – 7/02 syslog.5 = 6/18 – 6/25 syslog.6 = 6/11 – 6/18 syslog.7 = 6/04 – 6/11

Server Logs Analysis of the webmail server logs revealed several issues regarding the validity of the suspect message. Matching trace header timestamps and ESMTP ids revealed that RAA01318 was issued at 17:41:31 to the authentic message. Comparing the 14:41:31 timestamp of the suspect message with the log revealed the server was assigning ESMTP ids beginning with “OAA” not “RRA” as represented in the header.

Server Logs Analysis of the mail server logs confirmed that the suspect message was not authentic. Matching trace header timestamps and ESMTP ids revealed that the authentic Message-ID was logged at 17:41:32 and assigned ESMTP id e73MfW then it was sent to the server and it was assigned a new ESMTP id Comparing the 14:41:32 timestamp of the suspect message with the log revealed the were no messages for over an hour during that time frame.

Outlook Message Properties

Default Outlook Fields

Outlook Client Fields

Notes Message Properties

Spoofs

William L. Farwell, CFE, SCERS Deloitte & Touche, LLP Forensic Investigative Services 200 Berkeley Street Boston, MA Questions?